Conquering the sunk cost fallacy in FP&A
The sunk cost fallacy is one of the biggest but least obvious challenges that we see FP&A and Strategic Finance teams face.
Sunk cost fallacy: the phenomenon whereby a person is reluctant to abandon a strategy or course of action because they have invested heavily in it, even when it is clear that abandonment would be more beneficial (Oxford Languages).
Many have probably seen the following image on the evolution of SpaceX’s Raptor engine. How many of us have built a financial model that feels like Raptor 1? I would wager that most have - and like Raptor 1, that model on its own is an incredible achievement that probably did unprecedented things.
But how often do we get to Raptor 3, which is clearly far superior. These outcomes are much rarer. What is stopping teams from continuing to progress? What we see most often is that the barrier is not only technology, or time, or even costs, it’s our human nature - the sunk cost fallacy.
One of the most important experiences of my career involved overcoming the sunk cost fallacy:
I had just transitioned from years of consulting into an internal role, and my first objective was to solve systemic problems with sales volume forecasting accuracy, which was creating massive problems like overstaffing and material shortages, inhibiting our ability to scale.
Everything went well with the project - we partnered closely with the Sales teams and rolled out a new process and model in only a few months. Everyone was happy and over the first few months, the forecasts were more accurate than ever.
Despite these initial wins, however, we identified several areas of opportunity in those first few cycles. Plenty of minor quality of life improvements, but also one critical one: the Operations team was not fully onboard, because the process was more biased to our sales territories instead of operations branches.
We went back-and-forth for several weeks trying to identify workarounds. For me personally, it was difficult to accept that even though the project met all the business requirements and achieved the desired outcome, it was still being critiqued.
Eventually it was clear that there were no easy solves that wouldn’t be temporary band-aids. We also knew that not only addressing sales but operations as well was critical, since operations was where revenue and cash flow were actually realized.
Ultimately, we decided to re-build a v2 model and axe the first one. This was a painful decision on multiple levels - we had to push out other priorities, I and our team had to swallow pride, and we had to risk the incremental improvements we had already achieved.
In going through the rebuild, there were several positive revelations:
- It went much faster than expected because we knew exactly what we needed and could retrace many steps - maybe 15% of the original timeline.
- It addressed not only the obvious gaps but also revealed new opportunities from folks who had just taken it for granted that they were stuck with v1 forever.
- The Operations team’s willingness to collaborate and make compromises quickly shifted when it was clear that their voices would be heard.
Once we got through to the other side, not only was our sales accuracy even better, but our operations accuracy improved as well, and our organization for the first time was aligned on the same volume forecasts from top-of-funnel to delivery.
This alignment further enabled our external investor metrics to be accurate for the first time and most importantly, helped unblock the organization to scale to become the clear leader in its sector in the following years.
The biggest key to achieving this outcome was not process or technology, it was everyone’s collective resolve to not settle for less and put the status quo at risk to achieve something bigger.
When I think about my personal involvement as a finance and technology leader, it’s a bit unsettling to think about how my own natural biases could have tipped the scales in the opposite direction. It would have been all too easy to say ‘this is good enough’, ‘we don’t have time for this’, or ‘it’s too late now’.
Following are some of the principles we hold to internally and share with our clients to help them get to Raptor 3 instead of staying at Raptor 1:
- Avoid personal attachment: Even if you played a big role in a project, if you internalize something as ‘my model’ or ‘my process’ or ‘my approach’ it will be that much more difficult to make significant changes to it or even discard it if needed. Be especially careful when others assign you credit (even though it’s usually with good intentions).
- Prepare to fail and embrace failure: Too often teams think that they get everything right on the first go-around. This is rarely the case no matter how well you know the business and execute. The ingenious engineers who built Raptor 1 were probably the same ones who built Raptor 3, just with more context. Accepting this fact and immediately learning and building from failures produces optimal outcomes.
- Rip band-aids off: complete rebuilds sound painful but they’re often much easier the second time around because you know exactly what you need, know what to avoid, and can retrace most of the steps. Trying to retrofit things only leads to unnecessary complexity and an even more painful rebuild down the road. Anyone who has inherited a 150MB Excel file that barely opens up will understand this all too well. If you see too many formulas with ‘z_x_DELETE’, you may have some band-aids to rip!
- Don’t conflate human issues with technology issues: software providers will eagerly jump to present technology as the cure-all for all your problems, then turn around and blame you for' ‘not fixing the process first’ when a lift-and-shift inevitably fails. Be wary of falling into this marketing trap.
When you are thinking about how to scale your capabilities, in addition to technology features, strongly consider if you are set up to fail fast, learn, and rebuild when needed as your business changes. This involves not only technology but your resources, service partners, and culture.
