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
Relationships
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.
|
|