Wednesday, May 28, 2014

Keeping Employees Engaged With ITSM

Employee engagement had been a popular corporate buzzword the past few years. I've been a bit leery of how the term is applied, since it appeared to mean whatever a given organization wanted it to mean. I've seen engagement used to mean productivity (Productivity has decreased, it must mean employees are less engaged). I've also seen where employee satisfaction surveys were used to measure engagement (Employees hate working here. They must not be engaged). Engagement has frequently come to mean the attitude of the employee and how they feel about their direct supervisor.

I just came across an interesting article from Forbes titled, "CEO News Flash: If Your Workers Aren't Engaged, It's Your Own Fault", which gives the most useful context for engagement I've seen. The idea is that humans are intrinsically motivated to be a valued participant in the workplace. The message being that corporate culture is what most frequently squelches that intrinsic motivation, and leaders have the responsibility to reestablish it. The author suggests we start by looking at two key aspects of leadership:
  1. Setting high standards
  2. Creating a culture of recognition

IT in general and many ITSM initiatives in particular can work against these tactics. Who is more recognized for achievement in your organization? The diligent engineer who always plays by the Change process rules, or the maverick who puts out the dramatic IT fire, often created by their own sloppiness? I hope it's the former; but in many organizations I've worked for and with, the latter unintentionally receives the accolades. And don't assume your organization doesn't reward the arsonist/firefighter. Rewards can come in many forms. Some obvious, some not.

What about SLAs? Are they used to measure individual performance in addition to organizational adherence to agreements? Too often they are. We must remember that SLAs are minimally acceptable targets when it comes to individual performance. It is the equivalent of earning a C grade. Meets expectations. If all employees strive to merely meet your SLA targets, that leaves no room for the occasional task that fails to meet minimum expectations. In order to meet organizational SLAs, we need the performance on individual tasks to exceed minimal expectations more often than not. Do your expectations around employee performance reflect a culture of high standards? Look carefully at how you set expectations around individual performance. If they are the same as the standards around organizational performance (ie., SLAs), you may be unintentionally creating a culture of low employee engagement.

Think of it this way. Performance against the standards you set on an individual basis is a key leading indicator of overall organizational performance. Make your standards high, clear, and reachable.

Provide reinforcement. Publicly recognize performance excellence, focusing on the "why" and "how" over the "what." The "what" of recognition just says "well done". "How" takes it a step further and indicates how the performance enables a greater goal or outcome. Most important, "why" personalizes the experience to say "I get why you are good".

Engagement doesn't have to be a nebulous concept. Managed purposefully from the top, it can create tremendous value. At a time when IT departments continue to struggle for the favor of business partners, we need all the employee engagement we can muster. And it starts with you.

Monday, May 19, 2014

The Big 3 Questions of Consequence

I had a great conversation with a new client today.  It was a pre-workshop call to solidify the agenda for our upcoming process re-engineering workshop.  The discussion turned to how we transition from the old processes to new ones.  It's one thing to design a new business process.  It's another thing entirely to put that process into practice in a manner that optimizes the likelihood of success.

In addition to some standard organizational change management suggestions, such as communication, training, etc, I mentioned the importance of identifying consequences associated with the old procedures.  I said something along the lines of, "It's just as important to understand the positive consequences some staff get for behaving inappropriately."  I did't mean legal or ethical inappropriateness, but behavior that is inconsistent with the desired process.  I asked the questions:

  • Do people on your teams ever get praise for putting out day-to-day fires?
  • How often do they receive praise for doing the right thing so that the fire-fighting situation never arises?

The answer to question 1 is frequently "all the time", while the answer to question 2 is frequently "never".

A while back I wrote about some practical considerations for process and culture change.  One part of that post was about consequences for appropriate and inappropriate behavior.  I find that the most overlooked part of organizational change is that of consequences and rewards.  I thought about it some more today, and realized that almost every example I've seen of failed process change did the following three things poorly or not at all.  Conversely, in addition to clear measurable goals, every successful major process/organizational change did each of these thoroughly.

Three Questions of Consequence

  1. When developing new processes, are you including positive consequences for behaving appropriately?
  2. Does your current process have positive consequences for behaving inappropriately?
  3. Does your current process have negative consequences for behaving appropriately?

Let's take a brief look at each question.

When developing new processes, are you including positive consequences for behaving appropriately (and negative consequences for behaving inappropriately)?

This can manifest many ways, but it is critical to include clear expectations of positive and negative behavior.  How do you appraise employees?  Do you include appraisal criteria for process changes? For example, when re-defining change processes, have the relevant employees' job descriptions and/or performance assessment criteria been updated to reflect desired behaviors under the new process?  I am surprised how often this is overlooked, or considered minimally important.  Process folks all too often assume that everyone else gets the importance of process change the same way we do.  At the very least, we assume that process compliance is out of the scope of any process (re-) engineering project.  We must work with the personnel supervisors to ensure that compliance expectations are documented on a role-by-role basis.  An additional benefit is that you can also determine whether the supervisors are on board.

I can't state this strongly enough: Your process re-engineering or improvement project will fail without clear behavior expectations.

Does your current process have positive consequences for behaving inappropriately?

These are the most dangerous consequences, and the most important to uncover.  As you address organizational change, look for the hidden positive and negative consequences embedded in the current process.  Are there a few "star" performers who are always called out for exceptional fire fighting?  If I'm consistently rewarded for my fire fighting efforts, why on earth would I want to help make a transition to a more consistently applied process?  Don't forget that everyone else notices the rewards and accolades given to those who work outside the boundaries of the preferred system.  What makes it even harder is that we're also talking about perceived positive consequences.  Of course I don't intend to reward the system administrator that routinely takes on requests that should go through the service desk.  As a manager, however, I may forget the occasional process lapses and focus my promotion efforts on all the glowing customer feedback.  What happens when other staff perceive that the rule-bender gets more positive attention and even promotions?

Equally important in this assessment is a determination of why the rule-bender bends the rules in the first place.  Are there problems with the service desk to the point where customers understandably seek out help elsewhere?  Are there issues where, in the best interests of your business, the service desk should be bypassed?

Does your current process have negative consequences for behaving appropriately?

Just as baffling is the idea that there are actually negative consequences for performing appropriately.  These can be the most difficult to uncover, as they are usually the least intentional.  Again, these can be perceived or purposeful, and are frequently associated with positive consequences for behaving inappropriately.  Is someone following expectations around change request lead time also being punished by their boss for slow throughput?  Maybe a service desk agent is evaluated poorly due to a lower volume of incidents handled, while all along they were following the defined expectation of minimizing ticket re-assignments.  Can you add any of your own examples?

Being purposeful about formal and informal consequences is a critical part of any process re-engineering, improvement, etc. program.  The most thoughtful and well designed process changes are doomed to fail without thorough assessment and, if needed, remediation of competing and conflicting consequences.

What are your thoughts?

Sunday, April 6, 2014

Wherefore art thou, service desk?

This started as a reply to a blog written by ITSM consultant extraordinaire Barclay Rae. Go back and read that if you get the chance. My thoughts are intended to compliment what Barclay shared  and expand in an area that's had a lot of my attention lately. Where has the Service desk gone, what have we done to it, and how do we give it its proper place in ITSM?

We've worked so hard to define ITSM and ITSM software as "more than (just) the help desk" that we started to believe ourselves that the service desk doesn't matter. We (ITSM industry) have such a strong inferiority complex that we needed to show everyone else, the business and the rest of IT, that what we do is more than logging calls and managing trouble tickets. Along the way, we've forgotten that the people we put in between the rest of IT and the business actually matter. Instead we looked for easier and cheaper ways to do that function. This has given rise to:
  1. Outsourcing the service desk function entirely, and/or
  2. Scaling back on the quantity and quality of people we use to staff internal service desks
Over the past year I've come across more and more organizations downplaying the importance of the service desk. Even when facilitating Incident Management workshops, the service desk is barely mentioned. The service desk manager may even be present, but he/she recognizes that the people taking the calls are virtually irrelevant.

We've justified the easier, cheaper goal based on research  that tends to imply that customers don't want to talk to us anyway. The service desk is an anachronism of days long past when customers had no other options.

I'd argue that internal technology support is significantly different than most transactional customer support; but I'm willing to set that aside for now. Let's go with the assumption that most customers of internal IT services prefer not to interact with your staff. So customers try to resolve issues on their own. What happens when they can't? They've googled the issue, searched through your knowledge base, asked coworkers for help, and the issue remains. It's clear that by this point their issue is not a simple password reset that self service can easily solve.

Now they need to call in professional help, so who do we have them call? Outsourced staff armed only with scripts for common issues, or internal staff of whom we expect little more than being able to transcribe the issue into a ticket. These are the people you want representing the face of your services to your business?

Yes, we're probably right that automating simple service transactions are a good idea. But that doesn't mean we can scale back on the people who do engage with our customers. What it means is that the people who do call for help can be divided into two groups:
  • Those with more complex issues that aren't easily resolved by standard repeatable steps, OR
  • Those who prefer not to use self help, and need more hand holding
We need people taking those calls to have a broad technical base, so they understand how to triage and diagnose issues that may have multiple causes across technology AND business disciplines. They must understand how our specific business works. And we need people with the skills to empathize and listen, who actually enjoy helping less tech savvy customers achieve results.

Instead, we give our customers the polar opposite of what they need. We give them outsourced staff who know nothing about our business, and staff with minimal technical breadth.

The old model was to staff the Service desk with entry-level systems analysts. The current model staffs the Service desk with the cheapest resources we can find. I propose that what is needed going forward are service desks staffed with junior business analysts or junior relationship managers. Let's use people who are focused on technology breadth and customer outcomes.

Crazy idea, huh?

Friday, February 14, 2014

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.

Saturday, February 8, 2014

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.