Is Change part of Critical Incident

[mnsmith]

My organisation is trying to develop a critical incident process and has left out anything to do with change management. As the change manager, I am trying to challenge this but am hitting a brick wall.

My colleagues are using ITIL/ISO 20000 definitions to convince me that incident management is about getting things up and running quickly and if there is need for an emergency change, the change management process can be followed up later. Therefore the change manager doesn't need to be involved.

My view point (also based on ITIL/ISo 20000) is that although emergency changes can bypass standard change rules, they still have to follow a pre-defined process, for example getting approved. I agree that the paperwork can be followed up later but the process needs managing, so the change manager needs to be involved in critical incident management, at least to be kept informed of any changes that are made.

My question to the forum is - who is right?

Thanks
_________________
Mick Smith
Change, Configuration and Release Manager

[Diarmid]

Mick,

there is some fundamental misunderstanding going on at your place. You can't manage anything retrospectively. Unless you have a TARDIS. Of course you can do paperwork afterwards, but Change Management is about ensuring the change is appropriate and effective and does not damage anything ... and does not cost too much.

I'm sure there was another thread went over this angle, but I'm too lazy to look for it just now.

Whether the Change Manager is actually present must depend on how your emergency change process has been defined, but SOMEBODY has got to manage the change following properly defined procedures, however urgent the requirement.

There are some simple questions that can be asked, such as "how do you ensure that your proposed change will not make things worse?", "How do you ensure that it is possible to back out of the change if it fails?"

Set up a string of this type of question and from the answers you can define th emergency change process - it must see to all the ensuring.
_________________
"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

[asrilrm]

Hi all,

Mick,
I see that the misunderstanding is whether to invoke CM process or not.
Your colleagues were right about bringing the service up quickly, but when it comes to a change, the CM process MUST be followed. The case is who is doing the CM process.
I quote the case of RFCs after office hour, where the Change Manager has gone home (remember the thread?). One solution is you can assign the Manager on duty and a "acting" CAB/EC consisting of engineers to take the roles in the CM process.

Of course, this is only by case and could not be defined as a standard procedure

Hope this could help

Cheers,
Asril

[BNZ_Incidents]

Mick,

Just to expand a little bit on Asril's post,

[Skinnera]

In conjunction with my Incident Management colleague, I have just proposed the following 'best practice' statement for my organisation;

- Where a service is completely down or extensively degraded (typically P0/P1) and immediate restorative actions are required, a CCR is not mandated; instead the actions may be detailed on the Incident Case at the discretion of the appropriate Incident Manager and/or Service Minder.
-- The exception is where the physical or logical configuration of any part of the service will be changed as a result of the restorative actions, in which case a Fault CCR linked to the appropriate Incident Case is mandated, and this may be retrospective at the discretion of the appropriate Incident Manager and/or Service Minder.

- Where a service is partially degraded (typically P1/P2) and immediate restorative actions are required, a CCR is mandated although to avoid delaying service restoration this may be retrospective at the discretion of the appropriate Incident Manager and/or Service Minder. It will be a Fault CCR linked to the appropriate Incident Case, and the content and potential service impact of the CCR will have been discussed and agreed by the Incident Manager and/or Service Minder prior to implementation.

- Where restorative actions are not immediately required (typically P2 – P4), a CCR is mandated; this will be a Fault CCR linked to the appropriate Incident Case and will have followed the standard Fast Track Change Management process for Fault CCRs.


Hope that helps? I think it line up with all the previous input in terms of making sure someone is managing/approving the content of the Change ahead of it being implemented, but allowing the pragmatic 'retrospective' creation of the paperwork/Change record.

FYI - a Service Minder is a senior member of the Service Management team who takes responsibility for 'owning' all the big incidents as a support layer above the IMs.
_________________
When I say 'CCR', please read 'RFC'.