When was the last time you heard – “We need to handover this project to the new team”?
Don’t get me wrong, we sometimes need to handover projects, knowledge, products, etc… it’s natural, new people join, colleagues leave, new teams formed, etc… the thing here is what we need to do in advance before we handover anything; let me use an example.
Imagine that you are a team member and your company, some time ago hired a contractor to build some projects for you, now, after some time and some changes in the company, you no longer will work with that contractor, what does it mean? time for a handover of everything they built and were responsible! good news is that they will still work with you for one month more.
Let me ask you something, how would you face this? I mean, would you think in minimum criteria? for example, if you are being handovered with a project that you don’t have a clue about the release process, or how to act on a live incident? is it feasible to think you are going to succeed?
Remember, if you are being set with a new responsibility, the organization you work with needs to make sure you can succeed with this new responsibility, otherwise it will be setting you for failure.
So, I would say that when it comes to a project handover, a piece of software handover, or something else, first think on the minimum set of criteria (things) you need to know in order to succeed with this new responsibility.
Some thoughts…
- What is Technology stack (versioning, etc), also including all the infrastructure information (tests env, prod env).
- How is the Release / Rollback processes (manual, semi-automatic, automatic, CICD)?.
- How many logging , alerting and monitoring is currently available?.
- Codebase complexity
- Available Documentation (how long it takes someone to be able to start working and be productive?)
- Product (who are the stakeholders? Who normally requests new work? or who normally report bugs?)
- Others…
