Putting the handover at the start-up

Everything that has a beginning has an end ¹, and projects usually falls under this assumption. No matter of the type of project (e.g. software products, consultancies) when the end is approaching the handover begins.

The handover is the act of giving responsibility for something to another person, or the period during which this happens ². In plain words this can be translated to giving the client a software product you wrote or a web-application or reports and documents at the end of a consultancy. The seller giving you the keys of your shiny new car is an example of handover. When and how you get the keys is part of handover process, could it be in a showroom or in the manufacturer facility.

Although the most known trigger of handovers is the end of a contract the process can also start in the case a team member is replaced or a new team member takes over some responsibility.

From the perspective of the Knowledge Management Framework the handover process involves all the 4 legs:

• People: who is the target and who will be involved. There is a difference if you are handing-over to a technical or non-technical person.
• Processes: how the handover happens. Will it be a training session at the end of the project? Will be done in steps during the course of the project via written documentation?
• Technologies: you need to select the way the handover happens. Will it be a zip file? Is version control considered? Will the client have access to internal tools or should establish some tools to receive the artifacts?
• Governance: how the handover is framed within the project. Was it planned already? Was it planned for a different person? Is there enough time to do it? Should support be provided after the project ends?

At its heart the handover process is a balance between push and pull. Push as the creator of an artifact (i.e. a document, a software, ...) wants to share knowledge with an end-user (e.g. the client, a new team member). Pull as the end-user is interested in gaining knowledge.

Before planning an handover:

1. define who is the end-user. Some guiding questions can be: is it a technical person? Do they have the background to understand everything?
2. understand if an handover is necessary. Assuming that you are creating a product the main question is do they want to manage the maintenance and evolution of that product on their own?
3. define how the handover will be performed. Every sprint of the project (assuming an Agile process is in-place) or at its end?
4. select what tools to use. Do you need to use written documentation, with trainings or videos?

When planning the handover

1. be transparent on what will be shared, e.g. code using direct access to code repository or packaged artifacts like zip, Docker images
2. be transparent on how will be shared, e.g. the client needs to actions in preparation of the transfer
3. envision a support process that can last some days or plan training sessions
4. agree when the handover starts and the effort required from both parties

Defining the handover process since the beginning allows all the team to prepare for the challenges and to ensure the artifacts will be ready to shared in a short time.