IT Management Blog: my thoughts about putting the "i" in IT

Do we correctly explain IT to our customers?

Ever since the discussion that appeared on LinkedIn “What Are The Things We Hate About IT?” following a book by Susan Cramm.I have been thinking about one of the items brought forward: Do we hate other departments just as much? For example, would many of the “hate” things not apply to the Finance department as well?

I recently needed to undergo a knee reconstruction because I tore my ACL. Before I decided to get the operation done, I wanted to know more about it. Initially you have your appointments with the doctor and he explains a lot and gives you also some brochures. But I still had many questions. I did research as much as I could on the Internet but the exact details cannot always easily be found. Much medical information is locked behind sites for which you have to pay, besides the fact that it pretty much becomes very technical in medical terms.

However, once I had this information processed and had thought about it, I came up with many more questions. And these can of course only be answered through another appointment for which you have to pay good money again.

And then there is the general customer service. The assistant on the phone, just for making an appointment, did not come across too friendly either. As if it was all too much. You probably know these type of people – everything comes with a big sigh.

And then the costs. Yes they explained the costs for the surgeon, but I still had to chase up the costs for the hospital and the anaesthetist.

Now you could say, “Why don’t you go to another surgeon?”. Good point, but this one had a good reputation and you then need to ask yourself the question whether you want a surgeon who will technically do a good job or that you want better customer service but with more risk on the technical outcome.  I think you can guess, what I chose.

I think the issue for IT or for the Finance departments is the same. Good customer service is hard to find - anywhere. I have always found in any organisation that for example the Finance department is not too forthcoming with information. They have in general (also) an arrogant attitude. They set the rules and the rest has to follow.

The biggest issue here is that people hate the uncertainty and the lack of insight. My problem with the knee operation was not much different than the “IT is too expensive” complaint. I simply don’t understand why it all has to be so expensive and then the problem identifying all the associated cost. And then the risks. There were so many different aspects and risks around it that it simply took quite a bit of time to understand it all.

Just as I still have a lot of uncertainty around my knee of what I can do and what I can’t do, people hate the uncertainty when they are confronted with a (new) system. Understanding the complete behaviour and working of a system is too often too far away for the end users and they get by with a superficial understanding. And then there is the lack of insight in all the processes and components that all make up the story of higher costs, more time and more practical issues that the business user does not expect to be involved.

The contradiction in all this is that our business colleagues don’t have the time and the background to understand all the intricacies around IT. The same problem as I had. Though I could find medical information, it was too much abracadabra. But on the other hand you want to have just that right level of insight and confidence on how it goes. As service provider it becomes very difficult to explain why things need to happen a certain way while not going into the details. It is difficult for a doctor and it is difficult for an engineer (or CIO for that matter).

Coming to a conclusion, I think that it will always be difficult to make our IT customers understand all aspects associated with IT and therefore they will remain “uncomfortable” with it. This “uncomfortable” feeling is not much different than what we experience with a doctor or dentist or the rules and laws of the Finance department. To what level do you need to explain things? Some people will never get certain intricacies and others simply don’t have the time.

And in relation to customer service, to give another example outside IT - what about the banks? When I came to Australia I was confronted with bank fees. I did not have that in the Netherlands and it took a lot of time and effort before I found someone who was willing to explain it.

Yes, we should continue to improve our services and explain IT within the organisation, but I don’t think that we’ll ever achieve a Walhalla. At some moment in time, you just simply need to focus on results. Do we really need to be so much better than everyone else? Or in other words, is it really that bad?

At the moment it seems that the doctor did a great job on my knee. If you would ask me whether I was satisfied with the service, I say yes. He did a great job. Do I have general issues and could the service have been better? I definitely say yes, accepting the grumpy assistant as long as the result is good. The same applies to IT. If we deliver systems, isn’t it firstly about whether the business can achieve their objectives? Ok, the problem is why it takes so long. But my knee has a fixed 6 months healing process and there is nothing that I can do to make it go faster.

(As you can see on the photo above, my knee looks perfect again.)

Be cautious with helpdesk KPI’s

To measure the effectiveness of your IT services department, usually the first measurement you put in place is around the helpdesk. Gus Monne's blog post started me thinking because we do basically the same.

In the past we have reported for example on the number of calls received, calls resolved and calls outstanding on a periodic basis. I've always been reserved on publishing this information to the internal customers and senior management because they will only see the numbers and do not understand the stories behind them.

First of all, what does it mean to have received 500 calls in a fortnight? OK, you can benchmark it and compare it to averages with other similar organizations. But still, it does not mean that much to me. It might just mean that your users are not that IT savvy and there is a culture to call the help desk as soon as something unexpected occurs. By itself interesting insight and you might want to change the culture of the organisation.

Secondly, does it mean that your services have degraded if the number of calls have risen in the last three months? You might have rolled out a new system and the increase in calls can therefore be expected. Or the increase in calls was caused by a significant staff turnover in the last period.

If you have rolled out a new system and you can expect the number of calls to increase. In such a case the stats are not a direct measure of the helpdesk and in the early stages relate to the effectiveness of the project. Because you will run in many teething problems and the fact that the helpdesk also needs to build up experience, many of those calls have to be redirected to the second level support and to the engineers. The first line helpdesk team has quite often no direct means to resolve these.

And think about this. If you roll out a new system and you do not receive many service calls, would that be because the system works fine and users are using it effectively or because they are not using it? And when you are receiving many calls, can it be because the users are very keen on using the system and are going through a steep learning curve and therefore log many calls?

In the past I inherited a few systems that were rather instable and regularly went down and threw up java errors. The systems had many bugs and the effect was that we spent most of our time fighting fire. Over time we improved the stability and our development practices. Some of the systems were rebuilt from scratch. The end result is that those systems are stable  and basically we don’t receive any calls around problems with the system. We do receive calls in relation to new functionality and that is where we want to be. Spend our time on improving the business with new features instead of fixing bugs and restarting servers. The effect can be seen in the statistics in our helpdesk system but they can only be seen over a longer period of time stretching years.

The calls that come in relation to those systems are not going to be dealt with straight away. We plan this in our development process and prioritise them with our customer. It means that some of those requests stay open for a longer period of time. Basically they are not really helpdesk requests but we use the same system for it.

If you want to measure the effectiveness of the helpdesk itself, you can only look at those calls that fall in a category where there is stability and where it is expected that the helpdesk actually can resolve the calls. Proper classification of received calls is crucial to any reporting.

There is a difference in the role of the helpdesk in case you have a small set of business systems with a large number of users or when you have a large number of business systems with each a small number of users.

I had the pleasure to contact my ISP because my ADSL line was regularly dropping out. The ISP provides a standard service to a very large number of customers. The helpdesk has been provided with a script of questions and steps to go through to resolve the problem. In such a scenario this is very well possible and you can resolve this way the majority of calls. (Though in this case it was driving me crazy; needed to call many times and each time you get another person who wants to start the whole thing from scratch.)

But the scenario of the ISP is rather different then we have in our work situation where we have a relative large number of business systems with each a relative small number of users (excluding our real external customers for which we don't give helpdesk support through our IT department).

I have my doubts on just reporting helpdesk statistics as a KPI and I think you should be cautious reporting those numbers as the performance of the IT department to your customers and senior management. The numbers can be valuable if you actually analyse the cause, draw consequences and take measures for those causes within your own control. But without an explanation, the numbers can give a wrong impression of what really goes on.

I am not saying that you should not do the measurements. Of course you need the numbers for a variety of reasons and you still need to address the cause of increases of service calls and understand why it happened. Another reason is to manage your workload.

I am more keen on using surveys to identify effectiveness of the IT services as Gus also reports and using the Service Level Effectiveness as per Gartner’s Business Value Model

Service-Level Effectiveness = Surveyed users with >=90% satisfaction/Total No of surveyed users

This measures all aspects of the services including, and most importantly, the actual user experience. For example, when you just rolled out a new system and have a high level of service calls, the users still can be satisfied with the service (they love the system and the helpdesk provides great assistance). Or it could be completely the other way around, only a few service calls but low customer satisfaction.

Personality profiling, Part 3 - Ideas versus reality (Plato’s Return and Design Thinking)

Part of the TMS profile (see previous post) was the question to which you related better: “idea” or “reality”. It was an all or nothing question.

For me this is a bit sort of an chicken and egg question. Of course I like to stay with my feet on the ground, specifically in work situations and don’t want to walk around the whole day with my head in the clouds. But that’s not what this is about. The idea always comes before reality and specifically for us in IT, where we can mould our IT reality as much as we like, we should know this.

Before we build a system we should have an idea about how it will work, what it should do and how we will put it together. Before we have an idea about the system, we should have an idea about the benefits and why we want it. What is the business outcome?

But if we have an idea or a series of ideas, we should bring it into reality. And from that moment on we must be very practical in identifying all steps and resources to get the required outcome. And then we need to look at the reality of the business benefit and the business outcome.

So we start with our heads in the clouds and need to be creative and identify options but at some stage we need to focus on reality.

Idea and reality are two different aspects of one and the same thing. Reality does not exist without an idea and ideas are just dreams if we don’t turn them into reality.

I’d like to refer back to Plato’s Allegory of the Cave where he postulates that we don’t really know reality but just have an idea about what it could be. The idea is the shadow we see on the wall, a reflection in our mind. Quantum mechanics and string theory confirm the fact that there is no clearly defined reality. [see also my first post]

Ask 10 different people what your business reality is about a specific subject or business process and you will get 10 different answers. So reality is not something black and white; it has lots of shades of grey. And you can’t run your business without ideas. Ideas are the driver that makes the business move forward and grow. The trick is to turn the ideas into reality.

Roger Martin combines in Design thinking: achieving insights via the “knowledge funnel” in the magazine Strategy & Leadership both concepts in what he calls Design Thinking. He describes a knowledge funnel – a process starting with a Mystery (triggered by intuition ; idea) via the development of Heuristics to a structured Algorithm (reality). The process is the analytical process but you need regularly go back to your guts feeling and try things out and see if you can develop your heuristics and algorithms to see if your guts feeling was right. This is how he sees modern organizations should operate to develop their products and processes. Organisations that are driven by creative thinking alone or by analytical processes alone will be less successful.

Coming back to my previous post about interpretation of questions and the consequence of the resulting profile: once you have thought a bit longer on the subject, I bet that there will be people who at first might have answered one thing but after a bit of thought such as considering the subject from a different perspective as what I have attempted to here, might opt for the other answer.