Quigley’s Corner: The Confluence

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 that 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 brakes 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 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.

The graphic below 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 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 is 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 which 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 count of product.

They are an explicit recognition of temporary modifications outside the bounds of change control system, although a deviation is, in a sense, part of that 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 errant products to the customer, perhaps shutting down the customer’s manufacturing line.

Good configuration management always leaves a competent audit trail.