Estimating Is Hard But The Business Needs to Know

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.