Pilotage de projet : indicateurs, décisions et preuves
Un tableau de bord est utile s’il permet de décider. La maîtrise d’un programme se lit aussi dans ses hypothèses, ses dépendances et ses validations.
Publié le · À propos des dates
Mis à jour le
Le point de vue Spark
Le statut d’un projet doit aider à prendre une décision. Un indicateur vert qui mélange travaux réalisés, hypothèses et validations encore attendues donne une confiance difficile à justifier.
- Séparer l’avancement des travaux de la préparation du prochain jalon.
- Rendre visibles les preuves manquantes et les décisions attendues.
- Faire porter chaque action sur un responsable et une échéance utiles.
1. Distinguer le travail effectué de ce qui est démontré
Une interface développée peut ne pas avoir été testée avec son système destinataire. Une procédure rédigée peut ne pas être utilisable par l’équipe d’exploitation. Dans les deux cas, le travail existe, mais la préparation du service reste à établir.
Notre recommandation est de suivre deux questions : qu’a-t-on produit et qu’a-t-on effectivement validé ? Le premier axe renseigne l’exécution. Le second renseigne la possibilité de franchir le prochain jalon. Cette distinction évite de demander à un pourcentage d’avancement de résumer une situation qu’il ne décrit pas.
Elle ne suppose pas un nouveau dispositif lourd. Une ligne supplémentaire dans le support existant peut suffire, si l’équipe s’accorde sur ce que signifie « validé » et sur la personne qui peut le confirmer.
2. Organiser la revue autour de la décision suivante
Les revues de jalon du gouvernement britannique examinent les projets à des points de décision de leur cycle de vie. Ce principe relie l’assurance du projet au passage vers l’étape suivante. Voir le cadre des Gate Reviews.
Pour un projet IT, nous proposons une application légère : annoncer la décision à préparer, puis demander les éléments qui permettront de la prendre. Une revue de lancement de tests ne porte pas sur les mêmes preuves qu’une revue de mise en production.
| Sujet | Preuve attendue | Si elle manque |
|---|---|---|
| Périmètre | Critères de validation partagés. | Faire arbitrer les attentes divergentes. |
| Dépendance | Contribution confirmée par son responsable. | Préciser l’impact et l’alternative. |
| Réalisation | Résultat vérifié sur le périmètre concerné. | Planifier le contrôle manquant. |
| Exploitation | Responsabilités et moyens de support prêts. | Définir une condition de passage explicite. |
La grille ne produit pas une autorisation automatique. Elle rend la décision lisible et permet de conserver la raison d’un accord, d’un report ou d’une acceptation sous conditions.
3. Exemple : un test réussi sur le mauvais périmètre
Cette lecture évite aussi de dévaloriser le travail des équipes : un résultat partiel n’est pas un échec. Il devient un point d’appui quand son périmètre et ses limites sont clairement établis.
4. Transformer les risques en demandes d’action
« Risque sur les données » décrit un sujet, pas une action. Un risque devient exploitable lorsque l’équipe sait ce qui peut se produire, ce qui le rend plausible et ce qu’elle peut faire avant que la conséquence ne se réalise.
Nous proposons d’écrire chaque alerte sous une forme courte : condition observée, conséquence possible, action recommandée, responsable et date limite. Si un arbitrage est nécessaire, présenter les options et leurs conséquences au lieu de demander simplement une décision.
- Une action de correction traite un problème déjà constaté.
- Une action de réduction du risque vise une conséquence encore possible.
- Une décision d’acceptation explicite le risque conservé et son responsable.
Les trois peuvent coexister. Les distinguer permet de ne pas clôturer un risque au seul motif qu’une réunion a eu lieu ou qu’une tâche a été affectée.
5. Les six questions d’une revue utile
- Décision : quel passage ou quel engagement préparons-nous ?
- Critères : sur quoi repose l’acceptation de ce jalon ?
- Preuves : quels résultats sont disponibles et sur quel périmètre ?
- Inconnues : quelles hypothèses restent à vérifier ?
- Arbitrages : quelles options faut-il départager et avant quand ?
- Suite : qui fait quoi, et quand vérifie-t-on le résultat ?
Un chef de projet, un PMO et un responsable de programme peuvent contribuer différemment à cette discipline. Le rôle du PMO peut être de rendre l’information cohérente ; celui du chef de projet de coordonner les actions ; celui du décideur de trancher les engagements qui dépassent leur mandat.
Le bon support est celui qui permet à ces rôles de travailler ensemble. Ajouter des indicateurs sans améliorer les décisions ne constitue pas, en soi, un progrès de pilotage.
Source et périmètre
La référence publique porte sur les revues aux points de décision. La grille, la formulation des alertes et l’exemple sont des propositions éditoriales Spark, à adapter à votre gouvernance.
Lorsque la revue fait apparaître un choix à trancher, utilisez notre méthode pour préparer un arbitrage en comité projet : options, conséquences, recommandation et suivi des actions.
Retrouvez nos prochains points de vue Cloud, Data et Pilotage sur la page LinkedIn Spark Conseil.
