logo for information-management-architect.com
leftimage for information-management-architect.com

Change Management Methodology

Improve efficiency with David Bowman’s information management guidelines for change management methodology

This site is designed for Information Technology professionals who need to improve efficiency and require guidance and direction to help teams consistently produce error free results.

It provides information management guidelines for change management methodology.

What is change?

Change is defined as anything, hardware, software, system components, services, documents, or processes, that is deliberately introduced into the production environment and which may affect a service level agreement or otherwise affect the functioning of the environment or one of its components.

All changes falling under this definition should be managed by a change management methodology as changes may affect multiple users, potentially disrupt business-critical services, involve hardware e.g. servers or networking equipment or software modifications, affect data stored and hence the data management, data integration and data presentation environments, or involve operational and process modifications that affect multiple users.

What is change management?

A change management methodology i
ncluding release management best practices, should be established as part of the information management framework and all stakeholders need to be made aware of the importance of change management.

Change management provides a disciplined process for introducing changes into the production environment with minimal disruption to ongoing operations.

Change Management Overview
  • Should formally initiate a change through the submission of a change request following an approved change request management process;
  • Should determine impact on existing documentation and configuration items e.g. requirements, architecture documents and/or software configuration items;
  • Should establish a formal process for authorizing change;
  • Should plan the deployment of any change, which may impact the production environment;
  • Should manage the deployment of releases in a consistent manner with the least impact upon production;
  • Should conduct a post-implementation review to determine if the change has achieved objectives and whether to keep the change or back it out;
  • Should provide an authorization and tracking processes to ensure only approved changes are deployed;
  • Should require a configuration management process to assess the impact of change on all potential configuration items; and
  • Should require release management to package the changes for successful deployment with minimal disruption to production.
Change Management Scope
  • Should include requirement specifications;
  • Should include architecture and design documents;
  • Should include database objects;
  • Should include data integration code objects;
  • Should include Unix scripts;
  • Should include business intelligence code objects;
  • Should include infrastructure objects e.g. requests for new systems and/or improvements to existing systems and infrastructure;
  • Should include operations, i.e. changes that affect or improve day-to-day computer operations;
  • Should include the change management methodology i.e. requests for change to the change management process guide, and configuration management plan;
  • Should include security i.e. changes to the security processes  e.g. authentication or network security improvements; and
  • Should include support i.e. changes to the help/support desk process.
Change Management Roles and Responsibilities

Change Initiator
  • Should complete a change request;
  • Should submit the change request to the change manager; and
  • Should help the change manager complete the change request.
Change Manager
  • Should create a change management plan;
  • Should manage the activities of the change management process.
  • Should be involved in every step of the change process, from receipt of a change request thru the deployment of the change in the production environment; and
  • Should be ultimately responsible for the successful implementation of any change to the environment.
Change Owner
  • Should plan the release implementation, including developing implementation plans, and establishing the implementation schedule;
  • Should ensure that proper implementation training is provided to team members prior to implementation;
  • Should validate the deployment and, more importantly, the back-out procedures, before a release is implemented to the production environments;
  • Should create a release delivery plan;
  • Should provide technical leadership during release development;
  • Should coordinate release deployment activities; and
  • Should validate deployment and back-out plans.
Change Management Team

Should be a decision-making body that evaluates and votes to approve or reject change requests.
Release Manager
  • Should create a release plan;
  • Should manage the release process;
  • Should ensure user acceptance tests have been completed;
  • Should verify that training has been provided to the affected user community if needed;
  • Should validate the back-out plan;
  • Should stage pilot tests; and 
  • Should implement the full deployment of the release.
Documentation Coordinator

Should review existing manuals and make appropriate changes that reflect the modifications made to the production environment. 
Communications Coordinator

Should develop, update and manage the change communications plan.
Change Test Coordinator
  • Should contribute to the development of tests, manage the release user acceptance testing process, review the test results and evaluate how to handle failures;
  • Should develop a test analysis report at the completion of testing,  that should be used by the change owner and/or Change Management Team to decide whether to continue the release process.
Data Architect

Should identify which data architecture configuration items will be changed by the change request and estimate level of effort for the change

Data Integration Architect

Should identify which data integration configuration items will be changed by the change request and estimate level of effort for the change

Business Intelligence Architect

Should identify which business intelligence configuration items will be changed by the change request and estimate level of effort for the change


Change Management Process
Initiate Change
  • Should initiate a change through the submission of a change request following an approved change request management process;
  • Should be created by anyone who is involved with the project;
  • Should ensure that change requests are created with consistent quality and completeness; and
  • Should ensure that irrelevant requests are discarded.
Analyze Impact
  • Should determine impact on existing documentation and configuration items e.g. requirements, architecture documents and/or software configuration items; and
  • Should require review by development and/or production support teams to determine impact upon each area.
Authorize Change Request
  • Should establish a formal process for authorizing change; and
  • Should require the change management team to review the change request and vote on the changes according to predefined voting logic.
Develop Change
  • Should schedule the change according to business priorities, change pipeline, category, and priority;
  • Should appoint a suitable change owner according to the requirements of the change in terms of technology, size, priority, and category;
  • Should ensure that the change development process follows a recognized development life cycle;
  • Should conduct milestone reviews, with the participation of Change Management Team members, to ensure that each phase has been completed successfully; and
  • Should ensure that the change meets acceptance criteria before it is passed to the release management process.
Release Management
  • Should plan releases resulting from approved change requests;
  • Should build effective release packages for the deployment of one or many changes into production;
  • Should test transition to production release mechanisms to ensure minimum disruption to the production environment;
  • Should review preparation for the release to ensure maximum successful deployments; and
  • Should deploy the release in line with structured implementation guidelines.
Review and Monitor Release
  • Should monitor change after implementation into production;
  • Should review lessons learned from the deployment and document them for future benefit;
  • Should handle unsuccessful change implementations by backing out, considering further remedial changes, or using the “accept issues and continue” policy; and
  • Should close the Change Request and inform the initiator.
Summary...

A change management methodology provides a disciplined process for introducing changes into the production environment with minimal disruption to ongoing operations.

This site provided information management guidelines for change management methodology.