Get Savvy about PLM

December 18, 2006

Failed PLM Deployments - Part 3

Filed under: Lessons Learned, Success or Failure: Lessons Learned — Laila Hirr @ 12:25 pm

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

Blog at WordPress.com.