Term
|
Explanation
|
|
expected internal rate of return (EIRR)
|
A minor modification of the internal rate of return (IRR) sometimes used to prioritize projects (such as new product development projects) whose costs and future cash flows are highly uncertain. In the
formula for computing IRR, project costs are replaced by the expected value of initial-year project costs, and project cash flows are replaced by the year-by-year expected value of project cash flows. Thus,
The EIRR is the solution to the equation:

In other words, to use the EIRR, alternative project cost and future cash-flow scenarios are defined. For example, the various stages and associated cash flows for the project (such as development, testing, and
commercialization) may be represented in a decision tree. Probabilities are assigned to each scenario. The expected value of project costs and expected value of each year's net cash flow
are computed by multiplying probabilities by cash flows and adding. The EIRR is then computed as the discount rate that equates the discounted value of expected future cash flows with the expected project cost.
When applied to multi-stage, high-risk projects, the EIRR behaves in an intuitive way. For early stage projects with a low probabilities of ultimate success, expected cash flows tend to be low so the EIRR
tends to be low. However, if such a project is funded, its EIRR tends to grow (assuming initial project outcomes are successful) as project costs are sunk and early-stage failure scenarios are avoided.
A late stage project (one that has successfully avoided early and middle stage risks) tends to have a very high EIRR. Because of the strong influence of project stage on the EIRR, typical advice is that
project-by-project comparisons using EIRR be conducted only for projects at the same stage of development and that separate budgets be established for funding projects within the different stages.
As a project prioritization metric, the EIRR has the advantages and disadvantages described for the IRR, plus the advantages and difficulties associated with assigning probabilities to alternative scenarios.
|
|
expected net present value (ENPV)
|
An enhancement of the net present value approach that explicitly addresses uncertainty. Depending on how it is applied, ENPV can produce estimates of
uncertainty in the value of the overall project portfolio and adjust project value to account for risk. It can also be coupled with methods for quantifying the
non-financial or indirect components of project value. It is, therefore, a useful tool for computing project and project portfolio value. However, the computations necessary
to compute ENPV can be difficult. The method is best reserved for very large and risky projects.
With ENPV, rather than calculate a single time-stream of project cashflows and other project impacts, alternative scenarios are defined representing the range of possibilities.
Simulation techniques are often used to generate the alternative scenarios, which may be represented in as a decision tree (a graphic structure wherein
alternative sequences of choices and outcomes are displayed as branches in the tree and the various paths through the tree represent the alternative scenarios) or event tree (similar to a decision tree, but
without nodes and branches representing alternative choices). Probabilities are associated to each scenario in the tree. A project NPV is computed for each scenario, and the ENPV is the probability-weighted sum of the values.
As described under net present value, selecting discount rates is often problematic. If risk is important, risk-adjusted discount rates are often recommended, with different
risk-adjusted rates being appropriate for different scenarios. Alternatively, techniques based on risk tolerance can be used to account for risk (these techniques
generally involve using a risk-free discount rate for computing EPNV).
In addition to the difficulties mentioned above related to selecting the discount rate, another limitation of ENPV is that historical data is generally unavailable for estimating
probabilities. Thus, probabilities must typically be assigned subjectively.
|
|
expected value
|
Term used to represent the result of a mathematical computation performed using probabilities. Suppose there is an uncertain (random) variable X that may produce various "payoffs" (values).
Suppose the possible payoffs are denoted x1, x2,..., xN, and suppose that these
alternative payoffs occur with probabilities p1, p2,...pN, respectively. The expected value of the variable
is sum of each possible payoff multiplied by its probability:
If the uncertain variable can take on a continuum of possible values (e.g., any value between 0 and 1), then its expected value is computed by weighting the possible values using the variable's probability density function and using
integral calculus.
The expected value is the average return one would expect over many "trials" or opportunities for the uncertainty to occur. See expected commercial value and expected net present value
for examples of measures based on expected value.
|
|
goal programming
|
An optimization method designed for problems with more than one objective that allows a solution to be found using linear programming. The method, sometimes applied to resource allocation and project selection
problems, involves expressing goals or targets for objectives and assigning priorities or weights to achieving those targets. For example, the formulation might be to find the subset of R&D project opportunities that comes closest to achieving specified
goals for manpower utilization, market share, sales, and net present value maximization. Constraints on acceptable solutions may also be defined, for example, requiring total costs to be no greater than the budget. Goal programming seeks solutions
that meet constraints while minimizing the weighted sum of the deviations from the specified targets. The solution effectively involves a repetitive process of attempting to achieve each goal, in order of
priority, subject to the specified constraints.
Goal programming has several attractive features. One obviously, is the ability to address multiple objectives. Also, and importantly, solutions can be easily found using the Simplex Method of linear programming. This means that
relatively large numbers of decision variables, constraints, and goals may be established without creating difficulties for finding a solution. For example, in the context of resource allocation, you could solve for multi-year solutions that closely achieve many
detailed goals with many specified constraints.
A feature that no doubt promotes the use of goal programming is the (apparent) non-demanding nature of the necessary inputs. Like other prioritization logics, a model relating choices to performance is required. However, goal programming does not require detailed
quantification of decision making preferences and willingness to make tradeoffs the way that decision analysis methods do. Instead, all that is required is the specification of goal targets and weights.
The main disadvantage of goal programming, of course, is that
reasonable goals and targets cannot be specified without reference to underlying decision-maker preferences—choosing the "right" targets and weights is exceedingly difficult. If the targets and weights are not
appropriate, the solution will not be the one in the best interest of the organization. The reason for this is that goal programming does not allow tradeoffs between goals. For example, if sales growth is the first priority goal, and
market share is the second, the formulation implies that not even one dollar of sales growth can be sacrificed to obtain even a huge gain in market share. Goal programming represents a
"satisficing" approach to decision making, meaning that what is sought is a satisfactory solution rather than one that is truly optimal. Because the method does not capture willingness to tradeoff achievement
of the various objectives, it is incapable of finding solutions that lie on the efficient frontier.
|
|
hurdle rate
|
A specified rate of return for a project or other investment intended to represent the minimum return that the organization will consider. The hurdle rate is also
often referred to as the required rate of return.
Typically, the hurdle rate is the discount rate to be applied to the cash flows anticipated from the project. If the net present value (NPV) of cash flows using the hurdle rate as the discount rate is negative,
the project is rejected. Alternatively, the hurdle rate may refer to the minimum acceptable internal rate of return (IRR) for projects—If a project's IRR is less than the hurdle rate, the project is rejected.
According to investment theory, the hurdle rate should be set equal to the rate of return that the organization could obtain by investing in alternative investment opportunities having similar risks. If the
project generates a return greater than what the organization could earn elsewhere (i.e., greater than the opportunity cost of the required investment), the project will add value. Because the opportunity cost
is difficult to compute, in practice, hurdle rates for projects are often specified by adding or subtracting a risk premium to the organization's marginal cost of capital, so that a higher rate is specified for
project considered more risky.
Hurdle rates are generally a poor way to account for risks when prioritizing projects. As explained in one of the papers, hurdle rates tend to produce a bias toward short-term, quick payoff projects relative to
projects of similar risks whose benefits accrue over longer periods of time. Also, while hurdle rates can be used to decrease the value of projects whose benefits are more uncertain, they do not achieve the converse
effect of increasing the value of projects that, if not conducted or if delayed, would tend to increase risk.
|
|
integer programming
|
Similar to linear programming—A method for minimizing or maximizing a linear objective function subject to linear constraints. The difference is that in the case of integer programming one or more
of the decision variables must be integers. Unlike linear programming, which can be solved quickly and efficiently, finding the solution to an integer programming problem can be very difficult. The major algorithms
for solving integer programming problems are branch and bound, the cutting plan method, and Bender's algorithm.
|
|