Software project estimates – the brutal facts | submitted by Robert T. Merrill

It seems everyone’s heard of the Software Project From Hell. It took on a life of its own, chewing up money, time, and people before arriving at an outcome that no one would have picked at the outset. An entire book, Software Runaways, tells the stories of projects that didn’t just fail, but brought down entire companies and destroyed lives in the process. (I had to stop reading it – it was that traumatic.) If you think it’s IT’s fault, bear with me. If you are a business executive, you are able to make changes that will have a bigger impact than anyone else. From my series of IBMadison.com blog posts, you’ll start to learn how.

You deal with estimates all the time

As businesspeople, you use estimates all the time. You create or are handed numbers like projected sales, materials prices, health insurance premiums, and interest rates, and you budget for ongoing activities and fund new initiatives (or not) as best you can. Most of the time you have past figures to use as a starting point, and a way of adjusting them up or down. The longer the time frame, the less familiar the activity, and the more variables outside your control, the more likely the estimate is to be wrong. But you have a feel for that, and ways of dealing with it, too.

But software estimates are worse

One point I’ll belabor in this blog is that software is a new class of business asset. So don’t beat yourself up if a software initiative you’ve sponsored got away from you. They’re like things you’ve managed successfully before, but they’re also different, and sometimes the differences are really important. Estimation and planning represent one such difference. The numbers just aren’t as reliable as what you’re used to in other areas.

Just how inaccurate are they? The best way to know, if you do enough projects, is to keep track of estimates and actuals. But doing this without actually making things worse costs money (a percent or two of total project costs) and requires expertise in software metrics. So, if your firm is like most, you have to rely on outside figures. Prepare to be shocked.

The source is listed under “Additional Resources.” The labels across the bottom may not make complete sense, but just look at the ranges. At “Requirements Complete,” the actual outcome will probably be between 2/3 and 1-1/2 times the estimate. And getting to “Requirements Complete” typically takes around 10% of the project cost – it’s part of actually doing the work! Back up to “Approved Product Definition,” the point at which you probably first see an initiative, the uncertainty range is something like a factor of four. Is there anything else that routinely has this kind of uncertainty at the point where you decide to proceed or not?

The first step – confront the brutal facts

My title comes from Jim Collins’ Good to Great. “Confront the brutal facts, but never give up hope.” Most organizations don’t even know the brutal facts (though they might suspect them) and they sure don’t confront them. Instead, they set targets, extract commitments under some level of duress, and make often-desperate mid-course (or later) corrections. Some executives resort to carrot, stick, and scapegoat, since they don’t know what else to do, and the resulting politics and gamesmanship fill a whole page, Estimation Games, on an Australian consultancy’s website. They muddle through. But without much insight into what’s happening and why, that’s about the best that can be said for it. No wonder everyone has a software project war story.

Given this sorry state of affairs it might be hard to believe, but you can start responding to the brutal facts in ways that will give you not only hope but consistently positive results. What’s better, by taking the initiative as a senior leader to respond in more insightful ways, you can do more to improve the selection and outcomes of your software initiatives than anyone in your IT organization. You can do far more about the software estimation problem than you think.

Additional Resources

Steve McConnell’s 2006 Software Estimation: Demystifying the Black Art, is probably the single best book on the subject, and is useful to both creators and users of software project estimates. And I love the title!

Mike Cohn’s 2006 Agile Estimating and Planning contains material, especially on estimation early in projects, that is useful even if you’re not an Agile shop.

Robert Merrill is the principal of uFunctional LLC, a Madison-based consulting practice helping organizations get more value out of their software investments.

Sign up for the free IB Update – your weekly resource for local business news, analysis, voices, and the names you need to know. Click here.