Ten Things that Need to be Said Regarding Project Management

There are lots of articles around as to why projects continue to “fail”. Project management techniques (of all flavors!) have been adopted sporadically. They have helped only slightly. So I’m writing this SHORT article to focus on the causes of what so many term “failure”.

My main goal in this article is brevity: shorter durations, shorter definitions, shorter explanations! If something isn’t understood, feel free to ask about it in the accompanying discussion thread and I’ll try either to respond or to provide you with a link to another article/book where it’s explored.

Finally, I’m listing these in descending order, starting with what I regard as the most important:

?

1. ALL projects are investments and therefore results can only be judged in terms of the value they were undertaken to generate. To argue otherwise is to suggest that stakeholders would like less ?return on their invested funds. (Really?) Yes, they may accept constraints—financial, legal, moral—that limit ROI. But value generation that is limited by incompetent planning, scheduling, work, or product quality is not something they will—or should—accept. I believe that once judging project performance as we would any other investment becomes standard, new techniques will blossom and project management will become much better!
2. If during both planning and performance the data are omitted regarding: (a) how much value the scope is expected to generate if (b) schedule and cost specifications are met/exceeded/reduced (and almost all PM software packages ignore the expected value of scope and the value/cost of time!), how can the team ever make good investment decisions?
3. Project results are almost always not binary but relative: better or worse, or more or less value for the cost/investment. So the urge to judge as “success” or “failure” will almost always—well—fail!
4. The expected value of the project and how it will be impacted by time (acceleration or delay!) should be THE determining factor in setting the priorities of projects in a portfolio. Without those data, how can one ever allocate resources wisely across the projects and their critical paths?
5. Unlike most other investments, project results can be managed. Therefore good project management, including planning and scheduling, is extremely valuable! The commoditization of project management through certification programs aimed at maximizing revenues for the certifying organization (while ignoring the fact that really good project management can greatly increase return on the investment) will doom a significant percentage of projects as long as that attitude remains.
6. Product scope generates the value of the project to the stakeholders. The process of scope definition is therefore the most important attribute to plan and therefore requires (i) a PM who is adept at eliciting and synthesizing that information; (ii) using a value breakdown structure (VBS); and (iii) stakeholders willing to participate fully in this process! For stakeholders to expect good project/program results without such a process is absurd!
7. Every project is exactly as long as its longest path. That’s why critical path analysis is so important! And, amazingly, the two critical scheduling metrics (critical path drag and drag cost) aren’t even computed by the vast majority of project management software. (Seriously: can we really criticize those project methods touting “agility” and claiming that advance planning adds little value [despite thousands of years of human experience, going back at least to the leaders of both sides in 480 BCE at the Battle of Thermopylae, that demonstrate its value!] when THE CRITICAL scheduling metrics remain unknown and unsupported?)
8. Those who argue for “greater agility” are correct! Unfortunately, what so many seem not to recognize is that traditional PM’s work breakdown structure is THE tool for managing scope changes! That’s why traditional PM sometimes develops a “template WBS”—attached to a CPM schedule—for use when the precise scope for a given project won’t be defined till each specific project is ready to start. Of course, it’s also true that many organizations take an overly bureaucratic approach to any project changes. They seem not to recognize that projects always change, and that adapting to the changes in the BEST way is what project management is all about! Agile approaches are largely a reaction to the inefficiencies caused by organizations that confuse rigor with rigor mortis. ?
9. Contracts for projects are almost always abysmally written, usually by people with close to zero knowledge of the nature and techniques of project management! They create moral hazard through the “Principal-agent Problem”, where there is misalignment between customer benefit and contractor benefit. This leads to inefficiency (usually blamed on bad project management, when the fault is in the contract) and dissatisfied customers—but it also often leads to wealthy attorneys!
10. Whatever we’ve been doing wrong, we need to correct it—because projects and programs ain’t going away! More and more of the world’s effort will be associated with them. And that means the cost to humanity of inefficiencies—in dollars and in human suffering and mortality—will just keep climbing! Yes, construction and aerospace could do better—but they are paragons of efficiency compared to other industries that are just becoming aware of the value of good project management: health care and public health, pharma and medical devices, finance of all types, education, law enforcement, academia, emergency response, and—yes!—software! (The trouble is: most of those organizations have little idea what good project management is!)