Tuesday, 25 February 2014

Reporting and the Service Management Plateau

The problem with reporting is that quite often we think of it AFTER we are providing a service. We may speak to what the service can do in terms of expectations (SLA, SLR or OLA) beforehand, however the nuts and bolts of how the service is “doing” hasn’t really be thought out in detail. This may lead to some reporting inaccuracies which are their own challenge.
The title of this blog speaks of the service management plateau, by this I am referring to the way that we continue to manage our services, day in and day out, for the most part as effectively as we planned. The challenge is that when we want to take service to the next level we seem to hit an invisible barrier, or there are areas for improvement that seem just past our grasp. The reason for this is not that we are not doing the right things; one of the reasons is that we are continuing to look at this from the same perspectives month after month. The invisible barrier is the things that we didn’t take into account when we look at our current service challenges. One of these is the way we report on the service we provide.
The first inclination is to start gathering information in vast quantities so that we can make better decisions and identify where we can make some improvements, the more information we have the better right? Well, in my opinion while being able to pull information is great if we are not doing anything with it we are no better off that we were before we started collecting volumes of information.
One of the other challenges with reporting is that it has to actually reflect the customer experience. This is why starting simple and validating the data with those that it actually impacts is so important. For example let’s assume we start with the number of service outages (critical incidents) and their duration. In our initial reports it looks as though the service has been available 100% for the past 2 months, no critical incidents and no outages. Now we need to present this information to our customers and validate the accuracy, depending on the organization this may already be happening but if it’s not, starting a good dialog on how to improve service delivery is important.
After meeting with our business they tell us a different tale about their service altogether. From their perspective the service has been unavailable every Tuesday morning for 10 to15 minutes. The business continues to outline that they have seen this issue before, and generally it goes away after a few moments so they haven’t escalated it for the past couple of months. Which correlate to the fact that that there have been no reported critical incidents….
This breakdown in process is a problem. The dialog which has now been generated, however, has given us a unique opportunity to enable improvements in many areas. It will now allow us to find areas for escalation improvement within the incident process, it will allow us to tailor the way we look at our infrastructure for this service through monitoring, it will help us to determine how problem management could get involved to assist in root cause diagnosis for these Tuesday outages.
It is in these small steps that we can continue to make improvements and then discuss them with those who matter most – the business.

Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn


Wednesday, 19 February 2014

My #TFT14 Experience

The first time I experienced TFT (Tomorrows Future Today) was back in June 2012. I could identify with it immediately, not only was the content free but it was crowdsourced. This took care of the two things that I always had challenges with in physical conferences:
1.    Being able to afford it (both in cost and time when my employer valued both…)
2.    Seeing quality content at said conference. I would only get to choose what I could see depending on availability

So in 2012 I tuned into TFT12 and  I was able to see a few of the presenters “live” and was able to view the rest of the content at my convenience after the fact.

The following year in June 2013 I again consumed the TFT13 experience. It was after which that I decided that when it came around again that I would get out of the “cheap seats” and build a presentation of my own. The value in doing this is different for every presenter. For me it was about being a part of something larger than myself. It was “putting it out there” for right or wrong and getting some feedback on the content I would present. There is risk in doing this for some people they are worried that after all the effort is put in that it will be met with criticism. I have found that more often I learned more from doing things the wrong way rather than having everything go right.

In the fall of 2013 there was a request for presenters for a 2 part TFT online conference. The first 24 hours was slated for February while the second for June. I knew that I needed to be a part of this and submitted my presentation “What the Hell is IT Doing?” which was a look at some lesser utilized process which would improve the customer experience.

Only recently in the past year had I started to present content in a physical capacity. Initially I believed that the online presentation format would take away that “nervousness” of public speaking and might be easier to manage that presenting in front of others. I had my presentation finished more or less the way I wanted (never fully satisfied) on the morning of TFT and the countdown to present was on. After delivering my content I was surprised at how I felt it went, the best way I can explain the difference in presenting online vs. in person was similar to what people who perform live theater and film explain as their ability to connect with the audience. Aside from the questions I received at the end I did not directly interact with anyone. I had decided not to look at any social media streams during the presentation so that I could keep on track. The other major difference was the timing of the content delivery. When delivering content in person, I found that 45 minutes might be tight, however for my presentation I went through the content faster than I had thought I might (there’s that learning curve again)

When it was all done I was able to sit back and enjoy the other presenters once again. The nice thing that even with other events being held simotaneously on the same date the TFT content was recorded and will be available in a multitude of formats for consumption down the road.  I look forward seeing the next group of presentations in June, you can vote for them here

A huge thank you to all those who made this event possible:

·         +Chris Dancy the founder/creator of TFT,
·         The team from the Brighttalk,
·         The sponsors Cherwell Software CA Technologies and BMC
·         +Zoe James (who really pulled it all together) to logistically keep the cats herded
·         And the other presenters for broadening our horizons

I thank you for this opportunity and would gladly do this again

Tuesday, 11 February 2014

Service Level Management – The Gap between Delivery and Expectation

At some point in the delivery of service to your customers the formalization of a service agreement has either been implemented or in other cases may have only been discussed. In either case identifying what makes the service function is going to be paramount in order to identify and eliminate gaps in the ability to deliver a consistent customer experience.

The customer you support operates through processes which in one way or another are reliant on IT services. Effectively the SLA is the clarity for the customer deliverables. Think of this in these terms, your service is supported by something. Take this diagram for example, even if you remove one or two columns you still might be able to support the service but inevitably at some point there won’t be enough support to keep the thing from falling over. From an IT perspective we need to know what all the ‘columns’ are.

As an IT unit we now understand what is making this service work, for the most part. The next question we have to ask ourselves is how well is the service operating?

Think about the level of reporting your IT organization currently leverages. Does it report on the service as a whole or the underlying components of the service. Before I get too far ahead of myself while thinking about the output as a service is important we must not forget to remember that there are pieces which make it operate. This also includes understanding how our OLA’s and any underpinning contracts (UC) work to support them as well where they exist. We should be able to report on our ability to provide this service weekly. This way should there be something which might impact the delivery of service we are in a position to respond quickly to address any concerns. If these don't exist in a formal way they are likely being done via best effort and should be documented to review for improvements from a consistency perspective down the line.

Customer satisfaction can be a tricky thing to gage, so the next part will require good dialog with your customer.

Some might say that satisfaction is in the mind of the beholder. A potential gap may exist when we (IT) report against what we think services are doing and what the customers experience truly is.  In some cases the gap is larger than we originally thought. For example we showed that there was no outage at site x last month but in reality there were several outages that were never reported. This is where good discussion with the customers allows your Service Level Manager, or someone accountable to that role to ensure that we are reviewing the way we provide this service. While our customer may not need to know how we provide service we need to be able to better understand the challenges that face our customers so we can address them and work towards providing a consistent customer experience.

Follow me on Twitter @ryanrogilvie