Problem Categorization and Prioritization
The severity and impact of the problem need to also be established. All problems are important to the user, but problems that affect large groups of personnel or mission critical functions need to be addressed before those affecting 1 or 2 people.
Does the problem cause a work stoppage for the user or do they have other means of performing their job? An example would be a broken link on a web page is an incident but if there is another navigation path to the desired page, the incident’s severity would be low because the user can still perform the needed function.
The problem may create a work stoppage for only one person but the impact is far greater because it is a critical function. An example of this scenario would be the person processing payroll having an issue which prevents the payroll from processing. The impact affects many more personnel than just the user.
Priority Determination
The priority given to a problem that will determine how quickly it is scheduled for resolution will be set depending upon a combination of the related incidents’ severity and impact.
| Problem Priority | Severity | ||
| 3 – Low Issue prevents the user from performing a portion of their duties. | 2 – Medium Issue prevents the user from performing critical time sensitive functions | 1 – High Service or major portion of a service is unavailable | |
| 3 – Low One or two personnel. Degraded Service Levels but still processing within SLA constraints. | 3 Low | 3 Low | 2 Medium |
| 2 – Medium Multiple personnel in one physical location. Degraded Service Levels but not processing within SLA constraints or able to perform only minimum level of service. It appears cause of incident falls across multiple functional areas. | 2 Medium | 2 Medium | 1 High |
| 1 – High All users of a specific service Personnel from multiple agencies are affected. Public facing service is unavailable Any item listed in the Crisis Response tables. | 1 High | 1 High | 1 High |
Workarounds
In some cases, it may be possible to find a workaround to the incidents caused by the problem – a temporary way of overcoming the difficulties. For example, an SQL script may be manually executed to allow a program to complete its run successfully and allow a billing process to complete satisfactorily. In some cases, the workaround may be instructions provided to the customer on how to complete their work using an alternate method.
These workarounds need to be communicated to the Service Desk so they can be added to the Knowledge Base and therefore be accessible by the Service Desk to facilitate resolution during future recurrences of the incident.
In cases where a workaround is found, it is important that the problem record remains open and details of the workaround are always documented within the Problem Record.
Known Error Record
As soon as the diagnosis is far enough along to clearly identify the problem and its symptoms, and particularly where a workaround has been found (even though it may not yet be a permanent resolution), a Known Error Record must be raised and placed in the Known Error tables within CRM – so that if further incidents or problems arise, they can be identified and the service restored more quickly.
However, in some cases it may be advantageous to raise a Known Error Record even earlier in the overall process – just for information purposes, for example – even though the diagnosis may not be complete or a workaround found.
The known error recordmust contain all known symptoms so that when a new incident occurs, a search ofknown errors can be performed and find the appropriate match.
Major Problem Review
Each major (priority 1) problem will be reviewed on a weekly basis to determine progress made and what assistance may be needed.
The review will include:
- Which configuration items failed
- Specifics about the failure
- Efforts toward root cause analysis are being taken
- Solutions are being considered
- Time frame to implement solution
- What could be done better in the future to identify the issue for earlier correction
- How to prevent recurrence
- Whether there has been any third-party responsibility and whether follow-up actions are needed.
Any lessons learned will be documented in appropriate procedures, work instructions, diagnostic scripts or Known Error Records. The Problem Manager facilitates the session and documents any agreed actions.
Related links
Recent Blog Posts
Pre-register now!
GroupLink ITSM Problem Management’s beta release is scheduled for Q4 of 2021. Fill out the form below and we’ll you know when it becomes available.