Jest poniedziałek rano. Spędziłeś większą część piątku wyciągając aktualizacje statusu od pięciu różnych kierowników projektów, uzgadniając daty kamieni milowych w trzech arkuszach kalkulacyjnych i przekształcając raport Power BI w coś, co nie zawstydzi cię przed komitetem wykonawczym. Pulpit nawigacyjny wygląda dobrze. Może nawet dobrze. A jednak - pierwsze pytanie na spotkaniu brzmi: "Czy możemy ufać tym liczbom?".
To pytanie jest cichą przyczyną niepowodzeń większości konfiguracji raportowania portfela projektów. Nie jest to błąd techniczny. Nie brakujące dane. Po prostu powolna erozja zaufania, która sprawia, że raport staje się punktem wyjścia do debaty, a nie podstawą do podejmowania decyzji.
Jeśli brzmi to znajomo, problemem prawie na pewno nie jest Power BI. Chodzi o sposób raportowania portfela - i dlaczego zwykłe poprawki wciąż pogarszają sytuację.
Dlaczego raportowanie portfela projektów nie działa w Power BI?
Istnieje określony zestaw warunków, które sprawiają, że pulpit nawigacyjny portfolio Power BI staje się czymś, co generuje więcej pytań niż odpowiedzi. Żaden z nich nie jest oczywisty z zewnątrz, co jest jednym z powodów, dla których są one tak uporczywe.
1. Model danych jest zbudowany dla pojedynczych projektów, a nie portfeli. Większość wdrożeń Power BI w środowiskach projektowych rozpoczyna się od danych jednego projektu - harmonogramu, budżetu, zasobów - a następnie rozszerza się na portfolio, układając więcej takich samych danych. Rezultatem jest raport, który może dość dobrze pokazać status poszczególnych projektów, ale załamuje się, gdy próbujesz odpowiedzieć na pytania na poziomie portfela: Które programy są zagrożone niewywiązaniem się ze zobowiązań w trzecim kwartale? Gdzie w portfelu występują przekroczenia budżetu? Podstawowy model nigdy nie został zaprojektowany, aby odpowiedzieć na te pytania, a żadna ilość nowych miar nie naprawi niedopasowania strukturalnego.
2. Dane o statusie nie są spójne i nikt nie jest odpowiedzialny za problem jakości. Raportowanie portfela zależy od kierowników projektów przesyłających terminowe, uczciwe aktualizacje statusu. W praktyce niektórzy przesyłają je wcześnie, inni późno, a jeszcze inni podają optymistyczne liczby, aby uniknąć eskalacji. Power BI sumiennie raportuje wszystko, co otrzyma. PMO staje się odpowiedzialne za raport, którego w pełni nie kontroluje, a kierownictwo sceptycznie podchodzi do liczb, które mogą, ale nie muszą odzwierciedlać rzeczywistości. To nie jest problem ludzi. Jest to problem procesu i zarządzania, który dziedziczy warstwa raportowania.
3. Raport próbuje służyć zbyt wielu odbiorcom jednocześnie. Kierownicy projektów operacyjnych potrzebują szczegółowych informacji na poziomie zadań. Kierownicy programów potrzebują śledzenia kamieni milowych. Komitet sterujący potrzebuje statusu RAG na poziomie portfela i ekspozycji finansowej. Gdy jeden raport Power BI próbuje zrobić to wszystko - zwykle za pomocą rozległego zestawu stron i filtrów - kończy się na tym, że nie robi tego szczególnie dobrze. Użytkownicy wykonawczy przestają go przeglądać, ponieważ znalezienie tego, czego potrzebują, zajmuje zbyt dużo czasu. Kierownicy projektów ignorują go, ponieważ szczegóły są nieodpowiednie dla ich pracy. A PMO pozostaje z raportem, z którego nikt nie jest w pełni zadowolony.
Czego większość PMO próbuje najpierw - i dlaczego to nie działa?
Instynktem, gdy pulpit nawigacyjny portfolio nie ląduje, jest dodanie do niego więcej. Więcej filtrów. Więcej opcji drążenia. Kolorowe kolumny statusu, które kaskadowo przechodzą przez trzy poziomy hierarchii. Formatowanie warunkowe, które podkreśla wszystko na czerwono, aż nic się nie wyróżnia. Widziałem raporty z siedemnastoma stronami, po których kierownictwo poruszało się, prosząc PMO o udostępnienie ekranu i klikanie za nich.
Innym powszechnym posunięciem jest przebudowa potoku danych. Nowa struktura SharePoint. Nowe transformacje Power Query. Czasami odpowiednia hurtownia danych. Czasami jest to właściwe rozwiązanie - ale jest to wielomiesięczny projekt, który nie rozwiązuje problemu, dlaczego istniejący raport nie jest godny zaufania. Możesz mieć idealnie czyste dane zasilające raport, który nadal nie pomaga w podejmowaniu decyzji.
Istnieje również wzorzec, który warto nazwać: zastąpienie Power BI dedykowanym narzędziem PPM, tylko po to, by skończyć z tymi samymi problemami z raportowaniem w nowym interfejsie. Narzędzie się zmienia. Podstawowe pytania dotyczące tego, co kierownictwo faktycznie musi widzieć i w jaki sposób dane przepływają z projektów do portfela - pozostają nierozwiązane.
Szczerze mówiąc, nie ma tu srebrnej kuli. Problemy z raportowaniem portfela są zawsze częściowo problemem z danymi, częściowo problemem z procesem, a częściowo problemem z projektem. Każdy, kto twierdzi inaczej, nadmiernie upraszcza sprawę. Ale warstwa projektowa jest zwykle najszybsza do naprawienia i prawie zawsze jest rozwiązywana jako ostatnia.
Co tak naprawdę pomaga: Projektowanie pod kątem decyzji, a nie danych
Bardziej użyteczne jest rozpoczęcie od rzeczywistych pytań komitetu sterującego - trzech lub czterech rzeczy, które muszą wyjść ze spotkania po podjęciu decyzji - i projektowanie od tego momentu. Nie "jakie mamy dane", ale "co właściciel portfela musi zobaczyć, aby podjąć decyzję o opóźnieniu programu?".
W praktyce oznacza to zazwyczaj twarde oddzielenie widoku wykonawczego od widoku operacyjnego. Warstwa sterująca wymaga agregacji na poziomie portfela: ogólny stan harmonogramu, ekspozycja budżetu według programu, wyraźny sygnał, które projekty są kandydatami do eskalacji. Powinien być czytelny w mniej niż dwie minuty bez klikania czegokolwiek. Warstwa operacyjna - ta, z której faktycznie korzystają kierownicy projektów i liderzy programów - może zawierać więcej szczegółów. Są to dwie różne grupy odbiorców o różnych potrzebach, a próba obsługi obu w jednym raporcie jest miejscem, w którym większość pulpitów nawigacyjnych Power BI popełnia błędy.
Wybór wizualizacji ma większe znaczenie niż większość PMO zdaje sobie sprawę. Status sygnalizacji świetlnej, który nie pokazuje trendu - czy projekt właśnie zmienił kolor na pomarańczowy, czy był pomarańczowy przez sześć tygodni - jest mniej użyteczny niż się wydaje. Przegląd kamieni milowych w stylu Gantta, który pokazuje odchylenia harmonogramu w całym portfolio, komunikuje coś, czego nie może przekazać tabela dat. Wybór wizualizacji nie jest dekoracją; to różnica między raportem, który skłania do podjęcia decyzji, a takim, który skłania do zadania pytania.
Jest to obszar, w którym specjalnie stworzone wizualizacje Power BI dla kontekstów zarządzania projektami robią prawdziwą różnicę. LeapLytics tworzy certyfikowane niestandardowe wizualizacje specjalnie do tego celu - takie jak Wizualizacje wykresu Gantta i wskaźniki sygnalizacji świetlnej zaprojektowane do raportowania portfela, a nie przeprojektowane z ogólnych przypadków użycia BI. Nie rozwiązują one problemu modelu danych ani problemu zarządzania, ale przy odpowiedniej strukturze sprawiają, że dane wyjściowe są znacznie bardziej czytelne dla osób, które mają największe znaczenie.
Przed i po: Co się zmienia, gdy raportowanie portfela faktycznie działa
Średniej wielkości PMO zajmujące się infrastrukturą - około 40 aktywnych projektów w czterech programach - doszło do punktu, w którym ich comiesięczny przegląd portfela zajmował trzy godziny zamiast dziewięćdziesięciu minut, głównie dlatego, że każdy zgłoszony status wywoływał dyskusję na temat tego, czy liczby są aktualne. Kierownicy projektów przesyłali aktualizacje za pośrednictwem poczty elektronicznej. PMO ręcznie aktualizowało główny plik Excel. Power BI odczytywał dane z tego pliku. Łańcuch wprowadzał co najmniej tygodniowe opóźnienie między rzeczywistością a raportem.
Przeprojektowanie składało się z trzech części: ustandaryzowanego procesu przesyłania statusów z ustaloną datą graniczną w piątek, którą Power BI odczytywał bezpośrednio, wyraźnego oddzielenia wykonawczego one-pagera (portfolio RAG, pięć największych ryzyk, odchylenie budżetowe według programu) od widoku operacyjnego na poziomie programu oraz zastąpienia ogólnego wykresu słupkowego odpowiednią wizualizacją osi czasu kamieni milowych, która na pierwszy rzut oka pokazywała odchylenie harmonogramu.
Spotkanie sterujące skróciło się z trzech godzin do siedemdziesięciu minut. Co ważniejsze, początkowe pytanie przestało brzmieć "czy możemy temu zaufać?" i zaczęło brzmieć "co zrobimy z Programem B?". Ta zmiana - od walidacji danych do podejmowania decyzji - jest faktycznym celem. Cała reszta to infrastruktura.
Według Badania PMI dotyczące efektywności PMOOrganizacje z dojrzałymi procesami raportowania portfela realizują znacznie więcej projektów na czas i w ramach budżetu. Samo raportowanie nie jest tego przyczyną - ale złe raportowanie aktywnie ukrywa sygnały, które pozwoliłyby na wcześniejszą interwencję.
Od czego zacząć
Jeśli raport portfolio generuje więcej debat na spotkaniach niż decyzji zarządczych, najszybszą diagnozą jest zapytanie: co komitet wykonawczy faktycznie decyduje na podstawie tego raportu? Jeśli szczera odpowiedź brzmi "niewiele", raport nie spełnia swojego zadania - niezależnie od tego, jak solidna technicznie jest kompilacja Power BI.
Zacznij od tego. Zdefiniuj trzy decyzje, które komitet sterujący musi podejmować co miesiąc. Buduj wstecz. Następnie martw się o wizualizacje.
Jeśli masz to już za sobą, a wąskim gardłem jest sama warstwa Power BI, to Biblioteka wizualna LeapLytics jest warta uwagi - stworzona specjalnie do raportowania w kontekście zarządzania projektami, certyfikowana przez Microsoft i dostępna bezpośrednio do wypróbowania. Rozpocznij bezpłatny okres próbny tutaj i przetestować je w odniesieniu do rzeczywistych danych portfela.
