A – Z of new ITSM tool implementation
Okay, I’m inspired by Joe the IT guy and stole this idea from him! What was that quote about great artists stealing?
ITSM tool implementations are like removing the engine from a speeding car and replacing it with a new one. I’ve been part of a few successful implementations and there’s a lot to learn when you have a sideline view. IT leaders implementing software have an inside out perspective and they’re usually blinded to certain things.
ITSM tool implementations are like removing the engine from a speeding car and replacing it with a new one
Here’s my A to Z of new ITSM tool implementation based on my experiences.
Acceptance of the new software
Change is hard, for anyone. I remember how all of us complained when Facebook changed their layout many years ago. Now, people only remember it to make such references in blogs.
The entire team must accept that the old software is going away. If you’ve communicated the business reason of moving to a new software ahead of time and ensure that all the major stakeholders are bought into the idea, then you can ease them into acceptance.
Create a value prop presentation/emailer that highlights the benefits of moving to the new platform. If there are any severe shortcomings, be sure to highlight that too!
ITSM software is usually the living and breathing space for many who work in IT. Changing software involves changing behaviour. You might hear someone on the team say “Ah, I’m so used to clicking this button on the top right but it’s not there anymore.”
When you pick a new software, it’s impossible to make it look like your existing system and sometimes there’s good reason for you NOT to do that. Identify the behaviour change that is needed by the IT team and also the customers. This will make sure you’ve spotted all the resistance points well in advance and prepared to tackle them when they’re raised.
Work with your ITSM tool vendor and schedule a product walk through with your team. This will help unearth the behaviour changes and can be discussed before they start using the system.
Many IT teams think ITSM tool implementation only impacts IT. But the truth is, it has organisation wide impact. Periodic communication about the new software is imperative for its success.
Create an internal communication plan with IT stakeholders like service desk manager, power users and vendor point of contact to communicate fine details like deadlines and backlog items. Also, create an external communication plan with business users on high level information like launch days, URL change etc.
I don’t mean exhaustive documentation that is spread across a million spreadsheets. Documenting key decisions like scope of implementation, requirements, and vendor commitment, will ensure that the implementation doesn’t derail. It will also be a very useful document for longish projects that need transition.
Don’t create multiple versions of the doc and send them across as attachments. Then, you’ll have to deal with the “No, my version says Monday” problem. Use a collaborative tool like Google Docs or Sheets and invite everyone to collaborate there.
Educate doesn’t always translate to training. In this context, it’s about educating business stakeholders and your own team on how to get most value out of the new software. IT organisations will never get a return on their investment unless the majority of your organisation is aware of the tool and use it regularly.
Create short educational videos targeted towards different user bases. They don’t have to be perfect videos, you can simply do a screen capture and use default video editing tools to create these short videos.
This one is for my ITSM tool vendor friends. It is very hard to build a product that fits everyone but every IT organisation is unique. Companies are going to ask for functionalities that you don’t have. Be flexible enough to consider them and build them out if they make sense to the wider audience. At Freshworks, we enable that through our SDK and app marketplace where anyone can build on top of Freshservice to achieve functionality.
When IT organisations ask for functionalities currently unavailable in your ITSM tool, resist the temptation to build it, but rather ask them what they’re trying to achieve. Maybe there’s a better way to do it with your tool and they’re simply unaware of the solution. I’ve tried this many times and I’ve always been thankful that I asked!
I love Go-Live days. It’s the equivalent of a book launch day or an album release day for the creator. It’s the day when you open up the new ITSM tool to your business and wait to see it getting adopted. A lot of things can go wrong on this day so it’s important to plan for it.
Identify points of failure and create a backup plan for those. Your backup plan should have a backup plan. Work with your tool vendor and make sure they’re available for support during the first few days of go-live as it’ll help you resolve issues and move faster.
Homo sapiens are the only constant, irrespective of what you do in your organisation. It’s very important to always optimize for their happiness. In this case, I’m being very specific to measure the happiness comparison between your old system and new system to really understand if there’s impact.
When you’ve decided to move to a new system, send out a survey organisation wide – “How happy are you with the current self-service portal?”, “How happy are you with the service you receive from the IT team?”. You might want to do an internal survey with your agents with questions like “How happy are you with the functionality of the current system?”
3 months into the new system, follow up with the same set of questions and you’ll be able to measure happiness increase (or decrease).
Inflow of tickets
When you pick your new ITSM tool, consider the channels it offers for your end users. Can your end users call you? Can they chat with you? Will they be able to raise tickets through internal communication tools like Slack or MS Teams? On top of this, you must also consider other non-human sources for tickets. For example, does it integrate with your monitoring tools?
List down all the current sources of tickets in your ITSM tool. You might also want to talk to your end users to understand on how they actually want to raise tickets but are unable to do so now. Also, consider potential candidates to automate ticket creation. Hardware or network failure tickets that your agents are creating manually is a good example. Once you consolidate this list, evaluate the options your new ITSM tool offers based on their channels and API capabilities.
Join hands with other departments
Your new ITSM tool might make life better for other teams in your company too. End users usually prefer one place to go to for all their needs. IT isn’t the only department that offers services. With this mind, work with other departments to see how they can benefit from your new tool. Modern ITSM software are built for non-IT use cases as well and that’s just going to make this whole process easier.
Talk to the other department heads and understand how they manage requests. HR teams, marketing teams and finance teams are ideal candidates as they always receive questions and requests from internal teams. Once you have that, work with your ITSM tool vendor to setup the required workflows into your new tool.
Knowledge base strategy
You should ideally have one even before you move tools, but if you don’t, now is a good place to start. A new tool gives you a clean slate to start strong. Pick a tool that has a really good knowledge base editor that can house visual content. Who is going to read that 12 page document anyway?
Create a knowledge base strategy document that talks about how you want to organise the content within. The document should answer all these questions – How are we going to create content? Who is going to update it? How are our agents going to consume internal content? How the folders will be structured? How will this tie into our AI/ML strategy?
‘Build and they will come’ won’t work. You must have a solid launch strategy if you hope to realize any value from your new ITSM tool. Launch strategy should include a communication plan to agents and end users, measuring adoption of the new tool, and getting everyone excited about what’s coming (Oh, this is important!)
Pick a launch date and work backwards on a launch plan. Make sure you list down all important activities leading up to the launch and assign deadlines to them. For example, your agent training should have been completed two weeks before the launch day.
Why is this important? Your new ITSM tool might have tons of useful features but what’s the point if no one’s using it? IT teams have to start thinking like product marketing teams and communicate the value of the new ITSM tool. You don’t have to do a lot, but simple posters around the office and a short but impactful video will be a great place to start.
Find a friend in your organisation’s marketing team and ask them for ideas. They’re also well equipped to help you with attractive images and videos.
Many internal tools are adopted by existing users but as the organisation grows rapidly, the adoption numbers decline as new employees join the company. When new people join the company, they often struggle to understand the tools in place because they wouldn’t have been a part of the initial training phase. A part of your launch strategy should also include ‘launching’ it to the people who will be joining your organisation in the future.
Your company’s on-boarding plan should include a spot for new users to be trained and informed about the ITSM tool. When new members join the IT team, make sure their training is as good as the one the old ones received.
You’re ready to say goodbye to your trusted old friend but you must plan for the goodbye also. There will be some valuable data in the old system and you’ll be tempted to migrate everything. Resist the temptation. While the data is definitely valuable, it still doesn’t justify carrying that weight over to your new ITSM tool. For example, migrating the ticket data would mean migrating ticket fields that are no longer relevant.
Identify all the data that you need and export it from the old system. Migrate only those relevant into the new system. Consider using the old and new system in parallel to ensure seamless transition.
Product, not project
Don’t treat your ITSM tool implementation like a project. Projects end, products don’t. If someone tells you that ITSM tool implementation is a one time activity, then someone’s lying. It’s merely a start. I agree that majority of the work happens just before the implementation but you must constantly be revisiting it to ensure you derive maximum value out of your new tool. The product mindset will ensure you are constantly focused on improving, incorporating feedback and maximising value.
Assign an internal product owner to ensure continuous improvement of your ITSM tool. This product owner should be responsible for constantly measuring impact, capturing feedback, and keeping the tool updated to meet current needs of the business.
Question the old ways
“But, that’s how we did it in the old system” is not an acceptable answer in a world where things evolve rapidly. Based on my experience of implementing ITSM tools, companies often want things exactly the same way as their old system. However, when you question to check if the old ways actually add business value, it’s often not the case. Implementing a new ITSM tool is a great way for IT teams to deliver new wine in new bottle.
Start on a clean slate by capturing business requirements for the new tool. It’s important to do this before you compare your old system and new system as the old ways may bias your requirement gathering process.
Relationship with ITSM tool vendor partner
Don’t pick a vendor, pick a partner. Vendors want to sell, partners want to see you succeed. I know this statement is hard to accept given that you’re reading this on an ITSM tool vendor’s blog, but we really are committed to being partners for our customers.
We’re happy about winning SDI’s Best Implementation of an ITSM software award twice in a row!
You need a vendor whois honest and happy to spend a lot of time with you during the initial stages of the implementation so that you are able to manage the tool without their help.
When you’re evaluating the tool, add a criterion to evaluate the vendor as well. Notice how they engage with you during the pre-sales and implementation stage. Ask them for reference customers to talk to and understand how they engage.
Ah, self-service. My favorite thing to talk about. It’s no secret that organisations struggle with self-service adoption and that’s majorly because there is no focused strategy for self-service success. If you’re changing your ITSM tool, it’s a great time to revisit your self-service strategy (if you had one) or put together a completely new one.
This can be a topic on its own. Check out the video here to learn how to implement IT self-service for your organisation.
The biggest mistake when it comes to tool selection is to just pick the one with most functionality. Organisations fail to understand that complex tools mean higher bills and ongoing maintenance costs. Your organisation might actually need such a tool but you won’t know for sure until you spend time understanding what’s best for your business.
Build out a “Tool Evaluation Criteria” document that scores all the tools you’re evaluating under fixed criteria like ease of use, ease of maintenance, time to value and total cost of ownership. Assigning numerical scores to each of these sections will also remove subjectivity. In the end, don’t purely go by the numbers but use them as an indicator.
Implementing a new tool can take a while. There’s a high probability that you get lost during the process and fail to actually meet business and end users needs. Writing user stories for each of these will help you keep the focus on the end user. For example, start by writing out an user story that says “As an agent, I want to quickly use knowledge base articles in my replies so that I save time in answering repeated questions”. You could also map out the key user stories before the tool selection to help you make better choices.
Before you start the implementation process, list down all the user stories as backlog and work against that backlog. You necessarily don’t need to do this in a project management software. Sticky notes on a wall would do.
Voice of the customer
Most ITSM tool implementations face backlash because the business users weren’t involved in the decision making process. There will be many internal users who either use the tool directly or derive value from it indirectly. It’s important to involve them in the process to avoid statements like “Well, you should’ve asked us before making the purchase!”
Involve a non-IT stakeholder in the tool selection process right from the beginning. They should be the voice of customer in your meetings and should bring the outside perspective that is very much required in any IT initiative.
Why are you changing your tool?
Many businesses consider changing their ITSM tool when the contract ends. I don’t think that’s a good enough reason. Changing tools is a costly activity that affects almost everyone in the IT team. Before making that decision, you have to have a strong business reason. Therefore, it’s important to really start with why you want to change your tool before you go on a tool hunt.
When you’ve captured all the business requirements, have a word with your current ITSM tool vendor to see if you can tweak the existing tool to meet your needs. Technology evolves at a rapid pace and maybe your tool vendor can do what you want them to do! All you have to do is ask.
X% increase or decrease
Okay, I just forced that in to say that you need to be measuring impact of the new ITSM tool. Now, this is different from the happiness measurement I talked about earlier. You’ll start to measure hard metrics like number of tickets reduced, cost savings and agent productivity. When you’re going in for a new tool, these metrics will help justify the investment and hopefully make you look good in front of the management.
Most of the ITSM tools ship with out-of-the-box reporting. An easy way to measure this would be identifying these key metrics before the implementation and continue to measure them month-on-month (or quarter-on-quarter) after the implementation.
You need to celebrate
Oh yes, implementing a new tool is not easy and that definitely deserves a celebration! I know what you’re thinking, it’s not easy to close down IT for a day and party, but I really didn’t mean that. Celebration is merely an acknowledgement of all the hard work that went in. It is also an opportunity for the rest of the organisation to know what you’ve been up to. Go out, celebrate, take a few selfies (or not) and share it with everyone!
Well, I’ll leave this one for you to decide. If nothing works, a big box of donuts always will 😉
I’m not putting this here because words starting with Z are extremely difficult to find, but you need to get some good sleep! I’ve worked with many IT teams to know that there is usually more than one sleepless night during key projects like ITSM tool implementation.
There you go! My A – Z of ITSM tool implementation. If you think I’ve missed anything or if you’d like to add a key point, please leave them in the comments!
Have a great implementation!
Designer: Nidhi Shah
Editor: Vignesh Jeyaraman
Subscribe for blog updates
Thank you for subscribing! Please check your e-mail to confirm.
OOPS! something went wrong try after sometime