How to Run a Clean Project Handover Before You Leave

A handover done badly follows you out the door, because the person inheriting your work keeps calling with questions you could have answered in a document. A handover done well lets you leave cleanly and lets your successor look competent from day one. The difference is rarely effort and almost always structure. Most people dump files and context in a rushed final week and hope for the best. This guide lays out how to plan a handover early, what to actually write down, and how to run the conversations that make written notes stick.

Start the Handover Weeks Before You Leave

A handover crammed into a final afternoon fails because context lives in your head and leaks out slowly. Begin at least a few weeks ahead by keeping a running list of everything you touch and the knowledge each task quietly requires. The small things, which contact to email, where a password lives, which stakeholder dislikes surprises, are exactly what gets forgotten under time pressure. Early notes also give you time to notice gaps when your successor asks a question you cannot immediately answer. Treating handover as a process rather than an event is the single biggest factor in whether it holds up.

Write Down the Decisions, Not Just the Tasks

A task list tells someone what to do but not why the work looks the way it does, and the why is what prevents them from unraveling good decisions. Record the reasoning behind choices that are not obvious, the options you rejected, and the constraints that shaped the current approach. When the next person understands why a path was taken, they can adapt it instead of blindly following or needlessly reversing it. This record also protects the project from being relitigated every time a new voice questions a decision that was settled months ago for sound reasons.

Map the People, Not Only the Process

Projects run on relationships as much as procedures, and those relationships do not transfer automatically. Name the key people your successor will deal with, what each one cares about, how they prefer to be contacted, and any history that affects the tone. A stakeholder who needs early warning or a supplier who responds only to phone calls is the kind of detail that saves weeks of friction. Introduce your successor to the most important contacts in person or over a call before you go, so they arrive as a known quantity rather than a stranger inheriting a cold inbox.

Make the Document Findable and Scannable

A thorough handover note is useless if the next person cannot find it or cannot locate the one answer they need inside it. Store it where they already work, not in a personal folder that vanishes when your account closes. Structure it with clear headings, a short index at the top, and specific answers rather than vague summaries. Write it for a reader in a hurry who has a single question, because that is how it will actually be used. The test of a good handover document is whether someone can answer their own question in under a minute without calling you.

Walk Through the Live Work Together

Written notes carry the facts, but a live walkthrough reveals the gaps that writing hides. Sit with your successor and move through the active work in real time, showing them the tools, the recurring tasks, and the odd exceptions that never make it into documentation. Let them drive while you watch, so they hit the confusing parts while you are still there to explain. This session usually surfaces questions neither of you anticipated, and answering them in the moment is far cheaper than a confused email exchange after you have moved on.

Hand Over Access Before Your Last Day

Nothing strands a successor faster than discovering on day one that they cannot open a file, enter a system, or send on behalf of the project. Audit every account, shared drive, and permission the work depends on, and transfer or request access well before your final day. Test that the new person can actually reach each resource while you are still around to fix what breaks. Access problems are invisible until they stop someone cold, so treat the access checklist as seriously as the knowledge itself, because missing credentials undo an otherwise flawless handover.

Set a Clear Cutoff for Your Involvement

A handover without a boundary turns into months of you quietly running the project from your new role. Agree on a short window during which you will answer questions, then make the end of it explicit and real. A brief overlap is generous, but open ended availability signals that the handover was incomplete and discourages your successor from fully owning the work. Being clear and kind about the cutoff respects both of you. It forces the knowledge to land properly on their side rather than remaining on perpetual loan from yours.

Frequently asked questions

How far ahead should I start preparing a handover? Begin at least two to four weeks out. Context accumulates in your head and only transfers well when you have time to notice and record it. A single rushed final day almost guarantees forgotten details and follow up questions.

What is the one thing people forget to hand over? Access and reasoning. People document tasks but omit why decisions were made and which logins the work depends on. Both are invisible until the successor hits them, and both are expensive to recover after you leave.

Should I stay available after I leave? Briefly and with a clear end date. A short overlap helps, but open ended availability stops your successor from owning the work and keeps you doing a job you no longer hold.

Leaving Work That Stands on Its Own

A clean handover is a gift to your successor and to your own reputation, because work that survives your departure speaks well of how you ran it. Start early, write down the reasoning and the relationships rather than only the tasks, confirm access, and set an honest cutoff. Do that and you walk out the door without a trail of unanswered questions following you, which is exactly what a good exit should feel like.