The Confluence:
The Confluence:
Configuration Management, Change Management, and Project Management
Like Puzzle Pieces
Configuration management, change management and project management are all connected. Missing one or more of these in product development can mean exceeding the project budget and schedule at best, and at worst, the launching of a product that is more like a torpedo on the customers, not in the least beneficial but destructive. These three are fundamental product development process, no matter the approach to managing the project (agile or conventional approaches).
Experience indicates to be effective requires running a competent configuration management program will reduce faults throughout the product development effort, especially when it comes to prototype development and product testing. A failing configuration management program results in considerable rework, the larger more distributed the system, the more costly to the organization for a poorly run configuration management system.
In general, the enterprise is completely dependent on robust configuration management, whether the product is software, firmware, or hardware. Developing systems with insufficient configuration management will result in rework, which is a cost without adding value. Additionally, sending the customer, the incorrect version of a product may well result in recovering the errant parts, rework, shutting down the customer’s manufacturing line and ultimately being de-sourced.
Purpose of Configuration Management
Configuration management systems are essential to coordinating software and hardware deliveries. In distributed systems, configuration management does this same thing but on a larger scale. For example, configuration management ensures that an instrument cluster (developed by one supplier)-will fit into the dash opening (developed by another supplier), and that the screws align with the mounting tabs. For vehicle electronic systems, the way the anti-locking brake systems (ABS) works with a transmission system and the engine are also on that list. How do these components fit together, physically, electrically, hydraulically, and via serial communications links (what specific messages)?
Configuration management does this by making it easy to identify features, interfaces, and functional content within a particular software, hardware, system, and other product characteristics. For product development this is very important as part of a successful product development endeavor will require iterations of the product to be available (prototypes) for exploration and opportunities for learning. The project will have these iterative and incremental prototype deliveries is a maturing of the product over time and this will end up on the project schedule.
Configuration management provides straightforward traceability of function and feature growth of specifications and product revisions over the prototype iterations. Throughout the process, we will always clearly identify the content of the product or system, execute pre-release containment, and identify compatible components within a system. This will make future statements about the capability of the product and system with increased reliability.
This graphic provides an overview of the typical interaction as a result of writing specifications, prototype development, and the updates that happen as we learn about the product requirements. We start at the product needs, as we first enter the system through the definition of the product expectations.
Configuration management and planning
Perhaps a few good examples are a good way to demonstrate the lack of configuration management impact. A combination of hardware and software comes into the testing department. There are more than 3000 requirements that will be in the final system incarnation. The first iteration (prototype) of the system comes in for testing. This specific iteration of the product has limited features, not the entire 3000, this is an early prototype. What features should the testers, well, test? Should the testers test all 3000 test cases that match to the requirements? Why? Many of the product’s features are not yet delivered.
Consider also the development of a wire harness that must fit into a vehicle. A specific iteration of the wire harness will go into a specific prototype iteration of the vehicle. As the wire harness is being placed into the vehicle, a bracket it encountered, and the wire harness will not fit into the vehicle. It turns out, a mounting bracket for a part was added without considering the impact on the wire harness. Now the wire harness will need to be reworked to fit into this prototype vehicle – amounting to rework.
To deliver a robust product (hardware, software, or system product), it is necessary that we plan the iterations of the product via the prototype availability. Essentially, functionality, iterations delivered (prototype), testing, and production follow a growth plan rather than entirely ad hoc. Sufficient planning would eliminate the two aforementioned product development failures. The planning makes it possible to know the following items:
- Features and feature revision level
- For example, engine electronic control unit, cruise control rev 1.0 within a particular software revision
- Software revision level (and capabilities)
- Hardware revision level (and capabilities)
- Subassembly revision level in the case where we have firmware ‘burned’ onto a chip
- Systems integration (phased feature release)
Configuration management areas application areas
Configuration management should be applied to specifications (documentation), models and simulations, hardware, software, the combination of hardware and software, and to subsystems and systems integration. The truth is that configuration management can be applied the just about anything.
In a manufacturing facility, we might see the following approach to Configuration Management, namely:
- Product baseline
- Product change management
- Number of product changes (nature of the changes)
- Time spent on product changes
- Cost impact of changes
- Product configuration (CMP)
- Test configurations (test coverage)
- Configuration audit
The items in the list apply to both software and hardware for the most part.
Configuration Management Process Areas
Military standard 973 and military handbook 61 describes the four processes for any effective configuration management system. We are not going into those details, perhaps in future articles. It is sufficient to provide the list:
- Configuration Planning
- Configuration Identification
- Configuration Control
- Configuration Status Accounting
- Configuration Audit and Verification
Release notes
Release notes are linked to a specific iteration of the product (hardware, software, combination or system) configurations by part number with the product feature content, description of partial functions and known bugs identified. The release notes are also linked to the product, again by part number, revision levels, software modules, functions / features, and known bugs.
Change management
Change management is an umbrella term that contains configuration management and project management changes to scope, time and cost. Changes management is the initiating point for differentiation in the documentation for the product as well as the product. A successful change management system will not only include the definition of the change materially, but also have system impacts (if this part connects to others) as well a cost and time, and as such will require formalized agreement prior to the assimilation of the change into the project scope and planning work.
Managing product iterations
No matter whether the product is released to production or is a developmental iteration for testing, the product should be managed under the same controls. Control must exist for engineering release documentation, design change notifications, product change requests, and any similar or associated documentation. Any automotive, commercial vehicle, or ISO-certified organization must have configuration management for released products to avoid contaminating the supply chain with nonconforming material.
Configuration and systems development
With systems development, we will have multiple configurations making up a system configuration and multiple “releases” of configurations. Many organizations deliver the functions of the system in stages, with certain features in each component that comprise the system. This extends to items such as customizable product parameters (for example, those stored in non-volatile memory) alter the product features to customer demand, increasing adaptability and customer contentment. All of this requires updates to the system configuration and tracking of the revision progression. Under these conditions, we would expect more branching and less merging of configurations.
Deviations
Deviations are a written authorization granted before manufacturing a product that allows us to release the product from meeting one or more requirements. These documents only work if they represent a temporary condition that is controlled by time or by an account of the product. They are explicit recognition of temporary modifications outside the bounds of the long-term change control system. As with all forms of configuration management, deviations require an identification method such as serialization, part number control, or some other marking. Deviations not adequately accounted for and communicated can cause great harm to a project and product development and verification.
Configuration failures
When the system breaks down, we can see non-functional components and systems. Testing may become inefficient with reporting of faults that are not valid because that portion of the product has yet to be built. This tracking of non-existing faults is bad, worse yet is testing functions that have not been built yet, a stone waste of effort. This costs the project cost and will extend the schedule as we perform work at least twice, if not more. We may also miss expected functions (that are in the product but the testers do not know) as well as see duplication of cost in order to test again. We have also seen situations where a supplier shipped prototype parts with an unknown hardware version and an unknown software version—the product didn’t work on arrival at the customer site. Additionally, we have seen times when the product does not fit into the rest of the system (mounting or wire harness routing) all of which may result in a loss of the customer’s business.
Conclusion
I think the connection between configuration management, change management, and project management should be clear now. We say that configuration management is indispensable to delivering quality products. It should also be clear that uncontrolled change in the product or system likewise puts the project at risk. Failure to manage the configuration or changes to the product as we learn will put the project at risk of numerous, highly probable, and server failure modes. These failures modes start long before we are to sending the wrong item to a customer or fixing the wrong version of the product whether software or hardware. Not paying attention to these product and project management disciplines will likely deliver an errant product to the customer, perhaps shutting down the customer’s manufacturing line. Good configuration management always leaves a competent audit trail.
