"Soyons prêts, voilà tout." - Hamlet V:ii:215
Un projet, comme la vie, est incertain. Nous n'identifions pas les risques pour eux, mais pour les anticiper et les
atténuer, si possible, ou pour y répondre lorsque nous ne pouvons pas les anticiper.
Les risques décident des plans d'itérations car elles sont destinées à répondre à certains risques en les limitant ou
les réduisant. La liste de risques est revue régulièrement pour évaluer l'efficacité des plans d'atténuation, ce qui
décide des révisions du planning de projet et des itérations suivantes.
Le point clé de la gestion de risques est de ne pas attendre qu'un risque se matérialise (et devienne un
problème ou un échec) pour décider de la manière de le résoudre. Tout comme une modification de cap de quelques degrés
d'un vol transcontinental a un effet considérable sur l'endroit où il atterrit, gérer un risque tôt est pratiquement
toujours moins cher et moins compliqué que de devoir le résoudre par la suite.
Il existe trois stratégies principales [BOE91] :
-
Suppression du risque. Réorganiser le projet pour qu'il ne puisse pas être affecté par ce risque.
-
Transfert du risque. Réorganiser le projet pour que le risque devienne du ressort d'une autre personne ou
organisation (client, sous-traitant, banque, autre élément...). Stratégie de suppression de risque particulière.
-
Acceptation du risque. Décider de laisser le risque comme éventualité. Surveiller les symptômes du risque et
décider d'un plan de réponse s'il se matérialise.
Si vous décidez d'accepter le risque, vous pouvez également choisir d'atténuer le risque, de prendre des mesures
concrètes permettant de réduire un impact éventuel.
Il est important de faire la différence entre les risques directs et indirects. Pour simplifier, un risque direct est
un risque sur lequel vous avez un certain degré de contrôle tandis que vous n'en avez aucun sur un risque indirect.
Bien qu'il ne faille pas ignorer les risques indirects, ils n'ont que peu de conséquences sur le plan pratique : comme
ils sont hors de notre contrôle il est inutile de s'en préoccuper. Malgré le fait que le monde puisse
disparaître demain, il est également possible qu'il ne disparaisse pas et il est donc préférable de
continuer à travailler !
Dans certains cas un risque indirect est en fait un risque direct déguisé. Par exemple, certains composants dépendent
peut-être d'un fournisseur externe. Ce risque semble être indirect, mais si nous disposons d'un programme d'urgence
pour ces composants, nous pouvons prendre contrôle de ce risque : nous pouvons choisir un autre fournisseur ou décider
de développer les fonctions nous-même. Dans de nombreux cas, nous avons plus de contrôle que nous ne le pensons !
Pour gérer les risques indirects, vous devez essayer de gagner un certain degré de contrôle sur le risque ou le noter
et continuer. Il est inutile de s'étendre sur ce que vous ne pouvez pas changer.
Organisation
-
Le projet reçoit-il l'engagement requis (y compris au niveau de la direction, des testeurs, de la garantie de
qualité et autres parties prenantes externes) ?
-
S'agit-il du plus grand projet jamais entrepris par la société ?
-
Existe-t-il un processus de génie logiciel bien défini ? De capture et gestion des exigences ?
Financement
-
Le financement du projet est-il en place ?
-
Disposez-vous de financement pour la formation et le mentorat ?
-
Avez-vous reçu des contraintes budgétaires comme un coût fixe, le projet est-il sujet à annulation ?
-
Les estimations sont-elles précises ?
Ressources
-
Disposez-vous de suffisamment de personnes ?
-
Ont-ils les connaissances requises ?
-
Ont-ils déjà travaillé ensemble ?
-
Croient-ils dans la réussite du projet ?
-
Disposez-vous d'utilisateurs types pour les revues ?
-
Disposez-vous d'experts dans le domaine ?
Temps
-
Le calendrier est-il réaliste ?
-
Pouvez-vous faire varier les fonctionnalités pour adhérer au calendrier ?
-
La date de livraison est-elle critique ?
-
Disposez-vous de suffisamment de temps pour le faire correctement ?
-
Que se passe-t-il si un concurrent est prêt avant ?
-
Que se passera-t-il si le financement du projet rencontre des difficultés (une variante est "comment assurer un
financement correct") ?
-
La valeur projetée du système est-elle supérieure au coût envisagé ? (veillez à inclure la valeur-temps de l'argent
et le coût des capitaux).
-
Que se passera-t-il si vous ne pouvez pas passer de contrat avec les fournisseurs principaux ?
-
Pouvez-vous mesurer la réussite ?
-
Toutes les parties sont-elles d'accord sur la mesure de la réussite ?
-
Les exigences sont-elles suffisamment stables et bien comprises ?
-
La portée du projet est-elle figée ou continue-t-elle à croître ?
-
La durée prévue de développement est-elle courte et inflexible ?
-
La technologie est-elle éprouvée ?
-
Les objectifs de réutilisation sont-ils raisonnables ?
-
Un produit doit être utilisé avant d'être réutilisé.
-
Il faut parfois plusieurs versions significatives d'un composant avant qu'il ne soit suffisamment stable
pour être réutilisé sans trop de modifications.
-
Les volumes de transactions des exigences sont-ils raisonnables ?
-
Les estimations de taux de transactions sont-elles raisonnables ? Sont-elles trop optimistes ?
-
Les volumes de données sont-ils raisonnables ? Peuvent-ils être gérés par les ordinateurs disponibles, ou, si les
exigences vous indiquent qu'un poste de travail ou un système départemental fera partie de la conception,
pourront-ils gérer les données ?
-
Existe-t-il des exigences inhabituelles ou complexes qui demanderont à l'équipe de projet de résoudre des problèmes
avec lesquels elle n'est pas familière ?
-
La réussite dépend-elle de produits, technologies ou services nouveaux ou de matériel, techniques ou logiciel qui
n'ont pas été mis à l'épreuve ?
-
Existe-t-il des dépendances externes sur des interfaces vers d'autres systèmes, y compris d'autres entreprises
? Les interfaces existent t'elles ou doivent-elles être créées ?
-
Existe-t-il des exigences de disponibilité et de sécurité extrêmement inflexibles (par exemple, "le système ne peut
pas tomber en panne") ?
-
Les utilisateurs du système ont-ils l'expérience du type de système créé ?
-
Existe-t-il un risque lié à la taille et à la complexité de l'application ou à la nouveauté de la technologie ?
-
Existe-t-il une exigence pour la prise en charge de langues nationales ?
-
Est-il possible de concevoir, installer et utiliser ce système ? Certains systèmes sont simplement trop grands ou
trop complexes pour fonctionner correctement.
-
Le projet dépend-il d'autres projets en développement (parallèles) ?
-
La réussite dépend-elle de produits disponibles sur le marché ou de composants développés à l'extérieur ?
-
La réussite dépend-elle de l'intégration d'outils de développement (outils de conception, compilateurs...), de
technologies d'application (systèmes d'exploitation, bases de données, mécanismes de communications entre
processus...). Disposez-vous d'un plan de secours pour livrer le projet sans ces technologies ?
L'expérience montre que 85 % des risques ont un impact direct ou indirect sur le calendrier et donc également sur le
coût. Environs 5 % des risques n'affectent que le coût. Le reste n'a pas d'impact direct sur le coût ou le calendrier
mais sur la qualité, par exemple.
Si l'ennemi est le calendrier, approchez-le en douceur par des livraisons incrémentales. Evitez les livraisons massives
uniques pour essayer de vous tenir au calendrier.
Certains projets ont de véritable "dates de péremption". Un logiciel pour analyser le résultat d'une élection en
direct, par exemple, ne sera pas très utile s'il sort la semaine suivant l'élection. Un logiciel peut également être
rendu obsolète par vos concurrents : ils lancent un logiciel meilleur que le vôtre alors que vous êtes toujours en
cours de développement. Soudainement, vous n'êtes plus dans le coup, et vous ne pouvez rien y faire. Généralement, peu
de projets ont de telles échéances. Les délais affectent principalement le coût.
En règle générale, votre engagement doit être égal à l'estimation la plus précise, plus une réserve raisonnable.
engagement = estimation + réserve
D'autres conseillent de baser votre engagement sur la stratégie de récupération, c'est à dire sur votre plan de
réserve, mais c'est un peu trop pessimiste car tous les risques ne se matérialiseront pas.
Les risques de planifications sont intégrés dans certains outils d'estimation. Par exemple, dans le modèle COCOMO, des
éléments de coûts comme :
-
complexité (cplx)
-
contraintes en temps réel (time)
-
contraintes de stockage (stor)
-
expérience (Vexp)
-
disponibilité de bons outils (tool)
-
pressions du calendrier (sced)
sont en réalité des facteurs de risque.
Des techniques de gestion de risque plus sophistiquées impliquent l'utilisation de la simulation Monte Carlo, dans
laquelle un nombre très élevé de "scénarios" est passé par un outil de simulation pour calculer le risque global et les
imprévus [KAR96].
|