Trop souvent en phase de cadrage et avant une consultation, l’analyse des risques est négligée au motif qu’on ne peut pas tous les anticiper à ce stade ou qu’il s’agit toujours des mêmes risques qui relèvent d’une évidence.
C’est une erreur qui affaiblit le dossier de consultation en ce sens qu’elle ne permet pas de se poser les bonnes questions alors qu’il en est encore temps ou de distinguer le prestataire qui aura mieux que les autres appréhender le contexte du projet et donc sera en mesure d’y apporter les réponses adéquates (gouvernance, taille des équipes, budget réaliste, etc.).
Après avoir analysé plusieurs dizaines de cas de projets ayant rencontré des difficultés, DFC a modélisé les causes de difficultés des projets informatique. Cela nous a permis de disposer d’une matrice de base pour procéder à une analyse rapide d’une situation quelle que soit la nature du projet ou le secteur d’activité concerné.
En vous fondant sur cette « simple » matrice et en approfondissant vos échanges et réflexions, vous serez en mesure très tôt sur un projet d’identifier les risques qui pèsent sur ce dernier et de réfléchir aux mesures correctives ou aux questions que vous souhaiterez poser à un futur prestataire afin de comprendre si au-delà de son savoir, il a correctement appréhendé le contexte de votre projet.
Modélisation des causes des difficultés des projets informatiques
La perte de la maîtrise du périmètre fonctionnel
en raison d’oublis lors de l’expression initiale des besoins ou de l’expression de nouveaux besoins lors de la phase d’analyse fonctionnelle (post contractuelle). Il s’agit de la cause la plus fréquemment constaté sur les projets informatiques qui rencontrent des difficultés.
Le facteur humain
il s’agit tant des égos surdimensionnés que des « moins utiles » qui se cachent derrière la conscience professionnelle des « plus utiles », ces derniers passant leur temps à compenser l’inefficacité des premiers.
La dérive provient souvent d’un chef de projet qui, bien que le projet nécessite sa présence à temps complet, est en réalité accaparé par de multiples autres responsabilités. Ainsi le premier concerné par la mise en place d’un « capacity planning » manque lui-même de temps…
Elle peut également provenir d’un manque de formation aux basiques de la gestion de projet, qui engage le projet sur de mauvaises bases.
Le facteur contractuel
c’est une cause régulière de dérive des projets informatiques.
On trouve dans certains contrats un Plan d’Assurance Qualité ou un Plan Qualité Services. Ces documents sont souvent disproportionnés et manquent cruellement de pragmatisme. Ils sont de fait abandonné par les opérationnels et ne jouent absolument pas leur rôle de guide opérationnel.
Le facteur assurance qualité / la gouvernance
la difficulté réside dans le délitement de leur application au fur et à mesure du projet, au profit de la gestion de l’opérationnel. Or, lorsqu’un projet rencontre des difficultés, l’assurance qualité et la gouvernance sont précisément des sujets qu’il importe de traiter en priorité afin de restructurer l’organisation du projet, les flux d’informations et les canaux de communication.
Le facteur technique/technologique
il peut toujours y avoir des difficultés techniques ou technologiques. Lorsqu’elles sont importantes, le projet doit parfois s’arrêter car ce qui est impacté est la raison d’être du projet.
