Estimating the delivery date for a software application can be notoriously difficult. Miscalculations of 100% or more are surprisingly common. Let’s examine a couple of possible situations.
1) You’re working in a software-as-a-service environment like Salesforce.com or Microsoft Dynamics. The stakeholders want to know how long it will take to add a simple feature. You ask a few questions, indicate where the risks lie (if any), then offer an estimate (probably not more than a week or two).
Barring interruptions, the chances of delivering on time are high. Even if you don’t deliver exactly what the stakeholders envision, it will likely take only a day or two to fine tune the solution.
2) Now imagine your team needs to build a custom software application. You might use Java, C#, C++, Ruby, PHP, or Perl. There might be software components from prior projects that you can leverage but they’ll likely need some rework. You’re asked to estimate a delivery date.
You ask questions and identify risks but the real issue is the lack of business requirements, use cases, or epics. All you have is a description. You might even have a product vision statement, but that’s unlikely.
The team will have to rely upon its experience. Familiarity with the software tool set and the type of application being requested will help in scoping the solution. Of course, the stakeholders need an immediate answer so they can establish a budget for the project. No time for detailed analysis. Now the fun begins.
Assume the team brainstorms for a day or two and estimates that 5 people can deliver the software in 6 months. Six months is about 130 business days. Multiply by 5 people to get 650 person-days or 5,200 person-hours.
Ideally, the team should offer an estimate range rather than a single number. 5,200 hours becomes an official estimate range of between 4,000 (80% of 5,200) and 6,500 (125% of 5,200) hours. (The 80% and 125% numbers are only examples. Smaller or larger values will apply in different situations.) The team also offers lists of assumptions and risks.
Do you see the problems here?
Scenarios like the above play out every day in companies around the world. The stakeholders offer an over-simplified description of what they want. Then they ask, “How soon can we have it?”
High-level, broad-based software estimates are almost worthless. For a large, complex system, an estimate of X hours may translate to a range of X/2 (50%) to 4X (300%). You read that correctly — from one half to four times the estimated effort. Where’s the value in such a wide ranging estimate?
Of course, there’s rarely sufficient time to produce an accurate estimate — a narrow range. Such an estimate may take anywhere from a couple of weeks to a few months depending upon the situation complexity. Everyone wants instant answers and rapid delivery. There’s no time to do it right.
What should you do? Go agile!
Tell the business stakeholders what they want to hear. You can deliver the software anytime they want — as long as they are willing to scale the feature set to align with the timeframe. Once the initial feature set is delivered (on time, by definition), features will continue to be added through a series of incremental releases. When money runs out, the project is over and there’s little or no waste.
Everybody wins. And luck isn’t a critical success factor.