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


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: LatashiaDA
New Today: 15
New Yesterday: 37
Overall: 231700

People Online:
Visitors: 114
Members: 0
Total: 114



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

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.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Scope of problems
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Scope of problems

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

Joined: Feb 12, 2007
Posts: 27
Location: Minneapolis, MN, USA

PostPosted: Sat Aug 07, 2010 7:50 am    Post subject: Scope of problems Reply with quote

After a major incident review (which our Problem Management team facilitates), we often find opportunities for the future and document them. Some of these are technical in nature and turned in to problems and actioned (e.g. a known error in current version of driver which needs to be fixed, etc), but some opportunities are staff related. Perhaps the DBA on call that evening lacked the skillset to quickly identify or escalate an issue. My director thinks that problem management should track that issue to closure, because if it is not addressed, it threatens our ability to circumvent future issues and is a threat to the environment. I disagree that PM should track to closure. In my opinion, staffing issues should be docomented in the review, then handed off to the owning team and they should deal with it themselves.

We have good visibility to leadership on problems. Handing off to another team makes people uneasy because that visibility would be diminished if we hand off issues like that. However, I don't believe that these are considered "problems" in the IT/ITIL sense. It comes down to a scope issue.

How do other organizations handle it? Are issues with staffing in or out of scope as a "problem" to be handled by Problem Management?
Back to top
View user's profile
Senior Itiler

Joined: Mar 04, 2008
Posts: 1894
Location: Helensburgh

PostPosted: Sun Aug 08, 2010 7:22 am    Post subject: Reply with quote

For me, its clearly a relevant problem.

I'm not absolutely sure I understand what you mean by "hand off", but perhaps the issue is actually what is meant by "track to closure". Tracking involves making sure the solution gets fully implemented; it does not mean doing any of the work and so there is no issue of breaching scope.

The problem is identified as, say, a training issue (it could be something else, doesn't matter); relevant line and training management are charged with arranging the training. They may know when it is complete, but the problem manager needs to as well, and then the review can be done and the problem closed.

In quality management terms this is ensuring that staff have the necessary skills and knowledge for the work they are required to perform. Raising a problem is not dissimilar to raising a non-conformity and in that case it will come back to the auditor (quality manager) in the end to confirm that the corrective action has been done.

In theory you could leave it for the next audit to pick up, but there is a strong case for more active management so that you know exactly when the risk has been reduced satisfactorily. Hence tracking and review by Problem Management.

Confining PM to "technical" issues was never the ITIL intention and it leaves a gap which your situation illustrates. Any latent risk to service quality is a 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

Joined: Mar 19, 2008
Posts: 29

PostPosted: Wed Aug 25, 2010 6:57 pm    Post subject: Reply with quote

I find "lack of user education" to be the RC of a few Problems, now and then. The same with "IT staff education", actually. This points to two weaknesses in our environment, and both are clearly relevant to PM in both reactive and proactive Problem Mgmt.

Such issues just need to be "de-personalized" (as in "no-blame culture") and then escalated in a different way/to a different body within the organization, compared to tech problems.

HTH /Richard
---------------- bragging line -----------------
V2 Combined Practitioner (service support)
Problem Mgr
Back to top
View user's profile
Senior Itiler

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

PostPosted: Tue Aug 31, 2010 4:51 am    Post subject: Reply with quote

There seem to be lots of IT shops where root cause analysis ends as soon as "the bug in the code" has been identified. And in line with Diarmid and Bluesman, I think that that is a missed opportunity. In our environment one of the common causes behind these technical errors is the lack of proper coding standards (or the lack of enforcement thereof). That is definitely something to track through Problem Mgmt.

Some problems don't have any technical cause at all but come down to people incorrectly handling IT equipment. This too is something for Problem Mgmt to address.

Just think about it. Problem Mgmt aims to prevent/reduce incidents. Nowhere is there an exclusion that says that only technical causes of incidents should be addressed through Problem Mgmt.
Manager of Problem Management
Fortune 100 Company
ITIL Certified
Back to top
View user's profile
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

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.