Posted by Sarah Lahav
on May 9, 2017 in Cloud
Clouds are services, not products or technologies, so who better to manage them than an IT service manager with a “special set of skills.” Let’s call them Cloud Service Delivery Managers
The type of organization that has heavily invested in IT service management (ITSM)
is likely to be the “complicated” kind of IT organization that uses many cloud service providers to provision IT services. And while even the smallest, “simplest” organizations might be using multiple clouds for business and are struggling to manage all the different cloud bills, user accounts, and integrations – imagine that pain times-a-thousand. It’s the reality for these complex organizations as they juggle cloud, DevOps, ITSM, and possibly even service integration and management (SIAM)
Cloud Management Complexity
According to the RightScale State of Cloud 2017 Report
, which is based on a survey of over 1,000 practitioners, the cloud “situation” is getting increasingly complicated as cloud pushes into all aspects of business. From end users using cloud storage for work files, and cloud mail for email, to now replacing whole data centers with large cloud service providers – cloud is everywhere! Plus, DevOps
Thus, the challenge that all organizations have, regardless of size, is cloud service management. This ranges from consolidating the bills from the various services into finance all the way to some service administration and being the central point for standards and compliance. And the secret is to not “get in the way” while simultaneously de-risking the consumption of cloud services for the business.
Without someone like a Cloud Service Delivery Manager taking ownership for the above it will be the responsibility of each department, product team, or even individual end users. This might be perceived as great by freedom-seeking individuals who finally feel unshackled from IT – until, that is, the bill isn’t paid, confidential data is leaked by an ex-employee, or services can’t communicate – causing ever-increasing cost and pain.
This Cloud Service Delivery Manager role is an emerging reality, based on real organizational needs related to cloud computing. In this blog, I want to explore the needs driving the role and what the role actually entails.
The Driving Needs for Cloud Service Delivery Managers
All cloud services share similar characteristics and these can be seen differently through the eyes of a cloud optimist or cloud pessimist:
|Essential Cloud Characteristics
||Do it all by myself! No IT personnel needed!
||No IT involvement! No controls on end users!
|Broad network access
||Apps are available from anywhere
||Apps are available from outside controlled environments
||Lower cost by sharing public resources
||Noisy neighbors and risk of exposing business data
||I can balance business demand with cloud supply, scale to whatever I need
||Scale up but forget to scale down, wasting money, with unpredictable bills
||I can see exactly what I’ve used
||Multiple reports from different cloud service providers need reconciliation
At the heart of the Cloud Service Delivery Manager role is balancing these two perceptions, which brings us onto: What do Cloud Service Delivery Managers do?
The Roles and Responsibilities of a Cloud Service Delivery Manager
A Cloud Service Delivery Manager’s goal is to be at the center of tension between opposing drivers in the business. On the one hand, you have the business governance requirement to ensure risks are managed and money is spent wisely. On the other hand, you have business departments and individuals who want the empowerment and agility to create new business opportunities and revenues.
These two needs are often at odds because control can hamper agility, but not always – as the great IT Process Institute book, Visible Ops
, once said:
“Change (control) is like the brakes on your car – it lets you go faster!”
This quote is also used in the context of DevOps and increasing velocity.
Thus, the role of the Cloud Service Delivery Manager is to mirror this statement – to operate in this center of tension and to balance the opposing needs of agility and governance. But how?
The Cloud Service Delivery Manager needs to have responsibilities across five key areas:
|Cloud Service Delivery Manager Responsibilities
||➢ Consolidate all cloud bills for payment by finance
➢ Implement mechanisms to keep downward-pressure on spend such as turning of development resources (where unused out of business hours) and limiting subscriptions to those who need it for their role
||➢ Manage end-user adds, edits, and deletes to subscription services through a central directory
➢ Manage the on-boarding and exiting of staff in terms of cloud service subscriptions
➢ Run compliance reports on cloud services users and usage
||➢ Service catalog ownership and control
||➢ Educate cloud consumers on their rights and responsibilities
➢ Advise cloud service administrators on compliance requirements
➢ Run compliance reports, enforce standards and disciplinary policies
||➢ Maintain the map of business processes to services
➢ Assist with integration of cloud services (but the Cloud Service Delivery Managers don’t get in the way)
The secret to the success of this role is definitely “don’t get in the way” while mitigating risks and continually developing, monitoring, and enforcing standards and compliance.
As soon as the Cloud Service Delivery Manager makes the mistake of being a choke point where “all things cloud go through me” then it will introduce slowness and complexity into cloud service consumption, people will go around the Cloud Service Manager and the organization’s cloud consumption will splinter.
There are levels of maturity in cloud service management that can be understood by using a simple checklist, something the Cloud Service Delivery Manager will do with each cloud service:
The Cloud Service Delivery Manager could be a key role in your business as cloud services become all pervasive across the organization. Doing it badly will have a negative impact on business operations and success, such as if it becomes a choke point, but not doing it at all and letting individuals expose the business to known cloud risks with no guidelines could be more than negative – it could be catastrophic.
- What do I know about the cloud service? Is it invisible vs. on the radar vs. under control?
- Are we collecting metering and bills? Is finance paying for it, or is it on an employee credit card?
- Are we managing the end users? If the end users are not linked to the corporate directory, then this is a red flag risk.
- Is this service understood and available via on-boarding process via our service catalog?
- Do the cloud service consumers and administrators know their rights and responsibilities? Are they compliant? How can we help them enforce the rules? Do we have a reporting, escalation, and disciplinary process? Do we encourage whistle-blowers and white hat hackers?
- Is this service integrated into other services? What are the dependencies and what’s the business risk?
- Across all of the services, what’s the score of these services and where is it in our priorities for resource to improve?
Posted by Stuart Rance
on May 2, 2017 in ITSM
All the IT service providers I’ve worked with assure me that they measure the services they provide. They use metrics and KPIs to do this, and have service-level agreements (SLAs) with their customers, which they use to document what’s been agreed.
Unfortunately, most of the metrics and KPIs that I’ve seen only measure and report the things that service providers can control, and not the things their customers actually care about. This tends to result in reports that show service providers meeting most, if not all, of their targets, even when customers are distinctly unhappy about the service. This happens so frequently that the phenomenon even has a name: the “watermelon SLA
”. When you look at a watermelon from the outside, all you see is green. Delve a bit deeper and you discover that most of the fruit is red. In the same way, we report that everything is meeting its targets (it’s all green), but if you delve into the customer’s experience you find that it’s not very good (it’s mostly red).
So, what can service providers do that will help them to delve that bit deeper and focus on what matters?
What’s Important to Customers?
When service providers think about any service, they need to pay attention to what’s important: the value of the service, the intended outcomes, the costs, and the risks – together referred to as VOCR
. Here is a brief summary of what we mean by these terms.
- Value is a measure of the benefits that the service creates for the customer. This could be in terms of money, but it might be something like lives saved, or some other indication of the customer’s mission.
- Outcomes are the things that the customer achieves as a result of receiving the service. For example the service may help the customer to manufacturer products, or communicate with their partners, or collect payments on a web site.
- Costs are the money that the customer has to spend to achieve the outcomes they want.
- Risks are possible events that could affect the ability of the customer to achieve the desired outcomes.
In my view, if every service provider produced reports showing the VOCR of their services, then customers would have no difficulty understanding what these reports mean, and judging whether the service was good value (or not).
Of course, it’s not that easy. The trouble is that value, outcomes, costs, and risks are only partially under the control of an individual service provider. For example, consider an IT company that provides a manufacturing support service to a car manufacturer. The outcome that the customer wants might be “a car comes off the production line every 40 seconds” (my thanks to James Finister
for this example), but this outcome is not completely controlled by the IT service. Even if the IT service
works perfectly there could be other reasons why a car doesn’t come off the production line. So, what should you measure and report in this case?
What Should You Report to Your Customers?
Under these circumstances most IT service providers would probably report things like:
- Availability of the IT service
- Number and severity of incidents
- Average time to resolve incidents, subdivided by category
The information provided might be accurate, but it is very IT specific. It represents an IT service provider’s view of the world. But of course, this isn’t what the customer cares about. The metrics that matter to the customer are how many cars come off the production line (outcome), how much extra cost do they have due to IT failures (cost), how much lost production might they have next week (risk), and derived from these, how much profit can they make selling cars (value).
So, is it possible to create IT metrics and reports that actually show all of these things? Yes, it is. An ideal SLA could state the following:
“The desired outcome from this service is to support the production of one car every 40 seconds.”
The monthly report could then show whether this was achieved. Similarly there could be report sections on cost and risk, showing how well these have been managed for the customer.
Does this mean we stop measuring IT service availability, number and severity of incidents, incident resolution times? Obviously not. Providers can’t do their jobs well without this information. What I am saying is that these are not the key things to report to the customer. The main findings of any report to customers should be about value, outcomes, cost and risk; IT-centric issues should be reported within this context, as contributing factors, and at whatever level of detail suits the specific customer.
Here are two more examples of IT organizations that have great business-focused reports:
What about your SLAs and customer reports? Are they about IT or are they about value, outcomes, cost, and risk? Maybe it’s time to think about what your customers really care about, and create SLAs and reports that match their view of the world.
- One client that I worked with had a key business metric stating that they should never lose any customer data (the data represented a lot of money). It didn’t matter if the data was lost because a paper document got lost before it was scanned, or because of an IT error. The thing that mattered is that every piece of customer data must be correct and accurate at all times. The reports they produced started by summarizing the status of customer data, THEN they went on to account for any risks or issues that had occurred that month. Some of these were IT related, others were down to the various business units, but the report included everything.
- Another client was responsible for shipping parcels to end customers. Their key metrics were the percentage of parcels that arrived on time, and the percentage of parcels that were lost. As in the other examples, these things might be caused by IT failures, or they might be due to many other issues, but the IT reports focused on the business metrics, and then on how IT had contributed to these.
Posted by Doug Tedder
on April 25, 2017 in ITSM
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
- 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.
- 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!
- 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.
- 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.
- 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.
- CABs do not have the proper membership.
CABs are often just made up of IT personnel, with no participation from business colleagues.
- 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
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:
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”!
- 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.
- 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.
- 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).
- 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.
- 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.
- 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!
- 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.”
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
IT service management (ITSM)
Posted by Sarah Lahav
on April 18, 2017 in 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?
Posted by Rafi Rainshtein
on April 12, 2017 in Cloud
” 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:
- The misleading serverless name
- Serverless on a napkin
- Comparing serverless to other computing paradigms
- The serverless ecosystem
- 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
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
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:
- You write and upload your code.
- You define the triggers.
- An event triggers your code.
- Your code does one thing.
- 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.
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.
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:
||Node.js, Python, Java
||C#, Node.js, Python, F#, PHP, Java
|Google Cloud Functions
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:
Image 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?
Posted by Stuart Rance
on April 4, 2017 in ITSM
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.
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.
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!
Posted by Danny Tashiev
on March 30, 2017 in SysAid
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 ;)
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
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.
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.
Posted by Dena Wieder-Freiden
on March 28, 2017 in ITSM
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:
So, that’s my list of 20 great ITSM tweeters – who do you think I missed?
- Claire Agutter – she’s one of the busiest people in ITSM, playing a number of different roles, but she still gets her social on.
- Aprill Allen – there’s a reason her Twitter handle is @knowledgebird.
- 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).
- Breed Barrett – the lovely Breed tweets a varied mix of content from the @MacantaConsult
- Earl Begley – he’s the Jedi master of finding interesting ITSM articles and blogs to share.
- Alan Berkson – he definitely has a customer service and emerging support technology slant if you like that stuff.
- Daniel Breston – he loves mixing his Agile, Lean, and DevOps with ITSM.
- Stevie Chambers – he’s not really ITSM-focused but he’ll get you thinking about cloud and DevOps in particular.
- John Custy – he tweets what he finds interesting – and he finds a lot of ITSM stuff interesting.
- Sophie Danby – she might be pretending to know about IT (and ITSM), but she still shares some good stuff.
- 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.
- Matt Hooper – a man of many talents, and interests, which is reflected in his tweets.
- Joe the IT Guy – he might be a puppet but he definitely has his finger on the social ITSM pulse.
- 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.
- Stephen Mann – try spotting the good stuff among the occasional customer service failure moans.
- 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.
- Barclay Rae – it’s tweets from the father of #ITSMgoodness and itSMF UK CEO.
- Stuart Rance – it’s Stuart Rance, there’s nothing else that needs saying. It’s Stuart Rance!
- Greg Sanker – THE Twitter destination for words of ITSM wisdom in 140 characters or less.
- Paul Wilkinson – never one to shy away from an issue, Paul challenges the status quo and shares interesting content in equal measure.
Posted by Sarah Lahav
on March 21, 2017 in Service Desk
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:
So there you have some key points to consider with the IoT. What would you add or disagree with?
- 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.
- 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.
- 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.
- 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).
- 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.
Posted by Dena Wieder-Freiden
on March 14, 2017 in 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.https://www.sysaid.com/help-desk-software
The help desk deals with both incidents
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 :)