Go-Live Is the Milestone.
Adoption Is the Result.
A PLM system that technically works but that people route around has not been implemented, it has been installed. We deploy Windchill and 3DEXPERIENCE configured to your process, connected to your ERP, and used by the people it was bought for.
Fixed scope and a committed schedule, agreed before the project starts. What comes after hypercare is covered separately by Managed Services.
Four Ways a PLM Rollout Goes Wrong,
and What We Do About Each
None of them are technical failures. The system usually works exactly as configured, which is the problem.
Configured around the demo, not the process
The system gets set up the way it was shown in the sales presentation, because that is the version everyone has seen. Six months later, the workarounds start, and each one quietly carries process logic that now exists nowhere in the system.
Everything switched on at once
All departments, all data, all functionality, on one weekend. When something goes wrong, and something always does, nobody can tell which part caused it, and the organization loses confidence in the system in the first week.
Twenty years of data migrated wholesale
Every file, every revision, every abandoned variant, moved across because deciding what to leave behind requires decisions nobody wants to own. The new system inherits the old mess and users stop trusting search results within a month.
Integrations deferred to a phase two that never comes
The budget covers the PLM system, and connecting it to the ERP is pushed to the next cycle. Meanwhile someone keeps re-typing BOMs by hand, and the single biggest benefit of the project never actually arrives.
All four have the same root cause: decisions deferred because they are uncomfortable, then made by default under time pressure. Our delivery model forces each of them to be made deliberately, at the point in the project where changing your mind is still cheap.
Five Phases, Each With
a Condition for Moving On
Projects rarely slip all at once. They slip because a phase closes while something is still open, and the gap surfaces two phases later. Every stage here has an exit criterion that has to be met before the next one begins.
Mobilization & Solution Blueprint
We confirm the design before touching the system. If you have already been through a consulting engagement, this phase is short and mostly validation. If not, it is where the process decisions get made, because they will get made either way, and it is cheaper here.
- Project team, roles, and decision rights established on both sides
- Process design confirmed with the departments who will use it
- Data model, BOM structure, lifecycles, and change workflow specified
- Integration scope and interface behaviour defined
- Migration scope decided, including what stays behind
- Signed solution blueprint covering configuration, integration, and migration scope
- A named business owner per process area, with authority to decide
- Committed schedule and phase plan agreed by both sides
Environment & Configuration
The system gets built to the blueprint. Infrastructure, licences, security, and the full configuration of the data model, roles, and workflows. Every deviation from standard functionality is logged with the reason, so the next administrator knows why it exists.
- Environment set up, on-premise or cloud, with backup and restore in place
- Licence server, user provisioning, and security hardening
- Data model, object types, attributes, and lifecycle states configured
- Roles, permissions, and change and release workflows built
- Custom development where the standard configuration falls short
- Configured system demonstrated against the blueprint, process by process
- Restore from backup tested successfully, not assumed
- Configuration documented, including every deviation and its reason
Migration & Integration
Runs in parallel with configuration, because both depend on the same decisions. Data is cleansed, mapped, and loaded in trial runs before the real one, and at least one working integration is delivered in this phase rather than deferred to a later budget cycle.
- Legacy data cleansed and mapped to the new structure
- Trial migrations, with the results reviewed by your engineers
- Interfaces built to your ERP, warehouse, or production systems
- Error handling defined for what happens when a transfer fails
- Interface testing with real data volumes, not samples
- Trial migration accepted by your data owners, with discrepancies resolved
- Integrations passing end-to-end tests in both directions
- Rollback procedure documented and tested
Validation & User Readiness
Acceptance testing is run by your people, on your data, against the processes they will actually perform. Not a demonstration by us. If your users cannot complete their own scenarios, the system is not ready, and that is a finding rather than a delay.
- Test scenarios written from your real processes, not generic scripts
- Acceptance testing performed by the users themselves
- Key users and administrators brought up to working competence
- Documentation and procedures handed over to your team
- Findings resolved and retested before sign-off
- User acceptance signed off by the business owners, not by IT alone
- Administrators able to perform routine tasks without us in the room
- Open findings either resolved or formally accepted for a later phase
Cut-Over & Hypercare
Go-live happens in stages, by department or product line, so each one stabilizes before the next follows. Our people are present during the transition and for a defined hypercare period afterwards, with a documented route back if something does not hold.
- Final data migration into the production environment
- Phased go-live, with each stage confirmed before the next begins
- On-site presence during cut-over and the first working days
- Hypercare with fast-track escalation and daily status calls
- Adoption monitored, so quiet workarounds surface early
- System in productive use by the intended users, measured rather than assumed
- Incident volume stable and within the agreed threshold
- Handover pack complete: documentation, runbook, and open items list
What happens after hypercare
The project closes and the system moves into normal operation. Some companies take it over entirely with their own team, which is why the handover pack exists in the first place. Others keep us on for administration,
Two Platforms We Deploy,
and Everything We Connect Them To
As an authorized partner of PTC and Dassault Systèmes, we implement both platforms end to end. The integration layer is what turns either of them into something the rest of the business can use.
Windchill PLM
Product data and lifecycle management
- Data model with object types, attributes, and numbering rules
- BOM structures and the relationship between engineering and manufacturing views
- Lifecycles and change workflows, including who approves what and when
- Roles and access, mapped to how your teams are actually organized
3DEXPERIENCE Platform
Unified collaboration environment
- Role and licensing structure, matched to who genuinely needs which capability
- Collaborative spaces and the governance rules that apply inside them
- Data model and lifecycles on the platform, with maturity states defined
- Deployment model, whether cloud, on-premise, or a combination
The integration layer is where the project pays for itself
A PLM system that only serves the design office has delivered a fraction of what it cost. At least one working integration is in scope for the first phase, built by our own engineers rather than deferred to a later budget cycle.
Your ERP
BOM and revision transfer, item master synchronization, and change propagation into planning
InfoBiro WMS
Item and packaging data flowing from engineering into warehouse operations
DigiPro System MES
Product and tooling data reaching the shop floor, with production feedback coming back
Other Business Systems
Document management, quality systems, and reporting, over REST, file exchange, or database level
What is feasible depends on how your ERP is configured, not only on which one it is. Two companies running the same product often need entirely different interfaces. Integration scope is defined during the blueprint phase, once we have seen both sides.
Where You Are Starting From
Changes the Whole Project
Implementation proposals often look identical regardless of the situation. They should not. These three starting points carry different risks, different effort, and different reasons for failing.
Your First PLM System
Product data lives on shared drives and in the heads of a few engineers. There is no system to replace, which sounds simpler than it is: every process rule has to be decided rather than inherited.
- No existing configuration to work from, so the blueprint phase carries more weight
- Data exists but has never been structured, numbered, or governed
- Users have no reference point, so adoption depends heavily on how the change is introduced
- Scope creep is the constant pressure, because everything looks possible
Replacing an Existing System
You already run a PLM platform and are moving to another one. The migration is the project, and the hardest decisions are about what not to bring across.
- Years of accumulated data, much of it obsolete, all of it someone's responsibility
- Existing integrations that have to keep working during the transition
- Users with habits formed on the old system, which is harder than having no habits at all
- Both systems live in parallel for a period, which has to be planned rather than tolerated
Extending What You Already Have
The system works, and now it has to cover a new site, a new module, or a connection that was left for later. The constraint is that the existing environment cannot stop while you extend it.
- Production users are already dependent on the system, so every change carries risk
- The existing configuration may not have been documented by whoever built it
- A new site often works differently, and the question is whether to align it or accommodate it
- Shorter and more predictable than the other two, provided the current state is understood first
What we need from your side
Worth stating before a contract rather than discovering during Phase 2. Implementation projects fail on client-side availability more often than on anything technical, and no amount of effort on our side compensates for it.
A Decision Maker
One person per process area with the authority to settle a disagreement, not to escalate it
Key User Time
Workshops in the blueprint phase and acceptance testing later, from the people who know the process
Access to Data Owners
Someone who can answer what a legacy attribute means and whether a folder still matters
IT and Security Clearance
Access approvals moving at the pace of the project, since this is where schedules slip quietly
We schedule around production and release cycles wherever possible, and the effort required from your side is estimated per phase in the project plan rather than left as an open commitment. If a period genuinely does not work, the schedule moves. What does not work is proceeding while assuming the availability will appear.
PLM Implementation,
Answered Plainly
The questions that come up between the first meeting and the signed contract.
No. If you already have a process design, requirements, and a clear scope, whether from your own team or another partner, we start at Phase 1 and validate what exists rather than rebuild it.
What cannot be skipped is the decisions themselves. Data model, BOM structure, change workflow, and migration scope have to be settled before configuration begins. If they are already settled, Phase 1 is short. If they are not, that is what Phase 1 is for.
Where the decisions are genuinely open and the stakes are high, a separate consulting engagement is usually the cheaper route, because it happens before you have committed to a platform.
Yes. The new environment is built in parallel, so the system your teams use today keeps running until each department actually switches over.
The exception is the cut-over itself. For a defined window, usually a weekend, data is frozen while the final migration runs. That window is agreed in advance and scheduled around your release cycles, not announced two weeks before.
Because go-live is phased, only the department switching over is affected at any point. The rest continue as normal.
It gets sorted into three groups, and that sorting is a decision made in Phase 1 with a named owner on your side:
- Migrated: data with operational value, cleansed and mapped into the new structure
- Archived: historical records kept accessible but out of the working system
- Left behind: obsolete revisions, abandoned variants, and duplicates
Nothing is deleted. Migration runs in trial rounds first, and your engineers review the results before the real one. The decision on what not to migrate is the one that determines whether the new system stays usable, which is why we insist on it being made explicitly rather than by default.
Enablement is part of the project, in Phase 4. We bring your key users and administrators to working competence on the configuration we built, using your own processes and your own data rather than generic exercises.
From there the knowledge spreads internally, which works better than an external trainer explaining your process back to you. The documentation and procedures we hand over are written so your key users can run onboarding for the rest of the organization.
The exit criterion for Phase 4 is specific about this: your administrators have to be able to perform routine tasks without us in the room before the phase closes.
Phase 1 is quoted as a fixed fee, because its scope is known: workshops, design confirmation, and a signed blueprint.
Phases 2 to 5 are quoted as a fixed price against that blueprint, once it exists. That sequence is deliberate. A fixed price given before the design is settled is either padded to cover the unknown or renegotiated later, and both outcomes damage the relationship.
Licences are separate and contracted directly between you and the vendor. We manage the commercial process but the agreement is in your name.
They will. On a project of this length, something in the business changes before it ends, and pretending otherwise is how projects end up delivering the wrong thing on time.
What matters is that changes are handled as decisions with a visible cost, rather than absorbed quietly until the schedule collapses. Each change request gets an assessment of effort, schedule impact, and what would have to move to accommodate it. You decide whether it goes in now, in a later phase, or not at all.
What we push back on is changing the design during configuration, because that is where a two-day change turns into a two-week one. If something fundamental shifts, it is usually cheaper to pause and revisit the blueprint than to build around it.
Yes, and it is a more common request than the industry likes to admit. It starts differently from a normal engagement: with an assessment of where the project actually stands, which is rarely where the status report says it does.
We look at what is configured, what is documented, what was tested, and what was quietly deferred. The output is an honest position and three options, usually:
- Continue from here, with the gaps closed first
- Rebuild specific parts where the configuration will not hold
- Stop, if the premise itself was wrong
The third answer is uncomfortable and we give it when it applies. Continuing a project built on the wrong design costs more than restarting it.
Because we measure it rather than assume it. The exit criterion for the final phase is productive use by the intended users, and that means looking at what the system records: who is working in it, which processes run through it, and where activity is lower than expected.
A department with unusually low activity is not a training problem. It usually means a workaround has been found and nobody mentioned it, because the workaround is faster. Those surface during hypercare while the project team is still in place, which is the only time they are cheap to fix.
You receive a handover pack: full configuration documentation, an administrator runbook, integration specifications, and a list of anything formally deferred to a later phase.
From there, some companies run the system entirely with their own team, which is exactly what the handover pack exists for. Others keep us on for administration, upgrades, and integration maintenance under Managed Services.
That decision is planned for during Phase 5, while the project team is still in place, rather than raised in a hurry once everyone has moved on.
We work out which of the three starting points you are in, what is already decided, and what is still open. That usually takes one meeting.
The most useful thing you can bring is not a requirements document. It is an honest account of what has already been tried, including anything that did not work. Previous attempts tell us more about what will succeed here than any specification will.
From there we propose a scope for Phase 1 with a fixed fee, and you decide whether to proceed. Start there.
Question not covered here?
Describe your situation and we will answer against it, not against a generic project.
A System Nobody Works Around
Is the Only One Worth Implementing
Tell us where you are starting from and what has already been tried, including anything that did not work. Phase 1 is quoted as a fixed fee and ends with a signed blueprint, which is the point at which a committed schedule actually means something.