Chciałem się tym razem podzielić moimi doświadczeniami z funkcjonowania komitetu sterującego. Bo jak to często okazuje się teoria sobie, a praktyka sobie.
Metodyka taka, czy owa mówią, że komitet sterujący to ciało decyzyjne podejmujące decyzje w projekcie. PRINCE2 precyzuje, że składa się z przedstawiciela klienta, dostawcy i przewodniczącego. Każdy z nich ma ściśle określoną rolę: jeden broni interesów wymagań projektowych, drugi reprezentuje interesy dostawcy, a trzeci pilnuje kasy i uzasadnienia biznesowego projektu. PMBOK z kolei mówi o sponsorze projektu oraz kierownictwie firmy biorącym udział w podejmowaniu decyzji projektowych. Do każdego projektu powinien zostać wyznaczony dedykowany komitet sterujący, który będzie wsparciem dla danego kierownika projektu i jego zespołu.
Natomiast praktyka, jaką spotkałem bywa zupełnie inna. Wezmę na tapetę dwie skrajnie różne firmy. Jedna, nazwijmy ją A, zatrudniająca kilka tysięcy pracowników, realizująca 50 projektów rocznie o budżetach równych kilkadziesiąt milionów złotych. Druga, zgodnie z logiką B, zatrudniająca kilkudziesięciu pracowników z projektami o rocznych budżetach rzędu kilku milionów. Skrajnie różne branże, kultury organizacyjne, technologie, sposoby organizacji pracy, lokalizacje. Los chciał, że poznałem je obie dość dokładnie. Firma A prowadzi projekty rozwijające jej usługi. Są to w dużej mierze projekty informatyczne, zależne od wewnętrznego działu IT. Zespół ludzi zaangażowanych w projekty jest stały: kilkadziesiąt osób ze strony tzw. biznesu oraz ponad stu informatyków. Co więcej prawie wszystkie projekty skupiają się na zmianach w centralnym systemie informatycznym, więc kluczowe jest ich właściwe ułożenie na osi czasu.
Komitet sterujący w takiej organizacji to wybrani członkowie zarządu, dyrektorzy IT, dyrektor projektów. Na niektóre zebrania dopraszani są dyrektorzy albo kierownicy działów powiązanych z wybranymi, właśnie omawianymi projektami. Mimo prób uruchomienie KS dedykowanych wybranym projektom to nie zadziałało. Fakt,że wszyscy korzystają z tych samych zasobów ludzkich powoduje, że nie ma sensu omawiać pojedynczego projektu w oderwaniu od reszty portfela. Jedną z głównych jego funkcji jest ułożenie optymalnej kolejności projektów i przypisanie ich do konkretnych wersji głównego systemu.
Co ciekawe, kiedy realizowany jest projekt z zewnętrznym dostawcą, niekiedy powołuje się komitet sterujący, który angażować będzie przedstawiciela zewnętrznej firmy. Taki KS ma charakter rozliczający postęp umowy, zamykający odbiorami kolejne etapy lub autoryzujący dodatkowe płatności. Działa on równolegle do komitetu nadzorującego cały portfel.
Czasem też pojawia się swego rodzaju rytualny KS, gdy spółka matka oczekuje większego nadzoru nad realizacją konkretnego projektu. Wówczas zadaniem firmy A jest takie przygotowanie prezentacji i raportów, aby pokazywały pozytywy projektu, łagodząc jednocześnie pesymistyczny wydźwięk negatywów. Trudno w tym wypadku o rzeczywistą kontrolę, gdyż spółka córka stara się wszystko przedstawić w pozytywnym świetle, a spółka matka nie ma czasu przyjrzeć się szczegółowo temu, co naprawdę siedzi w projekcie. Firma B realizuje projekty inżyniersko-produkcyjne. Projekty są robione dla zewnętrznych klientów, ale głównie swoimi zasobami. Zewnętrzni klienci nie oczekują formalnego raportowania, natomiast wewnętrznie ze względu na rozmiar firmy nie ma konieczności prowadzenia wielu formalizmów obecnych w dużych organizacjach.
KS organizowany jest dla wszystkich projektów wspólnie. Bierze w nim udział większość samodzielnych specjalistów i kierowników w firmie. A jego rola to głównie informacja o stanie portfela projektów oraz bieżące rozwiązywanie problemów. Agenda polega na odpytaniu wszystkich ze statusu i istotnych zagadnień w projektach oraz sprowokowaniu do wspólnego skoordynowania prac produkcyjnych i logistycznych pomiędzy projektami, aby na przykład zachować właściwą kolejność prac produkcyjnych lub wysyłać mniej transportów. Ponieważ firma w 90% żyje z projektów to jest to również miejsce do porozmawiania o mniejszych zleceniach, reklamacjach i problemach technicznych. Decyzje podejmuje się kolegialnie bez formalnego rozdzielania ról decydentów.
Znowu nie ma potrzeby organizowania KS dedykowanego pojedynczemu projektowi. Nawet klienci tego nie wymagają, co może wynikać z niskiej świadomości, bądź postawy typu „zamówiłem, więc niech dostawca się martwi o projekt”.
Narzędziami monitorowania portfela są tabelki w Excelu z listą kluczowych kamieni milowych, rozliczeniem osobodni oraz ustna informacja o problemach w projektach.
Podsumowując, taka rozbieżność między teorią a praktyką może mieć swoje źródło w tym, że PRINCE2 wyrósł z przetargów organizowanych przez administrację publiczną. Wówczas racjonalnym jest organizowanie KS, który powodowałby, że dostawca spowiada się przed klientem. Natomiast panuje przekonanie, że PMBOK za punkt wyjścia ma dostawcę, który realizuje duży, złożony projekt, wymagający indywidualnego dogadania z klientem sposobu nim zarządzania. W praktyce firmy regularnie realizujące projekty mają wydeptane ścieżki wyrażone: podobnym cyklem życia (etapami), dokumentami, rolami. A więc i łatwo o wspólny nadzór nad nimi.
Natomiast nie spotkałem metodyki, która za punkt wyjścia w organizacji tzw. governance miałaby zarządzanie portfelem projektów u dostawcy. Czyli wychodziłaby z założenia, że większość projektów przechodzi podobną ścieżką, więc z definicji zarządzanie nimi powinno być zbieżne. I jednocześnie brałaby pod uwagę sytuację, że klienta nie obchodzi sposób zarządzania projektami przed dostawcę, on chce mieć po prostu zrobione zadania na czas i na odpowiednim poziomie jakościowy oraz w cenie uzgodnionej na początku kontraktu. A ta perspektywa jest właściwa dla firm, w których większość projektów jest realizowana za pomocą wewnętrznych zasobów albo firm, w których realizuje się wiele projektów w podobnym cyklu życia. Czyli wydaje się, że większości firm. 😉
