Towards a Multi-Dimensional Framework for Assessing the Value of

Software Projects

by
John Richard Kopp


Submitted in partial fulfillment
of the requirements for the Masters degree in
Software Development and Engineering

at

Seidenberg School of Computer Science and Information Systems

Pace University


June 2009


We hereby certify that this thesis, submitted by John Kopp, satisfies the thesis
requirements for the Masters degree in Software Development and Engineering and has
been approved.




_____________________________________________-________________
Dr. Olly Gotel Date
Chairperson of Thesis Committee


_____________________________________________-________________
Dr. Frank Marchese Date
Thesis Committee Member


_____________________________________________-________________
Dr. Sotiris Skevoulis Date
Thesis Committee Member


Seidenberg School of Computer Science and Information Systems
Pace University 2009



Abstract
Towards a Multi-Dimensional Framework for Assessing the Value of
Software Projects

by
John Richard Kopp

Submitted in partial fulfillment
of the requirements for the Masters degree in
Software Development and Engineering

June 2009


As the role of software within organizations and within society has increased, so have the
costs of producing and maintaining it. Whether the value delivered by software has
proportionally increased is a subject of debate. This phenomena has been coined the IT
value paradox. Part of the difficulty in establishing value is that it is dependent on
perspective. Value at the level of society, value at an organization level and value at an
individual project level need to be evaluated differently. Value also depends on the
viewpoint of the recipient. That received by society in general differs from that received
by consumers and from that received by the organization. This thesis specifically
examines the assessment of value of software projects from the perspective of the
organization. Value is seen to be multidimensional. Financial value can be measured
using techniques such as net present value calculations, internal rate of return and
payback period under the assumption that the world is static. Flexibility by management
is quantified by real option techniques and the dynamics of the marketplace by game
theory. In addition to financial measures, understanding project alignment with the
organization and with IT departments is essential to obtaining and understanding the
value of projects. A framework incorporating these multiple dimensions is presented to
allow systematic valuation of software projects.

Acknowledgements

I express my sincere gratitude to Dr. Gotel for her guidance, comments and feedback
over the last year which greatly assisted me in developing brief initial thoughts on this
topic into a more comprehensive understanding and framework. I thank her for teaching
me how to perform academic research and how to frame a large topic, such as the one
addressed in this thesis, in a manner so that it can be understood and communicated.
Learning how to find and define relevant questions and how to fully and properly answer
those questions was as valuable as learning the specific content of my thesis.

I also thank Dr. Marchese and Dr. Skevoulis for their efforts and feedback over the last
year.






v
Table of Contents
Abstract .............................................................................................................................. iii
List of Tables ...................................................................................................................... x
List of Figures ................................................................................................................... xii
List of Equations .............................................................................................................. xiv
Chapter 1 Introduction ................................................................................................. 1
1.1 Overview ............................................................................................................. 1
1.2 IT Value Paradox ................................................................................................ 4
1.3 Basic Question Addressed in This Work ............................................................ 5
1.4 Research Process ................................................................................................. 6
1.5 Roadmap ............................................................................................................. 6
Chapter 2 Current State of Practice in Project Valuation ............................................ 9
2.1 Overview ............................................................................................................. 9
2.2 Definition of Project Success .............................................................................. 9
2.3 Earned Value Techniques ................................................................................. 12
2.3.1 Introduction ................................................................................................... 12
2.3.2 Calculation of Earned Value (Example) ....................................................... 14
2.3.3 Predicting Cost at Completion ...................................................................... 17
2.3.4 Predicting Task or Project Duration ............................................................. 18
2.3.5 Use of Earned Value Techniques in Project Control .................................... 19
2.3.6 Discussion ..................................................................................................... 21
Chapter 3 Prerequisites for Project Valuation ........................................................... 22
3.1 Overview ........................................................................................................... 22
3.2 Stakeholder Value Proposition Elicitation, Analysis and Reconciliation ......... 23
3.2.1 Overview ....................................................................................................... 23
3.2.2 Benefits Realization Approach ..................................................................... 24

vi
3.2.3 Model Based (System) Architecting and Software Engineering (MBASE) . 28
3.2.4 Win-Win Model / Theory W ......................................................................... 29
3.2.5 Goal Based Techniques................................................................................. 31
3.3 Critical Success Factors .................................................................................... 34
3.4 Cost Estimation ................................................................................................. 37
3.5 Sales and Marketing Forecasts.......................................................................... 37
3.6 Discussion ......................................................................................................... 37
Chapter 4 Quantitative Approaches to the Measurement of Value ........................... 38
4.1 Overview ........................................................................................................... 38
4.2 Net Present Value (NPV) / Discounted Cash Flow .......................................... 39
4.2.1 Present and Future Values ............................................................................ 39
4.2.2 Discount Rates .............................................................................................. 43
4.2.3 Payback Period.............................................................................................. 48
4.2.4 Internal Rate of Return (IRR) / Return on Investment (ROI) ....................... 49
4.2.5 Comparison of NPV, IRR and Payback Period ............................................ 53
4.2.6 Capital Asset Pricing Model (CAPM) .......................................................... 54
4.2.7 Sensitivity and Scenario Analysis ................................................................. 57
4.3 Real Options...................................................................................................... 58
4.3.1 Introduction ................................................................................................... 58
4.3.2 Decision Trees .............................................................................................. 61
4.3.3 Review of Financial Options ........................................................................ 66
4.3.4 Valuing Financial Options Upper and Lower Bounds ............................... 72
4.3.5 Valuing Options ............................................................................................ 75
4.3.6 Relationship between Calls and Puts ............................................................ 79
4.3.7 Factors impacting the price of options .......................................................... 79
4.3.8 Black Scholes Formula .............................................................................. 80
4.3.9 Introduction to Real Options/ Extended NPV .............................................. 82

vii
4.3.10 Option to Defer ......................................................................................... 83
4.3.11 Option to Expand ...................................................................................... 88
4.3.12 Compound Options ................................................................................... 90
4.3.13 Example of Application of Black-Scholes Formula ................................. 95
4.3.14 Discussion ................................................................................................. 97
4.4 Game Theory Approaches to Project Valuation ............................................... 98
4.4.1 Introduction ................................................................................................... 98
4.4.2 Definition of Game Theory ........................................................................... 99
4.4.3 Nash Equilibrium / Prisoners Dilemma Example ......................................... 99
4.4.4 Commitments .............................................................................................. 101
4.4.5 Games ......................................................................................................... 102
4.4.6 Scenarios ..................................................................................................... 103
4.4.7 Discussion ................................................................................................... 110
4.5 Process Measures ............................................................................................ 110
4.5.1 Introduction ................................................................................................. 110
4.5.2 Generic Process Frameworks ...................................................................... 111
4.5.3 Process Measures ........................................................................................ 112
4.5.4 Use of Process Measures ............................................................................ 120
4.6 Discussion ....................................................................................................... 123
Chapter 5 Qualitative Approaches to the Measurement of Value ........................... 128
5.1 Overview ......................................................................................................... 128
5.2 Balanced Score Cards ..................................................................................... 129
5.2.1 Introduction ................................................................................................. 129
5.2.2 Traditional Balanced Scorecards ................................................................ 130
5.2.3 Linking Strategy to Measures ..................................................................... 133
5.2.4 Balanced IT Scorecards .............................................................................. 136
5.2.5 Corporate Governance ................................................................................ 139

viii
5.3 Project Portfolio Management / IT Governance ............................................. 140
5.4 Alignment with Organization Strategies and with IT Goals and Architecture 142
5.5 Discussion ....................................................................................................... 143
Chapter 6 A Proposed Multi-Dimensional Framework for Project Valuation ........ 144
6.1 Introduction ..................................................................................................... 144
6.2 Overview of the Framework ........................................................................... 146
6.2.1 Portfolio Based Approach ........................................................................... 146
6.2.2 Quantitative (Financial) Measures .............................................................. 146
6.2.3 Qualitative Measures .................................................................................. 146
6.2.4 Iterative Nature of the Process .................................................................... 147
6.3 Project Evaluation Framework ....................................................................... 147
6.4 Project Valuation Process ............................................................................... 149
6.5 Effect of Supplier and Customer Types .......................................................... 150
6.5.1 Shrink Wrap Projects (Suppliers Perspective)........................................... 155
6.5.2 Shrink Wrap Projects (Customers Perspective)......................................... 156
6.5.3 Bespoke Projects (Suppliers Perspective) ................................................. 157
6.5.4 Bespoke Projects (Customers Perspective) ............................................... 159
6.5.5 Internal Projects .......................................................................................... 160
6.6 Qualitative Evaluations ................................................................................... 160
6.7 Project Portfolios ............................................................................................ 162
6.7.1 Weill MIT CISR Framework (Categorization by Investment Type) .......... 162
6.7.2 Ross Beath (MIT CISR) Categorization by Management Objectives ..... 164
6.7.3 Proposed Categorization Scheme ............................................................... 167
6.8 Types of Firm .................................................................................................. 171
6.9 Investment Boundary ...................................................................................... 172
6.10 Discussion ....................................................................................................... 174
Chapter 7 Application of the Framework ................................................................ 175

ix
7.1 Example .......................................................................................................... 175
7.2 Discussion ....................................................................................................... 180
Chapter 8 Conclusions and Future Work ................................................................ 181
8.1 Conclusions ..................................................................................................... 181
8.2 Future work ..................................................................................................... 183
Glossary .......................................................................................................................... 185
References ....................................................................................................................... 188


x
List of Tables

Table 1 Measures Used in Earned Value Techniques ..................................................... 13
Table 2 Cost and Schedule Variance (Based on [8]) ....................................................... 15
Table 3 Summary of Cost and Schedule Performance Indexes (Based on [8]) ............... 16
Table 4 Cost Estimates at Completion (based on [8]) ...................................................... 17
Table 5 Time Estimates at Completion (based on [8]) ..................................................... 18
Table 6 Evaluation of Critical Success Factors for an Example Project .......................... 35
Table 7 Example of NPV Sensitivity Analysis ................................................................. 45
Table 8 Payback Period Example ..................................................................................... 48
Table 9 Comparison of NPV and IRR on Mutually Exclusive Projects (from [36]) ........ 51
Table 10 Comparison of IRR and NPV for Three Projects .............................................. 52
Table 11 Comparison of NPV, IRR and Payback Period ................................................. 53
Table 12 November 11th Google Option Prices [47] ....................................................... 66
Table 13 Factors Impacting Option Prices [51] ................................................................ 79
Table 14 Analogies between Real and Financial Options for Option to Defer [54]......... 87
Table 15 Present Values of Cash Flows for Movie Delivery Example ............................ 91
Table 16 Cash Flows Years 2 through 10 ......................................................................... 92
Table 17 Classic Prisoner's Dilemma ............................................................................. 100
Table 18 Analogies between Prisoners and Firms in Classic Prisoners Dilemma Game 103
Table 19 Prisoners Dilemma Game between Firms ...................................................... 105
Table 20 Analogies between Prisoners and Firms in Classic Grab the Dollar Game..... 107
Table 21 Grab the Dollar Example ................................................................................. 108
Table 22 Generic Process Goals ..................................................................................... 111
Table 23 Strengths and Limitations of Financial Valuation Techniques ........................ 125

xi
Table 24 Causal Relationships Supporting Strategic Objective of Increased Sales ....... 134
Table 25 Additional Measure Supporting Strategic Objective of Increased Sales ......... 134
Table 26 Supplier-Customer Type Summary ................................................................. 154
Table 27 Assumptions, Measures and Uncertainties of Shrink Wrap Projects (Supplier's
Perspective) ............................................................................................................. 156
Table 28 Assumptions, Measures and Uncertainties of Shrink Wrap Projects (Customer's
Perspective) ............................................................................................................. 157
Table 29 Assumptions, Measures and Uncertainties of Bespoke Projects (Supplier's
Perspective) ............................................................................................................. 158
Table 30 Assumptions, Measures and Uncertainties of Bespoke Projects (Customer's
Perspective) ............................................................................................................. 159
Table 31 Assumptions, Measures and Uncertainties of Internal Projects ...................... 160
Table 32 Usefulness of Process Measures by Project Type ........................................... 168
Table 33 Relevant Financial Measures by Project Type ................................................ 170
Table 34 Value in Different Firm Types......................................................................... 171
Table 35 Project Type Emphasized by Firm Type ......................................................... 172
Table 36 Example of Use of Framework ........................................................................ 176


xii
List of Figures

Figure 1 Relationship between Project and Product Life Cycles (based on [5]) .............. 10
Figure 2 Illustration of PV, BAC, AC and EV ................................................................. 14
Figure 3 Tracking Project Performance using Earned Value Techniques ........................ 20
Figure 4 Earned Value Measures as Feedback (based on [9]) .......................................... 21
Figure 5 Modeling Elements for Benefit Realizations Approach (from [10]) .................. 26
Figure 6 Example of Benefit Realizations Approach ....................................................... 27
Figure 7 MBASE Model Integration Framework [14] ..................................................... 29
Figure 8 Plot of NPV vs. Discount Rate ........................................................................... 46
Figure 9 Decision Tree for Option to Expand .................................................................. 59
Figure 10 Decision Tree Example .................................................................................... 63
Figure 11 Profit from Nov Call Option with 320 Strike Price .......................................... 69
Figure 12 Profit from Nov Call Option with 320 Strike Price .......................................... 70
Figure 13 Profit from Nov Put Option with 320 Strike Price ........................................... 71
Figure 14 Upper and Lower Bounds to Value of Call Option .......................................... 72
Figure 15 Stock Prices of Hypothetical Security .............................................................. 76
Figure 16 Option Prices on Hypothetical Security ........................................................... 76
Figure 17 Price of Equivalent Portfolio ............................................................................ 77
Figure 18 NPV Analysis for Option to Defer Example .................................................... 84
Figure 19 Option Analysis for Option to Defer Example ................................................. 86
Figure 20 Option Value Calculation - Option to Expand Example .................................. 89
Figure 21 Cash Flows for Internet Based Movie Delivery Example ................................ 90
Figure 22 Possible Changes in Demand (Movie Delivery Example) ............................... 93
Figure 23 Working Backwards in Movie Example .......................................................... 94
Figure 24 Impact of Nature of Project on Selection of Financial Measures ................... 127

xiii
Figure 25 Organizational Balanced Scorecard Example ................................................ 135
Figure 26 Balanced Scorecard Cascade [75] .................................................................. 137
Figure 27 Project Evaluation Framework ....................................................................... 148
Figure 28 Supplier Types ................................................................................................ 151
Figure 29 Customer Types .............................................................................................. 153
Figure 30 Shrink Wrap Projects Financial Value Calculation (Supplier's Perspective) . 155
Figure 31 Shrink Wrap Projects Financial Value Calculation (Customer's Perspective) 157
Figure 32 Bespoke Projects Financial Value Calculation (Supplier's Perspective) ........ 158
Figure 33 Bespoke Projects Financial Value Calculation (Customer's Perspective) ...... 159
Figure 34 Internal Projects Financial Value Calculation ................................................ 160
Figure 35 Project Evaluation against Firm's Objectives ................................................. 161
Figure 36 Project Evaluation against IT Goals and Architecture ................................... 161
Figure 37 Project Evaluation against Project Success Factors ....................................... 161
Figure 38 Returns from the Four Project Categories (based on [84]) ............................. 164
Figure 39 Project Classifications (from [85]) ................................................................. 165
Figure 40 Proposed Project Classification Scheme ........................................................ 168
Figure 41 Investment Boundary: ROI vs. Chance of Loss ............................................ 173
Figure 42 Investment Boundary: NPV vs. Chance of Loss ........................................... 174
Figure 43 Project Evaluation with respect to Organization and IT Goals ...................... 178
Figure 44 Project Evaluation with respect to Organization Goals and Project Success
Factors ..................................................................................................................... 179
Figure 45 Project Evaluation with respect to IT Goals and Project Success Factors ..... 180


xiv
List of Equations
Equation 1 Future Value Of $100, One Period At 5% ..................................................... 40
Equation 2 Future Value After One Period....................................................................... 40
Equation 3 Present Value After One Period ..................................................................... 40
Equation 4 Present Value of $110 .................................................................................... 40
Equation 5 Future Value After N Periods ......................................................................... 41
Equation 6 Present Value Of An Amount To Be Received in N Periods ......................... 41
Equation 7 NPV of Word Processor Project Example Assuming 5% Discount Rate ...... 42
Equation 8 NPV of Word Processor Project Example Assuming 12% Discount Rate .... 44
Equation 9 Rate of Return................................................................................................. 49
Equation 10 Single Period NPV Set to Zero ..................................................................... 50
Equation 11 Discount Rate ............................................................................................... 50
Equation 12 Calculation of NPV for Example from Section 6.1.2 ................................... 50
Equation 13 Variance of Portfolio of Two Assets [39] .................................................... 55
Equation 14 Capital Asset Pricing Model (Risk Premium) .............................................. 56
Equation 15 Calculation of Beta ....................................................................................... 56
Equation 16 NPV Calculation at Start of Project for Full System .................................... 64
Equation 17 NPV Calculation at Year 1 Assuming System Upgrade .............................. 64
Equation 18 NPV Calculation at Year 1 Assuming No Upgrade ..................................... 64
Equation 19 NPV Calculation at Start of Project for Partial System ................................ 65
Equation 20 NPV Calculation at Start of Project for Partial System with No Option to
Expand ...................................................................................................................... 65
Equation 21 Relationship of Call Price to Hypothetical Portfolio at Start of Period ....... 77
Equation 22 Relationship between Call Price and Hypothetical Portfolio with Increase in
Stock Price ................................................................................................................ 77
Equation 23 Relationship between Call Price and Hypothetical Portfolio with Decrease in
Stock Price ................................................................................................................ 77

xv
Equation 24 Number of Shares ......................................................................................... 78
Equation 25 Size of Loan in Portfolio .............................................................................. 78
Equation 26 Value of Call................................................................................................. 78
Equation 27 Risk Neutral Probability ............................................................................... 79
Equation 28 Black-Scholes Formula ................................................................................ 81
Equation 29 NPV Analysis using Risk Free Discount Rate - Option to Defer Example . 85
Equation 30 NPV Analysis using Risk Adjusted Discount Rate - Option to Defer
Example .................................................................................................................... 85
Equation 31 Static NPV of Operating System Example ................................................... 85
Equation 32 Option Value - Option to Defer Example ..................................................... 87
Equation 33 Project Value at Year 1 - Option to Expand Example.................................. 88
Equation 34 Project Value at Year 1 with High Demand - Option to Expand Example .. 88
Equation 35 Project Value at Year 1 with Low Demand - Option to Expand Example... 88
Equation 36 Project Value at Start of Project - Option to Expand Example .................... 89
Equation 37 Option Value Calculation - Option to Expand Example .............................. 89
Equation 38 Risk Free Probability (Movie Delivery Example)........................................ 94
Equation 39 NPV Calculation for Process Measurement Example ................................ 122




1
Chapter 1

Introduction
1.1 Overview
Over the last few decades, the cost of software to firms has grown significantly both in
absolute terms and as a percentage of the budgets of firms. Given this increase in
spending, one would expect to see a similar corresponding increase in value delivered to
the firm and to society. This linkage has been difficult to demonstrate, leading to what
has been described as the IT value paradox. Despite becoming ubiquitous within firms
and society in general, softwares impact and that of software projects has been difficult
to elusive to quantify. Part of the difficulty in establishing value is that it is dependent on
perspective. Value at the level of society, value at an organization level and value at an
individual project level need to be evaluated differently. Value also depends on the
recipient. That received by society in general differs from that received by consumers and
from that received by the firm. This thesis specifically examines the evaluation of value
of software projects from the perspective of the firm.
The need to deliver value to the users of our products increases as the role of software in
the success of enterprises and in society in general continues to grow. The value of
software projects can be evaluated in multiple dimensions including the degree of
satisfaction of stakeholder value propositions, financial terms and in terms of support for
larger organizational goals or strategies. Value considerations can be used to focus


2
resources and to evaluate the usefulness of software processes toward the goal of
delivering user needs.
Current project tracking and control methods, earned value techniques, as prescribed by
professional organizations describe project tracking and control as being done against the
plan of execution of the project. Completion of a project plan does not necessarily
correlate with the delivery of value. Explicit consideration of value is required. Project
tracking and control against a value baseline will lead to the better achievement of
stakeholder goals, the organizations strategies and to financial benefits. The components
required to establish such a value baseline are examined within this work.
There are several techniques used to quantify the financial benefits or returns expected
from a software project. The Net Present Value (NPV) of a project is calculated by
discounting future revenues and expenses by appropriate rates to calculate the total
present value of the project. The internal rate of return and the payback period provide
alternate views into the same numbers supporting the NPV calculation. Real options and
the use of decision trees are used to quantify the value of flexibility within projects.
Results from game theory can quantify the effects of market conditions, competition and
market timing. The inputs into these financial techniques vary from sales and market
forecasts for products sold in the marketplace to the quantification of business process
changes for software products used internally by the firm. The applicability of these
techniques and their use are examined.
Many techniques for eliciting, reconciling and measuring satisfaction of stakeholder
value propositions have been developed and are prerequisites for determining and


3
obtaining value. Identifying all key stakeholders and understanding the role of the
intended software within larger systems which include other software applications and
human actors are significant to identifying and reconciling value propositions. The
applicability and the use of techniques such as the Benefits Realization Approach, Model
Based (System) Architecting and Software Engineering (MBASE) and goal oriented
requirements engineering are examined within this thesis.
Projects exist within a larger framework of portfolios and also to varying degrees support
or conflict with overall corporate strategies and with IT strategies. The degree to which
an individual project complements other projects within a portfolio or supports corporate
or strategy is another important measure of its value. The satisfaction of stakeholder
value propositions refers to the degree that a project fulfils its own set of requirements. A
project has additional value when viewed from a wider perspective. The alignment of
projects within portfolios and with overall corporate and IT goals and strategies can be an
important criterion in project selection and delivery of value. Balanced scorecard
techniques are examined as a means of achieving this alignment.
Other factors play a role in successful delivery of value from a project and must be
identified to develop more comprehensive project evaluation techniques. For instance,
the level of innovation in a project and its level of complexity have impact on its chance
for success and influence the projects chance of delivering value. Factors such as the
skills of the project team and the organizational environment are also crucial. The
projects evaluation against these factors can be related to its chances for successful
completion.


4
Ultimately, multiple value based techniques, such as those measuring the financial
returns from a project and those measuring alignment with organizational goals need to
be combined in order to establish comprehensive measures for a project. This thesis will
examine ways to combine these techniques in a useful way for practitioners. A
systematic framework for the evaluation of projects is presented.
1.2 IT Value Paradox
Robert Solow, a Nobel price winning economist is frequently quoted as saying You can
see the computer age everywhere but in the productivity statistics. [1] In IT Doesnt
Matter [2], Carr provides a comparison that shows that the growth in spending on IT has
paralleled growth in spending of railroads and electricity. He argues that each follows
the same development pattern. Early adopters gain significant strategic advantages. As
usage becomes more widespread, each no longer offers advantage, only parity. He
argues that just as electricity and railroads became commodities, so too has IT. If IT is a
commodity, then firms should seek to minimize spending, seek off the shelf solutions
rather than firm specific distinct IT solutions and seek to ensure only that they have
sufficient IT resources to have parity with competitors. If IT can offer strategic
advantages to the firm, then increased spending on IT and development of firm specific
applications and IT solutions is valuable. It would offer competitive advantages. Carrs
postulation and other similar ones cause considerable debate. By extension, if ITs
contribution to value is limited, then what about the contributions of individual
academics and practitioners? [3]


5
The responses to arguments about ITs lack of value, which predate Carr, can be divided
into two groups. One attempts to understand sources of IT value and to improve value
delivered through the use of requirements techniques. Any lacking in delivered value is
seen as a failure to understand business needs and in the business changes necessary to
effectively utilize IT solutions. These are examined in section 3.2, Stakeholder Value
Proposition Elicitation, Analysis and Reconciliation. The second group attempts to
understand IT value generated, both quantitatively and qualitatively. The value of IT can
be studied at three levels.
At a national or society level. What has IT brought to the population?
At a firm level. What role does IT bring in allowing the firm to achieve greater
wealth generation? Does IT bring competitive advantage to the firm? How can
this be maximized?
At a project level. Simply, what is the value of individual projects? How should
projects be selected, prioritized and monitored?
This thesis primarily studies the question at the project level. It examines techniques to
determine the value of individual projects and of their selection. As part of
understanding value, the scope and requirements of the project must also be well
understood.
1.3 Basic Question Addressed in This Work
The basic question addressed in this thesis is the following. How can the value of a
software project be understood and assessed? Consider the following two projects:
Project A was estimated to cost 200,000 and last for 6 months. It was completed
for 180,000 in 5 months.
Project B was estimated to cost 300,000 and last for 9 months. It was completed
for 800,000 in 18 months.



6
Which project had more value?
The correct answer is that you cant tell from the information provided, yet it is not
uncommon for practitioners and organizations to make assessments using the very type of
incomplete information presented above. Only project cost and possibly the
successfulness of the job done by the project manager are described. The business value
of the project is not. Its quite possible that project B delivered more value to the
organization. This thesis is directed toward developing a systematic framework to
answer questions of this nature, that is, to understand project value, both quantitatively
and qualitatively.
1.4 Research Process
A survey and review of available literature from multiple fields including computer
science and software engineering, general management, finance and project management
was performed. Relevant approaches and concepts from these sources were combined
and synthesized into a framework with the intended goals of producing a summary and
guide useful to practitioners desiring to understand the sources and assessment of project
value and of providing a step by step process that could be used for assessment of project
value. Empirical validation of the proposed framework was outside the scope of this
thesis given time and resource constraints, but would be a direction for future work.
1.5 Roadmap
This work is divided into the following sections:


7
Current State of Practice in Project Valuation: A discussion of what is commonly
meant by project success and what should be meant is given. The benefits and lackings
of earned value techniques, commonly used to track and measure project progress, are
described.
Prerequisites for Project Valuation: Certain core competencies are required before
systematic valuation of projects is possible. An overview of several requirements
techniques, including the Benefits Realization Approach and goal based requirements
engineering are presented. Good requirements techniques allow the costs and benefits of
projects to be better understood and measured. Critical success factors, factors associated
with a better chance of a project successfully completing are also presented.
Quantitative Approaches to the Measurement of Value: Financial measures of value,
calculated from estimated costs and revenues, are presented. Static techniques, such as
net present value, internal rate of return and payback period, assume the course of the
project will not change. Real options is presented as a technique to allow the benefits of
managerial flexibility and choices to be quantified. Game theory is presented as a way to
model and quantify competition. Process measures are presented as a means of
quantifying the benefits of internal projects, that is, those that address internal business
needs and do not produce a product for sale.
Qualitative Approaches to the Measurement of Value: Project value is
multidimensional. Quantitative (financial) techniques do not fully capture project value.
Alignment with the strategic goals of the organization and with IT goals and architecture
is considered.


8
A Proposed Multi-Dimensional Framework for Project Valuation: A proposed
process for evaluating project value is presented. Both quantitative and qualitative
techniques are combined to allow better assessment of value.
Application of Framework: An example of the use of the framework is presented. Due
to time and resource constraints, the example is fictional, but is designed to emphasize
various aspects of the proposed process.
Conclusions and Future Work: Concluding remarks and possible future research
directions are presented.



9
Chapter 2

Current State of Practice in Project Valuation
2.1 Overview
A clear distinction must be made to distinguish between the project being conducted and
the product being designed and constructed. Many project management techniques and
measures of success examine only the former while the later is the only source of value.
Current practice utilizes techniques such as the earned value technique, which while
useful as a means of controlling and measuring progress, provide no information on the
value generated by a software project. There is no value in the earned value technique;
it is actually a cost tracking technique.
2.2 Definition of Project Success
An understanding of the meaning of project success is essential in developing
frameworks that can be used to value projects and to track success in the achievement of
that value. The definition of success is a key element in understanding what elements
need to be measured and tracked to evaluate project value. Success can be measured
along several dimensions and evaluation of the project in each of these dimensions can be
crucial for successful project delivery and to evaluate project value.
The distinction between the project and product and between the project life cycle and the
product life cycle is important. A project is a temporary endeavor undertaken to create a
unique product, service or result [4]. The product is the result of the project and has a


10
lifespan well past the end of the project. The relationship between the project and
product cycles is illustrated in the figure below from [5].
Business Plan
Product Life
Cycle
I
D
E
A
Initial Intermediate Final
Operations Divestment
Project Life
Cycle
P
r
o
d
u
c
t
Upgrades

Figure 1 Relationship between Project and Product Life Cycles (based on [5])
Of note, it is during the potentially long operations period, when the product is in active
use, when much of the business value promised by the project is delivered. During the
divestment or end of life phase some of the cost of the product is incurred or potentially
through salvage value, some of the cost of the product is recovered. Also significant is
that the operations phase of the products life is typically much longer than the formal
software project.
It is important to consider the difference between the project life cycle and the product
life cycle. Traditional measures of project success, such as the earned value technique,
discussed in section 2.3, have focused on time, cost and scope measures during the life of
the project. This narrow focus on the project life cycle leads to only operational
measures and misses the strategic value of the project. [6] It casts project success in terms
of internal project measures rather than in terms of what the project delivers to the
organization. It measures project delivery against the original plan, but fails to consider
the value delivered to stakeholders. The project life cycle is typically considered to end


11
with the start of the operational life of the product, that is, when the product is
delivered or implemented. By taking a limited view, looking only at the project life cycle
rather than the whole product life, much of the value of the project is not accounted for.
Judgev [6] suggests that a more holistic understanding of project success can be achieved
by measuring success during operations and decommissioning when effectiveness
measures are taken into account and involve input from different stakeholders. By
considering the whole product life, rather than just the project, we can measure both the
projects value to the organization and obtain feedback from stakeholders. Measuring the
value during the products operational life is also critical feedback that allows assessment
of valuation techniques done earlier in the project.
Another consideration in measuring project success is the difference between project
efficiency and effectiveness. Efficiency looks at time, scope and cost. Effectiveness
focuses on satisfying stakeholder requirements and goals. It is a wider view of project
success. Efficiency is operational in focus measuring the success of the project against
its plan. Effectiveness is more strategic measuring the value the project produced. An
alternate description of this is the difference between project management success and
project success. Cooke-Davies [7] makes the following distinction.
Project management success, being measured against the traditional gauges of
performance (i.e., time, cost and quality), and
Project success, being measured against the overall objectives of the project.
Many traditional measures of project success are actually measures of project
management success rather than project success. There are many examples of successive
projects that failed from an evaluation with respect to time and cost, and more


12
significantly, projects that succeeded on cost and time measures but failed overall. In
the latter case, traditional project measures such as the earned value technique may
declare the project a success and the project manager successful despite a lack of
satisfaction of stakeholder goals. Jugdev describes this phenomena succinctly as an
example of "the operation was a success, but the patient died [6]. Project management
success helps to complete the project and deliver a product. Project success is the
measure of the business or strategic value delivered.

Jugdev [6] traces the evolution of measures of project success. Initially (1960 - 1980),
success was defined mainly in terms of cost, time and scope measures. As noted earlier,
these measures fail to consider stakeholder satisfaction or overall product success and as
such fail to be good measures of project success and do not in themselves lead to
effective means of measurement of value delivered. Value must consider the financial
worth of the product and include an assessment of the project in terms of the stakeholder
needs or satisfaction or in terms of the wider organization.

2.3 Earned Value Techniques
2.3.1 Introduction
The earned value technique allows tracking and control based on time and scope
estimates and measurements. It allows for calculation of schedule and cost variances
and provides a means to calculate estimated cost at completion and estimated time to
completion as a project progresses. As shown later in this section, earned value, EV,
techniques can serve a role in early detection of time and schedule variances and in


13
understanding the effectiveness of corrective actions. The earned value technique is in
common use in practice and is frequently a main measure of project success even though
it only it has no measures of value, only costs.
EV techniques are based on four measures or parameters [8]:
Table 1 Measures Used in Earned Value Techniques
Parameter Definition Example
Planned value (PV) or
Budgeted Cost of Work
Scheduled (BCWS)
This is the budget
allocated for performing a
task, work package or
project itself. It is a time
phased, meaning it is
dispersed or spent as the
task or project proceeds.
Assuming linear progress,
a task estimated to take
two months and cost
10000, would have a
planned value of 5000 at
the end of month one.
Budget at Completion
(BAC):
This is the total budget
allocated to a task, work
package or project.

A task estimated to cost
10000 has a budget at
completion of 10000.
Actual Cost (AC) or
Actual Cost of Work
Performed (ACWP)
This is the actual
cumulative cost at an
interim point in time spent
on a task, work package or
the project itself.

Suppose that at the end of
month one, 6000 has been
spent working on a task.
Its actual cost is 6000
regardless of how much of
the task is completed or
what was estimated to be
done.
Earned Value (EV) or
Budgeted Cost of Work
Performed (BCWP)
This is the cumulative
(earned) value of work
completed on a task, work
package or the project
itself at an interim point in
time.
Assume a task is estimated
to cost 10000. If it is 45%
complete, its earned value
is 4500.

PV, BAC, AC and EV as of the end of the first month for the example presented in the
above table are illustrated below in Figure 2.


14
C
u
m
m
u
l
a
t
i
v
e

V
a
l
u
e
Time (Months)
1 2
5000
10000 BAC
PV at Month 1
EV at Month 1
AC at Month 1

Figure 2 Illustration of PV, BAC, AC and EV
2.3.2 Calculation of Earned Value (Example)
Earned value is best understood with an example. Suppose a project consists of two
sequential tasks. Assume that the estimates have been reviewed and accepted and the
budget is approved. The budgets at completion of the tasks are 20000 and 30000,
respectively.
Task A: Estimated cost 20000, estimated duration 2 months
Task B: Estimated cost 30000, estimated duration 3 months
Total Project: Estimated cost 50000, estimated duration 5 months

Suppose after one month, 12000 dollars have been spent on task A and it is 45%
completed.
The planned value, PV, of task A and the project at one month is 10000. This
assumes the progress expected and spending are linear. The task was expected to
take two months, so at the end of the first month, it was planned to have it half
done.

The actual cost, AC, of task A and the project at one month is 12000.


15

The earned value, EV, of task A and the project at one month is:
EV = percent complete * budgeted cost = 0.45 * 20000 = 9000.
From these measures, it is possible to calculate the cost performance and schedule
performance of the project at one month and to make predictions about the cost and
duration for project completion.
Table 2 Cost and Schedule Variance (Based on [8])
Term Calculation Meaning
Cost Variance, CV CV = EV AC Absolute variance in cost.
EV worth of value was
generated and it cost AC
Cost Performance Index,
CPI
CPI = EV/AC Ratio of value generated
(EV) to actual cost (AC)
Schedule Variance, SV SV = EV PV Variance in value
generation against plan. EV
worth of value was
generated, but we had
planned (scheduled) to
accomplish PV worth of
value
Schedule Performance
Index, SPI
SPI = EV/PV Ratio of value generated
(EV) to planned (scheduled)
value (PV)
Critical Ratio (CR) CR = CPI * SPI A measure of project health
[8]. Further described in
Table 3 Summary of Cost
and Schedule Performance
Indexes.

Continuing with the example:
Cost variance (CV) = EV AC = 9000 12000 = -3000. The interpretation of
this is that 12000 dollars has been spent to create 9000 worth of value. Money is
being spent than expected for the value produced.



16
Cost Performance Index (CPI) = EV/AC= 9000/12000 = 0.75. If money was
spent exactly as planned CPI would equal 1.0. A CPI of less than one indicates
that less value per dollar is being produced than that planned.

Schedule Variance (SV) = EV PV = 9000 10000 = -1000. The interpretation
of this is that 10000 dollars worth of value were planned to be created during the
first month, but only 9000 worth of value were actually created. Progress is
slower than planned.

Schedule Performance Index (SPI) = EV/PV = 9000/10000 = 0.9. If the project
was exactly on schedule, SPI would equal 1. A SPI of less than one indicates that
the project is behind schedule.

Critical Ratio (CR) = CPI *SPI = 0.75 * 0.9 = 0.675. The critical ratio is a
measure of project health [8]. A critical ratio greater than one is desirable. Less
that one indicates that the project is either behind on cost or schedule or on both.
It can be seen that CPI and SPI individually are insufficient measures. Suppose it
is costing more than estimated to create value (AC > EV or CPI < 0) and the
project is ahead of schedule (EV >PV or SPI > 0). The project may cost more but
may be completed sooner. Or suppose that it is costing less that estimated to
create value (EV > AC or CPI > 0) and the project is behind schedule (EV < PV
or SPI < 0). The project may cost less but may be completed later. Whether
either of these two scenarios should be a cause of concern is very dependent on
project particulars, but CR is a measure of the severity of the potential problem.

Table 3 Summary of Cost and Schedule Performance Indexes (Based on [8])
CPI SPI CR Cost Schedule Interpretation
> 1, EV >
AC
> 1, EV >
PV
>1 Ahead Ahead Positive
> 1, EV >
AC
< 1, EV <
PV
Depends Ahead Behind Mixed
< 1, EV <
AC
> 1, EV >
PV
Depends Behind Ahead Mixed
< 1, EV <
AC
< 1, EV <
PV
< 1 Behind Behind Negative



17
The example project is behind on both schedule and cost, corrective action may be
indicated and the cause of this deviation must at least be understood. Was the initial
estimate incorrect? Were the resources less skilled or less motivated than expected? Was
there a steeper than expected learning curve? Certainly, the corrective actions taken
depend on the cause, but equally significantly, the predicted cost at completion and
predicted project duration that can be made at this point as well based on the cause of the
deviation.
2.3.3 Predicting Cost at Completion
Earned value techniques can be used to estimate the cost of a task or project at
completion. Two parameters of interest are
Estimate at Completion (EAC): Estimated cost of the project at completion

Estimate to Completion (ETC): Estimated cost for the remainder of the task or
project
The estimate to completion and estimate at completion at dependent on whether there is
any variance in cost and the possible cause of the variance as summarized below.
Table 4 Cost Estimates at Completion (based on [8])
Case ETC EAC Comments
No cost variance BAC AC =
BAC- EV
BAC Original cost estimates correct, project
on budget. The earned value (EV) is
exactly equal to the actual cost (AC).
For example, $1000 was spent to create
$1000 worth of value.
Original
estimate
incorrect
Must create
estimate for
remaining
work
AC + ETC New estimate needed for remaining
work. Potential causes for error in
estimate are ill defined scope, incorrect
understanding of task or project


18
complexity or of skills of resources
Over cost, but
original estimate
valid
BAC EV AC + BAC
EV =
BAC +AC
EV =
BAC + CV
One explanation is that the learning
curve was greater than expected. Once
trained, resources can be expected to
perform as by the original cost
estimate. EAC is the cost so far (AC)
plus the original estimate for the
remaining work (BAC EV).
Past
performance is a
good indicator
of future work
(BAC
EV)/CPI
AC + (BAC
EV)/CPI
= BAC/CPI
The original estimate for the remaining
work (BAC EV) is scaled by the
performance to date (1/CPI) and added
to the cost so far (AC).
Cost variance
but no
correction
BAC AC =
BAC- EV
BAC In this case, there is cost variance, but it
is assumed that the variance will
somehow be made up. This is usually
not very realistic and not a good
approach.

The value of the above table is that it provides a way to estimate the cost to complete a
project or task and the total cost at completion given its current state. It also provides
guidance on when a new estimation for the project is required.
2.3.4 Predicting Task or Project Duration
Analogous to ETC and EAC, it is possible to predict the time estimate at completion
(TEAC) and time estimate to completion (TETC) using the following parameters:
Schedule at Completion (SAC): This is original estimated duration for a task or
project.
Actual Time (AT): The actual duration of a task or project to date.

Table 5 Time Estimates at Completion (based on [8])


19
Case TETC TEAC Comments
No schedule
variance
SAC AT SAC Original time estimates correct,
project on schedule
Original time
estimate
incorrect
Must create
new time
estimate for
remaining
work
AT + TETC New time estimate needed for
remaining work. Potential causes
for error in estimate are ill defined
scope, incorrect understanding of
task or project complexity or of
skills of resources
Behind
schedule, but
original
estimate valid
Original time
estimate for
remaining
work.
SAC - TV One explanation is that the learning
curve was greater than expected.
Once training, resources can be
expected to perform as by the
original cost estimate.
Past
performance
is a good
indicator of
future work
(SAC
AT)/SPI
SAC/SPI The original estimated duration for
the remaining work (SAC AT) is
scaled by the performance to date
(1/SPI) and added to the time spent
so far (AT).
Cost variance
but no
correction
SAC AT SAC In this case, there is time variance,
but it is assumed that the variance
will somehow be made up. This is
not very realistic.
The value of the above table is that it provides a way to estimate the time required to
complete a project and the total time the project will take.
2.3.5 Use of Earned Value Techniques in Project Control
Cost and time variances can be monitored over time as a project progresses as a means to
track progress and as a means to evaluate the effectiveness of project controls. Below is
an example of how CPI, SPI and CR are plotted and monitored as a project progresses.


20

Figure 3 Tracking Project Performance using Earned Value Techniques
The project is performing according to plan or better with respect to cost when CPI >= 1.
The project is performing according to plan or better with respect to schedule when SPI
>= 1. When either measure is less than one, the project may be in need of corrective
measures. Earned value is used as a form of feedback to control the project against its
original plan. The process is illustrated below.
Develop/Update
Plans
Perform to Plan
Measure actual
cost and
completion
status
Is CPI > 1 &&
SPI > 1
Determine
Corrective
Action
Yes
No

0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
1.1
1.2
R
a
t
i
o
Time
Project Performance
CPI
SPI
CR


21
Figure 4 Earned Value Measures as Feedback (based on [9])

2.3.6 Discussion
Earned value techniques perform a useful role in tracking and controlling cost and
schedule in software projects. They can be effective in controlling a project against an
initial plan. The technique itself is not lacking, but the real problem is described in
section 2.2. Earned value techniques measure project management success rather than
project success. They measure conformity to a plan. There is no explicit consideration
of whether the plan delivers value in financial terms or in terms of stakeholder value
propositions.
Interestingly, all of the value measures in earned value techniques are actually cost
measures. For instance, planned value, PV, is actually the estimated cost to complete the
project.
Successful project control requires attention to progress against plans, possibly via earned
value techniques, monitoring of the critical success factors described in section 3.3 and
explicit consideration of the measures of value described in Chapter 4, Chapter 5 and
Chapter 6 of this thesis.


22
Chapter 3

Prerequisites for Project Valuation
3.1 Overview
All project valuation techniques have an implicit assumption that the scope and
requirements of the project are sufficiently understood to allow estimation of costs and of
benefits. Without this level of understanding of the requirements of the project, accurate
and meaningful estimates are not possible and thus, accurate assessment of value is not
possible. Most software projects consists of both the design and construction of the
product and an associated set of changes within the business or within processes to
successfully adopt the product and adapt to use it well. Good requirements techniques
are needed to identify the changes needed to successfully use a new or modified product
and to obtain value from that product. A high level review of several requirements
techniques is presented.
Achievement of value from a software project requires the successful completion of the
project. Critical success factors are factors associated with higher chances of successful
project completion. They can be evaluated to establish necessary prerequisite conditions
before a project should be started and also can be used as a discriminator for project
selection. Critical success factors for projects are described and a simple method for
evaluation of projects against these factors is presented.


23
3.2 Stakeholder Value Proposition Elicitation, Analysis and Reconciliation
3.2.1 Overview
Good requirements techniques can be seen as a prerequisite for the valuation of projects.
In all techniques to measure the value of projects, there is a critical implicit assumption
that the scope of the project and the requirements for the project are known sufficiently
well to support value estimations appropriate for the current stage in the projects life
cycle. For instance, when projects are initially requested or proposed, sufficient
knowledge of their scope is required to make high level cost and benefit estimates. As
requirements are elicited, analyzed and validated, cost and benefit estimates should be
refined to reflect the better understanding of the project. Good requirements techniques
can be seen as necessary to obtain the understanding and details of the project required to
support valuation techniques.
IT expenditures represent a significant percentage of the expenditures of many
organizations. A natural question is, what value is returned by these expenditures. Can
this value be determined and produced by IT groups alone? Thorp [10] correctly states
that IT efforts or projects are typically only a small portion of a larger business effort and
it is necessary to consider the larger effort to both achieve and measure value to the
business. In project management terms, value needs to be established from an overall
program of business and IT projects. The IT project alone can neither deliver value nor
be the measurement of value. Thorp [10] refers to this as silver bullet thinking. The IT
project, by itself, does not deliver value and is not a silver bullet solution to the
underlying business need.


24
3.2.2 Benefits Realization Approach
3.2.2.1 Introduction
The Benefits Realization Approach [10] is a framework that allows consideration of the
overall business program, of which an IT effort or project is a part. It includes a simple
modeling technique that supports reasoning about the associated efforts needed to
achieve business value. There is an attempt to look at the entire set of conditions needed
for success; not just the IT efforts alone. The entire product life is examined rather than
just limited aspects of the software project. A concept to cash approach, rather than a
design to development approach, is needed to achieve value.
3.2.2.2 Approach
Key to an understanding of this approach is the notion that any IT solution, regardless of
its own merits, will not achieve its full value or benefit without wider and coordinated
changes in the business. Thorp [11] notes that even for IT efforts that would appear
initially to be primarily IT, when the product is fully integrated into the business much of
the changes and investments are actually on the business side. Organizations do not
always analyze, understand or track these related business costs. Thorp labels his
approach the Benefits Realization Approach. Three key premises underlie the
approach [11].
Benefits do not just happen
There is an adoption period for any new product and a learning curve as people learn
how to best utilize its functionality. Related to this is the notion that successful
realization of value (benefit) requires training and a migration plan from the current state
to a new one utilizing the software developed.


25
Benefits rarely happen according to plan
Benefits realization is a continuous process
These last two points noted by Thorp, really emphasize points noted in other parts of this
thesis. The achievement of value (or benefit) requires several steps.
An understanding of the measures of value is needed. From the realms of finance
and engineering economics, means of understanding the financial value of
projects (or of wider programs) are needed. Means of assessing the project in
relation to organizational and IT strategies and goals are also needed.
A wide understanding of means to elicit and understand the benefits and values
sought by stakeholders is needed. Modeling techniques such as the results chain
and goal based methods can elicit the requirements that will yield the value
sought by stakeholders. Getting this full set of requirements and goals and
understanding both the business and IT components needed are keys to obtaining
value.
The results of an initial analysis, an estimation of the value of the effort, a
business case, sets of goals, requirements and initiatives must be taken as what
they are: rough initial estimates of what needs to be done and what can be
achieved.
Progress must be measured, financial calculations must be redone and
achievements against models of stakeholder and organization value must be
monitored as reality unfolds. Some of the initial estimates will be proven correct
and some incorrect. Without measurement, the project or program is proceeding
blindly. Its unlikely to achieve the desired results given that it is quite unlikely
that initial estimates and plans are perfect. Evaluation of financial models,
requirements and goals, and business cases needs to be done early and often.
3.2.2.3 Results Chain Modeling
Results chain modeling is fully described in [12]. The interested reader is directed there.
A very brief example is presented below as an illustration. The key point of this
technique is to capture and understand all related business changes needed to accompany
software changes to achieve value.
Four main modeling elements are used [10]:


26
OUTCOME
INITIATIVE
ASSUMPTION
CONTRIBUTION
Outcome: The results sought, including either
intermediate outcomes in the chain, those
outcomes that necessary but not sufficient to
achieve the end benefit, or ultimate outcomes,
the end benefit to be harvested.
Initiative: actions that contribute to one or more
outcomes.
Contributions: the roles played by elements of
the Results Chain, either initiatives or
intermediate outcomes, in contributing to other
initiatives or outcomes.
Assumptions: hypothesis regarding conditions
necessary to the realization of outcomes or
initiatives but over which the organization has
little or no control. Changes to assumptions
require updates in the Result Chain

Figure 5 Modeling Elements for Benefit Realizations Approach (from [10])
3.2.2.4 Results Chain Example
The following example is an enhanced version of an example from Thorp [13]. The
enhancements include a consideration of training, of motivating factors and of associated
business process changes.
A firm is experiencing a drop in sales. Feedback from customers includes
complaints that order fulfillment is taking too long. The current order entry
system is paper based, manually intensive and time consuming. An automated
order entry system is proposed.


27
Initiative:
Implement an
automated order
entry system.
Outcome:
Reduced order
entry time
(Intermediate
outcome)
Assumption: The
time to fulfillment of
an order is an
important buying
criterion
Initiative: Train staff
to use new system.
Outcome:
Increased sales
Initiative: Create
financial incentives
for sales staff to
adopt new system
(commisions).
Decreased time
to process
order
Allows staff to
efficiently use
new system
Reduces time for
and resistance to
adoption
Reduced time to
order fulfillment
Initiative: Improve
distribution system
to reduce delivery
time by storing
products at multiple
locations near
customers.
Reduced time to
order fulfillment

Figure 6 Example of Benefit Realizations Approach
There are several key observations from this model. First, only one of the four initiatives
shown involves software development. An initiative can be considered the equivalent of
a project in standard project management terms. Achievement of the desired outcome of
increased sales requires a series of related projects that involve both training and changes
in business process. In project management terms, this collection of projects would be
considered a program. A key assumption is that the time to order fulfillment is an
important criterion for buyers when they are choosing whether to make a purchase. If
this is false, for instance, if potential customers are interested only in price, then the
benefits (value) desired from the program will not be achieved. Tracking, measurement


28
against both financial estimates and satisfaction of goals/requirements, and control,
making modifications in the overall plan based on these measurements, also play a key
role in achievement of value.
3.2.3 Model Based (System) Architecting and Software Engineering (MBASE)
3.2.3.1 Introduction
MBASE [14] [15] , Model Based (System) Architecting and Software Engineering, is
another technique that attempts to identify all conditions that are needed to achieve value.
A narrow focus on IT is again seen as too limited to achieve success. There is an attempt
to look along four dimensions to maximize value. An iterative process is used to ensure
that models representing each dimension are mutually consistent. The dimensions are as
follows [14]:
Product: The system being developed. Models in this dimension represent
requirements, code and architecture.
Process: The processes used to develop the system. Examples of process models
include waterfall development models, spiral models, iterative approaches.
Properties: These are models of the properties of the product or process. These
include project management models, such as cost estimates and schedules, and
models of the product that model performances or reliability.
Success: What each class of stakeholders needs to be satisfied. Success models
include the financial models presented in Chapter 4 and stakeholder satisfaction
models such as Win-Win or IKIWISI (Ill know it when I see it).
This can be visually represented as follows, from [14]:


29
Success Models
Win-Win; IKIWISI; Business-Case; Mission Models
Process Models
Life-Cycle
Waterfall
Evolutionary
Incremental
Win-Win Spiral
Anchor Points
Risk Management
Activities
CMM KPAs
Product Models
Domain
Artifacts
Requirements
Architecture
Code
Documentation
Packaging
Embedded
Shrink Wrapped
Turn Key
Product Line
Property Models
Cost/Schedule; Performance; Assurance;Usability
E
n
t
r
y
/
E
x
i
t

C
r
i
t
e
r
i
a
V
a
l
i
d
a
t
i
o
n

a
n
d

V
e
r
i
f
i
c
a
t
i
o
n

C
r
i
t
e
r
i
a
Product Development and Evolution Process
Milestone Content; Planning and Contol
Evaluation and Analysis

Figure 7 MBASE Model Integration Framework [14]
As can be seen in the above figure, models are formed in each dimension. These models
have interactions and there is a need for mutual consistency to achieve value. An iterative
spiral approach is used to achieve consistency between these models.
3.2.4 Win-Win Model / Theory W
3.2.4.1 Introduction
At the core of techniques to elicit and deliver stakeholder value are models to understand
stakeholder value and to reconcile the values of varied stakeholders. Theory W is a
theory that states that project success can be obtained by satisfying the value propositions
of all critical stakeholders. Any IT effort will have multiple stakeholders including end


30
users, customers, line of business management, IT management, project manager,
analysts, developers, maintainers of the future system among others. Each stakeholder
group will have their own goals which may conflict with other groups. Resolving these
conflicts can be a key to delivering value.
3.2.4.2 Theory W
Theory W is simply, make everyone a winner [16].
Or more formally from [17]
Making winners of the systems key stakeholders is a necessary and sufficient condition
for project success
3.2.4.3 Is Win-Win possible?
Many situations appear at a first pass to be zero-sum; that is, they appear to be a win-lose
situation where one parties will gain at the expense of another. A critical question is
whether these situations can be converted to win-win through negotiation and expectation
management. Theory W holds that unless everyone wins, success for a project is less
likely.
The key to creating Win-Win situations is negotiation. In the book, Getting to Yes [18],
five principles are established toward creating win-win situations. The reader is referred
to that text for more details.
Dont bargain over positions
A position is where someone stands on an argument. Arguing or bargaining over
positions can only result in one party losing.
Separate people from the problem


31
Negotiators are people. Their emotions and relationships can impact their
positions and negotiations over those positions. It is important to separate those
factors from the substantive problem at hand.
Focus on interests, not positions
It is critical to focus on the interests and needs of each stakeholder and not just
their current position.
Invent options for mutual gain
Expanding or inventing options can turn a win-lose situation into a win-win.
Insist on using objective criteria
The techniques described in Getting to Yes and from Theory W can enhance the
identification and creation of Win-Win conditions. Under certain conditions win-win is
possible. The examination of the conditions required is beyond the scope of this work,
but reconciling stake holder value propositions is a significant step in achieving value
from a project.
3.2.5 Goal Based Techniques
3.2.5.1 Introduction
A key part of obtaining value from a software endeavor is eliciting requirements. Fully
understanding and developing requirements is crucial to determining stakeholder value
propositions, that, simply, what they value. Goal modeling is a technique that can be
used to establish requirements. The establishment and definition of goals is recognized
as an important component in many aspects of requirements engineering. The creation of
a hierarchy of related goals at varied levels of abstraction can lead to better identification,
elicitation and elaboration of requirements. Analysis of goals by refinement, asking
how, and by abstraction, asking why, can lead to a more complete set of
requirements. Common GORE approaches include GBRAM [19] [20], i* [21] [22], the
NFR framework [23] and KAOS [24] [25]. Detailed study of these approaches is outside


32
the scope of this thesis, but the interested reader is directed to the references noted.
General GORE concepts are described below.
3.2.5.2 Goal-Oriented Requirements Engineering Concepts
Goals are fundamental to the requirements process. Yu noted [22]: Perhaps the
elucidation and manipulation of goals is a natural and inherent part of doing RE, even
though earlier RE methods have not made this explicit, and have not provided the
associated support. This interpretation is plausible since requirements by its very nature
represents a target to be reached, a wish to be fulfilled, a vision to be materialized.
Goal-oriented requirements engineering (GORE) is concerned with the use of goals for
eliciting, elaborating, structuring, specifying, analyzing, negotiating, documenting, and
modifying requirements [24]. Traditional requirements practices focus on what the
system is intended to do, that is, on its functionality. Users and other sources of
requirements typically express their needs as list of features. In contrast, GORE
techniques focus on why, leading to a more thorough understanding of the proposed
system within its environmental context and to a more complete, consistent set of
requirements, and on how, which allows generation and comparison of alternative
implementations. A better understanding of the project can lead to better achievement of
value.
The relationship between goals and requirements is analogous to the relationship between
design and code. Requirements implement the goals. Alternate sets of requirements can
be evaluated to determine how well they satisfy an identified hierarchy of goals.


33
Gore techniques can play a role across many aspects of requirements engineering,
but they are particularly relevant early in the process. Goals are fundamentally at a high
level and fully understanding stakeholder intent and motivations first can lead to
successful requirements development. Two fundamental approaches to GORE are:
Begin with an initial set of user goals at a high level and derive sub goals.
Successive and iterative refinement of sub goals leads to requirements.
Begin with a system description, scenarios or functional specification. From
these, determine an initial set of goals. Successive and iterative refinement of
these goals leads to a more complete set of requirements.

The concept of a goal is fundamental. A goal is an objective or intended purpose for a
system. Goals exist at varied levels of abstraction. At the highest level they may express
the overall strategy of the organization, for instance, "offer accounting services to
clients". At the lowest level they may be satisfied by the actions of a single agent and
map directly into a requirement or assumption. Goals can be concerned with either
functional or non-functional aspects of a system. Functional goals represent the
individual operations or services that the system supports. Non-functional goals are
system qualities. Goal oriented techniques provide a means for the qualitative and
quantitative systematic evaluation of both functional and non-functional goals.
Requirements can be linked back to non-functional goals and the satisfaction of these
goals by the proposed set of requirements can be evaluated.
Many non-functional goals are soft goals. A soft goal is one that can be satisfied to
varied extent. For instance, usability is a soft goal. The final system usability will be
supported to different extents by different sets of requirements, designs and
implementations.


34
Goals are interrelated or linked. Goal hierarchies can be established linking each goal
with its sub goals. Satisfaction of each goal can require that all sub goals are satisfied,
called AND-refinement, or satisfaction of any sub goal can result in satisfaction of the
parent goal, called OR-refinement. Soft goals linked to sub goals lead to the notion of a
goal being satisficed by its sub goals. Sub goals either add or detract from the
completion of a parent goal.
Development of a goal hierarchy is done by iteratively asking why and how. Refinement
of goals can be achieved by asking how to break each goal into sub goals. Abstraction
of higher level goals can be achieved by asking why, that is, why is a lower level goal
needed.
Goal based approaches examine the composite system, that is, the software system within
its larger environment. Explicit consideration of actors is also done. Within such
frameworks why, who, and when questions can be addressed in addition to the usual what
questions. It then becomes possible to reason formally about goal satisfaction [25].
Goal based approaches are seen as a means to determine the requirements necessary as a
prerequisite to deliver value.
3.3 Critical Success Factors
Critical success factors, CSFs, are sets of conditions associated with a higher probability
of project success. For instance, the technical background of the project team is a CSF.
A project with skilled, experienced, well trained team is more likely to be successful than
one with a less experience team. There are many studies of critical success factors in the
literature, this thesis presents a synthesis of three [26] [27] [28].


35
Belassi [26] suggests that critical success factors can be classified into four groups
Factors related to the project
Factors related to the project manager and to the project team
Factors related to the organization
Factors related to the external environment.
The specific factors sited in [26] [27] [28], plus others hypothesized by this author, can
be mapped into these categories. The set of factors chosen in this work is by no means
optimal or empirically demonstrated, but can serve to show a proposed technique to
evaluate specific projects with respect to critical success factors.
The focus of this section is on how critical success factors can be evaluated to
establish necessary prerequisite conditions before a project should be started and
also to demonstrate how CSFs could be used as a discriminator for project
selection. The proposed evaluation technique is independent of the exact set of
CSFs.
CFSs may vary based on project type, industry and possible other factors.
Determining an optimal set of CSFs would require empirical studies beyond the
scope of this work.
A simple spreadsheet can be used to evaluate projects against CSFs as shown below.

Table 6 Evaluation of Critical Success Factors for an Example Project
Category CSF Low (L)
Medium
(M) High (H)
Ranking of Example
Project
Project
Technical
Complexity
New
technolog
y
Hard, well
know
technology
Easy, Well
known
technology M
Project
Complexity of
Requirements
Complex,
uncertain
, subject
to change
Complex,
but stable
Simple,
easy to
understand M
Project
Manager
Technical
Skills Weak Good Excellent M
Project
Manager
Communicati
on Skills Weak Good Excellent M
Project
Manager
Management
Skills Weak Good Excellent M


36
Project
Team Techical Skills Weak Good Excellent L
Project
Team
Experience
With Similar
Projects
No
experienc
e
Some team
members
have
relevant
experience
Most team
members
have
relevant
experience L
Organizatio
n
Top
management
support Weak
Some
support
Clearly
identified
champion M
Organizatio
n
Maturity of
Software
Process
Ad hoc -
no
processes
Repeatable
processes
Optimized
processes M
Organizatio
n
Users actively
involved in
requirements Weak
Limited
user
participatio
n
Extensive
user
participatio
n M
Organizatio
n
Users actively
involved in
testing Weak
Limited
user
participatio
n
Extensive
user
participatio
n M
External
Environme
nt
Understandin
g of Market Poor Somewhat Excellent H
External
Environme
nt
Understandin
g of
Competition Poor Somewhat Excellent M
SCORE 1.92


Here the score has been calculated as (3 * number of H rankings + 2 * number of M
rankings + number of low rankings) / number of CSFs. It is not proposed that this
particular ranking is optimal or suggested, but that organizations can identify factors that
are correlated with their successful projects and that new projects can be ranked against
these factors for the following purposes.
As a stage gate to determine whether to consider the project at all. Some
minimum score would be required to proceed.
As a means to judge the relative possibility of success of different projects. This
would serve as one of several project selection criterions.


37
3.4 Cost Estimation
Quantitative valuation techniques are dependent on good project cost estimation. For
purposes of this thesis, it is assumed that accurate cost estimates are available. The topic
of cost estimation is outside the scope of this thesis, but it is a well researched topic and
information is readily available within software engineering literature.
3.5 Sales and Marketing Forecasts
Quantitative valuation techniques can be dependent on estimates of future revenue via
sales and marketing forecasts. For purposes of this thesis, it is assumed that these
forecasts are available and accurate. Since this topic is outside the scope of traditional
software engineering and of this thesis, it will not be discussed.
3.6 Discussion
Having good requirements is a key step in obtaining value. Without a clear definition of
what needs to be done, both in software and in associated business and process changes,
there is little hope of delivering value to stakeholders. Several techniques, the Benefits
Realization Approach, MBASE and goal-based requirements engineering were surveyed
at a high level as examples of techniques to obtain good requirements.
Project critical success factors were seen as useful in both predicting chances of project
success and as a discriminator for project selection.


38
Chapter 4

Quantitative Approaches to the Measurement of Value
4.1 Overview
Quantitative approaches to the measurement of value from projects are presented. These
measures attempt to assess the financial value of the project as measured by the
difference between costs and revenues. The costs of a project are dependent on good cost
estimation techniques. While not directly discussed within this thesis, cost estimation is
crucial in estimating value and in project ranking and selection. The expected revenue
from a project can be estimated by marketing and sales forecasts for projects producing
products for sale in the marketplace or can be estimated as savings from business process
improvements for internal projects.
Financial measurement techniques can be divided by whether they take a static or
dynamic view of the project. Net present value, internal rate of return and payback
period approaches are seen to take a static view of the project. A financial value is
calculated under the assumption that the project will proceed exactly as planned
regardless of how reality unfolds. Real options approaches take a more dynamic view by
attempting to value managerial flexibility. Game theory approaches also take a more
dynamic view and allow modeling and quantification of the effects of competition and
cooperation in the marketplace.
Internal projects are defined for purposes of this work as those that do not produce a
product for sale, but are instead producing a software product for internal use in the


39
organization to improve business processes. Techniques to quantify and assign
monetary value to internal business process improvements are presented.
4.2 Net Present Value (NPV) / Discounted Cash Flow
4.2.1 Present and Future Values
An underlying principle in the financial measure of investments, including investments in
software projects, is that the value of a given quantity of money today is worth more than
the same amount at a date in the future. This first basic principal, the time value of
money, can be stated succinctly as:
A dollar today is worth more than a dollar tomorrow [29]
It is intuitive that given a choice between receiving a dollar today and a dollar at a later
time, even tomorrow, that today is preferable. There are two factors that explain this
preference:
1. Money received today is immediately available for other investments.
2. Future events have uncertainties.

Suppose that a choice exists between receiving $100 today and a greater amount one year
from now. How much additional money would be required to make the later payment
preferable? A simple way to determine this is to look at possible investments at a similar
risk. Assume that in this example, the future payment is guaranteed; investments with
zero risk should be considered. Suppose that a U.S. government bond offers a 5%
interest rate. Presumably, even considering recent market turmoil and tremendous
government deficits, U.S. government bonds have no risk of default. Suppose that $100
is invested today at a 5% interest rate.


40

100 * (1 + interest rate) = 100 * (1 + r) = 100 * (1 + 0.05) = 105, where r is the rate of
return.
Equation 1 Future Value Of $100, One Period At 5%
The above equation states that given a 5% interest rate, the future value of $100 today is
$105.

PV * (1 + r) = FV, where FV is the future value and PV is the present value.
Equation 2 Future Value After One Period
From another perspective, suppose that a payment is offered at a later date. What is the
value of that payment today? Equation 2 can be manipulated to solve for the present
value in terms of the future value.

PV = = FV * ( )
Equation 3 Present Value After One Period

The term, ( ), is known as the discount factor, with r being described as the discount
rate.
As a concrete example, suppose a payment of 110.0 is offered in one year. What is the
present value of this payment? Assume that alternative, equivalent risk investments are
available at a 5% rate of return.
PV =
Equation 4 Present Value of $110


41
Assuming a 5% rate of return, or equivalently, a 5% discount rate, the present value of
$110 one year from now, is $104.76. This means that $104.76 received today is of equal
value to $110 received in one year.
Equation 2 and Equation 3 can be used to calculate future value and present value over
one time period, in the examples, over a period of one year. The future value over
multiple periods can be determined as follows.

Period 1:
Period 2:
..
Period N:



Equation 5 Future Value After N Periods

Solving for PV yields


Equation 6 Present Value Of An Amount To Be Received in N Periods

As can be seen from above, money has a time value. The value of a quantity of money
spent or received today is different from the value of the same quantity of money at a
future date. To evaluate any investment, all payments and outlays are converted into
dollars valued at the same point in time, usually the present. This is referred to as
calculating the net present value. Present value indicates that all money is converted
into its worth today. Net indicates that all payments and outlays are summed. Efforts


42
with positive NPVs are worthy of consideration. This is best understood via a simple
example. Suppose that a project to develop a new commercial software product, perhaps
a word processor, is being considered. Suppose that the costs include payment of
$100,000 to a team of requirements engineers today and payment of $300,000 to a team
of developers six months from now. Further suppose that the final product will be
completed in one year and that it can be sold to another company or on the market for
$420000 at that time. Should this project be conducted? The answer to this can be
determined by calculating NPV
1
.
Assume US government bonds are available at an interest rate of 6% per year or
0.06/12 = 0.005% per month. Individual cash flows (both revenue and outlays)
can be designated by C
i
.
C
0
= -100000 (today, cost of requirement engineers)
C
1
= -300000 (six months from now, cost of development team)
C
2
= 420000 (one year from now, sale of product)
r = 0.06/year = 0.005/month


NPV = -100000 + (-300000)/(1 + 0.005)
6
+ 420000/(1 + 0.005)
12
= -100000 291155 + 395600 = 4445
Equation 7 NPV of Word Processor Project Example Assuming 5% Discount Rate
The general rule is a project is worth consideration when NPV is positive
2
. The NPV of
this project is positive. This indicates that given our assumptions, the organization will

1
The question is actually answered partially by the NPV calculation. As seen elsewhere in this thesis,
value assessment is multidimensional. NPV calculations serve as a measure of worth in the financial
dimension.
2
Value is multidimensional and NPV, or financial value, is only one dimension. Some classes of projects,
mandatory, for instance, those forced by legal or regulatory requirements, may need to be done regardless


43
gain wealth as the result of this project. The next question is whether the project should
proceed based on this calculation. There are several implicit assumptions in this NPV
calculation. How certain are the expenses ($100000, $300000 (in six months)) and the
future revenue ($420000 (in one year))? Assume the discount rate (0.06) used was the
interest rate available from zero risk government bonds. Is this the correct discount rate
to use in this calculation? Using a risk free discount rate is appropriate for calculating the
NPV of risk free investments. Unless the project is risk free, which is highly unlikely for
any project, the calculation is not valid due to use of an incorrect discount rate. This
project generates a future value of $420000 in one year given investments of $100000
today and $300000 in six months. Again, assume that a 6% return is available from safe
government bonds. All projects have risk. Any rational investor would require a return
higher than $420000 to undertake this effort. The same return could be return risk free
from government bonds. This principal can be expressed as:
A safe dollar is worth more than a risky one [30]

4.2.2 Discount Rates
As can be seen in the proceeding section, NPV calculations are dependent on the choice
of discount rate, which begs the question of how to choose the correct discount rate.
Ideally, the discount rate should reflect the rate of return of similar investments. Suppose
that further analysis shows that the risk involved in undertaking the word processor

of NPV. Another example is an upgrade to an operation system or DBMS. These may need to be done to
maintain support. A negative NPV calculation would not be an indication to remain on an unsupported
operating system.


44
project in section 4.2.1 is equivalent to the risk of investing in a particular stock and
that the expected return of that stock is 12%. In this case, the opportunity cost of
investing in the software project is that of not investing in the stock market. The
opportunity cost of capital is said to be 12%. Recalculating the NPV of the word
processor project yields:
C0 = -100000.0 (today)
C1 = -300000.0 (six months from now)
C2 = 420000.0 (one year from now)
r = 0.12/year = 0.01/month

NPV = -100000 + (-300000)/(1 + 0.1)
6
+ 420000/(1 + 0.1)
12
= -100000 282613 + 372728 = -9885
Equation 8 NPV of Word Processor Project Example Assuming 12% Discount Rate
It is seen that given the new assumption about the risk of the project being equivalent to
an investment in a particular stock, the NVP is the project is negative. This indicates that
money is lost by conducting the project, relative to other equivalent risk investments such
as simply buying the particular stock as noted.
Two immediate criticisms of NPV methods are the need to determine an appropriate
discount rate and the need to have accurate estimates of costs and of revenues. By
maintaining a historical database of estimates from previous projects and comparing
project actuals against these estimates, the later concern, that of producing accurate
estimates can be addressed. Even after an organization gains expertise on estimation, the
problem of determining the correct discount rate remains. This can be handled by
performing sensitivity analysis of NPV on a range of discount rates. To see how this can
be done, consider this second example.


45
A new accounting system is proposed to replace a legacy system. Project costs are
estimated at $250000. The system will have a life span of 5 years and will save $70000
per year in operating cost compared to the legacy system. For simplicity, assume that
the development costs are spent completely at project initiation and that the savings are
realized as a bulk amount at the start of each year of operation. Should this project
commence based on its NPV? The critical question is what discount rate to use. To
determine the correct discount rate it would be necessary to identify investments with
similar risk and to quantify their return. Practically, it is difficult to impossible to do this.
As an alternate approach, consider a sensitivity study to evaluate the range of discount
rates for which the project generates wealth. A spreadsheet can be used to conduct this
study.
Table 7 Example of NPV Sensitivity Analysis
Discount
Rate
Development
Cost
Year 1
Savings
Year 2
Savings
Year 3
Savings
Year 4
Savings
Year 5
Savings NPV

-250000 70000 70000 70000 70000 70000
0.01 -250000 69307 68621 67941 67269 66603 89740
0.02 -250000 68627 67282 65963 64669 63401 79942
0.03 -250000 67961 65982 64060 62194 60383 70580
0.04 -250000 67308 64719 62230 59836 57535 61628
0.05 -250000 66667 63492 60469 57589 54847 53063
0.06 -250000 66038 62300 58773 55447 52308 44865
0.07 -250000 65421 61141 57141 53403 49909 37014
0.08 -250000 64815 60014 55568 51452 47641 29490
0.09 -250000 64220 58918 54053 49590 45495 22276


46
0.1 -250000 63636 57851 52592 47811 43464 15355
0.11 -250000 63063 56814 51183 46111 41542 8713
0.12 -250000 62500 55804 49825 44486 39720 2334
0.13 -250000 61947 54820 48514 42932 37993 -3794
0.14 -250000 61404 53863 47248 41446 36356 -9684
0.15 -250000 60870 52930 46026 40023 34802 -15349
0.16 -250000 60345 52021 44846 38660 33328 -20799
0.17 -250000 59829 51136 43706 37356 31928 -26046
0.18 -250000 59322 50273 42604 36105 30598 -31098
0.19 -250000 58824 49432 41539 34907 29333 -35966
0.2 -250000 58333 48611 40509 33758 28131 -40657

The results of this sensitivity analysis can be summarized in graph.

Figure 8 Plot of NPV vs. Discount Rate
-60000
-40000
-20000
0
20000
40000
60000
80000
100000
0 0.05 0.1 0.15 0.2 0.25
NPV
Discount Rate
NPV


47
It can be seen that for discount rates below approximately 12.5, the project has
a positive NPV and is worth consideration. That is, if the return on investments with
equivalent risk is less than or equal to 12.5%, the project is a good investment. If the
return on equivalent risk investments is greater than 12.5%, the project is a bad
investment.
Now suppose that a source of capital is available at 5% interest. For example, suppose a
bank is willing to lend funds for this project at a 5% interest rate. Given that the project
has a positive NPV at the discount rate of 5%, should it be done? Not necessarily. The
discount rate that should be used is that of investments of equivalent risk. The rate of the
loan is not the discount rate. The key decision is based on the rate of return available
from alternative investments of equivalent risk. Lets assume that investments of
equivalent risk are available that offer 20% return. At a discount rate of 20%, the NPV of
the project is negative and the project should not be done. Another way of stating this is
that we could take the 5% loan and invest the money in other ways that have a greater
return for the same risk.
Before evaluating other financial measures of projects, it is useful to summarize the
characteristics of the NPV rule, which is to accept projects with a positive NPV.
NPV is based on the fact that a dollar today is worth more than a dollar tomorrow.
Any financial valuation technique that does not account for the time value of
money is flawed. [31]
NPV depends solely on forecasted cash flows and the opportunity cost of capital.
Any financial valuation technique that depends on managerial tastes, the
companies choice of accounting method, the profitability of the companys
existing business or the profitability of other independent projects will lead to
inferior decisions. [31]


48
NPV is additive. Combining a project with negative NPV with a project with
positive NPV will result in a lower NPV for the combined project than that of the
project with a positive NPV. [31]
Other common measures of a projects financial worth include the return on the internal
rate of return (IRR) and the payback period.
4.2.3 Payback Period
The payback period is the number of periods until the estimated cash flows equal the
initial investment. NPV calculations express present and future cash flows as equivalent
current dollars. Payback period expresses this in terms of time. Intuitively, this can be
stated as the investment will pay for itself in X number of years. [32] While useful as a
secondary measure of project value, it has several defects that are apparent with a simple
example.
Table 8 Payback Period Example
Project
Initial
Outlay
Cash Flow
Year 1
Cash Flow
Year 2
Cash Flow
Year 3
Payback
Period
(Years)
NPV
assuming
10%
opportunity
cost
A -100 10 10 500 3 293
B -100 60 60 0 2 4
C -100 10 110 0 2 0

As a measure of value, payback period is seen to be deficient. Project A clearly brings
significantly more value to the organization than projects B or C, but has a longer
payback period. Project selection techniques based solely on payback period will


49
overlook valuable projects with longer payback periods. For instance, a requirement
that all projects payback their investments within two years would reject project A.
Additionally, simple techniques based on payback period fail to acknowledge the time
value of money. Projects B and C both have 2 year payback periods, but only project B
should be considered on the basis of NPV.
Myers [33] suggests that the use of payback period in valuing projects may stem from a
distrust of forecasted future distant cash flows. If distant forecasts are not trustworthy
then a quick payback is more valuable.
4.2.4 Internal Rate of Return (IRR) / Return on Investment (ROI)
NPV expresses an investment in terms of equivalent dollars. Payback period evaluates an
investment with respect to time. The internal rate of return, IRR, (or equivalently, the
return on investment, ROI) evaluates an investment in terms of an interest rate. [34]
The internal rate of return, alternately referred to as ROI, for a simple investment
consisting of a single investment and a single payoff in one period can be expressed
simply as:

Equation 9 Rate of Return
The internal rate of return is also the discount rate that makes NPV equal to zero. [35]
This can be seen as follows. Here, C
0
is the initial investment and C
1
is the revenue
(payoff) at the end of the period.


50

Equation 10 Single Period NPV Set to Zero
Solving for the discount rate or rate of return

Equation 11 Discount Rate
Comparing Equation 9 and Equation 11, it is seen that the IRR (or equivalently ROI) is
the discount rate at which NPV is zero.
For a project containing multiple investments, multiple cash flows and multiple periods
solving for the internal rate of return is less straight forward. Consider the second
example presented in 4.2.2. The NPV is given by:

Equation 12 Calculation of NPV for Example from Section 6.1.2
By setting this equal to zero, the IRR, being the rate at which NPV equals 0, can be
found. Solution of this equation is non-trivial. The IRR is best obtained by trial and
error. As can be seen in Table 7, the IRR is approximately 12.5%.
Projects that have an IRR greater than the opportunity cost of capital (the return on
investments of similar risk) have a positive NPV. Projects that have an IRR less than the
opportunity cost of capital have a negative NPV. This can be seen in Figure 8. When the
discount rate (opportunity cost of capital) is less than the IRR, NPV is seen to be positive.


51
This result can also be obtained by reviewing Equation 12. It is a strictly
monotonically decreasing function of r. The discount rate, r, equals the internal rate of
return, IRR, when NPV equals 0. Clearly, NPV will be positive when r is less than IRR
and negative when r is greater than IRR.
There are situations where IRR and NPV techniques give contradictory results. This is
particularly true for the case of mutually exclusive projects. An example of mutually
exclusive projects is when there are two possible approaches to a project with different
costs and different payoffs. An example of this is presented in Myers [36]. Suppose two
projects are proposed to build a particular software product. Perhaps they represent two
different architectural solutions.
Table 9 Comparison of NPV and IRR on Mutually Exclusive Projects (from [36])
Cash Flows
Project Investment (C
0
) Payoff (C
1
) IRR (%) NPV at 10%
A -10000 +20000 100 +8182
B -20000 +35000 75 +11818

Which approach is preferred from a financial standpoint? Project A has a higher IRR.
Project B has a higher NPV. Assuming no shortage of available capital, that is, assuming
that the 20000 investment for project B can be secured, performing project B rather than
A will make the organization 11818 8182 = 3636 dollars richer. Clearly approach B is


52
preferred. This suggests that using IRR as a means of evaluating the value of projects
may result in less profit for the firm than the use of NPV techniques.
The following example from [36] again illustrates a difference in the projects selected by
maximizing IRR and by maximizing NPV.
Table 10 Comparison of IRR and NPV for Three Projects
Cash Flows
Project C
0
C
1
C
2
C
3
C
4
C
5
IRR
(%)
NPV at
10%
F -9000 +6000 +5000 +4000 0 0 33 3592
G -9000 +1800 +1800 +1800 +1800 +1800 20 9000
H -6000 +1200 +1200 +1200 +1200 20 6000

Myers reports that when shown this example, many managers prefer project F to project
G despite the higher NPV associated with project G. He suggests the reason for this is an
implicit assumption about a shortage of capital. If project F is chosen, there is a
possibility of using its cash flow, C
1,
to fund project H. Is this a reasonable approach?
No, unless capital is limited. As shown above, the best way to maximize value for the
firm is to maximize NPV. A better solution would be to view this as an optimization
problem to be solved by linear programming techniques.


53
Another significant criticism of IRR techniques is that when used alone, they tend to
direct investments toward projects with lower strategic value. [37]. Lower level
managers attempting to maximize IRR may suggest projects or modify project
requirements to reduce initial investments and get quick paybacks (which will increase
IRR = payoff/investment 1). These short lived projects may not be the type of
investments that allow the firm to grow.
4.2.5 Comparison of NPV, IRR and Payback Period
NPV, IRR and payback period offer three different perspectives into the financial value
of projects. The following table summaries some significant points and conclusions
discussed in the preceding sections.
Table 11 Comparison of NPV, IRR and Payback Period
Technique Emphasis Investment Rule Criticism
Net Present Value Expresses all cash
flows in terms of
equivalent dollars
Invest in projects
with a NPV greater
than 0.0. Select
projects with greatest
NPV.
Lacks a time
dimension.
Revenues far in
the future are
more difficult to
predict and are
more uncertain.
No consideration
of capital being
tied up by project
preventing other
investments.
Internal Rate of
Return
Expresses all cash
flows in terms of an
interest rate
Invest in projects
with IRR greater than
some threshold.
Select projects with
highest IRR.
Essentially a
ratio. Is a project
with a high IRR
and a low NPV
preferable to one
with a lower IRR
and a higher
NPV? May


54
emphasize short
lived, non-
strategic projects.
Payback Period Expresses all cash
flows in terms of
time
Invest in projects that
have a payback
period shorter than
some threshold.
Select projects with
the shortest payback
period.
Does not
consider dollars
or cash flows,
only time. Is a
project that pays
for itself quickly
necessarily
preferred over
one with much
greater but more
distant payback?

Since each technique has strengths and weaknesses, projects should be evaluated with
respect to all three to obtain a better understanding of potential value.
4.2.6 Capital Asset Pricing Model (CAPM)
A critical question in the NPV technique is how to choose the correct discount rate. The
capital asset pricing model provides a means to calculate the relevant discount rate. The
Capital Asset Pricing Model is well covered in [38]. The following follows that text and
presents significant findings.
Generally, investors and firms wish to avoid risk. One way to avoid risk is through
diversification. As the overall market changes value, individual securities change price
with or against the market with varied ways. For a portfolio consisting of multiple
stocks, as the market changes, movements in the individual stocks tend to cancel out each
other. Suppose that a portfolio consists of two assets, r
1
and r
2
, weighted in proportions
x
1
and x
2,
then
Var(x
1
r
1
+ x
2
r
2
) = x
1
2
var(r
1
) + x
2
2
var(r
2
) + 2x
1
x
2
covar(r
1
r
2
)


55
Equation 13 Variance of Portfolio of Two Assets [39]
The variance of the portfolio is less than the average variance of the individual assets
provided that the correlation between the two assets is less than one. Extending this, the
variance of a portfolio consisting of many assets can be lower than the average variance
of its individual assets depending upon the correlation between the assets. For an
investor looking at a particular security, the relevant risk of a particular security is not the
risk of the security itself, but rather the how the security increases the risk of their
portfolio. The rate of return required by the investor is related to this risk, that is, the
investor will require to be compensated only for that portion of the assets risk that is not
removed by diversification within the portfolio.
Following on this line of reasoning, one might expect that the relevant risk for an
individual project is the contribution of that project to the firms risk, that is, to the risk of
firms portfolio of projects. There are two problems with this.
If this were the case, NPVs would not be additive. A new project would change
the risk of the portfolio of projects and change the NPV of all projects due to the
change in the portfolio risk and the related discount rate. Each projects discount
rate would be dependent on its contribution to the portfolio risk. If the risk of the
portfolio changes, the discount rate for each project and its NPV would change.
The NPV of the portfolio would no longer be the existing NPV of the portfolio
plus that of the new project [40]. To evaluate a new project, it would be
necessary to recalculate the NPV of all existing projects, which would be an
unpleasant prospect.
Investors are not willing to pay for a firm to diversify within their portfolio of
projects. They can achieve their desired levels of diversification more efficiently
by purchasing the securities of multiple companies. The value of a project to
investors (the owners of the firm) is independent of its risk relative to other
projects the firm is undertaking, that is, to how its risk is correlated to other
projects. The risk premium demanded by investors for a particular project is
related to the projects correlation with overall market risk. Investors require


56
compensation for the part of a projects risk that cannot be eliminated by
diversification by purchasing the securities of other firms.
For a particular stock, since firm specific risk can be eliminated by diversification, the
risk premium demanded by investors is related only to how a firms stock price varies
with the overall market. [41]. This finding forms the basis for the Capital Asset Pricing
Model. From [41]:
Expected risk premium on a stock = beta x expected risk premium of the market

Equation 14 Capital Asset Pricing Model (Risk Premium)
Where is the stocks sensitivity to changes in the market, r is the rate of return required
by investors for the security, r
m
is the rate of return for the overall market and r
f
is the risk
free rate of return (for instance, from treasury bills).

Equation 15 Calculation of Beta
All of this leads to a somewhat practical means of determining the proper discount rates
for NPV analysis of projects.
Choose a security of a company that performs many projects similar to the project
under consideration.
Determine the stocks
This can be determined by looking at on-line financial information sites such as
Yahoo or Google finance.
Calculate the rate of return required from the CAPM.
The complexity of doing this correctly points to the need for participation of both
technology and finance departments in assessment of project value.


57
4.2.7 Sensitivity and Scenario Analysis
Discounted cash flow (DCF) or NPV analysis is critically dependent upon estimates for
costs and for future cash flows. Obviously, these estimates are error prone. One way to
understand and quantify the possible errors in costs and cash flow estimates and
ultimately in NPV analysis is via sensitivity analysis. The estimates are functions of sets
of independent variables. For instance, cost might be a function of lines of code. Base
estimates for each independent variable can be made. From these, base-case cost or cash
flow estimates can be produced. Then, one variable at a time can be changed from its
base value to pessimistic and optimistic values. Cost and cash flows are recalculated as is
NPV. From this analysis, it is possible to determine key variables that impact NPV and
to further study them to reduce possible errors.
One criticism of sensitivity analysis is that only one variable is modified at a time.
Another type of analysis, scenario analysis, attempts to correct this by modifying several
variables at a time. For instance, in a software project, choosing a particular
programming language may impact lines of code, programmer productivity and defect
rates. Modifying each independently, as down with sensitivity analysis, may not reflect
reality.
Monte Carlo simulations can also be used to study dependencies on several variables at
once.


58
4.3 Real Options
4.3.1 Introduction
The valuation techniques discussed in Section 4.1 have a common theme. There is an
implicit assumption that project is always carried out as initially planned and that
management does not actively modify the project once it is in progress. Cost estimates
and cash flows forecasts were prepared and were discounted using a discount rate
appropriate for the project risk and NPV, IRR and payback period were calculated. As a
project proceeds valuable information is learned. There are opportunities to exploit good
fortune and success and opportunities to change direction or even stop the project in the
case of bad fortune and failures. Additional knowledge as the project proceeds leads to
additional choices and additional opportunities to create wealth or to avoid loss.
Opportunities to modify projects as the future unfolds are known as real options [42].
Additional information gathered as the project unfolds and the ability to modify the
course of the project have real value. Intuitively, all things being equal, a project that is
easy to modify based on better knowledge has more value than a project that is harder to
modify once in progress.
There are several types of real options or opportunities to modify projects as they
progress. The first is the option to expand. An example of this is a pilot project or initial
version of a product with a minimal feature set. Suppose that a new web based store is
proposed that will allow users to order coffee that will be delivered to them. This new
business might be piloted in a limited market and then expanded nationally based on the
observed success.


59
Create initial pilot in limited
market
Observe Results in
Test Market
Cancel Effort
Expand Nationally

Figure 9 Decision Tree for Option to Expand

The high values of certain of certain internet companies such as Amazon and EBay are
related to the option to expand. The high stock prices of these firms are related to the
perception that they have options to expand infrastructure and technology into new
markets. Based solely on a discounted cash flow analysis (NPV) of their current
business, their stock prices would be significantly lower.
A second type of real option is the option to abandon. Although not the case in the
software industry where old software and computers have little or no value, in other
industries after the choice is made to discontinue production there is often significant
salvage value to equipment and facilities. Depending on choices made during a project,
the salvage value may vary. For instance, one means of production may utilize
machinery with significant salvage value while another may utilize machinery with less
salvage value.


60
The following example is modified from [43]. Assume that a brokerage firm has a
choice between developing a specialized object oriented database or using a standard
vendor provided relational database, such as Oracle, to support a trading system for a
completely new market. The object oriented database is highly specialized, has lower
operational costs and no salvage value. The relational database is more standard, has
higher operational costs and some salvage value. Suppose that 10 million in licensing
costs could be saved by using the relational database on another project if the new trading
system fails. Suppose that the project development costs are equal for both technology
options. Further suppose that the expected payoffs (incoming revenue discounted to the
current time) from each technology are based on the demand for this product and are as
follows:
Payout (Millions)
O.O. Database Oracle
High Demand 20.5 18.0
Sluggish Demand 8.5 8.0

The payout represents the NPV of all future cash flows at the time the system is put into
use. Clearly, if we were certain that demand would be high, the custom O.O. database is
preferred. But suppose that demand is sluggish. With the custom database, the best
choice is to keep using the trading system to receive a payout of 8.5 million. The
specialized object oriented database cannot be reused. With the standard Oracle
database, we could continue to use the system and receive 8.0 million in payout, but a
better choice would be to shut it and reuse the database for another purpose saving 10
million. The option to abandon increases the value of the project when a standard
reusable technology is chosen.


61
A third type of real option is referred to as a timing option. Suppose that a project is
calculated to have a positive NPV, but there are uncertainties. For instance, these
uncertainties could be about the overall economy or about projections on future demand.
In this case, there may be value in delaying. The overall economy could improve or
additional details about future demand might become available. Erdogmus [44] described
a phased migration option as a type of timing option. A basic system can be deployed
and enhanced in a phased manor. Each enhancement is done only as demanded by
market conditions. Real options can quantify this approach.
The fourth type of real option is referred to as a production option. Part of the value of
modularity in software is due to this. Suppose a new software system is being developed
and there is a choice between making the system modular and expandable at higher cost
or less modular and more restrictive at lower cost. A simple NPV style analysis might
indicate that the less modular approach is preferred. Real options techniques provide a
way to quantify the value in a flexible, modular design. Having the ability to combine,
and selectively replace or improve software modules increases the value of a system [45].
4.3.2 Decision Trees
Decision trees can be used to calculate the value of a project when options exist and can
also be used to quantify the value of an option. The following example is taken from [46]
with modifications.
A company is considering entering a new web-based business. It can initially build a rich
full featured system or a limited system with minimum functionality. The cost of the full
system is 550K, but it will attract more customers. The cost of the minimal system is


62
250K and is less appealing to customers. The minimal system can be expanded after
one year of use for 150K. Due to shortcuts made during its initial construction, even with
an upgrade the minimal system will not be as appealing to customers as the full system.
There is uncertainty in the level of demand and thus in future cash flows. Assume that
there is a 60% chance of high demand in year one and a 40% chance of low demand.
This was determined by marketing and sales groups within the company and will be
assumed accurate. Assume that given high demand in year one, there is an 80% chance
of high demand and a 20% chance of low demand in year two. Assume that given low
demand in year one, there is a 40% chance of high demand and a 60% chance of low
demand in year two. Assume a discount rate of 10% is appropriate. Assume that the
future cash flows shown have been produced from accurate marketing and sales
forecasts. This is depicted below in Figure 10.






63
F
u
ll
S
y
s
t
e
m
-
5
5
0
P
a
r
t
ia
l
S
y
s
t
e
m
-
2
5
0
H
ig
h
D
e
m
a
n
d
(0
.6
)
1
5
0
Low Demand (0.4)
30
High Dem
and (0.6)
100
E
x
p
a
n
s
io
n
-1
5
0
N
o
a
d
d
itio
n
a
l
in
v
e
s
tm
e
n
t
L
o
w
D
e
m
a
n
d
(0
.4
)
5
0
High Demand (0.8)
960
Low Demand (0.2)
220
High Demand (0.4)
930
High Demand (0.8)
800
High Demand (0.8)
410
High Demand (0.4)
220
Low Demand (0.6)
140
Low Demand (0.2)
100
Low Demand (0.2)
180
Low Demand (0.6)
100
YEAR 1
YEAR 2

Figure 10 Decision Tree Example
As can be seen from the figure, if the full system is constructed, there is a 60% chance of
high demand in year 1 with a cash flow of 150K and a 40% change of low demand with a
cash flow of 30K. Given high demand in year 1, there is a 80% chance of high demand
in year 2 with a cash flow of 960K and a 20% chance of low demand with a cash flow of
220K.
Using discounted cash flows and expected values, it is possible to calculate a NPV for
each system choice.


64
Full System:


Equation 16 NPV Calculation at Start of Project for Full System

Partial System:
First, look at the decision on whether to expand. Assuming high demand, at the end of
year 1, an option exists. The firm can enhance the system or remain with the partial
system.

Equation 17 NPV Calculation at Year 1 Assuming System Upgrade


Equation 18 NPV Calculation at Year 1 Assuming No Upgrade

Clearly, if demand is high, the option to expand is preferred.


65
Calculating the NPV for the partial system choice from the start of the project yields:

Equation 19 NPV Calculation at Start of Project for Partial System
Since the NPV for the partial system with an option to expand is higher than the NPV for
the full system (117K > 96K), it is preferred.
Now, the remaining question is what the value of the option to expand is. Suppose there
was no option to expand the system. In that case:


Equation 20 NPV Calculation at Start of Project for Partial System with No Option to Expand
The value of the option to expand is 117 52 = 65K.
From this example, some immediate shortfalls are apparent. Complexity grows quickly
with the number of choices. Decision trees with more than a few choices quickly become
unworkable. There is also a need to estimate both cash flows and probabilities. The


66
probabilities of high or low demand are at best rough estimates, at worst, guesses.
Real options techniques offer solutions for all of these short falls of decision trees.
4.3.3 Review of Financial Options
Options are complicated. A review of financial options and their valuation is presented
as a means of better understanding options. Real options are simply similar techniques
applied to real assets and to projects. For the following sections, Google common stock,
GOOG, is used as an example.
The closing stock price on Nov 11
th
was 311.46. Option prices are:
Table 12 November 11th Google Option Prices [47]
Expiration
Date
Strike
Call Put
21-Nov 280
35.01 5
21-Nov 290
27.7 7.4
21-Nov 300
21.4 10.7
21-Nov 310
15.2 14.5
21-Nov 320
10.4 20
21-Nov 330
6.5 26.5

19-Dec 280
44.2 14.87
19-Dec 290
37.9 18.88
19-Dec 300
30.6 22.7
19-Dec 310
26.4 26.1
19-Dec 320
22 31.18
19-Dec 330
17.1 37.7


67

16-Jan 280
51 19.8
16-Jan 290
42.5 24.5
16-Jan 300
40 28.7
16-Jan 310
33 33.5
16-Jan 320
30 43.7
16-Jan 330
24.6 45

The following terms are used in the sections which follow.
Call option: Gives the owner the right, but not the obligation to purchase an
underlying asset at a predetermined price.

Put option: Gives the owner the right, but not the obligation to sell an underlying
asset at a predetermined price.

Strike price: The predetermined purchase price of an underlying asset for a call
option or the predetermined sale price of an underlying asset for a put option.

Exercise date: For American style options, the last date that the option can be
exercised or used. For European style options, the (only) date that the option can
be exercised or used.
4.3.3.1 Call Options
A call option gives its holder the right but not the obligation to purchase an underlying
asset at a specified execution or strike price on or before a specified exercise date. A
European style option can only be exercised on the exercise date. An American style
option can be exercised on or before the execution date. The key point is that an option is
a right to act, but not an obligation to act.


68
For purposes of this discussion, assume the current date is Nov 11
th
, 2008. The
current price of GOOG is 311.46. From Table 12, it would be possible to buy a Nov call
option for GOOG with a strike price of 320 for 10.4. For $10.4 a call option can be
purchased that would allow purchase a share of Google stock for 320 anytime before Nov
21
st
(still 10 days in the future since we are assuming it is Nov 11
th
). Since GOOG is
currently worth 311.46, the option would not be exercised immediately. If the option was
exercised, a share of stock could be purchased for 320. Since Google stock is available
on the market for 311.46, this would not be sensible. Similarly, any call option at a strike
price higher than the current price per share is worthless. Exercising it will cause the loss
of money.
A Nov call option for a strike price of 280 is available for 35.01. Its strike price, 280, is
lower than the current share price, 311.46. If it were exercised it today (assuming today
is Nov 11
th
), neglecting trading costs, the profit will be current share price cost of a
share via the option cost of the option itself = 311.46 280 35.01 = -3.55. At first,
this may seem surprising. The previous paragraph showed that call options with a strike
price higher than the current share price are worthless. This paragraph seems to imply
that a purchaser of a call option with a price less than the current share would also lose
money.
The key to understanding options is that their value is derived from variability. If the
share price of GOOG was static at 311.46, no option could ever be exercised for profit.
The current option prices are such that with the current price all are out of the money, that
is, they cannot immediately be purchased and executed for profit. The liquid nature of
the markets guarantees this. As soon as an option can be bought and executed for profit,


69
bidding occurs and drives up the price until no immediate profit is possible. The value
of an option is in variability. The holder of the option can profit when prices change.
The November call option for strike (exercise price) 320 costs 10.4. Figure 1 shows the
value of the option as the share price varies. For prices under 320 per share, the option
has no value. Its owner has a loss of -10.4 (the cost of the option). As the share price
increases, the option gains value. An important observation is that the potential value is
asymmetric. The option buyer can lose at most 10.4, but has unlimited potential.

Figure 11 Profit from Nov Call Option with 320 Strike Price
An analysis of the Nov call option for a 280 strike price yields a similar plot.
-20
-10
0
10
20
30
40
50
60
280 290 300 310 320 330 340 350 360 370 380
P
r
o
f
i
t

Share Price
Profit from Call Option to Buyer


70

Figure 12 Profit from Nov Call Option with 320 Strike Price

A call option becomes more valuable as prices or potential increases. This is
similar to a real option to expand.

It is significant to note that the value of a call option decreases with strike price and that it
increases as the expiration date is extended. Events far in the future have more
uncertainty. In the case of Google stock, there would be more time to increase or
decrease in value. Since the potential for profit is greater as the time frame increases, the
cost of the option also increases.
4.3.3.2 Put Options
A put option gives its holder the right but not the obligation to sell an underlying asset at
a specified execution or strike price on or before a specified exercise date. A European
style option can only be exercised on the exercise date. An American style option can be
-60
-40
-20
0
20
40
60
80
260 270 280 290 300 310 320 330 340 350 360 370 380
P
r
o
f
i
t

Share Price
Profit from Call Option to Buyer


71
exercised on or before the execution date. The key point is that an option is a right to
act, but not an obligation to act.
Again, assume it is Nov, 11
th
2008. A Nov put option for GOOG for strike price 280 is
available for $5. The holder of this option has a right to sell GOOG at 280. Since the
current price is 311.46, acting on the option would cause a loss. Just as with call options,
the value of the option results from variability. If the price of GOOG falls before the
option expires, a potential for profit exists. Suppose the price falls to 270. The holder of
the option could purchase a GOOG share for 270 (on the open market) and then sell it for
280 (to the unfortunate person who wrote (sold) the option). The profit would be 280
270 5 = 5 dollars per share.

Figure 13 Profit from Nov Put Option with 320 Strike Price
A Nov put option for GOOG for strike price 320 is available for 20.0. The holder of this
option has a right to sell GOOG for 320. Since the current price per share is 311.46,
-10
-5
0
5
10
15
20
25
30
35
40
240 250 260 270 280 290 300 310 320 330 340
P
r
o
f
i
t

Share Price
Profit from Put Option to Buyer


72
someone purchasing and exercising this option would have the following loss: 320
311.46 20 = -11.46.
Put options become more valuable as prices fall. This is similar to a real option to
abandon. The option to abandon is worth more when the project is worth less (ir as it
fails). It is significant to note that the value of a put option increases with strike price and
that it increases as the expiration date is extended.
Both call and put options increase in value as the time to expiration increases.
4.3.4 Valuing Financial Options Upper and Lower Bounds
The following plot is based on [48]

Figure 14 Upper and Lower Bounds to Value of Call Option
The first step in understanding the value of a call option is determining the upper and
lower bounds to its value. Continuing with the GOOG example for a 320 exercise price
for Nov, suppose that the current share price of GOOG is 0.0. At that price the value of a
0
100
200
300
400
500
600
0 500 1000
Value of Call
Stock Price
Upper Bound
Lower Bound
Value of Call
A
B
A
B
C


73
call option, which gives the right to purchase GOOG shares at 320 surely has no value.
It gives the right to buy GOOG at 320 per share, but the assumed current share price is 0.
As the price of GOOG increases, as long as the price remains below 320, the option has
no value. It is less costly to directly purchase GOOG stock. As GOOG share prices rise
above 320, the option starts to have value. It becomes possible to exercise the option and
buy shares of GOOG at 320 and to resell them for more than 320. If the current share
price is 321, the option could be immediate exercised and 1.0 profit made. Suppose the
price of the option were less than 1 dollar, say 0.75, anyone could immediate purchase
the option, exercise it to immediately earn a profit of 1 0.75 = 0.25. Such arbitrage
opportunities would immediately be recognized, assuming a fluid market and the price of
the option would be bid up to 1.00. A similar argument for all share prices above 320
sets the lower bound for the value of the option at share price option exercise price.
The upper bound for the value of a call option is the share price of the underlying stock.
Suppose the option had value above the share price. For instance, suppose there were
buyers willing to pay 100 for an option on a share of stock worth 80. Holders of the
option could immediately sell it (to a masochistic buyer) and buy an equivalent number
of shares of stock and pocket the difference. In this case, if the share prices rose, holding
the stocks instead of the option would yield the same profits. If prices fell below the
exercise price, the option is worthless but the stock still has value. It is seen that if the
option price (value) is above the share price, owners of the option would benefit by
immediately selling it. This forces the value of the option to be at maximum to be equal
to the share price.
Consider the following points on Figure 14.


74
Point A: If the stock (or underlying asset) is worth zero, the option is worth zero.
Presumably, if there is any potential for the stock to have value at a future time, someone
would be willing to pay some small finite amount for it. If it is zero, it has no potential.
No one would buy the stock or the option.
Point B: As the stock price increases more and more above the exercise price of the
option, it becomes more likely that the option will have value at the exercise date. If it is
very likely that the stock price will be above the exercise price, then holding the option is
the same as holding the stock except that you dont have to pay the exercise price until
you exercise the option. Suppose that GOOG is trading for 1000 and the 320 option is
selling for 1000 320 = 680. The buyer can purchase the option for 680 and invest the
320 in a risk free investment. Since it is fairly certain the price of GOOG will be above
320, this is the equivalent of buying a share for 1000, except that 320 does not need to be
paid immediately and can be invested. This leads to the option price being the current
share price minus the present value of the exercise price.
Point C: The exercise price of the option equals the current share price of 320. If the
price decreases, the most that can be lost is the purchase price of the option, if the price
increases the profit is limitless (the price of the stock has no upper limit). Given this
asymmetry, the option has some positive value even when the exercise price equals the
current share price. The value of the option at point C is related to the variability of the
stock or underlying asset. If it has very low variability, its quite likely that the share
price when the option matures will be around 320. No one will pay much for this option,
since it is likely that the payoff is not great. Suppose that the stock (or underlying) asset
has high variability. Then it may be worth much less or much more than 320 when the


75
option matures. In this case, since losses are limited to the price of the option and
gains are equal to the share price minus the exercise price and are potentially large, the
option has more value. This is a key observation, the more variability in the underlying
asset, the more valuable the option. A second key point to note is regardless of the
underlying asset, the longer the period until the option expires, there is more opportunity
there is for change. This indicates that the longer the period to expiration, the more
valuable the option.
4.3.5 Valuing Options
Call options can be valued by considering the value of an equivalent portfolio formed by
purchasing stock and borrowing money at the risk free rate. If this portfolio and the
option have the same value at all possible states, then the value of the portfolio must
equal the value of the option. If it didnt then an arbitrage opportunity would exist. For
instance, if the option were priced higher, owners of the option could sell it and purchase
the portfolio and profit. Such arbitrage opportunities would be recognized by participants
in the markets. As more and more option owners attempt to sell, as supply increases, the
price is forced downward. More people are trying to sell. There would be fewer and
fewer buyers. Buyers would realize that they could buy the portfolio instead as well.
The price of the option would drop until it reached that of the portfolio.
The following is based on [49].
To value a call option on a stock, suppose that the underlying stock is currently priced at
$100 and that
in one time
S = 100
q
1
- q
S
+
= 180
S
-
= 60


76
period it will either increase in value to $180 with probability q or decrease in value to
$60 with probability 1-q.

Figure 15 Stock Prices of Hypothetical Security

Now, look at the value of a call option on the same security assuming the same possible
movements in stock price over the period. Assume for now that the exercise or strike
price of the option is 112. The value of the option at the end of the period, C
+
or C
-
, is
easily calculated based on the stock price and the exercise price as shown in the figure
below. But what is the value of the option at the start of the period, that is, what is C?
C
q
1
- q
C
+
= max(S+ - E, 0) =
max(180 112, 0)
= 68
C
-
= max(S- - E, 0) =
max(60 -112, 0) = 0

Figure 16 Option Prices on Hypothetical Security

Suppose, an equivalent portfolio is constructed by buying N shares of the stock and also
borrowing money (B) at a risk free interest rate (r) to finance the purchase. At the end of
the period, the principal of the loan plus interest would need to be repaid, (1+r)B. The


77
porffolio also have N shares of the stock worth either NS
+
or NS
-
depending on the
movement in the share price.

C = NS - B
q
1
- q
C
+
= NS
+
- (1+r)B
C
-
= NS
-
- (1+r)B

Figure 17 Price of Equivalent Portfolio
Since the option and the portfolio have the same returns at the two possible states at the
end of the period, the above diagram yields two equations in two unknowns (N, B). The
values of S
+
, S
-
, C
+
, C
-
at the end of the period are known as shown in the above
diagrams.

Equation 21 Relationship of Call Price to Hypothetical Portfolio at Start of Period

Equation 22 Relationship between Call Price and Hypothetical Portfolio with Increase in Stock Price

Equation 23 Relationship between Call Price and Hypothetical Portfolio with Decrease in Stock Price



78
Using Equation 22 and Equation 23 and solving for N and B yields:

Equation 24 Number of Shares


Equation 25 Size of Loan in Portfolio
The return of the option, $68 if the stock price increases to $180 and $0 if the stock price
decreases to $60 can be replicated by buying 0.567 shares and borrowing $31.5. The
value N is also known as the replication ratio or options delta.
Plugging these values back into C = NS B (Equation 21) yields

The value of the option (at the start of the period) is $25.19.
As given in [38], Equation 24 and Equation 25 can be substituted into Equation 21 to
yield.

Equation 26 Value of Call
Where, p is the risk neutral probability and is given by:


79

Equation 27 Risk Neutral Probability
Application of this to software projects will be shown in a following section.

4.3.6 Relationship between Calls and Puts
The value of puts on an asset is related to the value of calls on the same asset. From [50]:
Value of call + present value of exercise price = value of put + share price
Or
Value of put = value of call + present value of exercise price share price.

4.3.7 Factors impacting the price of options

Table 13 Factors Impacting Option Prices [51]
Factor Price (value) of call Price (value) of put
Stock or asset price increase Increase Decrease
Exercise or strike price
increase
Decrease Increase
Interest rate increase Increase Decrease
Time to expiration increase Increase Increase
Volatility of stock price or
asset
Increase Increase



80
On key observation from the above is that both puts and calls increase in value with
variability, either due to an increase in the volatility of the underlying asset or due to an
increase in the time until the option expires. With respect to real options, this indicates
that risky projects, with greater rewards and greater chance of failure, have more value
than less risky projects. At first, this is very counter intuitive. With NPV analysis,
increased risk decreases value. With options, increased risk increases value. This is due
to the asymmetry of options. The most that can be lost is the cost of the option, but the
gains are limitless. High variance means high potential gains while the losses are still
limited. The option or choice to invest in a risky project has more value than the option
to invest in a less risky one.

4.3.8 Black Scholes Formula
The technique shown on Section 4.3.5, Valuing Options, derived the value of an option
by creating a leveraged portfolio (consisting of some amount of the asset plus a borrowed
amount) that would have the same returns as the option. A leveraged portfolio is created
by simply borrowing money to finance some portion of the asset or stock purchase. In
section 4.3.5, the return over a single time interval was considered. By subdividing the
time interval into progressively smaller periods, it is possible to derive the Black-Scholes
formula. Derivation of this formula is beyond the scope of this thesis, but the interested
reader is referred to [52]. The Black-Scholes formula provides a means to evaluate the
value of a call option, and via section 4.3.6 the value of puts. Let:




81



As developed in [52], the Black-Scholes formula for the price of a call option is given by:

Where



Equation 28 Black-Scholes Formula
A cumulative distribution function, F(X), is the probability that a random variable, X, is
less than or equal to some value, x.

A standard normal distribution is a Gaussian distribution with 0 mean and unit variance.
So N(d) is the probability that a random variable with a standard normal distribution is
less than or equal to d.


82
An application of the Black-Scholes formula to real assets (projects) is presented
below in section 4.3.13.
4.3.9 Introduction to Real Options/ Extended NPV
Financial options are pieces of paper, or more accurately today, electronic records, that
grant the right to purchase or sell other pieces of paper such as stocks or other similar
instruments. The purchaser of an option is paying at the current time for the right or
ability to take another action in the future. They are seeking to profit from the flexibility
to act on uncertain future events. If the future unfolds favorably, they can profit by
investing more. If the future unfolds unfavorably, they have lost only the cost of
participation, that is, the cost of the option. The valuation techniques used in financial
options are ways to assess the value of this flexibility. The value of an option, or
equivalently the value to have the flexibility to act, was seen to depend upon the current
worth of the asset, the amount of time until a decision is needed, the amount of variability
in the value of the asset and the risk-free interest rate (the opportunity cost, since instead
of trying to benefit from flexibility an investment with certain returns could be chosen).
These factors determine the value of the option. The value of the option is what an
investor will pay today for that flexibility.
Real options are an application of financial options theory to real assets or projects. By
making analogies between elements in investments in projects and elements in
investments in securities (stocks), the valuation techniques of financial options can be
used to assign value to flexibility in projects. This is best understood by illustration.
Suppose that is necessary to build a prototype to determine the feasibility of building a
full system. An investment is being done now (the cost of the prototype) for the option of


83
building a full system later. This is analogous to buying a financial option to buy a
stock at a later date. In both cases, there is flexibility. After building the prototype, there
is a choice of either building the full system or simply discontinuing the project. After
purchasing the financial option, there is a choice of either purchasing the stock or not. In
both cases, there is uncertainty. The feasibility of the system and conditions for its use,
its potential value in the future, is uncertain. The future stock price is uncertain. Both
cases are investment decisions. Both have the same opportunity cost. Rather than
engaging in a project that has risk, or trying to invest in a stock that has risk, its possible
to invest in a risk-free investment such as a government bond.
4.3.10 Option to Defer
Discounted cash flow/NPV analysis assumes that the decision to invest must be made
now. The project is either accepted or rejected at the present time. However, there are
many situations where it is beneficial to wait until more information is available or until
there are favorable changes in market conditions or the cost of resources. Agile based
approaches to software development derive much of their value from the option to defer.
Decisions are delayed by building incrementally. Later releases benefit from information
learned in early releases and by delaying decisions its possible to react to favorable or
unfavorable changes in the environment. Value is maximized by deferring. The value of
agile approaches is increased by situations that are highly variable. Options are worth
more if range of possible outcomes is wide. Its interesting to note that SDLC, waterfall
type software development processes derive value from reducing variability by having
standardized processes. Reduced variability reduces risk. Reduced risk lowers the
discount rate that should be used in static NPV analysis of projects. Since the discount


84
rate is in the denominator of the terms in NPV calculations, a lower discount rate from
reduces variability increases value.
The following is based on [53]. Suppose Microsoft is considering whether to develop a
new version of its Windows operating system. It has a proprietary license to produce
Windows. Assume that it takes one year to develop the new OS. Further assume that the
expected future cash flows depend on the future demand for new PCs. If demand is high,
future cash flows will be 180 million. If demand is low, future cash flows will be 60
million. Assume that there is a 50% chance of high demand and a 50% chance of low
demand. Development costs are 80 million. Should a project to build a new OS be
conducted?
The first step in the analysis is a static NPV calculation. V
+
is the value of the project at
the end of the period (in one year) assuming high demand. V
-
is the value of the project
at the end of the period assuming low demand. V is the value of the project today and
must be calculated.
q
=
0
.5
1

q
=
0
.5
V
+
= 180
V
-
= 60
V

Figure 18 NPV Analysis for Option to Defer Example
Investment: I = 80 (based on cost estimates)


85
Discount Rate: k = 0.20 (discount rates can be determined via the capital asset pricing
model)
Risk-free rate: r = 0.08 (assume this to be the case)
Actual probability: q = 0.5 (from marketing/sales forecasts of future demand)
Risk-free probability:
The present value of the future cash flows can be equivalently be calculated using risk-
free probabilities and rates.

Equation 29 NPV Analysis using Risk Free Discount Rate - Option to Defer Example
Or using the actual probabilities and risk adjusted discount rate.

Equation 30 NPV Analysis using Risk Adjusted Discount Rate - Option to Defer Example
The NPV of the project is given by:
NPV = V I = 100 80 = 20 million.
Equation 31 Static NPV of Operating System Example
Based on a positive NPV alone, the project would be accepted. But should the project be
conducted? There is substantial risk (50%) that demand will be low for PCs and the
investment will lose money. Only 60 million in cash flows would be generated one year


86
hence and 80 million is required as an investment. If management had no other
options, no flexibility, given that the NPV is positive, the project should be conducted.
But management does have options. Only Microsoft can produce a new version of
Windows. management could choose to wait one year to see the level of PC demand and
then decide whether to invest.
q
1
- q
C
+
= max(V
+
- I, 0) =
max(180 80, 0)
= 100
C
-
= max(V
-
- I, 0) =
max(60 -80, 0) = 0
C

Figure 19 Option Analysis for Option to Defer Example
C
+
is the value of the option at the end of the period (one year) if demand is high. In this
case, future revenue would be 180 and the development cost is still 80. The possible
choices available would be to conduct the project and earn 180 80 = 100 million or do
nothing. Clearly the project would be done one year given high demand, so C
+
is 100
million. C
-
is the value of the option at the end of the period if demand is low. In this
case, future revenue is 60 and the development cost is still 80. The possible choices in
this case are to invest 80 to get back 60 or to simply not conduct the project. C
-
is 0 since
it is preferable to not conduct the project rather than lose 20 million. Based on this
analysis, if demand is high after waiting one year, then invest. Otherwise, dont.
This option is worth the following.


87

Equation 32 Option Value - Option to Defer Example
The option to wait is worth more than the NPV from the immediate execution of the
project. The value C can be considered as an extended NPV that includes the static NPV
plus the value of flexibility. Management should wait to see how demand for PCs
evolves over the next year. Intuitively, this result is correct. Given the substantial risk of
loss and the ability to wait, it should be better to resolve market uncertainties before
investing. One significant point to note is that this analysis neglects the impact of
possible competitors. While Microsoft is waiting for market uncertainties to resolve,
competitors could capture the OS market. As will be explored in section 4.4 of this
thesis, game theory can be used to analyze such competitive interactions.
The following analogies exist between real and financial options [54].
Table 14 Analogies between Real and Financial Options for Option to Defer [54]
Variable Real Options in Projects Call Option
V Present value of expected cash
flows
Stock Price
I Present value of investment
outlays
Exercise Price
T Length of deferral time Time to maturity
r Risk free rate Risk free rate
2
Volatility of project returns Variance of stock returns



88
4.3.11 Option to Expand
Once a project is underway, management may have options to modify the level of output.
If demand is high, it may be possible to invest more to expand production. If demand is
low, planned expenditures can be reduced.
An option to expand the scale of production by e% is analogous to a call option, C, on (a
fraction of e%) the value of a project [55]. The exercise price of an option to expand is
the additional investment outlay. Suppose that demand is high in the OS example of
3.2.10 and that management can expand production by 50% by investing an additional 40
million (perhaps by advertizing more).
In this case:
The project value at one year is given by:

Equation 33 Project Value at Year 1 - Option to Expand Example
That is, its possible to continue with the original plan or increase sales by 50% by
investing I
1
.

Equation 34 Project Value at Year 1 with High Demand - Option to Expand Example

Equation 35 Project Value at Year 1 with Low Demand - Option to Expand Example



89
Discounting this back to the start of the project:

Equation 36 Project Value at Start of Project - Option to Expand Example
The expanded NPV is:

Since the static NPV is 20 (Equation 31), the value of the option to expand is 18.5.
The option value can be calculated directly as:
q
1
- q
C
+
= max(V
+
- I, 0) =
max(0.5*180 40, 0)
= 50
C
-
= max(V
-
- I, 0) =
max(0.5*60 - 40, 0) = 0
C

Figure 20 Option Value Calculation - Option to Expand Example


Equation 37 Option Value Calculation - Option to Expand Example


90
4.3.12 Compound Options
As an example of compound options, suppose a project is being considered to develop
and then market a new technology to deliver high definition quality movies via the
internet. Assume that the project will consist of the following:
An initial two year research and development effort
A large investment to develop infrastructure at the start of year two.
Positive cash flows beginning in year three continuing until year ten.
After year ten, it will be assumed that another technology will be developed and
will cause this technology to be obsolete. Essentially, the operation will cease in
year ten.
Assume that the rate of return demanded by investors for a security with similar
risk to this project is 15%.
Assume that capital for the development and infrastructure costs is available at a
4% interest rate.
Assume cash flows are as shown in Figure 21 and in Table 15.


Figure 21 Cash Flows for Internet Based Movie Delivery Example
-1500
-1000
-500
0
500
1000
1 2 3 4 5 6 7 8 9 10 11
T
h
o
u
s
a
n
d
s
Year
Cash Flows


91
The net present value of the project can be calculated as follows.
Table 15 Present Values of Cash Flows for Movie Delivery Example
YEAR CASH FLOW
PRESENT
VALUE
0 -10 -10
1 -40 -38.46153846
2 -1350 -1248.150888
3 300 197.2548697
4 350 200.113636
5 400 198.8706941
6 450 194.5474182
7 500 187.96852
8 450 147.1057982
9 350 99.49184421
10 150 37.07770592

-34.18193974

The sum of the present values is -34,000. Based on NPV analysis, this project would not
be done despite its potential. Intuitively, this seems wrong. Delivering high quality
movies directly to consumers via the internet would seem to have great potential. The
problem in this case, and with NPV analysis in general is the analysis is that it is static.
Regardless of how well or poorly the R&D phase progresses and regardless of how
demand materializes in year three forward, there is an assumption that management will
fully commit or not to the project on day zero and will run the project unaltered for the


92
entire 10 year period regardless of what additional information is available. Clearly,
this does not represent how companies behave.
In reality, management has two decisions. In year zero it can decide to engage in a two
year R&D effort and in year two it can decide whether to invest in full scale production.
The R&D effort can be viewed as an option. It provides the opportunity, but not the
obligation, for the company to invest for full scale production in year two.
The opportunity to invest in year two is really a (call) option with a strike price of 1350
thousand (the additional investment required to start production, that is, to begin actually
selling movies) with an expiration date of two years on an asset worth the NPV of the
cash flows from years 3 through 10. The present value of the cash flows from years three
to ten can be calculated as follows (discounted to year 2, again assuming a 15% discount
rate).
Table 16 Cash Flows Years 2 through 10
YEAR CASH FLOW
PRESENT
VALUE
3 300 197.2548697
4 350 200.113636
5 400 198.8706941
6 450 194.5474182
7 500 187.96852
8 450 147.1057982
9 350 99.49184421
10 150 37.07770592


93

1262.430486

As seen by the NPV analysis, based on this static view of the future, the project was not
worth conducting. But suppose during years 1 and 2, while the company is conducting
R&D, market conditions change. There could be an expansion of the number of
households with broadband access or there could be a recession that limits spending on
entertainment. Assume that demand will either increase by 50% per year or decrease by
33.333%. Marketing data or market surveys might be used to determine these market
swings.

1262
1893
846
2840
1268
567

Figure 22 Possible Changes in Demand (Movie Delivery Example)

The risk free probability is given by:


94

Equation 38 Risk Free Probability (Movie Delivery Example)
In Equation 38, the actual probabilities, 1/2 change of increased sales and 1/3 chance of
decreased sales were used.
As in section 4.3.5, Valuing Options, the value of a call option is

For commercial use, an investment of 1350 is required at year two. The value of the
project is the maximum of (the expected revenue minus the investment) and zero. If the
expected revenue is less than the required investment, the project will be abandoned. The
most revenue expected is 2840; the least is 567 and if there is no change in demand, 1268
is expected (see Figure 22). Working backwards from year two:
Max(2840-1350,0) =
1490
Max(1268-1350,0) =
0
Max(567-1350,0) = 0
C
L
C
H
C

Figure 23 Working Backwards in Movie Example


95
Where:





So, the value of the option for commercial implementation of this project is 273
thousand. The cost of obtaining this option is the cost of the R&D effort discounted back
to year zero.

For a cost of 48,500, management may purchase an option worth 273,000. The project is
worth doing when management flexibility and the variability of the market are
considered.

4.3.13 Example of Application of Black-Scholes Formula



96
The example given in section 4.3.12 contains many assumptions about the future. The
potential upward and downward movements in the market for high definition movies
delivered by the internet are assumed to be 1.5 and 0.67 respectively. There may be
some marketing data to support this, but this is more likely a guess at best. Weve made
assumptions about future cash flows as far as 10 years out. This is possible to do, but it
quite error prone. An alternate approach is described in [56]. The following procedure is
suggested.
1. Identify a replicating or tracking portfolio, and calculate its price and volatility
2. Size the investment relative to the replicating portfolio
3. Apply standard financial option pricing tools, particularly Black-Scholes

Continuing the same example as in 3.2.12, the first step is to identify a replicating or
tracking portfolio. This means, a security with the same risks and potentials as the real
asset under consideration must be identified. Assume that following considerable
analysis, it is determined that Netflix, NFLX, is such a security. On Jan 15, 2009, NFLX
traded for $31.26/share with a market capitalization of 1.83 Billion. The volatility of the
stock from ivolatility.com is 63%. Assume the risk free interest rate is 4% as in section
4.3.12. Assume the project (new movie distribution service) can capture 10% of the
market. In practice, this might be based on an assessment of marketing forecasts and an
assessment of planned technology against that used by the competitor, Netflix. 10% of
the current market is work 1.83 billion * .1 = 183 million. Also assume that the market
size will be the same in two years, meaning the current share price (183 million) equals
the strike price (what it will be in two years). This example is meant to illustrate the use
of the Black-Scholes formula, so the inputs and results do not directly correspond to the
example in the previous section, 4.3.12.


97

Share Price 183
Strike Price 183
Time to Expiration (Days) 730 (2 Years)
Volatiliy 63%
Annual Risk Free Interest Rate 4%

Calculating the option value (essentially what this project is worth) using Black-Scholes
by hand is cumbersome and difficult. Standard calculators are available on the internet
[57] [58].
Using available Black-Scholes calculators, the value of this option is 68 million.
Consistent results were obtained using several on-line calculators. If the total investment
required is less than this, it may be a good project to conduct.
4.3.14 Discussion
Real option approaches are seen to capture the value of management flexibility. Two key
assumptions are made during option valuation.
There are no arbitrage opportunities. That is the market is fluid, fair and
transparent.
That there exists a twin security traded on the market that has the same risk
characteristics as the project under consideration.


98
Both of these assumptions are questionable. Can we really identify a twin security? In
section 4.3.13, does an investment in Netflix really have the same risk as the proposed
project? Does it have the same potential? Are the results of the project correlated with
the returns on Netflix? Its more reasonable that the opposite is true. The better Netflix
does, the worse the prospects for the project. Perhaps a negative correlation exists.
[56] notes that there is little evidence that the correlation between an individual
investment and a twin security is valid. It notes that the co-variances (betas) of
individual securities and the overall market are well studied, but that covariances
between pairs of securities or investments (projects in the context of this thesis) are
not. Further noted is that The real-option approach may provide qualitative insight
even if some of the underlying assumptions are invalid.

If we accept that at least qualitatively, a real option approach provides insights into the
value of projects, there are still dimensions not captured by this approach. In particular,
there is no consideration of the interactions with competitors and with market timing. Is
there value to being first to market? Suppose competitors either increase or decrease
production or enter or leave markets? Game theory approaches attempt to analyze this.
4.4 Game Theory Approaches to Project Valuation
4.4.1 Introduction
One significant lacking in the NVP/Discounted Cash Flow and Real Option valuations of
projects is that there is no explicit evaluation of the impact of possible competition or
cooperation. The actions and reactions of other firms can have significant impact on the
profitability and thus the value of any proposed effort. NPV valuations are static. They
evaluate what will happen if the project is blindly continued regardless of how reality
unfolds. Real options are a valuation technique that includes management flexibility.
The ability to decide to continue or not, to expand or contract and to delay can


99
significantly increase project value. Lacking in this valuation technique are tools to
understand and evaluate potential competitors or partners. For instance, real option
techniques may tell us that there is value in delaying until more information is available
or until ambiguity is resolved. This is true in a world where the firm has a monopoly.
This is also true in a world of perfect competition, where a late entrant into a market with
better technology or prices could easily capture its share of the market. With reality
somewhere between these two extremes, game theory offers a systematic way of thinking
about and evaluating the impact of other firms on the value of a project. It allows an
understanding of which strategies will lead to competitive responses and which to
cooperative responses from other firms. One caveat is that the project under
consideration needs to significant enough to have strategic value to the firm. Competitors
react to entry into new markets, significant new technologies, major changes in products
and start ups. As such, game theory analysis is irrelevant for smaller efforts where a
competitor would be unconcerned and probably unaware.
4.4.2 Definition of Game Theory
Stripped to its essentials, game theory is a tool for understanding how decisions impact
each other [59]. It involves being able to visualize, analyze and anticipate the actions
and reactions of competitors, or in game theory terminology, of players. Game theory
studies techniques for players (management) to make optimal decisions to maximize their
returns in an environment with other players (other firms).
4.4.3 Nash Equilibrium / Prisoners Dilemma Example
For certain games, as each player reasons about all possible benefits and consequences
and about the actions of other players, its possible that as all players seek to maximize


100
their returns, the chosen actions of all players will converge into a single consistent
set. All of the reasoning and actions of players converge into an equilibrium where each
player will receive their maximum benefit. Given the situation and the rationally driven
actions of each player, no other course of action by any single player would increase their
return. This equilibrium is sometimes referred to as a Nash Equilibrium.
Nash equilibrium is best understood by examining a simple game known as the
Prisoners Dilemma. Two suspects, prisoner A and prisoner B, are arrested for a crime
and are interrogated separately by the police. Each suspect is offered two choices:
Confess and implicate the other suspect and receive a more lenient sentence.
Remain silent. Dont confess; dont provide evidence against the other suspect.

Further assume:
If both remain silent, they both will receive light 1 year sentences due to the lack
of evidence of more serious crimes.
If one turns evidence and the other remains silent. The rat receives no sentence
and the one who remains silent receives a 10 year sentence.
If both talk, they both receive 5 year sentences.

Table 17 Classic Prisoner's Dilemma
Prisoner A
Prisoner B
MUTE TALK
MUTE (1,1) (0,10)
TALK (10,0) (5,5)



101
The actions of prisoner A are shown on the horizontal. The actions of prisoner B are
shown on the vertical. The potential outcomes are as follows:
(1, 1): A receives a 1 year sentence; B receives a one year sentence
(0, 10): A receives a no sentence; B receives a ten year sentence.
(10, 0): A receives a 10 year sentence; B receives no sentence
(5, 5): Each receives a 5 year sentence
Prisoner A can either be mute or talk and he does not know what B will do. His
reasoning would be as follows: If B is mute, if I am mute I receive a 1 year sentence and
if I talk, I receive no sentence. Clearly in this case it is better to talk. If B confesses, if I
am mute I will receive a ten year sentence and if I talk, I will receive a five year sentence.
Again, it is better to talk. So regardless of the actions of B, As best option is to talk. A
similar analysis of Bs options leads to the same conclusion for B. Its better to talk
regardless of what A does.
In game theory, when a player has an optimal decision regardless of the actions of other
players, that decision is said to be dominant. In this game, both prisoner A and prisoner
B have dominant actions regardless of what the other does. Since both will chose their
dominant actions, equilibrium exists. Both will talk.
4.4.4 Commitments
In real option analysis, a premium was placed on flexibility. Managerial choice added
value at various stages of the project. In game theory analysis, the lack of flexibility or
said another way, commitment can add value. If a competing firm can view a firms


102
commitment to invest and participate in a particular market, they may choose not to
compete. It may be better not to compete rather than compete and face joint disaster. A
first entrant to a market, if deeply invested and committed, may deter other firms. If a
firm has no choice but to continue in a particular market, competitors may choose not to
engage them. As an example, Microsoft is deeply entrenched in the operating systems
business. They are very unlikely to leave that market regardless of which competitors
exist. Too much of their revenue is generated in this market to allow any flexibility by
Microsofts management. This commitment deters competitors. Competitors would face
a long extended costly battle for market share. This type of commitment is also referred
to as a credible commitment. There is no doubt of Microsofts commitment in this
market.
4.4.5 Games
Game theory reduces complex strategic decisions to four dimensions [60].
Identification of the players
The players in making strategic decisions are management. One key assumption
in simple game theory is that the actions of the players are rational. That is, they
analyze the game and make decisions to maximize value. Other factors that may
impact the decisions of people such as ego, hatred, revenge and favoritism are not
considered. Since these factors are present in most decisions, a valid criticism of
game theory is that it fails to account for psychological factors. Smit [61] notes
that although these factors can play a role, the assumption of rationality is a good
starting point in understanding for business and economic decisions.
Timing or order in which the players make their decisions
Games can involve simultaneous or sequential play. With sequential play, which
player moves first can have impact on the outcome of the game.
The available actions and information set
Players may or may not have complete information about the environment or
about other players.
The payoff structure attached to each possible outcome.


103
Its necessary to identify the source of value for the players. This may be
shareholder value evaluated with techniques such as NPV or real options or it
may be to gain market share or maximize short term profits.
Once a game is characterized along these dimensions, game theory provides techniques
for each player to come to analyze and understand potential moves by competitors and to
work toward a solution. As noted in section 4.4.3, a key to solving games is to look for
dominant strategies, that is, strategies that maximize value regardless of the actions of
other players.
4.4.6 Scenarios
The following scenarios follow the discussion in [62].
4.4.6.1 Prisoners Dilemma
The classic prisoners dilemma game was described in section 4.4.3. Competition
between two firms, each seeking to introduce a new innovation, can be described as a
prisoners dilemma game. Each firm can choose to invest at the current time or wait to
allow time for the market to be better understood or for technical issues to be resolved.
Without competition, real option analysis shows the value of delay under some
circumstances. With competition, a prisoners dilemma type game can be used to
understand the strategic choices available and their impact on value.
Table 18 Analogies between Prisoners and Firms in Classic Prisoners Dilemma Game
Prisoners Dilemma Analogous Strategic Game
Players Prisoners Firms
Option Confess / Turn Evidence Invest immediately
Option Remain silent Wait to resolve uncertainty
Possible outcome for
individual player
Receives no sentence Obtains full value of project
without added value from
delay.
Possible outcome for Receives short sentence Shares value of project with


104
individual player added value from delay
Possible outcome for
individual player
Receives intermediate
sentence
Shares value of project
without added value from
delay
Possible outcome for
individual player
Receives long sentence Receives no value.
Best possible outcome for
individual player
Prisoner confesses while
other prisoner does not.
Prisoner who confesses
receives least possible
sentence. Prisoner who
doesnt confess receives
maximum sentence.
Firm invests immediately.
Other firm does not invest.
Firm that invests receives
maximum value (without
added value from delay).
Firm that doesnt invest
receives no value.
Nash Equilibrium Both players confess. Both
receive intermediate
sentence.
Both firms invest
immediately and share
lower value.

As an example, lets assume that there are two competing software firms preparing to
invest to create virtual reality video games.
Each firm has two choices:
Invest immediately.
Delay to resolve uncertainty and benefit from flexibility as the environment
evolves.

Further assume:
The current NPV value of the market for virtual reality games is 1 billion. This
will be shared by all firms that participate in the market. In this example, if only
one firm invests it will receive the whole value; if two firms invest they will share
this value.
The value of the market including the added flexibility due to delay based on real
option analysis is 1.2 billion. Perhaps by delaying, better technology could
increase future sales or a better understanding of the market from additional
studies could produce more popular games. Based on the choices made, this
could be received by one firm or shared by both.
If both firms delay, they will share the maximum value of the market including
the value added by managerial flexibility to respond to market or technology
changes.


105
If one firm invests immediately while the other doesnt invest it will receive
the entire NPV without the added value of flexibility.
If both firms invest immediately they will share the NPV without the added value
of flexibility.
Table 19 Prisoners Dilemma Game between Firms
Firm A
Firm B
Delay and invest Invest Immediately
Delay and invest (600,600) (1000,0)
Invest Immediately (0,1000) (500,500)

The actions of firm A are shown on the horizontal. The actions of firm B are shown on
the vertical. The potential outcomes are as follows:
(600, 600): Both firms share 1.2 billion
(1000, 0): A receives 1 billion; B receives nothing.
(0, 1000): A receives nothing; B receives 1 billion
(500, 500): Both firms share 1 billion
To solve this game, the first step is to determine whether a dominant strategy exists.
For firm A:
If firm B delays, A should invest immediately to receive 1000 rather than 600.
If firm B invests immediately, A should invest immediately to receive 500 rather
than 0.


106
Since firm As best strategy is to invest immediately regardless of Bs actions, a
dominant strategy for A exists. Similar analysis leads to the same conclusion for B, that
is, B should invest immediately. This leads to a Nash Equilibrium as indicated in the
table by the highlighted cell.
There are several interesting observations that arise out of this example.
NPV/discounted cash flow, real option and game theory analysis assign different
value to the project. The project value based on NPV analysis without
consideration of potential competitors is 1 billion. The project value based on real
option analysis without consideration of potential competitors is 1.2 billion. The
project value based on game theory analysis is 500 million.
This indicates that a careful analysis of potential competitors is a crucial step in
determining value and in determining the best strategic direction.
As indicated in the sections on real options, there is value in flexibility and it must
be considered. Competition is seen to remove flexibility. Theres no value in
waiting for more information if a competitor can remove all your options by
gaining the entire market while you delay.
Game theory analysis depends on NPV and real option analysis. Those
techniques are used to assign value to the various choices available. Game theory
can be used to choose between choices.
Game theory applies to projects with strategic value. For small routine projects,
competitors are unaware and probably unconcerned.
An understanding of the market and of competitors is needed to perform valuation
of projects with strategic value.

4.4.6.2 Grab the Dollar
A classic grab the dollar game involves two players sitting with a dollar between them. If
only one player grabs for the dollar, they get it and win. If both grab for the dollar, it
tears in half. They both get a worthless torn dollar. Both lose. This is analogous to the
situation when two firms are competing in a market that can only support one firm or
perhaps one standard.


107
Table 20 Analogies between Prisoners and Firms in Classic Grab the Dollar Game
Grab the dollar Analogous Strategic Game
Description Two players sit at a table
with a dollar between them.
They can either wait or grab
the dollar. If one grabs, he
wins the dollar. If both
grab, they tear the dollar
and both lose.
Two firms are considering
an investment in a market.
The firm that invests first
(leads) will gain most of the
market. The second firm
can follow and gain a small
slice of the market. If both
firms try to lead, they will
both lose money.
Players People Firms
Option Grab for dollar Lead. Invest heavily,
establish a standard and
gain most of market
Option Dont grab Follow. Enter the market
later and get a small share.
Possible outcome for
individual player
Get a dollar Gain most of market
Possible outcome for
individual player
Get half a dollar (presumed
worthless)
Lose money in costly battle
over establishing a standard
Possible outcome for
individual player
Get nothing Gain a little piece of the
market
Best possible outcome for
individual player
Dependent on sequence of
play. By moving first, you
win.
Depends on sequence of
actions. Described below.

Suppose the following situation. Two firms are considering investing in a new
innovation that requires the establishment of a standard or format and the market will
support only a single standard. Further assume that if both firms invest fully and attempt
to lead in the market and establish a standard, they will both lose money in a costly battle.
If one firm invests and leads, it will gain most of the market. The second firm could then
invest and using the same standard could obtain a small slice of the market. As an
example of this type of game, two rival consortiums of media and electronics companies
have been competing over the last several years to establish a new standard for high


108
definition movies: Blu ray and HD DVD. Similar battles have occurred in the past
over standards in media formats, operating systems and computer hardware.
Each firm has two choices:
Lead: Invest heavily to try to establish a dominant standard. If the attempt is
successful, it will gain most of the market share and value. If the attempt fails,
the firm will lose substantial money.
Follow: Let another firm establish the standard. Enter the market later, perhaps
pay royalties to the first firm, and accept a lower market share and value.

Further assume:
If only one firm attempts to lead, it will be successful.
If both firms attempt to lead, they will both fail and suffer loses.
The total market has a NPV value of 1 billion.
A successful leader will get 90% of the market; a follower 10%.
Failure will result in a loss of 200 million for a firm.
If neither firm attempts to lead, no product at all is developed. This is analogous
to neither player grabbing for the dollar in a grab the dollar game. No play
occurs.

Table 21 Grab the Dollar Example
Firm A
Firm B
Follow Lead
Follow --------- (900,100)
Lead (100,900) (-200, -200)

The actions of firm A are shown on the horizontal. The actions of firm B are shown on
the vertical. The potential outcomes are as follows:


109
Neither firm participates
(900, 100): A receives 900 million, B receives 100 million
(100, 900): A receives 100 million, B receives 900 million
(-200, -200): Both A and B loss 200 million
The solution of this game depends on whether play is sequential or simultaneous.
Assume that firm A has no knowledge that B is doing research and development toward
this market or of Bs actions. Clearly, A would choose to invest under the assumption
that it had no competitors and that it would gain the entire value of the market. If it were
aware of Bs intent to participate in the market, its actions depend on the sequence of
play. If A is able to act first (winning a race to innovate) it gains most of the value (most
of the market). This is shown in the top right cell of the table. If B has already invested
heavily, As best choice is to follow. A would receive 100 million. If A attempts to catch
up (lead as well), the results are disastrous for both A and B. They both lose.
The key observation of this example is that the sequence of play can be critical. The rush
to be first to market can be a key to success in some situations.
4.4.6.3 Burning the Bridge
The burning the bridge game is best illustrated by the following scenario. Suppose an
island exists between two hostile countries, A and B. Each is connected to the island by a
single bridge and each wish to occupy the island. Neither wants a prolonged costly war.
Suppose A moves its army onto the island and then burns the bridge, leaving its army
stranded on the island. Without the possibility to retreat, As army can only fight. B has
two choices; it can either enter a costly unwanted war or cede the island to A. Given As
demonstration of commitment and assuming Bs wish to avoid for battle, B will cede the
island.


110
In a similar way, a firms demonstration of commitment can deter competition. A
perceived commitment, whether real or not, can be equally effective. If competitors are
convinced of a firms commitment, that is sufficient to deter them. Commitments were
discussed in section 4.4.4.
4.4.7 Discussion
Game theory approaches are seen to offer ways to reason about the environment that a
project will be conducted in and about the impact of possible competition or cooperation.
It is relevant for large strategic types of projects such as entering new markets, new
businesses or introducing entirely new products.
4.5 Process Measures
4.5.1 Introduction
The financial measures described above, are dependent on an estimate of cash flows, that
is, on the revenues earned by the product developed by the software project. The projects
presented as examples above all had a product sold in the market place or companies
competing in the market place. This leads to an important question. How can the
financial value of internal projects, those that do not produce a product for sale but
instead satisfy internal business needs with a firm, be evaluated? Many internal projects
are done to improve business processes, support new business processes, to reduce labor
and other resources needed or to improve quality of processes or products. All these
changes are measurable. It may be challenging to design and perform process measures,
but all changes are measurable [63]. If they are not measureable, then they have no
impact at all and the project should not be done.


111
4.5.2 Generic Process Frameworks
Process measures are to some extent dependent on the specifics of a particular project.
For instance, the measures appropriate for projects related to security will differ from
projects related to transactional business processes or to projects related to the delivery of
health care services. Several authors [64] [65] have attempted to create generic
frameworks of business processes. From these frameworks, sets of process (operational)
measures can be elicited. These frameworks are seen as ways to identify and elicit
relevant process goals. The following list of generic process goals is compiled from
multiple sources including [64], [65].
Table 22 Generic Process Goals
Category Process Goal
Process Planning and
Support
Improve the process and content of decision making [64],
[65]
Improve Intra-organization communications [64], [65]
Provide better coordination among functional areas in your
corporation [64]
Supplier Relations and
Inbound Logistics
Reduce transaction costs by making it easier for suppliers
to handle orders [64]
Reduce variance in supplier lead times [64]
Enhance the ability to monitor the quality of products and
services from suppliers [64]
Help to gain leverage over suppliers [64]
Help to coordinate closely with suppliers [64]
Reduce the cost of materials [65]
Production and
Operations
Increase the level of production / Improved throughput [64]
Retire systems [65]
Reduce waste / scrap [65]
Reduce headcount [65]
Reduce employee turnover [65]
Improve employee productivity [65]
Improve system uptime
Reduce days of inventory [65]
Reduce rework
Improve product / process quality


112
Product and Service
Enhancement
Reduce time to market [64], [65]
Reduce variance on product/service quality [64]
Facilitate the tailoring of products/services to markets [64]
Reduce the cost of designing/developing new products /
services [64]
Sales and Marketing
Support
Provide support for identifying market trends via analytical
tools [64]
Assist the firm in locating or serving new markets [64]
Enhance the accuracy of sales forecasts [64]
Increase firms ability to anticipate customer needs [64]
Track market responses to pricing strategies, discount
strategies, promotions [64]
Optimize existing markets [65]
Increase cross-selling [65]
Reduce days of receivables [65]
Customer Relations and
Outbound Logistics
Enable your corporation to provide administrative support
to customers [64]
Facilitate a high level of responsiveness and flexibility to
customer needs [64]
Reduce the variance and uncertainty in product/service
delivery times [64]
Increase available information about customers [64]
Help your corporation coordinate with customers [64]
General Risk Avoidance [65]
Reduce capital Hardware/Software expenses [65]
Become vendor of choice [65]
Increase Good Will [65]
Increased flexibility allowing redistribution of resources

4.5.3 Process Measures
Each of the process goals in the proceeding section can be related to quantitative benefits.
Examples are presented below.
Process Goal Improve the process and content of decision making
Examples of
quantification
Example: Reducing losses due to bad loans.
Calculation: reduced percentage of bad loans * number of
loans made * loss per loan




113
Process Goal Improve Intra-organization communications
Examples of
quantification
Example: Assume that one department sent information via
Email to another department who in turn used it to update a
status of a particular transaction and that this process is
being replaced by one that allows the first department to
make updates directly.
Calculation: Number of status send per day * (minutes
spent per transaction in old process minutes spent per
transaction in new process) * (1 work day / number of
minutes per day) * adjusted average labor cost per workday
* scaling factor
Assumption: Some fraction of saved employee time is
directed toward other productive work, as represented by
scaling factor

Process Goal Improve system uptime
Examples of
quantification
Example: New diagnostic software is being deployed to
identify problems with machinery within a factory. This is
expected to reduce downtime,
Calculation: Number of machines * reduction in length of
outage (hours)* number of units produced per hour * revenue
per unit
Assumptions: Equipment is currently 100% utilized, so
increased production due to decreased downtime is desirable.

Process Goal Provide better coordination among functional areas in your
corporation
Examples of
quantification
Example: Set up of dedicated test servers / regions requires
coordination of multiple groups such as DBA, system
administrators, hardware support groups, messaging groups.
A simple wiki based approach is proposed to reduce the need
for multiple request forms, Emails and phone calls.
Calculation: Number of tests conducted per year * time saved
by consolidated information on a wiki page * adjusted hourly
rate of staff * scaling factor.
Assumption: Some fraction of saved employee time is directed
toward other productive work, as represented by scaling
factor

Process Goal Reduce transaction costs by making it easier for suppliers to
handle orders


114
Examples of
quantification
Example: Electronic integration of internal ordering system
with suppliers order fulfillment systems to reduce manual
processing.
Calculation: Number of orders placed * time saved by not
manually processing * adjusted labor rate * scaling factor +
Number of incorrect orders * (time per reorder + time in return
processing) * adjusted labor rate.*scaling factor
Assumptions: Some fraction of saved employee time is
directed toward other productive work, as represented by
scaling factor.
Note: There may be additional benefits if reduction in
incorrect orders results in more output due to having fewer
delays due to needing to wait for materials to arrive.

Process Goal Reduce variance in supplier lead times
Examples of
quantification
Example: Electronic integration of internal ordering system
with suppliers order fulfillment systems to reduce manual
processing.
Calculation: Increased number of units produced * revenue
per unit
Assumption: Erratic delivery of supplied was leading to lost
production. Construction of products were delayed waiting
for supplies.

Process Goal Enhance the ability to monitor the quality of products and
services from suppliers
Examples of
quantification
Example: Deployment of automated testing software to test
circuit boards prior to use in assembly of products.
Calculation: Percentage of defective circuit boards * cost of
rework per unit produced.

Process Goal Help to gain leverage over suppliers
Examples of
quantification
Example: A system supporting comparison of products and
prices across suppliers could allow discounts to be negotiated.
Calculations: Cost savings per input * number of inputs used
per period.

Process Goal Help to coordinate closely with suppliers
Examples of Example: Electronic integration with supplies lowering


115
quantification transaction cost on orders and reduced time to supply resulting
in lower inventory requirements
Calculation: Savings per order * number of orders made
Calculation: Dollar amount of reduction in inventory * cost of
capital per period.

Process Goal Increase the level of production / Improve Employee
Productivity
Examples of
quantification
Example: Automation of business process
Calculation: Time saved per transaction (hours) * number of
transactions * adjusted hourly rate of employees * scaling
factor
Assumptions: Some fraction of saved employee time is
directed toward other productive work, as represented by
scaling factor.
Example: Automation of factory equipment
Calculation: Increased number of units produced * revenue per
unit


Process Goal Reduce the cost of materials
Examples of
quantification
Example: Ordering system integrated with suppliers
Calculation: Percentage discount * total cost of orders per
period.
Assumption: Suppliers will offer a discount because of lower
costs on their end.

Process Goal Retire system(s)
Examples of
quantification
Example: Implementation of new system allows retirement of
old system(s)
Calculation: Hardware Costs (Old System) Hardware Costs
(New System) + (Full Time Equivalents (Old System) Full
time Equivalents (New System) * Adjusted labor rate per year
* years of service of new system.
Assumptions: New system is less costly.

Process Goal Reduce waste / scrap
Examples of
quantification
Example: Factory automation reduces scrap / waste
production


116
Calculation: Reduced disposal costs

Process Goal Reduced Headcount
Examples of
quantification
Example: Automation of business process
Calculation: Number of headcount reduced * adjusted cost
per period
Calculation 2: Number of hours saved per day per employee /
number of hours per work day * adjusted daily rate of pay *
days in period * scaling factor
Assumptions: Some fraction of saved employee time is
directed toward other productive work, as represented by
scaling factor.

Process Goal Reduce employee turnover
Examples of
quantification
Example: Improved access to information about employee
benefits via new intranet site increases employee satisfaction
and decreases employee turnover.
Calculation: Total number of employees * reduction in
turnover rate * training costs for new employee
Assumption: Current employee headcount is required to
support business and new employees face a significant
learning curve.

Process Goal Improve system uptime
Examples of
quantification
Example: Better production monitoring software to minimize
production outages.
Calculation: reduction in down time (hrs) * units produced
per hour.
Assumption: Lost production time cannot be compensated for
by unpaid overtime for employees or increased rate of
production.

Process Goal Reduce days of inventory
Examples of
quantification
Example: Inventory control system supporting monitoring of
actual inventory levels and allowing lower levels of inventory
to be stored.
Calculation: Reduced level of inventory (dollars) * cost of
capital.
Notes: Relevant for both reduction in supplies needed for


117
input and in inventory of finished product.

Process Goal Reduce rework
Examples of
quantification
Example: Automation of manual processes leads to lower
error rates.
Calculation: Number of defective units * cost of repair per
unit
Calculation 2: Number of defective units * (cost of
manufacturing + cost of disposal) for unsalvageable units
Calculation 3: Number of times process is run per day *
reduction in error rate * process time (hrs) / number of hours
per workday * adjusted daily labor rate * scaling factor.
Assumptions: Some fraction of saved employee time is
directed toward other productive work, as represented by
scaling factor.

Process Goal Improve product / process quality
Examples of
quantification
Example: Automation of manual processes improving quality.
Calculation: Increased customer reorder rate * revenue per
unit
Note: See reduce rework for additional examples
Assumption: Higher quality products increase customer
satisfaction leading to higher reorder rate.

Process Goal Reduce time to market
Examples of
quantification
Example: Deployment of better or integrated software
development tools reduces time to market.
Calculation:
Assumptions: New tools do not become shelfware. Early entry
into market leads to at least a temporary increase in market
share.

Process Goal Reduce variance on products/service quality
Examples of
quantification
Note: See Improve product / process quality
Assumption: Customers care about variance in quality as well
as mean. Note 2: In some cases quality variance may be more
significant than the mean quality. A small percentage of
highly defective units (good mean quality with high variance)
can change customer perceptions more than a large percentage


118
of slightly defective units (average mean quality with low
variance) in some cases.

Process Goal Facilitate the tailoring of products/services to markets
Examples of
quantification
Example: System improvements allow production of
customized output or customization of processes to better
satisfy customers.
Sample Calculation: Increased number of units sold * cost per
unit.

Process Goal Reduce the cost of designing/developing new products or
services
Examples of
quantification
Example: Integrated development tools
Sample Calculation: Decrease in hours for
design/development * adjusted hourly rate * scaling factor.
Assumptions: Some fraction of saved employee time is
directed toward other productive work, as represented by
scaling factor.

Process Goal Provide support for identifying market trends via analytical
tools
Examples of
quantification
Example: Statistical analysis system allows detection of
market trends and allows greater investments in growing
market segments.
Sample calculation: Projected increase in sales * revenue per
unit.

Process Goal Assist the firm in locating or serving new market
Examples of
quantification
Example: See Provide support for identifying trends via
analytical tools

Process Goal Enhance the accuracy of sales forecasts
Examples of
quantification
Example: See Provide support for identifying market trends
via analytical tools



119
Process Goal Increase firms ability to anticipate customer needs
Examples of
quantification
Example: See Provide support for identifying market
trends via analytical tools

Process Goal Track market responses to pricing strategies, discount
strategies, promotions
Examples of
quantification
Example: See Provide support for identifying market trends
via analytical tools

Process Goal Optimize existing markets
Examples of
quantification
Example 1: See Increase cross-selling
Example 2: See Provide support for indentifying market tends
via analytical tools

Process Goal Increase cross-selling
Examples of
quantification
Example: CRM (Customer Relationship Management) system
allowing better cross selling, that is, the selling of other
products to current customers of one of the firms products.
Sample Calculation: Increased sales of product X to current
customers of product Y * revenue per sale of X.
Note: This increase can be determined in a pilot study
comparing the results of sales staff with access to the CRM
system to those without.

Process Goal Reduce days of receivables
Examples of
quantification
Example: New accounts receivable or billing system that
allows increased collection rates, tracks missing or late
payments to allow better collections and reduces errors in
billing.
Calculations: Number of days receipt of payment is earlier *
amount received * interest rate for risk free investment
Note: risk free interest rate is used to produce a conservative
estimate of revenue.



120
4.5.4 Use of Process Measures
Hubbard [63] presents valuable practical advice on how to perform process measures.
The following approach is based on the techniques presented in that work.
1. Review the list of generic process goals presented in section 4.5.2 Based on the
requirements of the project being evaluated, identify relevant process goals.
2. Review the related process measures presented in section 4.5.3.
3. Initially to evaluate a project, estimates are needed. Single point estimates are
particularly inaccurate. Estimates of upper and lower bounds are more accurate
and more reasonable to use
3
. Hubbard [63] suggests that estimators can be trained
to produce good estimates of bounds.
4. A confidence interval is an estimate of a range in which is expected to contain a
parameter [66]. A 50% confidence interval is a range that is expected to contain
the parameter 50% of the time.
5. Estimates of the 10% and 90% confidence intervals should be obtained. As an
example, suppose a business process is being automated to reduce headcount.
The 10% confidence interval might be 10 headcount. This means that there is only
10% confidence that the true value of headcount savings will be 10 or less. The
90% confidence interval might be 2 headcount. This means that there is a 90%
confidence that the true value of headcount savings will be 2 or less. A bounded
estimate is produced.
6. Using the estimates from the confidence interval, one of the following approaches
can be taken.
a. Calculate the process measure using the 10% and 90% estimates. An
average of the two can be used or the lower estimate can be used as a
worst case estimate.
b. A Monte Carlo simulation can be done.
i. A distribution must be assumed. For many processes, Gaussian or
uniform distributions are appropriate
4
.
ii. Using the 10% and 90% confidence intervals and the assumed
distribution, Monte Carlo simulations can be performed.

3
Validation of this statement by a review of literature or by empirical study is beyond the scope of this
work, but based on personal experience it is likely true.
4
The correct choice of a distribution is significant to producing correct results, but it is beyond the scope of
this work.


121
iii. Monte Carlo simulations are very useful to understand the total
benefits from several independent sources (independent random
variables).
7. The benefit estimates from step 6 can be used as input into the financial measures
covered in this chapter.

4.5.4.1 Example of Approach
Suppose a firm is automating its billing process. The current process for invoicing
customers is manual and time consuming. Clerks manually prepare each individual
invoice. Clerks perform multiple duties each day; only part of their day is spent
preparing invoices. A software project is being evaluated to automate this process. A
quantification of expected benefits is needed to justify the cost of the project.
1. After a review of 4.5.2, the benefits of this project are most likely derived from
improved employee productivity.
2. From section 4.5.3, the following measurement is suggested:
Time saved per transaction (hours) * number of transactions * adjusted hourly
pay rate of employees * scaling factor

a. The average number of invoices prepared per day is a quantity that can
be accurate determined from corporate records. Assume it is 300 per day
for this example.
b. The current time spent preparing each invoice manually can be measured
by observation of the current process. Assume it is hour.
c. The average adjusted hour pay rate for clerks is known. Adjusted means
that is considers the costs of all benefits, not just salary. Assume it is $20
per hour.
d. Since only part of each clerks day is spent doing productive work, all
time savings from automation will not be directed toward other
productive work. Clerks may not use all time savings productively.
Assume only 50% of the time savings will be redirected toward
productive work.
e. An estimate must be done of the time to prepare an invoice using the new
system. Assume the 10% confidence interval is 5 minutes (1/12 hour)


122
and the 90% confidence interval is 10 minutes (1/6 hour). There is
10% confidence that the invoices can be prepared in 5 minutes or less
using the new system. 90% confidence that invoices can be prepared in
10 minutes or less using the new system.
f. Translating the estimates: There is a 10% confidence that the time
savings will be 30 10 = 20 minutes per invoice. There is a 90%
confidence that the time savings will be at least 30 5 = 25 minutes per
invoice.
3. Calculation of financial benefit lower and upper bounds, average
Lower bound:
20/60 hours/transactions * 300 transactions/day * 1 day/8 hours *
$20/hour * 0.5 = $125 saved/hour = $1000/day
Upper bound:
25/60 hours/transactions * 300 transactions/day * 1 day/8 hours *
$20/hour * 0.5 = $156.25 saved/hour = $1250/day
Average: (1000 + 1250)/2 = 1125 saved/day = 250000/year based on a 220 day
year.

4. A NPV calculation can be performed to evaluate whether the automation project
should be done. Assume the following:
a. The risk free interest rate is 5% per year or 0.0137% per day. The
appropriate discount rate for projects of this nature and risk is 15% per
year or 0.0411% per day.
b. Cost estimates for the project are $500000. Assume this will be paid
evenly over six months. This cost will be distributed over 6 months of
calendar days to simplify the NPV calculation even though cost may
actually occur on business days only. 500000/183 days = 2732/day.
c. The savings of 1125/business day (assume there are 220 business days
per year) will begin in 6 months and will continue for five years after
which the system will need to be retired and replaced. Since the yearly
savings are 250000, to make the NPV calculation more tractable without
special software, assume the benefits are 250000/365 = 685 per calendar
day. Benefits start in day 184 and continue to day 2009, five years later.



Equation 39 NPV Calculation for Process Measurement Example


123
NPV = -493000 + 1079000 = 585000

d. Given the large positive NPV, the project is worth conducting. Some of
the simplifications done, such as working in calendar days rather than
business days and rounding some intermediate numbers will not impact
this result that the project should be done. The NPV is large enough that
even errors due to these simplifications, the true NPV will also be
positive.
5. A Monte Carlo simulation can be done to show the range of possible benefits.

4.6 Discussion
Discounted cash flow/NPV analysis suffers from a major flaw. Each project is evaluated
without regard to managerial flexibility. It is assumed that the entire project will be
conducted exactly as planned and exactly when planned. There is no consideration of
modifying the course of the project as more information is revealed or as events unfold.
Simple examples of this include the ability to expand or contract the project, delay the
project or even cancel based on how events unfold. NPV techniques tend to undervalue
projects. The flexibility to limit losses or take advantage of opportunities increases the
value of projects.
NPV/discounted cash flow techniques look at project value in terms of an absolute
number. IRR reduces value to an interest rate. Payback period reduces value to a time
period. All three can be combined to get an understanding of project value. They are
three views into the same set of numbers.
Decision trees incorporate managerial choices, but are deficient in several aspects. First,
as the number of decision points grows, they quickly become unmanageable with more


124
and more branches to keep track of. A second deficiency is that it necessary to
estimate probabilities of possible outcomes. The trees require information such as a 0.25
chance of one cash flow and a 0.75 chance of another. At best, these probabilities are
estimates. At worst, they are guesses. A third, more subtle, flaw in decision tree analysis
is that typically the same discount rate is used for all branches. Whether nature is
friendly and the best possible outcomes occur, for instance, the maximum cash flows are
achieved or nature is against us, the same discount rate is used. This is equivalent to
assuming that project risk is unchanged even though as more information is uncovered,
project risk changes.
Real options are a technique where the mathematics of financial options is applied to the
valuation of projects and capital asset investments. This analysis helps management
decide whether there is value in delay, expansion, contraction or abandonment of the
project. Real option techniques capture the value of flexibility, the value of changing the
course of the project based on additional information as it progresses. One fault in real
option approaches is that they only examine the project by itself. The effects of the
outside world and particularly of competitors are not included.
Game theory provides means to reason about competitors and about competition in the
market. It is relevant for large strategic types of projects such as entering new markets,
new businesses or introducing entirely new products.
Process measures were seen as a means to quantify financial value in internal projects
which ultimately allows application of the financial techniques described in this chapter
to be used on both projects producing a product for sale and for internal projects.


125
Strengths and limitations of these approaches are listed in Table 23. The strengths
and limitations listed are based on [67] [68] [69] [70].
Table 23 Strengths and Limitations of Financial Valuation Techniques
Financial Valuation
Technique
Strengths Limitations
Net Present Value Easy Calculation
Quantifies benefit of project
as a single absolute number
(profit).
Considers time value of
money.
Considers risk (via discount
rate).
Length of time not
considered.
Rate of return not
considered.
No accounting for
managerial flexibility.
No consideration of market
or competitors.
Under values risky projects
(by not considering
flexibility)
Internal Rate of Return Easy Calculation
Considers time value of
money.
Easy to understood (simple
percentage)

Length of time not
considered.
Risk not explicitly
considered.
No accounting for
managerial flexibility.
Under values risky projects
(by not considering
flexibility).
No consideration of market
or competitors.
No consideration of
absolute amount.
Payback Period Consideration of time.
Easy to understand.
Implicit consideration of
risk (Favoring quick
payback lowers risk).

Ignores revenues after
payback period.
Considers only time, not
absolute amount or
percentages.
No accounting for
managerial flexibility.
No consideration of market
or competitors.
Real Options Considers managerial
flexibility.
Realistic valuations of risky
or uncertain projects.
Complex calculations.
Difficult to understand.
No consideration of market
or competitors.


126
Captures value of delaying
until uncertainty is resolved.
Game Theory Approaches Considers competition and
market factors.
Captures value of early
entry into competitive
markets.
Very difficult to fully
understand markets and to
predict the actions of
competitors.
Only applies for strategic
projects where competitors
exist and matter.

The applicability of these techniques is to a large extent driven by the nature of the
project. This is illustrated below in Figure 24.



127
Is this a large strategic project
where an understanding of
competitors and the market is
crucial?
Is there uncertainty about
future cash flows or flexibility
to chance course based on
events?
Proposed Project
No
Use Basic
Financial
Measures (NPV,
IRR, payback
period)
No
Use Game Theory
Approaches
Use Real Option
Analysis
Yes
Yes

Figure 24 Impact of Nature of Project on Selection of Financial Measures


128
Chapter 5

Qualitative Approaches to the Measurement of Value
5.1 Overview
The techniques discussed in section 3.3 and Chapter 4 suffer from a common defect.
They examine each project independently. Each project was evaluated as if there were
unlimited access to capital and resources, as if there were no conflicts with other projects
or with respect to corporate strategy and is if there was no overlap or synergy with other
projects. The value of each project was evaluated independently.
There is uncertainty in quantitative measures. Costs and revenues are uncertain. How
markets will develop is uncertain. Projects have multiple objectives, dependencies on
other efforts and it is often unclear how to measure benefits [71]. Stakeholders value
propositions and utility functions vary. Qualitative measures can compensate for a lack
of confidence in financial measures such as ROI. [72]
The financial analysis techniques evaluated whether each project increased the wealth of
the firm, that is, whether it had positive net present value. If it is assumed there is
unlimited access to capital for projects, should all projects with positive NPV be
conducted? No.
Even with unlimited capital (money), other resources are limited. There are limits
on the number of available skilled employees.
Attempting to increase the number of resources available beyond some limit is
difficult and probably unwise. The labor pool limits the number of potential
resources. And even if the labor pool was unlimited, there are limits to the
number of new resources that can be successfully integrated in a given time
frame.


129
Suppose there is sufficient capital and other resources, should all projects with
positive NPV be conducted? No.
There are possible conflicts with the goals and requirements of other projects.
The techniques explored in section 3.2 looked at ways to determine and satisfy
stakeholder value propositions of stakeholders of a single project. The imperfect
knowledge of the stakeholders of an individual project about other efforts the firm
is conducting leads to the possibility of conflicts between projects and of lost
opportunity for synergy due to overlap between projects.
Even if it is assumed that an extraordinarily job was done in requirements, that all
potential stakeholders have been included, that all conflicts and overlap with other
projects have been uncovered and accounted for, that all capital and resources are
unlimited, should all projects with positive NPV be conducted? No.
At the core, the project may be at conflict with overall corporate strategies.
Microsoft could conceivably conduct profitable projects to produce crackers,
sardines and toy guns. These are probably unaligned with corporate goals and
strategy.
Given that a firm cant and shouldnt conduct every profitably project, which should be
conducted, how should the success of those projects be measured and how should those
projects be monitored and controlled to achieve success. Balanced score card techniques
are considered in section 5.2 as a way to analyze project alignment with corporate
strategy. Project portfolio techniques are considered in section 5.3 as a means of
evaluating project conflicts and synergies with other projects.
5.2 Balanced Score Cards
5.2.1 Introduction
Financial measures, while critical in measuring value at the project, program and overall
corporate level, cannot alone guide an organization toward its strategic goals. Financial
measures have limitations. First, they tend to be backward looking or lagging. That is,


130
they are a measure of what has occurred, not what can be achieved or how additional
value can be created. A second criticism is that there is no explicit linkage between
financial measures and the corporations strategic goals and that there is no linkage
between the financial measures and strategic goals with operational changes and with
programs and projects. The balances scorecard provides a framework to map the
organizations strategic goals into concrete measures and to link those measures to
individual projects.
The balanced scorecard is a technique that allows modeling, measurement and
understanding of financial measures to be combined with measures of value in other
dimensions. It provides a concise summary of value along several dimensions. By
considering value along several dimensions, certain types of sub-optimizations are
avoided. A simple example is that of achieving an objective of reducing time to market.
Within the software industry this could conceivably be achieved by lowering quality
standards. Thus, reduced time to market could be achieved at the expense of other goals
such as customer satisfaction or having a loyal customer base for future products. This
can be summarized by Even the best objective can be achieved badly [73].

5.2.2 Traditional Balanced Scorecards
The balanced scorecard technique as developed by Kaplan and Norton [73] measures
performance along four dimensions or perspectives. Measures, sometimes referred to as
key performance indicators, KPIs, are developed to understand performance in each
perspective:


131
Financial Perspective
Customer Perspective
Internal Business Perspective
Innovation and Learning Perspective
The customer perspective is an external view of the organization. What do customers
think about the organization; what do they value? A key point here is that source of
value and its measurement is defined by the customer. It is what they value and should
be determined by them, not internally. The sources of value can be identified via surveys
and via feedback from external parties. Measurement of value in this perspective should
also be done externally, either by the customer directly, or via a third party evaluations by
government agencies or external third parties, such as industry groups or companies such
as JD Powers or Gartner who specialize in producing comparative measurements of
performance. Having the customer define value is analogous to requirements
engineering techniques that look to identify all stakeholders and have them define their
requirements.
The internal business perspective looks at current processes and their measures. Broadly,
this perspective can be divided between processes whose aim is achieving customer
satisfaction and core competencies. Core competencies for an organization might include
design and manufacturing. For software organizations manufacturing competency could
be seen as the ability to produce high quality, low defect software.
The innovation and learning perspective looks at measures of how well the organization
expands its capabilities and those of its employees. Long term, the only way that an
organization can grow is to launch new products and expand into new markets. This


132
perspective measures the organizations processes that support this expansion by
improving staff.
It is interesting to note that the perspectives have different temporal focuses. The
financial perspective measures how well the organization has done. The customer and
internal business perspectives examine the present time; how well customer needs are
currently being met and how well the organization is currently functioning. The
innovation and learning perspective looks forward at how the company is organizing to
achieve longer term strategic goals and to expand.
The financial perspective, as stated earlier, is really a backward look at how the company
has performed with respect to the bottom line. But, it serves a critical purpose. It
provides a reality check on the other three perspectives. The customer, internal business
and innovation and learning perspectives in some sense are hypotheses. The ultimate
goal of the business is financial success; the achievement of increased value for
stakeholders. The success of any initiative in the other dimensions is ultimately
measured in the financial perspective. Kaplan [73] notes the hard truth is that if
improved performance fails to be reflected in the bottom line, executives should
reexamine the basic assumptions of their strategy and mission. Not all long term
strategies are profitable strategies.
A key benefit of balanced scorecard approaches is that they provide a framework for
explicit linking between operations and finance. The act of modeling, of creating
balanced scorecards can add value as consideration is given as to how initiatives and
projects in the other dimensions translate into performance in the financial perspective.


133
5.2.3 Linking Strategy to Measures
The relationship between measures and strategy can be seen as bidirectional. The
balanced scorecard can be seen as a set of measures that indicate progress toward a
strategy. Looking in the other direction, an interesting observation is that people are
motivated and influenced by the measurements made. The measures themselves
influence performance. Carefully selected measures can guide the organization toward
completion of its strategic objectives. The taking of measurements establishes goals for
individual employees and can guide performance.
The balanced scorecard displays a set of measurements. An implicit assumption is that
there is a causal relationship between the measurements and successful implementation
of the strategies they support. For instance, suppose a software company selling shrink
wrapped software to retail customers has a strategic objective to increase profit. Assume
that higher sales will increase profit. Sales can be measured in terms of number of units
sold. Assume that reducing the defect rates will increase customer satisfaction and
ultimately increase sales. The operational measure of defect rate is a measure supporting
the strategic objective of increased sales. Defect rates can be measured in defects per
thousand lines of code. Customer satisfaction can be measured (subjectively) using
surveys and a numeric scale. The next question becomes how a lower defect rate can be
obtained. Assume that developer education can achieve this. That is, developer
education causes a lower defect rate. Developer education could be measured in hours of
training per developer. The causal relationships, measurements and perspectives can be
summarized as follows.
Strategic Objective: Increased sales (Financial Perspective)


134
Table 24 Causal Relationships Supporting Strategic Objective of Increased Sales
Relationship Measurement Perspective
Better educated developers
produce code with fewer
defects
Hours of training per
employee
Innovation and Learning
Perspective
Fewer defects increase
customer satisfaction
Customer surveys Customer perspective
More satisfied customers
will purchase more software
Number of units sold Financial Perspective

Here we see three measures supporting one objective. Further analysis might indicate
that a better defined software process will lead to fewer defects in code. Process can be
measured via internal software quality assurance audits.
Table 25 Additional Measure Supporting Strategic Objective of Increased Sales
Relationship Measurement Perspective
Better process produces
software with fewer defects
Percentage of processes
followed as measured in
SQA audits
Internal business
perspective

The process of finding measures may lead to more strategic objectives. For instance,
increased customer satisfaction might be another strategic objective. Following along
the lines of the above analysis, a simple balanced scorecard can be drawn.
Financial Perspective
Strategic Objective: Increase Profit
Measures: Total revenue
Total costs
Number of units sold
Business Process Perspective
Strategic Objective: Better Quality Code
Measures: Defect rate (defects per KLOC)
SQA Audit results (percent
compliance)


135
Customer Perspective
Strategic Objective: Higher customer
satisfaction
Measures: Customer surveys
Innovation and Learning Perspective
Strategic Objective: Better trained staff
Measures: Training hours per employee
Figure 25 Organizational Balanced Scorecard Example
This process also shows the benefits of modeling. The process of finding causal
relationships and trying to form hypothesis between operational changes (such as
training) and achievement of strategic objects (which can also be called goals) lead to the
discovery of more strategic objectives and iteratively leads to more measures.
Measurements, also known as indicators, can be leading or lagging. Leading indicators
are indicators that show changes before the strategic objective is obtained. For instance,
a lower defect rate would be seen in advance of increased customer satisfaction. Leading
indicators are also called performance drivers. The act of measuring defect rate will
encourage developers to test more carefully (perhaps). Leading indicators also give early
feedback on the success or lack of success toward achieving strategic goals. Lagging
indicators are measurements of the achievement of the strategic objective. Lagging
indicators are also referred to as outcome measures. For instance, total revenue and total
cost are direct measures of profit (neglecting the intricacies of accounting and tax codes).
A successful balanced score card will have both leading and lagging measures.
Outcome measures without associated performance drivers do not show how the outcome
will be achieved. For instance, for the outcome measure of defect rate, associated
performance driving measures such as measures of staff education or measures of use of


136
testing tools must be established. Without them, the outcome measure may not be
achieved. [74] [75].
Performance drivers not linked to outcome measures have no demonstration of value.
For instance, measurements of staff education will drive line level managers to arrange
training for staff. Without a causal link to an outcome measure such as higher
productivity, lower defect rate or higher staff retention, the value of this training cannot
be established [73] [75].
5.2.4 Balanced IT Scorecards
The example developed in the previous section described applying a traditional balanced
scorecard approach to a company whose business was primarily producing software for
purchase. A more common case is that of an organization that engages in a business
other than software, but has internal groups dedicated to producing specialized software
to support the organizations business. In this case, the business has overall strategies and
goals that are not focused on software but are instead focused on goals for the overall
business. The internal software groups with the larger organization serve to support and
enable overall business strategies.
Similar to the way the software group can be thought of as enabling the larger
organization to achieve its strategy, its possible to construct an IT specific balanced
scorecard that can be shown to enable the strategies of a traditional balanced scorecard
and thus the strategies of the larger organization [75] [76]. Grembergen describes a
hierarchy of scorecards with the lower levels supporting or enabling higher levels. From
[75]:


137
Business
Balanced Scorecard
IT Strategic
Balanced Scorecard
IT Development
Balanced Scorecard
IT Operational
Balanced Scorecard

Figure 26 Balanced Scorecard Cascade [75]

In [75], a case study of the application of this approach as used by a group of Canadian
insurance companies is presented. This example is presented below as an illustration of
this technique.
The first step in this process is to establish who the key stakeholders are and their value
propositions. This is expressed in [75] by considering the key questions each stakeholder
group would ask to determine satisfaction of their value propositions. From [75]:
Stakeholders Key Questions
Board of Directors
Executive Management Committee
What value does IT deliver?
Does IT enable or retard business goal
achievement?
Does IT advance organizational innovation
and learning?
Is IT well managed?
Line of Business Management Are we getting value for our IT


138
Customers (internal users) investments?
How does IT influence the customer
experience?
Does IT favorably affect productivity?
Is IT positioning the group (line of
business) for future market demands?
Audit and Regulatory Are the organizations assets and
operations protected?
Are the key business and technology risks
being managed?
Are proper processes and controls in place?
IT Organization Are we doing the right things for the
business and employees?
Are we effective and efficient?
Where do we need to improve to meet our
goals?
Have we satisfied all key stakeholder
interests?
Can we attract/retain the talent we need to
meet business needs?
Are we fostering a culture of innovation
and learning?

To address these questions an IT balanced scorecard was established. Its objectives were
to demonstrate the value added by IT, link operational plans to IT strategic goals (as with
any balanced scorecard), and establish, communicate and report measures of IT
effectiveness. From [75], the following IT balanced scorecard was established.
CUSTOMER ORIENTATION CORPORATE CONTRIBUTION
Perspective question
How should IT appear to internal
customers (end users and division
managers)?

Mission
To be the supplier of choice for all
information services, either directly or
indirectly through supplier partnership.

Objectives
Customer satisfaction
Perspective question
How should IT appear to the executive
committees and Boards in order to be
considered a significant contributor to
company success?

Mission
To enable and contribute to the
achievement of business strategies through
the effective application of information
technologies and methods.



139
IT/business partnership
Application development performance
Service level performance
Objectives
Strategic Contributions
Synergy achievement
Business value of IT projects
Management of IT investments
OPERATIONAL EXCELLENCE FUTURE ORIENTATION
Perspective question
At which services and processes must IT
excel to satisfy the stakeholders and
customers?

Mission
To deliver timely and effective IT services
at targeted service levels and costs.

Objectives
Process excellence
Responsiveness
Backlog management and aging
Security and safety
Perspective question
How will IT develop the ability to change
and improve in order to better achieve the
IT and company vision?

Mission
To develop the internal capabilities to learn
and innovate and to exploit future
opportunities

Objectives
Service capability improvement
Staff management effectiveness
Enterprise architecture evolution
Emerging technology research

Sets of measures, not reproduced here, were established to determine satisfaction of the
objectives listed above. As noted earlier, both leading and lagging measures are needed.
The key observation is that this balanced scorecard has components that are specific to
the IT group, those listed in the operational and future orientation. Additionally, there is
a linkage to higher level organization strategies. The satisfaction of the needs of the
supported lines of business is addressed through the customer orientation. The linkage to
overall corporate strategies is made through the corporate contribution perspective.
5.2.5 Corporate Governance
In [77], an application of the balanced IT scorecard approach to achieving corporate
governance is presented. Corporate governance is a set of procedures and policies
established to direct activities toward satisfying the goals of shareholders (primarily,


140
wealth creation). It is an attempt to address the agency problem, where the goals of
internal parties within the corporation may conflict with the goals of the owners
(shareholders).
Shleifer [78] defines corporate governance as: Corporate governance deals with the
ways in which suppliers of finance to corporations (shareholders) assure themselves of
getting a return on their investment. How do the suppliers of finance get managers to
return some of the profits to them? How do they make sure that managers do not steal
the capital they supply or invest it in bad projects? How do suppliers of finance control
managers?
A balanced IT scorecard approach can link IT strategies and objectives back to the
overall corporate strategy. The overall corporate strategy includes a financial perspective
that represents the interests of investors. Balanced scorecards can drive both IT and
business groups through performance drivers (measurement that serve as leading
indicators) and can report performance through output measures (lagging indicators). In
this manner there is assurance that the IT organization returns some business value and
does not invest in bad projects and in the adequacy of IT controls [77].
IT governance can also be achieved through project portfolio management.
5.3 Project Portfolio Management / IT Governance
A portfolio is a collection of projects and programs or other work that are grouped
together to facilitate effective management of that work to meet strategic business
objectives. The projects or programs of the portfolio may not necessarily be
interdependent or directly related [4]. The portfolio exists to achieve strategic goals and


141
consists of both planned and in progress projects and programs. A program is a
collection of supporting projects to achieve some business goals. In this section,
project will be used to indicate either a project or program.
The challenge of portfolio management is twofold:
Select projects that are aligned with the strategic goals of the organization and
optimize financial value subject to resource and time constraints
Monitor and control the selected projects to successful completion. This includes
the possibility of terminating projects that are failing due to poor requirements or
failures in technology selections.
The goal of portfolio management is to ensure that the organization is doing the right
work rather than doing work right [79]. Doing work right is addressed by project
management. As such, the focus is on prioritization and selection of projects, project
governance and tracking and control of projects.
Weill [80] makes the observation that for portfolio management to be effective, all (IT)
investments and expenditures must be included. Weill presents an analogy to a personal
investment portfolio where only new investments are considered, but on-going costs such
as mortgage payments are not. In a similar way, both lights-on on-going maintenance
and infrastructure costs and costs for new development must be considered in a project
portfolio.
Project portfolio management is a means to achieve corporate or IT governance as
described in section 5.2.5.
For the purposes of this thesis, project portfolio management is defined as a set of process
to evaluate, select, prioritize and monitor potential and in progress projects. Key points
include [81]:


142
Aligning the portfolio with corporate strategies
Optimal allocation of capital
Optimal allocation of resources
Risk management, particular focused on risks to achieving strategic goals
Measuring component contributions. That is, measuring the projects within the
portfolio against the other goals
Portfolio management can be seen as a framework within which to conduct the valuation
activities explored in other parts of this thesis. Critical is that it also provides a means to
track and measure achievement of value and to provide feedback into making better
measures of value in the future. This can be done by carefully measuring actual
achievement of value and comparing it with estimates.
The portfolio management process assesses and monitors projects against multiple
criteria to ensure that maintain alignment with strategic and business goals and that only
projects that contribute to the organizations success will be funded [82].
5.4 Alignment with Organization Strategies and with IT Goals and Architecture
The organizational balanced scorecard, section 5.2.2, and the IT balanced scorecard,
section 5.2.4, concisely list the goals and measures of those goals for overall organization
and for the IT department or group respectively. Much of the available literature is
focused on using balanced scored cards to rate the organizations level achievement of
the goals expressed and to drive the organization towards achievement of those goals.
Little work is found in the literature on measuring individual project level requirements
and goals against the higher organization level goals expressed by balanced scorecard
techniques. Studies of techniques for ranking and aligning individual projects against the
goals in organizational and IT balanced scorecards would be a direction for future


143
research. For purposes of this thesis, it is proposed that each project be rated against
a list of measures from the organizational balanced scorecard and against a list of
measures from the IT balanced scorecard. Against each measure a project can be rated as
not-aligned (0), low alignment (1), medium alignment (2) or well aligned (4). A numeric
average of against all measures can be used as the alignment for the project. An example
of this technique is shown in section 3.3 for project critical success factors.
5.5 Discussion
A projects alignment with the goals of the organization and with the goals and enterprise
architecture of the IT group within the organization are seen as additional factors in
determining the value of the project. A survey of the literature found little guidance on
how to relate projects to the higher level goals of the organization and to those of the IT
group. As this is a key factor in project valuation, it would be a useful direction for
additional research.
Use of these factors in the ranking and selection of projects is given in Chapter 6 and
Chapter 7.



144
Chapter 6

A Proposed Multi-Dimensional Framework for Project Valuation
6.1 Introduction
Current practice typically fails to perform adequate valuation of software projects.
Techniques such as the earned value technique measure cost rather than value. When
valuation techniques are attempted, only limited dimensions, such as the financial value
of the project are considered. The valuation of projects must be done in multiple
dimensions using both quantitative and qualitative techniques. Qualitative evaluation can
be done along several dimensions including alignment with overall corporate strategies,
alignment with enterprise architecture / IT strategies and against factors associated with
project success or failure. Corporate and IT strategies can be expressed using balanced
scorecard techniques as seen in section 5.2. Projects can also be evaluated against project
success factors seen in section 3.3. Quantitative (financial) techniques are described in
section Chapter 4. In that chapter, the basic techniques were presented with a focus on
commercial projects with a marketable product. These techniques were extended to
include a quantification of benefits for projects that are strictly internal to the
organization using process measures.
Time is a significant additional dimension. Projects need to be reevaluated at multiple
points in their life cycle. At project initiation, a go/no-go decision is made based on the
high level project scope and benefits described in a business case or alternatively with a
simple project request. After application of good requirements techniques, several of
which are described within section 3.2, more of the cost and benefits of a particular


145
project are understood and known. At that time, it is appropriate to revisit the
business case, make updates based on the latest information and to reevaluate whether to
proceed with the project. In a similar way, project valuation should be done after all
significant stages in the projects life. The business case should be updated and
reevaluated after an initial design is completed, after completion of coding and testing of
an initial version of the product and when the product is ready for deployment. This
approach is sometimes referred to as establishing toll gates or stage gates. At defined
points in its life cycle the project must past toll gates in order to maintain funding to
continue. The process framework required to evaluate projects relative to each other and
against predefined yardsticks is the domain of portfolio management. A defined
repeatable process, as prescribed by portfolio management techniques, is an essential
element of project valuation. Portfolio management was examined in section 5.3.
Additionally, although rarely done, post deployment and throughout the operational life
of the product, the actual benefits and maintenance costs should be tracked to allow
feedback into the evaluation and portfolio processes. Without feedback using actual
measurements, process improvement attempts are at best guesses. This feedback can be
incorporated as part of a portfolio management process.



146
6.2 Overview of the Framework
The proposed framework for project valuation evaluates projects along multiple
dimensions.
6.2.1 Portfolio Based Approach
The proposed framework uses a portfolio based approach. Multiple portfolios are
established and funded based on the type of firm and the goals of the firm. Each receives
a percentage of the total available funding. Firms can direct investments by varying the
percentage each portfolio receives of the total funding. Each project is ranked and
evaluated against others within the same portfolio.
6.2.2 Quantitative (Financial) Measures
The choice of inputs into financial measures and the types of uncertainties present are
dependent on the projects supplier and customer and on the nature of the project.
Internal projects use process measures to determine future revenues or cash flows.
External projects depend on sales and marketing forecasts.
6.2.3 Qualitative Measures
Projects have different value for different stakeholders. Each stakeholder has their own
sources and measures of utility. Additionally, there is always uncertainty and potential
errors in quantitative calculations. Due to these factors, it is important to consider
qualitative measures such as alignment with the firms strategic goals and IT goals and
architecture. Evaluation against project critical success factors can be seen as a measure
of the risk that the project will not be successful.


147
6.2.4 Iterative Nature of the Process
Valuation should be redone as the project progresses. More details are understood and
uncertainties are resolved. At various points in the life of the project, it should be
reevaluated and should continue only if it is still attractive relative to other potential
work.
Post completion assessment of the project should also be done to evaluate the accuracy of
the valuation process. This is an important part of potential process improvements.
6.3 Project Evaluation Framework
The proposed project evaluation framework is shown below in Figure 27. It is described
in section 6.4.


148
Determine type of
project and
relevant portfolio
(Section 7.6.3)
Evaluate with
respect to Critical
Success Factors
(Section 3.3)
Evaluate with
respect to
Organizations
Strategic Goals
(Section 5.4)
Evaluate with
respect to IT Goals
and Architecture
(Section 5.4)
Cost Estimates for
Project
Estimates of
maintenance and
support costs
Process Measures
(Chapter 3.3)
Sales or Marketing
Forecasts
Is Project for
External Sale?
Financial
Measures
(Chapter 4)
Track success of project
against financial measures,
success factors, organization
goals and IT goals
End Project?
At Project End or
Cancellation, measure
success against Project
Evaluation with respect to
Organization and IT Goals.
Process Improvement Efforts
No
Yes
No
Rank project against other
potential projects within its
portfolio
Yes
Proposed Project
Determine Nature
of Project. Select
Relevant Financial
Measures (Figure
24)
Understand
Perspective of
Project
(section 6.3)
Type of Firm
(section 6.8)
Strategic
Goals of
Organization
(section 5.2)
Determine portfolios and
relative funding of each
portfolio
(section 6.3)
Is Project within
Investment
Boundary?
(section 6.9)
Yes
Dont Conduct
Project
No

Figure 27 Project Evaluation Framework


149
6.4 Project Valuation Process
0) The establishment of separate portfolios for different classes of projects is
necessary as a precursor to the process. The funding and establishment of
different portfolios are influenced by the type of firm (section 6.8) and by the
strategic goals of the organization (section 5.2).
1) The first step in the process is to classify the project into one of the established
portfolios. Project portfolios are discussed in section 6.7 and a proposed set of
portfolios is given in section 6.7.3.
2) It is necessary to understand the perspective of the project. It is being evaluated
by an organization supplying software or an organization purchasing software. Is
the product for sale or internal use? If for sale, is it for the general market or a
particular customer. The approach for the quantitative valuation of projects
producing software products for sale in the general market or to particular
customers is fundamentally different from the quantitative valuation of projects
producing software products for internal use by the firm. These key distinctions
determine what measures serve as inputs into the calculation of value. The
perspective is seen as determining the relevant inputs into quantitative
calculations. (see section 6.5)
3) The choice of which financial calculations apply is dependent on the nature of the
project. If it is strategic in nature and dependent on external markets and
competition then game theory approaches may be useful. If there are
uncertainties or if there is flexibility, then option techniques can be applied. For
projects addressing internal needs with more certain scope and benefits, basic
financial measures are applicable. The nature of the project is seen as
determining the type of relevant quantitative calculations. See Figure 24 and
section 4.6. There is also a dependency on the perspective of the project. See
section 6.5.
4) The quantitative (financial) valuation can be compared against the investment
boundary. If the risk is unacceptable for the level of return, the project should
simply be rejected. See section 6.9.
5) Financial measures of a project are simply one dimension of its evaluation. Other
dimensions, more subjective in nature, are also significant. Other dimensions
include strategic alignment with organization goals (section 5.4), alignment with
IT goals and architecture (section 5.4) and chance of project success based on
critical success factors (section 3.3). Also see section 6.6.
a. The strategic goals of the organization can be expressed using a balanced
scorecard.
b. The goals of the IT department and enterprise architectural can also be
expressed via a balanced scorecard approach.


150
c. Evaluation can be done against lists of project critical success factors.
d. These evaluations can be done with simple ranking schemes.

6) Each project should be ranked against other potential projects within the same
portfolio by combining quantitative and qualitative evaluations. The relative
significance of each dimension of evaluation would need to be evaluated
empirically.
7) Projects may be ranked by presenting data within a simple table or visually.
Assuming that a project portfolio approach is taken, projects are classified by type
into a particular portfolio. Within each portfolio projects are relatively ranked.
For visual representation of project data, bubble plots can be used. Bubble plots
as a valuation technique are presented in [83]. One possible visualization scheme
is to represent project financial return, for instance, ROI or NPV, as the size of the
bubble on these plots. Project risk can be represented as the color of the bubble.
Higher risk projects will appear as red, medium risk projects will appear as
amber, low risk projects will appear as green. The mapping of risks to these
colors will be dependent on project type.

The axes of the bubble plots can be chosen to represent either alignment with the
organizations goals, alignment with IT goals and enterprise architecture,
satisfaction of project critical success factors and project urgency/timeliness. The
dimension of urgency/timeliness can be used to represent the delay in conducting
the project. Some projects may address opportunities that vanish if not addressed
quickly. Two of these dimensions can be examined at a time in a single bubble
plot. By plotting different dimensions, different perspectives of project value can
be obtained.
8) Projects should be reevaluated as they progress. Based on this reevaluation, they
may continue or be cancelled.
9) Metrics collected during and after the project can serve a role in process
improvement efforts.

6.5 Effect of Supplier and Customer Types
The complicated nature of the task of project valuation can be simplified by categorizing
projects and by understanding the organizations involved in producing and consuming
software. Certain valuation techniques will be seen as more applicable to certain classes


151
of projects. At the highest level, the first aspect that must be understood is that value
is dependent on perspective. The value of a project for the developing organization or
supplier is distinct from that of the customer organization. Any attempt to measure value
must begin by answering value for whom?.
With respect to the supplier, two classes are readily apparent: external supplier and
internal supplier. An external supplier is an outside organization seeking to sell software
and services to customer firms. An internal supplier is department or group within the
firm.
Who is the
supplier?
External Firm
Internal Group or
Department

Figure 28 Supplier Types

The value proposition of an external supplier is potentially conflicting to those of the
customer. The supplier will rationally seek to maximize its obtained value by seeking the
optimum combination of number of sales and revenue per sale without regard to the value
sought or obtained by the customer. Value is delivered to the customer only as a
byproduct of the suppliers desire to establish repeat business, desire to improve
reputation and good will to obtain other customers or as a contractual obligation. Win-


152
Win techniques, described in section 3.2.4, attempt to address this conflict by
establishing conditions where the value proposition of supplier and customer become
aligned. It is unclear whether or when Win-Win approaches involving multiple
organizations result in more value obtainment for each involved party or whether more
value is ultimately obtained when each party selfishly seeks its own goals.
For the supplier, this points to a choice between establishing long-term mutually
beneficial relationships with customers and trying to maximize revenue and profit
without regard to particular customers. For the customer, this points to a choice between
tough negotiations techniques to establish lower costs or the establishment of long term
mutually beneficial relationships with suppliers at potentially higher costs, but with more
value or benefits. Establishing the validity of Win-Win approaches is beyond the scope
of this work.
The goals of internal software development groups and those of their customers, internal
business groups ideally are better aligned. Both should seek to maximize value for the
owners of the firm. This can be achieved by systematic valuation of projects and relative
evaluation of projects through portfolio techniques. Internal groups, both software
development groups and business groups, can, of course, have value propositions that
differ from the goal of maximizing value for the firm. This is known as the agency
problem. Although not investigated within this thesis, the agency problem is a common
problem in many human endeavors. The personal goals of individuals can conflict with
those of the wider organization they are employed to serve. Ideally, incentive schemes
can be used to align personal and organizational goals.


153
With respect to the customer, a distinction is seen between IT projects aimed at
producing a commercial product for sale, designated here using the somewhat dated term
shrink-wrapped, commercial products built on contract (bespoke software) and software
built for internal use by the firm. The first key question is who the ultimate customer is:
the general marketplace, a specific customer or an internal business group within the
firm.
General Public
Single or small
number of
customers
Business Group
within the firm
Who is the
customer?
Shrink Wrap Bespoke Internal

Figure 29 Customer Types

The combination of types of suppliers and types of customers leads to Table 26. The
perspective column indicates from whose perspective project value is evaluated. For
instance, consider video games (shrink wrap project type). For the supplier, that is, the
firm that designs, develops and markets the game, the potential value is based on


154
complex estimates of production costs and forecasts of future sales and revenues. For
the customer, the potential value of the game is based on a known cost, the purchase
price, and a benefit equal to the very personal subjective evaluation of the entertainment
provided by the game. It should be noted that in the general case, for most other types of
shrink wrap projects, the value from the customers perspective can be measured by
process measures (section 4.5).
Table 26 Supplier-Customer Type Summary
Supplier Type Customer Type Project Type Perspective Inputs to
Financial
Value
Calculation
External
Supplier
General Public Shrink Wrap Supplier Inputs: Cost
estimates,
sales and
revenue
forecasts.
External
Supplier
General Public Shrink Wrap Customer Inputs: Cost
of software,
process
measures.
External
Supplier
Single or small
number of
customers
Bespoke Supplier Inputs: Cost
estimates,
terms of
contracts
External
Supplier
Single or small
number of
customers
Bespoke Customer Input: Cost of
contract,
process
measures
Internal
Supplier
Internal
Customer
Internal Firm Input: Cost
estimates,
process
measures

The inputs to calculations, those for costs and revenues, for financial measures of value
are seen to vary in the above table. The basic calculations remain as shown in the


155
financial methods of Chapter 4. In the above table, in the internal customer/internal
supplier case, both the internal supplier, an IT group or department, and the internal
customer, a business group are assumed to have the firms goals. Agency problems can
exist in firms, but are assumed resolved for the purposes of this section.
6.5.1 Shrink Wrap Projects (Suppliers Perspective)
Shrink wrap products have traditionally been those intended for direct sale to the public
(or to a specific subset of the general public, for example, graphic designers). The term
shrink wrap, although anachronistic with increased distribution via direct downloads onto
varied devices, will be used within this thesis for any product sold in the general market
and for the projects producing these products. With all types of projects, the valuation is
a matter of comparing benefits with costs. In the case of shrink wrap products from the
suppliers perspective:
Development
Costs
Support and
Maintenance
Costs
Marketing
Estimates of
Future Sales and
Revenues
Calculation of
Value using
Financial
Techniques of
Chapter 4
Compare returns
against other possible
investments

Figure 30 Shrink Wrap Projects Financial Value Calculation (Supplier's Perspective)
The biggest unknown here is the estimate of future sales and revenues. The techniques
used by marketing to estimate sales are beyond the scope of this thesis, but the financial


156
valuation techniques, examined in Chapter 4, support sensitivity studies which allow
the analysis of errors in those predictions. Here, since it is unlikely that support and
maintenance costs can be charged to end customers, these costs are seen as an expense
which reduces project value for the supplier. Also, of note is that valuation techniques
such as real options and game theory are particularly relevant. Investment in a prototype
or limited function first release can be evaluated using real options techniques as a means
to value the flexibility of making future investments should the pilot be successful.
Game theory is useful as a means to model and understand competition in the market.
Table 27 Assumptions, Measures and Uncertainties of Shrink Wrap Projects (Supplier's Perspective)
Assumptions Marketing or other groups outside of the software engineering group
can provide reasonable estimates of future sales and revenues.
Accurate cost estimates are available.

Relevant
Financial
Measures
Relevant Financial Measures: Basic financials measures (NPV, ROI,
IRR, payback period) and advanced techniques such as real options
and game theory are relevant.
Greatest
Uncertainty
Estimates of future sales and revenues.

6.5.2 Shrink Wrap Projects (Customers Perspective)
From the perspective of an end customer, the cost of the project, that is the cost of
software plus deployment and maintenance costs are well known or can be well known
relative to the uncertainties developing organizations (suppliers) face with cost estimates.
For potential benefits, process measures as discussed in section 4.5 are useful. Process
measures are useful for determining the value of software used internal within the
organization.


157
Purchase Costs
Support and
Maintenance
Costs
Process Measures
Calculation of
Value using
Financial
Techniques of
Chapter 4
Compare returns
against other possible
investments

Figure 31 Shrink Wrap Projects Financial Value Calculation (Customer's Perspective)

Table 28 Assumptions, Measures and Uncertainties of Shrink Wrap Projects (Customer's
Perspective)
Assumptions Support and maintenance costs are paid by the customer.
Relevant Financial
Measures
Basic valuation techniques (NPV, ROI, IRR, payback period). Real
options and game theory techniques do not apply.
Greatest
Uncertainty
The real challenge is to estimate support and maintenance costs or
ultimately in determining the total cost of ownership.

6.5.3 Bespoke Projects (Suppliers Perspective)
Bespoke builds are custom builds or enhancements of a software product for a particular
customer or customers. These differ from shrink wrap products in that the future revenue
is usually known, that being the revenue specified in the contractual agreements between
the supplier of software and its customer(s). Unlike shrink wrap products, support and
maintenance costs may be paid by the customer. The financial valuations techniques
studied in Chapter 4 are relevant. Of note, in this case, revenues and possibly
maintenance and support costs (potentially zero for the software firm if the customer is
paying) are well known. The task of determining development costs is more challenging


158
due to the unique nature of each custom build. Also, of note is that the static analysis
techniques such as NPV calculation, ROI and IRR are more relevant. This is because
presumably the terms of payment and the requirements of the project are firmly specified
within contractual agreements. Real options, which model flexibility and game theory
approaches, which model competition and the marketplace are less relevant.
Support and maintenance costs may be a source of revenue not expense. As seen
earlier, with shrink wrap support and maintenance almost certainly are an expense. Also
significant, the revenue may be well known, as it is probably contractually specified. The
greatest uncertainty is seen in development costs and support and maintenance costs.
Development
Costs
Support and
Maintenance
Costs
Revenue as
specified in
contract
Calculation of
Value using
Financial
Techniques of
Chapter 4
Compare returns
against other possible
investments

Figure 32 Bespoke Projects Financial Value Calculation (Supplier's Perspective)
Table 29 Assumptions, Measures and Uncertainties of Bespoke Projects (Supplier's Perspective)
Assumptions Support and maintenance costs are contractually specified and may
represent a source of revenue for the supplier.
Relevant
financial
techniques
Basic techniques (NPV, ROI, IRR, payback period) apply.
Greatest
uncertainty
Development costs, particularly because bespoke projects may be
unique and novel in nature making cost estimation more difficult.



159
6.5.4 Bespoke Projects (Customers Perspective)
This case is identical to the Shrink Wrap (Customers Perspective) case. From the
perspective of an end customer, the cost of the project, that is the cost of software plus
deployment and maintenance costs are well known or can be well known relative to the
uncertainties developing organizations (suppliers) face with cost estimates. For potential
benefits, process measures as discussed in section 4.5 are useful. Since the software
product is used internally, process measures can be used to quantify potential savings
from business process improvements.
Purchase Costs
Support and
Maintenance
Costs
Process Measures
(Section 4.5)
Calculation of
Value using
Financial
Techniques of
Chapter 4
Compare returns
against other possible
investments

Figure 33 Bespoke Projects Financial Value Calculation (Customer's Perspective)
Table 30 Assumptions, Measures and Uncertainties of Bespoke Projects (Customer's Perspective)
Assumptions Purchase costs and support and maintenance costs can be well
known by the customer. Both may be specified contractually.

Relevant Financial
Measures
Basic valuation techniques (NPV, ROI, IRR and payback period)
apply.

Greatest
Uncertainty
Process measures.



160
6.5.5 Internal Projects
Internal projects refer to software development efforts internal to the firm. These are
customer products for use internal to the firm needed to satisfy the needs of particular
business groups or to meet strategic objectives. Since there is no direct payment made by
an external customer, we must seek alternative ways to measure and specify the benefits
of the project. Process measures can be used to produce quantitative measures.
Development
Costs
Support and
Maintenance
Costs
Revenue as
specified in the
context of internal
process measures
(Chapter 4.5)
Calculation of
Value using
Financial
Techniques of
Chapter 4
Compare financial
returns against other
possible investments

Figure 34 Internal Projects Financial Value Calculation
Table 31 Assumptions, Measures and Uncertainties of Internal Projects
Assumptions Accurate cost estimates are available
Relevant Financial
Measures
Basic valuation techniques (NPV, ROI, IRR and payback period).

Greatest
Uncertainty
Process measures, development costs and support and maintenance
costs can all be uncertain and errors can impact value calculations.

6.6 Qualitative Evaluations
In addition to financial measures based on process measures, the alignment of the project
with respect to strategic alignment with the firm and alignment with enterprise


161
architecture is significant and should be used as part of project evaluation. The
strategic goals of the firm can be identified through the use of business or organization
level balanced scorecards. IT balanced scorecards can give a summary of the firms
architectural directions and of IT department level goals. Projects can be evaluated
against critical success factors as a means of evaluating risk and as a means of evaluating
the potential for successful completion. This is illustrated below.
Project
Characteristics
Compare relative
alignment against
other proposed
projects
Compare against
Organizations
Strategic Objectives

Figure 35 Project Evaluation against Firm's Objectives
Project
Characteristics
Compare relative
alignment against
other proposed
projects
Compare against
Organizations IT
Objectives and Enterprise
Architecture

Figure 36 Project Evaluation against IT Goals and Architecture
Project
Characteristics
Compare relative
ranking against other
proposed projects
Compare against
Project Critical
Success Factors

Figure 37 Project Evaluation against Project Success Factors


162
6.7 Project Portfolios
Firms typically have more projects than resources. One task of portfolio management is
to select the best projects given constraints on resources.
Portfolio management techniques typically try to classify projects into categories. This
allows for the following advantages.
Distribution of funding across project categories. For instance, business
applications could receive 25% percent of the total project, exploratory projects
10% and infrastructure upgrades 65%.
Within each project category, projects can be evaluated relative to each other.
Essentially, each project category can be treated as a separate portfolio.
Certain valuation techniques may apply only to certain categories of projects.
6.7.1 Weill MIT CISR Framework (Categorization by Investment Type)
In Weill [80] the MIT Center for Information Systems Research (CISR) IT Framework is
presented. Projects are classified along two dimensions, new vs. sustaining investments
and along the dimension of asset class. The distinction of new vs. sustaining is that a
firm must invest in new development to maintain competitive advantages. If the entire IT
budget is consumed to maintain existing infrastructure and applications, the firm will lose
competitiveness relative to others in its industry. Four asset classes are described in
Weill [80].
Transactional automation of manual or repetitive tasks to cut costs and/or
increase throughput.
Informational providing information for finance, accounting, management,
compliance and process monitoring and improvement.
Strategic projects done to gain a competitive advantage or to remain competitive
in the market.
Infrastructure creation of shared IT services used by multiple applications, for
example, network resources or shared servers.


163
Each of these asset classes can have projects that are focused on new development or
on sustaining existing applications and functionality. As noted earlier, firms not spending
on new development have grim long term prospects. IT governance (section 5.2.5) can
be achieved by establishing separate portfolios for each class of project and be allocated
funds to each portfolio to enforce desired strategic goals. For instance, separate funding
for new vs. sustaining projects will prevent on-going demands for maintenance projects
from preventing projects focused toward growth.
The key point is that a categorization scheme is required. Different classes of projects
require different means of assessment, prioritization and different sources of funding. A
separate portfolio can be established for each asset class (type of project) and for new
and sustaining projects within an asset class. This allows comparisons of projects of
similar nature within each portfolio and more importantly directs funding toward certain
classes of projects. For instance, more spending can be directed toward projects of a
strategic nature, perhaps less toward infrastructure projects. While not directly related to
the valuation of an individual project, project categorization can direct funding towards
particular classes of projects and is related to the return and value obtained by the mix of
projects conducted.
The benefits expected from each category also vary by category. The following diagram
is from [84]. It shows the possible benefits from each category (class) of project.


164
Infrastructure (54%)
Informational (20%)
Strategic (13%)
Transactional (13%)
Increased Sales
Competitive advantage
Competitive necessity
Market Position
Business Integration
Business flexibility
Reduced marginal cost of
BUs IT
Reduced IT costs
Standardization
Increased control
Better information
Better integration
Improved quality
Cut costs
Increase throughput
50% fail
Some spectacular
successes
2-3 year lead
Premium pricing
More sales from modified
and enhanced products
Superior quality
Premium pricing
Larger margins
Higher Return on Assets
Higher sales per assets
Lower cost of goods sold
25-40% return
Higher market valuation,
faster speed to market
Smaller short run margins
and lower ROA

Figure 38 Returns from the Four Project Categories (based on [84])
A key point to observe in the above figure is the relative percentages that typical firms
spend for each asset type, or equivalently for each class of project. These figures can
serve as benchmarks for a firm to evaluate its spending relative to other firms. While
benchmarks are not useful to valuation of individual projects, they can be used to direct
funding for different types of projects. Ultimately, this direction of funding determines
the returns and value of the set of projects done by the organization. More detailed data
on an industry level can be obtained from MIT CISR, but is not presented here.
6.7.2 Ross Beath (MIT CISR) Categorization by Management Objectives
In Ross [85] a classification of projects by management objectives is presented. Projects
are classified along two dimensions. The first dimension is the time frame to
profitability. Some investments are for short term profitability, some for enabling long-
term growth of the firm. The second dimension is technology scope, which is whether


165
the projects benefits are related to a specific business process or need or whether
they are more global in scope.

PROCESS
IMPROVEMENT
EXPERIMENTS
RENEWAL TRANFORMATION
Business Solutions
Shared Infrastructure
Short-Term
Profitability
Long-Term
Growth
TECHNOLOGY
SCOPE
STRATEGIC OBJECTIVE

Figure 39 Project Classifications (from [85])

The technology scope is seen to vary from individual application level changes to address
specific business needs to corporate wide technology changes. The strategic objective
dimension is seen to run from addressing specific short term operational needs to
addressing strategic objectives such as new market entry. Within this framework, Ross
[85] classified projects into four types:

Process Improvement

Process improvements are changes to meet specific operational needs. An
example is a new order entry system to automate a previously manual process.

Renewal



166
Renewals are upgrades or expansions in existing technologies needed for
increased efficiency or for maintainability. An example is an upgrade in the
version of a vendor purchased product, such as a DBMS, to remain on a supported
version.

Experiments
Experiments are tests of new technologies done in order to evaluate them and
understand their applicability or research and development type activities.

Transformations
Transformations are changes in the core infrastructure when it is determined that
it is insufficient to meet business needs or to support a new business model. An
example is the development of an infrastructure to support E-commerce for a
previously brick and mortar only company.
The nature for evaluation and prioritization of projects in each category is different [85].
For instance, a business case approach is appropriate for process improvement projects,
but possibly not for experiments. Static NPV or ROI evaluations of experiments alone
would result in their rejection. Real option and game theory analysis as shown earlier in
this thesis might indicate value, but Ross [85] suggests that these types of efforts need to
be evaluated and funded based on a strategic evaluation. Additionally, based on the
classifications, the source of funding for individual projects may be different. Process
improvements (defined here to be efforts addressing specific operational needs rather
than process improvement in the traditional software engineering sense) should be funded
by the individual business units receiving benefit while transformations or experiments
should be funded at a CIO or other executive level.
The key point is once again that projects are initially classified by type to create
portfolios of projects of related type. The funding of each portfolio and the evaluation of
projects within each portfolio may differ as expounded in later sections of this thesis.


167
6.7.3 Proposed Categorization Scheme
As seen in the preceding two sections, it is possible to define varied project classification
schemes. For use within this thesis the following categorization scheme, based on
Weills work will be used. The category, Mandatory, is suggested in [83]. Empirical
validation of this is outside the scope of this work, but future work on the effectiveness of
alternate categorization schemes is an area that demands more research. Eight classes of
projects are seen. Transactional, Informational and Infrastructure projects are seen as
either New or Sustaining. Ross (section 6.7.2) provides examples of how infrastructure
projects depending on their technological scope and purpose (focused on short term or
long term profits) can determine whether they are new or sustaining efforts. Clearly a
simple upgrade to the latest version of a DBMS or OS is a sustaining type of project.
Development of extensive data centers to support turning a brick and mortar type store
into one focused on E-commerce is an example of a new infrastructure project. It is
assumed that strategic projects, by their nature, are new development efforts.
Similarly, mandatory projects by their nature are seen as sustaining.



168
Projects
Transactional
Automation of
manual or
repetitive
tasks to cut
costs and/or
increase
throughput.
Informational
Providing
information
for finance,
accounting,
management,
compliance
and process
monitoring
and
improvement.
Strategic
Projects done
to gain a
competitive
advantage or
to remain
competitive in
the market.
Infrastructure
Creation of
shared IT
services used
by multiple
applications,
for example,
network
resources or
shared servers.
Mandatory
Driven by
external legal
or regulatory
needs or to
satisfy internal
or external
audits.
New Sustaining New Sustaining New New Sustaining Sustaining

Figure 40 Proposed Project Classification Scheme
The usefulness of process measures (section 4.5) as a valuation technique is very heavily
dependent on project type. Process measures are useful for valuation of transactional,
informational and infrastructure projects.

Table 32 Usefulness of Process Measures by Project Type
Project Type Usefulness of process measures for
valuation
Transactional Useful
Informational Useful
Strategic For strategic projects, defined as those that


169
move the firm into new markets, create
radically different products or reinvent the
firm (for example, changing from a brick
and mortar store to E-commerce) not
useful
Infrastructure Useful for renewal type projects (section
6.7.2). For transformation type projects
(section 6.7.2) less useful.
Mandatory Not useful. The relevant question is the
cost of the project versus the cost of
withdrawing from the business or versus
the cost of fines, penalties and lawsuits.
Process measures are relevant to access
alternate approaches.

For strategic projects, often the future markets cannot be estimated with any
certainty. This might be the case for firms entering new markets or creating entirely new
products. For instance, firms competing early in the MP3 player market could not have
forecasted the tremendous growth of this media. Additionally, for radically new
technology, expenses are difficult to estimate. Early adopters of J2EE technology
probably could not have accurately estimated hardware or maintenance costs. For
projects of this nature, funding and the decision to proceed need to be made at senior
levels based on a somewhat subjective understanding of market and technology trends. It
is interesting, that despite this uncertainty and imprecise measure of value, it is these
types of projects that ultimately determine the firms survival, leading to great gains or
losses. Real option techniques and game theory are particularly applicable.


170
For mandatory projects, process measures are not necessarily useful.
Compliance and regulatory projects are seen as a cost of doing business. Careful
calculation of value is not necessarily useful. They may need to be done regardless of
value, or alternatively, the value of doing them can be seen as the value of being able to
continue to conduct business.
Table 33 Relevant Financial Measures by Project Type
Project Type Relevant Financial Measures
Transactional, New Basic Financial Measures (NPV, ROI, IRR,
payback period)
Transactional, Sustaining Basic Financial Measures (NPV, ROI, IRR,
payback period)
Informational, New Basic Financial Measures (NPV, ROI, IRR,
payback period)
Informational, Sustaining Basic Financial Measures (NPV, ROI, IRR,
payback period)
Strategic, New Basic Financial Measures (NPV, ROI, IRR,
payback period) plus advanced measures
(real option and game theory techniques)
Infrastructure, New Basic Financial Measures (NPV, ROI, IRR,
payback period) plus advanced measures
(real option and game theory techniques)
Infrastructure, Sustaining Basic Financial Measures (NPV, ROI, IRR,
payback period)
Mandatory, Sustaining Potentially none. These projects are done
to address regulatory or legal requirements
and generally must be done regardless of
cost to remain in a particular market or
business. In some sense, the value of the
project is that of remaining in business.



171
In the above table, advanced financial measures are seen as appropriate for projects
that have strategic value (strategic projects or large new infrastructure projects that
fundamentally alter the firm). These techniques have less value for informational or
transactional projects where there may be less managerial choice (flexibility) and no need
to consider competition from other firms.

6.8 Types of Firm
The strategic focus of the firm is related to firms strategic objectives. It is best seen as
input into the process of defining the firms objectives, perhaps as part of the process of
defining a balance scorecard at the level of the firm. Indirectly, the type of a firm plays a
role via an assessment of the characteristics of a project relative to the strategic objectives
of the firm.
Three dominant strategies exist [86].
Product Leadership: The firm competes by being on the leading edge of
technologies and functionality and by offering higher quality. The focus is on
new cutting edge technologies and on improved quality.
Price Leadership: The firm competes by operating in higher volumes and lower
per transaction costs. IT initiatives that lower costs and create efficiency are
favored.
Customer Intimacy: The firm attempts to customize services to particular
customers and to provide comprehensive services.
Tallon [64] presented an example of how the type of the firm could relate to the types of
projects which are emphasized. The following table is from [64].
Table 34 Value in Different Firm Types
Price Leadership Customer Intimacy Product
Leadership
Source of Value Best total cost Best total solution Best Product
Example Firms Dell, Costco,
Jetblue
Merrill Lynch,
Capital One
Intel, 3M, Sony


172
Core Processes Supplier Relations,
Production and
Operations
Customer Relations,
Sales and Marketing
Support
Product and Service
Enhancements
Role of IT Pursue automation
and supply chain
integration
Offer
personalization and
mass customization
Support the design
of new product
offerings

Relating this back to the proposed project categorization framework, the following can be
inferred.
Table 35 Project Type Emphasized by Firm Type
Strategic Focus of Firm Types of Projects Emphasized
Price Leadership Transactional
Customer Intimacy Informational
Product Leadership Strategic

Empirical validation of the above relationships is outside the scope of this work, but
could yield insight into the problem of project categorization. Relative funding of
portfolios to support particular project types may vary based on firm type. For instance,
as suggested above in Table 35, firms with a strategic focus of product leadership might
focus a relatively higher percentage of funds on portfolios of strategic projects.
6.9 Investment Boundary
The investment boundary is a concept from modern portfolio theory. It expresses how
much risk the organization is willing to tolerate for a given return. Relative to the
investment boundary, projects can be rated as acceptable, marginal or unacceptable.


173
Investment boundaries can be established for various financial measures. ROI over a
given period and NPV are shown below.
Additionally, the investment boundary is expected to vary based on project type. For
instance, a higher chance of loss may be tolerated for strategic projects than for
transactional or informational. The investment boundary will be seen to shift upwards or
downwards based on project type.


Figure 41 Investment Boundary: ROI vs. Chance of Loss

0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
0% 20% 40% 60% 80% 100% 120% 140% 160%
C
h
a
n
c
e
o
f
L
o
s
s
ROI over given period
Investment Boundary
Acceptable
Unacceptable


174

Figure 42 Investment Boundary: NPV vs. Chance of Loss

6.10 Discussion
A proposed framework and process for the valuation of projects was presented. A project
portfolio based approach was used. Projects were classified into a relevant portfolio and
ranked against projects within that portfolio. The valuation of each individual project
was done along multiple dimensions, both quantitative and qualitative. Projects should
be reevaluated at multiple times as they are being conducted and after completion.
Metrics collected during these reevaluations can be used for process improvements.

0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
0 50000 100000 150000 200000 250000 300000 350000
C
h
a
n
c
e
o
f
L
o
s
s
NPV
Investment Boundary
Acceptable
Unacceptable


175
Chapter 7

Application of the Framework
7.1 Example
Assume there are five internal software projects that need to be evaluated. Each is valued
using process measures, an example of which is given in section 4.5.4.1. From this, using
the financial measures such as NPV, IRR, ROI, payback period can be calculated as
shown in Chapter 4. The risk of loss for each project can be determined based on an
estimate of the cost if the project fails and an estimate of the likelihood of this occurring.
Additionally, each project is rated for its alignment with organizational strategy (section
5.4), its alignment with IT strategy / Enterprise architecture (section 5.4) and against a set
of critical project success factors (section 3.3).
This example shows how relative ranking of projects, steps six and seven, in the proposed
process can be accomplished. Steps one through five, as described in the preceding
paragraphs have been illustrated in other sections of this thesis.
Assume that each project costs $150000 and they have the returns shown below.
Additionally, the organization has capital and resources to conduct only one project. The
task at hand is to assign a value to each project and to choose the best one to fit the
organizations needs.



176
Table 36 Example of Use of Framework
Projec
t #
Alignment
with
Organization
al Strategy
Alignment
with IT
Strategy
and
Enterprise
Architectur
e
Project
Critica
l
Succes
s
Factors
Return
(NPV)
ROI Payback
Period
(Months
)
Risk of Loss
(based on
investment
boundary,
Figure 41,
and estimate
of chance of
loss)
1 Negative
(0.25)
Negative
(0.5)
2 42500
0
283
%
12 In
acceptable
region
2 Moderate (2) Moderate
(1.9)
2.2 27500
0
183
%
12 In
acceptable
region
3 Low (1.1) Low(1) 2.l7 35000
0
233
%
24 Boundary
4 High (2.5) Moderate
(2.2)
2.1 40000
0
267
%
12 Unacceptabl
e
5 Moderate
(2.1)
Moderate
(1.8)
1 28000
0
186
%
12 In
acceptable
region

At a first pass, looking at this table, any investments that fall outside the investment
boundary should be rejected. The investment boundary is the minimum return required
for a given level of risk or equivalently the maximum risk acceptable for a given return.
(see Figure 41 and Figure 42) The firm executives set this boundary to establish the
returns needed to tolerate a given risk of loss. On this basis alone, project 4 would
probably be rejected. This is interpreted as it being too risky for its level of returns.
Project 4 would be rejected because it is too risky for the given return (despite having the
largest overall return). This is based on its estimated chance of failure and the investment
boundary shown in Figure 42. Despite its high return, we are assuming that it is too
risky, that is, it is outside the investment boundary.


177
To establish choose among the remaining four projects, we need to consider other
non-financial factors such as alignment with organizational strategies, alignment with
enterprise architecture and chance for success when evaluated against project critical
success factors as well as financial factors.

Figure 43 examines alignment with Firm goals/strategies and with enterprise architecture
and IT strategies. From this it is seen that although financially project 1 is desirable it is
poorly aligned with the organization and IT. It should probably be rejected on this basis.
Project 3 is on the investment boundary (see Table 36), meaning it is risky relative to the
potential financial returns. Additionally, it has low alignment with organization and IT,
so it should also be rejected. In this figure, the size of the bubbles show relative NPV of
each project and the projects acceptability with respect to the investment boundary is
shown as in the legend.
From Figure 43, projects 2 and 5 have similar value with respect to financial returns and
alignment with organizational strategies/goals and IT strategy / architecture.


178

Figure 43 Project Evaluation with respect to Organization and IT Goals

Another view of these projects (Figure 44) examines each against project critical success
factors. It is seen that based on these factors, project 2 has a much better chance of
successful delivery. Perhaps it has a more experienced project team or a team co-located
with the end users. Based on this evaluation, project 2 should be selected over project 5


179


Figure 44 Project Evaluation with respect to Organization Goals and Project Success Factors
Another view, Figure 45, with each project evaluated against IT architecture and goals
and against project critical success factors. It confirms that project 2 is the best available
investment for the firm among the five potential projects.


180

Figure 45 Project Evaluation with respect to IT Goals and Project Success Factors
7.2 Discussion
The above example showed how projects within a portfolio could be evaluated with
respect to multiple dimensions. In the example, projects were evaluated with respect to
financial measures, project critical success factors, alignment with organizational goals
and alignment with IT goals and architecture. It was seen that each dimension
discriminates between projects and by examining different dimensions, project selection
can be achieved.



181
Chapter 8

Conclusions and Future Work
8.1 Conclusions
With ever increasing spending on information technology and its increased use in more
aspects of daily life, a critical question is how to value the worth of proposed software
projects. The question of what value they deliver to the firms investing in them and to
stakeholders seeking solutions to their needs becomes increasing significant as spending
and reliance on software increases. The thesis presented a review of quantitative and
qualitative ways to access value and proposed a framework to combine these multiple
measures and to systematically establish project portfolios and assess projects within
those portfolios.
A review of the current state of practice found that the distinction between project
success and project management success is not always clearly defined. The former leads
to a product that has value, either in the sense of satisfying stakeholder needs or in
increasing the wealth of the firm. The latter measures only the success of the project
manager. Its quite possible to run the wrong project well. Earned value techniques were
seen to be a misnomer. While very useful as a means of tracking costs and schedule,
they are not measures of value.
Software projects build solutions to satisfy a set of business requirements. Getting these
requirements right is a key step in delivering value. Requirements techniques such as the
Benefits Realization Approach and goal oriented requirements engineering were
reviewed as means of obtaining good requirements.


182
Engineering can be defined as applying science and mathematics in ways that are
useful to people or society. Implicit in this definition is the concept of value. Being
useful is synonymous with delivering value. Software engineers should explicitly
consider and calculate the value of software projects and of other software activities.
Some of the failed delivery of projects and shortfalls in software engineering techniques
can be attributed to a lack of explicit attention to value. [87]
Quantitative or financial approaches to the calculation of value were considered. Basic
techniques such as net present value, internal rate of return and payback period were
considered as three static views of project value. Flexibility and choice was seen as
quantified by real options. Game theory was shown as a means to model the market and
competition. Process measures were seen to provide a measure of future cash flows for
internal projects as marketing and sales forecasts were for external projects.
Quantitative techniques are imperfect. They fail to capture all dimensions of value and
are subject to error due to inaccuracies in inputs and due to model errors. Qualitative
evaluation of projects against the goals of the organization and against IT goals and
architecture are seen as ways to enrich understanding of project value. It was found that
the means of specifying these goals and of measuring projects against these goals are
lacking both in the literature and in practice.
A framework and process was proposed as a means of incorporating the multiple
dimensions of value and the multiple factors that influence value into the process of
project valuation. A portfolio based approach was proposed. The approach to
quantitative evaluation of a project was seen as dependent on perspective, that is,


183
depending upon whether a supplier or customer is trying to determine their value
from the project, on the type of project, whether it could be classified as transactional,
informational, strategic, infrastructure or mandatory, and on the type of the firm. The
applicability of differing financial measures was seen to depend on the nature of the
project itself, whether is had uncertainties and choices to be made in the future and on the
extent of its scope. Projects with major strategic significance were seen as benefiting
from game theory analysis.
The framework also incorporated qualitative factors. Alignments with the organizations
goals and with those of the IT group are measures of value. Satisfaction of critical
success factors were seen as indicates of the possibility of delivering value. As
previously noted, better means of identifying these goals and factors, of measuring them
and of combining them are needed.
Finally, the process was seen as iterative. As more information and understanding of a
project is obtained, valuation should be redone to evaluate whether the project should be
continued. These multiple valuations, along with a measurement of the actual value
obtained after completion of the project were seen as useful for process improvement,
that is, to improve the processes of valuation.
8.2 Future work
The proposed framework presented in this thesis is just that, proposed. Empirical studies
are required to validate the approach and to show that projects selected and conducted
following the use of valuation techniques within the proposed portfolio based framework
do in fact deliver more value that projects selected using other means.


184
Project valuation can useful for the following three purposes: project selection, value
based project tracking and control and as input into process improvement toward better
valuation techniques The middle technique, while not examined within this work may
have interesting potential. Given an initial assessment of project value and intermittent
measures of value as the project progresses, its possible that measured differences
between the value being achieved and that planned could be used as feedback to control
and correct the direction of the project to improve delivery of value.
A critical step in the framework was the establishment of portfolios, really of classes of
projects. Establishment of portfolios and the optimal relative funding of those portfolios
to achieve corporate goals warrants further research.
As noted elsewhere in this thesis, good means of measuring the alignment of individual
projects against critical success factors, organizational goals and IT goals/architecture are
needed. Combining these measures can be seen as a multidimensional decision making
problem. Adequate techniques, usable by practitioners are needed.
Project valuation requires measurement and analysis in multiple dimensions. As with
many multidimensional problems, better visualization and tools for viewing and analysis
are needed.


185



Glossary

TERM DEFINITION
Actual Cost (AC) or Actual Cost of Work
Performed (ACWP)
This is the actual cumulative cost at a given
point in time spent on a task, work package
or the project itself.
Budget at Completion (BAC) This is the total budget allocated to a task,
work package or project.
Call Option A right, but not an obligation, to buy an
asset at a fixed price at a future date. An
option to expand a project is analogous to a
call option.
Cost Performance Index (CPI) Ratio of value generated (EV) to actual
cost (AC). A CPI of less than one indicates
that money is being spent more quickly
than planned to complete the amount of
work accomplished.
Cost Variance (CV) Absolute variance in cost. EV worth of
value was generated and it cost AC. Cost
variance = earned value actual cost.
Critical Ratio (CR) A measure that combines CPI and SPI to
measure both the cost and schedule
performance of a task.
Critical Success Factors (CSF) Factors associated with a higher probability
of successful project completion.
Discount Rate A rate applied in net present value /
discounted cash flow calculates to calculate
the present value of a cash flow received in
the future. It is a function of the risk of the
investment.
Earned Value (EV) or Budgeted Cost of
Work Performed (BCWP)

This is the cumulative (earned) value of
work completed on a task, work package or
the project itself at a given point in time.
Exercise Date The expiration date of an option. American
style options can be exercised (used) on or
before the exercise date. European style
options can be used only on the expiration
date.


186
Execution Price The purchase price or sale price of the
underlying asset in an option. The option
itself is also bought. It gives a right to
purchase the underlying asset at the strike
price.
Internal Rate of Return The discount rate at which NPV is equal to
zero. It is an interest rate that can be used
to compare projects.
Net Present Value A sum or net of all cash flows of a project
or investment, both costs and revenues,
discounted to the present time. It is a
measure of the financial value of a project
or investment.
Opportunity Cost The value of the next best alternative.
Option A right, but not an obligation, to buy or sell
an asset at a given price on or by a future
date. American style options must be
exercised (used) on or before that future
date. European style options can be used
only on that future date.
Payback Period The length of time needed for a project to
earn cash flows to payback the initial
investment made.
Planned value (PV) or Budgeted Cost of
Work Scheduled (BCWS)
This is the budget allocated for performing
a task, work package or project itself. It is
a time phased, meaning it is dispersed or
spent as the task or project proceeds.
Measured at a point in time.
Put Option A right, but not an obligation, to sell an
asset at a fixed price at a future date. An
option to contract a project is analogous to
a call option.
Salvage Value After the end of the useful life of a product
or system, some components may be sold
or utilized in other efforts. The financial
worth of these components is called
salvage value.
Schedule Performance Index (SPI) Ratio of value generated (EV) to planned
(scheduled) value (PV). A SPI less than
one indicates the task is behind schedule.
Schedule Variance (SV) Variance in value generation against plan.
EV worth of value was generated, but we
had planned (scheduled) to accomplish PV
worth of value. Schedule variance =
earned value planned value.
Strike Price The purchase price or sale price of the


187
underlying asset in an option. The option
itself is also bought. It gives a right to
purchase the underlying asset at the strike
price.



188
References
[1] Robert Solow, New York Review of Books, July 12th 1987.
[2] Nicholas G. Carr, "IT Doesn't Matter," Harvard Business Review, vol. 81, no. 5, pp.
41-49, May 2003.
[3] Rajiv Kohli and Varun Grover, "Business Value of IT: An Essay on Expanding
Research Directions to Keep up with the Times," Journal of the Association for
Information Systems, vol. 9, no. 1, pp. 23-39, Jan 2008.
[4] Project Management Institute, A Guide to the Project Management Body of
Knowledge (PMBOK Guide), 3rd ed. Newtown Square, Pennsylvania: Project
Management Institute, Inc., 2004, p. 4.
[5] Project Management Institute, A Guide to the Project Management Body of
Knowledge (PMBOK Guide), 3rd ed. Newtown Square, Pennsylvania: Project
Management Institute, Inc., 2004, p. 24.
[6] Kam Jugdev and Ralf Muller, "A Retrospective Look at Our Evolving
Understanding of Project Success," Project Management Journal, vol. 36, no. 4, pp.
19-31, December 2005.
[7] Terry Cooke-Davies, "The 'Real' Success Factors on Projects," International Journal
of Project Mangement, vol. 20, no. 3, p. 185, April 2002.


189
[8] Frank T. Anbari, "Earned Value Project Management Method and Extensions,"
Project Management Journal, vol. 34, no. 4, pp. 12-23, December 2003.
[9] B Boehm and L Haung, "Value-Based Software Engineering: Reinventing Earned
Value Monitoring and Control," ACM SIGSOFT Software Engineering Notes, vol.
28, no. 2, pp. 1-7, March 2003.
[10] John Thorp, The Information Paradox.: McGraw-Hill, 1998.
[11] John Thorp, The Information Paradox.: McGraw-Hill, 1998, p. 38.
[12] John Thorp, The Information Paradox.: McGraw-Hill, 1998, p. 48.
[13] John Thorp, The Information Paradox.: McGraw-Hill, 1998, p. 49.
[14] Barry Boehm and Dan Port, "Escaping the Software Tar Pit: Model Clashes and
How to Avoid Them," ACM Software Engineering Notes, vol. 24, no. 1, pp. 36-48,
Jan 1999.
[15] B Boehm, "Software Economics Road Map," FOSS, 2000.
[16] Barry W Boehm and Rony Ross, "Theory-W Software Project Management:
Principals and Examples," IEEE Transactions on Software Engineering, vol. 15, no.
7, pp. 902-916, July 1989.
[17] Barry Boehm et al., "Using the WinWin Spiral Model: A Case Study," IEEE
Computer, pp. 33-44, July 1998.


190
[18] Roger Fisher and William Ury, Getting to Yes: Negotiating Agreement without
Giving In, 2nd ed.: Houghton Mifflin Company, 1991.
[19] A Anton, "Goal-based Requirements Analysis," ICRE, pp. 136-144, 1996.
[20] A Anton and C Potts, "The use of goals to surface requirments for evolving
systems," Proc. 20th International Conference on Software Engineering, pp. 157-
166, 1998.
[21] E Yu, "Towards Modeling and Reasoning Support for Early Phase Requirements
Engineering," Proc RE-97 - 3rd International Symposium on Requirements
Engineering, no. 226-235, 1997.
[22] E Yu and J. Mylopoulos, "Why Goal-Oriented Requirements Engineering,"
Proceedings of the 4th International Workshop on Requirements Engineering:
Foundations of Software Quality (8-9 June 1998, Pisa, Italy), pp. 15-22, 1998.
[23] J. Mylopoulos, L. Chung, and B. Nixon, "Representing and Using Non-Functional
Requirements: A Process-Oriented Approach," IEEE Transactions of Software
Engineering, vol. 18, no. 6, June 1992.
[24] A Van Lamsweerde, "Goal-Oriented Requirements Engineering: A Guided Tour,"
Proc. RE'01: 5th International Symposium Requirements Engineering, August 2001.
[25] A Van Lamsweerdem, D Robert, and M. Phillipe, "Goal-Directed Elaboration of
Requirements for a Meeting Scheduler," Proceedings of the 2nd IEEE Symposium


191
on Requirements Engineering (RE'95), pp. 194-205, March 1995.
[26] Ward Belassi and Oya Icmeli Tukel, "A New Framework for Determining Critical
Success/Failure Factors in Projects," International Journal of Project Management,
vol. 14, no. 3, pp. 141-151, June 1996.
[27] Francis Hartman and Rafi A. Ashrafi, "Project Management in the Information
Systems and Information Technologies Industries," Project Management Journal,
vol. 33, no. 3, pp. 5-15, Sept 2002.
[28] Xiangnan Lu, Xin Zhao, and Hui Han, "Analysis on Factors Impacting to
Information Systems Development," 2008 International Seminar on Future
Information Technology and Management Engineering (FITME 2008), pp. 356-359,
2008.
[29] Steward C. Myers, Richard A Brealey, and Franklin Allen, Principles of Corporate
Finance, 8th ed.: McGraw-Hill Irwin, 2006, p. 16.
[30] Steward C. Myers, Richard A Brealey, and Franklin Allen, Principles of Corporate
Finance, 8th ed.: McGraw-Hill Irwin, 2006, p. 17.
[31] Steward C. Myers, Richard A Brealey, and Franklin Allen, Principles of Corporate
Finance, 8th ed.: McGraw-Hill Irwin, 2006, p. 88.
[32] Steve Tockey, Return on Software.: Addison-Wesley, 2005, p. 119.
[33] Steward C. Myers, Richard A Brealey, and Franklin Allen, Principles of Corporate


192
Finance, 8th ed.: McGraw-Hill Irwin, 2006, p. 90.
[34] Steve Tockey, Return on Software.: Addison-Wesley, 2005, p. 117.
[35] Steward C. Myers, Richard A Brealey, and Franklin Allen, Principles of Corporate
Finance, 8th ed.: McGraw-Hill Irwin, 2006, p. 91.
[36] Steward C. Myers, Richard A Brealey, and Franklin Allen, Principles of Corporate
Finance, 8th ed.: McGraw-Hill Irwin, 2006, p. 96.
[37] Steward C. Myers, Richard A Brealey, and Franklin Allen, Principles of Corporate
Finance, 8th ed.: McGraw-Hill Irwin, 2006, p. 99.
[38] Lenos Trigeorgis, Real Options. Cambridge, Massachusetts: The MIT Press, 1996,
pp. 40-52.
[39] Lenos Trigeorgis, Real Options. Cambridge, Massachusetts: The MIT Press, 1996,
p. 40.
[40] Lenos Trigeorgis, Real Options. Cambridge, Massachusetts: The MIT Press, 1996,
p. 41.
[41] Steward C. Myers, Richard A Brealey, and Franklin Allen, Principles of Corporate
Finance, 8th ed.: McGraw-Hill Irwin, 2006, p. 189.
[42] Steward C. Myers, Richard A Brealey, and Franklin Allen, Principles of Corporate
Finance, 8th ed.: McGraw-Hill Irwin, 2006, p. 245.


193
[43] Steward C. Myers, Richard A Brealey, and Franklin Allen, Principles of Corporate
Finance, 8th ed.: McGraw-Hill Irwin, 2006, p. 260.
[44] Hank Erdogmus, "Valuation of Complex Options in Software Design," EDSER 1,
1999.
[45] Kevin J. Sullivan, William G Griswold, and Ben Hallen Yuanfang Cai, "The
Structure and Value of Modularity in Software Design," pp. 99-108, 2001.
[46] Steward C. Myers, Richard A Brealey, and Franklin Allen, Principles of Corporate
Finance, 8th ed.: McGraw-Hill Irwin, 2006, p. 262.
[47] (2008, November 11) Yahoo Finance. [Online]. http://finance.yahoo.com/
[48] Steward C. Myers, Richard A Brealey, and Franklin Allen, Principles of Corporate
Finance, 8th ed.: McGraw-Hill Irwin, 2006, p. 553.
[49] Lenos Trigeorgis, Real Options. Cambridge, Massachusetts: The MIT Press, 1996,
pp. 73-74.
[50] Steward C. Myers, Richard A Brealey, and Franklin Allen, Principles of Corporate
Finance, 8th ed.: McGraw-Hill Irwin, 2006, p. 549.
[51] Steward C. Myers, Richard A Brealey, and Franklin Allen, Principles of Corporate
Finance, 8th ed.: McGraw-Hill Irwin, 2006, p. 557.
[52] Lenos Trigeorgis, Real Options. Cambridge, Massachusetts: The MIT Press, 1996,


194
pp. 89-91.
[53] Han T.J. Smit and Lenos Trigeorgis, Strategic Investment.: Princeton University
Press, 2004, pp. 103-106.
[54] Han T.J. Smit and Lenos Trigeorgis, Strategic Investment.: Princeton University
Press, 2004, p. 111.
[55] Han T.J. Smit and Lenos Trigeorgis, Strategic Investment.: Princeton University
Press, 2004, p. 115.
[56] Adam Borison, "Real Options Analysis: Where are the Emperors Clothes?," Real
Options Conference, July 2003.
[57] (2009, May) BloBek AB Black-Scholes Option Value Calculator. [Online].
http://www.blobek.com/black-scholes.html
[58] Economic Research Institute. (May, 2009) ERI's Black-Scholes Calculator. [Online].
http://www.erieri.com/scripts23/blackscholes/blackscholes.exe/Calculate
[59] Han T.J. Smit and Lenos Trigeorgis, Strategic Investment.: Princeton University
Press, 2004, p. 164.
[60] Han T.J. Smit and Lenos Trigeorgis, Strategic Investment.: Princeton University
Press, 2004, p. 171.
[61] Han T.J. Smit and Lenos Trigeorgis, Strategic Investment.: Princeton University
Press, 2004, p. 209.


195
[62] Han T.J. Smit and Lenos Trigeorgis, Strategic Investment.: Princeton University
Press, 2004, pp. 182-190.
[63] Douglas W. Hubbard, How to Measure Anything: Finding the Value of Intangibles
in Business.: John Wiley & Sons, Inc., 2007.
[64] Paul P. Tallon, "A Process-Oriented Perspective on the Alignment of Information
Technology and Business Strategy," Journal of Management Information Systems,
vol. 24, no. 3, p. 227268, Winter 2007.
[65] David Sward, Measuring the Business Value of Information Technology.: Intel Press,
2006.
[66] Wikipedia. (May, 2009) Confidence Interval. [Online].
http://en.wikipedia.org/wiki/Confidence_interval
[67] Steward C. Myers, Richard A Brealey, and Franklin Allen, Principles of Corporate
Finance, 8th ed.: McGraw-Hill Irwin, 2006.
[68] Han T.J. Smit and Lenos Trigeorgis, Strategic Investment.: Princeton University
Press, 2004.
[69] Lenos Trigeorgis, Real Options. Cambridge, Massachusetts: The MIT Press, 1996.
[70] A.J. Gilbert Silvius, "Business Value of IT: A Conceptual Model for Selecting
Valuation Methods," Communications of the IIMA, vol. 8, no. 3, pp. 57-66, 2008.


196
[71] Steven B. Dolins, "Using the Balanced Scorecard Process to Compute the Value of
Software Applications," ICSE06, pp. 881-884, May 2006.
[72] Thomas Neubauer, Jan Pichler, and Christian Stummer, "A Case Study on the
Multicriteria Selection of Software Components," 2008 IEEE Asia-Pacific Services
Computing Conference, pp. 1005-1012, 2008.
[73] Robert S. Kaplan and David P. Norton, "The Balanced Scorecard Measures That
Drive Performance," Harvard Business Review, vol. 70, no. 1, pp. 71-19, Jan-Feb
1992.
[74] Robert S. Kaplan and David P. Norton, The Balanced Scorecard - Translating
Strategy into Action. Boston, Massachusetts: Harvard Business School Press, 1996.
[75] Wim Van Grembergen, "Aligning Business and Information Technology through the
Balanced Scorecard at a Major Canadian Financial Group: its Status Measured with
an IT BSC Maturity Model," Proceedings of the 34th Hawaii International
Conference on System Sciences (HICSS-34), vol. 8, p. 8061, Jan 2001.
[76] W. Van Grembergen and I. Amelinckx, "Measuring and Managing E-business
Projects through the Balanced Scorecard," 35th Annual Hawaii International
Conference on System Sciences (HICSS'02), vol. 8, p. 258, Jan 2002.
[77] Win Van Grembergen, "The Balanced Scorecard and IT Governance," Information
Systems Control Journal, vol. 2, 2000.


197
[78] Andrei Shleifer and Robert W. Vishny, "A Survey of Corporate Governance," The
Journal of Finance, vol. LU, no. 2, pp. 737-783, June 1997.
[79] Project Management Institute, A Guide to the Project Management Body of
Knowledge (PMBOK Guide), 3rd ed. Newtown Square, Pennsylvania: Project
Management Institute, Inc., 2004, p. 62.
[80] Peter Weill, Stephanie L. Woerner, and Howard A. Rubin, "Managing the IT
Portfolio," MIT Center for Information System Research - Research Briefing, vol. 8,
no. 2B, July 2008.
[81] Project Management Institute, The Standard for Portfolio Management, 2nd ed.
Newtown Square, Pennsylvania: Project Management Institute, Inc., 2008, p. 10.
[82] Egon Gleisberg, Hendrik Zondag, and Michel R.V. Chaudron, "An Empirical Study
into the State of Practice and Challenges in IT Project Portfolio Management," SEAA
'08: Proceedings of the 2008 34th Euromicro Conference Software Engineering and
Advanced Applications , pp. 248-257, Sept 2008.
[83] Martin Curley, Managing Information Technology for Business Value.: Intel Press,
2003.
[84] Peter Weill and Sinan Aral, "Managing the IT Portfolio: Returns from Different IT
Asset Classes," MIT Sloan Center for Information Research - Research Briefing,
vol. IV, no. 1A, March 2004.


198
[85] Jeanne W Ross and Cynthia M. Beath, "Beyond the Business Case: New
Approaches to IT Investment," MIT Sloan Management Review, pp. 51-59, Winter
2002.
[86] G. A.J. Silvius, "Does ROI Matter? Insights into to the True Business Value of IT,"
The Electronic Journal Information Systems Evaluation, vol. 9, no. 2, pp. 93-104,
2006.
[87] Steven Bliff, Aybuke Aurum, Barry Boehm, Hakan Erdogmus, and Paul
Grunbacker, Value-Based Software Engineering. Germany: Springer, 2006, p. 4.
[88] Gerald I. Kendall, "Project Portfolio Management: Principles and Best Practices," in
AMA Handbook of Project Management, 2, Ed., 2006, p. 294.
[89] C. James Bacon, "The Use of Decision Criteria in Selecting Information
Systems/Technology Investments," MIS Quarterly, vol. 16, no. 3, pp. 335-353, Sep
1992.