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.
Steering committee vs working group vs advisory board
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.
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.
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.
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.