| |
Proactive Risk Management
Preston Smith and Guy Merritt
New York: Productivity Press, 2002, 215+xx pages (1563272652)
This book as its title suggests, is about risk management. Specifically, risk
management for product development projects.
The size of the book (215 pages) should give you an indication that this is not
a treatise on risk management. It is, however, a description of a process and a
collection of tools for new product development (NPD) team leaders. Although the
processes outlined in this book are applicable to any project, the new product
development project leaders and team facilitators will find the content of this
book particularly valuable because of the NPD perspective and examples.
The book is clearly targeted at a project manger. It is written in a
conversational or instructional style without a condescending tone. Its clear
and concise prose assumes the reader is a busy person (like your typical project
manager). It also assumes that the reader has some formal project management
experience or training. It is the kind of book you can read in a Boston to LA
flight but it is also a book you'll want handy when planning your risk
management work. Margin notations such as "key idea," "caution," "scope," and
"example" make finding important passages easy. The books is loaded with easily
understood charts and tables to illustrate key points throughout and the back
cover has a fold-out bookmark quick reference containing checklists and process
summary.
Adding to its reader-friendly design is a summary at the end of each chapter
detailing what was covered in the chapter and what to expect in the subsequent
chapter. There is also an "industry neutral" worked example, "Bernardo," that is
continued through the middle chapters of the book (the chapters describing the
risk management process steps).
Bernardo analyzes his risk of having and dying from a heart attack. Though the
example demonstrates the thought process, a less neutral example or a more "work
related" example would facilitate readers' application of the ideas to their own
work. There is no shortage of example of risks for new product development
projects, and some risks are common to virtually every project (NPD or
otherwise).
The early chapters provide the reader with an overview of risk management and
essential concepts. The authors are quick to point out that the term "risk" can
be interpreted a number of different ways. Because of these many possible
interpretations, they reset the reader by defining risk and risk management in
the context NPD projects. Those definitions are: Risk - the possibility that an
undesirable outcome - or the absence of a desired outcome - disrupts your
project. Risk Management - the activity of identifying and controlling undesired
project outcomes proactively. (Page 5)
While these definitions are fine, it is surprising that they are different than
those used in A Guide to the Project Management Body of Knowledge (PMBOK
Guide) published by the Project Management Institute, especially since the
authors rely heavily on it (the PMBOK guide is referenced in about half of the
book's chapters).
Given that the PMBOK Guide is currently the only internationally recognized
standard for project management (and an ANSI standard), it would have made sense
to stick with these well known definitions, particularly for readers (and
companies) who are adopting PMBOK Guide terminology but have not yet solidified
their risk management practices.
If you compare the definitions, the authors' view on risk appears to be strictly
negative. The PMBOK guide's perspective is clear: risk has both down and up
sides. The Guide's definition: "Risk. An uncertain event or condition that, if
it occurs, has a positive or negative impact on project objectives." This is an
important perspective and suggests that as a project manager, you should not
limit your risk management to just the potential bad things, but pay attention
to potential good things as well.
On the other hand, the difference between the definitions of "risk management"
is less notable and potentially a matter of semantics. From the PMBOK Guide:
"Risk management is the systematic process of identifying, analyzing and
responding to project risk" (page 127, italics added) versus Proactive
Risk Management's definition: "the activity of identifying and
controlling undesired project outcomes proactively." (Page 5, italics added)
If you interpret controlling to mean, "To exercise authoritative or dominating
influence over" [see 2] then clearly there are risks that cannot be controlled
(such as force majeure).
The introduction and early part of the book make a good case for managing risk
and why companies often fail to do so. The authors make an important distinction
between risk management and "fire fighting," and they discuss how much risk
management is enough. Four "risk models" are presented in these early chapters:
Standard Risk Model, Simple Risk Model, Cascade Risk Model, and the Ishikawa
Risk Model. The goal here is to clarify our thinking about the components of
risk management and to present the strengths and weaknesses of each model. The
process described in the remainder of the book is based on the standard risk
model. Although the authors' definition of risk and risk management differs from
the PMBOK definition, the application of the model is consistent with the PMBOK
Guide.
The standard risk model's components include risk event, risk event driver,
probability of risk event, impact of a risk, impact driver, probability of
impact, and total loss. These terms are clearly defined and used in the chapters
describing the resulting risk management process.
This process is presented in summary form and then a chapter is devoted to each
major step. The steps described are risk identification, risk analysis, risk
prioritization and mapping, risk resolution, and risk monitoring. The chapters
describe each process step with a number of worked examples, making it easy for
practitioners to connect the process to their own work.
In the chapter on risk analysis the authors introduce the idea of "expected
loss" to a project as the product of probability of risk event, probability of
impact, and total loss. This terminology is sure to clarify risk discussions on
projects, because practitioners will have to distinguish probabilities of the
event and its impact, and be clear on total loss. However, the units offered to
quantify total and expected loss can introduce confusion. The two loss units
discussed are dollars for cost and workdays for schedule.
In some organizations, dollars will work fine as a measure of loss to a project.
In most organizations, however, resources are the currency, not dollars. (A
number of my clients tell me that they don't "dollarize" their labor.) For these
situations, an alternative should have been suggested.
In addition, the schedule loss unit of workdays can be confused with labor units
such as staff-days. (With my clients we use "Staff-days" or "Stays" to indicate
cost impact in terms of labor). Although, the authors define their usage of
workdays (page 69), the confusion between duration days and effort days is so
consistent in industry that every attempt should be made to clarify the two. For
example a risk that could generate a loss of 15 workdays for a ten full-time
equivalent (FTE) person project could generate a cost loss of 150 staff-days! An
organization may be willing to absorb the 15 workday loss, but is unlikely to
want to absorb a 150 staff-day loss.
Along with clarity on loss units, I would have also liked to see more on how to
best describe risks. Risk management often breaks down when the practitioner
tries to describe the risk to others, particularly senior management, who often
dismiss poorly worded risk statements as trivial or alarmist. An effective risk
statement, often written in an "IfÖThen" structure, avoids this by putting in
concrete terms the event and its impact on the project while presenting it as a
possible occurrence. This wording makes it clear that the event is a possibility
and details what it would mean to the project should that event occur (schedule,
resources, and revenue). This level of concreteness will get stakeholders to
sit-up and notice.
The discussion on risk management tools includes an excellent description of a
facilitated tool called "sticky density" (a process that uses Post-itÆ notes).
This is a well-known process for identifying risks associated with specific
aspects of a project based on the network logic diagram (PERT chart, to MS
Project users). Also presented are decision analysis, risk simulation, and
Design Structure Matrices (DSM). The finer details of these topics go beyond the
scope of the book but are worth further reading as your risk management process
matures. The most intriguing of those discussed is the DSM. This tool helps the
management of a project when assumptions (a.k.a. risks) have to be made so a
project can move forward.
The later chapters of the book address general approaches and strategies for
dealing with risk and provide much needed help for dealing with the
organizational issues that emerge when trying to bring in a new process such as
risk management. A set of industry specific examples rounds out the book's
content.
Overall, this is a useful book for project managers and project team
facilitators. It provides a nice framework, is substantially consistent with
current project management standards, and presents a clear and easy to follow
process documented with useful and recognizable examples.
References
1. A Guide to the Project Management Body of Knowledge. Newton Square,
Pennsylvania: Project Management Institute, 2000.
2. American Heritage Talking Dictionary. Copyright © 1997 The Learning
Company, Inc.
Mark R. Durrenberger, PMP
Oak Associates, Inc.
November 2002
|