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!
An important concept to track the maturation of your designs in New Product Introductions is the design maturity of a dataset.
What is a dataset design maturity?
It’s not a workflow status. It’s an indicator of what you can reliably do downstream with your dataset.
👉 A workflow status like Draft or Released tells you where you are in the process.
👉 Design Maturity tells you what you can do with it next.
When a dataset is released, it does not necessarily mean it is ready for use in a volume production setting. Design maturity provides this additional context.
Most organizations define design maturity in stages:
- Ready for Prototype – Can the data support a physical build to validate the dataset?
- Ready for Pilot – Can it validate manufacturability and repeatability?
- Ready for Production – Is it robust enough for volume, compliance, and lifecycle sustainability?
Do you need to use the change process to update the design maturity?
No, because the design maturity is a result of validation activities. For instance if you create a prototype and you confirm the prototype works as per the requirements, you can update the design maturity to Ready for Pilot. It also should not result in a new revision of the dataset, the same revision that was used for the prototype, will be increased in maturity.
Can you skip design maturity?
Sure, if you are changing an existing part, it can be that you can directly go to Ready for Pilot and skip the prototype. It is based on a risk assessment, and whether you need to go through each stage.
Can you ignore a design maturity?
So, if a design maturity is “Ready for Pilot”, could you issue regular production orders and use the dataset to produce in volume? Sure, if you have not built in any logic in your tools, you can always ignore design maturity.
In the end, that is a business decision, but you always have to be aware of the risks you are taking. In regulated industries, bypassing maturity can create compliance exposure. In less regulated industries, it may seem efficient until higher failure rates, warranty claims, and dissatisfied customers catch up with you.
💡 Treat design maturity as a risk management tool. It ensures your dataset’s integrity matches the business decision you’re about to make.
That’s where CM2 shines. It provides the framework to define, govern, and enforce maturity so organizations can accelerate confidently—without gambling with downstream chaos.
So, let me ask:
👉 How does your organization define dataset maturity?
Your experience could help shape how industries think about product development maturity.
It’s a deceptively simple question, and one that sparks more debate than you might expect.
Some organizations point to engineering. After all, they design the product, so surely they own the definition. Others assume Quality, because ”it’s Quality”. Manufacturing sometimes claims it, because they’re the ones who build. Most of the time CM is put under the ownership of the department that has the most problems and is trying to get back in control.
But here’s the reality:
👉 Configuration Management is not owned by engineering.
Engineering creates, but CM connects. Engineering is responsible for technical solutions, but Configuration Management ensures those solutions remain clear, consistent, and correct across the enterprise. If ownership stops at engineering, CM gets reduced to document control, a back-office function. And when that happens, the business loses visibility, traceability, and ultimately…credibility.
👉 CM must be aligned with all processes.
CM is not a single step in the lifecycle; it is the thread that binds every step together. From requirements definition to design, from procurement to production, from service to sustainment, CM is what ensures everyone is building, testing, and delivering against the same definition of truth.
Think about it this way:
- If supply chain isn’t aligned, parts arrive that don’t match the current design.
- If manufacturing isn’t aligned, products are built to yesterday’s revision.
- If service isn’t aligned, customers receive updates that don’t fit their configuration.
The result? Rework. Delays. Scrap. Lost trust.
But when CM is integrated into all processes, when every decision, change, and requirement is connected, you get speed, clarity, and confidence. You get the digital thread that works.
📌 In CM2, the world-class standard for Configuration Management, ownership isn’t about a single department “holding the pen.” It’s about embedding CM into the DNA of the organization, so that every function speaks the same language of traceability and accountability.
💡 Here’s the real takeaway: Configuration Management isn’t a department. It’s a discipline that needs to be integrated throughout your organization. So, whoever owns CM in your organization, needs to mature the discipline and align it with all functions of the organization. CM must be able to act as an unbiased 3rd party.
So let me ask you: In your organization, who “owns” Configuration Management, and how aligned is it across your processes?
Your answer shapes more than your internal efficiency. It shapes the reliability of your products. The satisfaction of your customers. And the strength of your reputation in the marketplace.
Everyone loves the shiny side of developing new products. The innovation. The speed to market. The “sexy” features that light up roadmaps and wow leadership.
But how often does serviceability get the same spotlight?
It’s often pushed off as a “later” problem. After all, who wants to slow down a launch to think about what happens three years from now when a field engineer needs to service the product?
Yet, when organizations don’t define and manage the as-maintained configuration during new product introductions, they aren’t just saving time. They’re planting the seeds of a future crisis.
What does that crisis look like?
- A product ships without a clear baseline.
- Service teams are left piecing together outdated drawings and inconsistent documentation.
- Downtime increases because the “as-maintained” configuration is incomplete.
- Maintenance costs balloon as teams waste time troubleshooting.
- Quality issues start to erode customer trust.
That’s when you have an as-nightmare instead of an as-maintained configuration.
The as-maintained configuration is not optional. It is not paperwork. It is not “extra.” It is a core deliverable of new developments.
If you capture it early, you:
🔹 Enable faster, more accurate service interventions.
🔹 Protect revenue streams tied to aftermarket and long-term support.
🔹 Strengthen the digital thread by connecting as-designed → as-built → as-maintained seamlessly.
🔹 Create customer loyalty by delivering quality during the entire lifecycle.
But if you don’t? You rob future teams of the resources, clarity, and trust they need to succeed. You force service and support into firefighting mode. And you pay for it in cost, time, and reputation.
The mindset shift:
Instead of an afterthought, consider serviceability as an integral part of innovation. The ability to maintain, support, and extend a product’s life is as critical to success as launching it on time. In the end, the long-term experience of the product is a key indicator when it comes to customers returning for more and ordering upgrades, not the on-time launch of the product.
So, let me ask:
👉 How do you manage the as-maintained configuration, and when do you start, early or later?
Because “later” has a way of turning into as-nightmare.
Check out the other How Do YOU CM2? posts.
Copyrights by the Institute for Process Excellence.