| Configuration management entails a number of benefits, such as savings and better quality, and a number of costs related to tools, workings hours, and so on. Both will vary from company to company. Configuration management also provides an element of "insurance," by helping, through a relatively small investment, to prevent situations that could cause considerable expense. To find the right level of ambition for configuration management in a specific context, it's important to calculate profitability based on the potential for savings and the concrete costs. It's also important to measure whether the costs and the benefits are realized as expected. The following procedure is recommended at the start of every initiative of implementation or improvement of configuration management in a company or a project: -
Produce a list of the potential savings for the company/project, including related estimates for economic value. Produce estimates for each alternative. -
Estimate the expenses. Again, produce estimates for each alternative. -
Prioritize the effort in view of profitability and in coherence with the strategical focus of the companytypical examples on strategical focus areas are customer satisfaction, productivity, quality, and so on. -
Follow up to ensure that expenses as well as savings are realized as expected, and use the experience to refine your estimating capability before the next improvement effort. Expenses Expenses, which must be foreseen, depend on the chosen level of ambition. They may, for example, consist of the following entries: Savings Savings may stem from preventing one or more of the following: -
Correcting the same error in several places -
Performing work on the wrong basis (e.g., outdated requirements) -
Having errors corrected once reappear -
Introducing unwanted functionality -
Not knowing which version the customer has received -
Upgrading free due to incompatibility with old equipment -
Performing redundant coding -
Transferring knowledge to new employees goes wrong Possible savings depend on the problems the company experiences. Table 5-3 shows details of some of these problems, a description of how configuration management may solve them, and a suggestion for estimating the economic value. This table is not a complete checklist but rather a suggestion for some of the more common problems, which may indicate that improvement or introduction of configuration management will be profitable. It may also be used as inspiration to identify other problems that are particularly relevant for the company. For example, the company may find that it is -
Difficult or impossible to reestablish a running product -
Difficult or impossible to make changes in an existing system -
Difficult or impossible to revert to an earlier version that works -
Difficult to establish a stable decision, because decisions are constantly reversed Table 5-3. Examples of Possible Savings Using a Configuration Management System | Problem | Benefits of Configuration Management | Economic Value | | The same error is correctedand then in turn found and corrected by other people in all the other variants of the product. | Immediate recognition of all affected variants and correction of the error at one time in the entire configuration item family. | ( n 1) x (time for diagnosis and correction of error in item in n variants) and possibly Savings in travel time and so on by handling all products/customer installations at one time. | | A design is produced based on outdated requirements, or a test is performed on the wrong version that contains already found errors. | Registration of status and history for all configuration items. | Time spent working on the wrong basis. Qualitatively (less measurable): Employee satisfaction. | | Old errors reappear when a new version is delivered to the customer. | Recognition of all versions of configuration items as well as all changes from version to version. | Time spent finding and correcting old errors. Qualitatively (less measurable): Greater customer satisfaction due to better quality. | | Designers or programmers introduce functionality not covered by requirements. | Only functionality that can be traced to an approved contract and/or requirement specification or change request is included. | Time spent implementing (designing, coding, and so on) the unwanted functionality and Time to recognize the "gold plating " and Time to consider the problem and (Time to remove the "gold plating" or Time to follow it through [requirement, test, user guide, and so on.]) | | Error at customer is hard to find, since it's unknown which version the customer has. | Immediate knowledge about the customer's version. | Time spent identifying the customer's version and/or Saved travel time and expenses (if onsite error correction is needed, for example, because the problem can't be re-created at home) and/or Saved rebates at the next sale to the same customer resulting from loss due to the error and/or Saved day fines while the customer is waiting (shorter downtime) and/or (less measurable): Extra sales due to greater customer satisfaction with regard to service. | | Extra sales to a customer. Since it's unclear if existing equipment is in a version that will work (e.g., exchange data) with new equipment, it's decided to upgrade all the old equipment free, to be on the safe side. | Information about which changes have been made in which versions combined with knowledge about which version the customer has bought earlier. | Time and material used for the upgrade of the old equipment. Qualitatively (less measurable): | | The same functionality is developed over and over in a number of products. You know it, but you drop the idea of finding and isolating the code that is implementing the functionality in one of the other products. | Reusable items are easy to find. | Estimate for new development of itemstime to fit the items to new environments. | | A new employee is to enhance the product and sits down to get acquainted with it by reading the documentation. The employee will design the enhancements on the basis of that information. It turns out that the documentation has not been updated and doesn't correspond to the source codeso the employee must start all over and read the source code. | Registration of the relationships between source code and corresponding documents, changes, and date and time for updates. | Time spend on designing on the wrong basis. Qualitatively (less measurable): Employee satisfaction. |  |
