ITIL Change Management Process, Roles and Responsibilities : ITILNews.com

ITIL Change Management Process, Roles and Responsibilities [3 comments]

The ITIL Change Management process is comprehensively described within the official publications, but within this article we attempt to provide a high level overview of the stages of the Change Management process, the various roles that need to be undertaken at each stage and also details of the responsibilities.

The article does not stipulate interactions with other ITIL disciplines such as Configuration Management, nor does it go into operational details such as what may be included on a Request for Change (RFC) form.

As part of a series of articles ITILnews will expand on the process described and based on practical experience will include details around 'governance'.

We welcome any feedback and knowledge that you are prepared to share.

ITIL Change Management Process Roles and Responsibilities

3 VISITOR COMMENTS

2012-02-15 by "femi.olawoyin"

The process highlighted here makes a lot of assumptions that are not clearly called out.

In general, change requests go through 3 main goalposts:

-Initiation
-Approval
-Implementation.

The approval process is when the Go/No Go decision is made. Post-implementation, verification is done (ideally in a controlled environment) before the change is 'released' to the production environment. This flow here either assumes that all these steps are implemented in a controlled environment (where back-out can be implemented with minimal or no impact on production) OR disregards the need for such a critical control step. It is expedient to point out that change implementation and validation should be done in a controlled environment BEFORE production access is granted (either the system should be 'locked down' during the change implementation window or access disabled while the change is being implemented AND verified).

The critical requirements for change implementation must be:

1. All changes MUST be approved BEFORE implementation (except for routine/standard changes that are already pre-approved and follow a set path)

2. Impact assessment must be done at a higher level than that of the person implementing the change

3. Changes must be verified in a controlled environment BEFORE release to production

4. Changes should never be implemented without clearly-validated rollback/back-out plans

It is expedient to build these best practices into flows in order to minimize the potential for production 'disasters' due to change.

Finally, the Change Initiator (not the Change Manager) should be the one closing out the change request. This person is the final point of verification that confirms changes have been implemented as requested OR agreed (in cases where there are modifications to the initial request).

Reply on 2015-03-17

Agree with points 1 - 4 above. I also agree that a Go/No Go decision should be made AFTER the implementation and backout plans have been completed and documented - its ridiculous to have an approval BEFORE this stage, what are you approving? If it got to raising a change record then the 'assessment/validation' of the need for change has already been made.

I also believe the Change initiator/implementor 'completes' the change and the Change Manager 'closes' the change following the PIR.

2013-03-27 by "Scott01"

The Change Process in of ITIL is probably one of the most disputed and contradicting processes in ITIL.

I agree with the previous comments with a couple of exceptions:

You're wrong with the go/no go comment. The flowchart has it right where it should be. An Approval does not necessarily result in an overall go/no-go. Some changes will fall apart in the engineering or build phase so putting the go/no-go before this phase has the potential of changing a preapproved go to a no go, what would be the point...

For some there may only be the 3 main goalposts (Initiation, Approval, Implementation) but for others they would include "Plan & Schedule" some people have huge global networks that can take months to get one approved change past the scheduling phase. For some crazy reason people across the global on the same network can never agree on an acceptable outage time to install the new changes

Only the Change manager should close the change request. The change manager follows and tracks the change through the entire process (not the initiator). But part of the due diligence of the Change Manager before closing the ticket is to coordinate with the initiator and make sure everything has been accomplished per their request (basic customer service skills).

Reply on 2014-05-25

In my company, one of those global networks Scott was talking about, the change manager will generally touch base with the requester to ensure everything was completed properly and then ask permission to close the change. Unfortunately this is not written into the policy and is a done as a courtesy.

2015-02-23 by "gunjan.genius"

Please could you highlight the process of approving the change ?

Key points which a chnage manager should take care of while approving a CR ?

Reply on 2015-03-09

The key points which a change manager should take care of while approving a RFC are provided in the third coloumn of the diagram contained within the article.

There are 3 comments awaiting user validation. There are 2 comments awaiting publication.

YOUR COMMENTS...

Please submit any comments you have about this article.

Your feedback will help add value to the content for other ITILnews.com visitors and help us develop the content for the benefit of all.

You will need to provide and verify your e-mail address but your personal information will not be published or passed on to others. To identify each post we take the part of your email address before the @ sign and use that as the identifier, so if you are john.smith@itilnews.com your post will be marked "by john.smith".

NB: We respond personally to every post, if it calls for it.

If you prefer to respond without posting your comment please use our contact form.

Click the REVIEW button below to preview your comments.