projekt it

Projekty IT i www – dlaczego 90% z nich ma opóźnienie?

Szef pyta: „to na kiedy możemy puścić tę aplikację do ludzi”. W odpowiedzi od zespołu IT najpierw słyszy „Eeee, aaaa… hmm… 3 czerwca 2012″… Potem wszyscy spotykają się na sylwestra 2012 i prezes życzy zespołowi aby w ogóle skończył opóźnione już przedsięwzięcie. Dlaczego projekty IT prawie zawsze są w tyle z harmonogramem? Istnieje panaceum?

Kilka lat pracowałem jako project manager IT w korporacji (w PMO), firmie developerskiej i agencji interaktywnej. Prowadziłem projekty IT, które pomagały w  sprzedaży, optymalizacji kosztów oraz minimalizacji ryzyk prawnych. Moim zadaniem było takie zarządzanie ludźmi, aby doprowadzić m.in. cele produktowe projektu do końca (implementacja systemu bądź zmian w istniejącym oprogramowaniu). Po wynegocjowaniu z Komitetem Sterującym założeń projektu, w ramach trójkąta ograniczeń, kompletowałem zespoły: wykonawcze, jakościowe, doradcze, itd. W połowie projektu okazywało się, że każdy w zespole ma zegarek, który działa z inną prędkością 🙂

trójkąt ograniczeń
Trójkąt ograniczeń projektowych

Projekty IT – opóźnienie jest OK?

W projektach, które prowadziłem duże koszty (kasa, zasoby ludzkie) i rozbuchany do granic możliwości zakres rzadko były problemem dla beneficjentów projektu. Tak mi się trafiało. Jednak na kolejnych spotkaniach informujących o statusie projektu IT i planowanym terminie jego skończenia, „góra” dostawała białej gorączki, ja też. Każdy „status” był kolejną aktualizacją harmonogramu (opóźnienie).
Trochę się uspokoiłem kiedy zacząłem jeździć na konferencje PMI oraz IPMA i tam prelegenci ze stoickim spokojem prezentowali globalne statystyki, gdzie zaprezentowane są projekty IT w kontekście opóźnień. Okazuje się, że 90% z nich ma istotne zmiany w harmonogramie ze szkodą dla Właścicieli Biznesowych. Do tego ponad 40% projektów (nie tylko IT) jest przerywanych i rzadko dzieje się to ze względów koniunkturalnych, a częściej operacyjnych.

PMI canceled projects global
Przerwane projekty wg raportu PMI

Jednak po paru latach raportowania opóźnień miałem dość. Zacząłem się zastanawiać o co chodzi w tym status quo? Gdzie radość z mojej pracy, w dostarczaniu ludziom potrzebnych im rozwiązań? Czy kiedyś uda mi się zaraportować aktualizację harmonogramu, w którym poinformujemy Komitet, że aplikacja zostanie wdrożona wcześniej niż zakładaliśmy?

Zespół ekspertów – czas to rzecz względna

Jako powody opóźnień, które odnotowują projekty IT, podaje się takie przyczyny:

  • Zewnętrzne czynniki
    • zmiany na rynku i brak dalszego uzasadnienia biznesowego dla kontynuowania projektu,
    • zmiany prawne, restrukturyzacja firmy, czynniki kulturowe…
  • Wewnętrzne czynniki
    • brak metod szacowania czasu wykonania („no zajmie to nam 1 miesiąc… albo 1 rok”),
    • brak motywacji zespołu („ten projekt jest bez sensu”),
    • brak myślenia systemowego („mam w dupie co robi drugi zespół projektowy”),
    • brak zarządzania priorytetami („zróbcie nam wszystko”),
    • słabe umocowanie władzy PM-a w organizacji („gadaj z moim kierownikiem”),
    • niewłaściwy sposób zgłaszania wymagań oraz ich dokumentowania przez klienta wewnętrznego (działy „biznesowe” organizacji) lub zewnętrznego (zlecenia). („eee… fajna ta aplikacja, ale nam chodziło o co innego”).
Czytaj również:  Jak nie płacić podatku w e-startupie?

O każdym z punktów można napisać elaborat. Ja skupię się na ostatnim. Czy nigdy nie spotkałeś(aś) się z sytuacją, że razem z klientem lub wykonawcą IT ustalacie zakres, tworzycie jakąś mniej lub bardziej formalną specyfikację, a po implementacji jesteście negatywnie zaskoczeni? Wystarczą same opowieści znajomych. Kto się zetknął z zespołową realizacją jakiegokolwiek oprogramowania (w tym internetowego) wie o czym mówię.

Wy po chińsku, my w Suahili

Diabeł tkwi w komunikacji osób programujących i zlecających (tzw. Biznes). Technologia ma to do siebie, że nie każdy ją zna. Nieumiejętne przenoszenie na papier (przez Biznes) swoich oczekiwań powoduje ich błędną interpretację przez programistów. Powstaje coś co rozmija się z oczekiwania Biznesu. Wtedy zgłaszane są poprawki, również niezrozumiałe dla drugiej strony, a takie ciągłe zmiany kosztują czas. Wtedy opóźnienie mamy gotowe.
Czasami dział IT, poprzez bierne zachowanie w projekcie, jasno pokazuje, że czeka na specyfikację i że nie ma kompetencji („naprawdę?”) do aktywnego włączenia się w proces tworzenia dokumentu wymagań i projektu zmian. W wielu firmach to pewien fakt, jednak jest on patologią w najczystszej postaci, bo każdemu pracownikowi i jednostce powinno zależeć na osiąganiu celów biznesowych firmy.
Także po stronie Biznesu nie jest wesoło. Nawet jeśli PM stworzy wspólny słownik dla komunikacji (w dużych projektach) to nie każdy ekspert-indywidualista ma ochotę na zmianę swoich nawyków w imię dobra zespołu. Pojawiają się często osoby, które bardziej stawiają na lans i spotkania towarzystwa wzajemnej adoracji. Jeśli moje prośby nic nie dają, szybko usuwam takiego pacjenta z zespołu, choćby nie wiem jak wielką wiedzę posiadał.
Do tego permanentna zmiana opisu wymagań przez Biznes („hmm.. co ja tak naprawdę chcę?”) śni się po nocach Dyrektorom IT.

Jak temu zaradzić?

Po pierwsze na podstawie własnych doświadczeń i nabytej wiedzy, zauważyłem, że im większa firma i zespół projektowy, tym trudniejsza komunikacja. Prosta zależność, gdzie projekty IT odczuwają ją wyjątkowo boleśnie. Masa kanałów informacyjnych i większe prawdopodobieństwo tworzenia się szumów informacyjnych oraz „przekręcania treści”. Prosta zasada: im większy zespół tym bardziej musisz sformalizować projekty IT aby jako tako trzymać ludzi w ryzach. Inaczej nie zapanujesz i przesunięcie terminu zakończenia projektu będziesz liczył w setkach procent.

projekty IT
Projekty IT i rzeczywistość

Jeśli natomiast zespół nie przekracza 20-30 osób (większe po części też), włącznie z klientami, a opóźnienia pojawiają się nadal, poniżej kilka moich rad (których nie znajdziesz w podręcznikach PRINCE2 czy PMI):

  • Wyznacz analityka systemowego – albo jako PM sam nim bądź. Analityk systemowy ma za zadanie spisać wymaganiami Biznesu, tak aby były one w formie zrozumiałej dla programistów. Jest on kluczowy w projektach IT jeśli chodzi o komunikację. Jeśli zna podstawy UML, ma trochę zdrowego rozsądku to uda mu się zarzuć pomost pomiędzy światem IT i Biznesu. Wtedy wszyscy się dogadają i uśmiech wróci ludziom na twarz. Jednak ze względu na koszty firmy często przemilczają temat. W małym startupie się nie zastanawiaj, bierz sprawy w swoje ręce 🙂
  • Pomagaj estymować czas – rzadko który programista lubi deklarować terminy wykonania. Jednak z moich doświadczeń wynika, że 80-90% komponentów jest używanych ponownie i są jedynie modyfikowane. Staraj się promować budowanie APIs, hermetycznych i re-używalnych komponentów. Do tego warto trzymać na jakiejś liście wykonywane „user stories” i wpisywać po zakończeniu implementacji rzeczywisty ich czas wykonania. Przegląd takiej historii naprawdę pomaga PM-owi i programiście w lepszym szacowaniu zadań. Nie polecam za to bardzo sformalizowanych metod estymacji takich jak SLOC czy metoda punktów funkcyjnych. Jedna firma konsultingowa karmiła nas tymi bajkami kiedyś w korpo i rezultaty były mało użyteczne.
  • Marginesy błędów estymacji – to ostatnia deska ratunku, kiedy zakładasz, że każdy programista myli się i każdemu z nich przypisujesz jakąś wartość współczynnika takiej pomyłki. Nie lubię takiego podejścia bo zakłada ono, że niektóre osoby nie są na tyle dojrzałe aby brać odpowiedzialność za swoje deklaracje.
  • Stosuj iteracje i dawaj feedback – to jedne z podstaw manifestów Agile i XP. Stosowane w ramach nich metody takie jak Scrum pozwalają poprzez iteracje zaplanować wiele punktów kontrolnych i minimalizować ilość niedopowiedzeń i pomyłek co do zakresu tworzonego projektu.
  • Buduj relację pomiędzy IT i Biznesem – to już kwestia kultury organizacji, która unika mówienia o innych działach czy klientach „że to banda idiotów”. Takie podejście to pierwszy stopień do braku zrozumienia drugiej strony i budowania czegoś czego nie rozumiemy. Projekty IT są robione przez ludzi i dla ludzi.
Czytaj również:  B2B = Human to Human w IT. Szanujmy się kliencie!

Ja dzięki takim doświadczeniom i wnioskom przeniosłem się do mniejszej firmy gdzie „mam” zespół kilku osób. Tutaj projekty IT rzadko zaliczają opóźnienia, głównie dzięki szybkiej i jasnej komunikacji. Bliższe relacje pozwalają być świadomymi po co tu jesteśmy i dlaczego to robimy.
A jakie są wasze doświadczenia z harmonogramem jeśli chodzi o projekty IT? 🙂

Komentarze (Dodaj swój):

  1. Współpracowałem już z kilkoma programistami, również znajomi zlecali kilka projektów i z doświadczenia widzę, że niezależnie czy programistą będzie początkujący student czy duża firma to opóźnienia są zawsze. Po części to rozumiem bo nie da się wszystkiego przewidzieć szczególnie jeżeli ktoś np. zaczyna pracę przy projekcie nad którym pracował ktoś inny. Najważniejsze żeby te opóźnienia były w granicach rozsądku (rekord gościa którego zatrudniłem to czas wykonania przekroczony o 700%).
    To co zacząłem stosować to aby usprawnić pracę:
    – podział prac na jak najmniejsze zadania i bieżąca kontrola postępu prac. Dużo bardziej motywuje to programistę niż zlecenie projektu jako całości i kontrola np. po miesiącu kiedy to okazuje się, że połowa rzeczy jest jeszcze do zrobienia a deadline coraz bliżej.
    – jak najbardziej szczegółowy opis + najlepiej wizualizacje prac (pokazuję konkretnie jak dana strona czy formularz ma wyglądać)
    – podwójny harmonogram – przykładowo jeżeli z programistą ustalam termin wykonania na 10 lutego to w swoim harmonogramie zapisuję, że praca zakończona będzie 20 lutego i do tej daty zakładam ewentualnie inne zadania. Wliczając opóźnienia przeważnie czasowo zakończenie prac wkomponowuje się idealnie 😉

  2. Współpracowałem już z kilkoma programistami, również znajomi zlecali kilka projektów i z doświadczenia widzę, że niezależnie czy programistą będzie początkujący student czy duża firma to opóźnienia są zawsze. Po części to rozumiem bo nie da się wszystkiego przewidzieć szczególnie jeżeli ktoś np. zaczyna pracę przy projekcie nad którym pracował ktoś inny. Najważniejsze żeby te opóźnienia były w granicach rozsądku (rekord gościa którego zatrudniłem to czas wykonania przekroczony o 700%).
    To co zacząłem stosować to aby usprawnić pracę:
    – podział prac na jak najmniejsze zadania i bieżąca kontrola postępu prac. Dużo bardziej motywuje to programistę niż zlecenie projektu jako całości i kontrola np. po miesiącu kiedy to okazuje się, że połowa rzeczy jest jeszcze do zrobienia a deadline coraz bliżej.
    – jak najbardziej szczegółowy opis + najlepiej wizualizacje prac (pokazuję konkretnie jak dana strona czy formularz ma wyglądać)
    – podwójny harmonogram – przykładowo jeżeli z programistą ustalam termin wykonania na 10 lutego to w swoim harmonogramie zapisuję, że praca zakończona będzie 20 lutego i do tej daty zakładam ewentualnie inne zadania. Wliczając opóźnienia przeważnie czasowo zakończenie prac wkomponowuje się idealnie 😉

  3. @Maciej Oleksy – jest jeszcze jeden, bardzo istotny i częsty powód, dla którego (duże) projekty IT się opóźniają – dostawcy świadomie zaniżają czas realizacji projektu tylko po to aby go wygrać, a później renegocjują, czyli metodologia "jakoś to będzie" 🙂

    1. Tomek, dlatego ja zawsze proponuję iteracyjną realizację zlecenia z płatnością po każdej. Jak klient się nie zgadza to rezygnuję bo wiem, że czeka mnie męczarnia i walka. Jednak wiem, że mało firm może sobie na to pozwolić. Ale to się opłaca obu stronom, wystarczy znać zalety Agile 🙂 u mnie muszę powiedzieć 90% na to idzie i są zadowoleni…

  4. @Maciej Oleksy – jest jeszcze jeden, bardzo istotny i częsty powód, dla którego (duże) projekty IT się opóźniają – dostawcy świadomie zaniżają czas realizacji projektu tylko po to aby go wygrać, a później renegocjują, czyli metodologia "jakoś to będzie" 🙂

  5. Porządny interaktywny brief, mądre, elastyczne i przyjazne pracownikom procedury oraz kontrola jakości są bardzo ważne. Bardzo dobry artykuł, nie zapominajmy jednak, że wymienione problemy dotyczą polskich firm w szczególności, gdzie kultura pracy jeszcze się nie wykreowała..

  6. Porządny interaktywny brief, mądre, elastyczne i przyjazne pracownikom procedury oraz kontrola jakości są bardzo ważne. Bardzo dobry artykuł, nie zapominajmy jednak, że wymienione problemy dotyczą polskich firm w szczególności, gdzie kultura pracy jeszcze się nie wykreowała..

  7. Tomek, dlatego ja zawsze proponuję iteracyjną realizację zlecenia z płatnością po każdej. Jak klient się nie zgadza to rezygnuję bo wiem, że czeka mnie męczarnia i walka. Jednak wiem, że mało firm może sobie na to pozwolić. Ale to się opłaca obu stronom, wystarczy znać zalety Agile 🙂 u mnie muszę powiedzieć 90% na to idzie i są zadowoleni…

  8. Raczej nie ma innej rady w średnich projektach IT, skoncentrowanych wokół internetu, jak zastosowanie waterfalli na poziomie managementu a agile na poziomie wytwarzania produktu. To się ze sobą w żaden sposób nie kłóci, pod warunkiem, że my jako wykonawca jesteśmy w stanie zaplanować projekt na wysokim poziomie a potem tak prowadzić zespół, aby dotrzymał terminów.
    Bardzo istotna jest tutaj uwaga odnośnie oczekiwań klientów – Agile nie da się sprzedać, ani wygrać nim przetargu w Polsce, ale bardzo często zadanie klientowi pytania "jaki jest cel tej aplikacji", "kto jest jej docelowym odbiorcą", "jaka akcja oznacza konwersję użytkownika" sprawia, że mamy dużo lepiej postawione wymagania i mniej więcej jasność do czego dążymy.
    Poza tym, tak jak pisze Maciej w komentarzu poniżej, typowe agile podejście – taski poniżej 8h, backlogi, i regularne dema!

  9. Raczej nie ma innej rady w średnich projektach IT, skoncentrowanych wokół internetu, jak zastosowanie waterfalli na poziomie managementu a agile na poziomie wytwarzania produktu. To się ze sobą w żaden sposób nie kłóci, pod warunkiem, że my jako wykonawca jesteśmy w stanie zaplanować projekt na wysokim poziomie a potem tak prowadzić zespół, aby dotrzymał terminów.
    Bardzo istotna jest tutaj uwaga odnośnie oczekiwań klientów – Agile nie da się sprzedać, ani wygrać nim przetargu w Polsce, ale bardzo często zadanie klientowi pytania "jaki jest cel tej aplikacji", "kto jest jej docelowym odbiorcą", "jaka akcja oznacza konwersję użytkownika" sprawia, że mamy dużo lepiej postawione wymagania i mniej więcej jasność do czego dążymy.
    Poza tym, tak jak pisze Maciej w komentarzu poniżej, typowe agile podejście – taski poniżej 8h, backlogi, i regularne dema!

  10. Nie raz zastanawiałem się jaka droga optymalizacji dla tego głównego i podstawowego procesu w firmach IT może być najlepsza. Na pewno tak jak piszesz ważny jest pomost między Biznes vs IT. Człowiek który to spina musi rozmawiać w obu językach, powinien być niesamowitym "mediatorem" i mieć szeroko otwarte oczy na tematy biznesowe jak też technologie, na tyle mocno by nie łykać bajek jak pelikan ze strony biznesu czy zwłaszcza IT 😉 Jeśli chodzi o sam czas wykonywania rękodzieła ze strony IT tutaj można przetestować taką idee – dodanie elementu grywalizacji – zamiast 1 dużego TEAM, dwa mniejsze ale komplementarne. Kto wygra ten dostaje xtra premie. Projekty na pewno zostaną zakończone przed czasem w obu drużynach, ba! oprócz czasu można również premiować lekkość i szybkość kodu (plus dokumentacje), dzięki czemu nie zawsze szybszy team wygrywałby cała pule premiową 😉 Możliwości ustawień grywalizacji dużo.

  11. Nie raz zastanawiałem się jaka droga optymalizacji dla tego głównego i podstawowego procesu w firmach IT może być najlepsza. Na pewno tak jak piszesz ważny jest pomost między Biznes vs IT. Człowiek który to spina musi rozmawiać w obu językach, powinien być niesamowitym "mediatorem" i mieć szeroko otwarte oczy na tematy biznesowe jak też technologie, na tyle mocno by nie łykać bajek jak pelikan ze strony biznesu czy zwłaszcza IT 😉 Jeśli chodzi o sam czas wykonywania rękodzieła ze strony IT tutaj można przetestować taką idee – dodanie elementu grywalizacji – zamiast 1 dużego TEAM, dwa mniejsze ale komplementarne. Kto wygra ten dostaje xtra premie. Projekty na pewno zostaną zakończone przed czasem w obu drużynach, ba! oprócz czasu można również premiować lekkość i szybkość kodu (plus dokumentacje), dzięki czemu nie zawsze szybszy team wygrywałby cała pule premiową 😉 Możliwości ustawień grywalizacji dużo.

  12. Oczywiście tak jest. Na naszym przykładzie, aby dobrze zrozumieć klienta, i aby klient dobrze zrozumiał nas na samym początku drogi bierzemy duży blok, ołówek i zaczynamy wspólnie rysować nasz cel. Oczywiście rysunki rysunkami i bardzo dużo wnoszą, wiele wyjaśniają ale niestety jest tak, że podczas realizacji zawsze coś wyskakuje, zawsze coś zaskoczy jak nie nas to klienta. Okazuje się że na pozór prosta funkcja nie jest już taka prosta, a to co tylko miało służyć do automatycznego wystawiania faktur jest integracją z kilkoma systemami łącznie z sapem i innymi. W sumie to na palcach jednej ręki można policzyć projekty zamknięte stanem pierwotnym specyfikacji. Fakt jest taki że jeśli od początku określimy reguły gry i zasady współpracy, i będziemy ukrócać zapędy klientów to jest realna szansa żeby fjuczery realizować po zakończeniu etapów głównych, lub po zakończeniu projektu. Reasumując. Jeśli uczymy się na błędach to jest duża szansa że każdy kolejny projekt będzie realizowany sprawniej.

  13. Oczywiście tak jest. Na naszym przykładzie, aby dobrze zrozumieć klienta, i aby klient dobrze zrozumiał nas na samym początku drogi bierzemy duży blok, ołówek i zaczynamy wspólnie rysować nasz cel. Oczywiście rysunki rysunkami i bardzo dużo wnoszą, wiele wyjaśniają ale niestety jest tak, że podczas realizacji zawsze coś wyskakuje, zawsze coś zaskoczy jak nie nas to klienta. Okazuje się że na pozór prosta funkcja nie jest już taka prosta, a to co tylko miało służyć do automatycznego wystawiania faktur jest integracją z kilkoma systemami łącznie z sapem i innymi. W sumie to na palcach jednej ręki można policzyć projekty zamknięte stanem pierwotnym specyfikacji. Fakt jest taki że jeśli od początku określimy reguły gry i zasady współpracy, i będziemy ukrócać zapędy klientów to jest realna szansa żeby fjuczery realizować po zakończeniu etapów głównych, lub po zakończeniu projektu. Reasumując. Jeśli uczymy się na błędach to jest duża szansa że każdy kolejny projekt będzie realizowany sprawniej.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *