If it has been identified that a new release of an application is required in order to solve an incident within an application e.g. certain functionality is not working (no workaround in place) should we keep the incident open until such a time as the release has been rolled out - even if the application/software itself is up and running?

If it has been identified that a new release of an application is required in order to solve an incident within an application e.g. certain functionality is not working (no workaround in place) should we keep the incident open until such a time as the release has been rolled out - even if the application/software itself is up and running?

Yes. Since you have not restored the user's Service, the Incident cannot be resolved. In a perfect world, implementing the Release (if successful) will auto-magically resolve all the associated open Incidents. This of course will only work if your Incident and Release management systems are integrated.

Agree with Ziad (although it can be influenced by your organisational culture?)
We normally close the incident and advise the caller if a workaround is known and give them a time frame and contact of their IS Account manager if they want an update on the longterm fix.

A problem record is opened to keep track of the progress, Its also hand to hand over to problem management as they can dig in a bit further.You may find out that the error was known by the project team when it went live and was not declared as a project known error !

Alternatively it may be introduced as a result of a change, either was I would recommend moving it out of incident management and handing it over to problem

In such situation I would say you have both records - Incident Record and Problem Record which are led independently. The new release should resolve the Incident ASAP and the Incident Record should be there opened until it is resolved.
As for Problem Record, I would say it should go its own way. The Incident and Problem Management processes may or may not meet. When new release requested by the Incident Management is done, then the Problem Management should review it and check if it resolves the Problem (assuming the root cause has been found). If it does, then the Problem Record may be closed, if not, then the Problem Record stays opened and may generate another Release request.

It is of course costly, since we may need 2 Releases, then the Problem Management should work in the high priority mode to be able to define the release request before it is done. From the other side, the Release may be held for a while if the Service unavailability is not the critical thing. It may be held till the PM is able to generate the release specification it needs.

Anyway - The Incident Record should stay opened until the Service is back .

That is my opinion, would you disagree?_________________Krzysztof (Chris) Baczkiewicz
IT Standards Support
Eracent

No the problem record should be closed when the root cause has been found , solution figured out, solution scheduled to be implemented (RFC created)

Once the RFC hass been raised and follows the process through chsaneg management, the problem record/team should wait until the successful implementation of the root cause solution has been done and the new 'environment' tested successfully to determine if the problem can be closed

Note: if the root cause solution is upgrade to Windows XP vice Windows 98 or NT4 , once the upgrade has happened and a period of time has passed without the same incident showing up, the problem can be closed_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

1. The user reports the outage of the service,
2. The Service Desk opens the Incident
3. The Service Desk finds the Incident impossible to resolve on-line and passes it to the Second Line Support,
4. The Second Line Support detects the Problem and opens the Problem Record.
4a. The Second Line finds the workaround and closes the Incident
5. The Problem Root Cause is found,
6. The Solution is Figured out,
7. The RFC arises
8. The RFC is accepted and the change is scheduled,
9. The Change is made
10. The results of Change are monitored.
11. The Service is confirmed to work OK.

Now,

UKVIKING wrote:

The problem should be closed when the root cause has been found and a decision has been made on whether to correct it.

This is point 7

UKVIKING wrote:

No the problem record should be closed when the root cause has been found , solution figured out, solution scheduled to be implemented (RFC created)

This is point 8

UKVIKING wrote:

Once the RFC hass been raised and follows the process through chsaneg management, the problem record/team should wait until the successful implementation of the root cause solution has been done and the new 'environment' tested successfully to determine if the problem can be closed

Note: if the root cause solution is upgrade to Windows XP vice Windows 98 or NT4 , once the upgrade has happened and a period of time has passed without the same incident showing up, the problem can be closed

This is point 11

Assuming I misunderstood you previously and you meant point 8 instead of point 7, we still close the Problem record twice - in point 8 and in point 11.

Am I missing something?

Actually what we see here is the need of 2 statuses of the Problem record: "Done" and "Closed".

As a note - point 4a may appear or may not appear - just to be anchored to the initial post._________________Krzysztof (Chris) Baczkiewicz
IT Standards Support
Eracent