Implementing an ITSM Tool: Plan the Change Well
While this blog can stand alone, it’s also the third part in my three-part blog series related to IT service management (ITSM) tool selection and implementation. So, if you have time, please check out the first two parts: “Implementing an ITSM Tool: Start With the Why” and “Implementing an ITSM Tool: Understand Your Needs.”
Buying a new ITSM tool and implementing it in your organization is like dropping a substantial rock into a lake, the ripples go everywhere, and it will be some time before things are calm again. So, don’t be surprised at the reach of the consequences of choosing and implementing a new ITSM tool. And understand beforehand that you’ll have to change multiple aspects of the existing operational processes and procedures to deliver the benefits that you want and were promised by the tool supplier.
Don’t Forget the People
Implementing a new ITSM tool is a significant people (or organizational) change project. So, don’t cut corners. You must involve people from all affected areas.
Here, the time taken to involve them in planning should more than pay back benefits later. Especially as those affected but uninvolved in planning are not likely to be eager adopters, but they can also derail the project by appearing from stage left just prior to implementation.
Some of these people-related consequences of a new ITSM tool are that:
- The processes that the ITSM tool supports will change. Not (just) because the tool needs changes, but because you can now do things you couldn’t before. Be sure that you don’t just do them because you can though, make sure that they are things that will deliver business benefits.
- Your first and second line support staff might need new or different skill sets to operate not only the new ITSM tool but also the new processes and perhaps policies.
- You have the chance to really build up useful knowledge management capabilities, re-using your hard-earned incident resolutions. But this means changing culture to capture and share that knowledge now that you’ve got a viable way of doing so.
What this all means is that there’s a need to get your planning right, and again to take the time to involve everyone who might be affected by the implementation of the new ITSM tool.
Getting Started
A good first step here is to examine your current ITSM processes to ensure that they are lean and serviceable before trying to increase the level of automated support for them (via the new ITSM tool). This will allow you to improve your processes together with introducing the new software. Which gives you a single set of changes to sell to your people, not two – because trying to sell two sets of change in quick succession is a sure way to introduce change fatigue.
A big message is to “learn from what you already know.” ITSM tools are complex, sophisticated, and powerful. Their flexibility means that there are many options available, settings to choose, and decisions to be made in set up. And the failure to exploit these options, and to match them to your specific situation and requirements, will ultimately diminish the delivered benefits from the new ITSM tool.
Also available to you is a large quantity of data – on your people, your hardware and software, your customers/end users, and much more. This will need collating, coordinating, and verifying but it’s likely to give you a good start in populating the data for your new software.
Go “Big Bang” or Take a Gradual Approach?
As with any major technology roll-out there’s good sense in starting with a proof of concept in one part of your organization, perhaps collecting the data and logging tickets for one IT service in the new ITSM tool.
In terms of the tool flexibility and the wide range of options, there’s logic in using a pilot to either verify the chosen settings or allowing some update and modification to the ITSM tool before rolling it out across the whole organization. It can save you loads of time.
Measure Success
Back in the first blog of this blog series, I advised that your organization must start by knowing why it’s implementing a new ITSM tool. That knowledge should deliver you the critical success factors (CSFs) and indicators against which you can judge the success of your ITSM tool implementation project.
And while CSFs are important, it doesn’t mean there won’t be other good things coming out of the ITSM tool project. So don’t overlook secondary or unexpected benefits when measuring and communicating your success.
One thing that’s definitely vital in demonstrating success is to build monitoring into your processes, to establish the new and better performance levels. And remember that it’s the combined performance of your people, processes, and technology that matters. Ultimately, implementing the perfect ITSM tool without getting the processes right, and capturing the enthusiasm and commitment of your people, will not deliver the desired or promised benefits.
There’s therefore a need to put a mechanism in place for capturing changed performance in the things that matter to your organization. Examples include:
- Cost of the support teams
- Downtime of key IT services
- Number of outstanding tickets awaiting resolution
- Customer and user satisfaction
Keep Going
A successful completion of your project is going to feel great and will fully justify some celebration and perhaps even an end-of-project party (you can tell your boss I said so).
But it’s really only the beginning of an ITSM improvement program. All of the aforementioned improvement measures are targets to be improved on again over the coming months and years.
Keep in mind that the ITSM tool will likely also have more capabilities available than have been implemented. So, decide on what you need next by going back round the loop of “why,” “how,” and “when” for delivering more benefits to the business from the investment in your new ITSM tool.
That’s the third and final part of my blog series completed. What else would you advise people to do when implementing a new ITSM tool? Please let me know in the comments.
