Appels d’offres et tout planifier d’avance (au lieu du développement itératif/Agile)
Je ne sais pas pourquoi il n’y a pas encore eu d’article à ce sujet sur mon blog, mais le voilà. Je me suis récemment trouvé dans le contexte d’une compagnie qui vient de gagner un appel d’offre gouvernementale. Mes observations ne sont pas uniques, c’est un classique mais c’est toujours fascinant….
-
Sur l’équipe de projet il y a plus de pigistes que d’employés de la compagnie…
L’appel d’offre demandait aux soumissionnaires de soumettre des CV ainsi que des CV de relève. Or la compagnie de toute évidence, ne peut pas prévoir une dizaine de personnes pour les 3 prochaines années d’un projet qui risque d’être gagné ou non. On fait quoi? On soumet n’importe quoi comme CV, en fait on soumet les meilleurs CV qu’on a, même si on sait pertinemment que ce n’est pas eux qui feront le projet! Ce n’est pas grave on les changera plus tard dans le projet. Attention, on ne soumet pas les meilleures personnes, mais les meilleurs CV… C’est carrément deux choses distinctes!
-
Sur l’équipe il y a plus d’analystes et d’architectes que de développeurs!
Alors que c’est un projet de développement logiciel, l’appel d’offre ne met pas l’emphase sur les fonctionnalités, mais plutôt sur les documents WORD du guide vert !!!!!!! Une série de documents très bien numérotés comme livrables. Ce qui est important c’est de livrer le P209 et non de livrer une fonctionnalité qui marche! On aura donc besoin de plus d’analystes que de développeurs!, puisque le client c’est ca qui veut vérifier.
-
Pour le projet qui s’étale sur quelques années, la planification est déjà faite au jour près!
Avant même de connaître le projet, avant même de connaitre l’équipe de projet (puisque la majorité sont des pigistes) la planification est déjà montée! Basé sur quoi, sur la fameuse boule de cristal! C’est basé sur le meilleur PIF qu’on peut avoir, sans même avoir consulté les gens-même qui effectuerons le travail!
Mois aussi j’ai le don de prévoir le futur : Le projet sera en retard, le projet dépassera ses coûts prévisionnels et des membres de l’équipe de départ il ne restera pas grand monde. Voilà mon intuition…
-
Il y aura de l’architecture et de l’analyse à ne plus en finir. Une belle architecture sera mise en place, j’en ai aucun doute. Mais ca ne sera pas l’architecture et l’analyse adéquate pour les finalités des besoins du projet.
-
Plutôt que de se concentrer sur les livraisons rapides afin de montrer au client ce qu’il s’attend à avoir.
-
Les membres de l’équipe ne s’engagerons pas personnellement dans le projet, et ne se sentirons aucunement responsable des estimés et de la planification bidon avancée, puisque ce n’est pas eux qui ont avancé ces estimés et cette planification.
-
Plutôt que d’évaluer les activités au fur et à mesure du projet et selon l’équipe en place, et d’établir un échéancier réel fondé sur la RÉELLE vitesse d’avancement de l’équipe de projet.
-
Il y aura des écarts (Attention, ce n’est pas des retards mais bien des écarts) entre la planification et le temps réel de développement, le chargé de projet se dira « on est en retard, mais ce n’est pas grave on va se reprendre pour les activités suivantes, on les fera plus vite » SURPRISE : NON CA N’IRA PAS MIEUX POUR LA SUITE DU PROJET. Le projet va juste accumuler plus du « retard ».
-
Plutôt que se baser sur le temps restant du projet pour évaluer le temps de fin de projet RÉEL.
-
Lorsqu’un premier livrable sera réalisé, ca ne sera pas ce qui est attendu, puisque c’est la première fois que le client voit de quoi et qu’on a du couper dans l’assurance qualité, parce qu’il ne restait pas de temps. Merde, toute la belle architecture et les belles analyses montées ne correspondent plus à ce qu’il faut maintenant faire! Ca a servi à quoi déjà de prendre tout ce temps de penser à ce qu’il faut faire?! Sans la
validation rapide du client, ca a servit à s’éloigner de plus en plus des attentes fonctionnelles du client !
-
Plutôt que de livrer du fonctionnel rapidement et s’assurer de régulièrement converger vers les attentes fonctionnelles du client.
Voilà ce que je propose rapidement…
-
Les appels d’offres devraient imposer des livraisons successives FRÉQUENTES et les fournisseurs devront être jugés sur le LIVRABLE FONCTIONNEL avant les documents WORDS.
-
Le client (le gouvernement par exemple) devrait s’occuper de monter une série AUTOMATISÉE (pas manuelle) de tests d’acceptations (ce n’est pas les outils qui manquent) pour valider chaque livrable du fournisseur de manière cohérente et uniforme à chaque fois. Une simili-intégration continue… (Il faut bien commencer quelque part)
-
Le fournisseur connait bien la série de tests d’acceptation que le client fera, il n’y a donc pas d’excuse, ni de chicanes, ni de flou de DDC (Demandes De Changements)…
-
Ainsi, le client assume ses attentes puisqu’il les a exprimées par le biais de tests FONCTIONNELS AUTOMATISÉS. Et le fournisseur assume la qualité livré puisqu’il sera jugé sur la base de ces mêmes tests fonctionnels.
Ce n’est pas demain la veille…. Je le sais. Mais le réel problème se situe où exactement? Est-ce le client qui demande de tout prévoir d’avance? Ou est-ce le client qui soumet une réponse à cette absurdité?
Le problème dans ce cas est d’abord le client. C’est le client qui demande ses formulaires P209 dûment remplis. C’est le client qui veut une analyse complète et une planification au jour près.
Bien entendu, les fournisseurs qui “bident” sur ces projets ne savent probablement pas dans quoi ils se lancent, ou encore ils se spécialisent dans la réalisation de projets de ce genre (grosses entreprises, avec beaucoup de ressources, qui salivent à l’idée de mettre 10 développeurs pendant 3 ans sur un projet qui a probablement 20% de chances de donner quelque chose d’utilisable, tant que les chèques rentrent…).
Dans la plupart des cas, un client qui demande ce type de projet verra, après l’échec de ce projet, que cette façon de faire ne fonctionne pas. S’ils se font ensuite expliquer les pratiques agiles, il y a des chances qu’ils “comprennent” et qu’ils exigent par la suite des suivis au niveau du fonctionnel, et non des nuages.
TOUTEFOIS, on parle ici du GOUVERNEMENT, et je doute fortement qu’une si grosse structure puisse faire ce virage de 180 degrés et vraiment adopter l’agile à travers tous les ministères et tous les projets. Un jour, peut-être, surement, ça va arriver, mais c’est pas demain la veille…
Le problème est évidemment du côté du client. Peut-on vraiment reprocher à une entreprise dont le but est de faire de l’argent de vouloir décrocher des contrats même si le modèle de gestion du gouvernement ne fonctionne pas?
Je comprends aussi que le gouvernement impose une tonne de livrables documentaires…le but du gouvernement n’est pas de faire des profits, ils n’ont de comptes à rendre qu’au public et non à des actionnaires. Les documents word constituent une police d’assurance comme quoi les employés du gouv ont fait ce qu’ils devaient faire en terme de suivi de projet et que les fonds publics n’ont pas été dépensés pour rien…même si on sait bien qu’un logiciel qui ne fonctionne pas avec de la belle documentation ne vaut rien sur le marché
On voit la même chose pour les gros projets de constructions. Le gouvernement va en appel d’offre pour la construction d’une autoroute sur 6 ans et demande aux soumissionnaires de leur fournir un échéancier et un budget alors qu’ils ne connaissent à peu près rien du projet. Le contrat va au plus bas soumissionnaire et ensuite on se scandalise que le projet dépasse budget ET temps.
Cependant je pense qu’une grosse partie de la solution appartient aux entreprises qui gagnent les appels d’offre en ce sens qu’il y a un gros travail d’influence à faire pour qu’un jour les choses changent.
Le problème réside dans la gestion de risques, vu que les décideurs ne veulent pas admettre que notre industrie possède un taux de réussite global de 50%. Si la gestion de risque était discuter au préalable, les problèmes en serait diminuer de beaucoup et la relation entre le fournisseur et le client n’irait pas de lune de miel à mise en demeure… Mais cela n’est pas attrayant de lire l’offre d’un fournisseur qui parle de gestion de risque a la base. Je crois que le processus d’appel d’offre s’apparente plus à une vente de hamburgers chez McDonald’s, alors qu’il ne diront surtout pas que ça peut faire grossir. Je crois que les technologies de l’information sont un aspect tellement important dans la vie nouvelle des entreprises du 21e siècle que ces tactiques de vente de restauration rapide doivent changer et se pencher plus sur les modèles de l’industrie de la construction. C’est par ce chemin que l’industrie prendra en maturité. Aussi, les mandats doivent être absolument éclatés, ils sont définivement trop gros. La séparation des travaux en sous mandats indépendants amènera un niveau de complication amoindrit et fera un succès de chaque sous-mandats. Lorsque qu’une compagnie fera état des risques et de la gestion de ceux-ci tout au long du mandat, elle réalisera exactement les implications et la gestion du projet proprement dit sera alignée en conséquense. L’autre aspect du problème sont la non connaissance des technologies de l’information de la part des décideurs mais je considère déjà le problème régler lorsque la génération Nintendo prendra le contrôle de nos entreprises. Quand ils regarderont autre chose que la colonne profit, beaucoup de choses seront réglés. Pour ce qui est du gouvernment, la règle du plus bas soumissonaire est la principal cause d’echec.
Définition de “Risk Management”: http://en.wikipedia.org/wiki/Risk_management