@SURTITRE:GESTION DU DEVELOPPEMENT

@TITRE:Que faire des projets "à problèmes" ?

@CHAPO:La dérive des projets suit quelques scénarios types... et conduit à des décisions difficiles: recadrer, geler ou stopper. L'expérience et les décisions de quelques grands utilisateurs.

@TEXTE:Des projets à problèmes, beaucoup d'entreprises en ont et en auront. Il ne faut pas se mettre la tête dans le sable. Les méthodes de gestion de projet ne sont pas toujours faciles à mettre en oeuvre, et surtout elles ne sont pas infaillibles. Il arrive aussi qu'aucune règle de gestion de projet ou de bon sens ne soit appliquée. Le tout est de détecter ces projets à temps et de les gérer. Avec trois solutions: les recadrer, les "geler" et les arrêter. Dans tous les cas, leur "dissection" s'avère instructive, révélant même parfois des difficultés qui dépassent largement le cadre initial du projet: organisation, communication, stratégie, management, technique.

Mais comment en vient-on là? A quelques variantes près, le problème émerge au terme de l'un des scénarios suivants: syndrome de la grenouille, spirale du perfectionnisme, problèmes de couple, passion pour la danseuse. Quelques projets les cumulent, d'ailleurs.

@INTER:Le syndrome de la grenouille

@TEXTE:"Pour résoudre un besoin réel, on peut faire beaucoup de choses inutiles", note Jean Demougin, délégué au système d'information à France Télécom (direction des Programmes et des finances), qui a pour mission de surveiller les projets. Ce syndrome "de la grenouille" voit un projet utile grossier démesurément au fil des mois. Parce que, consciemment ou non, le ou les responsables en profitent pour étendre leur territoire personnel. Autrefois répandu dans les très grandes entreprises, ce syndrome fait l'objet d'une surveillance attentive. Mais il reste vivace. Aujourd'hui, les utilisateurs poussent plus souvent à la roue que les informaticiens... contraints de jouer un rôle de frein qui ne leur convient guère: "Il est difficile pour une direction informatique de se battre pour ne pas faire un projet", avoue un directeur informatique.

Autre expression du syndrome: dès qu'un projet est mis en exergue, tout le monde veut y raccrocher son wagon. Un projet phare attire les désirs non assouvis de l'entreprise: fonctionnalités, technologies, applications, pouvoir, reconnaissance... ils trouvent là un point de cristallisation. Le projet devient alors tellement complexe que plus personne ne le domine vraiment.

@INTER:De la trop belle ouvrage

@TEXTE:La siprale du perfectionnisme naît, elle, de la volonté de bien faire. On vise à satisfaire pleinement les utilisateurs, faire un beau projet. "Le désir de la belle ouvrage s'observe en particulier chez les ingénieurs", note Jean Demoulin, qui constate une tendance à développer des machines à tout faire. Ce fut le cas d'un projet de système d'information... sur le système d'information de France Télécom, dont le budget risquait d'atteindre plusieurs millions de francs. Alors qu'une application sous Excel pouvait faire l'affaire.

"Les utilisateurs acceptent des solutions partielles qu'ils ont bricolé sur le micro. Mais, quand ils ont affaire à l'informatique, ils exigent la perfection", explique Nicole Hernandez, ingénieur de recherche au service informatique de gestion du ministère de l'Education nationale. Légitime et louable au départ, le désir de traiter 100% du problème peut entraîner loin. Les quelques derniers pourcents coûtent le plus cher. En temps et en argent. N'oublions pas la tentation technicienne, qui fait céder aux sirènes des technologies dernier cri, qu'elles se justifient ou non.

@INTER:Problèmes de couple

@TEXTE:Aujourd'hui dominent les "problèmes de couple". De belles étiquettes formalisent les relations: maître d'ouvrage, maître d'oeuvre... mais la communication entre informaticiens utilisateurs ne coule pas de source pour autant. Malentendus, tensions, manques de coordination, voire guerres de tranchées, continuent à miner plus d'un projet. Ils conduisent à des erreurs d'appréciation des besoins, à des rectifications fonctionnelles et techniques incessantes, à des sommes de détails jamais réglés qui font dériver complètement le développement.

@INTER:Des symptômes visibles

@TEXTE:Détecter les problèmes à temps relève des managers ou d'une tierce personne chargée de mission auprès de la direction générale, ou du responsable de la qualité. Un rôle souvent difficile pour quelqu'un d'extérieur au projet. Les délais offrent le premier critère à surveiller. Au premier écart, il faut regarder de plus près, mais sans tirer de conclusions hâtives. Un retard, chose courante, ne suffit pas à classer un projet comme "problématique". Sauf s'il dépasse les bornes, bien sûr. Tout l'art consiste à bien évaluer la situation... et à prévoir dès le début du projet des critères concrets, qualitatifs ou quantitatifs, permettant d'apprécier la trajectoire par rapport aux objectifs.

"Un projet qui marche est transparent", constate Jean Demougin. Quand les informations ne remontent pas facilement, quand les explications ne se laissent pas comprendre aisément, c'est mauvais signe". Autre indicateur, le "radio-moquette". Si l'on entend parler d'utilisateurs insatisfaits, ou de climat mauvais, il faut aller voir. Bref, rester à l'écoute de tous les petits signes et brancher son sixième sens. En cas de doute, faire une enquête personnelle et éplucher les documents (cahier des charges, budgets, rapports d'étape). Les convictions se précisent par le déroulement même de l'enquête: "Personne dans le projet ne disait la même chose", se souvient le délégué au système d'information de France Télécom à propos d'un projet récupéré de justesse.

@INTER:Recadrer, geler ou stopper

@TEXTE:Une fois le suspect détecté, il faut agir. Parfois on peut rattraper le projet par les cheveux. Soit en simplifiant le cahier des charges, soit en nommant un vrai responsable. On peut aussi reprendre le projet le confier à une équipe de pompiers. On n'oubliera pas de prévoir alors des éléments de mesure tangibles pour suivre la marche vers les objectifs.

Dans d'autres cas, on peut geler le projet, l'arrêter sur un état stable et renoncer aux étapes ultérieures. C'est ce que fait France Télécom, avec son projet de facturation Frégate, dont la première phase, déjà développée est déployée, mais qui n'ira pas plus loin. C'est la seule issue quand on ne contrôle pas le projet et qu'il a une importance stratégique. Reste alors, pour la suite, à prévoir d'autres solutions.

L'arrêt complet s'impose parfois comme le moindre mal. Quand, par exemple, la stratégie de l'entreprise ou les besoins des utilisateurs ont changé, quand les délais ou les coûts d'un projet important mais non vital échappent à tout contrôle, ou enfin quand les utilisateurs le rejettent sans appel. Comme l'explique Jean Demougin, les ressources sont limitées et continuer un projet mal parti peut empêcher d'en faire un autre, beaucoup plus stratégique. L'arrêt d'un développement peut même prendre une valeur pédagogique efficace: il signale une volonté de changement, il dégage la voie vers de nouveaux progrès. Mais les intéressés en souffrent toujours.

Trancher comporte le passage par pertes et profits de sommes parfois importantes, l'abandon du déploiement de fonctionnalités utiles. Un moment difficile, d'autant qu'il s'accompagne de problèmes humains qu'il faudra gérer: démotivation, reclassements, départs, rancunes... on trouvera toujours des utilisateurs ou des informaticiens pour se battre jusqu'au bout. Une telle décision de management, au sens fort du terme, comporte sa part de risque. "Quand un comité de pilotage est capable d'arrêter un projet, cela prouve que les rouages de l'organisation fonctionnent bien", conclut Pierre-Yves Duwoye, chef du service informatique de gestion au ministère de l'Education nationale. @SIGNATURE:SYLVIE HERIARD-DUBREUIL

@ENCADRE TITRE:LA SPIRALE DU PERFECTIONNISME

@TEXTE:Pour une fois, ils avaient eu le temps de tout faire dans les règles de l'art! Les responsables du projet GME (Gestion des moyens des établissements) au service informatique de gestion du ministère de l'Education nationale, ne cachent pas leur surprise. Après deux ans d'études et de développements, respectant tous les canons de la gestion de projet, le projet a été gelé.

Pierre-Yves Duwoye voit le côté positif de la décision: "Cela prouve que les garde-fous fonctionnent et que nous sommes capables de trancher. Cela a valeur pédagogique". Il ne s'agissait ni d'un grand projet (environ 3 hommes.années) ni d'une application critique. Autant en faire un cas d'école.

Les leçons de cette expérience? Tout d'abord que production et aide à la décision n'appellent pas la même informatique. "C'est culturellement un autre monde. Nous avons appliqué des méthodes traditionnelles alors qu'il faut trouver d'autres approches. Quand un outil est indispensable et qu'il n'y a pas de temps à perdre, les utilisateurs sont plus réalistes et on peut se permettre d'être plus directif. Avec l'aide à la décision, on touche un domaine beaucoup plus subjectif".

Dans le cadre de sa nouvelle mission "qualité et méthode", Nicole Hernandez, ingénieur de recherche au service informatique de mission du ministère, fait aussi l'exégèse du projet GME, qu'elle a, en partie, piloté. Les causes de ce "loupé" ne sont pas techniques. Le prototype final fonctionne bien. Son ergonomie de type Windows n'est pas mise en cause. Mais on le juge trop complet, trop lourd à mettre en oeuvre, par rapport à un besoin qui n'est pas si pressant... Entraînés par l'enthousiasme et les exigences des demandeurs, les informaticiens se sont lancés dans un projet trop ambitieux.

De plus, les représentants des établissements n'étaient sans doute pas suffisamment représentatifs des attentes de leurs collègues. La dimensions psychologique n'a pas été prise en compte. Or, si certains chefs d'établissements cherchaient à optimiser l'affectation de leurs ressources, d'autres reproduisaient la même structure d'une année sur l'autre sans se poser de questions... Utiliser l'outil supposait une méthode de travail nouvelle. "Comme le projet avait été développé à la demande des utilisateurs, nous avons pensé qu'il était vendu d'avance. C'était apparemment une erreur", conclut Nicole Hernandez. @SIGNATURE: SHD

@LEGENDE PHOTO: à venir