-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
1/41
ATHABASCA UNIVERSITY
ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE
FINANCIAL BENEFITS
BY
FRANCOIS NADEAU
An essay submitted in partial fulfilment
Of the requirements for the degree of
MASTER OF SCIENCE in INFORMATION SYSTEMS
Athabasca, Alberta
May, 2007
Francois Nadeau, 2007
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
2/41
DEDICATION
To Yoko who supported me during my studies and who has opened my eyes to the world, and to my
parents who sacrificed so much to raise me.
i
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
3/41
ABSTRACT
The use of the iterative delivery process has been popularized by the agile movement, and has now
become a well-understood and often used process for developing software. This thesis examines the
techniques for estimating the cost of software projects, and investigates whether projects which use the
iterative delivery process can be evaluated more favourably than projects which do not use this process.
For this purpose, expert-based estimation and formal mathematical model estimation techniques are
reviewed and discussed. Various mechanisms which can be employed to find an iteratively delivered
project's release plan are then reviewed, as well as the business models used by software vendors to
produce software for their customers. This thesis concludes that the use of the iterative delivery process
does not affect a project's estimated level of effort. Thus, knowing that this process will be used to
develop the project does not lower the estimated development cost. However, it is possible to demonstrate
that a project's return on investment (ROI) will be higher if the iterative delivery process is used instead of
a sequential delivery process such as the waterfall methodology. This occurs because software delivered
during iterations can generate income before the entire project has been completed. Furthermore, it is
argued that a higher ROI may be realized by combining the iterative delivery process with the service
oriented-business model.
Keywords: Iterative delivery process, software effort estimation, release planning, service-oriented
business model.
ii
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
4/41
Table of Contents
CHAPTER I.....................................................................................................................................................1INTRODUCTION......................................................................................................................................1
Introduction............................................................................................................................................1
Statement of Purpose.............................................................................................................................2Significance...........................................................................................................................................2Limitations.............................................................................................................................................3
Definition of Terms...............................................................................................................................4Organization of the Essay......................................................................................................................5
CHAPTER II...................................................................................................................................................6SOFTWARE COST ESTIMATES.............................................................................................................6
Introduction............................................................................................................................................6Quantifying effort..................................................................................................................................7
Line of code (LOC)..........................................................................................................................7Function Point (FP)...........................................................................................................................8
Expert judgement-based estimation......................................................................................................9Bottom-up.........................................................................................................................................9
Top-down..........................................................................................................................................9Formal Mathematical Models..............................................................................................................10
COCOMO.......................................................................................................................................11Conclusion...........................................................................................................................................13
CHAPTER III................................................................................................................................................15RELEASE PLANNING...........................................................................................................................15
Introduction..........................................................................................................................................15Ad hoc Approach.................................................................................................................................17
Planning Game.....................................................................................................................................17Optimization-Based.............................................................................................................................18Kano Model of Customer Satisfaction................................................................................................19
Incremental Funding Methodology (IFM)..........................................................................................20Conclusion...........................................................................................................................................22
CHAPTER IV................................................................................................................................................23BUSINESS MODELS..............................................................................................................................23
Introduction..........................................................................................................................................23Product Oriented (PO) Business Model..............................................................................................23
Service Oriented (SO) Business Model..............................................................................................24Hybrid Oriented (HO) Business Model..............................................................................................25
The Open Source Movement...............................................................................................................26Conclusion...........................................................................................................................................26
CHAPTER V.................................................................................................................................................28
CONCLUSION AND RECOMMENDATIONS.....................................................................................28Conclusion...........................................................................................................................................28
Product Quality....................................................................................................................................28Release Planning..................................................................................................................................29
iii
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
5/41
Business Model....................................................................................................................................30
Further Research Suggestions .............................................................................................................31
iv
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
6/41
LIST OF TABLES
Table 1: Function Point Types.........................................................................................................................8
Table 2: Effort Estimation Models................................................................................................................11Table 3: COCOMO Project Type..................................................................................................................12Table 4: COCOMO Coefficient Values........................................................................................................13
Table 5: Feature Categories for the Kano Model..........................................................................................19Table 6: Kano Categorization Matrix...........................................................................................................20
v
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
7/41
LIST OF FIGURES
Figure 1: Projected Cash Flow for the Sequential Life Cycle ......................................................................16
Figure 2: Projected Cash Flow for the Iterative Delivery Life Cycle...........................................................16Figure 3: Manipulating Financial Metrics through Resequencing MMFs...................................................21
vi
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
8/41
CHAPTER I
INTRODUCTION
Introduction
In today's aggressive business world, few executives are willing to bankroll large IT projects with
delivery dates in the far future. While some computer scientists may lament this change in business
vision, the fact is that today's business executives no longer see IT projects as soon-to-be-cash-cows,
but instead as investments to be analysed in the same manner as any other infrastructural investments. In
order to be financed in this environment, IT projects need to shorten their investment periods, quicken
their time-to-market, and respond quickly to internal or external events which may affect the project.
Some software practitioners have started to use the iterative delivery process to better handle these
difficulties.
Software development projects which use an iterative delivery process deliver their project's
features incrementally throughout the development life cycle. This is normally accomplished by
constructing a small part of the system, and then allowing a subset of the end users to either use the
software or to test it. In this way, each of the iterations are used to demonstrate that some features have
been adequately implemented, and allows for the collection of feedback from the end users. For example,
a development team could provide its users with the capability to enter data even though the system may
not yet allow them to retrieve and view this information.
The advantages of the iterative delivery process have been well documented[1]. They include:
lower production and maintenance costs, increase in product quality, and an increase in the product's
fitness of use. These advantages provide a competitive edge for companies which have successfully
implemented a methodology which uses the iterative delivery process.
1
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
9/41
The use of the iterative delivery process does, however, create some difficulties. For example, one
of the greatest advantages of the iterative delivery process is that it permits the development team to delay
making design decisions which need to be taken at an earlier stage with the use of other methodologies
[2]. This benefit results from the fact that the team will only work on the features which are to be released
on the next iteration. In this manner, the software's design is not restricted and new information can be
used to implement future features without, in theory, requiring that the team greatly modifies its previous
work. To allow this to happen, software requirements are not fully analysed, and the customer is not
locked into their requirements at the beginning of the development cycle. Overcoming the contractual
difficulties and evaluating the financial value of this feature during a project's bidding stage can be a
daunting task.
Statement of Purpose
This thesis will examine the techniques used to estimate the cost of software projects, and will
investigate whether projects which use the iterative delivery process can be financially more attractive
than projects which do not use this process. The author proposes to evaluate the potential financial
benefits of the iterative delivery process, and the possible manner in which a software company's
response to a request for proposal can be made so that it is financially appealing to the customer.
Significance
A great deal of research has been conducted about methodologies which uses the iterative delivery
process, such as Adaptive Software Development (ASD), Agile Modeling, Crystal Methods, Dynamic
System Development Methodology (DSDM), Extreme Programming (XP), Feature-Driven Development
(FDD), Lean Development, the Rational Unified Process (RUP), and Scrum. However, most of the
literature does not make a business case for the change, but instead focuses on the techniques which can
be applied to increase a software development team's agility.
2
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
10/41
Software effort estimation methods can be classified as belonging in one of two groups; expert
judgement-based, or formal mathematical models[3]. Expert judgement-based estimations methods rely
on an expert's judgement in order to evaluate and estimate a software project's effort cost. Methods in this
category include expert consulting, intuition based on experience, and analogy. These techniques have
been found to be the most commonly used estimation methods in the software industry[3].
Formal mathematical models, such as COCOMO, can be used to estimate a project's effort in
project months, kilo lines of code (KLOC) or function points (FP). Most of these models are based on the
assumption that the total effort required to complete a project will increase exponentially in relation to the
the project size[4]. Although a great deal of research has been conducted with regards to these models,
there is no evidence that their use will lead to more accurate estimates[5]. This reason, coupled with the
fact that the use of these models can be more complicated than using one's gut feelings, may be the
reason that the majority of the software industry has not adopted these models for cost estimation.
Limitations
Moving to an iteration delivery process can be difficult and costly for some organizations. This
thesis does not address these costs, and whether or not they will be recovered once the investment has
been made to change the development process. While these are important concerns for organizations
which have not yet moved to an agile methodology, the author believe that these changes will be forced
onto all software developers in the same manner as that by which just-in-time production was adopted by
the manufacturing industry; that is, organisations will either adapt or go out of business.
This thesis does not present any methodologies which use the iterative delivery process, but
instead builds on what has already been published. In other words, the findings in this thesis are expected
to be applicable to any methodology which uses the iterative delivery approach.
Another limitation of this thesis has to do with quality. Software products which are considered to
3
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
11/41
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
12/41
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
13/41
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
14/41
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
15/41
The use of expert judgement or Program Evaluation and Review Techniques (PERT) are common
techniques used to estimate a project's LOC. The former will be explained in more detail latter on in this
chapter. The latter uses expert judgement to evaluate the most optimistic LOC (O), the most likely LOC
and the pessimistic LOC (P). These values are then used in formula (1) to find the estimated LOC (E).
E=O4TeP
6(1)
Function Point (FP)
FP is a measurement method which is used to quantify a software project's functionality. This
method uses the sum of five distinct types, adjusted by their estimated level of complexity. Table 1
describes these types. An advantage of using FP, instead of LOC, is that they can be more accurately and
easily calculated before the project has been started.
Table 1: Function Point Types
FP type Description
User-input : user-entered inputs, e.g. inputs through a graphical user interface(GUI)
User-output : outputs which are required to be displayed by the system, or which
must leave the system, e.g. output filesInquiry : interactive inputs which produce a response from the system, e.g.
charts or reports which are viewed within the application
Internal file : logical groups of persistent data which are used exclusively by thesystem, e.g. a database columns, or configuration files
External file : logical groups of persistent data which are used by the system aswell as one or more external systems, e.g. columns in a database
which are shared by multiple applications
Value adjustment for each of the discovered FP Nij in the system is completed by estimating
the FP's level of difficulty Wij . These are classified as simple, medium, or complex, and are assigned
the value of 1, 2, or 3, respectively. Formula (2) describes how these values are compiled.
8
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
16/41
FP=i=1
5
j=1
3
NijWij (2)
For example, if a project's FPs are evaluated to be 1 simple inputs, 2 medium outputs, 3 complex
inquiries, 4 simple internal files, and 5 medium external files. Then the FP for the project is as
follows:
FP=1122334152=28
Expert judgement-based estimation
Expert estimation can be described as estimation conducted by persons recognised as experts, in
which important parts of the estimation process are based on non-explicit, non-recoverable reasoning
process such as intuition. Expert estimation strategies includes vague techniques such as gut-feeling, and
more structured techniques such as history-based expert estimation[12]. Expert estimates typically deal
better with vague requirements than mathematical models do. Expert estimation strategies can be
categorized as belonging to either the bottom-up or the top-down approach.
Bottom-up
Estimates which use a bottom-up approach typically divide the project into activities, and estimate
the effort required to complete each of these activities individually. The project's effort estimate is
evaluated as the sum of the effort required to complete each of the activities, with the possible addition of
a budget to cover unexpected activities or events. This is most often accomplished by developing a Work
Breakdown Structure (WBS)[8]. This approach can be more beneficial than the top-down one for re-
estimating the remaining activities required to complete a project.
Top-down
Estimates which follow a top-down approach estimate the total effort of a software project without
decomposing the project into activities or other types of project parts. For instance, an estimation strategy
9
Te,
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
17/41
may be to compare the entire project with previously completed projects which have similar
characteristics. This strategy has some advantages when estimates are needed for ROMs with vague
requirement specifications that don't enable the creation of a detailed WBS of the activities to be
developed.
Formal Mathematical Models
Formal estimation models, such as COCOMO, can be used to estimate a project's effort in project-
months, kilo LOC (KLOC) or FP. Although a great deal of research has been conducted with regards to
these models, there is no evidence that their use will lead to more accurate estimates[5]. This fact,
combined with the fact that the use of these models can be more complicated than the use of personal
experience, may be the reason for which these models are not used by the majority of the software
industry.
Formal models are typically expressed in the following form:
E=caSizeb (3)
where E represents the effort in man-month, c, a, b are determined by analysing historical data from
completed projects, and Size is measured either in KLOC or FP. Table 2 presents a short list of some of
the models which have been proposed.
10
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
18/41
Table 2: Effort Estimation Models[4]
Author Base formula
Halstead E=0.7KLOC1.50
Boehm Basic COCOMO organic E=2.4KLOC1.05
Boehm Basic COCOMO semi-detached E=3.0KLOC1.12
Boehm Basic COCOMO embedded E=3.6KLOC1.20
Boehm et al. COCOMO II.2000 post-architectural
with all parameters set Nominal E=2.9KLOC1.10
Walston Felix E=5.2KLOC0.91
Bailey Basili E=5.50.73KLOC1.16
Doty (forKLOC > 9) E=5.288KLOC1.047
Albrecht and Gaffney E=13.390.0545FP
Kemerer E=60.627.728108
FP3
Matson, Barnett and Mellichamp E=585.715.12FP
Most of these models are based on the assumption that the total effort required to complete a
project will increase exponentially in relation to the the project size. This implies that software projects
have a dis-economy of scale associated with their development.
The following section describes the COCOMO model, which is one of the most popular models
from Table 2.
COCOMO
The COnstructive COst MOdel (COCOMO) was original proposed by Barry Boehm in 1981. This
original model, often referred to as COCOMO 81, was upgraded during the 1990s to account for
technological novelties in the software industry. These revisions, named COCOMO II, still use the same
basic model presented in COCOMO, but now permit its users to enter additional input in order to increase
the result's accuracy.
COCOMO consists of three different levels; basic, intermediate and detailed. Each of these levels
require different amounts of data, and provide different levels of estimate accuracy. For the purpose of
this discussion, the basic level, which is also used by the other two levels, will be briefly described in this
11
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
19/41
section.
The first step in estimating a software project with COCOMO is to determine the type of project
which will be estimated. Table 3 describes the different types of projects which can be estimated with the
COCOMO model.
Table 3 : COCOMO project type[13]
Project Type Description
Organic relatively small, simple software projects in which small teamswith good application experience work to a set of less than rigid
requirements
Semi-detached intermediate (in size and complexity) software projects in whichteams with mixed experience levels must meet a mix of rigid and
less than rigid requirements
Embedded software projects that must be developed within a set of tighthardware, software, and operational constraints
Once the appropriate project type has been selected, the following equations are used to find the
effort (E) in man-months, development time (D) in chronological months, and the number of people (P)
required for the project's development:
E=aKLOCb (4)
D=c Ed (5)
P=E
D(6)
where the coefficients a, b, c and d are taken from Table 4.
12
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
20/41
Table 4 : COCOMO coefficient values[13]
Project type a b c d
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
For example, an organic project which is estimated to require 50 KLOC will require an effort of
146 E=2.4 501.05 man-months , will be developed over 17 D=2.5146
0.38 months, and will
require 9 P=146
17 developers.
Conclusion
Two key concerns emerged in this chapter: the accuracy of initial estimates is not very high
regardless of which estimation model is used, and the software industry seems to be plagued by a dis-
economy of scale. Fortunately, the problem of accuracy of estimation has been shown to diminish as the
project is developed. This implies that the development team is capable of accurately predicting the end
date and cost of a project before its completion. However, inaccurate estimates can cause contractual
problems, since either the customer or vendor must pay for the difference between the estimated cost and
the actual development cost.
Benediktsson and Dalcher suggest that the dis-economy of scales, demonstrated by the
exponential growth of required effort reported by models such as COCOMO, can be countered by the use
of the iterative delivery process[4]. They propose to estimate a project as a series of smaller projects
representing each of the iterations. By doing this, it is possible to show a linear relationship between the
effort required to complete a project and its size. This shows that it is theoretically possible to develop
software more cheaply with the iterative delivery process than with more traditional processes.
All of the estimation techniques discussed in this chapter generate effort estimates based on the
13
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
21/41
amount of work to be performed. In other words, estimates are based on the work to be completed, not on
the process that is to be used. Therefore, it is not possible to guarantee that a project will require less
effort if it is developed with the iterative delivery process instead of another process. This means that a
software vendor cannot offer to develop a project for a lower cost by assuming that the iterative delivery
process will reduce the development cost.
14
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
22/41
CHAPTER III
RELEASE PLANNING
Introduction
Release planning is the process of selecting the order in which features will be developed and
delivered. In other words, it is the process of determining which customer gets their features at which
time. The proper ordering of the requirements can provide financial advantages to projects which use the
iterative delivery process, since customers can benefit from the software delivered during each of the
iterations.
Figures 1 and 2 demonstrate the financial advantages of using the iterative delivery process
instead of a more traditional sequential process, such as the waterfall methodology, with which all of the
features are delivered at the end of the life cycle. The difference between the two charts is caused by the
assumption that ROI will begin after the first iteration has been delivered, and that it will increase after
each of the iterations. That is, it is expected that each of the iterations will cause an increase in income or
performance for the customer, and therefore financial benefits will be reaped at an earlier time than they
would be with the sequential process.
15
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
23/41
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
24/41
deterministic Polynomial-time hard (NP-hard) problem[14], and that the problem's complexity increases
the more it is explored.
The problem of optimizing a release plan is not new to software developers. For example, in 1978
Gilb wrote that each of the iterations have to either (a) give planned return on investment payback, or, if
impossible, then (b) give break-even (no loss); or, at least, (c) some positive user benefit measurably; or,
at least (d) some user environment feedback and learning[15]. Although there are many methods which
can be used to create release plans, none of them can be considered a silver bullet for the creation of an
optimal release plan. The next sections will discuss some of these methods.
Ad hoc Approach
Ad hoc release planning relies on a single individual's judgement, such as the project manager.
This approach typically produces release plans which are non-reproducible, and often focus solely on the
content to be delivered in the next release, giving preference to short-term gains over long-term ones.
These plans are most often completed by simply guessing the order in which the features should be
developed. The greatest advantage of this approach is that it requires less effort to complete than the other
approaches. The drawback of this approach is that it does not take into consideration all of the
stakeholders, and therefore runs the risk of not satisfying their needs. The ad hoc approach is most
suitable for small projects with few requirements and relaxed constraints.
Planning Game
The planning game is a process which has been defined as part of the extreme programming (XP)
methodology[16]. This process is first initiated by having the customer write storyboards which describe
the features which are required for the project. The software developers then estimate the time that will be
required to develop the features, and then the customer prioritizes the storyboards to match their own
preference. The customer is also responsible for setting the next iteration release date.
17
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
25/41
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
26/41
Kano Model of Customer Satisfaction
The Kano Model of Customer Satisfaction classifies requirements based on how they are
perceived by the end-users. These classifications can then be used for deciding the order in which
requirements should be developed. Table 5 defines and provides a short description of the three categories
in the Kano model.
Table 5: Feature Categories for the Kano Model
Feature Category Description
Threshold Must-have features which must be present in the product for it tosucceed. Improving the performance of these features is not typically
required. In other words, these features only need to be present andfunction properly.
E.g., the application must function with input and output devices.Linear Features which are correlated linearly with the end-user's satisfaction.
That is, the more of these features there are, the better it is for the end-
user.E.g., making the application support various export formats.
Exciters Features which provide a great deal of satisfaction for the end-user, but
which are not expected to be included. The lack of these features will notdecrease the end-user's satisfaction.
E.g., integrating email and voice-mail into the application.
The categorizing process first involves creating and administering a questionnaire to a subset of
end-users. The questionnaire is a collection of paired functional and dis-functional questions, the first
asking the user about their feelings if the feature is present, and the second asking about their feeling if it
is absent. The user answers each question by selecting one of the following five possible answers: I like
it that way, I expect it that way, I am neutral, I can live with it that way, or I dislike it that way.
The following provides an example of a functional and dis-functional question pair.
Functional form How do you feel if you can export xml files?
Dis-functional form How do you feel if you cannot export xml files?
19
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
27/41
Once the questionnaire has been answered by a satisfactory number of end-users, the matching
questions are compared in a matrix similar to Table 6.
Table 6: Kano Categorization Matrix[17]
Dis-functional
Question
Like
Expect
Neutral
Livewith
Dislike
FunctionalQuestion Like Q E E E L
Expect R I I I T
Neutral R I I I T
Like with R I I I T
Dislike R R R R Q
where Trepresents a threshold feature,L a linear feature,Ean exciter feature,R a reverse feature, Q a
questionable feature, andIuser's indifference to the feature.
The advantage of using the Kano model is that the end-user's preference is used to set the
priorities. By doing this, the software development team can prioritize the threshold requirements, and
therefore be sure to deliver a system which can solve the user's business problems. A disadvantage of the
Kano model is that since it prioritizes requirements solely on the end-user's view of importance, it does
not take the requirement's cost and projected ROI into consideration.
Incremental Funding Methodology (IFM)
The IFM is an approach to quantifying the financial benefits of individual features of a software
development project and optimizing the delivery sequence for maximum financial impact[18]. By using
this method, a project manager can prioritize the development of each feature to optimize the project's
overall net present value (NPV), which is a measurement of the overall value of the software development
over time.
20
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
28/41
The basic principle of the IFM is to quantify and then compare the financial benefits received
from software developed throughout the software development life cycle. To do this, a project's
requirements are first divided into minimum marketable features (MMF), which are requirement sets
capable of returning value to the customer when released as independent entities. By estimating the
expected financial benefits of each of the MMF, it becomes possible to apply various search algorithms to
prioritize the order in which the MMF should be developed.
One of the benefits of using IFM over the other methods explored in this paper is that IFM is
capable of handling requirement dependencies. For instance, MMF with high returns may have a
dependence on other MMF which may have low returns. In such cases, an approach which only compares
short-term profitability may delay the development of these more profitable MMF. This is demonstrated
in Figure 3, where the dotted line represents a release plan which only considers short term goals, while
the solid line represents a release plan which considers long-term goals.
Figure 3: Manipulating Financial Metrics through Resequencing MMFs[19].
By basing a project's release plan on the expected financial benefits of its features, IFM allows the
development team to optimise their release plans based on the expected financial benefits of each
requirement. This can make the plan more appealing to the customer and the management team. However,
21
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
29/41
a problem with the use of this methodology is that its performance is dependent on the accuracy of the
projected financial benefits of each of the requirements, which can be difficult to estimate. For example,
accurately estimating the financial value of a requirement which boosts the end-users' morale, and
therefore their productivity, can be a very difficult task.
Conclusion
The release planning techniques in this chapter suggest that projects developed with the iterative
delivery process are more financially attractive than projects developed with a sequential process. This
difference occurs because projects developed with the iterative delivery process can have a lower capital
requirement, and can provide a higher ROI on the project, since software can be used at an earlier stage
than sequential processes allow. Release plans can be optimized in order to further increase the value
gained from the project, but this task requires a level of effort from the development team.
An assumption shared by all of the release planning techniques defined in this paper is that it is
the development team's goal to satisfy their customers' needs, not simply to satisfy contractual
specifications. In other words, development teams that optimize their release plan do so by expanding
development resources for their customer's benefit. Doing so increases the development cost, and
therefore decreases the development team's short-term benefits. However, development teams which do
not make this assumption will have contracted the management disease of (supposing) that it is only
necessary to meet specifications[20] defined by Deming, and therefore may not provide a product which
satisfies their client's needs.
22
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
30/41
CHAPTER IV
BUSINESS MODELS
Introduction
Business models used by software companies can be grouped into three categories: Product
Oriented (PO), Service Oriented (SO), and Hybrid Oriented (HO)[21], where PO and SO represent
opposite ends of a spectrum, and HO refers to strategies between these two extremities. This section will
describe some of the advantages and disadvantages of these business models, and the skill sets required
for a company to be successful in each of the orientations. In conclusion, there will be a brief discussion
of the influence that the open source movement has had on these models.
Product Oriented (PO) Business Model
Companies which follow the PO business model generate income by selling packaged software
solutions which meet a set of generic computing requirements. Operating systems, enterprise resource
planning systems, software development tools, and personal-computing applications such as computer
games are all examples of software products.
The greatest appeal of the PO business model is its potentially high ROI. This can occur because
of the inexpensive cost of reproducing digital work, which allows companies to exercise large economies
of scale. An example of this is MS-DOS, which is believed to have been the greatest "cash cow" the world
has ever known. Purchased by Microsoft in 1981 for $50,000 US, MS-DOS came to dominate 80% to
90% of the PC market, making Microsoft a corporate giant, and one of the most influential companies in
the software industry.
Unfortunately, the ease with which software can be copied has also given birth to software
pirates. This term refers to users who use software products without paying the license fees. For
23
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
31/41
instance, in 2003 alone it has been estimated that companies in the United States were deprived of $6.5
billion US in unpaid licensing fees[22]. To prevent such losses, companies have been involved in legal
battles, have created large propaganda campaigns to intimidate and frighten their users, and have
intentionally crippled their products. All of these tactics have had the effect of increasing the development
cost of software, while not providing any additional business value to the customer.
Software users have also had to struggle with some of the methods used by software companies to
increase their customers' dependence on their products. One of these techniques is for the vendors to
prevent their clients from accessing their own data. The basic mechanism used to do this is to create and
patent a proprietary format for storing the product's digital data. This insures that the users cannot change
vendor without losing access to their own data, and therefore obliges the clients to remain loyal to the
same product vendor. Although this method has often favoured the vendors, some users have started to
fight the use of such strategies. For instance, the Peruvian government recently passed a legal bill
requiring all state departments to use software which does not limit access to information[23].
The reality of the PO business model is that it is very difficult to produce a best-seller product
from which a company can generate enough income to survive, and even more difficult to repeatedly
introduce new and successful products. Competitors also make it difficult to retain clients by copying the
product's features and offering them at a more attractive price.
Service Oriented (SO) Business Model
Businesses which follow the SO business model generate their income by selling software as
services. These include, but are not limited to: custom development, system implementation, system
integration, system upgrade, and maintenance[24]. SO companies create unique solutions for their clients'
needs, which typically cannot be packaged and sold "as is" to another client. PriceWaterhouseCoopers is
an example of an SO company which derives most of its revenues from its outsourcing and consulting
24
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
32/41
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
33/41
use the skills needed for both the PO and SO business models. Misbalancing the priorities of these two
strategies has caused failures[24]. An example of these conflicting priorities is that SO companies
typically focus on the technologies which are required to complete current contracts, while PO companies
are more concerned about long-term competitive implications of the technologies they decide to
specialize in. In other words, an SO company's skills are more often than not those which have been
acquired to complete contracts in the past, while PO companies need to acquire skills which will be in
demand once their product is deployed.
The Open Source Movement
The open source movement has had a great impact on the software industry. Open source software
developers, in contrast to proprietary software developers, allow their users to freely modify, copy, and
distribute the application's source code[25].
An example of the impact that open source has had on the software industry is the decreasing
demand for proprietary platforms such as operating systems, databases, and middle-ware applications. By
using open source solutions for their infrastructural needs, companies are able to lower their capital
investment, decrease the total cost of ownership, and decrease their reliance on specific vendors.
PO companies which have been forced to directly compete against open source software products
have had to adapt their business models. For instance, because of competition from open source operating
systems, Sun Microsystems has recently released the source code to its proprietary Solaris operating
system as an open source project. In other words, Sun now uses the SO business model for its operating
system, and generates income by offering support contracts to users of the Solaris operating system.
Conclusion
This section described and explained the different business models used by software companies.
Deciding which model to use depends on many factors, but recent events such as the open source
26
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
34/41
movement are forcing the industry to pursue an SO business model rather than a PO one. For instance, an
interesting aspect of the Peruvian open source bill, cited earlier in this section, is that government
officials felt that the bill needed to exist. A Peruvian congressman stated two reasons for this in an open
letter. The first is that the Peruvian government believes that the general public must be able to access all
public information. Proprietary software does not allow this, since it traditionally stores information in its
own formats, which are not public. The second reason for the bill is the fear that since each of the public
departments functions as an independent unit, it would be possible for some departments to accidentally
purchase proprietary software, and hence prevent the public from accessing the data[23].
27
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
35/41
CHAPTER V
CONCLUSION AND RECOMMENDATIONS
Conclusion
The estimated cost of creating a project cannot vary solely on the basis of development process
which will be used, as estimators generally only estimate the work that has been defined by the customer
in the contract. The fact that the iterative delivery process allows a more flexible approach, which in turn
permits the modification of requirements once the project has begun, does not lower the estimated effort,
since the modifications are unknown at the time. This means that, while estimating a project's cost, the
iterative delivery process may seem more attractive financially if it increases the final product's quality, or
if the customer benefits from the product earlier.
Product Quality
The product's quality is the first area in which the iterative delivery process may be financially
beneficial to the customer. However, although many claims have been made that the iterative delivery
process increases product quality, there is no conclusive proof that this is true for all projects. Just as
Brooks said in 1987, there is no silver bullet for software development[26]. It is also the author's belief
that processes do not produce software, but simply define the structure in which software developers
perform their duties. In other words, software is created by software developers, not by software
processes, and therefore the use of one process cannot guarantee higher levels of quality.
Claiming that the use of the iterative delivery process will increase quality can only be done as a
sales pitch, which unfortunately does not provide much financial information. In other words, a
company's claim that they will create a better product than their competitors is not a measurable variant.
28
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
36/41
Release Planning
The second area in which the iterative delivery process may produce benefits for the customer is
its ability of allowing the client to benefit from the software at an earlier stage. Working software can be
completed and deployed at each (or some) of the iterations, allowing the customer to use these
incremental deliveries. However, doing so creates two difficulties for the development team: estimating
benefits can be a difficult task, and finding the optimal release plan to maximize the benefits for a project
is a NP-hard problem.
In some cases, it may be a trivial task to estimate a feature's financial value. For instance,
developing software features to comply with newly enacted regulations prevents fines which are normally
well-defined by the enforcing party. In cases such as this one, the financial benefits of the features bear a
direct relation to the fines of not complying. On the other hand, estimating the financial benefits from
increasing customer loyalty, attracting new customers, decreasing product defects, and increasing
employees' productivity can be tricky at best. Estimating the value of these benefits can take a great deal
of effort and will typically be inaccurate, which further complicates the process of optimizing the release
plan.
Finding the optimal release plan can be a complicated task, though various methods and
techniques can be used to aid in its creation. However, development teams must not expend too much
effort on this activity, since finding the optimal solution can easily require more resources than it
warrants. Fortunately, it is not required to find the optimal release plan in order to benefit from multiple
deliveries.
The IFM, defined in chapter 3, provides a model to explain how financial benefits can accrue
from multiple deliveries. Although the IFM was defined as a tool for creating release plans, its basic
premise demonstrates how the iterative delivery process can be beneficial to the client. The premise that
29
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
37/41
software delivered at the end of an iteration can generate income for the client can be explained within a
project's request for proposal. Doing so can demonstrate to the client that they will be able to shorten their
investment periods, quicken their time-to-market, and increase their overall ROI on the project.
Business Model
The author began this thesis with the assumption that projects are to be developed as products.
That is, software development efforts have a beginning with its definition of requirements, and a definite
ending once the requirements have been satisfied. However, the research completed for this thesis has
suggested that the PO business model may not be well-suited to projects which are developed with the
iterative delivery process.
As stated before, one of the effects of the iterative delivery process is that it allows the client to
benefit from the development effort earlier. However, this short-term financial incentive is beneficial
exclusively to the client, while the software vendor will benefit only indirectly if the client provides them
with future work. Under the PO business model, conflicts between the client and the software vendor may
occur since both parties may decide to maximize their short-term profits. In practice, this often results in
a deteriorated relationship, and may even force one of the parties to seek another business partner. This in
turn affects the long-term profits for both the client and the vendor, since both will have to expend
resources searching for a new vendor or a new customer.
It is the author's belief that these problems could be minimized with the use of the SO business
model. By using this model, a vendor could respond to a request for proposal by sub-sectioning a project
into smaller parts, not contractually binding the client to all of the sections, and treating each of the
sections as service contracts to be agreed on sequentially. In this manner, the client and the vendor would
be able to begin a long-term relationship which would allow the vendor to acquire the business
knowledge required to better serve their clients, while the clients would become dependent on the service
30
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
38/41
solutions provided by the software vendor.
The author also believes that as the software industry matures, companies will no longer be able
to use a PO business model. The reason for this is that this model is not well-suited to developing digital
material which can be easily distributed via the Internet. Furthermore, this model requires that a great
deal of resources be wasted to prevent users from using the software illegally, and therefore has a higher
development cost than the SO business model.
Further Research Suggestions
Although software quality is an important concern, most of the literature about effort estimation
does not deal with this aspect of project management. Instead, the focus is most often placed exclusively
on estimating the total cost of producing the project without stating anything about the quality. This
obliges customers to compare project proposals solely on their estimated price tags, and in some cases
information about a vendor's past performance. Research in finding ways to quantify and estimate
software quality could provide decision makers with the information that they require to make better
business decisions.
In this thesis, it has been suggested that companies should shift to an SO business model.
However, this suggestion begets the question of how companies are to perform such a strategical change.
Obviously, established companies will want to continue collecting revenues from their products for as
long as they are able to do so, while also attempting to remain competitive. Further research needs to be
conducted to enable companies to make the decision of when and how quickly they should change their
business model.
Companies such as eBay, Youtube and Google have enjoyed extraordinary growth by using an SO
business model and the iterative delivery process over the Internet. Research on the impact of these
companies on the software industry may enable the prediction of upcoming business models trends. This
31
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
39/41
information could be used by educational institutions to offer courses to better assist their students.
32
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
40/41
REFERENCES
[1] P. Pande, R. Neuman, and R. Cavanagh, The Six Sigma Way, McGraw-Hill, 2000.
[2] M. Poppendieck and T. Poppendieck, Lean Software Development, Addison-Wesley, 2003.[3] K. Molkken-stvold, M. Jrgensen, S. Tanilkan, H.Gallis, and A. Lien, S. Hove, "A survey onsoftware estimation in the Norwegian industry", 10th International Symposium on Software Metrics, 14-
16 Sept., 2004, pp. 208- 219.[4] O. Benediktsson and D. Dalcher, "Effort estimation in incremental software development", Software,IEEE Proceedings, vol. 150, iss. 6, 2003, pp. 351 - 357.
[5] K. Molkken and M Jrgensen, "A review of software surveys on software effort estimation", isese,2003, p. 223.
[6] M. Cusumano, The Business of Software, FREE PRESS, 2004.[7] K. Schwalbe, Information Technology Projet Management, Thomson Course Technology, 2004.
[8] PMBOK Guide, Third Edition v1.2 CD-ROM, Project Management Institute, 2004.[9] E. Stensrud and I. Myrtveit, "Human performance estimating with analogy and regression models",
Fifth International Software Metrics Symposium, 1998, pp. 205-213.[10] M. Jrgensen, "A review of studies on expert estimation of software development effort", Journal of
Systems and Software, 2004, vol. 70, iss. 1-2, pp. 37-60.[11] H. Leung and Z. Fan, "Software Cost Estimation", Handbook of Software Engineer and Knowledge
Engineer, Vol. 2, 2002, .[12] M. Jrgensen, "Top-Down and Bottom-Up Expert Estimation of Software Development Effort",
Journal of Information and Software Technology, Vol. 46, Iss. 1, 2004, pp. 3-16.[13] "COCOMO", [Online document], Available at HTTP: http://en.wikipedia.org/wiki/COCOMO
[14] A. J. Bagnall, V. J. Rayward-Smith and I. M. Whittley, "The next release problem", Information and
Software Technology, 2001, Vol. 43, Iss. 14, pp. 883-890.[15] C. Larman and V.R. Basili, "Iterative and incremental developments: a brief history", Computer,2003, Vol. 36, Iss. 6, pp. 47-56.
[16] K. Beck and M. Fowler, Planning EXtreme Programming, Addison-Wesley, 2001.[17] M. Cohn, Agile Estimating and Planning, Prentice Hall Professional Technical Reference, 2006.
[18] "Software By Number: Frequently Asked Questions", [Online document], Available at HTTP:http://dactyl.cti.depaul.edu/ifm/faqs.html
[19] M. Denne and J. Cleland-Huang, "The Incremental Funding Method, A Data Driven Approach toSoftware", IEEE Software, 2004, Vol. 21, Iss. 3, pp. 39-47.
[20] W. Deming, Out of the crisis, First MIT Press edition, 2000.[21] M. Cusumano, The Business of Software, Free Press, 2004.
[22] "Software piracy losses 2003, by selected countries", [Online document], Available at HTTP:http://www.aic.gov.au/topics/cybercrime/
[23] "Peruvian Congressman refutes Microsoft's "Fear, Uncertainty and Doubt"", [Online document],Available at HTTP: http://www.opensource.org/docs/peru_and_ms.php
[24] S. Nambisan, "Why Service Businesses Are Not Product Businesses", MIT Sloan ManagementReview, 2001, vol. 4, iss. 42, pp. 72-80.
33
-
7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS
41/41
[25] "A Brief History of Free/Open Source Software Movement", [Online document], Available at HTTP:
http://www.openknowledge.org/writing/open-source/[26] F. Brooks, "No Silver Bullet Essence and Accidents of Software Engineering", Computer, 1987,
vol.20, iss.4, pp. 10-19.