Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
NOTE: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
The Itil Community Forum: Forums
ITIL :: View topic - Is Change part of Critical Incident
Joined: Mar 31, 2008 Posts: 109 Location: North West England
Posted: Sat May 24, 2008 1:26 am Post subject: Is Change part of Critical Incident
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
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Sat May 24, 2008 2:00 am Post subject:
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
Joined: Oct 07, 2007 Posts: 441 Location: Jakarta, INA
Posted: Sat May 24, 2008 10:04 am Post subject:
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
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
Out incident and change processes have made provisions for just this situation and any emergency changes required to resolve the incident are discussed in the war-room before receiving verbal signoff from all parties involved to go ahead. This is documented within the incident ticket and a RFC is raised once the dust has settled.
The questions asked during the discussion phase are around impact, time to implement, backout plan and time to backout - the warroom is acting in the role of a CAB/EC. It's all been agreed on between the incident and change managers and is fully documented.
The change management process must be followed for all changes, regardless of whether they are planned or being undertaken in anger to resolve a live incident. It is the documentation of the change that can be done retrospectively.
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'.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum