Gérer incidents, risques et demandes de modification

Un projet ne se brise pas sur une grande catastrophe, mais sur de petites choses que personne ne range : une anomalie sans responsable, un risque prévisible que personne n’a noté, une demande du client acceptée de vive voix. Tout mélanger dans une liste de points en suspens efface la différence entre l’urgent et l’important. PjMan donne à chaque chose son propre registre dans chaque projet, avec les champs qui lui conviennent : incidents pour ce qui s’est déjà produit, risques pour ce qui pourrait arriver et demandes de modification pour ce qu’on demande hors du périmètre convenu. Si vous hésitez sur lequel est lequel, le guide incident, risque ou demande de modification l’explique avec des exemples.

Incidents : ce qui s’est déjà produit

Un incident est quelque chose qui s’est déjà produit (une anomalie, un blocage, une erreur de données) et qu’il faut résoudre. C’est une entité indépendante des tâches. (Incidents)

• Statut configurable. Les statuts forment un catalogue de l’organisation géré par le PM ; par défaut Ouvert, En analyse, En résolution, Résolu et Clos. Chaque statut peut être marqué comme final.
• Gravité et priorité, séparément. La gravité du problème et l’urgence avec laquelle on le traite sont deux axes distincts : un incident peut être grave sans être urgent.
• Affectés et heures. Ils sont affectés à une ou plusieurs personnes, avec ou sans compte, et l’on y saisit des heures, avec une estimation facultative, pour savoir ce que coûte leur résolution.
• Dates de détection et de clôture. La clôture se pose automatiquement au passage à un statut final et s’efface à la réouverture.
• Lien avec la phase ou la tâche concernée, et étiquettes pour les regrouper selon votre critère.
• Liste et tableau Kanban, avec les mêmes incidents en colonnes de statut. (Kanban et Gantt)
• Commentaires sur chaque incident, avec des mentions @ qui préviennent dans l’application.

Ils peuvent être créés par le PM propriétaire, la direction du projet (pour signaler ce qu’elle détecte) et les consultants dans les projets où une tâche leur est affectée, avec des limites. C’est le seul des trois qu’un consultant peut ouvrir.

Risques : ce qui pourrait arriver

Un risque est quelque chose qui pourrait se produire et qui affecterait le projet. Il sert à anticiper. (Risques)

• Probabilité et impact, trois niveaux chacun, et une priorité de faible à critique. Ce sont trois données indépendantes que vous fixez : PjMan ne calcule pas d’exposition ni ne dessine de matrice, et la priorité décide de ce qu’on traite d’abord.
• Statut : identifié, suivi, atténué ou clos.
• Plan de contingence ou de mitigation, pour que le risque ne soit pas qu’une inquiétude écrite.
• Lien facultatif avec une phase ou une tâche.

Quand un risque se réalise, il s’enregistre comme incident. Le guide sur le registre des risques explique comment les identifier et les prioriser.

Demandes de modification : ce qu’on demande hors périmètre

Une demande de modification est une demande hors du périmètre convenu : une fonctionnalité nouvelle, un rapport supplémentaire, un changement d’avis du client. L’enregistrer garde la trace de qui l’a demandée, de ce qu’elle coûterait et de ce qui a été décidé, avant qu’elle n’entre dans le plan. (Demandes de modification)

• Demandeur (texte libre, pas forcément un utilisateur), description, effort estimé en heures, coût et délai estimés (texte libre).
• Un circuit simple : toute demande naît en attente et est approuvée ou refusée avec un sélecteur dans le tableau même ; on conserve qui a décidé et quand.
• Approuver ne crée rien en soi : c’est la trace de la décision ; les tâches ou phases qui en découlent, vous les créez dans le plan.

Le guide sur les demandes de modification explique comment les gérer pour que le périmètre ne dérape pas.

Du compte rendu ou du courriel au registre

Les trois registres peuvent être alimentés sans saisir chaque champ. Si vous collez dans l’assistant les notes d’une réunion ou un courriel de demandes, l’assistant peut vous proposer d’un coup le compte rendu, les tâches de suivi, les risques et les demandes de modification qu’il voit dans le texte, sur une seule carte de confirmation. Rien n’est créé tant que vous ne confirmez pas. (Texte collé) Et avant une réunion de suivi, l’assistant rassemble les incidents graves ouverts, les risques et les demandes de modification non résolues, avec le nombre de jours en attente.

Tout voir ensemble

• Rapports rassemble les indicateurs d’incidents : ouverts, clos, délai moyen de résolution, heures saisies et non affectés, avec leur répartition par projet ou par phase. (Rapports et requêtes)
• Requêtes permet de filtrer les incidents de tous vos projets par statut, gravité, personne, étiquettes et dates, et de les exporter vers un tableur.
• Le résumé du projet montre combien il y en a de chaque type et renvoie à chaque registre.
• L’état du projet donné par l’assistant inclut les incidents ouverts par gravité, les risques et les demandes en attente.

Chaque rôle voit ce qui lui correspond

Le PM propriétaire gère tout. La direction du projet voit les trois registres en lecture seule et peut créer des incidents. Un consultant voit les incidents qui le concernent et peut en créer liés à son travail, mais n’a pas accès aux risques ni aux demandes de modification. (Rôles et droits)

Essayez

Créez votre compte, ouvrez un projet et enregistrez un incident, un risque et une demande de modification. Ou explorez la démo avec ses données d’exemple.