Anna Totterdell
Projects Director
Every business leader I speak to agrees with the same principle: you need solid foundations before you can build anything meaningful on top of them.
Then the budget meeting happens.
Readiness work - mapping processes, structuring data, assessing data and systems integration gaps - does not survive the budget meeting. Not because anyone argues against it. Because it cannot compete with the things that do get funded: the new platform, the AI initiative, the dashboard project, the vendor proposal with the impressive demo.
Readiness work has a politics problem. And until you understand that problem, the work will keep getting deferred - no matter how many times it proves to be the reason the other projects fail.
Why readiness work gets killed
It gets killed for four reasons, and they are all predictable.
The first is visibility. Readiness work does not produce anything you can show in a board presentation. There is no demo. There is no interface. There is no before-and-after screenshot. The output is a structured understanding of how the business actually works, a set of cleaned and normalised data, and a collection of documented integration points. These are enormously valuable - but they are invisible to anyone who is not doing the work.
The second is attribution. When readiness work is done properly, the projects that follow it succeed. But the success gets attributed to the project, not the preparation. The AI initiative works - so the AI vendor gets the credit. The automation delivers results - so the automation tool gets the praise. Nobody writes a case study about the three weeks of data normalisation that made it all possible.
The third is competition. In every budget cycle, readiness work competes against proposals that come with vendor presentations, product demos, and projected ROI charts. These proposals are designed to be compelling. Readiness work, by contrast, is a pitch that says: "spend this money and the visible output will be that other things stop failing." That is a harder sell, even when it is the more important investment.
The fourth is timing. Readiness work is preventative. It solves problems that have not visibly exploded yet. And businesses, like people, are far more motivated by acute pain than by chronic risk. The spreadsheet that crashed last Tuesday gets attention. The data inconsistency that will quietly undermine every AI project for the next three years does not.
The pattern that repeats
Here is what happens instead - and I have seen this cycle play out dozens of times.
A business approves a technology project. A business automation platform, an AI tool, a new reporting system. The project kicks off with energy and executive attention. Two months in, the team discovers that the data does not reconcile across systems - and the IT and process strategy that should have surfaced that never ran. Three months in, they find that the processes they are trying to automate have undocumented exceptions that only certain team members know about. Four months in, the timeline has doubled and the budget is under pressure.
The project either limps to a compromised delivery, gets quietly shelved, or is declared a success while the team goes back to doing things manually.
Then the next project starts. Same pattern. Same discovery. Same surprise that the foundations are not there.
Each time, the cost of the failed or compromised project dwarfs what the readiness work would have cost. But because the readiness work was never done, nobody can point to that comparison. The failure is attributed to the technology, the vendor, or the team - never to the missing preparation.
How to make the case internally
If you are the person in your organisation who understands this problem - and there is usually at least one - here is how to fight for it.
Stop calling it readiness work. Nobody funds "readiness." Call it risk reduction. Call it project de-risking. Call it pre-implementation assurance. Frame it as the thing that stops the next technology investment from failing - because that is exactly what it is.
Attach it to a funded initiative. Readiness work on its own does not survive a budget cycle. Readiness work as phase one of an approved project does. If the business has already approved a business automation or AI initiative, position the readiness work as the mandatory first phase - the work that ensures the investment delivers. This is not a trick. It is the truth. But it needs to be positioned as part of the initiative, not a separate line item.
Quantify the cost of skipping it. Find the last technology project that ran over budget or underdelivered. Calculate how much of that overrun was caused by data issues, process ambiguity, or integration gaps discovered mid-project. That number is the cost of not doing readiness work. Present it.
Make the output tangible. Readiness work produces deliverables - they are just not the kind that look good on a slide. So make them look good on a slide. A process map that shows the real operation. A data quality assessment with specific error rates. An integration gap analysis with estimated fix costs. These are executive-grade outputs when presented properly.
Show the speed multiplier. The businesses that do readiness work first complete their subsequent projects in half the time at lower cost. That is not an exaggeration - it is a consistent pattern. When the data is already structured and the processes are already mapped, the automation or AI project becomes a focused, technical delivery instead of a discovery exercise that keeps uncovering surprises.
What happens when readiness is protected
The businesses that get this right do not treat readiness as a one-off exercise. They build it into how they operate.
They maintain living process documentation that reflects reality, not policy. They have data governance standards that are enforced, not aspirational. They know which systems are connected, which integrations are reliable, and which ones are held together with manual effort.
When a new technology initiative is proposed, they can assess whether the operation is ready for it - and if not, what specific work needs to happen first. That assessment takes days, not months, because the foundational knowledge already exists.
The result is that their technology projects land faster, cost less, and deliver what they promised. Not because they choose better technology. Because the ground is prepared.
The uncomfortable truth
Most businesses will continue to skip readiness work. They will continue to fund the exciting project over the foundational one. They will continue to discover, mid-implementation, that the data is a mess, the processes are undocumented, and the systems do not talk to each other.
And they will continue to attribute the resulting failure to the wrong cause.
The businesses that break this pattern will not be the ones with the biggest technology budgets. They will be the ones that had someone - a COO, a finance director, an operations lead - who fought for the boring work when it was not popular.
That is the competitive advantage nobody talks about. Not better tools. Not smarter AI. Better foundations, protected by someone who understood that the work nobody wants to fund is the work that makes everything else possible.
