Retrospective change request

Discuss and debate ITIL Change Management issues
Post Reply
User avatar
Dilberts_cousin
Newbie
Newbie
Posts: 1
Joined: Mon Dec 17, 2007 7:00 pm

Retrospective change request

Post by Dilberts_cousin » Tue Dec 18, 2007 5:38 am




User avatar
Ed
ITIL Expert
ITIL Expert
Posts: 411
Joined: Mon Feb 27, 2006 7:00 pm
Location: Coventry, England

Post by Ed » Tue Dec 18, 2007 7:13 am


User avatar
scrufmonst
Itiler
Itiler
Posts: 10
Joined: Mon Jun 25, 2007 8:00 pm
Location: Virginia

Retrospective change request

Post by scrufmonst » Tue Dec 18, 2007 7:23 am


User avatar
Mark-OLoughlin
ITIL Expert
ITIL Expert
Posts: 306
Joined: Thu Oct 11, 2007 8:00 pm
Location: Ireland

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

Mark O'Loughlin
ITSM / ITIL Consultant

User avatar
Timo
ITIL Expert
ITIL Expert
Posts: 295
Joined: Thu Oct 25, 2007 8:00 pm
Location: Calgary, Canada

Post by Timo » Wed Jan 02, 2008 12:02 pm


User avatar
Anushree
Newbie
Newbie
Posts: 1
Joined: Tue Jun 10, 2014 8:00 pm

Post by Anushree » Wed Jun 11, 2014 9:00 am

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!!

User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Post by UKVIKING » Wed Jun 11, 2014 2:31 pm

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
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

User avatar
ChangingMan
Itiler
Itiler
Posts: 27
Joined: Sun Apr 27, 2014 8:00 pm

Post by ChangingMan » Thu Jun 19, 2014 4:15 am

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.

User avatar
Sri368
Newbie
Newbie
Posts: 1
Joined: Tue Mar 14, 2017 8:00 pm

Retrospective change

Post by Sri368 » Wed Mar 15, 2017 4:12 am

Incident
Last edited by Sri368 on Wed Mar 22, 2017 7:07 am, edited 1 time in total.

User avatar
UKIT
Senior Itiler
Senior Itiler
Posts: 50
Joined: Tue Sep 25, 2007 8:00 pm
Location: England

Post by UKIT » Fri Mar 17, 2017 5:44 am

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.

User avatar
Subhendu
Newbie
Newbie
Posts: 4
Joined: Mon Apr 10, 2017 8:00 pm

Post by Subhendu » Mon Apr 17, 2017 2:27 am

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?

User avatar
phy_lis
Newbie
Newbie
Posts: 1
Joined: Mon Jun 12, 2017 8:00 pm

Who should raise a retrospective change?

Post by phy_lis » Tue Jun 13, 2017 10:51 pm

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.

User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Post by UKVIKING » Thu Jun 15, 2017 2:55 am

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
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

Post Reply