A project brief is not bureaucracy. It’s the document that saves everyone from three rounds of scope creep, two rounds of rework, and one awkward retrospective.
Use this checklist before any project — campaign, migration, system setup, or operational improvement — moves from idea to execution.
1. Project objective
- What problem does this project solve?
- What opportunity does it capture?
- Why is this being done now, not later?
- What does “success” look like at the end?
Prompt: Write one sentence that completes this: “This project exists to _______ so that _______.“
2. Scope
- What is explicitly in scope?
- What is explicitly out of scope?
- Are there any adjacent areas that could creep in — and have you named them as out of scope?
- What decisions are already made vs. still open?
Prompt: If someone joined the project two weeks in, could they read this section and know what to work on?
3. Deliverables
- What are the concrete outputs — documents, systems, reports, campaigns, integrations?
- What format should each deliverable be in?
- Who is each deliverable for?
- What does “done” mean for each deliverable?
Prompt: List each deliverable and attach a definition of done.
4. Stakeholders and ownership
- Who is the project owner or DRI (directly responsible individual)?
- Who are the core team members and what is each person responsible for?
- Who are the key stakeholders who need to be informed or consulted?
- Who has final approval authority?
- Who should not be surprised at launch?
Prompt: Could you draw a simple RACI (Responsible / Accountable / Consulted / Informed) for the key decisions in this project?
5. Timeline and milestones
- What is the target completion date or launch date?
- Are there fixed external deadlines (campaign date, event, platform migration window)?
- What are the major milestones between now and done?
- Which milestones are dependencies for other teams?
Prompt: Mark which dates are hard constraints and which are targets.
6. Constraints and dependencies
- Budget constraints, if applicable
- Technical constraints or system limitations
- Team availability or capacity constraints
- External dependencies (vendors, platforms, approvals, legal review)
- What can block this project?
7. Success criteria
- How will you know the project succeeded?
- What does good look like at 30/60/90 days after launch?
- Are there qualitative and quantitative criteria?
- Who signs off that the criteria are met?
Prompt: Write measurable or observable outcomes. “It should feel better” is not a success criterion. “Editorial team can publish without developer help” is.
8. Risks and open questions
- What are the top 2–3 risks to delivery?
- What are the open questions that could change scope or approach?
- Who owns each open question and when will it be resolved?
Before you start execution: share this brief with the core team, confirm alignment, and get the project owner’s sign-off. A brief without sign-off is a draft, not a contract.