When Configuration Management Goes Wrong
We have seen situations where poor configuration management has led to embarrassing situations with customers. In one case, a supplier shipped parts to a relatively new customer in which neither the hardware revision nor the software version were known. The parts arrived at the customer location for demonstration by a senior sales manager–none of them worked!!! Consequently, a senior sales person was left blowing in the wind and this new customer was less than impressed. Ultimately, this product was dropped by the customer, representing a waster of marketing, sales, engineering development time, and early production runs.
When working with software, it is incumbent on the developers to assist the management process by including internal documentation of the code (by the way, we consider internal documentation to be significantly more important than external documentation). We have seen a developer come upon some historical code that was prime for renascence and end up wasting days and weeks trying to resuscitate an unknown version with unknown capabilities! Again, we see wasted effort, wasted time, and wasted revenue. Development tools must come under configuration management, especially when we are dealing with cross-compilers and other peculiarities of the embedded development world.
Configuration management also has the benefit of letting the test groups know what they are really testing. When a test group is unsure how to configure the software, or the system, many hours are wasted. We test things that are not included yet in an iteration of software. If this is part of a larger system our problem gets much larger as we are unsure what systems features are supported by the system, therefore we do not know what should be tested. We waste time testing features not developed; we waste more time writing fault reports. Without configuration management, our test engineers may not know what or how to configure the product for the tests. Of course, the test group should have their test tools and plans under configuration management also. At the start of the test the test engineer should make note of the relevant part numbers (hardware and software) providing traceability back to the configuration management plan. When all is well, the test group will be able to execute promptly and present a meaningful report upon conclusion.
One Response to When Configuration Management Goes Wrong