# How to write a one-page project brief that makes the next step clear. Turn a mission into a bounded piece of work: one person, one problem, one complete promise, and a decision gate. Includes a worked example and a downloadable brief template. ## The direct answer A useful one-page project brief names whom the work serves, the problem and evidence behind it, the smallest complete promise, what is in and out of scope, the owner and constraints, and how the next decision will be made. It aligns people before detailed planning. Keep assumptions labelled, give unknowns an owner, and link to a separate pilot plan when the promise needs testing. - Author: Daniel Ziedins (https://www.danielziedins.com) - Published: Oct 18, 2026 - Updated: Oct 18, 2026 - Scripture: Luke 14:28 - Read: 7 min - URL: https://www.agent-six33.com/journal/how-to-write-a-one-page-project-brief > For which of you, desiring to build a tower, does not first sit down and count the cost > — Luke 14:28 A mission can be true and still be too broad to assign. Help our community, build a better resource, and make the experience easier express intention. They do not yet tell a collaborator what they are responsible for delivering, what they should leave alone, or when the work is ready for a decision. A brief is the bridge between the intention and the work. This guide offers an original working format for a small, low-risk initiative, not a contract, funding application, safeguarding process, or professional approval. A page is a useful constraint, not a virtue in itself: link to essential detail instead of making safety, accessibility, or important dependencies disappear to fit a layout. ## 1. Name a person, a situation, and a job to finish. Write who needs help, when the difficulty occurs, and what the person is trying to accomplish. For example: a first-time volunteer needs to identify an available role before contacting the team. That sentence is more useful than we need an improved portal because it leaves room to discover whether a portal is needed at all. GOV.UK's discovery guidance recommends understanding the problem and questioning a preselected solution before committing to build. Apply that distinction to your brief: keep the user's task on one line and your proposed response on another. Include people who may need a different format or support route. Do not define the audience only as the people most convenient for your team to recruit. ## 2. Put evidence, assumptions, and unknowns on separate lines. Evidence might be a dated support request, a source-linked interview finding, or an observed difficulty with the current version. Record what the source actually supports. A request for a printable sheet supports investigating that format; it does not prove that every visitor wants print or that a sheet will improve the outcome you care about. Write assumptions explicitly. We assume the role list can be kept current is operationally important, not embarrassing. Then assign a person to check the unknowns that could change the approach. If nobody knows who owns the information, that unanswered question may be the first piece of work. A polished brief is not permission to convert an untested assumption into a public claim. **Create a traceable research finding:** Keep source observations, interpretations, and the resulting decision connected. https://www.agent-six33.com/journal/how-to-synthesise-customer-interviews ## 3. Define the smallest complete promise and its boundaries. Describe what a person will be able to do with the delivery. Then state the minimum contents or behaviour needed for that promise to be real. A role sheet might need available options, the date checked, a clear way to confirm a place, and an alternative contact method. A beautiful title without usable information is not a complete delivery. Put exclusions beside inclusions. For this version, perhaps no accounts, automated matching, public directory of volunteers, or collection of personal stories. An exclusion should protect focus without quietly excluding people: no account needed is different from no assisted option offered. If an essential access need cannot be met, record the gap and resolve it before calling the delivery ready for those users. ## 4. Assign ownership, constraints, and a real handoff. Name one person responsible for the delivery and another, if needed, who can approve its factual accuracy or operational use. State the time and resources actually available, the review date, and dependencies that could block release. Use an explicit unknown rather than inventing a budget or deadline to make the document look finished. Agree how the delivery will stay useful after the first handoff. Who updates changed information? What happens if that person is unavailable? Where can a reader report a mistake? A brief for a small resource does not need a large governance system, but it does need someone who accepts the maintenance task. Otherwise a successful launch can become an unreliable promise a week later. ## 5. Read a worked example with a deliberately limited claim. This is a hypothetical example, not a SIX33 project result. A community team wants first-time volunteers to choose a suitable role before the next session. Its evidence is a source-linked finding from a small interview round: some participants described needing extra contact to understand which roles were available. The team still does not know whether unclear wording, stale information, or another issue caused the difficulty. The first delivery is one dated, mobile-readable and printable role list with an accurate confirmation route. Accounts and automated matching are out of scope. A named coordinator checks the information before sharing and owns updates. The release gate is that the information is checked, the contact route works, and the required formats are reviewed. Passing that gate establishes delivery readiness, not improved volunteering outcomes. A separate pilot then observes whether people can select a suitable role and identify the next step without assistance. The brief points to that test rather than declaring a success threshold after seeing results. If people still need help, the next decision is to investigate the remaining barrier. Neither publishing a sheet nor receiving praise is counted as a life changed. ## 6. End with the next decision, not an endless feature list. Distinguish a delivery check from a learning check. Delivery checks ask whether the agreed work exists and functions. Learning checks ask whether the intended person can use it or whether a proposed explanation deserves more investigation. A longer-term outcome claim needs an appropriate method and follow-up beyond either checklist. Before beginning, ask collaborators to restate the promise and the exclusions in their own words. If they describe different projects, fix the brief first. Put a version and date on the agreed document. When new evidence changes the scope, keep the reason beside the revision rather than silently rewriting the original intention. The goal is not to freeze learning; it is to make changed decisions visible. Keep a list of attractive extras outside the brief. Revisit them only if they serve the task and fit the next decision. You can have a large vision and still give today's work a clear edge. A brief earns its space when another person can take responsibility for a complete, useful step without needing to guess what you meant. **Write the pilot plan separately:** Specify the test, observations, limits, and decision rule before delivery. https://www.agent-six33.com/journal/how-to-plan-a-small-pilot ## One-page project brief Copy this blank template into your private working document. It contains no journal notes or tool drafts. ```markdown # One-page project brief Project name, version, and date: [name / version / date] Owner: [person responsible] Decision-maker or reviewer: [person / role] ## Person and problem Who, in what situation: [specific person and context] Task they need to complete: [task] Current difficulty: [problem, not a preselected feature] Evidence and source links: [dated findings / private source pointers] Assumptions: [not yet established] Unknowns that could change the approach: [unknown / owner / check date] ## Complete promise After this delivery, the person can: [one useful action] In scope: [minimum complete contents or behaviour] Out of scope for this version: [explicit exclusions] Accessibility and assisted alternatives: [needs / formats / gaps to resolve] ## Delivery and care Available time and resources: [confirmed / unknown] Dependencies and permissions: [requirements / owner] Review date: [date] Readiness checks: [accuracy / functional checks / required review] Maintenance and correction route: [owner / update trigger / contact] Privacy and safety boundary: [what is not collected / required review] ## Decision gate Next decision: [continue / change / stop / investigate] Evidence needed for that decision: [method and limits] Separate pilot plan, if needed: [link / version] Claims this delivery does not establish: [outcomes / prevalence / causation] Revision record: [date / what changed / reason] A working brief, not a contract or professional approval. Do not publish private source material or unresolved sensitive details. ``` > **The short version:** Keep the mission large and the next promise precise enough for somebody to own. ## Questions ### What should a one-page project brief include? Include the person and problem, the evidence and assumptions, one complete promise, scope and exclusions, an owner, constraints, review and maintenance arrangements, and the evidence needed for the next decision. Link to essential detail instead of omitting it to fit a page. ### What is the difference between a project brief and a project plan? The brief aligns people on why the work matters, what it includes, and who owns it. The plan details tasks, dependencies, timing, and delivery. A pilot plan additionally specifies the question, observations, limits, and decision rule for testing a promise. ### Can I write a project brief before doing interviews? Yes, as a provisional brief with assumptions clearly labelled. Use it to identify what you need to learn rather than to claim that demand is established. Revise it when relevant evidence changes the person, problem, scope, or proposed approach. ### Does completing the brief mean the project is validated? No. A brief records an agreed intention and a decision process. Completing it does not demonstrate demand, usability, impact, safety, or professional approval. Those require evidence and reviews appropriate to the claim and the risks of the actual work. ## Sources - GOV.UK Service Manual: how the discovery phase works: https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works — Further reading on understanding a problem, constraints, and assumptions before committing to a solution. The brief format and volunteer-role example are original illustrations, not a government template. - GOV.UK Service Manual: learning about users and their needs: https://www.gov.uk/service-manual/user-research/start-by-learning-user-needs — Reference for keeping a person's task distinct from a proposed feature. This small-project aid does not replace a formal discovery process. ## Explore the wider topic - Research and testing: https://www.agent-six33.com/journal/topics/research-and-testing — Daniel Ziedins · https://www.danielziedins.com · AGENT SIX33 https://www.agent-six33.com/journal/how-to-write-a-one-page-project-brief