Dlaczego wyceny projektów IT tak bardzo się różnią?

Dlaczego dwa software house'y mogą wycenić ten sam projekt IT z różnicą nawet 100 tysięcy złotych? Albo obiecać realizację w 3 miesiące, gdy w praktyce zajmie to co najmniej rok? Pokażę Ci dziś 4 nieoczywiste rzeczy prosto z mojego doświadczenia, które mają ogromny wpływ zarówno na koszt jak i na termin i o których rzadko się mówi wprost podczas etapu wyceny. Wyobraź sobie, że masz na biurku 3 oferty. Każda jest od innego software house'u. I teraz pytanie, w jaki sposób je porównać? I w ogóle, co wziąć pod uwagę, żeby je porównać?

Jak porównać oferty software house przy wycenie projektu IT

Pierwsza, podstawowa kwestia, na którą najprawdopodobniej zwrócisz uwagę, to sposób rozliczenia. Software house'y stosują z reguły 2 najpopularniejsze modele.

• Time and material - to model, w ramach którego rozliczamy się za przepracowane godziny.
• Fixed price - to model, w ramach którego firma deklaruje to, że przygotuje pełny zakres projektu i według tego zakresu podaje ci wycenę. Już nazwijmy to wycenę końcową.

Na pierwszy rzut oka wygląda to jak proste porównanie.

Mamy jedną wycenę, mamy drugą i trzeba zwyczajnie porównać ceny. Natomiast w praktyce okazuje się, że to dopiero początek pytań. Prawdziwy koszt zależy od tego, jak projekt będzie się zmieniał w trakcie realizacji.

A nie ma co się oszukiwać. W średnich i dużych projektach IT zmiany zawsze będą. I tu dochodzimy do sedna.

Jak przewidzieć, czy wycena, którą otrzymałeś, ma cokolwiek wspólnego z tym, co otrzymasz na końcu, z finalnym kosztem projektu? Proces przygotowania ofert to według mnie kluczowy punkt, który znacząco wpływa na to, czy wycena, którą otrzymaliśmy na początku, będzie faktycznym kosztem, w którym nasz projekt IT zostanie zrealizowany.

4 czynniki, które najbardziej wpływają na wycenę projektu IT

80% zapytań, które do nas wpada, wygląda w bardzo podobny sposób. Witam, jesteśmy firmą X, planujemy wdrożyć system Y. W załączeniu przesyłamy specyfikację, prosimy o wycenę.

I teraz co robią firmy? Software House z reguły dzwoni, dopytuje o kilka rzeczy:

• o wielkość firmy,
• o liczbę użytkowników,
• jakie systemy już są w firmie,
• w jakiej technologii zostały napisane.

I to są oczywiście sensowne pytania. Ale czy wystarczą, żeby wycenić projekt rzetelnie? Z mojej perspektywy i doświadczenia, absolutnie nie.

1. Analiza projektu IT przed przygotowaniem wyceny

Wycena samej specyfikacji, którą otrzymamy od klienta, to oczywiście jedna z rzeczy. Ale jeśli w specyfikacji pominiemy integrację z innymi systemami, nie zmapujemy kluczowych procesów, które w firmie się dzieją, nie zastanowimy się, które z tych procesów działają dobrze, a które już na etapie procesów trzeba zmienić, to i tak to wyjdzie, tylko, że w trakcie realizacji. I to właśnie wtedy okazuje się, że projekt, który miał kosztować te tytułowe 100 tysięcy, finalnie kosztuje 200.

Proces przygotowania oferty, to jak planowanie podróży. Z Wrocławia do Gdańska samochodem dojedziesz w 5 godzin. Rowerem? No, już zmienia się to. Co najmniej w kilkanaście. A jeśli planujesz przystanki po drodze, to potrwa to oczywiście jeszcze dłużej. I tak samo jest z projektami IT. Jeśli nie uwzględnisz wszystkich przystanków i nie wybierzesz właściwego środka transportu, to prognoza czasu i kosztów będzie kompletnie nietrafiona. Im większy projekt realizujemy, tym dokładniejsza powinna być ta praca planowania podróży, czyli ta praca przed wyceną.

2. Dobór technologii i koncepcji systemu IT

Druga kwestia, to dobór technologii i koncepcji projektu. W IT jest tak, że do jednego problemu biznesowego można podejść na wiele różnych sposobów. Można na przykład wykorzystać oprogramowanie tak zwane SaaSowe, czyli dostępne w formie abonamentowej. Można wykorzystać oprogramowanie open source'owe. Można też napisać oprogramowanie dedykowane zupełnie od podstaw. Co ciekawe, można też w ramach czwartej koncepcji w jakiś sposób połączyć te różne oprogramowania ze sobą, tworząc jeden spójny system składający się właśnie z kilku różnych klocków. I teraz każdy z tych wariantów oczywiście ma swoje plusy i minusy i zupełnie inne koszty początkowe oraz te długoterminowe.

Weźmy sobie na przykład platformę B2B, która w modelu SaaS będzie na start znacznie tańsza niż budowa dedykowanego systemu. Ale jeśli w twoim biznesie często wprowadzasz zmiany, to szybko zauważysz, że każda modyfikacja jest kosztowna i ograniczona. Dużo trudniejsza do wdrożenia niż w przypadku rozwiązań otwartych, tak zwanych open source'owych, czy dedykowanych, napisanych w 100% pod ciebie. Więc koniec końców trzeba brać pod uwagę nie tylko samą cenę, ale przede wszystkim to, z jaką koncepcją przychodzi dany software house. Z jakim rozwiązaniem na twój problem biznesowy. I porównanie oferty także na poziomie tego, jakie mają wady i zalety owe koncepcje.

Bo nie chodzi tu tylko o koszty takie tu i teraz, czyli te bieżące i samo powiedzmy wdrożenie, tylko ważne są też koszty w perspektywie dwóch, trzech lat, czyli już od etapu tego wdrożenia. I to, co wydaje się na początku tańsze, w długim terminie może okazać się znacznie droższe, przez ograniczenia, różne trudne modyfikacje, czy konieczność zwyczajnej późniejszej migracji z tej platformy, którą mamy, na jakąś nową w przyszłości.

3. Skład zespołu projektowego w software house

Kolejna sprawa i stosunkowo często niebrana pod uwagę to skład zespołu. Często software house'y pokazują różne case study, które są bardzo podobne do projektu, który chcesz zrealizować. I od razu pojawia się myśl, skoro dany software house zrobił to już wcześniej, to u nas przecież też dadzą radę. Ale i tu należy zadać kilka dodatkowych pytań.

1. Po pierwsze, czy osoby, które realizowały ten konkretny projekt będą też w twoim zespole? Case study tego niestety nie gwarantuje.
2. Po drugie, kto będzie dokładnie w twoim zespole? Czy będą to tylko programiści, czy także testerzy i być może project manager?

Dlaczego wspominam o tych dwóch konkretnych rolach? Bo one bardzo mocno wpływają na wycenę. Jeżeli nie ma tych osób, nie ma tego project managera czy testera, oferta zwyczajnie będzie tańsza, cena będzie niższa. Ale brak tych osób w projekcie oznacza zwyczajne kłopoty. Mogą pojawić się problemy komunikacyjne. Zadania mogą wracać z błędami, bo nikt ich nie przetestował. I wtedy o ten proces jakości i organizację projektu te obowiązki będą spadały na ciebie, klienta. Tyle, że ty masz milion innych spraw na głowie i IT jest tylko jednym z wielu wątków. Więc to na to bym tutaj zwrócił uwagę, jeżeli chodzi o kwestię zespołu.

4. Zakres projektu IT i podejście do priorytetów

Czwarta kwestia to podejście do priorytetów i zakresu projektu. Czy ktoś doradza wam konkretne priorytety realizacji zadań i ograniczenie zakresu prac na start? Tak, żeby jak najszybciej zweryfikować z rynkiem, z użytkownikami końcowymi, czy też zespołem, który faktycznie będzie z tego rozwiązania korzystał. Bardzo często na etapie wycen zakres jest sztucznie podbijany. No bo umówmy się, im większy zakres, który jest zlecony na raz, tym większy projekt, no i wyższa też wycena jego realizacji. Natomiast w IT najlepsze projekty realizuje się małymi krokami. Krok po kroku, etapami. Jeżeli ktoś na etapie wyceny nie przewiduje tego, że można by zrobić najpierw jakąś rzecz A, potem zrobić rzecz B, a potem rzecz C i wdrażać je też w takiej kolejności produkcyjnie, no to myślę, że też zastanowiłbym się nad tym, czy to na pewno będzie najlepsza oferta.

Jak powinna wyglądać rzetelna wycena projektu IT

Wycena projektu na podstawie samej specyfikacji nigdy nie będzie rzetelna, jeśli nie weźmie się pod uwagę tych czterech dodatkowych czynników. Dobra wycena wcale nie jest prosta. Czasem trzeba przeprowadzić kilka solidnych rozmów, a czasem nawet pojechać do firmy i sprawdzić jak coś wygląda w praktyce, żeby podać rzetelną kwotę i rzetelny szacunek czasowy, czyli tym lepiej tą przyszłość przewidzieć. I dlatego upewnij się, że rozmawiasz z dostawcą o ryzykach i etapach projektu, a nie tylko o końcowej cenie czy samej specyfikacji.