Download pdf - A Model for Effective Area of Hybrid Approach Combining

Journal of International Association of P2M Vol.13 No.1, pp. 52-70, 2018 Research Paper

† ††

PTC Japan / Graduate School of System Design and Management, Keio University Graduate School of System Design and Management, Keio University

52

A Model for Effective Area of Hybrid Approach Combining Agile and Plan-Driven Methods in IT Project

Takeomi IMANI†

Masaru NAKANO††

Conventional, IT system development organizations have selectively utilized the two tech-

niques: plan-driven method in which requirements are defined and baselined in early phase of the project

and agile method which is based on iterative development. Recently, the research articles that reported a

hybrid approach that uses plan-driven and agile method together have been on the rise. However, few the-

oretical studies have investigated the contextual conditions that illustrates a better fit for hybrid approach,

called effective area. This research is aimed to provide an analysis model of hybrid approach by evaluat-

ing project characteristics and iteration development strategy. Our model and numerical simulations pre-

sent that a hybrid approach should be fit with wider context of project characteristics than the agile

method. By investigating the effective area with multiple parameters, this research would contribute to a

growing literature of hybrid approach and a methodology for project manager or project management of-

fice to choose hybrid approach appropriately. Furthermore, this paper introduces a discussion of the man-

agement methodology in the Scheme-System-Service (3S) model of the Japanese Project and Program

management (P2M) studies, where very few studies have suggested the management methodologies of

the hybrid approach.

Keywords: IT System Development, Agile, Plan-driven, Hybrid Approach, Effective Area

1. INTRODUCTION

It is a common experience in software development projects that project managers often deal with both

project control issues and fast responses to changes in the project. The challenge in managing software

development and IT projects comes from the fact that diverse stakeholders seek for the both predictability

of project and flexibility of the requirements due to uncertain business circumstances. Conventional IT

system development organizations have selectively utilized the two techniques: the plan-driven method

in which requirements are defined and base-lined in the initial phase of the project [1], and the agile method

which is based on iterative, incremental development of the project scope [2,3,4]. The plan-driven, also

called Waterfall method, is a software development process that consists of sequential phases that are

linear. Phases in the plan-driven typically include requirements analysis, design, implementation, testing

T. IMANI, et al. Journal of IAP2M.

53 Vol.13 No.1 (Oct., 2018)

and operation, and requires a sign-off of the project manager to proceed to the subsequent phases. Re-

quirements are base lined before design and implementation is started using the integrated change control

process. Thus, after finalizing the requirements in the initial phase, the customer involvement is limited.

On the other hand, re-planning with customers is carried out even during the execution phase iteratively

in agile method. Although high-level requirements can be collected early in the project, team should re-

peatedly prioritize detailed requirements. A global research claims that 50% of projects have employed

agile method [5].

Agile method includes more than six frameworks and practices [6]. The most popular ones are Scrum [3], Extreme Programming [2], Crystal [8], Dynamic Systems Development Method [8], Lean software de-

velopment [9] and Feature Driven Development [10]. The Agile Manifesto [11] consists of four value state-

ments:

Individuals and Interactions over Processes and Tools

Working Software over Comprehensive Documentation

Customer Collaboration over Contract Negotiation

Responding to Change over Following a Plan

One of the features of the agile method is iterative scope definition and development, and incremental

delivery [12,13,14]. The purpose of the agile method is to deliver reliable and innovative products within the

cost and schedule constraints and, to mitigate risks proactively by managing the uncertainty with an iter-

ative process [13]. Agile project team must cope with rapid change of the project plan and active involve-

ment of customers [15]. Project members in agile method should be able to improve productivity through

with iterative incremental process and the active involvement of key customer members. However, a few

other research studies mentioned that there is no significant difference on success rate between agile and

plan-driven methods, and that rather the efficiency of the Agile should be lower [16,17]. Under these

circumstances, it might not be feasible for project managers to identify effectiveness and benefits of agile

methods properly.

Furthermore, recently software development has been more often positioned as a critical subsystem in

a complex and large-scale product development projects, whereby innovative outcomes are expected ex-

peditiously while phase gates are applied to mitigate risks. Agile approach alone should not be enough to

produce desired results. Therefore, it is no surprise that research shows an increased number of studies

focusing a hybrid approach that uses plan-driven and agile-method together [12, 15, 18]. Recent research

articles reported a rise in using hybrid approach of plan-driven and agile methods combined together for

enterprise level projects [15,17,18,19]. Consequently, practitioners are faced with three options: plan-driven,

agile methods and hybrid approach [18,20, 21]. Furthermore, we interviewed twenty project management

Journal of IAP2M T. IMANI, et al.

Vol.13 No.1 (Oct., 2018) 54

professionals and practitioners and administered a survey questionnaire targeting project managers in

approximately 150 companies [22,23]; results show a need for a systematic selection of hybrid approach in

large-scale IT system development projects.

However, most of the existing research evaluated the effective area of hybrid approach or agile method

(the contextual conditions that illustrates a better fit for hybrid approach or agile method) qualitatively.

One contrasting claims can be found project size and the agile effectiveness: in some cases, the agile

method is recommended for small project teams [24], whereas other studies claim that applying the agile

should not depend on the scale [13,25,26]. Boehm [12] recommends a hybrid strategy of agile and plan-driven

approach. The hybrid approach is selected based on analysis of the risk associated with critical tasks.

However, in the case of large-scale projects, quantitative analysis of project risk alone may not be suffi-

cient for the selection of hybrid approach due to large iterative, incremental developments associated with

the project [13, 27]. The project characteristics and technical maturity of iterative development (iteration

development strategy) are considered to decide whether the agile or hybrid approach would be effective

[7, 20, 28]. However, it is evident that the past research did not provide a systematic decision process to

choose hybrid approach. Further, literature review did not present an effective area and the boundary

conditions to choose among the hybrid approach, agile and plan-driven methods.

To address this knowledge gap, this research is aimed to provide an analysis model of hybrid approach

by evaluating project characteristics and iteration development strategy. This paper focuses on a research

question: how can the project manager analyze and determine where the hybrid approach is effective? It

is based on the project management contingency theory which asserts that a suitable project management

approach must be adapted based on situations [29]. To analyze the effective area of hybrid approach, agile

or plan-driven, the researchers may need a qualitative evaluation of fit with project characteristics and

competencies of project members [30]. However, as the research on hybrid approach is an emerging re-

search area, it would be more appropriate to formulate a mathematical model with multiple variables of

project characteristics and development strategies. We develop a mathematical cost (work effort) com-

parison model to examine the contextual conditions that illustrates a better fit for hybrid versus agile or

plan-driven method. This study refers to Boehm’s agile home ground framework [12] as a theoretical lens

for choosing model parameters, which consists of project size, criticality, rate of changes. We conducted

the empirical study of the success rates on quality, cost, and delivery (QCD) of the projects where the

agile, the plan-driven methods and the hybrid approach [23], but it may be practical to select a total project

cost (work effort) as a measurable explanatory variable, as previous research reported 7-8% cost reduction

in hybrid approach by reducing the documentation and change control/response costs [18].

Our model and numerical simulation results will show that the hybrid approach can be used in wider

range of projects characterized with a higher uncertainty of requirements. While the agile method needs


55 Vol.13 No.1 (Oct., 2018)

more coordination work effort due to the less documentation, the hybrid approach requires less coordina-

tion by utilizing the high-level requirement documents defined before the iterative development. Whereas

Boehm proposed risk-based approach with five steps from a software engineering perspective [12], the

analysis method of this study could provide a more practical decision support process with structured

inputs of project characteristics and iterative development effectiveness. This research besides should

contribute to formulating a methodology for project manager or project management office to choose

hybrid approach appropriately under a wide range of project environment and circumstances.

Remaining sections of this paper are organized as follows. Next section presents a review of the existing

literature about relationships among the project characteristics, iteration development strategy, and a hy-

brid approach. Following the literature review section, our model and numerical simulation results are

described. Finally, the concluding section presents managerial implications and limitations of this study.

2. LITERATURE REVIEW This section presents a review of the existing literature about hybrid approach, project characteristics and

iteration effectiveness, and defines the main parameters of the model this paper presents.

2.1 Hybrid Approach

The literature review reveals two types of hybrid approach. The first approach is to use both traditional

plan-driven and the agile by phase [12,17,18,29,31], which we call “Hybrid by phases”. The second one is to

utilize the mixed practices such as Scrum and XP, or to use an estimation tool of plan-driven approach in

agile development [16, 32, 33, 34], which we call “Hybrid by methods”.

Additionally, the hybrid approach can be applied to both IT and non-IT projects. The “Risk-based

approach” indicated a sweet spot by analyzing the minimization of the total risk exposure of change costs

and the delay cost of planning the critical tasks with an exploratory variable of up-front planning work

effort [12]. The hybrid approach would be effective in a large system development project where the or-

ganizational and the contractual issues will hinder the iterative development process of agile process [18].

On the other hand, the hybrid approach in a stage-gate model is often used for in hardware product devel-

opment projects of small companies [15]. Due to an increasing number of practitioners’ articles [18,27], this

paper will focus on a “Hybrid by phases” in Figure 1 [23] for IT system development projects.


Vol.13 No.1 (Oct., 2018) 56

Figure 1: Types of hybrid approach. (Adopted from the paper of Imani, Nakano et al [23] )

2.2 Project Characteristics

The project characteristics and project environment [28, 30, 35, 36] should be necessary to analyze effective

area of hybrid approach with that of plan-driven or agile. This paper will employ Boehm’s agile home

ground as a theoretical lens for building a theoretical model [12], which consists of project size, criticality,

rate of changes, culture, and people. The model in this paper contains the first three dimensions of from

the five and extend the ground by analyzing in an integrated manner taking into account of hybrid ap-

proach. The remaining two, culture and people, are related to soft skills and out of scope in this paper

since the proposed model focuses on project characteristics.

Project Size

The agile approach should be suitable for small projects, and not for large-scale projects. The number

of team members has been recommended from five to nine [37] to be self-managed, and it might be not

feasible to create the self-managed team in large-scale projects. Listing 14 assumptions and 6 constrains

of agile [4] stated that in a large team size requires that documents be used for coordination among a

number of members and that the effectiveness and frequency of face-to-face meetings should be limited.

However, other research studies have shown that the agile method can be applicable for large-scale pro-

jects by utilizing project management teams representing various disciplines and clearly defining roles

and responsibilities [12, 13, 38, 39]. In large-scale projects, the coordination between teams and dependencies

among component projects should be managed [14, 40]. While there are several indicators of project size


57 Vol.13 No.1 (Oct., 2018)

such as size of products, cost or number of project members, this paper will focus on the number of the

teams [41].

Criticality

Criticality would be defined as the extent to which project success or failure impacts the environment

and business circumstances [12]. The high critical projects may require a large amount of documentation

for rigorous quality assurance, reliability, and regulatory and legal compliance [25]. Furthermore, the pro-

ject manager may need more effort of quality management composed of system assurance and contin-

gency planning. In our theoretical model, the criticality will be evaluated with qualitative scales to impact

the test and documentation costs. Even in the hybrid or the agile method, high criticality projects hypoth-

esize in our calculation to require the similar amount of documentation as the plan-driven.

The agile method is considered not suitable for projects with high safety requirements due to a large

amount of documentation for strict quality assurance, reliability and compliance for laws and regulations [12, 28]. However, others claim that the agile can use the iterative verification and validation to response

changes even in high criticality projects [25, 41]. Our theoretical model which introduces hybrid approach

is expected to address these discrepancies.

Rate of Change

Rate of change is caused not only by the uncertainty of requirements and solutions but also by the

external environment changes of the project. When the requirement is unclear or ambiguous, critical func-

tions may be missing. Consequently, a significant amount of rework may result after the final validation

by customers [43]. Likewise, unclear solution will lead to critical deficiencies and project cannot reach the

expected and desired quality target, which would result in a major rework [7].

Two types of project rework effort are noted in literature. One is the rework of an individual project

task [7, 44]. Second is the large-scale rework of the overall project (rework project). Rework projects are

risky due to urgency, quality, and technological changes and they are often costly, undesirable, and un-

necessary [45]. Our proposed theoretical model will include a probability parameter of overall project re-

work caused by changes, which would in many times impact the project management significantly.

2.3 Iteration effectiveness

The agile development is generally iterative with short-term cycle with a light-weight process [12] and

project managers need to plan the iterative development and incremental delivery of function-based fea-


Vol.13 No.1 (Oct., 2018) 58

tures [13, 14]. However, the iterative development is not easy in large-scale projects [7]. The issues of itera-

tive incremental development (iterative development) are twofold: they are management and technical

perspectives.

From a management perspective, project managers of iterative development of agile method, as a pro-

active risk mitigation measure to manage uncertainties [12], tend to involve customers [27, 46] to prioritize

detail requirements and validate them using review meetings [27, 40]. Hybrid approach also needs to execute

iterative development efficiently by collaborating with customers [18]. From technical perspective, the

iterative development process of the agile or hybrid should enable project team members to deliver incre-

mentally tested codes in a relatively short time [18]. A strategy of continuous integration or automatic

testing should be a hurdle to execute the agile approach in a large-scale project [27] although research

showed that technology strategy, continuous delivery, and automatic testing are considered critical factors

for the agile [35].

In this research, the effectiveness of iteration development is defined as to the extent the probability of

rework is reduced in each iteration. A higher level of iteration development strategy will enable customers

to review the outcomes in each iteration with a working system and realize a greater benefit on reducing

project rework.

3. MODEL DESCRIPTION

This section will provide a model to analyze the effective area of hybrid, agile, and plan-driven methods

focusing on IT system development projects. It may be practical to select a total project cost (work effort)

as a measurable explanatory variable or output. Although a simulation study suggest that the hybrid ap-

proach is an optimized case in terms of the project cost benefit [47], the relationships of the number of

development teams (size) might not be clear, and thereby project size factor is explicitly included in our

model. Reducing the documentation and costs associated with change control/response can lead to 7-

8% reduction in cost, in spite of 20% of change associated with planned cost [18]. These numbers will be

used as reference data to choose the number of parameters of our model. Figure 2 depicts our model

design based on the existing literature in the previous section, our interviews and survey data analysis [23].


59 Vol.13 No.1 (Oct., 2018)

Figure 2: Model design.

The formula below presents the cost comparison rate calculation, which is the objective functions of

our model.

𝐶𝐶𝐶𝐶ℎ𝑦𝑦−𝑝𝑝𝑝𝑝(𝑝𝑝,𝑚𝑚, 𝑐𝑐) = 𝑇𝑇𝑇𝑇ℎ𝑦𝑦−𝑇𝑇𝑇𝑇𝑝𝑝𝑝𝑝𝑇𝑇𝑇𝑇𝑝𝑝𝑝𝑝

(1)

𝐶𝐶𝐶𝐶ℎ𝑦𝑦−𝑎𝑎𝑎𝑎(𝑝𝑝,𝑚𝑚, 𝑐𝑐) = 𝑇𝑇𝑇𝑇ℎ𝑦𝑦−𝑇𝑇𝑇𝑇𝑎𝑎𝑎𝑎𝑇𝑇𝑇𝑇𝑎𝑎𝑎𝑎

(2)

𝐶𝐶𝐶𝐶𝑎𝑎𝑎𝑎−𝑝𝑝𝑝𝑝(𝑝𝑝,𝑚𝑚, 𝑐𝑐) = 𝑇𝑇𝑇𝑇𝑎𝑎𝑎𝑎−𝑇𝑇𝑇𝑇𝑝𝑝𝑝𝑝𝑇𝑇𝑇𝑇𝑝𝑝𝑝𝑝

(3)

CB: Cost comparison rate [12, 16, 47]

TC: Total cost (work effort) [43]

pd: Represents plan driven [1]

hy：Represents hybrid [18]

ag：Represents agile [7]

p：Rework probability [12

m：Project size (team size) [13, 41]

c：Criticality [12, 25]

ie：Iteration effectiveness [13, 14, 27]


Vol.13 No.1 (Oct., 2018) 60

For example, if the 𝐶𝐶𝐶𝐶ℎ𝑦𝑦−𝑝𝑝𝑝𝑝 is positive, the hybrid approach is more effective on total cost than the

plan-driven method.

3.1 Total cost (work effort)

The mathematical formula described below and its numerical simulation results present the effective ap-

plication area of the hybrid, by comparing its total cost with that of the plan-driven and the agile methods.

The conditions and assumptions of the model are:

The cost is defined as the work effort of project team members.

The more the number of teams, the more the cost of coordination among the

teams

With the hybrid and the agile methods, the probability of project rework is re-

duced in each iteration by a geometric series

The cost calculation does not include maintenance or operation cost after the

project closure

The total cost of project can be written as below [43].

𝑇𝑇𝐶𝐶 = 𝑅𝑅𝑅𝑅𝑅𝑅 + 𝐷𝐷𝑅𝑅𝐷𝐷 + 𝑉𝑉𝑉𝑉𝑉𝑉 + 𝐶𝐶ℎ𝑔𝑔 + 𝐶𝐶𝐶𝐶𝐶𝐶 + 𝑀𝑀𝑔𝑔𝑀𝑀 (4)

TC: Total cost

Req: The cost for planning and requirement phase including high-level design

Dev: The cost for development phase including the detail design and unit test

Val: The cost for test and validation phase including the deployment cost

Chg: Change (rework) cost

Cod: Coordination cost

Mgt: Managerial (documentation cost)

The calculation logic for each variable is different for each method. The cost for each phase is input

variable of the model when the plan-driven is adopted. In hybrid approach, our model is created by

formula where the cost of requirement (Req) and test (Val) are smaller than that of the plan-driven by a

factor, and those differences are included in the cost of iterative development (Dev). Req and Val in the

agile method are included in the cost of Dev. For model calculation of the hybrid approach, the number

of iteration development is smaller compared with that of the agile, because the hybrid could have a test

and validation phase in addition to the iterative development, and thereby the duration of all iterations in

hybrid is shorter than in agile.


61 Vol.13 No.1 (Oct., 2018)

The change (rework) cost is calculated by the two input variables: rework probability and change

magnitude. Considering that changes in the agile or the hybrid may cause further changes after the tests,

we used a infinite geometric series for change cost calculation [43]. The probability of changes in the hybrid

approach or the agile methodwill be reduced by a factor after each iteration development cycle.

The bigger the project size, the bigger the coordination among teams. The coordination would be

generally defined as the management of the dependencies [48]. For the purpose of this research, the cost

for the coordination is differently calculated among the hybrid, the agile and the plan-driven methods. In

the hybrid and the plan-driven, we hypothesize that documents are necessary for requirement and testing

phase and that the project size affects the coordination cost by the number of teams (linear). In the agile,

the work effort of the meetings such as iteration planning and reviews would be much more than that of

the plan-driven, and thereby our calculation logic will increase the coordination effort in the agile by the

second order as the number of teams increase the number of communication paths [12].

Criticality would be defined as the extent to which project success or failure impacts the environment

and business circumstances [12]. The high critical projects may require a large amount of documentation

for rigorous quality assurance, reliability, and regulatory and legal compliance [25]. Furthermore, the

project manager may need more effort of quality management composed of system assurance and

contingency planning. In our theoretical model, the criticality will be evaluated with qualitative scales to

impact the test and documentation costs. Even in the hybrid or the agile method, high criticality projects

hypothesize in our calculation to require the same amount of documentation as the plan-driven.

3.2 Plan-driven method

The total cost is calculated by the work effort by phases, efforts for changes and coordination, and

management work effort for documentation [43].

𝑇𝑇𝐶𝐶𝑝𝑝𝐶𝐶 = 𝑅𝑅𝑅𝑅𝑅𝑅𝑝𝑝𝐶𝐶 + 𝐷𝐷𝑅𝑅𝐷𝐷𝑝𝑝𝐶𝐶 + 𝑉𝑉𝑉𝑉𝑉𝑉𝑝𝑝𝐶𝐶 + 𝐶𝐶ℎ𝑔𝑔𝑝𝑝𝐶𝐶 + 𝐶𝐶𝐶𝐶𝐶𝐶𝑝𝑝𝐶𝐶 + 𝑀𝑀𝑔𝑔𝑀𝑀𝑝𝑝𝐶𝐶 …(5)

𝑇𝑇𝐶𝐶𝑝𝑝𝑝𝑝: Total cost (work effort) of project

𝑅𝑅𝑅𝑅𝑅𝑅𝑝𝑝𝑝𝑝: Cost for planning and requirement phase

𝐷𝐷𝑅𝑅𝐷𝐷𝑝𝑝𝑝𝑝: Cost for design and development phase

𝑉𝑉𝑉𝑉𝑉𝑉𝑝𝑝𝑝𝑝: Cost for integration test and validation phase

𝐶𝐶ℎ𝑔𝑔𝑝𝑝𝑝𝑝: Cost for changes

𝐶𝐶𝐶𝐶𝐶𝐶𝑝𝑝𝑝𝑝: Cost for coordination between teams

𝑀𝑀𝑔𝑔𝑀𝑀𝑝𝑝𝑝𝑝: Management (documentation) cost


Vol.13 No.1 (Oct., 2018) 62

The change cost is calculated from the change volume times change rework probability with secondary

infinite change effects [43].

𝐶𝐶ℎ𝑔𝑔𝑝𝑝𝑝𝑝 = 𝐶𝐶ℎ𝐷𝐷 × 𝑝𝑝1−𝑝𝑝

, 𝐶𝐶ℎ𝐷𝐷 = 𝐶𝐶ℎ𝑝𝑝 × (𝐷𝐷𝑅𝑅𝐷𝐷𝑝𝑝𝑝𝑝 + 𝑉𝑉𝑉𝑉𝑉𝑉𝑝𝑝𝑝𝑝) ………………. (6)

𝐶𝐶ℎ𝑔𝑔𝑝𝑝𝑝𝑝: Change rework cost in plan-driven

Chv: Change volume

𝐶𝐶ℎ𝑝𝑝: Change proportion per development and validation cost

p: Rework probability after validation phase

i: Geometric series number index of change of changes

The coordination work effort [48] is composed of the ones in requirement phase and validation phase. Not

for development phase because the development specification is sent via documents.

𝐶𝐶𝐶𝐶𝐶𝐶𝑝𝑝𝑝𝑝 = 𝐶𝐶𝐶𝐶𝐶𝐶𝑟𝑟𝑟𝑟𝑟𝑟 + 𝐶𝐶𝐶𝐶𝐶𝐶𝑣𝑣𝑎𝑎𝑣𝑣, 𝐶𝐶𝐶𝐶𝐶𝐶𝑟𝑟𝑟𝑟𝑟𝑟 = 𝛼𝛼 × 𝑅𝑅𝑅𝑅𝑅𝑅𝑝𝑝𝑝𝑝 × (𝑚𝑚− 1) ……………….(7)

𝐶𝐶𝐶𝐶𝐶𝐶𝑣𝑣𝑎𝑎𝑣𝑣 = 𝛼𝛼 × 𝑉𝑉𝑉𝑉𝑉𝑉𝑝𝑝𝑝𝑝 × (𝑚𝑚− 1)

𝐶𝐶𝐶𝐶𝐶𝐶𝑝𝑝𝑝𝑝: Coordination cost among teams

𝐶𝐶𝐶𝐶𝐶𝐶𝑟𝑟𝑟𝑟𝑟𝑟: Coordination cost in requirement phase

𝐶𝐶𝐶𝐶𝐶𝐶𝑣𝑣𝑎𝑎𝑣𝑣: Coordination cost in validation phase

m: Number of teams

𝛼𝛼: Coordination parameter in requirement and validation phase

The management cost here is composed of the documentation cost in all phases [25].

𝑀𝑀𝑔𝑔𝑀𝑀𝑝𝑝𝑝𝑝 = (𝑅𝑅𝑅𝑅𝑅𝑅𝑝𝑝𝑝𝑝 + 𝐷𝐷𝑅𝑅𝐷𝐷𝑝𝑝𝑝𝑝 + 𝑉𝑉𝑉𝑉𝑉𝑉𝑝𝑝𝑝𝑝) × 𝐷𝐷𝐶𝐶𝑐𝑐𝑝𝑝𝑝𝑝……..…………………..…(8) 𝑀𝑀𝑔𝑔𝑀𝑀𝑝𝑝𝑝𝑝: Management cost

𝐷𝐷𝐶𝐶𝑐𝑐𝑝𝑝𝑝𝑝: Proportion of the documentation

3.3 Agile method


management work effort for documentation. In agile, the iteration development contains iteration

planning, development and test/reviews [13].

𝑇𝑇𝐶𝐶𝑉𝑉𝑔𝑔 = 𝑅𝑅𝑅𝑅𝑅𝑅𝑉𝑉𝑔𝑔 + 𝐷𝐷𝑅𝑅𝐷𝐷𝑉𝑉𝑔𝑔 + 𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑔𝑔 + 𝐶𝐶ℎ𝑔𝑔𝑉𝑉𝑔𝑔 + 𝐶𝐶𝐶𝐶𝐶𝐶𝑉𝑉𝑔𝑔 + 𝑀𝑀𝑔𝑔𝑀𝑀𝑉𝑉𝑔𝑔 ……..…(9)

𝑅𝑅𝑅𝑅𝑅𝑅𝑎𝑎𝑎𝑎 = 𝛽𝛽 × 𝑅𝑅𝑅𝑅𝑅𝑅𝑝𝑝𝑝𝑝 ,𝐷𝐷𝑅𝑅𝐷𝐷𝑎𝑎𝑎𝑎 = 𝑅𝑅𝑅𝑅𝑅𝑅𝑝𝑝𝑝𝑝 + 𝐷𝐷𝑅𝑅𝐷𝐷𝑝𝑝𝑝𝑝 + 𝑉𝑉𝑉𝑉𝑉𝑉𝑝𝑝𝑝𝑝 ,𝑉𝑉𝑉𝑉𝑉𝑉𝑎𝑎𝑎𝑎 = 0

𝑇𝑇𝐶𝐶𝑎𝑎𝑎𝑎: Total cost (work effort) of project


63 Vol.13 No.1 (Oct., 2018)

𝑅𝑅𝑅𝑅𝑅𝑅𝑎𝑎𝑎𝑎: Cost for planning and requirement phase

𝐷𝐷𝑅𝑅𝐷𝐷𝑎𝑎𝑎𝑎: Cost for design and development phase

𝑉𝑉𝑉𝑉𝑉𝑉𝑎𝑎𝑎𝑎: Cost for integration test and validation phase

𝐶𝐶ℎ𝑔𝑔𝑎𝑎𝑎𝑎: Cost for changes

𝐶𝐶𝐶𝐶𝐶𝐶𝑎𝑎𝑎𝑎: Cost for coordination between teams

𝑀𝑀𝑔𝑔𝑀𝑀𝑎𝑎𝑎𝑎: Management and documentation cost

𝛽𝛽: Portion of front planning and requirement per plan-driven

The change cost is calculated from the change volume times change rework probability. The probability

of rework is reduced after each iteration [7] by a geometric series.

𝐶𝐶ℎ𝑔𝑔𝑎𝑎𝑎𝑎 = 𝐶𝐶ℎ𝑔𝑔𝑝𝑝𝑝𝑝 × (𝑟𝑟𝑎𝑎𝑎𝑎)𝑛𝑛𝑎𝑎𝑎𝑎−1 …………………………………………..(10) 𝐶𝐶ℎ𝑔𝑔𝑎𝑎𝑎𝑎: Change rework cost in agile

𝐶𝐶ℎ𝑔𝑔𝑝𝑝𝑝𝑝: Change rework cost in plan-driven

𝑟𝑟𝑎𝑎𝑎𝑎: Reduction Rate of reworks probability per iteration

𝑛𝑛𝑎𝑎𝑎𝑎: Number of iterations in agile

The coordination work effort is composed of the ones in iteration development phase. This cost is in-

creased by the communication path among teams [12].

𝐶𝐶𝐶𝐶𝐶𝐶𝑎𝑎𝑎𝑎 = 𝛾𝛾 × (𝑅𝑅𝑅𝑅𝑅𝑅𝑝𝑝𝑝𝑝+𝑉𝑉𝑉𝑉𝑉𝑉𝑝𝑝𝑝𝑝) × 𝑚𝑚(𝑚𝑚− 1)/2 ………………………..……..(11) 𝐶𝐶𝐶𝐶𝐶𝐶𝑎𝑎𝑎𝑎: Coordination cost among teams

m: Number of teams

𝛾𝛾: Coordination parameter in development phase

The documentation cost can be reduced according the formality [18].

𝑀𝑀𝑔𝑔𝑀𝑀𝑎𝑎𝑎𝑎 = (𝑅𝑅𝑅𝑅𝑅𝑅𝑝𝑝𝑝𝑝 + 𝑉𝑉𝑉𝑉𝑉𝑉𝑝𝑝𝑝𝑝) × 𝐷𝐷𝐶𝐶𝑐𝑐𝑝𝑝𝑝𝑝 × 𝐹𝐹𝑚𝑚𝑉𝑉 ……………………………………(12) 𝑀𝑀𝑔𝑔𝑀𝑀𝑎𝑎𝑎𝑎: Management cost at agile

𝐷𝐷𝐶𝐶𝑐𝑐𝑝𝑝𝑝𝑝: Proportion of the documentation

Fml: Formality of the project

3.4 Hybrid approach


management work effort for documentation. In hybrid approach, a some portion (𝜹𝜹) of integration test

is conduced after the iteration [18].


Vol.13 No.1 (Oct., 2018) 64

𝑇𝑇𝐶𝐶ℎ𝑦𝑦 = 𝑅𝑅𝑅𝑅𝑅𝑅ℎ𝑦𝑦 + 𝐷𝐷𝑅𝑅𝐷𝐷ℎ𝑦𝑦 + 𝑉𝑉𝑉𝑉𝑉𝑉ℎ𝑦𝑦 + 𝐶𝐶ℎ𝑔𝑔ℎ𝑦𝑦 + 𝐶𝐶𝐶𝐶𝐶𝐶ℎ𝑦𝑦 + 𝑀𝑀𝑔𝑔𝑀𝑀ℎ𝑦𝑦 …………… (13)

𝑅𝑅𝑅𝑅𝑅𝑅ℎ𝑦𝑦 = 𝛽𝛽 × 𝑅𝑅𝑅𝑅𝑅𝑅𝑝𝑝𝑝𝑝 ,𝐷𝐷𝑅𝑅𝐷𝐷ℎ𝑦𝑦 = 𝑅𝑅𝑅𝑅𝑅𝑅𝑝𝑝𝑝𝑝 + 𝐷𝐷𝑅𝑅𝐷𝐷𝑝𝑝𝑝𝑝 + 𝑉𝑉𝑉𝑉𝑉𝑉𝑝𝑝𝑝𝑝 × (1− 𝛿𝛿),

𝑉𝑉𝑉𝑉𝑉𝑉ℎ𝑦𝑦 = 𝛿𝛿 × 𝑉𝑉𝑉𝑉𝑉𝑉𝑝𝑝𝑝𝑝 ,

𝑇𝑇𝐶𝐶ℎ𝑦𝑦: Total cost (work effort) of project

𝑅𝑅𝑅𝑅𝑅𝑅ℎ𝑦𝑦: Cost for planning and requirement phase

𝐷𝐷𝑅𝑅𝐷𝐷ℎ𝑦𝑦: Cost for design and development phase

𝑉𝑉𝑉𝑉𝑉𝑉ℎ𝑦𝑦: Cost for integration test and validation phase

𝐶𝐶ℎ𝑔𝑔ℎ𝑦𝑦: Cost for changes

𝐶𝐶𝐶𝐶𝐶𝐶ℎ𝑦𝑦: Cost for coordination between teams

𝑀𝑀𝑔𝑔𝑀𝑀ℎ𝑦𝑦: Management and documentation cost

𝛽𝛽: Portion of front planning and requirement per plan-driven

𝛿𝛿: Portion of end testing and validation planning per plan-driven

The change cost is calculated from the change volume times change rework probability. The probability

of rework is reduced after each iteration by a geometric series. In hybrid appraoch, the number of iterations

are less than agile due to the less work effort in development phae [49].

𝐶𝐶ℎ𝑔𝑔ℎ𝑦𝑦 = 𝐶𝐶ℎ𝑔𝑔𝑝𝑝𝑝𝑝 × (𝑟𝑟ℎ𝑦𝑦)𝑛𝑛ℎ𝑦𝑦−1, 𝑛𝑛ℎ𝑦𝑦 = 𝑅𝑅𝐶𝐶𝑅𝑅𝑛𝑛𝐶𝐶(𝑛𝑛𝑎𝑎𝑎𝑎 × 𝐷𝐷𝑅𝑅𝐷𝐷ℎ𝑦𝑦/𝐷𝐷𝑅𝑅𝐷𝐷𝑎𝑎𝑎𝑎) …………(14) 𝐶𝐶ℎ𝑔𝑔ℎ𝑦𝑦: Change rework cost

Chv: Change volume

𝐶𝐶ℎ𝑝𝑝: Change proportion per development and validation cost

p: Rework probability after validation phase

𝑟𝑟ℎ𝑦𝑦: Reduction Rate of reworks probability per iteration (=𝑟𝑟𝑎𝑎𝑎𝑎)

𝑛𝑛ℎ𝑦𝑦: Number of iterations in hybrid

The coordination work effort is composed of the ones in requirement, development and validation phase.

In hybrid, the coordination in development is linearly increased as the number of teams as the front

planning and documentation [49].

𝐶𝐶𝐶𝐶𝐶𝐶ℎ𝑦𝑦 = 𝐶𝐶𝐶𝐶𝐶𝐶𝑟𝑟𝑟𝑟𝑟𝑟 + 𝐶𝐶𝐶𝐶𝐶𝐶𝑝𝑝𝑟𝑟𝑣𝑣+𝐶𝐶𝐶𝐶𝐶𝐶𝑣𝑣𝑎𝑎𝑣𝑣 …………………………………………(15)

𝐶𝐶𝐶𝐶𝐶𝐶𝑟𝑟𝑟𝑟𝑟𝑟 = 𝛼𝛼 × 𝑅𝑅𝑅𝑅𝑅𝑅ℎ𝑦𝑦 × (𝑚𝑚− 1)

𝐶𝐶𝐶𝐶𝐶𝐶𝑝𝑝𝑟𝑟𝑣𝑣 = 𝛾𝛾 × (𝑅𝑅𝑅𝑅𝑅𝑅𝑝𝑝𝑝𝑝+𝑉𝑉𝑉𝑉𝑉𝑉𝑝𝑝𝑝𝑝) × (𝑚𝑚− 1)

𝐶𝐶𝐶𝐶𝐶𝐶𝑣𝑣𝑎𝑎𝑣𝑣 = 𝛼𝛼 × 𝑉𝑉𝑉𝑉𝑉𝑉ℎ𝑦𝑦 × (𝑚𝑚− 1)


65 Vol.13 No.1 (Oct., 2018)

𝐶𝐶𝐶𝐶𝐶𝐶ℎ𝑦𝑦: Coordination cost among teams

𝐶𝐶𝐶𝐶𝐶𝐶𝑟𝑟𝑟𝑟𝑟𝑟: Coordination cost in requirement phase

𝐶𝐶𝐶𝐶𝐶𝐶𝑝𝑝𝑟𝑟𝑣𝑣: Coordination cost in requirement phase

𝐶𝐶𝐶𝐶𝐶𝐶𝑣𝑣𝑎𝑎𝑣𝑣: Coordination cost in validation phase

m: Number of teams

𝛼𝛼: Coordination parameter in requirement and validation phase

𝛾𝛾: Coordination parameter in development phase

In hybrid, the documentation is more than agile in development phase.

𝑀𝑀𝑔𝑔𝑀𝑀ℎ𝑦𝑦 = (𝑅𝑅𝑅𝑅𝑅𝑅𝑝𝑝𝑝𝑝 + 𝐷𝐷𝑅𝑅𝐷𝐷𝑝𝑝𝑝𝑝 + 𝑉𝑉𝑉𝑉𝑉𝑉𝑝𝑝𝑝𝑝) × 𝐷𝐷𝐶𝐶𝑐𝑐𝑝𝑝𝑝𝑝 × 𝐹𝐹𝑚𝑚𝑉𝑉 ………………......(16) 𝐷𝐷𝐶𝐶𝑐𝑐𝑝𝑝𝑝𝑝: Proportion of the documentation

Fml: Formality of the project

4. AN EXAMPLE OF NUMERICAL EXPERIMENT

This section presents an example of numerical experiment based on the actual project data shown in Table

1. The equation (1-3) is for numerical simulations to illustrate the effective application area of the hybrid

approach compared with the agile and the plan-driven on cost. That area is depicted with respect to two

dimensions of size and rework probability. The boundary curve where either 𝐶𝐶𝐶𝐶ℎ𝑦𝑦−𝑝𝑝𝑝𝑝 , 𝐶𝐶𝐶𝐶𝑎𝑎𝑎𝑎−𝑝𝑝𝑝𝑝 and 𝐶𝐶𝐶𝐶ℎ𝑦𝑦−𝑎𝑎𝑎𝑎 is zero is simulated with goal-seek calculations [50] of rework probability (p), repeatedly

for several numbers of teams (m). Figure 3 shows the effective area of the three methods when projects are associated with high uncer-

tainty and low criticality. The input variables based on the data in a project case are shown in the Table 1.

The project is characterized with high uncertainty and low criticality and it has multiple teams [23]. The

boundary between the agile method and the hybrid approach, in terms of number of teams, should be five

or more. In other words, the agile should be appropriate for smaller number of teams and the hybrid

should be appropriate. This result would be consistent with our past case studies [23]. Further, the plan-

driven method can be adopted where more than 13 project teams are required and the rework probability

is very low.


Vol.13 No.1 (Oct., 2018) 66

Table 1: Input variables

𝑹𝑹𝑹𝑹𝑹𝑹𝒑𝒑𝒑𝒑 𝑫𝑫𝑹𝑹𝑫𝑫𝒑𝒑𝒑𝒑 𝑽𝑽𝑽𝑽𝑽𝑽𝒑𝒑𝒑𝒑 𝒏𝒏𝑽𝑽𝒂𝒂 𝜷𝜷 𝜹𝜹 m

900 3300 3400 9 0.3 0.5 6

Fml 𝒓𝒓𝑽𝑽𝒂𝒂 𝜶𝜶 𝜸𝜸 𝑫𝑫𝑫𝑫𝑫𝑫𝒑𝒑𝒑𝒑 Chp p

0.5 0.89 0.05 0.05 0.3 0.5 0.7

Figure 3: An example of effective area

5. DISCUSSION AND CONCLUSION

The objective of this paper is to answer to the following research question with a mathematical model

analysis and numerical simulations: How can the project manager analyze where the hybrid approach is

applicable? Our research effort is an extension to the existing literature and theoretical building of the

benefit of the hybrid approach as compared with the agile and plan-driven methods. This mathematical

model is an enhanced one of the author’s past research paper [51], which introduces the hybrid approach.

A numerical simulation result suggests that the hybrid approach can be used in wider range of projects

characterized with a higher uncertainty of requirements or solutions in a larger-scale projects that employ

five teams or more. The 9-month project described in the Section 4 (Table 1) provided a global procure-

ment system in an IT technology company and deployed a common procurement process and interfaces

with major customers in six countries, where approximately 50% of the requirements had not been clari-

fied [52]. While the agile method needs more coordination work effort due to the less documentation, the

hybrid approach requires less coordination by utilizing the high-level design documents defined before


67 Vol.13 No.1 (Oct., 2018)

the iterative development. Our analysis of a theoretical model with numerical experiments that the hybrid

approach would be applicable in a wider range of situations in more uncertain project contexts. The find-

ings in this paper would suggest that project managers or a project management office should establish a

project management methodology of hybrid, agile and plan-driven approach from not only the project

context but also from the development strategy considering iterative, incremental process in the agile

method.

Those findings described above should also contribute to the possibility of the management methodol-

ogy research in the Scheme-System-Service (3S) model of the Japanese Project and Program management

(P2M) [52]. The past studies of the P2M discuss the agile [53,54], but very few studies have suggested the

methodologies of the hybrid approach. Our model in this paper suggests that if the rework probability of

the System model is relatively low, the management lifecycle should be plan-driven. If the rework prob-

ability of the System model is relatively high and the project size is small, the management lifecycle

should be agile. If the rework probability of the System model is relatively high and the project size is

large, the management lifecycle should be the hybrid approach.

The implication of this study, which has possible limitations, could indicate directions for future re-

search questions. First, we should be cautious about interpreting the cost benefit formula, as the theoretical

model contains three dimensions as compared to the five dimensions proposed by Boehm and Turner [12].

Future research efforts may attempt to include organizational variables of culture or team member’s com-

petencies [55]. Second, the generalizability of our findings, which were obtained from a limited number of

simulation scenario, can be enhanced using a larger sample of case studies.

REFERENCES [1] Royce, W. W., “Managing the development of large software systems”, Proceedings of IEEE

WESCON , 26(8) 328-388, 1970

[2] Beck, K., “Extreme programming explained: Embrace change”, Addison-Wesley Professional, 2000

[3] Schwaber, K., and Beedle, M., “Agile software development with scrum”, Prentice Hall, Upper Sad-dle River, 2001

[4] Turk, D., France, R., and Rumpe, B., “Limitations of agile software processes”, arXiv Preprint arXiv:1409.6600, 2014

[5] Conforto, E., Rebentisch, E., and Amaral, D., “Project management agility global survey”, Massa-chusetts Institute of Technology, Consortium for Engineering Program Excellence – CEPE, Cam-bridge, Massachusetts, U.S.A., 2014

[6] Dybå, T. and Dingsøyr, T., “Empirical studies of agile software development: A systematic review”, Information and Software Technology, 50(9), 833-859, 2008


Vol.13 No.1 (Oct., 2018) 68

[7] Glaiel, F., Moulton, A., and Madnick, S., “Agile project dynamics: A system dynamics investigation of agile software development methods”, 31st International Conference of the System Dynamics Society, 2013

[8] Cockburn, A., Crystal clear: “A human-powered methodology for small teams”, Pearson Education, 2004

[9] Poppendieck, M. and Poppendieck, T., “Lean software development: An agile toolkit”, Addison Wesley, 2003.

[10] Palmer, S. R. and Felsing, M., “A practical guide to feature-driven development”, Pearson Educa-tion., 2001

[11] Beck, K., Beedle, M., Van Bennekum, A.,Cockburn, A.,Cunningham, W.,Fowler, M.,Grenning, J.,Highsmith, J.,Hunt, A. and Jeffries, R., “Manifesto for agile software development”, Retrieved from http://agilemanifesto.org (accessed 28 May 2017), 2001

[12] Boehm, B. and Turner, R., “Balancing agility and discipline: A guide for the perplexed, portable documents”, Addison-Wesley Professional ,2003

[13] Highsmith, J., “Agile project management: Creating innovative products”, Pearson Education, 2009

[14] Dyba, T. and Dingsoyr, T., “Agile project management: From self-managing teams to large-scale development”, Software Engineering (ICSE), 2015 IEEE/ACM 37th IEEE International Conference, 2, 945-946, 2015

[15] Conforto, E. C. and Amaral, D. C., “Agile project management and stage-gate model—A hybrid framework for technology-based companies”, Journal of Engineering and Technology Manage-ment, 40, 1-14, 2016

[16] Jahr, M., “A hybrid approach to quantitative software project scheduling within agile frameworks”, Project Management Journal, 45(3), 35-45, 2014

[17] Serrador, P. and Pinto, J. K., “Does agile work? —A quantitative analysis of agile project success”, International Journal of Project Management, 33(5), 1040-1051, 2015

[18] Hanabusa, S., Naka, K., Hiraoka, T., and Maegawa, Y., “Hybrid agile execution”, Ric Telecom. (In Japanese), 2013

[19] Hayata, T. and Han, J., “A hybrid model for IT project with scrum”, In Service Operations, Logistics, and Informatics (SOLI), 2011 IEEE International Conference on (pp. 285-290). IEEE, 2011

[20] Špundak, M., “Mixed agile/traditional project management Methodology–Reality or illusion?”, Pro-cedia-Social and Behavioral Sciences, 119, 939-948.

[21] Conforto, E. C., Amaral, D. C., da Silva, S. L., Di Felippo, A., and Kamikawachi, D. S. L., “The agility construct on project management theory”, International Journal of Project Management, 34(4), 660-674, 2016

[22] Imani, T., “A method to apply the agile and plan-driven approach for managing large-scale project”, Japan Society for Information and Management 72nd Annual Conference, 171-174. (in Japanese), 2016

[23] Imani, T., Nakano, M., and Anantatmula, V., “Does a hybrid approach of agile and plan-driven methods work better for IT system development projects”, International Journal of Engineering Re-search and Applications, 1(7), 39-46, 2017


69 Vol.13 No.1 (Oct., 2018)

[24] Nicholls, G. M., Lewis, N. A., and Eschenbach, T., “Determining when simplified agile project man-agement is right for small teams” Engineering Management Journal, 27(1), 3-10, 2015

[25] Leffingwell, D., “Agile software development with verification and validation in high assurance and regulated environments”, Rally Software Development Corp, 2011

[26] Ambler, S. W., “Agile software development at scale. In Balancing agility and formalism in soft-ware engineering”, (pp. 1-12). Springer Berlin Heidelberg, 2008

[27] Leffingwell, D., “Scaling software agility: Best practices for large enterprises”, Pearson Education, 2007

[28] Kruchten, P., “Contextualizing agile software development”, Journal of Software: Evolution and Process, 25(4), 351-361, 2013

[29] Lippe, S. and vom Brocke, J., “Situational project management for collaborative research projects”, Project Management Journal, 47(1), 76-96, 2016

[30] Sheffield, J. and Lemétayer, J., “Factors associated with the software development agility of suc-cessful projects”, International Journal of Project Management, 31(3), 459-472, 2013

[31] Vinekar, V., Slinkman, C. W., and Nerur, S., “Can agile and traditional systems development ap-proaches coexist? an ambidextrous view”, Information Systems Management, 23(3), 31-42, 2006

[32] Nisa, S. U. and Qureshi, M. R. J., “Empirical estimation of hybrid model: A controlled case study”, International Journal of Information Technology and Computer Science (IJITCS), 4(8), 43, 2012

[33] Mushtaq, Z. and Qureshi, M. R. J., “Novel hybrid model: Integrating scrum and XP”, International Journal of Information Technology and Computer Science (IJITCS), 4(6), 39, 2012

[34] Fitzgerald, B., Hartnett, G., and Conboy, K., “Customising agile methods to software practices at intel Shannon”, European Journal of Information Systems, 15(2), 200-213, 2006

[35] Chow, T. and Cao, D., “A survey study of critical success factors in agile software projects”, Journal of Systems and Software, 81(6), 961-971, 2008

[36] Shenhar, A. J. and Dvir, D., “Reinventing project management: The diamond approach to successful growth and innovation”, Harvard Business Review Press, 2007

[37] Sutherland, J. and Sutherland, J., “Scrum: The art of doing twice the work in half the time”, Crown Business, 2014

[38] Lindvall, M., Basili, V., Boehm, B., Costa, P., Dangle, K., Shull, F., . . . Zelkowitz, M., “Empirical findings in agile methods. Extreme Programming and Agile Methods—XP/Agile”, Universe 2002, 197-207, 2002

[39] Batra, D., Xia, W., VanderMeer, D., and Dutta, K., “Balancing agile and structured development approaches to successfully manage large distributed software projects: A case study from the cruise line industry”, Communications of the Association for Information Systems, 27(1), 21, 2010

[40] Vlietland, J. and van Vliet, H., “Towards a governance framework for chains of scrum teams”, In-formation and Software Technology, 57, 52-65, 2015

[41] Dingsøyr, T., Fægri, T. E., and Itkonen, J., “What is large in large-scale? A taxonomy of scale for agile software development”, In International Conference on Product-Focused Software Process Im-provement (pp. 273-276). Springer International Publishing, 2014


Vol.13 No.1 (Oct., 2018) 70

[42] Dark, M., Bishop, M., Linger, R., and Goldrich, L, “Realism in teaching cybersecurity research: The agile research process”, In IFIP World Conference on Information Security Education (pp. 3-14). Springer International Publishing, 2015

[43] Okada, M. and Nakano, M., “The impact of value transmission on design process in the system development project”, Journal of the Society of the Project Management, 12(4), 33-39. (In Japanese), 2010

[44] Browning, T. R. and Eppinger, S. D., “Modeling impacts of process architecture on cost and schedule risk in product development. Engineering Management”, IEEE transactions on engineering manage-ment, 49(4), 428-442, 2002

[45] Yim, R. L., Castaneda, J. M., Doolen, T. L., Tumer, I. Y., and Malak, R., “Exploring the relationship between rework projects and risk indicators”, Project Management Journal, 46(4), 63-75, 2015

[46] Dingsøyr, T. and Moe, N. B., “Research challenges in large-scale agile software develop-ment”, ACM SIGSOFT Software Engineering Notes, 38(5), 38-39, 2013

[47] Port, D. and Bui, T., “Simulating mixed agile and plan-based requirements prioritization strategies: Proof-of-concept and practical implications”, European Journal of Information Systems, 18(4), 317-331, 2009

[48] Strode, D. E., Huff, S. L., Hope, B., and Link, S., “Coordination in co-located agile software devel-opment projects”, Journal of Systems and Software, 85(6), 1222-1238, 2012

[49] Manabe, D., “The successful agile development project management case which involves multiple countries”, 27th National Conference of the Society of Project Management, 143-147. (In Japanese), 2016

[50] Fylstra, D., Lasdon, L., Watson, J., and Waren, A., “Design and use of the Microsoft Excel Solver”, Interfaces, 28(5), 29-55, 1998

[51] Imani, T. and Nakano, M., “A Basic Model to Analyze the Effective Area for Agile Development in IT Projects”, J. Jpn Ind Manage Assoc, 68(2), 74-81, 2017

[52] International Association of P2M, “Project and Program Management - P2M Version 2.0 Concepts Guideline -”, IA-P2M, 2009

[53] Sato, T. and Kameyama, H, “Application to the P2M of Agile development, Lean product develop-ment and Design thinking”, Proceedings of International Association of P2M Autumn, 26-35, 2012

[54] Sato, T., “The Effectiveness of Program Management Efforts by IoT Businesses”, Journal of Inter-national Association of P2M, 11(1), 85-94, 2016

[55] Nagaya, H. and Imani, T., “Socio-cultural enablers for agile project management”, PMI Global Con-gress Proceedings – EMEA, London, UK. 2015

Received July 16, 2018

Accepted September 15, 2018