Monday, 23 September 2013

Reporting Accuracy – Greater Than or Less Than


Nothing is more frustrating than publishing your metrics only to find that there are some inconsistencies in the values you have reported on. You may ask how that is even possible but it happens more often than some would like to admit.



Firstly, let me tell you, while you may feel only a few apples tall these erroneous numbers should have at the very least taught you a few things:

  1. There may be a process gap that is contributing to your metrics in some way
  2. That the vehicle for reporting has some “issues” that need to be addressed
  3. That you simply are not reporting the right “things”
  4. That there is a disconnect between you and your customer

To describe in some detail what I am talking about I will run through each in a little detail.

Process gaps

Let us suppose that you are reporting against the number of escalated critical incidents to your support teams. In a given month you run the report against all Priority 1 incidents created. Since these are always escalated this should be pretty simple right? After publishing the values your operations manager indicates that while the numbers for the most part look sound, the number of escalations to the database group looks to be only in half of what they should be. Puzzled you rerun the numbers and get the same results. You contact the Database Manager to see if she can shed some light on the situation. “Where are the automated alerts?” she asks. What we forgot was that our ticketing system also creates Incidents based on up/down traps from our database event management tool. The system automatically generates the alerts if a database appears to have lost connection for “x” period of time. The difference is that until reviewed the priority always remains as a priority 3 (moderate). This is why these never shown up in the reports. The process was to reprioritize all escalated events to Priority 1 should they need to be addressed.  Having found that we also need to ask:

  • Do we want to report against all escalations despite priority
  • Does our database team need to better understand the process for reassigning priority
  • Is our event management system trapping up/down correctly
  • Does that system need to be evaluated for information alerts as well

Reporting Issues
Not all systems are created the same. Suppose you want to run a report against all network outages for the customer last month. There is even a nicely “canned’ report which handles this. When you run the report it indicates that there was a 2 hour downtime that was the result of a hardware failure. Despite this your leadership team indicates that there was also a large outage at the beginning of the month, they are asking where this statistic is. Taking a closer look at your report, while it looks sound you see that it reports against the start time of last month. The large network outage that they are referring to started technically on the last day of the month previous. This is why you did not see it in your uptime report. This will need to be adjusted for the next time you run the report.

The Right Things
There are also times where the reports you run are correct but the audience just simply wants something else. For example you may have run a report which outlines the duration of Service Requests for a given period. Your audience however, while interested in the total duration, is more concerned with the time allotted to each team. You may need to revise the report to reflect these particular needs.

Customer Disconnect

You publish the monthly report for your customers which show that application “Y” had an uptime of 99.98% last month. The feedback that you received on this was that these numbers are greater than they should be. “We had several small but significant outages last month”, they indicate. After going back, the numbers look to be right, there appear to be no process gaps, reporting issues and the right things are in there. Even a discussion with your Service Desk manager seems to agree with the stats. However further discussion with your Problem Manager, and a customer stakeholder indicates that there is a consistent login problem with the application and that these issues may not always get escalated and in turn are not being tracked. This is why your numbers don’t match up to your customer’s experience. A discussion with the Problem Management, Service Desk, and the Business Relationship Manager helps to facilitate the need for escalations for these issues, even when they seem small.


Overall getting the discussion going on these reporting issues allows you to continuously improve not only what is reported, but gives insight into various processes and discussions with stakeholders to improve the quality of service you provide.



  
Feel free to connect with me on Twitter @ryanrogilvie and/or on LinkedIn
 
If you like these articles please take a few minutes to share on social media or comment
 
 

Monday, 16 September 2013

Baking Up IT Services - Swedish Chef Style


The ability to support your customer’s business outcomes will inevitably come back to a discussion on the services they consume and the way they are provided and supported by IT. Pause for a moment and think about what that means from a business perspective, rather than an IT one.

The business expects a certain consistency of #service. They don’t know, or frankly care how you make things work, only that they are up and running. Your challenge is to ensure that we have all the pieces in place to provide that service expectation. Whether you have formal processes to ensure this is happening or not you need to ensure that you cover off a few things to get the ball rolling

What is the service?
Ask 10 people and you could likely get 10 slightly different answers. This activity can be complicated, so having some strategy regarding your scope for this undertaking is important.

The requirements for a service should underpin a business outcome. In fact in the actual service record (however you track it) there should be a field that clearly indicates what that is.

Now that we have identified what a service is, by definition. We need to know what OUR services are. Using the scope we have outlined earlier should guide us to decide the level of granularity that we use for consideration. Remember it’s not about IT, it’s about the customer

Example

Since all customers are not the same for example purposes I will generalize a little here. As we are starting out, we need to keep our scope simple and because our customer base is also small we may “know” what applications that they leverage across the enterprise each day. As a result we may want to use well known applications as our services. The cautionary tale here is to not assume too much – remember it’s about the business outcomes, so discussing this with the business is imperative. We can always adjust these services later – watch for scope creep

In keeping with the title of this post let’s assume that the key application our customers need is called “B.O.R.K” or Business Operations with Registered Knowledge. This application is used Monday to Friday from 8am to 6pm and is only used in the city for the corporate office. There are 50 people at any given time who need to leverage the tool and we have identified the backend systems which make it tick. This supports our business to be able to track all of their customer’s payments. This in turn impacts our businesses bottom line for billing, or MAKING MONEY.

We have verified the details of the service record with the business, remember they may not care that we have a SQL database, an app server and a web server in the background. But they do care that the tool works. All of your IT functions should understand on some level what the service means to the customer and that we are positioned to support it accordingly

Establishing a notion of service culture across your IT organization rather than an “us vs. them” will go a long way to assist in the support of the established services

These records will in turn drive the way that you manage incidents, implement changes and fulfill requests in some way or another. It allows your IT teams to be able to more appropriately prioritize your customers work

Now that you have this information put together we need to maintain the accuracy of the service record. Who owns that component? Again there are no easy answers here and no right or wrong with the exception that someone or something (process) must ensure that we keep on top of the accuracy of the information we so painstakingly collected. We also need a way to ensure that we review with the business the service we have on record. Whatever B.O.R.K might be used for today may have different business requirements in 6 months and the way we deliver and support the application should be scalable as well. You could even tie in these reviews with your annual Operation budget activities. This could come in handy in the event you need to allocate resourcing to the services which you are providing.

Overall you need to start small and think a bit ahead of where your service roadmap will need to go.
Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn

If you like these articles please take a few minutes to share on social media or comment


Monday, 9 September 2013

Request Fulfilment - How Good Are You?

Since one of the key goals of Service Management is to ensure the customer has exceptional customer service, we need to make sure that the way we provide services through request fulfilment is top shelf.

You may be thinking to yourself right now where your teams excel and where they falter in regards to providing that service through your service desk. The question is how accurate are those assumptions? While you may have metrics that show how well you are doing, do you really have a good grasp on how well you provide service?

For the most part, generally speaking, we are talking about the speed of service delivery and the quality of the service provided. So I will talk about those.

Speed

Increasingly as time goes on there will be an increased expectation the rate at which we deliver services. What was good last year may not be good now. Let’s assume that you have been providing service to your customers the same way for many years without complaint. While you believe the rate at which you provide this service is acceptable, without quantifying it you may be doing you and your customers a disservice over a period of time.

Think about it in these terms, many studies indicate that customers want their requests completed, questions answered and problems solved as quickly as possible. In the past a 24 hour turnaround may have been acceptable, now as many as one third of modern consumers (those who utilize Twitter and Facebook) want action in some form in 4 hours or less. In addition customers expect a variety of ways to engage with those who provide services to facilitate this. They are looking for phone, email, and various social media outlets in order to accommodate this. Having some form of self service available will further improve your ability to further ensure the speed at which we are able to respond to customers. In fact many customers now expect it. For example, have knowledge records available for common questions. Also ensure you have automated workflows to account for standard requests.

I mentioned before the rate of service is not the only consideration. The ability to provide top quality service also requires the need for some personal communication. Where the automation ends there will be needs to have someone “walk me through it.”

Quality

Being able to provide a personal touch for your customer requests allows you not only to address what the automation does not but it gives you the opportunity to informally poll your customer base while they you are helping them. Identifying why they are calling may help you to streamline the self service options you currently provide. It will also give you a chance to see what your customers are doing and potentially gaining some insight into their future business needs. Gathering this informal information may help your team to identify areas where you can improve.

Ultimately, despite what your “numbers” say you should regularly be reviewing your ability to provide request fulfilment through as many angles as possible to ensure that your customer experience is an excellent one. The analogy is the frog in the boiling water. If a frog is in a pot warm water and you gradually turn the heat up to the boiling point the frog may not realize until it’s too late. Talk to your customers to continually improve your service.

 

Follow us on Twitter @ryanrogilvie

Tuesday, 3 September 2013

Knowledge Management – Horseshoes and Hand Grenades


As the old saying goes “Close only counts in Horseshoes and Hand Grenades”, so too is the need for accuracy in your good old knowledge locker. As I mentioned in a previous post, WORN - Write Once Read Never, the sky is the limit on the information in which you can retain. However there comes a time when you need to have a policy in which you are able to manage the information that you decide to collect.

Depending on how your organization is set up there may be varying opinions on how and what information should be stored. Sometimes there are inconsistencies from team to team, even within IT on how this data should be managed across the lifecycle.

As an example I will take the launching of a new application for our customers. I will keep this example really simple to illustrate how off the rails this could get.

Our customers wanted an application to manage their beverage refrigerator in the lunchroom. The requirement was to email the office services person when the volumes of the pop(soda) got to a “low level”

From an infrastructure component this was to be managed from “Joes Computer”. Joe sat closest to the lunchroom and since the application required very little overhead this seemed like a good idea.

From a documentation standpoint the inner workings of the application were documented and also stored on Joes Computer.

Over the next few years there were several changes as a result of the needs of the staff with regards to their beverage choices. They no longer wanted soda, and switched it up to juice, diet beverages, and vitamin infused waters. Joe also moved on to another lucrative career at another company. When this happened he did make sure the application and documentation was moved to Chris, who also sat near by.

The documentation which was originally created was never was altered to reflect any of these changes. In addition there were also several issues identified over the time since the application was launched which was also not documented correctly. These defects impacted the way this application worked even if only marginally.

Eventually the office had a fridge full of the pop (soda) it did not want and none of the beverages it needed. What’s wrong with the application?” people asked in the office. Chris, our newly voluntold sysadmin, had no answers. As he went through the documentation to look to make any corrections he noticed that while the information was close it was not entirely accurate. It also showed the last time it was updated – when it was written

This failed mainly because there was no policy to manage this knowledge either manually or automatically. This information would have positioned the support teams to ensure that this application ran smoothly armed with the information to be able to do so.

Overall in this example there was no process to review the documentation and ensure continued accuracy. Think about how your organization manages this application data, is there a formal process or is it more adhoc with best intentions. The end result will determine if you information is close or spot on.

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