IT SmartDesk: When Everyone Can Work in IT Support

I recently spoke with Maff Rigby of ITSM start-up IT SmartDesk.

Maff recently presented a session at the itSMF UK conference entitled ‘Social IT – how social media is turning ITSM on its head’. The slides from Maff’s session can be found here.

Facebook Meets IT Support

In a nutshell, during his itSMF session Maff suggested ways in which Social concepts could be used to our advantage in ITSM. These included real time chat and collaboration, using live feeds and activity ‘walls’, harnessing new technology to notify customers or users of issues and using modern collaboration techniques such as wiki’s, crowd sourcing and tagging.

IT SmartDesk is positioned as ‘Social IT Service Management’; using IT SmartDesk I can invite anyone to join me on the system, they can share what they are currently working on, log incidents, ask questions, follow an incident, log bugs and generally join the conversation and collaborate. It’s Facebook meets small IT team support.

IT SmartDesk is aimed at small teams or businesses seeking an online solution, Maff and his team have initially focused on logging incidents and bug tracking – but for me the real key differentiator with this offering is the type of user who can collaborate and provide support.

IT Support for IT Savvy Companies

Traditional ITSM solutions are based on a certain number of IT users who support the larger customer base. E.g. I’ll buy 5 concurrent users for my service desk system to support hundreds or thousands of my customers or users.

IT SmartDesk have turned this model on its head and have priced the system by total number of people logging into the system. They have wisely recognized the market trend that IT support does not have all the answers and many companies are providing support to IT savvy users. With IT SmartDesk anyone in the company can jump in and collaborate. The IT support operator changes from gatekeeper to curator.

The paint has only just dried on this new tool, but from what I have seen so far I found the system to be blindingly obvious to use, easy on the eye, fun to use and clean. Let’s hope they can keep it that way as the feature set expands.

I look forward to keeping track of IT SmartDesk over the coming months.

Further details can be found here > www.itsmartdesk.com

Screenshots below, click to enlarge.

Notifications
Notifications

 

Dashboard
Dashboard

 

Answer Question
Answer Question

Interview: Simon Morris, 'Sneaking ITIL into the Business'

Ignoring the obvious may lead to a nasty mess

I found Simon Morris via his remarkably useful ITIL in 140 app. Simon recently joined ServiceNow from a FTSE100 Advertising, Marketing and Communications group. He was Head of Operations and Engineering and part of a team that lead the Shared Services IT organisation through its transition to IT Service Management process implementation. Here, Simon kindly shares his experiences of ITSM at the rock face.

ITSM Review: You state that prior to your ITSM transformation project you were ‘spending the entire time doing break-fix work and working yourselves into the ground with an ever-increasing cycle of work’. Looking back, can you remember any specific examples of what you were doing, that ITSM resolved?

Simon Morris:

Thinking back I can now see that implementing ITSM gave us the outcomes that we expected from the investment we made in time and money, as well as outcomes that we had no idea would be achieved. Because ITIL is such a wide-ranging framework I think it’s very difficult for organisations to truly appreciate how much is involved at the outset of the project.

We certainly had no idea how much effort would be spent overall on IT Service Management, but we able to identify results early on which encouraged us to keep going. By the time I left the organisation we had multiple people dedicated to the practice, and of course ITSM processes affect all engineering staff on a day-to-day basis.

As soon we finished our ITILv3 training we took the approach of selecting processes that we were already following, and adding layers of maturity to bring them into line with best practice.

I guess at the time we didn’t know it, but we started with Continual Service Improvement – looking at existing processes and identifying improvements. One example that I can recall is Configuration Management – with a very complex Infrastructure we previously had issues in identifying the impact of maintenance work or unplanned outages. The Infrastructure had a high rate of change and it felt impossible to keep a grip on how systems interacted, and depended on each other.

Using Change Management we were able to regulate the rate of change, and keep on top of our Configuration data. Identifying the potential impact of an outage on a system was a process that went from hours down to minutes.

Q. What was the tipping point? How did the ITSM movement gather momentum from something far down the to do list to a strategic initiative? 

If I’m completely honest we had to “sneak it in”! We were under huge pressure to improve the level of professionalism, and to increase the credibility of IT, but constructing the business case for a full ITSM transition was very hard. Especially when you factor in the cost of training, certification, toolsets and the amount of time spent on process improvement. As I said, at the point I left the company we had full time headcount dedicated to ITSM, and getting approval for those additional people at the outset would have been impossible.

We were lucky to have some autonomy over the training budget and found a good partner to get a dozen or so engineers qualified to ITILv3 Foundation level. At that point we had enough momentum, and our influence at departmental head level to make the changes we needed to.

One of the outcomes of our “skunkworks” ITIL transition that we didn’t anticipate at the time was a much better financial appreciation of our IT Services. Before the project we were charging our internal business units on a bespoke rate card that didn’t accurately reflect the costs involved in providing the service. Within a year of the training we had built rate cards that both reflected the true cost of the IT Service, but also included long term planning for capacity.

This really commoditised IT Services such as Storage and Backup and we were able to apportion costs accurately to the business units that consumed the services.

Measuring the cost benefit of ITSM is something that I think the industry needs to do better in order to convince leaders that it’s a sensible business decision – I’m absolutely convinced that the improvements we made to our IT recharge model offset a sizeable portion of our initial costs. Plus we introduced benefits that were much harder to measure in a financial sense such as service uptime, reduced incident resolution times and increased credibility.

Q. How did you measure you were on the right track? What specifically were you measuring? How did you quantify success to the boss? 

Referring back to my point that we started by reviewing existing processes that were immature, and then adding layers to them. We didn’t start out with process metrics, but we added that quite early on.

If I had the opportunity to start this process again I’d definitely start with the question of measurements and metrics. Before we introduced ITSM I don’t think we definitively knew where our problems were, although of course we had a good idea about Incident resolution times and customer satisfaction.

Although it’s tempting to jump straight into process improvement I’d encourage organisations at the start of their ITSM journey to spend time building a baseline of where they are today.

Surveys from your customers and users help to gauge the level of satisfaction before you start to make improvements (Of course, this is a hard measurement to take especially if you’ve never asked your users for honest feedback before, I’ve seen some pretty brutal survey responses in my time J)

Some processes are easier to monitor than others – Incident Management comes to mind, as one that is fairly easy to gather metrics on, Event Management is another.

I would also say that having survived the ITIL Foundation course it’s important to go back into the ITIL literature to research how to measure your processes – it’s a subject that ITIL has some good guidance on with Critical Success Factors (CSFs) and Key Performance Indicators (KPIs).

Q. What would you advise to other companies that are currently stuck in the wrong place, ignoring the dog? (See Simon’s analogy here). Is there anything that you learnt on your journey that you would do differently next time? 

Wow, this is a big question.

Business outcomes

My first thought is that IT organisations should remember that our purpose is to deliver an outcome to the business, and your ITSM deployment should reflect this. In the same way that running IT projects with no clear business benefit, or alignment to an overall strategy is a bad idea – we shouldn’t be implementing ITIL just for the sake of doing it.

For every process that you design or improve, the first question should be “What is the business outcome”, closely followed by “How am I going to prove that I delivered this outcome”. An example for Incident Management would be an outcome of “restoring access to IT services within an agreed timeframe”, so the obvious answer to the second question is “to measure the time to resolution.”

By analysing each process in this way you can get a clearer idea of what types of measurement you should take to:

  • Ensure that the process delivers value and
  • Demonstrate that value.

I actually think that you should start designing the process back-to-front. Identify the outcome, then the method of measurement and then work out what the process should be.

Every time I see an Incident Management form with hundreds of different choices for the category (Hardware, Software, Keyboard, Server etc.) I always wonder if the reporting requirements were ever considered. Or did we just add fields for the sake of it.

Tool maturity

Next I would encourage organisations to consider their process maturity and ITSM toolset maturity as 2 different factors. There is a huge amount of choice in the ITSM suite market at the moment (of course I work for a vendor now, so I’m entitled to have a bias!), but organisations should remember that all of vendors offer a toolset and nothing more.

The tool has to support the process that you design, and it’s far too easy to take a great toolset and implement a lousy process. A year into your transition to ITSM you won’t be able to prove the worth of the time and money spent, and you have the risk of the process being devalued or abandoned.

Having a good process will drive the choice of tool, and design decisions on how that tool is configured. Having the right toolset is huge factor in the chances of a successful transition to ITSM. I’ve lived through experiences with legacy, unwieldy ITSM vendors and it makes the task so much harder.

Participation at every level

One of the best choices we made when we transitioned to ITSM was that we trained a cross-section of engineers across the company. Of the initial group of people to go through ITILv3 Foundation training we had engineers from the Service desk, PC and Mac support, Infrastructure, Service Delivery Managers, Asset management staff and departmental heads.

The result was that we had a core of people who were motivated enough to promote the changes we were making all across the IT department at different levels of seniority. Introducing change, and especially changes that measure the performance of teams and individuals will always induce fear and doubt in some people.

Had we limited the ITIL training to just the management team I don’t think we would have had the same successes. My only regret is that our highest level of IT management managed to swerve the training – I’ll send my old boss the link to this interview to remind him of this!

Find the right pace

A transition to ITSM processes is a marathon, not a sprint so it’s important to find the right tempo for your organisation. Rather than throwing an unsustainable amount of resource at process improvement for a short amount of time I’d advise organisations to recognise that they’ll need to reserve effort on a permanent basis to monitor, measure and improve their services.

ITIL burnout is a very real risk.

 

Simon Morris

My last piece of advice is not to feel that you should implement every process on day one. I can’t think of one approach that would be more prone to failure. I’ve read criticism from ITSM pundits that it’s very rare to find a full ITILv3 implementation in the field. I think that says more about the breadth and depth of the ITIL framework than the failings of companies that implement it.

There’s an adage from the Free Software community – “release early, release often” that is great for ITSM process improvements.

By the time that I left my previous organisation we had iterated through 3 versions of Change Management, each time adding more maturity to the process and making incremental improvements.

I’d recommend reading “ITIL Lite, A road map to full or partial ITIL implementation” by Malcolm Fry. He outlines why ITILv3 might not be fully implemented and the reasons make absolute sense:

  • Cost
  • No customer support
  • Time constraints
  • Ownership
  • Running out of steam

IT Service Management is a cultural change, and it’s worth taking the time to alter peoples working habits gradually over time, rather than exposing them to a huge amount of process change quickly.

Q. Lastly, what do you do at ServiceNow?

I work as a developer in the Application Development Team in Richmond, London. We’re responsible for the ITSM and Business process applications that run on our Cloud platform. On a day-to-day basis this means reviewing our core applications (Incident, Problem, Change, CMDB) and looking for improvements based on customer requirements and best practice.

Obviously the recent ITIL 2011 release is interesting as we work our way through the literature and compare it against our toolset. Recently I’ve also been involved in researching how best to integrate Defect Management into our SCRUM product.

The sign that ServiceNow is growing at an amazing rate (we’re currently the second fastest growing tech company in the US) shows that ITSM is being taken seriously by organisations, and they are investing money to get the returns that a successful transition can offer. These should be encouraging signs to organisations that are starting their journey with ITIL.

@simo_morris
Beer and Speech
Photo Credit

ITSM Vendor Directory V1.0 (itSMF UK Conference Exhibitors)

Web searches for tool vendors has given me a shortlist of over 100 ITSM related vendors (See here and here for a few examples).  However my goal is to present tool vendors in a meaningful and useful format for prospective buyers. The aim is to allow oranges to be truly compared with oranges.

As a starting point I have included software vendors who exhibited at the recent UK itSMF conference. I will add and enrich this grid over time adding more and more vendors as I comprehend them.

V1.0 itSMF UK Conference Exhibitors by Type / Focus

Vendors have been assigned to one of nine pens based on two characteristics; the primary market they serve and the company type. I don’t believe prospective ITSM buyers make decisions based on these criteria, but it allows a prospective buyer with an interest in one vendor to immediately see comparable vendors in that space. For example if I had shown some interest in Axios, I could quickly see companies of a similar ilk.

Market Focus

This is the primary market focus (i.e. not sole focus).

Generally speaking most software vendors will happily sell their software to anyone who wants to part with their cash, but they will typically have a market sweet spot that they focus on. I would be dubious of any company that claims to serve the entire market for every purpose, they are either desperate or naive.

The words ‘SME’, ‘Mid-Market’ and ‘Enterprise’ refer to product characteristics rather than specific numbers of users or company size. After all, each term will have a different meaning depending on where you live on the planet. A large enterprise in Helsinki is an SME in Houston. So for example, you might say that a characteristic of tools aimed at SME companies are typically aimed at high volume with DIY implementation.

Company Type 

  • Conglomerates – Large international brands with divisions that include ITSM tools.
  • Suites – IT Management tool sets which include ITSM tools
  • Specialists – vendors whose sole focus is ITSM.

Finally, I have deliberately avoided the word ‘Cloud’. Over the next few years I see this as being a delivery option rather than key competitive differentiator.

Other Categories

There are other product categories that are outside of scope of this grid which I would like to cover. They include utilities or enablers that are associated with ITSM (e.g. Intel exhibited at itSMF), customer service, general support ticketing tools and systems management tools with ITSM functionality. I also believe there is growing overlap with Social CRM tools.

Your Feedback?

Have these vendors been allocated accurately? what other characteristics would you track? Please share your feedback by leaving a comment. Thanks, Martin