Managing dependencies between initiatives on almost any scale is a tricky business. Many large programs and even some portfolios of work have been tripped up as a result of the dependencies between initiatives, or decisions associated with those initiatives, being unclear. Some time back we wrote a white paper called Dependency Management are we there yet, which focussed on the mechanics of dependency management, however many large programs and portfolios still struggle to do it well. So how do we do it better? There are many aspects to effective Dependency Management but we thought we would focus on terminology.
Imagine you are knee deep in a large program and have identified a number of things an initiative within the program requires of other initiatives (within the program or outside the program) or from the organisation (eg resources or money). It is logical that some mechanism be put in place to ensure these things don’t trip you up.
Imagine it is now several weeks further down the track and you are confused. You don’t know if the thing you know is required is a dependency, a risk, a constraint or something else because time wasn’t taken to define “our” terminology up front.
To avoid this, consider up front the terminology which may trip up effective management of dependencies. Here are some examples:
- Every dependency between one initiative and another has an embedded risk. So should we call it a dependency and manage it as such or call it a risk and manage it through our risk management process?
- Is there a difference between a dependency and an interdependency? If a dependency is within the initiative and an interdependency is between initiatives, do we only try to manage the interdependencies and leave the dependencies to the project manager?
- Is there a difference between a dependency owner and a dependency manager?
- Is there a difference between a soft and hard dependency?
- In the context of a dependency, what is a supplier or receiver?
- Should organisational constraints (such as resourcing and funding) be managed as dependencies or through another mechanism?
The answer to most of the above questions really don’t matter. What does matter is that when the answers to the questions are found, they are communicated, are clear and are used consistently by everyone in the organisation so that confusion is avoided.
So before rolling out dependency management, take the time to define the terms, agree what is what and get the entire team onto the same page.