What is a Configuration Management Plan?
Planning to implement configuration management is not the same as having a Configuration Management Plan!
A common mistake in configuration management planning is thinking that if your organization has implemented PDM software with change control capabilities, or even a complete industry-focused CM solution, then you must have a Configuration Management Plan. Unfortunately, this is all too frequently not true.
Why is a Configuration Management Plan important?
It has been said that almost every engineering disaster, except those arising from natural causes or operator error, can ultimately be traced to at least one configuration management issue. Failures in configuration management occur in every industry and are often splashed across the news headlines worldwide when things go wrong.
The role of configuration management deficiencies in product failures over the last half century conservatively had a negative impact well in excess of $30B in today’s dollars. Among the more prominent examples include the following accidents:
The implementation of configuration management starts with a well-conceived Configuration Management Plan, often abbreviated as CM Plan or CMP. The CM Plan is typically the first item that program auditors or accident investigators will examine when they evaluate the sufficiency of a firm’s configuration management implementation, as well as when seeking contributing factors to a product malfunction or system failure.
What is the purpose of a Configuration Management Plan?
The adequacy of a configuration management implementation begins with configuration planning. The CM Plan describes not just how the CM processes for a product, project, or program will be implemented, but also how they should be used and maintained throughout the lifecycle of the product or program.
For the aerospace & defense industry, the CM Plan defines how an organization will establish and fulfill the program management, systems engineering and other mission requirements specified in the contract throughout the life of the program’s Configuration Items (CIs) for each serial or lot number. This scope of a CM Plan is far greater than delivery of required data defined in the Data Requirements List (DRL), Mission Assurance Requirements (MAR) or the Statement of Work (SOW). It extends to requirements specified in the terms and conditions and general provisions of the contract, as well as those identified in requirements and mission assurance specifications.
What goes into a Configuration Management Plan?
A configuration management plan should address the responsibilities, procedures, activities, and oversight necessary to provide configuration identification, change control, status accounting and configuration audits. Within the CM Plan, configuration planning defines how and where configuration management activities fit into the organization and its processes.
Example Configuration Management Plan Table of Content
The CM Plan should define how and at what level Configuration Identification is to take place including specific lot or serial number requirements and the metadata fields associated with them. Configuration Identification evolves over the life of a program and may greatly expand in scope once all hardware or software CIs and Baselines are defined, approach deployment, and as logistic needs for maintenance are established.
A CM Plan should define Change Control Classification (minor, major, or critical) and stipulate the Change Control Board (CCB). This includes specification of its structure, membership, and approval authority for each classification. Processes must be specified for how change proposals, change requests and change notices are handled as well as deviations, variances and waivers.
Configuration Status Accounting activities must be clearly addressed in the CM Plan. This includes the recording, reporting, and metrics pertaining to change states and status, change requests, change notices, and the impact of approved changes to releases of drawings, documentation, red-lining, analysis, reports, procedures, etc. associated with each CI as well as the date the change is incorporated in each affected effectivity.
A CM Plan must define Verification and Audit of the items chosen as CIs as well as their components. This includes verification and validation of the CIs against functional baseline requirements and sufficiency of functional requirements allocation to subsystems and components. In-process Functional Configuration Audits (FCA) as well as formal Physical Configuration Audit (PCA) criteria are defined against contractual requirements as are criteria for acceptance, delivery, maintenance and final disposition.
Lastly, a good CM Plan should evolve and strengthen over time during each of the product or program lifecycle phases. It is not unusual to find a unique CM Plan for each milestone if the program or system is particularly long or complex. This is especially true when there are multiple subcontractors, vendors, and customer participating in any of the stages. CM Plan resources, definitions, metrics, reference libraries, data access, data management and data retention policies, along with data backup and recovery processes must be secured and preserved across all of the phases and participants.
How is a Configuration Management Plan used?
The CM Plan is a critical component of a program manager’s tool chest assuring an integrated strategy is deployed across all organizational functions. The long winding digital thread of the CM Plan flows through Systems Design and Engineering, Requirements Planning, Safety, Mission Assurance, Design, Supply Chain Management, Production, Assembly, Test, Logistics, Acceptance, Delivery, Support, Maintenance and Disposition. The strength of the CM Plan digital thread, like the warp on a loom, assures the final digital fabric as the weft is added, in the form of digital threads contributed by others performing work on a program, is strong and will endure until disposition of the last deliverable.
Nearly everyone in a company operates on or performs some element of Configuration Management whether they know it or not! A single Configuration Manager or even their entire team can neither do it all nor manage it all. An analogy is that each department in a company or function of a program is a section in an orchestra and the Program Manager is the conductor while the Lead Systems Engineer is the concertmaster, all playing in harmony to the CM Plan score.
For the new A&D program manager or engineering lead it is important to insist that the CM Plan is prepared during the bid and proposal phase, not afterwards, and that there are sufficient resources and budget planned to maintain it throughout the milestone phases of CIs. A well-constructed CM Plan will assure an integrated infrastructure in place, so it is possible to ascertain the configuration of each CI delivered as it proceeds from the As-Designed configuration through As-Built production, As-Tested validation, As-Delivered customer acceptance, and As-Maintained servicing, repair, and refurbishment.
Who should develop and approve the CM Plan?
The CM Plan should be developed by someone who:
Has been trained to the SAE/EIA-649 Standard as a Certified Configuration Manager and has experience implementing CM
Understands the company’s products, processes, customer requirements, and business culture
Possesses the skills to collaborate and communicate across organizational boundaries
Has the experience to participate in Configuration Management training for personnel at different functional levels
It is not always necessary that the CM Plan be developed or the effort be led by an internal company employee. Often, an expert external CM consultant who guides the process can operate more effectively and comprehensively across organizational boundaries. This is especially true in helping the entire company to realize that no one single employee, department, or product manager can perform the CM function as there are important roles and responsibilities to be enacted by nearly all.
The CM Plan should be reviewed, then approved, and finally accepted or at least acknowledged by all the managers whose organizations create, manage, consume, distribute, touch, revise, or repurpose configuration-related data. This list is often lengthy for the very good reason that effective configuration control is not the function of a single CM manager or CM group, but that of the entire company!
These managers may include Product Engineering, Project Management, Program Management, Manufacturing, Product Marketing, Tech Sales, Quality Assurance, Compliance, Procurement, Logistics, Supply Chain, Customer Support, and Service. Finally an executive at the Vice President level or above must put his or her signature on the plan to impart management confidence in the plan and that it is aligned with business policies, direction, and priorities.
What is the most common mistake in a CM Plan?
Not having a CM Plan and thinking that you do because you have PDM software with CM capabilities is an all too common mistake of CM planning. From the above discussion on all that goes into developing a CM Plan, it should be clear that deploying a general purpose PDM solution or even a CM focused software tool does not guarantee there is a CM Plan. Requirements defined in the CM Plan must always be in the lead and software tool selection must follow that lead.
Where to learn more?
To learn how you can receive a complimentary Configuration Management Plan Review of an existing CM Plan please visit HERE. Or contact CMstat at information@cmstat.com and (877) 537-1959 for help with developing, validating, or updating a new CM Plan.
Receive CMsights
Subscribe to CMsights News for the latest updates from CMstat on Configuration Management, Data Management, EPOCH CM, and EPOCH DM.
Request a Demo
See how EPOCH CM and EPOCH DM support industry standards and best practices in Configuration Management and Data Management.
