How to Write a Project Brief: Context, Success Criteria and Decisions

A project brief is not a miniature proposal. It is the document that turns an approved idea into a shared delivery record. A good brief tells the team why the work matters, what will count as success, which dependencies can delay it, and who gets to decide when trade-offs appear.

This article uses a consulting scenario: a client has approved a strategy review of its customer onboarding process. The consulting team must diagnose delays, recommend process changes and hand over a recommendations report. The brief is written after commercial approval but before discovery starts. All sample language is illustrative and should be adapted to the project, organization and jurisdiction.

Begin With Business Context

Start with the business situation, not the methodology. The reader needs to understand why the project exists before they read about interviews, workshops or deliverables.

Weak draft

This project will review onboarding and provide recommendations.

That sentence describes activity, but not the business reason. It leaves the team guessing what problem they are solving.

Stronger draft

[Client] reports that new enterprise customers are taking longer than expected to move from signed order to first productive use. The sponsor wants to identify the main causes of delay, decide which changes are worth implementing in the next quarter, and create a practical recommendations report for the leadership team.

Annotate the sentence as you review it:

• "Reports" is honest if the project has not yet verified the claim.
• "Signed order to first productive use" defines the process being reviewed.
• "Decide which changes are worth implementing" names the decision, not just the analysis.
• "Next quarter" sets a planning horizon.

Public project guidance often emphasizes alignment between project work and documented objectives. The California Project Management Framework says monitoring and controlling compares progress and status reports against project plans so potential issues or risks can be identified early (CA-PMF Monitoring and Controlling). Your consulting brief is earlier than a status report, but it should create the baseline those later reports use.

Write Success Criteria That Can Be Checked

Success criteria should separate business outcomes from project outputs. The team may control the report. The client controls whether the recommendations are funded and implemented.

Project output. A recommendations report that identifies the main onboarding delay points, explains the evidence behind each finding, compares practical improvement options, and states which decisions are needed from the sponsor.

Success criteria. The sponsor can use the report to approve, reject or defer the recommended changes by [decision date]. Each recommendation is tied to evidence gathered during discovery and has an owner for next-step planning.

This avoids the common overpromise: "reduce onboarding time by 40 percent." Unless the consulting engagement includes implementation and the team has verified baseline data, that is not a project brief success criterion. It is a possible future business metric.

If the project does include measurable targets, state the source and baseline:

Current baseline: [metric], measured from [system or report] for [period]. Target for implementation planning: [target], subject to validation during discovery.

The Federal Acquisition Regulation's service-order guidance requires statements of work for certain service orders to include work description, location, performance period, deliverable schedule and applicable performance standards (FAR 8.405-2). That is a procurement rule for federal orders, not a universal project brief rule. Still, it is a good reminder that "success" should be visible in schedule, deliverables and standards, not hidden in broad intent.

Map Dependencies Before They Become Excuses

A dependency is anything outside the delivery team's full control that can affect the work. Put dependencies in the brief so they are managed, not rediscovered during delivery.

Useful dependency language:

Client access. The sponsor will nominate up to [number] stakeholders for interviews by [date]. If interviews are not scheduled by [date], the discovery phase may move by the same number of delayed business days.

Data. [Client] will provide onboarding timestamps, issue logs and current process documents listed in Appendix A. If data fields are incomplete, the team will state the limitation in the findings rather than estimate unsupported figures.

Decision availability. The sponsor will attend the midpoint findings review on [date] or nominate a delegate authorized to confirm priorities.

Notice how each item contains an owner, date and consequence. "Client to provide data" is not enough. Which data? By when? What happens if it is missing?

Dependencies should include internal consulting dependencies too:

• Engagement lead available for sponsor reviews.
• Analyst assigned to evidence log.
• Quality reviewer scheduled before final delivery.
• Confidential material stored in the approved location.

This keeps the brief from becoming a document that only asks things of the client.

Name Decision Owners And Review Roles

Many project briefs fail because they list stakeholders but not authority. Separate people who provide input from people who approve decisions.

Sponsor and decision owner: [Name, title]. Approves scope trade-offs, final recommendations and any change to the delivery date.

Subject matter experts: [Names or roles]. Provide process facts and review factual accuracy. They do not approve scope changes.

Consulting delivery lead: [Name]. Owns the project plan, evidence log and draft report.

Quality reviewer: [Name]. Reviews whether findings are supported by evidence before the report is issued.

The Department of the Interior's service-contract checklist asks whether there are sufficient resources to evaluate contractor performance when advice, analysis or recommendations may influence agency decision-making (DIAR 1437.1). In a private consulting project, the principle is the same: someone needs enough authority and knowledge to evaluate the recommendation before it becomes a decision.

Do not hide the decision route in a RACI table unless the team already uses one consistently. A small table can help, but a plain-language paragraph is often clearer.

Add The Draft Brief Language

Here is a compact project brief section you can adapt:

Business context. [Client] wants to reduce friction in enterprise customer onboarding. The immediate decision is which process changes should be prioritized for implementation planning in [quarter].

Project outcome. The project will produce a recommendations report that identifies delay points, explains the evidence reviewed, compares improvement options and states the sponsor decisions needed.

Scope. Included: stakeholder interviews, review of supplied onboarding records, process map of current handoffs, options analysis and final recommendations report. Excluded: implementation, software configuration, legal review of customer contracts and changes to customer-facing terms.

Success criteria. The sponsor can approve, reject or defer each recommendation by [date] because the report states evidence, assumptions, impact, owner and next step.

Dependencies. Interview access, data availability and sponsor review dates are listed in Appendix A. Delays or material gaps will be recorded in the project status report.

This language is deliberately practical. It gives the project team enough to start, without pretending the brief is a full statement of work.

Review And Use The Brief

Before approval, check the brief against these gates:

• Context: does the opening explain why the project exists?
• Decision: is there a named decision the work supports?
• Scope: are included and excluded activities both stated?
• Success: can the sponsor check whether the output is usable?
• Dependencies: does each dependency have an owner, date and consequence?
• Roles: are reviewers separated from approvers?
• Evidence: does the brief say where facts and assumptions will be recorded?

Once approved, use the brief as the baseline for status reports, change requests and handover. If a new request changes the outcome, scope, date or decision owner, update the brief or create a change request. Do not let the live project drift away from the written baseline.

Start From An Editable Structure

The consulting project brief template is an editable Word file with sections for business context, intended outcome, scope, stakeholders, dependencies, success criteria and approval. It is a starting structure for clear project alignment, not a guarantee that a project is complete, compliant or commercially protected.