Following on my previous post on “why do PLM Implementation fail?“… It was noted that the very reasons why Product Life-cycle Management (PLM) implementations fail can be similar to reasons why other types of IT projects fail; this begs the following questions:
Are PLM implementations just like any other software implementations?
If so, why does the failure rate of PLM is, or seems, higher?
If PLM is indeed different, what is it that makes it different?
How can we improve its adoption rate?
Are PLM implementations just like any other software implementations?
The short answer is no. While most are IT-enabled, PLM implementations are not [only] about software or product. They are about people, process and business change. In fact, they are about business capability and efficiency improvement; some also say that PLM relates to optimization [though it is not a goal in itself to optimize something as not everything can be or even needs to be optimized].
Somehow, PLM projects are and they aren’t like other IT projects.. First, one difference is that not all PLM improvements have IT related components, they will imply cultural and organisational alignment where required; then transition and deployment usually take more time due to data and process complexity. Core IT projects typically have clearer requirements, clearer business acceptance criteria and service transition models because most issues can be addresses by IT, while business expertise is required to deploy and transition PLM implementations. PLM processes are not typically as rigid as Enterprise Resource Planning (ERP) processes hence they require more people education and acceptance…
PLM is historically rooted in Engineering (thought it is not always the case in some non-manufacturing non-industrial sectors), and Engineers typically need extra levels of engagement and adoption to make PLM projects successful. PLM data is also consumed by many enterprise cross-disciplinary functions (Engineering centres of competence, manufacturing engineering, finance, sales and marketing, senior management, procurement, supplier, partners, etc.) – hence it require complex business customer engagement across the extended enterprise, unlike any other (IT) project… For example, ERP solutions tend to be more focused in their implementation due to the transactional nature of the business functions that they enable and support.
If so, why does the failure rate of PLM is, or seems, higher?
PLM is not just like any software implementation, hence it is not relevant to compare like-for-like failure rates.
It is relevant to debate about the failure rate of small business improvement projects vs (typically large, complex) business transformation projects.
- Complex / large business projects involving people changes are more challenging than smaller business improvement or Kaizen projects.
- Complex / large PLM tool replacement implementations are also subject to higher a failure rate if the people factors, deployment transition, etc. are not considered.
It is important to clarify the PLM critical success factors (CSFs) (definition of success – hence failure) and key performance indicators (KPIs) (how performance and success or failure are measured) as, sometimes, ‘failures’ can be due to misinterpretations (ie measuring the wrong thing or not having the correct definition of success or the wrong expectations.
If PLM is indeed different, what is it that makes it different?
PLM is not a software or an IT product, it is an operating model, a concept and new way of thinking [some also say it’s a strategy] (…)
- Business improvements can encompass organisational changes, education, process improvement – and no IT involvement at all, either because the tools are already in place and require no change in a particular context, or no software is required at all in some cases.
- PLM solutions are not software, but they are typically IT-enabled. Why? Because most business processes these days are IT-enabled to gain in productivity, data security, accessibility, repeatability, etc. PLM typically depends on adoption, adaptation and augmentation of software (installation, configuration, customization, integration).
- The cost of doing nothing [carry on as current] will often outweigh the cost of change. Obviously, the cost of getting PLM wrong will always outweigh the cost of doing it right first time (…).
- PLM projects are not easy to manage: it takes significant planning and a significant investment in resources to ensure that the correct amount of due diligence is undertaken. More traditional IT projects
- Many business business improvement and efficiency projects are not necessarily called “PLM” – though, as someone from CIMdata put it to me last week: “if it looks like PLM, if it smells like PLM, it is PLM” 🙂
- The rate of change is higher with PLM projects than with typical software projects as the design phase is often a requirement discovery journey that tends to carry on during the build iterations.
- The PLM business case is not specifically difficult to create compared to other change projects – pending that an exhaustive “PLM scan” (scope / requirement identification) and roadmap (high level implementation and deployment plan and impact analysis) have been created and validated by the business. However, it is challenging to maintain it as business benefits can significantly change during the implementation. Also, benefits / ROI from PLM can take years to be realised post deployment.
How can we improve its adoption rate?
PLM adoption rate can be improved by considering the following CSFs:
- Robust and continuous business engagement;
- Continuous business benefit tracking, justification and validation (business sign-off);
- Robust continuous planning and risk mitigation;
- Detailed technical requirements cascaded from business scope and requirements – traceability and consistency of detail;
- Cultural alignment, skill alignment, consistent and relevant role-based education and training;
- Detailed implementation planning and dependency management, robust deployment planning and service operation transition (post deployment planning and support);
- If IT solutions / integrations are involved, tool / process alignment, and complexity of configuration / customization, as well as their maintainability / scalability;
- Appropriate implementation partner.
What are your thoughts?
This post was originally published on LinkedIn on 16 March 2015.
About the Author
