Gestion du risque des projets SI

De Baripedia
Gestion du risque des projets SI
Faculté Faculté d'économie et de management
Département Services généraux GSEM
Professeur(s) Jolita Ralyte[1]
Cours Gestion de projet

Lectures


Gestion du risque[modifier | modifier le wikicode]

La gestion du risque est d'une importance primordiale dans le développement des SI. C'est un ensemble des principes et des pratiques ayant comme objectif identifier, analyser, et traiter les facteurs de risque afin d'améliorer les chances d'obtenir avec succès le résultat attendu du projet.

  • Avant le projet : identification et évaluation du risque
  • Pendant le projet : suivi et contrôle du risque
  • Après le projet : capitalisation de l'expérience

Exemples de risque dans les projets SI

  • Le projet ne débouche pas sur un résultat attendu
  • Le projet consomme trop de ressources
  • Le projet dure trop longtemps
  • Le système ne remplit pas la fonction attendue
  • Les utilisateurs n'acceptent pas le système
  • Le fonctionnement du système est trop coûteux

"Le taux élevé d'échec s'explique par le fait que les gestionnaires ne prennent pas des mesures afin d'évaluer et de gérer les risques impliqués dans le projet" (Keil et al., 1998)

"Les post-mortem des projets échoués indiquent que les problèmes auraient pu être évités s'il y avait eu une identification et une résolution rapide des éléments à hauts risques." (Boehm, 1991)

La gestion du risque permet d'éviter le désastre ainsi que le travail superflu, de régler et équilibrer les efforts et de stimuler les situations "win-win".

La plupart des projets SI sont à l'origine des changements organisationnels. Leur succès peut donc être crucial pour la réalisation des objectifs économiques de l'organisation.

Définitions du risque[modifier | modifier le wikicode]

Le risque est une exposition aux facteurs spécifiques qui présentent une menace pour obtenir les résultats attendus du projet. (Bannerman, 2008)

C'est une mesure de la probabilité et de l'impact de non réalisation de l'objectif du projet.

  • R = P x I

R = exposition à un facteur particulier du risque. P = probabilité qu'un événement indésirable arrive. I = impact ou ampleur des pertes si l'événement arrive.

Selon la définition probabilistique :

  • tous les facteurs potentiels du risque doivent être identifiés au début du projet
  • l'exposition au risque est estimée pour chaque facteur
  • les facteurs sont classés en fonction de leur priorité afin d'identifier les facteurs les plus menaçants
  • focalisation sur les facteurs à haut risque pour minimiser leur probabilité d'occurrence ou l'ampleur de leur impact

Limitations de la définition probabilistique :

  • il est difficile d'estimer la probabilité et l'impact de plusieurs facteurs
  • il est plus facile d'évaluer le risque sur une échelle simple (ex. : bas, moyen, haut) que de calculer sa probabilité
  • couplage fort entre l'événement et les conséquences du risque sans prendre en considération la vulnérabilité et les capacités de l'organisation à répondre à la menace
  • la définition n'inclut que les menaces connues

Démarche de gestion du risque[modifier | modifier le wikicode]

  • Identifier les risques -> facteurs de risque
  • Évaluer l'impact des risques sur les coûts, le délai, et la qualité -> profil du risque, matrice de probabilité/impact
  • Identifier et mettre en place les actions aptes à réduire les risques inacceptables -> stratégies de gestion du risque
  • Suivre les actions et contrôler l'état des risques
  • Capitaliser l'expérience

Principaux facteurs de risque[modifier | modifier le wikicode]

  • La taille du projet
  • La difficulté technique
  • Le degré d'intégration
  • La configuration organisationnelle
  • Le changement
  • L'instabilité de l'équipe de projet

La taille du projet[modifier | modifier le wikicode]

  • Le risque est lié aux limites de l'individu
    • Un grand projet signifie une large étendue du domaine couvert et impose un partage du travail entre un nombre important de personnes
  • Il est difficile à gérer le processus de la production et l'intégration des travaux de plusieurs équipes

Critères

  • Durée du projet (en mois)
  • Charge du projet (en mois/personne)
  • Couverture fonctionnelle (nombre de processus)
Facteur Degré Métrique
Durée du projet 1 =< 6 mois
2 =< 18 mois
3 =< 30 mois
4 > 30 mois
Charge du projet 1 =< 20 mois/personne
2 =< 120 mois/personne
3 =< 300 mois/personne
4 > 300 mois/personne
Couverture fonctionnelle 1 =< 2 processus
2 =< 6 processus
3 =< 10 processus
4 > 10 processus

La difficulté technique[modifier | modifier le wikicode]

  • Le risque correspond à une nouveauté technologique ou une difficulté technique provenant des contraintes imposées au projet.
    • Ex. : contraintes de performance, de langage, d'architecture, ...
  • Le risque est l'absence de compétences techniques nécessaires, qui pénalise la production

Critères

  • Expérience de l'entreprise sur les techniques à utiliser (nombre de projets)
    • Expérience sur l'architecture, le langage de programmation, le SGBD
  • Expérience du marché sur les techniques à utiliser (nombre de références)
    • Expérience sur l'architecture, le langage de programmation, le SGBD
  • Contrainte de performance (de 0 à très élevée)
  • Responsabilité de la direction informatique (degré de responsabilité)


Le degré d'intégration[modifier | modifier le wikicode]

  • Le degré d'intégration mesure le degré de dépendance ou d'autonomie du futur SI
    • Plus le SI en construction doit collaborer avec d'autres systèmes de l'entreprise, plus il est difficile d'identifier clairement l'impact de choix de conception
    • D'autres entités, d'autres équipes, d'autres projets de développement peuvent être concernés, ce qui augmente le nombre d'acteurs du projet

Critères

  • Nombre de flux avec des applications connexes
  • Nombre d'applications connexes en évolution

La configuration organisationnelle[modifier | modifier le wikicode]

  • Ce facteur correspond à l'étendue de l'entreprise qui est touchée par le projet
    • Le risque provient de la lourdeur des procédures de participation et de décision quand plusieurs grandes entités de l'entreprise (les directions) sont parties prenantes du projet. La production en est ralentie.
  • Éventuels conflits politiques et organisationnels peuvent bloquer les prises de décision et ralentir le processus de développement

Critères

  • Nombre de directions assurant la MOA
  • Existence et implication d'un sponsor
  • Pérennité du sponsor
  • Appui de la direction générale

Le changement[modifier | modifier le wikicode]

  • Le risque de mauvaise définition du futur système à cause d'un changement métier ou organisationnel
    • Le changement visé par le projet signifie que le système de gestion et/ou d'organisation existants ne peuvent pas être pris comme référence stable et que l'effort de conception et d'innovation va être important.

Critères

  • Degré d'évolution organisationnelle (écart par rapport à l'existant)
  • Degré d'évolution fonctionnelle (écart par rapport à l'existant)
  • Degré d'évolution technique (écart par rapport à l'existant)
  • Impact social (conséquences sur effectif et salaire)
  • Nombre de sites concernés

L'instabilité de l'équipe de projet[modifier | modifier le wikicode]

  • Le risque est lié au départ de certains membres de l'équipe durant le projet
    • Problème du transfert de connaissances : les concepteurs engrangent un ensemble de connaissances implicites sur le projet et son domaine que des modèles formalisés ne suffissent pas à transmettre
    • Risque de mauvaise interprétation de la conception faite par d'autres personnes, ce qui peut avoir des conséquences sur les délais et la cohérence de la réalisation.

Critères

  • Durée du projet (en mois
  • Sous-traitance de MOA (en %)
  • Mobilité dans l'entreprise (degré)
  • Relation MOA - MOE (niveau de relations)
  • Techniques attrayantes (niveau d'attractivité)
  • Marché de l'emploi (niveau de difficulté)
  • Image du projet (degré de valorisation)

Évaluation du degré de risque[modifier | modifier le wikicode]

Le degré de risque de chaque facteur est calculé avec la formule :

Degré de risque d'un facteur = Somme (degré de chaque critère*pondération) / somme des pondérations.

Une pondération peut être définie pour majorer l'importance d'un critère dans le facteur étudié.

Le profil du risque permet ainsi de faire apparaître les risques majeurs qui présentent un degré élevé (si la moyenne des risques dépasse 3 sur 4, l'échec est inévitable).

Les stratégies de gestion du risque[modifier | modifier le wikicode]

  • Fuite

Recherche des moyens pour éviter l'effet négatif du risque sur le projet.

Exemple : modification de la solution conceptuelle du projet - élimination ou modification de certaines fonctionnalités et/ou propriétés.

  • Transfert

Déplacement de la responsabilité du risque à un tiers; n'élimine pas la menace mais délègue la responsabilité de sa gestion à quelqu'un d'autre.

Exemple : assurance, contrat de sous-traitance, outsourcing.

  • Mitigation

Réduction de la menace en réduisant la probabilité et/ou l'impact du risque.

Exemple : amélioration de la participation des utilisateurs, formation des développeurs, choix des méthodes, etc.

  • Acceptation passive ou active

Passive : quand la menace n'est pas importante et/ou la source du risque est externe au projet.

Active : quand la menace est réelle mais qu'il n'y a rien à faire avant son apparition; un plan de contingence peut être prévu.

Exemple : budget et/ou ressources supplémentaires, plan d'action, etc.

Solutions pour chaque facteur[modifier | modifier le wikicode]

La taille du projet[modifier | modifier le wikicode]

  • Découper le projet en sous-projets
  • Choisir un modèle de développement évolutif et incrémental. Exemple : le modèle de la Spirale où chaque cycle permet l'analyse du risque et la redéfinition des objectifs.
  • Choisir un dispositif de coordination formel pour gérer l'avancement d'une équipe importante

La difficulté technique[modifier | modifier le wikicode]

  • Différer l'introduction d'une ou plusieurs innovations
  • Rechercher les compétences nécessaires
  • Si les besoins sont stables, le risque majeur est lié à la programmation, alors les modèles de type Cascade ou RAD permettent de se focaliser sur la programmation
  • Sinon, choisir le modèle en W qui insiste sur les tests systématiques

Le degré d'intégration[modifier | modifier le wikicode]

  • Intégrer dans le projet les acteurs qui connaissent bien les autres systèmes avec lesquels le SI doit s'intégrer
  • Les modèles en V et W facilitent l'intégration modulaire

La configuration organisationnelle[modifier | modifier le wikicode]

  • Limiter le champ de participation de chaque membre exécutif
  • Privilégier le développement évolutif et incrémental

Le changement[modifier | modifier le wikicode]

  • Réduire l'incertitude en modifiant le champ du projet ou ses caractéristiques
  • Intégrer des acteurs qui ont le pouvoir de prendre les décisions stratégiques
  • Utiliser les techniques facilitant la créativité et l'exploration
  • Les modèles de développement évolutif et RUP permettent de gérer les besoins qui s'éclaircissent en cours du projet.

L'instabilité de l'équipe de projet[modifier | modifier le wikicode]

  • Obliger la documentation détaillée de chaque produit et activité du projet - un système d'information sur le futur système (documentation du projet)
  • Superviser les personnes à risque, ce qui favorise la transmission des connaissances

Conclusion[modifier | modifier le wikicode]

  • La gestion du risque s'attaque en premier lieu aux facteurs humains et non techniques : il n'y a pas de recette miracle, il faut avant tout beaucoup de jugement.

(Boehm, 1991)

  • La gestion du risque doit devenir une part entière de la méthodologie de développement et non pas une activité séparée

(Kwak & Stoddard, 2002)

  • Implantation progressive dans les organisations

(Boehm, 1991)

Le top 10 des facteurs de risque[modifier | modifier le wikicode]

Selon Boehm, 1991 :

  • Manque de personnel compétent
  • Budgets et échéances irréalistes
  • Mauvaises fonctionnalités développées
  • Mauvaise interface développée
  • Gold plating (addition de plus de fonctionnalités/propriétés que ce qu'il est nécessaire)
  • Demandes de changement continuelles
  • Pénurie de composantes acquises à l'externe
  • Problèmes au niveau des tâches confiées à l'externe
  • Problèmes de performance en temps réel
  • Limite des capacités informatiques

Annexes[modifier | modifier le wikicode]

Références[modifier | modifier le wikicode]