Jak skutecznie kontraktować budowę i rozwój systemów informatycznych?

Dany model musi być korzystny z finansowego punktu widzenia. Ponadto nie możemy zapominać o tym, aby mieć kontrolę nad postępem prac, a także, aby po zakończeniu realizacji projektu, wypracowane know-how zostało z nami.

Kluczowa jest kwestia zaufania i budowanie relacji partnerskich pomiędzy dostawcą a zamawiającym. Powinniśmy o to zadbać już na etapie prac nad zakontraktowaniem projektu.

Model Fixed Price, czyli co, na kiedy oraz za ile zostanie dostarczone

Z punktu widzenia wielu działów firmy jest to najlepszy model współpracy. Dział finansowy otrzymuje jasną deklarację, jaki jest ostateczny koszt realizacji projektu. Łatwo wpisać taką pozycję do budżetu. Dział zakupów mając do wglądu z góry określoną kwotę, czas i termin może łatwo porównać oferty i podjąć decyzję o wyborze najkorzystniejszej.

Realizacja projektu w modelu fixed price jest także bezpieczniejsza z punktu widzenia działu prawnego. W kontrakcie zawarty jest zakres odpowiedzialności dostawcy za dostarczenie odpowiedniego rozwiązania, jak również uwzględnione są kary za niewywiązanie się ze swoich zobowiązań. Dodatkowo większa część odpowiedzialności spoczywa na dostawcy.

Model ten oprócz powyższych zalet ma jednak kilka wad. Pierwszą z nich jest konieczność jasnego sprecyzowania zakresu prac i tego, co dokładnie zostanie zrealizowane. I to jeszcze przed rozpoczęciem projektu.

Problem pojawia się, gdy początkowe założenia okazują się niewystarczające i zakres prac ulega nieplanowanemu rozszerzeniu. Zamawiający i dostawca stają wówczas niejako po dwóch stronach barykady. Zamawiający próbuje włączyć do zakresu prac wszystko, co tylko możliwe i nie było ustalane wcześniej, a dostawca ze wszystkich sił broni się przed tym, jak przed ostrzałem. W obecnych czasach, gdy wymagania zmieniają się bardzo szybko, z pomocą przychodzą nam zwinne metodyki prowadzenia projektów, które częściowo rozwiązują ten problem.

Jednak i tu pojawia się kolejny, czyli jak połączyć zwinną metodykę projektową, w której z definicji priorytety i zakres prac zmieniają się podczas trwania projektu, z kontraktem fixed price, w którym cena i zakres zostają ustalone na samym początku. Rozwiązaniem może być określenie, już na etapie kontraktowania, zasad postępowania w przypadku wystąpienia rozbieżności.

Jednym z nich może być przeznaczenie w ramach umowy dodatkowego budżetu, który pokryje realizację dodatkowych prac. Innym jest wycena punktowa każdej funkcjonalności. Dzięki temu zamawiający może zdecydować, czy chce wymienić jedną funkcjonalność na drugą, o tej samej wartości punktowej.

Drugim problemem jest sytuacja, w której po zakończeniu projektu zamawiający nie będzie w stanie sam dalej rozwijać systemu. Czy to ze względu na zapisy w umowie, niepozwalające na zmiany w systemie, czy też z powodu braku wiedzy merytorycznej wynikającej z faktu, że osoby ją posiadające i zaangażowane w projekt były pracownikami dostawcy.

Jednym ze sposobów na uniknięcie takiej sytuacji jest zaproponowanie, aby w przykładowym, 20-osobowym zespole projektowym, znalazło się dwóch pracowników zamawiającego. Gdy dostawca nie zgadza się na takie rozwiązanie, powinniśmy się zastanowić, dlaczego tak się dzieje i starać się go przekonać.

Doświadczenie pokazuje, że ma ono wiele zalet. Przede wszystkim pomaga w zintegrowaniu zespołu. Ponadto pracownicy dostawcy biorący udział w projekcie mogą podzielić się swoją wiedzą na temat tego, jak pewne problemy w ich organizacji można rozwiązać szybciej. Najważniejsze jest jednak to, że buduje to zaufanie pomiędzy obydwoma stronami kontraktu, a zamawiający zyskuje informację od swoich zaufanych pracowników, na temat tego, jak wygląda obecny stan systemu.

Kolejnym problemem może być ustalenie, w jaki sposób prowadzić kontrolę postępu prac. W modelu fixed price zasadnicza odpowiedzialność leży po stronie dostawcy i to on dostarcza informacje zarządcze. Jak doprowadzić do tego, aby zamawiający na bieżąco wiedział o problemach pojawiających się w projekcie? Tutaj przydatna byłaby regularna kontrola. Jeszcze ważniejsze jest natomiast zbudowanie otwartej komunikacji i zaufania tak, aby w interesie dostawcy było zgłaszanie wszelkich ryzyk projektowych, nawet tych spowodowanych przez niego, tak aby wspólnie pracować nad ich zredukowaniem.

Body leasing – wiemy co i jak chcemy zrobić, a potrzebujemy tylko dostawcy, który nas wesprze

W ostatnim czasie możemy zaobserwować zwiększenie popularności projektów prowadzonych w formule body leasing. W szczególności widać to w ostatnich dwóch latach w sektorze publicznym w Polsce. Wzrost ten wynika w dużej mierze z potrzeby większej elastyczności przy ustalaniu zakresu projektów i lepszej kontroli nad prowadzonymi przedsięwzięciami. W tym wypadku cała odpowiedzialność za projekt leży po stronie zamawiającego, zarówno od strony zarządczej, jak i technologicznej.

 Co w takim modelu otrzymuje zamawiający? W skrajnym przypadku dostawca pełni rolę firmy pośrednictwa pracy. Szuka odpowiedniego kandydata spośród swoich i/lub dostępnych na rynku pracowników, a następnie kieruje go do klienta. Jednak dostawca może zrobić dużo więcej. Jeśli rozumie, jakie oczekiwania ma zamawiający, wówczas może samodzielnie dopasować dla niego idealnego kandydata. Dzięki temu zamawiający oszczędza czas, który musiałby przeznaczyć na przeprowadzenie rozmów kwalifikacyjnych.

Jednak wymaga to dużego zaufania i w przypadku pierwszego zamówienia, być może nie jest to najlepsza opcja. Jednak po 5 czy 10 skutecznie przeprowadzonych rekrutacjach takie zaufanie powinno wzrosnąć i warto to rozważyć.   

Team leasing – więcej niż body leasing

W tym modelu możemy otrzymać znacznie więcej niż tylko zaproponowanie odpowiedniego kandydata. Możemy zaoferować dostawcy zbudowanie całego zespołu. Kluczowe w nim osoby powinniśmy zweryfikować sami. Jednak, jeżeli lider zespołu już spełnia nasze oczekiwania, to możemy dać dostawcy swobodę wyboru poszczególnych programistów tak, aby stworzył najbardziej efektywny team. Dzięki temu przeniesiemy na niego część odpowiedzialności, a dodatkowo zyskamy czas, który musielibyśmy poświęcić na zarządzanie zespołem. Rolą dostawcy jest wówczas nie tylko zapewnienie odpowiednich kandydatów, ale również monitorowanie efektywności ich pracy oraz weryfikowanie zadowolenia, co pozwala zminimalizować ryzyko rotacji w trakcie trwania projektu.  Projekt prowadzony w ten sposób pozwala zamawiającemu na przekazanie dużej części odpowiedzialności na rzecz dostawcy bez utraty pełnej kontroli nad projektem.

Kluczowa współpraca i zaufanie

Niezależnie jednak, który model wybierzemy, kluczowa jest dobra współpraca między zamawiającym i dostawcą oraz wzajemne zaufanie. Jeśli tego nie ma, to ciężko będzie przeprowadzić projekt z sukcesem. Warto dobrze przyjrzeć się tej kwestii i już podczas kontraktowania projektu odpowiedzieć sobie na nurtujące obydwie strony pytania, jak np. co zrobimy w sytuacji, gdy projekt będzie się opóźniał.

Oczekiwania zamawiającego mogą się znacznie różnić od tego, w jaki sposób dostawca planuje rozwiązywać takie problemy. Z mojego doświadczenia wynika, że realizacja projektu, który zakończył się największym sukcesem, była pełna burzliwych dyskusji już na etapie kontraktowania.

Wynikały one głównie z konfrontacji oczekiwań – to, czego wymagał zamawiający w przypadku pojawienia się problemów, nie zawsze było spójne z tym, co w takich sytuacjach planował zrobić dostawca. Część z tych problemów wystąpiła w trakcie realizacji projektu, a część nie. Mimo to obydwie strony wiedziały, czego mogą się spodziewać i praca przebiegała bardzo sprawnie. A w końcu nic tak nie buduje wzajemnego zaufania, jak zakończony z sukcesem projekt.

Tomasz Dziki,

Executive VP & Owner,

Britenet.