Guide de la gestion de projet · Risques, qualité et maîtrise
Registre des problèmes : modèle, exemples et gestion des problèmes du projet
Un registre des problèmes est le document dans lequel un projet consigne les problèmes qui se produisent maintenant et nécessitent une action, avec leur priorité, leur responsable, leurs actions et leur statut. Il garantit que rien de ce qui a été signalé n'est oublié et que chaque problème est résolu, remonté ou clôturé de manière délibérée.
À retenir
- Un registre des problèmes suit les problèmes qui se produisent maintenant.
- Chaque problème doit avoir un impact, une priorité, un responsable, une action et une date.
- Faites remonter les problèmes qui dépassent le pouvoir du chef de projet.
- Reliez les risques réalisés aux nouveaux problèmes et bouclez la boucle avec les retours d'expérience.
Ce qui constitue un problème
Un problème est toute difficulté, question, préoccupation ou demande de changement actuelle que le projet doit traiter. Contrairement à un risque projet, il n'est pas incertain : il s'est déjà produit ou se produira avec certitude.
- Problèmes : un environnement de test est hors service, un fournisseur a manqué une livraison, une personne clé est en arrêt maladie.
- Préoccupations : une partie prenante est mécontente de la conception proposée.
- Non-conformités : un livrable ne satisfait pas à ses critères d'acceptation.
- Demandes de changement : dans certaines méthodes, dont PRINCE2, les demandes de changement sont aussi enregistrées comme un type de problème avant de passer par la maîtrise des changements.
Modèle de registre des problèmes : colonnes
| Colonne | Ce qu'il faut consigner |
|---|---|
| ID | Référence unique, p. ex. I-021 |
| Date de signalement | Date d'enregistrement du problème |
| Signalé par | Qui l'a signalé |
| Type | Problème, préoccupation, non-conformité, demande de changement |
| Description | Ce qui ne va pas, où, et les éléments de preuve |
| Impact | Effet sur le périmètre, les délais, les coûts, la qualité ou les bénéfices |
| Priorité | Critique, élevée, moyenne ou faible, selon des définitions convenues |
| Responsable | Personne nommément responsable de sa résolution |
| Actions | Étapes convenues, chacune avec une date |
| Date de résolution cible | Quand il doit être résolu |
| Remonté à | Sponsor ou comité, si cela dépasse le pouvoir du chef de projet |
| Statut | Ouvert, en cours, remonté, résolu, clôturé |
| Résolution | Ce qui a été fait et la date de clôture |
Exemples d'entrées
| ID | Description | Priorité | Responsable | Action | Statut |
|---|---|---|---|---|---|
| I-007 | L'environnement sandbox de la passerelle de paiement renvoie des erreurs pour les remboursements par carte, ce qui bloque 14 cas de test. | Haute | Responsable de l'intégration | Ouvrir un ticket auprès du fournisseur ; tester d'abord les autres cas | En cours |
| I-008 | Le responsable financier est indisponible pendant trois semaines ; l'approbation du budget de la phase 2 est retardée. | Moyenne | Chef de projet | Demander au sponsor de désigner un approbateur suppléant | Remonté |
| I-009 | La salle de formation réservée pour la semaine de mise en service a été réservée deux fois. | Basse | Coordinateur de la formation | Réserver une autre salle | Résolu |
| I-010 | Les étiquettes livrées portent l'ancien logo ; 2,000 unités concernées. | Haute | Responsable qualité | Refuser le lot ; le fournisseur réimprime d'ici le 21 juin | Ouvert |
Comment gérer les problèmes étape par étape
- Enregistrer : enregistrez chaque problème dès qu'il est signalé, même s'il semble mineur.
- Évaluer : décrivez l'impact et convenez d'une priorité à l'aide de critères définis.
- Attribuer : attribuez au problème un responsable unique et une date cible.
- Agir : convenez des actions et mettez-les en œuvre ; vérifiez si une plan de contingence existe déjà à ce sujet.
- Faire remonter : si sa résolution devait dépasser les tolérances convenues ou exige des décisions au-delà du pouvoir du chef de projet, faites-le remonter au sponsor ou à l'instance de gouvernance compétente.
- Surveiller : examinez les problèmes ouverts à chaque réunion d'équipe et signalez les plus prioritaires dans le rapport d'avancement de projet.
- Clôturer : consignez la résolution, confirmez-la avec la personne qui a signalé le problème et recueillez les éventuels retour d'expérience.
Registre des problèmes vs registre des risques
| Registre des problèmes | Registre des risques | |
|---|---|---|
| Moment | Maintenant | Futur |
| Certitude | S'est produit ou se produira avec certitude | Pourrait se produire |
| Champ principal | Priorité et résolution | Probabilité, impact et réponse |
| Objectif | Résoudre ou décider | Prévenir, réduire ou se préparer |
Lorsqu'un risque se réalise, clôturez-le dans le registre des risques (en le marquant « réalisé ») et ouvrez une entrée liée dans le registre des problèmes. De nombreuses équipes tiennent les deux au sein d'un même registre RAID.
Conseils
- Définissez les priorités en termes concrets, par exemple « critique » signifie que le travail sur le chemin critique est à l'arrêt.
- Rédigez des descriptions factuelles et évitez de désigner des coupables.
- Ne laissez pas de problèmes sans responsable ni date : ce sont ceux qui prennent de l'ampleur.
- Recherchez des schémas récurrents. Plusieurs problèmes ayant la même cause peuvent révéler un problème plus profond, qu'il vaut la peine d'analyser à l'aide d'un diagramme d'Ishikawa.
Modèles gratuits sur ce sujet
Questions fréquentes
Qu'est-ce qu'un registre des problèmes ?
Un registre des problèmes, préoccupations et demandes actuels du projet, avec leur priorité, leur responsable, leurs actions et leur statut.
Quelle est la différence entre un problème et un risque dans un registre des problèmes ?
Un problème se produit maintenant ; un risque est incertain et futur. Un risque qui se réalise devient un problème.
Que doit contenir un registre des problèmes ?
Au minimum un identifiant, une description, l'impact, la priorité, le responsable, les actions, la date cible et le statut. De nombreuses équipes consignent aussi qui l'a signalé et la résolution finale.
Qui tient le registre des problèmes ?
Le chef de projet ou le coordinateur de projet, chaque responsable mettant à jour l'avancement de ses propres problèmes.
Comment prioriser les problèmes dans un registre des problèmes ?
Utilisez des critères convenus fondés sur l'effet sur les objectifs, par exemple si le travail sur le chemin critique est à l'arrêt, le coût en jeu et le nombre de personnes concernées.
Quand faut-il faire remonter un problème du registre des problèmes ?
Lorsque sa résolution exige un pouvoir, des fonds ou des décisions qui dépassent les tolérances convenues du chef de projet.
Un registre des problèmes est-il la même chose qu'un registre des anomalies ?
Pas tout à fait. Un registre des anomalies suit les défauts d'un produit ; un registre des problèmes couvre tout problème affectant le projet, ce qui peut inclure des anomalies graves.
Peut-on tenir un registre des problèmes dans Excel ?
Oui. Un tableur convient à la plupart des projets. De nombreux outils de gestion de projet proposent aussi des fonctions de suivi des problèmes ou de tickets.
À quelle fréquence faut-il revoir le registre des problèmes ?
Les problèmes hautement prioritaires peuvent exiger une attention quotidienne ; l'ensemble du registre est généralement revu à chaque réunion de projet hebdomadaire.
Qu'est-ce qu'un registre des problèmes dans PRINCE2 ?
PRINCE2 utilise un registre des problèmes pour les problèmes gérés formellement, les problèmes informels étant consignés dans le journal quotidien.
Les équipes agiles utilisent-elles des registres des problèmes ?
Les équipes agiles suivent généralement les blocages sur leur tableau et les signalent lors du Daily Scrum, mais un registre distinct reste courant pour les problèmes nécessitant une escalade.