Harmonogram prac w umowie wdrożeniowej IT. Poradnik dla software house’ów #17

Harmonogram prac w umowie wdrożeniowej pełni funkcję operacyjną. Najczęściej jest to załącznik do umowy, który wskazuje w jakich terminach mają zostać wykonane poszczególne elementy tworzonego programu komputerowego. Harmonogram może przyjąć dwie postacie. Harmonogram stanowi kluczowy element strukturyzacji procesu developmentu, zapewniający stronom przewidywalność realizacji projektu. W praktyce polskich software house’ów harmonogram często łączy się z wyborem konkretnego modelu kontraktowego (Fixed-Price, Time & Materials lub Dedicated Team) oraz metodyki zarządzania projektem (Waterfall, Agile lub podejście hybrydowe). Harmonogram może mieć charakter niewiążący oraz wiążący.

Artykuł jest częścią serii dotyczącej umowy wdrożeniowej, poniżej znajdziesz odnośniki do pozostałych wpisów. Jeśli, któryś z artykułów nie jest jeszcze podlinkowany, oznacza to, że wpis dotyczący tego zagadnienia pojawi się na blogu w najbliższej przyszłości.

Niewiążący harmonogram prac w projekcie IT

W przypadku harmonogramu prac w umowie wdrożeniowej, który nie ma charakteru wiążącego wszystkie terminy oddania poszczególnych etapów prac – poza terminem końcowym – są terminami instruktażowymi. W przypadku gdy wykonawca przekroczy któryś z tych terminów, nie powinien z tego tytułu ponieść negatywnych konsekwencji. Niewiążący harmonogram prac pozwala stronom umowy wdrożeniowej na zapewnienie sobie pewnej przewidywalności.

Zamów wzór umowy wdrożeniowej IT!

Wiążący harmonogram prac w projekcie IT

Zupełnie inaczej ma się sprawa z harmonogramem prac, który jest wiążący. W tym przypadku każdy termin wpisany do harmonogramu ma charakter wiążący. Oznacza to, że wykonawca będzie odpowiadał za opóźnienie lub zwłokę w jego dotrzymaniu.

W harmonogramie tego typu wykonawcy często próbują zawrzeć klauzulę, która będzie pozwalała im na przesunięcie prac o konkretną liczbę dni.

Harmonogram wiążący jest charakterystyczny dla umów typu Fixed-Price, gdzie całkowity koszt i zakres projektu są ustalone z góry. W takim modelu wykonawca przyjmuje na siebie większe ryzyko związane z realizacją projektu, co często przekłada się na wyższe marże. Software house’y stosujące harmonogramy wiążące powinny rozważyć implementację następujących mechanizmów ochronnych:

1. Bufory czasowe – zgodnie z metodologią Critical Chain Project Management (CCPM), warto strategicznie alokować bufory czasowe. Zamiast dodawać zapasy czasu do każdego zadania, lepiej jest skonsolidować bufory na końcu krytycznych łańcuchów zadań (project buffer) oraz w punktach, gdzie zadania niekrytyczne zasilają łańcuch krytyczny (feeding buffers).
2. Klauzule przedłużenia czasu (Extension of Time – EOT) – pozwalają na formalne przedłużenie terminów w przypadku zdarzeń niezależnych od wykonawcy, takich jak: opóźnienia w dostarczeniu informacji zwrotnej przez klienta, zmiany w zakresie projektu (scope creep), problemy z integracją systemów zewnętrznych czy siła wyższa.
3. Precyzyjne kryteria akceptacji – każdy kamień milowy powinien mieć jasno zdefiniowane, mierzalne i testowalne kryteria akceptacji. Powinny one być sformułowane zgodnie z zasadą SMART (Specific, Measurable, Achievable, Relevant, Time-bound) i koncentrować się na rezultatach, a nie szczegółach implementacji.

W przypadku harmonogramu wiążącego zazwyczaj jego niedotrzymanie wiąże się z koniecznością zapłaty przez wykonawcę kar umownych.

Przy ustalaniu kar umownych za niedotrzymanie terminów w harmonogramie wiążącym należy pamiętać o specyfice polskiego prawa. Zgodnie Kodeksem cywilnym sąd może na żądanie podmiotu obarczonego karą zmniejszyć karę umowną, jeśli jest ona rażąco wygórowana. Dlatego software house’y powinny dążyć do ustalenia kar na poziomie, który stanowi rzeczywiste oszacowanie potencjalnej szkody klienta, a nie ma charakteru czysto represyjnego.

Typowa wysokość kar umownych w branży IT oscyluje między 0,1% a 0,5% wartości umowy za każdy dzień opóźnienia, z zastrzeżeniem maksymalnej łącznej wysokości kar (np. 50% wynagrodzenia za dany projekt).

Powyżej zaznaczyłem, że wykonawca może odpowiadać za opóźnienie lub zwłokę. Musisz wiedzieć, że polskie prawo rozróżnia te dwa pojęcia. Nie są one tożsame, chociaż w mowie potocznej tak może właśnie być.

Niekiedy kodeks cywilny wprost wskazuje kiedy coś należy rozumieć jako opóźnienie a kiedy za zwłokę. Ale są sytuacje, w których umownie możemy wskazać, że wykonawca będzie odpowiadał albo za opóźnienie albo za zwłokę.

Skutki opóźnienia i zwłoki są różne.

1. Z opóźnieniem (zwykłym) mamy do czynienia wówczas, gdy wykonawca nie spełnia świadczenia w czasie właściwym z przyczyn, za które odpowiedzialności nie ponosi. Zamawiający może podjąć kroki prowadzące do przymusowego dochodzenia świadczenia od wykonawcy. Przykładami opóźnień, za które software house nie ponosi odpowiedzialności, mogą być: brak dostępu do środowiska testowego ze strony klienta, opóźnienia w dostarczeniu kluczowych decyzji biznesowych przez interesariuszy, problemy z zewnętrznymi API niezależnymi od wykonawcy, czy też zmiany w przepisach prawnych wymagające modyfikacji rozwiązania. W takich przypadkach wykonawca powinien niezwłocznie poinformować zamawiającego o przyczynach opóźnienia i przedstawić zaktualizowany harmonogram realizacji.
2. Zwłoka jest opóźnieniem kwalifikowanym wykonawcy, czyli wynikłym wskutek okoliczności, za które wykonawca ponosi odpowiedzialność. Opóźnienie nie jest zwłoką tylko wówczas, gdy wykonawca udowodni, że nastąpiło ono z przyczyn, za które odpowiedzialności nie ponosi; zamawiający musi tylko wykazać, że świadczenie nie zostało spełnione w terminie, nie obciąża go natomiast dowód, że przybrało ono postać zwłoki. W takim wypadku zamawiający może się domagać nie tylko spełnienia świadczenia, ale i naprawienia szkody wynikłej ze zwłoki. Kluczowe znaczenie ma tutaj rozkład ciężaru dowodu. To wykonawca musi udowodnić, że opóźnienie nastąpiło z przyczyn od niego niezależnych. Dlatego software house powinien prowadzić szczegółową dokumentację projektową, obejmującą: logi komunikacji z klientem, raporty z postępu prac, dokumentację techniczną identyfikującą problemy i ich przyczyny, protokoły ze spotkań projektowych oraz wszelką korespondencję dotyczącą zmian w projekcie. Taka dokumentacja może okazać się niezbędna przy wykazywaniu braku winy w przypadku opóźnień.

Sprawdź również: Zwłoka a opóźnienie w umowach IT – czym się różnią?

Zapłata wynagrodzenia w częściach

W przypadku gdy harmonogram jest wiążący strony wprowadzają także najczęściej rozliczenie etapowe. To znaczy, że wykonawca otrzymuje wynagrodzenie partiami a nie na sam koniec.

Kodeks cywilny stanowi w takim wypadku, że jeżeli dzieło ma być oddawane częściami, a wynagrodzenie zostało obliczone za każdą część z osobna, wynagrodzenie należy się z chwilą spełnienia każdego ze świadczeń częściowych.

Warto pamiętać, że przepis ten może być dowolnie modyfikowany w umowie wdrożeniowej.

Struktura płatności etapowych powinna być starannie zaplanowana, aby zapewnić równowagę interesów obu stron. Typowy podział płatności w projektach software’owych może wyglądać następująco: 10-20% przy podpisaniu umowy (zaliczka inicjująca projekt); 15-25% po zatwierdzeniu analizy wymagań i specyfikacji funkcjonalnej; 25-30% po dostarczeniu pierwszej wersji funkcjonalnej (MVP lub kluczowych modułów); 25-30% po zakończeniu fazy developmentu i rozpoczęciu testów; 15-20% po pomyślnym zakończeniu testów akceptacyjnych (UAT); 10-20% po wdrożeniu produkcyjnym i przekazaniu pełnej dokumentacji

Każdy etap powinien mieć jasno zdefiniowane kryteria akceptacji. Warto również określić procedurę odbioru, w tym maksymalny czas na zgłoszenie uwag przez zamawiającego (zwykle 5-14 dni roboczych) oraz konsekwencje braku odpowiedzi w tym terminie (domniemanie akceptacji).

Software house powinien również zabezpieczyć się przed ryzykiem związanym z płatnościami etapowymi poprzez zastrzeżenie prawa własności intelektualnej do momentu otrzymania pełnej płatności lub wprowadzenie klauzuli wstrzymania dalszych prac w przypadku zaległości płatniczych przekraczających określony okres (np. 30 dni).

Podsumowując, harmonogram prac w umowie wdrożeniowej to nie tylko narzędzie planistyczne, ale przede wszystkim instrument prawny kształtujący rozkład ryzyka między stronami. Wybór między harmonogramem wiążącym a niewiążącym powinien być poprzedzony analizą charakteru projektu, możliwości dokładnego oszacowania zakresu prac oraz apetytu na ryzyko obu stron. Niezależnie od wybranego modelu, kluczowe znaczenie ma precyzyjne definiowanie terminów, kryteriów akceptacji oraz mechanizmów adaptacji do zmieniających się okoliczności projektu.