Modification de Gestion du risque des projets SI

{{Infobox Lecture
 | image = 
 | cours = [[Gestion de projet]]
 | faculté = [[Faculté d'économie et de management]]
 | département = [[Services généraux GSEM]]
 | domaine = [[Système d'information]]
 | professeurs = [[Jolita Ralyte]]<ref>[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]</ref>
 | années = 
 | code = S204033 CR <ref>[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&p_plan_is=0&p_langue=1&p_frame=N&p_mode=PGC&p_annee=2015&p_suffixe=&p_grtri= Présentation du cours sur le site du catalogue de cours wadme]</ref>
 | enregistrement = 
 | précédent = 
 | suivant = [[Techniques de planification ]]
}}

=Gestion du risque=

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=

''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= 

* '''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==

* 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===

*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

{| class="wikitable"
|-
! 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===

*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===

*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===

*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===

*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===

*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==

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=

*'''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 le 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=

==La taille du projet==

* 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==

* 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==

* 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==

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

==Le changement==

* 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==

* 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=

*'''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==

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 =

= Références =
<references />