December 3, 2018

How to sabotage an IT project handover?

Piotr Tuszyński

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.


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 a 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 an 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 an access to JIRA and GIT repository history from your team. And don’t mention if any deadlines related to the project are already committed.


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 letting 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 code base and its structure, and assure the app will perform flawlessly on the vast majority of the devices out there. A security audit of 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 at 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 clients values and mission, business goals, tactics and philosophies.

And I’m reminding you we don’t want this kind of benefits, as the handover is supposed to be a terrible experience.


Ok, now I’m not going to fool around anymore. Let’s talk serious — 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 preparations plan is crucial here.

Here’s a downloadable list of all things that need to be done in a way to successful project — I hope it helps!

Piotr Tuszyński is a CTO at inFullMobile, an international digital product design and development studio based in Warsaw, Poland.

Fell free to contact us:

Medium · Twitter · Dribbble · Stack Overflow · LinkedIn · Facebook · GitHub

How to sabotage an IT project handover? was originally published in inFullMobile Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Written by
Piotr Tuszyński

You may also like

Like what you read?
Get monthly business and technology insights straight to your inbox.
Location: Wilcza 46, 00-679 Warsaw
About us
.intent (formerly inFullMobile) is an international digital product design & development studio delivering software at the intersection of digital and physical.
.intent™ All rights reserved.
Terms and Privacy