"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.
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.
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.
The flow chart in figure x below illustrates the risk management process. The risk management process incorporates the familiar control cycle:
Plan - determine what to do and how to do it
Execute - do it
Monitor - compare actual performance with planned performance
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.
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:
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.
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.
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.
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:
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
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|
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:
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
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.
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
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.
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.
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|
|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:
events. You may want to give higher priority to catastrophic events. Because of the way
risk exposure is
calculated, a very serious risk may have a lower priority (risk exposure
value) than a risk with moderate values of probability and loss. This is
statistically correct because over time the risk with moderate probability
and moderate loss will occur more often than one with low probability and
However, this is of little consequence if the serious risk occurs
early and wipes out the project. Some risks are so damaging it may make sense
to give them priority over other risks that may cause a greater aggregate
loss but aren't so destructive in one incident. For example, considering the
risks in table x above, the project manager may want to raise the priority
of the 5th risk, "Forget to remove seeded bugs from final
product." It is very unlikely to occur but the damage to the product
and the reputation of the team would be so devastating it probably warrants a
Compound risks. Sorting risks by risk
exposure assumes risks are independent events when they may in
fact be related. Talking on a cell phone while driving increases your risk
of having an accident as does eating while driving. Individually the risks
for each of these activities might be acceptable, but if you don't recognize
that the risk of doing both at the same time is greater than the sum of each
individual risk, you might feel it's OK to talk on a cell phone, eat and
drive all at the same time.
Risks 2 and 3 in table x above are compound risks. A compressed schedule makes it more difficult to deal with expanding requirements and expanding requirements makes it more difficult to deal with a compressed schedule. These risks should be combined into a risk with a larger risk exposure or reevaluated considering the increased risk of dependent events.
Confidence in estimates. The analysis
techniques recommended in the previous step are meant to support informed
decision making not replace it. If the priorities from risk analysis don't
match your intuition it's reasonable to question the analysis as much as
your own intuition. The results of risk analysis are based on estimates
for probability and loss. Inaccurate estimates will lead to inaccurate
In the list of risks in table x above, "Poor work environment" is ranked 4th. An experienced project manager may question this result and decide it deserves a higher priority.
Output of the prioritize risks step is a prioritized list of risks in the order they should be considered for treatment.
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:
Action plans - plans for avoiding or reducing identified risks.
Contingency plans - plans for responding to identified risks that become problems.
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:
Risk Avoidance. Risk avoidance is changing behavior or project requirements to avoid a risk. This usually has the effect of trading one risk for another with lower risk exposure. For example, if using a new programming language on a project is perceived as a risk, the risk can be avoided simply by using a more familiar language. This may introduce additional risks such as reduced portability or longevity for the application.
Risk Transfer. Risk transfer is getting someone else to assume the consequences of the risk. When using risk transfer make sure both authority over the risk and responsibility for the risk are transferred together. You can lock valuables in a hotel safe but it's not risk transfer if there is a sign above the safe that reads, "not responsible for lost or stolen items." Most forms of risk transfer require the payment of a risk premium. Insurance is the most common form of risk transfer.
Risk Mitigation. Risk mitigation seeks to reduce the probability and/or impact of a risk. Risk mitigation results in action plans that will be implemented and tracked.
Risk Acceptance. When a risk can't be avoided, transferred, or mitigated, risk acceptance may be the only other alternative. Risk acceptance is the best option when treating the risk isn't cost effective. Risk acceptance may include the development of a contingency plan to be used if the risk does become a problem. A contingency plan should include a tracking plan and specific quantitative measures or thresholds for detecting when the contingency plan is needed.
Buy information. Buying information is a way of reducing risk by reducing uncertainty. When risk is caused by a lack of information, there may be an opportunity to reduce the risk by gathering more information about the risk. For example, if the risk is vague requirements, investing time and money in creating a prototype may be the best way to reduce the uncertainty inherent in the risk. Creating a prototype may also reduce the probability of the risk becoming a problem.
Table x below shows an example of each of these 5 strategies being applied to the risk of misunderstanding user requirements.
|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
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.
|Unrealistic schedules and budgets||
|Underestimate amount of work||
|Excessive changes to requirements||
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.
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|
|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:
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:
Risk Management Plan
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.
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.
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.