If It Isn't Written Down, It Didn't Happen

Eleven months after the design was signed off, six people are in a room deciding who pays for a rebuild. The client's programme director says the resilience requirement was always in scope. Your architect says it was explicitly descoped on a call in the March. Everyone in the room believes their own version completely. And there is no record, so the loudest version wins.

I have been in that room. It is not a fun room.

The reason this keeps happening is that nobody is lying. Two people can leave the same call with genuinely opposed recollections, and both will pass a lie detector.

What actually happened in that March call was that someone said "we could probably drop the second data centre for phase one and pick it up later." The architect heard a decision. The client heard a suggestion that was never confirmed. Both were in the room. Both were paying attention. Eleven months later, there is nothing to consult except two confident humans.

You cannot fix this with a better memory or a better meeting culture. You fix it with a sentence typed within about an hour of the call, which is the window in which you still remember the actual wording.

You do not need a document management strategy. You need four categories, and a habit.

Decisions. What was decided, by whom, on what date, and what the alternative was. That last part is the one that makes it useful a year later, because the question in the room is never "what did we decide", it's "why on earth did we decide that". If your record says "agreed to single-site for phase one (alternative: dual-site, rejected on cost, decided by the client's programme director on 12 March)", you're finished. Nobody argues with that.

Approvals. Who said yes, to what version, and when. A verbal yes on a call is an approval that will evaporate. Convert it the same day: "Confirming your approval on today's call for the revised cutover plan v1.3, attached. Shout if I've misread anything." You've now got an approval with a version number on it.

Changes. Every movement in scope, design, timeline, or money, with the date it moved and who asked for it. The killer is not the big change, that one gets a change request and a signature. The killer is eleven small ones that each took an extra day and a half, agreed informally, which collectively ate your contingency. Nobody can point to the moment the programme went late because there wasn't one.

Assumptions. This is the category everyone skips, and it is the one that saves you.

An assumption is something you've had to take as true in order to plan, which nobody has actually confirmed. "The existing cabling is Cat6 throughout." "The client's security team will review within five working days." "Store closures over the refresh period are no more than two per week."

Every one of those is load-bearing. Every one of them is unverified. And when one of them turns out to be wrong, the conversation goes one of two ways depending entirely on whether you wrote it down.

If it's in a log that was shared in week one, the conversation is "assumption 14 was wrong, here's the impact, here's what we do now." Boring. Solvable. If it isn't written down anywhere, the conversation is "why did you assume that", which is a conversation about your competence rather than about the cabling.

Write them as you make them, which is usually while estimating. Keep them somewhere the client or sponsor has seen. Review them at every milestone and mark each one confirmed, wrong, or still open. A ten-line list, updated monthly, has settled more disputes than any contract clause I've ever read.

Here is where most well-intentioned leads fall over. They do document things. The documentation is scattered across a chat thread, three email folders, someone's personal notebook, a wiki page nobody has opened since April, and a shared drive with two folders called "Final".

The test is brutal and you should run it on yourself. Someone asks: who approved the change to the migration sequence, and when? You have ninety seconds. Can you produce it?

If the answer is "I'd have to dig", you don't have an audit trail. You have archaeology.

What works is deliberately unglamorous. One decision log per programme, one place, chronological, never deleted. Every entry gets a date, a decision, an owner, and a link to whatever the underlying artefact is. Meeting notes go in the same place with the same naming convention. Version numbers on anything commercial or contractual, and the old versions kept rather than overwritten. Chat is where things get discussed, never where they get decided, and if something gets decided there, it moves to the log that day.

And tell people where it lives. An audit trail nobody else can open protects you and nothing else.

There is a failure mode on the other side and it deserves naming, because some people read all of this and become insufferable.

Documentation as a shield looks like this: everything gets an email, every email exists to establish that the problem is somebody else's, every risk is logged and none is chased. The person builds a paper record proving they raised it, while the thing they raised sails into a wall. Then they produce the file.

That is not accountability. That is accountability theatre, and experienced people spot it in about a fortnight.

The distinction is what you do after the record exists. A trail is written so the team can make good decisions and be defended later. A shield is written so one person can be blamed instead of you. If you find yourself copying someone in purely so they're implicated, you've crossed over. Write the record, then go and fix the thing.

Pick your current delivery. Find the single place your decisions live. If there are two places, there are zero places.

Then name the person who owns the log. One name, said out loud, in the next team meeting. It can be you. It is often better if it isn't, because a delivery lead who owns the notes ends up writing notes instead of leading. Whoever it is, their job is a five-minute pass at the end of every steering or design meeting: decisions, approvals, changes, assumptions, each with a date and a name.

Do that this week and start the log with a backfill of the last three decisions you made. You'll remember those. You won't remember the ones from two months ago, and that is precisely the point.