If you know me then you know that I’d rate myself as “pretty tidy with a spreadsheet”, and for many years spreadsheets have been the go-to tool for building business cases. They’re flexible, familiar, and just sitting there on your desktop, ready to go, so have long been the first thing I reach for, but after seeing dozens of projects go through approval cycles (and more than a few go off the rails to various degrees) I’ve learned that spreadsheets come with a hidden cost.
They’re great for quick calculations or one-off models, but when you’re trying to build a robust, credible business case (one that might influence major budget decisions or define the course of a project) spreadsheets introduce far more risk than most people realize, as you’re about to discover…
⚠️ Badly built spreadsheets
I’m going to start with a particular bugbear of mine, as it’s something I’m yet to find an org do well, but the ease of making and editing a spreadsheet is also the root of how they are massively misused. As an Economist you learn that there’s a right way to build models, and then when you start working you realise there’s then also how 99.99% of people actually build models….
The right way involves such treats as never hardcoding any information unless there is literally no alternative, having everything feasible in formulas and lookups, explaining those formulas with Notes, having an Assumptions tab where all assumptions are laid out, a Variables tab for the variables…. you get the picture. Absolutely that is one of the most tedious sentences I’ve ever written, but it’s also the only way that you can have any faith in the outputs (or indeed any hope of someone else auditing it or verifying those outputs without putting aside a full month of their life to reverse-engineer endless tabs of mess).
I can count on the fingers of one hand how many business cases (other than those made by me, and even I’ve been guilty of being lazy and slipping into bad habits) that I’ve reviewed, contributed to, presented or approved that I’ve actually liked the format of, and found easy to follow. Usually I find myself spending hours going down blind alleys trying to find where a cost or an assumption has come from, just to meet a hardcoded cell and realise that it could equally have just been plucked out of thin air.
When such crucial elements of a Business Case as assumptions and variables aren’t easily visible, they don’t get challenged. And if they don’t get challenged, you just end up greenlighting projects based on wishful thinking, and crossing your fingers in hope.
Good tools make assumptions explicit. Great ones let you adjust them easily and see how outcomes change, but that’s something spreadsheets just weren’t built to do.
🆚❌ Inconsistent models ruin comparisons
I’ve seen this first-hand more times than I can count: every team builds their own version of a business case, each in a slightly different spreadsheet. One pulls in estimates from finance, another lifts numbers from an old deck, someone else duplicates an old sheet full of outdated values from a previous project and tweaks a few inputs. Before long, no two models are remotely alike.
That might seem harmless - just a formatting difference - but there’s a bit more to it than that. One team might include ongoing maintenance costs, while another doesn’t. One might count headcount savings as benefits, another might not. The same input might appear in different places - or be named differently altogether. When each team defines “value” or “cost” differently, there’s no real way to compare proposals. I’ve sat in approval meetings where we’ve wasted far too much time trying to reconcile two business cases built on entirely different assumptions, and it just needlessly slows things down and clouds the conversation. Even worse, sometimes the best ideas get overlooked just because the spreadsheet didn’t tell the story clearly enough.
Without a common approach, comparisons are just guesswork. With a consistent model (where assumptions, inputs, and outputs are standardized) you get clarity as you can line up scenarios side-by-side and make informed decisions based on real differences, not formatting quirks or who happens to be best at Excel.
🧩 Collaboration is clunky
If you’ve ever opened up a spreadsheet and wondered, “Wait, is this the latest version?” then you know the pain of version control gone wrong. Building a business case will usually require input from across the business, be it subject-matter experts, finance analysts, project owners, or executive sponsors, then on to potentially multiple rounds of review, approval, and revision, but spreadsheets usually lack a decent way of managing this. There’s generally limited version control, a bit of change history and no good way to protect key inputs or formulas as it either ends up being so restrictive that no one can actually use it, or so lax that it's just a few token locked cells.
Sure, nowadays you can share them so it’s a touch better than it was 10 years ago, but what you gain in access, you lose in control. The reality is that people work in parallel versions, someone updates the model offline, another person adds comments without tagging anyone so those comments never get seen, and before long there are half a dozen versions of the same file floating around: one emailed last week, one uploaded to a shared drive, another renamed with a “FINAL_FINAL_v3” tag. It becomes hard to tell which version is current, or which numbers to trust. Google Sheets and Excel 365 offer basic real-time editing, but realistically that’s not enough. There’s no way to set permissions per role, properly track who made changes to the forecast, or manage approvals with an audit trail. You end up with a fragile system held together by good intentions, string, sticky tape and hope, where a simple overwrite can derail weeks of work.
This lack of control makes it harder to establish credibility. When you present numbers in a spreadsheet, you're implicitly asking stakeholders to trust that they haven’t been changed, miscalculated, or misunderstood. And if someone on the review committee has to ask, “Where did this number come from?”, you’ve already lost momentum.
❌ Mistakes are easy to make, and yet hard to find
Speaking of miscalculated or misunderstood….
Spreadsheets don’t warn you when a formula breaks, someone hasn’t understood the difference between absolute and relative cell referencing or when a pasted number overwrites something important. They don’t tell you that a critical assumption is out of date, or that a reference to another sheet has silently failed. And yet, all of these things happen, often without anyone noticing.
There’s an oft-quoted study by Ray Panko that found that nearly 9 in 10 spreadsheets contain errors. Honestly, I would have guessed higher. Some of these are obviously harmless, but in a business case a broken formula or incorrect cell reference can seriously distort ROI, payback period, or NPV.
Even well-designed spreadsheets are vulnerable, as one person making a change without fully understanding the impact can ripple through the model without obvious signs, and if that model is being used to justify a major purchase or strategic shift, the consequences can be significant.
💆🏻♀ Massaging the numbers
This is one that people don’t really like to talk about, but something I’ve seen in every org I’ve worked in. If you really know what you’re doing with a spreadsheet, then you know how to make a spreadsheet say whatever you want it to:
ROI a bit low? Let’s make the ramping period on those costs a bit more “friendly”.
Payback period a bit long? Let’s bring forward a couple of benefits, push a couple of costs.
All technically in the business case so no one can accuse you of manipulating the numbers, just conveniently hidden away in a part of the spreadsheet no one will ever get to, so the perfect crime. It happens across orgs large and small, projects worth a few hundred dollars, projects worth a few hundred million dollars and it’s a real problem, particularly as once the project gets signed off, chances are that business case will just be sat in a shared folder, never to be seen again.
⚖️ Scenario planning becomes a manual slog
A well-built business case doesn’t just consider a single plan, it involves comparing options, but modeling different scenarios in a spreadsheet is generally extremely painful and a recipe for disaster.
Each time the Economist in me gets the urge to test a different pricing model, timeline, or provider, I have to duplicate tabs, rewrite formulas, and pray nothing breaks. After a few rounds, the file is generally so fragile that I barely want to touch it, let alone let anyone else near it. And if someone did? We’re likely back to version control chaos.
In my experience for anything to be effective and actually used by people, it needs to be fast, flexible, and safe, and Scenario Modeling is a great example of this. When it’s not, people will often try to see if they can get away with just skipping it altogether, and that leads to less informed decisions.
💡 So what’s the alternative?
Rather than forcing spreadsheets to do things they weren’t designed for, people are increasingly seeing the value in turning to purpose-built platforms for a whole range of tasks, but business cases are still largely stuck in spreadsheets. 10 years ago you would have used a spreadsheet to track leads and deals but now there's Salesforce, you would have used a spreadsheet for your marketing campaign but now there's Hubspot, you would have used a spreadsheet to track OKRs and goals but now there's Lattice, and business case creation, scenario modeling and ROI tracking are finally catching up.
KangaROI is a platform structured to solve the specific pain points that spreadsheets create:
✅ Formulas and logic are built-in, reducing risk of error
✅ Scenarios can be created, cloned, and compared instantly
✅ Role-based permissions ensure the right people edit the right things
✅ Real ROI can be tracked post-signoff with live project inputs
The result is a business case that’s more than a one-off document, it’s a source of truth you can trust across the entire project lifecycle.
🔪🔫 Final thoughts
I am in no way anti-spreadsheet; I’ve spent a career playing around with them, and for so many tasks they are a great tool. But when it comes to business cases, it’s just not the right tool for the job, as the stakes are too high to rely on copy-pasted models, unchecked assumptions, or buried errors. If your business case is how you win budget, influence direction, or prove value, then you need something more robust than a spreadsheet, and to stop bringing a knife to a gun fight.
