What should developers know about IT Service Management?

I often work with developers and others involved with developers, and often get into discussions about what “ITSM” covers and what—if anything—they ought to know about it.

This post is aimed at developers (and team leaders and scrum masters and managers), and business analysts, and project and programme managers, in the hope that it may help—or at least stimulate discussion. Comments welcome of course from ITSM specialists, especially if you think I’ve misrepresented something.

So what is IT service management? In a nutshell, it’s what has to happen to the development product after it’s deployed and goes live.

And what do developers need to do about it? In a nutshell, don’t ignore it until deployment. Don’t just provide a demo to the support desk at deployment time. And don’t try to do it all in isolation from existing service management teams and duplicate existing capabilities.

It’s not doing anything, it’s just sitting there!

Over the years I’ve told a number of people how I got into service management (or possibly, bored anyone who will listen).

ITIL is a set of design patterns

ITIL

People who’ve spent any time with IT service management will be more or less familiar with ITIL – “the most widely accepted approach to IT service management in the world” (ITIL | AXELOS) (Decent Wikipedia article.) And people who’ve spent much time with ITIL will probably be familiar with the phrase “adapt and adopt”, and the recognition that ITIL isn’t a standard, just a library of good practices.

But still there’s a tendency to see ITIL as a monolithic block of processes and organisational recommendations, which all organisations should strive to adapt a little bit and implement in full, subject to reaching some flexibly-defined level of “maturity”. And this can in practice put people off getting the real value out of ITIL.

It is the best library of good practices we have, but it is not as cohesive and internally consistent as it aims to be, and falls short of being a management approach. Numerous authors, such as the IT Skeptic, have written extensively about the limitations.

Design patterns

People who’ve spent time in development, especially agile development methods, will be familiar with the concept of Design Patterns – generally reusable solutions to commonly occurring problems within specific contexts, as popularised by the 1995 book “Design Patterns: Elements of Reusable Object-Oriented Software” (Amazon). (Wikipedia; some links to pattern catalogues.) Terms like “decorator” or “factory method” are now parts of everyday development language, as “CMDB” or “SLA” are in ITSM.

For those who may not be familiar with the concept, I’ll outline the essential features (as I understand them – I am not an expert) below, with the parallels with ITIL.

Don’t forget the steering wheel

Someone recently said to me that the need to manage the customer’s experience of a service once it’s been delivered often seems to get forgotten. And I was reminded of this illustration I put in a presentation some years ago.

Service management is usually an afterthought

Yes – that’s vintage 1990s PowerPoint clipart.

You wouldn’t sell or hire out a car without a steering wheel and dashboard instruments. As a customer you wouldn’t expect to hear “But it does 0 – 60 in 7 seconds with a top speed of 115. And it complies with government emissions standards (no … not just under lab conditions). The documented requirements didn’t say anything about the end-user being able to control the direction or receive reports on the actual speed.”

So why is this so common with software and with technology services?

And why is this still an issue after 20 or 30 years?

Now in the United Kingdom

I am now active and consulting in the United Kingdom!

This is a return home for me – I’ve been working in Africa as an expat for the last 17 years. Based in London currently, but still busy with sorting out arrangements. There’s quite a lot to do even when you are already a citizen of the country.

More posts on ITSM matters to follow.

let’s get this rolling again

OK then … before this blog gets to be six months stale, let me add a placeholder post.

I’ve started a new contract – one that looks like being a long term one – and it’s taken pretty much all of my attention. I’ve ignored LinkedIn, industry news, other blogs and so on, let alone my own blog.

More than one person has described what we are doing as organised chaos – and part of my role is to create structure (architecture, specifically) out of this chaos. Currently the chaos is winning! – new bits of it arrive faster than I can structure whichever bit I’m thinking about. But the potential, when the solution is built, is huge: a large-scale multi-sourced IT service, with ITIL in a rather pure form, service catalogues, the works.

As my boss says, you learn the most in your career in the jobs that bring the most pressure.

But for me, I only feel that I’ve learnt it when I’ve reflect on, analysed and synthesised the experiences. And that’s what blogging should be for.

Start ITIL with Continual Service Improvement

People often ask which part of ITIL companies should implement first. They very often get the (correct) answer that you don’t implement ITIL, you use it to improve your service management. But that’s really just rephrasing the question: which part of ITIL should companies use first to improve their service management?

Terminology and Taxonomies

This is fun: Vinod Agrasala is refining terminology such as Purpose, Goal and objective, Policy, Process & Procedure, Standards & Guidelines, and Assessment, Gap analysis and Audit; and the IT Skeptic is looking at the taxonomy of ITIL V3 Incidents and a list of Request Classes (caution: with all the comments those pages are around 8,000 and 3,000 words).

Vinod:

I am in a focused drive of differentiating between confused terms

The Skeptic:

I think ITIL V3 muddies the definition of Incident, and of Incident Management.

People – Process – Technology – The eternal triangle

The eternal triangle of “People, Process and Technology” is tired and overworked, especially in marketing literature. In itself, these facts don’t make it wrong. But is it good enough?

It’s usually invoked to back a claim that there’s more to consider than just [whatever it is that is already being considered – often a technical product]. And this is nearly always a good thing. Obviously each of the three words embraces a number of related concepts – for example, a consideration of people requirements should bring in questions of skills and motivation as well as sheer numbers of people. But can the triumvirate of People, Process and Technology claim to be everything there is to consider?

.

Information

One thing I think is missing is the dimension of information or data. (Information and data are not the same thing, but we can understand them living on the same dimension, along with knowledge and wisdom. As does content, the term favoured in web-enabled business-to-consumer areas.)

Some people seem to regard information as a detail of technology, but I believe this view leads to incomplete solutions – in other words, information is very definitely something more to consider.

10 Reasons Why Strategic IT Management Initiatives Fail

Dennis Drogseth has published an article 10 Reasons Why Strategic IT Management Initiatives Fail on CIO Update.

Now, I agree with every one of his ten reasons, but I immediately thought of some different angles on the approaches he recommends …