A PLM programme rarely fails because the wrong platform was chosen. It fails because things were done in the wrong order — usually because the sequence was set by whoever asked loudest rather than by what depends on what.

This paper sets out a dependency-first method for sequencing and is explicit about what to refuse.

1. The dependency that governs everything

Almost every PLM capability rests on one foundation: an agreed, enforced item identity and revision scheme. Part numbering, revision rules and the definition of "released".

If that is not settled, everything built above it is provisional. A change process referencing revisions that people interpret differently produces disputes, not control. A CAD integration syncing to an unstable identity produces duplicates. A BOM comparison across two revisioning conventions produces noise.

So the ordering rule is simple and unpopular:

Nothing that consumes item identity may be built before item identity is agreed, documented and enforced.

Unpopular because item numbering is the least interesting conversation in the programme and the one most likely to be deferred. Defer it and you will rebuild whatever you shipped in the meantime.

2. A dependency graph, not a wish list

Write your candidate capabilities on cards and draw the arrows. In our experience the graph is remarkably consistent across manufacturers:

Item identity + revision rules
        │
        ├──> Document control ──> Approval workflow
        │
        ├──> BOM structure ──> Where-used / impact analysis
        │           │
        │           └──> ECR/ECO/ECN change process
        │                        │
        │                        └──> ERP integration
        │
        └──> CAD data management ──> CAD-BOM alignment
                                            │
                                            └──> Variant / configuration

Two observations that decide most roadmaps:

ERP integration sits deep. It depends on a stable BOM which depends on stable identity. Yet it is almost always requested first, because it is the most visible pain. Building it early means building it twice.

Variant management sits deepest. Attempting it before CAD-BOM alignment is the single most expensive sequencing error we see, because variant rules encode assumptions about structure that then have to be unpicked.

3. Four phases that survive contact with reality

Phase 1 — Foundation (8–12 weeks). Item identity, revision rules, lifecycle states, permissions model, document control. Deliverable: one item type moving through its full lifecycle with real approvers, in production.

Resist the urge to make Phase 1 broad. One item type, done properly, is worth more than six, done provisionally.

Phase 2 — Change (10–16 weeks). The ECR/ECO/ECN process, impact analysis, where-used. This is where the business case from the ROI paper is actually realised and it is the phase most likely to be cut short. Do not cut it short.

Phase 3 — CAD (8–16 weeks). Check-in/check-out, revisions tied to item revisions, CAD-BOM alignment. Duration varies wildly with CAD estate: one system is straightforward, four is a programme of its own.

Phase 4 — Downstream (ongoing). ERP, MES, supplier access, quality, variants. By now identity is stable, so these are integration problems rather than modelling problems.

Go live at the end of every phase. A programme that goes live once, at the end, is a programme with a single point of failure and no feedback until it is too late to act on it.

4. Three requests to decline in year one

"Can we migrate all the legacy data?" Not all of it and not first. Migrate what is actively used — typically the current revision of active parts, which is a small fraction of the archive. Legacy in bulk imports legacy problems into a clean system and makes every subsequent issue harder to diagnose. Keep the old system readable and migrate on demand.

"Can we replicate exactly what we do today?" This request is understandable and almost always wrong. Existing processes usually contain workarounds for the constraints of the old tool. Replicating them faithfully means paying to reproduce constraints you have just spent money to escape. Ask, for each step: would we design it this way if we were starting today?

"Can we add the analytics dashboard?" Not yet. Dashboards over data whose quality is not yet established produce confident wrong answers and they are disproportionately expensive to change once leadership has grown attached to them. Dashboards are a Phase 4 capability at the earliest.

Declining these is easier if you say when rather than no: "yes, in Phase 4, and here is what has to be true first."

5. Sequencing when the business will not wait

Sometimes there is a fixed external deadline — a certification audit, a customer mandate, a plant opening. The temptation is to reorder around it. Usually the right answer is a narrow vertical slice: take the deadline's specific need and implement the full stack for that one product line only.

A vertical slice keeps the dependency order intact — identity, then structure, then change — but at one-tenth the breadth. It ships something real by the date and produces a working template for the rest, rather than a horizontal layer that cannot be used until every other layer lands.

6. How to tell the sequence is wrong

Four symptoms, each usually meaning a dependency was skipped:

  • Duplicate parts appearing after go-live — identity rules were not enforced

before CAD integration.

  • Changes stuck at approval — the workflow was modelled from the org chart

rather than from who actually holds the decision.

  • The BOM in PLM disagrees with the BOM in ERP — integration preceded a

stable structure.

  • Users maintaining a parallel spreadsheet — the most reliable signal of all.

Something they need is missing and it is usually something in an earlier phase than the one you are working on.

Treat the spreadsheet as a diagnostic instrument rather than a discipline problem. Ask what it contains. It will tell you exactly which dependency was skipped.

7. A one-page test for any proposed roadmap

For each item, answer:

  1. What does this depend on and is that already in production?
  2. What breaks if we do this a phase later? (If nothing, do it later.)
  3. Which of the four ROI quantities does it move?
  4. Can we go live with it independently?

Anything that cannot answer (1) and (4) is not a roadmap item yet. It is a dependency waiting to be discovered — better found on a page than in production.

Working paper. If you are sequencing a programme and want a second pair of eyes on the dependency graph before you commit, get in touch.