O zarządzaniu projektami

Zarządzanie projektami to nie jest coś, co lubię. To nawet nie jest coś, co potrafię robić (i zwykle tego nie robię). Mam natomiast kilka obserwacji odnośnie tego, jakie błędy są popełniane przy projektach IT.

Jakie “mierzalne” atrybuty ma projekt?

Najprościej wyróżnić trzy atrybuty:

Oznacza to mniej więcej tyle, że celem projektu jest stworzenie sytemu realizującego określone zadania w trakcie określonego czasu przeznaczając na to określoną sumę pieniędzy.

Co to jest “sukces projektu

Sukces projektu można zdefiniować jako zrealizowanie go w przewidzianym zakresie w zakładanym czasie mieszcząc się w planowanym budżecie. Oczywiście z projektami wiąże się zawsze pewne ryzyko, więc pewne modyfikacje wszystkich trzech parametrów są dopuszczalne. Problem tylko, że czasami jest to zwiększenie budżetu o 5%25, a czasami trzykrotne wydłużenie czasu jego realizacji...

Jak je dobrać?

Te trzy atrybuty kojarzą mi się z trzema ramionami trójkąta, a co za tym idzie z warunkiem (nierównością) trójkąta. Tak jak trójkąta nie zbuduje się z dowolnych trzech odcinków, tak i projektu nie zrealizuje się dowolnie manipulując tymi trzema parametrami.

...na przykład...

Niech projektem będzie przebycie 100 kilometrów. Budżetem na ten projekt jest jeden piechur, czas trwania to 5 dni. Czy projekt ma szanse powodzenia? W zasadzie tak, bo 100 kilometrów to tylko 20 kilometrów dziennie, a tyle to robi przeciętny piechur w trakcie 4 godzin. Oczywiście zakładając, że ten biedny piechur nie idzie przez śnieg sięgający pasa (ale dla ułatwienia przyjmijmy, że idzie sobie równiną po dość dobrej ścieżce).

Teraz wprowadźmy pewne modyfikacje do projektu. Niech czas zostanie skrócony do 2 dni. Czy projekt nadal jest realny? Być może. 50 kilometrów dziennie to dystans osiągalny dla wprawionego piechura. Teraz ważne jest, czy w budżecie projektu zawiera się piechur wprawiony, czy też ktoś, kto pieszo chodzi na przystanek, a to i tak tylko wtedy, gdy samochód stoi w warsztacie... Jeśli zmianie czasu trwania towarzyszy uwzględnienie piechura wytrawnego, to sukces projektu jest realny. W drugim przypadku zachęcany argumentami “nie obchodzi mnie czy zdechniesz po drodze, masz to zrobić” okazyjny piechur z lekką nadwagą nie ma praktycznie szans na pokonanie takiego dystansu. Jest prawie pewne, że tych 100 kilometrów nie uda się pokonać w ciągu 2 dni. Co więcej istnieje prawdopodobieństwo, że również i budżet będzie trzeba podnieść, bo ten “dobrze zmotywowany” piechur po tej drodze rzeczywiście padnie...

Przekładając to na branżę IT...

Realizacja określonej funkcjonalności trwa określony czas. Czasami ciężko go właściwie oszacować, więc należy uwzględnić pewne ryzyko i pozostawić sobie pewien zapas czasu. Ogólnie jednak można z dość dużą dokładnością przewidzieć ile czasu określony zespół ludzi (budżet!) daną funkcjonalność będzie implementować.

Próba zmieszczenia się w zbyt krótkim czasie kosztem wydłużenia czasu pracy pracowników (a kto by im płacił za nadgodziny?) jest również skazana na niepowodzenie. Zmuszając kogoś do pracy 16 godzin na dobę nie należy oczekiwać, że będzie on dwa razy bardziej wydajny, niż pracując tych godzin tylko 8. A i więcej błędów zrobi... Co więcej ci wredni pracownicy motywowani wzniosłym etosem “pracuj aż padniesz” z dużym prawdopodobieństwem rzeczywiście “padną”, co w tym przypadku po prostu oznaczać będzie odejście z tej pracy...

...i wówczas do akcji wkracza zasada “każdego specjalistę można zastąpić skończoną ilością studentów”. Jednocześnie doskonale manifestuje się inna zasada związana z prowadzeniem projektów. A mianowicie ta, że dodanie zasobów (pracowników) do opóźnionego projektu, zwiększa jego opóźnienie. W tym wypadku w dodatku mamy do czynienia z zasobami (wcale nie zamierzam obrażać studentów) średniej jakości. Taki student to prawie specjalista, ale prawie robi różnicę. W efekcie ilość wprowadzonych błędów rośnie, co przekłada się na czas testów stworzonego systemu, ilość zgłoszonych błędów i czas ich usunięcia.

Parametry “nieruszalne”...

Jeśli jedna firma wynajmuje drugą do realizacji projektu, to przynajmniej dwa parametry stają się “nieruszalne”. To budżet rozumiany jako zapłata za realizację projektu oraz jego zakres. A co z czasem? Okazuje się, że tu może być ciekawie...

Jak zabezpiecza się dostawca?

Zwykłą praktyką jest zawarcie w umowie kar umownych, które wykonawca płaci zamawiającemu za każdy dzień opóźnienia. Jestem prawie pewny, że znaczna część dostawców wlicza sobie kary umowne w żądane wynagrodzenie za realizację projektu. Co więcej wysokość kar umownych bywa śmiesznie niska, bo jak inaczej określić sytuację, w której wykonawca zarabiający sumę z sześcioma zerami za realizację projektu, proponuje w umowie kary na poziomie, uwaga, kilkuset złotych? To jest mniej niż dniówka jednego specjalisty. Dniówka oczywiście “rozliczeniowa”, bo specjalista z tych pieniędzy to tylko nieznaczną część widzi. Kara, jeśli ma być rzeczywistym narzędziem zmuszenia wykonawcy do wywiązania się z założonego harmonogramu, musi być dotkliwa. Nie chodzi o to, by dostawca bał się, że zbankrutuje, ale sytuacja, w której bardziej opłaca się opóźnić jeden projekt przenosząc zasoby do drugiego (kary są niższe niż koszt utrzymania pracownika) jest po prostu chora.

Jak zabezpiecza się odbiorca?

Tu jest jeszcze ciekawiej, zwłaszcza jeśli odbiorca negocjujący warunki umowy nie jest końcowym odbiorcą. W trakcie mojej pracy w korporacji dowiedziałem się mianowicie, że istnieją trzy daty zakończenia projektu...

Pierwsza data zakończenia projektu to data, która jest podawana dostawcy (negocjowana). Zwykle jest to data wcześniejsza niż ta, którą pierwotnie zaproponował dostawca. Ponieważ dostawca często sztucznie skraca czas trwania projektu (bo na przykład jest to parametr oceny oferty), data ta jest praktycznie nierealna.

Druga data to data, w jakiej odbiorca zakłada, że projekt się realnie zakończy. Zwykle może ona lokować się w okolicach daty pierwotnie proponowanej przez wykonawcę.

Trzecia data to data, jaką otrzymuje do wiadomości odbiorca (ten końcowy). Jest to najczęściej data późniejsza, niż oczekiwana data rzeczywistego zakończenia projektu. Dlaczego? No przecież trzeba mieć jakiś sukces! A jak to dobrze będzie wyglądać, jeśli projekt zakończy się miesiąc przed oczekiwanym terminem!

Gdyby wykonawcy postawili się zamawiającemu, wówczas ta technika może by zakończyła swoją karierę. Niestety, tak nie jest. Wykonawca zrobi (prawie) wszystko, by zdobyć kontrakt, więc o sensowne ustawienie parametru czas , zwłaszcza w przypadku śmiesznych kar umownych, bojów toczyć nie będzie.

W praktyce spotkałem się tylko raz z sytuacją, w której (potencjalny) dostawca zerwał negocjację gdy odbiorca nie modyfikując zakresu chciał zmniejszyć cenę o 22%25 (“to ta cena netto jest dla mnie ceną brutto”) i ustawić irracjonalny czas (“musicie to zrobić przed X bo inaczej mnie to nie interesuje”). Muszę przyznać, że notowania tej firmy podskoczyły znacznie w moich oczach.

I to by było tyle...

Na chwilę obecną to tyle moich refleksji o projektach... Jeśli za miarę sukcesu projektu uznać realizację pełnego zakresu w określonym czasie i budżecie, to znaczna część znanych mi projektów zakończyła się niepowodzeniem.

A klucz do porażki to chcieć zbyt wiele (zakres) zbyt szybko (czas) i zbyt tanio (budżet).

Oryginał tego wpisu dostępny jest pod adresem O zarządzaniu projektami

Autor: Paweł Goleń