Surely So Many ITIL and ITSM Process Names Don’t Need to End in “Management”?

Stephen Mann • 13 Nov 2017

Before you shout at the screen, I know that only 20 of the 26 ITIL process names end in “management.” In case you are wondering, it’s change evaluation, continual service improvement, design coordination, request fulfilment, service validation and testing, and transition planning and support that don’t.

Before you shout at the screen, I know that only 20 of the 26 ITIL process names end in “management.” In case you are wondering, it’s change evaluation, continual service improvement, design coordination, request fulfilment, service validation and testing, and transition planning and support that don’t.

But have you ever stopped to think about what we do in the IT service management (ITSM) space? That we seem to have a lot of “management” stuff when we look at the processes we use (or are able to use). Not the type of management you can read about in business or leadership books but rather the use of a word that serves to give a formal legitimacy to operational processes/capabilities such as incident management or change management.

So we are managing incidents and changes (and problems, service levels, availability, capacity, configurations, etc.) but does the constant use of the word “management” really do the capabilities, activities undertaken, and business outcomes justice? And, more importantly, do these management-oriented process names do a disservice to the IT, end user, or customer needs that cause their existence?

It’s a Little Similar to What I Like to Say About Metrics

ITSM or service desk metrics can be overly focused on what is done rather than what is achieved through what is done. For example, companies measure how efficient their operational processes are, resulting in a sea of green performance indicators despite the fact that end users and customers still have issues with the quality of the IT support they receive. Why? Because we often measure success at the wrong point.

So in the case of incident management, say, am I being a little pedantic in thinking that that the term “incident management” seems a little inwardly focused – i.e. focused on an activity we do rather than on what we achieve – and thus divorced from the current approach to ITSM that talks about “the pursuit of positive outcomes” and “the need to create business value”?

You Might Be Thinking: “But Incidents Are Managed Though”

Don’t get me wrong, I agree that they are. For instance, one could argue that incident management is a relevant term from a couple of perspectives, because incidents are:

Managed in the same way that people are managed – there’s a control mechanism in place to ensure that everything is consistently in good order, i.e. that here management is “the process of dealing with or controlling things or people” (Oxford Dictionaries).

Managed, or systematically worked, through the incident lifecycle, from identification through to ticket closure.

Or the dictionary lovers among you will know that “The English verb ‘manage’ comes from the Italian maneggiare (to handle, especially tools or a horse), which derives from the two Latin words manus (hand) and agere (to act)” (Wikipedia) – and incidents are definitely handled by IT. Or, finally, that according to Merriam-Webster, management is the “judicious use of means to accomplish an end” – which sounds like a process.

But are Processes Labelled as “Management” because it Sounds Better or More Important?

We had this uniformity of terminology across ITIL v2’s ten “something-management” processes and now have it across 20 of ITIL 2011’s 26 processes. It looks tidy and probably helps us to remember the process names, in that one only has to think of an area and then add “management” to the end of it to get the process. For instance, supplier management.

Or maybe there’s an unwritten workplace rule that all processes need to have the word “management” in them? Which to me automatically makes them feel more inwardly, rather than outwardly, focused despite them sounding more important. It reminds me somewhat of interviewee CVs where they state that they managed this and that, and so you keep having to ask “But what did you achieve while you were managing x, y, and z?” With the word “managed,” or phrase “management of,” used to create an aura of importance but with little substance to support it.

Does This Need for “Terminology Uniformity” Affect Focus and Outcomes?

You’ve come this far, so hopefully I’ll now make my point…

I’ve written before about the common misconception that ITIL is seen as a set of processes rather than a fundamentally different way of providing IT – i.e. delivering IT as a service. With this due in part to the focus on the popular processes in the ITIL Foundation exam – where a disproportionate amount of time is spent learning about incident, problem, and change management, and thus these are what are adopted more than most “in the wild.”

But what if the terminology used in ITIL, or by those just using ITIL terminology for their ITSM processes, is another cause of the suboptimal focus on “the other processes”?

“But processes get things done!” I hear you cry. And you’re not wrong. But what if the use of “management” in so many ITSM processes makes one think that they are more important in isolation than they actually are? Or, alternatively, that the word “management” helps to compartmentalize each process from the bigger picture of “managing IT as a service.” And returning to my earlier point about “incident management” being an inwardly-focused term compared to the more traditional “IT support,” or the more modern “business support” – are we subconsciously misdirecting people from the required outcomes?

It makes you think whether the use of “management” in so many ITIL and ITSM process names does more harm than good?

About Stephen

Principal and Content Director at the ITSM-focused industry analyst firm ITSM.tools. Also an independent IT and IT service management marketing content creator, and a frequent blogger, writer, and presenter on the challenges and opportunities for IT service management professionals.

Previously held positions in IT research and analysis (at IT industry analyst firms Ovum and Forrester and the UK Post Office), IT service management consultancy, enterprise IT service desk and IT service management, IT asset management, innovation and creativity facilitation, project management, finance consultancy, internal audit, and product marketing for a SaaS IT service management technology vendor.

About Alemba

Alemba develops vFire, an Enterprise Service Management application that combines user-focused design philosophy with robust out-of-the-box functionality. Backed by a quarter of a century of heritage, Alemba’s specialist Service Management software is trusted by a large number of Enterprise-scale organizations across the globe.

With a strong consultancy background, unrivalled expertise in the Service Management market, and a strong focus on customer experience, Alemba is ideally positioned to deliver a successful, end-to-end ITSM project within your organization. Alemba can assist with every aspect of your Service Management needs, from software implementations to maintenance and support, training and upgrades.