ITIL Problem Management Question

Soldato
Joined
18 Oct 2002
Posts
7,507
Location
Maidenhead
Hi all,

We are currently introducing problem management in our organisation so our use at this point is limited.

We have identified that the security permissions on our file server are a mess and need to be changed. Should this be categorised as a 'problem'?

What are your thoughts?
 
dunno about this ITIL stuff but IMO that is a configuration issue and not bug/error etc.. and so the team dealing with bugs/errors ought to tell you to **** off if you raise it with them

might be best posting this in a different forum to GD though :)
 
I would only turn it into a problem if it is the sort of thing where you are going to get a bunch of calls every day all releated to that issue, so that you can link all the individual incidents to that problem
 
I would say no, my thinking is usually if a series of incidents occur that seem to be related then a problem record is raised.

More security related then problem management.
 
It all depends has someone raised an incident ticket about it? You can't have a problem unless there is a related incident, people often think it has to be a repeat incident but a problem can be raised in relation to any incident or incidents where a work around has been put in place but the root cause has not been resolved. This however sounds to me more like a service improvement piece than a problem management one.
 
It was identified by the datacentre team, so no users have logged an incident.

However ITIL says

"The unknown root cause of one or more existing or potential Incidents. Problems may sometimes be identified because of multiple Incidents that exhibit common symptoms. Problems can also be identified from a single significant Incident, indicative of a single error, for which the cause is unknown. Occasionally Problems will be identified well before any related Incidents occur."

It does however specifically say 'the unknown root cause'. In this example we know the root cause which leads me to think it's not a 'problem'.

edit: Actually, that's the V2 definition. The v3 is even more woolly

"A cause of one or more Incidents. The cause is not usually known at the time a Problem Record is created, and the Problem Management Process is responsible for further investigation."
 
if you arent getting incidents raised about just make a work order innit

if its just some faff that needs doing to change your server permissions -> work order
if it needs investigation and no known fix exists or you have a workaround to tell users -> problem

ITIL is just a framework so basically just do what ever you feel like at the time :p
 
Has an incident (or multiple incidents) been raised against the issue?

Remember, ITIL is a collection of best practice, not a rule book. Ultimately, whether the issue should be a problem or not relates to how your organisation implements ITIL. However, due to SLAs being associated with problems, most organisations won't raise a problem unless there are incidents also being raised.
 
Last edited by a moderator:
God I hate ITIL. It's like it was written by people who have no concept of logic and no one actually knows what the **** it's on about, so just pretend to and make it up as they go along.
 
Thanks for the opinions. I've been given the role of major incident and problem manager (with no previous experience of problem management). At the moment the senior managers seem to be classifying everything as a 'problem' so they can move the responsibility over to me.
 
God I hate ITIL. It's like it was written by people who have no concept of logic and no one actually knows what the **** it's on about, so just pretend to and make it up as they go along.

Me too, did the course 10 years ago and failed the exam because I found it boring and uninteresting. Been offered it again by my current employer to go on the course next week. Looked at the book and meterials over the past week. 10 years on and it's still boring and uninteresting. Not looking forward to next week.
 
Me too, did the course 10 years ago and failed the exam because I found it boring and uninteresting. Been offered it again by my current employer to go on the course next week. Looked at the book and meterials over the past week. 10 years on and it's still boring and uninteresting. Not looking forward to next week.

I know how this ends and I'd be looking for a new job if I were you. Or practice saying no a lot.
 
Yes it's a problem even if it hasn't caused any incidents yet. You should assign a problem manager and tasks to individual people/teams with target dates. Off the top of my head the activities would need to include:

Determine correct permissions / new standards

Review server estate to determine if they meet the standards and amend server permissions if required.

Review server commissioning process to ensure future servers adhere to the new standard

Review whether the "mess" has resulted in leaked permissions or leaked data and remediate them.
 
Me too, did the course 10 years ago and failed the exam because I found it boring and uninteresting. Been offered it again by my current employer to go on the course next week. Looked at the book and meterials over the past week. 10 years on and it's still boring and uninteresting. Not looking forward to next week.

I scrapped the foundation course mostly by guessing my way through lol

They want me to do the next 2, but I've been putting it off for 3 years and I'm going to book a Cisco course instead :P
 
Yes it's a problem even if it hasn't caused any incidents yet. You should assign a problem manager and tasks to individual people/teams with target dates. Off the top of my head the activities would need to include:

Determine correct permissions / new standards

Review server estate to determine if they meet the standards and amend server permissions if required.

Review server commissioning process to ensure future servers adhere to the new standard

Review whether the "mess" has resulted in leaked permissions or leaked data and remediate them.
Interesting, thank you. I'm not a fan of the v3 definition
 
I know how this ends and I'd be looking for a new job if I were you. Or practice saying no a lot.

I will be in 2 years. Thankfully I earned a MCSA in Windows 10 a few months back, paid for out my own pocket. Will be doing the same for Server 2016 starting in September. So any course work puts me on I don't care about because I know what direction I going in my career and taking the right steps to do so. :)
 
Thanks for the opinions. I've been given the role of major incident and problem manager (with no previous experience of problem management). At the moment the senior managers seem to be classifying everything as a 'problem' so they can move the responsibility over to me.

ITIL is a very good framework if places are willing to go all in.

Problem Management is basically the next step along from Incident Management. i.e known issues that keep cropping up, problem management is to remedy that.
If you like solving long term technical issues, or investigating them, you will have a blast in that role.

Major Incident isn't fun whatsoever though. It's basically whipping everyone to get a resolution to whatever your organisation deems to be "Major". Usually hassling 3rd parties to get off their arses and if you have SLAs in place, the pressure can be ridiculous.

You should kick the security permissions on the file server over to Change Management. There isn't a Problem, it's working as designed. Just designed very badly.
 
God I hate ITIL. It's like it was written by people who have no concept of logic and no one actually knows what the **** it's on about, so just pretend to and make it up as they go along.

Depends how it is taught. If you are taught how the cogs all work in the cycle using everyday practical concepts, you will dig it.

It's probably the most flexible and robust frame work in the business. People just switch off from it because they have a book chucked at them and told to learn it that way.

You can literally run any organisation using its principles, even without IT involved.
 
Back
Top Bottom