What’s it gonna take? How long before it’s done? How much will it cost?
No matter how often we explain that software development is not a predefined process, ‘they’ always want to know how long it will take and how much it will cost — right up front. ‘They’ are the business users. ‘They’ are the people that pay the bills. ‘They’ have a right to know.
So, what if ‘they’ clearly defined a software idea and wanted to know. Let’s assume ‘they’ provide answers to questions covering the following topics:
- Strategic and tactical business goals
- Stakeholder concerns and needs
- Current business process descriptions and diagrams
- System inputs and desired outputs including reports
- Data volumes and simultaneous users
- Required performance characteristics
- Security needs
Finally, let’s assume that there is an existing application that the new software will replace. This gives the team a sample implementation along with all the likes and dislikes associated with it.
So, what’s it gonna take?
If you were using a waterfall development approach, you’d want to generate requirements and a functional spec. If you’re using an agile approach, you’d want to create high-level stories and prioritize them.
Okay, but all that stuff takes time and the business needs an answer. ‘They’ need to decide whether to fund this project or use the money for something else.
It’s a tough question to answer and there is really only one way to come up with an answer — you need to have experience to draw upon. The more comparisons you can make between this effort and past efforts, the better the estimate you can derive.
Here are some questions to ask yourself and your team.
- What have you done like this before?
- Have you automated a process like this?
- Have you developed software using these technologies?
- Have you had to handle this volume of data before?
- Have you had to deal with this many simultaneous users before?
- Have you dealt with security needs like this before?
The more parallels, the more accurate the estimate will be. In the end, you’ll have an educated guess with a margin of error. The more experience you can draw upon, the smaller the margin of error.
That’s why it’s always best to offer an estimate range. For example, the project will take 13-17 weeks and cost between $x and $x+y.
Keep track of what your team does, how it does it, and how long it took. When something truly new and different comes along, take your best shot. ‘They’ will want to know.
Yes. Folks need some (ballpark) idea of effort and cost so as to make a judgement on whether a particular piece of work is justifiable (by comparison with the expected business value aka business benefit aka business return (ROI) i.e. via cost-benefits analysis), and where to rank that particular piece of work in the list of all other possible pieces of work competing for (inevitably) limited resources.
But I take issue with the idea that accuracy is necessary (or even desirable). And more profoundly, I take issue with the widespread assumption that candidate pieces of work should be estimated with an accuracy far in excess of the accuracy demanded of the “value” side of the equation (too often conspicuous by its absence entirely).
If a particular piece of work promises a marginal return, then maybe accurate estimates would permit a rigorous cost-benefit analysis. But surely those pieces of work offering but marginal returns should be canned in favour of higher-margin pieces of work, anyway?
Further, estimating and building to a specification seems a long way round a short problem. Surely it’s better (less risky, easier to manage) to set a cost-constraint up front (based on eg the expected returns) and commit only as much effort as that cost constraint allows (i.e “we’ll stop or review the situation just as soon as the piece of work has expended its allocated resources)?
– Bob (@FlowchainSensei)
I find it especially important when giving these types of high level estimates to explicitly state your assumptions (e.g., 2 FTEs dedicated to project, 3 integration points, 20-30 hours of SME participation, prerequisite functionality X completed).
I also like this quote on the subject:
“It is better to be roughly right than precisely wrong.” –John Maynard Keynes