Learning to Run

I had developed aches and pains from running because I had picked up a few bad behaviors by emulating others rather than looking at my own individual technique. The same is true with IT. Without knowing the users you serve, the context that they work in and what they need to achieve you could do more harm than good by doing what everyone else is doing.

Last year I started training for a half marathon. I frequently ran with a coworker who was fitter and faster. In order to keep up I started changing my running style, copying hers.

It started out pretty well. My speed and distance increased as the weeks went on but then I started to get some aches in my hips. No matter, I self-diagnosed the problem on the internet and kept going– no pain, no gain as they say. A couple of weeks before the half marathon my knees started hurting. This time it was severe enough to prevent me from running. So I did something you might think a little strange – I went back to school to learn how to run. The first thing I was told was that that the hip pain was the first warning sign that I was doing something wrong.

Most of us think running is easy. If we haven’t run before, we watch our training partners, athletes on TV, or find an internet article to teach us. At running school I was shown a video of how I run and all my bad points were highlighted in Technicolor detail. What I actually learned was that I had developed aches and pains because I had  picked up a few bad behaviors by emulating others rather than looking at my own individual technique. In addition, I needed to be aware of my location when I was running so that I didn’t cause undue stress to my joints and body in total. The result was that I received a program tailored to me after completing my first half marathon. I’m looking forward to running my next one soon.

It’s well known that the biggest issue that IT faces at the moment is improving customer satisfaction. Most articles suggest all you need to fix this is to reduce the time taken to resolve incidents for your users and the problem will be solved. However, there is a lot more that you need to learn about your own customers and what is best for them before you try to solve the problem.

Why? Because in many cases an assumption has been made based on a set of standard service desk metrics that are pumped out every day or week grouping together all customers no matter who they are, where they are and what their priorities of the moment are.  I’ve read on forums about many service desks who want to know what the industry average incident resolution time is or cost per incident should be so that they can take steps to emulate these stats. They are prepared to do whatever it takes to meet them from changing tools to re-organizing their teams.

But it’s time to stop running and learn about the users that make up your organizational body of customers – where and when they experience IT-related stress and strain and what workarounds they are putting in place themselves that could cause more serious concerns for the IT organization further down the line.

Without knowing the users you serve, the context that they work in and what they need to achieve you could do more harm than good by doing what everyone else is doing. f you are going to last the distance and make real improvements in your customer satisfaction, you need to listen to your customer body and understand the individual outcomes they want.

User Oriented IT – as a well-known slogan states “Just Do IT”