The project has a name, a deadline and three people already working on it. Ask them what success looks like and you get three different answers. One expects a new system. Another expects less admin. The sponsor expects both, with no disruption to clients.
A one-page project brief gives a small team an agreed purpose, outcome, scope, owner, milestones, constraints and acceptance checks before detailed planning starts. Keep unresolved questions visible with an owner and decision date. The brief aligns expectations; the project plan sequences the work.
Photo by Brands&People on Unsplash.
What should a one-page project brief explain?
“Implement a CRM” describes an activity. “Give the delivery team an agreed client record at handover” describes a business outcome. The second makes it easier to decide whether a proposed feature belongs in the project.
Write the current problem in two sentences. Add the people affected and one observable result. If you cannot describe the problem without naming a product, pause and talk to the people doing the work.
Use these seven fields
Purpose and outcome: What will work differently, for whom, and why does it matter now?
Scope and boundaries: Which deliverables are included? What is explicitly outside this project?
Owner and sponsor: Who runs the work day to day? Who approves trade-offs affecting budget, scope or the agreed deadline?
Milestones: What evidence will show progress at the main checkpoints?
Constraints and dependencies: Which people, access, supplier inputs and operational commitments shape the plan?
Risks and open decisions: What might prevent delivery, who will investigate it, and when is a decision needed?
Acceptance: Who confirms completion, using which checks?
Use names where possible. “Management” is a weak answer when two managers assume the other will approve something. Mark unknowns honestly, with an owner and a date for resolving them.
A worked example: improving a client handover
Consider an illustrative service business replacing its email-based sales-to-delivery handover. Its brief could read:
Outcome: Delivery receives the agreed scope, client contact and required access in one shared record before kickoff.
In scope: A handover form, ownership rules and a trial with the next suitable new clients.
Out of scope: Replacing billing software or migrating the entire historical client database.
Owner: Operations lead. Sponsor: managing director.
Checkpoints: Agree fields; test with a completed case; trial live handovers; review missing information and follow-ups.
Open decision: The sponsor must confirm which existing tool will hold the record before configuration starts.
Acceptance: Sales and delivery can complete the agreed handover checks, and the sponsor accepts the trial results.
This is deliberately narrower than “improve onboarding”. It gives the team a boundary they can discuss and a result they can check.
Make the brief usable after kickoff
Review the page with the sponsor and the people responsible for delivery. Ask each person to explain the outcome and their role in their own words. Differences are useful information, especially before anyone commits a delivery date.
Keep the agreed version somewhere everyone can find. Record later changes with the decision, owner and effect on the plan. A brief can evolve, but a silent change creates a different agreement for each reader.
The brief is a starting agreement. Your project plan turns it into sequenced work, responsibilities and review points. Avoid squeezing the whole schedule onto this page.
Project brief vs project plan: which do you need?
Use a brief when the team disagrees about what the project must achieve or who can approve it. Use a plan when the outcome is agreed and you need to sequence work, allocate capacity and manage dependencies. If the brief changes, review the plan as well. A detailed schedule cannot settle an unresolved business outcome.
If a project is already moving but nobody can agree what it must deliver, Hili Consulting can help clarify the brief and the decisions holding it up. Discuss your project requirements and bring the current outline, even if it is only a few notes.
