Monthly Archives: December 2011

How I use Real Options to play Tetris

Real Options have many applications. Any activity that involves making commitments can be studied using the lens of Real Options. One of my guilty pleasures is to play Tetris. It is a game full of commitments and options. It is a useful tool to study real options.

There are two strategies I use to get a high score in Tetris. The first is “Get a Tetris”. The second is “to stay alive”.

“Get a Tetris”

At the start of the game when the blocks fall slowly, I attempt to get a Tetris. That is where you guide a long thin block into a long thin gap and complete four rows in one go. Achieving a Tetris optimises your score for clearing four lines. As the blocks are moving slowly it is fairly easy to carefully chose the optimal place for each block. The success of this approach depends partly on the order in which the shaped blocks arrive.


One consequence of “Get a Tetris” is that you get high tower of blocks. These are easy to cope with when the blocks move slowly, but they cause trouble when the blocks start to move fast.

“Get a Tetris” is not really that interesting from a Real option perspective.

At some point (about 250k) in the game of Tetris that I play (on the iphone) the speed of the falling blocks increases to the point where they appear to teleport from the top of the screen to the bottom of the screen. “to stay alive” requires a different approach to getting a high score. Obviously the “Get a Tetris” strategy needs to be dropped. (See later). Now the only thing that matters is “to stay alive”.

“to stay alive”

We need to carefully manage our options and commitments. This is where real options really kick in.

There are two key capabilities in my version of Tetris. One is the ability to spin the block after it has landed. The other is the ability to move a block left or right after it has landed. However it is only possible to move a block in a direction on the same level or down a level. The option to move a block does not exist if it requires moving upwards.

“to stay alive” uses these two abilities. The ability to spin blocks is used to give more time to consider the target location for the next block. The block is then positioned according to where the next blocks should be placed.

In order to move a block it must land in a place that is higher or level with the spot it will be moved to. This has an influence on the target shape for the blocks. Given the speed that the blocks drop after a certain point, the following shape provides very few options…

Alternatively, it is possible to move the block in the following shape…

…Though only towards the edges. If you move the block one way and then discover you have made a mistake, you will find this shape has committed you to the move you made.

The ideal shape is flat so that you can change your mind after moving the block and move it back in the opposite direction.

In other words, the shape determines the number of options that we have and more options make it easier to play.

The towers that “Get a tetris” can create make it harder to survive.

So what does this really tell us about Real Options? I think it tells us that I need to stop thinking about Real Options so much.

Have a lovely holiday.


The Language of Risk

Last week I had an enjoyable chat with Janet Gregory about risk management. We were discussing how risk management is not one thing, rather it is an attitude or approach. The conversation reminded me why I started this blog.

Earlier this year the system I worked on was subject to a methodology audit. I spent several hours working with the auditor to explain the approach we were taking. At the end of the conversation the auditor said they wanted to use a kanban system to manage their audit process.

Why did the auditor like what I said? Because I explained everything we did in terms of risk. When they asked for a “process”, I explained the risk the process was meant to address. I then explained how our different process addressed the risk more effectively.

A couple of examples.

“Do you have stakeholder sign-off on your requirements to ensure they all agree on the priorities?”

reframed in risk terms as:

“How do we address the risk that we might be building the wrong thing?”

and we addressed as follows:

“Every week we present the status of the list of projects we are working on to the steering committee. The longest we can work on the wrong thing for is one week.”

“Where is your functional spec.”

reframed in risk terms as:

“How do we avoid the risk of building the wrong functionality?”

“We have a two page functional spec. Any more and the stakeholders will not read it. We also have a whole bunch of examples that the stakesholders have verified as correct, and a mock up in Excel so they have an idea of what it will look like. The key is to get quality feedback from the stakeholders rather than get a signature that means nothing. A signed off spec. sort of transfers responsibility from IT to the business for getting the requirements right… but not really. IT will get the blame if it does not work, even if they have it all signed in stone.”

For the fifty or so process audit points we went through each one doing the same kind of thing. Step one, agree the risk the process step is meant to address. Step two, explain how our team addressed it.

The language is important because it helps you think about the problem in the right way.

From my experience, middle and senior IT management respond well to this way of thinking, as do the business investors.