Value is what the customer decides it is. Not what the IT department decides, not what a framework says, not what a tool measures. It’s the point Stuart Rance keeps coming back to, in different forms, throughout his episode of Conversations with Giants with Roman Zhuravlev. That service management (and IT service management (ITSM)) is all about delivering value.
Stuart was one of the architects of ITIL 4 and co-author of ITIL Practitioner, and he’s been working in service management for more than three decades. His conversation with Roman moved across configuration management, tooling decisions, principles-based leadership, and the arrival of AI, but every answer came back to the same question: who’s this work delivering value for?
The CMDB nobody used
One of Stuart’s consulting engagements was with a client who wanted to improve how they managed configuration data. Their configuration manager was strong, with a full team, a solid tool, proper processes, and a carefully curated CMDB. The data was clean. Nobody was using it.
Stuart’s advice to the configuration manager was to go and find the people meant to be using the CMDB, and to ask them what they needed, where they were currently getting the data from, and whether what the configuration team was producing was any good to them. It’s the same point Mark Smalley made in the first episode of this series.
In Stuart’s words: “Why don’t you find the people who ought to be using what you’re doing and find out what they are doing instead, and what they value?” The configuration manager hadn’t thought to do it. He’d been running the practice as a complete, self-contained activity, and nobody had asked him to look outside it to look at delivering value.
It’s the same pattern behind almost every tool replacement project in service management.
Tool replacement projects
Stuart’s blunt about the kind of engagement he’ll refuse unless he can change the shape of it. “I’ve been involved in a number of projects where the original client intent was we need a new service management tool, we need help choosing a tool and then configuring and installing it. And I hate those projects, because that’s not going to make any value.”
It’s a cycle most people in service management will recognize. An organization is using a tool that was badly configured and is barely used. Leadership concludes the tool’s the issue. They fund a replacement. Three years later, the new tool is also badly configured and barely used, and the same conversation begins again. The tool was never the issue. The issue was that nobody had asked what value the tool was supposed to create, or for whom.
When Stuart agrees to work on one of these projects, he tries to rebuild the brief so it’s about delivering value. Sometimes that means bringing additional business units into scope. Sometimes it means going back to the business and asking what they wanted the project to change in the first place.
The test is never whether the replacement is technically better than what came before. The test is whether anything visible happens on the other side of it, for the users, for the customers, or for the business.
When people complain that their change process isn’t working, their incident practice is failing, or their configuration data isn’t being used, the reflex is to reach for a new tool, a new framework, or a new process. Stuart’s argument is that you need to start earlier. Before you pick the tool or write the process, someone has to decide what value the organization’s trying to create, and give the people doing the work enough autonomy to figure out how. Which is where it’s a good idea for guiding principles to come in.
ITIL guiding principles and delivering value
Stuart rates ITIL Practitioner as one of the two publications he’s proudest of contributing to. It was the book that introduced the guiding principles, which later became one of the foundations of ITIL 4’s service value system.
Stuart put it this way: “Moving away from telling people what to do, here are the processes, to telling people how to set principles and share them with their teams so that they could make good decisions.”
Stuart gave an example from a change enablement engagement. The client wanted to improve how changes were reviewed and authorized. Rather than writing a new universal process, Stuart got permission from management and went to each individual team that initiated changes. He asked every one of them the same question: what method of working would be best for you to achieve the goals that your management wants?
The result was a different change model for every team. Every one of them produced the same outcomes management had specified, and every one of them had been shaped by the people using it, which meant they had reasons to use it properly and were delivering value.
“That’s listening to people and letting them influence the work they do,” Stuart said. “It’s not cynically manipulating them. It’s making sure they know what you’re trying to achieve, and that they can then tell you how best to achieve it for them.”
Principles scale in ways prescriptive processes can’t, because a team that understands the goal and has been trusted to design the route will produce a better outcome than a team following a universal playbook written by someone who’s never met them. They’re also the only way of working that has any chance of holding up when the organization encounters something they’re not overly experienced in. Which, in 2026, mostly means AI.
AI, the right use and the wrong use
Taking note of all the ITSM vendor marketing flying around at the moment, it seems every vendor has AI on their materials, with agentic AI the latest focus. Stuart’s concern isn’t with AI itself. It’s with the goal the technology gets deployed to serve. There are two very different versions of that goal, and they produce two very different outcomes.
The version Stuart’s worried about, and he’s far from alone in this, is AI deployed to reduce headcount. He spoke as a consumer rather than a consultant: “I get really frustrated when I’m faced with an AI agent and I say to it please let me talk to a person and it just goes off. I hate it. And so do most of the people I know.” His conclusion: “We need to be really careful with how we introduce agentic AI into our service management tools to make sure it’s done to increase the value we deliver, not just to reduce the head count.”
The version he’s positive about uses AI to absorb the kind of tedious analytical work humans can’t do well at scale. Stuart talked about organizations pulling together their monitoring data, their customer feedback, their user feedback, and everything else they’ve got, and putting AI on top of it to look for correlations and surface what looks interesting. For incident management, major incidents, trend identification, and spotting improvement opportunities, this is AI used well: the pattern-matching work goes to the machine, the decisions stay with the team.
The technology’s the same in both cases. What’s different is the goal it’s been deployed to serve – delivering value. Deploy AI to make customers’ lives easier and the service management team more effective, and you’re delivering value. Deploy it to cut support costs while ignoring the experience the customer ends up with, and you’re making the same mistake as the organization that keeps replacing its tool every three years.
The argument running through all of it – delivering value
At the end of the interview, Roman asked Stuart what advice he’d give people who are new to service management. Stuart gave two pieces of advice. First, assume what you’re doing today won’t be relevant in five years, and spend time now thinking about what you’ll be doing next. Second, where you can, try to make what you do no longer necessary. “There’s the people who hoard their knowledge and try to make themselves indispensable,” he said, “and I find them really difficult to work with. And there’s the people who share what they’re doing, automate everything they possibly can (that makes sense), and try and make their current job no longer needed and move on to the next thing.”
It’s the same argument he’d been making throughout his entire conversation with Roman, just turned inward on a career. Every example he gave is a version of the same question: is the work delivering value for someone other than the person doing it?
The configuration manager with the unused CMDB has no one asking for what he produces.
The tool replacement project that ends in the same place three years later is simply costing the organization more time and money and nothing else.
The AI deployment that cuts headcount while the customer’s experience gets worse is producing savings that disguise a loss.
The career built around making yourself indispensable is producing security for one person at the expense of everyone around them.
Every one of those is activity that looks productive from the inside and produces nothing of value from the outside. Stuart’s thirty-year career has been spent making the same point: service management that produces no value for the people on the receiving end of it isn’t service management, it’s just busy work.
Further Reading
Sophie Danby
Sophie is a freelance ITSM marketing consultant, helping ITSM solution vendors to develop and implement effective marketing strategies.
She covers both traditional areas of marketing (such as advertising, trade shows, and events) and digital marketing (such as video, social media, and email marketing). She is also a trained editor.
