How project planning helps minimize risks

How Does Project Planning Minimize Risks?

Using Chapters 1 and 2 of the Kendrick’s text, describe in 300 words how project planning helps minimize risks, and give examples. This assignment s valued at 20 points. It is due before the next class convenes.

“You can observe a lot just by watching.”

—YOGI BERRA

Planning for risk involves paying attention. When we don’t watch, projects fail.

How many? One frequently quoted statistic is 75 percent. The original source for this assertion is a study done in 1994 by the Standish Group and documented in “The CHAOS Report.” There are reasons to be skeptical of this number, starting with the fact that if three of four proj- ects actually did fail, there would be a lot fewer projects. What the Stan- dish Group actually said in its study was that about a quarter of projects in the sample were cancelled before delivering a result. In addition to this, roughly half of the projects were “challenged,” producing a deliverable but doing it late, over budget, or both. The remaining quarter of the proj- ects they viewed as successful.

Although the Standish Group has done further research over the years with similar results, the actual picture for projects is probably not quite so bleak. The Standish Group studied only large IT projects, those with budgets more than US$2 million. In addition, the survey information did not come from the project leaders but was reported by the executives responsible for the organizations where the projects were undertaken. Larger projects are more prone to fail, and US$2 million is a big IT project (especially in 1994). The source of the data also raises a question about what was being compared to what. Were the projects in fact troubled, or

C h a p t e r

2

Planning for Risk Management

were they doomed from the start by unrealistic expectations that were never validated? Whatever the true numbers for failed projects are, how- ever, too many projects fail unnecessarily, and better risk management can help.

Although unanticipated “acts of God” doom some projects, most fail for one of three reasons:

• They are actually impossible. • They are overconstrained (“challenged” in the Standish Group

model). • They are not competently managed.

A project is impossible when its objective lies outside of the tech- nical capabilities currently available. “Design an antigravity device” is an example. Other projects are entirely possible, but not with the time and resources available. “Rewrite all the corporate accounting software so it can use a different database package in two weeks using two part-time university students” is an overconstrained project. Unfortunately, there are also projects that fail despite having a feasible deliverable and plau- sible time and budget expectations. These projects fail because of poor project management—simply because too little thought is put into the work to produce useful results.

Risk and project planning enable you to distinguish among and deal with all three of these situations. For projects that are demonstrably beyond the state of the art, planning and other analysis data generally provide sufficient information to terminate the project or at least to redi- rect the objective (buy a helicopter, for example, instead of developing the antigravity device). Chapter 3, on identifying project scope risks, dis- cusses these situations. 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 a realistic project lacks business jus- tification). Chapters 4, 5, and 6, on schedule, resource, and other risk identification, discuss issues common for these overconstrained projects. Dealing with “challenged” projects by negotiating a realistic project baseline is covered in Chapter 10.

The third situation, a credible project that fails because of faulty execution, is definitely avoidable. Through adequate attention to project and risk planning, these projects can succeed. Well-planned projects be- gin quickly, limiting unproductive chaos. Rework and defects are mini- mized, and people remain busy performing activities that efficiently move

18 I D E N T I F Y I N G A N D M A N A G I N G P R O J E C T R I S K

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 ef- ficient, risk planning also provides insight for faster, better project deci- sions. Although changes are required to succeed with the first two types of projects mentioned earlier, this third type depends only on you, your project team, and application of the solid project management concepts in this book. The last half of this book, Chapters 7 through 13, specifically addresses these projects.

P r o j e c t S e l e c t i o n

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 change something old. Projects are a large portion of the overall work done in organizations these days, and there are always many more attractive project ideas than can be funded or adequately staffed at any given time. The process for choosing projects both creates project risk and relies on project risk analysis, so the processes for proj- ect selection and project risk management are tightly linked. Selecting and maintaining an appropriate list of active projects requires project portfolio management.

Project selection affects project risk in a number of ways. Poor project portfolio management exacerbates a number of common project risks:

• Too many projects competing for scarce resources • Project priorities that are misaligned with business and techni-

cal strategies • Inadequately staffed or funded projects • Unrealistically estimated organizational capabilities

Project risk management data is also a critical input to the proj- ect selection process. Project portfolio management uses project risk as- sessment as a key criterion for determining which projects to put into plan at any given time. Without high-quality risk data and realistic esti- mates for candidate projects, excessive numbers of projects will be un- dertaken and many of them will fail. The topic of project portfolio risk management is explored in Chapter 13.

P L A N N I N G F O R R I S K M A N A G E M E N T 19

O v e r a l l P r o j e c t P l a n n i n g P r o c e s s e s

The project selection process is a major source of risk for all proj- ects, but the overall project management approach is even more signifi- cant. When projects are undertaken in organizations lacking adequate project management processes, risks will be unknown and probably un- acceptably 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 manage- ment 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 man- age 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 meth- ods used for managing project work are too informal and they lack ade- quate structure. Exactly what process you choose matters less than that you are using one. If elaborate, formal, PMBOK®-inspired heavyweight proj- ect management works for you, great. If agile, lightweight, adaptive method- ologies provide what you need, that’s fine too. The important requirement for risk management is that you adopt and use an effective project man- agement process.

For too many technical projects, there is indifference or even hos- tility to planning. This occurs for a number of reasons, and it originates in organizations at several levels. At the project level, other types of 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 prob- lems 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 proj- ect management is worthwhile, read on. If project planning and related management processes are adequate in your organization, skip ahead.

A t t h e P r o j e c t L e v e l

A number of reasons are frequently cited by project leaders for avoiding project planning. Some projects are not thoroughly planned

20 I D E N T I F Y I N G A N D M A N A G I N G P R O J E C T R I S K

because the changes 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 in- creasingly common reason offered is the belief that in “Internet time,” thinking and planning are no longer affordable luxuries. There is a re- sponse for each of these assertions.

Inevitable project change is a poor reason not to plan. In fact, fre- quent 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 based on the consequences demonstrated using the project plan. When changes are necessary, it is easier to con- tinue 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 valid reason to avoid proj- ect management processes. Although it is universally true that no project has enough time, the belief that there is no time to plan is difficult to un- derstand. All the work in any project must always be planned. There is a choice as to whether planning will be primarily done 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, tracking project progress will at best be guesswork. Second, most project risks, even those easily identified, 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. Pro- jects that must execute as quickly as possible need more, not less, proj- ect planning. Delivering a result with value requires sequencing the work for efficiency and ensuring that the activities undertaken are truly nec- essary and of high priority. There is no time for rework, excessive defect correction, or unnecessary activity on fast-track projects. Project plan- ning, particularly on time-constrained projects, is real work.

A b o v e t h e P r o j e c t L e v e l

Projects are undertaken based on the assumption that whatever the project produces will have value, but there is often little consideration

P L A N N I N G F O R R I S K M A N A G E M E N T 21

of the type and amount of process that projects need. In many high-tech environments, little to no formal project management is mandated, and of- ten it is even discouraged.

Whenever the current standards and project management prac- tices are inadequate in an organization, strive to improve them. There are two possible ways to do this. Your best option is to convince the man- agers and other stakeholders that more formal project definition, plan- ning, and tracking will deliver an overall benefit for the business. When this is successful, all projects benefit. For situations where this is unsuc- cessful, 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 con- trolled, 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 demonstrating the value of project management or the costs associated with inadequate process, assemble it. 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 es- tablished for the work, so mounting a compelling case for project man- agement 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 de- livering 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 con- trol 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, mod- els, 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 natu-

22 I D E N T I F Y I N G A N D M A N A G I N G P R O J E C T R I S K

rally. These folks will require little or no convincing, and any approach you use is likely to succeed. Other managers are highly skeptical about project management and will heavily focus on the visible costs (which are un- questionably real) while doubting the benefits. The best approach in this case is to gather local data, lots of it, that shows as clearly as possible how high the costs of not using better processes are. Trying to convince an ex- treme skeptic that project management is necessary may even be a waste of time, for both of you. Good risk management in such a skeptical envi- ronment is up to you, and it may be necessary to do it “below the radar.”

Fortunately, most managers are somewhere in the middle, nei- ther “true believers” in project management nor chronic process adver- saries. The greatest potential for process improvement is with this ambivalent group. Using anecdotal information, models, case studies, and other information can be 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 bene- fits, among them:

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

Finding situations that show where project management deliv- ered 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 will need to address these. One obvious cost is the “over- head” it represents: meetings, paperwork, time invested in project man- agement 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

P L A N N I N G F O R R I S K M A N A G E M E N T 23

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.

Answering the question “Is project management worth it?” using anecdotal information depends on whether the benefits can be credibly shown 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 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. Scal- ing 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 usu- ally 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 num- ber of slightly better ways to approach the work (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 man- agement processes are rarely applied with any rigor, even by project management zealots, as the overhead involved may double the work re- quired 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 addi- tional time and money. As the “to do” list spills over a single page, proj- ect 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 mid-size projects succeed, but the possi- bility of falling short of some key goal (or complete project failure) is in- creasing.

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 objec- tive. 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 with- out good project management will vary. Figure 2-1 shows the cost of a

24 I D E N T I F Y I N G A N D M A N A G I N G P R O J E C T R I S K

“best effort,” or brute force, approach to a project contrasted with a proj- ect management approach. The assumption for this graph is that costs will vary linearly with project scale if project management is applied, and they will vary 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.

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 minor near this point, and negative below it. For these smaller projects, project man- agement is a net cost or of small financial benefit. (Cost may not be the only, or even the most important, consideration, though. Project man- agement methodologies may also be employed for other reasons, such as to meet legal requirements, to manage risk better, or to improve coordi- nation 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 bet- ter project management practices.

P L A N N I N G F O R R I S K M A N A G E M E N T 25

Project Size

Project ManagementBest Efforts

Project Cost

Smaller Larger

Higher

Lower

Figure 2-1. Cost benefit for project management.

Case studies To offset the costs of project management, you need to establish measurable (or at least plausible) benefits. Many stud- ies and cases have been developed over the years to assess this, includ- ing the one summarized in Figure 2-2. The data in this particular study was collected over a three-year period in the early 1990s from more than two hundred 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.

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

26 I D E N T I F Y I N G A N D M A N A G I N G P R O J E C T R I S K

-200

-100

0

100

200

300

400

500

600

700

Schedule Change Codes

E n

g in

ee ri

n g

M o

n th

s

1 2 3 4 5 6 7 8 9 10 11 12 13 A

Figure 2-2. Schedule change Pareto diagram.

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 A. Acceleration

Not every one of these root causes directly correlates with proj- ect 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. Although 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. Similar conclusions may be drawn from the analysis of the Project Experience Risk Information Li- brary (PERIL) database later in this chapter and throughout this book.

Case study data such as these examples, particularly if it directly relates to the sort of project work you do, can be convincing. You likely have access to data similar to this, or could estimate it, for rework, fire- fighting, crisis management, missing work, and the cost of defects on re- cent 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. Current standards and legal requirements for enterprise

P L A N N I N G F O R R I S K M A N A G E M E N T 27

risk management in the United States and worldwide make adoption of formal processes for risk management obligatory. (The direct connec- tion of this to project risk management is explored in Chapter 13.) In firms that provide solutions to customers, using a defined methodology is a competitive advantage that can help win business. In some organi- zations, evidence of process maturity is deemed important, and stan- dards set by organizations such as the Software Engineering Institute for higher maturity are pursued. In other instances, specific process re- quirements may be tied to the work, as with many government con- tracts. In all of these cases, project management is mandatory, at least to some extent, whether the individuals and managers involved think it is a good idea or not.

T h e P r o j e c t M a n a g e m e n t M e t h o d o l o g y

Project risk management depends on thorough, sustained appli- cation 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 will be 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.

D e f i n i n g R i s k M a n a g e m e n t f o r t h e P r o j e c t

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 in- formation 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 involve assumptions leading 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 as- sumptions and project objectives. In particular, work to understand the

28 I D E N T I F Y I N G A N D M A N A G I N G P R O J E C T R I S K

expectations of the project stakeholders, and adopt an approach to risk management that reflects your environment.

S t a k e h o l d e r R i s k To l e r a n c e

Organizations in different businesses deal with risk in their own ways. Start-ups and speculative endeavors such as oil exploration gen- erally have a high tolerance for risk; many projects undertaken are ex- pected to fail, but these are compensated for by a small number that are extremely successful. More conservative organizations, such as govern- ments and enterprises that provide solutions to customers for a fee, are generally risk averse and expect consistent success but more modest re- turns on each project. Organizational risk tolerance is reflected in the or- ganizational policies, such as pre-established prohibitions on pursuing fixed-price contract projects.

In addition, the stakeholders of the project may have strong indi- vidual opinions on project risk. Although some stakeholders may be risk tolerant, others may wish to staff and structure the work to minimize ex- treme 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 toler- ance frequently depends on your perspective.

P l a n n i n g D a t a

Project planning information supports risk planning. As you de- fine 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 link- ages between project planning and risk identification are explored in Chapters 3 through 6.

Te m p l a t e s a n d M e t r i c s

Risk management is easier and more thorough when you have ac- cess to predefined templates for planning, project information gathering, and risk assessment. Templates that are preloaded with information com- mon 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 in- formation easier and improve communication. If such templates exist, use them. If there are none, create and share proposed versions of common

P L A N N I N G F O R R I S K M A N A G E M E N T 29

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 supports project estimating, quantitative project risk analysis, and project tracking and control. Examples of metrics useful for risk man- agement are covered in Chapter 9.

R i s k M a n a g e m e n t P l a n

For small projects, risk planning may be informal, but for large, complex projects, you should develop and publish a written risk man- agement plan. A risk management plan includes information on stake- holders, 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 de- termine specific trigger events and thresholds for metrics associated with project risks, and the budgets for risk analysis, contingency planning, and risk monitoring.

Another aspect of risk planning is ensuring that risk management plans include adequate attention to project opportunities. The uncer- tainty inherent in projects means that some things may go better than ex- pected. Considering project options that represent better opportunities can be at least as important to managing project risk as managing po- tential threats. Project opportunity management is discussed in more de- tail in Chapter 6.

T h e P E R I L D a t a b a s e

Good project management is based on experience. Fortunately, the experience and pain need not all be personal; you can also learn from the experience of others, avoiding the aggravation of seeing everything first- hand. The Project Experience Risk Information Library (PERIL) database provides a step in that direction.

30 I D E N T I F Y I N G A N D M A N A G I N G P R O J E C T R I S K

For more than a decade, in conducting workshops and classes on project risk management, I have been collecting data anonymously from hundreds of project leaders on their past project problems. Their de- scriptions included both what went wrong and the amount of impact it had on their projects. I have compiled this data in the PERIL database, which serves as the foundation for this book. The database describes a wide spectrum of things that have gone wrong with past projects, and it provides a sobering perspective on what future projects will face. Since the version of the PERIL database I used in the first edition of this book, the number of included cases has nearly tripled, to well over 600.

Some project risks are easy to identify because they are associ- ated with familiar work. Other project risks are more difficult to uncover because they arise from new, unusual, or otherwise unique requirements. The PERIL database is valuable in helping to identify at least some of these otherwise invisible risks. In addition, the PERIL database summarizes the magnitude of the consequences associated with key types of project risk. Realistic impact information can effectively counteract the generally op- timistic assessments typically used for project risks. Although some of the specific cases in the PERIL database relate only to certain types of projects or may be unlikely to recur, some close approximation of these situations will be applicable to most technical projects.

S o u r c e s f o r t h e P E R I L D a t a b a s e

The information in the PERIL database comes primarily from par- ticipants in classes and workshops on project risk management, repre- senting a wide range of project types. Slightly more than half the projects are product development projects, with tangible deliverables. The rest are information technology, customer solution, or process improvement projects. The projects in the PERIL database are worldwide, with a ma- jority from the Americas (primarily United States, Canada, and Mexico). The rest of the cases are from Asia (mostly Singapore and India) and from Europe and the Middle East (from about a dozen countries, but largely from Germany and the United Kingdom). As with most modern projects, whatever their type or location the projects in the PERIL database share a strong dependence on new or relatively new technology. The majority of these projects also involved software development. There are both longer and shorter projects represented here, but the typical project in the database had a planned duration between six months and one year. Although there are some large programs in PERIL, typical staffing on these projects was rarely larger than about twenty people.

The raw project numbers in the PERIL database are presented in the following table.

P L A N N I N G F O R R I S K M A N A G E M E N T 31

Americas Asia Europe/Middle East Total

IT/Solution 256 57 18 331

Product Development 224 66 28 318

Total 480 123 46 649

Although the PERIL database represents many projects and their risks, with only 600 examples, it is far from comprehensive. The data- base contains only a small fraction of the thousands of projects under- taken by the project leaders from whom it was collected, and it does not even represent all the problems encountered on the projects that are in- cluded. Because of this, analysis of the data in the PERIL database is more suggestive of potential project risks than definitive. Despite this, the overall analysis of the current data corroborates the conclusions reached from the earlier, smaller database, so the broad trends appear to be holding up.

Also, as with any data based on nonrandom samples, there are in- evitable sources of bias. The database contains a bias for major project risks, because the project leaders were asked to provide information on significant problems. Trivial problems are excluded from the data by de- sign. There is also potential bias because each case was self-reported. Al- though all the information included is anonymous, some embarrassing details or impact assessment may well have been omitted or minimized. In addition, nearly all of the information was reported by people who were interested enough in project and risk management to invest their time participating in a class or workshop, so they are at the least some- what skilled in project management. This could cause problems related to poor project management to be underrepresented.

Even considering these various limitations and biases, the PERIL database does illuminate a wide range of risks typical of today’s projects. It is filled with constructive patterns, and the biggest source of bias—a fo- cus on only major problems—accurately mirrors accepted strategies for risk management. Nonetheless, before blindly extending the following analysis to any particular situation, be aware that your mileage may vary.

M e a s u r i n g I m p a c t i n t h e P E R I L D a t a b a s e

The problem situations that make up the PERIL database resulted in a wide range of adverse consequences, including missed deadlines, sig- nificant overspending, scope reductions, and a long list of other undesir- able outcomes that were not easily quantified. Although such an extensive assortment of misery may be fascinating, it is difficult to pum- mel into a useful structure. To this end, I chose to normalize all the quan-

32 I D E N T I F Y I N G A N D M A N A G I N G P R O J E C T R I S K

titative data in the database using only time impact, measured in weeks of project slippage. This tactic makes sense in light of today’s obsession with meeting deadlines, and it was an easy choice because by far the most prevalent serious impact reported in this data was deadline slip. Fo- cusing on time is also appropriate because among the project triple con- straints of scope, time, and cost, time is the only one that’s completely out of our control—when it’s gone, it’s gone.

For cases where the impact reported was primarily something other than time, I either worked with the project leader to estimate an equivalent project slippage or excluded the case from the database. For example, when a project met its deadline by using significant overtime, we estimated the slippage equivalent to working all those nights, week- ends, and holidays. If a project found it necessary to make significant cuts to the project scope, we estimated the additional duration that would have been required to retain the original scope. Where such transforma- tions are included in the PERIL database, we used conservative methods in estimating the adjustments.

To better reflect the reality of typical projects, the time data in the PERIL database also excludes extremes. In keeping with the theme of focus on major risk, projects that reported a time slippage of less than a week were not included. On the assumption that there are probably better options for projects that overshoot their deadlines by six months or more, the cases included that reported longer slips are capped at twenty-six weeks. This prevents a single case or two from inordinately skewing the analysis, while retaining the root cause of the problem. Because of their enormous and disruptive potential impact, these and other significant cases will receive more detailed attention later in this book.

The average impact for all records was roughly seven weeks, rep- resenting almost a 20 percent slip for a typical nine-month project. The av- erages by project type were consistently close to the average for all of the data, with product development projects averaging a bit more than seven weeks and IT and solution projects slightly less than seven weeks. By re- gion, projects in the Americas and in Europe and the Middle East averaged slightly more than seven weeks. Asian projects were slightly better, but still nearly six weeks. This data by region and project type includes average im- pact, in weeks.

Americas Asia Europe/Middle East Total

IT/Solution 7.0 6.0 7.5 6.8

Product Development 7.7 5.2 6.6 7.1

Total 7.3 5.5 6.9 6.9

P L A N N I N G F O R R I S K M A N A G E M E N T 33

R i s k C a u s e s i n t h e P E R I L D a t a b a s e

Although the consequences of the risks in the PERIL database are consistently reported based on time, the risk causes were varied and abundant. One approach to organizing this sort of data uses a risk break- down structure (RBS) to categorize risks based on risk type. The cate- gories and subcategories I have used to structure the database form an example of an RBS. Each reported problem in the database is charac- terized in the hierarchy based on its principal root cause. The top level of the hierarchy is organized similarly to the first half of this book, around the project triple constraints of scope, schedule (or time), and resource (or cost). The database subdivides these types of risks based on further breakdown of the root causes of the risks. For most of the risks, determining the principal root cause was fairly straightforward. For others, the problem reported was a result of several factors, but in each case, the risk was assigned to the project parameter that was most significant.

Across the board, risks related to scope issues were dominant. They were both most frequent and, on average, most damaging. Al- though schedule risks were next most numerous, on average resource risks were slightly more harmful. The typical slippage for risks within each major type represented from about a month and a half to two months.

Count Cumulative Impact (Weeks) Average Impact (Weeks)

Scope 270 2114 7.8

Schedule 192 1141 5.9

Resource 187 1250 6.7

Total 649 4,505 6.9

The total impact of all the risks is a bit more than 4,500 weeks— almost ninety years—of slippage. A Pareto chart summarizing total im- pact by category is shown in Figure 2-3.

Within each of these three categories the data is further subdi- vided based on root-cause categories, using the following definitions.

34 I D E N T I F Y I N G A N D M A N A G I N G P R O J E C T R I S K

Cumulative Average Root-Cause Impact Impact Subcategories Definition Cases (Weeks) (Weeks)

Scope: Revisions made to scope Changes during the project 177 1,460 8.2

Resource: People Issues arising from internal staffing 123 706 5.7

Scope: Defects Failure to meet deliverable requirements 93 654 7.0

Schedule: Project slippage due to factors Delays under the control of the project 102 509 5.0

Schedule: Inadequate durations allocated Estimates to project activities 49 370 7.6

Resource: Outsourcing Issues arising from external staffing 47 316 6.7

Schedule: Project slippage due to factors Dependencies outside the project 41 262 6.4

Resource: Money Insufficient project funding 17 228 13.4

A Pareto of the cumulative impact data is shown in Figure 2-4. By far the largest source of slippage in this Pareto chart is scope change; it is more than twice as large as the next subcategory. One positive aspect

P L A N N I N G F O R R I S K M A N A G E M E N T 35

0

500

1000

1500

2000

2500

Resource ScheduleScope

W ee

ks o

f P

ro je

ct Im

p ac

t Figure 2-3. Total project impact by root-cause category.

of this data is that the top five subcategories are all things that are at least partially within the purview of the project leader. This suggests that more focus on the things that you can control as a project leader can signifi- cantly reduce the number and magnitude of unpleasant surprises you’ll encounter during your projects. This idea, along with further decompo- sition of these risk root-cause categories, is explored through the next three chapters, with scope risks discussed in Chapter 3, schedule risks in Chapter 4, and resource risks in Chapter 5.

B i g R i s k s

Most books on project risk management spend a lot of time on theory and statistics. The first edition of this book departed from that tra- dition by focusing instead on what actually happens to real projects, us- ing the PERIL database as its foundation. The point was to illuminate significant sources of actual project risk, with specific suggestions about what to do about the most serious problems—the “black swans.”

Calling such risks “black swans” has been popularized of late by the writings of Nassim Nicholas Taleb. The notion of a black swan origi- nated in Europe before there was much knowledge of the rest of the world.

36 I D E N T I F Y I N G A N D M A N A G I N G P R O J E C T R I S K

0

200

400

600

800

1000

1200

1400

1600

R e so

u rc

e M

o n e y

R e so

u rc

e O

u ts

o u rc

in g

R e so

u rc

e P

e o p le

S ch

e d u le

D e la

y

S ch

e d u le

D e p e n d e n cy

S ch

e d u le

E st

im a te

s

S co

p e

C h a n g e

S co

p e

D e fe

ct

W e

e ks

o f

P ro

je ct

I m

p a

ct Figure 2-4. Total project impact by subcategory.

In the study of logic, the statement “All swans are white” was used as the example of something that was incontrovertibly true. Because all the swans observed in Europe were white, a black swan was deemed impos- sible. It came as something of a shock when a species of black swans was later discovered in Australia. This realization gave rise to the metaphori- cal use of the term “black swan” to describe something erroneously be- lieved to be impossible.

Taleb’s primary subject matter (discussed in depth in his 2001 book, Fooled by Randomness) is financial risk, but his concept of a black swan as a “large-impact, hard-to-predict, rare event” is nonetheless appli- cable to project risk management. It is a mistake to consider a situation as impossible merely because it happens rarely or has not happened yet. In projects, it is common for project leaders to discount major project risks because they are estimated to have extremely low probabilities. But these risks do occur—the PERIL database is full of them—and the severity of problems they cause means that ignoring them can be unwise. When these risks do occur, the same project managers who initially dismissed them come to perceive them as much more predictable—sometimes even inevitable.

In the next three chapters, we will heighten visibility of these project-destroying “black swans” by singling out the most severe 20 per- cent of the risks in the PERIL database—the 127 cases representing the most schedule slippage. The definition of a “large-impact, hard-to-predict, rare event” is a useful starting point, but as the database shows, these most damaging risks are not as rare as might be thought, and they need not be so difficult for project managers to predict if they get appropriate attention in the risk management process.