For Configuration Management (CM) we have been concentrating so much on software and version control, (tools and applications), that we have forgotten that CM begins before you have the software or its components and modules (units). See definition for CM in Software/Firmware Configuration Management. With this misunderstanding comes the following that I have still encountered for going into the 21^st Century. Configuration Management begins with selecting the configuration items (products) and with specifying functional, (and non-functional), requirements and design, most importantly with the product(s) requirements. Many projects in the past failed because of incomplete, inadequate, and missing requirements. Many projects that failed because of this fact many times did not find the real problem/cause until testing. Problems must be discovered early with the proper QA process (Verification &Validation/Testing) that was implemented from the beginning of the projects/programs.

We must come to grips with the fact that no matter what methodology we use, requirements have to be complete enough and stable, whether we use rapid development or iterative development processes (Agile included for each sprint/functional release). Just because the discipline (like QA) was brought into the commercial environment does not mean we have to continue to create the same problems which contribute to failed projects. The lessons learned moving forward into the 21^st Century must be acted upon.

Configuration management problems and issues:

1. Advertisements and articles on Software Configuration Management (SCM) calling SCM configuration management identification, (structure and labeling), software and version control. This information overlooks requirements (definition, analysis, and specification) and why requirements are important (one of the first steps/activities for CM). CM has always included requirement management.
2. Published books on Configuration Management presenting software and version control, composition and arrangements, but not emphasizing the selection process and requirements definition and analysis. The same problem. When I wrote my book (Software/Firmware Configuration Management), my research uncovered the same problems, that still exist, and was the motivating reason as to why I wrote my book and wanted to prevent projects from failing.
3. Many companies did not know and understand Configuration Management. It is hard to believe that some Project Managers (PMs) seem still not to understand the complete definition and application of Configuration Management. While a consultant at several companies I found out that some PMs and other project team members did know what CM was and that CM began with requirements. They understood it to be software and version control, and were considering requirements as a separate issue (Requirements Management). One mistake we made was trying to separate requirements management from its birth place of Configuration Management. These PMs had not been educated properly about CM and how to apply it, beginning with requirements and baselines no matter what methodology was used.
4. Some projects did not have a formal Change and Configuration Control Process in place from the beginning of the project. Although you may have a change process in place, you also must have within the process a Configuration Control Process (Which by the way relates to the product(s) that were selected for Configuration Management).
5. It seems that establishing a process for knowledge transfer and lessons learned is talked about but widespread enforcement and use is not established as a best/good practice.

…and while some of the most popular tools and applications were being used for only software and version control, some projects were still failing because PM and Leads overlooked the importance of requirements along with customer/user involvement from the beginning to the end of projects (close out).

Solution:

How do we correct this problem of misunderstanding, and the improper application, of Configuration Management?

1. I would say by wide spread education and training, and a collaboration of many companies throughout the industry to correct the errors of the past and define CM as it should be defined (Software/Firmware Configuration Management).
2. Understand configuration management’s definition, (the definition (its concept) that does not eliminate requirements), what it really is, and how to apply it. Improve it but don’t forget the essence of what it means and where it starts: With Requirements.
3. Do the job right from the beginning. Get management support and sponsorship. Ensure senior management understand and support the discipline. It has to be top-down and bottom-up. …and the customer and user are involved in the beginning of the project and throughout the project’s execution.
4. Share information (knowledge transfer), and using lessons learned (are we learning from our past?).

CM and QA complement one another and without good CM and documentation (that which is only required), along with good and explicit processes (while knowing it team member (people) that use/implement these processes), you won’t have a thorough and complete QA process that can be put into place for the entire system/software development process (SDLC).