Este luni dimineața. Ați petrecut cea mai mare parte a zilei de vineri obținând actualizări ale stadiului de la cinci manageri de proiect diferiți, reconciliind datele de etapă în trei foi de calcul și transformând un raport Power BI într-unul care să nu vă facă de râs în fața comitetului executiv. Tabloul de bord arată bine. Poate chiar bine. Și totuși - prima întrebare în cadrul ședinței este: "Putem avea încredere în aceste cifre?"
Această întrebare este modul discret de eșec al majorității configurațiilor de raportare a portofoliului de proiecte. Nu o eroare tehnică. Nu date lipsă. Doar o erodare lentă a încrederii care face din raportul dvs. un punct de plecare pentru dezbatere, mai degrabă decât o bază pentru decizii.
Dacă vă sună cunoscut, este aproape sigur că problema nu este Power BI. Este vorba de modul în care este structurată raportarea portofoliului - și de ce soluțiile obișnuite continuă să înrăutățească lucrurile.
De ce raportarea portofoliului de proiecte nu este satisfăcătoare în Power BI
Există un set specific de condiții care transformă un tablou de bord de portofoliu Power BI în ceva care generează mai multe întrebări decât răspunsuri. Niciuna dintre acestea nu este evidentă din exterior, ceea ce explică în parte de ce sunt atât de persistente.
1. Modelul de date este construit pentru proiecte individuale, nu pentru portofolii. Majoritatea implementărilor Power BI în mediile de proiect încep cu datele unui proiect - calendar, buget, resurse - și apoi se extind pentru a acoperi un portofoliu prin stivuirea mai multor date similare. Rezultatul este un raport care vă poate arăta destul de bine starea proiectelor individuale, dar care se prăbușește atunci când încercați să răspundeți la întrebări la nivel de portofoliu: Care sunt programele care riscă să nu respecte angajamentele Q3? Unde se grupează depășirea bugetului în cadrul portofoliului? Modelul de bază nu a fost conceput niciodată pentru a răspunde la aceste întrebări și nicio măsură nouă nu va rezolva o neconcordanță structurală.
2. Datele de stare sunt incoerente, iar problema calității nu aparține nimănui. Raportarea portofoliului depinde de prezentarea de către managerii de proiect a unor actualizări oneste și în timp util. În practică, unii transmit mai devreme, alții mai târziu, unii transmit cifre optimiste pentru a evita escaladarea. Power BI raportează conștiincios tot ceea ce primește. PMO ajunge să fie responsabil pentru un raport pe care nu l-a controlat pe deplin, iar conducerea ajunge să fie sceptică cu privire la cifre care pot sau nu să reflecte realitatea. Aceasta nu este o problemă de oameni. Este o problemă de proces și de guvernanță pe care o moștenește nivelul de raportare.
3. Raportul încearcă să servească prea multe audiențe în același timp. Managerii de proiecte operaționale au nevoie de detalii la nivel de sarcină. Managerii de program au nevoie de urmărirea etapelor. Comitetul director are nevoie de starea RAG la nivel de portofoliu și de expunerea financiară. Atunci când un raport Power BI încearcă să facă toate acestea - de obicei prin intermediul unui set de pagini și filtre întins - ajunge să nu facă nimic deosebit de bine. Utilizatorii executivi nu se mai uită la el pentru că le ia prea mult timp să găsească ceea ce au nevoie. Managerii de proiect îl ignoră pentru că detaliile nu sunt potrivite pentru activitatea lor. Iar PMO rămâne cu un raport de care nimeni nu este pe deplin mulțumit.
Ce încearcă mai întâi majoritatea PMO - și de ce nu funcționează
Instinctul atunci când un tablou de bord de portofoliu nu este de aterizare este de a adăuga mai mult la ea. Mai multe filtre. Mai multe drill-through-uri. Coloane de stare cu coduri de culori, care trec în cascadă prin trei niveluri de ierarhie. Formatare condiționată care evidențiază totul în roșu până când nimic nu iese în evidență. Am văzut rapoarte cu șaptesprezece pagini pe care directorii le parcurg cerând PMO să le împartă ecranul și să facă clic în locul lor.
Cealaltă mișcare comună este reconstruirea conductei de date. O nouă structură SharePoint. Noi transformări Power Query. Uneori, un depozit de date adecvat. Aceasta este uneori decizia corectă - dar este un proiect de luni de zile care nu abordează motivul pentru care raportul existent nu este de încredere. Puteți avea date perfect curate care alimentează un raport care totuși nu reușește să conducă la decizii.
Există, de asemenea, un model care merită menționat: înlocuirea Power BI cu un instrument PPM dedicat, doar pentru a ajunge la aceleași probleme de raportare într-o interfață nouă. Instrumentul se schimbă. Întrebările de bază cu privire la ceea ce conducerea trebuie să vadă de fapt și la modul în care datele circulă de la proiecte la portofoliu - rămân nerezolvate.
Ca să fim sinceri: nu există un glonț de argint aici. Problemele de raportare a portofoliului sunt întotdeauna parțial o problemă de date, parțial o problemă de proces și parțial o problemă de proiectare. Oricine vă spune altceva simplifică prea mult. Dar, de obicei, nivelul de proiectare este cel mai rapid de rezolvat și aproape întotdeauna este abordat ultimul.
Ce ajută de fapt: Proiectarea pentru decizie, nu pentru date
Un cadru mai util este acela de a porni de la întrebările reale ale comitetului director - cele trei sau patru lucruri pe care trebuie să le decidă la ieșirea de la o reuniune - și de a proiecta în sens invers de la acestea. Nu "ce date avem", ci "ce trebuie să vadă un proprietar de portofoliu pentru a lua o decizie privind un program întârziat?"
În practică, acest lucru înseamnă, de obicei, o separare strictă între viziunea executivă și cea operațională. Stratul de conducere are nevoie de agregare la nivel de portofoliu: starea generală a programului, expunerea bugetului pe program, un semnal clar privind proiectele care sunt candidate la escaladare. Ar trebui să poată fi citit în mai puțin de două minute, fără a face clic pe nimic. Stratul operațional - cel pe care îl folosesc de fapt managerii de proiect și responsabilii de program - poate conține detalii. Acestea sunt două audiențe diferite cu nevoi diferite, iar încercarea de a le servi pe amândouă într-un singur raport este punctul în care majoritatea tablourilor de bord de portofoliu Power BI dau greș.
Opțiunile de vizualizare contează mai mult decât își dau seama majoritatea PMO-urilor. O stare a semaforului care nu arată tendința - dacă un proiect tocmai a devenit portocaliu sau a fost portocaliu timp de șase săptămâni - este mai puțin utilă decât pare. O prezentare generală a etapelor în stil Gantt, care arată abaterea de la program în cadrul portofoliului, comunică ceva ce un tabel de date nu poate. Alegerea vizualului nu este decorativă; este diferența dintre un raport care îndeamnă la o decizie și unul care îndeamnă la o întrebare.
Acesta este domeniul în care elementele vizuale Power BI construite special pentru contexte de gestionare a proiectelor fac o diferență reală. LeapLytics construiește elemente vizuale personalizate certificate special pentru acest lucru - lucruri precum Diagrame Gantt vizuale și indicatori semaforizați concepuți pentru raportarea portofoliului, nu repurtați din cazuri generice de utilizare a BI. Acestea nu rezolvă problema modelului de date sau problema guvernanței, dar atunci când structura este corectă, ele fac rezultatele mult mai lizibile pentru persoanele care contează cel mai mult.
Înainte și după: Ce se schimbă atunci când raportarea portofoliului funcționează cu adevărat
Un PMO de infrastructură de dimensiuni medii - aproximativ 40 de proiecte active în cadrul a patru programe - a ajuns la un punct în care revizuirea lunară a portofoliului dura trei ore în loc de nouăzeci de minute, mai ales pentru că fiecare stare raportată declanșa o discuție ulterioară cu privire la actualitatea cifrelor. Managerii de proiect transmiteau actualizările prin e-mail. PMO actualiza manual un fișier Excel principal. Power BI citea din acel fișier. Lanțul a introdus cel puțin o săptămână de decalaj între realitate și raport.
Reproiectarea a avut trei părți: un proces standardizat de prezentare a stadiului cu o dată limită fixă de vineri pe care Power BI o citește direct, o separare clară între o pagină executivă unică (portofoliul RAG, cele mai importante cinci riscuri, variația bugetului pe program) și o vizualizare operațională la nivel de program și înlocuirea unui grafic generic cu bare suprapuse cu o vizualizare adecvată a cronologiei etapelor care a arătat abaterea de la program dintr-o privire.
Reuniunea de coordonare a scăzut de la trei ore la șaptezeci de minute. Mai important, întrebarea de deschidere a încetat să mai fie "putem avea încredere în acest lucru?" și a început să fie "ce facem în legătură cu programul B?" Această schimbare - de la validarea datelor la luarea deciziilor - este obiectivul real. Orice altceva este infrastructură.
În conformitate cu Cercetare PMI privind eficiența PMO, organizațiile cu procese mature de raportare a portofoliului finalizează mult mai multe proiecte la timp și în limitele bugetului. Raportarea în sine nu este cauza - însă raportarea defectuoasă ascunde în mod activ semnalele care ar permite o intervenție mai timpurie.
De unde să începeți
Dacă raportul dvs. de portofoliu generează mai multe dezbateri în cadrul ședinței decât decizii de conducere, cel mai rapid diagnostic este să întrebați: ce decide de fapt comitetul executiv pe baza acestui raport? Dacă răspunsul sincer este "nu prea multe", raportul nu își face treaba - indiferent de cât de solidă din punct de vedere tehnic este construcția Power BI de bază.
Începeți de acolo. Definiți cele trei decizii pe care comitetul director trebuie să le ia lunar. Construiți în sens invers. Apoi preocupați-vă de elementele vizuale.
Dacă ați depășit deja această etapă și blocajul este nivelul Power BI în sine, soluția Biblioteca vizuală LeapLytics merită o privire - creat special pentru contexte de raportare a managementului de proiect, certificat de Microsoft și disponibil pentru testare directă. Începeți o încercare gratuită aici și testați-le în raport cu datele reale din portofoliul dvs.
