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.
|
|