Steering Committee Project Management: Decide, Don't Update

Watch the next steering committee you sit in on. Count two things: how many minutes pass before someone says the word "decide," and how many decisions actually leave the room with an owner and a date. The number is usually zero and zero. Sixty minutes of senior time, no decisions, three slide decks reviewed.

That meeting did not steer anything. It informed people who already had access to the same information in writing. The project will keep going in the direction it was already heading, which is the direction nobody is willing to question because the committee never sets the table for that conversation.

Steering committee project management has one job: turn the questions a single project manager cannot answer into decisions the project can act on. If your committee is not doing that, it is overhead. The fix is structural, not interpersonal, and it starts with admitting the room exists to decide.

TL;DR. A steering committee is a decision body, not a status forum. Measure its health by decision density: how many committed decisions per meeting, how many slipped into "let's discuss next month." Restructure the agenda so decisions come first, recommendations are pre-written, and every decision exits the room with an owner, a date, and a written record. The committee that ships projects is the one that votes on something every time it meets.

Why most steering committees inform instead of decide

The default failure mode is gravitational. PMs prepare a status update because that is what they do every Friday for sponsors. Sponsors arrive expecting that update because that is what they got last month. Senior leaders, who do not have time to read pre-reads, ask the PM to walk them through the schedule, which consumes 25 of the meeting's 60 minutes. The remaining 35 minutes get spent on whoever raises a question loudest, which is rarely the question that actually needs a vote.

Three patterns create this drift, and recognizing them is the first move toward fixing it.

The agenda is a status report in disguise. A committee whose agenda starts with "project update from the PM" has already chosen status over decisions. Status comes first because it feels safe and orienting. Decisions get pushed to the end, which is the slot that gets cut when the meeting runs over, which is every meeting. The agenda communicates priority, and putting status first communicates that informing comes before deciding.

No one wrote the recommendation. Senior leaders are good at reacting to specific proposals and bad at generating them in real time. When the PM says "we're seeing a resource conflict on the integration workstream and wanted to discuss," the room defaults to discussion because there is nothing concrete to vote on. Discussion fills the time. The decision waits for the next meeting, which has the same problem.

Decisions exit verbally. The PM thinks the committee approved a scope cut because the heads nodded and no one objected. Two weeks later the marketing director says "I never agreed to that" and the team relearns that nodding is not voting. Without a written record of decisions made, every committee meeting starts from a different version of reality.

These are not personality problems. They are room-design problems. The same set of leaders, with the same agenda, will produce the same non-decisions month after month.

What a steering committee is supposed to do

The cleanest definition is operational: a steering committee owns the class of decisions a single project manager cannot make alone, and it owns them within a defined cadence so the project does not stall waiting for input.

That class is narrower than people think. Most project decisions belong to the PM and the team. Should this task be done before that one? PM decides. Should we use library A or library B? Engineering decides. Should we hire a contractor for the test phase? PM decides, with sponsor approval if it crosses a budget threshold.

Steering decisions look different. They cross functional boundaries (the integration depends on data the analytics team is not staffed to provide), they shift commitments other teams have already made (we need to delay the campaign launch by six weeks), or they raise the project's risk profile in ways the sponsor needs to underwrite (we want to ship a partial release rather than the full scope). These are decisions where the right answer requires the authority to commit other people's resources or accept other people's risks.

A working steering committee handles roughly four kinds of decisions, in order of frequency:

1. Scope tradeoffs. Cut feature X to keep date Y, or hold the date and add resources, or hold scope and slip the date. The PM frames the choice; the committee picks.
2. Resource conflicts. Two projects need the same engineer in the same week. The committee decides which one waits.
3. Cross-functional dependency commitments. A function needs to commit to a deliverable that was previously aspirational. The committee makes that commitment binding.
4. Go or no-go at gates. At the end of a phase, does the project continue, pause, or stop? The committee decides based on whatever the gate criteria specified.

If your last three steering committee meetings did not produce decisions in two of these four categories, the committee is not steering anything; it is decorating a project that the PM is steering alone.

The decision-density agenda

The fix is to invert the agenda. Decisions go first. Status goes last, and only as much status as is needed to support the decisions on the table. The diagram below shows what changes.

The decision-density agenda has four blocks and a hard rule: every block produces an output the room can read back at the end.

Block 1: Decisions on the table (35 minutes). Three to five decisions, each with a one-page written recommendation circulated 48 hours ahead. Each item gets five to eight minutes: read the recommendation aloud, note any objections, vote, record the decision and owner. If the room cannot decide, the item moves to a named follow-up with a deadline shorter than the next meeting; it does not float to "next time."

Block 2: Risks and issues that need committee action (10 minutes). Not every risk. Only the ones where the response requires authority the PM does not have. A risk that says "we may need additional budget" with no recommendation does not belong here; that is a future decision that needs prep work first.

Block 3: Status headlines (10 minutes). RAG status, milestone date confirmations, and direct asks. The pre-read carries the detail. The meeting confirms the headline and surfaces anything that is not on paper. If the project is green and on track, this block runs in three minutes; the time is not lost, it is given back.

Block 4: Decision read-back (5 minutes). The PM reads the list of decisions made in the meeting, names the owner and date for each, and asks "any corrections?" before the room disperses. This is the single most important five minutes in the agenda. It converts verbal nods into a written record that survives the next four weeks.

The agenda ordering is not aesthetic; it is structural. When status is first, the room enters status mode and stays there. When decisions are first, the room enters decision mode and the rest of the agenda inherits that posture. Try it once; the difference shows up in the first meeting.

The pre-read that makes decisions possible

A steering committee that decides depends on a pre-read that prepares the room to decide. The pre-read is not the meeting deck. It is a short document that contains, for each decision on the agenda:

1. The decision. Stated as a binary or multiple-choice question. "Should we cut the reporting module from the v1 release to hold the August date, or extend the date to October to keep scope?" Not "we want to discuss the reporting module."
2. The recommendation. The PM and sponsor's preferred answer in one sentence, plus the reasoning in two more.
3. What changes if you say yes vs. no. Concrete: dates, budget, scope, risk profile. The room should be able to picture both futures.
4. The decision deadline. Today's meeting, or a specific later date. If it is later, why is it on this agenda.

If you cannot write all four items, the decision is not ready for the committee. That is good information; it tells the PM which prep work to finish before the next round. The discipline of writing the pre-read forces clarity that verbal walk-throughs allow you to skip. When pre-reads consistently arrive a clear 48 hours before the meeting, decision quality rises immediately.

A committee that gets used to pre-reads stops tolerating their absence. That is the cultural shift you want. The first time someone says "I cannot vote on this without a written recommendation" is the first time the committee starts behaving like a decision body.

How to count decision density

The metric that tells you whether the committee is working is decision density: the number of committed decisions made in the room, per meeting. Three decisions per monthly meeting is healthy for a project of normal complexity. Below one is a sign the committee is decorative. Above six usually means the room is making decisions that should have been made one level down; the PM is using the committee as cover for choices the team should be owning.

The diagram below shows what to track.

The chart is not theoretical. PMs who track decisions per meeting and surface the count to their sponsor see a pattern: months 1 and 2 produce nothing because the agenda has not changed; month 3, after the agenda is restructured and the pre-read becomes routine, produces a step change. The committee starts deciding because the room is finally set up to.

A simple practice: keep a decision log in the same place the project's other artifacts live. One row per decision, columns for date, summary, owner, deadline, status (Open, Closed, Reversed). Show the log to the committee at the start of each meeting. Public decisions stay decided; private ones drift. When you write goals and milestones for the project, you treat them with this same weight; the discipline that ships projects extends to the decisions about those projects, not just the work itself.

Common failure modes and how to spot them

Three patterns surface in committees that look healthy from a distance and fail up close. Each has a tell and a fix.

The committee that re-decides. A decision made in March is "discussed again" in May, not because new information arrived but because someone who was absent in March wants to relitigate. The tell: the agenda repeats itself. The fix: the decision log is read-only after the meeting in which the decision was made. Reopening requires a written change request with new information, treated as its own agenda item.

The committee that escalates everything. Every decision the PM brings becomes "let's get the SVP in the room to weigh in." The tell: the committee feels like a way station rather than a destination. The fix: the sponsor names the decision authority of the committee in writing, including budget thresholds and scope authority. If the committee cannot decide a $50,000 contractor engagement, the project is being run from too high up.

The committee that absorbs the project manager's job. Senior leaders start asking detailed schedule questions, second-guessing task assignments, redesigning the WBS in the meeting. The tell: meetings consistently run over because the room is doing the PM's work in real time. The fix: the sponsor closes the room politely with "the PM owns scheduling; this committee owns scope, resources, and gate decisions." This is uncomfortable to enforce, especially if the senior person doing the redesigning is the loudest voice. It is also necessary; without that boundary the committee becomes the bottleneck rather than the unblocker.

In any of these cases, walk through the PMO Maturity Assessment for the governance dimension. A committee that re-decides or absorbs the PM's job is almost always a symptom of governance maturity below where the project's complexity needs it.

Comparing committee shapes

Not every project needs the same committee. The shape should match the project's risk profile and cross-functional reach. The table below maps four common shapes to the projects they fit.

Shape	Members	Cadence	Fits projects that...
Lean steering	Sponsor, PM, two function heads	Bi-weekly	Are bounded to one or two functions; under 6 months
Standard steering	Sponsor, 3 to 4 function heads, PM, finance	Monthly	Cross 3+ functions; 6 to 18 months; medium budget
Program steering	Sponsor, all impacted function heads, PMO director, PM lead	Monthly + ad-hoc	Span multiple connected projects; over a year; high cross-org dependency
Executive steering	C-suite or equivalent, PMO director, PM lead	Monthly	Strategic; require board or capital-allocation visibility

The fastest way to break a committee is to apply program-steering rules to a lean project, or vice versa. A lean steering committee with a quarterly cadence will miss decisions; a program steering committee meeting bi-weekly with eight people will burn senior time on detail. Match the shape to the project, not to the org chart.

What to change at your next meeting

If the next meeting is two weeks away and you cannot rebuild the whole apparatus by then, change three things.

1. Move decisions to the top of the agenda. Whatever else is on the agenda, the first 30 minutes go to two or three named decisions with one-page recommendations. Status moves to the back.
2. Send the pre-read 48 hours ahead. Not a deck, a document. If you cannot fill in "the decision," "the recommendation," and "what changes" for an item, drop it from the agenda; it is not ready.
3. Read back decisions before the room disperses. Five minutes. Names, dates, decisions. Followed by a one-line email within 24 hours.

That is enough to shift the meeting's character in a single cycle. The deeper restructuring (membership, cadence, decision authority) takes a quarter. The agenda fix takes a Tuesday afternoon.

If decision quality is also being throttled by status-report bloat upstream of the committee, the inputs the room reads, the Status Report Writer drafts the headline-first, RAG-up-top format that committee members actually read. A committee that reads the pre-read makes better decisions than one that hears the status walk-through for the first time at the meeting itself.

For PMs running their first steering committee, pair this with creating a project plan that has clean milestones; without those, the committee has no natural decision points to gather around. And for projects where the committee is being asked to absorb work the PM should own, the patterns in why Project Online migrations fail describe the failure mode in a different domain: senior involvement that crowds out delivery ownership.

Run the free PMO Maturity Assessment Score your governance, including how decisively your steering committee operates, against five PMO maturity tiers and get a one-page report you can hand to your sponsor. No signup required. Open the assessment