Almost every “digital transformation” pitch deck we’ve seen - including some of our own older ones, honestly - leads with technology. New stack, new app, new dashboard. Almost none of them lead with the number a CEO actually cares about: what does this get back, and by when. That gap is why so many transformation projects get approved with excitement and cancelled eighteen months later with a shrug.
So instead of another framework, here’s how we’d actually walk a CEO through evaluating a transformation project before signing off on it.
Start with the cost of doing nothing
The ROI conversation almost never starts in the right place. Before asking “what will this new system cost,” ask “what is the old system already costing us, quietly.” That’s support hours spent on manual reconciliation, sales cycles lost because a competitor’s site loads faster, developer hours burned patching a legacy platform instead of shipping features. We’ve had clients discover their “we can’t afford to rebuild” system was costing more in staff time each year than the rebuild itself.
The three numbers that actually matter
- Payback period. Not “ROI” as an abstract percentage - the actual month you expect to have recovered the spend. If nobody on the project can give you a rough month, the business case hasn’t been done yet, only the technical plan has.
- Cost of delay. What does each quarter of not shipping cost - in lost conversion, in support overhead, in developer time spent working around the old system instead of building on the new one? This is usually the number that makes “let’s wait for a better time” indefensible.
- Blast radius if it goes wrong. Every transformation has a failure mode. A good plan names it upfront - what happens to the business if this project runs six months late - rather than discovering it mid-project.
Where most transformation budgets actually go wrong
It’s rarely the technology itself. In our experience it’s almost always one of two things: scope that keeps growing because nobody defined “done,” or a big-bang launch where the old and new systems never run in parallel, so there’s no safety net if something breaks. Both are project management failures dressed up as technology risk.
The fix for both is the same: ship in phases you can actually measure. We push every client toward a first phase that’s small enough to be genuinely low-risk but real enough to prove the economics - a rebuilt checkout flow before a full platform migration, a single high-traffic page before a full website rebuild, one automated workflow before a company-wide process overhaul. If the first phase doesn’t move the numbers, that’s information worth having before you’ve spent the whole budget, not after.
What we tell clients to actually track
Before we start any engagement, we ask for a baseline: current conversion rate, current page load time, current support ticket volume, current cost-per-transaction - whatever’s relevant to that specific project. Then we track the same numbers after launch. It sounds obvious, but most transformation projects we inherit from other agencies never had a baseline in the first place, which means nobody can actually prove the project worked, even when it did.
The honest version
Digital transformation isn’t a single project with a finish line - it’s an ongoing discipline of picking the highest-leverage bottleneck, fixing it with a measurable outcome, and moving to the next one. The CEOs who get real ROI from this work are the ones who treat each phase as an investment they can evaluate, not a leap of faith they’re funding once and hoping pays off.
If you’re weighing a transformation project and want a second, less technology-obsessed opinion on where the actual payback is, get in touch - we’ll tell you honestly if the numbers support it before you commit budget.