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.
PERIL database
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 findings
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.
An example
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.
Summary
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.
Copyright
2015 Debbie Gallagher
