Top tips for transitioning to a new IT service

Blog
Communication
Project planning
Training
ITIL
PRINCE2

Author Adam McCullough – ITSM expert

August 20, 2018 |

5 min read

Blog
Communication
Project planning
Training
ITIL
PRINCE2

Organizations are not generally well-prepared for IT service transition.

Either they outsource it because they’re not good at it, or they muddle through it. Recently, I’ve witnessed some transitions which have inspired me to revisit this topic.

Typically, service transition doesn’t necessarily have a dedicated team; the activity is just something added on to people’s day jobs. This leaves them to “put out fires” as normal while they’re trying to transition.

And while ITIL’s RACI Matrix should provide the framework for roles and responsibilities to be clearly allocated, it’s a fact of life that people leave, jobs change and people don’t know who does what and communication doesn’t happen.

Having a transition plan

One thing that became apparent on a recent project was the importance of having and maintaining a transition/project plan and ensuring it’s updated. You need to know where the milestones are and recognize when something slips.

It allows you to track service transition progress and let all stakeholders know about any anomalies while having a contingency plan in place. Having said all this, transition plans are difficult to maintain properly and regularly.

In-reach and outreach communication

In ITIL the Business Relationship Manager’s primary function is liaison between your organization and the customer. However, that person will often take on the role of doing in-reach communication also. That is about making sure that – internally – people know what’s going on. After that, outreach is aimed at the user community: how does the transition affect them, what will change, what training will they need?

Having a RACI matrix removes any ambiguity, although there is still the risk that the communication part gets missed. For example, people might assume that – following a meeting among organizational leaders – that information is flowing down to everyone else in the business. Too often, this doesn’t happen.

So, you need to make it crystal clear who will do in-reach and outreach communication and how. Ideally, there’s a single person conveying messages about what’s happening; that way, at least people know and can seek further information.

Training makes the difference

The amount of training people need will depend on the level of change/transition.

Essentially you want it be seamless. Therefore, offering “differences” training is effective to ensure that people are prepared sufficiently so the transition won’t affect business operations. For example, the transition shouldn’t affect the finance department when running payroll. So, you need to understand which organizations will be impacted and what issues will become problematic.

Project planning – taking ownership

In essence, you need to have a project plan and maintain it.

It’s very difficult to track what’s happening day to day when there are a lot of moving parts in a project. It’s about making sure you know what milestones there are and what happens if they slip and affect something else in a domino-like effect. ITIL gives you leeway about ownership of the project plan, but there should be someone who owns it.

The problem with giving ownership to a service operations manager – who is responsible for day-to-day operations – is that things can slip. Therefore, it’s better to have a dedicated project manager who has transition as their sole focus, while consulting other managers along the way.

Having training and certification in complementary best practice approaches – either PRINCE2^® or PMP^® – along with someone who understands how IT as a service runs would cover both demands.

Contingency planning

Part of developing a transition plan should include contingency: what happens if this new service breaks, or it breaks something else?

For anything that breaks along the way or there’s no single point of failure, you have to be able to roll that back.

Equally, in lots of projects there are unforeseen circumstances that come up and you need to “bake” that into your overall plans. This is difficult but you can mitigate as much as possible when doing your due diligence on a project. Above all, make sure that when you unearth these things everyone knows about it and work closely with service owners to identify what the options are.

Following this process for each transition means you will get better at forecasting the unknowns.

ITIL’s Continual Service Improvement approach instils the concept of “how can we do this better?”. That plays a huge role in transition to ensure you don’t repeat the same mistakes and have everything documented. What you want to avoid is completing the best transition ever and the main person gets another job or wins the lotto. Did someone write down what you did before he/she left?

I’d like to believe IT organizations are improving service transition and making it more frictionless. This is because of a shift towards gradual upgrades over time and avoiding major changes from one version to the next.

From a people, process and technology standpoint, the technology is now helping humans more with the challenge of service transition.