# Project Closure Report: [Project name]

> Formal report that closes a project: summary, objectives versus outcomes,
> scope, schedule and cost performance, quality results, benefits status
> and handover, transfer of open items, lessons, contract closure, resource
> release, archive and sign-off. Based on common project management
> practice. Replace every `[bracketed]` value and every row marked
> *Example*.

<!--
Guidance: How to use this template
- Write the report when deliverables are accepted and handover is complete, and
  before the team disperses. Draft it during hypercare, finalise at closure.
- Compare against the approved baselines, and show the original baseline as well,
  so approved changes and real variances are both visible.
- Nothing may close silently: every open risk, issue, defect and action is either
  closed or transferred to a named owner who has accepted it.
- Be honest about shortfalls. The report is used by future projects and auditors.
-->

## Document control

<!-- Guidance: Identify the report and its approvers. The sponsor's approval formally closes the project. -->

| Field | Value |
|---|---|
| Document ID | [PCR-PROJECT-001] |
| Project | [Project name] ([code]) |
| Sponsor | [@sponsor] |
| Project manager | [@project-manager] |
| Project start | YYYY-MM-DD |
| Project end | YYYY-MM-DD |
| Version | [0.1] |
| Status | [Draft / In review / Approved] |
| Classification | [Internal] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Project sponsor | [@name] | [Project closed / Closed with conditions] | YYYY-MM-DD |
| Steering committee chair | [@name] | [Decision] | YYYY-MM-DD |
| Receiving operations owner | [@name] | [Handover accepted] | YYYY-MM-DD |
| Finance controller | [@name] | [Accounts closed] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Usually one or two versions: draft for review and approved. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Draft during hypercare |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by sponsor; project formally closed |

## Contents

<!-- Guidance: Keep in sync with the headings below. -->

1. [Closure summary](#1-closure-summary)
2. [Objectives versus outcomes](#2-objectives-versus-outcomes)
3. [Scope delivered versus planned](#3-scope-delivered-versus-planned)
4. [Schedule performance](#4-schedule-performance)
5. [Cost performance](#5-cost-performance)
6. [Quality results](#6-quality-results)
7. [Benefits status and handover](#7-benefits-status-and-handover)
8. [Operational handover](#8-operational-handover)
9. [Transfer of open items](#9-transfer-of-open-items)
10. [Lessons learned summary](#10-lessons-learned-summary)
11. [Contract closure](#11-contract-closure)
12. [Resource release](#12-resource-release)
13. [Archive and records](#13-archive-and-records)
14. [Closure checklist](#14-closure-checklist)
15. [Sign-off](#15-sign-off)

## 1. Closure summary

<!-- Guidance: One paragraph a senior reader can rely on: was the project successful, what was delivered, at what time and cost, and what remains. -->

[Project name] ran from YYYY-MM-DD to YYYY-MM-DD to [purpose]. This section gives the overall verdict; the following sections provide the evidence.

*Example:* The project delivered the digital onboarding service, which went live on YYYY-MM-DD, 3 working days after the original baseline and within the approved schedule tolerance. Final cost was 468,200 EUR against a budget at completion of 478,500 EUR (2.2% under), after 30,000 EUR of contingency was allocated to approved change requests. All Must-have scope was delivered; one Should-have item was deferred to the service roadmap. Early benefit measurements show onboarding time down from 11 to 4 days, with the 3-day target expected by month 3.

| Dimension | Result | Rating |
|---|---|---|
| Scope | All Must-have delivered; 1 Should-have deferred | *Example:* Met |
| Schedule | Go-live +3 days vs original baseline | Met within tolerance |
| Cost | 2.2% under BAC | Met |
| Quality | 0 severity 1 or 2 defects at go-live | Met |
| Benefits | On track at first measurement | On track |

## 2. Objectives versus outcomes

<!-- Guidance: Take the objectives from the charter or project management plan unchanged and report the measured outcome. -->

Each approved objective is compared with the measured outcome.

| ID | Objective | Target | Outcome | Evidence | Status |
|---|---|---|---|---|---|
| OBJ-01 | *Example:* Reduce onboarding cycle time | 3 days median | 4 days at month 1 | Onboarding system report YYYY-MM | Partially met, on track |
| OBJ-02 | *Example:* Reduce abandonment | Below 8% | 9.5% at month 1 | Web analytics (first-party, aggregated) | Partially met, on track |
| OBJ-03 | *Example:* Go live before regulatory deadline | Before YYYY-MM-DD | Live YYYY-MM-DD | Release record | Met |
| [OBJ-nn] | [Objective] | [Target] | [Outcome] | [Evidence] | [Met / Partially met / Not met] |

## 3. Scope delivered versus planned

<!-- Guidance: List deliverables from the scope baseline with their acceptance. Show approved changes and anything not delivered, with the reason. -->

Deliverables are listed against the original and current scope baselines.

| Deliverable | Planned | Delivered | Accepted by | Date | Notes |
|---|---|---|---|---|---|
| D1 Process design | Yes | Yes | Head of operations | YYYY-MM-DD | |
| D2 Onboarding platform | Yes | Yes | Product owner | YYYY-MM-DD | |
| D3 Accessibility audit and remediation | Added by CR-007 | Yes | Product owner | YYYY-MM-DD | Approved change |
| D4 Joint application for two customers | Should-have | No | n/a | n/a | *Example:* Deferred to roadmap item RM-14, accepted by sponsor |
| [Deliverable] | [Planned] | [Delivered] | [@acceptor] | YYYY-MM-DD | [Notes] |

## 4. Schedule performance

<!-- Guidance: Compare milestone dates with the original and current baselines and explain significant variances. -->

Milestone performance against the original and the current (re-baselined) schedule:

| ID | Milestone | Original baseline | Current baseline | Actual | Variance vs original (days) |
|---|---|---|---|---|---|
| M1 | Plan baselined | YYYY-MM-DD | YYYY-MM-DD | YYYY-MM-DD | 0 |
| M2 | Design approved | YYYY-MM-DD | YYYY-MM-DD | YYYY-MM-DD | *Example:* +2 |
| M3 | UAT complete | YYYY-MM-DD | YYYY-MM-DD | YYYY-MM-DD | +6 |
| M4 | Go-live | YYYY-MM-DD | YYYY-MM-DD | YYYY-MM-DD | +3 |
| M5 | Handover | YYYY-MM-DD | YYYY-MM-DD | YYYY-MM-DD | +3 |

Schedule variance at completion is expressed in days and as a share of planned duration:

$$\Delta t = t_{\text{actual}} - t_{\text{baseline}}, \qquad \Delta t\,\% = \frac{\Delta t}{T_{\text{planned}}} \times 100\%$$

*Example:* go-live 3 working days late on a planned duration of 160 working days gives $\Delta t\,\% \approx 1.9\%$, within the 10-day tolerance. Main causes: late vendor staffing (LL-01) and the accessibility change (CR-007), partly absorbed by the project buffer.

## 5. Cost performance

<!-- Guidance: Final figures must be reconciled with finance. Separate approved changes from overruns. -->

Final cost by category, reconciled with [finance system] on YYYY-MM-DD (EUR):

| Category | Original budget | Approved changes | Final budget | Actual cost | Variance |
|---|---|---|---|---|---|
| Internal labour | *Example:* 210,000 | 0 | 210,000 | 216,400 | -6,400 |
| External services | 140,000 | +18,000 (CR-007) | 158,000 | 158,000 | 0 |
| Licences and infrastructure | 60,000 | 0 | 60,000 | 57,800 | +2,200 |
| Training and change | 25,000 | +12,000 (CR-009) | 37,000 | 36,000 | +1,000 |
| Contingency | 43,500 | -30,000 | 13,500 | 0 | n/a |
| **Total** | **478,500** | **0** | **478,500** | **468,200** | **+10,300 (under budget)** |

The final cost indicators are:

$$CV = EV - AC \qquad CPI = \frac{EV}{AC} \qquad VAC = BAC - AC$$

At completion $EV = BAC$, so $CPI = BAC / AC$. [State the values and explain the main drivers of any variance, separating approved changes from overruns.]

*Example:* with $BAC$ = 478,500 EUR and $AC$ = 468,200 EUR, $VAC$ = +10,300 EUR and $CPI \approx 1.02$. Of the 43,500 EUR contingency, 30,000 EUR funded two approved changes (CR-007 accessibility audit, CR-009 extended hypercare); 13,500 EUR was not needed and is returned to the portfolio. Internal labour overran by 6,400 EUR because business analysts supported UAT longer than planned; licences came in 2,200 EUR under budget after a negotiated discount. No costs remain open: the last vendor invoice was paid on YYYY-MM-DD and all project cost codes were closed on YYYY-MM-DD.

## 6. Quality results

<!-- Guidance: Report against the quality objectives and acceptance criteria. Include known defects released to production and who owns them. -->

Quality outcomes against the objectives in the quality management plan:

| Objective | Target | Result | Status |
|---|---|---|---|
| Open severity 1 or 2 defects at go-live | 0 | *Example:* 0 | Met |
| WCAG 2.2 AA findings open at go-live | 0 | 0 (re-audit YYYY-MM-DD) | Met |
| Migration field-level error rate | Below 0.1% | 0.04% | Met |
| Defect removal efficiency | At least 90% | 93.8% at 30 days | Met |
| Training assessment pass rate | At least 80% | 86% | Met |

Known defects released: [n] severity 3 and [n] severity 4, listed in [defect tracker query], transferred to the service owner (section 9).

## 7. Benefits status and handover

<!-- Guidance: Report early measurements against the benefits plan and confirm who now owns measurement. -->

Benefit status at closure, against the benefits realization plan [BRP-001]:

| Benefit | Baseline | Target | Latest actual | Date | Status | Owner after closure |
|---|---|---|---|---|---|---|
| B1 Onboarding time | 11 days | 3 days | *Example:* 4 days | YYYY-MM-DD | On track | Head of operations |
| B2 Cost per onboarding | 64 EUR | 28 EUR | 47 EUR | YYYY-MM-DD | On track | Finance director |
| B3 Abandonment | 18% | Below 8% | 9.5% | YYYY-MM-DD | On track | Head of digital |
| B4 Products per customer | 1.4 | 1.8 | Not yet measurable | n/a | Measured at +3 months | Head of retail |

Benefit owners have accepted continued measurement and reporting to [operations board] on YYYY-MM-DD. Benefit reviews are scheduled at go-live + 6 and + 12 months.

## 8. Operational handover

<!-- Guidance: Confirm the receiving organisation has accepted the solution and can run it. -->

The service was handed over to [IT operations and the onboarding operations team] on YYYY-MM-DD after a [4]-week hypercare period. Handover criteria and their status:

| Criterion | Status | Evidence |
|---|---|---|
| Runbooks and support documentation accepted | Met | [Link] |
| Service desk trained, scripts in place | Met | Training records |
| Monitoring and alerting live | Met | Dashboard [link] |
| Service level met for 10 consecutive working days | Met | SLA report YYYY-MM-DD |
| Support contract with vendor in force | Met | Contract C-2027-15 |

## 9. Transfer of open items

<!-- Guidance: Every open item is transferred to a named owner who has accepted it. Nothing is left "with the project". -->

Open items are transferred as follows.

| ID | Type | Description | Transferred to | Accepted on | Target date |
|---|---|---|---|---|---|
| RSK-030 | Risk | *Example:* Identity vendor price review at contract anniversary | Procurement category manager | YYYY-MM-DD | YYYY-MM-DD |
| DEF-0412 | Defect | *Example:* Date picker not localised for one language | Service owner backlog | YYYY-MM-DD | Next release |
| RM-14 | Deferred scope | *Example:* Joint applications | Product owner roadmap | YYYY-MM-DD | YYYY-Qn |
| ACT-02 | Lesson action | Requirements template checklist | Head of business analysis | YYYY-MM-DD | YYYY-MM-DD |
| [ID] | [Type] | [Description] | [@owner] | YYYY-MM-DD | YYYY-MM-DD |

## 10. Lessons learned summary

<!-- Guidance: Summarise the top lessons and link the full register. -->

The full register is in [LL-001]. The most important lessons are:

| ID | Type | Lesson | Applied to |
|---|---|---|---|
| LL-01 | Negative | *Example:* Supplier contracts need enforceable named-team clauses | Contract template v4.2 |
| LL-02 | Positive | *Example:* Co-design with affected managers turned resistance into support | PMO lifecycle guide |
| LL-03 | Negative | *Example:* Regulatory and accessibility needs must be checked at requirements stage | Requirements template |

Recommendations for future projects of this type: plan an explicit project buffer and report its use from the first status report; involve compliance and accessibility specialists in requirements elicitation rather than design review; and agree environment service levels with infrastructure before the test stage starts. These recommendations have been sent to the PMO for inclusion in the project lifecycle guide.

## 11. Contract closure

<!-- Guidance: Confirm each contract is complete, paid, free of open claims and evaluated. -->

All project contracts have been reviewed for closure.

| Contract | Supplier | Deliverables accepted | Final payment | Open claims | Supplier evaluation | Status |
|---|---|---|---|---|---|---|
| C-2027-14 | *Example:* Front-end vendor | Yes | Paid YYYY-MM-DD | None | 3.8 of 5, recorded | Closed |
| C-2027-15 | *Example:* Front-end vendor (support) | n/a | Ongoing | None | n/a | Transferred to IT operations |
| C-2027-21 | *Example:* Accessibility auditor | Yes | Paid YYYY-MM-DD | None | 4.5 of 5 | Closed |
| [Contract] | [Supplier] | [Yes / No] | [Status] | [Claims] | [Score] | [Status] |

## 12. Resource release

<!-- Guidance: Confirm people, equipment and accounts are released and access removed. -->

Project resources have been released.

| Resource | Released on | Released to | Access removed | Performance input given |
|---|---|---|---|---|
| *Example:* Business analyst | YYYY-MM-DD | Operations | Project folders read-only | Yes |
| *Example:* Vendor developers (3) | YYYY-MM-DD | Vendor | All accounts disabled | n/a |
| *Example:* Test environments | YYYY-MM-DD | Infrastructure | Data deleted per retention policy | n/a |
| [Resource] | YYYY-MM-DD | [Destination] | [Yes / No] | [Yes / No / n/a] |

## 13. Archive and records

<!-- Guidance: State where project records are kept, for how long, and who to ask. -->

Project records are archived in [repository and path], read-only from YYYY-MM-DD, and retained for [7] years under [records policy]. The archive contains the charter, plans and baselines, decisions and change log, RAID log, test and acceptance evidence, contracts, financial reconciliation, lessons register and this report. Archive contact: [@pmo-records].

## 14. Closure checklist

<!-- Guidance: Tick each item with evidence before requesting sign-off. -->

The following closure activities are complete:

- [ ] All deliverables accepted by their named acceptors
- [ ] Operational handover accepted by the receiving owner
- [ ] Open risks, issues, defects and actions transferred and accepted
- [ ] Benefits ownership accepted by benefit owners
- [ ] Contracts closed or transferred; final invoices paid
- [ ] Financial accounts reconciled and cost codes closed
- [ ] Resources released and access removed
- [ ] Lessons learned register published
- [ ] Records archived
- [ ] Closure communicated to stakeholders

## 15. Sign-off

<!-- Guidance: The sponsor's signature closes the project. Record any conditions. -->

By signing, the parties confirm that the project is closed on the terms stated in this report. Conditions, if any: [none / list].

| Role | Name | Signature or approval reference | Date |
|---|---|---|---|
| Project sponsor | [@name] | [Reference] | YYYY-MM-DD |
| Project manager | [@name] | [Reference] | YYYY-MM-DD |
| Operations owner | [@name] | [Reference] | YYYY-MM-DD |
| Finance controller | [@name] | [Reference] | YYYY-MM-DD |

## Standard and licence note

Based on common project management practice for project closure,
handover and final performance reporting. This template is original text
written for this collection. Template licence: MIT.