Working in IT is amazing! We get to save the world multiple times every day, play with sparkly new technology, and engage with our awesome end users (or customers). Sometimes though, we can get so caught up in doing what we think is the best thing to do, when actually we’ve gotten sidetracked or are missing out on the most effective way of restoring service.
This blog looks at seven deadly sins of IT service management (ITSM) as well as how best to avoid or correct them.
1. Making Your Incident Form Too Complicated
Incident management is a capability that should be front-and-center of any IT support model. It’s the practice (using the new ITIL 4 terminology) that looks at managing all incidents through to resolution and ensuring that nothing is lost, ignored, or forgotten about.
For us, one of the golden rules for any ITSM process/practice is “always make it easy for people to use your service”. But here’s the thing. Sometimes, we get so swept away with the available ITSM tooling and automation that we forget to make the incident reporting as easy as possible. So, our customers have to navigate complex IVRs or answer twenty questions on a web-form to just to log a request (and service desk agents will likely be doing the same). It’s not good, and a friction-filled barrier to support.
Hence, make your forms as easy to interact with as possible. Don’t ask for too much information, otherwise your users won’t engage with it (and service desk agents might cut corners with their incident capture screen too). Hopefully, their customer contact details will automatically populate if they’re logged on to your network – so just a short description, service affected, and priority will be enough.
Sometimes the simplest approach is the best – and IT gets more engagement and fewer complaints about the tool (or contacting of the service desk), and end users get to log the issues quickly.
2. Forgetting About Proactive Problem Management
Proactive problem management is the aspect of the capability that many people forget about. It’s more future-reaching than reactive activities – using trending, forecasting, and working with support teams to find out what’s worrying them. It’s the side of the problem management that looks at problems that might otherwise be missed.
Examples of proactive problem management activity include:
- Trend analysis – reviewing previous incidents and looking for common or recurring themes.
- Raising changes – to prevent incidents from recurring or even happening in the first place. For example, maintenance reboots, monthly patching, and network traffic re-routing.
- Working with your support teams – ask them what their concerns are, if there’s any technical debt, or if there’s anything that’s at risk of unplanned downtime.
3. Sending All Changes To the CAB
Nothing will frustrate your support teams, and other involved parties, more than sending all changes to the change advisory board (CAB). There’s simply no need to force people to attend a two-hour meeting when it’s something that could be covered in 30 minutes or less. Also, we’re not going to lie, the same people that you need to be engaged will likely become discouraged and potentially irate.
Hence, when designing your change capabilities, work with support teams to identify the work that they do day-in and day-out. Is it easy, low risk, and repeatable? If yes – congratulations – you have a standard change. It’s something that can be pre-approved and scheduled as needed.
If there’s slightly higher visibility and risk, then use delegated authority so that only the areas impacted need to sign off the change. Ultimately, save the CAB for the big, important, impacting changes.
4. Not Having A Data Model for Configuration Management
Not being able to model your services effectively can lead to inaccuracies and scope creep.
When creating your configuration plan, take the time to map out one service end-to-end so that you get used to the workflow and identifying the right attributes and dependencies. Having one service mapped out acts as a pilot of sorts for configuration management and is a great way to get across the benefits and day-to-day working requirements.
5. Not Prioritizing Knowledge Management
We know, we know... it’s hard working on the IT service desk. You’re constantly on the go troubleshooting everything from password resets to major incidents. But here’s the thing – if you’re not prioritizing knowledge management, then you’re missing a trick.
By creating a culture of knowledge sharing, you’re empowering your team. Use the shift-left principle by asking your infrastructure and application teams to give second-line support some tips that they can use for troubleshooting. And do the same from second-line to first-line.
This benefits everyone because the service desk agents get additional training and technical knowledge – freeing up third-line support to tackle the more complicated stuff.
6. Missing the X from SLAs
We’ve all seen a “watermelon” service level agreement (SLA) in our time – it’s the SLA where everything looks green from the customer contract perspective, but the reality is very different.
SLAs that don’t reflect the actual business experience reflect very little. At best, they give an inaccurate view of the end-to-end service and at worst they damage the relationship between IT and the business.
These days, SLAs should increasingly be about user experience. So, we need to shift the paradigm from internally-focused measurements and metrics to business impact – from SLAs to XLAs (eXperience level agreements).
Ask your customers, “What does good look like?” Work with your support teams to see if you can get measurements that reflect the ideal performance level. For example, how long it takes to run a transaction or for the screen to refresh. By building in the experience into your SLAs (or XLAs), rather than just quoting service uptime versus downtime, you can get a better handle on what the business needs and then deliver accordingly.
7. Not Engaging With CSI
So many people (and organizations) don’t do continual service improvement (CSI) – although ITIL 4 now calls it continual improvement – because they think that it’s too daunting or complicated.
But it really doesn’t have to be. Instead of getting overwhelmed start small. What little things can you do to make the day-to-day job better? Things to look at could include:
- Review the aged-incidents queue with your service desk staff so that agents and technicians can “see the forest for the trees”
- Looking for more opportunities for standard changes and change templates
- Using Kanban in CAB meetings to keep them on point.
Whatever you decide to do, keep it short and snappy. Try it, take a breath to see how things have improved, and then go around the loop again.
What do YOU think are the most commonly seen ITSM deadly sins? Please let us know in the comments!
