Projekty w branży IT są zazwyczaj sporym wyzwaniem. Wyzwaniem, które nie spoczywa jedynie na barkach firmy wykonującej, ale również po stronie zleceniodawcy, a co za tym idzie planując prace mamy bardzo wiele czynników na które nie zawsze mamy wpływ. Oczywiście możemy trzymać w ręce bat w postaci harmonogramu. “Jeśli nie dostarczycie X do dnia Y to przesuwamy termin o Z”. Daje nam to pewien poziom bezpieczeństwa, ale czy zawsze wpływa pozytywnie na przebieg projektu, dalszą współpracę, atmosferę, w której codziennie musimy funkcjonować?

Deadline

Z lekkim przymrużeniem oka, można śmiało napisać, że u niektórych klientów wszystkie rozmowy toczą się wokół dwóch słów: deadline i ASAP. Daje nam to wyraźnie do zrozumienia na czym zależy klientowi, a zależy na wykonaniu zadania w terminie, jedynym, najważniejszym i w teorii  nieprzekraczalnym. Jest to pewna stała.

Teraz zastanówmy się na czym nam zależy? Patrząc na model agencyjny w jakim mam okazję się poruszać  mogę stwierdzić, że nam jako wykonawcy, jeszcze bardziej niż klientowi, zależy na jak najszybszym zrealizowaniu założeń, oczywiście z zachowaniem standardów jakościowych.  Co oznacza, że powinniśmy podchodzić do projektów w sposób w którym deadline ustalany przez klienta jest tylko jednym z wyznaczników, które bierzemy pod uwagę planując pracę. Głównym wyznacznikiem dla strony realizującej powinno być ustalenie na kiedy jesteśmy w stanie wykonać projekt, a to mocno zależy od tego w jaki sposób podchodzimy do jego planowania i  realizacji. W projekcie zazwyczaj nie jesteśmy sami. Są całe zespoły odpowiadające za poszczególne elementy układanki i to od naszego podejścia zależy ile w rzeczywistości czasu potrzebujemy.

Dlaczego? Wyjaśnienie jest bardzo proste. W modelu agencyjnym zasoby planowane są krótkoterminowo i zwinnie dostosowywane do aktualnej sytuacji w całym portfelu projektów. Zwinność to słowo klucz w naszej codzienności.

Możliwości

Idąc dalej, rozważmy jakie możliwości mamy przy ustalaniu harmonogramów i weryfikacji terminów. Na te potrzeby musimy przyjąć pewne założenia. Poniżej rozpatrzymy dwie możliwości weryfikacji terminów na podstawie estymacji. W zależności od wyników mogą być niezbędne różne działania, zwiększenie/zmniejszenie zasobów, negocjacje z klientem, czy nawet podjęcie decyzji o przekazaniu informacji, że nie jesteśmy w stanie spełnić części oczekiwań klienta. Jestem zwolennikiem otwartej komunikacji i szukaniu wspólnych rozwiązań. Ukrywanie przed klientem rzeczywistości raczej nie jest dobrą praktyką, chyba, że lubimy ostrą jazdę na krawędzi dobrych relacji.

Harmonogram

Niezależnie od metody jaką wybieramy do przygotowania harmonogramu, niezbędne nam są dane wsadowe: zakres projektu, budżet, backlog, estymacje, zasoby i ich dostępność oraz wstępna analiza zagrożeń. Poszczególne informacje opracowujemy sami, część z nich dostarcza nam zespół lub analitycy, czyli ludzie. To bardzo istotna kwestia, że dane nie są wypluwane przez algorytmy obliczeniowe, a opracowywane przy różnym podejściu i założeniach. Układając poszczególne fragmenty projektu musimy ustalić czym kierowała się osoba, które je dostarczyła. Czy osoba estymująca dodała bufor i jeśli tak to jaki, czy zapoznała się ze wszystkimi znanymi problemami, czy brany był pod uwagę dostępny czas na realizację itd. Kolejny raz pojawia się pytanie, dlaczego ? Dlaczego musimy to analizować, dlaczego nie możemy przyjąć faktu. “Pan Xiński powiedział, że to będzie trwało 150h” i już. Wygodne, ale mało optymalne i w dużej mierze niebezpieczne. Chcemy mieć możliwie dużą pewność, że projekt będzie realizowany bez większych niespodzianek.

Podejście pesymistyczne

Chyba najlepiej znane i najbardziej popularne. Dające względne poczucie bezpieczeństwa, najbardziej chroniące poszczególne jednostki z zespołu, ale jednocześnie rozwlekające projekt. Idealnie wpisuje się w kilka podstawowych problemów występujących w projektach, np.: prawo parkinsona – mówiące o tym, że praca rozszerza się tak, aby wypełnić czas przeznaczony na dane zadanie, prawo studenta no i wszechobecne prawa Murphy’ego.

Jak to wygląda przy planowaniu ?
Pytamy Pana Xińskiego ile czasu zajmie dane zadanie. Pan X myśli: potrzebuję Y czasu na wykonanie, ale dam trochę więcej bo może być problem, no i dodam jeszcze bufor dla bezpieczeństwa, ponieważ jak nie zdąże to szef będzie wściekły i klient niezadowolony. My otrzymujemy wartość estymacji i mamy podobne założenia (tak, my też mamy szefa), dodajemy bufory dla buforów. Teraz jesteśmy bezpieczni, nie ma opcji, żeby się nie udało. A projekt ? Projekt jak to projekt wypełni cały dostępny czas, niezależnie ile by go nie było.

To podejście nazywane ścieżką krytyczną projektu jest pesymistyczne, ale i konieczne, wręcz niezbędne, aby wprowadzić optymizm do naszych projektów.

Szczypta optymizmu, jako przepis na udany projekt

Wprowadzenie optymistycznego podejścia w projektach wymaga wielu zmian, w tym ich akceptacji przez managment firmy oraz zrozumienia ze strony członków zespołu.

Zależy nam na optymalizacji i zwiększeniu efektywności, a więc musimy zebrać wszystkie problematyczne momenty z podejścia pesymistycznego i zastanowić się w jaki sposób je zmodyfikować. W w/w podejściu, możemy wyróżnić następujące problemy:

  • bufory bezpieczeństwa dodawane do zadań przez osoby estymujące,
  • syndrom studenta występujący przy realizacji zadań,
  • prawa Parkinsona i Murphyego.

Zacznijmy od dołu listy, na której znajdują się dwa prawa. Nie mamy na nie większego wpływu, one występują i musimy to zaakceptować, a jedyną możliwością jest zniwelowanie ich skutków. Odpowiedź na pytanie “jak?” znajdziemy rozpatrując sytuację związaną z poszczególnymi zadaniami.

Bufory bezpieczeństwa – nie możemy się obejść bez pewnego zapasu, ale rozpatrując w jaki sposób on powstał i w ilu przypadkach (bo nasz szef dla bezpieczeństwa zapewne jeszcze wydłużył termin realizacji) możemy świadomie i z czystym sumieniem nim zarządzać. Z pomocą przychodzi podejście nazywane łańcuchem krytycznym i jego podstawowym założeniem jest optymizm! Analizując zadania, świadomie decydujemy się na skrócenie ich estymacji o połowę, a pozostały czas kumulujemy na końcu całego projektu jako jeden wspólny bufor dla wszystkich zadań w projekcie. W efekcie suma czasu ze wszystkich zadań wskazuje nam na pewien termin. To data określająca najwcześniejszy termin zakończenia projektu.

Co dalej? Następnie musimy zająć się syndromem studenta. Jest to zjawisko polegające na wzroście efektywności wykonywania pracy wraz z kończącym się czasem przewidzianym na realizację.  Pozbądźmy się przeszkody! Jej występowanie zależy od terminu, a termin jest przypisany do zadania. Nie możemy usunąć zadania, a więc usuńmy finalny termin jego realizacji. Tym sposobem nie dajemy sztywnych ram. Jeśli ktoś skończy zadanie szybciej niż zakładała estymacja, wie za co ma się zabrać w następnej kolejności i wie również, że musi wykonać je najszybciej jak potrafi.

Jak kontrolować realizację projektu?

Podobnie jak w przypadku ścieżki krytycznej, monitorujemy realizację zadań, a jedynym pytaniem jakie musimy zadawać jest: “Kiedy dane zadanie będzie skończone?”. Nie ma konieczności przesuwania harmonogramu, co w przypadku ścieżki występowało przy każdym jednym opóźnieniu. Badamy jedynie zużycie wspólnego buforu.

Gdzie są korzyści?
Oczywisty zysk jest na realizacji zadań z pełną efektywnością członków zespołu, co skraca czas niezbędny na ich zakończenie. Dodatkowo, usuwając bufory zadaniowe optymalizujemy projekt całościowo. Ze statystyk wynika, że realny zysk czasu na projekcie wynosi ok. 20%, a procent projektów dowożonych w terminie wynosi ok. 80% (20% przy innych metodach).

Pozytywnie na koniec

Wykorzystując świadomość problemów z jakimi się mierzymy, możemy nad nimi pracować. Oczywiście w/w podejście może nie sprawdzić się w każdym projekcie lub na każdym jego etapie, ale moim zdaniem lepiej odwzorowuje naturalny przebieg życia projektu. Wymaga pracy z całym zespołem, zrozumienia, jasności sytuacji i zaangażowania, ale w efekcie zysk jest wart włożonej pracy.