I seem to have a pattern of starting my posts with “I am fortunate”; so, I am fortunate to have worked with lots of great clients over the years building many different and interesting products for them. I love getting to learn about so many different things in the world. For example, I know more about how tennis works and is played/scored than any person on earth who has never played.
Not only is it super cool to get to learn and understand so many different things, but I also become personally invested in the success of the clients I work with and the products they build. I want to see them succeed and prosper so even when it is time to send them off on their own, I try to do so in such a way that they can continue to be successful.
One way that I do that is to make sure that the handoff to a new team (whether internal or other) is smooth and stress-free for everyone.
Like everything in the world, handoffs can be great or they can fail miserably. So let’s go over some things that you can do to make sure yours doesn’t end in tears.
There are three parts to a solid handoff.
- Developer handoff
- Business handoff
- Support
Developer handoff
Code review/domain knowledge transfer
It is very important to spend time walking through the code base with the new developers to help them understand how it is written. Cover things like style and approach. Not all developers build the same way and it is helpful for new developers to understand why certain design decisions were made. This is a great time to cover domain knowledge as well. Pairing is one of the best ways to do this. Additionally, the new team can start working on enhancements and bug fixes while the old team is still around. There is no better way to figure out gaps in knowledge than doing actual work so the more working/coding time together the better.
Schedule Task and Backups
Make sure to cover any scheduled tasks that run and any potential problems that may arise. Additionally, let the new developers know how they will know there is a problem. Start having the new developers do the deployments and covering customer support/tickets before the old team rolls off. Again, this is the best possible way to get everyone on the same page.
README
Having a great readme is important regardless of whether you are doing a handoff or not. Marty covered READMEs in this blog post so I’ll just highlight the types of things that should be in the README here:
- An overview of the project
- Installation instructions
- Information on how to get seed data and how to use the seed data
- Information about the environment
- How to deploy (the process for moving codebase through test/acceptance as well as production).
3rd Party Accounts and Services
Review all 3rd party accounts and services with the new developer. Go over what each one is used for and where in the code base the corresponding code is. Additionally, it is good to bring up any missing functionality or items that need to be done in the future as well as any restrictions on these accounts. An example of this may be that you use Segment for tracking purposes and are on a plan that will hit its max at 1000 Monthly Tracked Users.
The Checklist!
You should create a checklist template that has everything you would want to cover in a handoff with any client. Then add any specific items for the specific client you are transitioning.
Things to include on the checklist are:
- All services or 3rd party integrations the application uses. I also include what plans you are subscribed to.
- Transfer all repos and accounts that require a transfer
- Logins/passwords to any services your team uses for development, product management, deployment, and monitoring. Some examples are:
- Deployments: Heroku, AWS
- Project Management: Pivotaltracker, Trello, Asana, Jiri etc
- User Tracking: Google Analytics, Segment,
- Monitoring systems: New Relic, Honeybadger etc.
Business Handoff
It is important to go over the product roadmap and the current state of things. This usually means bringing up your product and project management tools. It is important to bring up any items which may change as a result of the team change. Examples of this may be estimates around large features. Any time there is a team change it is important to revisit expectations, deadlines, and any work in progress.
Typically I work closely with the product owner from the beginning of our engagement so there shouldn’t be much that needs a hand off. If I am doing anything on my own then I would plan a hand off of those components. Examples of that could be collecting and reporting on metrics/KPIs, customer development and user feedback documents, or managing the product roadmap.
Be sure to cover all 3rd party services and integrations so the business owner knows why we’re using each service and that they are responsible for continuing to pay for them. You should also make sure to cover licenses and any upgrade information. A good example is SSL certs.
Support
Inevitably, even with an awesome handoff process, there are bound to be things we missed or questions we didn’t know to ask during code review. For that reason a period of support is necessary. I generally go with a few days time allotted to pair. Or I do a PR review followed by another week to two weeks of support through Slack or by phone so the handoff goes smoothly..
Conclusion
I hope this helps you the next time you do a project handoff and that all your clients continue to experience great success because you CARE.
- Share:
-
-
-
