You Assigned Change Management to the People Building the System

Every failed PLM implementation I've walked into had a change management plan. Usually a good one. Stakeholder map, communication plan, training schedule, the whole thing.

What it didn't have was anyone whose actual job was to do it.

Here's the pattern, and once you see it you'll see it everywhere. A company decides to implement or upgrade Windchill. They staff the project with the people who understand the systems — the PLM administrator, a couple of senior engineers, someone from IT, maybe a business analyst. Smart people. The right people, for the technical work.

Then, somewhere in the project plan, there's a workstream called organizational change management. And it gets assigned to the same team.

"Usually they ask the people that are doing the project, that are doing the technical side of things, of the process change and/or the technology improvement, to also do the people side of the change. Well, guess what?"

Guess what. It doesn't get done.

Not because those people are lazy or don't care. Because when the migration script fails at 11pm before a go-live rehearsal, nobody is choosing to go write a communication plan instead. The technical work has hard deadlines and visible failure. The people work has neither. So it slips, quietly, every single week, until go-live arrives and the organization has been told about the change roughly twice.

Then adoption comes in low, and everybody concludes the users resisted.

The users didn't resist. Nobody prepared them.

Resistance is real, and it shows up in places you can't predict.

"When it comes to people that push back against change, it comes from all over the place, and so sometimes you never know where those people are gonna come from."

But resistance is a normal, expected, manageable stage of any change. It's only fatal when nobody is managing it.

"The people side of things is always the biggest roadblock."

What that roadblock looks like in practice is someone in engineering saying: why are we changing something that isn't broken?

That's not an unreasonable question. It's usually asked by someone who has built a workflow that functions — often heroically — around the limitations of the current system. From where they sit, it works. The fact that it works only because they are personally holding it together is invisible to them, because they've been doing it for nine years.

"It takes the right person to be educated of saying, 'Hey, it actually is broken.'"

That conversation is a skill. It takes someone who can show a person their own workaround from the outside without making them feel stupid for having built it. Your solution architect, mid-migration, is not going to have that conversation. They're going to send a Teams message with a link to the training portal.

What the work actually is

The people side isn't a communication plan. It's five distinct jobs, and each one needs someone accountable for it:

1. Find the champions — and then actually equip them.

"The business definitely needs a champion or champions that are wanting to change and be the advocates for change."

Most companies do the first half. They identify enthusiastic people and put their names on a slide. Then those champions get no training, no talking points, no early access, and no authority — and within a month they're just normal users who were named on a slide.

"Let us help you educate those champions."

A champion who can't answer their colleague's question is worse than no champion, because they were supposed to be the person who knew.

2. Work all three stakeholder tiers, differently.

"There's subject matter stakeholders. There's management stakeholders, and there's also executive level stakeholders. They all play a different role. They all need to be involved at various degrees of level, but their support and buy-in is key."

Executives need to know the business case is holding. Managers need to know what happens to their team's throughput during the transition — that's the question they're actually worried about, and it's usually the one nobody answers. Subject matter experts need to be consulted early enough that their input can still change something, because being asked for your opinion after the decision is made is worse than not being asked.

3. Communicate more than once.

"Communication isn't a one-time event."

The kickoff email is not the communication plan. People need to hear what's happening, why, and what it means for them specifically — repeatedly, through the whole project, from someone they trust.

4. Reduce the barriers rather than argue with the resistance.

"You need to make sure that you're reducing the barriers to their inherent change. They're probably gonna resist at some point and be like, 'Ugh, I just wanna go back to the way things were.' Well, guess what? We can't go back to the way things were. So let's actually work on how can we make it better for you so that you can get through the adoption curve with the least amount of distraction to the company."

Note what that isn't. It isn't convincing anyone the new system is wonderful. It's accepting that the adoption curve is real, that people will be less productive for a period, and then working the specific problem of making that period as short and as survivable as possible.

5. Tie it to a metric leadership actually watches.

"If you're making changes and you're not moving the needle for the company in the right metric, your project may be cancelled. So make sure you're focusing on those metrics that the stakeholders are gonna be actually responding to."

Adoption percentage is a project metric. Cycle time, cost of poor quality, on-time delivery, scrap rate — those are business metrics. If your change work only ever reports the first kind, it reads as overhead, and overhead gets cut when the budget tightens.

So who should own it?

Someone who is not on the technical critical path. That's the whole answer.

It can be an internal person, if you genuinely have one — someone with the standing to talk to an executive and the credibility to talk to the shop floor, with real time carved out rather than a line in their objectives.

"All too often people are like, 'Hey, you know what? We can do that ourselves.' And quite honestly, you find out that they don't have the people that can actually do it."

If you don't have that person, the honest move is to say so early, while it's still a staffing decision, rather than at go-live when it's a rescue.

"If you want better outcomes, that actually proves a better bang for your buck to invest into the people rather than just the technology."

That's not a soft argument. The software costs the same whether or not people use it. Everything you get back from it is downstream of adoption.

Element has run 127 PLM implementations, and the pattern above is the single most common structural mistake we see. If you're scoping a Windchill implementation or upgrade and you're not sure who owns the people side, that's worth a conversation before the project plan is locked.