BT

"Real Options" Underlie Agile Practices

Posted by Chris Matts and Olav Maassen on Jun 08, 2007 |

Whether people realise it or not, "freedom to choose" is the underlying principle behind many of the agile practices. We call this principle Real Options. An understanding of Real Options allows us to develop and refine new agile practices and take agile into directions it hasn't gone before. Real Options also help us understand why some people resist some of the practices.

To use a familiar phrase, Real Options is about "deferring decisions to the last responsible moment," which is an explicit principle in the Lean Software approach. By avoiding early commitments, you gain flexibility in the choices you have later. A more formal definition will follow.

Viewing Agile through Real Options

Real Options are everywhere in agile practices. To illustrate this let's look at some agile practices and point out where commitments are avoided as long as possible. These are just a few examples. Once you become aware of Real Options you will discover a lot more.

Behaviour Driven Development and Test Driven Development provide many options, especially "the option to change the software, knowing when you have broken it." Without test driven development, there would be no refactoring. In other words, test driven development removes the need for design commitments, the choice of design can be deferred until after the coding has started. More subtly, Test Driven Development allows the developer to know with certainty that they have finished, instead of determining beforehand when the programming is done. Test driven development requires no decision at all, simply stop coding when all the tests are green. Similarly mock objects allow the developer to defer the decision on how to implement a class until a later time when they have more information on what is required from the class. They also create a nice recursive implementation pattern.

XP and Scrum defer the decision about which story to develop until just before the coding starts. This allows the team to incorporate information that arrives at the last moment, such as a new client request. The Scrum Backlog provides a forum where any idea for functionality can be recorded without requiring an immediate commitment to build it.

At the project Chris is working on, the development is prioritised based on client requests. In effect, sales drive the prioritisation process by stating the relative importance of a client. The team doesn't start working on a feature until the clients have requested it. "Strategy" meetings were cancelled several months ago because they were just crystal ball gazing about the features the team thought the clients liked. Now the team waits to see what the clients actually request.

By delaying commitment on the features built, the team is able to reduce time-to-market for new features requested. When the client requests a feature the team is free to act, because they are not tied up working on unwanted features. This is only possible with short iterations and a fast turnaround on regression testing.

Pairing provides options in that more than one developer will have an intimate knowledge of any part of the system. This mitigates the "truck number" (a.k.a. "lottery number") risk or "key man" dependency. (The truck number is the size of the smallest set of people in a project such that, if all of them get hit by a truck, the project would be in serious trouble [1]. By spreading the knowledge of the system the project is not in danger when anyone on the team wins the lottery.)

So What are 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. There are two aspects to Real Options, the mathematics and the psychology. The mathematics of Real Options, which is based on Financial Option Theory, provide us an optimal decision process [2]. The psychology of uncertainty and decision making (based on Neuro Linguistic Programming [3][4] and Cognitive Behavioural theory) tells us why people do not follow this optimal decision process and make irrational decisions as a result.

Financial options are options written and stock and shares. A huge amount of mathematics has been developed to price and risk manage these options. "Real Options" is the term we've coined to describe our use of financial options mathematics to help us make optimal real world decisions... Real Options are real world decisions.

Much of the existing literature explains how we can use the Black Scholes formula to price real options. Fisher Black and Myron Scholes along with Robert Merton are Nobel Prize winning economists who invented an equation to value financial options. Unfortunately, most of that literature is wrong when applied to Real Options. We cannot price real options using Black Scholes' famous equation. Whereas a PhD or Masters in financial mathematics is required to derive Black Scholes or prove the statement we just made, no understanding of maths is required to use the results of these maths.

The "only" things that the Financial Option maths can tell us about options are:

  1. Options have value.
  2. Options expire.
  3. Never commit early unless you know why.

Quite simply, the maths tells us not to make a commitment until the last minute unless we know with certainty why we want to make the decision early. Sound familiar?

The "Real Option" decision process is not new. Preston Smith was one of the first to coin the phrase "Make the commitment at the last responsible moment" [5]. However, whereas Preston's statement was an opinion based upon many observations, Real Options are based on financial mathematics.

In the Summer of 2006, we ran a series of sessions on Real Options. One participant, Iain Brocklehurst, a senior IT manager within JP Morgan said "This is just bottled common sense." Real Options, while based on maths, focuses on the psychological aspects of decision making which are probably more important than the maths. Without understanding the psychology, most attempts to implement a new decision process will fail.

Choices

Given any decision to be made, there are three possible decision categories, namely, a "right decision", a "wrong decision" and "no decision". Most people think there are only two; you're either right or you're wrong. As we normally do not know which is the right or wrong decision, the optimal decision is in fact "no decision" as this defers the commitment until we have more information to make a better informed decision.

However, if we observe the behaviour of most people, we notice that an aversion to uncertainty means people make decisions early. Real Options address this aversion to uncertainty by defining the exact date or conditions to be met before the decision should be made. Instead of saying "not yet", the Real Option approach says "Make the decision when.....". This gives people certainty over when the decision is made and as a result they are more comfortable with delaying the decision. Delaying commitments gives decision makers more flexibility as they continue to have options. It allows them to manage risk / uncertainty using their options.

Real Options feels unnatural to begin with. Like leaning down the hill when skiing, or leaning back when you jump from a height on horseback. A few people adopt them naturally. Others need a coach, time and practice to get it. Sound familiar? Perhaps like Agile? Perhaps the "unnatural" feel of this uncertainty one of the reasons that some people are so opposed to Agile.

Rather than decisions, Real Options is really about commitments. Quite often people make a decision which becomes an emotional commitment to an idea. They do not realise that they can change their minds.

Is agreeing to go to out with a friend an option or a commitment? Most will say a commitment because they have an agreement with their friend, while in reality it is an option. If something happens that provides you a higher value (like your dream partner asks you to go backstage at a U2 concert with them), you'll call your friend to reschedule. An agreement is an option.

Financial options have a contractually defined expiry date (date on which they end, or expire). The expiry date of Real Options is conditional rather than contractual. The most powerful aspect of Real Options is the ability to push back the expiry date of an option, thus giving more time for an optimal solution to be discovered. There is value in paying to defer a commitment.

Examples in business

These practices are already in use. As said before, this is nothing new. Three well known companies are already using this successfully: Toyota, Microsoft and Google.

Toyota's relationship with options is well documented in Mary and Tom Poppendieck's "Lean Software Development" [6]. Famously, Toyota waits until a customer buys a car before they start to build it. How's that for deferring commitment?

Microsoft's relationship with Real Options is well known, like the famous trade show where the Microsoft stand "looked like a bazaar". While other companies were betting their company on a single product or strategy, Microsoft was hedging its position so that it could still win the office automation battle even if it lost on the operating system front. Microsoft is the ultimate master of the wait, and wait, and wait, and see strategy. Consider the Internet Explorer episode where Microsoft waited until the internet had emerged as a technology before moving in. A question we would love to have answered is: "How many programming teams and solutions did Microsoft consider when faced with this crisis?" Did it adopt the traditional "cost optimising" best solution approach or did it look at many alternatives? We suspect the answer is fairly obvious.

Google is one of the first Informationalist [7] companies. Rather than enter into conflict with its customers, it cooperates with them. No random banner ads, but rather adverts for products and services that you might actually be interested in.

The Future of Agile

It is often too easy to destroy someone else's options. As a result, Real Options works most effectively if participants cooperate with each other. This goes against common practice of hiding our intent. However, we can learn from Google's approach. After all, how can I help you if I do not know what you want to achieve... Perhaps this should be starting point of Agile management practices.

We need to learn how to listen so that we can help other people achieve their goals. Ironically enough, "Listen" is one word that does not appear in the APLN's "Declaration of Inter-dependence". Leaders must provide and create options to for people they work with instead of making decisions for them.

Real Options is a set of principles that validates certain practices, as shown above, and can be used to generate new practices. Currently agile needs to develop Leadership and Management practices (beyond project management) that support the agile mindset, to move out of the IT department and into the rest of the corporation.

To give a few examples of how this would work, let's look at decision processes and resource management.

Decision process

The optimal decision process is as follows:

  • For each decision, identify the options available.
  • Identify the last point at which a decision can be made. i.e. the conditions to be met to make a commitment. This is calculated by working out the deadline for the implementation of an option, and then working back to the decision point (i.e. the Takt time). The first decision is made when the first option expires.
  • Until that expiry date, continue to look for new options.
  • Attempt to push back the decision time. Quite often this is free or very low cost. To do this, we need to be able to implement the option as quickly as possible. During slack time, work on how to speed up the process (just like Toyota does in their production plant).
  • Understand that cost optimisation is not the same as revenue optimisation or risk reduction. Sometimes it is worth investing in more than one option even though this may cost slightly more. After all, options have value (just ask Microsoft).
  • Wait to make decisions... and wait... and wait... until the conditions are correct.
  • When you need to make a commitment and act... do so as quickly as possible. And you can proceed with confidence because you know you have made the best informed decision possible.
Recently I was in a meeting where we were discussing the need for a "Plan B". We had a "Plan A". There was an argument about the need for a "Plan B" at all. The success of "Plan A" was quoted as 99%, 50%... and many other percent. I applied Real Options and suggested we first identify when to cut across to "Plan B". We also identified the additional up-front investment required to make "Plan B" an option. It transpired that about ten minutes of effort was required but it would take a few days to do because of the large number of steps and departments involved. We set the "Plan B" option in motion. In addition, we sketched out "Plan B" in rough detail. "Plan A" failed. We knew exactly the time to swap over to "Plan B", and everyone knew what they had to do. The switch over was a smooth process. Far from the emergency expedition of tasks, and resulting chaos, "Plan B" went so smoothly that many people did not even realise we had changed course at the last minute. -- Chris Matts

One of the key lessons to take from Real Options is that the right time to decide whether an idea is a good one is after you have tried it, rather than before you have listened to it.

Resource Management

Real Options, when applied to resource management, tells you that you should deploy resources from the least experienced up. Your most experienced team members with the most options (most skills etc.) should be allocated last. This means your most experienced staff can be deployed to address any emergent issues. While unallocated, they can coach junior members (create options) by pairing with them. This ensures they can ensure good practice and keep track of the architecture of the application. This could be the PM or lead developer. They should learn to be lazy - a good start is to read Tom DeMarco's "Slack" [8].

Executives in organisations should adopt an option based investment strategy rather than committing to project budgets. The executives should defer commitment to invest the full amount until they see the success of initial investment or validation of a business case. The investment should be made for each each release based on success criteria. The success should not relate to the development but rather the business project. i.e. the increase in business value. A project where the development of a feature costs double the original estimate would be a success if the revenue increase was high enough. Similarly, the perfect project that costs half the estimate should be canned if it does not generate enough revenue. Executives should be able to increase the investment in a project if it is going well. In order to do this, they need liquidity of development staff which is facilitated by Real Option based resource management.

Finally, executives in an IT-related company should consider adopting customer-driven development where real customers choose and prioritize the features (i.e. customers which are external to company, not the XP kind which are part of the project team), . In order to achieve this, the Sales and IT Development should be integrated. Sales gives an a la carte menu of features (options) to the customers rather than a feature list for the next release. Sales offers anything on the menu, or the option to chose something that's off the menu. To introduce a new item, the team brainstorms the features, does just enough analysis to determine the Takt Time for the feature, and identifies the major risks. The Sales team is given these Takt time estimates so that they can offer them to customers. If the customers don't want them, don't build them. If they do, do. In this way you avoid building the 67% of features identified in the Standish Chaos report as "Rarely or Never Used"[9].

This is the approach we are taking on our current project. Sales loves it. Instead of selling the customer features they do not want, they ask them what they want and give it to them. Sound familiar? (If it works for Google...) We've seen the sales team start to invite the project team to client meetings so that we can explain the approach in more detail.

There are many practices out there to be discovered...

A word of caution. 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.

Conclusion

Real Options is the underlying principle of agile. Many of the agile practices defer decisions as long as possible. Succesful companies like Toyota and Google are using Real Options to their benefit. Real Options provides us with the ability to take the agile mindset and project it into areas so far untouched.

As a final thought: last year Chris met with a friend in a London pub. Unlike many people, she instantly "got" Real Options. In the next ten minutes, she worked through many of the implications of Real Options. (It has taken us six months to work out what she had worked out in ten minutes). Then she fell silent. After a few minutes of silence, she said "They are about creating a better work place." She's right, but there is more. That's why we do them. Not because they will make us rich, which they will, but because they are fun.

Have fun. :-)

References

1. http://c2.com/cgi/wiki?TruckNumberFixed
2. http://en.wikipedia.org/wiki/Real_option
3. "NLP Unplugged", Gary Sage & David Hagan,
4. "User Manual for the Brain,' Bodenhammer, Bob G. & Hall, L. Michael
5. "Flexible Product Development" Smith, Preston G.; (Sept 2007)
6. "Lean Software Development", Poppendieck, Tom and Mary; Addison-Wesley Professional (May 2003)
7. Informationalism: "a technological paradigm based on the augmentation of the human capacity of information processing and communication made possible by the revolutions in microelectronics, software, and genetic engineering." From Castells, M. "Informationalism, Networks, and the Network Society: A Theoretical Blueprint." See also http://en.wikipedia.org/wiki/Netocracy.
8. "Slack", De Marco, Tom; Broadway (November 2001)
9. This chart is visible on page 5 of this document: www.clarkeching.com/files/why_your_business_needs_agile_software_development_v1.0.pdf

Rose photo credit - Ed Parcell

About the Authors

Chris Matts is a project manager and business analyst with over ten years experience developing trading and risk systems for Investment Banks including JP Morgan Chase, BNP Paribas and Dresdner Kleinwort Wasserstein. A former developer, Chris has a Master Degree in Mathematical Trading and Finance (including financial option maths) and a MEng in Micro-Electronics and Software Engineering. Chris is currently the programme manager on a product where he is using Real Options and Agile techniques to integrate the Sales and Projects teams.

Olav Maassen is chief engineer at QNH, the Netherlands and has nine years experience in IT doing projects for financial institutions. He is co-author of "Applied Java Patterns". His main interest is in helping teams develop software more effectively. Olav strives for continuous improvement both for himself as for those he works with.

Currently Chris and Olav are collaborating on a book about Real Options and how they really work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

real options.. by khurum hussain

who's the girl commenting on real options in the conclusion?

Hi Khurum, that was me. by Elizabeth Keogh

I'm an Agile Coach at Thoughtworks, and fairly new in the role. I have a particular love of spontaneous environments - places where people love to sign up to new work, try new things out, get stuff done. Spontaneity can't happen in a place where people have limited options, and spontaneity is fun!

The technical things that you can do with Real Options, are fairly easy to imagine (write two adapters, of course!) But I've used Real Options when considering whether decisions made now have to be permanent, and under what circumstances we'll revisit them (but not necessarily decide); to stop premature discussions in meetings, and to spot points at which we're shutting down our options unnecessarily, or not taking advantage of one. An example; as Iteration Manager, I'm moving from recording by iteration to recording by date. We don't need it at the moment, but it gives us the option to use that information in the future. Multicoloured finger charts! Cakes whenever a story gets finished in under 3 days! and what's the real impact of that post-release party?

Thanks, Chris; that conversation was fun too. :)

-- Liz

A question about the math... by Amr Elssamadisy

Why is the value of the option not important? Why is it obvious we should not make a decision earlier than the last possible moment?

We know from numerical methods that a series of local optimizations rarely lead to a global optimization. In the end we are looking for global optimizations not local ones.

Last responsible moment seems to me like we are putting blinders on.

Re: A question about the math... by Olav Maassen

Excellent comments Amr.

The value of the option is important, that's why we say that every option has a value. During the decision process you should look at the value of all your options and based on the price you would have to pay to get the value, decide what the best action to take is.

The reason for not making a decision earlier is that you don't gain anything by deciding earlier, but you can make a better informed decision if you wait until the latest responsible moment. If you know you can gain something by making the decision earlier, compare the immediate gain to the value of the options you're not using. And if you think you have to act earlier, do so, that's why the third line states: "Never commit early unless you know why".

Deciding what the best option is, is determined by your own context. If you are looking only for local optimization, that's fine. Deciding what constitutes the last responsible moment (time / circumstance / reaction) is essential and is influenced by many factors. The latest responsible moment is not just a specific time; it can be a specific time, or a response to an event, or a whole complex system of conditions to be met.

For an optimal decision process you should take the whole system into account and base the conditions for the latest responsible moment on the whole system not just the context of the decision alone.

You're only putting blinders on if you choose to, Real Options are not the blinders.

Deferring the decision. by Iain Brocklehurst

I don't think Chris and Olav are saying the value of an option is not important. In fact, quite the opposite. You absolutely need to understand the value of an option to understand when to exercise it. The value of the real options Chris and Olav are discussing does not always have to be financial, it could be related to some other change in situation. Flexibility within large programmes of work itself is often something very difficult to put a value on.

In terms of deferring a decision, I am fascinated by the human behaviour around uncertainty, and how uncomfortable it makes a lot of people feel.

If you look back over the last 15 years or so, how many people had easy access to email or mobile phones or the internet? I don't have to remember too far back to where video recorders revolutionised peoples behaviour and gave people options on when to watch films or TV progams.

Also, if you wanted to arrange to go for drinks you had to make a decision on where and when in advance. A lot of people who have teenage children today will agree that if they ask their kids at 6pm on a Friday night what they are doing tonight, they'll most likely shrug, grunt and point at their mobile phone. Teenagers have naturally adopted the "defer the decision" mentality, but the parents being of a different generation call it disorganised or lazy. Another example of how we are changing culturally is the popularity of LastMinute.com, TopTable.co.uk or other such sites that
allow you to avoid a lot of the detailed decision making (i.e. commitment) too far ahead of knowing where you feel like going or what you feel like eating, and therefore limit what your options are.

If you think about it, technology is helping us to avoid having to make decisions too far ahead when we don't have all the information we need. People are getting more comfortable with the uncertainty of not planning in advance as they have tools to provide them with options/choices at the time they really need to make a decision. However the older generation and my generation, still struggle with the "uncertainty" as they were not brought up in the "on demand" culture we see growing today. Perhaps that goes towards explaining why senior mgmt tend to not like uncertainty.

Re: Deferring the decision. by Chris Matts

The other thing about Senior Executives is that their diaries are normally planned very carefully. Often for months in advance. The idea of an empty diary is scary to them. They like to know what they are doing in advance so that they can plan other things around themselves. They operate a personal optimisation program that may make their organisation less efficient. Say I need the green light on program. It may take several months to get the authorisation which is a delay to the project. The delay is simply about getting a slot in the diary.

I like the mention of the "mobile" generation. The mobile phone is possibly the most important tool for a Real Option based approach.

Before the mobile phone, it was necessary for everyone to commit to a meeting place. Now, people can change their mind at any point and chose a new venue.

Re: A question about the math... by Chris Matts

Amr

Hello again. Will you be in Washington?

As Olav says, the value is important. Unfortunately you cannot use Black Scholes to derive the value. In fact, I am not aware of any model that will give you a reliable price for a Real Option. Quite often the value is not even monetary.

Most of the material I've read on Real Options apply Black Scholes to Investment Decisions without understanding the underlying assumptions (Stated or Unstated). When you investigate those assumptions as they relate to Real Options, it all falls down as a house of cards. In effect, the traditional Real Options approaches offer false accuracy. If you are interested, I can explain what those assumptions (Underlying Market Price, Liquidity, Risk Neutrality) are and why they fail for Real Options.

I agree whole heartedly on your second point. It is about time that IT departments stopped trying to optimise their own through put and costs at the expense of the wider business. When the only thing you can manage is costs, cost optimisation is your goal. Real Options appreciate that there is value in providing options to others and yourself. In effect, it avoids local optimisation. The question is always which level should you optimise? I suggest business unit is a good starting point.

By waiting to the last responsible moment, you give yourself the chance to incorporate late breaking information and consider alternative solutions. The "responsible" means that you need to understand the last point to make a decision without affecting the delivery of the project.

I'm puzzled by the blinker reference. My experience of normal management decision process is a quick brainstorm, big painful meeting to make a decision. Everyone gets behind the solution and runs like crazy. After that intial decision, there WILL be no deviation from the plan. Blinkers? Yes... This is the opposite of Real Options.

Re: A question about the math... by Amr Elssamadisy


The reason for not making a decision earlier is that you don't gain anything by deciding earlier, but you can make a better informed decision if you wait until the latest responsible moment.


This may be an instance of my misunderstanding - or seeing this misused in practice but this is local optimization.

By waiting for the last responsible moment for an action you are basically optimizing for that action and that action alone. If not, then how far up the context chain do you go?

My comment about blinders can be shown by using an example that was shown recently with the Soduko problem solved by both Ron Jeffries and Peter Norvig. Obviously Ron, with TDD, made decisions at the "last responsible moment" and reached a (significantly) suboptimal solution. On the other hand, Peter reached a much better solution by not doing so.

Re: A question about the math... by Amr Elssamadisy


As Olav says, the value is important. Unfortunately you cannot use Black Scholes to derive the value. In fact, I am not aware of any model that will give you a reliable price for a Real Option. Quite often the value is not even monetary.


So if there is no way to calculate the value on the option - doesn't that mean that there is no way to calculate the last responsible moment?

What I have seen in practice is that we tend to go overboard with this idea in our community. YAGNI, 'only remove duplicate code and your design will magically emerge', and 'wait, wait, wait, and then wait some more....'

I feel that there is a middle ground that we in the Agile community have missed and have overreacted to BDUF. There is a complex relationship that gives the optimal decision point.

Since we cannot calculate it - then we need a fuzzy solution. Let me suggest that it is in going away from frameworks - either CMM-like or the new and emerging Agile frameworks. The early reports of XP teams reported 2x, 3x, and more - and that was before 'last responsible moment' and other ideas. The current Agile teams regularly fail to reproduce that success. Is it because of Real Options or something more basic?

It is in each one of us taking responsibility and ownership and participating to the best of our abilities. We each have experiences - and those experiences give us our own estimations. Conversations, self-directing teams, and personal responsibility are more effective than mantras.

yes but by clarke ching

Hi Chris and Olav,

I remember talking to you a couple of years ago, Chris, about real options. I liked your thinking and I later had a chance to use the idea of "keeping your options open" while talking with my parents who were considering selling their farm and retiring.

It turned out that they actually had many options which they could explore and I thought they were prematurely choosing the most expensive one (selling the farm). We discussed the options but in the end they going with their first choice - i.e. they sold the farm. Why? My Dad said that they just felt more comfortable with the decision made and were pleased they no longer had to think about it.

I wonder if you've seen any research, writing or even your own opinions about how different people or personality types cope with the "ambiguity" of keeping their options open?

Re: A question about the math... by Chris Matts

Amr

We are not saying the "The last responsible moment." We are saying "Options Expire. Do not commit early unless you know why."

Even though we do not know the exact value, we do know an option has a value. Also, we can specify when an option expires.

Let me illustrate with an example.

I was working in an Investment Bank. We were developing a web site to display the results of some funky new analytics (clever maths). We had two choices. One, build on a strategic platform, or two, build a tactical solution that would be migrated to the strategic solution at a later date. The sales team insisted that we get to market asap. A month delay was unacceptable.

Unfortunately the strategic platform was still in development and was not in production. The funky analytics were currently in the hieroglyphics on paper stage. We could not start on the development until the analytics were complete (or at least the API was stable).

In typical fashion we held a meeting of about 20 very very smart business and IT people to decide between the two.

We decided on the tactical solution because we thought it would be quicker.

I was the project manager for the Web site.

I decided not to make a commitment to this decision. We were trying to decide which would finish first... The funky analytics or the strategic platform. We estimated that it would be at least a month for the analytics.
The expiry date for this option was actually the date on which the analytics were complete.

I asked the strategic platform guy to run like hell. I reordered my development plan to push the option expiry date out.

As it transpired, there were issues with the analytics (that were caused by market events outside of the bank) and they were delayed.

The solution was developed using the strategic solution which was quicker to market than the tactical solution would have been. In addition we saved several hundred thousand dollars by not developing the tactical solution. Simply by delaying a decision by a month or so, with no impact on the delivery date.

I would like to emphasize "Do not commit early UNLESS YOU KNOW WHY." This is the middle ground. It is not a hard rule. It is a principle. Observe people's especially manager's, behaviour. Quite often their default decision process is "NOW!". No middle ground.

Could I value the strategic/tactical option? No. Did I know when the option expired. Yes.

I hope you will be at Agile 2007, because I would love to take you through the full model.

chris

Re: yes but by Gary Sage

Clarke two points to look at here.

Wherever there are options there will be ambiguity by definition. Beware of using personality typing to predict outcomes such as commitment to a course of action. Commitment to an option is determined by state of mind, not personality type. It's state of mind that determines how one "cope"s with ambiguity and the associated choices present.

All sorts of factors will influence the excitement (or stresses) inherent in holding out for the "best" option because in the end selecting an option denotes commitment. All decisions - or commitments are triggered by feelings - (it's long subject - I'll take it offline if you wish) but in a nutshell the final driver in any decision is "it feels right". No matter how much logic or academic analytical rigour you apply to defining options, in the end commitment boils down to down to a trigger called "it feels right". Basically if one or more options create more "emotional stress" (pain, uncertainty) than others (relief/gain, selling a farm) then the commitment trigger will be driven by the criteria that provide the "best value" in the case above, selling held more "value" than the other options. Hope this helps.

Re: yes but by Chris Matts

Gary

My understanding of Myers Briggs Type Indicators would suggest that adoption of a Real Option based decision process would cause a migration from J (Judging) towards S (Sensing).

Chris

Re: yes but by Deborah Hartmann

Oh, like our world NEEDS more P's, lol

Re: yes but by Gary Sage

Chris
We need to bear in mind that Myers Briggs typing attempts to categorise a complex emergent entity (a person with thoughts and feelings) - with a view to infering that some groups (J or S types) would respond to an emergent environment containing options in a predictable way.

By attempting to classify people into like MBTI style "predictable types" we presuppose each type has a predictable set of limited options. Some may even wish to infer that your "type" could provide insight into the way in which you exploit options. By grouping people into types we are in effect assuming limits to the options available, when exactly the opposite is true.

Options provide choices - time and stress (neediness) regulate the excitement and prioritise the options - and finally commitment to a decision brings closure (gain); everything takes place as complex set of relatively simple interactions - the term for this is emergence. Statistics, Astrology, MBTI, etc assume a reductionist or constructivist approach to determing the probability of a single outcome.

Options are different; options provide true freedom of choice - (free will) - they provide the opportunity for a multiplicity of outcomes.
Options provide a platform for emergence - where anything can or may happen and usually does.

Regards
Gary

Real Options by John Beyer

If Toyota only builds cars after they have been purchased, what are all the cars doing in their sales lots? I love the concept. The last time I bought a car, I specified my requirements, after which the salesman said "I'll find you your car". I said "I don't want you to find it, I want you to BUILD it". Six weeks later I had the exact car I wanted! Howefver, it was not a Toyota!

Just a couple of thoughts...I've often found that there are many shades between "right decision" and "wrong decision". It is rarely a simple binary outcome.
Secondly (and this might be more related to Agile, in general, than to Real Options), I often encounter projects where functionality cannot be broken down into discrete, deliverable components/features. Oftentimes, a complete, end-to-end process must be delivered in order to have ANY useful funtionality.
Nice article.

Re: A question about the math... by Jason Hull

One thing that doesn't seem to be covered in the commentary is that most valuations derived in business cases where real options can be used are estimates. Certainly, there are usually some numbers to back up assertions, but at some point, you hit a jumping off point. What the valuation models do is try to average out a range of estimated outcomes. Instead of having a decision tree with two discrete and finite points, you find a range of potential outcomes and probabilities attached with each (e.g. a Poisson distribution). So, while valuing the option is an imperfect science, so is valuing and predicting the outcomes. By utilizing real options, you increase the probability of knowing your outcome because of more information, but it is not a guarantee of any outcomes. Time makes the crystal ball a little less murky, which is valuable in and of itself.

Nice post. I've enjoyed reading it!

Re: Real Options by Amr Elssamadisy

So if it is not a Toyota! - is that a good thing or a bad thing?

Re: Real Options by Chris Matts

Hi John

Toyota were the first to cater for two types of buyer. One buyer wanted to buy a car that day. They could choose from anything on the lot. The other buyer was prepared to wait a few weeks for the exact car they wanted.

The Toyota Way has spread throughout the motor industry and on to most manufacturing industries. Womack and Jones's Lean thinking gives a few case studies.

I agree on the right/wrong decision thing. When you force yourself to make a decision NOW, you often end up with a polarised decision. Giving yourself time allows you to come up with other options, often combining more than one. This is the subject of Roger Martin's "How successful leaders think" article in the June 2007 of HBR.

I agree on the functionality point. We tend to deliver Minimum Marketable Feature sets (or MMFs), the concept originated in "Software by Numbers" by Denne and Cleland Huang.

Re: A question about the math... by Chris Matts

Hi Jason

Thank you for your comment.

I'm with you here. I started out trying to value the optionality in Agile... And failed. Then I tried to use Real Options to generate business cases... And failed. Then I realised pretty much all business cases using ROI were Crystal Ball gazing as well. What is most important is that people actually put together a business case in the first case. This means people think about how they are going to generate business value.

As I've tried to develop business cases over the years I have found that the business often push back on ROI based business cases. This feature will mean we will process 1000 trades, with $1000 profit on each... Instead, a Real Option approach, we say This feature will give us the Option to process 1000 trades. Then we can guess probabilities for each trading volume which should generate ranges rather than a single value.

ROI and Black Scholes based analysis can give a false sense of accuracy. As you say, Business cases are crystal ball based estimates, and waiting gives you a better insight into the future.

Re: A question about the math... by Plamen Neykov

Chris, Olav,

an interesting aspect of the delayed exercise of real options is to look at the already known properties of normal (financial, or commodity) options.
It is well known that the so called american call option should be never exercised early (prior to expiry), however the opposite is true for the so called american put option. (there is an easy mathematicall proof of this in John Hull's book).
Is it possible that your statement about no early exercise applies only to certain class of real options but for some other classes there is more optimal exercise point of time prior to expiry?

Re: A question about the math... by Jason Hull

One case where you would exercise early is when there is an additional dividend declared with an ex div date prior to expiration that was not known at the time of the purchase of the call option (which has known dividends priced into the option price, presumedly). I would imagine that the same would apply here; exercise the option early when the underlying assumptions change or when there accrues an additional dividend (so to speak) that was not previously known or incorporated. Another possibility is when taking a path frees up resources which can then be applied to a higher ROI activity. This doesn't address "classes" per se, but situations.

Re: A question about the math... by Olav Maassen

Hi Plamen,

you are right. The optimal exercise point of time can be very dependend on the context in which it resides. Therefore it is important to stress the 'unless you know why' of the third rule. With the american put option you know why you want to exercise early and there are even situations where it actually makes sense to execute a call option.

One other point to make here is that options expire, which means that at that point in time they no longer have any value (or significantly less). Waiting till the expiry time may be very risky as circumstances may change and expire your option even earlier than you anticipated. This also is part of the knowing why.

Re: Real Options by John Beyer

Turned out to be a GREAT thing. The car was an Oldsmobile (in 1990, long before they went out of business). That was not GM's 'preferred' sales methodology (there were incentives for moving cars off the lot). However, American consumers had leverage as car buyers long before the internet exposed the MSRP myth! You could order a car at invoice price, specify exactly what you wanted, and add $100 for the salesman's efforts.

Sorry, Chris. I know none of this has anything to do with Real Options!

Real Options: Where do they fail? by Iain Brocklehurst

Chris/Olav - got a "dirty dozen" question for you.....

So where would you NOT want to use real options, and where would they fail to be effective?

Not Math - Personality types by Tim Murnaghan

Given that this is about behaviours, and not Black-Scholes, the question is how we can get people to let go of the spurious feeling on control they get from a big plan up front and have them realize the real control that they can get from making decisions when they're needed. As mentioned in the thread this is probably about personality types - some people are uncomfortable with the idea of ending up where it takes you rather than having the defined end point. This is especially true if people with that personality type have been more effective at getting to influential positions in your organization.
What can be done to win them over?

Re: Not Math - Personality types by Gary Sage

Tim - Your first question:
"how we can get people to let go of the spurious feeling on control they get from a big plan up front and have them realize the real control that they can get from making decisions when they're needed"

The secret is to make people curious enough to be uncertain about their existing options, thereby getting them to explore further options. The notion that good communication is driven by hard facts, logic, correctness or even grammatical rigidity and perfection is a fallacy - a clear logical sensible concept that holds little or no perceived value to the other party is not going to fly - period.

I believe the best way to approach understanding and promoting real options is to acknowledge the need to clarify and put things in such a way, that everyone else gets the point and understands options in the same way you do.

Beware of throw-away statements like
"ending up where it takes you rather than having the defined end point"
this will provoke fear in any uninitiated personality type. The "psychology of uncertainty" is something you need to overcome not provoke.

In the Fifth Discipline, Peter Senge points out that in most businesses, discussion take place instead of dialog. Discussion takes place when people state their views, position or observations and then provide reasons to defend (justify?) their beliefs.
Dialog takes place when people state their views, position or observations and then give their reasons, and invite exploration and appraisal of their reasons and presuppositions. A position is not supposed to be presented purely for the purpose of defending it. A view is presented “tentatively” - not as unassailable fact - with the keenness to acknowledge that others may just be able to improve the position, or else to illustrate why it is altogether unsustainable. Most of us will probably agree that “two heads are better than one” however when it comes to discussion, many people behave as though “my head is better than all others combined!” Dialog leaves people open to the concept of options - discussion is often focussed on a pre-established agenda or end-point. The problem is that however subtle the semantic difference - behind dialog there are many options, behind a discussion invariably lurks an agenda.

The answer to your second question lies in being able to communicate in two modes: yours and theirs simultaneously. Everyone experiences life through his or her model of the world. If you communicate with other people using only your own model, your response may not be what you expect. Suspending judgement and observing the response you get while you communicate, and adapting a flexible perspective is what sets the great apart from the rest of the herd. These people take responsibility and ask - “what do I need to say and do to get my point across clearly and convince them of its value?". Forget personality types in this context - it's up to you to evangelise and discover what others find valuable.

Real Options-is it ubiquitous? by Raymond Barlow

At a very high level, I think that real options in Agile are your stories. Your stories are your options. Iteration planning meetings let you decide what goes into this iteration (where this iteration is the last possible moment).

At a level a bit closer to the ground, the details of an individual story can be left until the last minute (e.g. a quick discussion with the customer as you launch into a new story). They tell you what they need to see before the story could be considered 'complete'

At the ground level, BDD and TDD give us the ability to specify what the facets of that story are. We write the specification for the story, as code-but we don't implement it until the very last moment. By which stage the decision on HOW to implement the story (or that single specification) becomes a no-brainer. Using true BDD and TDD approaches, the actual implementation of the code is a lot easier that the decision of what to implement (or how to implement it). BDD/TDD is the thought process-the discovery process. It allows developers to discover the options that are available.

If you cannot specify the functionality as a coded spec, then you obviously do not have enough information to make that decision-a great time to make no decision, go back to the customer and flesh out the detail some more.

What's I like about real options is that it is all-pervasive. A methodology that can be applied at the coarse grained as well as the fine grained is great! It gives members of the team, at all levels (customers, management, code-monkeys etc) a common understanding of how to approach an option, and when to make that decision.


BTW...Great article guys! ;)

Re: Real Options: Where do they fail? by Chris Matts

Great question Iain.

I apologise for the delay answering the question. I was in a bar last night watching "Shaun the Sheep" with a friend. An option to consider if you get the chance.

There are two situations where you should ignore the Real Option approach.

1. When your gut screams at you to get out of a situation. Get out! Get out fast!

Malcolm Gladwell's "Blink" contains a story (pg 122 on Amazon.com ) of a fire lieutenant who orders his team out of a seemingly routine kitchen fire... moments before the floor collapses.

Real Options are a conscious mind tool. Your conscious mind can only process information is it consciously aware of. The sub-conscious mind is aware of other information that a person's conscious mind might not be focused on. When the sub-conscious mind becomes aware of a threat, it will communicate through the body creating a sense of foreboding or unease. If this sense is acute... move fast. Any direction you can.

By conscious / sub-conscious, I mean the things you are focused on as opposed to your mindful peripheral vision (senses).

2. Sometimes other organisations are using utility and option based pricing models. This means the longer you wait, the more it will cost. This is not a problem when people say "Buy before 20th June and get 10% discount." In this case you know when the option expires. The problem is when the price changes based on unseen stimli to the system. The classic example is airline flight prices. The price goes up as more seats are sold and as it gets closer to the flight time.

Last year I decided to go to Agile 2006. I looked at flight prices on Wednesday and discovered it would be cheaper to do a stop off in Toronto. About $1000 in total. I e:mailed some friends in Toronto to see if they were free. On Friday I got the replies and tried to book the flight via Toronto. It had gone up to $3000. In the time it took me to check out expedia (ten minutes), the price went up to $4000. Someone else had obviously bought a ticket and sent the price up. Options are worth more when there are fewer of them. Supply and demand.

This year rather than wait until I knew for certain that I was going, I booked a suite in the conference hotel (free option that can be cancelled up to the day of stay) and bought a flight well in advance. It was likely I would go and the earlier I booked the cheaper the flight. I bought a flight ticket for $1000. The airlines reward you for removing their uncertainty.

Real options are about knowledge. Knowledge allows us to make better decisions. Two colleagues in New York were thinking of attending Agile 2007. They were getting the company authorisation when the "Nearly sold out" sign went up. I told them to buy immediately. They were worried they were commiting to the approx $1000 conference price. In actual fact they were committing to $100 which is the admin charge for a cancellation. They bought the option to attend for $100. A few days later it sold out.

Finally. On eBay, experienced bidder wait for the last minute to bid. They do not commit too early. They might decide weeks in advance to buy that rare signed edition of the white book. But they wait to the last minute to bid (commit) to get the chance to read chapter 3 (plus the other stuff on coding).

Night night.

Re: Real Options-is it ubiquitous? by Chris Matts

Raymond

Thank you.

Yep. Real Options are for everyone. Inside and outside the community or organisation. CxO down to Lawyer.

I agree on the story point.

Andy Pols and I are working on a Real Option, TOC based software investment, project management and community coordination tool. The metaphor we are using is a dream. A dream is a story that does not exist. Once a dream is implemented, it becomes reality.

demo.pols.co.uk/dream/world/available

We even realised a dream for Ward. Check out the bad patents.

Re: Real Options: Where do they fail? by Olav Maassen

Chris,

I have to disagree with you here.

I agree on the first example. In his book 'Blink' Malcolm Gladwell explains very well how our subconcious works and how we should listen to it and improve it. There are circumstances where something just doesn't feel right and you don't know why. There are many examples of this in the book and I can highly recommend it.

The second example is actually an example of Real Option theory. The third 'rule' of Real Option theory says to not commit early unless you know why. In the flight tickets situation you actually know why you want to commit early. If you don't commit early the prices go up dramatically over time. Therefore you commit early.

Re: Real Options: Where do they fail? by Iain Brocklehurst

So Chris - your airline example is perhaps a 'Real Future'?

Re: Real Options: Where do they fail? by Chris Matts

Olav

OK.

You have me here. Next time I'll reply before the glass of wine instead of after.

Chris

Re: Real Options: Where do they fail? by Jan Willem Alfenaar

Hi,

In my role as project manager, I prefer early decisions, instead of having them as late as possible.

Early decisions reduce the complexity and gives direction to the team, and clarity for the customer what we are really doing. Have a clear goal for the team increases motivation, while being vague because several options are still open can lead to misunderstanding/miscommunication.

Early decisions also reduces time(money) spent in (re-)discussing options and trying to have a good overview on them all.

I'm not saying that decisions are final. Let's see them as working assumption. When the need arises (especially brought up by the customer), most decisions can be debated again.

Making a decision sometimes takes into account several stakeholders in a complex project. So when an 'option expires' one may find out that a decision is not made fast enough because of the involvement of several people in the decision itself.

Jan Willem

Re: Real Options: Where do they fail? by Chris Matts

Hi Jan

Thank you for your comment. It is a question that often arises. In fact I was discussing this issue with a friend of mine over curry a couple of weeks ago. He also had a go at Real Options with Game Theory. Poor old Game Thoery ;-)

Are you going to Agile 2007. I would love to discuss this further.

My response...


In my role as project manager, I prefer early decisions, instead of having them as late as possible.

Early decisions reduce the complexity and gives direction to the team, and clarity for the customer what we are really doing. Have a clear goal for the team increases motivation, while being vague because several options are still open can lead to misunderstanding/miscommunication.

Early decisions also reduces time(money) spent in (re-)discussing options and trying to have a good overview on them all.


Making decisions early does not reduce complexity. It increases it.

I live outside of London and commute into Central London each day. My preference for getting to work is bus1-train-drain-bus2-walk. I do not decide how to get to work until I set off. Over the past year, each of bus1,train,drain,bus2,walk have been unavailable as options. In each case I have used another option. Taxi, Tube, Walk... On one occasion, a train strike was called so I immediately booked a taxi to take me to work. I heard on the radio that the strike was called off at the last minute and I cancelled the taxi 30 minutes before setting off to work on my usual route.

If I stuck to bus1-train-drain-bus2-walk I would fail to reach work about 20% of the time. Getting to work would be a complexity nightmare.

In all cases, my goal has been consistent. To get to work. Funnily enough, I do not need to know how my team get to work. If they have problems, I need to know when they will be in so that I can manage the situation. Your customers are the same, they do care about Java/C#/Python/Ruby. They care about the destination, and when you will get there.

A less abstract example. I am aware of a project where the Project Manager had to chose between Java and C#, the two corporate standards. He chose C# for a good reason, not sure what it was. He then hired the team. He was unable to hire any C# developers and ended up with a team of eight Java guys. He cross trained them to C# on the basis that they were commited to the technology, after all, they had already developed several man days of code. A better decision would have been to wait until you had hired at least a couple of guys for the team, or at the very least, checked out the job market. However, the manager liked to make decisions in order to reduce complexity.


Early decisions also reduces time(money) spent in (re-)discussing options and trying to have a good overview on them all.


Sorry, not my experience. Most of the time is spent by people trying to convince other people that their crystal ball (experience) is better than the other person. A discussion where everyone suggests their options which are simply recorded and questioned for details is quick and painless. Either that, or people do not know how to present, or express themselves properly.

Coming back to another comment. Most decisions are based on crystal ball gazing. We suggest you throw out the crystal ball and wait to see what happens.


Making a decision sometimes takes into account several stakeholders in a complex project. So when an 'option expires' one may find out that a decision is not made fast enough because of the involvement of several people in the decision itself.


I know what you mean. I worked on a project where we bought together twenty business and technical people to make a decision between a tactical and strategic solution. I ignored the decision to go with the tactical solution. A month later when it was obvious that the correct solution was the strategic one. No one even bothered. People were not emotionally linked to a solution but rather to a particular crystal ball.

In another example, I joined a forty man project that had been running for two years. Not a single line of code had been written, but lots of decisions had been made. It was obvious that a number of decisions (assumptions) made by the great and the good at the start of the project were wrong. I suggested changing one. No crystal ball required, just common sense. The PM agreed but I was told it would be too difficult to assemble the required people to overturn the decision. I doubt if that would have been necessary, a simple email outlying the current situation and the intent to change would have been enough, but I'll never know.


So when an 'option expires' one may find out that a decision is not made fast enough because of the involvement of several people in the decision itself.


How to determine the "exercise date". Start with when the solution needs to be in place (X). Work out how long each option takes to develop (L). Add appropriate contingency based on risk (C). The expiry for each option is X - L - C. If you work for a company where management need to review decisions, add some to L. You will see how your management processes limit your options.

Many thanks

Chris

Cost optimisation - Does that become an excuse to pre-build stuff ? by Prashant Gandhi

Quick q on real options - How do you deal with cost of creating the option in the first place ? Would it be a wasteful cost if that option is not really exercised ?

I know you speak about cost optimisation. But it should not really become an excuse to pre-build stuff e.g. "Frameworks would give you more options in the future to quickly deploy business applications"

Re: Cost optimisation - Does that become an excuse to pre-build stuff ? by Chris Matts

Great questions Prashant, one that gets to the heart of the problem in IT. IT departments try to optimise the cost of software development. They do not optimise the delivery of business value.

Consider the situation where a client will chose "A" or "B". Say the profit is $1Million, solution "A" costs £100K and solution "B" costs £100K. Now say the client will chose the provider that delivers the quickest solution. Which do you build? Well, it could be that you build both options at a cost of £200K. Traditional IT wisdom is to chose which one to build which optimises IT costs but not business value. i.e., you take the risk you make the wrong decision. building both is exactly what Microsoft did in the early 1990s.

As for building options... We know they have value. You can estimate the value (but do not use Black Scholes) and then compare to the cost. The key thing is to know when you have to start. The cost of the option is subjective. If everyone is flat out on building a feature for a client, then the cost of time is high. If people are between features, then the cost is effectively free. Do not associate cost with man days. Unutilised resource is free. Do not let the accountants mess you up.

Analysis is a knowledge option. We use analysis as an information discovery process. The key thing we are interested in is not the detailed analysis but how long it will take to build the feature. What is the takt time? We may never use the analysis but its value in "sizing" the effort is very valuable. We would not use an analyst to do this if they are working on something else, only if they are free (in more ways than one). The same with developer frameworks. You should not be building them on the critical path. They should be developed when the developer time is free.

At the moment, there is a LOT of low hanging fruit. Most Real Options you build are effectively free. Developers on the beach building frameworks are building free options.

Accountants would say that you used the developers and should assign their costs to an option. In actual fact the developers on the beach are an option. The option to deploy a developer quickly...

Theoretical Value by Fred Tingey

It is worth distinguishing between the (Theoretical) Value and the Cost of Real Options. The Value is the “fair value” of the option; the price at which you would be 50:50 on having it or not. The Cost is how expensive it would be for you to set up. If the Cost to you is less than the Value then you should buy/build it. If it is more then don’t bother.

One thing for sure about options is that they cannot have a negative Value.
However their Value can drop from whatever it was originally.

An options value changes when new information comes in. If the information is very bad the option would become worthless but if it is good the option would become more valuable.

One of the difficulties with Real Options is actually quantifying their theoretical Value. I suspect that it is far easier to give various options a relative value (bigger, smaller, about the same) than to actually quantify them in any absolute sense. I confess I have not managed to work out a precise theoretical Value of any Real Option.

The theoretical value of the option is how much you would be prepared to pay to have it given what you know right now. So the difficulty is in estimating both the likelihood and impact of good information vs. bad information.

A zero Cost or free option is always worth having. Its theoretical Value cannot be lower than the Cost. If bad information comes in it has cost you nothing whereas if good information comes in you gain Value by having the option.

One of the nice things about Real Options is that they provide a very general argument in support of making decisions ‘at the last responsible moment’. This can be re-interpreted as never exercise a zero Cost option early. They also provide a very general argument that there will always be a price worth paying for an option (even if it is not so obvious how to calculate it). However, if you can show that the Value is “clearly” greater than the Cost of the option then having exact figures does not matter.

So; Real Options are worth having when the Cost of setting one up is clearly less than its theoretical Value.

Re: Real Options (Toyota) by Steve Freeman

@John Beyer

First, Toyota had to change their approach in the US to fit with the local culture. Apparently in Japan they have a much tighter relationship with their customers.

More important is their approach to design. When designing a component, they will keep three streams running in parallel: a fallback based on known practice, an improvement that they expect to be able to make in the time, and an impossible target that will change the game. At the last possible moment, they will pick one. This means that they always hit their design dates, but sometimes get to make radical improvements.

The point is that they understand that minimising cost (i.e. only picking one stream) does not bring the most value. They're prepared to spend on options to achieve reliable delivery and, possibly, better quality.

Is it just common sense? by Tim Velvick

Interesting article. I think there definitely something in our make-up with causes us to strongly prefer certainty, but if we can let go of this there is often a far better outcome available.

It's also true that you can use options theory as a tool to analyse certain situations, but how you apply this as a tool is highly subjective. For example, this article suggests deploying projects resources on a least-experienced first basis, since you're buying a cheap option; However, you could equally apply option theory and decide that by putting the most experienced developer on the project, you're buying a cheap option (the option to reuse component that the more experienced developer has used before). Is 'Option theory' just a posh way of saying 'keep your options open'? The real art of management is look at the infinite range of possible options and determine which are valuable to you.

I think we have to be careful that we don't try and look for something too scientific here, and I think the link to financial options is a bit of a red herring (it tells us that keeping an option open has value, but we should know that already, even if we don't always apply it). A financial option contract is useful for managing a known unknown (e.g. a UK company buying an American product in 3 months doesn't know what the GBP/USD exchange rate will be, but it a clearly defined one dimensional unknown). A project manager's job, however, is largely about unknown-unknowns.

Re: Real Options: Where do they fail? by Faisal Jawdat

In my role as project manager, I prefer early decisions, instead of having them as late as possible.

Early decisions reduce the complexity and gives direction to the team, and clarity for the customer what we are really doing.


Sometimes this implies a framing problem -- you're putting off decisions, but if you know what the conditions are for the future decision (e.g. in financial options: is the option worth exercising) then you're really, making a decision today (you are deciding to pick A or B in the future based on a known set of conditions). Sometimes this framing is enough to keep the team moving in the right direction (we've decided to pick route A or B at date X based on whether or not technology A meets the criteria we have outlined today). By specifying the conditions now you can reduce the future decision down to a quick yes/no evaluation. If postponing the choice has a cost then you can take this into account in the immediate decision (e.g. it will cost one additional staff-week if we put the decision off 3 months, but we see a 50/50 chance of either choice being the right choice in 3 months, and the cost of reworking from the wrong path is 10 staff-weeks).

This does highlight an ambiguity in terminology: there are cases where you actually make the decision now but you're putting off what you decide until you have more information. The decision is created now but evaluated at a later date.

GJ, Chris and Olav by HIRANABE Kenji

I finally arrived at this article, today!
ditto, ditto.

It is easy to show by math that the sigma of the potential value times its possibility through all the possible branches of the future can be maximized by Real Options.

Is the sigma of "fun" also maximized ??

-Kenji

Real Option Theory & Variable Costs by Ng Jesse

I found a paper which state that "because the value of flexibility increase with uncertainty, high variable and low fixed costs become more attractive as uncertainty increases. Real-option theory therefore implies that the ratio of variable to fixed costs should increase with high uncertainty."

Actually, I don't understand this statement, anyone can help me to understand? thanks!

The paradox of Choice & Real Options by Yves Hanoulle

I'm rereading this article as I want to explain Real options to a clients managers. Since I first read this, I have also read The paradox of choice. www.amazon.com/The-Paradox-of-Choice-ebook/dp/B...
In the book Schwartz says that having more options does not make us any happier. (on the contrary)
Could this paradox be a reason why people prefer to make choices earlier?

XP Customer by Curtis Cooley

To clear up a common misconception about the XP Customer, XP always wanted a real customer to work in the building with the team at all times. Many times this is not practical or possible, so the commonly advised compromise was a "proxy" who got out of the building early and often to talk to the real customers. At no time, at least as far as I have seen, did XP prefer or advocate the customer "proxy".

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

45 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT