The most common source of delivery failure in mid-market programme management is not poor execution on the ground. It is the gap between when a project team identifies a decision they need and when that decision actually gets made. In organizations we work with, that gap routinely runs two to four weeks — the time required to prepare a paper, schedule a steering committee, wait for quorum, debate context that should have been pre-read, and get sign-off. Multiplied across a 12-month programme, governance latency of this kind can consume more calendar time than any other single factor. The project team is not slow. The governance structure is.

Why most governance structures are built to block, not enable

Steering committees in mid-market organizations are typically assembled by organizational logic rather than project logic. The CFO sits on it because the project has a budget. The VP of IT sits on it because there is a technology component. The COO sits on it because operations will be affected. Legal is added because someone raised a risk flag. The result is a committee of eight to twelve people — none of whom have the same information baseline, several of whom have conflicting priorities, and at least one of whom will miss every second meeting.

This structure creates three specific failure modes. First, the committee cannot achieve quorum on the decisions that actually matter, because the relevant authority is always distributed across members who are not simultaneously available. Second, meetings devolve into status briefings rather than decision forums, because members who missed the last session need to be brought current before they can engage. Third, the project team learns quickly that the committee is not a reliable source of timely decisions, and begins to escalate less — which means risks accumulate undisclosed until they become crises.

The design fix is not to reduce oversight. It is to be explicit about what the committee is actually for, who needs to be on it to fulfil that purpose, and how decisions flow through it on timescales the project can absorb.

Right-sizing the steering committee: membership and authority

The first principle of effective governance design is that every person on a steering committee must either hold a decision right the project needs, or hold accountability for an outcome the project affects. Neither condition alone is sufficient. A committee member who holds decision authority but has no accountability for delivery outcomes will prioritize other demands. A committee member who has accountability but lacks the authority to commit resources or resolve cross-functional conflict is window dressing.

In practice, for most mid-market projects — ERP implementations, operational restructures, technology deployments, M&A integrations — the effective steering committee is three to five people. Typically: an executive sponsor who holds budget authority and organizational credibility, one or two business owners who will live with the outcomes and can commit their functions, and a finance representative who can ratify material budget variances. Legal, HR, and other functions attend when agenda items require them; they are not standing members.

The second principle is explicit decision authority. At project initiation, the steering committee should agree on and document the categories of decision it will make, the threshold below which the project manager has delegated authority to decide, and the timeline within which the committee commits to respond to escalations. In our experience, organizations that document this at the outset — even in a half-page governance schedule — spend materially less time in ambiguity disputes during delivery.

The table above is illustrative. The specific thresholds matter less than the fact that they are agreed, written down, and known to both the project team and the committee before work begins.

The information pack that enables decisions in 90 minutes

Most steering committee papers are written to demonstrate rigor, not to enable decisions. They run to 20 or 30 pages. They include background sections that informed committee members do not need and uninformed members cannot absorb in a meeting. They are circulated the morning of the meeting, or occasionally the evening before. The committee chair opens the session by asking whether everyone has had a chance to read the paper, and the answer is always mixed.

The information pack that enables genuine decisions in a single session has a different design. It is short — typically five to eight slides or pages for a standard monthly committee meeting. It is structured around decisions and risks, not progress. It is circulated at least 48 hours in advance, with a standing expectation that members arrive having read it. And it is honest: it says what is behind schedule, what the team does not yet know, and what it is asking the committee to do.

The structure we recommend for each steering committee pack is as follows:

1. Decisions required this session: A single page listing each decision the committee needs to make, the options under consideration, the project team’s recommendation, and the consequence of not deciding today. This goes first, not last.
2. Programme status summary: A one-page RAG (Red/Amber/Green) status across workstreams, with a brief narrative on any status changes since the last session. No more than a page.
3. Risk and issue register summary: Top five risks by severity, with current mitigation status and any escalation requests. Not the full register — a curated view.
4. Financial position: Actual versus budget by phase, forecast to completion, and any variances requiring committee endorsement.
5. Decisions made since last session: A brief log of decisions made under delegated authority, for committee visibility without requiring ratification.

The session itself should be structured to match. The first 15 to 20 minutes address each decision item. The remaining time covers risks and issues requiring committee direction, and a brief programme update. If the pre-read has been done, 90 minutes is sufficient for a well-run steering committee — and many sessions can run shorter.

Escalation pathways that bypass committee latency

Even a well-designed steering committee meets monthly in most mid-market environments. A programme running at pace generates decisions that cannot wait 30 days. The governance design must account for this explicitly.

Pre-approved escalation pathways are the mechanism. At project initiation, the steering committee agrees on a protocol for out-of-cycle decisions: which categories of decision can be made by the executive sponsor alone, without a full committee session; how the project manager reaches the executive sponsor for an urgent decision; and what constitutes an acceptable turnaround time. In our experience, agreeing on a 48-hour response commitment for sponsor-level escalations — in writing, at the outset — eliminates the vast majority of governance bottlenecks that would otherwise require calling emergency committee meetings.

For decisions that genuinely require committee input but cannot wait for the next scheduled session, a lightweight asynchronous mechanism works well: a one-page decision brief circulated by email, with a stated deadline for responses and a default outcome if quorum does not respond. The default outcome should be conservative — typically “no change” — to discourage passive non-engagement. Committee members who disagree with the default are motivated to respond.

What does not work is leaving escalation pathways undefined and relying on project managers to navigate ad hoc. This creates inconsistency across projects, teaches delivery teams that escalation is politically risky, and concentrates decisions in whoever is most accessible rather than whoever holds the right authority.

Matching governance cadence to project risk level

Not every project needs monthly steering. Not every project can survive with monthly steering. The cadence should be set at initiation based on a small number of risk factors: timeline compression (projects under six months typically need fortnightly governance), budget materiality relative to organizational scale, number of cross-functional dependencies, degree of organizational change involved, and regulatory or compliance exposure.

A useful working framework:

• High-risk programmes (major ERP, multi-site operational restructures, regulated industry compliance programmes): fortnightly steering committee, weekly project lead check-in with sponsor, daily stand-up at delivery team level.
• Medium-risk projects (technology implementations, process redesign within a single function, vendor onboarding programmes): monthly steering committee, biweekly project manager to sponsor update, exception-based escalation otherwise.
• Lower-risk initiatives (departmental process improvements, single-vendor technology deployments with limited integration complexity): steering committee at initiation, mid-point, and close, with exception-based escalation in between.

The mistake organizations make is applying the same governance cadence to all projects because it is simpler to administer. This creates over-governance of low-risk work — consuming executive time and generating bureaucratic friction — while under-governing high-risk work, because a monthly cadence cannot absorb the decision volume a complex programme generates.

Measuring whether your governance is working

Governance effectiveness is not self-evident. Committees that feel productive — full rooms, engaged discussion, no awkward silences — can still be failing the project if they are not making timely decisions. The leading indicators worth tracking are:

• Decision turnaround time: From the date a decision request is logged by the project team to the date a decision is received. Track this by decision category. A rising trend is a governance signal, not a delivery signal.
• Escalation frequency and source: How often is the project team escalating, and are escalations coming from the same workstream repeatedly? Concentrated escalation indicates a structural dependency or authority gap the committee needs to address.
• Agenda composition: What percentage of each steering committee meeting is spent on decisions versus status updates? If status updates consistently consume more than 30% of meeting time, the pre-read process is not working or the committee membership is not stable.
• Out-of-cycle decision volume: How many decisions per month require out-of-cycle escalation? High volume indicates either that the scheduled cadence is too infrequent for the project’s risk level, or that the delegated authority thresholds are set too low.

These metrics are easy to track in a project log and should be reviewed at every steering committee session, not just at programme reviews.

Frequently asked questions

How do we get senior executives to actually read the pre-read pack before the meeting?

This is the most common implementation challenge, and the answer is structural rather than cultural. First, keep the pack genuinely short — five to eight pages is a reasonable expectation; 25 pages is not. Second, make the consequence of not pre-reading explicit: the meeting will not re-summarize background material, and decisions will be made on the basis of what is in the pack. Third, circulate 48 to 72 hours in advance, not the night before. Most executives will not prioritize a pre-read that arrives at 9pm for a 9am meeting. Fourth, consider adding a brief written question from the project manager with the pack — something that requires a response before the meeting — which prompts engagement with the material. In organizations we work with, these structural changes improve pre-read rates materially within two to three sessions.

Our steering committee has 10 people on it. How do we reduce membership without creating political problems?

The honest answer is that some political friction is unavoidable, and it is worth having. The practical approach is to reframe membership as a burden rather than a privilege: steering committee membership requires attendance at every session, advance reading of every pack, and a commitment to make decisions in real time. Presented this way, several members who joined for visibility will self-select out. For those who do not, propose a standing invitee structure — a separate list of stakeholders who receive papers and are invited to attend when agenda items directly affect their area. This preserves their visibility and organizational connection to the programme without creating decision-making gridlock in the core committee.

What happens when the executive sponsor is consistently unavailable for escalations?

This is a programme risk that should be named explicitly and early. An executive sponsor who cannot respond to urgent escalations within an agreed timeframe is not fulfilling the governance role, regardless of their seniority or organizational credibility. The appropriate response is to document the agreed escalation commitment in the project charter, track response times against that commitment, and raise availability as a risk at the steering committee level. If the pattern persists, the programme director or project manager should request a formal deputy sponsor arrangement — someone with sufficient authority to make decisions in the primary sponsor’s absence. Waiting for the sponsor to become available is not a governance strategy; it is a way of transferring programme risk to the delivery team.

At what point should governance structure be reviewed mid-programme?

Governance should be reviewed formally at each phase gate, and informally any time the escalation or decision metrics deteriorate. Specific triggers for a mid-programme governance review include: a change in project scope or timeline that materially alters the risk profile; a change in executive sponsor or key committee membership; a pattern of missed decisions or repeated out-of-cycle escalations; or a significant external change — regulatory, market, or organizational — that affects the programme mandate. The review does not need to be elaborate. A one-hour session with the sponsor and project manager to reassess committee membership, cadence, and delegated authority thresholds is usually sufficient.

How should governance work differently for AI or technology transformation programmes compared to operational projects?

Technology and AI transformation programmes typically require two governance adjustments. First, the steering committee needs a member with genuine technical literacy — not to make technical decisions, but to translate between the delivery team and the business stakeholders when the programme surfaces technical risks that have business consequences. In the absence of this, technical issues are either under-escalated (because the team does not know how to frame them for a non-technical audience) or over-escalated (because every technical decision becomes a committee agenda item). Second, technology programmes typically have higher out-of-cycle decision volume in early phases, as integration complexity and vendor dependencies create decision bottlenecks that operational projects do not encounter. The escalation pathway design is accordingly more important, and the asynchronous decision mechanism described above is particularly valuable.

Project Governance That Enables Rather Than Slows Delivery Down

Most senior operations directors, CFOs, and VPs at mid-market organizations have experienced programmes where governance was the bottleneck rather than the safeguard. This post offers a practical framework for designing steering committees, decision packs, and escalation pathways that protect delivery without slowing it down.