Page 1 of 1

Justification for separating incidents&problems in tool

Posted: Mon Mar 26, 2012 11:33 am
by nehemiah
Greetings ITILings

I've recently undertaken a new role to introduce problem management into a small rapidly growing IT organisation. I'm a practising problem management practitioner with seven years experience in this area, but this is the first time I've encountered such an ITIL-y challenged environment (i.e. non-existent). I'm confident I can bring about the necessary culture change within the company, but the major challenge I am facing is with the call logging tool, which has no ITIL functionality whatsoever.

The tool is made by an American company, and they readily admit to having no knowledge or concept of ITIL. There are, however, apparently plans to implement a change management module, which sounded promising at first, but they have repeatedly queried the necessity of a problem management module when I request such similar functionality. The challenge I am facing is justifying why it is necessary for them to implement such features. The management in my organisation are set on using this tool, but as already mentioned, they have no experience with ITIL, let alone problem management. Whilst they are willing to learn and are looking to me to lead in this area, I am having difficulty coming up with convincing arguments with regards to why we need a separate incident and problem section in the tool. My reasoning so far has articulated the following justifications:

Governance - no control at present over who can open / close a 'problem' (i.e. incident) record in the tool.
Best practice would dictate problem records have different fields and field values to incident records (the tool company have suggested a 'workaround' of using a series of user defined fields to overcome this, but in my opinion this is not effective and does not provide adequate control / functionality).
Reporting - difficulty to provide granular reporting on different ticket types etc.

...and that's the best I've been able to come up with. It's a bit embarrassing and I'm sure I'm missing something really obvious...but having separate problem management functionality in a call logging tool seems so obvious and sensible to me I've never encountered a situation before where someone queries what value it will add. I’ve scoured the internet and these forums, and can’t find a similar scenario recorded anywhere although I'm certain people must have encountered the same situation. Any assistance / suggestions welcome...

Posted: Mon Mar 26, 2012 4:01 pm
by Diarmid
Nehemia,

two things spring to mind.

Firstly, get away from the phrase and concept of "a separate incident and problem section". It just loses your ground. If they are offering incident management functionality accept that, but point out that they are not providing any problem management functionality. not only are the data requirements different, but, and even more so, the process flows are different between incident and problem management.

Secondly, try to sketch out the processes at this stage and then flesh in the steps you will need to take to extract for a two way flow of information between their incident management system and whatever problem management system you can devise.

To return to my first point, you compound the problem [sorry] by allowing their mis-perception of problem management space to breath. I suspect that their, probably unconscious, assumption is that problem management is an extension of incident management and that it consists of looking at it as merely a way of digging deeper into incidents with a view to prevention. This is plausible, but bad. To emphasise the point, if you had no incidents for a month, you still aught to be doing problem management every day.

Because, in the general run of things, most problem investigations emanate from the occurrence of incidents, many think that that is where it comes from but in reality problem management should be about looking to prevent incidents whether such have yet occurred or not.

Emphasise the parts of the process that are about mitigation and problem fixing and the way in which these have to be measured by non-occurrences. Emphasise the nature of value and cost in problem solutions, something that is rarely given more than a fleeting glance when resolving an incident because there is some urgency to restore service.

I'm toodling off now to watch telly.

Posted: Wed Mar 28, 2012 5:53 am
by abu1
I am in a similar position trying to establish a new problem process to be implimented in the company. the service desk software only had incident managment and the problems were recored and stored sepertaley. but now in the latest release they have inclded problem so we can work from them within the software rather than word documents..

It is still possible, hardest thing im finding is changing the culture of the people as they are used to doing it current way which involves no problem process at all.

Posted: Fri Mar 30, 2012 4:57 am
by nehemiah
Thanks for the feedback all.

abu1 - I definitely don't want to be using work documents :S

Diarmid - I worked through some process flows as per your suggestion and as a result identified some practical logistical issues that would be encountered when trying to squeeze a problem management process into the current tool functionality - so that's given me great ammo with which to go back to the supplier and whack them over the head with. Fingers crossed they'll take my comments on board!

Thanks again for your help - it's appreciated.

Posted: Fri Mar 30, 2012 7:23 pm
by Diarmid
nehemiah,

sounds promising.

They will probably try to offer some ingenious steps in their current product, but from your perspective workarounds(!) are not acceptable because you are giving examples and do not know how many more issues will surface when you go into detailed design.

I have known software companies who offered an incessant flow of workarounds for years and so the product was never satisfactory.