Tuesday, May 14, 2013

Process and Culture Change

I was re-reading an IT Skeptic blog post from a couple months ago, called "Obtaining compliance for policies, processes and procedures". It's a quick read, so I recommend you check it out before (or just after) finishing this article. While reading the post, I was reminded of a class I used to teach other managers at a previous job. The session was about handling performance problems on your team, and was based significantly on the book "Coaching for Improved Work Performance" (Amazon.com link) by Ferdinand Fournies. Fournies discusses pragmatic coaching tools that can be used to achieve optimal performance from employees. It is the most useful management book I've ever come across, and I've found many other books very useful. What I like best is that, while the book covers a lot of theory behind Fournies' approach, it is very action oriented. There are specific steps laid out clearly to address different scenarios. I highly recommend the book for managers of all types, including process managers who may or may not have actual supervisory authority.

My class was focused on addressing work performance problems, using a modified version of Fournies' coaching analysis tool. The coaching analysis tool is a great compliment to the IT Skeptic's compliance steps, in that it amplifies and gives some examples of practical application. The tool is applied as a flowchart, asking the manager simple "yes/no" questions with actions to take depending on the answer. In Fournies' model there are 16 questions for a manager to answer, starting with "Is it worth your time and effort?" and ending with "Could they do it if they chose to do it?". There are 15 questions to address before the one we often jump to: could they do if they wanted to? It's actually a very simple tool to apply, and you can often run through the questions very quickly. Fournies intends this to be used on an individual coach-employee scenario, but I find it useful to guide myself with all staff. The difference is that you can drop people out along the way when they become compliant with the new procedures.

I'll provide the list of questions, but I'll leave the detailed discussion to those who pick up Fournies' book. I'll highlight a few favorites, however.
  1. Is it worth your time and effort?
  2. Do they know what they're supposed to do?
  3. Do they know how to do it?
  4. Do they know why they should do it?
  5. Are there obstacles beyond their control?
  6. Do they think your way will not work?
  7. Do they think their way is better?
  8. Do they think something else is more important?
  9. Are there positive consequences for performing appropriately?
  10. Are there negative consequences for performing appropriately?
  11. Do they anticipate future negative consequences for performing appropriately?
  12. Are there positive consequences to them performing inappropriately?
  13. Are they performing inappropriately without receiving negative consequences?
  14. Are personal problems interfering?
  15. Could they do it if they chose to do it?

#3:  Do they know how to do it?

This question immediately follows "Do they know what they're supposed to do?". I like this question because we so frequently assume that someone who knows what they're supposed to do MUST know how to do it. Is this true in any other context besides business? Let's say you are a brand new golfer. If I tell you that you're supposed to hit the ball into the cup, you know what you're supposed to do. So how come you do it so badly? You must be unwilling to change! It's an exaggeration I know, but I've had similar things occur. I implemented a new standard where service desk reps needed to summarize the incident or request back to the caller to ensure understanding. There was one rep that refused to do it, which made me frustrated. I found out, however, that she had a specific flow with the calls that was different from everyone else. They end-of-call-summary completely broke her flow and slowed her down to the point where she couldn't keep up with even a moderate call volume. She needed help with the "how" part.

#6 and #7:  Do they think your way won't work? / Do they think their way is better?

The key here is to actually ask the employee these directly. Not "Why won't you do it?", but "Do you think the new way doesn't work?". The difference is that it invites the employee to share something that would otherwise be seen as negative or complaining. They might even have a better way to do something, or you will need to convince them otherwise.

#12:  Are there positive consequences to them performing inappropriately?

This is in the midst of several questions around consequences. The point is to not just look at positive consequences for compliance and negative consequences for non-compliance. There are also hidden, unintentional consequences that could easily go unnoticed. A client couldn't figure out why everyone was "too busy" to get to incidents and requests sitting in queue in a timely manner. One of the things we found was that several employees were taking in requests for work that they handled outside of the standard processes. These requests were usually not documented anywhere, except for a few emails between the tech and the requester. These techs received all kinds of praise from the requesters, who also made sure the tech's manager and the requester's business unit management knew what great service they received. It was so much easier than going through the service desk. We had to really work at cleaning out the "black market" consequences environment. It also pointed out some glaring issues with standard processes, since there were legitimate reasons why people didn't want to use the service desk.

Also note that the question about applying negative consequences is at the end of the consequences section. The point is that, before you start applying negative consequences to non-compliance, make sure there are not hidden consequences (positive or negative) driving the non-compliance.

This is an excellent tool to apply in any cultural change process, especially cultural change necessitated by ITSM journeys. We've been talking for years about people/culture change being arguably the most important of any ITSM undertaking, but there has been very little practical guidance on how to actually do it. The available guidance tends to focus around training and attitude. As in: "I'll train them, and, if staff do not follow the new procedures, it must be their poor attitude"; or some variant of this.

Go back to the golf example. An instructor shows and tells you how to swing the driver. From that point on, all your shots are long and straight, right? Of course not. It takes study, repetition, and review. Determine what's going wrong, and repeat the cycle. Sounds a lot like Deming's Plan-Do-Check-Act. When it comes to ITSM consider yourself lucky when the Plan stage consists of actual hands-on training. And we wonder why ITSM projects fail.

Friday, May 10, 2013

Service Level Management - Measure the Outcomes, Not the Process

I hate SLAs. Or rather, I hate the way SLAs are commonly used. All too often, they are used as the outcome of Service Level Management; much the way the Service Desk is frequently equated to Incident Management. Yes, each is very important to the other, but they don't define each other.

I wrote about the relationship between Service Management and Service Level Agreements (SLAs) a few months back.  I won't rehash the whole thing, but the point was that SLAs, especially when done as formal contracts with internal customers, create more harm than good.

Service Level Management, or SLM, is far more complex than simply meeting contractual targets. The latest episode of the Practitioner Radio podcast, "The Evolution and Children of Service Level Management", explains it very well. It was nice of Chris and Troy to cover this while I was writing this entry. I highly recommend that you take the 23 minutes to listen. They have a great discussion about the role of SLM, compared to its "children": Business Relationship Management, Service Catalog, and Service Owner. I'll post some of my own thoughts about the role of SLM sometime soon.

This time, however, I'd like to look at metrics around SLM. How do you measure the relative success of SLM? All too frequently we look at adherence to SLAs as the beginning and end of measurement.

"If I meet my defined SLAs 90% of the time, we have a solid service management practice. Right?"
  • When was the last time an irate customer was placated by that statement?
  • When was the last time your partners in the business recognized IT's significance through that statement?
  • When was the last time you generated business value with that statement?
I didn't think so. Now an argument could be made that the SLA is a fine internal measurement to identify process efficiencies, but no one outside of your IT shop cares about efficiencies. They might pay it some lip service, but that's when they only see IT as a cost to be minimized. It's time to focus SLM on what it does for your business. I've got a few ideas based on my own observations, and aggregating observations of ITSM pros around the world.

  • Kill the SLA
First, remove the concept of contracts between service providers and their internal customers. SLAs done this way create an us-versus-them mentality right from the start. You work for the same business with the same business goals. Contracts with your business peers are a primary reason everyone else hates IT. If you are an external service provider that must have SLAs, make it clear that SLAs are the minimally acceptable target, not the desired goal.
Replace the formal SLA with documented targets. It may sound like just a semantic change, but it's more than that. It's a completely changed mindset. These targets should NOT be based on what IT can do, they are based on meeting and exceeding the three foundations of business strategy:  Business Goals, Business Objectives, and Business Mission.
  • New Measures
Based on these new targets, start measuring the impact on current
    1. Business Goals
    2. Business Objectives
    3. Business Mission
Let's say a business unit has a goal to increase revenues by 20% this year. Meet with the B.U. to determine how they are planning to hit their goal, and how your services can help them get there. Focus your service targets specifically around these things. 
  • Continuous Review
You now have targets that you can measure and share with your partners. Meet with these partners regularly to review how well the targets have been met. Then ask the crucial question: Are they on track to meet or surpass their targets? If the answer is yes, and you've met your own targets, you now have a clear connection between the value being delivered by your SLM. If the answer is no, but you are meeting your service targets, there is a clear indication of disconnect between SLM and business goals.
Honestly, who cares if IT hits their targets if the business is not hitting theirs? Service level targets must be regularly reviewed and updated as needed in order to continue meeting business goals, objectives, and mission.
If you're doing anything else, you are failing. Period.