Project Brief Best Practices for Consulting Teams

A project brief works best when it stops the first month of a consulting project from becoming an argument about intent. The brief should tell the sponsor, delivery lead and working team why the project exists, what output will count as usable, which dependencies can delay the work and who can decide when priorities conflict.

This article uses a consulting scenario: a regional healthcare administrator has hired a consulting firm to review referral intake across four clinics. The sponsor wants recommendations before the next budgeting cycle. The project brief is not a contract, policy or legal opinion. It is the delivery record that keeps the team honest about the business decision and the evidence needed to support it.

Start With The Business Decision

The first best practice is to write the business context as a decision waiting for evidence. Many briefs open with a broad problem statement, then jump into activities. That makes the project sound busy but leaves the sponsor unclear about the decision they will make.

Weak draft

We will analyze referral intake and recommend improvements.

That sentence could describe almost any process review. It does not identify the business pressure, the decision date or the affected operation.

Better draft

[Client] needs to decide by [date] whether referral intake should remain clinic-managed or move to a shared intake team. The current concern is that clinic managers report different triage practices, uneven queue visibility and inconsistent escalation for urgent referrals. The project will gather evidence, compare operating options and prepare a recommendation for sponsor review.

This version gives the team three anchors: the operating model question, the reported problems and the decision deadline. It also avoids treating unverified concerns as findings.

FAR acquisition-planning guidance for U.S. federal procurement says planners should align statements of work with performance outcomes and cost estimates (Acquisition.GOV FAR Subpart 7.1). A private consulting brief does not need to follow that rule unless the engagement requires it, but the habit helps: connect work to an outcome before listing tasks.

Separate Success Criteria From Optimism

Success criteria should describe how the sponsor will judge the project output. They should not promise a downstream benefit the project does not control.

For the referral-intake review, weak success criteria would say:

Success means shorter referral wait times and happier clinics.

That may be the business hope, but the consulting team may only be authorized to diagnose and recommend. A stronger brief separates the deliverable from later implementation.

Project output: a recommendations report that compares clinic-managed, shared-team and hybrid intake models against agreed criteria.

Success criteria: the sponsor can approve, reject or defer each recommended operating change because the report states the evidence used, assumptions, operational impact, expected implementation owner and unresolved decisions.

This wording gives reviewers something to inspect. They can ask whether each recommendation has evidence, an owner and a stated assumption. They do not have to debate whether the report "feels strategic."

If the project includes measurement, name the baseline source:

Baseline referral cycle time will be drawn from [system] for [period]. Any missing fields will be listed as a data limitation rather than estimated without support.

For U.S. federal schedule service orders, FAR 8.405-2 says statements of work include a work description, location, performance period, deliverable schedule, applicable performance standards and special requirements when ordering covered services (Acquisition.GOV FAR 8.405-2). A consulting brief can use the same discipline at a lighter level: what will exist, when it is due and what standard makes it usable.

Make Dependencies Operational

Dependencies deserve more than a risk sentence. A useful brief states the required input, the owner, the date and the consequence if the dependency fails.

Decision analysis: incomplete referral data

Suppose the client can provide referral timestamps from two clinics but not the other two. The brief should not bury that in a risk register. It affects the evidence behind the recommendation.

Dependency: [Client data owner] will provide referral timestamp exports for all four clinics by [date], including receipt date, triage date, urgent flag and closure date.

If incomplete: the consulting team will show findings by available clinic, identify missing fields and ask the sponsor whether to continue with a limited evidence base or extend discovery.

This clause protects both sides. The client sees the data requirement before the schedule depends on it. The consulting team avoids pretending a partial dataset can support a systemwide conclusion.

Add the same treatment for access and decision availability:

Avoid vague phrasing such as "client availability may affect timing." It does not give anyone an action.

Name Decision Owners Before Committees Form

Stakeholder lists often create false comfort. Ten names in a table can still leave nobody accountable for the hard call. Best practice is to separate input, review and approval.

Worked example: intake operating model

Sponsor and decision owner: [Name], Chief Operating Officer. Approves the project brief, confirms operating models to compare and decides which recommendation moves to implementation planning.

Clinic reviewers: [Names]. Validate current-state descriptions and flag operational constraints. They do not approve scope changes.

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

Quality reviewer: [Name]. Checks that conclusions are supported by evidence before sponsor review.

This structure prevents a common failure mode: every reviewer comments on scope, but no one owns the trade-off. A project brief should make disagreement easier to resolve, not merely easier to document.

Add a short decision log starter:

The U.S. Department of the Interior acquisition rule for service contracts asks whether agencies have enough resources to evaluate contractor performance when advice, analysis or recommendations may influence decision-making (DIAR 1437.1). Outside that procurement context, the lesson still applies: recommendations need a capable evaluator, not just an interested audience.

Keep Scope Boundaries Close To The Temptation

Scope boundaries work when they mention the adjacent work people will ask for. A generic exclusion line can be technically neat and operationally useless.

For the referral-intake scenario, these boundaries are more useful than "out of scope items excluded":

Included: intake workflow review, stakeholder interviews, referral timestamp analysis, operating model comparison and recommendations report.

Excluded: software procurement, staffing negotiations, patient communication scripts, legal review of clinical obligations and implementation management.

Change route: adding an excluded item requires sponsor approval and a revised brief or change request.

The exclusions are specific because the project sits near sensitive topics. A clinic manager may expect staffing decisions. An IT lead may expect system selection. The brief needs to route those requests before they become implied work.

Use The Brief After Approval

A project brief loses value if the team treats it as a kickoff artifact only. Use it as the baseline for status reports, change requests and final acceptance.

During delivery, compare new requests against four questions:

• Does this change the business decision?
• Does this change the evidence needed?
• Does this change the delivery date or sponsor review?
• Does this change who can approve the output?

If the answer is yes, update the brief or create a change record. If the answer is no, add the task to the workplan without reopening the whole document.

The best project brief practice is consistency. Start with the decision, write checkable success criteria, make dependencies operational, name decision owners and keep scope boundaries close to predictable misunderstandings. That gives the consulting team a document they can use when the project becomes messy, which is exactly when a brief earns its keep.

Worked example: approve discovery before implementation

In the referral-intake scenario, the sponsor may want a new system immediately even though the team has not established where delays occur. Treat approval of the discovery work and approval of a system purchase as separate decisions.

For an illustrative discovery budget, allow 40 analyst hours at an internal cost of $90 per hour and 10 reviewer hours at $120 per hour. The estimated labor cost is $4,800. A 15% contingency adds $720, bringing the planning allowance to $5,520 before any additional expenses or taxes. These are example assumptions, not market rates or a supplier quote.

Use a consulting project budget from Stackrows to maintain the calculation and its assumptions. The project brief should identify the investigation boundaries, evidence required, responsible sponsor and conditions for completion. It should make clear that the discovery allowance does not authorize software procurement or implementation.

The approval presentation can then answer four questions:

1. What problem is evidenced, and what remains uncertain?
2. What will the discovery work establish?
3. What funding and staff access are being requested now?
4. What later decision will require a separate business case?

Deckary’s business case guide provides a structure for presenting the costs, alternatives, risks and recommendation. Apply it to the decision actually on the table. After approval, record the authorized scope and allowance in the brief, retain the supporting workbook version, and route any implementation request through a new decision.

Start From An Editable Structure

The consulting project brief template gives you editable Word sections for problem and intended outcome, scope and constraints, stakeholders, delivery plan, success criteria and authorization. Use it as a working draft, then replace every example with verified project facts and sponsor-approved decisions.