The Pro's And Con's Of CM
by Vince Guess
Yes, traditional approaches to CM provide a way to know, design-wise, what the last one was in order to build an identical one or one that is different in ways that it is supposed to be different.
Yes, traditional approaches to CM require that design requirements be approved and released and that changes be authorized and controlled.
The pro's and con's of CM can be summarized very simply. The intent is good but the process is poor. Although the intent is good, it is limited to design definition. That is because the process is poor.
An organization must do two things to sustain a competitive edge; continually improve the integrity of their "released information" and continually improve their ability to accommodate change.
An organization runs on many types of information. Design definition is only one. Any information that can affect quality, safety, schedule and/or cost must be managed. It must be validated and released. Changes must be authorized. All information must be subjected to CM. (per CMII)
Complex Problem; Simple Solution
Belief that complex or high cost problems require complex or expensive solutions is a paradigm. That is rarely true. It is not true in this case.
The problem has rarely been more complex/costly. The solution has rarely been more simple. CMII.How CM Began
Whether it was a desire to build another one like the first one or a desire to maintain that first one, CM began for the same reason. No one knew for certain what the first one was.What Was It Supposed To Be?
"Change" is the name of the game in most development programs. Could it have been done right the first time if everyone had known at the beginning what they knew at the end? Could all of those changes have been avoided? Should development begin without validated requirements?
Many types of information must be managed during development, from end-item application requirements and design definition, to process definition and as-built records. Changes come in every size, shape and form. One change to one set of information can ripple through all of the other sets.
Due to the pressure of schedules, physical items are often changed first with the "paperwork" to catchup when there is time. There is never enough time.
"Release" is a dirty word to a developer trying to be fast and flexible. To release it is to increase the paperwork obstacle. Solution? Do not release it.
So here we are. Shall the requirements be validated and released or not? Shall we lock CM in or out?
Institute of Configuration Management Scottsdale, AZ 85261-5656 Tel: (480) 998-8600 Fax: (480) 998-8923 Email: info@icmhq.com