- March 23, 2023
Table of Contents
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.
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.
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.
Upper-level meetings that structure the work on every level will help resolve the problems that are voiced.
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.
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.
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.
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:
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:
Establish a joint body to make final decisions, as well as to verify and approve the progress of the transition and set goals.
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.
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.
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:
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.
This role is crucial in terms of coordinating the migration of tools and servers to the new service provider.
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.
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.
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.
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.
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.
We had several types of meetings that were held at equal intervals:
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.
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.
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.
When finishing an IT project, there are plenty of technical steps to think about:
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.
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.
