Stop hurting your IT operations

It’s about time we faced a reality that we conveniently ignore: we constantly and continuously hurt our IT Service Operations. Yes, it is through us – our actions or lack thereof – that make our service operations, and the service desk in particular, perform and look bad and be widely derided by our user community. It’s time that we look at service operations in a very different light.

Let’s talk about fundamentals

As you know in ITIL parlance service operations is the lifecycle phase that ensures that IT services are delivered effectively and efficiently. This include fixing incidents (it’s broken, fix it!), service requests (I want something, give it to me!) and problem (I really don’t know why it broke. Let’s investigate!). It also includes our functions which includes the service desk, application management and so on. It is said that it is in Service Operations that customers see / realize the value of a service. But when is this not the case?

Many times, when customers and end user complain about a service not working or delivering to expectations the knee-jerk reaction of many IT leaders is to blame…the service desk! It is the service desk that’s “not working well”. It is the service desk that’s “not executing the incident management process correctly”. It is the service desk that’s using bad tools and “we need a new one”. You’ve probably heard variations of this throughout your career or your department and the end result is always the same: let’s bring in an outside consultant to ‘assess’ our processes and / or re-do our process documents. This probably happens every three or four years, maybe even less.

What if I told you that some of the issues, many even, can be traced not to the service desk and the execution of the service operations processes, but to things that that the organization missed doing or did poorly? There are two very specific things that I’d like to talk about here, which hopefully will shed some light on this issue.

First off there’s Service Design, whose objective is to design new services as well as changes and improvement to existing services. This may sound a bit simplistic, but it is not. If you don’t design it correctly, how can you expect it to work correctly, let alone be supported capably by anyone! Many organizations out there don’t “sweat out” the design of a service enough to make it meet all of the requirements, which include operational requirements and organizational changes that go beyond backup and monitoring. You want to make sure that whoever ends up supporting it is able to do so without affecting day to day delivery of the service.

One of the problems, though, is that Service Design processes are often considered and executed in isolation and/or in a very day-to-day operational perspective (e.g., availability management) as opposed to continuously checking the actual design (the blueprint) of the service against these issues. If you have opportune capacity or availability issues, for example, it is up to other processes to alert availability management and what should happen is for a service improvement initiative to be spun up to find out why it happen and then modify the design to ensure it doesn’t again. Simple, right?

Then there’s Service Transition. One of the issues I’ve seen regarding transition is that it is often considered and executed in piece meal fashion, particularly change management which often turns into a bureaucratic exercise in frustration and futility. Just like design, transition processes need to work together to provide better results. It’s not just about passing a change or a project from point a to point b! One of the main outputs of this lifecycle, aside from a release or an approved change is information. There’s information that goes into the configuration management database (CMDB), into one or multiple knowledge management databases, or into training information (because you do want the service desk and operations to be able to spot and handle errors detected in development, right?) that contributes and supports a clean transition.

There is no try

Doing, or trying to do, these two lifecycles well will save a whole lot of pain for those involved in Service Operations. Note that I said ‘well’ and not ‘good’ or ‘perfect’. I am often the first to realize, as should you dear reader, that the pursuit of executing a ‘perfect’ process, at least as it relates to IT service management is utopia. What you can do is to understand that you should always pursue improvements, no matter how small. Once you understand what is required out of each lifecycle, you need to empower your resources to drive improvements throughout the entire service management system which includes the service itself, processes and people.

The second thing I would like to talk about is that some organizations spend too much time just literally transcribing processes from one place to another without actually sitting down and planning what a process should do, perform and behave against a service or services.

Don’t get me wrong: having documented processes is great, and it is a requirement sometimes if you’re going to get audited. But think about this: several of the processes in the ITIL framework (and it’s close cousin ISO/IEC 20000 standard) have not really changed in years! You can probably close your eyes and recite the activities that occur during incident or change management quite easily! On the other hand, you and your organization change constantly to many things: the market, competition, new technologies and techniques, even people. So it is in your best interest to know how everything influences the execution of the process, not the process itself.

Go look, for your own good

So if we go out and revisit our design and transition activities, and then on top of that start planning out our processes and all of the elements that support it, we can start becoming better at executing them and making them standard work something that will certainly make things easier during day to day work, or if you want to pursue something like DevOps.

Many of these processes can fit in a couple of sheets of paper (yes, really!). Let’s take incident management, for example. Unless your organization does something wildly different than every one else, the process is roughly the same: log, categorize, prioritize, try to resolve, escalate (if needed), resolve and close. Note that I am not going into the nuances of the process itself (what does first call resolution look like, when to escalate). This is because I would spend some time defining these elements outside of the process itself! Probably in a separate ‘plan’ document that is constantly reviewed and constantly updated by everyone in involved in the execution of the process.

It is the plans where we sweat out the details as to how the process will execute. This should include all of your status definition, rules, the tools you’re going to use and the data they will collect, communication, training and automation rules! This last point is important because you want to have full control of the rules and mechanisms you’re automating at all times. Having automation without rules or definition will probably add little value to the activities the process is supporting.

Lastly, you want these plans to be created and revised throughout the entire lifecycle. Isolating a process to its lifecycle because ‘that’s where it fits’ is of absolutely no value to the organization. ITIL’s strength lies in it being integrated and not isolated.

Stop the hurt

So there you have it: two things that you can start thinking about doing right away. Where to next? Here are a couple of tips:

When was the last time you checked your Service Design Package (SDP)? Do you have one? As the SDP is one of the most important outputs of Service Design, you might want to spend time either tracking it down or checking the one you have. Make sure all elements of design were considered and if not, consider initiating an improvement initiative to fix any issues

Service transition is not just change management! If your other transition practices aren’t up to snuff, all you’re doing is approving and tracking requests. A good solid CMDB is crucial, as well as good knowledge tracking. (By the way, think that building a CMDB is hard? I do, too. But there are ways to make it through. I’ll talk about it in a future post)

Start thinking about planning over processes. You already have them, and you understand what they’re supposed to do for you. Start looking critically at how. How will activities be supported? How will automation work? How will we classify information? These are vital elements that support the execution of any given process. You may already have these documented, just make sure everyone understands the ‘how’

Lastly, involve your service operations people. For all of the things you set out to do, bring your best people forward and that includes people down in the trenches getting their hands dirty fixing issues and dealing with customers every day. I know that the Service Desk, for example, is often looked as low skilled, repetitive work (I should know. At one point, I was there) that has nothing to contribute. I fully disagree. A truly empowered individual at the Service Desk is one of the most valuable resources that you can have in any service design or transition team. They deal with issues every day! They know what’s happening down where value is being either created or destroyed. Their insight can provide elements of design and transition that other people in your organization may have missed.

These things will take time, and there is no silver bullet or quick technological solution for it. The best thing you and your organization can do is to go forward with a small, continuous improvement approach, along with the thought that failures will happen, but you can learn from them and emerge better on the other side.

After all, Rome wasn’t built in a day. Right?