When you work on a large web project, there will come a time to hand it over to another team. This could be a handover from an outside agency to an internal team, or from one internal team to another.

Handovers are always tricky. They’re as much about people and culture as they are processes and technology.

Here’s what we’ve learned over the years, distilled into 12 tips. Whether you’re a client organisation or a supplier, hopefully you can benefit from our experience.

1. Assume zero context

Handovers involve two teams:

The incoming team picking things up
The outgoing team putting things down

The outgoing team might have made the thing. The new team might be coming in to maintain it. Those are very different contexts.

Whatever the circumstances, it’s possible the incoming team has zero context. They might not know the goals of the project, or even what they’ve been brought in to do. The team might be comprised wholly of new hires.

If people are moved from elsewhere in the organisation, it’s probably a gentler on-ramp. But whatever the circumstances, skew cautious. Don’t make assumptions about what the incoming team already knows.

2. Make a plan

Making a handover plan is essential. It should be an actual document. It doesn’t need to be long.

Handovers are mostly about people, so the plan should be people-oriented, with input from everyone.

A list is a good place to start. Lists help you:

Align as a team
Assign and prioritise activities
Adapt to different project structures like now, next, later¹
Report progress

Include all possible duties, especially when it’s not clear how to do them.

Talk through the list with everyone. You’ll land on things you’ve missed, and things you thought were clear but aren’t. Expand on these.

Over time, you can flesh the plan out with useful, more detailed information.

To start with, the plan will be mainly written by the outgoing team for the needs of the incoming team. Gradually, the incoming team will have more input.

3. Start with fundamentals

The plan should contain whatever the incoming team needs to continue the project autonomously before the outgoing team pack their boxes.

Helpful things to include are:

Aims of the project
A who’s who of stakeholders
Where things are (e.g. project documents)
Working processes (this saves lots of time)
Project history and context
Project architecture
Unusual and unintuitive aspects
Unresolved points of friction

Remember that it’s a working document, not carved in stone. Add generously, then edit ruthlessly. Keep only useful things.

4. Work in phases

Identify which list items you can start handing over straight away.

Use paired working to gradually hand over trickier duties. Let the incoming team member take responsibility as soon as they can, but take as long as is needed.

Not everything will go smoothly. Reassure the incoming team that points of friction are a chance to make the plan better.

5. Test, then iterate

The plan should evolve alongside the handover process.

As the incoming team ramps up, have them use the plan to find its gaps and weaknesses. Figure out who’s best placed to address them. Over time, it’s less likely this will be someone in the outgoing team.

The plan could pan out in these stages:

Drafted by the outgoing team
Iterated by the outgoing team based on feedback and observations
Iterated by the incoming team based on their learnings and needs

But there are no handover police. Do what works.

6. Don’t prescribe

A handover plan shouldn’t tell the incoming team how to run the project. It should help them reach the point where they can run it themselves.

It shouldn’t be:

A knowledge repo
A disciplinary guide
A product roadmap or backlog²
A list of problems to fix
The home of project documentation

Report what you’ve been doing to the incoming team, and how you’ve done it. The incoming team should have freedom to do things differently.

Avoid directly mapping outgoing people to incoming people. It’s a form of telling the incoming team how to work, and skills don’t align this way. Hand over at team level.

7. Acknowledge feelings

Letting go of something you’ve built is like sending a child to a new school. Anyone who cares about the work will have feelings about it.

Sometimes the incoming team will have strong opinions, and that can be challenging. Remember, they don’t have the organisational context for the decisions you’ve made.

Encourage frank discussion about why things were done the way they were. They may uncover organisational challenges that should be documented.

But be prepared to let things go. You can’t make people understand past decisions. An opinionated team is better than an incoming team that just wants to be told what to do.

It can be hard for the outgoing team members to not know how the story ends. Suggest ways to catch up in future, even if it’s just going for a coffee. This helps with closure and personal development.

Ultimately, it’s essential to let go. If by the last day and the outgoing team are holding on to things: problems.

8. Manage time

Don’t preempt a handover before it’s real. You’ll waste time on things that will change in future.

Start planning as soon as you know a handover’s coming. A few months is usual, although it depends on the project’s scale and complexity, as well as the number of people involved.

You’re handing over culture and relationships as well as systems and processes. Those aspects take time.

If you weren’t given enough notice, share feedback to sow seeds for a rosier future.

9. Tidy up

A handover is a great excuse to tidy up the project. Leave the incoming team with forward momentum. If they have to unpick knotty problems from day 1, the project will grind to a halt.

We like to think of it as parking the project nicely so someone else can get in and drive off.

Resolve as many problems and fix as many broken things as you can before final handover. Prioritise issues that require contextual knowledge.

10. Keep a friction log

You won’t be able to fix everything, and not everything should be done by the outgoing team.

Note outstanding issues in a friction log. This could be a section of your handover plan.

For example, you might discover a process that was hindering progress. It’ll be down to the incoming team to find a better way.

Any decisions that that will have a long-term effect should be left to the incoming team.³

11. Treat the handover as core work

Don’t think that two teams means double capacity. There’s plenty to do to keep the project on track while also handing over.

Project work and business-as-usual activities should continue. This prevents the handover plan being theory rather than practice. It shows how things work.

Don’t worry about keeping the outgoing team busy. If, by the end, they have nothing to do, things have gone well. If they’re grafting on their last day, you’ll be lost when they go.

Above all, don’t create urgency. It’s not the time to kick off a large or complex piece of work.

12. Make friends

The outgoing team should make friends with the incoming team. The incoming team should make friends with everyone.

If possible, get together in person at the beginning of the process. Be honest about the challenges the project and organisation has gone through.

Be engaged but not obsessive. Doom and gloom isn’t the vibe — keep it positive.

Three things to remember

Handovers are about people more than technology or logistics. So:

Make a plan around the needs of the people involved
Include people’s feelings in your thinking
Carve out time for the actual handover work

Prioritise these, and you stand every chance of a successful handover.

See Escaping the roadmap trap by Emil Kabisch for creating roadmaps which differentiate now, next and later. ↩
Although the plan shouldn’t be a roadmap, it should be easy for the incoming team to derive one from your list of duties.) ↩
The friction log is another source the incoming team can use to create a roadmap. ↩

12 tips to make project handovers a success