Is your project hooked on dependencies?

Concept of gantt chart with task completion.“My project is going to be delayed because I am dependent in ‘X’ and ‘X’ is behind schedule”

Sound familiar?

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.


The basics

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.

Tagged with: ,
One comment on “Is your project hooked on dependencies?
  1. James says:

    this does sound familiar. rather too familiar for my liking.

    great points, the critical path of a project, its dependencies and effectively managing the resources and tasks shouldnt be left to chance.

    a PM should be skilled in identifying the issues before they become critical. when this happens, review the resources on this task, establish what needs to be actioned to get the project back on track.

    to ensure all stakeholders are kept up to date during the project i use a common tool such as mindgneius (the tool our PMO and resources all utilise)

Leave a Reply

Your email address will not be published. Required fields are marked *