The AI pilot is back on the executive committee’s agenda. The results look promising, the team has learned a lot, and they’re asking for another quarter to be sure before anything bigger is committed.

I’ve been in an executive committee meeting where an AI pilot in finance made exactly that request. Nobody around the table, me included, wanted to be the one to say stop, so it was noted and we moved on.

I understand why that happens. Another quarter feels like the careful choice. Nobody has to back the pilot at scale or write off what’s been spent, and the meeting gets to the next item on time. But it’s still a spending decision, and nobody actually takes it. The team stays on the pilot, the budget stays committed, the benefits in the business case wait, and whatever those people would otherwise be working on does too.

Here’s how I’d pitch an extension that could change the decision from "no," and what I’d ask for before funding either.

The short version

• Treat another quarter as a new funding request: the cash, the work the same people aren’t doing, and the benefits that arrive later.

• Ask what the next quarter will tell you that this one didn’t, and whether that answer could change your decision.

• Before the review, ask for a one-page case in numbers, including what the improvement is worth versus what it would cost to run.

• The second time a pilot comes back, choose scale, change or stop, with a named decision-maker and a date.

Another quarter is a new investment decision

You don’t need to be told that what’s already been spent shouldn’t decide what happens next. The extension still gets through, because it doesn’t look like a decision. It looks like continuity: same team, same budget, one more quarter.

So I’d price it like any other request for money. Say the pilot costs $200,000 a quarter for the delivery team, licences, and running the model. That excludes the finance people testing it alongside their day jobs.

Approve the first extension and two more after it, and you’ve committed another $600,000. That’s only the cash. The pilot team isn’t working on the next priority, and if go-live moves with each extension, the business case benefits arrive nine months later. Those are three different costs, and only the first appears on the pilot’s budget line.

If the executive committee faces the same question at the third review as it did at the first, that $600,000 bought nine more months of the same question. There may have been useful learning along the way. What matters is whether any of it changed what the committee can decide.

This is about pilots funded to prove a business case. Exploratory work with a capped budget, set up to learn, is a different kind of spend, and we judge it by what it learns.

The question I’d put to any extension is this: “What will the next quarter tell us that this one didn’t, and could that change what we decide?” If nobody can answer it, you already have what you need to decide today.

Why executive committees keep saying yes

Everyone around the table knows this. So why does the extension keep getting approved?

Research published in Harvard Business Review in August helped me name it. Morgan Blangeois and Thomas Roulet spent three years with leadership teams in 11 European IT services firms, through 23 interviews and three workshops in which executive committees debated their own AI strategy. In private, the executives had clear views about what AI required of their firms. In the workshops, they quietly dropped those views. As the authors put it, “Nobody fought AI; nobody decided anything about it either.”

One scenario they gave every team was a multimillion-dollar AI plan with no return yet, and whether to keep paying for it. Individual views shifted, but no team reached a position it could state out loud together, and even with their sector’s productivity figures in front of them, teams asked for more time. The authors call it AI leadership drift.

Their study was of IT services firms, so applying it to other executive committees is my judgement, not their finding. It matches the meeting I described. An extension is the one option that asks nobody to say what they think: scaling means someone backs the pilot in front of their peers, and stopping means someone says the money didn’t work.

Better numbers alone didn’t break the drift. The authors’ answer has two parts: tie every pilot to the bigger decision it’s meant to feed, with a date, and make it one person’s explicit job to keep raising the question everyone else would rather drop.

Before the pilot comes back, I’d ask who in the meeting has that job. If the answer is nobody, the extension is already approved.

The one page I’d want before funding another quarter

If the request arrives as a progress update, with what the team did, what it learned and what it’ll do next, that’s useful to the team. It doesn’t tell the person deciding whether another quarter is worth paying for.

Before the next review, I’d ask the programme director for one-page that answers five questions.

1. What has the pilot proved, against a baseline finance has signed off? Promising results aren’t enough here. I want the measure before the pilot, the measure now, and how you took both.

2. Where did the saved time go? If the pilot saves hours, I want to know what happened to them: a close finished earlier, cost avoided, more work absorbed without hiring, lower risk, or nothing, because the time disappeared into the next queue.

3. What’s the one question still open, and what evidence would settle it by the decision date? If the page lists several, I’d ask which one would change the decision.

4. What does it cost, and what is it worth? Another quarter all in, including the business people testing it; what it would cost to run in production, because a pilot that’s cheap to test can be expensive to run; and what the improvement is worth against that.

5. What’s the recommendation, who decides, and what would change it? Scale, change, or stop, with the decision date.

Each question removes one way to avoid the decision. The baseline stops “promising” standing in for a number, the time question stops counting hours as money, and putting the cost next to the worth makes the extension compete with every other use of the same budget. The fifth makes someone commit to a view, with their name and a date, before the meeting starts.

If the papers that reach you usually arrive as options rather than recommendations, I wrote about what to do when every decision is sent up to you for review.

Here’s the page filled in for a made-up pilot. Say a finance team has spent a quarter testing an AI agent that compares the ledgers of two group companies each night and flags the entries that don’t match, so mismatches surface before the month-end close. The figures are illustrative.

1. What it proved: over three closes, the system flagged mismatches on day two of the close instead of day six, against a baseline the group financial controller signed off before the pilot started.

2. Where the time went: the analysts spend less time finding differences, but the close hasn’t got any shorter. Clearing a mismatch still needs procurement, billing and the other company’s finance team to agree.

3. The open question: if the agent also sends each mismatch straight to the people who have to agree it, does the close get shorter? The evidence: two more closes, with the close date measured against the same baseline.

4. Cost and worth: $150,000 for the quarter, plus two analysts spending about a day a week on it. Running it across 40 companies in the group would cost roughly $400,000 a year. Nobody has yet put a value on a shorter close.

5. The recommendation: change it. Fund one more quarter on the routing question only, and ask the group financial controller to value a shorter close before the January review, where the CFO decides. If the close doesn’t get shorter, or a shorter close isn’t worth $400,000 a year, stop it.

The example separates three things a pilot report can blur: whether the technology works (mismatches found on day two), whether the process improves (the close finishing earlier) and whether the improvement is worth what it costs to run. Only the third tells you whether to fund it.

The second question is the one I’d read first. In the reconciliation work I’ve seen, finding a difference is quick; getting several teams to agree on it, often across business units and time zones, takes time. A pilot can speed up the quick part, look like a success, and leave the close where it was.

That page changes the conversation. Instead of “Do we give it more time?”, the executive committee is deciding whether a shorter close is worth $150,000 and one more quarter, and it already knows what it’ll do if the answer is no.

Three real decisions on the review date

When the pilot comes back with its page, the executive committee has three real decisions. Noting it and moving on isn’t one of them.

I treat a returning pilot the way I treat a risk at a steering committee. Noting a risk the first time is reasonable. The second time it comes back, I want one of three outcomes: mitigate it, explicitly accept it, or change the plan, scope, budget, or date. A pilot coming back a second time gets the same treatment.

If it has a business owner who’ll answer for the results, a baseline finance has signed off, results that hold up outside the pilot, a cost to run that the value covers, and a fallback that’s been tested once without the agent, scale it. Tie each release of money to the measures in the business case moving, and keep measuring after it scales. A steering group in the owner column doesn’t count; I wrote in August about why a committee cannot own a change.

If one specific question is still open, change it. Change means the next round differs from the last: one question, the evidence that would settle it, a capped budget, a decision date, and the name of the person who’ll decide. If the next quarter's plan is the last one with new dates, I’d send it back.

Some evidence does take time. You can only measure an I pilot on a quarterly process at quarter end, and sometimes a dependency won’t be ready, so pausing makes sense. Both are fine as decisions, as long as you agree on the question and date before the review. If they first appear in the meeting, you're putting off a decision.

If the evidence isn’t there any more, stop it. Write down what the pilot taught you, get the sponsor to sign off, and move the people and money in the same meeting so the budget doesn’t drift into the next pilot by default. A pilot that answers its question with a no has still done its job. The point of all three is to get the strong pilots to scale sooner and the weak ones off the budget, so the next idea gets its turn.

Doing nothing has a cost too, and it’s the one the minutes don’t show. If the minutes say the pilot was noted, the executive committee has paid for another quarter without deciding to.

Keep the person who asks apart from the person who decides

None of this needs a new governance process. One page, a date and clear names will do.

For each AI pilot coming back this quarter, write down the decision it’s meant to inform and the date it has to inform it by. Then I’d keep four jobs apart: the programme director brings the recommendation, the business owner answers for the value, the sponsor or the investment committee makes the funding decision, and one person with nothing riding on a yes keeps the question on the agenda until it’s answered.

That person doesn’t need the authority to decide. In the research I mentioned, the role usually fell to people one level below the leadership team, near enough to the work to make the questions specific. On an AI pilot, that might be the AI governance lead or a finance business partner.

A board can ask its own version of this: “Which AI pilots have come back more than once without a decision, and who is answering for each one?”

Before the next review, I’d ask the programme director for that one page, in time to read before the meeting.

If the next quarter can’t change the decision, take the decision now.

Roman

New here? Start with what to do when your business case runs years longer than your programme plan.

Too often, the transformation programme adopts the same horizon. Once the technology is stable, the implementation team leaves, the programme closes, and the business takes over the benefits realisation.

Yet most of the value the board approved has not arrived yet. It is still sitting in years two, three, four and five of the business case. In my experience, a benefit that nobody owns and chases never arrives.

For years, I planned transformation programmes backwards from go-live. And I was good at it. The plans were detailed, the milestones were clear, and design, build, test, data migration and cutover were tightly managed. When dates moved, we replanned and kept going.

Once the technology was stable, the programme could close. My team was usually already preparing for the next implementation, sometimes in another country.

That competence hid something from me for longer than it should have. We were extremely precise about what had to happen before go-live. We were much less specific about what had to happen afterwards for the business case to become real.

I think about that differently now.

If the business case commits the organisation to five years of benefits, I want the transformation programme to have a five-year horizon too.

That does not mean keeping the implementation team together for five years. After go-live, the programme changes shape. The system implementation may finish a few months after go-live. But the transformation programme continues around the outcomes it was funded to deliver. The value owners remain accountable. The benefits remain planned. Dependencies remain visible. Progress against the business case is still governed.

The programme finishes when the transformation has delivered what the organisation approved, or when the remaining business case has been consciously rebaselined.

I still plan backwards. I just start further out.

Start from the final year of the business case

The usual planning question is: what do we need to do to hit go-live?

That question still matters though. But I now ask another one first: what has to be true by the final year of the business case?

Suppose the board has approved a five-year transformation case. Start in year five.

• What value should have been realised by then?

• Which business measures should have moved, which costs should have come out, and which processes, risks, revenues or productivity should look different?

Then work backwards.

• what has to be true in year four for year five to happen?

• what must be in place in year three?

• what has to change in the business during year two?

• what needs to be enabled at go-live?

• and what, therefore, has to be designed, built, tested, and prepared during implementation?

That creates a different planning logic. Instead of starting with implementation and eventually handing over the benefits, you start with the business case, work through the benefits and business changes required to deliver it, identify the capabilities needed, and then determine what the technology implementation must enable.

The technology plan still matters. It just sits inside a larger transformation plan.

Make the transformation programme as long as the business case

This is the first thing I would change on many programmes.

Put the business case and the transformation programme plan side by side and look at the final date on each. If the business case runs to 2031 and the transformation programme disappears in 2028, ask who is managing the difference.

A five-year transformation programme does not need the same level of activity every year. The first two years may contain thousands of implementation activities and tens (sometimes, hundreds) of people. Years three to five may include far fewer actions around benefit milestones, process adoption, further releases, operating model changes, and the measures in the business case. The programme’s purpose does not change: it still exists to turn the approved investment into the outcomes that justified it in the first place.

I now see system implementation as one phase of the transformation.

Build the benefits realisation plan during mobilisation

At mobilisation, the pressure is usually elsewhere. Get the team in place. Confirm scope. Mobilise the workstreams. Start design. Protect the date.

The benefits are there, but often as headline numbers in the business case: £20M cost reduction, a five-day month-end close, lower working capital, 30% faster onboarding. Those are useful commitments, but they are not yet plans.

One of the first things I now want to see is a benefits realisation plan that takes every material benefit and phases it across the years in which the business case expects it to arrive.

Take a simple example: faster month-end close.

The business case may promise a five-day close. The benefits realisation plan needs to show the route to it. For example, the close takes 12 working days today. In year one it falls to 8 days after intercompany reconciliation moves into the new solution. In year two, it falls to 6 days once regional finance teams stop making specific adjustments outside the system. In year three, it reaches 5 days after the remaining process and data changes are embedded.

Now the benefit can be managed.

The first improvement may depend heavily on the system. Later improvements may depend much more on process discipline, operating model changes, data quality, or behaviour inside the business.

Those activities still need dates and owners. Otherwise, the business case quietly assumes the value will arrive at go-live, without anyone managing what has to produce it.

Capture the baseline while you still can

This is one of the easiest things to postpone and one of the hardest things to reconstruct later.

You need to know where you started.

I have seen programmes reach go-live with a clear description of the new capability but a weak answer to a much more basic question: what was the number before we changed it?

Sometimes the old reports have disappeared. Definitions have changed. The legacy system has been retired. People who understood the previous process have moved on.

Then the transformation is trying to prove improvement against a baseline nobody properly captured.

Record it early. For every material benefit, agree on what the current measure is, where the number comes from, what exactly it means and how the same outcome will be measured after go-live.

The system may change. The definition of success cannot quietly change with it.

For each benefit, I want three things to be clear: where we are today, where we should be each year, and what has to change to move between the two.

If those answers are missing, the benefit is still largely a promise.

Give every benefit a value owner

Most business cases contain an owner column. That does not necessarily mean the benefit is owned.

“Finance”, “Operations”, “Business” or “Transformation Board” are organisational labels. What I want to see is a named business leader accountable for each material benefit: one person who will still care about the number after the implementation team has gone.

And I want that person involved early.

If a value owner appears at handover, they inherit a solution whose important design decisions have already been made. If they are accountable for delivering £10M of value three years later, they should have a voice while the programme decides what capabilities, data, and process changes will make that £10M possible.

Then they need a plan, not just an annual target: the activities, dates, dependencies and decisions required to realise the benefit, planned with the same seriousness we apply to implementation.

An owner with a target can explain afterwards why the benefit did not arrive. An owner with a plan can see it going off track while there is still time to intervene.

If the owner column on your programme contains a committee rather than a person, I wrote previously about what happens when a committee is named as the owner of a change.

Connect the benefits plan to the implementation plan

This is where benefits management often becomes detached from delivery.

The implementation team has its plan. The benefits team has its register. They meet around go-live. They should be connected from the beginning.

Suppose the programme needs to remove scope to protect the go-live date. The usual discussion asks what can move, what creates the least delivery risk and what can be deferred into a later release.

The benefits plan adds another question: what value moves with it?

Perhaps removing one capability delays £4M of benefit by a year. Another item may have little effect on the business case. Perhaps protecting the go-live date is still the right decision.

The difference is that the sponsor now sees the value consequence alongside the delivery consequence.

The same applies to design decisions. A simplification may reduce implementation risk but constrain a later benefit. Poor data quality may delay automation benefits. A deferred integration may change the year in which working capital improvement begins. A process decision may make a business-case assumption impossible.

When the two plans are connected, those consequences become visible before the decision is made.

That is why I no longer think benefits realisation begins after implementation. The implementation is already making decisions about which benefits will be possible later.

Go-live remains an important anchor

Planning backwards from the benefits does not make go-live less important. A large proportion of the benefits cannot begin until the new capability is in use, so I still treat go-live as a major planning anchor. What changes is where it sits.

It is no longer the right-hand edge of the transformation plan. It sits somewhere in the middle.

Before go-live, implementation dominates the programme. After go-live, the balance shifts toward adoption, business change, and value realisation.

The first activities after go-live should already exist in the value owners’ plans. What changes on the first Monday? Which old process stops? Which new behaviour starts? Which measure should begin moving? Who checks whether it has? What happens if it does not?

I wrote earlier this month about how to capture what should run differently from day one on a single page.

Hypercare can still end. The implementation team can still leave. The transformation programme continues.

The programme should change shape after implementation

This is where I expect some people to disagree.

Why keep a programme open for five years when most of the delivery work is finished? Because keeping the transformation programme alive does not mean keeping the implementation machinery alive. The team should get smaller. Meetings should become fewer. Some forums should disappear. Some responsibilities should move into normal business governance.

But there should still be a coherent transformation plan, clear ownership and an executive view of whether the investment is producing what was promised. Otherwise we create a strange asymmetry.

The organisation governs the spending intensively while the money is going out, then reduces the governance just as the promised value is supposed to start coming back.

What if the benefits are handed to BAU?

They can be.

But “BAU owns the benefits” is not, by itself, a governance model.

The more important question is what still connects those benefits to the transformation and its approved business case.

• Who can see that benefit A is slipping because business change B never happened?

• Who challenges a value owner whose measure has not moved?

• Who decides whether to rebaseline a benefit?

• Who tells the sponsor that the original business case is no longer achievable?

• Who compares actual value with the investment decision the board made several years earlier?

Those questions may eventually be handled by a transformation office, portfolio governance, finance or another permanent business forum. That can work, provided the transition is deliberate, and the transformation does not disappear simply because the technology implementation is complete.

For me, that continuing horizon still belongs in the transformation programme plan, even when the mechanism that runs it becomes lighter and moves into permanent governance.

If your programme already ends with the implementation

You do not need to rebuild the implementation plan. Leave it alone. It is probably doing exactly what it was designed to do.

Add the part that is missing.

Take the business case and work through each material benefit. Establish the baseline. Phase the benefit across the remaining years. Name one value owner. Ask what has to happen each year for the value to arrive. Identify what that plan depends on. Then connect those dependencies back to current programme decisions and extend the transformation programme plan to the end of the business case.

You may find uncomfortable things: a benefit nobody wants to own, a number nobody knows how to measure, a target with no credible route behind it, a saving dependent on functionality that has already left scope, a year-three benefit dependent on a business change nobody has planned, or an owner who had no idea their name was in the business case.

They are the reason to do it now, while the programme can still change something.

Start with one benefit

You do not need to redesign your entire programme tomorrow.

Take one significant benefit from the approved business case and ask:

• what is the baseline?

• what should this benefit deliver in each year of the business case?

• who owns it?

• what has to happen for each step to occur?

• which current programme decisions affect it?

• where does it sit in the transformation plan after go-live?

If you cannot answer those questions, you are not managing the benefit with the same discipline as the implementation.

Do it properly for one benefit, then put its timeline next to your current programme plan.

The gap becomes very obvious.

For years, I planned transformations backwards from go-live.

I still plan backwards. I just start further out.

I start at the final year of the business case and work back through the benefits, the business changes, the capabilities and the system implementation until I reach mobilisation.

If the business case runs for five years, I want the transformation programme to span those five years too.

Go-live is an important milestone in that plan. It is not the end of it.

Roman

Architecture has sent three design options “for review”. Finance wants your view on two ways to shorten the month-end close timeline. The data team wants approval for an exception they believe is necessary. A workstream lead wants you to settle a sequencing decision with another team.

All four are waiting.

And in every case, the people sending the paper understand the subject better than you do. You could spend your evening reading every page and still know less about the detail than the person who wrote it.

Yet somehow the programme is waiting for your name.

That is the part worth paying attention to. Because sometimes the programme genuinely needs your decision. And sometimes it has simply learned not to move without you.

What “for review” can hide

Ask the person who sent you the paper what they recommend. Quite often, the answer comes immediately.

“I would choose option two.” Then ask why. Usually they can explain that too. They know the trade-off. They understand the risk. They know what they would do.

The analysis was never the missing piece. What was missing was permission to own the decision.

There are good reasons for decisions to come upward. A choice may change the programme date. It may require more funding. It may create risk for another workstream, commit the organisation externally or cross a risk threshold that belongs with the programme leadership.

Those decisions should come to you.

The problem is when everything does.

When every recommendation turns into a request for approval, your calendar becomes part of the critical path.

One question that sorts the pile

When something arrives for review, ask: “What happens if I do nothing for a week?”

There are usually three answers.

1. Nothing happens

The work continues. You were copied because somebody wants you informed. That is fine. It is information, not a decision. Treat it that way.

2. The work genuinely stops

There is a trade-off nobody below you has the authority to make. Perhaps the decision changes cost, scope or timing. Perhaps two workstreams need the same scarce resource. Perhaps it changes the business case, crosses a risk threshold or creates an external commitment.

That decision belongs with you. Make it quickly. The programme is paying for every day it waits.

3. The work could continue, but nobody will move

This is the interesting category. Nothing material prevents the person from deciding. They have the expertise. They have a recommendation. They are still waiting for somebody more senior to put their name against it.

If this category is large, you do not have a review problem.

You have a decision-rights problem.

Programmes teach people where decisions belong

This behaviour rarely appears from nowhere. A programme teaches people what is safe. If somebody makes a reasonable call and gets overruled in front of their peers, everybody watching learns something.

If nobody says what a workstream lead, architect, or functional owner is allowed to decide, they learn something else.

If a mistake follows somebody around for six months, while escalating everything carries no cost at all, the rational response is obvious. Send the next decision upwards.

And programme leaders can create this behaviour without meaning to. Reopen enough decisions that were properly made below you, and people stop making the next one.

Ask for “one more review” often enough and eventually every decision arrives with a request for yours. The team slows down while you get busier.

It shows up in the governance too, which is why steering committees fail 48 hours before they meet.

The aim is not delegation

I do not think the answer is simply “delegate more”. Some decisions should stay at programme level. The question is whether they are there by design. A useful rule is to keep decisions at the lowest level that has both the context and the authority to make them.

I would be clear about three things.

1. You own a decision when it is inside the agreed guardrails for your area and does not create material consequences elsewhere.

2. Bring me a recommendation when it affects another workstream, changes an important assumption or approaches an agreed risk realisation point.

3. I will decide when a decision changes the programme’s funding, scope, major milestones, risk profile, benefits case or an external commitment.

The exact boundaries will differ for every programme. What matters is that people know where they are.

Then change the way work comes upward. Instead of:

Here are three options. Please advise.

Ask for:

Here is my recommendation. Here is why. Here is the risk I am accepting. Here is what changes elsewhere if we proceed. Here is when I need a decision.

That is a very different conversation. You are no longer being asked to become the architect, finance lead or security specialist for an evening. You are being asked to exercise the judgement that belongs at your level.

Where that judgement actually gets exercised is often the meeting before the meeting.

The first mistake matters more than the rule

You can publish the clearest decision-rights matrix in the world. The real test comes when somebody uses it and gets a decision wrong. That will happen.

The question is what you do next. If the response is to take the authority back, require more approvals and make the person explain themselves repeatedly, everybody has learned that the old system still applies.

The safer choice is still to escalate. Correct the decision. Understand what was missed. Change the guardrail if necessary.

But if the person made a reasonable decision within the authority you gave them, do not remove that authority simply because the outcome was imperfect. That moment will shape behaviour more than the slide where you explained the governance model.

AI is making this problem more visible nowadays

None of this started with AI. A programme in 2011 could bury its director in options, design papers and requests for review just as effectively as one today.

What has changed is the supply of analysis. AI can produce alternatives, comparisons, draft impact assessments and recommendations in minutes. A team that once brought you three options after several days of writing those up may soon bring you twelve to evaluate before lunch.

But AI has not added another five hours to your day. And it has not answered the organisational question: “Who is actually allowed to decide?”

That may become one of the less discussed constraints on AI productivity in transformation. If analysis becomes dramatically faster while decision authority remains concentrated, you do not remove the bottleneck. You feed it faster.

And as agents move from producing recommendations to taking action, the question becomes even more important. What may the agent decide? What must stop at a human? Which human? What happens when confidence is low? Who owns the exception?

Those are not only technology questions. They are programme governance questions.

One thing to try this week

For five working days, make a simple note of everything that arrives asking for your review or approval.

Put each item into one of three categories:

1. Information

The work could continue without you.

2. Genuine escalation

The decision crosses a boundary that belongs at your level.

3. Avoidable escalation

The person has the expertise and authority, but the programme has taught them to wait.

Do not worry about creating a perfect framework. Just count them. If the third category is larger than you expected, choose one recurring type of decision and reset the boundary.

Tell the people involved what they can decide. Tell them when you want to be consulted. Tell them what must still come to you. Then watch what happens the first time somebody uses that authority and gets something wrong. That is when the programme will find out whether you really meant it.

A programme where every choice reaches one person cannot scale beyond that person’s calendar.

And with AI increasing the speed at which choices can be produced, that limit is only going to become more visible.

— Roman

The PMO walked you through the programme plan. The workstream leads took you through their most burning risks. The sponsor told you the outcome they expect from the programme. The systems integrator reminded you what the contract says. Finance showed you the business case, and how the investment decision was made.

Every one of them described the same programme.

And none of the descriptions quite agreed.

Resist the urge of solving this problem in your first week. It may be the most useful thing you have learned.

Everyone will tell you the first 30 days are about learning the programme. And they are.

But there is another job happening at the same time.

People are working out which decisions you will make yourself. Whether you want bad news early or only once there is an answer. Whether you will take a position when the room gets uncomfortable. Whether every problem now needs to come through you.

Nobody gives you a briefing on that.

If I were taking over a programme tomorrow, these are the seven things I would want to understand before changing too much.

1. Work out what you have actually inherited

The status pack tells you what you inherited on paper.

The briefings tell you what you inherited according to the person taking you through the briefing.

Your first job is to notice any gaps between those versions.

The plan might say the integration build finishes in March. The architect tells you some interfaces are still not fully designed. The sponsor cares about holding the go-live date. Finance cares about the year-two benefits that depend on it. The contract has a milestone payment attached to the build.

None of those statements is necessarily incorrect.

Put them next to one another, though, and you start seeing the assumptions the programme is running on.

The temptation is to reconcile everything immediately and create one clean version of the truth.

I would resist that.

For the first couple of weeks, write down the disagreements instead.

• Where does the plan say one thing and the people doing the work say another?

• Where does the contract assume something that the delivery team does not?

• Which benefit depends on an operating change nobody owns?

Those disagreements are often more useful than the status itself.

They tell you where to look next.

2. Find out what the sponsor expects you to decide

This is one of the boundaries worth establishing early because discovering it by accident can be expensive.

Some sponsors want a programme director who brings recommendations, exercises judgement and makes the decisions that come with the role.

Others want to remain close to a much wider set of calls.

Either model can work. And you need to find out, which model your sponsor is applying.

What does not work particularly well is finding out which model you are in during your first steering committee.

So take the significant decisions you can foresee coming over the next quarter and put them into three groups:

→ decisions I own
→ decisions where I put forward a recommendation
→ decisions the sponsor owns

Then put the list in front of the sponsor.

I would much rather discover in week two that the sponsor expects to make a decision I thought was mine than discover it after I have already made it.

And the reverse is equally useful.

If you keep taking decisions upwards that the sponsor expected you to make, you may think you are keeping them close to the programme. On the contrary, they may be wondering why they appointed a programme director.

This is less about creating another RACI and more about learning where your judgement is expected.

3. Find where the programme is running on heroes

Listen carefully when somebody says:

“We couldn’t do without her.”

It may simply be well-deserved praise.

But I would also treat it as a reason to look closer.

Maybe it is the architect who knows every integration. Or the project manager holding five workstreams together. Or the business lead who resolves problems through a few phone calls before they ever reach the formal governance.

Sometimes the person is exceptional.

Sometimes the programme has quietly built part of its operating model around that person being exceptional.

The integrations sit in one person’s head because the design was never properly documented.

Five workstreams stay aligned because one project manager spends their week absorbing the gaps between them.

Issues get resolved informally because the formal escalation route takes too long.

There is nothing wrong with having exceptional people.

The risk is not knowing what would stop working if one of them disappeared for four weeks.

Your first few weeks may be the easiest time to see these dependencies because you have not yet accepted them as simply “how this programme works”.

Once you have, they become much harder to notice.

4. Listen for what people are reluctant to tell you

The formal risk register rarely coverthe whole programme.

Some of the useful information arrives after the meeting. Or in the last two minutes of a call.

It often starts with something like:

“Between us...”

“This isn’t in the pack yet...”

“I probably shouldn’t say this, but...”

That moment matters.

The person speaking is not only giving you information. They are learning something about you.

Can I bring this person a problem before I have solved it?

Will they listen?

Will they immediately escalate it?

Will they make me regret having said it?

Before reacting, I would do three things: thank them for raising it, ask what they have actually seen, and go and look.

The important thing is what happens next.

If your first response to uncomfortable information is to solve it for them, forward it to somebody else or visibly react before you understand it, people notice.

And the next concern may arrive later.

The person telling you the problem will remember that conversation far longer than you probably will. On a programme, that matters.

Your reaction to the first piece of bad news teaches the programme how to bring you the second one.

The next warning about the supplier, the data or the business readiness reaches you early only if the person carrying it expects something useful to happen when they speak.

5. Do not confuse being useful with solving everything yourself

You probably got this job partly because you are good at fixing things.

Your first month will present you with plenty of opportunities to prove it.

A cutover plan that does not add up. A contract clause interpreted differently by the client and supplier. A migration approach nobody can explain clearly. A decision that has been circling the programme for three weeks.

Of course, a programme director sometimes has to go into the detail.

The question I would ask is different:

Am I getting involved because this needs my judgement, or because solving it myself feels easier than getting somebody else to own it?

I have done this myself.

In 2017 I was programme director on a large ERP-enabled transformation for a global bank. I kept turning up to the design authority meetings where the detailed solution decisions were being made.

A solution architect should have owned that place.

I should have been hearing about the design decisions that materially changed the programme’s cost, date, risk or outcome.

But I stayed. The design was where I felt useful. It was also where I was least needed.

It does not mean programme directors should stay away from detail. Sometimes the detail is exactly where you need to be.

The problem starts when detail becomes the place you automatically go to whenever something is difficult.

Do it often enough and the programme learns very quickly that difficult problems belong to you.

Workstream leads bring them upwards instead of resolving them.

Meetings wait for you.

Decisions queue behind your diary.

And eventually the programme director becomes one of the programme’s dependencies.

6. Work out which meetings actually run the programme

The governance tells you where the programme is supposed to be run.

It does not necessarily tell you where it is actually run.

The real decisions may happen in the sponsor’s Tuesday call, the Thursday finance review and coffee conversations before the steering committee.

Your job initially is not to tidy that up. It is to understand it.

After an important decision, ask yourself where it was really made.

• Who was in the room when the position formed?

• Who influenced it?

• Who only heard about it after the meeting?

• Where are decisions actually debated and where are they merely ratified?

This matters because a meeting can look redundant on a governance and still be the one place where the sponsor thinks out loud.

If you remove it just because the governance looks untidy and you may accidentally remove one of the programme’s most useful conversations.

So I would be cautious about redesigning governance in the first month.

First understand the formal governance. Then understand the informal governance underneath it. Only then decide what is duplication and what is doing work the organisation has never written down.

As the new programme director, one of your first jobs is finding out which meeting that is.

7. By day 30, have a point of view

I would not expect a programme director to have fixed a complex programme in 30 days.

I would expect them to know what they think.

After a month, you should be able to explain the programme in plain language and in under five minutes:

→ This is what I believe the programme is really trying to achieve.
→ These are the two or three things will most likely stop us.
→ This is what I think we should change.
→ This is what I would deliberately leave alone.

That is not the same as completing a diagnostic.

A forty-page diagnostic can describe the programme back to people who have lived in it for two years. A point of view tells them what you have concluded. It also gives the sponsor something to challenge.

That matters.

You do not need a sponsor who agrees with everything you think. You need to discover where your judgement and theirs differ while there is still time to do something useful with the disagreement.

What I would not do in the first 30 days

I would not rush to reorganise the team.

I would not redesign every governance forum.

I would not promise a new date until I understood how the existing one was built.

I would not assume the people described to me as “difficult” are actually the problem.

And I would be very careful about announcing that the programme needs “more discipline” before understanding what the people on it have already been through.

There is a familiar piece of advice when starting a new leadership role: secure an early win. On a live programme, one of the most tempting early wins can be a new date.

The programme has been struggling. Confidence is low. You arrive, challenge the plan and announce something more credible.

It feels decisive.

But a date is only as reliable as the assumptions that sit underneath it.

Until you understand what the old date was built upon, there is a real danger that the new one rests on exactly the same foundations, except now it has your name attached to it.

There is, of course, an important exception to most of the above.

If you inherit a programme six weeks from go-live, a supplier is walking away or the sponsor has already lost the board, you may not get a comfortable 30-day learning period.

You may get a week at the most. You decide with what you have.

But I would still ask many of the same questions.

I would just ask them faster and accept incomplete answers.

How to tell whether the month worked

At the end of 30 days, there is an obvious way to measure progress.

You know more about the programme.

But I think there is another measure that matters just as much.

What can the people around you now say about you that they could not say on day one?

Not:

Roman knows the plan.

That would be a fairly poor return on a month.

Something closer to:

I know what I can decide without asking him.

I know when to bring him bad news.

I know what he thinks matters most.

I know which problems he expects me to own.

I know he will take a position when the programme needs one.

That is the other half of your first 30 days.

You were learning the programme.

The programme was learning how to work with you.

If, after a month, people still do not know what they can decide, what you expect them to own, whether they can bring you an unresolved problem or where you will take a position, then you may have learned a great deal about the programme.

The programme may still be waiting to learn about its director.

If you are inside your first 30 days now, I would start with two pieces of paper.

On the first, write down where the different versions of the programme do not agree.

On the second, write down which decisions you believe are yours, which ones need your recommendation, and which belong to the sponsor.

Take the second page to the sponsor before the end of the week.

And if your first 30 days are long behind you, those two pages are still worth writing.

They may tell you something about the programme you are running today.

— Roman

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.