Get Savvy about PLM

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

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