Posted: Tue Dec 18, 2007 8:38 pm Post subject: Retrospective change request
Hello everyone! I am quite new to ITIL and I wanted to get some opinions on an ITIL standard, as I have conflicting views to our CAB.
Our IT department is in the process of introducing ITIL standards. While this is a good thing, I feel that the designers of our system have been a bit "artistic" with some definitions and have basically made something up.
I am aware of what a change request is (obviously)
I am aware of a retrospective change.
I do not accept that there is such a thing as a "Retrospective change request" though. Their thinking behind is that it is a way of logging all changes in the event of emergency unplanned downtime, which sounds great to me. But they insist that this is a perfectly acceptable ITIL approved term. My question is simply "IS IT?!?"
I may be just arguing over wording, but exact wording is very important as far as I am concerned. Any opinions welcome!
Joined: Feb 28, 2006 Posts: 411 Location: Coventry, England
Posted: Tue Dec 18, 2007 10:13 pm Post subject:
We also have Retrospective Change Requests - Logic is:
A Request For Change (RFC) is the document/starter for a Change to be initiated in the system(manual or electronic).
In order to facilitate speedy / timely correction/fixing of a system outage ITIL recognises the need to complete documentation retrospectively. In other words, fix the problem, then document it.
In this scenario you have a Retrospective Change Request.
I quote from the V2 Service Support CD Chapter 8.5.11
"It may not be possible to update all Change Management records at the time that urgent actions are being completed (e.g. during overnight or weekend working). It is, however, essential that manual records are made during such periods, and it is the responsibility of Change Management to ensure that all records are completed retrospectively, at the earliest possible opportunity. This is vital to ensure valuable management information is not lost. An example could be the updating of an attribute defining 'success', 'failure' or perhaps 'partial failure' of a Change. The updating should be carried out by the person responsible for applying the Change, and should happen no later than the
Post Implementation Review - and perhaps with the cooperation of the project team, Release or applications software development manager."
Posted: Tue Dec 18, 2007 10:23 pm Post subject: Retrospective change request
Ed is correct in his assessment you can have a change that is to implement a quick fix (to get the system back on its feet) but after the fact you HAVE to do the due diligence of documentation.
Also, just a point of fact, ITIL does not have standards it is a framework of best practices.......if Standards are to be applied to ITIL than those Standards would be ISO 20K. Yes, common language is esstential to any broad scope business change, keep your head up and good luck
yes you can have retrospective changes. Ensure you have them only for emergencies and also that you have a time period for when they have to be logged e.g. 24 hours after the change and no later. _________________ Mark O'Loughlin
ITSM / ITIL Consultant
Joined: Oct 26, 2007 Posts: 295 Location: Calgary, Canada
Posted: Thu Jan 03, 2008 3:02 am Post subject:
Agree with all the above posters. The only thing I wanted to add is that somebody should be accountable and have it in their job responsibilities that all such changes are recorded within certain period of time.
Make sure it is ONE person who has to ensure that happens, otherwise, it won't get done.
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...
Joined: Sep 16, 2006 Posts: 3527 Location: London, UK
Posted: Thu Jun 12, 2014 4:31 am Post subject:
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
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.
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