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: StephenGerie
New Today: 3
New Yesterday: 37
Overall: 231688

People Online:
Visitors: 125
Members: 0
Total: 125



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 - Problem or defect?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Problem or defect?

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

Joined: Jan 21, 2010
Posts: 9

PostPosted: Wed Jan 04, 2012 2:03 am    Post subject: Problem or defect? Reply with quote

I've been working for some time on standardizing and maturing problem management in our organization.

One of the issues I've encountered is that when a problem is found in production, developement wants to reclassify this as a 'defect'.

Maybe it's all in the terminology, but my understanding of problem management is that it is not specific to just production environments, but to all.

We have some large hurdles to overcome, as developers use a different tool for "defect" tracking than in operations. The integration between these tools is a whole different discussion.

I do know that Problem management does exist in Service Transition when pushing releases into production with known errors. However, can problems be manifested earlier on and be called such or does it even matter?

For newly built configuration items, in development, going through early testing phases with issues, are they classified as problems or just 'defects'?

Back to top
View user's profile
Senior Itiler

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

PostPosted: Wed Jan 04, 2012 3:19 am    Post subject: Reply with quote

Without getting too precious about the definition, a defect is something that is wrong with a product in the sense of being contrary to its design specification.

In service management terms a problem is a set of circumstances that has the potential to disrupt a service either int erms of its availability or of its quality.

So, the use of a software product being delivered as a service is discovered to be causing incidents. The incidents are resolved by some means (workaround?), but it is recognized that they will recurr. This is a problem and requires investigation as to underlying causes with a view to resolution (eradication or amelioration).

Among other things, the underlying cause may be a defect in the software. It could be a design failing which you may regard as a defect or not, or it may be a documentation or training failing, or something else. If the underlying cause is a defect then there you are!

It is not the problem that is the defect, it is the cause of the problem that is the defect. This is an important distinction because, with a problem, you want to remedy it in accordance with the measure of risk agains the cost of the remedy and so you ask (require) development to expedite the correction accordingly.

My point is this: Service Management has a problem to manage and Development has a defect to identify and correct. The act of developing the correction is not part of problem management, but the imposition of, for example, timescales or deadlines is part of problem management. You do not pass the problem to Development. You commision them to perform actions (investigation, design, development, testing etc.)
"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

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.