In reading Tom Kendrick’s book, Identifying and Managing Project Risk: Essential Tools for Failure-Proofing Your Project (2nd edition, 2009), I found it a compelling read and thought I’d share my views.
The premise of Kendrick’s book is that the experiences from previous projects, specifically the historical data of project problems and their impacts can help us in identifying risk and managing those risks on our own projects.
Over a period of more than ten years, Kendrick collected data on project problems from hundreds of project managers. He assembled this data in his Project Experience Risk Information Library (PERIL) database. The database provides information on what types of things go wrong on projects, and attributes each to root causes. In addition, the database captures estimates of the impact of the problems that occurred. The PERIL data is mainly based on projects having a dependence on new or relatively new technology; includes mostly projects that had a planned duration between six and twelve months; and twenty or fewer project team members.
Kendrick analyzed over six hundred projects, and has come up with an interesting approach to allow comparison. For each project, whatever the actual impact of the project issues, he has converted the impact to a time impact. For example, if scope was reduced to meet the scheduled completion date, the timeline impact has been determined by calculating how late the project would have been if it had delivered its original scope. Kendrick’s approach may not stand up to rigorous scientific scrutiny (and he is open about the bias in the data), but in my opinion, it still provides a very useful way to compare project risks. From these risks come clear risk management strategies.
Kendrick’s first analysis is high level and compares the total timeline impact in the PERIL database for eight root causes. These include, for example, scope changes during the project, failure to meet deliverable requirements, schedule delays, internal staffing.
In later chapters, Kendrick then breaks down the categories of risk/impact into sub-categories. For example, the impact of scope changes during the project is broken down into non-mandatory scope changes, legitimate requirements gaps, and so on.
In the chapters covering sub-categories, the descriptions of issues from the project managers are included along with the frequency and impact figures. For example, end user not involved enough in requirements, supplier not meeting deadlines, system architect not available. In reading these issues from other project managers, some triggered project flashbacks!
The Panama Canal
Throughout the book Kendrick weaves stories of the Panama Canal building projects. The first project, which ran from 1879 to 1889, was a failure. Ten years after the start of the project, it was cancelled, thousands of workers were dead, the costs had spiraled out of control, and there was no canal. A failure indeed!
The second Panama Canal project started in 1902, started re-planning in 1905, and the canal opened in 1914. This project finished under budget and ahead of schedule, and was useable for its intended purpose. Although workers also died on the second project, the death and disease rates were dramatically reduced due to improved insect control, housing and other practices implemented on the project.
Although Kendrick placed the Panama Canal segments to tie each to a specific risk or approach being discussed in the book, for me they were very interesting, not just as project management solutions, but also as an interesting historical sidebar.
Lessons from the book
Although Kendrick makes project management recommendations regarding each sub-category, he does not make recommendations about which are the most critical practices for project managers to adopt overall. He leaves this to the discretion of each project manager, to be determined based on their own specific projects and environments.
In examining the breakdowns in the book, each project manager can determine what the biggest-impact problems are likely to be, either in general or on their own project, and then decide what to do about them. Every reader will likely take something different from the book depending on whether they are looking for general guidance or for insights for their own project.
For purposes of this article, I decided to look at the data from the perspective of “If I wanted to improve my project risk management in just one area, where should I focus to address the project risks that occur most frequently and have the greatest impact?” So, I started by looking for the category that has the greatest number of issues and the greatest impact. As described above, the greatest impact is from scope changes that occur during the project. It is also the issue that occurs with the greatest frequency.
Then, within the scope change category, the two sub-categories that have the greatest frequency and impact are non-mandatory changes and legitimate requirements gaps.
My conclusion is that to improve my project risk management practices, I should start by improving scope management. By looking at the sub-categories, I see that the ways to improve scope management the most are: (a) eliminate the non-mandatory changes; and (b) reduce legitimate requirements gaps by either spending more time on requirements or by making a provision in the schedule right from the outset.
If I was looking at the data before starting a new project, I would be looking to see what might apply to my own project.
The value in Kendrick’s book is the analysis of many technical projects and the comparability of the various causes of problems. This comparability allows each project manager to assess for themselves what recommendations can be quickly implemented for the highest improvement in their projects.
The Panama Canal highlights provide interesting examples of the differences in project management techniques and capabilities.