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
T. IMANI, et al. Journal of IAP2M.
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.
Journal of IAP2M T. IMANI, et al.
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
T. IMANI, et al. Journal of IAP2M.
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-
Journal of IAP2M T. IMANI, et al.
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].
T. IMANI, et al. Journal of IAP2M.
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]
Journal of IAP2M T. IMANI, et al.
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.
T. IMANI, et al. Journal of IAP2M.
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
Journal of IAP2M T. IMANI, et al.
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
The total cost is calculated by the work effort by phases, efforts for changes and coordination, and
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
T. IMANI, et al. Journal of IAP2M.
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
The total cost is calculated by the work effort by phases, efforts for changes and coordination, and
management work effort for documentation. In hybrid approach, a some portion (ð¹ð¹) of integration test
is conduced after the iteration [18].
Journal of IAP2M T. IMANI, et al.
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)
T. IMANI, et al. Journal of IAP2M.
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.
Journal of IAP2M T. IMANI, et al.
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
T. IMANI, et al. Journal of IAP2M.
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
Journal of IAP2M T. IMANI, et al.
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
T. IMANI, et al. Journal of IAP2M.
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
Journal of IAP2M T. IMANI, et al.
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