Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Extrait de La Lettre de l’ADELI N°22 - Janvier 1996 1 Les risques d’un projet C

Extrait de La Lettre de l’ADELI N°22 - Janvier 1996 1 Les risques d’un projet Cet article regroupe des analyses des risques de projets informatiques effectuées par différents observateurs. Nous vous laissons le soin d’en faire une synthèse, à la lumière de votre propre expérience. L’ouvrage C’est le résultat du projet. Il est représenté par une Arborescence Technique du Système. Il existe des risques que l’ouvrage final, insuffisamment défini, ne corresponde pas aux attentes des utilisateurs. L’œuvre C’est l’ensemble des travaux nécessaires à la réalisation de l’ouvrage. Elle est représentée par une Structure Hiérarchique des Travaux. Il existe des risques qu’un choix, maladroit ou présomptueux, de techniques de réalisation mal adaptées, ne permette pas de réaliser l’ouvrage projeté. Les ressources C’est l’ensemble des moyens nécessaires au bon déroulement des travaux. Elles sont représentées par une Structure Des Contributeurs. Il existe des risques qu’une affectation optimiste de moyens inadaptés ne permette pas de réaliser les travaux. La planification initiale C’est l’ordonnancement de l’œuvre. Elle est représentée par un Organigramme Technique. Il existe des risques qu’une planification peu réaliste ne puisse respecter les contraintes de coûts et de délais imposées au projet. Le suivi C’est la constatation du déroulement réel des travaux. Il existe des risques qu’un management, inattentif et peu rigoureux, laisse se développer des dérives irréversibles (insatisfaction des exigences de qualité, dépassement des coûts, allongement des délais). On voit, ainsi, que chaque stade du projet génère ses propres risques qui se combinent avec ceux des autres stades: • conception de l’ouvrage - nomenclature, • choix des techniques de réalisation - gammes de fabrication, • choix des moyens - affectation des ressources, • ordonnancement - planification, • déroulement du projet. 2 Extrait de La Lettre de l’ADELI N°22 - Janvier 1996 1 - Les 10 risques majeurs d’un projet, d’après BOEHM Risques encourus et classement Mesures préventives Risque n° 3 Développement de logiciels impropres à satisfaire les besoins Analyse de l’organisation Analyse des missions Revue Prototypage Rédaction anticipée des manuels utilisateurs Ouvrage Risque n° 4 Développement de mauvaises interfaces utilisateurs Analyse des tâches Prototypage Prise en compte de l’utilisateur (fonction, comportement, charge de travail) Risque n° 9 Défaillance des performances en temps immédiat Simulation Essais comparatifs Modélisation, Prototypage Instrumentation, Réglages Œuvre Risque n° 10 Blocage sur les limites technologiques des plates-formes Analyse technique Vérification a priori des performances Analyse des coûts Ressources Risque n° 1 Inaptitude du personnel Structuration de l’équipe Redistribution des rôles Renforcement de l’encadrement Formation, entraide, motivation Planification Risque n° 2 Prévisions optimistes, sous- estimation des budgets Recoupement de plusieurs estimations détaillées des charges, des coûts et des plannings Remise en cause des demandes Développement incrémental Réutilisation de logiciel Risque n° 5 Perfectionnisme Examen critique des spécifications Prototypage Calcul des retours sur investissement Suivi Risque n° 6 Courant continu de modifications Seuil d’acceptation des changements Développement incrémental Report des modifications en fin de projet Risque n° 7 Défaillances des fournitures externes Mise en concurrence Contrôle des références Analyse de compatibilité Inspection et recette Risque n° 8 Défaillances des travaux sous- traités Contrôle des références Audit de qualification Structure d’équipe Extrait de La Lettre de l’ADELI N°22 - Janvier 1996 3 2 - Alerte rouge, selon le GARTNER GROUP L’analyse du GARTNER GROUP identifie les risques suivants : • Absence de planning adéquat, • Fournisseurs de services autorisés à procéder sans supervision, • Modifications supérieures à 5 % sur la portée d’ensemble du projet, • Absence d’implication des utilisateurs finals, • Projet de taille excessive, • Acheteur sans expérience pour superviser un fournisseur inexpérimenté. 3 - Pourquoi un projet échoue, selon INPUT Les causes les plus fréquemment incriminées sont les suivantes : • Mauvaise définition des objectifs, • Changement des besoins, • Mauvaise gestion du projet, • Planning irréaliste, • Sous-estimation des coûts, • Mauvais choix de fournisseurs. 4 - Les risques du projet, selon Eurométhode Le guide de la planification des livraisons d’Eurométhode présente des tableaux qui croisent des conséquences néfastes pour le projet et des facteurs générateurs d’incertitude. Chaque ligne caractérise une conséquence néfaste. Chaque colonne caractérise un facteur situationnel, générateur d’incertitude. L’intersection caractérise l’influence de l’incertitude du facteur situationnel sur le déclenchement d’une conséquence défavorable. Liste de conséquences défavorables... ... pour l’ouvrage • Faible qualité des produits, • Développement d’un système erroné ou inutilisable, • Rejet du nouveau système par les utilisateurs, • Déficiences des propriétés non fonctionnelles (sécurité, maintenabilité, efficacité, rentabilité, etc.), • Coûts insupportables pour l’entreprise. ... pour l’œuvre • Exigences indéterminées ou irréalisables, • Indétermination des interfaces, • Difficulté d’intégration avec les autres systèmes, • Dépassement de capacité des possibilités informatiques, • Incidence de l’échec du projet sur le fonctionnement de l’entreprise. ... pour la planification • Coûts imprévisibles pour le projet, • Retards dans la livraison des produits. 4 Extrait de La Lettre de l’ADELI N°22 - Janvier 1996 ... pour le suivi • Accroissement des coûts du projet, • Défaut de participation des acteurs, • Déficiences des tâches exécutées à l’extérieur, • Evolution des exigences. Liste des facteurs situationnels, générateurs d’incertitude... ... dus au système d’information final • Attitude hostile des utilisateurs, • Faible compétence des utilisateurs, • Instabilité de l’environnement, • Défaut de formalisation des informations, • Défaut de formalisation des processus, • Instabilité des informations et des processus, • Caractère trop spécifique du système, • Incompréhension des spécifications, • Importance stratégique excessive, • Lourdeur des changements organisationnels, • Indisponibilité, confusion, instabilité des exigences. ... dus au système informatique • Importance des changements technologiques, • Nouveauté de la technologie cible. ... dus à la technologie du projet • Innovation technique, • Indisponibilité technique. ... dus à la planification • Nouveauté de l’adaptation, • Délais tendus, • Budget serré. ... dus à la structure du projet • Incompétence de l’équipe projet, • Dépendance de la sous-traitance, • Dépendance d’autres adaptations du système d’information, • Flou du contexte client-fournisseur. 5 - Les causes de dérive des projets, vues du côté de la maîtrise d’œuvre Extension des limites du projet au fur et à mesure de sa réalisation Lorsque les limites du projet n’ont pas été correctement fixées, des tendances d’extensions continuelles se manifestent sans que l’on puisse les écarter, faute d’avoir définies des frontières contractuelles claires et précises. Dans un contexte commercial, le flou est toujours interprété à l’avantage du client. Extrait de La Lettre de l’ADELI N°22 - Janvier 1996 5 Déficience du maître d’ouvrage Un maître d’ouvrage qui ne joue pas son rôle constitue un risque majeur pour l’ensemble du projet. En effet, le maître d’ouvrage est responsable de la définition des besoins fonctionnels. Il doit arbitrer entre les utilisateurs et choisir les options souhaitables et possibles. Un maître d’ouvrage qui ne met pas en jeu sa carrière sur son projet n’est peut être pas un maître d’ouvrage motivé. Absence de motivation des développeurs La gestion quantitative des ressources ne dispense pas d’intégrer les facteurs humains dans la conduite de projet. Le maître d’œuvre doit, en permanence, motiver son équipe, si possible en prêchant par l’exemple. Innovations technologiques Il est bien évident que la prise en compte, dans un projet, de technologies innovantes et peu maîtrisées est un risque difficile à évaluer. Il faut garantir que les aides (formations, assistances) promises par le fournisseur de la technologie seront tenues. Divers autres risques Ainsi, les principaux risques ne sont pas liés à l’établissement du planning ni à la tenue d’un cycle de réunion. Ils découlent essentiellement de problèmes humains : • Instabilité de l’équipe au cours du projet tant du côté client que du côté fournisseur, • Dilution des responsabilités dans des équipes trop nombreuses, • Changement d’orientations au cours du projet, • Démotivation par absence de reconnaissance des contributions, • Mauvaise répartition des moyens. En conclusion Un groupe de travail du Mouvement Français pour la Qualité (MFQ), auquel participent plusieurs adhérents de l’ADELI, élabore un document sur « La gestion du risque dans les projets logiciels ». Ce document : • proposera une synthèse sur le concept de risque, • indiquera une démarche de maîtrise des risques, • présentera les outils logiciels d’aide à la gestion du risque. Dans l’attente de cette publication, nous vous avons soumis cette première série de réflexions. L Alain Coulon uploads/Ingenierie_Lourd/ les-risques-d-x27-un-projet.pdf