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