Three phase transition - do we really need it in IT projects?
Transition is the reality of IT. System and technologies are constantly upgraded or replaced and each such transition of systems involves some form of handover, amongst teams within an organization or across organizations. As examples, a vendor is brought in to support and keep lights on for a platform that is being phased out; or a consultant is brought in to transition into and supplement an area that the organization does not have internal skill and/or scale; or there is a strategic reason - transition to a partner for cost efficiency or predictability of service.
It is commonly believed that the success of the engagement depends on the effectiveness of the transition. While I would not disagree in principal with this statement, my doubts are with the process of transition and the measurement employed for determining the transition progress.
Here's what happens in a typical transition:
At the start detailed transition plans are created for documentation and knowledge sessions; followed by a period of incoming team being secondary and then an equal time being primary. These plans are actively tracked to and updated based on the progress made. However in almost all cases there are delays in the transition tasks and/or there are quality concerns raised by the incoming team. As a result the plans are modified and transition end date is moved out. The dates may move out more than once till finally the cost benefit analysis from management kicks in which determines that outgoing team is too expensive to retain and boom the transition is over.
Once the management takes that decision almost everyone accepts that date and gives a go-ahead. I have rarely seen a transition where the incoming team outright rejects the transition end date (especially if it has already moved a couple of times). Also somewhere close to this final transition end date the quantitative measurements of documents created, sessions conducted, knowledge level etc takes a back seat. The indicators of readiness at this stage are the more qualitative factors like management's comfort feel, team's confidence level, extent to which incoming team has settled in with the environment & stakeholders etc.
Two things of this typical approach struck me, one that the time period spent in transition is not being determined by the time it takes for transition to complete but by the cost dynamics clubbed with a qualitative feel factor. And second, however long or short this period might finally turn out to be, people can't really quantify what was achieved in it (there is no good way to do the quantitative measurements of transition effectiveness like the knowledge level of incoming team).Given these two, do we really need the three phase transition period in the first place?
Here's what I propose. Start the clock on transition period with the incoming team as the primary, which means that this team performs all the activities that they are being brought in for, right from day 1 after their logistical on-boarding has been completed. Now this does imply that the outgoing team needs to prepare some sort of documentation in advance of the transition start date. That's efficient too since you are prepared before the users (read as incoming team) come in and not once the users come in. I remember the days as an ERP consultant, we had these heads down periods for completing documentation of various phases, two weeks everyone heads down typing away!
Do away with the knowledge sessions; utilize the time instead for on-the job learning. And use the actual job indicators to determine the transition progress. For one it is based on robust data and moreover it automatically gets tracked. You brought in a team for support, well look into their productivity by area and average criticality of incidents resolved week after week and after 4 weeks you have a trend that tells you all you need to know.
With this approach not only do you have better quantifiable measures for the knowledge, towards the end of transition period, when qualitative factors kick in, you will see better results there too - The incoming team has had a longer time working with the various stakeholders and built work equations; the incoming team would have seen the actual work at hand and progressively built confidence; as management you would have seen the team in live action, which means less unknowns and more comfort feel.
Of course the proposed approach would work better for technology based work as opposed to business or operations work, more on the differences and reasons for that later.