Problem Management Process Health?

“HappiNess” studies IT Service Management with Edinburgh Castle in the background.

Everyone deals with problems but not everyone can measure how well they deal with problems. To measure you need a clear, shared Problem Management process.

If using a dedicated Problem Management function is new to you then the first challenge is identifying all the problems and known errors. Some problems will be well known – they are part of the collective knowledge due to the pain that they may have caused. However other problems surely exist. The niggly ones. Where are these all hiding?

It is a fair guess that you already are doing Incident Management alongside Request Fulfilment. You probably have a service desk and perhaps they have escalated technical issues to a background operator or team. The first place to look is for breached incidents, not yet completed, sitting with technical teams. When probed, it is likely that many of these 2nd line breached incidents are better characterised as problem or known error records. Unless policed, technical staff yet to embrace problem management will be storing Problems in Incident records. And because the user was given or found a workaround, the user is often unaware a ticket is still open in their name. The ticket sits as a techie’s someday maybe to-do task list.

The first stage of implementing a Problem Management process is to unpick the recording of problems under Incident Management !

How Urgent Are Problem Records?

At the start of the academic year (September) we have a Change Freeze to ensure service stability at this critical business period. And something interesting happened with engagement with Problem/Known Error records – the engagement went up! On reflection this makes sense.

Technical staff were under a Change embargo – having to be on standby to address any arising service issues. But the Change Freeze had the effect of ensuring service stability, so whilst service desk may have been very busy with request fulfilment, the number of Incident tickets as a percentage of workload fell and the percentage of tickets escalated to second line also fell. So incident load on second line was low and the workload on Change frozen and technical staff had some headroom to look at Problem / Known Error records.

The result was 20% of all Problem Management activity happened in September. And whilst more new problems were logged, the majority of the activity was progressing Problem records to a completed state.

Engagement with Problem Management Process – 2019

By identifying this we can plan for next start of academic year to really push Problem Management with 2nd line if we can replicate the service stability.

Surely Some Problems Are Urgent?

Absolutely. If the business is hurting because a Problem exists that Problem is urgent. And it will likely be accompanied by many incidents – possibly a Major or Critical Incident.

However once a workaround is in place, or the pattern of business changes and the effect is negligible, naturally attention is redirected to other priorities. So the Known Error (if there is a workaround) or Problem still exists. It just not exceeding a threshold, for now. (There is an assumption that low priority problems and known error are reviewed on a scheduled basis. )

Are Some Problems/Known Errors Are Too Big To Fix?

Yes. Some fixes require levels of resource that just is not available. Indeed Problem/Known Error Management is not about fixing! It is about first identifying a workaround, then identifying the root cause to suggest what change would be required to fix the issue. Actually doing the change is Change Management, and that is another post…