Hoisted On Our Own PM Petards?

 

Since my undergraduate degree is in English, and I have a particular affinity to the works attributed to William Shakespeare, I was somewhat taken aback to learn that the phrase “hoist with his own petard” originated in Hamlet (Act 3, Scene 4, the “Closet Scene”). In this particular case of ironic reversal, Hamlet is referring to the scheme between Claudius, Rosencrantz, and Guildenstern to have him murdered during a trip to England. I used to believe that it meant to be hung with the noose that the schemer had tied for someone else; in fact, it means to be blown up by a bomb created by the bomb-maker himself. In a play full of ironic reversals (Laertes is killed by the saber he himself had poisoned; Claudius is forced to drink the poisoned chalice he had intended Hamlet to drink, among others) this particular reversal remains ensconced in modern English idiom; even those who have no idea what the archaic meaning of “hoist,” or any idea at all what a “petard” is (or was) knows the meaning of the phrase. That is, perhaps everyone except Project Managers.

Not all PMs, to be sure, but a dangerous percentage. My regular readers know that I’ve spent considerable computer pixel-ink on the perniciousness of Processors, those claiming membership within the PM community who are more interested in making project teams obey what they consider the right way of doing PM, as opposed to Producers, who simply bring their projects in on-time, on-budget. The Producers know, often intuitively, that even simple Earned Value and Critical Path systems can produce extremely valuable cost and schedule performance information, information without which their jobs become extraordinarily difficult. Ah, but there’s the rub, as the melancholy Prince of Denmark might say. Processors know this too, but have no intention of allowing the notion that simplified systems will still deliver powerful information streams to become commonly accepted. No siree, these Processors are out to make a buck on their idle musings, and want the Producers to be the ones to pay.

The strategy to monetize their flawed business models is as familiar as it is transparent. They set up an approach similar to the jaws of a vice. The first premise is one that’s indisputably true: to track cost and schedule performance on project work, the Earned Value and Critical Path methodologies are irreplaceable. Projects that had eschewed these methodologies early in the project cycle ended up failing spectacularly, and remain as cautionary tales for any major project’s manager who believes himself to be so advanced as to not need such traditional tools. Critical Path and (especially) Earned Value are simply indispensable, and any PM claiming to the contrary is going to experience a major PM debacle. Oh, maybe not the very next project, or the one after that. But, sooner or later, it will happen.

The other jaw of this vice is where the Processors come in. You see, Earned Value is really a very simple concept. By placing a value on how much of the projects’ budget has been actually accomplished, or “earned,” much valuable information can be gleaned. In fact, the calculated Estimate at Completion (EAC), arguably the most valuable piece of Project Management information out there, can be accurately and reliably derived from two parameters: cumulative percent complete, and cumulative actual costs. That’s right: divide the former into the latter, and you have an estimate that’s been shown to be consistently accurate to within ten points of the real at-completion costs. Something similar happens in forecasting when the project will finish, based on performance. Divide the percent complete figure into cumulative duration, and you have a reliable estimate on total duration. It really is that simple.

“Not so!” claim the Processors. They will insist on a long list of both marginally and completely superfluous data collection and analysis techniques, such as:

• The time-phased budget must be derived using up-to-date resource dictionaries.
• Ditto for the Basis of Estimate.
• Variance Analysis Thresholds must be set tightly, as tight as possible.
• Ditto for Change Control Thresholds.
• Did I mention Change Control? The members of the Change Control Board must be highly educated and diverse stakeholders, some of whom probably hate your project.
• Time-phased Estimates to Complete, comparing the original Basis of Estimate to the actual costs on a line-item basis, “bottoms-up” Estimates at Completion…
• And don’t get me (re-) started on risk management.

I could go on (and often do), but you see my point. The second jaw of the vice, that of an overly-complex EV system being required, because, well, reasons, is pushing the whole concept of setting up and operating such systems into insufferable, if not intolerable territory. Already Earned Value is being slandered with a reputation of being so difficult and onerous to use that the newbies in the PM world avoid it like it’s a curse.

And here’s the ironic twist: many self-identified “experts” within the community are the ones larding up these Management Information Systems with the unnecessary requirements that make them less likely to be widely accepted, or employed. I would normally make some plea here, along the lines of “Hey, guys, we’re doing this to ourselves,” except for the fact that that’s not entirely accurate. The Processors are doing it to the Producers. Maybe it’s a sort-of payback for all that success that the Producers produce, while laughing at the Processors behind their backs.

Just keep in mind, you Processors: Fortinbras doesn’t know nor care about the subtleties or murderous machinations of the Danish Royal Court, and yet he’s the one crowned king at the end of the play.

And very few of the rest of them had a happy ending.