The views expressed in this article are strictly those of Max Wideman.
The contents of the book under review are the copyright property of the author.
Published here February 2017

Introduction | Book Structure | What We Liked
Downside | Summary


This book has a sub-title that reads: "What every executive needs to know to avoid costly mistakes and make major investments pay off".[1] That sounds like a good recommendation. And as we get into the book, we find that author Paul Barshop's intent is to make a convincing case for applying the concept of a Stage-Gate process to the project's basic technological life span.

Moreover, as that sub-title indicates, the book is aimed squarely at the executive level of an organization conducting a project, or contemplating doing so, especially where the project is of significant capital value. Unfortunately, as the author notes, this topic is sometimes met with some skepticism with comments like: "Oh no — not another presentation on the stage-gate process!"[2]

Paul Barshop explains it this way:[3]

"... the fact is, it is the only approach that has ever been shown to work long term. A more complete name is the 'stage-gate project development and delivery process' [see Figure 1]. The process contains five distinct stages with gates between the first three stages, which are referred to as the front-end of the process. Each stage has a set of requirements for the work to be completed in that stage. That work is used by executives at each stage-gate to decide whether the potential benefit from the project justifies the expense for completing the next stage. The Define gate is the point in the process when executives authorize the full budget to complete the project." [Editor's Note: Approval of the Define gate results in project Execution, which includes the preliminary work of Detailed Design.]

Figure 1: The Key Questions Asked and Answered at each Stage-Gate
Figure 1: The Key Questions Asked and Answered at each Stage-Gate[4]

At this point, we think that Paul might just as well have responded: "So do you want to control the project cost or don't you?"! The fact is that once a project is initiated, i.e. at the Start point, the project travels through time whether we like it or not. That is, unless we actively stop it. Of course if we don't care about the cost, we can sidestep all of this, and withdraw from any cost responsibility. But then, that is not even project management, let alone best practice.

And yet, a surprising number of folks in the project management community either do not concern themselves with the so-called front-end work, or do not consider it a part of so-called project management. We suspect that there are a number of reasons for this, such as:

  1. It is somebody else's responsibility.
  2. It is a part of the "Project's Life Span" and not a part of the traditional "Project Life Cycle" as promoted by most professional associations.
  3. The detailed content of the Stage-Gate process is dependent upon the type of project in question. That is, it has to relate to the management of the technology involved, and hence is the responsibility of the project's technical manager, rather than the project's management.

And yet, in reality, successful project management (of a single project) is highly dependent on the work done by whom-so-ever-that-may-be, and is the essential bridge between Single Project Management and the Management of the Technology.

In our view, author Paul Barshop succeeds admirably in getting his message across, by using simple explanations and extensive practical examples. Indeed, his book does provide a valuable lesson, especially to corporate executive levels, including anyone whether "executive" or not but charged with the responsibility for the conduct of a large-scale project. The book is written for the private sector where: "capital projects are investments of substantial company resources to develop, to improve, or to refurbish an asset that is expected to generate cash flows for more than one year."[5] Nevertheless, the advice provided is equally applicable for those in the public sector, or even the not-for-profit sector. Failure of projects in these areas may not be measured in terms of "value erosion"[6] like the private sector, but can certainly be measure in terms of loss of popularity and future voting patterns.

About the author

Paul Barshop is a Director of IPA Capital Solutions, a new IPA business initiative to provide hands-on support to clients implementing changes to their capital project development and delivery systems to improve performance. Paul was IPA's Chief Operating Officer from 2004 to 2015. He previously served as Director of IPA's Netherlands Office from 2000 to 2004, serving European and Middle Eastern clients. Paul joined IPA in 1994. In his early years at IPA, he served as Quality Manager and Project Analyst. Paul holds an M.S. in Business Administration from Boston University, Boston, Massachusetts and a B.S. in Chemical Engineering, New Mexico State University, Las Cruces, New Mexico.


1. Barshop, Paul, Capital Projects, John Wiley & Sons, Inc. Hoboken, NJ, USA, 2016, book cover
2. Ibid, p17
3. Ibid
4. Ibid, p179
5. Ibid, p3
6. Ibid p8. Value erosion occurs when what was actually delivered by a project is lower than what was promised when the project was funded.
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page