Before Work Starts: A One-Page Brief for a Small Team Project

When a small team project needs a brief

A brief is most useful when a request involves shared effort, meaningful trade-offs, or more than one reasonable interpretation.

Before a modest team project begins, agree on its purpose, intended result, boundaries, owner, approver, and evidence of success. Capture those agreements in a short shared brief so collaborators can check that they are solving the same problem.

Not every task needs a document. If one person can complete a clear, low-risk task without affecting other work or requiring approval, a message or task description may be enough. A brief becomes more useful when several people are involved, the request is vague, the work could expand, or someone expects a particular result.

Think of the brief as an early agreement, not a promise that the project will succeed or a detailed delivery plan. The Project Management Institute describes a project charter as a way to establish the business need, objectives, high-level scope, stakeholders, assumptions, constraints, and success criteria, while distinguishing it from a more detailed project plan. A small-team brief can adapt those ideas without being treated as a universal standard.

• Use a brief when teammates may understand the request differently.
• Scale the detail to the work’s uncertainty and consequences.
• Check whether your organization requires a specific approval or document.

Turn the request into a clear purpose

Start with the need behind the request, then describe an outcome the team can recognize.

Write one or two sentences about what prompted the work and who it is meant to help. “Refresh the website” describes an activity, not the underlying need. Ask what is confusing, outdated, or missing, and for whom. The answer gives the team a basis for deciding which work belongs in the project.

Next, describe the intended outcome in observable terms. “Make the site better” is hard to assess. “Help customers find current returns information without contacting support” gives the team something more concrete to check. If a measure would help, state what will be observed and who can confirm it. Do not invent a numerical target just to make the brief look precise.

Keep the intended outcome distinct from the deliverable. The deliverable is what the team produces, such as revised FAQ pages. The outcome is the change the work is meant to support, such as making answers easier to find. The team may deliver the pages without achieving the broader outcome, so the brief should not treat the two as interchangeable.

Use this one-page project brief template

A compact template keeps the conversation focused and makes missing agreements visible.

Copy the fields into a shared document and write plainly. Short phrases are fine when they are clear. Mark unanswered items as open rather than filling gaps with guesses. UK government project-management guidance notes that a small-project brief can be very short and includes topics such as objectives, scope, deliverables, assumptions, risks, stakeholders, and outline time and cost estimates. Treat these as useful prompts, not mandatory wording for every team.

Make the project scope concrete

A clear in-and-out list prevents a modest request from quietly expanding into a different project.

Imagine a small business asks its team to update the customer FAQ. That phrase could mean correcting a few answers, redesigning the page, reviewing every support policy, or rebuilding the help center. The brief should say which interpretation the team is taking.

For example, the agreed scope might include reviewing the existing FAQ, correcting approved answers about returns and shipping, and publishing those revisions on the current page. It might exclude changing the returns policy, redesigning the website, adding languages, or rewriting unrelated support materials. These are illustrative boundaries, not recommended requirements; the project owner and relevant decision-makers should choose what fits their actual request.

A useful test is to ask someone who was not in the original conversation what they think the deliverable includes. If their interpretation differs from the team’s, refine the wording. “Improve the FAQ” invites debate later; naming the pages, topics, and exclusions makes the boundary easier to check.

• Name the deliverable, not just the activity.
• List likely adjacent requests that are outside the current scope.
• Identify who must supply or approve content, access, or policy decisions.

Agree on ownership, approval, and uncertainty

Clear roles help the team move forward without guessing who can make commitments.

The owner coordinates the work, keeps the brief accessible, and brings unresolved questions to the right people. The approver authorizes the project or accepts its outcome, depending on the organization’s process. In a small team, one person may fill both roles; say so explicitly rather than leaving responsibility implicit.

Separate assumptions from confirmed facts. “The support team will provide current shipping wording” is a dependency if the project needs that input. “The wording is already approved” is an assumption unless someone has confirmed it. For important open questions, name who will resolve them and when or under what condition they need an answer.

Distinguish a target from a commitment, too. A preferred delivery window is not necessarily an approved deadline, and a rough estimate of resources is not budget authorization. If timing, spending, customer commitments, or compliance approvals matter, note who can confirm them and follow the relevant internal process. A charter or brief can make authorization and alignment clearer, but it does not replace local controls.

Review the brief together before work begins

A short review tests whether the draft reflects a shared agreement rather than one person’s interpretation.

Bring together the people doing the work and whoever can authorize it. Read the purpose, outcome, and exclusions aloud. Check that the deliverable is specific enough to recognize when complete, and that the proposed measure can actually be observed. Invite collaborators to flag missing expertise, access, or dependencies.

1. Ask each participant to summarize the goal in their own words. Clarify differences before work starts.
2. Check that the deliverable and exclusions fit the purpose. Remove unrelated tasks or identify them as separate work.
3. Review assumptions, constraints, risks, and dependencies. Give important open questions an owner and a point for follow-up.
4. Confirm who authorizes the work, who approves the result, and whether other internal sign-off is needed.
5. Save the agreed version somewhere the team can find it, and mark its status so nobody mistakes a draft for an approved brief.

Use the brief, project plan, and decision log for different jobs

Keep each record focused on its own question, even if a very small project combines them in one file.

The brief answers, “What are we doing, and why?” It captures the purpose, boundaries, owner, and intended success. A project plan answers, “How and when will we deliver it?” It can hold tasks, sequencing, dates, and assignments when the work needs that level of coordination. A decision log records choices made as work proceeds, including the question, decision, rationale, owner, and next step.

For a small project, the plan might be a short checklist and the decision log a few entries in a shared document. Avoid copying every detail across all three. The brief can point to the plan and log while remaining the reference for the original agreement.

If a material change emerges—such as a new audience, a different intended outcome, or substantial work beyond the agreed scope—pause and check with the approver. Update the brief or record the approved change wherever your team documents authorization. Small clarifications may belong in the plan or decision log instead. The practical next step is simple: draft the brief from the request, review it with the people doing and authorizing the work, and use it to decide whether a separate task plan is needed.