On maanantaiaamu. Olet käyttänyt perjantain siihen, että olet kerännyt tilannekatsauksia viideltä eri projektipäälliköltä, täsmäyttänyt virstanpylväspäivämääriä kolmella taulukkolaskentaohjelmalla ja muokannut Power BI -raportista jotain sellaista, joka ei nolaa sinua johtoryhmän edessä. Kojelauta näyttää hyvältä. Ehkä jopa hyvältä. Ja silti - ensimmäinen kysymys kokouksessa on: "Voimmeko luottaa näihin lukuihin?".
Tämä kysymys on useimpien projektisalkun raportointijärjestelmien hiljainen epäonnistumistapa. Kyse ei ole teknisestä virheestä. Ei puuttuvia tietoja. Vain luottamuksen hidas heikkeneminen, joka tekee raportista pikemminkin keskustelun lähtökohdan kuin päätöksenteon perustan.
Jos tämä kuulostaa tutulta, ongelma ei varmastikaan ole Power BI. Kyse on siitä, miten salkkuraportointi rakennetaan - ja miksi tavanomaiset korjaukset pahentavat tilannetta.
Miksi projektisalkun raportointi hajoaa Power BI:ssä?
On olemassa tietty joukko ehtoja, jotka muuttavat Power BI:n salkun kojelaudan sellaiseksi, joka tuottaa enemmän kysymyksiä kuin antaa vastauksia. Mikään niistä ei ole ilmeinen ulkopuolelta, ja siksi ne ovat niin sitkeitä.
1. Tietomalli on rakennettu yksittäisiä hankkeita, ei portfolioita varten. Useimmat Power BI:n käyttöönotot projektiympäristöissä alkavat yhden projektin tiedoilla - aikataulu, budjetti, resurssit - ja laajenevat sitten kattamaan koko portfolion kasaamalla lisää samoja tietoja. Tuloksena on raportti, joka näyttää yksittäisen projektin tilan kohtuullisen hyvin, mutta romahtaa, kun yrität vastata salkun tason kysymyksiin: Mitkä ohjelmat ovat vaarassa jäädä jälkeen kolmannen vuosineljänneksen sitoumuksista? Mihin budjetin ylitykset ryhmittyvät koko salkussa? Mallia ei ole koskaan suunniteltu vastaamaan näihin kysymyksiin, eikä mikään määrä uusia toimenpiteitä korjaa rakenteellista epäsuhtaa.
2. Tilatiedot tulevat epäjohdonmukaisesti, eikä kukaan vastaa laatuongelmasta. Portfolioraportointi on riippuvainen siitä, että projektipäälliköt toimittavat ajantasaiset ja rehelliset tilapäivitykset. Käytännössä jotkut toimittavat tiedot aikaisin, jotkut myöhään ja jotkut optimistisia lukuja välttääkseen eskalaation. Power BI raportoi kuuliaisesti kaiken, mitä se saa. PMO on lopulta vastuussa raportista, jota se ei ole täysin hallinnut - ja johto suhtautuu epäilevästi lukuihin, jotka saattavat vastata todellisuutta. Tämä ei ole ihmisten ongelma. Se on prosessi- ja hallinto-ongelma, jonka raportointikerros perii.
3. Raportti yrittää palvella liian monia yleisöjä samanaikaisesti. Operatiiviset projektipäälliköt tarvitsevat tehtävätason yksityiskohtia. Ohjelmapäälliköt tarvitsevat virstanpylväiden seurantaa. Ohjauskomitea tarvitsee salkun RAG-tason tilan ja taloudellisen altistumisen. Kun yksi Power BI -raportti yrittää tehdä kaiken tämän - yleensä laajojen sivujen ja suodattimien avulla - se ei lopulta tee mitään näistä erityisen hyvin. Johtavat käyttäjät eivät enää katso sitä, koska heidän tarvitsemansa tiedon löytäminen vie liian kauan. Projektipäälliköt jättävät sen huomiotta, koska sen yksityiskohdat eivät sovi heidän työhönsä. PMO:lle jää raportti, johon kukaan ei ole täysin tyytyväinen.
Mitä useimmat PMO:t kokeilevat ensin - ja miksi se ei toimi?
Kun portfolion kojelauta ei ole onnistunut, siihen lisätään vaistomaisesti lisää. Lisää suodattimia. Lisää porauksia. Värikoodattuja tilasarakkeita, jotka kulkevat kolmella hierarkiatasolla. Ehdollinen muotoilu, joka korostaa kaiken punaisella, kunnes mikään ei erotu. Olen nähnyt seitsemäntoista sivua sisältäviä raportteja, joita johtajat selaavat pyytämällä PMO:ta jakamaan näytön ja klikkaamaan niitä heidän puolestaan.
Toinen yleinen tapa on rakentaa dataputki uudelleen. Uusi SharePoint-rakenne. Uudet Power Query -muunnokset. Joskus kunnollinen tietovarasto. Tämä on toisinaan oikea ratkaisu, mutta se on kuukausien mittainen hanke, jossa ei käsitellä sitä, miksi nykyiseen raporttiin ei luoteta. Täysin puhtaat tiedot voivat ruokkia raporttia, joka ei silti auta tekemään päätöksiä.
Myös eräs kuvio on mainitsemisen arvoinen: Power BI:n korvaaminen erityisellä PPM-työkalulla, mutta sitten päädytään samoihin raportointiongelmiin uudessa käyttöliittymässä. Työkalu vaihtuu. Perimmäiset kysymykset siitä, mitä johto oikeastaan tarvitsee nähdä ja miten tiedot kulkevat projekteista salkkuun - nämä kysymykset jäävät ratkaisematta.
Rehellisesti sanottuna: tässä ei ole mitään ratkaisua. Portfolioraportointiin liittyvät ongelmat ovat aina osittain tieto-, osittain prosessi- ja osittain suunnitteluongelmia. Kaikki, jotka väittävät muuta, yksinkertaistavat liikaa. Suunnittelukerros on kuitenkin yleensä nopeimmin korjattavissa, ja siihen puututaan lähes aina viimeisenä.
Mikä oikeastaan auttaa: Suunnittele päätöstä, älä tietoja varten
Hyödyllisempi kehys on lähteä liikkeelle ohjauskomitean varsinaisista kysymyksistä - kolmesta tai neljästä asiasta, jotka heidän on päätettävä kokouksessa - ja suunnitella siitä taaksepäin. Ei "mitä tietoja meillä on" vaan "mitä salkun omistajan on nähtävä tehdäkseen päätöksensä viivästyneestä ohjelmasta".
Käytännössä tämä tarkoittaa yleensä tiukkaa erottelua johdon näkemyksen ja operatiivisen näkemyksen välillä. Ohjauskerros tarvitsee salkun tason aggregointia: aikataulun kokonaistilanne, budjetin altistuminen ohjelmittain, selkeä signaali siitä, mitkä hankkeet ovat eskalaatioehdokkaita. Sen pitäisi olla luettavissa alle kahdessa minuutissa klikkaamatta mitään. Operatiivinen taso - jota projektipäälliköt ja ohjelmien johtajat todella käyttävät - voi sisältää yksityiskohtia. Nämä ovat kaksi eri yleisöä, joilla on erilaiset tarpeet, ja useimmat Power BI:n salkkuesimerkkitaulut menevät pieleen, kun yritetään palvella molempia yhdellä raportilla.
Visualisointivalinnoilla on enemmän merkitystä kuin useimmat PMO:t ymmärtävät. Liikennevalotilanne, josta ei käy ilmi suuntaus - onko hanke juuri muuttunut keltaiseksi vai onko se ollut keltainen jo kuusi viikkoa - on vähemmän hyödyllinen kuin miltä se näyttää. Gantt-tyylinen virstanpylväsnäkymä, joka näyttää aikataulupoikkeamat koko salkussa, viestii jotain, mitä päivämääristä koostuva taulukko ei pysty. Visuaalisen ilmeen valinta ei ole koriste, vaan se on ero sen välillä, kannustaako raportti tekemään päätöksen vai herättääkö se kysymyksen.
Tämä on alue, jolla projektinhallintayhteyksiin tarkoitukseen kehitetyt Power BI -visualisoinnit tuovat todellista hyötyä. LeapLytics rakentaa sertifioituja räätälöityjä visualisointeja nimenomaan tätä varten - esimerkiksi seuraavia asioita varten Gantt-kaavion visualisointi ja liikennevaloindikaattorit, jotka on suunniteltu salkun raportointia varten, eikä niitä ole käytetty uudelleen yleisistä BI-käyttötapauksista. Ne eivät ratkaise tietomalliongelmaa tai hallinto-ongelmaa, mutta kun rakenne on oikea, ne tekevät tuotoksesta huomattavasti luettavamman niille, joilla on eniten merkitystä.
Ennen ja jälkeen: Mikä muuttuu, kun portfolioraportointi todella toimii
Keskikokoinen infrastruktuurin PMO - noin 40 aktiivista hanketta neljässä ohjelmassa - tuli pisteeseen, jossa kuukausittainen salkun tarkastelu kesti yhdeksänkymmenen minuutin sijasta kolme tuntia, lähinnä siksi, että jokainen raportoitu tilanne aiheutti jatkokeskustelun siitä, olivatko luvut ajan tasalla. Projektipäälliköt toimittivat päivitykset sähköpostitse. PMO päivitti manuaalisesti Excel-päätiedostoa. Power BI luki tätä tiedostoa. Ketju aiheutti vähintään viikon viiveen todellisuuden ja raportin välille.
Uudelleensuunnittelussa oli kolme osaa: vakioitu tilatietojen toimittamisprosessi, jossa oli kiinteä perjantairaja, jota Power BI luki suoraan, selkeä erottelu johdon yhden sivun (salkun RAG, viisi suurinta riskiä, budjettipoikkeama ohjelmittain) ja ohjelmatasoisen operatiivisen näkymän välillä sekä yleisen pylväskaavion korvaaminen asianmukaisella virstanpylväskaavion visualisoinnilla, joka osoitti aikataulupoikkeaman yhdellä silmäyksellä.
Ohjauskokous lyheni kolmesta tunnista seitsemänkymmeneen minuuttiin. Vielä tärkeämpää oli, että avauskysymys ei enää ollut "voimmeko luottaa tähän?" vaan "mitä teemme ohjelmalle B?". Tämä muutos - tietojen validoinnista päätöksentekoon - on varsinainen tavoite. Kaikki muu on infrastruktuuria.
Mukaan PMI:n tutkimus PMO:n tehokkuudestaorganisaatiot, joilla on kehittyneet salkkuraportointiprosessit, saattavat huomattavasti useammat hankkeet päätökseen ajallaan ja budjetissa. Tämä ei johdu raportoinnista itsestään, mutta huono raportointi peittää aktiivisesti signaalit, jotka mahdollistaisivat varhaisemman puuttumisen.
Mistä aloittaa
Jos salkkukertomuksesi synnyttää enemmän keskustelua kokouksissa kuin ohjauspäätöksiä, nopein diagnoosi on kysyä: mitä johtokunta oikeastaan päättää tämän kertomuksen perusteella? Jos rehellinen vastaus on "ei paljoa", raportti ei tee työtään - riippumatta siitä, kuinka teknisesti vankka sen taustalla oleva Power BI -rakenne on.
Aloita sieltä. Määrittele kolme päätöstä, jotka ohjauskomitean on tehtävä kuukausittain. Rakenna taaksepäin. Huolehdi sitten visuaalisesta ilmeestä.
Jos olet jo ohittanut sen ja pullonkaulana on itse Power BI -kerros, on LeapLytics visuaalinen kirjasto on katsomisen arvoinen - se on suunniteltu projektinhallinnan raportointikonteksteihin, Microsoftin sertifioima ja suoraan kokeiltavissa. Aloita ilmainen kokeilujakso täältä ja testaa niitä todellisia salkkutietojasi vastaan.
