I’ve been involved in IT service management (ITSM) since the 1970’s, and I’ve seen many changes since then. Here’s my summary of where ITSM 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 ITSM, and I certainly didn’t think of what I was doing as incident management or problem management.
ITIL in the 1990s
In the mid-1990s I came across ITIL (the leading best practice framework for ITSM), 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 rigour 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 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 a 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 realised 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 organisation 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 ITSM 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?
Meanwhile ITSM is moving on again. The world of software development has adopted ideas such as Agile and DevOps and many people in ITSM are recognising 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 ITSM. I don’t have the 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 emphasised 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 ITSM. They are changing ideas about the best way to approach implementing and improving ITSM (no more multi-year ITSM projects); and about the best way of supporting customers (individuals and interactions over processes and tools).
Lean
Lean is a management approach which emphasises 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 ITSM 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 judgement 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 judgement 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. ITSM 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 judgement across the whole of the end-to-end process.
Enterprise Service Management
Many of the ideas, tools, and processes that have developed to support ITSM 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, fulfil 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 ITSM 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
ITSM 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 21st 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
And by attending events run by itSMF, HDI, ISACA, and others.Image Credit
