The Last Estimation Tool You Will Ever Need

Estimation is hard

Cognitive tasks sometimes seem impossible to estimate. Software project estimation in the best case is an exercise in guessing based on experience. The problem is that unlike building a deck or a kitchen, many tasks in software development - particularly for firms working on a fee for hire basis, are novel. Sure, everyone has experience creating databases, but they might not have done so for a company in a particular industry or for a particular problem set. But even with the variables of experience, specialization, etc. - the variables that kill a project are not typically around the knowns. When we know what has to be done, and just don't quite know how to do it. The variability across task estimates is eventually weighed out by what expertise is available to skew the result to be more definitive - an output of the law of large numbers.

Let's say we have 10 tasks on a project. 3 of the tasks I may overestimate the time to complete, 3 of the tasks I may underestimate, and the other 4 I'm more or less spot on with. The result is that my "Do It" estimate - the amount of time I'm heads down working in the project, will likely be somewhat accurate (with manageable variance that particularly in larger projects, will end up being more of a rounding error).

The larger problem in estimation is not estimating the work to be done, but in estimating risks and downtime.

Estimation is not just about the work

The biggest thing I've always heard from people with project timelines or budgets that have been blown to smithereens is "we didn't expect some of these things to happen." While it's true that "everyone has a plan until they get punched in the mouth," plans that go south quickly are often victims of a lack of understanding and planning for risk. Some managers when asked for an estimate will turn to their engineers and get a number, and then turn to their management and double it. The fact is that in a lot of cases, most of the risk in a project can be pulled out through a simple discussion of everything that needs to be done, with each step being analyzed for dependencies.

Project risk is ultimately undiscovered or unbounded work, and it is the job of project management to ensure the team vets these risks early in the project to either remove them or mitigate them otherwise. Risk is hidden tasks.

In addition to risk, a good estimate needs to include:

• Accounting for time-off
• Overheads from management and non-deliverable producing activities
• Ramp-up for the team as they begin the project and are underproductive
• Ramp-up for new team members as turnover naturally occurs

Basically, the project timeline is a function of (Do It LOE + Risk + Overhead + Ramp-Up + Time Off)/Number of People on Project.

One tool to rule them all

Software people have a bad habit of jumping right into a solution like this and coding their way out of it - but for me, a spreadsheet is an easy, go to tool for building a project estimation. I've built this tool so many times over the years that I figured I would share it as a platform for your estimation work, and hopefully it can help make it so project budgets and bids can go faster and have more certainty.

I hope that this tool helps you! Let me know on LinkedIn or Twitter about projects that you've been able to use this for!