Trap 10 - The go-live

Planning the wedding, not the marriage

Anyone who has planned a wedding knows the feeling. Eighteen months of decisions: the venue, the menu, the flowers, the band. A seating plan redrawn eleven times so that two uncles never share a table. A schedule for the day, down to the minute. There is a whole industry to help you: planners, checklists, apps, rehearsal dinners.

Then the day comes, and it is perfect. Everyone cries at the right moment. The photos are beautiful. The last guests leave at four in the morning.

And on Monday, real life begins. Whose turn is it to cook? Which bank account pays the rent? Where do we spend Christmas? Nobody wrote that plan. Nobody rehearsed it. There are wedding planners everywhere; I have never met a marriage planner.

The wedding lasts a day. The marriage is everything after. Large programs make exactly the same mistake, with much bigger budgets.

The program that succeeded, and still failed

Every program has its big day: go-live. For two or three years, everything points toward it. The plan, the budget, the steering committee, the dashboards, even people’s objectives and bonuses. The cutover weekend is rehearsed like a ceremony. When it works, there is cake, a thank-you email from the CEO and a slide that says “delivered on time.”

Then the program team moves on to the next program. And quietly, in the months that follow, the story changes. Users keep their old spreadsheets “just for now.” The legacy system is still running, because one team still needs it. The operations team learns the new system from its incidents. The business case promised savings, faster onboarding, happier customers, and nobody ever checks whether they arrived.

Officially, the program is a success. It was delivered. In reality, the organization paid for a transformation and got a new system running next to the old way of working.

That is the go-live trap: treating delivery as the finish line, when it is only the moment the value can start.

The ten faces of the trap

In 25 years, I have seen it take ten shapes, in three families: before the big day, on the big day, and after the party. Most programs that “succeeded” without changing anything show at least half of them.

Before the big day

Go-live as the finish line. The program’s definition of done, its budget and its success criteria all stop at go-live. Everything after belongs to “the business” or “run,” which means to nobody in particular.
Users meet it at training week. Real users see the system for the first time a few weeks before go-live, in a classroom, with demo data. Their feedback arrives when nothing can change anymore. Change management is reduced to a communication plan.
Operations, not invited. The run team discovers the system at handover: no runbooks, monitoring added at the last minute, an on-call rota built over a weekend. They will own it for ten years; they met it on Friday.

On the big day

The big-bang cutover. All users, all features, all data, on the same weekend. The bet is that everything works at once, because the plan left no room for anything else.
No way back. There is a plan to go live, and no rehearsed plan to go back. When the first serious problem appears on Monday morning, the only option is to fix forward, under pressure, in production.
The team leaves with the guests. The program team is disbanded, reassigned or out of contract the week after go-live. The people who understand why the system works the way it does are gone just when the questions start.

After the party

Benefits nobody measures. The business case was written to get funding, then filed. Nobody took a baseline before the start, so nobody can say what changed after.
The zombie legacy. The old system was supposed to be switched off “three months after go-live.” Years later, it still runs for one report, one team, one edge case, and the organization pays for both.
Workarounds become the process. Users route around what doesn’t fit them: an export to a spreadsheet, a shared mailbox, a manual step. Soon the real process lives outside the system, and nobody designed it.
IT owns the program, nobody owns the outcome. The sponsor’s attention moved on the day after the party. The system has an owner; the result it was built for does not.

The morning after

If you read The planning trap, you met Bent Flyvbjerg’s sobering number: of thousands of large projects, only one in two hundred delivered on budget, on time, and with the promised benefits. Most of this series has been about the first two. This episode is about the third, the one almost nobody checks.

And it really is rarely checked. In its 2016 Pulse of the Profession, PMI reported that a large majority of organizations, more than four in five, lacked maturity in benefits realization. Programs measure what they spend down to the euro, and what they return almost not at all.

The incentives stop at the altar. The budget, the team, the steering committee and the success criteria all end at go-live. The benefits arrive six, twelve, twenty-four months later, when the program no longer exists to collect them. What nobody owns, nobody delivers.

The dip nobody planned. After almost every go-live, performance gets worse before it gets better. Users are slower, the help desk is flooded, small defects pile up. That dip is normal; every new marriage has its first difficult months. But when nobody planned for it, it looks like failure. Managers ask to keep the old system “for safety.” And the safety net becomes permanent.

Two homes, one budget. Every month the legacy keeps running, the organization pays twice: two licenses, two infrastructures, two sets of skills, two sources of truth to reconcile. The savings in the business case quietly turn into extra costs, and nobody puts that line in a dashboard.

Early signals

You can tell whether a program is planning a wedding or a marriage long before the big day:

The plan ends on the go-live date.
Nobody can name the person accountable for the benefits, as opposed to the delivery.
No baseline was measured before the program started.
Real users haven’t touched the system three months before go-live.
The run team has not yet seen it, or sees it only in a handover meeting.
The cutover plan has no rehearsed rollback.
The program team’s contracts all end within a month of go-live.
The legacy decommissioning date says “after go-live,” with no date and no owner.
Success is defined as “delivered,” not as a change anyone could measure.

Plan the marriage

The answer isn’t to celebrate go-live less. Teams deserve the party. It is to define success as the change you wanted, and keep the program alive until that change is real.

Define done as value. Write the outcome as a measurable change, take the baseline before the program starts, and name the business owner who will report it at three, six and twelve months. If a benefit can’t be measured at approval, it won’t be measured after go-live.
Bring users in from the first month. Co-design with real users, test with them early, run pilots with a friendly group. Treat their workarounds and frustrations as requirements, not as resistance.
Make operations a gate, not a guest. The run team helps build the system, writes the runbooks with you, and holds a real veto at the operational readiness review. Better still, let the teams that build it also run it.
Go live in waves. One site, one segment, one product at a time. Every wave teaches the next one, and a problem touches a few hundred users instead of all of them.
Rehearse the way back. Every cutover has a rollback plan, tested like the cutover itself, with a clear decision point and a named person allowed to call it.
Keep the team through the honeymoon. Plan a hypercare period with the people who built the system, and release them only when the adoption targets are met, not when the calendar says so.
Plan for the dip. Tell sponsors in advance that performance will drop before it improves, by how much, and for how long. A dip that was announced is a milestone; one that wasn’t is a crisis.
Put the decommissioning in the plan and the budget. The old system gets a switch-off date, an owner and a budget line, just like the new one got a go-live date. The program isn’t finished while both are running.
Write it down before the team leaves. Decisions, runbooks, known issues, the reasons behind the odd parts of the design. The knowledge must outlive the program, for the people who will run it and for the AI agents that will help them.

What to avoid

A plan, a budget or a team that ends on the go-live date.
Showing users the system for the first time at training week.
Handing the system to operations instead of building it with them.
A big-bang cutover with no rehearsed way back.
Keeping the legacy running “for safety,” with no switch-off date.
Declaring success on delivery, without a measured outcome.
Letting the program team, and its knowledge, leave the day after the party.

The AI twist

AI is the most spectacular wedding planner ever invented. A convincing demo now takes days; a pilot, a few weeks. So organizations are holding more weddings than ever, and the marriages are struggling. In 2025, an MIT report claimed that around 95% of enterprise generative AI pilots had produced no measurable financial return. The exact figure is debated. The pattern isn’t: the demo was the wedding, and nobody planned the Monday.

AI also speeds up delivery, which means more go-lives landing on the same users. People can absorb only so much change at once. Ship faster than they can adopt, and you get a portfolio of delivered systems that nobody has had time to start using properly.

And the go-live trap has a new victim: the AI agents themselves. When the program team leaves without writing down why things are the way they are, the people who stay can at least ask around. Agents can’t. As I argued in The third ledger, undocumented knowledge is now a debt with interest.

Used after the party, though, AI may be the marriage counselor programs never had. It can read usage data and show which features are adopted and which are avoided. It can spot the spreadsheets and manual steps where users are quietly routing around the system. It can answer users’ questions inside the tool, at the moment they’re stuck, instead of in a training session three weeks earlier. It can map what still depends on the legacy, so it can finally be switched off. And it can draft runbooks and decision records from the code and the tickets, before the team leaves.

Till value do us part

The best programs I have worked on had surprisingly quiet go-lives. A first wave on a Tuesday, a second one two weeks later, no cake, a few nervous coffees. The real celebration came six months later, when the numbers in the business case finally moved, and the old system was switched off for good. That was the day everyone remembered.

This is the last episode of the series, so let me step back for a moment. Ten traps: the mosquito of too many yeses, Everest climbed in one push, the one-hour flight that takes five, the road to Abilene, the Sydney Opera House, the Vasa, nine women and one month, a bridge that missed by 54 centimeters, the watermelon, and now the wedding without a marriage.

No program avoids all of them. I never have. Think of them as cards dealt to you along the way. You will pick some up; everyone does. The programs that succeed are not the ones that never draw a card. They are the ones that recognize each card early, name it out loud, and put it down before the next one arrives. The programs that fail are the ones still holding a full hand on the big day.

So at your next go-live, after the cake, ask one gentle question: a year from now, what will be different, for whom, and who will still be here to check? If the room goes quiet, the wedding is planned. The marriage isn’t yet.

Thank you for following this series to the end. Which of these ten traps have you met most often, and which one did you manage to put down? I would genuinely love to hear your story.

All situations described here are composites, drawn from many programs over 25 years.