3 bad PLM implementation habits to kill in 2017

3 bad PLM implementation habits to kill in 2017


PLM implementations are slow. Cloud PLM reduced the level of complexity, but still there are things that cloud PLM cannot do for you. These things are directly related to the way PLM implementations are managed by IT and service companies. And these problems are not technology or product related. It is actually people related. I have my collection of “bad PLM implementation habits”.  Today, I want to come with my top 3 bad PLM implementation habits I recommend to change in 2017.

1- Insisting on 100% completeness of PLM use cases

Computers are good in main cases. People are good in exceptions. By trying to nail down PLM project to cover all use cases, we risk to over-complicate the solution. And it takes time and money and people resources. So, the new approach should be to program PLM implementation around main use cases. You can ask me what about the rest? My recommendation – kick out the rest as exceptions for manual processing. It might be incomplete, but it will make your PLM implementation simpler and healthier for the future. Some of these “what if” scenarios might not happen.

2- PLM “projects”

Traditionally organization make new technology come as a “project”. The more complicated problem, the bigger the project. But as project get bigger, the chances of failure increases. So, what to do? Switch from “project” to agile releases. And make them happen timely. Every 1-2 months. You might screw up some of these releases. Or you might come with incomplete results. But as you repeat more, implementations will improve. Each “release” brings enhancements in PLM implementation. As soon as you work out 1-2 months releases, move into continues integration. Ask your PLM vendor how to implement PLM technology using agile implementation methods. This is a good starting point how to escape risky PLM projects.

3- Focus on PLM TCO

PLM implementations are too obsessed with total cost of ownership (TCO). The obsession is so big that often it starts to impact the outcome. Actually cost generate benefits. And benefits are good. So, focus on how to generate benefits and not how to cut cost. TCO is discourage new functionality and as a result of that you can miss PLM value. So, shift from PLM TCO to PLM value. And combine it together with shift from PLM “project” to “releases”.

What is my conclusion? Old habits die hard. Remember the phrase “Nobody ever got fired for choosing IBM”? It came from the time when the focus was on how to take less risky decision. The result was impacting project duration and cost. Most of companies today don’t have a luxury to run 5 years PLM projects. There are things in PLM implementation practice that needs to be changed. Often, companies are doing things not because they are better, but because they did it before. Just my thoughts…

Best, Oleg

Want to learn more about PLM? Check out my new PLM Book website.

Disclaimer: I’m co-founder and CEO of openBoM developing cloud based bill of materials and inventory management tool for manufacturing companies, hardware startups and supply chain. My opinion can be unintentionally biased


Share This Post