UNIVERSITE PARIS XII - ISIAG MASTER 2 - CHAPITRE 4.b LE PILOTAGE DU PROJET ANALYSE DES RISQUES 1
LE PILOTAGE DU PROJET I. Software Development Plan II. III. IV. Risks Management Plan (Analyse des Risques) Estimation des charges Planification et Ordonnancement V. Measurement Plan (Suivi des coûts et des activités) 2
1. INTRODUCTION Définition du risque dans le domaine des SI : la possibilité qu un projet ne s exécute pas conformément aux prévisions de dates d achèvement, de coût, de spécifications, ces écarts par rapport aux prévisions étant considérés comme difficilement acceptables voir inacceptables [AFITEP (Association Francophone de Management de Projet) 1993]. Importance des risques : On rappelle qu une proportion énorme de projets informatiques sont abandonnés ou n atteignent pas leurs objectifs (exemple récent en France : SNCF et Socrate). Cela montre à quel point il est risqué de lancer un projet informatique. Solution = l analyse des risques : Le respect de méthodologies ne suffit pas à assurer le succès d un projet. Les difficultés principales (mauvaise définition des besoins, mauvaise estimation des charges, aléas) peuvent être repérées et prévenues par une approche d analyse et de suivi des risques. Différentes méthodes d analyse des risques existent. 3
2. L APPROCHE GÉNÉRALISG RALISÉE ISIAG MASTER 2 Méthode représentée notamment par le projet européen «RiskDriver». Principe : 1. Identification des risques 2. Evaluation d impact sur les coûts, les délais et la qualité (fonctionnelle ou technique) 3. Définition d actions de réduction des risques inacceptables 4. Suivi des actions 5. Capitalisation d expérience Pour les trois premières étapes on utilise des techniques classiques de simulation des idées : - Brainstorming - Diagramme causes-effets d Ishikawa (Cf. page suivante) - Matrice des probabilités/conséquences (Cf. page suivante) 4
Diagramme causes-effets d Ishikawa : Outil qui permet d identifier les causes possibles d un effet constaté et donc de déterminer les moyens pour y remédier. 5
Matrice des probabilités/conséquences ISIAG MASTER 2 Conséquences Peu importantes Graves Probabilité Faible Risque Mineur Risque Acceptable Elevée Risque Acceptable Risque Inacceptable Rappel : Typologie des risques COUT Risque DELAI QUALITE / PERFORMANCE 6
3. APPROCHE PAR RECENSEMENT DES RISQUES L AFITEP a proposé une typologie des projets informatiques et une liste des risques associés. On caractérise un projet par son type d objectif, la cible visée et le type de solution que représente le projet. 7
Risques associés au type d objectif du projet : Objectif Définitions Exemples Risques Stratégie II s'agit d'un projet dont les enjeux relèvent de la Direction générale. Il s'appuie souvent sur une technologie novatrice. Messagerie dans les années 1970, GPAO dans les années 1980, Commerce électronique Faible niveau d'implication de la Direction Générale Changement de l'environnement Non-remise en cause de l'existant Communication déficiente Efficience Il s'agit d'un projet de remplacement ou d'optimisation d'un processusexistant, en vue d'accroître la productivité.il s'appuie souvent sur des technologies éprouvées. Mise en place d'un workflow, Mise en place d'un progiciel de paie, Automatisation de gestionde stock Appropriation insuffisante du SI par les utilisateurs Sous-estimation globale du projet, minimisation des coûts Dérive technologique Obligation Il s'agit d'un projet lié à une obligation extérieure, légale ou de fait. Il s'appuie souvent sur une technologie banalisée. Projet an 2000, Projet Euro, Fusion/absorption d'entreprise Manque d'attractivité du projet Cahier des charges incomplet Non-respect des délais 8
Risques associés à la cible du projet : Cible Définitions Exemples Risques Client Le résultat du projet accroît, pour les clients, la valeur ajoutée de l'organisation (entreprise, administration, association...). Le client peut être l'usager, le consommateur, le prescripteur, l'adhérent. Bon de commande sur Internet, Informatique embarquée, TGV, Gestion de la relation client Mauvaise perception des attentes client Non-remise en cause du fonctionnement interne Détérioration de la performance de l'organisation Support Le résultat du projet améliore le fonctionnement interne de l'organisation. L'impact sur le client est indirect. Progiciel comptable Non-remise en cause de l'existant Sous-estimation des travaux Modification de l'environnement Rejet par les opérationnels Transversal Le résultat du projet touche l'ensemble de l'organisation. Il s'agit principalement de la mise en place d'outils communs. Messagerie, Systèmes bureautiques, Intranet Définition insuffisante de l'objectif Structuration inadéquate du projet Sous-estimation de l'utilisation 9
Risques associés au type de solution que représente le projet : Type Solution Définitions Exemples Risques Progiciel Applicatif Développement applicatif Intégration de systèmes Projet de mise en place d'un produit logiciel standard commercialisé par un éditeur. Projet de conception et de développement d'un logiciel spécifique dont le code source appartient à l'entreprise (même si le développement est soustraité en tout ou partie). Projet d'assemblage et d'interface des différents éléments matériels et immatériels CAO, gestion intégrée, Gestion documentaire électronique Création d'un site web commercial, Gestion de bourses Projet «Socrate» de la SNCF et son matériel Non-pérennité du produit sélectionné Sous-estimation de la charge/complexité de l'intégration Pas de remise en cause de l'existant Gestion du changement déficiente Pas de prise en compte des évolutions du progiciel Insuffisance du cahier des charges (besoins et solutions) Manque de compétences ou de pérennité du prestataire Erreurs dans le choix des composants Sous-estimation des travaux de migration et d'interfaçage Maintenance évolutive Projet d'évolution d'un système existant (matériel ou logiciel) Nouvelle version d'un logiciel interne Absence ou indisponibilité des ressources (humaines et/ou documentaires) Mauvaise analyse d'impacts des modifications envisagées Infrastructures techniques Projet concernant la mise à disposition d'une ossature technique Déploiement de réseau, Système de sécurité Réduction du projet à sa dimension technique Technologie incompatible avec la maturité technologique de l'entreprise 10
4. L AUDIT EN COURS DE PROJET ISIAG MASTER 2 Etude du Standish Group (dizaines d'interviews approfondies auprès de responsables informatiques) : grille d'évaluation du potentiel de réussite d'un projet en cours. La grille comprend dix critères, pesant chacun d'un certain poids. Critères de réussite Poids du critère Implication des utilisateurs 19% Soutien de la hiérarchie 16% Définition claire des besoins 15% Plan de développement correct 11% Attentes réalistes 10% Découpage en modules/étapes 9% Compétences dans l'équipe projet 8% Appropriation du projet par ses acteurs 6% Vision claire des objectifs 3% Productivité et motivation de l'équipe 3% 100% 11
Lors de l audit, on détermine la valeur de chaque critère grâce à un questionnaire. Cf. document «Questionnaire Audit Risques.doc» La somme des valeurs pondérées de chaque critère donne le potentiel de réussite du projet. Cette grille d'analyse permet de redresser la barre et de mettre en œuvre des actions correctives pour augmenter les chances de succès. 12
5. APPROCHE PAR LE PROFIL DE RISQUE ISIAG MASTER 2 Selon cette approche il existe six facteurs principaux de risque : 1. la taille du projet 2. la difficulté technique 3. le degré d intégration 4. la configuration organisationnelle 5. le changement 6. l instabilité de l équipe projet Taille du projet : Grand projet => large étendue couverte, nombre élevé de ressources humaines, morcellement perte de maîtrise Difficulté technique : causée par une nouveauté technologique ou par des contraintes fortes de performance. Risque = Absence de compétences techniques suffisantes. 13
Degré d intégration : niveau d autonomie du futur système. Des flux nombreux et variés entre le système développé et les autres SI de l entreprise plus d impact, choix de conception plus délicats, plus d acteurs à consulter. Configuration organisationnelle : étendue du projet dans l organigramme. Si plusieurs grandes entités sont impliquées procédures plus lourdes, décisions plus lentes, conflits possibles. Changement : les systèmes existants ne constituent pas une référence stable, effort de conception important. Le changement crée une instabilité qui peut favoriser le processus politique. Risque de rejet ou de mauvaise définition du futur système. Instabilité de l équipe : problème de transfert de connaissances (même si on utilise des modèles formalisés). Il est difficile de reconstituer la connaissance et les erreurs d interprétation peuvent avoir des conséquences sur les délais et la cohérence de la conception. 14
Chaque critère est évalué différemment et mesuré par une métrique spécifique : Risque Taille Métrique Charge estimée, durée prévue, couverture fonctionnelle Difficulté technique Degré d intégration Configuration organisationnelle Changement Instabilité de l équipe Expérience de l'entreprise sur les techniques à utiliser, diffusion de ces techniques sur le marché, contraintes de performance, existence de direction informatique interne Nombre de flux entre la future application et les autres, nombre d'applications connexes en cours d'évolution Nombre de directions assurant la MO, appui de la DG, implication et perennité du commanditaire Degré d'évolution fonctionnelle, organisationnelle et technique, nombre de sites concernés, éventuels impacts sociaux Nombre d'acteurs impliqués, Proportion de procédures faisant l'objet d'une documentation, degré de formalisation des documents On attribue à chaque critère un niveau de risque situé entre 0 et 5. 15
Grâce à ces métriques on représente le profil de risque du projet : Exemple de profil avec risque extrême (échec inéluctable) : 16
6. CONCLUSION Comme on l a vu dans l approche généralisée, l essentiel est de repérer les risques principaux inhérents à un projet et de mesurer quantitativement leur gravité. Les causes éventuelles des risques les plus graves feront l objet d une surveillance accrue pendant toute la durée du projet. Des plans d action doivent être établis avant que les risques ne se réalisent, de manière à pouvoir réagir immédiatement, voire proagir. L analyse de risques doit prendre place : - de façon préventive avant le lancement du projet (en phase d avant-projet ou d étude faisabilité). Dans ce cas, l analyse de risques peut influencer la conception et le choix de solutions, voire faire renoncer au projet. - en cours de projet, dans un cadre de surveillance permanente. 17
Application : Cf. document «Etude de cas Analyse de Risques.doc» 18