Ken Turbitt Blog
Aidan Lawes Blog
Paul Gostick Blog
Dr Jenny Dugmore Blog
Shirley Lacy Blog
Alim Ozcan Blog
Juan Jimenez Blog
Ian Clayton Blog
Nas Ozcan Blog
Aidan Mills Blog

The General Data Protection Regulation Benchmarking Survey
How are organisations facing the challenge of complying with the most radical overhaul of data protection laws in a generation?...

Ten Strategic Technology Trends for Government
Technologies that enable new service models for digital government must be at the top of the list for government organizations as they prioritize technology investments...


The Robots are Coming: Are CEOs Ready for the Era of Automation?
CEOs agree that robotics is going to make their companies more efficient, with 94% of those who've already adopted robotics saying that it's increased productivity in their business...


The 2015 Chief Digital Officer Study
More companies are appointing a Chief Digital Officer to join their C-suite - but are they doing it quickly enough?...


18th Annual Global CEO Survey
The United States has overtaken China as top target for growth for the first time in five years...

4 July 2013 | Ken Turbitt Blog
Send to a colleague | Add to MY ITP

Focus on the Root Cause as Well as the Incident
This week Ken explains why it's important for root cause analysis in addition to addressing an incident...

  Ken Turbitt

Too many times I’ve talked to both clients and service providers and discovered that they are not focused on the root cause, and simply deal with the symptoms. I’m sure you would agree if you are suffering from pain perhaps internally, and the Doctor prescribed only painkillers to keep you up and moving, you would be initially happy until things got worse. You could carry on that way for quite some time, until eventually your appendix burst and then there is a real life-threatening emergency to deal with. Now had the Doctor carried out a full root cause analysis to start with and determined that it was appendicitis he could have used a known error record or knowledge to deal with the problem before it became life-threatening.

All too often I see service desks simply taking each Incident as it comes in and dealing with the initial symptoms with pain killers and rarely progressing it into problem management to  investigate the Root Cause for full eradication of the problem. Many don’t elect these answers into the Known Error Database (KEDB) or Knowledge Base (KB) and so end up re-solving the same problem over and over again, wasting time, resources and effort. Just imagine if Doctors and Surgeons did not share their solutions with others in each region, area and practice and they had to re-discover the solution for themselves!

Even clients tend to focus on measure the wrong thing. Many set up contracts with their suppliers to measure the reduction in time spent on resolving incidents, and the number of incidents. This is fine, if at the same time they measure and correlate this with the number of linked problems raised and resolved. Without this you find that the supplier and agent are simply focused on issuing pain killers to all as quickly as possible. How many measure solved problems that are migrated into the KEDB or KB? How often is the KB utilized in Incident management to permanently resolve them, preventing more being raised in the future? How many solved Problems are progressed into Change Management to enable preventative medication and prevent Incidents in the first place?

I mentioned before that I’m working with a client on Service Request Management (SRM) in a Multi-supplier environment, and I still fail to see proper integration into Incident and Problem management to handle SRM exceptions. Many tell me that Incident management is not meant to handle Service Request exceptions! Is the Service Desk not there to deal with all Services, including Service Requests?

Let’s suppose a supplier keeps rejecting the approved service request because they do not have all the information necessary to complete the request. If this exception gets recorded as an Incident (as it’s impacting the requestor with a delay or failure in the service) then the agent can investigate the cause. Yes, they can obtain the information from the requestor, fill in the details and then re-send the request to the supplier. However this is only dealing with the immediate pain.

Root cause analysis would highlight that the SRM form of that item needs changing to either have a mandatory field added, better integration with master data or pull down choice lists etc. So that when this root cause is determined, a change is raised and the system improved, we then find none or a few rejections from the suppliers.  I could go on, with more examples, but I’m sure you get the point. Yes, we need to address the immediate pain, but we also must investigate the root cause and make every effort to prevent something more critical.

Any feedback and comments are always welcome!


Ken Turbitt Email to a colleague | Add to MY ITP

terms & conditions