Skip to content

Lesson 2 — Project Documentation, Closure, and Lessons Learned

At a glance

Learning objectives

By the end of this lesson you should be able to:

  1. Define a proportionate documentation set, driven by named readers.
  2. Run a closure process covering acceptance, transition, resources, and finance.
  3. Hand over in a way that can be tested rather than assumed.
  4. Run a retrospective that produces changes, and record lessons where the next project will find them.

Prerequisites

Introduction

Two activities are cut first when a project runs late: documentation and closure. Both are cut because their benefit appears after the project ends — which is exactly why they need to be scheduled and owned rather than left to goodwill.

This lesson covers the documentation worth producing, the closure process that ends a project properly, and the lessons-learned practice that turns experience into an asset.

1. Documentation

Documentation is a deliverable. Like any deliverable it needs a purpose, an owner, and acceptance criteria — and, like any deliverable, it should not exceed what is needed.

Three kinds, serving three audiences:

Kind Audience Examples
Product documentation Users, integrators User guide, API reference, release notes, troubleshooting
Project documentation Team, sponsor, auditor Charter, plan, registers, reports, change log
Process documentation The organisation Standards, conventions, procedures

Three rules keep it proportionate.

Start from the reader. If you cannot name the reader and the task or decision the document supports, do not write it. This single test removes most unnecessary documents.

Prefer living documents. A document that lives in the repository, updated as part of the work, stays true. A document written once at the start and stored elsewhere is wrong within weeks. Where documentation can be generated — API schemas, data dictionaries, dependency graphs — generation beats maintenance.

Leave behind what the next person needs. The test is handover: could someone who has never spoken to you run, change, and diagnose this system? Whatever is missing for that is what you owe.

A minimum viable documentation set

README that runs the system; requirements with acceptance criteria; architecture with the key decisions and their reasons; data dictionary or schema; change log; deployment instructions. Six items, each genuinely useful — worth far more than a large set of unmaintained pages.

2. Closure

Closure is a defined process, and every element of it is routinely skipped.

Activity What it produces
Acceptance Confirmation that deliverables meet their criteria
Transition and handover Documentation, training, and support arrangements
Resource release People formally returned, with their contribution recognised
Financial closure Final costs, licence and asset records, unused budget returned
Lessons learned What to repeat and what to change, recorded where it will be found
Archiving Artefacts and decisions retained and findable

Two failures are common enough to name.

Handover as an event rather than a capability. Sending a document is not handover. The only honest test is behavioural: can the receiving team operate, change, and diagnose the system without the people who built it? If the answer is only "yes, with the original developers on call", the project has not transferred anything.

Closure without acceptance criteria. If deliverables were never given testable criteria, closure becomes a negotiation about whether the project is finished — usually resolved by declaring it finished. That is why the criteria written in Module 05 and Module 12 Lesson 1 matter at the end.

3. Retrospectives and lessons learned

A retrospective examines how work went, in order to change how work is done. It is not a status meeting and not a blame session.

A simple structure that works: what went well, what did not, what we will change, and who owns each change. The output that matters is the last two. A retrospective that produces only warmth has produced nothing.

Common failure modes:

Failure Symptom Correction
No actions Sentiment recorded, behaviour unchanged Require owners and dates for each change
Blame People describe causes defensively Focus on systems and process, not individuals
Seniority dominance The most senior person's view becomes the conclusion Gather input independently first
Recency bias Only the last few weeks are discussed Review the whole period against the plan
Premature closure "We didn't have time" Schedule it as a deliverable of the project

Lessons learned is the organisational version. A lesson is only learned when something changes and the next project encounters the change — a template, a checklist, a standard, an estimating adjustment. Notes written and filed are documentation; a lesson that alters future behaviour is knowledge.

Record lessons where the next project actually looks: in the template it will copy, the checklist it will follow, or the guide it will read. A lessons-learned document in a project folder nobody opens has the form of the practice and none of the effect.

Key terms

Term Meaning
Product documentation Material for users and integrators
Project documentation Material for the team, sponsor, and auditors
Transition Moving the product into operational use
Acceptance Formal confirmation that deliverables meet criteria
Retrospective A structured review of how the work went, producing changes
Lessons learned Recorded knowledge that changes future practice
Archiving Retaining artefacts and decisions in a findable location

Worked example

Task: close the illustrative public service information system and capture its lessons. Details are invented for teaching.

Step 1 — Confirm acceptance against criteria written earlier. Each release is checked against its agreed criteria. One criterion — "an application is processed end to end by a member of the public without assistance" — was demonstrated by an actual tester unfamiliar with the system, not by the team. A demonstrated criterion is worth more than a reported one.

Step 2 — Prepare the handover as a capability, not a document. The receiving operations team receives a runbook, a data dictionary, admin training, and two weeks of joint support. Then it is tested.

Step 3 — Test the handover and accept the result. A member of operations who has never worked on the project completes a change request unaided. They succeed on the second attempt — blocked first by a configuration step missing from the runbook. The runbook is corrected. That failure, found during closure, is the cheapest possible version of it.

Step 4 — Release resources deliberately. Team members are formally released to their departments, and their contribution is recorded and acknowledged. Quietly drifting away is how organisations lose the goodwill that makes the next project possible.

Step 5 — Close financially and archive. Final costs are reconciled against the budget, licences and hosting are recorded against the owning department, and unused contingency is returned — separately from management reserve, which the sponsor accounts for. Requirements, decisions, and the change log are archived in the repository beside the code.

Step 6 — Run the retrospective properly. Input is gathered in writing before the discussion, so that the most senior voice does not set the frame in advance. Three changes emerge, each with an owner:

Finding Change Owner
Privacy and retention questions surfaced late Add a data-protection question set to the requirements template Business analyst
A load-test failure was found after the launch date was announced Add a load test as a gate before any launch date is communicated Tech lead
Two incidents were caused by decisions nobody had recorded Record decisions within 24 hours in a decision log Project manager

Step 7 — Put the lessons where the next project will find them. The data-protection questions go into the requirements template, not into a lessons-learned document. The load test goes into the release checklist. The decision log goes into the project charter template. A lesson in a template will be encountered by the next project whether or not anyone reads a lessons document.

Step 8 — Define benefits measurement now, before everyone disperses. The intended benefit is reduced application processing time. Baseline it before launch, name an owner in the service department, and schedule the measurement three months after adoption. If nobody owns adoption, the benefit is a prediction rather than an outcome.

Common misconceptions

“Documentation slows delivery”

It delays the next delivery and turns every future change into archaeology. The answer is proportion and generation, not omission.

“The project ends at launch”

Launch begins the benefit. Handover, acceptance, and measurement are what convert a delivery into an outcome.

“Lessons learned is a document”

A document is where the practice often stops. A lesson is learned when a template, checklist, or standard changes and the next project meets the change.

Practical activity

Close it properly. For one example project:

  1. Define a documentation set with at most seven items; for each, name the reader and the task it supports.
  2. State one document you are deliberately not producing, and why.
  3. Write a closure checklist covering acceptance, transition, resource release, financial closure, and archiving.
  4. Design a handover test a stranger could pass or fail.
  5. Hold a retrospective and record at least two changes with owners — then place each change in a template or checklist the next project will use.

What "good" looks like: every document with a named reader, at least one explicit exclusion, a handover test that can fail, and lessons recorded in artefacts that future work actually touches.

Self-assessment

  1. What single test decides whether a document is worth writing?
  2. Why is "we sent them the documentation" not evidence of handover?
  3. What distinguishes a lesson learned from a lesson recorded?

  4. Why must benefits measurement be defined before the project closes?

  5. Apply it — inventory system closure. The software is live and the team calls the project done. Closure is proposed as a pack containing the plan, the status reports, and a 60-page design document. Nobody has confirmed with the warehouse staff that they can operate the system unaided, and the old spreadsheet is still being kept up to date “just in case”.

    Hint: A strong answer names what acceptance actually requires and which closure steps are still missing.

Show answers
  1. Whether you can name the reader and the decision or task the document supports. If neither can be named, the document has no purpose and will not be maintained.
  2. Because handover is a capability, not an artefact. The test is whether the receiving team can operate, change, and diagnose the system unaided — which a document does not demonstrate.
  3. A recorded lesson sits in a file. A learned lesson has changed something — a template, checklist, standard, or estimate — and the next project encounters the change.
  4. Because after closure the team disperses, attention moves to the next project, and no one remains whose job is to measure. Unless the owner and the measurement date are agreed while the project still has standing, the benefit will not be checked.
  5. Acceptance has not happened: it needs the deliverable, the criteria, a named acceptor, and recorded evidence — and the evidence here should include a warehouse user completing a stock count unaided, not a signature on a document. Record the residual limitations at the same time, with the person accepting them. Then close the rest: transition (training, a named support owner, and a decision on the spreadsheet — either decommission it with a date, or run it in parallel with a defined end, because leaving it running indefinitely means the benefit never arrives), resources released, financial closure, and archiving. On the documentation, apply the reader test: keep what named readers use — an operator runbook, interface notes, the decision log — and archive the design document rather than shipping it as evidence. Finally, hold the retrospective and file the lessons somewhere the next project will actually look.

Summary

  • Documentation is proportionate and reader-driven; prefer living and generated documents.
  • Closure covers acceptance, transition, resource release, financial closure, archiving, and lessons learned.
  • Handover is proven behaviourally, not by couriering documents.
  • Retrospectives must produce owned changes; lessons must be placed where the next project will meet them.
  • Benefits are measured only if someone owns the measurement and the date before closure.

Further learning

  • Lesson 3 — Distributed and Remote Teams
  • Project Retrospectives: A Handbook for Team Reviews, Norman L. Kerth — the standard reference on structured retrospectives.
  • A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute — closing the project or phase.

Next

Continue to Lesson 3 — Distributed and Remote Teams.