Introduction to the Books | About the Authors and Their Books
Book 1 - What Executives Need to Know about Project Management
Book 2 - What Functional Managers Need to Know about Project Management
Book 3 - Introduction | Book Structure | What We Liked | Downside | Summary
Book 4 - Managing Complex Projects

Downside

Unfortunately, from the book's fly sheet to the first paragraph of the Preface, to Chapter 1, even to the very last page, this book is rife with references to the now obsolete and misleadingly-simple construct: "The Triple Constraint".[35],[36],[37] If these constraints must be labeled, we would much prefer to see them described as "The Traditional Constraints"[38] or "Tetrad-Tradeoff", which we feel is more accurate. However, we have already belabored the questionable use of "Triple Constraint" in the Downside of what Executives Need to Know About Project Management.

But maybe salvation is on its way. In a discussion of Redefining the Triple Constraint Success Criteria[39] we learn that: "Actually, the definition of success is completing the project within the cube rather than the triple constraint."[40] A "cube"? Why a cube, with six sides? Never mind, we will quietly refrain from further comment.

In the previous book we reviewed, we observed that the contents were oriented towards project management in those companies involved in contracting. That is, private sector companies providing new product or facility delivery services under contract, or those companies necessarily involved in letting contracts for those services. We conclude that this present book is similarly oriented towards a contracting environment by the statement:

"Capturing best practices has become a business necessity. Best practice libraries are viewed as competitive weapons and can create significant advantages during the bidding process."[41] (Emphasis added)

That indicates that the projects under discussion have a bidding process[42] as a prerequisite for contract awards.

In a discussion of global project management, we learn that:

"Multinational firms are not managing all projects with a single EPM methodology. The methodology is used to plan and execute projects for all customers, all products, and for the entire product life cycle."[43]

However, earlier we were told that:

"EPM systems are usually rigid processes designed around policies and procedures, and work efficiently when the statement of work is well defined. But with the new type of projects expected over the next decade, these rigid and inflexible processes may be more of a hindrance."[44]

If the latter is true, then why the former?

On the subject of "success" we contend that project success is not the same as product success, even though project owners often attribute the latter to the former. In our view, product success is not the responsibility of the project manager. That is not to say that the project manager should be oblivious to the issue of delivering a successful product, obviously not. But in the last analysis, it is up to whoever has final custody of the product, to ensure that the expected benefits are realized and hence establish the product's success by whatever measure.

It may be argued that project managers should expand their territory to include the realization of benefits such as in P3[45] contract arrangements. However, we think not, if only because the personality typology of those suited to managing projects is quite different from that required for traditional management.

What We Liked

Summary

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page