SOFTWARE ESTIMATES – PLANNING FALLACY

software estimation - planning fallacy

OVERVIEW

Specialist no code, low code and traditional code developers have two things in common.  First, they all claim some level of expert status – at least extensive expertise in, and knowledge of, highly complex software development tools and platforms.   Second, they are notoriously optimistic planners.  The flipside of this second trait is that they are equally bad judges of the most likely duration of software projects. 

Unsurprisingly, despite their expert status, like most people, they cannot accurately predict the future.  They are not prophets.  However, they often fail to get close to reliable estimates.  In this blog we review this problem and suggest approaches to achieve more realistic time estimates.

 

OPTIMISTIC PROPHETS

We are optimists and software developers are no exception.  Expert software developers, just like expert planners, really believe in their plans and estimates but they are not prophets. Despite their best intentions, many are affected by something called optimistic bias – they may unintentionally overestimate the benefits and underplay the risks. They are also aware that most of their clients see them as experts and are keen not to disappoint them by displaying uncertainty. 

Clients also hold some responsibility for the problem – many set their own expectations for the duration of projects.  Unsurprisingly, development experts feel pressured to match expectations.  More importantly, software development is complex and this is exacerbated by the fast pace of change in this industry.  However, the biggest problem, in our experience, is the lack of an outside view. 

 

THE OUTSIDE VIEW

First, recognise that experts can be some of the worst judges and decision makers.  Like most of us, despite their expertise and experience, they cannot predict the future.  Their ability to make sound judgements is affected by bias and noise.  See my previous blog for a primer on both.  Next, understand that the real problem is the tendency to neglect the “outside view”.  Simply put, once focused on the estimation task, software development experts do not typically review how long previous projects took to complete or how much they cost.  The most common approach is to consider new projects as unique and special.  Whilst they are both, neglecting the outside view is often the root cause of most unreliable estimates.

 

WHAT TO DO

How do you predict the adult height of a child with scarce data?  Best not to start with optimistic bias driven by assumptions around the role of nutrition, etc.   In the absence of other data, you would do well to first consider the height of the population as a whole.  That is the so-called “base rate” data or outside view.  If you want to know how long it might take a software development team to complete a software project, first look at the population of software projects.  Of course, each project is unique and similar projects are often impossible to come by but this outside view is important.  This should always be the starting point  – a baseline view that is detached from the optimism of experts, unaffected by bias, noise and other impediments to sound decision making.

The next step is to adjust the baseline with  information that you know about the specific software project that you need an estimation for.  How is this project unique and different from the baseline? Is it less complex?  Is it being built on a different platform?  Is the team more experienced?   The main thing is to never neglect the outside view – start with the outside view and make appropriate adjustments based on the characteristics of the new project.      

 

G2Guide

As project managers, we have access to a large pool of previous projects’ estimates (time and cost) from a variety of teams and specialists.  To support the planning process we often share this “outside view” with software development specialists and they may choose to use it to adjust their own estimates.

July 28-2021, Written by Segun Osu Leave a comment

Leave a Reply