Problématologie (Non Exhaustive) des Projets Informatiques
Par Frédéric Leroy, le lundi 08 décembre 2008 (18:13) - Gestion de Projets - Lien permanent
La refonte du système de gestion financière au sein d’une institution financière ou d’une entreprise (gestion de trésorerie) est souvent présentée comme un facteur de réduction des risques et des coûts opérationnels. Pourtant, de nombreux projets échouent du fait de la complexité technique, fonctionnelle et opérationnelle de tels projets qui, de plus, impliquent bien souvent un re-engineering des process et des méthodes.
Ainsi, P. Jorion[1] rapporte que les projets d’implémentation de solutions intégrées front-to-back chez CSFB comme chez Salomon Brothers ont subi des retards et des dépassements de budget pour un coût total supérieur à $100M chacun. Et il ne s’agit pas de cas isolés. Philips[2] a montré qu’environ 80% des projets informatiques échouent du fait de dépassements de délais et de budgets significatifs avec comme « scénario catastrophe » l’échec total du projet et son abandon pur et simple.
L'occasion de faire le point sur les problèmes et leurs causes.
On distingue les causes fondamentales, les causes spécifiques à chacune des étapes du projet et les facteurs aggravants.
Les causes fondamentales résultent de l’absence et/ou de l’inefficacité de l’organisation globale de gestion des risques opérationnels. A savoir :
- Organisation globale de gestion des risques opérationnels absence et/ou inopérantes
- Méthodologie de gestion des risques opérationnels absente et/ou inopérante
- Processus de contrôle et de validation de la gestion des risques opérationnels et du déroulement du projet absents et/ou inopérants
- Procédures de reporting périodique absentes et/ou inopérantes
- Actions correctives en cas de dérive (management, opération) absentes et/ou inopérantes
Ces causes fondamentales sont (relativement) simples à éviter par la mise en place d’une organisation et de process.
Des raisons plus spécifiques et plus insidieuses peuvent accroître le risque d’échec au niveau de chaque étape du projet (cf. liste non exhaustive ci-dessous).
|
Etapes |
Causes des Problèmes |
|
Sélection |
Faible implication et/ou intérêt des utilisateurs finaux du fait des contraintes de production Choix d’un système trop éloigné du RFP impliquant une liste de gaps trop importante Choix d’un système n’ayant pas de track-record significatif dans le segment de marché du client Choix d’un système conçu, développé et commercialisé par un challenger et non un leader du marché (en particulier, sur un marché en stagnation) |
Spécification |
Faible implication et/ou intérêt des experts « métiers » du fait des contraintes de production Incapacité des consultants à rédiger des business requirements exhaustifs et cohérents du fait des problèmes en amont et/ou de leur méconnaissance des problématiques métiers du client Incapacité des ingénieurs de R&D (Editeurs) à rédiger des functional specifications exhaustives et cohérentes du fait des problèmes en amont et/ou de leur méconnaissance des problématiques métiers du client |
|
Développement |
Incapacité des ingénieurs de R&D (Editeurs) à rédiger des technical specifications exhaustives et cohérentes du fait des problèmes en amont Absence de méthodologie de développement et/ou méthodologie peu/pas appliquée dans les faits Absence de programme de formation et/ou de documentations techniques pour les partenaires extérieurs ou les nouveaux « entrants » participants au développement Absence d’étude d’impact préalable des développements envisagés (gaps) sur la cohérence technique, architecturale et fonctionnelle du produit existant |
|
Implémentation |
Faible assiduité et/ou intérêt des utilisateurs finaux aux formations du fait des contraintes de production Recours à des consultants externes ayant peu/pas d’expérience sur la version et/ou le produit et/ou l’éditeur de logiciels (hommes, culture, process) Incapacité des consultants à rédiger des « implémentation & intégration guidelines » exhaustives et cohérentes du fait des problèmes en amont Priorités différentes entre le client (être « live » avec le produit) et l’éditeur (avoir « livré » le produit) exacerbées si l’éditeur ne participe pas directement au projet |
Production |
Incapacité des consultants à rédiger des « procédures de gestion et de test (en double systèmes)» exhaustives et cohérentes du fait des problèmes en amont Procédures de gestion et de test (en double systèmes) peu ou pas respectées du fait des contraintes de productions ou des problèmes en amont |
Enfin, un certain nombre de facteurs contribuent à augmenter les risques d’échec sur un projet :
- Etendue du projet (mesurable en nombre de gaps, en nombre d’utilisateurs ou en nombre de partenaires parties prenantes du projet). Lorsque les projets sont très complexes il est impératif de « casser » la complexité en modularisant le projet et en réalisant une analyse cohérente et exhaustive des « connexions » entre les sous-projets.
- Faible expérience du management et des ressources impliquées dans le projet. Le recours à des ressources ayant peu ou pas d’expérience sur des postes « opérationnels » ou « techniques » peut dans certain cas se justifier[3]. Par contre, dupliquer cette « stratégie » au niveau des postes de types « expert » ou « manager » est plus nettement plus problématique.
- Choix d’une technologie de rupture par rapport au système d’information existant. Il s’agit ici d’un débat essentiel entre les tenants d’une approche « intégration de systèmes » et les tenants d’une approche « système intégré tout-en-un » qui présentent d’ailleurs des profils « risk/return » pas forcément symétriques.
Ces risques potentiels doivent avant tout être identifiés au début du projet et faire l’objet d’un traitement prospectif à plusieurs niveaux en fonction du type de risque.
Notes
[1] P. Jorion (2001), “Value-at-Risk - The New Benchmark for Managing Financial Risk”, MacGraw-Hill
[2] D. Philips (1998), “The Software Project Manager’s Handbook – Principles that Work at Work”, IEEE Computer Society Press
[3] La réduction des coûts est probablement la justification la plus souvent avancée, c’est aussi la plus mauvaise car les effets négatifs à moyens/long termes peuvent être beaucoup plus importants que les gains à court terme. Il s’agit là d’un biais cognitif assez connu qui consiste à sur-pondérer le présent (le gain est quasi-immédiat) et la certitude (il est quasi-certain).