Page 1 of 1

Retrospective change request

Posted: Tue Dec 18, 2007 5:38 am
by Dilberts_cousin

Posted: Tue Dec 18, 2007 7:13 am
by Ed

Retrospective change request

Posted: Tue Dec 18, 2007 7:23 am
by scrufmonst

Posted: Tue Dec 18, 2007 8:40 am
by Mark-OLoughlin

Posted: Wed Jan 02, 2008 12:02 pm
by Timo

Posted: Wed Jun 11, 2014 9:00 am
by Anushree
I am fairly new to itil. in an interview i was asked what retrospective change is.. i didnt know.. well i read the above comments.. so i now understand that it means... first fix the issue then document it. but what i want to know is.. even in an emergency, an ECAB is convened.. so does that not happen in retrospective change? or can somebody please explain me the process of retrospective change...

Thanks is advance!!

Posted: Wed Jun 11, 2014 2:31 pm
by UKVIKING
A Retrospective change - an example.

The company has a network which is managed by Cisco routers

The company finds out that the network is suffering several intermittent outages.

The fix is to upload a fix.
The problem is that the standard process is to test this fix in a test environment and then watch

The fix is NOT Guarenteed to solve the issue... but....

So the IT Mgmt gives the go ahead. It gets done
It fixes the problem

So the IT Mgmt has the network team raise the Change request... and get it scheduled for the next meeting

The reason it is a retro spective is that the time that is needed to approve an emergency change may be too long before the company's entire network shuts down

Posted: Thu Jun 19, 2014 4:15 am
by ChangingMan
Emergency changes, in my opinion, should be like Standard Changes with approval given in advance.

In fact emergency changes shouldn't even require any detailed information on the change record prior to being implemented. This can be added afterwards.

An Emergency Change should only be used to restore service or prevent an immediate outage to service.

Retrospective change

Posted: Wed Mar 15, 2017 4:12 am
by Sri368
Incident

Posted: Fri Mar 17, 2017 5:44 am
by UKIT
ChangingMan wrote:Emergency changes, in my opinion, should be like Standard Changes with approval given in advance.

In fact emergency changes shouldn't even require any detailed information on the change record prior to being implemented. This can be added afterwards.

An Emergency Change should only be used to restore service or prevent an immediate outage to service.
I wouldn’t be in favour of that as this is not about the re-categorisation of change types, but simply completing the formal paper work and processes at a later date.
From experience, a firewall change had to be made urgently in order restore service because an external supplier had moved one of their servers which involved changing the server’s IP address without giving us advance notification. Network operations spoke to the external supplier in order to obtain the new IP address, so that a change could be made to the firewall.
The network operations team discussed the change amongst themselves, (almost like a mini CAB) gave me the heads up and what they were planning to do, then successfully made the change on the firewall, resulting in the restoration of service.
An RFC was then generated to cover the work which was formally presented at the next CAB as part of the process.

Posted: Mon Apr 17, 2017 2:27 am
by Subhendu
Hi John,

The term " Retrospective change" is new for me, but after refering to your example, I feel.. tjis is same as " After the fact " change or " Post Facto " change.. is that right understanding?

Who should raise a retrospective change?

Posted: Tue Jun 13, 2017 10:51 pm
by phy_lis
A sample scenario:
Support that batch jobs for reading bounce back emails failed. Exchange team and InfoSec teams were engaged to drive recovery. Exchange team assisted InfoSec team to disable Symantec Mail Security feature in one of the Exchange server.

In this sample scenario, who should raise a Latent Change to document the recovery action during the incident?

It is required in my organisation that after the incident is resolved, a retrospective change should be raised to document the change done.

There are debates on who should raise the change. Support for failing service says they should not be the one to raise as they did nothing, while the resolver group is arguing that they are not the person either as the failing service should raise a change for them to do the fix.

Posted: Thu Jun 15, 2017 2:55 am
by UKVIKING
It does not matter in the long run

What you have is a spine problem - no one is willing to take any responsibility

Change manager included


The Change Management policy should state this clearly who raises Retrospective changes