Vers une autre structure projet

SOUS-SYSTEMES
Couper un système en deux crée deux sous-systèmes et une interface, une surface de frontière commune aux deux systèmes.
Cette interface va engendrer du gaspillage, au sens lean du terme.

MODE PROJET MULTI-ORGANISATION
Exemple caricatural mais réaliste : une entreprise confie la rédaction des spécifications à un premier sous-traitant, la réalisation des développements à un second, la recette des développements à un troisième. Sois trois sous-systèmes. Je vous laisse dénombrer le nombre d’interfaces.
Ici, le découpage créer des sous-système appartenant à des organisations différentes (au sein ou non du même groupe, il ne s’agit pas nécessairement de SSII), ce qui « durcit » les interfaces : les organisations parentes ayant des objectifs différents, elles “blindent” leurs points de contact avec les autres.

CONTRATS D’INTERFACE
Pour chaque interface, ce découpage engendre un besoin de formalisation de “contrats”. Cahier des charges, spécifications fonctionnelles détaillées, cahier de tests détaillés, etc… Le summum étant le contrat au forfait.
Ces contrats engendrent la nécessité de formaliser à l’excès un échange d’information qui pourrait être plus fluide, rester à un niveau synthétique, être complété de manière “ad hoc” dans un wiki, le meilleur passage de connaissance restant le biseau, en synchrone, formation des nouveaux par les anciens.

L’ESPRIT DU MODE PROJET
Le découpage crée la nécessité de pouvoir stocker une information pour la restaurer plus tard dans d’autres contextes (chez un sous-traitant qui n’a pas participé à l’effort initial d’élaboration de l’information, au tribunal pour justifier de ce qui avait été convenu, …) créer une formalisme qui serait –sans cette nécessité- inutile. La source de ce besoin en formalisme est la nature asynchrone de l’utilisation de l’information par les différents sous-systèmes.
Du coup, l’idéal est d’appliquer le principe du mode projet (que l’on soit en interne ou avec des ssii partenaires) selon son esprit : Tous à bord, tous dans le même bateau. En régie. Dans les mêmes locaux.

SYNCHRONISATION
Ce découpage en sous-entités engendre aussi un besoin de synchronisation dans le temps.
Du coup chacun va publier son planning, ses jalons. Et déployer une énergie phénoménale à se synchroniser avec le planning des autres,
prendre des marges en annonçant ses dates et freiner des quatre fers à l’idée du moindre changement.
Changer une ampoule passe de 10 minutes à 3 semaines.

DISCONTINUITE DU PROJET
Autre exemple, caricatural mais réaliste lui aussi.
On n’a pas le budget qu’il me faut pour faire mon projet.
On en réalise un premier tiers cette année.
L’année d’après on en réalise un nouveau tiers.
L’année encore après on en réalise un troisième tiers.
Evidemment, les tiers ne durent pas toutes l’année, donc il y a des trous, pendant lesquels on libère les membres de l’équipe.
Quand on reprend le tiers suivant, on prend de nouveaux intervenants.
Et après le dernier tiers, on passe en maintenance, par une équipe encore différente.
On se retrouve avec un besoin de formalisation décuplé.
Comment faire passer à l’équipe suivante toute la compréhension métier et technique ?
On rédige tout, mais comme on n’a pas le temps de le faire au fur et à mesure, on le fait au dernier moment, en remontant péniblement le temps, avec une piètre qualité.

EXEMPLES D’ALTERNATIVES

• Prendre moins de monde (sacrifier les délais) pour garder les personnes en continu. Dans mon exemple, faire des tiers mieux étalés dans le temps, de façon à conserver l’équipe. Le “sacrifice” est donc d’étaler aussi les livraisons, donc d’avoir la release moins vite.
• Embarquer un membre de l’équipe support dans le projet.
• Embarquer un membre de l’équipe projet dans le support.

PRAGMATISME DANS LA STRUCTURE DE L’EQUIPE PROJET
La nécessité de gérer la complexité d’un gros projet est indéniable. Le découpage en équipes est inévitable.
Ce découpage est fait pour des raisons commerciales (client / fournisseur), politiques, historiques, … que je peux comprendre mais qui aboutissent à un résultat qui n’est pas toujours optimum.
L’organisation d’un projet, calque parfois à tort sur la base de l’organigramme de l’entreprise (découpage fonctionnel, business d’un côté, IT de l’autre)
et pas sur un découpage ad hoc (feature teams).
Ce qui devrait compter, à tous les niveaux, y compris pour l’organisation, c’est la seule efficacité du fonctionnement du projet !

DYNAMIQUE DE LA STRUCTURE DU PROJET
Et puis il y a l’aspect dynamique : J’ai visité il y a très longtemps un projet où les intervenants n’avaient pas de bureau fixe, où ils se regroupaient selon le sujet du sprint, afin d’optimiser les échanges. Cela m’avait impressionné.
A un niveau plus avancé : plutôt que de décréter ce qui sera efficace, faire intervenir les uns et les autres dans l’élaboration, sans y passer trop de temps, faire un essai, éprouver, faire un retour, changer ce qui a été élaboré, … Mais cela suppose que l’on admette que l’on ne sait pas et que l’on refuse de plaquer des organisation importées d’autres contextes, même si elles sont popularisées.