A project steering committee tends to drift the same way. The first meetings make decisions, then the meeting turns into a progress update: the project manager presents, the executives listen, everyone leaves with an impression. Six weeks later a decision is still waiting, and nobody is quite sure who was supposed to take it.
I work alone, on short engagements. In that setting the project steering committee is often the moment when the people who decide are together, and I have no meeting to waste. Here is what I expect from a steering committee, how I write its terms of reference, how I prepare it, and when it is better to do without one.
01What a steering committee decides, and what it leaves to the team
A steering committee exists to decide what the project team cannot decide alone. That is its only job, and it is already a heavy one: moving a go-live date, dropping a feature to stay on budget, choosing between two design directions, settling a disagreement between two departments.
The UK government's project delivery standard, Government Functional Standard GovS 002, puts it in civil service language. The governance framework should set out authority limits, decision-making roles and criteria. The sponsoring body makes, or refers upwards, the decisions that are above the authority delegated to the person running the project. And a risk its owner cannot resolve gets escalated.
What I take from it is simple: a steering committee exists because there is a boundary of authority. If nobody knows where that boundary sits, everything goes up to the committee, or nothing does. Both are bad.
Steering committee and project committee
The project committee brings together the people doing the work, every week or every fortnight. It handles the routine. The steering committee brings together the people who commit the organisation, less often, and only sees what goes beyond the project committee.
The steering committee also gets confused with the sprint review when the team works in Scrum. The Scrum Guide describes the Sprint Review as a working session where the team and stakeholders inspect the outcome and decide what to do next with the product. I trained as a Scrum Master and Product Owner, and I keep the two apart: the review is about the product, the steering committee arbitrates budget, timeline and scope.
02Who sits on the steering committee, and how many
In a video on steering groups, trainer Mike Clayton gives a rule I apply: roles first, faces second. You list what the committee needs in order to decide, then look for who can fill each role.
For a digital project, I would start from this list:
- the sponsor, who owns the project and chairs;
- the heads of the departments the project changes, with authority to commit their department;
- whoever holds the budget, if that is not the sponsor;
- the project manager, who prepares and runs the meeting without a vote.
I prefer a small committee. Every extra person adds another agenda to reconcile, and a member who comes "to be kept informed" has no reason to be there: the minutes will do. When a supplier or a specialist needs to inform a decision, I invite them for that item, not the whole meeting.
03Write the terms of reference before the first meeting
The terms of reference fit on one page. Mike Clayton lists the committee's purpose, what it can look at, what it can commit, its working rules, how often it meets and how it handles conflicts of interest. I recommend writing them with the sponsor before the first meeting, then having them approved in session.
What the terms of reference should contain
- The project's goal in one sentence, the one you will reread when you have to choose between two options.
- What the committee decides: for example any change to the go-live date, any addition to scope, any spend above a threshold agreed with the sponsor.
- What the project team decides alone, below those thresholds.
- Who settles it if the committee cannot agree, usually the sponsor.
- How often it meets, and the option of an extra meeting when a decision cannot wait.
Point 3 matters as much as point 2. A team that knows how far it can go without asking does not clog the committee with routine questions. And a committee that knows what it has to decide arrives prepared.
On an integration between an ERP and an online shop, the specification changed at almost every meeting. I versioned it, one release after another, so that everyone was talking about the same document. A steering committee's terms of reference deserve the same treatment: they carry a version number, and when they change, you say so.
04Preparing a meeting: nothing new in the room
The rule I recommend: nobody discovers bad news during the steering committee. Mike Clayton calls it "no surprises". The report goes out before the meeting, and if a piece of news is likely to shock, you call the people concerned before they read it.
It is a lesson from my missions that I hold on to: a monthly report that goes out on its own and a committee that decides are worth more than a dashboard nobody reads. In practice, the report is short, it goes out a few days ahead, and the meeting starts on the assumption that it has been read.
The pack to send
- The state of the project on one page: timeline, budget, scope, risks, each with a green, amber or red status.
- For each amber or red, one sentence explaining why and what is being done.
- The decisions requested, each with two or three options, their consequences and my recommendation.
- The log from the previous meeting, with what has happened since.
The written amber comes from my content machines. In the machine that writes this blog, an amber article only goes out with a written justification for each point. A steering committee works the same way: an amber status with no explanation turns green out of habit, and you find out it was red too late.
For a design decision, I show the options at the same level of finish. A polished mock-up next to a rough sketch makes the decision for the committee, and that is not the committee's choice.
The Harvard Business Review piece on agenda design sums up the aim: a good agenda sets out what needs to happen before and during the meeting, helps everyone prepare and tells you when a discussion is finished. For a steering committee, a discussion is finished when the decision is taken or explicitly deferred, with a name and a date.
05The decision log, the only record that counts
Mike Clayton advises recording, at the end of each meeting, the decisions taken and the actions each person has committed to. I would add reading them back aloud before everyone leaves. It takes a few minutes and saves weeks of "that is not what I understood". The log goes out the same day.
I recommend keeping decisions in a log that runs from the start of the project to the end: the date, the decision, who took it, what it changes. When someone reopens a settled question, the log answers. In my content calendars, an "on hold" status flags that a human decision is needed, and the machine does not touch the topic until it is taken. A steering committee log benefits from the same column: what is waiting for a decision, and since when.
The format of the log and the agenda of a monthly committee are covered in my piece on the monthly marketing committee that actually decides. The principle holds for a project: nobody leaves without a written decision.
06When a steering committee is one meeting too many
Not every project needs a steering committee. On an engagement of a few weeks with a single decision-maker, a weekly check-in with the sponsor is enough, and a formal steering meeting would add ceremony without deciding anything else. A steering committee earns its place when several departments have to agree, when the budget commits the organisation beyond a single manager, or when a date cannot move.
It has a cost too. Mike Clayton points out that these committees can be highly political, because everyone arrives with their own agenda. Written terms of reference limit the problem; they do not make it go away. Sometimes the real decision is taken beforehand, in a corridor, and the meeting is there to announce it. That is not necessarily a problem if the log says so.
Finally, a steering committee does not replace the project manager's work. My early years in audiovisual production taught me to hold a budget, a schedule and a crew together with a date that does not move. A committee cannot rescue a badly run schedule; at best, it helps you decide what to cut.
07Where to start with your next steering committee
If your steering committee has turned into a progress update, I would start with three things. Write the terms of reference on one page with your sponsor, separating what the committee decides from what the team decides alone. Send the next pack a few days ahead, with the decisions requested at the top. And end the meeting by reading the decisions back aloud.
The rest you adjust as you go. If you are launching a project with several stakeholders and the governance worries you, that is part of what I do as a digital project director, and my engagements are described on the services page. Happy to talk it through.