Ask ten enterprise manufacturers why a PLM program went sideways and you will get ten different stories: the integration that ran long, the team that never really adopted it, the data that came over broken, the budget that quietly doubled. The specifics always differ. What they tend to share is harder to see. By the time any of those problems surfaced, the conditions that allowed them were already in place, set months earlier, before the first configuration screen was ever opened.
That is the uncomfortable thing about PLM risk. Most of it is shaped before the program officially starts. It is a big part of why PLM performance research has long put the share of investments that fall short of expectations at roughly 70%, and why broader work on large transformation efforts finds only about 30% hit their goals. The platform rarely deserves the blame. More often, the program inherited a problem that was sitting there, unexamined, on day one.
None of which means there is a formula that guarantees a good outcome. There isn’t. PLM programs are genuinely complicated, and the right approach usually depends on your industry, your data, your people, and how much change the organization can realistically take on at once.
But there is one move that tends to pay off regardless of the specifics: taking the time, before you commit, to ask honestly whether you are ready. Not in a box-ticking sense. In the sense of sitting with the questions you would rather skip because the program already has momentum.
A few things worth sitting with
- Most of what determines a PLM program’s outcome is in place before kickoff, when a course-correction is still cheap.
- There is no readiness formula. But the act of pausing to ask whether you are ready tends to surface the risks that later get expensive.
- The questions easiest to skip (is the sponsor really behind this, can our people absorb it, is our data any good) are usually the ones that matter most.
Why so much of it is decided up front
The thing about a readiness gap is that it gets more expensive to deal with the longer it goes unnoticed, and PLM programs are very good at not noticing. A fuzzy definition of success is a half-day conversation in the planning stage. The same fuzziness, surfacing in month nine when nobody can agree whether the program is on track, is a painful re-baseline that costs weeks and a fair amount of political capital.
A data problem you catch before migration is a line item. The same problem after go-live, when people log in and do not trust what they see, is the start of an adoption problem. The gap itself does not change much. What changes is the cost of dealing with it.
This is not unique to PLM. McKinsey’s well-known study of more than 5,400 IT projects found large programs running, on average, 45% over budget and delivering 56% less value than expected, and most of that slippage traces back to decisions made early rather than mistakes made late.
PLM has its own version. The work that quietly determines the outcome (agreeing on why you are doing this, understanding what you are starting from, preparing your people and your data) tends to happen, or not happen, before the implementation everyone is watching even begins.
So the most useful thing you can do is also one of the least glamorous: slow down long enough, before you commit, to take an honest look at whether the conditions for success are actually in place. What follows is less a checklist to complete than a handful of areas worth being honest about.
Do you actually agree on why you’re doing this?
It sounds obvious, and almost everyone assumes the answer is yes. Then you get the stakeholders in a room and ask them to name the two or three outcomes that would make this investment worth it, and the answers do not line up. Engineering wants faster change cycles. IT wants to retire a system nobody can maintain. Quality wants audit findings to stop. Finance wants a number. None of those are wrong, but a program pointed at all of them at once has no clean way to make a trade-off when, inevitably, it has to.
This is also where the sponsor question lives, and it is worth being honest about. An executive who will defend the program when it gets hard is, across years of PMI’s research, one of the most reliable predictors of whether a project succeeds. A sponsor who showed up to the kickoff and has not been seen since is a different situation, and it is better to know which one you have before you are leaning on them.
Ask yourself: Do we have an executive sponsor who is prepared to advocate for and support the PLM initiative across the organization?
You do not need a signed charter to start thinking about this. You do need to be able to say, plainly, what this program is for and who will carry it when it stops being exciting. If those answers are vague today, they are unlikely to get clearer once the work is underway.
How honest is your picture of where you stand?
A lot of readiness conversations run on assumptions about the current state that nobody has actually checked. Everyone knows the legacy system is painful. Far fewer can say, with numbers, how painful, or where the pain really concentrates. Tech-Clarity’s research suggests something like a third of engineering time goes to non-value-added work, but a figure like that only helps if you know your own version of it. Otherwise the business case rests on someone else’s averages, and the program has no baseline to prove it worked.
Ask yourself: Have we conducted or planned a formal PLM maturity assessment to identify capability gaps?
Then there is the data, which deserves its own moment of honesty because it is the thing most likely to be quietly bad. Years of legacy product data (broken CAD links, duplicate parts, inconsistent metadata, orphaned change records) tend to look fine until you try to move them, at which point “we’ll clean it up during migration” becomes the reason the new platform launches and nobody trusts it. The useful question is not whether your data is perfect. It is whether you actually know its condition, which sets matter most, and who owns them. Plenty of organizations do not, and finding that out before you commit beats finding it out after.
Ask yourself: Have we mapped where product data lives across the lifecycle, and identified key gaps in traceability?
Can your people actually absorb this?
This is the one that gets nodded past most often, and it may be the one that matters most. PLM changes how engineers, quality, and manufacturing do their daily work, and an organization’s capacity to take on that kind of change is real, finite, and easy to overestimate. You can deliver a technically flawless system into a team with no bandwidth or appetite for it and end up with something people work around instead of work in.
It is not a coincidence that when large transformation efforts fall short, weak change management is cited more often than almost any other reason. The signals here are not subtle if you look for them. Are there people on the floor who actually want this and will pull others along? Have the affected teams heard about it from someone other than the rumor mill? Is there any real plan for the human side, or is it assumed to take care of itself? There is no universal answer for how much change capacity is enough. It depends heavily on what else the organization is carrying at the same time. But it is worth a clear-eyed look rather than optimism.
Ask yourself: Have impacted teams been engaged or briefed on the upcoming changes, and are they aware of the cultural impact of PLM?
Have you thought about how you’d actually run it?
Not the detailed plan. That comes later and will change anyway. The more basic question is whether anyone has thought about the shape of the thing: roughly how it phases, who is genuinely available to work on it (as opposed to who is on the org chart), and who makes the call when scope and timeline start to argue with each other. Programs without even a rough phasing model tend to absorb every new request that appears, because nothing is in place to say “later.” Programs that have not honestly counted their internal capacity discover, halfway in, that the people they need were already full.
Ask yourself: Is there a governance model, working group, or steering committee prepared to oversee the transformation?
You do not have to have this solved before you begin. You do want to have thought about it enough to know whether you have a way to govern the program, or just a hope that it will govern itself.
What “ready” actually looks like
Here is the part worth saying plainly: ready does not mean every answer is yes. It rarely is, and a team that waited for perfect readiness would never start anything. The point of the exercise is not to pass it. It is to know, going in, where you are strong, where you are exposed, and which of those exposures you are choosing to live with on purpose.
A team that can say “our data is rough and we have a plan for it, our sponsor is solid, our change capacity is the real question mark” is in far better shape than a team that believes everything is fine because nobody has looked.
That is also why this is often worth doing with someone from outside the program. The people who want the initiative to go ahead are, understandably, not the best placed to surface the reasons it maybe should not, at least not yet. An outside read tends to ask the questions the inside team has already talked itself out of.
Where ArcherGrey fits
We spend a lot of our time on exactly this conversation, often before a client has settled on a platform or a partner at all. ArcherGrey’s Readiness Program is a short, structured version of the thinking above: a focused week of working through these questions with your stakeholders and coming out with an honest read on where you stand and what is worth addressing before you invest. It is built for the moment between “we think we need to do something about PLM” and “we’re committing budget to it.” If that is roughly where you are, it might be time to start a conversation with us.
A few questions people ask
We’ve already started. Is it too late?
No, though it changes the conversation. Mid-program, these questions become a diagnostic rather than a pre-flight check, and an outside read is usually more useful than a course-correction run from inside the existing program, which tends to reproduce whatever caused the problem in the first place.
How long does this take?
Less time than people expect. The idea is to fit it into the window where acting on what you find is still less expensive than the mistake of recovery, which usually means days or a couple of weeks, not months. The goal is a clear-eyed read, not an exhaustive study.
The bottom line
Most of the risk in a PLM initiative is shaped before the real work begins, in the conditions you bring to it more than the plan you write. No formula removes that risk, and anyone selling one is overpromising. But the simple act of pausing to ask, honestly, whether you are ready, and being willing to hear an uncomfortable answer, tends to be the cheapest and most useful thing a leader can do before committing. The questions are not hard to ask. The discipline is in asking them early, and in being honest about the answers.