Estymacja

Estymowanie

On time, on budget, with a satisfactory result (w wolnym tłumaczeniu: na czas, w budżecie i z satysfakcjonującym rezultatem) – tak brzmi najnowsza definicja sukces projektu według Standish Group – niezależnej międzynarodowej firmy doradczej, założonej w 1985 roku, specjalizującej się w badaniach i publikowanych każdego roku raportach dotyczących projektów wdrażania systemów informatycznych w sektorze publicznym i prywatnym. Wspomniana definicja zmienia nieco dotychczasowe postrzeganie sukcesu projektu, bowiem wcześniejsze raporty Standish Group odwoływały się do “on scope” – w zakresie, co zmieniło się na rzecz “satisfactory result”. Rzeczywiście wiemy, że nie zawsze projekt zrealizowany zgodnie z zakresem jest jednocześnie projektem spełniającym oczekiwania na końcu. Czas trwania projektów oraz nie do końca zdecydowany czego chce czy potrzebuje klient (i mający prawo nie wiedzieć w tak dynamicznie zmieniającym się otoczeniu konkurencyjnym) to czynniki, które ograniczają możliwość zdefiniowania zakresu na tyle precyzyjnie, aby nawet jego pełna realizacja była równoznaczna z satysfakcjonującymi rezultatami, ale o tym kryterium sukcesu innym razem.

Dzisiaj chciałbym się skupić na dwóch pozostałych czynnikach: w budżecie i na czas i tym samym otworzyć cykl czterech artykułów związanych z estymacją w projektach, bo cóż innego jak nie estymacja właśnie przekłada się na dwa powyższe.

W poniższym artykule (część 1.) opowiem czym jest proces estymacji, gdzie jest jego miejsce w całym procesie planowania, jakie dane są potrzebne, aby przeprowadzić proces estymacji oraz na co finalnie estymacja się przekłada. Część 2. dotyczyć będzie technik estymacji. W części 3. opiszę czym jest niepewność, bufor oraz założenie w ramach estymacji, a całą serię zamknie artykuł na temat analizy opóźnień, która – choć rzadko tak jest – powinna być nieodzowną częścią procesu estymacji (część 4.).

Estymacja w procesie planowania

Według Encyklopedii Zarządzania proces estymacji polega na “określeniu przewidywanego czasu trwania poszczególnych zadań projektu, który umożliwia wyznaczenie ram czasowych całego projektu oraz stworzenie harmonogramu projektu.” Krótko mówiąc, estymujemy zadania po to, żeby:

stworzyć harmonogram i określić datę dostarczenia projektu,
móc monitorować postęp prac, chociażby z wykorzystaniem metody EVM, która pozwala na porównanie stanu faktycznego z planowanym w odniesieniu do czasu i kosztów.

Gdybyśmy chcieli spojrzeć na proces estymacji z perspektywy macierzy PMBOK (1), warto podkreślić, że leży on w obszarze wiedzy “Zarządzanie czasem” (ang. Time Management) i jest częścią grupy procesowej “Planowanie”.

Określenie zakresu projektu

Przed rozpoczęciem estymowania zespół, w ramach obszaru wiedzy “Zarządzanie zakresem projektu” (ang. Project Scope Management), ma za zadanie zdefiniowanie zakresu projektu, czyli:

zebranie, uszczegółowienie oraz zrozumienie wymagań projektowych – ich brak lub błędne zrozumienie mogą odbić się boleśnie na późniejszych etapach prac, a z całą pewnością na pierwotnych estymacjach;
dokonanie struktury podziału zadań (ang. Work Breakdown Structure, w skrócie WBS), która poukłada pracę zespołu w łatwiejsze do zarządzania części. Zespół projektowy zaczyna od zdefiniowania najważniejszych funkcji w ramach projektu, a następnie dzieli je na mniejsze, aż do poziomu pojedynczych zadań.
wypracowanie sposobu w jaki będzie zakres prac będzie kontrolowany. Działanie to ma na celu poprawić jakość szacowanego czasu, kosztów i zasobów, wyraźnie rozdzielić odpowiedzialności oraz określić bazowy plan kosztów do pomiaru efektów projektu.

“Dziurawy” zakres może doprowadzić do nieplanowanego wzrostu kosztów w projekcie. Wszystko to, na co nie znajdujemy odpowiedzi w zdefiniowanych wymaganiach, rodzi pole do interpretacji, a często też do konfliktu z klientem. Zwiększa też prawdopodobieństwo dostarczenia projektu, który nie przyniesie satysfakcjonujących rezultatów. W tym temacie przypomina mi się popularny w sieci rysunek:

wymagania klienta

Takie niespodzianki w zakresie prowadzą też do zakłócenie rytmu projektu, niepotrzebnego dublowania pracy zespołu, osłabienia morale pracowników, a co za tym idzie – obniżenia ich efektywności i zaangażowania. Finalnie może doprowadzić do przekroczenia ustaleń zawartych w kontrakcie. Znacie to skądś? :)

Ok, zakres już mamy – przyjmijmy, że bez dziur ;) Mamy zdefiniowanie działania do wykonania oraz znamy ich kolejność. Pozostaje nam teraz estymacja – proces wcale niełatwy. O technikach estymacji i pułapkach tego procesu opowiem w części 2. Dzisiaj przedstawię, co na estymację może mieć wpływ niezależnie od przyjętej techniki:

doświadczenie osób dokonujących estymacji – im mniej doświadczona osoba, tym czasochłonność zadania będzie większa, niemniej koszt powinien pozostać na podobnym poziomie (dłuższy czas wykonania zadania, ale za niższą stawkę);
rozumienie zakresu – jest to poniekąd związane z punktem poniżej, ale również odnosi się do tego “co” będziemy wykonywać, czyli na estymację wpłynie nie tylko sposób realizacji zadania, ale ogólne rozumienie tego, co mamy do zrobienia – im bardziej nieprecyzyjna specyfikacja, tym większe pole do interpretacji;
przyjęte do estymacji założenia – jaki poziom “skomplikowania” zadania zakładamy, jakie mamy kryteria akceptacji, co rozumiemy przez wykonanie zadania oraz “jak” zamierzamy zadanie wykonać – pewnie z własnych doświadczeń wiecie, że każde zadania wykonać można na wiele sposobów;
nasza natura – optymiści podają mniejszą czasochłonność zadań niż pesymiści;
doświadczenia z poprzednich projektów – jeśli nic się “nie wysypało”, będziemy szacować bardziej optymistycznie, jeśli jednak mieliśmy sporo turbulencji, estymacje będą bardziej ostrożne – nauczeni doświadczeniem, będziemy się asekurować;
świadomość ryzyk – im większa świadomość zagrożeń, tym mniej optymistyczne estymacje, stąd dobrą praktyką jest podanie optymistycznej (założenie, że znane nam zagrożenia się nie zmaterializują) i pesymistycznej estymacji (założenie, że znane nam zagrożenia się zmaterializują) oraz przyjęcie średniej z nich.

Moim ulubionym, choć nie projektowym przykładem jest prosta czynność sprzątania mieszkania – spróbujcie ją oszacować i porównać wymagania oraz kryteria akceptacji z Waszymi drugimi połówkami ;) Na tym przykładzie doskonale zobaczycie jak bardzo można się różnić w rozumieniu – wydawać by się mogło prozaicznego – zadania.

Harmonogram projektu

Gotowe estymacje wraz z sekwencją zadań są “wsadem” do harmonogramu. Oczywiście do jego wykonania potrzebnych jest jeszcze kilka innych elementów jak np. dostępność zasobów oraz ich alokacja, poprzedniki / następniki, godziny pracy czy kalendarz dni ustawowo wolnych, niemniej bez estymacji z harmonogramem ani rusz.

Sam harmonogram, oprócz informacji o spodziewanej dacie zakończenia projektu, daje nam możliwość śledzenia postępów oraz konfrontowanie planu z rzeczywistością. Jest to rodzaj kalendarza projektowego, w którym widzimy jakie zadania kiedy powinny być wykonane.

Podsumowanie

Estymowanie na pierwszy rzut oka wydaje się zadaniem nieskomplikowanym, jednak kryje wiele obszarów, które mogą być problematyczne, szczególnie, gdy mowa jest o dużych i złożonych projektach. Choć prawie niemożliwym jest stworzenie planu idealnego, z estymacjami, które nie ulegną zmianie, możemy przynajmniej próbować, aby odchylenia od planu nie były duże, nie tylko poprzez celniejsze estymowanie, ale również przez bieżące monitorowanie i wczesne reagowanie.

W kolejnej części cyklu przedstawię techniki estymacji, które mogą okazać się pomocne, gdy przyjdzie Wam zmierzyć się z tym zadaniem.

(1) Obszary Wiedzy wraz z Grupami Procesów tworzą tzw. macierz PMBOK, gdzie – wzdłuż górnej krawędzi znajdują się Grupy Procesów, a wzdłuż lewej krawędzi – Obszary Wiedzy. W polu, w którym krzyżują się te dwie osie zobaczyć możemy zmapowane procesy, na przykład na skrzyżowaniu obszaru wiedzy “Zarządzanie integracją” i grupy procesowej “Inicjowanie” leży proces “Opracowanie karty projektu”. Każdy obszar wiedzy składa się z zestawu procesów, z których każdy zawiera dane wejściowe, narzędzia i techniki oraz rezultaty. Wszystkie te procesy razem zapewniają sprawne zarządzanie projektami i przyczyniają się do ich sukcesu.