Hétfő reggel van. A péntek nagy részét azzal töltötte, hogy öt különböző projektmenedzsertől státuszfrissítéseket szerzett, három táblázatkezelőn keresztül egyeztette a mérföldkő dátumait, és egy Power BI-jelentést olyan formába hozta, ami nem hozta zavarba a vezetői bizottság előtt. A műszerfal jól néz ki. Talán még jól is néz ki. És mégis - az első kérdés a megbeszélésen: "Megbízhatunk ezekben a számokban?".
Ez a kérdés a legtöbb projektportfólió-jelentési rendszer csendes kudarca. Nem technikai hiba. Nem hiányzó adatok. Csak a bizalom lassú csökkenése, ami miatt a jelentés inkább a vita kiindulópontjává válik, mintsem a döntések alapjává.
Ha ez ismerősen hangzik, a probléma szinte biztosan nem a Power BI. Hanem a portfóliójelentések felépítésével - és azzal, hogy a szokásos javítások miért rontják tovább a helyzetet.
Miért romlik el a projektportfólió-jelentés a Power BI-ben?
Van egy speciális feltételrendszer, amely egy Power BI portfólió műszerfalat olyanná változtat, amely több kérdést generál, mint amennyit megválaszol. Ezek egyike sem nyilvánvaló kívülről, és részben ezért is olyan tartósak.
1. Az adatmodell egyedi projektekhez készült, nem portfóliókhoz. A legtöbb Power BI implementáció projektkörnyezetekben egy projekt adataival - ütemterv, költségvetés, erőforrások - kezdődik, majd több ilyen adat egymásra halmozásával egy portfólió lefedésére bővül. Az eredmény egy olyan jelentés, amely az egyes projektek állapotát viszonylag jól megmutatja, de összeomlik, amikor portfóliószintű kérdésekre próbál válaszolni: Mely programoknál áll fenn a veszélye annak, hogy nem teljesítik a 3. negyedévi kötelezettségvállalásokat? Hol csoportosul a költségvetés túllépése a portfólióban? Az alapul szolgáló modellt soha nem úgy tervezték, hogy ezekre a kérdésekre választ adjon, és semmilyen új intézkedés nem fogja helyrehozni a strukturális eltérést.
2. A státuszadatok következetlenül érkeznek, és senki sem vállalja a minőségi problémát. A portfóliójelentés attól függ, hogy a projektmenedzserek időben és őszintén tájékoztatják-e a projekt állapotáról. A gyakorlatban egyesek korán, mások későn, megint mások optimista számokat közölnek, hogy elkerüljék az eszkalációt. A Power BI kötelességtudóan jelenti, amit kap. A PMO végül felelősséget vállal egy olyan jelentésért, amelyet nem tudott teljes mértékben ellenőrizni - és a vezetőség végül szkeptikusan tekint azokra a számokra, amelyek esetleg nem a valóságot tükrözik. Ez nem emberi probléma. Ez egy folyamat- és irányítási probléma, amelyet a jelentési réteg örököl.
3. A jelentés túl sok célcsoportot próbál egyszerre kiszolgálni. Az operatív projektmenedzsereknek feladatszintű részletességre van szükségük. A programvezetőknek mérföldkövek nyomon követésére van szükségük. Az irányítóbizottságnak portfóliószintű RAG-státuszra és pénzügyi kitettségre van szüksége. Ha egy Power BI-jelentés mindezt megpróbálja megvalósítani - általában oldalak és szűrők burjánzó halmazán keresztül -, akkor a végén egyiket sem csinálja különösebben jól. A vezető felhasználók nem nézik tovább, mert túl sokáig tart megtalálni, amire szükségük van. A projektvezetők figyelmen kívül hagyják, mert a részletesség nem felel meg a munkájuknak. A PMO pedig egy olyan jelentést tart fenn, amellyel senki sem elégedett.
Amit a legtöbb PMO először kipróbál - és miért nem működik
Amikor egy portfólió műszerfal nem ér célba, az ösztönös, hogy még többet adjunk hozzá. Több szűrő. Még több szűrő. Színkódolt státuszoszlopok, amelyek három hierarchiaszinten átívelnek. Feltételes formázás, amely mindent piros színnel emel ki, amíg semmi sem tűnik ki. Láttam már tizenhét oldalas jelentéseket, amelyeken a vezetők úgy navigáltak, hogy megkérték a PMO-t, hogy ossza meg a képernyőjüket, és kattintsanak körbe helyettük.
A másik gyakori lépés az adatvezeték újjáépítése. Új SharePoint struktúra. Új Power Query transzformációk. Néha egy megfelelő adattárház. Ez esetenként helyes döntés - de ez egy hónapokig tartó projekt, amely nem foglalkozik azzal, hogy a meglévő jelentés miért nem megbízható. Tökéletesen tiszta adatokkal is táplálhat egy jelentést, amely mégsem képes döntéseket hozni.
Van egy minta is, amelyet érdemes megnevezni: a Power BI-t egy dedikált PPM eszközzel váltják le, hogy aztán ugyanazokkal a jelentéskészítési problémákkal szembesüljenek egy új felületen. Az eszköz változik. A mögöttes kérdések, hogy a vezetésnek valójában mit kell látnia, és hogyan áramlanak az adatok a projektekből a portfólióba - ezek megoldatlanok maradnak.
Hogy őszinte legyek: itt nincs ezüstgolyó. A portfóliójelentési problémák mindig részben adatproblémák, részben folyamatproblémák, részben pedig tervezési problémák. Bárki, aki mást mond, túlságosan leegyszerűsíti a helyzetet. De általában a tervezési réteget lehet a leggyorsabban megoldani, és szinte mindig ezt kezelik utoljára.
Ami valójában segít: Nem az adatok, hanem a döntéshez való tervezés
Hasznosabb, ha az irányítóbizottság tényleges kérdéseiből indulunk ki - abból a három-négy dologból, amiről úgy kell kisétálniuk az ülésről, hogy már döntöttek -, és onnan kiindulva visszafelé tervezünk. Nem "milyen adatokkal rendelkezünk", hanem "mit kell látnia a portfólió tulajdonosának ahhoz, hogy a késleltetett programról döntsön?".
A gyakorlatban ez általában azt jelenti, hogy a vezetői és az operatív szemléletet keményen el kell választani egymástól. Az irányítási rétegnek portfóliószintű összesítésre van szüksége: az ütemterv általános állapota, programonkénti költségvetési kitettség, egyértelmű jelzés arról, hogy mely projektek alkalmasak az eszkalációra. Két perc alatt, bármire való kattintás nélkül is olvashatónak kell lennie. Az operatív réteg - amelyet a projektmenedzserek és a programvezetők ténylegesen használnak - hordozhatja a részleteket. Ez két különböző célközönség, különböző igényekkel, és a legtöbb Power BI portfólió-műszerfal ott hibázik, ahol megpróbálja mindkettőt egy jelentésben kiszolgálni.
A vizualizációs döntések többet számítanak, mint azt a legtöbb PMO tudatában van. Egy olyan jelzőlámpa, amely nem mutatja a tendenciát - hogy egy projekt most váltott-e sárgára, vagy már hat hete sárga - kevésbé hasznos, mint amilyennek látszik. Egy Gantt-stílusú mérföldkő áttekintés, amely a portfólió teljes ütemtervének eltérését mutatja, olyasmit kommunikál, amit egy dátumokat tartalmazó táblázat nem tud. A vizuális elem kiválasztása nem díszítés; ez a különbség a döntésre sarkalló és a kérdésre késztető jelentés között.
Ez az a terület, ahol a projektmenedzsment összefüggéseiben a célzott Power BI vizuális eszközök valódi különbséget jelentenek. A LeapLytics kifejezetten erre a célra készít hitelesített, egyedi vizuális elemeket - például a következőket Gantt diagram vizuális megjelenítése és a portfóliójelentéshez tervezett jelzőlámpás mutatók, nem pedig az általános BI-felhasználási esetekből átdolgozva. Ezek nem oldják meg az adatmodell vagy az irányítás problémáját, de ha a struktúra megfelelő, akkor a kimenetet lényegesen olvashatóbbá teszik azok számára, akik a legfontosabbak.
Előtte és utána: Mi változik, ha a portfóliójelentés valóban működik
Egy közepes méretű infrastrukturális PMO - körülbelül 40 aktív projekt négy programban - eljutott arra a pontra, amikor a havi portfólió-felülvizsgálat kilencven perc helyett három órát vett igénybe, főként azért, mert minden egyes jelentett állapotjelentés utána megbeszélést váltott ki arról, hogy a számok aktuálisak-e. A projektvezetők e-mailben küldték be a frissítéseket. A PMO manuálisan frissített egy Excel-fájlt. A Power BI ebből a fájlból olvasta be az adatokat. A lánc legalább egy hét késést hozott a valóság és a jelentés között.
Az újratervezés három részből állt: egy szabványosított státuszbeadási folyamat egy fix pénteki határnappal, amelyet a Power BI közvetlenül olvasott, egy egyértelmű szétválasztás a vezetői egyoldalas oldal (portfólió RAG, öt legnagyobb kockázat, költségvetési eltérés programonként) és a programszintű operatív nézet között, valamint egy általános, egymásra helyezett oszlopdiagram felváltása egy megfelelő mérföldkő-idővonal ábrával, amely egy pillantással mutatta az ütemtervtől való eltérést.
Az irányító ülés három óráról hetven percre csökkent. Ami még fontosabb, a nyitó kérdés nem az volt, hogy "bízhatunk-e ebben?", hanem az, hogy "mit tegyünk a B programmal?". Ez a váltás - az adatok validálásáról a döntéshozatalra - a tényleges cél. Minden más csak infrastruktúra.
A PMI kutatás a PMO hatékonyságáróla kiforrott portfóliójelentési folyamatokkal rendelkező szervezetek lényegesen több projektet fejeznek be időben és a költségvetésen belül. Ezt nem maga a jelentéstétel okozza - de a rossz jelentéstétel aktívan elrejti azokat a jeleket, amelyek lehetővé tennék a korábbi beavatkozást.
Hol kezdjem
Ha az Ön portfóliójelentése több vitát generál az ülésen, mint vezetői döntést, a leggyorsabb diagnosztikai módszer, ha megkérdezi: valójában miről dönt a végrehajtó bizottság a jelentés alapján? Ha az őszinte válasz az, hogy "nem sokat", akkor a jelentés nem végzi el a feladatát - függetlenül attól, hogy az alapul szolgáló Power BI-építés technikailag mennyire megbízható.
Kezdje ott. Határozza meg azt a három döntést, amelyet az irányítóbizottságnak havonta meg kell hoznia. Építsen visszafelé. Aztán aggódjon a vizuális elemek miatt.
Ha már túl van ezen, és a szűk keresztmetszetet maga a Power BI réteg jelenti, akkor a LeapLytics vizuális könyvtár érdemes megnézni - kifejezetten projektmenedzsment jelentéskészítési kontextusokhoz készült, a Microsoft által tanúsított, és közvetlenül kipróbálható. Indítson ingyenes próbaverziót itt és tesztelje őket a tényleges portfólióadatokkal szemben.
