Estimating the cost of software is, at best, an educated guess.
We try to pretend this is not the case, yet despite all the new ideas and models, software is still costed in the same way it was when I left university 20 years ago. There are so many complexities in software estimates that it ultimately relies on the judgement and informed opinion of the software creator.
Errors detected during requirement phase account for 40%-60% of defects.
We typically estimate software by doing variations of the following approach:
- We deconstruct the software system along functional boundaries. This is simply functional decomposition of the system, and the result is often a requirements document. We often have a different understanding to that of the customer, so requirements documents are often a ‘best first guess’ of what the system needs.
- Programmers estimate how long it would take to build each component.
- Some contingency factor is then applied. This contingency factor goes by various names such as ‘transactional complexity’, or ‘risk assessment factor’ and are gross multipliers often by up to +/- 150%.
The result is an software estimate that can vary by +/-50% of the final cost. This is such a large margin of error that I would consider it a good guess and nothing more. In comparison to a real science, we know the speed of light to an accuracy of plus or minus one part in 300 million .
Professional consultants will point out that 100% of their project are exactly on budget, but this is often done by false accounting. For example, the quote any changes to the initial requirements as a separate project even though the we know that the initial requirements are incorrect by 40%-60%. In an even more egregious example, software might be released on time to the client, but with known defects (i.e. the quality of the product is compromised to meet the time, cost and scope parameters).
The true cost of producing software is hidden by shifting work between different cost centers, or by re-defining what’s ‘in scope’ [also know as finessing scope]. It’s an accepted way for suppliers and customers to lie to each other.
Estimating the total cost of Agile projects
Questions about how to estimate the total cost of Agile projects are questions about how to do fixed-price, fixed-scope contracts. Fixed-price, fixed-scope contracts are adversarial and often mutually disadvantageous, so I wouldn’t encourage them.
How would a team estimate the cost of fixed-scope work upfront? Here are several approaches for you to consider:
Estimate the project the same way you currently do. If the approach that you’re using provides enough accuracy and you’re able to make a profit, then why change? Any other approach is as likely to be as inaccurate as what you have now.
Estimate the project using a coarse scale … such as T-shirt sizing, and then assign a dollar range to each size. For example, have the team work with the product owner to create a list of User Stories at a high level (epics). The team then estimates the epics on a very coarse abstract scale such as T-Shirt sizes ranging from XS through to XL [XS, S, M, L, XL]. Because we’re only concerned with order-of-magnitude and not about accuracy, this should be a relatively quick operation.
We would then assign a dollar range to each size on our scale; XS would be $10,000-$20,000, S would be $40,00-$80, 000, M would be $150,000-$200,000, etc. We would tally up the final figure to give an upper and lower bound for the total cost.
If the customer wanted a fixed price project then we would quote the upper bound figure to compensate us for the additional risk that this might incur. If they’re willing to work on a more flexible basis (say fixed-cost, variable-scope), then we could consider a quoting a lower cost.
Change the conversation. Changing the conversation is my preferred solution, because changing the conversation helps to educate the client that Scrum is more than a different way to do the same old thing … rather it’s systemic change.
This approach is also the most difficult.
To use it effectively requires a mature understanding of the different arguments for and against. It is also a realistic answer to the question of how to determine the cost of software upfront. We don’t know [although we can provide educated guesses].
A more meaningful question is how much does the client value the new software? If the client is unable to answer that question, then perhaps the new software has no value at all and is not worth creating. If the client has an understanding of the value of the software (perhaps through a cost/benefit or ROI analysis) then the breakeven point should serve as then upper bounds of the teams budget.
Taking this approach is not without its risks. There is certainly the possibility that the client will decline our services. Mature agile consultancies understand this and are often willing to walk away from work that results in a mutually disadvantageous arrangement.
A way forward
This post has likely raised as many questions as it has answered. Let me finish by providing a glimmer for a way forward … Agile companies tend to form strong, long-term relationships. How to do this will be the topic of my next blog post(s).
 “Speed of light” from Wikipedia.