Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
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.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Joined: Jan 05, 2009 Posts: 7 Location: British Columbia, Canada
Posted: Tue Jan 13, 2009 8:02 am Post subject: How to identify a problem
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.
Joined: Sep 16, 2006 Posts: 3591 Location: London, UK
Posted: Tue Jan 13, 2009 7:02 pm Post subject:
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
Joined: Jan 05, 2009 Posts: 7 Location: British Columbia, Canada
Posted: Wed Jan 14, 2009 4:25 am Post subject:
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.
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Wed Jan 14, 2009 10:26 pm Post subject:
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
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
Joined: Oct 13, 2006 Posts: 116 Location: South Africa
Posted: Wed Feb 04, 2009 2:19 am Post subject:
jayrob wrote:
A problem is created by anyone in the organization.
Diarmid wrote:
"identified"
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...).
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Wed Feb 04, 2009 3:09 am Post subject:
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
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
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Wed Feb 04, 2009 7:49 pm Post subject:
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
Joined: Sep 16, 2006 Posts: 3591 Location: London, UK
Posted: Wed Feb 04, 2009 7:52 pm Post subject:
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
Joined: Nov 01, 2004 Posts: 83 Location: Sask, Canada
Posted: Thu Mar 26, 2009 5:24 am Post subject: How to identify a problem
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!
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
