Risk Management Process

A key factor in the success of any application development project is the identification of the risks a project might encounter, and the development of a system for managing those risks should they materialize during the project's life cycle. We include a discussion of risk management in this chapter because it begins in the Envisioning Phase. However, the process of managing risks continues throughout the entire project.

Many IT professionals have misconceptions about risk management. At best, they think it is a necessary but boring task to be carried out at the beginning of a project before the real work of writing code begins. At worst, they think it is another form of bureaucratic red tape that prevents the organization from achieving its objectives. Every project has its risks, and taking risks is essential to progress. However, that doesn't mean that attempting to recognize and manage risks is a useless activity or that it will stifle creativity.

Risk is the possibility of suffering loss. For a given project, this loss could be in the form of:

  • Diminished product quality.
  • Increased costs.
  • Missed deadlines.
  • Complete failure to achieve the project's goals.

Because risk is a problem waiting to happen, not one that has occurred, effective risk management is a dynamic process rather than a static project management chore.

Team members usually know the risks associated with their project, but often communicate these risks poorly. Typically, communicating risks down the chain of command is easy, but communicating risks up the chain of command is difficult. At every level, people want to know the risks identified at the lower levels, but are wary of communicating the risks they have identified to the people above them. For the risk management process to succeed, the organization must create an environment in which people who identify and communicate project risks are safe from retribution. In a "don't shoot the messenger" environment, team members feel free to express tentative or controversial views, which significantly improves the scope and quality of risk management.

On some projects, reporting new risks can be viewed as a form of complaining or troublemaking. Often the reaction to the risks is seen as a problem with the person making the report rather than a problem with the product. If the organization's unspoken message is to "soften the risk," critical information that would result in better risk mitigation and contingency plans might be stifled.

Remember that risk is the possibility, not the certainty, of loss. Team members might erroneously view a project with a list of 15 to 20 identified risks with skepticism, even though the total risk exposure is modest.

Sources of Risk

Effective project risk management must take into consideration the business environment in which the project will be carried out. Many IT projects fail not because of faulty technology or bad project management, but because larger organizational pressures were ignored. These organizational pressures come in many forms, such as competition, financial health, and organizational culture. Potential risk sources include:

  • Mission and goals.
  • Decision drivers.
  • Organization management.
  • Customer and users.
  • Budget and costs.
  • Schedule.
  • Project characteristics.
  • Development process.
  • Development environment.
  • Personnel.
  • Operational environment.
  • New technology.

Possible consequences for the project include:

  • Cost overruns.
  • Schedule slips.
  • Inadequate functionality.
  • Project cancellation.
  • Sudden personnel changes.
  • Customer dissatisfaction.
  • Damage to the organization's image.
  • Demoralized staff.
  • Poor product performance.
  • Legal proceedings.

It is important to remember that different types of projects pose different kinds of risks, and each project's risks must be addressed individually.

Types of Risk Management

Risk management can be approached in three ways:

  • Waving the magic wand The project team assesses the risks only once during initial project planning. Major risks are identified, but are never explicitly reviewed or acted upon.
  • Reactive The project team reacts to the consequences of risks (actual problems) as they occur.
  • Proactive The project team has a visible process for managing risks that is measurable, repeatable, and addresses the conditions that cause the risks.

Obviously the "magic wand" approach is not an example of good risk management. But neither is the reactive approach, because it has no prevention component. Preventing the risks identified for a project from materializing is the hallmark of a good risk management process. Prevention begins in the Envisioning Phase and continues until the product is released at the end of the Stabilizing Phase. For most risks, the goal is to take certain actions to prevent the risks from materializing as problems, as well as to determine in advance what actions will be taken if a particular risk does in fact materialize. To reach mature levels of proactive risk management, the project team must be able to unemotionally evaluate the risks and take actions that address their root causes, not just their symptoms.

It's important to emphasize that no matter how good a job the team does of risk assessment, it is the team's ability to manage risks that will be a determining factor in the project's success.

The risk management process consists of proactive decisions and actions that continually:

  • Assess what risks might occur.
  • Determine what risks need to be acted upon.
  • Specify what strategies should be implemented to mitigate those risks.

An effective project team assesses risks throughout the life cycle of the project and uses them for decision-making in all project phases. As shown in Figure 5.2, the team carries the risks forward until either they are resolved or they turn into problems and are handled as such.

click to view at full size

Figure 5.2 Proactive risk management process

Step #1: Risk Identification

Risk identification is the first step in the proactive risk management process. Risks must be identified before they can be managed. Risk identification provides the opportunities, cues, and information that allow the team to expose the major risks that might adversely affect the project.

To identify risks, team members and key stakeholders hold a series of brainstorming and open discussions to identify and rank the risks for the project. To facilitate this process, risk factors can be grouped by focus area, such as custom software development, infrastructure deployment, packaged software deployment, enterprise architecture planning, and component-based development. Within each focus area, risk factors can be further grouped into categories, such as mission and goals factors, decision drivers, organizational management factors, and budget and cost factors.

For example, Table 5.2 identifies three mission and goals risk factors. Each factor has low, medium, and high risk cues. If the low risk cue is in evidence for the project fit risk factor, the project directly supports the customer's mission and goals; if the factor's high risk cue is in evidence, the project does not support or relate to the customer's mission and goals.

Table 5.2 Sample risk factors chart

Risk factor Low risk cue Medium risk cue High risk cue
Project fit Directly supports customer's mission and goals Indirectly impacts one or more goals Does not support or relate to customer's mission or goals
Customer perception Expects team to provide this product Believes team is not working on expected product Believes desired product is mismatched with prior team products
Workflow Causes little or no change to workflow Changes some aspect of workflow or has small effect on workflow Significantly changes workflow or method of organization

For any risk the team discovers as a result of working through the risk factors chart, it should develop a risk statement and enter the risk on a master list. A risk must be clearly expressed before it can be managed. In stating a risk, the team should consider not only symptoms, but also causes and results. As Figure 5.3 shows, each risk statement should include the problem (the condition), what is causing the problem (the source), and the expected result for both the problem and the project (the consequence).

click to view at full size

Figure 5.3 Sample risk statement

The process followed during this step is a powerful way to expose the assumptions and differing viewpoints of various team members and stakeholders. It's unlikely that everyone will agree on the ranking of all risk factors. Depending on their level of experience and area of concern, different team members will see the project differently. If no agreement can be reached, the best approach is a majority vote technique. If the votes are tied, caution dictates that the worst case be used for the risk assessment.

Step #2: Risk Analysis

Risk analysis is the process whereby risk data is converted into risk decision-making information. Thorough analysis ensures that the team is working on the right risks.

Risk is primarily composed of two factors:

  • Risk probability Risk probability is the likelihood that an event will actually occur. A simple percentage from 0 to 100 can be used for ranking risks. Only risks with a probability that is greater than 0 percent pose a threat to the project. Only risks with a probability of 100 percent are certainties—in other words, they are known problems. The team might find it more efficient to consistently use a 1 to 3 scale that corresponds to 25 percent, 50 percent, and 75 percent, because too many arguments are often waged over the difference between a 60 percent and 70 percent probability.
  • Risk impact Risk impact measures the severity of adverse affects, or the magnitude of a loss, if the risk materializes. Deciding how to measure sustained loses is not a trivial matter. If the risk has a financial impact, the team can use a dollar value to quantify the magnitude of loss. The financial impact can be long-term costs in operations and support, loss of market share, short-term costs in additional work, or lost opportunity cost. When the financial impact is understood, the risk impact can be classified on a simple 1 to 5 scale, 5 being the greatest impact. Additionally, other risks might have the type of impact where only a subjective rating from 1 to 5 is appropriate. This scale essentially rates the viability of project success. High values indicate serious loss to the project, and medium values show loss to portions of the project or loss of effectiveness.

To evaluate a list of risks, the team must understand the overall threat each risk poses to the project. Sometimes risks that are high in probability are low in impact and can be safely ignored. At other times, risks that are high in impact are low in probability and can again be safely ignored. Risks that have high exposure (high probability and high impact) are the ones worth managing. Reducing the risk exposure can be accomplished by reducing either the risk probability or the risk impact.

To help communicate project risks, team members and stakeholders typically maintain the following items of information in a spreadsheet or database:

  • Risk identifier This name uniquely identifies a risk statement for reporting and tracking purposes.
  • Risk source The source can be identified from a focus area (custom software development, infrastructure deployment, packaged software deployment, and so on), or a category (mission and goals, decision drivers, organizational management, and so on), and or factors (project fit, political influences, organization stability, and so on).
  • Risk condition This natural language statement describes the existing condition that might lead to a loss for the project.
  • Risk consequence This natural language statement describes and quantifies the loss that can occur if the risk materializes.
  • Risk probability This expression represents the likelihood that a risk that results in a loss will materialize. The probability is typically stated as a value of 1, 2, or 3, representing a percentage of 25 percent, 50 percent, or 75 percent respectively.
  • Risk impact The effect on the project, should the risk materialize, is measured as a dollar value or a number, on a scale of 1 to 5, that indicates relative magnitude.
  • Risk exposure The overall threat of the risk to the project is calculated by balancing the likelihood of actual loss with the magnitude of the potential loss. The result of multiplying risk impact by risk probability is used to rank risks. (Note that to rank risk exposure, all the risk impact values must be in the same unit of measurement: either dollars or relative magnitude.)
  • Risk context This paragraph contains additional background information that helps clarify the risk situation.
  • Related risk This list of risk identifications is used to track interdependent risks.

Risk analysis weighs the threat of each risk and determines which risks require preventive action. After the risks are ranked by risk exposure, the team should focus on a risk management strategy and how to incorporate risk action plans into the overall project vision. Because managing risk requires time and effort, the key is to identify a limited number of major risks that must be managed. A simple but effective technique is to develop a list of the ten highest risks for the project. This top-ten risk list should be visible to all project team leads. An additional list of major project risks, to raise awareness with the project stakeholders, should be included in the Vision Document created during the Envisioning Phase and the Master Project Plan created during the Planning Phase.

Step #3: Risk Action Planning

Risk action planning turns risk information into decisions and actions. Planning involves developing actions to address individual risks, prioritizing risk actions, and creating an integrated risk management plan that forms the basis of the Master Risk Assessment Document delivered as part of the Vision Approved Milestone.

During risk action planning, the team should consider four facets of each identified risk:

  • Research Does the team know enough about this risk? Is further study necessary to acquire more information and better determine the characteristics of the risk before decisions are made about what action to take?
  • Accept Can the team live with the consequences if the risk actually occurs? Can the risk be accepted and no further action taken?
  • Manage Can the team do anything to mitigate the impact of the risk should the risk occur?
  • Avoid Can the risk be avoided by changing the product's scope?

When the team identifies a risk that needs management, team members have three options:

  • Reduce the probability of occurrence.
  • Reduce the magnitude of loss.
  • Change the consequences of the risk.

For those risks within the team's control, the action plan consists of applying the resources needed to reduce the risk. For those risks outside the team's control, the action plan consists of finding workarounds. It may also be possible for the team to transfer the risk by:

  • Moving to different hardware.
  • Moving a software feature to another part of the system that is better able to handle it.
  • Subcontracting the work to a more experienced player.

As a safety net, the team should also develop a contingency strategy, which is a fallback plan that can be activated in case the action plan fails to contain the risk. For example, suppose a particular commercial product is needed so that software can be deployed on desktop systems, but the release date of the commercial product is uncertain. The team's contingency strategy might be to use an alternate product. In this case, during Planning Phase's design, the team would identify an alternative product to be used if the original commercial product does not meet the release date.

Deciding when to resort to the contingency strategy is a matter of watching the strategy's trigger value. Often the team can establish a trigger value for each contingency plan based on the identified type of risks or the type of project consequences. Table 5.3 shows some typical risks and consequences and their trigger values. When a trigger value is exceeded, the corresponding contingency strategy can be put into action to help mitigate the risk.

Table 5.3 Sample risks and contingency plan trigger values

Type of risk Trigger value
Schedule slips Latest date to use contingency strategy
Latest date to select another vendor
Additional resources required Latest date to allow time to find resources
Greatest amount of penalty or fine to incur
Greatest amount of effort available for overrun
Extra cost to customer Dollar limit
Learning time Time limit

To begin creating the Master Risk Assessment Document, several key items must be identified for each risk. These items are typically entered into an automated risk action form to assist communication between the team members and stakeholders:

  • Risk identifier This name uniquely identifies a risk statement for reporting and tracking purposes.
  • Risk statement This natural language statement (explained earlier) describes the condition that could possibly lead to a loss for the project, and describes the loss that will occur if the risk materializes.
  • Risk management strategy In a paragraph or two, the team describes its strategy for managing the risk, including any assumptions it has made.
  • Risk management strategy metrics The team will use the following metrics to determine whether the planned risk management actions are working:
  • Probability The likelihood that the risk will occur. Represented as a number between 1 and 3.
  • Impact The severity of the impact on the project. Can be represented as a relative number between 1 and 5. Consistent impact measures should be used for all risks.
  • Exposure The overall threat to the project. Calculated by multiplying the probability by the impact.
  • Action items This list describes the actions the team will take to manage the risk. Any actions taken will be logged in the risk tracking system.
  • Due dates This is the date by which the team will complete each planned action item.
  • Personnel assignments These people are assigned to perform the listed actions.
  • Contingency strategy In a paragraph or two, the team describes the contingency strategy to be followed in the event that the action plan fails to manage the risk.
  • Contingency strategy trigger values and metrics The team will use these trigger values to determine when the contingency strategy should be put into effect and these metrics to gauge whether the contingency strategy is working.

Step #4: Risk Tracking

Risk tracking is essential to effectively implement an action plan. It is the process by which the project team monitors the status of risks and the actions it has taken to mitigate them. It includes devising the risk metrics and trigger values needed to ensure that the planned risk actions are working. Tracking is the watchdog function of the risk action plan.

It is a good practice to include a risk review during regular project reviews and debriefings. Risk review should include an assessment of progress made toward mitigation of the project's top ten risks.

During each project review, the team should report on the major risks for the project and the status of any risk management actions. Ranking risks over time is useful, as well as keeping a record of the number of times a risk appears in the top-ten risk list.

Risk status reporting can identify four possible risk management situations:

  • The risk is resolved, and the risk action plan is complete.
  • Actions are proceeding as planned, in which case the risk action plans can continue.
  • Actions are not proceeding as planned, in which case corrective measures should be determined or the contingency plan can be implemented.
  • The situation has changed significantly with respect to one or more risks, and reassessment is necessary.

As the team takes actions to manage risks, the total risk exposure for the project should decrease.

Step #5: Risk Control

After the team has defined the risk trigger values and metrics, the difficult part of risk management is over. Risk management melds into project management processes that:

  • Control risk action plans.
  • Correct for variations from plans.
  • Respond to trigger values.
  • Improve the risk management process.

As suggested by Ron Higuera and Yacov Haimes in the Software Engineering Institute paper Software Risk Management,

If the risk management process is not integrated with day-to-day project management, it will soon be relegated to a background activity.

Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Year: 1999
Pages: 182

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net