Configuration Management done right = Product Centric

I recently posted a poll on LinkedIn,  triggered by a question from Rob Ferrone on LinkedIn: Is Config Management compatible with a Product Thinking approach?, I was curious how my network would respond to the question to choose one of the following 2 statements:

A: Managing configurations is executing the change process.

B: The change process is a capability to manage configurations.

The statements are not about right or wrong, but it was more about the question behind the question.  The poll is used to see whether people have a more change centric or more product centric mindset without directly asking this question (as people might be inclined to answer with what they think is the favorable answer). With only one question there is always some bias as was also evident from the comments. It still provides us with some idea as the difference between the 2 values are significant. About a quarter chose for Statement A and about three quarters chose for Statement B.

 

“Statement A: Managing configurations is executing the change process.” Tends towards a change centric mindset. Processing change by change. While it is absolutely key that you have a closed loop change process and that it is used in changing the configuration to either fix something or introduce improvements (see also More is more: Make every change count). Managing configurations requires more than just executing a change process.

“Statement B: The change process is a capability to manage configurations.” Puts the focus on the configuration, where the change process is ‘just’ one of the capabilities needed to manage configurations.

While managing configurations requires a change process there is more to managing configurations from first  requirement to decommission of the product. Think about defining a product roadmap, planning changes to accommodate the roadmap, execute these changes, apply status accounting and verify if what is built, equals what has been defined. This is also supported by standards like CM2 or SAE-EIA-649.  According SAE-EIA-649 rev C: “Configuration Management (CM) is a technical and management process applying appropriate processes, resources, and controls, to establish and maintain consistency between product configuration information, and the product.” Next to this SAE-EIA-649 rev C describes the 5 functions as being:

  1. CM Planning and management
  2. Configuration Identification
  3. Configuration Change Management
  4. Configuration Status Accounting
  5. Configuration Verification & Audit

A change centric mindset, can work in environments were you do not have a lot of changes as you are mainly in a sustaining mode, and is mostly about cost saving or managing end of life for components. However in complex products, and/or products with a lot of changes, and/or in new product introduction phases having a more holistic view from a product perspective allows for better control and more efficient processing of changes, reducing risk for the need of corrective actions. A change can have impact on other changes that are also in process, dependencies that dictate a release sequence or dependencies that require merging the change and execute as one. Not understanding changes in the context of the configuration of the product and not planning for successful implementation of all these changes, will increase rework and reduce efficiency. 

That is why I believe that: Configuration Management done right = Product Centric.

What do you think?

Photo by Linh Ha on Unsplash

3 thoughts on “Configuration Management done right = Product Centric”

  1. Martijn, thanks for cajoling such an important topic, and fundamental for a robust Systems Engineering. Based on experiences and research so far, I personally felt that Product Lifecycle Management has been actually Configuration Management of a Product (mind it, ‘a Product’) thought out the lifecycle of a Product : cradle to grave OR so called infinite Circular Economy. Hence the Digital Thread is of great importance. Thru configuration management, establishing the context is important. This context keeps evolving. Product is a time and space slice of intersection of context over the configuration. This also necessaciates that context and configuration is maintained with full bidirectional traceability, and structures (products, documents, BOM etc.) are derivatives.
    Again, interesting thoughts – and please continue cajoling such topics – and we interact more.

  2. Hi Martijn, interesting topic with nice observations. Regarding the expression ‘product centric’ at conclusion, once ‘product’ is just a mean to fulfill ‘requirements’, I’m thinking about a way to not let the ‘requirements’ forgotten far behind. Even though we all know that ‘product’ and ‘requirements’ are deeply connected, maybe it should be more clear in the context.

Leave a Reply

Your email address will not be published. Required fields are marked *

I accept the Privacy Policy

This site uses Akismet to reduce spam. Learn how your comment data is processed.