<figure><img src="image_1.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
PLM implementation success rate in SME.
An empirical study of implementation projects,
preliminary findings.

Bas Koomen<sup>1,2[0000-0001-8253-6084]</sup> , Marko Hoogeboom<sup>2</sup>, Vera Schellens<sup>3[0000-0001-5197-8517]</sup>

¹ University of Twente, Enschede, The Netherlands

² Cadmes b.v., ‘s-Hertogenbosch, The Netherlands

³Avans University of Applied Science, Tilburg, The Netherlands

s.p.koomen@utwente.com, bas@cadmes.com

**Abstract.** Research on the implementation of Product Lifecycle Management (PLM) has been published since the beginning of the 21st century. Some researchers claim that the success rate of PLM implementation projects is below 50%, but the authors have found no evidence of that figure. In this paper’s research, a number of PLM implementation cases have been analyzed for their project goals, implementation challenges, and project results. The research data are retrieved from project files and interviews with project managers. The investigated implementation cases are in Small to Medium-sized Enterprises (SME). The results have been structured and compared with findings from the authors’ earlier literature research on SME specific implementation challenges and recommended implementation methods. From this comparison, a conclusion is drawn regarding the implementation success rate and a hypothesis for causes of observed failure.

**Keywords:** PLM, PDM, Implementation, Case Studies, SME.

# 1 Introduction

Product Lifecycle Management (PLM) is a business activity or strategy to manage products and product information across the lifecycle, from idea to disposal or recycling [1-5]. It helps to manage the increasing complexity of product structures, organizations, and processes. PLM is supported by PLM software. This software can be authoring software (for example Computer Aided Design; Computed Aided Manufacturing; Finite Element Analysis) or information system software (for example Product Data Management; Project Management).

When PLM emerged at the end of the 20th century, mainly large companies deployed PLM initiatives. Nowadays, Small and Medium-sized Enterprises (SMEs) also have an increasing need for PLM. An SME is a company with less than 250 employees and an annual turnover of less than 50 Million Euros, according to the definition of the European Union. A large part of the industry consists of SME companies. For example in
2014, 98% of companies in the machinery and equipment sector of the European Union were SME, responsible for 41% of the annual turnover [6].

A general problem with PLM implementation is that many projects fail to achieve the project goal. Some authors claims a failure rate of 50%, but no further sources are mentioned [3, 7, 8]. Moreover, industry surveys show that companies struggle to implement PLM successfully [9]. While this is a problem for large companies, it is a considerable risk for SMEs. The relative cost of a PLM implementation is higher for SMEs because the fixed part of the investment is divided over fewer people. Failure has a high relative impact on the financial health of the company [10].

To overcome implementation problems, researchers have proposed ways to model companies in a formal structure of more efficient organization and processes. For example, Bitzer [11] has reviewed and compared a number of implementation guidelines suitable for large companies. These guidelines work with organizations who already have a formal structure where current state assessment can be done successfully. Conversely, SMEs do not have formal processes, but organizations rely heavily on personal interaction. Factors such as trust, fairness, intuition, and empathy play an essential role in SMEs' business processes [12]. This makes an SME a more dynamic and agile enterprise in comparison to larger enterprises. On the other hand, knowledge management is not formalized, and most SME organizations are not able to describe their current or future state without external help, because they lack internal resources with process analysis and design skills.

From earlier research [13] we learned that case studies on the implementation of PLM at SME companies were described from a customer's perspective in most cases. We did not find papers that described cases from the perspective of a software vendor or implementation service provider.

The research question for this paper is: "Does a relation exist between the outcome of a project and the circumstances of the implementation project?" We investigated implementation cases in smaller SME companies, from the implementation service provider's perspective.

## 2 Theoretical background

Three elements are used to structure the empirical research for this paper:

1. PLM Challenges for SME.

2. PLM implementation guidelines.

3. PLM goals and benefits.

The first two elements are taken from our previous paper, [13].

### 2.1 PLM challenges

Companies face many challenges when they transform their business processes into a more PLM oriented way of working. The PLM challenges for SME, identified in our paper [13], are shown in Fig. 1, section 4.
## 2.2 PLM implementation guidelines

Researchers have proposed various methods to implement PLM in companies. We have investigated a number of these methods during the earlier literature research [13]. We derived a general PLM implementation guideline, visible in Fig. 2, section 4.

## 2.3 PLM goals and benefits

Goals for PLM are diverse. Authors have used various structures to categorize goals for PLM in their books. In Table 1, we have summarized the goal definitions found in PLM literature. We selected academic books that are frequently cited by other papers. These books contain more in-depth elaborations of goals and benefits.

In the survey results, we observed cases where the implementation of the software itself or replacement a current software was the goal of the project. This type of goals does not fit into the categories in Table 3.

<table><caption>Table 1. PLM goal examples</caption><thead><tr><th>Author</th><th>Goal categorization</th><th>Examples</th></tr></thead><tbody><tr><td rowspan="3">Feldhusen and Gebhardt [14]</td><td>Product</td><td>Make a product configurable, standardize a product family, manage variants</td></tr><tr><td>Process</td><td>Shorten time-to-market, establish unambiguous milestones, reduce the number of process steps</td></tr><tr><td>Organization</td><td>Shorten communication lines, make organization more flexible, define clear responsibilities</td></tr><tr><td rowspan="2">Arnold et al. [10] Stark [3]</td><td>Strategic</td><td>Higher customer satisfaction, increase market share, improve competitiveness.</td></tr><tr><td>Economic/operational</td><td>Information transparency, reduce rework, improve quality</td></tr><tr><td rowspan="3">Grieves [5]</td><td>External drivers</td><td>Scale, complexity, cycle times, globalization, and regulation</td></tr><tr><td>Internal drivers</td><td>Productivity, innovation, collaboration, and quality</td></tr><tr><td>Boardroom drivers</td><td>Income, revenue, and costs.</td></tr><tr><td rowspan="3">Saaksvuaori and Immonen [15]</td><td>Time</td><td>Less rework, less search time, and automation</td></tr><tr><td>Quality</td><td>Change control, documentation, standardization, and security</td></tr><tr><td>Reduce capital tie-up</td><td>Reduce the number of different and special items, reduce component stock, and manage production load with product structure information</td></tr><tr><td rowspan="3">Eigner and Stelzer [4]</td><td>Time</td><td>Reduce effort on development, search, and data exchange</td></tr><tr><td>Quality</td><td>Reduce errors and therefore warranty costs</td></tr><tr><td>Reuse</td><td>Improve search capability</td></tr><tr><td></td><td>Synergy effect</td><td>Make product and process information available and hence improve better decision making</td></tr></tbody></table>

In our research we looked for a relation between goals, impact on the company and success rate. Therefore, we organize the project goals into three categories:

1. Strategic goals, related to the future of the company and include aspects as growth, market share, competitiveness, or survival.

2. Operational goals, related to the performance of business processes. Typical aspects are cost, efficiency, quality, time-to-market, and resource capacity.

3. Functional goals, related to technical requirements. Examples are the replacement of software, consolidation of data, and protection of intellectual property. Fundamentally, there might be an underlying goal for these functional requirements, but they are not made explicit. Therefore, this category is added.
# 3 Methodology

For this research, we surveyed project managers who were involved in PLM-software implementation projects with SME companies on behalf of an implementation service provider. The surveys were conducted in live interviews. During the interviews, we also had access to project management records. In total, we collected information about 9 projects, executed between 2012 and 2019.

## 3.1 Case selection

We selected cases based on the following criteria:

- The project must be finished and executed in an SME company.

- The project must contain a strategic element, related to company processes, for example Product Data Management (PDM) or Design Automation.

- The project must impact multiple processes, not just engineering.

- The project manager and documentation must be available.

## 3.2 Interview questions

The surveys are structured to use them for comparative analysis. We used multiple-choice (M/C) questions if possible. The questions are listed in Table 2.

<table><caption>Table 2. Interview questions</caption><thead><tr><th>Topic</th><th>Questions</th><th>Q. type</th></tr></thead><tbody><tr><td rowspan="3">1. Company details</td><td>1a. Nr. of employees</td><td>M/C</td></tr><tr><td>1b. Type of industry</td><td>M/C</td></tr><tr><td>1c. Number users involved in implementation</td><td>Open</td></tr><tr><td rowspan="8">2. Goals</td><td>2a. Were goals defined before the project?</td><td>Y/N</td></tr><tr><td>2b. What were the goals?</td><td>Open</td></tr><tr><td>2c. Who defined the goals?</td><td>M/C</td></tr><tr><td>2d. Were new goals defined during the project?</td><td>Y/N</td></tr><tr><td>2e. What were the additional goals?</td><td>Open</td></tr><tr><td>2f. Who defined the additional goals?</td><td>M/C</td></tr><tr><td>2g. Were the goals achieved?</td><td>Y/N</td></tr><tr><td>3. Challenges</td><td>3a. Which PLM challenges were relevant? (list)</td><td>M/C</td></tr><tr><td rowspan="2">4. Guidelines</td><td>3b. Additional challenges identified?</td><td>Open</td></tr><tr><td>3c. Impact of the challenges on the project?</td><td>Open</td></tr><tr><td>5. Change impact</td><td>4a. Which guideline steps were relevant in the project?</td><td>M/C</td></tr><tr><td rowspan="8">6. Project performance</td><td>5a. Impact areas (IT/Process/Organization)</td><td>M/C</td></tr><tr><td>5b. Was this impact foreseen before the project?</td><td>Y/N</td></tr><tr><td>6a. Planned software investment (Euro)</td><td>Open</td></tr><tr><td>6b. Realized software investment (Euro)</td><td>Open</td></tr><tr><td>6c. Planned hours of service (Hours)</td><td>Open</td></tr><tr><td>6c. Realized hours of service (Hours)</td><td>Open</td></tr><tr><td>6e. Planned delivery time (Months)</td><td>Open</td></tr><tr><td>6f. Realized delivery time (Months)</td><td>Open</td></tr><tr><td>6g. Was the project a success?</td><td>Y/N</td></tr></tbody></table>
## 3.3 Definition of project success

We can define project success in more ways. On the one hand, we can look at a project quantitatively and measure how the project performed on time, budget and project goal achievement. From a project manager's standpoint, a project may have failed if there is a substantial budget overrun. On the other hand, we can look at the project outcome holistically: did the project leave a better world behind? A PDM project may have failed on its goals, but the company has learned more than it would have otherwise.

In our research, we primarily asked whether the project goals are achieved. We also asked for “planned delivery time and budget” versus “realized delivery time and budget” for comparison. At the end of the survey, we asked the project manager if he regarded the project to be a success as a holistic evaluation.

# 4 Results

We have investigated 9 cases with 5 different project managers. In Table 3, we have listed the case characteristics. In this section, we summarize the main results.

<table><caption>Table 3. Characteristics of the investigated project cases.</caption><thead><tr><th>ID</th><th>PrjMngr</th><th>Industry</th><th>Size</th><th>Users</th><th>Delivered</th><th>All goals achieved</th></tr></thead><tbody><tr><td>P1</td><td>M1</td><td>Machinery</td><td>100-249</td><td>25</td><td>2014</td><td>Yes</td></tr><tr><td>P2</td><td>M2</td><td>Installed Equipment</td><td>25-49</td><td>4</td><td>2018</td><td>Yes</td></tr><tr><td>P3</td><td>M1</td><td>Machinery</td><td>100-249</td><td>52</td><td>2018</td><td>No</td></tr><tr><td>P4</td><td>M3</td><td>High-Tech</td><td>100-249</td><td>50</td><td>2017</td><td>Yes</td></tr><tr><td>P5</td><td>M3</td><td>Engineering Services</td><td>100-249</td><td>25</td><td>2015</td><td>No</td></tr><tr><td>P6</td><td>M4</td><td>Machinery</td><td>100-249</td><td>65</td><td>2015</td><td>No</td></tr><tr><td>P7</td><td>M5</td><td>Machinery</td><td>50-99</td><td>50</td><td>2018</td><td>No</td></tr><tr><td>P8</td><td>M5</td><td>Machinery</td><td>50-99</td><td>14</td><td>2019</td><td>Yes</td></tr><tr><td>P9</td><td>M5</td><td>Machinery</td><td>50-99</td><td>20</td><td>2019</td><td>Yes</td></tr></tbody></table>

## 4.1 Goals

The project managers have named goals for the projects. We have categorized them into the goal types, identified in Section 2.3. Functional and operational goals were found in all cases. Only 3 cases contained strategic goals. In 5 cases, the primary goal was to replace an existing PDM system for functional reasons.

In 8 cases, the implementation service provider defined the goals, after an analysis of the customer's situation. In 3 cases, the customer (also) defined goals for the project. Furthermore, only two cases contained goals that are measurable quantitatively. In none of the cases did the customer use a third party for advice.

## 4.2 PLM Challenges

We asked the project managers for each PLM challenge in Fig. 1 to indicate if it played a role in the implementation project. The number of cases, relevant to each PLM
challenge, is shown in Fig. 1. With the color we also indicate the number of related project that failed to achieve all goals.

What stands out in this diagram is that “high cost of implement” is mentioned in only 3 cases, despite being mentioned in literature most frequently. Conversely, the project managers mention “lack of strategic business planning” in 7 cases, with only one reference from literature.

The interviewed project managers added “Lack of leadership commitment” as an additional challenge. Some projects fail to achieve goals or suffer delays, due to the low priority of the implementation project from high management.

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** Relevant SME specific PLM Challenges, occurrence in 9 cases. The number between parentheses indicates the number of papers that identified the challenge [13].</figcaption></figure>

<figure><img src="image_3.png" /><figcaption>**Fig. 2.** Executed guideline steps, occurrence in 9 cases.</figcaption></figure>
## 4.3 Implementation guidelines

We also asked the project managers, which of the steps in the general implementation guidelines were taken. The result is shown in Fig. 2. We noticed that towards the end of the implementation process, most steps were deemed as relevant in the projects. Most steps in the design and implement phases have a high relevance score. Conversely, we observe the absence of preparation and part of the analysis phase for the majority of projects. A maturity level assessment is absent in all cases, and a PLM strategy is created in only one case.

## 4.4 Project success rate

We assessed the project outcome in two questions. Firstly, if all goals were achieved. Secondly, if the project manager subjectively qualified the project as successful. In 5 cases, all goals were achieved. In 7 cases, the project manager qualified the project as successful.

## 4.5 Project plan deviation

In the survey, we captured the actual spent budget versus planned budget. In the result we observed that in all cases, the software investment was exactly or almost as planned. In contrast, we measured large deviations in the amount of effort and elapsed time from what was planned at the beginning of the projects. Fig. 3 shows a graphical representation of the relative deviation (delay) of the project duration versus relative deviation of effort (hours of external implementation services). The size of the circles indicate the amount of planned hours for the projects, ranging from 112 hours (P2) to 800 hours (P3). The projects that did not achieve all goals are marked with dashed red circles, the project with all goals achieved are marked in solid green circles.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Relative deviation of project effort and duration.</figcaption></figure>
**4.6 Limitations in this research**

With the interpretation of the results, we considered the limitations of our research method. We have in-depth access to a specific implementation service provider and all project managers it employs. Within the scope of the research it is not feasible to have the same data access with a competitive provider. This, by default, causes a bias for the specific method of implementation. We try to compensate this by interviewing as many different project managers as possible, and use cases over a longer period of time.

The answers of the project managers are subjective. Moreover, the information about the companies' goals is indirect, because it is the interpretation of the project managers. To overcome this limitation, we used cases of which project records were available. We compared the answers with the project records, together with the project managers, and clarified answers where needed. Furthermore, we used dichotomous answers (Yes or No) to avoid introduction of unjustified detail.

**5 Conclusions**

**5.1 Measurement of goals**

The operational goals, as defined in the project plans of the surveyed cases, are not measurable in most cases. They contain qualifications like “more efficient”, “fewer errors”, and “higher quality”. The surveyed project managers are aware of this weakness, but claim that the SME companies do not have enough metrics to measure improvement.

**5.2 Project failure**

Did we find evidence for the claim that 50% of the projects do not achieve their goal?

Based on the sample size and the limitations, we do not claim to have statistical proof. Nevertheless, the preliminary results are not contradicting the claim either.

More important is that our research shows the importance of goal setting. If project failure is measured as the achievement of all goals, then the definition of goals is just as important as the project outcome. More attention should be paid to help customers to define better goals, related to business strategy, and measurable.

The alternative measure for project success, where we asked the project managers for their personal opinion, shows success with 7 out of 9 cases. A conclusion could be that we need to look for another definition of project success, for example to look at the deviation from project plan and budget.

**5.3 Requirements, goals and specifications.**

An important conclusion is that the companies in the cases focus on specifications. Apparently, there is a need in the company that leads to a decision to invest in PDM. Only in 3 out of 9 cases, the customer has stated the goals for the project themselves, but in 8 cases, the implementation service provider has helped to define goals.
Moreover, the majority of goals is functional. The companies expressed their desire to improve IT-related functionality. In 5 cases, an important goal was to replace another PDM system. Additionally, we observe that companies initially desire to automate their current process with little changes.

We suspect the lacking activity during the preparation phase to be the reason for this desire. This relates to the absence of maturity level assessment, which makes companies unaware of their position relative to what could be achieved, and a lacking strategy for most cases. Furthermore, the awareness and vision steps are mostly limited to explaining how PDM benefits the organization and processes of the company, according to the explanation of the surveyed project managers. The result of this lacking preparation is that the primary goal for most projects in this survey is to deliver a particular functionality, regardless of the business value of this functionality.

## 5.4 Causality

With 9 cases surveyed, we are not able to perform a quantitative statistical analysis for causality or correlation. At first glance, the distribution of relevant PLM challenges and implementation show little apparent relation in a qualitative sense. An exception is customization of off-the-shelf functionality. Customizations cause more substantial budget overruns. 6 of 9 cases contain customization. In these cases, the number of service hours was 69% over budget. The cases without customization were only 12% over budget. The two common reasons for customization are integration to ERP and migration of legacy data.

## 5.5 Future research

We also looked for individual reasons for project failure and budget deviations. Most projects used more time and resources than planned, although the project managers have built in buffers in their project plans. The project managers believed that the initial plan was realistic before the start, so unforeseen events and circumstances must play a role in the deviations. Based on the preliminary findings of this empirical research, we plan to two direction to improve PLM implementation projects for SME.

Improve the decision making process for technical and functional solutions during the implementation: From the survey results, we conclude that project often contain loopbacks. Technical and functional problems occur in the later stages of the project, causing unplanned rework. Ward and Sobek describe this phenomenon as “wishful thinking” [16]. In their proposed method, alternative solutions for subsystems are evaluated in parallel until enough knowledge is gathered to make a confident decision. This method could also apply to PLM implementations.

Improve the goals definition for implementation projects: The project goals are important for the project. Goals are strongly related to benefits. A better understanding, and definition of benefits could improve the overall project performance.
References

1. CIMdata. About PLM. 2017 [cited 2019 January 26]; Available from: https://www.cimdata.com/en/resources/about-plm.

2. Gartner. IT Glossary - Product Lifecycle Management. 2018 [cited 2019 January 26]; Available from: https://www.gartner.com/it-glossary/product-lifecycle-management-plm.

3. Stark, J., Product lifecycle management. Volume 1, 21st century paradigm for product realisation. 2015, Springer: Cham.

4. Eigner, M. and R. Stelzer, Product Lifecycle Management; Ein Leitfaden für Product Development und Life Cycle Management [Product Lifecycle Management; a guideline for Product Development and Lifecycle Management]. 2009, Springer: Heidelberg.

5. Grieves, M., Product Lifecycle Management: Driving the Next Generation of Lean Thinking. 2005, McGraw-Hill Education: New York, NY, USA.

6. European_Commission, Key figures on European business — with a special feature on SMEs. 2011, Luxembourg: Publications Office of the European Union.

7. Wognum, P.M. and I.C. Kerssens-van Drongelen, Process and impact of product data management implementation International Journal of Product Development, 2005. 2(1): p. 5-23.

8. Siddiqui, Q.A., N.D. Burns, and C.J. Backhouse, Implementing product data management the first time International Journal of Computer Integrated Manufacturing, 2004. 17(6): p. 520-533.

9. Woo, T., Data Management in PLM: Optimize your Business Performance. 2016, AberdeenGroup: Boston, MA.

10. Arnold, V., et al., Product lifecycle management beherrschen : ein Anwenderhandbuch für den Mittelstand [Mastering Product Lifecycle Management: a User Manual for Medium Enterprises.]. 2011, Springer: Berlin ;.

11. Bitzer, M.A., Entwicklung einer Methode zur prozessorientierten Planung und Optimierung von Product-lifecycle-Management-Lösungen : am Beispiel der Automobilindustrie [Development of a Method for Process Oriented Planning and Optimization of PLM Solutions : by Example of the Automotive Industry]. 2008, TU Kaiserslautern: Kaiserslautern. p. 165.

12. Dhillon, G., B.C. Stahl, and R. Baskerville. Creativity and Intelligence in Small and Medium Sized Enterprises: The Role of Information Systems. in Information Systems – Creativity and Innovation in Small and Medium-Sized Enterprises. 2009. Berlin, Heidelberg: Springer Berlin Heidelberg.

13. Koomen, B., PLM in SME, what are we missing? an alternative view on PLM implementation for SME in 15th IFIP WG 5.1 International Conference on Product Lifecycle Management, PLM 2018, J. Rios, et al., Editors. 2018, Springer New York LLC. p. 681-691.

14. Feldhusen, J. and B. Gebhardt, Product Lifecycle Management für die Praxis : ein Leitfaden zur modularen Einführung, Umsetzung und Anwendung [Product Lifecycle Management for Practitioners: a guideline for modular implementation and application.]. 2008, Springer-Verlag: Berlin, Heidelberg.
15. Saaksvuori, A. and A. Immonen, Product Lifecycle Management. 2008, Berlin Heidelberg: Springer.

16. Ward, A.C. and D.K. Sobek II, Lean product and process development in Second edition. 2014, The Lean Enterprise Institute: Cambridge, Mass.