Mes théorèmes de la gestion de projet

source: https://dilbert.com/strip/2011-05-16

Avec l’âge on finit par tirer quelques enseignements de la vie. La pensée gagne en précision formelle ce qu’elle perd peut-être en agilité. Traduisez: on devient un vieux croûton radoteur.

Alors voilà j’avais envie de vous livrer mes « Théorèmes de la gestion de projet ». S’ils ont été établis de façon empirique, je peux dire qu’au bout de 20 ans de consulting je les ai toujours vu se vérifier.

Théorème n° 1 du projet réussi

Un projet réussira si et seulement si les 2 conditions suivantes sont remplies:

  1. une forte adhésion des utilisateurs finaux et leur participation active dans toutes les phases du projet. Cette adhésion est généralement obtenue par la présence d’un sponsor légitime, actif et impartial
  2. une vision claire établie avant le début du développement de ce à quoi ressemblera l’architecture fonctionnelle de la solution avec ses objets métiers et les processus métier couverts. Cette vision doit en principe être détenue par un dépositaire unique capable de la communiquer au sponsor, aux utilisateurs et évidemment à l’équipe projet

En l’absence de l’un ou l’autre des ces éléments – et a fortiori – des deux, prenez vos jambes à votre cou: le projet est sûr de se planter ou de prendre 2 fois plus de temps que prévu.

le premier point qui concerne l’adhésion ou comme disent les anglais le « buy in  » des utilisateurs est souvent cité , c’est assez classique. Le 2ème à mon avis l’est moins et peut-être n’est-ce pas clair pour tous les lecteurs. Ce que je veux dire c’est qu’il faut vraiment que quelqu’un – par exemple vous – ait en tête la vision de « comment ça va tourner ». Si ça tourne sur le papier alors ça tournera en vrai.

en pratique cela signifie aussi que:

– aucune méthode ne remplacera un peu d’intelligence et de créativité. Vous pouvez avoir consciencieusement rempli tous les documents standard et produit tous les beaux dessins prévus par la méthode et ne toujours pas savoir, pour de bon, ce que fera votre fichu système. Et là c’est vous qui l’êtes – fichu.

– aucun software « off the shelf » (ou progiciel) ne vous dispense non plus de cette phase de réflexion et de conceptualisation. J’ai vu principalement deux projets d’implémentation, l’un réussi, l’autre raté. Le projet réussi l’a été parce qu’on s’était donné la peine, lors du cahier des charges, de décrire par le menu les activités couvertes et toutes les fonctions attendues. Le projet raté l’a été parce qu’on s’est dit « bah de toute façon tout est dans la boîte ».

Théorème n°2 de la réconciliation

Donnez à un utilisateur deux sources de données supposées produire des informations similaires, alors les deux conséquences suivantes vont infailliblement se produire:

  1. l’utilisateur va vouloir réconcilier les deux sources – et vraisemblablement vous demander un développement pour ce faire
  2. il va trouver des différences – toujours – et va vous demander des explications

Pensez aux réconciliations front / back, compta / gestion et la plus belle, la fameuse « réconciliation des nostri ». Cette dernière est ma préférée car c’est une triple réconciliation: compta/gestion/dépositaire

C’est à cause de ce théorème qu’on a inventé le STP (Straight Through Processing). On s’est dit s’il n’y a pas de crétin d’utilisateur pour faire des saisies manuelles – erronées par définition – entre deux étapes et qu’on fait tout faire par des programmes informatiques dûment testés, alors on est sûr que tous les systèmes seront en phase et diront la même chose. Et bien non. Voir pour cela le théorème suivant. Et quelque part c’est beau. Ben oui, c’est la nature vivante qui se manifeste, et puis cela vous donne l’occasion d’exercer votre sagacité (tout en étant payé-e)!

Théorème n°3 des interfaces successives

Quand 3 systèmes d’information A, B et C sont liés entre eux par une succession d’interfaces de type A–>B–>C, alors le fait que les interfaces A–>B et B–>C aient été officiellement validées ne garantit absolument pas que A–>C fonctionne.

Alors là je sais que ça heurte le bon sens de tout informaticien biberonné aux mathématiques depuis son plus jeune âge. Sur le papier, si A=B et B=C alors A=C. Dans la vraie vie non. C’est comme ça.

Je l’ai vérifié deux fois et les deux fois me laissent un souvenir cuisant. Deux fois, j’étais A, et j’ai fait confiance à B qui me disait « oui oui ça marche ». Et deux fois C a fini par me dire « mais c’est quoi cette m… » que vous m’envoyez?

Ce qu’il y a c’est que quand B a été testé ce n’était pas avec vos données.

Mon conseil:

– quand vous êtes à un bout (au début ou à la fin), ne faites jamais confiance aux intermédiaires. Essayez le plus tôt possible d’entrer en relation avec le partenaire le plus éloigné de façon à savoir exactement ce qu’il attend ou ce qu’il fournit.

– quand vous êtes au milieu: faites bien votre boulot, nom d’un chien, essayez de comprendre ce qu’on attend de vous!

Avez-vous aussi des théorèmes éprouvés, des vérités ultimes que vous auriez envie de partager? Les commentaires sont là pour ça!