The Two-Week Absence Test: What Your Handover File Should Prove

December is a strange month on UK projects. The calendar is full of deadlines, but the office is half empty. People disappear for annual leave, the odd supplier goes quiet, and decisions that normally take a morning can stretch into a week because the right person is on a train to somewhere with poor signal.

That makes it the perfect time to run a test almost nobody runs willingly: could your project survive you taking a fortnight off?

I do not mean a theoretical test. I mean handing your project file to a capable colleague who has never sat in your stand-up, giving them the document, and asking them to keep things moving while you are out of the picture. If they can do it, you have a handover record. If they cannot, you have a diary with extra steps.

The test, not the document

The mistake most teams make is treating handover as a leaving ritual. Someone writes a long document in their final week, attaches it to an email, and feels better. The document is usually a data dump: file paths, meeting names, a list of contacts, and a few notes that assume the reader already knows the context.

A useful handover record is different. It is written so that someone competent but outside the daily loop can make sensible decisions for two weeks. That person does not need to know everything you know. They need to know where to look, what matters this week, what can wait, and when to escalate.

So run the test before you need it. Pick someone from another team, or a delivery lead who supports the project but does not run it day to day. Give them the file on a Monday morning. Ask them to answer three questions by the end of the day. Then watch where they get stuck. The gaps are your to-do list.

What a genuinely useful handover record contains

A good handover file is not a novel. It is a working map. It should include the current state of the project in plain English: what has been delivered, what is in flight, and what is due next. It should list the decisions that have already been made and the reasons behind them, because a decision without its rationale is just a rule waiting to be broken.

It should also cover the commitments that actually bind the project: contractual dates, supplier obligations, internal approvals, reporting deadlines, and any fixed events that cannot move. Add the risks that are live this month, not the full risk register. Add the triggers that would make someone escalate, and the names of the people who can actually decide.

Then there is the unglamorous material that causes most of the trouble: access to systems, shared drives, meeting links, distribution lists, version control, and the workarounds people use because the official process is too slow. If your project depends on a spreadsheet that only you can update, that is not a handover document problem. That is a single point of failure wearing a lanyard.

A useful file also says what not to do. Which supplier conversation is sensitive? Which stakeholder prefers a phone call rather than an email? Which approval route looks optional but is not? That kind of context is hard to write down, but it is exactly what a temporary stand-in needs.

Three questions that expose single-person dependency

If you want a quick diagnostic, use these three questions. They are deliberately practical, and they work best when the person answering has not been briefed verbally.

First: if the main supplier goes silent on day three, what does the file tell you to do, and who decides? If the answer is call me, the handover has failed. The file should name the escalation route, the contractual position, and the person who can authorise a fallback.

Second: which date in the next fortnight is immovable, and what must happen before it? A good file makes the critical path obvious. A weak file lists meetings but not consequences. The stand-in should be able to see which milestone matters, what feeds it, and what happens if it slips.

Third: what is the one decision you would expect me to make that is not written down? This is the question that catches the quiet dependencies. It might be a judgement call about quality, a tolerance on cost, or a stakeholder sensitivity that lives only in your head. If the stand-in cannot answer, you have found the gap.

Why December is the right time to try it

December is useful precisely because it is quiet. The pressure is lower, the stakes are usually manageable, and people are more willing to spend half a day testing a process they would ignore in a busy October. It also mirrors reality. The last two weeks of the year are when annual leave, sickness, and skeleton crews combine to create the exact conditions a handover file is supposed to survive.

Run the test as a fire drill, not a paperwork audit. Give the stand-in a real task, not a reading exercise. Ask them to update the status report, chase a supplier, or prepare a decision note for the sponsor. Then review what happened in thirty minutes. Where did they have to guess? What did they have to ask you? What would have gone wrong if you had been on a plane rather than at your desk?

Who should be able to pick it up

The honest answer is more than one person. A handover file that only your deputy can use is a backup person, not a backup system. The sponsor should be able to understand the current position. Finance should be able to see the commitments. A delivery lead from another workstream should be able to keep the basics moving. If the file only makes sense to someone who already knows the project, it is not a handover record. It is a memory aid.

That does not mean everyone needs the full document. It means the document should have a short front page that tells any reasonable reader what the project is, what is due, what is at risk, and who to call. The detail can sit behind that. The front page is what buys you time when nobody can reach you.

Keep it alive

A handover file written once and never updated is worse than no file at all, because it creates false confidence. Update it at milestones, after major decisions, and before any planned leave. Keep it short enough that people actually read it. A living document with a few blunt sentences beats a polished archive that nobody opens.

The best time to discover a handover gap is a quiet Tuesday in December, not the morning you are on a train with your out-of-office on. Test the file while the desks are half empty. If the project can survive a fortnight without you, you have built something more valuable than a document. You have built a project that does not depend on one person's memory.