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

Change Request Management

Improve efficiency with David Bowman’s information management guidelines for data warehouse change request management

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 request management.

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 the 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 movement and data presentation environments, or involve operational and process modifications that affect multiple users.


What is Change Request Management?

Change management defines the processes required to initiate change,, analyze impact, authorize change request, develop change and release change into production.
Initiate Change
  • Should initiate a change through the submission of a change request;
  • Should be requested by any stakeholder, but is typically is initiated and submitted by one of the project team members who submits requests for changes relating to its area of responsibility e.g. the data integration team may initiate database change requests or change requests required to satisfy new or changed data sources;
  • 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.
Log Request
  • Should assign a change number to the change request, record request date, requested by, request name, and
    change manager name;
  • Should assign priority e.g the change initiator should assign a priority as emergency, high, medium or low;
  • Should add the change request and change log to the project documentation change request folder.
Analyze Impact
  • Should determine impact on existing documentation and configuration items e.g. requirements, architecture documents and/or software configuration items;
  • Should require review by development and/or production support teams to determine impact upon each area;
  • Should identify configuration items that are impacted by the change request e.g. if the request involves a change to a configuration item, then each configuration item that will be impacted shall be documented in the appropriate work sheet on the change request NB one worksheet should be created for requirements e.g. a list of all requirements that are under version control, architecture e.g. a list of all architecture and design documents that are under version control; data architecture e.g. a list of all documents that are under version control and/or all configuration items, data integration e.g. a list of Informatica and Unix configuration items, business intelligence e.g. a list of Micro Strategy Configuration Items; infrastructure e.g. a list of infrastructure configuration items; and
  • Should assign category e.g. the Change Manager, with input from development and production support team leads, should assign a change category as major, significant, minor; or standard.
Authorize Change Request Management
  • Should authorize standard change request e.g. standard changes do not require Change Management Team approval since they are automatically approved and move directly to change deployment;
  • Should authorize minor change request e.g. the Change Manager is responsible for determining if the change is minor and, if so, may approve it or submit it to the Change Management Team for review/approval;
  • Should authorize significant or major change requests e.g. the Change Manager is responsible for submitting all significant and/or major changes to the Change Management Team for approval who should vote to accept the change, reject the change; or escalate the change to senior management; and
  • Should log authorization e.g. the Change Manager shall update a  change log with the decision and the status date.
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 Process
  • Should plan production changes resulting from approved change requests;
  • Should build effective release packages for the deployment of one or many changes into production;
  • Should test 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 change in line with structured implementation guidelines.
Summary...

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.

This site provide information management guidelines for change request management.