How to manage project dependencies

Many projects struggle with (external) dependencies. Most of the time these dependencies can not be managed. They are simply out of the control of the project and the project management is only able to monitor and maybe influence. There are however often dependencies that are results of poor project design and therefor occur by choice. These are dependencies between projects (in programmes and in portfolios) and should often be managed by focus on quality.

I use the lessons described by and terminology used by PRINCE2 and MSP (Managing Successful Programmes).

The customer of a process is the next process.

Quality should be clearly defined by the customer. But the difficulty is often to realize who the project’s customer is.

Interfaces between teams

Let’s start at the bottom: the work in teams and their dependencies. Imagine a project to move a manufacturing company to a new location. As part of the project machinery needs to moved. There are three teams: one team dismantles the machinery. Another team moves the machinery and a third team reassembles the machinery. Obviously, the final criterion is that the machinery works at the new location. The Product Flow Diagram of this part of the project would look like this:

A product should have quality criteria and these criteria will be defined by the customer of that product. Dismantled machinery could have criteria such as: parts should be boxed, maximum size, maximum weight. These criteria will be defined by team 2.

Team 2 can be seen as the customer of team 1.

The customer of a process is the next process

W. Edwards Deming

And team 3 can be seen as the customer of team 2 because the same will apply to Moved machinery. Team 3 may want the moved parts to arrive at a certain location and stored in a convenient order. Team 3 may also require that all parts are labelled and described by an inventory list. These requirements will then be passed on by team 2 as requirements for Dismantled machinery. Clear goals in terms of measurable quality criteria will help to prevent a lot of confusion, rework and delays.

Dependencies between projects

Now we will look at dependencies on a higher level: between projects in the context of a programme or portfolio. Imagine a company planning a project to develop a new product. The company’s sales force will sell the product to retail chains. The company will be responsible for the product’s support. The chain would look like this:

A common practice is to create several projects, based on technical specialism. The project we use here would often be split up, possibly in this way:

This would in many organizations be the normal and most intuitive way to organize the projects. Even in the MSP guidance there is an example of projects grouped by technical disciplines (IT-projects, HR-projects), But this is also usually the most ineffective and most risky approach. This approach normally creates many dependencies and interfaces between projects which results in unclear goals, fragmentation, confusion, overhead, many meetings, low quality and severe delays and cost.

As MSP also states, the approach should be to design projects as independently as possible (cohesion). I recommend to take the same approach also on the lowest levels (project teams). As shown this can be done by a focus on products (a PRINCE2 Principle) and on a higher level a focus on coherent parts of the Blueprint (MSP defines a Blueprint as a coherent set of Processes (1), Organization (2), Tools/Technology (3) and Information (4); the POTI model).

In the MSP view coupling between projects should be prevented as much as possible. A common way of coupling is a focus on work and disciplines.

Resource Dependencies

This article focussed on dependencies created by poor design and approach of projects, resulting in poor quality and many interfaces between projects and teams. I believe this is the most common and most problematic type of dependencies, although very often hardly recognized and underestimated.

When having to cope with resource dependencies, I recommend the excellent guidance by Eli Goldratt. Goldratt’s Theory of Constraints became a well-known approach when he published his book The Goal. A very important theme is the management of bottlenecks: that part of the process with the lowest capacity. As an extension of his work, Goldratt later published his application of ToC for projects in his book Critical Chain.

Conclusion:

Dependencies between projects are often caused by poor project design. This where clear and coherent goals will help, supported by MSP’s Blueprint and PRINCE2’s focus on products (quality).

Your opinion?

Do you have opinions on this subject? Please add your comment below. It will be appreciated!

About the author

Specialist in effective change.

Accredited MSP™ and PRINCE2® trainer.

comments powered by Disqus