SysAid Blog

Blog Home
Welcome to the SysAid Blog - the place to go to find out where the IT industry is going, and what is SysAid’s role in it.

The 7 Deadly Sins of Change Management

Posted by on April 25, 2017 in ITSM
7 Deadly Sins of Change Management Many businesses, and IT organizations, become frustrated with a lack of agility and responsiveness with their change management process. Rather than being viewed as a “value enabler,” the change management process is often seen as overly bureaucratic and a hindrance to getting things done. But in my experience, these issues usually boil down to a poor implementation and misunderstanding of the purpose of change management.

What Is the Purpose of Change Management?

The change management process has three primary purposes:
  • To ensure the appropriate planning, review, coordination, and communication of a change. While not all changes are created equal, all changes must have the appropriate degree of planning, evaluation, approval, orchestration, and communication. Without these elements, there can be no control over the managed environment, which ultimately means that the business cannot rely on IT.
  • To protect what’s already in production. A change must have no negative impact to services that are already in the managed environment.
  • To ensure that a change delivers the intended result. The whole reason why a change is being made is to deliver a planned result. If a change is implemented, but it does not deliver the intended result, this points to larger issues that must be addressed.
Seems rather straight-forward and common sense, doesn’t it?  So why do so many change management implementations result in frustration, subterfuge, and headache?   Perhaps you’ll recognize some reasons in my list below.

The Seven Deadly Change Management Sins

  1. Every request for change has to go before a change advisory board (CAB). Out of all the sins, this is the one that I see most frequently. Because change models and evaluation criteria are not defined, *every* request for change – regardless of complexity, resource needs, or impact – gets dumped onto the CAB.
  2. No true management support. This is my second-most encountered issue with change management implementations. I believe that management – especially senior management – must exhibit strong, visible support to ensure an effective change management process. But what I often find when it comes to enforcing policies and supporting the process, is that senior managers do not want to (visibly) enforce the very policies and process that they commissioned!
  3. Request for Change (RFC) not raised…until just before implementation. This behavior essentially guts the change management process by bypassing the crucial initial review, evaluation, planning, and communication of upcoming work. This action in turn, has a cascade effect on work that has already been planned, resulting in resource conflicts.
  4. No one, other than the change manager, has any accountability for the success of the process. I frequently encounter the misconception that once an RFC is logged, then it’s the responsibility of the change manager to coordinate all of the activities related to the change. The fact is that the change manager is accountable for the operation of the process – and ensuring that the handling of each RFC follows the process – not the design, build, testing, and implementation of a change itself.
  5. The change schedule is not published outside of IT – sometimes, it’s not even published *within* IT. The change schedule is intended to promote communication and transparency, not only regarding the change management process, but also regarding the demand and workload within IT.
  6. CABs do not have the proper membership. CABs are often just made up of IT personnel, with no participation from business colleagues.
  7. Process over engineering. When discussing change management, I often use the analogy of the control tower at an airport. The control tower ensures that at any given time there is one and only one airplane on any given runway at the airport. The control tower does not pilot the plane, does not manage the loading and unloading of passengers and cargo, nor the servicing of the aircraft, and so on. Those activities belong within other roles and procedures. The control tower’s job is to ensure safe landings and take-offs. A good change management process is like the airport control tower – but unfortunately, many change process definitions include all of the other “airport operations” that really shouldn’t be there.
Any of the above sound familiar? It’s no wonder that our business partners are frustrated. It’s no wonder that IT is frustrated.

Seven Things You Can Do to Fix It

If your change management process is suffering, here are seven things you can do to fix it:
  1. Define change models. A change model is simply a pre-defined way of implementing a change. Executing the steps within a change model is often the fastest way to implement a change.
  2. Define and enforce the responsibilities of the change owner. The change owner is accountable for the success of a change, not the change manager. It is the change owner who is responsible for capturing the requirements for a change, ensuring the design and build of a change, defining and executing appropriate testing, and ensuring a smooth implementation of a change.
  3. Define evaluation criteria. Not all RFCs should go before a CAB for review and authorization. In fact, in a well-defined change management process, most RFCs should be authorized by someone other than a CAB. Defining evaluation criteria helps ensure the “right” RFCs go before the “right” people as defined in… (see my #4).
  4. Define a change authority matrix. Defining and following a change authority matrix identifies who the “right” people are to review and authorize RFCs. Have your senior management review, approve, and sign-off on it – this helps enforce accountability – and get management commitment.
  5. Publish the change schedule – to everyone. Not only will this improve change management awareness and communications within IT, it is a great way to illustrate how much work is getting done by IT.
  6. Produce and publish metrics that make sense to the business. While publishing the number of changes implemented within a timeframe is nice to know, measuring and publishing the business improvements resulting from the implementation of a change is much more meaningful. For example, if a change is intended to reduce order processing time – measure that!
  7. Remove any non-value added work and wait time from the process. For example, why arbitrarily conduct CAB meetings on a weekly basis? Take a page out of Agile and use the daily stand-up meeting like a “CAB meeting.”
Is your change management process not producing the results your organization needs?  Even worse, is your change management process in the way of making changes? Don’t give up – these seven fixes are sure to move your change management process from being the “barrier” to being the “value enabler”! If you’d like more tips, I highly recommend Stuart Rance’s blog listing his top tips for supercharging your requests for change. And for the beginners out there, Joe The IT Guy does a great job explaining the basics in his blog ITSM Basics: A Simple Introduction to Change Management.
Continue reading

4 Reasons Why ITSM is a Key Investment for SMBs

Posted by on April 18, 2017 in ITSM
ITSM investment IT service management (ITSM) is not just a “big company” opportunity – as both the need and the benefits are not solely dependent on the relative size of an organization’s IT estate, employee numbers, and/or budgetary power. Small and medium-sized businesses (SMBs) should also look to ITSM as a route to better quality IT services and support, increased efficiency and effectiveness, reduced costs, and a better employee/customer experience. Plus, ultimately for better business outcomes, enabled through the delivery of better IT. And while the economies of scale might mean that there’s greater potential for financial savings in larger organizations, the limited resources (money and people) of SMBs means that ITSM might actually have a more significant impact. As ITSM empowers SMBs to “do (and deliver) more with less.”

Arguments as to Why SMBs Don’t Need ITSM

This has already been touched on in my opening section, but it’s worth taking a closer look – for example, that SMBs potentially think:
  • “We don’t spend enough on IT to make ITSM worthwhile”
  • “We don’t have enough people to do ITSM”
  • “ITSM will cost more than it saves”
  • “We don’t need the 26 processes and four functions of ITIL”
I could go on, as it’s easy to offer many reasons – or excuses – as to why SMBs don’t need ITSM. But many of these reasons are shortsighted, overlooking the fact that ITSM investments can be as big or as small as you need them to be. And, as with any reasoned investment, the returns will outweigh the costs when scoped, planned, and executed correctly.

Four Reasons Why SMBs Need ITSM

1. Modern Companies Are Totally Reliant on IT

Most, if not all, companies now need IT just to operate, let alone for competitive advantage. But many do need IT to differentiate themselves and to win and retain business, with IT a valuable part of the overall business jigsaw puzzle. And this is regardless of size – from large enterprises to SMBs. The IT organization/capability, whether a cast of thousands or just one person and their cat, plays an important role in keeping the business operating – from employee productivity to customer-facing IT systems. Investing in ITSM best practice helps to ensure that IT services are designed, delivered, managed, and changed in an optimal way – providing the best quality of IT service at an acceptable, maybe even optimal, price.

2. IT Support Needs to Always Bring its A-Game

Without ITSM best practice, SMB IT capabilities are at risk of “blowing in the wind” (usually where the loudest voice gets attention first), or failing to prioritize workloads correctly, i.e. the easiest things get done first to keep work volumes low. In either scenario, IT and particularly IT support isn’t bringing its A-game – no matter how talented the involved people are. ITSM best practice helps SMBs to best structure their ways of working such that the most important needs/issues are dealt with first through to the least important service requests. Plus, if applicable, the use of a fit-for-purpose ITSM tool not only supports this through priority matrices, workflow and automation, and knowledge management – the introduction of a self-service capability can allow end users to help themselves with the simpler issues and information requests. Thus, freeing IT staff up to focus on more complex, and potentially more important, things.

3. Change Can Do More Harm than it Helps

ITSM isn’t just about the service desk. Although some of the other ITSM best practices do link in with, or affect, IT support – a good example being change management. Why? Because failed or poorly executed changes can place an additional burden on IT support staff through high levels of change-related incidents. And working in IT support is hard enough without colleagues creating even more IT issues to deal with! So, look to change management best practice to understand:
  • How best to balance change risk and speed.
  • How to involve relevant business parties in change decisions when the risk and impact of change failure is high.
  • How best to prioritize and schedule changes for optimal business effect.
  • And how to employ change models to facilitate the swift delivery of low risk and low impact changes.

4. People Are Under Pressure and Potentially Underperforming

Without ITSM best practice or, more specifically, a fit-for-purpose ITSM tool enabling ITSM best practice, it can be hard to ascertain individual and team performance. For instance, people might seem busy as they run around fixing things – but are they really making best use of their time and performing well? It can be hard to gauge performance when issues and requests are “managed” in email inboxes, spreadsheets, and people’s heads. There’s no way of knowing how long things took to resolve, whether IT support productivity is high enough, or – probably even more importantly – whether resolutions were delivered in line with service level targets and end-user expectations. ITSM best practice and tooling can help considerably here, allowing management as well as IT staff to understand where improvements can be made (at both an individual and team level) and to help ensure that limited IT resources is used optimally across the SMB’s spectrum of IT service delivery and support needs. So, that’s my four reasons as to why SMBs should invest in ITSM. Would you agree? What would you add?
Continue reading

A Beginners Guide to Serverless Computing

Posted by on April 12, 2017 in Cloud
Serverless Computing The “serverless” computing paradigm emerged a couple of years ago in Amazon Web Services (AWS) as a new cloud service called Lambda – a serverless computing platform. And now, even though it’s mainstream, it nonetheless can still be new or unknown to many in the IT industry. This blog explains and visualizes serverless for IT professionals who are new to the topic, covering:
  1. The misleading serverless name
  2. Serverless on a napkin
  3. Comparing serverless to other computing paradigms
  4. The serverless ecosystem
  5. The serverless sweet spot
So please read on to learn more about serverless.

1. The Misleading “Serverless” Name

Why is the name “serverless” misleading? It’s because code still needs to run on a server somewhere. But in the case of serverless, it’s not your server. With serverless, the cloud service provider (CSP) is doing all the low-level infrastructure work for you. You don’t see the servers (even though they’re out there somewhere). So, therefore, from your perspective, there are no servers to manage, hence – it’s serverless. There has been much rhetoric about the name. Some people have wanted to change it to functions-as-a-service (FaaS), which is very accurate but it didn’t stick. Maybe we are now all aaS-ed out? So “serverless” it is then. And there’s even a series of global serverless conferences now.

2. Serverless on a Napkin

There are five simple steps to understanding how serverless works, under the covers, but first, the headline – serverless is an event-driven compute paradigm. It works as follows:
  1. You write and upload your code.
  2. You define the triggers.
  3. An event triggers your code.
  4. Your code does one thing.
  5. The end.
You can log in to AWS directly and do this manually but, in reality, this will be part of an automated DevOps pipeline, integrated into other systems such as AWS S3 storage, Dynamo databases, and SQS queues. If you’re an artist, and have a big enough napkin, you could try to draw this example application of serverless on AWS while you sip on your gin and tonic. Example application of serverless on AWS

Image source: AWS

To go beyond the napkin, head over to the Serverless Framework to dig deeper into the topic thanks to the site’s excellent content.

3. Comparing Serverless to other Computing Paradigms

Over time, moving from left-to-right in the image below, organizations are increasing their use of:
  • Cloud services to cede control to CSPs
  • Smaller batch sizes to reduce change scope and increase change frequency, and
  • Small services at lower cost at all scales.

Spectrum of compute paradigms

Image source: ViewYonder

4. The Serverless Ecosystem

So where do you buy these serverless “things”? As serverless lives at the bleeding-edge of the technology wave, it’s still a mixed, and changing, bag. The table below lists some popular serverless offerings:
Offering Cloud? On-Premise? Launch Date Languages
AWS Lambda Yes No 2014 Node.js, Python, Java
Azure Functions Yes Yes 2016 C#, Node.js, Python, F#, PHP, Java
Google Cloud Functions Yes No 2016 JavaScript
IBM OpenWhisk Yes Yes 2014 Node.js, Swift

5. The Serverless Sweet Spot

Everything isn’t going to go serverless, and rightly so, because there are some use cases for which it doesn’t make sense. The diagram below shows the current sweet spot for serverless:

Serverless sweet spotImage source: ViewYonder

  Latency is the time measured from the trigger of your code until it completes. This can vary depending on how CSPs load and run your code. Unchanging, infrequently accessed code can be “unloaded,” or “spun down,” but this means more latency when this code is run because it has to be reloaded and “spun up.” A good rule of the thumb to use when considering serverless is that: the more sensitive and more-frequently accessed your code is, then (at high levels) it might be better to run it on dedicated hardware somewhere, with you managing the server. In terms of the serverless sweet spot, here are some examples of application types: So, there you have a quick guide to serverless. If you already know about serverless, what would you say are the most important things to know (and understand) about it that I haven’t already called out?
Continue reading

5 Tips to Help Prioritize Your CSI Improvements

Posted by on April 4, 2017 in ITSM
Prioritize Your CSI Improvements I have often said that, in our rapidly changing business and technical environment, continual service improvement (CSI) is the most important service management process. If you don’t keep improving what you do, then you don’t just stay still, you gradually fall behind. This happens because:
  • Your competitors keep improving, which causes customer expectations to keep rising even if you don’t improve.
  • Your customers’ needs evolve, hence delivering what they used to need no longer delivers the value they’re looking for; to keep up you have to deliver what they need now.
There are many well-publicized examples of organizations that failed to adapt to a changing environment and so went out of business.  Here are some ideas of how your IT staff can contribute to help ensure your company doesn’t join them.

Identify Your Improvement Opportunities

Before you can prioritize improvements, you need to identify what improvements you could make. It’s surprisingly easy. Create a CSI register for logging and tracking improvement suggestions, and then:
  • Ask IT staff what improvements are needed. The people who do the work always know what’s problematic, and what needs to be improved. When I work with IT organizations, I always ask people what needs to be improved and they invariably give me a long and accurate list.
  • Ask customers what improvements are needed. Do you really know how your customers experience your services? Do you know what they love and what they’d love you to do better? This is even more important than asking the people who do the work. Every organization should ask their customers what they like about the services they receive, what they want more of, and what they dislike; and they should do this regularly. Ideally you should have business relationship managers to do this, but even if you don’t, someone needs to talk to your customers to find out what they would like to see improved.
  • Review your metrics to identify trends that could cause future issues. If you are measuring and reporting on targets, either internal targets or customer-facing ones, then you can use trends to identify where you need to intervene to ensure that the targets are met. This is much better than waiting until a target is breached before trying to fix the issue.
Make sure that you log and track all the improvement suggestions you identify.

Prioritizing Improvements

When you first create a CSI register, you will almost certainly find you have identified a very large number of things that need to be improved. It’s easy to feel overwhelmed, and to be uncertain about where to start. Here are some suggestions to help you prioritize your improvement opportunities and feel confident that you are starting with the right things.

1. Limit Work in Progress (WIP)

The first thing to think about is how much capacity you have for making improvements. There’s no point in starting work on 20 different improvements, and then running out of time, money, or other resources so that nothing gets finished. Assess how much improvement work is realistic, given your circumstances, and help yourself succeed by making sure you don’t start too much. If your team uses a Kanban board, showing all the work you have outstanding and how much work you currently have in progress, then it’s easy to add the improvement opportunities to your board and use this to help you manage WIP. In any case, decide how much improvement work you can do, and don’t take on more than you can finish. You can read more about Kanban boards in my blog Using Kanban boards to support IT operations.

2. Improve in Short Sprints

If you need an improvement that will take a long time to complete, think about how you could break it down into smaller steps, while making sure that each increment delivers real value. I have seen IT organizations start improvement projects that are intended to replace many tools and processes, but won’t deliver any value for the first 12 months. This is never appropriate. If you make use of some Agile ideas to help you plan, you can always find ways to create value in short sprints. Aim to complete each sprint in less than four weeks, so that everyone can see real improvements and you can keep the continual improvement momentum going. You can read more thoughts on this topic in my blog Major ITSM Improvements Should Start with Small Steps.

3. Focus on Value for End Customers

Once you have identified several possible sprints, and you know your capacity for delivering them, you need to pick a small number to start on. I suggest that you evaluate each possible improvement in terms of how much value it will create for end customers. Since everything you do is ultimately funded by end customers of the business you work for, this will give you the clearest possible indication of which improvements to work on first. Creating better value for the end customers who keep you in business is always going to be important.

4. Look for Zero-Cost Improvements

I have sometimes worked with organizations that tell me they can’t do continual improvement because there is no money, or time, for making improvements. For these organizations, I always recommend that they focus on zero-cost improvements. There are always improvements you can make that have no significant cost, and use very little time. By starting with these zero-cost improvements you can begin to establish a culture of continual improvement, particularly if your zero-cost improvements free up some resources that could be used to start on other improvements (see next tip).

5. Free Up Resources for Future Improvements

Some improvements can result in a long term reduction in the number of people or other resources you need, which can in turn enable you to carry out further improvements. For example, if you start doing problem management, you may identify a few frequently recurring incidents and permanently fix them. This could free up service desk personnel who can be assigned to do some more problem management work. Eventually a ‘virtuous cycle’ like this can result in enormous improvement in customer experience for a very small investment.


If you’ve been putting off continual improvement because you don’t have enough resources, then maybe you should think again. You can start improving with very little effort and the impact can be enormous. The best time to start is right now! Follow the 5 tips in this blog to ensure you are focusing on the improvements that will create the most value, in the shortest time, for the lowest cost.
Continue reading

How Hot Is Your F11 Key?

Posted by on March 30, 2017 in SysAid
SysAid F11 Hotkey Hey there, long time no blog post! I’ve been working in SysAid for more than two years now, and lately it has come to my attention that many of our customers don’t know about the SysAid Agent F11 hotkey feature. This is one of our blowout, unique features which is also incredibly easy to implement and use so I felt the need to rectify this situation. Time for a quick refresh!

Simplify IT for the End User, Get the Good Life You Deserve

Anyone who works in IT and support knows how difficult it can be to get an end user to properly describe an issue that they’re having. Don’t even get me started on what happens if you ask them to provide a screen capture in a good scenario it will require launching a screen-capturing app, taking a screenshot, saving the file and sending it your way by an email or attaching it to a ticket. Not all end users know how to use, or even have, a screen-capturing app. But even if they do, it only adds more steps where something might get screwed up and delay the resolution time of the issue, i.e. the IT ticket which becomes *your* problem. SysAid simplifies this with its F11 hotkey. When the SysAid Agent is installed on the end user’s machine, all they have to do is hit the F11 key, and SysAid will capture whatever is on their screen, and automatically open SysAid’s Self-Service Portal, in order to submit a ticket with the screen capture already attached! Unless of course, their desktop is as messy as mine, in which case you might have second thoughts about them attaching it to the ticket ;) Cluttered desktop Even better when an end user presses the F11 hotkey, SysAid automatically signs the user into the Self-Service Portal (no need for manual login) and selects their computer as the associated asset in the ticket making your job of identifying their machine that much easier.

F11, F12, F13 (Just Kidding) Choose What You Want

If the F11 key is already in use in your organization by another software, no problem - you can easily customize SysAid to use a different key. It can be done from the beginning when deploying your SysAid Agents, or at any time afterwards by changing the SysAid Agent settings directly from the Asset List. Simply select the relevant assets, click on “Agent Settings” in the action menu and select a different F-key, or a different key altogether (using JavaScript key code e.g. F11 has a value of 122).
Another tip is to place the SysAid desktop shortcut on your taskbar (this is what I did - see the animated GIF below). It works exactly the same as clicking the F11 (or other) function key. You can click it whenever in need, and it will perform the actions described above just as well.

Coming Soon...

Last but not least good things come to those who wait. We plan on announcing, very soon,  a new surprise related to this feature. Keep your eyes peeled! For any questions and feedback, I encourage you to visit the SysAid Community where I’m always happy to help and/or just chat.
Continue reading

The 20 Best ITSM People to Follow on Twitter

Posted by on March 28, 2017 in ITSM
ITSM People on Twitter A few months back there was a lot of social love for a report that listed the top 100 IT service management (ITSM) “influencers.” As to whether the listed individuals are really influencers is open to debate, but I do know that I learn a lot via Twitter. So, I wrote my first draft of this blog and scheduled it for publication. Then Cherwell’s Alida Mooreston created a far more thoughtful and detailed “influencers” list (than the aforementioned one) – 25 IT Service Management Experts to Watch in 2017. As my UK friends would say: “You wait an hour for a bus, then three come along at once.” But since Twitter is definitely a preferred social network for so many in the ITSM industry looking to learn (I, for one, can often “feel” like I’m at an industry conference by simply following the designated Twitter hashtag), I thought I’d still publish my blog about who I see as some of the most valuable and prolific ITSM Twitter users (aka “tweeters”). There’s quite an overlap with Alida’s list, which has to be a good thing… but please don’t think that I’ve been copying! Before I continue, however, I need to state my Twitter “position” – that I’m not currently particularly overactive in the Twitterverse, and my views are formed from my lurking in the background rather than by my interactions with people. Twitter, and the tweets of these people in particular, has taught me so much about both the ITSM industry and how to best use this social medium.

20 of the Best ITSM People to Follow on Twitter

Firstly, I want to explain that my list is just people not corporate accounts. Some people will of course have company allegiances (don’t we all?) but they don’t use their Twitter account to hard sell you anything, other than good ITSM stuff. There’s no science to it, other than appreciating what these people are tweeting. And, in addition to the quality of what they share, you can feel as though you know the person somehow – they are more than a faceless tweet machine. I, of course, follow many more people, many of whom I did think of including, but I had to factor in people’s current tweeting cadence in deciding who would make my final 20. So I hope some of my ITSM friends don’t take it personally if they’re not on the list :). The list is in alphabetical order and, depending on when you find and read this blog, circumstances might have changed over time:
  1. Claire Agutter – she’s one of the busiest people in ITSM, playing a number of different roles, but she still gets her social on.
  2. Aprill Allen – there’s a reason her Twitter handle is @knowledgebird.
  3. Roy Atkinson – he has two Twitter accounts (@HDI_Analyst and @RoyAtkinson), so choose the one that suits your ITSM and help desk interests best (or both if you are feeling greedy).
  4. Breed Barrett – the lovely Breed tweets a varied mix of content from the @MacantaConsult
  5. Earl Begley – he’s the Jedi master of finding interesting ITSM articles and blogs to share.
  6. Alan Berkson – he definitely has a customer service and emerging support technology slant if you like that stuff.
  7. Daniel Breston – he loves mixing his Agile, Lean, and DevOps with ITSM.
  8. Stevie Chambers – he’s not really ITSM-focused but he’ll get you thinking about cloud and DevOps in particular.
  9. John Custy – he tweets what he finds interesting – and he finds a lot of ITSM stuff interesting.
  10. Sophie Danby – she might be pretending to know about IT (and ITSM), but she still shares some good stuff.
  11. Rob England (the IT Skeptic) – I believe that not following Rob is the ITSM equivalent of being an ostrich with its head in the ground.
  12. Matt Hooper – a man of many talents, and interests, which is reflected in his tweets.
  13. Joe the IT Guy – he might be a puppet but he definitely has his finger on the social ITSM pulse.
  14. Kaimar Karu – he’s a very busy man, with steering the good ship ITIL, who still finds time to tweet good stuff and to occasionally disagree with people.
  15. Stephen Mann – try spotting the good stuff among the occasional customer service failure moans.
  16. Sanjeev NC – he might work for an(other) ITSM tool vendor but he shows his peers how to do the virtuous tweeting well, particularly at ITSM events.
  17. Barclay Rae – it’s tweets from the father of #ITSMgoodness and itSMF UK CEO.
  18. Stuart Rance – it’s Stuart Rance, there’s nothing else that needs saying. It’s Stuart Rance!
  19. Greg Sanker – THE Twitter destination for words of ITSM wisdom in 140 characters or less.
  20. Paul Wilkinson – never one to shy away from an issue, Paul challenges the status quo and shares interesting content in equal measure.
So, that’s my list of 20 great ITSM tweeters – who do you think I missed?  
Continue reading

5 Ways to Better Equip the IT Service Desk for Enterprise IoT

Posted by on March 21, 2017 in Service Desk
Equip the IT Service Desk for Enterprise IoT While smart, connected devices in the home such as Amazon’s Echo get much of the media attention around the Internet of Things (IoT), there are many other IoT use cases already in the wild – especially use cases that relate to the improvement of business operations and services. Whether it’s automation, data collection/monitoring, controlling previously “dumb” devices, or something else, the use of IoT devices in the enterprise is growing rapidly as businesses seek to improve operations and the customer experience, gain greater insight into operations and service quality, and capitalize on new revenue streams.

The Impact of IoT on the Corporate IT Service Desk

These enterprise IoT “infrastructures” need supporting, and the existing corporate IT service desk is the most likely home for that support capability. Some might argue that support should lie with the business function that supplies the IoT-enabled service – for instance, that the facilities team should support a connected intelligent heating system. However, many of the issues that enterprises have already encountered with IoT devices relate to such business functions simply not understanding the risks and management needs, of what is ultimately technology. It will probably be an ongoing topic of debate for many companies, as the different lines of business “empires” want to keep or gain control of things, but for now, let’s assume that the corporate IT service desk has responsibility for IoT devices and the dependent services. There are a number of things that will affect them, such as:
  • Increased volumes. The IoT brings with it more end points, higher bandwidth usage, increased storage requirements, and more incidents. The IoT increases the IT infrastructure, and the scale of the management and support needs, by an order of magnitude. Service desks and their support tools will need to be able to handle thousands, potentially millions, of new end points and their data transmission and storage needs.
  • Greater complexity. When we talk of enterprise IoT devices we often think of things that aren’t attached to, or associated with people – for example a network-connected scanner or the sensors powering intelligent lighting or heating systems. But let’s not forget the IoT devices directly used by people. From the traditional PC and smart phone, through tablets and wearables, to intelligent personal assistants (such as the Echo) where voice is now the UI. Thus, complexity is not only the increased types of technology but also the reliance on different technologies for people to “get things done.”
  • Increased security requirements. Security now gets, and will continue to get, a big chunk of the enterprise IoT attention; and rightly so. In late-2016 we saw the first large-scale security attack attributed to the IoT – a distributed denial of service (DDoS) attack on Dyn, an internet infrastructure company, which was believed to be the work of a bot that uses IoT devices, protected only by the factory-default log-in details, to attack online services. IT security per se will of course also continue to be a high priority area for IT organizations in 2017.
  • Asset and configuration management. When an IT device is “used” by a person, it’s often easier to know (or to find out) it’s location, purpose, owner, and the impact of its failure. In the absence of “end users,” service desks will need to have a better appreciation and understanding of IoT assets – whether via configuration management, asset management, or knowledge management. This also covers the need to understand whether devices are up to date in terms of software and security patches.

Five Ways to Better Equip Your Service Desk for IoT

There are of course going to be far more than five things that could be done to help IT service desks deal with the growth in numbers and importance of IoT devices. But here are five to get you thinking:
  1. Service desk people need the ability to look beyond the technology to see the business impact of IoT device failures. Plus, the ability to recognize that a “silent” IoT device might be a far more urgent priority than a shouting business colleague – as the former might have a much worse business impact than the latter.
  2. Service desk people need new or improved IT management tools. Some might say they need new IoT management tools but I’m sure most IT pros would prefer to be able to use fewer management tools wherever possible. Ideally, existing IT management tools need to be able to deal with the types and high volumes of IoT devices we will see. Plus, the ability to predict future failures and launch remedial action before services are adversely impacted.
  3. Built-in redundancy and/or localized (but secure) stock. Cheap doesn’t always mean “easily breakable” but cheap does mean that it might cost more to visit and fix/replace an IoT device than the device costs (although some IoT devices will be expensive). And this is before the cost of business-affecting downtime is added into the equation. Thus, having crunched the numbers, it might be better to over-deploy cheaper IoT devices or to keep a local stock of spare devices such that downtime and the costs of replacement are minimized.
  4. Access to local support resources. I’m not referring to traditional desktop support but suitably-skilled business colleagues who are able to quickly rip-and-replace simple, inexpensive IoT devices when remote access can’t quickly diagnose and fix the issue. This is reinforced by localized stock (#3 above) and my next point (#5 below).
  5. Access to knowledge and better collaboration. In an IoT-dependent world, the availability of knowledge becomes even more important. Not just for service desk agents who now have a wider range of technology, and potentially services, to support. But also for business colleagues who might be assigned to support an IoT device that they use personally or that they are responsible for due to their locality. Plus, better collaboration is needed too, given that the issue and resolution might not always be addressable by the remote IT service desk team, with the issue passed to facilities, say, for a building engineer to address.
So there you have some key points to consider with the IoT. What would you add or disagree with?
Continue reading

Feeling Good about Your Help Desk

Posted by on March 14, 2017 in Help Desk
Feeing Good about Your Help Desk Everyone has a help desk these days, and the service that a help desk delivers will probably cover a range of aspects. The service will be delivered by a combination of human-to-human and computer-to-human interactions, by calls/emails/chats to help desk agents and use of the self-service portal via an organization’s integrated help desk software system. That combination of people and automation is what delivers support to the users. Along with the actual support, how that support is delivered in terms of the way people feel afterwards, will very much affect how willing those users are to us it again. The help desk deals with both incidents and requests in a similar way, although there is a key difference between them:
  • Requests is a user asking for something new or different, like a PC upgrade, additional software, or new access rights
  • Incidents are when something has gone wrong and the user is looking to get it put right.
So, requests are things you actually want to happen – improvements and new capabilities; incidents are things that nobody wants to happen.

Measuring the Help Desk

Because the help desk costs money – for staff, equipment, software, etc. – organizations feel the need to measure its performance, and its cost. So they record the money spent and measure metrics that describe how effective it is. Typically, organizations will measure the desk using a set of tension metrics to give a broad and balanced view of how well the help desk is performing against the targets set for it. This will give you a set of numbers and an indication of whether the help desk delivers what you’re paying for, and whether it’s getting better or worse against those measurements. It might include a measurement called something like ‘user satisfaction’ but, at best, that will be one small part of the measurement. The major focus gets put onto easier-to-measure aspects like ‘first time fix rate’ and ‘average call duration’.

How Does Your Help Desk Make Folks Feel?

I’m a firm believer that the best help desks add more to an organization’s potential than just numbers can easily measure. Every interface with the help desk is a transaction of sorts. We, all of us, know from our everyday lives that this kind of interaction delivers two kinds of outputs:
  • Did I get what I set out to get?
  • Has the experience made me happier or angrier?
Whether it’s booking a flight, making a doctor’s appointment, or a host of other things, most of us have had the experience of getting what you needed but having been upset by the overall experience. A host of factors can upset us: having to wait, rude operators, confusing screens with obscure questions, trouble understanding, and more. If your help desk is like this, your normal measures may show you meeting the service level targets you have set. But you will not be delivering the level of support your customers and users – and the organization as a whole – expect and deserve. Critically, unpleasant experiences with a help desk can have almost immediate detrimental effects on the business, such as:
  • Reluctance for the user to call again, meaning future requests are delayed and incidents will affect business performance for longer than they need do.
  • Increased temptation to try and fix things alone, or with peer support before considering to contact the help desk. This effectively stops both the user, and others, from working, and increases the prevalence of shadow IT.
  • A bad reputation, meaning customers are predisposed to see, and tell others about, the bad in your performance above the good.

Finding Out How They Feel about You…

It isn’t easy to get an accurate feel for how a help desk is perceived, and the effect it’s having on the user community. But you can try. Of course, the obvious thing is to ask your users, but that only gets us so far for a couple of reasons:
  • Firstly, IT isn’t always so good at building and interpreting the right approach to surveys. (Joe The IT Guy wrote about that in his blog: Is Your IT in the Shadows?)
  • There is usually a wide range of variables – different groups, at different times, in different circumstances will feel differently about their help desk experience. Unless you can measure across that range of variables, it’s almost impossible to prepare and implement relevant improvements. That range includes things like:
    • Request or incident?
    • Time of day, month, or business cycle
    • Users from different parts of the organization
    • Language and cultural differences
The issue here is that we’re trying to find out how the help desk makes people feel – was it a pleasant experience, did they actually feel helped afterwards or just like they had been processed by an impersonal service? Since it’s a feeling rather than an objective fact, sometimes subtler methods than simple questions are needed, i.e. more general conversations, and of course feedback from business relationship management, account managers, and the like.

…And Then Doing Something about It

It isn’t enough to learn the effect that your help desk has on your users. That knowledge has to then be applied to improve the impact, to increase the ‘feel good’ factor during interaction with the help desk. That might mean: targeted training for help desk staff; workshop sessions with the help desk’s users to increase awareness; better knowledge gathering and presentation so that help desk staff are more aware of their clients concerns and attitudes. There is a range of skills and practices that make a difference to a help desk providing a good experience. Obvious factors like interpersonal skills, awareness of the user’s role and environment those users live and work in, and so on. Time spent on training to increase these factors is usually time and money well spent. Another valuable and effective technique is simulation and practice – these can be done in-house fairly easily. Pick out some examples of past issues and take a group out of the workspace for a few hours to talk through how things were done and how else they might have been done. And, of course, do understand and encourage the application of “intelligent disobedience” (knowing when NOT to follow the rules) towards help desk performance and perception. Have you tried any of these “feel good” tactics? Please do let me know if it helped and how so. Sometimes I get inspiration from the Godfather of Soul himself…maybe you will too :)

Continue reading

Hide and Seek With Problem Management

Posted by on March 7, 2017 in ITSM
Hidden ITSM Problem Management If I asked you how your organization does problem management, would you, like so many of the people I have worked with over the years, tell me that you don’t do it? You know you ought to, of course, but you simply don’t have the time and resources to get started. I’m willing to bet that if you’re one of those people, and you asked me to take a close look at the running of your IT operation, you’d be surprised. Because, quite often, when I look at what people who work in IT organizations actually do, as opposed to listening to what they tell me they do, I find that they’re already quietly getting on with many of the things that need to be done to manage problems. They just don’t call what they do problem management. Too often people believe that problem management is something formal and complex that can’t be put in place without specialized tools and extensive training. And so they fail to recognize the power – or the potential – of the steps they’ve already put in place. I’m always really pleased when I come across a situation like this, because it’s a great position for an organization to be in. It only takes a very small amount of effort to create an effective problem management capability when you’re building on what’s already being done. (See my blog Back to ITSM Basics: Start Where You Are for some more thoughts on this idea.) So what should you look for if you want to know whether or not your IT organization already has in place the foundation it needs to build an effective problem management capability? Where do you start? Well, you start by understanding the difference between managing incidents – which any IT organization must do routinely – and managing problems.

What’s the Difference Between Incident Management and Problem Management?

In case you aren’t familiar with the difference between incidents and problems here’s a brief summary. An incident is “An unplanned interruption to an IT service or reduction in the quality of an IT service” (ITIL Glossary). Most incidents are detected by users who phone the service desk to report that something is wrong. The purpose of incident management is to get the business working again, and to reduce the overall impact of the incident as far as possible. For example, if a user reports that a printer isn’t working, then you could resolve the incident by routing their printout to another nearby printer so that they can get the document they need. Incident management activities include:
  • Identifying, categorizing, logging, and prioritizing incidents
  • Diagnosis and escalation (where needed)
  • Incident resolution and closure
  • Ensuring that users are kept informed about status
  • Managing the lifecycle of incidents and ensuring that SLA targets are met
For more information, see ITSM Basics: A Simple Introduction to Incident Management. A problem is “The cause of one or more incidents” (ITIL Glossary). The purpose of problem management is to prevent incidents from happening and to minimize the impact of incidents that can’t be prevented. For example, you could identify that a particular model of printer tends to fail after two years of use and plan to replace these printers before they fail. This would completely prevent the associated incidents. Alternatively, you could order a stock of spare printers so that you can replace them very quickly when they do fail, which would minimize the impact of the failures when they occur. Problem management activities include:
  • Analyzing incident trends to identify problems that should be investigated
  • Reviewing information from other sources, such as vendors or development teams, to identify problems that need to be managed
  • Investigating problems to identify what is causing the incidents
  • Developing and testing workarounds that can help to minimize the impact of future incidents
  • Identifying remedial actions that can prevent future incidents
For more information, see ITSM Basics: A Simple Introduction to Problem Management.

Hidden Problem Management

I started this blog by saying that many IT organizations are actually doing some problem management, even if they claim not to be. Here are some examples of things that I have seen in place:
  • A major incident review being held after every major incident, where everybody involved helps to understand:
    • What caused the incident
    • What can be done to prevent future similar incidents
    • What can be done to minimize the impact if the same thing happens again
This then results in improvement activities.
  • Technical support teams keeping up to date with information from vendors, identifying patches that need to be installed, and other proactive actions that can be taken to help prevent future incidents.
  • A service desk manager identifying frequent incidents, and reporting them to vendors or technical support teams for investigation.
  • A service desk agent developing a workaround for an incident and discussing it with co-workers, so it can be used whenever similar issues arise.
I have no doubt that there are many other examples of hidden problem management taking place. So, if you “don’t do problem management” why not take a close look at your organization and see what you discover?

Building an Effective Problem Management Capability

If you know you should be doing problem management, but keep putting it off because you think that it would involve too much effort and expense, then you should think about using three of the ITIL Practitioner guiding principles to help you get started: Observe Directly, Start Where You Are, and Progress Iteratively.
  • Observe Directly – Go and talk to people who work on the service desk, and in technical support teams. Make sure you know and understand what they are already doing. Identify the things that help your organization manage problems – there will almost certainly be some, if you look for them.
  • Start Where You Are – Think about how you could build on the things that people are already doing. If there really is nothing, introduce something, however small, making sure it’s straightforward but capable of producing useful results. But it’s more than likely that there will be a lot of good practice around, once you go looking for it. Start measuring and reporting the good practice that already exists; share best practice between teams; gradually increase the scope of the work that is already being done.
  • Progress Iteratively – Make small improvements, and measure how effective they are. Build on the ones that work well, and modify the ones that work less well. Then do it again.
If you follow these guiding principles you should find that you’re building an effective problem management capability at a very low cost and with minimum effort. And 2017 could be the year your increasingly proactive approach results in better service and happier customers. You can’t ask for better than that, can you? So why not give it a try?
Continue reading

A Different Way of Looking at Categorization

Posted by on February 21, 2017 in Service Desk
Different way of looking at categorization Categorization is a critical aspect of many IT service management (ITSM) processes.  Categorization helps us:
  • Route work associated with an incident or a request
  • Produce effective management reporting that enables further analysis or process improvements
  • Translate what a consumer is telling us into something that IT can understand and do something about
There’s a lot of good advice about categorization that is readily available via an internet search.  A couple of great articles can be found right here on the SysAid blog.  Stuart Rance shared his thoughts about categorization in his post titled Improving Categorizing Incidents. Another SysAid blog post, Incident Categorization – Reasons and Consequences, discusses the benefits of a good categorization scheme and the consequences of poor categorization. But how do you go about defining your categorization scheme? I have some ideas about categorization that I’d like you to consider.

Good Categorization Is About Balance

The most important thing to understand about categorization is that it is all about balance.  If a categorization scheme is too simple, it will inhibit work flow and trend analysis. The categories will simply be too broad or vague to facilitate effective process execution or continual improvement. The other end of the spectrum is a categorization scheme that is overly complex. While further definition may help with more precise workflow and analysis, this comes at a cost – the up-front time it would take a service desk agent to determine the exact category of an incident or request. While good documentation may mitigate this risk, keep in mind that a primary objective of a service desk is to complete its tasks in a timely manner. Service desk agents don’t necessarily have time to read through a lengthy procedure while the consumer is on the other side of a telephone call or chat session. Also, categories can and should change over time. As services are introduced or retired from the managed environment, there will be impact to a categorization scheme.  A good categorization approach recognizes that, and should strike a balance between the need for consistency for managing day-to-day activities with the flexibility needed when services do change.

Common Categorization Mistakes

Unfortunately, many organizations don’t take the need for balance into consideration when defining their categorization schemes. They often don’t think about how they want to leverage their categorization schemes in terms of workflow routing, reporting, or identifying improvements. As a result, I’ve seen them make the following mistakes:
  • Define categories based on the organizational chart This might work, and seem very straight-forward…until the organization chart changes.
  • Top level categories are “too technical” Generally speaking, the consumer has no knowledge of the underpinning technologies that are used in delivering service, and are unable to articulate an issue in technical terms. As a result, the service desk has to translate (read: guess) from the business-reported symptom to the technical taxonomy.
  • Too many top-level entries or a scheme that is “too deep” I once worked with a client that had a six-level deep categorization scheme. I’ve seen clients that had dozens of top-level entries in their categorization scheme. If there are too many entries (keep in mind that “too many” for one organization may or may not be too many for another organization), handle times for logging an incident will become needlessly excessive.
  • Assuming that the consumer “knows” the categorization scheme Yes, it may make absolute sense to the IT organization, but how (or even why) will the consumer know about the categorization scheme? The consumer has no idea how the scheme is defined, how the scheme is intended to be used, or even the cause of their issue so that it can be properly categorized within an IT-centric scheme.
  • Using “other” or “miscellaneous” as a category Frankly, this is laziness! If these categories are defined, they will (and do) inevitably become a dumping ground, nullifying the reasons for categorization to begin with!

Another Way of Looking at It

Consider this – what is the trigger for categorization?  How an incident is categorized is essentially based on what the consumer has said. So why not take a consumer-centric approach to categorization? In my experience, most categorization schemes have been defined following an “inside-out” approach. The scheme is defined based on the IT organization’s processes and services, and is pushed from “inside” IT “out” to the consumer. So why not look at it from the consumer’s perspective? Looking at this from the “outside,” or consumer’s perspective, what should the consumer’s experience be? This is known as “outside-in” thinking. So rather than trying to categorize incidents by “hardware” or “software” or “network” (all IT-ish ways of looking at an incident), why not categorize based on the consumer’s perspective? This might look something like “can’t print,” “error message,” “not working or slow,” or “need help.” From this top level, the service desk agent can then drill into the issue to identify further symptoms that will assist in determining how to manage the issue. Following this approach essentially defines the roadmap for helping the service desk agent categorize the issue; for example, “not working > intranet > broken link” or “need information > software > excel”.

Advantages of an Outside-In Approach

Here’s a few advantages of taking an outside-in approach to categorization:
  • It improves the customer experience – service desk agents can have a conversation (rather than follow a script) with the consumer to manage the incident.
  • Strikes the right balance – it allows for the needed flexibility (changes in offered services can be easily added or removed at a sublevel), while having consistency at the top level.
  • Removes the ‘tech speak’ from categorization – consumers need not be intimated by a call to the service desk, as the service desk will be enabled to speak and use terms that the consumer understands.
Taking an outside-in approach to categorization may seem awkward at first. But by taking this approach, both the consumer and the service provider will benefit by facilitating a good customer experience (and for more on that, I highly recommend you read Sarah Lahav’s blog Bridging the Gap Between Service and Customer Experience).
Continue reading
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 Next
Watch & learn from industry experts about ITSM and help desk hot topics!