This document discusses real options analysis and how it can be applied to make decisions on software projects and architecture. It provides examples of using techniques like identifying options and their costs/values, setting decision deadlines, and implementing options in parallel to avoid sunk costs and keep options open. The key message is that real options analysis focuses on creating flexibility and avoiding premature decisions by planning to decide later when more information is available.
7. 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
20. Real Options Team to the
Rescue!
“Give us a day and we’ll tell you when and how to decide”
Olav Chris Chris
21. What is the problem?
Cost of Delay: a delay (even one day) can
cost us 50% of sales
22. Real Options
Real Options
Have a cost (= the price of the option)
Have a value
Have a price (“strike price”) when we exercise the option
Have an expiration date/condition
~ “Call Option”
An option is not an obligation
This is a metaphor
23. 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
design
2. 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
24. Comparing our options
Option Cost Price Value Expires
Blue ??? / Consistent
Design
???
Yellow +
Blue
??? Blue
redesign
Cost of
Delay == 0
???
25. When do we have to
decide?
Yellow + Blue option ???
Blue option ???
DecNov
Stock
shops
Oct
Produce
DVD+box
Servers
????March
We are here!
26. 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.”
27. 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)
28. 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
29. 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
30. 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”
31. 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)
32. 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)
33. 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
34. 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
35. 3. Real Options
Optimal Decision Process
Option Implement
Option
Option
Decisions Deadline
http://commitment-thebook.com/
36. 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:
40. 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?
42. 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…
45. Retrospective
• Decision: platform A
• Implementation A in production on time
• Dev+Test platform continues to be used
• Implementation B was wasted
• To be continued...
47. Company B acquires A
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é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
48. 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 B
B
C
55. 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”
56. 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
57. 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”
59. 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
62. 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”
64. 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”
65. 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!
66. What is the added
value for your
customer of your
architecture and
process?
67. 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
68. 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
70. Principle of the right moment
Easy to change decision: decide early
Hard to change decision:
• Make it easier to change
• Delay decision date
71. 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”
72. 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
