Posted: Tue Dec 11, 2012 5:43 pm Post subject: Process followed when issue occur during implementation
What is the best/standard process that needs to be followed if any issues are encountered while implementing a change?
For example we had a DR test change scheduled and during the test the ram module of one of the firewalls went faulty when rebooting the firewall. The ram had to be ordered and replaced by the external vendor.
Now in this scenario what is the process that needs to be followed?
One of the suggestions I received is to raise an incident and start the Major Incident Management Process.
Also should we give a chance to the implementing team to resolve the issue until the change window lapses or should we intervene as soon as an issue is encountered and take appropriate action?
I donít think rollback would be an option in this scenario.
In a normal work day if the ram goes faulty MIM process is initiated.
The difference here is we have already taken approval for the downtime and expectations have been set that the firewall will not be available during the change window. (Please note this is a secondary firewall, primary firewall is not affected)
As you are having the approved down time for the same, these may be three cases --
1) you successfulluy Replace the faulty RAM and complete your activity within down time window then it is your Change management process only.
2) You exceed the down time window but your business has approved the extension of the downtime, then also it will be Change Management.
3) You exceeded the downtime window and Business has not aprroved the Extension of Planned Activity, at That time you will require to log an Incident and start the Major Incident Procedure. The Incident will be logged by the time when Activity was supposed to get complete as per scheduled time.
Joined: Sep 16, 2006 Posts: 3407 Location: London, UK
Posted: Wed Dec 12, 2012 1:59 am Post subject:
If this CM process is audited, all of your suggestions could possibly be failure in audit
raise a retrospective change for the fault - yes i know it is secondary... yes i know it is durign a change window... but the work it self to fix the broken equipoment was not part of the change approved at the CAB
raise the retro and fix the secondary
present the retro to the cab
it is retro because it is fault fix - ie emergency under incident conditions...
now all this depends on your policy process and procedures _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Mar 04, 2008 Posts: 1893 Location: Helensburgh
Posted: Wed Dec 12, 2012 2:04 am Post subject:
If it is so impactful as to be a major incident. It is going to run far beyond your agreed downtime.
As John said, an incident is an incident. It does not matter that the customer might not be affected.
There is nothing retrospective about incident management.
You treat it as an incident because it is an incident. You don't decide afterwards whether it was an incident or not.
Among the many reasons for this are a) incident management is geared for dealing with it properly, including any issues with the vendor b)if it happened again the next week your incident team will know about it and, among other things, will recognize the need to start a problem investigation to try to avoid more repeats.
AS to when you fix it - like all incidents, as soon as possible, because you won't know how long it will take until it is done. Unless the DR test change is more important than the potential business impact. _________________ "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
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