Why PLM Fails 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. Adoption comes from redesigning the process and getting engineering and manufacturing working from one shared design package. The tool alone won’t get you there.

Why PLM adoption stalls after go-live

The picture people imagine, a company that 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 capable, modern PLM platform, often on a sizeable annual 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 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 work out what a revision change back through engineering actually costs.
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, its changes are probably moving by email and phone call.
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 drag on for months simply because the data wasn’t captured properly during R&D. Capturing it as you go shortens that a lot, at the cost of doing more work up front.

One manufacturer: about 400 nonconformances a year down to about 40

Eric Horn tells this one. A manufacturer set out with a modest goal: use the system to make employees more productive. Instead of treating PLM as engineering-only storage, they built 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 together), and manufacturing reviewed that data before it was released.

For one manufacturer, that change cut the nonconformances sent back to engineering from about 400 a year to about 40. Because manufacturing reviewed the data before it hit the shop floor, they reduced the cost of poor quality by 80%.

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. Eric Horn walks through the same pattern in 400 change orders a year, down to 40.

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. When someone insists “our process is broken, the system is bad,” the cause is usually 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. Most of the time the system can already do it; they were just never shown how.

How to treat mistakes and CAPAs during adoption

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 treated as a chance to improve. When teams treat opening a CAPA as getting sent to the principal’s office, they hide problems instead of fixing them, which is 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, with your eyes open.

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, and helping everyone see that their task is one link in a chain: they need to know what’s upstream and downstream of them.

This is why the order is people, process, technology. Element’s role is often enterprise translator (and, some days, 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. That’s how we start a Windchill rescue.

What good adoption feels like on the shop floor

For a plant manager, good adoption looks like manufacturing engineers actually talking to engineering and taking part in design reviews, shaping the data before it reaches them. 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 implement PLM

If you manufacture or engineer with anything other than paper (and everyone does now), you should be investing in this. The variable that decides it 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. 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.

What executives must do for PLM adoption to stick

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 trade-offs nobody saw coming. Change runs in a cycle. 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 means giving your managers the tools and air cover to make change stick, without micromanaging them. And because no single decision-maker can carry it alone, the executive’s job is to make sure the leaders beneath them are on board.

The sponsor is one piece of the people side. The rest (stakeholder analysis, champions and super-users, CRP and UAT, role-based training, the readiness check before go-live, hypercare and adoption measurement) is laid out step by step in our guide to organizational change management for PLM rollouts.

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 fix usually sits in the process and the people around the software. That’s the work Element does: people and process first, technology second, across 100+ PLM implementations. Talk to a consultant →

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?
Eric Horn has seen it happen when manufacturing reviews the engineering data before release. For one manufacturer, that change cut the nonconformances sent back to engineering from about 400 a year to about 40. Because manufacturing reviewed the data before it hit the shop floor, they reduced the cost of poor quality by 80%.

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, and the business process and the people are what need rescuing. Silos, no change-management discipline, and data living outside the system are the usual causes.