Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: JHarmon
New Today: 28
New Yesterday: 92
Overall: 141372

People Online:
Visitors: 68
Members: 6
Total: 74 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Is this a problem or not?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Is this a problem or not?

 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
philc
Newbie
Newbie


Joined: Jun 16, 2011
Posts: 2

PostPosted: Thu Jun 16, 2011 7:26 pm    Post subject: Is this a problem or not? Reply with quote

Hi,

We've been experiencing some record locking errors with an application we host internally on our own infrastructure, but have a support contract with a supplier for.

There's no obvious pattern or reason for it and we've already raised the issue with the supplier's support team. In my mind, this seems to be a textbook case for having a problem record - repeated incidents logged for the same issue, therefore requiring root cause analysis. The problem may be ours, it may be the software, we just don't know. I can't see how we distinguish between whose responsibility it is to investigate when we don't know that? And even if it is the supplier's responsibility, don't we want to keep track of this too? We still have the problem, right?

Our Problem Manager, however, says that because we have supplier support for the software it's up to them to do root cause analysis and we can continue to log incidents, just not create a problem record to link them to because we can do no root cause analysis ourselves (but clearly we can examine our infrastructure etc.).

I think this just makes life unnecessarily complicated, but what do you ITIL experts think?

Many thanks!
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Jun 16, 2011 8:29 pm    Post subject: Reply with quote

You must distinguish between managing the problem and solving the problem. Your's (your Problem Manager's) essential responsibility is to manage the problem. Who conducts the technical investigation into the underlying cause(s) - I don't believe in root cause analysis because it is a meaningless phrase - is whoever you (your problem manager) commission to do such work.

In this case it could be internal staff, your third party support organization, a combination of the two [there's that song title again], or first one and then the other according to how things go, who do the investigation.

The key point is that management (and control) remain within your own organization because you own the services - it is your problem.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
Marcel
Senior Itiler


Joined: Sep 21, 2006
Posts: 63
Location: USA

PostPosted: Tue Jun 21, 2011 7:30 am    Post subject: Reply with quote

Fully agreed. Problem Management is about managing all IT problems in your organization, regardless of who 'owns' the problem. You should have a point of contact within your organization who is responsible for keeping the pressure on the external vendor and for keeping the problem record in your system up to date so all stakeholders can remain informed throughout the process.
_________________
Manager of Problem Management
Fortune 100 Company
ITIL Certified
Back to top
View user's profile
philc
Newbie
Newbie


Joined: Jun 16, 2011
Posts: 2

PostPosted: Wed Jun 22, 2011 7:28 pm    Post subject: Reply with quote

Excellent, thanks to you both.
Back to top
View user's profile
mredekar
Itiler


Joined: Dec 30, 2005
Posts: 21
Location: Navi Mumbai, Maharashtra, India

PostPosted: Tue Jul 19, 2011 7:55 pm    Post subject: Reply with quote

Excellent discussion!!

Just to add, if your supplier is not responding with appropriate responsibility of finding timely solution to problems, you may like to discuss the same with supplier and add it to the official agreement with them, next time you amend/renew the agreement.
==
Back to top
View user's profile
elbow
Itiler


Joined: Feb 14, 2011
Posts: 35

PostPosted: Wed Oct 12, 2011 6:06 pm    Post subject: ? Reply with quote

Diarmid...

what exactly do you mean by this?

Quote:
I don't believe in root cause analysis because it is a meaningless phrase
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Oct 13, 2011 1:36 am    Post subject: Reply with quote

Hi elbow,

someone finally took the bait (or the bull by the horns!)

The simplest answer is that there is no point in analysing beyond the level at which we have the capability to fix something.

The "root" (it is possible to go back further yet) cause of a faulty disc may lie in poor quality ore extraction processes, but you are unlikely to take this beyond your immediate supplier with whom you can negotiate warranties of quality - or you can change supplier.

Also, root cause implies one cause. But there are many examples of combinations or accumulations of circumstances being the cause and sometimes you will tackle one of these, but at others you will deal with a whole array. A system I was associated with was poorly performing and, fed up with sticking plaster solutions, I called in an expert. He identified 17 (!) ways to improve the performance and we implemented most of them. However we did not tackle the underlying cause at that time because it was the nature of the system design and we could not afford to replace the entire system any time soon.

I think the reason that ITIL introduced the term "root cause" was to emphasise that with complex systems (such as a mainframe as it was at that time or a network of interrelated systems) it was important to dig deeper than the superficially apparent cause which was often little more than a symptom. It is still important to do this, but many problems do not lend themselves to anything that could meaningfully be called "root cause analysis".

This is particularly true where the cause is related to people rather than system components. There is not a lot of deep technical analysis to recognize inadequate documentation or a lack of training or even poorly designed procedures as the relevant cause of some problems.

Therefore I prefer the term underlying cause(s) to emphasise a more than superficial approach, but not to exaggerate what is actually required.

Hope this helps. I've rushed it a bit, but I have gone over it a couple of times before either here or at LinkedIn.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.