How to Manage Project Dependencies and Interdependencies

I’ve previously written a post about Dependency Mapping. Whilst it’s not the most popular post in terms of the number of visitors it receives, it’s certainly the post about which I get the most emails. Although I explained how to map dependencies in that article, people usually ask for a more detailed example to help them manage their dependencies. Given that, the aim of this article is to walk through dependency mapping in a little more detail than the previous article.

The most obvious way to manage dependencies through a Dependency Structure Matrix (DSM). The acronym DSM is often referred to as a Design Structure Matrix. In the context of a project or program, a DSM is basically a matrix showing which tasks need to be completed before a particular task can start.

The simplest possible DSM is shown below.

Simplest example of DSM

Here we have two tasks, A and B. To construct the DSM we write all tasks on both the vertical and horizontal axes of the matrix. In the above example, we have placed an X in the matrix, showing that task A must be completed before task B can start.

Even in this very simple example, it’s possible to introduce some complexity. Take a look at the example below.

DSM with loop
Here we are saying that task A must be completed before task B can begin. At the same time, task B must be completed before task A can start. In short, we have a contradiction. There are a couple of techniques in DSM we can use to get around this problem, Clustering and Splitting.

DSM: Clustering

Here we place a box around the interdependent tasks to show that they will be managed as a whole with very close collaboration between teams. Another way of saying this is that the clustered tasks will be managed together as a single task.

Simple DSM Clustering Example

DSM: Splitting

This is a different approach to the same problem. Here we analyze A and B to understand the cause of the dependency loop. We then create a new task (let’s call it Task C) which needs to be completed before either task A or B can start.

DSM with Splitting Example

At this stage, you might be wondering if I’m going to provide you with a template to solve all your dependency issues, or you might be thinking that this looks like it could get very complex, very quickly, especially if you have thousands of dependencies. My personal opinion is that DSM has great potential, and I can even envisage it to assist in program planning, but for now it’s too unwieldy. If anyone out there has been successfully using DSM for large programs or knows of a tool to tame DSM, then please drop me an email.

Dependency Management: How I do it

Because I’m unable to get DSM to work for anything but the smallest program, my preferred method of managing dependencies in project management (and program management) is as follows.

Ask each project stream to consider its key deliverables and milestones, and examine the dependencies on delivering their deliverables or milestone at the individual project level. Next plot this into MS Project or create a Spreadsheet with all the dependencies plotted onto it, along with the program milestones. You may want to get your Program Office to perform this task as it can take time. This will result in a much more complex version of the following diagram, which is in effect a project dependency matrix template:

Example Dependency Map

On this project interdependency mapping is complete, the next step is to get the whole team together and hold a Dependency Culling Workshop. Here you will spend the time to understand the dependencies between projects and try to eliminate as many dependencies as possible. Spending the time to remove as many dependencies as you can, will make your program run more smoothly. Remember that the ideal number of dependencies is zero. One the workshop is complete you have yourself a baseline project interdependency map.

Once the project is in full execution mode you should consider asking the project streams to report on the status of key dependencies on a regular basis, enabling you to track the key dependencies and take corrective actions if necessary.

Note that you could equally use the above template to track interdependencies in business change initiatives.

Finally, there is one key tip for managing interdependencies in project management, and that is to try to get the number of dependencies as low as possible. Work with your teams to creatively think of ways to reduce dependencies, for example, full stack teams are better than having a web team and a database team if you’re working with software.

Gareth says

Excellent, just what I’m looking for.

Could I get a copy of this dependancy map template please?

Gift says

This is what i’ve been looking. please can i get a copy of this dependency map template please? thanks

E says

Exactly what i have been looking for! Can i get a copy of the dependency map template please?

Precious says

Hi There,

Please can I get a copy of this template please?

Charles says

Guys,

The author has been kind and brilliant enough! Asking for the template seems like pure laziness to me as it is fairly straightforward and easy to build in Excel. On another note, the chief aim of dependency management is to augment risk management , but a lot of project people seem to overlook this…

Denis says

Thanks! And so true.
Denis

Bob says

You mention culling dependencies. Can you give an example of how an identified dependency can be culled?

Denis says

Hi Bob,

Good question.

I simply mean that the best way to manage dependencies is not to have them in the first place. A couple of ways to solve this are…

1. Through team structure: A really simply example from the software world is: can you make the case for a project to have full-stack feature teams rather than a database team, ecommerce team etc etc.
2. Through planning: don’t commit to a deliverable that has a dependency until the dependency is delivered. So, if you were building a house you don’t commit to building up until the foundations are complete and signed off. Also, read this about derisking a project through planning: https://expertprogrammanagement.com/2010/11/planning-and-risk/

This is just a couple of off-hand ideas. You obviously can’t get rid of all dependencies. For those that you are left with make sure you have end-to-end visibility across all teams, and have a representative from each team meet frequently to discuss specifically those dependencies and the status/progress.

Denis

Comments are closed