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.

- 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

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.

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

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

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

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

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!