Guideline: Defining Practices for Configuration and Change Management
This guideline provides considerations for defining practices that projects will use for configuration and change management.
Relationships
Main Description

Change Management and Configuration Management are closely related process areas. 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. Configuration Management is the process of controlling and synchronizing the evolution of the set of work products composing a software system

In order to understand the impact of changes and to plan for verification, change requests must identify which versions of which artifacts were affected by the change. A common problem with stand-alone change management practices and tools is a lack of traceability to the affected configuration items. For this reason, it is critical to integrate your Configuration Management and Change Management processes.

Change and Configuration management are also related to Product Integration. The purpose of this process area is to incrementally assemble the product from its components, ensuring that the integrated product functions properly. Milestone builds and releases must have traceability to all implemented changes and their associated configuration items.

Reference the following typical activities and key considerations for these three process areas as you define practices for your organization.

Configuration Management 

Identification of configuration items

Organizations should specify which work products and what parts of work products should be placed under configuration management, and what specific controls are required, and when those controls are applied.

One way to represent this is with a table that lists work products or parts of work products, and lists the type of configuration control required, and in what phase they are placed under configuration control.  A separate guideline (or practice) then describes the different types of configuration control, if there is more than one.  You may also wish to specify how configuration controls change for a single work product through different phases of the project.

Another approach is to have a general policy that can be used to determine whether work products need to be under configuration control.  For example, you might just mandate that all project deliverables are placed under configuration control, rather than have a separate table.  You might also have a policy that says project deliverables are placed under configuration control in the phase where they are first formally reviewed.

Levels of configuration control

Typical levels of configuration control on projects are:

  • No controls - this typically applies to work products that have no long-term value, such as results of brainstorming efforts, throw away prototypes, and so on.
  • Version control only - in this case, you may capture past versions of a work product, but not have any controls on what changes are made, by who, or why.

Naming conventions

Organizations may wish to specify naming conventions for different kinds of configuration items.

Configuration management audits

Define the policies for configuration audits. These audits ensure that the system satisfies the specified requirements, including all approved change requests, and nothing more. 


Configuration management environments

Organizations should specify tools and tooling configurations that automate the configuration management process and enforce configuration management policies.

This includes the following.

Role authorization and notification

You may wish to limit access to certain kinds of information to particular project roles.  For example, project plans may not be available to customer representatives directly.  Project plans may be updateable only by the project manager.  You may also set up automatic notifications so that certain roles are notified when configurations items are changed.

The level of controls applied may be different for different project types.  For example, you may wish to have a high trust environment with very few controls in order to encourage high levels of collaboration.

Archival policies and mechanisms

Certain work products may be important to archive for metrics, compliance, or other reasons.  These may be identified using a table that lists work products that need to be archived.  Or you may have a general policy to identify which items to archive, such as "archive all configuration controlled items".

Product directory structure

Organizations may propose one or more standard product directory structures to organize configuration items.

Baselining

You may wish to establish policies on who can create a baseline, what kinds of work products are included, and what approvals are required.

Baselines should be created from approved configuration items only. 

Change management

Define Change Management practices to provide project teams with explicit approaches for controlling changes, including defining states for change requests and tasks for transitioning change requests between their specified states.

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. Organizations typically define a formal Change Management practice and an informal Change Management practice so that teams can select the most appropriate approach for their project.

An informal practice provides a simple change management process which is integrated into project management activities.  In this approach, any team member may request a change to the system (or supporting artifacts) at any time, either to correct a defect identified or to add an enhancement. The request for change is captured in the backlog. During project planning the team reviews the backlog, prioritizes work, and decides which changes will be implemented next. A more formal practice is used when additional governance is needed in the Change Management process when there is a group of stakeholders outside the project team that needs to approve and verify certain kinds of changes or changes need to be tightly controlled (such as late in an iteration or release cycle) for stabilization purposes.

Confirm your Change Management practices address the following concerns:

  • work products and kinds of changes that are controlled by the practice.
  • change request types (e.g. defect, enhancement request).
  • change request states (e.g. approved, assigned, deferred).
  • how often are changes reviewed?
  • what roles participate in the change-request process?
  • what metrics are tracked?

Product integration

Product Integration practices help teams progressively assemble the product components in incremental stages according to a specified integration strategy.

Enterprise policies for product integration prevent:

  • subsystems that don't integrate/ operate together.
  • installing a product that does not integrate with the customer's production systems.
  • delayed testing and increased integration times.

Establish enterprise procedures and the environments required to support the integration of product components.

  • Product integration environments may include equipment for testing and simulation, production hardware and other devices.
  • Make build or buy decisions based on the the availability of existing organizational resources and the enterprise product integration strategy.
  • Practices for the integration of product components typically describe such procedures as the types of tests to be carried out at each stage, criteria for managing interface descriptions and repositories, and guidelines for determining system build procedures.
  • Create tailoring guidelines describing how projects can tailor their project-specific process and integration environment (including build/ buy decisions).