A steering committee is the governance body that makes the decisions a programme team cannot make alone, holds the programme accountable to its business case, and removes the obstacles that block delivery.
Most steering committees do none of those things. They meet monthly to receive updates. The programme director presents the status. Workstream leads walk through their slides. The sponsor asks a few questions. Everyone agrees to reconvene next month. That is not governance. That is a briefing. A steering committee exists to do something far more specific, and far more valuable, than listen.
What is a steering committee?
A steering committee is a governance body, not a reporting forum. It sits above the programme team and below the board, and it holds delegated authority to decide the things a programme cannot decide for itself.
Three features separate it from every other forum a programme runs. It has decision rights, written down and bounded. It is accountable for the business case rather than the schedule. And it is chaired by someone carrying organisational authority, normally the sponsor, rather than by the person running delivery.
Remove any one of those and the forum becomes something else. A committee without decision rights is an advisory board. A committee accountable only for schedule is a delivery review. A committee chaired by the programme director is a team meeting with senior guests.
The purpose is narrower than most charters make it sound, and it is worth stating plainly. A steering committee exists so a programme can move at the speed of its decisions rather than the speed of its escalations. Every other function it holds follows from that one.
Steering committee vs programme board vs working group vs advisory board
The programme board distinction causes the most confusion. In structured frameworks the board sits above the committee and owns the investment decision, while the committee runs delivery. In practice many organisations run a single forum and call it either name. The label does not matter. What matters is whether the forum holding the funding decision is the same forum hearing the delivery truth, and whether anyone has written down which decisions sit where.
Who sits on a steering committee, and what each seat owns
Membership is where most steering committees are set up to fail. The common error is treating a seat as recognition rather than as a responsibility, which produces a forum large enough to be informed and too large to decide.
Steering committee seats and what each one owns
Two membership rules matter more than the rest.
The programme director does not chair. When the person accountable for delivery also runs the forum that scrutinises delivery, scrutiny becomes optional. The chair should be the person who suffers most if the programme fails, which is almost always the sponsor.
The vendor or SI attends for part of the meeting, not all of it. A committee cannot discuss vendor performance candidly with the vendor in the room, and it cannot hold a commercial conversation about a contract in front of the counterparty. Structure the agenda so there is a portion the vendor does not attend, and say so openly rather than arranging it awkwardly.
On size, the working number is six to eight. Beyond that, attendance becomes an audience. If more people need visibility, send them the pack. Visibility and decision rights are different things, and conflating them is what makes committees unable to decide.
Make decisions that the programme team cannot make alone
The primary function of a steering committee is to make decisions. Not all decisions. The programme team should handle the vast majority of operational decisions without escalation. The steering committee exists for decisions that exceed the programme team's authority: scope changes that affect the business case, budget reallocation, timeline adjustments with organisational impact, and trade-offs between competing priorities.
This requires two things. First, the programme team must frame decisions clearly: what the options are, what each costs, what each risks, and what is recommended. A steering committee that receives problems without options is being asked to do the programme team's job. Second, the steering committee must actually decide. Deferring a decision to the next meeting is itself a decision, and it should be treated as one: with a documented rationale, an impact assessment, and an accountability for the delay.
When a steering committee stops making decisions, the programme either stalls or the programme team starts making decisions they should not be making. Both outcomes are governance failures.
Hold the programme accountable to its business case
Every technology programme was commissioned to deliver something. Cost reduction. Operational efficiency. Regulatory compliance. Capability uplift. Revenue protection. The business case is the "why" behind the investment. The steering committee is the custodian of that "why".
This means asking, at every meeting, whether the programme is still on track to deliver the benefits it was commissioned to deliver. Not just whether it is on schedule. Not just whether it is on budget. Whether the thing being built will actually produce the outcome that justified the investment. This is a different question, and it is one that most steering committees do not ask.
In HRIS programmes, this might mean challenging whether the new platform will genuinely reduce payroll processing time or whether it is simply replacing one system with another. In AI deployments, it might mean questioning whether the AI features being implemented will deliver measurable business value or whether they are being adopted because the vendor included them in the licence. In ERP programmes, it means testing whether the configuration decisions being made align with the operational outcomes the business case described.
Challenge programme reporting, not just receive it
A steering committee that accepts programme reporting at face value is not governing. It is spectating. The value of the committee is in its ability to ask the questions that the programme team may not be asking itself, or may not want to answer.
This means questioning RAG ratings. If a workstream has been amber for three consecutive months, what does that actually mean? Is it genuinely at risk, or has amber become the new green because nobody wants to report red? If the data migration workstream reports green but the data quality metrics are not being tracked, what is that rating based on?
Effective challenge requires preparation. Steering committee members who arrive without having read the papers cannot challenge anything. They can only listen. The most effective governance structures include a pre-read expectation and a standing agenda item for challenges and clarifications, separate from the status update itself.
What a steering committee report should contain
Most steering committee packs are built to be presented. A useful one is built to be decided from.
The difference shows on the first page. A pack that opens with a workstream-by-workstream status walk is a briefing document. A pack that opens with the decisions required at this meeting is a governance document. The second is shorter and produces more.
Four things earn their place in every pack. The decisions required, framed as questions with options, costs, and a recommendation. The business case position, showing whether the benefits that justified the investment are still achievable. The exceptions, meaning what moved against plan and what is being done about it. The escalations, each carrying an owner, a date, and its status since the last meeting.
Everything else is optional. Packs grow because nobody removes anything, and a sixty-page pack guarantees that nobody reads it. A committee that receives its papers the night before will not challenge them. Papers should land three to five working days ahead, and the pre-read should be treated as an obligation rather than a courtesy.
One test separates a governance pack from a status pack. Read it and ask what the committee is being asked to do. If the answer is to note the update, the pack has failed before the meeting starts.
Manage escalations and remove obstacles
Programmes get stuck. Resources are not released on time. Business decisions that the programme depends on are not made. Vendor disputes need executive intervention. Organisational politics block progress. These are the obstacles that programme teams cannot resolve within their own authority.
The steering committee exists to resolve them. When a programme director escalates a resource constraint, the steering committee should assign an owner, set a deadline, and track it to resolution. When a vendor dispute requires commercial negotiation above the programme level, the steering committee should appoint the right person and authorise the conversation. When an organisational blocker requires executive intervention, the sponsor should act.
An escalation that sits in the steering committee without resolution for more than one meeting cycle is not being governed. It is being tolerated. The committee's effectiveness is measured not by how many escalations it receives but by how quickly it resolves them.
How often should a steering committee meet?
Monthly is the sensible default for a programme in steady delivery. Fortnightly is right through cutover, hypercare, and any period where the decisions the programme needs are arriving faster than a monthly cycle can absorb them.
The cadence question is really a decision latency question, and it is better answered from the other direction. Ask how long a programme decision currently waits before someone with authority makes it. If the answer is routinely more than two weeks, the committee is meeting too rarely regardless of what the charter says. If the committee regularly meets with nothing to decide, it is meeting too often and will drift into receiving updates to fill the time, which is how briefing culture starts.
Two mechanisms matter more than the interval itself. There should be a route to a decision between meetings, normally a written approval from the chair within agreed limits, so a programme is never idle for three weeks waiting for a date in a calendar. And there should be a trigger for calling an extraordinary session, tied to defined events rather than to how worried someone feels. A missed go or no-go gate, a material business case change, or a vendor dispute crossing a commercial threshold are all reasonable triggers.
A committee that only ever meets on schedule is not responding to the programme. It is responding to the calendar.
Own the relationship between the programme and the organisation
A technology programme does not exist in isolation. It affects operations, it requires organisational change, and it depends on business engagement. The steering committee is the bridge between the programme and the broader organisation.
This means ensuring that business leaders are engaged, that change readiness is being tracked, and that the organisation's capacity to absorb the transformation is not being overwhelmed. It also means managing expectations upward: ensuring that the board or executive team has an accurate view of programme health, not an optimistic one.
When the steering committee fails to own this relationship, the programme becomes disconnected from the organisation it is supposed to serve. The programme team builds what was specified. The organisation rejects it because nobody maintained the connection between what was being built and what the business actually needed.
Scrutinise vendor and SI performance
In any technology programme that involves a vendor or system integrator, the steering committee has a responsibility to scrutinise their performance from the client's perspective. This is not the same as reviewing the SI's status report. It means asking whether the vendor is delivering what was contracted, whether milestones are being met by the client's definition (not just the vendor's), and whether the commercial relationship is functioning as intended.
This function is often neglected because steering committee members do not have the platform or commercial expertise to challenge vendor performance. They rely on the programme team's assessment, which may itself be influenced by the vendor's reporting. This is where independent programme oversight adds the most value: providing the steering committee with a view of vendor performance that is not filtered through the vendor's own narrative.
Without this scrutiny, the vendor relationship operates on trust rather than evidence. That is not a commercial partnership. It is an arrangement that favours the party with the most information.
These six functions define what a steering committee is for. They apply whether the programme is implementing an HRIS, an ERP, an AI platform, or any other technology that changes how the organisation operates. The technology changes. The governance requirements do not.
Corporate steering committee or programme steering committee?
The term is used for two different bodies, and the distinction is worth drawing, because advice written for one frequently gets applied to the other.
A corporate or standing steering committee is permanent. It oversees a portfolio, a function, or an ongoing capability, its membership is stable, and its agenda repeats. A programme steering committee exists for the life of one programme and dissolves when the programme closes. It has a defined end, a single business case, and an agenda that changes shape as the programme moves through its phases.
Everything in this article describes the second. The functions transfer to a standing committee reasonably well, with one exception that matters. A programme committee can and should be wound up. A standing committee cannot, which means it tends to accumulate agenda items and lose the sharpness that a finite mandate produces. If a standing committee is overseeing a major programme, the practical answer is usually to stand up a dedicated programme committee underneath it rather than add the programme to an existing agenda.
What an effective steering committee does versus what most do
A steering committee that only receives updates is not governing. It is spectating.
Effective governance makes decisions, holds the programme to its business case, challenges what it is told, resolves escalations, connects the programme to the organisation, and scrutinises vendor performance. Every meeting. Every cycle. Without exception.
