Anyone who has renovated while still living in the house knows the three truths. The scope grows, the dust lasts twice as long as quoted, and what you actually remember afterwards is the six weeks the kitchen was a camping stove on the laundry bench. We have all watched enough Grand Designs to know exactly how it goes (the caravan on site, the Christmas deadline nobody believes, Kevin McCloud least of all, and yet they always seem genuinely surprised!). Sure, the budgets are very different, but a transformation programme in a live business goes wrong in the same three places.
When you turn your mind to it, the programme is the renovation with far more people living in the house. The service keeps running while the platform is replaced; staff and customers are in the dust together, in some shape or form. I run member service for one of Australia's largest superannuation funds and have been through transformations of that kind at different scales, as a sponsor and as the person running the service. What I take from all of them, consistently, is that we judge a programme on the everyday service, long after the business case is forgotten. Put differently, nobody thanks you for the architecture. Which means your job is really about the people who have to live in it.
Why does the kitchen matter?
Bent Flyvbjerg has spent an entire career studying why big projects fail, and his book How Big Things Get Done opens, rather pointedly, with a Brooklyn renovation gone badly over. His rule for everything from kitchens to the Olympics is think slow, act fast; planning is cheap and building is expensive, so it goes without saying where the time should go. I won't summarise it here but I do highly recommend it.
TSB in 2018 is the corporate example you should know. The bank moved its whole customer base to a new platform in one weekend; nearly two million customers could not get to their money for weeks and the chief executive was gone within five months. The review found the platform simply was not ready. Nobody outside the bank remembers what it was for. Every customer remembers those weeks. That is the kitchen.
Four things that have worked
The programme is going to happen anyway (it usually should) and the business is certainly not moving out. So what do you actually do? Four practices I have road-tested, and I think they travel.
Deciding what you will not touch
Every renovation grows if you let it. So does every programme. Once funding is approved, every function arrives at the steering committee with a perfectly reasonable change request. Your discipline is a short written list of what stays exactly as it is until the programme closes, agreed at the outset and defended by you personally at the steering committee. Change control depends on you being willing to say no to a good idea.
It feels timid. Perhaps it is, a little. But without that list the scope spreads quietly into every room and everyone lives in the dust for longer.
Doing the kitchen first
The kitchen is whatever people use every single day: the phone queue, the Thursday payment, the Monday morning login. Sequence the releases so the front line gets its tools first and the clever automation comes after. A programme that builds the back end for eighteen months and leaves the front line to the last release has decided that staff and customers will pay for it.
Put the front line in the design sessions and the user testing from release one. They know precisely which Thursday matters. Your programme office, frankly, does not.
Having a wet-weather plan with names in it
On The Block the rain always arrives the week the roof is off. In a programme your wet-weather plan is people and decision rights, agreed well before go-live, and it has to say who moves across to the queue, who can approve overtime without a meeting, who can call the rollback and how long hypercare runs before anyone is allowed to declare it over. If the plan only exists in the risk register it has never been tested. The bad week will test it.
In every bad week I have seen on a programme, the plan was the least of it. People walked out of their lanes without being asked; analysts assessed requests, leaders answered phones, whole teams dropped their own lists to take on someone else's work. You cannot write that into a plan the week before. It takes years, and it is built in the ordinary weeks. The plan only works where that culture already exists.
Moving back in properly
The builder leaves with the house ninety per cent finished. Programmes do the same. The go-live happens, the team is reassigned, and you inherit the list that was always going to be phase two. Moving back in properly means three things: the people who run the service sign off on the close, the business measures the benefits itself, and the open defects have owners and dates. You have moved back in when people stop calling it the programme and just call it work.
The part people still talk about
It is a lot to take on alongside keeping the lights on; but the alternative is a programme green on every milestone and disliked by everyone who has to use it. Decide what you will not touch, give the front line its tools first, agree decision rights before go-live, and do not close until the people who run the service say so.
Listen to what people say afterwards, too. A year on from the hardest stretch of any programme I have been part of, nobody mentions the milestones. They talk, usually fondly, about the organisation pulling together, people from every corner of it working the same queue. Protect that. And if someone proposes a go-live the weekend before a long weekend, ask them where they plan to cook.