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

November 2, 2006

Failed PLM Deployments - Part 1

Filed under: Lessons Learned — Laila Hirr @ 10:06 pm

The unfortunate reality is that some deployments fail, and they predictably fail.  I will share some case studies of deployments we’ve seen fail and the top reasons why.

Danger #1 -  Bypassing the Discovery/Feasibility Phase

At Company A we were contracted to assist with the requirements gathering and initial qualification list of PLM suppliers.  The company was bracing for major outsourcing, trying to address RoHS issues, and living with an older PDM system that was sorely in need of updating.  They had extensive workarounds to having limited workflows and had a strong need to leverage product change management with their supply chain.  They had a clear and sound business case for investing in the next generation of PLM systems and wanted to do their due diligence in assessing candidate applications.  They contracted with us to conduct the Discovery phase of their PLM initiative.  We met with stakeholders from each department, gathering requirements and developing a prioritized list of feature/functions that they would need and the business benefits to be gained from each level of capability and based upon that list began culling the list of 7 PLM providers down to a target list of three who would then have to provide a full capability evaluation to be considered as potential solutions.  This was all consistant with Company A’s IT project management directives. 

The problem arose when the internal program manager decided he needed an exit strategy - he was preparing to leave the company and did not want to leave an “open” ended status on the selection process.  Upon learning that 2 of the 7 PLM solutions had been disqualified based upon early assessment of the capabilities compared to requirements - he convinced his management that a straight upgrade of the existing PDM system was the best path and halted the discovery process and procured approvals to move forward with the upgrade, and then he left.

The problem was multifold -

  1. The end users had the perception, due to the information gathering that had taken place, that the upgrade was a “qualified” selection.
  2. The upgrade would not have passed the qualification process based upon the requirements to demonstrate functionality - but the vendor never had to show they could do what they said they could do.
  3. The vendor would not have passed the due diligence process in that it could not provide any referenceable customers for the solutions they were offering.

In the end the deployment was considered a corporate wide failure due to lack of user acceptance and due to the “bugginess” of the upgraded offering.

At Company B we were contracted to assess the feasibility of using their existing ERP system which boasted workflows and document management as a change control tool.  We evaluated the business processes and regulations that the company had to adhere to along with accepted change management processes.  We also delved into the actual functionality of the ERP system’s solution by building a sandbox to test various concepts considered to be core to change management workflows.  This took several weeks - by which time the Director of Engineering began pressing for the “ECO” design that would be implemented with the system.  We paused and pushed back - reminding him that we were still in the feasibility phase and that any process design would be premature if developed without understanding what the tool could or could not do.  He agreed to wait, very wisely too.  Less than a week later it was evident to every member of the company team assigned to champion the effort that the ERP system would fail as a long term solution for change management and a new path was quickly taken with full executive management support.

In the second case - dispite the eagerness for a rapid solution, waiting and commiting to the feasibility process saved this company years of potential struggles. 

Copyright 2006, LR Hirr, All Rights Reserved

Blog at WordPress.com.