\u00c8 luned\u00ec mattina. Avete trascorso la maggior parte del venerd\u00ec a raccogliere aggiornamenti sullo stato di cinque diversi project manager, a riconciliare le date delle milestone in tre fogli di calcolo e a trasformare un report di Power BI in qualcosa che non vi metta in imbarazzo di fronte al comitato esecutivo. Il dashboard sembra a posto. Forse anche bene. Eppure, la prima domanda della riunione \u00e8: \"Possiamo fidarci di questi numeri?\".<\/p>\n
Questa domanda \u00e8 la modalit\u00e0 di fallimento silenziosa della maggior parte delle configurazioni di reporting del portafoglio progetti. Non un errore tecnico. Non si tratta di dati mancanti. Solo una lenta erosione della fiducia che rende il vostro report un punto di partenza per il dibattito piuttosto che una base per le decisioni.<\/p>\n
Se questo vi suona familiare, il problema quasi certamente non \u00e8 Power BI. \u00c8 il modo in cui \u00e8 strutturata la reportistica di portafoglio e perch\u00e9 le solite soluzioni continuano a peggiorare le cose.<\/p>\n
Esiste una serie specifica di condizioni che trasforma un dashboard di portfolio in Power BI in qualcosa che genera pi\u00f9 domande che risposte. Nessuna di queste \u00e8 ovvia dall'esterno, e questo \u00e8 uno dei motivi per cui sono cos\u00ec persistenti.<\/p>\n
1. Il modello di dati \u00e8 costruito per singoli progetti, non per portafogli.<\/strong> La maggior parte delle implementazioni di Power BI in ambienti di progetto iniziano con i dati di un progetto (calendario, budget, risorse) e poi vengono espanse per coprire un portafoglio, impilando altri dati dello stesso tipo. Il risultato \u00e8 un report che pu\u00f2 mostrare ragionevolmente bene lo stato dei singoli progetti, ma che crolla quando si cerca di rispondere a domande a livello di portafoglio: Quali programmi rischiano di non rispettare gli impegni del terzo trimestre? Dove si concentra il superamento del budget nel portafoglio? Il modello sottostante non \u00e8 mai stato concepito per rispondere a queste domande e nessuna nuova misura potr\u00e0 risolvere un disallineamento strutturale.<\/p>\n 2. I dati di stato arrivano in modo incoerente e nessuno \u00e8 responsabile del problema della qualit\u00e0.<\/strong> La rendicontazione del portafoglio dipende dalla presentazione da parte dei project manager di aggiornamenti tempestivi e onesti sullo stato di avanzamento. In pratica, alcuni inviano in anticipo, altri in ritardo, altri ancora presentano numeri ottimistici per evitare escalation. Power BI riporta doverosamente tutto ci\u00f2 che riceve. Il PMO finisce per essere responsabile di un report che non ha controllato completamente e la leadership finisce per essere scettica su numeri che possono o meno riflettere la realt\u00e0. Non \u00e8 un problema di persone. \u00c8 un problema di processo e di governance che il livello di reporting eredita.<\/p>\n 3. Il rapporto cerca di servire troppi destinatari contemporaneamente.<\/strong> I project manager operativi hanno bisogno di dettagli a livello di attivit\u00e0. I responsabili di programma hanno bisogno di un monitoraggio delle milestone. Il comitato direttivo ha bisogno dello stato RAG del portafoglio e dell'esposizione finanziaria. Quando un report di Power BI cerca di fare tutto questo, di solito attraverso una serie di pagine e filtri, finisce per non fare nulla di particolare. Gli utenti esecutivi smettono di guardarlo perch\u00e9 trovare ci\u00f2 di cui hanno bisogno richiede troppo tempo. I project manager lo ignorano perch\u00e9 i dettagli sono sbagliati per il loro lavoro. E il PMO si ritrova a gestire un report di cui nessuno \u00e8 pienamente soddisfatto.<\/p>\n Quando il cruscotto di un portafoglio non funziona, l'istinto \u00e8 quello di aggiungere altro. Pi\u00f9 filtri. Altri drill-through. Colonne di stato codificate per colore che scendono a cascata attraverso tre livelli di gerarchia. Formattazione condizionale che evidenzia tutto in rosso finch\u00e9 non spicca nulla. Ho visto rapporti con diciassette pagine che i dirigenti hanno navigato chiedendo al PMO di condividere il loro schermo e di cliccare per loro.<\/p>\n L'altra mossa comune \u00e8 quella di ricostruire la pipeline dei dati. Nuova struttura SharePoint. Nuove trasformazioni di Power Query. A volte un vero e proprio data warehouse. A volte questa \u00e8 la scelta giusta, ma si tratta di un progetto lungo mesi che non affronta il motivo per cui il report esistente non \u00e8 attendibile. \u00c8 possibile avere dati perfettamente puliti che alimentano un report che non riesce comunque a prendere decisioni.<\/p>\n C'\u00e8 anche uno schema che merita di essere citato: la sostituzione di Power BI con uno strumento PPM dedicato, per poi ritrovarsi con gli stessi problemi di reporting in una nuova interfaccia. Lo strumento cambia. Le questioni di fondo su ci\u00f2 che la leadership ha effettivamente bisogno di vedere e su come i dati fluiscono dai progetti al portafoglio rimangono irrisolte.<\/p>\n In tutta onest\u00e0, non esiste una pallottola d'argento. I problemi di reporting del portafoglio sono sempre in parte un problema di dati, in parte un problema di processo e in parte un problema di progettazione. Chiunque vi dica il contrario sta semplificando eccessivamente. Ma il livello di progettazione \u00e8 di solito il pi\u00f9 veloce da risolvere, e quasi sempre viene affrontato per ultimo.<\/p>\n La cornice pi\u00f9 utile \u00e8 partire dalle domande reali del comitato direttivo - le tre o quattro cose che devono uscire da una riunione avendo deciso - e progettare a ritroso da l\u00ec. Non \"quali dati abbiamo\", ma \"che cosa deve vedere il proprietario di un portafoglio per prendere una decisione su un programma in ritardo?\".<\/p>\n In pratica, questo significa di solito una separazione rigida tra la visione esecutiva e quella operativa. Il livello direttivo ha bisogno di un'aggregazione a livello di portafoglio: lo stato di salute generale delle scadenze, l'esposizione del budget per programma, un segnale chiaro su quali progetti sono candidati all'escalation. Dovrebbe essere leggibile in meno di due minuti senza dover fare clic su nulla. Il livello operativo - quello che i project manager e i responsabili di programma utilizzano effettivamente - pu\u00f2 contenere i dettagli. Si tratta di due pubblici diversi con esigenze diverse, e cercare di soddisfarle entrambe in un unico report \u00e8 il punto in cui la maggior parte dei dashboard di portfolio di Power BI fallisce.<\/p>\n Le scelte di visualizzazione contano pi\u00f9 di quanto la maggior parte dei PMO si renda conto. Un semaforo che non mostra l'andamento, se un progetto \u00e8 appena diventato giallo o lo \u00e8 stato per sei settimane, \u00e8 meno utile di quanto sembri. Una panoramica di milestone in stile Gantt che mostri lo scostamento delle scadenze in tutto il portafoglio comunica qualcosa che una tabella di date non pu\u00f2 comunicare. La scelta della visualizzazione non \u00e8 una decorazione: \u00e8 la differenza tra un report che spinge a prendere una decisione e uno che spinge a fare una domanda.<\/p>\n Questo \u00e8 il settore in cui le visualizzazioni di Power BI appositamente create per i contesti di gestione dei progetti fanno la differenza. LeapLytics costruisce visualizzazioni certificate e personalizzate proprio per questo, come ad esempio Grafici di Gantt<\/a> e indicatori semaforici progettati per la reportistica di portafoglio, non riproposti da casi d'uso generici della BI. Non risolvono il problema del modello dei dati o della governance, ma quando la struttura \u00e8 corretta, rendono l'output molto pi\u00f9 leggibile per le persone che contano di pi\u00f9.<\/p>\n Un PMO di infrastrutture di medie dimensioni (circa 40 progetti attivi su quattro programmi) \u00e8 arrivato a un punto in cui la revisione mensile del portafoglio richiedeva tre ore invece di novanta minuti, soprattutto perch\u00e9 ogni stato di avanzamento dei lavori comportava una discussione successiva per verificare se i numeri fossero aggiornati. I project manager inviavano gli aggiornamenti via e-mail. Il PMO aggiornava manualmente un file Excel principale. Power BI leggeva da quel file. La catena introduceva almeno una settimana di ritardo tra la realt\u00e0 e il report.<\/p>\n La riprogettazione si \u00e8 articolata in tre parti: un processo standardizzato di presentazione dello stato di avanzamento con un termine fisso al venerd\u00ec che Power BI leggeva direttamente, una chiara separazione tra un one-pager esecutivo (RAG del portafoglio, cinque rischi principali, scostamento del budget per programma) e una vista operativa a livello di programma, e la sostituzione di un generico grafico a barre impilate con un'adeguata visualizzazione della timeline delle milestone che mostrava lo scostamento della schedulazione a colpo d'occhio.<\/p>\n La riunione di direzione \u00e8 passata da tre ore a settanta minuti. Cosa ancora pi\u00f9 importante, la domanda iniziale ha smesso di essere \"possiamo fidarci di questo?\" e ha iniziato a essere \"cosa facciamo con il Programma B?\". Questo passaggio - dalla convalida dei dati alla presa di decisioni - \u00e8 l'obiettivo reale. Tutto il resto \u00e8 infrastruttura.<\/p>\n Secondo Ricerca PMI sull'efficacia del PMO<\/a>Le organizzazioni con processi maturi di reporting del portafoglio completano un numero significativamente maggiore di progetti nei tempi e nei budget previsti. Non \u00e8 il reporting in s\u00e9 la causa, ma un cattivo reporting nasconde attivamente i segnali che consentirebbero di intervenire prima.<\/p>\n Se il vostro report sul portafoglio genera pi\u00f9 discussioni in riunione che decisioni di indirizzo, la diagnosi pi\u00f9 rapida \u00e8 chiedersi: cosa decide effettivamente il comitato esecutivo sulla base di questo report? Se la risposta sincera \u00e8 \"non molto\", il report non sta facendo il suo lavoro, indipendentemente dalla solidit\u00e0 tecnica della struttura Power BI sottostante.<\/p>\n Iniziate da qui. Definite le tre decisioni che il comitato direttivo deve prendere mensilmente. Costruite a ritroso. Poi preoccupatevi delle immagini.<\/p>\n Se si \u00e8 gi\u00e0 superato questo limite e il collo di bottiglia \u00e8 il livello Power BI stesso, la soluzione \u00e8 la seguente Libreria visiva LeapLytics<\/a> vale la pena di dare un'occhiata: \u00e8 stato creato appositamente per i contesti di reporting della gestione dei progetti, \u00e8 certificato da Microsoft e pu\u00f2 essere provato direttamente. Inizia una prova gratuita qui<\/a> e testarli con i dati reali del vostro portafoglio.<\/p>","protected":false},"excerpt":{"rendered":" \u00c8 luned\u00ec mattina. Avete trascorso la maggior parte del venerd\u00ec a raccogliere aggiornamenti sullo stato di cinque diversi project manager, a riconciliare le date delle milestone in tre fogli di calcolo e a trasformare un report di Power BI in qualcosa che non vi metta in imbarazzo di fronte al comitato esecutivo. Il dashboard sembra a posto. Forse addirittura buono. Eppure, la prima domanda ... <\/p>","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-14620","post","type-post","status-publish","format-standard","hentry","category-news","latest_post"],"_links":{"self":[{"href":"https:\/\/www.leaplytics.de\/it\/wp-json\/wp\/v2\/posts\/14620","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.leaplytics.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.leaplytics.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.leaplytics.de\/it\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.leaplytics.de\/it\/wp-json\/wp\/v2\/comments?post=14620"}],"version-history":[{"count":2,"href":"https:\/\/www.leaplytics.de\/it\/wp-json\/wp\/v2\/posts\/14620\/revisions"}],"predecessor-version":[{"id":14622,"href":"https:\/\/www.leaplytics.de\/it\/wp-json\/wp\/v2\/posts\/14620\/revisions\/14622"}],"wp:attachment":[{"href":"https:\/\/www.leaplytics.de\/it\/wp-json\/wp\/v2\/media?parent=14620"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.leaplytics.de\/it\/wp-json\/wp\/v2\/categories?post=14620"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.leaplytics.de\/it\/wp-json\/wp\/v2\/tags?post=14620"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Cosa prova per prima la maggior parte dei PMO e perch\u00e9 non funziona<\/h2>\n
Cosa aiuta davvero: Progettare per la decisione, non per i dati<\/h2>\n
Prima e dopo: Cosa cambia quando il reporting di portafoglio funziona davvero<\/h2>\n
Da dove iniziare<\/h2>\n