How to Turn a Vague Work Request Into a Decision-Ready Brief

A vague work request creates hidden work for everyone involved. “Can you look into this?” “We need a plan.” “Please make this better before Friday.” The person asking may believe the request is clear because they know the history. The person receiving it has to guess the outcome, audience, decision-maker, deadline and level of detail. That guessing is where rework begins.

A decision-ready brief is a short written agreement that turns a broad request into a usable assignment. It is not a long project document and it is not a way to challenge the requester. Its purpose is to make the next action obvious and to expose the few choices that really need an answer. You can usually create one in ten minutes.

Why vague requests cost more than they appear to

When a request has no defined outcome, capable people often solve different versions of the problem. One colleague produces research, another creates slides, and a third waits for approval that nobody realized was needed. The team may look busy while moving in several directions.

Vagueness also makes deadlines unreliable. “By Friday” might mean a first draft, a review-ready recommendation or a finished deliverable sent to a client. Those are different commitments. If you do not separate them early, the disagreement usually appears at the deadline, when it is hardest to fix.

Clearer requests are especially useful when priorities are shifting. Before accepting a new task in the middle of a busy day, use the urgency test in How to Start Work When Everything Feels Urgent to decide whether it is a real immediate need or an important item that needs a planned slot.

The five-line decision-ready brief

Write the brief in the message thread, a shared document or your task system. Keep it to five lines first. If the work is genuinely complex, the five lines become the heading structure for a fuller plan.

1. Outcome

State what will exist when the work is complete. Avoid activity words such as “review,” “work on” or “improve.” Use a concrete output instead: “a one-page recommendation comparing the two suppliers,” “a revised customer email ready for approval,” or “a launch checklist with owners and dates.”

A useful test is whether someone could look at the output and say yes or no: is this the thing we asked for? If not, the outcome still describes effort rather than a deliverable.

2. Decision or use

Explain what the output will help someone decide or do. This line prevents overproduction. A supplier comparison for a manager choosing a vendor needs a recommendation, price assumptions and risks. The same comparison for a team update may need only a short factual summary.

Write: “This will let Operations choose whether to renew Supplier A or run a short tender.” That sentence tells you which facts matter and which interesting details can stay out.

3. Scope and exclusions

Name what is included, then name one or two things that are not. For example: “Include the current contract, delivery performance and total cost. Do not renegotiate terms or contact suppliers yet.” Exclusions are not negative; they protect the time and authority boundaries of the assignment.

If the requester does not know the boundary, offer a sensible proposed boundary rather than sending a blank question. You are making the work easier to steer, not demanding that someone design the whole task for you.

4. Owner, reviewers and deadline

Identify who prepares the first version, who gives feedback and who makes the final call. Then separate the review date from the final use date. A document needed in a Friday meeting may need a Wednesday review to allow changes.

This is also the moment to surface a conflict. If the work will displace another committed deliverable, state the trade-off plainly. The practical format in How to Communicate Project Status Without Being a Nag is a good model: status, facts, next step and the attention needed.

5. First checkpoint

Set the earliest point at which a wrong interpretation can be corrected. It could be a ten-minute check-in, an outline, two options, or a sample page. Do not wait until the final draft if the requester has strong preferences or the task depends on a judgment call.

A checkpoint gives you permission to move while keeping the requester involved at the right moment. It is far more efficient than asking for approval after every small action.

A practical example

Imagine a manager says, “We need to improve the onboarding material before the new hires start.” A rushed response might be, “Sure, I’ll review it.” That sounds cooperative but leaves several unanswered questions. Which material? What does better mean? Are new hires starting next week or next month? Who approves changes?

Turn it into this brief:

Outcome: a revised first-day onboarding guide and a one-page checklist for managers.
Decision/use: HR will use it for the September intake and decide whether a short live orientation is still needed.
Scope: cover the first day, access setup and required policies; exclude redesigning the full training programme.
People/dates: I will draft it, HR will review it by Tuesday, and the People Lead will approve the final version on Thursday.
Checkpoint: I will share the proposed outline tomorrow morning before rewriting the existing guide.

Notice what this does not do: it does not create bureaucracy. It gives the manager a compact chance to correct the objective before a larger piece of work begins. It also makes the approval route visible, so a draft does not sit in a shared folder waiting for an unknown person to respond.

Questions that clarify without sounding difficult

You do not need to ask all five questions every time. Listen for the missing piece that would change your work, then ask a short question with a proposed answer.

• “Should the final output be a recommendation, a draft message or a presentation?”
• “Is the goal to decide this week, or to prepare options for the next planning meeting?”
• “I can cover the customer impact and cost. Should I leave legal review to the specialist team?”
• “If Friday is the final meeting, may I send you an outline on Wednesday for direction?”

These questions work because they give the other person an easy choice. They follow the same principle as the focused prompts in How to Ask Smart Questions in Meetings: show the context, name the answer you need and explain the decision it supports.

When to write the brief before starting

Use this method whenever the task crosses a team boundary, affects a customer, needs someone else’s approval, or will take more than an hour. It is also worth using for recurring work that repeatedly returns for “small” changes. The repeating changes may be evidence that the real definition of done was never written down.

Keep the brief useful after the request is accepted

Once work begins, the brief becomes the reference point for updates. If the scope changes, edit the line that changed and state the consequence: “Adding regional pricing will move the review from Wednesday to Thursday.” This is more useful than silently expanding the work and hoping the date still holds.

When a choice is made, record it in a simple decision log rather than relying on meeting memory. How to Create a Decision Log for Your Team explains how to capture the decision, rationale, owner and date without turning it into a transcript.

If the task needs uninterrupted time, protect a block tied to the brief’s outcome. A calendar entry such as “Draft supplier recommendation for Tuesday review” is easier to defend than a vague “focus time” label. The approach in How to Protect Focus Time Without Looking Unavailable helps you communicate that boundary without disappearing from your team.

Common mistakes

Writing a project plan for a small request

Start with the five lines. Add detail only when it changes a decision, a handoff or a risk. A brief should reduce friction, not become another document to maintain.

Using a deadline with no review point

Final deadlines do not protect you from wrong direction. Put an early checkpoint on any task where the requester’s judgment matters.

Assuming the requester owns every decision

Sometimes the person who assigned the task cannot approve the budget, legal wording or customer commitment. Name the final decision-maker early so the work reaches the right person before the deadline.

Final takeaway

A vague request is not a sign that anyone is careless; it is usually a sign that context is still sitting in someone’s head. A decision-ready brief moves the essential context into a form the team can act on. Define the outcome, the decision it supports, the scope, the people and dates, and the first checkpoint. You will spend less time guessing, reduce last-minute rewrites and make it easier for other people to help at the right time.