Discussion :

[fluctus]

J'avoue que le choix de la voiture était un peu bancal, à la rigueur ça s'appliquerait mieux sur des camionnettes d'artisans à aménagement spécifique, ou des remorques de poids lourds spécifiques.

Dans le bâtiment, des lotissements avec 120 pavillons identiques, c'est quand même pas le cas le plus fréquent, j'ai vécu dans plusieurs régions de France, je n'ai vu que des lotissements avec des maisons individuelles dont aucune ne se ressemblait, et je n'ai aucune personne dans mon entourage qui n'ait fait construire une maison identique à une déjà existante. D'ailleurs mes principales citations concernaient des immeubles, qui à part les tours jumelles du feu WTC ou celles de Kuala Lumpur, sont toujours des constructions uniques.

D'ailleurs, au 120ème pavillon de ton lotissement tu ne seras jamais à l'abri d'être en bordure du lotissement sur une galerie d'une ex mine de charbon qui fait tout s'affaisser et mette le projet en retard, en engendrant des surcoûts ...

On est d'accord.
Comparer les projets informatiques aux projets immobiliers est pertinent dans le sens où dans ces deux types de projets, on a environ la moitié des projets qui échouent.

Il n'y a que les logiciels en boîte qui sont vendus à prix fixes (et l'acheteur ne connaît pas le délai d'installation, paramétrage etc. qui sera effectivement nécessaire avant que le logiciel soit opérationnel sur sa machine). Encore cela résulte-t-il d'une stratégie de commercialisation où l'éditeur décide de mutualiser les coûts de développements déjà réalisés, entre le nombre de ventes qu'il estime pouvoir générer.

Dire que

"Le client a besoin de savoir quand son produit sera livré, et ce qu'il va lui coûter"

c'est croire naïvement que les désirs exprimés par le client correspondent à ses besoins réels. C'est privilégier une stratégie commerciale basée sur la demande, et non pas sur l'offre (avec la course à la baisse de prix qui va avec pour "remporter" des marchés). C'est nier notre rôle de conseil. C'est être incapable de créer de la valeur !
Ce qui est présenté comme du pragmatisme est en fait une utopie, entretenue par manque de courage dans la relation avec nos clients.

Quand j'achète une maison, je ne fais pas que rechercher le meilleur rapport qualité/prix.
Une fois informé du taux d'échec des projets de construction, je peux choisir de persister dans ma stratégie initiale, ou au contraire de diminuer les risques. Dans ce second cas, une fois informé des causes d'échecs/retard/dépassement des projets, je peux décider de réaliser mon projet dans la vraie vie, et non pas dans un monde magique où délais et coûts de revient seraient parfaitement maitrisables.

Mon approche devient alors :
1- compte tenu de mes capacités de remboursement, combien la banque peut-elle me prêter ? (identique au scénario habituel basé sur le rapport qualité/prix)
2- avec ce budget, quelle est le résultat minimum que je suis certain d'obtenir (worst case scenario) ?
3- le retour sur investissement de ce résultat minimum est-il acceptable ? (L'acheteur peut aussi choisir un scénario plus optimiste, en sachant qu'il augmente le risque de ne pas le voir se réaliser)
4- il peut ensuite prioriser ses attentes au-delà de ce scénario minimum : si les choses se déroulent mieux que prévu, dans quel ordre réaliser les options pour consommer tout mon budget ?

On remarque que c'est à peu près la même chose, avec des conséquences différentes, qui se passe dans le scénario habituel que nous connaissons :
1- compte tenu de mes capacités de remboursement, combien la banque peut-elle me prêter ?
2- avec ce budget, quelle est le résultat optimal que je peux obtenir (best case scenario) ?
3- le retour sur investissement de ce résultat optimal est-il acceptable ?
4- une fois le budget de sa banque consommé, l'acheteur doit payer un dépassement de budget pour faire réaliser ce qui n'a pas pu le budget de départ. Dans le meilleur des cas, 0 euros. La moitié du temps, ce budget dépasse les capacités de financement du client (cf point 1 : le budget a été optimisé par-rapport aux capacités financières de l'emprunteur), ce qui conduit à l'échec du projet : http://www.lamy-expertise.fr/experti...on-borloo.html

Nous avons un devoir de conseil envers nos clients, car c'est nous qui sommes des professionnels de la construction de logiciel.

La manière de faire habituelle cherchent à transférer les risques aléatoires du projet, de la MOA vers la MOE. Au final, la MOA voit les risques s'aggraver d'autant plus qu'elle a transféré la gestion de ces risques à la MOE. Celle-ci ne dispose pas d'indicateurs pertinents ni d'une marge de manoeuvre suffisante pour adapter la marche du projet. On se retrouve alors dans un schéma "tout ou rien".
Résultat : la moitié du temps le projet est considéré en échec, le retour sur investissement n'est pas atteint : http://leblogdumanagementdeprojet.co...adoxe-de-cobb/

Le marché valorise habituellement les risques par une rémunération financière. L'acteur qui se charge des risques (compagnie d'assurance...) mutualise les risques et se rémunère pour la gestion statistique de ces risques. Pour pouvoir assurer ce type de service, une SSII soit avoir une taille suffisamment importante, et imposer le niveau de marge supplémentaire correspondant à cette gestion de risques.
Elle peut alors baser sa stratégie commerciale sur le fait de s'engager au forfait et avec obligation de résultat : les pertes sur certains contrats seront couvertes par la marge commerciale.

Dans ce cas, la SSII gagne à tous les coups, même si elle ne livre pas ou livre en retard. Mais pas le client.
Car son besoin de productivité, exprimé sous la forme d'un désir de logiciel, n'est pas satisfait.
Le marché n'a pas de pitié pour ceux qui ne s'adaptent pas à temps.

[gombo]

Ces lois sont considérable, elles requièrent des lignes d'ajustements pour être Proactif c'est un Manager de Choix.