This task describes how to identify, analyze and prioritize risks to the project, determine appropriate risk management strategies, and reflect these in the Risk List for the project.
Disciplines: Project Management
Purpose
To identify, analyze and prioritize risks to the project
To determine appropriate risk management strategies
To update the Risk List to reflect the current project status
Relationships
RolesPrimary Performer:
Project Manager
Additional Performers:
InputsMandatory:
None
Optional:
Vision
Outputs
Risk List
Process Usage
Project Management > Manage Iteration > Identify and Assess Risks
Project Management > Conceive New Project > Identify and Assess Risks
Project Management > Evaluate Project Scope and Risk > Identify and Assess Risks
Project Management > Reevaluate Project Scope and Risk > Identify and Assess Risks
Steps
Identify Potential Risks
Purpose
To make an inventory of 'what can go wrong' with the project.
To initiate the risk list (in the inception phase):
Gather the project team together (which at this point should be quite small; if there are more than five to seven
people on the project team, limit the risk assessment process to the activity leaders).
When we identify risks, we consider 'what can go wrong'. At the broadest level, of course, everything can go wrong. The
point is not to cast a pessimistic view on the project, however; we want to identify potential barriers to success so
that we can reduce or eliminate them. For more information, see Guideline: Risk List.
More specifically, we are looking for the events which might occur which would decrease the likelihood that we will be
able to deliver the project with the right features, the requisite level of quality, on time and within budget.
Using brainstorming techniques, ask each member to identify a project risk. Clarification questions are allowed, but
the risks should not be evaluated or commented on by the group. Go around the table until no more risks can be
identified.
Involve all parties in this process, and don't worry too much about form or duplicates; you can clean up the list
later. Use homogeneous groups of people (customers, users, technical people, and so on). This eases the process of
collecting risks; individuals are less inhibited in front of their peers (in specialty and hierarchy) than in a large
mix.
Make clear to the participants that raising a risk does not equate in any way with volunteering to address the risk. If
there is any sense that raising a risk will result in becoming responsible for addressing the risk, no one will
identify any risks (or the risks they do raise will be trivial).
To prime the pump, try starting with generic risk lists such as Assessment and Control of Software Risks by
Capers Jones [JON94] or the Taxonomy-Based Risk Identification established by the Software
Engineering Institute [CAR93]. Circulate
the risk list: seeing what has been already identified often helps people to identify more.
To update the risk list (in later phases):
You may solicit input as identified above. But generally, based on the example of the existing list, new risks will be
identified by the team members, and captured at the regular project Status Assessment. See Task: Assess Iteration.
Analyze and Prioritize Risks
Purpose
To combine similar risks (to reduce the size of the risk list).
To rank the risks in terms of their impact on the project.
When no more risks are being found, look at the risk list as a group to see if there are any natural groupings
(occurrences of the same risk), and combine risks where possible to eliminate duplicates. Sometimes, the risks
identified will be symptoms of some more fundamental risk; in this case, group the related risks together under the
more fundamental risk.
Quantitative risk management techniques recommend that risks be prioritized according to the overall risk exposure the
risk represents to the project. To determine the exposure for each risk the group should estimate the following
information:
Impact of risk
The deviations of schedule, effort, or costs from plan if the risk occurs
Likelihood of Occurrence
The probability that the risk will actually occur (usually expressed as a percentage)
Risk Exposure
Calculated by multiplying the Impact by the Likelihood of Occurrence
As a group, the exposure of each risk should be derived by consensus. Significant differences of opinion should be
further discussed to see if everyone is interpreting the risk the same way. Typically this information is included as
columns in a tabular Risk List.
It is human nature to worry about the highest impact risks, but if these are very unlikely to occur they are really
less important than more moderate risks that are often overlooked. By considering both the magnitude of the risk and
its likelihood of occurrence, this approach helps project managers focus their risk management efforts in areas that
will have the most significant affect on project delivery.
Once the exposure for each risk has been determined, you can sort the risks in order of decreasing exposure to create
your "top 10" Risks List.
Because estimation of likelihood and cost is expensive and risky in itself, it is generally only useful to gauge the
impact of the top 10 to 20 risks. Smaller projects may consider fewer risks, whereas larger projects present a larger
'risk target' and as a result have a larger number of relevant risks.
In addition to ranking the risks in descending order of exposure, you may also find it useful to group or cluster the
risks into categories, based on the magnitude of their impact on the project (risk magnitude). In most cases, five
categories is sufficient:
High
Significant
Moderate
Minor
Low
Document the risks and circulate them among the project team members.
Identify Risk Avoidance Strategies
Purpose
To reorganize the project to eliminate risks
While not always possible, sometimes you can side-step risks altogether. Often risk is caused by poor system scope; if
you can reduce the scope of the system (by eliminating non-essential requirements), whole sections of the risk list go
tumbling off with the dropped requirements. Not the least of these risks is that of not having enough resources
(including time) to do the work.
In other cases, technology can be acquired to reduce the risk of building particular functionality, a form of risk
avoidance in which one set of risks (that of building the technology) is exchanged for another (that of being dependent
upon forces outside one's control).
Finally risk can be transferred to other organizations.
Identify Risk Mitigation Strategies
Purpose
To develop plans to mitigate risks, that is to reduce their impact of the risks.
For direct risks, that is, risks for which the project has some degree of control, identify what actions will be
taken to reduce the probability of the risk, or to reduce its impact on the project (the mitigation strategies).
Typically, the risk itself derives from lack of information; often, the mitigation strategy itself is one of
investigating the topic further the reduce the uncertainty.
There are risks for which some action can be taken to either make the risk materialize or retire it. In an iterative
development process, allocate such actions to early iterations to mitigate the risk as early as possible. Confront the
risks as early as possible. If a risk is in the form "X may not function as planned?", then plan to try X as soon as
possible.
Examples:
To reduce the risk that products X and Y cannot be integrated, a prototype will be built to investigate the
difficulty of integration. The following features (enumerate in a list) will be tested to ensure the integration is
successful.
To reduce the risk that Database A will not perform adequately, it will be benchmarked using a suite of tests which
model the workload of the target application.
To reduce the risk that test tool Z will not be able to effectively regression test the application, we will
acquire and use it during the upcoming iteration.
The result of these actions should be to reduce the probability that certain risks will occur, perhaps to near zero. In
cases where the risk is confirmed, the risk is responded to with a contingency plan (See Identify Contingency Strategies).
Identify Contingency Strategies
Purpose
To develop alternate plans
For each risk, whether you have a plan to actively mitigate it or not, you must decide what actions are to be taken
when or if the risk materializes, that is, if it becomes a problem, a 'loss event' in insurance jargon. This is
commonly called "a plan 'B'" or contingency plan. A contingency plan is needed when risk avoidance and risk transfer
have failed, mitigation was not that successful, and now the risk must be addressed head-on. This is very often the
case for indirect risks, that is, the risks for which the project has no control, or when the mitigation strategies are
too costly to implement.
The contingency plan should consider:
Risk
Indicator
Action
What is the risk?
How will you know that the risk has become a reality? How is the 'loss event' recognized?
What should be done to address the 'loss event' (how can you stop the "bleeding"?)
Identify Risk Indicators
Some risks can be monitored using project metrics, looking at trends and threshold; for example:
Rework remaining too high
Breakage remaining too high
Actual expenditure far above plans
Some risks can be monitored based on project requirements and test results; for example:
Response times one order of magnitude above requirement.
Some risks are associated to specific event; for example:
Software component not delivered in time by third party.
There are many other, "softer" indicators, none of which will fully diagnose the problem. For example, there is always
a risk that morale will drop (in fact, at certain points in the project, this is almost (predictable). There are a
number of indicators: grumbling, "gallows humor", missed deadlines, poor quality, and so on. No one of these "measures"
is a sure indicator; joking about the futility of a particular deliverable can be a healthy way of relieving stress,
but if it continues, it may be an indication that the team feels an increasing sense of impending doom.
Listen to all indicators without passing judgment. It is easy to label the bearer of 'bad news' as someone who has a
bad attitude; behind cynicism there is often more than a grain of truth. Often, the 'bearer of bad news' is acting as
the 'conscience of the project'. Most people want the project to succeed, and they feel frustrated when momentum is
carrying the project in the other direction.
Identify "Loss" Actions, or "Plan B"
For simple cases, the contingency plan enumerates alternate solutions. The impact is usually costs and delays to scrap
the current solution and implement the new one.
For other, "softer" risks is often not one action to take when a loss has occurred, but several. When morale drops, for
example, it is best to acknowledge the condition and gather as a group to discuss the prevailing attitudes on the
project. Listen to concerns, identify issues, and generally let people vent. After an appropriate amount of venting,
though, move on to address the causes of concern. Use the risk list as a way to focus the discussion. Translate the
concerns into a concrete action plan by reprioritizing risks and then reformulating the iteration plans to
systematically address the top risks. Positive action has a stronger effect than positive (but empty) words.
Despite the mood at the time, a loss occurrence has a positive side: it forces action. Too often it is easy to postpone
risks by ignoring them, lulled into complacency by the apparent quiet. When a loss event occurs, action is required.
The risk is no longer a risk, there is no longer any uncertainty about its occurrence.
Yet a loss occurrence is also a failure to avoid or mitigate risk. It should force a re-examination of the risk list to
determine whether the project team may have some systematic blind-spots. As difficult as frank self-assessment is, it
may prevent other problems later on.
Revisit Risks During the Iteration
Purpose
To ensure that the risk list is kept current throughout the project.
Risk assessment is actually a continuous process, rather than one which occurs only at specific intervals during the
project. At minimum, you should:
Revisit your list weekly to see what has changed.
Make the top ten items visible to the whole project and insist on action being taken on them. Often you would
attach the current risk list to your Status Assessment reports.
Revisit Risks at the End of Iteration
Purpose
To ensure that the risk list is kept current throughout the project.
At the end of an iteration, refocus on the goals of the iteration with respect to the risk list. Specifically:
Eliminate risks that have been fully mitigated.
Introduce new risks recently discovered.
Reassess the magnitude and reorder the risk list (see Analyze and
Prioritize Risks).
Do not be too concerned if you discover that the list of risk grows during the inception and elaboration phases. As
project members do the work, they realize that something they thought was trivial actually contains risks. As you begin
doing integration, you may find some hidden difficulty. However the risks should steadily decrease as the project
reaches the end of elaboration and during construction. If not, you may not be handling risks appropriately or your
system is too complex, or impossible to build in a systematic and predictable fashion. For more information see Guideline: Risk List.