We all get it wrong sometimes
In a previous blog, The customer is NOT always right, I wrote about the importance of understanding the outcomes your customers need, rather than simply delivering the output that they have asked for. What I didn’t mention was that we ALL have similar blind spots. We approach situations in what looks, at first sight, like the obvious manner, and then find that our solution is taking too long, or costs are escalating, or it isn’t working out as well as we’d hoped. Quite often, this is because we haven’t stopped to think about the outcomes we want and so we are doing the wrong things.
I was reminded of this recently when I tried fixing some hooks to the back of a bedroom door. My first attempt failed because the door panel was too thin and the screws came straight through; ugly to look at and a menace to unwary fingers. So, I fixed the holes in the door and tried again with self-adhesive hooks. This did work for a while, but eventually the weight of things hanging on the hooks was too much for the paintwork, and the hooks came off, dropping things on the floor, and jamming the door to boot. I spent quite a long time thinking about what I could do to get hooks to stick to the back of the door before I finally realized that I had made the same mistake as I identified in other people. I was so focused on fixing hooks to the bedroom door that I had forgotten my goal – I needed to use the space behind the door for hanging dressing gowns and towels. After that, the job was straightforward. I mounted the hooks on the wall, so that they were behind the door when it was open, and everything worked perfectly.
It’s important to think about the outcomes we need in every aspect of IT. Most people know that this applies to designing the services that we deliver, but there are many other aspects of IT where it’s easy to get so caught up in routines that we forget. For example, there are many things that we do in IT service management (ITSM) that are more focused on following a procedure than on achieving an outcome. Some of the more common examples of this are:
- Discussing changes in a CAB. Many IT organizations have a change advisory board (CAB) that meets on a regular basis to discuss changes. The purpose of these meetings is to decide which changes should be authorized. Now there may be a few particularly challenging potential changes that do have to be discussed by a change management board meeting. But if we remember that the real purpose of routine change management is to facilitate the rate of change our customers want, while protecting everyone from the negative impact of change, it becomes clear that most of the time there are much simpler and more effective ways of working. For example, we can automate as many routine changes as possible; we can subject changes to peer review; or we can simply make people accountable for the impact of any changes they implement.
- Insisting that every incident is logged by phoning the service desk. Many IT organizations do not allow technical staff to help customers unless an incident has been logged with the service desk. In many cases this rule was introduced when the service desk was first put in place, and it enabled technical staff to prioritise their work, and avoid excessive interruptions. This was a great solution when it was introduced, 20 years ago but things have changed since then. If we want to make improvements, we could just think about ways to log phone calls more efficiently, but if we do that we’re stuck thinking about process and not about outcomes. There are often much better ways for customers to request help. We need to consider web-based self-help, walk-in genius bars and the many other options available for improving customer experience. If we just think about how to log phone calls more efficiently then we miss many opportunities to do a better job for our customers.
- Deploying releases once a quarter, at the weekend. Batching changes up into releases, that are extensively tested and then released at a quiet time when nobody is working, is another approach that some organizations haven’t reviewed in a long time. There is now lots of evidence to show that releasing smaller changes much more frequently leads to fewer failures, and faster resolution of the few failures that do occur. But in some organisations, the smooth working of an outdated release process has become the goal, and staff have lost sight of the real goal – releasing changes as efficiently and safely as possible. It is much easier for release managers to recognize that they need to fundamentally change how they work once they begin thinking about outcomes.
- Producing monthly service reports. Almost every IT organization that I work with produces monthly service reports which are delivered to their customers. They often don’t know why they do this, except maybe that “The SLA says we will produce monthly reports”. There is often a lot of effort required to produce these reports, and yet the report content may not be particularly relevant to the needs of the customers. If an organization really understands what the reports are for they can do a much better job of providing what a customer needs. For example, this might be a dashboard providing real time data whenever it’s needed, or maybe exception reports, or just a simple email with the most important two or three metrics.
I hope these simple examples have stimulated you to think about why you do some of the things you do. Could you deliver much better service, with less effort, by focusing on the outcomes you’re trying to achieve, rather than continuing to produce the same outputs as you always have?
As always, please let me know if you try any of the ideas in my blog, and share how this works out for you.
Image Credit: Stuart Rance