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.

Document control

Approvals

Revision history

Contents

1. Closure summary
2. Objectives versus outcomes
3. Scope delivered versus planned
4. Schedule performance
5. Cost performance
6. Quality results
7. Benefits status and handover
8. Operational handover
9. Transfer of open items
10. Lessons learned summary
11. Contract closure
12. Resource release
13. Archive and records
14. Closure checklist
15. Sign-off

1. Closure summary

[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.

2. Objectives versus outcomes

Each approved objective is compared with the measured outcome.

3. Scope delivered versus planned

Deliverables are listed against the original and current scope baselines.

4. Schedule performance

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

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

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

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

Quality outcomes against the objectives in the quality management plan:

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

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

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

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:

9. Transfer of open items

Open items are transferred as follows.

10. Lessons learned summary

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

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

All project contracts have been reviewed for closure.

12. Resource release

Project resources have been released.

13. Archive and records

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

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

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

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.