Product Lifecycle Management (PLM) has shifted into an essential requirement for product development companies over the past few years. It is no longer about whether or not a company will have PLM but more about which platform they choose and how they deploy the software. There is a lot of misinformation being distributed by vendors and their partners to try and accelerate purchase cycles. This misinformation causes companies to make poor decisions around PLM software and how to adopt the software. Messaging around simplicity, accelerators and jump starts makes it seem like all one has to do to be successful with PLM is place the purchase order and soon you will be awash in productivity and automation. Time to market issues and product defects will simply melt away all from buying or subscribing to software and a jump start services package. The problems and processes PLM addresses are complex; therefore the solutions are also complex. Simplified software and services will fall short in meeting most company's business needs. The focus on simplicity ignores the real issues which are all rooted in aligning business outcomes with technology. Quick start solutions with little flexibility to change their tools will typically just shift business issues from one platform to another.
In the rush to identify features and functionality the basic questions around what outcomes are expected from PLM adoption often are ignored. This leads to missteps in the initial deployment and can significantly impact the results a company hopes to achieve. Many companies have evolved over time and their processes for new product introduction, data and change management, supply chain management, compliance, project management and many other processes have developed in an organic manner. When faced with having to reconcile these processes into a PLM solution many elect to try and short cut the process by using accelerators or jump start packages from PLM service vendors. The attraction of these packages is that the cost for services can be capped and the time to adoption is reduced because you avoid having to redefine process. The idea is that you will use the processes and structures that are already contained within the application. Sometimes this is done by the PLM service partner who has prebuilt templates for different industry segments other times the PLM vendor themselves offers limited tools that force you to conform to their methods. Cloud based solutions tend to fall into this category when compared to the more robust on premise solutions.
The fact remains that enterprise software deployment has a troubling history and this trend toward simplicity is a logical progression to address the concerns of the industry. There are numerous stories about the multi-year, multi-million dollar deployments of PLM and ERP that cause CIO's to cringe and CEO's to wake up in a cold sweat. The mere mention of embarking on another large IT project can cause shockwaves throughout a company and having a story around simplicity and quick starts is a great way to calm that fear. The fact is that for some companies this does work. If you are a start-up company then using this method will get you further down the road than you are today. If you have any success and grow it may create issues in the future but most companies elect to worry about that when the time comes. If you have basic simple products and processes then this method will also suffice but most companies typically have a fairly intricate environment with numerous systems and processes to transcribe into the PLM solution they have purchased. Moreover, they are usually wrestling with significant business issues that need to be addressed by the PLM solution of their choice. If this is given little or no consideration upfront then the likelihood they will be able to resolve these business issues with the PLM adoption is poor. It is more likely they will just end up in the same situation again with different tools.
What we have learned in our experience working with hundreds of clients is that there is a middle ground. We have been involved with the quick start type solutions. We have even developed some of these as a response to the industry demand but the patterns we have seen from successful deployments of PLM is that business outcomes must be considered upfront in order for a project to have a high likelihood of success. This is why we have recruited and hired resources that have spent time in the industry on the user side of PLM. These resources understand firsthand what matters in deploying and using PLM. We have resources that have overseen the adoption of PLM at multiple organizations and they understand the financial impact PLM can have when approached properly. This experience has led to the creation of our methodology that we call "Start State". This process is driven first by business architecture mapping to understand the short term and long term outcomes clients are looking to accomplish by the adoption or expansion of PLM. Once this baseline has been established then a more in-depth needs analysis can be undertaken that will link the business outcomes to the execution of the PLM deployment. To avoid the "science experiment", deployments can be phased but the key is that even doing small sprints with PLM deployment will ensure that they are aligned to business outcomes so that the financial investment is warranted. This approach avoids situations we see today where companies have used a quick start approach and now need complete overhauls because they failed to consider business outcomes. It also avoids situations where tools have been deployed but no one in the company really understands the business value behind them. This lack of understanding thwarts adoption and is one of the key factors in PLM failure.
The fundamental shift for Zero Wait-State has been to move away from focusing purely on the technology and becoming more oriented to the business issues that the technology resolves. We have long prided ourselves in tackling the most challenging aspects of PLM deployment, including engineering collaboration, data migration and system integration. While it is true that these are valuable activities if we do not understand the business drivers behind doing these types of projects then we are just a hammer looking for a nail and while through blunt force trauma we may succeed in getting the solution implemented it may not be a positive experience for either us or the customer. By spending time upfront to map out and link to the business architecture we can ensure the customer is making the right decisions and we can make sure we are deploying a solution that truly satisfies our customers. This approach has resulted in close partnerships with several of our customers and we are using this as an engagement model going forward. By driving these results for our clients we become a valued asset for them and the relationship is much more impactful for both sides.
[Edit: Repost from 2013]
