Six Constraints: An Enhanced Model for Project Control – Risk

Six Constraints: An Enhanced Model for Project Control – Risk (#6 in the series Six Constraints: An Enhanced Model for Project Control)
By Jay Siegelaub – MBA, PMP, PRINCE2

PRINCE2™ employs “tolerances” – its term for these six constraints – as key project controls. They are dimensions of the project for which ranges of acceptability are defined, which are monitored to identify or anticipate when a plan has entered “problematic” or “exception” territory. They are needed and used at all three planning levels of a project – the project as a whole, any one stage or phase of the project, and at the detail work package level.

The Six Constraints are:

• Time
• Cost
• Scope
• Quality
• Benefits
• Risk

This article discusses Benefits.

The last two elements of the six-constraint model are the newest and least-familiar ones, and could be considered controversial – except that they are both already present in projects. We are not creating them – we are just bringing them to the forefront and demonstrating how they interact with the “classic” constraints (time, cost, scope, and quality). When these two new constraints – benefits and risk – are not considered, they are likely to be neglected and produce a negative impact on the project and the organization. In this article we will focus on risk.

Everyone recognizes the Risk on a project needs to be addressed and managed. We can see that in any project there may be a level of risk that we are simply not willing to live with, or “tolerate.” That is our risk tolerance. Its simplest and most common expression is in examining the probability of significant risks occurring, their potential impact on the project if they do occur, and our degree of willingness to live with those potential consequences. Risk refers to “opportunities” as well as “threats,” and can be applied in a similar manner.

“Risk Tolerance” of stakeholders is presented as an important consideration in the PMBOK® Guide’s Management of Risk knowledge area, but how one establishes “risk tolerance” is not defined. Here you will see a clear, functional definition. These concepts can be brought back to the PMBOK® Guide and applied there as well.

The basic Risk model looks like this: (See figure 1.)

Each of the numbers represents an identified (and documented) significant project risk. We would be particularly concerned about threats that fall in the upper right-hand corner: medium-to-high likelihood of occurrence and medium-to-high (negative) impact of the project if they do. The more serious the threat the greater effort we make to mitigate that risk. The “risk tolerance line” – here indicated as the thick line – represents the limit as to the level of risk the project owners are willing to “live with” (or “tolerate”) for that project.

Here is an example. Our project is developing a new product for our domestic market. We have identified several significant risks, which have been mapped into our model (figure 1). Risks #1 and 2 represent risks that are under control, and are not significant enough to stop the project. We will look at risks 3 and 4.

First Scenario:

Risk #4 is a Supplier risk. We have a great supplier, but they are having financial problems. The probability that they will have trouble delivering looks high right now; the impact would be that we couldn’t deliver our product. As of now we haven’t come up with any satisfactory mitigating responses that would protect us. The risk tolerance of the project owners could be: “We can’t live with Risk #4 as it stands. If there are no options to deal with it, it’s better to stop the project right now before we commit too many resources.” This particular risk is on the wrong side of their “risk tolerance” limit (which they had established). They could also say: “Let us look for additional ways to mitigate it – like an alternative supplier. If we can have a reliable contingency plan, the probability would still be high, but we would reduce the impact (to the “probability high, impact low” box), so the overall rating would fall below our risk tolerance line.” (See the new location of risk #4 in figure 2.) The project risks are now within their constraint/ tolerance limit.

Second Scenario:

Risk #3 is the risk that our market-dominant competitor might come out with a similar item. At this point that looks very unlikely (from what we know), but the impact on our project would be high if it did occur. (See risk #3 in figure 1.)
Risk #3 is acceptable right now, since the probability is low, and it falls below the project owners’ risk tolerance line. If, during the project, we hear more reliable rumors that it is becoming increasing probable that our competitor will come out with their product, then risk #3 would move to “probability high” with the same level of impact. (See the movement of risk #3 in figure 2.) That would put the risk above the risk tolerance limit – ie, “we cannot live with that level of risk – we have to re-consider our situation.”
There could be three choices for the project owners at this point, with risk #3:

1. find a mitigating response that will reduce probability and/or impact to an acceptable level;
2. close the project down, since the project owners are unwilling to live with projects that have any risks above their agreed-upon risk tolerance line;
3. move the risk tolerance line to some point above the new risk level. (See the new solid line representing the revised risk tolerance in figure 3.) They can move risk tolerance just as cost or time limits might be re-set or adjusted. “We decided reluctantly that we have to go ahead and live with a higher level of risk, because this project is critical to our survival.”

Jay Siegelaub has over 30 years of professional experience delivering and supporting projects in information technology, insurance systems, banking, and nonprofit strategic planning, as well as in the pharmaceutical, financial service, consulting, and consumer products industries. As a recognized educator he has trained thousands of project managers over the past 23 years, including 13 years as the Project Management tutorial instructor for the Drug Information Association.

Jay’s recent responsibilities included leading the North American Change Management and Training practices for a UK-based management consulting firm, training corporate consulting professionals in project and program management, and supporting clients in managing the “people” issues of their business change initiatives. He has authored articles on training, project management and information technology for various publications, and often presents at conferences, including the PMI North American Congress (1999, and 2004 – 2007), ProjectWorld and ProjectSummit.

In addition to his PMP® certification, Jay has his MBA in Organization Management from New York University’s Stern School of Business, and is an accredited PRINCE2™ Practitioner, Instructor and Examiner. He has taught and consulted in PRINCE2™ in North America for 10 years (the first US-accredited PRINCE2™ instructor), and worked for the company (and with the authors) that wrote the PRINCE2™ Manual for the UK government.

He has provided Change Management and Project Management consulting and training (including PRINCE2) to companies such as Sun Microsystems, NATO, the United Nations Development Programme, Bechtel, IBM, Philip Morris, Credit Suisse, JPMorganChase and Diageo.

Jay also consults in Organizational and Professional Development.