“Once a new technology rolls over you, if you’re not part of the steamroller, you’re part of the road.” – Stewart Brand

If you’re an IT management professional, these are the glory days, aren’t they? You have at your disposal an ever-growing throng of product developers working tirelessly to meet all of your needs and take the “hard” out of your hard day’s work. And if you’re managing projects, you’re spoiled by a vast array of choices in the form of shiny new software tools to replace your struggling legacy system.

All of these platforms offer a smooth onboarding journey while promising meteoric project success and a bottom line so healthy your CEO will make you the company star. And all you have to do in order to move from the old way to the new-and-improved way is to order those licenses, outlay some cash and then sit back and watch the magic happen.

Except it doesn’t work that way.

A sound transition process matters

The successful transition to a new software tool isn’t dependent on the provider, nor some manifestation of technical black magic. It’s dependent on you. Yes, you. The thing is, you’re the bridge between the old and the new. You’re the arbiter that has to own the transition and shepherd your business through the change process. That evolution doesn’t just mean learning some new buttons to press; it means making the new tool part of the culture and shifting people’s thinking.

Your new tool must align with and, better yet, improve your existing workflows and processes. If you get it wrong, it won’t stick. And you may find yourself thrown under the bus (figuratively or literally) for coming up with the idea of changing PM tools in the first place.

It doesn’t have to hurt

Transition doesn’t have to be a painful process, and the fear of that pain shouldn’t deter you from making a necessary change instead of sticking with the devil you know. It’s all about managing that change effectively. Here are the key points to bear in mind to ensure you move away from the old way of managing projects while swiftly reaping the benefits of the new.

Know what you want from the get-go

The transition process starts at the consideration stage. Before you even start browsing around for a new tool, you need to be clear what problems you need it to address and what benefits you expect it to deliver. List them all, and if you can, attach a dollar value to the benefits. This way you have something to measure against the cost of implementation and the ongoing use of the new tool. If you’re not clear on what you want your tool to deliver, how will you know whether it delivers or not? Bottom line: Know what you want, have a list, attribute costs and weigh the differences. Setting your goals has long-lasting benefits.

Manage the transition like a project

Changing or adding new software should be managed like a project. It sounds so obvious but the major cause of failed change programs is lack of planning—so plan it. Transitioning to a new tool will take up your resources in the shape of people, time (including yours), money and possibly equipment. If you treat change management as an activity you just slot in around your other tasks when time allows, then it will surely falter.

Timing is everything

Think about the timing as well. Teams that are sweating out a deadline will give you no love for swapping out their toolset in the eleventh hour. And yet, it’s easy to think there’s never an ideal time. Chances are you’re introducing the new tool to help you manage a workload you can’t find the edges of, but there will still be better times than others to make the change. Be sure to plan in time for testing and training. This may seem costly when you pitch it to management but how costly would a failed implementation or sticking with your inefficient way be?

Choose your champions

If the transition process doesn’t have owners it will surely fail. Also needed is sponsorship at senior management level because each department that will be impacted by the transition needs an evangelist for the new tool. If you don’t actually know which departments those are, you need to find out and get them onside. And yes you’re the ultimate owner and bless you for your optimism but you can’t do it alone, so get the right team working with you.

Prepare the ground

Other than skipping the planning stage, the worst thing you can do when introducing a change of any sort is to just throw it out to an unsuspecting crowd and expect the team to take to it favorably. Even the very best stand-up comedians use a warm-up guy. You might be introducing something that will transform the business and everyone’s working day immeasurably for the better, but if you put a new tool out there with no warning and no pre-education, don’t expect a whole lot of uptake.

Transition is change—and people don’t like it, especially when it comes as a surprise. Talk to your organization and tell them the whys. Explain the key benefits that using this new tool will have on the business, and how each person plays an important role in motivating the other champions to spread the same message. Try having a formal kick-off meeting to introduce your new platform; show the team all the ways their new tool will make everyone’s life at work better, let alone the business. It’s also important to document business rules on how the team will use the tool and go through them with everyone involved.

Transferring data

Chances are you’ve got a ton of current and historical data in your legacy system. This brings up questions: Will all that data port across to the new tool easily? If it won’t map directly, will it require a lot of manual wrangling to get it in sync? Does all that data need porting across or can existing projects live out their days in the old system while new projects take life in the new one? This last approach might mean running both tools simultaneously for a time which might add to the reporting workload; but whichever way you go, just make sure you take a decent chunk of time to think about the data and what does and doesn’t need transferring between tools.

This is actually a great opportunity for some spring cleaning and a review of what data is important to you moving forward. Just because you had 200 activity codes in the old system doesn’t necessarily mean you need them all in the new one. Less is more – so keep it simple where you can! But before you do any revamping/tweaking/transferring make sure you take a backup or snapshot from the old system that you can refer back to if needed. You may not be able to maintain a full failover solution due to technical constraints but where you can, make sure you can still get at the old data in some form.

Adopt in phases

It might be tempting to populate the new tool with all your live projects and get everyone churning and burning as soon as possible. This might be okay if every user is thoroughly trained in the tool, and all the teething problems have already been ironed out during a test phase. But if not, be a little less gung-ho or the wheels might quickly fall off.

Start with one or two non-critical projects or admin tasks that a selected, product-educated team can find their feet with before going full-blown with your entire project workload across the whole organization. Even if the new tool has the most intuitive interface, new users will take some time to get used to the new environment and unlearn the old one. Chances are there will also be some impact on other work processes that will require addressing before going global.

Pick a supplier who will join your team

I’m sure that every product representative you meet during the pre-sale process will be only too keen to answer your questions and give you all the guidance you need right up to the point that you decide to give them your money.

But what then?

Will your supplier still be there beside you when you put on your armor and gallop off to the transition wars? If not, and this is important to you, then find a supplier who will. Sure there might be a smart-looking online help manual and some automated help desk thing you can use when all else fails, but having accessible (human!) expertise to help you through the transition increases success.

You might have to choose a higher cost package to get that level of support, but if that seems too pricey, take a moment to work out the price of a failed transition. Chances are, the support will suddenly seem like good value by comparison. In short, don’t skimp – it might well turn out to be a false economy.

Need to gain executive buy-in for your chosen project management tool? Read our in-depth guide to building a compelling business case for a new tool.

Keep rolling

A new tool rollout never ends – there will be (or should be!) updates and new functionality which your organization needs a heads-up on before they get hands-on. Consider refresher training as needed, to keep adoption healthy. Even when all your team members have set up their accounts and logged on, don’t just dust off your hands and ride off into the sunset, your job’s just starting.