In defense of the Digraph

I’ve found project risk management to be one of the weakest performed PMBOK knowledge areas in most organizations, even for those companies whose operational risk management practices are very mature. A part of this challenge is that we tend to identify obvious risks but miss key ones when we don’t engage sufficient stakeholders in the identification process or when we ignore lessons identified in past projects. But another major source of issues is the lack of meaningful response to identified, analyzed risks.

An article from the October 2017 issue of PM Journal reminded me that HOW we communicate risk information is as important as WHAT we communicate.

I’m sure many of you recognize the futility in only sharing risk information via risk registers. While those are a valid place to consolidate risk information for project management purposes, it is unlikely that most stakeholders will know where to locate a risk register for a project, let alone review it periodically. A better approach would be to use existing information radiators, reports or meetings to secure ownership of actions and responses for key risks.

But how do we present the information itself?

Extracting key fields from the risk register into a management-ready table is one way to do this. You might also be creating some colorful heat maps to provide stakeholders with a higher level view of overall risk probability and impacts.

But what about the relationships between risks?

You might have communicated some information regarding the secondary risks generated by responding to other risks, but what about the relationships between the risks in your register?

Creating a visual representation of the relationship between risks can help us focus further analysis and response efforts on those risks where we will get the greatest overall project benefits. An interrelationship digraph which was one of the quality management tools covered in the Fifth Edition of the PMBOK Guide and excised from the Sixth Edition provides one way to do this. Such a view might also help key stakeholders to connect the dots for themselves. They can visualize how their response to a specific risk might help to prevent impacts resulting from the realization of other risks triggered by the first one.

Our project risk management practices are only effective if there is a tangible difference in outcomes compared with our doing nothing. 

Categories: Project Management | Tags: , , | 2 Comments

O Pareto, Pareto! Whereforth art thou Pareto?

I recognize that unless the scope of a project includes process or product redesign most teams are unlikely to have the need to use Pareto charts, but what concerns me is that the underlying Pareto principle is applicable on a broader basis.

Had the Pareto principle been defined early in the Guide, it could have been referenced subsequently in a number of key processes including Qualitative Risk Analysis, Direct and Manage Project Work, Manage Quality and Plan Stakeholder Engagement. With all of these processes, a project team needs to identify the “vital few” elements where they should spend valuable time while keeping the “trivial many” on watch lists for occasional monitoring.

The Pareto principle can also apply to Manage Project Knowledge, which is one of the new processes added within the Integration Management chapter in the Sixth Edition. When coming up with lessons which might be applicable to current or future projects, after the team has used techniques such as brainstorming to identify a large set of candidate ideas, the Pareto principle can be used to filter those down to a handful by considering which will deliver the greatest productivity or quality improvement.

The Pareto principle also applies when we are tailoring our approach to the needs of a given project. Project management methodologies and standards are usually very comprehensive but a competent project manager needs to be able to apply good judgment in deciding exactly which practices, tools and techniques will deliver the greatest benefit.

Finally, if we acknowledge that “It depends” is the safest answer to most project management questions, then the Pareto principle is a valuable tool to help narrow our focus to where our efforts might be best spent.


Categories: Project Management | Tags: , , , | 1 Comment

In defense of Critical Chain

One of the more subtle changes in the Sixth Edition of the PMBOK Guide is the elimination of all references to Critical Chain Method (CCM).

The rationale for this excision was not provided in Appendix X1 of the Guide which provides details of most of the Sixth Edition changes so I can only speculate that this might have resulted from the desire of the volunteer standards committee to cover commonly used tools and techniques for schedule development, and with the addition of agile release planning perhaps CCM became an easy sacrificial lamb.

Many years ago, I worked in an organization where I attempted to introduce CCM as an approach to managing key resource availability challenges as well as shifting leadership focus from individual tasks to milestones.

Unfortunately, this failed miserably.

A fundamental tenet of the methodology is using optimistic activity durations by stripping out padding and by aggregating uncertainty into buffers at the end of activity sequences. I was unable to convince team members to provide such aggressive estimates given the organization’s prevailing culture. Given that a fair bit of padding remained in each activity duration estimate, the buffers ended up being bloated and milestone dates were later than would have been previously planned.

However, some of the key lessons remained with me which I was able to apply later.

  1. Eliminate multitasking of high demand, low supply resources. It’s really tempting to squeeze out every iota of working time from such team members, but the opportunity cost of context switching is much greater than for other team members. So while I encourage the elimination of multitasking for all core team members, if that is unrealistic, at least do it for your “drum” resources.
  2. Centralize uncertainty into contingency reserves and defend those reserves. Calling these buffers does not resonate well with senior management as the perception is that these will be consumed carelessly. Position them as contingency reserves and they can start to appreciate the necessity of having some shock absorbers to protect the timelines from known-unknowns.
  3. Obsess over milestones and not individual tasks. Estimates are probability distributions – some activities are bound to be late and some will be early. A good project manager keeps their eye on the key milestones and while they are aware of the give and take which results from variation in activity end dates, they won’t micro-manage the team to those. This not only reduces perceptions of micromanagement while empowering individual team members, but it also keeps everyone’s eye on hitting the milestone date. Scrum incorporates this principle by focusing team efforts on sprint goals and commitments and not just on individual tasks.

Use of CCM requires a level of scheduling discipline which is absent on many projects and it does lend itself well to deterministic or predictive projects. But just because you can’t use the method as a whole doesn’t mean it doesn’t contain some good practices which could be applied to your project.


Categories: Project Management | Tags: , , , , | 6 Comments

Blog at

%d bloggers like this: