Death By Quality

 

There’s a story that at the onset of Operation Desert Shield, the United States’ and her allies’ effort to kick Saddam Hussein out of Kuwait, that the Pentagon had sent out a clue that something big was about to happen by inundating the nearby pizza delivery restaurants with so many orders that it was clear that the employees were going to be there through at least dinner time.

As I’ve discussed previously, project management information systems that deal with actual project performance – Earned Value and Critical Path methodologies-based, all others being fake – have two overarching functions: (1) to put into the hands of the project teams’ decision-makers the information they need to select the best strategies, and (2) to provide a narrative after-the-fact as to what happened, and why, as the project pursued its objectives. The first of these functions can be established relatively quickly and easily since (as I have also discussed before) both Earned Value and Critical Path can provide essential performance information without many of the formalities often associated with them, such as highly detailed cost estimates or intricately linked schedule baselines. The providing-the-narrative function, however, does need this level of formality and detail. But, like the Pentagon swamping local area pizza restaurants, there are going to be times that the prescient project manager does not want the particulars of her project’s narrative known to others, even if they do assert a claim to being a “stakeholder.”

The reasons for this are many. The particular project may have national security issues, or may involve the use of techniques or technologies that represent trade secrets. It may be as simple as the project team’s organization not wanting to share its insights on how to execute projects with its competitors. Whatever the reason, the very project management information systems that constitute the life-blood of informed decision-making can also be used against the owning organization and, in my humble opinion, this represents a quality issue.

So what we have with respect to assessing the quality of project management information systems are two essential, but potentially overlooked, components: the level of difficulty involved in establishing the information stream, and the potential for mis-use of that very information once it becomes available. In each instance, quality control plays a central role, and it’s not always positive. For example, the notion that a project’s cost baseline must be considered to be of poor quality if it does not take into account the most recent rates for labor, equipment, or any other line-item in the basis of estimate (BoE), is simply false. Perfectly usable and effective cost baselines can be (and are) created with budget estimates rather than detailed estimates, and those insisting that only detailed estimates will do are misguided. Depending on the project’s size and complexity, putting in the extra effort to create a detailed estimate (and it’s not cheap) will often lead to the attempt to derive other, irrelevant information from the cost baseline, such as the difference in price between the individual elements from the BoE and the same-time period actual costs. The fact that comparing budgets to actuals is useless is axiomatic among the better cost engineers, and this fact does not change simply because the comparison is occurring at a far more detailed level.

I’m sure many (if not most) of my readers have recognized a surge in the demand for schedulers who are adept at performing – not the creation and maintenance of Critical Path networks, but forensic analyses of projects that are either nearing completion or are complete, and some sort of claim/counterclaim is going on. This gets back to the narrative-building aspect of these information systems, and needlessly-detailed baselines are a gold mine to plaintiffs in these challenges. Any deviation from the original plan, no matter how innocent or appropriate, can be mis-interpreted as a quasi-breach of contract, essentially leading to the excusing of poor performance from subcontractors due to the collection and placement of irrelevant data in the project’s baselines.

But, hey! At least those who insist that quality baselines are synonymous with extremely detailed baselines are happy!