Posted by Joe The IT Guy
on October 14, 2015 in ITSM
The IT service management
(ITSM) event season has kicked-off again, and it’s time for myself and the rest of the SysAid clan to jet off to the annual FUSION Conference
– which this year is being held in fabulous New Orleans. I’ve already packed my saxophone.
Taking place from the 1st
November, we’ll be joining over 1,500 delegates to “roar into the modern age of service management.”
What to Expect at FUSION
Well despite the “roaring” part, I’m assuming that there are not going to be real lions involved (can someone please verify this for me?). Unless of course Roy Atkinson
is planning on serenading us with a version of the Lion Sleeps Tonight
, in full costume, during one of his many presentations (I have it on good authority, from the very honest Sophie Danby
, that he has been known to thrown down a tune or two while sharing his ITSM wisdom at events). Roy
– please give us a heads up if this is going to happen, I will need to bring my camera!
What you can actually expect to hear and see at FUSION is presentations from a wide range of industry-renowned speakers on a variety of ITSM-based topics such as:
However, where things get really interesting with FUSION is the introduction of an array of “modern service management” content. Including topics such as:
That’s right, we’re not just focusing on the ITSM basics anymore – we’re playing with the big boys. In fact, this year the FUSION team is also introducing a brand new co-located event: DevOps FUSION
. Who can guess what the topic of this event is going to be?
My personal recommendations on the sessions to attend from this side of the FUSION party include:
By the way, if you’re not sure how DevOps fits in with ITSM and you can’t wait until (or can’t attend) the conference, then I highly recommend checking out this introductory DevOps whitepaper
from Barclay Rae
Over the course of the last year we’ve definitely witnessed more “modern age” topics creeping into the world of ITSM events, but this is the first time (to my knowledge) that there has been such a heavy focus on this “new wave.” For that reason, I think it’ll be very interesting to see whether or not this convergence of events and change of topic focus is successful.
I’m a big fan of all things DevOps and Agile, and the benefits they can provide to any given organization, but is the wider world of help desk and service desk managers ready for it yet? Are their organizations mature enough to benefit from these “new” (let’s face it we all plug it as “new” but DevOps isn’t new my friends) ways of working? Or is likely to be too overwhelming? Are we just adding fuel to the fire? Despite the sexy nature of these topics, I know for example that if I write an article over on my blog site
about incident management, it receives more than double the amount of attention as a blog on say, Lean IT. What do you think? I’m interested to hear your thoughts.
Go Listen to My Good Friend Stuart Rance
The only thing better than seeing Roy Atkinson dressed as a lion is a presentation by the one and only Stuart Rance
. You can catch Stuart’s breakfast briefing on “We Don’t Do People
” at 7.30am on Monday 2nd
November. Focused on the people issues of IT, Stuart will be sharing his advice around the ABCs of IT (that’s attitude, behavior, and culture). Want to get an idea of what might be covered? Check out his blog
on the same topic.
If you decide to attend (you should), be sure to say hi. I’ll be the groupie in the front row shouting “Stuart, Stuart, Stuart.” I really love this guy. I’m hoping my colleague Dena Wieder-Freiden
might join me in the cheerleading – she’s a massive Stuart fan too.
Come Play with SysAid
While I’ll most certainly be wandering into the DevOps event along with our CEO Sarah Lahav
at some point; we’ll primarily be found with the other SysAiders entertaining delegates over on the ITSM side of the house. Discussing ITSM best practices, showcasing our software solutions, giving away the best swag (portable chargers, plus a “Conference in a Box” focused on customer experience), and just generally being the life and soul of the exhibition floor (as always).
Last year, we also ran a short three-question survey on the future of ITSM
. This time around we’ll be asking you about your thoughts on customer experience (and you can take the survey now if you like!
). No need to leave your name, details, and blood type – the survey is completely anonymous. Unless of course you’d like to win an Apple iWatch, in which case you can leave us your business card for our prize draw (or if you’re a cool kid who doesn’t carry business cards you can write your details on a piece of paper).
Rest assured though, once the winner has been picked your details will be heading into the bin rather than our marketing database. We’ll only add you to our mailing list if you specify interest in our product or request general information about SysAid. That said, we can’t promise that some of the other naughty vendors who favor scanning quantity over quality won’t dip their hands into the bin for the information afterwards…. Just kidding!
Enjoy, Learn, and Drink Lots in the Bar
As always, it’s bound to be an excellent event – if not even more so this year with the introduction of the co-located DevOps conference. If you’re planning on attending, be sure to look me up on Twitter
. Talking of Twitter, don’t forget to keep your eye on what is bound to be an interesting and informative Twitter feed by checking out the #SMFUSION15 and #DevOps15 twitter streams. This is also where you can typically find the latest meet up of industry luminaries (usually at one of the hotel bars).
Not convinced whether or not you should attend? Check out our overview
of last year’s key takeaways to see what you’re missing. It’s my personal favorite of the three major US-based ITSM events (PINK and HDI being the other two) and in my opinion, one not to miss.
Posted by Stuart Rance
on October 8, 2015 in Service Desk
In many organizations there is a separate information security team that deals with all things relating to security. This team is responsible for designing and implementing all the controls needed to protect the organization, and for managing all major security incidents. So why does the service desk need to be involved, and what contribution should it make? Here are five reasons that you should consider:
1. Everyone’s Responsible for Security
The first and most obvious reason is that information security, also known simply as InfoSec
, isn’t just about process controls or technology controls that we can delegate to the InfoSec team and then ignore unless they affect us directly. Good information security depends on a good balance between people, process, and technology controls, where the people controls affect a broad range of personnel in the organization – all of whom need to take some responsibility for security.
Service desk agents, like everyone else in the organization, need to know what information security policies apply to them, and need to take responsibility for following these policies. Typical policies that everyone needs to follow include:
- Acceptable use policies– what you are allowed to do with email, social media, the company network, etc.
- Mobile device or BYOD policies– how personal devices such as laptops, tablets, and smartphones should be managed
- Password management policies– how often you have to change your password, rules about how passwords are made up, and whether you’re allowed to record passwords
- Remote working policy– rules for how people should work from remote locations, such as their home or a hotel room
- Information classification and handling policies– how documents and other information should be classified, labelled, and handled; for example: certain types of information may not be transferred out of a secure location, other types of information must always be encrypted, etc.
- Visitor policies– how visitors to your site should be managed
Your organization probably has lots more InfoSec policies that should be followed by all staff, so you need to find out what they are, and make sure your service desk staff understand and follow them.
2. Service Desks Are the Eyes and Ears of IT
Major security breaches at some organizations have remained undiscovered for many months, during which time the attackers have been able to make off with vast amounts of highly confidential data. Early detection is crucial.
Your service desk is the main interface between the IT organization and the people who use your IT services. This means people who work on the service desk are uniquely placed to understand what is happening within your user community. If they are appropriately trained, they can be a first line of defense against many potential security breaches.
For example, issues such as users being locked out of their accounts for no obvious reason, data being deleted or data integrity being compromised, and performance problems due to unusual system and network usage can all be early signs of something more serious. If your service desk staff have been trained to consider such issues, they may notice the very early signs of an attack and escalate this to the appropriate InfoSec team. By helping you to identify security incidents quickly, your service desk can help change a major incident into something more manageable.
3. Service Desks Can Communicate Information Security Messages to Users
The service desk is in regular contact with users, and you can use this as an opportunity to communicate essential InfoSec messages, to reinforce other training and awareness activity.
For example, you could put a banner message on your self-help portal reminding people never to copy confidential data to portable media, or you could include a permanent message, with the email you send asking a user to complete a post incident survey, about never sharing passwords.
This is a great opportunity for service desk management to collaborate with InfoSec staff, planning how they can help communicate essential messages, and building relationships.
4. Service Desks Have a Major Role to Play in Security Incident Management
Most organizations have a security incident management process that is designed to:
- Log, track, and manage security incidents
- Escalate security incidents to people with appropriate skills and management responsibility
- Triage incidents and implement an initial response to contain the damage and stop it from spreading
- Ensure that confidential information about security incidents is suitably protected
- Preserve evidence that may be needed in case of legal or regulatory involvement
- Investigate and resolve security incidents
- Communicate with stakeholders such as police, regulatory authorities, shareholders, and the press
- Carry out post incident reviews to learn from the security incident
It’s very hard to get all of these things right without practice, so a good InfoSec team will run rehearsals and simulations to ensure that everyone involved is ready and able to take the right action when an incident happens.
The service desk is often the first place to become aware of security incidents, so they have a major role in this process flow. In some organizations, the service desk will also be responsible for logging, tracking, escalating, and managing security incidents. In all cases, the service desk should be involved in the rehearsals and simulations, to ensure that they know what is expected, and to make sure they get it right when a real attack happens.
5. Service Desk Staff Are Role Models
Service desk staff deal with users when things aren’t working properly, giving advice and asking questions. It is important that they are trained to do this in a way that demonstrates behaviors you want to encourage, and avoids any behaviors you want to discourage.
If service desk staff ask users for their passwords, then this implies that it’s acceptable to share passwords, which may later make it easier for an attacker to trick people into giving out their passwords. If service desk staff send executable files by email, or ask users to click on a link to sign in to their accounts, then this will make those users more likely to fall for a phishing attack.
There are still some organizations where the service desk staff need to ask users for their passwords, in order to troubleshoot incidents or to build new computer systems. If this is your situation, then you urgently need to get new tools and redesign your process so that you can stop doing it. You can’t afford to consistently demonstrate the wrong behavior to your users, because it encourages them to do the wrong thing too. After all, you don’t really want train your users to give out their passwords to anyone who sounds sufficiently plausible, do you?
Don’t just leave information security to your InfoSec team. Your service desk staff can play a big role in helping to protect your information if you give them the skills, knowledge, tools, and training they need to play their part.
Posted by Sarah Lahav
on September 30, 2015 in Service Desk
It’s human nature to seek out others to communicate. Through communications we learn, relate, help, influence, and play. Communication is the currency and propellant of our society.
Thanks to technology we are connected and able to communicate more today than at any previous time in our recorded history. We have become ‘digital citizens’ and many of us ‘digital consumers’
Add to this that pretty soon just about any device will be able to interact and communicate with any other device (the infamous Internet of Things
concept), what could possibly go wrong?
Plenty it seems.
From home life, to work and everything in between, it seems a “failure to communicate” is cited as the biggest risk and the primary cause when things go wrong. “I didn’t know”, “You didn’t tell me”, “I didn’t realize”, and the infamous “That’s not what you said” are recognizable claims from the victims of poor or missing communications.
The biggest reason offered, for failing to communicate properly, is time. That is, not enough time to prepare a communication plan to ensure it’s effective, and not enough time by the recipient to read and digest properly.
Hopefully, through reminding you of the key concepts and basic principles of communications, I can help you decide if, when, and how much time you will invest to make sure your communications have the desired effect.
The Communication System
Firstly, communication is the act, by one or more persons, of sending and receiving information as messages. Such messages are distorted by noise from other communications happening simultaneously, and can be additionally affected by a filter (representing local bias, capability, or language) at both the sender and receiver ends.
Communication incurs within a situational context, has an effect, and provides the opportunity for feedback. Communication involves choices and those choices will determine the effectiveness.
Individual and organizational culture permeates all forms of communication.
In any interactional situation, communication is inevitable.
It’s almost impossible to get through any given day without the need to interact with someone, or something.
What’s the longest time you’ve gone or can go without some form of communication? Were you trying to avoid communication, or were others? Have you ever deliberately tried not to interact, only to discover that no response is in itself a response!
Communication is irreversible.
Once a message is received it cannot be taken back. Say something, click “send” on your email, or perhaps flash your headlights at the driver taking your braking distance – it’s done. There’s no easy way to ‘un-communicate’ a message received.
You can of course try to reduce its effect. “I didn’t really mean what I said”. “That’s not what I meant”. “You misunderstood what I said”. Communication is reparable – but at an added and unexpected cost of time, effort, and perhaps the relationship.
Sometimes the more clarification you offer, the worse the effect!
The good news is some communication – verbal for example, fades as soon as it’s spoken. It’s the digital communications that are persistent, and typically un-erasable.
Finally, communication is unrepeatable.
The circumstances that existed and set the context for a previous communication are subject to constant change.
Relationship dynamics, frame of mind, and the situational context are always in flux. As a result you can never recapture exactly the same situation; you can’t simply replay the communication and expect the same effect.
It should come as no surprise when I say the more important it is to make sure the communication has the desired effect, the more time you should invest in planning that communication.
My Planning Checklist
A communications plan is the obvious result of planning your communications, and is typically a written document. It can span a single improvement or change, or an entire program or project, and address the messaging of one audience, or multiple audiences. Here’s my checklist for planning communications:
- Know why you need to communicate. What do you want to be different as a result of communication, what is the purpose of the communication? What do you want your audience to hear, think, and do as a result?
- Create your starting message. Draft your base with a starting message irrespective of audience, tying this back to your purpose. Be prepared to revisit and change this as you address the needs of each audience.
- Consider who you need to communicate with. Make a list of your potential audiences. Exploit any existing ‘stakeholder analysis’ research or taxonomy of stakeholder communities.
- Define the scope of the messaging. Check if each audience is one or more discrete parties; sub-divide and segregate as necessary.
- Characterize and prioritize the audiences. Define a ‘persona’ or set of common characteristics for each audience. For example ‘ VIPs’ versus ‘general workforce’. Rank them by importance to your goals.
- Research and tune into each audience. Locate any available communications, reports, articles, and similar materials from the target audience. Research key objectives, performance measures, and likely problematic concerns. List and compare between audiences. Identify common themes.
- Connect to keywords. Identify and catalog keywords used, key concepts, important language, and culture-specific aspects of the audience.
- Be relevant. Find and define a basis for your message being relevant to the audience. Connect your message to a problem or area of interest for each audience.
- Position your message. Take your starting message and change as necessary to better position it in the ‘minds eye’ of each audience. Establish the reason why they should pay attention to your message over others.
- Assume their position. Put yourself in the position of each audience. Ask “what’s in it for me?” What do these audiences think about the topic or issue? Are they supporters, or protagonists? Will they create friction or remove it?
- Channel surf. Identify what delivery methods are preferred by each audience, and are available to use. What additional resources and costs might be involved? Decide what channels you will use to deliver each message.
- Plan of action. Develop your action plan to develop and combine the messaging with the selected channels, include any special resourcing or elements containing high costs or major risks.
- Develop with agility. Write your key messages for each audience. Be aware of and responsive to changes in circumstances within each audience. Be prepared to revisit any earlier item in this list.
- Time travel. Decide when you need or prefer to deliver your messages, differentiate between important milestones and interim progress markers.
- Collision avoidance. Check for other communication plans, similar messaging activities, or major activities within an audience scheduled for your preferred timeline. Conduct ‘collision avoidance’ – adjusting your timeline or influencing others to change theirs.
- Noise abatement. Subject to the likelihood of collisions competing for attention, are there any other major distractions that could negatively affect the success of your communications plan? If there are, how will you overcome this ‘noise’ and gain the attention you require? Be prepared to revisit items 8 and 9.
- Execute and orchestrate.Execute your communications plan, orchestrating its delivery with any actions of an associated program or initiative.
- RARE – Received And Responded to as Expected. How will you check the message was received and understood as you expected and as you require? Define a means for verifying RARE based upon your initial purpose statement. This could include an online survey, interactive ranking system, or a like/dislike question or prompt.
- Invite feedback. Optionally, communications are designed to solicit one or more of the three types of feedback from the audience based upon the ACE model (appreciation, coaching, and evaluation). The communication may also offer ways in which the audience can become more involved in associated activities – termed a call for action or CTA. Decide if a CTA is required and how you might invite and invoke feedback using one of the common methods.
- Research results. Analyze and assess the results of the communication to verify it had the desired effect. This includes situations where feedback was solicited. Was feedback received, in sufficient quantities, and useful?
The more important the message, the more value there likely is in investing your time to plan what the message is, who needs to hear that message, and what result you require to guarantee success.
If you have an important idea, change, improvement, or project, consider investing time, no more than perhaps 30 minutes, in drafting a simple communications plan for at least one audience using the checklist as your guide.
When you’re done, ask yourself – do you think about your messaging and approach differently than before? Was the difference important and helpful? Do you think your communication will be more effective?
I hope you found this article and my checklist for communications planning helpful. Lets keep the conversation going! Drop me a line and let me know how you are doing and remember…
Communications are inevitable, irreversible, and unrepeatable.
Posted by Joe The IT Guy
on September 24, 2015 in ITSM
If you read my blog
regularly you’ll know that I’ve already written simple introduction blogs related to:
Now it’s change management’s turn.
To misquote Amazing Fantasy
#15 – the first Spider-Man comic ever! – “with IT change, comes great responsibility!” (The original comic quote was: “...with great power there must also come -- great responsibility!”
if you’re interested).
The need for change, IT or otherwise, is an unavoidable part of modern business life, whether that change is:
- Reactive – aimed at resolving errors or to adapt to changing business or IT requirements, or
- Proactive – which could be to provide new products, services or functions; to reduce costs or to increase efficiency; or to increase performance or operational effectiveness
Change management, put in simple terms, is ensuring that such changes are managed and implemented in an optimal manner and with a sufficient level of control. So it’s a process, or collection of discrete activities, that allow organizations to consider, agree, and deploy changes to their IT ecosystem as easily, quickly, and cheaply as possible while effectively managing risk…more on this later.
So to give you an introduction to change management, I’ll briefly cover:
- Where change management fits in
- The objectives of change management
- ITIL definitions of change management
- The “change lifecycle”
- The benefits of change management
I refer to ITIL – the IT service management (ITSM) best practice framework formerly known as the IT Infrastructure Library – a fair bit (you might think too much) but you can quite easily use your own self-created change management process and activities, or look to alternative sources of ITSM and IT management advice such as ISO/IEC 20000
, ISACA’s COBIT
, Microsoft’s MOF
, or even a combination of a few
Where Change Management Fits In
Change – especially uncontrolled or poorly managed IT change – has associated risks, which can potentially result in either business-affecting incidents or problems. In fact, it’s not unusual for service desk personnel to cite poorly-delivered change as a major cause of incidents, even major incidents.
Plus the lack of effective change management, or the inability to demonstrate the right change controls, can be a major stumbling point in both internal and external compliance audits. Some common compliance concerns include the answers to questions such as:
- Is there adequate separation of duties between the key roles in the change management process?
- Are change requests approved and prioritized by appropriate personnel, including service owners?
- Is change impact thoroughly assessed?
- Are there detailed audit trails for all changes?
- Is there a process for tracking the progress of critical changes?
Thus, change management has a very serious purpose, to:
- Optimize, so not necessarily to minimize, IT and business risk exposure associated with the change (given that some risks might be accepted and managed accordingly)
- Minimize the severity of any impact or disruption brought about by the change
- Ensure the change is delivered first time and without the need for rollback and/or rework
- Provide business stakeholders with appropriate and timely communication about the change
Finally, change management is a commonly adopted ITIL process, usually second behind incident management
in terms of frequency. It’s also an early-adopted ITIL process, either paired with incident management or configuration management.
Change Management Definitions
It’s time for me to get all ITIL
on you as we look at what change management is!
ITIL uses the term “change” to describe:
“The addition, modification, or removal of anything that could have an effect on IT services.”
Where change management is:
“The process that ensures that standardized methods and procedures are used for the efficient and prompt handling of all changes, in order to minimize the adverse impact of any changes on IT services and business operation.”
So that’s sort of what I said earlier but said in a much fancier way.
Other common change-related ITIL-definitions include:
- Request for change (RFC) – “A formal proposal for a change to be made. It includes details of the proposed change, and may be recorded on paper or electronically. The term is often misused to mean a change record, or the change itself.”
- Change advisory board (CAB) – “A group of people that support the assessment, prioritization, authorization and scheduling of changes. A change advisory board is usually made up of representatives from: all areas within the IT service provider; the business; and third parties such as suppliers.”
For completeness, although I state my own benefits
below, ITIL states that the value of change management includes:
- “Protecting the business, and other services, while making required changes
- Implementing changes that meet the customers’ agreed service requirements while optimizing costs
- Contributing to meet governance, legal, contractual, and regulatory requirements by providing auditable evidence of change management activity. This includes better alignment with IISO/IEC 20000, ISO/IEC 38500 and COBIT where these have been adopted
- Reducing failed changes and therefore service disruption, defects, and re-work
- Reducing the number of unauthorized changes, leading to reduced service disruption and reduced time to resolve change-related incidents
- Delivering change promptly to meet business timescales
- Tracking changes through the service lifecycle and to the assets of its customers
- Contributing to better estimates of the quality, time and cost of change
- Assessing the risks associated with the transition of services (introduction or disposal)
- Improving productivity of staff by minimizing disruptions caused by high levels of unplanned or ‘emergency’ change and hence maximizing service availability
- Reducing the mean time to restore service (MTRS), via quicker and more successful implementations of corrective changes
- Liaising with the business change process to identify opportunities for business improvement.”
What this means is that change management is really all about knowing what needs to change and why, approving and prioritizing the changes, and then ensuring that changes are deployed with risk optimally managed.
Change Management Objectives
ITIL defines the objectives of the change management process as:
- “Responding to the customer’s changing business requirements while maximizing value and reducing incidents, disruption, and re-work.
- Responding to the business and IT requests for change that will align the services with the business needs.
- Ensuring that changes are recorded and evaluated, and that authorized changes are prioritized, planned, tested, implemented, documented and reviewed in a controlled manner.
- Ensuring that all changes to configuration items are recorded in the configuration management system.
- Optimizing overall business risk – it is often correct to minimize business risk, but sometimes it is appropriate to knowingly accept a risk because of the potential benefit.”
So, in practice, this could mean:
- Ensuring that new modules, or new functions within an existing business system, are delivered in a manner that doesn’t disrupt business operations. This could be at the point the new modules, or functions, are released or in the ongoing use of the changed application, i.e. the whole system might no longer work as it should post change.
- A change to resolve a major incident, i.e. an IT issue that is having a significant and adverse impact on business operations. This would normally be termed an emergency change.
- A change to address a business-affecting issue, for example a change in industry legislation might require business processes, or data collection, to change and thus the supporting IT needs to be changed to reflect it. This might need to be undertaken as an expedited change if the planning and lead-time is insufficient.
My simple diagram (OK I admit that it’s not that simple) hopefully provides a snapshot of what can happen with change management.
Change Management Benefits
A formal change management process should address many of the common issues encountered with uncontrolled change, such as:
- Change-related incidents
- Unauthorized changes (and their potential unwanted impact)
- Change scheduling conflicts
- Rush jobs to deploy changes
- The unexpected and unwanted side-effects of deployed changes
- The inability to back out or rollback failed changes
- Rush jobs to deploy fixes
- A lack of cross business input in assessing change impact or change priority
- The absence of appropriate approvals and audit trails
- Lack of change awareness, especially at the IT service desk
Thus the main benefits of formal change management include, but are not limited to, the following areas.
The financial benefits associated with minimizing change-related incidents and problems, such as a reduction in the:
Improved change visibility, control, and sometimes speed of change through the:
- Business costs associated with business-critical service downtime (when caused by changes)
- IT costs of dealing with change-related incidents and problems, from the service desk through to technical domain experts
- IT costs of backing out failed changes or deploying change fixes (including on-the-fly code fixing) – often paid overtime
- Business cost of delays to important or mandated changes
Better collaboration – the business-wide collaboration benefits include:
- Communication of the schedule of changes
- Use of a stage-gate approach to change approval
- Prioritization and fast tracking of changes, for example: the use of change models and having to deal with expedited or emergency changes at speed
Better use of potentially scarce IT resources, including:
- Better cross-functional risk and impact assessment
- Improved change prioritization and scheduling between competing needs
- The idea that defined roles and responsibilities, along with a single, consistent process, not only speed things up but also reduce the need for rework, duplication of effort, and wastage
- The ability to leverage existing knowledge, through effective knowledge management, to speed up change
Plus, of course, the usual goal for, and benefit of, ITSM: Better IT services, and improving customer service and the business’s perceptions of the IT organization as a whole.
Well there you have it, a quick guide and a simple introduction to change management. Hopefully you found it helpful.
If you want to read more from me, and few of my friends, on change management then please look at:
Posted by Oded Moshe
on September 17, 2015 in ITIL
Everyone loves heroes, and not just in comic books. Heroes come in and save the day when things go wrong, and naturally anyone suffering as a result of that ‘going wrong’ is pleased to be saved.
Society employs heroes that are there to save us if a misfortune occurs: firefighters, police, and even the army; and we expect our utility suppliers (water, electricity, gas, telephone, etc.) to have such heroes too, ready to go out in the worst weather to fix any damages. But actually what we, as customers and consumers, would prefer is that things just keep working seamlessly – no water or power failures in the first place – and certainly we don’t ever want to need firefighters rushing to our homes. We like to know that the hero is there, but we don’t want to actually need them and their heroics.
In service management (whether applied to IT or non-IT), the biggest and bravest heroes live inside the problem management
team, notably the reactive problem management team, seeking out root causes and solutions to fix what goes wrong. Just like firefighters, many of these guys enjoy their work the most when faced with challenges and having to fix catastrophic failures or mystery issues that require analysis and skill to solve.
However, if we judge this team only on how well they react to disasters and issues, then we inadvertently set up a mechanism whereby the more things go wrong, the better they look. It’s like judging the fire service on how many major fires they put out. The easiest way for them to look good would be for them to go around starting fires so they can put them out. Now that’s a shuddering thought!
Of course neither the firefighters nor most problem management teams would deliberately cause issues to happen, but without incentivizing them otherwise, they might not focus on trying to prevent disruptions.
For the fire service, prevention rests upon aspects like promoting risk awareness and installing/ maintaining smoke detectors, as well as ensuring human emergency skills and equipment are ready to roll should they be needed.
Reactive and Proactive
has always (well, since 1988) ascertained that problem management has two sides: reactive and proactive. Reactive
deals with what has actually gone wrong; proactive
deals with prevention of impact through means like:
- Fixing things before they have any impact, such as repairing back-ups where duplication is in place
- Ensuring things remain healthy by scheduling preventative maintenance
- Seeking potentially weak or suspect parts of the infrastructure and repairing them before they fail
All this sounds good, but how on earth do you measure it, and justify the money it costs? Within any organization, it’s always hard to justify spending money, particularly when that funding is for making things NOT happen. Whilst it may be the best and preferred situation for everyone, no-one gets fair recognition by pointing out the things that didn’t happen because of their work. For example, the heroes of the Victorian age tend to be the engineers who built the big visible things like bridges and ships, whereas the biggest advancement at that time was perhaps the work done in preventing infectious diseases through the less visible things like water supply and especially the sewers. But we don’t instinctively judge progress by seeing when cholera stopped being widespread.
Corporate management should also want a set of services that don’t break, failures that don’t happen, and business output uninterrupted by errors. But even if management recognizes this, it can be hard to set targets and encourage improvement. And it can be even harder to get funding to expand, or even keep, resources dedicated to this preventative work. The issue lies with the difficulty of quantifying this type of work, but thankfully there are workarounds.
Measuring the Value
So what can be measured that would indicate that the proactive problem management team is delivering what is needed by the business? The most powerful way is to measure the damage being caused and (hopefully) how it’s gradually being reduced month by month through things such as:
- Service availability. How often does someone not do their job because a service isn’t there for them?
- Repeat incidents. Even the most trivial interruptions and failures can get in the way of the business. Working on making sure recurring faults go away reduces the damage.
- Cost of IT. Failures cost money and spending too much money is damaging to the business. Not having failures saves money. It’s that simple.
One of the biggest messages to get across is that spending money on prevention is often money well spent. Most people who rely on their car to get to work spend money to have it serviced regularly and replace components like brake pads before they fail. Funding proactive problem management is just applying that proven logic to the business.
We prefer our car to keep working and don’t want to be in a situation where we admire the mechanic who fixed our car in the rain on the roadside at night. What that preference translates to, in ITSM terminology, is mean time between failures (MTBF)
– where the longer the time, the happier the user is likely to be, and it’s a good focus for the supplier to have.
So, here’s what I propose for service mangers today - let’s focus more on recognizing, rewarding, and funding the preventative aspects of what we do, and acknowledge the true heroes of problem management.
Posted by Nicole Katz
on September 8, 2015 in ITIL
For as long as ITIL has been around (26 years) and longer, it’s told us that Service Management needs a triple focus. People, Process, and Technology all must be addressed if services are to be delivered and supported as well as they should be.
It sounds simple enough, yet it can be hard for people in IT to see past the technology sometimes. After all, most guys joined the IT profession to play with technology toys.So they get understandably disappointed when told to look at other aspects.
The Three-Legged Stool
It doesn’t work having a great process without people who can deliver it, and it’s not good having the best of all possible software tools if you don’t have good processes to support it. It’s like a stool with two perfect legs – it can’t do the job it’s supposed to do. In the picture you can see the three legs do their jobs separately. Of course they have to be built to a common specification, at least be the same length, otherwise you will get a lopsided stool and fall off. For service management, considerably more integration is needed: each of the proverbial legs (process, people, and technology) needs to be built with the others in mind to deliver the best solution for a particular environment.
Integrated Build, Maintenance, and Improvement
For example, designing processes needs to take into account the people who will be required to operate these processes. If you build a theoretically perfect process that requires a skill, physical ability, or degree of experience that your staff doesn’t have, then it will be as relevant and helpful as a two-legged stool. So, knowing staff availability and skill needs to affect the process design. Similarly, knowledge of the processes (which staff will be required to follow) should be a relevant influence on recruitment and training of these staff members.
This isn’t just related to IT service management (ITSM) of course. Look at professional sports, for example, which is littered with cases of managers who develop excellent processes (tactics, formation, style of play, etc.) that should sweep them to victory, but they don’t, because the processes fail to factor in the skills and abilities of the specific players on the team. And just as many times, teams will fail when skilled players do not perform because the style of play imposed on them doesn’t match their skills. The best teams are where the approach and the skills are in harmony, and that only comes from a holistic view, building with what will be available and not in isolation.
The same idea can be applied to technology. Tools need to support the processes required, that’s how it’s taught in the ITIL®
Foundation courses. But in real life, the availability of a tool and its capabilities will affect which processes are possible. An organization’s choice of ITSM tool is often heavily influenced by whether the staff who will use it will ‘like it’ or ‘feel comfortable’ with it. This is the sensible approach; not pandering to staff’s whims but integrating the threefold approach to ITSM, making sure the technology and the people and the process are built – and can then continue to develop – together.
Building the Legs to Work Together
The pragmatic lessons of this are really quite simple. Work on process, people, and technology as a combined and interconnected ongoing effort. Allow each to influence the other. Technology will open up new process possibilities, improved processes will reveal technology requirements, and it will possibly also change skills requirements in people. New skills coming into the workforce, as with the Millennial’s familiarity and comfort with smart technology and social media, will influence what are the most relevant tools, and the processes for using them.
Encourage – and be encouraged by – the broad perspective.
Perhaps it is worth looking at your attitude to the three elements we’re discussing (people, process, and technology), and checking on how you can integrate them better. Maybe ask some questions like:
- Do your suppliers see their product(s) as essential parts of an integrated whole, or as a magic bullet that can work in isolation?
- When designing and documenting processes, do you consider and also document skills and experience that will be necessary to perform them?
- Do your process designers know the capabilities of your technology, and treat them as design constraints?
This is a good place to start. I’ll follow up, in another blog, with some direct tips to help you further.
Posted by Stuart Rance
on September 2, 2015 in Service Desk
I really enjoyed delivering a webinar with Stephen Mann
recently. The webinar, which was called Real-World Tips for Self-Service Success
, attracted a large audience, and generated some great feedback. If you missed the live event then you can still listen to the recording by following the link, and if you want a brief synopsis of what we spoke about, read this blog
. If you would prefer to read more about the topic (with or without watching the webinar) then start playing the webinar and click on the Attachments
button to access our white paper.
Quite a few attendees typed in questions, and although we didn’t have time to answer all of them during the live event, we have given them some thought. So here are my answers to some of the questions.
If your company doesn't have ITIL in place, do we need to approach self-service in a different manor?
Not at all. Nobody has “ITIL in place”. ITIL is just a set of best practices that you can adopt as part of your management system. You must have some kind of processes in place for managing incidents and requests, and I assume you have a service desk or something very similar. All of the ideas and suggestions we made about self-service were general ideas about IT service management, none of them was specific to ITIL.
Any ideas on how knowledge articles can be written or related so nuggets of wisdom can be interwoven into a self-service process - available at relevant points from the customer's perspective?
This is a very challenging question, and you are right that it is needed. The first thing to do is to identify what information you need to make available. You can do this by reviewing service desk calls to see what questions come up frequently, and also by talking to your users to find out what they would find useful. You should then stop thinking about “writing” and start thinking about what is the best medium for the knowledge you want to share. A short video or graphic can often be far more effective than a piece of writing.
Do you agree that self-service demands careful design of a supporting 'knowledge-base' of helpfiul information to coerce, guide, and support whatever process is being self-served?
We do talk quite a bit about the need for a good knowledge base during the webinar, so yes, I absolutely agree. I think this question must have been asked before we got to that part!
We know that many users will not or do not call support when they have an interruption or a question - they go to online search like Google or Bing. Is properly constructed self-service better than that, which may give generic or irrelevant answers?
It’s not only your users that do this. I do it, and I suspect that you use an internet search engine to try and solve problems too! There’s not necessarily anything wrong with this. In fact, the best way to get users to use your self-service portal rather than a generic search engine is to offer a better service! You could actually include a generic internet search within your portal to help you collect data about the help your users are looking for and use this to help you fine tune the relevance of the resources you provide for them. You could even incorporate the results of a generic search alongside the results of searching your own knowledge base, so that users can get both with a single search.
What about incorporating or embedding capabilities such as Google search into your organization's portal to help make your self-service look like something folks might be familiar with outside of IT?
This is a great idea. See my response to the previous question.
What measures/metrics are important to help you gauge how your self-service is working?
What’s important is that you measure things that matter to you. Don’t just use a generic metric, but think about why you’re investing in self-service, and measure to see that you achieved what you wanted. Some things that you might want to measure include:
- User satisfaction ratings when they have used self-service
- Percentage of incidents and service requests that are received via self-service
- Percentage of self-service incidents and requests that are resolved without needing manual intervention from the service desk or technical support
- Average time to resolution of self-service incidents compared to the same category of incidents handled by the service desk
How do you motivate users for enrolment in self-services such as password services?
This is one of the hardest aspects of self-service. You need to look at the whole spectrum of organizational change management and decide how this can work in your context. Start by identifying a sponsor in the organization who cares about success of the self-service project and who will support what you are doing. Continue by identifying “what’s in it for me” for the people you want to engage. Then work out a plan for communicating with them. Make sure they know how much easier things will be for them when they use self-service instead of phoning the service desk. AND MAKE SURE IT REALLY IS MUCH EASIER. Then communicate, communicate, and communicate. Share examples of how people have saved time and effort by using self-service, share how the company has saved money, shared how the business has become more efficient due to less wasted time, etc.
"Getting the right people involved..." I'm bound to say that I hope you mean start 'outside-in' and look at what is needed from the perspective of those being offered self-service as an option. Worth walking in their shoes for a mile... (Loaded question) What methods do you recommend for understanding the customer experience?
Of course, we should always take an outside-in customer-focused view when we design any aspect of IT services. I am a big supporter of the Lean concept “go to the Gemba”, which says that the way you find out what the users experience is by going to where the users are and seeing what they see.
I hope you have found some of these answers useful. Please feel free to share your own answers via the comments area below this blog or find me on Twitter at @StuartRance
Posted by Greg Sanker
on August 26, 2015 in Service Desk
Everyone knows that incident management
is designed to manage the overall life of an incident. Start to finish. Cradle to grave.
But what does that really mean?
The standard, accepted practice is that (most) incidents are started at the service desk – aka "Level 1 support". In fact, the service desk is generally synonymous with incident management ownership. The role of service desk employees includes ensuring timely and effective resolution.
Issues that cannot be fixed at level 1 are escalated to specialty teams, also known as Level 2 (or 3) “resolver” groups. Resolver groups have deep technical experience in a specific technology area (network, servers, application, etc.)
We’ve all heard horror stories of incident tickets that spend days, weeks, or months getting kicked from queue to queue. It’s a concept I call “bus therapy”. Basically, when a resolver group either can’t resolve a ticket, or doesn’t know what to do with it (and before the SLA expires!), they assign it to some other random queue, making it someone else’s problem.
The reason I call it bus therapy is because it’s like buying a one-way ticket to some other town, wishing it well, and sending it down the road, hopefully never to be seen again.
This happens when there’s not clear ownership for incidents. And when that happens, guess who suffers. You got it – the customer.
Who’s On First?
Incidents that are created, worked on, and resolved by the service desk are pretty straightforward. Ownership is clear, tracking resolution time is pretty simple, and, in the end (hopefully), a happy customer.
No problem here.
But incidents worked on by the service desk that requires deeper support for resolution – now that’s a different story. When that happens, the ticket is reassigned to the appropriate resolver group (network, servers, etc.).
But what if the resolver group determines it’s not their issue? Do they route the ticket on to another resolver group? Do they route it back to the service desk for rerouting?
What if the issue requires multiple resolver groups’ efforts? Who manages the ticket, or are there now multiple tickets?
Every hand off potentially adds delay as the ticket is queued awaiting the new resolver group to respond and begin working the ticket. The more hand offs, the more potential for delay.
It’s not that anyone is trying to give bad service to any particular incident. Everyone is busy, and tickets have a way of getting forgotten or lost in queues. Unassigned tickets can be particularly troublesome.
This is the shocking, secret life of escalated incidents:
- Potential for unclear or multiple owners
- Convoluted paths between resolver groups
- Unclear, or circular, paths to resolution
It really comes down to one fundamental principle: who owns an incident at any given time?
There’s really only two options:
- The person currently working it, or
- The incident owner, regardless of who’s working it
Two Roads Diverged
In the first option, incident ownership transfers with the ticket as it gets assigned to different people. This is the simplest, and perhaps most common, approach. The service desk analyst owns the incident while working it. If it gets transferred to a colleague for any reason, the ticket owner is simply changed, and off you go.
Where this model struggles a bit is when transferring ownership to a resolver queue, rather than a person, and the ticket sits unassigned for a period of time. At that point in time, it has no identified owner. The service desk analyst no longer owns it, and it’s sitting in a queue waiting for someone to notice and take ownership for it.
If there are multiple handoffs, each new group’s response time is added to the overall resolution time.
In the second option, ownership of the incident remains constant. It never transfers. The owner is generally the service desk analyst whom, as you recall, has ownership for all incidents.
With this approach, when issues go to resolver groups, a child ticket (sub-ticket, task, etc.) is created, related to the original (parent) ticket, and the child ticket is routed to the resolver group. If multiple resolver groups are required, additional child tickets are created and related to the single parent ticket.
The service desk maintains ownership of the parent ticket, and keeps watch over the child ticket(s). This gives the service desk the ability to monitor the overall coordinated response to an incident. The service desk calls attention to child tickets that don’t appear to be making progress, and takes action to ensure timely resolution.
The service desk is then positioned to facilitate the overall response to complex and escalating incidents. The service desk uses child tickets to effectively manage the incident, and rally additional resources as needed.
Which Is Better?
Neither, really. Or both, perhaps. I don’t want to go the “it depends” route, but, well, it kind of does depend.
In smaller organizations, transferring ownership can be clean and effective. In tight-knit groups, tickets are much less likely to get lost or bumped multiple times without being noticed.
But in a larger shop, especially where there are multiple, geographically dispersed resolver groups, and follow-the-sun
support, it’s easier for tickets to get lost in the shuffle.
It’s worth noting that the service desk is designed to be a customer-service contact center. Its primary purpose is to ensure all incidents are resolved within service level targets. Having a handle on all incidents facilitates high levels of service. It also puts them in a powerful position to correlate, detect, and trigger major incident response.
What to Do?
The bottom line is, either approach can be made to work perfectly well, depending on the circumstances. Personally, I prefer a service desk with clear ownership and end-to-end accountability for incident management. To me, this is the fulfillment of “managing the lifecycle” objective of incident management.
But that’s a decision that each organization must make for itself based on its unique circumstances and challenges.
As with all processes and tools efforts, the focus should be on the process first. Don’t rely on the tool to define the process. You have to understand what works best for your organization, and why, before you begin configuring your ITSM tool
All modern ITSM tools can be configured to effectively manage either of these approaches.
What approach have you seen to be most successful?
If you are struggling with service level performance and incident resolution times, and if you have too many tickets receiving bus therapy, you may want to revisit your incident model. Service desks that started small and grew with the business may never have made an intentional decision on incident ownership, and it’s worth revisiting.
Posted by Sophie Danby
on August 19, 2015 in Service Desk
Sadly, many IT departments don’t see the importance of delivering great customer service to their end users. After all, it’s not as though the end users can leave them for another support provider, right?
Technically this is true, but it’s also wrong… Have you heard of a new-fangled thing called Google
? At a recent IT service management (ITSM) conference
in London, a great point was made: “No ITSM tool vendor is the leader in providing technology to help solve IT issues. That award goes to Google.”
And according to Forrester Research
, only 17% of IT issues actually make it to the corporate IT service desk. So where does the other 83% go?
End Users Have Consumer-Driven Expectations of Support and Can Self-Help
End users are becoming increasingly more tech-savvy and their expectations of IT are increasing daily (to match the service experiences they receive in their personal lives). So why would they want to deal with a potentially unhelpful service desk analyst who doesn’t respond to their ticket for three days, when they can simply type their issue into a search engine (although we don’t actually recommend this
) to find a workaround or fix for their issue themselves in mere minutes?
In my opinion, given the continued rise of Shadow IT, personal cloud services, and BYOD, corporate IT departments cannot afford to ignore their end users nor to deliver a bad service experience. So make the most of the opportunity you have right now to improve your service experience before that 17% drops so low that the need for an internal service desk is questioned.
Here are five simple tips to get you thinking about (and hopefully started on) the road to providing a better service experience:
Whether you’re providing internal or external support, the best customer service and service experience comes from those people who spend more time listening than talking. Allow your end users to fully explain why they need help and what makes it so important for their issue to be fixed quickly. After all, just because their IT issue doesn’t seem important to you, it doesn’t mean that it isn’t disruptive and important to them, their working, and possibly a business-critical activity or service. So don’t blindly dive into the resolution script in front of you or prioritize the issue as low for level 2 support – actually listen to what the caller has to say and then act accordingly.
2. Don’t make excuses
The end user doesn’t care whether it’s your fault, his/her fault, your colleague’s fault, or your best friend’s cat’s fault. They just want you to address their issue. So take ownership of the issue, understand why they are frustrated, and don’t be defensive and/or make excuses. As Nike would say “Just do it” in terms of getting things fixed (of course bearing in mind my first tip).
3. Manage expectations
Okay, so it’s not ideal for the caller that you cannot immediately solve their issue, but do you know what is less ideal? Them having to guess when their issue will be fixed. Yes, they might be unhappy with you if you say that it’s going to take three days, but how unhappy are they going to be if you don’t set a resolution timeframe and three days later they have to call you for an update? Always let them know when their issue will be addressed and any reasons for delay – it might be an agreed service level target that says it can take up to three days based on workloads. In my opinion, not managing end user expectations effectively will simply lead to them becoming even more frustrated (and potentially contacting you every few hours for updates – which isn’t a great use of your time, or theirs).
In line with effectively managing expectations, always keep your end users updated on the status of their incidents. Don’t leave them in the dark; they’re probably not mind readers. Let them know if there is going to be a delay and let them know what you’ve achieved as you go along, ideally via self-service, so that they don’t assume you’re just sitting there doing nothing to help them.
5. Use customer satisfaction surveys
First and foremost, don’t ask for feedback if you’re not going to bother acting on it. If you’re wondering why very few people actually complete your post-service survey, this is probably the reason. No one is going to waste their time giving answers to your questions if they know they’re not going to see any action taken on what they have to say. Make your survey short, and use appropriate questions (I advise checking out the net promoter score and system
), and then ensure that you follow up on the answers. Show end users that you’re listening by communicating how you are going to address the highlighted issues, and provide evidence of improvements once completed.
So there you have it, my five quick tips on how to improve your service desk’s customer service and service experience. What do you agree with? What would you change? And what would you add? I’d love to know.
If you’re looking for further advice, then I also recommend looking at the following:
Posted by Gil Blinov
on August 12, 2015 in Service Desk
Sets of best practices for service management – like ITIL for example – are full of good ideas and good advice, and all that good information is valuable, but sometimes you are able to generate added value by combining two elements of advice from different parts of the guidance.
If you look in ITIL®
2011’s Service Operations book (Chapter 6.3.5), you’ll see a list of relevant metrics about service desk performance. Now go to ITIL’s Continual Service Improvement (CSI) book (Chapter 5.5.2) and you’ll find some words about tension metrics, which are different metrics that effectively compete with each other. Each book has some pretty good stuff on their own, but put them together and you really start getting somewhere!
Metrics, of course, are just things you can measure to give you an idea of how well something is performing. We use metrics every day – for example we might measure a car by how fast it goes or how much fuel it uses to cover 100km. This is, in fact, tension metrics. The faster your car, the more fuel it is likely to use. You might choose to drive slowly to save fuel, or quickly to save time. You won’t be able to do both because the two compete with each other – there is ‘tension’ between them.
Metrics for a Service Desk
If you focus only on one metric, it is usually simple enough to meet, because you are basically disregarding all other factors. So that may not be the perfect scenario.
Let’s take a look at two traditional metrics that are used to measure service desk performance:
- First-time fix rate. Easy to meet - just keep callers hanging on for as long as it takes.
- Short call duration. Just as easy - take their number, hang up, call back, and disturb them each and every time you need more information.
If you judge a service desk simply on one of the above metrics, you’re going to get behavior guaranteed to upset rather than delight customers. What the customers want is a balance of first-time fixing in a sensible amount of time. Just like you don’t want the world’s fastest car (way too expensive) nor the most fuel efficient (far too small and slow) for everyday motoring. You want something fast enough and cheap enough to run – along with other factors too, of course, like enough seats and luggage space.
So with the service desk, both first-time fix rate
and short call duration
are important, and both need to be measured (as do even more metrics besides those). This, however, then sets up a challenge that requires thought and consideration by service desk staff and managers. Do you keep the caller hanging on while you try a quick solution? Do you give up on the first-time fix rather than extend the call too long? It makes the service desk work harder on decision making, but also delivers a much better and balanced service overall.
This is just an overly simple illustration of course. In real life you would want to choose more than just two metrics that fight and challenge each other – making the decisions even more complex but hopefully also making the service better matched to the client’s concerns, wishes, character, and culture. There isn’t a single right answer, but here is my list of optimal service desk metrics – as an opening or food for thought:
- First time resolution rate
- Average call duration
- Percentage and number of abandoned calls
- Percentage and number of calls miss-assigned (e.g. to wrong support team)
- User and customer satisfaction survey results (that’s two different surveys)
- Staff turnover
- Total cost of operation: staff, equipment, resources, etc.
It’s not easy to measure everything on this list, and likely you don’t need to measure it all, but surely you would benefit from measuring across the implicit tension that exists between many of these measurements.
Some of these suggested metrics might surprise you – staff turnover for example. Each new worker on the desk can take days or even weeks to reach a reasonable operating performance level, while you are paying them; so keeping the turnover down, keeps costs down. Of course, it also means more experienced staff, and that experience should deliver faster and better service.
Using Metrics to Measure Value
No one set of metrics is right for every situation – sometimes speed matters more, sometimes economy, sometimes safety. That applies to cars or service desks. What matters is measuring the value that the customers get from the service. To do that for your particular situation, the first step is to establish what those customers would see as value. Start with possible metrics and discuss with the customers to work out the best bundle of measurements for your situation.
What is universal though is the need to try and make sure you have that tension element in your chosen set of metrics, so that the compromise between speed and cost – or whatever matters to your situation – is rewarded rather than just one target that can be easily reached at the expense of overall service quality.
We all use the tension metric concept in everyday life (as with the car). You probably also do so at work, perhaps without even realizing it. Can you think of any examples? Please share.