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

Current Membership

Latest: Cynok
New Today: 4
New Yesterday: 73
Overall: 150041

People Online:
Visitors: 62
Members: 0
Total: 62

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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.


The Itil Community Forum: Forums

ITIL :: View topic - Problem Management Free for all
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Problem Management Free for all

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


Joined: Nov 11, 2009
Posts: 5

PostPosted: Tue Dec 08, 2009 3:06 am    Post subject: Problem Management Free for all Reply with quote

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 Tue Dec 08, 2009 8:00 am; edited 1 time in total
Back to top
View user's profile
Timo
Senior Itiler


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

PostPosted: Tue Dec 08, 2009 3:42 am    Post subject: Reply with quote

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.
Back to top
View user's profile
dam
Senior Itiler


Joined: Sep 05, 2007
Posts: 57

PostPosted: Tue Dec 08, 2009 4:35 am    Post subject: Reply with quote

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!
Back to top
View user's profile
Caperz
Itiler


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

PostPosted: Wed Dec 09, 2009 8:54 am    Post subject: Re: Problem Management Free for all Reply with quote

Hi Joe,

I have provided information in a recent post "http://www.itilcommunity.com/modules.php?name=Forums&file=viewtopic&t=4647" that basically is inline with what you are about to venture on here and will respond to your post below :

Quote:
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


Quote:
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 ?

Quote:
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).

Quote:
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.

Quote:
1. Has anyone gone down this path before and if so, how did it turn out?

Look above Wink

Quote:
2. How did you get out of it?

I supported this move and am still transitioning towards that path

Quote:
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.


Quote:
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.

Quote:
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
Back to top
View user's profile
AverageJoe
Newbie
Newbie


Joined: Nov 11, 2009
Posts: 5

PostPosted: Fri Dec 11, 2009 4:27 am    Post subject: PM criteria Reply with quote

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
Back to top
View user's profile
Timo
Senior Itiler


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

PostPosted: Fri Dec 11, 2009 6:39 am    Post subject: Reply with quote

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
Back to top
View user's profile
MBU
Senior Itiler


Joined: Dec 18, 2008
Posts: 70

PostPosted: Fri Dec 11, 2009 7:54 pm    Post subject: Reply with quote

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)
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 http://www.nukecops.com

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.