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?
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.
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.
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.
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:
- No customer support
- Time constraints
- 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.