Problem Management Documentation

[Curby]

Our problem management Severity One documentation is currently over 20 pages. I have been requested to create an Executive Summary in hopes that we can get people to read and use the documentation. In the currently documentation there is alot of duplication. We will have information in verbal and graphical. Which is more effective in this type of document?

[m_croon]

Hi Curby,

Allow me to make a little guess: have you made a distinction in sev1 events regarding different platforms (Wintel/Ux) / services / clients? Is there any possibility you can decrease the number of pages by going for a more generic approach?

In my experience, a combination of graphs and text works best. Graphs never extending the size of 1 page.


Michiel

[Fabien]

Michiel is pointing out an important thing here. Your Sev1 doc is something that should be digested by anyone who could come across one, which means it must be lean, efficient, and take into account that people hate reading... Reduce to bullet points only, use graphs and diagrams, make it one 4' by 3' poster if necessary.
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek

[Globis]

I'm a little unsure of what you're refering to. Do you mean the severity (priority) rating applied to an incident in incident management, or do you mean the severity rating of a problem after carrying out e.g. Pain Value Analysis?

If you did mean problem severities, then mirror the way you define incident severities. After all the way you handle a problem is driven in the same way as you handle an incident, i.e. the effect on the business.

If you meant incident severities, and if Michiel is correct, i.e. your incident severities are differently defined per service, you are on the road to disaster. Your service desk will never cope effectively at supporting more than a few services. Documentation will become too detailed to be useful (as you've found out), and therefore redundant. Processes will be confusing and hard to carry out accurately, especially in a pressured environment such as the Service Desk.

Define one set of Severities (or priorities according to ITIL, although personally I think severity is a much better description), and apply them to all services.

These should be described in terms of impact to the service (business), and describe things like handling process, target resolution time, escalation path, reporting required etc.

No more than one A4 page should be required per severity, and there is no need for more than 4, maybe 5 severities.

For example:

Severity: One (aka Critical)
Impact: Total loss of service, business severely affected
Target Resolution time: 1 hour
Escalation path: Service Manager -> CIO -> CEO
Reporting: Update every 30 minutes to requestor
Process: ** short generic description of handling process + flow chart**

Each service will be restored differently, but those details do not need to be reflected in the documentation for severities.

This is equally valid for problem severities, certainly the rating and impact should be the same. Resolution time, Reporting, escalation path and process will be different as the driver here is to find the root causes and fix them, rather than get the service restored ASAP.

Dave