FIELD GUIDE NO. 02 · FIRST EDITION 2026

The Transformation

Leader’s Field Guide.

A working reference for the senior leader accountable for whether a transformation programme actually pays back. The postures, the artefacts, the governance discipline, the benefits rhythm — and what separates a programme that ships from one that compounds. Aligned to PMI Program Management and PMI Benefits Realization Management. Parallel reference · Axelos MoP/MSP.

By Trevin Nimaladasa

Edition Vol. II · First Edition · 2026

Standard Aligned to PMI Program Mgmt + Benefits Realization Mgmt

Artefacts the leader owns

8×

Programme archetypes

8×

Industries calibrated

10+

Prompt templates

Preamble · Operating posture

Postures & Mindset

Six postures that hold up when the programme is under pressure. Written so a leader can use them as checks during real decisions — at the steering committee, at the funding gate, at the moment the vendor wants scope locked.

PMI Domain 1 · Strategy Alignment Domain 2 · Benefits Management Domain 3 · Stakeholder Engagement MSP · Lead with purpose · Realise measurable benefits

Leverage before launch

Every programme commitment answers a question about operational leverage. What stops, retires, or compounds because we did this? If nothing does, the programme is a renovation, not a transformation — and should be funded as one.

"What gets smaller, faster, or unnecessary because we did this?"

The operating model is the deliverable

The system, the vendor, the platform — those are the cost. The deliverable is a different way of running the business: different roles, different decisions, different rituals, different data flow. The business doesn't receive a system at go-live — it migrates into a new operating model.

"What runs differently on the Monday after go-live — and who runs it?"

Name the benefit owner before the case is signed

A benefit without an owner is a forecast. A benefit with an owner is a commitment. Every line in the benefits register has a name next to it — and that name is not the programme team. The programme finishes at go-live; the owner is on the hook for 24 months.

"Who is on the hook for this benefit twelve months from now?"

Kill criteria before kickoff

If there is no defined way for the programme to stop, the programme will only ever be paused — and paused programmes consume capacity indefinitely. The leader names, in writing, the conditions under which the programme is wound down.

"What evidence — if we saw it — would cause us to stop?"

Decision velocity, not artefact velocity

Programmes stall on unmade decisions, not on missing deliverables. The leader's primary metric is how many binding decisions get made per fortnight — and how many are still open past their due date. Steering committees that approve papers without making decisions are theatre.

"What did we decide this fortnight that wasn't decided last?"

One accountable name, not a committee

"The steering committee owns this" is the most expensive sentence in transformation. Every decision class, every benefit, every risk has a single named owner. The committee informs, escalates, and unblocks — it does not own. The leader who can't or won't name the owner is the owner by default.

"If this fails, whose name is on the page?"

A good transformation leader does not just sponsor delivery. A good leader builds the conditions under which an organisation can absorb change, sustain decisions, and compound benefits — programme after programme. The leadership philosophy

Mindset standards

Five postures that distinguish a sponsor from a signatory.

The programme is not the change.The programme is a vehicle. The change is whatever happens in the operating model after the programme closes. Optimising the vehicle without owning the change is funding motion, not transformation.

Governance is a system, not a committee.A committee meets and reviews. A system makes the next decision clear, fast, and owned. The leader installs a governance system the team can run between meetings — not more forums.

Capacity is the binding constraint.Strategy is not what gets approved in a paper — strategy is what gets resourced, and what gets deliberately starved. The leader either secures the capacity or shrinks the scope.

Sponsorship is not ownership.The sponsor signs the case and defends the funding. The owner runs the operating model the programme produces. The sponsor rotates within eighteen months; the owner is on the hook for years. Get this distinction wrong and the benefits register has names on it that mean nothing. See §02.

"We shouldn't fund this."The senior leader is comfortable saying it when the evidence supports it. The willingness to recommend cancellation is what separates a sponsor from a passenger.

The thesis · Why this guide exists

Delivery Is Not Value.

A portfolio that delivers excellent programmes against the wrong problems is a portfolio doing harm at scale. Value is operational leverage — what changes in how the enterprise actually works, after the programme closes. The leader's most important contribution is upstream of the funding decision, not in their visibility at the launch.

There is nothing so useless as doing efficiently that which should not be done at all. Peter F. Drucker

The Delivery Trap

Portfolios optimised for delivery focus on velocity and visibility. Programmes shipped. Milestones hit. Vendors paid. These metrics create the illusion of progress while the operating model moves sideways — or in the wrong direction. The trap shows up as: portfolios full of "completed" programmes with no measurable operational lift; business teams stretched thinner after delivery, not relieved by it; new platforms layered on top of old processes; benefits registers written once to secure funding and quietly retired; AI initiatives bolted onto workflows that were never simplified.

Programme factories

The portfolio continuously starts new programmes without retiring old ones. Each looks viable in isolation. Together they consume more capacity than the business has.

"How many programmes are we keeping alive past their useful life?"

As-is replication, at scale

The current operating model gets perfectly preserved into the new platform. Manual work is digitised instead of eliminated. The vendor calls this success — because the implementation matched the BRD.

"Are we transforming, or migrating dysfunction with a better licence cost?"

Benefits theatre

The business case names benefits to clear investment committee. The register goes into a drawer the day funding is approved. Twelve months later, no-one can find the register at all.

"Who can produce the benefits register, today, without a week's notice?"

Success at go-live

The launch is celebrated. Operations quietly absorbs more work because the old and new processes now both run in parallel. By the time anyone asks whether it paid back, the leadership team has rotated and the question becomes unanswerable.

"What evidence — six months from now — would say this paid back?"

The Illusion Stack

The illusion starts long before delivery. The sequence is predictable, and each step creates a different illusion that hardens before the leader has a chance to call it. By the time delivery begins, assumptions have hardened into commercial commitments.

The Illusion Stack · what each step produces, and what it hides
Step	What it produces	The illusion it creates
Strategic narrative	A funded story about why this matters.	The appearance of alignment before the operating-model implications have been costed.
Business case	An NPV-positive financial argument.	The appearance of value before the benefits have an owner who'll be there to realise them.
BRD / Solution Outline	A documented future state.	The appearance of certainty before the problem is sharp.
RFx	A market test of vendors against the BRD.	The appearance of choice before the trade-offs are owned.
Vendor selection	A signed scope, schedule, and price.	The appearance of control. Scope is contractually locked — not strategically chosen.
Delivery	A go-live, a launch, a closure report.	The appearance of success before anything in the operating model has actually changed.
Benefits register hand-off	A document marked "owner: TBC".	The appearance of accountability — but no-one's calendar reflects it.

The transformation leader's leverage point is between the strategic narrative and the business case. Every step after that is harder, slower, and more politically expensive to unwind. The earliest move is the cheapest move. The leader's window

iii

The standards · Where this guide aligns

PMI · MoP/MSP Alignment.

This guide is not a study guide. It is a working reference for a senior transformation leader running real programmes — and it sits cleanly inside the disciplines named by the PMI Standard for Program Management and PMI Benefits Realization Management, with MoP/MSP as parallel reference. The map below tells you where each section of the guide lands inside those standards.

PMI Program Management Performance Domains

The Standard for Program Management names five performance domains. This guide operationalises all five.

Domain	What PMI names	Where this guide lands it
Strategy Alignment	The programme is anchored to enterprise strategy and contributes to a defined capability.	§i Postures · §01 Investment Thesis · §04 Decision Hygiene · §06 Stage Gates
Benefits Management	Benefits are identified, planned, delivered, transitioned, and sustained.	§01 Benefits Map · §09 Benefits Realisation · §11 Operating Rhythm
Stakeholder Engagement	Stakeholders are identified, analysed, and engaged across the lifecycle.	§01 Accountability Charter · §07 Governance Dial-ups · §08 Industry Calibration
Governance	Decisions, rights, and oversight are explicit and enacted.	§01 Governance Operating Model · §07 Dial-ups · §11 Rhythm
Life-cycle Management	The programme has explicit phases, gates, and transitions.	§06 Stage Gates · §09 Benefits Realisation · §11 Closure Cadence

MSP Principles · How they show up here

MSP names seven principles. Each becomes a working posture inside this guide.

MSP Principle	How it lands in this guide
Lead with purpose	The Investment Thesis (§01) is the programme's anchor — every paper, every decision, every contract traces back to it.
Collaborate across boundaries	The Accountability Charter (§01) names the boundary-spanning decisions and who owns each one. No "the committee."
Deal with ambiguity	Decision Hygiene (§04) is the practice that surfaces ambiguity before it hardens into commercial commitment.
Design in coherent chunks	Programme Archetypes (§05) help the leader scope, sequence, and resource by archetype rather than monolithically.
Align with priorities	The Stage Gate framework (§06) is the cadence that re-tests alignment with enterprise priorities — at every gate.
Deploy diverse skills	Governance Dial-ups (§07) and Industry Calibration (§08) name the specialist skills required by context.
Realise measurable benefits	Benefits Realisation (§09) is the post-go-live spine — named owners, real cadence, structured variance reviews.

MoP · The portfolio frame above the programme

MoP (Management of Portfolios) sits above MSP. Where MSP organises a programme, MoP organises the set of programmes a portfolio runs. Two MoP principles flow into this guide. Senior management commitment — the named, accountable transformation leader is the embodiment of this principle; without one, the portfolio defaults to "the committee." Strategy alignment — every programme in the portfolio is interrogated for its contribution to a stated strategy. Section §04 (Decision Hygiene) is the test the leader applies before a programme is admitted to the portfolio at all.

The minimum · Non-negotiable

The Floor — seven artefacts.

Seven artefacts that together form the execution system a transformation programme runs on. Owned by the transformation leader, not delegated to the programme manager. Right-sized to context but never absent. The point isn't the documents — the point is what they force into the open: a named bet, a named owner, a named benefit, a named decision, a named risk, a named outcome.

PMI Strategy Alignment Benefits Mgmt Governance MSP · Vision · Blueprint · Benefits Profiles

Investment Thesis

One page. Why this programme is the right use of capital and capacity, in the leader's own language, with kill criteria.

Read▾

Purpose

The single sheet every steering paper, business case, vendor brief, and status report traces back to. Names the bet. Names the conditions under which the bet is wrong. Anchors the programme to enterprise strategy before any solution conversation is open. This is not the business case — the business case is the financial argument; the Investment Thesis is the strategic one.

Template — sections

The bet	What we believe will be true twelve months after this programme closes. One sentence.
Why now	What forces this decision in this funding cycle rather than the next.
Strategic anchor	The enterprise strategy or capability roadmap this programme serves. Named, not implied.
Leverage created	What stops, retires, simplifies, or compounds. The leverage thesis in operational terms.
What we're explicitly not doing	Adjacent problems, attractive scope, defensive features — and why each is out of scope.
The accountable sponsor	Named individual. Not a committee. Not a role. The person whose calendar reflects this work.
Kill criteria	What evidence, if observed, would cause us to wind down. Written before kickoff.
Decision rules	What we optimise for when trade-offs appear. Written in advance.

Worked example · core systems modernisation, utility sector

The bet. Standardising on a single project & portfolio platform — with the finance system as the authoritative actuals feed — will eliminate the monthly reconciliation cycle and give project managers a live financial position they can act on without finance support.

Why now. The legacy reconciliation process is fragile, owned by a single SME approaching retirement, and the audit committee has flagged it twice. Doing nothing is not stable.

Leverage created. Retire the parallel reconciliation pathway. Reclaim ~3 FTE-months per quarter in finance partner time. PMs make funding-level decisions inside the platform.

Kill criteria. If finance integration cannot achieve clean reconciliation within the first three monthly cycles after go-live, the programme reverts to parallel reconciliation and the modernisation pause is reassessed at the next gate.

Benefits Map

Output → outcome → benefit → strategic objective — with owners, baselines, and tracking cadence per benefit.

Read▾

Purpose

Forces the programme to trace every output (what we build) through to a strategic objective (what the enterprise wants). Without this map, the programme delivers outputs and assumes the rest will follow. With it, every line of scope is testable against the question "and the benefit this produces is…".

Template

Output	Outcome	Benefit	Owner	Baseline	Target	Cadence
What we ship	What changes operationally	The measurable result	Operational owner — named	Pre-programme value	Post-realisation value	Monthly / quarterly

Worked example · enterprise HR programme

Output — single HRIS platform live across all business units. Outcome — manager self-service for leave, performance, and basic transactions. Benefit — 40% reduction in HR transactional load. Owner — Head of HR Operations. Baseline — 2,800 transactions/month in shared services. Target — <1,700/month within 12 months of go-live. Cadence — monthly through +12, quarterly to +24.

Accountability Charter

Who decides, who signs, who's on the hook post go-live. The map that replaces "the committee" with names.

Read▾

Purpose

Names accountability for every binding decision class the programme will encounter, and every benefit the programme will eventually transition to operations. The most expensive form of decision drift is the absent name — "the steering committee" is a euphemism for "no-one in particular." The Charter replaces euphemism with names. It has two halves: who decides during the programme, and who owns the benefit after the programme closes. The operational owners listed in the second half are not signing for ceremony — they are the people who will run the new operating model. If they're not in the room when the Charter is drafted, the Charter has been written for the programme's convenience, not for the business that has to live with the outcome.

Template · decision rights matrix

Decision class	Accountable	Consulted	Informed	Escalation
Investment / funding	name	name	name	name
Scope	name	name	name	name
Vendor & contract	name	name	name	name
Architecture & integration	name	name	name	name
Change & adoption	name	name	name	name
Go-live readiness	name	name	name	name
Benefits sign-off	name	name	name	name
Programme closure	name	name	name	name

Worked example · multi-vendor integration programme

Architecture & integration. Accountable: Enterprise Architect. Consulted: Solution Architects per workstream, Lead BA, vendor leads. Informed: Programme Board. Escalation: CIO.

Benefits sign-off. Accountable: Head of Service Delivery (not the programme sponsor). Consulted: Finance Business Partner. Informed: CFO. Escalation: Executive Sponsor.

Disagreement protocol. Time-boxed at 5 working days from logged disagreement. Unresolved disputes escalate with a written one-pager from the accountable party stating the trade-off they are recommending.

Governance Operating Model

Forums, cadence, escalation, scope-of-authority. Governance as a system the team can run between meetings — not theatre.

Read▾

Purpose

Designs governance as an instrument the leader uses to keep decisions moving — not a recurring forum where decisions go to die. Specifies what each forum decides (and explicitly what it does not), how often it meets, who attends, what escalation looks like, and the boundary between informed and accountable.

Template

Forum	Decision scope	Cadence	Attendees	Escalation
Programme Board	Strategic decisions only — scope, investment, kill criteria	Monthly	SRO + sponsors + leader	Executive committee
Working group	Operational decisions within scope	Weekly	Workstream leads + leader	Programme Board
Architecture authority	Architecture & integration decisions	Fortnightly	EA + solution architects + vendor leads	CIO via Programme Board

The "what we don't do here" boundary

Every forum has an explicit list of decisions it cannot make — to prevent forum drift. The Programme Board doesn't approve weekly status. The working group doesn't approve scope changes. The architecture authority doesn't approve funding.

Decision Log

Every binding decision, the moment it was made, by whom, with what reasoning. The auditable spine.

Read▾

Purpose

The leader's most underrated artefact. Captures every binding decision — the call, the date, the accountable name, the rationale, and the alternatives that were rejected. It is the artefact that makes governance auditable, defensible, and reversible-when-it-must-be. Most programmes have a status report; few have a Decision Log. The leaders who do are the leaders who can explain — in any room, on any day — why the programme is where it is.

Template

Date	Decision	Made by	Rationale	Alternatives rejected	Reversibility
YYYY-MM-DD	The decision in one sentence	Named individual	Why this option	What we considered and why we said no	Easy / hard / locked

The reversibility column matters

Decisions are not equal. A reversible decision should be made fast and adjusted later. A locked decision (commercial commitment, system architecture, regulatory filing) deserves more rigour upfront. Labelling reversibility on the log is what gives the leader decision velocity without decision recklessness.

RAID Register

Risks, Assumptions, Issues, Dependencies — owned by name, reviewed on cadence, retired with evidence.

Read▾

Purpose

Standard discipline most programmes treat as filler. The senior leader uses the RAID as an early warning system, not a reporting artefact. Every item has a named owner, a review date, a kill-criteria for retirement, and an explicit link to the Benefits Map (because most material risks are risks to benefits, not risks to delivery).

Template highlights

Type	Description	Owner	Probability × impact	Mitigation	Linked benefit
Risk	What could go wrong	Named owner	L/M/H	Active mitigation	Which benefit is at risk
Assumption	What we're betting on	Owner who'll be wrong if it fails	Confidence	What validates it	—

Outcome Dashboard

One screen. Leading indicators, benefit trajectories, decision-velocity metric, RAID trend. What the leader looks at every week.

Read▾

Purpose

The leader's working surface. Not a status report, not a sponsor briefing pack — a single screen the leader can look at on a Monday morning and know whether the programme is healthy. The dashboard answers four questions: are benefits tracking? are decisions being made? are risks being closed or accumulating? is the operating-model change progressing or stalled?

What goes on the screen

Benefit trajectory — leading indicators per benefit, plotted vs target. Decision velocity — decisions made this period vs decisions still open past their due date. RAID trend — opened vs closed this period, with the top three risks named. Operating-model adoption — for live programmes, the leading indicators of the new operating model actually being used (usage rates, process throughput, manager self-service uptake, etc).

The work behind the funding · Who actually owns this

Business Ownership.

Sponsorship is not ownership. Sponsorship is the political cost of standing behind a programme; ownership is the operational cost of living inside the operating model the programme produces. The two are routinely confused, and the confusion is the single most common reason transformation programmes fail to realise benefits. The sponsor rotates within eighteen months. The owner is the person whose performance review still mentions the benefit four years later.

PMI Benefits Management Stakeholder Engagement Governance MSP · Senior Responsible Owner · Business Change Manager

Systems are not accountable. Leaders are. A benefit cannot be owned by a platform, a process, or a portfolio — only by a person whose calendar reflects it and whose performance review references it. The ownership thesis

Sponsorship vs ownership — the distinction that gets blurred

Both roles are necessary. They are not the same role. Every transformation programme needs both, and the leader's job is to make sure neither is being asked to do the other's job.

Dimension	Sponsor	Owner
Primary question	Is this still the right bet for the enterprise?	Will my operating model actually run this on the Monday after go-live?
Time horizon	Programme lifecycle — until closure.	Two to four years past closure — until the benefit is structurally embedded.
What they sign for	The Investment Thesis. The funding. The kill criteria.	The Benefits Map. The operating-model change. The realisation cadence.
Where their calendar shows it	Steering committee. Sponsor sync. Board briefings.	Operational reviews. Benefits reviews. The Monday-morning question of "is this working?"
What they're rewarded on	Programme delivered on bet, schedule, and budget.	Operating-model outcomes — measured in their P&L, KPIs, performance review.
What "failure" looks like	Funding wasted; political cost; investment thesis disproved.	The new operating model never embeds; the team works around it; the benefit dies.
Rotation reality	~18 months on average. The role outlasts the person.	Owns the change until the change owns itself. Years, not months.

The four ownership failure modes — and what they look like in flight

The absent owner.The Benefits Map shows "Owner: Head of Operations" but no-one in operations has actually agreed to it. The name was added to clear the gate. Twelve months post go-live, nobody is tracking the benefit because nobody believes it was theirs to track.

The borrowed owner.The owner is named, but is also running their day job, three other programmes, and an org restructure. The ownership is real on paper and notional in practice. The programme delivers; the change does not embed.

The rotated sponsor.The sponsor who signed the case has moved on. The new sponsor inherited the programme but not the bet. The Investment Thesis quietly drifts. Ownership of the operating-model change — which was already shaky — now has no senior backing.

The implied handover.At closure, the programme team "hands the benefits to BAU." There is no signed transfer, no named accountable owner, no first review in the calendar. Within ninety days, tracking has stopped. Within twelve months, the benefits register cannot be found.

Strategy is not what gets approved in a paper. Strategy is what gets resourced — and what gets deliberately starved. Ownership is the same: a benefit owned in writing but not in calendar is a benefit being deliberately starved. Why ownership has to be funded

What a business owner actually does — concretely

Most ownership conversations stay at the level of "they're accountable." That is not a job description. These are the seven things an operational owner does that nobody else can do for them.

What the owner does	What it means in practice
Co-designs the operating model	The owner is in the room when the new processes, roles, and decision rights are designed — not at the end signing off what was designed for them. If they're not present at the design phase, they will own a model they did not build.
Names the benefit baseline	Says, in writing, what the current performance is. Most baselines are invented by the programme team because no-one in operations would commit to a number. If the baseline isn't owner-signed, the variance conversation has no honest reference point.
Commits the capacity	Names which of their team's hours will be diverted to learn, transition, and embed the new model. Capacity is the binding constraint. Silence on capacity is consent to the team being overrun.
Owns the change-management plan	The change-management plan is signed by the owner, not the programme. The owner is the person whose team has to absorb the change; if it's not theirs to author, it won't be theirs to enforce.
Chairs the realisation review	From +3 months onward, the owner chairs the benefits review — not the programme leader. The programme leader attends as advisor. This is the ritual that proves the handover happened.
Names the operating-model debt	At closure, the owner identifies what stayed that was meant to retire — the workaround, the parallel process, the spreadsheet. They take responsibility for retirement and name the date.
Carries the variance conversation	If the benefit drifts, the owner is the one who explains why, names the action, and adjusts. They do not escalate to the programme leader, because the programme leader has closed. Ownership is the inability to escalate.

The Ownership Charter — a working artefact

The Accountability Charter (§01) names decision rights during the programme. The Ownership Charter names operational ownership after it. Both are needed. The Ownership Charter is signed at G2 (contract gate) — not at closure — so the named owner has a year to shape the change they will inherit.

Ownership Charter · template
Benefit / capability	Operational owner	Reporting line	Capacity committed	First review	Performance link
Named benefit from the Benefits Map	Named individual — not a role	Their line manager / executive	Hours per week / month, named, agreed by line manager	Date — within 3 months of go-live	How this benefit shows in the owner's KPIs or performance review

The performance link is non-negotiable. If the owner's performance review does not reference the benefit, the ownership is decorative. The leader's job — and this is often the politically uncomfortable conversation — is to make sure the line manager of the named owner agrees that this benefit will be part of how the owner is assessed. Without that conversation, the owner has been handed a benefit they cannot afford to prioritise.

The handover discipline — what proves it stuck

Ownership transfer is a moment, not a memo. Most handovers fail because the programme team announced the transfer and the receiving team didn't accept it. These five tests are how a leader knows the handover actually happened.

The owner can describe the benefit without notes.If they need the Benefits Map to explain what they own, they don't own it yet. Ownership shows up in language, not documentation.

The owner has met their measurement source.The data, the system, the report, the team that produces the number — the owner has seen it work and trusts it. If they're learning it at the first review, the review will be theatre.

The first three reviews are in the calendar.+30 days, +3 months, +6 months. Booked. With the right attendees. Before closure. If they're not booked, they won't happen.

The owner has run a variance conversation.Pre go-live, deliberately, on a leading indicator. To prove the muscle exists. Because the first real variance conversation will be in the middle of hyper-care and that's not the moment to learn the rhythm.

The line manager has signed.The owner's manager has agreed, in writing, that ownership of this benefit is part of the owner's job. Without that, ownership evaporates the moment a competing priority arrives — which is always.

Worked example · enterprise HR transformation

The programme. Single HRIS platform replacing three legacy systems across all business units. Benefits case forecast 40% reduction in HR transactional load, freeing capacity for strategic work.

The sponsor. Chief People Officer. Signed the Investment Thesis. Chairs the Programme Board. Will rotate roles roughly six months after go-live (succession plan is known).

The owners (named at G2, eighteen months before go-live). Head of HR Operations owns transactional load reduction. Head of Talent Acquisition owns the recruitment-cycle benefits. Head of Reward owns the compensation-cycle benefits. Each has capacity committed (8 hours/week through go-live + 4 hours/week for the first six months), their line manager has signed, and the benefit appears explicitly in their next annual performance review.

What the leader did differently. Refused to let the Benefits Map say "Owner: TBC" anywhere. Booked the first three reviews before contract signature so the owners could push back on dates if they didn't suit operational rhythm. Held a fifteen-minute conversation with each owner's line manager to lock the performance-review link. Caught one case where the named owner did not actually have the team capacity, and renegotiated with the line manager at G2 — not at go-live, when it would have been too late.

The result at +12 months. Three of four major benefits realised against target. The one drifting benefit had an owner-led recovery plan inside thirty days of the variance being named — without the programme team being asked to re-mobilise.

The business owns the change. The programme enables it. Get this backwards and the programme delivers a system to people who will inherit a problem. The ownership posture

Named tools · Portable · Decision-forcing

The Leader's Toolkit.

Seven named tools the transformation leader uses across the lifecycle. Each is portable — a colleague can run it after one explanation. Each is decision-forcing — applying it produces an action, not awareness. Each is referenced throughout this guide by name. The tools are not a substitute for judgement; they are scaffolding that makes the leader's judgement faster, sharper, and more defensible.

PMI Strategy Alignment Benefits Mgmt Governance MSP · Tailoring · Decision rights · Realisation discipline

The Leverage Test

Three answers required at framing. No answers → it's a renovation, not a transformation. Run before any programme is admitted to the portfolio.

Read▾

The test

Before funding is committed, the leader requires three concrete answers — in writing, in plain English, signed by the sponsor:

What gets smaller because we did this? (effort, cost, cycle time, role count, complexity)
What gets faster because we did this? (a decision, a process, a customer outcome, a release cycle)
What becomes unnecessary because we did this? (a system, a workaround, a parallel process, a manual reconciliation, a team)

The decision rule

If the sponsor cannot answer all three with specifics — not adjectives — the programme is a renovation dressed in transformation language and should be funded as one. Renovations are honourable; they just shouldn't be sold to investment committees as transformations.

Why it works

The test forces the conversation upstream of the business case. It surfaces the difference between "doing more" and "doing differently" before millions are committed. The sponsor who cannot answer column three is the sponsor who will quietly let the legacy stay live.

When to run

At G0 (Concept) and again at G1 (Investment). Re-run at G3 if the scope has materially changed.

The Sponsor/Owner Split

A two-column reconciliation that surfaces the gap between political backing and operational ownership. Run on every programme at G1.

Read▾

The test

For every benefit on the case, the leader produces two columns:

Sponsor column	Owner column
Who signed the funding paper?	Who runs the operating model after closure?
Who attends the steering committee?	Whose calendar reflects the change post go-live?
Who pays the political cost if it stalls?	Whose KPIs change because of this benefit?
How long are they in role?	How long until the change is structurally embedded?

The decision rule

If the Owner column says "the sponsor" — the programme is not yet fundable. If the Owner column is blank — the programme is not yet fundable. If the Owner is named but their line manager has not agreed to the performance link — the programme is not yet fundable.

Why it works

Most enterprise benefits cases conflate the two roles deliberately, because the sponsor is the only person willing to sign at the moment funding is needed. The Split makes the missing operator visible before the gate, not at +12 months when no-one can be held to the case.

When to run

At G1 (Investment). Re-run at G3 if either party has changed role. Reference: §02 Business Ownership.

The 18-Month Pre-Mortem

Move forward in time. Write the post-mortem of the programme that failed. Walk it back. Use as the design brief.

Read▾

The exercise

The leader, the sponsor, and the named owners sit in a room with one premise. It is eighteen months after closure. The programme failed to realise its core benefits. Each person writes — independently, on paper, no discussion — answers to three prompts:

What did we get wrong? The central misjudgement.
Why did it fail? The sequence of decisions, omissions, and assumptions that compounded.
Who could have stopped it, and when? Name the gate, the meeting, the moment.

Then read aloud. The patterns are uncanny: the same three or four failure modes surface in every person's notes. Those are the real risks — surfaced before they cost anything.

The output

Three "fix it now" actions, owned and dated, that change the programme design in the next two weeks. Not a risk register entry. Actual change to scope, sequence, ownership, or capacity.

Why it works

People are bad at predicting failure but extraordinary at explaining it. The pre-mortem inverts the cognitive bias. It also surfaces the political truth — the things people know but won't say in a forward-looking conversation come out freely once the premise is "we already failed."

When to run

Once at G1 (before funding). Once at G2 (before contract). And as a leader's solo exercise any time the programme is drifting and you can't name why.

The Kill Criteria Clock

Explicit evidence + date at which the programme winds down. Set at G1. Reviewed at every gate. Binary question: do those conditions still hold?

Read▾

The artefact

A one-page document signed at G1 that names, in advance, the evidence under which the programme is stopped. Not "lose support." Not "things go wrong." Specific, observable, dated conditions.

Condition	Evidence	Review date
The bet is disproved	e.g. pilot results show <50% of forecast leverage	+90 days post pilot
The owner cannot commit capacity	Named owner formally withdraws hours or moves role without replacement	Within 14 days of event
The integration is not viable	Architecture authority concludes the integration cannot meet performance threshold	+30 days of finding
The cost-of-carry exceeds the benefit	Realised cost at G3 is >1.5× original case AND benefits forecast unchanged	G3

The cadence

Read aloud at every steering committee. The question is binary: do these conditions still hold, yes or no? If yes, proceed. If no, the conversation that follows is the most important conversation in the programme's life — and the leader is on the hook to facilitate it honestly.

Why it works

Programmes without explicit kill criteria can only be paused. Paused programmes consume capacity indefinitely. The Clock makes stopping a designed-in option, not a political event.

When to run

Authored at G1. Reviewed at every gate and every steering. Never archived.

The Operating-Model Debt Register

Everything that was meant to retire and didn't. A register with a cost-of-carry column. What the next programme inherits.

Read▾

The register

A live document that captures, throughout the programme and at closure, every workaround, parallel process, spreadsheet, role, or system that was meant to be retired by the new operating model but stayed live. Each entry has a cost-of-carry — measured in FTE-days, dollars, or risk exposure — that the business is now paying indefinitely.

ID	What stayed	What should have retired it	Owner	Retirement plan	Cost-of-carry
OMD001	Monthly reconciliation spreadsheet	PPM platform integration	Finance Business Partner	Action + date	4 FTE-days/month
OMD002	Parallel approval queue in legacy CRM	Workflow in new platform	Head of Sales Ops	Action + date	2 FTE-days/week

The discipline

Cost-of-carry is reviewed at every quarterly portfolio meeting. Items without a retirement date are escalated. The register is handed to the leader of the next funded programme — formally, in writing, before they begin. They start with a known inheritance, not a hidden one.

Why it works

Operating-model debt is the single most under-tracked liability in transformation portfolios. Most programmes "go live" carrying debt no-one named. That debt compounds, silently, until the next programme has to absorb it without funding. The register turns invisible debt into visible debt — and visible debt gets retired.

When to run

Opened at G2. Updated continuously. Handed forward at closure. Reviewed quarterly at portfolio level. Reference: §09 Benefits Realisation.

The Decision Velocity Score

Decisions made this fortnight ÷ decisions still open past due date. A single ratio per programme. Stalled programmes show up here before anything else fails.

Read▾

The score

For each programme, every fortnight, compute one ratio:

DVS = Decisions made this period ÷ Decisions still open past due date

The reading

DVS > 1.5 — Healthy. The programme is closing decisions faster than it's accumulating them.
DVS 1.0–1.5 — Watch. Decision flow is keeping pace but not getting ahead. Surface what's slowing the close rate.
DVS < 1.0 — Slow. More decisions opened or breaching SLA than closed. Programme is accumulating decision debt.
DVS < 0.5 sustained for 3 periods — Stalled. The programme has stopped deciding. Delivery is theatre. Intervene.

Why it works

Programmes do not fail at delivery; they fail at decision. Status reports are slow indicators — by the time RAG turns red, the cause is months upstream. The DVS is a leading indicator. A programme cannot deliver if it cannot decide, and the ratio shows that before the delivery dashboard does.

What it asks of the leader

The leader must keep the Decision Log live (§01) and discipline the team to log decisions on the day they're made. If the team is not logging, the score is wrong. The act of measuring the score is what creates the discipline.

When to run

Every fortnight. Surfaced on the Outcome Dashboard. Reviewed at every Programme Board.

The Handover Five

Five tests applied before any programme closes. Pass/fail. Closure cannot occur if any one fails.

Read▾

The five tests

Before the closure paper is signed, the leader certifies — with evidence, not assertion — that each of the following is true:

The owner can describe the benefit without notes. Ownership shows up in language, not documentation. If the owner needs the Benefits Map to explain what they own, they don't own it yet.
The owner has met their measurement source. They've seen the data, the system, the report. They trust it. If they're learning it at the first review, the review will be theatre.
The first three reviews are in the calendar. +30 days, +3 months, +6 months. Booked. With the right attendees. Before closure.
The owner has run a variance conversation. Pre go-live, deliberately, on a leading indicator. The muscle exists before it's needed.
The line manager has signed. Owner's manager has agreed, in writing, that ownership of this benefit is part of the owner's job. Without this, ownership evaporates the moment a competing priority arrives.

The decision rule

Five passes — closure proceeds. Any fail — closure is held. The programme funds an additional period to complete the handover, or the leader formally escalates that closure is being declared without ownership transfer (which is honest, and increasingly rare once this tool is in use).

Why it works

Most handovers fail because the programme team announced the transfer and the receiving team didn't accept it. The Handover Five replaces announcement with evidence. It is the single most expensive tool to skip — and the single cheapest to apply.

When to run

At G4 (Go-live readiness) and again at closure. Reference: §02 Business Ownership.

Tools without names get used once and forgotten. Tools with names get passed between leaders, taught to teams, and survive the person who introduced them. Naming is how a practice compounds. Why these are named

Decision hygiene · Before the business case opens

The Eight Tests.

If you have five hours to cut down a tree, spend the first four sharpening the axe. Eight tests the transformation leader applies before the business case opens — because once it's open, the assumptions baked in are very expensive to remove. Skip these and the programme documents symptoms, freezes the wrong solution, and locks in low-leverage work.

PMI Strategy Alignment Program Definition Phase MSP · Identifying · Designing a Programme

The investment framing test

Make the investment decision explicit before solutioning. What capability are we creating or retiring? What's the unit of leverage? Strategy is not what gets approved in a paper — strategy is what gets resourced, and what gets deliberately starved. Every funded programme is an implicit decision to under-fund something else; the leader names that something.

"What is this programme an investment in — and what does it crowd out?"

The problem worth solving test

Define the problem before defining the solution. Who is affected? What effort, delay, cost, or risk exists today? Why is this worth solving now and not next year? If the team is debating solutions, the problem isn't sharp enough.

"Could a competitor identify this same problem from the outside?"

The leverage thesis

Force the compounding question early. What effort disappears permanently? What decision becomes faster? What capability becomes reusable across programmes? If nothing compounds, the programme is a maintenance activity dressed in transformation language.

"What gets easier — for someone else — because we did this?"

The trade-off declaration

Kill ambiguity upfront. What are we explicitly not optimising for? Speed vs correctness? Flexibility vs simplicity? Local benefit vs enterprise reuse? Unstated trade-offs always reappear as scope creep, vendor disputes, or post-go-live regret.

"What are we choosing not to be good at?"

The benefit owner test

For every benefit on the case, name the operational owner — the person whose KPIs will reflect realisation. If the only owner you can name is the sponsor or the programme team, the benefit will not realise. The programme team leaves at closure; the sponsor rotates within 18 months.

"Whose performance review changes because of this benefit?"

The capacity reality check

Programmes assume the business has capacity to absorb the change. Most don't. Map the planned change against operational rhythm — peak periods, audit cycles, regulatory windows — and ask honestly whether the operating teams have the bandwidth to do their day job and the change. Silence here is consent to overrun.

"Have we secured the capacity, or are we hoping?"

The kill criteria test

Before kickoff, name the evidence that would cause this programme to stop. Not "lose support" — actual operational, financial, or strategic evidence. A programme without kill criteria can only be paused; paused programmes consume capacity indefinitely.

"If we saw X, would we have the courage to wind this down?"

The 18-month pre-mortem

Move forward in time. It is eighteen months after closure. The programme failed to realise its core benefits. Write the post-mortem — who didn't do what, which assumption was wrong, which decision came too late. Then walk it back and use it as the design brief.

"What is the most likely future regret on this programme?"

Three leader scripts (use these in real meetings)

To re-open framing without sounding obstructionist."I want to make sure we're investing in the right thing. Can we spend ten minutes restating what capability we're building, and what we're choosing not to fund as a result?"

To force benefit ownership."Before we approve this, I need every benefit to have an operational owner. Not the programme team, not me — someone whose performance is going to reflect realisation. Who is that person, for each benefit?"

To name kill criteria."I'd like us to agree, in writing, the evidence that would cause us to stop this programme. Naming kill criteria now is how we earn the right to move fast later — and how we protect the portfolio if this isn't the right bet."

Classification · How to recognise what you're funding

Programme Archetypes.

Eight archetypes. Each has a distinct funding pattern, governance pattern, benefit-realisation pattern, and failure mode. The leader's first job at framing is to recognise which archetype the programme actually is — because the discipline that suits a Modernisation will quietly suffocate an M&A integration, and the rigour that suits a Compliance programme will paralyse a Cost-out.

Modernisation

Replacing or retiring a core platform. Re-platforming, lifting-and-improving, or moving from legacy to SaaS.

Read▾

What's distinctive

Funded for capability replacement, not new capability creation. Benefits realise slowly — most of the value is in retirement (of old systems, parallel processes, fragile integrations). Easy to over-engineer; easy to declare success at go-live and miss the actual leverage moment which is decommissioning.

The leader's discipline

Track decommissioning as a primary benefit. Anything not retired is an operating-model debt entry. Resist the urge to add new capability — the case was funded for replacement.

Consolidation

Bringing multiple systems / teams / processes into one. Common after M&A, divestment, or org restructure.

Read▾

What's distinctive

The hard work is in the operating model, not the system. People lose decision rights, ways of working get standardised, local optimisation surrenders to enterprise rules. The system change is the easy part; the political change is the hard part.

The leader's discipline

Sponsorship matters disproportionately. Without a named executive willing to absorb the political cost, the programme will deliver a consolidated platform alongside un-consolidated practices.

Capability Build

Creating a capability that did not exist — new function, new platform, new way of working.

Read▾

What's distinctive

The benefits are hardest to forecast because there is no baseline. Easy to over-promise. Tendency to under-resource the change side because "it's all new — there's nothing to change from."

The leader's discipline

Treat the operating-model design as the primary deliverable, not the system. The organisation has to invent how the new capability fits — and that invention is the work.

Compliance / Regulatory

Programme exists because a regulator or auditor said so. The business doesn't want it; it has to do it.

Read▾

What's distinctive

Benefits are negative-cost avoidance, not positive value creation. Easy to under-scope (do the minimum) or over-scope (gold-plate the response). The temptation is to treat it as a documentation exercise.

The leader's discipline

Treat the regulator as a stakeholder, not an obstacle. Build the operating-model change that also creates uplift — many compliance programmes contain a quiet operational improvement opportunity inside them.

M&A Integration

Day-one to Day-X integration of an acquired or merged entity.

Read▾

What's distinctive

Two cultures, two operating models, two sets of systems — and the case for the deal usually assumed integration synergies that have not yet been costed. The clock is real; the political stakes are high.

The leader's discipline

Sequence by decision class, not by system. The most expensive integration mistakes are decisions made fast that should have been deliberate, and decisions deferred that should have been made on Day One.

Cost-out

Programme exists to reduce run-cost — headcount, vendor spend, infrastructure, or process cycle time.

Read▾

What's distinctive

Benefits are visible and measurable in months, not years — but the change-management cost is high. Easy to declare a saving while creating an operating-model fracture that costs more downstream.

The leader's discipline

The saving is not the benefit. The benefit is the saving without creating a downstream operational liability. Track operating-model debt as a counter-metric to dollar savings.

Digital Front-door

Customer-facing channel transformation. New portal, new app, new self-service experience.

Read▾

What's distinctive

Highly visible (board pays attention, customers see it). Easy to over-invest in the front and under-invest in the back — meaning the new experience surfaces the unchanged operating model behind it, often worse than before.

The leader's discipline

Cap the front-end scope to what the back-end can honour. If the digital experience exposes the broken process, the programme has made the customer's experience worse, not better.

Data & AI

Programme to land data infrastructure, analytics capability, or AI in production.

Read▾

What's distinctive

Most programmes named "AI" are actually data-foundation programmes — and most fail because they were funded as the former. No data strategy means no AI strategy. The leader has to expose this honestly to the funding body.

The leader's discipline

Name the data-foundation work as the primary deliverable for the first 12-18 months. The AI use-cases are the proof points, not the programme.

The pivot points · Entry & exit

Stage Gates.

Five gates, each with explicit entry and exit criteria. The point of a gate is not to slow the programme down — the point is to ensure the programme has earned the right to continue. A gate without criteria is theatre. A gate with criteria is governance.

The five gates · entry criteria, exit evidence
Gate	Purpose	Entry criteria	Exit evidence
G0 · Concept	Should we explore this?	Strategic narrative drafted. Problem-worth-solving test passed. Initial sponsor named.	Funded discovery slot. Decision hygiene tests committed to as the next-phase work.
G1 · Investment	Is this the right bet?	Funded business case. Benefits map with named owners. Kill criteria committed. Programme leader appointed. Accountability Charter v1.	Programme initiated. Vendor selection process scoped. Governance Operating Model agreed.
G2 · Contract	Are we committing to the right vendor and the right scope?	Vendor evaluation complete with explicit trade-offs declared. Reference checks done. Integration readiness assessed. Commercial terms reviewed by procurement and legal.	Contract signed. Vendor onboarded. Architecture & integration approach baselined.
G3 · Build / Implement	Is the operating-model change being built alongside the system?	Functional design signed off by business owners. Change-impact assessment per workstream. Data migration approach validated. Training and adoption plan with named owners.	Build complete. UAT passed against business scenarios — not just system scenarios. Operating model documented for go-live.
G4 · Go-live	Is the business ready to run the new operating model?	Operational readiness assessment. Hyper-care plan named with operational owner. Benefits baseline locked. First six months of realisation reviews already in calendars.	Cutover successful. Stabilisation period defined. Benefits realisation cadence underway.

Four questions every gate must answer

Has the bet changed?Is what we believed at G1 still what we believe today? If not, what's the implication for the case and the kill criteria?

Are the named owners still here?Sponsor, benefit owners, operational owners — are they still in role and on the hook? Sponsor rotation between G1 and G3 is the silent killer of benefits realisation.

Has the operating-model change progressed?Or has only the system progressed? At every gate, the leader asks: "what runs differently in the business because of work completed this phase?"

Do the kill criteria still hold?Are the conditions for stopping still defined, still relevant, and still understood by everyone in the room? Kill criteria that get quietly forgotten between G2 and G3 are kill criteria that don't exist.

Above the floor · Context-driven rigour

Governance Dial-ups.

Governance is not a committee. Governance is the system that makes the next decision clear, fast, and owned. The Floor is the minimum that system must contain. Above it, the leader dials up rigour based on risk profile, complexity, and stakes — and dials it down where adding rigour would only slow the team. Structure that enables speed is the goal; compliance theatre is the failure mode. Senior leadership is knowing what to add — and knowing what to refuse to add.

PMI Tailoring MSP · Tailoring principles · Contextual adoption

Context · A

Regulatory / Compliance-heavy

Formal compliance traceability into the Benefits Map and Decision Log
Regulator-language alignment in the Investment Thesis
Second-line risk function with veto rights at G2 and G4
Audit-ready evidence trail for every binding decision
Sponsor briefed on regulator escalation protocol before kickoff

Context · B

Multi-vendor / Integration-heavy

Vendor accountability matrix as an extension of the Charter
Joint architecture authority across vendors
Integration readiness as an explicit gate criterion at G3 and G4
Commercial interlock between contracts — no unilateral re-baseline
Master systems integrator role named — or explicitly absent and owned by the client

Context · C

High-change / High-impact on operations

Named change owner outside the programme team
Prosci-style change impact assessment per workstream
Readiness gates aligned to operational rhythm (peak avoidance)
Pilot or beta group with real users pre go-live
Change saturation review across adjacent programmes

Context · D

Data-heavy / Migration-led

Data owner and steward named at G1 — not delegated to the architect
Master data governance live before build
Source-to-target mapping signed off by source-system owner
Reconciliation thresholds and exception policy agreed
Decommissioning criteria for the legacy source

Context · E

Strategic / Board-visible

Quarterly board briefings — leader-authored, not vendor-authored
External assurance partner engaged at G1, not after a wobble
Benefits trajectory plotted vs case — not just status
Kill criteria reviewed at every board meeting

Context · F

Tactical / Low-strategic-stakes

Combined Working Group + Programme Board as a single forum
Lightweight Decision Log — captured in working forum minutes
Benefits cadence quarterly, not monthly
Resist the urge to dial governance up just because it's an option

Context · G

Cross-programme / Portfolio-coupled

Cross-programme dependency log, owned by portfolio lead
Capacity heatmap across operating teams maintained portfolio-wide
Sequencing decisions made at portfolio level
Single benefits register owner across the portfolio

Context · H

Public / Externally-visible

Public-facing comms strategy agreed at G1 — not in response to an event
FOI / disclosure exposure mapped for every binding decision
Ministerial / board / regulator briefing cadence pre-agreed
Reputational kill criteria treated alongside financial kill criteria
Crisis playbook signed off before go-live, not after

The test of a governance system is not how many meetings it holds. The test is whether the team can decide between meetings — and whether the decision will stick. Structure enables speed. Anything else is theatre. The point of governance

Industry calibration · What the leader reads differently

Industry Calibration.

Standards are universal. Their application is not. Eight industries, each with a distinctive funding logic, governance pattern, regulator/stakeholder geometry, and what the senior transformation leader looks for differently in that context.

Utilities

Water, energy, telco infrastructure. Regulator-driven funding cycles, asset-heavy, long horizons.

Read▾

What the leader reads differently

Regulator funding cycles set the investment rhythm. Programmes that don't align to the price-determination window are programmes that won't be funded. Asset lifecycles are long; operating-model debt compounds slowly but visibly. Field operations are real and unforgiving.

Floor artefacts to emphasise

Investment Thesis (anchored to regulatory price-determination outcome) · Benefits Map (with regulator-language overlay) · Accountability Charter (with field-operations representation).

Financial Services

Banking, insurance, wealth. Heavy regulation, multi-vendor, fast change-impact cycles.

Read▾

What the leader reads differently

Risk and control functions have real teeth — and right of veto. Conduct, prudential, and consumer protection regimes shape what "done" actually means. Customer outcome is a regulator question, not just a CX question.

Floor artefacts to emphasise

Decision Log (auditor-defensible) · Accountability Charter (with named control owners) · Risk Register · Outcome Dashboard with control-effectiveness view.

Healthcare

Hospitals, primary care, payer organisations. Patient outcomes, clinical governance, multi-clinician decision rights.

Read▾

What the leader reads differently

Clinical safety is non-negotiable; clinician adoption is harder than user adoption anywhere else. Decision rights sit with clinicians by professional accountability — not by org structure. The change-management cost is uniquely high.

Floor artefacts to emphasise

Accountability Charter (with clinical governance representation) · Risk Register (with clinical safety case overlay) · Stage Gates (with clinical sign-off at G3 and G4).

Government / Public Sector

Federal, state, local. Ministerial visibility, FOI, election cycles, public scrutiny.

Read▾

What the leader reads differently

Ministerial visibility is not sponsorship. Election cycles can re-baseline strategy with three months' notice. Public scrutiny means every decision is potentially newsworthy. Procurement frameworks shape what's even possible.

Floor artefacts to emphasise

Investment Thesis (anchored to citizen outcome) · Decision Log (FOI-defensible) · Accountability Charter (named SRO) · Benefits Map (with public-value framing).

Telecommunications

Carriers, MSOs, network operators. BSS/OSS layered, customer-base sensitivity, regulatory exposure.

Read▾

What the leader reads differently

BSS/OSS architecture is more layered than most enterprises understand. A retail-side change can fracture six back-end integrations. Churn-rate sensitivity makes customer experience and regulatory complaint volume genuine kill-criteria inputs.

Floor artefacts to emphasise

Accountability Charter (with BSS/OSS owners) · Risk Register · Benefits Map (with churn / NPS / margin overlay) · Stage Gates (with regression-test integrity criteria).

Retail / E-commerce

Multi-channel, peak-period sensitive, supply-chain integrated.

Read▾

What the leader reads differently

Peak trading windows are real and unforgiving. Change freezes block release cadence for months. The customer-facing front-end can be transformed faster than the back-end supply chain — and that asymmetry is where most retail transformations underdeliver.

Floor artefacts to emphasise

Stage Gates (with peak-trading windows as hard constraints) · Benefits Map (linked to conversion, throughput, and inventory turn) · Decision Log (releases pre-peak require kill-criteria readiness).

Manufacturing / Industrial

Plant operations, IT/OT convergence, capital-cycle funded.

Read▾

What the leader reads differently

OT systems carry safety and production consequences IT systems don't. Plant managers have real authority and a strong reason to resist anything that risks throughput. Capital-cycle funding means programmes are budgeted in years, not financial quarters.

Floor artefacts to emphasise

Accountability Charter (with plant manager / engineering authority) · Risk Register (with safety case) · Stage Gates (with planned-outage windows agreed upfront).

Higher Education

Universities, TAFE, professional education. Faculty governance, semester rhythms, public funding.

Read▾

What the leader reads differently

Academic governance is real and slow. Change between teaching periods is materially easier than during them. Public funding constraints sit alongside competitive private-funding pressures. Student experience is now a competitive differentiator.

Floor artefacts to emphasise

Accountability Charter (with faculty representation) · Stage Gates (aligned to inter-semester windows) · Benefits Map (with student-experience overlay).

The post-go-live spine · Discipline that compounds

Benefits Realisation.

The discipline that separates a programme from a portfolio result. Go-live is the start of benefits realisation, not the end of the programme. The leader who treats closure as completion is closing on the most important phase of the work. Systems do not deliver benefits — operating models do, and operating models are run by named people. The leader's job is to make sure those names exist, those people are equipped, and the tracking discipline survives the closure date.

PMI Benefits Realization Management Identify · Execute · Sustain MSP · Benefit Profiles · Benefit Realisation Plan

The three phases — what they actually mean

PMI's Benefits Realization Management framework names three lifecycle phases. Most enterprise practices stop at Execute. The leverage is in Sustain.

Phase	What it is	Owned by	Common failure
Identify	Benefits are named, sized, owned, traced to strategy.	Programme leader + benefit owners + sponsor	Benefits invented to clear investment committee; ownership left blank or assigned to "the programme."
Execute	Outputs are delivered, outcomes start to occur, benefits begin to land.	Programme leader hands to benefit owners progressively	Programme closes on output delivery; benefits handover is implicit; tracking lapses.
Sustain	Benefits are tracked over time, variances explained, the operating model is adjusted, follow-on investment is made or retired.	Operational benefit owners + portfolio governance	Tracking dies at +6 months; lessons absorbed by attrition; the next funded programme repeats the pattern.

The realisation cadence

The minimum. Adjust intervals to the operational cycle, but never drop the cadence to less frequent than quarterly within the first 24 months post go-live.

Milestone	What happens	What the leader is looking for
Pre go-live (−4 weeks)	Baselines locked. Tracking owner confirmed. Measurement source confirmed. Calendar invites sent for the next 24 months.	That the baseline is real and reproducible, and the calendar discipline starts before the programme closes.
+30 days	Stabilisation review. Hyper-care issues triaged. Initial leading indicators checked.	Leading indicators (usage, throughput, error rates) — early signals of a benefit at risk.
+3 months	First realisation review. Benefits Map walked end-to-end with the operational owner.	That the operating-model change has actually occurred — not just that the system is live.
+6 months	First benefits variance analysis. Trend vs target per benefit.	The shape of the curve, not the point estimate. A benefit late but in the right direction is healthier than one on track for the wrong reason.
+12 months	Realisation gate. Each benefit assessed: realised · in train · at risk · failed.	That at-risk benefits have action plans owned by the operational owner — not by the closed programme team.
+18 months	Strategic-level review. Investment thesis vs reality. Lessons for portfolio.	Whether the original bet paid off, and what it teaches the next funded programme. The highest-leverage portfolio learning moment.
+24 months	Sustainment review. Hand off to BAU or commission follow-on.	That the benefit is now structurally embedded — or the gap is being addressed by a named follow-on investment.

A benefits register that survives the closure date is a portfolio asset. A benefits register that dies at closure is the receipt for a programme that didn't compound. The cadence is the practice. What outlasts the programme

The variance conversation · four categories

Most benefits don't land on target. They land near target, late, on a different shape, or in a different place. The discipline is not to demand precision; the discipline is to make the variance conversation routine, structured, and non-punitive.

Realised.Benefit landed at or above target. The action is to embed structurally — process, KPI, performance review — so realisation persists past the people who built it.

In train.Benefit is trending toward target on the right shape. The action is to maintain cadence; resist the urge to declare victory early.

At risk.Benefit is tracking late, flat, or below curve. The action is a named recovery plan owned by the operational owner with a review date inside 60 days.

Failed.Benefit will not realise as forecast. The action is honest naming, lessons extracted, and a portfolio-level decision: write down, restructure, or commission follow-on.

Operating-model debt

The single most underrated artefact in transformation. Operating-model debt is everything the programme intended to retire but didn't — the workaround that stayed live, the parallel process that never closed, the spreadsheet that "just for a quarter" became permanent, the role meant to be reshaped and wasn't. Debt accumulates silently and compounds. The leader who tracks operating-model debt as a register — with named owners and retirement dates — is the leader whose next programme inherits less.

Operating-model debt · the inheritance register
ID	What stayed	What was meant to retire it	Owner	Retirement plan	Cost-of-carry
OMD001	e.g. monthly reconciliation spreadsheet	e.g. PPM integration	Finance Business Partner	action + due date	FTE-days/month

A programme that closes without naming its operating-model debt has not closed. It has handed forward a problem the next leader will inherit — usually without the funding to solve it. The honest closure

Working prompts · For real leader workflows

Prompt Library.

Ten prompts the transformation leader can run against any modern LLM. Each is field-tested on real programmes. They are not a substitute for judgement — they are scaffolding that makes the leader's first draft sharper, faster, and more rigorous. Customise with your context in brackets; copy with the button.

framingv1.0

Investment Thesis drafter

Turn a rough programme idea into a one-page Investment Thesis with the bet, leverage, kill criteria.

Open ⌄

Use when

A programme is being mooted but the strategic case isn't sharp. Run before the business case opens.

Prompt

Draft a one-page Investment Thesis for the following programme. Programme: [NAME] Sponsor: [NAME] Why it's being raised now: [CONTEXT] What we think the bet is: [ROUGH DESCRIPTION] Linked strategy / capability roadmap: [LINK or PASTE] Output the thesis in these sections, each no more than 3 sentences: 1. THE BET — what we believe will be true 12 months after closure 2. WHY NOW — what forces this in this cycle, not next 3. STRATEGIC ANCHOR — the enterprise strategy or capability this serves 4. LEVERAGE CREATED — what stops, retires, simplifies, compounds 5. EXPLICITLY NOT DOING — adjacent problems and why they're out of scope 6. ACCOUNTABLE SPONSOR — named individual whose calendar reflects this 7. KILL CRITERIA — what evidence would cause us to stop 8. DECISION RULES — what we optimise for when trade-offs appear Rules: — Plain English. No vendor names in the bet itself. — If the input is too thin to draft a section, name what's missing. — Output should fit on one page in a 12pt font.

benefitsv1.0

Benefits Map generator

From outputs to outcomes to benefits to strategic objectives, with named owners.

Open ⌄

Use when

Drafting or stress-testing the benefits side of a business case. Forces the trace from output to strategy.

Prompt

Build a benefits map for the following programme. Programme: [NAME] Outputs we plan to ship: [LIST] The case as drafted: [PASTE or LINK] Operational owners under consideration: [NAMES, with roles] Output a single table: OUTPUT · OUTCOME · BENEFIT · STRATEGIC OBJECTIVE · OWNER · BASELINE · TARGET · CADENCE Rules: — Every benefit must trace to a strategic objective. If it doesn't, flag it. — Every benefit must have a named operational owner — not "the programme." — Baseline and target must be plausible to measure. If a metric can't be measured, say so. — Flag any output that produces no measurable benefit. After the table, list: — The 3 benefits most at risk of not realising and why — The 2 outputs that look like benefits but aren't — The owner role that is over-loaded across multiple benefits

decisionv1.0

Decision Pack one-pager

For any binding decision: options, recommendation, trade-offs, reversibility.

Open ⌄

Use when

Anywhere a decision is going to a Programme Board or sponsor. Replaces the 30-page paper that no-one reads.

Prompt

Draft a one-page decision pack for the following decision. Decision: [STATE THE DECISION] Context: [WHY IT'S BEING MADE NOW] Options under consideration: [LIST WITH KNOWN PROS/CONS] Constraints: [TIME / MONEY / POLITICAL / TECHNICAL] Reversibility: [EASY / HARD / LOCKED] Output in this format: THE DECISION (one sentence — what we are deciding) THE OPTIONS (max 3, each with one-line description) THE RECOMMENDATION (named option, one sentence why) THE TRADE-OFFS WE ARE ACCEPTING (3 bullets — what we're giving up to choose this) THE EVIDENCE BEHIND IT (3 bullets — what supports the recommendation) THE KILL CRITERIA (what evidence would cause us to reverse, if reversible) THE ASKS OF THE BOARD (what we need them to do — approve, escalate, fund, signal) Rules: — Plain English. No jargon. — Honest framing. If the recommendation is weak, say so. — One page maximum.

framingv1.0

18-month pre-mortem

Imagine the programme failed. Write the post-mortem. Use as the design brief.

Open ⌄

Use when

Before G1 (Investment), or as a hard checkpoint at G2. Surfaces failure modes while they're cheap to fix.

Prompt

You are writing the post-mortem of a transformation programme that failed to realise its benefits 18 months after closure. Use the inputs to draft an honest narrative. Programme: [NAME] The bet: [FROM THE INVESTMENT THESIS] Key stakeholders: [NAMES + ROLES] Known risks today: [LIST] Capacity assumptions: [LIST] External dependencies: [LIST] Write the post-mortem in three sections, each one paragraph: 1. WHAT WE GOT WRONG — the central misjudgement 2. WHY IT FAILED — the sequence of decisions, omissions, and assumptions that compounded 3. WHO COULD HAVE STOPPED IT, AND WHEN — name the gate, the meeting, the moment End with three "fix it now" actions the leader should take in the next two weeks to make this future less likely. Be honest. The point is to surface failure modes while they are cheap to address. Do not soften the language.

governancev1.0

Governance Operating Model designer

Forums, cadence, decision scope, escalation — sized to the programme.

Open ⌄

Use when

Setting up programme governance from scratch, or auditing existing governance for theatre.

Prompt

Design a governance operating model for the following programme. Programme: [NAME] Complexity (low/med/high): [CHOICE] Multi-vendor: [Y/N — if Y, list vendors] Regulator/audit exposure: [LIST or NONE] Sponsor seniority: [ROLE] Cross-programme dependencies: [LIST or NONE] Output: 1. FORUMS (max 4) — name, decision scope, cadence, attendees, what they explicitly do NOT decide 2. ESCALATION — when a forum can't decide, what happens, with timeframe 3. DECISION-RIGHTS MATRIX — for these classes: Investment, Scope, Vendor, Architecture, Change, Go-live readiness, Benefits sign-off, Closure 4. THE "ANTI-PATTERNS" — 3 governance failures most likely on this programme, and how the design above prevents them Rules: — No forum without a clear decision scope. — No forum more frequent than its decisions warrant. — Resist the urge to dial up governance just because the programme is high-profile.

vendorv1.0

RFx critique

Stress-test an RFx or vendor response against the Investment Thesis and kill criteria.

Open ⌄

Use when

Pre-issue (test the RFx) or post-response (test the vendor's answer). Forces traceability back to the bet.

Prompt

Critique the following RFx / vendor response against the programme's Investment Thesis and kill criteria. Investment Thesis: [PASTE] Kill criteria: [PASTE] RFx document or vendor response: [PASTE or LINK] Output: 1. ALIGNMENT — for each section of the RFx/response, rate alignment to the thesis: STRONG / WEAK / ABSENT — with one-sentence justification. 2. WHAT THE RFx ASSUMES THAT MAY NOT HOLD — 5 assumptions baked in that should be tested. 3. WHAT'S MISSING — 5 things a senior transformation leader would expect to see that aren't there. 4. THE COMMERCIAL EXPOSURE — where the scope is ambiguous enough that the contract will need to absorb risk that should sit with the buyer. 5. THE THREE QUESTIONS — for evaluation panel or vendor — that will most efficiently surface real capability vs sales narrative. Be honest. The point is to protect the programme, not to praise the document.

gatev1.0

Stage-gate readiness audit

Check whether a programme has actually earned the right to pass the next gate.

Open ⌄

Use when

Before a gate paper goes to the board. Surfaces what's not really ready under the readiness narrative.

Prompt

Audit the following programme's readiness for the next stage gate. Programme: [NAME] Gate being approached: [G0 / G1 / G2 / G3 / G4] Gate entry criteria (from the standard): [PASTE] Current state evidence: [PASTE STATUS / DECISION LOG / RAID / BENEFITS MAP] Output: 1. CRITERION-BY-CRITERION — for each entry criterion, rate: MET / PARTIAL / NOT MET, with one-sentence evidence cited. 2. THE THREE WEAKEST AREAS — and what needs to happen in the next 14 days to address each. 3. THE FOUR GATE QUESTIONS — answer each honestly: — Has the bet changed? — Are the named owners still here? — Has the operating-model change progressed? — Do the kill criteria still hold? 4. THE RECOMMENDATION — pass / pass with conditions / hold / fail — with the conditions or remediation needed. Be honest. A gate passed before evidence is a future regret.

benefitsv1.0

Benefits health check

At a +3 / +6 / +12 month review, classify each benefit and produce the leader's variance script.

Open ⌄

Use when

Running any post-go-live realisation review. Turns raw data into a structured variance conversation.

Prompt

Classify the following benefits portfolio for a realisation review. Programme: [NAME] Review milestone: [+3m / +6m / +12m / +18m / +24m] Benefits Map: [PASTE or LINK] Current measurements: [PASTE] Notes from operational owners: [PASTE] For each benefit, output: NAME — OWNER — BASELINE — TARGET — CURRENT — TREND (↑/→/↓) — CLASSIFICATION (Realised / In train / At risk / Failed) — ACTION Then write the leader's variance script for the review meeting: 1. WHAT'S WORKING (1 paragraph, name the realised + in-train benefits) 2. WHAT'S DRIFTING (1 paragraph, name the at-risk items and what the next action is) 3. WHAT WE'RE NAMING HONESTLY (1 paragraph, the failed items and the portfolio-level decision being recommended) 4. WHAT THE BOARD SHOULD DO (3 bullets, asks of the room) Rules: — Honest framing. No spin. — Variance is normal. Theatre is not.

boardv1.0

Board read-out

Turn a complex programme position into a 5-minute board narrative.

Open ⌄

Use when

Preparing for quarterly board, ministerial briefing, or sponsor steering. Replaces the slide-thrash.

Prompt

Draft a 5-minute board read-out for the following programme. Programme: [NAME] Audience: [BOARD / EXEC / MINISTERIAL / SPONSOR] Investment thesis: [PASTE] Current status (delivery, decisions, benefits, RAID): [PASTE] Material changes since last read-out: [PASTE] Output a single page in this structure: 1. WHAT'S CHANGED (1 paragraph — material movement since last read-out) 2. WHERE WE ARE AGAINST THE BET (1 paragraph — still believe / believe with caveats / no longer believe) 3. WHAT WE'RE DECIDING NEXT (3 bullets — open binding decisions and dates) 4. WHAT WE NEED FROM THE BOARD (max 3 — explicit asks) 5. WHAT WE'RE WATCHING (top 3 risks named, with mitigation owners) Rules: — No vendor names unless commercially material. — No status colours without numbers underneath them. — Plain English. A non-specialist board member should understand the bet and where we are against it.

portfoliov1.0

Cross-programme heatmap

For portfolio leaders: which programmes are healthy, which need intervention, which to kill.

Open ⌄

Use when

Portfolio review. Turns disparate programme reports into a single decision-ready heatmap.

Prompt

Produce a portfolio heatmap for the following programmes. Programmes: [LIST WITH BRIEF DESCRIPTIONS] For each programme, evidence: [investment thesis link · current status · benefits position · key risks · decision velocity] Output one table with columns: PROGRAMME · ARCHETYPE · STRATEGIC ANCHOR · STAGE · BET HEALTH (Strong/Weak/Failed) · BENEFITS TRAJECTORY (On/Drifting/At risk/Failed) · DECISION VELOCITY (Healthy/Slow/Stalled) · OVERALL (Green/Amber/Red/Stop) · RECOMMENDED ACTION Then write three paragraphs: 1. PORTFOLIO HEALTH — overall position of the portfolio 2. THE INTERVENTION LIST — which 2-3 programmes need leader attention this quarter, and why 3. THE STOP LIST — which programmes should be wound down, with the evidence base Be honest. The point is to free capital and capacity, not to defend the portfolio's history.

closurev1.0

Closure pack

Honest closure — what shipped, what didn't, what's owed to the next leader.

Open ⌄

Use when

Programme closure. Forces an honest hand-over to BAU and to the next funded programme.

Prompt

Draft a closure pack for the following programme. Programme: [NAME] Investment thesis: [PASTE] What we shipped: [LIST] Benefits position at closure: [PASTE] Operating-model debt items: [LIST] Lessons for the portfolio: [PASTE] Output: 1. HONEST STATEMENT — one paragraph: did this programme deliver against its bet? If yes, name the evidence. If no, name what was missed and why. 2. WHAT'S BEEN HANDED OVER — list of named operational owners, benefits, residual risks, and tracking cadence. 3. OPERATING-MODEL DEBT REGISTER — items that stayed, who owns retirement, by when. 4. LESSONS FOR THE NEXT PROGRAMME — 3 lessons that should change how the next funded programme is shaped. 5. WHAT WE STILL OWE — a single sentence: what does the closed programme still owe the business, and who owes it. Rules: — Honest framing. If the thesis was wrong, name the moment it became clear. — Plain English. The pack is read by the next sponsor.

How the practice runs · Cadence

The Operating Rhythm.

Standards stay alive only if the practice runs them. The artefacts in §01 are the components of an execution system; the cadences below are how that system actually runs. Each is owned by a named role, has a clear purpose, and an explicit "what we don't do here" boundary. Without them, the field guide is a document no-one opens. With them, it becomes the operating discipline a team can run — programme after programme.

PMI Governance Lifecycle Mgmt MSP · Programme Office · Learning from Experience

Weekly · 45 min

Sponsor sync

Transformation leader + sponsor

Held by the leader, not the programme manager. The conversation is about the bet, the kill criteria, the political climate, and the decisions the sponsor needs to make this week. Not a status update.

Fortnightly · 90 min

Steering committee

Per Governance Operating Model

Decisions, not noting. Every meeting opens with the four gate questions. Closes with decisions made this period and decisions still owed. The Decision Log is updated live in the room.

Monthly · 60 min

Benefits review

Leader + benefit owners + sponsor

Begins pre go-live, runs for 24 months past closure. The Outcome Dashboard is the artefact. The conversation is about the variance. Operating-model debt is reviewed alongside benefits.

Quarterly · 2 hrs

Portfolio review

Portfolio lead + transformation leaders

The cross-programme heatmap is the artefact. Sequencing, capacity, and stop-list decisions made here — not in individual programme governance. The forum where the portfolio actually holds itself accountable.

Half-yearly · half day

Lessons review

Across programmes, with portfolio lead

Closed programmes reviewed for value realised — at +12 / +24 months, not at closure. Failed programmes named honestly. Lessons elevated to standards. Standards that didn't survive contact retired publicly.

The artefacts are not the practice. The rhythm is the practice. A leader running the rhythm — week, fortnight, month, quarter, half — is a leader compounding discipline programme after programme. What the rhythm builds