This article is part of the How Do YOU CM2? blog series in collaboration with the Institute for Process Excellence (IpX). Although I receive compensation for writing this series, I stand behind its content. I will continue to create and publish high-quality articles that I can fully endorse. Enjoy this new series, and please share your thoughts!
Do you have mature CM processes that actually work across the entire lifecycle?
Because CM process maturity isn’t about having procedures on SharePoint. It’s about whether the process is consistently defined, applied, measured, and continually improved, and enables the changing needs of an organization.
👉 Takeaway:
If your CM process is not standardized, adaptable, compliant, and pragmatic, maturity will remain a paper exercise.
Start with the foundation.
A mature CM organization has documented, validated, and released CM processes under formal change control and accessible to all stakeholders. That process is explicitly based on recognized standards such as CM2 and SAE-EIA-649.
But maturity doesn’t stop at documentation.
The CM process must be defined in a way that:
- Accommodates product and project lifecycle differences
- Preserves company-wide CM principles
- Applies consistently to products, facilities, and even administrative information from single sources of truth
- Uses KPIs to monitor performance and guide continual improvement 📊
Where many organizations struggle is with application at scale. True process maturity means CM is applied:
- Across all lifecycle phases — from concept to decommission
- To products and facilities
- To CM itself, including changes to CM strategy, processes, and documentation
- With measurable success, supported by defined KPIs
Then comes the heart of CM discipline, closed-loop change traceability. Mature processes are clearly defined:
- Ownership of configuration information
- Closed-loop change traceability for all configuration information
- Embedded customer and supplier involvement when required
- Transparent status accounting (as-designed, as-built, as-maintained, etc.)
And yes, the classic CM pillars still matter:
- Configuration Planning with clear maturity expectations
- Configuration Identification with naming, numbering, baselining, traceability, and Model-Based Engineering support
- Change Management with impact analysis, governance, and differentiated change tracks
- Status Accounting that reflects reality, not intent
- Verification and configuration audits before release to customers
A CM process is only mature if it survives complexity, change, and scale.
Not because it’s rigid, but because it’s well-governed, measurable, flexible, fit for purpose, and continually improved.
👉 Where does your CM process struggle most today: definition, application, or measurement?
I’d be interested to hear your view.
Note: the following post around maturity assessments will focus on Knowledge and Support, and Tools.
Copyrights by the Institute for Process Excellence
Don’t forget to subscribe to this newsletter and follow me