Workshop Tales for ITSM Planning
In my last blog we looked at some of the things you can do to plan ahead for your IT service management (ITSM) tool implementation – particularly data and project management.
Usually this takes the form of workshops, which are a great way to combine requirements gathering, consensus/team building, and feedback gathering. This second blog is based on some real workshops I’ve been involved with recently and the discussions that took place.
Here are some things to look out for when it comes to ITSM planning, with some (mostly) serious suggestions on how to deal with them:
“We need to have 357 different SLAs.”
This can be a difficult challenge, if an organisation (particularly a Managed Service Provider) has a number of different contracts and associated Service Level Agreements (SLAs) already in place. In most cases the answer to this should be: ”No, you don’t need 357 different SLAs, you probably need about 10 maximum, which will cover 80/90% of your services.“ Success will depend on how you say this…
The issue of course is how to convince people (in a kind and non-confrontational way) that their services are not really that different from the rest of the world. Implementing a new tool is a great opportunity to streamline how you do things and also to reduce unnecessary duplication and manual work.
So the project should be an opportunity to do things differently and not “just the way we’ve always done them”. This includes SLAs, the great majority of which in my experience are not set correctly in the first place.
“Why am I here? This is for the Service Desk.”
Ah, the old ones are the best. Okay, the product may have a strong focus around Service Desk, support, and operations, but that doesn’t mean that other teams are not required to be involved. Service and support are a supply chain and this is a great opportunity for collaboration.
I am still amazed, as well as regularly irritated, when I hear this, or worse still when people invited or even mandated to attend these sessions, simply don’t turn up – effectively giving out the message that they don’t care or see this as being of value.
I always make sure I find a way to make their management aware of this and the real benefit that can be achieved for them and their teams from participating. If this doesn’t work I move to what I call the ‘Lencioni position’ – I demand from the CIO that the management team have an away-day that focusses on common goals, commitment, and trust, based on everyone reading Patrick Lencioni’s book The Five Dysfunctions of a Team.
This is a great way to create an agenda that gives people permission to be open with each other, and hopefully sort out their goals and intentions, as well as to understand the impact of not contributing to the team.
“We are doing this already.”
This, or similar words, are often actually a passive-aggressive way of resisting change, or stating that this is not something that is going to be easy. They might as well say “I hate you and your silly ITSM processes, and your new system won’t change what I do buster…”
If nothing else, it’s a clear indicator that you may need to spend extra time with these people winning them over. This can also relate to point 1 in terms of the need to examine what is currently done and identify how to make it work better, rather than simply go for ‘as is’
“Can the system do…?”
Grrr. If they were on the procurement team, they should know, if not this is usually whimsy, an attempt to look good, or way of changing the subject.
Whichever of these, this slows the workshop down for everyone, so let’s move on…
The ‘what is a service?’ debate
However painful this might be, it’s important to have this debate and try to work through what your services are, so that the new system can be set up in a way that might remotely produce some useful business reports. Excuses to avoid this session can be very creative, but should all be rebuffed on a 3-line whip.
During sessions of this type I have on many occasions witnessed almost religious-like epiphanies (the look of terror) when managers realise they are responsible for areas they didn’t know existed – the ‘at least we are understood’ look from front-line staff, the ‘I’ve been a bit of a fool’ look from the technical manager, and the ‘that’s the reporting I want’ outburst from the CIO or senior manager.
And yes, there are many blank stares too, but it’s worth it – so just do it.
What does ITIL say?
Just don’t get me started.
No really.
I have no issue with ITIL being used as a reference point for the design of services and processes. This question however often gets raised in the context that we are doing an ‘ITIL project’ – which really should not be the focus and driver. So anyone who is labouring under that misapprehension (rather than the fact that this is a business-driven service improvement project) should be taken aside and ‘educated’ (…in a nice way of course).
The category debate
This is often the most practical and interesting discussion in these projects – it helps to clarify key elements in terms of data structure, process, and reporting. It is a signature debate that also identifies the level of shared understanding (or not) around what ITSM is, what the tool is required to do, and how this will work.
The basic question is – what is a category? Most other information about organisation, people, service, CI, SLA, priority, etc. is captured elsewhere. What do we need ‘category’ for? It is useful at the close of an incident to assign ‘cause codes’ to identify reasons for the incident happening, which is a great driver for problem management. But cause can’t be assigned (in most cases) on logging, so what is ‘category’ actually capturing?
I find it useful to have some basic principles here: (1) set a high-level layer of identifiers that can be used for a generic rolled-up view of incidents and types – like Incident, Request, Access, Question, and (2) use a small set of 2nd or 3rd level business or service definitions that allow you to focus on either key business areas or useful escalation points.
The key is to find an agreed definition for use. So, whichever way you view the use of this concept, get everyone on the same page.
What you need to do is…
In some circumstances this this can be a way of trying to offload responsibility. In the ITSM context this can relate to the mis-perception that the project is only for the Service Desk or immediate support operation (see #2 above).
It’s always good to remind everyone that the project is about teamwork and collaboration, so any imperatives identified for action should be expressed as ‘what we need to do…’
Principles
A useful and completely serious approach to take for these (and all) workshops is to set out some clear principles for topic of discussion. This helps to keep the discussion focussed and targeted on common objectives.
For example, if you are discussing incident management, then it can be helpful to establish ‘fastest possible resolution time’, ‘priority in relation to business need’, or ‘shift left’ as principles to work towards. In most cases this requires some initial discussion and clarification of what these actually mean, which I find a great way to start strategically, and not let the discussion get too detailed and stuck too early on current organisational issues.
Taxonomy
Probably the most useful and essential requirement for any of these projects – and where ITIL can provide the objective model. Common understanding is vital and so a glossary of relevant terms is a must.
Produce a short 1-2 page version of this for your project, with the key definitions that are being used. Use the ITIL or other glossaries as a reference point, but build your own short version and ensure that right people read it.
Good luck and keep smiling!
This article has been contributed by Barclay Rae, who is an experienced ITSM mentor and business manager. He has worked on approximately 500 ITSM projects over the last 25 years, as well as starting life on the operations side of IT, setting up and running Help/Service Desks. More recently Barclay has created ITSM Goodness – a set of practical steps and guidelines – simple practical and proven tips and tools for successful ITSM.
