Risk Management & Real Options V. Designing a system means sculpting its value shape Stefan Scholtes Judge Institute of Management University of Cambridge MPhil Course

2 September 2004 © Scholtes 2004Page 2 Where are we? I. Introduction II. The forecast is always wrong I. The industry valuation standard: Net Present Value II. Sensitivity analysis III. The system value is a shape I. Value profiles and value-at-risk charts II. SKILL: Using a shape calculator III. CASE: Overbooking at EasyBeds IV. Developing valuation models I. Easybeds revisited V. Designing a system means sculpting its value shape

2 September 2004 © Scholtes 2004Page 3 Project design Value shape / risk profile helps us analyse strengths and weaknesses of the project and optimise it Focus on TAILS of the distribution What causes the left tail (losses / threats) and what can we do to avoid it? What causes the right tail (profits / opportunities) and what can we do to amplify it? Aim: Re-design the project so that its value shape moves further to the right (towards the higher values) KEY MESSAGE OF THIS SESSION: DESIGNING A PROJECT MEANS SCULPTING ITS RISK SHAPE

2 September 2004 © Scholtes 2004Page 4 Project design Designing a project means sculpting its risk profile

2 September 2004 © Scholtes 2004Page 5 Design decisions Where? When? How big? With whom? Etc.

2 September 2004 © Scholtes 2004Page 6 Group work Parking garage case I

2 September 2004 © Scholtes 2004Page 7 The flaw of averages Tacit assumption: “The system value calculated on the basis of of average conditions is the average system value” THIS IS WRONG! Parking garage valuation based on static NPV is far from the average NPV of the Monte Carlo simulations, although the demand data for the static NPV is the correct average demand

2 September 2004 © Scholtes 2004Page 8 Arguing on the basis of averages Jane: “James, Paul, thanks for coming. You know we need to decide on the launch of the new computer games that we have developed over the last months. James, you’ve promised to produce cost, sales volume, and margin projections.” James: “Well, boss, I’ve checked our historic data. We’ve sold 75 games of this sort over the past 4 years. Our average sales volume is 130,000 units and our average margin is £11. The average launch cost is about £800K” Jane: “So our revenue projection is 130,000*£11=£1,43 M against an investment of £800K. That’s a juicy profit of £630K. Let’s go for it.”

2 September 2004 © Scholtes 2004Page 9 Thinking in scenarios Paul: “Well, Jane, you know that we have been less than impressed with the financial performance of our games over the past years. I have looked at our data again. The launch cost estimate of £800,000 is pretty reliable but when it comes to sales, the data varies a lot. Our marketing people tell us that a game becomes a success only if it reaches a critical sales volume of around 100,000 units. Then it sells itself without much advertising. If a game doesn’t reach the critical volume, we keep it in the shops and sell it as a niche product; there are always freaks who love our games. Over the past 4 years about 50% of our launched games became mainstream games, selling an average of 250,000 copies each at an average unit margin of £4. The niche games sold about 10,000 copies on average but we could command a high unit margin of £18 because this type of market is fairly price inelastic and our competitors don’t develop competing products. It would be great if we could predict in advance whether or not a game becomes mainstream but that is notoriously difficult. We have to bite the bullet and invest the launch cost before we know the sales success.” Jane: “Okay, okay, Paul. I am well aware that there is a risk that the new game will not cover the launch cost. But we are selling many of these games. So we are well diversified and can therefore safely base our analysis on averages.” IS JANE RIGHT?

2 September 2004 © Scholtes 2004Page 10 The flaw of averages Business projections of performance measures based on average conditions are typically NOT averages of the performance measures! Formally: E: Expected value f(): System performancemeasure X: Uncertainties that determine system performance

2 September 2004 © Scholtes 2004Page 11 The flaw of averages E = Expected value f() = System performancemeasure X = Uncertainties that determine system performance This is what we are interested in and what the Monte Carlo model calculates This is what a projection- based model calculates

2 September 2004 © Scholtes 2004Page 12 System constraints and uncertainty The mean is where the histogram “balances” NPV Probability“mass” Histogram of NPV

2 September 2004 © Scholtes 2004Page 13 System constraints and uncertainty The mean is where the histogram “balances” NPV Constraint cuts off some good NPV scenarios Probability“mass”

2 September 2004 © Scholtes 2004Page 14 System constraints and uncertainty The mean is where the histogram “balances” NPV Probability“mass”

2 September 2004 © Scholtes 2004Page 15 System constraints and uncertainty The mean is where the histogram “balances” NPV The probability mass is now out of balance! Probability“mass”

2 September 2004 © Scholtes 2004Page 16 System constraints and uncertainty The mean is where the histogram“balances” NPV New balance point to the left: average is reduced Probability“mass”

2 September 2004 © Scholtes 2004Page 17 System constraints and uncertainty Constraints are often invisible in number-based models Implicitly incorporated in the projections Constraints will often cut off some good NPV scenarios Bad results are not balanced out by good results ̵ Expectation is reduced The larger the uncertainty… the more mass is assigned to both good and bad results The more NPV-mass is cut off by constraint The further to the left the balance point moves … the larger the negative effect of constraints Can we see the effect of uncertainty in the presence of system constraints in a numbers model? Compare static NPV of parking garage

2 September 2004 © Scholtes 2004Page 18 Conclusion: Flaw of averages Theflaw of averages is one of the most prevalent “valuation traps” Bear in mind: System performance based on average conditions is NOT the same as average system performance Have seen that system constraints induce the flaw Monte Carlo simulation avoids the flaw of averages Sam Savage has coined the term “flaw of averages” and has collected a host of stories around the flaw google Sam to find out more