5.3Closure, review & lessons learned
The essentials in 30 seconds
- Closing ≠ delivering: formal acceptance, delivery, administrative and contractual closure, archiving, resource release.
- Blameless review: a structured review of what went well and badly — facts and processes, never people.
- Capitalize: 3 to 5 lessons formalized and filed where future projects will find them.
Threaded mini-case — Bilal closes and runs his first review
Bilal's deliverable is ready, but the client has validated nothing in writing and two administrative items drag on. Instead of “turning the page”, Bilal organizes formal acceptance, completes delivery and archiving, releases his members cleanly, then runs a one-hour review: what worked, what to improve, what to try. This section tells how he turns a fuzzy ending into capitalization useful to following projects.
Sequel to cases 5.1-5.2 — Bilal moves from execution to clean closure.
1. Closing properly
A project does not stop when the deliverable is ready: it is closed properly. This includes acceptance (formal client validation of the deliverable), delivery, administrative and contractual closure, and releasing resources. Bilal has acceptance signed against the agreed criteria: with nothing in writing, everything stays disputable.
A botched closure leaves loose ends haunting the team months later. Bilal also completes archiving: a filed dossier is a dispute avoided.
2. Lessons learned: capitalizing
The most precious step — and most often neglected — is the lessons-learned review: reviewing what went well and badly, to capitalize. Bilal runs it fast, while fresh, with his team still available.
What you learn from a project only counts if passed on to the next ones. The review turns experience into the organization's continuous improvement: 3 to 5 actionable lessons, filed where future projects will find them.
🔎 Concrete example — 🔎 Concrete example — A blameless review
Learn, don't blame.
You analyze facts and processes, NOT people.
Structure: what went well / to improve / to try.
→ a climate of trust is the condition of a useful review.Outcome: the same mistakes are no longer repeated.
Reflex: run the review fast, while it is fresh.
Section vocabulary
- Closure
- Final phase: acceptance, delivery, administrative and contractual closure, resource release, archiving.
Simple example: Bilal has acceptance signed, archives the dossier and releases his 5 members.
What it is not: sending the deliverable by message with no validation or filing.
Reflex: is any item left unvalidated, unfiled, unsettled?
- Acceptance
- Formal client validation that the deliverable meets agreed expectations.
Simple example: Bilal's client signs that the deliverable meets the specification criteria.
What it is not: a vague oral agreement (“looks fine”) with nothing in writing.
Reflex: is my acceptance written and tied to agreed criteria?
- Lessons learned
- A structured review of what went well and badly, to draw reusable lessons.
Simple example: Bilal runs one hour: went well, to improve, to try.
What it is not: a score-settling session hunting culprits.
Reflex: does each finding lead to an actionable lesson?
- Capitalization
- Keeping and passing on lessons (best practices, pitfalls) to improve future projects.
Simple example: Bilal files 4 lessons in the shared project folder.
What it is not: keeping lessons in heads, never written or filed.
Reflex: where will a future project find my lessons?
- Project review
- Final summary: objectives met?, cost and schedule variances, satisfaction, key lessons.
Simple example: Bilal compares planned vs actual on schedule, costs and client satisfaction.
What it is not: telling the project from memory with no figures or criteria.
Reflex: does my review answer “objectives met? variances? lessons?”
In practice — In practice — Closing and capitalizing
- Organize acceptance: have the client formally validate the deliverable against agreed criteria.
- Complete closure: delivery, contractual and administrative aspects, archiving, resource release.
- Run a team review: what went well (to reproduce), what went less well (to improve), surprises.
- Formalize 3–5 key lessons and file them where future projects will find them (capitalization).
Ready-to-say script — opening the blameless review (1 min)
“We are here to learn, not to blame: we talk facts and processes, never people. Each person gives one point that went well, one to improve, one surprise. We leave with 3 to 5 written lessons, filed for the next teams. What is said here serves projects, not reproaches.”
Say when opening the review, right after closure; note lessons live.
Copy-paste template — closure + review sheet
ACCEPTANCE (date, signatory, criteria): _______________
DELIVERY + ARCHIVING (where, what): _______________
RESOURCES RELEASED (who, when, message): _______________
REVIEW — WENT WELL (to reproduce): _______________
REVIEW — TO IMPROVE: _______________
LESSONS FILED WHERE: _______________Small team
No heavy ceremony: Bilal uses a simple written acceptance + a one-hour review around a 3-column board.
Remote / hybrid
Closure and review by video: acceptance signed digitally, dossier archived shared, lessons posted in the same place.
Algeria SME
Bilal completes the local contractual and administrative side (invoices, acceptances) before releasing members back to departments.
Already scattered team
Run the review fast: even in a short remote format, while memories are fresh — otherwise the experience is lost.
✓ Best practices
- Have the deliverable formally validated (acceptance) before closing.
- Run a review right after closure, while it is fresh.
- Formalize and file lessons where future projects will find them.
✗ Common pitfalls
- Botching closure (issues resurfacing later).
- Skipping the review (same mistakes repeated forever).
- Turning the review into settling scores.
Key takeaways
- Closing = acceptance, delivery, administrative closure, resource release.
- A botched closure leaves issues resurfacing later.
- Lessons learned draw the project's teachings.
- Capitalize: experience only counts if it benefits following projects.
48h challenge — apply tomorrow
Take a recent or nearly finished project: list what closure still misses (acceptance? archiving? resources?). Run a 30-min mini-review (went well / to improve / to try) and write 3 lessons filed in the right place.
- I can name the 5 building blocks of clean closure without hesitating.
- I can explain the blameless review in one sentence.
- I have formalized 3 lessons from a real project.
Frequently asked questions
Is a review worth it when the project is done and the team already elsewhere?
Yes, provided you run it fast (right after closure, while fresh) and make it useful. One hour of honest review avoids repeating the same mistakes on the next project — a huge return on investment. The real waste is turning the page learning nothing: every organization neglecting reviews repeats the same mistakes forever. A late or never-held review is lost experience.
How to run a constructive, not score-settling, review?
By framing the mindset: you analyze facts and processes, not people; you seek learning, not blame (“blameless” approach). Structure around “what went well / to improve / to try”, give everyone voice, and conclude on actionable lessons. A climate of trust is the condition of a useful review: if people fear blame, they hide real problems and the review serves nothing.
Bilal's deliverable is ready but nothing is validated in writing. What comes first?