4 min
FOUNDATIONS · LESSON 01.08beginner

How a project ends.

Closure, handoff, retrospective — the parts new PMs skip.

↳ tl;dr

Most projects don't fail at the end — they just leak away. The deliverable ships, attention drifts, and the closure work (verification, handoff, lessons-learned, formal sign-off) gets compressed or skipped entirely. PMBOK calls closure a real phase for a reason: it's where credibility for the next project is banked or burned.

Three things have to happen

  1. Verification — does what was delivered actually meet the acceptance criteria the team agreed to at kickoff? Not "does it look done" — does it pass the criteria written down at the start.
  2. Handoff — who's the long-term owner of this thing now? Who do tickets go to? What runbooks exist? If the project leaves the building without an owner, you've created an orphan.
  3. Retrospective — capture what worked, what didn't, and what the next team should know. Even just 30 minutes saves the next team a quarter.

Sign-off — the formal gesture

PMBOK calls it "close project or phase" — the formal ceremony where the sponsor accepts the deliverable in writing. The gesture matters. Without it, the project never officially ends, and you'll find yourself getting pinged about it eight months later. The sign-off email or document is what closes the loop and frees you to move on.

The retrospective discipline

Scrum bakes a retro into every sprint. Waterfall and traditional PM cultures often save it for project end — and then skip it because everyone's already on the next thing. Both are mistakes. The cheapest learning happens close to the event.

A good retro answers four questions:

  • What did we set out to do?
  • What actually happened?
  • What worked well — to keep doing?
  • What didn't — to change next time?

the most common failure

The retro becomes a venting session about the team you collaborated with. McConnell calls this blaming people instead of systems. The good retro question isn't "who failed?" — it's "what would we change in our process so the same thing doesn't happen again, regardless of who's on the next team?"

Closure for cancelled projects

Cancelled projects deserve closure too. The temptation is to quietly walk away. The disciplined move: a short closure doc that captures (a) what we built, (b) what we learned, (c) what the residual code / contracts / commitments are, (d) who owns unwinding them. The next team that proposes something similar will look for that doc — and your name on it is reputation currency.

in the wild

The PMs who get promoted aren't the ones who shipped the most projects — they're the ones whose last impression on a project was clean. A clean ending makes sponsors want to fund you again.

// practice this

Run a debrief in the simulator

Every chapter ends with a debrief — that's the simulator's version of a retrospective. Notice how the framing focuses on patterns and decisions, not who-was-at-fault.

// sources

Sources cited

  1. [01]
    A Guide to the Project Management Body of Knowledge (PMBOK Guide), 7th Edition

    Project Management Institute (PMI) · 2021 · retrieved 2026-04

    PMI's flagship reference. 7e shifted from process groups to performance domains.

  2. [02]
    Rapid Development: Taming Wild Software Schedules

    McConnell, S. · Microsoft Press · 1996 · retrieved 2026-04

    Catalogues 36 'classic mistakes' of software project management.

  3. [03]
    The Scrum Guide (2020 revision)

    Sutherland, J. & Schwaber, K. · Scrum.org / Scrum Alliance · 2020 · retrieved 2026-04

    The canonical Scrum definition. ~13 pages — short and dense.

// sources

Further reading

  1. [01]
    A Guide to the Project Management Body of Knowledge (PMBOK Guide), 7th Edition

    Project Management Institute (PMI) · 2021 · retrieved 2026-04

    PMI's flagship reference. 7e shifted from process groups to performance domains.

  2. [02]
    Rapid Development: Taming Wild Software Schedules

    McConnell, S. · Microsoft Press · 1996 · retrieved 2026-04

    Catalogues 36 'classic mistakes' of software project management.