John Goodpasture has a post on estimates from Fred Brooks. Fred's quote, which I'll repeat for effect, from John's site is
It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers.
In many domains, estimating is performed in ways similar to Fred's description. Here's some phrases found in RFP's from the Defense Department:
- The estimate must be easily traceable from the lowest level at which the Offeror’s estimate was substantiated to the CLIN.
- When using historical data, the Offeror should describe why the system is comparable to the proposed program. This includes a functional and technical comparison explaining the differences as well as similarities between the historical and the proposed system. Also include an explanation of the relationship between the analogous element cost and the total program cost.
- Adjustments to derive the proposal estimate relate to reasons and justification for any adjustments made to programmatic, technical and actual cost data for the historical system. The Offeror should provide the basis and document any adjustments applied to the historical data (e.g., complexity factors and normalization methods) that reflect the characteristics of the proposed system. This includes an audit trail sufficient for the Government to reconstruct the proposed estimate and judge its credibility.
Now these are heavy duty words, probably not applicable outside the procurement of similarly heavy duty weapons systems.
But as John points out through Brooks' quote, to do otherwise is complete nonsense on anything but a trivial project.
So wjy does this continue to be the practice in many areas? Some would say, it's because IT projects are software projects and you really can't estimate software projects. To this I say frankly - BS. The program we work int he defense are predominately software development projects. Software development with emerging requirements, changing requirements, state of the art technology, all the things IT project managers encounter.
My personal opinion is
Project estimating, and project management is hard work. Software development is fun work. Still hard but fun. Project Management is hard work, with almost no fun.
So why work on something hard if it's not fun? Secondly, there is no real downside for missing estimates in the commercial IT world. Oh sure, there is hell to pay, people get fired, the project gets canceled. But the company rarely goes out of business, people never die, launch dates are rarely missed. I'm not talking about silly commercial product launch dates, I'm talking about launch dates to Mars, launch dates for NRO (National Reconnaissance Office) launch dates. Those kind of launch dates.
What's missing is the discipline - at appropriate levels of course - to "do the right thing." That's the root cause of most problems in the commercial world - pure missing discipline.
It's the Micky Rooney school of management. Where Micky and Judy Garland are in the alley behind a NYC theater, when they say to each other and their friends...
Hey guy, I have an idea, let's put on a show
It's that, let's get started and see where this goes, kind of approach to project management. Where it goes many times is straight into the ditch.
