A steering committee update for a transformation program should start with what the committee must do today: each decision needed, with options, a recommendation, an owner and a deadline. Below that come overall program RAG with its trend, status by workstream, benefits as baseline, target and actual, and the cross-functional blockers only an executive can clear. Copy the plain-text template below, fill it from your workstream leads' evidence, and close the meeting by reading back decisions and owners.
What goes in a steering committee update for a transformation program?
A transformation steering committee update needs these parts, in this order: decisions needed, overall RAG with trend, status by workstream, benefits against baseline and target, adoption and readiness, blockers needing executive help, risks that moved, and actions carried from the last meeting. Decisions go first because the committee exists to decide things the program team cannot.
That ordering follows the governance guides rather than the slide shops. Digital Advisory's agenda template says a steering committee exists to make decisions above the team's authority, remove obstacles in members' own organisations, and change direction when the evidence says to, and it covers delivery as "exceptions only". Mustavant's transformation guide says delivery status stays in the pre-read. This update is that pre-read: something the committee can read before the meeting, so the time in the room goes to decisions.
Three checks before you send it:
- Every decision has an owner and a date.
- Every red or amber workstream says what is off plan and who is fixing it.
- Every blocker names the executive whose function it sits in.
What does the template look like?
The steering committee update template is a plain-text pre-read with numbered sections: decisions needed, overall status, workstream status, benefits, adoption and readiness, blockers needing executive help, risks that moved, and actions from the last meeting. Plain text pastes into email, a document, or slide notes, and every bracket marks something you fill in.
Keep every section in every update. When a section is empty, write "none this period" rather than leaving it blank, so the committee knows you checked.
STEERING COMMITTEE UPDATE: [Program name]
Meeting: [date] | Prepared by: [name] | Period: [start date] to [end date]
1. DECISIONS NEEDED TODAY
D1. [Decision question, one sentence ending in a question mark]
Options: A) [option] B) [option] C) [do nothing / defer]
Recommendation: [option] because [reason, one sentence]
Cost of waiting: [what slips, costs more, or is lost if not decided today]
Owner: [executive name] | Needed by: [date]
D2. [same structure]
2. OVERALL PROGRAM STATUS
RAG: [Green / Amber / Red] | Trend since last meeting: [Improving / Stable / Worsening]
Summary: [Where the program stands against the next gate, and the single biggest issue]
Next gate: [gate name] on [date] | Confidence: [On track / At risk / Will miss]
3. STATUS BY WORKSTREAM
[Workstream] | RAG [ ] | Trend [ ] | Next milestone: [milestone, date] | Exception: [what is off plan, or none]
[Workstream] | RAG [ ] | Trend [ ] | Next milestone: [milestone, date] | Exception: [ ]
4. BENEFITS
Benefit | Measure | Baseline | Target (by [date]) | Actual to date | Forecast | Note
[benefit] | [unit] | [value] | [value] | [value] | [value] | [reason actual differs]
5. ADOPTION AND READINESS
[Indicator] | Planned [value] | Actual [value] | Trend [ ] | Note [ ]
6. BLOCKERS NEEDING EXECUTIVE HELP
B1. [Blocker] | Sits in: [function] | Help needed: [specific action]
From: [executive] | By: [date] | If unresolved: [workstreams and milestones affected]
7. RISKS THAT MOVED
[Risk] | Change: [New / Likelihood up / Impact up / Closed] | Response: [action] | Owner: [name]
8. ACTIONS FROM LAST MEETING
[Action] | Owner: [name] | Due: [date] | Status: [Done / Late, new date [date]]
How should you define red, amber and green?
Define RAG by what the workstream needs from the committee, not by how the lead feels. Green means on plan for the next gate with no help needed. Amber means off plan, with a recovery the workstream owns and can deliver. Red means off plan, and recovery needs a committee decision or executive help.
Write these definitions at the top of your first update and keep them unchanged, so a colour means the same thing every time. SlideModel's guide lists status labels such as on track, delayed and at risk; agreeing what each one means in your program is what makes them useful to the committee.
Add a trend to every colour. "Amber, improving" and "Amber, worsening" call for different conversations. Compare against the last update, not against how the program felt a while ago.
Two rules that keep colours honest:
- A red workstream always has a matching entry under decisions needed or blockers. If it does not, either the colour is wrong or the ask is missing.
- Overall program RAG is never greener than the worst workstream on the critical path to the next gate.
How do you report benefits against baseline and target?
Report each transformation benefit as one row: the measure, the baseline before the change, the target and its date, the actual to date, and your forecast. The note column explains any gap in a sentence. Benefits keep the committee focused on why the program exists, not only whether tasks are finished.
Steps to set this up:
- Take the benefits from the approved business case. Do not add new ones in the status report.
- Agree one owner per benefit, usually the business owner, not the program team.
- Record the baseline once and freeze it. If no baseline was measured, write "baseline not yet measured" and add an action to measure it.
- Before each meeting, ask each benefit owner for actual and forecast, and the evidence behind them.
- When forecast falls below target, add a decision or blocker that explains what would close the gap.
Put adoption and readiness next to benefits. Benefits usually depend on people using the new process or system, so indicators such as people trained, sites or teams live, or process compliance tell the committee whether the benefit forecast is believable. Mustavant describes an outcome health block that reviews the benefits trajectory at the committee; this section is where that trajectory shows up.
How do you write a decision request the committee can answer?
A decision request for a steering committee states one question, the options including doing nothing, your recommendation with its reason, the cost of waiting, the executive who owns it, and the date it is needed by. The committee should be able to say yes to the recommendation without asking you anything first.
Mustavant's decision paper uses the question, options, recommendation, cost of delay, and the exact approval requested, and holds that every item closes with a decision or a dated commission, never "noted". SlideModel recommends showing options with their pros and cons, and lists presenting problems without solutions as a common pitfall.
Wording you can use as is:
We are asking the committee to decide [question] today. We recommend [option] because [reason]. If we wait until [next meeting date], [consequence]. [Executive] owns this decision.
If the committee cannot decide, do not leave it open. Digital Advisory advises minuting precisely what evidence is missing, who brings it, and by when. Write that into your actions list for the next update.
What does a filled-in transformation example look like?
The filled-in transformation example below shows an operating model program with several workstreams, written at the tone and level of detail a steering committee can act on. The example is illustrative, so placeholders stand where your own figures, names and dates go. Each line states a fact, a consequence, or an ask rather than recounting activity.
STEERING COMMITTEE UPDATE: [Operating model transformation]
Meeting: [date] | Prepared by: [program lead] | Period: [date] to [date]
1. DECISIONS NEEDED TODAY
D1. Should [region] go live at the [next gate] or wait for the following release?
Options: A) Go live as planned with manual workaround for [process]
B) Delay [region] to [later date] C) Defer the decision
Recommendation: A, because the workaround is tested and B delays
[benefit] realisation by [period].
Cost of waiting: cutover rehearsal for [region] cannot be scheduled.
Owner: [COO] | Needed by: [date]
2. OVERALL PROGRAM STATUS
RAG: Amber | Trend: Improving
Summary: On track for [gate] except [region] cutover, which depends on D1.
Data migration recovered after the slip reported at the last meeting.
Next gate: [gate] on [date] | Confidence: At risk until D1 is decided
3. STATUS BY WORKSTREAM
[Process redesign] | Green | Stable | [Sign-off of target process, date] | none
[Systems] | Amber | Improving | [Integration test complete, date] | [interface] late, recovery owned
[Data migration] | Green | Improving | [Final load rehearsal, date] | none
[People and change] | Red | Worsening | [Training wave, date] | trainers not released, see B1
4. BENEFITS
[Cost to serve] | [unit] | [baseline] | [target by date] | [actual] | [forecast] | below target until [region] live
5. ADOPTION AND READINESS
[Users trained] | Planned [value] | Actual [value] | Worsening | blocked by B1
6. BLOCKERS NEEDING EXECUTIVE HELP
B1. Trainers from [function] not released for [training wave]
Sits in: [function] | Help needed: release [number] trainers for [period]
From: [function head] | By: [date] | If unresolved: [People and change]
milestone and [region] go-live both slip
7. RISKS THAT MOVED
[Peak trading overlaps cutover] | Likelihood up | Response: confirm freeze window | Owner: [name]
8. ACTIONS FROM LAST MEETING
[Confirm data owner for [domain]] | [name] | [date] | Done
How do you close the meeting?
Close the steering committee by reading back each decision, its conditions, and its owner while everyone is still in the room, then each blocker and the executive who accepted it with a date. Digital Advisory reserves the final slot for exactly this read-back and for agreeing the message going upward.
A closing script you can read aloud:
Before we finish, here is what we agreed. On [D1], we decided [option], with [condition], owned by [name]. On [B1], [name] will [action] by [date]. [D2] is not decided; [name] brings [missing evidence] by [date]. Have I missed anything?
Send the same list in writing soon after, and copy it into section 8 of the next update so follow-through is visible.
When does this template not fit?
This template suits programs with several workstreams and a committee that meets to decide. It fits less well early in a program, when there may be no actuals for benefits yet, and for committees that want a slide deck. In both cases keep the structure and adapt the format rather than dropping sections.
Early on, show benefits with baseline and target only and say when actuals will start. If the committee expects slides, put each numbered section on one slide in the same order, and keep the text version as the pre-read. If an update has no decisions, say so plainly at the top; Digital Advisory goes further and says no decisions needed means the meeting should be cancelled.
How do you keep the update easy to produce each cycle?
Keep the steering committee update easy to produce by collecting evidence from workstream leads in the same structure every cycle, rather than rewriting it from memory. Ask each lead for their row, their exception, and any help they need, ahead of the date you send the pre-read, and keep actions in one running list.
A short request you can send to workstream leads:
For the [date] steering committee, please send your workstream's RAG, trend, next milestone, and any exception, with the evidence behind it. If you need a decision or help from an executive, write it as: what you need, from whom, by when, and what slips if it does not happen.
When the replies come in, check that each red row has a matching decision or blocker before you assemble the pre-read.