Keywords

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,2,3,4,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. 1.

    PLM Challenges for SME.

  2. 2.

    PLM implementation guidelines.

  3. 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, Sect. 4.

Fig. 1.
figure 1

Relevant SME specific PLM challenges, occurrence in 9 cases. The number between parentheses indicates the number of papers that identified the challenge [13].

Full size image

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, Sect. 4.

Fig. 2.
figure 2

Executed guideline steps, occurrence in 9 cases.

Full size image

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.

Table 1. PLM goal examples
Full size table

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.

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. 1.

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

  2. 2.

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

  3. 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 2. Interview questions
Full size 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 3. Characteristics of the investigated project cases.
Full size table

4.1 Goals

The project managers have named goals for the projects. We have categorized them into the goal types, identified in Sect. 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.

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. Figure 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 h (P2) to 800 h (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.

Fig. 3.
figure 3

Relative deviation of project effort and duration. (Color figure online)

Full size image

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.