Print Page | Report Abuse | Sign In | Join
Is Problem a Problem?
Thread Score:
| 2
Thread Actions

12/06/2014 at 12:54:59 GMT
Posts: 15
Is Problem a Problem?

Problem Management, was one of the earliest Service Management processes and one that many organisations implement at the start of their service management journey. I might think that with all the wealth of experience and learning of Problem Management, it would be one of the processes that organisations have got licked.

Yet Problem Management is often the first name on a list of ‘what type of events would you like’ and it still a topic that generates lively debate – so much so, that there is a Twitterchat on 18th June at 20:00 BST dedicated to Problem Management as part of the ITSMF UK Big4 initiative.

So how good as we, as an industry, at Problem Management and what are the issues that prevent many organisations from making this process one that adds great value to an organisation?



P.S. all are welcome to participate in the Twitterchat. Delighted that Barry Corless, the chair of the ITSMF UK Problem Management Special interest Group will be leading the event.

Use the hashtag #itSMBig4 to follow and join in with the discussion – it will be great to have you on board!

Last edited 14 June 2014
14/06/2014 at 16:48:19 GMT
Posts: 4
I think that problem management is far more difficult than people assume. There is a lot of confusion and very few organizations are getting real value from it. This is a great pity as it can have a great ROI when it's done well.

I'll be talking to James Finister and Rob England about this topic on a BrightTalk webinar next Thursday at

14/06/2014 at 17:19:29 GMT
Posts: 15
Where is the source of the confusion with problem management?

14/06/2014 at 22:45:21 GMT
Posts: 4

There are many sources of confusion, often discussed on various social media platforms and I'm sure they'll come up again on the panel debate I'm planning with James and Rob.

People are confused about what problem management should be doing. Is it about Root Cause Analysis of problems, or about creating workarounds, or preventing problems in the first place, or doing trend analysis of incidents? If it is about all of these then how do you prioritise the work? There is also confusion about when to log a problem and when to log an incident for infrastructure failures. If a server has failed is this an incident or a problem? what if no users are affected? what if there are already lots of incidents logged by users?

Last edited 14 June 2014
15/06/2014 at 08:39:48 GMT
Posts: 15
The key, for me, is getting processes in place that work for the organisation and a clear understanding of scope, roles and responsibilities of Incident/problem - even if it differs from 'the books' and from organisation to organisation. For example does Problem Management in a particular organisation extend to non-IT issues? A lot will depend on the resources of the organisation, the maturity of the processes and the way that service management tools are used.

My thoughts on the situations above:

If a server fails then it should be logged as an incident, even if it was a simple fix. It does not matter if no users were affected. If there are future incidents of this nature then trend analysis should pick it up.

If there are lots of incidents logged by users as a result, then Problem management should be involved - as it is clearly costing the organisation time and money.

I think Problem is about all of RCA, trend analysis, creating workarounds, preventing problems etc. Prioritisation, if resources are tight, can be tricky but will depend on the damage to the business/customers - e.g. cost, reputation, etc.

16/06/2014 at 08:52:05 GMT
Posts: 1
I think there are 2 issues with approach to this
(1) A misconception that problem management will happen simply as a process, particularly if someone is then identified with it who becomes the owner and who is expected to fix all problems ('great, we've got a problem manager, sorted, I don't need to think about that any more')
(2) Lack of clarity and understanding around the role itself - both in terms of what its expected to deliver (ie clear objectives) and the sort of person that is needed to do it, particularly initially. Its not simply an admin function and it needs someone with some klout and the personality to make things happen

17/06/2014 at 14:21:38 GMT
Posts: 3
In my experience, there are many things that can go wrong with Problem Management in an organisation. Where to start?

1) Execs and Senior Managers need to understand and accept that Prob Mgt is not a tool to be used in a blame culture. Too often I have seen situations where the emphasis moves from "What went wrong and what do we do to correct it?" to "Who did what wrong, and what disciplinary action needs to be taken?"

2) In the same way that Incident Managers don't actually resolve issues and restore service, neither do Problem Managers identify Root Causes and implement the long term fixes.... all this work is actually done by the IT Technical resources, suppliers, third parties, etc. Inc and Prob Mgrs provide the facilitation, coordination and planning skills to make sure that service recovery and fix implementation is carried out in the optimum way and timescale, so as to minimise the service impact. To achieve this, they need to have the fully committed support of these resources and their management teams..... and this will NOT be found if these teams are in a blame culture as outlined in 1) above, looking over their shoulders, afraid to be honest about what's wrong in case they get blamed/penalised/(in extremis!) sacked for failures.

3) Both Inc and Prob Mgt also need to have full cooperation and interaction with the other Service Management disciplines - including, but not just - Change Management, Config Management, Business Service Management. Without these good relationships, you can find situations where the different areas are pulling in different directions, resulting in more service impacts and degradations, rather than less.

4) The relationship of Problem Management with the business itself - through the Business Service Managers - is also key. Too many times, I've seen long term fixes for Root Causes being delayed due to the lack of business priority, competing projects, etc. Sometimes, we need to remember the biblical story about a house built on shifting sands. If the foundations of a system are unstable, there's no point in business sponsored changes and projects being implemented before IT implement the fixes to stabilise the underlying systems and processes.

5) A point is made earlier about the business processes surrounding the IT service... if the Problem Management investigations find that these are inefficient or otherwise flawed, they need fixing just as much as the IT systems.

.... there's a start!

17/06/2014 at 14:23:16 GMT
Posts: 3
PS - sorry, I don't do Twitter, so won't be on the discussion tomorrow. I'd like to see the outputs, though!

18/06/2014 at 20:42:43 GMT
Posts: 2
How can I help?

18/06/2014 at 20:50:58 GMT
Posts: 15
Originally posted by P. Soutar:
PS - sorry, I don't do Twitter, so won't be on the discussion tomorrow. I'd like to see the outputs, though!

Paul, the Twitterchat discussion will be disentangled (as best I can) into the individual conversations and posted on Storify so that anyone can view it. I'll post the link once it is ready.

Premier Gate
21 Easthampstead Road
Berks RG12 1JS

Tel: 0118 918 6500

Fax: 0118 969 9749

Contact Us