When a project ends, some clients are not entirely sure what they should be asking from us. They know that the source code and documentation are owned by them but they're not entirely clear on the exact steps of the handover.
To make this process easier for everyone involved, we created a checklist to ensure an efficient project handover.
We started from the premise that other developers will work on that project in the future and we asked ourselves "What information would this new team need to be able to re-start the project independently from our initial work?"
This checklist was created with something we like to call "professional empathy". We imagined that we were the software development team being given an existing source code and thought about the type of information we would need to get started.
If you're in a hurry, download the checklist here and read it later.
Our Project Handover Checklist
1. Identify the parties involved in the handover
Start by deciding which people will be involved in the handover process. For us, that would be the team leader, the project manager and some (if not all) team members. Everyone should have a clear role in this process.
It's also important to establish who will be involved from the client’s side and what aspect of the project they are interested in. Which individual or group will receive the handover and is accountable for making sure they have all they need to continue the project after the handover is complete.
2. Define a clear deadline for the project handover
Establish a date by which the handover should be completed and communicate it to all involved parties.
Most probably, this will be heavily influenced by the collaboration contract.
3. 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.
4. Update the readme file with relevant information
A complete readme file should have:
- a project description
- the steps to setup the project
- information on how to run the project locally
- information on how to connect to API, other apps etc.
- information on how to deploy on production (or other environments)
- API documentation
- information on architecture and design
- app/code structure
- other relevant information that would make it easy for a new developer to take over the project without your support
5. Organize knowledge sharing sessions
We found that organizing a series of knowledge sharing sessions can be really useful. This creates a more engaging communication environment and allows for questions and clarifications on both sides.
6. Transfer codebase ownership
If the codebase is already owned by the client, meaning it's been pushed to their git repo on github, gitlab, bitbucket, etc., you can skip this step.
Otherwise, make sure they get access to it via git or send it as a zip archive.
7. Transfer accounts & credentials ownership
Send the complete list of 3rd party services and tools (e.g. AWS/server hosting, database, GooglePlay/AppStore, mailing service apps, SSL certificate files, etc.). Include links and credentials for login.
Ideally, these accounts were made by the client. If the accounts were made using company or personal email addresses, we recommend to provide access to the client's email address and make them the admin for all accounts.
8. Transfer app admin and demo accounts
Provide the app admin links and credentials for each environment.
If you used demo accounts with valuable content in the app, provide the credentials for those accounts and write a short description of what someone can find there after they log in. If you have sensitive personal data on those demo accounts, make sure you delete it before the handover.
9. Provide documentation and feature requirements
Make sure the client has access to your documentation.
We use Jira, Confluence and Google Drive to manage this. Clients are provided with credentials for the accounts which allow them to export the information they need.
Some clients set up their own accounts at the beginning of the project which makes the handover easier.
10. Send a handover email
At the end of the project, the team leader or project manager should send a final handover email with all the relevant links and a short description of how the information is organized.
If you have any other good case practices for a great handover, let us know in the comments section.
YOU MIGHT ALSO BE INTERESTED IN
Kicking off new projects
The ABC of starting a new software project, complete with best practices, how-tos, and other resources.