Planning for Risk Management

Overview

"You can observe a lot just by watching."

—YOGI BERRA

Planning for risk involves paying attention. The practices that worked before are the foundation of future work, and the problems of the past trigger necessary changes.

Projects fail for one of three reasons. First, some projects fail because they actually are impossible; the objective lies outside the technical capabilities available, at least currently. "Design an antigravity device" is such a project. A second failure mode occurs when the project has a perfectly possible deliverable, but the rest of the objective is unrealistic. "Rewrite all the corporate accounting software so that it can use a different database package in two weeks using two part-time university students" is an example. The third reason projects fail is avoidable but all too common. Here, the deliverable is feasible, and the rest of the objective is also plausible. These projects fail simply because too little thought is put into the work, and no useful results emerge.

Risk and project planning enable you to distinguish among and to deal with all three of these situations. For projects that are demonstrably beyond the state of the art, planning and other data generally provide sufficient information to terminate consideration of the project or at least to redirect the objective ("buy a helicopter," for example, instead of developing antigravity). Chapter 3, on project scope risk identification, discusses these projects. For projects with unrealistic timing, resource, or other constraints, risk and planning data provide you with a compelling basis for project negotiation, resulting in a more plausible objective (or, in some cases, the conclusion that the project should not be undertaken because its cost would exceed its value or it would take too long). Chapters 4, 5, and 6, on schedule, resource, and other risk identification, discuss issues common for these failure-prone projects.

The third situation, a credible project that fails due to faulty execution, is definitely avoidable. Through adequate attention to project and risk planning, these projects can succeed. Well-planned projects begin quickly, limiting unproductive chaos. Rework and defects are minimized, and people remain busy performing activities that efficiently move the project forward. A solid foundation of project analysis also reveals problems that might lead to failure and prepares the project team for their prompt resolution. In addition to making project execution more efficient, risk planning also provides insight for faster, better project decisions. While changes are required to succeed with the first two types of doomed projects, this third type depends only on you, your project team, and application of the concepts in this book. The last half of this book, Chapters 7 through 13, specifically addresses these projects.

Most of the content of this chapter falls into the "Risk Management Planning" portion of the Planning Processes in the PMBOK Guide, but it also draws from Project Integration Management and from other Planning Processes. The principal ideas in this chapter include:

• Project selection
• Overall project planning processes
• Risk management planning
• The Project Experience Risk Information Library (PERIL) database

Project Selection

Project risk is a significant factor even before there is a project. Projects begin as a result of an organization's business decision to create something new or to change something old. Projects are a large portion of the overall work done in organizations, and there are nearly always many more attractive project ideas than can be undertaken at any given time. The process for choosing projects both creates project risk and relies on project risk analysis, so the processes for project selection and project risk management are tightly linked.

Project selection affects project risk in a number of ways. Appropriate project selection can minimize several problems: too many projects; project priorities misaligned with business and technical strategies; and overestimated resources and resource capabilities. Inadequate analysis during project selection creates these risks.

Project risk management data are also a critical input to the project selection process. Decisions about which projects to initiate (and continue) should reflect the overall risk tolerances of the organization. Companies just starting up normally have a high tolerance for risky projects, and their project mix contains mainly projects with considerable uncertainty. Organizations that provide custom solutions for fixed fees typically avoid risky projects to protect their reputation and to avoid financial penalties. Risk data are necessary to make appropriate selection decisions. Since these decisions are generally made before there is much detailed planning, the project risk information available is often not very precise. Revisiting the decisions on a regular basis is crucial for both managing overall risk and keeping the project portfolio balanced.

An effective project selection process has only three possible outcomes for a new or continuing project. The first possibility is that the project is authorized and it becomes or remains an active project. The second option is that the project may require changes (to scope, schedule, or resources) before it becomes or continues to be an active part of the portfolio. The third option is rejection; some (perhaps most) project ideas are turned down or postponed for later reconsideration.

Decisions about which projects to select, change, or reject are generally based on the relative costs and benefits of each option. Expected project benefits and returns are estimated in a number of ways for these portfolio decisions, including predictions of financial metrics for return on investment (ROI metrics are covered in Chapter 9). Risk management information is critical to the portfolio decisions. It allows you to assess the credibility of the estimates for overall return, and it is often the primary factor that triggers changes in the project objectives. Best-in-class companies reject questionable projects early, before too much investment is made. Best-in-class high-technology companies spend less than 5 percent of their research and development budget on failed projects. In the typical high-tech company, the figure is far higher.

The most effective project selection processes include frequent reviews, at least once per quarter, to update project information, revisit the assumptions, and rebalance the project load. This ensures that inappropriate projects are weeded out early and the mix of ongoing projects contains the best available opportunities.

Project selection decisions also directly impact the risk of the selected projects. If choices are made on the basis of unrealistic assumptions about resource requirements, too many projects will be started. It is not uncommon for the project load in high-tech organizations to have resource requirements that are double, or even triple, what is actually available, due to chronic underestimation of the actual resources required. If projects expected to complete are delayed, or hiring new staff takes longer than expected, there may also be insufficient resources for the approved projects. Inadequate staffing on projects creates increased risk for all the projects in the portfolio. Project risk and resource information can minimize the "too many projects" problem.

Project risk also arises from the type of projects selected. The mix of projects by type—such as new research and development, next generation, evolutionary, partner or joint venture, maintenance, support, and infrastructure—also needs to be kept in balance. The proportions will vary over time and from organization to organization, but the target mix should consistently reflect strategic planning decisions and staffing constraints. It requires ongoing discipline to ensure that the project load does not become overloaded with too many projects of a given type—for example, too many maintenance projects or too many projects that depend on speculative technology. When the project load deviates from the overall business objectives, it increases business risk for the organization as a whole. Project selection should result in an appropriate mix of projects with risk and benefit profiles consistent with business objectives and adequate staffing for a focused portfolio of good projects.

Overall Project Planning Processes

The project selection process is one source of project risk for all projects, but another factor, the overall approach used for project management, is even more influential. When projects are undertaken in organizations that lack adequate project management processes, risks will be unknown, and probably unacceptably high. Without adequate analysis of projects, no one has much idea of what "going right" looks like, so it is not possible to identify and manage the risks—the things that may go wrong. The project management processes provide the magnifying glass you need to inspect your project to discover its possible failure modes.

Regular review of the overall methods and processes used to manage projects is an essential foundation for good risk management. If project information and control is sufficient across the organization and most of the projects undertaken are successful, then your processes are working well. For many high-tech projects, though, this is not the case. The methods used for managing project work are too informal, and they lack adequate structure. Exactly what process you choose matters less than that you are using one. If elaborate, formal, PMBOK-inspired heavyweight project management works for you, great. If agile, lightweight, adaptive methodologies provide what you need, that's fine, too. The important requirement for risk management is that you adopt and use a project management process.

Too many technical projects are undertaken with indifference or even hostility to planning. This occurs for a number of reasons, and it originates in organizations at several levels. At the project level, other work may carry higher priority, or planning may be viewed as a waste of time. Above the project level, project management processes may appear to be unnecessary overhead, or they may be discouraged to deprive project teams of data that could be used to win arguments with their managers. Whatever the rationalizations used, there can be little risk management without planning. Until you have a basic plan, most of the potential problems and failure modes for your project will remain undetected.

The next several pages provide support for the investment in project processes. If you or your management need convincing that project management is worthwhile, read on. If project planning and related management processes are adequate in your organization, skip ahead.

At the Project Level

Project leaders frequently cite a number of reasons for avoiding project planning. Some projects are not thoroughly planned because changes to them are so frequent that planning seems futile. Quite a few leaders know that project management methodology is beneficial, but with their limited time they feel they must do only "real work." An increasingly common reason offered is the belief that in "Internet time," thinking and planning are no longer affordable luxuries. There is a response for each of these assertions.

Inevitable project change is a poor reason not to plan. In fact, frequent change is one of the most damaging risk factors, and managing this risk requires good project information. Project teams that have solid planning data are better able to resist inappropriate change, rejecting or deferring proposed changes on the basis of the consequences demonstrated by the project plan. When changes are necessary, it is easier to continue the work by modifying an existing plan than by starting over in a vacuum. In addition, many high-tech project changes directly result from faulty project assumptions that persist because of inadequate planning information. Better understanding leads to clearer definition of project deliverables and fewer reasons for change.

The time required to plan is also not a very good reason to avoid project management processes. While it is universally true that no project has enough time, the belief that there is no time to plan is difficult to understand. All the work in any project must always be planned. There is a choice as to whether planning will be done primarily in a focused, early-project exercise or by identifying the work one activity at a time, day by day, all through the project. All necessary analysis must be done by someone, eventually. The incremental approach requires comparable, if not more, overall effort, and it carries a number of disadvantages. First, project tracking is not very useful, as progress measurement is at best a guess. Second, most project risks, even the easily identifiable ones, come as unexpected surprises when they occur. Early, more thorough planning provides other advantages, and it is always preferable to have project information sooner than later. Why not invest in planning when the benefits are greatest?

Assertions about "Internet time" are also difficult to accept. Projects that must execute as quickly as possible need more, not less, project planning. Delivering a result with value requires sequencing the work for efficiency and ensuring that the activities undertaken are truly necessary and of high priority. There is no time for rework, excessive defect correction, or unnecessary activity on fast-track projects. Project planning, particularly on time-constrained projects, is real work.

Above the Project Level

Projects are undertaken on the basis of the assumption that whatever the project produces will have value, but there is often little consideration of the type and amount of process that projects need. In many high-tech environments, little to no formal project management is mandated, and often it is even discouraged.

Whenever the current standards and project management practices are inadequate in an organization, strive to improve them. There are two possible ways to do this. Your best option is to convince the managers and other stakeholders that more formal project definition, planning, and tracking will deliver an overall benefit for the business. When this is successful, all projects benefit. For situations where this is unsuccessful, a second option is to adopt greater formalism just for your current project. It may even be necessary to do this in secret, to avoid criticism and comments like "Why are you wasting time with all that planning stuff? Why aren't you working?"

In organizations where expenses and overhead are tightly controlled, it can be difficult to convince managers to adopt greater project formalism. Building a case for this takes time and requires metrics and examples, and you may find that some upper-level managers are highly resistant even to credible data. The benefits are substantial, though, so it is well worth trying; anything you can do to build support for project processes over time will help.

If you have credible, local data that demonstrate the value of project management or the costs associated with inadequate process, assemble them. Most organizations that have such data also have good processes. If you have a problem that is related to inadequate project management, it is likely that you will also not have a great deal of information to draw from. For projects lacking a structured methodology, few metrics are established for the work, so mounting a compelling case for project management processes using your own data may be difficult.

Typical metrics that may be useful in supporting your case relate to achieving specifications, managing budgets, meeting schedules, and delivering business value. Project processes directly impact the first three but only indirectly influence the last one. The ultimate value of a project deliverable is determined by a large number of factors in addition to the project management approach, many of which are totally out of the control of the project team. Business value data may be the best information you have available, though, so make effective use of what you can find.

Even if you can find or create only modest evidence that better project management processes will be beneficial, it is not hopeless. There are other approaches that may suffice, using anecdotal information, models, and case studies.

Determining which approaches to use depends on your situation. There is a wide continuum of beliefs about project management among upper-level managers. Some managers favor project management naturally. These folks require little or no convincing, and any approach you use is likely to succeed. Other managers are highly skeptical about project management and focus heavily on the visible costs (which are unquestionably real), while doubting the benefits. The best approach in this case is to gather local information, lots of it, that shows as clearly as possible the high costs of not using better processes. Trying to convince an extreme skeptic that project management is necessary may even be a waste of time for both of you. Good risk management in such a skeptical environment is up to you and is probably best done "below the radar."

Fortunately, most managers are somewhere in the middle, neither "true believers" in project management nor chronic process adversaries. The greatest potential for process improvement is with this ambivalent group, and the following approaches can be very effective.

Anecdotal Information

Building a case for more project process with stories depends on outlining the benefits and costs, and showing there is a net benefit. Project management lore is filled with stated benefits, among them:

• Better communication
• Less rework
• Lowered costs, reduced time
• Earlier identification of gaps and inadequate specifications
• Fewer surprises
• Less chaos and fire-fighting

Finding situations that show either where project management delivered on these or where lack of process created a related problem should not be hard.

Project management does have costs, some direct and some more subtle, and you need to address these. One obvious cost is the "overhead" it represents: meetings, paperwork, time invested in project management activities. Another is the initial (and ongoing) cost of establishing good practices in an organization, such as training, job aids, and new process documentation. Do some assessment of the investment required, and summarize the results.

There is a more subtle cost to managers in organizations that set high project management standards: the shift that occurs in the balance of power in an organization. Without project management processes, all the power in an organization is in the hands of management; all negotiations tend to be resolved using political and emotional tactics. Having little or no data, project teams are fairly easily backed into whatever corners their management chooses. With data, the discussion shifts and negotiations are based more on reality. Even if you choose not to directly address this "cost," be aware of it in your discussions.

Your decision to answer the question "Is project management worth it?" with anecdotal information depends on whether you can credibly show the benefits to outweigh the costs. Your case will be most effective if you find the best examples you can, using projects from environments as similar to yours as possible.

Models: Estimating Project Management Costs

Another possible approach for establishing the value of process relies on logical models. The need for process increases with scale and complexity, and managing projects is no exception to this. Scaling projects may be done in a variety of ways, but one common technique segregates them into three categories: small, medium, and large.

Small projects are universal; everyone does them. There is usually no particular process or formality applied, and more often than not these simple projects are successful. Nike-style ("Just Do It") project management is good enough, and, although there may well be any number of slightly better ways to approach the work (very apparent in hindsight, more often than not), the penalties associated with simply diving into the work are modest enough that it doesn't matter much. Project management processes are rarely applied with any rigor, even by project management zealots, as the overhead involved may double the work required for the project.

Medium-size projects last longer and are more complex. The benefits of thinking about the work, at least a little, are obvious to most people. At a minimum, there is a "to do" list. Rolling up your sleeves and beginning work with no advance thought often costs significant additional time and money. As the "to do" list spills over a single page, project management processes start to look useful. At what exact level of complexity this occurs has a lot to do with experience, background, and individual disposition. Many midsize projects succeed, but the possibility of falling short of some key goal (or complete project failure) is increasing.

For large projects, the case for project management should never really be in doubt. Beyond a certain scale, all projects with no process for managing the work will fail to meet at least some part of the stated objective. For the largest of projects, success rates are low even with program management and systems engineering processes in addition to thorough project management practices.

For projects of different sizes, costs of execution with and without good project management will vary. Figure 2-1 shows the cost of a "best effort," or brute force, approach to a project contrasted with a project management approach. The assumption for this graph is that costs will vary linearly with project scale if project management is applied and geometrically with scale if it is not. This figure, though not based on empirical data, is solidly rooted in a large amount of anecdotal information.

Figure 2-1: Cost benefit of project management.

The figure has no units, because the point at which the crossover occurs (in total project size and cost) is highly situational. If project size is measured in effort-months, a common metric, a typical crossover might be between one and four total effort-months.

Wherever the crossover point is, the cost benefit is very minor near this point and negative below it. For these smaller projects, project management is a net cost or of very small financial benefit. (Cost may not be the only, or even the most important, consideration, though. Project management methodologies may also be employed for other reasons, such as to meet legal requirements, to manage risk better, or to improve coordination between independent projects.)

A model similar to this, especially if it is accompanied by project success and failure data, can be a compelling argument for adopting better project management practices.

Case Studies

To offset the costs of project management, you need to establish measurable (or at least plausible) benefits. Many studies and cases have been developed over the years to assess this, including the one summarized in Figure 2-2. The data in this particular study were collected over a three-year period in the early 1990s from more than 200 projects at Hewlett-Packard. For every project included, all schedule changes were noted and characterized. All changes attributed to the same root cause were aggregated, and the summations were sorted for the Pareto diagram in the figure, displaying the magnitude of the change on the vertical axis and the root causes along the horizontal axis.

Figure 2-2: Schedule change Pareto diagram.

Additional project effort—hundreds of engineer months— was associated with the most common root causes. The codes for the root causes, sorted by severity, were:

1. Unforeseen technical problems
2. Poor estimation of effort/top-down schedules
3. Poor product/system design or integration problems
4. Changing product definition
5. Other
6. Unforeseen activities/too many unrelated activities
7. Understaffed, or resources not on time
8. Software development system/process problems
9. Related project slip (also internal vendor slip)
10. Insufficient support from service areas
11. Hardware development system/process problems
12. Financial constraints (tooling, capital, prototypes)
13. Project placed on hold
14. Acceleration

Not every one of these root causes directly correlates with project management principles, but most of them clearly do. The largest one is unforeseen technical problems, many of which were probably caused by insufficient planning. The second, faulty estimation is also a project management factor. While better project management would not have eliminated all these slippages, it surely would have reduced them. The top two reasons in the study by themselves represent an average of roughly five unanticipated engineer-months per project; reducing this by half would save thousands of dollars per project.

Case study data such as these, particularly if they directly relate to the sort of project work you do, can be very convincing. You very likely have access to data similar to these, or could estimate it, for rework, fire-fighting, crisis management, missing work, and the cost of defects on recent projects.

Other Reasons for Project Management

One of the principal motivators in organizations that adopt project principles is reduction of uncertainty. Most technical people hate risk and will go to great lengths to avoid it. One manager who strongly supports project management practices uses the metaphor of going down the rapids of a white-water river. Without project management, you are down in the water—you have no visibility, it is cold, it is hard to breathe, and your head is hitting lots of rocks. With project management, you are up on a raft. It is still a wild ride, but you can see a few dozen feet ahead and steer around the worst obstacles. You can breathe more easily, you are not freezing and are less wet, and you have some confidence that you will survive the trip. In this manager's group, minimizing uncertainty is important, and planning is never optional.

Another motivator is a desire (or requirement) to become more process-oriented. Some industries have adopted ISO standards so widely that individual companies have no choice but to comply. In companies that provide solutions to customers, use of a defined methodology is a competitive advantage that can help win business. In some organizations, evidence of process maturity is deemed important, and standards set by organizations such as the Software Engineering Institute for higher maturity are pursued. In other instances, specific process requirements are tied to the work, as with many government contracts. In all of these cases, project management is used, at least to some extent, whether or not the individuals and managers involved think it is a good idea.

The Project Management Methodology

Project risk management depends on thorough, sustained application of effective project management principles. The precise nature of the project management methodology can vary widely, but management of risk is most successful when consistent processes are adopted by the organization as a whole, because there is more information to work with and more durable support for the ongoing effort required. If you need to manage risk better on your project and it proves impossible to gain support for more effective project management principles broadly, resolve to apply them, project by project, with sufficient rigor to develop the information you need to manage risk.

Defining Risk Management for the Project

Beyond basic project planning, risk management also involves specific planning for risk. Risk planning begins by reviewing the initial project assumptions. Project charters, datasheets, or other documents used to initiate a project often include information concerning risk, as well as goals, staffing assumptions, and other information. Any risk information included in these early project descriptions is worth noting; sometimes projects believed to be risky are described as such, or there may be other evidence of project risk. Projects that are thought to be low-risk may use assumptions that lead to unrealistically low staffing and funding. Take note of any differences in your perception of project risk and the stated (or implied) risks perceived by the project sponsors. Risk planning builds on a foundation that is consistent with the overall assumptions and project objectives. In particular, work to understand the expectations of the project stakeholders, and adopt an approach to risk management that reflects your environment.

Stakeholder Risk Tolerance

Organizations in different businesses deal with risk in their own ways. Start-ups and speculative endeavors such as oil exploration generally have a high tolerance for risk; many projects undertaken are expected to fail, but these are compensated for by a small number that are extremely successful. More conservative enterprises and organizations that provide solutions to customers for a fee generally are very risk-averse, expecting consistent success but more modest returns on each project. Organizational risk tolerance is reflected in the organizational policies, such as preestablished prohibitions on pursuing fixed-price contract projects.

In addition, the stakeholders of the project may have strong individual opinions on project risk. While some stakeholders may be risk-tolerant, others may wish to staff and structure the work to minimize extreme outcomes. Technical contributors tend to prefer low risk. One often repeated example of stakeholder risk preference is attributed to the NASA astronauts, who observed that they were sitting on the launch pad atop hundreds of systems, each constructed by the lowest bidder. Risk tolerance frequently depends on your perspective.

Planning Data

Project planning information supports risk planning. As you define the project scope and create planning documents such as the project work breakdown structure, you will uncover potential project risks. The planning processes also support your efforts in managing risk. The linkages between project planning and risk identification are explored in Chapters 3 through 6.

Templates and Metrics

Risk management is easier and more thorough when you have access to predefined templates for planning, project information gathering, and risk assessment. Templates that are preloaded with information common to most projects make planning faster and decrease the likelihood that necessary work will be overlooked. Consistent templates created for use with project scheduling applications organizationwide make sharing information easier and improve communication. If such templates exist, use them. If there are none, create and share proposed versions of common documents with others who do similar project work, and begin to establish standards.

Risk planning also relies on a solid base of historical data. Archived project data support project estimating, quantitative project risk analysis, and project tracking and control. Examples of metrics useful for risk management are covered in Chapter 9.

Risk Management Plan

For small projects, risk planning may be informal, but for large, complex projects, you should develop and publish a written risk management plan. A risk management plan includes information on stakeholders, planning processes, project tools, and metrics, and it states the standards and objectives for risk management on your project. While much of the information in a risk plan can be developed generally for all projects in an organization, each specific project has at least some unique risk elements.

A risk plan usually starts by summarizing your risk management approach, listing the methodologies and processes that you will use, and defining the roles of the people involved. It may also include information such as definitions and standards for use with risk management tools; the frequency and agenda for periodic risk reviews; any formats to be used for required inputs and for risk management reports; and requirements for status collection and other tracking. In addition, each project may determine specific trigger events and thresholds for metrics associated with project risks and the budgets for risk analysis, contingency planning, and risk monitoring.

The PERIL Database

Over the past ten years, in the context of a series of workshops on risk management, I have asked hundreds of project leaders to describe typical past project problems, defining both what went wrong and the impact it had on their projects. These data are collected in the Project Experience Risk Information Library (PERIL) database and serve as the basis for the following analysis of high-tech project risk.

One useful dichotomy in risk management is between the "known" risks, the risks that occur frequently enough to be analyzed in advance, and the "unknown" risks, those that result from the uniqueness of the work and are difficult or impossible to anticipate. While the PERIL database contains a few unusual situations that are unlikely to recur, nearly all of the data represent situations that are typical of technical projects, so PERIL also provides a template for identifying risk situations that might otherwise fall into the "unknown" category.

The Data

First, what the information in PERIL is not. It is not comprehensive. It represents a small fraction of the tens of thousands of projects undertaken during this time by the project managers from whom it was collected, and it does not represent all the problems encountered even for the projects that are included. It is not unbiased. Several sources of potential bias are obvious: the data were not collected randomly, they are self-reported, and the information comes from a constituency at least interested enough in project and risk management to invest time attending the workshop. Another bias is toward more significant risks; few minor risks are reported here, as the point of the exercise was to collect data on major problems. Having said all this, the risk information collected represents a wide range of risks typical of current projects, and, even with its flaws, a number of patterns emerge. Some of the bias may even make the data more useful, as a focus on more significant problems is consistent with accepted strategies for risk management. However, in extending this analysis to other situations, be aware that "your mileage may vary."

Now, what the PERIL database is. The information collected covers a wide range of projects. Slightly more than half are product development projects, and the rest are information technology, customer solution, or process improvement projects. The projects are worldwide, with a majority from the Americas (primarily United States, Canada, and Mexico). The rest of the cases are from Asia (Singapore and India) and from Europe and the Middle East (from a number of nations, but mainly Germany and the United Kingdom). Whatever the type or location, most of these projects share a strong dependence on new or relatively new technology and significant investment in software development. Both longer and shorter projects are represented, but most had durations between six months and one year. While there are some very large programs in PERIL, typical staffing on these projects was between ten and twenty-five people.

The raw project numbers in the PERIL database are:

	AMERICAS	ASIA	EUROPE/MIDDLE EAST	Total
IT/Solution	67	25	13	105
Product Development	56	45	16	117
Total	123	70	29	222

In order to normalize the data for analysis and comparison purposes, a consistent measure for "impact" is used. The most typical serious impact reported was deadline slip (in weeks), so I estimated a slippage equivalent to this whenever the impact was primarily unplanned overtime, scope reduction, or some other project change. In cases where the deadline was mandatory, the data reported are the equivalent duration that would have been required if the overtime had been worked on a standard schedule or the duration that would have been required to restore any deletions from the project scope. When this was necessary, very conservative estimates were used in making these transformations. The average impact for all records was slightly over five weeks, representing about a 20 percent slip for a typical nine-month project. The averages by project type and by region were consistently very close to the average for all of the data, ranging from about four and a half weeks up to six and a half weeks.

Risk Types

Categorizing risks is a useful way to identify specific problems. Categories suggested by the project triple constraint—scope, schedule, and resources—are used to organize the PERIL database. The relative occurrence and impact of risks of various types provide the basis for improved risk discovery and for more selective and cost-effective risk management. The resource, schedule, and scope risks in PERIL are further subdivided into categories and subcategories on the basis of the sources of the risks.

For most of the risks, the categorization was fairly obvious. For others, the risk spanned a number of factors, and the categorization was a judgment call. In each case, however, the risk was grouped under the project parameter where it had the largest effect, and then by its primary perceived root cause. While schedule risks are most numerous, they seem slightly less damaging, on average, than the other risks (but they still typically caused nearly a month of project slip). Scope risks represent the most impact on project delivery, followed by resource risks. The data are shown here:

	COUNT	CUMULATIVE IMPACT (WEEKS)	AVERAGE IMPACT (WEEKS)
Scope	76	478	6.3
Schedule	82	306	3.7
Resource	64	361	5.6
Total	222	1145	5.2

Scope risks dominate the data, but all categories are significant. A Pareto chart summarizing this total impact by category is in Figure 2-3.

Figure 2-3: Risks in the PERIL database.

Each of these three categories is further characterized by root cause, and a summary of this data appears in Figure 2-4. The PERIL database offers insight into the sources and magnitudes of technical project risk, and detailed descriptions of the analysis for each category are spread through the next three chapters, with scope risks discussed in Chapter 3, schedule risks in Chapter 4, and resource risks in Chapter 5.

Figure 2-4: Subcategory risks in the PERIL database.

Key Ideas for Project Risk Planning

• Project selection affects risk management and depends upon it.
• Project risk management builds on the foundation provided by your project definition and planning.
• A project risk plan summarizes your risk management approach.

A Second Panama Canal Project Sponsorship and Initiation (1902 1904)

"A man, a plan, a canal. Panama."

Successful projects are often not the first attempt to do something. Often, there is a recognized opportunity that triggers a project. If the first attempted project fails, it discourages people for a time. Soon, however, if the opportunity remains attractive, another project will begin, building on the work and the experiences of the first project. A canal at Panama remained such an attractive opportunity. When Theodore Roosevelt became president in 1901, he decided to make successful completion of a Central American canal part of his presidential legacy. (And so it is. He is the "man" in the famous palindrome.)

As much as the earlier French project failed due to lapses in project management, the U.S. project ultimately succeeded as a direct result of the application of good project principles. The results of better project and risk management on this second project unfold throughout the remainder of this book.

Unlike the initial attempt to build a canal, the U.S. effort was not a commercial venture. Maintaining separate U.S. navies on the east and west coasts had become increasingly costly. Consolidation into a single larger navy required easy transit between the Atlantic and Pacific, so Theodore Roosevelt saw the Panama Canal as a strategic military project, not a commercial one.

The U.S. venture started with the Battle of the Routes— Nicaragua versus Panama—and, on the basis of technical analysis, they selected Panama. Unlike Ferdinand de Lesseps, Theodore Roosevelt was a more typical project sponsor. He delegated the management of the project to others. His greatest direct contribution to the project was in "engineering" the independence of Panama from Colombia. (This "revolution" was accomplished by a pair of gunboats, one at Colon, on the Gulf of Mexico side of Panama, and another at Panama City, on the Pacific. Without the firing of a single shot, the independent nation of Panama was created in 1902. Repercussions from this U.S. foreign policy decision persist a century later.) To get the project started quickly, Roosevelt also moved to acquire the assets of the Nouvelle Compagnie (which returned some relief to shareholders of the original company, but not much).

"I took the isthmus!" Roosevelt said. He then went to the U.S. Congress to get approval to go forward with the building of the canal. Following all this activity and the public support it generated, Congress had little choice but to support the project. While the specifics for the project were still vague, the intention of the United States was clear: to build a canal at Panama capable of transporting even the largest U.S. warships and to build it as quickly as was practical.

Insight into Roosevelt's thinking concerning the project is found in this quotation from 1899, two years before his presidency:

Far better it is to dare mighty things, to win glorious triumphs, even though checkered by failure, than to take rank with those poor spirits who neither enjoy much nor suffer much, because they live in the gray twilight that knows not victory nor defeat.

Project sponsors often aspire to "dare mighty things." They are much more risk-tolerant than most project leaders and teams. Good risk management planning serves to balance the process of setting project objectives so that we undertake projects that are not only worthwhile and challenging but also possible.