Retrospective change request

[Dilberts_cousin]

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!

[Ed]

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."

Regards

Ed

[scrufmonst]

Dilbert,

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

Regards

scott

[Mark-OLoughlin]

Hi,

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

[Timo]

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.