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: ARolph
New Today: 24
New Yesterday: 59
Overall: 146183

People Online:
Visitors: 56
Members: 0
Total: 56

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

Where does Problem Management stop?

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


Joined: May 04, 2007
Posts: 6

PostPosted: Tue Aug 11, 2009 8:08 pm    Post subject: Where does Problem Management stop? Reply with quote

Is problem mgmt concerned only with finding the solution or dies it also implement their solution? i feel that its suggestions should be carried out by the Change Mgmt team or Incident Mgmt?

But, shouldn't Problem Mgmt be implementing the change (in a test environment. if needed) to ascertain the viability of its recommended solution? or does it just give the verbal solution and leaves it for the Chane Mgmt or Incident Mgmt to find out if it works.

Any ideas will be appreciated.
Back to top
View user's profile
SwissTony
Senior Itiler


Joined: Feb 26, 2009
Posts: 118
Location: Geneva

PostPosted: Tue Aug 11, 2009 10:11 pm    Post subject: Reply with quote

Briefly work arounds should be recorded in the Known Error Database & then communicated to users via the Service Desk.

For Permanent Fixes the Problem Mgr should work in coordination with the technical teams that assisted in finding the solution to raise an RFC. In which case it would most likely be the tech guys implementing the solution, and the Problem Mgr staying in the loop to be able to monitor the change, and close the Known Error once the permanent fix is successful.
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Wed Aug 12, 2009 1:22 am    Post subject: Reply with quote

1. A reasonable outcome of the management of a particular problem would be the specification of a change and this may have been arrived at by conducting tests and experiments. However it should come to change management as a formally proposed change with proper evidence of correct quality attached.

The above is "this is what needs fixed, and this is how to fix it."

2. Equally a reasonable outcome of the management of a particular problem could be a functional specification of requirement which the business would commission (internally or externally) and which might be owned by the development manager. This would then come to change management by the normal development route. The problem manager would at least keep a watching brief until the product was developed, implemented and proved.

"This is what needs fixed and this the way it has to be different."

----

Both approaches will apply because it would be a waste of time to start commissioning very trivial solutions well within the skill set of problem analysts and it would be a management nightmare if the problem analysts went off on six month development projects just because they know what is needed. where you draw the line will vary from one place to another.

The point is that problem management is responsible for identifying the underlying cause of the problem and seeing that this is addressed by the organization. There can be no hard and fast rule about how involved the PM team becomes in the steps up to implementation since it depends on how your organization deploys its skilled resources.
_________________
"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
BorisBear
Senior Itiler


Joined: Mar 10, 2008
Posts: 403
Location: Sunderland

PostPosted: Wed Aug 12, 2009 9:38 pm    Post subject: Reply with quote

It sounds like you're after a physical answer to a logical subject.

A more useful question might be "where does problem management start" as this is the question that many struggle to articulate a cogent answer to.
Back to top
View user's profile
Bluesman
Itiler


Joined: Mar 19, 2008
Posts: 29

PostPosted: Fri Aug 14, 2009 6:32 pm    Post subject: Reply with quote

"The point is that problem management is responsible for identifying the underlying cause of the problem and seeing that this is addressed by the organization. There can be no hard and fast rule about how involved the PM team becomes in the steps up to implementation since it depends on how your organization deploys its skilled resources.
"

This is as close you can get. A very precise piece of text!

Problem Management is just that. Management. Making sure it gets fixed, using the tools available. Your best tool is the "helicopter view". (The second and third IMHO are improvisational skills and good relations to the right people). The PM does not need to be an analyst or even an IT geek. He needs a mandate, though, and a way of knowing who to ask for help.

In some cases, the PM actually has the skills that would help RCA and RFC implementation. Fine. Then let the PM be a part of the solution, maybe as an analyst, or as a part of build&test. If the PM has the skills to package a software rollout - fine. Let the PM do some practical work for the Release process.

Just don´t forget to take the PM hat off while you do practical stuff in other processes. While there, you are just a guest, maybe with special skills, but still.

Once in a while, go back to your helicopter, put your PM hat back on and make sure you still have the helicopter view (and grip) of your investigation(s) and your process = management.
_________________
---------------- bragging line -----------------
V2 Combined Practitioner (service support)
Problem Mgr
Back to top
View user's profile
Marcel
Senior Itiler


Joined: Sep 21, 2006
Posts: 63
Location: USA

PostPosted: Sat Aug 15, 2009 3:11 am    Post subject: Reply with quote

Keep in mind that for many organizations Change Mgmt is essentially not more than an approval process to get changes into production in an orderly fashion (gatekeeper of the production environment). In other words, the Change Mgmt process does not modify application code. It just gives the approval to go ahead and put it into production after checking certain requirements have been met (i.e. properly tested, communicated to steakholders, etcetera).

It is very well possible that the same people involved in root cause analysis are also involved in developing the fix. Most organizations do not have fully separated teams for these activities. That would not be cost-effective in many cases.
_________________
Manager of Problem Management
Fortune 100 Company
ITIL 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 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.