Why Estimating Software Development Costs is Hard and Dangerous

After 12 years designing and building custom web and mobile software applications I’ve found that providing precise estimates can sometimes be like providing the customer with rope to come back and hang me with later. Accurately estimating software tasks is difficult and estimating complex applications is nearly impossible.

Imagine a really capable build shop approached by a client to create a custom car with the following features:

• Autonomous driving
• Flying (yea, in the air like a plane)
• Submarine support (underwater travel)
  

Each one of these features in isolation has been done before and though not completely trivial is somewhat straightforward for an experienced engineer. Combine all three together, now you have something unique and ambitious. Estimating the time and costs to put all three together in a working prototype would be difficult because the creative process has undetermined elements. The iterative process of trial and error will need to occur in order to build a stable, usable, and safe prototype that satisfies the client’s vision.

Software development is similar. We are commonly asked to build custom applications that have many familiar components (like payment portals, social media feeds or shopping carts) combined with innovative user experiences and proprietary functionality.       While we can leverage our experience (to help estimate the known features of a project, estimating the unique elements is difficult.  Further, sometimes even an assemblage of known elements can be unexpectedly troublesome due to the interactions.

“If you think education is expensive, try estimating the cost of ignorance.” — Howard Gardner

The hardest part of any estimate are the unknowns.  There are two primary uncertainties in any project: known unknowns and unknown unknowns.  The first are risks that are known to exist.  The second are risks so wild and unexpected they are completely unforeseen.

By way of example, you may think you have a good idea of how long it takes to drive home from downtown Chicago. However, the known unknowns like traffic levels and stop lights can make your arrival time variable. The unknown unknowns like a completely unforeseen hazard materials spill or a medical emergency can make the travel time highly variable.

There is also another important uncertainty.  Sometimes identifying what works best is an iterative process. The project team doesn’t fully know what they want until they can see an initial prototype or end users need an alpha grade prototype for real world usability testing. By definition an iterative prototype takes an unknown amount of time to refine.

In response to the challenge of accurately estimating project timelines, a number frameworks are now employed that remove time as a unit of measurement.  This solution is at best incomplete because stakeholders outside the project team need to plan and budget.  Resource planning, budgets and projects plan require time estimates to be meaningful.

We have found that a range is the best way to offer estimates. In this way the project team can leverage their experience to come up with a guesstimate with a confidence interval.  The project stakeholder’s needs are met for a reasonable expectation of the time and costs that will be associated with their vision. For example, a developer comes up with their SWAG estimate (scientific wild ass guess) using his trusty custom proprietary spreadsheet formula and comes up with an hours estimate. Then, depending on the perceived level of variability and unknowns a buffer is added to create a range. It’s typical to see ranges in the area of 10 - 30%. This approach recognizes the inherent timeline variability and offers others a general idea of the required time and investment.

Check out this other post where I further discuss ways to mitigate the unknowns in software development and more accurately estimate time and costs.