Home
|
Risk Plan |
|
|
Risk assessment is an important part of planning a software project
because it allows the project manager to predict potential problems
that will threaten the project and take steps to mitigate those
problems. Adding a risk plan to a software project plan is an effective
way to keep the project from being derailed by surprises or emergencies.
Risk Plan
A risk plan is a list of all risks that threaten the project,
along with a plan to mitigate some or all of those risks. Some people
say that uncertainty is the enemy of planning. If there were no
uncertainty, then every project plan would be accurate and every
project would go off without a hitch. Unfortunately, real life
intervenes, usually at the most inconvenient times. The risk plan is an
insurance policy against uncertainty.
| 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 where 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
|
- 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.
-
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).
-
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
document and identified in a Delphi session are another good source of
potential risks. The team should go through them and evaluate each
assumption for potential risks as part of the risk brainstorming
session.
Estimate the impact of each risk
Once the team has generated a final set of risks, they have enough
information to estimate two things: a rough estimate of the probability
that the risk will occur, and the potential impact of that risk on the
project if it does eventually materialize. The risks must then be
prioritized in two ways: in order of probability, and in order of
impact. Both the probability and impact are measured using a relative
scale by assigning each a number between 1 and 5.
These numbers are arbitrary; they are simply used to compare the
probability or impact of one risk with another, and do not carry any
specific meaning. The numbers for probability and impact are assigned
to each risk; a priority can then be calculated by multiplying these
numbers together. It is equally effective to assign a percentage as a
probability (i.e. a risk is 80% likely to occur) and a real duration
for impact (i.e. it will cost 32 man-hours if the risk occurs).
However, many teams have trouble estimating these numbers, and find it
easier to just assign an arbitrary value for comparison.
Many people have difficulty prioritizing, but there is a simple
technique that makes it much easier. While it’s difficult to rank all
of the risks in the list at once, it is usually not hard to pick out
the one that’s most likely to occur. Assign that one a probability of
5. Then select the one that’s least likely to occur and assign that one
a probability of 1. With those chosen, it’s much easier to rank the
others relative to them. It might help to find another 5 and another 1,
or if those don’t exist, find a 4 and a 2. The rest of the
probabilities should start to fall in place. Once that’s done, the same
can be done for the impact.
After the probability and impact of each risk have been estimated, the
team can calculate the priority of each risk by multiplying its
probability by its impact. This ensures that the highest priority is
assigned to those risks that have both a high probability and impact,
followed by either high-probability risks with a low impact or
low-probability risks with a high impact. This is generally the order
in which a good project manager will want to try to deal with them: it
allows the most serious risks to rise to the top of the list.
Make a mitigation plan
All of this risk brainstorming and estimation is only useful if it
leads to the team taking actions to avoid the most pressing risks. The
remainder of the risk planning meeting should be dedicated to
identifying these actions. The project manager should start with the
highest-priority risk, working with the team to decide on any actions
that should be taken. After that, the team should move down the list of
risks, until they decide that the priority of each of the remaining
risks is low enough that no action would be required.
The team can take any or all of these actions to mitigate a risk:
- Alter the project plan. The project schedule can be
adjusted to help reduce the risk. Riskier tasks can be moved earlier in
the project, or given more time. This will give the team an early
warning or a time cushion in case the risks materialize. The project
manager can also hold an additional estimation session to break down
the riskiest tasks into sub-tasks. More detailed planning will help
reduce the risk.
- Add additional tasks. There are certain actions that can
be added to the schedule to help avoid risks. For example, if there is
a high probability that a critical team member will leave the
organization, cross-training tasks can be assigned to other people.
This will increase total effort in the project, but it will be worth it
if the team member leaves.
- Plan for risks. For risks with a high impact that do not
need specific tasks or project plan changes, the project manager should
have the team spend a few minutes identifying the steps that should be
taken in case the risk does occur. These do not need to be added to the
project schedule, but they should be written down and added to the risk
plan. This way, if the risk does occur, nobody will panic. Problems
that have a large impact on the project can be demoralizing to the team
and may throw the project into chaos. Simply having pre-planned the
steps needed to fix the problem is highly reassuring; it keeps the team
feeling like they are on track.
Once the mitigation steps are identified, all of these risks and
actions should be documented in a risk plan. The easiest way to do that
is to create a simple spreadsheet with five columns: Risk (one to three
sentences which describe each risk), Probability (the estimated
probability from 1 to 5), Impact (the estimated impact from 1 to 5),
Priority (Probability × Impact) and Action (the specific actions that
will be taken to mitigate the risk, or “None” if the risk is deemed a
low enough priority to ignore).
Sample Risk Plan
|
|
|
|
%2072dpi.png "Sample Risk Plan")