Practice: Formal Change Management
This practice explains what formal change management is, and how you can implement this practice in your projects.
Purpose

This practice is an explicit approach for controlling changes, including defining states for the change request artifact and tasks for transitioning the change request artifact between states. This practice is useful in a number of situations, including:

  • When there is a group of stakeholders outside the project team that needs to approve and verify certain kinds of changes
  • When a baselined work product is part of a contract in which changes need to be strictly controlled and approved
  • When changes need to be tightly controlled (such as late in an iteration or release cycle) for stabilization purposes

Risks of not having a change management practice

Without a change management practice, an organization risks encountering the following problems:

  • Difficulties in tracking changes (status of the change, which changes were entered into which release, and so on)
  • Delays in resolving issues and deploying changes
  • Duplicate effort or lost change requests
  • Requests that are not prioritized according to stakeholder needs
  • Hard to establish mechanism for measurement and improvement
  • Reduced quality of products
  • Higher costs to introduce changes

Reasons not to have a change management practice

Every organization and project should have a change management practice. However, there are some special cases in which you may not implement a change management practice. These cases are mainly related to cost and time constraints, such as:

  • A one-time project with tight schedules
  • A very small project that has some procedures already adopted
  • Distributed teams, with each team already using a different practice, and the project timeline does not permit the introduction of a unified practice


Goals

To ensure that all proposed changes are documented prior to installation in the production environment.

  • To ensure verification of technical completeness:
    • Accuracy of technical impact and risk analysis
    • Plans for final test and installation
    • Identification and review of all technical dependencies, including the effect on concurrent changes
  • To ensure that the timing of product change executions does not conflict with the business plans and priorities.
  • To ensure appropriate management involvement and approval, such as:
    • Required sign-offs (for example, justification, user acceptance, affected areas)
    • Approval, deferral, or disapproval of change installations
  • To ensure that successful testing is verified to the degree required by organization standards before introducing the change to the production environment (customer deliverables)
  • To ensure the documentation of actual change installations, enable communication of the change results, provide a history of changes, and support the maintenance of systems documentation
  • To minimize the adverse impact of necessary changes on system integrity, security, and the service-level agreements.
  • To allow the coordination and planning of changes in order to provide a stable production environment.
  • To maximize the productivity of persons involved in the planning, coordination, and implementation of "quality" changes.
Main Description

Change management is the process of planning and coordinating the implementation of product changes in a planned, authorized, logical, and orderly fashion. It does not develop changes, nor does it implement them.

Relationship to work item management

Most of the work in a project can be planned, assigned, and tracked by a project manager in collaboration with the team. This practice is not about assignments within the team, but rather about identifying particular types of changes and work products that require approvals by specific stakeholders, typically from outside the development team. Since these change requests are assigned and implemented, they are work items, but we call them out separately to emphasize that there is a separate enhanced process for managing them.

How to read this practice
The best way to read this practice is to first familiarize yourself with its overall structure, what it is in it, and how it is organized.
Additional Information
For more information on this practice,  see the practice resource page on IBM® developerWorks®.
Relationships