A broad ambition becomes easier to work with when you can describe the situation, the decision and the limits. Use this brief to prepare for an internal discussion or a conversation with an adviser.
Put the problem into five sentences
- Situation: Describe what is happening and where it happens.
- Consequence: Explain the effect on customers, colleagues, cost, time or quality.
- Decision: Name the choice that needs to be made and the person responsible for it.
- Evidence: List the observations or records that could help explain the situation.
- Boundary: State the timing, budget or operational constraint the work must respect.
A working example
A fictional service team receives customer requests through several inboxes. Some requests are forwarded more than once, and nobody can easily see which ones are unassigned. The team needs to choose a single intake process before its next service review. It can inspect a sample of handoffs and response times. The solution must work with its existing tools.
That brief leaves room to investigate. It does not assume that new software is the answer before the team understands the problem.
Decide what progress would look like
Choose one result the team can observe: fewer unassigned requests, a clearer handoff or a shorter response time. Write down how it would be measured and when the team will review it.
Build a usable project outline
Once the five-sentence brief is clear, expand it into a small working outline. Add detail only where it helps someone investigate, decide or carry out the next step.
| Section | What belongs in it | What makes it useful |
|---|---|---|
| Problem | The observed situation and who experiences it. | People doing the work recognize the description. |
| Decision | The choice, decision owner and timing. | The team knows what the work must enable. |
| Scope | Included work and explicit boundaries. | New requests can be compared with an agreed starting point. |
| Evidence | Available records and important gaps. | The investigation begins with something concrete. |
| Output | The document, test or recommendation needed. | Someone can explain how it will be used. |
| Review | The test of progress and the next decision. | The work has an endpoint and a learning step. |
Develop the service-team example
In the fictional intake example, begin by mapping ten recent requests from arrival to assignment. For each request, note where it arrived, which team first saw it and where responsibility became clear. Record an exception when a request followed a different route.
The first output is a shared picture of the process. The next output is a short comparison of feasible intake options. A single queue, a rotating coordinator and clearer routing rules may have different costs and limitations. The team should examine those trade-offs before choosing a new system.
A practical test could run one proposed route on a limited category of requests. Name who watches for unassigned items, who can resolve a problem and when the team will review the result. Keep the existing route available if the test interrupts customer work.
Evaluate the outline before committing to it
Read the brief as though you were joining the work tomorrow. Can you tell what to investigate first? Is there a decision owner? Does the proposed evidence actually relate to the problem? Is the output small enough to complete within the boundary?
Use a simple readiness check:
- Clear: The next action, responsible person and purpose are understood.
- Incomplete: A missing detail needs an answer before the action can begin.
- Exploratory: The action is intended to answer the missing question.
This distinction prevents every uncertainty from becoming a reason to stop, while keeping genuine blockers visible. A team can investigate the frequency of a problem without knowing the final answer. It may still need permission to access the underlying records before starting.
Common questions
Should the brief include a budget? Include the budget boundary when one is known. If it is unknown, identify who can set it and avoid treating an unsupported estimate as an agreed amount.
What if people disagree about the problem? Capture the competing descriptions and the evidence that could distinguish them. That disagreement may define the most valuable first investigation.
When should the brief change? Revise it when the evidence, decision or constraints change. Record the reason so participants understand how the work developed.
The full project-brief guide develops this example into a one-page working document. Use it to expose missing information, compare possible next steps and keep the conversation focused on a decision.