W skrócie: porażka projektu IT to w sensie prawnym spór o to, która strona nie wykonała swoich obowiązków z umowy. Najważniejsze zasady:
- Za niewykonanie umowy odpowiada przede wszystkim dostawca, również za błędy swoich programistów i podwykonawców, tak jak za własne.
- Klient odpowiada wtedy, gdy nie współdziała z dostawcą, czyli: nie dostarcza wymagań, danych i dostępów albo nie dokonuje odbiorów.
- Kierownik projektu zatrudniony na etacie odpowiada tylko wobec pracodawcy, a wobec klienta za jego błędy odpowiada ten, kto go zatrudnia.
- O wyniku sporu decydują dokumenty: protokoły odbioru, korespondencja stron, zgłoszenia przeszkód, a czasami biegły sądowy.
Twoja firma podpisała umowę na wdrożenie systemu. Po dziewięciu miesiącach budżet projektu IT jest przekroczony o 40%, harmonogram przesunął się o kwartał, a moduł integracji nadal nie przechodzi testów. Dostawca twierdzi, że nie dostał na czas specyfikacji. Twój zespół odpowiada, że kierownik projektu po stronie dostawcy nie zgłosił żadnego ryzyka. Zarząd pyta, kto za to zapłaci.
Odpowiedź rzadko brzmi „wszyscy” albo „nikt”. O wszystkim rozstrzyga umowa, kilka przepisów Kodeksu cywilnego i to, co obie strony udokumentowały w trakcie projektu. Artykuł pokazuje, jak wygląda ten podział z perspektywy zamawiającego i dostawcy.
Sprawdź: Umowa wdrożeniowa IT
Porażka projektu IT to spór o umowę, nie o metodykę
Za porażkę projektu IT odpowiada ta strona, która nie wykonała swoich obowiązków z umowy albo wykonała je nienależycie. Odpowiedzialność jest ponoszona w zakresie, w jakim uchybienie spowodowało szkodę.
Przepisy prawa cywilnego nie znają pojęcia „porażka projektu”. Znają za to niewykonanie lub nienależyte wykonanie umowy. Zarządzanie projektem IT to obszar menedżerski, ale w sporze sąd nie oceni, czy zespół pracował w Scrumie, czy w modelu kaskadowym (waterfall). Oceni, kto czego nie zrobił w terminie i czy miało to wpływ na wynik.
Prawna analiza przyczyn porażki projektu zawsze sprowadza się do trzech pytań:
- Jaki był przedmiot umowy: rezultat (dzieło) czy staranne działanie (usługa)?
- Kto był dłużnikiem konkretnego obowiązku: Dostawca czy Zamawiający?
- Czy uchybienie da się udowodnić dokumentami z projektu?
Przyczyny niepowodzenia projektu IT opisywane w literaturze zarządczej, takie jak źle zebrane wymagania, bierny sponsor czy nierealny budżet, mają znaczenie prawne o tyle, o ile da się je przypisać jednej ze stron. Niepowodzenie wdrożenia systemu, za którym stoją błędy obu stron, kończy się zwykle podziałem odpowiedzialności, a nie wygraną jednej z nich. Odszkodowanie zmniejsza się wtedy stosownie do tego, w jakim stopniu poszkodowany przyczynił się do szkody (art. 362 KC).
Dostawca odpowiada za zespół i podwykonawców jak za siebie
Dostawca odpowiada wobec Zamawiającego za całość prac, również za błędy programistów, testerów i podwykonawców, którymi się posługuje.
Wynika to z art. 474 KC: dłużnik odpowiada za działania i zaniechania osób, z których pomocą wykonuje zobowiązanie, jak za własne. Odpowiedzialność zespołu za projekt IT jest więc w relacji z klientem odpowiedzialnością Dostawcy. Zamawiający nie musi wskazywać, który programista popełnił błąd. Wystarczy wykazać, że prace wykonano nienależycie. Co więcej, przy odpowiedzialności kontraktowej wina Dostawcy jest domniemana. To powoduje, że Dostawca musi wykazać, że opóźnienie lub wada wynikły z okoliczności, za które nie odpowiada.
Zakres tej odpowiedzialności zależy od kwalifikacji umowy:
- Umowa o dzieło (art. 627 KC): Dostawca zobowiązuje się do konkretnego rezultatu, np. działającego systemu zgodnego ze specyfikacją. Brak rezultatu oznacza niewykonanie umowy, nawet przy dużym nakładzie pracy.
- Umowa o świadczenie usług (art. 750 KC): Dostawca zobowiązuje się do starannego działania, np. w modelu time & material (rozliczenie za czas pracy). Odpowiada za niestaranność, a nie za to, że produkt nie powstał.
Miarą staranności jest zawodowy charakter działalności Dostawcy. Od software house’u wymaga się wiedzy, w tym umiejętności rozpoznania ryzyk i ostrzeżenia klienta, zanim ryzyko się zmaterializuje.
Ogólnej oceny sytuacji nie ułatwia to, że umowy wdrożeniowe bywają umowami mieszanymi: zaprojektowanie i zbudowanie systemu podlega przepisom umowy o dzieło, ale utrzymanie podlega przepisom o usługach, a korzystanie z oprogramowania podlega jeszcze innym przepisom, tj. o licencji.
Warto też zadbać o umowy IT, które określają obowiązki stron, odpowiedzialność i procedurę odbiorów.
Wewnętrzna odpowiedzialność zespołu projektowego to osobna kwestia. Dostawca, który zapłacił Zamawiającemu odszkodowanie, może dochodzić zwrotu od pracownika lub współpracownika B2B. Dla Zamawiającego ta kwestia nie ma jednak znaczenia, bo jego szkody ma naprawić Dostawca.
Zobacz również: Ile kosztuje pomyłka programisty i kto za nią zapłaci?
Klient odpowiada za porażkę, gdy nie współdziała z dostawcą
Zamawiający odpowiada za niepowodzenie projektu wtedy, gdy nie wykonuje obowiązku współdziałania z Dostawcą.
Art. 354 § 2 KC nakłada na wierzyciela obowiązek współdziałania przy wykonaniu zobowiązania. W projekcie IT oznacza to zadania, których Dostawca nie przejmie za Zamawiającego:
- przekazanie wymagań biznesowych i ich akceptacja w umówionym terminie;
- dostęp do środowisk, danych testowych i systemów, z którymi trzeba się zintegrować;
- udział ekspertów dziedzinowych w warsztatach i testach akceptacyjnych;
- terminowe decyzje właściciela biznesowego projektu IT, np. członek zarządu musi rozstrzygać sporne kwestie lub podejmować decyzje w umówionym czasie;
- dokonywanie odbiorów w terminach z harmonogramu.
Aktywne współdziałanie jest jednak wymagane tylko wtedy, gdy wynika z umowy lub z właściwości zobowiązania. Dlatego katalog obowiązków Zamawiającego musi być wpisany do umowy wprost.
Brak współdziałania Zamawiającego skutkuje głównie tym, że ewentualne dochodzenie odszkodowania od Dostawcy będzie utrudnione albo wręcz niemożliwe. W takiej sytuacji Dostawca nie popada bowiem w zwłokę, bo niedotrzymanie terminów nie wynika z okoliczności, za które on odpowiada. Jeśli zastrzegłeś kary umowne za zwłokę, to nie będziesz mógł ich skutecznie dochodzić, bo niedotrzymanie terminu nie wynika z winy Dostawcy, którego blokuje brak decyzji po stronie Zamawiającego.
Ponadto odmowa czynności, bez której zadanie Dostawcy nie może być wykonane, to zwłoka Zamawiającego. Dostawca może żądać naprawienia wynikłej stąd po jego stronie szkody. Przykładowo, Dostawca ma przestój i nie zarabia na czynnościach, gdyż nie może ich podjąć ze względu na brak decyzji Zamawiającego. Przy umowie o dzieło może też wyznaczyć Zamawiającemu termin do podjęcia decyzji, a po jego bezskutecznym upływie odstąpić od umowy (art. 640 KC). Jeśli był gotów wykonać dzieło, a przeszkoda leżała po stronie Zamawiającego, zachowuje prawo do wynagrodzenia (art. 639 KC).
Błędy w wymaganiach biznesowych również obciążają Zamawiającego, chyba że Dostawca jako profesjonalista powinien był je z łatwością zauważyć. Częstą przyczyną tego problemu są rozproszeni interesariusze projektu, którzy zgłaszają sprzeczne wymagania. Brak komunikacji wewnątrz organizacji nie zwalnia Zamawiającego z obowiązku przekazania jednej, spójnej specyfikacji.
Kierownik projektu IT odpowiada wobec pracodawcy, nie wobec klienta
Kierownik projektu IT (project manager, PM) co do zasady nie odpowiada osobiście wobec klienta, ale odpowiada wobec firmy, która go zatrudnia lub z nim współpracuje.
Rola project managera w projekcie IT jest kluczowa operacyjnie, ale prawnie PM działa w imieniu strony, z którą współpracuje. Błędy kierownika projektu IT po stronie Dostawcy obciążają Dostawcę (art. 474 KC), a błędy PM-a po stronie Zamawiającego obciążają, co oczywiste, Zamawiającego. Osobista odpowiedzialność kierownika wobec strony, z którą współpracuje, zależy od formy umowy.
PM zatrudniony na umowę o pracę
Odpowiedzialność kierownika projektu IT zatrudnionego na etacie regulują przepisy Kodeksu pracy. Najważniejsze zasady:
- pracodawca musi wykazać winę pracownika, szkodę i związek przyczynowy (art. 116 KP);
- pracownik odpowiada tylko za rzeczywistą stratę, a nie za utracone korzyści (art. 115 KP);
- przy winie nieumyślnej odszkodowanie nie może przekroczyć trzymiesięcznego wynagrodzenia (art. 119 KP);
- pracownik nie odpowiada za ryzyko związane z działalnością pracodawcy (art. 117 § 2 KP);
- za szkodę wyrządzoną osobie trzeciej, np. klientowi, odpowiada wyłącznie pracodawca (art. 120 § 1 KP).
Pełna odpowiedzialność wchodzi w grę tylko przy szkodzie wyrządzonej umyślnie (art. 122 KP).
PM współpracujący na kontrakcie B2B
Kierownik projektu na kontrakcie B2B odpowiada wobec Dostawcy na zasadach ogólnych (art. 471 KC), bez limitu odpowiedzialności, który daje mu Kodeks pracy. Limit odpowiedzialności można jednak wprowadzić do umowy w takiej formie, w jakiej strony go uzgodnią.
Wiele ryzyk związanych z nieudanym wdrożeniem można ograniczyć jeszcze przed podpisaniem kontraktu. Warto więc wiedzieć, jak negocjować umowę ERP, aby zabezpieczyć zakres prac, harmonogram i odpowiedzialność dostawcy.
Błędy w zarządzaniu projektem IT to problem dowodowy
Błędy w zarządzaniu projektem IT, takie jak: nieprecyzyjne wymagania, nierealny budżet i brak udokumentowanej komunikacji, w sporze przed sądem zamieniają się w problem dowodowy.
Sąd nie był na spotkaniach biznesowych, nie brał udziału w ustaleniach. Dlatego fakty będzie ustalać na podstawie dokumentów i zeznań świadków, które zostaną mu przedstawione. Częsta jest sytuacja, w której wiesz, że masz rację, ale nie masz jak tego udowodnić. Często proces wygrywasz, albo przegrywasz zanim jeszcze się on rozpocznie, gdyż ciężar udowodnienia faktów spoczywa na tym, kto wywodzi z nich dla siebie skutki prawne. Typowe błędy w projekcie informatycznym i ich skutki prawne:
- Błędy w planowaniu projektu: harmonogram bez buforów i bez powiązania z zadaniami Zamawiającego. W sporze nie da się wykazać, które opóźnienie wywołało które.
- Błędy wymagań biznesowych: specyfikacja ogólnikowa, np. „system ma być intuicyjny”. Na jej podstawie trudno udowodnić wadę.
- Nieadekwatny budżet projektu IT: stała cena (fixed price) bez procedury zmian. Każda zmiana zakresu staje się sporem o dopłatę.
- Ustalenia bez śladu: decyzje podejmowane przez telefon lub Teams/Google Meet, bez notatki i akceptacji e-mail drugiej strony.
Komunikacja w projekcie IT ma więc dwa wymiary: operacyjny i dowodowy. Metodyka zarządzania projektem, np. Scrum, PRINCE2 czy waterfall, nie zastąpi obowiązku utrwalania decyzji i praktycznego waloru takiego działania. Nie chodzi o tzw. „zbieranie kwitów” na drugą stronę, ale o rzetelne dokumentowanie decyzji. W modelu zwinnym (agile) takie działanie jest nawet ważniejsze, bo zakres zmienia się z każdym sprintem.
Zobacz również: Agile czy waterfall? Którą metodykę wybrać w projekcie IT?
Zarządzanie ryzykiem w projekcie IT warto wpisać do umowy
Zarządzanie ryzykiem w projekcie IT powinno być obowiązkiem umownym obu stron, a nie tylko dobrą praktyką kierownika projektu.
Dostawca jako profesjonalista ma obowiązek ostrzegać Zamawiającego o przeszkodach. Czynniki sukcesu projektu informatycznego w 2026 r. nie różnią się od tych sprzed dekady: jasny zakres, decyzyjny właściciel biznesowy i wczesne wykrywanie ryzyk.
Dobrze ułożone w umowie zarządzanie ryzykiem projektu obejmuje:
- rejestr ryzyk prowadzony przez Dostawcę i aktualizowany co najmniej raz na sprint lub raz w miesiącu;
- obowiązek zgłoszenia przeszkody w formie dokumentowej, w określonym terminie od jej wykrycia;
- ścieżkę eskalacji: kierownicy projektu → komitet sterujący → zarządy stron;
- wspólne podsumowanie po zakończeniu etapu (co zadziałało, co nie i dlaczego), jako obowiązkowy element zamknięcia etapu.
Konsekwencje porażki projektu IT: odstąpienie, kary i odszkodowanie
Porażka projektu IT kończy się zwykle jednym z trzech scenariuszy: odstąpieniem od umowy, naliczeniem kar umownych albo sporem o odszkodowanie.
Przy umowie o dzieło Kodeks cywilny daje Zamawiającemu kilka narzędzi:
- Odstąpienie przed terminem (art. 635 KC): gdy Dostawca opóźnia się tak dalece, że nie jest prawdopodobne ukończenie prac w terminie, bez wyznaczania terminu dodatkowego.
- Wezwanie do zmiany sposobu wykonania (art. 636 § 1 KC): gdy prace są prowadzone wadliwie; po bezskutecznym upływie terminu możliwe jest odstąpienie albo powierzenie prac innemu wykonawcy na koszt Dostawcy.
- Kary umowne: należne bez wykazywania szkody, ale sąd może je obniżyć, gdy zobowiązanie wykonano w znacznej części lub kara jest rażąco wygórowana (art. 484 § 2 KC).
Dla firmy konsekwencje wykraczają poza samo odszkodowanie: zamrożony budżet, koszt przejęcia projektu przez nowego wykonawcę i ryzyko braku dostępu do kodu, jeśli autorskie prawa majątkowe przechodzą na Zamawiającego dopiero z chwilą odbioru.
Zobacz również: Odbiór projektu IT: jak powinna wyglądać procedura?
FAQ: odpowiedzialność za porażkę projektu IT
Kto ponosi odpowiedzialność za niepowodzenie projektu IT?
Odpowiedzialność ponosi strona, która nie wykonała swoich obowiązków z umowy, najczęściej Dostawca, ale także Zamawiający, jeśli nie współdziałał. Gdy błędy popełniły obie strony, odszkodowanie dzieli się stosownie do ich udziału w szkodzie. Dlatego Twoja firma powinna dokumentować każdą przeszkodę na bieżąco.
Czy klient ponosi odpowiedzialność za niepowodzenie projektu IT?
Tak, jeśli nie wykonał obowiązku współdziałania, np. nie dostarczył wymagań lub dostępów albo nie dokonał odbioru. Dostawca nie odpowiada wtedy za wynikłe stąd opóźnienie, a przy umowie o dzieło zachowuje prawo do wynagrodzenia. Jeśli jesteś po stronie Zamawiającego, sprawdź, czy Twoje obowiązki są opisane w umowie konkretnie.
Czy kierownik projektu IT odpowiada za jego niepowodzenie?
Osobiście tylko wobec swojego pracodawcy lub zleceniodawcy, a nie wobec klienta. PM na etacie przy winie nieumyślnej odpowiada najwyżej do trzykrotności miesięcznego wynagrodzenia, PM na B2B według zasad ze swojej umowy. Wobec Twojej firmy odpowiada strona, którą PM reprezentuje.
Jaka jest rola zespołu deweloperskiego w sukcesie lub porażce projektu IT?
Zespół deweloperski wykonuje prace, ale prawnie jego błędy są błędami Dostawcy. Zamawiający nie musi wskazywać konkretnego programisty, wystarczy wykazać nienależyte wykonanie umowy. Rozliczenie z członkami zespołu to wewnętrzna sprawa Dostawcy.
Czy brak komunikacji może doprowadzić do porażki projektu IT?
Tak, a do tego utrudnia ustalenie, kto za nią odpowiada. Ustalenia niezapisane w notatkach, protokołach lub zgłoszeniach trudno w sporze udowodnić. Wpisz do umowy formę dokumentową dla decyzji projektowych i zgłoszeń przeszkód.
Jak uniknąć porażki projektu IT?
Od strony prawnej: przypisz w umowie każdy obowiązek konkretnej stronie, wprowadź obowiązek zgłaszania ryzyk i ustal ścieżkę eskalacji. Do tego potrzebne są jasne kryteria odbioru i limit odpowiedzialności dopasowany do wartości projektu. Te elementy nie gwarantują sukcesu, ale przesądzają, kto poniesie koszty, jeśli projekt się nie uda.
Podsumowanie: umowa decyduje, kto zapłaci za porażkę
Porażka projektu rzadko ma jednego winnego, ale prawie zawsze ma stronę, która zapłaci więcej. Decydują o tym kwalifikacja umowy, katalog obowiązków Zamawiającego, procedura zgłaszania przeszkód i jakość dokumentacji projektowej. Kierownik projektu, zespół i sponsor to role operacyjne, odpowiedzialność prawna spoczywa na stronach umowy.
Jeśli Twoja firma przygotowuje wdrożenie albo projekt już utknął, sprawdź umowę, zanim spór przejdzie na etap pism procesowych.
W przypadku wątpliwości dotyczących już zawartej umowy pomocny może być audyt prawny umów IT.
Potrzebujesz wsparcia prawnego w związku z nieudanym wdrożeniem systemu IT? Kancelaria Łochowski Legal specjalizuje się w obszarze prawa nowych technologii, pomagając przedsiębiorcom w sprawach dotyczących umów i projektów informatycznych. Skontaktuj się z nami, aby omówić swoją sytuację.
