In the second part of this three-part series we continue to examine the good and bad around change with this discussion around resistence to change
Many years ago I worked for an organisation where support across multiple sites was being centralised through a single service desk and the on-site support technicians were only supposed to respond to calls through the system. Of course, all users were told what was happening and why, but for some it made no difference. As a technician, it became difficult because our raison d’etre was to help people.
Eventually after few weeks of new processes being ignored by some users and senior IT managers complaining that we were bypassing processes to help these people, we discovered a way forwards. Each user that approached us, we would go and help, but ask them to log the call while we were there. Next time, we would advise them that they would be there shortly, could they log it. Then a few minutes later, go and help. The next time this happened, we would say the same thing, but as soon as they left to log the call, we would pre-warn the Service Desk and give them hints on likely fixes / knowledge articles. This enabled the Service Desk to fix the call while the user was on the phone, creating a good impression. Within a few short weeks of this type of approach, we managed to get over 95% of “walk-ups” to go via the Service Desk first. The other 5% took months to train properly!
Good ways to prepare for this are through good planning and considering all ways that the teams might either be, or feel affected.
The Pleasure
Now, the pleasures of these changes that people can be so resistant to.
If you get your changes right, and bring people, teams and users, along on the journey it can be so fulfilling. You have improved ways of working which the majority of people within your teams and user or customer base will acknowledge.
You will get respect from your customers, because they can see what you are doing and why. If they understand and respect what you are doing, it will become so much easier to keep the momentum up. You will be able to demonstrate the improvements.
Implementation of Event & Availability Management
These two are often a pair. It’s unlikely you will do availability reporting without event management. They provide visibility of what is happening, or going to happen, to support teams and if set up in such a way, to customers as well.
It can also provide assistance to support teams, to enable them to see what else may be affected in an incident or change.
The Pain
The pain of not having effective event management is something that I would like to guess, we have all been through. As a support team member – Service Desk, technician, problem manager, change manager, IT manager, – you need to know what is going on. If you don’t have those tools, it can be a nightmare.
The phone rings and a users asks if something is wrong with web access. Straight away you are on the back foot. Service Desk agent tries it and it works. Another one tries it and it doesn’t. What’s going on? Is it the site? The computer? The switches? The web monitoring application? The server? Firewall? (we all like to blame the firewall).
I have seen and been part of teams where it has taken what felt like hours to diagnose the issue before the resolution could be considered.
You have no idea what is happening. What went wrong? The correct SME (Subject Matter Expert) is not around, because they were working late last night doing a change, The majority of the support team are investigating so that they know where to go to fix the issue.
No communication can be sent out because nobody knows the full extent.
You are cuffed and blindfolded.
As for availability management or reporting, how can you tell your customers how wonderful you are if you can’t prove it?
The Pleasure
Get it right however, and it just feels, Good!
Firstly you need to know how you want to do it, and then get your tool in place. Spend the time to define a process and then spend more time getting the tool set up right and it will be worth it. It is worth noting that it isn’t all about the big expensive shiny tools. There are some very good, cheap and easy to set up ones which deliver just as much for an awful lot less outlay. However, as with anything, you need to understand your requirements before you buy. Free or cheap may suit you, but another organisation may find that they have a need for a large enterprise wide, multi-national tool.
This will enable you to be prepared – most of the time – because your tool should be able to tell you, somehow, when something untoward is starting to occur. Is it a hardware component? Event log? Traffic between 2 points of the network? You will be able to see it before the users, if all goes well. If you get really good at it, you can even investigate and resolve BEFORE anybody even realised it.
Maintaining them is another. They do not come without an overhead. Change Management / Projects will need to consider monitoring thresholds, licensing, etc. prior to handing over to Operations and somebody will need to maintain it to ensure that the information received is accurate.
But when done right, they are fantastic.
In the final part of this blog series we look at major incident management – good and bad…
