Keywords

1 Introduction

This paper investigates the design methodology and project organization used to design multidisciplinary products. A multidisciplinary product is defined as a product which involves different domains (e.g. mechanics, electronics, computer science, optics, chemistry, etc.). An example of a multidisciplinary product is Mechatronics, which appeared in the late 1960s in Japan, and is defined as the synergetic approach of mechanics, electronics and information technology (IT) [1, 2]. Cyber Physical Systems (CPS) are another type of multidisciplinary products. Introduced more recently in the 2000s [3], CPS can be defined as “physical and engineered systems whose operations are monitored, coordinated, controlled, and integrated by a computing and communication core” [4]. Some business sectors like the automotive or aeronautical industry have developed strong interest in CPS and Mechatronics. These developments have reached a high level of complexity driven by the perpetual growth of customers’ expectations, as these have involved diverse disciplines (e.g. mechanics, electronics, and computer science) and the incorporation of the continual technological advances in these domains to meet those expectations.

CPS and Mechatronics are two domains where the design methodologies remain discipline-dependent. This heterogeneity generally leads to poorly integrated products [5], mainly because the methods have generally been developed to address the needs of a given discipline; very and few of the existing methods were initially developed to cope with multidisciplinary approaches. In some companies, methodologies have adapted to cope with this complexity, even though most design methods were first developed for a specific domain (e.g. electronics, mechanics, or software development). Our objective is not to create a design methodology or a new organizational structure but to propose mixing some existing methods to meet specific needs. To support this mixing, an organizational model is proposed. Its aim is to promote multidisciplinary integration, leading to a better collaboration for product design. This proposition falls within the scope of Product Lifecycle Management (PLM).

PLM is an approach to support this complexity, including the design methodology and the complete product life cycle [6, 7]. PLM is defined as “the business activity of managing, in the most effective way, a company’s products all the way across their lifecycles; from the very first idea for a product all the way through until it is retired and disposed of” by [8]. PLM is thus an approach that supports the collaborative process for product development, from its first draft to the end of its life.

Several approaches are used for product development, although this paper is focused on Agile methods and project-planned (PP) methods, also called plan-driven methods. Agile methods were selected because of their growing implementation in companies which see their potential as a new approach to product development. The PP method is highlighted because of its frequent utilization in hardware (HW) product development. Agile methods arose from software (SW) development and are defined as “the ability to react rapidly to changes in the environment, whether expected or not” [9]. PP methods are a popular way of designing and manufacturing a product in hardware product development, and offers a rigorous framework to the process. These methods each have their own advantages and drawbacks. Hybrid models have also been explored [10], and this solution will be investigated further.

Moreover, in a multidisciplinary product development methodology, a domain is often dominant and its background is instilled in the design project. CPS have a SW and IT background, and Mechatronics comes from the HW side and is an evolution of electromechanics products [5]. Thus, because of CPS’ SW-oriented-background, the engineers, the design process, the design methodology, the procedures and everything in relation with the project are both IT- and SW-oriented. This particularity should be taken into account: this environment is their hallmark and changing it by massively introducing techniques from a HW development background could introduce resistance to change, as well as being incredibly difficult. Moreover, their working habits appear to be efficient and they do not have an interest in changing them.

After introducing the context, this paper focuses on different design methodologies that are able to provide a framework for multidisciplinary product development. The second section proposes an overview of Agile and PP methods and discusses a hybridization option. The third section is our proposition based on the hybridization of the Agile and the PP methods. We end with our conclusion and an overview of promising future work.

2 Agile, Project-Planned and Hybrid Methods

This section presents the Agile, PP and hybrid methods, including their advantages and their limits. In a hybrid approach, the added value expected from combining two (or more) approaches is much higher than if they were utilized separately. This is the main motivation for using hybrid methods; their practicality has already led to the exploration of their incorporation in multidisciplinary product design and especially for CPS and Mechatronics products.

2.1 Agile Methods

Agile methods, noted in plural form as there are several methods (e.g. Scrum [11], Extreme programming [12], etc.), appeared in the late 80s and at the beginning of the 90s in SW development, their adoption supported by the general dissatisfaction with the “heavyweight approaches” in use [13]. Those too-rigid methods with their heavy frameworks were perceived as inefficient and did not add any notable value. Agile methods, instead, focus more on the product rather than on how it is produced and all of the associated documentation.

In our CPS and Mechatronics context, the market, the expectations of the customers and the resulting requirements can all change quickly, and thus Agile methods would be the best option for meeting those challenges and to react efficiently to changes. The current methods can present as too rigid to deal effectively with these types of challenges.

Another advantage of Agile methods is their bottom-up approach [5]. The reverse is the top-down approach, which is used in the analysis of PP’s described in the next section. This bottom-up approach reflects how teams really work. Team members are directly linked to customers and their requirements, thus, solutions are not imposed by the head of a project and can arise from the relationships between customers and team members. This approach is, from our point of view, a bottom-up scheme. This scheme stimulates and supports creativity and new ideas, leading to innovations even at a final stage. In the current very competitive market, Agile methods and how they support innovation is a solution to make products more distinguishable. According to Highsmith: “Agile development defines […] a capability to balance flexibility and structure, a capability to draw creativity and innovation out of a development team” [14]. Thus, innovation can also be stimulated by the flexibility provided by Agile methods.

Having listed the main advantages, the Agile method’s limits are presented next. Among their limits, as highlighted in [13] and [15], is the problem of how this method can be applied to large-scale companies and projects: all the principles cannot be respected. For example, the involvement of all stakeholders is needed, especially that of major clients, and the associated communication task in large-scale projects can be insurmountable. In most cases it is understood that the customer is the final user, although in some cases, the customer can be different from the user. It is the project members’ responsibility to identify all the stakeholders and to involve them in the development process. Another point involves communication in an extended enterprise context. When a project is highly collaborative and involves many partners a strong communication network is needed. Sommerville [13] focuses on the security and safety aspects in development. This perspective is addressed in the third section. Agile methods are not yet widespread in HW domains, but some work has already been done to analyze the relationship between Agile methods and HW [16, 17]. We should note that in HW it could be more difficult to address late requirement changes. Moreover, in a HW or in a physical product development, a production line is often designed or modified concurrently. As a consequence, late changes could incur a significant cost and thus an overall view is needed to analyze the situation and make the best decision in terms of a project’s durability and return on investments (ROI). A possible solution to allow for and manage late changes without significantly affecting a project’s global cost could be to introduce modularity, as is often done in SW engineering. The product would then be developed in a modular approach and so a particular attention should be paid to the interfaces. However, if this modular approach is overdeveloped, product integration can be hindered.

Finally, in Agile methods, the focus is on the product and not on the documentation. The associated lack of documentation is rarely acceptable for a physical product [13], where it is normally required, especially in terms of maintenance. If the documentation is to provide a user guide, an exception is made by some smartphones which are delivered with no documentation because they are considered to be intuitive, however for other hi-tech or large Mechatronics and CPS products, this lack of documentation is not conceivable.

This section has presented a brief state of the art on Agile methods, their strengths and their limitations. In the next section, the PP methods are evaluated in terms of their advantages and their limits.

2.2 Project-Planned/Plan-Driven Methods

Project-planned (PP), also called Plan-driven [13] methods, were first introduced in the 1980s [18]. The philosophy of this method could appear as quite antagonist to that of Agile methods: whereas Agile methods are flexible, PP methods appear as more rigid. Another difference is that they are reference-document-based [5]. At the beginning of a project, reference documents are submitted in order to have a common objective and to position the project into a specific direction. These reference documents are built with project management references such as Product Breakdown Structure (PBS), Work Breakdown Structure (WBS), Organization Breakdown Structure (OBS) and Cost Breakdown Structure (CBS) [18]. These references are provided in order to define the hierarchical architecture of the product (with PBS), the link between the planned work and the team members (with WBS), the organizational structure of the project with the different actors (with OBS) and the cost distribution (with CBS). These references provide the rigid framework that is required in certain large-scale or medium-scale product design processes to fix a common view and objectives. PP is also based on the milestones and associated deliverables determined by project leaders in the early stages of a project. Each stage also has its own objectives in terms of costs, time and product performance. Managers measure a project’s progress by checking the deliverables’ progress. Earned value management [18] is often used to determine if a project is running late or not. In this methodology, the major decisions emerge from the head of the project, based on their application of these reference tools, and thus this method is considered to be a top-down approach [5]. Moreover, in a generic design approach, projects are based on templates to capitalize on knowledge from past projects.

After introducing the main concepts of PP, this paragraph investigates the advantages of PP’s methods. PP is mainly applied in HW product development. PP can also be applied in SW engineering for large developments, or when there are serious security, safety and reliability concerns (e.g. when developing an operating system or an embedded SW for an aircraft or in a spaceship). Sommerville [13] recommends that for “critical systems”, “embedded systems where the SW depends on HW development” or for “very large systems where development may involve teams working in different locations” PP is preferable because Agile methods cannot be fully applied. Some of the documents provided by PP have important advantages for the course of a project. For example, WBS allows task parallelization and avoids overloading team members [5]. When a strict organization is needed, with a “very detailed specification and design before moving to implementation” [13], as is the case for some Mechatronics and CPS developments, Sommerville advises using PP methods.

Having mentioned the advantages associated with PP, we address its limits. One of its limits is the development of risk management for projects to rationalize their execution [5]. This rationalization influences the stages and deliverables, which can now be standardized. Finally, it induces a highly rigid organization that impedes initiatives and innovation. When the top-down approach is over-developed, the empowerment and the decisional power of the team members and of some managers is low, which will badly impact any impetus for innovation. Moreover, the task force organization does not contribute to any significant reduction in the compartmentalization of the different disciplines. This point has an important impact in a multidisciplinary context where disciplines have to communicate to efficiently produce a highly integrated product [5]. Finally, due to compartmentalization, only a few people in a project will have a global view of a project and its problems.

After analyzing two of the main current product design methodologies, highlighting the limits and the advantages of each methodology, hybridization is discussed next.

2.3 Hybrid Methods

As presented in the previous sections, each method has its advantages and its limits. Hybridization could be a way to get more from these methods; to select the most important characteristics of each method and to merge the two together. Hybridization has already been experimented with in [10], in an association of Scrum (an Agile method) and Stage-gate methods, which are very close to PP. That study was conducted on different companies from different business sectors. They all adapted some of the principles from Scrum, although they do not have the same level of hybridization. The authors in [10] quote Ovesen’s studies on the implementation of a Scrum solution into a “traditional” organization and the analysis of the implementation of Scrum in different types of companies [19]. Ovesen observed that “all companies deploy a Stage-Gate process-control model in combination with the Scrum framework” and that “none of the seven companies comply 100% with the rules of Scrum”. This emphasizes that hybridization is tested often in companies because it can bring new elements that increase a companies’ efficiency and flexibility. This observation is also supported in [10], where the authors state “companies significantly improve product development (PD) performance after implementation [of Scrum], but the Agile framework is merged into the existing PD standards rather than replacing them.”

Based on the previous observations, the two methods appear to be antagonistic but are in fact complementary. Detecting possible model clashes and synergies is an important step to realize before building and implementing a hybrid model [15]. Boehm and Turner suggest that companies “develop management and architectural practices for hybrid agile and plan-driven methods” [15] in order to overcome the Agile methods’ barriers.

Table 1 was prepared as a means to compare and summarize these methods’ ability to deal with criteria selected to highlight the methods’ advantages and limits. Table 1 is built on the literature review exposed in previous sections. Agile and PP methods’ limits and advantages are indicated in the first two columns, and the Hybrid method’s column is filled with what is expected by merging the first two. A “++” or “+” is indicated when a method is, respectively, completely or partly suitable to a particular criteria. When the drawbacks of a method are incapacitating or cannot fulfill the criteria, a “−” is indicated.

Table 1. Agile, project-planned and hybrid methods for multidisciplinary design.
Full size table

The proposed criteria were selected to cover some of the specific aspects of project organization: a projects’ scale, type of product developed, management aspects, dealing with changes and “non-functional requirements” [13]. The financial aspects are deliberately not taken up in this study but that is envisioned for future works. The proposed model is macro-level focused, to be further detailed up to a micro level with metrics to obtain the information required for efficient project management. Large, medium and small-scale projects: a particular attention is paid to determine if a method is suitable for different project scales. A large-scale project would not be managed in the same manner as a small one. Whereas large projects need a rigid framework, a small one could be easily supported by Agile methods.

Dealing with late/unexpected changes is linked to customer involvement and meeting frequencies. Agile methods provide a framework that allows late changes to be managed, due to their significant customer involvement and daily meetings. A Hybrid approach must integrate this aspect to be able to incorporate late changes. In an industrial context customers are at the core of product design. The product must meet the customers’ needs and their expectations, which could change during the design process. Another point is that when a modification has to be made in a SW domain, it is not as expensive as a similar-scale modification in a HW domain. Late changes are always a challenge, but Agile methods cope with them efficiently in the SW domain.

Strategic-tactical-operational decision power is linked to top-down and bottom-up approaches. In a top-down approach, the strategic level has a strong decision-making power. It sets the objectives and makes most of the decisions during meetings. Technical solutions are virtually frozen and innovation does not have much opportunity to be expressed. In contrast, the bottom-up approach offers more decision-making power and initiatives to the teams members at the operational level. Due to this flexibility and decentralized decision-making power, innovation can be expressed much more easily. A significant rigidity will impede innovation and technical solutions, but is needed to set clear and common objectives. This is emphasized by Bricogne: “[PP] allows little opportunity for initiatives and innovations, it does not spur regular tradeoff between the different disciplines and is thus considered to be relatively “rigid”” [5]. However, too much flexibility and decentralized decision-making power can slow down a project.

SW/HW/Multidisciplinary development are analyzed to determine if a method can deal with SW and HW design and a combination of both.

When dealing with non-functional requirements (e.g. security, reliability), Agile methods are not the most suitable methods to use ‘as is’ [13, 15]. Instead, they would require some modification to cope with security and reliability, both of which are important in CPS and Mechatronics.

Finally, the ideal hybrid method would be where the limits of one method are counterbalanced by the advantages of the other and vice versa. Several authors share the view that hybridization can increase efficiency and is a way to implement Agile methods in a company. The observations made in this section emphasize the need to develop and implement hybrid methods in a multidisciplinary product design to take maximum advantage of Agile and PP methods. Hybridization cannot be the perfect answer to all of a project’s needs, even though it does allow Agile and PP methods to overcome their respective barriers. Our vision of Agile-PP hybridization is exposed in the next section.

3 An Organizational Model of a Hybrid Agile-PP Approach

This section presents our proposition, illustrated in Fig. 1, which is a macro-level-hybrid model. Agile and PP methods are hybridized as a way to optimize their advantages and overcome their limits.

Fig. 1.
figure 1

Macro-level-hybrid model.

Full size image

Four main areas are shown in Fig. 1: the hierarchical levels are on the left; a slider which can move towards Agile or PP methods is on the right; between the two is the core of our proposition, the hybridization between PP and Agile methods; and the PLM, which provides a global framework, is at the bottom.

Our proposition is mainly focused on utilizing both top-down and bottom-up approaches and deciding how best to combine them. This proposed model could be an answer to the development of medium- and large-scale projects by integrating Agile methods to stimulate innovation and support bottom-up initiatives to create a dynamism, and PP methods to provide a rigid framework for a common global project view.

The hierarchical levels are the strategic, tactical, and operational levels [19]. The strategic level defines the global objectives and makes the decisions that can affect a company’s longevity. This level is mainly represented by the company’s directors, which can be grouped as a steering committee who monitor a project. Project leaders can also be encountered at this level, depending on their decisional power. The tactical level is an intermediate one. This is where the “structures and resources” [19] needed to match the objectives set by the strategic level are defined here. Depending on a company’s organization, this level is represented by project leaders and/or by team leaders. Project leaders have an overview of the project and can be viewed as global project managers. Team leaders are in charge of a project team. Finally, the third level is the operational level, where the decisions are applied and which is charged with the design’s execution [19]. This hierarchical model is top-down oriented, although applying Agile methods’ principles at the operational and tactical level is expected to stimulate some bottom-up communication and to assign more decisional power to these levels. Moreover, in our multidisciplinary context, the team’s composition must be considered. Ovesen [20] proposes three types of team composition: a large and extremely cross-functional team, multiple smaller functional teams, and multiple cross-functional teams.

In addition to the hybridization at the tactical and operational levels, at the strategic level the PP method is implemented with its rigid framework. The global project is structured by project management reference documents (e.g. PBS, PDP, CBS, WBS, Gantt Planning, etc.). Moreover, in a PLM approach, our macro-task allocation would be provided by a macro-workflow. A classical workflow allocates a task to a person, whereas our vision of a macro-workflow only allocates macro-tasks to the team leaders, to give them an objective. A project’s global objectives and vision are set and shared to all of the project’s members. The aim of this top-down structure is to provide a framework to set the boundaries and offer a common vision. The long and short-term objectives and financial aspects are discussed at this level.

On the bottom of Fig. 1, at the operational level, Agile methods are preferred. These are applied to small teams to avoid large-scale problems and to respect the communication principle. In this organization, with independent small teams, the macro tasks are given by PP and the project subdivision made by PBS and WBS. Once these tasks are given by the macro-level workflow, the teams are completely independent, and an Agile method is used to manage the operational level of the project. The team leader links the team’s work with the customers’ requirements. Hence, the teams are mainly customer-focused. The teams’ tasks evolve with the evolution of the customers’ requirements. Each team is independent during the Agile process flow; system architects, helped by Software Configuration Management (SCM), check the interfaces and the impacts of changes on the different levels. This micro-level collaboration is supported by the third-party systems that manage a project’s data and that are integrated in most PLM approaches.

Moreover, simulation has to be accounted for in our context to help engineers and technicians to design efficient systems. In fact, multidisciplinary product design such as Mechatronics or CPS cannot be managed without using simulation. Products are becoming more and more complex and simulation is the best way to efficiently deal with that complexity [21]. Moreover, according to Ottino et al. [22], managing simulation data is a key factor in being competitive and reducing time-to-market. This management could be done by implementing a Simulation Lifecycle Management (SLM) approach in the macro PLM context.

Finally, because a project is often developed in a context of uncertainty, our approach is aimed at being dynamic and not static, and thus it is flexible. A slider is shown on the right side of the figure to illustrate the dynamism of the proposed approach. The slider is movable along the design process and between the stages to deal with company, team and environmental particularities. It can slide towards the Agile or PP methods, indicating the balance between bottom-up and top-down approaches as well as the balance between rigidity and flexibility, and thus how much innovation is stimulated or not.

For example, if the project deviates too much from the global direction and that is not desired, moving the slider towards PP (the global organization will be more oriented toward PP methods) to provide more rigidity and rigor in order to reframe the project could be necessary. On the contrary, if team members do not manage to circumvent a patent, or to create a technological gap to produce a major competitive advantage, moving the slider towards Agile methods could be a solution to increase flexibility and to stimulate innovation. The possibility of moving the slider aims to face the scope of possible situations that a project manager can face along the project. Maintaining an ideal balance between too much rigidity and too much flexibility is the goal. This can be done by relying on project leaders’ experience and by using metrics to adapt the balance. The balance between Agile and PP methods can be changed during the course of a project. This decision, which will impact the project, should be taken during regular meetings between the steering committee, project leaders and team managers at the strategic level.

4 Conclusion and Future Work

This paper proposes a representation of an Agile-PP-hybrid-approach. This type of hybridization has been explored by Ovesen [20] and Sommer et al. [10] and is already being tested in some companies. PP and Agile methods are two approaches that can appear to be in opposition although they are actually complementary. Agile methods bring new elements to PP and PP can provide elements to overcome the Agile methods’ limits.

Our model aims to formalize a possible hybridization between Agile and PP methods by combining the main advantages of both methods and using those to overcome their respective limits. The PP method is used to achieve a macro-rigid-framework to give a project its global direction (at the strategic level). Agile methods are used at the operational and tactical levels to provide the requisite flexibility to encourage innovation for technical solutions. The model aims to combine top-down and bottom-up approaches for multidisciplinary large- and medium-scale product development.

A project evolves in an uncertain environment, and thus our model should be dynamic. For the moment, it is the project team’s responsibility to find the right balance and to position the slider between Agile and PP approaches. A part of our future work is to refine our representation so as to focus on the micro-level project aspects by determining metrics with which to measure a project’s data. These data would be measured to facilitate the monitoring of a project in order to make suitable decisions and to even change the direction of a project as needed.

Finally, multidisciplinary product design is very specific to the interactions that can exist between the domains. Our proposition can provide a framework for multidisciplinary product design which then needs to be refined and detailed up to the micro-level. It will be interesting to observe if Mechatronics and CPS design needs to be de-coupled, and at which level of the approach the de-coupling is most likely to occur.