Among his observations and examples of misuse and abuse of the project's management reserve (MR), he lists these tricks (paraphrased and translated for the non-defense project audience, so these are not a direct quote of Solomon's remarks)
Rework--in other words, error of feature, function, or performance requiring correction--is not included in the budget (though it's reasonable to expect some rework as part of the natural variation in the design and development processes). Rework is identified as a risk (on the risk register) and money to fund the risk response is included in management reserve (MR). Later, funding is transferred from the reserve to the budget when the design or test item does not meet, or no longer meets, technical requirements.
Cost drivers such as software lines of code (LOC), number of drawings, hours per drawing or per LOC, are understated (justified as aggressive interpretation of bottom up estimates) compared with empirical data and realistic estimates. The low ball estimate is called “management challenge” and identified as a risk, not an issue. Later, funding from the management reserve is transferred to the budget to cover the risk.
The same conditions exist, as above, but no “risk” was identified. Instead, the additional iterations are called “scope growth” even though the basic tasks were planned in the budget
The number of tests (and resultant rework and problem reports) is understated based on realistic estimates and empirical data. Later, the tests and rework needed to meet technical requirements are funded from MR as “additional scope” even though the customer requirements are stable.
Work that could not be completed internally is transferred to a supplier. MR is used under the pretext that it is “additional scope” or “unplanned.”
So, you might ask: what's the management reserve for if not to fund problems not foreseen? That's Paul's point exactly: rework--at least to some extent--should be in the baseline so that the project's cost is not a matter of deliberate deception. So also for the other practices. In other words, trust and integrity, so valued in the implementing teams, starts at the top. No news there, but never a bad thing to review.
Of course, these practices are not exclusively in the defense domain. Try big time construction if you want more examples. This is Bent Flyvbjerg's favorite topic, as depicted in one of his articles, "Design by Deception: the politics of megaproject approval"
Good grief! Is there no one on top of this?
Are you on LinkedIn? Share this article with your network by clicking on the link.
