How to Write Decisions Needed in a Steering Committee

Write each decision in a steering committee report as a question the sponsor can answer with a clear choice. Name the person who decides, give the date an answer is needed, and state your recommendation with what waiting would cost. Put decisions near the top of the report, and keep only the items that need the committee's authority.

Which decisions belong at the steering committee?

A decision belongs at the steering committee when only the committee can make it, such as a scope tradeoff, a funding shift, a cross-department escalation, or a go or no-go call. Onplana describes these as decisions a project manager cannot make alone. Items the delivery team can settle within its authority go on a separate delivery list.

Test each open item with one question: if the answer waits, does the sponsor have to change a date, a budget, the scope, or a commitment that another team relies on? If yes, the item goes to the committee. If no, it stays with the delivery team and off the decision list.

This test is the team's working rule, not a published standard. Ask the sponsor to confirm where the line sits, and write the answer into the charter or terms of reference. Until then, apply the test as written.

Typical committee-level items:

• Moving the [milestone] date that [client or executive name] has already been told about
• Shifting funds from [budget line] to [budget line]
• Removing [deliverable] from the agreed scope
• Deciding whether [phase] starts before [gate review]

Typical delivery-level items:

• The order of work inside [phase] when the end date stays the same
• Staffing inside the plan the sponsor has already approved
• A workaround for [defect] that changes no agreed date, cost, or scope

How do you word a decision so the sponsor can answer quickly?

Word each decision as a question with a clear answer: yes, no, or one of the named options. Put the decision-maker and the answer date beside it. Slidemodel contrasts 'Approval needed for additional funding to address supply chain delays' with 'Discussion on budget challenges'; the first tells the sponsor what to decide.

Use this block for each committee-level item:

Decision: [question, for example: Do we approve moving [deliverable] to [new date]?]
Decision-maker: [name, role]
Answer needed by: [date], so that [what the date protects]
If this waits: [specific effect on date, budget, scope, or risk]
Options:
A. [option]: date [effect]; budget [effect]; scope [effect]; risk [effect]
B. [option]: date [effect]; budget [effect]; scope [effect]; risk [effect]
Recommendation: Option [letter], because [short reason].
Fallback if the sponsor chooses otherwise: [what the team will do next]

Fill the lines in that order. The question, the decision-maker, the answer date, and the effect of waiting are what the sponsor reads first, so write them first. Winningpresentations marks the recommended option and includes a fallback in its decision format, and the same structure works in a written report.

Question forms that work:

• Do we approve [option] by [date], or hold until [condition]?
• Which should the team take forward: [option A] or [option B]?
• Do we accept [risk] with [mitigation], or do we take [alternative]?

What does a filled-in decision look like?

A filled-in decision shows the question, the decision-maker, the options with their effects, a recommendation, and the sponsor's reply in the order the sponsor reads them. The example below is illustrative: every name, date, and figure in brackets is a placeholder for your project's facts.

Illustrative example: a delivery lead asks whether to move a milestone that the client has already been told about.

Decision: Do we approve moving [deliverable] to [new date], or hold it at [current date] and accept [risk]?
Decision-maker: [sponsor name], [role]
Answer needed by: [date], so that [what the date protects]
If this waits: [specific effect on date, budget, scope, or risk]
Options:
A. Move to [new date]: date [effect]; budget [effect]; scope [effect]; risk [effect]
B. Hold at [current date]: date [effect]; budget [effect]; scope [effect]; risk [effect]
Recommendation: Option A, because [short reason].
Fallback if the sponsor chooses B: [what the team does next]

The sponsor's one-line reply, sent by email:

[Sponsor name]: Approve option A, with [condition], and I will confirm the new date with [client name] by [date].

The logged row, kept in the committee log:

Decision	Answer and date	Decided by	Conditions	Next step owner	Check by
Move [deliverable] to [new date]	Approved, [date]	[sponsor name, role]	[condition]	[name]	[check date]

The read-back line, sent the day the decision is logged:

[Sponsor name], recorded: [deliverable] moves to [new date], approved on [date], subject to [condition]. [Name] owns the next step and will check it by [check date]. If any line is wrong, reply by [date].

Where do decisions go in the report?

Place decisions near the top of the report, after a one-line status and before risks and detail. A sponsor who reads only the first section then sees what is being asked and can answer quickly. Status.net advises leading the report with exceptions, risks, and decisions.

Use this order for the written report:

1. One-line status: [project] is [on track, at risk, or off track] for [milestone] by [date].
2. Decisions needed, in the template above.
3. Risks and blockers where the team needs the sponsor's help.
4. Progress against each deliverable, with the evidence behind it.
5. Next steps, each with an owner and a date.

Winningpresentations puts its decision slide right after the executive summary, which is the same logic in slide form.

Send the report before the meeting, not during it. Status.net recommends a 48-hour pre-read lead time, and Onplana circulates its pre-read 48 hours ahead. Pick a lead time the sponsor can keep, and put it in the meeting invite.

How many decisions should one meeting take?

Keep the list short enough that each item gets a real answer. Onplana suggests 3 to 5 decisions per meeting, and the author presents that threshold as a heuristic, not a tested rule, so treat it as a starting point.

The practical cost of a long list is that the sponsor cannot give a real answer to each item. The sponsor then either answers without reading each one or defers the whole list, and the items that would change a date or budget get lost among the rest.

Ask of each item whether waiting until the next meeting would change the answer. If it would not, move it to the status section as information. Sort the rest by the date each answer is needed, so the items that would change a date or budget if they waited come first. Move anything left over to the next meeting or the delivery list.

How do you record and follow up each answer?

Log each decision on the day it is made, with the answer, the decision-maker, any conditions, the owner of the next step, and the date it will be checked. Then send the sponsor a read-back. Onplana sends its read-back within 24 hours, so match that window where you can.

Keep one log for the committee, and carry every open item into the next status report until it closes. Each entry uses the same columns:

Decision	Answer and date	Decided by	Conditions	Next step owner	Check by
[decision]	[approved, rejected, or deferred], [date]	[name, role]	[condition or none]	[name]	[date]

Use this read-back wording, with one line per decision:

Subject: Committee decisions, [meeting date]

[Sponsor name], these are the decisions recorded at the [meeting date] meeting:

1. [Decision]: [answer], decided by [name]. Conditions: [condition or none].
2. [Decision]: deferred to [date] because [reason]. Owner: [name].

Next step: [owner] will [action] by [date]. If any line is wrong, reply by [date] and we will correct the log.

If the sponsor defers an item, record the new decision date and the effect of the delay in the report. If approval comes with conditions, write each condition as its own action with an owner and a check date.

What if the charter does not say who approves a decision?

Check the charter or terms of reference for who gives approval or sign-off before you record a decision as final. If the charter is silent on voting, quorum, or dissent, ask the sponsor which rule applies, and write the answer into the log with the authority the decision-maker acted under.

Record the authority beside the answer, not only the name. A decision marked 'approved' with no authority beside it is hard to defend later. If a member objects, add one sentence beside the answer that states the objection. A decision that needs real discussion is better handled in a short slot in the meeting, with the template sent as the pre-read, than as a bare yes or no.

What should you do before the next committee meeting?

Before the next committee meeting, sort open items into committee-level and delivery-level lists, write each committee-level item in the decision template, and send the draft to the sponsor for review. Then send the report ahead of the meeting and log every answer afterwards.

1. Run the test in the first section on every open item.
2. Write each committee-level item with the question, the decision-maker, the answer date, and the effect of waiting.
3. Add a recommendation and a fallback to each item.
4. Ask the sponsor to review the draft by [date], before the report goes out.
5. After the meeting, log each answer and send the read-back.