Programme Reporting for Steering Committees

What Steering Committees Actually Need

A steering committee exists to make strategic decisions, remove organisational blockers, and ensure the programme stays aligned with business objectives. They don't need:

• Detailed sprint-level progress
• Technical architecture discussions
• Comprehensive risk registers (they need the top 3-5)
• Proof that the programme team is working hard

They need:

• "Are we on track?" (Clear RAG with honest assessment)
• "What could derail us?" (Top risks with mitigation status)
• "What do you need from us?" (Specific decisions or resources)
• "Are we still investing in the right thing?" (Benefits and strategic alignment)

The One-Page Programme Report

Structure

Section 1: Executive Summary (3 lines)

• Overall RAG status with one-sentence justification
• Key achievement since last steering
• Key concern or decision needed

Section 2: Milestone Tracker

• Table of programme milestones with planned date, forecast date, RAG, and owner
• Only show milestones due in the next 90 days (not the full programme plan)
• Highlight any milestone that has moved since last steering

Section 3: Financial Summary

• Budget: Approved vs Actual vs Forecast at Completion
• Variance: % over/under with brief explanation
• Contingency: Used vs Remaining
• One line: "On budget" or "£X over/under — [reason]"

Section 4: Top Risks and Issues

• Maximum 5 items
• For each: Description, Impact, Mitigation, Owner, Status
• Highlight any that are new since last steering or have escalated in severity

Section 5: Decisions Required

• Specific decisions needed from the steering committee
• For each: Context, Options, Recommendation, Deadline
• Maximum 3 decisions per meeting (more than that = poor pre-work)

Section 6: Benefits Progress (Quarterly)

• Expected benefits vs early indicators
• Adoption metrics if relevant
• Any benefits at risk

Formatting Rules

• One page maximum (A4 or letter, landscape works well for tables)
• RAG colours used consistently (same definitions every time)
• No jargon — write for a business audience, not a technical one
• Numbers over narratives where possible
• Trend indicators (↑ ↓ →) for metrics that change over time

Running the Steering Meeting

Before the Meeting

• Send the one-page report as pre-read 48 hours in advance
• For each decision item, prepare a separate decision paper (1 page: context, options, recommendation)
• Brief the sponsor privately on any sensitive items (no surprises in the room)
• Confirm attendance — if key decision-makers can't attend, consider rescheduling

During the Meeting (60 min)

1. Programme status walk-through (10 min): Walk the one-page report. Don't read it aloud — they've read the pre-read. Highlight what's changed since last time. 2. Risk and issue discussion (15 min): Focus on items that need steering input. "This risk has escalated because [X]. Our mitigation is [Y]. We need [Z] from you." 3. Decisions (20 min): Present each decision with options and recommendation. Facilitate discussion. Get a clear yes/no/defer. 4. Strategic alignment check (10 min): "Given what we know now, is this programme still the right investment? Any strategic changes we should be aware of?" 5. Actions and next steps (5 min): Summarise decisions made, actions assigned, next meeting date.

After the Meeting

• Circulate decision log within 24 hours
• Update programme plan to reflect any decisions
• Communicate relevant decisions to project teams
• Begin work on any actions assigned to the programme team

Managing Difficult Steering Conversations

When the news is bad

• Don't hide it. Don't minimise it. Don't bury it on page 3.
• Lead with the problem: "We have a significant issue that needs your attention."
• Quantify the impact: "This will delay the programme by 6 weeks and cost an additional £50K."
• Present your plan: "Here's what we're doing about it. Here's what we need from you."
• Never surprise the sponsor in the meeting — brief them privately first.

When stakeholders disagree

• Present the trade-off clearly: "We can do A (stakeholder 1's preference) or B (stakeholder 2's preference). Here's the impact of each."
• Provide your recommendation with rationale
• If they can't decide, propose a deadline: "We need this decision by [date] to avoid [impact]."
• Document the decision and the rationale — this prevents re-litigation later.

When the committee wants to micromanage

• Redirect to outcomes: "I appreciate the interest in the technical approach. The key question for steering is: are we confident this will deliver the milestone by June?"
• Offer detail offline: "I'm happy to walk through the technical details after the meeting with anyone who's interested."
• Protect the team: "The delivery team has the technical expertise to make this decision. What they need from steering is [specific decision at the right level]."

Measuring Steering Effectiveness

• Decision rate: Decisions made per meeting. Target: at least 1 per meeting. Zero decisions = the meeting was unnecessary.
• Decision cycle time: Days from "decision needed" to "decision made." Target: <10 business days (including one steering cycle).
• Action completion rate: % of steering-assigned actions completed by deadline. Target: >90%.
• Meeting duration: Consistently within timebox? If meetings regularly overrun, the agenda is too full or pre-reads aren't being read.
• Attendance: Key decision-makers present. Target: >80%. Low attendance = low perceived value.

---

Download the [Stakeholder Update template](/templates) for a ready-to-use programme reporting format for steering committees.