Managing Scope, Stakeholders and Human Resources in Cyber-Physical

System Development

Filipe E. S. P. Palma

, Marcelo Fantinato

, Laura Rafferty

and Patrick C. K. Hung

University of São Paulo, São Paulo, Brazil

University of Ontario Institute of Technology, Oshawa, Canada

Keywords:

Cyber-Physical Systems, Project Management, Scope, Stakeholers, Human Resources.

Abstract:

Cyber-Physical Systems (CPS) represent the convergence of physical processes and computational platforms

into technological solutions composed by sensors, actuators and software. Such as for other types of projects,

project management practices can beneﬁt a CPS development project. Due to some particularities of CPS, such

as multidisciplinary team and high innovative aspect, generic project management practices may not be enough

to enhance project success. Therefore, speciﬁc practices are proposed for better managing CPS projects,

called CPS-PMBOK approach. CPS-PMBOK is based on the Project Management Institute’s PMBOK body

of knowledge. It is focused on the integration, scope, human resource and stakeholder knowledge areas;

which were chosen considering a systematic literature review conducted to identify the main CPS challenges.

Managers and developers of a R&D organization evaluated the approach. According to the practitioners

consulted, the proposed practices can improve several aspects related to CPS projects.

1 INTRODUCTION

Cyber-physical Systems (CPS) are computational

systems that interact with the physical world (Rajku-

mar et al., 2010; Sha et al., 2009). CPS gained re-

markable advances in science, such as autonomous

vehicles, medical surgery, smart buildings and energy

harvesting. A CPS is composed of a computing plat-

form, the physical world, sensors and actuators (Ra-

jkumar et al., 2010; Sha et al., 2009). CPS merge ar-

eas from embedded systems, mechanical engineering,

software etc. (Lee and Seshia, 2017).

CPS development projects tend to be large, com-

plex and groundbreaking, with innovative technolo-

gies (Rajkumar et al., 2010; Sha et al., 2009; Baheti

and Gill, 2011). They are often related to proofs of

concept, to test a new technology. These projects are

usually related to research due to the natural complex-

ity of its interaction environment. A usual feature is

multidisciplinary, which requires good team commu-

nication skills, since CPS development merges com-

puting and physical world concepts.

A recurring issue in CPS projects is the misunder-

standing caused by the large number of concepts in-

volved. Collaboration among practitioners from dif-

ferent areas (such as software engineering, civil en-

gineering, experimental physics or natural sciences)

is needed to accomplish CPS developments (Lee and

Seshia, 2017; Baheti and Gill, 2011).

Project management practices aim to enhance the

probability of success in a product or service devel-

opment (Lester, 2014). The success depends on orga-

nization, application area and project goals, but pri-

orities may vary, including: ﬁnishing within planned

time, meeting agreed scope, reaching satisfactory

quality or ﬁnishing in determined budget. Managing

a project consists of controlling the development and

providing all resources necessary for project execu-

tion; which is a responsibility usually assigned to a

project manager. Project management is useful for

diverse areas, such as: medicine, civil engineering,

software development, advertising campaigns etc.

The Project Management Institute gathers best

practices in the so called Project Management

Body of Knowledge (PMBOK) (PMI, 2013), which

presents tools and techniques for a better management

considering experts’ knowledge. PMBOK organizes

the best practices via ﬁve process groups (initiating,

planning, executing, monitoring and controlling, and

closing) and ten orthogonal knowledge areas (integra-

tion, scope, time, cost, quality, human resource, com-

munications, risk, procurement, and stakeholder).

Considering the particularities of CPS projects

and the need to manage them to reach their goals ac-

Palma, F., Fantinato, M., Rafferty, L. and Hung, P.

Managing Scope, Stakeholders and Human Resources in Cyber-Physical System Development.

DOI: 10.5220/0007485300360047

In Proceedings of the 21st International Conference on Enterprise Information Systems (ICEIS 2019), pages 36-47

ISBN: 978-989-758-372-8

cording to the success factors established, this paper

presents speciﬁc practices for better managing CPS

projects. A preliminary version of the proposed prac-

tices was presented (Palma et al., 2018), but still with

no evaluation results. These practices are proposed

as a PMBOK extension, called CPS-PMBOK. CPS-

PMBOK is focused on the integration, scope, human

resource and stakeholder knowledge areas. They were

chosen considering a systematic literature review con-

ducted to identify the main CPS challenges. Thus,

we expect to improve both team communication skills

and understanding of the project activities. The pro-

posed practices rely on approaches previously pre-

sented in literature as well as the authors’ background.

We consider that a well-managed CPS project may in-

crease physical world comprehension, modeling and

interaction, enhancing the technological advances.

The remainder of this paper presents: background,

related work, research method, the proposed approach

and its evaluation and the paper conclusion.

2 CYBER-PHYSICAL SYSTEMS

Cyber-Physical Systems (CPS) describe a new gen-

eration of engineered systems capable of high per-

formance in information, computing, communication

and control. Examples are: online and robotic medi-

cal surgeries; smart power grids, in which the power

line health and consumption can be monitored at dis-

tance all the time; and autonomous vehicles, as trains,

cars, drones or Unmanned Aerial Vehicles (UAV).

CPS are a new way of interaction based on the

possibility of both full understanding of physical phe-

nomena and environmental behaviors as well as ex-

changing of contextualized information between the

computing world and the physical world, as people in-

teract with each other at the internet (Rajkumar et al.,

2010). On the one hand, the computing world in-

cludes all types of computing platforms, able to pro-

cess and provide information for people or other tech-

nological components; on the other hand, the physi-

cal world includes physical phenomena and processes

that can be found in the environment.

From the computing side, some devices can be

found: Unix-based computers, microcontrollers, mi-

croprocessors, signal acquisition hardware, embed-

ded systems, digital signs processors, programmable

logic controller, ﬁeld-programmable gate arrays etc.

From the physical side, some physical phenom-

ena can be found: temperature, atmospheric pres-

sure, electrical current and voltage, lighting, radio-

frequency, motion (velocity/direction), sound, time

etc. Physical processes are phenomena combined in a

certain context, such as: room temperature, changing

over the time considering the number of people in it;

airplane pressure, changing considering the ﬂight alti-

tude; and the current provided by an electrical engine,

proportional to its load.

Sensors and actuators enable the union of the two

worlds. Sensors may be any technological device ca-

pable of transforming a physical phenomenon into

electrical signs or other computer-readable sign. Ac-

tuators are speciﬁc technological devices able to gen-

erate electrical signs, sound, radio-frequency, indirect

motion or any other physical phenomena to stimu-

late elements in a physical process. Actuators can

also stimulate sensors of other CPS (Lee and Seshia,

2017). This interaction consists of computers read-

ing and controlling the physical world, via cycles of

feedback reading, and the control adaptation via com-

puting for the next interaction (Lee, 2008).

CPS are addressable via a multidisciplinary view,

since they are a conﬂuence of embedded, real-time,

distributed sensors and control systems. This requires

a diversity of experts working together from differ-

ent areas, such as: civil engineering, mechanical engi-

neering, biomedical engineering, electrical engineer-

ing, control engineering, software engineering, chem-

ical engineering, network engineering, computer sci-

ence, human interaction, learning theory, material sci-

ence, signal processing and biology (Lee, 2008; Sha

et al., 2009; Rajkumar et al., 2010; Baheti and Gill,

2011; Lee and Seshia, 2017).

3 RELATED WORK AND

RESEARCH METHOD

Speciﬁc areas, including CPS projects, may beneﬁt

from adapted or focused project management prac-

tices, which can better drive project activities and pre-

vent common weaknesses (Lester, 2014). Some au-

thors proposed new techniques for stakeholder man-

agement in civil engineering projects and in clini-

cal research environments (Shen et al., 2015; Pandi-

Perumal et al., 2015). Taking differences on organiza-

tional structures, some works are concerned on stake-

holders, scope, human resources and communications

for globally distributed projects (Deshpande et al.,

2013; Golini and Landoni, 2014). Others propose en-

tire revisions of PMBOK processes, knowledge areas

or other project management approach adaptations,

but in a general way. One example extends the knowl-

edge areas creating the new ‘project sustainability

management’, dealing with reuse of lessons learned

and standardization of project management practices

within an organization (Reusch, 2015).

Managing Scope, Stakeholders and Human Resources in Cyber-Physical System Development

To propose our PMBOK extension, we used re-

sults from a systematic literature review, conducted

to link PMBOK’s knowledge areas and the CPS de-

velopment. We looked for works addressing speciﬁc

CPS project management issues. We used various

technical CPS-related terms to embrace as many pri-

mary studies as possible, such as: embedded systems,

system of systems, sensors network, IoT, and automa-

tion and control. These terms are used for different

levels of interactions but useful for our purpose.

The primary studies were analyzed to ﬁnd which

knowledge areas were subject of study. A relevance

score was applied based on the number of times that

keywords related to each area were mentioned. The

outcomes are that scope, human resource and stake-

holder were the areas with more issues studied. These

results do not mean that the remaining knowledge ar-

eas are not relevant, but that the current project man-

agement practices are probably enough to properly

manage them in the CPS context. Considering the

outcomes of this systematic review, our work pro-

poses project management practices, focused on the

CPS context for the scope, human resource and stake-

holder knowledge areas. We also propose a generic

practice related to the integration area.

The following practices are suggested to man-

age scope in CPS projects: software and frame-

works for requirements analysis; application of in-

ternational standards; estimations based on use case

points and hardware points; speciﬁc modeling lan-

guages for requirements elicitation and system archi-

tecture visualization; requirements review via peer re-

viewing and Scrum boards; development of design

models; speciﬁc development approaches; meetings

with live demonstrations; analysis-driven design; re-

quirements lists; model-driven design; and new pro-

cess models for scope management (Greene, 2004;

Jun et al., 2007; Madachy et al., 2007; Madachy,

2008; Silva et al., 2009; Shatil et al., 2010; Berger

and Rumpe, 2010; Garay and Kofuji, 2010; Savio

et al., 2011; Rong et al., 2011; Helps and Mensah,

2012; Huang et al., 2012; Penzenstadler and Eck-

hardt, 2012; Insaurralde and Petillot, 2013; Zhu and

Mostafavi, 2014; Parkhomenko and Gladkova, 2014;

Yue and Ali, 2014; Sapienza et al., 2014; Faschang

et al., 2015; Lattmann et al., 2015).

For human resource, these practices are suggested

to CPS projects: distribution of tasks considering the

team members’ proﬁle and expertise as well as sta-

tistical estimation and classiﬁcation of familiarity of

team members, according to their proﬁles and re-

quirements; deﬁnition of speciﬁc key-roles needed

for the team; use of an expert and multidisciplinary

team; training in speciﬁc development methods, such

as goal- and model-driven and extreme program-

ming; and skill-based human resource management

(Greene, 2004; Madachy et al., 2007; Madachy, 2008;

Chen and Wei, 2009; Shatil et al., 2010; Wolff et al.,

2011; Rong et al., 2011; Helps and Mensah, 2012;

Huang et al., 2012; Zhu and Mostafavi, 2014; Yue

and Ali, 2014; Parkhomenko and Gladkova, 2014).

Finally, considering the project stakeholders, the

following practices are suggested to address this

knowledge area in CPS projects: identiﬁcation of

stakeholders and assignment of tasks following sys-

tematic algorithms and norms; assignment of stake-

holders within the organization; involvement of stake-

holders during the transition between development

phases; face-to-face meetings; workshop meetings;

and speciﬁc stakeholders management approaches

such as the evolutionary development and the con-

structive SoS integration model (Greene, 2004;

Madachy et al., 2007; Madachy, 2008; Shatil et al.,

2010; Rong et al., 2011; Huang et al., 2012; Penzen-

stadler and Eckhardt, 2012; Zhu and Mostafavi, 2014;

Yue and Ali, 2014; Singh, 2013).

As part of the method to propose CPS-PMBOK,

we analyzed all the practices related to scope, human

resource and stakeholder found in the primary stud-

ies identiﬁed. We compared them with the best prac-

tices existing in PMBOK. As a result, we found both

practices still not covered by PMBOK and practices

covered but with suggested specializations. Follow-

ing an empirical approach, we reﬁned this list of prac-

tices considering the authors’ practical experience in

CPS projects. The ﬁnal practices chosen are those

most frequently found in the primary studies as well

as aligned with the primary insights of the authors of

this work. Finally, such chosen practices were also

evaluated by experts in a CPS-related R&D company,

including managers and developers, who presented

some ﬁnal suggestions to produced the last list of cho-

sen practices to compose CPS-PMBOK.

4 THE CPS-PMBOK APPROACH

Given the growing demand on CPS projects and

consequent need for proper management, this ap-

proach propose appropriate practices for managing

CPS projects. Our main goal is improving both

team communication skills and understanding of the

project activities when addressing CPS projects. The

Cyber-Physical Systems – Project Management Body

of Knowledge (CPS-PMBOK) approach proposes

practices based on Project Management Institute’s

PMBOK, but oriented to the speciﬁc context of CPS

projects. Agile methods indirectly inﬂuence the prac-

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

tices since agile practices are also commonly related

to the issues addressed here. One of the main char-

acteristics of CPS-PMBOK is the adequate treatment

of concerns with hardware beyond software as well as

teams composed of very different technical proﬁles.

CPS-PMBOK is composed of the original set

of PMBOK best practices, extending it for CPS

projects. The specialization address four PMBOK’s

areas. For each, one or more practices are pro-

posed: (a) integration – characterization model (ar-

tifact); (b) scope – pre-elaborated requirements lists

(technique), review requirements (process), process

simulation (technique); (c) human resource – special-

ized team division (technique), cross-training (tech-

nique); (d) stakeholder – build technical trust (tech-

nique), dynamic follow-up strategies (technique).

From the 47 processes suggested by PMBOK

(v.5), seven of them received some enhancement sug-

gestion, including: the addition of a new process out-

put, the addition of a new process tool/technique, or

the addition of a new whole process.

4.1 Integration Management

First proposed practice, the characterization model

should be used a brainstorm driving, to equalize the

comprehension and familiarization with the system to

be developed. This artifact is proposed to be pro-

duced as an output of the develop project chart pro-

cess, which is part of the initiating process group.

Fig. 1 presents the proposed characterization model

output artifact, highlighted in bold, within the de-

velop project charter process, following the graphic

pattern used in PMBOK to present its processes. This

output should be used as input by all processes that

use the project charter also as input, i.e.: plan scope

management, collect requirements, deﬁne scope, plan

schedule management, plan cost management, plan

risk management, and plan stakeholder management.

Figure 1: Characterization model (“develop project charter”

process).

Fig. 2 illustrate a characterization model. For

each proposed characteristic, the participants of the

brainstorming ﬁll the characterization model choos-

ing between low, moderate and high. This may pro-

vide estimates regarding project size, complexity and

technical challenges besides to discussions among the

team members. These characteristics are divided in

two sections: CPS environment and CPS complexity.

Our example of CPS characterization model presents

some characteristics usually found in CPS projects.

Figure 2: CPS projects’ characterization model (example).

The CPS environment represents the variables

present in the CPS to be developed, such as how

much: limited tasks are required, communication

with known group of devices, interaction with known

group of people, and industrial standards or norms

should be followed. The higher the score assigned

for each characteristic, the better deﬁned and sur-

rounded by formalized processes is the CPS environ-

ment. The opposite means that the CPS environment

can be chaotic and unpredictable, which might de-

ﬁne project management strategies, adequate teams to

work on the project or budget adjustments.

The CPS complexity is based on speciﬁc techno-

logical areas: mechanical structures, network, sen-

sors, actuators, data storage, user interaction, legacy

systems integration, and power energy system. The

complexity characterization is made by choosing how

relevant is the integration of the CPS being developed

with each of these technologies. For each one, a spe-

ciﬁc technical team may be required to estimate such

complexity. Like the environment characterization,

different project management decisions may be taken

depending on the CPS complexity.

We do not intend to deﬁne a ﬁxed characterization

model, with ﬁxed characteristics. Fig. 2 proposes a

basic example that may be adapted for each organiza-

tion or team, based on lessons learned, project goals

or application area, considering CPS concepts. More-

over, we expect that the list of characteristics evolves

considering the team’s experience on past projects.

4.2 Scope Management

As for scope, some processes show special challenges

for CPS projects due to highly innovative and dy-

namic aspects (Lee, 2008; Sha et al., 2009; Baheti and

Managing Scope, Stakeholders and Human Resources in Cyber-Physical System Development

Gill, 2011; Lee and Seshia, 2017). The high complex-

ity of modeling the physical world and its phenomena

is another challenge source. Innovation and complex-

ity result in ever-changing requirements mainly due

to: realignment of the stakeholders’ conception, un-

derstanding of further issues, rise of new technolo-

gies, adaptation of unstructured processes, and ﬁnd-

ing of new physical phenomena. In this innovative

scenario, a late discovery of new requirements is in-

evitable mainly when considering an exploratory de-

velopment method as required and adopted by many

organizations (Huang et al., 2012). CPS project man-

agers and team should be able to constantly look for

new requirements, bringing up changes in scope as

soon as possible. Besides contributing to a proper

system speciﬁcation, a partnership-based approach,

involving an outsourced organization, also allows to

proper address ever-changing requirements when its

participation is needed. As a result, two practices are

proposed to the scope management: pre-elaborated

requirements lists and review requirements.

4.2.1 Pre-elaborated Requirements Lists

Technique

To support requirements gathering, CPM-PMBOK

includes a technique called pre-elaborated require-

ments lists. Their purpose is to create reusable assets

by gathering common requirements in CPS projects.

This technique is proposed to be used within the col-

lect requirements process, which is part of the plan-

ning process group. Fig. 3 presents the proposed pre-

elaborated requirements lists technique, highlighted

in bold, within the collect requirements process. Pre-

elaborated requirements lists help collect require-

ments which should be used to estimate project size

and avoid missing requirements. It contains topics of

possible requirements so the project manager or team

can ﬁll with weights, points or simple tags signaling

the existence of some requirement, such as a check-

list. These topics may be divided in domains related

to technical areas (cf. Fig. 2). Fig. 4 shows an exam-

ple of a pre-elaborated list of software requirements

for an initial collection of CPS requirements. It indi-

cates a subject of high level of abstraction (on the ‘Re-

quirements topic’ column) and a corresponding tech-

nical question for each topic (on the ‘Technical issue’

column) to be answered as a support for collecting

requirements. It is based on the hardware points tech-

nique, proposed to estimate hardware assembly and

development cost (Silva et al., 2009).

Figure 3: Pre-elaborated requirements lists (“collect re-

quirements” process).

Figure 4: Example of a pre-elaborated requirements list.

4.2.2 Review Requirements Process

CPS development may lead to unexpected results and

hence dynamic requirements (Huang et al., 2012).

Thus, the innovative aspect of CPS demands many

scope revisions and redeﬁnition. By understanding

that such scope revisions and redeﬁnitions are highly

common in CPS projects, one of our speciﬁc prac-

tices is proposing an additional process to the scope

knowledge area – review requirements – as part of

the monitoring and controlling process group. Fig.

5 presents the proposed review requirements process,

including its inputs, tools/techniques and outputs. Re-

view requirements aims to advance requirements re-

views, bringing up the changes as soon as possible,

so it can be timely addressed. Review requirements

results in change requests similarly to performed by

the control scope process, as described in PMBOK.

The difference is that, in CPS-PMBOK, review re-

quirements is a creation-focused process, consider-

ing less the known requirements and revisiting the

highest deﬁnitions of the project looking for new re-

quirements. In PMBOK, the control scope process

focuses on ensuring the accomplishment of the de-

ﬁned scope and, when needed, the appropriate pro-

cessing of changes are made. This new process fol-

lows principles of agile methodologies. Its purpose is

to predict requirements changes enabling the team to

react in real time and according to the resources avail-

able. Moreover, this additional process aims to reduce

the impacts of requirements constantly changing. In

this new process, techniques to collect requirements

already described in PMBOK are used, as meetings,

surveys and interviews. CPS-PMBOK additionally

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

includes the process simulation technique in support

of review requirements. It consists of tests and vali-

dation of the various stages of development, accord-

ing to the features becoming ready to use. Simulation

tools to predict environment or conditions such as me-

chanical simulation, radiation diagrams and thermal

dissipation are useful in review requirements and are

part of process simulation. Other tools to isolate part

of the CPS, to validate models or equipment, such as

hardware or software in the loop may also be used.

Figure 5: Review requirements process, with process simu-

lation.

4.3 Human Resource Management

Considering multidisciplinary, human resources can

be from different specialization areas, what increases

the challenge of managing relationships and technical

communication (Wolff et al., 2011). A project to de-

velop a smart power grid system, for instance, may

include professionals from electrical supply, hard-

ware design, telecommunication and software de-

velopment. Those from electrical and software ar-

eas may be not familiar with hardware technologies

whereas from telecomm and hardware areas come

from a very different school, where software is usu-

ally not object of study. These different academic ap-

proaches applied in a same project may cause mis-

understanding among team members, inﬂuencing re-

quirements understanding and even task priorities. As

a result, two additional techniques are proposed in

CPS-PMBOK for human resource management: spe-

cialized team division and cross-training.

4.3.1 Specialized Team Division Technique

specialized team division is included in CPS-PMBOK

to improve the development performance and avoid

inappropriate assignment of tasks. The team should

be split into subteams taking different application ar-

eas or project deliverables. Some works found in lit-

erature were used as a basis to propose it, includ-

ing: the application of team division based on aca-

demic proﬁles, such as electrical engineering, com-

puter engineering and information technology (Helps

and Mensah, 2012; Sha et al., 2009). This technique

is proposed to be used within two processes: the plan

human resource management process, which is part

of the planning process group; and the acquire team

process, which is part of the executing process group.

Figures 6 and 7 present the proposed specialized team

division technique, highlighted in bold, within both

the plan human resource management process and the

acquire team process, respectively. We propose an

initial suggestion for a specialized team division con-

sidering the context of CPS projects and taking into

account the proposed characterization model in terms

of CPS complexity. According to our suggestion, the

sub-teams for a CPS projects could be: (a) mechani-

cal design team – responsible for physical structures

and mechanical packing; (b) hardware design team

– responsible for processing platforms, sensors and

actuators speciﬁcation; (c) electrical design team –

responsible for electrical project and drawings, be-

sides power energy design; (d) network design team

– responsible for communication protocols and tech-

nologies speciﬁcation; (e) information system devel-

opment team – responsible for software development;

(f) other specialized teams – power bank development

team, human-computer interface team, antenna de-

sign team, speciﬁc sensors team etc. Other options

for specialized team division can be used according

to speciﬁc project needs, based on the context of the

system application. An alternative division is based

on deliverables or partial results of the project, as-

signing a focused team for each logical deliverable

part of the developed CPS system. As an example,

considering an autonomous meteorological informa-

tion collector, which involves drone development al-

lied with weather sensing and statistical software for

forecasting, a specialized team division based on de-

liverables could be: (a) mechanical structure – mixing

mechanical and hardware design proﬁles, responsible

for structure and engines design and development; (b)

ﬂight system – composed of mechanical and hard-

ware design proﬁles and possibly a theorical ﬂight

expert, responsible for designing and developing the

propellers and orientation sensors; (c) power energy

system: composed of electrical design proﬁles plus

chemists for battery technologies experts; (d) com-

munications system – delivering the radio communi-

cation system for remote control and data collection;

(e) embedded software – composed by software en-

gineers with a focus on reliable embedded software

design and development, responsible for delivering

the main drone software, which controls the engines,

reads sensors, communicates with radios and also

has some autonomous routines for emergencies; (f)

weather data system – composed by statistical experts

on weather sensors allied with some electrical and

hardware design professionals, responsible for speci-

fying appropriate sensors to be used and for interpret-

ing their results. A specialized team division may be

Managing Scope, Stakeholders and Human Resources in Cyber-Physical System Development

used to support organizational or resource breakdown

structures. A specialized team division may include

varied departments or even external organizations.

Figure 6: Specialized team division (“plan human resource

management” process).

Figure 7: Specialized team division (“acquire team” pro-

cess).

4.3.2 Cross-training Technique

cross-training is a practice brieﬂy depicted in PM-

BOK, proposed to reduce impact when a team mem-

ber leaves the project. It consists in allocating more

than one resource to a task execution. For CPS

projects, we propose that the cross-training should be

always used to enable some team members acting as

a communication bridge between different sub-teams

by allocating a team member from a given area to

perform a task of some other area. This technique

is proposed to be used within the develop team pro-

cess, which is part of the planning process group.

Fig. 8 presents the proposed cross-training technique,

highlighted in bold, within the develop team pro-

cess. Considering cross-training, a software engi-

neer may sporadically follow a mechanical engineer’s

work with the purposed of understanding and even

positively contributing with potential ideas and in-

sights emerged from another outlook. Cross-training

can be used as a facilitator in the identiﬁcation and

development of multidisciplinary practitioners.

Figure 8: Cross-training (“develop team” process).

4.4 Stakeholder Management

Project stakeholders in CPS projects are usually

highly technical or very close to the system’s ﬁnal

users. This occurs mainly in joint projects of re-

search with universities, where the stakeholders are

researchers and students. Also in industrial projects to

improve production performance, where many stake-

holders are production leaders experts in many tech-

nologies of the area (Baheti and Gill, 2011). Due

to the diverse and complex nature of CPS project

stakeholders, we understand that speciﬁc techniques

should be applied to properly address this stakeholder

proﬁle to guarantee that the best results are achieved.

Consequently, two additional techniques are proposed

in CPS-PMBOK for stakeholder management: build

technical trust and dynamic follow-up strategies.

4.4.1 Build Technical Trust Technique

CPS projects tend to involve academic researchers or

experts to support the development of CPS physical

elements. They may represent technical stakeholders

who understand both the application and engineering

areas. PMBOK describes a practice of trust build-

ing for stakeholder engagement management, show-

ing that the company, team and even the manager

have competencies to accomplish project’s require-

ments in time and cost. Accordingly, an relevant ne-

cessity when involving stakeholders in CPS projects

is to build technical trust between them and the team.

In this context, CPS-PMBOK proposes a specializa-

tion of the trust building, adding the technical aspect

to this practice. Build technical trust is proposed

to be used within the manage stakeholder engage-

ment process, which is part of the executing process

group. Fig. 9 presents the proposed build technical

trust technique, highlighted in bold, within the man-

age stakeholder engagement process. Build techni-

cal trust means to pass technical conﬁdence regard-

ing project accomplishment conditions, considering

the team and project manager. Accordingly, the team

should get close to the stakeholders, mainly in situ-

ations in which the stakeholders are highly techni-

cal. For CPS-PMBOK, an internal expert or an ex-

ternal consultant should be put in charge of following

up the project management activities allowing more

technical stakeholders to be more comfortable with

the project progress. This person has the role of trans-

lating technical stakeholders concerns. The technical

trust may improve stakeholders’ satisfaction due to

their proximity and understanding of technical issues.

Besides that, the developers may feel more comfort-

able as well, due to the understanding of terms and

concerns provided by a expert or consultant.

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

Figure 9: Build technical trust and dynamic follow-up

strategies (“manage stakeholder engagement” process).

4.4.2 Dynamic Follow-up Strategies Technique

as observed in the outcomes of the systematic re-

view that embased this project, some authors iden-

tiﬁed that the proposed practices for communication

with stakeholders may be not enough to keep stake-

holders properly updated in a CPS project. Some

approaches found to improve communication with

CPS projects’ stakeholders are: face-to-face meetings

to update the project status to stakeholders (Huang

et al., 2012), stakeholders’ participation in every last

weekly follow-up meeting of development iterations

(Rong et al., 2011), and weekly workshops for sys-

tem demonstrating – to update stakeholders (Pen-

zenstadler and Eckhardt, 2012). Most of these ap-

proaches are based on agile methods, which has the

communication with stakeholders as one of their most

relevant concerns. To meet the different levels of de-

mand and satisfaction of stakeholders, we propose dy-

namic follow-up strategies as part of CPS-PMBOK.

The proposed technique is based on practices found

in literature with this purpose. This technique is pro-

posed to be used within two processes: the manage

stakeholder engagement process, which is part of the

executing process group; and the control stakeholder

engagement process, which is part of the monitor-

ing and controlling process group. Figures 9 and

10 present the proposed dynamic follow-up strategies

technique, highlighted in bold, within both the man-

age stakeholder engagement process and the control

stakeholder engagement process, respectively. Ac-

cording to different aspects of a given speciﬁc CPS

project, the project manager should adapt the follow-

up strategy to enhance stakeholder engagement and

reach their expectations. The following suggested

strategies are proposed: (i) during the project initia-

tion and planning stages, which involve, for example,

discovering of requirements and stakeholders, under-

standing of highly engaged stakeholders, and under-

standing of stakeholders’ application area – regular

face-to-face meetings should be adopted as follow-up

strategy; (ii) during the project execution and mon-

itoring stages, which involve, for example, resolu-

tion of requirements conﬂicts and alignment between

technical demands from stakeholders and project doc-

uments – only sporadic participation of stakehold-

ers could be included during planning and technical

meetings; and (iii) during the closing stage, which in-

volves, resource scarcity, time re-planning and stake-

holder staff updating – the stakeholders should be able

to follow up on the ﬁnal results via workshops with

live CPS demonstrations.

Figure 10: Dynamic follow-up strategies (“control stake-

holder engagement” process).

5 EVALUATION

To evaluate CPS-PMBOK, we conducted a qualita-

tive empirical analysis taking the experience of prac-

titioners working in an R&D organization. This orga-

nization was chosen because it develops CPS projects

and one of the researchers authoring this paper works

there. We consulted six managers and four develop-

ers. The evaluation was split into an in-person inter-

view and an online survey.

5.1 In-person Interviews

For the in-person interviews, we ﬁrstly presented to

these practitioners the proposed practices. For each

practitioner type, we presented a speciﬁc descrip-

tion of our approach. For managers, we explained

that CPS-PMBOK is a PMBOK-based approach that

aims to enhance CPS project success likelihood via

project management concepts focused on CPS devel-

opment. For developers, we emphasized that CPS-

PMBOK should be applied by project managers with

the collaborative presence of technical personnel, to

provide better conditions for the CPS project. Dur-

ing the approach presentation, we discussed, with

the practitioners, issues raised in CPS projects that

they have previously experienced, now considering

the practices proposed in CPS-PMBOK. Our purpose

with this evaluation phase was to raise critical analy-

sis regarding the CPS-PMBOK beneﬁts and feasibil-

ity. We conducted this evaluation individually, i.e.,

a practitioner at a time. We were not able to con-

duct a group evaluation due to the non-availability

of common hours by the involved practitioners, es-

pecially from those at managerial level. Nevertheless,

we developed a non-structured roadmap to increase

the chances of spontaneous feedback.

From the in-person interviews, we collected feed-

Managing Scope, Stakeholders and Human Resources in Cyber-Physical System Development

back from the practitioners, which allowed us to align

the understanding of CPS project concepts. How-

ever, while we asked the practitioners to evaluate the

proposed approach in a generic way, some feedback

seems to be strictly related to the organization where

the evaluation was conducted. Moreover, some devel-

opers showed knowledge about project management

and hence some of their opinions are more related to

managerial rather than technical aspects.

Table 1 summarizes the most relevant opinions.

Different types were recorded, including praises, crit-

icisms and suggestions. In some cases, we concluded

that CPS-PBMOK and the proposed practices have

not been properly presented since the raised criticism

or suggestions refer to items indeed addressed by our

approach. A large part of the suggestions is related

to possible extensions of the proposed models. Such

extensions or adaptations are in fact what is expected

to be done by practitioners with speciﬁc needs.

5.2 Online Survey

We used a structured questionnaire to gather the prac-

titioners’ opinions on the potential effectiveness and

relevance of each proposed practice. The practitioners

were expected to consider the corresponding knowl-

edge area to inform their opinions. We elaborated the

questions and possible responses considering a ﬁve-

points Likert-type scale. We chose standard ﬁve-level

responses to represent the perceived effectiveness of

each practice to its corresponding knowledge area.

The used responses are: totally disagree, partially dis-

agree, neutral, partially agree, and totally disagree.

Moreover, the practitioners were asked to inform if

they perceived each practice as relevant to two spe-

ciﬁc needs: (i) team communication and (ii) project

understanding. These two additional questions were

included to evaluate the proposed approach to our

main goals when proposing such practices. Lastly, we

also used a question with free-response style to allow

the practitioners to present general comments about

CPS-PMBOK and the practices.

Table 2 shows the results of the online survey ap-

plied to managers and developers. Although not sta-

tistically valid, sequential integers were assigned to

the categorical responses to allow the calculation of

a mean among the responses and obtain an overview

of the practitioners’ opinions, representing an aver-

age response. The following weights were used: to-

tally disagree (1), partially disagree (2), neutral (3),

partially agree (4) and totally agree (5). For contribu-

tion to the team communication and activities’ under-

standing needs, the answers were ‘yes’ or ‘no’.

Regarding effectiveness, both managers and de-

velopers reported a general perception with high rates.

For both groups, the practices together received an

average of 4.2, indicating a general response slightly

higher than ‘partially agree’. There were only some

small differences between both groups. For example,

managers’ general opinions vary from 4.0 to 4.3 while

developers’ general opinions vary from 3.8 to 4.5.

Both groups reported build technical trust with the

highest effectiveness. On the other hand, managers

reported review requirements with the lowest effec-

tiveness while developers reported it with the highest

effectiveness. Either way, the rating differences at-

tributed to them are very small.

Regarding contribution to team communication

and activities’ understanding, both groups also re-

ported a common general perception but with lower

values. For almost all cases, an average of 50% of the

practices were reported as contributing to both spe-

ciﬁc needs. Speciﬁcally for activities’ understand-

ing, managers reported the contribution of an aver-

age of 60% of the practices. Some notable differences

are identiﬁed within each group: some practices con-

tribute more to team communication than to activities’

understanding (as the specialized team division, ac-

cording to managers) while for some other practices

the opposite is noticed (as review requirements, ac-

cording to developers). Other notable differences are

identiﬁed between both groups: managers reported

that dynamic follow-up strategies highly contributes

to both team communication and activities’ under-

standing whereas developers reported it with a low

contribution to both speciﬁc needs. The opposite

was reported for the specialized team division. On

the other hand, both groups agree that cross-training

presents a good contribution for both.

5.3 Discussion of Results

We could observe some convergences and diver-

gences between the managers’ and developers’ opin-

ions. We analyzed some divergences to understand

their motivations.

The managers perceived review requirements as

one of the most contributors to team communication,

which was not expected by us (considering the on-

line survey, cf. Table 2). Although not initially ex-

pected, managers should have taken into account that

reviewing requirements requires collective coopera-

tion, mainly considering the proposed process simula-

tion technique. Review requirements was also consid-

ered as one of the most contributors to activities’ un-

derstanding, which is naturally understandable. Nev-

ertheless, review requirements is contradictorily one

of the two worst rated by managers in terms of gen-

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

Table 1: Feedback regarding the proposed management practices (Man – Manager / Dev – Developer).

Area / Feedback From

Project Integration Management

1 Life-threatening should be added as a characteristic in the model’s environment section. Man

2 The characterization model can support project planning activities such as estimating time or cost. Man

3 Available time, team and budget may inﬂuence the characterization model. Man

4 Something similar to the characterization model could be proposed to characterize the team. Man

5 The model’s characteristics could be weighted considering the proposers’ proﬁle and expertise. Man

6 This practice may inhibit creativity and innovation. Man

7 Levels ‘low’, ‘moderate’, ‘high’ should be better deﬁned. Dev

8 ‘Intelligence over data’ should be added as a characteristic in the model’s complexity section. Dev

9 ‘Hazardousness’ and related industrial standards should be added as a characteristic in the environment section. Dev

10 ‘Unknown’ should complement low/moderate/high levels. Dev

Project Scope Management

1 Pre-elaborated requirements lists should be provided when considering an exposed environment. Man

2 Pre-elaborated requirements lists and reviewing requirements should better connect with each other. Man

3 Reviewing requirements should be associated to risk management since they are closely related. Man

4 For pre-elaborated requirements lists, ﬁxed requirements is very risky due to different contexts of success. Dev

5 Process simulation, proposed for review requirements, should better integrate with other processes. Dev

6 Pre-elaborated requirements lists should guide team deﬁnition. Dev

Project Human Resource Management

1 Cross-training can be very useful as a parallel approach when the technologies involved are still quite unknown. Man

2 An architect role should be considered in a specialized team division to integrate all sub-teams involved. Man

3 Cross-training only works if all subteams practice it. Dev

4 An integration role is missing in the specialized team division; all sub-team leaders should act as integrators. Dev

Project Stakeholder Management

1 Dynamic follow-up strategies may be useful to show what is being achieved and avoid the need for changes. Man

2 Build technical trust can be useful to bring conﬁdence also to the team, not only to the stakeholders. Man

3 Build technical trust can be also useful to translate technical concerns and terms to the team. Man

4 Dynamic follow-up strategies should also be suggested as a technique to the scope management processes. Man

5 Build technical trust can be enriched by providing access to the team’s source code for technical stakeholders. Dev

6 Preparing for a follow-up workshop may be very costly considering its potential results as return. Dev

Table 2: Online survey responses (Eff – Effectivess [1-5] / TC – Team Communication / AU – Activities’ Understading).

Area Proposed practice

Managers Developers

Eff. TC AU Eff. TC AU

Integration Characterization model 4.0 33% 83% 4.3 50% 75%

Scope Review requirements 4.0 83% 83% 4.5 0% 75%

Pre-elaborated requirements lists 4.3 17% 67% 3.8 75% 50%

Human Resources Cross-training 4.2 50% 50% 4.5 75% 75%

Specialized team division 4.3 50% 17% 4.3 75% 75%

Stakeholder Build technical trust 4.3 33% 50% 4.5 50% 0%

Dynamic follow-up strategy 4.2 83% 67% 3.8 25% 0%

Average 4.2 50% 60% 4.2 50% 50%

eral effectiveness. This contradiction probably occurs

due to the risk of losing the project control seeing that,

if not properly managed, the requirements review can

make the project scope inﬁnite. This conclusion is

corroborated by one of the managers’ feedbacks (cf.

Table 1) that states: ‘Review requirements should be

formally associated to the risk management area since

both are closely related’.

The developers did not perceive any contribution

of review requirements for team communication, ex-

actly the opposite of the managers (considering the

online survey, cf. Table 2). In fact, there is no feed-

back from developers considering the in-person inter-

views (cf. Table 1), which indicates they really do

not see any importance for this practice. Another di-

vergence, taking the online survey, is for the activ-

ities’ understanding aspect, for which the managers

saw an relevant contribution of dynamic follow-up

strategies whereas the developers did not perceive any

contribution of it for this aspect. Moreover, the de-

velopers raised some cost issues related to his tech-

nique, considering the in-person interviews (cf. Table

1). On the another hand, developers indicated more

importance for the practices suggested to the human

resource management when comparing to the man-

agers’ opinions about these practices.

Managing Scope, Stakeholders and Human Resources in Cyber-Physical System Development

There is no consensus as to what suggested prac-

tices may contribute most to team communication.

For managers, review requirements and dynamic

follow-up strategies can do it, whereas, for develop-

ers, pre-elaborated requirements lists, cross-training

and specialized team division can. The other two

practices (characterization model and build technical

trust) were not well rated for both sides. In terms of

contribution to activities’ understanding, there were

some convergences between managers and develop-

ers. For example, both groups consider that charac-

terization model and review requirements are the most

relevant for this aspect, although they diverge in terms

of importance for the other practices.

For the organization where the evaluation was

conducted, the evaluation process allowed to recon-

sider its own organizational practices. The evaluation

allowed to know technical team members skills and

professional possibilities. Some legislative concerns

showed up, not addressed in CPS-PMBOK, such as

privacy and ﬂight rules for drones, and metering reg-

ulation in power grid communication systems. The

extinction of some professions in industry automa-

tion was also highlighted. Speciﬁc human resource

issues appeared in the discussions, which may depend

on country and organization developing the CPS sys-

tem, such as availability or suitability of profession-

als. Nevertheless, dispite the differences among coun-

tries, very speciﬁc proﬁle resources may be a problem

for every organization in any country, such as a physi-

cist specialized in light propagation, for example.

One of the suggestions from developers was to

provide a way to keep every person involved in the

project, by using a wiki, for example. This technique

can be aggregated to specialized team division, as-

signing the updating tasks to a speciﬁc support team.

The role of an architect or integrator appeared twice

in feedbacks: one from managers and other from de-

velopers. But in the developers context, it was sug-

gested that the leader for each team could do this role.

Since the goal is to get together all information about

current development in one person, this can create an-

other need: a leader integrator. The most wise strat-

egy would be the assignment of the architect or in-

tegrator role to one person who gather skills of lead-

ership, technical experience, impartiality and a good

understanding of the project. If it was not possible to

ﬁnd this professional proﬁle, then the creation of an

integration team may be needed.

As stated by other authors, social issues seemed

to inﬂuence the evaluation: some managers showed

more interest in taking part of this research

project, understanding the academic context involved,

whereas others faced it as a work evaluation, ques-

tioning the need to review their project management

methods. Some raised issues leed to concerns related

to relevant subjects for CPS research, wich are not the

focus of this research, such as: types of project life-

cycles, software development methods, and project

funding strategies. Since the organization in case is

both industry and research-driven, issues related to

project ﬁnal goals showed up, such as any project to

creating a product, methods or an art study for wider

R&D projects. These issues indicate that particu-

lar reﬁnements of CPS-PMBOK or other approaches

may be necessary according to the ﬁnal project goal,

which connects to the success deﬁnition, as cited by

one of the managers. Although these points can also

be speciﬁc for each organization or country, it is rel-

evant for the CPS-PMBOK application, mainly in

scope and human resource management, since some

requirements and team members can never change

due to legal requirements in case of R&D projects

funded by the government, for example.

6 CONCLUSION

This work proposed project management practices

driven to CPS projects. The approach is based on

PMI’s PMBOK best practices and focused on inte-

gration, scope, human resource and stakeholder. CPS-

PMBOK relies on the following requirements for CPS

projects: multidisciplinary teams, high level of inno-

vation and unpredictable requirements. The approach

was presented to managers and developers to evalu-

ate its potential beneﬁts, feasibility and effectiveness

and collect feedback. Both groups were excited about

applying it to their organization and found it partic-

ularly audacious and innovative, mainly considering

some characteristics imported from agile methods.

The feedback allows us to improve CPS-PMBOK

considering a series of opportunities. Our challenge

is to be able to evolve the proposed practices, includ-

ing proposing new ones, considering two needs that

can be seen as antagonistic ones: for one hand, being

speciﬁc to the CPS project domain; but, for the other

hand, being not too speciﬁc to allow adjustments as

required for speciﬁc contexts and organizations.

REFERENCES

Baheti, R. and Gill, H. (2011). Cyber-physical systems. The

Impact of Control Tech., 12:161–166.

Berger, C. and Rumpe, B. (2010). Supporting agile change

management by scenario-based regression simulation.

IEEE Trans. on Intel. Transp. Syst., 11(2):504–509.

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

Chen, Y. M. and Wei, C.-W. (2009). Multiagent approach

to solve project team work allocation problems. Int. J.

of Prod. Res., 47(13):3453–3470.

Deshpande, S., Beecham, S., and Richardson, I. (2013).

Using the PMBOK guide to frame GSD coordination

strategies. In 8th Int. Conf. on Glob. Soft. Eng., pages

188–196.

Faschang, M., Kupzog, F., Widl, E., Rohjans, S., and Lehn-

hoff, S. (2015). Requirements for real-time hardware

integration into cyber-physical energy system simula-

tion. In Work. on Mod. and Sim. of Cyb.-Phys. Energy

Sys., pages 1–6.

Garay, J. R. B. and Kofuji, S. T. (2010). Architecture for

sensor networks in cyber-physical system. In Latin-

Amer. Conf. on Commun., pages 1–6.

Golini, R. and Landoni, P. (2014). Int. development

projects by non-governmental organizations: An eval-

uation of the need for speciﬁc project management

and appraisal tools. Impact Asses. and Proj. Appr.,

32(2):121–135.

Greene, B. (2004). Agile methods applied to embedded

ﬁrmware development. In Agi. Dev. Conf., pages 71–

77.

Helps, R. and Mensah, F. N. (2012). Comprehensive design

of cyber physical systems. In 13th Ann. Conf. on Inf.

Tech. Educ., pages 233–238.

Huang, P. M., Darrin, A. G., and Knuth, A. (2012). Agile

hardware and software system engineering for inno-

vation. In Aeros. Conf., pages 1–10.

Insaurralde, C. C. and Petillot, Y. R. (2013). Cyber-physical

framework for early integration of autonomous mar-

itime capabilities. In Int. Sys. Conf., pages 559–566.

Jun, D., Rui, L., and Yi-min, H. (2007). Software processes

improvementement and speciﬁcations for embedded

systems. In 5th ACIS Int. Conf. on Soft. Eng. Res.,

Man. & Appl., pages 13–18.

Lattmann, Z., Klingler, J., Meijer, P., Scott, J., Neema, S.,

Bapty, T., and Karsai, G. (2015). Towards an analysis-

driven rapid design process for cyber-physical sys-

tems. In Int. Symp. on Rapid Sys. Prot., pages 90–96.

Lee, E. A. (2008). Cyber physical systems: Design chal-

lenges. In 11th Int. Symp. on Obj. Ori. Real-Time

Distr. Comp., pages 363–369.

Lee, E. A. and Seshia, S. A. (2017). Introduction to Em-

bedded Systems: A cyber-physical Systems Approach.

Lee & Seshia, 2nd edition.

Lester, A. (2014). Project Management, Planning and Con-

trol: Managing Engineering, Construction and Man-

ufacturing Projects to PMI, APM and BSI Standards.

Butterworth-Heinemann, 6th edition.

Madachy, R., Boehm, B., and Lane, J. A. (2007). Assessing

hybrid incremental processes for SISOS development.

Soft. Proc.: Imp. and Prac., 12(5):461–473.

Madachy, R. J. (2008). Cost modeling of distributed

team processes for global development and software-

intensive systems of systems. Soft. Proc.: Imp. and

Prac., 13(1):51–61.

Palma, F., Fantinato, M., Rafferty, L., and Hung, P. (2018).

Enhancing project management for cyber-physical

systems development. In Fed. Conf. on Comp. Sci.

and Inf. Sys., pages 747–750.

Pandi-Perumal, S. R., Akhter, S., Zizi, F., Jean-Louis,

G., Ramasubramanian, C., Freeman, R. E., and

Narasimhan, M. (2015). Project stakeholder manage-

ment in the clinical research environment: How to do

it right. Front. in Psyc., 6:71.1–71.18.

Parkhomenko, A. V. and Gladkova, O. N. (2014). Virtual

tools and collaborative working environment in em-

bedded system design. In 11th Int. Conf. on Remote

Eng. and Virt. Inst., pages 90–93.

Penzenstadler, B. and Eckhardt, J. (2012). A require-

ments engineering content model for cyber-physical

systems. In 2nd Work. on Req. Engi. for Sys., Serv.

and Sys.of-Sys., pages 20–29.

PMI (2013). Guide to the Project Management Body of

Knowledge. Project Management Institute.

Rajkumar, R. R., Lee, I., Sha, L., and Stankovic, J. (2010).

Cyber-physical systems: The next computing revolu-

tion. In 47th Des. Autom. Conf., pages 731–736.

Reusch, P. J. A. (2015). Extending project management pro-

cesses. In 8th Int. Conf. on Int. Data Acq. and Adv.

Comp. Sys.: Tech. and Appl., pages 511–514.

Rong, G., Shao, D., Zhang, H., and Li, J. (2011). Goal-

driven development method for managing embedded

system projects: An industrial experience report. In

Int. Symp. on Emp. Soft. Eng. and Meas., pages 414–

423.

Sapienza, G., Crnkovic, I., and Potena, P. (2014). Architec-

tural decisions for hw/sw partitioning based on mul-

tiple extra-functional properties. In IEEE/IFIP Conf.

on Softw. Archit., pages 175–184.

Savio, D., Anitha, P. C., and Iyer, P. P. (2011). Consider-

ations for a requirements engineering process model

for the development of systems of systems. In 1st

Work. on Req. Engin. for Sys., Serv. and Sys.-of-Sys.,

pages 74–76.

Sha, L., Gopalakrishnan, S., Liu, X., and Wang, Q. (2009).

Cyber-physical systems: A new frontier. In Tsai, J.

J. P. and Yu, P. S., editors, Machine Learning in Cyber

Trust: Security, Privacy, and Reliability, pages 3–13.

Shatil, A., Hazzan, O., and Dubinsky, Y. (2010). Agility in a

large-scale system engineering project: A case-study

of an advanced communication system project. In Int.

Conf. on Soft. Sci., Tech. and Eng., pages 47–54.

Shen, Y., Tuuli, M. M., Xia, B., Koh, T. Y., and Rowlin-

son, S. (2015). Toward a model for forming psycho-

logical safety climate in construction project manage-

ment. Int. J. of Proj. Man., 33(1):223–235.

Silva, C. M. B. d., Loubach, D. S., and Cunha, A. M. d.

(2009). An estimation model to measure computer

systems development based on hardware and soft-

ware. In 28th Dig. Avi.Sys. Conf., pages 6C2.1–

6C2.12.

Singh, M. P. (2013). Norms as a basis for governing so-

ciotechnical systems. ACM Trans. on Int. Sys. and

Tech., 5(1):21.

Wolff, C., Gorrochategui, I., and Bücker, M. (2011). Man-

aging large HW/SW codesign projects. In 6th Int.

Conf. on Int. Data Acq. and Adv. Comp. Sys., pages

919–922.

Yue, T. and Ali, S. (2014). Applying search algorithms

for optimizing stakeholders familiarity and balancing

workload in requirements assignment. In Conf. on

Gen. and Evol. Comp., pages 1295–1302.

Zhu, J. and Mostafavi, A. (2014). Towards a new paradigm

for management of complex engineering projects: A

system-of-systems framework. In 8th Ann. IEEE Sys.

Conf., pages 213–219.

Managing Scope, Stakeholders and Human Resources in Cyber-Physical System Development