If you can meet with Triumph and Disaster
And treat those two impostors just the same;
- Rudyard Kipling, If, 1910
Every few weeks, someone will start a discussion on a website about what constitutes project “success” and “failure”. Frequently, an advocate for a specific methodology (CCPM, Scrum, other agile) will quote some study that reports success was far greater when using that methodology than with the “Brand X” methodology (often referring to “the PMBOK approach” or “waterfall”, whatever those are intended to mean). At this point, someone will ask about the criteria on which the study’s categories of “success” and “failure” are based. Invariably, it’s “Original scope delivered on time and on budget.”
That paragraph above incorporates so many unsupported assumptions and ill-defined concepts that it poisons not only comparative studies, but the very way we manage projects.
Let’s consider how project parameters, the very ones that are used to judge success or failure, are set. The scope/cost/schedule objectives are usually laid out at project initiation, whether by a project charter or by a contract. At this time, the product scope (i.e., the features of the final product) may be fairly well defined – but the project scope (the work that must be performed to generate the product requirements) rarely is. If needed work may be overlooked, that means that planned duration and cost can only be estimates whose accuracy may be impacted by a host of factors: accuracy of historical data, risk aversion and estimator tendency, as well as project team skill and experience.
Yet these highly variable goals are the basis for the metrics on which project performance is then judged in all those studies.
Let’s imagine two projects with identical scope:
- The parameters for Project A, set by individuals who believe that tight strictures drive better performance, are 10 months and $1.0M.
- For Project B, the parameters are looser — 12 months and $1.3M.
The team performing Project B has enough time and money available. It does minimal planning, uses its budget to plug in resources when it sees they are needed, and completes the project without much trepidation. It uses the full 12 months and $1.3M, and enters the study’s spreadsheet in the “SUCCESS” column.
Conversely, the team performing Project A rigorously applies the appropriate planning techniques: WBS, rigorous quality checks, critical path analysis and optimization, resource loading and bottleneck resolution. A 10 month schedule with one week of reserve is assembled and then executed industriously. But with three weeks to go, a test uncovers an intermittent problem. The resulting rework fragnet has almost three weeks of critical path drag and costs $100K. The project is completed in 10.5 months for $1.1M and thus enters the study’s spreadsheet in the “FAILURE” column.
Remember, the product scope was identical – only the performance parameters were different. But our FAILURE” project actually took less time and cost less.
If these two projects were performed by competing organizations, which one is more likely to survive and thrive? Which project was actually performed better? Which team solved those issue(s) for which the project was undertaken faster? Which enjoyed the benefits of reaching the market first?
Gary Heerkens starts his “The Business of Projects” column in the December 2014 issue of PM Network by asking: “Which is better: a project that runs on time and budget and meets its objectives or a project that runs late and is over budget but overachieves on cost savings that have a ‘change of life’ impact?” This is the same issue that I raised above, only dressed in different clothes: How should we judge project performance? Because that is the factor that drives so many of the decisions that project teams must make. And Gary is taking the lead in voicing the concern that so many project management theorists are recognizing: the current approach is wrong in that it ignores the project’s business value, and that needs to be fixed!
As the title of my newest book Managing Projects as Investments suggests, the value the project is expected to return and that is the reason for its funding must be a prime metric in all decisions and judgments about projects. To do otherwise is to say: “The team scored seven goals, but despite playing so brilliantly, lost 8 to 7.” Or perhaps, in more stark terms: “The surgery was successful but the patient died.”
As I launch these columns into a new year, I will explore in ever greater depth this new “business value” approach to project management. Meanwhile, if you want to fully understand the concepts and techniques I will cover, I urge you to read my book and ask me questions or raise issues right here in the blog.
Happy New Year!
Fraternally in project management,
Steve the Bajan