Joined: Jan 13, 2011 Posts: 2 Location: Perth, Australia
Posted: Thu Jan 13, 2011 6:25 pm Post subject: How much detail in the impelmentation plan
Just wondering how much detail is required in the implementation plan of Change Records.
There are discussion in my company that the implementation plan should be a step by step outline that anyone could pick up and follow and implement. Im under the belief that the plan should contain enough information that any authorised person (same skillsets) to make these sort of changes should be able to follow and implement with no issues.
Implementation plan is where Change passes on to Release Management.
Implementation plan should be a high level description attached to the RFC if possible and then Release Management would have to take care of detailed implementation including Release Plan, Build Guide (if needed), Release Instructions (step by step), Back Out Plan and Remediatin Plan.
It can contain more detail if needed.
If RM is not involved then details needed would be Deployment Plan (install), Backout and Remediation.
Joined: Sep 16, 2006 Posts: 3366 Location: London, UK
Posted: Fri Jan 14, 2011 12:45 am Post subject:
IT depends on the work that is being done, how complex and how many different teams are involved
For ex, a firewall change.
The network team should know how to login to the router, enable admin mode, edit the file, save and exit admin mode
So for a f/w chaneg, I would excpect and accept
login into router using admin privledges
However, if the organization is very A.R. (anal retentive), the imp plan may say
login into router using STD Router login process as noted in document 123 v2 dtd 1 jun 2011
The Change / Release manager want a synopsis / summary where they can be satisfied that the deployment manager knows who and how the work will be done
If the deployment manager does not know enough information to summarize that, we usually get a little A.R and ask for an itemized list by time frame and group
In addition, if the work requires coordination from different groups - system, network, application, etc - at different times, then the summary plan should higjhlight this and indicate areas where hand offs occur etc
This applies also when working ith 3rd parties
The CM / RM merely want to ensure that the people doing the work have a clue _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
I agree with what has been stated, in terms of it depends on the nature of the change.
For example - If we are talking about a standard low risk change then the implementation (in my organisation) would not be assessed by CM, however we would expect there to be a valid Imp plan which the techncial (or supplier) team can follow and is auditable.
For larger changes (i.e ones which CM manage) we have a set document which clearly states that:
"In the Imp Plan section of RFC record please include a full implementation plan of the work that has clear dates, timings and event descriptions from the scheduled to the end date, this must include any designated back out timings if applicable. If a detailed imp plan is omitted from the RFC then your RFC will be rejected. Even if there is a documented Implementation plan attached to the RFC, you must update the Imp plan field. "
So a more technical detailed plan can always be added to the RFC, however this is an aid, and is not considered as part of the assessment and approval of an RFC.
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