Review published in the Journal of Product Innovation 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./
- A Guide to the Project Management Body of Knowledge. Newton Square, Pennsylvania: Project Management Institute, 2000.
- American Heritage Talking Dictionary. Copyright © 1997 The Learning Company, Inc.
Mark R. Durrenberger, PMP
Oak Associates, Inc.
(Reviewed in Journal of Product Innovation Management, November 2002, pp. 463-464.
(c) Copyright 2013 by Preston G. Smith. All Rights Reserved.