Assigning problem records

[gon689]

Hello everyone,

According to our Problem Mgmt process, every problem record should be assigned to a problem owner. Currenly, I contact a manager of a group responsible for root cause analysis and ask him/her to assign a problem owner.

How do you guys handle it in your organisations?

[UKVIKING]

Short answer:

it depends

If your process says that then that is fine.

However, do you have a problem manager (yourself) to monitor / manager the assignments
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[UrgentJensen]

Hi,

We have a central problem manager (who has another primary role) to own all problems. He then raises actions with any relevant individual/team in the department.

It works for us because we have a tight head count and means that delivery managers don't have to get too heavily involved in running the process themselves, just taking part in it when asked to.

UJ
_________________
Did I just say that out loud?

(Beige badge)

[gon689]

[UKVIKING]

The problem with assigning things to individual (names Joe smith, etc ) vice role - Microsoft team leader - is that when that person leaves, you have to change your documentation
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[UrgentJensen]

John,

That's an assumption that you're not well documented, communicated and trained. We created a queue within our Service Desk system for problems, so they don't get lost in a spreadsheet on someone's local drive. Problem reporting is discussed weekly in our service meetings... you know, standard stuff, but keeps things ticking over.

(Would like to say we have an ultra modern process orientated Service Management tool here to do the classical linkage from incident through to problem etc, but that's not arriving for another year.)

UJ
_________________
Did I just say that out loud?

(Beige badge)

[UKVIKING]

UJ,

I am not well documented (manual missing key pages) however I am trained (potty, beer, spelling) and I have been communicated.

I have seen however official documented processes that put peoples names in key roles and when that person leaves or transfered, he / she still is assigned that work and when contacted... they usually go 'huh' but I left that role 6 months ago...

It should always be named role rather than named person

In addition, if people share an assigned role, then the first phrase they use is - well I thought blank was doing that as it came out when he was on rotation

The best (practical, pragmatic, pedantic) way to do this is to assign to a team lead or manager who's primary role is then to assign it // task it to a specific team member - this way there is an audit trail.

For example: the problem team has a issue about microsoft servers, the primary team would always be the microsoft team and the M/S team has 2 people dedicated to PM work (rotating everymonth). If the issue is assigned to the MS team lead, he can a) assign it to the poor sod on rotation or b) if it is specific enough (SNA, IIS, Exchange) to the poor sod who is the corp expert

but... it depends
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[UrgentJensen]

Agreed, all should be role based, not individuals.

It's a bit like knowledge pickett-fencing, techies think it makes their jobs more secure because they control knowledge about certain areas. What they fail to realise is that if you make yourself indispensible then no one will want to move you on.

UJ
_________________
Did I just say that out loud?

(Beige badge)

[Gana147]

Ideally the problem record (RCA) must be done by the Resolver Group. and the Problem Coordinators and Problem Managers have to facilitate the actions.

Problem Coordinator/Problem Manager:
*Have to read the incident and should prepare a Draft with sequence of events.
*Come up with Issues identified/lessons learnt.
*Facilitate resolver group meetings.
*Speak with Business if necessary to implement the changes.
Coordinate the overall proces.

Problem Analyst:
*One member from each resolver group should be termed as Problem Analyst.
*Identify the root cause.
*Participate in the meetings with other resolver groups.
*Propose suggestions and changes to give permanent solution.