LES SYMPTOMES LES PLUS VISIBLES DES PROJETS PATHOLOGIQUES (1/2)

PREAMBULE

Si des mots tels que chef de projet, utilisateurs, maîtrise d'ouvrage, maîtrise d'oeuvre, ou recettage, ...ne vous sont pas familiers, commencez de préférence par le chapitre Quelques termes de base illustrés par un exemple (retour assuré). Ce petit passage lexical vous permettra d'ailleurs de constater que nous avons tous fait un jour de la gestion de projet sans le savoir (comme monsieur Jourdain pratiquait la prose à son insu) et que les règles de réussite en la matière sont assez semblables d'un projet à l'autre, quelle qu'en soit la typologie.

Dans le cas où vous en sauriez assez, vous pouvez passer à l'analyse directement.

LES SYMPTOMES LES PLUS VISIBLES DES PROJETS PATHOLOGIQUES

• Introduction
• Un désintérêt marqué des utilisateurs pour le projet
• Un enchaînement de tâches et de décisions désordonné pour un résultat médiocre
• Des dépassements de coûts et de délais "en cinémascope
• Le silence des organes de contrôle
• Le partage des responsabilités

Les différentes phases d'un projet selon J-L Gassé :
Indifférence
Ignorance
Enthousiasme.
Désenchantement.
Panique.
Recherche du Coupable.
Punition de l'Innocent.
Récompense du Non-impliqué

INTRODUCTION

Analyser le déroulement des projets pathologiques n'est pas chose facile : non pas que les symptômes soient rares : ils sont au contraire d'une richesse infinie ; mais le désordre dans lequel ils se mêlent et s'entremêlent, l'incohérence et l'absurdité de leurs manifestations ne permettent pas d'en faire facilement un compte rendu rationnel et ordonné. Nous serons donc amenés très souvent au cours de cette analyse à examiner en même temps les symptômes, les causes de ces symptômes et leurs conséquences les plus directes dans l'organisation.

Si le descriptif mis en exergue de cette page est un bon résumé du déroulement involutif d'un projet pathologique, il exige cependant quelques explications pour ceux qui n'auraient pas la chance d'être des initiés en la matière.

Tout individu plongé brutalement dans un environnement pathologique a en principe deux solutions :

• soit il s'adapte sans trop se poser de questions et adopte les comportements (pathologiques) exigés par son environnement, en les considérant comme normaux ;
• soit, un peu moins souple, il éprouvera un certain malaise devant la succession étrange de phénomènes désordonnés et incohérents propres à ces processus. C'est généralement dans ce deuxième cas, que les symptômes listés ici lui apparaîtront comme anormaux (comme quoi la notion de normalité ne dépend que d'une plus ou moins grande capacité d'adaptation à son environnement...).

Ces symptômes, on peut sans trop se tromper, les regrouper sous les constantes suivantes :

UN DESINTERET MARQUE DES UTILISATEURS POUR LE PROJET

Dans le chapitre Quelques termes de base illustrés par un exemple, nous avons souligné à partir d'un exemple simplifié l'importance de la participation des utilisateurs finaux dans les projets.  

Lorsqu'un projet va mal, commencez donc par chercher ces utilisateurs ! Vous constaterez sans difficultés que leur position apparente sur le sujet peut se résumer à la déclaration suivante : J'ai bien d'autres choses beaucoup plus importantes à faire, je n'y vois aucun intérêt et je n'ai pas de temps à y consacrer!

Derrière cette position apparente se cachent bien d'autres considérations qui - sans être justifiables - s'expliquent comme suit :

Le chef de projet pour des raisons que nous analyserons plus loin considère que l'intervention des utilisateurs est effectivement une perte de temps et il n'est pas prêt à entamer un processus de concertation qui risque d'être beaucoup plus long que ce qu'il a prévu au départ ; on peut donc aboutir dans un tel cas à une entente ou à une complicité de fait entre un responsable de projet pressé et des utilisateurs indifférents. Il peut même arriver, dans les cas pathologiques aigus, que les chefs de projet soient des théoriciens convaincus de la non participation des utilisateurs, qu'ils considèrent comme trop "bêtes" ou trop "incompétents" pour pouvoir participer à des projets "trop innovants pour eux".

Ces utilisateurs de leur côté sont très souvent occupés à des tâches opérationnelles récurrentes qui ne leur permettent pas facilement de fonctionner en “équipe projet” et rien dans leur environnement (hiérarchique en particulier) ne les y encourage. L'organisation, dans ces cas là, ne sait tout simplement pas accommoder le travail en "mode projet" et la façon dont les employés sont évalués est en général un très bon indicateur de cette incapacité : lorsque la participation active à un projet ne rapporte aucune gratification à un employé et que symétriquement sa non participation ne lui coûte rien, quel intérêt peut-il bien avoir à s'en occuper ?

Les utilisateurs peuvent aussi avoir déjà fait l'expérience de projets bâclés et considèrent avoir “suffisamment de problèmes comme ça avec les produits qu'on leur a déjà livrés pour ne pas en rajouter avec de nouveaux projets”. Cette attitude se mêle très souvent de considérations assez vagues sur le fait qu'un système qui marche est déjà mis en place ailleurs et qu'au lieu de réfléchir pendant des mois, il suffirait de le leur installer sans perdre de temps et sans "en faire des tartines" (attitude dite du « y'a qu'à faut qu'on »).

Enfin, si ces utilisateurs ont déjà vécu des projets pathologiques jusqu'à la phase de “partage des responsabilités” durant laquelle le responsable “initial !” d'un projet en difficulté se met activement à la recherche d'un responsable “final !”, ils savent d'instinct que la seule attitude sûre à adopter et de ne surtout pas tremper dans une nouvelle aventure....

La conséquence de tout ce qui précède, est que la phase de définition des besoins, qui est une phase essentielle dans les projets, est très souvent confiée à des personnes déléguées qui ne sont pas réellement compétentes et ne connaissent les besoins des utilisateurs que de façon superficielle ou sur la base d'informations le plus souvent verbales (interviews). Ces personnes portent des noms divers allant de celui d'organisateurs à celui d'assistants à la maîtrise d'ouvrage. Et dans les processus pathologiques, leur rôle consiste pour l'essentiel à décharger les utilisateurs de toute responsabilité dans les projets qui les concernent. L'expression des besoins sera en conséquence incomplète et bâclée.

Dans les projets pathologiques, tout l'art du management consiste à confier à Monsieur X une tâche que Madame Y saurait mieux faire et vice versa.

UN ENCHAINEMENT DE TACHES ET DE DECISIONS DESORDONNE POUR UN RESULTAT MEDIOCRE

Un projet classique respecte en principe les grandes phases suivantes :

• Expression détaillée des besoins et cahier des charges (objectifs fonctionnels, contraintes de coût et de délais) ;
• Proposition technique détaillée (spécifications) par le fournisseur (interne ou externe) et établissement du prix (ou du coût) ;
• Accord du client (sur les spécifications et sur le coût) et décision de lancement ;
• Réalisation (développement du produit) ;
• Tests et livraison définitive ;
• Déploiement.

Et bien, croyez le ou non, dans les projets pathologiques, on commence souvent (et presque toujours) par établir les budgets et les plannings avant même de savoir ce qu'il y a à faire ! Ces budgets et ces plannings on ne les établit d'ailleurs pas n'importe comment ! Ils sont au contraire définis d'une façon très précise : c'est à dire qu'ils sont absolument, irrémédiablement et autoconstitutionnellement....IMPERATIFS !

Cette attitude, dont nous analyserons les ressorts plus loin, conduit en pratique à une grande précipitation dans le déroulement du projet et à un enchaînement de tâches désordonné: un observateur objectif constatera alors que l'équipe projet (ou ce qui en porte le nom) se lance dans le plus grand désordre sur des tâches de toutes sortes souvent déconnectées entre elles, menées dans l'urgence et en court-circuitant tout spécialement la phase la plus importante qui consiste à définir ce que l'on veut faire de façon détaillée (l'expression des besoins). C'est que le mot d'ordre qui guide tout le plan de bataille, se résume en deux mots:“FAIRE VITE !”

Notre observateur s'apercevra ainsi que la définition des besoins et les spécifications sont faites en réalité après la livraison ou même après le “déploiement” du produit : c'est à dire au moment où les utilisateurs finaux réceptionnent le produit “livré”, et découvrent (oh stupeur !) qu'il ne correspond pas à leurs besoins....

On défait alors d'urgence ce qui n'aurait jamais dû être fait, on bricole en vitesse ce qui n'a jamais été demandé et l'on révise et recette les nouveaux développements à un rythme effréné. Le taux de modification en arrive finalement à dépasser le taux d'avancement du projet, lorsque toutefois on n'a pas encore renoncé à suivre un tel indicateur.

C'est d'ailleurs au stade du “déploiement” du résultat (hum...) que la situation devient la plus cocasse, car ces mêmes utilisateurs qui n'avaient pas une minute à consacrer au projet lors de son lancement se transforment alors en stakhanovistes de la correction des bugs, de la réécriture des besoins et de la conjugaison des temps. On les verra ainsi faire connaissance avec toutes les femmes de ménage de la société pour les avoir rencontrées soit très tôt le matin soit très tard le soir, réutiliser leurs vieux bouliers pour faire des opérations que leur “nouveau” système est incapable de réaliser, souffrir d'ulcères gastriques, recommencer à fumer, hurler sur leurs enfants et cent fois écrire et réécrire l'expression des besoins...voire même les spécifications (pendant qu'on y est...), pareils à des Pénélopes involontaires et méritantes de leur société.

Ce qui porte le nom d'équipe projet prend alors des allures de troupe en déroute après la campagne de Russie et le ras le bol devient probablement le seul élément fédérateur entre les personnes.

LOI DE GOLUB N° 3 : L'effort nécessaire à redresser le cap croît géométriquement avec le temps

Ce travail considérable que les utilisateurs se trouvent contraints de fournir à un stade avancé du projet, lorsque tout changement devient plus difficile à réaliser et force à de multiples bricolages, ne sera cependant pas quantifié et passera inaperçu dans le suivi du projet ; ce qui d'ailleurs, ne fera que conforter les responsables initiaux de cette situation. Pour une raison simple : c'est qu'à partir du moment où il est établi que les utilisateurs finaux ne doivent pas perdre de temps sur les projets, le temps qu'ils consacrent en abondance ensuite à défaire et refaire ce qu'ils auraient simplement dû faire au début, ne doit surtout pas figurer dans les dépenses du projet...pour des raisons de cohérence, bien entendu ...! 

Dans le cas où vous auriez du mal à suivre, voici donc comment notre observateur vivra les différentes phases du projet :

Mémento :

• Définition des délais et des plannings: IMPERATIFS !
• Choix et paiement de la solution
• Déploiement
• Tests (phase du “y'a un truc qui va pas...”)
• Définition des besoins (phase du “c'est pas comme ça qu'y fallait faire...”)
• Re-Développements
• Re-Tests
• Re-élaboration des objectifs et des besoins
• Re-Développements
• Re-Tests
• Re-élaboration du périmètre, des spécifications, des objectifs et des besoins
• Re-Développements
• Re-Tests
• Re-élaboration du phasage, du périmètre, des spécifications, des objectifs et des besoins
• Re-Développements
• Re-tests.........
• Etc, etc.....
• 

C'est ainsi qu'on pourra voir (cas authentique) des systèmes informatiques achetés et payés pour lesquels on s'apercevra soudain au stade du déploiement qu'on a oublié de se demander au départ qui diable pourraient bien en être ...les utilisateurs ! C'est bête non ?

DES DEPASSEMENTS DE COUTS ET DE DELAIS "EN CINEMASCOPE"

Explosion est le mot le plus approprié à ce troisième symptôme des projets pathologiques, à moins qu'orgie ne soit plus proche de la réalité : explosion de budgets, orgie de délais, dépassements de toutes sortes se mêlent et s'entremêlent. Le projet initial tourne au bouillon ; plannings et budgets sont revus, révisés et redéfinis pour ainsi dire tous les jours.

Les retards s'accumulent en même temps que les versions successives des plannings se multiplient ; les révisions budgétaires s'entassent et cette masse de papier fait le plus grand bonheur...des femmes de ménages, décidément très amusées du rythme auquel se remplissent les poubelles.

LOI DE GOLUB N° 8 : Un projet mal planifié prendra trois fois plus de temps. Un projet bien planifié prendra seulement deux fois plus de temps.

NDLR : Tout en étant très claire, cette loi de GOLUB écrite aux US dans les années 70 mérite sans doute d'être actualisée de ce côté-ci de l'Atlantique, où nous avons énormément progressé depuis : on y connaît en effet des projets qui ont duré et ont coûté allègrement dix fois plus que ce qui était prévu au départ. Sans doute s'agit-il là simplement d'une question de persévérance. Dans tous les cas, ce petit “a parte” devrait faire un sort au mythe selon lequel les Américains seraient beaucoup plus riches que les Européens : c'est faux, on le voit bien ! Quand on peut se permettre sans conséquence sérieuse de dépenser 10 fois plus que ce qu'on avait prévu, c'est qu'on est forcément très riche...

Explosion donc, ...mais peu bruyante, somme toute très silencieuse et pour ainsi dire confidentielle...parce qu'une autre caractéristique des projets pathologiques tient à l'étrange discrétion qui couvre les dérapages de budgets et de délais, dans ces circonstances...

Page précédente    Haut de page    Page suivante