Why PLM Implementations Fail After Go-Live (And How to Fix Adoption)

Most PLM implementations that "fail" aren't technically broken. The software works. The organization simply kept running its old processes and never made the people-and-process changes that adoption requires. Companies that have run PDM or PLM for decades often use a modern platform the way they used a 1990s file drive — as engineering-only storage, which is a small fraction of what PLM does. Real adoption comes from redesigning the process and getting engineering and manufacturing working from one shared design package, not from the tool alone.

Want to go deeper? Watch this video:

Nobody buys a $2M system and shelves it — they grow into it

The picture people imagine — a company buys expensive software and abandons it on day one — is rare. What actually happens is slower and more expensive.

A company has some form of PDM or PLM for decades, often predating Windchill. As they upgrade off deprecated software, they invest in a genuinely capable, modern PLM platform — frequently paying millions of dollars a year on subscription. But they keep using it exactly the way they used the old system: a place to store engineering files.

That's the trap. They're paying for an enterprise platform and getting a network drive. And because "it's always worked that way," nobody stops to ask what the new capabilities are, how the company should mature its data management, or how PLM could connect strategically to other systems. It gets quietly filed under "engineering-only application."

The metrics PLM should actually move

The way out of that trap is to stop asking "is our data stored?" and start asking "what business metric are we trying to move?" A few that PLM directly affects:

• Cost of poor quality. Shop-floor rework, quality defects, and non-conformances — anything that deviates from the as-planned build and adds unanticipated cost. Most companies only measure the shop-floor portion and never quantify what a revision change back through engineering actually costs. (Some who have measured it put a single drawing revision at ~$40,000 in direct labor alone — before the churn.)

• Engineering change cycle time (ECN). How long a change takes to move through the system from one revision to the next. If a company can't answer this, it isn't really doing change management — it's running changes through email and phone calls.

• First-pass yield.

• On-time-in-full (OTIF). Beware the vanity version: teams that look "always on time" because they quietly push the due date every time they're about to be late.

• Time to productize. In regulated industries like medical device, a full production release can take six months simply because the data wasn't captured properly during R&D. Done right, that can drop to under four weeks — at the cost of doing more work up front.

Case study: an 85% cut in cost of poor quality

One manufacturer set out with a modest goal: use the system to make employees more productive. Instead of treating PLM as engineering-only storage, they integrated engineering and manufacturing around a single design package — EBOM to MBOM, process planning, 3D visualizations, and work instructions built in the system and published to MES and ERP simultaneously.

Because everyone worked from one design package, product hit the shop floor far more accurately. Previously, the shop floor caught mistakes and bounced them back to engineering — about 450 changes a year, each one a cycle of churn. Afterward, that dropped to about 40.

Cost of poor quality on that line fell 85%. It more than paid for three years of process development and change work — and quality wasn't even the original target. The freed-up capacity could then go to value-added work: developing new product instead of sustaining old product.

Why people go back to Excel (and break the digital thread)

Here's the pattern that undoes adoption. The system can do the job, but people pull the data out into Excel anyway — usually for reporting or BOM manipulation. Why?

Often they were simply never shown how to filter or build a report inside the system. Sometimes they're intimidated: doing it "for real" means a revision change, so they'd rather have a scratch pad to play in. So the work happens in a spreadsheet nobody else can see.

Then the damage compounds. That Excel file becomes an unversioned, invisible source of truth. The data in the system changes underneath it. The spreadsheet flows downstream into another system that no one reconciles. Now there are two versions of the truth and a quality problem no one can trace — and when someone insists "our process is broken, the system is bad," the real cause is that the system of record was abandoned the moment the data was exported.

This is what a broken digital thread looks like. The thread appears fully digital right up until you notice the hands holding it together — a person in the loop who has to remember a manual step for it to work. One vacation or one forgotten step and it snaps. The goal is systems that talk to each other on trusted, triggered events, so the thread holds without anyone holding it.

The discipline: every time someone exports to Excel, ask why. Nine times out of ten, the system can already do it — they were just never shown how.

Continuous improvement, not blame

Adoption also depends on how an organization treats mistakes. Lean manufacturing, the Toyota Production System, and Lean Six Sigma all assume you will catch problems, go back, and fix them. The best companies expect mistakes and build the loop to learn from them.

That's why a CAPA (Corrective and Preventive Action) should be an opportunity for improvement, not a punishment. When teams treat opening a CAPA as getting sent to the principal's office, they hide problems instead of fixing them — the opposite of what the process is for.

One caution on language: "fail fast" is the wrong framing. It reads as "don't think, just ship something we know will break." The useful idea underneath it is simply stop being so risk-averse and take the right risks — deliberately, not carelessly.

When a rollout is really a rescue

Walk into a struggling project and the tell, usually within the first hour, is in the people. Get engineering, manufacturing, and supply chain in the room and the disconnects surface fast — the dirty laundry comes out because someone is finally there to advocate for change.

And the recurring finding is this: the implementation is usually fine, or only slightly off. It's the business process and the people that need the rescue. The business hasn't evolved the way it should have. Fixing it means investing in the process and the people — helping everyone understand that they're not just doing their isolated task, but are a link that needs to know what's upstream and downstream of them.

This is why the order is people, process, technology — not the reverse. Element's role is often enterprise translator (and, honestly, part therapist): telling manufacturing what engineering needs and why, and vice versa, because the silos have been separate so long that no one owns what the enterprise needs to become more effective.

What good adoption feels like on the shop floor

For a plant manager, good adoption looks like manufacturing engineers actually talking to engineering and participating in design reviews — being a collaborator, not just a receiver of data. The shop floor knows what's coming, so there are no surprises. Non-conformances stop being a fight. Instead of "us versus them," a catch becomes "good catch — we both missed that one, we'll fix it right away." When the reflex shifts from blame to shared ownership, the system is being adopted.

Regulators are now forcing the issue

For heavily regulated companies — defense, aerospace, medical device — the biggest blocker is often an internal culture that acts as its own gatekeeper, stopping change out of risk aversion. That's no longer sustainable, because regulators have started requiring the change:

• The DoD issued DoDI 5000.97, "Digital Engineering," because industry wasn't adopting the digital engineering thread on its own.

• The FDA continues to publish guidance pushing medical-device manufacturers to work the way their systems are designed to work.

A telling anti-pattern: teams that keep data out of the system because they don't want an auditor to find it. That's backwards. When the data is in the system and the process is followed, an audit is far more defensible — you can walk the auditor through what happened and why. "We don't know why this failed" is the answer that destroys trust; if you don't know what happened inside your own company, the auditor concludes there are bigger problems. Auditors don't care what's in the messy closet — a mess alone tells them there are problems to fix.

Who should — and shouldn't — implement PLM

If you manufacture or engineer with anything other than paper — and everyone does now — you should be investing in this. The real variable is barrier to change, not company size:

• Larger companies usually have the money but must overcome "this is how we've always done it."

• Smaller, growing companies face a higher relative cost barrier, but often adopt better because they have no legacy habits to unlearn — and increasingly they can't afford not to, whether to track design-through-production or to satisfy investors.

There's even a competitive dimension emerging in aerospace and defense: smaller, more nimble firms adapt faster and are starting to win work, while larger primes risk being outpaced. Whatever the size, the rule holds — change the system, the process, or the people. Change nothing and expect nothing to change.

The one thing every executive needs

If there's a single sentence to leave leaders with, it's this: be a champion for change on a daily basis.

The most common failure at the top is treating support for change as a one-time event — showing up energized at the kickoff, then walking away. But the hardest decisions don't happen at kickoff; they happen months in, when the team hits the real trade-offs. Change is cyclical, not a signature: leadership sets the mindset, managers carry it to their people, behavior shifts, something gets questioned and goes back up the chain, and the mindset is reinforced or adjusted. Remove the leader from that loop and the organization quietly reverts to old habits.

Being present isn't micromanaging — it's giving your managers the tools and air cover to make change stick. And because no single decision-maker can carry it alone, the executive's real job is to make sure the leaders beneath them are genuinely on board.

Talk to a Windchill expert

If your PLM system is installed but underused — or a go-live isn't delivering the ROI you expected — the problem usually isn't the software. It's the process and the people around it. That's exactly the work Element does: people and process first, technology second, across 127 PLM implementations. Talk to a Windchill expert →

FAQ

Why do PLM implementations fail to get adopted after go-live?
Most aren't technically broken — the software works, but the organization kept its old processes and never invested in the people-and-process change adoption requires. Companies that have run PDM/PLM for decades often use a modern platform as engineering-only storage, a fraction of its value. Adoption comes from redesigning the process and getting engineering and manufacturing working from one shared design package.

Why do employees keep using Excel instead of the PLM system?
Usually because they were never shown how to report or manipulate BOMs inside the system, or they're wary of making a controlled change, so they export to a "scratch pad." That file becomes an unversioned, invisible source of truth that drifts out of sync, creating quality defects no one can trace. The fix is training and process discipline, not more software.

How much can PLM reduce cost of poor quality?
In one engagement, integrating engineering and manufacturing around a single design package cut cost of poor quality by 85% on a factory line — reducing engineering changes from roughly 450 per year to about 40 — by eliminating the churn of shop-floor errors bouncing back to engineering and publishing work instructions to MES and ERP together.

What's the difference between a PLM rescue and a rollout?
A rollout is a fresh implementation; a rescue fixes one that isn't delivering. The tell is usually that the software is fine — it's the business process and the people that need rescuing. Silos, no change-management discipline, and data living outside the system are the real culprits.