Skeptical Project Management: Real Options
In finance, we use options to hedge our risk. There are two types – puts and calls, one giving us the right to buy a stock at a certain price, the other the right to sell. They act like insurance. If I hold IRBT and it’s trading at 30, and I want to lock in that price, I can buy a put option that gives me the right to sell at 30, no matter what the price of IRBT goes to in the future.
If, in the future, before the option expires, IRBT drops, I can exercise my option and not have suffered losses due to IRBT’s drop in value. If IRBT rises, the option expires worthless, and I’m only out what it cost me to buy the option.
If we look at a potential chart, we’ll see IRBT’s activity over time.
If I directly hold the stock, that’s also a chart of my wealth over time. But, let’s buy an put option with a strike price of $30, ensuring I can always sell my shares for at least $30 dollars. My wealth now looks like this:
In other words, my wealth never drops below $30 a share. Now, if you’ll indulge me a little, I’m going to go a little further into this than you think I might need to in an attempt to illustrate a point. This insurance can be costly, as you can see in most cases the price of the stock is well above 30 and my option expires worthless, meaning I just lose whatever it cost me to buy the option. I can ameliorate this by selling a call option at a higher price, say, 40. (Needless trivia: When I sell, or write, a call option on a stock I own, it’s called a covered call.)
To recap, I’m buying a put at $30, which means I’m paying someone else for insurance such that my wealth never drops below $30 a share. I’m also selling a call at $40, which means I’m giving someone else the right to buy at $40. Why would someone want the right to buy the stock at a higher price than its going for on the open market? Perhaps they believe IRBT is about to hit it big and shoot to $100. If they buy the option I’m selling, they’ll be able to buy IRBT at $40 and turn around and sell it at $100, making a cool $60 per share.
But think about what that does to my potential wealth. If I sell a call option at $40, I must assume whoever buys it will exercise it if the stock rises above $40. That means I must sell them my stock at $40 dollars a share, and no higher. To illustrate with a chart:
As you can see, I’ve limited my losses by buying the put at $30, and I’ve also limited my gains by selling a call at $40. Usually options traders try and ensure that the extra money I get from selling the calls offsets the money needed to buy the puts. Now I get free insurance, at the cost of limiting my gains in the short term.
Why did we go so deep into that? Well, project management, especially software project management, is also fraught with risk. We are really bad at estimating, and we’re also really bad at knowing what sort of black swans might creep up on us. It’d be nice if we could hedge those risks.
D’Souza argues that we can hedge risks with something like an option in project management. He uses a decision tree methodology in particular, but it really doesn’t matter how you express the option. It just means that your project plans and schedules need to have the same limits on them as my last stock chart above – you need to limit your losses as well as your potential gains.
We can limit our losses on projects by providing escape hatches in our schedule and project plans. Basically, we need explicit points that all parties can agree to that the project will be scrapped if certain milestones aren’t met. For the most part, the idea of scrapping a project if milestones aren’t met isn’t new. But without explicit options, we fall prey to the same problems that plague traders who’s ‘options’ aren’t explicit.
For instance, traders may opt rather than purchasing a put option, they’ll just sell their stock if it drops below $30. That should limit their losses, correct? There are a few problems with this, some technical some behavioral.
First, the technical problem is they cannot guarantee as tightly as an option to limit their losses. They may not be able to execute a trade until the price drops to $29, or even much lower if the stock is falling fast. Even special orders like stop orders are subject to this problem, particularly if the stock opens one day much lower than it close the last (called a ‘gap’). Maybe we find out that IRBT has been selling poisoned milk to school children after the trading day is closed, and it opens at $1 the next day. Our trader would be forced to take that price, rather than the $30 the option would guarantee him.
Behaviorally it’s much worse though. We get into the effects of loss aversion, sunk costs, and anchoring. First, because we tend to feel losses much worse than we enjoy gains, we have a strong tendency not to recognize losses when they occur. Our trader will most likely hold on to the stock, even if it drops further, now waiting for the stock to rise back up so he can sell. He’s holding on to a loser. Secondly, the trader may ‘throw good money after bad’ and double down if the stock drops, assuming that it will at least rise up to where it was. While this isn’t in itself a terrible strategy (sometimes called ‘contrarian’), the real problem is that the trader has become enamored with the stock and is ignoring other great opportunities with the same upside risk. Finally, the trader has anchored his valuation of the stock at – of all prices – where he bought it at. This is rather arbitrary since if he had waited a day later or bought a day sooner, the price would have been different, and the trader would instead be waiting for that price to sell.
All these problems happen in project management too, if not worse ones. We frequently don’t want to admit things are going south in the first place and succumb to the effects of loss aversion. Moreover, when a project begins to take a turn for the worst, we throw tons of money at it, hoping it will be propped up. We think we need to invest more money into our project to recoup the money we’ve already put in. But these are sunk costs, we can’t get them back no matter what, and we need to put projects on equal footing instead of propping up failing ones unnecessarily. Lastly, we end up anchoring the project on whatever we’ve spent thus far – if we’ve spent $1M on a project, then the benefits of success must be worth at least $1M. If we’ve spent more, somehow magically the benefits go up. We should not anchor our valuation of the benefits of a project to its cost – they are decoupled. Finally, the same technical issues occur, since a project without a built in option won’t be as efficient as one that does have that option. Customers usually only get updated on the progress of a project during reviews, and just like a lot of news can change a stock over night, progress can stall unexpectedly between reviews, leaving the Customer exposed to additional losses than they would have.
A put option is insurance – it’s something the customer must buy from the vendor (or a third party) that will guarantee losses will not go over a certain amount. An example of a put option in practice might be an agreement between a vendor and customer that if a $1M project goes over $2M, the vendor will continue the project but eat the additional costs themselves. In return, the vendor may get up front payment from the customer, the price of the option.
Of course, are more simplistic put option in project management might simply be pulling the plug at $2M. This is an example of the customer exiting the market, rather than staying in such that they may be exposed to progress later.
Of course, now the customer is mad because they have to pay this premium – buying insurance from the same person that’s completing their project. It might, for example, encourage vendors to overestimate their risks to sell more expensive insurance. The customer probably wants this insurance built into the contract.
Enter the call option. Just like the customer bought the put from the vendor – the right to back out, or the obligation of the vendor to eat additional costs beyond the bid price, the Customer might sell a call option back to the vendor – the right for the vendor to buy-in if things are going really well, ahead of schedule. This more or less means the vendor must be exposed to upside risk, at the cost that the customer is not as exposed.
What would this look like? Well, software often moves forward in fits and starts. It can also take a long time for a breakthrough, and all of this is hard to estimate. We put in the put option for the customer that, in exchange for a higher payment, the vendor would agree to eat cost over runs. This gives an incentive for the vendor to try their best to be lean, but also to over estimate the risk of the project.
The call option, in turn, would be an agreement between vendor and customer that in the case the vendor is, for example, ahead of schedule the schedule itself does not change. The extra time is the vendor’s (to a degree). Likewise, if the vendor comes in under budget, the vendor keeps the extra money agreed to in the beginning rather than facing claw backs or reallocation.
The customer, in turn, gets potential over runs covered by the vendor, and the right to walk out if schedule milestones aren’t met, without further compensation to the vendor.
Without the compensation up front, the vendor no longer has any incentive to bid up the price due to risk. In fact, due to the upside benefit, this combination of a put and call option protects the customer from over runs at the same time giving the vendor a performance incentive for free.
This has been a rather literal interpretation of Real Options on a project, so there’s a lot more to be said about options on a project that I won’t say. The point is that options fit very well on a schedule (D’Souza’s decision trees can easily be incorporated into a PERT chart, for instance) and should be a part of any bidding and brainstorming session for a software project. They also serve as (one) layer of risk management both to the customer and vendor, limiting losses (and gains) to a set boundary.
No comments yet.