Incident Management and Releases

[SD]

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?

[dboylan]

[Ziad]

The best approach is to find a workaround and close the incident, while keeping a problem record open until the rollout of the release.

Keep in mind that the objective of Incident Management is to get the Service Back to normal funcationality as soon as possible, while problem management is not bound by time limits.

Cheers,
Z!

[goitilcouk]

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

[Cekir]

The initial post states explicitly that no workaround is available.

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

[UKVIKING]

Cekir,

The incident should be closed when the service has been restored.

The problem should be closed when the root cause has been found and a decision has been made on whether to correct it.
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Cekir]

[UKVIKING]

Cekir,

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)

Change Management is POWER & CONTROL. /....evil laughter

[Cekir]

Let's have a scenario:

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]

Thanks Christopher for the incrementals

When problem mgmt recommends a RFC, the problem should be classified ' RFC raised' so as to identify that the solution is being discussed

if the CAB (8) accepts and 9 happens, and 11 confirms that the problem has gone away the problem record should be closed with some sort of indication that the rfc fixed the problem

if the cab (8) declines the change due to $$$ or what ever, then the problem should be classified closed RFC rejected
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter