During the COVID era, I started thinking of all the home improvement projects I would like to tackle and sadly have not started any, lol. However, I recently became motivated and decided to apply drywall mud (skim coat) to two walls in my garage that have been dinged and dented over the years. An essential part of this process is to first estimate my materials, time and effort to minimize the impact of disruption to my family’s day to day lives. Estimating this job is a simple process – amount of surface area to be covered yields the amount of drywall mud I will need. The time and effort to complete the project is the fuzziest part of the estimate, but since I have mudded before, I have a rough idea of how long it will take to mud, sand, mud again, sand again, then primer and paint. The risk of this estimate is low, since my work won’t be keeping a medical device functioning, an airplane afloat or a billing system used by thousands operational.
Estimating software delivery is not that simple and its accuracy can be easily compromised – but what is “accurate?" Software estimation’s non-linear nature introduces much complexity, since time, effort, resources, and quality are all interdependent - when a change to one of those measures happens it affects the others.
Some organizations implicitly expect an estimate to be accurate 6 decimals out, but that level of accuracy defies the very nature of the word “estimate.” In my experience, a 50% probability in the estimate is a victory, but then when you add in contingency, based on historical data, the estimate can be elevated to 80%-90% accuracy. In the graph below is an example of a cumulative effort estimate at 50% probability (gold shaded) compared to an 80% probability (gray shaded). In this scenario, I’d condition my development team to the gold and my client to the gray – if my dev team finishes up early, then we look all the better!
A PMI survey revealed, “organizations that are ineffective with project management waste 21 times more money than those with the highest performing project management capabilities. But the good news is that by leveraging some proven practices, there is huge potential for organizations to course correct and enhance financial performance.” We at QSM have seen firsthand that many software projects have failed because of inaccurate and unrealistic expectations of their estimates, but to achieve a win, the estimate does not need be 100% accurate.
The PMI survey also stated, "the survey showed that on average, around half (52 percent) of projects experience scope creep and roughly half (48 percent) are not delivered on time, leading to huge financial losses. Defining success measures upfront helps ensure projects stay on track, and meet budgets and goals." Of course, scope creep, added functionality, staff turnover can all have negative effects on the estimate after the project has been started. That is when project oversight and tracking are deployed to act as the monitor of achieving our goals and adjusting measures as needed midflight to increase success and accuracy.
The industry as whole seems to have developed an acceptance for missing goals through no fault of any single person, role or group, rather a combination of variables. Given the number of projects that fail, it would seem even getting to a 50% estimate accuracy would be a great leap and first step, but the exciting part is there are method and tool combinations that can get us much higher per centages of success.