Small Business Resources, Business Advice and Forms from AllBusiness.com

Keeping it sophisticatedly simple in R&D project management.

By Bordley, Robert F.
Publication: Engineering Economist
Date: Tuesday, June 22 1999

INTRODUCTION

RECIPE FOR STONE SOUP

Souder and Mandakovic [4] observed that "today, there is a growing recognition that project-selection models should be used to ask questions of the entire organization" and that project-selection models are "decision aids" to facilitate communication.(1) Indeed,

work at General Motors [2] suggests that project-selection models, properly used, are especially useful in stimulating the rethinking of existing criteria and objectives as well as the development of new alternatives.

A project-selection process can stimulate the rethinking of existing criteria and objectives by showing their implications in the light of concrete alternatives. It can stimulate the development of new alternatives by identifying the strengths and weaknesses of existing alternatives in the light of the existing criteria and objectives - thus suggesting the possibility of hybrid alternatives that combine the strengths of several alternatives and avoid their weaknesses.

To facilitate communication, a project-selection process must be able to communicate how different projects rate on various important aspects to those individuals (R&D project leaders, R&D implementers and R&D customers/technology strategists) who can create or modify R&D projects and project criteria. Because our management had decided to use net present value (NPV) as a criterion, this implies that we needed to make the NPV calculation simple and transparent. In other words, we needed to create a "back-of-the-envelope" NPV formula that would stimulate discussions among project leaders, implementers and customer/strategists (the iron triangle) on how to develop projects of greater value to the company.

STANDARD APPROACH TO CALCULATING NET PRESENT VALUE

Matheson, Menke and Derby [3] enunciated the standard decision-analytic approach to assessing NPVs for research projects. It hinges on assessing three kinds of factors:

(1) Technology-related Factors

(a) Technical benefit: Amount by which the project, if technically successful, can potentially increase product sales, increase customer willingness to pay for a product or decrease product costs (above what the company would have done without the project). Note that assessing this factor often requires direct marketing input.

(b) Technical risk: Probability the project will successfully achieve its technical benefit by the project's deadlines given the project's current budget.

(c) Technical cost: Research costs associated with the project.

(2) Implementation-related Factors

(a) Volume: Number of units (products, plants, product programs) over various years upon which the project's results could be implemented, if the project were technically successful.

(b) Implementation risk: Probability of the project's results being implemented on this volume, given the project is technically successful.

(c) Implementation cost: Costs associated with implementing the project (i.e., building new plants, etc.).

(3) Strategy-related Factors

(a) Discount rate the company attaches to future cash flows.

These data are traditionally collected (or sometimes even estimated) by a single corporate group that inputs the data into a model to estimate the project's NPV. One then displays tornado diagrams to executive management to indicate how changing various variables can affect the overall value criterion.

This represents the standard kind of decision analysis in which a single decision must be made by a single centralized group of individuals. But as we noted before, we are more concerned with creating a decision analytic environment in which a wide variety of project leaders, faced with their own unique circumstances, independently make high-quality decentralized judgments about which projects they individually will pursue. Given this environment, the criteria upon which projects will be judged should be communicable and transparent to a wide variety of decentralized and very busy decision makers. So the traditional approach of creating a centralized Excel spreadsheet to be used by a centralized core team for evaluating all projects is inappropriate.

To develop a decision analytic approach appropriate for the decentralized environment, we require:

(I) A transparent, easily communicable formula for assessing the project's benefits for a typical unit (product, plant or product program) affected by the project.

(II) A transparent easily communicable way of combining a project's per unit benefits with the number of units it affects over time to estimate discounted cash flow.

(III) A transparent, easily communicable way of combining a project's expected NPV at its current funding level with other information to estimate how NPV will change if we add or subtract funding from the project.

In the next section, we address the first issue using standard techniques from additive multiattribute utility theory [5]. To address the second issue, we specify a generic formula for how innovations roll out over time. This leads to a simple multiplicative formula for NPV.

To address the last issue, we discuss how the techniques from our first two sections were used to estimate NPVs for 300 research projects at General Motors. Upon examining these 300 NPV estimates, we found that project value appeared to be an exponential function of project funding level. This exponential relationship implies that we can infer how a project's current NPV changes given a change in funding simply by specifying one further point - the potential project NPV attainable if an arbitrarily large budget were devoted to that project. This empirical regularity provides a solution to our third and last issue. In our conclusions, we then infer a simple formula for a project's optimal budget allocation as a function of the attributes of NPV.

Together, these results give us a very transparent system for measuring project benefits, one that can be easily communicated to the iron triangle of project creation: project leaders, project implementers and project customers/strategists. It is this focused dialogue (or trialogue) that generates most of the value associated with a project selection process.

SIMPLIFIED BENEFIT ASSESSMENT

Standard estimates of a project's value allow the analyst to express those benefits as increases in customer willingness to pay, cost reductions or sales increases. But because any sales increase potentially involves taking sales from competitor products and the company's own products, calculation of sales increases must consider competitive response, cannibalization, etc. Because these considerations make sales estimates fairly obscure to local project leaders and their internal customers, we focused on simplifying the calculation.

Note that if a project increases sales, the company could institute a hypothetical price increase that induces sales losses exactly offsetting the sales increase. So the value of a project that potentially leads to sales increases is equivalent to the value of a project that leads to no sales increases but increases customer willingness to pay by the amount of the hypothetical price increase. Hence - except in instances where a technology's main benefit is entering a totally new market - whether one chooses to estimate benefits in terms of marginal willingness to pay or sales increases becomes a matter of taste. For simplicity, we chose to estimate benefits in terms of marginal willingness to pay.

But estimating marginal customer willingness to pay was also a source of nontransparency in our analysis. One approach to estimating customer willingness to pay for a technology is to run a marketing clinic or ask for a marketing analyst's best guess. While these approaches are certainly legitimate, running a marketing clinic on each possible project deliverable clashes with the "back-of-the-envelope" nature of the NPV formula we wish to generate. Likewise, asking for a marketing analyst's best guess potentially introduces some subjectivity into the process - possibly motivating engineers to lobby this marketing analyst to "endorse" their technology. While this could lead to more accurate estimates of project value, this possible gain in accuracy is more than offset by the perverse organizational incentives it might introduce.

To avoid these concerns, we consulted our technology strategists and constructed a list of 30 "benefit attributes" (e.g., reduced lead time, variable cost reduction, increased fuel economy, reduced emissions, etc.). We then:

(1) Constructed benchmark estimates for the value of a unit change in each attribute. Thus the benchmark value for a unit change in fuel economy was just the total cost savings the average consumer would incur from buying less gasoline as a result of the unit increase in fuel efficiency.

(2) Had our strategists adjust these estimates to give importance weights (dollars per unit improvement in an attribute) to each of our attributes.

These importance weights were publicized so that all project leaders knew the strategic importance assigned to each attribute. In addition, strategists could assign much higher weights to those attributes that were important to attaining corporate strategic objectives. Hence our NPV estimates reflect not only customer willingness to pay but also corporate strategic priorities.

Doing this obviously assumes that a ten-unit improvement in an attribute was worth ten times as much as a one-unit improvement. Making this approximation plausible required, in some cases, a transformation of attributes. Thus quadrupling fuel economy - the number of miles attainable from a gallon of gas - is not worth twice as much as doubling fuel economy. But suppose we replace the attribute, fuel economy, by the attribute, gasoline consumption - gallons of gas required to travel one mile. Cutting gas consumption by a factor of four is, arguably, worth approximately twice as much as cutting as consumption by a factor of two. (This notion of choosing attributes to be linear in value is consistent with standard precepts of multiattribute utility theory [5].

SIMPLIFIED DISCOUNTED CASH FLOW FORMULAS

DISCOUNTED CASH FLOWS OVER TIME

The main source of complexity in the NPV calculation stems from discounting cash flows over time. Much of this complexity stems from the difficulty of modeling the number of units affected by the at each point in time (the technology rollout). Because most individuals have very little idea of how many units will be affected in future years by an, as yet, undeveloped and untested product, we can potentially specify a generic formula for how the technology is rolled out over time. Such a generic formula should clearly postulate low volume initially followed by increasing volume up to some asymptote. Using the simplest possible modeling assumptions is often critical to securing customer buy-in. At GM, the linear trend model was the easiest model to communicate and motivate. In the linear trend model, there is an initial introduction of N(0) units at time T that ramps up linearly over the course of At time units to a final volume of N([infinity]) units. At that point, sales stay constant at this final volume level. (The exponential growth model is an alternative model that, in some ways, is mathematically simpler. But the Gompertz model - which might be physically more realistic than either the exponential or linear trend model - is also easily used. We discuss both these alternatives in our Appendix.)

Then the NPV of the project's payoffs is a function of

(a) Time, T, until the product is introduced into the marketplace.

(b) Corporate discount rate, r. Many companies set r by adjusting the risk-free interest rate upward to compensate for perceived optimism in the numbers used in business cases. As is well-known, explicitly assessing technical and implementation probabilities may eliminate the need to compensate for optimism and would justify setting r equal to the risk-free interest rate. But for political reasons, the company decided to enforce a common discount rate across all business cases (including those from R&D, vehicle development and new business ventures) even if it would introduce distortions. Hence we used the standard corporate discount rate that - in most companies - ranges from 12% to 20%.

(c) Initial price premium per unit, B, that the company can extract from an innovation.

(d) How fast that premium shrinks over time as competitors emulate the innovation. (We model this by specifying a decay rate, [r.sup.*].)

(e) Eventual penetration of the innovation, N([infinity]), assuming successful implementation.

(f) Number of years, [Delta]t, that will lapse between when an innovation is initially introduced and when it first achieves its maximum penetration.

If we let R = r + [r.sup.*], then the NPV is

[Mathematical Expression Omitted]

where s = (1 - exp(-R[Delta]t))/[R[Delta]t]

When the product of the interest rate, R, and the time to ramp up, [Delta]t, is small, then s is approximately 1 - (R[Delta]t)/2. (In fact, when R[Delta]t can be assumed to be zero, s = 1, and the NPV is the value of a perpetual annuity starting at time T.) Suppose we also let L = (1/R) denote the effective time horizon so that an annuity over an infinite time horizon at an interest rate of R is equivalent to an annuity over the effective time horizon at a zero interest rate). Then R[Delta]t/2 is the fraction of the effective time horizon that is spent in getting from the introductory volume to half of the maximum penetration volume. Hence s is roughly the fraction of the effective time horizon spent at the maximum penetration volume.

If N(0) is very small relative to N([infinity]), then our formula is approximately

B exp(-rT)LsN ([infinity])

that is, discounted cash flow is a product of

(a) Marginal benefit, B (reflecting the project's technical benefits and their importance),

(b) Discount factor (reflecting the time of introduction and the corporate interest rate),

(c) Effective time horizon (reflecting both the discount factor and the degree of competitiveness of the industry),

(d) Potential volume (reflecting the applicability of the innovation),

(e) Average fraction, s, of that potential achieved over the time horizon (reflecting the speed of rollout).

A SIMPLIFIED APPROACH TO CALCULATING NET PRESENT VALUE

With these modifications, our process for estimating NPV involves estimating the following factors.

(1) Technical Factors

(a) Technical benefit: Amount by which the project, if successfully completed, can potentially change the benefit attributes (fuel economy, emissions, lead time, etc.) above baselines for each attribute. To avoid artificial precision, we limit our project leaders to reporting the effect (including their cost effect) on at most four attributes. We also caution them to use one-digit precision. (We denote the technical benefit by [b.sup.i].).

(b) Technical risk: Probability the project will successfully achieve its technical benefit by the project deadline given its current budget (denoted by p(T)).

(c) Technical cost: Research costs associated with the project (denoted by c(T)).

(2) Implementation Factors

(a) Implementation date: Time, T, at which the product will be introduced into the marketplace at a nontrivial volume.

(b) Eventual penetration: Potential number of units the innovation could affect. (In many cases, the answer is "all units made by the company.") We denote this by N([infinity]).

(c) Speed of implementation: Estimated time after introduction before the innovation reaches its maximum penetration (denoted by [Delta]t).

(d) Implementation risk: Probability of the project's results being implemented at this average volume, given complete technical success (denoted by p(I)).

(e) Implementation cost: Costs associated with implementing the project (e.g., the capital costs of building new plants). (We denote this by K.)

(3) Strategic Factors

(a) Time horizon: Effective time horizon of the project. (This was assumed the same for all projects unless competitors were considered unusually capable of quickly copying the technology.) We denote this by L.

(b) Importance: Importance attached to each attribute (denoted by [w.sup.i]).

To get the payoff (or benefit) of the product, we take a weighted average of the project's contribution on each attribute and the importance of that attribute, summed over all attributes. Multiplying by the probability of technical success then gives the technical value of the project. Multiplying the technical value by the average volume per year affected and the effective time horizon and subtracting implementation costs gives the project's commercial value, if implemented. Multiplying by the probability of implementation success and a discount factor (reflecting when the project's results achieve their average volume) then gives our expected NPV. Hence our NPV is given by

NPV = {{{[Sigma][b.sup.i][w.sup.i]}exp(-rT)LN([infinity])s}p(T) - K} p(I) - c(T) (1)

What was especially useful about this calculation is that it requires inputs from three key players: project leaders, strategists and internal customers. Because all players understand how their inputs affected the NPV, it becomes very easy to identify why a project appears to have a low NPV. This tends to precipitate a focused dialogue (or trialogue) between project leaders, strategists and internal customers on whether a low NPV is just a modeling error or whether it reflects real weaknesses in the project. Inducing this trialogue was the most important result of our work.

PROJECT VALUE AS A FUNCTION OF BUDGET

GROUPING PROJECTS UNDER FUNCTIONAL AREAS

We sorted all 300 projects into one of eight functional areas. In an effort to estimate the payoff associated with various levels of spending in each functional area, we sorted all projects in a given area according to project NPV divided by project cost (or bang for the buck). Suppose that the value (or cost) associated with any set of projects is just the sum of the project NPVs (or costs). A rational decision maker, given any sum of money to spend on projects in a functional area, will - ignoring integrality issues - only choose to spend money on the projects with the highest bang for the buck. Hence by varying the level of money given this rational decision maker, we get various levels of NPV. We can interpret this as how the NPV delivered by the functional area changes as we change the amount of funding allocated to work in that area.

Plotting this relationship gives a concave curve, reflecting the fact that we do the highest bang-for-the-buck projects at low levels of funding but only do the more marginal bang-for-the-buck projects at high levels of funding. The "let a thousand flowers bloom" philosophy of R&D generally provides very little direction to projects, thus causing most projects to be of marginal value and a few - very fortunate - projects to be of astronomical value. Hence we should expect the curves describing R&D to be very concave. This highlights the need to communicate the success.

EXPONENTIAL CURVE

With 300 projects and eight project areas, we had extensive data for reliably estimating the relationship between cumulative NPV and cumulative budget. We found that an exponential curve fit this data remarkably well. More specifically, if V(x) denotes reported cumulative project value given that we spend a total of x dollars in an area, then

V(x) = [V.sup.*] (1 - exp(-[Lambda]x))

fit our data for eight functional areas with an [R.sup.2] exceeding 0.98 in all areas. To help interpret this finding, suppose all projects have identical funding requirements.

Suppose we let [v.sub.k] be the value of the kth most valuable project. Suppose also that project value decreases geometrically; that is, there exists a "[Lambda]" such that

[v.sub.k] = exp(-[Lambda])[v.sub.k-1]

Then [V.sub.k], the cumulative value of the kth most valuable projects, satisfies

[V.sub.k] = [v.sub.1] + [v.sub.2] + ... + [v.sub.k]

= [v.sub.1][1 + exp(-[Lambda]) + exp(-2[Lambda]) + ... + exp(-[Lambda](k - 1))]

= [v.sub.1] (1 - exp(-[Lambda]k)) / (1 - exp(-[Lambda]))

so that

[V.sub.k] = [V.sup.*](1 - exp(-[Lambda]k)) with [V.sup.*] = [v.sub.1] / (1 - exp(-[Lambda]))

Thus we get the observed exponential relationship between spending in an area and the total value delivered by the area.

What is important about this relationship is that it indicates we can infer the relationship between value and spending level from just two assessments:

(a) Maximum potential value, [V.sup.*], that one could attain in the functional area given arbitrarily high funding. This value, potential value of an area, is something many project leaders feel they can assess.

(b) Cumulative NPV from funding the current projects within the functional area.

Thus the decision about how to allocate funding among various functional areas could, potentially, have been done by assessing two numbers per functional area (for a total of 16 numbers) rather than by assessing 300 numbers. This, of course, dramatically simplifies portfolio analysis.(2)

ALLOCATING FUNDS TO PROJECTS

To explore the implications for funding, suppose we assume this exponential result applies to the funding of projects (as well as project areas). We use the techniques of the previous sections to assign a value, [v.sub.j], to each project j while assuming that the project leaders had unlimited funding. We also assess [Mathematical Expression Omitted], a more limited level of funding that would be sufficient to give us 63.2% (or roughly two thirds) of the project's maximum potential value, [v.sub.j].

Assuming the concave exponential applies to projects implies that the value of the project given a funding level of [x.sub.j] is

[Mathematical Expression Omitted]

Now define

(1) [x.sub.j] to be the appropriate level of funding in project j.

(2) [Mathematical Expression Omitted] to be the funding level required to leave project j with a gap of roughly one third. ([Mathematical Expression Omitted] is just the reciprocal of the value of "[Lambda].") We refer to this as the critical point.

(3) [Mathematical Expression Omitted], which is the share of funding received by project j if each project were funded to its critical point.

(4) [Mathematical Expression Omitted] to be the amount of money consumed by funding all projects at their critical points.

Now suppose we wish to set funding levels [x.sub.i] to maximize [Sigma][v.sub.i] ([x.sub.i]) subject to a budget constraint [Sigma][x.sub.i] = W. Solving this problem indicates that the fraction of the budget allocated to project i, [x.sub.i]/W, is given by

[Mathematical Expression Omitted]

In other words, all projects get a funding proportional to [Mathematical Expression Omitted] adjusted by the extent to which the project's potential value, log [Mathematical Expression Omitted], exceeds the average potential value associated with the average project, [Mathematical Expression Omitted]. The degree of adjustment is small if the available budget, W, exceeds the amount needed to fund each project to the "knee." (In other words, when research funds are abundant, we do not pay as much attention to potential value as measured by [v.sub.i].)

To determine the value generated by this optimal allocation, we write

[Mathematical Expression Omitted]

where [Mathematical Expression Omitted] and [Mathematical Expression Omitted] Note that the payoff associated with the cluster of products is, itself, a concave exponential of the total amount of money, W, allocated to the area. Hence using the concave exponential to describe projects is consistent with using the concave exponential to describe functional areas (i.e., groups of projects.)

CONCLUSIONS

We can summarize our results by focusing on the simple case in which each project has just one benefit and capital costs and technical costs are negligible. In this case, the NPV formula in EQUATION (1) can be written in the additive form:

[Mathematical Expression Omitted]

Hence [x.sub.i], the funding allocated to project i, is proportional to

(a) Relative technical contribution: Size of the potential technical contribution, relative to the average project's technical contribution. We measure this with the index [Mathematical Expression Omitted].

(b) Relative importance: Importance of the problem area relative to the importance of the average problem area. We measure this with the index [Mathematical Expression Omitted].

(c) Immediacy: Immediacy of the application (as measured by -rT), relative to the immediacy of the average project's application. We measure this with the index [Mathematical Expression Omitted].

(d) Duration: "Duration of potential competitive advantage" relative to the duration associated with the average project's application. We measure this with the index [Mathematical Expression Omitted].

(e) Applicability: Breadth of applicability of the technology, relative to the penetration of the average project's application. We measure this with the index [Mathematical Expression Omitted].

(f) Speed of rollout: How fast implementation ramps up to full production relative to the rollout speed of the average project. We measure this with the index [Mathematical Expression Omitted].

(g) Lack of risk: Likelihood of technical success relative to the likelihood of success of the average project. We measure this with the index [Mathematical Expression Omitted].

(h) Organizational commitment: Likelihood of the technology, if successful, being implemented relative to the customer commitment for the average project. We measure this with the index [Mathematical Expression Omitted].

(i) Cheapness: How much it costs to achieve two thirds of the potential value in an area as compared with the cost of achieving two thirds of potential in the average area. We measure this with the index [Mathematical Expression Omitted].

In fact, our algorithm assigns project i a budget of

[Mathematical Expression Omitted].

that is, we first estimate the fraction of the total budget project 1 would receive if funded to its critical point. We then give project I this fraction of the actual budget adjusted by an amount proportional to the sum of its scores on the above nine indices.

ACKNOWLEDGMENTS

I am indebted to Drake Maher, Dave Howarth, Lynne Schultz, Mark Hauser, Judy Denardis, Lisa Rosenbaum, Dan Owen and Deb Peters. They helped develop and implement a project selection system at General Motors. As a result of this work, the portfolio planning team (Drake Maher, Dave Howarth, Lynne Schultz, Lisa Rosenbaum, Bob Bordley) received GM's Award of Excellence for "the first-ever GM process for DDP-based R&D project selection. Great teamwork and success story known around all large Corporate R&D communities."

1 This is reminiscent of the children's story, Stone Soup [1]. Stone Soup starts with a village whose inhabitants have each been hoarding food from one another. In the story, three soldiers tell the suspicious villagers that they can make an appetizing stew simply by boiling a stone in a pot. But as the soldiers boil the stone and boast of its qualities, the villagers start, one-by-one, to unlock their hoards in order to "spice" up the stone soup with vegetables and meats. Hence boiling the stone in the soup is actually just a gimmick that the soldiers used to coax the villagers into adding their own secret stores of food to the stew. As a result, a half-starved village of withdrawn and suspicious occupants had a lively communal feast, with everyone sharing what used to be their private hoards.

2 As another way of thinking about this result, define the gap, G(x), to be the fraction of the maximum possible value that has not been achieved if we spend only x dollars in an area. If we let c be the current level of spending, then for any other spending level, x,

log G(x) / x = log G(c) / c

If we have achieved only half of the maximum possible value in an area (G (c) = 0.5), then doubling spending cuts the gap to one quarter and tripling spending cuts the gap to one eighth. At the margin, each dollar added to the area cuts the gap by the constant amount, [Lambda].

REFERENCES

(1) BROWN, M.,Stone Soup, An Old Tale, Scribner, New York, (1947).

(2) KUSNIC, M., and D. OWEN, "The Unifying Vision Process: Value Beyond Traditional Analyses in Multiple Decision Maker Environments," Interfaces, 22 (6), Dec. 1992.

(3) SOUDER, W., and T. MANDAKOVIC, "R&D Project-selection Models." Research Management, 29 (4), 36-42, 1986.

(4) MATHESON, J., M. MENKE, and S. DERBY, "Managing R&D Portfolios for Improved Profitability and Productivity," Journal of Science Policy and Research Management, 4 (4), 1989.

(5) WINTERFELDT, D., and W. EDWARDS, Decision Analysis and Behavioral Research, Cambridge University Press, New York, 1986.

APPENDIX

CONCAVE EXPONENTIAL

To derive the formula, t let N(t) be the number of units affected t units after the innovation is first introduced and assume:

N (t) = N ([infinity])(1 - exp(-t / H))

If we let R = r + [r.sup.*], then the NPV of a project's payoffs will be

[Mathematical Expression Omitted]

Define L = 1/R as the "effective" time horizon. An innovation that yielded a one dollar payoff per year in perpetuity at a discount rate of R is equivalent to an innovation that yields a one dollar payoff per year for L years at a zero discount rate. Define s = (1/(1 + RH)) as a rollout factor. When H = 0, the rollout is rapid and s = 1. As H goes to infinity, the rollout is slow and s = 0. In an application in which H is about 10 years, s will be about 0.4. Hence the NPV of the project's payoffs are

B ex p(-rT) LsN ([infinity])

SIMPLIFIED GOMPERTZ CURVE

While the concave exponential is mathematically convenient, most of the literature on modeling innovation (Mahajan, Mason and Srinivasan, 1986) customarily assumes that the innovation function is first convex - as the initial introduction sparks many immediate applications - and then concave. The logistic and Gompertz curves are widely used to model this behavior. Instead of assuming a concave exponential, therefore, suppose we assume a Gompertz relationship, that is,

N (t) = N ([infinity]) exp(-[Beta]exp(-Rt))

where the coefficient of the second exponential, R, is chosen to match the adjusted discount rate, r + [r.sup.*]. Then the NPV of the project's payoffs are

[Mathematical Expression Omitted]

At the time t = 0, N(0) = N([infinity]) exp(-[Beta] and [Beta] = log(N([infinity])/N(0)); that is, [Beta] measures the amount by which the initial introduction of the technology falls short of its potential penetration. Hence we can define s = (1/[Beta]) with s once again measuring the speed with which the technology rolls out. (In an application in which initial introduction is one tenth of ultimate potential, s will be about 0.4.) If we also define L = 1/R as the effective time horizon, then the NPV of the project's payoffs is

B exp(-rT)LsN ([infinity])

BIOGRAPHICAL SKETCH

DR. ROBERT F. BORDLEY is part of General Motor's Knowledge Network and an Adjunct Professor of decision analysis at Oakland University. His previous responsibilities at GM included managing portfolio planning for the GM R&D Center, management and marketing systems, decision support systems and mission analysis. He has also been director of the decision, risk and management science program at the National Science Foundation. He has held offices with the Operations Research Society, the Institute for Operations Research and Management Sciences and the American Statistical Association. He has also published more than 60 papers in operations research, economics, political sciences, economics and physics.

In addition, make sure to read these articles:

Direct Mailing: Close the Loop
Interview with Patricia Block, Marketing Professional with Meridian Builders