ENGINEERING THINKING IN IT PROJECT MANAGEMENT

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