Email this Article Email   

CHIPS Articles: Increase Your Rewards: Guidelines for Project Risk Management Part III

Increase Your Rewards: Guidelines for Project Risk Management Part III
By Pen Stout, PMP - October-December 2003
IT project managers could learn a lot from 17th century European merchants — both have experience with uncertain, dangerous ventures that promise great rewards. Over 350 years ago the merchants, with some help from a monastery of nuns outside Paris, founded the modern theories of risk management. Their revelation: "Fear of harm ought to be proportional not merely to the gravity of the harm, but also to the probability of the event." 1

To the merchants this meant they could calculate when their fleets would reach port and what returns they could expect. This allowed the merchants to maximize their odds over the long run to make dependable profits. As a result they could fund increasingly risky — but potentially profitable enterprises. This in part contributed to the growth of modern Western economies.

In the 21st century, IT risk management could translate to: backing up critical data, a secure power supply, documenting procedures and delegating authority when absent from the office. In short, we take precautions to secure our essential systems against the unexpected. In this the third article in our series on IT project management we will explore a practical approach to risk management using a common IT experience for an example: the design and implementation of an IT help desk.

A Practical Risk Management Process

Though risk management can involve complex statistics, the heart of the process is common sense: 1) Identify potential threats to the project cost, time and quality goals; 2) Assess each threat as the Parisian nuns suggested: determine both the gravity of the event and its probability of occurrence; 3) Create a proportionally justified plan of action for each threat. In other words, if there is a 1/10 chance of a $1,000 loss you might spend as much as $100 to eliminate the possibility of the threat; 4) Respond to actual problems as they occur. Rigorous risk planning will not make all the problems go away, but you will have fewer and you will be better prepared to handle them. Now let's use our IT help desk project to illustrate this process.

Step One: Identify Threats

It makes sense that once we know about a potential problem we can plan for it, but how can we know what problems we will encounter? Andrew, our IT help desk project manager, uses a common approach: he assembles a cross-functional group of project stakeholders and asks them point-blank, "What threats do you see to our cost, schedule and quality goals?" In other words — they brainstorm. Andrew practices two important principles of risk identification:

• Involve a diverse group of stakeholders because both their perspectives and their tolerance for risk will differ.
• Encourage them to be pessimistic about the project and to generate as many potential problems as possible.

Other tips for risk identification are: 1) Use a common format for describing risks that distinguishes the event from the impact. Here's a good format: Event causing impact. Andrew followed the format in this risk statement: "Database server infected with virus causing staff to field help calls without access to customer data"; 2) Brainstorm first — use open-ended, concept-expanding, "blinders-off" techniques to encourage divergent thinking and catch the risks that are not obvious; 3) Check results with more convergent methods. Once the open-ended brainstorming is complete, it is good practice to check results against lists of historical risks, particularly those that apply to your specific industry, organization and program.

Some project managers find it helpful to create profiles of typical risks they are likely to encounter on different types of projects. Cast a very wide net during this initial stage. The problems that hurt the most are often the ones we didn’t identify early due to ignorance, denial, myopic vision or lack of discipline. At the end of this step you will have a long list of possible problems. Now it’s time to separate the wheat from the chaff. Go through the list setting aside the low-probability, low-impact threats. Place these in a tickler file. Things change on projects so you will want to review these threats in the future to confirm they remain low-probability and low-impact.

Step Two: Assess Each Threat

After setting aside the smaller threats you will still have a large number to manage, but you won’t have the time and effort available to monitor all of them. How will you decide where to spend your limited time and money? Andrew sorts the remaining threats into categories matching his functional teams: hardware, software, test, human resources, etc.

Gathering the leads of each team together he asks them to analyze each threat in their respective subject areas. “I’d like you to assign a dollar impact to each threat and an estimated probability of it actually occurring,” he tells his leads. “If we have experienced similar problems in the past, use our experience to improve your analysis.” To encourage accuracy, but discourage them from getting caught up in analysis, he continues, “It will be very helpful if you can put actual numbers into the impact and probability estimates if the numbers can be supported and it doesn’t cost too much to figure them out. But don’t ignore the threats that would be too hard or costly to quantify. I’d like you to give them a subjective or qualitative estimate based on the Stout-Weidner Matrix.”

Andrew has his leads collect the information required to calculate the “Expected Value.” Expected Value is the product of the impact multiplied by the probability of occurrence. Here is an example: Kim identified one risk this way, “If we have too many employees ill at one time, it causes poor response times for our users because we simply can’t answer the telephones fast enough. Sometimes costing us.”

Andrew agrees that this is a project threat and asks Kim to calculate an Expected Value. Kim reports, “I’ve discovered that we lose about $1,000 a day in long-term customer business due to hang-ups whenever we don’t have the right staffing levels answering the phones. This usually occurs due to a combination of poor scheduling and illness. It has occurred, on average, about 10 percent of the time.” Andrew says, “We can multiply the daily impact ($1,000) by the probability (10 percent) and calculate an Expected Value of $100 per day. The help desk will be open 365 days a year so our annual Expected Value for this threat is $100*365 or $36,500 a year. That is a significant risk we better manage effectively.”

Andrew will use the Expected Value of each threat to focus his limited risk management resources where they will do the most good. Andrew also recognized that the analysis of impact and probability can best be performed by the subject matter experts so he delegated these tasks to his leads. This will help the team speed through the analysis step. Andrew followed these risk management techniques: 1) Categorize the threats and delegate assessment to subject matter experts; 2) Assess cost of impact and probability of occurrence; 3) Base analysis on past history when possible; 4) Develop quantitative numbers where it is cost effective.

Additional tips for the assessment step include: 1) Accurate estimating takes time and good data; 2) Balance the need for accuracy with the cost of collecting information; 3) Estimating is better than ignoring a true threat; 4) Different stakeholders have different tolerance levels for risk. Take this into account when determining which risks to actively manage and where to draw the line. Keep in mind that active risk management requires time, effort and resources. These are usually limited so you must select which threats to manage. The size of the Expected Value is very useful for prioritizing and filtering.

Step Three: Response Planning

At this point Andrew’s sponsor asks to see the list of threats. She looks it over with a frown. “Andrew, this is still a very long list. I really don’t know if this project is a good idea if so much can go wrong. What do you suggest I recommend to the Chief Financial Officer?” Andrew responds, “We are just getting to the big payoff in good risk management. The next step is to plan how the project team can reduce the surprises and control the uncertainty. Can you give me until next week to pull together a complete recommendation?”

His sponsor agrees, but advises that the CFO will want to know if the project still makes good business sense. “Numbers and dollars will persuade me to take this further. And I need them by COB [Close of Business] Wednesday,” she says.

When team members gather in the project room they find a list on the whiteboard: “Avoid, Transfer, Mitigate, Fallback Plan and Monitor, Accept and Reserves.” Andrew opens the meeting, “We need to plan how we can reduce our current risk exposure. This is a list of ways (Figure 1) regarding how we might respond to each threat. I’d like each of you to look at your risks, starting with those having the highest Expected Value, and determine which response makes the most sense. I will want to know: 1) What actions you propose? 2) How much they will cost to implement? 3) How much it will reduce the total Expected Value of your threats list? Once you are done we will get back together to decide which actions we can afford as a team and what to do about the remaining risk exposure.”

Response planning process

-- Determine the best response for each managed risk. For each approach consider the initial Expected Value of the threat, the cost of the response and the predicted reduction in Expected Value. Select the most cost-effective response. For example: Kim proposes to reduce the probability of poor phone response due to poor scheduling by hiring a consultant to teach the team how to use the software already on their computers. Training costs about $6,000, but it reduces (mitigates) the Expected Value of this threat from $36,500 to $24,000 due to improved planning and coordination. She is also investigating wellness programs that might reduce staff sick days and the resulting poor response rates.

-- Add all resulting actions to the project’s WBS (Work Breakdown Schedule), budget and schedule to assure they are managed like any other project task. v Review the total residual Expected Value. Determine a contingency reserve sufficient to cover this remaining risk exposure. Negotiate it with your sponsor.

Additional Tips: 1) Reserves should be held separate from the allocated performance budget. They are released as work packages only when a threat becomes an actual problem and requires corrective action; 2) Reserves usually cover financial impacts. Some scheduling approaches, such as Critical Chain Project Management, also attempt to provide extra time to cover the uncertainty in estimating task durations and project schedules. This time reserve is often called a buffer. In some organizations it is standard practice to sandbag or artificially inflate estimates and quotes to assure sufficient resources are available to cover the unexpected. Unfortunately such fudge usually gets eaten as work expands to fill the time or budget available. This is a poor management practice.

At the next meeting the team reviewed everyone’s proposed threat responses. In a couple of cases, two responses to different threats conflicted with each other so the team worked out mutually supporting responses. The required actions were added to the baseline project plan. The next day Andrew brought his risk plan (Figure 2) to a meeting with his sponsor. She was pleased to see that the team had developed a proactive approach for many of the project threats and agreed to help negotiate a project contingency reserve with the CFO. “He’ll be very happy to see that you have identified and taken positive action to reduce the possible surprises in this project. He doesn’t like project surprises because they reduce his ability to deliver on his promises to the CEO and Board of Directors. I’m sure he will agree to a good reserve if we can assure him it will not be eroded by poor performance. Oh, and have Kim give me a call. I think we can help with the financial justification for that wellness program if it really works.”

Step Four: Continuous Risk Management

One of Andrew’s team members remarks, “That risk management exercise was interesting, but now it’s good that our focus is back on the real tasks of getting this help desk up and running.” Andrew responds, “I’m glad you are concentrating on the project tasks, but I want to point out that the risk process doesn’t go away just because we have performed an initial risk exercise. We will need to stay current with the risk effort just in case things change.”

Andrew knows that all risks have not been identified or eliminated. He will follow these principles during the rest of this project:

• Make risk identification a regular part of project team activities.
• Ask for new risks at every project status meeting.
• Update the status of risks. If the probability or impact changes, maybe the response needs to change. If a response works and the risk event passes with no problem, note the success and retire the risk from the log.
• At key project points, such as when a phase ends or at significant changes in scope or personnel, perform another formal risk assessment.

Some Cultural Challenges

Some managers appear to be practicing denial as a form of risk management when they demand a “can do” attitude and accuse those focusing on threats of being pessimistic whiners. They may not understand that risk management is a well-formed, proactive process that delivers value by focusing limited resources on the reduction of surprise. When this is the case the politically savvy project manager will engage in tactful education emphasizing the benefits of improved control.

Implementation of the process will require discipline at several levels including the team and executive levels. The team must realize that risk requires constant attention coupled with routine effort to limit exposure. Executives will have to gauge the long-term benefits of active risk management and balance it against the short-term need to fund risk management activities.

Project leaders managing enterprises, like aircraft carriers and nuclear power plants, which require very high reliability, have learned that uncertainty is the enemy of reliability. They successfully battle it by creating a culture of mindfulness at all levels. They use both formal and informal methods to constantly scan for potential problems while fully empowering an active threat response by all team members. Move your project team into this culture and deliver better performance with fewer surprises to your sponsor and customers.

Summary

Risk management is a systematic process that reduces the potential for unexpected project outcomes and improves the project manager’s ability to meet or exceed the expectations of key stakeholders. It adds value to the project effort by increasing the probability that sponsors and customers will receive what they expect, when they expect it, for a price they expect to pay. Stripped to its essence, risk management is a set of methods for answering a few, common sense questions: What could go wrong? How wrong could it get and what can we do about it?

The ideas are simple. Like most things, the payoff is not in the knowing, but in the routine doing. Discipline and practical, routine application are key. Once you and your teams internalize the process and use it on a day-to-day basis you will find a sustainable improvement in project performance and stakeholder satisfaction. These simple ideas really work wonders because they get the odds working for you — rather than against you — and that’s a truly sweet spot to be in.

References
1. Hacking, Ian. The Emergence of Probability: A Philosophical Study of Early Ideas about Probability, Induction, and Statistical Inference. Cambridge University Press, 1975. Chap. 8, p. 77. Hacking describes the activity of nuns working in association with Blaise Pascal at the Port-Royal monastery in 1662.
2. Derived from Eric Verzuh, Dr. Harold Kerzner and DoD.
3. These are considered acceptable variances in stable, mature, competitive industries with high selective pressure for accurate estimation. An overrun of 10 percent for a new publicly-funded stadium would be considered terrible, an aerospace firm may or may not consider a 10 percent overrun a problem depending on the type of program, while a software product developer would consider a 10 percent overrun to be the best performance he has ever seen.

Sources:
A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Project Management Institute, 2000. Risk Management Guide for DoD Acquisition. Defense Systems Management College Press, 2000. Kerzner, Harold.
Project Management/Project Management Workbook. Van Nostrand Reinhold, 1995.
Leach, Lawrence P. Critical Chain Project Management. Artech House, 2000.
Verzuh, Eric. The Portable MBA in Project Management. John Wiley & Sons, 2003. Chap. 6.
Weick, Karl and Sutcliffe, Kathleen. Managing the Unexpected. Jossey Bass Wiley, 2001.

Pen Stout is a project management consultant and trainer. He coaches firms as they implement project management and he conducts project leader training for the Versatile Company.

Figure 1. Andrew’s handout for response planning
Figure 1. Andrew’s handout for response planning

A matrix showing impact vs. probablility.
Stout-Weidner Probability Impact Matrix.

A level 5, the likelihood is near certainty and the probability is greater than 90 percent.  A level 4, the likelihood is highligh likely and the probability is 60-90 percent.  A level 3, the likelihood is likely and the probability is 40-60 percent.  A level 2, the likelihood is unlikely and the probability is 10-40 percent.  A level 1, the likelihood is remote and the probability is less than 10 percent.
Stout-Weidner Probability Impact Matrix--Part 2

If a project is a level 5 on this chart, the technical/scope is unacceptable, a major milestone can't be achieved, the cost is greater than 10 percent and the impact is unacceptable.  If the project is a level 4, the technical/scope is acceptable-no remaining margin, there is a slip in critical path or major milestone, cost is 7 to 10 percent and there is a major impact.  If the project is a level 3, the technical/scope is acceptable-significant reduction in margin, deadlines are not met, cost is 5 to 17 percent and there is a moderate impact.  If the project is a level 2, the technical/scope is acceptable-minor reduction in margin, dates can be met if additional resources are available, cost is less than 5 percent and there is some impact.   A level 1 shows little to no impact.
Stout-Weidner Probability Impact Matrix-Part 3

Figure 2 shows Andrew's risk management breakdown partially.  It lists future events, like poor phone response due to scheduling and illness or database server down due to virus.  Then, he lists the probability, impact, expected value, response, response cost, probability-after response, impact-after response and expected value-after response for each event.
Figure 2. Andrew's risk management breakdown--partial.
Related CHIPS Articles
Related DON CIO News
Related DON CIO Policy

CHIPS is an official U.S. Navy website sponsored by the Department of the Navy (DON) Chief Information Officer, the Department of Defense Enterprise Software Initiative (ESI) and the DON's ESI Software Product Manager Team at Space and Naval Warfare Systems Center Pacific.

Online ISSN 2154-1779; Print ISSN 1047-9988
Hyperlink Disclaimer