The most common way an engagement ends badly is not the deliverable being wrong. It’s the deliverable being right, and the client being left without the institutional knowledge to operate it, defend it, or build on it. Six months later, something breaks, the original team is gone, the documentation is partial, and the engagement that “succeeded” has produced a fragile asset.
The Close phase exists to prevent this. The eight artifacts below are what we hand off at the end of every engagement, regardless of workstream.
1. Deliverable inventory
A one-page list of every thing produced during the engagement, with its location and current owner. For a renovation: the property, the marketing materials, the listing, any vendor warranties. For a software build: the repo URL, the production URL, the credentials vault, any dependencies the client now owns.
Not a status of what we did — an index of what now exists and where it lives.
2. Decisions log
A chronological record of the consequential decisions made during the engagement, with the context that produced each one. “We chose vendor X over vendor Y in week three because Y’s lead time exceeded our window.” “We descoped the second-floor master bath in week eight because the structural inspection added $14k unplanned.”
This is the artifact that prevents the six-months-later why on earth did they do that moment. A decision without context decays into mystery; with context, it’s reusable judgment.
3. Final risk register
The risk register from the Run-phase practice, in its final state — every entry resolved with a one-line outcome (closed, fired and contained, fired and uncontained). This is the document a future PM reads to understand what actually threatened this engagement, as distinct from what might have.
The intermediate weekly versions are bookkeeping. The final-state version is the asset.
4. Lessons learned
What we’d do differently next time. Not what the client did wrong — what MHA would do differently. Three to seven items, each specific enough to act on.
Bad: “Communication could be improved.” Good: “Schedule the structural inspection in week one, not week six. Delaying it cost us two weeks of nominal-progress work that the inspection later invalidated.”
We write the Lessons Learned section together with the client if they want to participate, and for the client if they don’t. Either way, the document goes to them.
5. Vendor + contract index
Every third party touched during the engagement, what their role was, the contact who held the relationship, and where the contract lives. For a renovation: contractors, suppliers, inspectors, the listing agent, the title company. For a software build: hosting provider, payment processor, transactional email provider, any analytics or monitoring tool.
This is the artifact that prevents “we don’t even know who to call” three months after handoff. A client should not have to reverse-engineer their own vendor list from invoices.
6. Operating runbook
The short manual for the thing now in their hands. For a property: tenant onboarding, maintenance schedule, key contacts, recurring obligations. For a software system: how to deploy, where the logs are, who responds to an outage, how to roll back. For a programme: the cadence and template for ongoing reporting.
The runbook is not exhaustive documentation. It’s the answer to: if the person operating this from now on is reasonably competent but new to it, what’s the smallest document that lets them not be helpless? Usually three to ten pages.
7. Outstanding-items list
The honest list of things we did not finish, with one of three labels:
- Out of scope — never in the plan; mentioning so the client doesn’t think it was a gap.
- Deferred by decision — was in the plan, removed in the Shape or Plan phase by a recorded decision; flag the decision.
- Carried forward — was in the plan, didn’t ship, here’s the proposed path to closing it (whether by us, by the client, or by another vendor).
Most engagements have a few of these. Pretending they don’t exist is the surest way to a client realising six weeks later that something they expected is missing. Naming them is the integrity move.
8. Final financial report
What was budgeted, what was spent, where the variances came from, what’s still outstanding (invoiced but unpaid; contracted but not yet invoiced). One page, plain English. The summary should be readable by someone who wasn’t in the engagement.
If we earned a fee structure tied to outcomes (e.g., a percentage of margin on a property sale), the report reconciles the calculation transparently.
What we don’t hand off
- All meeting minutes. Filed for our own records; not part of the handoff.
- Slide decks. Slides are for the meetings they were made for; they’re not durable assets.
- Draft documents. Only final versions go in the handoff.
- Tooling we used internally. Our project tracker, our internal templates — those stay with us.
When this gets delivered
Two to four weeks before the engagement’s nominal end, we draft the eight artifacts and circulate the index. The client reads them and tells us what’s missing. We revise.
At the engagement’s actual end, the artifacts are delivered as one bundle — usually a shared folder, organised in the order above, with a one-page README listing all eight. The bundle is the engagement’s last deliverable. It is also, in our experience, the artifact clients most often cite when explaining why they re-engaged us for the next project.
It is faster to re-buy a relationship that left a useful Close behind than to recover one that didn’t.