Zarządzanie programem staje się coraz bardziej popularne również w Polsce. Już nie tylko projekty inwestycyjne stosują takie podejście, ale także złożone i powiązane projekty organizacyjne, usprawnieniowe i informatyczne potrzebują zarządzania programem.
Z jednej strony teoretyczna struktura organizacji programu jest bardzo prosta i składa się z trzech poziomów: Komitetu Sterującego, Kierownika Programu i Kierowników Projektów, ale w praktyce widać, jak wiele błędów popełniamy w naszych organizacjach przy uruchamianiu i realizacji tego typu przedsięwzięć. Popatrzmy na główne wyzwania, które stoją przed nami.
Komitet Sterujący
Programy dotykają wielu interesariuszy i wielu departamentów, dlatego bardzo często widzimy przerośnięte struktury organizacyjne programu. Wynika to w dużej mierze z błędnie rozumianej roli Komitetu Sterującego. W Komitecie powinny być osoby, które będą decydować o programie jako całości, a bardzo często mamy tam przedstawicieli spółek lub departamentów, których ludzie pracują w projektach realizowanych w ramach programu. Jest to bardzo sprytna metoda zaangażowania interesariusza i często sprawdza się na poziomie projektu, ale już na poziomie programu powoduje tylko niepotrzebne komplikacje. Wstawienie do Komitetu Sterującego Programu przedstawicieli wszystkich spółek zaangażowanych w realizację programu lub wszystkich sponsorów projektów realizowanych w ramach programów powoduje, że mamy wieloosobowe Komitety Sterujące, w których podjęcie decyzji zajmuje wielokrotnie więcej czasu niż potrzeba. Przykładem może być sektor publiczny w Polsce, gdzie na spotkaniu Komitetu Sterującego Programu pojawiło się ponad 50 osób! Dwie decyzje, które można było podjąć w wąskim gronie decydentów, zajęłyby 20 minut, a spotkanie trwało… ponad 4 godziny. Komitet Sterujący Programu ma składać się z osób decyzyjnych dla programu, a nie być sposobem zarządzania zaangażowaniem interesariuszy – są do tego inne sposoby.
Struktura decyzyjna się komplikuje, gdy Komitet Sterujący powołuje dodatkowy podkomitet konsultacyjny, stanowiący zespół doradczy dla Komitetu Sterującego. Zespół Dyrektorów, konsultantów zewnętrznych lub doświadczonych menedżerów w danym sektorze stanowi bardzo istotne uzupełnienie wiedzy merytorycznej dla Komitetu Sterującego Programu, ale nieprecyzyjne określenie uprawnień podkomitetu powoduje dużo komplikacji we współpracy Kierownika Programu z Komitetem Sterującym. Podobny podkomitet pojawia się również w sytuacji, gdy Komitet Sterujący chce korzystać z pomocy audytora/kontrolera programu, który w jego imieniu nadzoruje program z większą częstotliwością.
A co jeśli skład jest źle dobrany, ponieważ zarząd delegował do Komitetu Sterującego Programu swoich ludzi, a nie osoby, które powinny naprawdę decydować o losach programu? W takiej sytuacji w Komitecie Sterującym pojawia się osoba niedecyzyjna, która w praktyce opóźnia działanie Komitetu. Przykładem niewłaściwie dobranego Komitetu Sterującego może być również sytuacja z pewnej organizacji – w programie reorganizacji firmy w zakresie współpracy i obsługi klienta Dyrektor Sprzedaży nie był włączony do Komitetu, bo nie chciał – projekt był zbyt ryzykowny i nie do końca po jego myśli. Dzięki temu mógł spokojnie opóźniać wprowadzenie zmian w swoim departamencie poprzez bojkotowanie programu (za niego nie odpowiadał).
Zachęcam kierowników programów do własnej analizy, czy skład Komitetu Sterującego został dobrany właściwie ze względu na specyfikę zakresu programu oraz cele i korzyści, dla których został powołany. Czasami w programach pojawia się Właściciel Biznesowy/Dyrektor Programu odpowiedzialny za całość i stanowiący punkt kontaktowy między Komitetem Sterującym (spotykającym się dość rzadko – np. raz na kwartał) a Kierownikiem Programu, który potrzebuje bieżących konsultacji z przedstawicielem Komitetu Sterującego. W takiej sytuacji pojawienie się roli Właściciela Biznesowego/Dyrektora Programu stanowi wypełnienie ważnej luki w strukturze zarządczej. Ale oczywiście muszą być dobrze doprecyzowane uprawnienia takiej osoby, bo czasami próba poradzenia sobie samemu (bez angażowania Komitetu) powoduje, że taka osoba zaczyna ciągnąć program trochę w innym kierunku niż wyznaczył Komitet.
Kierownik Programu
Tutaj podejście jest proste – mamy jednoosobową odpowiedzialność za zarządzanie całym programem. Ale co w sytuacji, kiedy mówimy o programie inwestycyjnym i spółce celowej powołanej do zarządzania całością programu? Wtedy często struktura takiej spółki składa się z Zarządu, Dyrektora Zarządzającego i kierowników lub dyrektorów danego obszaru. Całość stanowi bieżącą strukturę zarządczą dla programu.
Na poziomie zarządczym pojawia się również problem synchronizacji prac w projektach. Jeżeli potrzebujemy głównego architekta rozwiązania, to powinien on być w strukturach zarządczych programu jako oficjalna rola, a nie być wpisany jako konsultant wielu projektów. Jeżeli wiele działań jest synchronizowanych na poziomie programu (np. raportowanie), wtedy potrzebujemy PgMO, które wspomoże kierownika programu. Przykładem tutaj może być program digitalizacji firmy, gdzie dla wielu projektów zarządzanych przez różne działy biznesowe został powołany jeden koordynator po stronie działu IT. Taki koordynator w normalnej strukturze powinien się znaleźć pod kierownikami projektu, ale byłaby to nieefektywna struktura. Dlatego konieczne było ustawienie takiej roli na poziomie całego programu, aby to Kierownik Programu priorytetyzował prace po stronie wspólnego (dla wielu projektów) zespołu IT.
Na takim poziomie zarządczym pojawia się również problem współpracy z dostawcami. Który dostawca powinien być zarządzany przez Kierownika Programu? Dla których dostawców wystarczy, że współpraca będzie na poziomie projektów? Chcielibyśmy nie zajmować się na poziomie programu dostawcami, którzy są potrzebni tylko dla jednego projektu, ale czasami dla synchronizacji zleceń, płatności lub raportowania musimy zarządzać podwykonawcami na poziomie całego programu. Takie decyzje powodują konieczność doprecyzowania wszystkich aspektów współpracy na linii Kierownik Programu – Kierownik Projektu – Kierownik po stronie dostawcy.
Poziom projektów
Czy w strukturze zarządzania programem powinniśmy budować Komitety Sterujące dla projektu? Co, jeżeli budujemy infrastrukturę i jeden projekt jest realizowany tylko i wyłącznie z punktu widzenia potrzeb programu? W praktyce oznacza to, że sponsorem takiego projektu powinien zostać Kierownik Programu. W przypadku, gdy finansowanie dla projektu jest zapewnione z budżetu programu, wtedy ten model jest oczywisty. Ale mamy również sytuację, kiedy lokalny projekt jest finansowany z innego źródła (budżetu spółki, dofinansowanie unijne, itp.). Wtedy wydaje się, że potrzeba powołania Komitetu Sterującego dla jednego projektu się pojawia, ale spójrzmy w praktyce jaki zakres decyzyjny powinien mieć taki Komitet? Czy powinien sam decydować o przesunięciu tego projektu? Najczęściej nie, bo projekt jest w programie i taka decyzja najczęściej wpływa na inne projekty, na inną dystrybucję osób, dostawców w projekcie. Czy Komitet Sterujący sam powinien podejmować decyzję o zwiększeniu budżetu projektu? Z jednej strony – jeśli Komitet Sterujący sam finansuje projekt to powinien móc podjąć taką decyzję, ale z drugiej strony program został uruchomiony przy pewnych założeniach finansowych dla całości, więc czy pojedynczy projekt może zwiększać budżet bez konsultacji z kierownikiem programu? W jednej firmie w ramach międzynarodowego programu Polska realizowała jeden z projektów. Projekt ten był finansowany z lokalnych środków, ale całość była uwzględniona i akceptowana na poziomie budżetu całego programu. Brak określonych zasad podejmowania decyzji na poziomie projektu spowodował, że w momencie, kiedy w Polsce zorientowano się, że koszty projektu są niedoszacowane postanowiono (bez decyzji na poziomie programu) zwiększyć budżet przedsięwzięcia (aby temat nie został wykryty). I oczywiście z punktu widzenia finansowania nie ma problemu, bo budżet się znalazł i projekt został dowieziony, ale z punktu widzenia budżetu całego programu nie mamy pojęcia o rzeczywistych kosztach wdrożenia jednego projektu. Jakie decyzje wtedy podejmiemy? Jak oszacujemy kolejny projekt w kolejnym kraju w ramach tego programu, jeżeli nie wiemy o rzeczywistych wydatkach?
Ustawiając organizację programu warto rozpocząć od analizy otoczenia programu, struktury organizacyjnej firmy, celów i korzyści programu i na tej podstawie rozpocząć analizę struktur organizacyjnych dla programu. Struktura zarządzania programem powinna zostać ustawiona z punktu widzenia całości niezależnie od tego, jakich projektów i ilu będziemy potrzebować do realizacji celów. Takie spojrzenie pozwala na ustawienie właściwych interesariuszy do struktur programu.
Uwzględnienie i analiza wyżej wymienionych wyzwań i błędów na wszystkich trzech poziomach zarządzania pozwoli nam bardziej świadomie ustawić całość programu. Struktura zarządzania programem wymaga dopasowania jej do specyfiki programu i w praktyce zawsze będzie to indywidualnie zaprojektowane podejście dla danego programu.
Ekspert w zakresie zarządzania projektami, portfelem projektów i PMO. Specjalizuje się w obszarze usprawnień organizacji poprzez wdrożenie zarządzania portfelem projektów i PMO oraz w obszarze rozwoju kierowników projektów. Od 2003 roku związany z PMI®, gdzie pełnił m.in. funkcję Prezesa Oddziału Polskiego. Z centralą PMI® w USA związany od 2010 roku – obecnie pracuje w Komitecie do Spraw Certyfikacji (CGC). Od 2010 roku prezes firmy WHITECOM Project Experience specjalizującej się w szkoleniach, ustawianiu PMO oraz zarządzaniu projektami i portfelem projektów. Współautor książki PMO. Praktyka zarządzania projektami i portfelem projektów w organizacji.