How to Mitigate Risk at the Project Portfolio Level

Daniel Doiron

Daniel Doiron

Guest Author

Table of Contents:

When managing a large portfolio of projects, sometimes, you might need to allocate people and resources in order to mitigate risk, act on relative criticalities and optimize your capacity to its fullest extent.

I remember a story my friend and colleague Steve Tendon once told me. When he started working with a client, there was a portfolio committee meeting every two weeks, managing 6-7 streams of 40-50 projects. The meetings lasted anything between 4 to 6 hours.

When having to optimize capacity according to the risk of failing to finish a project on time, it was all HIPPO (highest paid person in the room) decision-making, despite the 300 slides, where each project/product manager was making their case and begging for people and resources.

In addition to all the time wasted by mid and senior-level managers attending the meeting, consider all the other damage that such decisions caused. Leaders went back to their teams disappointed to inform them that no reinforcements are available, but the projects at risk are still expected to finish on time.

This resulted in additional stress and an increased risk of overburdening the team. Nonetheless, such decisions affected employee morale, which is critical for succeeding in the face of unfavorable odds.

If this sounds familiar and you would like to see an alternative, the rest of this article can prove to be the remedy for a very common management pain: taming coordination costs. In their nature, coordination costs are invisible and tend to behave in an exponential manner.

Manage Risk with Buffers

Few people know that it is possible to use CCPM's buffers for explicit risk management in Kanban. Just to be on the same page, by CCPM I mean critical chain project management. If this is your first time hearing about it, CCPM is a project management methodology introduced by Eliyahu M. Goldratt about two decades ago. It applies the Theory of Constraints (TOC) to resolve project task and delivery issues. In CCPM buffers are used for determining realistic project deadlines. There are 3 types of buffers:

  • Project buffer: A unique and single buffer to protect the project deadline
  • Feeding buffer: Multiple buffers to protect parts of the critical chain
  • Resource buffer: Multiple artificial buffers that act as warning signals to assure the availability of resources

With their help, you can mitigate risk according to a project's critical path, which is basically the inevitable path required to complete all tasks comprising it. In order to elevate the critical path as a constraint, you can use the MMR buffer from Steve Tendon's Tameflow Kanban.

Afterward, using a CCPM buffer as a leading indicator of risk materialization, you can differentiate between common cause and special cause variation and act way before a cumulative flow diagram (CFD) would lead you to take action.

Create the Aggregated MMR/MVP Buffer

At this point, we should understand that MMR – Minimum Marketable Release and MVP – Minimum Viable Product are synonymous. Each MMR is, in fact, a target-scope project that can be part of a portfolio as illustrated below!

The MMR buffer can be considered by all means analogous to the Critical Chain Project Management’s Project Buffer. It is not a kind of padding that we add just in case something goes wrong. Although it is often presented like this and can even be misused with that intention in mind, the MMR buffer is in line with Goldratt’s CCPM buffer: an operational monitoring tool that gives significant leading signals of oncoming risk materialization.

Hence the MMR buffer is not there to reduce variability, it is instead used to detect unfavorable variability early enough.

MMR Buffer from Timeflow Kanban The Tameflow-Kanban MMR buffer takes into account the average flow time for each class of service. The simple procedure is to divide the expected flow time of each MMR by 50%. The buffer can now be split in 3 ways (Expected, Normal and Abnormal Variation) to manage explicit risk as follows: Mitigating risk with MRR Buffers MMR buffers can be helpful in 3 ways: 1) as a Fever Chart for managing a project 2) to affix to a CFD and 3) to be transformed in a Bubble Chart 1)The basic representation of an MMR buffer is in its Fever Chart format. It shows the buffer consumption (as a percentage) towards MMR completion (also as a percentage). MMR buffer consumption 2)The nice thing about the "˜consumption' of the MMR buffer is that it is on the same scale as that of a CFD. For that purpose, the Fever Chart can be transformed into a Buffer Control Chart. Imagine putting it below a CFD and see how fast you can act on risk materialization! You have gained 6 units of time ahead of what the CFD would have told you! Buffer CFD visualization

Credit: Steve Tendon

3) We can now have a transformation to an MMR Bubble Chart by incorporating projects. If you look at the GIF below, you will see that labor liquidity decisions are leveraged: No one should ping a resource from project B, which is red! Bubble chart - MMR buffer

Looking at the graph from week 5 to 9, you see the dynamics. You see the trends.

To conclude, it is only fair to give you the rest of the story about the long meetings that you have read at the beginning of this article. The company that was wasting between 4 and 6 hours every couple of weeks to decide how to optimize capacity started using buffers to mitigate risk.

As a result, those meetings were reduced to 15 minutes. Thanks to the bubble chart, the management team was now able to set priorities right in relation to the most critical project.

Tags

Experts Speak

Project Management

Daniel Doiron

Daniel Doiron

Guest Author

Daniel has been involved in IT since 1981 in a wide range of roles and responsibilities primarily in client-facing consulting projects. Daniel's involvement with Agile started with Scrum in 2005 and, more recently with Kanban and Management 3.0. Daniel is heavily involved with Steve Tendon's Tameflow method. Read more articles by Daniel at http://agileagonist.com/