Your PLM Didn’t Fail. It Told You the Truth.

by Daria Kniese

THE FASHION DECISION ECOSYSTEM™
Executive Essay No. 02

Technology doesn’t create organizational maturity. It exposes it.

Every failed PLM implementation has a villain. Sometimes it’s the software. Sometimes it’s the implementation partner. Sometimes it’s IT. Sometimes it’s „the business.“ I’ve heard every version, and over the last decade I’ve sat in many of those meetings.

My career has allowed me to experience transformation from almost every perspective inside a fashion company. I’ve conducted software tenders, gathered business requirements, evaluated vendors head-to-head, facilitated process workshops, mapped AS-IS and TO-BE processes, reviewed functional design documents, written test scenarios, tested software, trained end-users and advised executive leadership on strategic decisions. Somewhere along that journey I realised something that fundamentally changed how I viewed transformation.

The software was rarely the first thing that failed. It was simply the first thing honest enough to expose what already had.

The most dangerous sentence in fashion transformation is one I’ve heard countless times: „Once the new PLM is live, our process will improve & we will generate the ROI from the business case.“ It sounds perfectly reasonable. It is also one of the biggest misconceptions in our industry.

A PLM system doesn’t create an effective product development process. It accelerates the one that already exists. If every teams follows their own processes they become faster – but remain inefficient.  If ownership is ambiguous, the software digitizes the ambiguity. If collaboration is broken, workflows simply make the dysfunction more visible. Technology scales behaviour. It doesn’t transform it.

Over the years I’ve spent hundreds of hours in workshops. Walls covered with brown paper. Virtual Miro boards. Hundreds of sticky notes. Current-state maps. Future-state maps. Approval workflows. Every session produced beautiful process diagrams. Yet many of those organisations still struggled long after the workshops ended.

Why? Because we were mapping processes—not decisions. That distinction changes everything.

Product development is often described as a process. I don’t believe it is. It is a sequence of commercial decisions. Should we approve this design? Should we challenge this cost? Should we delay the launch? Should we switch suppliers? Should we increase the minimum order quantity? Should we protect margin or chase volume?

Every one of those decisions influences sourcing. Sourcing influences lead times. Lead times influence logistics. Logistics influence availability. Availability influences markdowns. Initial Retail Price, Promo Pricing & Markdowns influence profitability.

The process is merely the route. Decisions determine the destination.

One of my favourite questions during software selection was deceptively simple:

„Why is this actually a requirement?“ The answers were almost always revealing.
„Because that’s how we’ve always done it.“
„That’s how the current systems work.“
„The business requested it.“

Sometimes, we forget to describe requirements as future capability the business genuinely needs in order to generate added-value. Most described historical habits. That’s often where implementations quietly begin to fail—not during testing or go-live, but in the earliest workshops, when organisations mistake familiarity for business value.

People often say PLM manages products. I disagree. PLM manages organisational behaviour. It reveals where decisions wait, where information gets lost, where ownership is unclear, where departments optimise themselves instead of the business and where unnecessary complexity has quietly become accepted as normal. The software doesn’t create these realities. It simply removes the places where they can hide.

Picture the executive steering committee. The implementation is behind schedule. Testing is taking longer than expected. Budgets are increasing. Users are frustrated. Someone inevitably asks: „What went wrong with the implementation?“ After years of sitting in those meetings, I believe that’s the wrong question. The better question is: „What truths has this implementation exposed about the way we operate?“

Every delay tells a story. Every workaround tells a story. Every rejected requirement tells a story. Every change request tells a story. The real challenge is deciding whether we’re willing to listen.

Transformation doesn’t begin with vendor demonstrations. It doesn’t begin with configuration. It doesn’t begin with business requirements. It begins much earlier, with a far more uncomfortable question: How do we want this organisation to make decisions? And which of those decisions generate significant business value?

Only after that question has been answered should we discuss software. Without clarity in decision-making, even the world’s best platform will faithfully automate uncertainty.

Looking back, I no longer believe I’ve spent my career implementing software. I’ve spent it observing how retail organisations make decisions. I’ve watched exceptional transformations and struggling ones. The difference was rarely technology. It was organisational readiness. Technology simply made it impossible to hide.

Perhaps that’s why I no longer believe failed PLM projects are primarily technology failures. More often than not, they are leadership opportunities disguised as software implementations. And mirrors, inconveniently, never create the reflection. They simply reveal it.