INTRODUCTION
Life is full of uncertainty. Project managers call that risk.Consider the following scenarios:
• A Silicon Valley software company subcontracts part of a product development effort to a software shop in Los Angeles. How will the project manager in San Jose make sure the subcontractor produces the right product on time?
• To reduce administration costs and streamline admissions, a hospi- tal is considering reengineering its process for creating and storing patient records. How can hospital administrators accurately esti- mate the cost of the change when they aren’t even sure what the change will entail?
• In the design to build a completely new fighter aircraft, a defense contractor specifies lightweight composite materials. How can the contractor be sure the new materials will hold up under the pres- sures a fighter jet endures?
In these projects, there is uncertainty about the schedule, the costs, and the quality of the end product. How can this uncertainty be man- aged?
Risk managementis the means by which uncertainty is systemati- cally managed to increase the likelihood of meeting project objectives.
The key word is systematic,because the more disciplined the ap- proach, the more we are able to control and reduce the risks. This chapter presents a framework for transforming the uncertainty inher-
T H E P L A N N I N G P R O C E S S
ent in projects into specific risks and developing strategies for manag- ing them.
THE RISK MANAGEMENT ADVANTAGE All projects experience the unexpected; but some project managers are ready for it. Impossible? The language of project risk management explains this phenomenon:
• Known unknownsrepresent identified potential problems, such as the possibility of a strike when a labor contract expires, or enough rain to stall a construction project during winter in Seattle. We don’t know exactlywhat will happen, but we do know it has a potential to damage our project and we can prepare for it.
• Unknown unknownsare the problems that arrive unexpectedly.
These are the ones you honestly couldn’t have seen coming. But seasoned project managers do expect them, because they know something unexpected always happens.
The risk management advantage is that fewer problems catch the project team off guard. For every surprise thunder shower the project manager just happens to have an umbrella handy.
The ability to prepare for and reduce uncertainty is well illustrated within the insurance industry, where risk management has become a sophisticated science. Actuaries are constantly researching the proba- bilities of various calamities, and this research helps them set insur- ance premiums. Not only do insurance companies charge us for assuming risks, they actively try to avoid risks by encouraging their policyholders to avoid risky behavior. Premiums are reduced for non- smokers and for automobile owners with good driving records. The insurers even send representatives into businesses to advise them how to avoid accidents—and reduce the clients’ premiums when they fol- low the advice.
ALL PROJECT MANAGEMENT IS RISK MANAGEMENT
Insurance companies understand and practice risk management bet- ter than most project managers because they realize that it is their pri- mary business. Not many project managers realize that it is also their primary task, but those who do have an edge: They are constantly on the outlook for uncertainty that could lead to project failure.
Risk management is the primary job of a project manager? Yes, it’s true, especially if you look at it this way: Every technique in every chapter of this book is really a risk management technique. Some
R I S K M A N A G E M E N T
techniques reduce the risk of being late. Others reduce the chances of overrunning the budget. A few address the process for ensuring the quality of the end product. And all techniques try to increase the satis- faction of every stakeholder and improve the chances of success.
All project management activities can be construed as managing risk, but the risk management process is a specific set of activities you’ll consciously perform to identify and manage risks on the project.
Like project definition, these are outcomes of the risk management process (see Figure 5.1). Let’s consider the ways in which risk man- agement activities relate to project definition, project planning,and project control.
Definition
The first risks surface as the project is conceived, the business case is constructed, and the goals for cost, schedule, and product scope are developed. Initially, these risks may be listed as assumptions, but as it becomes clear that they represent specific threats, they become the first documented risks.
Planning
Figure 5.1 shows the function of planning as having two major compo- nents: risk managementand schedule and budget development.
Schedule and budget development are the detailed plans required for day-to-day management of the project. Techniques for creating these detailed plans are described in the next three chapters. Risk planning
FIGURE 5.1 Risk management influences the project plan and changes assumptions in the project rules.
All stakeholders authorize the project rules
DEFINITION PLANNING
Risk management
Schedule and budget development
• Statement of work
• Responsibility matrix
• Communication plan
• Project deliverables
• Development approach
• Responsibilities
• Risk monitoring
Changes to: scope, deliv- erables, responsibilities, cost and schedule, communication plan
New risks
T H E P L A N N I N G P R O C E S S
represents the formal, conscious activities of the project manager and team to identify risks and to formulate strategies for managing the risks. It cannot be overemphasized that risk planning happens repeat- edly throughout the project.Risk planning analyzes the project’s deliv- erables, environment, and stakeholders from a critical perspective to find any weaknesses. The project team identifies risks and develops strategies for neutralizing the risks. Those strategies, in turn, will affect the detailed action plan and may require changes to the state- ment of work, responsibility matrix, or communication plan.
Risk management and detailed planning have a symbiotic relation- ship and are iterated two to four times before project execution begins. With each iteration, the assumptions are more fully exposed and the risk management plan and the detailed schedule and budget become a more accurate reflection of reality.
Control
As the project is monitored for progress, known risks are watched and new risks are identified. Risks that don’t materialize are removed from the risk plan, new risks are added, and the process of risk planning is repeated. All of these activities result in updates to the statement of work, budget reserves, progress reports, work breakdown structure, and the many other project management deliverables.
Business Risk versus Project Risk
The City of Seattle acquired a beautiful new office tower in the early 1990s after the lender foreclosed on the original developers.
The city government was able to buy the building at a huge discount because so much of it was vacant. The developers had taken a risk in building the tower, and when the downtown office market hit a slump, they began to lose money. There was no evidence of cost overruns during construction; demand for office space simply didn’t materialize.
This is an example of a successful project (a beautiful building, on time and on budget) that turned out to be an unsuccessful business venture. Business risk is inherent in all business activities, but it is sel- dom the project manager’s job to manage it; that responsibility lies with the owner of the project. Selecting the right project is business risk. Managing uncertainty to meet the stakeholders’ objectives is project risk.
THE RISK MANAGEMENT FRAMEWORK Figure 5.2 describes a risk management process that is repeated throughout the project:
R I S K M A N A G E M E N T
• Identify risks. Systematically find all the factors that threaten proj- ect objectives.
• Develop a response. Identify each risk in terms of its possible dam- age and degree of likelihood and develop strategies for reducing risk in each case. Most projects have an enormous number of potential risks. Quantifying the potential damage and the probabil- ity that a risk will occur enables the team to prioritize the risks, focusing their attention where it does the most good.
• Establish reserves. Set aside additional funding for the project that will be used in case specific risks occur—the known risks—as well funding for the unknown risks.
• Continuous risk management. Implement the strategies and moni- tor the effects of these changes on the project. Risk strategies may require fine-tuning as they are put into effect. Communicate with the stakeholders as new risks are found, known risks are avoided, and risk reserves are spent.
FIGURE 5.2 The risk management process.
New risks
Establish Reserves
1. Allocate risk contingency for known risks.
2. Establish management reserve for unknown risks.
Identify Risks
1. Identify potential risks.
2. Review previous low-priority risks.
Develop Response Plans
1. Define each risk, including the probability and potential negative impact.
2. Develop a response for high-priority risks.
Continuous Risk Mgmt.
1. Monitor for new risks.
2. Report status at regular intervals.
3. Upon a risk event:
Execute the response plan.
Update the entire plan.
Known risks
Risk management plan Risk management plan
R e s e r v e s
Updates to risk management plan
Plan for Ongoing Risk Control
If it is smart to proactively plan for risk at the beginning of a proj- ect, it is even smarter to continuously plan for risk duringthe project.
In the process of working through a project, new risks—both large and small—will usually emerge. Risk management is successful only if its steps are consciously repeated and applied to all risks throughout the life of the project. Planning for ongoing risk management is part of risk control and is usually documented either in the communication plan or in a specific risk management plan (to be discussed later).
STEP ONE: IDENTIFY THE RISKS
One of the scenarios at the beginning of this chapter involved defense contractors concerned about the strength of the new material they were building into fighter planes. In this example, the first critical step of risk management was performed: The risk was identified. Identify- ing risk involves skill, experience, and a thorough knowledge of proj- ect management techniques—both the art and science of project management. There are four techniques for identifying risk: asking the stakeholders; making a list of possible risks (a risk profile); learning from past, similar projects; and focusing on the risks in the schedule and budget. We will look at these four techniques in detail, along with tips for making them work better.
Getting Information about Risk from Stakeholders If you want to know what could possibly go wrong on a project, just ask the people on the team—they’ve probably been making their own lists since they were assigned to the project. Here are two ways to involve the team in identifying project risks.
1. Brainstorming sessions. Everyone’s favorite method for generating ideas works well for identifying risks. Gather the stakeholders and any others involved in the project and follow basic brainstorming rules:
• Generate as big a list of potential risks as possible. Don’t try to evaluate the risks as they are named; let the creativity of the group flow.
• After generating a list of potential risks, combine similar risks and order them all by magnitude and probability. Risks that have little chance of affecting the project can be crossed off.
Don’t try to solve all the risks at the meeting. If there are easy answers, be sure to capture them, but keep the session focused on risk identification, not response development.
DANGER!
T H E P L A N N I N G P R O C E S S
R I S K M A N A G E M E N T
2. Interviewing. Interviewing individuals about risk requires a more structured approach than brainstorming. Using a risk profile with specific questions will help stimulate the person being interviewed to think about all aspects of the project.
Murphy’s Risk Management Law
The art of identifying risk begins with a critical attitude. Because we’re trying to find problems before they emerge, it’s appropriate at first to adopt the attitude that “anything that cango wrong willgo wrong.”
Later, after we’ve developed solid strategies for managing the risks, we can be optimistic again. There is, however, a big difference between a critical examination of the project to identify risks and plain old grip- ing. It’s up to the project manager to set the tone.
Include All Perspectives
People bring different perspectives to the project depending on their project role. Be sure to include customers, sponsors, team members, subcontractors, functional management, and people who have worked on similar projects. They all have a stake in the project and they’ll gladly take this chance to help ensure its success.
Using a Risk Profile
One of the best ways to ensure the success of a project is to apply the lessons learned from past projects. This is done by using a risk profile.
A risk profile is a list of questions that address traditional areas of uncertainty on projects (see Table 5.1). These questions have been gathered and refined from previous, similar projects. Creating a risk profile is an ongoing process: At the end of this project, what has been learned will be incorporated into the profile.
Good risk profiles follow these basic guidelines:
• They are industry-specific. For example, building an information system is different from building a shopping mall.
• They are organization-specific. While industry-specific profiles are a good place to start, the profiles are even better when they address risks specific to a company or department.
• They address both product and management risks. Risks associ- ated with using or developing new technology are product risks.
Management riskaddresses project management issues, such as whether the team is geographically dispersed. Table 5.1 has exam- ples of both product and management risks.
T H E P L A N N I N G P R O C E S S
• They predict the magnitude of each risk. Even simple, subjective indicators of risk such as “high–medium–low” contribute to a clearer assessment of specific risk factors. More specific quantita- tive indicators offer the opportunity for greater refinement and accuracy over many projects.
Risk profiles are generated and maintained by a person or group independent of individual projects. (See discussion of the project office in Chapter 13.) The keeper of the risk profile participates in postproject reviews to learn how well the risk profile worked and to identify new
TABLE 5.1 EXAMPLE: RISK PROFILE QUESTIONS Project Team
1. How many people are on the team?
2. What percent of the team is fully dedicated to the project?
3. Which team members will spend 20 percent or less of their time working on this project?
4. What is the experience level of the team?
5. Have team members worked together before?
6. Is the team spread out geographically?
Customer
1. Will the customer change current processes to use the product? (No) (Minor changes) (Major changes)
2. Will the project require the customer to reorganize? (No) (Minor changes) (Major changes) 3. Are the customers in different departments? Companies?
Technology
1. Will there be technology that is new to the development team?
2. Will there be technology that is new to the users or customers?
3. Is there any new or leading-edge technology in the project?
4. Are the product requirements clearly documented and signed by all necessary stakeholders?
5. Are the product requirements stable?
Executive Support
1. Is there a known project sponsor who is actively involved in the project?
2. Is there sufficient recognition, support and involvement from all the senior management required for the success of the project?
3. Is senior mangement setting deadlines or budget limitations independent of the project manager’s schedule and budget estimations? If so, are these constraints realistic?
• Develop categories of risk, then list several questions for each category.
• Each question probes at a possible weakness.
• Add new categories and questions over time.
risks that need to be added to the profile. These profiles, when kept up- to-date, become a powerful predictor of project success. The combined experience of the firm’s past projects lives in their questions.
It is even possible to buy good risk profiles. Consulting firms will sell them as part of their project management services. The Software Engineering Institute offers a detailed list of questions for evaluating risk on software projects in its Continuous Risk Management Guide- book.1
Historical Records
History continues to be the best predictor of the future. In addition to the history incorporated in the risk profile, a project manager can investigate what happened on similar projects in the past. There may be useful risk-related information already written down that you can tap into, such as:
• Planned and actual performance records that indicate the accuracy of the cost and schedule estimates.
• Problem logs that portray the unexpected challenges and relate how they were overcome.
• Postproject reviews that generate the lessons learned from the proj- ect; while these lessons are often ignored, they may be critical to the success of your project.
• Customer satisfaction records. Records like these are increasingly available in our service-oriented economy. You can mine them for the pitfalls or triumphs of your predecessors, particularly when a previous project generated either glowing praise or mountains of complaints from the customer.
Be Your Own Historian
You can be your own source of historical records in the future. Orga- nize project documentation in such a way that it will be easy to refer- ence long after the project has been finished.
Estimating Schedules and Budgets
Risk management contributes to detailed planning, but detailed plan- ning is also an opportunity to discover risks (see Figure 5.1). As part of the plan, each low-level task will require a cost and schedule esti- mate. When you are involved in this process, watch for those tasks that are difficult to estimate; this usually means that there is some uncertainty associated with them. Treat these individual tasks the same way you would any other risk: Identify the reason for the uncer-
R I S K M A N A G E M E N T
tainty and create a strategy for managing it. (Chapter 8 deals in detail with estimating.)
The risks identified during scheduling and budgeting usually affect smaller parts of the project, but they are important just the same.
Managing the small risks as well as the big ones means that little things are less likely to trip you up.
Recognizing detailed planning as a risk management opportunity further emphasizes the iterative and unbreakable relationship between risk planning and schedule development.
Prioritize the Risks
If performed energetically, these risk identification activities will have created a long list of potential risks. However, many of these risks won’t be worth managing—they’ll have a low impact, a low probability, or both. Even without performing detailed analysis of these risks, the project manager and team will nonetheless be able to use their intu- ition to quickly sort through and winnow out the risks it doesn’t pay to worry about. That means the outcome of the risk identification process is a list of known risks that are worth studying and planning for.
STEP TWO: DEVELOPING A RESPONSE STRATEGY Not every risk will jeopardize a project. Some are no more than peb- bles in a pond; they cause a ripple that quickly subsides. But others resemble an underwater earthquake that causes a tidal wave. Project managers must recognize the difference between the two. They must know how to discern the magnitude of the risk andhow to develop an appropriate strategy to deal with it. This strategy is called response development,and it has three components:
1. Defining the risk, including the severity of the negative impact.
2. Assigning a probability to the risk. How likely is it that this problem will occur?
3. Developing a strategy to reduce possible damage. This strategy will be based on the severity and probability of the risk.
Defining the Risk
Being able to concisely describe the risk is essential to understanding it. The Software Engineering Institute offers this simple but effective format for recording a risk.2
Condition: A brief statement describing the situation that is causing concern or uncertainty.
T H E P L A N N I N G P R O C E S S