A small project needs enough structure to keep commitments clear, without creating records nobody uses. Start with one shared brief that answers five questions: why are we doing this, who can decide, what will be delivered, what uncertainty matters and who accepts the result?
This is an independent lightweight planning tool, not a complete implementation of PRINCE2 or any other method. PRINCE2 itself includes tailoring; it is misleading to assume it must be applied as a large fixed document pack to every small project.
A filled one-page example
Illustrative project: introduce a shared supplier-onboarding checklist for three teams. The sample below shows the information to agree; its dates and limits are examples, not universal thresholds.
| Brief section | Example entry |
|---|---|
| Purpose | Reduce missing onboarding information; purchasing owner to compare a baseline sample with later submissions |
| Authority | Purchasing manager accepts the workflow; IT approves access; coordinator maintains the record |
| Deliverables | Agreed field list, shared checklist, access setup, instructions and handover |
| Plan | Week 1: agree requirements; week 2: build; week 3: trial; week 4: revise and hand over |
| Constraints | Use approved tools; no change to supplier-payment rules |
| Dependencies | Finance reviewer and representative users available for agreed test dates |
| Risk response | If reviewer availability slips, ask the authorised owner to nominate a delegate |
| Acceptance | Representative cases pass agreed checks; owner accepts instructions and support route |
| Benefit review | Purchasing owner reviews missing-information rate after a defined period |
1. State the reason and its limits
Separate a deliverable from a benefit. A published checklist is a deliverable. Fewer incomplete submissions is a desired outcome that needs a baseline, measure and owner. Do not report the outcome as achieved merely because the checklist launched.
Write exclusions where they prevent misunderstanding. If supplier payments or contract terms are unchanged, say so. An exclusion still needs review if a later request shows it prevents the intended outcome.
2. Name decision authority
Do not assume one sponsor can approve every kind of change. Budget, access, policy and acceptance may sit with different people. Record delegated limits and the route for an exception.
In a very small organisation, people may combine responsibilities. Make any conflicts, approval requirements and independent checks explicit rather than declaring that a combined title always means accountability has failed.
3. Make the plan testable
List deliverables, responsible people, dependencies and target dates. Include the evidence that will show completion. Tasks can also have clear completion criteria; the distinction is that deliverables describe the outputs the work must produce.
Check capacity before agreeing the dates. A four-week duration does not mean a person is available full-time for four weeks. Record existing commitments and the availability of reviewers as well as the people doing the build.
4. Track uncertainty and action
| Record | Example | Next action |
|---|---|---|
| Assumption | Finance can review in week 1 | Confirm with the reviewer |
| Threat | A missed review could delay the trial | Agree delegate and escalation date |
| Opportunity | An existing approved checklist may be reusable | Inspect it before building |
| Issue | Trial users cannot open the shared file | Assign an access fix and retest |
Choose controls according to consequence. A short project involving payments, personal data or safety can need substantial review. Duration and headcount alone do not decide how much governance is appropriate.
5. Agree acceptance and handover
- Define checks before delivery begins.
- Record the person authorised to accept each output.
- Capture outstanding exceptions and their owners.
- Confirm operational ownership, access and support.
- Keep a review date for the intended benefit.
Copy the blank brief
Purpose and benefit owner: __. Deliverables/exclusions: __. Decision rights: __. Owners, capacity and dates: __. Dependencies: __. Risks/opportunities and responses: __. Acceptance evidence and approver: __. Handover and benefit-review date: __.
For the behaviours behind these records, read five PMP-informed practices. For complex dependencies, use the fuller project-plan guide. The brief is a starting point; extend it when the project risks or organisational requirements demand more.
Sources and further reading
Reviewed 5 November 2026. Examples and worksheets are independent editorial illustrations, not claimed client results or official framework templates.
