There's a phenomenon in PLM and enterprise software that nobody talks about publicly but everyone who works in this industry has seen: the pilot that never ends.

It starts with good intentions. A manufacturer wants to modernize its product lifecycle management. They do a vendor evaluation, select a platform, and decide to start with a pilot — a limited deployment in one product line or one business unit, designed to prove the concept before full rollout.

Six months later, the pilot is still running. A year later, it's still a pilot. Two years in, it's "ongoing." The core team turns over. The executive sponsor gets promoted. The initiative lives in a kind of organizational limbo — not failed enough to kill, not successful enough to scale.

Welcome to Pilot Purgatory.

Why Pilots Get Stuck

Pilot Purgatory is almost never about the technology. The software usually works. The real causes are organizational — and they're predictable enough that you can spot them before a pilot even launches.

1. The pilot was designed to prove the technology, not to prove the business case.

When the success criteria for a pilot is "does the software work as advertised," the answer is almost always yes. Enterprise PLM platforms are mature. They work. The harder question — does this implementation approach work for our organization, our data, and our processes — is left unanswered.

Pilots that succeed have clear, quantifiable business outcomes attached to them from day one. Not "the system is functional." Not "users can log in." But: what does this pilot need to demonstrate about cycle time, error rate, or cost reduction to justify full rollout? If you can't answer that question, you don't have a success criterion — you have a hope.

2. The pilot scope was too narrow to show real value.

Single-product-line pilots are a double-edged sword. On one hand, limited scope reduces risk. On the other hand, a PLM system that manages one product line while the rest of the organization operates in legacy systems can't demonstrate integration value, cross-functional workflow improvements, or enterprise-scale data governance.

The result: the pilot works in isolation, but nobody can see how it would work at scale. Skeptics in other departments have no reason to become advocates. And the expansion conversation always starts from zero.

3. There was no plan for what comes after the pilot.

This is the most common killer. The implementation team builds a great pilot. Users are trained. The system is configured. Data is loaded. And then... the project plan ends. Because the project plan was for the pilot.

Scaling a PLM implementation isn't the same project as piloting one. It requires different resources, different change management, different data migration scope, different integration complexity. Organizations that don't plan for Phase 2 before they finish Phase 1 find themselves starting from scratch after the pilot — re-justifying the business case, re-engaging executives, re-budgeting, re-hiring.

4. The organizational prerequisites weren't met.

PLM implementations require decisions to be made before go-live: Who owns the BOM? What's the change management process? How does this system interact with ERP? Who has authority to release a product record?

When those decisions aren't made during the pilot, the pilot works around them. Custom configurations get built to handle edge cases. Workarounds proliferate. And when it comes time to scale, you discover that the pilot architecture was built on organizational assumptions that don't hold at enterprise scale.

The Hidden Cost of Purgatory

What does Pilot Purgatory actually cost?

The direct costs are easy to see: licensing fees for a system that isn't fully utilized, implementation consulting fees that keep accumulating, internal headcount dedicated to a project that isn't delivering.

The indirect costs are harder to see but larger. Every month a manufacturer operates with fragmented product data is another month of quality escapes, engineering rework, and supply chain expediting that a proper PLM implementation would have prevented. The opportunity cost of not scaling is real — it just doesn't show up on the project budget.

There's also an organizational toll. The team members who built the pilot burn out waiting for a scaling decision that never comes. The executive sponsor loses interest. The vendor relationship deteriorates. And when the organization eventually tries again — with a new system, a new team, a new approach — they're starting from a worse position than before, because they've now spent a year or two building learned helplessness around PLM initiatives.

Breaking Out: What the Successful Rollouts Have in Common

I've seen organizations escape Pilot Purgatory. Here's what they do differently.

They define the exit criteria before the pilot starts. Not "when we're ready," but: what specific outcomes, at what level of confidence, will trigger the rollout decision? This needs to be agreed by leadership before the pilot launches — not negotiated after the fact.

They treat the pilot as Phase 1 of an enterprise program, not a standalone proof of concept. The governance model, the data standards, the integration architecture — these are designed for enterprise scale from the beginning, even if they're only implemented for one product line in Phase 1.

They start the Phase 2 planning while Phase 1 is still running. Resource planning, budget approval, and stakeholder alignment for the full rollout should be in motion before the pilot concludes. Waiting until the pilot is "done" to start Phase 2 planning is how you end up with a six-month gap between phases.

They expand the stakeholder base during the pilot. If only the pilot team knows the system is working, the rollout decision will be made by people who've never seen it. Getting skeptics from other business units into the pilot — as observers, as early users, as data providers — builds the coalition you need for the expansion conversation.

They make the organizational decisions the pilot revealed. Every pilot surfaces process questions that weren't answered in the planning phase. Successful organizations treat those as requirements to be resolved before scale. Organizations stuck in purgatory treat them as problems to be escalated later.

A Note on Vendor Dynamics

One more thing that contributes to Pilot Purgatory: misaligned incentives with implementation partners.

Some vendors and system integrators are incentivized to extend pilots. More consulting hours, more customization requests, more discovery workshops. The pilot that goes slowly is, from a billing perspective, a successful engagement.

This isn't universally true — the best implementation partners push hard to scale because that's where reference-able case studies and long-term platform revenue come from. But it's worth being clear-eyed about: if your implementation partner's revenue model benefits from a longer pilot, their advice about "pilot readiness" needs to be evaluated accordingly.

The organizations that break out fastest have a clear internal owner — someone with authority and accountability for the implementation outcome, not just the project budget — who can make the call to scale independent of vendor advice.

The Path Forward

If you're in Pilot Purgatory right now, the first step is diagnosis. Ask the hard questions:

• What were the success criteria for this pilot? Were they met?

• What decision needs to be made to move to Phase 2, and who has the authority to make it?

• What organizational prerequisites remain unresolved?

• What would it take to put a Phase 2 plan in front of leadership in the next 90 days?

The answers will either give you a path forward or tell you that the pilot needs to be formally sunset. Both of those are better than purgatory.

Element Consulting specializes in helping manufacturers get PLM investments to full operational value — not just through technical implementation, but through the organizational alignment that makes implementations stick. If your pilot has been running longer than it should, let's talk about what's really holding it back.