# How to write a project brief that prevents pointless revisions

https://techy.eus/en/resources/write-a-project-brief
Updated: 2026-10-04

A useful brief is not a polished presentation. It is a short agreement that lets people make decisions without guessing what the project was meant to achieve.

Techy · Editable offline copy. Examples are illustrative, not customer results. Review the guide's limitations before applying it.

## Describe the outcome before the tasks

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.

## Name what is outside the work

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.

## Make decision ownership visible

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.

## Worked example: a request form is not a booking engine

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.

## Price one change without quietly rewriting the agreement

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.

Worked example · fictional inputs

| Version | Labor | Subtotal | Contingency | Estimate |
| --- | --- | --- | --- | --- |
| 24 hours in the baseline | $1,800 | $1,900 | $190 | $2,090 |
| 32 hours after a scoped change | $2,400 | $2,500 | $250 | $2,750 |

## Test the result and handle the exception

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.

## A completed one-page brief to copy

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.

Completed fictional brief · request form · version 1

| Field | Agreed proposal to review |
| --- | --- |
| Reader and problem | Repair-shop customers need to request a service date; the shop needs service, preferred date and contact details to assess availability. |
| Outcome | A customer can send a complete request from a phone and the shop receives it in the agreed inbox. |
| Deliverable | Responsive request page, required-field validation, acknowledgement and email delivery to the shop. |
| In scope | Service, preferred date and contact fields; invalid-input errors; successful receipt message; failed-delivery message. |
| Out of scope | Online payments, deposits, customer accounts and automatic appointment confirmation. |
| Acceptance | A valid mobile request reaches the test inbox; missing required fields are explained; a failed send never reports success; receipt says ‘request received’. |
| Decision owner | Shop owner approves fields, copy, scope changes and release. Implementer prepares the page and records acceptance-test results. |
| Dependencies | Shop supplies approved service names, verified receiving address and authorized access to the website. Use fictional contact details during testing. |
| Sequence and timing | Approve fields and copy → implement → verify receipt and failure cases → shop owner reviews release. Agree a delivery date after dependencies are available. |
| Estimate | 4 discovery + 16 implementation + 4 review hours = 24 hours at $75: $1,800. Add $100 expenses, then 10% contingency on $1,900: $2,090. Taxes and payment terms require a separate agreement. |
| Change rule | A proposed extra 8 implementation hours adds $660 including contingency. Total becomes $2,750 only if approved; a rejected change preserves the baseline. A defect against acceptance is not extra scope. |
| Review status | Draft for approval. Record approving person, version, decision and date before work or release is authorized. |

## Your one-page project brief

Project, version and draft / approved status: ____________________

Reader and problem: ____________________

Observable outcome: ____________________

Deliverable: ____________________

In scope: ____________________

Out of scope: ____________________

Acceptance tests and evidence: ____________________

Decision owner and implementer: ____________________

Dependencies and their owners: ____________________

Milestones and agreed dates: ____________________

Hours, rates, expenses and contingency assumptions: ____________________

Taxes and payment terms to agree: ____________________

Change decision, scope effect and estimate difference: ____________________

Approval: person, version, decision and date: ____________________

Do not put passwords, patient details or other sensitive data in a shared worksheet. Downloading or checking a box does not verify real-world compliance.