Are you tired of hearing about a new “next generation” PLM software that promises a “different” approach to product development and an instant remedy to product development woes? Or about a PLM software package that was “designed from the ground up to be web-based and cloud-ready” and therefore, presumably, will deliver better outcome?
I know I am.
It seems the heightened interest in the Internet of Things (IoT) and the resultant attention to the challenges of developing embedded control software has a lot to do with the recent wave of “next generation” PLM tools, methods and promotion webinars.
It’s not that there are no PLM software tools that are old fashion and cumbersome to use. Certainly some software is easier to modify and integrate with external systems (and it doesn’t lose everything during the next upgrade). And a modern software architecture could imply (but certainly not guarantee) a more robust and flexible software.
Why PLM Software Fails
But when you look carefully at product lifecycle management and why product organizations feel the PLM software “failed”, you realize that the root case has far less to do with the PLM software itself and more with suboptimal product development processes and a corporate culture that resists change.
Product development practices today are the result of the confluence of a myriad intertwined engineering disciplines, product development processes, and organizational cultures.
Product development remains essentially a linear, forward-feeding process in which the goals and constraints of downstream lifecycle activities, such as supply chain and service, are frequently dealt with too late in the process, when design changes are impractical because they are too costly, time consuming and, quite frankly, because engineering priorities may be somewhere else.
Modern Agile practices promote early rapid incremental development steps, each incorporating the requirements of all stakeholders. However, reconciling a broad swath of complex and interdependent requirements that are defined using different methods and metrics, and are frequently biased by different cultures that are seemingly at odds with each other, is absolutely daunting.
The Blind Men and the Elephant
It is has become customary to define PLM software as the maintainer of a “single version of the product truth.” But when internal processes are misaligned, then the goals and constraints of different practitioners and decision makers are not aligned either, and they tend to act differently even when considering the very same data.
Rather than a single version of the truth paradigm, PLM becomes more akin to the Indian parable of the blind men and the elephant.
The alignment and coordination of the vastly different approaches and cadences of hardware and software development cycles is complex and burdensome. And when the final product also involves numerous mechanical subsystems, as in cars, the difference in tempos across engineering disciplines is even more striking, as are the cultural differences between these engineering groups.
Product organizations recognize these barriers, but struggle to fight sacred cows and change old habits. Sequential development methods, poor process interfaces, and turf wars will squelch the “single version of the truth” voice of the best PLM tools.
So don’t blame the PLM software (and the vendors).
Product Development Transformation
Unless decision makers involved in all aspects of the product lifecycle operate are in sync, are able to frontload analyses, and harmonize decisions, PLM software is going to offer very little help.
Product organizations should take the time to rethink their product development practices.
All decision makers involved in the entire spectrum of product lifecycle disciplines should have access to unified and harmonized product lifecycle information that facilitates informed decisions. These decisions must not only consider early lifecycle design requirements and constraints, but, as importantly, long-term downstream considerations such as service and end of life. They must apply holistic, long term, total lifecycle point of view rather than making suboptimal localized decisions skewed by irrelevant organizational boundaries.
With this in mind, you should evaluate your product development process and seek to maximize your organization’s ability to make better decisions that are based on objective product data and reduce cross-organizational friction. This, not a nebulous “next generation” label, should be your guide.