Skip to content

Final Project Report

At a glance

  • Purpose: Compare what the project promised with what it delivered, explain the difference, and hand over what remains — in the form a sponsor or a successor can use.
  • Use it when: At the end of the capstone, and at the end of any project of a few weeks or more. It is the input to the project closure report, which adds the organisational and contractual closure detail.
  • Owner: The project manager; the sponsor or business owner accepts it.
  • Related: Module 12 Lesson 2 · Capstone deliverable 14 · Capstone rubric

How to use this template

  1. Compare with the original plan. The revised baseline has already absorbed earlier variance, so using it as the reference understates the difference. Both baselines appear in section 2, with the reason for any re-baseline.
  2. Populate both columns of section 3. A not-delivered list that is empty is almost always wrong, and a deliverable quietly dropped is the commonest way closure fails an audit.
  3. Give every variance a cause, and aim for causes at system level: requirements undefined at the start, data unavailable until late. "Lack of effort" is a symptom, and it teaches nothing to the next project.
  4. Separate facts from judgements, and label which is which. "Upload took 11 days against an estimate of 8" is a fact; "the estimate was optimistic for file handling" is a judgement, and both belong here.
  5. Write it from your artefacts, not from memory, so that it agrees with the plan, the reports, and the logs you are submitting alongside it.

Field descriptions

Section What goes in it Watch out for
Outcome statement What exists now, in plain language A description of the work rather than of the result
Outcome against plan Original plan, any re-baseline, actual result Comparing only with the revised baseline
Delivered / not delivered Both lists, with reasons An empty not-delivered column
Variance analysis Measure, planned, actual, cause, when noticed Causes that name people or effort
Quality outcome Acceptance results, defect summary, exit criteria met Declaring quality without naming the criteria
Measures The dashboard's measures, planned against actual Cherry-picked measures chosen after the fact
Residual limitations What is still true, with the person accepting it Limitation recorded but not accepted by anyone
Handover Component, receiving owner, evidence, date "Handed to operations" with no named person
Benefits Measure, baseline, owner, review date after closure Benefit claimed at closure, with no future review

Blank template

# Final Project Report — [Project name]

| | |
| --- | --- |
| **Report date** | [YYYY-MM-DD] |
| **Project manager** | [Name or role] |
| **Sponsor** | [Name or role] |
| **Outcome** | [Completed / Completed with limitations / Partly delivered / Stopped] |
| **Project window** | [Planned start and finish] → [Actual start and finish] |

## 1. Outcome statement

[Three or four sentences a busy reader can act on: what exists now, who uses it, and the honest headline —
including whether the original date and scope were met. Write this last; put it first.]

## 2. Outcome against the original plan

| Dimension | Original plan (charter, v[ ]) | Revised baseline (v[ ], [date]) | Actual | Variance |
| --- | --- | --- | --- | --- |
| Scope | [What was promised] | [What it became, if changed] | [What was delivered] | [Difference] |
| Finish date | [Date] | [Date and reason for change] | [Date] | [Days] |
| Cost or effort | [Amount, with basis] | [Revised] | [Actual] | [Difference] |
| Quality bar | [Stated criteria] | [Revised] | [Result] | [Difference] |

Re-baseline record: [If the plan was re-baselined, state when, why, and who approved it. If not, say
"no re-baseline".]

## 3. Delivered and not delivered

| Delivered | Evidence of acceptance |
| --- | --- |
| [Item] | [Who accepted it, when, and what was observed] |

| Not delivered | Reason | Status |
| --- | --- | --- |
| [Item] | [Why it did not happen] | [Deferred to X / dropped / part of a future project] |

## 4. Variance analysis

| # | What varied | Planned | Actual | Cause | When it was noticed | What was done |
| --- | --- | --- | --- | --- | --- | --- |
| 1 | [Effort on X] | [n] | [n] | [System-level cause] | [Milestone or week] | [Decision taken] |

**Facts:** [State the measured differences without interpretation.]
**Judgements:** [State your interpretation separately, and label it as your judgement.]

## 5. Quality outcome

| Exit criterion | Result | Evidence |
| --- | --- | --- |
| [Criterion from the quality plan] | [Met / not met] | [Test record, defect log extract, acceptance note] |

Defect summary: [Opened, closed, open by severity, and where they were found — from the defect log.]

## 6. Measures: planned against actual

| Measure | Planned or threshold | Actual | Reading |
| --- | --- | --- | --- |
| [Milestone slip in days] | [≤ 2] | [n] | [Green / Amber / Red] |

## 7. Residual limitations and risks

| ID | Limitation or risk | Accepted by | Owner after closure |
| --- | --- | --- | --- |
| [L-01] | [What is still true] | [Named person or role] | [Who owns it now] |

## 8. Handover

| Component or artefact | Receiving owner | Date | Evidence of handover |
| --- | --- | --- | --- |
| [Repository, documentation, environment access, support arrangement] | [Named person or role] | [Date] | [What confirmed it] |

## 9. Benefits and their measurement

| Benefit | Measure | Baseline | Review date | Owner |
| --- | --- | --- | --- | --- |
| [Intended benefit] | [How it will be measured] | [Value, or "not yet established"] | [Date after closure] | [Named owner] |

## 10. Lessons

[Link to the [lessons learned register](lessons-learned-register.md). Do not duplicate the entries: state
which lessons changed something, and where each was routed.]

## 11. Sign-off

| Role | Name | Date | Statement |
| --- | --- | --- | --- |
| Sponsor | | | Outcome accepted |
| Business owner | | | Benefits ownership transferred |
| Project manager | | | Report is an accurate account of the project |

Worked example

From the capstone, on the admission-portal option — invented figures for teaching. The extract below is the shape a well-evidenced submission takes.

Dimension Original plan (charter v1.0) Revised baseline (v1.1, week 3) Actual Variance
Scope One end-to-end capability: apply, upload one document, receive acknowledgement File replacement removed from scope As revised One capability deferred
Finish date 8 weeks 8 weeks (no date change) 8 weeks None against revision; on time against the original date but with reduced scope
Effort 36 person-days 39 person-days 41 person-days +2 against the revision
Quality bar Unaided completion in under 10 minutes Unchanged One of two testers at 14 minutes Criterion narrowly missed
# What varied Planned Actual Cause Noticed What was done
1 Document upload effort 8 pd 11 pd Validation rules were undecided when the activity began — a definition-of-ready failure, not an estimating failure; the estimate was also optimistic for file-handling work Week 3 status report Validation rules decided; file replacement dropped to protect the date

Two features of this extract are worth copying. The date comparison states plainly that the original date was met only because scope was reduced — a report that claimed "delivered on time" without that clause would be misleading, and the rubric's consistency dimension compares it against the scope statement, so the omission would also be detectable. And the cause is a named system failure with a routing consequence (the definition-of-ready checklist), which is what makes it a lesson rather than an excuse.

Common mistakes

  • Comparing only with the revised baseline. It makes the project look better and teaches the organisation nothing about its own planning.
  • An empty not-delivered list. Deliverables do get deferred; recording them is the difference between closure and a surprise later.
  • Causes that name people. "The developer was slow" is unverifiable, unhelpful, and usually wrong. Name the system condition that made the work take longer.
  • Assuming acceptance. If no one confirmed the criteria, the project has not been accepted — say so, and record what was observed.
  • Residual limitations with no acceptor. A limitation nobody accepted will be discovered by whoever hits it first.
  • Benefits claimed at closure. Many benefits arrive months later; state who measures them and when.
  • Duplicating the lessons register. Link it. A report that repeats it will eventually disagree with it.
  • Writing from memory. The report must reconcile with the artefacts; if it does not, one of them is wrong, and finding that out at closure is too late.