A process with just one page?

Stop me if you’ve heard this:

You have a breach of the terms of your service level agreement (SLA) or a bad incident in your IT organization that results in lost productive time or embarrassment to your organization. Or there is consistent, negative feedback regarding the service desk and the activities they do in support of the user community. Or a change goes through to the production environment that breaks something else downstream. Most likely, there will be a “post-mortem” meeting to determine what happened, and at some point in that meeting someone will say, “Well, we should revise to ensure that doesn’t happen again.”

What happens next is that you either ask someone in your organization to review all of those processes or you hire an external consultant to do that for you, most likely through a process assessment. This is great, but I’m here to challenge you with a different point of view.

Ask yourself this question: In the past 10 years, how many times has that incident occurred, and how often have change management processes, for example, changed? Not many. You can probably recite the steps of both processes with your eyes closed. The reference is sitting right there in your bookshelf, in the form of many of the best practice frameworks and standards that exist today. I think, though, that some organizations spend too much time focusing on the mechanics of process improvement the wrong way.

You can get away with writing a process document on one page (really!) if you start looking at your service management system in a holistic, systematic way (think about the “work holistically” principle of ITIL practitioners). I would like to offer you some ideas as to how you can think differently in terms of your processes, and how to improve them.

Let’s start with scope. I discussed scope in a previous post, but this is something worth revisiting. If you define a good, concise and sufficiently narrow scope of services, your processes can be adapted to support and react to situations specific to the scope. Let’s say you’re an internal service provider for a supermarket and you’ve determined that your vital business functions (VBF) revolve around ensuring that merchandise gets efficiently to the stores and that cashiers are able to sell and process transactions. (We could include more, but indulge me on this one. Yes?). What would an incident look like for these? An inoperative point-of-sale system could be one. The inability of a store to scan and register incoming inventory could be another. I could go on, but having a narrow scope of service helps you in identifying potential issues that can affect your VBFs, along with everything else that this provides (a well-defined, tight configuration management database, well-established service level agreements — or perhaps expectations?).

There will always be unexpected issues (that cashier who spilled coffee on his terminal, for one). But thinking about these types of issues at a very high level (as part of your user profile and patterns of business activity analysis) can be used as an input for service design to think around some of those things and develop countermeasures in design that can help the organization avoid some of these issues. It is my opinion that by “sweating“ the design of a service — that is, by constantly reviewing the design specifications of a service — you can avoid many issues in operations, and that includes incidents.

So what does this have to do with writing processes in one page? Well, I think that the vast majority of process theory exists already. ITIL has 26 processes and functions, for example. CoBIT 5 has 37. (And very interestingly, it has more for processes related to planning and organizing — 13 — than it does for delivery and support — 6. I don’t know. Food for thought.) There are a handful of clauses in the ISO/IEC 20000 standard, and I could go on and on.

The point is, this is one area that you can go very lean and first strive to focus on defining a process that converts an input (e.g., a broken service) into an output (e.g., a restored service) in a very succinct, high-level way and then refocus your organization’s improvement efforts in all of the other aspects that affect the execution of the process. The way I would do it is to start thinking this way: “In this organization, our incident management process looks like , adapted and inspired by ” and do more of the heavy detailed definition of what the process will do as design and transition thinking.

Let me give you a practical example. The sample incident prioritization matrix (note the judicious use of bold for the word “sample”) is defined in the incident management chapter of ITIL’s Service Operations. Everyone knows this and I’ve been in organizations that have lifted (copy/pasted, literally) the exact same wording and matrix from the book into their (very lengthy) incident management process documents. (And this includes tool vendors. You know who you are.) What does that do in actual operations? Very little, as service desk resources struggle often to prioritize based on what they hear from customers or what they see from monitoring tools, if they have them. And this is something that should be dead simple: A downed point-of-sale system in a store is tied to a VBF, and that’s not good. The VP of HR can’t print in HQ, and that’s not good, either, but the expectation has to be set that VBFs are more important. (More on VIPs in another post. Promise.)

So how can we spin this around? During design and transition, and with the inclusion of your operations folks at all times, you can do a couple of things. You can establish all of the alerting mechanisms that operations will need through event management, establish what Priority 1, 2 or 3 incidents look like based on the service, and you can create knowledge, scripts, procedures and so on before operations has to struggle with actually supporting the service. Why do service desk agents have to ask customers “How many people are affected?” By design, you should know! Most of the time anyway, and it shouldn’t be the responsibility of either the user or the service desk agent to figure it out for you.

As for the unknowns? That’s what continual service improvement is for. There are some situations that you can never prepare for. That’s a given. But I’ll bet you that many of those have a root cause that you have not discovered yet.

So for those process documents, how about defining at a high level what they look like for your enterprise? Instead of spending time developing long and boring documents that no one will ever read — in essence rewriting bits and pieces of ITIL itself — why not adapt that to what they look like for your organization at a very high level and then develop the necessary knowledge based around the organization’s VBFs, its supporting services and other details?

Scope and design are your best friends when designing processes for your organization. Use the frameworks wisely, as reference points. Adopt and adapt to your organizational situation, and always be mindful about doing continual improvement.