Rob England: "What is Service Management?"

Tenuous link: One of Rob's passions outside of ITSM is trains. The ITSM Review offices are in sunny Swindon in the UK, home of Isambard Kingdom Brunel's workshops which powered the Great Western Railway.

Editor’s Note: We are very pleased to welcome Rob England (a.k.a The IT Skeptic) as regular columnist at The ITSM Review.

Service Management

Railways provide a useful analogy for understanding what service management is and how it works.

What is a railway for? (or “railroad” for our American readers)

If you said “to move people and/or goods” you are only partly right.  On the right track (pun intended) but not there yet.

How should it move goods and passengers?  With maximum quality?  Or at minimum cost?  The answer to that is “it depends”.  It depends on what the customer wants.

A customer is one who pays for the service of the railway.  That isn’t always the same as the one who buys the ticket or books the freight.  Many railways receive public funding, so the government or other body is effectively also a customer: they are paying for part of the service.  Not all customers are users of the services.

The railway is answerable not only to its customers.  It is also answerable to its owners and the governors they delegate authority to.  The owners may not want the same things as the customers at all.  For example, railways are often required to provide a passenger service as a requirement of gaining the right to operate.  These passenger services are often unprofitable: the money is in the freight services.  Guess how often such passenger services meet the needs of the paying ticket-holders.

So a railway exists to provide a service that moves people and/or goods to meet the needs of its governors and customers.

Your are in the service business

If you were operating a railway, what activities would you have to manage in order to ensure you meet the needs of your governors and customers?  There would be some activities that are unique to railways, such as scheduling, servicing rolling stock, dispatching trains and so on.  But the bulk of the activities involved in operating a railway are the same as operating any business: reporting, financials, HR, marketing, IT, procurement… and delivering your services.  It doesn’t matter whether an organisation’s services are transporting goods, providing accommodation, building houses or catching fish.  They all serve customers and they all perform a similar set of activities to manage that service.

Whether you build roads or map them, operate ports or use them, build houses or sell them, plan weddings or sing at them, care for kids or clothe them, sell PCs or scrap them, you are in a service business, even if you may not be in a “service industry”.

We aren’t talking about over-the-counter “may I help you?” service, how to develop the customer service interface, the experience of contact.  Service Management is about the end-to-end process of providing services.  It covers such things as:

Service management activities Rail examples
Delivering Executing a service for users Food service, engine drivers, shunters
Operating running the infrastructure that makes the services work Signaling, track maintenance, security guards
Supporting Responding to user requests for service or help, and resolving them Ticket sales, call centre, guard, repair crews
Cataloguing Providing information about what services are available Timetables, websites, brochures
Customer relations Maintaining relationships with customers Customer account managers, sales, public relations
Measuring Monitoring and reporting service metrics Punctuality, traffic volumes, profitability
Planning Proposing, choosing and strategising new services, improvements and retirements Routes, trains, schedules, freight deals, specialised cars e.g. refrigerated)
Designing How the service will work, what infrastructure it needs Developing  anew schedule, specifying new equipment
Building Creating the infrastructure, mechanisms, and processes to deliver a service Ordering or constructing new rolling stock, laying track, hiring and training staff, printing collateral
Implementing Rolling out the new service, going “live” Commissioning new rolling stock, publishing new or changed schedules, deploying staff, rolling trains
Assuring Protecting the organisation, its staff, customers and users.  Making sure the service is safe for people, compliance and profits. Track safety programmes, risk register, ticket inspection, financial and quality audits
Improving Making service better: identifying, planning and managing improvement to efficiency and effectiveness Quality programme, cost control, regular maintenance schedules
Governing Direct, monitor and evaluate the management and execution of the services Corporate vision and goals, high-level policy, risk profile, annual report

Service Management says the most important thing you do is deliver services to your customers.  Moreover, everything you do should be considered in terms of the services you provide to your customers.

‘Outside-In’ Thinking

Adopting a service management approach can have a profound affect on the way your business works and your staff think.  It takes us away from that introverted, bottom-up thinking that begins with what we have and what we do and eventually works its way up and out to what we deliver to the customer.  Instead, with service management we change our point of view from concentrating on the internal “plumbing” of our business, moving instead to a focus on what “comes out of the pipe” – what we provide.  We take an “outside-in” view.  Starting from this external perspective we then work our way top-down into the service organisation to derive what we need and what we have to do in order to provide that service.

Service management isn’t one subset of the business; it is not one activity at the end of the main supply chain.  It is a different way of seeing the whole supply chain, the whole business that produces the services, by seeing it initially from the outside, from the customer’s point of view.  Therefore any discussion of Service Management may stray into general business management topics.

Seeing our business in terms of the services it provides can’t help but make us better at providing them.

To a customer, “better” means more useful and more reliable, i.e. more valuable and better quality.  

From the service-provider’s point of view, “better” means more effective and more efficient, i.e. better results and cheaper.  

Follow along in this series of articles as we look at Service Management through the lens of railways and how they operate.  We hope it will provide a fun and useful way to understand this thing called Service Management.

© Copyright 2012 Two Hills Ltd.

How to Provide Support for VIPs

One of the outcomes of IT Service Management is the regulation, consistency and predictability in the delivery of services.

I remember working in IT before Service Management was adopted by our organisation and realising that we would over-service some customers and under-service others. Not intentionally but we didn’t have a way of regulating our work and making our output predicatable.

Our method of work delivery seemed to be somewhere between “First come first served” and “She who shouts loudest shall get the best service”. Not the best way to manage service delivery.

Chris York tweeted an interesting message recently;

It’s a great topic to talk about and one that I remember having to deal with personally in previous jobs.

I have two different views on VIP treatment – I think it’s a complex subject and I’d love to know your thoughts in the comments below.

if your names not down you're not getting support
if your names not down you're not getting support

The Purist

Firstly IT Service Management is supposed to define exactly how services will be delivered to an organisation. The service definition includes the cost, warranty and utility that is to be provided.

Secondly, there is a difference between the Customer of the service and the User of the service. The Customer is characterised as the people that pay for the service. They also define and agree the service levels.

Users are characterised as individuals that use the service.

There are loads of great analogys to reinforce this point – from local government services that are outsourced (The local Government is the customer, the local resident is the user), to restaurants and airports. The IT Skeptic has a good discussion on the subject

It’s also true to say that the Customer might not also be a user of the service, although in organisations I’ve worked in it is usually so.

This presents an interesting dilemma for both the Provider and the Customer. Should the Customer expect more from the service than they originally negotiated with the Provider? I think the most common example that this dilemma occurs is end-user services – desktop support.

The people that would “sign on the dotted line”for the IT Services we used to provide would be Finance Directors, IT Directors, CFOs or CIOs. Very senior people with responsibility for the cost of their services and making sure the company gets a good deal.

Should we be surprised when senior people that ultimately pay for the service expect preferential treatment? No – but we should remind them of the service warranty that they agreed would be supplied.

Over-servicing VIPs has to be at the cost of someone else – and by artificially raising the quality of service for a few people we risk degrading the service for everyone.

The Pragmatist

The reality is that IT Service Management is a people business and a perception business, especially end-user services.

People call the Service desk when they want something (a Request) or they need help (an Incident). Both of these are quite emotional human states.

The performance and usability of someones IT equipment is fundamental to their own productivity and their own success. It feels very personal when your equipment that you rely on stops functioning.

Although we can gather SLA and performance statistics for our stakeholder meetings we have the problem that we are often seen as being as good as our last experience with that individual person. It shouldn’t be this way – but it is.

I’ve been to meetings full of good news about the previous months service only to be ripped to pieces for a request submitted by the CEO that wasn’t actioned. I’ve been to meetings after a period of general poor service and had good reviews because the Customer had a (luckily) excellent experience with the Service desk.

Much as we don’t like it prioritising VIP support it has an overall positive effect when we do.

The middle ground (or “How I’ve seen it done before”)

If you don’t like the Pragmatist view above there are ways to come to a compromise. Stephen Mann touched on an idea I have seen before:

Deciding business criticality is obviously a challenge.

In my previous role, in the advertising world, the most important people in an agency are the Creatives.

These guys churn out graphical and video content and work on billable hours. When their equipment fails the clock is ticking to get them back up and running again.

So calculating the financial cost of individuals downtime and assigning a role is a method of designating those that can expect prioritised support.

As a Service Provider in that last role our customer base grew and our list of VIPs got longer. We eventually allocated 5% of each companies headcount to have “VIP” status in our ITSM tool.

I think there are ways to write VIP support into an IT Services contract that allows the provider to plan and scale their support to cater for it.

Lastly, we should talk about escalated Incidents. This is a more “formal” approach to Service Management (the Purist would be happy) where a higher level of service is allocated to resolving an Incident if it meets the criteria for being escalated.

When dealing with Users it is worth having a view of that persons overall experience with the Service Provider. If a user already has one escalated Incident should she expect a better service when she calls with another? Perhaps so – the Pragmatist would see that although we file each Incident separately her perception of the service is based on the overall experience. With our ITSM suite we use informational messages to guide engineers as to the overall status of a User.

Simon Morris
Simon Morris

In summary…

I think everyone would agree that VIP support is a pain.

The Purist will have to deal with the fact that although he kept his service consistent regardless of the seniority of the caller he might have to do some unnecessary justification at the next review meeting.

The Pragmatist will have to suffer unexpected drain on her resources when the CEOs laptop breaks and everything must be focussed on restoring that one users service.

Those occupying the middle ground will be controlling the number of VIPs by defining a percentage of headcount for the Customer to allocate. Hopefully the Customer will understand the business well enough to allocate them to the correct roles (and probably herself).

The Middle Ground will also be looking at a users overall experience and adjusting service to make sure that escalated issues are dealt with quickly.

No-one said IT Service Management was going to be easy!


'Basic Service Management' by Rob England (a.k.a The IT Skeptic)

Basic Service Management by Rob England

This is a quick review of Rob England’s book ‘Basic Service Management’.

You can find out more about Rob’s book and the TIPU method here: www.basicsm.com. If you want to share your own review please add a comment below.

In my opinion this is a well written introduction to service management.

This book might have also been called:

  • ‘Service Management in a nutshell’
  • ‘An introduction to Service Management’
  • ‘Service Management for Business Owners’
  • ‘The book on Service Management that you buy for your boss’ or
  • ‘How to introduce someone to service management without scaring the bejesus out of them by banging on about ITIL or other IT geekery’

I read this in one sitting and I’m not a fast reader. It is quick, accessible and thought provoking.

It is not an ITSM or IT book per se, in fact I think the best recipient of this book is a non-IT business owner or service owner who wants to appreciate the benefits of service management.

As an ITSM professional, this is the sort of book you need to send to those you wish to educate and influence about your chosen profession. Or as one Amazon reviewer put it: “I recommend reading it before you get lost in ITIL”. This would also be useful to an entrepreneur looking to start or scale their business.

Why Service Management?

“If you are reading this book, you probably don’t manage your services so much. That gives you an opportunity to increase revenues and profitability: improving your service brings increased efficiency and effectiveness. That means increased returns for much less investment than from improving your products or equipment”.

Rob England, The IT Skeptic

Rob is a great wordsmith and well respected in the ITSM industry – my only criticism of this book is that I wish he had used the power of metaphor, story telling or examples to describe his seven practice areas. The second half of the book tends to slide into a glossary of his basic service management terms and bullet points. I thought this might have been a perfect opportunity for Rob to use some examples in order to reinforce his message and walk the reader through his ‘Seven Areas’ rather than explaining principles in purely theoretical terms.

In the ‘How to Use this Book’ section Rob urges the reader to “Read it, It is short”. In a similar fashion my advice to you as an ITSM professional is, “Buy it, it is good”.

Have you read Rob’s book? Please share your opinion in the comments below.

Links:

Event Listing: Proactive Problem Management, itSMF UK, 8th Feb, London

Chelsea Football Club
Chelsea Football Club

What?

itSMF UK Seminar – Proactive Problem Management

“Problem management is often the most under used process, and is described by some as the “If we only have the time” process. In reality it is a process that if used correctly adds real value to the business, and supports all of the other service management processes. To get there, there is a need to invest both time and resource – the very things that problem managers have little of.

“This seminar is targeted at problem managers who want to improve their approach and understanding of problem management by adopting a more proactive focus in order to deliver more successful outcomes”

When?

  • Wednesday 8th February 2012, 9am – 4pm

Where?

Who?

  • itSMF UK

Agenda

  • ‘Incident, problem and availability management – the new holy trinity’ Vawns Guest, Pink Elephant
  • ‘IT service delivery from a third party – jumping from reactive to proactive’ Mike Evans, ITS & Rich Starkey, Oasis Healthcare
  • ‘Are you communicating problems or having problems communicating?’ John Griffiths, Fox IT
  • ‘Is the cloud a ‘problem’ for problem management?’ David D’Agostino, Service-Now.com

Further Info…

Interview: Simon Morris, 'Sneaking ITIL into the Business'

Ignoring the obvious may lead to a nasty mess

I found Simon Morris via his remarkably useful ITIL in 140 app. Simon recently joined ServiceNow from a FTSE100 Advertising, Marketing and Communications group. He was Head of Operations and Engineering and part of a team that lead the Shared Services IT organisation through its transition to IT Service Management process implementation. Here, Simon kindly shares his experiences of ITSM at the rock face.

ITSM Review: You state that prior to your ITSM transformation project you were ‘spending the entire time doing break-fix work and working yourselves into the ground with an ever-increasing cycle of work’. Looking back, can you remember any specific examples of what you were doing, that ITSM resolved?

Simon Morris:

Thinking back I can now see that implementing ITSM gave us the outcomes that we expected from the investment we made in time and money, as well as outcomes that we had no idea would be achieved. Because ITIL is such a wide-ranging framework I think it’s very difficult for organisations to truly appreciate how much is involved at the outset of the project.

We certainly had no idea how much effort would be spent overall on IT Service Management, but we able to identify results early on which encouraged us to keep going. By the time I left the organisation we had multiple people dedicated to the practice, and of course ITSM processes affect all engineering staff on a day-to-day basis.

As soon we finished our ITILv3 training we took the approach of selecting processes that we were already following, and adding layers of maturity to bring them into line with best practice.

I guess at the time we didn’t know it, but we started with Continual Service Improvement – looking at existing processes and identifying improvements. One example that I can recall is Configuration Management – with a very complex Infrastructure we previously had issues in identifying the impact of maintenance work or unplanned outages. The Infrastructure had a high rate of change and it felt impossible to keep a grip on how systems interacted, and depended on each other.

Using Change Management we were able to regulate the rate of change, and keep on top of our Configuration data. Identifying the potential impact of an outage on a system was a process that went from hours down to minutes.

Q. What was the tipping point? How did the ITSM movement gather momentum from something far down the to do list to a strategic initiative? 

If I’m completely honest we had to “sneak it in”! We were under huge pressure to improve the level of professionalism, and to increase the credibility of IT, but constructing the business case for a full ITSM transition was very hard. Especially when you factor in the cost of training, certification, toolsets and the amount of time spent on process improvement. As I said, at the point I left the company we had full time headcount dedicated to ITSM, and getting approval for those additional people at the outset would have been impossible.

We were lucky to have some autonomy over the training budget and found a good partner to get a dozen or so engineers qualified to ITILv3 Foundation level. At that point we had enough momentum, and our influence at departmental head level to make the changes we needed to.

One of the outcomes of our “skunkworks” ITIL transition that we didn’t anticipate at the time was a much better financial appreciation of our IT Services. Before the project we were charging our internal business units on a bespoke rate card that didn’t accurately reflect the costs involved in providing the service. Within a year of the training we had built rate cards that both reflected the true cost of the IT Service, but also included long term planning for capacity.

This really commoditised IT Services such as Storage and Backup and we were able to apportion costs accurately to the business units that consumed the services.

Measuring the cost benefit of ITSM is something that I think the industry needs to do better in order to convince leaders that it’s a sensible business decision – I’m absolutely convinced that the improvements we made to our IT recharge model offset a sizeable portion of our initial costs. Plus we introduced benefits that were much harder to measure in a financial sense such as service uptime, reduced incident resolution times and increased credibility.

Q. How did you measure you were on the right track? What specifically were you measuring? How did you quantify success to the boss? 

Referring back to my point that we started by reviewing existing processes that were immature, and then adding layers to them. We didn’t start out with process metrics, but we added that quite early on.

If I had the opportunity to start this process again I’d definitely start with the question of measurements and metrics. Before we introduced ITSM I don’t think we definitively knew where our problems were, although of course we had a good idea about Incident resolution times and customer satisfaction.

Although it’s tempting to jump straight into process improvement I’d encourage organisations at the start of their ITSM journey to spend time building a baseline of where they are today.

Surveys from your customers and users help to gauge the level of satisfaction before you start to make improvements (Of course, this is a hard measurement to take especially if you’ve never asked your users for honest feedback before, I’ve seen some pretty brutal survey responses in my time J)

Some processes are easier to monitor than others – Incident Management comes to mind, as one that is fairly easy to gather metrics on, Event Management is another.

I would also say that having survived the ITIL Foundation course it’s important to go back into the ITIL literature to research how to measure your processes – it’s a subject that ITIL has some good guidance on with Critical Success Factors (CSFs) and Key Performance Indicators (KPIs).

Q. What would you advise to other companies that are currently stuck in the wrong place, ignoring the dog? (See Simon’s analogy here). Is there anything that you learnt on your journey that you would do differently next time? 

Wow, this is a big question.

Business outcomes

My first thought is that IT organisations should remember that our purpose is to deliver an outcome to the business, and your ITSM deployment should reflect this. In the same way that running IT projects with no clear business benefit, or alignment to an overall strategy is a bad idea – we shouldn’t be implementing ITIL just for the sake of doing it.

For every process that you design or improve, the first question should be “What is the business outcome”, closely followed by “How am I going to prove that I delivered this outcome”. An example for Incident Management would be an outcome of “restoring access to IT services within an agreed timeframe”, so the obvious answer to the second question is “to measure the time to resolution.”

By analysing each process in this way you can get a clearer idea of what types of measurement you should take to:

  • Ensure that the process delivers value and
  • Demonstrate that value.

I actually think that you should start designing the process back-to-front. Identify the outcome, then the method of measurement and then work out what the process should be.

Every time I see an Incident Management form with hundreds of different choices for the category (Hardware, Software, Keyboard, Server etc.) I always wonder if the reporting requirements were ever considered. Or did we just add fields for the sake of it.

Tool maturity

Next I would encourage organisations to consider their process maturity and ITSM toolset maturity as 2 different factors. There is a huge amount of choice in the ITSM suite market at the moment (of course I work for a vendor now, so I’m entitled to have a bias!), but organisations should remember that all of vendors offer a toolset and nothing more.

The tool has to support the process that you design, and it’s far too easy to take a great toolset and implement a lousy process. A year into your transition to ITSM you won’t be able to prove the worth of the time and money spent, and you have the risk of the process being devalued or abandoned.

Having a good process will drive the choice of tool, and design decisions on how that tool is configured. Having the right toolset is huge factor in the chances of a successful transition to ITSM. I’ve lived through experiences with legacy, unwieldy ITSM vendors and it makes the task so much harder.

Participation at every level

One of the best choices we made when we transitioned to ITSM was that we trained a cross-section of engineers across the company. Of the initial group of people to go through ITILv3 Foundation training we had engineers from the Service desk, PC and Mac support, Infrastructure, Service Delivery Managers, Asset management staff and departmental heads.

The result was that we had a core of people who were motivated enough to promote the changes we were making all across the IT department at different levels of seniority. Introducing change, and especially changes that measure the performance of teams and individuals will always induce fear and doubt in some people.

Had we limited the ITIL training to just the management team I don’t think we would have had the same successes. My only regret is that our highest level of IT management managed to swerve the training – I’ll send my old boss the link to this interview to remind him of this!

Find the right pace

A transition to ITSM processes is a marathon, not a sprint so it’s important to find the right tempo for your organisation. Rather than throwing an unsustainable amount of resource at process improvement for a short amount of time I’d advise organisations to recognise that they’ll need to reserve effort on a permanent basis to monitor, measure and improve their services.

ITIL burnout is a very real risk.

 

Simon Morris

My last piece of advice is not to feel that you should implement every process on day one. I can’t think of one approach that would be more prone to failure. I’ve read criticism from ITSM pundits that it’s very rare to find a full ITILv3 implementation in the field. I think that says more about the breadth and depth of the ITIL framework than the failings of companies that implement it.

There’s an adage from the Free Software community – “release early, release often” that is great for ITSM process improvements.

By the time that I left my previous organisation we had iterated through 3 versions of Change Management, each time adding more maturity to the process and making incremental improvements.

I’d recommend reading “ITIL Lite, A road map to full or partial ITIL implementation” by Malcolm Fry. He outlines why ITILv3 might not be fully implemented and the reasons make absolute sense:

  • Cost
  • No customer support
  • Time constraints
  • Ownership
  • Running out of steam

IT Service Management is a cultural change, and it’s worth taking the time to alter peoples working habits gradually over time, rather than exposing them to a huge amount of process change quickly.

Q. Lastly, what do you do at ServiceNow?

I work as a developer in the Application Development Team in Richmond, London. We’re responsible for the ITSM and Business process applications that run on our Cloud platform. On a day-to-day basis this means reviewing our core applications (Incident, Problem, Change, CMDB) and looking for improvements based on customer requirements and best practice.

Obviously the recent ITIL 2011 release is interesting as we work our way through the literature and compare it against our toolset. Recently I’ve also been involved in researching how best to integrate Defect Management into our SCRUM product.

The sign that ServiceNow is growing at an amazing rate (we’re currently the second fastest growing tech company in the US) shows that ITSM is being taken seriously by organisations, and they are investing money to get the returns that a successful transition can offer. These should be encouraging signs to organisations that are starting their journey with ITIL.

@simo_morris
Beer and Speech
Photo Credit