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.

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:

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:

1. High
2. Significant
3. Moderate
4. Minor
5. Low

Document the risks and circulate them among the project team members.

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.

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

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:

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.

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.

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.