March 2015 Download this article as a PDFAbstract

Too many industrial projects still fail, mainly due to the managerial techniques used. Indeed, organizational processes are more or less specifically mentioned in systems engineering standards, but in practice, project managers tend to rely more on their own standards, which sometimes set forth practices that do not align with those of the systems engineering domain, hence the reported discrepancies that very often lead to project failure. Thus, we argue that, to improve the companies’ competitiveness when developing new products, cooperation between processes related to system development and project management is key to achieving performance and success. This article presents arguments that tend to support this assertion and introduces an ongoing project to develop both a method and tool that aim to integrate both domains.

Introduction

About one-fifth of the world’s GDP, or more than $12 trillion, will be spent on projects each year from 2010 to 2020 (Beer & Nohria, 2000). However, despite this heavy investment, far too many projects – up to 18%, according to the Standish Group International (2013) – will fail. Owing to a widespread lack of project management, only 20% of projects achieve the expected results in terms of quality, costs, and deadlines (Beer & Nohria, 2000). Recent studies have underscored the current partitioning between systems engineering processes and project management practices, leading to competing priorities and trade-offs throughout the course of a project.

Systems engineering and project management are two critical aspects in the success of product development projects (Benjamin et al., 2010; Conforto et al., 2013). The literature suggests that, from the very early stages of projects, the implementation of systems engineering and project management processes is crucial (Sharon et al., 2011). Indeed, developing complex systems is a highly interactive social process involving hundreds of people that have to make joint and consistent decisions (Eppinger & Salminen, 2001). In this dynamic process, product, process organization, and engineering must operate in conjunction. The aim of project management is first to define the project mission and organization, then to determine the budget and plan a schedule, and then to ensure operational control of said project through an assessment of performance by analyzing possible deviations relative to the initial schedule, and to implement corrective actions or new preventative actions if necessary to mitigate risks (Danilovic & Browning, 2007). Its role also consists of organizing and monitoring systems engineering processes.

Companies usually pay attention to these systems engineering and project management processes, but, usually separately: they do not consider connections between them. Indeed, for many years, systems engineers and project managers have thought that their work was separate, focusing more on their own domains than on the whole project (Conforto et al., 2013). However, recent studies have pointed out this unproductive compartmentalization of processes and have emphasized the need for cooperation between processes at the normative level (Pyster & Olwell, 2013).

Our research objective is thus to elaborate a method and a tool to bridge the gap between these disciplines in order to help project managers detect these inconsistencies and make joint decisions during a system development project. This objective relies on a pragmatic concern, even at the risk of possibly watering down the theoretical recommendations of standards, which is to make them applicable within the company: adapting, scaling to company size, and offering methods and support tools to prime contractors. The main targets are small and medium-sized enterprises (SMEs), for which the deployment of systems engineering processes and the management of complex systems remain practices that cannot easily be harnessed.

The article is structured as follows. First, we describe the current state of industrial practices to introduce the problem addressed and our research motivations. Then, we survey the literature for a methodological solution to align systems engineering and project management processes at the normative level. Next, we propose a method and tool aimed at supporting this alignment and decision making. Finally, we conclude by describing the benefits and future developments of this proposal.

The Need for Cooperation between Systems Engineers and Project Managers

To quickly renew their commercial offer and to reduce development delays, companies have to be proactive and anticipate changes. In the current context of global competition, they have to reduce delays and costs, and increase the offers and the quality of products and services to meet the customers’ requirements. The competitiveness of a company thus relies on its capability to master the whole product lifecycle. Consequently, most companies no longer hesitate to collaborate to launch new products on the market. In this field of extended enterprises, it becomes increasingly complex to conduct systems engineering projects given the numerous participants and stakeholders, from the conception to the retirement stage. Systems development involves organizational, financial, human decision-making, logistics, and environmental disciplines, among many others. In the case of straightforward systems engineering projects, it may be sufficient to meet the technical requirements and rely on coherent planning. But, for complex projects, companies will rely on systems engineering and project management guides that allow optimal management of the product lifecycle and the project itself: breaking down the project into tasks and processes, planning tasks and processes with an overall project plan, and monitoring all tasks and processes until the validation of the project (Lee et al., 2008).

Thus, many companies rely on standards and product lifecycle management tools to guide the industrial processes (Rachuri et al., 2008). However, systems engineering and project management standards describe what engineering "best practices", but refrain from saying how to do it. They focus on processes and activities (the "what") rather than on methods and tools (the "how"). On the other hand, according to a study by Pierre Audoin, consulting product lifecycle management tools only helps in the collaboration of technical activities (Nayagam, 2011). Thus, beyond the use of some business intelligence tools (e.g., the SQuORE platform, which is a new-generation tool for optimizing software project management), some major industrial groups develop their own tools to support the enterprise process (e.g., “Unified Planning” at AIRBUS or the “Enterprise Program” at Dassault Systems). These tools, which have been customized to support the companies’ own processes, rely on project management standards. However, these tools still do not consider project management and systems engineering processes jointly. Likewise, they do not offer decision-support mechanisms to monitor the project; it will thus be necessary to develop a tool in the near future to implement and coordinate cooperation between the processes of systems engineering and project management and help project management decisions during the systems engineering project.

Support for the importance of developing a tool to integrate the systems engineering and project management can be found in the current economic trend that aims to reduce the cost of activities. Indeed, in a study carried out by McKinsey Global Institute (2013), which ranks the 12 technologies that will most impact the economy by 2025, the "work of the automated knowledge" (e.g., management, engineering, finance) would rank second in the list; the goal would thus be to reduce expenses by about US$ 5,000 billion per annum! This study reinforces our belief that close attention has to be paid to the integration of systems engineering with project management because it is fully in line with current concerns.

Our objective is thus to provide the project manager with a standards-compliant method and tool that support cooperation between systems engineers and managers and their respective processes, to control the project and optimize cooperation between processes. To do this, a first step consists of identifying and modelling systems engineering and project management processes, and then finding the relevant indicators to monitor them. There are three goal: i) to support management by coordinating processes; ii) to offer a method to stakeholders to monitor progress at any time, and at any level, from different points of view; and iii) to provide tools to help them make decisions and explore several directions to guide the project. This tool is designed to simplify and formalize the implementation of the elementary processes proposed by the standards while using the available data, including data generated by tools supporting the business project.

Aligning Systems Engineering and Project Management at the Normative Level

In collaborative engineering, using data exchange, communication, or product lifecycle management tools is not enough to make individuals collaborate; the very notion of role must be revised, as well as processes and interactions between processes, work organization in the company, and mentalities. Business units must cooperate, and what is required is a different mindset, one that redefines professionalism as achieving the mission and having a satisfied customer or end user versus struggling to protect "turf". Systems engineers and program managers bring unique skills and experiences to the programs on which they work (Sudarsan et al., 2005). Those unique capabilities both are essential for the successful execution of the program, as are the skills and capabilities of team members from other disciplines (Langle, 2011). However, there is also a “shared space” where program managers and systems engineers collaborate to drive the program team’s performance and success. Each discipline would then benefit from an understanding of the other’s discipline.

Integrating systems engineering and project management has only been considered since the beginning of the 21th century. Sharon and colleagues (2011) put forward that system engineering management always uses some subsets of project management methods and tools. The technical activities are related to the product domain and the managerial activities are related to the project domain. However, these constitute two complementary facets of system engineering management.

In 2011 and 2012, INCOSE and PMI recognized the importance of integrating systems engineering with project management (Conforto et al., 2013). With the help of the Massachusetts Institute of Technology (MIT), they conducted a survey to better understand the responsibilities of systems engineers and project managers and thus to help organizations reduce program risk and improve their return on investment (ROI). Another objective was to better understand how project management and systems engineering were integrated within the organizations. The results highlighted how critical integration of systems engineering and project management was to alleviate unproductive tension between systems engineering and project management. A guide to help the systems engineers and project managers improve the performance of their programs was provided by Oehmen and colleagues (2012). It indicates four methods to enhance cooperation based on the analysis of several cases to better integrate project management and systems engineering: i) using standards from both domains, ii) formalizing the definition of integration, iii) developing integrated engineering program assessments, and iv) sharing responsibility for risk management, quality, lifecycle planning, and external suppliers

In our study, we conducted theoretical research into the alignment of standards from both domains. We first identified and analyzed standards and guides in systems engineering (i.e., ANSI/EIA 632, IEEE 1220, INCOSE HandBook, and SEBoK) and did the same with PM standards and guides (i.e., ISO 21500 and PMBoK), as listed in Box 1. We concluded that not a single standard or guide contemplates an advanced cooperation between systems engineering and project management, despite the fact that engineers and manager have to cooperate closely throughout all stages of project development. So, we compared and analyzed the differences and similarities between systems engineering and project management standards and guides with the aim of supplementing them during project implementation. We concluded that it may be interesting to adopt ISO 15288 and to include in the process some processes from EIA (Xue et al., 2014a). However, given that suggesting a new release for a standard may involve a long and complicated process, we decided to compare standards and guides from both domains to evaluate which ones could best be aligned. We came to the conclusion that the ISO/IEC 15288 standard could be aligned with the PMBoK quite easily.

Relying on the principle of cooperating standards, we therefore considered the other solutions suggested by the joint study of the INCOSE and PMI: developing integrated engineering program assessments and sharing responsibilities in decisions. This solution is developed in the proposal outlined in the following section.

Box 1. Standards and guides examined in this study

Systems engineering

Project management

Proposed Method and Tool

The research strategy put forward is motivated by the prospect of improving the companies’ competitiveness in the development of new products or services: according to the MIT survey and industrial practitioners, a better linkage between the development of products or services and project management is a decisive leverage in a project’s performance (Conforto et al., 2013). Existing project management tools and model-based systems engineering tools fail to communicate and do not provide proactive aid to the control of engineering processes and management of said processes. In a highly competitive economic environment, the development cycle keeps shortening and the search for excellence in engineering project management is one of the main pathways for improving competitiveness along at least two main lines:

  1. Acceleration and optimization of the development process from design to prototyping
  2. Improvement of increasingly sophisticated project control through enhanced coordination of all actors and processes involved

Indeed, the quality of collaboration between organizations (in the increasingly common case of projects within distributed companies) and between project actors (the latter enacting different roles) is a decisive performance factor. Current corporate practices derive from proposals and recommendations, particularly those highlighted in the PMBoK guide. The various areas of competence that have to be mustered are fully identified in system design project management, including technical and technological (systems engineering, job engineering, innovation-orientated engineering), financial (resources management) and human (skill management), forecast capabilities (planning), corporate and market knowledge, and risk and opportunity analysis. Project management does not intend to develop these different disciplines involved in system design but aims to implement and coordinate them using tools in line with the objectives sought, for the proper advancement of the project. System design PM is therefore a highly multidisciplinary process and, as a result, is a highly difficult one to achieve: corporate experience plays an essential part in the progressive definition of a "proprietary" process suitable for the type of product or service to be developed. This evidence does account for the fact that, although the PMBOK guide recommends a number of practices, project management does not benefit from a genuinely standardized approach. Hence, in practice, companies have to adapt the general recommendations laid down in PMBOK to suit their operating habits and the engineering processes implemented.

In these corporate approaches, we have already defined the main mechanisms that pose an obstacle to the smooth running of the project, including insufficiently detailed or even inconsistent sets of specifications, a priori unjustified (not to say hazardous) technological choices, clumsy resource allocations, insufficiently shared clear, structured, and understandable information. We focus on the problems and deadlocks associated with the fields of detection, analysis, coordination, and decision making: how can an error or insufficient feature be detected at the earliest opportunity? How can the origin be detected in the history of the choices made during the course of the project? How can the best solution – or at least the best corrective action – be chosen?

The approach proposed here consists of relying on the current dynamic aiming at aligning systems engineering with project management to define a generic process for monitored project management. Its originality lies in the choice of monitoring based on the notion of aggregate indicators, coupling information about the system to be built with the system for creating, as recorded in the dashboards made available to all the major project leaders for purposes of tracking, assessing options, diagnosing, and making decisions. In a nutshell, we propose a new decision-making and technical-coordination tool (i.e., a decision model, a formalization of an integrated project and system evaluation process, an indicator dashboard, and a proactive decision-support mechanism), coupling the system development with project management and systems engineering management. We focus on the evaluation, verification, and validation processes, which are poorly instrumented using regular project management or engineering tools, but which form the backbone of the critical decisions made during project reviews.

These proposals are based on previous studies aiming to prove the concept and feasibility of such a tool (Baron, Estève, & Rochet, 2004; Baron, Rochet, & Estève, 2004; Zhang et al., 2012). On the industrial side, a market analysis shows that the industrial tools available only partly meet the needs. These tools belonging to the field of business intelligence have become essential for organizations to identify changes early and to quickly respond and adapt their strategies. However, they are plagued with their own limitations because they fail to provide the overall vision required to address critical issues such as: "How much effort should we undertake to achieve a sufficient level of maturity for the end customer" or "How can I optimize product quality while complying with budget and time constraints?" Thus, the scientific expertise, together with an analysis of industrial needs and existing tools, led us to design a first prototype, named ATLAS, which progressively evolved towards the definition of a more ambitious one, DECWAYS. In the next section, we briefly describe the objectives and results of ATLAS and where DECWAYS stands relative to the first prototype.

ATLAS

The research project ANR/ATLAS (2008-2011) dealt with the connection between project management and product design, as illustrated in Figure 1.

Figure 1

Figure 1. Architecture of the ATLAS platform

These two domains have been the subject of much research over the years, and a fairly wide range of software solutions have been offered (e.g., in project management: Primavera, MS Project, etc; in product lifecycle management: Windchill, Team Center, ENOVIA, etc.). On the other hand, formalizing the relationships that necessarily existed between these processes was a novel idea. It was tested with twenty or so industrialists; the survey conducted revealed a high level of interest in principle and highlighted the expected results (DRIRE, 2009).

Technically speaking, the starting point of the ATLAS project is the EIA-632 standard for engineering a system. This standard allows the project to be broken down into subprojects, leading to a classical tree representation. This decomposition also allows the review of alternative solutions to be memorized for subsequent use when the time comes to opt for a technical solution for the project. With respect to breaking down the project into subprojects and overcoming the difficulty of exchanging data within this tree structure, a key result of ATLAS has been the drawing up of an overall information transmission model between a project and a subproject (Geneste et al., 2009).

However, the main innovation lies in the implementation of two mechanisms coupling system design tools and project management tools, these mechanisms being used to propagate the managers’ operational and managerial decisions:

  1. Structural coupling: each subproject is broken down into a design architecture and a project management architecture. These two architectures are logically connected to enable an exchange of information.
  2. Information coupling: each subproject is governed by requirements distributed between the two architectures, leading in some cases to the definition of common indicators. The most straightforward example is the budget, which, from the design point of view, will be the provisional budget and, from the project viewpoint, the budget available. The dialog between these two points of view is based on the definition of these indicators and on their management.

To become operational, these two coupling mechanisms necessitate a formal decision-making mechanism to be activated whenever a coupling information or communication network modification justifies it. This mechanism had not been defined by ATLAS.

Beyond this, the main results obtained after completion of this project can be identified at various levels and were essentially used to validate the approach in its principle:

  1. The establishment of an overall monitoring system shared through dashboards associated with each tree node and displaying the system status: these dashboards summarize the values of various indicators – particularly local ones – and provide the real current data value and an estimated value projected downstream of the project.
  2. Conflict management: the conflict arises when one of the two project leaders (i.e., the designer or manager) submits their forecasts to the other, thereby prompting a conflict in respect of the expected indicator values.
  3. Managing options as to the different possible technical solutions: at each step, the aim is to identify and characterize one option or a limited subset of interesting options among a number of evaluated options. Thus, at a given tree node, one obtains the list of possible solutions and the integrated values of various indicators for each solution so as to guide the development of the project towards the completion of the selected option.

Also worth mentioning is the inclusion in this approach of various experiences and achievement reuse mechanisms via a database structured by an ontology of concepts encountered during development.

By focusing on the limitations of ATLAS (i.e., versions that are not managed, rigid tree structure that must be homomorphic, validation processes not taken into account, etc.), it became clear that we had to further investigate: i) the methodology used (by conducting a more detailed analysis of the industrial practices and tools); ii) standards (by implementing highly detailed comparative analyses of systems engineering and project management standards); and iii) technical features (by integrating in the computing-platform project new storage technologies, data access and sharing, new interface generations. etc.).

DECWAYS

Within the context of the lack of a common vision in terms of engineering/project management and the necessary multidisciplinary approach that this vision entails during product or service lifecycle, we relied on the results obtained with this first prototype to define a method and specify a tool for supervision, coordination, and control of the evolving stages of a project involving all stakeholders. This proposal truly breaks away from current engineering practices by monitoring the whole development cycle of a product or service from its initial design phase to the prototyping of solutions.

In comparison to ATLAS, DECWAYS offers new proposals:

  1. Submitting a generic, high-level project management process that can easily be appropriated by companies, handling multidisciplinary features, and supplementing PMBOK practices. The goal is to promote alignment between disciplines and particularly systems engineering and project management by harmonizing their descriptions of the project notion and its constituent processes, a strategic need as underpinned by the INCOSE/PMBOK alignment (Conforto et al., 2013). In this way, the ATLAS project has been refined to take into account the standardization between project management and systems engineering processes and to exploit the notion of indicators supportive of this alignment.
     
  2. Refining the notion of indicators as language elements common to the disciplines concerned. The aim is to:
    • Highlight indicators allowing one to check how the stakeholders handle any mismatch between expectations and results. These expectations may deal with the system to be built (as viewed from the angle of the product or service) or the system for creating (as seen from the viewpoint of performance, stability, and integrity of the organization supporting the project) (Baron et al., 2009).
    • Show how to construct "aggregate indicators" and "dashboards" providing an overall process supervision capability. The goal is to bring together and promote the use of all data to steer projects and more generally support decision making when managing reputedly highly complex projects.
  3. Designing a smart system for an integrated management of a development project relying on the generic process model and on indicators and dashboards to master multidisciplinarity and the project progress; the aim is to:
    • Define mechanisms that provide a genuine aid for taking into account the needs of stakeholders and following-up, verifying, and validating these needs according to the indicators selected.
    • Anticipate and plan the efforts needed, however costly but unavoidable, to check and validate both systems (i.e., the system to be built and the system for creating).
    • Propose mechanisms for tracking any malfunctions by relying more particularly on trend analysis and offering an aid to decision making and longitudinal follow up of the project evolution.
    • Permit exploration of options for guiding the development of systems to be built and the project.

To specify the outlines, objectives, functioning, and services offered by DECWAYS, a first objective was to work towards the alignment of project management and systems engineering process modelling (i.e., needs and requirements engineering, architecture design, system analysis, check and validation) applied to a project. As previously mentioned, Zolghadri and colleagues (2010, 2011) allowed us to analyze the main differences in their descriptions, as well as the roles involved in the process. A comparative study of processes identified the main deviations in their descriptions (Xue et al., 2014b), the roles in either process, and submitted ways and means to make these processes more operational by facilitating their cooperation in practice by looking for and defining the links needed between them (Xue et al., 2014b). This was a prerequisite and a condition for successfully arriving at a generic process of project management that includes coordination, decision making, tracking, analysis, memorizing, follow-up, and correction. Standardizing the process descriptions is one of the means of bringing closer together the systems engineering and project management approaches.

DECWAYS intends to rely on an extended version of ANSI/EIA 632 standard for systems engineering and on the PMBOK for project management (Xue et al., 2014b). As a result, the choice made by DECWAYS lies within the scope of the approach identified in the INCOSE-PMI-MIT project.

However, the analysis goes beyond this result. Indeed, in order to meet our pragmatic concern expressed earlier (i.e., to adapt standards and scale them for SMEs through easy-to-use tools), it was necessary to simplify the organization and the interconnection of processes and to define how and when processes were (or could be) interconnected and who (i.e., which role) was involved in the company. An option that has already been identified in the ATLAS project consisted of a recursive description of concatenated task batches and in coupling design and management through a decisional model associating the leaders of these two communities. A possible solution in DECWAYS would be to distribute the overall project leadership according to three activities with complementary responsibilities – Executing (Ex), Planning (Pl), Controlling (Co) – relying on a single structural representation of the project (e.g., of the Work Breakdown Structure type). These three responsibilities (Ex, Pl, and Co) share the same obligation, when programming so dictates or when a malfunctioning warning sign occurs, to embark on a discussion and to go ahead only if a decision has been made and if dissemination and memorization have been conducted.

For these activities, the benefit of sharing a common representation lies in the cooperation that it entails and formalizes: at each time step, any discrepancy relative to the original programming will be characterized through use of indicators and the project will only be allowed to continue if the three partners – Ex, Pl and Co – permit. As a potential discrepancy has been characterized, each partner can within their remit analyze upstream requirements that have not been met and find reasons for such a deviation within or without their area of expertise and initiate a dialog with their partners. However, DECWAYS does not interfere with the choice mechanism for decision making: it can either result from a discussion through consensus building or be handled directly by each project leader. What is important here is to record the decision and its context in order to memorize the decision routes and progressively improve them over time on the basis of experience.

In this standardization of systems engineering and project management processes, the second objective is to obtain greater insights into the notion of indicators and deviation. During the task execution, monitoring the evolution of each indicator and checking against the objective will enable an automatic detection of any deviations between the work program initially drawn up and the effective progress in the field.

Operationally, these indicators feature various lifecycles: their definitions, the negotiation between the stakeholders of objective values and related parameters (i.e., thresholds, validity ranges, etc.), and their evolution over time as recorded during implementation. They reflect or are computed on the basis of data, tacit information, and knowledge recorded by the company in its information system (i.e., data originating from enterprise resource planning, data about the project progress and follow-up of the planning tool, etc.). In DECWAYS, the objective is therefore to obtain greater insights into the indicator concept so as to provide it in a multiple-indicator approach (i.e., to express it in a multiple indicator format), with the ability to dialog, to detect danger and drifts, to diagnose and analyze with the ultimate goal of tracing it back to the design and set of specifications, if needed, on the technical and on the organizational side. To do this, we identified several indicators whose function and nature differ: pre-defined "classic" indicators associated with the definition of processes in systems engineering standards and "customized" ones, depending on the project or relative to the company strategy. As in ATLAS, dashboard definition and operator interfacing are part and parcel of the project: given the necessary hierarchical construct of tasks, indicators will be progressively aggregated, which might lead to a multilevel construct of these indicators. Figure 2 synthesizes the main principles of the method and tool.

Figure 2

Figure 2. Architecture of the DECWAYS platform

Conclusion

To develop systems quickly and efficiently, it becomes crucial to align practices in systems engineering and in project management. This issue of systems engineering and project management integration is at the core of economic and industrial concerns. It is also a source of motivation for international standardization organizations, companies, and governments alike.

The DECWAYS method and tool address any inconsistencies that might exist between systems engineering and project management domains, from a pragmatic perspective. It is a follow through on the ATLAS project, which has demonstrated the feasibility of the concept and has served as a prototype to validate the industrial value of these proposals. The tool tackles the issue of collaborative work and project steering conducted in a consistent manner in terms of follow-up and decisions. DECWAYS seeks to offer a method and tool capable of bringing systems engineering and project management closer together, detecting practical divergences, making concerted decisions, and jointly supervising the proper development of the project and system. This article presented the objectives and specifications of the DECWAYS tool, which aims to address this problem. As underscored by the INCOSE-PMI-MIT analysis, a natural means of achieving process cooperation, chosen in DECWAYS, is the use of standards from both domains and processes from these standards. But, beyond the mere issue of choosing between the main standards and with the aim of achieving a better match with project management processes, DECWAYS also considers other ways to align processes from both domains such as sharing responsibilities and crossing data towards a collaborative decision process. To do so, it intends to structure collaboration (i.e., between processes, actors, etc.) and provide project leaders and engineers with information produced to assist with decision making. Such a technical and scientific concern fits in well with the current purpose of reducing the cost of intellectual work (e.g., management, engineering, finance) of $5,000 billion annually until 2025 via "smart" software (McKinsey Global Institute, 2013.  Thus, DECWAYS should facilitate the management of projects in companies by providing: i) progress visibility, ii) a formal decision-making process, and iii) traceability.

 

Acknowledgements

An earlier version of this article was presented at the 2014 International Conference on Engineering, Technology, and Innovation (ICE), which was held from June 23rd to 25th in Bergamo, Italy. The ICE conference discusses systems engineering as a socio-technical task, with a focus on design of products and services, and the entrepreneurial innovation process for its adoption in society and the economy.

 


References

Baron, C., Estève, D., & Rochet, S. 2004. How Evolutionary Computation Can Be Introduced to Select and Optimize Scenarii along a Product Design Process. Transactions on Systems, 3(2): 888–893.

Baron, C., Rochet, S., & Estève, D. 2004. A Genetic Approach to Support Decision Makers during Project Management. Transactions on Systems, 3(3): 1027–1032.

Baron, C., Auriol, G., Zolghadri, M., Wehbe, A., Merlo, C., & Girard, P. 2009. Livrable L6 : Entités d’organisation et de planification - Version finale des méthodes et principes utilizes. Rapport de Contrat: Projet ANR-RNTL: ATLAS 07TLOG002.

Beer, M., & Nohria, N. 2000. Cracking the Code of Change. Harvard Business Review, 78(3): 133-141.

Conforto, E., Rossi, M., Rebentisch, E., Oehmen, J., & Pacenza, M. 2013. Improving the Integration of Program Management and System Engineering. Survey report presented at the 23th INCOSE Annual International Symposium.
http://cepe.mit.edu/survey-results-pm-se/

Danilovic, M., & Browning, T. R. 2007. Managing Complex Product Development Projects with Design Structure Matrices and Domain Mapping Matrices. International Journal of Project Management, 25(3): 300–314.
http://dx.doi.org/10.1016/j.ijproman.2006.11.003

DRIRE. 2009. Report on the Project APOSAR: Analyse des Problématiques Organisationnelles du Secteur Aéronautique Régional. Paris: Direction régionale de l'Industrie, de la Recherche et de l'Environnement (DRIRE).

Eppinger, S. D., & Salminen, V. 2001. Patterns of Product Development Interactions. International Conference on Engineering Design.
http://hdl.handle.net/1721.1/3808

Geneste, L., Reversat, Y., Robert, A., Esteban, P., Esteve, D., Pascal, J.-C., Abeille, J. 2009. Livrable L5: Spécification détaillée complète de l'environnement de conception. Rapport de Contrat: Projet ANR-RNTL: ATLAS 07TLOG0022009.

Langle, M., 2011. Toward a New Mindset – Bridging the Gap between Program Management and Systems Engineering. PM Network, September: 24–26.

Lee, S. G., Ma, Y. S., Thimm, G. L., & Verstraeten, J. 2008. Product Lifecycle Management in Aviation Maintenance, Repair and Overhaul. Computers in Industry, 59(2-3): 296–303.
http://dx.doi.org/10.1016/j.compind.2007.06.022

McKinsey Global Institute. 2013. Disruptive Technologies: Advances That Will Transform Life, Business, and the Global Economy. McKinsey & Company. http://www.mckinsey.com/insights/business_technology/disruptive_technolo...

Nayagam. 2011. Enquête sur les usages de solutions PLM en entreprise. Press Release. Pierre Audoin Consultants (PAC), December 13, 2011. Accessed March 1, 2015:
https://www.pac-online.com/enqu%C3%AAte-sur-les-usages-de-solutions-plm-...

Oehmen, J. et al. 2012. The Guide to Lean Enablers for Managing Engineering Programs. Cambridge, MA: Joint MIT PMI INCOSE Community of Practice on Lean in Program Management.
http://hdl.handle.net/1721.1/70495, 2012.

Pyster, A., & Olwell, D. 2013. The Guide to the Systems Engineering Body of Knowledge (SEBoK), v.1.1. Hoboken, NJ: The Trustees of the Stevens Institute of Technology. Accessed March 1, 2015:
http://www.sebokwiki.org/

Sharon, A., De, W. & Olivier, L. 2011. Project Management Vs. Systems Engineering Management: A Practitioner’s View on Integrating the Project and Product Domains. Systems Engineering, 14(4): 427–440.
http://dx.doi.org/10.1002/sys.20187

Standish Group International. 2013. CHAOS Manifesto 2013: Think Big, Act Small. The Standish Group International.

Sudarsan, R., Fenves, S. J., Sriram, R. D., & Wang, F. 2005. A Product Information Modeling Framework for Product Lifecycle Management. Computer-Aided Design, 37(12): 1399–1411.
http://dx.doi.org/10.1016/j.cad.2005.02.010

Sudarsan, R., Subrahmanian, E., Bouras, A., Fenves, S.J., Foufou, S., & Sriram, R. D. 2008. Information Sharing and Exchange in the Context of Product Lifecycle Management: Role of Standards. Computer-Aided Design, 40(7): 789–800.
http://dx.doi.org/10.1016/j.cad.2007.06.012

Xue, R., Baron, C., & Esteban, P. 2014a. Integrating Systems Engineering with Project Management: A Current Challenge! INCOSE 2014 International Symposium.

Xue, R., Baron, C., & Esteban, P. 2014b. Managing Systems Engineering Processes: A Multi-Standard Approach. 8th Annual IEEE International Systems Conference.

Zhang, X., Auriol, G., Eres, H., & Baron, C. 2013. A Prescriptive Approach to Qualify and Quantify Customer Value for Value-Based Requirements Engineering. International Journal of Computer Integrated Manufacturing, 26(4): 327–345.
http://dx.doi.org/10.1080/0951192X.2012.717718

Zolghadri, M., Baron, C., & Girard, P. 2010. Modelling the Mutual Dependencies between Product Architectures and a Network of Partners. International Journal on Product Development, 10(1/2/3): 62–86.
http://dx.doi.org/10.1504/IJPD.2010.032451

Zolghadri, M., Baron, C., Aldanondo, M., & Girard, P. 2011. A General Framework for New Product Development Projects. International Journal of Technology Management, 55(3/4): 250–262.
http://dx.doi.org/10.1504/IJTM.2011.041951

Share this article:

Cite this article:

Rate This Content: 
No votes have been cast yet. Have your say!

Keywords: collaborative engineering, decision support, engineering processes, project management, system design, systems engineering, systems engineering standards

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.