It works! Risk management on an IS project
Risk management is the process of identifying potential project risks, assessing the probability and severity of risk events, and planning responses for the most important risk events. People tend to relate only negative events to the term risk. However, risk includes all uncertainty on a project and includes both the positive (opportunities) and negatives (threats).
This paper describes the successful use of risk management on an information systems (IS) project to create a new capital management system (CMS) for a Fortune 500 company. This IS project was done to create a new, customized intranet-based software package that will be used for managing the capital budget and expenditures for the company. The client sponsor's most important project objective was completing the project within budget, followed by functionality and then schedule. The presentation will describe how risk management was a major part of the detailed project plan and helped ensure project success.
This paper explains the specific risk identification technique used by the project team. Each project risk was described using a standard sentence format describing the cause, risk event and consequence. The team then used qualitative risk analysis to better understand the potential of each risk event. The scales used to assign a value for probability and risk impact for each risk event will be reviewed. Using these numbers, an expected value was calculated to determine which risk events warranted specific risk response planning.
The presentation will cover risk response planning, which was done as part of the project plan. For all major risks, mitigation plans were prepared to reduce the likelihood of threats and to maximize the likelihood of opportunities. Contingency plans were also prepared for the major risks. The spreadsheets developed on this project to document the risk processes used will be reviewed. The talk will conclude with a discussion on the use of risk monitoring and control on the project. This included a status review of all risk events as part of the weekly project team meeting. The talk will provide ideas on how to apply risk management to your projects!
This IS project provided a new customized intranet-based software package to manage the capital budget and expenditures for a Fortune 500 company with multiple manufacturing plants around the world. Capital projects include things such as new manufacturing facilities, upgrades to production equipment, new or renovated office areas, and storage facilities.
The business case for the new CMS software was productivity savings in managing the capital budget for the company. CMS replaced over ten obsolete systems in use at various plant sites. These legacy systems were only accessible by a few administrative personnel, did not interface with each other and used old software that was no longer supported. In addition, the legacy systems did not provide online access to project information for most users and had very limited reporting capability.
The new CMS software provides about 200 data fields for each capital project including project description, justification category, business case data, budgets, actual costs, key schedule dates, project team members, project status and project performance measures. Actual projects costs are uploaded from existing cost systems used at the various plant sites. The software also provides summary level information that can be rolled up by business unit or plant site. CMS includes standard reports that can be run by project, by business unit, plant site or rolled up for the entire company. The system includes various levels of security to limit access to project data, and provides the ability to search the database for multiple selected criteria (such as for a specific justification category like capitalized maintenance projects being planned for the next year).
The resource plan for this IS project was contracting design and programming to a software vendor. The project team was lead by an experienced IS project manager from the client company. The team also included the database manager and a few key users of the existing capital budget systems. Once the software contractor was selected during project requirements definition, the team was expanded to include the contractor project manager and a lead technical consultant. Once the project was fully defined and approved, the contractor finalized the project price and added programmers to the project team. An experienced project management coach with an extensive background in the use of risk management and earned value assisted the team from project initiation to completion.
The Risk Management Process
Risk is a frequent occurrence in all aspects of our lives. People tend to relate only negative events to the term risk. However, risk includes all uncertainty on a project, both the positive and the negative. Risk management is the process of identifying potential project risks, assessing the probability and severity of risk events, and planning responses to the most important project risks. The goal of risk management is to identify all project risks and develop strategies to maximize the effects of potential opportunities and significantly reduce or eliminate the potential impact of threats.
Exhibit 1. Identified Risks on the CMS Project
Companies that consistently excel in project delivery, typically have a well-documented project process in use, which includes risk management. An excellent reference on the project risk management process is A Guide to the Project Management Body of Knowledge (PMBOK® Guide), published by the Project Management Institute.
The material presented in this article is consistent with the PMBOK® Guide, which describes the generally accepted project management knowledge. However, generally accepted doesn't mean that the knowledge and practices should be uniformly applied on all projects. The project team is responsible for determining the appropriate tools and techniques to apply on a project. For example, the risk management plan for construction of a multibillion-dollar chemical plant would be more extensive than the risk management plan for a simple office renovation. The risk management processes are as follows:
• Risk Management Planning. Deciding how to approach and plan the risk management activities for the project.
• Risk identification. Determining which risks may affect the project and understanding the characteristics of the risk events.
• Risk analysis. Using qualitative and/or quantitative techniques to understand the probability and severity of each risk event, in order to prioritize the risk events based on impacts to the project objectives.
• Risk response planning. Determining actions that the project team can take for each major risk event, in order to maximize any opportunities and minimize threats to the project objectives.
• Risk monitoring and control. Keeping track of major potential risks, implementing the risk response plan when risk events do occur, and watching for any new risks.
Risk identification involves information-gathering techniques that determine which risks may affect the project and the characteristics of each risk event. Risk characteristics include the possible frequency of the risk event, the range of outcomes, the type of risk, impacts if the risk event occurs and symptoms of the risk event. Many different techniques are available for identification of project risks. These include the following:
Brainstorming. The free flow of ideas used to generate a listing of potential risk events. The key to brainstorming is to not prejudge any idea until after completion of the brainstorming session. Phrases to avoid during brainstorming include: “that can't happen” and “what a dumb idea.”
Checklists. A listing of risk events typically encountered for a specific type or class of projects. The project team reviews the checklist when starting a new project to identify specific risk events that may occur. Checklists can be organized by project phase, major deliverables or by impacts to the project.
Interviews. Discussions with project team members and other stakeholders can help identify risks not identified during normal planning activities. A good source of risk information is from people who have done similar projects in the past.
Flowcharting. Diagramming techniques displaying how various elements of a project are related. This illustrates how risk events and causes relate to create potential risk impacts and help the team better understand causes and effects of risks.
Identifying Risks on the CMS Project
To help the CMS project team focus on risk events, a technique was used to describe each risk by listing the risk cause, risk event, and consequence. This technique was introduced in an excellent article titled “Project Risks, Identifying Causes, Risks and Effects” by David Hillson, PMP. This article was published in the September 2000 issue of PM Network.
A common error during risk identification is not differentiating between risk causes, risk events, and consequences (also called impacts or effects). This failure can dilute the risk identification process by not providing focus on actual risk events. Risk events have one unique feature, and that is uncertainty!
A risk cause is a definite event or circumstance that exists. For example, purchasing a special piece of equipment from a foreign supplier would be a risk cause if the only alternative were buying the equipment from the foreign supplier due to patents. The risk event could be exchange rate fluctuations or poor communications due to language barriers.
The consequences are the results that will occur if the risk event happens. For the example above, if the exchange rate does fluctuate, it will have an impact on the project cost. Keep in mind this impact could be favorable! If the foreign currency drops relative to the U.S. dollar, this becomes an opportunity for the project team.
A good technique to use when doing risk identification is to express each project risk as a sentence covering the cause, risk event, and consequence. A suggested format is: “Due to <cause>, <risk event> could occur, resulting in <consequence>”
An example would be “Due to purchase of the equipment from an overseas vendor, exchange rate fluctuations could occur, resulting in a cost impact to the project budget.” Another example would be “Due to sharing a senior programmer between two projects, a work overload could occur, resulting in a schedule delay on one or both projects.”
The CMS project team used this technique to identify potential risk events. A brainstorming session was held with the entire team, and a listing of risk events was developed. Then the team used the risk cause, risk event, and consequence technique to fully describe each risk. For example, in Exhibit 1 Risk #3 reads: “Due to the database manager having multiple jobs, missing key project requirements could occur, resulting in a lack of needed functionality with the new system.” Risk #1 reads: “Due to the many job opportunities for top-notch programmers, the loss of key project personnel could occur, resulting in higher costs and a longer schedule.” In order to keep the Exhibit 1 to a reasonable size, not all identified risks on the CMS project are listed.
Qualitative Risk Analysis on the CMS Project
Once the risk identification process was completed, the project team used a qualitative risk analysis process to understand the likelihood (probability) and consequence (severity or impact) of each risk event. This was done to identify those risks that required risk response planning. The technique the team used is from the PMBOK® Guide, and also from an excellent article titled “Qualitative Risk Assessment” by Roger Graves. This article was published in the October 2000 issue of PM Network.
Exhibit 2. Risk Probability Scale Used by the CMS Team to Determine for Each Project Risk the Level of Probability
For the CMS project, the team decided on a simple probability scale as detailed in Exhibit 2.
Impact (Consequences) Scale
Basically, there are only four possible consequences to any risk event on any project. They are cost, schedule, quality and/or functionality impacts. In this definition, quality can cover a variety of miscellaneous impacts, including how well the product works and safety. On any project, it is vital for the project team to understand what is most important to the client. This is essential knowledge so the team can accurately access the impact of any risk event on the project. For example, if schedule is not critical to the client, then a risk event with a schedule impact would have a lower impact rating.
On the CMS project money was limited, so the most critical impact was cost. The team needed to complete the project within or below the allocated budget. Functionality and quality were second in importance, since it was necessary to provide the data fields and information needed by Project Managers and management. Also, the system had to be user friendly to ensure it was accepted and used. Schedule was the least important driver. The desire was to implement CMS in January 2002 since that was the time period of lowest system use. However, a delay was not a significant problem since the legacy systems could continue to be used until the new system got up and running.
For the CMS project, the team used a simple consequence (impact) scale as detailed in Exhibit 3. The highest impact value is chosen if any of the criteria is met for that value. For example, if the risk event had a very high cost impact, the impact value was a 10 even if there were no functionality, quality or schedule issues.
Calculating Expected Value for Each Risk
Each identified risk event on the CMS project was assigned a probability and impact value using the Exhibits 2 and 3. An expected value was then calculated for each risk event using the following formula:
Expected Value (EV) = Probability x Impact Rating
Expected value provides a scale to assess the importance of each risk event relative to other risk events. Using the probability and impact scales defined by the CMS project team, the maximum expected value a risk event could have is 10 (1.0 probability x 10 impact). The CMS project team decided that risk events with an expected value over 5.0 warranted specific risk response planning, and risk events below 5.0 deserved watching, but not necessarily specific action. Exhibit 4 shows the assigned probability, impact and expected value for each risk event on the CMS project. For simplicity, not all identified risk events on the CMS project are shown in Exhibit 4.
Exhibit 3. Project Impact Scale Used on the CMS Project Shows That Schedule Was not a Major Project Driver
Exhibit 4. The CMS Project Risks Expected Values Helped Team Members Focus on the Most Important Risks
Risk Response Planning
Risk response planning is the process of developing plans and actions to respond to specific risk events. The effectiveness of risk response planning will greatly influence how much the risk level decreases as the project continues. The risk response techniques commonly used are described below.
Avoidance is changing the project plan to eliminate either the risk event or the impact. However, keep in mind that the project team can never eliminate all risk events! An example of avoidance is adopting a familiar approach instead of a new and untried innovative approach. Another example of avoidance is selecting a site for a new shopping mall in a town with a friendly town planning board where quick approval of building plans occur.
Transference is shifting the risk event impact to a third party along with ownership of the risk response. Transferring the risk simply gives another party responsibility for the risk but the risk isn't eliminated. Transference is most effective in dealing with financial risk exposure. However, risk transfer almost always involves payment of a risk premium to the party taking on the risk. Examples of transference include insurance, warranties and fixed price contracts.
Mitigation is reducing the expected value of a risk event by reducing the probability of occurrence and/or the risk event value. It looks to change conditions so that the probability of the risk event occurring is reduced.
An example of mitigation to prevent missing a schedule completion date is adding more resources. Mitigation also looks to reduce the risk impact. An example of this is airplanes that have redundant hydraulic systems to greatly reduce the impact of a failure of any one hydraulic system.
Acceptance as a risk response technique is where the project team has decided not to change the project plan to deal with the risk—or more likely, is unable to identify any other suitable response strategy. Acceptance can be either passive or active. The active acceptance response is developing a contingency plan in case the risk event occurs. An example of active acceptance is developing an alternative schedule plan to deal with late delivery of key equipment. The passive acceptance response would be doing nothing until the risk event occurs.
Exhibit 5. Sample Mitigation and Contingency Plans on the CMS Project
Risk Response Planning on the CMS Project
Exhibit 5 shows the risk planning worksheet used by the CMS project team for some representative risk events. Exhibit 5 only shows a few representative examples from the CMS project.
Mitigation was the biggest response technique used by the CMS team, and this technique looks to reduce the expected value of the risk event by reducing either or both the probability and impact. It makes sense that if a risk has high likelihood of occurring, the team won't just sit idle, but will try to intervene to reduce the probability of the risk event. Likewise, if the consequences of the risk event are high, the team will look for methods to reduce the impact. In addition to mitigation planning, the project team also considered contingency plans in case the risk event did occur. This allows a team to quickly respond to any risk event that does occur. The spreadsheet in Exhibit 5 includes columns for mitigation and contingency plans, along with columns for responsible person and status. The project team reviewed the risk spreadsheet at the weekly team meetings.
Risk Response Monitoring and Control
Note that probability and impact are not fixed during the project life! As the project team implements actions to mitigate risk probabilities and impacts, the associated values should drop. This means the expected value should also decrease, reducing the overall risk level on the project.
For example, in Exhibit 5, Risk Event #3 (missing key project requirements) has a high probability and impact. The high probability (0.9) resulted from the database manager holding multiple jobs. The mitigation plan was getting management commitment to dedicate the database manager to the CMS project and finding another person to pick up her other job responsibilities. Once this happened, the probability dropped from 0.9 down to 0.4. In addition, once the project requirements were totally defined, the impact dropped from 10 down to 4. This means the expected value of Risk Event #3 dropped from 9.0 down to 1.6, which is a very low risk event value. This is the goal of the project team—to reduce the expected value of risks and to increase the expected value of opportunities.
Successful project teams include risk management as part of their project plan. The probability of success on any project is much higher when the project team follows a structured risk management process. On the Capital Management System (CMS) IS project, use of risk management helped ensure successful completion of the project.
Graves, Roger. 2000. Qualitative Risk Assessment. PM Network (October), pp. 61–66.
Hillson, David. 2000. Project Risks—Identifying Causes, Risks, and Effects. PM Network (September): pp. 48–51.
Lukas, Joseph. 1995. Managing Risks on Capital Projects. AACE Transactions.
Lukas, Joseph. 2001. Manage Project Risks with Success. Inside Project Management (November), pp. 1–5.
McKim, Robert. 1992. Risk Management—Back to Basics. Cost Engineering (December), pp. 7–12.
Project Management Institute Standards Committee. 2000. A Guide to the Project Management Body of Knowledge. PMBOK® Guide. 2000 Edition. Newtown Square, PA: Project Management Institute.
Royer, Paul. 2000. Risk Management: The Undiscovered Dimension of Project Management. PM Network (September), pp. 31–39.
Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio, Texas, USA