who should raise a Problem Record?

[elbow]

For a while now i have always assumed it was the PM only that raised a problem record. It now seems not the case depending on company policy. On inspection of itil process, it doesn't state this but suggests the service desk can.
i imagine this to be reasonable if the SD is sharp, but not always the case and could be messy. I have always worked whereby the pm is notified of any issues and therefore retains control over all problem records.

Once the SD raises the PM case, i then assume it is then administered by the PM only?

The same for major incidents, the PM case can be raised by the SD?

Thanks for any pointers

[UKVIKING]

Elbow

Please read more closely

What should happen is as follows

A Problem candidate record is raised. What this means is that something is found that may requirement PM involvement. I call it a P C R. for lack of a better term

The PM team have a set of criteria to determine whether they can take on the PCR and try to solve it - based on the criteria...If accepted a Problem record is created and a team is assigned to work on it. To solve it and come up with a solution.

However, this depends on whether the PM Team can deal with the P CR or not

For example

You have an issue with Windows 7 or Windows 8 for about 40 users. Yet, the PM Team have no specialists with Win7 or Win8. So why would they spend time trying to clear this problem. The Win7/8 may be a pilot and there fore the pilot team would need to solve it or even worse point to Microsoft
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[elbow]

UNVIKING.

Thanks for the reply - in essence what you're saying is that the PCR is a notification/request to PM to investigate an issue and then PM decide whether they will open an actual Problem investigation based on certain criteria.

Therefore, it should only be PM that open a problem record and also retain control of that problem record?

[UKVIKING]

Elbow

In essence, yes.. how you do it is the devil in the details

You can allow everyone to suggest (however your tool works) a Problem record - call it a problem record request

however, the PM team has to accept it or reject at their convenience

i would recommend a PM 'cab like' meeting accepting or rejecting these
and do follow ups - on outstanding ones
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[baloutang]

UKVIKING,

Would you suggest that the PM-like CAB be run similarly to a CAB? It makes sense to have an "approval process" for problems that are worked by the PM team. I think it's in the details of how this is executed to where it can become extremely efficient or greatly dysfunctional depending on the organization.

Personally, I like the idea, but for the organization I work for it would be a face to face meeting going over a status rather than digging into the weeds. It'd be more feasible working through a tool that documents and records information onto the initial record.

Thanks.

[UKVIKING]

Yes,
it should sort of run like a CAB

The PM should be there and the representatives of the areas that can raise the PM requests

The meeting should be short and quick,

Any new items ?
Yes
Discuss from the representative about the issue / PR Request
PM team rep for that area
If it meets criteria, then announce it has been accepted. Diarize it
Number it and start the team that is working on it
NO CLOSE DATE or SLAs are LINkED TO the solution

go through the new ones
Comment on the in progress ones only if there is negative news or delays
such as
PR \45 requires involvemnet of vendor - blah - who has taken the issue and will report back when they have an answer. We will check for update in 2 weeks
or
PR \93 requires a test environment which has to be built to recreate the error..

End with the closed (cause found), closed (solution developed and handed to testing) and closed - to Production CAB
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[KenLuo]

In my organization, the problem ticket should only be raised by incident team or problem team itself, because

1) Users should only raise incident tickets, but never problem.
2) The problem should be recognized by incident support when dealing the issue multiple times.
3) For proactive actions done by problem support, they can create the problem ticket to track.

Also when a problem ticket is created, incident support should create some links and tell requester.

This tells you who should create the problem tickets.

Secondly, in my organization, there is a published template which lists all the criteria for a problem creation.

The problem would be reviewed by problem manager and if it is accepted, it would be assigned to PO.

i believe this is also documented in ITIL.

Now it comes to you what are those criteria? This is something you need to review with PM.
_________________
Luo, Tian-Hong (Ken)
Regional Operation Lead

ITIL Expert Certified