Configuration control--release the handcuffs!

The increasingly complex, global nature of all business across industries and vertical sectors, coupled with rapid-fire, “Internet Time” business models, is driving new emphasis on change management. The ability to effectively manage change is emerging as a differentiating key among competitors – enabling organizations to evolve business models and product lines, and change gears quickly enough to meet the opportunities of the current economy – ahead of the competition.

As organizations struggle to manage projects in this environment, Configuration Management (CM) has become an increasingly critical component, offering a framework for managing change.

The discipline of CM consists of six areas of expertise as defined by EIA-649 (ANSI, 2004))

• CM Planning and Management (CMPM),
• Configuration Identification (CI),
• Configuration Change Management (CCM),
• Configuration Status Accounting (CSA),
• Configuration Verification & Audits (CVA), and
• CM of Digital Data.

However, ISO 10007 (ISO, 2003) groups CM into four classifications:

• CI,
• Configuration Control (CC),
• CSA, and
• Configuration Reviews and Audits (R&A).

(CCM and CC are for all practical purposes identical, as are CVA and R&A.)

Note that configuration control is discussed in this article. Configuration change management and change control are also terms used to describe the same process.

Many project managers perceive configuration control as restraining and confining – systems designed to stunt product development and that usually impacts the project's schedule in a negative way. Unfortunately, too often generic CC processes designed for large, complex programs such as weapons or medical systems development, are imposed on other types of projects. These processes are not tailored to meet the needs of, for example, a Web development effort or a new product roll-out. This ultimately leads to intense frustration with the CC process and the “handcuffing” effect – where processes not designed to meet the needs of the program negatively impact progress.

Project managers implement configuration control to control and track changes. The processes are designed to ensure that the appropriate level is used to approve changes and that these changes are based on best-available information. The processes provide a framework for change review. This enables the team to assess if implementing the change is acceptable and to identify potential problems in a timely fashion. These processes allow for calibration, and if necessary, further revision.

The real question is not whether to implement configuration control, but what level of configuration control to implement. An organization may require a “company standard” configuration control package on all projects. This type of system is often imposed on project teams due to a history of lack of configuration control, and the resulting financial impact. Project managers, who recognize that a “one-size-fits-all” approach will not work, must demonstrate that appropriate controls are in place to avoid repeating past mistakes.

Configuration Control in Action

The typical development project does not require a configuration control process on the level of a major weapons system. It is important to empower the team with the appropriate level of flexibility while ensuring that a system of checks and balances is in place. The key to any system is the effort required in documenting the process, along with the documentation required by the process. The sample CC process described below is designed to meet the requirements of a small to mid-sized application development project.

The project team should first analyze the appropriate role of configuration control on the project. This, at a minimum on a software project, would entail a theme of documenting all code files internally and some type of external documentation. Additional areas to cover include change approval and change documentation processes. Simple consensus by the participants involved should suffice. Of course, a structured board convened regularly is better.

Now let's get into the different aspects of the simple Configuration Control process.

Documents

The Configuration Management Plan (CMP) will define the CC process. In some applications where the CC process is fairly detailed, a Configuration Control Plan (CCP) is developed. In either case, all processes and procedures are covered to perform configuration control.

Change documentation itself (detailed later) must provide enough information that is self explanatory to the point of not requiring additional information from the originator. This is required due to the possibility that the originator may not be available by the time the change is implemented.

Process

The CC process is simple (Exhibit 1). An individual has an idea or finds an error in the current system. This individual should document their findings on an Enterprise Change Request (ECR), a form utilized to log all bugs, changes, or enhancements for the given project. The change request is routed to peers and supervisors for review and then approved and implemented.

Exhibit 1- Simple Configuration Control Process

Change Documentation

Documenting change is the most critical part of a configuration control system. The detail of documentation is not as important as the information being documented. However, the documented information must describe the change and include, at a minimum, the following information. Minimal requirements for documentation are:

Of course, the more information contained in the documentation, the easier it is to recreate, recover, analyze, and correct. In addition, this will aid in final documentation for product delivery.

When an individual discovers an error or a requirement in the current project, he or she documents the change required. A change request contains information about the request and describes the scenario that discovered the error, who discovered it, when it was discovered, and recommended fixes. The request should also identify the configuration items affected, if possible, and place some sort of severity or priority code to identify when this change, if approved, should occur.

Change Approval

Change approval should come from a designated project supervisor with the “big picture” view of change impact. A peer review is a highly effective means of verifying all facets of the change and ensuring all areas affected by the change are addressed. Having the customer agree with the change would be beneficial for enhancements. However in small developments projects, most changes are of a “bug fix” type and the customer would not see the impact of the change.

Data Collection

Data collection is vital in recovering information of like items and discovering trends and tendencies. This information should reside electronically, which allows for easy recovery of data and data manipulation for status accounting and metrics. The information can be used to compile a “lessons learned” report, which is distributed throughout an organization for technical improvement.

Change Implementation.

Once all the appropriate approvals are received then the task of implementation begins. Testing at every step of implementation verifies that impacts to other aspects of the program are minimal. All testing is completed and the change is implemented into the entire program.

Closed-Loop Process

A closed-loop process in which the change originator will know the final outcome of the change before it shows up in the final product is a key component for success. This holds true for all types of industries, from construction to manufacturing to software.

This closed-loop process sets up control boards with different roles in the change process (Exhibit 2). Each board has the obligation to review a change in the full context of its charter and to come to a definitive decision for each change. Of course, the board may require additional information before it can make that decision, but this should be minimal.

The Institute for Configuration Management (ICMHQ) teaches the CMII (CMIIU) methodology for configuration management and has developed this view of a closed-loop change process. This process begins and ends with the end item. Note that configuration change administration appears at three different levels within the loop. Each area is defined differently and has specific roles and responsibilities.

• Technical Review -- Ensures that all detail evaluations and feasibility analysis are complete.
• The Change Review Board (CRB) - Evaluates the business impact of the change. Is this change valid for our business environment? Does it meet one of our strategic goals? Does it fit into our vision statement? With an approved change, the CRB may or may not indicate a timeframe for the change, dependent upon competitive forecasting and business risk.
• The Change Implementation Board (CIB) - Allocates the funding required and determines change implementation timeframes. This also includes assigning effectivity for the change, which specifies when the change is effective. The effectivity could pertain to a date, build, serial number, or lot number. This is dependent upon the end item.

The Fast Track option of the loop is where all the pain of CC is released and the owners can get a changed approved in minutes versus days. The key to this of course is a proper documentation tree for each product. Each document must have a creator and user assigned to them. If the changes only impact the low-level documentation, then Fast Track is in order and the change screams through the CC Process.

Summary

The key to any successful Configuration Control process is the buy-in from the entire project team. Team members should not be asked to relinquish sound judgement and control for the sake of a management infrastructure that is not designed to meet the requirements of the project at hand. Configuration Control processes are designed to reduce the risk of failure and ensure deliverables are met on time and on budget. If the project team participates in establishing the initial Configuration Control framework – participation and acceptance across the project team is accelerated and the infrastructure established will support the business goals.