Nous sommes lundi matin. Vous avez passé la majeure partie de la journée de vendredi à obtenir des mises à jour de l'état d'avancement de la part de cinq chefs de projet différents, à réconcilier les dates d'étape sur trois feuilles de calcul et à faire en sorte qu'un rapport Power BI ne vous mette pas dans l'embarras devant le comité de direction. Le tableau de bord a l'air bien. Peut-être même bon. Et pourtant, la première question posée lors de la réunion est la suivante : "Pouvons-nous faire confiance à ces chiffres ?"
Cette question est le mode d'échec silencieux de la plupart des systèmes de rapports sur les portefeuilles de projets. Il ne s'agit pas d'une erreur technique. Pas de données manquantes. Juste une lente érosion de la confiance qui fait de votre rapport un point de départ pour le débat plutôt qu'une base pour les décisions.
Si cela vous semble familier, le problème n'est certainement pas Power BI. C'est la façon dont les rapports sur les portefeuilles sont structurés - et la raison pour laquelle les solutions habituelles ne font qu'empirer les choses.
Pourquoi les rapports sur les portefeuilles de projets s'arrêtent-ils dans Power BI ?
Il existe un ensemble spécifique de conditions qui transforment un tableau de bord de portefeuille Power BI en quelque chose qui génère plus de questions qu'il n'apporte de réponses. Aucune de ces conditions n'est évidente de l'extérieur, ce qui explique en partie pourquoi elles sont si persistantes.
1. Le modèle de données est conçu pour des projets individuels, pas pour des portefeuilles. La plupart des implémentations de Power BI dans des environnements de projet commencent par les données d'un projet - calendrier, budget, ressources - et s'étendent ensuite à un portefeuille en empilant d'autres données du même type. Le résultat est un rapport qui peut raisonnablement vous montrer l'état d'un projet individuel, mais qui s'effondre lorsque vous essayez de répondre à des questions au niveau du portefeuille : Quels sont les programmes qui risquent de ne pas respecter les engagements du troisième trimestre ? Où se situent les dépassements de budget dans le portefeuille ? Le modèle sous-jacent n'a jamais été conçu pour répondre à ces questions, et aucune nouvelle mesure ne pourra corriger une inadéquation structurelle.
2. Les données sur l'état de la situation ne sont pas cohérentes et personne n'est responsable du problème de qualité. Les rapports sur le portefeuille dépendent des chefs de projet qui soumettent en temps voulu des mises à jour honnêtes sur l'état d'avancement des projets. Dans la pratique, certains le font en avance, d'autres en retard, d'autres encore présentent des chiffres optimistes pour éviter l'escalade. Power BI rapporte consciencieusement tout ce qu'il reçoit. Le PMO finit par être responsable d'un rapport qu'il n'a pas entièrement contrôlé - et la direction finit par être sceptique face à des chiffres qui peuvent ou non refléter la réalité. Il ne s'agit pas d'un problème humain. Il s'agit d'un problème de processus et de gouvernance dont hérite la couche de reporting.
3. Le rapport tente de s'adresser à trop de publics à la fois. Les gestionnaires de projets opérationnels ont besoin de détails au niveau des tâches. Les gestionnaires de programme ont besoin d'un suivi des étapes. Le comité de pilotage a besoin d'un statut RAG au niveau du portefeuille et d'une exposition financière. Lorsqu'un rapport Power BI tente de faire tout cela - généralement par le biais d'un ensemble tentaculaire de pages et de filtres - il finit par n'en faire aucun particulièrement bien. Les utilisateurs exécutifs cessent de le consulter parce que trouver ce dont ils ont besoin prend trop de temps. Les chefs de projet l'ignorent parce que les détails ne correspondent pas à leur travail. Et le PMO se retrouve à gérer un rapport dont personne n'est pleinement satisfait.
Ce que la plupart des OMP essaient d'abord - et pourquoi cela ne fonctionne pas
Lorsqu'un tableau de bord de portefeuille n'est pas satisfaisant, l'instinct veut que l'on en rajoute. Plus de filtres. Plus d'explorations. Des colonnes d'état codées par couleur qui s'étendent sur trois niveaux de hiérarchie. Une mise en forme conditionnelle qui surligne tout en rouge jusqu'à ce que plus rien ne ressorte. J'ai vu des rapports de dix-sept pages dans lesquels les cadres naviguaient en demandant au PMO de partager leur écran et de cliquer pour eux.
L'autre solution consiste à reconstruire le pipeline de données. Nouvelle structure SharePoint. Nouvelles transformations Power Query. Parfois, un véritable entrepôt de données. C'est parfois la bonne solution, mais il s'agit d'un projet de plusieurs mois qui n'explique pas pourquoi le rapport existant n'est pas fiable. Vous pouvez avoir des données parfaitement propres qui alimentent un rapport qui ne parvient toujours pas à prendre des décisions.
Il existe également un modèle qui mérite d'être cité : le remplacement de Power BI par un outil PPM dédié, pour se retrouver avec les mêmes problèmes de reporting dans une nouvelle interface. L'outil change. Les questions sous-jacentes sur ce que les dirigeants ont réellement besoin de voir, et sur la manière dont les données circulent entre les projets et le portefeuille, restent sans réponse.
Pour être honnête, il n'y a pas de solution miracle. Les problèmes liés aux rapports de portefeuille sont toujours en partie un problème de données, en partie un problème de processus et en partie un problème de conception. Quiconque vous dit le contraire simplifie à l'extrême. Mais la couche de conception est généralement la plus rapide à résoudre, et elle est presque toujours abordée en dernier.
Ce qui aide vraiment : Concevoir pour la décision, pas pour les données
Le cadre le plus utile est de partir des questions réelles du comité de pilotage - les trois ou quatre choses qu'il doit décider à la sortie d'une réunion - et de concevoir à l'envers à partir de là. Il ne s'agit pas de se demander "quelles sont les données dont nous disposons", mais plutôt "qu'est-ce qu'un propriétaire de portefeuille a besoin de voir pour décider d'accepter ou de refuser un programme retardé ?
Dans la pratique, cela signifie généralement une séparation nette entre la vue exécutive et la vue opérationnelle. La couche de pilotage a besoin d'une agrégation au niveau du portefeuille : santé globale du calendrier, exposition du budget par programme, un signal clair sur les projets qui sont des candidats à l'escalade. Elle doit pouvoir être lue en moins de deux minutes sans avoir à cliquer sur quoi que ce soit. La couche opérationnelle - celle que les chefs de projet et les responsables de programme utilisent réellement - peut contenir les détails. Il s'agit de deux publics différents avec des besoins différents, et essayer de servir les deux dans un seul rapport est la raison pour laquelle la plupart des tableaux de bord de portefeuille Power BI se trompent.
Les choix de visualisation ont plus d'importance que la plupart des PMO ne le réalisent. Un feu tricolore qui n'indique pas la tendance - si un projet vient de passer à l'orange ou s'il est à l'orange depuis six semaines - est moins utile qu'il n'y paraît. Une vue d'ensemble des jalons de type Gantt qui montre les écarts de calendrier dans l'ensemble du portefeuille communique quelque chose qu'un tableau de dates ne peut pas communiquer. Le choix du visuel n'est pas une question de décoration ; c'est la différence entre un rapport qui incite à prendre une décision et un rapport qui incite à poser une question.
C'est dans ce domaine que les visuels Power BI spécialement conçus pour les contextes de gestion de projet font une réelle différence. LeapLytics construit des visuels certifiés et personnalisés spécifiquement pour cela - des choses comme Graphique de Gantt et des indicateurs lumineux conçus pour le reporting de portefeuille, et non pas adaptés à partir de cas d'utilisation génériques de BI. Ils ne résolvent pas le problème du modèle de données ni celui de la gouvernance, mais lorsque la structure est adéquate, ils rendent les résultats beaucoup plus lisibles pour les personnes les plus importantes.
Avant et après : Ce qui change lorsque les rapports de portefeuille fonctionnent réellement
Un PMO d'infrastructure de taille moyenne - environ 40 projets actifs répartis sur quatre programmes - en est arrivé à un point où l'examen mensuel du portefeuille prenait trois heures au lieu de quatre-vingt-dix minutes, principalement parce que chaque état rapporté déclenchait une discussion de suivi pour savoir si les chiffres étaient à jour. Les chefs de projet soumettaient les mises à jour par courrier électronique. Le PMO mettait à jour manuellement un fichier Excel principal. Power BI lisait ce fichier. La chaîne introduisait au moins une semaine de décalage entre la réalité et le rapport.
La refonte comportait trois parties : un processus standardisé de soumission de l'état d'avancement avec une date limite fixée au vendredi que Power BI lisait directement, une séparation claire entre un one-pager exécutif (portefeuille RAG, cinq principaux risques, variance budgétaire par programme) et une vue opérationnelle au niveau du programme, et le remplacement d'un diagramme générique à barres empilées par une ligne de temps appropriée qui montrait l'écart de calendrier d'un seul coup d'œil.
La réunion de pilotage est passée de trois heures à soixante-dix minutes. Plus important encore, la question d'ouverture a cessé d'être "pouvons-nous faire confiance à ces données ?" pour devenir "que faisons-nous à propos du programme B ?". Ce changement - de la validation des données à la prise de décision - est l'objectif réel. Tout le reste n'est qu'infrastructure.
Selon le Recherche du PMI sur l'efficacité des PMOLes organisations qui disposent d'un processus de reporting de portefeuille mature réalisent beaucoup plus de projets dans les délais et dans les limites du budget. Ce n'est pas le reporting en lui-même qui en est la cause, mais un mauvais reporting dissimule activement les signaux qui permettraient d'intervenir plus tôt.
Par où commencer ?
Si votre rapport sur le portefeuille génère plus de débats en réunion que de décisions de pilotage, le diagnostic le plus rapide consiste à se demander ce que le comité exécutif décide réellement sur la base de ce rapport. Si la réponse honnête est "pas grand-chose", le rapport ne fait pas son travail - quelle que soit la solidité technique de la création Power BI sous-jacente.
Commencez par là. Définissez les trois décisions que le comité de pilotage doit prendre chaque mois. Construisez à l'envers. Ensuite, préoccupez-vous des visuels.
Si vous avez déjà dépassé ce stade et que le goulot d'étranglement est la couche Power BI elle-même, l'option Bibliothèque visuelle LeapLytics vaut le coup d'œil - conçu spécialement pour les contextes de rapports de gestion de projet, certifié par Microsoft et disponible directement à l'essai. Commencez un essai gratuit ici et testez-les par rapport aux données réelles de votre portefeuille.
