Chapter 4 – Configuration Management Plan

The Configuration Management plan is the defining guidebook for a CM program. It defines all of the procedures, organizational responsibilities, and tools to be used within the CM process. The plan is the backbone of a CM program, and as such, must either include well-developed, detailed procedures or refer to their locations in other documents. Following a general description of CM plans from EIA 649, this chapter provides implementation guidance and best transportation practices as examples of these recommendations.

EIA Standard 649 Definition

"A CM Plan describes how CM is accomplished and how consistency between the product definition, the product's configuration, and the CM records is achieved and maintained throughout the applicable phases of the product's lifecycle."

A CM plan clearly describes how CM is accomplished and how consistency between a system's configuration and the configuration records is achieved and maintained. The CM plan is a central source of information for the CM program. According to EIA 649, key benefits of creating a CM plan include:

  • Assurance that the appropriate CM processes are applied.
  • Detailed descriptions of responsibilities for CM activities.
  • Accurate knowledge concerning required resources.
  • A foundation for continued improvement.

EIA 649 discusses in detail the requirements of the plan and considerations that should be taken into account in its development. A CM plan should not be a one-size-fits-all document. Rather, it must be tailored to meet the needs of the agency responsible for CM. In particular, EIA 649 points out that a well-developed plan will aid in the training of personnel in CM and will help explain the process to outside personnel, such as upper-level management and auditors.

Key topics that EIA 649 states should be addressed by a CM plan include:

  • General {system} definition and scope.
  • Core CM process procedures.
    • Configuration identification.
    • Change control.
    • Configuration status accounting.
    • Configuration audits.
  • CM management.
  • Organization, roles, and responsibilities.
  • Programmatic and organizational interfaces.
  • Definitions of terms.

If these topics are covered in detail in the plan, the CM program will have a sound blueprint to guide its effective implementation. It also is important to note that the size of the CM plan should not be so large as to intimidate users; some specialists have found that large documents tend to convey a perception of large bureaucracy. If the procedures are sizeable, they should be segmented out into their own documents to reduce cultural resistance.

Implementation Guidance

The CM plan is essential to establishing and maintaining an effective CM program. This reflects the fact that the mechanics of the CM process mean very little if they are not tailored to the specific TMS. Under no circumstances should a transportation management system attempt to institute a CM program without first developing a CM plan.

Why a CM Plan?

Performing CM for the sake of CM becomes a cumbersome, time-consuming process, which does not result in benefits. A concerted effort to tailor the process to the TMS must be made by using a CM plan.

A recent survey of transportation professionals involved in CM identified the following key benefits of a CM plan.

  • The plan documents the CM process and as such acts as the tool used to gain project and management support for the process.
  • The plan forces an agency to define and describe the process.
  • The plan causes the agency to think about what it will do and how it will do it.
  • The plan serves as a contract vehicle for the project (in some cases).

Where to Begin

First, recognize that the development of an effective CM plan for a transportation agency is not a turnkey job that can be completely handed over to a consultant. Although most agencies surveyed have used a consultant to support CM plan development, they agree that it is essential to have agency staff actively involved with, or leading the development of, the plan because agency staff has the best understanding of the system functionality and change control needs.

Given the active role required of a transportation agency in plan development, the next step is to become educated. Staff must understand the principles and concepts of CM. The training opportunities detailed in chapter 10 provide examples of available courses. In addition this handbook may be used for educational purposes.

An excellent guidance document specific to CM plan development is CM Plans: The Beginning of your CM Solution (Bounds and Dart, 2001). This document is available on-line at the Software Engineering Institute's Web site at http://www.sei.cmu.edu/legacy/scm/abstracts/abscm_plans.html [Link no longer active]

Much of the guidance provided in this document is derived from the Bounds and Dart report. Individuals involved in CM plan development are advised to obtain a copy of this report for further guidance.

Most transportation professionals currently involved in CM did recommend using outside consultants to support the development of the CM plan. Consultants helped minimize the disruption of normal operations and allowed the CM managers for the various agencies to spend as little as a few hours a week on plan development. For some of the larger CM programs, consultants worked full time for up to a year developing the system and procedures that would be used, while a number of agency staff worked part time on CM throughout development.

Many agencies also cited the importance of using industry standards in the development of the plans, organization, and procedures that are to be used in the CM program. Some used the standards as the primary resource in the development of the plans.

Developing the Plan

Developing a CM plan is not a mysterious, magical process. Rather, it simply requires concerted effort and communication to ensure that the plan meets the needs of the TMS in question. This subsection summarizes the steps recommended by Bounds and Dart.

  1. Start with a standard. A number of good standards to guide CM plan development are available. The Bounds and Dart document includes a comparison of some of the more popular plans. In particular, the IEEE Standard for Software Configuration Management Plans (IEEE Std 828-1990) is recommended.
  2. Create a template. Create a template/outline for the plan, which will guide deliberations in next steps.
  3. Develop CM procedures. Develop the various procedures that the organization will follow in the CM program using the template as a guide. Doing so is by far the most difficult step in the process. It also will require involvement of individuals with expertise in the TMS as well as CM. Essentially, the team must study various procedures to find ones that will work for the agency.
  4. Document. Document the procedures and other plan material developed in step 3.

What Should Be in the Plan?

The outline provided by Bounds and Dart is an excellent example structure of a CM plan.

CM plan in outline format D

The Plan is a Living Document – It Will Change Too

The CM plan documents an agency's CM program. As the program progresses, the plan will need to change to reflect the changing environment. In addition, as a transportation agency gains experience in CM, this experience will dictate changes to the plan. A one CM official stated, "The old adage 'We don't know what we don't know' applies to CM. Most agencies have little or no experience and will find that their original plan will require multiple changes and modifications once put into effect. Experience will determine what works and what does not work for a given agency or situation."

Clearly, the CM plan subsequently will change throughout the system's life cycle. For this reason the CM plan is subject to change control and should be treated as any other component of the TMS.

Don't Start Too Big

A common mistake of individuals just getting involved in CM is to attempt to develop an overly complex, comprehensive CM plan, which addresses every possible situation in a system changing through time. Experienced CM professionals note that it is best to start out small and address the essentials. Often, many of the possible scenarios that an agency labors to address in a CM plan will never actually occur.

Implementation Guidance Summary

  • A CM program requires a CM plan.
  • The development of a CM plan must include the active involvement of TMS agency staff.
  • Use the following document to guide plan development: CM Plans: The Beginning of your CM Solution (Bounds and Dart, 2001) –http://www.sei.cmu.edu/legacy/scm/abstracts/abscm_plans.html
  • Use a standard to guide development. Recommended: the IEEE Standard for Software Configuration Management Plans (IEEE Std 828-1990).
  • Put the majority of the effort into crafting CM procedures that work for the agency and TMS.
  • Start small – be sure to include essential elements and do not seek to address every possible system change scenario.
  • Put the CM plan under CM control.

Best Transportation Practices

Before attempting to plan and manage a CM system, consider what other transportation professionals have done and what practices have proven effective. This section describes the experiences of a number of agencies that have developed and use formal CM plans.

CM Plan Development

Although a handful of agencies use CM without having a formal CM plan, DOTs that have an extensive TMS have seen a need to implement formal documents. This section describes how three DOTs developed their plans, including the resources the agencies used and methodology employed.

Georgia NaviGAtor

The Georgia NaviGAtor program developed its first formal CM plan in 1999. From the beginning, NaviGAtor's CM plan was developed with the help of an outside consultant with constant overview from GDOT personnel, particularly the CM manager. The actual plan took the consultant approximately 9 months to develop, and GDOT spent approximately 50 hours to review and approve it. The consultant who was originally hired to develop the plan had a great deal of personal experience with CM, although not in the TMS environment. In order to compensate for this lack of exposure, the consultant spent a good deal of time talking with GDOT personnel and getting a feel for the environment. The consultant also consulted a few CM books to aid his understanding.

Richmond, VA Smart Traffic Center

The Richmond Smart Traffic Center finished Version 01 of their CM plan at the end of 2001. When the proposal for construction of the STC was originally sent to the Virginia DOT, it provided for a minimal CM system, which included a standard query language (SQL) accessible database containing all inventory information. With this beginning the STC hired two outside consultants from different firms, who then developed the plan and currently serve on its configuration control board. One consultant was with the firm that developed the STC software. The other was an on-call technology support consultant to VDOT. Both were involved to ensure an objective, outside party involvement. The consultants estimated that they spent between five and six weeks working full time to develop the plan. Like the NaviGAtor consultant, the consultants' methodology was derived from personal experience with CM, and they did not use any standards or outside resources. VDOT employees spent less than 10 hours supervising plan development. VDOT employees did use standards and examined projects from other DOT's to assist them with plan revision.

Maryland CHART II System

The Maryland DOT finished development of its first CM plan, which manages only software, in July of 1999. Like the Richmond STC and the NaviGAtor program, the Maryland CHART II System's CM plan was developed by outside consultants, who also developed the DOT's CM software system. According to the consultant, the plan took two weeks to develop working full time. The plan likely would have taken more time to develop if the contractor had not used a standard CM plan that simply required customization to fit the CHART II System's needs.

Example TMS CM Plan Content

Excerpts from the CM plan of the Southern California Priority Corridor illustrate the principles and concepts discussed in this section. This document was originally published on December 5, 2000. Reviews of other TMS CM plans are provided in appendix C.

The following subsections illustrate content of the CM plan of the Southern California Priority Corridor.

CM Program Goals

The document clearly defines the goals of the CM program.

The Goals of Corridor-Wide Configuration Management for the Southern California Priority Corridor are to:

  • Ensure sustainability of Southern California Priority Corridor.
  • Reduce redundancy and increase the synergy across the current and future corridor projects.
  • Provide consistency across the Priority Corridor in areas of Advanced Traveler Information Systems (ATIS), Advanced Traffic/Transportation Management Systems (ATMS) and Commercial Vehicle Operations (CVO) to ensure seamless operations.
  • Maximize the Priority Corridor investments for current and future projects while balancing these goals with the autonomy of individual agencies to meet the needs to their Stakeholders.
  • Ensure the stability and smooth evolution of the Corridor-Wide System of Systems over time.
  • Provide a "Blue Print" and resource for new and existing projects to join the Priority Corridor Network.
Configuration Item Identification

A structure is established for identification of all configuration items as seen in the figure 4.1.

Figure 4.1 – Southern California Priority Corridor Identification Structure
Figure 4.1 D
Change Control Process

The change control process and procedures are fully documented in the plan. They are summarized in figure 4.2.

Figure 4.2 – Southern California Priority Corridor Change Control Process
Figure 4.2 D
CM Program Organizational Structure

The plan clearly lays out the organizational structure required to implement the program. This structure is described graphically in figure 4.3.

Figure 4.3 – Southern California Priority Corridor CM Program Organization
Figure 4.3 D