Bridge renovations, bullet trains, major sporting events, oil refineries, canals, commercial construction, healthcare applications, software upgrades—they’ve all made recent headlines with record-breaking cost overruns. Some of these reported cost overruns are not just 50-60% over—they’re orders of magnitude higher than budget.
The Standish Group reports only 7% of medium sized projects and only 3% of large projects using traditional Waterfall techniques complete successfully (i.e. on budget, on time and within scope). That leaves a pandemic level 97% of large, complex, expensive projects failing to deliver on expectation.
Knowledge of success or failure is critical, and the earlier the better. The costs and consequences of not knowing a project is failing can sink an entire organization. The cost of knowing is relatively inexpensive.
What causes cost overruns, and what is the cure? Unfortunately, you can’t reverse what’s already been spent. However, preventative cures from further cost overruns are possible.
Low estimates
Many estimates are precisely based on best-case scenarios. In other cases, low estimates are strategically used to get approval to begin a project. In either case, the perceived precision sets up the environment for eventual failure.
The cure:
- Estimate for accuracy, not precision: Use a relative estimation technique to provide better accuracy in your estimates. Estimating absolute hours or days for everything on the product backlog throughout the entire project gives a false sense of precision. We really don’t know with precision what we will be doing eight months in the future, but we can use a team’s previous iteration’s performance to accurately extrapolate into the future because the same team will do the same thing (i.e. fully build product), in the same timebox. Whether a team estimates optimistically or pessimistically, the result is a more accurate estimation of delivery, self-corrected for the team’s individual idiosyncrasies.
- Provide ranges based on reality: Use PERT techniques the way they were intended. Widen delivery date ranges based on iterative empirical data of optimistic, pessimistic and average (most likely) performance. Teams developing functionality in iterations establish empirical output data points at the end of every iteration. What was built was fully built and is potentially shippable. This can be used to provide more realistic delivery date scenarios to stakeholders.
- Fund incrementally: Avoid upfront funding and establish incremental funding expectations. Rather than agreeing to the entire budget upfront (i.e. setting the expectation the entire amount can be spent before determining success or failure), agree to allocate the requested amount, but only fund the first release. If you can’t deliver on a little, you can’t deliver on a lot.
Weak change control
Traditionally, many project teams try to lock down all requirements up front and in detail and then treat changes as failure rather than opportunities to apply what is learned in reality. In this quest for precision and sticking to the original plan, they either make change control a difficult and lengthy process or stick to the original scope and find out too late what they built isn’t what the customer needs. Alternatively, they continue with the original scope, plus add in the new scope without adjusting the schedule or budget (i.e. scope bloat). In other words, they fail to plan for variability due to complexity.
The cure:
- Progressively elaborate: Spend time elaborating requirements only as they rise up in priority (based on business value and risk). Don’t waste time breaking down to detail until it’s clear the business value is required to accomplish your next release goal.
- Prioritize & fund by value: Agile teams don’t run out of time or money, they run out of value. Simplify priority and ordering of your product backlog by business value and risk. Develop to completion one product backlog item at a time. Following this pattern ensures that at any point of the project you have your highest priority (value) functionality ready to ship, regardless of the amount of remaining funds. A project’s end date should not be based on when the project budget is depleted, but rather when the actual cost (AC) of continuing the current project, combined with the opportunity cost (OC) of not working on a different project, outweighs the value (V) received by continuing to work on the current project. AC + OC > V is the point where the current project should end and your limited resources should be focused on a higher value initiative.
- Swap scope: Stop worrying about scope creep or bloat, and manage changes by scope swap. Iterative development of a product backlog harnesses real-world feedback for competitive advantage because functionality is developed to completion within short iterations and presented to the customer for immediate adaptation. Pivot decisions can be made often as items worked on are the highest priority items.
Poorly validated assumptions
Most assumptions should be considered bad until they can be validated. We make the most assumptions at the beginning of the project when we know the least. Without validating these assumptions early, they perpetuate and influence our decisions all along the way. If we delay our opportunity to pivot, the distance we have to travel to get back on course increases.
Until assumptions get validated, making commitments on decisions too early in the process locks a project team down in the future decisions they can make. Likewise, over-engineering early on creates overhead the team has to carry through the rest of the project and limits their options. The more flexibility a team has throughout a project, the less likely they will experience cost delays due to re-work or cost dependencies on sub-optimal alternatives.
The cure:
- Validate riskiest assumptions early through feedback loops: Deliver fully built product early and often to your customers and gather immediate feedback. Address the highest risk assumptions as early as possible in the project (i.e. your first few iterations) through this feedback loop with your customer. If your assumption is wrong, finding out early allows you to either pivot or stop before wasting any more money.
- Act immediately on validated learning: If a pivot makes sense to enhance your ability to provide business value to the customer, make the pivot immediately. If what you learned suggests it may not be possible to deliver the business value you originally expected, cut your losses. Early failure is a form of success.
- Defer decisions: Don’t lock in decisions at the beginning just because you know those decisions need to be made at some point. Allow the team as much time as reasonably possible to learn before making decisions. Allow architecture to emerge, implementing only that which is needed to complete the requirements currently in progress.
The real cure to all of this is summed up in a change in mindset: Ability to recognize when early failure is actually a form of success.
After spending a lot of money on a failing project, it’s natural to think of it as an investment you have to keep trying to turn into something rather than a truly sunk cost. Projects shouldn’t run out of money. They simply run out of value. Knowing when to say when and actually doing it is the skill needed to cure the cost overrun pandemic.
