The Last Estimation Tool You Will Ever Need

Software project estimation may be an exercise in guesswork, but it is imperative for almost any company in the business of developing software on a fee for hire basis or teams looking to plan budgets to develop a software project estimate that from the ground up has reasonable assumptions, scientific wild-ass guesses, and an accounting for things that could go wrong. Let me save you some time and share with you how I've estimated for projects in the past.

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.

There's more to an estimate than the work.

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.

Your Agile Team Should Stop Using Story Points.  Here's Why.

Your Agile Team Should Stop Using Story Points. Here's Why.

In a place far away and long ago, teams used to be asked "when will this be done?" which at some point go confused with "how much time will this take to finish?" Business stakeholders and software engineers - forever separated by semantics and the inability to communicate were united by consultants who came up with an abstraction: story points. Ever since, we have been in hell.

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.

cloudGet the Sheet

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!

Ryan Norris Ryan Norris

Ryan is the former Chief Product Officer at Medullan, CTO at Be the Partner, and CTO and General Manager at Vitals. He currently works as a fractional CTO offering strategy as a service to growth-stage companies in health care and education.

Recommended Posts