ITSM Cannot Live on Process Alone

I've received great feedback on my article, "Process Improvement is not Service Improvement". I was in the process of responding to a comment, when I realized the response probably needed its own article.

Process improvement is frequently, maybe even almost always, a component of service improvement. What I'm saying is that it's a bad idea to use process CSF's and KPIs as the desired outcome of an improvement project. I've come into client projects where the goal was something akin to "improve Problem Management to CMMI level 3". That's a noble purpose. The conversation might look like this.

Me:  What is your project goal?

Client:  To improve the services we provide to the business. 

Me:  Why do you need to improve services? Is there a specific business driver? 

Client:  Reach maturity level 3 in Problem Management. 

Me:  OK, how will you know when you've reached it? 

Client:  We have some internal targets set. Once we've reached those, we'll have an outside audit done. 

Me:  Great! What do you hope to achieve by doing this? 

Client:  I told you. CMMI level 3. 

Me:  No, what I mean is, what is the business driver causing you to do this now?

Client:  The CIO talked about SOX compliance. There was a finding in our internal audit that needs to be addressed.  

Me:  OK, so the business driver is the remediation of a SOX audit finding? 

Client:  Yes ... (Sigh) ... but our outcome is to reach CMMI level 3.

Then we discuss how maturity level 3 may have nothing to do with addressing SOX compliance. The client agrees with that, but says executives determined that CMMI level 3 would provide what they needed to remove the audit finding.

OK, now we're getting somewhere. It turns out that HOW achieving level 3 remediates the audit finding was never shared with the project team. All they know is that they need to achieve level 3 to remediate an audit finding.

Does having a process success factor, reaching Problem Management level 3 maturity, inherently improve the service provided to the business? No. There's an excellent chance it will even increase the cost of providing services. If we're going to increase costs, there better be an inherently clear business purpose for doing so, and that purpose should clearly provide more benefit than the added costs.

How many different process changes could you implement in order to achieve CMMI level 3? What does it mean to achieve level 3? How do we know that the process changes put in place in order to reach level 3 will actually resolve the audit finding? It's possible that your process changes help you achieve level 3, but do not address the audit finding. This is a recipe for disaster. The "service improvement" effort is based on a process CSF, which was selected in order to meet a compliance issue, and we know that making the necessary process changes may not even resolve the compliance issue!

This isn't a unique example. Plug in terms like "reduce incidents", "improve SLA achievement %" or just about any other process based metric you want.

There is no direct correlation between achievement of the process goal and improvement of services provided to the business.

You might end up improving services, but you could just as easily increase costs of providing services with no business-visible improvement in those services.

Process improvement is almost always part of service improvement. They compliment each other very well, but they are not the same thing. Before embarking on any sort of service improvement program, whether it is continual or one-time, make sure the desired business value is clearly defined before you start defining any process CSFs or KPIs.

Failure to do so dooms your program before it even starts.

Process Improvement is not Service Improvement

What is the statute of limitations on ITSM transgressions? I hope they have long past, since I am now confessing some of my past sins.

I used "process improvement" interchangeably with "service improvement".

There. I've said it on the Internet, where everything is indisputable fact. Good to unburden myself like that. It's like a good cleanse.

I'm amazed by how often I come across CSI (Continuous Service Improvement) efforts that list things like fewer incidents or process efficiency as the primary goals. But again, I once did the same thing. Much ITIL and process maturity direction tries to sell the idea that "better" process is all we need to do to reach better service offerings. Process metrics like first contact resolution, mean time to restore, and self service growth are constantly presented as THE way to measure success in IT service management. Of course there are outliers who offer different measures, but the fact that they are outliers speaks volumes.

Here's the confusing part: We are providing a service that is also a product. Customer interactions with individuals delivering the service are part of that service. We call those interactions "providing service" or "customer service". This word service is used all over ITSM, so it's easy to confuse the service product with the activity of customer service.

Let's be clear. Incident management is not a service. It controls a process or series of activities done in order to restore a service to normal working state. Measures of incident management or customer service have no direct correlation to the willingness of customers to consume your service-product. Those measures may have an indirect connection. Please allow me to paraphrase Deming:

You can have great customer service and zero service customers.

(Or in ITIL speak: You can have great service processes and zero service customers.)

This is also true: You can have lots of service customers and lousy customer service (or lousy service processes).

While service process quality is certainly a variable of overall service quality, they are not synonymous. More or better process definition does not mean better service. More process can even lead to degraded overall service-product. (See "Is your IT Team and Budget a Victim of Process Over-Engineering?")

It's well documented that I am not a fan of First Contact Resolution as a success metric. I'll take it a step further and say that ITIL process metrics should never be used to measure service success. Process improvement does not mean service improvement. Service Request process improvement to CMMI level 4 doesn't mean you are delivering an improved service. It can be a tactic used to reach improved service, but it can just as easily end up being an expensive boondoggle that does nothing to improve your service-product.

Service Improvement is about value. Do my customers feel they receive sufficient benefit from their cost investment? Do they like doing business with me?

I've come across ITSM practitioners where their CIO had set a goal of reducing incidents by 2%. And that's their CSI initiative. What the heck does fewer incidents have to do with service value? Enough!

I've come clean. Are you ready to as well?

Edit: I've posted a follow up article to address some questions.