Building a Project Memory That Outlives Turnover
The person who knew why the foundation detail changed took a job in another province. Her handover was two hours and a link to a shared drive with 4,000 files in it.
Nobody did anything wrong. She gave what she had; the team took what they could carry. Six weeks later a subcontractor asked why a detail had been specified the way it was, and the honest answer was that the only person who knew had moved 900 kilometres away. The reasoning walked out the door with her. Here's the part worth sitting with: almost none of what she actually knew was in those 4,000 files.
Turnover isn't the risk. Unwritten reasoning is.
Drawings survive turnover perfectly well. So do contracts, schedules, budgets, permits and submittals — all of it stays exactly where it was. What leaves with a person is the layer underneath: why the third option was chosen over the second, which constraint made the obvious answer impossible, what was tried two years ago and quietly abandoned.
That layer is the actual project memory, and most organizations have nowhere to put it. It lives in heads, in a handful of email threads, and in the tone of voice somebody uses when they say “don't do that.”
The four things a newcomer actually needs
A handover doesn't have to transfer everything. It has to transfer enough that a competent stranger can act correctly on Monday morning. In practice that's four categories:
The current state. Where the work genuinely stands, as distinct from where the last status report said it stood.
The decisions that got you here. Each with the one-sentence reason behind it. The reason matters more than the decision, because the decision is already visible in the work.
The open commitments. Everything this project has promised somebody else, and everything somebody else has promised it. This is where handovers fail most expensively.
The landmines. The things a newcomer would reasonably do that would blow something up. Usually a short list, and almost never written down anywhere.
Notice the shape of it. The categories that survive well are the ones that were already a byproduct of doing the work — you can't build without drawings, so drawings exist. The categories that evaporate are the ones that required somebody to stop and write them down separately.
Make memory a byproduct, not a chore
That is the whole trick, and it's why “we should document more” never works. Documentation as a separate task loses to the work itself on every project, every time. Anything that depends on a busy person doing an extra thing at the end of a hard day is not a system. It's a wish.
Capture the reason where the decision happens, not in a document written later
One mandatory field, one sentence: why this, and not the obvious alternative
One place per project, so “where does this go?” is never a question anyone has to answer
Generate the handover document from what's already recorded, instead of writing it from memory during somebody's notice period
The two-hour handover is a symptom, not a cause
If your handovers are short, it isn't because your people are careless. It's because there was nothing to hand over that wasn't already in the shared drive, and everyone in the room knew it. The test is blunt: if your most knowledgeable person gave notice tomorrow, could a competent stranger take that project over on Monday? If the answer depends on her staying reachable by phone for a few months, you don't have a project memory. You have her.
Closing that gap is the problem we built XNM-VISION to end — though even if you never touch our software, the four categories above will carry most of the weight.The rest of the pattern is written up here, and it costs nothing to start on Monday.
