At a time when many organisations are undergoing a significant amount of changes, most of the change managers still considering ITIL change management process is the only process dealing with the change. I believe holistic approach to change management starting with gathering business requirement and ending with deliver business value is the right approach to deliver a change to business. Change management customers do not interest in what internal IT processes are managing the change, and their only one concern is the result of the change request in operation environment, so change managers are finding themselves having to manage changes thought almost all ITIL processes to provide effective change management from the business point of view.

To provide a holistic approach to change management thought all ITIL processes it is essential to understand the change lifecycle. If there was a defined change lifecycle, maybe it could mimic the service lifecycle assuming develop new service is considered as a change. Although there is no standard change lifecycle, most of the change management specialists accept the following change stages.

Changes have ten lifecycle stages: Initiation, Evaluation, Planning, Authorization, Design, Build, Test, Deploy, Post Implementation Review and Close stage. Throughout this journey the change ownership, unfortunately, might move between different process managers and as a result the accountability will be lost.

Let’s go through the change journey to identify how the ownership can jump between different managers.

Initiation: Within initiation stage change will be requested by making a formal request for something to be changed. The change manager owns the change within this stage.

Evaluation: During the change evaluation stage the change will be assess through multiple methodologies such as risk analysis, and/or cost benefit analysis, etc… . During this stage the change could be owned by change manager or evaluation manager.

Planing: All change’s stages should be well planned so change authority can have a holistic view of the change and it is relation with the existing services and CIs. Most probable the change will be owned by transition manager, project manager for major changes during this stage and change manager for minor change.

Authorization: Change authority based on the evaluation result and change plan will decide to go forward or to reject the change.  In this stage, change manager we own the change again.

Design: Once the change is approved technical team will be carry out the change design so change might be owned by design coordinator, project manager or change manager.

Build: After design the change the practical work will start by building the change in real environment. And the change ownership will move again to release manager, project manager or change manager.

Test: Change should not be deployed before perform the entire required test. This test might be limited to UAT in minor change or through formal test process in major change. During this stage the change ownership will be jump to test manager.

Deploy: Based on the test result formal decision should be taken to whether go live or no. then deploy the change to operation environment activities will take place. During this stage release manager will own the change.

PIR: Post implementation review could be limited to end user survey, or through multiple activities depends on the nature of the change. Most probably the change will be owned by change manager.

And Close): Once the business side is satisfied with the solution provided, change to be closed. Finally the change ownership will back home to change manager.

Through this long journey of change the change moved through more than twenty ITIL processes and the change ownership changed more than seven times.

To overcome the dilemma of changing the change owner It is recommended that the change to be owned by transition manager or project manager from start to end.

However; the following list explains the potential processes required for deliver effective change management and why it is required during the change journey.

• Portfolio management process – required  in case of new service
• Financial management process – required for financial approval of the change
• Demand management process – required to justify the major change
• Business relationship management process – required to assess the major change and to collect business requirement.
• Design coordination management process – will coordinate the change design
• Service Level management process – to be consider during change design and during change authorization.
• Service Catalogue management process – to update the service catalogue within the new and modified service.
• Supplier management process. In case of outsource any of the change activities
• Security management process – to be consider during designing and authorizing the change
• Availability management process – to be consider during designing and authorizing the change
• Capacity management process – to be consider during designing and authorizing the change
• IT Service continuity management process – to be consider during designing and authorizing the change
• Change management process – most of the activities will be managed by change management within the minor change and to be coordinated within the major change
• Change Evaluation process – to assess and evaluate the predicted change performance and actual change performance.
• Asset and Configuration management process – to assess the change and it is relation to other CIs and any change will be deployed to CI.
• Release and Deployment management process – will manage the Build, and deploy the change
• Validation and test management process to manage the change test
• Knowledge Management Process. To update the learned lesson in PIR
• Transition planning and support management process – to plan the overall change and coordinate between different change
• Request fulfilment process – change request will be raised through request fulfilment process
• Incident management process – change could be trigger because of incident and incident to be monitor during PIR
• Problem management process – change could be trigger because of Problem and Problem to be monitor during PIR
• Event Management process – change could be trigger because of Event and Event to be monitor during PIR

In reference to the definition of change “change is the addition, modification, or removal of anything that could effect on IT service”. All IT activities are changes. so considering ITIL change management process is the only process dealing with the change is pure myth.

In nutshell change should be owned by only one owner from start to end and otherwise the accountability will be lost. This owner is responsible of coordinate the relationship with all ITIL processes and any other external process could be involved.

You Can Learn More About the ManageEngine Product Line By Going to manageengine.optrics.com

The original article/video can be found at Change Journey through ITIL processes