PMI PMP: Zarządzanie zamówieniami i umowami — Przewodnik do nauki

By Laurynas Brazys · 21 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Część PMP — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów PMI, albo rozwiąż testy na czas na ExamRoll.io.

Rodzaje i struktura umów: Dopasowanie instrumentu do ryzyka

Rodzaj umowy to najważniejsza decyzja w procesie zamówień, ponieważ określa, kto ponosi jakie ryzyko i gdzie skierowane są zachęty. Umowy o stałej cenie (FFP, Firm Fixed-Price) przerzucają ryzyko związane z zakresem, harmonogramem i kosztem na sprzedawcę i sprawdzają się, gdy opis przedmiotu zamówienia (SOW, Statement of Work) jest stabilny i dobrze zdefiniowany — na przykład przewidywalna relokacja siedziby głównej ze znaną listą usterek do usunięcia. Umowy typu czas i materiały (T&M, Time-and-Materials) przenoszą ryzyko na kupującego, ale zapewniają elastyczność w reagowaniu na pojawiające się wymagania; pasują do powiększania personelu (staff augmentation), prac odkrywczych i wczesnych etapów rozwoju zwinnego, gdzie backlog jest autentycznie nieznany. Warianty oparte na zwrocie kosztów (CPFF, CPIF, CPAF) plasują się pośrodku i są użyteczne, gdy praca ma charakter eksploracyjny, ale kupujący chce powiązać zachęty z celami kosztowymi lub wydajnościowymi.

Punktem spornym w nowoczesnych projektach jest zderzenie między realizacją w metodyce zwinnej a komercyjnymi oczekiwaniami dotyczącymi stałej ceny. Kierownictwo często oczekuje pewności cenowej, jaką daje umowa FFP, podczas gdy zespół deweloperski potrzebuje elastyczności zakresu, charakterystycznej dla Scrum. Podpisanie umowy FFP na niezdefiniowany zakres zwinny to jedna z najbardziej szkodliwych pułapek w procesie zamówień: sprzedawca albo znacznie zawyży cenę, aby pokryć niewiadome, odmówi zmian wykraczających poza wąsko interpretowany SOW, albo poniesie straty, które ostatecznie ujawnią się jako kompromisy jakościowe i spory. Właściwą odpowiedzią nie jest rezygnacja z umów o stałej cenie, ale uzupełnienie ich o mechanizmy kontrolne dostosowane do metodyk zwinnych.

Szczególnie skuteczne są dwa mechanizmy strukturalne:

• Poziomy zakresu (must-have / should-have / could-have)
  • Jak to działa: Umowa zobowiązuje do realizacji poziomu „must-have”; niższe poziomy są dostarczane w miarę dostępnych mocy przerobowych
  • Co to chroni: Rentowność i pewność dostarczenia kluczowego zakresu
• Limity iteracji/sprintów
  • Jak to działa: Stała liczba sprintów lub całkowity wysiłek nieprzekraczający określonego pułapu
  • Co to chroni: Zapobiega nieograniczonym żądaniom poprawek pod pretekstem „to przecież agile”
• Wymiana „zmiana za zmianę”
  • Jak to działa: Nowe elementy backlogu wymagają usunięcia elementów o równoważnym nakładzie pracy
  • Co to chroni: Utrzymuje ramy kosztowe i harmonogramowe
• Wycena oparta na wydaniach
  • Jak to działa: Każde wydanie jest ponownie wyceniane na podstawie doprecyzowanego backlogu
  • Co to chroni: Harmonizuje cykl komercyjny z cyklem dostarczania

W przypadku programu hybrydowego – na przykład przewidywalnej przeprowadzki siedziby połączonej ze zwiną migracją systemów – jeden rodzaj umowy rzadko pasuje do obu strumieni prac. Prawidłową strukturą jest często umowa FFP dla deterministycznej, fizycznej przeprowadzki oraz T&M (lub T&M z poziomami/pułapem) dla migracji, albo umowa ramowa o świadczenie usług z oddzielnymi zleceniami wykonawczymi dla każdego strumienia.

Polityka zamówień, SOW i wybór dostawcy

Każda decyzja dotycząca zamówienia musi mieć swoje źródło w formalnej polityce zamówień organizacji. To nie jest biurokratyczna formalność – to mechanizm, który ustanawia uprawnienia, zapewnia uczciwą konkurencję, spełnia obowiązki audytowe i regulacyjne oraz zapewnia obronę prawną, jeśli przegrany oferent zakwestionuje wybór. Kierownik projektu, który omija dział zamówień, aby „działać szybciej”, naraża siebie i organizację na ryzyko, które znacznie przewyższa wszelkie korzyści harmonogramowe.

Opis przedmiotu zamówienia (SOW) to dokument operacyjny, który przekształca intencje w zobowiązania. Dobrze przygotowany SOW określa produkty i kryteria akceptacji, standardy wydajności (czasy odpowiedzi, progi defektów, dostępność), częstotliwość i format raportowania, prawa do inspekcji i audytu, klauzule dotyczące personelu kluczowego, środki zaradcze w przypadku niewykonania umowy (kary umowne, kredyty usługowe, prawa do przejęcia wykonawstwa) oraz warunki rozwiązania umowy. Niejasne SOW są główną przyczyną większości późniejszych sporów, ponieważ niejednoznaczność jest zawsze rozstrzygana na korzyść strony, której interpretację pisemne sformułowania najbardziej wspierają.

Wybór dostawcy powinien odbywać się zgodnie z udokumentowanymi kryteriami oceny zawartymi w planie zamówień — oceną ważoną uwzględniającą zdolności techniczne, dotychczasowe wyniki, stabilność finansową, dopasowanie kulturowe i cenę. Każda decyzja, od krótkiej listy oferentów po ostateczny wybór, musi być udokumentowana wraz z uzasadnieniem, osobami oceniającymi i uzyskanymi zgodami. Gdy pojawią się audytorzy, organy regulacyjne lub przegrani oferenci, dokumentacja musi mówić sama za siebie.

Wydajność dostawcy, integracja i rozwiązywanie sporów

Umowy nie zarządzają się same. Po rozpoczęciu prac kierownik projektu staje się terenowym administratorem umowy ze strony nabywcy. Monitorowanie wydajności oznacza egzekwowanie od sprzedawcy rytmu raportowania wymaganego przez SOW, przeprowadzanie inspekcji i przeglądów jakości w określonych w umowie punktach oraz formalne stosowanie środków zaradczych w przypadku obniżenia wydajności — a nie tolerowanie odchyleń, a następnie narzekanie przy zamykaniu projektu.

Egzekwowanie powinno być stopniowe. Wczesne sygnały (brak raportu o stanie, niewielkie opóźnienie w kamieniu milowym) uzasadniają udokumentowaną rozmowę i zobowiązanie do podjęcia działań naprawczych. Powtarzające się lub istotne naruszenia uruchamiają formalne powiadomienia, okresy na usunięcie naruszeń, a jeśli problem nie zostanie rozwiązany, środki zaradcze przewidziane w umowie: wstrzymanie płatności, kary umowne lub wypowiedzenie z winy wykonawcy. Kluczową zasadą PMI jest wczesne eskalowanie problemów i ocena alternatyw przed podjęciem jednostronnych działań. Wypowiedzenie umowy dostawcy bez uprzedniego wyczerpania procedur naprawczych lub rezygnacja z podwykonawcy bez planu ciągłości działania naraża projekt zarówno na roszczenia prawne, jak i na załamanie realizacji.

Rozważmy sytuację podwykonawcy, który dostarcza aplikację zgodną technicznie z SOW, ale niespełniającą standardu UI przyjętego po podpisaniu umowy. Podwykonawca ma rację z punktu widzenia umowy — nowy standard nie był zawarty w SOW — a jego żądanie dodatkowej zapłaty jest uzasadnione. Prawidłową reakcją jest złożenie formalnego wniosku o zmianę, zaangażowanie działu zamówień i działu prawnego w celu zmiany SOW oraz dostosowania ceny i harmonogramu, a dopiero potem autoryzacja poprawek. Naleganie, aby dostawca wziął na siebie koszt zmiany, jest naruszeniem umowy; nieformalne zezwolenie na zmianę bez aneksu jest jeszcze gorsze, ponieważ tworzy precedens, że produkty mogą odbiegać od ustaleń bez przeglądu umowy czy płatności — i tworzy niejasność co do tego, kto jest odpowiedzialny za powstałe wady.

Integracja podwykonawców i wspólna praca

Podwykonawcy osiągają najlepsze wyniki, gdy są traktowani jako część zespołu realizacyjnego, a nie jak czarna skrzynka za fasadą umowy. Skuteczna integracja obejmuje wspólne warsztaty inauguracyjne, uzgodnione zasady komunikacji i podejmowania decyzji, wspólne definicje ukończenia i kryteria akceptacji, zintegrowane backlogi lub harmonogramy oraz połączone rejestry ryzyk. W kontekstach zwinnych (agile) deweloperzy podwykonawcy powinni uczestniczyć w tych samych ceremoniach co pracownicy wewnętrzni, przy czym zapisy umowne powinny pozwalać na taką współpracę bez zacierania granicy handlowej.

Zmiany w umowie, ciągłość działania i warunki płatności

Każda istotna zmiana — zakres, cena, harmonogram, personel kluczowy, kryteria akceptacji — musi przejść przez formalną zmianę w umowie, zatwierdzoną przez dział zamówień i dział prawny, a nie przez poboczną wiadomość e-mail między kierownikiem projektu a liderem ze strony dostawcy. Warunki płatności powinny być powiązane z akceptacją kamieni milowych, a nie z terminami fakturowania, tak aby pieniądze podążały za wykazaną wartością.

Planowanie ciągłości działania dostawcy powinno znaleźć się w rejestrze ryzyk od pierwszego dnia, a nie dopiero po wystąpieniu zakłóceń. Kluczowe pytania: Co się stanie, jeśli dostawca zbankrutuje, zostanie przejęty lub straci kluczowy personel? Czy w umowie zapisano obowiązek depozytu kodu źródłowego, standardy dokumentacji i przekazania wiedzy? Czy istnieje kwalifikowany dostawca alternatywny? Czekanie z myśleniem o ciągłości działania do momentu upadku dostawcy gwarantuje kryzys w projekcie; zajęcie się tym na etapie strukturyzacji umowy przekształca potencjalną katastrofę w zarządzane ryzyko.

Problem praktyczny: Scenariusz użycia

Scenariusz: Meridian Financial modernizuje swoją platformę do onboardingu klientów, zastępując 12-letni system legacy. Komitet sterujący zatwierdził budżet w wysokości 4,2 mln USD na 14 miesięcy i wybrał zewnętrznego dostawcę, Northwind Digital, do realizacji projektu w metodyce Scrum. Podczas negocjacji umowy dyrektor ds. zamówień w Meridian nalega na umowę typu FFP (firm fixed-price) na cały zakres, aby chronić budżet, podczas gdy przedstawiciel handlowy Northwind naciska na umowę T&M (time-and-materials), ponieważ backlog produktu zawiera tylko 40% historyjek użytkownika w stanie gotowości (ready), a integracje z trzema systemami podrzędnymi są wciąż w fazie analizy.

Wyzwanie: Jako kierownik projektu musisz zarekomendować dyrektorowi ds. zamówień strukturę umowy, która zapewni Meridian rozsądną przewidywalność kosztów, nie zmuszając jednocześnie Northwind do zawyżania szacunków lub opierania się przed doprecyzowaniem zakresu w trakcie sprintu.

Zalecane podejście:

1. Podziel projekt na dwie fazy kontraktowe: fazę odkrywczą (discovery) w modelu T&M (około 6 tygodni, z limitem 180 tys. USD) w celu ukończenia doprecyzowania backlogu, analizy integracji i wykonania spajków architektonicznych przed rozpoczęciem głównej fazy budowy.
2. Ustrukturyzuj fazę realizacji jako umowę o stałej cenie za sprint — Northwind zobowiązuje się do zapewnienia stabilnego zespołu 8 specjalistów za stałą cenę za sprint wynoszącą około 95 tys. USD za dwutygodniowy sprint, z górnym limitem nieprzekraczalnym (not-to-exceed) w wysokości 3,6 mln USD na przestrzeni 34 sprintów.
3. Zdefiniuj zakres komercyjnie jako priorytetyzowany backlog, a nie sztywny SOW, i dołącz „klauzulę wymiany” (swap clause), pozwalającą Meridian na zamianę historyjek o równoważnej wielkości w punktach historyjki (story points) bez zlecenia zmiany (change order).
4. Wprowadź klauzule wyjścia (exit ramps) w sprintach 6, 12 i 20, pozwalające Meridian na wypowiedzenie umowy bez podania przyczyny z 30-dniowym wyprzedzeniem, co chroni budżet w przypadku, gdyby dostarczanie wartości uległo zahamowaniu.
5. Powiąż zatwierdzenie faktury z obiektywnymi kryteriami akceptacji dla każdego sprintu (definicja ukończenia, pokrycie testami automatycznymi powyżej 80%, zero krytycznych defektów).
6. Przedstaw rekomendowaną strukturę działowi zamówień, działowi prawnemu i sponsorowi wraz z jednostronicowym podsumowaniem alokacji ryzyka, zanim Northwind kontrasygnuje umowę.

Dlaczego to działa: Dopasowanie typu umowy do dojrzałości wymagań jest podstawową zasadą PMI w zakresie zamówień — narzucanie umowy FFP na niezdefiniowany zakres zwinny przenosi ryzyko tylko z nazwy, ponieważ sprzedawcy wyceniają się asekuracyjnie lub dochodzą swoich praw sądownie przy wnioskach o zmianę. Model stałej ceny za sprint zachowuje przewidywalność kosztów, której potrzebuje sponsor, jednocześnie utrzymując elastyczność backlogu, a faza odkrywcza zapobiega zobowiązywaniu się obu stron do liczb opartych na założeniach, a nie na dowodach.

← Zarządzanie jakością i akceptacja · Wszystkie domeny · Planowanie i integracja projektu →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →