With all the hype recently around the release of Apple's new watch, there appears to have been a plethora of blogs telling us how the helpdesk needs to be ready for the influx of calls from people wanting to use the benefits of wearable tech for work and how the helpdesk needs to address issues like security, compatibility with existing software and hardware and the information "stored on them".
None of this is a role for the helpdesk. Just as with smart phones and tablets or people's personal laptops or palm pilots, this comes back to governance.
Do the governors of IT want IT to allow smart watches to be used in the workplace? I doubt they would be able to consider all of the risks and benefits so this is where IT (maybe in the form of the CIO) needs to advise the governors. When they have all the information, they can make an informed decision. Then they can direct IT to allow certain things.
Without this direction, IT don't allow anything.
If the governors decide that they do want to allow wearable tech within the workplace, then it is still not the helpdesk that addresses the issues mentioned above. Information Security will consider and address information and security concerns, compatibility will be undertaken by architects. None of that is the helpdesk.
When everything has been considered and all risks mitigated to an acceptable level, then the helpdesk and other support teams (who we hope have been involved in the design of any changes) will receive all the appropriate information BEFORE go-live, so that they can support the users. Until then, nothing is supported.
So pundits, before you start scaremongering, just consider who DOES need to address concerns and when. Let's get the governors governing and IT managing. It's like Government and Police. The Police (IT) are suppose to uphold the law, and the Government (Governors) set the law. (To follow that analogy a bit, see the IT Skeptic's To Protect and Serve)
Many organisations know about this thing called IT Service Management and hear consultants claiming to have the come up with THE silver bullet to take away all your pain, or the new shiny, washes whiter than white approach, but ...this is article is about the things that can go wrong and the successes in the real world.
I would like to discuss some areas where things can go right and be worthwhile, where things can and have gone wrong (speaking from experience) and what lessons can be learnt.
The initial areas are:
Resistance to Change
Resistance to any type of change can come about through many different ways.
1. – Cultural changes - This can range from the implementation of new team structures or shifts to new management coming in or a reduction in team sizes. Many different areas cover cultural changes and can lead to resistance. We’ll cover this is a bit more detail further on.
2. – Resistance by customers or users. Change can be seen by customers or users as just another way to make life harder for them, or to remove their favourite support technician from their grasp.
This is a key area that needs to be addressed as early in the change process as the team members being affected. If you get this wrong at the start, it can take a lot longer to put right later.
3. - Something I have seen but did not expect was around changes to Service Management toolsets. One of these issues was partially of my own doing and one was at a client site before I started there.
I’m sure we have all worked somewhere where the main Service Management toolset has not been to everyone’s liking. Either it’s not intuitive, there’s too many fields / not enough fields, reporting is cumbersome, the screens doesn’t look pretty enough…..
Yet I have been in organisations where changes of toolset have brought about resistance from the most unexpected areas. Many people just don’t like you to change the tool that they like to complain about. The best way around this resistance is to engage as many people as you can.
Key users will, of course, be involved in the process of understanding what was wrong with the old one and what is trying to be fixed. These people will be the main inputs into your requirements gathering exercise. (You are doing that, aren’t you?) However, don’t forget to ask the team that use the tool occasionally. Their input is just as important to the success of the project, as anybody elses.
Also, don’t expect that just because people sign off on a new toolset and agree that it will deliver all of their requirements, that they will be happy. We are dealing with people here. Of the holy trinity of People, Process and Tool, People are the hardest ones to get right. But also the most important.
The pain of this resistance to change; what can go wrong?
Poor team spirit
If this isn’t handled correctly, one person’s negative view of a change can bring down the rest of the team’s view. Too often I have seen a minority, change the majority’s mind-set through continual complaining and negativity.
This poor team spirit has the ability to also be concentrated on the management or leadership of a team. “Why are you allowing this to happen to us?” It may have one positive aspect, of pulling the team together, but if it is still in a negative way then that helps no-one; you still have resistance to the change and that can take months to put right.
If you discover a negative aspect to somebody’s attitude, address it a quickly as possible. This does not mean that you crush them, but rather you understand the issues and address them in the best way possible. This might require improved communication or training, or a complete re-evaluation of the approach and change of direction.
Potentially the worst of these areas of resistance, however, is a breakdown between the teams and the users or customers.
This is generally for a couple of reasons:
Your customers won’t talk to or work with the team because of the negative attitudes or disruptive ways of working (see above), or the customer will ignore new ways of working because they “liked the other way”.
If customers won’t change and they continue to do things like ring their favourite person direct, then that is harder to address.
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.
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 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?
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.
Major Incident Management
To my mind the three areas, outside of event management, that really improve the way that major incidents are handled, are communication, learning from the incident and being transparent.
In IT, we are not an island. We are a core part of most organisations now, whether they and we like it or not. We have to share what is happening, what we have learnt from the incident and what is going to happen to reduce the chance of it happening again. Otherwise, how can we even hope to be trusted?
I have seen IT teams embrace the opportunity to operate, during major incidents, with heads down in a locked room keeping information secret thereby increasing the chance of recurrence.
The trouble with being like this is that the wider organisation starts to accept that this is the way it is. So they don’t complain formally, they just moan to each other.
And in fairness to IT, how often do you see a review of a failed marketing campaign? Or a full and frank review of a failed pay run (apart from to blame IT; who ever heard Finance say that they should have had business continuity plans in place because they accepted that the system was not resilient when it was implemented?)
Get it right however and the pleasure is shared amongst all concerned parties.
Communicate with your customers and users. Let them know what is going on, even if that communication is just to say that you are still working on it. Set up lines of communication. Make sure that the technicians working on the fix are left alone to get on with it, but have one person who gets updates. If you commit to telling users every 30 minutes or hour, get an update 10 mins before. Keep telling people what is happening. AND keep the Service Desk updated.
When the service is restored, carry out a full review. What went well and what didn’t. Keep to the facts. No emotions. What infrastructure components failed. Can resilience be done better? Should the service be resilient if everyone in the rest of the business was jumping up and down? Should processes inside or outside of IT be amended? Set actions. Set timeframes. Follow up on them.
Share the outcome with as much of the rest of the business as possible. If there has been a failure and you have a plan to mitigate the chances of this happening again, tell everyone. If you have a piece of work in place and it is being progressed, but the issue reocurrs sooner than you can finish the remediation, less people are going to complain than if you had done nothing.
Use the incident as a driver for good.
Service Management Life Lessons Learnt
Some key lessons that I have learnt that I would share with you on removing some of the pain from Operations and Service Management.
Don’t be afraid to bring in consultants, but find ones with real world experience. You probably know what needs to be done, but do you have the time to think it through and implement the change, while also doing your day job? Probably not.
Don't be afraid to take advice and use a mentor. Other people's thoughts are sometimes the clarity you need when the trees are hiding the woods.
Don’t forget to ask the people on the ground what is wrong or what can improve. They have good ideas; often the best ideas.
Ask a lot of questions before starting.
Don’t try and do too much too quickly. Keep going for the “low hanging fruit”. It’s always there and it’s always easier to do that than try and pick all fruit in one day. Look up Tipu by Rob England.
As a consultant, remember, you don’t know it all. You can learn from each client. Admit it to them and yourself. Also, use your peers. Accept that other people can sometimes do things better, and generally will help.
Why would you want to attend a conference that takes you away from your work and costs several hundred or thousand dollars?
That is a very good and important question. You may only have the opportunity to attend either a training course or a conference in a year and a training course looks so much better on your CV, doesn't it? Or does it?
Training, while important to your current employer, addresses an immediate need. Your employer has identified a need for you to have a particular skill set, or you have convinced them during your annual review process, and so it is signed off. "Go and find the training course you need" (before the training budget is slashed).
Conferences probably come from the same budget as your training, so it is fighting for the same opportunity. However conferences are often not going to address an immediate need. They address a long-term desire. Attending a conference will allow you to meet, talk to and listen to other people in similar roles as you, but in different organisations. You will learn about the mistakes they have experienced, the improvements they have made and the ideas that this will spark will enable you to often identify improvements in your current workplace. It will also enable you to network with other people and talk to those people throughout the year. I've never met somebody at a conference who has said that they are happy to talk about things when everyone is back at work, and not meant it. If they are at the conference, they generally enjoy their work and want to grow and help others to grow. So when you get that sticky piece of work and are not sure who to talk to, call upon your network. Someone will have been there before or will be happy to think and talk it through with you.
Conferences are also where vendors are. These are not the terrible people that your mother warned you of, but the people who have products that will probably help you in your job and help keep the cost of your conference down to a level that means you are more likely to be able to get it signed-off. By talking to these people, you will learn about different ways of doing your job, different products to ease the way you do your job or you may even be able to talk to a subject matter expert in the product you currently use to understand what you could do differently, or why you should push to get the latest version in your organisation.
Conference attendance also, in my view, looks better on a CV. It demonstrates maybe not enthusiasm, but enjoyment of your role or skills, and a desire to improve. That is more important in the long-term than a 3 - 5 day course, unless you need to plug an immediate gap.
So get along to the local conference of your choice. There may only be one a year in your country, or there may be several and you have to pick and choose. Many conference organising teams will also be happy to help you justify your attendance if you ask.
I find that the itSMFnz annual conference, and the branch meetings, are a valuable asset for all of the reasons above, so maybe I'll see you at one of those?