# Work Package: [WP-NN] [Work package name]

> A work package is the agreement between the project manager and a team
> manager (in-house or supplier) that authorises a defined piece of
> work: the products to deliver, their quality criteria, the effort and
> cost, the tolerances the team may work within, and how progress and
> problems will be reported. It lets the project manager delegate
> without micromanaging. The structure is aligned with the work package
> management product of PRINCE2 7 (PeopleCert, 2023) and fits any
> project that hands work to separate teams. Replace every `[bracketed]`
> value and every row marked *Example*.

<!--
Guidance: How to use this template
- Agree it with the team manager; do not just send it. The team manager
  must accept that the products can be built within the stated limits.
- Describe products and their quality criteria, not tasks. The team
  decides how to build them.
- Set tolerances smaller than the stage tolerances, so a work package
  problem reaches the project manager while the stage can still absorb
  it.
- If the work is done by an external supplier, the contract prevails.
  Reference the contract and keep commercial terms out of this document.
- Common pitfall: no clear handover and approval method, so products are
  "finished" but never accepted.
-->

## Document control

<!-- Guidance: One work package per authorised piece of work. Record acceptance by the team manager. -->

| Field | Value |
|---|---|
| Document ID | [WP-PROJ-NN] |
| Project | [Project name] ([project code]) |
| Stage | [Stage number and name] |
| Authorised by | [@project-manager] |
| Team manager | [@team-manager] ([organisation]) |
| Contract or agreement | [Contract ID, call-off, internal agreement] |
| Version | [1.0] |
| Status | [Draft / Authorised / In progress / Completed / Withdrawn] |
| Date authorised | YYYY-MM-DD |
| Classification | [Internal] |

### Approvals

| Role | Name | Action | Date |
|---|---|---|---|
| Project manager | [@project-manager] | Authorise | YYYY-MM-DD |
| Team manager | [@team-manager] | Accept | YYYY-MM-DD |
| Project assurance | [@assurance] | Review (optional) | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | YYYY-MM-DD | [@author] | Authorised |
| 1.1 *(Example)* | 2027-04-23 | [@project-manager] | Scope reduced after exception option B |

The worked example is work package **WP-07, Legacy data migration**, in
stage 3 of the fictional **Brackwell Vale Housing Trust** Tenant
Services Portal project, delivered by a fictional supplier, **Halvern
Data Partners**.

## 1. Description and scope

<!-- Guidance: What the work package delivers and the boundary with other work packages. -->

| Item | Value |
|---|---|
| Purpose | [Why this work is needed] |
| In scope | [Work included] |
| Out of scope | [Work excluded, and where it is done] |
| Interfaces | [Other work packages, systems, teams] |

*Example:* Profile, cleanse and migrate tenancy and repairs data from
the legacy housing system to the new portal. Excludes portal
configuration (WP-06) and rollout support (stage 4). Interfaces with the
legacy vendor's export service and the portal supplier's import tool.

## 2. Products

<!-- Guidance: List each product with its quality criteria and who approves it. Use product IDs from the stage plan. -->

| Product ID | Product | Quality criteria | Quality method | Approver |
|---|---|---|---|---|
| [PRD-NN] | [Product] | [Measurable criteria] | [Review, test, reconciliation] | [@approver] |
| PRD-35 *(Example)* | Data profiling report | Covers 100% of in-scope tables, error rates by field | Review by data owner | [@data-owner] |
| PRD-36 *(Example)* | Cleansed tenancy records | 100% of current tenancies reconcile to the legacy system, 0 duplicate tenants | Automated reconciliation | [@data-owner] |
| PRD-37 *(Example)* | Migration runbook | Dress rehearsal completed within the cutover window | Rehearsal | [@project-manager] |

## 3. Techniques, processes and standards

<!-- Guidance: Methods, tools and standards the team must follow, such as the organisation's data protection, security or coding rules. -->

- [Standard or method]
- *Example:* Process personal data only in the approved test environment
  under the project's data protection impact assessment.
- *Example:* Use the project's configuration management for scripts and
  mapping rules.

## 4. Effort, cost and dates

<!-- Guidance: The agreed estimate. Link the team plan if one exists. -->

| Item | Value |
|---|---|
| Start | YYYY-MM-DD |
| End | YYYY-MM-DD |
| Effort | [Person-days] |
| Cost | [Amount] |
| *Example:* Dates | 2027-03-08 to 2027-04-16 (6 weeks) |
| *Example:* Cost | 96,000 EUR |

## 5. Tolerances

<!-- Guidance: The limits within which the team manager can act without referring back. Set them inside the stage tolerances. -->

| Area | Target | Tolerance | In money or time |
|---|---|---|---|
| Time | [End date] | [+/- days or weeks] | [Range] |
| Cost | [Amount] | [+/- %] | [Range] |
| Scope | [Products] | [What may flex] | [n/a] |
| Quality | [Criteria] | [Allowed range] | [n/a] |
| Risk | [Limit] | [Score limit] | [n/a] |
| *Example:* Time | 2027-04-16 | +/- 1 week | 2027-04-09 to 2027-04-23 |
| *Example:* Cost | 96,000 EUR | +/- 5% | 91,200 to 100,800 EUR |
| *Example:* Risk | No risk above score 12 unreported | Score 12 | n/a |

## 6. Reporting and escalation

<!-- Guidance: How often the team reports (checkpoint reports), what they contain, and how the team manager raises an issue when a tolerance is forecast to be exceeded. -->

| Item | Value |
|---|---|
| Checkpoint frequency | [Weekly / fortnightly] |
| Checkpoint content | [Products done, next period, issues, risks, forecast vs tolerance] |
| Escalation route | [Raise an issue to the project manager immediately when a tolerance is forecast to be exceeded] |
| *Example:* Checkpoint | Weekly on Thursday, with a cleansing burn-down chart |

```mermaid
flowchart LR
    A["Project manager authorises work package"] --> B["Team manager accepts"]
    B --> C["Team builds products"]
    C --> D["Checkpoint report"]
    D --> E{"Forecast within tolerance?"}
    E -- Yes --> C
    E -- No --> F["Team manager raises issue to project manager"]
    C --> G["Products approved and handed over"]
    G --> H["Project manager confirms completion"]
```

## 7. Handover and approval

<!-- Guidance: How completed products are handed over, approved and recorded. Include configuration records and documentation. -->

| Item | Value |
|---|---|
| Handover method | [Release, delivery note, repository] |
| Approval record | [Quality register entry, sign-off] |
| Completion | [All products approved; team manager notifies project manager] |

## 8. Constraints, assumptions and joint agreements

<!-- Guidance: Anything the team must work around, and agreements with other parties, such as access to systems or people. -->

- [Constraint or assumption]
- *Example:* The legacy vendor provides two full exports, on 2027-03-08
  and 2027-04-12.

## 9. Related templates

<!-- Guidance: Link the plans and reports this work package connects to. -->

- [Highlight report](./highlight-report.md), which summarises checkpoint reports
- [Exception report](./exception-report.md), if the stage tolerance is forecast to break
- [Work breakdown structure](./work-breakdown-structure.md)
- [Statement of work](../business/statement-of-work.md) for the contract side
- [Data migration reconciliation](./data-migration-reconciliation.md)

## Glossary

- **Team manager:** the person who leads the team that builds the products of a work package.
- **Checkpoint report:** the team manager's regular progress report to the project manager.
- **Tolerance:** the permitted deviation before the team manager must refer back.
- **Quality register:** the record of planned and completed quality checks.

## Standard and licence note

Structure aligned with the work package management product and the
managing product delivery process 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
and Halvern example are original. Official text: PeopleCert, purchase or
licensed access: https://www.peoplecert.org/prince2. PRINCE2 is a
registered trademark of PeopleCert. Where work is contracted, the
contract governs. Template licence: MIT.