Rosnąca złożoność projektów powoduje, że kierownicy projektów oraz organizacje szukają rozwiązań i technik związanych z zarządzaniem programami. Mnogość departamentów i działów (a nawet krajów) zaangażowanych w realizację przedsięwzięcia, a przy tym coraz większa otwartość Dyrekcji i Zarządów do delegowania uprawnień w organizacji powoduje, że w firmach „robi się miejsce” na zarządzanie programami. Nie mówimy tutaj jednak o dodatkowej metodycznej nazwie, ale rzeczywistym zapewnieniu korzyści dla firmy z organizacji i synchronizacji realizowanych powiązanych projektów. Czy w takim razie jesteśmy gotowi na zarządzanie programami i czy do końca rozumiemy, co oznacza wdrożenie ich w przedsięwzięciu lub całej organizacji? Spójrzmy na kilka praktycznych aspektów prowadzenia programów.
Zastosowanie programów
Pierwszym ważnym aspektem jest odpowiedź na pytanie – gdzie mam zastosować zarządzanie programem? O ile oczywiste jest, że wdrożenie w wielu krajach złożonych rozwiązań informatycznych lub inwestycyjnych jest miejscem na program, o tyle wiele innych przedsięwzięć stanowi już znak zapytania, czy jest to złożony projekt, czy program? Przede wszystkim musimy zrozumieć, że zastosowanie programu oznacza dodatkową warstwę zarządczą nad projektami, która kosztuje! Dlatego wartość z zastosowania tego podejścia musi być widoczna. Drugi aspekt to rzeczywiste oddelegowanie uprawnień do podejmowania decyzji za projekty znajdujące się w programie. Czy Twoja organizacja jest na to gotowa? Oczywiście główną korzyścią z zastosowania programów jest dostarczenie wspólnych korzyści z synchronizacji projektów. Miałem okazję wdrażać metodykę zarządzania programami w firmie telekomunikacyjnej, gdzie Zarząd zgodził się na prawie wszystkie elementy podejścia, tylko chciał samodzielnie decydować o każdej bramce decyzyjnej i zmianie w projekcie. Przy takim podejściu wystarczy zarządowi sprawnie działające PMO i nie potrzebuje kierownika programu.
Wiele firm realizuje programy nie nazywając ich programami. Pierwszą kwestią do rozwiązania jest sama nazwa – czy powinniśmy ją wprowadzać? Z punktu widzenia organizacji i uczestników projektów nie zawsze wskazane jest wprowadzanie nowych skomplikowanych bytów. Pamiętam dyskusję z jednego programu, gdzie było tyle propozycji nazywania elementów programów (projekty składowe, strumienie, komponenty – zgodnie z metodyką, projekty zależne, itd.), że Komitet Sterujący nie mógł się zdecydować na wybór nazwy. Ze względu na komunikację z otoczeniem (inwestorzy, mieszkańcy, media) przyjęto nazwę dla całości „Projekt”.
Problem z podziałem obowiązków
Najważniejszym aspektem programu, który powinien być zaprojektowany na początku, jest struktura organizacyjna i uprawnienia w programie. Zacznijmy od składu osobowego Komitetu Sterującego dla programu, który musi działać sprawnie i podejmować decyzje strategiczne. Moim ulubionym przykładem jest sektor publiczny, gdzie do Komitetu Sterującego programu zaproszono przedstawicieli wszystkich projektów wchodzących w skład programu. Spotkania 30-osobowego Komitetu musiały trochę trwać… W praktyce tylko dwie osoby na poziomie programu decydowały o wszystkim, ale Komitet trzeba zorganizować w odpowiednim dla wszystkich terminie. Drugi poziom to odpowiedzialność za projekty i uprawnienia w kontekście podejmowania decyzji strategicznych dla projektów. Czy potrzebujemy Komitetu Sterującego do danego projektu? Kto powinien być Sponsorem projektu w programie? Na te pytania musimy odpowiedzieć z punktu widzenia korzyści każdego projektu i efektywności podejmowania decyzji (które wpływają na program jako całość).
Strumienie vs projekty
Trzeci aspekt do ustawienia to organizacja podprogramów, projektów i innych prac w programie. Musimy tutaj zdecydować, które elementy powinny zostać zidentyfikowane jako osobne projekty, a które możemy po prostu traktować jako strumień prac (możliwe, że zarządzany przez osobnego kierownika projektu). Powinniśmy wybrać najprostszą możliwą strukturę, która zapewni nam realizację przedsięwzięcia. Gdzie w takim razie potrzebne nam są projekty w programie? Na przykład wprowadzając program w wielu krajach, w jednym kraju musimy powołać dedykowany projekt i to w dodatku zgodnie z przepisami obowiązującymi w danej spółce zależnej. Taki projekt oprócz korzyści na poziomie programu, będzie też realizował korzyści dla danej spółki. Czy na przykład budowa stadionu, który był rozbudowywany na potrzeby organizacji mistrzostw świata czy Europy, realizuje tylko korzyści dla programu? Nie! Jego cykl życia jest dłuższy i decyzje o tym projekcie powinny zapadać pod kątem nie tylko programu. Dlatego w takiej sytuacji nie tylko będzie nam potrzebna struktura projektu, ale również lokalny Komitet Sterujący projektu, który zadba o przyszłe korzyści dla organizacji (a nie tylko programu).
O dostosowaniu programów
Czwarty aspekt to specyfika programu, która zawsze wymaga dostosowania. Pierwszym obszarem jest podział obowiązków zarządczych. Kierownik programu nie jest w stanie realizować wszystkich aspektów sam. Powołanie biura zarządzania programem wraz ze zdefiniowanym składem osobowym to jedna z pierwszych decyzji. W jednym programie inwestycyjnym do biura zatrudniono dwóch specjalistów na pełen etat zajmujących się tylko komunikacją zewnętrzną. Drugi temat to raportowanie – jakie dane są nam potrzebne z projektów, jak będziemy monitorować status korzyści, jak będą wyglądać raporty dla Komitetu, Inwestora, Banków, Grupy Kapitałowej, mediów, itp.? Trzeci aspekt to samo monitorowanie zakresu programu. Pomimo faktu, że to w projektach realizujemy główne prace i produkty, to musimy zapewnić sobie pilnowanie zakresu na poziomie programu. Robimy to nie tylko w celu monitorowania postępu, ale również synchronizacji podziału zakresów i monitorowania zależności między elementami programu. Kolejny aspekt to sposób współpracy z dostawcami. Bardzo często wymagane jest ich zarządzanie na poziomie programu w celu synchronizacji prac i ustalania priorytetów. Te wszystkie aspekty wymagają decyzji i ustawienia jeszcze przed rozpoczęciem realizacji projektów.
Podsumowanie
Co w takim razie zrobić, jeśli organizacja lub my sami nie posiadamy zdefiniowanej metodyki i doświadczeń z zarządzaniem programami? Najprostsza odpowiedź brzmi: użyj podejścia projektowego! Tylko sprawdź wszystkie obszary wiedzy i dostosuj je do specyfiki i skali programu.
Zarządzanie programami zyskuje na znaczeniu w coraz bardziej złożonych i rozbudowanych inicjatywach realizowanych w organizacjach. Co więcej, zależności technologiczne, architektoniczne, czy funkcjonalne dotyczące wdrażanych w firmach zmian powodują, że wiele praktyk z zarządzania programami może mieć również zastosowanie w inicjatywach mniejszej skali. Niestety tylko pojedyncze organizacje mogą pochwalić się wdrożonymi dobrymi praktykami zarządzania programami i brak jest gromadzenia wiedzy w tym zakresie. Podnoszenie dojrzałości zarządzania projektami w firmach powoduje też, że coraz większa jest gotowość organizacji do delegowania uprawnień do zarządzania „grupą projektów”. Patrząc w przyszłość – zarówno kierownicy projektów powinni rozwijać swoje kompetencje w tym zakresie, ale również PMO powinno pomyśleć o przygotowaniu się na kolejny krok w organizacji projektów w firmie.
Fot. Pascal OLHMANN z Pixabay
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.