10 configuration management truths for project managers.

Levels of technical complexity and financial risk have grown rapidly in aerospace and defense (A&D) programs, with project managers experiencing a crushing density of complexity due to a confluence of business drivers and technology trends. Large and small programs run over budget and over schedule yet still underperform.

Unrelenting pressures on the program office can originate from: higher performance requirements, broader design envelopes, systems engineering challenges, product configuration permutations, new material use, embedded software, compressed design cycles, new manufacturing processes, supply chain integration, shorter testing time, extended service life, workforce retention, safety concerns, and regulatory compliance.

While any one of these elements alone can disrupt a program schedule, their combination can wreck even the best-managed, well-funded initiative.

A succession of strategies with supporting software solutions has emerged throughout recent years to help tame the complexity beast. While the resulting automation, digitalization, integration, and connection of products, data, and processes throughout the original equipment manufacturer (OEM) enterprise has helped, it has also injected new complexities. In the process, a deep layer of concealed digital interdependencies has been added to known intricacies which already existed in the physical world.

One of the most visible consequences of cascading complexity manifests itself in the expectations for and challenges of configuration management (CM). This is true for the CM application, whether across a single product, larger program, or an entire enterprise with its extended supply and service chain partners.

CM is the application of resources, methodologies, processes, best practices, standards, governance policies, and software solutions to establish and maintain consistency and traceability between product requirements, the actual product as manufactured and serviced, and product data for all the creators and users of this information.

The importance of CM – and consequences from its lack – is well understood by most A&D OEMs and supply chain contractors. The financial cost and business risk from not having an updated all-inclusive understanding of CM can produce catastrophic failures in new products or ruinous consequences to an entire business line.

However, CM’s role in everyday practice is not always fully appreciated by new project managers or new contract suppliers. Some may consider CM to be a product engineering function. They do not recognize that there are more users and revisers of configuration data outside of product engineering than inside. Others believe that if they have change management processes defined then they must by default have an adequate CM implementation. Even experienced project managers may have been told that engineering product data management (PDM) or enterprise product lifecycle management (PLM) software solutions have taken care of CM. Nothing could be further from the truth.

Ten CM truths

1) CM is the foundation for quality management at the product, project, and program levels – The lack of a robust CM implementation is the greatest quality management issue a company may ever face. Without effective CM implementation you cannot state with certainty that you are in compliance with AS9100 quality standards; nor can you verify that you are designing and delivering to contractual requirements.

The five foundational elements of CM – planning, identification, change control, status accounting, and traceability and audit – apply to every process, service, and product developed through its entire life cycle. While design activity may be concerned with design for a one-off product or larger production runs, how the unit is built, tested, delivered, and maintained falls to the users of engineering’s as-designed documentation. Quality management through effective configuration control at each step is critical.

2) CM is everyone’s responsibility – By some estimates there is an order of magnitude more users of configuration information and data downstream of product development than in engineering. These users include stakeholders in contracts, finance, requirements planning, supply chain, reliability, safety, manufacturing, quality, mission assurance, test, logistics, compliance, customer support, and service. These users don’t just view or use CM data produced by engineering, they change, enrich, and repurpose it for other uses.

While the engineering staff’s responsibility is to know everything that may occur downstream, this pre-supposes that the information is available in a useable format to everyone else. An effective CM implementation assures that the digital threads created by the downstream entities are woven together in a way that these impacts are quantified to deefine mid-stream functional re-allocations.

3) CM is not about product history, present state, or the future impact of changes – It’s about all three states in time. The MIL-HDBK-61A on Configuration Management Guidance states, “Configuration Status Accounting (CSA) is the process of creating and organizing the knowledge base necessary for the performance of configuration management. In addition to facilitating CM, the purpose of CSA is to provide a highly reliable source of configuration information to support all program/project activities including program management, systems engineering, manufacturing, software development and maintenance, logistic support, modification, and maintenance.”

In the implementation of CM across the product life cycle, the digital threads are woven into a fabric so the state of the product as well as changes to its component parts, subsystems, assembled systems, and documentation is known and visible. CM processes must be structured so data hooks are attached to the nodes in the digital fabric so as-designed status information is captured as well as the as-built, as-delivered, as-maintained, and as-disposed of data for every lot or serial number delivered.

The as-Xs are the configuration of a configuration item (CI) throughout its life cycle. For defense contractors, CIs are identified for products, critical components, spares for fielded equipment, or complete weapon systems. These stages can occur through many years of production and service life.

4) Enterprise resource planning (ERP) or supply chain management (SCM) systems will not support the five tenets of CM – ERP systems deliver and integrate core business functions such as planning, purchasing, inventory, sales, marketing, finance, and human resources. This is missing key product life cycle stages such as engineering design and change control from the as-designed through the as-disposed configurations. The five foundational elements of CM each require special software functionality and workflows that accommodate these stages and requirements.

Also lacking is the planned interrelated responsibilities and interfaces required for program success and meeting key reviews and audits, as well as management of key performance indicators (KPIs). Out-of-the-box ERP or SCM systems are not set up to establish, maintain, or feed the digital threads needed to pull the desired metrics from the system.

5) PDM or PLM software does not guarantee that your project is performing CM – Most PDM software products support engineering change control, but many users and operators of CM data are outside of engineering, so it is unrealistic to expect an engineering- centric PDM solution with a CM module will be usable by everyone. Likewise, most PLM solutions claim to also support CM, yet few can answer basic questions without extensions or customizations:

• Is compliance with industry-specific CM standards, rules, and best practices inherent or must it be manually added and configured at additional cost?
• Can different levels of configuration control be performed without requiring all the OEMs’ original computer-aided design (CAD) or bill of materials (BOM) data?
• Is the CM functionality independent of where CAD and PDM data may have originated or the CAD development platform?
• Can the PLM system support multi-CAD and multi-PDM operating environments from different providers?
• Is having a complete product structure mandatory, even for component-level CM work performed by a supplier partner?
• Can users restrict, filter, or throttle automatic updates to the product structure such that as-configured records of fielded products are not prematurely or unintentionally polluted?

6) Document version control or change control is not configuration management – CM is a comprehensive approach that assures, maintains, and verifies a product’s physical and functional attributes against its requirements and documented design and operation throughout its life. CM provides the provenance of every item contained in the product including what was tested, how it was tested, part substitutions, and field modifications. Change management is a single element of CM. You can’t have true CM without change management, but you can have excellent change management processes yet still have non-existent CM controls.

If all you are doing is change management; you are only performing one-fifth the scope of CM. As an example, managing subsystem design and documentation changes without defining the metadata to be captured and internal subsystem- to-subsystem interfaces severely constricts the stakeholders’ review process. Integration once individual subsystems are completed and merged together is harder because they rarely interface properly. The costs associated with rework, re-design, and re-test far outweigh the extra effort required to fully implement CM.

7) A plan for using CM software is not the same as having a CM plan – For contractors, 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 design. This includes the extra layer of CM control associated with elements designated as CIs for each serial or lot number. A CM plan should address intra-organizational as well as extra-organizational responsibilities and interfaces, units of measure, date-time notations, metadata, metrics, procedures, and activities. It must also define the oversight necessary for configuration identification, change control, change board membership, status accounting, and configuration verification and support in-process, internal, and formal audits.

Within the CM plan, configuration planning defines how and where CM activities fit into the organization and its processes, so a CM plan’s scope is far greater than delivery of required data defined in the system requirements specification, mission assurance requirements (MAR), statement of work (SOW), or data requirements list (DRL). It extends to requirements specified in other sections of the contract including supplies and services, packaging and marking, inspection and acceptance, deliveries or performance, special contract requirements, and contract clauses. Finally, the CM plan is a living document that is released, revised, and maintained throughout the product’s or program’s life.

8) Special CM training or certification is needed – An experienced staff member or a respected external consultant must engage to perform the needs assessment, define strategy options, develop a CM plan, establish policies, specify requirements, evaluate software, architect processes, deploy and test a solution, and train users. CM consultants are often trained by Configuration Management Training and Certification (CMPIC), Institute for Process Excellences, and National Defense Industrial Association (NDIA).

While it can be helpful for the lead to have familiarity with your products and processes, it is more important they have experience guiding a CM implementation and independently moderating the work of other specialists who will have the product and institutional knowledge needed. Without such independent training a CM lead may be so ingrained in the status quo that they fail to grasp the entire CM mission. The wider view provided by external training and certification means that the CM implementation is undertaken from a top-down strategic perspective rather than a tactical bottom-up approach.

9) Ignore CM standards at your own peril – Dozens of international organizations, trade associations, and governing bodies stipulate hundreds of standards relating to configuration management. The most important CM standards for A&D contractors are to be found from the Code of Federal Regulations, Dept. of Defense, European Defense Standards Reference System, European Space Agency, Federal Aviation Administration, NASA, NATO, and SAE Int’l. Therefore, it is no surprise that some A&D contractors have a dedicated resource to monitor and master these standards, especially with frequent changes and updates. The failure to do so can be especially costly to a program with international partners and global customers.

10) CM requires executive involvement to provide oversight and governance – CM is not a single engineering function, product development task, or regulatory compliance annoyance to be delegated to any one functional or project manager. CM responsibilities and potential liabilities run across all facets of a program or enterprise. As such, CM must reside within the province of an executive office such as a vice president, chief product officer, or chief operatiing officer.

These executives should own the mandate to monitor the evolving maturity of their organization’s CM competency, including identification of performance gaps and comparison with industry peers.

Savvy executives understand the relevance and breadth of CM at the outset; those who arrive late discover the importance of CM only after a product failure. When a failure occurs, everyone in the company, including executive officers, suddenly become members of the CM department.

CMstat

About the author: Tom Tesmer is president of CMstat. He can be reached at 877.537.1959 or ttesmer@cmstat.com.