Ask most people what “organisational readiness” means and you’ll get a fairly consistent answer: governance in place, funding secured, the right team structure, a delivery methodology everyone’s signed up to. On paper, readiness looks like a checklist. Tick enough boxes, and you’re ready to go.

I don’t think that’s quite right. And I think the gap between what we assume readiness is and what it actually is turns out to be exactly where AI has something real to offer — not as a shortcut, and not as a fix, but as a way of getting to genuine readiness faster.

My colleague Suzanne recently wrote on this blog about how loosely the word “transformation” gets used across government and industry, and how that ambiguity shapes the way change gets funded, governed and delivered. This piece picks up a related thread from the same roundtable discussion, hosted by the Institute for Government in partnership with Scott Logic — you don’t need to have read Suzanne’s piece for this one to make sense, but the two sit well together.

So, let’s be clear about what this isn’t. This isn’t an “AI will sort it out” piece. If anything, the argument here is closer to the opposite: AI is only useful for readiness once you understand what readiness actually requires. In this article, I want to unpack what organisational readiness really is, what “shifting it left” means in practice, where AI genuinely helps, where human judgement has to stay firmly in charge, and how we think about the ethics — particularly around data — that come with any of this.

Readiness isn’t what you think it is

The roundtable kept arriving at the same conclusion, from different directions: most transformation failures aren’t technology failures. Organisations that fail don’t usually fail because they picked the wrong platform or the wrong supplier. They fail because of something further upstream — unclear objectives, fragmented ownership, decisions that never quite get made.

Here’s the phrase from that discussion that’s stuck with me most: the real constraint isn’t what an organisation is capable of building. It’s what an organisation is capable of defining, deciding and sustaining.

That’s a different claim to the checklist version of readiness. It says readiness isn’t a structural property of an organisation — it’s not something you install by getting the right governance board in place. It’s a shared understanding problem. And shared understanding is much harder to achieve than it looks, because most teams don’t realise they lack it until it’s too late.

One example that came up during the roundtable was a programme simultaneously expected to reduce costs, improve user experience, and reduce appeals and contacts. Every one of those is a reasonable goal. Put together, without anyone explicitly reconciling them, they pull delivery in different directions — effectively working for two or three masters at once. Nobody in the room disagreed with each other, because these things were never discussed. They only discovered they had different objectives once delivery commenced.

That’s the pattern worth sitting with: people believe they agree until delivery starts. Different groups can leave the same meeting with different assumptions about the problem, the users, the desired outcome, what success looks like, and what trade-offs are acceptable — and delivery teams usually only discover the gap after significant money and time have already gone in.

This is why, in my view, readiness is actually the ability to reach genuine, shared understanding about the problem, the outcomes, and the decisions an organisation is prepared to make. And naturally, given that not every organisation formally considers this step in their transformation programmes, the question that this definition of readiness throws up is “how do we get to that shared understanding faster, and more reliably, before we’ve committed to a direction?”

Shifting left, properly understood

“Shift left” gets used a lot in software delivery, usually to mean moving testing or security earlier in the process. I want to use it in a related but distinct sense here: shifting the understanding left, not just the delivery.

That’s not the same as rushing. A pattern that came up repeatedly at the roundtable was that agile gets misunderstood in transformation as permission to skip the hard thinking. Iteration is mistranslated as “we’ll figure it out as we go.” In fact, shifting left means making sure that everyone is aligned on the vision and understanding before delivery – but doing it fast enough that it doesn’t become its own six-month delay.

And this is where the constraint stops being organisational and starts being informational. Reaching shared understanding quickly means synthesising a lot of material — research, evidence, prior documentation, conflicting stakeholder input — faster than any team can typically read it, while also surfacing the assumptions and disagreements that are usually invisible until delivery exposes them. That’s a genuinely hard information problem, and it’s where I have already seen exciting results using AI.

How AI helps you shift left

On a recent large public sector programme, working at pace against a huge volume of source material, we used AI tooling to triage and synthesise that material. Not only was it faster than a human team could manage by reading everything manually, it also surfaced things nobody on the team had thought to look for. Obviously, human checks ensured there were no hallucinations or mistakes – but even with that step, the process was faster and more comprehensive than without AI.

We’ve also worked with organisations carrying significant legacy and fragmentation, working with systems that have accumulated over years, built by different teams for different purposes, with the relationships between them barely documented anywhere. AI tooling has meaningfully sped up the process of understanding how those systems relate to each other, where the real gaps sit, and where the opportunities are — the unglamorous groundwork that normally eats months of a discovery phase.

Vital to this is ensuring that the AI tools you use aren’t just looking outside the organisation, but inside it. Tools that can draw on an organisation’s existing document libraries and correspondence mean you’re not starting from a blank page on every engagement. In fact, I am using AI in this way internally at Scott Logic to look for opportunities to standardise practices and methodologies across projects, ensuring that we don’t build things from the ground up when we don’t have to and that we don’t lose nuggets of wisdom between projects. Used well, AI can become a forcing function for more consistent practice, not just a productivity boost on any single piece of work.

And returning to the ability to achieve shared understanding and consensus, we have also been experimenting with AI-enabled prototyping in tools like Figma and Claude. By quickly building something visible and testable and putting it in front of internal and external stakeholders as well as service users, we can uncover areas where expectations and goals differ, and answer questions before it gets too expensive to do so. Engineering and service design both get fuelled by the same underlying capability: faster synthesis, faster prototyping, faster exposure of disagreement, and ultimately a faster understanding of user needs.

Human in the loop is the important bit

None of this works without a human firmly in the loop. AI’s role here is assimilation and triage at scale — reading more, faster, and flagging what a person should look at next. It is not decision-making, and it doesn’t replace the conversations that actually build shared understanding. Bringing alignment to a mountain of information still takes a person who understands the organisation, the politics, and the people in the room.

This is the guardrail against the reading I’m most keen to avoid: AI doesn’t make readiness someone else’s problem. It gives the people who own that problem better material to work with, faster.

Ethics is a data question, not a jobs question

Understandable caution about AI runs deep in the public sector, and I don’t think that caution is misplaced. But in our experience, it’s often aimed at the wrong target. We’re not advocating using AI to eliminate roles — we’re using it to assimilate information at scale, with a person still making every decision that matters.

The sharper ethical question, in this use case, is about data: how information gathered from interviews and stakeholder conversations is used, stored, and represented back. Be clear and specific about that, and most people are comfortable. The times we’ve seen genuine unease, it’s almost always been about ambiguity — not knowing where the boundaries are — rather than opposition to AI itself. Clarity resolves more of this than policy documents do.

It’s a behavioural shift as much as a technical one

Any of this only works if it actually changes what happens on the ground, which makes it a behavioural change problem as much as a technology one — nudge theory is a more useful lens here than most technology frameworks. You have to understand the culture and the ecosystem you’re operating in to know what’s genuinely possible, and how quickly people are likely to move.

Seeing the other side of the mountain

Ultimately, my experience – and that of the people in the roundtable discussions – is that the success or failure of a transformation is down to human elements rather than organisational or technical. Indeed, at their core, the organisational and technical aspects of transformation programmes should only exist to support the humans at the centre of the transformation, whether they are employees or service users.

Hopefully, I’ve demonstrated how organisational readiness can be thought of in terms of an organisation’s ability to align on a vision for transformation; from this, everything else flows. I hope my experiences of using AI to shift that alignment work left in the process have given you something useful to consider for your own organisations and projects.

I’d like to end on the idea that the transformation is often about showing people ‘the other side of the mountain’. During any transformation, the leaders and evangelists will have the vision clearly in their heads and can see the benefits on the other side of the effort. But not everyone shares that vision. That’s not a failure of imagination. It’s just harder to see from inside the day-to-day pressure of delivery. As a leader in transformation, you have a responsibility not just to align everyone on the vision at the start of the programme, but to bring everyone with you as that vision becomes reality.

Our own research with around 100 developers and testers backed this up: the productivity gains from AI tools are real, but realising them safely depends on training, prompt engineering, structured experimentation, and governance — not just switching a tool on.

It’s where Scott Logic adds value in our engagements. We aren’t brought in to ‘do your transformation’ any more than AI will fix a problem. What we do is equip organisations to manage their own transformation, including helping organisations identify what the other side of the mountain looks like for them specifically, and mapping a realistic, low-risk way to get there — starting small, testing, and learning as you go, rather than betting everything on a single leap.