Whether a member leaves a team or a team inherits a project, knowledge transfer is required so that the new owners can continue with the project, and the previous owners can move on to something else. We want to minimize archaeology when the new owner wants to add an endpoint, add a command, deploy the service, or flush caches. And we want to avoid constantly involving the previous owner. The purpose of the handover is to ensure that the new owner is in the best condition to continue the project and successfully accomplish its goals. And it’s the responsibility of both parties to make the handover a success.
Here are the expected results of the project handover:
- The project’s current status is well established.
- The transition from the current owner to the new one is documented and understood.
- A clear deadline for the process has been established, with milestones.
- The new owner has been introduced to the stakeholders.
- The project yields the same results and achieves the goals set out.
- The stakeholders are fully satisfied.
The handover process is not an easy task, and it’s hardly about updating an Owner file. The purpose of this document is to provide a checklist meant to help you have a successful handover.
Handover checklist
Planning
1. Identify the parties involved in the handover
Start by deciding which people should be involved in the process. That could be the team lead, the project owner, or a team member that really knows the ins and outs of the project. Everyone should have a clear role in the process.
It’s also very important to know the stakeholders. Does the service have an API? Who’s using it? Does the service publish messages? Who’s consuming them? If the service goes down, who would be impacted? Who should be informed of the handover, its progress, and its completion?
2. Prepare project status report
Establish the status quo of the project. For services, that could be known issues, areas of improvement, technical debt, a brief history of the recent incidents… Also, what’s still in the backlog that needs to happen next. Are these tickets that are over 6 months old still relevant?
The outgoing project owner prepares the project status report so that their successor would know what has so far been accomplished in relation to the set-out objectives for the project, and where to pick it up from. The outgoing project owner brings the new project owner up to speed on all matters on the project to ensure that the new project owner is well informed. This helps the new project owner to understand the whole project better. Once this is established, the information should be shared with both teams to make sure it’s accurate and understood.
3. Define a clear deadline for the handover
Consider all the phases and estimate how long they would take.
Establish a date by which the handover should be completed and communicate it to all involved parties.
4. Create a communication plan early on in the process
It doesn't have to be something complicated but it should clearly state who communicates which information to whom and when.
Knowledge transfer
5. Update the readme file with relevant information
Make sure the README file follows the company's template and that you can easily find the API documentation, dashboard, and logs. Every day-to-day activity should be defined in the README: running the service locally, running the service in staging, testing the service, deploying the service, troubleshooting the service (how do I clear caches?)…
6. Organize knowledge sharing sessions
Use pair-programming, event storming sessions, and stand-ups to spread knowledge. Try to blend some ceremonies as soon as possible to familiarize the new owners.
For pair-programming sessions, make sure you observe different phases:
- Shadowing (~2 weeks): Future previous owner codes, future new owner follows.
- Reverse-Shadowing (~2 weeks): New owner codes, previous owner follows.
- Backup (~2 weeks): The new owner sometimes calls the previous owner for help.
By the end of this period, the previous owner should not be involved anymore and should forward questions to the new owners.
Deliverables
7. Transfer codebase ownership
The owner of the project should be clear as day. Update the Owner information. If needed, move the service, its CI pipeline, and its secrets to the new namespace.
8. Provide documentation and feature requirements
Make sure the documentation is transferred to the new owner, and under the correct namespace in Confluence.
Jira tickets should be transferred as well.
Don’t forget Google documents! Those are easily missed.
Communication
9. Sign-off Project Handover Checklist
The purpose of the sign-off project handover checklist is to ensure both parties are happy with the handover process and are ready to close it.
10. Send a handover email
At the end of the process, the team lead or project manager should send a final handover email to the company with all the relevant links and a short description of how information is organized.
Conclusion
The handover process is integral to the life cycle of a project. The quality of that handover can make or break a project, and team spirit. Nobody wants to inherit from an application without clues. A successful handover will help your team start on solid foundations, and avoid wasting time digging around.
As a parting gift, here's the word cloud that my chapter came up with during the introduction meeting. As you can see, documentation, dependencies, and architecture are a major concerns.
