Many organisations struggle to make Problem Management work effectively.
For me there are a number of reasons for this – many to do with getting the right people to do the right job.
One key area which is vital to develop for this is reporting, particularly to start to really identify underlying causes and trends – e.g. for incidents. If you close your incidents off against the initial (logging) categories that you’ve used to identify the incident, you may miss the reason why the incident actually happened. So closing against ‘software’ may be useless to you if the cause was actually a user or 3rd party error.
So it’s important and useful to use separate ‘closing’ categories or ‘causes’ for logging categories or impact etc. – these are different things.
Here is a suggested list of closing or ’cause’ codes to help you to identify trends and make some sense and provide MI around root cause etc.
- existing issue, fault or request known, with a workaround to maintain service
- no relevant process
- process not adequate
- governance – process not followed
- Skill/knowledge issue
- Availability issue
- 3rd party system issue
- environment issue
- user error
- training issue
- Policy issue
- xxx as required
- password reset
- access issue
- operating systems failure
- xxx as required
- design issue
- build issue
- test issue
- service introduction issue
Contract/Commercial Issue Information
- technical information given
- ‘how to ‘ question answered
Request or Order Fulfilled Cause Unidentified
- service resumed, cause unknown
(Optional to be used by limited SD people only) usually should be passed to problem management, but in some cases the cause is unknown. To be used with care and to avoid having ‘other’ as an option.
How effective is the reporting in your area of influence right now?
Are you already using causal closing codes?
Do they work for you and if so, which ones in particular?