I share, with many others of the anglophone Caribbean culture, a propensity for exaggerated over-the-top hyperbole. And no, I’m not being redundant – any one, or even two, of those three terms would often be insufficient to describe the extended lengths to which we will sometimes go to draw attention to the point we’re trying to make.
As an illustration, there is the old story of the Bajan visiting London who is trying to describe the wonders of his home isle.
“In Barbados, we have mountains of sugar, rivers of rum, and fish that fly!”
To which, of course, the Englishman replies: “I might believe in the mountains of sugar and the rivers of rum, but I’m damned if I’ll believe in fish that fly!”
So in my previous article, “Whaddya Do When the Critical Path Changes?”, I resorted to a little (for a Bajan!) hyperbole. I wrote that when the critical path changes, “sirens should wail.” And I was, quite properly, taken to task by a couple of people, including Shelley Horowitz in the Comments following that article, for suggesting the need for a state of alarm or danger due to such a change. And the criticism is quite correct. A half century spent in US cities, where sirens are an everyday occurrence, has perhaps combined with my West Indian exaggerations to dull me to the fact that, for many people in the world, sirens really do represent danger and appropriate panic: fire, tornadoes, tsunamis…
So I am taking this opportunity first to apologize, and then to explain in greater depth exactly what I meant.
The exact sentence in that previous article was:
“What should happen immediately is that sirens should wail, warning the project manager that Activity H, with a value-added of just 20% of $350K, or $70K, now has a negative NVA due to the fact that it now also has drag of 2 days and thus drag cost of $50K.”
So let’s eliminate the need for sirens. What I was suggesting is that a change in critical path during project execution can have a major impact on the future project plan. Work that made sense to perform in a certain way may now be a significant drag (!) on our project investment, requiring new analysis.
Notice, the key event as described in the quoted sentence above is NOT that the critical path changed — it is that this change caused specific activities to now have a negative impact on the project’s expected value! The project would now be better off without the optional Activity H, because its true cost is now greater than its value-added. And this is a potential hazard any time that the critical path changes.
But the problem is that such an event, as described in the linked article, would most probably not even be recognized. Or if it were, it would only be after a great deal of “manual” analysis. Even on a schedule of 100 activities (never mind a medium-sized project of 2000+ activities!), the chance of the scheduler or project manager noticing that one or more activities are suddenly costing more than they are worth is vanishingly small. Why? Because few of the techniques that would allow such a negative anomaly to be noticed are being used:
- Projects are not being defined as investments, so that expected monetary value (EMV, or NPV or ROI or any other investment value term you like) and its changes are not being incorporated into the PM software and tracked and optimized either upfront or during performance. The vast majority of commercial software packages do not provide a project-level field for attaching quantified investment value to a project, nor the functionality to manage and track changes that might affect it.
- The value-added of specific work packages is not being estimated and assembled into a value breakdown structure (VBS), so that in the diagram from the previous article the value-added of Activity H would be unknown.
- The value/cost of time, which usually has significant impact on project EMV, is not being estimated or tracked on most projects, and certainly not in the software. This in turn makes it impossible to compute either the drag cost or the true cost of an activity.
- Even on that small minority of projects where the value/cost of time is estimated, critical path drag and drag cost are not being computed. This means that the true cost of Activity H, and the fact that the slippage it is now making the net value-added (NVA) of Activity H negative, is therefore completely unknowable!
Notwithstanding my previous remark, what should happen when such an event occurs is not wailing sirens. Rather, the user’s PM software (MS Project, Primavera, or whatever) should take the info that was entered up front regarding the VBS and the value/cost of time, compute the new drag, drag cost and true cost totals for each new activity on the new CP and kick out an exception report, calling attention to Activity H, perhaps by highlighting it in red (preferably, fire engine red!). And now the team/PM can reassess and amend the plan.
But first, the team has to recognize the issue. And currently, none of that can happen because with the exception of one software package (Spider Project), none of the others (not MS Project, not Primavera, not Asta, not PlanView, not Safron, NONE!) is even computing critical path drag, far less supporting a VBS or drag cost, true cost, and net value-added computation! (And they should, because every project has a critical path, and critical path items have drag and drag cost!)
And that’s why projects are being performed all the time that generate less expected project profit (EPP) than they might because they include work whose true cost after a critical path change outweighs the value that it adds.
If you want to learn more about assembling a VBS and the other techniques mentioned above, they are explored in much greater detail in the new (2015) edition of my first book, Total Project Control: A Practitioner’s Guide to Managing Projects as Investments.
Again, thank so much to those who criticized my “siren” hyperbole and for making it clear that I need to post another article pointing out the implications (and cures!) listed above.
Fraternally in project management,
Steve the Bajan