Projekty IT zaczynają się umową wdrożeniową. To w niej niektóre zapisy umowne mogą później znacznie utrudnić zrealizowanie projektu.

1. Umowy w projektach informatycznych
Dlaczego chcemy się oszukiwać w projektach IT?
Bogdan Górka

2. Co wiemy rozpoczynając projekt informatyczny?
KLIENT
WIEDZA
O
POTRZEBACH
FIRMY
WIEDZA
O MOŻLIWOŚCIACH
SYSTEMU IT DOSTAWCA
SYSTEMU
IT
Na początku projektu, wiedza Klienta o możliwościach systemu jest mała,
ale dużo wie o swojej firmie i „czuje” co by jej pomogło.
Wiedza Dostawcy o tym co może system i jak pomaga innym firmom jest
duża, ale nie wie i „nie czuje” czego potrzebuje firma
DUŻA
MAŁA
DUŻA
MAŁA

3. Z czym rozpoczyna Klient (biznes)?
Mam nadzieję, że moje
potrzeby i wymagania
zostały dobrze
zidentyfikowane przez
Dostawcę
Płacę i
wymagam
Mam uzasadnienie
biznesowe na
konkretną kwotę i
MUSI mi starczyć
System MUSI być
uruchomiony
szybko i na
1 stycznia
Muszę mieć PEWNOŚĆ że system od
Dostawcy będzie miał to co
potrzebuję w wyznaczonym terminie

4. Z czym rozpoczyna Dostawca (IT)?
Klient nie wie (jak zwykle)
czego potrzebuje i co chce
biznesowo osiągnąć tym
wdrożeniem
Kwota od klienta jest stała, a
ja chcę się zmieścić w
zakładanej marży, więc
muszę ciąć koszty
Nie mam za dużo czasu na analizę
potrzeb i precyzyjne uzgodnienia, muszę
przyjąć ogólne założenia i swoje gotowce
Muszę się zmieścić w
narzuconych
terminach, bo też
mam innych klientów

5. Umowa wdrożeniowa
MUSIMY SIĘ ZABEZPIECZYĆ!
KLIENT
DOSTAWCA
SYSTEMU
IT
UMOWA – w rzeczywistości to obustronne zabezpieczenie finansowe na wypadek porażki.
Każda ze stron czuje się dobrze zabezpieczona przed skutkami niepowodzenia projektu,
optymalizuje swoje działania pod zapisy umowne zabezpieczając swoje interesy, a nie cel
projektu
UMOWA
WDROŻENIOWA
Interes Klienta:
otrzymać system
według moich
potrzeb w
ramach mojego
budżetu
Interes Dostawcy:
dostarczyć system
według specyfikacji
i w budżecie z umowy

6. Strategia Zamawiającego - Klienta
 Napisałem Zapytanie Ofertowe i ogólnie wiem czego
potrzebuję
 Mam nadzieję, że tak jak to Sprzedawca Dostawcy
zapewniał, jest to dokładnie taki system, który spełni
wszystkie moje potrzeby (te niewypowiedziane też)
 Jest ryzyko, że Dostawca będzie chciał wcisnąć mi byle
co, albo wysłać do mnie byle jakich konsultantów, więc
muszę się zabezpieczyć, kontrolować wykonanie
zapisów umowy i zbierać na wszystko kwity i wymagać
szczegółowej dokumentacji – może się to przydać do
wstrzymania płatności albo w sądzie

7. Strategia Zamawiającego – Klienta (cd.)
 Muszę wycisnąć z konsultantów Dostawcy tyle ile się da,
żeby zrealizować jak najwięcej wymagań za tyle pieniędzy ile
mam, w tym czasie jaki mam do dyspozycji
 Nie wiem dokładnie czego potrzebuję, więc na wszelki
wypadek chcę odtworzenia wszystkiego tego co miałem w
moim obecnym systemie (żeby wszystko tak samo działało)
 Nie mam czasu zastanawiać się czy specyfikacja wymagań
jest dobrze napisana, więc na poważnie zajmę się tym
projektem podczas testów akceptacyjnych, a konsultanci
niech sobie na razie piszą
 Jak czegoś Dostawca nie zrealizuje, to będzie to dorabiał już
za darmo, po to jest przecież specyfikacja i umowa

8. Strategia Realizującego - Dostawcy
 Jak najszybciej doprowadzić do podpisania przez Klienta
specyfikacji funkcjonalnej – im mniej szczegółów tym lepiej
 Ogólna specyfikacja umożliwia dostarczenie projektu szybko i
tanio, niekoniecznie zgodnie z oczekiwaniami Klienta i jego
użytkowników. Klient i tak nie wie czego potrzebuje i co
może otrzymać.
 Analiza potrzeb i uzgodnienia muszą być zminimalizowane,
bo im więcej szczegółów w specyfikacji, tym bardziej Klient
będzie się mógł tego domagać, a to z kolei ogranicza mi
pole manewru i możliwości realizacyjne
 Mój cel - wykonać i dostarczyć jak najszybciej cokolwiek, co
Klient zgodzi się odebrać zgodnie z zapisanymi w umowie
warunkami akceptacji – miara sukcesu: odebranie kwitu

9. Strategia Realizującego – Dostawcy (cd.)
 Oprogramowanie nie musi być użyteczne dla końcowych
użytkowników. Musi tylko być zgodne ze specyfikacją i
przejść testy, które ja ustawiam
 Klienci (Zarządy firm) najbardziej doceniają ostatecznie tych
Dostawców, którzy realizują projekty szybko i tanio. Potem się
wszystko poprawi w ramach umowy serwisowej.
 Nie jest winą Dostawcy, że nie dostarczył funkcjonalności
której nie było w specyfikacji
 Funkcje wymagane przez Klienta poza specyfikacją
funkcjonalną są mile widziane, ale tylko po wynegocjowaniu
przesunięcia terminów i za dodatkowym wynagrodzeniem

10. Przeciwstawne interesy nie zrealizują projektu –
zrealizują zapisy umowne
Wszystko ma być dokładnie udokumentowane,
podpisy i pieczątki zebrane, raporty generowane
(jakby trzeba było iść do sądu)
Cel: Zrealizować dokładnie to,
co jest napisane w umowie
i w specyfikacji
Nie udowodnią nam tego przed sądem,
nigdy nie byliśmy za tę część odpowiedzialni
Macie dostarczyć gotowy system
A ja go sprawdzę i zdecyduję o zapłacie To jest wniosek o zmianę,
tego nie było w specyfikacji,
potrzebuję czas i pieniądze na
jego realizacjęJa inaczej rozumiem te
zapisy w umowie
Nie interesuje mnie jak to jest zrobione.
To wy jesteście konsultantami i ma to działać

11. Z czym więc zaczynamy projekt?
 Niemożliwe jest napisanie tak szczegółowej
specyfikacji wymagań, która uwzględni:
• wszystkie potrzeby Klienta
• wszystkie możliwości konfiguracji Systemu IT
• zmiany w sytuacji rynkowej Klienta, które wpływają na
zmiany jego potrzeb w trakcie projektu
 Brak zaufania stron utrwalony w Umowie zachęca
do uprawiania polityki i podchodów z udziałem
biurokracji
 Wszystko co jest poza specyfikacją, jest okazją do
dodatkowego zarobku (gra w „Mamy Cię”)

12. Co daje nam więc umowa?
 Umowa, która rozpoczyna współpracę i utrwala
brak zaufania między Klientem i Dostawcą, jest jak
telefon komórkowy, który jest poza zasięgiem sieci.
Można nim tylko grać w gry.

13. Gra projektowa „Mamy Cię”
 Cel Dostawcy: wykazać, że żądanie dodania
funkcjonalności wykrytej dopiero na etapie testów i
szkoleń, nie było uwzględnione w umowie i w
specyfikacji.
Dostawca: Zmiana zakresu = Wzrost wynagrodzenia
 Cel Zamawiającego: wykazać, że żądanie dodania
funkcjonalności wykrytej w dowolnym etapie było od
początku przedmiotem zapytania ofertowego i
specyfikacji wymagań.
Zamawiający: Wstrzymujemy płatności, nie
dokonujemy odbiorów, wykazujemy niewywiązanie się
z umowy

14. Klasyczna umowa zabezpiecza przeciwstawne
interesy, ale nie dostarcza wartości żadnej ze stron
INTERES KLIENTA INTERES DOSTAWCY
 Dostać jak najlepszy
funkcjonalnie system
 którego możliwości
jeszcze nie rozumiem,
 aby spełnić potrzeby
których sobie w pełni
nie uświadamiam,
 w ustalonej cenie
i w nieprzekraczalnym
terminie
 Dostarczyć działający
system
 który jest w pełni zgodny
ze specyfikacją, tak aby
musiał zostać odebrany
 niekonieczne
odpowiadający
prawdziwym potrzebom
użytkowników
 i jak najmniej koszto- i
pracochłonny

15. Klasyczna umowa
zabezpiecza tylko ryzyka finansowe
BEZPIECZEŃSTWO KLIENTA BEZPIECZEŃSTWO DOSTAWCY
 Z góry ograniczony
budżet „fixed price”
 Z góry „określony” zakres
projektu według moich
(lepszych czy gorszych)
wymagań
 Duża swoboda w
interpretacji co jest w
zakresie projektu
 Im bardziej ogólne
wymagania tym
bezpieczniej
 Z góry ustalona zapłata i
termin płatności

16. Komunikacja? Za wolna komunikacja.
 Komunikacja szczegółowo sterowana zapisami umowy
 Konieczność obszernego udokumentowania wszystkich
wymagań i założeń
 Konieczność dokumentowania wszelkich ustaleń, zmian,
uzgodnień – zredagowanie, przegląd, akceptacja, poprawki,
zwrot, ponowny przegląd…
 Konieczność uzyskiwania pisemnych potwierdzeń
dokumentacji, jako podstaw do zobowiązań umownych
 To wszystko generuje zbędną pracę i koszty – po obu
stronach
 Korespondencja pisemna zamiast rozmowy trwa i kosztuje
czas
 Celem nie jest porozumienie, tylko zebranie dowodów na
ewentualne spotkanie w sądzie

17. Wnioski
 Umowa wdrożeniowa typu „Stała kwota” utrwala
brak zaufania między Dostawcą i Zamawiającym i
jest zorientowana na zabezpieczenie się przed
porażką
 Umowy wdrożeniowe ubezpieczają tylko interesy
finansowe, ale nie wspierają wspólnej realizacji celu
biznesowego projektu i wspólnego sukcesu
 Zabezpieczenie interesu finansowego wymaga
obszernej dokumentacji okołoprojektowej i
korespondencji pisemnej, której przygotowanie
dużo kosztuje

18. Co można w tej sytuacji zrobić?
 Na szczęście nie zawsze umowy wdrożeniowe służą do
trzymania się nawzajem „na widelcu”
 Dostawca i Klient muszą wspólnie zastanowić się jakie mają
potrzeby i co jest źródłem ich ograniczeń, niepewności,
obaw i zagrożeń finansowych
 Potrzebny jest cel biznesowy – oczekiwany i mierzalny efekt
w rozwoju firmy Klienta musi być wpisany w ich strategię i
być potwierdzony z Dostawcą, że to technologia IT jest
dobrym sposobem na osiągnięcie tego celu
 Dostawca i Klient muszą mieć zbieżne cele, aby obu
stronom opłaciło się zrobić wspólnie dobry projekt. W
przeciwnym razie zawsze będą trudności w realizacji tego,
czego w umowie nie opisano.

19. Warto poczytać
 http://www.cio.com/article/2381167/agile-
development/-no-estimates-in-action-5-ways-to-
rethink-software-projects.html
 http://www.slideshare.net/gerardbeckerleg/noestim
ates-stop-lying-to-yourself-and-your-customers-
and-stop-estimating
 http://www.isixsigma.com/tools-templates/cause-
effect/determine-root-cause-5-whys/

20. Bogdan Górka
Więcej o projektach
na ProjectCoach.pl