Do you remember the scene from History of the World Part 1 where Mel Brooks, playing Moses comes down from the mountain and says I give you these 15 (dropping the tablet) I mean these 10 commandments? I kind of feel the same way about the PLM Code of Conduct. I thought it would be pretty easy to come up with 5 rules but in the end a lot of it comes down to common decency and common sense. So in order to avoid redundancy and more importantly boring blog articles sounding preachy and moralistic I will get it all out of my system in one article. I give you the 5… I mean 3 PLM Codes of conduct. As you recall from my previous articles the first principle was "leave no man behind", meaning PLM vendors should assure upgrade paths for users of previous versions that are not too expensive or require extensive services. The second principle was "if you love somebody set them free" meaning PLM vendors should not lock up their data in proprietary schemas or make it difficult for their customers to utilize other technology solutions as part of their product development process. The final principle is "honesty is always the best policy". Obviously this applies to most things but particularly in the Product Lifecycle Management (PLM) space. PLM is a big investment and companies have a lot at stake when they purchase PLM. If it is not going to be a good fit or if there are better approaches for deployment vendors need to be upfront about their solutions. Obviously, companies need to do their due diligence and make sure the solution is viable but sometimes vendors will follow the path of least resistance because they don't want to disrupt the sales process. This blog will review and debunk some of the myths that are perpetuated in these pre-sales situations.

Myth #1: "Everyone has PLM and is using it across their enterprise."

This gem is an often sited fact derived from an Aberdeen Group report stating that best in class manufacturing companies use PLM. It should be noted that the study is of 185 companies and only 20% of them actually had "adopted a PLM program", whatever that really means. The truth of the matter is that adoption of PLM is still far from universal. The last two years CIMdata has indicated that the market has grown but if you want to know how much you will need to spend a little money with them to get the full report. So while more and more companies are starting to adopt PLM it is still fair to say most companies are still trying to figure out how best to leverage this technology for their product development process. There are still spirited discussions about the role PLM plays and where it actually fits in the enterprise. The take away is that your company is unique and while there are numerous companies out there taking advantage of PLM technology in their product development process the paint is far from dry. The majority of companies leveraging this type of technology are more oriented around data vaulting and some workflow capability. Product Portfolio Management, Governance and Compliance and Requirements Management are still fairly new concepts. Even supply chain management is somewhat fragmented with bigger companies using this capability to manage cost but struggling to get their customers and vendors to cooperate. One of the better articles I have read on PLM adoption was written by Kevin Prendville and A.J. Gupta from Accenture last October. The article, titled "Product lifecycle management the innovation enabler goes mainstream", makes several interesting points. This quote is particularly telling, "Even many industrial companies that utilize PLM principles still do not apply them as part of an end-to-end discipline. Among businesses in other sectors, the use of PLM can be rudimentary at best." The point that the article is making is that while many are familiar with PLM and may even own it proper adoption still has a long way to go.

Myth #2: "Out of the Box solves PLM implementation costs and deployment time."

There have been a few articles on this topic. To be clear utilizing a predetermined configuration will reduce the cost of the implementation and the time it takes to deploy but in the PLM world one size rarely fits all. I think the idea behind quick starts and accelerators is good but misused. The true statement is that the more customization and configuration you require the more expensive and time consuming it will be. The prolific Oleg Shilovitsky wrote an article last May discussing the pros and cons of the out of the box approach titled "Out-Of-The-Box PLM and Open Source Option". In the article Oleg writes this regarding the "out of the box" pitch," They (customers) need software to solve problems today and not tomorrow. Out-of-the-box started as an initiative to compensate long, complicated and expensive implementation cycle. The fundamental idea was simple- you pay more, but you can take a system and work now. One of the reasons it wasn't successful is in the nature of manufacturing organization." His explanation as to why "out of the box" fails is that every organization considers itself unique and when you start getting to some of the more involved processes out of the box falls apart and becomes another long customization story. Interestingly, one of his readers points out that the failure of OOTB (love the abbreviation) might be due more to a not invented here bias rather than a legitimate need to reconfigure the systems differently. I tend to agree that there is probably some middle ground between a pure out of the box implementation and a massive reconfiguration customization approach. The key is to spend the time up front to define business objectives and understand how the PLM system will meet these objectives and configure the system accordingly. I think the take away on this one is take in the out of the box pitch with a grain of salt and understand that while a preconfigured system might work in some areas more than likely some modifications will be needed. Spend the time to understand how a PLM system is configured. Most vendors don't like to spend time in this area but understanding this can be a key factor in your success.

There are other assertions that PLM vendors and consultants like me present as facts that need to be challenged, but overall I do believe that PLM vendors and consultants want their customers to succeed. Sometimes it is tempting to take shortcuts and avoid the hard work that ultimately leads to success. There are numerous risks that can lead to failure when implementing PLM. The key is to do the upfront work to define the way the system will be used and fully understand what business problems you are attempting to address. Breaking this up into incremental steps will allow you to achieve success along the way and learn from mistakes. Having vendors and partners that are up front about the challenges is a good start. I actually found a relevant cartoon this week that sums up the perils of PLM implementation.

Copyright Scott Adams, Inc./Distributed by Universal Uclick for UFS

[Edit: This has been a repost from 2011]