Available:*
Shelf Number | Material Type | Copy | Shelf Location | Status |
---|---|---|---|---|
658.404 KEN | Book | 1 | Standard shelving location | Searching... Unknown |
Bound With These Titles
On Order
Summary
Summary
Winner of the Project Management Institute's David I. Cleland Project Management Literature Award 2010 It's no wonder that project managers spend so much time focusing their attention on risk identification. Important projects tend to be time constrained, pose huge technical challenges, and suffer from a lack of adequate resources. Identifying and Managing Project Risk , now updated and consistent with the very latest Project Management Body of Knowledge (PMBOK)® Guide, takes readers through every phase of a project, showing them how to consider the possible risks involved at every point in the process. Drawing on real-world situations and hundreds of examples, the book outlines proven methods, demonstrating key ideas for project risk planning and showing how to use high-level risk assessment tools. Analyzing aspects such asavailable resources, project scope, and scheduling, this new edition also explores the growing area of Enterprise Risk Management. Comprehensive and completely up-to-date, this book helps readers determine risk factors thoroughly and decisively... before a project gets derailed.
Author Notes
Tom Kendrick (San Carlos, CA) is an internal project management consultant for Visa Inc., and the author of Results Without Authority (978-08144-7343-6). He has more than 30 years of project management experience, twelve of which were spent as a part of the Hewlett-Packard Project Management Initiative.
Excerpts
Excerpts
Chapter 1 Why Project Risk Management? Far too many technical projects retrace the shortcomings and errors of earlier work. Projects that successfully avoid such pitfalls are often viewed as "lucky," but there is usually more to it than that. The Doomed Project All projects involve risk. There is always at least some level of uncertainty in a project's outcome, regardless of what the Microsoft Project Gantt chart on the wall seems to imply. High-tech projects are particularly risky, for a number of reasons. First, technical projects are highly varied. These projects have unique aspects and objectives that significantly differ from previous work, and the environment for technical projects evolves quickly. There can be much more difference from one project to the next than in other types of projects. In addition, technical projects are frequently "lean," challenged to work with inadequate funding, staff, and equipment. To make matters worse, there is a pervasive expectation that however fast the last project may have been, the next one should be even quicker. The number and severity of risks on these technical projects continues to grow. To avoid a project doomed to failure, you must consistently use the best practices available. Good project practices come from experience. Experience, unfortunately, generally comes from unsuccessful practices and poor project management. We tend to learn what not to do, all too often, by doing it and then suffering the consequences. Experience can be an invaluable resource, even when it is not your own. The foundation of this book is the experiences of others--a large collection of mostly plausible ideas that did not work out as hoped. Projects that succeed generally do so because their leaders do two things well. First, leaders recognize that much of the work on any project, even a high-tech project, is not new. For this work, the notes, records, and lessons learned on earlier projects can be a road map for identifying, and in many cases avoiding, many potential problems. Second, they plan project work thoroughly, especially the portions that require innovation, to understand the challenges ahead and to anticipate many of the risks. Effective project risk management relies on both of these ideas. By looking backward, past failures may be avoided, and by looking forward through project planning, many future problems can be minimized or eliminated. Risk In projects, a risk can be almost any uncertain event associated with the work. There are many ways to characterize risk. One of the simplest, from the insurance industry, is: "Loss" multiplied by "Likelihood" Risk is the product of these two factors: the expected consequences of the event and the probability that the event might occur. All risks have these two related, but distinctly different, components. Employing this concept, risk may be characterized in aggregate for a large population of events ("macro-risk"), or it may be considered on an eventby- event basis ("micro-risk"). Both characterizations are useful for risk management, but which of these is most applicable differs depending on the situation. In most fields, risk is primarily managed in the aggregate, in the "macro" sense. As examples, insurance companies sell a large number of policies, commercial banks make many loans, gambling casinos and lotteries attract crowds of players, and managers of mutual funds hold large portfolios of investments. The literature of risk management for these fields (which is extensive) tends to focus on large-scale risk management, with secondary treatment for managing single-event risks. To take a simple example, consider throwing two fair, six-sided dice. In advance, the outcome of the event is unknown, but through analysis, experimenting, or guessing, you can develop some expectations. The only possible outcomes for the sum of the faces of the two dice are the integers between two and twelve. One way to establish expectations is to figure out the number of possible ways there are to reach each of these totals. (For example, the total 4 can occur three ways from two dice: 1 + 3, 2 + 2, and 3 + 1.) Arranging this analysis in a histogram results in Figure 1-1. Because each of the 36 possible combinations is equally likely, this histogram can be used to predict the relative probability for each possible total. Using this model, you can predict the average sum over many tosses to be seven. Figure 1-1. Histogram of sums from two dice. If you throw many dice, the empirical data collected (which is another method for establishing the probabilities) will generally resemble the theoretical histogram, but because the events are random it is extraordinarily unlikely that your experiments rolling dice will ever precisely match the theory. What will emerge, though, is that the average sum generated in large populations (one hundred or more throws) will be close to the calculated average of seven, and the shape of the histogram will also resemble the predicted theoretical distribution. Risk analysis in the macro sense takes notice of the population mean of seven, and casino games of chance played with dice are designed by "the house" to exploit this fact. On the other hand, risk in the micro sense, noting the range of possible outcomes, dominates the analysis for the casino visitors, who may play such games only once; the risk associated with a single event-- their next throw of the dice--is what matters to them. For projects, risk management in the large sense is useful to the organization, where many projects are undertaken. But from the perspective of the leader of a single project, there is only the one project. Risk management for the enterprise, or for a portfolio of projects, is mostly about risk in the aggregate (a topic explored in Chapter 13). Project risk management focuses primarily on risk in the small sense, and this is the dominant topic of this book. Macro-Risk Management In the literature of the insurance and finance industries, risk is described and managed using statistical tools: data collection, sampling, and data analysis. In these fields, a large population of individual examples is collected and aggregated, and statistics for the "loss and likelihood" can be calculated. Even though the individual cases in the population may vary widely, the average "loss times likelihood" tends to be fairly predictable and stable over time. When large numbers of data points from the population at various levels of loss have been collected, the population can be characterized using distributions and histograms, similar to the plot in Figure 1-2. In this case, each "loss" result that falls into a defined range is counted, and the number of observations in each range is plotted against the ranges to show a histogram of the overall results. Figure 1-2. Histogram of population data. Various statistics and methods are used to study such populations, but the population mean is the main measure for risk in such a population. The mean represents the typical loss--the total of all the losses divided by the number of data points. The uncertainty, or the amount of spread for the data on each side of the mean, also matters, but the mean sufficiently characterizes the population for most decisions. In fields such as these, risk is mostly managed in the macro sense, using a large population to forecast the mean. This information may be used to set interest rates for loans, premiums for insurance policies, and expectations for stock portfolios. Because there are many loans, investments, and insurance policies, the overall expectations depend on the average result. It does not matter so much how large or small the extremes are; as long as the average results remain consistent with the business objectives, risk is managed by allowing the high and low values to balance each other, providing a stable and predictable overall result. Project risk management in this macro sense is common at the project portfolio and enterprise levels. If all the projects undertaken are considered together, performance primarily depends on the results of the "average" project. Some projects will fail and others may achieve spectacular results, but the aggregate performance is what matters to the business bottom line. Excerpted from Identifying and Managing Project Risk: Essential Tools for Failure-Proofing Your Project by Tom Kendrick All rights reserved by the original copyright owners. Excerpts are provided for display purposes only and may not be reproduced, reprinted or distributed without the written permission of the publisher.Table of Contents
Acknowledgments | p. vii |
Chapter 1 Why Project Risk Management? | |
The Doomed Project | |
Risk | |
Benefits and Uses of Risk Data | |
The Project Risk Management Process | |
Anatomy of a Failed Project: The First Panama Canal Project | p. 1 |
Chapter 2 Planning for Risk Management | |
Project Selection | |
Overall Project Planning Processes | |
Defining Risk Management for the Project | |
The PERIL Database | |
A Second Panama Canal Project: Sponsorship and Initiation (1902-1904) | p. 17 |
Chapter 3 Identifying Project Scope Risk | |
Sources of Scope Risk | |
Defining Deliverables | |
High-Level Risk Assessment Tools | |
Setting Limits | |
Work Breakdown Structure (WBS) | |
Other Scope-Related Risks | |
Documenting the Risks | |
Panama Canal: Setting the Objective (1905-1906) | p. 40 |
Chapter 4 Identifying Project Schedule Risk | |
Sources of Schedule Risk | |
Activity Definition | |
Estimating Activity Duration | |
Activity Sequencing | |
Documenting the Risks | |
Panama Canal: Planning (1905-1907) | p. 70 |
Chapter 5 Identifying Project Resource Risk | |
Sources of Resource Risk | |
Resource Planning | |
Staff Acquisition | |
Outsourcing | |
Project-Level Estimates | |
Cost Estimating and cost Budgeting | |
Documenting the Risks | |
Panama Canal: Resources (1905-1907) | p. 100 |
Chapter 6 Managing Project Constraints and Documenting Risks | |
Analyzing Constraints | |
Managing Opportunities | |
Scope Modification | |
Resource Modification | |
Schedule Modification | |
Assessing Options and Updating Plans | |
Seeking Missing Risks | |
Documenting the Risks | |
Panama Canal: Improving the Plan (1906) | p. 127 |
Chapter 7 Quantifying and Analyzing Activity Risks | |
Quantitative and Qualitative Risk Analysis | |
Risk Probability | |
Risk Impact | |
Qualitative Risk Assessment | |
Quantitative Risk Assessment | |
Panama Canal: Risks (1906-1914) | p. 149 |
Chapter 8 Managing Activity Risks | |
Root-Cause Analysis | |
Categories of Risk | |
Risk Response Planning | |
Risk Avoidance | |
Risk Mitigation | |
Risk Transfer | |
Implementing Preventative Ideas | |
Contingency Planning | |
Risk Acceptance | |
Documenting Your Risk Plans | |
Managing A Specific Risk | |
Panama Canal: Risk Plans (1906-1914) | p. 176 |
Chapter 9 Quantifying and Analyzing Project Risks | |
Project-Level Risk | |
Aggregating Risk Responses | |
Questionnaires and Surveys | |
Project Simulation and Modeling | |
Analysis of Scale | |
Project Appraisal | |
Project Metrics | |
Financial Metrics | |
Panama Canal: Overall Risks (1907) | p. 212 |
Chapter 10 Managing Project Risk | |
Project Documentation Requirements | |
Project Start-Up | |
Selecting and Implementing Project Metrics | |
Management Reserve | |
Project Baseline Negotiation | |
Project Plan Validation | |
Specification Change Management | |
Panama Canal: Adjusting the Objective (1907) | p. 251 |
Chapter 11 Monitoring and Controlling Risky Projects | |
Don't Panic | |
Applying the Plan | |
Project Monitoring | |
Collecting Project Status | |
Metrics and Trend Analysis | |
Responding to Issues | |
Communication | |
Project Archive | |
Project Reviews and Risk Reassessment | |
Taking Over a Troubled Project | |
Panama Canal: Risk-Based Replanning (1908) | p. 272 |
Chapter 12 Closing Projects | |
Project Closure | |
Project Retrospective Analysis | |
Panama Canal: Completion (1914) | p. 292 |
Chapter 13 Program, Portfolio, and Enterprise Risk Management | |
Project Risk Management in Context | |
Program Risk Management | |
portfolio Risk Management | |
Enterprise Risk Management | |
Panama Canal: Over the Years | p. 301 |
Chapter 14 Conclusion | |
Choosing to Act | |
Panama Canal: The Next Project | p. 332 |
Appendix: Selected Detail from the PERIL Database | p. 339 |
Index | p. 349 |