RAID dans la gestion de projet : comment il soutient les PMO et les parties prenantes

En gestion de projet, l'approche RAID est une méthode structurée permettant de recenser et de gérer les risques, les hypothèses, les problèmes et les dépendances susceptibles d'affecter la portée, le calendrier, le coût ou la qualité d'un projet.

Le RAID se comprend mieux comme trois choses à la fois :

• Un cadre de référence: une manière cohérente de catégoriser l'incertitude (risques et hypothèses) et la réalité (problèmes et dépendances) afin qu'aucun élément important ne se perde dans les échanges de courriels ou les comptes rendus de réunion.
• Un processus de gestion continu : les éléments RAID sont identifiés, évalués, attribués, traités et clôturés. Le processus ne s’arrête pas à la création de la liste.
• Un mécanisme de communication et de gouvernance : les journaux RAID offrent aux commanditaires de projet, aux comités de pilotage et aux bureaux de gestion de projet un point de référence commun pour discuter de l’état d’avancement du projet, au lieu de s’appuyer sur des mises à jour de statut informelles.

L'erreur la plus fréquente dans la gestion de projets RAID est de considérer le journal RAID comme un livrable ponctuel produit lors du lancement du projet. Dans les projets bien menés, le RAID est un processus évolutif : de nouveaux risques apparaissent, les hypothèses sont validées ou invalidées, les problèmes sont résolus et les dépendances évoluent au gré des changements de planning. Un journal RAID non mis à jour régulièrement devient rapidement inexact, et un journal RAID inexact est souvent plus dangereux que l'absence de journal, car il engendre une confiance illusoire.

RAID signifie Risques, Hypothèses, Problèmes et Dépendances. Chaque composante répond à une question différente concernant le projet.

1. Risques

Un risque est un événement ou une situation future possible qui ne s'est pas encore produite, mais qui pourrait avoir un impact négatif sur le périmètre, le calendrier, les coûts, les ressources, la qualité ou les objectifs commerciaux. L'évaluation des risques s'effectue généralement à l'aide des méthodes suivantes :

• Probabilité: la probabilité que le risque se produise
• Impact: quelle serait la gravité des conséquences si cela se produisait ?
• Gestion des risques : une vision combinée de la probabilité et de l'impact, souvent utilisée pour prioriser
• Responsable: la personne chargée de surveiller et de gérer le risque
• Atténuation: actions entreprises dès maintenant pour réduire la probabilité ou l'impact
• Plan de contingence: la réponse prévue si le risque se concrétise.
• Déclencheurs: signes avant-coureurs de la matérialisation du risque
• Statut: ouvert, sous surveillance, atténué, clos ou constaté (ce qui signifie que le problème est devenu une réalité)

2. Hypothèses

Les hypothèses sont des conditions que l'équipe considère comme vraies à des fins de planification, mais qu'elle n'a pas formellement vérifiées. Tout plan de projet repose sur des hypothèses, qu'elles soient écrites ou non. Le problème n'est pas d'avoir des hypothèses, mais de ne pas les valider.

Une hypothèse non validée peut se transformer discrètement en risque, en problème ou en dépendance :

• S'il est incertain que cela se vérifie, cela se comporte comme un risque.
• Si cela s'avère faux et que cela affecte déjà le projet, cela devient un problème.
• Si sa confirmation nécessite l'intervention d'une autre équipe, il s'agit effectivement d'une dépendance.

Exemple : L’équipe projet part du principe que le service financier du client aura nettoyé les données du plan comptable et les aura prêtes pour la migration au début de la phase 2. Si cela n’a pas été confirmé directement avec l’équipe financière, cette supposition pourrait devenir un obstacle ultérieurement.

3. Problèmes

La distinction la plus claire en matière de RAID : un risque peut survenir, un problème est déjà survenu.

Les problèmes nécessitent :

• Classification de la gravité: l'impact actuel du problème
• Responsabilité: une personne chargée de mener à bien la résolution du problème, et non pas seulement de le constater.
• Mesures correctives: que fera-t-on pour résoudre le problème ?
• Échéances: dates auxquelles la résolution est attendue
• Escalade: la résolution du problème nécessite-t-elle l'intervention de plusieurs instances de l'équipe projet ?
• État de la résolution : ouverte, en cours, escaladée, résolue

4. Dépendances

Les dépendances sont des tâches, des ressources, des équipes, des fournisseurs, des décisions, des systèmes ou des livrables dont dépend un travail. Les dépendances peuvent être :

• Gestion des tâches : une tâche ne peut pas commencer tant qu'une autre n'est pas terminée.
• Dépendances en ressources: une tâche nécessite une personne, une compétence ou un équipement spécifique.
• Dépendances vis-à-vis des fournisseurs: le travail dépend des livrables d'un fournisseur externe
• Dépendances entre équipes: le travail d'une équipe alimente celui d'une autre.
• Dépendances entre projets: les jalons d'un projet dépendent d'un autre projet.
• Dépendances inter-projets: plusieurs projets actifs dépendent d'une même ressource, d'un même système ou d'une même décision partagée.
• Dépendances externes: approbation réglementaire, infrastructure tierce ou préparation côté client

Dans le cadre d'une approche RAID, les dépendances sont cruciales car un retard dans une dépendance isolée provoque rarement un problème ponctuel. Il a un effet domino : un retard dans la livraison d'un fournisseur repousse une étape clé, ce changement d'étape est dû à la nécessité de faire appel à un spécialiste partagé, ce conflit de ressources affecte un second projet dépendant de la même personne, et le retard cumulé impacte un engagement au niveau du portefeuille auprès d'un comité de pilotage.

Exemple : Un projet de migration dépend de la reconfiguration du pare-feu par l’équipe de sécurité réseau. Cette même équipe gère également deux autres projets en cours. Un retard de deux semaines dans les travaux sur le pare-feu ne retarde pas seulement une tâche de migration, mais aussi la date de basculement, ce qui impacte le planning des ressources du projet suivant, déjà prévu avec la même équipe d’infrastructure.

Un registre RAID est un outil de suivi couramment utilisé en gestion de projet pour recenser et gérer les risques, les hypothèses, les problèmes et les dépendances susceptibles d'affecter la réalisation d'un projet. Il offre aux chefs de projet et à leurs équipes une vision claire des menaces potentielles, des problèmes actuels, des hypothèses clés et des dépendances à prendre en compte.

Un registre RAID est bien plus qu'une simple liste de points à surveiller dans un projet. C'est un document de gestion évolutif qui doit être régulièrement mis à jour, priorisé et attribué à des responsables spécifiques. En établissant des liens entre les éléments RAID et les échéanciers, tâches, ressources et jalons du projet, les équipes peuvent identifier les problèmes plus tôt et prendre des mesures correctives avant qu'ils n'aient un impact significatif sur les résultats.

Envisagez la mise en œuvre d'un progiciel de gestion intégré (ERP) d'entreprise impliquant les services financiers, les opérations, l'informatique et un partenaire de mise en œuvre externe.

Les organisations conservent parfois ces informations dans des documents distincts et parfois les regroupent dans un seul registre RAID auquel elles ajoutent une catégorie « Décisions ». Les deux approches sont valables ; l’important est que l’équipe utilise la structure choisie de manière cohérente, plutôt que la structure elle-même.

1. Création d'un journal RAID au démarrage et mise à jour rarement ultérieure.
2. Enregistrement des éléments RAID sans attribution d'un propriétaire clairement identifié.
3. Confondre les risques et les problèmes, et laisser les risques avérés mal étiquetés.
4. Traiter chaque risque comme étant d’égale importance au lieu de les hiérarchiser en fonction de leur probabilité, de leur impact et de l’exposition.
5. Ne pas valider les hypothèses avant qu'elles ne créent ou ne contribuent à des risques, des problèmes ou des dépendances. 
6. Suivi des dépendances dans un document distinct du planning de projet proprement dit.
7. Gestion de feuilles de calcul RAID déconnectées par projet, sans format partagé.
8. Ne pas définir à l'avance des critères d'escalade clairs.
9. Signaler les risques sans les traduire en impact commercial pertinent pour les dirigeants.
10. Ne pas fermer les éléments RAID obsolètes ou résolus, encombrant ainsi le journal actif.
11. Ne pas identifier les risques connexes ou systémiques dans plusieurs projets 
12. Ne donnant aux dirigeants aucune vue d'ensemble du portefeuille, mais seulement des aperçus projet par projet.
13. Utiliser RAID comme une simple case à cocher pour se conformer aux exigences, plutôt que comme un véritable outil d'aide à la décision.

RAID est important en gestion de projet pour plusieurs raisons concrètes :

• Détection précoce des problèmes – La plupart des échecs de projet ne sont pas soudains. Ils sont souvent liés à un risque non identifié, une hypothèse non vérifiée, un problème non remonté ou une dépendance non signalée à temps. RAID permet de les détecter avant qu'ils n'entraînent des retards ou des dépassements de budget.
• Cela évite que les petits problèmes ne s'aggravent : un dans la gestion des ressources ou des fournisseurs est plus facile à gérer s'il est détecté rapidement. S'il n'est pas pris en charge, il peut entraîner des retards en cascade, des augmentations de coûts et le non-respect des échéances.
• Cela devient crucial pour plusieurs projets : un retard, un conflit de ressources ou un problème avec un fournisseur sur un projet reste rarement isolé. Il affecte souvent d’autres projets partageant les mêmes personnes, fournisseurs ou décisions. RAID aide les équipes à identifier ces liens avant même qu’un problème ne survienne.
• établit clairement les responsabilités et les attributions : chaque risque, problème ou dépendance est attribué à un responsable spécifique. Ainsi, une simple prise de conscience d’un problème se traduit par une personne réellement chargée d’agir.
• Fournit aux équipes un langage commun pour l'état d'avancement – ​​Au lieu d'une mise à jour vague comme « les choses sont un peu en retard », un journal RAID indique la cause exacte : un risque, un problème ou une dépendance nommés, avec un statut et un responsable associés.
• Favorise une meilleure prise de décision – Grâce aux données RAID disponibles, les chefs de projet, les PMOet les dirigeants peuvent prendre des décisions éclairées concernant les priorités, les ressources et l’escalade, au lieu de se fier à des conjectures ou à des mises à jour informelles.

Gérer les risques liés à la gestion des actifs, des passifs et des risques (RAID) au sein d'un seul projet relève de la gestion de projet. Les gérer à l'échelle d'un portefeuille de projets est un problème de gestion de projet et de gouvernance, et cela soulève des difficultés qu'un tableur par projet n'a jamais été conçu pour résoudre.

Les difficultés courantes rencontrées à l'échelle de l'entreprise comprennent :

• Les journaux RAID de chaque projet existent de manière isolée, sans possibilité de voir le même risque apparaître dans plusieurs initiatives.
• Les risques partagés, tels qu'un problème systémique de performance du fournisseur affectant chaque projet pris en charge par ce fournisseur, sont à prendre en charge.
• Fournisseurs communs, où un retard chez un fournisseur se répercute sur plusieurs projets sans lien entre eux
• Ressources partagées, lorsqu'un même spécialiste, une même équipe ou un même élément d'infrastructure est une dépendance pour plusieurs projets simultanément.
• Dépendances inter-projets, où la date de début du projet B est conditionnée par l'atteinte d'une étape clé du projet A
• Priorités de portefeuille : les responsables PMO doivent savoir quels éléments RAID menacent les initiatives les plus stratégiques de l’organisation, et non pas seulement quel projet a le plus long historique RAID.

Les responsables de PMO doivent généralement suivre une chaîne de visibilité complète : impact RAID (élément, projet, programme, portefeuille). Chaque défaillance de dépendance doit être traçable, de la tâche jusqu'à son impact potentiel sur un engagement de livraison au niveau du portefeuille. Obtenir cette visibilité avec des feuilles de calcul cloisonnées par projet nécessite généralement un travail de consolidation manuelle important, répété à chaque cycle de reporting. C'est là que les plateformes de gestion de projet au niveau du portefeuille prennent tout leur sens.

Comprendre le concept RAID est relativement simple. C'est sa mise en œuvre opérationnelle, à travers des dizaines de projets actifs, des ressources partagées et les exigences de reporting de la direction, qui représente le plus grand défi pour la plupart des organisations. Celoxis est conçu comme une plateforme de gestion de projets et de portefeuilles tout-en-un, et plusieurs de ses fonctionnalités répondent directement aux problématiques de gestion RAID décrites précédemment.

Le principal problème du suivi RAID basé sur des tableurs, des e-mails ou des comptes rendus de réunion réside dans sa fragmentation : les informations relatives à un même projet sont dispersées, mises à jour par différentes personnes, à différents moments, sans source unique de vérité. Celoxis propose une automatisation des flux de travail, incluant des modèles pour les journaux de risques, de problèmes et RAID, permettant aux équipes de centraliser ces informations dans l'environnement de gestion de projet. Au lieu d'un risque isolé dans un tableur, déconnecté du planning qu'il impacte, les informations RAID sont intégrées au flux de travail du projet, au même titre que les tâches, les ressources et les jalons concernés.

2. Surveiller les risques sur plusieurs projets

(PMO) rencontrent souvent des difficultés lorsque chaque projet gère sa propre feuille de calcul des risques, sans format uniforme ni moyen simple de les consolider. Celoxis propose de gestion de portefeuille de projets , incluant des tableaux de bord et des analyses qui offrent une visibilité simultanée sur l'état de santé de plusieurs projets. Ceci permet une progression naturelle du suivi individuel des risques à la visibilité globale du portefeuille, en passant par l'état de santé global du projet, sans nécessiter la compilation manuelle de feuilles de calcul par chaque équipe projet avant chaque revue.

3. Suivre les dépendances entre les tâches et les projets

La gestion des dépendances est au cœur de RAID et figure parmi les aspects les plus difficiles à représenter avec précision dans un tableur. Celoxis intègre une planification de projet basée sur le diagramme de Gantt, avec gestion des dépendances entre les tâches et planification dynamique. Ainsi, lorsqu'une tâche précédente est modifiée, les tâches dépendantes et les échéances suivantes sont mises à jour en conséquence. Grâce à la possibilité de lier les projets au sein d'un même environnement de portefeuille, les équipes anticipent plus rapidement l'impact d'un retard sur les échéances d'un autre projet, au lieu de le constater a posteriori.

4. Améliorer la propriété et la responsabilisation des RAID

Un élément RAID sans responsable n'est qu'une simple note. Structurer les informations RAID dans l'environnement de projet et de flux de travail de Celoxis permet d'attribuer les éléments à des responsables spécifiques, avec des tâches et des échéances associées. Ainsi, la responsabilité reste visible au sein du plan de projet plutôt que d'être reléguée dans un document séparé, facilement oublié.

5. Créer des tableaux de bord et des rapports RAID

Les différentes parties prenantes ont besoin de visions différentes des mêmes données RAID. Les chefs de projet exigent un niveau de détail précis. Les responsables PMO recherchent des tendances transversales aux projets. Les dirigeants, quant à eux, ont besoin d'une analyse de l'impact commercial et d'une vue d'ensemble du portefeuille, et non d'une simple liste d'éléments. Celoxis propose des tableaux de bord et des rapports configurables, incluant des tableaux de bord au niveau du portefeuille et la possibilité d'explorer en détail les projets sous-jacents à partir d'une vue synthétique. Ceci permet d'adapter la visibilité RAID à chaque public sans avoir à gérer manuellement des rapports distincts pour chacun.

6. Connectez le RAID aux données de projet en direct

C’est le principe fondamental qui sous-tend l’utilisation du RAID, bien au-delà de la simple documentation. Le RAID prend tout son sens lorsque les équipes projet peuvent relier les risques, les problèmes et les dépendances aux plannings, aux ressources, aux jalons et aux décisions de portefeuille qu’ils sont susceptibles d’affecter, au lieu de gérer ces informations dans un fichier séparé. Celoxis fonctionnant comme un environnement intégré de gestion de projets et de portefeuilles, et non comme un simple outil de journalisation RAID, les informations relatives au RAID sont consultables en parallèle des plannings, des tâches, des affectations de ressources, des budgets, des jalons et de l’état d’avancement global du projet. Cette connexion permet de retracer un retard de dépendance jusqu’à son impact réel sur le planning et les ressources, au lieu de le considérer comme une simple note isolée nécessitant une vérification manuelle dans le plan de projet.

7. Utiliser les informations de projet fournies par l'IA lorsque cela est pertinent

Celoxis intègre Celoxis Lex, une solution d'intelligence artificielle conçue pour faciliter l'interaction et la récupération des informations de projet, notamment en faisant remonter les données pertinentes et en facilitant l'analyse des événements survenant dans l'ensemble des projets. Utilisée dans le cadre de la gestion des risques, des problèmes et des dépendances (RAID), cette solution permet aux équipes et aux responsables de PMO de trouver plus rapidement les informations pertinentes sur les risques, les problèmes ou les dépendances au sein d'un environnement de projet vaste et interconnecté. Elle privilégie un accès plus rapide aux données de projet existantes plutôt qu'une prédiction autonome ; elle ne dispense pas les équipes d'identifier, d'évaluer et de traiter elles-mêmes les éléments RAID.

GroundProbe, une entreprise australienne spécialisée dans les technologies de surveillance des risques géologiques pour les opérations minières et de génie civil, a rencontré un problème courant. Ses équipes de développement produit et de géophysique géraient simultanément plusieurs projets, partageant leurs ressources humaines et collaborant avec des prestataires externes. Avant d'utiliser Celoxis, le suivi de toutes ces informations s'effectuait via des tableurs, des e-mails et des échanges informels, sans système centralisé.

Les risques et les dépendances étaient bien réels, mais personne ne les percevait clairement. Deux projets pouvaient nécessiter la même personne simultanément, et personne ne s'en apercevait avant que cela n'entraîne des retards. Les coûts étaient difficiles à suivre, si bien que les problèmes budgétaires apparaissaient tardivement. Les chefs de projet découvraient souvent les problèmes une fois les échéances déjà dépassées.

L'analyste d'affaires Laura Yue a mené la recherche d'un système plus performant, en comparant Celoxis à Microsoft Project, Wrike et Smartsheet. Celoxis a été choisi pour ses outils de planification, ses tableaux de bord et son assistance.

Après la migration, la situation a évolué. Les conflits de ressources sont devenus visibles avant qu'ils n'entraînent des retards. Les tableaux de bord ont permis d'identifier les goulots d'étranglement en amont, et non plus après coup. Les dépassements de coûts ont été détectés plus rapidement. Les rapports, auparavant élaborés manuellement, sont désormais disponibles directement depuis le système.

Laura Yue a décrit Celoxis comme étant riche en fonctionnalités, facile à mettre en œuvre et hautement personnalisable, avec un système de reporting et un support performants.

La leçon à retenir : les risques et les dépendances de GroundProbe n’ont pas disparu lors de leur migration vers Celoxis. Ce qui a changé, c’est que l’équipe a enfin pu les identifier à temps pour agir, car l’information était désormais liée aux données réelles du projet au lieu d’être dispersée dans des feuilles de calcul isolées.

Le RAID n'est utile que si les équipes projet gèrent activement les informations qu'il contient, et non pas si elles se contentent de les enregistrer. Un journal RAID obsolète, déconnecté du planning, des dépendances, enfoui dans un tableur que personne d'autre n'ouvre, sans responsables clairement identifiés ou invisible au niveau du portefeuille, a une utilité pratique limitée comme outil de gestion, aussi complet qu'il ait pu paraître le jour de sa création.

Les organisations gérant quelques projets simples peuvent souvent se contenter d'un tableur bien tenu et de bonnes pratiques. Celles qui gèrent des portefeuilles complexes et multiprojets, avec des ressources partagées, des interdépendances entre projets, des relations avec des fournisseurs et des obligations de reporting auprès de la direction, doivent généralement relier directement les informations RAID à l'exécution des projets : calendriers, dépendances, ressources, tableaux de bord, rapports et décisions que les responsables de portefeuille doivent prendre.

Celoxis centralise la planification de projet, les flux de travail liés aux risques et aux problèmes, les dépendances entre les tâches et les projets, la gestion des ressources, les tableaux de bord et le reporting de portefeuille dans un environnement unique et connecté. Ainsi, les informations RAID ne sont plus dissociées des données de projet qu'elles sont censées décrire. Si la gestion RAID au sein de votre organisation est devenue un enjeu de gestion de portefeuille plutôt qu'un simple problème de tableur, il peut être judicieux d'étudier comment une plateforme connectée peut y remédier.