Real Options:
Quand et comment (ne pas)
prendre des décisions
13:30h – 14:20h - Salle La Seine A

Real Options:
Quand et comment (ne pas)
prendre des décisions
Pascal Van Cauwenberghe
NAYIMA
We make play work
@pascalvc
27 au 29 mars 2013

Donne des conseils
Gère des projets
Programme
Crée des Jeux
Organise des Conférences
http:/www.xpday.net
27 au 29 mars 2013

http://www.cafepress.com/+true-story+mugs
27 au 29 mars 2013

Il était une fois...
27 au 29 mars 2013

Le projet (1)
Site Social
Jeu Video
http://www.flickr.com/photos/rohdesign/3307874546
http://www.flickr.com/photos/seandreilinger/2187892869

Le site
http://www.flickr.com/photos/rohdesign/3307874546

A la une
Redesign de tous les sites!
Le “vieux” design jaune sera remplacé par un design bleu cool, fresh et clair

Le Redesign
http://www.flickr.com/photos/rohdesign/3307874546

La reaction
http://browse.deviantart.com/art/Edvard-Munchs-Homer-71026771

Chiffre de vente (estimé)
#
http://en.wikipedia.org/wiki/File:Sinterklaas_2007.jpg
http://commons.wikimedia.org/wiki/File:Jonathan_G_Meath_portrays_Santa_Claus.jpg
t

1. Cost of Delay
€
t
27 au 29 mars 2013

Les redesigns précedents

Creative Process
Generer des Tester et choisir
options des options
Problème Implémenter
MOA MOE
Maitrise d’ouvrage Maitrise d’oeuvre

Creative Process

Creative Process chez nous

N’essayez pas de décider trop vite!

2.The Creative Process
27 au 29 mars 2013

Entretemps...
http://browse.deviantart.com/art/Edvard-Munchs-Homer-71026771

http://www.flickr.com/photos/miagant/5203621384

Real Options Team to the Rescue!
Olav Chris Chris
“Donnez nous un jour et on vous dira quand et comment décider”

Quel est le problème?
Cost of Delay: un retard (même d’un jour) peut nous couter 50%
des ventes

Real Options
Le options
• Ont un cout
• Ont une valeur
• Ont un prix (quand on exerce l’option)
• Ont une date d’expiration
Une option n’est pas une obligation
Ceci est une métaphore

Quelles sont nos options?
1. Aller en production avec le design bleu
• Oui mais, on risque d’être en retard s’il faut attendre que le design
bleu soit stabilisé
• Oui mais, entre temps il y aura plein de changements dans le design
1. Aller en production avec le design jaune, puis retravailler avec le
design bleu
• Oui mais, ce ne sera pas consistent
• Oui mais, le retravail va augmenter le budget

Comparons les options
Option Cout Prix Valeur Expiration
Bleu ??? / Design ???
consistent
Jaune + Bleu ??? Redesign en Cost of ???
bleu Delay == 0

Quand est-ce qu’il faut décider?
On est ici!
Option jaune + bleu ???
Production
DVD
Stockage
Magasin
Serveurs
Option bleu ???
Mars ???? Oct Nov Dec

Quelques questions aux développeurs
• Est-ce qu’il faut appliquer le design immédiatement?
• “On l’a toujours fait dès le début, mais on pourrait le faire plus tard”
• Combien de temps est-ce qu’il faut pour appliquer le design
jaune?
• “A peu près un mois”
• Combien de temps pour un design vraiment compliqué?
• “Moins de 2 mois”
• Imaginez le pire design que les créatifs peuvent inventer
• Rire. “Deux mois. On a de l’expérience avec ce type de design” 

Quand est-ce qu’il faut décider?
On est ici!
Option jaune + bleu
Production
DVD
Design et test Stockage
(2M) Magasin
Serveurs
Option bleu
Mars Août Oct Nov Dec

Comment est-ce qu’on va décider?
SI le nouveau design bleu est complètement stable
ET si l’estimation de la charge de travail du design blue est moins
que deux mois
ALORS on applique le design bleu
SINON on applique l’ancien design jaune et on planifiera le redesign
bleu quand il sera stable
Rendez vous: 1er Août

Et entre temps
On développe le site en “noir et blanc”
Un membre de l’équipe participe aux réunions de suivi du redesign
(2h toutes les 2 semaines) et tient l’équipe au courant de la
situation.

La journée n’est pas encore finie
On a encore quelques questions:
• Développeurs, qu’est-ce qu’il faut changer quand le design change?
• Développeurs montrent l’architecture et le code
• Et s’il y avait moins à changer?
• Petit spike architectural: séparation, déduplication...
• Ca coute combien pour améliorer l’architecture?
• “On peut faire cela en quelques jours”
• “Après, un redesign ne coutera jamais plus qu’un mois”

Quand est-ce qu’il faut décider?
On est ici!
Option jaune + bleu
Production
DVD
Design et test Stockage
(2M) Magasin
Serveurs
Option bleu
Mars Août Oct Nov Dec

Quand est-ce qu’il faut décider?
On est ici!
Option jaune + bleu
Production
DVD
Design Stockage
et test Magasin
(1M)
Serveurs
Option bleu
Mars Sep Oct Nov Dec

L’avantage de réduire le temps de cycle
• On peut décider encore un mois plus tard
• On a un mois de plus pour implémenter la fonctionnalité
• Un redesign jaune -> bleu ne coute plus qu’un mois au lieu de
deux
Rendez-vous pour la décision: 1er septembre

Comparons les options
Option Cout Prix Valeur Expiration
Jaune + 1 semaine de Redesign en Cost of 01/09/20XX
Bleu refactoring bleu (1 mois) Delay == 0
+ 2h de suivi /
2 semaines
Bleu 1 semaine de / Design 01/09/20XX
refactoring consistent
+ 2h de suivi /
2 semaines

3. Real Options
Optimal Decision Process
Décisions Deadline
Option Implementer
Option
Option
http://commitment-thebook.com/ 27 au 29 mars 2013

Retro
• 1 septembre: le design bleu n’est pas stable (ce n’était pas une
surprise) => design jaune
• Projet livré à temps
• “Ce project était beaucoup moins stressant que les précedents”
• Fonctionalité:
• Design:

Et ils vécurent heureux à tout
jamais
27 au 29 mars 2013

Le projet (2)
Internet Banking Internet Banking servers
http://www.flickr.com/photos/seeminglee/8276505285 http://en.wikipedia.org/wiki/File:Rack001.jpg
p.s. La banque n’est pas HSBC

Votre mission, si vous l’acceptez...
• On lance notre service online banking le DD/MM/YYYY
• Société X va développer l’application web
• Vous devez livrer l’application serveur à temps
• On est en train de décider sur quelle platforme
• On est en train de la documenter la DB que vous devez utiliser
• On est en train de rédiger le cahier de charge
• Mais commencez déjà à développer, car on n’a pas beaucoup de
temps!
• Accepteriez vous cette mission?

Notre problème
On est ici!
Decision
Plateforme A
Pas assez de
Implementer temps
Plateforme B

Notre solution
Si on n’a pas assez de temps pour implémenter plateforme A OU
plateforme B
On va implémenter plateforme A ET B
C’est logique... En Belgique 

Notre solution
On est ici!
Decision
Implémenter Plateforme A
Finir implementation de
la plateforme choisie
Implémenter Plateforme B

Set-based development
3 implementations en parallèle :
APP •Plateforme A
•Plateforme B
•Environnement de développement et test
API
A B Server Test
Server Server

Retro
• Décision: plateforme A
• Implementation A est allée en production à temps
• Implementation dev/test continue à être utilisée pendant le
développement
• Implementation B na servi à rien
• A suivre...

Un peu plus tard
• Vendeur de plateforme B envoit une lettre à la banque:
• “Bonne nouvelle! Nous venons d’acquérir la plateforme A.Tout
développement sur cette plateforme est arrêté. Le support sera arrêté
bientôt.
• Veuillez migrer vers la plateforme B.”
• Facile!
C
A BB

4. Set-based development
Option Option B Option
A C
27 au 29 mars 2013

Le projet (3)
• J’arrive sur le projet
• Le projet est déjà en retard: 12 mois au lieu de 9
• Exercice rapide de scoping et estimation...
• => Il faut encore +/- 6 mois pour compléter le projet
• Est-ce qu’on continue ou est-ce qu’on arrête?

Est-ce que ça vaut la peine?
Temps Coût
Déjà investi 12 mois 1,000,000€
A investir 6 mois 500,000€
Valeur 18 mois X€

Sunk Cost Fallacy (*)
(*) couts irrécuperables, couts échoués
• Investissement 1,000,000€ => 0€ de valeur
• Oubliez l’argent qui a déjà été investi, cet argent est perdu
• “On a déjà dépensé 1,000,000€”
• En comparaison 500,000€ ne semble pas beaucoup
• Comparez delta coût et delta valeur
• +500,000€ de coût => +X€ de valeur – 9 mois de cost of delay

5. Sunk Cost Fallacy
Marginal Economics
27 au 29 mars 2013

Emotional Sunk Cost Fallacy
• Il y a aussi les investissements immateriels:
• Temps de l’équipe
• Reputation
• Investissement emotionnel dans son produit
• Sécurité financière
• Tenez compte du sunk cost quand vous proposez un changement
• Surtout: quel est votre sunk cost?

Mais ce n’est pas logique, capitaine!

Irrationnel et fier de l’être
• Valeur(ce qu’on a) > Valeur(ce qu’on n’a pas)
• Couts > Bénéfices
• Valeur = f(prix) + g(nos attentes)
• On gere mieux les chiffres relatifs que les chiffres absoluts
• Les options peuvent nous distraire de notre but
• On ne sait pas choisir s’il y a trop de choix
• ....
• Comment prendre des décisions rationelles avec des êtres (et des
groupes) irrationnels?

6. On n’est pas rationnels,
mais on peut faire semblant
27 au 29 mars 2013

Encore une histoire?
OUI NON
27 au 29 mars 2013

Le projet (4)
Vendeurs Fabricants
EDI
http://www.flickr.com/photos/caseorganic/3216853440 http://www.flickr.com/photos/danielfoster/4725849931

La situation (avant)
IMPL
IMPL
EDI Fabricant
Vendeur

Les problèmes de nos clients
• Ceux qui veulent utiliser la plateforme doivent connecter leurs
systèmes et implementer 1 API
• Et puis nous configurons/customisons la plateforme
• Pour les vendeurs et fabricants de cette industrie c’est un
“grand projet”
• Les vendeurs et fabricants ne tiennent pas leur planning
• Donc notre planning de customisation ne sert à rien
• Une intégration dure longtemps, donc retour sur
investissement tardif

Et si c’était notre problème?
• Si chaque flux est indépendent, chaque integration est un petit
projet
• Si on peut customiser rapidement un flux pour un client, on n’a
plus besoin du planning du client
• Si on peut mettre les customisations rapidement en production, le
client a un retour sur investissement rapide et incremental

La situation (après) - Technique
IMPL
IMPL
IMPL
EDI IMPL
Fabricant
IMPL
Vendeur IMPL
IMPL
IMPL
IMPL

La situation (après) - Technique
• Chaque flux est un composant indépendant. Mais si le client en a
implementé plus qu’un ils coopèrent.
• Par exemple: il y a un flux pour les données catalogue et un flux pour
les commandes qui sont indépendants. Si on a les deux, le composant
“catalogue” peut faire des validations et augmentations pendant la
commande
• On est passé d’une architecture “pipe et filter” vers “blackboard”
• On avait déjà un système continuous delivery

La situation (après) - clients
• Le client a l’option de faire une intégration incrementale
• Dans l’ordre qu’il veut
• Le client ne doit plus nous donner de planning, ils annoncent
quand un flux est prêt
• On customise, test et met en production immédiatement
• Le client reçoit de la valeur avec chaque flux
• => La plateforme devient plus facile à vendre

C’est quoi l’architecture?
“L’architecture c’est les décisions qui sont difficiles à changer et
qu’il faut prendre au début du projet”
Pour de telles décisions
• Ou bien on rend la décision facile à changer
• Ou bien on retarde le point de décision
• Et je suis prêt à payer pour des options qui ont de la valeur
“Oui mais... Il y a des choses qu’on ne peut pas changer”

Hola Hop, Barbatruc
“Et si on changait de plateforme et langage?
Sans arreter le système, bien sur!”
“Impossible!”
Vendeurs Fabricants
EDI
Gestion

Changer de plateforme et de langage
• D’abord des prototypes pour apprendre
• Puis on aborde la partie avec le moins de risque client
• On garde et maintient l’ancien composant pendant la transition
• On peut toujours revenir un (petit) pas en arrière
• Deployment continu et développement incrémental réduisent la
complexité et le risque

7. Quelle est la valeur ajoutée pour
le client de votre architecture et
votre processus?
27 au 29 mars 2013

Techniques utiles (1)
• Cost of Delay:
• Quel est l’effet d’une livraison retardée ou avancée?
• Creative Process:
• Générer des options, puis selectionner les options
• Options:
• Cout, prix, valeur, date d’expiration
• Optimal Decision Process:
• Moment de décision = deadline – temps d’implementation

Techniques utiles (2)
• Variation Separation:
• Séparez les éléments qui varient à des vitesses différentes
• Set-based design:
• Faire la même chose de 3 façons peut être moins cher q’une
• Sunk Cost Fallacy:
• Oubliez combien vous avez déjà investi
• Créez des options pour vos clients

Décisions architecturales
“Le principe du bon moment”
Décisions faciles à changer: décidez tôt
Décisions difficiles à changer: décidez tard
“Le principe de l’effort minimal”
Ne faites pas le travail de demain aujourd’hui
Ne faites rien aujourd’hui qui entrave le travail de demain
Une bonne architecture crée des options pour votre équipe,
votre organisation et vos clients
Les systèmes patrimoniaux ont de moins en moins options
27 au 29 mars 2013

“Dans chaque mauvaise
décision, il se cache une
bonne décision”
Donald Reinertsen
27 au 29 mars 2013

MERCI !
Si vous voulez en savoir plus...
27 au 29 mars 2013

27 au 29 mars 2013

27 au 29 mars 2013