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

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


Application
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®.