Closing Contracts Without Leaving Loose Ends
Contract closure rarely looks like an event. The work tails off, the last invoice is paid, the supplier's people stop appearing in the stand-up, and at some point everybody assumes the arrangement has ended. What has actually happened is that attention moved on while a set of obligations, permissions and possessions stayed exactly where they were.
Closing a procurement properly is the work of detaching everything that was attached to it, and then recording that this has been done. It is unglamorous, it takes a day or two, and the projects that skip it generate the sort of problem that surfaces eighteen months later in somebody else's audit. Appendix X4 of the PMBOK® Guide Eighth Edition places procurement inside the wider delivery picture, and closure is the point where that connection is easiest to forget.
What has to be true before you close
The deliverables have been verified against what was agreed, by somebody competent to judge. Not received, not installed, verified: the acceptance criteria applied and the result recorded. Where a deliverable was accepted with a caveat, the caveat needs a home before the contract stops being the mechanism for pursuing it.
The money is settled in both directions. Final invoices, retentions held and due, credits for service failures, any disputed amounts and any charges the supplier has not yet raised. Suppliers do occasionally invoice after closure, and a final account agreed in writing is what makes that a short conversation.
The disputes are resolved or formally parked. A claim that is genuinely unresolved does not disappear when the contract closes, and the closure record should state its status plainly. Projects that close a contract while quietly hoping an argument evaporates are choosing the worst of both positions.
What outlives the contract
Data is first, because it is the one most often missed. Copies of client data sit in a supplier's test environments, on migration staging servers, in analysts' working folders and in backups. The contract usually says what should happen to it. Somebody has to ask for confirmation that it happened, and record the answer.
Access comes next. Accounts on client systems, building passes, VPN certificates, shared mailboxes, administrative rights granted for a cutover and never removed. Every one of these is a live permission held by an organisation that no longer has a reason to hold it.
Licences and rights need checking against what was actually bought. Who owns the configuration, the custom code, the documentation and the designs. Whether the licences transfer to the client or sat in the supplier's name. Whether anything the supplier used is subject to terms the client has now inherited without knowing it.
Warranty and defect periods run after closure by definition, and they need an owner inside the organisation who knows they exist. A twelve-month defect liability period is worth nothing if the person who knew about it has moved on and the first failure is fixed at the client's cost.
Fourteen months of donor records
A charity replaced its supporter database. The implementation went reasonably, the system went live, the supplier's team rolled off, and the final invoice was paid in the March.
The migration had been run from a staging environment in the supplier's own tenancy, holding a full copy of the supporter file: names, addresses, giving history and, for a subset, information about circumstances that had been recorded in case notes. The contract required its deletion within thirty days of acceptance. Nobody asked for confirmation, and the supplier's project team had dispersed to other work without raising it.
It came to light fourteen months later, when the supplier suffered an unrelated security incident and, to its credit, told every client what data had been in the affected environments. The charity's trustees then had to explain to their regulator why supporter data had remained with a supplier a year past the point the contract required its removal. The closure step that would have prevented this was one email and a written reply. Knowing which of these steps a given contract genuinely needs, and building them into the plan before the team disperses, is procurement and closure ground that Omega's PMP® Exam Preparation works over.
Making closure something you can actually do
Write the closure list when the contract is signed, not when the work ends. At signature you know what data will be shared, what access will be granted, what will be licensed and what warranties will apply, because you are agreeing them. Capturing them then takes twenty minutes. Reconstructing them at the end means reading the contract again with the people who negotiated it already gone.
Record how the supplier performed while anyone still remembers. A short, factual note on what they were good at, where they needed managing and whether you would use them again is worth more to your organisation than most of the documents a project produces, and it takes a paragraph. It also gives the next project manager something better than a rumour to work from.
For a PMP® candidate, the point worth holding is that closure is a control, not an administrative tidy-up. A scenario describing a supplier who has finished work, a client who considers the project complete and an obligation still outstanding is describing a procurement that was abandoned rather than closed, and the useful response is to complete the closure activities, including the formal record.
Take ten minutes at the next supplier review and list what that supplier currently holds: which of your systems they can reach, which of your data they have, and what they would need to return or destroy if the contract ended next month. Most people find at least one item on that list they had forgotten about, and it is far cheaper to find it now.
Interested in going further?
Closing a contract cleanly protects an organisation long after a project team has moved on, and it depends on knowing what to look for while the relationship is still live. Omega's PMP® Exam Preparation covers procurement from strategy through administration to closure as one connected sequence.
Appendix X4 of the PMBOK® Guide Eighth Edition sets out how procurement activity, including closure, connects to the rest of a project.
Ad · Amazon affiliate link.
References
A245: Make or Buy? How to Decide Before Procurement Begins
A246: Procurement Strategy: Decide How You Will Buy Before You Go to Market
A247: RFP vs RFQ vs IFB vs ITT: Which Procurement Document Should You Use?
A248: Choosing a Supplier: Cheapest Is Not the Same as Best
A249: Fixed-Price vs Cost-Reimbursable vs Time-and-Materials Contracts
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
