Next Article in Journal
The Impact of CSR on Sustainable Innovation Ambidexterity: The Mediating Role of Sustainable Supply Chain Management and Second-Order Social Capital
Previous Article in Journal
The Lived Experience of Residents in an Emerging Master-Planned Community
Previous Article in Special Issue
Sustainability in Construction Projects: A Systematic Literature Review
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

A New Product Development Model for SMEs: Introducing Agility to the Plan-Driven Concurrent Product Development Approach

1
Faculty of Mechanical Engineering, University of Ljubljana, Aškerčeva cesta 6, 1000 Ljubljana, Slovenia
2
Development and Technology Department, Elvez Ltd., Ulica Antona Tomšiča 35, 1294 Višnja Gora, Slovenia
3
Ecotechnology Programme, Jozef Stefan International Postgraduate School, Jamova cesta 39, 1000 Ljubljana, Slovenia
*
Author to whom correspondence should be addressed.
Sustainability 2021, 13(21), 12159; https://doi.org/10.3390/su132112159
Submission received: 2 October 2021 / Revised: 30 October 2021 / Accepted: 1 November 2021 / Published: 4 November 2021
(This article belongs to the Special Issue Project Management and Control for Sustainability)

Abstract

:
In order to survive in today’s highly competitive global market, small and medium-sized enterprises (SMEs) have had to transition from sequential to concurrent product development, which significantly shortens development cycles, reduces costs, and ensures high product quality. Despite its many benefits, concurrent product development is still based on detailed upfront planning and cannot address the challenges related to today’s ever-growing uncertainty, constantly changing environment, and unstable requirements. A potential solution to this problem could be in more flexible and value-driven agile project management (APM) approaches, typical of software development. In this paper, we propose a new product development model specifically appropriate for SMEs that combines concurrent product development principles with APM elements. It is designed as a loop of five repetitive steps (macroplan, microplan, iteration activities, review, and retrospective) that are being executed within individual concurrent development loops. The application of the model is presented on a real case example of process development and small batch manufacture of a complex wiring harness. The study reveals many benefits of the proposed model, such as improved communication, faster detection of discrepancies, more effective problem solving, and greater flexibility. A positive impact on project success is also observed.

1. Introduction

The success of new product development (NPD) is of vital importance for the growth and prosperity of manufacturing companies [1]. Complex product demands are increasing [2] and companies must be able to produce the right products at the right time and at an affordable price; otherwise, they can quickly lose their competitive advantage [3,4]. Especially vulnerable are small and medium-sized enterprises (SMEs) that can find it difficult to compete with larger companies on a global market and are also more prone to suffer from potential losses related to unsuccessful NPD, as they have a smaller set of both financial and non-financial resources [5,6].
One of the key success factors of NPD is a selection of an appropriate project management approach [7,8]. For a long time, predictive linear approaches, such as the stage-gate model, have been used [9,10,11]. An upgrade of traditional sequential models represents the concurrent product development model [12]. In concurrent development, the development stages overlap, which facilitates collaboration and information sharing, and therefore enables more efficient product development [13].
Both traditional sequential and concurrent development approaches focus on upfront planning and control and work well in a deterministic and certain environment. In today’s highly unpredictable and constantly changing environment, however, companies need to adopt more flexible approaches. For that purpose, agile project management (APM) approaches have emerged over the last few decades. Originally developed for the software industry, APM is now being increasingly transferred also to other industry sectors due to its many benefits [14]. In recent years, various hybrid models combining traditional and APM approaches have been developed, and studies show that there are many benefits to such a combination [15,16]. However, most of the studies have been conducted in large companies [17], and there is a great concern that the existing hybrids are not appropriate for SMEs [18].
The main aim of this paper is to propose a new product development model that combines concurrent product development principles with APM elements and is specifically suitable for SMEs. The model is designed as a loop of five repetitive steps that are being continuously executed within concurrent product development loops. The use of the proposed model is shown on a real industry project, conducted in a Slovenian medium-sized manufacturing company. The study shows that there are many benefits to the proposed agile–concurrent product development model for SMEs, such as improved communication, faster detection of discrepancies, more effective problem solving, and greater flexibility. Additionally, a positive impact on project success could be observed, both in terms of project efficiency and stakeholder satisfaction.
The rest of the paper is composed as follows: Section 2 presents a literature review on concurrent product development, APM, and hybrid models. The biggest challenges of applying APM in SMEs are also presented. In Section 3, the research methodology is described. In Section 4, we describe the steps of the proposed model in detail. The model is further presented in terms of a structured project management process as an integrated part of the project execution phase. In Section 5, the use of the model is shown on a real case example of a complex wiring harness development. The main findings of the case study are presented. In Section 6, we compare the proposed model to other existing hybrids and elaborate on its main advantages and potential challenges. The paper concludes with some final remarks and directions for future research.

2. Literature Review

2.1. Concurrent Product Development

Concurrent product development first appeared in the late 1980s as an upgrade of the traditional sequential product development. It is defined as “… a systematic approach to the integrated, concurrent design of products and their related processes, including manufacturing and support. This approach is intended to cause the developers from the very outset to consider all elements of the product life cycle, from conception to disposal, including quality, cost, schedule, and user requirements” [19].
In concurrent product development, the traditionally sequential development stages overlap. For performing the interactions between the overlapping stages, the track-and-loop approach has been proposed. In the track-and-loop approach, the overlapping stages are combined into development loops; this facilitates communication and enables constant information sharing. For SMEs, Winner et al. propose the adoption of 3-T loops, which means that three consecutive stages overlap and interact [19]. The general concurrent product development process with the application of 3-T loops is shown in Figure 1 [20].
For efficient execution of development loops, good multidisciplinary teamwork is a must. According to Duhovnik et al., SMEs should adopt a two-level team structure: the core team and the project team [21]. The core team consists of the core team leader, representatives of individual functional departments, and project manager. Its composition is permanent and does not change during the project. The project team is responsible for carrying out project activities. The project manager represents a standing member of the project team, while other team members change depending on the development loop underway. With this structure, it is ensured that at each moment, the right experts from different functional departments are working on the project. Constant collaboration and information sharing between team members with different expertise allow for a better understanding of the problem and timely detection of potential discrepancies. The two-level team structure in SMEs is shown in Figure 2 [21].
The main goal of concurrent product development is achieving higher project efficiency, as customers are primarily interested in the price, quality, and functionality of the product [22]. Studies have shown that applying concurrent product development strategies (parallelism, standardization, and integration [23]), track-and-loop approach, and appropriate concurrent engineering tools (e.g., design for manufacturability (DFM), design for assembly (DFA), quality function deployment (QFD), failure mode and effects analysis (FMEA), etc. [12]) can lead to up to 60% shorter development times, up to 50% lower costs, and as much as 95% fewer errors and necessary changes [24]. Another important factor in achieving greater project efficiency is also detailed upfront planning. While in the traditional sequential product development, on average 3% of total order development time is used for planning, in concurrent product development this time increases to about 20% [25]. This enables detection and elimination of discrepancies early on when the implementation of potential changes is easier and less expensive [26].
Although concurrent product development, based on detailed upfront planning, enables greater project efficiency in rather stable project environments, it does not offer the necessary means to address the challenges of today’s turbulent environment. Companies are becoming more and more aware that they need to upgrade their standard development approach with appropriate principles that will introduce greater flexibility and enable a more rapid and effective response to change.

2.2. Agile Project Management

APM approach first emerged in the software industry as an alternative to traditional deterministic approaches that no longer allowed for effective development in highly unpredictable and competitive environments [27]. It became widely popular with the release of the Agile Manifesto in 2001, where 17 prominent practitioners presented better ways of developing software. Through their work, they have come to value (1) individuals and interactions over processes and tools; (2) working software over comprehensive documentation; (3) customer collaboration over contract negotiation; (4) responding to change over following a plan [28]. The main goal of APM is to ensure greater flexibility and faster response to change by reducing documentation and minimizing upfront planning [29]. The main differences between traditional and agile project management approaches are presented in Table 1.
Definitions of APM still differ, however, in general, it can be defined as “… an approach that seeks flexibility, simplicity, iterations in short period of time, and incrementally add value” [30]. In APM, the whole development process is partitioned into short iterations, and after each iteration, a working, potentially marketable partial product is delivered to the customer. The customer, who is actively involved in the development process, tests the product increments and constantly provides feedback information. This allows for faster identification of discrepancies, rapid response to change, and development of the product that the customer wants and needs.
For achieving greater project agility, many practices have proven to be very beneficial and are nowadays frequently used for managing complex software projects. Some of the most popular APM practices are listed and briefly described in Table 2.
Based on the APM best practices, many different structured agile methods have been developed over the years. All of the existing methods are based on iterative and incremental development, collaboration, simplicity, and adaptability [31] but differ in their depth of guidance and breadth of their life cycles [32]. Among the most popular APM methods are scrum, kanban, scrumban, extreme programming (XP), feature-driven development (FDD), dynamic system development method (DSDM), crystal methods, etc. [32,33,34].
The benefits of APM methods, which are nowadays considered to be the mainstream in software development [27], are numerous: more effective and rapid response to change, timely identification of errors, greater flexibility, improvements in teamwork, greater transparency, etc. [35,36]. Consequently, APM has started to gain recognition also outside the software industry. Due to some discipline-specific differences, a direct transfer of APM methods to other industry sectors is not possible [37], but the so-called hybrid models have started to emerge that can represent a good alternative for non-software companies [38].

2.3. Hybrid Models

Hybrid models combine agile methods with traditional product development models [15,39], thus enabling companies to take advantage of agility without sacrificing the stability provided by traditional approaches [15,16]. Many researchers agree that it is the balance between agile and traditional approaches that is usually the most effective for managing projects [29,40,41,42]. A study by Gemino et al. showed that hybrid approaches lead to higher stakeholder satisfaction than traditional approaches while allowing for a comparable project efficiency as completely agile approaches [41].
Of all the existing agile methods, scrum has the greatest potential for physical product development [43,44]. The reason for this can be found in the fact that scrum is relatively simple, direct, and well documented, compared with other agile methods. Additionally, Sommer et al. (2015) state that scrum is the only agile method that directly addresses all aspects of project management and is explicitly intended for managing projects across the development process [45]. Most often, scrum is combined with the traditional stage-gate model, which is still very frequently used in product development [9,10].
Cooper, the father of the stage-gate model, addressed a number of criticisms of this traditional model in his 2014 article [10], such as strict linearity, rigidity, inflexibility, and a high level of bureaucracy. He discussed the next generation of the stage-gate model, which needs to become more flexible, agile, and accelerated in order to be able to effectively manage innovative and dynamic projects. He also introduced the idea of a protocept, equivalent to a working product increment in agile software development. A protocept can represent anything from the initial concept to the final working prototype, something that leads us closer to the final product and enables customers to provide feedback information on [10].
Based on Cooper’s work, Sommer et al. later developed the agile–stage-gate hybrid, proposing the use of a stage-gate model on the strategic management level and scrum on the operational level [45]. The hybrid is based on the adaptation of typical scrum events (sprint planning, sprint review, sprint retrospective, daily scrum), scrum roles (scrum master, product owner, development team), and scrum artifacts (product backlog, sprint backlog, sprint increment, i.e., protocept). Case studies in various multinational corporations (Lego Group, Danfoss, Tetrapak, etc.) have shown that the implementation of the proposed hybrid leads to significant improvements, such as design flexibility, faster response to change, improved productivity, better communication, improved productivity, and raised team morale [43,46,47,48]. There have also been some attempts to implement the proposed agile–stage-gate hybrid in SMEs. The study of Edwards et al. has shown that the implementation is possible; however, it requires some additional adaptations and leads to less evident improvements [17].
Conforto and Amaral developed the IVPM2 method for managing innovative product development projects. The method combines the traditional stage-gate model approach (phase definition, standardized documentation, and checkpoints) with different scrum elements (iterative cycles, visual boards, and daily standup meetings) [42]. Research has shown that simple iterative and visual agile practices, combined with good practices of traditional product development, lead to greater creativity and innovation, greater added value for the customer, shorter planning time, and improved communication between all stakeholders [42,49].
Schuh et al. designed a customized scrum model for a highly iterative innovation process and rapid realization of physical product ideas [50]. The model is based on continuous integration of customers and production engineers and early and stepwise development of prototypes. As key enablers, integrated ICTs, interdisciplinary teams, a product lifecycle management system, and scalable manufacturing technologies are suggested. The authors also highlight the potential advantages of running individual cycles in parallel, which could further accelerate development [50].
Ullman presented an adapted scrum framework for hardware design and proposed its use in the combination with the stage-gate model [44]. In his book, he presented thirteen steps of the proposed framework that are being executed within the organize–plan–do–review cycle. Similar to the agile–stage-gate hybrid [45], Ullman’s adapted scrum framework also preserves the typical scrum events, roles, and artifacts [44].
Reichwein et al. recognized APM as a potential solution to the problems of the additive manufacturing industry. They designed additive manufacturing adapted scrum procedure that stresses the importance of frequent production of prototypes, which allows for early testing of product functionality and facilitates the introduction of changed or new requirements [51].
As a first attempt to combine scrum with a concurrent product development model, Žužek et al. presented a conceptual agile–concurrent hybrid [13]. They propose that concurrent product development framework remains unchanged (stages overlap, the track-and-loop approach is preserved, etc.), while scrum is proposed for the execution of day-to-day work. As the main advantage of the proposed hybrid, the authors stress a more comprehensive protocept that in agile–concurrent hybrid represents the result of an entire development loop, not only of one stage. This allows for a broader insight into the project progress and more extensive customer feedback.
Combining APM and concurrent product development elements has also been recognized as a promising solution for advanced mass customization and one-of-a-kind production [52]. The study of Varl et al. showed that such a combination can result in great direct savings (reduced time to market, rework, man-hours, etc.) and indirect savings (improved knowledge management, improved information flow, etc.). They have also reported increased team motivation, a lower number of changes during later phases, and enhanced effectiveness.
The results of hybrid models applied to physical product development in large organizations are very promising; however, there is a great lack of literature regarding agile and hybrid approaches in SMEs [17]. This is rather surprising, concerning SMEs account for the majority of businesses worldwide. The few existing studies indicate that the implementation of APM in SMEs is feasible but much more challenging than in larger enterprises [17,18]. Both Edwards et al. [17] and Žužek et al. [18] showed that ensuring fully dedicated team members, which represents an important element of APM, is almost impossible in SMEs. Additionally, the implementation of existing hybrids requires a complete company reorganization, which usually calls for employing agile experts [48,53]. Most SMEs usually do not have enough financial and non-financial resources to afford such an extensive transformation and therefore need an alternative approach that will still allow them to increase their agility but without such high inputs and risks related to it.

3. Research Methodology

Based on a thorough literature review and the problem stated above, we focused on the following two main research questions:
  • RQ1: How can a structured product development hybrid be designed that is specifically appropriate for SMEs and allows them to increase their agility without a complete company reorganization?
  • RQ2: Is the adoption of such a hybrid possible in a real industry environment, and are there any benefits to it?
A potential answer to the first research question (RQ1) has already been indicated by Hilt et al. [54], who found that companies can relatively easily adopt individual APM practices separately (not as a part of a structured APM method such as scrum) and combine them with traditional approaches without losing their benefits. Žužek et al. [18] further supported this statement through an in-depth case study in a Slovenian medium-sized manufacturing company, where they showed that combining APM practices with concurrent product development principles can evidently increase the level of project agility and positively impact project success. Customizing a company’s standard project management approach by implementing individual APM practices based on individual project’s characteristics instead of adopting an entire APM method has also been suggested by Brandl et al. [55] and Gabriel et al. [56].
Based on these findings and our experience in a real industry environment, we propose a new structured hybrid product development model for SMEs based on implementing individual APM elements and best practices into a standard concurrent product development approach that proved more efficient than the traditional sequential approach. We present a five-step agile–concurrent product development model for SMEs and describe each of the steps in detail. We further present the model in the context of the whole project management process, where it represents an integrated part of the project execution phase.
In order to address the second research question (RQ2), we show the use of the proposed model on a real case example of process development and small batch manufacture of a wiring harness in a Slovenian medium-sized manufacturing company. The case company is a tier 2 supplier for the automotive industry. Its development process follows the advanced product quality planning (APQP) framework and automotive standards such as IATF 16949:2016. In 2019, when the case project began, the company had 200 employees and EUR 20 million turnovers. The realization of the proposed steps and the company’s internal adaptations of the model are shown. The success of the model implementation is evaluated through the evaluation of agility level increase. Additionally, the main benefits of the proposed model are presented.

4. Agile–Concurrent Product Development Model for SMEs

The proposed agile–concurrent product development model for SMEs takes on the philosophy behind the existing hybrids (agile–stage-gate hybrid [45], IVPM2 [42], agile–concurrent hybrid [13], etc.) that preserve traditional approaches on the strategic management level while introducing agility on the execution level. The basis for the proposed model represents the concurrent track-and-loop approach that is now upgraded with an internal agile cycle (iteration) inspired by agile scrum and popular APM practices (iterative and adaptive planning, customer collaboration, protocepts, daily standup meetings, retrospectives).
The agile cycle is designed as a loop of five repetitive steps—macroplan, microplan, iteration activities, review, and retrospective (Figure 3)—that are being executed within individual concurrent product development loops. The steps of the model are similar to scrum events (i.e., sprint planning, sprint review, sprint retrospective); however, unlike in scrum, we propose that a rough macroplanning according to concurrent product development is still preserved in order to maintain a certain level of stability and predictability. Additionally, instead of scrum roles, we propose SMEs preserve a two-level team structure and a changing project team composition according to the concurrent product development loop underway. Changing team composition has proven to be a good alternative for SMEs who cannot ensure fully dedicated team members [18].
In the following, the five steps of the proposed model are described in detail.

4.1. Steps of the Agile–Concurrent Product Development Model for SMEs

4.1.1. Step 1: Macroplan

The first step of the proposed model is the macroplan generation. The macroplan represents a rough project plan, containing basic project activities and all major milestones. It is designed according to concurrent product development principles: the development stages overlap and are combined into 3-T loops (the track-and-loop approach). A two-level team structure with changing project team composition is adopted. At the beginning of the project, the project teams of individual loops are formed, and the project manager is assigned. As SMEs only rarely employ specialized project managers [57], this role is usually assigned to one of the team members.
The macroplan should be generated using appropriate project management software and a standardized template. This facilitates the initial planning process and enables automatized plan updates based on the detected changes. Having good software support is necessary when working in a multi-project environment.
After the initial macroplan is generated, the iteration duration is defined based on the complexity of the project (usually a few weeks). It is also decided if any additional APM practices will be adopted (e.g., user stories, burndown chart, etc.). The selection of APM practices depends on the capabilities of the company and the needs of the project and can be adapted with each iteration.
At the beginning of each iteration, the macroplan is updated based on the newest information. Updates have to include potential changes in the timeline and new activities related to new or changed customer requirements. Frequent updates of the macroplan provide a certain stability to the process and allow for an in-depth insight into the whole development process. Thus, it is ensured that the project team does not forget the final project goal when working on individual iteration increments.

4.1.2. Step 2: Microplan

The second step of the proposed model represents the generation of a detailed iteration microplan. The project team defines iteration requirements and the iteration protocept. A to-do list containing all priority activities necessary for achieving the set iteration goals is designed. The responsibilities are rearranged internally, based on the team members’ expertise.
For the microplan representation, a simple Gantt chart or a table can be used; however, it is encouraged to adopt visual tools typical of APM, such as a scrum table. In the scrum table, the iteration activities are organized into three groups: to do, in progress, done. The activities are moved between different groups based on the iteration progress, which allows for greater clarity and transparency.
Iterative and adaptive microplanning for one iteration upfront only introduces the much-needed flexibility to traditional project management approaches. It allows for a more rapid and effective response to changes in a project environment.

4.1.3. Step 3: Iteration Activities

Iteration activities are carried out in accordance with APM and concurrent product development principles. The project team members are constantly collaborating and sharing information. They share the responsibility for achieving iteration goals and protocept development. According to APM, it is beneficial that the project team is collocated, but the development of advanced ICTs has enabled a fast and reliable exchange of information even among distributed team members. Still, face-to-face communication and problem solving have proven to be the most effective.
In the proposed model, the team members are not fully dedicated to only one project; therefore, daily standup meetings similar to daily scrums should be introduced. Each day, all team members should gather in the same location and at the same time to quickly elaborate on project progress. Each team member answers the following three questions: What did you accomplish yesterday? What will you accomplish today? Are there any impediments in your way? Daily standup meetings should be brief, no longer than 15 min.
The result of each iteration represents the protocept, defined in the second step of the model. Depending on the loop underway, the protocept can represent anything from initial drawings, 3D models, simulations, samples, working prototypes, etc. The use of advanced modern technologies (e.g., powerful computer tools, virtual and mixed reality, 3D printing) can greatly facilitate the production of protocepts and offer the customer a more comprehensive insight into the development process and a better idea of the manifestation of the final product.

4.1.4. Step 4: Review

After each iteration, a review is carried out. The review is intended to analyze the iteration results and the protocept together with the customer. Customer reviews the protocept, tests it if necessary, and provides feedback. Constant customer collaboration allows for faster creation of final requirements and timely implementation of potential changes. It is also intended to eliminate technical discrepancies and resolve open points.

4.1.5. Step 5: Retrospective

Similar to scrum, the last step of the proposed model represents a retrospective. The retrospective is intended for the project team to evaluate the workflow and identify potential opportunities for improvements. The use of tools such as a starfish diagram (shown in Figure 3, Step 5) allows the project team to analyze good and bad practices and thus continuously upgrade the processes.

4.2. Project Management of Agile–Concurrent Product Development in SMEs

In terms of the whole project management process, the proposed model represents an integrated part of the second project management phase, i.e., the project execution phase. The whole project management process of agile–concurrent product development in SMEs is shown in Figure 4.
In the first phase (the project goal definition and planning phase), the company reviews the contract and defines key goals and strategies, the project milestones are checked, and reference projects are found. Based on the initial project definition, a rough macroplan and risk analysis are prepared that can lead to either project termination or continuation according to the following project management steps.
If it is decided to continue, the project team selects the appropriate project management approach (traditional, agile, or hybrid) based on various factors related to the characteristics of the project, the project team, and the company culture. To help with the decision, various APM suitability filters can be used (see for example Boehm and Turner’s polar chart [58] or APM suitability chart proposed in [32]). If the evaluation shows that traditional approaches are more appropriate, the project team continues with the project execution according to the standard concurrent product development model. Otherwise, the project execution phase begins based on the proposed agile–concurrent product development model.
The five steps of the proposed model are carried out within individual product development loops. Each loop is executed until all loop goals are met. The loop goals are inspected at the end of each iteration, which enables a smooth transition between the individual loops and project team compositions.
After the goals of the last loop are met, the project finalization phase begins. In the project finalization phase, course and deviation analysis is carried out, and attained goals are evaluated. The whole project documentation is stored in the project dossier that can serve as a reference for future projects. After the project dossier is archived, the project team is dissolved, and the project is completed.

5. Results

The proposed model was successfully introduced into a Slovenian medium-sized manufacturing company (described in Section 3. Research Methodology), where it proved to be easily adoptable and very beneficial. In the following, the use of the model is shown on an example of process development and small batch manufacture of a complex wiring harness for a car battery. The realization of the proposed steps and the company’s internal adaptations of the model are presented.

5.1. Use of the Proposed Model on a Case Project

5.1.1. Step 1: Macroplan

In the case company, the development process follows the advanced product quality planning (APQP) framework and is consistent with the basic concurrent product development principles. In Figure 5a, the overlapping of the stages and the formation of 3-T loops for the case project are shown. Figure 5b shows the changing project team composition according to the track-and-loop approach. The company does not employ specialized project managers; therefore, this role was assigned to the head of research and development. In Figure 5c, the initial project macroplan is shown. The macroplan was prepared using an internal template (in MS Excel), adapted to the strict standards of the automotive industry. It contains all crucial project information: project activities (start, finish, man-hours), milestones, responsibility matrix (1-3-9 method [59]), and Gantt chart.
Even though the risk analysis showed that the case project risk level was high, company management made a strategic decision of project continuation. Using the APM suitability radar chart proposed in [32] (Figure 6), the project team decided to apply the hybrid project management approach based on the proposed agile–concurrent product development model. The questionnaire used for the evaluation is provided in Appendix A (taken from [32]).
The iteration duration was set at 1 week. At the beginning of each iteration, the macroplan was updated according to the information gained in the previous cycle. In Figure 7, an example of an updated macroplan is shown. The example corresponds to the 20th iteration, which is a part of the 3rd development loop (i = 3, j = 20).

5.1.2. Step 2: Microplan

In the second step, the project team prepared a detailed iteration microplan and defined iteration protocept. In Figure 8, the microplan of the 20th iteration is shown. The microplan is presented in a form of a basic scrum table. As the protocept of the 20th iteration, the first samples of wiring harness were defined.

5.1.3. Step 3: Iteration Activities

For the execution of iteration activities, various concurrent product development principles and engineering tools were applied (CAx, 3D printing, FMEA, PDCA, lean manufacturing principles, etc.). Daily standup meetings were successfully implemented and played an important role in executing iteration activities successfully. They facilitated information sharing and improved communication between team members from different functional departments. For additional transparency, a whiteboard containing all crucial project information and open points was used (Figure 9a).
In accordance with APM, the project team focused on more incremental development and frequent value delivery. The main result of each iteration represented a predefined protocept that was delivered to the customer as a part of a weekly review. In Figure 9b, a few examples of prototypes are shown.

5.1.4. Step 4: Review

The review was carried out in a form of weekly teleconferences. Teleconferences were scheduled each week at the same time and were intended to review the results of the iteration.
In Figure 10, the results of the 20th iteration are presented. The main protocept of the 20th iteration represented the first samples of a wiring harness (Figure 10a). Based on the discussion and customer feedback, technical discrepancies were dissolved and changes to the connector cover and terminal material were proposed. Two-dimensional drawings were also changed (Figure 10b). In accordance with all new pieces of information and changes proposed, the project timeline was adjusted (Figure 10c), which also provided the basis for the macroplan update at the beginning of the following iteration.

5.1.5. Step 5: Retrospective

In the case project, the retrospectives were informal. Practices that proved to be beneficial were extensively used throughout the project (e.g., daily meetings, informal discussions, weekly macroplan updates), while some of the practices, typical of the company’s standard project management approach (lengthy meetings, detailed planning, daily changes to macroplan) were identified as unnecessary and ineffective and were therefore abandoned.

5.2. Findings of the Case Project

With the implementation of the proposed model, the case project was successfully executed. Based on the results of the case study, we came to the following conclusions:
First, the proposed model is easily adoptable even in SMEs that are just starting the agile transformation. The case company, whose standard development process follows concurrent product development principles, had no problems in upgrading it with APM elements even without lengthy training sessions and the employment of agile experts.
Second, with the implementation of the proposed model, the agility level increases significantly. The comparison of agility levels before and after the model implementation is shown in Table 3. For the evaluation, the standard questionnaire for measuring agility was applied (Appendix B; taken from [60]). The five key agility variables (customer and team integration, delivery frequency, customer validation, decision time, and project plan updating time) were evaluated by the project manager, who has years of experience in the field and, therefore, presented a reliable source of information. As proposed by the authors of the questionnaire, a six-point Likert scale was adopted for the evaluation.
Third, the combination of concurrent product development and APM principles proved to have several advantages. Concurrent product development and rough macroplanning provide for the stability of the development process, while the APM practices such as iterative and adaptive microplanning lead to a more efficient and rapid response to change and thus greater flexibility. Daily standup meetings improve communication within the team and allow for facilitated work in a multiproject environment. Reviews, frequent protocepts, and constant customer collaboration enable faster identification of discrepancies and lead to more effective problem solving. The study also confirmed that the changing team composition typical of the concurrent track-and-loop approach represents a good alternative to the fully dedicated APM teams. In combination with the daily standup meetings, it allows all team members to stay up to date with the newest information, even if they have little or no responsibility in the loop underway and have to work on other projects at the same time.
Last but not least, the results of the study indicated that implementing the proposed agile–concurrent product development model positively impacts project success. For the case project, both the project efficiency (costs, time, quality) and stakeholders’ satisfaction (company, project team, customer) exceeded the company’s expectations (a more in-depth project success evaluation for the case project is published in a separate paper [18]). Additionally, the project manager, who has years of experience with similar projects (similar in scope and complexity), stated that if the company’s standard product development approach would have been applied, the project could not have been executed as successfully.

6. Discussion

With this study, we aimed to address two main research questions. In terms of RQ1, i.e., how to design a hybrid model specifically appropriate for SMEs, we showed that a combination of concurrent product development principles and APM elements provides a valuable alternative to the existing hybrid models. We designed a structured agile–concurrent hybrid that upgrades standard concurrent track-and-loop approach with an internal five-step agile cycle inspired by scrum.
In comparison to other existing hybrid models, the main advantage of the proposed model is that it takes into account the unique characteristics of SMEs (lower financial and non-financial resources, impossible to ensure fully dedicated team members, not employing specialized project managers, etc.). It preserves the standard company organization, typical of concurrent product development in SME and therefore does not require high financial and non-financial investments related to an extensive company reorganization. In other existing hybrids, typical scrum roles and artifacts are adopted (e.g., [13,44,45]), which requires the employment of agile experts and extensive training of employees. In such hybrids, the hierarchy structures also need to be adopted, which can lead to resistance of employees and skepticism of top management [61].
Another noteworthy advantage of the proposed model is addressing the challenge of ensuring fully dedicated team members through the changing project team composition according to the concurrent development loop underway. Some other researchers have also mentioned changing team composition and part-time dedication as a potential solution [43]; however, none has explicitly addressed how and when the team composition should change and how effective information sharing can be preserved.
Furthermore, in the proposed model, agile iterations are executed within concurrent product development loops, which enables a broader insight into the project progress and timely detection of potential discrepancies between different functional departments. Similar to the agile–concurrent hybrid [13], the protocept is more comprehensive, as it combines the progress of three consecutive stages and therefore allows for more extensive feedback from the customer.
The second research question of the paper (RQ2) focused on the implementation of the proposed model in a real industry environment. The case study conducted in a Slovenian medium-sized manufacturing company showed that the implementation of the model is feasible and leads to an evident increase of agility. Additionally, a positive impact on project success was observed.
Allowing for comparable benefits with much lower investments, the proposed model proved to be more appropriate for SMEs than existing hybrids combining traditional models with scrum. Additionally, the model is widely applicable, as it enables SMEs to simply adjust the set of APM practices, iteration duration, etc. to their own needs and capabilities. Still, the proposed model is not a priori applicable for all SMEs, and some limitations and potential challenges of its implementation have to be addressed.
First, the proposed model is primarily suitable for innovative projects. In SMEs that are working on simple or routine projects, where the solutions are in a great manner known upfront, the proposed model, with its emphasis on the importance of constant customer collaboration, daily meetings, and protocept development, would not be beneficial and could hinder the development process.
Second, all stakeholders must be fully cooperative when implementing the proposed model: the management must provide full support to the project team, the project team members must be prepared to change their standard work patterns and work at a more intense pace, and the customer must be willing to be actively involved throughout the development process and constantly provide feedback. If SMEs cannot ensure the full cooperation of all stakeholders, the implementation of the model will fail.
Third, even though there is no need for extensive training, the employees should still change their mindset and be familiar with general APM concepts, practices, and tools. Some basic workshops might therefore be necessary. Additionally, it is necessary for SMEs to have appropriate resources and adopt various modern technologies (advanced computer simulations, virtual and mixed reality, 3D printing, etc.) [62]; otherwise, the incremental nature of the proposed model (frequent protocept delivery) could be very expensive and time consuming.
Last but not least, the proposed model is based on the assumption that SMEs have already transitioned from a sequential to a concurrent product development approach. SMEs that have not yet made this transition could therefore have some initial problems with the implementation of the proposed model. For those SMEs, it is suggested to first adopt concurrent product development principles (track-and-loop approach, changing team composition), and then gradually upgrade it with APM elements. The implementation process—even though much simpler than in other hybrids—still requires some caution, and in the future, this topic should be addressed in more detail.

7. Conclusions

Today’s highly competitive global market, along with its great uncertainty, has brought about a need for a new project management style. Many companies from various industry sectors have started to recognize APM as a promising new solution for managing complex projects. In the last decade, so-called hybrid models have started to emerge that combine APM approaches with traditional product development models. The results of the existing hybrid models are promising; however, they are primarily appropriate for large organizations, while there is almost no research conducted on SMEs.
In our study, we proposed a new hybrid product development model appropriate specifically for SMEs. Unlike the existing hybrids that combine sequential product development model with adapted scrum framework, we proposed that SMEs combine individual APM elements (iterations, iterative and adaptive planning, customer collaboration, protocepts, daily standup meetings, retrospectives) with concurrent product development principles (overlapping of development stages, track-and-loop approach, changing team composition). The case study in a Slovenian manufacturing SMEs showed many benefits to such a combination: improved communication both within a team and with the customer, timely identification of discrepancies, more effective problem solving, faster response to change, and greater flexibility. The results also indicated a positive impact of the model on project success.
The main contribution of the study is a new structured step-by-step development approach that allows SMEs to increase their agility without having to undergo an extensive company reorganization or having to invest in high financial and non-financial resources. It presents one of the first attempts to develop a hybrid model specifically appropriate for SMEs, and the model is widely applicable, as it can be simply adapted to the needs and capabilities of an individual company. Furthermore, in the literature, there are almost no studies addressing APM implementation in SMEs; therefore, the case study presented in this paper also provides an important contribution to this research field and can be interesting for both the researchers and the companies starting their agile transformation.
APM for non-software SMEs is still a very young and poorly researched field; therefore, future research should focus on additional case studies in different industries. Both the benefits of the proposed model and the potential implementation challenges should be researched in more detail. Additionally, the main preconditions for a successful model implementation should be analyzed (e.g., management support, motivated team members, customer willingness to actively collaborate, etc.). Further, the implementation of the proposed model was only tested for the execution of one project at a time, while other ongoing projects were executed according to the standard concurrent product development model. Implementing the proposed model for multiple projects concurrently could lead to several challenges related to intense coordination of shared resources and resources overload. Therefore, a structured implementation approach needs to be developed in the future that will enable SMEs to translate the use of the proposed model from a single project level to a multiproject environment.

Author Contributions

Conceptualization, T.Ž. and T.B.; methodology, T.Ž. and Ž.G.; validation, J.K. and T.B.; formal analysis, T.Ž.; investigation, Ž.G.; resources, Ž.G.; data curation, T.Ž. and Ž.G.; writing—original draft preparation, T.Ž.; writing—review and editing, T.Ž., Ž.G., J.K. and T.B.; visualization, T.Ž.; supervision, J.K. and T.B.; project administration, T.B.; funding acquisition, J.K. All authors have read and agreed to the published version of the manuscript.

Funding

This research was partially supported by the Ministry of Higher Education, Science, and Technology of the Republic of Slovenia, Grant Number 1000-15-0510, and by the Slovenian Research Agency, Grant Number P2-0270.

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Conflicts of Interest

The authors declare no conflict of interest.

Appendix A. APM Suitability Questionnaire (taken from [32])

Culture
  • Buy-in approach: Is there senior sponsor understanding and support for using an agile approach for this project? (Yes—1; Partial—5; No—10)
  • Trust in team: Do the stakeholders (the sponsors and the business representatives who will be working with the team) have confidence that the team can transform their vision and needs into a successful product or service, with ongoing support and feedback going both directions? (Yes—1; Probably—5; Unlikely—10)
  • Decision-making powers of the team: Will the team be given autonomy to make their own local decisions about how to undertake work? (Yes—1; Probably—5; Unlikely—10)
Team
  • Team size: What is the size of the project team? (1–9 = 1, 10–20 = 2, 21–30 = 3, 31–45 = 4, 46–60 = 5, 61–80 = 6, 81–110 = 7, 111–150 = 8, 151–200 = 9, 201+ = 10)
  • Experience levels: Do the project team members have experience in APM? (Yes—1; Partial—5; No—10)
  • Access to the customer/business: Will the team have daily access to at least one customer/business representative to ask questions and receive feedback? (Yes—1; Partial—5; No—10)
Project
  • Likelihood of change: What percentage of requirements are likely to change or be discovered on a monthly basis? (50%—1; 25%—5; 5%—10)
  • Criticality of product or service: Using an assessment that considers loss due to the possible impact of defects, what type of loss could result from a failure? (Time—1; Discretionary funds—3; Essential funds—5; Single life—7; Many lives—10)
  • Incremental delivery: Can the product be built and evaluated in portions? Additionally, will business or customer representatives be available to provide timely feedback on increments delivered? (Yes—1; Maybe/Sometimes—5; Unlikely—10)

Appendix B. Questionnaire for Measuring Agility (taken from [60])

  • Customer and team integration: The frequency of the communication (interaction) between the project team and the customer to discuss project-related topics was (1) above 6 months; (2) every 6 months; (3) bimonthly; (4) monthly; (5) biweekly; (6) weekly or daily.
  • Delivery frequency: The frequency in which the team delivered partial results to the customer was (1) above 6 months; (2) every 6 months; (3) bimonthly; (4) monthly; (5) biweekly; (6) weekly or daily.
  • Customer validation: The partial results of the project were frequently presented, discussed, and validated by the customer: (1) strongly disagree to (6) strongly agree.
  • Decision time: In case of changes in the project scope, what was the average time needed for the team to analyze information and make a decision? (1) above 30 days; (2) 15 to 30 days; (3) 8 to 14 days; (4) 4 to 7 days; (5) 1 to 3 days; (6) less than 24 h.
  • Project plan updating time: In case of changes in the project scope, what was the average time for the team to update the project plan and to communicate to all stakeholders? (1) above 30 days; (2) 15 to 30 days; (3) 8 to 14 days; (4) 4 to 7 days; (5) 1 to 3 days; (6) less than 24 h.

References

  1. Zirger, B.J.; Maidique, M.A. A Model of New Product Development: An Empirical Test. Manag. Sci. 1990, 36, 867–883. [Google Scholar] [CrossRef]
  2. Sremcev, N.; Stevanov, B.; Lazarevic, M.; Mandic, J.; Tesic, Z.; Kuzmanovic, B. Improving Process of Quotation Creation through Value Stream Mapping and Simulation. Int. J. Simul. Model. 2019, 18, 563–573. [Google Scholar] [CrossRef]
  3. Ogawa, S.; Piller, F.Z. Reducing the risks of new product development. MIT Sloan Manag. Rev. 2006, 47, 65–71. [Google Scholar]
  4. Kušar, J.; Duhovnik, J.; Grum, J.; Starbek, M. How to reduce new product development time. Robot. Comput. Manuf. 2004, 20, 1–15. [Google Scholar] [CrossRef]
  5. Verbano, C.; Venturini, K. Managing Risks in SMEs: A Literature Review and Research Agenda. J. Technol. Manag. Innov. 2013, 8, 33–34. [Google Scholar] [CrossRef]
  6. Falkner, E.M.; Hiebl, M.R.W. Risk management in SMEs: A systematic review of available evidence. J. Risk Finance 2015, 16, 122–144. [Google Scholar] [CrossRef]
  7. Cooper, R.G. The drivers of success in new-product development. Ind. Mark. Manag. 2019, 76, 36–47. [Google Scholar] [CrossRef]
  8. Pacagnella, A.C.; da Silva, S.L.; Pacífico, O.; de Arruda Ignacio, P.S.; da Silva, A.L. Critical Success Factors for Project Man-ufacturing Environments. Proj. Manag. J. 2019, 50, 243–258. [Google Scholar] [CrossRef]
  9. Ahmed-Kristensen, S.; Daalhuizen, J. Pioneering the combined use of agile and stage-gate models in new product develop-ment—Cases from the manufacturing industry. In Proceedings of the 22nd Innovation and Product Development Management Conference, Copenhagen, Denmark; 2015. [Google Scholar]
  10. Cooper, R.G. What’s Next?: After Stage-Gate. Res. Manag. 2014, 57, 20–31. [Google Scholar] [CrossRef]
  11. Brandl, F.J.; Kagerer, M.; Reinhart, G. A Hybrid Innovation Management Framework for Manufacturing—Enablers for more Agility in Plants. Procedia CIRP 2018, 72, 1154–1159. [Google Scholar] [CrossRef]
  12. Rihar, L.; Žužek, T.; Kušar, J. How to successfully introduce concurrent engineering into new product development? Concurr. Eng. 2021, 29, 87–101. [Google Scholar] [CrossRef]
  13. Žužek, T.; Kušar, J.; Rihar, L.; Berlec, T. Agile-Concurrent hybrid: A framework for concurrent product development using Scrum. Concurr. Eng. 2020, 28, 255–264. [Google Scholar] [CrossRef]
  14. Zasa, F.P.; Patrucco, A.; Pellizzoni, E. Managing the Hybrid Organization: How Can Agile and Traditional Project Management Coexist? Res. Manag. 2021, 64, 54–63. [Google Scholar]
  15. Magistretti, S.; Trabucchi, D.; Dell’Era, C.; Buganza, T. A New Path toward a Hybrid Model. Res. Manag. 2019, 62, 30–37. [Google Scholar] [CrossRef]
  16. Ciric, D.; Lalic, B.; Gracanin, D.; Palcic, I.; Zivlak, N. Agile Project Management in New Product Development and Innovation Processes: Challenges and Benefits beyond Software Domain. In Proceedings of the TEMS-ISIE 2018—1st Annual International Symposium on Innovation and Entrepreneurship of the IEEE Technology and Engineering Management Society, Beijing, China, 30 March–1 April 2018; Institute of Electrical and Electronics Engineers Inc.: Piscataway, NJ, USA, 2018. [Google Scholar]
  17. Edwards, K.; Cooper, R.G.; Vedsmand, T.; Nardelli, G. Evaluating the Agile-Stage-Gate Hybrid Model: Experiences from Three SME Manufacturing Firms. Int. J. Innov. Technol. Manag. 2019, 16, 1–31. [Google Scholar] [CrossRef]
  18. Žužek, T.; Gosar, Ž.; Kušar, J.; Berlec, T. Adopting Agile Project Management Practices in Non-Software SMEs: A Case Study of a Slovenian Medium-Sized Manufacturing Company. Sustainability 2020, 12, 9245. [Google Scholar] [CrossRef]
  19. Winner, R.I.; Pennell, J.P.; Bertrand, H.E.; Slisarczuk, M.M.G. The Role of Concurrent Engineering in Weapons System Acquisition; Institute for Defense Analyses: Alexandria, VA, USA, 1988. [Google Scholar]
  20. Duhovnik, J.; Starbek, M.; Dwivedi, S.N.; Prasad, B. Development of innovative products in a small and medium size enterprise. Int. J. Comput. Appl. Technol. 2003, 17, 187–201. [Google Scholar] [CrossRef]
  21. Duhovnik, J.; Starbek, M.; Dwivedi, S.; Prasad, B. Development of New Products in Small Companies. Concurr. Eng. 2001, 9, 191–210. [Google Scholar] [CrossRef]
  22. Grznar, P.; Gregor, M.; Gaso, M.; Gabajova, G.; Schickerle, M.; Burganova, N. Dynamic Simulation Tool for Planning and Optimisation of Supply Process. Int. J. Simul. Model. 2021, 20, 441–452. [Google Scholar] [CrossRef]
  23. Duhovnik, J.; Žargi, U.; Kušar, J.; Starbek, M. Project-driven Concurrent Product Development. Concurr. Eng. 2009, 17, 225–236. [Google Scholar] [CrossRef]
  24. Gatenby, D.A.; Lee, P.M.; Howard, R.E.; Hushyar, K.; Layendecker, R.; Wesner, J.; Layendacker, R. Concurrent Engineering: An Enabler For Fast, High-Quality Product Realization. AT T Tech. J. 1994, 73, 34–47. [Google Scholar] [CrossRef]
  25. Kušar, J.; Bradeško, L.; Duhovnik, J.; Starbek, M. Project management of product development. Strojniški Vestn. J. Mech. Eng. 2008, 54, 588–606. [Google Scholar]
  26. Kennedy, B.M.; Sobek, D.K.; Kennedy, M.N. Reducing Rework by Applying Set-Based Practices Early in the Systems Engi-neering Process. Syst. Eng. 2014, 17, 278–296. [Google Scholar] [CrossRef] [Green Version]
  27. Stavru, S. A critical examination of recent industrial surveys on agile method usage. J. Syst. Softw. 2014, 94, 87–97. [Google Scholar] [CrossRef]
  28. Beck, K.; Beedle, M.; Van Bennekum, A.; Cockburn, A.; Cunningham, W.; Fowler, M.; Grenning, J.; Highsmith, J.; Hunt, A.; Jeffries, R.; et al. Manifesto for Agile Soft-ware Development. Available online: http://agilemanifesto.org/ (accessed on 14 September 2021).
  29. Serrador, P.; Pinto, J.K. Does Agile work?—A quantitative analysis of agile project success. Int. J. Proj. Manag. 2015, 33, 1040–1051. [Google Scholar] [CrossRef]
  30. Azanha, A.; Argoud, A.R.T.T.; de Camargo Junior, J.B.; Antoniolli, P.D. Agile project management with Scrum: A case study of a Brazilian pharmaceutical company IT project. Int. J. Manag. Proj. Bus. 2017, 10, 121–142. [Google Scholar] [CrossRef]
  31. Abrahamsson, P.; Warsta, J.; Siponen, M.; Ronkainen, J. New directions on agile methods: A comparative analysis. In Proceedings of the 25th International Conference on Software Engineering, Portland, OR, USA, 3–10 May 2003; IEEE: New York, NY, USA, 2003; pp. 244–254. [Google Scholar]
  32. PMI. Agile Alliance. In Agile Practice Guide; Project Management Institute, Inc.: Newtown Square, PA, USA, 2017; ISBN 978-1-62825-199-9. [Google Scholar]
  33. Williams, L. Agile Software Development Methodologies and Practices. Adv. Comput. 2010, 80, 1–44. [Google Scholar] [CrossRef]
  34. Abrahamsson, P.; Salo, O.; Ronkainen, J.; Warsta, J. Agile Software Development Methods: Review and Analysis; VTT: Espoo, Finland, 2002. [Google Scholar]
  35. Kumar, G.; Bhatia, P.K. Impact of Agile Methodology on Software Development Process. Int. J. Comput. Technol. Electron. Eng. 2021, 2, 46–50. [Google Scholar]
  36. Thesing, T.; Feldmann, C.; Burchardt, M. Agile versus Waterfall Project Management: Decision Model for Selecting the Appropriate Approach to a Project. Procedia Comput. Sci. 2021, 181, 746–756. [Google Scholar] [CrossRef]
  37. Schuh, G.; Riesener, M.; Diels, F. Structuring highly iterative product development projects by Using HIP-indicators. In Proceedings of the 2016 IEEE International Conference on Industrial Engineering and Engineering Management (IEEM), Bali, Indonesia, 4–7 December 2016; pp. 1171–1175. [Google Scholar]
  38. Riesener, M.; Dolle, C.; Ays, J. Hybridization of Development Projects Through Process-related Combination of Agile and Plan-driven Approaches. In Proceedings of the 2018 IEEE International Conference on Industrial Engineering and Engineering Management (IEEM), Bangkok, Thailand, 16–19 December 2018; IEEE: New York, NY, USA, 2018; pp. 602–606. [Google Scholar]
  39. Papadakis, E.; Tsironis, L. Hybrid methods and practices associated with agile methods, method tailoring and delivery of projects in a non-software context. In Proceedings of the Procedia Computer Science; Elsevier B.V.: Amsterdam, The Netherlands, 2018; Volume 138, pp. 739–746. [Google Scholar]
  40. Špundak, M. Mixed Agile/Traditional Project Management Methodology—Reality or Illusion? Procedia—Soc. Behav. Sci. 2014, 119, 939–948. [Google Scholar] [CrossRef] [Green Version]
  41. Gemino, A.; Horner Reich, B.; Serrador, P.M. Agile, Traditional, and Hybrid Approaches to Project Success: Is Hybrid a Poor Second Choice? Proj. Manag. J. 2021, 52, 161–175. [Google Scholar] [CrossRef]
  42. Conforto, E.C.; Amaral, D.C. Agile project management and stage-gate model—A hybrid framework for technology-based companies. J. Eng. Technol. Manag. 2016, 40, 1–14. [Google Scholar] [CrossRef]
  43. Cooper, R.G.; Sommer, A.F. The Agile-Stage-Gate Hybrid Model: A Promising New Approach and a New Research Opportunity. J. Prod. Innov. Manag. 2016, 33, 513–526. [Google Scholar] [CrossRef]
  44. Ullman, D.G. Scrum for Hardware Design; David Ullman LLC: Independence, OR, USA, 2019. [Google Scholar]
  45. Sommer, A.F.; Hedegaard, C.; Dukovska-Popovska, I.; Steger-Jensen, K. Improved Product Development Performance through Agile/Stage-Gate Hybrids: The Next-Generation Stage-Gate Process? Res. Manag. 2015, 58, 34–45. [Google Scholar] [CrossRef] [Green Version]
  46. Cooper, R.G.; Sommer, A.F. Agile-Stage-Gate: New idea-to-launch method for manufactured new products is faster, more responsive. Ind. Mark. Manag. 2016, 59, 167–180. [Google Scholar] [CrossRef]
  47. Sommer, A.F. Agile Transformation at LEGO Group. Res. Manag. 2019, 62, 20–29. [Google Scholar] [CrossRef]
  48. Cooper, R.G.; Sommer, A.F. Agile–Stage-Gate for Manufacturers: Changing the Way New Products Are Developed. Res. Manag. 2018, 61, 17–26. [Google Scholar]
  49. Conforto, E.C.; Amaral, D.C. Evaluating an Agile Method for Planning and Controlling Innovative Projects. Proj. Manag. J. 2010, 41, 73–80. [Google Scholar] [CrossRef]
  50. Schuh, G.; Gartzen, T.; Basse, F.; Schrey, E. Enabling Radical Innovation through Highly Iterative Product Expedition in Ramp up and Demonstration Factories. Procedia CIRP 2016, 41, 620–625. [Google Scholar] [CrossRef] [Green Version]
  51. Reichwein, J.; Vogel, S.; Schork, S.; Kirchner, E. On the Applicability of Agile Development Methods to Design for Additive Manufacturing. Procedia CIRP 2020, 91, 653–658. [Google Scholar] [CrossRef]
  52. Varl, M.; Duhovnik, J.; Tavčar, J. Agile product development process transformation to support advanced one-of-a-kind manufacturing. Int. J. Comput. Integr. Manuf. 2020, 33, 590–608. [Google Scholar] [CrossRef]
  53. Sommer, A.F.; Slavensky, A.; Nguyen, V.T.; Steger-Jensen, K.; Dukovska-Popovska, I. Scrum integration in stage-gate models for collaborative product development—A case study of three industrial manufacturers. In Proceedings of the 2013 IEEE International Conference on Industrial Engineering and Engineering Management, Bangkok, Thailand, 10–13 December 2013; IEEE: New York, NY, USA, 2013; pp. 1278–1282. [Google Scholar]
  54. Hilt, M.J.; Wagner, D.; Osterlehner, V.; Kampker, A. Agile Predevelopment of Production Technologies for Electric Energy Storage Systems-A Case Study in the Automotive Industry. In Proceedings of the Procedia CIRP; Elsevier B.V.: Amsterdam, The Netherlands, 2016; Volume 50, pp. 88–93. [Google Scholar]
  55. Brandl, F.J.; Roider, N.; Hehl, M.; Reinhart, G. Selecting practices in complex technical planning projects: A pathway for tailoring agile project management into the manufacturing industry. CIRP J. Manuf. Sci. Technol. 2021, 33, 293–305. [Google Scholar] [CrossRef]
  56. Gabriel, S.; Niewoehner, N.; Asmar, L.; Kühn, A.; Dumitrescu, R. Integration of agile practices in the product development process of intelligent technical systems. Procedia CIRP 2021, 100, 427–432. [Google Scholar] [CrossRef]
  57. Turner, R.; Ledwith, A. Project Management in Small to Medium-Sized Enterprises: Fitting the Practices to the Needs of the Firm to Deliver Benefit. J. Small Bus. Manag. 2016, 56, 475–493. [Google Scholar] [CrossRef]
  58. Boehm, B.; Turner, R. Balancing Agility and Discipline. A Guide for the Perplexed; Addison-Wesley, Pearson Education, Inc.: Boston, MA, USA, 2003. [Google Scholar]
  59. Rihar, L.; Kušar, J.; Duhovnik, J.; Starbek, M. Teamwork as a Precondition for Simultaneous Product Realization. Concurr. Eng. 2010, 18, 261–273. [Google Scholar] [CrossRef]
  60. Conforto, E.C.; Amaral, D.C.; da Silva, S.L.; Di Felippo, A.; Kamikawachi, D.S.L. The agility construct on project management theory. Int. J. Proj. Manag. 2016, 34, 660–674. [Google Scholar] [CrossRef]
  61. Atzberger, A.; Paetzold, K. Current Challenges of Agile Hardware Development: What are Still the Pain Points Nowadays? In Proceedings of the Design Society: International Conference on Engineering Design, Delft, The Netherlands, 5–8 August 2019; Cambridge University Press (CUP): Cambridge, UK, 2019; Volume 1, pp. 2209–2218. [Google Scholar]
  62. Cooper, R.G. Agile–Stage-Gate Hybrids: The Next Stage for Product Development. Res. Manag. 2016, 59, 21–29. [Google Scholar]
Figure 1. General concurrent product development process with the application of 3-T loops [20].
Figure 1. General concurrent product development process with the application of 3-T loops [20].
Sustainability 13 12159 g001
Figure 2. Two-level team structure in SMEs [21].
Figure 2. Two-level team structure in SMEs [21].
Sustainability 13 12159 g002
Figure 3. Agile–concurrent product development model for SMEs.
Figure 3. Agile–concurrent product development model for SMEs.
Sustainability 13 12159 g003
Figure 4. Project management of agile–concurrent product development in SMEs.
Figure 4. Project management of agile–concurrent product development in SMEs.
Sustainability 13 12159 g004
Figure 5. (a) The overlapping of the development stages and 3-T loops formation for the case project; (b) changing team composition; (c) initial project macroplan, prepared using company’s internal project management template.
Figure 5. (a) The overlapping of the development stages and 3-T loops formation for the case project; (b) changing team composition; (c) initial project macroplan, prepared using company’s internal project management template.
Sustainability 13 12159 g005
Figure 6. APM suitability radar chart for the case project.
Figure 6. APM suitability radar chart for the case project.
Sustainability 13 12159 g006
Figure 7. Example of an updated macroplan at the start of the 20th iteration.
Figure 7. Example of an updated macroplan at the start of the 20th iteration.
Sustainability 13 12159 g007
Figure 8. Microplan of the 20th iteration.
Figure 8. Microplan of the 20th iteration.
Sustainability 13 12159 g008
Figure 9. (a) Whiteboard with the key information and open points of the project; (b) examples of protocepts (from left to right: initial 2D drawings, prototype, cross section of first samples, changes in 2D drawings, and first samples’ testing).
Figure 9. (a) Whiteboard with the key information and open points of the project; (b) examples of protocepts (from left to right: initial 2D drawings, prototype, cross section of first samples, changes in 2D drawings, and first samples’ testing).
Sustainability 13 12159 g009
Figure 10. Results of the 20th iteration: (a) protocept, i.e., first samples; (b) proposed changes; (c) timeline adjustments.
Figure 10. Results of the 20th iteration: (a) protocept, i.e., first samples; (b) proposed changes; (c) timeline adjustments.
Sustainability 13 12159 g010
Table 1. The main differences between traditional and agile project management approaches.
Table 1. The main differences between traditional and agile project management approaches.
CharacteristicTraditional Project Management ApproachAgile Project Management Approach
EnvironmentStable, predictableTurbulent, dynamic, unpredictable
Project sizeLarge projectsSmall projects
Requirements and specificationsKnown upfront, big changes not expectedRough initial definition, gradual development, in a form of user stories, changes encouraged
PlanningDetailed upfront planning for the whole projectIterative and adaptive planning, detailed planning for one iteration upfront only
Development approachSequential development stages, strictly following an initial project planShort iterations, iterative and incremental development
TeamworkLarger teams, high level of specialization, hierarchy levels, responsibilities clearly assignedSmaller teams, generalizing specialists, self-organization, full dedication, colocation, daily meetings
Management styleControl and commandLeading and cooperating
Customer collaborationInitial involvement (project definition)Active involvement in product development, frequent feedback information
CommunicationFormalInformal
Quality controlProcess-oriented, detailed planning, strict control, testing later onPeople-oriented, constant control of requirements and solutions, frequent testing
GoalsOptimization, predictabilityAdaptability, flexibility, responsiveness, quick value delivery
Project successProject triangle (time, costs, quality)Project triangle (time, costs, quality), stakeholder satisfaction
Table 2. Popular APM practices.
Table 2. Popular APM practices.
APM PracticeDescription
Iterative developmentThe whole development process is partitioned into short iterations (1–4 weeks long).
Iterative planningInstead of upfront planning, a plan is developed iteratively for one iteration upfront only.
Incremental development, frequent value deliveryEach iteration results in a working product increment customers can already use.
Time boxingThe duration of activities (meetings, iterations) is defined upfront and is fixed.
Active customer collaborationThe customer is involved in the development throughout the project and constantly provides feedback and collaborates with the project team.
Product backlogThe project is cut into small pieces that are prioritized based on customers’ business needs. Project backlog is flexible and updated frequently.
User storiesCustomer requirements and needs are provided in terms of short and simple descriptions of desired functionalities.
Small self-organized interdisciplinary teamsTeams are small (usually 7 ± 2 members), all team members are equal (no team leader), tasks are internally rearranged between team members, each team member can take on each task
ColocationAll team members are located in the same room.
Daily standup meetingsShort standup meetings (15 min) are carried out every day at the same time and in the same location where project progress is discussed.
Test-driven developmentBefore fully developing software, test cases are prepared to test new code.
Pair programmingTeam members work in pairs, one writes the code while the other supervises. Roles are frequently switched.
Burndown chartFor greater transparency, work left to do versus time is graphically represented.
SimplicityDesigning simple software is cheaper and quicker, and it allows for easier problem fixing.
Continuous integrationAll new code is first verified and then connected with the existing code.
RetrospectivesRetrospectives should be carried out frequently to analyze good and bad practices and identify possibilities of improving processes.
Table 3. Agility level before and after the implementation of the proposed agile–concurrent product development model for SMEs.
Table 3. Agility level before and after the implementation of the proposed agile–concurrent product development model for SMEs.
VariableBefore the Implementation of the Proposed ModelAfter the Implementation of the Proposed Model
Customer and team integration46
Delivery frequency35
Customer validation66
Decision time36
Project plan updating time35
Σ1928
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Share and Cite

MDPI and ACS Style

Žužek, T.; Gosar, Ž.; Kušar, J.; Berlec, T. A New Product Development Model for SMEs: Introducing Agility to the Plan-Driven Concurrent Product Development Approach. Sustainability 2021, 13, 12159. https://doi.org/10.3390/su132112159

AMA Style

Žužek T, Gosar Ž, Kušar J, Berlec T. A New Product Development Model for SMEs: Introducing Agility to the Plan-Driven Concurrent Product Development Approach. Sustainability. 2021; 13(21):12159. https://doi.org/10.3390/su132112159

Chicago/Turabian Style

Žužek, Tena, Žiga Gosar, Janez Kušar, and Tomaž Berlec. 2021. "A New Product Development Model for SMEs: Introducing Agility to the Plan-Driven Concurrent Product Development Approach" Sustainability 13, no. 21: 12159. https://doi.org/10.3390/su132112159

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop