Projects and product development is one long series of difficult decisions, says Pascal Van Cauwenberghe. Real Options can help you to take the right decision at the right time, even under difficult circumstances. At the Agile Tour Brussels conference, Pascal presented stories of his experiences with real options in decision taking.
Earlier InfoQ published the article real options underlie agile practices in which Chris Matts and Olav Maassen introduced the principle of real options:
Real Options is an approach that allows people to make optimal decisions within their current context. This may sound difficult, but in essence it is a different view on how we deal with making decisions.
Real Options is an active risk management strategy. It is necessary to constantly monitor your portfolio of options to make sure they are not being destroyed. In addition, it is an information hungry process as it requires the practitioner to actively look for information. Also remember that doing nothing is an option. To do nothing must be part of an active decision process. Real Options is not an excuse for procrastination.
The presentation that Pascal gave in Brussels is available at real options as an agile coaching tool.
A first story that Pascal told was about the redesign of a website for a video game. In this project many decisions were taken about the look and feel. Those decisions were changed along the way, which gave many redesigns with new decisions. The project had a fixed delivery deadline, 1 day delay would have significant impact on the sales. Deciding too fast and too often was leading to rework which increased the odds that the project would not deliver on time, so something had to change.
The team investigated the options they had for the redesign, by describing the option, cost, price value, and expiration date. They investigated when they would have to decide. Managers wanted to decide today, but exploring the options made clear that decisions could be taken much later, while still meeting the delivery date. They agreed that a decision would be taken at a later date whether or not to put the redesigned interface into production, depending on if it was stable enough to ship it. Postponing the decision gave the team time to work on the product, not being bothered by ongoing decisions to change the look and feel. Also the team found ways to reduce their development cycle time, which gave them even more time before they had to take a decision. Real options helped the team to postpone the decision, giving them more time to develop the product.
A second story was about a banking project for releasing a new internet banking service. The backend development project needed an architecture decision on the platform. They decided to uset "set-based design" and started developing both platform A and B. At some point during the project, a decision was taken to go for platform A , which was delivered on time. But then the company making platform A was acquired by another company, who made platform B. Platform A was discontinued. So now they had to migrate to platform B, coming back on a decision taken earlier. The new situation where platform B was required meant that investment in platform A was now gone. How much money was spent on platform A was no longer relevant, as it was no longer a feasible option.
Another story Pascal told was about a new system, that has to be delivered before the date on which the European law changed, which required some changes. The team had the possibility to invest €1000,- to ask the vendor if it could make the current system compatible, but decided not to do it. When the system was delivered months too late, the company was losing €10.000-€100.000 per month since it couldn’t invoice it’s customers with the current system. What they learned is that next time they should look at the potential value of the option, which could have saved them much money.
The examples that Pascal presented are based on using real options as described in the book commitment – a novel about managing project risks.