How to write a project brief that prevents pointless revisions

Start with the change the work should create: what should be different when the project is complete, and for whom? A task list alone lets every participant define success differently.

Choose one simple way to recognize that outcome. It might be a published page, a completed decision, a handoff, or fewer steps in a recurring process.

Write the scope and the exclusions with equal clarity. The second list stops a reasonable request from quietly becoming a different project.

New ideas do not have to be rejected. Decide whether they replace something, belong in a later phase, or need a brief of their own.

• Outcome and audience.
• Expected deliverable or decision.
• Scope and exclusions.
• Owner, reviewers and decision date.

A list of attendees is not enough. State who prepares the work, who decides, who reviews and who only needs to be informed. Projects often stall because two people assume the other owns the decision.

A fictional repair shop wants a page where customers can request a service date. The brief includes a mobile-friendly form, an acknowledgement and an email to the shop. It excludes payments and automatic appointment confirmation. Acceptance means a valid request reaches the agreed inbox, missing required fields are explained, and a failed submission never displays success.

The acknowledgement says ‘request received’, not ‘booking confirmed’: the shop still needs to check availability. Assign one person to approve the fields and another to verify delivery. If someone later requests deposits, record it as a scope decision with additional payment and refund flows. Either replace existing scope or plan another phase; silently adding it makes the original acceptance test misleading. Copy the structure as: outcome, deliverable, exclusions, acceptance test, decision owner, dependencies.

Fictional service project: discovery is 4 hours, implementation 16 and review 4, all at $75/hour. Direct expenses are $100 and contingency is 10% of labor plus expenses. The agreed output is a tested request form, not a payment or booking system.

The extra eight implementation hours add $600 of labor and $60 of contingency. Put the $660 difference beside the new deliverable and acceptance test. It is not enough to send a new total: the reviewer needs to know what changed, what remains excluded and whether the date changes. The linked tool can export both input sets for that conversation.

Scroll the table to see every column.

Contingency is neither profit margin nor a tax calculation. Clarify payment terms and any applicable taxes separately. If the original brief is ambiguous, resolve that ambiguity before presenting the comment as additional billable scope.

• Changing implementation does not also change discovery or review without explanation.
• A rejected change leaves the approved baseline intact.
• A defect against the existing acceptance test is not automatically an extra feature.

This is a synthetic brief for the repair-shop request form described above. Roles, scope and estimate are example inputs, not a real client agreement. Copy the blank brief in the download and replace every field before using it.

The brief is ready for review, not approved for delivery: approval and a delivery date still require the named people to agree. A form that accepts a preferred date must not tell the customer that an appointment is confirmed.

Scroll the table to see every column.