Abstract
Unfortunately, many people using risk management do not fully understand basic risk concepts and therefore utilize incorrect techniques in preparing and implementing risk management plans. The authors have reviewed and critiqued client risk management process and procedures, along with risk management plans for projects, and the same mistakes reoccur on a regular basis.
Based on these reviews, this paper presents the top ten mistakes people make in dealing with project risks and how these mistakes greatly reduce the value of risk management. Both authors have also done numerous projects where risk management was successfully used, and this paper will also discuss effective risk techniques that should be used on all projects. If you think you know how to deal with project risks, read this paper to see if you are making any of these common errors. You may be surprised!
Introduction and Basic Definitions
When the word risk is used in casual conversation it invariably has a negative connotation: risk is bad and should be avoided whenever possible. The Merriam-Webster online dictionary reinforces this negative connotation by defining risk as the possibility of loss or injury, or someone or something that creates or suggests a hazard. However, for project management risk has a less threatening and more realistic definition as “any uncertain event or condition that, if it occurs, has a positive or negative effect on a project's objectives” (PMI, 2004, p. 438). In this expanded scope of understanding, risk is associated with uncertainty—the possibility that things will not go as planned due to uncertain risk events, which can have good or bad impacts on the project.
Risk management includes the processes of identifying potential project risks, analyzing risks, planning responses to the most important project risks, and also monitoring and controlling risks over the life of the project (PMI, 2004, p. 273). The goal of risk management is to maximize the effects of potential opportunities, and minimize or eliminate the threats to the project objectives.
Risk Management Process
Before exploring the common mistakes made in dealing with risks, let's review the suggested process steps for managing project risks. This will ensure a common understanding of the sequential actions that should be followed when dealing with risks. Here are the processes done as part of risk management:
- Prepare a Risk Management Plan: This should be completed early in the project planning phase. First decide if risk management is needed. On some small, simple projects it may not be value adding. But for most projects, risk management is needed. The risk management plan should document the techniques, tools and responsibilities for risk identification, risk analysis, risk response planning and risk monitoring and control.
- Identify the Project Risks: The most commonly used techniques are brainstorming and checklists. As part of risk identification also identify any triggering events for each risk.
- Analyze the Project Risks: The simplest technique is assigning a value for the probability and impact of each risk and calculating the risk factor. The risks are then prioritized and the highest scores are the threats and opportunities that should be actively managed as part of risk response planning. On larger projects advanced risk analysis using quantitative techniques such as Monte Carlo analysis may be appropriate.
- Plan Responses for Project Risks: The project team should decide on actions to be taken to deal with the threats and opportunities. The responses should include the actions to be taken to deal with the risk event before it may happen, along with contingency plans that will be implemented if the risk event happens.
- Monitor and Control Risks: Managing risks is an ongoing process over the entire life of the project. This includes identifying any new risks.
The Top 10 Mistakes in Managing Project Risks
Listed below are the top 10 mistakes people make with risk management. As noted, this is based on consulting work with numerous clients. The list covers the mistakes in sequential order when doing risk management on a project, and is not intended to be a prioritized list of mistakes. Here are the top 10 risk mistakes made on projects:
1. Not considering opportunities
2. Confusing risk causes, events, and impacts
3. Using checklists and not looking for other possible risk events
4. Underestimating impacts
5. Not using 100% probability during project planning
6. Not considering sensitivity with risks
7. Calling risk response planning mitigation
8. Not considering contingency plans along with response plans
9. Not making team members responsible for specific risk events
10. Not making risk management an on-going process
The rest of this paper will cover each risk mistake in more detail, along with effective risk techniques that should be used on all projects.
Mistake #1: Not Considering Opportunities
The problem is that project managers are human, and, therefore, are programmed by society to associate risk with bad things. Project managers may receive training and read articles and/or books on risk management, but most still ignore the possibility that something good might happen as a result of a risk event. However, to be a successful project manager, you need to deal with all project risks, and using the simple definition below will help you focus on both good and bad risk events:
PROJECT RISKS = OPPORTUNITIES + THREATS
Therefore, there are two kinds of risks to consider on projects—threats and opportunities. Threats are easier to grasp because when they occur there is a negative impact on the project objectives. An opportunity is a risk event that when it occurs results in a favorable or advantageous impact on project objectives. Dealing with major threats obviously needs to be done on projects, but don't forget to consider and take advantage of opportunities. Many people have a difficult time thinking of project opportunities, so here are some examples from recent projects:
- Special pricing offered by a supplier
- Competitive market conditions for a specific service
- Sudden availability of a key resource for a short time period due to their project being postponed
- Availability of some needed equipment (such as servers or desktop computers) from another company that is downsizing their operations
- Availability of a government investment tax credit for work done before a specified date.
Most project managers develop plans to deal with threats, but, unfortunately, very few plan for opportunities. “Why bother?” some project managers might ask. “Why not just wait and enjoy it if something good happens?” Project managers should bother because opportunity planning will let you take advantage of these opportunities. How many times have you heard about “lost opportunities”? They will all be lost if specific plans are not developed to make the opportunities reality. The PMBOK® Guide (PMI, 2004, pp. 304-305) lists four risk response strategies for opportunities (also called positive risks):
- Exploit—Take steps to make sure the opportunity happens.
- Share—Pass the opportunity on to another group that is better positioned to take advantage of it for the benefit of the project.
- Enhance—Take steps to increase the probability and/or the positive impact of the opportunity. Note that increasing the probability and/or impact values increases the risk factor value.
- Accept—Take no steps to actively pursue the opportunity, but take advantage of it if it happens.
Let's look at an example for each of these response strategies, and how the identification and planning for a specific opportunity might look:
- Exploit: Your resource plan includes adding Cindy, a talented senior developer, starting in January, when her work on another project will finish. It's now early November, and you find out the other project has been cancelled. Looking at your schedule, you realize changing the sequencing of some project work will allow you to utilize Cindy now and save three weeks in your project schedule. You contact the resource manager and request Cindy be immediately reassigned to your project. Reworking your schedule and immediately requesting Cindy is exploiting the opportunity created by the cancellation of the other project.
- Share: During the planning phase for your laboratory renovation project, you discover a new flexible piping technology that can reduce service piping installation time for the lab benches by 30% with minimal cost impact. You preliminary plan is based on using an internal maintenance group for the piping work. However, they don't have the knowledge and experience in working with the flexible piping technology. Because the lab bench piping is on the critical path and the client sponsor wants to improve the end date, you decide to outsource this work to a contractor with expertise in flexible piping systems, and release the internal maintenance group for work on other projects. This is a share since you are taking advantage of the opportunity (using flexible piping) to shorten the schedule, and the contractor is making a profit on the work.
- Enhance: Your company has been selected as the painting contractor for a bridge renovation project. The project specification calls for a paint with a 15-year life. However, your company has developed a new epoxy paint that will last 30 years or more, and it only costs 30% more than the standard paint (but has a higher profit margin since it is a proprietary product of your company). You notify the project manager, Susan, of this opportunity. She likes the added value, but the state Department of Transportation (DOT) Director will have to approve the change. Susan suggests a meeting with the DOT project engineer, Jim, to discuss the benefits and enlist his support in getting the change approved. Susan is confident that Jim will support the scope change and help obtain the necessary approval within the DOT. This is an opportunity for the project because the better paint will last substantially longer, plus an opportunity for the painting contractor to earn some extra profit. The action of meeting with Jim and getting his support increases the probability of the scope change being approved.
- Accept: The testing team leader informs you there is a chance the integration testing on your software development project will not take as long as the plan shows, but the probability is low and best case it might save up to one week for the one-year project. You decide to record the opportunity in the risk register, but take no other actions at this time since the impact to the project is minimal.
Mistake #2: Confusing Risk Causes, Events, and Impacts
The first step taken by a team in implementing the risk management plan is risk identification, which is determining which risks may affect the project and understanding the characteristics of each specific risk event. Common tools used by many project teams for risk identification are checklists and brainstorming, along with interviews of key project stakeholders. However, a common error during risk identification is not differentiating between risk causes, risk events, and impacts. This failure can dilute the risk identification process by not providing a focus on actual risk events and this is important because risk events have one unique feature, and that is uncertainty!
A risk cause is a definite event or circumstance that exists. A cause is a fact and has no uncertainty. For example, multiple job opportunities for topnotch programmers due to a shortage of computer programmers in the region would be a risk cause.
Risk events are simply things they may or may not happen because of the risk cause being present. An example of a risk event would be losing one or more key software programmers to another software company who offers them more money.
Risk impacts are the results that will occur if the risk event happens. For the example above, if a key software programmer leaves for a higher paying job, it probably will have an impact on the project cost and schedule.
An effective risk identification technique is expressing each project risk as a sentence. Your sentence should include the cause, risk event, and impact as shown below (Hillson, 2000):
Due to <cause>, <risk event> could occur, resulting in <impact>.
Note that a risk event may have more than one cause, and more than one impact. This technique can be used to fully describe each identified project risk, and is an effective method to help keep the project team focused on the actual risk events.
One tool that can be useful during brainstorming sessions is the use of Post-It notes as shown in Exhibit 1. A separate sheet of chart paper is used to list risk causes. The post-it note format has the risk event description in the center, and the cause numbers listed on the left. The four possible impacts are listed on the right side of the post-it note and the applicable impacts are circled. Risk categories can be added at the top, and the Post-It note is also used for risk analysis, with values assigned for probability and impact, and the calculated risk factor. This format has been successfully used on numerous projects.
Exhibit 1 – Effective Risk Identification Tool
Mistake #3: Using Checklists and Not Looking for Other Possible Risks
Many organizations do similar projects over and over. Examples include a civil engineering company specializing in road construction, or an IT team that only does data migration projects. Most of the risk events will be the same from project to project, and in these situations the use of a risk checklist makes sense. The problem with this approach is complacency—making the false assumption that the only possible risk events will be included in the checklist. The checklist can certainly be a good place to start, provided it is not the only thing done to identify risks. Your team also needs to “scan the horizon” to identify any other possible risk events not on the checklist that may impact the project. For example, the civil engineering company may have an excellent risk checklist, but the company is awarded a new project and the road will cross an old abandoned landfill. This will undoubtedly create some unique risk events for this new project that are not currently on the checklist.
To initially develop the checklist for group of similar projects, get some experienced project managers together and brainstorm the risk events they have encountered on their projects. The checklist should be considered a dynamic document, and as previously unidentified risk events occur on other projects, these risks should be added to the checklist. The lesson learned sessions done at project completion is also a good place to identify new risk events that should be added to the risk checklist. The project management office (PMO) should have responsibility for maintaining the template checklist.
When using checklists, it can be helpful to segregate the risks into categories. The exact grouping will depend on the needs of the organization. One set of categories frequently used is by project phase: initiation, planning, design, build, test, and deployment. For the civil engineering company doing road construction, a grouping that could be used is design, government/regulatory, contractor, suppliers and weather. Some teams have used the categories of cost, schedule, quality and functionality to organize their risks. This isn't a good idea, however, since these four categories are also the risk impacts, and many risk events will have more than one impact. What that means is that if you try using this set of categories you won't be able to easily place risk events with multiple impacts into a single category.
As previously discussed, a risk checklist is not inherently a bad thing, but you must make sure the identification of any additional risks is done in conjunction with use of the checklist. Use brainstorming to find new risks. One technique is to award a simple “prize” such as a car wash or movie ticket to the team member who identifies the most new risk events not already on the checklist.
Mistake #4: Underestimating Impacts
One area that some project teams struggle with is underestimating the impacts of risk events. This may be due to the optimistic nature of project teams—especially early in the project. When the impacts are understated the risk factor calculations become skewed, the prioritization becomes flawed, and the entire risk management process is threatened.
There are four possible consequences for any risk event: cost, schedule functionality, and quality. Each needs to be considered when deciding the risk impact value. However, it's also important to prioritize these impacts based on what's most important for the project. In some cases it may be a specific end date that must be met due to a government regulation, or maybe a fixed budget that cannot be exceeded. If the most important driver for a project is meeting a completion date, then a risk event that will delay the completion date should be assigned a bigger impact value compared to a risk event that just impacts cost.
Shown in Exhibit 2 (Lukas, 2001, p. 5) is the impact table for a specific software development project. For this project the budget was fixed and was the most important project driver—the budget could not be exceeded. Functionality and quality were secondary drivers, and if the budget was in jeopardy, functionality reductions could be considered. Schedule was least important, since the company had existing software in use and could continue using the software if the completion date slipped. Let's consider a sample risk event that has a cost impact score of 8, a schedule impact value of 0, and impact scores of 4 for functionality and quality. The obvious question is what impact value would the project team use for this risk event? Is it the average of the four impact scores, which would be 4? The answer is no! The correct method is using the highest value for the impact score. In this case that value is 8, which is the cost impact score.
Exhibit 2 – Project Impact Table for a Sample Software Project
Be careful when discussing prioritization of project drivers with clients. The answer you'll frequently here is that everything is equally important! That's an easy answer but most often not really true. If a client has a project with a fixed end date that MUST be met, cost is probably not as much a consideration. It may still be important—but not as much as schedule. A perfect example of this is the year 2000 projects (Y2K). There was a definite end date of December 31, 1999 and for clients that was the project driver.
Mistake #5: Not Using 100% Probability during Project Planning
At the beginning of this paper a risk event was defined as having uncertainty, so it may be confusing now stating that a risk event can have 100% probability during project planning. One hundred percent probability means no uncertainty—therefore it's a fact. This is not a conundrum because before completion of project planning you will take actions to deal with some of the project risks, and these actions should reduce the risk event probability below 100%. Project execution cannot begin with risk events that have a probability of 100% because they are facts and the project plan must be prepared to deal with these facts.
However, giving a risk event a probability of 100% during project planning will obviously call lots of attention to that risk event provided it also has a high impact—and that will either result in actions taken to reduce the probability and/or impact to a lower value, or constructing the project plan to deal with the 100% reality.
An actual project example is a customized software development project for use at company manufacturing locations around the world. Business was good and the manufacturing areas were extremely busy. The project manager correctly realized a major risk event would be having incomplete project requirements due to his inability to get the manufacturing representatives to take time to meet and adequately explain their requirements. Incomplete requirements would probably result in a solution design that didn't meet all of the manufacturing plant needs. The project manager gave the risk of incomplete requirements a probability of 100% and informed the project sponsor the project would fail unless this risk was dealt with during project planning. A risk response plan was developed and implemented for this risk. The actions taken included a comprehensive schedule and resource plan for the requirements document deliverable, listing the specific people at each plant site needed for requirements definition, and the dates of the planned meetings to define requirements. The actions also included a contingency plan where if a person missed a meeting, the project sponsor was immediately notified and the sponsor contacted the appropriate plant manager to resolve the problem. By the time the project planning phase was completed, the risk probability of having missed requirements dropped from 100% down to around 30%.
A final caution—don't overuse the 100% probability approach. It should only be used where the risk really will happen unless actions are taken and the impacts are major. Otherwise, you run the risk of losing credibility.
Mistake #6: Not Considering Sensitivity with Risk Analysis
The simplest technique for qualitative risk analysis is assigning a value for the probability and impact of each risk and calculating the risk factor. The risks are then prioritized and the highest scores are the threats and opportunities that should be actively managed as part of risk response planning. This simplified approach ignores the sensitivity around the probability and impact values. In reality, these are not fixed values, but are a range of values.
On smaller projects qualitative risk analysis is usually “good enough.” However, on larger projects advanced risk analysis using quantitative techniques such as Monte Carlo analysis should be considered. Monte Carlo is a risk simulation technique, and can help better understand the project risk events. With risk simulation, when discussing the probability and impact of a risk event, instead of a single value being identified there is a most likely value, along with an optimistic and pessimistic value. Risk simulation software can show the frequency of possible outcomes and a cumulative cost and/or schedule with overrun probabilities.
Mistake #7: Calling Risk Response Planning “Mitigation”
A common mistake made by many project organizations is calling risk response planning “mitigation.” That is incorrect, since mitigation is just one risk response technique and is specifically used for dealing with risks that are threats. Another term often used to describe risk response planning is “risk management plan,” and that's also incorrect since that is part of the project plan and describes what the team will do to manage risks on the project. One final term that should not be used to describe risk response planning is “risk assessment,” which more correctly means identifying and analyzing risks—but the recommendation is to avoid use of this term.
The product of risk management is called the risk register and it includes the list of identified risk, the risk analysis results and the risk response plans including contingency plans. The correct term to use for describing what steps will be taken to deal with risks is “risk response plan.”
When risk mistake #1 was discussed, the commonly used risk responses for opportunities were described. Listed below are the common risk responses for threats:
- Mitigation: This response seeks to reduce the probability and/or impact of a negative risk event. An example of mitigation is offering a performance bonus to a key project resource to mitigate the potential of the person leaving the company before project completion. The performance bonus reduces the probability of the person leaving.
- Avoidance: This response looks to eliminate the threat by taking actions to cause the risk to go away completely. This is usually done by eliminating the causes. When you avoid, the risk is gone! There is no need to do any contingency planning, because the risk no longer exists. An example of avoidance is a developer looking to build a new store decides not to build in a certain town due to a hostile town board, which probably will hold up the zoning approval.
- Transference: This response shifts some or all of the threat to a third party. The risk doesn't go away, but the ownership and impact of the risk belongs to somebody else. An example of transference is using a firm fixed price contract with a vendor for the data migration work on a software project. This provides the project team with a known cost, and the threat of a cost overrun belongs to the vendor (along with the opportunity to complete the work for less money and make more profit).
- Acceptance: This response is deciding not to do anything about the risk. This may be because no other actions are feasible, or the risk factor isn't significant. The response can be active acceptance, which means developing a contingency plan if the risk event occurs. An example is building a new store in upstate New York in January. It will snow—so active acceptance is the best approach. You can't control the weather!
In summary, mitigation is just one risk response technique, and it is specifically used for threats. Do not call risk response planning “mitigation”—the correct term to use for describing what steps will be taken to deal with risks is “risk response plan.”
Mistake #8: Not Considering Contingency Plans along with Response Plans
As mentioned with mistake #7, the correct term to use for describing what steps will be taken to deal with risks is “risk response plan,” but don't forget that should also include a contingency plan! To clarify the difference, the risk response are actions taken before the risk event occurs to make the risk event more likely to happen for opportunities and less likely to happen for threats. Contingency plans are more specifically the actions that will be taken if and when the risk event occurs. Risk response planning should deal with both!
Let's revisit the common risk responses for threats covered in mistake #7. The mitigation example was losing a key project resource due to the person leaving the company. The contingency plan for this example would be identifying a back-up resource (either internal or a contractor) that could step in and handle the work if the person does leave the company. For the acceptance example of building a store in upstate New York in winter weather, contingency planning could be adding some extra days in the schedule as an allowance for non-working days due to snow, and/or including money in the budget for plastic sheeting and space heaters so work can continue even if snow occurs.
One final comment is that not all risks need a contingency plan! The example used for transference was using a firm fixed price contract with a vendor for the data migration work on a software project. The risk impact now belongs to the vendor so the project team doesn't need to worry about a cost overrun. The example used for avoidance was a developer looking to build a new store deciding not to build in a certain town due to a hostile town board. Because the decision was made not to build in the town with a hostile town board, the risk no longer exists. In both cases a contingency plan is not pertinent.
Mistake #9: Not Making Team Members Responsible for Specific Risks
One observation is that some project managers are not effective at delegating work, and end up taking responsibility where other team members could be used. Part of risk response planning is assigning ownership of each risk to an individual. Assign each risk to a specific individual on the project team, and the project manager should avoid assigning risks to her/himself. The assigned person should implement the risk response plans, monitor the risk, and report on the risk status. Assign each risk to the team member who has the particular skills related to the risk. For example, a risk concerning the requirements elicitation work on a software project should be assigned to a business analyst, while a metallurgy risk on a construction project should be handled by an engineer.
Mistake #10: Not Making Risk Management an On-going Process
Unfortunately, some project managers think of risk management as a task that is started and completed as part of project planning. The risk register is completed and then filed away and forgotten. This is the mistake—a risk management review should be part of every project team meeting! Shown in Exhibit 3 is a sample risk register, which is a simple worksheet.
Exhibit 3 – Risk Register Example
For each risk event, the responsible team member should provide a brief status report on the risk response actions taken and/or planned, along with changes to the probability and/or impact values based on actions taken. The project team should also discuss if any risk triggers have occurred, and whether any new potential risk events have surfaced since the last meeting. The key point is that risk management is an on-going process over the entire life of the project! For the project manager, watch for certain phrases that appear in people's conversation, such as “there is a chance that…” or “maybe this would cause problems…” When you hear words like that, ask for clarification, and it may become apparent that this is a new risk event and should be added to the risk register.
Conclusion
Many people using risk management utilize incorrect techniques in preparing and implementing risk management plans. This paper has covered the top 10 mistakes people make in dealing with project risks and how these mistakes greatly reduce the value of risk management. Check how you are doing risk management on your projects and see if you are making any of these common errors. You may be surprised!
