MIAGE MASTER 1 Cours de gestion de projet

1. MIAGE MASTER 1Cours de gestion de projet Session 9 : Risques – Assurance Qualité

2. Sommaire • La gestion des risques • Manager par la qualité

3. Gestion des risques

4. Principes • Les risques ? Quels risques ?

5. Principes… • Deux manière de piloter un projet : • Par les délais et les livrables : garantie de livrer quelque chose… mais pour quoi faire ? • Par les risques : voir le projet dans son ensemble et stratégie gagnant-gagnant avec le client • En pratique : • tenue de plusieurs indicateurs de risque tout au long du projet, permettant de remonter les contraintes et les alertes au plus tôt • pas de rétro-planification, ayant toujours comme conséquence le sacrifice des phases de tests et de qualification • La mise en œuvre pratique passe par la définition de fiches de risques et de tableau de suivi des risques.

6. Principes… Tout projet doit faire l’objet d’évaluations des risques : En avant-vente (par le responsable de la réponse) identifier les risques aider au GO-NOGO élaborer un plan d’action Au démarrage du projet (par le CP) réévaluer les risques mettre à jour le plan d’action En cours de projet (par le CP) réévaluer les risques mesurer l’avancement du plan d’action et son efficacité

7. Etape 1 : Profil de risque • L’origine des risques pouvant peser sur une situation de projet est variée. Six facteurs jouent cependant un rôle déterminant • La taille du projet : grand projet  large étendue du domaine couvert, qui impose une division du travail, donc un nombre important de personnes. Absence d’un dispositif => perte de la maîtrise du processus de production. • La difficulté technique : N’est pas la cause principale des échecs de projets, mais facteur de risque important. Les difficultés techniques sont généralement dues à un manque de compétences sur un sujet nouveau ou à des problèmes de performance du système. • Le degré d’intégration : Il agit sur la complexité du projet puisqu’il mesure le degré de dépendance ou d’autonomie du futur système. L’intégration peut se voir en interne par rapport au projet développé, mais aussi en externe par rapport à d’autres applications, ce qui multiplie les contraintes et le nombre total d’acteurs du projet global.

8. Etape 1 : Profil de risque • Suite des facteurs : • La configuration organisationnelle : correspond à l’ampleur de l’entreprise 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 sont parties prenantes du projet. Pb des conflits qui bloquent les prises de décision. • Le changement : Les systèmes de gestion et/ou d’organisation peuvent ne pas avoir été clairement compris comme référence stable et que l’effort de conception / innovation va être important. Les risques de rejet ou de mauvaise définition du futur système sont élevés. • L’instabilité de l’équipe de projet : Pose le problème du transfert des connaissances. Lors des modifications de l’équipe, la connaissance implicite accumulée est à reconstituer et les erreurs d’interprétation peuvent avoir des conséquences sur les délais et sur la cohérence de conception.

9. Etape 1 : résultat

10. Etape 2 : les facteurs de risque du projet • Les risques « incompressibles » doivent être regroupés par domaine. Pour chaque risque identifié, une solution doit être envisagée afin d’y faire face. • Afin de pouvoir les anticiper, il est indispensable de les recenser • Exemple :

11. Etape 2 : les facteurs de risque du projet • Exemple (suite) :

12. Le niveau de risque d’un indicateur • Chaque indicateur de risque fait l’objet d’une double évaluation : • Probabilité d’occurrence : • 0 : Aucun (non réaliste) • 1 : Peu probable (0-20%) • 2 (20-40%) ; 3 (40-60%) ; 4 (60-80%) • 5 : quasi certain (80-100%) • Niveau de gravité (impact) : • 0 : aucun impact (pourquoi l’identifier ??) • 1 : impact mineur (ne bloque pas l’application) • 2 : gênante : bloque une partie des fonctionnalités mais problème contournable • 3 : grave : problème grave nécessitant un plan d’action important • 4 : bloquant : problème important qui causera des dérapages du projet • 5 : critique : peut causer l’arrêt du projet

13. Etape 3 : les outils de suivi • Au démarrage du projet, on crée autant de fiches de risques que de facteurs de risques identifiés ci avant. • Dès lors qu'une difficulté sera soulevée lors de la réalisation du projet, une nouvelle fiche de risque sera mise en place jusqu'au règlement du problème. • Ces fiches de risques permettront : • de mettre "à plat" un problème et de lancer des actions qui permettront de le résoudre. Le cas échéant, une petite étude peut proposer des solutions et argumenter le bien-fondé de la solution retenue • d'historiser l'avancement dans la résolution du problème en spécifiant des réunions d'avancement planifiées et un responsable de l'aboutissement de l'étude. Le but est d'arriver à terme à une résolution satisfaisante pour toutes les parties.

14. Etape 3 : les outils de suivi Les actions à mettre en œuvre portent sur les facteurs de risque pour en réduire la probabilité de survenue Action de « réduction » des causes pour en réduire l’impact en cas de survenue Action de « contingence » des conséquences pour en accroître la détectabilité Action de « détection » de la survenue du risque Pour chaque action il faut estimer un coût de mise en œuvre (en équivalent j.h) pour comparer les coûts d’impact du risque avec les montants à engager pour réduire ce risque

15. Etape 3 : les outils de suivi • A chaque comité de pilotage ou comité de suivi, on effectue un état des lieux des fiches de risque encore ouvertes. • Cette démarche est importante, car elle permet de faire participer tous les acteurs du projet aux tâches sensibles de celui-ci, et ainsi évoluer vers une résolution qui sera satisfaisante à la fois du point de vue technique, fonctionnel et organisationnel. • Le coût et le temps pris pour la tenue d'un tel dossier de risque sont sans commune mesure avec ceux d'un risque non maîtrisé. • Les fiches, pour être efficaces, doivent tenir sur un format A4, en ayant recours à des pièces jointes. • En annexes de chaque fiche, on donne, à chaque révision, le nouvel état de gravité du problème, l'état des travaux et les plans d'action à mettre en œuvre. • Ces fiches sont résumées dans un tableau de bord de suivi des risques

16. Exemple de fiche de risque (partie 1)

17. Exemple de fiche de risque (partie 2)

18. Exemple 1

19. Exemple 1

20. Exemple 2

21. Exemple 2

22. Exemple 2

23. Exemple Exemple : Le risque d’inondation d’une île de l’océan indien Facteur : Tsunami on ne peut pas agir sur la probabilité qui est faible mais pas nulle on va lancer des actions de contingence qui vont être limitées car phénomène rapide information population sur conduite à tenir on va lancer des actions de détection réseau de surveillance sismique information population sur l’observation de phénomène anormaux Facteur : Elévation du niveau des océans on peut agir sur la probabilité : réduction des causes de la fonte des calottes glaciaires on peut agir sur la contingence car phénomène lent construction de digues déplacement des populations menacées on va lancer des actions de détection réseau de mesure du niveau des océans et analyse statistique mise en place locale de point de mesure

24. Exemple Exemple : Le risque d’avalanche dans une station de ski Facteur : météo on ne peut pas agir sur la réduction on peut agir sur la contingence mur anti avalanche plan d’évacuation en cas de danger déclenchements préventifs on doit agir sur la détectabilité analyse régulière des couches de neiges Facteur : les skieurs hors piste on peut agir sur la réduction information sur le danger mesures d’interdiction on peut agir sur la contingence idem facteur météo on ne traite pas de la sécurité des skieurs hors piste. C’est un autre risque

25. ESCALADE L’escalade consiste à informer voire impliquer des niveaux hiérarchiques de plus en plus élevés en fonction de l’impact des risques identifiés ou des constats sur le projet. par devoir d’information pour la prise de décision allant au-delà des habilitations du Chef de projet Escalade en fonction de l’impact d’un facteur de risque ou d’une situation plus les impacts sont importants plus la hiérarchie doit être impliquée car : les budgets peuvent être important des décisions ne sont plus du ressort d’un CP Niveau Impact Commentaire Escalade Communication 1 Pas de conséquence Coût délai périmètre inchangé Pas d’escalade Pas de communication Conséquences limitées 2 Coût délai périmètre restent dans les hypothèses basses Escalade DP ou Directeur d’unité Au moins un indicateur de risque à orange dans le reporting projet 3 Conséquence sensible Coût délai périmètre impactés Escalade Directeur d’unité Projetsensible (rouge) dans le reporting projet 4 Conséquence critique Arrêt du projet, impact au-delà du projet et/ou perte du client Escalade DIG-DQG-Juridique Projet sensible au comité des risques

26. Bilan • Efficacité de la méthode ? • Pour être efficace, il faut qu’elle soit globale (prestataire + client) : attention aux tabous… • Si nécessité d’efficacité des intervenants clients • Si identification de tensions client entre services ou entre personnes •  Orienter la description des risques et les moyens de contournement de manière consensuelle • Associer à la conduite du changement • Doit servir de levier pour communiquer efficacement et faire prendre conscience des problèmes potentiels •  Support au rôle de conseil

27. Assurance QualitéPrincipes

28. Evolution des approches de qualité • Les enjeux de la qualité s’articulent autour des thèmes que sont la compétitivité, l’amélioration des ressources humaines et l’évolution culturelle. La qualité est devenue le centre stratégique de chaque entreprise. • Evolution des approches de la qualité :

29. Qualité : démarche • Qualité par l’inspection : coût élevé, ne permet pas de diminuer sensiblement les défaillances. • Qualité par le contrôle des processus (lancée par DEMING & JURAN) contribue à anticiper les défauts. Cette appréhension de la qualité fut une première étape d’amélioration transversale des projets complexes. • Par la suite fut introduit la criticité du défaut (indice de sévérité, probabilité d’occurrence, probabilité de détection  prémisses de l’anticipation des risques  amélioration de la qualité. • Les systèmes ISO de management de la qualité : formalisent le système de référencement de la qualité et proposent une attention toute particulière sur l’organisation. • L’objectif est de satisfaire le client en s’appuyant sur un management cohérent, gage d’une entreprise de qualité et donc d’une prestation de qualité.

30. Management par la qualité : les 10 process principaux • Stratégie : objectifs et intégration du projet dans le fonctionnement de l’entreprise • Coordination : processus d’intégration qui concernent chaque phase du projet (développement, réalisation, modifications, clôture) • Périmètre du projet : assurer le résultat correspondant aux attentes des parties prenantes (spécifications, définition des tâches, maîtrise des activités). • Management des délais : enclenchement des tâches, estimation des durées, ordonnancement des tâches et maîtrise du planning • Management des ressources et des coûts : planification des ressources, estimation des coûts élémentaires, établissement du budget, maîtrise des coûts. • Management de la qualité : planification, assurance de la qualité et maîtrise. • Ressources humaines : organiser le projet en explicitant les responsabilités avec une maturation progressive de l’équipe projet • Communication : rédaction, collecte, diffusion, traitement et archivage des informations nécessaires aux acteurs du projet • Management des risques de projet : à chaque phase, effectuer une identification, quantification, prise en compte, documentation et maîtrise des réponses aux risques

31. Qualité et informatique • Enjeux de la qualité informatique • L’informatique devenant un outil de différenciation compétitive, la qualité des applications représente à la fois un enjeu commercial et économique. • L’utilisation de méthodes et outils industriels permet de garantir la qualité des applications et de réduire les coûts liés à des opérations à faible valeur ajoutée. • Qualité des applications • La croissance des applications informatiques orientées client (Web, front-office automatisés,…) fait apparaître de nouveaux critères de qualité, comme la disponibilité du service, la rapidité de consultation, la sécurité des données, la simplicité d’utilisation, la rapidité d’exécution.

32. Qualité et informatique • Qualité du processus de fabrication • Les applications en prise directe avec le client - Web, front office - doivent pouvoir être adaptées très rapidement à l’évolution des demandes des clients. • Qualité du processus de recette • La recette doit être organisée de façon à vérifier le respect des exigences du client. La qualité du processus de recette (dite aussi qualification) conditionne celle des produits informatiques livrés. • Nécessité d’industrialiser la phase de recette : absence de méthodes et d’outils  tests à exécuter et à analyser manuellement  risque de ne pas détecter des erreurs est élevé  coût pour le client. • Le coût et le délai de la phase de recette représentent des problèmes cruciaux, d’autant que ces phases sont souvent « sacrifiées » pour garantir la fin du projet.

33. Assurance QualitéEn pratique…

34. Comment mettre en place l’Assurance Qualité • L’Assurance Qualité vient en complément d’une démarche de pilotage classique • En plus des outils de suivi de projet classiques (tableau de bord d’avancement, suivi des livrables, gestion des comités projets, …), l’Assurance Qualité est basée sur : • Un Plan d’Assurance Qualité : documentation des procédures à mettre en place dans le projet : souvent réalisé, peu contraignant • Eventuellement, une liste d’objectifs qualité mesurables (SLA): plus contraignant, mais peu d’impact s’ils ne sont pas régulièrement évalués • Eventuellement, la conduite d’audits qualité : permettent un suivi fin des objectifs, mais rarement déclenché (temps passé à l’audit est payé par le client)

35. Les trois parties du PAQ

36. Le Plan d’Assurance Qualité • Le plan d'assurance qualité est un document énonçant les pratiques, les moyens et la séquence des activités liées à la qualité spécifiques à un produit, un projet ou un contrat particulier (Extrait de la norme ISO 8402:1994). • Buts : • homogénéiser et d'assurer une cohérence dans les pratiques des projets • améliorer la qualité des produits • optimiser les méthodes de travail • de capitaliser et partager les expériences. •  Pour être efficace, l’Assurance Qualité du projet doit être en accord avec les principes d’Assurance Qualité du client.

37. Le Plan d’Assurance Qualité • Les deux niveaux de l’Assurance Qualité : • niveau référentiel : il s'agit des procédures, plans types et guides méthodologiques communs à la DSI ; ces documents sont regroupées dans le site de conduite de projet de la DSI ; (document nommé PAQ client ou Manuel d’Assurance Qualité) • niveau spécifique : il s'agit de l'application de ces procédures de manière spécifique dans chaque projet ; ces dispositions font l'objet d'un Plan Qualité Projet (PQP) par projet.  C’est un document contractuel dans la relation client - prestataire • En pratique, et par abus de langage, on réalise un PAQ par projet, et peu de clients disposent de leurs normes internes d’Assurance Qualité

38. Le Plan d’Assurance Qualité • Principes d’élaboration • Le PAQ s'élabore lors de l’initialisation du projet. • Dans la pratique, il importe de se limiter aux dispositions les plus pertinentes pour le projet considéré et de veiller à la facilité d'utilisation du PAQ. Il doit rester un document synthétique. • Après validation par le chef de projet et le responsable qualité de la DSI, le PAQ peut être diffusé à toutes les parties prenantes (Maîtrise d'ouvrage, Maîtrise d'œuvre, équipes projets…) pour application. • Le PAQ peut être remis à jour à chaque étape d'avancement du projet. Dans ce cas, il sera soumis à l'acceptation des interlocuteurs les plus directement concernés. • Remarque : Citer un document applicable implique que le responsable qualité contrôlera son application pendant le projet.

39. Exemple de PAQ • Source : CNRS : http://www.dsi.cnrs.fr/conduite-projet/phasedeveloppement/qualite/pacq/basdevqual.htm • 1. OBJET ET CARACTERISTIQUES DU PLAN D'ASSURANCE ET CONTROLE QUALITE • 1.1 OBJECTIFS DU PLAN • Définir les objectifs du document • 1.2 DOMAINE D'APPLICATION • Projet, Système d’information, marché, domaine métier, … • 1.3 RESPONSABILITES DE REALISATION ET DE SUIVI DU PLAN • Qui crée le PAQ, qui le met à jour, qui contrôle • 1.4 DOCUMENTS APPLICABLES ET DOCUMENTS DE REFERENCE • 1.4.1 Documents applicables : Documents contractuels • 1.4.2 Documents de référence : Guides méthodologiques, manuels de développement, plans de nommage, … • 1.5 CRITERES ET PROCEDURE D'EVOLUTION DU PACQ • Ce qui justifie une évolution du PAQ, comment appliquer une évolution de PAQ • 1.6 PROCEDURE DE DEROGATION AU PACQ • Peut on déroger au PAQ ? Si oui, faut il mettre à jour ? Qui valide la dérogation ? • 2. TERMINOLOGIE • 2.1 GLOSSAIRE DES TERMES • Termes métier • 2.2 ABREVIATIONS • Abréviations et acronymes

40. Exemple de PAQ • 3. SYSTEME QUALITE MIS EN ŒUVRE POUR LE PROJET • 3.1 OBJECTIFS ET ENGAGEMENTS QUALITE DU PROJET • Objectifs propres au projet, établis par le client • 3.2 MESURE DE LA QUALITE (PROPRIETES ET METRIQUES) • Liste des critères qualité, échelle de valeur, niveau à atteindre (voir suite) • 3.3 DOCUMENTATION QUALITE DU PROJET • Types de documents gérés au titre de l’Assurance Qualité : PAQ, Procédures, Guides méthodologiques, Plans types • 3.4 ACTIVITES D'ASSURANCE ET DE CONTROLE DE LA QUALITE • Chaque membre de l'équipe projet est tenu de respecter les dispositions décrites dans le PACQ et de vérifier l'adéquation du produit (document ou code) avec les normes en vigueur sur le projet (Autocontrôle). • Les activités du responsable assurance qualité projet se déroulent tout au long du projet. Elles sont de deux types : • les activités d'assurance qualité qui permettent de définir au plus tôt les principes qualités du projet et d'anticiper d'éventuels problèmes. Ces activités sont importantes au début du projet et dans une moindre importance au début des phases. • les contrôles qualité qui vérifient régulièrement que les procédures sont comprises et correctement appliquées. En cas de non-conformités réelles ou potentielles, il propose des actions correctives ou préventives. Il est chargé ensuite de suivre le déroulement de ces recommandations. • Exemples : • Assurance qualité • Elaboration du PACQ • Interface avec la cellule qualité de la DSI • Participe aux revues internes DSI (revues de fin de phases) • Information de l'équipe projet sur les procédures en vigueur • Contrôle qualité • Relecture des documents projet • Contrôle de la bonne application des procédures applicables • Réalisation d'audits de contrôle (bilan qualité et revue qualité fournisseur) • Suivi des actions correctives ou préventives • 3.5 DOCUMENTS RELATIFS A LA QUALITE DU PROJET • Destinataires de chaque type de document

41. Exemple de PAQ • 4. CONDUITE DE PROJET • 4.1 ORGANISATION DU PROJET • Organigramme des missions assurées au sein du projet (liens hiérarchiques et fonctionnels) • Description des rôles et responsabilités : chef de projet, adjoint, responsable d'équipe, ... • 4.2 PRESENTATION DES ACTIVITES COUVERTES PAR LE PROJET • Organigramme des différentes activités qui sont nécessaires au projet (ex : PBS) • 4.3 PLANIFICATION ET SUIVI DU PROJET • Définit l’interlocuteur privilégié du client ainsi que les comités projet nécessaires (pilotage, suivi, groupes de travail), … • 5. DEMARCHE DE DEVELOPPEMENT DU SYSTEME D'INFORMATION • 5.1 CYCLE DE DEVELOPPEMENT • Méthode appliquée : V, W, RAD, Agile, … • 5.2 DESCRIPTION DES ETAPES • En fonction de la méthode : définition des étapes ou des itérations • 6. GESTION DE LA DOCUMENTATION • 6.2 IDENTIFICATION DE LA DOCUMENTATION • Normalisation du codage des documents • Principe de versionning majeur/mineur • 6.3 SAUVEGARDE ET ARCHIVAGE • Structure des dossiers de sauvegarde, droit d'accès, périodicité, procédure d'archivage.

42. Exemple de PAQ • 7. GESTION DE LA CONFIGURATION LOGICIELLE • 7.1 RESPONSABILITES • Qui est responsable de la GCL ? Lien avec les développeurs ? Synchro client ? • 7.2 IDENTIFICATION DES ELEMENTS • liste des composants logiciels de l'application, des moyens de développement et de tests, • règles de constitution des identifiants, • liaisons entre les différents éléments. • 7.3 CYCLE DE VIE ET ETATS DES ELEMENTS • méthodes de gestion des versions, révisions, • modalités de vérification et de validation. • 7.4 SAUVEGARDE ET ARCHIVAGE • Procédure de sauvegarde et de restauration • 8. GESTION DES MODIFICATIONS • Identifier ce qui relève du correctif (inclus dans la prestation) de l’évolutif (bons de commande supplémentaires) • Evolutif : fonctionnel, adaptatif, performances • Délais de prise en compte des modifications, notamment correctives : selon le niveau de gravité • 9. CONTROLE DES FOURNISSEURS • 9.1 DOCUMENTS DE LIAISON • Liste des documents : Compte Rendu de Comité, Fiche de liaison, Demande d'intervention, Procès verbal de réception, PV de recette. Identification des procédures associées (déclenchement, tâche associée, émetteur, destinataires, engagements, …) • 9.2 DESCRIPTION DES DOCUMENTS • Modèles de ces documents

43. Critères de qualité standards • Exemples de critères qualité :

44. Exemples de métriques associées aux critères

45. Exemple 1 • Identification des alertes qualité

46. Exemple 2 : partie analytique

47. Exemple 2 : partie graphique • Vue instantanée : permet le positionnement par rapport aux objectifs mini/maxi • Vue historisée