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?
As a follow up to my Beginner’s guide to meeting etiquette blog, Stuart Rance asked for thoughts on online / phone meetings.
We don't want meetings like this, do we?
So, where to start? Well, again in no particular order :
Let me know what else should be part of meeting etiquette. Let's change this meeting filled world!
Ah! Meetings. Whether we love them or hate them, we all have to attend them. So why do so many people get it so wrong?
A tweet from Kirstie Magowan, which in turn referenced an article written a year ago by Greg Savage called No, you are not ‘running late’, you are rude and selfish, got me thinking about how few people understand or consider meeting etiquette. Having to then cancel a meeting with somebody today, I thought I would share my thoughts with the hope of gathering your feedback and compiling a definitive set of meeting etiquette rules.
In no particular order:
What have I missed out? What should be included? Let me know your thoughts and let’s see if we can change the world, bit by bit.
I'm currently putting myself through training on ISO20000 which is the international standard for IT Service Management and am learning about the audit requirements. Reading through the types of audit and the steps that should be undertaken reminded me of something an old boss (old as in previous, not ancient) taught me when we were about to be audited for ISO9000 re-certification. It stuck in my head and so I thought I would share it with you in the hope that it helps you with your next audit.
Why do we get audited?
I pay a membership fee to a certain international hotel group, so that I get preferential rates, upgrades, etc. You know the deal. I'm sure that if you travel a fair bit for business, then you are a member of something similar. When you join or renew, they provide you with a free night in any hotel. Great deal. They also provide you with points, which you can redeem as vouchers to pay for accommodation.
Now, I have tried to book two rooms, for two nights, so that we can be tourists in a lovely part of this great country, en famille. I contacted the hotel I wanted to stay at and they were more than helpful. They could provide us with the exact rooms I wanted, at a good rate. Unfortunately, the hotel are unable to provide the booking for the freebie over the phone. I have to do that on line. This is where it falls apart. To reclaim the vouchers, I have to decide if I want to reclaim them in USD or EUR. I'm in New Zealand, so am not interested in these currencies. I considered it would be easier to contact the freephone number and book it all over the phone, because I wanted to make sure I knew how many vouchers I would need, and how much it would cover. The helpful young lady overseas advised that I couldn't use both on the same booking but changed her mind after I requested to speak to a manager. Trying to complete the booking got very complicated due to language differences, so I will try again tomorrow.
Now I am not here to tell you that any particular French hotel group is wrong or right in the way that they operate, but this seems like a prime example of how companies can get customer service wrong.
If you are going to offer special deals and freebies to paying customers, then it should be easy for them to reclaim them. I spent 20 minutes talking to people before I lost the will to continue. I shall try again tomorrow. However why should I need to go through this? Why not offer the customer a simple way for them to reclaim the offers? Why not allow the front desk the ability to take a booking and the computer system handle the promotional codes.
The trouble is, I have seen this type of thing on too many Service Desks as well. You want a new piece of software? You go to the Service Desk and ask them. I have seen Service Desks where they use tools to provide a Request Catalogue, and work flow the request to all parties concerned. This makes life easier for the customer / user. However I have seen situations where the customer / user is passed from pillar to post and left bemused and frustrated.
How do we get this right? This will sound easier than it is. Bear with me.
Firstly, it is about understanding what your customer (I use the term for ease, instead of customer / user - I know it annoys some skeptics, and I wouldn't want to do that). If you know what they want, you can try to provide them with a simple or easy way to achieve that.
Next, understand what you can or cannot deliver. What are the services that you provide? What do you rely of others to provide? Where are the lines of delineation? Do you need OLAs (Operational Level Agreements)? I would recommend against them, as it creates a non-team spirited approach.
Make sure you have a simple way of passing information between dealing groups. Once you understand how you will do it, by all means use a tool if it is justified. Please don't jump at the first big-named tool you see because you have read good things about it. Work out whether it will deliver what YOU want and need. There are many very good ones out there that cost very little.
Once you have this worked out, understand how you can measure whether what you deliver is actually delivering what the customer wants. And the cycle continues.
So why does it seem so hard in areas and industries whom we are supposed to look up to?
Is it me?
Not so long ago I came home to a notice from daughter number 2's school. The school was planning a beach trip to participate in an "Education Outside The Classroom" programme. We are, of course, expected to pay for this, on top of the "voluntary donation" that we are expected to pay each year. That isn't my issue. What I am concerned with, is the fact that one sentence says: " Chidlren will be carry their own packed morning tea...." Chidlren??? They "will be carry " will they?
So this is by the people who are paid to educate our children? What steps are put in place to perform quality checks on the work that the educators perform? By the look of this note, and some of the notices / posters around the place, none.
So, Is it me? (I fully expect that I have misspelled words or even made grammatical errors, so no chocolate fish for spotting them)
However, what quality checks do we put in place within our workplace? Do we check that the communications we send out are accurate and timely? Do we check the quality of the builds we do when handing over a new PC to a customer, or a new server? How many changes fail due to errors - do you know or measure it?
There are many quality checks that we ought to be making on a daily basis, but don't. The time has come to start to improve in this area.
Checklists are essential, yet so often overlooked, because we are so busy. +Rob England has made a good start with his Basic Service Management site which I recommend, but I would recommend you to think, write and review your own as well, to make sure that you check your own and your team's work.
Remember, it's all about perception.
Communication. Essential when keeping customers updated and informed and also for gathering feedback. It's a two-way thing.
During a normal day's work, keeping that communication flow going is relatively simple. Talking to people, whether formally or over a coffee, is what we do. Giving information is part of life and work too. No biggy.
However the time that you really have to focus on it because it is easy to forget, is when you are busy. If all around you is melting, and you feel that everyone and everything is on-top of you, communicating properly can slip off the desk so easily.
How do you get round this?
The simplest method to ensure that you do what you are supposed to do, and when, is to have a checklist on your desk, or stuck to your wall, but in sight at all times. Then, when the world turns to custard, you know what you are supposed to be doing.
It can be so easy as a Service Desk co-ordinator to get side tracked and forget to call back a customer when you said you would. You don't always need technology to help with this - write a sticky note and put it where you will see it. This may be your screen, telephone handset or your coffee cup. If it's important, leave yourself a few. You might feel daft, but you won't be letting down your customer. If you are an SDM / BRM / Major Incident Manager / Somebody who is responsible for updating stakeholders during major incidents, make sure you have a checklist right in front of your eyes at all times, so that you know who you need to update and how often. They will thank you for updates saying "It's still being worked on, further updates will be provided in 30 minutes" but get really annoyed if nothing comes out, even if you have nothing.
So just have a clear, clean sheet of paper stuck to your desk, or somewhere you can always see it and use it. It might just make your work life easier.