I published a book, but the book was not the focus, it was my attempt to reach a wider audience as soon as possible to: (1) correct the mistakes that had been made translating and applying configuration management and quality assurance (2) share best practices and (3) promote successful projects. I did not plan to self publish but I was concerned about the time that it would take to have the information available for use to the IT industry and individuals that needed to understand the processes. Several publishing companies had requirements (selecting of subjects for publication) that indicated it could take a year or two before the book could/would be on the market. I researched publishing and major reviewers' requirements and joined and met with some publishing companies and authors (including self published) to understand what was required to start the company and publish books.

When you read the book it has information that is useful for project managers and other IT professionals in commercial, government and aerospace. Although you reference several standards such as ISO, PMI, and SEI/CMM, you use several DOD standards as examples?


Yes, the information (content) in the book can be useful to any industry implementing or executing IT development and technology projects but my initial research and review of failed projects discovered that certain processes such as configuration management were misrepresented, incomplete, or missing all together. To correct the problem, especially since I was challenged once with the statement, "That every one has their definition.", I thought a historical perspective was required. Yes, but Configuration Management's origin is the Department of Defense (DOD) and the aerospace environment. Other organizations developed, revised, and modified standards to accommodate a wider audience (commercial, international, etc. and not just have DOD or USA ownership or flavor). One example: Did you know that ISO 9000's development was influenced by military standard MIL ?Q- 9858, a quality management standard. Nothing is wrong with what took place but it is a mistake to leave behind significant requirements to manage and control a project and a product's development. To this point, some of us seem to be just realizing that companies must include requirements management, change/configuration control, quality assurance (instead of just testing), and true product management and control (configuration management, instead of just on line code control and change/problem tracking). Configuration management begins with requirements. Many are now realizing, hopefully, that project management is not just reporting but managing the project from initiation to close out and being responsible for the development, configuration management, and quality assurance processes.

The CM discipline entails specifying requirements and design, documenting code or the product's implementation, change/configuration control, code control, and security/access control. It's just that in the commercial environment,
the technical skill requirements were pulled into the arena first and the rest was left behind: that is system and project management, configuration management, and quality assurance.

My commitment to CM processes has been key to my success in managing projects, and establishing dynamic teams without which no project would be successful.

Transfer knowledge and share lessons learned not later but now, in the 21century.