Introduction

It’s definitely no easy feat, especially when there may be a lot of specialists and organisations involved. You have to be able to reconcile often conflicting interests, ideas and views, and manage to deal with different personalities, all the while staying calm and rational.

There are a few parts of the process, and each one can be broken down into smaller chunks. We’ve been through all of them and in this article we want to share an ultimate checklist of all the best practices, helpful hints and universal lessons that we’ve learnt.

This article is based on our own real experience with transitioning an IT project – a situation where we had to pass a project to another provider. In order to give you an idea concerning the scale of the project, we present you with some of the most important numbers.

Throughout the duration of the entire project, our company was responsible for 5 different IT systems.

Below, you’ll see how we managed to deal with each part of the process – from preparation, through the actual transition, to the completion of the project. We learnt a lot along the way, picked up some excellent moves, and also made a few mistakes — from which we were able to draw some valuable conclusions. May our invaluable experience help you with your own IT project transition as well.

First things first: know the universal truths

Whether you’re about to start managing a project or hand it over to another entity, there are some universal rules you should bear in mind if you want to avoid chaos.

Problems should be named and the right people notified

The entire cooperation needs to be based on a foundation of openness and loyalty. There’s no wiggle room for downplaying any emerging issues either, as this may undermine the project.

Governance Meetings are necessary

Upper-level meetings that structure the work on every level will help resolve the problems that are voiced.

Communication is the key

The bigger the teams, the harder it is to maintain effective communication. Therefore, it may be a good idea to identify a person who will not only be responsible for communication within and between teams, but also for synchronising their work.

Documentation can be lifesaving

Always remember to keep detailed and up-to-date documentation, in case any of your experts have to leave the team. Their knowledge about the technical aspects of the project should be explicitly written down on paper, as they may not be able to pass on all the necessary information in person.

Some of the points above may sound cliché, but our experience shows that they are very often not implemented at all, so their importance is worth underlining. And now, after covering all the basics, we are ready to move forward with the transition.

Phase 1: Preparation

Step 1: Choosing a new IT service provider

If your company is the one handing over the project, it should remain involved during the entire process of selecting the new IT services provider, preferably from the point of preparing the RFP to making the final decision.

Your role at this stage is complementary, yet significant, as you may have to help your client ask the right questions and provide potential candidates with all the necessary information about the project. You could also be asked to support the process of analysing their offers, selecting the most promising ones and identifying the best overall option.

Step 2: Kick-off

The kick-off step is basically a meeting (or a series of meetings) during which both companies – the ones handing over and taking over the project – can establish the processes and plan future actions. What you need to remember is that the transition is just a project (consisting of numerous tasks) and should be treated as such, therefore it needs a proper plan.

From our perspective, these points are particularly relevant:

• drafting a high-level transition plan:
  • preparing a schedule,
  • establishing and specifying certain roles and their scopes of responsibility,
  • defining project risks along with adequate mitigation plans,
  • determining staggered milestones (in order to make sure that everything goes as planned);
• checking the availability of key people involved (don’t forget to include e.g. vacations or maternity leave),
• preparing important documents’ templates, like a License and Software Register, Application Access Tracker or Environments Tracker,
• determining methods (e.g. stand-up meetings, weekly calls) and channels of communication (e.g. Skype, Slack),
• figuring out the most appropriate frequency and methods of reporting progress.

Step 3: Establishing roles

It is necessary to establish clear roles early on within each of the following three organisations: the company handing over the project, the company taking over the project, and the client. Before you begin the process, it’s a good idea to create a special Transition Team that will be solely and exclusively responsible for transferring knowledge to the new service provider. When it’s done you should establish some more specific roles, like the ones mentioned below. When establishing the Transition Team, you should consider individual experience, knowledge, both hard skills and soft skills as well as personal preferences (whether someone wants to be on the team).

Main roles include:

The steering group

Establish a joint body to make final decisions, as well as to verify and approve the progress of the transition and set goals.

Transition lead

Generally speaking, this is the person who will be responsible for overseeing the transition. From our experience, there should be three Transition Leads – one for each company – who will be responsible for all actions within their individual organisations.

One of the leads should be given priority, so he or she can fully coordinate and control the work among all of the participating companies. In our case – this was a manager from the transferee company.

Service management lead

This is a role responsible for defining processes and organising workflows related to the second and third-line support that have to be structured from scratch.

Knowledge transfer lead

This is one of the most important roles in the transition — if not the most important.

Knowledge Transition Leads are responsible for planning and coordinating Knowledge Transfer Sessions and choosing the right people to lead each one. They also have to make sure that session owners are always well-prepared. These experts should not only have broad technical knowledge about the project but also be very familiar with the team members involved and possess excellent communication and organisational skills.

Additional significant roles include:

Transition lead developer

This is the person who will be responsible for the vast majority of substantive knowledge transfer, and who will answer to all the technical questions.

DevOps engineer

This role is crucial in terms of coordinating the migration of tools and servers to the new service provider.

Members of the development team

Individual developers with the broadest domain and technical knowledge should always be involved in the transition process and take part in all meetings and calls. They should be assigned to each thematic session according to their areas of expertise by the Knowledge Transfer Lead.

Phase 2: Transition

Step 1: Preparing a solid ramp down plan and project documentation

There’s a big challenge that every company handing over a project has to face. Namely, what to do with a team (or teams) of engaged specialists when the transition is over? The larger the team, the more difficult the problem. If you are left with a relatively big team after the transition, you may find it difficult to find other projects for them within your organisation. That’s why it’s a smart move to prepare a ramp down plan in advance and gradually relieve people from the project.

Another significant challenge is collecting and unifying all the documentation, as everything may be scattered in different locations. The documentation doesn’t need to be extremely detailed, but it certainly has to be specific enough to fall back on when some of the original experts are no longer available for the project.

Step 2: Knowledge transfer

Knowledge should be transferred to other company during Knowledge Transfer that are run through the selected communication channels (like Skype for Business). In our case, we had to go through about 70 sessions in a span of 1,5 months. This means that we had 1 to 3 sessions per day.

Before we could start the Knowledge Transfer Sessions, everything had to be planned and structured in advance. When it came to the people involved in the process – virtually every member of our Transition Team had to run at least one session, so all of them had to be highly committed.

Step 3: Job shadowing + reverse job shadowing

Job shadowing is another way to learn and receive knowledge during on-the-job training sessions. This way, teams from the new IT services provider can become familiar with how everything works in practice. The ideal scenario for a job shadowing session involves having specialists from the new provider work together with specialists from the initial provider to solve daily development problems, through active participation in the development process.

In our case, job shadowing took place within our company. After that, there was time for reverse shadowing sessions, which took place in the transferee company, with the participation of a few of our leading experts.

Bonus: Work organisation & technical problems

Before we move onto the last phase of the transition process, it may be interesting to see how work organisation can be structured and what additional problems you may want to consider in advance.

Work organisation

We had several types of meetings that were held at equal intervals:

• Daily Knowledge Transfer Sessions were always followed by the Transition Daily Status – which was a sort of stand-up meeting summarising what had been done on a given day and what was to be done during the next day. It was also the time when all problems and obstacles were reported to the designated person.
• Weekly Transition Lead Meetings – for the higher management level. These weekly meetings were necessary for the Transition Leads to stay on top of the process so that they could plan the next steps.
• Bi-weekly Governance Meetings – were held on the highest level, regarding, among others, contracts, critical problems, delays, along with analysing reports and emerging risks.

Active development

Even if you plan a code freeze, this may be quickly overturned by the client’s needs and project requirements. Instead, you may be forced to run active (yet significantly slowed down) development with a gradually shrinking team.

Pros:

• It’s easier to keep the team motivated when there are still development goals to achieve.
• A transferee company has the chance to observe active development and practice running some code releases to the production environment.

Cons:

• In an unstable environment, there’s a risk that the code will also be unstable, or not finished on time.
• Every milestone that is deployed has to be followed by two additional introductory sessions – business and technical – in order to:
  • let the transferee company know which of the client’s needs have been fulfilled,
  • do the code walkthrough for developers.

Data and environment migration

During the transition process, all scattered development and test environments have to be migrated to the client’s business space. From as far in advance as possible, these environments should be kept in the cloud or on the client’s servers. Any knowledge that is related to this problem should be wisely distributed among team members, since relying on just one person for information may increase the project risk.

Progress reports and tools

Reports are essential in terms of tracking progress and making sure that everything is moving according to the plan, especially when many people from different organisations are involved in the transition process. Reports should be simple, clear and brief. Plus, they should always be sent on the same day and in the same form.

No less important are the tools that you use. For example, we worked with Confluence to keep all the documentation nicely organised while providing official information, and Slack for quick and less formal updates. We also learnt that open Slack channels are better than private ones – so everyone can join the channel they want and the workflow is more transparent.

Phase 3: Completion

Step 1: Technical steps

When finishing an IT project, there are plenty of technical steps to think about:

• deleting or archiving all the project data,
• cutting off the team’s access to all the tools and servers that they had been using,
• requesting the removal of all your team members’ accounts on the client’s side,
• terminating the VPN connection between you and your client’s company
• making sure that all involved team members are moved to other projects,
• finalising all issues related to active development.

Step 2: Social steps

Last but not least: try to organise a farewell meeting for the entire team. It’s very important to end the collaboration on a positive note and thank everyone for all the effort that they put into the process.

Wrap-up

Apparently, handing over a project to another IT company requires weeks or months of combined effort, depending on the scale of the project. However, by putting the above-mentioned tips into practice, the process can be led in a much more manageable and smooth way than expected.

To sum up, we want to distinguish the 10 most essential factors of project transition success – that are significant for all organisations involved.

Top 10 factors of success in IT project transition

1. If you’re a potential new IT services provider trying to win a contract – make sure you emphasise your skills and professional experience. Be proactive in the presale process and show that you care about more than just the relationship with your future client, but also about your relationship with the company handing over the project, as they may have a final say in the matter.
2. If you’re the one handing over the project – create a gradual ramp down plan, keep your team motivated by organising their work in a thoughtful way and try to understand their needs and concerns.
3. Keep your team members informed and facilitate transparent communication.
4. Establish clear roles and determine the availability of key persons to prepare a solid transition plan.
5. Close the gap between the old and new teams by organising some after-hours activities. Grab a drink together, have some fun, and create a pleasant atmosphere that keeps the door open for future cooperation.
6. Prepare a plan for the Knowledge Transfer Sessions and keep it up to date. Create a knowledge transfer team with broad competencies and experience.
7. Maintain solid documentation.
8. Report on progress during daily stand-up meetings. Introduce Playback Sessions in order to make sure that the new provider has acquired all the knowledge presented during the Knowledge Transfer Sessions.
9. Don’t forget about the practical side of the project – plan job shadowing and reverse job shadowing sessions. Bear in mind that the transition is not only about the code but also the tools to be used.
10. Take the final steps to close out the project after consulting with all concerned departments. Finish the transition in a pleasant atmosphere.