Product Lifecycle Management (PLM) implementations are often difficult to justify as their business cases are typically complex, long time driven; it is not straightforward to get them approved by the board as they don’t see short term return of investment and are more focused on manufacturing realization. They aim at enabling new business capabilities or delivering business improvements, and will usually be implemented as part of business change initiatives (people, process, and tool—ref. the “golden triangle” of change).
PLM implementation failures are typically characterized by one or more of the following root-cause factors:
- Lack of business engagement: most issues come from people’s false expectations(e.g. “everything will be fully integrated”, “it will all work first time”, “all legacy data will be migrated overnight”, etc.). Other issues arise from challenging stakeholder change management (e.g., business champions changing halfway through a PLM project, limited ongoing engagement and communication with key users, limited scalability analysis, not clear or not consistent critical success factors (how to define success) and key performance indicators (how to measure success), lack of quick-win identification (…). Engaging with the various functions is important to break silos and cross-feed, rationalise / consolidate and validate requirements across department, centres of competencies, product lines and platforms, etc.
- Unclear Return of Investment (ROI), and / or lack of business benefit tracking and (evidence of) realization, lack of business case maintenance during and after the PLM project implementation—leading to lack of focus, limited understanding of end-to-end PLM, lack of management commitment (organizational and budget-wise).
- Tool / process misalignment: tool best practices not understood, business not willing to change legacy processes, tool not fit-for-purpose, false expectations, functionality novelty vs stability and scalability, etc.
- Poor project management and poor or lack of planning: limited or poor recovery and mitigation planning, poor transition and deployment planning; focus on TO BE solution, hoping that “somebody in IT will get the data migration and integration right without any detailed requirements”; minimizing deployment delays due to technical readiness issues, lack of business validation (…).
- Contradicting requirements, lack of detailed requirements, lack of prioritisation(core vs non core, must vs want vs nice to have), limited or biased change control, lack of assumption validation across functional business silos and across technical domains, limited adoption of OOTB capability (over-customisation or lack of impact analysis of customisation on performance). Some of these issues can be due to the lack of business or technical understanding or business analysts and lack of leadership of business architects; other challenges include too much blue sky thinking process mapping (not be achievable with current tools and technologies unless heavy customisation is implemented).
- Adoption and cultural issues (change readiness issue, business prioritisation issue, organisational alignment issue, new solution, education issue, etc.).
- Subsequent high maintenance costs, potentially coupled with lack of after-service support (e.g. due to too complex and over-customised solution, chaotic integration, lack of master data management, not the right IT or PLM controls, etc.). This is typical when business as usual solution are managed by IT suppliers with no or limited PLM knowledge as they focus on middle-ware and infrastructure maintenance, not on process improvement, user training, etc. In addition, hand-over efforts to business-as-usual operations are often greatly under-estimated due to the lack of agility…
What are your thoughts?
This post was originally published on LinkedIn on 15 March 2015.
Views: 1
About the Author
