I wanted to address a real problem that we in the IT industry seem to think has gone away. Understanding What Configuration Management (CM) is. As stated in Software/Firmware Configuration Management and in articles. ……. There’s simply no problem with explaining what CM is by discussing and addressing each of its processes/activities (no different than explaining the development process), but it’s wrong to address each of these processes/activities as if they are not part of the CM discipline.

Purchasers of the of the book have responded with not only that the book has been of value but now they understand that Configuration Management is more than just software version control and does include “Requirements Management”. Configuration management’s purpose is to document the system as it is being developed from requirements, through design, produced code, and then managing any configuration changes to the product/system and its related technical documentation. Software version control is a part of Configuration Identification and Control and not the primary/only concern. Why? Because before you have a product or component or module, created or in a library, you first had/have requirements and design.

Just because we have progressed to reusable code does not eliminate the first two processes or activities (i.e., Requirements Definition/Analysis and Design (Architecture and Detail). It does not matter if they are performed at some point in parallel, (when requirements are stable and agreed to), or as an iterative development process, they are still significant processes/activities for the full life cycle development process. And remember, requirements definition and analysis are the processes or activities that are required before any of the other processes are conducted (or when requirements are thorough enough and stable). How many disasters have we seen when requirements are reduced to being non-essential.
What do I mean by the above? When many discuss the entire life cycle or SDLC, "best practices processes: PM, Development, QA, and of course CM " must be performed as required. SDLC is an acronym that is identified as the system or software development life cycle, although the software development life cycle can be defined within or outside of the System Development Life Cycle. CM documents/specifies the development the product(s) during the entire life cycle until it becomes a deliverable product. The technical documentation mirrors the product, which allows configuration control to be applied. The following outlines the SDLC basic or typical processes/activities.

• Requirements (definition/analysis)

• Design (Architecture and Detail Design)

• Development/Construction: Code/Unit Test (programming and unit test)

• Testing (Integration/System Testing)

• Implementation (Deployment/Delivery)

• Support

• Maintenance

(Note: Some projects or programs have ended before Support and Maintenance are completed but all projects and programs should have been properly “Closed Out”.)
The CM process with its identified activities is a discipline that has prevented projects from failing. Each development process having CM implemented correctly using these activities as required, in the beginning, and throughout the product’s development have experience much success. CM is not just documenting for documentation sake, its concern again is for the product(s) and its full life cycle or project. The following are the processes/activities of Configuration Management:

•  Configuration Identification
  (Which always gets confused with just identifying and controling a version(s) of software and documentation with some kind of reference or structure identification or number? But it is not just that, it begins with identifying and specifying requirements and design.  

• Configuration Control

• Status Accounting

• Functional and Physical (or Design) audit and review

When each activity/process is not, or has not been, a part of the CM discipline/process, it has started a trend that allows many to misunderstand CM, misuse it processes, leave out processes when implemented, and out right misrepresent what Configuration Management is. One example is Requirements Management (and even Design Management). In the current IT environment many … seem to believe that requirements management is separated (because it has been) from CM. Taught out side the CM discipline. Which leaves one to think that it is not apart of the engineering discipline (i.e., CM) …but it complements the development process by providing documentation  of the system, product, (description/mirror it) and its maturing development until it becomes a product (application, system, etc.), to be supported and maintained throughout it’s life cycle.

Configuration Management
The same problems that existed in the past continue into the 21st Century. It is the second quarter of 2007, and we still have the same problems with Configuration Management and Quality Assurance. CM and QA when interpreted and transferred into the commercial environment without its true meaning and implementation, was/is a disservice to the industry! QA will be discussed in the 3rd Quarter Newsletter.

For 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 2007 and 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 (V&V) 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. 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).
   
   
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. Several companies I have been a consultant for, 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. They had not been educated properly about CM and how to apply it, beginning with requirements and baselines.
   
   
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 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.

Solution (Some where plug the book for use again)

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 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.
   
   
4. Sharing the 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, along with good and explicit processes, you won’t have a thorough and complete QA process that can be put into place for the entire SDLC. See RayAnn’s upcoming articles on QA in next quarter

*Take control of your project/program success with this
Configuration Management Guide:
A Practical Guide to Understand and Apply Software/Firmware
Configuration Management:
http://management.rayannpublishers.com

*Project/Program Management BEST PRACTICES Case Study/Series 1:
www.rayannpublishers.com

Send inquiries to info@rayannpublishers.com or fill out the ?Ask The Facilitator? form to have your questions,comments, or concerns addressed in our next newsletter:
http://itprofessional.rayannpublishers.com/askthefacilitator.php