A project is delivered, the customer says thank you and everyone moves on. Six months later someone asks which version of the specification was approved, who had access to the test server, or what exactly was promised about support. The answers are in a former colleague's inbox, a folder called "final_v3" and a chat thread nobody can search.
Closing a project is a small job, but it is easy to skip because nothing is on fire. This article gives a short routine for the end of one engagement: what to keep, where it goes, who owns it and when the rest is deleted. It is about closing a single project. For the company-wide rules on how long each type of record is kept, see the data retention schedule for business records. For how the working folders are laid out in the first place, see shared drive folder structure and file naming rules.
Decide the archive day
Set the archive day when the project is closed, not later. A good default is two to four weeks after final hand-over, which leaves time for the customer's last questions and any small fixes. Write the date in the project's closing note and put it in the owner's calendar.
The person who ran the project owns the closing. Another person, usually the owner of the company or the office manager, confirms it is done. That second look is what stops "I'll do it next week" from lasting two years.
Keep five things
Most of a project folder is working material that has no value once the work is accepted. What is worth keeping is small and predictable.
- The agreement. The signed quote or contract, the order, change requests and the acceptance confirmation. If the customer later disagrees about scope, these are the documents you will open first.
- The final deliverables. The version the customer received, exactly as sent: documents, drawings, exports, and for software the release you handed over, its version number and its documentation. Keep what was delivered, not every intermediate draft.
- The decisions. A one-page list of the choices that shaped the work and why they were made. For a software project this includes the options rejected. It is the part new colleagues will thank you for. A handover note like the one described in who owns an internal tool after its author leaves is a good model.
- Access and contacts. Which systems, accounts and environments the project used, who at the customer and at suppliers was involved, and who revoked which access on which date. Record where credentials are managed, never the credentials themselves.
- Lessons learned. Three to five lines: what went well, what cost more than expected, what you would do differently. Without this, the next project repeats the same mistakes.
Everything else is a candidate for deletion: duplicate attachments, test exports, screenshots, meeting recordings and drafts that were replaced.
Put it in one place
Create one archive location for the whole company, for example a read-only "Archive" folder on the shared drive, with one subfolder per project named by year, customer and project name. The same pattern every time means anyone can find a project without asking.
Inside each project subfolder use the same five headings as above. A folder with five clearly named items is easier to trust than a copy of the whole working directory.
Make the archive read-only for everyone except its owner. Files that can still be edited are not an archive; they are another working folder that will quietly change.
Check what lives outside the drive. Project material often sits in email attachments, chat channels, a personal laptop, a code repository or a project tool. For each, decide: move the file to the archive, export it, or note where it stays and who is responsible. A repository can be archived in place, as long as the closing note says which one it is.
Write the deletion date down
The archive note should contain the date when the working copies will be deleted. A common pattern is thirty days after the archive day for working drafts and test data, and the end of the retention period for the archive itself.
Retention periods depend on the type of record. In the UK, a company must keep its accounting records for at least three years if it is a private company, and longer in some cases (Companies Act 2006, sections 386 and 388). Personal data is a separate question: data protection law says it should not be kept in identifiable form for longer than needed for the purpose (UK GDPR, Article 5). If the project involved customer personal data, decide what the archive really needs, remove or anonymise the rest, and write the reason in the note.
When the date comes, delete. Put it on the yearly clean-up day if you have one, and record who deleted what. If a dispute or a request is open, pause the deletion and write down why.
Close the access
Archiving is also the moment to close what the project opened. Remove the project team's access to the customer's systems and the customer's access to yours, shut down test environments and rotate any shared credentials. Record the date next to each item in the access list.
For software projects, check three more things: that the production system has a named owner or a support agreement, that backups cover it, and that licences and domains the project depends on have a renewal date and someone responsible. Otherwise the project is archived but the thing it built is orphaned.
A one-page closing checklist
Copy this into your project template.
- Final hand-over date and customer acceptance recorded
- Archive day set and owner named
- Agreement and change requests saved
- Final deliverables saved exactly as sent
- Decisions page written
- Access list complete, access revoked, dates recorded
- Lessons learned written, three to five lines
- Folder moved to the read-only archive, working folder marked for deletion
- Deletion date for working copies written down
- Second person has checked the archive and signed off
Ten lines are enough. If the checklist takes more than an hour to complete for a typical project, the project folder was probably too messy during the work, which is a topic for the next retrospective.
Common mistakes
Archiving everything. A full copy of the working folder is expensive to store, impossible to search and a risk if it contains personal data you no longer need.
Archiving nothing. "It's all still in the folder" works until the person who knows the folder leaves.
No owner. An archive that belongs to everyone is maintained by no one.
Passwords in the archive. Credentials in a document become a security problem long after the project ends. Record where access is managed instead.
No deletion date. Without one, working copies stay forever and the archive becomes a second, bigger mess.
What to do this week
Pick the last project you finished. Spend one hour on the checklist: save the five items, move them to a single archive folder, name an owner and write the deletion date. Then add the checklist to your project template so the next project closes the same way.