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)

Hi ChgLed,
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.

If this CM process is audited, all of your suggestions could possibly be failure in audit

ChgLed

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)

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