The Past and Future of IT Service Management

I’ve been involved in IT service management since the 1970s, and I’ve seen many changes since then. Here’s my summary of where IT service management has come from, and where I think it’s going next.

A purely technical focus in the 1970s

My first job in IT was in the late 1970s. I worked in a support role, fixing broken hardware, and before too long I moved on to jobs which involved resolving incidents and problems on a wide range of hardware and software products. Like others who did similar work in IT, I went on lots of training courses, where I learned about different hardware and software products, and how to fix them, but there was no training in processes, services, or customer experience. If someone asked what I did for a living I would reply “I fix computers”, or maybe “I solve computer problems”. At the time I’d never even heard of IT service management, and I certainly didn’t think of what I was doing as incident management or problem management.

IT service management and ITIL in the 1990s

In the mid-1990s I came across ITIL (the leading best practice framework for IT service management), and it was a revelation. It was like discovering a family that I never knew I had. Concepts like availability management, service continuity management, change management, and problem management described activities that I had discovered for myself. I now had a framework of ideas that I could use to bring more consistency and rigor to how I worked, AND I had a common language that made it easier to communicate with my peers and customers. I attended ITIL Foundation and ITIL Service Manager training courses, and eventually became an ITIL instructor, passing on these great ideas to other people to help them succeed in their careers.

At that time ITIL was very largely focussed on processes, and provided the framework for creating them. In companies that used ITIL, IT support teams stopped lurching from incident to incident, from crisis to crisis, often responding to people who shouted the loudest rather than those who needed help the most. Instead, they put their energies into agreeing on service levels with their customers. Then they ensured that those service levels were met, using the ITIL framework to help them create repeatable processes that ensured the agreed services were delivered consistently.

ITIL 2007 edition

In 2007 a new version of ITIL was released. The biggest change was that ITIL was now structured around a lifecycle. What this meant was that there was now a much better understanding of what services were for, and a clearer focus on what mattered to customers. Much more emphasis was given to strategy and design, and there was a whole book about continual service improvement.

I now realized that meeting an SLA might not be the most important thing for IT organizations to do. It was far too common for us to deliver SLAs whilst leaving our customers disappointed, frustrated, or furious. What we needed was, in fact, a service focus. We had to understand our customers and users and to ensure that our services actually delivered value to them.

So I changed how I worked.

I still tried to ensure that I met agreed targets, but, when circumstances called for it, I understood that I might need to ignore the targets and focus on what the customer really wanted instead. The important things were customer satisfaction and customer experience. But, of course, doing this when appropriate, and only when appropriate, requires an IT organization that has mature processes in the first place, as well as experienced staff who are confident working without a heavy reliance on routine, repeatable processes.

Many people found the transition from a process focus to a service focus very difficult; we still have people working in IT service management who insist on meeting SLAs even when it hurts their customers. I’ve had many conversations with these people, face-to-face and on social media, trying to persuade them to move on from their very old-fashioned process-focussed approach. Sometimes I succeed, but often they continue working the same way, causing issues for their customers wherever they work.

What’s next for IT service management?

Meanwhile, IT service management is moving on again. The world of software development has adopted ideas such as Agile and DevOps and many people in IT service management are recognizing that we also need to move on if we want to deliver the best value to our customers. Here are some of the things that I think will influence the future of IT service management. I don’t have space here to develop all of these ideas fully, but hopefully there will be enough here to stimulate your interest and get you to do some more research.

Agile

The manifesto for agile software development was published in 2001. This emphasized the importance of:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The result is a much more flexible and rapid approach that has delivered enormous improvements in the quality of new software, as well as facilitating the ability to respond rapidly to changing business needs.

The same agile ideas are now being applied to IT service management. They are changing ideas about the best way to approach implementing and improving IT service management (no more multi-year IT service management projects); and about the best way of supporting customers (individuals and interactions over processes and tools).

Lean

Lean is a management approach which emphasizes the importance of creating maximum customer value with minimum waste. You can find articles on the internet about Lean manufacturing, Lean product development, and Lean software development if you want to read more.

In the context of IT service management the most important aspects of Lean are:

• Identify the end-to-end value chain(s) that you are part of
• Ensure that everything you do creates value for customers
• Eliminate waste in every activity, reducing process steps to the bare minimum needed to create value

Automation

Automation has always been part of managing IT. Even when I started, back in the 1970s, we would automate tasks wherever we could. What has changed is the availability of tools that support and enable automation. We can now automate almost anything if we decide to.

There are some things that shouldn’t be automated because they require human judgment as part of the decision-making process, but we should automate everything that we possibly can, so long as:

• We really understand the activity
• The activity is simple enough that we can document it clearly
• It is something done sufficiently often that we can refine and improve the automation
• The automation doesn’t replace human judgment with inflexible rules (“computer says no”)

DevOps

DevOps uses ideas from Agile, Lean, and automation to improve the flow of software from development to customers. DevOps emphasis the three ways:

• Flow – Understand how you fit in an end-to-end value chain, eliminate bottlenecks, limit work in progress
• Feedback – Provide fast feedback loops to help identify and eliminate poor quality as soon as possible with minimum wasted effort
• Experiment and Learning – Create hypotheses, make predictions, test them, learn, and improve

The combination of these three ways with intense collaboration across teams and very high levels of automation can result in extremely fast deployment of new and changed software with very high levels of flexibility and customer satisfaction.

DevOps typically automates many of the tasks that once fell to the people who implemented software changes, but it does include operational aspects as well as software development. IT service management needs to embrace this. We need to contribute to the evolution of new ideas and help to ensure that a massively increased automation of routine operational tasks retains human judgment across the whole of the end-to-end process.

Enterprise Service Management

Many of the ideas, tools, and processes that have developed to support IT service management are just as useful when used to support services that have nothing to do with IT. Enterprise service management (ESM) is the use of these approaches across an organization, including facilities management, HR, procurement, legal, and any other department that delivers services. We all need to manage incidents and problems, fulfill service requests, and engage with customers. By using common tools, processes, and approaches we can deliver better services across an entire organization.

Effective ESM is not just deploying IT service management tools for use by other departments, but involves collaboration and learning across the organization. Often the IT department has as much to learn as it has to share.

ITIL Practitioner

The latest addition to ITIL is the ITIL Practitioner Guidance, published in January 2016. This publication supports many of the ideas described in this blog.

ITIL practitioner describes nine guiding principles

• Focus on value
• Design for experience
• Start where you are
• Work holistically
• Progress iteratively
• Observe directly
• Be transparent
• Collaborate
• Keep it simple

It also discusses three core competencies

• Metrics and measurement
• Communication
• Organizational change management

All of these are described in the context of continual improvement of IT services.

If you want to learn more about ITIL practitioner then I recommend reading the ITIL Practitioner Guidance and taking a training course. You might also be interested in this review of ITIL Practitioner by my good friend Stephen Mann.

In conclusion

IT service management has helped IT organizations change from being providers of technology to being providers of value-creating services. We can’t stop there though, if we offer a 1990s solution to the problems of the 21^st century, then we’ll rapidly become irrelevant.

Everyone who delivers or supports IT services needs to keep abreast of new approaches and adopt new ideas that will increase the value they provide to their customers. Some of the concepts you should think about adopting are described in this blog, but there are many more that are also relevant. I’m a fan of Kanban, Cobit 5, and Resilia – which other practices do you think we should all consider?

You can find out more by keeping abreast of ongoing discussions on social media

• Twitter #ITSM
• Facebook Back2ITSM group

And by attending IT service management events run by itSMF, HDI, ISACA, and others.

Image Credit

If you are looking for popular ITSM articles, please consider these:

• The Software Request Process – What Does Good Look Like?
• Service Desk Basics: What to Do When the End User Doesn’t Respond?
• Using ITIL 4 to Manage Risks
• ITIL Service Portfolio Management and Its Benefits Explained
• ITIL 4 Dummies

Want more? Here’s an article on the ITIL 4 service desk.

Want even more? Here are informative ITIL 4 service value system and ITIL 4 service value chain articles.

What is ITSM?

ITIL 4 Explained

What is ITIL?

Which ITSM Tool? Here’s an ITSM Tools List

Enterprise Service Management Explained