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: HGoble
New Today: 33
New Yesterday: 69
Overall: 148113

People Online:
Visitors: 57
Members: 2
Total: 59 .

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 - How to identify a problem
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

How to identify a problem

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


Joined: Jan 05, 2009
Posts: 7
Location: British Columbia, Canada

PostPosted: Tue Jan 13, 2009 8:02 am    Post subject: How to identify a problem Reply with quote

Hi All,

I'm trying to hammer down a policy of "How to identify a problem."

In my current organization we do not have a Problem manager to watch all the incidents that come in and identify problems. I haven't decide exactly who will be creating problems but, I would like to know what other people use (as a policy) to identify problems.

I know that there is the obvious "high number of incidents" but, are there any other out there?

I'm trying to move this away from an art to a science so that people can follow an exact process.

Does that make sense??
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3320
Location: London, UK

PostPosted: Tue Jan 13, 2009 7:02 pm    Post subject: Reply with quote

jayrob

Here is a suggestion

It may be helpful, it may be sarcastic it may be both or it may be a waste of alphabetical characters

Establish a criteria for a problem - hitn use ITIL definition
Reactive Problem mgmt

- criteria should be at least
-- why has this happened ? what is the underlying root cause ? if known (not a candidate for a problem). If unknown (how much time and resources should be spent on find root cause)
- are there any incident which were major service outages - even if root cause known, can PM help ? if so, make PM record

Proactive PM-

- look at system architecture
- look at network archtitecture
- look for Single points of failure
- look for 'problem' systems. OS, patches etc -

Microsoft WinNT4 servers, sp1 - have a tendancy to BSD
Cisco router 4800 series has a IOS vulneraility...
SQL Server patch
etc

plan via Change mgmt to close these in a timely fashion

What you would do - is turn one of your IM staff into a PM staff on a tasking basis. IM team can me front line, system support etc etc

Mike from Wintel support team will investigate this (issue/incident set / now a probelm record) for 2 weeks to find root cause
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
jayrob
Newbie
Newbie


Joined: Jan 05, 2009
Posts: 7
Location: British Columbia, Canada

PostPosted: Wed Jan 14, 2009 4:25 am    Post subject: Reply with quote

Thanks UKVIKING,

That's what I thought should happen. A problem is created by anyone in the organization. The problem then gets assigned to a problem coordinator.

In out IT department, we have different groups of people looking after different aspects of the organization. IE: there's a group for networking, client support and programming. In each department under IT a person will be designated as a problem coordinator to own the problems under their portfolio. Which means, its not a role that one person will be doing all the time but, only when there is a problem ticket assigned to them.

My only concern with this model is, finding the right people to be designated as a problem coordinator. It has to be someone in the department with either formal or informal power in the organization to be able to engage other employees from other departments to resolve/diagnose a Known Error.

Interesting...
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Wed Jan 14, 2009 10:26 pm    Post subject: Reply with quote

jayrob wrote:
A problem is created by anyone in the organization.


If I may be a little pedantic, I think you mean "identified" rather than "created"; although I have no doubt most people are capable of creating problems Smile

jayrob wrote:
... a person will be designated as a problem coordinator to own the problems under their portfolio.


Not all problems will fall within a single portfolio.

jayrob wrote:
It has to be someone in the department with either formal or informal power...


Your procedures will not stand up to scrutiny if you try to document informal authority within them.



You will not reap the full benefits of Problem Management unless you have someone responsible overall. If the role cannot be placed anywhere else, then it should be done another rung up the ladder (IT Services Manager?).

Otherwise you may find two sections pursuing the same problem, there could be issues of priority, neglect of problems that are difficult to diagnose, responsibility for performance of Problem Management etc.
_________________
"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
JoePearson
Senior Itiler


Joined: Oct 13, 2006
Posts: 116
Location: South Africa

PostPosted: Wed Feb 04, 2009 2:19 am    Post subject: Reply with quote

jayrob wrote:
A problem is created by anyone in the organization.

Diarmid wrote:
"identified"

Smile

I want to quibble ever so slightly with the idea that anyone can identify a problem.

One useful definition of problem management (I can't remember if I got this from one of the ITIL books, or elsewhere) is that it represents a decision to allocate extra resources to addressing some quality issue. Now, clearly that decision has to be taken by management, and it's IT service provider management not customer management.

I assume you mean "anyone in the IT organisation", which is fine - but there should be clearly delineated authority as to who can decide that a problem is going to be allocated staff resources over and above normal work. Not necessarily, in fact probably not, a "Problem Manager", but not just anyone.

So in theory anyone could "identify" a problem but only authorised mgt can approve a problem for work (RCA and error control). And if your customer sees stats on "problems", you don't want identified but not approved problems cluttering up the reports, so you would even restrict "identifying".

---

One of the issues, which Diarmid touched on saying "Not all problems will fall within a single portfolio", comes when you have several separately managed technical teams - as most large service providers do. In a client I worked with last year, we looked at this issue. They allowed each team to work on "problems" that were wholly within their technical domain without any central control ... a situation we hope to improve in the future, but one they can live with for now. The real pain was problems that require cross-team involvement, and this is where they are applying formal problem mgt, with a problem manager who runs the process, identification of problems by committee (some official criteria, but more by discussion) and - this is where it gets formal - appointment of a problem coordinator, resources committed from each technical team, and scheduled meetings. These teams could in theory be in place for months, for intermittent symptoms (only when there is an unusual peak of month-end billing processing and some back-end network traffic is routed differently from normal...).
Back to top
View user's profile Visit poster's website
Diarmid
Senior Itiler


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

PostPosted: Wed Feb 04, 2009 3:09 am    Post subject: Reply with quote

JoePearson wrote:
So in theory anyone could "identify" a problem but only authorised mgt can approve a problem for work (RCA and error control).


That's what I said. I just didn't write it down Laughing

Diarmid wrote:
My underlying assumptions are someone else's essential details and vice versa.

See - Told you so!

================

JoePearson wrote:
And if your customer sees stats on "problems", you don't want identified but not approved problems cluttering up the reports, so you would even restrict "identifying".


I totally agree.

However, the prioritizing has to be based on business imperatives which might mean you are talking to the business about them.
_________________
"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
UrgentJensen
Senior Itiler


Joined: Feb 23, 2005
Posts: 458
Location: London

PostPosted: Wed Feb 04, 2009 6:46 pm    Post subject: Reply with quote

I tend to know I've got a problem when I've woken up in a ditch behind a drive-thu wedding chapel and I'm wearing an elvis costume and wig.

UJ
_________________
Did I just say that out loud?

(Beige badge)
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Wed Feb 04, 2009 7:49 pm    Post subject: Reply with quote

UJ,

so long as a service was delivered in the chapel, that might just be an outcome rather than a problem.
_________________
"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
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3320
Location: London, UK

PostPosted: Wed Feb 04, 2009 7:52 pm    Post subject: Reply with quote

Like UJ

I can identify problems real easy

Mirrors help

And UJ ... as long as you were wearing the Elvis costume and wig, it is an incident and only that... if you had been wearing the wedding dress, then it would have been a problem

or a change
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
UrgentJensen
Senior Itiler


Joined: Feb 23, 2005
Posts: 458
Location: London

PostPosted: Wed Feb 04, 2009 8:31 pm    Post subject: Reply with quote

Diarmid - there's always an outcome... unfortunately.

Viking - It's definitely a problem - it's not the first time it's happened... And as for a wedding dress, I can't guarantee anything next time.

UJ
_________________
Did I just say that out loud?

(Beige badge)
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3320
Location: London, UK

PostPosted: Wed Feb 04, 2009 10:47 pm    Post subject: Reply with quote

I think it would be a major incident

if you were dressed as elvis with the wig and in a wedding dress
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
eisbergsk
Senior Itiler


Joined: Nov 01, 2004
Posts: 81
Location: Sask, Canada

PostPosted: Thu Mar 26, 2009 5:24 am    Post subject: How to identify a problem Reply with quote

jayrob wrote:


In each department under IT, a person will be designated as a problem coordinator ...
My only concern with this model is, finding the right people to be designated as a problem coordinator. It has to be someone in the department with either formal or informal power in the organization to be able to engage other employees from other departments to resolve/diagnose a Known Error.

Interesting...


oh dear. I would suggest that you designate a person with power to pick a manageable sample set of incidents based on the criteria of what is important to your company/organization, review them & assign them as problems to be worked on by these other employees from other departments.
By focusing on what is important to the company, you will hopefully be able to come up with an objective, non-disputable agenda which will transcend departmental boundaries. Otherwise - you get bupkes! (nothing)! problems will get cherry picked, or mostly avoided. Have you noticed that most problems are caused by 'other people/groups/departments'? yeah.
/Sharon
_________________
In theory, there is no difference between theory and practice.
In practice, there is!
Back to top
View user's profile Send e-mail
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.