One day you discover that your PLM implementation project is not doing so well. It happens and it called failure. Scott Cleveland’s blog took me back to the topic of PLM implementation failures. Unfortunately, I didn’t find the link on CIMdata research to read the paper mentioned by Scott. According to the post, wrong scoping and failure to get buy-in from users are on the topic of the list. Not a surprise.
Failure is not such a rare situation in IT world. Google “IT project failure” and your can quickly discover that 68% of all IT projects fail. Few months ago, I had long discussion around my Why PLM stuck in PDM? article on LinkedIn. I cannot publish all comments from closed discussion group, but the question about “how to identify what is PLM project failure” was one of the dominant topics in the discussion. Guess what… no agreement about how to identify “Failed PLM project”. Few other notable references on PLM failure publications: PLM Failure, you didn’t see anything; Keynote presentation by Martin Eigner on ProSTEP iViP Symposium 2009.
Unfortunately, most of PLM events and publication are placing shining picture of success on their PLM references. The problem that all these successes looks the same. It is time to remember Leo Tolstoy passage from Ana Karenina – Happy families are all alike; every unhappy family is unhappy in its own way. One of the interesting place to learn about failures is to attend FailCon – the conference for startup founders to study their own and others’ failures. There is no PLM Failure Con… yet. And I doubt companies will be ready to do so.
Reading and discussing PLM failure articles, made me think that you really want your first PLM project to fail. Why so? Here are few thoughts…
Challenge the status quo. As people often say – PLM exists in every manufacturing company. You do product lifecycle management by the way you manage product development processes, store data, communicate within organization and with outside contractors. At the first attempt you will try to build PLM system that mimic all existing practices. I’ve heard it many times – if you have a mess, don’t bring a computer. Otherwise, you will have computerized mess. First, fix the mess, then bring computers.
Get rid of outdated stuff. Every manufacturing company usually trailing lots of existing software and practices. It is hard to cut the cord and switch and leave outdated stuff behind you. PLM project failure can bring an awareness to the problem and force company to make a change. It is hard to company and people to admit they do something wrong. Especially if they do it many years.
Learn as you go. You have the best chance to learn when you actually do something. Regardless on your experience, every manufacturing company is different. How to see that new system will fit? Put it in action! When it comes to people, they only way to see if it works is to try it. Then you fail and only after, find the right way to do it right.
Think about your PLM system in the same way you think about product development processes. Your design doesn’t fit manufacturing plan, some requirements are failing to communicate and some of them got misunderstood. Your first manufactured item fails and you need to fix issues. These are absolutely normal thing for every manufacturing company. Your PLM is not much different.
What is my conclusion? Failure is not an option is probably wrong PLM implementation strategy. Opposite to that, you need to bring it fast, engage with users, fail, fix it and bring back fixed. Lifecycle. This is the only way to make it right. Just my thoughts…
Best, Oleg
Pingback: Prepare For The Worst – Brent Petring()