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 only continue to create and publish high-quality articles that I can fully endorse. Enjoy this new series, and please share your thoughts!
In case you missed it, here are the 3 How Do YOU CM2? posts. Also, make sure you check out the previous newsletter article: The #1 Constraint on Innovation Isn’t Technology, It’s Fragmented Change Management.
Stop Calling Product Changes: “Engineering Changes”!
What do you call a change to a product? And no, this is not the start of a joke; it is a serious question. Do you call it an Engineering Change? If so, please consider stopping doing that.
A change to a product is almost never solely limited to an engineering scope. It will impact the supply chain, it will impact manufacturing, possibly your production line or facility, it might impact service and upgrades. It could be that people in manufacturing or in the field need to get certified to work on the resulting parts in question.
I heard about a company that got a request from an important customer to develop an improved version of an existing product. The customer requested a quote, and the company provided a quote solely based on the input from engineering. However, to be able to achieve the requirements of the customer, the product needed to be assembled in a clean room with ISO 14644-1 Cleanroom class 5. However, the current production facility was rated at class 8. You can probably guess what happened next. It was clear that a change request to the product also impacted the entire production facility of the company.
“The only type of change that exists in a company is an Enterprise Change.”
🖨️ Oh, this is “just” a print change.
Actually, that tolerance change means we have to modify the:
- 🧑🏭 assembly fixture;
- 🧪 test rig;
- 🧑🏫 instructions for serviceability.
Not to mention, we have:
- 💰 $1M in purchased materials at the supplier;
- 📅 6 months of inventory.
So, calling it an Engineering Change limits the scope, even if unintended, it limits how people view the change. That results in not looking beyond the engineering impact, not involving the right people to do an impact assessment, and ultimately resulting in a lot of extra rework, cost, and/or compliance issues.
It’s like calling something having an autopilot that does not function autonomously. People will make the wrong assumption and end up killing or hurting themselves or others. Words have meaning, and meaning guides our assumptions. An engineering change is just the engineering scope of a change, but there will likely be manufacturing scope, supply chain scope, and customer support scope related to the same change.
Changes almost always require cross-functional alignment, typos excluded. And you know what, having these cross-functional alignments helps the different functions to learn from other functions. This makes for a much more resilient and scalable organization, a well-oiled machine, ready for the next challenge.
So please, call it a change or enterprise change or anything that does not limit the scope by its terminology. If enough people do this, you will see that the assumptions made will also change.
What do you think? Share your thoughts in the comments and keep building a more robust future for Configuration Management together!
Impact Analysis: The Secret Ingredient No One Wants To Do!
It’s a familiar scenario, isn’t it? We’re all wired to solve problems. We identify an issue, envision a solution, and our brains immediately jump to implementation. We tend to gravitate towards solutions and implementing solutions, but this tendency causes us to forget or skip impact analysis of the proposed solution.
This isn’t just a minor oversight; it’s a blind spot that can lead to costly rework, unforeseen dependencies, and a cascading effect of issues down the line. Especially if you know that:
😞 𝐀𝐛𝐨𝐮𝐭 𝟒𝟎% 𝐨𝐟 𝐭𝐡𝐞 𝐜𝐡𝐚𝐧𝐠𝐞𝐬 𝐚𝐫𝐞 𝐚 𝐜𝐡𝐚𝐧𝐠𝐞 𝐨𝐧 𝐚 𝐜𝐡𝐚𝐧𝐠𝐞, 𝐢𝐧 𝐨𝐭𝐡𝐞𝐫 𝐰𝐨𝐫𝐝𝐬 𝐚 𝐜𝐨𝐫𝐫𝐞𝐜𝐭𝐢𝐯𝐞 𝐚𝐜𝐭𝐢𝐨𝐧.
That statistic alone should make us pause and reflect. A staggering 40% of our efforts are spent on fixing changes! Not to mention the opportunity cost! If the change is worth doing, then it is worth doing right the first time. Proper impact analysis and planning don’t hurt anybody; it doesn’t stifle your speed or agility.
Why do we skip this vital step? Is it the perceived time investment? The complexity? Or simply the human inclination to “act” rather than “think”?
🧠 𝐂𝐌𝟐 𝐭𝐞𝐚𝐜𝐡𝐞𝐬 𝐮𝐬 𝐭𝐡𝐚𝐭 𝐜𝐡𝐚𝐧𝐠𝐞 𝐢𝐬 𝐢𝐧𝐞𝐯𝐢𝐭𝐚𝐛𝐥𝐞, 𝐛𝐮𝐭 𝐜𝐡𝐚𝐨𝐬 𝐢𝐬 𝐨𝐩𝐭𝐢𝐨𝐧𝐚𝐥.
Effective Impact Analysis isn’t about slowing down the change process; it’s about accelerating successful change. It’s about meticulously understanding:
– What components, documents, or systems will be affected?
– What are the potential ripple effects on other projects or products?
– What resources (people, budget, time) will be required for the change and its downstream impacts?
– What risks are we introducing or mitigating?
When done correctly, Impact Analysis transforms a reactive approach into a proactive, strategic one. It’s the difference between blindly forging ahead and navigating with a clear, illuminated path.
Impact analysis is not about slowing things down. It’s about enabling speed without sacrifice. It’s the secret ingredient to:
– Preventing rework.
– Ensuring downstream alignment.
– Building cross-functional trust.
– Maintaining digital thread integrity.
– Customer Trust
⏰ 𝐐𝐮𝐢𝐜𝐤 𝐫𝐞𝐚𝐥𝐢𝐭𝐲 𝐜𝐡𝐞𝐜𝐤:
If your impact analysis looks like:
– “Check with engineering”
– “Email manufacturing”
– “Hope for the best”
You’re not doing impact analysis. You’re flipping a coin.
💡 𝐂𝐌𝟐 𝐁𝐞𝐬𝐭 𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐞 𝐓𝐢𝐩:
Start treating impact analysis as a standardized, teachable, measurable process—not tribal knowledge. Use a CM2 Change Process that enforces structured evaluation of impact before approval. Track the First Time Right Yield to measure progress. You’ll see fewer corrective actions and a more agile system.
So, I want to hear from YOU, the CM2 and PLM community!
How do you ensure thorough Impact Analysis is conducted in your organization? Share your insights below!
CM2 Baseline: how to make Impact Analysis easy!
In the previous edition of How Do YOU CM2?, we talked about Impact Analysis and why it is often skipped.
👉 One of the main reasons? It’s not always easy to do.
If you can’t find the data or understand the dependencies, how can you perform a proper impact analysis?
🔎 This is where the 𝐂𝐌𝟐 𝐁𝐚𝐬𝐞𝐥𝐢𝐧𝐞 comes into the picture.
𝐓𝐡𝐞 𝐂𝐌𝟐 𝐁𝐚𝐬𝐞𝐥𝐢𝐧𝐞 𝐢𝐬 𝐭𝐡𝐞 𝐜𝐫𝐲𝐬𝐭𝐚𝐥 𝐛𝐚𝐥𝐥 𝐭𝐡𝐚𝐭 𝐚𝐥𝐥𝐨𝐰𝐬 𝐲𝐨𝐮 𝐭𝐨 𝐬𝐞𝐞 𝐩𝐚𝐬𝐭, 𝐩𝐫𝐞𝐬𝐞𝐧𝐭, 𝐚𝐧𝐝 𝐟𝐮𝐭𝐮𝐫𝐞.
It’s the gateway to all the single sources of truth. You can see how it was connected, how it is connected, and how it will be connected.
Let’s unpack that.
Imagine trying to forecast the weather without satellite imagery or historical data. You’d be guessing. That’s what performing Impact Analysis without a CM2 Baseline is like: guesswork in the dark.
💡 A proper 𝐂𝐌𝟐 𝐁𝐚𝐬𝐞𝐥𝐢𝐧𝐞 turns Impact Analysis from a painful process into something as easy as looking up the weather forecast.
When implemented correctly:
– You gain full visibility across product, process, and people interdependencies.
– You make decisions based on truth, not assumptions.
– You prevent rework, cost overruns, and unnecessary delays.
👎 𝐖𝐢𝐭𝐡𝐨𝐮𝐭 𝐂𝐌𝟐 𝐁𝐚𝐬𝐞𝐥𝐢𝐧𝐞:
Your team needs to implement a critical design change. Without a robust CM2 Baseline, you’d spend countless hours manually tracing dependencies, sifting through disparate systems, and crossing your fingers that you haven’t missed anything. This isn’t just inefficient; it’s risky. A missed dependency can lead to costly rework, delays, compliance nightmares, and even product failures.
🚀 𝐖𝐢𝐭𝐡 𝐂𝐌𝟐 𝐁𝐚𝐬𝐞𝐥𝐢𝐧𝐞:
But with a well-implemented CM2 Baseline, the process transforms. You have immediate visibility into every impacted and affected item, every dependent dataset, every stakeholder. You can instantly understand the ripple effect of any change, empowering you to make informed decisions. This isn’t just about speed; it’s about precision, control, and significantly reducing risk while remaining agile.
𝐇𝐨𝐰 𝐜𝐚𝐧 𝐈 𝐠𝐞𝐭 𝐭𝐡𝐢𝐬?
🔗 𝐋𝐢𝐧𝐤𝐚𝐠𝐞𝐬 are the secret ingredient combined with knowledge graph technology.
You most likely already identify your parts, datasets, and link them in one way or another. So the hard part is already done! Some links can even be inferred with some basic logic. While this information currently resides in multiple application databases, you can create a knowledge graph that connects all of it in one graph, which represents your CM2 Baseline.
What’s your biggest challenge when it comes to performing Impact Analysis? And how has your organization leveraged (or struggled with) baselines to overcome this?
Share your insights in the comments below! Let’s elevate the conversation around effective Configuration Management.
Check out the other How Do YOU CM2? posts.
Copyrights by the Institute for Process Excellence.