Project handover checklist

Maria is moving to Harbor Clinic full time, and Priya and Daniel are taking over her work on Northstar Offices. The drawings are on the server and the emails are in the shared inbox, so the files are fine. What gets lost is everything around them: that the lobby finishes package can go to the client without the stone sample decision, that mechanical moved two diffuser locations last week, that the client was promised the package on Wednesday.

None of that is in a drawing. It's in Maria's head, and it leaves with her unless someone writes it down while she's still there. This checklist covers what to write down, and how Arkscape, a project tracking tool for architects, designers, and engineers, keeps most of it on the work itself.

The checklist

Work through it with the person leaving, before their last day rather than after it.

Where the project stands

• The current phase and the next milestone, with its date
• What was issued last, to whom, and when
• Anything that will move a date in the next month, and why

Open tasks

• Every open task has a new responsible person
• Each new owner has accepted their tasks, not just been told about them
• Tasks with no date have been given one, or closed

Promises to the client

• What the client has been promised, and by when
• Decisions and approvals the client still owes, with dates
• The client knows who their contact is now

Consultants

• What each consultant owes, and by when
• Who the contact is at each consultant, and how they prefer to be reached
• Questions already sent that haven't been answered

Decisions on record

• Where past decisions and approvals are recorded
• Decisions made in conversation that aren't written down yet

Files and drawings

• Where the current set lives, and which files are the latest
• Anything in a personal folder, inbox, or desktop that belongs to the project

Access

• The accounts, shared folders, and groups the new owner needs
• The access the person leaving no longer needs

The handover meeting

• Walk through this list together, with the open tasks on screen
• A date for a follow-up session one or two weeks later

How to run the handover

Start as soon as the leaving date is known. The checklist takes a few hours spread over a week, and it can't be done after the person has gone.

Ask the person leaving to go through their open tasks first, writing down for each one why it's in the state it's in. That context is the most valuable part of the handover, because a task title says what has to be done and only they know what's been tried, promised, or decided. Then the project lead chooses who takes each task, and asks them.

A task is handed over when the new owner has accepted it. Being told about it in a meeting isn't the same thing. Write down the decisions that were only ever made in conversation, tell the client and each consultant who their contact is now, and hold the meeting with the open tasks on screen. Call it done when every task has an owner who said yes, not when the last day arrives.

Where a handover document falls short

A handover document is a copy of the work, made on one afternoon. From the next day the tasks keep moving and the document doesn't. And context written in it is read once and forgotten: the person who picks up a task a month later won't think to open last month's handover notes.

The better place for the context is the task itself, and the better proof of a handover is the new owner's own yes.

Handing over in Arkscape

In Arkscape, each project is a group with its own board, and every task is a card with one Responsible person. A card someone has accepted is also on their own board, Your Ark, as the same card. So the handover happens on the cards themselves.

Start with the project group's Reports tab. Workload by person shows how many open cards the person leaving is responsible for, how many are overdue, and how many are still awaiting their acceptance. The board's Activity, in its ... menu, can be filtered by person to show what they changed recently.

Cards that belong to the project but were created on their own Ark should move to the group first. Only the person who created a card can move it, so this step is theirs: they open the card's menu, choose Move to a group, and leave Keep it on my Ark as Responsible ticked, so it arrives ready to reassign.

Then change the owner of each card. In the card's Responsible menu, choose Reassign to... and pick the new person. The card leaves the previous person's Ark straight away, and the new owner gets a request they answer with Accept or Decline. Until they accept, the report counts the card as awaiting acceptance, so you can see which tasks have been handed over and which have only been sent. Whatever you would have written in a handover document goes in the card's notes, where the next person will find it a month from now.

Every step is on the record. Each card's History shows who assigned, reassigned, and accepted it, and when, along with changes to its dates and notes.

Cards shared with a consultant or client through Add people stay with the person who created them, who can hand the work on with Reassign to... in the card's people list but remains its owner. For consultant work that should outlast one person, the project group's board is the better home.

If someone leaves the group before handing over, they come off every card on its board, and the cards they were responsible for show as Unowned in the group's report until someone takes them on.

Groups, cards, History, and Activity are on every plan, including Free. Group reports come with the Business plans, from $25 per user a month with a 14-day trial, and with the Connect ($10) and Pro ($20) Personal plans.

Common questions

What should a project handover document include? Where the project stands, every open task with a new owner who has accepted it, what the client has been promised, what consultants owe, decisions on record, where the files are, the access needed, and a date for follow-up questions.

How long before someone leaves should the handover start? As soon as the date is known, so their last days are for questions rather than writing.

Can I use the same checklist for someone going on leave? Yes. Note the return date with each task, and hand the tasks back the same way when they return.

What if the person has already gone? Start from what's written down: the tracker, the last issued set, and the email threads. Then ask the client and each consultant what they're waiting for. They'll know.

Read next: how to delegate tasks and know they were taken on, how architects and engineers work together, and how card History works.