The symptoms
Low PLM adoption shows up in daily habits well before it reaches a steering committee report. Login counts can look healthy while the real work happens somewhere else. Watch for these signs:
- Specifications get entered in PLM after approval. as a record, and never used to make the decision
- Formulators keep their own trial sheets. and copy final numbers across
- Approvals run by email. and someone clicks "approve" in the system later
- Regulatory teams ask project managers for data. instead of looking it up
- Key users fill in records for colleagues. who won't log in
You aren't alone in this. Bas Koomen's research on PLM projects estimates that at least 50% fail, although the figure hasn't been confirmed statistically. Check your own case by picking one recent launch and tracing where each decision was actually made.
What parallel spreadsheets mean
A parallel spreadsheet means the system can't hold a piece of work your people need to do. It's rarely defiance. Oleg Shilovitsky, CEO of OpenBOM and author of the Beyond PLM blog, describes spreadsheets as a rational response to a gap in the system: "The spreadsheet is where working knowledge lives because no enterprise system was ever designed to hold it."
In formulation-driven businesses, the gap sits in early work. Teams compare five versions of a recipe or note supplier alternatives. They also test claims against target markets, and none of that has anywhere to go in PLM. So the spreadsheet holds the thinking, and the system only gets the answer.
Treat each spreadsheet as a requirements document someone has already written for you. Ask the owner which columns they'd lose if the file were deleted tomorrow. Those columns are your design backlog.
Design cause versus training cause
Most stalled programmes have a design cause, and training only fixes what's left once the design works. The two look alike from a distance, since in both cases people avoid the system. They separate when you watch someone work.
Signs the design is the cause
The design is at fault when skilled users avoid the system too. A strong key user who builds a workaround is telling you the process in the tool doesn't match the process on the floor. Other signs are fields people fill with dummy values and steps they skip in a fixed order. Complaints that name a specific screen also point to the design.
Signs training is the cause
Training is at fault when users can't find a function that works well for colleagues who know it. Errors vary from person to person instead of repeating. And the problem fades once someone sits beside them for 10 minutes.
Before you book another round of classes, watch three users from different roles complete one real task. If all three get stuck in the same place, you've found a design problem.
Where the system asks wrongly
The system asks wrongly when it wants data before that data exists, or wants it from someone who doesn't own it.
Mandatory fields at item creation are the most common trouble spot in consumer goods PLM. A product developer opening a concept can't know the final pack size or the costed formula, so they type "TBC" or wait to create the record until the project's done. Workflows modelled on discrete manufacturing are another. They expect a bill of materials (BOM) where formulators think in recipes with percentages and processing steps.
Approval routes cause trouble too. Many mirror the organisation chart instead of the actual handoffs between R&D and regulatory or packaging teams. And when PLM and the enterprise resource planning (ERP) system both demand the same supplier data, someone types it twice and soon stops typing it in one place.
To find your own trouble spots, list every mandatory field and ask who knows that value, and at what stage.
Fixing the design
The design gets fixed when each request reaches the person who can answer it at the right moment, with the platform's standard features used before any custom code. Customization feels quicker, but every bespoke screen has to be retested at each upgrade. Work through it in this order:
- Map how one product really moves from concept to launch, with the people who do it.
- Mark every point where the system asks for data early or asks the wrong role. Mark repeated requests too.
- Change the configuration first, with adjustments to field timing and stages. Adjust role views and workflow routing too.
- Bring spreadsheet content into the system only where it supports a decision.
- Test the revised flow with the same users who built the workarounds.
Expect to drop requirements along the way. A field nobody can fill at any stage shouldn't be there.
Then retraining
Retraining works once the process in the system matches the work, and it should be built by role around real tasks. A formulator uses different screens from a regulatory specialist or a packaging technologist, so a single generic course wastes most of their time.
Retraining also needs to be part of managed change, with sponsors who explain why the new process matters. Prosci's benchmarking data links better change management to more projects that meet or exceed objectives.
| Change management quality | Projects in sample | Met or exceeded objectives |
|---|---|---|
| Poor | 728 | 15% |
| Fair | 2,125 | 42% |
| Good | 2,577 | 77% |
| Excellent | 503 | 93% |
Source: Prosci benchmarking data, 2007 to 2019.
Run sessions on the redesigned process using your own products and data. Then check two weeks later whether the spreadsheets for that task have stopped being updated.
How we fix low adoption
C+P Consulting fixes low adoption by redesigning the process after diagnosis and then retraining users. It's a specialist PLM consultancy for consumer packaged goods (CPG) and fast-moving consumer goods (FMCG) manufacturers. It works with product and R&D leaders, along with their regulatory and IT counterparts. Its clients manufacture food and beverages as well as beauty and home care products. It also works in ingredients and similar formulation-driven industries.
For an adoption problem, the work draws on the firm's core services. A capability assessment shows where the system and the work have drifted apart. Process re-engineering and blueprinting set out the corrected flow, and implementation work changes the configuration. Adoption and training then follow by role. The firm favours standard-first delivery, which keeps customization risk low and future upgrades simpler.
What sets it apart from large systems integrators is the team. It's small and senior, and it works on site with your people. The same consultants handle business process design and technical delivery, so nothing gets lost in a handoff between a process team and a build team. Scope follows what the assessment finds.
What changes in ninety days
In ninety days, a stalled PLM programme can move from records filled in after the fact to decisions made inside the system for the workflows you redesign. Not every module will be done. The aim is to prove that the corrected process works in your highest-traffic flow.
Measure progress against targets set on day one for the share of active users and use of key features, as suggested by a guide from Knowmore365, an adoption training provider. The guide also suggests tracking time to proficiency and reductions in duplicate data entries. In a CPG business, that means new projects created in PLM at concept stage and approvals completed in the workflow. It also means trial data that stops living on personal drives.
The results depend on how deep the design problems run and how much spreadsheet data has to come back in. Ask for these measures as a baseline before work starts, so day 90 has a real comparison point.
Next steps
Your first step is to diagnose the problem before anyone books more training. Trace one real product through your busiest workflow and record every point where people leave the system. That list tells you whether you have a design problem, and design problems are the reason users aren't using PLM. It also gives any consultant a concrete starting brief. If you want plm adoption help from a senior team that redesigns the process on site and then retrains each role, C+P Consulting does this work for formulation-driven manufacturers. Talk to us about your programme.
FAQ
Start by tracing one real product through the busiest workflow and recording where people leave PLM. Use those departures to identify misplaced data requests or missing functionality. Correct the configuration, test it with the people using workarounds, then retrain each role.
More articles
PLM for process manufacturers: the complete guide
PLM for process manufacturing: how formula-based PLM differs from discrete, where ERP, PDM and PIM take over, and the signs you have outgrown spreadsheets.
Regulatory compliance in Food product development
Food information regulation explained: what must legally appear on an EU food label, which foods are exempt, and where UK requirements now differ
Packaging specifications: why they are the weakest record in the product file
Packaging specification management: what the record must hold at component level, why supplier data decays, and how the pack file drives labels and artwork.
The EU packaging regulation and the product data you will need
PPWR regulation explained: what applies from 12 August 2026, the PFAS and recyclability limits, and the packaging data behind every declaration of conformity.
Product data management for process manufacturers
Product data management for process manufacturers rests on 3 decisions. Poor data quality costs $12.9 million a year on average, per Gartner.
PLM implementation for process manufacturers: a delivery model that holds
A plm implementation for process manufacturers runs in 4 phases. A first release takes 3 to 6 months and an enterprise rollout runs 12 to 24 months.
Specification management for food manufacturers: the complete guide
This guide explains food product specification management, with a 7-step approval order and the BRCGS Issue 9 review every 3 years.
New product development in consumer goods: the complete guide
This new product development guide for consumer goods compares three stage-gate options and four methods to rank projects against capacity.