In this blog series, I provide insights as to why PLM has true potential to be so transformational for life sciences companies, but many aren’t getting there. We have come a long way, established the right technology, developed a defensible roadmap and socialized it, created excitement and ground swell. We put in place a governance model that will help the program last and overcome the many obstacles that commonly slow or dismantle these kinds of programs. Finally, we have selected or built a great team.
Next we need to consider a most important question; how do we actually get this done? This is a question of methodology.
Two Successful Implementation Methodologies
In my career as a consultant, I have seen two successful PLM implementation methodologies.
The first is a descriptive methodology. With a descriptive methodology, the team defines requirements for the solution, perhaps based on optimized business processes. The advantage of this approach is that the business gets exactly what it wants (and possibly what it needs) to optimize the product lifecycle. The downside is typically cost. While one phase alone might seem okay, when this cost is multiplied over three or five or seven phases (not counting upgrades), cost adds up fast. With a descriptive approach, be prepared to spend a significant amount (although still less than an ERP implementation) on a roadmap that spans the entire product lifecycle. This is not necessarily bad as long as we can prove–at every step–that PLM makes more money and provides more value to the business than it costs.
The second approach is a prescriptive methodology. With a prescriptive methodology, you lean entirely on the vendor and implementation partner to bring leading practice approaches for a specific industry. Note that this is not the same thing as out-of-the-box, which may not be based on leading practices as much as one would hope. With a prescriptive approach, the team supplies basic setup information that is unique to the business (e.g. lists of sites and users), but has almost no say in the functionality, business process or data structures. If done well, this approach can be very quick to implement and cost a fraction of the price.
These two approaches represent the extremes on a spectrum and both can be perfectly valid for some companies. Most companies should select a middle ground along this spectrum that best fits the organization. Discuss this heavily with your implementation team or partner. It’s also important to be realistic about where you are on this spectrum. Many companies make the mistake of saying “we want leading practices,” but then are unwilling to change processes (or undertake the organizational change) required to implement them, leading to significant cost overruns.
Three Characteristics of a Successful Implementation Methodology
Regardless of the chosen approach, the methodology should have at least the following three characteristics:
It should be holistic (People, Process, Tools): People (often executives) make the mistake of thinking of PLM as a technology project. PLM should be a practice and a way of thinking. This means we not only need to put in technology, but we need to think about the organization and the processes. We have all heard the mantra “don’t implement a bad process.” The methodology should be designed to cover all three of these components, ideally with entire swim lanes dedicated to each.
It should be quality-focused: When implementing PLM, I find the V model to be a very reliable approach for driving quality. With a V model, we build a series of documentation that ties together with a trace matrix. The V model helps link business needs to technical solutions by establishing a firm set of unambiguous requirements and use cases, and assures high quality with multiple types of testing (verification, validation and user acceptance). The trace matrix ensures that all requirements are covered as use and test cases, and that the system has been validated. Finally, the PLM solution provides reports to illustrate the actual cost savings and incremental revenue, so we know if the results from PLM outweigh the cost to build it. In the descriptive model, much of this documentation is built during the implementation, and in the prescriptive model, much of it is templated ahead of time.
It would probably require a white paper to describe all of the components, but the essential elements of a V model are shown in the figure below.
It should embrace uncertainty: I have said it before in this series and I will say it again: while the benefits of PLM can be very high, implementing PLM correctly can be really hard! The design is rarely right the first time, especially with a descriptive methodology. Therefore, it’s essential to build in system reviews (often referred to as conference room pilots) throughout a project. This gives the users a chance to walk through the system (often following a script based on use cases), and these sessions can last hours or even days if done well. Users should be quizzed and challenged for their insights, and discussion should be encouraged.
After each review, the team should be allowed to make adjustments to the requirements. The first session will allow for the most change and then the amount of changes allowed can be tapered at subsequent sessions. The number of review sessions needed to be effective will vary widely depending on the complexity of the organization and project phase, but three review sessions is a good rule of thumb, especially if the PLM strategy has been developed with well balanced phases.
Dave lives in Ponte Vedra, FL and when not traveling the globe can usually be found out on the water, at the gym, playing board games, spending time with family or trying new recipes with his instant pot.