Year two of an AI transformation: what usually comes apart

The first anniversary of the programme is marked with a short deck. Three systems live, two more in pilot, a slide of quotes from the people who use them. The board is pleased, and nobody in the room is pretending: the year went well.

Fourteen months in, the finance director asks a question about the model bill, which is now a visible line in the IT budget and growing. The sponsor who would have answered it has moved to run a different division. The partner’s team is still in the building, and the two internal people who were meant to take over have been borrowed by the ERP upgrade.

Nothing has failed. No system is down. Yet the programme is now held together by habit and by the supplier, and the energy that carried year one has gone somewhere else.

The cause is rarely the technology. Year one runs on things that are naturally abundant at the start: executive attention, a fresh budget, a partner on site, and the novelty of the first results. Year two runs on things that have to be built on purpose, and year one is usually too busy shipping to build them.

Where it comes apart

The sponsor moves. Programmes are sponsored by people, and people change jobs. If the sponsorship lived in one person rather than in a role with a written mandate, the successor inherits a budget line and a set of running systems without the reasons for either. The safest thing to do with an inherited programme is to let it coast, and coasting is what year two looks like from outside.

The models change underneath. A model version used by the first systems is deprecated, or quietly behaves differently after an update. Prompts that were tuned in a pilot start producing slightly different answers. In year one this was the build team’s problem. In year two the build team has moved on, and the question of who tests a model change before it reaches users has no answer.

The partner is still on site. The original plan assumed the supplier’s share would decline. It did not, because nobody wrote the decline into the contract and nobody on your side was freed up to receive the work. The supplier is not doing anything wrong. It is doing the work that was never handed over, and invoicing for it.

The internal team never formed. Two names were pencilled in at the start as the people who would own this. One left. The other was never actually released from the previous job and has been doing both. There is no team, only a person with two roles and a mailbox of alerts.

The cost became a line without an owner. Model usage, hosting, the support contract and the licences arrive as a single number nobody can explain by system or by feature. The number grows with success, which is good, and with waste, which is not, and nothing distinguishes the two. When cost has no owner it is eventually judged by its size alone.

The second wave was not chosen. Year one picked the obvious cases. Year two needs a decision about what comes next, and that decision needs the capacity assessment the organisation skipped while it was busy. Without it, the second wave is whatever the loudest department asks for.

Infographic

What year one runs on and what year two needs

Year one, naturally available

• –A sponsor's personal attention
• –A fresh budget with no history
• –The partner's team on site
• –Novelty of the first results
• –Model versions as pinned at build

Year two, built on purpose

• →A role with a written mandate
• →A cost owner per system
• →A declining supplier schedule
• →An internal team that exists
• →A model lifecycle process

What to set up at the end of year one

Move sponsorship from a person to a role. A one-page mandate: what the programme is for, which decisions the sponsor may take alone, what the review cadence is. Written while the current sponsor is still in post, so the successor inherits a mandate rather than a mood.

Give every running system a cost owner. A person on the business side who sees that system’s model, hosting and support cost each month and can say whether it is worth it. The first month of doing this usually produces the first honest conversation about which systems should be narrowed.

Put the supplier’s decline on paper. Which parts of the work move to which of your people, by when, and what remains. If the people do not exist yet, hiring or releasing them is a year-one deliverable, not a year-two hope. How to write that schedule is covered in a good transformation partner should be getting smaller.

Decide who runs what is live. Each system needs a named operator, an evaluation set and a process for model changes before year two starts. The vendor’s retirement of a model version is a year-two certainty, not a risk, and the sibling post on what happens when the vendor retires your model describes what that process needs.

Choose the second wave against capacity, not appetite. A short capacity assessment: every programme running, who is on more than one, what can genuinely be taken on this half-year. Then pick fewer things than the list suggests.

A test to run this week

Take the three people most central to the programme today: the sponsor, the person who answers technical questions, and the one who talks to the supplier. For each, write down what would happen to the programme next month if they left this Friday. Who would sign the invoices, who would test the next model change, who would decide whether the second wave starts.

If each name has a written successor, a role description or a process behind it, year two will probably hold. If the answer in two of the three cases is a shrug, the programme is still in year one, whatever the calendar says, and the next six months should be spent on the right-hand column above before anything new is started.

This is also where an outside partner is not the answer: if the gap is an internal team that was never formed, buying more external capacity fills the gap and hides it at the same time.

Our part

In an AI transformation engagement the year-two column is part of the scope from the start: the sponsor mandate, the cost owners, the operating model and the schedule by which predictes gets smaller. If a programme is already in its second year and coasting, the work starts with the capacity assessment and the list of what is actually running.