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.