Organigramme du processus de gestion des risques du projet (enregistrement…

Organigramme du processus de gestion des risques du projet : enregistrez le risque, évaluez la probabilité et l'impact, faites remonter le problème, choisissez une réponse, examinez-la et fermez-la ou soulevez un problème.

Utiliser ce modèle

Qu'est-ce que le processus organigramme du processus de gestion des risques du projet (enregistrement… ?

La plupart des registres des risques du projet sont rédigés une seule fois et ne sont jamais lus. Ils sont remplis dans un atelier lors de l'initiation, notés, acceptés, puis rouverts uniquement lorsque quelqu'un a besoin d'une diapositive avant le groupe de pilotage suivant. À ce stade, la moitié des entrées décrivent une phase déjà terminée et le risque qui nuise réellement au projet n'a jamais été là du tout. Ce qui fait fonctionner un processus de gestion des risques d’un projet, ce n’est pas la méthode de notation. C'est la boucle : chaque risque ouvert revient à une cadence fixe et change, se matérialise ou se ferme.

Cette page représente le cycle au niveau du projet, réparti sur cinq voies et cinq phases. Il ne s'agit pas de la méthode d'évaluation des risques organisationnels : les critères, les échelles de probabilité et d'impact, la notation inhérente par rapport à la notation résiduelle et l'efficacité du contrôle appartiennent à l'organigramme du processus d'évaluation des risques de /fr/templates/organigramme-du-processus-d-evaluation-des-risques, et ce tableau suppose que ces échelles existent déjà et les applique simplement. Il ne s'agit pas non plus d'un test de routage pour un risque : si la question est de savoir quel organisme doit détenir un risque particulier, l'arbre de décision d'escalade des risques de /fr/templates/modele-d-arbre-de-decision-en-matiere-d-escalade-des-risques traite cela de manière beaucoup plus détaillée que la décision à seuil unique ici, et qui est autorisé à approuver le port d'un risque est déterminé par l'organigramme de décision d'acceptation des risques de /fr/templates/organigramme-de-decision-d-acceptation-des-risques. Ce graphique s'arrête également au moment où un risque devient réel : à partir de là, le journal des problèmes prend le relais et la perturbation en direct est transmise au processus de gestion des incidents chez /fr/templates/organigramme-du-processus-de-gestion-des-incidents.

Deux choses que la plupart des procédures de risque de projet laissent implicites sont soulignées explicitement. Le seuil d'escalade est une décision à laquelle le chef de projet répond avant que la réponse ne soit choisie, et non après que l'atténuation ait été chiffrée, de sorte que des risques graves atteignent le groupe de pilotage alors qu'il y a encore un mandat et un budget à disposer. Et "Risque **matérialisé ?**" est une véritable branche : un risque qui s'est produit n'est plus un risque, il est donc soulevé comme un problème de projet et l'inscription au registre se clôture comme matérialisée plutôt que d'être réévaluée mois après mois. Tout entre la réponse et la clôture est une boucle : « Le risque est-il toujours présent ? » renvoie les risques ouverts pour réévaluation, et seul un risque dont la fenêtre est dépassée atteint la clôture et la leçon qui alimente le prochain cycle d'identification.

Ce que couvre cet organigramme

Dans ce modèle

  • Cinq couloirs (équipe de projet, propriétaire du risque, chef de projet, groupe de pilotage, PMO) répartis en cinq phases : identification, évaluation, réponse, surveillance et clôture.
  • Identification à partir de n'importe quelle source dans un seul registre : le risque est soulevé, enregistré avec sa cause et son effet, et un propriétaire du risque nommé l'accepte avant que quoi que ce soit ne soit noté.
  • « Au-dessus du seuil d'escalade ? répondu par le chef de projet. Itinéraires ci-dessus vers le groupe de pilotage pour examiner le risque accru et convenir du mandat et du budget de la réponse ; Ci-dessous, nous passons directement à la planification de la réponse.
  • Un quadrilatère « Quelle stratégie de réponse ? » (Éviter, Réduire, Transférer, Accepter) où éviter, réduire et transférer convergent vers "Attribuer des actions avec des propriétaires et des dates", et accepter va directement à la surveillance sans rien faire d'autre que de la regarder.
  • La boucle de suivi : « Réévaluer le risque à chaque revue » alimentant « Risque matérialisé ? puis "Le risque est-il toujours présent ?", dont la branche Live renvoie le risque à la prochaine révision plutôt que hors du processus.
  • Deux points de terminaison au lieu d'un. Un risque matérialisé est signalé comme un problème de projet et laisse à « Géré via le journal des problèmes » ; un risque dont la fenêtre est passée est clôturé dans le registre par le PMO et se termine par « Risque clôturé et leçons captées ».

Quand utiliser ce modèle

  • Vous rédigez la section des risques d'un plan de gestion de projet et vous avez besoin d'une image de qui identifie, qui possède, qui escalade et qui clôture.
  • Votre registre contient des entrées qui n'ont pas bougé depuis des mois, et vous avez besoin que la boucle de révision et le test de clôture soient intégrés au processus plutôt que laissés à celui qui prépare le dossier du tableau.
  • Les risques et les problèmes sont enregistrés dans la même liste, et vous souhaitez que le point de conversion et le transfert vers le journal des problèmes soient dessinés plutôt que supposés.
  • Le groupe de pilotage continue de recevoir des risques trop tard pour changer quoi que ce soit, et vous avez besoin que la décision d'escalade soit prise avant la planification de la réponse plutôt qu'après.
  • Vous intégrez des chefs de projet ou des responsables de flux de travail et souhaitez l'appropriation, le seuil d'escalade et les quatre réponses enseignées à partir d'un seul diagramme.

Comment cela fonctionne

  1. Renommez les voies selon votre gouvernance

    Remplacez l'équipe de projet, le propriétaire du risque, le chef de projet, le groupe de pilotage et le PMO par les rôles et les organes dont vous disposez réellement. Séparez le propriétaire du risque du chef de projet : l’un porte le risque, l’autre gère le processus. S'il n'y a pas de PMO, fusionnez cette voie avec le chef de projet plutôt que de laisser un corps dans le graphique qui ne fait jamais rien, et si votre groupe de pilotage et votre sponsor sont la même personne, dites-le.

  2. Écrivez le seuil d'escalade sous forme de chiffres

    « Au-dessus du seuil d'escalade ? est inerte jusqu'à ce que vous attachiez des chiffres. La plupart des projets fixent un chiffre de coût lié à la limite de dépenses déléguée par le chef de projet et un chiffre de calendrier lié au flottant ou à un jalon contractuel, puis traitent celui qui est dépassé en premier comme déclencheur. Ajoutez un itinéraire qui ignore entièrement le score en matière d'exposition en matière de sécurité, juridique, réglementaire ou de réputation, car ceux-ci dépendent de leur nature plutôt que de leur note.

  3. Définir les champs obligatoires du registre

    Décidez ce que « Enregistrer le risque dans le registre » doit capturer : la cause, l'événement et l'effet dans des champs distincts, la date d'apparition, le propriétaire proposé, le lot de travaux ou le jalon concerné, la probabilité et l'impact avec la date à laquelle ils ont été notés, la réponse choisie, les actions avec les dates et l'état actuel. Tout ce qui reste facultatif sera vide dans un délai d’un mois, et un risque écrit en trois mots ne pourra être réévalué par quiconque n’était pas présent dans la salle.

  4. Corriger la cadence de révision et les déclencheurs hors cycle

    La boucle ne tourne que s'il y a une révision programmée. Attachez-le au rythme de reporting existant du projet plutôt que d'inventer une nouvelle réunion, examinez les risques les plus élevés plus souvent que les autres et nommez les événements qui entraînent une réévaluation : un changement de fournisseur, un jalon manqué, une nouvelle dépendance, un changement de périmètre, un incident ou un dérapage d'action d'atténuation. Un registre touché seulement avant le pack du conseil est exact un jour par mois.

  5. Rendre les actions d’atténuation réelles

    « Attribuer des actions avec des propriétaires et des dates » signifie une personne nommée par action, une date d'échéance et une ligne dans le plan de projet contenant l'effort. Les actions qui ne figurent que dans le registre des risques entrent en concurrence avec le travail sur lequel tout le monde est évalué et perdent. Suivez-les là où l'équipe les regarde déjà et laissez le propriétaire du risque rendre compte des progrès réalisés lors de l'examen plutôt que de signaler que le risque est inchangé.

  6. Acceptez la règle de risque de problème, puis publiez une version

    Définissez ce qui compte comme matérialisé, qui peut le déclarer sans attendre une réunion et comment la référence croisée est transmise dans les deux sens afin que l'histoire survive à la conversion. Ensuite, parcourez le graphique terminé avec le chef de projet, un responsable du risque et celui qui préside le groupe de pilotage, corrigez-le en fonction de ce qu'ils font réellement et publiez cette révision tout en conservant les précédentes, afin que toute personne l'ouvrant plus tard puisse savoir quelle version elle lis.

Questions fréquentes

Quelles sont les étapes d’un processus de gestion des risques d’un projet ?

Identifiez le risque, enregistrez-le dans le registre avec sa cause et son effet, demandez à un propriétaire nommé de l'accepter, évaluez la probabilité et l'impact, décidez s'il dépasse le seuil d'escalade, choisissez une réponse parmi éviter, réduire, transférer et accepter, attribuez des actions d'atténuation avec des propriétaires et des dates, réévaluez-le à chaque examen, convertissez-le en problème s'il se produit et fermez-le une fois sa fenêtre passée. Les méthodes utilisent un vocabulaire différent pour la même colonne vertébrale : PRINCE2 décrit une procédure de gestion des risques allant de l'identification et de l'évaluation à la planification et à la mise en œuvre des réponses, avec une communication parallèle, et les éditions précédentes basées sur les processus du Guide PMBOK séparaient la planification d'une réponse de sa mise en œuvre et de son suivi. La partie qui échoue dans la pratique est rarement la liste. C'est le retour à la réévaluation.

Quelle est la différence entre un risque et un problème ?

Un risque est incertain : il peut se produire ou non, il est donc décrit comme une cause, un événement et un effet et comporte une probabilité. Un problème est déjà survenu ou est désormais certain. Ils sont gérés différemment, c’est pourquoi la distinction mérite d’être renforcée. Un risque fait l’objet d’une stratégie de réponse et d’actions d’atténuation avant l’événement ; un problème est confiné, un plan de rétablissement et souvent une demande de changement pour le temps ou l'argent qu'il consomme. Garder les deux dans une seule liste remplit le registre de choses qui ne peuvent plus être atténuées et enterre les éléments véritablement incertains. Dans ce graphique, la conversion est une branche explicite : « Risque matérialisé ? » soulève un problème de projet, l'entrée du registre se ferme comme matérialisée et la référence croisée est transmise dans les deux sens.

Quelles sont les quatre stratégies de réponse aux risques ?

Évitez, réduisez, transférez et acceptez. Éviter supprime la cause, généralement en modifiant la portée, la séquence ou l'approche, et c'est la seule qui élimine le risque du registre plutôt que de le réduire. Réduire réduit la probabilité, l’impact ou les deux, et c’est là que la plupart des mesures d’atténuation aboutissent. Le transfert des conséquences à une autre partie via un contrat à prix fixe, une clause de responsabilité ou une assurance, et c'est l'option la plus souvent surestimée : il déplace généralement les conséquences financières et laisse les conséquences de la livraison au projet. Accepter signifie supporter le risque en connaissance de cause, avec un approbateur nommé, une provision pour imprévus et une date de révision : un risque que personne n'a financé n'est pas un risque accepté. Si votre méthode traite les opportunités comme un risque positif, elles ont des réponses miroir : exploiter, améliorer, partager et accepter.

Qui doit assumer un risque sur un projet ?

Une personne nommée, suffisamment proche de la cause pour remarquer son changement et suffisamment expérimentée pour faire quelque chose. Dans la pratique, il s'agit généralement d'un responsable du flux de travail, d'un responsable technique ou d'un fournisseur plutôt que du chef de projet, qui est propriétaire du processus plutôt que de chaque entrée. Deux modèles sont à l'origine de la plupart des problèmes : la propriété attribuée à une équipe ou à un service, où personne ne la réévalue parce que personne en particulier n'a été invité à le faire, et chaque risque appartient au chef de projet, qui transforme le registre en une liste de tâches personnelle qui cesse d'être notée. Ce tableau fait de « Accepter la propriété du risque » une étape à part entière avant l'évaluation, car un propriétaire qui n'a jamais accepté de l'être ne se présentera pas à l'évaluation.

En quoi est-ce différent d’un organigramme de processus d’évaluation des risques ?

Ils couvrent des domaines différents. Un organigramme du processus d'évaluation des risques est la méthode : comment les critères et les échelles sont convenus, comment les risques sont décrits, comment les scores inhérents et résiduels sont produits, comment l'efficacité des contrôles existants est jugée et comment un traitement est sélectionné. Il est rédigé une seule fois et s’applique à toute l’organisation. Cette page est le cycle opérationnel au niveau du projet qui consomme ces échelles (soulever, enregistrer, posséder, évaluer, faire remonter, répondre, agir, réviser, convertir ou clôturer) pendant la durée de vie d'un projet, avec un groupe de pilotage, un PMO et un journal des problèmes. Si vous définissez la manière dont les risques sont notés, utilisez le modèle de processus d'évaluation des risques. Si vous définissez la façon dont votre projet gère son registre de semaine en semaine, utilisez celui-ci.

Fait partie de

Fonctionnalités QueryChart pour ce processus

Utiliser ce modèle

Browse all Modèles de gestion de projet