Organizational Change Management for PLM Rollouts: A How-To

Organizational change management (OCM) for PLM is the planned work of getting people to work the new way once the system is live. On a Windchill rollout that means a stakeholder analysis, a program OCM plan, super-users and champions who are actually equipped, a communication calendar tied to the project’s milestones, role-based training on your own data, a readiness check before go-live, hypercare, and adoption measured after go-live. It runs alongside the technical build, and it needs its own owner.

I’ve watched plenty of PLM projects go live on time with the configuration right and the data migrated clean, and then stall, because engineering kept working the old way. This guide is the version of the people side we’d hand a client at kickoff: who does what, in what order, and the specific Windchill habits your users will push back on. It follows the delivery method Element uses on its own implementations.


What OCM covers	Stakeholders, the OCM plan, champions and super-users, communication, training, readiness, hypercare, adoption measurement
When it starts	Discovery, alongside the first process workshops. Not at training, and not at go-live
Who owns it	A named OCM lead with no technical deliverables, plus a client sponsor who stays visible
Where it plugs into the project	Discovery (stakeholder analysis, OCM plan), CRP and UAT (key users), training, the go/no-go decision, hypercare
What users resist on Windchill	Check-in/check-out, the formal change process, BOM ownership, part numbering
The usual mistake	Handing the change work to the team that is configuring and migrating the system
How you know it worked	Behavior in the system and business metrics against a pre-go-live baseline, tracked apart from training attendance

Why PLM rollouts fail on adoption

A PLM system changes who decides what, who sees what, and when. An engineer who used to save a model to a shared drive now checks it in, and a manufacturing engineer who kept the “real” BOM in a spreadsheet now works from one in the system. A change that used to be an email and a hallway conversation becomes a change request with an approval route. Every one of those is a habit somebody built over years, often a clever workaround for the old tool’s limits.

The technical team can get all of that configured. What it can’t do, in the same weeks, is prepare hundreds of people to give up their workarounds. So the pattern we see when we’re called in after a stalled rollout is pretty consistent:

Nobody owned the people work. The OCM workstream sat with the PLM administrator or the solution architect, and it lost to technical deadlines every week. (We wrote about that pattern here.)
The sponsor went quiet after kickoff. Within a few months the team reads the silence as “this isn’t a priority anymore.”
Users met the system for the first time in training. They had no say in the design, so the first time they saw it, it looked like somebody else’s idea.
Training covered screens, not the job. People learned which button creates a change request but not when they’re supposed to raise one.
Success was declared from a training roster. Attendance was reported as adoption, so nobody noticed the exports to Excel until quality problems showed up downstream. (Why PLM implementations fail after go-live.)

None of these are software problems. They’re all preventable, and the rest of this guide is the order we prevent them in.

Who owns change management on a PLM project

Name these roles before the project plan is baselined. Our delivery method uses the same names on every engagement:

Role	Side	What they own
OCM lead	Implementation partner (or a client person with real time carved out)	Stakeholder analysis, the program OCM plan, the readiness approach, training and adoption execution
Sponsor	Client	The business case, the success criteria and final sign-off. Also the voice people need to hear say why, more than once
Client project manager	Client	Runs the client’s side of the plan and brings the right people to each session
Key users / process owners	Client	Speak for one process each, test it in CRP and UAT, and accept it. Most of your super-users come from here
Solution architect	Implementation partner	The future-state process and the design decisions the OCM lead has to explain
Technical architect	Implementation partner	Environments, migration and cutover. Also owns the hypercare plan with the OCM lead

The OCM lead is the one role you can’t double up. The point of the role is that it has nothing else competing for its calendar. If you have an internal person with the standing to talk to an executive and the credibility to talk to the shop floor, they can do it, with the job written into their objectives. If you don’t, say so while it’s still a staffing decision.

Step 1: Discover what is actually changing

Change work starts in discovery, in the same workshops where the solution architect maps the current and future process. We go in with five questions:

How is the work done today, and what goes wrong?
What will be different once the new process and system are in place?
Who will be affected most?
What else has to change for this to work (other systems, other processes, approvals, job descriptions)?
What have people already heard, and how are they reacting?

Write the answers down in the participants’ own words. “We email the PDF to purchasing and hope” tells you more than “manual release distribution,” and it’s the sentence you’ll use later to explain why the change is worth it. Keep what people do today apart from what you expect the new system to fix, and list the questions nobody in the room could answer, with who to ask.

Three things come out of this step:

A case for change. Why now, what problem it fixes, which benefits the business expects. One page, in plain words, that the sponsor will actually say out loud.
A change radius. Where the change is broad (lots of people, small changes) and where it’s intense (fewer people, their daily work turned over). Design engineers moving onto disciplined CAD check-in is intense. Occasional approvers getting a task in a new inbox is broad but light.
A first stakeholder list, which becomes Step 2.

Step 2: Map stakeholders and user groups

A PLM rollout reaches further than the engineering department. Map every group that creates, changes, approves or consumes product data:

Group	Typical change on a Windchill rollout	What they usually worry about
Design engineering	CAD check-in/check-out, parts and BOMs in the system, raising and working change tasks	“This slows me down.”
Manufacturing engineering	Working from the released BOM, owning the manufacturing BOM, process plans	“We lose the spreadsheet that actually builds the product.”
Quality	Problem reports and change records in the system, audit trails	“Can I still find the evidence an auditor asks for?”
Supply chain and purchasing	Released data instead of emailed drawings, revision visibility	“Which revision do I send the supplier?”
Operations and the shop floor	Work instructions and drawings from the system	“Will the floor have what it needs on Monday?”
IT	Accounts, access, integrations, support after go-live	“Who answers the phone after hypercare?”
Approvers and occasional users	Tasks and sign-offs in a new place	“I’ll get emails I don’t understand.”

For each group, record three things: how much their daily work changes, how much influence they have over whether others adopt (the senior designer everyone asks is worth more attention than the org chart suggests), and where they stand today (supportive, unsure, opposed, or unaware). Then look across the three tiers of stakeholders: executives, people managers and the people doing the work.

The middle tier is the one projects skip most often. Managers mostly want to know what happens to their team’s throughput during the transition. Answer that question early and specifically or it turns into quiet resistance, because a manager who expects a bad month will protect the old way of working.

A gap we check for at this step: every area of the business in scope has at least one named stakeholder, and the people who use the data but never come to workshops (planners, buyers, field service) are on the list.

Step 3: Write the program OCM plan

The program OCM plan is a discovery deliverable, finished alongside the solution approach and the program roadmap. It holds:

the case for change and the change radius from Step 1;
the stakeholder analysis from Step 2, with an engagement approach per group;
the champion and super-user network: who, how they’re picked, what they get;
the communication calendar, mapped to project milestones (Step 5);
the training approach by role (Step 7);
the readiness approach and the criteria that feed go/no-go (Step 8);
the hypercare support model, written with the technical architect (Step 9);
how adoption will be measured, and the baseline to capture before go-live (Step 10);
escalation paths: who decides when a group isn’t ready.

On a multi-release program there’s one OCM plan for the program and a lighter plan per release. Keep the plan on the same status cadence as the rest of the project, so slipping people work shows up in the weekly report next to slipping configuration work.

Step 4: Pick super-users and champions, then equip them

People use the two words loosely, so here’s how we split them:

A champion is someone people listen to, who wants the change and will say so in rooms the project team isn’t in. Often a respected senior engineer or a manufacturing lead.
A super-user knows the new process in depth for one area and is the first person colleagues ask after go-live. Most come from the key users who sat in CRP and UAT.

Naming them is the easy half. Equipping them is the half that gets skipped, and a champion who can’t answer a colleague’s question does more damage than no champion at all. Give them:

a seat in the CRP sessions for their area, so they’ve used the system before anyone else;
early access to a sandbox with realistic data;
talking points and an FAQ that answer “why are we doing this?” in their department’s terms;
a standing channel to the project team, so questions they can’t answer get a same-week reply;
protected time, agreed with their manager. (Super-user work done on top of a full job is the first thing to go.)

Pick at least one per site and per major user group. A site without a super-user will run on phone calls to the project team for as long as you let it.

Step 5: Set the communication cadence

Communication on a PLM project is a calendar of messages that runs from kickoff through hypercare. People need to hear what’s changing, why, and what it means for them specifically, from someone they trust, more than once.

We plan messages for three audiences (leaders, people managers, contributors) and move each one through four stages: awareness (this is happening and why), understanding (what it means for my work), commitment (I’m willing to try it), and adoption (I work this way now). Tie each message to a project event so it lands when people care:

Project point	What people hear, and from whom
Kickoff	The sponsor: why the business is doing this, what success looks like
Discovery	Managers: workshops are coming, who’s in them, how input changes the design
Design sign-off	Key users: what was decided for their process, and why
CRP rounds	Champions: what users found and what got fixed (this is where trust is earned)
Training and UAT	Managers: dates, who attends, what’s expected of their team during go-live
Go/no-go and go-live	The sponsor and project team: the date is set, where to get help on day one
Hypercare	Super-users and the project team: tips, known issues, what got fixed this week
After hypercare	The sponsor: what changed in the business metrics, and what’s next

Build a feedback loop into it. Every message should tell people where to ask questions, and the questions that come back are your best readiness signal.

Step 6: Use CRP and UAT as adoption tools

The delivery method puts the build in front of users twice before go-live, and both are as much OCM as they are testing.

Conference room pilots (CRP, also called conference room validation or CVR) show the configured system to the people who’ll use it, running their real scenarios: a designer checking in an assembly, a manufacturing engineer building an MBOM from a released EBOM, a change administrator routing a change request. Most projects run more than one round. Every finding gets logged and sorted: fix now, fix later, or accept. Users then see their finding either fixed or explained, and either one builds more trust than a feature list.

The trap is running a demo and calling it a pilot. If users watch while a consultant clicks, you’ve learned nothing about whether they can do the work, and they’ve learned nothing about the system.

User acceptance testing (UAT) is where the client’s users test the solution against the acceptance criteria and formally sign off what they accept. Run it with business users, on a realistic copy of the data, after system integration testing is done, and record the sign-off (a verbal “looks good” doesn’t count). Key users who’ve been through CRP and UAT become the people who defend the design to their colleagues later, which is worth more than any announcement.

Step 7: Train by role, on your own data

Training material is built while CRP is running, so it reflects what users actually found. A few rules we hold to:

Train the job, not the screens. “When you find a dimension error on a released drawing, raise a problem report” teaches the process. “Click New, then Problem Report” teaches a menu.
Use the client’s own parts, documents and BOMs in the exercises. Generic sample data makes people think the real thing will be different.
Split by role. Designers, manufacturing engineers, change administrators, approvers and occasional viewers need different courses of very different lengths.
Train close to go-live, with follow-up office hours and make-up sessions for whoever missed it.
Check access before day one. Users need the right security roles assigned, per access policy, so they can do on day one what they practiced in class. A training roster isn’t an access list.
Track attendance and completion, and keep it apart from readiness. Sitting through a session doesn’t prove someone can do the work.

Step 8: Check readiness before go/no-go

The readiness approach says how you’ll check that people and teams, not just the system, are ready to go live. We keep two questions separate:

Product readiness: is the system configured, tested, migrated and accessible?
Operational readiness: can the people in each area actually perform the changed process on Monday?

Clean data and working logins aren’t proof of the second one. Before the go/no-go meeting we run readiness sessions with each area and confirm:

Every user group in the stakeholder map has been trained, or has a dated make-up session.
Security roles are assigned and tested for each role, not just for the project team.
Each site and major group has a named super-user who knows they’re on call.
Managers know what’s expected of their team in the first weeks and have planned for slower throughput.
Users know where to report a problem on day one, and that channel is staffed.
Open readiness gaps are written down with owners, and the sponsor has seen them.

The readiness result goes into the go/no-go decision alongside the technical checklist, and the decision is recorded with who made it. An area that isn’t ready is a reason to delay that area, or to add support for it, before it becomes a hypercare fire.

Step 9: Run hypercare

Hypercare is the period of extra support right after go-live while users learn the system. In our method:

users get one place to report problems, and every report gets an answer within an agreed time;
defects get fixed first; new requests wait (hypercare that turns into free new development never ends);
the project team reviews open issues every day and reports the incident trend to the sponsor;
super-users collect tips and recurring questions, which go back out as short reinforcement messages;
hypercare ends when the system is stable and incidents are low and steady, not on a date, and not before the support team has been trained to take over.

Keep the project team’s knowledge around through the handover. Losing the people who know why the system was configured a certain way, the week after go-live, is how small questions turn into workarounds.

Step 10: Measure adoption after go-live

Track three things separately, because each one can look fine while the others don’t: training (who attended and completed), readiness (who could do the work at go-live), and adoption (who actually works the new way now).

For adoption, look at behavior in the system and at the business:

Signals in Windchill: objects left checked out for long stretches, designs that only reach the system at release, changes that show up with no change record, BOMs exported to spreadsheets and edited there, the same questions coming back to super-users.
Signals in the business: the metrics leadership already watches, such as engineering change cycle time, cost of poor quality, rework sent back to engineering, and on-time delivery. Capture a baseline before go-live, or you’ll have nothing to compare against. (You can’t prove ROI you never baselined.)

Report adoption in business terms. A dashboard that only shows logins reads as overhead, and overhead gets cut. When the numbers say one group hasn’t moved, go and watch them work for an hour. You’ll usually find a training gap or a step the design got wrong, and both are fixable.

The Windchill change points users resist

Every rollout has its own sore spots, but four come up on nearly every Windchill project we run. Each needs a decision in design, a reason people can repeat, and training on that exact moment.

Check-in and check-out discipline

What changes: Designers work in a Windchill workspace and check work in to share it. Saving or uploading to your own workspace isn’t the same as checking in; until you check in, colleagues see the last checked-in version. Checking an object out reserves it while you work on it.

Why people resist: It feels slower than saving to a shared drive. If check-in is slow, references break, or large assemblies take minutes, engineers start keeping working copies outside Windchill and checking in only at release.

What to do: Treat slow check-in and broken CAD references as adoption problems and fix them before go-live; an IT ticket queue won’t get to them in time. Agree the rules in writing (check in at the end of each working session; don’t hold objects checked out over long absences; who may undo someone else’s checkout). Make the stale-checkout report a hypercare routine. (Creo and Windchill CAD data management.)

The formal change process

What changes: A change that used to be an email becomes a chain of records: a problem report to capture the issue, a change request for the business decision, a change notice holding the implementation plan, and change tasks that revise the affected objects and release the results.

Why people resist: It looks like bureaucracy, especially for small fixes. And people who used to approve things by walking over to someone’s desk now get workflow tasks they don’t understand.

What to do: Size the process to the risk. Windchill’s change process can be configured to run light for low-risk changes and in full for changes that need cross-department review; decide which changes take which route during design, and write it down. Train each role on its own step (a requester doesn’t need the change board’s course). Teach the habits that save rework, such as doing the first analysis on the change request before creating the change notice. (What engineering change management is, and how to implement the change order process.)

BOM ownership

What changes: The BOM lives in the system, with an owner. Typically engineering owns the engineering BOM (what the product is) and manufacturing owns the manufacturing BOM (how it gets built), derived from the released engineering BOM.

Why people resist: Manufacturing often has a spreadsheet BOM that’s the one that actually builds the product, and giving it up feels risky. Engineering may resent being accountable for data manufacturing will use. Both sides suspect they’re inheriting the other’s work.

What to do: Decide ownership explicitly in design, by BOM type and by lifecycle state, and put it in the RACI. Run CRP scenarios that cross the handoff, so both sides see the same structure. In hypercare, every spreadsheet BOM that shows up gets a “why?”: usually someone was never shown how to report or edit in the system. (EBOM vs. MBOM and the engineering-to-manufacturing handoff.)

Part numbering

What changes: Many rollouts move from “intelligent” part numbers, where the digits encode a product line or a part type, to numbers Windchill assigns, with the meaning moved into attributes and classification. CAD file names and part numbers may follow different rules than before.

Why people resist: People read meaning from the old numbers every day, and some of them have memorized hundreds. A meaningless number feels like a loss of control, and downstream systems and suppliers may depend on the old format.

What to do: Make the numbering decision early, with manufacturing, purchasing and the ERP owner in the room, since it touches every integration. Give people a way to find parts that’s better than reading the number (classification and search), and show it in CRP before go-live. Decide how legacy numbers are carried and searched after migration. (Parts classification in Windchill, and what happens when departments name the same part differently.)

How to choose a partner for the people side

If you’re bringing in a firm, ask them these before you sign:

Who is the OCM lead, by name, and do they have any technical deliverables? If the answer is the solution architect, you’re back to the usual mistake.
When does change work start? Discovery is the right answer. Training is too late.
What do you hand over at each stage? Expect a stakeholder analysis, a program OCM plan, a communication calendar, training by role, a readiness assessment and a hypercare plan. A line item that says “OCM support” is a warning sign.
How do your OCM people work with the Windchill architects? The change lead has to understand check-in, the change process and BOM ownership well enough to explain the design decisions.
How will we measure adoption? Listen for a baseline before go-live and business metrics, not login counts.
What happens if one area isn’t ready at go/no-go? A good answer names who decides and what the options are.

How Element runs OCM on PLM rollouts

Element runs organizational change management as its own workstream, led by OCM practitioners who work alongside the Windchill architects on the same project. The method on this page is our delivery method: stakeholder analysis and the program OCM plan in discovery, key users in CRP and UAT, role-based training, a readiness approach that feeds go/no-go, and hypercare with the technical team. On most engagements your people run the change day to day; we bring the method, train your champions and stay accountable for the workstream. Where you don’t have someone to lead it, we staff that role.

Element Consulting is an independent PTC partner founded in 2003, with 100+ PLM implementations behind it and a senior-only team. The tradeoff: we’re small, and we’ll tell you on the first call if your program needs more change people than we can put on it. See our organizational change management service, or how it fits into a Windchill implementation.

FAQ

What is organizational change management (OCM) in a PLM rollout?
OCM for PLM is the planned work of getting engineering, manufacturing, quality, supply chain and IT to work the new way once the system is live. In practice it is a stakeholder analysis, a program OCM plan, equipped super-users and champions, a communication calendar tied to project milestones, role-based training on the client’s own data, a readiness check before go-live, hypercare, and adoption measured after go-live. It runs alongside the technical build, with its own owner.

Who should own change management on a PLM or Windchill project?
A named OCM lead who has no technical deliverables, working with a client executive sponsor who stays visible for the whole project and with key users who speak for each process. When change management is assigned to the people configuring and migrating the system, the technical deadlines win every week and the people work slips until go-live.

How do conference room pilots (CRP) and UAT support adoption?
A conference room pilot (also called conference room validation, CVR) puts the configured system in front of the people who will use it, running their own scenarios, so they find problems while there is still time to fix them. UAT is where those users test and formally sign off what they accept. Both double as early training and turn key users into people who can defend the design to their colleagues. A demo where users watch does neither.

Which Windchill changes do users resist most?
Four come up on almost every rollout: check-in and check-out discipline (work is not shared until it is checked in), the formal change process (problem report, change request, change notice and tasks in place of an email), BOM ownership (who owns the engineering BOM and who owns the manufacturing BOM), and part numbering (system-assigned numbers in place of numbers people read meaning from). Each needs a decision in design, a reason people can repeat, and role-based training.

How do you measure PLM adoption after go-live?
Track training attendance, readiness and adoption as three separate pieces of evidence, because a full training roster does not prove anyone works the new way. For adoption, watch behavior in the system (objects left checked out, changes routed by email, BOMs exported to spreadsheets and edited there) and tie it to business metrics leadership already watches, such as change cycle time and cost of poor quality, measured against a baseline taken before go-live.

What is hypercare in a PLM implementation?
Hypercare is the period of extra support right after go-live while users learn the system. Users get one place to report problems, every report gets an answer within an agreed time, defects are fixed first and new requests wait, open issues are reviewed daily, and the incident trend goes to the sponsor. It should end when the system is stable and incidents are low and steady, not on a calendar date.

Organizational Change Management for PLM and Windchill Rollouts: How to Do It