Build an ITSM Tool Implementation Plan

Plan ahead with a step-by-step approach to ensure the tool delivers business value.

EXECUTIVE BRIEF

Analyst perspective

Take control of the wheel or you might end up in a ditch.

An ITSM tool implementation is a complex project with direct impact on IT’s ability to support the business. With that level of risk, you need to take control early on.

Yes, your vendor will support or execute the technical implementation, but they depend on you to tell them how to configure ITSM parameters and workflows that affect user interface, the ability to manage incidents, and governance over assets and IT changes.

If you leave the configuration completely to the vendor, at best you might get the same setup as in your old tool (and not realize the benefits that leadership is expecting). At worst you end up with default values that don’t fit your process needs, i.e., confusion and not realizing expected benefits.

A successful implementation requires early planning from a wide range of resources including ITSM tool experts (supported by the vendor), process experts, and a project manager to methodically step through the hundreds of parameters you will need to define before implementation.

Frank Trovato
Research Director, Infrastructure and Operations
Info-Tech Research Group

Executive Summary

Info-Tech Insight

As with any large project, a key step is tackling it one bite at a time – but also understanding the size of the whole meal. This is where organizations often fail with ITSM implementations: not understanding upfront the volume of work required for a successful implementation.

Your Challenge

Organizations implementing a new ITSM tool often face these pitfalls:

• Selecting the Wrong Resources: You need ITSM technology and process experts, because this is not just a technology project but also a process improvement opportunity. You will need to configure ITSM parameters and workflows in the new tool – which directly affects processes. Take advantage of that opportunity to fix pain points. For example, if your existing ticket categories are not effective, implement a better categorization scheme rather than just configure the same old, ineffective scheme.
• Over-Reliance on the Vendor to Optimize Your Tool: Yes, the vendor will typically install and set up the tool but they will not fix your processes for you. On installation day, if you are not prepared with the categories, ticket templates, and so on that you wish to configure, your vendor will just go with the default or migrate your old parameters from your old ITSM tool.
• Not Preparing for Data Migration: Data migration is complex. You need to determine what data to migrate, if any, and how that data will be mapped to the new environment. That takes planning and must be defined well before the vendor is ready to implement your tool.
• Insufficient IT and End-User Training: A link to the ITSM tool manual is not enough. Staff and users need training on how your processes will be executed in the new tool.

A survey of implementation challenges for ServiceNow’s customers

26% Resistance to change

43% Lacked a clear roadmap

38% Planning for resources

Source: Acorio, 2019

Info-Tech’s approach

Divide the implementation project into controllable phases for an effective implementation.

STOP: Use this blueprint after you have selected an ITSM solution

Leverage our SoftwareReviews service and related blueprints to assist with ITSM tool selection, and then use this blueprint to plan the implementation.

Info-Tech’s methodology to build an ITSM Tool Implementation Plan

Insight summary

Blueprint deliverables

This blueprint includes tools and templates to help you accomplish your goals:

ITSM Tool Implementation Checklist Identify the most common decisions you will need to make and prepare for your implementation project.	ITSM Tool Project Charter Template Review and edit the template to suit your project requirements
	ITSM Tool Deployment Plan Template Prioritize and prepare tool rollout plan
	ITSM Tool Training Schedule Use the checklist to create your new tool training roadmap

Blueprint benefits

Measured value from using this blueprint

Use this guide as an example to calculate your total cost savings from the ITSM tool implementation project.

Info-Tech offers various levels of support to best suit your needs

Diagnostics and consistent frameworks used throughout all four options

Guided Implementation

A Guided Implementation (GI) is a series of calls with an Info-Tech analyst to help implement our best practices in your organization. A typical GI is between 6 to 8 calls over the course of 3 to 6 months.

Phase 1

Identify Stakeholders, Scope, and Preliminary Timeline

This phase will walk you through the following steps:

1. Define scope
2. Define roles and responsibilities
3. Identify preliminary timeline

Step 1.1

Define scope

Activities

This step will walk you through the following activities:

• Define the scope of the implementation project
• Establish the future processes and functionalities the tool will support

This step involves the following participants:

• CIO
• IT Director/Manager
• Service Manager
• Project Manager and the project team

Outcomes of this step

• Specifying the implementation project
• Identifying the business units that are needed to support the project
• Defining the ongoing and future service management processes the tool will support

1.1.1 Use the Project Charter Template to capture scope, stakeholders, and timeline as outlined in Phase 1

Follow the instructions in Phase 1 (step 1.1, 1.2, and 1.3) to gather information needed to create a project charter to define project parameters.

Specific subsections are listed below and described in more detail in the remainder of this phase.

1. Project Overview: Includes deliverables, scope, milestones, and success metrics.
2. Governance and Management: Includes roles, responsibilities, and resource requirements.
3. Project Risks, Assumptions, and Constraints: Includes risks and mitigation strategies as well as any assumptions and constraints.
4. Project Sign-Off: Includes IT and executive sign-off (if required).

Download the ITSM Tool Implementation Project Charter Template

1.1.2 Leverage the Implementation Checklist to guide your preparation

The checklist tabs align to each phase of this blueprint.

• Phase 1 (Tab 1) – Identify Stakeholders, Scope, and Preliminary Timeline
• Phase 2 (Tab 2) – Prepare to Implement Incident Management and Service Request Modules
• Phase 3 (Tabs 3+4) – Prepare to Implement Additional ITSM Modules (e.g. Change Management)
• Phase 4 (deployment section in each tab) – Create a Deployment Plan (Communication, Training, Rollout)

Download the ITSM Tool Implementation Checklist

1.1.3 Review goals that drove the ITSM tool purchase

Identify the triggers for the selection and implementation of your new ITSM tool.

Whether this is your first ITSM tool or a replacement for your old tool, the project was likely triggered by pain points that must be addressed by the new tool to improve your service desk. Having a clear understanding of these pain points throughout the implementation of your new tool will help to prevent them from reoccurring.

Common ITSM pain points include:

1. Poor communication with end users on ticket status.
2. Lack of SLA automation to escalate issues to the appropriate channels.
3. Poor self-service options for end users to perform simple requests on their own.
4. Undeveloped knowledgebase for users to find answers to common issues.
5. Lack of reporting or mistrust in reporting data.
6. Lack of automation, including ticket templates.
7. Overcomplicated ticket categories resulting in categories being misused.
8. Overconfiguration prevents future upgrades.
9. Lack of integration with other tools.

If you haven't already selected an ITSM tool, leverage the IT Service Management Selection Guide to select the right tool.

Download the IT Service Management Selection Guide

1.1.4 Plan to interview staff to support organizational change management

Identify challenges with the existing tool and processes as well as potential objections to the new tool.

Incorporate this feedback in the implementation to drive buy-in and a successful rollout.

Implementing a new ITSM tool will force changes in how IT staff do their work:

• At a minimum, it means learning a new interface.
• It could also mean leveraging features that improve IT operations but could change the process or tasks for the staff.
• Their input on the current tool and process challenges can be critical for the project.
• Solving at least some of their challenges can help bring them onboard to use this tool properly and follow associated process changes.

Info-Tech Insight

Keep management in the loop through every stage of the implementation process. They are the ones who are paying for the software, so they need to be informed throughout implementation and feel that their needs and feedback are being heard to prevent pushback further into the implementation.

1.1.5 Identify the modules and features you will plan to implement

Consider these factors when deciding what modules and features you want to implement:

• Specific ITSM modules based on the recommended order and any unique business requirements
• Key features that drove the tool purchase and address key issues
• High-level process changes needed to address challenges and realize expected benefits from the new ITSM tool (e.g. if a key goal was automated ticket routing based on categories, then the project needs to include developing a good categorization scheme)

Recommended order for implementation:

1. Incident Management and Service Request

This is the core of service management and typically has the highest impact on the organization. Include knowledgebase development as part of this implementation.

2. Change Management

A foundational component of service management, it allows organizations to minimize disruptions to IT services when making changes to services and critical systems.

3. Asset Management

A foundational component of service management, it allows organizations to track their assets’ locations, how they are used, and when changes are made to them.

1.1.6 Determine if data migration is required

If you are switching from a previous ITSM tool, carefully weigh the pros and cons as well as the necessity of migrating historical transactional data before deciding to import it into the new tool.

Importing your old transactional data will allow you to track metrics over time, which can be valuable for data analysis and reporting purposes.

However, ask yourself what the true value of your data is before you import it.

You will not get value out of migrating the old data if:

• You have incomplete or inaccurate data (a high percentage of incidents did not have tickets created in the old system).
• The categorization of your old tickets was not useful or was used inconsistently.
• You plan on changing the ticket categorization in the new system.

“Don’t debate whether you can import your old data until you’ve made sure that you should.”

– Barry Cousins, Practice Lead at Info-Tech Research Group

Info-Tech Insight

If you decide to migrate your data, keep in mind that it can be a complex process and proper time should be budgeted for planning, structuring the data, and importing and testing it.

Step 1.2

Define roles and responsibilities

Activities

This step involves the following participants:

• CIO
• IT Director/Manager
• Service Manager
• Project Manager and the project team

Outcomes of this step

• Decision on whether to hire professional services for the implementation
• Clearly defined roles and responsibilities for the project

1.2.1 Identify key internal roles and responsibilities

Review the tasks outlined in the Implementation Checklist to help you identify appropriate roles and specific staff that will be needed to execute this project.

RACI = Responsible, Accountable, Consulted, and Informed

Assign individuals to roles through each step of the implementation project in the governance and management chart in the Project Charter Template.

Download the Project Charter Template

1.2.2 Key external roles and responsibilities

Determine whether you will engage professional services for the implementation.

Step 1.3

Identify preliminary timeline

Activities

This step involves the following participants:

• CIO
• IT Director/Manager
• Service Manager
• Project Manager and the project team

Outcomes of this step

• Specifying the target dates for the implementation project

1.3.1 Identify preliminary internal target dates

Identify high-level start and end dates based on the following:

• Existing process maturity
• Process changes required (to address process issues or to realize targeted benefits from the new tool)
• Data migration requirements (if any)
• Information to prepare for the implementation (review the Checklist Tool)
• Vendor availability to support implementation
• Executive mandates that have established specific milestone dates

Create an initial project schedule:

• Review the remaining phases of this blueprint for more details on the implementation planning steps.
• Review and update the Checklist Tool to suit your implementation goals and requirements.
• Assign task owners and target dates in the Checklist Tool.

Note: This is a preliminary schedule. Monitor progress as well as requirement changes, and adjust the scope or schedule as needed.

Update the columns in the Checklist Tool to plan and keep track of your implementation project.

1.3.2 Identify target dates for vendor involvement

Plan when you'll be ready for the vendor and identify the key points for when the vendor will come in.

Are dates already scheduled for tool installation/configuration/customization?

If yes:

• Clarify vendor expectations for those target dates (i.e. what do you have to have prepared in advance?).
• Determine options to adjust dates if needed.

If no:

• Defer scheduling until you have reviewed and updated the Implementation Checklist. The checklist will help you determine your readiness for vendor involvement.

Consider if the vendor will implement the ITSM tool in one go or if they will help setup the tool in stages. Keep in mind that ITSM implementation projects typically take anywhere from 9 weeks to 16 months and plan accordingly depending on the maturity of your processes and the modules and features you plan to implement.

Use your internal target dates to estimate when you'll be ready for the vendor to set up the tool and implement the setting that you've defined.

Phase 2

Prepare to Implement Incident Management and Service Request Modules

This phase will walk you through the following steps:

• Review your existing solution and challenges
• Plan ticket management and workflow implementation
• Plan data migration, knowledgebase setup, and integrations
• Plan the module rollout

Additional Info-Tech Research

The Implementation Checklist Tool summarizes what you need to prepare for the implementation. If you need more assistance with developing the underlying ITSM processes, use the tools, templates, and guidance in these blueprints.

Standardize the Service Desk

Build core elements of service desk operations, including incident management and service request workflows, ticket categorization schemes, and ticket prioritization rules.

Optimize the Service Desk With a Shift-Left Strategy

Implement tools such as an improved knowledgebase and self-service portal to enable lower tier support staff and end users to resolve incidents or fulfill service requests.

Incident and Problem Management

Develop a critical incident management workflow and create standard operating procedures for problem management.

Step 2.1

Review your existing solution and challenges

Activities

This step involves the following participants:

1. Service Manager and Service Desk Team
2. Project Manager and Core Project Team
3. Subject Matter Experts and Tool Administrator, if applicable

2.1.1 Configure your tool, don’t customize it

Your tool may require at least some basic configurations to align with your processes, but in most cases customization of the tool is not recommended.

Case Study

Consider the consequences of over-customizing your solution.

INDUSTRY: Education

SOURCE: IT Director

2.1.2 Review your existing process to identify opportunities for improvement

Documenting your existing processes is an effective method for also reviewing those processes and identifying inefficiencies. Take advantage of this project to fix your process issues.

1. Document your existing workflows for incident management and service requests.
2. Review your workflows to identify opportunities to optimize through process refinement (e.g. clarifying escalation guidelines) or by leveraging features in your new ITSM tool (e.g. improved workflow automation).
3. Similarly, review the challenges identified through stakeholder interviews: is there an opportunity address those challenges through process changes or leveraging your new ITSM tool?
4. Address those challenge and issues as you execute the tasks outlined in the Implementation Checklist Tool. For example, if inconsistent ticket routing was identified as a challenge due to a vague categorization scheme, that’s a driver to review and update your scheme rather than just carry forward your existing scheme.

Regardless of your existing ITSM maturity, this is an opportunity to review and optimize existing processes. Even the most-mature organizations can typically find an area to improve.

Case Study

Reviewing and defining processes before the implementation can be a project in itself.

INDUSTRY: Defense

SOURCE: Anonymous

Step 2.2

Plan ticket management and workflow implementation

Activities

This step involves the following participants:

1. Service Manager and Service Desk Team
2. Project Manager and Core Project Team
3. Subject Matter Experts and Tool Administrator, if applicable

Outcomes of this step

Tool is designed and configured to support service desk processes and organization needs.

Checklist overview

The ITSM Tool Implementation Checklist will help you estimate resources required to support demand, based on your ticket volume.

TAB 2	TAB 3	TAB 4
Incident and Service Modules Checklist	Change Management Modules	Asset Management Modules

How to follow this section:

The following slides contain a table that explains why each task in the module matters and what needs to be considered. Complete the checklist modules referring to this section.

2.2.1 Define ticket classification values

Ticket classification improves reporting, workflow automation, and problem identification.

Review your existing ticket classification values to identify what to carry forward, drop, or change. For example, if your categorization scheme has become too complex, this is your opportunity to fix it; don’t perpetuate ineffective classification in the new tool.

2.2.2 Define ticket templates for common incident types and service requests

Ticket templates are the backbone of automation. A common complaint is that tickets take too much time. However, a little planning can reduce the time it takes to create a ticket to less than a minute.

2.2.3 Plan your ticket intake channels

Consider possible ticket intake channels and evaluate their relevance to your organization.

2.2.4 Design a self-service portal

Map your processes to the tool by defining your ticket input, categories, escalations, and workflows.

Don’t forget about the client-facing side of the solution. It is important to build a self-serve portal that has an easy-to-use interface where the user can easily find the category for the help they’re looking for. It is also necessary to educate the users on where to find the portal or how to access it.

2.2.5 Plan your knowledgebase (KB) implementation in the new tool

Evaluate how onerous KB migration will be for you. Is this an opportunity to improve how the KB is organized?

2.2.6 Design your ticket status notification processes and templates

2.2.7 Identify required user accounts, access levels, and skills/service groups

2.2.8 Review and update your workflows and escalation rules

2.2.9 Identify desired reporting and relevant metrics to track

Documentation of key metrics of service desk performance and end-user satisfaction that you wish to improve through the new solution is key to evaluate the success of your implementation.

Step 2.3

Plan data migration and integrations

Activities

This step involves the following participants:

1. Service Manager and Service Desk Team
2. Project Manager and Core Project Team
3. Subject Matter Experts and Tool Administrator, if applicable

Outcomes of this step

• Decisions made around data migration, integrations, automation, and reporting.
• ITSM Tool Implementation Checklist

2.3.1 Create a data migration and archiving plan

2.3.2 Identify and plan required integrations

Consider and plan for any necessary integrations with other systems.

A major component of the implementation that should be carefully considered throughout is if and how to integrate your ITSM tool with other applications in the environment.

Step 2.4

Plan the module rollout

Activities

This step involves the following participants:

1. Service Manager and Service Desk Team
2. Project Manager and Core Project Team
3. Subject Matter Experts and Tool Administrator, if applicable

Outcomes of this step

Identify and plan for additional modules and features to be implemented

2.4.1 Repeat the methodology for additional ITSM modules, using the Checklists as a guide

The preparation completed in Phase 1 and 2 to this point provide a foundation for additional ITSM modules.

This blueprint starts with the incident management and service request modules as those are typically implemented first since they are the most impactful to day-to-day IT service management.

In addition, the methodology outlined in Phase 1 and 2 to this point provides a model to follow for additional ITSM modules:

• If you did not already account for additional modules in Phase 1, then repeat the steps in Phase 1 to define scope, stakeholders, and timeline.
• The Implementation Checklist Tool provides tabs for Change Management and Asset Management to outline the specific details for those topic areas, but they follow the same high-level steps as Phase 2 (e.g. review existing processes, design relevant workflows).
• If you are planning to implement other modules (e.g. Problem Management), create additional tabs in the Implementation Checklist Tool as needed, using the existing tabs as a base.

2.4.2 Leverage these blueprints to help you implement change and asset management modules

The Implementation Checklist Tool summarizes what you need to prepare for the implementation. If you need more assistance with developing the underlying ITSM processes, use the tools, templates, and guidance in the blueprints below.

Optimize IT Change Management

Define change management workflows, key roles, and supporting elements such as request-for-change forms based on best practices.

Implement Hardware Asset Management

Create an SOP and associated process workflows to streamline and standardize hardware asset management.

Implement Software Asset Management

Build on a strong hardware asset management program to also properly track and manage software assets. This includes managing software licensing, finding opportunities to reduce costs, and improving your software audit readiness.

Phase 3

Create a Deployment Plan (Communication, Training, Rollout)

This phase will walk you through the following steps:

1. Create a communication plan (for IT, users, and business leaders)
2. Create a training plan
3. Plan how you will deploy, monitor, and maintain the solution

ITSM Tool Training Schedule		ITSM Tool Deployment Plan Template
Use the template to document and plan the communications and training needs prior to deployment of the new tool.		Use the deployment plan template to document the strategy and decisions made for making the transition to the new ITSM tool.
	Download the ITSM Tool Training Schedule		Download the ITSM Tool Deployment Plan Template

Step 3.1

Create a communication plan (for IT, users, and business leaders)

Activities

This step involves the following participants:

1. CIO/IT Director
2. IT Manager
3. Service Manager

Outcomes of this step

Plan for communicating the change with business executives, service desk agents, and end users.

3.1.1 Ensure there is strong communication from management throughout the implementation and deployment

A common contributing factor for unsuccessful implementation is a lack of communication around training, transitioning, and deploying the new tool.

Common Pitfall:

Organizational communication and change management should have been ongoing and tightly monitored throughout the project. However, cut-over is a time in which critical communication regarding deployment and proper user training can be derailed when last-minute preparations take priority. Not only will general user frustration increase, but unintended process workarounds will emerge, eroding system effectiveness.

Mitigating Actions:

Deliver training for end users that will be engaged in testing. For all other users, deliver training prior to go-live to avoid the risk of training too early (where materials may not be ready or users are likely to forget what was learned). If possible, host quick refresher training a week or two prior to go-live.

Aim to communicate the upcoming go-live. The purpose of communication here is to reiterate expectations, complexities, and ramifications on business going forward. Alleviate performance anxiety by clearly stating that temporary drops in productivity are to be expected and that there will be appropriate assistance throughout the transition period.

Transition: Have the project/program manager remain on the project team for some time after deployment to oversee and assure smooth transition for the organization.

Complete training: Have a clear plan for training those users that were missed in the first round of training as well as a plan for ongoing training for those that require refresher training, for new joiners to your organization, and for any training requirements that result from subsequent upgrades.

3.1.2 Base your communications timeline on a classic change curve

It’s important to communicate the change ahead of the implementation, but also to reinforce that communication after implementation to recover from any resistance that occurs through the implementation itself.

Stages in a typical change curve:

1. Change is announced. Some people are skeptical and resistant, but others are enthusiastic. Most people are fence sitters; if they trust senior leadership, they will give the benefit of the doubt and expect change to be good.
2. Positive sentiment declines as implementation approaches. Training and other disruptions take people’s time and energy away from their work. Project setbacks and delays take credibility away from project leaders and seem to validate the efforts of saboteurs and skeptics.
3. Overall sentiment begins to improve as people adjust and see real progress made. Ideally, early successes or quick wins neutralize saboteurs and convert skeptics. At the very least, people will begin to accept and adapt to new realities.
4. If the project is successful and communication is reinforced after implementation, sentiment will peak and level out over time as people move on to other projects.

1. Honeymoon of “Uninformed Optimism”: Tentative support and enthusiasm for change before people have really felt or understood what it involves.
2. Backlash of “Informed Pessimism” (leading to “Valley of Despair”): People realize they’ve overestimated the benefits (or how soon they’ll be achieved) and underestimated the difficulty of change.
3. Valley of Despair and beginning of “Hopeful Realism”: Sentiment bottoms out and people begin to accept the difficulty (or inevitability) of change.
4. Bounce of “Informed Optimism”: More optimism and support when people begin to see bright spots and early successes.
5. Contentment of “Completion”: Change has been successfully adopted and benefits are being realized.

3.1.3 Communicate new processes

1. Communicate with business unit leaders and users:
• Focus on the benefits for end users to encourage buy-in for the change.
• Include preliminary instructions with a date for training sessions.
2. Train users:
• Teach users how to contact the service desk and submit a ticket.
• Set expectations for IT’s response.
• Record all your training sessions so it can used for recursive training.
3. Enforce:
• IT must point users toward the new process, but ad hoc requests should still be expected at first. Deal with these politely but encourage all employees to use the new service desk ticketing process, if applicable.
4. Measure success:
• Continue to adjust communications if processes aren’t being followed to ensure SLAs can be met and improved.

“Communicate with your end users in phase 1 to let them know what will be changing, get feedback and buy-in, and inform them that training will be happening, then ensure you train them once the tool is installed. A lot of times we’ll get our tool set up but people don’t know how to use it."

– Director of ITSM Tools

Info-Tech Insight

If there is a new process for ticket input, consider using a reward system for users who submit a ticket through the proper channel ;(e.g. email or self-serve portal) instead of their old method (e.g. phone). However, if a significant cultural change is required, don’t expect it to happen right away.

Step 3.2

Create a training plan

Activities

This step involves the following participants:

• IT Director
• Project Manager
• Service Desk Manager

Outcomes of this step

• Training modules for different users of the tool.
• Assignment of training modules to users and schedule for completion.

3.2.1 Target training session(s) to the specific needs of your service desk and IT staff

Create targeted role-based training programs for your service desk analysts; they care about the portion of the solution they are responsible for, not the functionality that is irrelevant to their job.

Create and execute a role-based training program by conducting training sessions for targeted groups of users, training them on the functions they require to perform their jobs.

Use a table like this one to help identify which roles should be trained on which tasks within the ITSM tool.

The need for targeted training:

• IT personnel may challenge the need for training. They may feel they don’t require training on the use of tools or that they don’t have time to dedicate to training when there is so much work to be done.
• Providing targeted training focused on only the functions of the solution that each tier is responsible for can help to overcome that resistance.
• Targeted training may include basic training for level 1 technicians and more advanced in-depth training for administrators, power users, or level 2/3 technicians.

Info-Tech Insight:

Properly trained users promote adoption and improve results. Always keep training materials updated and available. New employees, new software integration, and internal promotions create opportunities for training employees to align the ITSM tool with their roles and responsibilities.

3.2.2 Provide training

Training must take place before deployment to ensure that both your service desk agents and end users will use the tool in the way it was intended and improve end-user satisfaction.

• Implementing a new ITSM tool will likely bring with it at least some degree of organizational and cultural change. It’s important to manage that change through proper training. Your training needs will vary depending on the maturity of the organization and the amount of cultural and process change being implemented.
• If this is your first ITSM solution with many new changes for staff to take on board, it will be important to dedicate training time not only before deployment but also several months after the initial installation, to allow staff to gain more experience with the new tool and processes and formulate questions they may not think to ask during implementation.
• A training plan should take into account not only training needs for the implementation project but also any ongoing training requirements that may be required. This may include:
  • Training for new personnel.
  • Training on any changes to the tool.
  • Training on any new processes the tool will support.
• Better agent training will lead to better performance and improved end-user satisfaction.

The blue graph line charts new-agent training hours against first contact resolution and the orange graph line charts the trendline for the dataset.

Source: MetricNet, 2012

3.2.3 Choose an appropriate training delivery method

Training should include use cases that focus on not only how the tool’s interface works but also how the tool should be used to support process activities.

1. Training through use cases highlights how the tool will support the user in role-based tasks.
2. If new processes are being introduced along with the tool, training should cover both in an integrated way.
3. Team leadership and management commitment ensures that all agents take their training seriously and are prepared for all use cases by the deployment date.

Info-Tech Insight:

Ensure that the training demonstrates not only how the tool should be used, but also the benefits it will provide your staff in terms of improved efficiency and productivity. Users who can clearly see the benefits the tool will provide for their daily work will accept the tool more readily and promote it across the organization.

Step 3.3

Plan how you will deploy, monitor, and maintain the solution

Activities

This step involves the following participants:

• IT Director
• Project Manager
• Service Desk Manager

Outcomes of this step

Deployment plan, including a plan for cut-over from the old tool (if applicable), release of the new tool, and post-deployment support and maintenance of the tool.

3.3.1 Plan the transition from your old tool to ensure continual functionality

If you will have a transitional period during which the current tool will be used alongside the new tool, develop a clear plan for the transition to ensure continued service for your end users.

• If there will be an interim period during which only some aspects of the new ITSM tool are functional, you will need to determine how the new system and old systems will work together for that period of time. This may require creating interfaces as well as providing user documentation and/or SOPs on how the business processes will operate during the interim period.
• Cut-over is the period during which the changeover to the new system occurs. Cut-over activities need to be tightly choreographed for a successful deployment. If improperly planned, chaos may erupt when unforeseen issues are encountered during deployment, the deployment may be jeopardized, and the organization may encounter costly interruptions to its daily operations.
• Many organizations may leave any open tickets in the old tool until they are closed, which requires that tool run alongside the new tool for a transitional period. In this case, it is necessary to create guidelines around how long the open tickets will remain in the old system and ensure there is clear communication around these processes.

Be prepared for the transition:

1. Create a robust cut-over plan that includes when the old tool will be decommissioned, what activities are necessary during the cut-over, and what the contingency plan is in case of unforeseen issues.
2. Plan for and perform mock cut-overs to establish the timeline and dependencies for all steps that need to be performed to successfully complete the changeover. Do this to avoid any surprises or delays during the true cut-over period.
3. Establish cut-over logistics: Create a schedule for resources to work in shifts to avoid burn-out during cut-over, which can lead to lapses in judgment and easily avoidable mistakes. Allocate dedicated workspaces for cut-over activities, e.g. “war rooms” for the triage of issues.

3.3.2 Choose a cut-over approach that works for you

Approaches and insights from three case studies

3.3.3 Deploy the solution and any new processes simultaneously to ease the transition

Follow a deployment plan for introducing new processes alongside the new tool to ensure changes to both process and technology are adopted simultaneously.

If you’re introducing new processes alongside the new tool, it’s important to maintain the link between process and tool. Typically, the processes and tool should be deployed simultaneously unless there is a strong reason not to do so.

Deployment can be done as a big-bang or phased approach. The decision to employ a phased deployment depends on the number and size of business units the tool will support, as well as the organization’s geography and infrastructure (deployment locations).

Before deployment, conduct readiness assessments to understand whether:

The people are ready to accept the new system (have received the proper training and communications and understand how their jobs will change when the switch is flipped).

The technology is ready (test results are favorable, workarounds and a plan for closure have been identified for any open defects, and the system is performing as expected).

The data is ready (data for final conversion has been cleansed, and all conversions have been rehearsed).

The post-deployment support model is ready (infrastructure and technical support is in place, sites are ready, knowledge transfer has been conducted with the support organization, and end users understand procedures for escalation of issues).

3.3.4 Have a post-deployment support plan in place

Ensure that strong internal support for the project and tool will continue after deployment.

The stabilization period after a new software deployment can last between three and nine months, during which there may be continued training needs and fine-tuning of processes. Internal support from project leaders within your organization will be critical to recover from any dip in operational efficiency and deliver the benefits of the tool.

Consider the following to prepare better for your support plan:

What are the roles and responsibilities for ongoing tool administration support?

What level of support will exist to assist service desk staff after deployment?

How much time will project team resources devote to tackling upcoming issues and assisting with ongoing support?

Who will be responsible for ongoing training needs and documentation?

If your organization is spread across multiple locations, what level of support/assistance will be available at each site?

How will new code releases or system upgrades be managed and communicated?

Info-Tech Insight:

Deployment is only the first step in the system lifecycle. Full benefit realization from the tool requires ongoing investment and learning to be sustained. Unless processes and training are updated on an ongoing basis, benefits gained will start to decrease over time. If your service desk efficiency stagnates at the level it was at prior to implementation, the tool has failed to serve its objective.

Establish ongoing tool maintenance, improvement structures, and processes

People, processes, and organizations change over time, and your ITSM tool will need to change to meet expectations.

Develop and execute a plan for the maintenance of the solution and its infrastructure components.

Assign responsibility for ongoing maintenance. Hold regular meetings for the following activities:

1. Inspect data and reports.
2. Assess whether you’re meeting SLAs.
3. Predict any upcoming changes that may impact ticket volume (e.g. a new operating system or security patch).
4. Create new ticket templates for recurring or upcoming issues.
5. Create new knowledgebase articles.
6. Determine whether ticket categories are being used correctly.
7. Ask team if there are any problems with the tool.

3.3.5 Monitor success metrics defined in Project Charter

Revisit your goals for the solution and assess if they are being met by evaluating current metrics. If your goals have not yet been met, re-evaluate how to ensure the tool will deliver value.

Sample High-Level Goals:

1. Improved service desk efficiency
2. Improved end-user satisfaction
3. Improved self-service options for end users
4. Improved data and reporting capabilities

Related Info-Tech Research

Optimize IT Change Management

Define change management workflows, key roles, and supporting elements such as request-for-change forms based on best practices.

Standardize the Service Desk

Build core elements of service desk operations, including incident management and service request workflows, ticket categorization schemes, and ticket prioritization rules.

Optimize the Service Desk With a Shift-Left Strategy

Implement tools such as an improved knowledgebase and self-service portal to enable lower tier support staff and end users to resolve incidents or fulfill service requests.

Incident and Problem Management

Develop a critical incident management workflow and create standard operating procedures for problem management.

IT Service Management Selection Guide

Identify the best-of-breed solution to make the most of your investment and engage the right stakeholders to define success.

Analyze Your Service Desk Ticket Data

Develop a framework to track metrics, clean data, and put your data to use for pre-defined timelines.

Bibliography

Adiga, Siddanth. “10 Reasons Why ITSM Implementations Fail.” Could Strategy, 6 May 2015. Web.

Hastie, Shane, and Stéphane Wojewoda. “Standish Group 2015 Chaos Report.” InfoQ, 4 October 2015. Web.

“How to Manage Change in the Implementation of an ITSM Software.” C2, 20 April 2015. Web.

Lockwood, Meghan. “First Look: Annual ServiceNow Insight and Vision Executive Summary [eBook].” Acorio, 31 October 2019. Web.

Mainville, David. “7 Steps to a Successful ITSM Tool Implementation.” Navvia, 2012. Web.

Rae, Barclay. “Preparing for ITSM Tool Implementation.” Joe the IT Guy, 24 June 2015. Web.

Rae, Barclay. “Successful ITSM Tool Implementation.” BrightTALK, 9 May 2013. Webcast.

Rumburg, Jeffrey. “Metric of the Month: Agent Training Hours.” MetricNet, 2012. Web.