Page 90 - The Six Sigma Project Planner

The risk control plan addresses four areas:
1. Identifying the risk

2. Measuring the risk
3. Preparing risk response plans

4. Executing the risk response plans

Identifying and Measuring the Risk
As the name implies, the first step is to recognize which risks are likely to affect the
project. Once identified, these risks will be described in clear and concise terms to
ensure that all team members understand them. This activity, by itself, will go a long
way toward mitigating the risk. Often, simply by seeing a risk, team members will spot
flaws in their project plan that they can address immediately. The project team may
wish to brainstorm to develop a list of potential risks. Examples are:
• What adverse events have affected other projects in this organization in the past?
– Similar projects

– Any project
The team may wish to interview team members who have participated in other
projects. This question could also be included in the interviews conducted during
the activity definition phase. If your organization has an online database of
projects, you may find information there. You may also wish to search the Web
or Usenet discussion groups. (www.google.com contains searchable archives of
newsgroup discussions.)
• What new technology must we develop or use to successfully complete this project?
Projects that use proven technologies are inherently less risky than those that rely
on state-of-the-art technology. Riskier still are those that require innovation and
invention for success. Creativity is still impossible to program.
• How reliable are the cost, duration estimates, scope elements, and other inputs on which
the project plan is based?
There’s an old saying in the computer science field, “Garbage in, garbage out”
(GIGO). Your project’s action plan was developed based on the inputs from a
wide variety of sources. Now is the time to step back and ask whether any of
those inputs might be of questionable accuracy or reliability. We are not implying
that any of the people providing information are incompetent or deceitful.
Rather, we are saying that some inputs are inherently more difficult to know
with certainty than others. For example, activity duration estimates based on
historical experience with a dozen similar projects are more trustworthy than
estimates based on the recollection of an individual from a project he worked on
several years ago. Focus on activity estimates that, if wrong, will have a
significant impact on the project’s ability to deliver as promised.

73