Software Estimating

Pawel commented on the previous post about the difficulties in making estimates of duration and cost of software. From an introduction to a seminar conducted by the 309th SMXG in Ogden Utah.

One of the most dominant and serious complaints arising from the "software crisis" is the inability to estimate with acceptable accuracy the cost, resources, and schedule required for a software development. Traditional intuitive estimation methods have consistently produced optimistic results which contribute to the too familiar cost overrun and schedule slippage.

One of the biggest problems in the this area - in my opinion - is the naive approach to the discussion of the problem. It goes like this

• The software team comes up with a credible estimate of duration and cost. The proposed values are unacceptable to the stakeholder. No good reason other than they themselves have done a poor job of estimating. The conversion ends, because the software staff does have sufficient clout to stand up to management. No models, no past performance, no measurable data.
• When work starts and then overruns - for what ever good or bad reason - there is little understanding of how to use that information to re-forecast the future.

One of the powerful concepts in Agile is to time box the work and perform work essentially as a "level of effort" task. This is the basis of the notion of Velocity.
    By the way

What good is velocity of we don't know the distance?

Our 18 y/o son is training for his first serious triathlon in the spring. As a moderately serious road rider, he has ridden with our over-50 group many times. The triathlon has a road bike section of 36 miles. "No bad Dad, it it's that long and goes over relatively flat roads - for Colorado." "yea" I say in my best Fatherly voice. "Depends how fast you ride that 36 miles." The Tour of California had prologue yesterday of in individual time trial of a measly 2.5 miles. Very short distance over flat streets. But of you ride that 2.5 miles at 36MPH to get under 4:30 to be in the top 10 - that's called "motoring" in cycling slang.
    So knowing the distance - how much work is contained in the end-to-end project, is mandatory to have velocity be of any use.

So What Can We Do About Estimating?
First recognize estimating is a profession, in the same way writing Java is a profession. No everyone is qualified to be an estimator. Next acknowledge there are formal and rigorous approached to estimating and there are less rigorous and formal approaches. But try and learn something from the formal approaches. I grew up on COCOMO Independent of the usefulness to your specific project COCOMO II needs to be understood in order to understand how the estimating process works.
    What is fundamental to COCOMO and all formal estimating processes - is they are calibrated. If you making uncalibrated estimates you're smply wasting your time and the time of the stakeholder. You're making up numbers that have no basis in reality. Here in the A&D world the numbers are derived from the "basis of estimate." This means no one can make this stuff up, it has to come from some underlying process.

    There are other tools:

• EstimatePro is one I've used.
• Steve McConnell has a book on the topic
• Price
  
• SLIM

Don't like these - they're too formal, not agile, too "waterfall-ish" for your tastes. Then something else. But don't blame the lack of models, tools, and process on poor estimates. Don't forget.

Project Cost, Schedule, and Risk Estimaitng is a Profession

Treat it like someting else and you get Professional Amateur results.