Let’s talk about introducing ITSM. IT service management (ITSM) – the management of IT, delivered as a service – is nothing new; but for some companies it still is. It might not be totally new, as much of what is contained in ITSM best practice, such as the ITIL framework, is based on common practices and, in many instances, common sense. And thus, many companies will be doing elements of ITSM even if they don’t think of it, or label it, as such. In such instances, the introduction of ITSM is as much the formalization of existing ways of working, with small improvements, as it is starting to do brand new things.
If your company wants to introduce ITSM, or ITSM best practice using ITIL or another approach, then it’s wise to ask those involved five key questions before starting on the journey. This will help to ensure that your company is ready for everything that will follow, along with preventing many of the common ITSM adoption mistakes.
Question 1: Why Are We Introducing ITSM?
Silly question, right? Well, not really.
When introducing ITSM, it’s important to understand why ITSM is needed and how it will benefit your company. Hopefully this question will reinforce the fact that ITSM is merely “the means to an end” rather than the end itself, i.e. that it’s not about introducing a formal incident management process (the means) but rather realizing a reduction in downtime and the associated adverse impact of IT issues (the end).
The question should also help to identify the pain points that your company needs to address through ITSM. If you don’t do this, then you’re adopting ITSM as merely a “good thing to do,” and who’s to say that what you adopt will make any tangible difference to your IT service delivery and support in such a scenario.
Question 2: What Do We Hope to Achieve by Introducing ITSM?
This follows on from the previous question and, as such, we need to remember the difference between the “means” and the “end” when introducing ITSM. So, ensure that you agree on appropriate critical success factors (CSFs) and key performance indicators (KPIs) that can be used to focus attention, to measure progress, and to ascertain success.
Importantly, this shouldn’t be achievements such as “the new ITSM tool is implemented to time and budget” or “problem management people, processes, and technology are in place by Q2.” It needs to be positioned in terms of achieving better business outcomes. For example:
- Higher employee productivity due to less downtime (thanks to problem and incident management)
- Speedier delivery of new business capabilities (thanks to change management)
- Better value IT (thanks to demand, capacity, and financial management)
Question 3: What’s Most Important?
As I already mentioned, your company might not need everything that an ITSM best practice framework such as ITIL has to offer when introducing ITSM. I’d be shocked if it did! Many companies only ever adopt a small subset of the 26 processes and four functions ITIL includes – often incident, problem, change, request fulfillment, service desk service level agreements (SLAs), service catalog, self-service, and a partial configuration management database (CMDB). But even following this isn’t the right approach. Instead, you need to understand what ITSM capabilities will make the most difference and address those opportunities first.
Traditionally, companies have started with one (or more) of these combinations when introducing ITSM:
- Incident and problem management
- Incident and change management
- Incident, problem, and change management (IPC)
- Change and configuration management
However, you should identify the capabilities that will make the most difference to your IT service delivery and support, which might be none of the above and rather self-service or continual improvement (formerly known as CSI).
Question 4: How Will We Assess Our Requirements When Introducing ITSM?
This needs to start with the desired business outcomes rather than the features and functions available in ITSM technology. There are two common mistakes to avoid when introducing ITSM:
- Using another company’s request for proposal (RFP) and adding to it such that you end up with a long list of low-level requirements that might not deliver the outcomes you need. It will probably also mean that you ask, and pay, for much more than your company needs and could ever use when investing in an ITSM tool.
- Being driven by a particular ITSM tool’s capabilities – it’s what you could do versus what you need to do (plus your company might not have the people capacity or capabilities to use much of what the tool offers).
Both of these common mistakes will take your company further away from what was agreed when answering Question 3. So, ensure that requirement assessment is based on need, not the art of the possible; and that the right people are involved in agreeing the final, prioritized set of business requirements. And don’t throw out what you already do – some of it will still be relevant in a formalized ITSM world.
Question 5: Have We Considered the Impact on Our People?
ITSM is often viewed as a set of best practice processes, with the processes enabled by a fit-for-purpose help desk or ITSM tool. But it’s really about people, and changing the way people think and act in the pursuit of better IT service delivery and support.
Thus, introducing ITSM involves significant change – people change. And organizational change management capabilities need to be applied to ensure that people’s concerns and fears are known and addressed, and that the highly-likely resistance to change is well-managed and minimized.
Please remember this – ultimately, the introduction of ITSM will be sub-optimal, or might even fail, without the required investment in organizational change management to help with people change.
So, there you have five key questions to ask before introducing ITSM. If you want to hear more from me, and in person, then please come see me present at the Service Desk and IT Support Show (SITS) in London this June. I’ll be talking on “True stories of service desk contributions to the bottom line” on Wednesday 7 June at 12:30 in Theatre 1 (REG CODE: SW3):
“Does your organization view the service desk as a maintenance operation taking care of the daily technology infrastructure? Would you rather be seen as a dynamic initiator of technology change that contributes directly to the financial success of the business?”
My session will explain how to create business KPIs which prove to the C-suite that IT support can be a profit and loss center, quoting real stories from the front line service desk leaders who “cracked the code” by demonstrating the business contribution of their team.
Hopefully I’ll see you there.
As SysAid Technologies' first employee, Sarah Lahav has remained the vital link between SysAid and its customers since 2003. She is the current CEO and former VP of Customer Relations at SysAid, two positions that have given her a hands-on role in evolving SysAid solutions to align with the dynamic needs of service managers.