Dependency management is a very important discipline for a project manager.  It is the “D” in RAIDs management.

What is a dependency?

gantt showing project dependenciesIn simple terms, a dependency is where a task, milestone or activity is dependent on another task or milestone being completed before it can start or be completed.

It is possible for a project to have intra-dependencies. This is where tasks, milestones, etc within the same project are dependent on each other. The other type of dependency is external. This is where the dependency is on a different project, programme or even business as usual.

A project manager must be aware of all of the dependencies for their project.  The reason is simple, if a dependency is not met, the successful delivery of the project may be threatened.

A smart project manager should call on the services of the  PMO, a good, value adding PMO will be able to facilitate and manage external dependencies as a project manager should have the empowerment and oversight to manage intradependencies.

Dependency tools

In a similar way to the management of risks, issues and assumptions, the simple method of recording and monitoring dependencies is by using a dependency register. This should typically capture:

  • Unique Reference – used to identify dependency
  • Description – used to briefly describe the dependency
  • Enabling Programme / Project – who must deliver the task, milestone, etc (sometimes known as the ‘giver’)
  • Task / Milestone Description – details of the exact milestone / Task that must be delivered
  • Dependent Programme – who needs the task, milestone to be delivered (sometimes known as the ‘receiver’)
  • Dependent Task / Milestone – details of milestone / task that needs the delivery
  • Delivery Date – date dependency must be delivered by to not cause a delay in dependent project
  • Probability – probability that dependency will not be met in required timeline
  • Impact – impact of dependency not being delivered in required timeline
  • Status – open, closed, etc
  • Owner – who owns the dependency
  • Date Raised – date dependency was raised

Other fields can be added to indicate if dependency is on the critical path, etc. However, the above fields should allow for the management of external dependencies.

How to capture dependencies

You will see lots of articles and diagrams that show wonderful process flows for managing dependencies. However, the real skill is identifying what are the dependencies that need to be worried about. This is not an exact science and difficult to fully document. However, the following to be a good approach.

1. Awareness sessions

Get all of the projects and programmes into a workshop, ideally no more than 2 hours. Ahead of the meeting get each project to prepare a one page slide using a standard format. This should provide:

  • Project name
  • Sponsor
  • Project Manager
  • Start / end dates
  • Current status
  • Business area / function
  • Overview of the project
  • Business process being changed
  • Platforms being implemented / changed
  • Key milestones
  • Key issues / risks

In the actual meeting, the PMO lead should set the scene by stating the purpose of the session is to identify any dependencies between projects.  Each sponsor / project manager will then briefly discus their project.  This will allow other project managers to ask questions and identify potential dependencies i.e. where 2 different projects are trying to change the same system at the same time.

At the end of the session you should have:

  • List of potential dependencies
  • Possible dependencies with clear actions for the appropriate project managers to discus after meeting

The PMO can then spend time reviewing and cleansing the list.  Working out the exact milestones where the dependency exists and then play this back to the project managers to agree

2. Agree dependencies

When all of the dependencies have been captured, it is then necessary to work with the project managers on either side of a dependency to confirm and agree that the dates are realistic and achievable.  If not, one of the projects will probably need to re-plan.  The aim is to have all parties in agreement on the delivery date.

3. Monitor and control

The now should be a clear view of dependencies and the associated milestones in the different plans.  The PMO should track progress against these critical milestones as part of the regular meetings and reporting.  When a milestone looks like it is slipping, they can quickly explore if it will be missed and then start the dialogue with the receiving project so as to assess impact and mitigating actions.

However, it is important that each project manager monitors the dependencies that are important for their project.  The same way risks and issues should be reviewed, the project manager and / or the project team should check to make sure that all deliveries on which they are dependent, are on track.


Dependency management can be a very complicated, time consuming activity.  Therefore, think about how many dependencies need to be managed, the ability of the projects to communicate effectively and the impact of dates not being met.  This will then allow you to decide how much time, effort and process you wish / need to commit to dependency management.  However, running a session like the one described above will help open the channels of communication, flush out dependencies and allow for monitoring as part of the normal reporting cycle.