Justification for separating incidents&problems in tool

Discussion on issues related directly or largely to ITIL problem management.
Post Reply
User avatar
nehemiah
Newbie
Newbie
Posts: 2
Joined: Sun Mar 25, 2012 8:00 pm

Mon Mar 26, 2012 11:33 am

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...


User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Mon Mar 26, 2012 4:01 pm

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.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
User avatar
abu1
Senior Itiler
Senior Itiler
Posts: 30
Joined: Tue Oct 25, 2011 8:00 pm

Wed Mar 28, 2012 5:53 am

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.
User avatar
nehemiah
Newbie
Newbie
Posts: 2
Joined: Sun Mar 25, 2012 8:00 pm

Fri Mar 30, 2012 4:57 am

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.
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Fri Mar 30, 2012 7:23 pm

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.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Post Reply