Czynnik ludzki jako ryzyko w zarządzaniu projektami IT – Agile vs. PMBoK

0
1530

Ostatnie kilkanaście lat, to okres dynamicznego rozwoju przemysłu informatycznego. Każdego roku miliardy dolarów wydawane są na nowe technologie informatyczne i związane z nimi projekty. Mimo to, większość projektów (aż 65% projektów realizowanych w Stanach Zjednoczonych wg badań The Standish Group z 2006 roku) kończy się niepowodzeniem. Na niepowodzenie projektów w branży IT wpływa wiele czynników – jednym z nich jest czynnik ludzki. Poznanie i zrozumienie przyczyn niepowodzeń zespołów programistów w projektach IT, może pomóc liderom projektów, dyrektorom firm i innym osobom związanym z prowadzeniem projektów IT w wyeliminowaniu lub uniknięciu wciąż popełnianych tych samych błędów. Może również nauczyć zespoły jak wykorzystywać najrozmaitsze techniki prowadzenia projektów, które pozwalają osiągać sukcesy.

Tylko dwie rzeczy są nieskończone: wszechświat oraz ludzka głupota,
choć nie jestem pewien, co do tej pierwszej.

Albert Einstein (1879 – 1955)

Niniejszy artykuł stanowią fragmenty pracy dyplomowej Michała Leksińskiego, obronionej w ramach IV edycji Podyplomowych Studiów Zarządzania Projektami na Wydziale Informatyki i Zarządzania Politechniki Wrocławskiej.

Wstęp

Postęp technologiczny mający miejsce w ostatnich kilkudziesięciu latach spowodował wzrost nakładów pieniężnych na rozwój technologii informacyjnych i produkcji oprogramowania. Pomimo ogromnych zalet płynących z pracy z najnowszymi technologiami w przemyśle IT, nadal więcej niż połowa projektów kończy się niepowodzeniem, rozumianym jako przekroczenie dopuszczalnej wartości co najmniej jednego z czterech podstawowych parametrów projektu: czasu, budżetu, zakresu lub jakości. Poznanie przyczyn niepowodzeń zespołów programistów w projektach IT związanych z czynnikiem ludzkim, może pomóc liderom projektów, dyrektorom firm i innym osobom związanym z prowadzeniem projektów IT w wyeliminowaniu lub uniknięciu wciąż popełnianych tych samych błędów. Może również nauczyć zespoły jak wykorzystywać najrozmaitsze techniki prowadzenia projektów, które pozwalają osiągać sukcesy.

Historia lubi się powtarzać – popełniane błędy, wpływające na niepowodzenie projektów, jeżeli nie zostaną przeanalizowane i nie zostaną z nich wyciągnięte konstruktywne wnioski, będą narastać i ujawniać się w kolejnych realizowanych projektach. Wydawanie ogromnych sum pieniędzy na projekty IT nie jest równoznaczne z ich dobrym zainwestowaniem. Wg corocznych raportów przedstawianych przez The Standish Group na projekty IT kończące się niepowodzeniem, rok rocznie setki firm na całym świecie wydaje miliardy dolarów. Pieniądze te mogłyby być znacznie lepiej wydawane i inwestowane, jeżeli większą uwagę poświeciłoby się na analizę przyczyn niepowodzeń projektów informatycznych, tak, aby w przyszłości zdarzenia powodujące ogromne ryzyko w projektach były eliminowane tak wcześnie, jak to tylko możliwe.Istnieje wiele czynników, które są przyczynami niepowodzeń projektów wytwarzania oprogramowania. Jednym z tych czynników jest czynnik ludzki. Wg badań przeprowadzanych od lat przez Toma DeMarco respondenci, jako przyczynę niepowodzenia, najczęściej podawali politykę. Zwróćmy jednak uwagę, że ludzie mają skłonność do dość swobodnego posługiwania się tym terminem. Określa się nim takie niepowiązane ze sobą albo luźno powiązane sprawy, jak problemy komunikacji w pracy, problemy dotyczące doboru obsady, rozczarowanie szefem lub klientem, brak motywacji do pracy i duża fluktuacja kadr

Analiza czynnika ludzkiego i związanych z nim zdarzeń, maksymalizujących prawdopodobieństwo zaistnienia ryzyka w projekcie, dostarczy wartościowych informacji zarówno zespołom programistycznym, kierownikowi projektu jaki dyrektorom firm, w których realizuje się projekty. Informacje te, jeżeli zostaną odpowiednio wykorzystane, mogą zwiększyć szanse ukończenia projektów zgodnie z zaplanowanym zakresem, budżetem i w zaplanowanym czasie.

Raport „Chaos”

Dane dotyczące czynników sukcesów i niepowodzeń projektów w branży IT, po raz pierwszy zostały zebrane i opisane przez The Standish Group w raporcie zatytułowanym „Chaos” w 1995 roku odnoszącym się do stanu branży IT w Stanach Zjednoczonych. Pomimo, iż od tego czasu upłynęło prawie 15 lat, to „aktualność” tych danych co do specyfikacji niektórych zależności w dalszym ciągu jest pouczająca.

Informacje w raporcie zgromadzono na podstawie licznie przeprowadzonych ankiet, badań i wywiadów z menadżerami projektów. Badaniami objęto duże, średnie i małe firmy z najróżniejszych segmentów przemysłu (np. bankowości, ochrony, medycyny, ubezpieczeń itp.), w których realizowano projekty informatyczne.  Ogółem w badaniach w 1994 roku wzięło udział 365 menadżerów, a analizie poddano 8380 aplikacji.

Dla potrzeb raportu, projekty sklasyfikowano w trzech kategoriach:

  • projekty zakończone sukcesem – ukończone na czas, w założonym budżecie, spełniające wszystkie wymagania zdefiniowane na początku projektu;
  • projekty zakończone niepełnym sukcesem – ukończone w przekroczonym budżecie i czasie, niespełniające wszystkich zdefiniowanych na początku projektu wymagań;
  • projekty anulowane – nieukończone, zakończone w trakcie trwania projektu.

Celem, jaki przyświecał The Standish Group podczas przygotowywania raportu „Chaos” w 1995 roku, było znalezienie przyczyn niepowodzeń projektów. W badaniu pod uwagę brano opinie managerów projektów IT wg których, trzema najważniejszymi czynnikami sukcesu projektów są zaangażowanie klienta, wsparcie kierownictwa i jasno określone wymagania. Istnieją również inne czynniki sukcesu, ale te trzy znacząco wpływają na zwiększenie szans odniesienia sukcesu. Bez nich, szanse na niepowodzenie projektu wzrastają. W 1995 roku The Standish Group opublikowała czynniki sukcesu projektu:

  1. Zaangażowanie klienta 15.9%
  2. Wsparcie kierownictwa 13.9%
  3. Jasno określone wymagania 13.0%
  4. Właściwe planowanie 9.6%
  5. Realistyczne oczekiwania 8.2%
  6. Mniejsze odstępy pomiędzy kamieniami milowymi 7.7%
  7. Kompetencje pracowników 7.2%
  8. Odpowiedzialność 5.3%
  9. Jasno postawione cele i wymagania 2.9%
  10. Ciężko pracujący, skupieni pracownicy 2.4%

Ponad 10 lat później, w 2006 roku „top ten” czynników stanowiących zdaniem analityków The Standish Group kryterium sukcesu projektu przedstawiało się następująco:

  1. Zaangażowanie klienta
  2. Wsparcie kierownictwa
  3. Jasny cel biznesowy projektu
  4. Zoptymalizowany zakres projektu
  5. Metodyka Agile
  6. Doświadczony manager projektu
  7. Zarządzanie budżetem projektu
  8. Wykształcone zasoby ludzkie
  9. Formalna metodyka prowadzenia projektu
  10. Standardowe narzędzia programistyczne i infrastruktura

Przedmiotem badań The Standish Group były również przyczyny niepełnych sukcesów projektów:

  1. Brak informacji wejściowych od klienta
  2. Niekompletne wymagania i specyfikacje projektu
  3. Zmiana wymagań i specyfikacji projektu
  4. Brak wsparcia ze strony kierownictwa
  5. Brak kompetencji w danej dziedzinie
  6. Brak zasobów ludzkich
  7. Nierealne oczekiwania klienta
  8. Niejasne cele
  9. Nierealne ramy czasowe projektu
  10. Nowe technologie

Czynnik ludzki został sklasyfikowany „po środku” listy czynników wpływających na niepełny sukces projektu – tzn. projekt został ukończony w przekroczonym budżecie, przekroczonym estymowanym czasie i nie spełnia wszystkich wymagań klienta wyspecyfikowanych na początku projektu. Brak kompetencji w danej dziedzinie sklasyfikowano na pozycji numer 5, a brak zasobów ludzkich na miejscu 6.

Czynnik ludzki odgrywał znaczącą rolę w projektach, które zostały anulowane lub które nie osiągnęły nawet fazy realizacji produktu technicznego. Brak zasobów ludzkich sklasyfikowany został na miejscu 3, a „analfabetyzm” technologiczny na pozycji 10:

  1. Niekompletne wymagania
  2. Brak zaangażowania klienta
  3. Brak zasobów ludzkich
  4. Nierealne oczekiwania klienta
  5. Brak wsparcia ze strony kierownictwa
  6. Zmiana wymagań i specyfikacji projektu
  7. Brak planowania w projekcie
  8. „Już tego nie będziemy potrzebować”
  9. Brak zarządzania częścią IT projektu
  10. „Analfabetyzm” technologiczny

Przeprowadzone w 1994 roku badania wskazują na bezpośredni związek pomiędzy projektami zakończonymi niepowodzeniami, a czynnikiem ludzkim. Wykazują także znaczną przewagę procentową projektów zakończonych niepełnych sukcesem i anulowanych nad projektami zakończonymi pełnym sukcesem. Im większa skala niepowodzenia projektu, tym większy udział w tym niepowodzeniu czynnika ludzkiego. Większość projektów związanych z wytwarzaniem oprogramowania kończy się niepowodzeniem, ponieważ popełniane są błędy na poziomie zespołów projektowych.

Korzystamy z komputerów i innych nowoczesnych narzędzi do opracowywania naszych produktów lub do prowadzenia naszych interesów. Ponieważ robimy to w zespołach, w grupach zadaniowych lub innych zwartych grupach roboczych, zajmujemy się głównie komunikacją między ludźmi. Nasze sukcesy zawdzięczamy skutecznym interakcjom zachodzącym między wszystkimi uczestnikami tych prac, a niepowodzenia – kiepskim interakcjom… Interakcje międzyludzkie są złożone, a ich skutki nigdy nie są wyraźnie określone i jasne. Odgrywają jednak większą rolę niż jakikolwiek inny aspekt pracy. Dlatego też w projektach IT, czynnik ludzki nie powinien być ignorowany. W przeciwnym wypadku, zaistniałe problemy będą się powtarzać i narastać wraz z kolejnymi projektami, zwiększając prawdopodobieństwo ich niepowodzenia (Tom DeMarco).

The Silence Fails – Raport „Cisza”

Raport zatytułowany Silence Fails, będący podsumowaniem badań przeprowadzonych przez firmę szkoleniową VirtalSmarts i firmę The Concours Group, prezentuje pięć krytycznych obszarów nazwanych „decydującymi rozmowami” czy też ”krytycznymi obszarami”, które mają ogromny wpływ na powodzenie i niepowodzenie przedsięwzięć biznesowych.

W badaniach wzięło udział ponad 1000 menedżerów projektów i dyrektorów z 40 dużych firm z najróżniejszych gałęzi przemysłu w Stanach Zjednoczonych i na świecie – m.in. przemysłu farmaceutycznego, budowlanego, lotniczego, korporacji finansowych, agencji rządowych, firm IT itd. Analizami objęto ponad 2200 projektów, o budżetach zaczynających się od dziesiątek tysięcy (np. projekty IT) do miliardów dolarów (projekty restrukturyzacji korporacji).

Pięć krytycznych obszarów zidentyfikowanych i opisanych w raporcie należy do najbardziej rozpowszechnionych i najdroższych przeszkód do osiągnięcia sukcesu, jakie menedżerowie projektów napotykają w projektach. Do tych obszarów należą:

  • wstępne planowanie projektu – zbyt szczegółowe planowanie harmonogramu, z datami i zasobami, które nie przystają do rzeczywistości, „skazując” projekt na niepowodzenie;
  • brak zaangażowania sponsora projektu – sponsorzy projektów nie zapewniają odpowiedniego wsparcia grupie realizującej projekt, poświęcają za mało czasu i energii, aby doprowadzić projekt do końca;
  • ignorowanie priorytetów – ignorowanie priorytetów zadań w projektach przez członków projektu, do którego zostali przypisani;
  • ukrywanie faktycznego stanu projektu – lider projektu i członkowie zespołu nie sygnalizują występujących w projekcie problemów – czekają, aż ktoś inny to powie lub zapyta;
  • porażka zespołu – członkowie zespołu nie posiadają odpowiedniej wiedzy, która wymagana jest do realizacji projektu – nie chcą lub nie są w stanie zaangażować się w efektywną realizację projektu.

Przeprowadzone badania wykazały, że jeżeli jedna z ww. sytuacji nie zostanie odpowiednio przeanalizowana i nie zostaną wyciągnięte z niej odpowiednie wnioski w stosunku do prowadzonego projektu, to prawdopodobieństwo zakończenia tego projektu porażką (zdefiniowaną jako przekroczenie zaplanowanego budżetu i czasu oraz niespełnienie wszystkich wymagań klienta co do jakości i funkcjonalności wytworzonego produktu) wzrasta do 85%. W takiej sytuacji nieuchronnie spadają także morale zespołu.
Według większości ankietowanych, jeśli rozmowy dotyczące „krytycznych obszarów” się powiodą, to prawdopodobieństwo porażki spada o 50-70%.

Przeprowadzone badania wykazały, że członkowie zespołów często nie posiadają odpowiedniej wiedzy, która wymagana jest do realizacji projektu – nie chcą lub nie są w stanie zaangażować się w efektywną realizację projektu.

Cechą wspólną większości liderów projektu jest posiadanie znacznie większej odpowiedzialności, niż władzy w prowadzonym projekcie. Stoją na czele zespołów składających się ze specjalistów należących do różnych grup kompetencji, posiadających swoich przełożonych – członkowie zespołu bezpośrednio nie podlegają liderowi projektu, co jest przyczyną wielu nieporozumień zwiększających prawdopodobieństwo niepowodzenia projektu. Liderzy mają „związane” ręce – członkowie zespołu nie pojawiają się spotkaniach projektowych, nie dotrzymują terminów, nie posiadają kompetencji, dlatego też nie stawiają sobie ambitnych celów     i wyzwań. Brak możliwości doboru ludzi do zespołu, zastąpienia nieefektywnych pracowników kompetentnymi osobami powoduje bezsilność lidera projektu – nie posiada władzy, a zespół zamiast pracować nad celami projektu, pracuje „wokół” tych celów.

Przykładowo, osoba przypisana do projektu może być postrzegana przez pozostałych członków zespołu jako osoba niekompetentna. Zamiast postawić sprawę jasno i otwarcie, lider projektu angażuje kolejne zasoby w wykonywanie zadań związanych z projektem. Nie tylko wzrastają koszty projektu, ale tworzy się środowisko, w którym członkowie zespołu projektowego zaczynają niezdrowo rywalizować między sobą. Drugim źródłem problemów zespołów projektowych jest sytuacja, w której lider projektu jest zmuszony do negocjowania z menedżerami grup kompetencji zasobów ludzkich dla swojego projektu. Menedżerowie kompetencji często mają swoje, dużo wyższe priorytety w innych projektach. Ponownie, jeżeli lider projektu nie może efektywnie sprostać „krytycznym obszarom” z powodu braku dostępnych zasobów ludzkich, sukces projektu jest poważnie zagrożony.

W przypadku, kiedy liderzy projektu mają problemy z efektywnym poradzeniem sobie z kłopotami wewnątrz zespołów projektowych, to 4 na 5 projektów kończy się niepełnym sukcesem (przekraczając budżet i zaplanowany czas realizacji, o gorszej jakości i zmniejszonej funkcjonalności).

Przytoczone badania pokazują, że wciąż niewiele firm (niezależnie od gałęzi przemysłu) dostrzega znaczenie czynnika ludzkiego w niepowodzeniach projektów informatycznych. Generalnie metody zarządzania można podzielić na trzy grupy – te skupione na procesach, technologiach i ludziach. Niewiele jest natomiast metody, które uwzględniałyby wszystkie te trzy czynniki na równi. Zwłaszcza czynnik ludzki jest mocno niedoceniany, zwykle kosztem nadmiernego przywiązania do procedur. Tymczasem w przypadku „pracowników wiedzy”, a takimi niewątpliwie są programiści, ogromne znaczenie odgrywa ich wiedza, intuicja, czy możliwość dostosowywania się do zmieniających się warunków.

Przeanalizowane wwyniki badań, przeprowadzonych przez The Standish Group oraz The Concours Group, są odpowiedzią na pytanie: „W jaki sposób doprowadzić zespół projektowy do niepowodzenia?”.  Pierwszym krokiem są nieodpowiednio (jeżeli chodzi o ilość) dobrane zasoby ludzkie, mające realizować zadania projektowe. Niech te zespoły nie posiadają specjalistycznej wiedzy na odpowiednim poziomie, wymaganym do realizacji powierzonych im zadań. Niech członkowie zespołu nie potrafią komunikować się i współpracować ze sobą. Jeżeli taki zespół już istnieje, należy umieścić go w środowisku, w którym warunki do pracy są nieodpowiednie (za mało miejsca przypadającego na jednego członka zespołu, hałas itd.). Jest to łatwy i szybki sposób na doprowadzenie projektu, a przede wszystkim zespołu do niepowodzenia.

Budowanie zespołu projektowego

Sukces projektu zależy między innymi od zgranych, lojalnych wobec siebie i współpracujących ze sobą członków zespołu projektowego. Wyhodowanie zgranego zespołu to wręcz czysta loteria. Nikomu się to nie udaje raz za razem. Nikt też nie może sprawić, żeby taki zespół powstał, a już zwłaszcza wtedy, kiedy jest najbardziej potrzebny. Zdarza się, że skład zespołu jest nieodpowiedni, a zdarza się też, że są w nim ludzie, którzy nie chcą być jego częścią; są samotnikami i zawsze nimi będą.

Zgrany zespół to grupa powiązanych ze sobą i wspólnie pracujących ludzi, zdolna wytworzyć produkt, który będzie spełniał zdefiniowane na początku projektu założenia. Wyniki pracy takiego zespołu są większe niż wyniki uzyskiwane przez tych samych ludzi, ale pracujących w niescementowanej grupie.  W momencie, kiedy pracownicy zaczynają tworzyć zgraną i rozumiejącą się drużynę, prawdopodobieństwo odniesienia sukcesu w projekcie wzrasta. W takiej sytuacji zadania menedżera projektu sprowadzają się jedynie do usuwania wszelkich przeszkód, które pojawiają się na drodze zespołu do odniesienia sukcesu.
Aby zespół projektowy odnosił sukcesy, jego członkowie muszą posiadać odpowiednie kompetencje. W tym celu kierownik projektu (znający wymagania i umiejętności potrzebne do realizacji zadań projektowych) powinien posiadać prawo dobierania jego członków. Członkowie zespołu powinni cechować się odpowiednimi kompetencjami zawodowymi, wymaganymi do realizacji powierzonych im zadań projektowych, ale również i predyspozycjami psychologicznymi. W związku z tym w procesie zatrudniania musimy kłaść nacisk na co najmniej kilka cech komunikacji międzyludzkiej.  Według DeMarco i Listera, dobrym sposobem oceny przydatności kandydatów na pracownika są tzw. przesłuchania. Kandydat przed rozmową proszony jest o przygotowanie kilkuminutowej prezentacji na wybrany temat, dotyczący aspektu wykonywanej przez niego pracy. W rozmowie kwalifikacyjnej biorą udział osoby, które potencjalnie będą z tym kandydatem współpracować. Po zakończeniu przesłuchania i po wyjściu kandydata odbywa się narada osób biorących udział w rozmowie. Każdy przedstawia swoją opinię na temat tego, czy kandydat nadaje się do danej pracy i do zespołu.  Ostateczna decyzja o zatrudnieniu należy jednak do kierownika projektu, ale informacje zwrotne uzyskane od jego przyszłych współpracowników są cennymi wskazówkami, które powinny zostać uwzględnione w procesie decyzyjnym. Jeżeli uczestnicy w większości zaakceptują kandydata, proces jego wdrożenia w obowiązki pracownicze przebiegnie sprawnie i bezkonfliktowo.

Cele firmy mogą wydawać się członkom zespołu arbitralne. Do zadań kierownika należy uświadomienie zespołowi jak projekt, który ma być przez niego realizowany, wpasowuje się w strategię biznesową firmy. Zrozumienie celu projektu i umiejscowienie go w celach firmy daje pracownikom poczucie własności, stają się bardziej wydajni i podążają w tym samym kierunku. Zespół jest potrzebny nie po to, żeby osiągnąć cel zbiorowy, ale po to, żeby dostosować do niego cele indywidualne.

Istotny wpływ na powodzenie projektu ma fluktuacja kadr. Jeżeli zespół posiada odpowiednią liczbę wykwalifikowanych pracowników, którzy bez problemów porozumiewają się i współpracują ze sobą, zmiana tej stabilnej struktury może negatywnie wpłynąć na realizowane zadania. Po pierwsze, zatrudnienie nowych osób wiąże się ze zamianami budżetu i harmonogramu projektu. Następnie nowa osoba musi zostać odpowiednio przeszkolona przez i tak już zajętych „starych” członków zespołu. Wszystko to wpływa destrukcyjnie na produktywność w projekcie, co z kolei zwiększa budżet, czas realizacji projektu, może pogorszyć jakoś produktu poprzez większą liczbę błędów itd.

DeMaro i Lister zaobserwowali kilka charakterystycznych cech świadczących    o zżyciu się zespołu. Takie zespoły charakteryzują się poczuciem tożsamości, wyjątkowości i wspólnej własności. Najważniejszą cechą jest mała fluktuacja kadr podczas prac nad określonymi zadaniami i w trakcie wykonywania dobrze zdefiniowanych zadań. Członkowie zespołu nigdzie nie odchodzą przed zakończeniem danego przedsięwzięcia  – sprawy związane z wynagrodzeniem, prestiżem, możliwościami awansu odchodzą na dalszy plan, stają się mało ważne.

Metody utrudniające powstawanie zespołów i niszczące więzi społeczne w realizacji projektów DeMarco i Lister określili mianem „zespołobójstwa”. Do działań składających się na tę strategię należą:

  • defensywne zarządzanie – charakteryzujące się nadmiernym brakiem zaufania do pracowników. Jeżeli pracownicy zauważą, że im się nie ufa i odczują brak samodzielności, nie będą skorzy do utworzenia zgranego zespołu;
  • biurokracja – nadmiar pracy papierkowej wybija zespół z rytmu powodując, że praca będzie odbywać się wokół rozwiązania, a nie nad rozwiązaniem problemu;
  • fizyczne rozdzielenie członków zespołu – ludzie mający tworzyć zgrany i zwarty zespół, są rozrzuceni po różnych budynkach, lokacjach itp. Z wykorzystaniem poczty elektronicznej i odpowiednich narzędzi kooperacyjnych interakcje robocze nie ucierpią, ucierpią natomiast interakcje nieformalne, wzmacniające więzi międzyludzkie;
  • rozdrabnianie zadań pracowników – pracownicy pracują w kilku projektach jednocześnie, co chwile zmieniając wykonywane zadanie w jednym na inne zadanie w drugim projekcie – wpływa to na obniżenie wydajności i przeszkadza w kształtowaniu się zespołów;
  • obniżanie jakości produktu – dostarczenie produktu we wcześniejszym terminie niż zaplanowany na początku projektu jest jednoznaczne z obniżeniem jego jakości. Użytkownik końcowy akceptuje kompromis (gorsza jakość za szybciej  i taniej ukończony projekt). Jest to niezdrowa sytuacja dla zespołu projektowego, który musi wykonać produkt o wyraźnie niższej jakości niż ta, którą są w stanie osiągnąć;
  • nierealne terminy – napięte harmonogramy uniemożliwiają odniesienie sukcesu, co zniechęca członków zespołu do wysiłku i zaangażowania w realizację zadań projektowych;
  • kontrolna stopnia zżycia zespołów – źródłem satysfakcji pracowników jest wspólna praca w określonym gronie kolegów nad kolejnymi problemami w najróżniejszych projektach. Jednak jak na ironię, duch zespołu, dzięki któremu praca się powiodła, bywa postrzegany przez kierownictwo jak polityczne zagrożenie. Często w takich wypadkach po zakończeniu projektu zespół zostaje rozproszony. Perspektywa podziału ma tak demoralizujący wpływ, że dezintegracja zespołu może nastąpić jeszcze przed ukończeniem projektu.

W wielu firmach niszczenie zespołów nie jest procesem intencjonalnym – tak po prostu te firmy funkcjonują.

Komunikacja i współpraca

Komunikacja, zarówno pomiędzy kierownikiem a resztą zespołu, jak i samymi członkami zespołu jest jednym z najistotniejszych elementów w budowie zżytego zespołu, mającego realizować projekty zgodnie z założonym budżetem, harmonogramem i spełniające stawiane wymagania.

Menedżer projektu, podczas procesu tworzenia zespołu, powinien stworzyć środowisko, w którym członkowie będą mogli swobodnie wymieniać się swoją wiedzą   i doświadczeniami, co zwiększy kompetencje i atrakcyjność zespołu projektowego. Istotny jest charakter tej komunikacji i jej intensywność.  Idealna sytuacja to taka, w które menedżer projektu nie ma tajemnic przed współpracownikami – wszyscy w zespole są poinformowani o wszystkim i biorą udział w podejmowaniu decyzji, które dotyczą zespołu. Znany jest plan aktualnie wykonywanych prac, priorytety zadań, rodzaje ryzyka, problemy itd. Sytuacje taką można osiągnąć poprzez organizację cyklicznych spotkań (np. raz w tygodniu), na których będą poruszane powyżej przytoczone tematy.

Szczególną uwagę należy poświęcić komunikacji w projektach, które realizowane są przez ludzi pracujących ze sobą po raz pierwszy w grupie. Sprawą zasadniczą jest poufność komunikacji wewnętrznej. Omawiane sprawy nie powinny wydostawać się na zewnątrz. Zachęci to do szczerej, otwartej wymiany informacji.
Środowisko, w którym każdy członek zespołu może swobodnie przekazywać swoje spostrzeżenia i wiedzę współpracownikom, jest pierwszym krokiem do zwiększenia kompetencji zespołu projektowego.

Obecnie, komunikacja w projektach sprowadza się do wymiany poczty elektronicznej i informacji z wykorzystaniem narzędzi kooperacyjnych, co w pełni zaspokaja interakcje robocze. Ucierpią natomiast interakcje międzyludzkie, które są istotne dla podtrzymania zdrowej atmosfery w zespole projektowym. Dlatego od czasu do czasu powinny być organizowane imprezy integracyjne, których celem będzie wzmocnienie więzi między współpracownikami. Brak komunikacji, interakcji międzyludzkich może niekorzystnie wpłynąć na realizację projektu.

Motywacja

Zaangażowanie członków zespołu w realizację zadań projektowych jest istotnym elementem, wpływającą na sukces projektu. Dlatego kierownik projektu powinien zadbać o jego zwiększenie. W idealnej sytuacji członkowie zespołu przysięgają lojalność i poświęcenie wszystkiego dla projektu. Takie całkowite poświęcenie jest możliwe przez 3 miesiące do 6 miesięcy, ale nie, jeśli projekt trwa 36 miesięcy.

Jedną z umiejętności jaką powinien cechować się kierownik projektu jest charyzma. To dzięki niej może wzbudzić w pracownikach uczucie lojalności i zaangażowania w projekt.  Bywają kierownicy, którzy umieją stworzyć taką atmosferę, że reszta zespołu, nie bacząc na związane z projektem ryzyko, pójdzie za nimi na koniec świata.

DeMarco i Lister w swojej książce „Czynnik ludzki. Skuteczne przedsięwzięcia   i wydajne zespoły” napisali: Nic bardziej nie zniechęca człowieka do pracy niż świadomość, że motywacja do działania jest niedostateczna i wymaga „uzupełniania” motywacją szefa… Rzadko kiedy trzeba stosować drakońskie środki, żeby zmusić ludzi do pracy; większość z nich lubi pracować.

Czynników motywujących ludzi do pracy jest wiele – odpowiednie wynagrodzenie, premie i nagrody, szkolenia, możliwości awansu i rozwoju osobistego, praca z najnowocześniejszymi technologiami itd. Kierownik projektu powinien zadbać, aby firma dawała członkom zespołu możliwości doskonalenia i rozwoju zawodowego, nagradzała w postaci atrakcyjnych szkoleń, bonusów czy podwyżek. Takie ruchy zapewnią, że pracownicy będą skupieni na realizacji zadań projektowych i będą wiązali swoją przyszłość z daną firmą.

Jeżeli chodzi o motywowanie, to do każdego pracownika powinno podejść się indywidualnie – np. jednemu wystarczą pochwały czy nagroda pieniężna, a drugi będzie tylko i wyłącznie zadowolony ze znacznej podwyżki. Motywacja musi dodawać sił członkom zespołu przez cały okres trwania projektu, wyczerpującej pracy oraz licznych problemów technicznych.

Obok czynników motywujących do pracy można znaleźć czynniki demotywujące. Jednym z nich są nadgodziny, których na ogół nie sposób uniknąć w większości projektów. Kierownik projektu zazwyczaj nie widzi innego sposobu, by dotrzymać wyśrubowanego terminu.  Zespół składający się z młodych ludzi, entuzjastów wyzwań i nowych technologii jest skory do poświęceń – pracuje w nadgodzinach. Odpowiednie zarządzanie nadgodzinami, ich przydzielanie oraz rejestrowanie pozwoli na uświadomienie członkom zespołu, że jest to praca płatna, ale   i pozwoli na ocenę wydajności zespołu i ocenę prawdopodobieństwa dotrzymania założonego terminu. Poniższy wykres przedstawia wydajność netto w zależności od liczby godzin pracy wg E. Yourdon’a:

Znaczny wzrost wydajności pracy może nastąpić w ciągu pierwszych 20 nadgodzin. Jest to związane z adrenaliną, koncentrowaniem się na nowym projekcie, możliwościami nabycia nowej wiedzy i doświadczeń itd. Liczba nadgodzin nie może rosnąć nieskończenie – następuje taki moment, w którym wydajność zaczyna maleć, zaczynają pojawiać się błędy w projekcie. Nikt nie jest w stanie pracować po 18 godzin dziennie. Zmęczenie daje o sobie znać – członkowie zespołu robią się nerwowi, pojawiają się problemy w komunikacji zespołowej, spada wydajność. Popełnione błędy trzeba eliminować, co wiąże się z przerabianiem tego, co już zostało zrobione. Liczba poprawek i przeróbek zaczyna przewyższać ilość nowo opracowanego oprogramowania. Wszystko to wpływa negatywnie na postęp prac projektowych. W takiej sytuacji kierownik powinien zachęcać projektanta do 60 godzin pracy tygodniowo. W przedziale od 60 do 80 godzin tygodniowo kierownik powinien pozwolić projektantowi na ustalenie własnego limitu. Kogoś, kto pracuje więcej niż 80-90 godzin tygodniowo, kierownik powinien stanowczo odesłać do domu na odpoczynek.

Istotnym elementem pracy kierownika projektu musi być umiejętne zarządzanie nadgodzinami, odpowiednie ich przydzielanie i rejestrowanie. Członkowie zespołu powinni mieć świadomość, że praca w nadgodzinach nie jest pracą dla idei i że otrzymają za nią odpowiednie wynagrodzenie.

Czynnik ludzki w metodyce Agile

Wobec wszystkich produktów wytwarzanych w dzisiejszych czasach stawia się najrozmaitsze wymagania m.in. potrzeby klienta, zysk, szybkość i koszty wytwarzania, ciągłe zmiany, wysoka jakość, wykorzystanie najnowszych technologii informatycznych itd. Spełnienie tych wymagań jest równoznaczne z posiadaniem źródła wysokich kompetencji w różnych dziedzinach wiedzy i nauki. Te często wzajemnie trudne do spełnienia uwarunkowania i żądania nałożone równocześnie na tworzenie produktu – szybkość i jakość, bogata funkcjonalność i niski koszt, niepewność i przewidywalność, mobilność i stabilność – rodzą potrzebę posiadania kierowników projektów i praktyk zarządczych ukierunkowanych na dostarczanie wartości.

Większość metodyk prowadzenia projektów dostarcza firmom, menedżerom, kierownikom projektów obszerne zasady opisujące obligatoryjne reguły postępowania w większości, jak nie wszystkich możliwych sytuacjach, które mogą mieć miejsce w realizowanym projekcie. Metodyka Agile oferuje zbiór podstawowych zasad, obejmujący minimum czynności, które osoba, odpowiedzialna za prowadzenie projektu, może wykorzystać w każdej sytuacji, wypracowując w ten sposób właściwą dla danego projektu i środowiska metodę postępowania w danej sytuacji. Zespoły projektowe, które postępują wg obszernych zasad, zależą od osoby, która opracowała lub dopiero opracuje procesy i praktyki dla każdej sytuacji w realizowanym projekcie. Strategia taka jest „krótkowzroczna”. W przypadku zespołów postępujących wg zasad Agile, ich praca zależy od indywidualności ich członków w określaniu sposobów rozwiązywania problemów. Tylko dogłębnie przemyślane zasady mogą być jedynym rozwiązaniem wobec zarządzania złożonymi projektami wytwarzania oprogramowania.

Metodyka Agile jest zbiorem wartości, zasad i praktyk, które ułatwiają zespołom projektowym podejmowanie nowych wyzwań w postaci ambitnych i innowacyjnych projektów. Jest adaptacyjnym zarządzaniem projektem polegającym na adaptacyjnym wytwarzaniu produktu, spełniającego wymagania klienta. Stosowana jest tam, gdzie projekty polegają na wytworzeniu elastycznie adaptowalnych produktów przez pracujące z wigorem zespoły projektowe, zdolne do szybkiej adaptacji do zachodzących w środowisku projektowym zmian. Agile charakteryzują następujące cele biznesowe:

  • ciągła innowacja;
  • adaptacyjne produkty;
  • skrócone harmonogramy procesu wytwarzania;
  • adaptacyjność ludzi i procesów;
  • rzetelne wyniki.

Wytwarzanie nowych produktów i usług zaawansowanych technologicznie wymaga od zespołów realizujących związane z nimi projekty ciągłej innowacji, wspomaganej przez kierownictwo firmy. Innowacja steruje i napędza proces realizacji i dążenia do dostarczania klientowi produktów cząstkowych, spełniających jego wymagania. Innowacyjne idee nie powstają w sztywnych, autorytarnych środowiskach, lecz w kulturze adaptacyjnej opartej na zasadach samoorganizacji i samodyscypliny.

Zespół projektowy realizujący projekt, kierownik projektu czy firma, choćby niewiadomo jak byli przewidujący, zawsze w przyszłości zostaną w jakiś sposób zaskoczeni. Dla niektórych branż zmiana wymagań czy wykorzystywanych standardów ma miejsce bardzo często. Z kolei w innych, zmiany są bardzo rzadkie. Metodyka Agile definiuje dla produktu wbudowaną w niego zdolność adaptacyjną, która jednocześnie staje się krytycznym kryterium dla procesu wytwórczego. Liczy się to, czy zespół projektowy realizujący projekt, jest w stanie dostarczać klientowi produkty cząstkowe, spełniające teraźniejsze jego wymagania, a jednocześnie posiadające możliwość dalszego rozwoju i zdolność adaptacji do przyszłych, często nowych wymagań. Agile promuje ciągłe dążenie grupy projektowej realizującej projekt adaptacyjny do osiągnięcia doskonałości technicznej, czego wynikiem będą niskie koszty ewentualnych zmian.

Jednym z celów biznesowych każdej firmy jest redukowanie harmonogramów projektu tak, aby w odpowiednim momencie produkt pojawił się na docelowym rynku sprzedaży i uzyskał jak największą stopę zwrotu z zrealizowanej inwestycji. Iteracyjna   i oparta na elementach funkcjonalności natura metody [Agile]  przyczynia się do redukowania harmonogramów wytwórczych na trzy sposoby: przez koncentrację wysiłków, usuwanie oporów i rozwijanie umiejętności.   Ciągłe monitorowanie funkcjonalności produktów cząstkowych i odpowiednie nadawanie priorytetów realizacji poszczególnym zadaniom, w krótkich, iteracyjnych odcinkach czasu zmuszają zespołu do przemyślenia poszczególnych funkcjonalności produktu oraz zakresu ich implementacji. Pozwala to na wyeliminowanie mało istotnych elementów dla klienta, co z kolei wpływa na skrócenie czasu realizacji produktów cząstkowych i nakładu pracy. Jedną z domen Agile jest usuwanie oporów, upraszczanie skomplikowanych procesów np. zastąpienie wytwarzania ogromnej ilości niepotrzebnej nikomu dokumentacji, cyklicznymi spotkaniami projektowymi członków zespołu. Trzecim, bardzo istotnym elementem metodyki jest skupianie się na procesie rekrutacyjnym – selekcji i rozwoju osób o umiejętnościach odpowiednich dla realizowanego projektu.

Posiadanie adaptowalnych produktów jest możliwe w momencie, kiedy zespoły projektowe je wytwarzające posiadają cechy grupy adaptowalnej. Do tych cech należy postrzeganie częstych zmian nie jako przeszkody, ale jako integralną część wysiłków, jakie należy podejmować każdego dnia w celu realizacji powierzonego zadania projektowego z sukcesem. Agile zachęca członków zespołu projektowego do ciągłego uczenia się, rozwijania i adaptacji, co pozwala szybko reagować na zmiany produktu i zamiany biznesu.
Sukcesem metodyki jest dostarczanie produktów klientom, w których uwzględniono nałożone ograniczenia na czas realizacji projektu i poniesione w związku z tym projektem koszty. Działania takie wspierają wzrost zysków oraz wpływają pozytywnie na budowanie wizerunku firmy.

Podstawowe wartości obrazujące zasady metodyki Agile, jej twórcy zawarli w Manifeście adaptacyjnego tworzenia oprogramowania (Manifesto for Agile Software Development).

Odkrywamy lepsze sposoby na tworzenie oprogramowania poprzez robienie tego i pomaganie w tym innym. Poprzez tę pracę osiągnęliśmy korzyści:

  • Ludzie i współpraca ponad proces i narzędzia;
  • Działające oprogramowanie ponad wyczerpującą dokumentacją;
  • Współpraca z klientem ponad negocjacją kontraktu;
  • Reagowanie na zmiany ponad trzymaniem się planu.

Czyli, choć elementy po prawej mają swoją wartość, cenimy bardziej elementy po lewej stronie.

Procesy, narzędzia, dokumentacja, kontrakty i plany są istotnymi elementami wpływającymi na powodzenie realizowanego projektu. Mimo tego, elementy wymienione powyżej po lewej stronie są elementami bardziej krytycznymi. Brak utalentowanych, wykształconych i doświadczonych pracowników, działających produktów cząstkowych, dobrych relacji z klientami oraz odpowiedniej reakcji na zachodzące zmiany, wpływa destruktywnie na szanse dostarczenia produktu w zaplanowanym czasie, budżecie, zgodnego z zakresem i spełniającego zdefiniowane na początku normy jakości.

Nowe, często innowacyjne produkty, są wynikiem prac wykształconych, posiadających wiedzę ekspercką i doświadczenie, członków zespołów projektowych. Liczne procesy i narzędzia mogą wspierać wytwarzanie produktu, niejednokrotnie je upraszczać i skracać, ale są czynności, których nie można wykonać posiadając nawet najlepsze dostępne procesy i narzędzia (np. podejmując krytyczną decyzję trzeba się opierać tylko i wyłącznie na dogłębnej wiedzy członków zespołów). Bez odpowiednich ludzi nikt nie jest w stanie osiągnąć zadowalających kierownictwo firmy wyników. Ruch Agile wspomaga ludzi i ich wzajemne interakcje przez przywiązywanie wagi do koncepcji samoorganizacji samodyscypliny, egalitaryzmu, szacunki dla jednostki i jej kompetencji. Agile oznacza ruch społeczny kierowany przez pragnienie tworzenia określonego środowiska pracy i wiarę, że „adaptacyjne” środowisko jest istotne, aby dostarczyć klientom innowacyjne produkty.

Nawet bardzo szczegółowa dokumentacja wytworzonego produktu nie zadowoli klienta, jeżeli produkt nie będzie spełniał zdefiniowanych na początku projektu wymagań. Agile kładzie nacisk na adaptacyjne wytwarzanie produktów, polegające na dostarczaniu klientowi produktów cząstkowych – kolejnych wersji rzeczywistego produktu. Nie oznacza to jednak, że dokumentacja jest zbędna – wspiera, poprawia komunikację i współpracę.

Współpraca z klientem oznacza, że wszyscy „gracze” w projekcie – sponsor, klient, użytkownicy i programiści stanowią jeden, zgrany zespół, każdy zna swoją rolę, obowiązki i odpowiedzialność. Zestawienie ich doświadczeń, opinii oraz chęci współpracy pozwala zespołowi projektowemu bez większych przeszkód adaptować się do zmieniających się wymagań klienta w celu wypracowania właściwych wartości, rezultatów, ponosząc jak najmniejsze koszty. Kontrakty podpisywane z klientem są potrzebne, ale bez współpracy z nim, nie stanowią żadnej korzyści dla zespołu projektowego czy firmy.

Reagowanie na zmiany odzwierciedla adaptacyjne wytwarzanie produktu zdefiniowane przez Agile. Każdy projekt ma pewne wiadome i niewiadome, pewniki i obszary niepewności, a zatem każdy projekt musi utrzymywać równowagę pomiędzy planowaniem a zmianami. Jednakże utrzymywanie równowagi jest konieczne również dlatego, że projekty prezentują sobą całą gamę, od typowo produkcyjnych, w których jest mało niewiadomych, po projekty typowo eksploracyjne, gdzie stopień niepewności jest wysoki”.  Projekty eksploracyjne, innowacyjne polegają w pierwszej kolejności na wyobrażaniu i wymyślaniu czegoś nowego, a następnie badaniu tych pomysłów, podczas gdy projekty produkcyjne na szczegółowym planowaniu i wykonywaniu kolejnych zadań. Nie jest możliwe wskazanie jednego, słusznego podejścia realizacji projektów – zależy to od specyfiki realizowanego projektu.

Reasumując, podstawę metodyki Agile stanowią klienci, produkty oraz ludzie. Kolejny rozdział jest próbom wskazania, jak korzystając z dobrodziejstw metodyki Agile wyeliminować ryzyko związane z czynnikiem ludzki.
Rdzeń APM tworzą zespoły adaptacyjne. Łączą w sobie wolność i odpowiedzialność, elastyczność i strukturę. W obliczu niekonsekwencji i niejednoznaczności celem zespołu jest konsekwentnie dostarczać elementy wizji produktu (w tym jego adaptowalność)  w ramach zakresu projektu. Osiągnięcie tego wymaga zespołów o samoorganizującej się strukturze oraz samodyscypliny członków.  Budowa takiego zespołu projektowego zgodnie z metodyką Agile należy do zadań kierownika projektu. Wg Highsmith’a na proces tworzenia struktury samoorganizującej się składają się:

  • pozyskanie odpowiednich ludzi;
  • zdefiniowanie wizji produktu, dopuszczalnych tolerancji i ról zespołowych;
  • stworzenie dobrze funkcjonujących kanałów komunikacyjnych;
  • ułatwianie wspólnego podejmowania decyzji;
  • wzbudzenie poczucia odpowiedzialności u każdego członka zespołu;
  • sterowanie, a nie kontrolowanie.

W metodyce Agile wymaganie pozyskania odpowiednich ludzi wynika z przypisywania ludziom większej wartości niż procesom. Kierownik projektu musi mieć możliwość doboru i usuwania członków zespołu projektowego, musi skupiać swoją uwagę na czynnikach ludzkich w projektach – talencie, posiadanych umiejętnościach, komunikacji, relacjach koleżeńskich itd., a następnie na produkcie i procesach. Bez odpowiednich ludzi niczego się nie zbuduje. Bez ostrego skupienia na produkcie, wkradają się działania uboczne. Bez ram procesu może wystąpić niska wydajność i być może pewien chaos.  Również zespoły projektowe pracujące wg metodyki Agile skupiają swoją uwagę na indywidualnych kompetencjach członków zespołu, które są krytycznym czynnikiem sukcesu projektu.  Kompetentny zespół może pracować wg dowolnego procesu i zrealizuje powierzone mu zadania projektowe, podczas gdy niekompetentny zespół nawet z pomocą najlepszych procesów nie odniesie sukcesu. Istotną rolę odgrywa również użytkownik i kierownictwo firmy – bez ich wsparcia, nawet najlepszy zespół projektowy poniesie porażkę.

Podczas procesu tworzenia zespołów projektowych, zatrudniania nowych pracowników firmy, menedżerowie i kierownicy projektów dosyć często korzystają z opracowanych przez siebie procesów rekrutacyjnych. Większość z tych procesów stara się „na siłę” dopasowywać kandydatów do organizacji, ograniczając im możliwości rozwoju osobistego. Metodyka Agile została tak skonstruowana, że na pierwszy miejscu stawia indywidualność każdego z pracowników oraz unikalną siłę każdego z zespołów projektowych. To nie zespół projektowy jest dopasowywany do wykorzystywanych w projekcie procesów, ale procesy są odpowiednio selekcjonowane i adaptowane do członków zespołu projektowego. Przyglądając się metodykom, które wywodzą się od Agile – eXtreme programing, Scrum, Crystal, FFD (Future – Driven Development) czy DSDM (Dynamic Systems Development Methodology) można zauważyć, że wszystkie kładą nacisk na ludzi, ich talent, umiejętności, zaangażowanie, współpracę i komunikację.

Kierownik projektu musi zadbać od to, aby każdy członek zespołu zrozumiał cel projektu, wizję produktu oraz swoją rolę i obowiązki w grupie projektowej. Pomaga zespołowi ogarnąć nie tylko harmonogram projektu, wskazuje zadania o najwyższym priorytecie wraz z ich uzasadnieniem. Im lepiej członkowie zespołu pojmą powody ograniczeń projektowych, tym lepiej mogą pomagać w zachowywaniu tych ograniczeń   i podejmowaniu decyzji kompromisowych w swojej codziennej pracy.  Ponieważ wytwarzane w trakcie projektu produkty ewoluują, zespół się rozrasta – przybywają nowi członkowie, pojawiają się nowe problem – formułowanie wizji powinno być ciągłym zadaniem realizowanym przez kierownika projektów w trakcie zarządzania projektem.

Twórcy metodyki rozróżnili dwa często uważane za synonimy pojęcia – komunikacja i współpraca. Komunikacja to wysyłanie, odbieranie i przekazywanie informacji. Natomiast współpraca rozumiana jest jako wspólna praca członków zespołu, której wynikiem będzie produkt główny lub cząstkowy realizowanego projektu czy też podjęta decyzja. Metodyka Agile skupia się na poszczególnych członkach zespołu projektu, na ich talentach i indywidualnościach, dopasowując odpowiednie procesy do specyfiki zespołów i ich członków, ale również na komunikacji pomiędzy nimi. Ludzie pracujący ze sobą w zespołach projektowych, w których komunikacja i współpraca z pozostałymi członkami odbywa się bez żadnych problemów, pracują na dużo wyższym poziomie niż, podczas gdy używają tylko i wyłącznie swojej wiedzy i talentu. O jakości wyników każdej współpracy przesądzają zaufanie i szacunek, swobodny przepływ informacji, dyskusje i aktywne uczestnictwo – połączone razem w procesie wspólnego podejmowania decyzji. Gdy któregoś z tych składników brakuje, lub jest nieskuteczny, cierpi na tym jakość rezultatów. W zespole współpracującym jedna z kluczowych ról lidera wiąże się z ułatwianiem, coachowaniem, nakłanianiem  i wpływaniem na członków zespołu, by budowali zdrowe relacje.   U podstaw sukcesu projektu leży zgrany zespół projektowy, którego „wyhodowanie” wg metodyki Agile powinno należeć do kierownika projektu. Kolejnym udogodnieniem, jakie wprowadza Agile jest zmniejszenie ilości tworzonej, przez zespół projektowy, dokumentacji technicznej do niezbędnego minimum. Wg Highsmith’a ok. 75% złożonych informacji przekazywana jest w dyskusjach pomiędzy członkami grup projektowych, a tylko 25% z wykorzystaniem stosownej dokumentacji. Choć współpraca i interakcja są motorem efektywnego wytwarzania adaptacyjnego, nie wszyscy inżynierowie (i inni członkowie zespołu) są skuteczni w komunikacji. Ten fakt jest źródłem kolejnej kluczowej roli adaptacyjnych kierowników projektu i liderów zespołu: „coachowania”.

Pracujący wg Agile kierownicy, muszą wspomagać członków zespołu w kształtowaniu umiejętności skutecznej komunikacji, która jest podstawą efektywnej współpracy z pozostałą częścią grupy projektowej.

Na efektywność pracy wpływa również możliwość wspólnego podejmowania decyzji. Współpraca polega na wspólnej realizacji zadań projektowych w celu osiągnięcia zdefiniowanego na początku projektu celu. Podczas realizacji tych zadań, członkowie zespołu często napotykają na najróżniejsze przeszkody, mają miejsce sytuacje, w których trzeba podjąć mniejsze lub większe decyzje. Sposób, w jaki zespół je podejmuje, określa, czy jest to zespół prawdziwie współpracujący. W podejmowaniu decyzji, powinien brać udział również kierownik projektu.  Często podczas realizowania innowacyjnych projektów trzeba podjąć tysiące decyzji, a potrzebne do tego dostępne informacje często są nieprzejrzyste i niejednoznaczne. Zespoły projektowe mogą pogubić się i wahać z podjęciem słusznej decyzji. W takiej sytuacji powinien wkroczyć kierownik, który przejmuje inicjatywę – podejmuje najlepszą decyzję, biorąc w pełni za nią odpowiedzialność i pozwala zespołowi realizować kolejne prace projektowe.

Pomimo, że metodyka promuje wspólne podejmowanie decyzji, definiuje również ogromne znaczenie odpowiedzialności członków zespołu.  Odpowiedzialność w każdym znaczeniu tworzy dobrze funkcjonujące zespołu samoorganizujące się.  Gdy jeden członek zespołu zobowiąże się wykonać, w określonym czasie, powierzone mu zadanie lub dostarczyć pozostałym członkom odpowiednie informacje, jest świadom wzięcia odpowiedzialności za te działania. Na każdym członku grupy projektowej i na kierowniku projektu spoczywa odpowiedzialność i obowiązek dotrzymywania danego słowa – pozwala to na zbudowanie odpowiedniego zaufania w zespole, które jest źródłem efektywnego wykorzystania ich kompetencji, co z kolei pozytywnie wpływa na współpracę.

Samoorganizacja i silna współpraca „wzdłuż i wszerz” organizacji to cechy bardzo dobrze charakteryzujące zespoły projektowe wykorzystujące Agile. Zespoły samoorganizujące się nie są zespołami nieposiadającymi lidera – potrafią organizować się i dopasowywać swoje działania do najróżniejszych sytuacji, aby sprostać problemom i wyzwaniom już w momencie ich pojawienia się. Metodyka wymusza na zespołach posiadanie wspólnego celu, zaufania i szacunku, wspólnego i szybkiego podejmowania decyzji w niejasnych sytuacjach. Rola lidera (kierownika projektu lub menedżera) w zespołach adaptacyjnych sprowadza się do sterowania zespołem, czyli wpływania, nakłaniania, ułatwiania pracy, zalecania, doradzania itd. Ustala cele i ograniczenia, określając w ten sposób środowisko, w którym projekt będzie realizowany i osiągnie swoją dojrzałość. Aby uzyskać adaptowalny, samoorganizujący się zespół, kierownik projektu przyznaje mu jak najwięcej autonomii, w maksymalnym stopniu „spłaszcza” jego strukturę, a następnie coachuje jednostki i pozbywa się tych, które nie przystają do zespołu.

Zespół projektowy tworzony jest z ludzi o najróżniejszych osobowościach i umiejętnościach pracujących w danej organizacji lub poza nią. Ludzie, środowisko  i kultura projektowa organizacji przenikają się wzajemnie. W swoim artykule Agile Software Development: The People FactorCockburn i Highsmith, projekt określają mianem ekosystemu. Zaburzenie pracy jednego z elementów tego systemu może mieć ogromny wpływ na jego stabilne funkcjonowanie. Przykładowo, jeżeli firmę opuszcza pracownik posiadający bardzo specjalistyczną wiedzę, organizacja będzie musiała sobie z tym poradzić, albo poprzez dopasowanie projektu do nowego procesu lub procesu do danego zadania projektowego. W rzeczywistości zarówno proces jak i ekosystem ulegną pewnym – większym lub mniejszym – zmianom. Wg metodyki Agile nie wszystkie procesy można stosować w każdym projekcie, dlatego należy je we właściwy sposób modyfikować i dopasowywać się do nich.

Sukces realizowanego projektu zależy m.in. od tego, co ludzie – członkowie zespołu projektowego realizującego dany projekt – robią i jak się zachowują. Istnieje wiele zasad, praktyk i metodyk, które stanowią przewodnik, pomagają w identyfikacji, kreowaniu i podtrzymywaniu pewnych zachowań zwiększających prawdopodobieństwo odniesienia sukcesu w realizowanym projekcie. Metodyka Agile promuje tzw. wytwarzanie adaptacyjne produktu. Promuje takie zachowania jak myślenie, działanie, interakcja, odpowiedzialność czy samodyscyplina. Podobnie jak wskaźnik psychologiczny Myers’a – Briggs’a definiuje cechy, jakimi powinni odznaczać się członkowie zespołu projektowego w branży IT – developerzy. Zarówno wg metodyki jak i wskaźnika MBTI powinny być to osoby:

  • będące introwertykami – czerpiące energię z własnego, wewnętrznego świata idei, emocji i wrażeń;
  • kierujące się intuicją – zbierające informację przez tzw. „szósty zmysł”, biorące pod uwagę, co mogłoby być;
    myślące – podejmujące decyzje i osądy obiektywnie, w sposób logiczny;
  • osądzające, będące sędziami – preferujące życie zorganizowane i zaplanowane.

W Manifeście Agile zawarto zasady, które wskazują kierunek zespołom adaptacyjnym, natomiast do faktycznej realizacji prac potrzebna jest konkretna praktyka. Struktura procesu i konkretne praktyki tworzą minimalne, elastyczne ramy strukturalne dla zespołów samoorganizujących.  Odpowiednie ich wykorzystanie znacznie zminimalizuje ryzyko związane z czynnikiem ludzkim opisane w rozdziale drugim.

Metodyka Agile nie jest metodyką uniwersalną, nadającą się do zastosowania w każdym projekcie. Może być wykorzystywana tylko w projektach pewnego typu, w pewnego typu organizacjach, których pracownicy mają szczególne spojrzenie na świat. Rozwijać się może w kulturach innowacyjnych i w projektach, w których szybkość, mobilność i jakość są razem kluczem do sukcesu. Określa strategiczną zdolność do tworzenia i reagowania na zmiany, do równoważenia elastyczności  i solidnej struktury, do wyzwalania kreatywności i innowacyjności w zespole wytwórczym oraz prowadzenia organizacji przez turbulencje i niepewność. Z sukcesem może być stosowana w sytuacjach opisanych w rozdziale drugim, które są rezultatem działań czynnika ludzkiego. Jej skuteczność została potwierdzona przez takich gigantów przemysłu IT jak Microsoft, Nokia, Google czy Yahoo.

Agile vs. PMBoK w kontekście ryzyka czynnika ludzkiego

Struktury podziału pracy, analiza ścieżki krytycznej czy zarządzanie zmianami składają się na wiedzę, narzędzia i techniki, które znajdują zastosowanie w zarządzaniu projektami. Elementy te nie wystarczą, aby skutecznie zarządzać projektami. Wg metodyki PMBOK osiągnięcie umiejętności skutecznego kierowania projektami przekłada się na rozumienie i użytkowanie wiedzy oraz umiejętności z następujących obszarów wiedzy:

  • Kanonu wiedzy o zarządzaniu projektami;
  • Wiedzy, norm i standardów oraz przepisów dotyczących danego obszaru zastosowań;
  • Zrozumienia otoczenia projektu;
  • Wiedzy i umiejętności z zakresu szeroko rozumianego zarządzania;
  • Umiejętności interpersonalnych.

Relacje pomiędzy tymi obszarami wiedzy przedstawiono na poniższym rysunku:

Kanon wiedzy o zarządzaniu projektami opisuje wiedzę znajdującą zastosowanie wyłącznie w dziedzinie zarządzania projektami, ale pokrywającą się z innymi dziedzinami zarządzania.  Na wiedzę opisaną przez metodykę PMBOK składają się definicja cyklu życia projektu, pięć grup procesów zarządzania projektami oraz dziewięć obszarów wiedzy.

Specyficzne obszary zastosowań obejmują kategorie projektów posiadających wspólne elementy charakterystyczne dla tych projektów, ale niekoniecznie występujące lub potrzebne we wszystkich przedsięwzięciach.  W odniesieniu do branży IT obszarami takimi mogą być np. produkcja lub projektowanie oprogramowania. Każdy z obszarów zastosowań charakteryzuje się własnym zbiorem norm, rozwiązań  i standardów, które powinny być brane pod uwagę podczas realizacji projektów.

Każdy projekt jest planowany i realizowany w określonym środowisku, które zarówno korzystnie, jak i niekorzystnie na niego wpływa. Dlatego zespół projektowy powinien postrzegać realizację projektu w jego kontekstach środowiskowych: kulturowym, społecznym, międzynarodowym, politycznym i fizycznym.
Kierownik projektu, oprócz posiadania wiedzy dotyczącej zarządzania projektami, powinien być zaznajomiony z innymi obszarami zarządzania, związanymi bezpośrednio ze specyfiką realizowanego projektu np. funkcjonowaniem danej organizacji, finansami i rachunkowością, wytwarzaniem i dystrybucją, technologiami informatycznymi, sprzedażą i marketingiem itd. Wiedza ta stanowi podstawę kształtowania się umiejętności z dziedziny zarządzania projektami i jest ważnym czynnikiem, który decyduje o sukcesie projektu.
Jednym z najistotniejszych elementów wpływających na sukces realizowanego projektu są umiejętności interpersonalne kierownika projektu i związany z nimi czynnik ludzki. Skuteczna komunikacja i działanie, przywództwo, motywowanie, negocjowanie i zarządzanie konfliktami oraz rozwiązywanie problemów to dobre praktyki zarządzania relacjami międzyludzkimi, które powinny być wykorzystywane i wcielane w proces zarządzania projektem przez kierownika projektu.

Wiedza zawarta w metodyce PMBOK stanowi jedynie część kanonu wiedzy o zarządzaniu projektami i wiedzy związanej z umiejętnościami interpersonalnymi. Umiejętności te przekładają się na czynnik ludzki w projekcie, który jak pokazała analiza źródeł niepowodzeń projektów informatycznych, przeprowadzona w rozdziale drugim, są jedną z najczęstszych przyczyn niepowodzeń projektów w branży IT. Dalszą część pracy poświęcono porównaniu praktyk opisanych w metodyce PMBOK  i metodyki Agile w kontekście radzenia sobie z ryzykiem, którego przyczyna leży w czynniku ludzkim.

Wg metodyki PMBOK „celem zarządzania ryzykiem w projekcie jest zwiększenie prawdopodobieństwa i skutków wystąpienia ryzyk korzystnych oraz zmniejszenie prawdopodobieństwa i skutków wystąpienia ryzyk niekorzystnych dla projektu”.  Jest ono jednym z procesów zarządzania projektem. Z kolei w metodyce Agile zarządzanie ryzykiem jest nieodzownym elementem procesu wytwarzania produktu. Identyfikacja, analiza i monitorowanie ryzyka oraz planowanie działań zapobiegawczych stanowią integralną część iteracyjnego wytwarzania produktów cząstkowych przez zespół projektowy. Oznacza to tyle, że za zarządzanie ryzykiem w projekcie prowadzonym zgodnie z Agile odpowiedzialny jest każdy członek zespołu.

DeMarco i Lister w swojej książce „Tańcząc walca z niedźwiedziami” wymienia podstawowe kategorie ryzyka występujące w projektach w branży IT – harmonogram zawierający błędy, zmieniające się (najczęściej rosnące) wymagania klienta, rotacja pracowników, problem z osiągnięciem konsensusu z klientem w sprawie specyfikacji wymagań oraz niska produktywność. Wg autorów najlepszą i najskuteczniejszą strategią tłumienia ryzyka jest inkrementalne wytwarzanie  produktu projektu.

Ryzyko, związane z czynnikiem ludzkim, o którym pisze DeMarco i Lister jest rezultatem utraty kluczowego członka zespołu projektowego. Kierownik zespołu powinien zadbać o odpowiednią motywację współpracowników, wspólne treningi i wzajemne samokształcenie się oraz tworzenie dokumentacji projektowej, zawierającej tylko i wyłącznie najistotniejsze informacje. Niestety, opisywana sytuacja jest rzadkością. Projekty adaptacyjne – prowadzone zgodnie z metodyką Agile lub pokrewną – posiadają wbudowane mechanizmy redukujące rotację personelu ze względu na wagę, jaką przywiązują do współpracy.  Agile narzuca kierownikowi projektu pewne schematy interakcji z członkami zespołu. W wytwarzaniu oprogramowania często jest stosowana technika „programowania parami”. Jak pokazały badania, stosowanie tej techniki wykazuje lepsze przekazywania  i współdzielenie wiedzy, co redukuje także negatywny wpływ płynności personelu.

Niska produktywność, o której wspomniano powyżej może mieć różne źródła pochodzenia – posiadanie nieodpowiednich ludzi w zespole projektowym, brak odpowiedniej współpracy członków zespołu czy też niskie morale. Metodyka Agile posiada praktyki pozyskiwania właściwych zasobów ludzkich, ich rozwoju jako jednostki, ale i zespołu, które pozwalają kompensować to ryzyko. Na wzrost produktywności mają wpływ również krótkie iteracje, których wynikiem są produkty cząstkowe spełniające żądane wymagania klienta, a także często skrócone czasy realizacji poszczególnych faz projektu. Problem produktywności i rotacji personelu nie jest poruszany przez PMBOK.

Celem procesu planowania zarządzania ryzykiem w metodyce tradycyjnej jest stworzenie planu opisującego działania, będące metodami zarządzania ryzykiem podczas realizacji projektu. Metodyka adaptacyjna nie narzuca konieczności tworzenia formalnego planu zarządzania ryzykiem, a sam proces wpisany jest w procedury wytwarzania produktu.

Proces identyfikacji ryzyka w tradycyjnym podejściu do zarządzania projektami przeprowadzany jest w zawężonym gronie, skupiającym tylko niektórych członków zespołu projektowego, z wykorzystaniem takich technik jak burza mózgów, listy kontrolne, przegląd dokumentacji itd. W projektach realizowanych z wykorzystaniem Agile wykorzystywane są te same techniki, ale to cały zespół projektowy bierze udział w identyfikacji ryzyka. W kolejnych iteracjach podczas spotkań planistycznych zespół identyfikuje oraz nadaje priorytety konkretnym ryzykom mającym wpływ na realizowany projekt.

Identyfikacja ryzyka wg PMBOK może mięć zarówno charakter ilościowy jak i jakościowy. W Agile wystarczy przeprowadzać tylko identyfikację ilościową – iteracyjne wytwarzanie produktu połączone z jego przeglądami wpływa na efektywność tej metody. W obydwu przypadkach procesy identyfikacji ryzyka są zdarzeniami cyklicznymi, a ich wynikiem jest lista ryzyk z nadanymi priorytetami, która powinna być uwzględniana i wykorzystywana w dalszej realizacji projektu (np. podczas planowania kolejnej iteracji w Agile bądź uaktualnia harmonogramu projektu w projekcie realizowanym zgodnie z wiedzą zawartą w metodyce PMBOK).

Zarówno metodyka tradycyjna jak i Agile przewidują proces planowania reakcji na ryzyka, który polega na wyszukiwaniu możliwości i akcji redukujący zagrożenia w projekcie oraz zwiększających prawdopodobieństwo jego powodzenia. W odniesieniu do zagrożeń, czyli ryzyk, które w razie wystąpienia wpływają niekorzystnie na cele projektu, stosuje się na ogół…”  następujące strategie: akceptacja, łagodzenie, przeniesienie lub unikanie. Różnica pomiędzy Agile a metodyką PMBOK w tym obszarze polega na tym, że w metodyce „zwinnej” w proces planowania reakcji na ryzyka zaangażowany jest każdy członek zespołu projektowego. Zespół wspólnie podejmuje decyzję, jaka strategia zostanie obrana w stosunku do każdego z zidentyfikowanych ryzyk. W projekcie realizowanym zgodnie z tradycyjną metodyką zarządzania projektami, proces ten obejmuje określenie i wyznaczenie jednej lub więcej osób (zwanych dysponentami reakcji na ryzyka), które będą odpowiedzialne za każdą uzgodnioną i finansową reakcję na ryzyko. Planowanie reakcji na ryzyka przeprowadza się według określonej istotności ryzyk, zaczynając od najważniejszych. W miarę potrzeb uzupełnia się budżet, harmonogram i plan kierowania projektem o zasoby i działania.

Kontrola i nadzorowanie ryzyka odbywa się w metodyce Agile na końcu każdej iteracji, jako integralna część iteracyjnych spotkań polegających na przeglądzie danego etapu. Analizie poddawane są wyniki z procesu monitorowania każdej z iteracji, który polega na obserwowaniu ryzyk podczas codziennych zadań członków zespołu. Dodatkowo proces ten wspomagany jest przez spotkania integracyjne zespołu, polegające na koordynowaniu z dnia na dzień działań jego członków oraz monitorowaniu ryzyka poprzez zauważanie potencjalnych źródeł ryzyka i nowych problemów czy przeszkód. Proces ten, zdefiniowany w metodyce PMBOK, podobnie jak inne procesy zarządzania ryzykiem, jest procesem ciągłym realizowanym przez cały cykl życia projektu , ale częstość jego przeprowadzania zależy od kierownika projektu – to on ustala terminy kolejnych kontroli i nadzoru ryzyk.

Najistotniejszą różnicą pomiędzy metodyką tradycyjną reprezentowaną przez PMBOK, a metodyką Agile jest to, kto jest właścicielem procesu zarządzania ryzykiem. W metodyce tradycyjnej osobą odpowiedzialną jest kierownik projektu, natomiast w Agile odpowiedzialność za zarządzanie ryzykiem spoczywa na całym zespole projektowym. Rola kierownika projektu w tym procesie sprowadza się do nadzoru i umożliwiania pracy zespołowi zgodnie z takim „zwinnym” podejściem. Metodyka Agile wręcz wymusza, aby ryzyko było identyfikowane na każdym spotkaniu planistycznym – czy to na codziennym spotkaniu integracyjnym, spotkaniu poświęconym planowaniu kolejnej iteracji (kolejnego etapu) czy przeglądzie zakończonego etapu itd. Prawdopodobieństwo zaistnienia ryzyka, którego źródłem jest czynnik ludzki, w projektach realizowanych z wykorzystaniem metodyki „zwinnej” jest zredukowane do minimum. Jest to rezultatem ogromnego zaangażowania zespołu projektowego w realizację całego projektu, łącznie z procesem zarządzania zakresem i ryzykiem. To na zespole projektowym i każdym jego członku spoczywa odpowiedzialność za wywiązywanie się z powierzonych zadań, podejmowanie decyzji itd. Iteracyjne wytwarzanie produktów cząstkowych zapewnia ciągłą analizę  i identyfikację ryzyk, zmniejszając ryzyko niepowodzenia projektu.

Tradycyjne podejście do zarządzania projektami kładzie silny nacisk na planowanie, a w mniejszym stopniu na kontrolę wykonania raz założonego planu projektu. Niestety, w praktyce zbyt często okazuje się, że stworzenie wiarygodnego planu jest bądź to bardzo trudne, bądź po prostu niemożliwe ze względu na ograniczony zakres dostępnej informacji i szybko zmieniające się warunki w projekcie.  Efektem takiego podejścia jest załamanie się projektu, do którego wkrada się chaos, a kierownicy bronią się przed nieuniknionymi zmianami. W takiej sytuacji powodzenie projektu jest zagrożone. PMBOK promuje planowanie, jako najważniejszą rolę menedżera projektu, pomijając istotną rolę procesów realizacji, monitorowania i kontroli projektu. Takie podejście może stwarzać wiele problemów w projektach z branży IT, które charakteryzują się dużą zmiennością wymagań klientów i wykorzystywaniem ciągle rozwijających się technologii informatycznych, co z kolei przekłada się na wysokie ryzyko w projekcie.

Pomimo, iż metodyka Agile stanowi otwartą i brutalną krytykę tradycyjnego sposobu wytwarzania oprogramowania i zarządzania projektem opartego o złożone i skomplikowane procedury zarządzania jakością oraz niezwykle biurokratyczne mechanizmy raportowania i kontroli  jest bardzo popularna w projektach IT. Nie skupia się na technikach, procesach i procedurach, ale podkreśla istotną rolę relacji międzyludzkich, spekulatywnego planowania, iteracyjnego wytwarzania produktów cząstkowych pozwalającego na wiarygodny pomiar postępu prac projektowych. Cykl życia projektu wg koncepcji adaptacyjnego zarządzania projektem składa się z pięciu faz:

Ponieważ metodyka Agile czerpie bardzo dużo z praktyk tradycyjnego zarządzania projektami, procesy zwinnego wytwarzania produktu można łatwo przemapować na grupy procesów zdefiniowane w metodyce PMBoK.

Sukces projektu w branży IT, rozumiany jako zrealizowanie go w założonym budżecie i czasie, spełniającego wszystkie wymagania klienta i posiadającego odpowiednią jakość, zależy w dużym stopniu od czynnika ludzkiego, co potwierdzają badania przytoczone w rozdziale drugim przeprowadzone przez The Standish Group oraz The Concours Group. Metodyki tradycyjna i Agile mają wiele cech wspólnych: obydwie definiują pojęcie cyklu życia projektu, fazę inicjującą projekt itd., ale również wiele różnic – choćby taka, że Agile minimalizuje ilość wytwarzanej dokumentacji projektowej do niezbędnego minimum, podczas gdy metodyka tradycyjna wymusza dokładne dokumentowanie każdego procesu. W pewnych obszarach zarządzania projektem, jedna metodyka ma przewagę nad drugą i vice versa. Jednak rozpatrując obie metodyki w kontekście radzenia sobie z ryzykiem wynikającym z czynnika ludzkiego, można śmiało stwierdzić, że z rozwiązaniem tego rodzaju problemów lepiej poradzi sobie metodyka Agile.

Z biznesowego punktu widzenia projekty IT zazwyczaj posiadają kilka celów produktowych obejmujących np. modernizację infrastruktury IT, szkolenia użytkowników, tworzenie dokumentacji użytkownika, wytwarzanie oprogramowania itd. Takimi projektami trudno zarządzać tylko z wykorzystaniem technik tradycyjnych lub technik „zwinnych”, ponieważ metodyki te sprawdzą się tylko do pewnego obszaru zakresu. Dobrym rozwiązaniem będzie synergiczne wykorzystanie obydwu metodyk, poprzez umiejętne wykorzystanie ich zalet.

Procesy inicjalizacji projektu ułatwiają formalne zatwierdzenie rozpoczęcia nowego projektu lub jego etapu. W przejrzysty sposób formułuje się cele projektu, w tym uzasadnienie, dlaczego dany projekt jest najlepszym z możliwych rozwiązań spełniających wymagania. Dokumentacja tej decyzji obejmuje również podstawowy opis zakresu projektu, produktów cząstkowych, czasu trwania oraz prognozę wykorzystania zasobów…  Dobre praktyki zalecają również angażowanie klientów oraz innych interesariuszy w proces inicjalizacji projektu – wynikiem tego jest współodpowiedzialność, akceptacja produktów cząstkowych projektu, zadowolenie klientów i interesariuszy. Podobne postępowanie w trakcie rozpoczynania projektu zaleca Agile. Aby już w tej fazie nie wkradły się chaos i nieporozumienia, koncepcja iteracyjnego wytwarzania produktów musi być dokładnie przedstawiona wszystkim zainteresowanym stronom projektu.

Planowanie powinno być procesem iteracyjnym, mającym miejsce w trakcie trwania projektu – od momentu rozpoczęcia, do jego zakończenia. Motorem tej grupy procesów powinny być aktualny status i stan projektu, zmiany biznesowe wymagań czy wzrost technicznej wiedzy na temat realizowanych produktu głównego i produktów cząstkowych. W metodyce tradycyjnej z procesami planowania związane jest tzw. planowanie kroczące, polegając na stopniowym uszczegółowianiu planu w miarę gromadzenia odpowiedniej wiedzy np. nt. danego produktu. Koncepcja ta jest dość często pomijana przez kierowników projektów, czego wynikiem są bardzo skomplikowane harmonogramy projektu (wykresy Gantta) i struktury podziału pracy, których wiarygodność nie jest duża, a próba ich uaktualnienia może zakończyć się niepowodzeniem. Projekty z branży IT cechują się dużą niepewnością jeżeli chodzi o wymagania jak i stosowane technologie, dlatego planowanie ich realizacji powinno być oparte o produkty cząstkowe, a nie o zadania poszczególnych członków zespołu projektowego. Próba zaplanowania szczegółowych aktywności wymaganych do rozwiązania problemu projektowego zakończy się niepowodzeniem. Zaletą podejścia produktowego planowania jest ułatwione śledzenie kondycji realizowanego projektu.

Grupa procesów realizacji składa się z procesów wykorzystywanych w celu wykonania prac określonych w planie kierowania projektem i pozwalających spełnić wymagania projektu. Zespół projektu ustalić, które z procesów są potrzebne w danym przedsięwzięciu.  Ponieważ PMBOK opisuje najlepsze praktyki zarządzania projektami niezależnie od dziedziny przemysłu, nie wskazuje, jak podejmować realizację zadań w dowolnym projekcie. To zespół projektowy powinien ustalić, które   z procesów (często specyficznych dla danej dziedziny wiedzy) są potrzebne do realizacji danego projektu. Najlepsze praktyki realizacji w projektach z branży IT, szczególnie polegających na wytwarzaniu oprogramowania, opisuje metodyka Agile. Do tych praktyk należą:

  • wytwarzanie iteracyjne;
  • bliska współpraca z klientem i użytkownikiem produktu;
  • otwarta komunikacja;
  • odpowiedzialność zespołu projektowego;
  • wspólne planowanie i podejmowanie decyzji przez zespół projektowy.

Wg metodyki tradycyjnej, procesy monitorowania i kontroli polegają na obserwacji wykonania projektu, która pozwala na dostrzeganie potencjalnych problemów i w razie konieczności realizowaniu działań korygujących dla zachowania kontroli wykonania projektu.  Z ich wykorzystaniem możliwe jest również określenie aktualnych odchyleń od planu realizacji projektu. Dla projektów IT lepsze praktyki definiuje metodyka „zwinna”. W Agile odpowiednikiem grupy procesów monitorowania jest faza adaptacji projektu, w której wyniki pracy z fazy eksploracji (realizacji) poddawane są przeglądom i ocenie od strony technicznej, od strony biznesowego uzasadnienia projektu oraz z perspektywy klienta.

Formalne zamknięcie działań projektowych lub pewnego etapu projektu powinno być realizowane z wykorzystaniem wiedzy zawartej w metodyce PMBOK. Zakończenie tej grupy procesów potwierdza zakończenie wszystkich procesów we wszystkich grupach procesów i tym samym zamknięcie projektu lub jego etapu. Tym samym następuje formalne zakończenie projektu lub jego etapu.

Obecnie projekty IT charakteryzują się dużą zmiennością wymagań, stopnia trudności i wysokim ryzykiem realizacji, co negatywnie wpływa na realizację projektu. Podejście Agile eliminuje te czynniki poprzez iteracyjne wytwarzanie produktów cząstkowych oraz ścisłe trzymanie się idei produktu łatwo modyfikowalnego. Kierownik projektu podejmując się realizacji projektu o wysokim ryzyku realizacji, powinien obok technik tradycyjnych opisanych w PMBoK, wykorzystać metodykę Agile, która daje dodatkowe mechanizmy realizacji i kontroli projektu, a także alternatywne metody śledzenia postępu projektu, których wykorzystanie nie powoduje większego wpływu na obciążenie wykorzystywanych zasobów.

Podsumowanie

Główne problemy pojawiające się w projektach w branży IT mają podłoże socjologiczne, a nie techniczne. Badania omówione w rozdziale drugim, przeprowadzone w ciągu ostatnich lat przez The Standish Group oraz The Concours Group, pokazały, że jedną z głównych przyczyn niepowodzeń projektów informatycznych jest czynnik ludzki. Ponieważ wciąż ok. 50% projektów kończy się niepowodzeniem, czynnik ludzki nie może być ignorowany, jeżeli zaistniały problem będący jego wynikiem jest do rozwiązania. Wymienić można dziesiątki sytuacji czy zdarzeń świadczących o potencjalnym ryzyku, którego źródłem jest czynnik ludzki. Do takich sytuacji należą:

  • informacje od kierownictwa powodują konflikty;
  • zespół projektowy jest rozbijany ze względu na konieczność realizowania zadań w innych projektach o wyższych priorytetach;
  • mała liczba lub całkowity brak szkoleń;
  • członkami zespołu stają się niedoświadczeni, posiadający małe kwalifikacje pracownicy;
  • liczne zwolnienia członków zespołu z firmy;
  • brak spotkań integracyjnych;
  • brak działań wpływających na utrzymanie motywacji zespołu projektowego na wysokim poziomie;
  • brak zainteresowania menadżera projektu zespołem projektowym;
  • organizacja zespołu projektowego zakończona niepowodzeniem;
  • niedobór zasobów ludzkich w zespole projektowym;
  • zespół projektowy przestaje realizować cele projektu – traci je „ze wzroku”;
  • członkowie zespołu nie są rozliczani z realizowanych zadań;
  • członkowie zespołu nie są usytuowani w jednym miejscu;
  • członkowie zespołu „rzucani” są od zadań projektowych w jednym projekcie do zadań w innym projekcie;
  • brak zaangażowania menedżerów wyższego szczebla w realizowany projekt;
  • niedoinformowani członkowie zespołu projektowego;
  • nieodpowiednie środowisko pracy;
  • praca nad projektem z nierealistycznym lub niemożliwym do dotrzymania terminem realizacji.

Powyższa lista zawiera tylko niektóre, potencjalne sytuacje i zdarzenia, które mogłyby doprowadzić zespół projektowy i projekt do niepowodzenia. Wystąpienie jednej z tych sytuacji nie doprowadzi od razu do porażki. Dopiero wystąpienie kilku z nich w tym samym czasie, spowoduje wzrost prawdopodobieństwa wystąpienia potencjalnego ryzyka, co powinno zaniepokoić kierownika projektu.

Ryzyko związane z czynnikiem ludzkim może wystąpić w dowolnym etapie projektu, dlatego też powinno być monitorowane przez cały okres realizacji projektu. Możliwości takie dają m.in. takie narzędzia zarządzania ryzykiem jak ankiety eksperckie, burza mózgów czy listy kontrolne. Są to narzędzia stosunkowo łatwe  i szybkie do wykorzystania. Bazują na zasobach grupy projektowej, które najlepiej wiedzą jakie elementy czynnika ludzkiego negatywnie wpływają na realizowany projekt. Kierownik projektu, który wykorzystuje wspomniane narzędzia do analizy ryzyka w kontekście czynnika ludzkiego, powinien do udziału w takich sesjach zapraszać jak największą liczbę członków zespołu. Pozwoli mu to osiągnąć wiarygodne wyniki dla zespołu projektowego. Dodatkową zaletą będzie poczucie wspólnoty w zespole i przekonania, że razem można osiągnąć więcej. Mocną stroną tych narzędzi są otrzymywane wyniki, które w dokładny sposób wskazują zaistniałe problemy, mogą również zawierać wskazówki i metody ich rozwiązania.

Ryzyko związane z czynnikiem ludzkim można również zminimalizować poprzez odpowiednie podejście do zarządzania zasobami ludzkimi i realizacją zadań projektowych. Dobre praktyki przedstawiono w rozdziale trzecim. Stworzenie odpowiedniego procesu budowania zespołu projektowego zwiększy możliwości zbudowania zgranej grupy, złożonej z utalentowanych i zmotywowanych ludzi, zaangażowanych w realizację powierzonych im zadań, znających zasady komunikacji  i dobrej współpracy z pozostałymi członkami zespołu. Utalentowani ludzie, zgrane zespołu oraz przyzwoite warunki pracy nie wystarczą, żeby zapewnić powodzenie projektu. Brak jednak tych elementów prawie na pewno gwarantuje niepowodzenie projektu.

Projekty w branży IT charakteryzują się wysokim stopniem ryzyka, wynikającym z często zmieniających się wymagań klienta. Podejście jakie proponuje metodyka Agile eliminuje te czynniki poprzez iteracyjne wytwarzanie produktów cząstkowych oraz ścisłe trzymanie się idei produktu, który łatwo można modyfikować    i rozwijać. Agile promuje takie zachowania jak myśleniem działanie, interakcja, odpowiedzialność czy samodyscyplina. Narzucając pewien schemat postępowania kierownika i członków zespołu projektowego oraz wskazując sprawdzone praktyki zarządzania projektami, minimalizuje prawdopodobieństwo zaistnienia ryzyka związanego z czynnikiem ludzkim.

Wierzę, że przedstawione w pracy rozważania stanowią wartościowe informacje zarówno dla menedżerów, kierowników projektów jak i członków zespołów projektowych oraz wszystkich tych, którzy związani są z realizacją projektów w branży IT. Praca pokazuje, jak stosując proste zasady i wskazówki dotyczące sposobu budowania zespołu projektowego, odpowiedzialności, komunikacji i środowiska pracy projektowej zminimalizować wpływ czynnika ludzkiego na niepowodzenie realizowanych projektów.

PODZIEL SIĘ
Redakcja 4PM.pl
Misją 4PM.pl jest pomaganie Project Managerom w ich codziennej pracy poprzez dostarczanie informacji i wiedzy z zakresu zarządzania projektami.

BRAK KOMENTARZY

ZOSTAW ODPOWIEDŹ