Many teams adequately identify their project's risks, but few effectively mobilize the concerted action needed to resolve the problems. The team can use a model to clarify thinking around the project risk details and reach effective consensus on how to resolve the individual risks.
Take Santa Clara, Calif., USA-based Intel, a global producer of integrated circuits, motherboards, systems and software. When developing a dual-processor server at its Hillsboro, Ore., USA facility, including a motherboard, an enclosure, a power supply and several layers of software, the project team applied a standard risk model (Figure 1) to track potential problems through a risk management process. By employing a risk model to visualize and communicate possible problems, the project team analyzed, prioritized and dealt with risks to deliver the server successfully.
Figure 1. Shown is a framework for a project risk. A risk event causes an impact. Both components are influenced by drivers, which are the facts that lead you to believe that the risk event and its impact could occur and how serious they could be. This template provides for three numeric quantities: a probability of risk event, a probability of impact and a total loss. All three are estimated based on the drivers.
Figure 2. The standard risk model portrays the Intel project risk. The drivers substantiate the risk event and its impact and help the team reach consensus on the three quantities.
Figure 3. The Intel team identified a number of risks. The project workers developed an action plan for both the first and second risks shown and monitored the third.
As part of the planning process, a cross-functional project team brainstorms potential problems. Utilizing a risk model doesn't change the identification process, but it encourages greater thoroughness. Instead of just listing a risk, with the standard risk model, you must state both its risk event and its impact. Because the submitter must be reasonably careful in describing the risk, the identification phase automatically prescreens and eliminates “phantom” risks.
In Intel's dual-processor server project, the team identified one possible risk as inadequate product validation capacity. Its impact would be delayed product validation.
During the analysis step, the team examines each identified risk in two substeps:
- List the drivers, or the facts that lead you to believe that the risk event or its impact could occur. After examining each driver, you will see an increased or decreased likelihood or severity of the risk event or its impact.
- From the drivers, estimate the two probabilities and the total loss shown in Figure 1.
For Intel's possible inadequate product validation capacity, Figure 2 shows the results of analysis. The team listed the risk event and its impact as part of the risk identification step, and the model's other five boxes were filled in during this analysis process. This figure reveals the risk's details and interactions. The project team easily can observe the drivers that provide a foundation for the risk. Conversely, the team can clearly see if these supporting drivers are weak, suggesting that more investigation is needed before proceeding.
Step 3. Prioritize Risks
From the probability of risk event (Pe), probability of impact (Pi) and the total loss (Lt), you can calculate the expected loss (Le) for each risk as:
Le = Pe × Pi × Lt
By determining the expected losses for all risks in the project, you can rank them in order of overall severity: Larger numbers equate to bigger risks. You can support your prioritization decisions with the drivers detailed in your model. There always will be risks that you can't address, but by ranking them, you can agree which ones are most pressing and relevant.
Two other risks the Intel team managed on this dual-processor server project include:
- High mortality rate on a new memory component
- Incomplete requirements regarding power management features.
Figure 3 compares the three risks in terms of their expected loss (calculated using the formula). Based on this prioritization, the Intel team decided to actively manage the first two risks, or formulate and execute action plans for them. It also decided to manage the third risk inactively by monitoring the risk in case it grew more serious later.
Step 4. Develop Action Plans
Using your risk event drivers and impact drivers as clues, you can create the most common and powerful types of action plans: prevention plans and contingency plans. Usually, each risk event driver suggests a prevention plan, which is an action plan that keeps the risk event from occurring. Similarly, each impact driver suggests a contingency plan, which is an action plan that minimizes the actual loss should the risk event occur despite your prevention plans.
Figure 4 illustrates how drivers naturally led to action plans for the Intel validation-capacity risk. Sometimes, one driver suggests multiple action plans, and some drivers do not lead to an action plan by themselves. An effective action plan must designate a responsible individual, a due date, means to measure progress and resources to execute the plan. The model facilitates the formulation of actionable plans in two ways:
- Often, the drivers may point you toward an effective action plan targeting root causes
- If an action plan isn't apparent, you should reconsider whether or not you have listed all of the drivers for the risk.
The risk model also points to other types of action plans, such as avoidance, transference and acceptance plans. However, if you do not word your risk event and impact drivers clearly, you probably do not have a clear picture of the risk yet, and this deficiency will become apparent when you attempt to convert your drivers into action plans.
Step 5. Monitor Your Plans
You can monitor your risk management progress overall by tracking the total expected loss across all actively managed project risks. If you're managing the top seven risks, for example, you add these seven expected losses and monitor this total every week to see if it is decreasing fast enough to suit you. In addition, you can see where you need to do more work simply by following these values individually for each of your risks, either with spreadsheet software or an online project data management system.
Figure 4. The Intel team used drivers to develop action plans to mitigate risks. This simplified version shows two drivers and the respective action plans.
Benthos’ earlier side-scan towfish, “C3D,” is being deployed in Fairhaven Harbor, Mass., USA.
The Intel team's primary prevention plan was to work with management to elevate the priority of the project within the business unit project portfolio. Management chose not to reprioritize, and the team was poised to move to its contingency plan (replanning the project for later delivery). However, when the team presented its risk analysis and plans to management, executives clearly could see the consequences of reprioritized laboratory resources. Although management did not elevate the priority of the dual-processor server project (prevention plan), it did allow the team to replan its schedule to compensate for the low-priority status (contingency plan). In other words, management took responsibility for its prioritization decision, rather than blaming the team for the schedule slippage.
Consequently, the Intel project was executed far more realistically than it would have been without using a risk model to guide project management, and key customer commitments still were achieved.
Exploring the Seas
Regardless of the exact risk management process you employ or type of project, a risk model provides a powerful means of managing the project risk.
Benthos Inc., a North Falmouth, Mass., USA-based manufacturer of undersea exploration and packaging inspection equipment, used the standard risk model in 2002 when developing a towfish, an instrument used to map the ocean floor. This “project gamma” involved mechanical design, electrical design, software development, prototyping and testing.
For its towfish project, Benthos identified possible risks, one of which was that the lead hardware engineer would be pulled from project gamma to fix a customer field problem. In this case, the impact would be delayed development of the towfish.
Next, Benthos analyzed this risk, supporting it with risk event and impact drivers, then estimating the probability of risk event, probability of impact and total loss. Thus, the risk model for Benthos’ pulled-engineer risk is shown in Figure 5.
Figure 5. The Benthos team also used the standard risk model. The drivers are used to place the risk on a solid foundation, which allows the team to decide whether or not it is serious enough to manage.
When the project gamma team prioritized the risks, it identified the pulled-engineer risk as the most serious threat to successful completion of the project. As with Intel, the team looked at the risk event drivers to suggest prevention plans and at the impact drivers to prompt contingency plans, as illustrated in Figure 6.
Although project gamma is not yet complete, there already has been valuable companywide benefit from managing the pulled-engineer risk. Due to the nature of Benthos’ business, the risk of having an engineer pulled from a development project to fix problems on fielded products is always possible. Consequently, the action plans developed for this specific project also have minimized this risk for other projects. PM
Figure 6. The Benthos team developed plans to mitigate risks based on drivers. The team uses impact drivers to develop contingency plans that will render a risk less severe if the prevention plan is not effective.
Preston G. Smith, New Product Dynamics, Portland, Ore., USA, consultant and trainer, has guided new product development efforts for 16 years and has 20 years of prior engineering and management experience. He is co-author of Proactive Risk Management (Productivity Press, 2002).
