Request a Decision on a Specific Open Project Question

Use this when a choice is holding up a next step

This format works when a project has a specific unresolved question and someone has the authority or relevant knowledge to answer it. For example, a project owner may need a stakeholder to choose between two report layouts before the team prepares the final version. The decision should be narrow enough that the recipient can understand what a reply will settle.

It is less suitable for an issue that still needs exploration, a decision that belongs to a group, or a question with important options you have not identified. In those cases, ask for a short discussion or propose how to gather the missing input instead of disguising a broad conversation as a simple yes-or-no request.

Bound the choice before drafting

Write the decision as one direct question. Name the item being decided and the available choices. If the answer is a selection, make clear whether the recipient should choose one option or can suggest another. Avoid combining separate questions, such as asking for approval of a schedule and a budget in the same sentence.

Check that each option is genuinely available. If one depends on a resource, approval, or condition that has not been confirmed, say so. A useful request can still include an alternative such as “another option, with the trade-off noted,” but do not imply that every possible suggestion can be accommodated.

• Can the recipient state the decision in one sentence?
• Are the choices distinct, understandable, and currently feasible?
• Have you identified who decides and who needs to be consulted?

Give context that helps someone choose

Include only the background that could change the decision: the relevant constraint, what has already been agreed, and the next step waiting on the answer. If you mention a prior agreement or document, identify it plainly so the recipient can find it. Do not make the reader reconstruct the whole project from a long thread.

Compare the options against the same considerations. For instance, explain that one layout is quicker to prepare but leaves less room for detail, while another preserves detail but requires more review. Keep consequences concrete and proportionate. Separate known facts from estimates or assumptions, and label an assumption if the decision depends on it.

Set a response date with a reason

Choose a date that allows the recipient a realistic chance to consider the question and still gives the project owner time to act. State the date, time, and time zone when ambiguity is possible. Explain the next work step that depends on the reply, rather than using vague urgency such as “ASAP.”

If the date passes without an answer, do not silently treat that as approval unless that arrangement was explicitly agreed beforehand. Say what you will do instead—for example, pause the dependent work, ask whether someone else can decide, or send a brief follow-up. If a default choice is genuinely authorized, state it clearly and invite the recipient to flag concerns before the deadline.

Editable email example

Replace the bracketed fields with accurate project details. Remove any option or consequence that does not apply, and check that the proposed date leaves enough time for a response.

To: [recipient@example.com]
Subject: Decision needed: [specific project question] by [date]

Hi [name],

Could you decide whether we should use [option A] or [option B] for [specific project item]?

The relevant context is [brief constraint or prior agreement]. Option A would [practical consequence]. Option B would [practical consequence]. The next step, [work waiting on this choice], depends on the decision.

Please reply with A or B by [date, time, time zone]. If neither works, please suggest an alternative and note the main trade-off. If you need more information to decide, tell me what is missing and I’ll follow up.

If I don’t hear back by then, I’ll [accurate next step; do not imply approval unless agreed].

Thanks,
[your name]

Check the request before sending

Read the email from the recipient’s point of view. Could they tell what is being decided, why it matters now, and how to answer? Verify names, dates, time zone, option labels, and any stated consequence. Make sure the response date matches the actual project dependency, not merely the date that would be most convenient for you.

Also check whether you have presented the choices fairly. Do not describe your preferred option in detail and leave the other unexplained, or hide a meaningful cost or delay. If the consequences are uncertain, say what is uncertain. A concise request should make a choice easier, not steer someone by withholding relevant context.

• One decision is prominent in the subject and message.
• Options use comparable descriptions and include material trade-offs.
• The deadline, reason, and plan if there is no reply are explicit.

Close the loop so work can move

When the recipient answers, reply with a short confirmation that restates the selected option and the next action. Name the person responsible for that action if it is not obvious, and correct any misunderstanding before work proceeds. If the answer changes a date or deliverable, record that change in the project’s usual place as well as in the email thread.

You can confirm the request worked when the decision is clear, the responsible person knows what to do next, and the blocked work has either resumed or has a stated reason for remaining paused. If the reply introduces a new question, separate it from the original decision and decide whether it needs its own owner and response date.