real options: how and when (not) to take decisions
DESCRIPTION
Some stories that tell how we applied Real Options, the Creative Process and Set-based Design to deal with some tough architectural decisionsTRANSCRIPT
Real Options: how and when (not) to make
decisionsPascal Van Cauwenberghe
ConsultsManages projectsPrograms
Creates gamesTells storiesOrganises conferences@pascalvc
http://blog.nayima.be
http:/www.xpday.net
http:/www.atbru.be
http://www.cafepress.com/+true-story+mugs
Once upon a time...
The project (1)
http://www.flickr.com/photos/seandreilinger/2187892869
http://www.flickr.com/photos/rohdesign/3307874546
Video Game
Social website
http://www.flickr.com/photos/rohdesign/3307874546
The website
New DESIGN !!L'analyse par les Options Réelles est une technique qui permet de prendre des décisions sur les décisions. C'est cool, c'est meta.
Mais quel est l'intéret pour l'équipe au quotidien ?
Vous prenez plein de décisions chaque jour comme développeur ou architecte. Des décisions qui peuvent couter cher.
Les Options Réelles ne sont pas très compliquées, cela s'explique en quelques minutes. Mais en appliquant les Options Réelles sur les projets informatiques et sur l'architecture des logiciels j'ai découvert que plein de choses que je croyais vraies ou qui me semblaient intuitivement correctes étaient fausses.
J'illustre chaque technique avec des exemples qui viennent de projets auxquels j'ai participé les dernières années, ou bien de la vie de tous les jours.
Découvrez une autre façon de voir les décisions, des techniques simples pour gérer des projets ou définir une architecture de logiciel. Vous découvrirez peut-être que vous aussi croyez des choses qui sont fausses.
Au minimum vous entendrez quelques histoires belges... :-)
CELEBRITY NEWS AND GOSSIP WORLD EXCLUSIVES
The NIOUZE
Redesign de tous les sites!
Le “vieux” design jaune sera remplacé par un design bleu cool, fresh et clair
Template: www.presentationmagazine.com
Le Redesign
http://www.flickr.com/photos/rohdesign/3307874546
The team
Estimated sales
t
#
http://en.wikipedia.org/wiki/File:Sinterklaas_2007.jpg
http://commons.wikimedia.org/wiki/File:Jonathan_G_Meath_portrays_Santa_Claus.jpg
1. Cost of Delay
t
€
Previous redesigns
Creative Process
Problem
Generateoptions
Test and chooseoptions
Implement
Customer Supplier
Creative Process
Our Creative Process
Don’t try to decide too fast
2. The Creative Process
http://www.flickr.com/photos/miagant/5203621384
Real Options Team to the Rescue!
“Give us a day and we’ll tell you when and how to decide”
Olav Chris
Chris
What is the problem?
Cost of Delay: a delay (even one day) can cost us 50% of sales
Real Options
Real OptionsHave a cost (= the price of the option)Have a valueHave a price (“strike price”) when we exercise
the optionHave an expiration date/condition~ “Call Option”An option is not an obligation
This is a metaphor
What are our options?
1. Go in production with the (new) blue design• Yes but, we risk delay while we wait for the new
design to stabilize• Yes but, meanwhile there will be many changes to
the design2. Go in production with the (old) yellow design,
the redesign with the (new) blue design• Yes but, it won’t be consistent with the other sites• Yes but, the blue redesign will cost extra
time/money
Comparing our options
Option Cost Price Value Expires
Blue ??? / Consistent Design
???
Yellow + Blue
??? Blue redesign
Cost of Delay == 0
???
When do we have to decide?
Yellow + Blue option ???
Blue option ???
DecNov
Stock shops
Oct
Produce DVD+box
Servers
????March
We are here!
Questions for the developers
• Do we have to apply the design from the start?• “We’ve always done it like this, but we could do it
later”• How much time to apply the Yellow design?
• “Around one month”• How much time for a complex design?
• “Less than two months”• Imagine the worst design the designers can
create• Laughs. “Two months. We’ve got experience with
that kind of design.”
When do we have to decide?
Yellow + Blue option ???
Blue option ???
DecNov
Stock shops
Oct
Produce DVD+box
Servers
AugustMarch
We are here!
Design and test(2M)
How will we decide?
• IF the new blue design is completely stable• AND if the estimate of the blue design < 2
months• THEN we use the blue design• ELSE we use the yellow design AND we’ll plan
the blue redesign once the blue design is stable
• Meeting: August 1st
Meanwhile...
• We develop the site in “black & white”
• One team member participates in the followup meetings of the new design (2 hours every 2 weeks) and keeps the team informed of the situation
The day is not done yet
• A few more questions:• Developers, what changes when the
design changes?• Developers show architecture and code
• What if there was less to change?• Quick architectural “spike”: remove duplication, separate concerns...
• How much to refactor the site?• “We can do it in a few days”• “Afterwards, any redesign costs less than 1 month”
When do we have to decide?
Yellow + Blue option ???
Blue option ???
DecNov
Stock shops
Oct
Produce DVD+box
Servers
AugustMarch
We are here!
Design and test(2M)
When do we have to decide?
Yellow + Blue option ???
Blue option ???
DecNov
Stock shops
Oct
Producte DVD+box
Servers
SeptMarch
We are here!
Design and test(1M)
The benefits of reducing cycle time
• We can decide another month later• We have one month more to implement
functionality• The redesign Yellow=>Blue costs 1 extra
month, not 2
• New meeting date: September 1st
Comparing our options
Option Cost Price Value Expires
Blue 1 week of refactoring+ 2h followup / 2 weeks
/ Consistent Design
01/09/20XX
Yellow + Blue
1 week of refactoring+ 2h followup / 2 weeks
Blue redesign (1 month)
Cost of Delay == 0
01/09/20XX
3. Real Options Optimal Decision
Process
Option Implement
Option
Option
Decisions Deadline
http://commitment-thebook.com/
Retrospective
• 1 september: the blue design isn’t stable (no surprise). We keep using the yellow design.
• Product delivered on time• “This project was a lot less stressful than usual”
• Functions:
• Design:
And they lived happily ever after
Another story?
The project (2)
http://www.flickr.com/photos/seeminglee/8276505285p.s. La banque n’est pas HSBC
http://en.wikipedia.org/wiki/File:Rack001.jpg
Internet Banking Internet Banking servers
Your mission, should you decide to accept it...
• Online banking goes live on DD/MM/YYYY• Company X will develop the frontend• You need to deliver the backend servers on time
• A few small details...• We’re still deciding what server platform to use• We’ve started documenting the DB you have to
use• We’ll start documenting the requirements• “But start developing, because we don’t have a
lot of time!”• Would you accept this mission?
ImplementNot enough time
The problem
Platform A
Platform B
Decision
We are here!
Our solution
• IF we don’t have enough time to implement either Platform A OR Platform B
• THEN we implement Platform A AND B
• It’s logical when you think about it…
Our solution
Implement Platform A
Finish implementation of chosen platform
Implement Platform B
Decision
We are here!
Set-based development
APP
API
A Serve
r
B Serve
r
Test Serve
r
3 parallel implementations:• Platform A• Platform B• Development+test platform
Retrospective
• Decision: platform A• Implementation A in production on time• Dev+Test platform continues to be used• Implementation B was wasted
• To be continued...
And they lived...
Company B acquires AL'analyse par les Options Réelles est une technique qui permet de prendre des décisions sur les décisions. C'est cool, c'est meta.
Mais quel est l'intérêt pour l'équipe au quotidien ?
Vous prenez plein de décisions chaque jour comme développeur ou architecte. Des décisions qui peuvent couter cher.
Les Options Réelles ne sont pas très compliquées, cela s'explique en quelques minutes. Mais en appliquant les Options Réelles sur les projets informatiques et sur l'architecture des logiciels j'ai découvert que plein de choses que je croyais vraies ou qui me semblaient intuitivement correctes étaient fausses.
J'illustre chaque technique avec des exemples qui viennent de projets auxquels j'ai participé les dernières années, ou bien de la vie de tous les jours.
Découvrez une autre façon de voir les décisions, des techniques simples pour gérer des projets ou définir une architecture de logiciel. Vous découvrirez peut-être que vous aussi croyez des choses qui sont fausses.
Au minimum vous entendrez quelques histoires belges... :-)
CELEBRITY NEWS AND GOSSIP WORLD EXCLUSIVES
The NIOUZE
Redesign de tous les sites!
Le “vieux” design jaune sera remplacé par un design bleu cool, fresh et clair
Template: www.presentationmagazine.com
A little bit later
• Company B sends a letter to the bank
“Great news! We’ve just acquired company A. All development on platform A has been stopped. We will stop support very soon.
Please migrate to platform B.”• Easy!
A BBC
And they lived happy
4. Set-based development
Option A
Option B
Option C
That’s only logical, captain!
It’s just common sense!
Irratio
nal
Predictably Irrational
Sunk Cost Fallacy
• Our investment to date is gone• We should not take it into account when
deciding if we want to continue• Yet we value money and time spent very highly• Solution: look at the “deltas” of value and cost
• “Marginal Economics” (Reinertsen, Flow)
• Also: “Emotional Sunk Cost”
We suck at estimating
• We have trouble with absolute values• Use relative estimates to make decisions
• We overestimate the costs and underestimate the benefits of changing a decision• Once decided, we fear losing what we have
• We overestimate the value of what we have• This confirms that we made a good decision
• We overestimate the value of events closer to now (faulty discount function)=> We favour short term decisions
Choice Anxiety
• We freeze when there’s too much choice• Many choices, high odds of take the wrong choice
• We lose sight of the goal when we have too many options• Spend all our time “chasing options”• Create “generic solutions”
Above all...
We don’t like uncertainty
• Especially when under stress• These tools help me calm down, slow down
• We don’t decide, we plan to decide:• When will we make the decision?• How will we make the decision?• What data will we use? Where/how will we get the
data?• Who needs to be involved• => We make decisions quickly and confidently
• My favourite tool to manage options: my calendar
How did you survive this long?
6. We’re not rational, but we can fake it
What is architecture?
“Architecture are those decisions that are hard to change and must be taken at the beginning of the project”
If the decision is hard to change• Either we make it easier to change• Or we buy an option to move the decision back
I’m ready to pay for valuable options
• “Yes but… There are some things you can’t change”
Yes but… Options are too expensive
Another project (4)
• Hard deadline: the EU law changes on 01/01/YYYY• The current system is not compatible with the new
law• We’re building a replacement system• What happens if we’re too late (cost of delay)?• Deadline is getting nearer...• Shouldn’t we look at backup options?
• Option: ask vendor to estimate cost and last moment to start work to make current system compatible
• My estimate: option costs < 1000€• “No. Failure is not an option”
What happened next?
• System is not accepted for production in december
• Company can’t invoice it’s customers• Every month of delay cost X00.000€
• But we saved a few thousand euros on options!
What is the added value for your
customer of your architecture and
process?
Useful techniques (1)
• Cost of Delay:• What is the (financial) in time for early/late
delivery?• Creative Process:
• Create options, select options, implement• Options:
• Cost, value, price, expiration date/condition• Optimal Decision Process:
• Decision point = Deadline – Implementation Time
Useful techniques (2)
• Variation Separation:• Keep items with different rate of variability separate
• Set-based design:• Implement many options simultaneously. Choose
the best• Sunk Cost Fallacy:
• Forget your investment to date
• Create options for your customers
Architectural decisions
Principle of the right moment
Easy to change decision: decide early
Hard to change decision:• Make it easier to change• Delay decision date
Minimum effort principle
Don’t do tomorrow’s work today(YAGNI)
AND
Don’t do anything today that makes tomorrow’s work more difficult
Aka “The laziness principle”
A good architecture…
Creates options for your team; your organisation and your customer
Creating and maintaining the options is continuous, daily work in small steps
Otherwise you create legacy systems that contain fewer and fewer options
“Every seemingly bad situation or decision hides a good decision.
You just have to look.”
