Embrace an opportunity for some serious CSI

IT Service Management (ITSM) is not about the tools or the technology, but about delivering value to your customer through the use of that technology. The rapid advancements in hardware and software may have shifted the conversation onto what technology makes possible, but that’s not really the issue. A service provider might be using the most advanced tools for testing, delivery pipeline management, infrastructure management or monitoring, but if their customers don’t receive what they need, in the way they need it and when they need it, the value of what is delivered is questionable - and so is the service provider’s future.

While this might be easy to agree to on an intellectual level, it can be difficult to reach a common understanding of what that value is. As Mark Schwartz writes in his recent book, The Art of Business Value, “Ultimately, it turns out that business value is what the business values, and that is that”. There is no magic formula that defines value for every service provider and for every customer. Value is highly context-dependent and needs to be assessed, collaboratively, by the service provider and their customer. In ITIL®, the concept of value focuses on the three components of value (business outcomes, preferences, and perceptions) and positions it in the context of services, distinguishing between utility (fitness for purpose) and warranty (fitness for use). This is discussed in more detail in ITIL Service Strategy1 and ITIL Practitioner2.

For a service provider to be a good one, they need to understand what their customers consider valuable. Understanding this alone is not enough, of course. One of the main differentiating factors between service providers is their ability to combine available capabilities (e.g. experience, people’s skills, and processes) with available resources (e.g. infrastructure, applications, and funding). What was fit for purpose and fit for use yesterday might not have the same value today. Most service providers support their customers in the achievement of their desired outcomes, but the difference in the value delivered by high performing organizations versus low performing organizations can be several orders of magnitude.

The world of startups has provided us with a wealth of insight into how to mash up technologies to best serve our customers. Without the restrictions of ‘this is the business we are in’, startups have been able to combine the latest technologies in the creation of amazing solutions, frequently going far beyond what was considered possible. And, if the first stab at a new business model is not successful, it is easy enough to pivot and disassemble the capabilities and resources, and reconfigure them for another attempt. There is plenty of funding available, as well as plenty of ideas. The trick is in the execution.

When the speed of innovation trumps stability, there is rarely room for hand-offs between teams. Quick response times is key, both in terms of technology (was the change successful?) and customers (was the new feature useful?), as the companies perpetually redefine themselves and their business models, achieving new heights and bringing their customers along for the ride.

A significant part of that experience is captured in the DevOps movement, which takes a critical look at existing practices and does its best to remove unnecessary procedures and components. For many who have worked in the IT industry for some time and are familiar with ITSM, DevOps provokes mixed feelings. On one hand, the DevOps way of doing things, as described in many conference presentations and blog posts, can sound on first hearing, reckless, or downright dangerous. On the other hand, it raises the question – what is all the fuss about, because much of it sounds common sense? But most importantly, the question ‘what does it mean for me?’ needs an answer.

As DevOps author and authority Gene Kim recently wrote, the worlds of ITIL and DevOps are well aligned. But, saying that ITIL and DevOps fit together is not to say you should ignore the lessons from DevOps and continue working as you were without reassessing your current practices. The DevOps movement presents us with a fantastic opportunity for a major step in continual service improvement. The focus is not so much on the ‘what’ – the capabilities of event, incident, change, configuration management etc. are as important as ever. What has changed, and changed significantly, is the ‘how’. And, more than ever before, as an industry, we are willing and able to take advantage of this opportunity.

Our goal at AXELOS is to help individuals and organizations become more effective. Historically, ITIL – being a framework rather than a method – has seldom gone into the detail of ‘how’. It leaves it up to the organization, with guidance, to identify the most appropriate ways of achieving their objectives. In the months to come, we will explore various DevOps topics in conversation with industry experts, and publishing practical guidance on how ITSM professionals can leverage new methods, technologies, and new ways of working to make the most of ITIL, and further improve the value of their services for the benefit of their customers.

Comments

I think sometimes the customers get caught up in various gadgets I think they for get about the purpose. It is our responsibility to assist them in finding the right (best)application/tool (gadget) to meet their need(s).

Great article. I'm in line with you Russ that we must orient and guide the people to successfully walk the right path but it's also true that tools are there to enable processes thus to be designed/implemented first then choose a tool tat enables it.Thanks!