Ideal PLM and Failures

This blog post is promoted by a LinkedIn post:
https://www.linkedin.com/posts/alindenthal_engineers-give-up-plm-plm-systems-have-activity-7337209561826660352-Yi2X/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAJVUn4BzjTVfTnHgKx3zQWTPI5tYcYTiCM

What Is an Ideal PLM System Supposed to Do?

An ideal Product Lifecycle Management (PLM) system is designed to serve as the digital backbone for managing a product’s entire lifecycle—from concept and design through manufacturing, service, and end-of-life. At its core, a PLM system should:

  • Centralize Product Data: Store and manage all product-related information (CAD files, BOMs, requirements, documents) in a single, authoritative repository.
  • Enable Collaboration: Facilitate seamless communication and collaboration across engineering, manufacturing, quality, procurement, and service teams.
  • Support Change Management: Provide robust tools for managing engineering changes, approvals, and traceability.
  • Ensure Compliance and Quality: Help organizations meet regulatory requirements and maintain product quality through controlled processes and documentation.
  • Integrate with Other Enterprise Systems: Connect with ERP, MES, CRM, and other business systems to ensure data consistency and process continuity.
  • Drive Innovation and Speed to Market: Streamline workflows, reduce errors, and accelerate product development cycles.

In short, an effective PLM implementation should be the single source of truth for product data and processes, driving efficiency, reducing risk, and supporting business growth. [1]

 

Top Reasons PLM Implementation Fails

Despite the promise of PLM, many organizations struggle with PLM implementation failures. Here are the most common pitfalls:

  • Lack of Executive Sponsorship and Clear Vision

Without strong leadership and a clear vision, PLM projects quickly lose momentum. Stakeholders may not understand the value, leading to poor adoption and underfunded initiatives. It is essential to spend insufficient time articulating immediate and long-term goals and getting team engagement.  We are a fan of developing common mental models (Senge) between the executives and leadership and those doing the work.

    • Sub-optimisation of the work process
    • Conflicting focus or objective- organization politics motivated
    • Nebulous definition of success (not in terms of tangible capabilities and performance), Ill-defined metrics
    • Poorly funded training
    • A discrepancy between the talk about the use of the PLM tool and the walk. Abandoning the principles in times of duress.
  • Poor Change Management

PLM implementation often requires significant changes to established processes. User resistance, lack of training, and insufficient communication can derail the best-designed systems.  How do we transition from the present systems and work with this new system?

    • No plan for transitioning (increment) from the present PLM system to the new PLM
    • No monitoring or plan for the identification of alterations needed to the new PLM system as it goes live
    • Insufficient or unidentified talent support for alterations
    • Insufficient training on new processes and how to use the new PLM tool
  • Over-Complexity and Customization

Customizing PLM software to fit every legacy process leads to bloated, difficult-to-maintain systems. Excessive complexity increases costs and reduces user satisfaction.  This is as much a problem when we try to achieve the PLM functions in multiple products, where data from one system must be submitted to the next system.  Any new PLM system we have should be one without these limitations, essentially providing insights into the entire pipeline of product development, growth, and variations.

    • Process misalignment between the optimized and actual work process
    • A hyperfocus on making a tool meet our present way of working, rather than a critique of the present workflow, selecting, and modifying the tool.
    • Stapling disparate systems together – make it work – rather than design a system that works (from experience $ related)
  • Failure to Integrate Disparate Systems

Many companies rely on a patchwork of legacy tools—spreadsheets, shared drives, email, and homegrown databases—as makeshift PLM systems. This results in data silos, version confusion, and manual rework. PLM implementation failures often stem from an inability to unify these disparate systems into a cohesive platform.

    • Glomming or cobbling together disparate systems in an attempt to keep costs down
    • When a multiplicity of systems is necessary, poor articulation
    • Missing areas of responsibility and skill (also tribal knowledge) for the integration in the setup
    • Lack of understanding of the range of product management (for example, CM, Testing, and Requirements Management) needs for successful product development
  • Inadequate Data Migration and Cleansing

Migrating poor-quality, incomplete, or inconsistent data into a new PLM system can cripple its effectiveness from day one. Clean, structured data is essential for a successful PLM implementation.

    • Poor understanding and application of existing data
    • Existing data has defects, but nobody knows
    • Validity or veracity unknown – the appearance of following a process with metrics when the metrics collected are not from a prescribed method.
  • Underestimating the Cultural Shift

PLM is not just a technology project—it’s a business transformation. Organizations that treat PLM as an IT deployment rather than a change in how work gets done are prone to PLM implementation failures.

    • Insufficient “inculcation” on the PLM tool usage
    • Inadequate training of team members
    • Management consistency with the use and application of the PLM tool
    • A discrepancy between the talk about the use of the PLM tool, and the walk.
  • Lack of Ongoing Support and Governance

After go-live, PLM systems require continuous improvement, user support, and governance to adapt to changing business needs. Without this, systems quickly become obsolete or ignored.

    • Lack of ongoing actions to continuously improve the PLM connection to the work
    • Poorly defined metrics and the data collection methods to drive improvement
    • Functioning as if the first incarnation of the PLM system is the silver bullet solution

Problem with Using Disparate Systems as PLM

Many organizations attempt to manage product data and processes using a combination of spreadsheets, file shares, email, and disconnected databases. While this may work in the short term, it creates major risks:

  • Data Silos: Information is scattered, making it hard to find, trust, or maintain.
  • Version Control Issues: Multiple versions of the same file lead to errors and rework.
  • Manual Processes: Lack of automation increases the risk of mistakes and slows down workflows.
  • Limited Traceability: Tracking changes, approvals, and compliance becomes nearly impossible.
  • Scalability Problems: As products and teams grow, these makeshift systems become unmanageable.

Ultimately, relying on disparate systems is a leading cause of PLM implementation failures, as it undermines the very goals of PLM—centralization, collaboration, and control.

Inclusion: Getting PLM Implementation Right

PLM implementation failures are common, but avoidable. Success requires:

  • Clear executive vision and sponsorship
  • Thoughtful change management and user engagement
  • Realistic process alignment (not over-customization)
  • Careful integration and data migration
  • Ongoing support and governance

Above all, organizations must resist the temptation of relying on disparate systems to substitute for true PLM. Only a well-implemented, integrated PLM system can deliver the promised benefits of efficiency, quality, and innovation.

 

 

 

Bibliography

[1] J. M. Quigley and K. L. Robertson, Configuration Management: Theory and Application for Engineers, Managers, and Practitioners, Boca Raton, FL: CRC Press, 2020.
[2] J. M. Q. S. P. Q. Quigley, Continuous and Embedded Learning for Organizations, Boca Raton: Taylor and Francis, 2022.
[3] K. Pries and J. M. Quigley, “Project Management of Complex and Embedded Systems, Ensuring Product Integrity and Program Quality,” Boca Raton, CRC Press, 2008, p. 256.
[4] K. Pries and J. M. Quigley, Total Quality Management for Project Management, Boca Raton: CRC Press, 2012.
[5] K. Pries and J. M. Quigley, “Reducing Process Costs with Lean, Six Sigma, and Value Engineering Techniques,” CRC Press, Boca Raton, 2013.
[6] K. H. Pries and J. M. Quigley, Testing Complex and Embedded Systems, Boca Raton, FL: CRC Press, Taylor & Francis Group, 2011.
[7] J. M. Quigley, “Dictionary of Testing, Verification and Validation,” SAE Publishing, Warrendale, PA, 2024.
[8] J. M. Quigley and R. Shenoy, Project Management for Automotive Engineers: A Field Guild, Warrendale, PA: SAE Publishing, 2016.

 

For more informationcontact us:

The Value Transformation LLC store.

Follow us on social media at:

Amazon Author Central https://www.amazon.com/-/e/B002A56N5E

Follow us on LinkedIn: https://www.linkedin.com/in/jonmquigley/

https://www.linkedin.com/company/value-transformation-llc

Follow us on Google Scholar: https://scholar.google.com/citations?user=dAApL1kAAAAJ 

Post by Jon Quigley