Rentowność projektów w firmie IT

Firma IT sprzedaje godziny wysoko wykwalifikowanych ludzi. Wynagrodzenia są głównym kosztem i trzeba je płacić niezależnie od tego, czy zespół ma projekt. Dlatego rentowność zależy tu nie tylko od cen, ale od tego, jak dokładnie firma szacuje pracę i jak szczelnie wypełnia kalendarze. Jak wygląda organizacja całej firmy, opisuje strona dla firm IT i software house'ów.

Dwa modele, dwa rodzaje ryzyka

Cecha	Stała cena	Rozliczenie za czas
Co sprzedaje firma	Wynik: działający system o opisanym zakresie	Czas zespołu o określonych umiejętnościach
Kto ponosi ryzyko zakresu	Wykonawca	Klient
Skąd bierze się zysk	Z różnicy między wyceną a rzeczywistym nakładem	Z różnicy między stawką a kosztem godziny
Co niszczy marżę	Niedoszacowanie, rozrost zakresu, poprawki	Przerwy między projektami, niesprzedane godziny, presja na stawki
Co trzeba mierzyć	Godziny faktyczne wobec wycenionych, na bieżąco	Wykorzystanie czasu każdej osoby

Gdzie znikają godziny

• Wycena optymistyczna. Liczona dla najlepszego scenariusza, bez integracji, testów i wdrożenia.
• Drobne prośby. „To tylko jeden przycisk”. Po trzydziestu takich przyciskach projekt jest o miesiąc dłuższy.
• Niejasne wymagania. Praca wykonana dwa razy, bo klient miał na myśli coś innego.
• Czekanie na klienta. Zespół stoi, bo brakuje decyzji, dostępów albo treści.
• Poprawki po oddaniu. Naprawiane w ramach gwarancji.
• Przerwy między projektami. Tydzień lub dwa bez zlecenia dla części zespołu.
• Przełączanie się. Programista pracujący nad trzema projektami naraz traci czas na powroty do kontekstu.
• Sprzedaż. Godziny ekspertów poświęcone na wyceny i warsztaty.

Scenariusz: projekt oddany w terminie

Scenariusz jest zmyślony. Software house z trzydziestoma osobami zrealizował dla sieci przychodni system rejestracji pacjentów w stałej cenie. Projekt wyceniono na tysiąc dwieście godzin. Oddano go w uzgodnionym terminie, klient był zadowolony, a zarząd uznał zlecenie za wzorcowe.

Pół roku później dyrektor finansowy zestawił zapisany czas pracy. Zespół przepracował w projekcie tysiąc dziewięćset godzin. Termin dotrzymano kosztem nadgodzin i dołożenia dwóch osób w ostatnich tygodniach. Do tego dwieście godzin poprawek w okresie gwarancji. Przy rzeczywistym nakładzie projekt, który miał przynieść solidną marżę, zamknął się w okolicach zera.

Źródła nadwyżki były trzy. Integracja z programem laboratoryjnym klienta, którą wyceniono bez sprawdzenia dokumentacji. Kilkadziesiąt drobnych zmian zgłoszonych przez pracowników przychodni podczas testów i wykonanych bez dyskusji. Moduł raportów, o którym w umowie było jedno zdanie, a który klient rozumiał znacznie szerzej.

Firma wprowadziła cotygodniowe porównanie godzin przepracowanych z planem dla każdego projektu o stałej cenie. Przekroczenie budżetu etapu o ustalony próg uruchamia rozmowę kierownika projektu z opiekunem klienta. Integracje z cudzymi systemami są wyceniane dopiero po płatnej analizie technicznej.

Liczby, które trzeba znać

1. Pełny koszt godziny dla każdej roli, z uwzględnieniem godzin niesprzedanych.
2. Wykorzystanie czasu: godziny zafakturowane wobec dostępnych.
3. Godziny faktyczne wobec wycenionych w każdym projekcie, co tydzień.
4. Wartość zmian zgłoszonych, zafakturowanych i wykonanych bez faktury.
5. Godziny gwarancyjne przypisane do projektów.
6. Wynik projektu po zamknięciu i po okresie gwarancji.
7. Wynik na kliencie w dłuższym okresie, ze wszystkimi projektami i utrzymaniem.
8. Obłożenie na kolejne miesiące wobec podpisanych i prawdopodobnych umów.

Ogólny sposób liczenia wyniku zlecenia opisuje artykuł rentowność zlecenia: jak ją liczyć.

Jak poprawić wynik bez podnoszenia stawek

• Płatna analiza przed wyceną. Zmniejsza niedoszacowanie i odsiewa klientów bez budżetu.
• Wycena w przedziale. Z listą założeń i ryzyk, zamiast jednej liczby.
• Etapy. Krótsze odcinki o stałej cenie, po których zakres jest przeglądany.
• Rejestr zmian. Każda prośba spoza zakresu ma opis, wycenę i decyzję klienta.
• Baza zakończonych projektów. Rzeczywisty nakład na podobne moduły jako podstawa kolejnych wycen.
• Planowanie przejść. Rozmowa o kolejnym projekcie dla zespołu na miesiąc przed końcem bieżącego.
• Umowy utrzymaniowe. Stały przychód wypełniający przerwy i porządkujący poprawki.
• Mniej projektów na osobę.

Rentowność a sprzedaż

Dane o wynikach projektów powinny wracać do osób, które wyceniają i sprzedają. Bez tego firma powtarza te same błędy: wciąż zaniża integracje, wciąż godzi się na niejasne zapisy o raportach. Kwartalne spotkanie, na którym sprzedaż i kierownicy projektów oglądają razem pięć zakończonych zleceń, uczy więcej niż jakiekolwiek szkolenie z szacowania. Informacja o obłożeniu z kolei mówi sprzedaży, kiedy i jakich projektów szukać.

Narzędzia

Minimum to zapis czasu przypisany do projektu i etapu oraz zestawienie z budżetem. Programy do zarządzania projektami zwykle to umożliwiają. Trudniej o jedno miejsce, które łączy sprzedaż, planowanie zespołu, czas i faktury, tak żeby obłożenie i wynik były widoczne bez ręcznego składania raportów. Jakie moduły do tego służą, opisuje przewodnik ERP dla firmy, a jak pokazać te liczby na jednym ekranie artykuł dashboard dla właściciela firmy. O ograniczaniu czasu ekspertów poświęcanego na wyceny piszemy na stronie CRM dla firm IT i software house'ów. Pozostałe tematy są w bazie wiedzy.