Zarządzanie projektami w organizacji

Zarządzanie projektami zawsze wiąże się ze skutecznym zrównoważeniem zakresu dopuszczalnych wysiłków oraz dostępnych środków w celu zakończenia projektu w określonym terminie. PMI tak naprawdę odnosi się do trzech wymienionych powyżej akcji, określanych zwykle jako potrójne ograniczenie. Chcielibyśmy aktualnie omówić rzeczywiste relacje oraz kompromisy pomiędzy tymi trzema elementami, a mianowicie zakresem projektu, kosztem i harmonogramem. Zastanowimy się także, w jaki sposób można efektywnie zarządzać relacjami pomiędzy tymi elementami, aby konsekwentnie realizować projekty, jakie spełnią większość celów klientów zgodnie z określonym harmonogramem oraz budżetem.

Dlaczego projekty kończą się niepowodzeniem?

Z mojego doświadczenia wynika, że jeśli projekt kończy się niepowodzeniem, to zwykle prawie zawsze oznacza to, że jeden lub kilka kluczowych elementów są niewłaściwie zarządzane. Bardzo często jest tak, że relacje pomiędzy tymi zmiennymi są w ogóle nierozpoznane lub słabo rozpoznane.

Z naszego doświadczenia wynika, że tylko 25% projektów kończy się całkowitym powodzeniem. Kolejne 25% kończy się kompletnym fiaskiem. Natomiast 50% projektów kończy się kiedyś, ale zwykle przekracza harmonogram lub budżet o 100%. Oczywiście wiemy o tym, że to nie projekty zawodzą, ale ludzie którzy nimi zarządzają. Jaki jest z tego wniosek? Ludzie nie potrafią zwykle efektywnie zarządzać projektami.

Jakie są kluczowe zmienne projektu?

Wspomnieliśmy już, że każdy projekt informatyczny ma trzy zasadnicze zmienne. Teraz chciałbym zdefiniować te zmienne oraz pokazać, w jaki sposób odnoszą się one do siebie w różnych fazach życia projektu.

Pierwszym elementem jest zakres prac. Zakres prac może zostać zdefiniowany jako zadania, jakie należy wykonać w ramach projektu, aby dostarczyć działający produkt albo usługę. W świecie IT produktem najczęściej jest system informatyczny. Zakres prac można oczywiście określić na kilka możliwych sposobów. Zwykle jest to lista zadań, które określają coś, co nazywa się cykl życia rozwoju oprogramowania i które muszą być koniecznie zrealizowane w danym projekcie informatycznym. Niektóre firmy określają zakres prac poprzez zestaw funkcji systemu, które muszą być koniecznie zawarte w systemie oraz zrealizowane i dostarczone do odbiorcy finalnego. Im więcej jest funkcji i im bardziej są one złożone, tym większy jest zakres samego projektu. Zakres projektu to nie wymagania końcowe w stosunku do produktu, ale coś, co jest związane bezpośrednio z dostarczeniem funkcji oraz ich złożonością.

Kolejnym elementem, jaki jest ważny dla każdego projektu informatycznego, jest koszt zasobów. Zasoby są przydzielane i konsumowane przez każdy projekt. Zasoby zazwyczaj generują koszty. Kosztami w projekcie najczęściej są pracownicy oraz rozwiązania, ale mogą nimi także być surowce, zakupione oprogramowanie, narzędzia, materiały biurowe, koszty podróży, czas spędzony przy komputerze. Koszty zwykle oblicza się w konkretnych pieniądzach lub roboczogodzinach.

Kolejnym elementem jest oczywiście harmonogram. Harmonogram to coś, co może być narzucone przez klienta albo przygotowane przez nas, aby zdefiniować czas trwania projektu. Zwykle szacuje się go w dniach, tygodniach, miesiącach lub latach.

Podstawowe relacje pomiędzy zakresem prac, kosztami oraz harmonogramem

W odniesieniu do menedżerów projektów bardzo często pada kilka pytań, które pozwalają zdefiniować warunki pracy, zasoby, zakres, koszty oraz harmonogram. Pomyśl o swojej roli jak o tym, jakbyś siedział w dużej sali i miał do dyspozycji trzy pokrętła. Bardzo często zadaję moim menedżerom kilka pytań, które pozwalają mi określić błyskawicznie stan projektu.

Pierwszym pytaniem jest to, co możemy zrobić z dostępnej listy zadań, wykorzystując jak najmniejszą ilość pracy i w jak najkrótszym czasie, dysponując bardzo ograniczonymi środkami. Drugie pytanie zazwyczaj brzmi, co możemy zrobić i jak dużo pracy wykonać, jeśli mamy jakiś krytyczny termin oraz jakie będą koszty wykonania krytycznych założeń. Ostatnie pytanie brzmi zwykle, czy jeśli mamy jakiś zestaw funkcji do wdrożenia, jaki jest nasz budżet i harmonogram dostaw działającego oprogramowania. Bardzo często pada też pytanie, czy da się tego wszystko stworzyć na akceptowanym poziomie ryzyka oraz akceptowalnym poziomie jakości.

A więc spokojnie możesz sobie wyobrazić, że siedzisz na takim zebraniu jak w wielkiej sali, z trzema głównymi pokrętłami o nazwach zakres, koszty i harmonogram oraz dwóch mniejszych o nazwach jakość i ryzyko. Jeśli weźmiemy się za ustawienie pokrętła reprezentującego zakres, powinniśmy także wziąć się za ustawianie pokręteł o nazwach koszty oraz harmonogram, a wtedy uzyskamy realny plan projektu i podniesiemy swoje szanse na sukces. Oczywiście wszystkie zmienne możemy ustawiać w określonych granicach, które także zostaną omówione.

Bardzo często dzieje się tak, że co najmniej jedna ze zmiennych może być wartością stałą lub trwale ograniczoną, aby móc zapewnić sobie podstawy do planowania projektu. Czasami także jest możliwe ograniczenie dwóch zmiennych, jeśli trzecia zmienna jest nieograniczona. Czasami jednak jest tak, że wszystkie trzy zmienne są ograniczone i wtedy nie można opracować żadnej drogi, aby osiągnąć coś sensownego. I właśnie wtedy zaczynają się Twoje problemy. Jeśli menedżer projektu nie może manipulować żadną zmienną, wtedy nie powinien w ogóle przyjmować projektu lub z niego po prostu odejść. Jeśli tego nie robi, powinien zastanowić się, czy nie przedstawić klientowi zerowej zasady wytwarzania oprogramowania, a więc „Jeśli nie musimy dostarczyć działającego systemu, to wtedy możemy olać wszystkie inne wymagania i ograniczenia.”.

Idealnym podejściem jest ograniczenie jednej zmiennej, na przykład zakresu i próba optymalizacji drugą zmienną, na przykład harmonogramem, aby znacząco wpłynąć na trzecią, na przykład na koszt. Spróbujcie odpowiedzieć sobie na następujące pytanie: jeśli chcę opracować ten produkt w określonym czasie, to to ile może może mnie kosztować dotrzymanie harmonogramu? Czasami istnieje też coś takiego, że należy ograniczyć wszystkie te trzy zmienne. Wtedy wystarczy zadać sobie pytanie: jeśli mam określony z góry budżet projektu, to ile może potrwać jego wykonanie?

W większości projektów jest jednak tak, że zarówno koszt jak i czas jest ograniczony. Wtedy można manipulować zakresem projektu. Dla większości organizacji produkujących oprogramowanie, koszt określa zwykle ilość zasobów, jakie można przeznaczyć na dany projekt i budżet szacuje się zawsze po wydaniu określonej wersji. Dlatego wtedy do negocjacji pozostaje jedna rzecz, a mianowicie zakres projektu, czyli liczba funkcji, jakie można dostarczyć skutecznie w danym terminie. Jedno z praw Brooksa brzmi: Im więcej rzeczy dodamy do projektu, tym bardziej opóźni się jego wykonanie.

Zastanówmy się teraz w jaki sposób wszystkie zmienne mogą ze sobą współpracować od początku projektu. Wspomniane powyżej prawo Brooksa odnosi się do każdego projektu nawet przed jego fizycznym wykonaniem. Czasami jest tak, że nie mamy ograniczenia co do kwoty kosztów, jakie mogą zostać użyte do realizacji danego projektu i mogą być przenoszone na dowolne dziedziny projektu w dowolnym czasie. A więc w tym przypadku wiemy, że możemy zmniejszyć ogólny harmonogram poprzez dołożenie do projektu określonych zasobów. Ale tutaj pojawia się pewna pułapka. Każdy dołożony zasób poprawia nasz harmonogram w coraz mniejszym stopniu, mimo że nadal zmniejsza czas kalendarzowy. I tutaj znowu ma zastosowanie kolejne prawo, a mianowicie prawo pomniejszonych przychodów, które mówi, że każdy dodatkowy przyrost w mniejszym stopniu przyczynia się do całości. Jednak w pewnym momencie dzieje się coś strasznego. A mianowicie każdy dodatkowy zasób lub środki nie przyczyniają się do zakończenia projektu w określonym harmonogramie. Kiedy dochodzimy do tego momentu?

Badania empiryczne w dziedzinie zarządzania projektami pokazały że optymalna ilość zasobów, którzy mogą być przeznaczeni do projektu, aby zmniejszyć jego czas kalendarzowy, wynosi zwykle pierwiastek kwadratowy z liczby osobo-miesięcy. Czyli jeśli jedna osoba będzie realizować projekt przez 10 lat, czyli 120 miesięcy, to dostarczenie do projektu 11 osób powinno go skrócić do 11 miesięcy. A więc każda większa liczba zasobów, jakie można przydzielić do projektu tak naprawdę poprawi tylko atmosferę, ale nie poprawi wcale wydajności zespołu. Poza tym czasami może zdarzyć się tak, że czas kalendarzowy wykonania projektu wzrośnie zamiast zmaleć.

Zbyt wiele zasobów może przedłużyć projekt w nieskończoność

W jaki sposób możesz się przekonać, że jest to prawdziwe? Po pierwsze każdy zespół ma zapotrzebowanie na efektowną komunikację wewnętrzną. Złożoność tego procesu oraz samych komunikatów może być bardzo duża, jeśli dodamy zbyt dużo osób do zespołu projektowego. Komunikacja wymaga także dodatkowego czasu i zasobów. Po drugie istnieje wiele zależności w przypadku zadań, jakie zaistnieją w obrębie danego zespołu. Przeważnie jest tak, że punkty wyjściowe z jednych zadań są punktami wejściowymi do innych zadań.  W pewnym punkcie już nie można podzielić pewnych zadań na mniejsze, aby umożliwić pracę nad nimi dwóm osobom. A więc czasami zdarza się tak, że za dużo osób w projekcie oznacza więcej bezczynności lub więcej off-topów w komunikacji, co może naprawdę rozbić i wydłużyć każdy projekt.

A więc zbyt wiele zasobów jest w rzeczywistości niebezpieczne dla projektu i wydłuży czas dostarczania działającego oprogramowania. Zapamiętajcie prawo malejących przychodów. W pewnym momencie każdy nowy zasób będzie wpływał ujemnie na projekt.

Czynniki wydajności

Każdy kierownik projektu musi zwykle w procesie planowania projektu określić zakres prac, wymagane zasoby oraz harmonogram prac, a następnie wytłumaczyć wszystko kierownictwu. Dużo tych czynników prawda? O wiele lepiej wprowadzić dodatkowy znacznik o nazwie czynnik produktywności lub czynnik wydajności. Co to jest czynnik wydajności? Załóżmy, że macie do przepracowania okres 10 osobo-miesięcy, a więc jak długo potrwa projekt w przeliczeniu na każdą osobę zatrudnioną w pełnym wymiarze czasu pracy? Uwierzcie mi, że zdecydowanie dłużej niż 10 miesięcy, gdyż żaden człowiek nie osiąga 100% produktywności.

Do tego dochodzi jeszcze zespół kilku innych czynników. Czas dziesięciu osobo-miesięcy nie uwzględnia na przykład urlopów, wakacji, zwolnień lekarskich, czy spotkań pracowników. Istnieje także wiele innych czynników, które prowadzą do obniżenia wydajności i zwiększenia liczby osobo-miesięcy.

Czynniki produktywności będą oczywiście różne w zależności od organizacji i poszczególnego pracownika. Wykonawcy i podwykonawcy są na ogół bardziej wydajni, ponieważ nie muszą się przejmować funkcjami administracyjnymi, w jakich muszą uczestniczyć pracownicy. Zwykle oblicza się współczynnik produktywności na poziomie 60%, co oznacza, że pracownik jest dostępny tylko przez trzy dni w tygodniu. Dlatego dziesięć osobni-dni może przerodzić się w siedemnaście, zaś dziesięć osobo-miesięcy może obrać kształt 17 miesięcy kalendarzowych.

O wiele lepszy współczynnik wydajności osiągniemy, jeśli wynajmiemy wykonawców specjalnie do wykonania określonych zadań. W tym przypadku współczynnik może się klasyfikować na poziomie 80%, ale można go podkręcić do 90%, jeśli da się poszczególnym osobom nadgodziny. Większość podwykonawców będzie zadowolona, ponieważ nie dość, że więcej zarobi, to jeszcze nie będzie musieć pracować po 60-70 godzin w tygodniu poprzedzającym dead-line.

Aby to dobrze prze-konwertować, należy podzielić po prostu liczbę spodziewanych osobo-jednostek przez współczynnik produktywności. Na przykład dla dziesięciu osobo-miesięcy wynosi to 16,67 lub jak wolicie 17 miesięcy. Proste, prawda?

Read it in english version: http://www.businessmantoday.us/project-manageme…the-organization/

Zapisz