I.1.4. Les risques sources de dérives et
d'insuccès des projets informatiques
Un risque se définit comme un événement,
pouvant survenir pendant le cycle de vie d'un projet, susceptible de remettre
en cause la réalisation des objectifs en termes de coût, de
qualité et de délai.
Le but de la gestion des risques n'est pas d'éviter
des projets à risques, mais de minimiser l'impact des risques sur les
projets qui sont menés.
Ainsi, gérer les risques, c'est :
· anticiper continuellement les problèmes futurs
et non attendre leur survenance pour les gérer ;
· refuser la gestion des crises dans l'urgence, mais
prévoir leur apparition et s'y préparer.
Ainsi les principaux risques (détails en annexe 2)
sources d'échec des projets sont :
· l'inexpérience du chef de projet ;
·
12
la faiblesse de la MOA ;
· une mauvaise gestion contractuelle ;
· des objectifs non alignées sur la stratégie
de l'entreprise.
I.1.4.1. L'inexpérience du chef de projet
De nombreux projets dérapent de façon
importante en termes de délai, de coût et de qualité. Les
écueils à l'origine de ces échecs sont multiples, mais on
peut retenir en premier lieu l'inexpérience du chef de projet ou son
incapacité à conduire son projet. Ensuite, il y a
l'imprécision du cahier des charges, le manque de maturité du
client, le manque de maîtrise des processus d'ingénierie logiciel
ou les mauvaises estimations de charge du projet. Mais, il y a concomitance des
facteurs. En effet, un chef de projet expérimenté qui
maîtrise les techniques d'estimation de charges, identifiera des
imprécisions du périmètre fonctionnel et posera les
questions adéquates. L'imprécision du cahier des charges donne
dans certains cas au client l'illusion de disposer de plus de temps pour mieux
préciser ses besoins encore flous et peut-être d'en avoir plus
pour le même prix. Quant au prestataire, il peut aussi y trouver une
porte ouverte à la signature de nouveaux avenants. En plus des
connaissances du métier client et du référentiel
méthodologique propre à l'entreprise, le chef de projet se doit
de maîtriser les processus clé de la gestion de projet, mais aussi
de connaître les référentiels de bonne pratique pouvant
l'aider à appréhender de la bonne manière des situations
qui lui sont inédites.
I.1.4.2. Faiblesse de la MOA
Dans les grandes entreprises, la maîtrise d'ouvrage a
pris plus d'assurance. Elle n'hésite pas à se faire accompagner
d'une assistance interne ou externe (AMOA : assistance à la
maîtrise d'ouvrage) pour pallier à son indisponibilité ou
à son manque de compétence.
Lorsqu'on se penche sur les origines des dérives des
projets, on identifie souvent les mêmes maux résultant en partie
de la maîtrise d'ouvrage : un cahier des charges insuffisamment
précis qui est figé lors du lancement du projet alors qu'il
devrait évoluer et s'adapter au rythme de l'avancement du projet parce
que les systèmes informatiques sont aujourd'hui en constante
évolution et trop complexes pour pouvoir être totalement
prédéfinis plusieurs mois ou années à l'avance.
La réussite d'un projet se bâtit par le
partenariat, ce qui implique une maturité du client comme du prestataire
qu'il soit ou non intégrateur, mais surtout par la professionnalisation
de la MOA. Dans cette situation, la maîtrise d'ouvrage est à
même de comprendre la
13
préoccupation du prestataire qui souhaite restreindre
parfois certaines exigences fonctionnelles ou techniques. La MOA a en
contrepartie, l'assurance du respect de la livraison d'une version plus
restreinte, mais opérationnelle.
| 
