Technology and technology people are strange and fickle. We like to play with our toys and “techy things.” We like to use models, frameworks, and systems (each with its own landscape and jargon). We spend a lot of time agonizing over and then eulogizing “management,” “processes,” and “governance,” often interchangeably, in a way that suggests that no person, organization, or group of people has ever come across or dealt with these issues and concepts before. And, bizarrely, we seem to be highly susceptible to the perils and traps of marketing hype, stuck in a whirring blender of innovation, fad, doom, change, and irrelevance.
Technology is fast-moving, certainly, and it’s constantly at the mercy of disruption and new ideas, compounded by the ever-increasing demand for new things and the speed at which innovation must be brought to market. Of course, we need to keep ahead of the game as much as possible and look to the future, but I also think that sometimes we forget to do even the most basic things well enough to learn and make the most of future opportunities.
Future-proofing is of no value if the present is in disarray. Rather than searching for the next big thing that might solve our problems, whatever they are, we need to take stock of the universal service management principles we have now and apply them to what we’re doing today. My observation from twenty years of consulting in the ITSM space is simply this:
- We keep trying to cope with new things that might never happen, or that we can’t change. Meanwhile, we’re not delivering now.
- We need to focus on getting better at doing some basic things really well and building on that. Otherwise, we risk fulfilling the “ITSM is dead” prophecy before it’s been made.
So, what can we do to keep current and build more long-term quality into the services we deliver?
Let’s look at just one aspect of ITSM: continuous service improvement (CSI). In recent years, CSI has evolved from an afterthought into one of the leading drivers and areas of focus for service management. In simple terms, CSI means ensuring ongoing success and constant improvement by building reviews, checks, and metrics into processes and operations, and then using that data to provide targets and identify areas for development.
CSI gets a lot of press these days, but I still don’t find it to be particularly well defined or well implemented across organizations. ITIL’s official CSI book contains a list of very useful and relevant suggested metrics and things to measure (for my money, this is one of the most practical features of the current ITIL oeuvre), but the book itself is part of the problem: it’s a separate book (CSI) in a separate framework (ITSM) in a separate discipline (IT). IT people like to put things in boxes, and quite often major strategic areas get treated like manuals for a new programming language or operating system. The fact that CSI has been treated like a manual condemns it to failure: either it’s made the responsibility of someone who isn’t in a position to make it work, or it’s abandoned for being too difficult.
CSI should be a culture—it should be intrinsic, not just something that we switch on at the end of a project. It’s an action (continuous improvement), not a thing; it’s about how we do things and why. And however we choose to pursue CSI, we must make sure we’re in line with our organizations’ goals and taking coherent action to improve our services. In practical terms, this means:
Talking to our customers and showing them that we’re listening to their needs. We need to have a clear understanding of their requirements, and we need to establish solid and trusting business relationships that can transcend functional SLAs. Our customers’ input is essential, lest we spend time improving our services only to find out that those improvements are irrelevant to our customers.
Understanding what “the service” is and what about the delivery of that service is important to our customers. We can’t “do” CSI if we don’t have a clear understanding of what the service is, does, and requires (in terms of delivery) from the perspective of the customer, the manager, the business owner, the service delivery owner, the technical owner, etc. We should also be able to demonstrate this understanding in actions, words and language that are meaningful to the customers and businesses we support.
Ensuring that we have appropriate levels of investment and resources in place to deliver the right levels of service. If we want to be competitive and cost-effective (and we do), then we need to understand the costs and constraints of service delivery.
Having an organizational culture wherein everyone takes responsibility for the resolution of long-term issues. It’s not just “those guys who keep messing up.” It’s our problem and we need to resolve it. This often requires special hybrid skills, like combining analysis with project management to ensure that solutions are consistently identified and delivered.
Embedding our practices and processes and using data to compare the service’s performance to targets and expectations. We should be able to articulate this understanding in terms of how we define the priorities, targets, and metrics related to each service.
Engendering an open and supportive culture for all our people, so that self-awareness leads to self-improvement. Use issues as transparent and blame-free opportunities for improvement, for both individuals and teams. Organizations need to create safe environments where their employees are comfortable speaking up and identifying issues—even if these cross management lines or appear to question individual performance.
Promoting our successes and finding new ways to market them. It’s imperative that we not only deliver but also demonstrate value. Otherwise we’re only as good (in perception) as our last contact (good or bad).
These steps are all pretty straightforward; if your organization has already taken these steps, then you’re probably doing pretty well. The point here is that CSI is an integral part of these steps, not an additional component, and it requires a certain level of engagement, commitment, and positive attitude from everyone in the organization, at all levels, if we expect it to work. It’s a bit like what we used to say about total quality management (TQM) in the 1980s and business process engineering (BPE) in the 1990s: they’re useful and worthwhile activities, not to be viewed or implemented in isolation.
The bigger point here is that we’ve compartmentalized certain key activities—ITSM, service design, service desk, SLAs, etc.—in the same way that we’ve divided up our technical activities. All of these technical and process and quality-based activities are part of delivering services to our customers, and we need to view them holistically. Otherwise, we’re just delivering commodity components, not a proper “supply chain” of services.
For CSI, in particular, we shouldn’t ignore the useful metrics in the CSI book, but we should try to see them in a wider perspective, and we should make sure our goals are clear across the organization. We’re all responsible for CSI, just as we’re all responsible for problem and incident management, customer relationship management, teamwork, promoting the values and successes of our department, etc. So, rather than trying to take some new-fangled approach to changing our culture, processes, or behaviors, we should be focusing on doing a few basic things really well—and actually succeeding!
Let’s not “just do” CSI, let’s be excellent!
Barclay Rae is an experienced ITSM mentor and business manager. Over the past twenty-five years, he’s worked on approximately 400 ITSM projects; for the past ten years, he’s run his own consultancy company, e2e. Barclay advises organizations on their ITSM, mentoring, and business development strategies, focusing on service desks, service level management, and the service catalog. Barclay hosts ITSMTV and the “Service Desk Inspector” series, and he participates in the weekly “ITSM Rest of the World” podcast.