Get Savvy about PLM

Danger #3 - Stopping at end of Phase 1

Time and time again I see the same thing happen on deployments.  The beauty of PLM is that the benefits begin almost as soon as the initial installation and configuration is done (many midsized companies can have a live system in 1-3 months) unlike ERP deployments which at best will take 6 months and often over a year to implement.  The danger of PLM is that when the initial system is deployed the project is “stopped” because it’s implemented - but the true power has not even yet been touched.  Here are some real cases I’ve encountered:

Company A:

Using Agile 6.5 the company had determined that they needed to upgrade to Agile 9.X in order to extend change management to their outsourced partners.  The analysis of the business benefit showed that the straight upgrade would only meet 50% of their system requirements and that by leveraging the newer features (which required continued process changes and configuration changes) they could obtain over 95% of their business system requirements with the newer release.  The project was laid out in 4 phases in order to manage the business impact on the company as a whole rather than try a big bang approach.  Phase 2 would meet another 30% of the requirements, Phase 3 would meet about another 15% and a final 10% of the requirements would be met by Phase 4.  Each phase was shorter in project demands and lower in cost - and the original executive approval was based upon these findings, but each phase was to be funded as each phase was started.  But as feared - phase 1 was completed and the “urgency” of the remaining 45% of the business benefits was lost - the momentum dried up and the remaining phases were not pursued.  Overall the users had a perception that the tool never met their expectations as it was never fully deployed.

Company B:

This company deployed MatrixOne as an engineering department change management tool yet did not pursue leveraging it as a enterprise product information management system.  As a result when discussing product change management with the manufacturing organization, the perception was that they had only manual change processes because the tool was not extended across the enterprise but was only deployed as a departmental solution.  Engineering would toss a bill of materials to production and it would no longer be managed within the enterprise level vault that the company owned.

Copyright 2006, LR Hirr, All Rights Reserved

My apologies for the lapse resulting in no update last week.  To continue our case studies on failed deployments - note these are not listed in any ranked order. 

Danger #2 - Lacking top leadership

This is a common issue for all major systems implementations, however tends to plague PLM deployments more than the typical ERP or CRM deployments.  Why is that?  Often because the executives have failed to acknowledge that PLM is an enterprise issue and relegate it to being an “engineering” system.  I’ve mentioned before having a CIO refer to the corporate PLM system as E-PDM, the irony of it is that while he was touting the success of his ERP implementation, he didn’t seem to know how unsuccessful the PLM deployment was.  The exact same company was struggling to deal with change management and keeping information current between engineering and manufacturing, yet they had a system in place - the problem was the system was viewed only as an engineering vault. No one had ever considered that it would assist them in resolving change control for their product structures yet they had an E-class PLM system.  Was this unusual? Unfortunately no.  The roots of a successful or failing PLM system go hand in hand with the level of executive involvement.  The successful deployments have active engagement of the executive management and a program manager that reports to the top.

PLM systems serve the enterprise.  If in doubt go back to the article I posted on where product information is used.  And dispite the fact that most change management occurs within a document control department - having the document control department lead the charge on PLM deployments is the second most common error I’ve seen in setting the direction.  Document control departments do what they do VERY well, manage the details and painstaking processes required to manage change - the department function does not lend itself well to enterprise visioning, nor to being able to step back from the tree to see the forest.

The reality is that there needs to be top level regular visibility of the PLM deployment (not once per quarter, but more like weekly or at worst twice a month) that is clear to the entire enterprise.  I heard a CIO say recently that for a enterprise deployment he was involved in - he crafted every memo that went out to the organization regarding the status and progress, he attended the planning meetings, he championed at the executive table, for the duration of the deployment - he had a program manager yes - but he OWNED the communication to the corporation and he owned the success or failure - which guarenteed the success.  To expect a program manager at any level to gain the buy in of the company without that level of executive commitment will not succeed. 

Copyright 2006, LR Hirr, All Rights Reserved