ITSM Weekly the Podcast (Week11)

WOW what a privelege and a treat this weeks podcast.


Malcolm Fry, "founding father" of ITIL as he is known in the industry was our special guest.



Malcolm's insight and inspiration is truly fantastic, and it was a real treat to have him on the show.  He introduces to us "ITIL Light".  Which to be honest, I thought was going be just a chopped approach to ITIL.  Leave out the meaningful stuff and focus on the easy bits.


Well I was wrong.  (enjoy this comment while it lasts, as I'll be deleting it from history)

His approach seems not only logical, but productive.  Though I still questions the CMS phasing and starting point, it really is something I believe any shop no matter their size or level of maturity can start to undertake.

I look forward to finishing the book and sharing it's value with others.

Show Notes by the man Chris Dancy Here:  http://www.servicesphere.com/blog/2010/4/17/itsm-weekly-the-podcast-week-11.html
Thanks again to Matt Beran for his amazing audio editing.





ITSM Weekly The Podcast (Week 11) from ServiceSphere on Vimeo.

Customers - Are they always right?

So you finally get a chance to look at your customer surveys. Disappointingly after all the coaching and training and process around your service desk, your customers are still complaining.

What's the deal? you say to yourself. "I thought if we put this Service Management process stuff in place customers would be happy, at least that is what Matt told me. Last time I listen to that idiot."

While not taking my advice is many times a good thing, it's not that the processes did not work, its that the implementation was not taking into the most important aspect of Service Management. It's Customer Service Management, not Process Service Management. That means that you have to take into consideration the customer's unique circumstances.

So while Customers are not always "Right", they can be made to feel like they are getting the service they are paying for, by listening to them and acknowledging their intelligence and frustration.

Too many groups are putting in Incident and Request models that are purely focused on the work flow, not the communication. The customers request or incident needs to be resolved, yes, but they also need to feel like they are getting attention individually. Let me share an example with you.

Recently I purchased a VHS to DVD copier. Upon making my 3rd or 4th copy successfully the device stopped reading the VHS tapes. It was snowy on the screen but with clear voice. I called tech support, where upon the technician following his trouble-shooting steps told me that I needed to plug in the "Yellow" jack from the back of the device to my television.

I explained that I was using the Component cables which were Red, Blue and Green and that my TV did not have a "Yellow" Jack to plug into. The technician insisted that the device could not work unless the "Yellow" jack was plugged in. Mind you I had told him several times that I had successfully made copies, and that nothing had changed with my physical connections. Needless to say a horrible experience, and I ended up returning a product that is probably fine because of someone not listening to the customer.

In a different call to my Internet provider Comcast, I had completely the opposite outcome. After troubleshooting why my connection was not working, I finally called Comcast. Now I know it's been a while since I've got my hands dirty with technology, but I still feel pretty comfortable troubleshooting network issues. Upon plugging my laptop directly into the Cable Modem, I realized that the problem was with their Cable Modem. So I called the Comcast tech support. I explained my situation and the steps I had taken. The Comcast rep told me "Can I put you on hold one moment, you clearly have taken some steps to isolate this and let me see if I can pick up where you left off." Literally within 2 minutes the router was up and running and my Internet was back up. He apologized for the inconvenience and then explained to me that they would add my device to their monitoring solution so that they would be notified again should this happen.

Now that is Customer Service.

Next on my hit list of topics: The mother of all Metrics "Service Outage Avoidance" - how this one set of metrics can be the key to your next raise.

SLA's why are they needed?

Service Level Agreements - SLA's. For those who have been able to develop them with metrics that are meaningful and achievable, they love them. For everyone else, they are a nightmare. What makes a good SLA? In my experience, it takes very little to make a good SLA. First, it needs to be understandable. If you don't understand the commitment of service that you need to perform, then the actions you need to take to improve will be a mystery.
For example, if a person at a fast food restaurant was to get measured on the quality of their hamburg, that is good thought, but what does it mean? It's not like they can change the type of beef or bread or other things like that. So rather than just say improve the quality, the manager needs to put in measures that the employee can affect. Time on the shelf less than 10 minutes, bread no older than 5 days, etc...

Those are factors that the employee can watch and adjust, ultimately improving the SLA. Which brings me to the second factor. It has to be measurable. If you can not measure it you can not manage it. If you can not time the hamburger on the table, the age of the bread, you can not determine it's indication of quality.

If you look at the standard SLA's in place that are not on the nightmare side of the house, they are things like 99.999% up-time. If you asked most IT folks what that meant you would get different answers. Some would say the server 99.999% of the time up over the course of a year. Others might say 99.999% would mean that application services are available to all users for no less than 15 minutes in the course of a year.

1 is very measurable, but not of high-value. The other is extremely valuable but difficult to measure.

So when establishing your agreements to the level of service required it is important to determine what you can do and what the business needs. Then negotiate the middle ground. The more the business needs, then the more IT will need to deliver and the higher the cost. Over promising on an SLA that the IT department can not hit does not help anyone. So it is crucial for IT to establish what their capabilities look like. My next blog will be what a Service Catalog is and why it is needed to have true SLA management.