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.
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.
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.
It doesn't have to be something complicated but it should clearly state who communicates which information to whom and when.
A complete readme file should have:
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.
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.
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.
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.
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.
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.
Download the printable checklist here.