Search

Why are Estimates for Large Software Projects Wrong So Often?

Joe Conaty, CEO


Anyone involved with enterprise software delivery has seen projects that run far past the original deadline and cost much more than the initial estimate. The impact on the teams involved is extensive - press releases need rescheduling, development teams get burned out, product teams are frustrated, and everyone is left feeling failure.


So why does this happen so often? Two psychologists, Daniel Kahneman and Amos Tversky, spent years researching the root causes of poor decision-making and failed intuition in uncertain circumstances. Kahneman eventually won the Nobel Prize for their work on this topic. Michael Lewis wrote about their research in his 2016

book, The Undoing Project, where he articulated the root causes for projects running over time and budget:



1. Strategic Misrepresentation: the planned, systematic distortion or misstatement of fact (lying) in response to incentives in the budget process. Strategic Misrepresentation is disturbingly common in the consulting world, where competition is fierce, and companies are biased toward awarding contracts based solely on costs. As a result, many consulting companies consistently underbid a project even though they (should) know it is unrealistic and is likely to result in the project going over time and/or budget. The implications are demoralizing for a project team, resulting in an ugly final codebase and creating mistrust with the client.

Over time we have witnessed several cases of Strategic Misrepresentation. In these situations, our competition had done this work before, yet still underbid the projects and “won” the work. For example, in the fall of 2012, Leapfrog asked us to estimate how long it would take to re-platform their ecommerce application. We created an honest and accurate estimate using our two primary methodologies and avoiding engaging in Strategic Misrepresentation. Unfortunately, our competitor came in with a much lower bid, and Leapfrog chose the competitor.


The inevitable happened - the project ran drastically over time and budget, and Leapfrog called us to finish the work and launch the new application. We continued to work with them for years after that, but the codebase never recovered from the mess created when the development team was forced into a death march by an initial case of Strategic Misrepresentation. We refuse to do this at Commerce Architects as it violates one of our brand promises: No Surprises.

2. Optimism Bias: a cognitive predisposition to judge future events in a more positive light than is warranted by experience. Optimism Bias is less nefarious than Strategic Misrepresentation because the company doing the estimation genuinely believes it can do the work within the proposed time and budget.


One of the few explanations for this is that the people doing the estimates haven’t ever actually done a project of similar scope. However, looking at previous projects of similar size and complexity would inform them that the proposal is unrealistic.

Kahneman and Tversky defined a different approach to project estimation called Reference Class Forecasting, whereby looking at the time and costs of previous projects of similar size, you can get a reasonably accurate estimate for your project.


When Commerce Architects estimates a project, we use two primary methodologies:

1. Bottom-up Estimation: we start with prioritized high-level requirements, then break down all known risks, assumptions, dependencies, and tasks required to deliver the project successfully. The tasks are then given worst-case level-of-effort estimates, which strategically build time into the project to account for mitigating unknown risks and addressing unforeseen tasks. This approach takes a little more time but produces the best level of accuracy.


Additionally, we prioritize the most complex functionality first, tackling that early as it is more likely to have changes to requirements or defects in the initial implementation. For example, integrations and data migration are frequently the “long poles in the tent,” so we plan extra time for those and start work on them early in the project.

2. Reference Class Forecasting: we then look at the total time and cost for large enterprise applications we have built over the past 20 years. By comparing the new project scope to these previous projects of similar size and complexity, we can validate our Bottom-up Estimation and land on a realistic estimate. If there is a wide discrepancy between the Bottom-up Estimate and the Reference Class Forecast, we dig in, find out what we are missing, and adjust the final estimate before submitting it to the client. This method is useful when you have limited information on the project you are estimating.

While these methodologies can be applied individually to projects, combining them (when possible) provides a realistic project estimate that the client can trust. Combining methodologies also creates a baseline roadmap our program manager can use to track the project and create transparency on the status with stakeholders.

Commerce Architects has a long track record of delivering enterprise-level software projects on time and on budget. Not only because we adhere to our Brand Promise of No Surprises by not engaging in Strategic Misrepresentation, but we also assign a program manager who manages our baseline project estimate, mitigates risks, communicates regularly with clients, and ensures the team remains unblocked.

We welcome all our prospective clients to speak with any of our previous clients to understand how we deliver on projects.