A user called up the Service Desk stating that his LAN password is locked out. The Service desk advised the user to ask his manager or collegue to raise a request ( basically a pre-approved standard change) and a new password will be sent to him. He did that and got a new password within half an hour. He called up again for the next day and the same workflow was followed. The Service Desk doesn't log incident for password reset as its considered as degradation of users' memory and not as system's issue. However, the changes happening to the user's account was failing and there was something with his account which needed an investigation.

In this case there is no links between Incident Management and Problem Management but between change management and problem management. The recurring nature of the issue invoked the problem management to find out the underlying root cause of the account getting locked frequently.

By this simple example, I am keen to understand the link between the change management and the problem management. For example, a change is raised and approved for certain enhancement ( not bug fixing) and the Incident Management was never involved in it. After carrying out the change it was classified as failed change with no effects on the user. Can the problem management be invoked at this stage to find out the underlying root cause of failing changes? I would assume yes, it can be but can a problem record be opened for a failed change. I mean to think of the role of problem management without any incident management in place. The problem management comes into picture not due to recurring incidents but due to recurring failure of changes.

Firstly, you are not logging calls to the service desk if they are perceived as "user error/incompetence". I would consider this questionable because you will not see patterns that might indicate underlying problems. If there are frequent "user errors" then that indicates at least a poor match between the systems provided and the needs / capabilities of the users. Either you need to train the users better or provide better interfaces for them to use and probably a bit of both.

So you had to rely on noticing that the change was failing to help the user because you were blanking out the natural source for detecting this (i.e. your incident logs).

Secondly, you ask if a failed change could immediately be put to Problem Management to determine root cause of the failure. Well, the first point of analysis after a change has failed is to review the development and preparation and implementation actions to see if they went wrong anywhere. If that analysis comes up with an inferential conclusion that there is an underlying problem in the service (perhaps in a configuration item) then it is reasonable to invoke Problem Management.

By the by, if a user had his password locked out, then the failed change had an effect on users and there was something amiss in the process that verified there was no effect on users.

Thirdly you oversimplify Problem Management to be a reactive process that responds to recurring incidents and wonder if it can be extended to recurring change failures.

Well, the reality is that you need neither an incident nor a change failing to identify a problem which requires attention. Not all problems come from incident management. There is no need for an excuse of recurring anything to invoke a problem investigation never mind recurring failures of a change. Anyway, I would have thought that your Change Manager would get well on top of that at a very early stage, probably before the second attempt failed in almost every case. Your Change Manager would drive an investigation that, as above, might lead to raising a problem in some cases.

Whereas it is reasonable and natural to look for patterns in incident occurrences, there should be so few failing changes that your Change Manager would be on the case without requiring any statistical analysis to help sort wheat from chaff.

My view is, stick to basics. Understand what a problem is in terms of damage or threat to services, rather in terms of relationships to Change or Incident, and deal with each one appropriately.

Understand what an incident is in terms of effects on service rather than on perceived source and record everything that affects service regardless of apparent cause.

Focus on service rather than on boundaries._________________"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

Thanks for your response and I didn't mean that the calls for password resets are not logged at all. They are logged under the category of 'service requests' as it is a request to unlock the account or reset the password. So, the detection is in place.

Secondly, I didn't intend to oversimplify problem management. The problem management is normally seen as as a solution to recurring incidents and this is oversimplification. My intention is to uderstand if the problem management service can cross boundaries to investigate into a failed change (ofcourse with zero involvement of Incident mgmt). I would not want the change manager to drive the investigation as the manager should have approved only a mistake-proof change. For me, a failed change should open a problem ticket ( nothing recurring, no chance given to the change manager). The problem management is required to find out what went undetected. In order to have a bigger role of the problem management in changes, the problem management should also be one of the approving bodies in the CAB. Just to let the audience know that proactive problem detection is done and rectified. They should have a say in go/no go. Please feel free to differ.

I'm not sure what you mean by "if the problem management service can cross boundaries". Problem management needs to have the scope of whole service in order to pro-actively seek out issues and potential issues. Therefore, among other things, it should be looking at all calls your service desk receives irrespective of whether you label them as incidents or service requests or anything else. Whether incidents lead to 93% or 33% of your recorded problems, there is no special formal relationship binding Problem Management to Incident Management.

What I am about to say may seem a little unorthodox, especially for those who were never exposed to the original ITIL training back in the mid-90s.

I really like your example because it highlights issues that have wider connotations and it allows me to illustrate something I have said before in regard to certain other issues such as server reboots.

First let us look at password reset as change.

Of course it is a change, but of what? It is not a change to the infrastructure; it is not a change to the service. In fact if were put under the control of the customer and managed and performed by customer staff (and it could be), it would be a modification of data within an application. And that is how I would manage it within IT Services as well.

So it is controlled and managed and recorded and performed (by a Password or Access Manager) under strictly defined procedures but it does not impact on service management. In other words changes to passwords do not come under the remit of the Change Manager.

That is a kind of ideal position and not without its problems. For example changes to the process may well have to come under the Change Manager and probably even policy changes. But if you think of it that way for a minute you will see why you have to consider it differently from simple architecture or service changes.

Now, to get to your case, resetting the password, whether you consider it a change or not, did not fail. Therefore if it was a change it succeeded and the service request was honoured.. However the user did not experience restored access which was what s/he required.

Which nicely leads on to considering how the call was logged.

When the user first reported that s/he was locked out, that, for my money, was an incident plain and simple and should have been logged as such. The first diagnosis leads to a "standard" resolution for this incident. I. e. to go through proper approval channels to obtain a new password. This leads to a service request for a new password and should be logged as such.

The new password is provided and not long after the user reports that the problem has not gone away (or has returned). This is an incident (or is the same incident, or is an iteration of the same incident from some unknown common underlying cause). However you define it, it begins to look like there may be a Problem requiring attention.

At this stage I would expect Incident Management to start treating it more seriously and do a little investigation before advising the user to raise a service request for a password change. It might still be something very mundane and not worth going through a full formal Problem process to sort it. However if nothing shows and it recurs again you will have a clear pattern and Problem Management should be invoked to determine the cause and find a resolution.

The general assumption with password issues is that they are user-generated and that is often correct. but even if they are, that does not make it less of a problem. Whether it is a training issue or a poor user interface or a staff turnover issue or a complexity issue or whatever, it still is detrimental to service and even if the resolution (improvement) has to lie entirely within the customer's hands, the analysis needs to be done and the advice, guidance, assistance provided to remedy the situation.

If the above scenario goes away on the second reset, but similar events occur intermittently, then it becomes more likely that Problem Management will pick up on it before Incident Management, but again, this will be made easier by having logged the incident as an incident in the first place. That is not to say that Problem Management should not be looking at the frequencies of Service Requests of this or any other kind; this kind of analysis can identify all sorts of potential or actual problems.

I know this all seems a bit long-winded, but it need not be onerous in practice. For example if your users are encouraged to make password reset requests when they are locked out, then they will only raise an incident after their first request has not given them what they want and you will immediately know that there is probably something wrong.

I'm not trying to prescribe your processes, but simply to illustrate a way of thinking about the issue that gets beyond the labels. Perhaps a way to emphasise my point is to consider the situation in which password resets and changes are provided as an automated service that the user invokes at will. In this case it is even harder to think of them as Changes in terms of Change Management.

One final issue. There is no such thing as a "mistake-proof" Change in my view. The idea of keeping the Change Manager out of the loop for failed changes is not very practical. If the Change Manager has been derelict or negligent, that is an issue for performance review and audit, not for review of a failed Change, when his/her expertise is vital and it is unlikely that any direct blame accrues to any one individual, never mind the main man.

And another. Investigation of a failed change is not automatically a Problem although the investigation may well lead to the discovery of one in which case the process will raise it formally to Problem Management. Perhaps that is a better way for me to address your question about "crossing boundaries". It is not the role of Problem Management to review a failed Change, but rather to respond to the review if required._________________"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