Dependency everyone can buy into

The last few Simply Better PMO articles in this series have explained, by way of real experiences with clients, the tools and techniques I have discussed in my articles.

 It is important to me to maintain the link with real experience to show that what we discuss in our blog is not just theory but well proven techniques used with our clients to deliver real value for them.

 This article continues in the same way and deals with that old favorite, dependency management. I talked about the work breakdown structure in a previous article where that process was aimed at defining the work that needed to be done in logical workstreams to complete the project, minimizing dependencies.

 In any reasonably sized project there are always dependencies to manage between work streams even if the work breakdown structure has been well constructed. The work is translated into a project schedule detailing the tasks and activities and the dependencies between tasks. This allows the project manager to understand the project in more detail and to ensure that each dependency is understood and owned so that it is completed and delivered at the right time.

 In very large complex programs where there are thousands of activities and many work streams, this task becomes a lot more complex.

 In a very large program recently, our client asked us to help set up the program management and delivery assurance function. This was a complex program with 4 work streams and 32 infrastructure, end-user system and process projects. During the detailed planning process some 146 individual input and output dependencies were identified and which needed to be actively managed over the duration of the program. While these were all detailed in the project schedule and accountabilities for each allocated, the Program Director needed an intuitive way of managing these dependencies and tracking the status of each while the work streams delivered against their schedules.

 We proposed a tool we had developed, the dependency matrix. This matrix lists the projects on adjacent sides and each intersecting cell details the input or output dependency between those projects as shown in this diagram represented by #1 to #13.

Each dependency is color coded according to its status at each reporting cycle and is updated by the PMO based on inputs from each project manager for inclusion in the status report.


In this way the Program Director discovered that dependencies could easily be tracked using the simple color coded tool and that those requiring attention and resolution during program execution could be addressed. The tool also proved invaluable during work stream planning when additional projects were added and defining the dependencies quickly resulted in a well integrated project schedule. It is easy to use and update and since this program is still underway, the dependency matrix is a key tool in the delivery assurance process ensuring a reliable outcome for this important strategic program.


In our experience the tool particularly lends itself to highly complex programs where dependencies are difficult to manage but it is just as effective in less complex program environments.


In my next article I will discuss further experiences with clients assuring project portfolio delivery.

 John Hall


Post a comment or leave a trackback: Trackback URL.


  • Peter Martiniello  On November 9, 2011 at 10:16 pm


    Found the article interesting. I have used various methods to represent dependencies between projects, but they all had issues in providing a simple overview useful to assess issues with dependencies.

    After reading the article I am not quite sure how to interpret the information. My interpretation is

    – Columns outputs show projects which will produce a deliverable other projects have a dependency on.
    – The number in a cell represents the project waiting for the output produced by the project. For example column (project) C output will be provided to “project” #1.

    A few questions

    – Confirm that the numbers in the cells (eg #1) do not correspond to a project shown in column/row (#1! = project A).
    – Does a cell number (e.g. #1) represent a project or is it an index to other details maintained elsewhere.
    – How is the matrix used to show a project waiting/providing more than one dependency?
    – Can you elaborate on the data used to generate the dependency matrix?

    • johnohall  On November 10, 2011 at 9:24 am

      Thanks for your comment Peter.

      Columns and rows represent the same set of projects (A to K). The columns represent projects producing outputs consumed by the rows.
      The numbers in each cell represent dependencies, not projects. The dependency details are captured in each cell. (the numbers are merely indicative of descriptive text)
      Projects with multiple dependencies are indicated by multiple dependency entries in the same column or row (e.g. project C has dependencies with C & E)
      The data used is the detailed project schedules used in facilitated discussions between the projects/workstreams to define in detail and plan for the dependencies.

      Hope I have answered your questions?

      • Precious  On March 8, 2014 at 4:52 am

        Hi John,

        I found this article to be very interesting as well. My question is that how do you represent multiple dependencies with various status, since projects with multiple dependencies are indicated by multiple entries in the same column or row.

      • johnohall  On March 8, 2014 at 10:04 am

        Thanks for your comment and question Precious. Obviously the real estate in a single spreadsheet cell is limited but you can add muotiple dependencies within the cell but need to be brief. We have done it and it’s suitable for most large projects.

  • JJ  On December 2, 2011 at 7:35 am

    just in initiation phase of what will likely be a heavily inter-dependent programme. what if a project had more than one inbound dependency on the same project? if i am interpreting the grid correctly it seems you could only represent one at a time.

    • johnohall  On December 2, 2011 at 7:52 am

      That is a common situation. You can capture as many dependencies as you like in each cell (workstream/project).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: