Three weeks before cutover, in the readiness review, the sponsor asks you a question you were not expecting: “So what actually runs differently on day one?”

You have an answer for everything else. Training is at 84% and the last sessions are booked. The comms have gone out on schedule. The cutover plan runs to 24 pages and has been rehearsed twice. The data is loading at the rate the plan said it would.

What you do not have is a written answer to their question. You start listing things: the new approval limits, the reports that will come out of the system, the shared service picking up supplier invoices. They wait. Then they ask whether any of that is written down anywhere with a name against it, and the honest answer is no. It lives in the process designs, in the training decks and in the heads of about 40 people, and nobody has put it on one page.

That silence is yours. Eight months from now, when the old spreadsheets are still running in two plants and the CFO asks where the benefit went, the sponsor will remember who could not answer this question while there was still time to do something about it.

This issue is that page. It is called the day-one register, it fits on one side of A4/letter, and by Monday you can have the first three lines written. The reason your programme does not already have one comes from the way programme plans are built, which is also why nobody notices it is missing.

Why the page does not exist

Look at what your programme actually tracks. The plan tracks the build: environments, configuration, interfaces, data loads, test cycles, each with a date and a person who gets called when it slips. The change plan, if there is one, tracks activities: how many people have been trained, how many comms have gone out, how many champions have been named, how many process designs have been signed off.

An activity and an operating change are different things, and the plan only tracks the first. Training three thousand people is an activity. “From day one, purchase orders above £25k are approved in the system by the category manager, and the email approval stops” is an operating change. You can train every single person and still change nothing on Monday.

My view, and I hold it firmly: that is what usually happens. People go to the training, pass the quiz, and on Monday morning they do what they did on Friday, because nobody told them, in writing, with a date, what stops.

The plan does not carry the second list because the second list has no owner. The build owner owns the build. Nobody owns what the business does differently, so nobody writes it down. Last week’s issue was about that missing person, the one senior owner who holds the change the way the build owner holds the build: A committee is not an owner.

This week is about the page that person holds, because an owner with nothing written down has a title and nothing anyone can hold them to.

What a line looks like

A day-one register line has five parts. All five have to be there, or the line is a wish.

The process. A decision, a process or a control, by name. Not “procurement” but “approval of purchase orders above £25k”. Not “month-end” but “the intercompany reconciliation”. If it takes a paragraph to name, it is two lines.

Who runs it differently. One name from the business: the category manager, the plant controller, the team lead in the shared service centre. The programme never owns a line, because the programme does not run anything after go-live.

From when. Day one for most lines. Some start later because the calendar says so: a month-end line starts at the first month-end, and that is fine, as long as the date is written down and the owner has agreed it.

What stops. This is the part nobody writes, because writing it means naming the spreadsheet, the email chain or the local workaround people are attached to, and the person who has to switch it off. Write it anyway. If nothing stops on day one, nothing has changed. The new system has been added to the old way of working, and the business is now running both.

The week-one evidence. What would you look at on the Thursday of the first week to know this line is running? Approvals in the system with no email trail. No new rows in the old tracker. A report that came out of the system rather than being rebuilt in a spreadsheet. If you cannot name the evidence, you cannot tell running from not running, and the line will be reported green by default.

Two lines filled in, so you can see the shape:

Process: purchase order approval above £25k.
Who runs it differently: the category manager, one name.
From when: day one.
What stops: approval by email, and the finance inbox that queues them.
Week-one evidence: every PO above £25k carries a system approval and no email; the inbox queue is empty.

Process: the intercompany reconciliation.
Who runs it differently: the group controller, one name.
From when: the first month-end after go-live.
What stops: the reconciliation spreadsheet and the two-day manual match.
Week-one evidence: none until month-end, so the line reports “not yet due” and the sponsor knows why.

The register is one page. Twelve to twenty lines on a large programme is my honest range. If you have sixty, you have rewritten the process catalogue, and nobody senior will read it. Choose the lines where money, control or a customer changes hands. The rest already lives in the process documentation, which is where it belongs.

Who holds the page

The page has one holder, and every line has one name.

The holder is the adoption owner: the senior person from last week’s issue, a peer of the build owner, with the change budget and the authority to say the business is not ready. They write the register with the business before the gate, they put it on the table at the gate, and they report against it after go-live. It is the first concrete thing that role owns, and my view is that it is what makes the role real to everyone else: a person with a page they are answerable for.

The name on each line is the operating owner: the person who runs that process differently from Monday. Filling that column is where committee ownership fails all over again, because "the business" is a department, and a department cannot run a process differently on Monday morning. A named person can. A named controller can. If a line comes back with a department in the owner column, that line is not ready, however green the training numbers are. I still catch myself typing “ business” into an owner column when I am in a hurry (it is easier, and it commits nobody, which is exactly why it is easier).

If your benefits register has names in its owner column, the two pages should agree with each other. Every day-one line is the thing that makes one benefit line real. Where a benefit has no day-one line behind it, ask what is actually going to change so the money arrives. Quite often the answer is nothing yet, and it is better to hear that in the readiness review than in the year-one benefits review.

What the page is for

Three uses, in this order.

At the readiness gate, the question changes. Most gates ask whether training is complete, whether the comms have gone out and whether the business has signed the readiness statement. Those are activity questions, and all three can be yes while nothing is ready to run; a readiness pack built from them is the failure I wrote about in July, in Technically correct, strategically useless. With the register on the table, the gate asks one question, line by line: “Is this ready to run on Monday?” The operating owner answers for their own line, and the answer is yes, no, or not until a date. A no on a line where money changes hands is a go-live conversation. A no on a reporting line is a workaround with a date against it. Telling those two apart in one meeting is the whole reason the register fits on a page.

For the first 30 days after go-live, the register is the adoption owner’s report to the sponsor. The adoption report is one page, and every line on it says one of three things: running, not running, reverted. It replaces the adoption dashboard, which counts logins and cannot tell you whether the category manager has stopped approving by email. The weekly readout takes ten minutes, because there are fifteen lines and every one of them has a name.

A line that is not running escalates the same day, with a name attached, on the same route a technical defect would take. The old spreadsheet comes back in a plant on Tuesday; the plant controller owns that line; the adoption owner is on the phone to them on Tuesday, and the sponsor hears about it on Wednesday if it is still running the old way. Compare that with what usually happens: reversion turns up as an anecdote in hypercare, then as a footnote in the month-two review, and by then it is how things are done. A steering committee that hears about it a month later has already failed, in the way I described in SteerCo fail 48 hours earlier.

Where this still fails, and what to do then

You are already past cutover and there is no register. Write it now, from what was supposed to change. Take the process designs and the business case, list the lines, and put a name against each one. Writing the register after go-live starts an argument over about half the lines, from people who will tell you that change was never agreed, or was agreed with someone who has since left, or is "in progress". That argument is the conversation the programme should have had before the gate, and having it in month two costs a great deal less than having it in month eight, when the CFO asks where the benefit went.

The line nobody will own. Sometimes a change that is in the business case has no operating owner, because the person who would run it differently was never asked, or said no quietly. Do not leave it on the page with a department name against it. Take it to the sponsor as a decision: name an owner this week, or take the benefit that depends on it out of the case. Either answer is honest. Leaving a department name on the page is not.

The programme where nothing runs differently, by design. Some migrations were decided as like-for-like: same processes, new system, change deferred to a later phase. If that decision was made openly, you do not need this register. Write the three lines that do change, put them in the readiness pack, and leave the rest alone. If the decision was never made openly, and the business case still promises savings, then the empty register is the most useful page you will produce this month, because it shows the sponsor in one look that the case is buying a postponement. That conversation is uncomfortable now and expensive later.

And the workstreams that change nobody’s day, a technical upgrade, an infrastructure move, do not need a line at all. Leave them out.

This is an afternoon’s work and two hard conversations. You do not need a tool, a workshop or a template pack. You need the process designs, the business case, an hour with the adoption owner, and the nerve to fill in the “what stops” column truthfully.

Tonight, write three lines for your own programme: the process by name, the person who runs it differently, and what stops. If you can write three without asking anyone, write the rest tomorrow with the adoption owner. If you cannot write three, that is your programme status, and it tells you more than the training percentage does.

Reply and tell me which line you could not write, and who you think should own it; the next issues get built from what comes back.

Roman

About a year later the CFO stopped me in a corridor and asked one question: “So where did the benefit go?”

I started an answer and discovered, while speaking, in real time, that I did not have one. Neither did anyone else he had asked. The programme that existed to change the numbers could not point to where the numbers had changed. It had delivered everything except the thing it was initially designed for.

I have spent years since chasing that question across programmes, and the trail keeps ending in the same place: the change that was delivered but never owned.

Everything had an owner except the thing that mattered

Think about how that programme, and probably yours, was structured. The build had an owner, a person with a name whose weekend was ruined when the build was not progressing as expected. The data had one. The integrations, the testing, the cutover, all of them had a single human being attached, someone who could be called, texted, congratulated, or held.

The change, on the other hand, had a workstream. It had a plan, a budget, a slide in the steering pack, and a committee that met monthly to receive updates. What it never had was a name. Ask who owned making three thousand people work differently on Monday morning, and the answer came back in the plural: the business, the network of champions, the adoption board. Everyone, which operationally means no one.

The benefit went wherever adoption went. Nowhere in particular.

What a committee cannot do

This is structural, and I’d rather be precise about it, because committees are not useless. They are useful for exactly one thing: alignment. They cannot own, because ownership has physical properties a group does not have.

A committee cannot be called on a Tuesday night when the operations teams quietly revert to the old spreadsheets. A committee cannot hold a date; it can only note that a date has been missed. A committee cannot take an escalation; it can only add the item to next month’s agenda, which on a live programme is the same as declining the call. And a committee cannot be embarrassed, which matters more than we like to admit, because embarrassment is one of the few forces that reliably moves senior people.

Watch what your own programme does under pressure. A technical risk escalates to a person within the hour. An adoption risk escalates to a meeting that is three weeks away. The governance is telling you, in its own language, which failures it intends to prevent and which it intends to document.

Attendance is the currency committees trade in, and attendance is not accountability. Twelve people nodding at a dashboard is not one person lying awake.

What the adoption owner actually holds

The fix is one named senior person who owns the change the way the build owner owns the build. Not a champion, not a coordinator, not the change manager three levels down doing heroic work without authority. A peer of the build owner, visibly equal, holding four things.

• Authority: they can stop a go-live the business is not ready for, and everyone knows it.

• A budget: the change money sits under them, not scattered as a percentage across other people’s lines.

• An escalation route: when adoption stalls, they are who gets called, and they in turn can reach the sponsor without an appointment.

And a definition of done that has nothing to do with usage dashboards. They are not accountable for how many people logged in; counting logins is how adoption becomes a vanity metric.

They are accountable for the new way of working holding until the value shows in the numbers, which is the only place value counts.

If you want it on one page, it is this:

The adoption owner’s charter
Name: one person, senior, known to the sponsor.
Accountable for: the new way of working holding, until the benefit is visible in the numbers.
Holds: the change budget; the authority to delay go-live; a seat equal to the build owner’s.
Escalation: adoption risks come to them first; they reach the sponsor directly.
First question at every review: who got called this week when people didn’t use it?
Stands down when: the CFO can answer, unprompted, where the benefit went.

Retrofitting an owner onto a live programme

You do not need to restart governance to install this, which is fortunate, because the moment you most need an adoption owner is usually the moment the programme can least afford a redesign.

Name the person this week, out loud, in the forum where the build owner is already visible; ownership that is not announced is not ownership.

Re-route the escalations next: any risk with the word adoption, readiness, or behaviour in it goes to them first, and the committee hears about it afterwards.

Move the change budget under their line at the next reforecast, because authority without money is advice.

Then change one question in the review: retire “how is adoption tracking” and ask instead who got called this week when people did not use it. If the answer is nobody was called, adoption is not being governed; it is being watched.

The committee survives all of this, demoted to what it was always good at: the owner’s forum for alignment, not the place where accountability goes to be shared.

The person who should want this job

Nobody volunteers for adoption ownership, which is worth pausing on, because the reluctance is exactly what makes the role valuable to the right person.

It cannot be finished by effort alone, it depends on other people changing, and it produces nothing that looks clean on a review slide. Senior people read those properties as risk. Look instead at what the role demonstrates to the people deciding who runs the next programme. By that point execution is assumed; what they are looking for is evidence that you can be handed a problem with no work breakdown structure and still be trusted to land it. Owning the human half of a transformation is the cheapest available proof, because so few people bid for it that the field is empty.

One warning travels with the role. Take it only whole: the charter, the budget, the seat. Offered the accountability without the authority, decline politely and say why, in one sentence, to the sponsor. That sentence says more about your readiness than a year of green milestones.

Where this still fails

An owner without authority is a scapegoat with a title, and naming one is worse than naming nobody, because it lets the programme believe the problem is handled. An owner named at cutover is a paramedic hired after the car crash; the role earns its keep in design, when the processes people must adopt are still negotiable.

And when the operating model itself is wrong, when the organisation is being asked to run in a shape it cannot hold, no owner saves it; they just report the failure with unusual clarity. The role is a control, not a cure.

But run it whole, and the corridor question stops being frightening. The build ends at go-live. The change ends when one person can say it held, and mean it. If nobody can say it, it didn’t.

Reply and tell me who owns adoption on your programme right now, or whether the honest answer is a meeting; the next issues get built from what comes back.

Roman

At the half-year review the board moved a third of its budget and two of its strongest people to the integration workstream, which had been red for a quarter and had everyone’s attention.

Nobody argued. I did not argue either. On the evidence in front of that board it was the obvious call.

• One workstream was visibly in trouble.

• The other was visibly fine.

Eight months later the data workstream missed a milestone for the first time in two years, and I sat and listened to three senior people explain that it had always been the fragile part of the programme. The record supported them. Two years of governance had produced almost nothing to say otherwise.

Governance runs on exceptions

Every reporting system built for a large programme is an exception machine. RAG ratings, escalation paths, risk registers, exception reports, the weekly call that exists to surface what has moved. The apparatus is designed to find deviation and route attention to it, and it does that well.

None of it is designed to surface prevention. A decision that stopped a problem from forming produces no status line, because there is no status to report. The register never holds the risk that was retired before anyone wrote it down.

So a programme’s information about itself runs systematically warm on what is going wrong and cold on what is being prevented. Nobody chooses this. It falls out of the design.

Three things follow, and only one of them is about people’s feelings.

Money and attention flow toward noise, which is the story above. Budget moves to whoever is loudest about the difficulty they are in, and the quiet workstream funds the rescue.

The wrong lessons get institutionalised. Programmes hold post-mortems on failures and almost never on the parts that worked, so the method that prevented six months of rework leaves with the person who used it, while the failure gets a lessons-learned deck and a process change.

And the people who prevent problems get read as ordinary, which I have very nearly done to the best operator on a programme, and wrote about on LinkedIn yesterday.

What actually goes missing

The risk retired in week three, before it was ever worth a line in the register.

The dependency renegotiated while it was still a conversation rather than a date.

The scope discussion held privately with a market lead, so it never became a change request.

The integration assumption tested early, which is why the September window needs no contingency.

Every one of those is a decision, made by a named person, with a cost avoided that can be estimated. None of them will appear anywhere in the programme’s record unless somebody puts them there deliberately.

Report decisions, not activities

An activity list dies in the inbox. It reads as effort, it invites no response, and nobody repeats it in another meeting.

A decision travels, because a decision has a shape a listener can hold: something was in the balance, a call was made, and something else did not happen as a result. That is a story, and stories are what get repeated in the rooms you are not in.

The unit of visibility on a transformation is not the update. It is the decision plus its avoided cost, attached to a name.

The fortnightly line

This is the whole artefact. One decision per lead, per fortnight, six fields, no longer than the space below.

The decision. What was decided, in one line, with the date it was taken.

The alternative. What would have happened otherwise, in money, time or risk, with the basis for that estimate stated plainly.

The author. Who made the call, by name. Not the workstream, not the team.

The proof. The fact that shows it worked, or the date by which it will be visible.

The sponsor sentence. The single line your sponsor can say in their own meeting, without you in the room and without checking anything first.

The destination. Which forum needs this, and by when.

The sponsor sentence is the field people skip and the one that does the work. Write it as the sentence you want repeated: “We changed the cutover sequence in March, which is why the August window needs no downtime.” If your sponsor cannot say it from memory after reading it once, it is not finished.

Two practical points about where this lands. It goes into the body of what the board reads, not an appendix, because appendices are read by nobody who allocates budget. And it accumulates in the quiet weeks, which are exactly the weeks that feel safe to go silent. A record built only during crises is a record of crises.

Where this stops working

Three places:

• The first is counterfactual inflation. Every avoided cost is an estimate about something that did not happen, and the temptation to round it upward is constant. A claimed disaster that nobody can verify costs you more than saying nothing, because it teaches the room to discount everything else you report. State the basis, keep the number conservative, and let it be dull.

• The second is narration outgrowing delivery. There are people who have learned to report brilliantly and deliver adequately, and everyone in a programme knows who they are within two months. Making real work visible is a correction to a governance defect. Making thin work visible is a different activity, and the same room will eventually price it correctly.

• The third is the uncomfortable one. Sometimes quiet is quiet because nothing hard is happening. The test is in the fields above: if a lead cannot name a decision and what it avoided, there may not have been one. That is worth knowing too, and it is the same instrument that finds the opposite case.

The part I keep off the feed

A programme’s record is not a neutral account of what happened. It is an argument about what mattered, and it is written mostly by whoever bothers to write it.

That argument outlives the programme. It decides what the client believes about which parts of the transformation created value, which shapes the next phase and the next budget. It decides which of your people are remembered as the ones who handled the hard year. And it decides, quietly, who gets trusted with the next transformation, because the people making that choice are reading a record rather than watching the work.

At programme manager the job is to deliver clean work. The system rewards that, and it should. Then the gate changes, and nobody announces the change. Above that line you are being assessed on whether value moves through an organisation because of you, and value that nobody can see has not moved anywhere. A transformation lead who delivers well and reports thinly is competing against one who does both, and the second one is the safer bet from where the decision is made, every time.

There is a version of this that people find distasteful, and I understand why. The correction is not to talk about yourself more. It is to put the decisions and their consequences into the record with names attached, including names that are not yours. Do that consistently and the record starts telling the truth about the whole programme, which happens to include you.

Problems tell their own story. Competence needs an author.

Reply and tell me about a piece of work on your programme that nobody outside it knows happened. The next issues get built from what comes back.

Roman

The client’s operations director spoke for 4-5 minutes. He proposed the cautious option with a hardly tenth of my evidence, and the room agreed before even the coffee arrived.

I stayed behind to pack up, mostly so I didn’t have to share a lift with anyone. The programme sponsor stayed too.

“Your paper was better,” he said. “But Marcus spent the last two weeks having coffee with everyone in that room. You spent them with the data. He knew what the finance director needed to hear about headcount before she could nod. He knew the markets MD had promised his board there’d be no restructuring this year. What did you know about anyone at that table?”

I said something about the analysis speaking for itself.

“Nothing speaks for itself. Someone speaks for it, or nobody does.”

What I was calling politics

I had a name for what Marcus did, and the name was doing a lot of quiet work for me. Politics. The game around the work, played by people who couldn’t win on the work.

The label was very convenient because it turned a skill I didn’t have into a virtue I did. As long as pre-wiring a room counted as politics, my refusal to do it counted as integrity, and losing counted as being above the game.

"If you bring a finished answer to a room you haven't worked, you are the failure mode."

Here is the definition that survived that afternoon. A decision moves through people, and every person it touches carries stakes they have not declared. Reading those stakes is information work, the same as reading a contract or a cutover plan. Refuse it and you are not purer than the room. You are working with less information than everyone else in it.

Paul Nutt, a professor at Ohio State, spent two decades studying why organisational decisions fail. Half the decisions he tracked failed outright, and the failures piled up where somebody pushed a finished answer at people instead of working the decision through them. That finding usually gets read as advice for executives. Read it from our side of the table instead: if you bring a finished answer to a room you haven’t worked, you are the failure mode he was counting.

The question under the question

Every contested decision usually runs on two questions at once.

1. The stated one, which is on the agenda: which option is right.

2. And the operating one, which never appears anywhere: what will each person here have to explain, and to whom, if this goes each way.

The stated question is about the work. The operating one is about the people, and the operating one decides.

I told a shorter story on LinkedIn this week about being sent back for more analysis several times, by a room that turned out to be protecting a commitment nobody could mention. That is what the operating question looks like from the outside: it looks like the stated question, asked repeatedly.

You cannot hear the operating question directly, but it leaks.

• A deferral that keeps finding new reasons.

• A request for detail on ground the paper already covered.

• The sponsor who agrees with you at his desk and goes quiet at the table.

None of those people are lying to you. They are answering a question you haven’t found yet.

"It looks like the stated question, asked repeatedly."

Reading a room before it decides

The method is unglamorous. Before any contested decision, go person by person through the room and ask what each of them has to explain if it goes ahead, and to whom. Their board, their boss, their own team, the colleague they overruled last quarter. Then ask what each of them has already promised that this decision touches. Prior commitments are where the unsayable lives, because reversing one in public costs standing, and people protect standing before they protect outcomes.

Then have the conversations the meeting can’t hold, one person at a time, before the meeting. Not to sell. To find out. Open with their problem, never with your decision: “What would need to be true about headcount for this to work from where you sit?” gets you the operating question.

“Can I walk you through the recommendation?” gets you a polite preview of the meeting.

The most senior people I’ve watched do this spend most of the conversation building the other person’s exit. If someone has to move off a position they’ve taken publicly, they need a story in which moving is sense rather than surrender. New information arrived. The context shifted. The phasing protects what they promised. Give someone a dignified road out and they will usually take it. Corner them with evidence and they will fight you with the full creativity of someone defending their standing.

"Corner someone with evidence and they will fight you with the full creativity of someone defending their standing."

The pre-read I run before any contested decision

One page, 6 questions, filled in before I book a single meeting. It has never once come back empty.

The decision as stated: the question on the agenda, in one line.

The explanations: for each person in the room, if this goes ahead, what do they have to explain, and to whom?

The prior commitments: what has anyone already promised, to a board, a budget round, their own team, that this decision touches?

The unsayable: what is true here that cannot be said in front of the others, and who is carrying it?

The conversations: who needs a private conversation before the meeting, in what order, and what does each need to be able to say in that room without losing standing?

The exits: for anyone who has to move, what is the story in which moving is sense rather than surrender?

Where this stops working

Three places, as far as I have learned.

1. The first is the line. Used to find the organisation’s best answer, this is reading. Used to engineer your answer past the organisation, it is manipulation, and people detect the difference with unnerving accuracy, usually only once. My test is simple: if the whole map were read aloud to the room, would I be comfortable? The moment the answer is no, I have crossed over.

2. The second is over-reading. Some rooms are genuinely undecided. If every deferral becomes a conspiracy, you will start negotiating with ghosts, and you will be exhausting to work with.

3. The third is the hardest. Sometimes the unsayable thing is about you. Your firm’s fees, your last delivery, the workstream your team is quietly failing on. A pre-read that never includes yourself is a comfort exercise. Some of the silence in your rooms is people protecting you.

The people deciding whether you become a transformation director are not re-marking your analysis. They are watching whether rooms move when you are in them, because a director is someone a partner can send into a client’s decision alone. Alone means nobody senior there to read the room for you, to have had the coffees for you, to build the exits for you. That is the actual test behind the title, and it is why some brilliant senior managers stall for years while less brilliant peers pass them: the stalled ones are still winning the stated question.

There is a quieter cost too. “I don’t do politics” functions as permission to skip the hardest skill in the job, and the people who grant themselves that permission usually discover the gate only after their third flat year.

A decision is settled before it is made. Execution prepares for the meeting. Leadership joins the settling.

Reply and tell me about the last decision that was settled before you walked in. The next issues get built from what comes back.

Roman

A client needed to make a big platform decision. Six weeks of analysis went into it. Three options, properly costed. Every risk quantified. A recommendation that survived every test we threw at it. I was proud of that work, and I still think it was the best pure analysis my team ever produced.

We presented it. The room was polite. Someone called it “really helpful”. Then they asked for another meeting.

I found out what was actually going on in a corridor conversation afterwards. Two of the executives in that room had been fighting about this decision for over a year. Everyone already knew what the answer was. They just had not agreed to want it. Our beautiful deck had not brought analysis to a decision. It had brought ammunition to an argument, and every extra page made things worse.

The method we all learned

Every big consulting firm teaches the same way of working. Break the problem into pieces. Analyse each piece. Put it back together as a recommendation. Present it well.

It is a genuinely good method, and I am not here to mock it. It also made my career possible. The trouble is what we were taught alongside it: that it works on everything.

It does not. It works brilliantly on one kind of problem. And in my experience, the problems clients actually bring come in four kinds.

The four kinds of problems

Kind one, the diagnostic problem: “We don’t understand what’s happening.” Margin is leaking somewhere in the European business and nobody can explain why. This problem needs patience. You have to keep it open until you truly understand the mechanism underneath. What the standard method does instead is pick a suspect in week one and spend five weeks building the case against it. It feels rigorous. It is actually a guess with a paper trail. Research on decision-making backs this up: failure is about four times more likely when leaders run with the first idea they meet.

Kind two, the decision problem: “We must choose between options.” Three acquisition targets, one cheque. This is the problem our method was built for, and here it genuinely shines. Honest analysis across real options is exactly the right treatment.

There is one catch, and it is the most useful research finding I know. Paul Nutt, a professor at Ohio State, spent two decades studying how organisations make big decisions. He looked at over four hundred of them. About half failed. And the failures were concentrated in one pattern: the boss had already decided, and the analysis was commissioned to defend the choice. Those imposed decisions took around 22 months to land, and only half of them stuck. When leaders genuinely searched for options instead, decisions landed in around 14 months and about 85% stuck. Analysis that dresses up a done deal is not a decision process. It is theatre with exhibits.

Kind three, the design problem: “We must create something that doesn’t exist.” A new operating model. A business the market has not seen yet. This problem needs you to spread out before you narrow down: generate lots of ideas first, choose later. The standard method cannot wait. It benchmarks what competitors already do, builds a scoring matrix over three options, and picks a winner. The answer comes out neat, defensible, and built for yesterday.

Kind four, the alignment problem: “The parties haven’t agreed to want the same thing.” This is my deck story. Two executives at war, and a brief that says “give us the analysis.” What this problem actually needs is the disagreement worked: get the real interests on the table, find out what each side would need in order to say yes, and build the agreement person by person. What the method does instead is stack more evidence onto one side of an argument. And here is the thing I learned in that corridor: when the problem is a disagreement, every extra page of analysis reads as pressure. You cannot analyse your way out of a disagreement.

The reference card

• Diagnostic: "We don't understand what's happening." Needs: patience until the mechanism is clear. Dies when: a suspect is chosen early and proven at length.

• Decision: "We must choose between options." Needs: honest analysis across real options. Dies when: the choice was already made and the analysis is decoration.

• Design: "We must create something new." Needs: many ideas before any choosing. Dies when: the team benchmarks yesterday and picks from three.

• Alignment: "We haven't agreed to want the same thing." Needs: the disagreement worked, person by person. Dies when: rigour is used as ammunition.

How to tell which type of problem you’re standing in

Nobody taught me this part. I learned it from getting it wrong, and it now takes me four questions in the first meeting.

The four questions, in the order I use them:

1. “If the analysis lands clean, who acts, and what stops them?” If the honest answer includes a name and a grudge, you are in an alignment problem, whatever the brief says.

2. “Do the options exist yet, or do we need to invent them?” Choosing is a decision problem. Inventing is a design problem. Each one dies under the other’s treatment.

3. “Do we understand why this is happening, or only that it is happening?” A symptom without a mechanism means a diagnostic problem, however loudly the room asks for recommendations.

4. “Would you fund experiments that might fail?” If the answer is no, the room wants something new invented at the price of a simple choice, and someone should say so out loud.

And there is one sentence that gives the game away every time: “we need an analysis to prove who is right.” Nobody who says that has a decision problem. They have a fight, and they are shopping for a weapon.

Two honest warnings before you use any of this.

• First, real projects move between the four kinds. A margin question turns into a redesign, which turns into a turf war. So you re-ask the questions at every big gate, not just at kickoff.

• Second, I understand exactly why the standard method gets used on everything: it can be taught to a twenty-four-year-old, it scales across a big team, and its output is defensible in front of a board.

A method that fits one problem in four but can be taught will always outsell judgement that cannot be staffed. That is precisely why the fix is not a new method. It is one meeting and four questions before the machine switches on. Asking them costs nothing. It just needs someone senior enough to ask.

It all depends where you are in your consulting career

Somewhere between Senior Manager and Director, the thing you are being graded on quietly changes. Below that line, you are graded on running the analysis well. Above it, you are graded on knowing what work the situation actually needs. The two skills are almost unrelated, and nobody sends a memo about the switch.

Misreading the problem is how strong analysts stall. The work stays excellent. The client stays unmoved. And your credibility drains without anyone saying a word, because clients can always feel when the work missed the problem, even when they cannot explain how. Rigour can be delegated. Reading the problem cannot.

There is also a money angle to this, and it is the most senior thing in this letter. Reading the problem correctly will sometimes argue against the big analytical project your firm would love to sell. The consultant who walks in with the smaller, better-aimed piece of work is trading margin for trust. In my experience it is the fastest trust trade in this profession, because the client has met a hundred people who sold them analysis, and very few who told them what their problem actually was. Make that call visibly, once or twice, and it becomes the reason the people above the room start saying you are ready to sit with a client alone.

One last thing. The mismatched engagements are the exhausting ones. Six weeks of rigour that nobody wanted takes something out of a team that a well-aimed fortnight never does. Reading the problem first is not just better advice. It is how this job stays survivable.

Analysis is graded on rigour. Advice is graded on fit.

Reply to this email and tell me about the time your best work changed nothing, and what the problem turned out to be. I read every reply, and the next issues get built from what comes back.

Roman

47% of the people running those programmes agree.

That gap, measured by PMI a decade ago and never meaningfully closed since, is the sponsorship problem in one line. From above, the role feels done. From below, it feels absent. I told two stories about that absence on LinkedIn this week; a post can carry the lesson, but not the system.

This is the system: the evidence for why appointed sponsors don’t sponsor, the construction kit that fixes it from below, the three ways the fix backfires, and what building your sponsor signals to the people above the room.

Appointment is not activation

Start with the strangest fact in the delivery literature: the most important success factor is also the most reliably absent one.

Prosci’s benchmarking has ranked active and visible executive sponsorship as the top contributor to change success in every study it has run since 1998, cited roughly four times more often than any other factor. In the same research, programmes with highly effective sponsors meet or exceed their objectives about three times as often as those without. And yet the same benchmarking finds that roughly half of sponsors do not adequately understand what the role requires, and PMI’s global data has actively engaged sponsors on only about two projects in three, a figure that sat flat for years. In PMI’s 2018 study, a quarter of organisations named inadequate sponsor support as the primary cause of their failed projects.

A note on the numbers, because I hold this newsletter to the standard I hold business cases. Much of this evidence is practitioner self-report, and Prosci sells the interventions its research recommends. What makes the finding credible is convergence: a change-management vendor, a project-management association, the strategy firms, and a national audit office reach the same verdict from entirely different data. Bain’s transformation research lands the hardest version: only 12 per cent of transformations achieve their original ambitions.

So the single most valuable behaviour in delivery is missing from a third to a half of the programmes that depend on it. The interesting question is why.

Why the chair stays empty

The comfortable answer is character: we got a weak sponsor. The evidence says structure, four ways.

1. First, the arithmetic never worked. Sponsoring one major programme properly takes something like 10% to 15% of an executive’s working week. PMI found sponsors averaging 3 concurrent projects and around 34 hours a week on sponsorship duties on top of the day job. Nobody survives that maths, so the role quietly collapses into what fits the diary, which is symbolism.

2. Second, the symbolic fallacy. Most sponsors believe the job is to approve the business case, appear at kickoff, and return for the victory lap, because nobody has ever told them otherwise. They are deeply trained in running operations and almost never trained in sponsoring change, so they look to the programme team to deliver it and assume their part is done. Appointment gets mistaken for activation on both sides of the relationship.

3. Third, the default assignment. Whoever heads the department gets the badge, capacity and appetite unchecked, and when the diary bites they delegate to a proxy who has interest but no clout, which makes the sponsorship politely toothless.

4. Fourth, and least discussed, the role outlives nobody. The National Audit Office looked at major UK equipment programmes and found a median programme duration of 77 months against a median Senior Responsible Owner tenure of 22. The structure guarantees that most long programmes burn through several sponsors. Universal Credit ran through six SROs in its first four years, an average tenure under six months, one of them, the NAO later revealed, working a single day a week through serious illness. The Institute for Government’s verdict on that churn: it “did immense damage”. The counter-proof matters just as much: the programme stabilised only when one sponsor stayed for a decade.

Underneath all four sits an incentive truth the frameworks tiptoe around. Sponsors are measured and paid on business as usual, not on benefits realisation. The programme learns that in the first hard quarter.

None of this excuses an empty chair. It explains it, and the explanation is the point: if the causes are structural, waiting for a better sponsor is not a plan. Building one is.

The construction kit

On Tuesday I described the 30-minute conversation that turned my quiet sponsor into a working one. That conversation is the front door. Here is the whole house.

One decision they own. Named, minuted, and genuinely theirs. Not “support the programme” but “you own the go decision on the finance cutover”. A sponsor with a decision has a reason to stay engaged; a sponsor without one is an audience.

Two doors only they can open. Name the rooms and the peers the programme cannot reach without them, and ask for exactly those. Specificity is what converts goodwill into action.

One sentence of air cover. Drafted by you, adapted by them, rehearsed before it is needed: the line they will say to their peers when the programme hits weather. Air cover that has to be composed during the storm arrives late.

The contracting conversation, thirty minutes. Frame it as respect, not remediation: “there are three things on this programme only you can do.” Executives do not resent being given a defined job; they resent discovering, mid-crisis, that they had one.

The fifteen-minute rhythm. Fortnightly, one page, three items: the decision coming toward them, where their sentence lands next, and what their peers should be hearing from them. No status theatre; status by exception only.

The no-surprises rule, both directions. They are never surprised in a room because of you; you are never surprised by their diary. This rule is the currency everything else is bought with.

Why the kit works is worth naming, because each part answers one of the structural causes. Decisions arrive as decision asks, options with costs and a recommendation, because busy executives act on what is structured and defer what is open-ended. The talking points and the sentence are drafted by you because a saturated sponsor performs what is prepared and postpones what is not; the research politely calls these frictionless assets. Coalition-building gets the most help because it is the role sponsors fail at most, the weakest-rated behaviour in Prosci’s data, so the lead maps the coalition and hands the sponsor named asks rather than a vague plea for support. And the pre-briefing discipline from the previous issue is the delivery mechanism for all of it: the meeting before the meeting is where a built sponsor actually earns their keep.

One calibration: the job you build changes shape over time.

• Early, it is backing the programme leader and fixing priorities.

• In the middle, it is communication and politics.

• At the end, it is refusing to let the organisation declare victory before the benefits land.

Re-contract at each turn, and re-contract within a fortnight of any new sponsor, because the churn statistics say you will get one.

Where this backfires

Honesty requires this section, because the construction move carries three real hazards, and the literature that ignores them is doing you no favours.

1. The first is the puppet fallacy. If you script everything the sponsor sees and says, you have not built a sponsor; you have built an echo, and you have quietly removed the one person positioned to challenge your programme’s assumptions. The test is simple: if your sponsor has never pushed back on you, the construction has gone too far. You build the role. They must inhabit it.

2. The second is the transferred accountability trap. Manage upward too completely and the organisation quietly re-homes executive accountability onto you: when benefits slip because a peer division resisted, the question becomes why you failed to manage your sponsor. Keep the accountability where governance put it, in writing, in the charter and the minutes.

3. The third is fragility. A relationship you constructed leaves the building with either of you. Institutionalise it: the decision in the charter, the rhythm in the calendar, the sentence in the record, so the role survives its occupants.

And one honest limit. Everything above assumes a sponsor who is passive, not hostile. For the executive who is politically invested in the programme’s failure, no kit exists, in the literature or anywhere else. The professional move there is to escalate the gap itself, early and in writing, because an unsponsored programme dressed up as a sponsored one is a governance defect, and naming it is protection, not betrayal.

What this signals above the room

The people who decide whether you make a Programme Director are, overwhelmingly, the population that sponsors programmes. When you construct a sponsor well, the person experiencing your most senior work first-hand is exactly the person whose opinion of you decides what you lead next. Running a team well is expected at your level. Constructing the executive layer above your programme, quietly, without ever making the executive feel managed, is scarce, and it is visible to precisely one audience: theirs.

There is a compounding effect the frameworks never mention. A sponsor who succeeded because of you does not just remember it; they can describe it, from evidence, in rooms you will never enter. The sponsorship you built for the programme becomes sponsorship for you, and it is the only kind that survives a promotion discussion, because it is testimony rather than impression.

And the sustainability arithmetic, since this letter is also about not burning out: the kit costs perhaps two hours a month. One unsponsored crisis consumes weeks and a piece of your reputation. The version of this career that lasts is the one where the executive layer works, and the executive layer works because somebody built it.

An appointed sponsor is a name on a governance slide.

A built sponsor is the difference between air cover and silence.

Reply to this email and tell me about the sponsor you had to build, or the one you couldn’t. I read every reply, and the next issues get built from what comes back.

Roman

This is the system. The complete preparation system I now run, why it works, where it still fails, and what running it says about you to the people above the room.

The room confirms. It doesn't decide.

Start with what a steering committee actually is, because most of the failure is baked in before anyone opens a slide pack.

In most organisations, 12 senior people do not make a complex decision together in one hour. It has never happened in any programme I have run or chaired. What a committee does is confirm decisions its members have individually already accepted, and share the risk of that confirmation across the table.

That is not a cynical reading; it is the only way a forum of that seniority can work. Each person at the table is accountable elsewhere for what they endorse here, so no executive will publicly back something they have not privately tested.

Which explains the death rattle every programme lead learns: “deferred for further analysis.” It is rarely about the analysis. It is the room protecting itself from a surprise. A recommendation discovered live, however well argued, asks 12 people to take a position in front of their peers on something they saw an hour ago. The safest individual move is delay, so delay (in a form of deferral) is what the room produces.

Once you see that, the timing of failure becomes obvious. The outcome is settled roughly 48 hours before the meeting starts. By then, every person whose voice matters either understands and supports what you are bringing, or is about to discover it in front of colleagues. Everything below is the system for making the first of those true.

The one-page decision memo

Two full working days before the steering committee meeting, every member receives one page. Not the full pack. Just one page, and the decision sits at the top of it.

Decision required: one sentence, written so it can be answered. “Approve option B for the finance data migration, releasing £1.4m from contingency” is decidable. “Discuss migration approach” is not.

Why now: what deferral costs, with a date on it. “A decision after the 28th moves cutover past year-end freeze” tells the room what their delay buys.

Options considered: two or three, each with its trade-off stated plainly, and the recommendation named. Committees trust people who show the discarded options; a single option smells like a sales pitch (and will most likely be “deferred for further analysis”.

What we need from whom: the owner and the date for each consequence of the decision.

Risk either way: what we accept by deciding, and what we accept by not deciding. The second half is the one most decision papers omit, and it is the half that moves rooms.

The discipline of this page is for you more than for them. If the decision cannot be written in one decidable sentence, it is not ready for a committee, and the memo just saved you from finding that out live. The detailed pack still exists, because governance needs the record, but it travels as a supplement. Evidence for a decision that has already been socialised, not the vehicle by which anyone discovers it.

The meeting before the meeting

The memo earns you attention. The pre-briefs earn you the decision.

In the two days between memo and meeting, I speak to every voice that matters, 15 to 20 minutes each, and the order is deliberate. The first conversation goes to the person most likely to object, because objections are worked in private and performed in public, and you want the working version. The question that matters in that conversation is not “do you agree” but “what would need to be true for you to support this.” Listen for the sentence “I can support this if,” because everything after the if is an amendment you can usually make, and an objector whose condition you built into the recommendation arrives at the meeting as an owner of it.

Then the people who influence the decision owner, so the recommendation reaches them through more than one channel. The chair gets the second-to-last conversation: a no-surprises summary of where every member stands, what conditions were raised and absorbed, and the one sentence you will open with. A chair who knows the item is wired can run the room; a chair who is guessing protects the room instead.

Two things this is not. It is not lobbying: lobbying asks people to agree regardless of the merits, while a pre-brief tests the merits privately so the room can confirm them publicly. And it is not sneaky: executives expect it, and at senior levels the pre-brief is the courtesy, because it gives each person the chance to react somewhere their reaction costs nothing.

By the meeting, the item is not a proposal. It is a confirmation with a paper trail.

Running the room

Open with the decision, not the journey. "We are here for two decisions; the first is on page one" does in ten seconds what 40 slides cannot.

Status is given by exception only: anything green gets one line, and the room's attention goes where the memo pointed it.

Never announce the wiring; let the alignment show as ease. Close by reading back what was confirmed and which conditions attach, so the minutes record a decision rather than a discussion.

My steering committees now run to half their old length, and I have stopped measuring their success by how the presentation went, because there barely is one.

The three failures that survive good preparation

Honesty requires this section, because the system reduces failure and does not abolish it.

The proxy. A sponsor you briefed sends a delegate nobody briefed. The delegate cannot commit, and your confirmed item is suddenly a discussion again. The counter is in the pre-brief itself: when a sponsor’s attendance looks doubtful, ask who would attend instead, brief that person too, and ask the sponsor whether their support can be minuted in their absence. A wired delegate is fine; an unwired one is usually a surprise occupying your sponsor’s seat.

The new fact. Something material moves between memo and meeting: a number, an incident, a resignation. The 48-hour window is deliberately short to shrink this exposure, but when it happens, the rule is absolute: no pre-briefed sponsor is ever surprised in the room. A two-line message the morning of the meeting, “one figure has moved, here is what it changes and what it does not,” costs you nothing and preserves the thing the whole system runs on, which is that people trust your no-surprises promise.

The hijack. An executive arrives fighting a different war, budget, territory, an old score, and your item becomes the hostage. You cannot pre-brief this away, because the fight is not about your item. What saves you is the chair conversation and your opening sentence: a chair who knows the item is wired, and a stated decision the room can be brought back to, turn a hijack into a 5-minute detour instead of your slot.

What this signals above the room

Here is the part I would not write on LinkedIn, and the reason this newsletter exists.

The people who decide whether you are retained as a programme director or, in fact, make a director are usually in that room, and they are not grading your pack. They are answering a different question: can this person be trusted with a room of executives, unsupervised. Delivery excellence got you into the room; it does not answer that question, because the question is about judgement, and judgement is invisible unless you make it legible.

Pre-wiring is judgement made legible. It demonstrates that you understand how decisions actually happen, which most people at your level do not. It puts you in 6 private conversations with the exact people whose opinion of you decides your next role, conversations in which you are testing recommendations and absorbing conditions, which is to say, behaving like the level above you. And months later, when your name comes up in a room you are not in, those are the people who can describe your judgement from first-hand experience, which is the only kind of advocacy that survives a promotion discussion.

There is a quieter benefit. This system costs about 2 hours of conversations per committee and buys back the weeks that deferral loops and resubmissions used to eat. The version of this career that does not burn you out is the one where meetings confirm instead of ambush, and that version is built in the 48 hours before, not in longer nights on a bigger pack.

The pack proves the work was done. The preparation proves you can be trusted with the room.

Reply to this email and tell me where your last steering committee went sideways. I read every reply, and the next issues get built from what comes back.

Roman

• RACI defines who does the work (Responsible) and who signs off (Accountable), but not who drives it forward

• In multi-partner programmes, this gap creates decision paralysis, accountability games, and finger-pointing

• Five governance frameworks exist: RACI, RASCI, DACI, RAPID, and MOCHA – each designed for different contexts

• For transformation execution, DACI is the right choice: it explicitly names the Driver (who ensures work moves forward) and the Approver (who makes the call)

• For steering committee decisions with multiple stakeholders, add RAPID to name a single Decider

• This article reviews all programme governance frameworks and explains why DACI wins for transformation programmes

You are in a steering committee. The RACI chart is on the screen. The vendor is Responsible for data migration. The client sponsor is Accountable.

Someone asks: “Who is making sure this actually happens? Who is engaging the right stakeholders, scheduling the workshops, chasing the decisions?”

Silence.

The vendor says: “We are doing the work, but we cannot force client decisions.”

The sponsor says: “I am accountable for the outcome, but I am not running this day-to-day.”

Everyone has a letter. No one is driving.

This is the governance gap that quietly kills transformation programmes. Not missing processes. Not bad intentions. Just a framework that assumes someone will drive without ever naming who.

Sound familiar?

Before we go further, I’m curious what you’re seeing in the field.

What RACI Gets Wrong

RACI emerged in the 1950s from management consulting. It was designed for internal projects with clear hierarchies: one organisation, one chain of command, one boss who could hold people accountable.

It defines four roles:

• Responsible – who does the work

• Accountable – who signs off (and supposedly “owns” the outcome)

• Consulted – who gives input before decisions are made

• Informed – who needs to know after decisions are made

This works nicely when:

• One team delivers to one manager

• Authority flows through a single hierarchy

• The Accountable person has direct control over the Responsible person

• Decisions stay within one organisation

It falls apart when:

• Multiple vendors share delivery responsibilities

• Authority is distributed across organisations

• The Accountable person cannot direct the Responsible parties

• Decisions require alignment across competing interests

In other words: it falls apart in transformation programmes.

RACI is not failing because people are incompetent. It is failing because it quietly assumes conditions that no longer exist.

• It assumes a single organisation context, where authority and accountability sit within the same boundary.

• It assumes line management authority, where the Accountable role can direct the Responsible role.

• It assumes decisions are internal, not negotiated across contracts, vendors, and steering forums.

Digital transformation programmes violate all three assumptions by design.

The Three Gaps That Kill Transformation Governance

When you apply RACI to multi-partner programmes, three critical gaps emerge.

Gap 1: No Driver

Who ensures work moves forward?

Who engages stakeholders, schedules workshops, chases decisions, and removes blockers?

In RACI, the Accountable person is supposed to “own” this. But in transformation programmes, the Accountable person is often a senior sponsor, someone with ten other priorities who cannot drive work day-to-day.

The Responsible party does the work. But they are often a vendor who cannot force decisions from the client side. They cannot schedule workshops without client availability. They cannot resolve design disputes between client stakeholders. They cannot approve scope changes.

So work stalls. The vendor waits for the client. The client waits for the vendor. Everyone points at the RACI chart and says: “I did my part.”

In transformation programmes, “Driver” is not an optional governance enhancement.

It is a structural requirement.

Gap 2: No Decision Authority

RACI assumes Accountable = Approver = Decider.

In complex programmes, these are often different people.

Or committees.

Or informal consensus that never quite forms.

The result: decisions bounce between forums. They wait weeks for the next Steering Committee. They die in endless alignment meetings where everyone is consulted but no one is empowered to say ‘yes’ or ‘no’.

I have seen programmes where “Accountable” meant “will be blamed if this fails” rather than “has the authority to make this succeed.”

That is not governance. That is a setup for finger-pointing.

Gap 3: Accountability Without Authority

Someone is marked “Accountable” but cannot actually influence the work.

Architects labelled Accountable for solution designs they cannot enforce.

Architects are often treated as Accountable because they “own the design”.

But owning design quality is not the same as owning delivery outcomes.

Architects can be accountable for architectural coherence, technical integrity, and adherence to principles. They should never be accountable for delivery speed, vendor performance, or business adoption unless they control the levers that make those things happen.

Client managers Accountable for vendor deliverables they cannot control.

Programme directors Accountable for benefits that depend on business changes they have no authority to mandate.

This is pressure without power. It creates resentment, not results.

What Happens When No One Drives

These gaps create predictable failure modes. You will recognise them.

Failure Mode 1: Decision Paralysis

Everything escalates.

Design decisions that should take a day wait for the next Design Authority. Design Authority decisions wait for Steering Committee. Steering Committee defers to “offline alignment”.

A Fortune 500 manufacturing firm learned this the hard way during their global ERP rollout. They assigned regional business units as “Consulted” for global process templates.

The regions interpreted “Consulted” as “Consent Required”.

43 Regions flooded the programme with over 2,000 change requests to localise the processes. The system integrator ground to a halt, waiting for the Programme Director to resolve the conflicts. The Programme Director lacked the political power to overrule regional VPs.

The programme paused for six months. Five million dollars burned in “standby army” costs – consultants and contractors waiting for decisions that never actually came.

The RACI was perfect on paper. Everyone had their letter.

And the programme nearly died.

Failure Mode 2: The Blame Game

RACI becomes a legal document for post-mortems rather than a collaboration tool.

People hide behind their letter.

• “That is not my R”.

• “I was only Consulted, not Accountable”.

• “The RACI says the vendor is Responsible, so this is their problem”.

I have watched vendors and clients spend more energy and time defending their RACI assignments than solving actual problems.

The framework designed to create clarity becomes a weapon for avoiding responsibility.

Failure Mode 3: The Integration Gap

In multi-vendor programmes, each vendor is Responsible for their piece. No one is Responsible for making the pieces fit together.

Vendor A delivers their scope.

Vendor B delivers their scope.

Neither works with the other because no one drove the integration. Each vendor points at the RACI: “We delivered what we were Responsible for, and what’s in our statement of work (SoW)”.

The client, marked Accountable for overall success, is left holding the pieces.

Failure Mode 4: The Anti-Agile Effect

Practitioners working in agile transformations often find RACI causes friction at the team level.

RACI focuses on individual accountability: “I did my job”.

Agile focuses on team accountability: “We delivered the value”.

When you overlay RACI onto agile teams, people revert to “ticket passing” behaviour. They complete their assigned task and throw it over the wall. The agile, collaborative, outcome-focused mindset breaks down.

This does not mean governance is unnecessary. It means RACI is the wrong framework for how modern programmes actually work.

The Five Governance Frameworks: A Complete Review

RACI is not the only option. Four other governance frameworks exist, each designed to solve different problems.

Before choosing a governance framework for your transformation, you need to understand what each one does, and what it does not do.

Framework 1: RACI

Stands for: Responsible, Accountable, Consulted, Informed

Origin: 1950s management consulting, designed for internal projects with clear hierarchies

What it defines:

• Responsible: Who does the work

• Accountable: Who owns the outcome and signs off (rule: only one A per task)

• Consulted: Who provides input before the work is done (two-way communication)

• Informed: Who is told after decisions are made (one-way communication)

What gap it fills: Basic task clarity, i.e. who does what

When to use it:

• Single-organisation projects with clear reporting lines

• Tasks where the Accountable person has direct authority over the Responsible person

• Simple approval workflows

When NOT to use it:

• Multi-partner programmes with shared accountability

• Complex decisions requiring explicit decision rights

• Situations where “Accountable” lacks authority over “Responsible”

The core weakness for transformations: RACI does not define who drives work forward or who makes decisions. It assumes the Accountable person does both. In multi-partner programmes, they usually cannot.

One-line summary: RACI tells you who does and who approves but not who drives or who decides.

Framework 2: RASCI

Stands for: Responsible, Accountable, Supportive, Consulted, Informed

Origin: Variant of RACI, adds a Support role for complex delivery

What it defines:

• Responsible: Who does the work

• Accountable: Who owns the outcome

• Support: Who actively helps the Responsible party (hands-on assistance, not just advice)

• Consulted: Who provides input

• Informed: Who is told after decisions are made (one-way communication)

What gap it fills: Clarifies who is hands-on helping versus who is just advisory

When to use it:

• Multi-party delivery where teams actively support each other

• Situations where “Consulted” is too passive so you need people rolling up their sleeves

• Vendor-client relationships where the client provides active support (data, access, decisions)

When NOT to use it:

• When you need decision clarity (RASCI still has no explicit Decider)

• When you need a Driver role (RASCI still assumes Accountable drives)

Why it is not enough for transformations: RASCI improves on RACI by distinguishing active support from passive consultation. But it still has the same weakness for transformation scale: no explicit Driver, no explicit Decider. Adding the Support role helps with execution clarity but does not solve the governance gaps.

One-line summary: RASCI clarifies who helps but still does not clarify who drives or decides.

Framework 3: DACI

Stands for: Driver, Approver, Contributor, Informed

Origin: 1980s, developed for environments where decision-making clarity was critical

What it defines:

• Driver: Who drives the work forward: coordinates inputs, schedules decisions, chases blockers, ensures progress. Does not do all the work but makes sure it happens.

• Approver: Who makes the final call. One person with decision authority. Their ‘yes’ means go; their ‘no’ means stop.

• Contributor: Who provides input and does parts of the work. Combines RACI’s Responsible and Consulted.

• Informed: Who needs to know the outcome.

What gap it fills: Explicitly separates driving from approving. Names who keeps things moving, distinct from who makes the call.

When to use it:

• Multi-partner programmes where no single party controls all the pieces

• Workstreams and deliverables that require coordination across teams

• Any situation where work stalls waiting for someone to “drive”

When NOT to use it:

• Simple tasks where driving and approving are naturally the same person

• High-stakes decisions requiring explicit veto rights (use RAPID instead)

Why it works for transformations: DACI directly addresses the Driver gap. The Driver is explicitly named and accountable for progress. Not just for doing work, but for making sure work gets done. This prevents the “everyone has a letter, no one is driving” problem.

One-line summary: DACI names who drives and who decides, the two things RACI leaves ambiguous.

Framework 4: RAPID

Stands for: Recommend, Agree, Perform, Input, Decide

Origin: Bain & Company, early 2000s, designed for complex multi-stakeholder decisions

What it defines:

• Recommend: Who develops the recommendation: gathers input, analyses options, proposes a course of action

• Agree: Who must agree before proceeding – a formal veto right, used for compliance, legal, or technical feasibility

• Perform: Who executes once the decision is made

• Input: Who provides information and perspective influences but does not decide or veto

• Decide: The single person who makes the final call. One person. Not a committee.

What gap it fills: Explicitly names the Decider and distinguishes input (no veto) from agreement (veto). Prevents decisions from dying in consensus-seeking.

When to use it:

• Steering Committee or Design Authority decisions with multiple senior stakeholders

• High-stakes decisions where multiple parties have legitimate interests

• Situations where “Consulted” keeps being interpreted as “Consent Required”

• Go/No-Go gates, major scope changes, strategic trade-offs

When NOT to use it:

• Day-to-day workstream execution (too heavyweight)

• Simple decisions where one person naturally owns the outcome

Why it works for transformations: RAPID solves decision paralysis by forcing clarity on who decides. The Decide role is singular. Input providers can influence but cannot block. The Agree role is reserved for veto requirements, not political comfort.

One-line summary: RAPID ensures one person decides and everyone else knows their role is input, not veto.

Framework 5: MOCHA

Stands for: Manager, Owner, Consulted, Helper, Approver

Origin: Nonprofit and social sector, developed by The Management Center for mission-driven organisations

What it defines:

• Manager: Who supports the Owner and holds them accountable, provides coaching, removes blockers, ensures the Owner succeeds

• Owner: Who owns the work, i.e. the single point of accountability for driving it forward

• Consulted: Who provides input

• Helper: Who actively assists the Owner (similar to RASCI’s Support)

• Approver: Who signs off on the final output

What gap it fills: Separates ownership from management. Clarifies that the Owner drives while the Manager supports and holds accountable.

When to use it:

• Programme leadership structure where sponsor and programme lead are different people

• Situations where senior leaders need to support without micromanaging

• Organisations that value coaching and development alongside delivery

When NOT to use it:

• Corporate IT environments unfamiliar with the framework (requires explanation)

• Decision-heavy governance where RAPID’s explicit Decider is more useful

• Organisations that equate “Manager” with “Boss”

Why it may not be the best choice for transformations: MOCHA is excellent for clarifying leadership dynamics – who owns versus who supports. But it is less known in corporate IT and consulting circles. Introducing MOCHA requires education that DACI does not. For pure governance clarity, DACI achieves the same Driver/Approver separation with less friction.

One-line summary: MOCHA clarifies who owns and who supports, valuable for leadership, but less known in enterprise transformation.

The Framework Comparison: Which One Fits Transformations?

Key observations:

1. RACI and RASCI leave the Driver role undefined. They assume the Accountable person drives. In multi-partner programmes, this assumption fails.

2. DACI explicitly names the Driver. This is the core fix for transformation execution.

3. RAPID explicitly names the Decider and separates Input from Agree. This is the fix for decision governance.

4. MOCHA has an Owner role similar to DACI’s Driver, but is less known in enterprise contexts and requires more education to adopt.

Why DACI Wins for Transformation Execution

For day-to-day programme execution across workstreams, deliverables, cross-functional coordination, DACI is the right governance framework.

Here is why:

1. It names the Driver explicitly.

No more assuming the Accountable person will drive. The Driver role is defined, assigned, and accountable for progress. They coordinate, chase, escalate, and unblock. They do not do all the work but they make sure it happens.

2. It separates driving from approving.

The Driver keeps things moving. The Approver makes the call. These are often different people with different availability and authority. Making that explicit prevents confusion.

3. It is simple enough to adopt.

Four roles. Clear definitions. No extensive training required. Teams can start using DACI in days, not weeks.

4. It works for multi-partner delivery.

When you have vendors, clients, and third parties sharing responsibilities, DACI forces clarity on who is driving coordination, not just who is doing their piece.

DACI in Practice: The Multi-Vendor Success

A financial services organisation used DACI for a multi-vendor ERP- and data-enabled transformation programme. They explicitly assigned the lead system integrator as the Driver for the integrated cutover plan.

This meant the SI had to coordinate the ERP vendor, security vendor, the data vendor, and the client infrastructure team (all Contributors). They could not say “the data vendor is late” and shrug. As the Driver, it was their contractual obligation to chase the data vendor and escalate to the Client Approver only if blocked.

The result: no integration gap. No finger-pointing between vendors. One party was clearly responsible for making sure all the pieces came together. Not because they did all the work but because they drove it.

When to Add RAPID: Steering Committee and Design Authority Decisions

DACI handles execution. But some decisions are bigger. They involve multiple senior stakeholders, competing interests, and political complexity.

For Steering Committee and Design Authority decisions: major scope changes, design trade-offs, localisations, go/no-go gates – consider RAPID.

The power of RAPID is the explicit Decider. One person. Not a committee. Not consensus.

RAPID in Practice: Clearing the Backlog

Remember the ERP programme that burned five million dollars waiting for regional alignment?

They reset using RAPID.

Regional VPs were moved from “Consulted” (which they interpreted as veto power) to “Input” (perspectives welcomed, no veto).

A Global Process Owner was given the Decide role.

The System Integrator was assigned Recommend.

The backlog of 2,000+ change requests was cleared in six weeks. Not because the regions stopped caring. Because the right to veto was explicitly removed. The Decider could hear input and make the call.

This is what good governance does. It does not eliminate disagreement. It ensures disagreement does not paralyse progress.

When Governance Blurs: The ASX Lesson

The Australian Securities Exchange attempted to replace its CHESS clearing system with a blockchain solution. The project failed after years of delay and massive cost overruns.

Post-mortems revealed a governance structure where ASX tried to act as both the Platform Owner and the Systems Integrator despite lacking internal software depth.

The lines between “Client” and “Vendor” blurred. There was no clear architecture veto to stop scope creep. The codebase inflated from 300,000 to 1.3 million lines.

In RAPID terms: there was no Agree function to say “this is not technically feasible.” The desire for features (Input) was never separated from the feasibility of execution (Perform/Decide).

The lesson: governance frameworks must match reality. If you do not have the capability to act as the integrator, do not govern as if you do. And if decisions require technical feasibility checks, make that an explicit Agree gate, not an assumption.

A quick clarification on frameworks

Governance frameworks are not mutually exclusive. They operate at different layers.

• DACI governs execution and coordination.

• RAPID governs decision authority.

• Agile roles govern team delivery.

The Recommendation: What to Implement

If you are a transformation leader deciding on governance, here is the practical guidance:

Replace RACI with DACI for programme execution.

For every major workstream and deliverable, name:

• A Driver who ensures work moves forward

• An Approver who makes the final call

• Contributors who do the work and provide input

• Informed parties who need visibility

Use RAPID for steering committee and cross-functional design decisions.

For major programme decisions (scope changes, design trade-offs, go/no-go gates), name:

• A Recommender who develops the proposal (typically your lead implementation partner)

• A Decider who makes the call (one person, not a committee)

• Input providers who inform but do not veto

• Agree roles only where genuine veto is required (legal, compliance, technical feasibility)

Why not RASCI? It adds Support but still lacks a Driver. The core governance gap remains.

Why not MOCHA? It has an Owner role that functions like a Driver, but is less known in enterprise contexts. DACI achieves the same outcome with less friction.

The Mindset Shift

• RACI asks: “Who is accountable if this fails?”

• DACI asks: “Who is driving this to success?”

That is not wordplay. It is a fundamentally different positioning, from blame assignment to progress ownership.

Questions to Ask (Without Getting Yourself Burned)

If you suspect your programme has a governance gap, here are questions you can raise without sounding like a cynic.

To surface the “Driver” gap:

• “Who is responsible for making sure this moves forward, not just doing the work, but ensuring decisions get made?”

• “If this stalls waiting for input, who chases it?”

• “I want to make sure I understand who is driving this workstream. Can we name that person explicitly?”

To surface the “Decision” gap:

• “Who will make the call if we disagree?”

• “Is the Accountable person also the decision-maker or do they need to consult others first?”

• “For this decision, who has the authority to say yes?”

To propose a fix without confrontation:

• “It might help to name a Driver for this workstream, someone who keeps it moving day-to-day, separate from the Approver.”

• “Can we clarify who the single Decider is for this? I want to make sure we do not end up in circular alignment.”

These questions position you as diligent, not difficult. You are trying to make the programme succeed and you need clarity to do your job.

A Note on Agile Programmes

If your transformation uses SAFe or another agile framework, you may find RACI causes friction at the team level.

This is expected.

RACI focuses on individual accountability: “I did my job.”

Agile focuses on team accountability: “We delivered the value.”

Successful agile transformations often abandon RACI at the squad level entirely.

Teams rely on Scrum roles (Product Owner, Scrum Master, Team) for day-to-day work.

They retain RAPID only for portfolio-level decisions that span multiple teams or trains, the decisions that still require explicit authority.

The principle holds: use the governance framework that matches the work. DACI for cross-cutting coordination. RAPID for strategic decisions. Agile roles for team-level delivery.

The Governance Diagnostic

Signs your programme has a “Driver” gap:

• Work stalls waiting for someone to chase decisions

• Responsible parties say “we cannot move without client input”

• Accountable parties say “I am waiting for the vendor to deliver”

• No one is explicitly named to coordinate across parties

Signs your programme has a “Decision” gap:

• Everything escalates to Steering Committee (and sometime beyond)

• Decisions get revisited after they are made

• Multiple people believe they have veto power

• “Consulted” is interpreted as “Consent Required”

The fix:

• Replace RACI with DACI for deliverables and workstreams

• Optionally, use RAPID for major cross-functional and execution decisions

• Name a single Driver and a single Decider for everything that matters

• Make sure the Driver has the mandate and the bandwidth to actually drive

The Bottom Line

RACI tells you who does the work. It does not tell you who drives it.

In multi-partner transformation programmes, that gap is fatal.

Work stalls.

Decisions bounce.

Accountability becomes blame.

Five governance frameworks exist. For transformation execution, DACI wins: it explicitly names the Driver and the Approver. For steering committee decisions, add RAPID: it explicitly names the Decider and separates input from veto.

The next time someone pulls up a RACI chart and asks “who is Accountable?”, try a different question:

• “Who is driving all of this?”

If the answer is not immediate and clear, you have found your governance gap.

A simple rule for sponsors and programme leaders:

If progress depends on goodwill, informal escalation, or heroic individuals, your governance is already broken.

While retrospectives tell us what went wrong after the fact, pre-mortems offer a chance to see those same risks before they become reality. It’s a simple, powerful shift in mindset: instead of assuming success and reacting to failure, assume failure and plan to prevent it.

Pre-Mortems: A Strategic Reframing of Risk

A pre-mortem is not about being cynical. It’s about being clear-eyed.

This technique, popularised by psychologist Gary Klein, helps teams imagine that a project or programme has failed, and then articulate all the possible reasons why. Unlike traditional risk registers — which often surface only the obvious or already-known threats — a pre-mortem encourages a more creative and candid examination of vulnerabilities.

In the context of large, cross-functional change, pre-mortems allow leadership teams to:

• Pressure-test assumptions that underpin business cases and roadmaps.

• Identify cultural, political, or behavioural blockers that formal planning often ignores.

• Expose interdependencies across teams or initiatives that may not be obvious at the outset.

• Build a shared understanding of what failure actually looks like — and how to avoid it.

Rather than relying solely on bottom-up risk escalation, a pre-mortem gives the executive team direct visibility into the dynamics that may threaten delivery. It facilitates proactive decision-making rather than reactive damage control.

Anatomy of a Pre-Mortem: From Assumption to Action

To conduct a high-impact pre-mortem, it’s essential to go beyond surface-level exercises. The process must be structured, inclusive, and psychologically safe — especially when challenging sacred cows or exposing potential leadership missteps.

Here’s how it typically works:

1. Clarify the Objective: Define what success looks like. What is the intended outcome of the programme? What metrics or milestones matter most?

2. Assume Failure Has Happened: Fast forward 12–18 months. The programme has failed to deliver. Imagine the headlines, the boardroom discussions, the loss of confidence.

3. Identify the Causes: Participants — ideally a cross-section of business, IT, delivery, and operations — list every reason this failure occurred. Nothing is off limits: unrealistic timeframes, underpowered governance, missed change impact, lack of user buy-in, weak sponsorship.

4. Cluster the Insights: Group the risks into themes — technical, organisational, behavioural, political — and assess their severity and likelihood.

5. Turn Risks into Action: Identify countermeasures for the most critical risks. This might include governance changes, sequencing adjustments, redefined KPIs, or a reframed narrative to support alignment.

The key is to embed this process before execution begins — and revisit it at key decision gates as the programme progresses.

Executive-Level Benefits

Senior leaders are the primary custodians of business outcomes. Yet they’re often the furthest removed from daily delivery challenges. Pre-mortems bridge that gap by giving executives direct, unfiltered insight into what may go wrong — and what can be done about it now.

Some of the core benefits include:

• Strategic clarity: Gain confidence that major assumptions and dependencies have been pressure-tested before sign-off.

• Cultural candour: Signal to the organisation that speaking about risk isn’t punished — it’s valued.

• Alignment: Ensure sponsors, delivery teams, and supporting functions are clear on their role in both success and failure prevention.

• Governance resilience: Design oversight that goes beyond reporting — capable of course-correcting when needed.

By investing time in a pre-mortem, leadership teams don’t just prevent failure. They build stronger muscles for delivery, agility, and cross-functional trust.

Making Pre-Mortems Part of the Governance Rhythm

The real power of pre-mortems lies in consistency. While a single workshop can generate valuable insights, embedding pre-mortem thinking into programme governance creates ongoing resilience.

For instance, some organisations:

• Schedule pre-mortem checkpoints before each major investment gate.

• Use “What would make this fail?” as a standing agenda item in executive steering groups.

• Conduct mini pre-mortems for specific workstreams or vendor engagements.

In this way, the pre-mortem evolves from a one-time event to a cultural mindset — one that embraces critical thinking, surfaces dissent productively, and encourages leaders to challenge their own blind spots.

Conclusion: Preparing for Failure to Deliver Success

It’s tempting to believe that a well-documented plan and a high-level sponsor are enough to guarantee transformation success. But the reality is that even well-intentioned programmes falter when organisations fail to anticipate — and mitigate — the many forces that work against change.

A pre-mortem isn’t about slowing down delivery. It’s about making delivery smarter.

By assuming failure and designing from that place, organisations give themselves the best chance to succeed. They protect their investments, their credibility, and most importantly — their outcomes.

Leave a comment

So how do you architect a transformation journey that protects the balance sheet and still delivers operational lift?

Why Strategy Without Structure Fails

Many transformation programmes start with strategy documents full of ambition, buzzwords, and bullet points. But beneath the vision, they lack:

• A sequenced plan that accounts for capability gaps

• Defined investment phases with clear commercial logic

• A benefits model that is measurable, realistic, and cash-aware

Without these elements, organisations either try to do too much at once or follow vendor-led timelines that prioritise technology over business value.

The result? Programmes run hot, cash burns fast, and board confidence erodes before any value lands.

Anchor the Roadmap in Business Reality

A robust roadmap starts not with what’s technically possible, but what’s commercially necessary. That means:

• Mapping the target operating model (TOM) across people, process, data, and tech

• Identifying which changes will unlock measurable EBITDA impact fastest

• Sequencing initiatives to fund later phases through early wins

This isn’t about “boiling the ocean.” It’s about picking the right depth and timing for each investment — focusing capital where impact is real, measurable, and visible to the board.

Bridge the Gap Between Strategy and Execution

The missing link in most plans is execution logic. Great strategy should naturally feed into delivery — but too often, the handoff breaks:

• Vendors propose “Day 1” architectures with no path to get there

• PMOs struggle to translate vision into achievable workstreams

• Sponsors can’t defend the investment case under scrutiny

To avoid these traps, roadmaps must be built backward from desired outcomes, not forward from technology constraints. They should:

• Translate high-level goals into concrete transformation tracks

• Show where investments compound (versus compete) for value

• Include decision gates for reallocation if assumptions shift

When the board sees this level of rigour, they’re far more likely to release funding and stay committed.

Build a Benefits Track, Not Just a Budget

It’s easy to focus on the cost line — but if the benefits case isn’t built in, it’s just another spend programme. A transformation roadmap must have a benefits track that:

• Defines value in business, not technical, terms

• Tracks how each phase contributes to EBITDA or customer outcomes

• Establishes a method for periodic review and scope adjustment

Crucially, the benefits model must be credible, co-owned, and monitored — not buried in a spreadsheet the moment go-live hits.

Protecting Cash While Accelerating Value

Transformation doesn’t have to be a financial cliff. By sequencing phases smartly, and ensuring each builds toward measurable outcomes, organisations can:

• Self-fund later phases through early efficiency or margin wins

• Minimise stranded cost and vendor lock-in

• Retain agility to shift as markets or internal realities change

A good roadmap isn’t about spending less — it’s about spending wisely, and building a transformation journey that sustains executive backing and withstands boardroom pressure.

The Architect’s Role: Independent, Commercial, Pragmatic

Many organisations rely on internal teams or technology partners to build the roadmap. But vendor incentives, internal blind spots, and delivery optimism often skew planning.

An independent architect brings:

• A commercially grounded view of sequencing and scope

• Honest stress-testing of assumptions, timelines, and cost estimates

• The ability to integrate across finance, ops, and tech in one plan

The outcome is a roadmap that isn’t just technically sound, but politically resilient and commercially fundable — one that makes transformation a credible enterprise priority, not a siloed IT initiative.

Final Thought

A clear, value-driven roadmap does more than set direction — it builds confidence. Confidence for the CFO to release funds. Confidence for delivery teams to stay focused. And confidence for the board that transformation will land value, not just headlines.

In today’s climate, that kind of clarity isn’t a luxury. It’s a prerequisite for making transformation real.

Leave a comment

Because slideware isn’t strategy. Because transformation isn’t a technology problem — it’s a value realisation challenge.

Read more

• Ask one question: Will this change how we create or capture value, beyond moving the same work onto a new system?

• Sort the programme into one of three realities: 1/ IT modernisation, 2/ real business transformation, or 3/ digital theatre.

• Then use the matching playbook: what success looks like, what to expect from leaders, and what to say in the room without getting yourself burnt.

The Feeling You Cannot Shake

You are three months into a programme everyone calls a “digital transformation”.

The town halls are energetic. The slides talk about reimagining the business. Your calendar is full of workshops with names like “Future State Design” and “Value Stream Mapping”.

But something does not add up.

The conversations are mostly about system configuration, data migration, and cutover planning (the planned switch from old systems to the new one). The benefits case is a spreadsheet of assumptions nobody has validated. Middle managers smile politely in steering committees, then go back to doing things the way they always have.

You are starting to wonder: Is this actually a transformation? Or is it something else dressed up in transformation language?

You are not imagining it. And you are not the only one who sees it.

This guide will help you diagnose what you are really working on, understand why programmes get mislabelled, and, most importantly, figure out how to do good work and protect yourself regardless of which type of programme you are in.

The Upshift Transformation Test

There is one question that cuts through the noise. Ask it about any programme that carries the word “transformation”:

Does this change how we create or capture value, beyond doing the same work on a new system?

If the honest answer is yes, you are in a real transformation.

If the answer is no but the work is still valuable, you are in an IT modernisation.

If the answer is no and the programme is mostly narrative and optics, you are in digital theatre.

Let me break down each one.

IT Modernisation

The programme is:

• Replacing legacy systems

• Moving to cloud

• Standardising processes across the organisation

• Automating manual work

Example: Moving from an unsupported on-premise ERP to a supported cloud platform, with standardised finance processes and stronger controls, but no change to products, pricing, or routes to market.

The business model stays the same. How the company makes money stays the same. The outcomes are lower cost to serve, better reliability, reduced risk from ageing technology, and improved controls. These programmes are necessary and valuable. They keep the company running. But they are not transformation in the value-creation sense.

Real Business Transformation

The programme is:

• Changing how the company creates or captures value

• Entering new markets or channels

• Launching new products, services, or pricing models

• Fundamentally redesigning how work gets done

Example: Shifting from one off product sales to subscription revenue, redesigning service delivery, incentives, and customer success so retention and lifetime value drive the P&L.

Technology enables new ways of selling, serving, pricing, or operating. Customers, suppliers, or partners will experience the difference. The P&L will move in ways that matter to investors. This is genuine transformation.

Digital Theatre

The programme is:

• Called a transformation because it sounds impressive

• Full of town halls, change campaigns, and glossy communications

• Generating dashboards and decks that look sophisticated

Example: Rebranding an implementation programme as a “customer journey transformation”, while measures of success remain go live, training completion, and dashboard activity.

But underneath, the business operates almost exactly the same. The P&L does not move in a visible way. The main change is new software, new vocabulary, and a lot of activity that does not add up to value. Digital theatre often starts from good intent. But it raises expectations that the programme cannot meet.

Quick Diagnostic Checklists

You are likely in IT Modernisation if most of these are true:

1. The main driver is system age, support risk, or vendor sunset

2. Benefits are described as efficiency, standardisation, control, or compliance

3. Success is measured by go-live date, budget, and adoption rates

4. The benefits case mentions FTE savings but not new revenue or margin

5. Business users describe their work the same way as before, just “on the new system”

You are likely in Real Transformation if most of these are true:

1. There is a specific, measurable change in how the company will make or save money

2. The business case links directly to P&L drivers: revenue, margin, working capital, risk

3. Processes, roles, and decision rights will visibly change

4. Customers, suppliers, or partners will notice the difference

5. Senior business leaders own the programme, not just IT

You are likely in Digital Theatre if most of these are true:

1. Slides are full of vision language but vague on specific value changes

2. People talk about “journeys,” “ecosystems,” and “capabilities” but cannot draw a clear before-and-after for any process

3. Success means “go-live” rather than business impact at month 12, 24, or 36

4. Only a small share of the budget is allocated to changing how people work (process, roles, incentives, training, adoption), compared with technology delivery

5. Middle managers were not involved in design but are expected to “drive adoption”

6. The benefits case looks like an Excel wish list rather than a disciplined model

Why Programmes Get Mislabelled

If you have diagnosed your programme as IT modernisation or digital theatre, you might wonder: why does everyone keep calling it a transformation?

The answer is not stupidity or dishonesty. It is incentives.

“Transformation” gets budget approved.

A request for a $50 million “platform modernisation” faces tough questions. A request for a $50 million “digital transformation” that will “reimagine customer experience” and “future-proof the business” often sails through. The word itself unlocks funding.

“Transformation” accelerates careers.

Leading a transformation is a promotion-worthy achievement. Leading an IT upgrade is just doing your job. Senior leaders have strong incentives to frame their work as transformation, because that is what gets noticed.

External partners reinforce the narrative because it matches how the work was funded and sold.

Changing the label mid-stream creates governance and commercial friction, so most people avoid it. That does not mean the people involved are bad actors. It means the incentives point in one direction, and the easiest path is to keep the original story alive.

Many people see the gap, but few say it plainly in formal forums.

This is not a secret. Senior leaders understand the game. Consultants understand it. Programme team members understand it. The mislabelling is not a mistake – it is a feature of how large organisations work.

Understanding this does not make you cynical. It makes you realistic. And realism is what allows you to navigate well.

What to Expect Once You Know

Once you have diagnosed what you are really in, certain things become predictable. Here is what to expect from different players depending on the type of programme.

If You Are in IT Modernisation

Your boss may still use transformation language in public forums. That is fine – they need to. But in working sessions, the focus will be on delivery milestones, technical stability, and adoption metrics.

Colleagues will be pragmatic. They know this is an upgrade. Conversations will centre on configuration, testing, cutover, and training. Less vision, more execution.

External consultants will focus on implementation methodology and go-live readiness. The transformation narrative in the Statement of Work (SoW) may not match the day-to-day reality of delivery.

Steering committees will track RAG (Red-Amber-Green) status, timeline, and budget. Conversations about business value may be brief or formulaic.

Benefits reviews will focus on cost savings, efficiency metrics, and risk reduction. Expect modest outcomes that are hard to attribute cleanly to the programme.

If You Are in Real Transformation

Your boss will be under genuine pressure to deliver value, not just go-live. Expect hard conversations about outcomes, trade-offs, and business ownership.

Colleagues will include people from the business, not just IT and programme management. Cross-functional tension is normal. It means people care.

External consultants may push for scope that matches the transformation ambition. Watch for scope creep but also recognise that real transformation requires real investment.

Steering committees will ask about value realisation, not just go-live. Expect robust challenge on whether the business is actually changing.

Benefits reviews will be visible and consequential. Business owners will be named. There will be accountability for P&L impact, not just activity metrics.

If You Are in Digital Theatre

Your boss will maintain the transformation narrative in all forums. Challenging it publicly will not go well. The messaging is deliberate.

Colleagues will divide into true believers and quiet sceptics. The sceptics will find each other at coffee machines and in private conversations. You are not alone.

External consultants will validate the vision. Their fees depend on the programme continuing. Do not expect them to name the gap between narrative and reality.

Steering committees will focus on activity metrics, workshops delivered, systems deployed, people trained. Conversations about actual business impact will be brief or deferred.

Benefits reviews will be quietly rescheduled, redefined, or reframed. When they happen, expect explanations about “adoption curves” and “lagging indicators.” The hard numbers may never arrive.

How to Navigate Each Type of Programme

Whatever type of programme you are in, you can do good work, build your skills, and protect your reputation. The approach varies depending on what you are actually working on.

Navigating IT Modernisation

This is honest, valuable work. Your job is to deliver a stable platform that improves reliability, reduces risk, and creates a foundation for future change. Here is how to do it well.

Focus on what is actually measured. Go-live readiness, system stability, user adoption, issue resolution. These are the metrics that matter. Do not overinvest in transformation outcomes that are not in scope.

Be excellent at execution. Clean data migration, solid testing, smooth cutover, effective training. A well-delivered modernisation is career-building work. It demonstrates you can be trusted with complexity.

Manage stakeholder expectations quietly. You cannot contradict the transformation narrative. But you can steer conversations toward realistic outcomes: “After go-live, we will have a stable platform to build on. The real changes to how we work will come in subsequent phases.”

Document your contribution clearly. Keep a record of what you delivered, the quality of your work, and the problems you solved. When the programme ends, you want to be known for solid execution, regardless of what the initiative was called.

Build skills that transfer. Even if this is not transformation, you can develop expertise in system implementation, stakeholder management, cross-functional coordination, and delivery governance. These skills are valuable anywhere.

Navigating Real Transformation

This is rare and valuable experience. Real transformation programmes demand more from everyone but they also offer the most learning and the greatest career impact. Here is how to contribute at your best.

Connect your work to value outcomes. Understand how your workstream contributes to the P&L changes the programme is trying to achieve. If you cannot draw a line from your work to business value, ask until you can. This is how you make your contribution visible.

Build relationships with the business. Real transformation requires genuine partnership with people who own processes, customers, and revenue. Invest time with business stakeholders. Understand their incentives and constraints. This is where transformation succeeds or fails.

Embrace productive discomfort. Transformation is messy. Scope will change. Priorities will shift. Conflict between functions is normal, it means the change is real. Your job is to navigate ambiguity, not to eliminate it.

Challenge constructively. In real transformation, good ideas can come from anywhere. If you see a gap between what is being built and what the business needs, say so, but do it with data, options, and respect. Being the person who asks hard questions well is valuable.

Stay close to change adoption. Technology delivery is necessary but not sufficient. The real work is getting people to work differently. Volunteer for roles that put you close to users, training, and behaviour change. This is where transformation actually happens.

Think beyond go-live. Transformation benefits take months or years to materialise. Position yourself for roles in post-go-live optimisation and continuous improvement. This is where reputations are made.

Document the value story. Keep notes on business outcomes, not just deliverables. When benefits start to land, you want to be able to articulate your contribution. “I helped deliver the platform that enabled a 15% reduction in customer churn” is more powerful than “I was on the technology workstream.”

Navigating Digital Theatre

This is the most politically delicate situation. The gap between narrative and reality is wide. Your job is to do good work, protect yourself, and avoid becoming collateral damage when expectations are not met. Here is how:

Accept what you cannot change. You will not relabel this programme. Your boss needs it to be called a transformation. Fighting that battle is career-limiting and unwinnable. Focus on what you can control.

Do good work within realistic scope. Even if the programme is mislabelled, there is usually real work to be done. System implementation, process improvement, data cleanup – these are valuable. Do them well. Your execution quality is within your control.

Ask clarifying questions diplomatically. You cannot say “this is not a transformation.” But you can ask questions that surface the truth without confrontation:

“Help me understand how this will change how we make money, I want to focus my effort on the right outcomes.”

“What will be different about how we work after go-live? I want to prepare stakeholders.”

“Who owns the benefits after go-live? I want to make sure I am aligned with them now.”

These questions position you as diligent and aligned, not as cynical or obstructive.

Document carefully. Keep your own record of what was in scope, what you delivered, and what assumptions were made about benefits. Not to blame anyone but so you can speak precisely about your contribution when asked. When benefits do not arrive, you want a clear record that you delivered what was funded.

Find the other realists. You are not the only one who sees the gap. Find colleagues who share your perception. You do not need to say it loudly. But working alongside people who see clearly is better for your sanity and your work.

Manage your energy. Stop trying to transform things you were never funded to transform. Do not overinvest emotionally in outcomes that were never realistic. Do good work. Protect your wellbeing. That is enough.

Build transferable experience. Even in theatre, you can develop skills: stakeholder management, navigating ambiguity, delivery under pressure, political awareness. These are valuable. Use this programme to sharpen them, even if the programme itself does not deliver what it promised.

Questions You Can Use

Here are questions you can ask in steering committees, design workshops, or one-on-ones. They surface the truth without putting you at risk.

“How exactly will this change how we make or save money?”

Tests whether the team can connect scope to P&L. In real transformation, this answer is crisp. In theatre, it is vague.

“What would stay the same about how we run the business, even if this programme succeeds?”

Tests whether you are doing an upgrade or a redesign. If almost everything stays the same, it is probably not transformation.

“If we removed all the technology language, how would we describe this change in plain business terms?”

Tests whether this is a technology story or a business story. Transformation should be explainable without mentioning systems.

“Who in the business owns the benefits after go-live, by name?”

Tests whether value accountability exists. In real transformation, business owners are named. In theatre, it is unclear or deferred.

“How much of the budget is for changing how people work, not just implementing technology?”

Tests investment in behaviour change. If less than about 15% of the budget is aimed at changing how people work (process, roles, incentives, training, adoption), it is probably delivery dressed as transformation.

The Coffee Machine Conversation

Sometimes you want to acknowledge reality with a peer without sounding like the bitter cynic. Here is language that works:

“You know, I think what we are doing is important, the platform upgrade is valuable work. I just wonder if calling it a ‘transformation’ sets expectations we cannot meet. But that is probably above my pay grade.”

This names the gap while respecting the reality that you cannot change it. It signals that you see clearly, without positioning you as the problem.

The Quiet Clarity

You probably cannot change what your programme is called. You probably should not try.

But you can stop doubting your own perception. You can adjust your expectations. You can do good work without overinvesting in outcomes that were never realistic.

If you are in a real transformation, you now know what that demands, and what it offers. Engage fully. This is where careers are built.

If you are in IT modernisation, you know what success looks like. Deliver it well. Solid execution is valuable.

If you are in digital theatre, you know the game. Protect yourself. Do good work anyway. Find the others who see it clearly.

And the next time someone asks you about “the transformation,” you will know exactly what you are really working on, even if you never say it out loud.