Category Archives: A Simply Better PMO

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

 

Getting a handle on risk and confidence


In one of our earlier posts “Addressing challenges along the program delivery path” we talked about how successful program management seeks to ensure that the impact of changes in business operations is coordinated and that the transition to the new ways of working is explicitly managed.  However, programs are fraught with challenges.  Delivery is never guaranteed.

To overcome these challenges, program management should focus on inter-dependencies between the projects and the risks and issues that may impact the program as a whole through leadership, direction setting and decision-making processes with individuals responsible for these processes. 

Hired by a client recently to define a large strategic program, we were faced with a familiar set of circumstances. There was no formal organization, plenty of perceived expended effort with little forward motion and no view of or control over a myriad of potentially crippling risks.

Taking back control we put proper planning in place with the Work stream Brief and defined the work to be done in a structured way using the Work Breakdown Structure. However, as helpful as these measures were, there was no view of the impact that risk had on project delivery and without this view, they couldn’t address the ongoing impacts.

In addition to a traditional risk log we coached project managers to develop an understanding of these risks and their impact and helped them report on the confidence of successful delivery. The tool we developed to do this was the confidence matrix.

An example shown above, this matrix is used to help project managers think about the risks facing them against a common set of dimensions such as scope, resources etc. and to define their confidence in delivery in easy to understand language color coded to focus attention on those with the highest impact and needing attention – those representing the biggest threat to successful delivery.

We have found that the confidence matrix is an excellent way to focus the attention of busy executives on the problems that matter. Risks and issues are handled as a continuum, and the matrix forms an integral part of the management process, providing a highly visible, top-down view which allows a clear management focus on the real threats.

Through a one-page snapshot, stakeholders can quickly determine which areas require immediate attention.

A confidence matrix brings risk management and prgram management closer together and enables an effective management through:

  • A top-down framework to ensure focus and completeness
  • A proactive process and forums for resolution, reporting and escalation
  • Application at both program and project levels, with rules for escalation
  • A brief summary of the detailed logs which record and classify risks, issues and other constraints, i.e. their likelihood, severity, owners, action assignments and status.

With this new awareness, helped by the confidence matrix, the client was able to quickly take control of their projects and vastly improve delivery confidence. The entire program is now on track for successful delivery.

John Hall

The work stream brief a planning cure all?


In a previous blog Top-down versus bottom-up planning: a false dichotomy we discussed the clear inter-relationship between Program and Project Management Plans and how there is overlap between these plans to establish targets (at the program level) while demonstrating feasibility and commitment to delivery (at the project level).

One of the key deliverables in any project is the charter which outlines in detail, the objectives, scope, key milestones, dependencies, costs, resources and risks. The detail expected in these documents is appropriate when in the process of setting up the project management plans but the effort is significant.

It is also vital to the successful outcome of any project or program to devote sufficient time to planning up front and dealing with “hassles” early in the process (see Putting in more effort during the initial planning stages pays off in the long run) rather than procrastinating and paying a higher price later by risking successful delivery.

In a recent project the client was gearing up for a large program with multiple work streams and projects. We found there to be well defined program management processes but much of the rigor of these processes was being ignored by the teams. There was also little planning co-ordination between these teams.

The project charter included in the process was a formidable document which no one wanted to use because of the sheer effort in completing it.

Working with their teams we devised an abridged “charter” for each work stream, a “charter-lite”, see below, which each could complete quickly but thoroughly and which contained sufficient data to launch the more detailed planning process and get the work started a good deal sooner.

Called the work stream brief, the teams liked the easy to understand format and all were able to get the planning and discovery work started quickly and the results were really encouraging.

Projects which were previously considered difficult or complex were easily analyzed using this tool and the data which was collected was shared with the other work streams enabling better integration with architecture teams and the business and brought a much better understanding of scope dependencies and risk. Previously this information was not shared and the benefits and delivery success was limited.

A simple solution to a complex problem which enabled the work streams and the program to make a leap forward and drive delivery benefits for the business.

In a future blog I will discuss an old favorite, risk and how it impacts confidence in delivery. 

%d bloggers like this: