Posted: Wed Nov 18, 2009 7:28 am Post subject: Problem ticket documentation requirements
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?
Joined: Oct 26, 2007 Posts: 295 Location: Calgary, Canada
Posted: Wed Nov 18, 2009 8:29 am Post subject:
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
Joined: Mar 04, 2008 Posts: 1890 Location: Helensburgh
Posted: Wed Nov 18, 2009 7:56 pm Post subject:
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
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
Cheers /Richard _________________ ---------------- bragging line -----------------
V2 Combined Practitioner (service support)
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)
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.
/R _________________ ---------------- bragging line -----------------
V2 Combined Practitioner (service support)
Joined: Jul 24, 2009 Posts: 23 Location: Sydney, Australia
Posted: Mon Dec 07, 2009 6:25 am Post subject:
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
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
- 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
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
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.