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: MargeneD47
New Today: 39
New Yesterday: 34
Overall: 231611

People Online:
Visitors: 67
Members: 0
Total: 67



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 ticket documentation requirements
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Problem ticket documentation requirements

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

Joined: Nov 11, 2009
Posts: 5

PostPosted: Wed Nov 18, 2009 7:28 am    Post subject: Problem ticket documentation requirements Reply with quote

Hi All,
I've just read through most of the PM discussions on this forum and learned that I have a lot more to learn. I am a recently promoted PM Manager (Foundation v1 trained) and have been tasked with developing the requirements and processes for opening our PM module to more of the IT groups.
Our PM group has been around for about 9 years but has shrunk from 8 people to 3 people, including myself. My organization has about 400 Service Desk employees and roughly 1000 IT support staff and opens roughly 46k incident tickets per month.

My concern revolves around people/groups opening Problem tickets with little to no documentation. Our support teams have vast areas of opportunities when it comes to ticket documentation. (understatement) Certain groups are asking for everyone to have the ability to open a Problem ticket and Known Errors, including the Service Desk and our Data Center. (Worst offenders when it comes to ticket documentation)

To prevent PM from becoming a black hole of infinite problem tickets that have little to zero documentation, is it acceptable to have requirement questions that have to be answered before we will look at a ticket?
Questions such as How often has this ticket happened and Have you contacted 2nd level support regarding this issue?

So everything boils down to....
Are question requirements acceptable before PM will investigate the issue?
Should PM expect other teams to do a little groundwork first before requesting a Problem?

Thanks in advance for any help
Back to top
View user's profile
Senior Itiler

Joined: Oct 26, 2007
Posts: 295
Location: Calgary, Canada

PostPosted: Wed Nov 18, 2009 8:29 am    Post subject: Reply with quote

I would say that questions and initial investigation are a must before a problem record is open/requested. Should be done during the Incident handling in most cases anyway.

Seeing how there is only 3 of you, I wonder, if you group is responsible for actually solving technical issues or staying on top/coordinating resolution of the problems, while other technical teams do the actual work?

Regardless, questions should always be asked. While I doubt you will be able to establish a black and white criteria for creating a problem, you should provide teams with some guidelines that will allow them to detect problem, and with information that they must provide you with in order to initiate the process. After that, it might be a back and forth exercise requesting clarification, additional information, etc, etc...

On a personal note, since there is only 3 of you I would think of a very very strict and extensive criteria for creating a problem Wink
Back to top
View user's profile
Senior Itiler

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

PostPosted: Wed Nov 18, 2009 7:56 pm    Post subject: Reply with quote

If staff outwith the Problem Management team are to open problem records, then certain information must be provided (it's not really a matter of questions, but of information).

1. Description of problem including which services/customers it may affect.
2. Identification of incidents, if any, that have occurred in consequence.
3. Description of resolution actions (including null actions) that have been identified/applied - and comment on effectiveness.
4. Statement of probability of [further] incidents occurring.
5. Statement of cost (or range of costs) to business of these incidents
6. Statement of costs of incident investigation and resolution actions for these incidents.
7. Relevant business and service contacts.
8. Confirmation of, or request for, appropriate authority to raise problem.

You will reject any requests that do not provide this information or co-operative means of obtaining it.

This list is incomplete both because I have probably missed something and because there will be further information necessary that can only be identified from within your organization.

Since you are not resourced directly for more than a few problems, you probably need a process (managed by the Problem Manager) to obtain approval, prioritization and resource allocation within IT services in order to ensure that business focus is properly maintained.

I sense a need to review the capacity of such a small team in such a large environment to pursue pro-active problem management and manage the progress of current problems.
"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 Nov 18, 2009 9:48 pm    Post subject: Reply with quote

In our world, we use the term "Problem Candidate". Any ITIL process manager + Service Desk + IT management + external partner/supplier can submit a Candidate. Whether it will be promoted to a Problem ticket is up to the PM only, after scrutinizing the info and consulting SMEs. If the Candidate has enough background info and is justifiable in a business perspective, it is more likely to get promoted and correctly prioritized. Simple - but a local adaptation of ITIL. And a good filter against being flooded by garbage and dupe tickets.

Actual (accepted) Problem tickets are published, get a queue number and a PM priority, and then they are handed over to SME:s, flagged as "RCA in progress" a s o...

Problem Candidates that get rejected are published as such, and sent back to the owner with a motivation (lack of substance, bad info, dupe, already being handled, no business case etc).

A Known Error is treated likewise: a few select people can submit a KE or a SR (or an INFO post) into the KEDB, but only 2 people can publish them. Publishing criteria are strict: language, content, correct TAGging, tried and true solution, in-depth RC description if available etc. This ensures hight standards all over.

Advice from here: do NOT let anyone else create your Problem Tickets or publish KE:s. Half of the power of the PM process lies in good background data, which you lose if you allow "anyone" to create a PT or a KE. Use the "Candidate" middle way - let people help you, but keep your firm grip on the accepted/published stuff. Thatīs management Smile

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

Joined: Dec 18, 2008
Posts: 70

PostPosted: Thu Nov 19, 2009 2:52 am    Post subject: Reply with quote

Nearly the same approach at a customer:
PM Candidates can be raised by SD & IM team members. Then, frequently (weekly or every 2 weeks) the IM & SD Manager has to justify the Candidates in front of the PM Manager (exception: Prio 1 Incidents). This has improved the quality of Candidates tremendously, because the IM & SD Manager don't want to "look like idiots" in front of PM Manager and they see, what their teams are producing. After a certain time teams learned their lessons and now only few candidates (< 3%) are rejected. Rejected PM Candidates are then in monthly review of SD,IM and PM Manager to improve procedures.
Hope this helps ...
Michael B.

"I can't say it'll be better if it changes, but I can say it has to change to be good"
G.C. Lichtenberg (1742 - 1799)
Back to top
View user's profile
Senior Itiler

Joined: Oct 26, 2007
Posts: 295
Location: Calgary, Canada

PostPosted: Thu Nov 19, 2009 5:55 am    Post subject: Reply with quote

Great tip... I haven't heard of the Problem Candidate before. Thanks.
Back to top
View user's profile

Joined: Nov 11, 2009
Posts: 5

PostPosted: Thu Nov 19, 2009 8:13 am    Post subject: Thank you all Reply with quote

Great information from everyone. Thank you for all the help.
Back to top
View user's profile

Joined: Mar 19, 2008
Posts: 29

PostPosted: Mon Nov 23, 2009 6:23 pm    Post subject: Reply with quote

We had to invent this Candidate thing for 2 reasons:

1. The Problem Manager job is only 50% of my work. I didnīt want to miss things when doing my other work (often away from office), and this is a great way to stay in touch and keep the helicopter view. (due to this 50% issue, our IM has taken the responsibility of handling MI:s, too, even if ITIL says itīs the PM:s responsibility. PM takes over ASAP after the MI is resolved.)

2. Since we had a LOT of issues (potential, actual and fictional problems) initially, I felt the need to get a quick overview. To allow people to submit "Candidates" gave me just that, and also pointed out areas where many functions/teams/users have similar issues. At one point, 5 or 6 different candidates from different sources were promoted to ONE Problem Ticket - they all pointed towards the same Root Cause (sloppy programming of a helper application).

These days, a rejection is VERY rare. Also, the initial flood of submitted Candidates has slowed down to a trickle, most being proactive stuff.

Many advantages in this Candidate level. But: it may or may not be usable in your organisation.

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

Joined: Jul 24, 2009
Posts: 23
Location: Sydney, Australia

PostPosted: Mon Dec 07, 2009 6:25 am    Post subject: Reply with quote

Hi team,

We have also been working where only the Incident & Problem Managers were allowed to register problem records. We found that there was a bottleneck when we worked this way as there was way too many problems that were not being registered as it was only the global team of 4 that could register these records and a total of 1200 IT users.
Also technicians were already working with the problem management process is some way but were recording their investigative and resolution work in their own operations activities databases and then submitting disconnected RFCs etc. They would get discouraged to even request a problem record be created as they needed to fill out a form with the following questions :

- Please provide a Summary of this Problem in your own words
- How long has this problem existed ?
- How did you become aware of it ?
- What criteria has been met for this to be defined as a Problem ?

Please choose one :

When a P2/UH Incident is recorded
Monitoring events that might lead to a future Incident (e.g. disk space warning, low bandwidth)
Workaround or temporary fix is not available
Repeat Incidents
Unsustainable workaround (e.g. end user not satisfied with the workaround)
Incidents caused by changes or releases

- Please list all the related Incident Records and/or RFCS that are
related to this Problem
- Do you know of any current workarounds that exist for this Problem
today ?
- What is the impact of this problem today ? (How many people are
effected by it that you are aware of and where are they located ?)
- Who shall be the stakeholder and/or contact person for this Problem ?
- What is the best contact number for this Contact ?

These are not all mandatory and the requestor is encouraged to fill in as many questions as possible. They were also discouraged at the fact they needed to ask someone else to create the problem record and felt frustrated when they couldnt do it themselves.

We have now been running Problem Management training sessions slowly throughout the organisation and then opening up the ability of users to create their own problem records once they have had the training. I am aiming at keeping this group to as small as possible so we dont lose the focus on process adherence.

I really hope that this actually adds value and at least encourages the techies to log problems in the right tool and connect them back to the RFCs being used. We are now implementing a KEDB. That will be fun !
ITIL V3 Capability - Operational Support & Analysis 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.