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.

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.