Alternative à Asana pour la gestion des risques du projet : un registre qui n’est pas une liste

Un registre des risques qui est une liste de tâches

Asana a un modèle prêt de registre des risques et un modèle de matrice. Leur logique est saine : vous décrivez la menace, notez sa probabilité et son impact, nommez un responsable et ajoutez un plan de réponse. Avec un projet et une douzaine de risques, cela suffit. Cela vaut aussi mieux qu’un tableur, car le registre se trouve là où le travail a lieu, et une comparaison fonction par fonction de FlexiProject et d’Asana dresse le tableau plus large.

La limite est dans la construction. Un risque n’est pas ici un objet distinct, seulement une tâche avec des champs en plus. Tout ce qui découle du fait qu’un risque n’est pas un travail à faire doit être organisé hors de l’outil.

Ce que le modèle donne et ce qu’il ne peut pas

Le modèle organise l’information, et c’est là sa vraie valeur. Trois choses, il ne vous les donne pas.

Un risque ne peut pas pointer vers une autre tâche, car il est lui-même une tâche. Vous ne pouvez donc pas noter qu’une menace donnée concerne une livraison précise du planning. Les risques ne peuvent pas non plus être comparés entre projets, car les champs personnalisés ne fonctionnent qu’à l’intérieur d’un projet. Et il n’y a pas de niveau au-dessus du projet. Chaque registre est complet en lui-même et aveugle à ce qui se trouve à côté. Trois équipes peuvent gérer le même risque fournisseur et aucune ne l’apprendra.

Trois signes que le registre a cessé de fonctionner

Un registre mis à jour juste avant le comité de pilotage plutôt qu’au fil du travail. Si mettre à jour est une activité distincte, cela se produit quand quelqu’un le demande. Généralement trop tard pour changer quoi que ce soit.

Des risques ressaisis à la main dans la charte de projet et le rapport mensuel. Ce travail ne crée aucune information nouvelle, et trois versions de la même liste finissent par circuler dans l’entreprise.

La question « quelqu’un s’en occupe-t-il déjà » sans personne à qui la poser. Sans un niveau où les risques de différents projets se rencontrent, chacun est résolu à partir de zéro. Nous examinons aussi quoi rechercher parmi les applications comme Asana.

Ce qu’il faut exiger d’un registre des risques

La différence entre une liste et un module se ramène à sept choses. Chacune est soit traitée par le système, soit faite à la main.

Ensemble, elles décrivent ce qu’un logiciel de gestion des risques doit fournir. Ci-dessous, je passe les exigences une à une et montre comment FlexiProject les traite.

Une matrice dans les dimensions que vous utilisez déjà

Configurer la matrice des risques ressemble à un détail. C’est l’une des raisons les plus fréquentes pour lesquelles un module de risques dans un système PPM reste vide. Une entreprise a passé des années à développer une matrice trois par trois, et le système en cours de déploiement a cinq par cinq codé en dur. Personne ne va reformer trente chefs de projet à une nouvelle échelle parce qu’un éditeur en a décidé ainsi. Le résultat est prévisible : le module reste inutilisé et le risque retourne sur une diapositive.

Dans FlexiProject, les dimensions de la matrice se règlent au déploiement, sans programmation. L’entreprise apporte l’échelle que ses gens connaissent, avec l’habitude qu’une note donnée exige une réponse donnée. La norme que vous avez développée survit ainsi au changement d’outil.

Une fiche de risque plutôt qu’une ligne dans un tableau

Dans le système de gestion de projet FlexiProject, le registre des risques est un module distinct du projet. Chaque risque a un nom, un statut, un responsable, un lien vers une tâche du planning, une catégorie, un impact, une probabilité et une date d’identification. L’impact sur le planning et l’impact sur le budget sont notés séparément. Cela compte en pratique : un risque retardant la recette d’un mois et un risque ajoutant cent mille au coût appellent des réponses différentes. Une note commune « impact élevé » ne les distinguera pas.

Au-dessus du registre se trouve une fiche de risque. Au-delà des données du registre, elle contient des pièces jointes, le plan de gestion de cette menace et une messagerie où l’équipe discute de ce risque précis. Cela paraît anodin, mais résout un vrai problème. Une discussion dans un canal d’équipe disparaît en deux jours. Une conversation enregistrée sur le risque reste avec lui. Quand quelqu’un demande six mois plus tard pourquoi cette réponse a été choisie, la réponse se trouve au même endroit que la décision.

Un risque épinglé à une tâche du planning

Les registres des risques sont généralement plats. Ils traitent un risque concernant tout le projet, par exemple un manque de ressources, de la même façon qu’un risque concernant une seule tâche, comme une livraison d’un sous-traitant. Ce sont deux situations différentes et elles se gèrent différemment.

Dans FlexiProject, chaque risque peut être lié à une tâche précise du module de planning du projet. Vous affectez un risque fournisseur à la tâche qui dépend de la livraison, et un risque réglementaire à la tâche d’approbation. Dès lors, le planning porte l’information sur les menaces. Un triangle avec un point d’exclamation apparaît sur la ligne de la tâche, avec un cercle à côté : rouge quand le risque est actif, gris quand il ne l’est pas. Le chef de projet voit les endroits qui demandent de l’attention sans ouvrir le registre.

Cela aide surtout quand le plan change. Quand le planning se déplace, vous savez tout de suite quels risques sont devenus plus pressants. Ils concernent des tâches qui se sont rapprochées d’une échéance ferme ou sont passées sur le chemin critique. Cette information existe aussi dans un registre plat, mais vous devez la déduire vous-même en comparant deux listes. Donc généralement personne ne le fait. Séparément, nous expliquons comment aborder la planification de projets que le système tient à jour.

Le risque comme savoir de l’organisation, pas d’un seul projet

Dans la plupart des entreprises, la façon dont les équipes identifient et évaluent les risques du projet se ramène à une réunion de lancement où quelqu’un imagine ce qui pourrait mal tourner. La méthode n’est pas fiable. Les gens sous-estiment les menaces qu’ils n’ont pas rencontrées auparavant. L’entreprise dans son ensemble les a généralement déjà vues, mais sur un autre projet.

Des modèles avec une liste de risques types

Une liste de risques potentiels pour un type de projet donné peut être intégrée au modèle. Une équipe qui lance un déploiement client, un projet de recherche ou un investissement démarre avec une base prête et l’ajuste à son cas. Cela change la nature de la réunion. Au lieu d’inventer des menaces, l’équipe passe en revue celles qui sont connues et décide lesquelles s’appliquent. C’est plus rapide et plus efficace, surtout dans les équipes moins expérimentées.

La fiche de clôture et les rapports de risques

L’autre versant de ce mécanisme est d’enregistrer ce qui s’est réellement passé. La fiche de clôture du projet peut lister les risques survenus et la façon dont ils ont été résolus. Les équipes qui planifient des projets ultérieurs ont accès aux fiches de clôture historiques.

Le troisième élément, ce sont les rapports. Dans le module de rapports, vous pouvez construire une vue des risques pour les projets d’une catégorie ou d’un domaine de l’organisation. Une nouvelle équipe obtient une réponse concrète : voici les menaces survenues dans des projets similaires. Ensemble, ces trois mécanismes font que la gestion des risques ne dépend plus de la compétence d’un seul responsable.

Catégories de risques et vue pour les services

Le risque ne concerne que rarement le seul chef de projet. Le juridique veut savoir quelles obligations et quels litiges figurent dans le portefeuille. La production s’enquiert des défis technologiques, les achats des menaces du côté fournisseurs. Avec un registre enfermé dans un projet, aucun d’eux ne peut poser sa question.

Dans les paramètres de FlexiProject, vous définissez votre propre liste de catégories de risques, alignée sur la façon dont la responsabilité est répartie dans l’entreprise. C’est là qu’une structure de découpage des risques (RBS) cesse d’être un schéma et devient quelque chose sur quoi le système peut filtrer. C’est là-dessus que se construisent les rapports inter-projets. Le juridique voit les risques juridiques de tous les projets, la production les siens, les achats les leurs. Le risque cesse d’être l’affaire privée du chef de projet. À part, nous détaillons ce qu’est un vrai contrôle du budget de projet.

Niveau portefeuille, ou la fin de la gestion du même risque trois fois

Avec plusieurs dizaines de projets, certaines menaces se répètent par nature. Le même fournisseur, le même changement de réglementation, la même technologie immature. Si les registres sont enfermés dans les projets, chaque responsable tient sa propre version de ce risque et aboutit à des conclusions légèrement différentes.

Le logiciel de portefeuille de projets résout cela autrement. Chaque portefeuille dans FlexiProject a un onglet risques distinct. Il rassemble les menaces de tous les projets de ce portefeuille. Le coordinateur voit la répétition et peut résoudre le risque de façon centralisée, en s’appuyant sur tout le savoir disponible plutôt que sur une seule perspective. Un triple effort devient un responsable et une réponse. Cela supprime aussi la situation où trois projets appliquent trois stratégies différentes au même fournisseur. Nous décrivons à part ce que doit offrir une alternative à Asana pour un PMO.

Fini la ressaisie : la charte et le rapport de statut

L’économie la plus visible concerne la ressaisie, pas l’analyse. Dans beaucoup d’entreprises, la procédure exige que les risques les plus significatifs parviennent à la charte de projet et, une fois par mois, au rapport pour la direction. Avec un registre distinct, quelqu’un déplace les mêmes entrées à deux endroits et vérifie que les versions concordent.

Dans FlexiProject, le module de charte de projet tire les risques du registre automatiquement. Les deux documents sont cohérents par conception, non par la diligence de quelqu’un. Le reporting de statut cyclique fonctionne de la même façon. Si le rapport contient une section risques, elle se remplit d’elle-même depuis le registre, et il reste au responsable un commentaire sur la façon dont ces menaces sont gérées. Une activité qui ne créait aucune information nouvelle disparaît, et elle a disparu de la pire semaine du mois.

Quand un modèle suffit

Vous menez un projet, vous le gérez seul, vous avez une douzaine de risques et personne n’exige de reporting formel ? Un modèle de registre dans un outil de tâches suffit. Un module distinct ajoutera de la formalité, pas du contrôle, car les problèmes décrits ci-dessus apparaissent à plus grande échelle. Si vous voulez un regard plus large sur les options, nous avons comparé à part le meilleur logiciel de gestion des risques.

Les signaux que cette échelle est atteinte sont concrets. Un deuxième et un troisième projet apparaissent, et il faut comparer les risques entre eux. Quelqu’un hors du projet s’enquiert des menaces selon une coupe donnée. La procédure exige des risques dans la charte et dans le rapport. À partir de là, une liste avec des champs personnalisés coûte plus de travail qu’elle n’en fait économiser.

Comment le tester sur votre propre registre en deux semaines

Les comparaisons de fonctionnalités tranchent peu, car la page de chaque éditeur répond oui à tout. Un test sur vos propres données en dit plus. Prenez le registre d’un projet en cours et transférez-le en entier, avec votre échelle de notation. Cette première étape montre si votre matrice entre dans l’outil sans changer les habitudes de l’équipe.

Ensuite quatre tests. Liez trois risques à des tâches du planning et vérifiez que vous les voyez sur le diagramme de Gantt. Déplacez une de ces tâches de deux semaines et voyez si le tableau des menaces change. Construisez un rapport de risques pour une catégorie, les fournisseurs par exemple, couvrant plusieurs projets. Ouvrez l’onglet risques du portefeuille et vérifiez si une menace se répète à plusieurs endroits. Ce dernier test justifie généralement le changement à lui seul.

Questions fréquentes

Asana a-t-il un registre des risques ?

Asana propose un modèle de registre des risques et un modèle de matrice. Ils produisent une liste avec des champs comme probabilité, impact, responsable et plan de réponse. Ce n’est pas un module distinct, seulement un projet fait de tâches. Vous ne pouvez donc pas lier un risque à une tâche du planning, le comparer entre projets ni le voir au niveau portefeuille.

Quelle différence entre un registre des risques et une liste de tâches avec des champs personnalisés ?

La même différence qu’entre un risque et un travail à faire. Un registre traite le risque comme un objet distinct avec son propre cycle de vie, sa note, son responsable, son plan de réponse et ses liens au planning et au budget. Une liste de tâches vous laisse enregistrer cette information mais pas l’utiliser hors d’un projet.

Qu’apporte le lien d’un risque à une tâche du planning ?

Il montre où, dans le plan, se situe la menace. Dans FlexiProject, une tâche avec un risque lié porte une icône d’avertissement sur le diagramme de Gantt, et la couleur à côté indique si le risque est actif. Après chaque changement du planning, vous voyez quelles menaces sont devenues plus pressantes.

Pouvons-nous conserver notre propre matrice des risques ?

Oui. Les dimensions de la matrice se règlent au déploiement, donc une entreprise travaillant sur une échelle trois par trois n’a pas à passer à cinq par cinq. C’est l’une des conditions les plus importantes pour qu’un module de risques soit utilisé plutôt qu’évité.

Comment commencer si notre registre des risques est aujourd’hui dans Excel ?

En transférant un projet en cours, avec son échelle de notation et ses catégories actuelles. Le tableur contient généralement toutes les informations nécessaires. Ce qui lui manque, ce sont les liens : aux tâches, aux autres projets et aux documents que vous remplissez à la main de toute façon. Ces liens sont la raison de changer, non le simple fait de tenir un registre.

On cherche une alternative à Asana pour la gestion des risques du projet non parce qu’il n’y aurait nulle part où enregistrer une menace. La raison est autre : une menace enregistrée ne fait ensuite rien. Un registre qui est une liste s’arrête à la documentation. L’information existe, mais elle ne se relie pas au planning, ne s’additionne pas entre projets, ne revient pas à l’entreprise au projet suivant et doit être ressaisie dans chaque document séparément. Un registre qui est un module fait ces quatre choses de lui-même. Il laisse au responsable la seule chose qu’aucun système ne fera à sa place : décider comment répondre. Si votre registre est aujourd’hui surtout mis à jour avant le comité de pilotage, le moyen le moins cher de le vérifier est de transférer un projet et de lier trois risques à des tâches du planning.