Project Management vs. Systems Engineering Management: …

1 Project Management vs. Systems EngineeringManagement: A Practitioners View onIntegrating the Project and Product DomainsAmira Sharon,1, * Olivier L. de Weck,2 and Dov Dori11 Faculty of Industrial Engineering and Management , Technion, Israel Institute of Technology, Haifa 32000, Israel2 Engineering Systems Division, Massachusetts Institute of Technology, 77 Massachusetts Avenue, Cambridge, MA 02139 Project Management VS. Systems Engineering MANAGEMENTR eceived 3 August 2010; Revised 18 December 2010; Accepted 18 December 2010, after one or more revisionsPublished online in Wiley Online Library ( ). DOI most Systems Engineering Management (SEM) applications use some subset of traditional ProjectManagement (PM) methods and tools, the actual practice of Systems Engineering Management involvescontinuous cognitive zigzagging between Systems Engineering the product domain and Project man-agement the Project domain.

2 Focusing on seven PM methods, we examine two research questionsregarding Systems Engineering practitioners: (1) While conducting SEM, do they perceive a notion of aproject domain, a product domain, and a combined Project -product domain? (2) What is the extent towhich, and ways by which, Systems Engineering practitioners deem PM methods as effective for supportingSEM? Using analysis of structured questionnaires among 24 participants, we verified that Project andproduct are indeed viewed as two complementary facets of SEM, and that certain PM methods addressboth domains better than others with respect to particular examined factors. 2011 Wiley international,Inc. Syst Eng Key words: Systems Engineering Management ; Project Management ; model-based Systems Engineering ;model-based Project planning; Project -product lifecycle management1.

3 INTRODUCTIONS ystems Engineering (SE) and Project Management (PM) aretwo tightly intertwined domains as stated in the Handbook ofSystems Engineering and Management by Sage and Rouse[2009]. The handbook is a recent detailed source for a frame-work to SEM and its application for various types of Engineering Management (SEM) utilizes some com-mon Project Management framework features, such as WorkBreakdown Structure (WBS), Project organization, and man-agement plan in the form of system Engineering Manage-ment Plan (SEMP) [Blanchard, 2008]. As SEM is the practicethat couples the SE domain and the PM domain, the successfulimplementation of system Engineering requires not only tech-nical but also managerial traits [Kossiakoff and Sweet, 2003]. Systems engineers are required therefore to apply science andtechnology, as well as technical planning, Management , andleadership activities [Frank, 2000].

4 Systems engineeringmanagers must rely on a combination of technical skills andmanagement principles that address both complex technicaland managerial issues. While the technical issues are relatedto the product domain, the managerial aspects reside in theproject domain. Practicing SEM is a continuous process,conducted by iterative zigzagging between the technical prod-uct domain and the managerial Project domain. It is an itera-*Author to whom all correspondence should be addressed (e-mail: Engineering 2011 Wiley Periodicals, Inc. 1 Regular Papertive process of planning, derivation, refinement, and simula-tion of both the product models and the Management plans,while maintaining traceability and coherence between theproduct models and the Project plan at all levels through thehierarchical structure of both the product and the impact of Systems Engineering on program cost wasrecognized over a decade ago [DSMC, 1999])

5 , suggesting that,from the very early stages, careful Management of the rela-tionships between the product and the Project is crucial to thesuccesses of a Project that aims to deliver a defined to closely manage the intricate web of resource con-straints emanating from the two domains the Project and theproduct for meeting the development and test objectives isa recipe for inadequate product performance and Project timeand cost overruns. The identification and Management of therelationships between the two domains is at the heart of SEMpractitioners. Empirical investigations have shown that therelationships and interactions between the architecture ofsystems, their development projects, and the organizationalteams involved, should be aligned in order for a company tobecome successful [Eppinger and Salminen, 2001].

6 These observations call for a fresh look at the methods andtools Systems Engineering managers use in an attempt to bringthe product issues and the Project issues together under thesame conceptual model of a combined Project -product systemensemble. This is the premise of the Project -Product LifecycleManagement (PPLM) paradigm [Sharon, Perelman, and Dori,2008; Sharon, Dori, and de Weck, 2009], the context withinwhich this research was conducted. The PPLM approach isdesigned specifically with SEM in mind. The PPLM effortaims at developing a methodology and a support softwareenvironment for fusing the product to be developed with theproject to be executed by SEM on seven researched PM methods, this paperpresents two research questions: (1) While engaged in systemengineering Management , do practitioners perceive a notionof a Project -domain, a product-domain, and a combined pro-ject-product domain?

7 (2) How do Systems engineers perceivethe extent to which each one of the surveyed PM methodssupports SEM?2. THE COMPARED Project MANAGEMENTMETHODSThe need to concurrently address more than one domain hasbeen identified by Suh [1990], who developed the AxiomaticDesign (AD) methodology. AD addresses four domains: thecustomer, functional, physical, and process domains. Theoutput of each domain evolves gradually and hierarchicallyfrom an abstract concept into detailed information. The hier-archical decomposition in one domain cannot be performedindependently of the other domains; , decomposition re-quires zigzagging in order to map adjacent domains to eachother. The planning process involves the continuous process-ing of information within and between the four domains. Thecustomer needs are identified in the customer domain and arestated in the form of required functionality of a product in thefunctional domain.

8 Design parameters that satisfy the func-tional requirements are defined in the physical domain, andmanufacturing variables are defined in the process domain inorder to determine how the product is to be produced. The ADphysical domain is somewhat analogous to our product do-main, while the AD process domain contains elements of ourproject domain. However, all the four AD domains focus tothe product. In our context of SEM and PM, the mentalzigzagging between domains entails switching back and forthbetween the product domain and the Project domain. With thisrealization in mind, we have decided to conduct a comparisonsurvey of Project Management Methods, which are com-monly used by Systems Engineering managers. These methodsinclude Work Breakdown Structure (WBS) [Department ofDefense, 1968], Product Breakdown Structure (PBS) [Officeof Government Commerce, 2005], Reliability, Availability,Maintainability (RAM) [Department of Defense, 2009],Critical Chain Project Management (CCPM) by Theory ofConstraints (TOC), resource scheduling, procurement tech-niques, contract bidding techniques, and risk managementmethods.

9 Other traditional methods are Earned Value Method(EVM), Design Structure Matrix (DSM), system Dynamics(SD), Critical Path Method (CPM), Program Evaluation andReviewing Technique (PERT), and Gantt chart. The last meth-ods, together with WBS, vary in terms of their objectives andapplications, and are the most referenced PM methods insystems Engineering handbooks sources, indicating that theyare most commonly used within SEM. We have examinedseven PM methods EVM, DSM, SD, CPM, PERT, Ganttchart, along with Object Process Methodology (OPM) [Dori,2002] for answering our both research questions. See theAppendix for succinct description of the seven PM potential use of Object Process Methodology (OPM)for Project planning and Management has been studied in thecontext of the Project -Product Lifecycle Management (PPLM) framework [Sharon, Perelman, and Dori, 2008,Sharon, Dori, and de Weck, 2009], and is explored further inthis study.

10 Originally used for modeling information systemsand for Systems architecting and Engineering , Object ProcessMethodology (OPM) has been found useful for Project plan-ning in combination with product Systems representation. Itssuitability stems from its inherent capability to combine prod-uct- and Project -based planning within a single Model-BasedProject Plan (MBPP). OPM is a formal yet intuitive concep-tual modeling language with formal ontology, syntax, andsemantics. Specific extensions to OPM were defined as partof the PPLM research. Based on OPM s formality, specificPPLM OPM-based templates were developed to be used formodeling of combined Project -product RESEARCH POPULATION AND SETTINGThe research population consisted of 24 mid-career systemsengineers from companies across the USA with an average years of work experience.