A Project–Product Model–Based Approach to Planning Work Breakdown Structures of Complex System Projects A

Home , Work breakdown structure

IEEE SYSTEMS JOURNAL 1 A Project–Product Model–Based Approach to Planning Work Breakdown Structures of Complex System Projects A. Sharon and D. Dori, Senior Member, IEEE

Abstract—Project planning practices employ various methods domain and the product domain—gradually and hierarchically at various stages, with work breakdown structure (WBS) being evolve from abstract concepts into detailed information. The a prominent starting point. Using WBS, the components and hierarchical decomposition in the project domain cannot be associated enabling products are often not explicitly expressed. We first introduce the notions of generic project construct and performed independently of the system domain. In other words, system build. Using a running example of a simplified unmanned this decomposition requires zigzagging between these two aerial vehicle, we review the WBS method and discuss prob- adjacent domains in order to map them to each other. This lems stemming from the lack of explicit and direct representa- mapping between the two domains becomes more difficult tion of the product facet in the project plan. A comprehensive as the product to be developed gets more complex or as the project–product life cycle management model is the exclusive authoritative source for deriving project management tools, in- project scale grows. Project complexity often depends also on cluding WBS, augmented with product-related information. the complexity of the organization and the connections among its parties [4]. A definition that integrates the product aspect Index Terms—Complex systems, conceptual modeling, model- based planning, object–process methodology (OPM), project man- with the project aspect has been suggested by Shenhar and agement, project planning, project–product life cycle management Dvir [5], [6], who argued that the project complexity depends (PPLM), work breakdown structure (WBS). upon product scope, number and variety of elements, and the interconnection between them, in addition to uncertainty due I. INTRODUCTION to novelty or superhigh technology system development. The product complexity is usually handled by decomposing its HE PROJECT and the system it delivers, be it a product, architecture into a hierarchical structure. The planning process a service, or some combination thereof, are inseparable. T is aimed at managing the complexity of the evolving design so What needs to be developed, tested, and delivered is determined all its relevant aspects and details are accounted for. by the system requirements, its architecture, and design. Each Managing this complexity is the problem that lies at the heart component that should and can be developed and tested is of the project–product life cycle management (PPLM) approach stated in the project plan. A framework and a process for [7]. The integrated PPLM approach and the model used in integrating perspectives of a developed complex system with this paper induce traceability, explicating critical relationships its corresponding project processes are clearly missing [1]. between the product and the project. As we show in the sequel, Furthermore, empirical investigations have shown that the the ability to simultaneously express the required information relationships and interactions between the architecture of prod- from the project and the product domains within a single in- ucts, their development projects, and the organizational teams tegrated model-based framework can potentially lead to a more involved, should be aligned in order for a company to be- reliable project plan, which is less prone to the need for repeated come successful [2]. However, since the development of a IEEEchanges, rework, and corrective actions. The increased robust- complex system—a project—involves design processes, which ness of the resulting project plan is attributed to the constant ref- differ from workflow processes [3], the planned activities are erence to the system model, which is integrated into the PPLM usually unique to each specific project. Moreover, there is no model, while making decisions about the project’s “technolog- single “correct” way of breaking down the project activities. ical order” [8]. The planning process carried out following this In large-scale projects, the project and the product are hierar- approach clarifies the intricate relationships between project chically decomposed. The outputs of each domain—the project and product or system entities. This model-based approach enables the simultaneous expression of the function, structure, Manuscript received April 16, 2013; revised November 26, 2013; accepted and behavior of both the project and the product via the same December 18, 2013. Proof A. Sharon is with Technion–Israel Institute of Technology, Haifa 32000, ontological and methodological foundations, maintaining full Israel (e-mail: [email protected]). traceability between project and product data and information. D. Dori is with the Engineering Systems Division, Massachusetts Institute of Technology, Cambridge, MA 02139 USA, and also with the Faculty of Indus- In this paper, we focus on the work breakdown structure trial Engineering and Management, Technion–Israel Institute of Technology, (WBS), a widely used planning method [9]. WBS is a tree struc- Haifa, Israel (e-mail: [email protected]). ture representing a hierarchical decomposition of a project into Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. smaller components, down to the level of work elements—the Digital Object Identifier 10.1109/JSYST.2013.2297491 leaves of the hierarchy. WBS is supposed to reflect the total

1932-8184 © 2014 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information. 2 IEEE SYSTEMS JOURNAL scope of work involved in the project. Capturing the entire TABLE I work and efforts required for the project is most important, COMPARISON BETWEEN THE FOUR PPLM MODELING LANGUAGE CANDIDATES as WBS is the source for project cost estimations, schedule planning, and risk mitigation. In order to accomplish the project objectives and produce the anticipated deliverables, the Guide to the Project Management Body of Knowledge [10] promotes a deliverables-oriented decomposition of the work to be executed. Producing such a deliverables-oriented WBS requires that the WBS be based on planned outcomes throughout the project, rather than on planned actions. Using this approach produces a project plan in which the system or the product is written all over, albeit not explicitly. We propose a model-based counterpart of the WBS and demonstrate its advantages with respect to the classical WBS. This WBS is based on our PPLM approach [11], [12], which is described next. The suggested improvement over the classical WBS model can become useful to the product design definition and project planning phases during complex, novel, high, or superhigh technology system development. OPM is a holistic integrated approach to the design and In addition to the model-based WBS for managing the development of systems in general and complex dynamic sys- project-product system complexity, we introduce and define tems in particular. A formal yet intuitive paradigm for systems two fundamental concepts that are useful in PPLM-based mod- architecture, engineering, development, life cycle support, and eling of project–product systems: the generic project construct evolution, OPM has been used for modeling of both natural (GPC), which enables the project plan to explicitly incorporate and artificial complex systems, where natural systems draw the product facets, and the system build (SB), which enables upon conceptual systems biology [15], [16], whereas artifi- modeling of various project–product configurations to be de- cial ones might comprise humans, physical objects, hardware, signed and constructed along the early project–product life software, regulations, and information. The OPM ontology is cycle phases, each with its specific demonstrable requirement- most compact. As its name suggests, the two basic building meeting capabilities. blocks in OPM are (stateful) objects—things that exist (at some state)—and processes—things that transform objects by creating or destroying them or by changing their state. Objects II. PPLM FRAMEWORK and processes are of equal importance, as they complement Product life cycle management (PLM), a concept that has each other in the model specification. The model is represented been around for over two decades, brings together previously in a single type of diagram that is translated on the fly to basic disparate fields, including computer aided design, product English. Links, the OPM elements that connect entities, are data management, sustainable development, enterprise resource of two types: structural and procedural. These generic OPM planning, and life cycle analysis and recycling [13]. PLM elements make OPM suitable for modeling complex systems is about establishing relationships among entities across the that comprise technology and humans. This definition is equally arsenal of tools used in a specific enterprise throughout the suitable for modeling the product system to be delivered and the product life cycle. The PPLM approach [11], [12] extends project system designed to deliver the product system. More- PLM in a significant way by calling for the construction of a over, the project and the product can be easily viewed as two IEEEfacets of a larger overarching system, in which the project is just comprehensive project–product model at the early stages of the combined project–product life cycle. The model can be then the first of several phases in the life cycle of the system, whose integrated with a tailored organizational PLM solution. main longest phase is deployment, usage, and maintenance. The PPLM model integrates the project domain with the OPM notation supports conceptual modeling of systems product domain via a shared ontology, utilizing object process using a single type of diagram to describe the functional, methodology (OPM) [14]. Here, we refer to product in its broad structural, and behavioral aspects of a system. An OPM model sense, capturing also the notions of whole product or service consists of a set of hierarchically organized object–process system. Potential users of our PPLM framework come from a diagrams (OPDs) that alleviate the systems’ complexity. Each OPD is obtainedProof by refining—in-zooming or unfolding—a wide range of disciplines and user types, including enterprise, 1 project, and systems engineering managers. The notation, while thing (object or process) found in its ancestor OPD. OPCAT being formal, must therefore be also simple and intuitive; thus, [17], an OPM-based conceptual modeling software environ- all the potential users and stakeholders can relate to the model ment, features an accessible user-friendly interface, a basic as it evolves. animated class-level execution module, and integration with Comparison of four candidate modeling languages—UML, files of various formats, e.g., XML and CSV, reducing the de- xUML, SysML, and OPM (see Table I)—led to the selection velopment effort. OPM is currently in the process of becoming of OPM as the underlying conceptual modeling language and paradigm for PPLM. 1http://esml.iem.technion.ac.il/ SHARON AND DORI: PROJECT–PRODUCT MODEL–BASED APPROACH TO PLANNING WORK BREAKDOWN STRUCTURES 3 an ISO standard 19450, a publicly available specification for enterprise standards [18]. When completed, this endorsement will enable accelerated dissemination of OPM as a basis for enterprise standards in general and for PPLM in particular. Using OPM, the combined project–product model ultimately contains the activities (compound processes), tasks (leaf level, atomic processes), and deliverables or products (objects). Hence, activities and tasks are OPM processes at various detail levels required for completing the product. Deliverables are product components, resources, and informatical objects, such as documents and approvals. Having all this information consistently embedded in the same PPLM model eventually yields all the specific structural relations (among objects) and procedural relations (between objects and processes). Understanding the product’s structure hierarchy hand-in-hand with the project activities and progress provides the basis for the technological process order and timing. With this understanding, the project planner can model the rationale for ordering the project activities—the model processes—by identifying the flow of objects into and out of each process.

III. COMBINED PROJECT–PRODUCT METHODOLOGY A. The Generic Project Construct (GPC) The PPLM model is constructed using a designated template

called the generic project construct, or GPC, which is presented × ÜÙØ ÓÒ in Fig. 1. The GPC comprises the process Ì ,

which takes an expected duration and is aimed at achieving a Ê×ÓÙÖ× ËØ

speciﬁc Ð ÚÖÐ× ËØ,usinga that special-

ÙØ ÁÒ×ØÖÙÑÒØ× ËØ ÒØ× ËØ izes into ÒØ× ËØ, ,and .

is a set of required human enablers, ÁÒ×ØÖÙÑÒØ× ËØ is a set

of required nonhuman enablers, and ÙØ is a consumed

monetary input. Although ÙØ could have been considered

to be member of the ÁÒ×ØÖÙÑÒØ× ËØ, it has been assigned its own dedicated object since it is a universal generic resource that enables attainment of all the other resources, and all other resources consumption can be expressed by or converted into

units of ÙØ.

Each resource type is utilized as deﬁned by its ÍØ Ð ÞØ ÓÒ at-

tribute, which is measured using speciﬁed Å×ÙÖÑÒØ ÍÒ Ø×.

IEEEFig. 1. OPM model of a generic project construct (GPC) with its OPD—the

× ÜÙØ ÓÒ ÙÖØ ÓÒ The Ì process has an associated at- graphical modality—and the OPL paragraph that was automatically extracted

tribute, which is deﬁned by Å Ò ÑÙÑ Ø ÚØ ÓÒ Ì Ñ, from the OPD by OPCAT.

ÍÒ Ø× ÊÐØ ÁÒÓÖÑØ ÓÒ

ÅÜ ÑÙÑ Ø ÚØ ÓÒ Ì Ñ,and .

Ì× ÜÙØ ÓÒ

ËØ is linked to each speciﬁc process, per- Ê × ËØ

taining to a speciﬁc ÊÕÙ ÖÑÒØ× ËØ and .The Current methods apply traceability mechanism to track

Ì× ÜÙØ ÓÒ Ð ÚÖÐ× ËØ, which is the outcome of each , project concepts, such as task and milestone, to product con- may include deliverables such as product components, docu- cepts, such as requirements, functions, and components. Con- ments related to derived requirements, approvals, simulations, versely, the GPCProof facilitates and streamlines the modeling of

analyses, speciﬁcations, and other types of reports. These deliv- the entire project–product complex overarching system, as it ÓÑÔÓÒÒØ erables are classiﬁed into three roles: Ó ÙÑÒØ, , provides a means for checking all the possible deliverables that

or Ø . Each one of the deliverables directly and explicitly can be generated by each activity and are required by one or results from a speciﬁc process in the PPLM model and is used more subsequent activities. The time for obtaining each deliver- in a subsequent process, either as an instrument (usually if able can be calculated from the relevant process durations. The it is an informatical object, which does not change) or as a resulting project plan incorporates the product to be designed, consumee (usually a physical object that is consumed by or manufactured, delivered, used, serviced, and disposed of, with

embedded into a larger component). The Ê×ÓÙÖ× ËØ and the the project, including all its signiﬁcant deliverables, such as

Ð ÚÖÐ× ËØ are described and exempliﬁed in Table II. resources and their allocation, timetable, limits and milestones, 4 IEEE SYSTEMS JOURNAL

TABLE II TABLE III CLASSIFICATION OF OBJECTS IN THE OPM PROJECT PLAN SB-RELATED DEFINITIONS FOR THE COMBINED PROJECT–PRODUCT METHODOLOGY

The incremental strategy [19], which is called “preplanned product improvement” [20], determines user needs and de- fines the system requirements with focus on software. It then performs the rest of the development in a sequence of builds. The first build incorporates part of the planned capabilities, the next build adds more capabilities, and so on, until the system is complete. The “evolutionary” strategy [20], while also advocating the development of a system using builds, differs IEEEfrom the incremental strategy in that it acknowledges that the user’s needs are initially not fully understood, and therefore, not all the requirements can be defined upfront. Following the evaluation of project constraints, and assertions related to its evolutionary strategy, user needs and system requirements are cost and duration. defined upfront only partially and are refined in each build. Our proposed SBs strategy resembles the incremental strategy, with one major difference: while in the incremental strat- B. System Build (SB) egy the capabilities are built up on top of each other for each The complete combined project–product ensemble includes build, our SBsProof strategy facilitates the planning of capabilities the concept of system build, or SB. An SB is a specific con- to be achieved not necessarily in a cumulative manner, but figuration of the system, which is planned to be achieved at rather in a way that best serves the technological order and risk some point along the project life cycle span. A methodology mitigation of the project. involving SBs enables the planner to plan for a specific func- The number of SBs planned for a project depends on the tionality, which is related to a specific requirement or a set of planner’s technical experience and judgment. The SBs planning requirements that must be met in a certain SB. is derived from the system requirements, functionality, and There are two known strategies that are related to our pro- architecture, accounting, as noted, for technological capabilities posed SBs approach: the incremental strategy and the evolu- and risk mitigating. Some SBs may be planned to achieve cer- tionary strategy. tain functionality to be demonstrated due to binding milestones,

SHARON AND DORI: PROJECT–PRODUCT MODEL–BASED APPROACH TO PLANNING WORK BREAKDOWN STRUCTURES 5 ÖÓ ××

Fig. 2. PPLM model of an ËÍ ÚÐÓÔ Ò Ô .

ÙÒØ ÓÒ ½ ËÝ×ØÑ $ÙÒØ ÓÒ & whereas other SBs may be planned for mitigating technological ËÝ×ØÑ $ and achieved according risks along the development of the system to be delivered. In to the plan. The dashed red line denoted by NOW indicates the

any case, the last SB is the complete product to be supplied by current time.

" ÁÒØÖØ Ò the project. The product or service system to be delivered is the ÁÒØÖØ Ò + immediately starts when +

uniﬁcation of all the capabilities proven successful in previous ends, at the end of the second year’s quarter, as denoted "

SBs, reﬂecting all the system requirements and functions that by the horizontal dashed line. For ÁÒØÖØ Ò + to start,

ËÙ×Ý×ØÑ " ÓÑÔÐØ

were realized in the entire set of SBs. SB-related deﬁnitions both ËÙ×Ý×ØÑ and must be in their

" ËÍ

for the combined project–product methodology are listed in states. When ÁÒØÖØ Ò + ends, the second SB—

ËÝ×ØÑ $ÙÒØ ÓÒ ¾ ËÝ×ØÑ

Table III. Ë ¾—is complete, exhibiting and ÙÒØ ÓÒ ¿

Fig. 2 depicts the OPM view of the PPLM model for a $ according to the plan. ÚÐÓÔ Ò general ÚÐÓÔ Ò process. The process is aimed Having the information of both the product and the project

to produce the three subsystems, namely, ËÙ×Ý×ØÑ , in the combined plan enables the following observation: Since

ËÙ×Ý×ØÑ " ÓÑÔÐØ ÁÒØÖØ Ò " ÓÑÔÐØ ËÙ×Ý×ØÑ ÓÑ¹

ËÙ×Ý×ØÑ ,and , each in its state. + requires and ÔÐØ ËÙ×Ý×ØÑ "

All three subsystems comprise the ËÝ×ØÑ ÍÒÖ ÚÐÓÔ¹ , without them being integrated, there is no

ËÍ ËÝ×ØÑ $ÙÒØ ÓÒ× ÁÒØÖØ Ò " ÁÒØÖØ Ò

ÑÒØ ( ), which exhibits ﬁve .TheSUD need for + to be executed after +

is planned to be accomplished by four SBs: 1) ËÍ Ë ½, ends. It can be planned to start earlier.

ÙÒØ ÓÒ ½ ËÝ×ØÑ ÁÒØÖØ Ò " ÁÒØÖØ Ò

which is planned for obtaining ËÝ×ØÑ $ and + ﬂoats within the duration of +

$ÙÒØ ÓÒ & " ÁÒØÖØ Ò "

;2)ËÍ Ë ¾, which is planned for obtaining (second year’s quarter). + requires that both

ÙÒØ ÓÒ ¾ ËÝ×ØÑ $ÙÒØ ÓÒ ¿ ËÍ Ë ¿ ËÙ×Ý×ØÑ ËÙ×Ý×ØÑ " ÓÑÔÐØ

ËÝ×ØÑ $ and ;3) IEEE,which and be in their states.

ÙÒØ ÓÒ ) ËÍ Ë & ÁÒØÖØ Ò " ËÍ Ë ¿

is planned for obtaining ËÝ×ØÑ $ ; and 4) , When + ends, the third SB— —is ÙÒØ ÓÒ )

which is the final build, i.e., the complete delivered system, completed, exhibiting ËÝ×ØÑ $ . ÙÒØ ÓÒ× which has all five required ËÝ×ØÑ $ . In this example, each SB is planned for obtaining specific

The ÚÐÓÔ Ò process starts on January 1, 2009 and ends functions in a noncumulative manner, i.e., it is not based on an

on December 31, 2009. It begins with two simultaneously incremental strategy.

ÚÐÓÔ Ò ÁÒØÖØ Ò "

starting processes: ÚÐÓÔ Ò ËÙ×Ý×ØÑ and + + is planned to be executed as soon as

ÁÒØÖØ Ò "

ËÙ×Ý×ØÑ . The latter takes longer and ends at the end of the + ends, at the end of the third year’s quarter,

ÁÒØÖØ Ò

ﬁrst year’s quarter. When ÚÐÓÔ Ò ËÙ×Ý×ØÑ ends, it as denoted byProof the horizontal dashed line. + +

ÓÑÔÐØ " ËÙ×Ý×ØÑ× ÓÑÔÐØ

transforms ËÙ×Ý×ØÑ to its state, and when start requires that all three be .When

ËÙ×Ý×ØÑ ÁÒØÖØ Ò " ËÍ Ë &

ÚÐÓÔ Ò ËÙ×Ý×ØÑ ends, it transforms to its + + ends, the ﬁnal SB— —is

ÓÑÔÐØ ËÝ×ØÑ $ÙÒØ ÓÒ×

ÓÑÔÐØ state. The states of both of these subsystems completed, exhibiting all ﬁve .

ÁÒØÖØ Ò ÚÐÓÔ Ò ËÙ¹

are required for ÁÒØÖØ Ò + to start. + Fig. 3 presents the in-zoomed view of

ÚÐÓÔ Ò ËÙ×Ý×ØÑ "

starts simultaneously with ,atthe ×Ý×ØÑ , which is planned to be executed at the beginning ËÙ×Ý×ØÑ

end of the ﬁrst year’s quarter, as they are both related to of the ÚÐÓÔ Ò process shown in Fig. 2.

"ÓÑÔÙØÖ Ä×Ö ÌÖÖ

ÚÐÓÔ Ò ËÙ×Ý×ØÑ in a ﬁnish-to-start relationship, as consists of a ,a ,anda . The pro- ÚÐÓÔ Ò ËÙ×Ý×ØÑ

denoted by the horizontal dashed line. When ÁÒØÖØ Ò + cess of begins with the simultaneous

ËÍ Ë ½ "ÓÑÔÙØÖ ÚÐÓÔ Ò Ä×Ö ÚÐÓÔ Ò ends, the ﬁrst SB— —is completed, having both start of together with . 6 IEEE SYSTEMS JOURNAL

B. OPM Notation for Model-Based Project Planning The OPM-based project–product plan was modeled using OPCAT [17]. The model is strictly based on the text in Fig. 4, and deliverables were added based on this text. The activities identiﬁed in the speciﬁcation are OPM processes in the model, whereas all the inputs and outcomes of these activities are

OPM objects. The ÒØ× ËØ (the human enablers) and the

ÁÒ×ØÖÙÑÒØ× ËØ (the nonhuman enables) were also modeled based on the text. The duration of each task is the duration of the corresponding task (leaf-level process), which is assigned in OPCAT using the minimum activation time attribute of the process. The activation time units can be set to milliseconds, seconds, minutes, hours, days, months, or years. Following

Fig. 3. PPLM plan ÚÐÓÔ Ò ËÙ×Ý×ØÑ . Fig. 4, the activation time for each process was deﬁned in weeks. For the sake of simplicity, budget is not included in the

The end of "ÓÑÔÙØÖ ÚÐÓÔ Ò transforms the state of current model as a consumed input, but it can be readily added.

Ö ÓÑÔÐØ Ä×Ö ÚÐÓÔ Ò

"ÓÑÔÙØÖ from to .When The model follows the guidelines of the methodology part of

ÌÖÖ ends, it yields Ä×Ö ,justas is generated when OPM. It starts with a top-level process at the System Diagram

Ä×Ö ÚÐÓÔ Ò ends. (SD, top-level OPD) of the model, representing the system’s

The timing of the entire ÚÐÓÔ Ò ËÙ×Ý×ØÑ process in function, which, in our case, is the execution of the entire Fig. 3 is coherent with the upper level presented in Fig. 2. The project. The model then contains decomposition of the system current time of the project, which is indicated in Fig. 2 by the hierarchy using OPM reﬁnement mechanisms, primarily in- dashed red line denoted by NOW, is also compatible with the zooming, following the top-to-bottom ordering of a sequence upper level of this PPLM model. of subprocesses within an in-zoomed process. The entire project is modeled through concurrent hierar- The entire project is modeled through concurrent hierarchi- chical decomposition of processes and objects involved in cal decomposition of processes and objects involved in these these processes as inputs, enablers, or deliverables. Using processes as resources (inputs or enablers) or deliverables. this approach, the model ultimately contains 1) the activities Following this approach as noted, the PPLM model ultimately and tasks, which are processes at various detail levels (task contains 1) the activities, which are processes at various detail is the most detailed nondecomposable process), required for levels from the entire project down to the task level, required for completing the product; 2) the artifacts (model-based deliver- completing the product; 2) the deliverables created during the ables) created during the project process; and 3) the different project execution process; and 3) the various resources required resources, including agents (humans), budget, and instruments for the project execution. (facilities and other inanimate resources). Embedding this in- Abstraction provides for aggregating processes in nodes formation consistently in the same unifying model yields all the while creating the model in a hierarchical manner, catering structural relations—relations between any two objects—and to the human limited channel capacity [22] and maintaining procedural relations—relations between any object and any Miller’s rule of 7 ± 2[23]. process.

C. Modeling the UAV OPM-Based Project Plan IV. MODEL-BASED PROJECT–PRODUCTIEEEPLAN Following the basic OPM modeling guideline, the top- A. UAV Project Plan

level process in the system diagram (SD) (see Fig. 5),

Î ÈÖÓØÓØÝÔÚÐÓÔ Ò ÁÒØÖØ Ò As a case in point, we consider a project of developing i.e., Í & , represents the a simpliﬁed unmanned aerial vehicle (UAV) by an imagi- entire project process. It is assigned a maximum dura-

nary New Millennium Aerospace (NMA), Inc., a government- tion of 90 weeks. Three agents (human resources) carry .ÓÚÖÒÑÒØ ÒØ× ËØ

contracted leading UAVs manufacturer. A rough speciﬁcation out this process: ÆÅ ÒØ×ËØ, ,

Ò Ò .$ ÈÝÐÓ

of the UAV concept [21] was used as the basis for the UAV and "" ÒØ× ËØ. and are parts of

Î ÈÖÓØÓØÝÔ development, which focuses on the vehicle, whereas the pay- Í Proof, the deliverable of the project. load is provided by the government as modiﬁed government- When creating the SD using OPCAT, a paragraph of equiva- furnished equipment (GFE), and the engine is supplied by an lent natural language sentences, which is called object process established commercial company (ECC) under a subcontract. language (OPL), is automatically generated. This is presented The UAV speciﬁcation, which is given in Fig. 4, contains a in Fig. 6.

description of 23 tasks necessary to develop the UAV, including Fig. 7 presents SD1—the second-level OPD of the model—

Î ÈÖÓØÓØÝÔ ÚÐÓÔ Ò ÁÒØÖØ Ò the dependencies between tasks and their durations. Each task in which Í & is detailed (“job”) description is underlined the ﬁrst time it is mentioned, using the in-zooming reﬁnement mechanism that is built into and the task ID and its normal duration in weeks are given in OPM. At each detail level, the execution order of subprocesses parentheses. within the in-zoomed process starts at the top of that process SHARON AND DORI: PROJECT–PRODUCT MODEL–BASED APPROACH TO PLANNING WORK BREAKDOWN STRUCTURES 7

Fig. 4. Basic speciﬁcation of the UAV development concept.

Î ÈÖÓØÓØÝÔ ÚÐÓÔ Ò Fig. 5. OPD of the top-level SD of Í &

ÁÒØÖØ Ò . and proceeds downward since the time line in an OPM model Fig. 6. Automatically generated OPL paragraph of the OPD in Fig. 5. is vertical, ﬂowing from top to bottom. IEEE

Some of the processes in SD1 (see Fig. 7), e.g., Ú ÓÒ ×

"/ÓÙØ ËÓØÛÖ ÚÐÓÔ Ò ËÓØÛÖ ÚÐÓÔ Ò Ð ÚÖÝ & and , are already process ends, can start; as it is linked

tasks, i.e., simple leaf-level atomic processes, as indicated by with a ﬁnish-to-start relationship, one of the outcomes of the

Î ËÔ Ý Ò ËÓØÛÖ ËÔ ¬Ø ÓÒ

their thin ellipse contours. Other processes, which are indicated Í process is the object.

ÛÖ ËÔ ¬Ø ÓÒ

by thick ellipse contours, are nonsimple and are further reﬁned ËÓØ is assigned the role of document. This

ÛÖ ÚÐÓÔ Ò

in subsequent lower level OPDs. document is instrument to the ËÓØ process.

ÛÖ ÚÐÓÔ Ò

In Fig. 7, there are two pairs of processes modeled with Therefore, ËÓØ cannot start before this de- Î ËÔ Ý Ò

ﬁnish-to-start relationships (denoted by a dashed line between liverable is generatedProof by the Í process. The

ÛÖ ÚÐÓÔ Ò ÍÎËÔ¹ ËÓØÛÖ ÚÐÓÔ Ò ËÓØÛÖ ÔÔÖÓÚÐ

ellipses): ËÓØ immediately follows outcome of is , an ob-

ÁÒØÖØ Ò Ì×Ø Ò

Ý Ò ,and & immediately follows ject, which is assigned the role of a gate. This gate is an

"/ÓÙØ ÁÒØÖØ Ò Ì×Ø Ò

Ú ÓÒ × Ð ÚÖÝ & . Two processes in the same instrument of the & process. Therefore,

Ì×Ø Ò

figure are modeled using a PPLM floating start-and-finish re- ÁÒØÖØ Ò & cannot start before this deliverable is

/ Ð ÚÐÓÔ Ò ËÓØÛÖ ËÓØÛÖ ÚÐÓÔ Ò

lationship: The timing of Î and of generated by .

ÈÝÐÓ Ò Ò ÈÝÐÓ Ò Ò ÚÐÓÔ Ò

ÚÐÓÔ Ò ﬂoat within the timing of and The & process can start fol-

ÍÎ ËÔ Ý Ò Ò Ò

ÚÐÓÔ Ò . lowing the start of , provided that the

ÎÈÖÓØÓØÝÔ ËÔ ¬Ø ÓÒ Ò Ò ËÔ Ý Ò

The ﬁrst process in the sequence of Í object has been created by the

ÁÒØÖØ Ò ÍÎ ËÔ Ý Ò ÈÝÐÓ ËÔ ¬Ø ÓÒ ÚÐÓÔÑÒØ & is . When this process. Similarly, is an outcome of

8 IEEE SYSTEMS JOURNAL

Î ÈÖÓØÓØÝÔ ÚÐÓÔ Ò ÁÒØÖØ Ò

Fig. 7. OPD of the Í & , in-zoomed.

ÝÐÓ ËÔ Ý Ò ÈÝÐÓ Ò Ò ÚÐÓÔ Ò

È .Forthe and This is so since constructing all the relationships between the

Ð Ø × ËØ .ÓÚÖÒÑÒØ

process to start, "" ÒØ $ and 23 leaf-level processes and the objects to fully account for Ð Ø × ËØ

ÒØ $ must be also available. the textual speciﬁcation in Fig. 4 captures the entire project

"/ÓÙØ

When the Ú ÓÒ × Ð ÚÖÝ & process ends, the speciﬁcation.

Ì×Ø Ò ÁÒØÖØ Ò & process can start, as they are linked Since all the entities and their relations are represented in

with a ﬁnish-to-start relationship. Starting the ÁÒØÖØ Ò & the project plan model, automatic procedures can be devised to ×Ø Ò Ì process requires also that the objects linked to it generate familiar project views, including Gantt chart, activities

as instruments be available. These include four components, network plan, critical path, and WBS. In what follows, we

ÁÒØÖÒÐ $ ØØ Ò× ËØ ËØÖÙØÙÖÐ ÖÖÑ

namely, Ú ÓÒ ×, , present the potential for automatic extraction of the WBS

ÝÔ ÈÓÛÖ ËÝ×ØÑ ËÓØÛÖ

ÈÖÓØÓØ ,and , as well as one gate, planning representation from the OPM model and provide new

ÖÓÚÐ ÁÒØÖØ Ò Ì×Ø Ò

ÔÔ . & is the last process within OPM model-based representations.

Î ÈÖÓØÓØÝÔ ÚÐÓÔ Ò ÁÒØÖØ Ò

Í & . When it ends,

Î ÈÖÓØÓØÝÔ .$ ÈÝÐÓ Í is generated, and it contains the

V. C LASSICAL WBS AND OPM-BASED WBS

ÈÝÐÓ Ò Ò ÚÐÓÔ Ò and Ò Ò as outcomes of & . The abstraction of the original 23 processes (seeIEEE Fig. 4) into The WBS was initially developed as a product-oriented aggregating “parent” processes was based on planning practice. family tree by the U.S. Department of Defense, which, in 1968, Each parent process is a logical cluster in the hierarchy of issued the “Work Breakdown Structures for Defense Material the project plan model. The processes in each cluster appear Items” [9]. WBS captures the work content within a project’s in the same OPD, which is a node in the OPD set tree. scope in a hierarchical structure and is usually accompanied Different planners would probably suggest somewhat different with a dictionary describing each WBS element. The devel- hierarchical process decompositions (where a process decom- opment of the WBS model involves breaking the overall work position is equivalent to task clustering). Similarly, different involved in a project into progressively smaller pieces, down decompositions of hammocks would be defined by different to the levelProof of “work packages.” These work packages are the planners using a Gantt chart. The point to note is that the elements for which required resources, budget, and duration “real” model is the flattened all-inclusive model at the most can be estimated with relative confidence. The classical WBS detailed level. Clustering into logical groups helps humans, model is usually developed before identifying the dependencies who are subject to cognitive limited channel capacity, to grasp between activities and estimating their durations. the “big picture.” This decomposition is not necessarily iden- Figs. 8 and 9 show automatically extracted process WBS tical in all the models of the same system, but as long as diagrams for two intermediate-level processes using the OPM

the original 23 processes contained in the original UAV spec- unfolding mechanism. The ﬁrst process WBS is for the Î ËÔ Ý Ò

iﬁcation are identical, and their dependence relationships are Í process (see Fig. 8), and the second is for

Ì×Ø Ò maintained the same, all these decompositions are acceptable. ÁÒØÖØ Ò & (see Fig. 9). They look like common SHARON AND DORI: PROJECT–PRODUCT MODEL–BASED APPROACH TO PLANNING WORK BREAKDOWN STRUCTURES 9

A deliverable of an OWBS can be a mixed deliverable—a deliverable to at least two processes—of which at least one is internal and another is external. Like internal deliverables, mixed deliverables are solid, but they are placed at the bottom of the OWBS view, along with the external deliverables.

We demonstrate this by the six deliverables produced by Î ËÔ Ý Ò

Fig. 8. Automatically extracted process WBS for Í . Î ËÔ Ý Ò

subprocesses of the Í node in the OWBS at

ÖÓÚÐ Î/ Ð

the top in Fig. 6: ÊÕÙ ÖÑÒØ× Ó ÙÑÒØ ÔÔ ,

ÝÓÙØ ËÓØÛÖ ËÔ ¬Ø ÓÒ .$ Ú ÓÒ × × Ò ÈÝÐÓ

Ä , , ,

Ò Ò ËÔ ¬Ø ÓÒ ÊÕÙ ÖÑÒØ× Ó Ù¹

ËÔ ¬Ø ÓÒ ,and . ÖÓÚÐ

ÑÒØ ÔÔ is an internal deliverable, as it is generated Î

and required only by internal processes—subprocesses of Í

ÊÕÙ ÖÑÒØ× Ó ÙÑÒØ ÔÔÖÓÚÐ ËÔ Ý Ò . is therefore

marked by a solid rectangle and placed at the ﬁrst level un-

ÈÝÐÓ

der the node’s subprocesses. Ò Ò ËÔ ¬Ø ÓÒ and

ËÔ ¬Ø ÓÒ

Ì×Ø Ò Fig. 9. Automatically extracted process WBS for ÁÒØÖØ Ò & . are mixed deliverables; they are required by internal processes, but based on the PPLM model, they are also

inputs to external processes. Being mixed deliverables, Ò Ò

ÈÝÐÓ ËÔ ¬Ø ÓÒ classical hierarchical WBS views, except that the nodes, which ËÔ ¬Ø ÓÒ and are solid rectangles,

are OPM processes, are denoted by ellipses instead of the but they are placed at the bottom of the OWBS view together

/ Ð ÄÝÓÙØ

commonly used rectangles. In both WBS views, each ellipse with the remaining three deliverables, namely, Î ,

ÛÖ ËÔ ¬Ø ÓÒ .$ Ú ÓÒ × × Ò represents a process in the hierarchy, and it contains informa- ËÓØ ,and , which are tion regarding the process duration, allocated resources, and external, as indicated by their blank rectangles. budget, if inserted into the model. The resources (not shown in these views for simplicity) are denoted by rectangles—objects VI. CONCLUSION AND FUTURE WORK

that are related to the various processes—as members of the ÁÒ×ØÖÙÑÒØ× ËØ ÒØ× ËØ for human resources or of the for Model-based project planning is part of the joint PPLM ap- all other types of resources, except for budget, which has its proach. The joint project–product OPM-based model combines own dedicated object, as argued earlier. the project’s activities and timing with the product’s structure in While the process WBS may be sufﬁcient for classical a single conceptual model. This integrated conceptual model si- project management, the PPLM approach advocates the plan- multaneously expresses the function, structure, and behavior of ning and control of the correspondence between the project the two intertwined domains—the project and the product—via processes and the product deliverables. To this end, we suggest the same ontological foundations, making it possible to directly a new PPLM view, object WBS (OWBS), which adds the and precisely link entities in one domain to those in the other, involved objects (deliverables) to the hierarchy of the conven- thereby attaining a holistic view of the highly complex and tional process WBS views. The OWBS view is valuable as intricate project–product ensemble. It provides the ability to it provides a clear picture of the deliverables and how they gain deep comprehension of the project–product supersystem ﬂow among the planned WBS process nodes; it enables the and to derive various common project management views from comprehension of dependencies between nodes through the the unifying PPLM model of this complex ensemble. WBS decomposition in terms of deliverables. Collaboration of relevant systems engineering and project

A partial OWBS view is presented in Fig. 10 forIEEE the same management stakeholders is essential in order to provide the Î ËÔ Ý Ò

Í process shown in Fig. 8. A complete OWBS most reliable information to be included in the model. This

Ì×Ø Ò view is presented in Fig. 11 for the same ÁÒØÖØ Ò & model provides for assigning speciﬁc functionalities into the process shown in Fig. 9. Both Figs. 10 and 11 contain only two different SBs at early design stages, when the uncertainty is levels, since they were produced for nodes which are one level high, thereby mitigating project risks. The depth and range up from the task level, the lowest (leaf) level in the OPM-based across time line, which is contained in the model, is up to the UAV project plan model. planner to decide on. Therefore, the plan can be assessed and These internal processes are placed horizontally beneath updated as necessary, even for sprints of Agile development. the parent process and are connected with the parent by The newlyProof suggested GPC, the SB approach, and the OWBS an aggregation-participation link (the solid triangle). Beneath view presented in this paper are valuable for all stakehold- each one of these internal processes are the exclusively in- ers of the project plan since they provide a clear picture of ternal deliverables of that process, along with their links to the deliverables and how they ﬂow among the planned WBS the process. An exclusively internal deliverable is a deliv- process nodes. In particular, the OWBS view enables the com- erable that is required only between internal processes. All prehension of dependencies between nodes through the WBS the other deliverables are external—they are (also or only) decomposition in terms of deliverables. required by processes other than the process at the top of the The various consistent views extracted from the model- OWBS. External deliverables are placed at the bottom of the based project model enable the project manager to focus on OWBS view. advancing the completion of the required deliverables rather

10 IEEE SYSTEMS JOURNAL Î Fig. 10. Automatically extracted partial OWBS for Í Specifying.

IEEE

Ì×Ø Ò Fig. 11. Automatically extracted partial OWBS for ÁÒØÖØ Ò & . than on performing processes that are not necessarily linked to and other types of product development, to integrated anticipated outcomes. project–productProof teams (IPPTs). The IPPT will use the PPLM Future work includes automating the derivation and update model as a common blueprint, a single integrated model that of the various project views—WBS, Gantt, Program Evaluation supports the work performed by all the IPPT members. More- and Review Technique, etc.—from the PPLM model source, over, since the complete PPLM model includes the organi- which we recommend maintaining and using as the single zational personnel involved in the development with explicit common blueprint of the project and the product or service relationships to processes and milestones, organizational infor- system it is designed to deliver. mation can also be extracted from the model. This includes, for Another research avenue is the extension of integrated prod- example, organizational design structure matrices for managing uct teams, which are widely used as a means for managing the complex relationships of the IPPTs and their members to the complexity during large-scale systems development in Lean product and the project information. SHARON AND DORI: PROJECT–PRODUCT MODEL–BASED APPROACH TO PLANNING WORK BREAKDOWN STRUCTURES 11

REFERENCES [21] O. de Weck and J. M. Lyneis, “MIT ESD.36 system project management course assignments,” MIT, Cambridge, MA, USA, 2008. [1] S. C. Cook, J. E. Kasser, and T. K. J. Ferris, “Elements of a framework [22] R. E. Mayer, Multimedia Learning. Cambridge, MA, USA: Cambridge for the engineering of complex systems,” presented at the Proc. 9th Univ. Press, 2001. ANZSYS Conference, Systems in Action, Melbourne, Australia, 2003, [23] G. Miller, “The magical number seven, plus or minus two: Some limits Paper 3 000 079. on our capacity for processing information,” Psychol. Rev., vol. 63, no. 2, [2] S. Eppinger and V. Salminen, “Patterns of product development interac- pp. 81–9, Mar. 1956. tions,” in Proc. ICED, Glasgow, U.K., Aug. 21–23, 2001, pp. 283–290. [3] E. D. Fischer, Ed., Workflow Handbook. Lighthouse Point, FL, USA: Fes Inc., 2005. [4] A. Jaafari, “Modeling of large projects,” in The Wiley Guide to Managing A. Sharon received the B.Sc. degree in mechan- Projects, P. W. G. Morris and J. K. Pinto, Eds. Hoboken, NJ, USA: ical engineering, the M.Sc. degree in industrial Wiley, 1994, ch. 12, pp. 288–320. design, and the Ph.D. degree in information manage- [5] A. Shenhar and D. Dvir, “How projects differ and what to do about ment engineering from Technion–Israel Institute of it,” in The Wiley Guide to Managing Projects,P.W.G.Morrisand Technology, Haifa, Israel, in 1992, 1997, and 2010, J. K. Pinto, Eds. Hoboken, NJ, USA: Wiley, 2004, ch. 50, pp. 1265–1286. respectively. [6] A. Shenhar and D. Dvir, Reinventing Project Management. Boston, MA, Her professional career spans the areas of me- USA: Harvard Business School Press, 2007. chanical engineering, programming, systems engi- [7] A. Sharon, D. Dori, and O. de Weck, “Project management vs. systems neering, systems engineering management, leading engineering management: A practitioners’ view on integrating the project systems engineering methodologies development, and product domains,” Syst. Eng., vol. 14, no. 4, pp. 427–440, Dec. 2011. and robotic systems development. Her research in- [8] K. F. Levy, G. L. Thompson, and J. D. Wiest, “The ABCs of the critical terests include conceptual modeling of complex systems, systems engineering path method,” in Harvard Business Review. Boston, MA, USA: Harvard management, and combining systems engineering with project management in Business School Publishing, 1963, #63508. large-scale complex project–product systems. [9] Work Breakdown Structures for Defense Material Items, Mil Std. 881- Dr. Sharon is a member of the Executive Committee of the Israeli Chapter of 1968, 1968. the International Council on Systems Engineering. [10] PMBoK, Project Management Institute, Newtown Square, PA, USA, 2008. [11] A. Sharon, V. Perelman, and D. Dori, “A project-product lifecycle management approach for improved systems engineering practices,” presented D. Dori (SM’99) received the B.Sc. degree in indus- at the Proc. INCOSE 18th Annual International Symposium, 6th Biennial trial engineering and management from Technion– European Systems Engineering Conference, Utrecht, the Netherlands, Israel Institute of Technology, Haifa, Israel, in 1975, 2008, Paper 8.2.2. the M.Sc. degree in operations research from Tel [12] A. Sharon, D. Dori, and O. de Weck, “Is there a complete project plan? Aviv University, Tel Aviv, Israel, in 1981, and the A model-based project planning approach,” presented at the Proc. 19th Ph.D. degree in computer science from Weizmann Annual International INCOSE Symposium, Singapore, 2009, Paper 1.3.2. Institute of Science, Rehovot, Israel, in 1988. [13] J. Stark, Product Lifecycle Management: 21st Century Paradigm for Prod- He is currently a Visiting Professor with the En- uct Realisation. London, U.K.: Springer-Verlag, 2004. gineering Systems Division, Massachusetts Institute [14] D. Dori, Object-Process Methodology—A Holistic Systems Paradigm. of Technology, Cambridge, MA, USA, where he Berlin, Germany: Springer-Verlag, 2002. lectures on a regular basis. He is also currently the [15] D. Dori and M. Choder, “Conceptual modeling in systems biology fosters Harry Lebensfeld Chair of the Industrial Engineering and the Head of the Enter- empirical findings: The mRNA Lifecycle,” PLoS ONE, vol. 2, no. 9, prise System Modeling Laboratory with the Faculty of Industrial Engineering p. e872, Sep. 12, 2007. and Management, Technion–Israel Institute of Technology, Haifa, Israel. His [16] J. Somekh, M. Choder, and D. Dori, “Conceptual model-based systems research interests include model-based systems engineering, conceptual model- biology: Mapping knowledge and discovering gaps in the mRNA tran- ing of complex systems, systems architecture and design, software and systems scription cycle,” PLoS ONE, vol. 7, no. 12, p. e51430, Dec. 2012. engineering, and systems biology. He invented and developed object–process [17] D. Dori, I. Reinhartz-Berger, and A. Sturm, “Developing complex sys- methodology, the emerging ISO 19450 Standard. He has authored or edited five tems with object-process methodology using OPCAT,” in Proc. 22nd ER books and over 200 journal and conference publications and book chapters. Int. Conf. Conceptual Modeling, Chicago, IL, USA, Oct. 13–16, 2003, Prof. Dori is a Fellow of the International Council on Systems Engineering, a pp. 570–572. member of Omega Alpha Association (International Honor Society for Systems [18] A. Blekhman, D. Dori, and R. Martin, “Model-based standards author- Engineering), a Fellow of the International Association for Pattern Recognition, ing,” presented at the Proc. 21st INCOSE International Symposium, and a Senior Member of the Association for Computing Machinery. He was Denver, CO, USA, Jun. 19–23, 2011, Paper 245. a Chairperson of nine international conferences or workshops. He was an [19] Software Development and Documentation, Mil. Std. 498 AMSC N7069- Associate Editor of the IEEE TRANSACTION ON PATTERN ANALYSIS AND 1994, 1994. IEEEMACHINE INTELLIGENCE and is currently an Associate Editor of Systems [20] Department of Defense Instruction, DODI 5000.02, 2008. Engineering. Proof