|
| |
|
|
 |
| La délicate étape de l'arbitrage de fin de projet |
| La décision menant au décalage, voire à l'abandon, d'un projet est redoutée par nombre d'entreprises et de SSII. Sans être toutefois considérée comme une fatalité.
(12/05/2006) |
|
Loin de constituer - fort heureusement - la grande majorité des situations, les projets informatiques connaissant des difficultés peuvent - dans certains cas critiques - se voir abandonnés.
En tout état de cause, il est nécessaire de ne pas attendre le dernier moment - devant le fait accompli - pour se rendre à l'évidence qu'un projet, confronté à une échéance de déploiement prévue, ne dispose pas d'un contexte de réalisation suffisamment stable et sécurisé.
"L'analyse de risques est importante et devrait constituer un pré-requis indispensable à la mise en uvre de tout projet informatique, au travers d'un haut niveau d'exigence et de qualité. On ne peut pas mettre les miettes sous le tapis dès qu'un problème survient", fait remarquer Jean-Bernard Franck, responsable du métier intégration de systèmes, en charge des best practices et de la formation des chefs de projets au sein de la SSII Euriware.
Des dérives peuvent également survenir en raison notamment d'un manque de cohérence entre la phase de spécification, d'analyse des besoins et attentes des métiers avec celle de la mise en production.
Mais afin d'anticiper les risques de voir capoter un projet, encore faut-il disposer de plusieurs atouts, dont celui consistant à faire appel à un chef de projet doté à la fois de compétences opérationnelles et organisationnelles, et d'une équipe projet faisant preuve d'une solidarité à toute épreuve.
"Face à un projet qui ne se déroule pas dans les bonnes conditions, l'équipe en charge de la gestion de projet peut soit décider de mettre en production, par exemple, une première version d'une solution afin de se conformer aux délais prévus et développer ensuite d'autres fonctionnalités, soit forcer le décalage de sa mise en production", note Stéphane Guibert, directeur du déploiement et du management de projet au sein de Mexon Technology, intégrateur et fournisseur de solutions de gestion de la relation client.
"En France, un projet peut être enterré dans l'indifférence générale" -
(Jean-Bernard Franck - Euriware) |
Pour autant, en cas de difficultés, une réduction de voilure (et donc de fonctionnalités) peut s'avérer - si ce n'est une solution viable sur le long terme -, au moins une porte de sortie honorable pour tenter d'éviter un conflit ouvert entre, par exemple, un client et son prestataire de service.
"Un projet sera toutefois plus difficilement abandonné en France qu'aux Etats-Unis notamment, où sa complète remise à plat sera plus facilement décidée. En France, un projet pourra mourir gentiment, utilisé au quart de ses fonctionnalités initiales, et enterré dans l'indifférence générale afin de permettre à tout le monde de garder la face", constate Jean-Bernard Franck.
Mais l'arbitrage de fin de projet, lorsqu'il mène à un abandon, pourra être également imputé à des évènements extérieurs au projet, propres à la stratégie de l'entreprise et à ses activités. Par exemple, la survenance de plans sociaux ou d'offres publiques d'achats inamicales peuvent porter un coup fatal à un projet pourtant déjà bien avancé.
Les contraintes "traditionnelles", comme les effets tunnels (corrélés le plus souvent à des rallonges budgétaires), peuvent également jouer un rôle dans l'échec de la mise en production initiale et ce, d'autant que "plus un projet s'installe dans le temps, plus il a de chances de devenir vulnérable aux critiques et de voir ressortir ses faiblesses ou points de non-maîtrise", analyse Jean-Bernard Franck.
Malgré tout, la probabilité de voir un projet purement et simplement abandonné demeure mince : "la finalité première étant d'aboutir et de mettre en production un projet qui corresponde à des besoins initiaux, émis par des acteurs clairement identifiés", indique Stéphane Guibert.
Et le directeur de mettre en garde : "le projet, bien que bloqué à un instant T, doit être créateur de valeur. Il faut donc nécessairement capitaliser sur ce qui a été mené jusqu'alors, comme la définition de spécifications détaillées, réutilisables et transférables à d'autres équipes projet de manière à ne pas avoir à réinventer la roue dans le cas où le projet serait relancé".
|
|
|
|
Dossier 