Dependencies outside the control of the project manager are one of the most common reasons for project delays and late completions.
But there are things you can do to minimise the likelihood of delays and the potential impacts on your project. Too many project managers hand off the responsibility and shrug their shoulders.
They think they have a ‘get out of jail free’ card.
To me, that is just abdicating responsibility and I want to know everything the project manager has done to mitigate the possibility of a delay due to dependencies.
Let’s go though the basics of dependencies first to ensure we are all on the same page.
Internal dependencies: these are dependencies within your project. You can’t start task B until task A has completed. These are within your control and should be managed through linkages between tasks or milestones in your project plan. Microsoft Project does this very well.
Dependencies between programmes or independent projects: This is where your project or programme is dependent on a deliverable from a project or programme outside your control, but within your organisation. These could be managed through enterprise level project/programme management tools directly or by separate processes. We’ll discuss this later.
External dependencies: This is where you are dependent on a deliverable from a third party outside of your organisation. This could be a system, a building, some marketing materials or even decisions or details from a regulator.
Managing complex intra organisation dependencies
If you have a large and complex project, possibly with sub-projects in separate plans this can get complex and I would recommend having a dedicated planning resource to build and manage the plan.
Managing complex Microsoft Project plans (or using any tool for that matter) can be a black art. Beware the auto-schedule feature. Back up first before you use it as it can sometimes have unexpected consequences. Some server based systems make it hard to back up first so be especially careful here, Many hours of good planning can be lost with the click of a mouse.
Managing dependencies between projects in a programme, or between programmes or independent projects can be handled through tools like Microsoft Project Server. Milestones within separate plans can be linked but it requires a fairly high degree of standardisation and control across all projects to work effectively. Even in organisations which use enterprise level tools this can be a step too far.
I prefer to give project and programme managers a bit more flexibility in their use of the tool and put in place some additional processes to capture and manage dependencies.
At the core of any dependency management process is the dependency definition form. This is where the dependency get’s described and should be used by both sides to agree the date and a common reference. Reporting can then be used across both projects/programmes to check the dates don’t move on either side, or at least flag when that occurs.
The key is the engagement between the programmes. It needs to be early in the programme, open, honest and frequent. So no surprises down the line.
Managing External dependencies
Here you have even less control or influence that in the inter-programme scenario. I would still use the dependency definition form so that ecerything is clear but you need contractual stuff in place too.
Just because a contract says they will deliver, you cannot just rely on that. You need to ensure the contract provides for regular progress updates, the opportunity to do onsite checkpoints to ensure you get visible progress, and you need to build extra contingency into the delivery schedule.
Lots of contracts have penalties which all well and good, but they won’t deliver the project for you and rarely compensate for the lost opportunity.
Dependencies are often the achilles heal of a project. The key to success is early identification and agreement, then frequent open and honest communication.