Qu’est-ce qu’un journal RAID (et comment l’intégrer à votre flux de travail de projet)


Lire la transcription :

Nous essayons de transcrire nos podcasts à l’aide d’un logiciel. Veuillez nous pardonner les éventuelles fautes de frappe, car le robot n’est pas correct à 100 % du temps.

Galen Low : Vous recherchez frénétiquement un e-mail dans votre boîte de réception, encore une fois. Cette fois, vous cherchez ce message de votre responsable confirmant une décision concernant votre projet. Comment s’appelait cette personne ? Quelle était la décision ? Tout est à l’arrêt jusqu’à ce que vous le retrouviez. Vous préparez donc une cafetière et continuez à fouiller. La nuit va être longue.

Nous allons explorer les aspects pratiques des journaux RAID et la manière de les intégrer à votre flux de travail de projet afin que vous puissiez conduire les conversations avec vos parties prenantes, communiquer facilement l’état de votre projet et ne plus jamais passer des heures à chercher cet e-mail de votre responsable.

Bonjour à toutes et à tous, merci de nous écouter. Je m’appelle Galen Low et je travaille avec le Digital Project Manager. Nous sommes une communauté de professionnels du numérique dont la mission est de nous aider mutuellement à développer nos compétences, à gagner en confiance et à créer des liens, afin d’amplifier la valeur de la gestion de projet dans un monde numérique. Si vous voulez en savoir plus, rendez-vous sur thedigitalprojectmanager.com.

Aujourd’hui, nous parlons des journaux RAID et de l’art délicat consistant à suivre les risques, les actions, les problèmes et les décisions afin de mener les projets vers la réussite.

Je reçois aujourd’hui Kim Essendrup, ancien membre du Kolme Group — une organisation résolument engagée à aider les entreprises à intégrer une prise de décision fondée sur les données dans leurs processus. Mais beaucoup d’entre vous le connaissent probablement comme l’un des deux animateurs fondateurs du très populaire podcast PM Happy Hour.

Bienvenue, Kim !

Kim Essendrup : Bonjour, Galen ! Merci de m’avoir invité.

Galen Low : Merci d’être avec nous. Oh là là, c’est un moment exceptionnel pour moi. PM Happy Hour est tellement amusant. Chaque épisode que j’ai écouté était hilarant.

Quoi qu’il en soit, je vous envie pour votre podcast. Je le trouve excellent. Pour les auditeurs qui ne le connaissent pas, allez le découvrir. Il y a une très bonne dynamique. Je me demandais si je pouvais commencer par une question de grand fan : qu’est-ce qui vous a poussé à lancer le podcast PM Happy Hour au départ ?

Kim Essendrup : Tout d’abord, je dois dire que je suis aussi un grand fan de votre travail. Nous sommes donc fans l’un de l’autre. J’ai beaucoup accompagné des chefs de projet. Je me suis rendu compte que je répétais sans cesse les mêmes conseils, alors je me suis dit : « Je vais simplement les mettre dans un article de blog, les gens le liront et ce sera parfait. » Puis j’ai découvert que les gens n’aimaient vraiment pas lire des articles de 10 000 mots sur la gestion de projet.

Ce n’est pas très amusant. Je travaillais aussi sur une petite entreprise en démarrage consacrée à un autre sujet, et un consultant m’a dit : « Vous devriez faire un podcast. » J’ai donc appris tout le processus, compris comment procéder et acheté un micro. Je l’ai fait pour cette autre jeune entreprise, qui n’est finalement pas allée très loin, mais cela m’a permis de découvrir le monde des podcasts.

J’ai pris le rythme et j’ai réussi à comprendre comment cela fonctionnait. Je me suis dit que je pourrais peut-être rendre certains de ces articles de blog vraiment intéressants. Puis je me suis demandé quelle serait la personne idéale à inviter dans un podcast pour rendre la gestion de projet intéressante.

Et c’était absolument Kate. Je l’ai contactée et je lui ai dit : « Veux-tu tenter cette expérience folle ? » Kate a immédiatement accepté. Depuis, c’est de plus en plus amusant.

Galen Low : J’adore. La dynamique est vraiment excellente. J’ai presque l’impression d’écouter une émission de radio matinale, une très bonne émission de radio matinale. Les échanges sont hilarants, mais ils portent aussi sur les projets.

Je me dis : oui, c’est exactement ce qu’il me faut. Quoi qu’il en soit, je suis un grand fan. Alors, si vous ne l’avez pas encore découvert, PM Happy Hour, ou Project Management Happy Hour, est disponible sur presque toutes les applications de podcasts que j’ai vues.

Kim Essendrup : Sur toutes celles que nous avons pu trouver.

Galen Low : Voilà. Excellent. Très bien, entrons dans le vif du sujet.

Aujourd’hui, nous allons nous intéresser de près aux journaux RAID. Pour commencer par définir les choses avec nos auditeurs, pouvez-vous expliquer ce qu’est pour vous un journal RAID et pourquoi il est important ?

Kim Essendrup : Oui. Pour le dire le plus simplement possible, un journal RAID est un registre dans lequel RAID est l’acronyme de Risks, Actions, Issues and Decisions, c’est-à-dire risques, actions, problèmes et décisions. Certaines organisations préfèrent remplacer les actions et les décisions par les hypothèses et les dépendances, mais nous pourrons en parler dans un instant.

L’idée principale est qu’il s’agit du registre des risques, du registre des actions et de tous ces registres que l’on vous apprend à créer, notamment si vous suivez une méthode comme celle du PMI. Historiquement, nous suivons ces éléments dans une même feuille de calcul. C’était déjà une méthode ancienne lorsque j’ai commencé à gérer des projets, il y a plusieurs décennies.

Cela existe donc depuis toujours et c’est un outil opérationnel indispensable pour aider les chefs de projet à gérer leurs projets. Selon nos sondages, environ la moitié à deux tiers des chefs de projet l’ont utilisé ou en connaissent l’existence. C’est un outil vraiment essentiel, et nous cherchons actuellement à le faire connaître davantage.

Galen Low : Très intéressant. J’étais justement l’une de ces personnes. Je ne m’en étais pas vraiment rendu compte, mais je participais à une session au cours de laquelle nous parlions de notre journal RAID. On m’avait appris le modèle risques, hypothèses, problèmes et dépendances. Puis quelqu’un a levé la main et a demandé : « Êtes-vous sûr que ce n’est pas plutôt ceci ? » Nous nous sommes alors demandé quelle version nous préférions et pourquoi.

Kim Essendrup : J’aime les actions et les décisions. Prenons l’exemple d’une hypothèse. Une hypothèse est une hypothèse de planification : « Je vais réaliser ce projet. » Quelles hypothèses avons-nous concernant le périmètre ou lors de l’élaboration de notre plan ? Une hypothèse est donc quelque chose qui intervient davantage comme donnée d’entrée au début.

Une hypothèse devient en réalité un risque, car si elle se révèle incorrecte, cela crée un risque. Pour moi, les hypothèses entrent donc naturellement dans la catégorie des risques. Les dépendances fonctionnent de la même manière. Si votre projet comporte une dépendance externe, celle-ci représente soit un risque, soit un élément qui appartient au calendrier du projet, car elle est associée à une échéance, à des prédécesseurs et à des successeurs.

Elle se retrouve généralement dans l’un de ces deux endroits. Parfois, les dépendances externes sont tellement préoccupantes qu’elles méritent un onglet spécifique ; dans ce cas, on pourrait parler de RAIDD. Mais je pense que si vous vous concentrez sur les actions et les décisions, qui sont des éléments plus opérationnels à suivre tout au long de la réalisation du projet, votre journal RAID reste un outil opérationnel que vous utilisez au quotidien pour vous gérer et rester organisé.

Galen Low : Je comprends. J’aime cette idée d’aller de l’avant, et je suis tout à fait d’accord. Je butais toujours sur le fait que toutes mes hypothèses et dépendances étaient en réalité des risques. Dans mes projets, tout était formulé comme un risque, et je me demandais si je faisais les choses correctement.

Kim Essendrup : Oui. La meilleure manière de commencer votre registre des risques consiste peut-être à partir de toutes les hypothèses et dépendances sur lesquelles repose votre plan.

Galen Low : Et à mesure que vous invalidez ou validez certaines hypothèses, vous pouvez les retirer. J’aime cette idée. Nous avons parlé de l’importance d’un journal RAID, notamment pour les décisions.

Le fait de tout regrouper dans un seul journal plutôt que dans huit documents différents que les gens doivent consulter et maintenir à jour — et qu’ils ne regardent généralement pas, soyons honnêtes — est vraiment utile dans un projet.

Kim Essendrup : Sinon, vous devez rechercher dans Outlook : « Où est cet e-mail ? Je sais qu’il était quelque part ici. »

Galen Low : Je suis le roi des recherches Outlook, parce que je suis aussi le roi de la désorganisation de ma boîte de réception. Mais oui, cela a tout son sens. Vous avez mentionné que cet outil pouvait empêcher un projet de basculer dans des scénarios catastrophiques. Sans vouloir dramatiser, il aide vraiment à maintenir le projet sur les rails. Comment utiliseriez-vous concrètement un journal RAID pour y parvenir ?

Kim Essendrup : Je considère qu’il sert à faire fonctionner ou à sauver n’importe quel projet. La partie « faire fonctionner » est très importante, car si vous ne l’utilisez pas, vous devrez probablement finir par sauver votre propre projet.

Quand vous pensez aux outils de gestion de projet, vous avez votre plan ou votre carnet de tâches, avec toutes les activités qui contribuent directement à vos livrables. C’est très bien, c’est ce que nous faisons. Mais le journal RAID intervient pour répondre à la question suivante : comment vous assurer que ces activités seront correctement réalisées ?

Le journal RAID n’est pas le plan ; c’est le moyen de vous assurer que le plan sera exécuté. Et, inévitablement, qui a déjà eu un projet qui s’est déroulé parfaitement ? Vous allez rencontrer des problèmes et des difficultés. Les choses peuvent mal tourner, et elles tournent effectivement mal.

Que pouvez-vous utiliser pour les gérer ? Pas votre calendrier, mais votre journal RAID, afin d’identifier ce qui risque de mal tourner et de suivre les petites actions que vous devez surveiller pour éviter que vous ou votre équipe ne preniez du retard. Vous pouvez aussi y suivre les problèmes apparus et déterminer comment les résoudre le plus rapidement possible afin de maintenir le projet sur la bonne voie.

Il vous permet également d’anticiper, de planifier et de mettre en œuvre les décisions nécessaires, ou de faire prendre celles auxquelles vous n’aviez pas pensé au début du projet. Ce sont tous ces éléments qui nous aident à maintenir nos plans sur la bonne voie et à les livrer avec succès.

Lorsque vous ne réfléchissez pas aux risques, que vous ne planifiez pas les décisions et que vous ne les formalisez pas, le plan commence à se désagréger. Tout repose donc sur la gestion des fondamentaux. C’est là que les projets échouent : lorsque l’on ne surveille pas les bases. Pour moi, c’est toute la magie d’un journal RAID. C’est incroyablement simple, mais essentiel pour rester concentré sur les fondamentaux.

Galen Low : Vous avez parlé de votre expérience en accompagnement. Avez-vous des exemples de situations où les choses dérapaient et où vous vous êtes dit qu’un outil aussi simple qu’un journal RAID pouvait résoudre le problème ?

Kim Essendrup : Oui. Il y a quelques années, j’ai pris la direction d’un bureau de gestion de projets basé en Europe. C’était très intéressant, notamment parce que mes déplacements en Europe étaient financés par l’entreprise. Je vivais toujours dans la région de Phoenix, donc je m’y rendais environ une fois par mois.

Lorsque vous prenez la direction d’un bureau de gestion de projets, vous êtes aussi responsable de tous les incendies à éteindre. Un vendredi, j’ai reçu un appel concernant un projet. Et lorsqu’on reçoit un appel au sujet d’un projet un vendredi, ce n’est jamais une bonne nouvelle. Ils m’ont dit que le projet se déroulait tellement mal que le client menaçait de nous facturer les problèmes, puis d’annuler le contrat.

Le lundi matin, je n’étais plus à Phoenix : je me trouvais dans les Midlands, au Royaume-Uni, et je devais reprendre le contrôle du projet. Le client était absolument furieux.

J’étais là avec toute notre équipe. Le client a énuméré tous les problèmes et tout ce qu’il nous reprochait. Je me suis dit que cela semblait légitime et que j’aurais moi aussi été contrarié. Puis j’ai regardé mon équipe et demandé : « Avez-vous des problèmes de votre côté ? »

Ils se sont immédiatement manifestés : « Le client ne nous a pas fourni ceci. Vous ne nous avez pas donné cela. Nous ne pouvions pas réussir parce qu’il nous manquait tout ce dont nous avions besoin. » Le client répondait : « Vous ne me l’avez jamais dit. Je ne le savais pas. »

J’ai demandé à tout le monde de patienter jusqu’à ce que le calme revienne, puis j’ai dit : « Pouvez-vous me montrer votre journal RAID ? » Silence total. Je ne savais pas s’ils ne connaissaient pas cet outil et étaient trop gênés pour le dire, ou s’ils venaient de comprendre qu’ils n’en avaient pas et n’osaient pas l’admettre.

J’ai donc ouvert mon ordinateur portable et créé un journal RAID. Nous avons commencé à consigner tous les problèmes. J’ai projeté le document et tout saisi afin de reconnaître chacune des préoccupations du client. Ils ont alors eu le sentiment d’être enfin entendus, car ils me voyaient noter leurs problèmes.

Puis j’ai demandé à mon équipe quelles étaient ses difficultés. C’était exactement la même chose. J’ai tout documenté, puis nous avons commencé à constater que beaucoup de ces éléments étaient des dépendances : chacun attendait quelque chose de l’autre sans que cela ait été clairement établi.

C’est l’une des raisons pour lesquelles les dépendances peuvent parfois avoir leur place dans un journal RAID. Nous avons donc documenté toutes les dépendances entre les deux parties. Au fil de l’après-midi, au lieu de nous crier dessus de part et d’autre de la table, nous avons progressivement tourné nos chaises vers le projecteur.

Nous ne nous opposions plus les uns aux autres : nous nous attaquions aux problèmes. Cette histoire montre qu’un journal RAID est une excellente plateforme pour créer un alignement, faire en sorte que chacun comprenne le point de vue des autres et établir une liste commune de problèmes à résoudre ensemble. Il peut réellement transformer ce type de situation ou, au minimum, aider à reprendre le contrôle.

Galen Low : J’aime beaucoup cette histoire, notamment le langage corporel. Au lieu d’être face à face dans une confrontation, les participants se tournent progressivement vers la collaboration.

Dans toutes ces techniques, tactiques et procédures de gestion de projet, nous sous-estimons souvent le fait qu’elles servent à faciliter la communication et la collaboration. Les dépendances peuvent fonctionner dans les deux sens : « Si vous ne faites pas ceci, nous ne pouvons pas faire cela », mais aussi « Faites ceci pour que nous puissions faire cela ».

Sans visibilité sur ces dépendances, il est difficile de comprendre pourquoi une tâche doit être réalisée. Les gens peuvent la remettre à plus tard, personne ne dit rien et, soudain, le projet est très éloigné de sa trajectoire.

Il s’agit parfois simplement de garder une trace des éléments à suivre. Cela peut sembler être une documentation lourde, mais personne ne peut mémoriser des centaines de choses à surveiller au cours d’un projet.

Kim Essendrup : C’est vrai. Parler d’une décision, d’une dépendance ou d’un risque en réunion est une chose. Mais lorsque vous le mettez dans un document partagé, sur Zoom ou sur un projecteur, que vous le saisissez et que vous associez le nom des personnes concernées, cela devient concret.

Si mon nom figure à côté d’un élément, je vais immédiatement commencer à y prêter attention. Le journal RAID est donc aussi un excellent outil de communication et de responsabilisation. Lorsque vous arrivez dans un nouvel environnement ou que vous reprenez un projet, créez un journal RAID s’il n’en existe pas.

Vous devez comprendre comment vous allez exécuter et gérer le plan. L’une de mes expressions préférées, surtout lorsqu’il s’agit d’un projet gouvernemental, est la suivante : traitez votre journal RAID comme s’il pouvait faire l’objet d’une assignation en justice, car cela pourrait un jour arriver. Vous regretterez peut-être de ne pas l’avoir tenu à jour.

Galen Low : Absolument. J’ai participé à plusieurs projets qui ont été audités. Ne pas avoir la bonne documentation facilement accessible, même si les données existent quelque part, signifie devoir les extraire, ce qui constitue un projet à part entière. Disposer d’une trace claire des événements, des risques identifiés et de la manière dont nous en avons parlé peut être extrêmement utile.

Kim Essendrup : Cela a dû vous réveiller rapidement le matin où vous avez appris qu’un audit était prévu.

Galen Low : Oh oui. « Ouvrez tous le suivi du temps ! »

Je pense que vous avez soulevé un point important concernant l’utilisation pratique d’un journal RAID. Beaucoup de personnes se disent que cela représente beaucoup de travail. Comment conserver ce document comme source de vérité après ce moment d’alignement ?

Kim Essendrup : Le chef de projet doit vraiment l’incarner. Oui, cela représente davantage de suivi et de gestion. Vous pourriez ne pas utiliser de journal RAID et espérer vous en sortir, comme lorsque vous traversez un feu orange en fermant les yeux et en accélérant en espérant éviter l’accident.

Cela peut fonctionner plusieurs fois. Mais dans tous les projets que j’ai dû reprendre et sauver, lorsque je demandais : « Pouvez-vous me montrer votre journal RAID ? », la réponse était toujours non.

Lorsque mes propres projets commencent à dévier, je me rends compte que nous allons dans le fossé et que je n’ai pas tenu mon journal RAID à jour, ou que je n’en ai pas créé pour ce projet.

Après avoir vécu cela suffisamment souvent, on comprend qu’il faut utiliser cet outil. Les études varient, mais on constate généralement que 70 à 80 % des projets n’atteignent pas leurs objectifs clés et qu’environ 19 à 20 % échouent complètement.

Nous savons que les problèmes surviennent, que les tâches sont repoussées et que les coûts peuvent dépasser les prévisions. Si vous savez qu’un problème risque de se produire, ne rendez-vous pas un mauvais service à vous-même et à votre projet en ne consacrant pas un peu de temps à sa prévention ?

C’est notre métier. Nous sommes des chefs de projet et nous sommes censés réussir à mener ces projets à bien. Le journal RAID est une sorte d’arme de super-héros qui nous aide à maintenir nos projets sur la bonne voie.

Galen Low : Les statistiques sont amusantes, car elles peuvent nous donner une excuse pour ne pas agir. Nous entendons qu’une personne sur trois va rencontrer un problème et nous pensons que cela ne nous arrivera pas. Puis, lorsque cela arrive, nous nous disons que c’était inévitable.

On peut aussi être paralysé en pensant que le projet va probablement échouer. Mais ce que vous décrivez ressemble plutôt au fait de reprendre les rênes. Le plan est comme une carte avec une ligne tracée dessus. Le véritable volant qui permet de faire avancer le projet et d’éviter qu’il ne sorte de la route, ce sont des outils comme le journal RAID.

J’aime le fait qu’il soit centralisé et clair, et que les équipes puissent collaborer dessus en salle de réunion. Cela m’amène à une question : mon journal RAID a toujours été une feuille de calcul, et beaucoup de gens ne veulent pas d’une feuille de calcul supplémentaire. Quels outils peut-on utiliser pour gérer un journal RAID autrement qu’avec Excel ou Google Sheets ?

Kim Essendrup : Il existe bien sûr de nombreux outils de gestion de projet sur le marché. Le Kolme Group, où je travaillais comme consultant en gestion de portefeuille et de projets, a déployé des outils de gestion de projet dans plus de 650 organisations.

Nous avons constaté que les outils disponibles ne gèrent généralement pas bien les journaux RAID. Beaucoup ne proposent rien de comparable. Certains sont spécialisés dans la gestion des tâches, la planification des ressources ou la prévision des activités de l’entreprise. Ce sont des fonctions importantes, mais elles ne répondent pas forcément aux besoins du chef de projet.

Les outils se concentrent soit sur la vision de la direction ou du portefeuille, soit sur les équipes avec une interface très simplifiée. Le chef de projet se retrouve entre les deux.

Certains outils proposent quelques fonctions RAID, comme le suivi des risques ou des problèmes, mais il faut parfois détourner une fonctionnalité existante pour créer un tableau Kanban de risques et de problèmes. On perd alors la simplicité et la valeur d’un journal RAID classique.

Nous avons donc décidé de créer notre propre solution, car nous étions fatigués des feuilles de calcul. Elles fonctionnent, mais elles ont leurs limites : partage difficile, suivi des versions complexe et collaboration peu pratique. Si vous voulez suivre l’historique d’un risque, vous devez souvent faire défiler de longues colonnes.

Nous avons créé un journal RAID sous forme de logiciel en tant que service : raidlog.com. Nous en sommes encore aux premières étapes, mais notre mission est de créer l’outil ultime pour aider les chefs de projet à réussir.

Galen Low : Le logiciel de gestion de projet semble effectivement évoluer dans deux directions : la vision d’entreprise et l’équipe qui cherche simplement à accomplir ses tâches. Le chef de projet est souvent oublié.

Pouvez-vous expliquer comment votre solution fonctionne ? S’intègre-t-elle à d’autres logiciels ou fonctionne-t-elle de manière autonome ?

Kim Essendrup : C’est un logiciel autonome. Il comprend un journal RAID avec une interface ressemblant à une feuille de calcul. Elle est rapide, simple et efficace, afin de ne pas ralentir les utilisateurs habitués aux journaux RAID.

Nous proposons aussi une interface plus visuelle et intuitive, notamment pour les personnes qui découvrent les journaux RAID ou qui doivent présenter un problème critique à un dirigeant. Les composants visuels permettent d’ouvrir une vue détaillée d’un problème ou d’une décision et de l’afficher de manière adaptée à une conversation avec les parties prenantes ou le commanditaire.

Nous ajoutons également des fonctions qui accompagnent les différents processus. Par exemple, si vous connaissez le tableau en T utilisé pour comparer les avantages et les inconvénients d’une décision, nous l’avons intégré à notre module de décisions.

Nous ajouterons aussi des cartes thermiques et des fonctions d’analyse avancée, comme les simulations de Monte-Carlo. Plus tard, nous intégrerons des fonctions alimentées par l’intelligence artificielle.

Le journal RAID n’est pas le seul outil de gestion de projet. Nous développons donc des intégrations. Nous en avons déjà une avec Planview AdaptiveWork, nous allons en créer une avec Jira et nous nous intégrerons à autant d’outils que possible. Nous sommes également connectés à Zapier.

Notre objectif est de rendre obsolète le journal RAID basé sur une feuille de calcul en proposant une meilleure solution. Nous offrirons une version gratuite puissante ainsi que des fonctions avancées pour les utilisateurs expérimentés.

Galen Low : Ce que j’aime le plus, c’est que votre solution va bien au-delà d’un simple journal. Un journal sert généralement à consigner quelque chose qui s’est produit ou qui pourrait se produire. Vous proposez plutôt une véritable gestion RAID, avec des analyses et des tableaux en T.

Kim Essendrup : C’est même davantage que cela. Nous l’appelons raidlog.com parce que le journal RAID est le principal outil opérationnel. Mais les journaux RAID n’ont pas beaucoup évolué ces dernières décennies, car ils sont limités par l’outil utilisé.

Notre vision est d’aider les chefs de projet en leur fournissant les outils dont ils ont besoin pour gérer un projet. Nous ne nous arrêterons pas aux éléments RAID. Nous intégrerons les enseignements tirés et les comptes rendus de réunion, afin que vous puissiez mettre à jour votre journal RAID tout en rédigeant le compte rendu et économiser plusieurs heures par semaine.

Notre objectif est de devenir l’outil de référence qui se connecte à votre outil de planification, de calendrier ou de carnet de tâches comme un module complémentaire. Nous voulons contribuer à réduire les difficultés liées à la gestion de projet.

Galen Low : J’aime le fait que la solution s’intègre à d’autres outils et reste ouverte. Les intégrations Zapier permettent de faire circuler les informations. Il s’agit finalement d’une couche de collaboration destinée à l’analyse des risques et à la gestion des décisions.

Kim Essendrup : Nous voulons aussi aller au-delà de l’outil. Grâce à notre expérience en formation et en accompagnement, nous voulons intégrer des connaissances et des contenus pédagogiques.

Si vous découvrez la gestion des risques, l’outil doit vous guider : que faire ici ? Que signifie la probabilité et l’impact ? Nous voulons proposer une aide contextuelle, mais aussi des fonctions avancées comme la valeur monétaire attendue et les simulations de Monte-Carlo.

Vous pourriez vous demander quelle provision pour imprévus prévoir. Après avoir saisi les données, vous cliquez sur un bouton et le système effectue les calculs pour vous.

Galen Low : J’ai créé plusieurs registres des risques à partir de zéro et cela implique beaucoup de formules. J’aurais aimé ne pas avoir à le faire.

Kim Essendrup : On arrive rapidement à un point où l’on se dit que c’est suffisant et qu’il faut maintenant faire avancer le projet.

Galen Low : Disons simplement 15 % de provision pour imprévus et avançons.

Dernière question. Certains outils oublient les besoins du chef de projet, notamment les éléments RAID. Mais le RAID est-il réservé aux chefs de projet ? Et sinon, comment peut-il aider une équipe à développer une culture de responsabilité concernant les risques, les actions, les problèmes et les dépendances ?

Kim Essendrup : Les origines du RAID se trouvent dans les outils spécialisés de gestion de projet utilisés par les anciens chefs de projet. Mais il s’agit surtout de savoir comment réaliser un plan. Ce plan ne doit pas nécessairement être un projet au sens traditionnel du cycle en cascade.

Il peut s’agir d’un produit agile. En tant que responsable produit, vous devez gérer les risques liés au produit et faire prendre les décisions nécessaires. Lorsqu’une décision est prise, vous devez la documenter et la suivre.

Si vous êtes responsable Scrum, vous dirigez une équipe agile et devez vous assurer qu’elle peut être efficace. Le journal RAID concerne donc moins le produit que l’équipe : comment l’aider à réussir et comment la soutenir.

Pour un responsable de bureau de gestion de projets qui souhaite accompagner ses chefs de projet, demander « Montrez-moi votre journal RAID » est une excellente manière de comprendre comment ils gèrent leurs projets et de leur proposer des suggestions.

Du point de vue du chef de projet, le journal RAID aide aussi à gérer la relation avec la direction. Si vous devez rencontrer votre responsable de bureau de gestion de projets, vos commanditaires ou vos parties prenantes, vous pouvez filtrer le journal et ne présenter que les trois ou quatre éléments principaux sur lesquels vous avez besoin de leur intervention.

Le journal RAID est donc bien plus qu’un outil opérationnel de projet. C’est une manière de travailler et de collaborer, qui permet de rester organisé, de maintenir l’équipe organisée et motivée et de faciliter la communication.

Galen Low : J’aime beaucoup ces points. Peu de personnes ne sont pas confrontées à des risques, des actions, des problèmes ou des décisions dans leur travail.

Cela peut devenir un outil de collaboration pour n’importe quelle équipe. Le filtrage est essentiel, car les chefs de projet développent une grande capacité à gérer une quantité écrasante d’informations. Mais lorsqu’ils montrent leurs diagrammes de Gantt aux autres, ceux-ci peuvent rapidement se sentir dépassés.

Il faut réduire l’information et la présenter dans un format permettant d’avoir une conversation avec une partie prenante métier, pas uniquement avec un autre chef de projet. Le journal RAID peut servir à gérer une équipe de chefs de projet ou les attentes de la direction. C’est une source de vérité qui, lorsqu’elle est tenue avec rigueur, peut être utilisée de nombreuses façons pour fluidifier le travail.

Kim Essendrup : Exactement. Le RAID n’est qu’un début. On peut l’étendre aux enseignements tirés. Les problèmes sont désagréables, mais il est encore pire de rencontrer le même problème encore et encore. Ajouter des enseignements tirés au journal RAID permet d’y répondre et d’améliorer la prochaine fois.

Galen Low : J’adore cette idée et je suis également très intéressé par les fonctions liées à l’intelligence artificielle.

Je trouve tout cela fascinant. Où les auditeurs peuvent-ils en apprendre davantage sur RAID Log ?

Kim Essendrup : Sur raidlog.com. Le nom de domaine est facile à retenir. J’aimerais que les gens essaient le produit et nous donnent leur avis, car nous voulons en faire un excellent outil pour les chefs de projet. Vous pouvez également me contacter sur LinkedIn.

Si vous découvrez les journaux RAID et que vous vous demandez de quoi il s’agit, j’ai écrit un livre, car il n’existait curieusement aucun ouvrage consacré aux journaux RAID. Sur Amazon, recherchez simplement « Ultimate Guide to RAID Log » et vous trouverez mon livre.

Galen Low : C’est incroyable. Je n’en avais aucune idée. J’ajouterai tous ces liens aux notes de l’émission pour les auditeurs. Je vais également aller voir cela, car je trouve le sujet fascinant. Je pensais que ce n’était qu’une feuille de calcul, mais je vais certainement approfondir.

Kim Essendrup : Excellent.

Galen Low : Excellent. Kim, merci beaucoup d’avoir été avec nous aujourd’hui. J’apprécie vraiment vos éclairages. J’aime toujours approfondir les sujets liés à la gestion de projet, notamment ces éléments qui semblent parfois impénétrables, comme les journaux RAID et les registres des risques. Pourtant, lorsqu’on en parle, ils sont très simples et très pertinents.

Merci beaucoup pour votre point de vue.

Kim Essendrup : Merci de m’avoir reçu, Galen.

Galen Low : Voilà pour aujourd’hui. Comme toujours, si vous souhaitez rejoindre la conversation avec plus d’un millier de passionnés de la gestion de projet, rejoignez notre collectif. Rendez-vous sur thedigitalprojectmanager.com/membership pour en savoir plus.

Si vous avez apprécié cet épisode, abonnez-vous et restez en contact sur thedigitalprojectmanager.com. À la prochaine, merci de votre écoute.