Risk Management

"If you don't actively attack the risks, they will actively attack you."  --Tom Gilb

"Risk Management is not the same as worrying about your project." -- Tom DeMarco, in Waltzing with Bears: Managing Risk on Software Projects. 

Risks management is a regular practice in finance, politics, environmental planning, medicine, etc. Risk management is a integral part of software engineering project management because so much of what goes on during software development is uncertain and non-deterministic.

A risk is a potential problem. A risk may materialize into a real problem. If it does, it is no longer a risk but a problem that should be dealt with using traditional problem solving techniques. The purpose of risk management is to identify risks early while there is still time to take some action before they become problems. Preventing a risk from become a problem is usually easier and less expensive than waiting for the risk to become a problem and then dealing with the problem.

As an analogy, risk management is like a beacon of light illuminating risks in the misty air surrounding the project boat. Whenever possible the project boat will steer clear of the risks identified by risk management. For risks that can't be completely avoided, risk management offers tactics for minimizing the potential damaged caused by risks should they become problems. The last line of defense are contingency plans. Contingency plans are plans for dealing with the risks that become problems. In this analogy, a risk becomes a problem when it strikes the project boat. If it is a risk for which a contingency plan has been prepared, the problem can be dealt with swiftly and effectively.

Risks Management Analogy

Risk management is not the same as risk aversion. Risks are an inevitable part of software development. Some risk is necessary for potential reward. What's important is to take the right risks. The right risks are the ones you understand and the ones with the maximum risk/reward tradeoff. You can avoid risks by investing your money in a bank savings account, but you won't get rich that way.

Risk Management verses Project Management

Many of the project management activities described earlier have the effect of minimizing risks. Creating a schedule reduces the risk of not finishing on time. Testing and quality assurance reduce the risk of delivering an error-prone product. The organization and staffing functions of project management reduce the risk of not having adequate resources to complete a project. With project management already concerned with minimizing risks, why is it necessary to have a separate discipline of risk management? What is the difference between risk management and good old fashion project management?

Figure x. The difference between risk management and project management

The difference is, project management isn't looking for any new problems. Project management is concerned with preventing the common well-known problems that all projects face. Risk management, on the other hand, is concerned with identifying, understanding and abating unique project-specific risks. There are many potential problems that can derail a software project. The software development process needs to address every one. Project management covers the predictable risks all projects are likely to face, and risk management covers the unique project-specific risks that are harder to predict.

Concepts and Principles

A risk is a potential problem. More formally, a risk is the possibility of an unsatisfactory outcome [Boehm 89]. There are two important components of risk:

o the probability of the unsatisfactory outcome
o the magnitude of the loss associated with the unsatisfactory outcome (the impact)

For example, 50% of small businesses fail during their first year of operation. Business failure during the first year is the risk. The probability of this risk is 50% and the magnitude of the loss associated with the risk is the amount of capital invested in the business.

This definition of risk leads to the fundamental concept of risk management which is risk exposure. Risk exposure is defined as:

RE = Pr(Uo) * Loss(Uo)

Pr(Uo) is the probability of an unsatisfactory outcome and Loss(Uo) is a measure of the loss associated with the unsatisfactory outcome.

The probability-loss graph in figure y below shows the relationship between Pr(Uo), Loss(Uo) and risk exposure. Notice that risks (such as risk A) with moderate values for both loss and probability have a greater risk exposure than risks (such as risk B) with high values for either probability or loss alone. Also notice how the contours for constant values of risk exposure (10 and 60) divide the graph into different regions for high, medium and low risks. The specific risk exposure thresholds for classifying a risk as high, medium or low will be project-specific.

Figure y. Probability-Loss Graph

Here is an example of the practical application of risk exposure. Assume there are two companies that provide satellite launch services. Company A has had 12 catastrophic failures in the last 100 launches and company B has had only 10 similar failures in the last 100 launches. One advantage of company A is that it can carry larger less expensive satellites. If the cost of a satellite to be carried by company A is $200 million and the cost of a satellite for company B is $250 million, which launch carries the most risk?

Using the concept of risk exposure we can calculate the risk of launching with each company:

Risk Probability of loss Size of loss Risk Exposure
Lose a satellite with company A 12% $200,000,000 $24,000,000
Lose a satellite with company B 10% $250,000,000 $25,000,000

The risk exposure of launching with company A is less then the risk exposure of launching with company B, so there is less risk associated with launching with company A even though there is a greater probability a satellite will be lost.

Risk Management Process

The flow chart in figure x below illustrates the risk management process. The risk management process incorporates the familiar control cycle:

  1. Plan - determine what to do and how to do it

  2. Execute - do it

  3. Monitor - compare actual performance with planned performance

  4. Take Corrective Action - when actual performance deviates from planned performance take necessary actions to bring performance back in line with plans.

The goal of the control cycle during risk management is to identify and minimize project risks.

Figure x. Risk Management Process

Here the risk management process is described as if it were a standalone process. In practice risk management should be integrated in with project management. This is desirable because (1) risk management requires resources that need to be planned and scheduled along with other project activities, and (2) risks may be identified opportunistically during project management activities. For example, a project not meeting a milestone might suggest a new risk.

The numbered activities in figure x are described in more detail now.

Identify Risks

The risk management process starts with risk identification. The goal of risk identification is to simply identify risks. At this stage it's not necessary to analyze the risk to estimate likelihood, consequences or potential responses. However, this information will be needed in a later step, so if ideas do materialize they should be noted for use later.

Risks should be specific to the project and precise. Whenever possible state the cause of the risk rather than its effect. Knowing the cause will make it easier to mitigate the risk later. For example, "the project might not finish on time" is a risk but it is a risk that virtually all projects face and it doesn't indicate why it is a special concern on this project. To correct the problem, ask why the project might not finish on time and restate the risk so that the cause of the risk is clear. For example, the risk might be restated as: "the schedule is compressed more than 75% of what is considered normal for this type of project". 

Risks are events or conditions that threaten the success of the project. It's easy to brainstorm several of the more obvious risks, but a more systematic approach will yield a more complete list. When looking for risks a good place to start is with the three critical dimensions of a project: schedule, cost and performance. There are risks that threaten the schedule, risks that threaten the cost or resources needed to complete the project, and risks that threaten the product including features and quality attributes. The management and technical processes are also vulnerable to risks. They both define procedures and intermediate work products that lead to the final product. Risks to these processes and work products are risks to the final product. And finally, there are risks that threaten the interest of the various stakeholders. The best way to identify risks to a stakeholder's interest is to invite all stakeholders to participate in risk identification. When stakeholder interests are considered, don't neglect un-represented or under-represented stakeholders, such as the programmers who will maintain the system after it is delivered. You can be sure that someone somewhere cares very much about the quality attribute "ease of maintenance".

Here are some specific techniques for identifying risks:

  1. Check lists. Table x below provides a general checklist of common project risks organized by type. More useful are specific check lists developed from prior experience with projects similar to the one about to be started.

  2. Requirements document and project plan reviews. The project plan and requirements document contain assumptions and other details about the project and product, and as such are good sources for risks.

  3. Decomposition of tasks. Vague tasks in the work breakdown structure are a rich source of project risks. At the very least they add uncertainty which is a source of risk. More likely their solution is difficult with more than a few hidden risks.

  4. Group consensus techniques such as Delphi. Delphi is an effective technique for reaching consensus, and for risk identification has the added benefit of being anonymous. In some project environments project members may be reluctant to mention certain risks. Delphi provides a way for risks to be raised anonymously and debated publicly.

Here is a list of common project risks grouped by type:


  • Unrealistic schedule for given budget and performance requirements
  • Unrealistic budget for given schedule and performance requirements
  • Changing or expanding project scope and objectives
  • Underestimate amount of work
  • Underestimate project complexity
  • Poor planning
  • Plan abandoned under pressure and project reverts to code-and-fix
  • Lots of parallel activity, many tasks on or about to be on the critical path
  • Inadequate project control
  • Inadequate change management procedures
  • Inadequate time for testing
  • Cost estimates (budget) not increased after schedule compression


  • Poorly defined requirements
  • Misunderstood requirements
  • Incomplete requirements
  • Excessive changes to requirements
  • Vague requirements (customer unsure of requirements)
  • Expanding requirements
  • Gold plating by product champion  (product champion or marketing adds features indiscriminately)


  • Insufficient personnel (lack of knowledge, training and/or experience)
  • Low motivation
  • Poor work environment (noisy, crowded offices)
  • People available aren't people needed
  • Problem team members undermine morale and productivity
  • Project team members are incompatible
  • Unsuitable organization structure (unclear responsibilities and authorities which reduce productivity)


  • Unrealistic performance expectations for given budget and schedule
  • Implementing the wrong functions
  • Implementing the wrong user interface
  • Lack of user involvement
  • Solution-driven decisions (someone's favorite solution is offered as the best solution while its merits are questionable)


  • Unfamiliar development processes
  • Introduction of new technologies
  • Inappropriate methods and/or tools
  • Improper use of new tools or methods leads to rework or poor results
  • Tools don't work as expected
  • Supporting technologies (database, web server, message queue, etc) don't work as expected
  • Learning curve for new tools and technologies longer than expected
  • Inadequate architecture to support future changes
  • Overly complex architecture to support future changes
  • Developer gold plating (developer-driven features are promoted that are technically interesting but not necessarily a high priority for the customer)


  • Unfamiliar problem domain
  • Lack of project champion
  • Customer unresponsive

Table x. Checklist of General Project Risks Adopted from [McConnell 96] [Boehm89] [Gilb 88] [Jones 94]:

Output of the identify risks step is an unordered list of potential project risks. For example:


Plan abandoned under pressure and project reverts to code-and-fix
Cost estimates not increased after schedule compression
Poorly defined requirements
Supporting technologies don't work as expected

Table x. Example List of Identified Risks

Analyze Risks

Once risks have been identified the next step is to analyze each risk to understand its potential impact on project objectives. The results of this analysis will be used in the next step which is to prioritize risks for risk treatment actions.

The impact of a risk on project objectives is determined by the probability of the risk becoming a problem and the expected loss if the risk does become a problem. The risk exposure equation defined above provides a quantitative assessment of risk impact. Recall that risk exposure is:

Risk exposure = (probability of risk becoming a problem) * (expected loss)

Risk analysis can be quantitative or qualitative. Table x below shows the quantitative analysis and prioritization of two risks according to their risk exposure value. Comparing the risk exposure for these two risks, you can see the risk of poorly defined requirements represents a much greater threat to project objectives than poor team organization.

Risk Probability of loss Size of loss Risk Exposure
Poorly defined requirements 50% 2 weeks of extra effort 1 week
Poor team organization leads to disagreements which slows progress 20% 3 weeks of extra effort 1.5 days

Table x. Quantitative analysis and prioritization of risks

Paying for Risk Management

There is a cost for performing risk management. If the cost is taken from the overall project budget, some team members may react negatively to seeing the budget reduced by risk management activities. Their reaction might be, "Stop! We can't afford any more risk management!"

If risk management is done correctly there should be a net gain. The amount saved by performing risk management should more than pay for the activities of risk management. One way to make this clear and to justify the amount spent on risk management, is to use the analysis techniques discussed in this section to examine risks and calculate the expected cost overrun if no risk management is performed. This amount is a pretty good estimate of the management reserve that will be needed to complete the project if nothing is done to reduce the risks. The alternative is to set the same amount aside as management reserve but spend some of the money on risk management. If the risk management techniques are effective it should be possible to pay for risk management from this reserve and still have money left over.

For example, given the risks identified in table x above, the actual time to complete the project is likely to be 6.5 days more than what the current schedule predicts. (With just two risks this estimate isn't likely to be statistically accurate, but in practice there will be many more risks increasing the confidence in the estimate.) This figure now becomes the management reserve, some of which may be spent on risk management.

Even if risk management isn't paid for from the management reserve, the output of the risk analysis step is still an effective way of calculating the management reserve.

Risk impact may also be assessed using qualitative analysis techniques. With qualitative analysis the probabilities and expected losses are described with qualitative terms such as high, medium and low. Figure y below shows an example of a qualitative probability-loss matrix.



Figure y. Example qualitative probability-loss matrix

If you compare the qualitative probability-loss matrix in figure y with the quantitative matrix above in figure z, you will notice that the qualitative matrix is a bit skewed towards higher risk exposure values for catastrophic losses with low probability. The axis scales on a qualitative probability-loss matrix don't have to be linear. What's more important is that they reflect how stakeholders think about the risks. For example, most people would rate the risk exposure of an event with low probability and catastrophic consequences as a high risk.

Table z below shows the qualitative analysis and prioritization of two risks using qualitative values from figure y above.

Risk Probability of loss Size of loss Risk Exposure
Cost estimates not increased after schedule compression Moderate Major Extreme Risk
Plan abandoned under pressure and project reverts to code-and-fix Likely Moderate High Risk

Table x. Qualitative analysis and prioritization of risks

The advantage of qualitative analysis is that the people doing the estimating may relate better to qualitative adjectives as opposed to precise numbers. Quantitative analysis is potentially more precise, but because most estimates are based on human judgment, it may be a false sense of precision. When estimates are derived from human judgment, qualitative techniques offer about as much accuracy as quantitative techniques.

Whether you are performing quantitative or qualitative risk analysis, one challenge to comparing and prioritizing risks is that of finding a common measure of loss. For example, the loss associated with an unrealistic schedule is naturally expressed in weeks. The loss associated with the risk of an unrealistic budget is naturally estimated in dollars (or the local currency). How can you compare the severity of these two risks? In the table below, is the risk exposure "2 weeks" greater than, less than, or equal to the risk exposure "$6000"?

Risk Probability of loss Size of loss Risk Exposure
Unrealistic Schedule 50% 4 weeks 2 weeks
Unrealistic Budget 60% $10,000 $6,000

One solution is to normalize all losses to a standard unit of measure. Another solution is to define separate categories of risks based on the type of loss they represent, and then only compare risks within the same category. The most common categories of risks are schedule, cost, and performance (features and quality). Whatever method is used, you should analyze all risks together at the same time to insure the same relative measures are used.

The most difficult part of risk analysis is estimating the probability and potential loss of a risk. Some techniques for making these estimates are:

  1. Expert Opinion. Perhaps the simplest technique is to just ask the person or group most experienced with the values being estimated. If there isn't consensus among the experts, Delphi or some other group consensus technique can be used to find the best estimate.

  2. Cost Modeling. Cost models such as COCOMO II have cost drivers that can be used to estimate the impact of a change in the project environment. For example, if there is a risk that the project will be staffed with the most available people rather than the most qualified people, the COCOMO II model can be used to estimate the cost of the project assuming high skilled analysts and then again assuming analysts with average skills. The difference will be the risk of not staffing with the best people. (The difference is 4X. See lesson 4 for more details.) COCOMO II has equations for estimating both cost and schedule.

  3. Simulation. Simulation techniques, such as Monte Carlo simulation, can be used to estimate project-level attributes from estimates of more detailed components. For example, Monte Carlo simulation can be used to estimate the probability distribution for completing a milestone in the project plan given the probability distribution for each constituent task of the milestone. (See lesson 4 for an example.)

    The techniques of cost modeling and simulation may also be combined. When values for the cost drivers of cost models have a probabilistic distribution, simulation can be used with cost models to arrive at a probability distribution for the results of the cost model.

  4. Betting analogies. Betting analogies don't really add any new information, but instead encourage accuracy by relying on people's desire to preserve their capital. Betting analogies work like this. If an event has a 50% chance of being true, most people (that gamble) would be willing to put up a certain amount of money, say $100, to win $100. As the odds of the event being true drop below or rise above 50%, the amount of money expected in return for a bet would increase or decrease to compensate for the increase or decrease in risk. For example, if you're waiting for a meeting to start and a colleague turns to you and says, "I'll bet you $100 the meeting starts late." You might respond, "no way, our meetings always start late." But if your colleague continues to goad you into a bet, offering better and better odds, "I'll bet $50 to your $30", "$50 to your $20", "$50 to your $2", at some point the odds will sound just too good to pass up, and you'll take the bet. It's this point that determines the odds of the meeting staring on time. If you accept the bet at "$50 to your $2" you are assuming the probability of the meeting starting on time is a little more than 2/(50 + 2) or about 4%.

Output of the analyze risks step is a list of risks together with estimates for the probability and potential loss of each risk. These values are used to compute the risk exposure of each risk. During risk analysis you should document the rational behind these estimates for use later when planning risk response actions.

Prioritize Risks

Risks should be prioritized to avoid analysis paralysis. Analysis paralysis is characterized by spending more time analyzing risks than addressing risks. The results of this step determine the order in which risks will be addressed.

Given the output of the previous step, which includes risks and their risk exposure values, prioritizing risks may at first seem trivial--just sort by risk exposure. Table x below shows a list of risks from the previous step sorted by their risk exposure values. 

Rank Risk Probability Size of loss (1-10) Risk Exposure
1 Project complexity underestimated 50% 6 3.0
2 Unrealistic schedule 40% 5 2.0
3 Expanding requirements 30% 6 1.8
4 Poor work environment 30% 4 1.2
5 Forget to remove seeded bugs from final product 1% 10 0.1

Table x. Risks sorted by risk exposure

Sorting by risk exposure is a good first approximation for the order in which risks should be addressed, but risk exposure alone shouldn't be the only consideration when prioritizing risks. Other considerations that might affect the priority for dealing with risks include:

Output of the prioritize risks step is a prioritized list of risks in the order they should be considered for treatment.

Plan Risk Response

Once you have a prioritized list of risks, the next step is to create plans for managing these risks.

The flow chart for the risk management process in figure x above shows the output for this step:

In general, risks that can be avoided are avoided; risks that can't be avoided are mitigated; risks that can't be avoided or mitigated have contingency plans prepared for them in case they do become problems.

Risk response plans may employ one or more of the following strategies:

Table x below shows an example of each of these 5 strategies being applied to the risk of misunderstanding user requirements.

Risk Buy Information Avoid Transfer Mitigate Accept
Misunderstand user requirements  Create prototypes and conduct surveys to determine how well requirements are understood.  Give users tools to create their own data processing applications. Assign responsibility for documenting requirements to the user. To reduce probability: use documentation techniques that make it easy for the user to review and approve requirements.

To reduce loss: use the design technique of information hiding to make it easier to modify the system in the future if the requirements are misunderstood and the system does need to be changed.

Accept the risk and optionally create a contingency plan.

Example contingency plan: create a fast track procedure for moving change requests through the change control process.

Table x. Potential responses to the risk of misunderstanding user requirements

Table y below lists potential responses to other common project risks.

Risk Risk Response
Insufficient personnel
  • Training.
  • Wait for the best people.
  • Teambuilding.
Unrealistic schedules and budgets
  • Design to cost and design to schedule.
  • Use incremental development to deliver most important features early.
  • Use multiple estimation techniques (expert judgment, cost models, analogies with past projects, etc).
  • Use earned value analysis to detect schedule slip so stakeholders can be notified in advance of the most likely completion date for the project.
  • (long-term solution) Collect project metrics on completed projects in a database. Use database of pas experience to plan future projects.
Gold plating
  • Design to cost and design to schedule.
  • Prioritize system requirements early as: mandatory, desired, and optional.
  • Requirements scrubbing (remove unnecessary requirements via cost/benefit analysis, etc.)
  • Incremental development.
  • Perform design review with standards for including and excluding features.
Underestimate amount of work
  • Make a concerted effort to count all tasks
  • Use multiple estimation techniques (expert judgment, cost models, analogies with past projects, etc).
  • (long-term solution) Collect project metrics on completed projects in a database. Use database of pas experience to support estimation via analogy and to calibrate cost models.
Excessive changes to requirements
  • Incremental development (changes can be scheduled for future increments).
  • Architecture that supports system changes.
  • Use design techniques such as modularization and information hiding to minimize impact of changes.
Inadequate design
  • Perform design inspections.
  • Schedule time for design. 

Table y. Potential Responses to Common Project Risks

As mentioned earlier, risk treatment options may also emerge from the risk identification and risk analysis steps. It's hard to think about risks and their causes without generating some ideas or thoughts about how to respond to them.

For each risk there may be multiple treatment options. A tool for deciding among the various treatment options is the risk reduction leverage (RRL) equation. Risk reduction leverage provides a cost benefit analysis of treatment options. Specifically,

Risk Reduction Leverage = (REBefore - REAfter) / Risk Reduction Cost

Where REBefore is the risk exposure before the risk reduction activity, and REAfter is the risk exposure after the risk reduction activity. The numerator of the RRL equation is the benefit of the risk reduction activity and the denominator of the RRL equation is the cost of the risk reduction activity. Risks treatment options with the highest RRL should be implemented first. Treatment options with a RRL of less than 1 shouldn't be implemented at all--the cost of the treatment doesn't justify the expected benefits.

When using the RRL equation to evaluate a treatment option be sure the benefit portion of the equation reflects the benefit to all risks. Sometimes two or more risks have a common cause. When there is a common cause, a single risk response may mitigate multiple risks. This makes calculating risk reduction leverage a little more complicated. When a risk response does affect more than one risk, Risk ExposureBefore and Risk ExposureAfter should represent the total project risk exposure before and after the risk reduction activity.

Output of the plan risk response step are actions plans and contingency plans. Action plans include a schedule for their completion and are executed according to this schedule. Contingency plans are stored and used later when measurement activities detect that the risk is a problem or about to become a problem.

Monitor Risks and Mitigation Plans

Risk management is an ongoing and continuous process. The risk profile of the project is constantly changing. Risk mitigation plans are hopefully reducing some risks, new risks are likely emerging, and the risk exposure of others are changing. During this step project risks and mitigation plans are monitored in order to:

The conventional technique for tracking progress according to a plan is to review project status at scheduled milestones. Risk management activities can be monitored by tracking milestones, but a more common technique for monitoring risk management activities is the top-10 risk list.

Table x shows an example of a top-10 risk list. It's called a top-10 list but in practice doesn't have to have exactly 10 items. It should list all of the serious risks but not so many that they can't all be effectively managed.

The data recorded for each risk includes: current ranking, ranking during the last review, number of review periods the risk has been on the list, a short description of the risk, and progress toward resolving the risk. Depending on what other types of documents are kept, the actions for responding to the risk may or may not be included in the list. The top-10 risk list in table x assumes a separate document, like that show in figure z below, is being used to record risk resolution actions.

This Week Last Week Weeks on List Risk Risk Resolution Progress
1 1 4 Unrealistic schedule Incremental develop being used to deliver most important features first. Earned value analysis is being used to communicate most likely completion date to stakeholders. These are actions to reduce the impact of the risk. No progress has been made on reducing the likelihood of this risk becoming a problem.
2 - 1 Plan abandoned under pressure and project reverts to code-and-fix Progress on design and code inspections is being reported during weekly team meeting. Number of inspections has increased as a result of increased focus.
3 2 3 Low motivation Motivation has been improving since planning next iteration using job-matching
Off list



Supporting technologies don't work as expected Technical preview successful. Have sample program that demonstrates each technical feature needed.

Table x. Top-10 risk list

The purpose for recording historical data about a risk's position on the list is to understand the trajectory of the risk. Is the risk moving up or down on the list? If it's moving up, it deserves special attention. If it's moving down, it may not warrant as much attention as other risks of similar priority.

A regular review schedule should be established for reviewing the risks on the top-10 list. Weekly review meetings at the team or project level are most common but longer review cycles can be justified during quiet periods of the project. Each review should start with a current assessment of each item on the list. What is the progress of risk resolution actions since the last review meeting? Is any corrective action needed to bring progress in line with plans? Should risk items be moved up, down or off the list? Notice, that in table x items that are no longer ranked in the top-10 list are retained for at least one review period.

Several actions may be initiated as a result of the risk monitoring step:

Document the Risk Management Process.

Nobody likes documentation, but the alternative is so much more unpleasant most people are willing to accept a certain amount of paperwork. The alternative is misunderstandings because there is poor communication, poor quality products because there is no record of past work to build on, and rework because previous decisions are forgotten.

Documentation doesn't have to be onerous. Projects that are traveling light can get by with the top-10 risk list described in the previous section. For projects that need more formality there are two other types of documents for recording risk management activity:

  1. Risk Management Plan

  2. Risk Response Plan

The risk management plan describes the project's overall strategy and approach to risk management. A risk response plan is created for each individual risk and details the plans for managing that risk. In spite of the word 'plan' in the title of each document, neither document has to be more than a page in length.

The risk management plan is usually part of the overall project plan but may be maintained as a separate document. Figure x below shows an outline for a risk management plan.

  • Risk management overview

  • Risk management strategies and policies - overall strategy for risk identification, analysis, planning, and monitoring. Will risk identification be done during regular project reviews (project status, design reviews, change control process, etc)? Will a top-10 list be used to monitor risks?

  • Risk management responsibilities - who is responsible for identifying, planning and monitoring risk management activities.

  • Risk management costs and schedules - budget and schedule for performing risk management activities. This section isn't necessary if this information is included in the overall project schedule and budget.

  • Risk management process description - guidelines for performing risk management activities.

    • Risk identification

    • Risk analysis

    • Risk prioritizing

    • Risk response planning

    • Risk monitoring

Figure x. Template for Risk Management Plan, Derived from [IEEE Std 1540-2001]

The Risk Response Plan is used to document an individual risk as well as plan and track risk response activities. It may be used to plan and track mitigation activities as well as contingency plans. Figure y below shows a template for a risk response plan.

Figure y. Risk Response Plan Template

Table z below provides guidelines for filling out the risk response plan in figure y.

  • Risk ID - unique identifier

  • Title - short descriptive name

  • Origination Date - when was the risk identified?

  • Originator - who originally identified the risk?

  • Status - select one of the following: identified, assessed, planned, contingent, problem, crisis, resolved, closed. "Contingent" is used when the risk response plan describes a contingency plan for a risk.

  • Description - short description of the risk including the cause and consequences of the risk.

  • Risk assessment - may be quantitative or qualitative.

    • Probability

    • Consequences

    • Risk Exposure

  • Owner - the person or organization who is responsible for managing the risk.

  • Risk response alternatives - options for responding to risk.

  • Risk response plan - actions needed to implement selected risk response. Should include schedule and responsibilities (task owner) for performing actions. The risk response plan should also include milestone for tracking progress.

  • Plan Status - progress with risk response activities.

  • Resources - people and equipment required to perform risk response plan.

Table z. Guidelines for completing Risk Response Plan Template

Both the risk management plan and the risk response plans need to be coordinated with the overall project plan because they will require project resources.


Boehm, "s/w rm: principles and practices," IEEE s/w 9,1 (Jan 1991), pp. 32-39. Maybe I should start out with a simple list of most likely risks. Maybe I should ditch the distinction between risk mgmt and good old fashion pm.

Project risk = uncertain event or condition that has consequences for the project. The purpose of risk management is to identify, analyze and respond to risks that threaten project success (project risks). Typical software project risks: third-party components don't work as expected. Developers lack sufficient skills and expertise. 

Risk management is (a common practice in other disciplines but almost mandatory during software projects because of the high risk of most software projects. Unique, innovative, people- and communication-intensive, ) frequently used in other disciplines but especially important in s/w eng project management because all software projects are unique undertakings. Successful projects have effective techniques regularly identify and mitigate risks throughout a project.  Risk management is a widely used technique for identifying risks and taking actions to prevent risks from becoming problems and being prepared to minimize consequence of risks that do become problems.