Page 34 -

be much more likely to occur and, if they do occur, they might cause much more damage
than others. In those cases, steps should be taken to hedge the project (or portfolio)
against the risk; this is usually referred to as “mitigation” when it is done in the context of
project planning.
Risk planning for most projects can be done in one meeting, usually in less than two
hours. The meeting is led by the project manager, who should select a team similar (or
identical) to that of the Wideband Delphi session (see Chapter 3), with the exception that
there is no moderator. Table 2-2 contains a script for creating the risk plan.

TABLE 2-2. Risk planning script
Name Risk planning script
Purpose To assess risks and create a risk plan.
Summary The risk planning meeting happens in three parts: a brainstorming session to identify risks; a
discussion in which the probability and impact of each risk is estimated; and a discussion to
identify actions that can mitigate risks. The end result is a risk management plan, which
should be included verbatim in the final project plan.
Work Products Input
Any project documentation that has been developed so far.
Output
Risk plan.
Assumptions generated by the Delphi process.
Assumptions in the vision and scope document.
Entry Criteria The project manager has gathered the project team for a two-hour meeting to assess the
project’s risks.
Basic Course of Events 1. Brainstorm potential risks. The project manager leads a brainstorming session to identify
risks. Team members suggest every risk they can think of; the project manager writes the
risks on a whiteboard as they come up. Brainstorming should be reminiscent of microwave
popcorn: a few ideas should “pop” at first, followed by a large number being fired rapidly,
slowing down to a final few “pops.” The team will generally be able to judge when the risk
identification is over.
2. Estimate the impact of each risk. The team assigns a number from 1 (highly unlikely) to 5
(very likely to occur) to represent the estimated probability of each risk. Similarly, impact
should be estimated by assigning a number from 1 (for a risk with low impact) to 5 (for a
risk which, if it occurs, will require an enormous effort to clean up).
3. Build the risk plan. The team identifies actions to be taken to mitigate high-priority risks

and creates a risk plan that documents these actions.
Exit Criteria The risk plan is finished.

Brainstorm potential risks
Risks should be as specific as possible. It’s true that “The project might be delayed” or “We
will go out of business” are risks; however, they are far too vague to do anything about.
When a vague risk comes up, the project manager should prod the team into making it
more specific. What are the possible sources of the project delay? How have past projects
been delayed? For example, if the last project was late because a major stakeholder quit
and was replaced by someone who disagreed with his predecessor’s vision, the team
should write that down as a risk. The assumptions documented in the vision and scope

26 CHAPTER TWO