Ron,  thanks for reading…I read your blog regarding quick wins and ITSM  I’m a bit concerned that you left out bubble gum, bailing wire and Velcro (my personal favorites) J Seriously though, in my fifteen plus years Program/Project Management experiences in IT and Service Management and software development, I’ve found the requirement to establish rapid time to value (aka “quick wins”) as simply the “nature of the beast” .  This is not some phenomenon unique to Consultants or IT Service Management… It’s a reality -  based upon straight up, out of the box project management and large program successes mindful of a corporate bottom line requirement for year to year return on investment.It’s a pretty good practice to put a monkey in the capsule & circle the earth a couple of times before you shoot for the moon.  

Of course getting too “quick win”,  schedule pressure focused , can also be illustrated with some not so pleasant space program analogies too.   IMHO, demonstrating measurable value enables you to continue on a much longer and more valuable journey – whether that’s in ITSM, SOA, large software development projects…or a family journey with the kids.    Ok, I’m an idealist at heart, who’s developed some real life scar tissue.   I’ve never seen long programs succeed that didn’t’ demonstrate enough wins to keep the sponsors/executives happy enough to continue the funding year in and year out. 

Simply put, It’s about balance to me.    Of course, like always, your mileage may vary J  Scott M. Davis

Process Consultant

One key metric that Problem and Incident Managers are typically looking at is their incident/problem “backlog”.  Many incident or problem managers may recognize problem/Incident backlog as the average elapsed time to date of “outstanding” problems needing resolution.   In my experience managing global, high volume incident/problem support centers, backlog measurement is a key operational measurement to be institutionalized  - with the awareness that it can provide interesting results.

What I found with this key indicator was that measuring performance based upon average elapsed time & trying to drive that downward can actually incent “bad behavior”.  Say what?  This is a standard ITIL incident/problem management KPI.  How could this be?   In my experience, this measurement, when balanced with customer satisfaction, can produce some interesting areas to improve. What I found in using backlog as a key indicator was that while the age of my backlog was decreasing (good), my customer sat was declining (bad).  What’s the problem here?  Well, what I found was that in addition to lacking the technology to escalate based upon time/severity, I was working with process/kpi’s and a culture which incented our SME’s, first and second line management teams to “manage by the numbers”.   Net/Net:  they were furiously working on older, low priority incidents/problems in order to make the numbers look good.

When I was extolling the virtues of improving aged backlog to a Customer Executive once… he told me…  “numbers never lie… but liars use numbers”.   Put all the numbers in front of me you want… If I did business - like you do business… I’d be out of business” Ouch!

So, by taking another for the team (In ITIL V3 I think scar tissue is mentioned as an underlying part of the continuous improvement process – the check/act part of the Deming method  I think J ), I implemented improved review cycle (process) and measurement (tools) to improve satisfaction. How can you improve the Average aging/backlog KPI?… Pretty Simple:   Start by assigning the following weights to each open problem – giving higher weights based upon severity. Example:

•  Priority 1 - 10 points

• Priority 2 - 5 points

• Priority 3 - 3 points

• Priority 4 - 1 point

 Multiply the weight/points of the problem by the open time/days - then average, trend, slice and dice to your hearts content.  Shazzam!The trends you will see will be a much more accurate view of your performance.  Bad behavior will show itself like a cockroach caught in the open with no cover.  The culture inches forward in the right direction.  Institutionalizing improvements like this with other balanced organizational KPI’s/objectives,  and instilling a cultural “customer first mindset” that focuses on resolving customer-impacting problems faster and you’ll take strides supporting the business outcome that you’re there for.

Keep up the good work!

Scott

Learn more about Incident and Problem Management by downloading our popular white paper on Developing the Business Value of ITIL at the link below: www.evergreensys.com/downloads/businessvalueofitil/ 

So you are scheduled to meet with that really tough customer who has issues with your overall service desk or incident management performance.   My experience in running an incident management organization of over 100k problems per year supporting Fortune 500 customers may help with an approach that almost always facilitated a healthy and productive (although sometimes painful) customer outcome. Key Mantras:  

• Do your homework

• Listen

• Open your Kimono…Commit to improving your customers life

• And do what you say you’ll do.

I was never big on Homework in school, but found the value in real life.  The quote “those who don’t learn from history are doomed to repeat it” fit’s well in these scenarios.  Demonstrating you know your customer is a key ingredient to constructive relationship management and overall service improvement.  Try following these guidelines:

• Drill down in to your standard service desk & incident/problem KPI’s from a customer perspective.  Take a deep dive into the  trend of incidents and problems with that customer, or department/organization in relationship to your overall KPI’s.  What do you see from those trends?   How do you stack up with this customer?  Was the call response timely?   How many incidents did they report per period?  Is that trend higher than normal?  How many are still open and how does that relate to your overall trends?  How long have they aged?   Do any customer specific patterns related to root cause appear obvious that you can learn from or that the customer can learn from. 

• Can you assess whether you are following documented process?   Was each action planned and action taken well documented?   Was relevant diagnostic data needed captured and analyzed in a timely basis?   Were expectations set and followed through with the customer?  Did a high percentage of calls result in some sort of escalation? 

• How was the tone of the incidents & how were our customer care skills?  

• What’s the history regarding service level performance? 

• Is there any funding or revenue dependent upon performance or known issues? 

 While looking at a single customers’ incident management experience doesn’t always offer trends, I always found that a little bit of research always facilitated two key areas of improvement:

1. how can we do better at resolving the incidents faster, more effectively and with customer focus

2. how can we help the customer help themselves (ie training, better diagnostics, expectations, etc…)?    

You can add these approaches to some standard root cause analysis and gain a wealth of insight.  At a minimum,  the customer you are meeting with will certainly understand that you’ve taken time to know him better.

While all this historical self inspection and assessment is good stuff – it doesn’t relieve you of possibly the most important rule of thumb and that is: “listen to your customer”.   My mom used say: “take the cotton out of your ears & put it in your mouth”.  Sometimes I hate it when mom is right.    I’ve found that customer perception and expectations can be managed, only in so far as I understood them.  

 Listening carefully enables me to find out what makes my customer tick, what drives that manager/executive’s success, where their pain is and how my service execution affects their business outcomes.  One lesson I learned this way is that multiple open low priority incidents can equal customer perception of low service value and high business impact.   

Bottom line:  Customer perception trumps service providers interpretation of the facts – add one layer of scar tissue… “thank you, can I have another”.Understanding the facts and listening to the customers viewpoint help open the partnership to a mutually beneficial, open and honest discussion    If a real inventory of your performance and the customer view uncovers  a few “cockroaches” … “it’s all good!   Continuous Improvement is all about exposing those little buggers, finding their food source ( ie.. getting down to the real root causes in your activities,  isolating  work instruction flaws  and/or execution improvement) and then shining the light on the next set of the little buggers (sound like plan do check act?)  Open your Kimono to your customer where it makes sense… It develops trust in the partnership.  Hiding your warts & playing the roach only degrades the relationship and you’ll ultimately lose their faith and honest appraisal (right before they replace you.   As you find real root causes in your area, that causes their pain, be honest and tell them what you found and what you plan to do about it (even if you it means you aren’t going to address it at present).  Invariably though , these scenarios will drive you to constantly improve the activities and work instructions within your incident and problem management process and the honest approach with the customer increases the level of partnership.    

I’m sure none of this is new to may of you…and of course your mileage may vary.  To me,   In the end, It’s all about showing your customer – Big C & little C that you have insight into their world, that you care about their pain are serious about continuously improving and executing a process they depend upon to deliver their business success.

Keep up the good work!

Scott Davis

Evergreen Process Consultant

Learn more by downloading our most popular white paper below:

Developing the Business Value Of ITIL