Model-Based Project-Product Lifecycle Management and Gantt...

For Peer Review

> Manuscript ID SYS-16-056 <

1

Abstract—Systems engineering (SE) and project management

(PM) are two complementary disciplines that aim at achieving a

common goal. In order for systems engineers and project

managers to communicate efficiently, there is a need for a

common language that balances system performance, quality,

stakeholder expectations and needs, cost, and schedule. We use

Object Process Methodology (OPM) as the basis for Project-

Product Lifecycle Management (PPLM), where SE and PM are

complementary parts of an overarching system.

Since the project plan is one of the first artefacts that both SE

and PM professionals should agree on, we compared Gantt chart,

a commonly used method, and a PPLM project plan. We present

a three-stage comparative research, investigating how differences

between a Gantt chart and an OPM model based PPLM project

plan are perceived by mid-career systems engineers, who were

graduate students in systems engineering academic programs.

The outcomes indicate that the comprehension of information

contained in the OPM model-based PPLM project plan is more

easily grasped than the same information presented via the Gantt

chart. The results suggest that PPLM has the potential to better

clarify the intricate relationships between SE and PM involved in

developing systems through projects. It can enable better

understanding and communication between systems engineers

and project managers, thereby improving decision-making,

project outcomes, and product performance.

Index Terms—Project Plan, Model-Based Systems

Engineering, Project-Product Lifecycle Management, Systems

Engineering, Project Management, Object-Process Methodology,

Project Management Tools and Techniques

I. INTRODUCTION

YSTEMS Engineering (SE) and Project Management

(PM) are two tightly intertwined domains. Indeed, put

simply, project is the process through which a system or

product start their lives. Not only is this observation

straightforward, as expressed in at least two prominent SE

handbooks. The first is the SE Handbook of the International

Council on Systems Engineering (INCOSE) [1], which

provides framework and guidelines for SE and addresses the

strong relationships between SE and PM. The second is the

NASA Systems Engineering Handbook [2], over one third of

which is devoted to "management issues in systems

engineering". Indeed, indicated in this Handbook is the fact

that it covers topics that are also considered to be in the

domains of Project Management/Program Control, "reflecting

the unavoidable connectedness of these three domains."

Along these lines, the INCOSE SE Handbook includes

elements of planning, scheduling, reviewing, and auditing

under Systems Engineering process. The Handbook calls for

including the Systems Engineering Management Plan (SEMP)

and the Systems Engineering Master Schedule (SEMS) as

systems engineering deliverables. In doing so, the SE

Handbook further underscores the tight links and

dependencies between the PM and the SE domains. While PM

methods have traditionally focused on scheduling, budgeting,

and scope management, SE emphasizes the management of

the combined project-product ensemble and issues related to

the technologies of the product to be ultimately delivered by

the project.

The literature has been struggling with delineating the

border between the SE and PM domains. For example, the

INCOSE SE Handbook [1] indicates that "although there are

some important aspects of PM in the SE process, it is still

much more of an engineering discipline than a management

discipline. It is a very quantitative discipline, involving trade-

off, optimization, selection, and integration of the products of

many engineering disciplines." [1]. Underlying this statement

is the tacit assumption that management is primarily

qualitative while engineering is primarily quantitative. More

specifically, it implies that PM is less "quantitative" than SE.

Yet, PM does involve the quantities of time and budget, while

SE does have managerial aspects that are not too far from

those of PM [3], [4]. Perhaps a better distinction would be that

PM has traditionally been focusing on the "iron triangle" of

scheduling, budgeting, and scope management, while SE

emphasizes the management of the project-product ensemble.

Over the past few years, the International Council On

Systems Engineering (INCOSE) and the Project Management

Institute (PMI) have made efforts to reach out towards each

other's practitioners. The leaders of INCOSE and PMI believe

that a cultural barrier between SE and PM exists, but can and

must be overcome. Therefore, these organizations started

working together, hoping to foster a collaborative approach for

the benefit of their members. This cooperation produced a

whitepaper highlighting four key elements to reduce

unproductive tension between program managers and system

Model-Based Project-Product Lifecycle

Management and Gantt Chart Models:

A Comparative Study

Amira Sharon

Technion, Israel Institute of Technology

Haifa, Israel

Dov Dori

Technion, Israel Institute of Technology

Haifa, Israel

S

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


2

engineers and support the integration of these roles [5].

On the PMI side, there are initiatives of integrating SE and

PM, calling for exploring the idea of using systems

engineering in project management and the complementary

aspects of SE and PM [6]. INCOSE offers a project manager’s

guide to systems engineering measurement for project success,

supported by the organization’s measurement working group

[7].

Over the last years, some books have been offering ways to

deal with the critical relationships and interconnections

between PM and SE, describing how SE and PM can be

integrated in order to streamline project workflow, improving

cost, schedule, and technical performance [8], [9], [10].

The need to fill the gap between SE and PM may be a result

of history and tradition of people coming from different

backgrounds—management on one hand and engineering on

the other hand—who cope with the same problem of designing

products and systems, but emphasize different aspects of this

problem. Specifically, PM focuses on the work required in the

project, whereas SE is concerned with the SE efforts needed

and the performance of the resulting system or product.

Nevertheless, the managerial methods and tools that systems

engineers use originate from the same arsenal that project

managers use. These methods include Work Breakdown

Structure (WBS) [11], Product Breakdown Structure (PBS)

[12], Reliability, Availability, Maintainability (RAM) [13],

Critical Chain Project Management (CCPM) according to the

Theory of Constraints (TOC) [14], resource scheduling [15],

procurement techniques [16], and risk management methods

[17], [18]. Other more traditional and commonly used

methods are Earned Value Method (EVM) [19], [20], Design

Structure Matrix (DSM) [21], System Dynamics (SD) [22],

[23], Critical Path Method (CPM)/Program Evaluation and

Reviewing Technique (PERT), and Gantt chart [24].

Among the PM methods, which vary in terms of their

objectives and applications, Gantt chart is probably the most

widely used method for SE. Graphically, a Gantt chart

comprises horizontal scheduling bars with time flowing from

left to right, allowing for both planning and tracking of project

schedule. In its original form [25], invented in the early

1900's, roughly forty years before PERT and CPM, the Gantt

chart showed the timing of tasks without specifying

relationships among them. Constraining relationships between

tasks, such as start-to-start and finish-to-start, were added only

in the late 1990's, making it possible to view and understand

the impact of a single task delay on the entire project duration.

Indeed, in its latest form, Gantt charts are used also for CPM-

based project analysis, where software tools extend the

network model representation.

Model-based approaches for designing the product are

already widely used within SE practice, but the managerial

aspects of SE still benefit from using mostly traditional PM

methods. A new initiative that has attempted to resolve this

dichotomy is the Project-Product Lifecycle Management

(PPLM) research [26], [27], [28], [30], [31]. PPLM calls for

construction and deployment of an integrated comprehensive

product-project model. The PPLM framework integrates the

project domain with the product domain via a shared ontology

that explicitly relates project entities to product entities within

a unifying frame of reference, utilizing Object Process

Methodology (OPM) [29] as the underlying conceptual

modeling paradigm and language. This is the context within

which this research has been conducted.

OPM is one of the six systems engineering methodologies

recognized by INCOSE [32]. OPM is currently in the process

of becoming an ISO 19450 standard and the basis for model-

based enterprise standards [33], [34]. It is a formal yet

intuitive paradigm for systems architecting, engineering,

development, lifecycle support, and evolution. OPM has been

used for modeling natural [35], [36] and artificial complex

systems [37], where artificial ones might comprise humans,

physical objects, hardware, software, regulations, and

information. As its name suggests, the two basic building

blocks in OPM are (stateful) objects—things that exist

(possibly at some state), and processes—things that transform

objects by creating or destroying them, or by changing their

state.

Object-Process Diagram (OPD) is the graphic representation

of an OPM model, which has also an equivalent textual

representation. Tasks in an OPM-based project plan are

modeled as processes, denoted by ellipses, while resources

and deliverables are objects, modeled by rectangles. Objects

can include specifications, drawings, approvals, reports and

other document types, prototypes, simulation and analysis

results, as well as the final system, product, or service—the

ultimate project outcome. Structural links include whole-part

(denoted by a black triangle) connecting a whole to its part(s),

and characterization (black-on-white triangle), connecting an

object with its attribute(s). Specific time-related extensions to

OPM, such as start-finish relations between processes, were

defined as part of the PPLM research. Based on OPM’s

formality, specific OPM-based templates were developed for

modeling of combined project-product plans.

II. RESEARCH POPULATION AND SETTING

The research was conducted on two research groups in three

stages. The first group, which participated in the first stage,

included 24 mid-career systems engineers, who were graduate

students in the Systems Project Management course at the

Systems Design and Management (SDM) program at MIT's

Engineering Systems Division. In the first stage, conducted

during the spring 2008 semester course [38], the research

participants studied different PM methods and practiced them

through targeted homework assignments, along with a specific

number of 3-hour class sessions devoted to each method. All

the participants had prior knowledge of Gantt and OPM from

a previous systems architecture course. In the fifth homework

of the course, the participants were requested to create two

project plan versions by using two different methods: A Gantt

chart model and an OPM model, based strictly on the text

given in former homework.

The second and third research stages were conducted with a

second research group, which included 32 mid-career systems

engineers from companies across Israel with 3-15 years of

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


3

practice, who were graduate students at the Systems

Engineering Masters of Engineering Program at the Technion

– Israel Institute of Technology, during the fall 2009 semester.

The participants in both research groups were introduced to

the PPLM approach during a three-hour lecture session. The

UAV case study, which was the basis for the structured

questionnaires administered to both groups, was familiar to the

MIT (first stage) participants, since it was based on the case

study they had used during the semester and on which their

fifth homework assignment was based. The UAV case study

was new to the Technion (second stage) participants. In order

to familiarize the Technion group with this system, they were

asked to (1) construct a task table from the project description

in a “technological order”, and (2) create the project activities

network plan graph of the type "activity on nodes". These

same two tasks had been assigned to the MIT group as their

second homework. Neither one of the groups received any

guidance regarding modeling with Gantt chart, assuming this

is a common planning tool, of which participants are familiar

with from prior work experience.

The Gantt chart contains a list of activities, which, in OPM

terms, are processes. It is therefore quite straightforward to

construct the process aspect of the OPM model from the Gantt

chart. However, an OPM model is not complete without the

objects that serve in different roles. A subset of these objects

is expressed in the Gantt chart as milestones. In the OPM

model, participants had to add objects of various kinds to the

originally process-only model obtained from translating the

Gantt chart. The PPLM framework includes an objects

typology that classifies the Deliverables (OPM objects), which

are the outcomes of Tasks Execution (OPM processes), in the

combined project-product plan. The objects typology includes

deliverables such as product components, documents related

to derived requirements, approvals, simulations, analyses,

specifications, and other types of reports. Each one of the

deliverables results directly and explicitly from a specific

process in the PPLM model, and is used in a subsequent

process, either as an instrument (usually if it is an informatical

object, which does not change), or as a consumee (usually a

physical object that is consumed by or embedded into a larger

component). The participants were not introduced to the

PPLM objects typology since our goal was to gauge the

“natural” systems engineers approach for adding objects in the

model rather than enforcing our objects typology. The analysis

of the PPLM models produced by the participants was based

on classifying the objects contained in each model according

to the typology, with each object classified into a single type.

The participants in the third research stage were the same

participants as the ones in the second stage, namely the 32

mid-career systems engineers who were graduate students at

the systems engineering program at the Technion. This stage

was conducted through a class assignment, given after

reviewing the solution of the homework that had been

assigned to the participants a week earlier, serving as the

second stage of our research. The class assignment was given

individually, allotting one hour for its completion. While in

the former two stages the participants were asked to create the

models based on a given text, in the third stage, the

participants were provided with both the "book solution"

PPLM model and the Gantt chart, and we asked to respond to

comprehension questions.

III. RESEARCH QUESTION AND METHODOLOGY

The research question investigated in this study is the

following: What are the differences, if any, between systems

engineers' comprehension of a project plan specified via a

Gantt chart on one hand and a conceptual PPLM model on the

other hand? The comprehension was evaluated according to

the following two aspects: (a) the systems engineers'

expressed comprehension and (b) the systems engineers'

perceived comprehension.

TABLE I

THE THREE STAGES OF THE RESEARCH

Research

Stage

Comprehension

aspect

Population Description Project-

Product combination

Stage 1

expressed

comprehension level

24 mid-

career

systems engineers,

who were

graduate students in

the Systems

Project Manageme

nt course at

the Systems Design and

Manageme

nt (SDM) program at

MIT's

Engineering Systems

Division.

A Gantt

chart and a PPLM

model

were compared

based on

a simplifie

d UAV

OPM model.

The project

and the

product aspects were

combined in

an OPM model with

no underlying

PPLM methodology

guidelines.

Stage 2

expressed

comprehension

level

32 mid-career

systems engineers

who were

graduate students at

the systems

engineering program at

the

Technion.

Same as Stage 1.

Same as Stage 1.

Stage 3 perceived

comprehension

level

Same as in

Stage 2.

Gantt

chart and

a PPLM model

were

compared using a

simplifie

d CT scanner

model as

the case in point.

The project and product

aspects were

combined in an OPM

model

according to the PPLM

methodology.

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


4

The research comprised the three stages as described above

and summarized in Table I in terms of the population, stage

description, and the combination of the project and the product

aspects.

Like other similar studies of descriptive and exploratory

nature with a similar number of participants, percentage and

mean were calculated, followed by t-test for significant

difference comparison [39], [40], [41].

IV. DETAILED DESCRIPTION OF THE RESEARCH METHOD BY

STAGES

Stage 1 was based on a UAV case study [32] – see Fig. 1 (left)

and included a structured assignment designed to explore the

reflections of systems engineers regarding differences between

a project plan expressed by a Gantt chart and the same project

plan expressed by a PPLM model. The participants in the first

(MIT) research group were divided randomly into two equal

subgroups, similar in number of participants. Subgroup 1 was

instructed to model the project by a Gantt chart first, and then

to create the OPM model. Subgroup 2 was instructed to do the

same, but in reverse order. The participants were asked to do

this in a specific order without backtracking, and to document

their reflections on the way they did their project planning.

The assignment was designed to enable analysis by two

comparisons of project plan types between the two subgroups:

(1) The Gantt chart created by Subgroup 1 vs. the Gantt

created by Subgroup 2, and (2) the PPLM model created by

Subgroup 1 vs. the PPLM model created by Subgroup 2. The

reverse plan construction order was aimed at cancelling out

potential differences that might have been related to the order

of plan or model construction.

We did not instruct the participants to model in a specific

methodology. Rather, they could freely use their own judg to

create a model that integrates the project and the product.

Neither group was introduced with the complete PPLM

methodology or the PPLM objects typology. They added

objects in the PPLM model based on their own judgment of

the given text, after or before creating the Gantt model.

There was no one single "correct" solution for the PPLM

model. However, the model had to comply with the following

basic requirements:

- It had to express all the information provided in the

text.

- It had to follow the basic OPM rules, including:

o Starting with a top-level process at the first

System Diagram (SD) of the model,

representing the entire project-system

model.

o Hierarchical decomposing using the in-

zooming mechanism.

o At each level, the processes should be laid

from top downwards, indicating the

technological order of sub-processes.

- It has to contain additional OPM things (objects and

processes), as required for a complete model.

Stage 2 was based on the same UAV case as in Stage 1

(Fig. 1, left), but this time, the participants were the second

(Technion) research group. They were introduced to the

PPLM approach during a three-hour lecture, followed by

homework. In this homework they were given the exact text

given to the first (MIT) group, and were asked to create three

project plan versions by using three different representations:

(1) an Activities Network Plan (AON type) model, (2) a Gantt

chart model, and (3) an OPM model. No particular order of

creating the models was imposed or suggested. The

participants were instructed to document the process they had

undergone while creating each model by recording their

reflections, assumptions, and decisions they had made during

the modeling process.

The research conducted in Stage 3 was designed to answer

the same research question. However, this time, the

examination was elaborated to investigate project and product

aspects when these are integrated according to the PPLM

methodology in a pre-prepared model, as explained below. For

this stage, we used a simplified CT scanner model – see Fig. 1

(right).

The participants were provided with the following models: (1)

a PPLM model, that is, an OPM-based CT scanner model, in

which the project and product aspects were combined

according to the PPLM methodology (see Appendix A), and

(2) A Gantt model of the same project plan (see Appendix B).

Both models were identical in their information content,

except for a few specific differences, which were intentionally

inserted in order to enable us to examine them against our

expected results of the models comparison.

In both models, the given information contained the same

tasks planned for developing and integrating the five planned

development cycles of the CT scanner, which in PPLM

ontology are called system builds (SBs). The objects of the

planned development cycles in the OPM-based model were

represented by equivalent milestones in the Gantt chart. The

participants were given 33 comprehension questions that were

directly related to the project plan, as well as to the product-

based rationale of this project plan. Appendix C presents four

of these questions with their type and rationale. The

participants were asked to answer these questions based on the

Gantt chart model and the PPLM model that were provided to

them. The questions were of three types, designed and

administered in a gradually increasing level of difficulty: (1)

process or task duration questions, (2) general completeness

questions—questions related to the completeness of the PPLM

model or the Gantt chart model, and (3) project-product

completeness questions—questions related to the

completeness of the PPLM model or the Gantt chart model in

terms of cross-relations between the project domain and the

product (system) domain.

The participants answered the questions regarding their

view on the ease of finding the answer to each question in the

Gantt chart and PPLM model using the following scale: (a)

The answer can be easily found in the chart or the model, (b)

The answer can be found in both the Gantt chart and PPLM

model, (c) The answer can be found in the Gantt chart or in

the PPLM model with difficulty, and (d) It is impossible to

find the answer in the Gantt chart or in the PPLM model.

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


5

V. RESULTS AND ANALYSIS

We present the research results and their analysis according

to the three research stages.

A. Results of Stage 1 and their analysis

Since the Gantt chart can be produced easily from the given

text, we expected that the Gantt charts that participants

modeled first would only contain the given tasks and

relationships among them. We also expected that the Gantt

chart produced after modeling the same text in OPM will be

influenced by the OPM model, such that, for example,

clustered processes in the OPM model would become

hammocks in the Gantt chart, while added objects in OPM

would be reflected as milestones in the Gantt chart.

Surprisingly, however, all the Gantt charts produced by the

participants were almost identical, regardless of the order in

which they were designed. They all contained the 23 given

tasks expressed by the problem text: 21 tasks and their

relationships plus the two milestones project start and project

end (both assigned zero duration). Reflections participants

provided on the Gantt chart design process indicated that they

had felt the provided text contained all the required

information for creating the Gantt chart. Therefore, no

assumptions were made nor were data added to the Gantt chart

other than what was given in the text. Some selected

reflections, provided by the participants in this part of the

research, are presented in Appendix D. While no differences

were found among the Gantt charts, the OPM models

participants produced were very different from each other. The

total number of processes ranged from 14 to 31, with the

median being 23, which is the same number of processes in

the text. While this might seem incidental, it does reflect one

aspect of the power of "crowdsourcing." Indeed, most of the

OPM models participants produced contained the 23 tasks

which had been provided in the text. Some of the participants

included abstractions by clustering processes using the OPM

in-zooming mechanism. The total number of objects in the

OPM model ranged greatly, from 2 to 44 objects, with a

median of 21.5. This indicates that the majority of participants

modeled at least 21 objects, as expected, since each one of the

21 processes (which remain after excluding the project start

and project end pseudo-processes) should have at least one

deliverable, otherwise the process does not meet the OPM

definition of process as a thing that transforms at least one

object. Several participants modeled only few objects. The

high number of objects in some of the models was due to the

fact that in these models, objects were not modeled as being

stateful, but rather, each state was taken as a separate distinct

stateless object. For example, instead of having one object

called "Fuselage" with states "designed" and "manufactured",

the model contained two objects—"Designed Fuselage" and

"Manufactured Fuselage".

The standard deviation of the number of objects was 10.6,

almost three times bigger than the standard deviation of the

number of processes, 3.9. This outcome is in accord with the

results presented previously: while there was little difference

in modeling the processes, modeling the object in the OPM

model was much more diversified in terms of the number of

objects modeled.

B. Results of Stage 2 and their analysis

Based on the results of Stage 1, we expected the Gantt charts

designed by the participants in Stage 2 (Technion) to be the

same as in Stage 1, containing the given 21 tasks and their

relationships, plus two milestones – project start and project

end. The results matched our expectations. The participants

did not add to the Gantt charts any information such as

hammocks or additional milestones. As in Stage 1, based on

the reflections provided by the participants, they had

considered the creation of the Gantt chart from the provided

problem text to be straightforward.

The great variability among the OPM models was also

repeated in this stage. The total number of processes varied

between 6 and 32, with the median result again being 23.

Indeed, in most of the cases, as in Stage 1, the OPM models

contained the 23 tasks, which we had provided in the text.

Some participants did not include in the OPM model all the 21

tasks from the Gantt chart. As expected, some of the

participants did not model the first task (project start) and the

last task (project end) as processes, but rather used objects for

modeling them.

The total number of objects in the OPM model varied from 2

to 35, with a median of 20, a very similar result to the one

obtained in Stage 1, where the number of objects ranged from

2 to 44 with a median of 21.5. In cases where more than 20

objects were included in the model, the large number of

objects was again a result of modeling each stateful object as

several separate stateless objects.

C. Results of Stage 3 and their analysis

We quantified the participant responses as follows: (a) The

answer can be easily found in the model – 4 points, (b) The

answer can be found in the model – 3 points, (c) The answer

can be found in the model with difficulty – 2 points, and (d) It

is impossible to find the answer in the model – 1 point. This

grading scheme reflects the notion that (a) is the best situation

and (d) is the worst.

Based on (1), the total grade for each question, QTotal Grade,

in each model was calculated. Each total grade for each one of

the 33 questions is based on the quantity (Count) of a, b, c,

and d found among the 32 participants’ answers.

The total grade for each one of the 33 questions was

analyzed based on paired samples statistics for PPLM and

Gantt. PPLM-based plans scored significantly (p<0.001)

higher (Mean Score=94.7, SE=3.47) than Gantt chart based

plans (Mean Score=77, SE=4.83).

�� = 4�� + 3�� + 2�� +��

� !

��

� !

��

� !

��

� ! (1)

Examining the results for individual questions reveals

significant differences in participants' comprehension between

the PPLM model and the Gantt chart model in more detail.

The results of grades obtained for each one of the 33 questions

separately for the PPLM model and the Gantt chart model are

depicted in Fig. 2. The horizontal axis indicates the question

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


6

number (1 through 33), while the vertical axis indicates the

total grade, calculated according to (1).

For each one of the 33 questions, a T-test comparison was

conducted between the grades obtained for the PPLM model

and for the Gantt chart. There were only six questions, 1, 2, 5,

13, 21, and 23, for which no significant difference was found

between the Gantt chart model and the PPLM model. These

are denoted by circles on the horizontal axis. The questions for

which no significant difference was found matched our

expectations, as detailed in Appendix E. According to Fig. 2,

Q14, 15 and 30 scored more for the Gantt chart model than for

the PPLM model. These results matched our expectations as

well, as detailed in Appendix F. The results for the remaining

24 questions for which a significant difference was found in

favor of the PPLM model are specified and discussed in

Appendix G.

VI. DISCUSSION AND FUTURE RESEARCH

In this three-stage comparative research we investigated how

differences between a Gantt chart project plan, an OPM model

based project plan, and an OPM-PPLM model based project

plan are conceived by systems engineers. In the first and

second stages, the number of entities (tasks and milestones) in

the Gantt chart was 23, which is identical to the number of

tasks in the text provided to the participants. Based on the

participants’ reflections, this correspondence can be explained

by the fact that the text contained the tasks and their

relationships in a straightforward manner, which did not

encourage the participants to question or investigate the plan

deeper. The assignment enabled the coverage of the processes

in both models with only little effort. Based on our

professional experience in the field of project planning, we

suspect that a more profound reason for this is the common

belief that capturing the tasks and their relationships, if

conducted thoroughly and correctly, guarantees the

construction of a “good” project plan.

The diversity of the PPLM models that participants

developed, both within each stage and between Stage 1 and

Stage 2, can be explained as follows. The participants modeled

the processes (which are in the project domain) and the objects

(in the product domain) in the OPM model in a free manner,

as we wanted to gauge the participants’ systems engineering

approach prior to exposing them to a the PPLM methodology.

Modeling the combined project-product plan according to the

PPLM methodology would probably result in models that are

more similar to each other. This can be examined in a test

similar to Stage 3 in several ways: (1) teaching the PPLM

methodology in detail to the participants prior to asking them

to produce the OPM model, (2) providing text that explicitly

contains the objects in addition to the processes, or a

combination of (1) and (2). In Stage 3 we did part of this, as

we generated the models ourselves in accordance with the

PPLM methodology and administered a comprehension

questionnaire on the model provided.

Taking in account all 33 questions asked in Stage 3 of the

research, the PPLM model median grade was about 20%

higher than the Gantt chart model median grade. In 24 of the

33 questions, the perceived comprehension was significantly

higher for the PPLM model than for the Gantt chart, ranging

from 8% to 65% difference, while in three questions the

perceived comprehension was significantly higher for the

Gantt chart than for the PPLM model, ranging from 34% to

56% difference. In six questions, there was no significant

difference between the perceived comprehension of the Gantt

chart model and the PPLM model.

This is a very encouraging result, indicating that, at least for

the examined CT scanner case and the systems engineers’

population we tested, the answers to the comprehension

questions were more easily found by consulting the PPLM

model than by consulting the Gantt chart model. Given that

Gantt charts are commonly used with consensus, and that the

participants became familiar with OPM only one week prior to

getting the researched assignment, we had expected to find the

PPLM model scores close to, or perhaps slightly lower than

the Gantt chart model scores. However, the results we

obtained exceeded our expectations from the PPLM model.

This result may also indicate that OPM is easy to learn, at least

for the purpose of comprehending PPLM models, but not

necessarily also for designing them—this needs to be

investigated separately.

Both ways of creating a project plan – the Gantt chart and

the OPM-based model – are supported by software tools.

Creating the PPLM project plan requires acquaintance with

OPM, so it may take longer, but it enables grasping more new

concepts than tasks and milestones that the Gantt chart

requires. However, the extra effort is supported by using the

in-zooming refinement mechanism that is built into OPM.

This mechanism ensures consistency with upper level OPDs

of the model. As the project and the product evolve over time

throughout the development process, the project plan has to be

updated accordingly to reflect the changes. Unlike in Gantt,

the execution of changes in the PPLM project plan readily

reveals the change impact on the product, since the product

domain objects and , along with their relationships to the

project entities, are inherent in the PPLM model.

The ability to simultaneously express the required information

from both the project and the product domains within a single

integrated model-based framework can potentially lead to a

more reliable project plan, which is less prone to the need for

repeated changes and corrective actions. The increased

robustness of the resulting project plan stems from the need to

make decisions about the project's process order and logic

while explicitly addressing the associated product model.

Change management of the project-product plan is made easy

as the PPLM plan contains the details of the project activities

and their relations to specific product entities. This enables

tracking down product processes or objects that are in

jeopardy, in case some specific project activities are delayed.

This information facilitates the system engineering as well as

the project management by enabling better coping with

changes. This is achieved by following the explicitly modeled

relationships, which are the potential paths of project-product

impacts. Such combined project-product knowledge cannot be

extracted from commonly-used project plans models.

In future work, we propose a unifying OPM-based

underlying PPLM model as the basis for various project

management tools and representations. In their new, model-

based versions, these are guaranteed to be consistent, as they

would be derived from a single common source—the OPM-

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


7

based PPLM model that is updated along the development

process. Moreover, each representation will be enhanced with

information on resources and deliverables gleaned from the

common underlying model, facilitating a shift from activities-

based to deliverables-based project management.

REFERENCES

[1] INCOSE 2004 Systems Engineering Handbook, INCOSE-TP-2003-016-02, Version 2a.

[2] NASA 1995. Systems Engineering Handbook, NASA-SP-6105. SP-6105.

[3] A. P. Sage and W. B. Rouse, Handbook of Systems Engineering and Management. John Wiley and Sons Inc., Hoboken, New Jersey, 2009.

[4] B. S. Blanchard, System Engineering Management. John Wiley and Sons Inc., Hoboken, New Jersey, 2004.

[5] Conforto, Rossi, Rebentisch, Oehmen & Pacenza, Improving the Integration of Program Management and Systems

Engineering. Whitepaper presented at the 23rd INCOSE Annual Internat

ional Symposium, Philadelphia, USA, June 2013. [6] D. Van Gemert, Systems engineering the project, 2013:

https://www.pmi.org/learning/library/systems-engineering-project-5857

[7] The Project Manager’s Guide to Systems Engineering Measurement for Project Success, INCOSE Measurement Working Group:

http://www.incose.org/ProductsPublications/techpublications/pmguide

[8] H. Eisner, Essentials of Project and Systems Engineering Management, John Wiley and Sons Inc., Hoboken, New Jersey, 2008.

[9] A.P. Sage and W. Rouse, Handbook of systems engineering and management, John Wiley and Sons Inc., Hoboken, New Jersey, 2009.

[10] E. Rebentisch (Editor), Integrating Program Management and Systems Engineering: Methods, Tools, and Organizational Systems for Improving Performance. John Wiley and Sons Inc., Hoboken, New

Jersey, 2017.

[11] Work Breakdown Structures for Defense Material Items, Military Standard Mil-Std-881, 1968.

[12] Managing Successful Projects with PRINCE2, Office of Government Commerce, 2005.

[13] Department of Defense Reliability, Availability, Maintainability, and Cost Rationale Report Manual, Department of Defense, Washington,

DC: Office of the Secretary of Defense, 2009. [14] E. M. Goldratt, Critical Chain. Great Barrington, MA: North River

Press. 1997.

[15] C. L. Gray and E. W. Larson, Project Management: The Managerial Process. 2nd Ed. Boston, MA: McGraw-Hill/Irwin, 2003.

[16] Systems Engineering Fundamentals, Defense Acquisition University Press, Fort Belvoir, Virginia 22060-5565, 2001.

[17] Risk management — Vocabulary, ISO/IEC Guide 73, 2009. [18] Risk management — Principles and guidelines on implementation,

ISO/DIS 31000, 2009. [19] Earned Value Management Textbook, Defense Systems Management

College, EVM Dept., 9820 Belvoir Road, Fort Belvoir, VA 22060-5565,

1997. [20] Practice Standard for Earned Value Management. Project Management

Institute, 2005.

[21] The Design Structure Matrix (DSM), http://www.dsmweb.org/. [22] A. Rodrigues and J. Bowers, “The role of system dynamics in project

management,” International Journal of Project Management, Vol. 14,

Issue 4, August 1996, pp. 213-220. [23] J. M. Lyneis and David N. Ford, “System dynamics applied to project

management: a survey, assessment and directions for future research,”

System Dynamics Review Vol. 23, No. 2/3, pp. 157–189, 2007. [24] A Guide To The Project Management Body Of Knowledge (3rd ed.).

Project Management Institute, 2003.

[25] Gantt, Henry L., A graphical daily balance in manufacture, Transactions of the American Society of Mechanical Engineers, Volume XXIV, pages

1322-1336, 1903.

[26] A. Sharon, V. Perelman, and D. Dori, A Project-Product Lifecycle Management Approach For Improved Systems Engineering Practices, in

Proc. 18th Annual INCOSE Conf., Utrecht, the Netherlands, 2008.

[27] A. Sharon, D. Dori, and O. de Weck, “Is there a Complete Project Plan? A Model-Based Project Planning Approach,” in Proc. 18th Annual

INCOSE Conf., Singapore 2009.

[28] A. Sharon, O. de Weck, and D. Dori, Model-Based Design Structure Matrix: Deriving a DSM from an Object-Process Model. Accepted to Systems Engineering, July 2012.

[29] D. Dori, Object-Process Methodology – A Holistic Systems Paradigm. Springer Verlag, Berlin, Heidelberg, New York, 2002.

[30] A. Sharon, D. Dori, and O. de Weck, Project Management vs. Systems Engineering Management: A Practitioners' View on Integrating the

Project and Product Domains. Systems Engineering, 14(4), pp. 427-440, Oct. 2011.

[31] A. Sharon and D. Dori, Integrating the Project with the Product for Applied Systems Engineering Management. Proc. 14th IFAC Symposium on Information Control Problems in Manufacturing

(INCOM 2012) Bucharest, Romania, May 23-25, 2012. Winner of the

Track Paper Award. [32] J. Estephan, Survey of Model-Based Systems Engineering (MBSE)

Methodologies, INCOSE-TD-2007-003-02. Accessed Feb. 22 2010.

http://www.incose.org/ProductsPubs/pdf/techdata/MTTC/MBSE_Methodology_Survey_2008-0610_RevB-JAE2.pdf

[33] ISO N1049 - OPM Study Group, Terms of Reference, 2009. Accessed Feb. 20, 2010. http://isotc.iso.org/livelink/livelink?func=ll&objId=547513&objAction=

RunReport&InputLabel1=004315.

[34] ISO N1078 ISO/TC 184/SC 5 Plenary Meeting Resolutions 2010-03-25/26, Hosei University, Tokyo, Japan, 2010.

[35] D. Dori and M. Choder, Conceptual Modeling in Systems Biology Fosters Empirical Findings: The mRNA Lifecycle. Proceedings of the Library of Science ONE (PLoS ONE), September 12, 2007.

http://www.plosone.org/article/info:doi%2F10.1371%2Fjournal.pone.0000872

[36] J. Somekh, M. Choder, and D. Dori, Conceptual Model-Based Systems Biology: Mapping Knowledge and Discovering Gaps in the mRNA Transcription Cycle. PLoS ONE, 7(12): e51430.

doi:10.1371/journal.pone.0051430, Dec. 20, 2012.

http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0051430

[37] C. A. Osorio, D. Dori, and J. Sussman, COIM: An Object-Process Based Method for Analyzing Architectures of Complex, Interconnected, Large-Scale Socio-Technical Systems. Systems Engineering 14(3), 2011.

[38] O. L. de Weck, MIT ESD.36 System Project Management course assignment, 2008.

[39] D. McKinney, J. L. Dyck and E. S. Luber, iTunes University and the classroom: Can podcast replace Professors? Computers & Education 52,

pp. 617–623, 2008. [40] K. G. Ricks, et al, An Engineering Learning Community To Promote

Retention And Graduation Of At-Risk Engineering Students, American

Journal of Engineering Education, p 5 (2), December 2014. [41] N. Patel et al., A comparative study of speech and dialed input voice

interfaces in rural India, Proceedings of the SIGCHI Conference on

Human Factors in Computing Systems, pp. 51-54, Boston, MA, USA, 2009.

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


8

A. Sharon holds a B.Sc. in Mechanical Engineering (1992), a M.Sc. in Industrial Design (1997), and a Ph.D. in Information

Management Engineering (2010), all from Technion, Israel Institute of Technology. Her professional career spans the areas of

mechanical engineering, programming, systems engineering, systems engineering management, leading systems engineering

methodologies development, and robotic systems development. Her research interests include conceptual modeling of complex

systems, systems engineering management, and combining systems engineering with project management in large-scale complex

project-product systems. Amira Sharon is a member of the executive committee of the INCOSE_IL, the Israeli Chapter of

INCOSE.

D. Dori is Harry Lebensfeld Chair in Industrial Engineering and Head of the Enterprise System Modeling Laboratory at the

Faculty of Industrial Engineering and Management, Technion, Israel Institute of Technology. He is Fellow of IEEE – Institute of

Electrical and Electronics Engineers, Fellow of INCOSE – International Council on Systems Engineering, and Fellow of IAPR –

International Association for Pattern Recognition. Since 2000, he has been intermittently Visiting Professor at MIT. He received

his PhD in Computer Science in 1988 from Weizmann Institute of Science, MSc in Operations Research from Tel Aviv

University in 1981, and BSc in Industrial Engineering and Management from Technion in 1975. His research interests include

model-based systems engineering, conceptual modeling of complex systems, systems architecture and design, software and

systems engineering, and systems biology. Prof. Dori invented and developed Object-Process Methodology (OPM), recently

adopted as ISO 19450. He has authored over 300 publications and mentored over 50 graduate students. He is co-chair of the

IEEE SMC TC on Model-Based Systems Engineering and chaired or was co-chair of nine international conferences and

workshops. He was Associate Editor of IEEE Transaction on Pattern Analysis and Machine Intelligence, and currently he is

Associate Editor of Systems Engineering. He is Member of Omega Alpha Association – International Honor Society for Systems

Engineering, and Senior Member of ACM.

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


9

APPENDIX A – SAMPLE DIAGRAMS OF THE PROVIDED CT SCANNER PPLM MODEL

Figure A1. SD1 - CT scanner Project-Product Lifecycle Management in-zoomed (1)

Figure A2. SD1 - CT scanner Project-Product Lifecycle Management in-zoomed (2)

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


10

Figure A3. System Build #1 view


of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


11


Figure A6. SD1.1 - CT scanner Developing and Integrating in-zoomed

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


12

Figure A7. SD1.1.1 - First developing cycle in-zoomed

Figure A8. SD1.1.3 - Third developing cycle in-zoomed

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


13

Figure A9. UD5 - CT scanner unfolded

Figure A10. SD1.2 - 3D Organ Imaging in-zoomed

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


14

APPENDIX B – THE PROVIDED GANTT CHART OF THE CT SCANNER PLAN

Figure B1. The Gantt chart of the CT scanner plan used in the experiment

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


15

APPENDIX C – FOUR OF THE 33 QUESTIONS GIVEN IN STAGE 3, THEIR TYPE, RATIONALE, AND EXPECTED OUTCOME

# Question Type Rationale and expected outcome

Q2 What is the planned

duration of the first development cycle?

Process

duration

In Gantt chart – the duration assigned to the hammock.

In the PPLM model – the duration assigned to the process.

The first development cycle of the CT scanner is clearly identified in both the Gantt chart

model and the PPLM model. No significant difference was expected to be found between the

models for this question.

Q7 Are there

components of the CT scanner that are

not covered by the

plan?

General

completeness

In Gantt chart – the components names are part of a task name (as a convention, in relevant

tasks).

In the PPLM model – the components are inherent objects in the model, related to relevant

processes.

For answering this question based on the provided Gantt chart and the PPLM model, the participants had to alternate between the two to find out whether there are components of the

CT scanner that are not covered by the plan. This information is clearer in the combined project-product PPLM model, therefore we expected to get higher scores from students who

consulted the PPLM model.

Q13 How many

specifications are

contained in the plan?

General

completeness

In Gantt chart – the speciation names are part of a task name or milestone (as a convention, in

relevant tasks or milestones).

In the PPLM model – the specifications are inherent objects (of specific type according to the PPLM methodology) in the model, related to relevant processes.

No significant difference was expected to be found between the models for this question, since

they both contain the same information regarding to the specifications contained in the plan – modeled as objects in the PPLM model and as milestones in the Gantt chart model.

Q24 If a software specification is

delayed, how is the

plan affected?

Project-product

completeness

There are three identical software specifications in both models. However, their nature as software specifications can be derived only from the PPLM model, which specifically indicates

these three objects as being software components. For answering this question based on the

Gantt chart model and the provided product model, the participants had to alternate between the two to find out the answer. This information is clearer in the combined project-product PPLM

model, hence we expected to get higher scores from students who consulted the PPLM model.

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


16

APPENDIX D – SELECTED REFLECTIONS PROVIDED BY THE PARTICIPANTS

Some selected reflections provided by the participants, are presented in this Appendix: first for the Gantt chart model, followed

by the PPLM model, through PPLM vs. Gantt reflection.

A. The Gantt chart model

All the participants reported on the ease of creating the Gantt chart, based on the given text, in which the tasks along with their

durations and relationships were included:

“While building the [Gantt] model, the most critical aspect was figuring out task dependencies. I did not feel that fully

understanding the nature of the task or its end results were very significant for building the model. Overall, there were three

items I needed for each task: 1 - task duration, 2 - task dependencies, 3 - task resources (though not very significant for the

model’s structure).

When building the model I was only interested in the task itself and what it depended on. It was not very important to

understand where the task fits within the overall project.” [Subject 17]

“It took me 0.5 hours to develop the Gantt chart in MS project. Per the given information, the step and time duration of each

step, as well as the dependency are very clear, and easily organized into the Gantt chart… I did not make any additional

assumption beside the given information.” [Subject 18]

“The [Gantt] model was very easy to create, no need for intermediate objects to be created, only the sequence matter and

Microsoft Project worked very well for it.” [Subject 24]

Some of the participants provided judgment of the Gantt chart utility, as contained in the following phrasing:

“It [the Gantt chart] is a general timeline which helps assessing the duration of the project, and the general outline.”

[Subject 11]

B. The PPLM model

Many participants indicated the longer time spent on producing the PPLM model, but reported added value to the effort of

including both the processes and the objects in the combined PPLM model:

“While the [PPLM] model took significantly more time, I found it quite interesting that the end result gave me an insight on

both the project process and the system being built (product). Throughout the process I was also very much engaged in

understanding the outcome of each task and the resulting states. Overall it is interesting to observe that through OPD I was

able to both model the project flow and the outcomes.” [Subject 17]

“It took significantly longer to make an OPM model of the project (probably partly because I was not close to as comfortable

with OPCAT as I was with Project)…I had to make some more assumptions when using OPCAT. I decided to model the

informational and physical aspects of the project as separate objects (i.e. the “software” was treated as one physical object,

while the “software design” was a separate informational object). I also had to make assumptions for the state and process

for each task “grouping.” In the end it generally ended up that I modeled each task from HW2 as a set of an object with two

states and a process that changed the object from one state to the next. When viewing the completed project model, there is

more information presented in the OPM model as far as interactions and statuses, however the Gantt chart better shows the

timing of tasks since those are contained within the properties box on OPCAT.” [Subject 12]

“It took me about 3 hours to complete the OPM of the UAV product System as shown above. Clearly, the project plan has

been divided into five high level processes…Each of these high level processes are further subdivided into processes as

shown in the OPM above. Each sub-process, for example “Develop Engine Specification” depends on a deliverable (UAV

Requirements document in this case as a result of previous process) and results in a deliverable namely, Engine Specification

in the above model. All tasks in the project are thus mapped into process and object deliverables.” [Subject 14]

“It took me 5 hours to develop OPM model. I regrouped the tasks on the basis of task content such as design spec defining,

designing and developing, integrating and assembling, as well as testing. These meta-groups have clear sequences. The

previous group tasks are done, and then the next group tasks can begin.” [Subject 18]

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


17

Some of the participants explicitly phrased the added value, in their opinion, from the combined OPM based project-product plan

they had produced with the OPCAT software:

“In the process of writing the OPM, you need to think of operators like ECC and states of objects in a project… I used the

creation of objects like Engine Specification or Payload Specification as a deliverable of an activity to later be used by

consecutive process as a pre-requisite. The good thing about this diagram is that it pictures what process affects on a

particular object (deliverable) and which processes depend on those objects (previous activity deliverable).” [Subject 24]

“What I did like about this tool [OPCAT], is the strong relationship between objects and processes. I think it simplifies the

way one thinks about a project. It makes the stages more clear. You know that at the end of each process there is an object to

create, and it feels like little milestones, that helps define the step by step execution of the project.” [Subject 11]

C. PPLM vs. Gantt

Many participants included a comparison of the two models they had produced, as part of their reflection on the modeling

process, expressing their criticism on both the modeling process and the produced models. A single participant was entirely in

favor of the Gantt chart:

“After my experiencing with both softwares, I believe the MS Project can demonstrate most critical factors of a project much

more explicitly than OCPAT.” [Subject 18]

All the other participants provided a more balanced comparison, overall favoring OPM and indicating its advantages over Gantt.

Following are a few excerpts of students’ reflections.

“The OPM model adds another perspective to the CPM model in HW2. Despite the time to create, the OPM is quite useful

and best describes the project plan and its resulting objects... the OPM model is a much more of a comprehensive

representation of the project and its corresponding process…The Gantt chart should only be used for analyzing higher level

tasks when schedule is the managers only concern.” [Subject 10]

“OPM also triggers the need to identify the output or object, and incorporate that as a deliverable, this can be reflected in

the Gantt chart. By doing so, all stakeholders in the Gantt chart will understand the deliverable being received and also the

deliverable being delivered downstream…OPM can assist to reflect which task should be completed first before engaging in

subsequent task. In this example, the task list in diagram 3 would be completed first, and then the link will continue in

diagram 2. Diagram 2 would of course be initiated first due to Requirement Definition task, but the next step would be to

branch into this task, and as the micro task of Requirement Definition is completed, then the Gantt chart should refer back to

Diagram 2 for subsequent tasks.” [Subject 9]

“I guess the concept of these 2 tools is very different, and concentrate on different aspects of a project. While Gantt gives you

a general idea about the project schedule, the OPM model represents the project as a relationship between objects and

processes that need to be accomplished. It helps understanding the different stages of development, and makes it simpler… It

makes sense to me to have an OPM of the product first, specify each component, and its function and then map it directly to

the project OPM, making sure that the product is being built correctly, timely manner.” [Subject 11]

“The Gantt was directly created from the Task details in HW2, using the task durations and Early Start and Early Finish

times for the project. It’s an interesting observation that, remarkably enough the OPM diagram (above) has captured much

more detail compared to the Gantt (below). In the Gantt the object and process relationships are really embedded within

each task, there is no clear way to differentiate what really are the deliverables at each stage of the project… There is also

no straight way to figure out which tasks can be grouped together for iterations.” [Subject 14]

So far, from Figure 6 [OPM], it does not appear that I can visualize the project timeline, nor the start dates. If you recall, I

indicated that once I entered the project start date, and the task dependencies and durations, the Gantt chart calculated the

ES and EF of each of my tasks, and showed them graphically with blue bars. It is helpful for me to visualize the schedule

part of the iron triangle (cost, schedule, scope) in that way. However, it is better for me to visualize the scope part of the iron

triangle through the OPCAT model in figure 1. Displaying the tasks and resources separately makes it very easy to see

who/what is needed and when. ... The major change from the Gantt to the OPM is that I created objects that signify the end

of a process. All tasks in a real project have a deliverable. Using these objects to indicate the deliverables, what creates

them and who requires them is extremely useful.” [Subject 13]

“The change that I made to the OPM model that I did not have in the Gantt chart was the NMA facilities. One explanation

would be that I just picked out something in the second reading of the project description that I did not see in the previous

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


18

reading when I created the Gantt chart. However, I would suggest that this was not the only reason. Making a pictorial

distinction between the objects and processes enabled me to think harder as to what other ‘resources’ could be needed.

When I thought about this, I then noticed that it said ‘NMA Facility’ in the project description.” [Subject 23]

APPENDIX E QUESTIONS FOR WHICH NO SIGNIFICANT DIFFERENCE WAS FOUND BETWEEN THE PPLM MODEL AND THE GANTT CHART MODEL

Question Score T-Test

result Discussion

# Phrase PPLM Gantt

1

What is the planned

duration of the first

development cycle?

122 126 not

significant

This result indicates that in this stage, where we provided the models, we overcame the problem of the inconvenience of the presentation of

process durations in the PPLM model. It also suggests that with

proper training, one can produce both models – PPLM and Gantt – with little difference if any with respect to presentation of process

durations.

2

What is the planned duration of the

second development

cycle?

118 124 not

significant The discussion in question 1 above is applicable here as well.

5

Are there system

builds that are not covered by the plan?

101 94 not

significant

We expected the results for both models to be close, since both

models do not contain all development cycles, or PPLM system

builds (SBs), although both show the intent of having 5 SBs in the plan.

13

How many specifications are

contained in the

plan?

110 102 not

significant

We expected the results for both models to be close, since they both contain the same information regarding to the specifications

contained in the plan – object in the PPLM and milestones in the

Gantt.

21 How many design reviews are

planned?

64 64 not

significant

Both models got the same low score.

We expected these, or even lower scores, since neither one of the models contains planned design reviews.

23

If the table sub-

system specification is delayed, how is

the plan affected?

90 98 not

significant

The results for the two models are close and match our expectations,

since both models contain all five specifications, as objects in PPLM

and as milestones in Gantt.

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


19

APPENDIX F – QUESTIONS FOR WHICH NO SIGNIFICANT DIFFERENCE WAS FOUND BETWEEN THE PPLM MODEL AND THE GANTT CHART MODEL


result Discussion

# Phrase PPLM Gantt

14 When is the built-in

test (BIT) planned? 49 110 P<0.05

Gantt is about 56% better than the PPLM. We expected this result since the BIT is clearly completely missing in the PPLM model

while clearly fully contained in the Gantt model.

15 What is required for the BIT?

48 91 P<0.05 Gantt is about 47% better than the PPLM. The discussion in question 14 is applicable here as well.

30

How long does

System Build #5 take?

75 114 P<0.05

Gantt is about 34% better than the PPLM.

We expected this result since the fifth development cycle (SB#5), which appears in the Gantt model, is missing in the PPLM model.

of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

For Peer Review


20

APPENDIX G – QUESTIONS FOR WHICH A SIGNIFICANT DIFFERENCE WAS FOUND IN FAVOR OF THE PPLM MODEL


result Discussion

# Phrase PPLM Gantt

3

When does the first cycle start with

respect to the

Definition? What is the reason for this?

118 109 P<0.05

PPLM is about 8% better than the Gantt. This is due to the question phrasing. While the relationship between the first cycle and the Definition is explicit in

both models, the reason is explicit only in the PPLM model. This result is an

example for the strength of the PPLM model: it provides the rationale for the relationship, which is that the deliverables resulting from the first cycle and

required for the Definition.

4 How many System Builds are planned?

122 107 P<0.05

PPLM is about 12% better than the Gantt. We expected the results for both models to be close, since neither contain all the development cycles (SBs), but

both show the intent of including 5 SBs in the plan. We expected that when a

SB is missing, it would be indicated as “can be easily found out”, but many participants chose other answers to reflect the missing SBs.

6 Is the plan

complete? 91 79 P<0.05

PPLM is about 13% better than the Gantt.

The discussion in question 4 is applicable here as well.

7

Are there components of the

CT scanner that are

not covered by the plan?

91 75 P<0.05


For answering this question based on the Gantt and the provided product model,

the participants had to alternate between the two to find out whether there are components of the CT scanner that are not covered by the plan. The result

indicates that this information is clearer in the combined project-product PPLM

model.

8

Are there

components of the

CT scanner that are not required

according to the

plan?

90 73 P<0.05 PPLM is about 19% better than the Gantt. The discussion in question 7 is applicable here as well.

9

Is there a parameter

of the CT scanner

that is not covered by the plan?

92 61 P<0.05 PPLM is about 34% better than the Gantt.


10

What specifications

are required for the first development

cycle?

115 104 P<0.05


This result is an example for the strength of the PPLM model – it provides the rationale of the plan in terms of explicit deliverables that result from each

process and are required for each process in order for it to start.

11

What specifications are required for the

second development

cycle?

120 95 P<0.05


We expected the results for both models to be close, since all five specifications are contained in both models – as objects in PPLM and as milestones in Gantt.

12

What is the outcome

of the Definition

activity?


16

What product

processes are

planned to be achieved by the end

of the second

development cycle?


17

What product

processes are planned to be

achieved by System

Build 3?



18

What product

processes are

planned to be achieved by System

Build 4?



19 How many product processes?


20 How many product requirements?

73 40 P<0.05


Actually neither one of the models contains the product requirements. The result can be explained by the halo effect of the deliverables being in general more

explicit in the PPLM model than in the Gantt chart model.

22 Are all the product processes covered

by the plan?



of 20

John Wiley & Sons

Systems Engineering

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

Model-Based Project-Product Lifecycle Management and Gantt...

Documents

Transcript of Model-Based Project-Product Lifecycle Management and Gantt...