Chapter 4

Configuration Change Management

This chapter provides information about managing change in the context of PCM. It expands upon information presented in the PMBOK® Guide–Third Edition and provides specific guidance with respect to the processes used for managing change on a project. It includes the following major sections:

4.1 Overview

The PMBOK® Guide–Third Edition defines Configuration Management (CM) as a subsystem of overall project management. The processes in PCM are utilized when managing the fundamental project constraints of scope, time, cost, and quality. Configuration Change Management (CCM) plays a crucial role in managing these constraints, as it encompasses the processes and procedures used to administer changes to Configuration Items (CIs).

Applying CCM principles to project artifacts ensures a number of benefits including:

• The correct version of the configuration item is in use by the project team;
• Changes to configuration items are made only by authorized individuals;
• A planned means of notifying stakeholders of approved changes to configuration items is in place; and
• A record of configuration item changes is kept to support auditing and project closure activities.

CCM is applied when identifying and documenting changes and their impact on configuration items. Changes are then processed through the project’s change control system. In many application areas, the change control system is a subset of the configuration management system, as described in Figure 4-1.

Figure 4-2 illustrates the process required to execute configuration change management.

The individual phases of the configuration change management process are described as follows:

• Baseline: This is the latest baseline released by CM.
• Submit Change Request: This step prepares the request, ensuring that adequate information is supplied to allow proper assessment of the impact of the change.
• Verify Change Request: This step ensures that all the information needed to carry out an evaluation has been provided. It establishes relationships between the proposed changes and the items that will be impacted by the change.
• Evaluate Impacts: This step evaluates the impact of the proposed change. Technical, cost, schedule, security, and contract impacts are all evaluated. Identifying the appropriate people to carry out the evaluation may be challenging. The need to ensure that all impacts are identified must be balanced with the need to executing the process efficiently by doing only the necessary evaluations.
• Review Decision and Plan: This step considers the proposed change in light of the evaluated impact. The authority required to approve a change will vary according to the type and status of items affected. A proposed change may, of course, be rejected. Items which actually need to be changed are confirmed and work packages are established and/or adjusted.
• Implement Change if Approved: This step makes the change, tracks the progress, and reports status to the tracking system. Relationships between the change record and the item(s) actually affected by the change are established and updated.
• Conclude Change Process: This step ensures that the CCM process has been correctly followed and that there is appropriate evidence that changes have been satisfactorily implemented (typically a review process for documents, testing for code). Authority to conclude a change is the same as the authority to prove it. Status is reported to the tracking system.

4.2 Identification

The PMBOK® Guide–Third Edition suggests that a clear distinction be made between plans and project performance measurement baselines. Specifically, it defines plans as project deliverables that should be expected to change over time and states that performance measurement baselines change only in response to approved scope of work or deliverable changes.

The identification of project deliverables as CIs may be either formal or informal. The level of formality, the complexity of the CCM process, and the cost of supporting the procedures should be appropriate to the needs of the project.

CCM is usually described in the project change control plan or in a separate CM plan if project size and complexity justify it. Ideally, the CCM process is described in one document and scalable to the project. Ultimately, CCM should be readily visible to project stakeholders so that constraints (scope, time, cost, and quality) can be managed successfully.

4.3 Process

The change management process describes integrated change control as a system that covers the creation and value assessment of change requests. In addition, the change management process includes maintenance of baselines and managing the approved changes. In some systems, authorization for making changes or document modifications is tracked and in other systems authorization is electronically controlled through security access. CCM encompasses the processes used to administer change to CIs. A project may have a number of change management processes.

CCM may be governed by industry standards or practice. CCM systems and components have been developed for some practices, such as manufacturing, software development, and construction.

A CCM process may include a number of components and a structured process flow. The structured process flow describes the activities, inputs, outputs, and controls for each step of a change process life cycle. The CCM components are mechanisms that support the CCM process. A database listing information about CIs is one such component. A change request form is another.

A CCM process has processes and procedures that serve to assure that all necessary aspects of configuration change management are addressed and decisions are accurately reflected. The CCM process serves a number of purposes in addition to prescribing administrative procedures. For example, the process helps ensure:

• Stakeholders’ viewpoints are addressed;
• Impacts on scope, time, cost, and quality are identified and documented;
• Assigned personnel conduct evaluations;
• Recommendations and approvals are sought and recorded; and
• Decisions are communicated by means of appropriate internal and external human interfaces.

It is important to remember that the CCM process requires that the related procedures are documented and that the appropriate configuration baselines are established. It is imperative that the baselines provide for the identification and control of the CIs.

In general, the sequence of events for an iteration of the CCM process begins with the determination that a change is required. The impetus for change, for example, can be an improvement, a new requirement, clarification of an existing requirement, or an externally mandated change. The project documentation establishes responsibilities and procedures for documenting the need for change, as well as procedures for submitting a change request. Note that the change control process has the tools and techniques needed for the submission, recording, and retention of change requests.

The CCM process is a type of workflow, where the first set of activities involves the recognition and documentation of a needed change and the entry of that information into the change management system.

The next set of activities is concerned with the evaluation and approval of the change request. These activities and their sequence can be quite complex if several organizations and/or a large body of documentation is involved. Often, the evaluation includes review by a Configuration or Change Control Board (CCB) or equivalent.

The next set of activities includes those related to processing the results of the evaluation and approval activities. These activities include providing notifications, preparing for implementation of approved changes, implementing the changes, and validating that the changes occurred. Note that in some projects, the verification of change is performed by an operating element and a separate organizational element subsequently verifies the implementation.

4.4 Control

Fundamental control of changes to configuration items (CIs) may be achieved through a Project Management Information System (PMIS), which supports a full audit trail and reporting of change requests. The requests contain information appropriate to managing changes to project deliverables. Depending on the application area and on the degree of deliverable complexity, the PMIS may be augmented or supplemented by a CI database.

Formal controls of CIs tend to focus on the unique deliverable being produced. Application areas such as architecture, engineering, construction, manufacturing, and computer systems frequently are governed by industry standards or formal practice guidelines.

Whether formal or informal, change management control ensures that each change request is tracked over its lifetime. Tracking would normally include the following as a minimum: unique tracking number, originator information, time stamp, and synopsis of request.

4.5 Assessment and Approval

The project manager bears ultimate responsibility for the integrity of the change request process, and for tracking work on the implementation of the approved change request resolution. Responsibility for approvals and rejection of a change request is established in the project process documents. This responsibility may be assigned to a qualified technical stakeholder at any level in the hierarchy.

A project charter or other requirements may impose change control information requirements on a project. This can be expected when a project is part of a program of related projects. Points of contact hierarchies are more complex for programs than for projects. The level of effort for program CCM is expected to be greater than for project CCM.

If a contract applies, legal and client stakeholders should be included in the point of contact hierarchy. This may be expected to increase the level of effort. These stakeholders may have change request rejection authority, depending on the nature of the contract and the level of risk exposure and risk tolerance.

4.6 Implementation

Some basic requirements to implement change on a CI are:

• Documented approval;
• Use of CM tools and techniques appropriate to the application area; and
• Documentation of relevant quality metrics and testing results appropriate to the application area.

4.7 Verification and Acceptance

Verification and acceptance of a change request resolution is achieved only after the authorization of an appropriate business or technical stakeholder is obtained. In some cases, formal testing or regulatory approval is required before a change can be accepted. Verification and acceptance ensures that only authorized changes are implemented.

4.8 Closure

The authority of an appropriate business or technical stakeholder, acknowledging successful implementation of an approved change request resolution within relevant scope, time, cost, and quality bounds, is both necessary and sufficient for change request closure. A deliverable should not be considered complete until all change requests impacting that deliverable are closed.