After 15 years working in PLM, we have seen that many PLM implementations are being delivered late and only after lots of pain for everyone involved and some projects fail to deliver anything at all. So why is PLM so hard to implement? Why are the projects almost always late? And how can we deliver a successful PLM on time?
Why projects are late and/or fail
Here are some common reasons why a PLM project is late or fails:
- Resources: getting the right ones with the right knowledge
- Unrealistic expectations of management and users
- Under-estimating the complexity of PLM
- It’s the fault of the software: we should have bought PTC, Dassault, Siemens etc.
- Delays of vendors to fix “critical” issues
- Technical problems that delay migration of data
There are many more but in essence it comes down to Project Management and resources, and in PLM the way we manage these things doesn’t seem to have changed in decades.
Let’s start at the beginning, scoping the project: how long will it take and how much will it cost?
Often, implementers are obsessed with counting man days. Most PLM projects are scoped in the same way, the implementer spends days or weeks producing a huge excel spreadsheet that has a large number of line items specifying each activity and the number of days that each will take. They add them up and triumphantly present a huge number of XXX days. The customer is shocked at the huge number and the next few weeks are spent trying to find “savings”. It is an archaic way of defining a project that assumes we know everything from the beginning. But how can this be right? How can we know what we don’t know before we even begin?
Over time, lots of project management ideas have come and gone to solve this failure to deliver PLM, such as Platforming, Critical chain, etc. which certainly improve things, but I propose we run our PLM projects as if the PLM team were a “Startup”.
“The Lean Startup” is one in a series of recent books that try to help entrepreneurs create and manage successful tech startups. The book has many ideas, but a key one is to get something to market as soon as possible so you can learn what you don’t know. The idea is not new, e.g. Agile software development methodology also promotes it, and ironically these methods basically reuse many ideas from Lean Manufacturing that the manufacturing industry itself invented. In “The Lean Startup”, this idea takes the form of a concept called the MVP, the Minimum Viable Product.
I propose we need to think about our PLM projects as the Minimum Viable PLM to make our projects a success.
What is a Minimum Viable PLM?
A Minimum Viable PLM is not a prototype, it is not a “bad” implementation, it is a production worthy system, but we have cut down the requirements to the core. Once it is in production, we rapidly move to improve the solution, fix issues and add features that make our PLM the fully featured system our users require.
So we need to learn from our users and fix our mistakes, but we also need to be brave and make decisions (even the wrong ones) to avoid analysis paralysis. It does require a responsive dynamic team to make it work,
So the question is “Could it work?”. Our experience tells us it does, as the following case study illustrates.
MVP Case study
A medium size French company that makes postal machines, implemented a successful PLM in 1 year, How?
A project manager who ruthlessly defined his MVP
An infrastructure that meant they could change their decisions, quickly and rapidly and learn from mistakes
A small highly focused team
A mechanism to release new software updates almost daily
Really good software people, a skilled implementation team (Accenture) and a fully engaged customer
At go live, our Minimum Viable PLM looked like the image below and was successfully used in production.
But that was not the end; two years after go live, it now looks like this:
Over time there have been issues but these have been rapidly resolved. More features are constantly being added and some will take more time such as a key goal to radically change the way products are designed using ETO (Engineer-to-Order); some things in PLM are just plain difficult.
MVP really works, we have seen it work and we know that even in projects that are traditionally scoped, it rapidly takes hold, by simply providing the tools to iterate quickly. However we must have the project management and technical expertise to support this concept and the bravery to make decisions that may be wrong.