An IT project handover seems simple — it’s when one or more components of a project transfer from one team to the next. Of course, if that’s all you think your team should do when taking over a project, you guys are likely to run into some ugly issues along the way. A handover can either make or break the success of the product — if you want to f*ck it up, make sure to follow all of our tips to kill it, you bad, bad person.
Preparations
Not always the company that took care of the project you’re taking over will hand you all of the information without any problems. First of all, make sure everything listed in the following process will occur while you’re planning a handover:
Under any circumstances don’t create a plan agreed between the project teams, production support, and operations in both companies.
Don’t set a specific date for a handover — it will only help to succeed and we don’t want to succeed, right?
Make sure all of the handover criteria won’t meet the handover date. The less you know, the easier the sabotage will be.
All of the important people have to sign off their acceptance without the knowledge that things are not planned as they’re supposed to.
The beginning of an end starts now. Are you excited?
F*cking up a handover — a step by step guide
Business/general introduction to the product’s idea
Who needs any introduction? Just go with the flow. Don’t ask your client or predecessor to share any knowledge, especially anything about:
company’s mission and vision
project’s goals and roadmap
business model and strategy
unique product value
strategic knowledge of their users (such as User Personas, their needs and pain points)
core features
ways of execution
Forget about The North Star Metric too!
Project status
Another thing that should be done to sabotage a handover is completely ignoring the status of your soon-to-be-project. Make sure the predecessor won’t hand you information on a work done before, at what stage of dev roadmap is the project now, what work remains on code that hasn’t been deployed, the upcoming scope of work.
Do everything to hide access to JIRA and GIT repository history from your team. And don’t mention if any deadlines related to the project are already committed.
Challenges
Time for YOLO/Carpe Diem rule to come in. If you’ll summarize the challenges your predecessor encountered so far and think about the obstacles that can stand in the way of transition and further development, the team will be prepared to a handover too good and there’s a risk that it will run smoothly. And we don’t want it, don’t we?
Operational fit/workflow
Don’t you dare to let your predecessor to hand you any tools, workflow specifics, or management method that has been used previously — it would make all of the planning easier. When someone asks about the roles and responsibilities of the team-to-be, avoid answering, there’s absolutely no need to talk about this. Also, make sure to sabotage answering a few key questions by the previous team. Those questions are:
What kind of management method should be applied (e.g. Scrum, Scrumban)? If you agree on Scrum, how long will the Sprint last? What days should Scrum ceremonies take place on and who should be involved in them?
What are the specific responsibilities of particular team members? Have the proper introduction has been made?
What tools will be used to communicate (e.g. Slack, Hangouts)? How often audio/video meetings should be organized? What times of day does your team agree on being available?
What tools will be used for task management, time tracking, etc. ? How will the workflow look like? Are there any repository branching models to be followed? ?
Reviews, tests, reviews, tests
Knowledge & material transfer — access to the latest version of all component’s codebase is crucial. So as documentation produced throughout the process and full change history of the code repositories, git history, access to previous ticket tracker (like Jira), wiki, API doc, codebase doc, etc. Running a few Q&A sessions with the previous team or organizing a handover period during which their team is available for questions could be very helpful, so don’t do this under any circumstances.
In-depth code review — once you receive all of the items mentioned in step 1, there will be a need for performing a fully-fledged code review that will go deep down into all application layers surface potential security vulnerabilities, issues with the codebase and its structure, and assure the app will perform flawlessly on the vast majority of the devices out there. A security audit of the server is a must too. If you really want the handover to be a tragic experience for your company, make sure someone incompetent will do all of this — there is a chance something will be missed and no one will know what. You’re such an evil genius thanks to us!
QA tests — in a perfect world QA engineers should be involved in the early stages of every project. Their responsibilities are: reviewing requirements, preparing acceptance criteria for each task, creating functional spec documents, and finally for project testing — both automated and exploratory. Try to convince your team you don’t need their help and failure of this handover will get closer.
Infrastructure setup review and load testing — doing a proper review of the current network infrastructure as well as the server setup will allow your team to assess the scalability potential of the project. The same case is an infra architecture validation to make sure the project is ready to te scale it’s intended for. Do you really want this to happen?
Project kickoff meeting
A face-to-face meeting will greatly benefit all team members. Attaching a face to an email or Slack avatar is extremely vital, especially in long-term vision projects. Kicking the work off in person allows everyone to get a feel of the dynamics and helps your team to make sure you guys/gals are aligned with the client's values and mission, business goals, tactics, and philosophies.
And I’m reminding you we don’t want this kind of benefit, as the handover is supposed to be a terrible experience.
Summary
Ok, now I’m not going to fool around anymore. Let’s talk seriously — when a handover is done correctly, the project should continue to run smoothly. The transition should be as smooth as if it never happened. But if you don’t take it seriously, you’ll end up with communication issues, missed deadlines, and an angry client. Not only will this add stress to your team, but it can also ruin your valuable business relationships. Remember a successful project handover will drastically reduce questions from your team and clients later on, so a smart preparation plan is crucial here.
Peter Tuszynski
CTO
