Why are we still so confused about what “Configuration Management” means?
Yes, this is the 21st Century.
Author: Eddie R. Williams, PMP
Contributing Author: Marc Gravez
I. Introduction
We still have confusion, debates, and even arguments about what the meaning of “configuration management,” “configuration,” and what constitutes a “configuration item” (software/hardware/firmware).
Commentary
Recently, I was in a networking group meeting, on Zoom of course. Individuals from different industries were sharing information about software and hardware quality assurance (QA), configuration management (CM), change management, information technology (IT), and project/program management office (PMO)/enterprise project/program/portfolio management office (EPMO).
For configuration management, there were several comments. One person said a configuration item is not a document where they work. Another said a document was a configuration item where or in the field in which they work. I said, “You both are right, based on where you work. That is the problem and an indication of why there is confusion about the definition of “CM” and “configuration” and what is a “configuration item.”
I have had to manage using both perspectives, adjusting to ensure the successful management of projects and programs through close out and beyond (support/maintenance).
Another story
A gentleman contacted me because he had read a couple of articles and my e-book because of the situation below. I call it “you never think it could happen to you.”
He worked at a company that did government and commercial work, and performed configuration management and version control using a tool. He had just been part of a highly visible project that had some issues and was on a path to fail. The manager for his group was terminated. They brought in a manager with some government and software/system development background. He said he was asked how did the code look, were there any specifications (of any size), and what was the cost of changes for changes that took place. Are they available/or in historical archive or files?
He informed the manager that with a hybrid situation, they had no specs for the code and cost was not tracked for all changes accumulated from a baseline. The manager said that was an issue but going forward some documentation was required, sprints or releases clearly identified and all significant changes will be tracked (out of scope and in-scope), and that lessons learned would be used at checkpoints/go no go, or at each phase. He indicated that the next project was a success with client/user satisfaction.
He said that they also set up a group to understand CM and that it was not just version control.
Below is a statement from someone who read the following article: Why CM? What is the SDLC? System/Software Development Life Cycle Process Explained.
https://management.rayannpublishers.com/ Software/Firmware Configuration Management
“I was still having problems with understanding Configuration Management but after reading your article and book, I do know why I was having difficulties with the entire development life cycle focusing only on software version control and software library development.”
CM is more than just version control, integration and build tool but automating processes is a good thing.
II. Why there is still confusion
There is confusion because the origins of CM are misunderstood and/or used incorrectly in different industries. Simultaneously, these industries re-defined the meaning of CM and what constitutes a configuration item for themselves.
Important: In the beginning, the definition of “configuration” needed to be/required so that all understood its definition: (Words in parenthesis are clarification words and statements from me)
MIL-STD-973/DOD-STD480 – Configuration, the functional (requirements) and physical (design/product) characteristics of hardware, firmware (embedded software programs/systems in hardware devices), software or a combination thereof as set forth in technical documentation (requirements, design, interface, the code/program/the software in devices) and achieved in a product.
Does the above sound like a document? Designated technical documents are used to capture the information specifying product or system to document its configuration and to be managed and changes (configuration) controlled.
When the commercial industries and some IT companies used CM these are some the activities or things they did:
- A major pharmaceutical company used customized DOD and military documents to fit their environments and comply with some guidelines and regulations (e.g., GXP, CFRs, etc.).
- Some industries did not understand the total processes and activities of CM and instead just used “CM” to refer to version control and changes. Overlooking that CM activity and processes support requirements, release management, and security implementations.
- Other industries began to call a document a configuration item, without having the required expertise for CM and knowledge of what a configuration item is and how it had to initially meet some criteria.
- One person in a network group talking about relevant information stated we even “stole” (laughing, a joke) – we used Quality Assurance (QA, a process that supports lifecycle development and production, and CM) and made it just testing. He said he learned later, with lessons learned, that QA, a process/program supported the full life cycle and it processes with activities such as QA V &V, with reviews, audits, and verification (documentation examinations) and validation/testing (ensuring CIs functionality met requirements.
- When I move into the commercial IT environment and business companies from government and DOD, Some of these companies did not even have documentation or specifications (and some documentation were too much (but don’t eliminate the necessary documentation/deliverable) and why I say Agile brought two needed improvements and iterations. It was not meant to eliminate good planning and the appropriate or limited documentation for control and planning, execution and change control.
For Agile development requirements, initially testing was not stressed as much as it required in the beginning – that later changed. But wide spread use instead of using waterfall has improved quicker releases of functional software/firmware but there has to be a continuous improvement track/process also. (However, many have discovered that it is not just either or, in some cases it is/has been use of a hybrid methodology – using both methodologies to successful close out, and in some case client’s request.)
(No one tried to stop it all in the beginning when CM’s use began to be widespread (1980-1990s) by other industries, but I did with some options or an option to resolve the problem. However, it may have been too late, or it appears it was/is.?) I even had a book published addressing the issues.)
Link to article(s) and the book.
(Management Control and Quality – Software/Firmware Configuration Management – https://management.rayannpublishers.com/
Configuration Management Definitions:
Below are definitions. I include CM’s origin and some current definitions (such as from ITIL) or usage for Configuration Management, Configuration and Configuration item. …and CI’s selection criteria.
Configuration management: A discipline applying technical and administrative direction and surveillance to: (1) identify and document the functional and physical characteristics of a configuration item; (2) control changes to those characteristics; and (3) record and report changes to processing and implementation status. (US DoD)
Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design, and operational information throughout its life. The CM process is widely used by military engineering organizations to manage changes throughout the system lifecycle of complex systems, such as weapon systems, military vehicles, and information systems. Outside the military, the CM process is also used with IT service management as defined by ITIL, and with other domain models in the civil engineering and other industrial engineering segments such as roads, bridges, canals, dams, and buildings.
Configuration management (CM) is an ITIL version 2 and an IT service management (ITSM) process that tracks all of the individual configuration items (CIs) in an IT system, which may be as simple as a single server, or as complex as the entire IT department (WHAT DOES THAT MEAN?).
Configuration management (CfM), one of the components in the ITIL Service Support area, exists to identify, maintain, and verify information on IT assets and configurations in the enterprise. CfM stores up-to-date information about configuration items (CIs) in a configuration management database (CMDB).
MIL-STD-973/DOD-STD480 – Configuration, the functional (requirements) and physical (design/product) characteristics of hardware, firmware (embedded software programs/systems in hardware devices), software or a combination thereof as set forth in technical documentation (requirements, design, interface, the code/program/the software in devices) and achieved in a product
MIL-STD-973, 483, and DOD-STD-480A – Configuration Identification includes the selection of CIs (or CSCIs -Computer Software Configuration Items), the determination of the type of configuration documentation required for each CI, the issuance of numbers (and version numbers) and identifiers affixed to the CIs and to their technical documentation that defines the CI’s configuration, including external interfaces; the release of CIs and their associated configuration documentation; and the establishment of configuration baselines for CIs.” (Configuration Identification is not just selecting and determining the type of documentation, it is also describing the CSCIs technically; function or capability and design.)
Configuration Item
Now configuration items has become this:
Examples of configuration items include software and applications, locations and offices, employees and customers, documentation, hardware and companies, and even your incidents, changes and customers. Each Configuration Item must include the following: Name and description.
What is a hardware configuration item?
A hardware component of a system, which is designated for configuration management to the integrity of the delivered product. It may exist at any level in the system hierarchy, since configuration management must be imposed down to the lowest level where item interchangeability is required.
What is a configuration item in CMDB?
Configuration items (CIs) are the focal point of a CMDB. Simply put, a CI is an instance of an entity that is part of your environment and has configurable attributes specific to that instance. …Feb 18, 2013
Configuration items can include hardware, equipment, and tangible assets as well as software and documentation. Documentation can include requirements specifications and interface documents. Other documents that serve to identify the configuration of the product or service, such as test results, may also be included.
The issue now is can we resolve the problems or do we continue down different paths?
IV. CONFIGURATION ITEM SELECTION CRITERIA
MIL-HDBK-61A: Configuration Identification
https://www.acqnotes.com/Attachments/MIL-HDBK-61A%20(SE)Configuration%20Management%20Guidance.pdf
Activity Guide: Table 5-2. Configuration Item Selection Criteria
The process of selecting configuration items requires the exercise of good systems engineering judgment based on experience, supported by cost trade-off considerations. No fixed rules govern CI selection or dictate the optimum number of CIs for a particular system. Rather guidelines for making the appropriate judgments are provided in the General Guidance, CI Selection Checklist, and Additional Factors sections of this table.
“CI Selection Criteria Guidelines
During the concept exploration and the program definition and risks reduction phases, the system architecture is established, the program work breakdown structure is developed, and major CIs are selected….”
From: “The Bottom Line:”
“CI” is a DOD generated term that was intended for DOD/contractor programs.
“CIs” were selected prior to development for project/program management purposes. A CI would have its own baselines, its own FCA/PCA, its own change boards, its own status accounting reports, its own structure, its own program reviews, etc. A CI was also any item required for logistic support and is designated for separate procurement.
According to this definition, documents cannot be CIs and were never intended to be.”
Below, from the published Book: Software/Firmware Configuration Management (Within the System Development Process) – Subtitle: Management Control & Quality.
From: Software/Firmware Configuration Management – Management Control and Quality – https://management.rayannpublishers.com/
Typically, a CI/CSCI had to also meet some criteria for identification, management and control.
Such as:
The S/F book:
“The product (Computer Software Configuration Item) is selected based on a coordinated effort by the customer/user and developer. Considering the following, several CSCIs (products) may be selected
System requirements allocation (if product major function of the system)
- Software/Application functionality and capability
- Extensive information and data requirements
- Each processor (embedded software)
- Critically/safety
- Size (source code lines)
- Cost/schedule
- Quality (i.e., reliability, reusability, maintainability, testability, modularity, etc.)
- Logistical support
- Maintenance…”
Do the above sound as if you are selecting a document to be developed or produced?
In the CM book, each section identifying CM processes/activities provides a definition, what it means and some cases where it begins, who is responsible and some recommendations in each section (but not limited to). Now yes, there have been improvements for CM like any other discipline or process and it should be subject to continuous improvement but should we change what it encompasses and meant?
In the book, the CM process/discipline (supports an engineering/system/software development process/activity) and is not Data Management even though Data Management supports Configuration Management.
Configuration control is under the umbrella of change management, but is not data management. Data management is data administration (some call it “documentation”) controlling a document(s) and it revisions. Configuration management is concerned with content: what the document specifies, technical information and requirements, the product (system, software, application, etc.) and not the document itself. Although test plans, manuals and other non technical documents (not part of describing/specifying requirements and design or interfaces) of an item’s configuration, they are put under data management and change control as a document changes/revised (but not for their “configuration” because a document does not have a configuration to selected as a CI).
V. Conclusion:
My question to technical and business professionals in various industries is “What can be done and what may not happen?” Do you have any “constructive” feedback? I hope that it does not offend anyone.
We can continue the conversations, debates, and confusion or collaborate to resolve the issues. I am just responding to what I have observed on the application of CM for projects and programs. I have experience and background directly managing projects and programs in both environments and different industries. The teams that were built were proactive and used development methodologies, configuration management, quality assurance/testing, and change (and configuration) management to close out successfully.
We all are “in the same boat” or maybe not. I have worked in two fields and authored a book when I saw the issues and problems. At that time, I tried to present a resolution. That resolution was difficult at the time and remains challenging now. A resolution will require collaboration from difference industries having different perspectives. Along with the different interpretations and practices, there are certifications.
Is there common ground to help us move forward or do we continue on the current paths without collaboration?
Good luck and be safe and healthy.
Eddie R. Williams, PMP
New Jersey, USA
Eddie R. Williams has over 25 years of experience as a program and project manager for system/software engineering, Information Technology (IT) development and management in aerospace, DOD, commercial IT and other industries such as healthcare, pharmaceutical, insurance, and academia. He has been a Project Manager, Sr. PM, Program Manager, Sr. Program Manager, Integration Manager, and Sr. Program/Portfolio Manager for the creation, development and management of PMOs/EPMOs. He has managed successfully through close out projects and programs for business transformations and systems, applications (including web applications) and infrastructure/networks, communication systems implementations. Mr. Williams has been a certified Project Management Professional (PMP) through the Project Management Institute since 1999. Before becoming a certified project and program manager, he held positions such as Systems and Procedures Analyst (programming and creating system/software specifications), Configuration Management Specialist and Manager, Software Product/Quality Assurance Engineer and Manager, Division Administrator/Manager (development methodologies (Waterfall, Agile, hybrid, etc.), management and control).
He is also a coach/mentor and educator, and been a speaker at numerous conferences, and is the author of Software/Firmware Configuration Management (Within the System Development Process) and Management Control and Quality. In 2014, he provided program management content through the Program Management Academy: Content contribution to the 2014, Wiley publication, “Program Management for Improved Business Results” for University master’s degree programs. You can contact Eddie at https://www.itprofessionalfacilitator.com.
Marc Gravez
Pennsylvania, USA
Marc Gravez is a customer-focused technical communication professional and technical writer. His passion is creating content that empowers people to learn faster, remember more, and work better, bridging the gap between what users know and technologists think users know. Mr. Gravez has more than 20 years of industry experience, including healthcare IT, telecom, cable, networking, banking, and engineering. He is a Past President of the Society for Technical Communication (STC) Philadelphia Metro Chapter. He can be contacted at marcgravez@gmail.com.
