Przejęcie projektu IT przez innego wykonawcę to sytuacja, w której nowy dostawca bierze odpowiedzialność za dalszy rozwój, utrzymanie lub dokończenie istniejącego rozwiązania — najczęściej po zakończeniu współpracy z poprzednim wykonawcą, w wyniku sporu, zmiany strategii albo braku możliwości dalszego rozwoju po stronie dotychczasowego partnera. Dobre rozwiązanie w takim przypadku nie polega wyłącznie na „przepisaniu kodu na nowo”, lecz na uporządkowanym przejęciu odpowiedzialności: od audytu stanu projektu, przez zabezpieczenie dostępu do środowisk i dokumentacji, po jasny podział ryzyka i odpowiedzialności w umowie.
Z perspektywy właściciela firmy kluczowe jest to, że przejęcie projektu IT jest procesem zarządczym i prawno-technicznym jednocześnie. Oferta nowego wykonawcy powinna odpowiadać na pytanie: „co dokładnie przejmujecie, w jakim stanie, na jakich zasadach i za ile”, a nie tylko „ile kosztuje godzina pracy”. Poniżej rozkładam ten proces na decyzje, ryzyka, elementy kosztowe, przebieg wdrożenia i kryteria oceny ofert, które można zastosować w małej lub średniej firmie bez rozbudowanego działu IT.
Co realnie oznacza przejęcie projektu IT
Przejęcie projektu to nie jest pojedyncze spotkanie przekazania. To sekwencja działań, w której nowy wykonawca musi najpierw zrozumieć, co istnieje, potem ocenić, czy da się to bezpiecznie utrzymywać i rozwijać, a następnie przejąć odpowiedzialność operacyjną. W praktyce obejmuje ono co najmniej kilka warstw.
Warstwa techniczna: kod źródłowy, repozytoria, infrastruktura (serwery, chmura), bazy danych, integracje z systemami zewnętrznymi, konfiguracje środowisk, mechanizmy wdrożeniowe, kopie zapasowe, monitorowanie i alerty.
Warstwa dokumentacyjna: opis architektury, instrukcje uruchomienia i wdrożenia, dokumentacja API, procedury awaryjne, rejestr znanych błędów i decyzji technicznych.
Warstwa organizacyjna: dostępy, konta, licencje, umowy z poddostawcami, zobowiązania wobec osób trzecich, wiedza ukryta w głowach osób, które dotąd zajmowały się systemem.
Warstwa odpowiedzialności: kto odpowiada za dostępność systemu w okresie przejściowym, kto ponosi koszt naprawy błędów zastanych, jak wygląda eskalacja problemów i kto podejmuje decyzje techniczne.
Dobre rozwiązanie przejęcia porządkuje wszystkie cztery warstwy. Oferta, która skupia się tylko na pierwszej, zwykle prowadzi do sytuacji, w której nowy wykonawca „zna kod”, ale nie zna kontekstu biznesowego ani ograniczeń infrastruktury — a to właśnie tam powstają najdroższe opóźnienia.
Warianty decyzji: dokończenie, utrzymanie, przepisanie
Zanim ocenisz oferty, warto zdecydować, czego właściwie potrzebujesz. To decyzja biznesowa, nie techniczna, i powinna być podjęta przed rozmowami z wykonawcami.
Wariant 1: Przejęcie i kontynuacja rozwoju istniejącego rozwiązania
Nowy wykonawca przejmuje system w obecnym kształcie i rozwija go dalej. Zaleta: krótszy czas do pierwszych efektów, zachowanie dotychczasowych inwestycji. Ryzyko: jakość istniejącego kodu i dokumentacji może być niska, a dług technologiczny przechodzi na nowego dostawcę — trzeba więc jasno ustalić, kto płaci za naprawę problemów zastanych.
Wariant 2: Przejęcie wyłącznie utrzymania
Nowy wykonawca odpowiada za stabilność, bezpieczeństwo i drobne poprawki, ale nie za rozwój funkcjonalny. To rozwiązanie sensowne, gdy system jest wystarczający biznesowo, a problemem była wyłącznie dostępność wsparcia. Wymaga precyzyjnego określenia zakresu: co jest „drobna poprawka”, a co osobnym zleceniem.
Wariant 3: Przepisanie lub modernizacja
Czasem przejęcie projektu IT jest punktem wyjścia do przebudowy systemu. To najdroższy i najbardziej ryzykowny wariant, ale bywa konieczny, gdy technologia jest przestarzała, brakuje specjalistów na rynku albo koszt utrzymania przewyższa koszt zmiany. W tym wariancie warto rozdzielić dwa etapy: audyt i decyzję o kierunku, a dopiero potem budowę nowego rozwiązania.
Wariant 4: Przejęcie hybrydowe
Część systemu zostaje, część jest wymieniana. To często najbardziej realistyczny scenariusz w MŚP, ale wymaga od wykonawcy umiejętności pracy w niejednorodnym środowisku i jasnego planu migracji.
Ryzyka, które trzeba nazwać przed podpisaniem umowy
Największe ryzyka w przejęciu projektu IT nie są techniczne w wąskim sensie — są organizacyjne i kontraktowe.
– Brak dostępu do repozytoriów i infrastruktury. Jeśli poprzedni wykonawca jest jedynym administratorem kont, nowy dostawca może utknąć na etapie dostępu. To trzeba uregulować jeszcze przed startem.
– Wiedza ukryta. Systemy bywają utrzymywane przez jedną osobę, która „wie wszystko”. Jej odejście lub brak współpracy to realne ryzyko operacyjne.
– Dług technologiczny bez wyceny. Nowy wykonawca może odkryć, że kod wymaga gruntownej naprawy. Bez zapisu w umowie koszt tego odkrycia spada na Ciebie.
– Zależność od poddostawców. Licencje, hosting, zewnętrzne API — każdy z tych elementów może mieć warunki, które utrudniają zmianę wykonawcy.
– Nieciągłość odpowiedzialności. W okresie przejściowym może dojść do sytuacji, w której ani stary, ani nowy wykonawca nie czuje się odpowiedzialny za awarię.
– Zbyt optymistyczny harmonogram. Przejęcie zwykle trwa dłużej niż deklaruje wykonawca, zwłaszcza gdy dokumentacja jest niekompletna.
Dobre rozwiązanie zawiera mechanizmy ograniczające te ryzyka: okres przejściowy z jasno określoną odpowiedzialnością, listę kontrolną przekazania, zapis o odpowiedzialności za wady zastane oraz procedurę eskalacji.
Z czego składa się koszt przejęcia projektu
Dokładna kwota zależy od zakresu, stanu projektu i liczby integracji — nie da się podać uniwersalnej ceny. Zamiast szukać „widełek”, warto zrozumieć, z jakich elementów składa się wycena, żeby porównywać oferty na tym samym poziomie szczegółowości.
| Element kosztowy | Co obejmuje | Czy zwykle jest w ofercie |
|—|—|—|
| Audyt początkowy | Przegląd kodu, infrastruktury, dokumentacji, integracji | Często osobno lub jako etap 1 |
| Przekazanie dostępów i wiedzy | Warsztaty, dokumentacja powykonawcza, checklisty | Często pomijane lub niedoszacowane |
| Utrzymanie i wsparcie | Monitoring, reagowanie na awarie, poprawki | Zwykle w abonamencie |
| Rozwój funkcjonalny | Nowe funkcje, zmiany w istniejących | Wyceniane zadaniowo |
| Naprawa długu technologicznego | Refaktoring, aktualizacje, bezpieczeństwo | Często poza zakresem — trzeba ustalić |
| Migracja lub przepisanie | Nowe środowisko, nowa architektura | Osobny projekt |
| Zarządzanie projektem | Koordynacja, raportowanie, komunikacja | Bywa ukryte w stawce |
W praktyce najczęstszym błędem jest porównywanie ofert wyłącznie po stawce godzinowej. Dwie oferty z podobną stawką mogą różnić się zakresem odpowiedzialności, czasem reakcji, liczbą godzin w abonamencie i tym, czy audyt jest w cenie. Dlatego pytaj o rozbicie kosztów na etapy i o to, co jest poza zakresem.
Przebieg wdrożenia krok po kroku
Dobrze poprowadzone przejęcie projektu IT ma kilka etapów, które warto zapisać w umowie jako kamienie milowe.
1. Inwentaryzacja i audyt. Nowy wykonawca zbiera informacje o systemie, infrastrukturze, integracjach i dokumentacji. Efekt: raport o stanie projektu i lista ryzyk.
2. Zabezpieczenie dostępów. Przekazanie lub utworzenie kont administracyjnych, uporządkowanie licencji, potwierdzenie własności domen i środowisk. Efekt: nowy wykonawca ma legalny i techniczny dostęp do wszystkiego, co potrzebne.
3. Warsztaty przekazania wiedzy. Sesje z osobami znającymi system, spisanie procedur, znanych błędów i decyzji. Efekt: dokumentacja powykonawcza i lista otwartych pytań.
4. Okres próbny / równoległy. Nowy wykonawca przejmuje część zadań, a stary lub wewnętrzny zespół pozostaje w gotowości. Efekt: ograniczenie ryzyka nieciągłości.
5. Przejęcie pełnej odpowiedzialności. Nowy wykonawca odpowiada za utrzymanie i rozwój zgodnie z umową (SLA, czas reakcji, sposób raportowania).
6. Przegląd po okresie przejściowym. Ocena, czy założenia się sprawdziły, czy trzeba skorygować zakres lub harmonogram.
Każdy z tych etapów powinien mieć właściciela, termin i kryterium zakończenia. Bez tego przejęcie zamienia się w otwarty proces bez końca.
Jak ocenić ofertę wykonawcy: konkretne kryteria
Ocena ofert powinna być ustrukturyzowana. Poniższa checklista pomaga porównać wykonawców na tych samych zasadach.
– Czy oferta zawiera opis metodyki przejęcia? Nie chodzi o ogólne deklaracje, ale o konkretne etapy, efekty i role.
– Czy audyt jest osobnym etapem z jasnym produktem? Raport z audytu powinien być dostarczalny niezależnie od dalszej współpracy.
– Jak wykonawca zamierza pozyskać dostępy i wiedzę? Czy ma plan na sytuację, w której poprzedni dostawca nie współpracuje?
– Czy zakres i wyłączenia są wymienione wprost? Oferta bez listy wyłączeń jest niepełna.
– Jak wygląda podział odpowiedzialności za wady zastane? Kto płaci za naprawę błędów istniejących przed przejęciem?
– Czy są zdefiniowane poziomy usług? Czas reakcji, czas naprawy, kanały zgłoszeń, godziny wsparcia.
– Jak wygląda raportowanie? Czy dostaniesz regularny przegląd stanu projektu i budżetu?
– Czy wykonawca pokazuje zespół, a nie tylko nazwę firmy? Kto realnie będzie pracował przy projekcie i jakie ma doświadczenie w podobnych systemach?
– Czy oferta zawiera plan wyjścia? Dobry wykonawca nie boi się zapisu o przekazaniu projektu dalej — to sygnał dojrzałości.
– Czy warunki płatności są powiązane z etapami? Płatność za kamienie milowe ogranicza ryzyko.
Warto też zadać pytanie o scenariusz awaryjny: co się stanie, jeśli w pierwszych tygodniach pojawi się krytyczna awaria, a nowy wykonawca nie zna jeszcze systemu? Odpowiedź pokazuje, czy wykonawca myśli operacyjnie, czy tylko sprzedażowo.
Rola umowy i zabezpieczeń prawnych
Umowa o przejęcie projektu IT powinna regulować rzeczy, które w codziennej pracy wydają się oczywiste, ale w sytuacji sporu stają się kluczowe. Do najważniejszych należą: własność kodu i dokumentacji, zakres licencji, obowiązek przekazania dostępów, odpowiedzialność za wady zastane, okres przejściowy, warunki rozwiązania umowy oraz obowiązek przekazania projektu innemu wykonawcy bez blokad.
Szczególnie istotny jest zapis o tzw. wyjściu z projektu. Jeśli współpraca się nie ułoży, musisz mieć prawo i możliwość zabrania kodu, danych i konfiguracji. Warto też ustalić, w jakim formacie i w jakim terminie wykonawca przekaże dokumentację — „w rozsądnym czasie” to zbyt mało precyzyjne sformułowanie.
Kiedy warto skorzystać z zewnętrznego wsparcia
W małej firmie nikt zwykle nie ma czasu ani kompetencji, by samodzielnie ocenić stan projektu i porównać oferty. Zewnętrzne wsparcie przy przejęciu projektu IT ma sens szczególnie wtedy, gdy system jest krytyczny dla działalności, gdy poprzedni wykonawca nie współpracuje albo gdy oferty znacząco różnią się zakresem. Wsparcie nie musi oznaczać oddania całego projektu — czasem wystarczy audyt i druga opinia przy ocenie ofert. Więcej o tym, jak ułożyć współpracę z dostawcą IT w MŚP, znajdziesz w materiałach o rozwiązaniach IT dla małych i średnich firm.
FAQ
Czy przejęcie projektu IT zawsze oznacza przepisanie systemu od zera?
Nie. W większości przypadków nowy wykonawca przejmuje istniejące rozwiązanie i rozwija je dalej. Przepisanie jest osobną decyzją, którą warto podejmować po audycie, a nie z góry.
Ile trwa przejęcie projektu IT?
To zależy od liczby integracji, stanu dokumentacji i dostępności osób znających system. Realistyczny plan powinien być podzielony na etapy z kamieniami milowymi, a nie oparty na jednym terminie końcowym.
Co zrobić, jeśli poprzedni wykonawca nie chce przekazać dostępów?
To sytuacja, którą trzeba rozwiązać prawnie i organizacyjnie. Warto sprawdzić zapisy umowy z poprzednim dostawcą, potwierdzić własność domen, licencji i repozytoriów oraz zaplanować działania zabezpieczające ciągłość działania.
Czy nowy wykonawca odpowiada za błędy w kodzie, którego nie napisał?
To zależy od umowy. Dobrą praktyką jest rozdzielenie odpowiedzialności za wady zastane i za nowe prace. Oferta powinna jasno mówić, co jest w zakresie, a co wymaga osobnej wyceny.
Jak porównać oferty, jeśli mają różne stawki i różny zakres?
Nie porównuj samych stawek. Zestaw oferty według tych samych kryteriów: zakres, etapy, odpowiedzialność, poziomy usług, wyłączenia i warunki płatności. Dopiero wtedy różnice w cenie stają się zrozumiałe.
Przejęcie projektu IT to decyzja, która ma konsekwencje na lata. Jeśli chcesz uporządkować ten proces w swojej firmie, warto zacząć od rozmowy o zakresie i kryteriach oceny — zanim podpiszesz pierwszą umowę z nowym wykonawcą.
