Estymata projektu IT – po co?

Estymata projektu IT ma na celu uzyskanie odpowiedzi na pytanie: ile dany projekt będzie kosztować i jak dużo czasu zajmie jego implementacja. Po co software house estymują projekty, skoro wiemy, że nie ma możliwości, żeby ta estymata była dokładna (skąd? Zerknij tutaj)?

Cel estymaty

Zasadniczo jest jeden powód. Banalny i oczywisty, estymata projektu jest niezbędna do podjęcia przez klienta decyzji biznesowej. Koniec. Klient musi wiedzieć jakiego rzędu to będzie koszt, by móc ocenić zasadność biznesową projektu. Estymata jest niezbędna, by móc obliczyć możliwe ROI (wskaźnik zwrotu z inwestycji). Jest ona również niezbędna, jeśli firma ma alternatywny projekt do realizacji i musi podjąć decyzję, który z nich będzie bardziej opłacalny. Jest punktem wyjścia dla rozważań, czy dany projekt realizować. Może się okazać, że z punktu widzenia finansowego projekt opłaca się realizować, ale trafi on na rynek w niekorzystnej dla klienta luce czasowej i nie przyniesie oczekiwanego zysku. Estymata powinna być również dla klienta punktem wyjścia do poszukiwania optymalizacji rozwiązania, które chce wdrożyć, celem uzyskania jak najwyższego ROI.

Główne problemy związane z estymatami zostały opisane w innym wpisie, przywołanym w pierwszym akapicie tego artykułu. W tym miejscu chciałabym się na chwilę zatrzymać nad tym, skąd te problemy się biorą. Widzę kilka głównych obszarów problemowych, które jednak dość silnie ze sobą korelują:

• Niezrozumienie przez klienta, czym jest estymata. Estymatę można porównać raczej do prognozy pogody niż do cennika w sklepie lub u fryzjera. Estymata jest prognozą, nie zobowiązaniem. Synoptycy przygotowują prognozy pogody nawet na 45 dni do przodu, ale traktujemy je z dużą dozą rezerwy. Myślimy raczej: jest szansa, że długi weekend będzie słoneczny, ale nie traktujemy tego jako pewnik. Zauważyłam, że bardzo dużym problemem jest to, że niemal zawsze klienci traktują estymatę jako zobowiązanie software housu, że zakupione przez nich rozwiązanie będzie miało dokładnie taką cenę, jak wyestymowano. Traktują ją jako coś pewnego i niezmiennego, mimo tak wielu niewiadomych i zmiennych. Ba, czasem klient sam nie do końca wie jaki kształt powinien mieć dany projekt, jakie chce mieć funkcjonalności i jak powinny one działać, ale oczekuje, że dostarczona estymata nie zostanie przekroczona nawet o godzinę.
• Nieodpowiednia komunikacja estymaty przez software house. Może być też tak, że to, jak estymatę zrozumie klient, jest pochodną tego, w jaki sposób software house ją zakomunikuje. O co chodzi? Jeśli osoba odpowiedzialna za kontakt z klientem na etapie sprzedaży projektu powie klientowi, że dany projekt będzie kosztował około 100 tysięcy, nie tłumacząc zbytnio jakie elementy stanowią zagrożenie dla wyceny, jaki jest margines błędu wynikający ze stożka niepewności typowego dla projektów IT w tej fazie, czy jakie można przyjąć strategie ograniczające ryzyko przesunięcia się estymaty do górnej granicy stożka niepewności, to oczywiste jest, że klient potraktuje to jako pewnego rodzaju wyznacznik i będzie zaskoczony, że finalnie jest zobowiązany zapłacić np. 150 tysięcy za projekt wyceniony na 100 tysięcy. Szczególnie klient, który nie ma dużego doświadczenia w realizacji projektów IT i nie wie jakie czynniki wpływają na wycenę.
• Brak transparentności i zaufania w relacji klient — dostawca. Dostawca chce sprzedać swoje usługi, a klient chce zrealizować projekt na jak najkorzystniejszych dla siebie warunkach. Ta pozorna sprzeczność interesów często prowadzi do pomijania niezbyt wygodnych aspektów, by każda ze stron mogła ugrać jak najwięcej. Niemniej, gdyby tak stanąć frontem do jednej bramki i wyłożyć karty na stół, obie strony mogłyby zyskać znacznie więcej. Krótki przykład. Otwartość klienta odnośnie do budżetu, którym dysponuje, mogłaby się przełożyć na optymalny dobór strategii realizacji projektu. Jeśli estymata jest znacznie wyższa niż budżet, którym w danym czasie dysponuje klient, możliwe jest na tym etapie opracowania takiego rozwiązania, które zaspokoi potrzeby klienta. Np. skorzystać z buforu funkcjonalności lub rozważyć alternatywne, tańsze do implementacji integracje. Można też przygotować warianty wyceny zawierające różny zakres funkcjonalności wdrażanych w ramach MVP. Kolejnym rozwiązaniem mogłaby być optymalizacja produktu. Jednym z narzędzi służących do tego celu jest model kano. Z jego pomocą sprawdza się, które funkcjonalności faktycznie będą wartościowe dla użytkownika końcowego. Z kolei, jeśli software house nie ukrywa, że estymata to nie koniecznie około 100 tysięcy, ale w skrajnym przypadku projekt może kosztować nawet 160 tysięcy to klient będzie przygotowany na to, że być może będzie potrzebował większego finansowania, by móc zrealizować ten projekt. Dlaczego może to być aż 160 tysięcy? Zbadano, że w praktyce, na tym etapie niewiedzy o projekcie i produkcie, końcowy koszt projektu może wynosić nawet do 160-170% wartości estymowanej. Klient, mając świadomość tego, będzie mógł zdecydować, że w związku z ryzykiem poniesienia wyższych kosztów chce w fazie MVP zredukować zakres funkcjonalności lub poszuka już na tym etapie dodatkowego finansowania. Wariantów jest mnóstwo, ale mogą być brane pod uwagę tylko i wyłącznie, jeśli na stół wyłoży się wszystkie karty. Szczerość, otwartość i transparentność to jedne z najważniejszych aspektów budowania zaufania. Zaufanie, którym obdarzył nas klient, może wielokrotnie zaprocentować w przyszłości czy to kolejnymi wspólnie realizowanymi projektami, czy też poleceniem naszych usług innym. Nie wspomnę już o inne jakości współpracy z takim klientem.

Podsumowanie

Mam wrażenie, że wszystko, w tym wątku sprowadza się do… komunikacji. To, co i jak powiemy, może być prawdziwym game changerem.