I've had a look through previous discussions and cant see an exact answer to my question. Apologies if I am repeating anything.

I am currently trying to encourage my IT colleagues to include more detail in their RFC backout plans. Currently I am lucky if I get more than 2 lines of text! I go along the lines of "if you were hit by a bus tomorrow and your RFC had failed, we would need to be able to open your RFC and back it out from your plan". They on the other hand are fighting this as it they feel that if someone were to back out their RFC in their absence, it would be someone in their team and so 1 - 2 lines of information would be enough to tell them what to do.

I was just wondering what other people's thoughts were? and what stance you take in your roles as fellow Change Management, ITIL professionals?

It depends solely on what is the requirement from the change management policy and process.

The back out plan needs to be a statement or series of statements that indicate that there is a process - standard or otherwise - that will be actioned if there is a need to undo the work or restore to a previous version.

If there is a standard process - back up etc - then the change raiser needs to make sure the info in the CM form is clear enough to satisfy the CAB

It is one of those subjective questions that truly depends on the context_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

When asked how much details needs to go into any plan (Implementation, test, Backout, etc), I always use the line that, if the person responsible (e.g. Sysadmin A) were to get hit by a bus, there needs to be a sufficient level of details that an appropriate, equivalent resource (e.g. Sysadmin B) could pick up the plan and run with it.

Our approach is slightly different to those mentioned, I always say the more complex the change the more detailed the plans have to be.

One of our biggest challenges is speeding up change into the business safely without being seen as needless bureaucracy. If we ask for super detailed implementation and backout plans for simple minor changes then we run the risk of slowing the process down and giving Change Management a bad rep.