Sunday, June 24, 2012

Shifting the Burden on Problem Management

"The cure can be worse than the disease" - Peter M. Senge, The Fifth Discipline

This is another of an irregular series of posts inspired by Senge's book. In systems thinking, one of the most frequent archetypes is called "shifting the burden". We have all seen examples of this. A common example is when someone deals with the stress of everyday living by turning to alcohol, drugs and other addictions.

IT organizations frequently shift the burden when it comes to incidents. Here's a simplified systems model of what we often see:

As a Service Desk manager, our first instinct to improve how we deliver service is to focus on handling incidents faster. We focus on templates, scripts, etc in order to reduce the time needed to handle a call. We reduce time off the phone for training and focus on getting people off the phone faster. This allows the team to answer the next call more quickly.

Nothing wrong with that on the surface, yet this by itself is a doomed strategy. As the business changes, IT systems either become less aligned to the business or IT makes system changes to respond. Either way, we almost certainly will experience increased incident volume. We then work even harder to increase throughput - more training, scripts, templates, and maybe we even get more staff.

Here are the main downsides over time:

  • as you get more efficient, we have to expend more and more effort to get the same amount of increase
  • one of the frequent casualties of increased throughput is lower quality
The end result is an Incident Management process that delivers shoddy service, provides little useful data, and burns out its good staff. All of these reduce IT's reputation and ultimately drive a wedge between IT and the rest of the business. Quite a vicious circle!

In order to get leverage on incident response, we need to focus on reducing the causes of incidents. While it does not return immediate dividends, as problems are eliminated from IT systems, we begin to see fewer incidents. This improves incident responsiveness and frees up more time for investigating problems. 

Now instead of a vicious circle, we get a virtuous one. Fewer incidents mean that employees can focus on serving customers and delivering value. IT systems are delivering more value and has a better reputation.

In summary, it can be very easy to get fixated on responding to events faster. This is rarely a path to success. Instead, focus on the patterns causing the events. The end result will often be more satisfying work that provides more value to our organizations.


Sunday, June 17, 2012

The One Tool You Need to Find the Source of Your ITSM Adoption Problems

"Nothing undermines openness more than certainty" - Peter M. Senge, The Fifth Discipline

This is the first of an intermittent series of posts inspired by Senge's book and how it relates to ITSM. I just finished reading it this weekend and there is a lifetime's worth of ideas in this book. I'd love to hear more from those in the field that have used his ideas to drive improvement in their organizations.

Just about anyone that's been through formal ITIL training can remember the moment when they were convinced that the path to nirvana had been found. Just stand up the processes, build a service catalog, and voila! Heaven on earth, with cool technology to boot!

Alas, nearly all of us found that even if we had support from our boss (and even higher), there was resistance or even outright hostility. The harder we tried to get people to see the way to enlightenment, the harder reality pushed back.

So as a public service, I want to share the one tool that can help you identify the source of your (and my!) failure to drive ITIL adoption.


Yep, it's you. Don't feel bad, it happens to all of us. We get to evangelizing about ITIL (or COBIT, or LSS, or PMI...) and forget that the people we are talking to have a vision of the future too. And if we don't help them find a way to see how their vision fits with our vision, they will reject it.

To avoid this, we need to be genuinely open to the vision of others and realize we don't have all the answers (this is particularly a peril of those who have just finished ITIL Foundations and not had certainty beaten out of the by the Intermediate courses). It's not about "compromise", it's about making the vision richer by including more perspectives and ideas.

The end result is an opportunity for genuine commitment and greater chances of success. And that makes looking in the mirror more tolerable.

Sunday, June 10, 2012

Service Management is not a Project!

Projects are like weddings, services are like marriages

We have a tendency in IT and ITSM to focus on getting done. While that is commendable, don't forget that at the end of the improvement project, whatever is delivered has to live on. 

Are you focused on the wedding or the marriage?

Saturday, June 2, 2012

All Measures are Proxies

I've been a stat-head my whole life. Whether it's sports stats, how much milk our cows were making, box office data, or incident data, I'm interested. So I'd like to focus this post on what data can tell us and what is cannot.

Most people are familiar with the notion of proxies - a measure that is used when you can't measure something directly. In theory, anything can be used as a proxy for anything else. For instance, the number of mirrors I have broken or black cats that have crossed my path could be a proxy for how unlucky I will be in the future.

In practice, we tend to only use a proxy when we perceive a cause and effect relationship. For instance, we use a customer survey score as a proxy for customer satisfaction. A good proxy meets the following conditions:


  • Credibility - stakeholders believe that the proxy is a reasonable stand-in
  • Correlation - movement of the proxy appears to mirror the movement of the item to which it is linked
In a sense, even things that we can easily measure serve as proxies for something else we can't measure. For instance, batting average in baseball is a proxy for whether a player is a good hitter. The amount of money in our bank account is a proxy for how wealthy (or poor!) we are. And so on.

Where this becomes important in ITSM is when no one agrees on how to measure something. For instance, think about the warranty measures - availability, capacity, continuity and security. There is no one agreed definition for any of these terms that would allow you to take a set of data and calculate its measure. This causes a lot of headaches as people debate what the "right" formula is to calculate availability, for instance.

The most useful way to think about these terms is to understand why we want to measure these things. Most groups want to measure these things so they can understand how well a service is performing. It also helps them communicate with the customers of their service. 

Do we need the "correct" calculation in order to do these things? No! We just need to calculate it in a way that is credible to stakeholders and that correlates with delivery of good service. As long as everyone views the calculation as reasonably approximating reality (as they see it), and helps them focus on what areas to improve, the measure is as good as it needs to be!

So the next time you're struggling with metrics, ask yourself why you're trying to measure something. As Lean principles state, overproduction is waste. Don't try to produce a perfect measure when a decent one will let you do what is needed to deliver value!