Engineering
A project is not finished until the agency can run it without the vendor
The artifacts and demonstrations an agency should require at closeout: code, pipelines, runbooks, credentials, and documentation.
Most of the risk in a software project arrives after the final invoice. Months later somebody has to change a fee schedule, rotate an expiring certificate, or tell an auditor how records are retained. If the handover was a slide deck and a zip file, that small change becomes a new procurement.
A project is finished when agency staff can operate, modify, and if necessary rebuild the system without the people who built it. That is a testable condition rather than a sentiment. The checklist below is the one we work from internally; the relevant parts can be lifted into a solicitation or an acceptance form.
The code, and the rights that come with it
The source belongs in a repository the agency controls, not one the vendor owns and shares. Ask for the full commit history rather than a squashed snapshot, because it is often the only surviving record of why something is the way it is. Tags or branches should correspond to exactly what is running in each environment.
Build instructions have to work on a clean machine. In our own reference builds, someone who did not write the code clones the repository, follows the written steps, and produces a working build. Include a dependency inventory with license information, preferably a software bill of materials in SPDX or CycloneDX format, and confirm nothing essential lives in a personal account.
Rights in software and technical data come from the contract. Federal acquisitions address them under FAR Part 27 and agency supplements such as the DFARS; states and localities set their own terms. Settle that language before work starts, while the leverage still exists.
Pipelines, not build instructions
Source code alone lets the agency read the system but not ship it. The deployment path should transfer as working automation: pipeline definitions, infrastructure defined as code, environment configuration held separately from secrets, and a documented rollback procedure.
The test is simple. An agency engineer makes a trivial change, runs it through the pipeline into production, and rolls it back while the outgoing team watches without touching the keyboard. If that cannot happen, the handover is not finished whatever the documents say.
Runbooks written for the person on call
Runbooks are written during the project, not in the last week, tested by somebody other than the author, and aimed at a competent engineer who has never seen the system. At minimum an agency should receive:
- How to start, stop, and restart every component
- Where logs and metrics live, and how to reach them
- How to restore from backup, and when that was last done end to end
- Every alert the system can raise, what it means, and the first steps to take
- Scheduled jobs, what each does, and what happens if one fails or runs twice
- Support contacts for every dependency, with account identifiers
Accounts and credentials
Cloud tenants, domain registrations, repositories, and third-party subscriptions should be created in the agency's name from the first day. Untangling ownership at the end is slow and sometimes impossible.
At closeout the agency should receive a written inventory: administrative accounts, service accounts, API keys, certificates with their expiration dates, DNS records, and every paid subscription with its renewal date and billing contact. Rotate every credential the outgoing team could reach, and treat the removal of their access as a dated, verified event rather than an assumption.
Documentation that gets opened
Volume is not the goal. Aim for a short set answering the questions that come up in practice: an architecture diagram matching what is deployed, a data dictionary, an inventory of integrations and the owner of each side, the significant design decisions and the reasons for them, security documentation mapped to the control set the system is assessed against, and an accessibility conformance report.
Which control set applies depends on the system. Federal information systems fall under FISMA, with controls drawn from the NIST SP 800-53 catalog, and cloud services bought for federal use go through FedRAMP authorization. States set their own standards, and criminal justice and health data carry extra requirements. On accessibility, Section 508 of the Rehabilitation Act covers federal technology procurement and its standards incorporate WCAG 2.0 Level AA, while state and local web content falls under the Department of Justice rule adopting WCAG 2.1 Level AA.
Include a candid list of known defects, deferred work, and shortcuts taken under schedule pressure. An empty list is never true, and an honest one helps the team inheriting the system.
Knowledge transfer as a schedule, not a meeting
A final walkthrough transfers almost nothing. Spread sessions across the last weeks of the project, record them, and structure them so agency staff do the work while the outgoing team advises. Have agency staff run a real deployment and a real data fix, and an incident if one occurs. Name the receiving staff early; documentation nobody has time to read changes nothing.
Putting it in the contract
Put handover in the solicitation and the acceptance criteria, with each item written as something demonstrable. Tie part of the final payment to those demonstrations, and run the deployment rehearsal and the credential rotation while the outgoing team is still under contract. A checklist verified after everyone has rolled off is only a list of things to discover later.