# Project Brief: [Project name]

> A project brief is the short pre-initiation document that sets out
> what a proposed project is for, what it should deliver, roughly how and
> at what cost, and who will direct it. The project board (or investment
> committee) uses it to decide whether to spend money on initiation,
> where the detailed plan and full business case are written. The
> structure is aligned with the project brief management product of
> PRINCE2 7 (PeopleCert, 2023) and suits any stage-gated organisation.
> Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write it from the project mandate or idea, in days rather than weeks.
  It is an outline: ranges and assumptions are expected.
- The decision it supports is "start initiation or not", not "approve
  the whole project". Ask only for the time and money initiation needs.
- Keep the outline business case honest: a cost range, the main
  benefits with a baseline, and the main risks. The full case comes in
  initiation (project/project-initiation-document, business/business-case).
- Name the executive (sponsor) and the project manager. A brief without
  a named accountable executive is not ready.
- Common pitfall: a brief that already fixes the solution. Describe the
  outcome and the approach options, and let initiation choose.
-->

## Document control

<!-- Guidance: The brief is approved once, then superseded by the initiation documentation. -->

| Field | Value |
|---|---|
| Document ID | [PB-PROJ-001] |
| Project | [Project name] ([project code, if assigned]) |
| Source mandate | [Mandate, strategy item or request ID] |
| Version | [0.1] |
| Status | [Draft / Submitted / Approved / Superseded by initiation documentation] |
| Author | [@project-manager] |
| Executive (sponsor) | [@executive] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Executive (sponsor) | [@executive] | [Approve initiation / Reject / Revise] | YYYY-MM-DD |
| Senior user | [@senior-user] | [Agree / Disagree] | YYYY-MM-DD |
| Senior supplier | [@senior-supplier] | [Agree / Disagree] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@author] | First draft from mandate |
| 1.0 | YYYY-MM-DD | [@author] | Approved for initiation |

The worked example is the fictional **Brackwell Vale Housing Trust**, a
housing association managing 18,500 homes, proposing a Tenant Services
Portal to replace its ageing tenant website.

## 1. Background

<!-- Guidance: Why this project, why now. Link the strategy or mandate. Two short paragraphs. -->

[Background]

*Example:* Tenants can report repairs and check rent only by phone or at
an office. The contact centre handles about 210,000 calls a year, and
the legacy housing system's tenant module reaches end of vendor support
next year. The board's digital strategy asks for self-service for the
most common requests.

## 2. Project definition

<!-- Guidance: Objectives, scope, exclusions, constraints, assumptions, users and interfaces. Make objectives measurable at closure. -->

### 2.1 Objectives

| ID | Objective | Measure | Target |
|---|---|---|---|
| OBJ-1 | [Objective] | [Measure] | [Target and date] |
| OBJ-1 *(Example)* | Tenants report repairs and pay rent online | Portal live for all tenancies | By YYYY-MM-DD |
| OBJ-2 *(Example)* | Reduce contact centre demand | Share of calls moved to self-service | 25% within 12 months of go-live |

### 2.2 Scope and exclusions

| In scope | Out of scope |
|---|---|
| [Item] | [Item] |
| *Example:* Repairs reporting, rent statements and payment, tenancy details | *Example:* Replacing the core housing management system |
| *Example:* Migration of current tenancy data | *Example:* Leaseholder service charges (separate project) |

### 2.3 Constraints and assumptions

| Type | Statement |
|---|---|
| Constraint | [Fixed date, budget, policy or technology] |
| Assumption | [What must be true; to be checked in initiation] |
| *Example:* Constraint | Must be live before legacy vendor support ends |
| *Example:* Assumption | Legacy data can be exported through the vendor's standard interface |

### 2.4 Users and interested parties

[Tenants, contact centre, repairs contractors, finance, IT, regulator if relevant.]

## 3. Outline business case

<!-- Guidance: Why the project is worth initiating: reasons, options considered, cost range, main benefits with baseline, main risks. Use ranges. The full business case is written in initiation. -->

| Item | Value |
|---|---|
| Reasons | [Problem or opportunity] |
| Options considered | [Do nothing, do minimum, do something] |
| Estimated cost range | [Low to high] |
| Expected annual benefit | [Amount and basis] |
| Indicative payback | [Range] |
| Main risks | [Top three] |

*Example:* Estimated cost 1,000,000 to 1,300,000 EUR. Annual benefit
about 255,500 EUR net: 52,500 calls moved to self-service (25% of
210,000) at 4.20 EUR a call is 220,500 EUR, plus 95,000 EUR legacy
licence saving, minus 60,000 EUR portal running cost. Indicative payback
3.9 to 5.1 years. Main risks: legacy data quality, tenant digital
access, supplier capacity.

## 4. Project product description

<!-- Guidance: What the project will hand over, its quality expectations and acceptance criteria. This is the customer's view of "done". -->

| Item | Value |
|---|---|
| Final product | [What is handed over] |
| Composition | [Main parts] |
| Customer quality expectations | [Expectations] |
| Acceptance criteria | [Measurable criteria] |
| Acceptance method and responsibility | [Who accepts and how] |

*Example:* Acceptance criteria include: all current tenancies available
in the portal, WCAG 2.2 AA conformance for public pages, payment
service compliant with the card industry standard required by the
payment provider, and the contact centre trained.

## 5. Project approach

<!-- Guidance: How the work will be done: build or buy, in-house or supplier, predictive, agile or hybrid delivery, and why. Initiation will confirm it. -->

| Option | Description | Initial view |
|---|---|---|
| [Option] | [Description] | [Preferred / Possible / Rejected, reason] |
| *Example:* Buy and configure a housing portal product | Software as a service, supplier configures | Preferred: fastest, vendor supports |
| *Example:* Build in-house | Own development team | Rejected: no in-house team |

Proposed stages: [Initiation, then stages for delivery].

*Example:* Initiation (6 weeks), Design and procurement, Build and
migrate, Rollout. Delivery inside stages uses two-week iterations.

## 6. Project management team

<!-- Guidance: Name people where known. The executive is one person, accountable for the business case. -->

| Role | Name | Note |
|---|---|---|
| Executive (sponsor) | [@executive] | Accountable for the business case |
| Senior user | [@senior-user] | Represents those who use the outcome |
| Senior supplier | [@senior-supplier] | Represents those who build it |
| Project manager | [@project-manager] | Day-to-day management |
| Project assurance | [@assurance] | Independent check for the board |

## 7. Request for initiation

<!-- Guidance: What the board is asked to approve now: initiation budget, duration, team and tolerances. -->

| Item | Value |
|---|---|
| Initiation budget | [Amount] |
| Duration | [Weeks], YYYY-MM-DD to YYYY-MM-DD |
| Tolerances | [Time, cost] |
| Outputs of initiation | [Initiation documentation, full business case, first stage plan] |
| *Example:* Initiation budget | 60,000 EUR, tolerance +/-10% |

## 8. Related templates

<!-- Guidance: Link what comes before and after the brief. -->

- [Project charter](./project-charter.md) where your organisation authorises projects with a charter
- [Project initiation document](./project-initiation-document.md), the next step
- [Business case](../business/business-case.md) and [Feasibility study](../business/feasibility-study.md)
- [Stakeholder register](./stakeholder-register.md)

## Glossary

- **Project mandate:** the trigger for the project from corporate, programme or portfolio management.
- **Executive:** the board member accountable for the business case, often called the sponsor.
- **Initiation:** the first stage, which plans the project and builds the full business case.
- **Project product description:** the customer's description of the final product and how it will be accepted.

## Standard and licence note

Structure aligned with the project brief management product of PRINCE2 7
(*Managing Successful Projects with PRINCE2*, 7th edition, PeopleCert,
2023). PRINCE2 is cited by name only: no text, tables or figures from
the publication are reproduced, and the headings, wording and the
fictional Brackwell Vale example are original. Official text:
PeopleCert, purchase or licensed access:
https://www.peoplecert.org/prince2. PRINCE2 is a registered trademark of
PeopleCert. Check the current edition and your organisation's investment
rules before use. Template licence: MIT.