The First 90 Days of AI Transformation: A Week-by-Week Plan That Holds Up

Most AI programmes are decided in the first three weeks and nobody notices until month nine.

By then the budget has been approved, a platform has been chosen, and a pilot is running against a problem nobody quantified. The technology works. The steering committee cannot say what changed. And the honest post-mortem always lands in the same place: the sequencing was wrong from the start.

The first ninety days are not a race to launch something. They are the window in which you decide what should be different, prove it can be, and build a plan someone will fund.

Here is how we run it, week by week, with the artefact each week has to produce.

Weeks 1 to 3: Establish what you are actually trying to change

Week 1: Get leadership to agree on the outcome, not the technology

One question, and it takes longer to answer than anyone expects.

What business number are we trying to move, and from what to what?

Not "where can we use AI." That question produces eleven candidate projects with no thesis connecting them, and it is how most programmes begin.

Get the right people in one room: someone from the business function that owns the outcome, technology, data, security, and finance. Finance in week one is unusual and it is deliberate. If the CFO first sees this at the approval stage, you will spend a month re-litigating a business case that could have been built correctly from the start.

Artefact by Friday: one page naming the priority outcome, the current number, the target, and who owns the decision. If you cannot write that page, do not proceed to week two.

Week 2: Map how the work actually happens

Not the process diagram. The real thing.

Sit with the people doing the work and trace it: where the manual handoffs are, where data gets rekeyed, which approvals exist because of a decision made in 2019, which steps depend on a spreadsheet somebody maintains privately.

This week regularly produces an uncomfortable finding. The biggest opportunity is frequently not where leadership assumed, and sometimes the process needs redesigning before AI would help at all. We have talked clients out of AI at this stage more than once, because a broken integration between two systems was the actual bottleneck and fixing it cost a fraction of the alternative.

That conversation is not a lost engagement. It is the point of week two.

Artefact: a workflow map with the friction points marked and quantified where possible.

Week 3: Capture the baseline

This is the week teams skip, and skipping it makes everything afterwards unprovable.

For each priority process, record what it costs today. Processing time. Cost per transaction. Error and rework rate. Hours consumed. Turnaround. Volume. SLA performance.

Get it from systems where you can and from a two-week sample where you cannot. Imperfect measured beats are precisely remembered.

The rule: anything you cannot measure before will be impossible to prove after. A return calculated retrospectively to justify a decision already made is a narrative, and everyone in the room knows it.

Artefact: signed-off baseline metrics with the method documented.

Weeks 4 to 6: Choose what to fund

Week 4: Build a real portfolio, not a wish list

Now translate business problems into candidate interventions.

Resist the fifty-item backlog. Six to ten serious candidates are right. For each one, document the same seven fields: the problem, what the AI actually does, the expected outcome in baseline terms, the data required, the systems it must touch, the risks, and a named owner.

That last field kills more bad ideas than any scoring model. A use case nobody will put their name against was never real.

Week 5: Score on value, feasibility, risk and adoption

Four questions per candidate, scored honestly.

• Value : How much does the baseline number move, in currency?
• Feasibility : Can we build this with the data and systems we have, not the ones we plan to have?
• Risk : What happens when it is wrong, and who is exposed?
• Adoption : Will the people who have to use it actually use it?

The compelling use case is often not the right first one. The right first one usually scores high on feasibility and adoption even if value is moderate, because it produces evidence and reusable capability faster. You are buying learning in the first cycle, not maximum return.

Artefact: a ranked shortlist of two or three, with the reasoning written down so the decision survives a leadership change.

Week 6: Decide build, buy or integrate

For each shortlisted candidate: would an existing platform do this? Would a standard model API do this? Does anything genuinely need custom development? What must it connect to? Where does sensitive data get processed, and under what controls? Where does a human stay in the loop?

Default toward the least custom option that meets the requirement. Custom development is sometimes right and is far more often a preference dressed as a necessity. A partner who consistently recommends building is optimising their revenue rather than your outcome.

Weeks 7 to 9: Design the operating model, then build

Week 7: Decide what the organisation looks like afterwards

This is the week that separates a transformation from a deployment, and most programmes skip it entirely.

• Which tasks disappear: Which roles change and how. Where human approval stays mandatory. Who owns a decision the system made. What the process does when the output is wrong.
• Design these before launch: Improvising them afterwards is how you get a technically successful system that the team quietly routes around.
• Be specific: "The system prepares the risk assessment, the manager approves, exceptions above threshold X escalate to Y" is a design. "Human in the loop" is a phrase.

Week 8: Set governance proportionate to consequence

Governance in week eight, not week twenty, because these are architectural decisions. What the system can retrieve, for whom. What it can do autonomously versus with approval. What gets logged and how you would reconstruct a decision six months later. How degradation gets detected. Who handles an incident.

Calibrate to stakes. An internal productivity assistant and a system informing credit decisions should not carry identical controls, and applying enterprise-grade governance to everything is how organisations conclude that AI governance makes AI impossible.

Week 9: Build and launch the pilot

Narrow enough to control, meaningful enough to measure.

The framing matters more than the scope. "Reduce average document processing time by 30% for the operations team while holding accuracy at or above the current process" is a business experiment with a falsifiable claim.

"Deploy an AI document processing platform" is a purchase.

Define the kill condition now, while everyone is optimistic. Agree in advance what result means stop, because that conversation is impossible to have honestly in week thirteen.

Weeks 10 to 13: Run it, read it, decide

Weeks 10 to 12: Let it actually run

Four weeks minimum. This is where the draft version of this plan goes wrong and where most real programmes go wrong too.

Week one of any pilot is people learning the interface. Week two is discovering the edge cases nobody scoped. Only by week three or four is anyone using it the way they will use it in production. Measure earlier and you are measuring the learning curve.

During the run, track two things in parallel.

The numbers, against your week 3 baseline. Hours, cost, speed, quality, error rate, adoption depth.

The secondary effects, which nobody budgets for and which frequently decide the outcome. AI often creates new work: validation, exception handling, an escalation queue that did not previously exist. A credible ROI figure subtracts these. An optimistic one ignores them, and then the number collapses at scale.

Talk to users properly in week 12. What got easier. What got harder. Where do you not trust it, and why. What still needs to be done by hand. What would stop you recommending this to a colleague?

If adoption is poor, resist the training explanation. Training does not fix a workflow that adds a step.

Week 13: Scale, refine, or stop, then write the roadmap

Three legitimate outcomes, and the third is not a failure.

• Scale: if the evidence supports it and production requirements are understood.
• Refine: if the value is visible but something specific in the process, data or interface is blocking it.
• Stop: if the case does not hold. An organisation that can kill a weak pilot at day 90 for the cost of a pilot has just demonstrated the single most valuable capability in enterprise AI. Most cannot, which is why so many programmes limp on for two years.

Then build the twelve-month roadmap: sequenced initiatives with dependencies visible, the investment each requires, the architecture and data work that has to happen first, governance, named executive owners, milestones and the measurement framework.

Sequence it: Do not launch everything at once. Some initiatives return quickly; others need foundational data work before they are possible at all, and the roadmap should make that ordering obvious to anyone reading it cold.

One honest caveat to state in the room: four weeks of pilot data is directional, not conclusive. It is enough to decide whether to continue. It is not enough to extrapolate an annual return with confidence. Say so, and you keep your credibility when the real numbers arrive in month six.

What you should be holding on day 90

Ten artefacts, not ten slides.

A stated ambition with an owner. A signed-off baseline. A documented use-case portfolio. A ranked business case. A readiness view across data, technology, governance and people. A target operating model. A proportionate governance framework. Evidence from one controlled pilot. An ROI assessment that includes secondary costs. A sequenced twelve-month roadmap.

If those do not exist, the organisation has spent a quarter discussing AI rather than transforming around it. That is a common outcome and an expensive one.

Three ways this goes wrong

• Choosing the platform in week one: Every subsequent decision then bends toward justifying it.
• Running six pilots at once: You cannot attribute anything, you cannot resource any of them properly, and none reaches production.
• Treating it as an IT project: Technology enables the outcome. The business function has to own it, or nobody will change how they work.

What the ninety days are really for

Not to prove your organisation can use AI. Almost every organisation can.

The harder question is whether AI can become part of how the business runs, decides and makes money. That takes a different sequence: operating reality first, measurable outcomes second, prioritisation third, governance designed in rather than bolted on, controlled evidence fourth, and scale only once something has been shown to work.

The strongest programmes we see do not start with a technology purchase. They start with a leadership decision about what should work differently in ninety days, and what should be unrecognisable in twelve months.

If you are at week zero and want the sequence run properly, that is where our engagements begin. Book an advisory session. We start with how your business actually operates, not with a technology recommendation.

Frequently Asked Questions

What should happen in the first 90 days of AI transformation?
Three weeks establishing the outcome and baseline, three prioritising use cases, three designing the operating model and building a pilot, four running and reading it.

How long should an AI pilot run before you measure it?
At least four weeks. The first fortnight measures the learning curve, not the system.

What is the most commonly skipped step?
Capturing the baseline. Without it, the result is unprovable and the business case becomes a retrospective narrative.

Who should own an AI transformation programme?
The business function that owns the outcome, with technology enabling it. Programs owned solely by IT rarely change how anyone works.

Is stopping a pilot at day 90 a failure?
No. Killing a weak use case for the cost of a pilot is the capability most organisations lack and the reason so many programmes run for years without value.

How many use cases should you pilot at once?
One, or at most two. More than that and you cannot attribute results, resource them properly, or get any of them to production.

When should governance be designed?
Before the build. What a system can access and do autonomously are architectural decisions, and retrofitting them means rework.