There is no go-live. That is the flaw in the change plan on the wall, and no amount of care in the rest of it compensates.
Classic change management is built around an event: a before, a cutover, a period of heightened support, a closure report. It works when the change is a state transition: a new finance system, an office move, a restructure. You can plan against a date because after the date the thing is different and stays different.
Copilot does not have a date. It has a release cadence, a licensing position that moves, and a regulatory context that moved twice this year. Run an event-shaped programme against it and the programme will finish while the change is still happening.
Your written artefacts have a half-life
Go and read what your organisation has written down about Copilot, and check how much of it is still true.
Three examples, none of them exotic.
The unit of consumption changed. It is the Copilot Credit, and the currency changed from messages to Copilot Credits on 1 September 2025. A business case written in messages is describing something that no longer exists, and it will be read by a finance team who will take the vocabulary at face value.
Commercial terms changed too. From 1 June 2026 there is a 15% saving on three-year commitments for 300 or more Copilot licences. Any procurement approach settled before that date was optimised against different terms.
Then the regulatory dates changed. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was adopted on 8 July 2026 and entered into force on 27 July 2026. It moved the Annex III standalone high-risk obligations, which include employment and worker management, from 2 August 2026 to 2 December 2027. Plenty of published guidance still carries the old dates. When I checked the widely cited tracker at artificialintelligenceact.eu on 8 August 2026, it still showed them. That is a month after the amending regulation was adopted, on the reference most people reach for first.
None of those changes were announced to your staff. All of them make something in your documentation wrong. The practical test of a programme is not whether its documents were right when written. It is how long they stay wrong after they stop being right.
What replaces the launch plan
A service with a budget line, an owner, and a rhythm. It is less exciting than a launch, which is the main reason it does not get funded.
Four components, and they are small.
- A monthly triage. One person spends a morning reading what changed in the product, the licensing and the regulatory position, and produces one line per item: no action, update guidance, update policy, or update the licence position. The output is a list of verdicts, not a summary of the release notes. The verdict is the work.
- A named owner with the authority to change guidance. If updating a page of user guidance requires a change board, the guidance will be out of date permanently, and everyone will use the version they saved locally in 2025 anyway.
- A decision log with dates. Not for compliance. For the moment in fourteen months when somebody asks why agents are restricted to one department and the only people who know have left. A decision with a date and a name attached can be revisited. Folklore cannot.
- A date and an owner on every artefact you publish. Policies, guidance pages, the intranet post, the slide someone will reuse. An undated document asserts that it is permanently true.
That is the whole operating model. It costs a fraction of a person and it is the thing that keeps the rest honest.
Communications become a service, not a campaign
Campaigns are designed to peak. This does not peak.
What works better is dull and continuous: one page that is always current, and a short monthly note that says what changed and what it means for you specifically. Two hundred words. No feature tours. If nothing relevant changed, say that. A note that occasionally says “nothing this month that affects you” is one people keep opening, because it has shown it will not waste their time.
Stop announcing capabilities people cannot use yet. Every announcement of something arriving later spends credibility you will want when something arrives that they have to act on.
I got this wrong for a long time. I used to build a proper launch: an all-hands, a champions kick-off, a comms calendar with a tail of about eight weeks. It produced a good spike in activity and almost no lasting change, and I could not tell the difference between the two at the time because activity was what I was reporting. What actually shifted behaviour was slower and less visible: small clinics for one team at a time, run repeatedly, on a real piece of their work, after everyone had stopped paying attention. The launch was the part that photographed well.
The problem with having no finish line
Without a go-live there is no moment of accountability, and things without moments of accountability lose their funding quietly. There is never a bad week to cut half a person from a service that has no deadline.
So give it an artificial one. Pick a date, a quarter out, and commit to publishing what changed, what you updated, what you decided to leave alone, and one number that somebody outside the programme already counts. That review is not a status report. It is the mechanism by which a standing cost keeps being paid.
Run it as a service with a budget line, or accept that your guidance will go stale and you will find out from a user who followed it.