Comment aligner la gestion des risques avec la réalité opérationnelle du projet ?

Un réseau d'exigences est raffiné sous forme de graphe. Les exigences sont affectées aux livrables. Ces derniers les documentent. Qinaps construit automatiquement un reporting partagé.
Un registre des risques, c'est bien, mais comment ne pas faire deux fois le travail d'analyse et de reporting ? Comment ne pas lasser les équipes avec des revues redondantes ? Qinaps est une solution SaaS de traçabilité des exigences qui se prête particulièrement bien à cet exercice.

🤔 Comment aligner la gestion des risques avec la réalité opérationnelle du projet ?

Un registre des risques, c’est bien, mais comment ne pas faire deux fois le travail d’analyse et de reporting ?  Comment ne pas lasser les équipes avec des revues redondantes ?

Le registre des risques d’un projet et son avancement sont certes deux objets distincts.  Le registre des risques est « descendant », de l’environnement vers l’état du projet, alors que l’avancement est « montant », des actions vers l’état du projet.  Le premier est fondé sur des aléas, le second sur des actions.

Mais à moins d’être fataliste, les deux objets se rencontrent au niveau des actions décidées en regard des aléas :

  • actions de prévention (éviter qu’il survienne),
  • actions de minimisation (minimiser l’impact s’il survient),
  • actions de réparation (restaurer un état acceptable à partir de l’impact éventuellement minimisé)

Si l’on considère un risque comme l’exigence d’éviter certaine situation, alors on peut gérer les actions qui en dépendent comme on gère toute action en regard d’une exigence commune.

Qinaps est une solution SaaS de traçabilité des exigences qui se prête particulièrement bien à cet exercice.

Pour Qinaps, une exigence est un bloc d’information réutilisable sous forme de texte (p.ex. dans un document) ou sous forme d’objet à affecter à un livrable (« le livrable doit satisfaire l’exigence »). Exigences et livrables sont raffinés en blocs plus détaillés à mesure que le travail avance.  Un livrable déclare une exigence satisfaite ou non.  Un livrable est qualifié sur une échelle « avancement / difficulté ».

Imaginons maintenant un projet de développement électronique.  Nous avons une équipe Approvisionnement et une équipe Conception.  Le risque « obsolescence de composant » est soulevé lors de la première revue de risques. L’impact est tel que la revue de risque décide de lancer les actions de prévention.

1️⃣ Le risque est inscrit en tant qu’exigence :  Elle est ensuite raffinée en « Surveiller » et « Anticiper ».  Surveiller et Anticiper sont affectées au livrable « Approvisionner ».   Anticiper est affectée au livrable « Concevoir ».

2️⃣ Le travail avance :  « Approvisionnements » développe un livrable de diversification fournisseur et un livrable de contrat à long terme. Aucun des livrables n’est encore achevé.  « Conception Electronique » livre une conception avec un autre composant qui résout le problème.  Le livrable est classé « terminé / facile ». Le niveau de couverture du risque est de 33%

3️⃣ « Montant » — Le tableau de bord de Qinaps partage l’avancement en temps réel.  Une solution est trouvée : « Approvisionnements » met en place la nouvelle source.  Le niveau de couverture du risque passe à 100%.

✅ Pas besoin de réunion ou échange de mail.  Les acteurs ont sous les yeux le tableau de bord de l’avancement en regard des exigences.  Ils est mis à jour à chaque fois qu’un acteur déclare son avancement ou ses difficultés.  Le tout dans un seul et même outil.

➡️ Commentaires et questions bienvenues 😊