Risques, problèmes et demandes de modification
en éléments distincts, pas en tâches.
Ce qui pourrait arriver, ce qui est arrivé et ce que vous demandez de changer reçoivent chacun l’élément dont leur rôle a besoin, lié aux autres, pour que la liste des tâches reste une liste de travail.
Ce que vous obtenez
Des éléments distincts, liés
Un risque peut devenir un problème, un problème peut donner lieu à une demande de modification, et chaque élément garde le lien vers son origine.
Un registre des risques sur chaque projet
Notez ce qui pourrait mal tourner, avec une gravité, une catégorie (planning, ressources, budget, périmètre ou externe), les tâches concernées et ce qu’il faut faire. Modifiez-le quand il évolue, et ignorez ce qui ne s’applique plus.
Détection des risques par IA
Lancez une analyse et l’IA lit le plan à la recherche de risques de planning, de budget, de ressources et de périmètre, chacun avec une mesure d’atténuation proposée, que vous gardez ou ignorez.
Un journal des problèmes pour ce qui est arrivé
9 types de problème, 4 niveaux de gravité et un cycle de vie qui va d’Ouvert à En investigation, puis à Résolu et Clôturé, par projet et pour toute l’organisation.
Quand un risque survient, promouvez-le
Promouvez un risque et un problème est rédigé à partir de lui, en attente d’acceptation. Le problème accepté garde le lien vers son risque, et le risque est marqué comme résolu. Quand la réponse est du travail, transformez plutôt le risque en tâche.
Des demandes de modification avec leur impact
Demandez à changer le périmètre, le calendrier, le budget ou les ressources dans un élément à part, avec l’impact en jours et en argent écrit avant que quiconque l’approuve.
Un comité de contrôle des changements qui décide
Les chefs de projet, les membres du comité de l’organisation ou des réviseurs désignés approuvent ou rejettent. Un changement approuvé est marqué comme mis en œuvre, et chaque étape reste dans son historique.
Des demandes de modification qui nomment leur cause
Quand résoudre un problème oblige à changer le plan, créez la demande de modification depuis le problème, et chaque demande de modification liste les problèmes qui l’ont motivée.
Les risques dans la date de fin
Donnez à un risque une probabilité et un impact en jours ouvrés, et la simulation de Monte-Carlo en tient compte pour calculer la probabilité de tenir la date du plan.
Pourrait arriver, est arrivé, demande un changement
Chaque élément répond à une autre question
Le Guide PMBOK les sépare pour une bonne raison : ils sont examinés par des personnes différentes, à des moments différents, pour des décisions différentes.
Un risque demande ce que nous ferons s’il survient, il porte donc une gravité, une catégorie et une recommandation.
Un problème demande qui le corrige et pour quand, il porte donc un type, une gravité, un responsable et un statut d’ouvert à clôturé.
Une demande de modification demande si nous acceptons de changer le plan, elle porte donc l’impact en jours et en argent et une décision avec son historique.
Gratuit, sans compte
Voyez le risque dans un planning que vous avez déjà
Importez un fichier Microsoft Project ou Primavera et obtenez les dates de fin qu’il atteindra probablement, ou les problèmes cachés dans sa logique.
Questions sur les risques, les problèmes et les demandes de modification
De quel forfait ai-je besoin ?
Le registre des risques fonctionne sur tous les forfaits, avec ou sans IA, et le journal des problèmes est disponible sur tous les forfaits, y compris le forfait gratuit. La détection des risques par IA est disponible à partir du forfait Professional, et la prise en compte des risques dans la date de fin de Monte-Carlo à partir du forfait Professional. Les demandes de modification et le comité de contrôle des changements sont disponibles à partir du forfait Enterprise.
Quelle différence entre un risque, un problème et une demande de modification ?
Un risque est quelque chose qui pourrait arriver, vous décidez donc à l’avance ce que vous ferez. Un problème est déjà arrivé et a besoin d’un responsable et d’une solution. Une demande de modification demande de changer ce qui avait été convenu, son périmètre, ses dates, son budget ou ses personnes, et a besoin d’une décision. En les tenant comme des éléments distincts, chacun a les champs et le cycle de vie dont son rôle a besoin.
Pourquoi ne pas tout suivre comme des tâches ?
Une tâche, c’est du travail à faire. Un risque n’en demandera peut-être jamais, un problème a besoin d’une gravité et d’une résolution, et une demande de modification a besoin d’un impact et d’une approbation. Mettez tout cela dans la liste des tâches et le planning se remplit d’éléments qui ne sont pas du travail, tandis que le registre que demande un sponsor n’existe pas. Dans Onplana, un risque ne devient une tâche que lorsque la réponse à ce risque est du travail.
Que se passe-t-il quand un risque se réalise ?
Promouvez-le en problème. Onplana rédige le problème à partir de la description et de la recommandation du risque, et une fois que quelqu’un l’accepte, le problème garde le lien vers le risque et le risque est marqué comme résolu, si bien que le registre montre quels risques sont devenus des problèmes. Si traiter le problème oblige à changer le plan, créez une demande de modification depuis le problème.
L’IA décide-t-elle quels risques comptent ?
Non. L’analyse propose des risques avec une mesure d’atténuation pour chacun, et ils restent dans le registre pour qu’une personne les garde, les modifie ou les ignore. Rien n’atteint le plan tant que personne n’a agi.
Donnez au sponsor un registre, pas une liste de tâches.
Commencez gratuitement avec le registre des risques et le journal des problèmes, et ajoutez le contrôle des changements quand le programme a besoin d’un comité.