Problem Management Free for all

Discussion on issues related directly or largely to ITIL problem management.
Post Reply
User avatar
AverageJoe
Itiler
Itiler
Posts: 5
Joined: Tue Nov 10, 2009 7:00 pm

Mon Dec 07, 2009 12:06 pm

Hey Everyone,
I am hoping someone can help me head off a decision that I believe would be a major disaster. The current ITIL tool we are using was setup so all Problem submissions would be sent to the Problem Management Manager. (Me) I would then validate the submission and assign it to one of my staff. We have kept a very tight lid on who could open a problem for fear of drowning under a deluge of non problems. Currently, my team of 3.5 people only work on the low hanging fruit. My management has asked that I create a process for opening up the tool so more problems can be worked/managed by other groups.

After receiving great advice from this forum, I submitted a Problem Review board and it was shot down very fast. They felt the process was too over managed and just want to open the tool so anyone could open and assign a Problem to anyone else. (shudder) As a background note, we are a very large company and as a whole, we do a very very poor job when it comes to documenting incident tickets so I would assume it won't be any better with problem tickets.
When I explained the chaos that would follow, I was told we could review the data in 6 months. (sigh) Management believes that a report showing PM tickets open for 30/60/90 days would "encourage" groups not to use the Problem tickets as a holding bucket.

To top this off, we have a group who has a database of over 1000 "Problems" that they want to submit. (Most of their "problems" don't meet the PM criteria but they just don't get the PM process)
I am pushing that we bring a outside consultant on-board but it seems like that path has already been chosen for us.

So here are my questions...
1. Has anyone gone down this path before and if so, how did it turn out?
2. How did you get out of it?
3. How do you implement documentation review and validation if anyone can open a problem ticket and transfer it anyone else?
4. How does one control a free for all where 99% of the people haven't and won't get any type of ITIL training?
5. Are my fears unfounded and this is normal?
Last edited by AverageJoe on Mon Dec 07, 2009 5:00 pm, edited 1 time in total.


User avatar
Timo
ITIL Expert
ITIL Expert
Posts: 295
Joined: Thu Oct 25, 2007 8:00 pm
Location: Calgary, Canada

Mon Dec 07, 2009 12:42 pm

What is your criteria for determining a Problem? Perhaps one thing you can do to lessen the flood is to

a) tighten the criteria that determine that an issue is a problem
b) setup a gatekeeper (yourself) and turn down any issues that do not fall within that criteria
c) ask for more resources (probably won't get it)
d) make sure your input/warnings are well documented and communicated to management (CYOA)
f) pray

Sorry, Joe, I feel your pain, but if you don't really have any say in what happens here then your only other choice is to either bite the bullet and pray, or change jobs. This is the problem in many companies: people holding process manager roles do not really have any say in how these processes are to be engineered, executed, impacted, etc.
User avatar
dam
Senior Itiler
Senior Itiler
Posts: 57
Joined: Tue Sep 04, 2007 8:00 pm

Mon Dec 07, 2009 1:35 pm

In the context of an ITIL organisation the problem management activity is strictly related to the incident management activity. People from outside the process cannot state if an issue is an incident, a problem or whatever. They are not supposed to know the process into details and they shouldn’t. If you establish an ITIL organisation for your support activity -or Service Operation activity to use the ITIL V3 lexicon- is to:
First, making things simple from outside: every request goes towards the service desk
Second, being strictly organised within the process, with clearly defined roles and responsibilities associated to processes and activities

In your case the misunderstanding seems coming from the fact the senior management want to state how to drive the process without a clear insight. As often happens it seems they misunderstand the ITIL meaning of the word “problem” that in the real world is almost the same as “incident”.

Therefore what I recommend you to defend the ITIL vision of the Problem Management against the senior management -and so keep the ownership of this process and keep the process functioning well- is to stick to the ITIL books and find the written justification of your approach.

Normally is more about adapting ITIL best practices to the real world, but in this case maybe being very strict with the “ITIL verb” may help you to defend your vision. Sadly senior managers are more ready to give reason to a book than a person.

Good luck!
User avatar
Caperz
Itiler
Itiler
Posts: 23
Joined: Thu Jul 23, 2009 8:00 pm
Location: Sydney, Australia

Tue Dec 08, 2009 5:54 pm

Hi Joe,

I have provided information in a recent post "https://itilcommunity.com/modules.ph ... pic&t=4647" that basically is inline with what you are about to venture on here and will respond to your post below :
The current ITIL tool we are using was setup so all Problem submissions would be sent to the Problem Management Manager. (Me) I would then validate the submission and assign it to one of my staff. We have kept a very tight lid on who could open a problem for fear of drowning under a deluge of non problems...... My management has asked that I create a process for opening up the tool so more problems can be worked/managed by other groups.
I am one of the problem managers in my global team. I/we also faced this same dilema. Historically (last 2 - 3 years) we have run the same way where it was only Problem and Incident Managers that can raise problem records mainly to ensure integrity and quality of what was being raised. This also created a bottleneck, as will explain further below

After receiving great advice from this forum, I submitted a Problem Review board and it was shot down very fast.
What was the "Problem Review board" that you submitted ?
They felt the process was too over managed and just want to open the tool so anyone could open and assign a Problem to anyone else. (shudder) As a background note, we are a very large company and as a whole, we do a very very poor job when it comes to documenting incident tickets so I would assume it won't be any better with problem tickets.
When I explained the chaos that would follow, I was told we could review the data in 6 months. (sigh) Management believes that a report showing PM tickets open for 30/60/90 days would "encourage" groups not to use the Problem tickets as a holding bucket.
I can fully understand and empathise with that as this is basically what has happened on my side also. Except I have been part of the process decision making process but also worked with the Operations top level management to look at aligning our processes, that we manage, into the operations and technical teams daily work. The problems are actually reported on and reviewed by the top level technical function managers at a monthly basis and questions are starting to be asked which is reducing the problems tickets being used as a "holding bucket". So this does work as long as you have process buy in from the management at that level and I think the key here is forming a good, solid and on-going relationship with that level of management that will have a big say in promoting, supporting and pushing process and process adherence through the support groups - from the top down (this is exactly what you want).
To top this off, we have a group who has a database of over 1000 "Problems" that they want to submit. (Most of their "problems" don't meet the PM criteria but they just don't get the PM process)
Hmmm - this was another reason why a joint decision was made to get access to others to create the problem records. I want to encourage ALL problems to be recorded in the same and chosen problem management tool. At the end of the day, you cant improve what you can measure, you cant measure what you cant control, you can control what you cant see !
I would rather have all the problems in the one tool... freeing up some of my time to actually start to look at and measure how problem management is being used in the organisation and run process reviews and meetings with technical managers about how their teams are performing, where the gaps are and how they can do better. This is all part of the PDCA and/or CSI model.
1. Has anyone gone down this path before and if so, how did it turn out?
Look above ;)
2. How did you get out of it?
I supported this move and am still transitioning towards that path
3. How do you implement documentation review and validation if anyone can open a problem ticket and transfer it anyone else?
I would keep the group that can open new problem records to as small as possible so it stays manageable. I would say maybe a team leader and a backup from each tech group.... then review that again is say 3- 6 months.

4. How does one control a free for all where 99% of the people haven't and won't get any type of ITIL training?
That is a challenge and requires top level management buy-in of ITIL and its direct benefits to the organisation !
I have found that even after ITIL training - there are still process adherence issues - in my career. Techs will be techs... and tradionally my experience has been that techs hate documentation and following processes. There are mixed reasons for this and some are related to fear of loss of control, being made expendable and the big brother feeling etc. However the key is Continous Process Adherence, persistance and consistency with reviewing process adherence and getting input from the people working with the processes and their line managers / top level managers then looking at gaps and areas of improvement and running programs to address these.
I am now looking at starting regular open sessions that I will invite technicians to where the agenda will be problem / incident management and the tool that we use. People can drop in with no commitment and ask as many questions and/or give as much feedback towards the processes and this can be taken on and worked on, as part of CSI.
5. Are my fears unfounded and this is normal?
To me, VERY natural as per my reply and my previous posts. I hope things work out mate... keep this post updated with your experiences and learnings going forward. Good Luck !
ITIL V3 Capability - Operational Support & Analysis Certified
User avatar
AverageJoe
Itiler
Itiler
Posts: 5
Joined: Tue Nov 10, 2009 7:00 pm

Thu Dec 10, 2009 1:27 pm

The criteria we use to determine if my team created a Problem ticket and takes ownership is as follows

1. High Impact (Root cause not found during recovery effort)
2. Major Process issues
3. Reoccurring impact
4. Senior Management requests a MPR (Major Problem Review)

During a Pilot where we gave 5 people PM user access, we gave these guidelines....

"A problem is a condition often identified as a result of multiple Incidents that exhibit common symptoms. Problems can also be identified from a single significant Incident, indicative of a single error, for which the cause is unknown, but for which the impact is significant." (Please note, if the impact is significant, then PM (my team) will own the ticket)

A Problem ticket will not be opened by any team if any of the following conditions are met
1. A Minor work request is in flight to resolve the issue
2. The incident has not been resolved
(A problem ticket will not be created for the purpose of only closing an incident ticket)
3. An Business accepted workaround has not been implemented
4. A change ticket needs a origination
5. A project is in flight to create, upgrade, replace or restore a service or application

We found that even with these guidelines, those 5 people we trained kept opening Problem tickets for issues that didn't meet the criteria.

Examples would include....
Opening a problem ticket because a user corrupted some data and wanted it to be restored (Still an incident)
An application wasn't performing calculations correctly after a change had been performed on the app. (This is an incident)
An log file had shown a weird error message one time 2 years ago. (They wanted to track the message in case it every happens again
User avatar
Timo
ITIL Expert
ITIL Expert
Posts: 295
Joined: Thu Oct 25, 2007 8:00 pm
Location: Calgary, Canada

Thu Dec 10, 2009 3:39 pm

I think it's good Joe, to get you guys going. Overtime specific conditions will be adjusted as you get more real data and knowledge accumulated and see what's working and what's not, but I'd say this is a pretty good start.

I don't think you should try and create a 100% proof criteria, and leave no room for reasoning and judgement. You will never cover all the possible scenarios. Good luck.

Timo
User avatar
MBU
Senior Itiler
Senior Itiler
Posts: 70
Joined: Wed Dec 17, 2008 7:00 pm

Fri Dec 11, 2009 4:54 am

Joe,
I agree to Timo.
The only thing where I would keep an eye on is the "Senior Management MPR". for this you have to define and agree on a list of VIP or roles inside your organisation. And, be careful, once the ceretary of CxO knows this all of her "I can't print please raise a MPR" Incidents will be Problems for you.
My 2ct
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)
Post Reply