Rentowne kontrakty Fixed Price – checklista PRZED

Rentowne kontrakty Fixed Price – checklista PRZED

Pomimo coraz większej popularności kontraktów Time&Material i metodyk Agile niektórzy klienci wolą pozostać przy kontraktach Fixed Price. Z punktu widzenia dostawcy usług IT na rentowność takich kontraktów ma wpływ wiele czynników i jest bardzo zależne od konkretnego klienta i projektu. Poniższa checklista to zbiór najważniejszych zasad, których stosowanie przed podpisaniem kontraktu powinno pomóc w utrzymaniu rentowności takich projektów.

1. Zaangażuj zespół przewidziany do realizacji projektu w przygotowanie oferty i kontraktu

Proces ofertowania usługi klientowi inicjowany jest przez dział handlowy, ale za przygotowanie oferty często odpowiadają już inne osoby, np. dział presales consulting. Dość ważne jest zaangażowanie w  proces przygotowania oferty zespołu technicznego i kierownika projektu, którzy zostaną przydzieleni do projektu w przypadku podpisania kontraktu.

Z jednej strony włączenie zespołu technicznego i kierownika projektu w przygotowanie ofert oznacza wyższe koszty pozyskania klienta i czasami może być trudne do wykonania z powodu obłożenia zadaniami w trwających projektach. Z drugiej strony, jeśli oferta i późniejszy kontrakt nie będą dobrze wycenione, to firma może później ponieść koszty znacznie wyższe niż te, które oszczędziła nie angażując tych osób odpowiednio wcześnie.

Członkowie zespołu technicznego oraz kierownik projektu są niezastąpieni w identyfikacji ryzyk i zależności zewnętrznych, które stają się w trakcie realizacji częstym powodem zwiększonych kosztów i opóźnień projektu.  Dodatkową korzyścią z zaangażowania zespołu technicznego w przygotowanie oferty jest jego późniejsze większe zaangażowanie i przywiązanie do wycen – redukuje to też sytuacje obwiniania handlowców przez zespół techniczny o podpisywanie umów, z których nie można się wywiązać.

2. Umieść założenia implementacyjne w kontrakcie

Podczas wyceny zespół analizuje wymagania i robi pewne założenia co do tych wymagań. Te założenia są kluczowe jeśli chodzi o oszacowanie pracochłonności i bardzo ważne jest umieszczenie ich w ofercie oraz kontrakcie. W momencie, gdy kontrakt będzie podpisany i projekt w trakcie realizacji, dostawca jest w gorszej pozycji negocjacyjnej jeśli chodzi o interpretację zakresu, a spisane założenia ograniczające upraszczają znacznie takie negocjacje.

Dla przykładu, gdy klient zawarł w zapytaniu ofertowym lakonicznie określony moduł raportowy, założenia do wyceny mogą ograniczać ilość raportów prekonfigurowanych przez dostawcę czy ograniczać elastyczność konfiguracji tych raportów.

3. Określ daty i formę dostarczenia zależności zewnętrznych

Może być wiele różnych przypadków, gdzie istnieje zależność zewnętrzna, np:

  • integracja z systemami klienta lub systemem dostarczanym przez innego dostawcę,
  • migracja danych klienta,
  • wspólne wykonywanie części prac przez dostawcę i klienta,
  • zdefiniowanie interfejsu aplikacji (API) przez klienta,
  • dostarczenie projektu ekranów przez klienta,
  • dostarczenie scenariuszy testowych,
  • dostarczenie danych testowych,
  • dostępność osób po stronie klienta do przetestowania aplikacji.

Nie wywiązanie się klienta z tych dat oznacza przesunięcia w harmonogramie i nawet jak klient nie będzie egzekwował kar umownych za opóźnienia, to naraża on dostawcę na dodatkowe koszty.

Warto wpisać w kontrakt nie tylko kiedy zostanie coś dostarczone przez klienta, ale też w jakiej formie i w jakiej dokładności. Dla przykładu może się zdarzyć, że klient dostarczy niekompletną dokumentację interfejsów, niekompletne dane testowe, nie w pełni działające środowisko testowe, itp. Z punktu widzenia kontraktowego, klient dostarczył to, co miał, ale i tak powoduje to opóźnienia w projekcie.

4. Zdefiniuj i wyceń wymagania niefunkcjonalne

Wymagania niefunkcjonalne to na przykład wydajność aplikacji, jej skalowalność, możliwości konfiguracyjne. Klient może zapomnieć o zdefiniowaniu wymagań niefunkcjonalnych w zapytaniu ofertowym, ale na pewno sobie o nich przypomni w trakcie albo po odbiorze projektu. Dostawca zanim podpisze kontrakt powinien dopytać klienta jakie są standardy, których oczekuje i jeśli nie ma żadnych, to umieścić w kontrakcie swoje i je uwzględnić w wycenie.

5. Zidentyfikuj i zaadresuj ryzyka

Warto przeprowadzić burzę mózgów w zespole i zidentyfikować jak najwięcej ryzyk zanim wyśle się klientowi ofertę.

Dla każdego z istotnych ryzyk trzeba zdecydować co z nim zrobić, np:

  • akceptacja i wzięcie na siebie ryzyka,
  • ograniczenie ryzyka poprzez odpowiednie założenie implementacyjne,
  • zaproponowanie klientowi wyłączenia z zakresu kontraktu danego obszaru zanim nie zrobi się analizy lub proof of concept,
  • transfer ryzyka na klienta i dodanie wyceny ryzyka do kwoty oferty,
  • transfer ryzyka na poddostawcę przez odpowiednie zapisy umowne.

6. Precyzyjnie określ warunki odbioru

Przeciągające się odbiory etapów projektu lub całości projektu oznaczają dla dostawcy takie konsekwencje:

  • zespół musi spędzić więcej czasu niż planowano nad wspieraniem klienta przy testach, odpowiadaniem na pytania, poprawianiem drobnych błędów, które mogłyby być poprawione w kolejnych fazach, itp.
  • mniejsza dostępność zespołu w kolejnych fazach projektu lub innych projektach, czyli opóźnienia się kaskadują,
  • płatności za etapy są opóźnione, co ma wpływ na płynność firmy,
  • pojawia się ryzyko roszczeń klienta co do kar umownych za opóźnienia.

Aby zminimalizować ryzyko nadmiernego wydłużenia się odbioru etapów (poza oczywistym dostarczeniem jak najlepszej jakości produktu), warto szczegółowo zaplanować jakie będą warunki odbioru i jak będzie przebiegał ten proces.

Zdefiniowanie warunków i procesu odbioru w kontrakcie to m.in.:

  • Określenie klas błędów – co oznacza błąd krytyczny, major, minor, itp. Można to zrobić na przykład w oparciu o listę scenariuszy testowych i ich klasyfikację jako krytyczne, ważne, poboczne,
  • Określenie kryteriów odbioru – jaka jest dopuszczalna ilość błędów w poszczególnych klasach pozwalająca na odbiór. Dla przykładu można dopuścić odbiór warunkowy z błędami typu minor, nie oznacza to, że zostaną one zignorowane, ale będą poprawione w uzgodnionym terminie po odbiorze.
  • Sposób zgłaszania błędów oraz czasy reakcji na ich poprawę – sposób zgłoszenia jest dosyć istotny, bo brak szybkiej możliwości odtworzenia błędu przez dostawcę oznacza wydłużony czas ich naprawy. Można tu określić czego dostawca oczekuje w ramach poprawnego zgłoszenia błędu, np. zrzut ekranu, pełne dane użytkownika, dokładną datę i godzinę, logi aplikacji jeśli brak do nich dostępu.
  • Plan testów – ile czasu będą trwać testy, ile będzie iteracji, które scenariusze będą przetestowane w poszczególnych iteracjach, jakie są odpowiedzialności obu stron, itp.

7. Precyzyjnie określ odpowiedzialności stron

W projektach IT występują zadania, dla których odpowiedzialność może być zarówno po stronie dostawcy jak i klienta. Przykładowe odpowiedzialności, które warto opisać w kontrakcie to:

  • kto przygotuje infrastrukturę IT oraz jaka będzie dostępna liczba środowisk dostępnych dla aplikacji,
  • kto pokryje koszty licencji zewnętrznego oprogramowania i kto będzie się kontaktował z dostawcami,
  • kto przygotuje dane testowe, w jakiej ilości i formie,
  • kto przygotowuje projekty ekranów,

Dobre określenie tych odpowiedzialności przed rozpoczęciem projektu, pozwala lepiej go wycenić oraz uniknąć potencjalnych spięć z klientem. Wszystkie tego typu zadania łatwiej zidentyfikować robiąc dokładny plan projektu, dlatego tak istotne jest zaangażowanie kierownika projektu w przygotowanie oferty oraz kontraktu.

8. Wyceń wsparcie gwarancyjne

Klient może wymagać objęcia produktu okresem gwarancyjnym, po którego zakończeniu podpisywana będzie pogwarancyjna umowa utrzymaniowa. Naprawa błędów w ramach gwarancji jest usługę bezpłatną, więc cena za usługę powinna uwzględniać koszty wsparcia gwarancyjnego. Jeśli w umowie znajdą się zapisy dotyczące gwarancji, to oprócz czasu jej trwania trzeba sprecyzować inne warunki np. czasy reakcji i naprawy błędów.

 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *