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.

How Can You Create an SLA that Helps to Delight Your Customers?

Posted by on November 5, 2014 in ITIL
How Can You Create an SLA that Helps to Delight Your Customers? IT people tend to like technology, and we like things to be clear and unambiguous, with proper facts and figures. In some other areas of expertise people are more comfortable with things that are abstract, less well-defined and harder to measure, but we tend to stick to the facts. This cultural difference can lead to big problems when it comes to negotiating and agreeing on service level agreements (SLAs) with our customers. We want the content in our SLA to be well-defined and unambiguous. All our books say that metrics should be SMART (specific, measureable, achievable, relevant and time-based), and everyone in IT agrees that SLA targets must be written like this. The trouble is that our customers are often quite bad at defining SMART targets, so we usually have to do it for them. We don’t just ask the customers what they want and write that down, because their ideas aren’t SMART enough, so we go to the customer with a generic SLA and tell them that we can negotiate this number or that number, but we rarely agree to completely change the whole way we write about services. One result of this approach to negotiating SLAs is that customers don’t feel ownership of the SLA, they think of them as “the IT SLAs”.  In many cases customers think that the SLA is there for the IT department to hide behind, reporting numbers that mean little to the business but failing to deliver the services that they really want. I have seen some truly horrible behaviour from IT departments where they think meeting the SLA is all they are supposed to do.
  • One IT department had a target that they should close 98% of Priority 1 incidents within 4 hours and 95% of Priority 2 incidents within 8 hours. Towards the end of one quarter an operations manager sent an email to service desk staff saying that the target for Priority 1 incidents would be met, even if the next Priority 1 incident took too long to resolve, but there was a risk that the target for Priority 2 incidents would be missed – so everyone should focus on Priority 2 incidents even if there was a Priority 1 incident open. The customer found out about this and was extremely angry. The IT department met their SLA, but the customer experience was very negative and it took a long time to re-establish trust.
  • Another customer was very unhappy because there had been a number of service outages that had had a significant impact on the business, but IT pointed out that the service had met the 99.5% availability target, and didn’t seem interested in addressing the issue.
How can we bridge this gap between what IT can measure and report, and what our business customers really care about? One approach that I have seen used very successfully is to include both what we can measure AND what the customer wants in the SLA. This is how it works:

1. Find out what the customer really wants

Start by asking the customer what they want from the IT service. Let them tell you in their own words and write this down. Get the customer to check that what you have captured really is what they want, and let them reword the statements until they are happy with them. Here are examples of some things that customers might ask you for:
  • Downtime of the service should not have a significant impact on the business process
  • Data should be protected so that there are no embarrassing security breaches
  • When we have a problem it should be fixed quickly
  • If we need to change the business process then IT should be agile and not get in the way of the change
  • Transactions should be fast enough that they don’t delay staff when they are trying to serve customers
  • If there is a disaster then the IT systems should be recovered by the time the rest of the business recovery plan needs them
Once you have a complete list, ask the customer to confirm that if you achieve all this, will they then be delighted with the service. Make sure you really have captured what they want. Most (maybe all) of these things won’t be measureable. Don’t worry about this, we’re going to think about measurement next. You have to start by moving out of your comfort zone to the place where your customer is, before you ask the customer to move a little bit towards where you are.

2. Think about what you can actually measure

Take each of the customer statements and think about what you could measure that would be relevant to this. Accept that you can’t actually measure the thing the customer really wants; this doesn’t mean that you can’t make a relevant measurement. There is a great book by Douglas W. Hubbard called How to Measure Anything: Finding the Value of Intangibles in Business, which explains that a measurement is any observation that reduces your uncertainty. Hubbard shows how you can measure anything you need to, and you can measure it to any level of accuracy you want if you are prepared to invest enough effort. Taking some of the examples above, here are some relevant measurements you could make:
  • When we have a problem it should be fixed quickly
    • Priority 1 problems will be resolved within 1 hour
    • Priority 2 problems will be resolved within 8 hours
    • etc.
  • If we need to change the business process then IT should be agile and not get in the way of the change
    • Initial assessment of any change request will be complete within 24 hours
    • Minor changes will be implemented within two weeks of the change being approved
    • A plan for implementation of major changes will be available within four weeks of the change being approved
  • Transactions should be fast enough that they don’t delay staff when they are trying to serve customers
    • 99% of logins will complete within 10 seconds
    • 99% of sales transactions will complete within 20 seconds
    • 100% of sales transactions will complete within 40 seconds
    • etc.

3. Discuss the measurements with your customer

Explain to the customer that you are going to measure and report these numbers, and ask if they agree that achieving the numerical targets will tend to indicate that you have achieved the real customer target. Make sure they understand that the numbers are NOT the real target, they are just what you will measure. The customer may suggest some other things you could measure, or they may want to change the numbers. This is fine, you are now working in your space, negotiating numerical targets with the customer.

4. Make regular measurements and discuss achievements with customers

You can now measure your agreed numerical targets and capture the results in regular customer reports. Don’t make the mistake of thinking that achieving the numerical targets proves that you have delivered what the customer wants. When you hold your customer meeting you should be making statements like: "The SLA target says ‘Transactions should be fast enough that they don’t delay staff when they are trying to serve customers’, and the figures we measured this month show that 99.5% of logins completed within 10 seconds and 100% of sales transactions completed within 20 seconds. Are you happy with this?" You can also use the numerical measures to show trends, to help the customer understand whether you are improving the service. Note that you haven’t told the customer that they are happy, or that the measurements prove that the target was achieved. What you have done is reported the numbers and asked the customer if they are happy. They can now respond to this by confirming that they are happy, or by explaining why these measurements aren’t quite right. Maybe they will say that some logins took 3 or 4 minutes and this was a big problem, so you can now add another measurement to capture a new numerical target of "100% of logins complete within 30 seconds".


The whole point of this approach is that you are measuring and reporting things that you can control and understand, but that you are framing your reports in language that the customer cares about. Remember that you should NEVER tell the customer that the numbers mean they are happy. The numbers are simply an indication that you can use to show trends, and to help the customer express what they want in terms you can understand. What kind of language and measurements do you have in your SLAs? Are you brave enough to step outside your comfort zone and start writing SLAs in customer language?

Like this article? You may also like: If You Don't Have an SLA, You're Delivering Bad Service.

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Everything ITSM in Less Than Three Days

Posted by on October 28, 2014 in ITSM
FUSION 14: Everything ITSM in less than 3 days Well FUSION 14 was a whirlwind of ITSM Goodness (the royalties check is in the post Barclay Rae). Working the SysAid booth, trying to attend conference sessions, meetings with clever people, and the informal networking can be tough when you’re small. Although IT service management (ITSM) BFG Michael Slabodnick was also probably looking forward to the weekend at home post-FUSION 14. This blog is a quick snapshot of the event, which SysAid will build upon over the next few months via our blog sites:I have written a number of blogs about metrics and KPIs recently, each focussing on a different area of IT service management. Here are some links in case you’ve missed any of them.

Key Takeaways

The conference sessions started with an interactive presentation that, for me, set the scene for the issues and opportunities that would run throughout the conference – courtesy of Jenny Rains, Cinda Daly, and the customer service demi-god that is Roy Atkinson. Some of their key points, based on recent HDI research, were that:
  • “Service organizations are still challenged to demonstrate business value and to support sustainable business growth.”
  • “Service and support models are changing to streamline, enhance mobile and remote support, bolster shift-left, AND become the single point of contact for all business services.”
  • Automation and self-service are growing in use. Two great statistics were that: remote control technology is now (unbelievably) more common in support centers than incident management technology, and 85% of organizations now provide some type of self-help facility.
  • The use of ITSM tools and techniques outside of IT continues to grow. 25% of organizations have already taken ITSM outside of IT, with another 26% currently doing, or planning to do, so.
  • Knowledge management is in vogue (again). Ranked second to incident management as the most important technology required for successful end-user support.
Look out for the full HDI “Service Management: Not Just for IT Anymore” report that will be available soon. We shouldn’t fail to recognize the West Coast alternative to FUSION 14 – DevOps Enterprise Summit (#DOES14) – where some of the people you might expect to see at FUSION (such as Glenn O’Donnell, Gene Kim, Rob England, and Kaimar Karu) were having fun. You can read a summary by Mirco Hering here. There were of course DevOps sessions at FUSION 14 but my spies tell me that they weren’t as well attended by ITSM practitioners as the more traditionally-focused ITSM sessions. It makes me wonder how involved, or interested, Ops (including ITSM) people are in the opportunities of DevOps.

A Little More Information

As not everyone was lucky enough to attend the event, we thought it might be useful to pull together a list of recommended reading to help you learn more about these key takeaways:

Other Topics

There were over 80 track sessions, with advice provided on a wide variety of other ITSM topics such as: I’m sure many of the presenters won’t mind you messaging them via Twitter if you want to find out more about their sessions.


I really enjoyed the conference, though I have to admit that a big part of this was seeing the industry people I know and love again, and talking with new people while working in the Expo Hall. This is often the case, as (wo)manning the booth takes up a big part of the conference for vendor attendees at the expense of the conference sessions. My biggest gripe, as with many of the larger industry conferences, is that too many great speakers are scheduled at the same time. Not only is it Sophie’s Choice based on what (well who) I know, and I realize I shouldn’t moan about the wealth of knowledge on tap, but having too many of my friends speaking at the same time also prevents me (and probably others) from trying out new speakers. Maybe at the next conference I should only attend the sessions of people I don’t know – a higher risk strategy, but we all know that higher risk investments can provide higher returns. Finally, over the next few months Joe the IT Guy will be blogging around these and other topics covered at FUSION 14. And, if you feel like you missed out, then there’s always next year – FUSION 15 runs from November 1-4 2015 in New Orleans. That’s my 2 cents on FUSION 14, and I’d love to hear your thoughts on FUSION 14 if you were lucky enough to be there too.

Like this article? You may also like: FUSION14: Bringing the ITSM Community Together for the Greater Good.

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

How to Make Sure Your KPIs Are Balanced

Posted by on October 21, 2014 in ITIL
Balanced IT service management KPIs I have written a number of blogs about metrics and KPIs recently, each focussing on a different area of IT service management. Here are some links in case you’ve missed any of them. It's great to have well thought out KPIs for individual ITSM processes, but if you combine them all you will end up with a huge unwieldy report that’s of very limited use to anyone. Every report must be useful to its audience, and everything in the report should be focussed on that audience. Somehow you need to create balanced reports for different audiences, but they all need to derive from the data that you have collected about what you are doing. My preferred approach to achieving this is to use a balanced scorecard.

What is a Balanced Scorecard?

A balanced scorecard is a way of thinking about metrics that helps you to focus on strategic goals. The balanced scorecard defines four perspectives, and every report should include metrics that are balanced between these.
  • Financial metrics help you to understand how well you are using your organizations’ resources.
  • Customer metrics help you to understand how well you are serving customers’ needs, and how satisfied the customers are with your services.
  • Internal business processes metrics help you to understand the efficiency and effectiveness of your internal processes, and whether they are meeting their agreed goals.
  • Learning and growth metrics help you to understand how well you are preparing for the future, and whether you are continually improving in order to remain competitive.
These four perspectives can be used at many different levels within an organization, and can form a cascade to link together reporting at each level, so that it all rolls up to provide useful data for management decision making. They can also help you to move from an old-fashioned “inside-out” view of your work towards an “outside-in” view that thinks about what you do from the perspective of the customers who fund everything. The strategic metrics that you could report with a balanced scorecard are not typically ITSM focussed. A strategic balanced scorecard typically includes metrics like: return on capital employed, customer churn rate, number of business process errors, or average staff training hours per year. This is the sort of thing that senior management in the business care about. The great thing about a balanced scorecard though, is that you can break down the high level business goals into goals for each business unit, and then team or process goals below that. Each set of goals retains all four perspectives but considers them from a different organizational context. For example you might have an overall IT report that shows:
  • Financial: Percentage of annual turnover spent on IT. Return on investment in IT projects.
  • Customer: IT customer satisfaction rating. Achievement against end-to-end service metrics.
  • Internal business processes: Number of ITSM processes meeting their internal goals. Number of IT projects meeting their agreed goals.
  • Learning and growth: Number of improvement opportunities completed from CSI register. Average hours training per year for IT staff.
This can then be further broken down to individual ITSM processes, or technology groups. So for example the service desk could measure and report:
  • Financial: Total annual cost of running the service desk. Average cost per incident.
  • Customer: Incident closure satisfaction ratings. Achievement of SLA commitments.
  • Internal business processes: Number of problems logged by service desk.
  • Learning and growth: Number of improvement opportunities logged on CSI register by service desk staff and accepted for implementation. Number of service desk staff who spent at least 4 hours working in a business unit to learn about their customers.
The great thing about using a balanced scorecard approach to metrics and reporting is that you can focus each report on the audience it is intended for, by collating, averaging, or summarizing data from more detailed reports. You can ensure that each team and each process thinks beyond their view of the business to how they are impacting the rest of the organization, and you can make sure that everyone thinks about a broad range of metrics, not just the detailed process metrics that some IT organizations focus on. How many of these four perspectives are covered by your existing ITSM metrics? Could you add some new metrics and KPIs to improve the balance of your reports, and their relevance to the audience? Could you move some of your existing metrics and KPIs to reports that are just used for process managers, to avoid overloading customer-facing reports with internal ITSM information?

Like this article? You may also like: What's the Point of Configuration Management?.

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

FUSION14: Bringing the ITSM Community Together for the Greater Good

Posted by on October 14, 2014 in ITSM
Our first visit to ITSM Fusion In the words of Peter, Paul, and Mary (or, if you prefer, John Denver), "All my bags are packed, I'm ready to go …" for SysAid's first visit to FUSION – an annual IT service management (ITSM) conference for ITSM professionals and IT leaders, brought to the ITSM Community by:
  • itSMF USA – a member-driven organization, and the United States chapter of the itSMF international organization, organized into local interest groups (LIGs) and special interest groups (SIGs) located in over 43 major metropolitan areas; and
  • HDI – a professional association and certification body for the technical service and support industry, serving a community of more than 120,000 technical service and support professionals.
We’re pretty excited about being there, meeting friends old and new, and learning more about ITSM in the conference track sessions on the 20-22 October 2014.

Socially Yours

If you can’t make it, but still want to hear what’s happening, you can follow the Twitter stream using #smfusion14 or follow the accounts of people I know will be tweeting there (some of them way too much): And hopefully many more people. Sadly there will be no Patrick Bolger there this year though. Even though he works for a competitor, we still love him.

Content Is King

FUSION is renowned for the breadth of its session content. This year is no exception with the nine tracks covering:
  • The Beginner’s View
  • Continual Service Improvement
  • Emerging Technologies
  • The Expert Focus
  • Industry Insights
  • IT Governance and Security
  • The People Factor
  • Service Support and Operations
  • The Strategic View
With so much content it’s hard to choose which sessions to attend, but here are a few I’m looking forward to.

Sophie's Choice

In no particular order other than date and time, I’m hoping to attend the following sessions amongst others: Monday, October 20 | 10:15am-11:15am SESSION 106: HOW TO ESTABLISH YOUR ENTERPRISE GENIUS BAR Speaker:  Jarod Greene (Gartner) Which unfortunately clashes with: SESSION 108: SUPPORT CENTER 2.0: LEADING THE CHARGE FORWARD Speakers:  Roy Atkinson (HDI), Cinda Daly (Focus Events), Jenny Rains (HDI) So I’m looking into cloning technologies. Monday, October 20 | 11:30am-12:30pm SESSION 202: PROBLEM MANAGEMENT: MAKING IT WORK FOR YOUR ORGANIZATION Speaker:  John Custy (JPC GROUP) Which clashes with: SESSION 209: COBIT AND ITIL SELF-ASSESSMENTS: ARE THEY FOR ME? Speaker:  Dr. Mauricio Corona (BP Gurus) Monday, October 20 | 03:00pm-04:00pm SESSION 304: EXPERT FOCUS: CONTROL SHIFT: HOW TO TALK TO YOUR CUSTOMERS ABOUT MANAGING SERVICES Speaker:  Hank Marquis (Global Knowledge) Tuesday, October 21 | 10:00am-11:00am SESSION 406: BREAKING DOWN THE BARRIERS BETWEEN LEVELS OF SUPPORT Speaker:  Rae Ann Bruno (Business Solutions Training Inc.) Tuesday, October 21 | 11:15am-12:15pm SESSION 505: TAKING THE MYSTERY OUT OF THE INTERNET OF THINGS Speaker:  Robert Stroud (CA Technologies) Which clashes with: SESSION 506: UPGRADING TO THE SERVICE DESK 2.0 Speaker:  Aale Roos (Pohjoisviitta Oy) Tuesday, October 21 | 02:45pm-03:45pm SESSION 601: ITSM NEXT Speaker:  Matthew Hooper (ISM) This one clashes with a number of other great sessions from industry luminaries Ian Clayton, David Cannon, and Jayne Groll in particular. Wednesday, October 22 | 10:15am-11:15am SESSION 803: CRASH AND BURN: HOW TO SCREW UP ITSM AND STILL CREATE AN ITSM FLIGHT PLAN Speakers:  Adrienne DuBrul (AC Group International), Chris Jaquay-Williams (AC Group International) So I’ve some tough decisions to make before the sessions start.

All Hail the Chief

Finally, Charles Araujo will be stepping into the itSMF USA President role at FUSION. We, especially Joe The IT Guy, would like to wish him all the best for the forthcoming year. We may have a special surprise to follow… If you are thinking about attending, more details can be found here. If you are attending, please search us out – we’ll be hanging with Joe The IT Guy and we love to talk ITSM, IT service delivery, and IT support.

Like this article? You may also like: IT Service Management at LEADit - It's as Easy as ABC.

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

BYOD: Will IT Departments Live Long and Prosper?

Posted by on October 7, 2014 in BYOD
BYOD: Will IT departments live long and prosper? Last week at Interop, New York’s Javits Center was abuzz with IT professionals seeking practical advice on IT management good practices (and the technology to support them). The conference element included the following tracks:
  • Applications
  • Business of IT
  • Cloud Connect Summit
  • Collaboration
  • Infrastructure
  • Mobility
  • Risk Management & Security
  • Software-Defined Networking (SDN)
This BYOD* and mobility-related blog is the first of a number of SysAid blogs based on the Interop sessions – with the intention of spreading the Interop advice and good practice wider than its physical attendees.

BYOD and Star Trek

Michele Chubirka, a security architect and best practice researcher, presented on “BYOD: Beating IT’s Kobayashi Maru.” For those of you not up on their Star Trek folklore, Kobayashi Maru refers to a no-win situation, or the need to redefine the problem. In this case, that in Michele’s opinion: “The answer to BYOD cannot be, “No,” but a qualified “Yes, and….”” The point is that BYOD is not something that can be prevented, bar situations where industry legislation or regulations limit the use of certain technology – corporate or otherwise – in the workplace. And, instead of fighting BYOD, corporate IT organizations should be looking to ensure that they are ready for, and accommodating to, BYOD – and both protecting business assets and operations, and optimizing employee productivity.

BYOD Needs Policies and Standards

Michele stated that organizations need to have the following in place for BYOD:
  • High-level BYOD policy
  • Acceptable use policy (AUP)
  • End-user agreement (EUA)
  • Data classification and handling standards
  • Basic user roles/classification
  • Supported application list
  • Resource matrix
And that organizations don’t need to reinvent the wheel here. Instead they should use Google to find existing examples of the above, which can be tailored to suit their own needs. For example, the White House’s BYOD guidance for government, or SANS’s AUP.

Guidance on Access Control

Michele also offered the following security-flavored advice, that:
  • Data has value and should be organized according to:
    • Sensitivity to loss
    • Disclosure
    • Unavailability
  • Appropriate application of controls creates the handling standards
  • User roles or personas determine privilege levels
  • Access controls are determined by the intersection of data classification with user classification
But it’s not just about security.

Employee Support Needs to Be Well Thought Out

No IT support organization could realistically support every BYOD device, personally-acquired application, or personally-chosen use case. So organizations need to be very clear on what they will and will not support. Michele's three key support points were that:
  • Even though you don’t own the device, what applications will you license and/or support on it?
  • How will you communicate this?
  • Many support costs don’t go away, they simply shift
She also pointed out that a resource matrix should be used, based on data classification and the level of risk the organization will accept, to document which applications and facilities are approved, provided, and supported for corporately owned devices, employee BYOD devices, and office guests.

Common BYOD Misconceptions

Michele finished with a short list of BYOD misconceptions:
  • BYOD is less secure
  • I can say "no" to BYOD
  • BYOD will always save money
  • I have to buy expensive solutions
  • I have to reimburse users to force adoption
  • We don’t need to consult HR or Legal

Key Takeaways

And some key takeaways for the audience (and now you):
  • Controls should focus on data/resources, not technology
  • Policies become requirements, don’t jump to solutions; you will pay for it later if you skip this step
  • Get executive buy-in on policies and sign-off on design, otherwise you’ll be redesigning later
  • Training and end-user support is critical
  • Offer options: full device management vs. containerization**
  • BYOD is no longer optional
So there’s a lot to consider from a BYOD management and service delivery perspective. But, importantly for us at SysAid, one has to remember that mobility isn’t really about mobile devices and apps. Rather, it’s really about supporting employees and customers while they are on the go – it’s about service delivery and service experience, and the pursuit of business over IT outcomes. If you want to hear more from Michele Chubirka you can find her on Twitter as @MrsYisWhy. * BYOD = bring your own device, the use of personally owned devices in the workplace ** And not forgetting mobile virtualization options such as Nubo. Image credit

Like this article? You may also like: Nubo - World's First Remote Android BYOD Launches.

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Interop: a First-Timer’s View

Posted by on October 2, 2014 in General IT
Interop: a non ITSM event Well, SysAid’s and my first day at Interop New York was a busy one. As Joe the IT Guy states in his pre-Interop blog, SysAid is the only pure-play IT service management (ITSM) vendor at the event, which meant that we had some very meaningful conversations with attendees about ITSM, service desks, IT support, and improving IT service delivery. It was a very different experience to the many ITSM events we have previously exhibited, and in a good way. But you don’t want to read about the SysAid booth traffic. And, while I was on the booth most of the day, I still managed to attend the four keynotes and a Women in IT lunch panel.

Keynote Gems

I enjoyed the four keynotes to different extents based on what I took away from them and how the presenters engaged me. I’m quite black-and-white with presentations – I’d rather listen to a poor presenter deliver great content than a great presenter with poor content. Plus, of course, the personal relevancy of the presentation makes a massive difference. The first keynote, Ben Haines of Box being interviewed by R Ray Wang, offered up a number of gems such as:
  • "The common thing across all industry verticals is the need for speed of change."
  • "We talk in weeks and months for delivering new services not years."
  • "We need to think about users at the center of everything we do now."
With R Ray Wang throwing in an insightful: "Users want IT to be simple, scalable, and sexy." In the second keynote, Steve Comstock of CBS Interactive, aimed to convince the audience that Shadow IT is an opportunity for, rather than a threat to, corporate IT departments. It was humorous and engaging, recounting Steve’s personal journey with Shadow IT over the last 15+ years and how the IT organizations he has worked in needed to change. I particularly liked the statement that: “My IT conversations with business partners used to be like awkward first dates. We couldn't converse.” I think this resonated with many in the audience. But the real piece of wisdom was:“The problem with ‘engaging with the business’ is that IT people are rarely given advice on HOW to do this successfully.” How often is this true with non-technical aspects of IT management? We are frequently pointed in the right direction (on a journey of change) but are rarely offered a map and compass to help us make the journey successfully, and as swiftly as possible. Then John Jeremiah of HP offered advice on mobility, starting with some potentially hurtful home truths for IT, that:
  • "IT organizations often have mobility initiatives because they want to do mobility not because of user needs."
  • "It shouldn't be a mobile first mantra, it should be users first."
This and more - before talking about how HP can help throughout the mobility lifecycle. The fourth and final keynote was comedian Seth Myers who sent the audience off to the Expo with smiles on their faces.

Women in IT

As I mentioned in the pre-Interop interview I had with Adrian Bridgewater on Computer Weekly, I was really looking forward to the Women in IT lunch panel. And, as evidenced by the relatively small number of women (compared to men) in the day one keynotes’ audience, such initiatives stack up against valid concerns over workplace diversity. If you pardon my potentially inappropriate humor, I usually find IT conferences to be one of the only places where it’s the men’s restroom that has the queue. Sadly though, the Women in IT lunch panel didn’t live up to my expectations. I guess I had expected, and wanted, to hear a series of tangible things that female attendees could personally leverage. Proven plans, practices, activities, or techniques that had been shown to repeatedly help women succeed in IT work environments. Instead, the panel delivered personal stories of how they had individually triumphed within their own careers that, while sometimes interesting, did not leave me with my desired list of concrete things my female colleagues and I could use to our advantage. My disappointment soon disappeared though, thanks to the ladies of Bronx Academy for Software Engineering (BASE) who came over to chat to us at the SysAid booth. I was totally blown away by their enthusiasm and passion for technology. They are the future of Women in IT. So a mixed bag for me, but that is often the case for events - in that you can’t please everyone (given our individual wants, needs, and expectations) all of the time. And I’m really looking forward to day two of the Expo. More content to follow!

Like this article? You may also like: Like a Virgin - ITSM for the Very First Time.

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

CVE-2014-6271 aka Shellshock Bash Bug

Posted by on September 28, 2014 in General IT
CVE-2014-6271 aka Shellshock Bash Bug Remember Heartbleed? Back in April, I was flooded with questions from our customers, so I wrote that blog post about it when the hype was about as big as Apple’s iPhone 6 announcement. Well, guess what? Five months later we’ve got a new vulnerability with an equally awesome name. Meet "Shellshock" - an awesome bug with the potential to be a as big as Heartbleed. Today, I wanted to put together something definitive, both for me to come to grips with the situation, and for others to separate the hype from the true underlying risk.

What Is Bash and Why Do We Need It?

Let’s start at the beginning. Bash is a *nix shell or in other words, an interpreter that allows you to orchestrate commands on Unix and Linux systems, typically by connecting over SSH. It’s been around since the late 80s where it evolved from earlier shell implementations (the name is derived from the Bourne shell) and is enormously popular. There are other shells out there for Unix variants, but the thing about Bash however is that it’s the default shell for Linux and Mac OS X, which are obviously extremely prevalent operating systems.

What Is the Vulnerability?

The flaw involves how Bash evaluates environment variables. With specifically crafted variables, a hacker could use this hole to execute shell commands. A good example could be an application calling a Bash shell command via web HTTP or a Common-Gateway Interface (CGI) in a way that allows a user to insert data using this vulnerability. The most dangerous circumstance is if your application calls scripts with super-user, aka root, permissions. In this case, your attacker could get away with "murder" on your server.

Are You Exposed?

You are probably asking yourself, "If I am not running Linux/Unix/Mac, am I exposed?" Short answer "no" and long answer "yes". I'll tackle the easy one first – Bash is not found natively on Windows and whilst there are Bash implementations for Windows, it's certainly not common and it's not going to be found on consumer PCs. It's also not clear if products like win-bash are actually vulnerable to Shellshock in the first place. The longer answer is that just because you operate in a predominantly Microsoft-centric environment doesn't mean that you don't have Bash running on machines servicing other discrete purposes within that environment.

So What Should You Do?

Firstly, discovering if you’re at risk is trivial as it’s such an easily reproducible risk. There’s a very simple test — simply run this command within your shell: env X="() { :;} ; echo busted" /bin/sh -c "echo stuff" If you get “busted” echoed back out, you’ve exploited the bug and are vulnerable. Of course the priority here is going to be patching systems. Linux distros, such as Red Hat are releasing guidance on patching the risk, so jump on that as a matter of priority!

Are You a SysAid Cloud Customer?

As always, those using SysAid Cloud services can continue sleeping quietly at night knowing we already did all the necessary patching to make sure our systems are not exposed to Shellshock. Image credit

Like this article? You may also like: CVE-2014-0160.

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Defining Metrics for Incident Management

Posted by on September 23, 2014 in ITIL
Defining Metrics for Incident Management I have written about how to define metrics and KPIs for IT service management processes before. In Defining Metrics for Change Management I discussed the importance of identifying stakeholders, and defining CSFs and then using these to help you think about what KPIs you should measure and report. In Defining Metrics for Problem Management I continued this theme, and showed how the KPIs that you find in best practice publications like ITIL may not be suitable for your needs. In response to these earlier blogs, I received some requests for more blogs in the series, and in particular a request for guidance on metrics for incident management. So here are my thoughts on how you can define metrics for incident management…
The first question to ask is what is incident management for? What are you trying to achieve? This won’t be the same for everyone, but most organizations will want something like:
  • We resolve incidents quickly, so they don’t have a significant impact on our customers
  • We prioritize incidents appropriately, based on their impact and urgency
  • We communicate well so that customers and users understand what is happening and when they can expect their incidents to be resolved
  • Customers and users are satisfied with the way we handle their incidents
  • We recognize repeating incidents and log problems to help reduce future business impact
  • We make efficient use of our incident management resources
Ideally our KPIs should help us to understand whether we are achieving these goals, and should provide trends to help us focus on where we need to improve. So let’s think about what we could measure to help with these. Please remember that these are all just examples, based on how I think about incident management. Some KPIs will be appropriate for one organization and completely inappropriate for another. For example some organizations measure the First Call Resolution (FCR) rate. This is a measure of what percentage of calls were resolved during the initial phone call with the service desk. For many organizations this is a great way of measuring that they resolved incidents quickly and made efficient use of resources, but if you are investing in self-service tools then you may find that FCR gets worse, even though the service is improving. Here are some examples of KPIs that might help you to understand how well you are doing against the goals listed above. In each case I have indicated the metric, but not provided a target, as this will be completely dependent on your environment. You may need to collect data for a while before you can set targets for any of these metrics.
  • We resolve incidents quickly, so they don’t have a significant impact on our customers
    • Percentage of Priority 1 incidents resolved within SLA agreed target
    • Percentage of Priority 2 incidents resolved within SLA agreed target
    • Percentage of Priority 3 incidents resolved within SLA agreed target
  • We prioritize incidents appropriately, based on their impact and urgency
    • Number of incidents where the priority was changed after logging
    • Number of customer complaints or escalations due to disagreement over incident priority
  • We communicate well so that customers and users understand what is happening and when they can expect their incidents to be resolved
    • Percentage of incidents where customer contacted the service desk to ask for an update
  • Customers and users are satisfied with the way we handle their incidents
    • Percentage of users giving a score of 4 or 5 on post-incident satisfaction survey
    • Increased satisfaction with incident management on annual customer satisfaction survey
  • We recognize repeating incidents and log problems to help reduce future business impact
    • Number of problems logged by the service desk
    • Number of problems identified by analysis of incident data
  • We make efficient use of our incident management resources
    • Percentage of incidents logged via self-service
    • Percentage of incidents solved by self-service
    • Average cost to resolve incident (by priority)
Remember these are all just examples. It really doesn’t take long to write down your own goals, and then to think about what you could measure to help you achieve them. What are your current incident management KPIs based on? Do they help you understand how well you are doing for your customers, or are many of them just internally focussed? Why not sit down and review them and see if you can start measuring and reporting the things that really matter to you?

Like this article? You may also like: Defining Metrics for Problem Management.

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

ITSM: Shift Left, Left, Left…

Posted by on September 17, 2014 in Service Desk
Consider the concept of shift left in ITSM When looking at ways to improve your IT support and service desk, it’s always useful to take a look at what managed service providers (MSPs) are doing, since their entire business is based on successful and efficient service delivery – so they will always have some good ideas to consider.

The shift left concept

One of the most prevalent of these ideas over recent years has been the concept of shift left – which means moving the activity of providing resolution support as close to the front line and customer as possible. The concept is simple. By moving the capability and delivery of resolution work to the immediate front line, this reduces waiting time for customers, simplifies support activity and (important for outsourcers) reduces the actual cost of dealing with the incident. So, an incident fixed at the front line might cost $10, whereas the cost rises steeply for 2nd and 3rd level support to $100/$300, due to the increased numbers of staff involved, their costs, the cost of extended user downtime, etc. For many organizations, at a very basic level this is the prime activity that they might look at, in terms of service modeling, i.e. how they define the sort of service and service levels that are provided by their support structure. There are also often questions raised about the value of this approach, notably with the development of self-service and crowdsourcing in recent years, particularly as the models and norms of IT Support and IT service management (ITSM) are constantly being challenged. However, in general, the concept is a good and valuable one as it provides several highly desirable benefits, for both short and long-term gain, examples of which I will discuss below.

Speeding up resolution time for users, thereby improving the customer experience

We all know that if you can fix an issue on the first call this greatly improves customer satisfaction. No one likes being passed around or having to wait, then chase, then wait again. The old ‘Helpdesk’ model of ‘log and refer’ wasn’t usually supported by slick escalation processes and a culture of collaboration, so often incidents were delayed not because the IT organization couldn’t fix them, but simply because IT wasn’t organized into a service model that worked to achieve the quickest possible resolution for the customer or business. This is clearly a poor level of business support (where business performance is impacted by chaotic or incompetent IT management) and has led to a focus on pushing resolution competence and capability to the front line. The key element here is unproductive user time, not just bad experience. If customers are unable to work, this is punishing the very business that the IT organization is there to support. So, the faster the resolution time, the less productive downtime for the customer. This should be simple and obvious, however many IT people and organizations have resisted this over the years based on fear, prejudice, and ignorance – fear of losing their technical power, prejudice against ‘lower level’ technical people on service desks, and ignorance of the impact of their views and actions.

Simplifying the escalation and support processes, essentially cutting out waste and hassle

In simple terms, the whole process of escalationacceptance/rejection, updating, chasing, resolving, closing, and QA – is a painful one. So if this is reduced to a minimum, it also reduces friction between teams and reduces the time spent or wasted chasing updates, negotiating on priorities, etc. This in itself is a cost and efficiency saving but also allows re-focussing on high value work, for all concerned at different levels in the support model. Once in place, shift left removes a level of attrition, waste, and inefficiency that benefits both provider and customer alike.

Cost reduction

Basically it’s cheaper.There is a general consensus of agreement on this, since the figures have been around for some time from Gartner, for example, which show the cost of resolution increasing across 1st to 3rd levels of support in an IT organization. Of course nowadays there is also self-help and self-service, which is the ‘zero level’ and which is even cheaper that human 1st level support. So to return to the initial point, this is where MSPs can achieve value – their focus is of course on saving costs but in reality (unless this is done very poorly), using the shift left process will result in an improvement in speed of resolution, customer experience, and simplicity in operation too.

Overall shift left shows a commitment to service and customer experience – or at least it should!

It certainly provides the framework that would deliver better and faster resolution of issues and therefore reduction in downtime.

What if it’s just done only for cost saving?

Of course the customer experience may still need to be reviewed and improved, e.g. if the analysts/agents do not provide good customer care, etc. However there is still a focus with this on reducing the interruptions and inconveniences to the customer.

What are the implications of shift left? What do we need to do for success?

Traditional retained IT organizations have often struggled to come to terms with the real implications of shifting left. As mentioned above, this can be due to misplaced fears and uncertainties, as well as politics and empire building. True quality customer service and customer experience needs these barriers to be removed in order to achieve a consolidated and seamless service ‘supply chain’ and collaborative workforce.

Key pointers to removing barriers

  • Continual Service Improvement can be a strong driver; customer feedback and priority can be even stronger. There’s a need to document and prioritise key internal service improvements but also set these in the light of what customers say they want and need to do their jobs effectively. Customer feedback must be the most powerful mandate for action and this can trump any technical teams’ objections to change.
  • Knowledge management and its level of maturity in the organisation is a key factor in getting information, expertise and practical solutions documented and shared across teams.
  • It can be helpful to start setting targets for numbers of incidents that are passed over from technical teams to the front line, e.g. monthly targets. It’s also useful to have some simple pre-forms (as part of the knowledge approach) for handing these over.
The greatest challenge often is around changing the mindset that can’t allow service desk/front line teams to carry out apparently difficult/technical/high risk functions (those that need to be done by experienced people). That’s missing the point. If the business need is to get the issues resolved more quickly than can be practically done by escalation, then the model needs to change, i.e. the structure, staffing, and skills of the service desk. So they need to be trained, or re-hired. That’s the extreme end of the scale and in most cases, once the argument has been won, it’s a matter of simply delivering good knowledge management, staff training, and ongoing governance and management.

But remember, shift left doesn’t always work

Finally, shift left doesn’t work for every situation and should be considered in context of business need and priority. Some emergency/critical services simply need a log and triage approach. It should however always be considered as a valuable customer experience option and used as a de facto approach, rather than the other way round. Image credit

Like this article? You may also like: If We Could Just Talk to Our Customers.

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Evolution and How to Keep IT from Going Extinct

Posted by on September 9, 2014 in Cloud
ITSM Evolution and How to Keep IT from Going Extinct When I hear about Shadow IT and comments that the IT department will soon be dead, here are a few ITSM panicking thoughts I've heard so far:
  • Cloud computing is destroying the data center.
  • IT as we know it is going away.
  • Save yourself and change careers now! Perhaps an exciting job in exotic bird grooming?
Now that the panic is over, I want to reiterate what I’ve stated many times beforeIT service management (ITSM) will never go away. After all, a service can have several means to deliver value. As long as expected outcomes are being produced with little to no risk, it doesn’t matter if the technology is in a private datacenter or being hosted by Amazon. With that in mind, here’s a survival guide on how not only to survive, but what to do to excel in the new way of IT.

Survival Guide

  1. Think services: It's important for everyone in an IT group to understand that technology is nothing more than the tools used to deploy services in order to create value. Since the strategic value proposition will be the future role of IT, the next step is key to success.
  2. Map business outcomes to services: I once heard a brilliant idea from Mark Kawasaki, an ITSM practitioner at Emory University – “map business outcomes to the Configuration Management Database (CMDB)”. In other words, when you design a solution, understand how it will produce value for business processes.
  3. Build the service maps: Along with understanding expected business outcomes, service management focuses on the business getting value. The CMDB was a valiant attempt at managing technology, but its importance has been falling by the roadside as cloud computing has reduced the need to focus on technology. While a service map may include items that overlap with a CMDB, it should also expand beyond the scope of technology to include all elements, and their relationships, of a service.
  4. Stop Shadow IT: Shadow IT is similar to a warning light on a car’s dashboard - it indicates customers are finding technology solutions without the IT department. Several articles and blog posts have already been written on the topic, so to save time I’ll only state that it exists and is prevalent where customers aren’t being provided the solutions they want by IT. As a result, users are looking outside of the IT department to find their solutions.
  5. Take on Business Relationship Management (BRM): Everyone will agree it’s important for IT to understand the business, so it’s obvious why BRM made its way into ITIL 2011® as a formal process, but it may not be obvious why the understanding will be key in future IT operations. If IT is to move from being only a technology provider to being that of strategic partner, understanding market trends and business operations will help give insight as to how emerging technologies can give a business an advantage over competition.
If you noticed, I didn’t specifically list anything related to ITIL®, DevOps, or any other methods or frameworks for operations or development. The reason is that there’s no perfect way to run all IT departments. Depending on size, culture, industry, and several other factors that I may not even be aware of, each organization will have to evolve at its own pace and with the methods best fitting to maximize efficiency. The only guarantee is that technology is in a state of constant flux and IT will have to be the strategic advisor for how a business can take advantage of these changes and keep relevant in the market.

An Opportunity to Learn More

I'm not the only one that thinks ITSM is here to stay: “Service management is not only relevant, it’s more relevant than it’s ever been” - Glenn O’Donnell, Vice President and Research Director at Forrester Research. In our upcoming webinar we will be discussing with Glenn how the role of ITSM is changing. We’ll be talking about its strategic value proposition, as well as the role that cloud technology has to play in the future of ITSM. Discover what will likely become of ITIL, DevOps and Shadow IT, as the speed in which IT and business landscape further increases. Join Glenn and I on September 16th at 12pm EDT to learn how ITSM will evolve and how to keep your IT organization from becoming extinct. Register now. After the webinar, all attendees will also receive a short report with the 20 Top Tips for Addressing the Future of ITSM. Image credit

Like this article? You may also like: The Cloud Behind the Curtain - Why ITSM Matters.

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading
Watch & learn from industry experts about ITSM and help desk hot topics!