ENGINEERING
THINKING IN IT
PROJECT MANAGEMENT
INTRODUCTION
Uncertainty
is a central fact of life on most large IT capital investments. From enterprise
applications (e.g., ERP, CRM) to infrastructure technologies (e.g., knowledge
management, wireless networking) to IT-enabled strategic initiatives of every
flavor, a common element is doubt about whether the project will achieve its
goals, and if so, what payoffs can be expected. This uncertainty arises from
many sources—the immaturity, complexity and unpredictable evolution of the
technologies themselves; the increasing integration of technologies within and
across organizations; and the increasing emphasis on using IT to support
innovative products and customer-facing processes with hard-to-predict market
appeal. Major investments in IT clearly bear more than a passing resemblance to
other high risk organizational activities, like new product development and
R&D.
Given
the potential for major losses on IT projects, the defensive posture exhibited
by many organizations towards these efforts should come as no surprise. One
manifestation of this posture is simply downplaying the level of risk. Although
it has been demonstrated with some regularity that major IT initiatives produce
disappointing results 50% of the time or more,
this uncomfortable fact rarely makes it into the planning processes of
many organizations. Another manifestation of a defensive posture is penalizing
projects that have large risks but also large potential rewards by employing an
excessively high hurdle rate.
A
third manifestation is applying a veneer of predictability to IT investments by
demanding rigidity in project planning and execution. A final manifestation is
the tendency to treat setbacks on IT projects as arising first from the
inadequacies of the project team, rather than being inherent in the process of
undertaking uncertain ventures.
Ironically,
these defensive maneuvers are just as likely to increase an organization’s
exposure to unnecessary risk as to reduce it: downplaying uncertainty
discourages vigilance to potential problems; rigid project plans invite
corner-cutting; and a blame-the-team-first mentality deters forthright
communication about project status.
A
better approach is to assume a proactive stance that fully acknowledges and
seeks to manage uncertainty on these projects. We believe that “options
thinking,” an emerging investment management philosophy based on the theory of
real options, provides an especially promising foundation for this sort of
proactive stance.
A
real option refers to the right to acquire some real world asset without the
obligation to exercise that right.
Whenever an IT project has flexibility about which applications and
functions to implement, and when or how to implement them, real options are
present. These options can be quite
valuable, and much of the academic literature on this topic has focused on
developing appropriate tools to assist in quantifying option value. Managers,
however, do not need to acquire option quantification skills to put options
thinking to work. The bigger win comes from using real options concepts to
actively create and extract the value of embedded options that can otherwise be
difficult to see.
Our
goal in this article is to highlight how practitioners can incorporate options
thinking into contemporary IT project evaluation and management. While we will pinpoint some tools for
quantifying option value, we believe it is more important for managers to learn
to recognize what kinds of options can be embedded in IT investments; to
develop a sound intuition about how options create value; and to understand how
to manage projects so that option value that exists in theory is actually
realized in practice.
It
is a certain philosophy of project management-more so than precise
quantification that comprises the essence of options thinking. To illuminate this philosophy, we explain six
types of real options that commonly exist on major IT investment projects, with
real-world examples to show how the options create value and how value can be
increased through active project management. We will also consider the pitfalls
associated with each option, the benefits and limitations of different
approaches to valuing options, and how organizations can decide whether to
undertake the difficult process of practicing options thinking. However, our first task will be to explain
why real options are so pervasive on IT investment projects, and why they are
valuable.
HOW FLEXIBILITY CREATES OPTION VALUE ON
UNCERTAIN IT INVESTMENTS
If
uncertainty is one fact of life on major IT investment projects, another is
managerial flexibility. No other technology supports managerial flexibility
quite like IT.
One
aspect of this flexibility is that modern IT systems are themselves highly
malleable. While many kinds of assets (traditional equipment, manufacturing
plants, real estate) have a relatively fixed set of potential uses, most forms
of IT can be applied to a variety of business processes or products. Even
so-called “standard” packages come with a large array of potential
configurations and associated applications. Further increasing the flexibility
of many IT assets—at least those embedded in software—is they can be replicated
at low cost, modified if necessary, and then shared or sold. Moreover, the
level of flexibility asso¬ciated with any given IT system is not pre-ordained.
Rather, organizations can enhance flexibility by making systems more generic,
multi-purpose, interoperable, and scalable.
A
second dimension of flexibility on IT investments concerns the processes by
which IT systems are delivered. IT is particularly well suited to the use of
simulations, prototypes, pilots, and various forms of staged implementation—all
of which generate a wide variety of opportunities for incremental project
commitment.
Also,
many alternatives exist for sourcing IT, including acquiring packages to use “as
is,” modifying packages, developing custom-tailored solutions—and doing all
this as a solo effort or joint venture, and with or without the help of vendors, consultants, or system integrators.
The
twin pillars of IT project uncertainty and managerial flexibility make real
options especially pervasive on IT investment projects. But what exactly are real options, and why
does uncertainty together with flexibility enhance their value?
A real option
refers to the right to obtain the benefits of owning some real world asset
without the obligation to exercise that right. Real options are similar to
financial trading options such as calls and puts, and can be valued similarly
using options pricing models (OPMs), such as the Black-Scholes and the
Binomial. OPMs were originally developed
to assist in the valuation of tangible assets,
but have increasingly been applied to more intangible sorts of
investments, such as those related to R&D,
and information technology.
Just
as a call (or put) option confers the right, but not the obligation to buy (or
sell) a given stock at some future date, a real option provides the right but
not the obligation to acquire or dispose of some real world asset in the
future. In both cases, the value of the option comes from the flexibility to
decide whether to exercise the option depending on future conditions. This
flexibility means that option holders can participate in the upside of the
investment, but limit their losses to the cost of acquiring the option. Since
uncertainty about benefits increases the range of the potential upside outcomes
but not the downside (which is capped at zero), greater uncertainty increases
the value of flexibility and thus the value of the option.
Although
most managers can understand why increased uncertainty expands the value of a
stock option, the same principle applied to IT investments with embedded
options strikes many as counterintuitive, so we offer the following concrete
illustration. Suppose a firm is faced
with a large project to implement radio frequency ID (RFID) tagging across its
supply chain. The firm chooses to begin with a smaller pilot initiative, and
expects to proceed with full investment only if the pilot goes favorably. The
cost of the pilot is akin to the cost of purchasing a call option on the full
project—an option that will only be exercised if information gained during the
pilot indicates that the payoff for the larger project will likely be
positive. These sorts of options can change
a project that has a negative expected payoff according to conventional tools
(i.e., NPV); to one that has a significant positive value. Figure 1 illustrates
the difference in the payoffs for a hypothetical $10 million RFID investment
project with no embedded options (e.g., proceeding immediately with full
implementation) versus one with an embedded call (e.g., starting with a pilot
project that gives information about where true payoffs reside). Traditional
tools for estimating the value of such a project do not take into account this
sort of managerial flexibility, but rather, assume equal exposure to both
potential losses and gains, as in Figure 1a.
-INSERT
FIGURES 1A AND 1B ABOUT HERE
Because
options acknowledge managerial flexibility to act in ways that avoid potential
losses while preserving potential gains, a project with an embedded option is
more valu¬able than one without, as illustrated in Figure 1b. The extent of
this extra value depends on the degree of uncertainty and corresponding
variability in potential future gains or losses, and on how long the option can
be held. It also depends on whether
managers have truly adopted options thinking, and all that comes with
it—including the willingness to identify specific criteria that will later be
applied to decide if full investment should be made, and to pull the plug
without delay when these criteria are not met. Flexibility in principle does no
good unless it is properly exploited in practice.
Uncertainty
can arise from an unknown future (market uncertainty) and from inherent risks endemic
in particular IT projects (technical uncertainty). The main requirement is that some of the
uncertainty be resolvable. The mechanisms for resolving uncertainty will differ
for technical versus market uncertainty. The former usually requires that managers
“do something” to resolve the uncertainty, while the latter can often be
resolved by simply waiting (and, of course, paying alert attention to the
market). Yet, the same project structuring elements can advance both goals
simultaneously. Scheduling a pilot project or a small scale initial
implementation can provide information that reduces uncertainty about technical
feasibility, while simultaneously allowing for an elapse of time during which
some market uncertainty will be resolved.
There
is of course no free lunch in the world of traded financial options, because
the purchase price of an option at any moment reflects the market’s current
best estimate of what the option is actually worth. However in the case of real
options, there isn’t necessarily a strong relationship between what an option
costs to acquire, and what the option is actually worth, so quite valuable IT
options can often be created relatively inexpensively. Thus, managers that
employ options thinking stand to gain a considerable advantage, especially in
fast moving, unpredictable environments where real options tend to be most
valuable and plentiful.
FROM
OPTION VALUATION TO OPTIONS THINKING
Real
options concepts not only allow an organization to more accurately assess
uncertain IT investments, but perhaps more importantly, can guide managers in
how to actively create and extract value.
This is the heart of options thinking. The key to understanding how
options create actual value lies in the distinction between what an organization
must do on a project, versus what it may do. For those things an organization
must do, there is (by definition) no flexibility, and so traditional analytic
tools (such as NPV and ROI) that place no economic value on flexibility are
appropriate.
However,
for those things a firm may do, value is created by actively structuring those
elements as an option.
This
suggests managers can enhance value creation with two general strategies
1.
shifting project elements that are part of the baseline
implementation from must do to may do status; and
2.
performing a systematic search for opportunities beyond
the baseline implementation that represent additional may do elements. In
options terms, the first sort are referred to as operating options, in that
they relate to the operational aspects of a project. The latter sort are
referred to as growth options, in that they refer to the opportunity to grow
the project’s scope through follow-on investments beyond what was initially
anticipated. Figure 2 illustrates the difference between a traditional project
and one driven by options thinking.
-INSERT
FIGURE 2 ABOUT HERE
Effective
options thinking requires that managers do three things well:
a)
recognize and enhance opportunities to create options
with IT
b)
value these options (in some way), and
c)
manage projects to fully extract this value. We address
each of these tasks in the following sections. First we provide six examples of
options thinking in practice that illustrate how some organizations have
recognized, valued and managed projects according to the logic of real options.
Then we provide some more detail on the latter two tasks, valuing and managing
real options.
SIX
EXAMPLES OF REAL OPTIONS IN PRACTICE
Embedded IT
options can take many forms, including the options to:
(1) Stage investments,
(2) To abandon investment
(3) Defer initiation of
investment,
(4) To create growth
opportunities based on an initial investment
(5) To change the scale of
investment, and
(6) To switch assets created
by the investment to another use Gaining
an appreciation for these option types and how each adds value will make them
easier to recognize in practice. In addition, all vary somewhat in terms of the
conditions under which they provide the most value, and the different pitfalls
and challenges associated with managing them.
It
is worth noting that the same project can embed more than one type of option,
and it is not always completely clear how a particular option should be
classified. However, our goal is to
provide examples that give the richest illustration of how to manage options in
practice, rather than ones that can be most neatly classified. In three instances the projects we identified
involved a formal OPM. We also found three examples that were managed as real
options, even though options were not formally considered as part of the
justification. These latter examples are
included to show that firms can employ guide¬lines that are consistent with
options thinking without having to adopt a sophisticated valuation methodology.
Example 1: The Options to Stage and to
Abandon - Carlson Hospitality
In
practice, most large IT projects are divided into stages for the purpose of
resource planning and setting milestones for project tracking. However, the mere existence of stages in a
project does not by itself create embedded stage options. To create value using
stage options requires an active management approach where execution of each
stage is made contingent on a reassessment of the costs and benefits of
completing that stage at the time the stage is reached.
By
then team members will be more experienced in the project domain from having
completed prior stages and so better information will exist at about the actual
costs and benefits of completing the stage. In addition, business requirements
or opportunities often change in ways that increase or decrease the importance
of what a given stage delivers, and so the team will be better able to
recognize and avoid investing in stages that no longer have a worthwhile
payoff. In summary, stage options
create value by providing the chance to alter or terminate a project before
each new stage of funding, based on updated information about costs and
benefits.
In
practice, stage options often overlap with other options, such as abandon,
change scale, and strategic growth. In cases where completion of each stage
does not produce a useable system, but is merely a necessary condition to
proceed to the next stage, this is a form of the abandon option
(stage-abandon).
Stage-abandon options can be created by
developing “throw away” prototypes or following the traditional waterfall SDLC
(i.e., analysis, design, construction, implementation) but with a formal
go/no-go decision for each phase, such as in the spiral model of
development. Conversely, when early
stages produce a useable, but smaller scale system that can subsequently be
scaled up, or to which additional functions can be added, the overlap is with
the option to change scale (stage-scale) and growth options (stage-growth). The
latter sort of staging options are naturally preferable, as they produce a useable
asset at the end of each stage—but they are not always feasible, and even a
stage-abandon option can create considerable value in the right circumstances.
Carlson
Hospitality Worldwide’s recent implementation of a new Customer Reservation
System (CRS) illustrates how a project
can be reconceptualized to create embedded stage-growth and stage-abandon
options.
The
project was initially pitched as a $15 million all-at-once investment. When that pro¬posal was soundly rejected, the
IS team reconceptua¬lized the project as a set of nine separately
imple¬men¬table “chunks,” each of which had to produce a direct business
benefit. Though no formal OPM was used, it was clear that management understood
how staging can create value through increased flexibility: “… [the IS team]
managed to get funding for the first chunk, and soon they started rolling out
the new CRS…along the way, they would insert one chunk and ditch another as
needed to get the biggest payback, while staying open to sugges¬tions…”. Furthermore, IT managers structured each
stage to be implemented gradually, so that at any point the roll-out of a given
stage could be reversed, thus creating additional stage-abandon options.
This
example illustrates a key tactic for increasing the value produced by embedded
stage options, which is to ensure that each stage actually produces an
identifiable benefit beyond simply enabling subsequent stages. Otherwise it is
difficult to develop an estimate of net benefits of performing that stage in
isolation. This suggests that a project
be divided into incremental units of functionality, each of which can be
implemented separately even if no further increments are implemented. A second useful tactic is to schedule stages
with the most uncertainty as late as possible in the overall project lifecycle,
since the value of an option increases the longer the option can be held.
This
tactic will be even more valuable if project managers segregate functions with
the most uncertainty from functions with the least uncertainty. This can be
done by combining the most uncertain functions together into the same stages,
or even better, by isolating uncertain functions into their own stages. This
sort of modularization of project effort (which creates flexibility in the
process) is different from modularization of the functions in the delivered
system (which creates flexibility in the result), although it seems likely that
pursuing either one will make it easier to achieve the other.
Potential
Pitfalls of Stage-Growth and Abandon Options.
Not
all projects can be divided up to create embedded stage options. Some¬times a
firm must make a binding commitment to a project as a whole, such as when a
project is so large that external funds must be raised, or when co-investment
from other parties are required. Or, the
payoffs from investment may depend on whether a self-reinforcing adoption
process reaches critical mass, meaning that a potential investor must, in
essence, play to win or not play at all.
In such all-or-nothing investment situations, valuable options may still
exist in the form of the option to defer (as described in the next section).
Even
when a project could be staged in principle, managers may have difficulty
crafting stages that conform to the above criteria. Another pitfall is that
stakeholders may prefer all-at-once funding to obtain maximum control over a
project’s fate, and to have more time to get a troubled project back on track
before facing the next round of justification. In practice, it can be difficult
to distinguish the ordinary setbacks that occur on almost most
implemen¬tations from those that
indicate embedded options should not be exercised—thus raising the possibility
of premature cancellation of valuable may do project elements. A final pitfall of stage-growth options is
they may require tem¬porary interfaces and reworking previously implemented
functions. Some organizations may resist
the idea of incurring these certain expenses to enable uncertain benefits later.
In some cases these extra expenses may be so high that they overshadow the
value of the stage option altogether.
The
main pitfall associated with abandonment, a second kind of option on the
Carlson CRS project, is that many projects take on a life of their own and can
be difficult to terminate, as illustrated in the large literature on escalation
of commitment. In fact, some observers
see this as perhaps the central challenge associated with options
thinking. People involved in a project
will naturally become personally vested in seeing the project succeed, and so
terminating projects can carry intangible costs related to morale. Also, those involved may suffer a loss of
credibility, owing to ambiguity about whether project failure was due to project
team deficiencies or factors beyond their control. Finally, abandoning a
project can have unanticipated side effects.
For
example, when the mayor of Denver effectively abandoned the computerized
baggage handling system at the Denver International Airport, he encountered
strong, and apparently unanticipated, resistance from United Airlines which
sought to block the city’s exit plan.
Furthermore, the perceived waste of taxpayer money generated
considerable criticism for the city government.
Granted, a firm that explicitly conceptualizes a project as carrying an
abandon option and justifies the project on that basis should find it easier to
exercise an option to terminate compared to a firm that unexpectedly finds
itself questioning the value of proceeding—but nevertheless, we believe this option
will be the most difficult to exercise in practice until options thinking
permeates an organization.
Example 2: The Option to Defer Investment
—Yankee 24
An
option to defer exists when a decision on whether or how to invest can be
delayed for some period without imperiling the potential benefits. When uncertainty is high but can be resolved
over time, deferral options can be surprisingly valuable. A good example of a
large project with an embedded deferral option was Yankee 24’s implementation
of a network infrastructure to support point of sale (POS) debit cards for New
England merchants. All of the elements
listed above that tend to lead to valuable deferral options were present in
this case.
Yankee
first began considering the POS network investment in 1987 when considerable
uncertainty existed in four key areas:
1)
How fast would retailers (who would bear the brunt of
total infra¬structure investment cost) adopt POS debit cards as a payment
option?
2)
Would Massachusetts, which comprised 50% of the New
England market, revise banking regulations that currently discouraged POS debit
adoption among smaller businesses? Would consumers in New England take up POS
debit cards at the same rate as other markets, such as California, where POS
debit had been introduced earlier? and
3)
Would a competing network signal an intent to enter the
POS debit arena? Yankee understood,
correctly, that by simply waiting much of the uncertainty about payoffs could
be resolved. For example, they could observe debit card adoption rates in other
more mature markets and lobby the Massachusetts government for favorable
legis¬lation. And meanwhile, the upside
opportunity was not in serious peril for at least three years, because this was
how long Yankee thought the most likely competitor would need to establish the
necessary infrastructure. Yankee, by contrast, could move much more quickly
because it had most of the necessary infrastructure already in place.
A
retrospective options-based analysis of the Yankee case by two IT researchers
determined that the optimal time for Yankee to defer investment was three
years. This three year deferral option
was estimated (using the Black Scholes OPM) to be worth approximately $150,000.
This compares with an estimated NPV for initiating the project immediately in
1987 of minus $80,000. Interestingly, Yankee did, in fact, defer entry for
three years, which gives an example of managing an investment in ways that were
consistent with options thinking without adopting a formal OPM.
Possible Pitfalls of Deferral Options.
There
are two main pitfalls associated with this option. The first is the potential
for erosion of project benefits with time. This may occur when first mover
advantages exist and there is a danger of preemption by another firm, or when
it can be expected that other firms will quickly follow (thus shortening the
window of competitive advantage).
In
fact, as will be discussed later in the section on valuation, the possibility
of value eroding with time runs counter to the standard OPM assumption that
longer deferral periods increase the value of options. The second pitfall stems
from the fact that a firm must often gain direct experience with an innovative
technology in order to be in a position to resolve uncertainty about its
potential uses and benefits.
Organizations that make a habit of deferring investments may therefore
suffer a general loss of innovative capa¬bilities and may lose the ability to
appreciate new technologies, and thus may find themselves “locked out” of not
only the current opportunity, but future opportunities as well.
Example 3: Options that Provide Growth
Opportunities — A European Automaker
An
embedded growth option exists when an initial baseline investment opens the
opportunity to pur¬sue a variety of potential add-on projects. Unlike the other options described so far,
which produce value mainly by limiting the extent of potential losses in the
event of unfavorable circum¬stances, growth options add value by increasing
potential gains in the event of favorable circumstances. As firms increasingly
rely on IT to be innovative, they step into a terrain where it is much more
difficult to pin down what a system should do.
Because the IS unit's knowledge of the application domain of a novel
system is likely to be embryonic at the outset, both the growth and switch
options matter more when firms seek to "tilt the playing field" using
IT.
A
case study of an ERP implementation project by a European auto maker provides a
well-developed example of how to value IT growth options in practice. The base project, which involved upgrading
from SAP’s R/2 system to R/3, was expected to cost $1.85 million and to produce
about $1.45 million in operational savings, leading to negative NPV of about
$400,000.
The
base implementation by itself was not cost justified, but managers realized
that the greater robustness and flexibility of the R/3 system would enable
several potential follow-on projects that would otherwise have been infeasible,
including introduction of EDI-based purchasing and invoicing, workflow
applications for sales, engineering document handling, and web-based ecommerce.
The NPV of these additional applications was estimated to be $150,000—still not
enough to offset the expected loss on the base implementation
Thus,
had the project team simply expanded the bounds of the initial must do project
to include these elements, the project would have remained unjustified, with a
negative NPV of $250,000. However, the
project team took a different approach, which was to recognize that the add-on
projects should be treated as may do elements that would only be pursued in
favorable circum¬stances, and to value them accordingly using an OPM.
The
resulting Black-Scholes estimate for the option value of the add-on projects
was $650,000—enough to make the overall project worth undertaking—and based on
this expanded estimate of value managers did proceed with the implementation.
In this case,
the value of having the flexibility to say “no” to one or all of the add-on projects
if the base implementation went poorly or other unfavorable events transpired
(e.g. an adverse change in business environment) was over $500,000. (To put
this amount in perspective, the add-on projects were expected cost $2.2 million
to implement and maintain.) In this
case, the reason for the high relative valuation of the growth options was that
most of the follow-on projects had a negative projected NPV, and also high
uncertainty in the range of possible payoffs (as with the hypothetical example depicted
earlier in Figures 1a and 1b).
-
IT platform implementations, by their very nature, will
tend to have a variety of embedded growth opportunities. As the above example
illustrates, managers will gain the most by attempting to iden¬tify and value
these opportunities as embedded options when: the base project has an unclear
payoff taken alone
-
the NPV of the add-on projects is not enough to give
the project an overall positive payoff, and
-
there is much uncertainty regarding the net payoffs of
the add-on projects.
Potential Pitfalls of Growth Options.
Growth
options are most likely to be present on more innovative projects and on those
that implement a platform for future applications. The main challenge here is the difficulty of
estimating option values (due to ambiguity about potential future cash flows)
and uncertainty about the appropriate value for option model parameters. These
challenges are compounded to the extent that longer time horizons are involved,
as is often the case with growth options.
Example 4: The Option to Change Scale -
Cypress Communications Authority
An
embedded option to change scale exists when the resources allocated to a
project can be contracted or expanded in response to future conditions, or when
the production system enabled by a project can be scaled up or down with
comparative ease. If unexpected technical barriers are encountered—or a change
in business conditions reduce the value of the intended system—a project with
an embedded scale-down option can be reduced in scope, and some project
resources reassigned. Thus the scale-down option may be viewed as a milder form
of an abandon option. Conversely, a project structured to increase the scope of
the resulting system in the event of favorable future conditions has a scale-up
option that is similar to a growth option.
An
initiative by the Cypress communications authority (CYTA) to enable a major
network expansion provides a case of an IT investment that created a valuable
scale-up option. In 1992, CYTA
anticipated that Cypress’ eventual entry into the European Union would warrant
a significant expansion of its telecommunication network. Yet, they determined
that this expansion would only be feasible if a complementary investment was
made in upgrading the information system used to support the daily operations
of the authority.
The
IS upgrade would produce some immediate benefits (e.g., improved network
utilization, productivity improvement, overtime reduction) even if the future
network expansion were not pursued, but the expected value of these immediate
benefits was not enough to justify the IS project (the NPV was estimated to be
-£1.7 million). However, the value of the option to expand the
telecommunication network in the future should conditions warrant was estimated
to be £2.55 million, resulting in an overall valuation for the IS development
of £0.85 million, enough to justify proceeding with the project.
Possible Pitfalls of Scale Options.
The pitfalls associated with scale options
depend on whether the option is to scale up or down. The option to scale up can
add to project costs, and some organizations may resist adding such costs in
return for an uncertain future payoff.
Conversely, in the case of scale down options, there may be
resistance—albeit less severe—to exercising the option in practice similar to
that for the abandon option.
Example 5: The
Option to Switch use — TWA
An
embedded option to switch use exists when an IT asset developed for one purpose
can be redeployed to serve another purpose.
This option is apt to be more prevalent and valuable on software
development projects as compared to the kinds of physical assets (manufacturing
plants, real estate) for which real options analyses were originally intended.
Software is more malleable than physical assets and has a very low cost of
reproduction. This means that software applications can be more easily
repurposed without necessarily having to discontinue use of the system from its
original application.
TWA’s
development of a computer-aided software engineering (CASE) “template” for
their Frequent Flyer Benefits (FFB) shows how to create a switch use
option. A CASE template is a detailed
design model that automatically generates part or all the program code required
to implement the target system. The
automatic code generation typically supports various programming languages and
operating system environments, and this represents one key form of
flexibility. However, more impor-tantly,
the approach facilitates tailoring of the system to different business
requirements.
The FFB system
was originally developed for TWA’s own use, however, the CASE template
facilitated subsequent sale of the system to Canadian Air. While any software
system can, in principle, be sold to another firm, the likelihood of another
firm being interested and what they will pay and thus the value of the embedded
switch use option depends on how easy the system is to understand and modify.
In this case, the use of a template allowed Canadian Air to produce a
customized system in eight months, as compared to the 18 months needed for a
from-scratch development. The rapid modifi-cations were possible because of:
-
The explicit depiction of business rules and other
design elements in the CASE template (rather than having this buried in program
code);
-
The ease of generating operational prototypes, which
facilitated requirements analysis and communication with end users; and
-
The ease of modifying a design model and regenerating
program code compared to modifying the program code itself.
-
Potential Pitfalls of Switch use
Options.
The
main potential pitfall of this option is that it can add extra time and expense
to the initial development project. Some
researchers have estimated that making program modules generically reusable which
may be seen as the ultimate in creating switch use options can cost several
times as much as creating single use modules.
In some cases, the cost of creating a switch use option could exceed the
value it produces.
The
case studies considered so far provide examples of each kind of option and
their potential pitfalls. We now turn to a sixth and final case that provides a
particularly illustrative example of how several types of real options can
simultaneously be embedded in the same project.
Example 6: Stage, Growth and Switch use Options
Starbucks Coffee Company
Starbucks’
recent introduction of their pre-paid card was a project that had embedded
stage, growth and switch use options.
Though a formal options valuation methodology wasn’t used, the approach
to managing the project provides an excellent example of options thinking in
practice.
The
original intent for the Starbucks card was simply to speed checkout in a
business where cash transactions dominate. Managers were unsure about demand
for such a card, and so they consciously chose a bare-bones approach to the
initial implementation rather than a more ambitious rollout. The card used a
simple, stand-alone magnetic stripe design, which meant the only infrastructure
upgrade needed was some reprogramming of cash registers to read the cards.
Later,
after demand for the card was clear, Starbucks went the additional step of
providing online registration of the cards, which allowed users to replace lost
cards, reload cards with more money, and view transaction histories.
This
second stage could easily have been anticipated and included from the start.
However, by segregating this functionality into a separate stage, managers
created an embedded stage option. If the card had flopped, the expense of this
extra functionality would have been avoided.
After
the second stage was completed Starbucks managers realized that the card could
do much more than simply speed check out: it could be enhanced to serve as a
platform for a customer loyalty program. As a third stage, the card was
enhanced to support loyalty points redeemable at Starbucks based on purchase
volume, entry in occasional sweepstakes, and email notification of in-store
promotions and new products. Since this add-on project created a new asset
(e.g., a loyalty program) rather than changing the value of an existing asset
(as with online registration for the initial pre-paid card), it represented a
growth option rather than a scale-up option.
By
implementing this program, Starbucks not only increased loyalty, but perhaps
just as importantly, created a database of customer behavior. Now they can
tell, for example, that card holders visit a Starbucks café 17 times a month,
on average.
Most
recently, Starbucks has taken a fourth step that illustrates an embedded switch
use option similar to the TWA FFB case. They have collaborated with Visa USA
and Bank One to introduce a co-branded card that combines the functionality of
the enhanced Starbucks prepaid/loyalty card with standard Visa credit card
functionality. Since all of the prior
functionality of the pre-paid card (programming of cash registers, online
registration) could be reused to support the new dual use card, this can be
seen as a switch use option.
It
is worth emphasizing that there is no evidence that Starbucks managers had
planned from the start to consider any specific potential enhancements; rather
their intent was simply to “keep their options open” by using an incremental
commitment approach.
However,
this sort of alert incrementalism is a central principle of options thinking.
One thing managers apparently did not do was
to identify at the start what enhancements might be worth pursuing later, and
to estimate a value for each enhancement using an OPM. As it happened,
Starbucks managers were confident that at least the initial step was worth
pursuing and so putting a value on options was not necessary.
However,
if things had been different and the initial step was less clearly justified,
then estimating the option value of potential enhancements could have been
crucial in justifying the initial project, as was the case in the ERP and
network expansion examples described earlier. Thus, it is important that
managers interested in real options be acquainted with approaches to estimating
option value, a topic we consider next.
Valuing Real Options
By
increasing the ratio of what may be done to what must be done, and structuring
what may be done as an option, managers create value even if they do not go the
extra step of quantifying what this value is. However, managers that do develop
option value quantification skills will stand to make better decisions on those
occasions where option value is crucial to justifying a project that does not
appear to pay off from a traditional NPV standpoint.
As
prior examples show, the quantified value of a real option is not always
intuitively obvious and can change a decision on a worthwhile project from a
no-go to a go. Also, estimating option value can help with more tactical
decisions, for example, whether to build in flexibility to support either of
two standards that are currently battling it out in the market place, rather
than placing a bet on only one standard.
The
most commonly used tools for valuing real options are the Black-Scholes and the
Binomial OPMs. Some of the IT examples
already mentioned used the Black-Scholes, and the associated articles each
provide excellent discussions of how to apply this model in practice. The Binomial model has less stringent assumptions than the Black-Scholes
and is likely to receive increasing attention from options researchers. In a recent article, Copeland and Tufano note
“[the Binomial model] captures the contingencies of real options and addresses
nearly all of the more commonly voiced criticisms of using option theory to
manage those contingencies”. In
addition, some newer OPM variants have been developed that are even more flexible
than the Binomial model.
The
use of OPMs on IT investments is subject to several challenges, starting with
concerns about “transparency.” The Black-Scholes model in particular is based
on a complex, five-parameter formula can seem like a black-box to anyone
lacking a solid grasp of calculus.
Other
complaints have been raised about the absence of a traded market for IT assets,
which leads to difficulty in estimating options parameters and concerns that
analysts may “fudge” these parameters; the absence of a fixed time by which an
IT option must be exercised; and the fact that the value of an IT initiative
may erode with time due to loss of potential for competitive advantage. We believe that counter arguments and
remedies exist (see Sidebar 1 “Options Valuation Challenges”) that make the use
of OPMs, while not perfect, still generally superior to traditional NPV
approaches that place no quantified value on flexibility at all.
Nevertheless,
adopting formal OPMs today will require that senior management be open to
considering leading edge valuation techniques, and even then, a considerable
education effort will be required.
However, these hurdles should be lowered as more managers get exposed to
the use of OPMs in business schools and at leading firms such as Merck, Hewlett-Packard, and Intel.
After all, it took many years for the NPV approach to make the leap from
textbook to standard organizational practice, and real options have only
recently become a fixture in finance and MIS textbooks.
PUT SIDEBAR ABOUT HERE
Alternatives
to Formal OPMs
If
it is expected that senior managers will (for whatever reason) resist the use
of formal OPMs, then decision trees or even qualitative option valuation
approaches provide viable alternatives. Decision trees, unlike OPMs, are highly
transparent. In the ERP example above the framing of proposed investments in
the form of a decision tree is what ultimately convinced management, rather
than the OPM estimates per se.
The
main limitations of decision trees are first, that the complexity of a tree can
increase rapidly as more alternatives scenarios are incorporated, and second,
that there is no straightforward way to determine what the correct risk
adjusted discount rate for the whole tree should be.
Yet,
decision trees can be expected to come closer to correctly valuing a project
that has important embedded options than conventional approaches that place the
value of flexibility at exactly zero.
We
also think that managers can gain considerable benefit from using structured
but qualitative approaches that help them to think about option value more
intuitively. However, if managers are
to rely on intuition they must be on guard against systematic biases. In a separate research study, we found some
interesting indications of bias in how managers viewed different kinds of
options (see Sidebar 2 “Is Options Thinking Real”).
The following
attributes increase the importance of using real options concepts when
estimating a project’s value:
-
Embedded options clearly exist due to high uncertainty
in combination with flexibility in the systems delivery process and/or in the
delivered system itself. (Previous
sections have provided examples to assist managers in recognizing when this is
the case.)
-
The project is going to be evaluated quantitatively “by
the numbers”. Given that managers are
going through the effort of estimating cash flows, the incremental effort of
employing OPMs is, surprisingly, not that great, although there is, of course,
a learning curve associated with gaining competency in the applications of such
models.
-
Traditional quantitative analysis produces a result
that leaves the value of the project with a negative NPV—but not so negative
that the potential value of options is overshadowed. It is when options value might well change the
decision on whether to proceed with a project that using an OPM will be most
important.
-
Managing Real Options
While
putting a number on the option value of project is not a mandatory part of
options thinking, it is essential that projects at least be managed in such a
way that the potential value that has been created by building in options
actually gets extracted. To put this
another way, projects must be managed so that options contracts are honored.
When
managers seek to create value by embedding options, they are in effect writing
an options contract.
What
this contract says is that at some specific future time they will compare the
revised estimated value of proceeding with further investments against the
revised estimated cost, and will proceed if, and only if, this value exceeds
the cost—just as the holders of financial options only choose to exercise
options that are “in the money” at expiration.
Thus,
an options contract is a commitment to employ certain principles in deciding
whether the element will be done, rather than binding commitment to actually do
a project element.
An
organization that fails to honor such contracts will not only systematically
over value options, but will also lose credibility and thus the discretion to
write such contracts in the future. As a result, the ability to honor options
contracts is an essential element of options thinking.
Yet
creating an organization, a process and culture that ensures that options
contracts will be honored may present some organizations with special
challenges. A few examples illustrate
the point.
One
of the easiest ways to create option value on a project is simply to defer
non-essential features to a separate stage, as Starbucks did with the pre-paid
card. This amounts to changing a fixed commit¬ment into a call option.
Getting
stakeholders to give candid opinions about which features are essential and
non-essential requires trust that options contracts on non-essential items will
be honored.
Also,
stakeholders must understand that honoring the contract does not mean the
feature will definitely be addressed later. Rather, it means at some future
date the project team and the requestor will jointly determine whether the
option is worth exercising according to a predefined set of criteria.
As
a second illustration, consider an organization that has proceeded with a “now
or never” investment opportunity owing to the value associated with an abandon
option.
This
amounts to writing a put contract on the project.
However,
as previously argued, these sorts of put options can be difficult to honor
because of the negative signal project termination may send about the project
team’s abilities. Indeed, many of the
qualities we seek to instill in project team members (positive thinking, personal
responsibility for outcomes) can work against project termination.
Thus,
firms that use real options as part of the project justification process must
put managerial guidelines in place that allow sound options contracts to be
created and honored in practice. We offer ten such guidelines in the Sidebar 3
“Guidelines for Bringing Options Thinking into Project Management.”
PUT SIDE BAR ABOUT HERE
Should You Adopt?
As
just discussed, options thinking requires major changes to project management
and complimentary changes to organizational culture. So managers need to assess the prevalence of
real options and their readiness to undertake the challenges of options
thinking before taking the lead as an early adopter.
It
was a little review of my 7 ENGINEERING
THINKING IN IT PROJECT MANAGEMENTthank you
for visiting this blog . May be useful for friends and can be a reference for
future success . If there are errors in this article . I apologize profusely .
If there are criticisms and suggestions , you can attach it below.
____________SEND
REGARDS FOR SUCCESS_____________
thanks
GBU
