When you leave a project you have to make sure that it is left in prepared hands.
It seems simple enough: just showcase the project and its goals. However, I am sure you ran into issues and possible headaches along the way that the next team will surely also run into.
A project hand-over when done wrong, deadlines may be missed (which hinders business relationships), you add stress to the team’s workload, and you will be pulled back to a project you left (maybe a long time ago). When done right, the receiving team should be able to run the project smoothly after you leave.
In this post you will find suggestions for organizing a project hand-over.
Since you are presenting a project with a coworker in mind, it is easier to ask yourself questions you would also have in their place. And then try to answer them as completely as possible without an overflow of details.
One way to do this is to plan it as a workshop, and divide it into four sessions:
- Introduction (30min session)
- Implementation (2h session)
- Operation & Deliverables (3h session)
- Q&A (2h session)
Tip: Create a calendar event for each session, invite everyone that is involved in the transition, and talk about it with other people too. They may be curious about it and want to learn something new.
Here I refer to a project hand-over with a strong software development component, but most questions are valid for any type of project. Below you will find suggestions of questions for each session/section you should answer during your hand-over.
1. Introduction
This is the first session and the quickest. The goal is to introduce the project and some key concepts begore going into detail in the next session.
Who are the stakeholders in the project? Here include everyone that is a part of the project: initial contributors, clients, project manager and the group who will receive the project.
What is the motivation for this project? What was the problem/challenge this project was proposed to solve? Having a clear view of the project’s value is important to keep everyone aligned with the same goals.
What is the solution? What is the solution based on? Introduce and explain technical concepts and how they are used. End with a black-box drive trough: present what are the inputs and the output (results) of the proposed solution.
How is the solution architected? Focus on a grey-box approach where you can give a high-level walkthrough of the main components and how they interact with each other. It is specially useful to include diagrams to demonstrate this perspective.
How has the project evolved so far? Showcase a timeline of the main accomplishments of the project: start date, deployment, deliverables, evaluation dates and metrics, etc.. This will come in handy when the group that takes in the project will eventually have to present to other stakeholders.
2. Implementation
Whereas in the introduction session we presented a high-level overview of the project’s architecture (from a black-box and grey-box perspective), now we should go into a technical detail.
How is the project implemented? Elaborate on how the components work and how they interact with each other (white-box perspective).
What is the solution’s development environment? Detail every technology used for the development of the solution: code languages, frameworks, technologies and applications, and their versions. If needed, do a walkthrough of the project’s file structure.
How was the solution deployed? Share servers’ characteristics (OS, HDD, RAM and CPU), where are the servers located (URLs), who have access to them; show credentials to use applications or technologies. Additionally talk about maintenance: how updates and migrations should take place, and what to look for afterwards.
What are the main limitations? Every solution has its own scope and limitations. During your working the project you have certainly encounter tasks that could be improved and issues that should be fixed, or even stakeholders that require more updates or have the most questions. Give a wide view of your personal experience with the project. Do not forget to propose solutions!
Where can I find documentation? Documentation. This is gold when taking on an ongoing project. Leave file paths for every documentation you can remember so people can come back to this hand-over presentation and quickly find what they are looking for (this will also drastically reduce questions).
3. Operation & Deliverables
This session usually will be the longest since we are laying out the specifics on how to operate and continue running the project (and where a lot of questions will arise).
What does a day look like operating this project? Enumerate day-to-day tasks you perform, meetings schedules, etc.
How does one operate the project? Give a live demo as a step-by-step tutorial of the stages it takes from the input to the output. Tip: record the session for people to come back to later on.
How are the reports structured? Prepare a document with a default structure of the report and give a walkthrough of each section.
When are the reports to be delivered? Present specific details about the reports/deliverables already handed over and the schedule for when the next ones are expected.
4. Q&A
During the previous sessions you surely were asked a few questions. Try to answer the ones you have quick replies or if it goes with the flow of the presentation. For big questions, take a note of them and use this time-slot for those answers. It also gives you time to better prepare demonstrations if needed.
Finally, leave enough time for final questions.
Also, it is a good practice to share your contact if any questions arise in the future.
At the end, you have to make sure you have transmitted everything one needs to know to understand how the project works and to feel confident on how to operate it.