Why Projects Succeed – Proactive Risk Management
By Roger Kastner
This article is part of a series, the previous article can be found here.
The art and science of Risk Management is so important to the success of a project that I’m going to take the next three articles to talk about it.
Most of what’s written about Risk Management is clearly based in the science of Project Management: how to calculate risk factors, the four types of risk responses, the thresholds for Risk severity, and so on. These are all important, no doubt. However, I want to spend some time focusing on the social skills required for proactive Risk Management and how the art of Risk Management contributes to a successful project.
All projects will be knocked sideways at some point. Guaranteed. It is an immutable law of Project Management, like the need to balance a project’s Triple Constraints (scope, schedule, and budget), and that Project Managers will sometimes resemble the pointy-haired boss in Dilbert. Saying “all projects will go sideways” is as a sure thing as a “chance of rain” forecast is in Seattle.
I’ve come to the conclusion that all projects will go sideways not because of a general lack of proficiency or lazy Risk Management practices by Project Managers, or bad Project Management in general. Actually, it’s just the opposite. It’s been my experience that the more senior and more talented the Project Manager, the more likely that Project Manager will be assigned to a project with higher risk and complexity that is even more likely to go sideways. If you don’t buy that, we should talk with our Project Management friends on the 787 project at Boeing or on the Space Shuttle program at NASA.
Project Managers at Boeing and NASA are extremely talented and experienced, yet those projects have had their share of very public challenges and failures. And it’s definitely not due to a lack of professional Risk Management. It’s because they are more difficult projects. And there is always precedence for this, such as Murphy’s Law.
No, I say that every project will be knocked sideways at some point because I haven’t met a Project Manager or been on a project that didn’t experience that rogue wave or “Houston, we have a problem” moment. In my experience, the goal of Risk Management is to identify and plan for all the items that may knock the project sideways specifically so you have the personal bandwidth to deal with those unforeseen elements that are going to knock you sideways despite your preparations. So, what should a successful Project Manager do to ensure that they can minimize the impacts of risks becoming actual issues?
If the title was not foreshadowing enough, the successful Project Management will perform proactive risk management so he or she has a plan to deal with all the “known unknown” items specifically so that when an “unknown unknown” event does occur, that Project Manager has the personal bandwidth to detect the trigger event, and marshal the troops to triage the issue and quickly respond appropriately.
“Can I have Proactive Risk Management for $400, Alex?”
Proactive Risk Management
By Proactive Risk Management I don’t mean only identifying a few risks and building a mitigation plan for some. I mean something more powerful, valuable, and yes, more time-consuming. It’s a combination of attitude and approach:
- Attitude: The successful Project Manager takes this very seriously in order to protect their personal bandwidth for when the big one hits;
Approach: The successful Project Manager has set up the Risk Management process appropriately to ensure they can protect their personal bandwidth.
It’s project insurance: the project is paying upfront to safeguard for the ability to identify and address the big issue, resulting in protecting value throughout the project.
What do you need to start your Proactive Risk Management effort with? The successful Project Manager will start with a plan, some time, and some dollars.
Risk Management Plan
The first thing a successful Project Manager needs is a Risk Management Plan. This plan outlines how risks will be managed throughout the life of a project. The Risk Management Plan should include:
- The basics of the Process, how risks will be identified and assessed,
- How risks will be monitored and communicated, and
- How time and cost contingencies will be calculated and included in the project schedule and budget.
The Plan will need to be signed off by the project sponsor, the project leads, and possibly the project Steering Committee, if applicable. This signifies that the successful Project Manager has the support of the primary stakeholders to manage those risks and prepare for the unknown.
Pretty straightforward, right? Exactly right, and doing so will helps set expectations with the stakeholders. What’s not straightforward, and is a crucial part of the plan, is how you are going to handle the Contingency Reserve.
Since Contingency can sometimes be misunderstood, I want to take a moment to level set what I mean by Contingency. Contingency is not “buffer” or “fluff” added to the budget or schedule based on something the Project Manager read on a bumper sticker (i.e., “Stuff Happens.”). And Contingency is not meant to be spent on Change Controls. A Change Control is a “change” to one or more approved baselines (i.e., scope, schedule, or budget). Spending Contingency dollars on a change means the Project Manager is decreasing their ability to minimize the impact when a risk is realized.
Calling it “buffer” connotes a lack of sophistication and hints of “guess-timation.” And like blood in the water for a shark, some stakeholders will chew up that line item in the budget because they don’t like guessing, the lack of precision, or lack of discipline when it comes to how their project dollars are being spent.
Contingency is a schedule and budget pool meant to be spent on reducing the impact to project baselines when a risk is realized. The Contingency for budget is commonly referred to as a Contingency Reserve. The contingency for time is referred to as Schedule Contingency.
Depending on the level of maturity of one’s organization, the practice of maintaining a Contingency Reserve as part of the project will vary. The existence of a Contingency Reserve is basically adhering to that immutable Project Management law acknowledging that things will go sideways on the project, and if you don’t have a reserve of dollars set aside, not only do you have immediate impacts to scope and schedule, but you’ve hit the trifecta and your budget baseline is immediately impacted.
A successful Project Manager will calculate the Contingency Reserve by analyzing all identified risks, and then determining the probability of the risk being realized and impact (measured in dollars) of the realized risk. Then multiplying the probability and impact will give you a Risk Factor for each individual risk, and the sum of all Risk Factors should be used to inform the size of the Contingency Reserve. Notice, I said “inform the size of the Contingency Reserve,” not “calculate the size of the Reserve.” This is where the successful Project Manager will use their experience and best judgment to recommend how much to set aside for the Contingency Reserve.
Just as a Contingency Reserve helps minimize the cost impact to unanticipated issues, the same approach should be used in creating the Schedule Contingency, measured in days, to ensure that stakeholder expectations for the project schedule includes accommodations for being knocked sideways and recovering. Instead of calculating the Risk Factor by multiplying probability and impact in dollars, now calculate the impact in days. The sum of the Risk Factors should now be used to inform the size of the Schedule Contingency.
Two words of caution for Schedule Contingency: Parkinson’s Law. Parkinson’s Law states that the work will grow and shrink based on the time that is given. I refer to the same principle as the college term paper syndrome. Sure the instructor assigns the term paper on the first day of class, however, usually no work on the assignment really begins until the week before it’s due and then something occurs that we in the business call an “all-nighter.” Maybe some of you are still familiar with that practice.
By adding the Schedule Contingency into the middle of your project schedule, you may get the same results my instructors did with my college term papers, or suffer from Parkinson’s Law and see the team’s work slips until the last minute, losing the original intent of the Schedule Contingency. My advice: put the Schedule Contingency at the end of your schedule between “sponsor go-live signoff” and “go-live.” Call that time “cookies cooling on the rack” days, as in “they smell good and look good, but too hot to eat just yet.”
Contingency Reserve and Schedule Contingency are major pieces of Proactive Risk Management because they enable the successful Project Manager to focus on the issue while minimizing the impact of the issue, literally buying the project time to recover. In doing so, the successful Project Manager is better able to set and manage stakeholder expectations from the beginning of the project with the very first discussion about Contingency: “Read my lips: bad stuff will happen. Here’s how we are going to deal with it.”
And the successful Project Manager will never refer to Contingency as “buffer” or “fluff,” because that would just be silly.
Does This Work?
I was working on a project in a group recently where each project manager had a different understanding of what Contingency was meant to be used for and how it was calculated. Some projects used Contingency for Change Requests, which is actually another budgetary reserve called a “Management Reserve,” whereas other projects used it for bad estimates (i.e., change controls). The organization had a standard definition for Contingency, unfortunately, it was clear as mud and was subject to interpretation.
I worked with my Project Manager colleagues to agree to a single definition and protocol, then we worked with our sponsors to socialize and gain agreement on the process. We set the minimum threshold of Contingency at 10% of schedule and budget, but Project Managers had the ability to submit estimates for schedule and budget as long as the risk calculations were validated and signed-off by the sponsors. The new process helped establish greater transparency and predictability, which in turn lead to greater credibility for the Project Managers. This new definition and process was shared with the larger organization and has now become a standard practice for the company.
Ultimately, each organization needs to a) agree on the definition of Contingency, b) determine how to calculate Contingency, and then c) determine when to release Contingency dollars and days back to the portfolio as risk trigger events pass, or decide how to spend unused reserves. As with my recent experience, defining Contingency for schedule and budget will provide greater transparency, predictability, and credibility, which seem like three pretty good objectives for Project Managers in everything they do.
Proactive Risk Management is a key process that leads to successful projects. Because all projects will be challenged at some point, Proactive Risk Management will enable the successful Project Manager to safeguard their bandwidth to deal with the big, unforeseen issues that knock the project sideways. Contingency is a major piece of Proactive Risk Management because it enables the successful Project Manager to minimize the impact when the project goes sideways and literally buys the project time to recover.
Next time, we’ll discuss where the Risk Management rubber meets the road: the Identification of Risks. I’ve got a process that doubles not only as a risk identifier, but also for gaining team consensus on whether a project is feasible.
After that, we’ll discuss Risk Assessment. Since not all risks are created equally, they should not be treated as such. Two legs good, four legs bad, that kind of stuff. Unfortunately, there are projects where all risks are identified at DEFCON 1. That’s unreasonable and a waste of time, energy, and money, and the successful Project Manager won’t let that happen.
I’m excited about the next articles that delve deeper into specific steps in the process and I hope you’ll join me next time.
Reprinted with permission from Slalom Consulting – © 2011 Slalom Consulting
Roger Kastner is a Business Architect with Slalom Consulting who is passionate about raising the caliber of project leadership within organizations to maximize the value of projects. You can read more articles from the series on “Why Projects Succeed” here.