Roadmap: How to Adopt the Formal Change Management Practice
This roadmap describes how to adopt the Formal Change Management practice.
Main Description

Getting started (small deployment)

Most organizations have change control environments available that can be adopted and adapted for a project's use. The key considerations for a project are:

  • What work products and kinds of changes are controlled by the process? Requirements? Project plans? Baselined implementations? See Example: Types of Changes.
  • What kinds of changes, if any, can be done outside of this process? Corrections to typos? Minor defect fixes? Who decides? Determine if there is a need for a streamlined "fast-path" process for small, low-risk changes.
  • What types of change requests should you manage: defect, Enhancement Request, new feature?
  • Who participates in this process (who can submit, who can approve, and so on)?
  • How often are changes reviewed?
  • What metrics are needed? How are they used?

A good rule of thumb is to have as much formality as you require, and no more. Generally, it is most efficient to minimize formal change control to highly visible features, and allow the project team to manage lower-level details with a minimum of overhead.

Getting Started (large scale deployment)

If the scope of adopting change control is a multiple-project, multiple-organization effort, or if a major tooling purchase is required, then you may need to treat the roll-out of the process as a project in its own right. The following are considerations that may apply.

1. Scope

The first step is to define the scope and the boundaries of the change management process. In addition to the questions applicable to small deployments, consider the following:

  • What kinds of work products are mandated to be controlled by the process? Which are optionally controlled by this process?
  • What kinds of changes, if any, are mandated as part of the process?
  • Who participates in this process?
    • Is it open to customers and partners (affects architecture, security, and licensing)?
    • Who are the stakeholders and the users? Will the process be used by all of the departments in the organization? Will it be used for all of the products? Who in the organization will be able to view the status of requests and projects as they are analyzed, prioritized, designed, developed, tested, and deployed?
    • How are resources allocated? Is there a separate project office that needs to be involved in the process?
  • What standards, if any, do you need to comply with, such as Capability Maturity Model(R) Integration (CMMI) and the Sarbanes-Oxley Act(SOX)?
  • Does the change management environment need to integrate to other systems (version control, build management, help desk, and so on)?
  • What metrics, if any, are mandated? How are these metrics used?

2. Requirements

  • Based on the defined scope, define the requirements for the process. Make sure to cover the needs of both the stakeholders and the users.
  • Agreement on the requirements and priorities must be achieved with all of the stakeholders.
  • A sponsorship of CxO level will help to solve disagreements.

3. Architecture

  • Architecture (database, Web server, integration, and so on).
  • Change types, work items, stateless record-types (for BOM). The best way to describe this is in a class diagram.
  • Data. The best way to describe the data is as attributes of classes (if there are no special requirements, start with the basic recommended fields).
  • Workflow. The best way to describe this is as a state transition diagram or activity diagram (consider Unified Workflow for all changes, or private for each change type).
  • Roles (actions allowed, fields allowed).
  • Integrations (How to integrate? API, import/export, e-mail).

4. Implement

  • Build and customize the schema.
  • Test and interact with power users.
  • Document the process (tailoring this practice can be a good starting point).

5. Transition and Deploy

  • Installations servers and clients (if relevant)
  • Configuration
  • Acceptance tests
  • Legacy data import and cleansing
  • Training
  • Mentoring
  • Ongoing fixes and enhancements

Common Pitfalls

Too much process
The overhead of the change process is much greater than the effort required to just make the changes.

Too little process
The results of too little process are incomplete changes sets. Incomplete change sets can result in additional defects and project scope creep, which in turn can result in missed deadlines.

Lack of agreement on, or understanding of, the process
When stakeholders do not understand or agree with the process, the results can be dashed expectations and conflict. When development teams do not understand or agree with the process, then developers are more likely to bypass the process.

Inadequate tool support
When there is inadequate tool support, users are more likely to abandon the proecess due to the difficulty of managing, navigating, and finding information.

Change management is disconnected from configuration management
When change management is disconnected from configuration management, it becomes impossible to determine the proper configuration that implements a change, and to identify which changes are in a configuraiton.

More Information