Każda współczesna organizacja IT ma problem z zarządzaniem zasobami. Jest to sytuacja powszechna i typowa dla większości firm, niezależnie od ich wielkości i branży, w jakiej prowadzą działalność.

Wdrożenie metod zarządzania portfelem projektów (PPM - Project Portfolio Management) z definicji pozwala organizacji poradzić sobie z większością problemów z zasobami. Przede wszystkim wprowadza powszechną kulturę planowania oraz systematyczny proces przydziału ludzi do poszczególnych zadań i projektów. W sytuacji, kiedy wiemy, kto w jakim projekcie uczestniczy teraz i do jakiego został zaalokowany na przyszłość, możemy świadomie planować i kontrolować jego pracę. W modelowej sytuacji zarządzania portfelem projektów wprowadza rozwiązania idealne. Dlaczego jednak nie zawsze sprawdzają się one w praktyce? Przyjrzyjmy się kilku historiom sukcesów i porażek.

Kto decyduje i kontroluje?

Modelowy proces planowania zasobów w ramach PPM jest przede wszystkim narzędziem komunikacji pomiędzy odpowiedzialnymi za projekty (kierownikami projektów, komitetami sterującymi, radą portfela) a przełożonymi poszczególnych pracowników. Typową sytuacją w organizacjach silosowych jest to, że bezpośredni przełożony danej osoby chciałby w pełni zarządzać jej czasem i zaangażowaniem w konkretne prace. Tymczasem wszelkie projekty, tworząc tymczasową, ale jednocześnie sformalizowaną strukturę zarządzania, która lokuje się niejako w poprzek normalnej struktury organizacyjnej, wymuszają, aby ktoś inny (kierownik projektu) przejmował kontrolę i podejmował decyzje w zakresie obowiązków danej osoby. Może to prowadzić do szeregu konfliktów i bardzo utrudniać operacyjne zarządzanie projektem.

W jednej z organizacji, z którą współpracował autor artykułu, obserwowano właśnie tego typu problemy. Organizację wyróżniało standardowe podejście do projektów. Project managerowie byli przedstawicielami biznesowej części firmy. Duża część projektów obejmowała swoim zakresem dział IT. Zgodnie z obowiązującymi zasadami, przed uruchomieniem realizacji projekt podlegał szczegółowemu planowaniu - włączając w to alokację zasobów IT, połączoną z weryfikacją ich dostępności. Prawie wszystkie projekty realizowane z udziałem IT cierpiały na dolegliwość permanentnych opóźnień i problemów zasobowych. Przeprowadzona analiza wykazała, że źródło stanowił menedżer IT, bardzo przywiązany do bezwarunkowego "władania" czasem pracy podległych mu pracowników. Przypadłość ta objawiała się częstymi i niezaplanowanymi "wrzutkami" dla pracowników działu IT. Oczywiście, prace te nie podlegały koordynacji z alokacjami zaplanowanymi na potrzeby projektów. Nietrudno się również domyślić, że prace zawsze miały priorytet. W efekcie w organizacji bardzo często dochodziło do konfliktów pomiędzy kierownikiem projektu a trudnym zespołem z IT. Z biegiem dni problem narastał do coraz większych rozmiarów - już na etapie planowania projektów wymyślane były strategie radzenia sobie z IT; w skrajnych przypadkach zaobserwowano nawet tworzenie dwóch wersji harmonogramu - jednej dla IT i drugiej "tajnej", z definicji zakładającej opóźnienia w IT.

Oczywiście, mówiąc o źródłach problemów z zasobami, w żadnym wypadku nie można zaryzykować stwierdzenia, że winę zawsze ponosi IT. Najlepszym kontrprzykładem jest niewielka firma (niecałe 50 pracowników) skoncentrowana na realizacji projektów informatycznych. W organizacji tej - podobnie do poprzednio opisywanej - również wąskim gardłem zasobowym było IT. Jednak w tym przypadku kierownicy projektów zbyt dosłownie brali stwierdzenie, że jedyną pewną rzeczą w projekcie jest zmiana. Wykazując się cenną dbałością o klienta, kierownik projektu często (nie zawsze świadomie) zamieniał się w opiekuna handlowego. Skutkiem tego były ciągłe częste i znaczące zmiany zakresu prac projektowych - oczywiście z koniecznością ich realizacji w trybie pilnym. Nadzwyczajność tej sytuacji polegała na tym, że kierownik projektu był rozliczany przede wszystkim z poziomu zadowolenia klienta. Nigdy nie dochodziło do sytuacji, w których weryfikowano rozbieżności pomiędzy pracochłonnością projektu zaplanowaną a rzeczywistą. Z obserwacji autora wynika, że rozbieżności występowały zawsze na minimalnym poziomie 25-30%, a niechlubni rekordziści z pewnością zbliżyli się do poziomu 200%. W efekcie ciągłej pracy w stresie i permanentnych nadgodzin w bardzo krótkim czasie dział IT, składający się z wybitnych specjalistów, przeszedł prawie stuprocentową rotację etatów i utratę większości wypracowanych kompetencji.

Według ustalonych reguł

Powyższe sytuacje stanowią ciekawe - ale i zatrważające - przykłady porażek. Na rynku jednak spotyka się organizacje, które potrafią radzić sobie z zarządzaniem zasobami. Jak one to robią?

Jedną z podstawowych zasad wprowadzania efektywnego procesu przydzielania ludzi do projektów jest jego formalizacja i unifikacja w całej organizacji. Nie chodzi o wprowadzenie bardzo sztywnych i niepraktycznych reguł. Na proces ten warto spojrzeć jak na rodzaj kontraktu, zawieranego pomiędzy project managerem a przełożonym osób uczestniczących w projektach. W ramach tego kontraktu kierownik projektu zobowiązuje się do osiągnięcia zdefiniowanego rezultatu, zachowując określone terminy i kryteria jakościowe, a przełożony udostępnia czas i kompetencje swojego podwładnego, gwarantując konkretne parametry jego dostępności w całym okresie trwania projektu. Oznacza to konieczność czasowego delegowania na kierownika projektu uprawnień do zarządzania pracą danej osoby w ustalonym zakresie i terminie oraz wyklucza sytuację, w której zostanie ona bez uzgodnienia zabrana do "innych ważniejszych zadań".

Oczywiście, zarówno projekty, jak i cała codzienna działalność biznesowa to ciąg nieustannych zmian. Dlatego niewątpliwie - i raczej szybciej niż później - pojawi się konieczność odstępstwa od każdego takiego kontraktu. Bo dana osoba rzeczywiście będzie musiała zająć się czymś innym, co jest bardziej istotne ze strategicznego punktu widzenia, bo projekt się przedłuża, gdyż wymagane jest zwiększenie zaangażowania pracownika. Tyle tylko, że należy na to patrzeć właśnie jako na formalną aktualizację istniejącego kontraktu, a nie reaktywne działanie ad hoc. W ramach uporządkowanego procesu najpierw zostaje przez kierownika projektu zmodyfikowany harmonogram i ewentualnie inne wymagane parametry projektu, a dopiero potem podejmowana jest świadoma decyzja, biorąca pod uwagę wszelkie konsekwencje tak przeprowadzonej zmiany. Wynikiem tego działania staje się zawsze nowy kontrakt. Tak stosowane i, co ważniejsze, rozumiane oraz akceptowane podejście do planowania zasobów autor artykułu obserwował w organizacjach efektywnie zarządzających ludźmi w projektach.

O ile sam proces wydaje się prosty, o tyle w praktyce wymaga on posiadania rzeczywistych i aktualnych informacji o planowanym i faktycznym "obłożeniu" ludzi projektami. Aby zobrazować skutki braku informacji o wykorzystaniu zasobów w projektach, warto ponownie przywołać firmę z przykładu numer dwa. Istnieje uzasadnione (ale nigdy niesprawdzone z powodu braku kontrolingu projektowego) podejrzenie, że część projektów realizowanych przez tę organizację była nierentowna - mimo wykazywania zysków przez kierownika projektu. Powodem było bezkosztowe traktowanie zasobów ludzkich oraz brak jakiejkolwiek wiedzy o rzeczywiście przepracowanej liczbie godzin w projekcie.

Role czy ludzie?

Warto zastanowić się również nad jeszcze jednym aspektem planowania zasobów do projektów, a mianowicie nad pytaniem, czy powinniśmy planować konkretne osoby, czy też raczej wymagane kompetencje. Innymi słowy, czy alokujemy rolę "analityk biznesowy", czy też osobę - Jana Kowalskiego. Na etapie przygotowywania założeń zdecydowanie lepiej jest posługiwać się kompetencjami (rolami). Pozwala to na znacznie większą efektywność planowania. Tworzy również elastyczność w zakresie późniejszego przetasowywania osób między projektami. Nie należy jednak przeceniać tej elastyczności, ponieważ zastąpienie w trakcie trwania projektu analityka A analitykiem B, nawet o tych samych albo wręcz większych kompetencjach, może być bardzo trudne i kosztowne ze względu na specyficzne doświadczenie nabywane w ramach realizowanych prac, relacje wewnątrz zespołu i szereg innych "miękkich" aspektów. Dlatego warto unikać takich zmian, nawet jeśli wydają się proste i naturalne, ponieważ ich koszty i konsekwencje mogą okazać się znacznie wyższe, niż może się początkowo wydawać.

Z drugiej strony nie można mylić zarządzania portfelem projektów z mikrozarządzaniem. Perspektywa PPM to patrzenie na alokację poszczególnych ról (a nie osób) w określonych przedziałach czasu, takich jak miesiące czy kwartały. Operacyjne zarządzanie przydziałem poszczególnych osób do zadań w każdym dniu czy też godzinie to już rola kierownika projektu lub kierownika danego zespołu. Często na etapie wstępnego planowania próbuje się zbilansować cały portfel, aby w każdym momencie unikać przeciążeń. To błąd, ponieważ w ten sposób gubi się kontekst strategiczny, a rzeczywistość i tak zweryfikuje wszystkie szczegółowe plany.

Dominik Chrzanowski jest dyrektorem Departamentu ValueBoard w firmie ValueTank dostarczającej usługi doradcze i rozwiązania wspomagające strategiczne obszary zarządzania przedsiębiorstwem.