Dlaczego Twoje przetargi i RFP zawodzą: przewodnik Design Ops po RFI, RFP i PRD
Poznaj najczęstsze problemy w procesach przetargowych, RFI i RFP, i dowiedz się, jak moim zdaniem można je naprawić. Zbiór przemyśleń na ten temat.
TL;DR / Streszczenie
Wracam po letniej przerwie i jestem gotowy na nowe wpisy. Sporo myślałem o kierunku, w jakim chcę poprowadzić tego bloga, skupiając się na tym, co mnie napędza i czego brakuje w krajobrazie treści. Choć poruszałem popularne tematy, takie jak przegląd narzędzi do osobistej strony i dlaczego Research Ops jest częścią Design Ops!, teraz chcę zagłębić się w bardziej wartościowe treści, dające unikalne, przetestowane w praktyce wartości, podobnie jak mój wpis o narzędziach, na których polegamy codziennie w Design-Ops.
Obecnie moja praca koncentruje się na dwóch głównych celach: zwiększeniu efektywności naszych procesów projektowych i napędzaniu sprzedaży dla naszej grupy. Znaczna część tego procesu sprzedażowego dotyczy świata przetargów, RFI (Request for Information) i RFP (Request for Proposal). Im więcej pracuję w tej przestrzeni, tym wyraźniej widzę krytyczną potrzebę poprawy. Byłem odpowiedzialny za przygotowanie wielu ofert i prowadzenie analiz biznesowych, i szczerze mówiąc, często jestem zaskoczony, jak słabo te kluczowe dokumenty są przygotowywane.
To nie jest tylko narzekanie; to diagnoza. Sposób, w jaki prosimy o pracę, bezpośrednio wpływa na jakość pracy, którą otrzymujemy. Przeanalizujmy problem i zbadajmy bardziej efektywne, design-driven rozwiązanie.
Alfabet zamówień: krótkie spojrzenie na przetargi, RFI, RFP i PRD
Zanim przejdziemy do analizy problemów, uporządkujmy terminologię. Te akronimy są często używane zamiennie, ale reprezentują odrębne etapy w cyklu życia zamówień i rozwoju produktu. Ich zrozumienie to pierwszy krok do efektywnego wykorzystania.
-
RFI (Request for Information): To faza eksploracyjna. Firma używa RFI do zebrania ogólnych informacji od różnych dostawców o ich możliwościach. To jak oglądanie wystaw – nie jesteś jeszcze gotowy do zakupu, ale chcesz zobaczyć, co jest na rynku i kto jest kluczowym graczem.
-
RFP (Request for Proposal): To formalne zaproszenie do złożenia oferty. RFP dostarcza szczegółowych informacji o konkretnym projekcie lub potrzebie i prosi dostawców o przedstawienie propozycji rozwiązania, harmonogramu i oczywiście kosztów.
-
Przetarg: Często używany zamiennie z RFP, przetarg to bardziej formalny, ustrukturyzowany i często publiczny proces zamawiania towarów lub usług. Jest powszechny w projektach rządowych i dużych korporacyjnych.
-
PRD (Product Requirements Document): To dokument wewnętrzny, ale jest sekretnym składnikiem dobrego RFP. PRD jasno artykułuje cel produktu, funkcje, funkcjonalność i zachowanie. To plan. Bez solidnego PRD, RFP to tylko lista życzeń zbudowana na chwiejnych fundamentach.
Pułapka przetargowa: powszechne problemy, które widzę każdego dnia
Celem każdego przetargu lub RFP jest znalezienie najlepszego partnera do dostarczenia najlepszego rozwiązania za uczciwą cenę. Jednak proces jest często tak skonstruowany, że osiąga odwrotny efekt. Oto najczęstsze pułapki, z jakimi się spotkałem, szczególnie na polskim rynku.
Paradoks „tylko cena"
W Polsce istnieje silna tendencja do tworzenia przetargów ocenianych niemal wyłącznie na podstawie jednego kryterium: ceny. Choć budżet jest niewątpliwie ważny, ocena oparta wyłącznie na cenie tworzy wyścig do dna. Zachęca agencje do cięcia kosztów, niedostatecznego obsadzania projektów i pomijania kluczowych faz odkrywania i badań, aby złożyć najniższą ofertę.
Niejasne vs. nadmiernie szczegółowe RFP
Stale widzę RFP, które wpadają w jedną z dwóch niepomocnych kategorii:
-
Czarna skrzynka: Dokument jest tak niejasny i słabo zdefiniowany, że niemożliwe jest stworzenie dokładnego szacunku lub zaproponowanie sensownego rozwiązania.
-
Zamknięta skrzynka: Dokument jest tak hiper-szczegółowy, że wydaje się napisany pod konkretnego dostawcę. Niedawno analizowałem przetarg dla miasta Tarnów, gdzie opis modelu 3D był tak szczegółowy – aż do specyfikacji technicznych nieadekwatnych do wymagań wydajnościowych – że silnie sugerował, iż istniejący zasób był już przeznaczony na to zlecenie.
Labirynt NDA
Umowy o poufności to standardowa część biznesu, ale mogą być nadużywane w procesie RFP. Niedawno złożyłem ofertę i wygrałem projekt, w którym zakres prac omówiony po podpisaniu NDA był zasadniczo inny od tego opisanego w dokumentach przetargowych.
Choć rozumiem potrzebę poufności, ta podmiana marnuje ogromną ilość czasu i zasobów wszystkich firm składających oferty. Prosta klauzula stwierdzająca, że „dalsze kluczowe szczegóły zostaną ujawnione w ramach NDA" byłaby bardziej przejrzystym podejściem.
Syndrom „Myślimy, że wiemy, czego chcemy"
To klasyczny scenariusz w świecie agencyjnym. Potencjalny klient przychodzi do nas z prośbą o konkretne oprogramowanie. Inwestujemy czas w wycenę i przygotowanie oferty. A potem, gdy zaczynamy z nimi rozmawiać, okazuje się, że to, o co proszą, jest zupełnie inne od tego, czego naprawdę potrzebują.
To naturalna część procesu sprzedaży i odkrywania, ale wskazuje na głębszy problem. Ile firm przechodzi przez pełny proces przetargowy, podpisuje umowę i rozpoczyna projekt na warunkach, których żadna ze stron w pełni nie rozumie?
Anatomia dobrego przetargu: moja propozycja
Nie jest jednak tak źle. Niedawno miałem okazję przeanalizować przetarg dla miasta Olsztyn i to był powiew świeżego powietrza. Choć nie idealny, był fantastycznym przykładem tego, co należy robić dobrze. Wymagania były jasno określone, dając nam solidną podstawę do wyceny. Zawierał nawet diagramy pomagające wizualizować złożone części systemu.
„komunikacja jest najważniejszym czynnikiem sukcesu w projektach IT"
Wszystko sprowadza się do fundamentalnej prawdy naszej branży. Jak zauważono w badaniu z 2017 roku, „komunikacja jest najważniejszym czynnikiem sukcesu w projektach IT" (Stevenson & Starkweather, 2017), więc powinna być dostosowana do swojego odbiorcy. Przetarg to pierwsza i prawdopodobnie najważniejsza komunikacja w projekcie.
Rozwiązanie: design thinking w zamówieniach
Jak to naprawić? Odpowiedź leży w zastosowaniu tych samych zasad, których używamy do budowania świetnych produktów: praktyk discovery i user experience (UX). Musimy traktować sam proces zamówień jako problem projektowy.
Zacznij od wewnętrznego PRD
Źródłem większości złych RFP jest brak wewnętrznej jasności. Zanim zaczniesz pisać RFP, Twój zespół musi stworzyć solidny PRD. To obejmuje:
- Warsztaty ze stakeholderami: Zbierz wszystkich kluczowych decydentów. Jakie są cele biznesowe? Jaki problem naprawdę próbujemy rozwiązać?
- Badania użytkowników: Dla kogo jest ten produkt? Jakie są ich potrzeby i bolączki?
- Definiowanie zakresu: Użyj technik jak mapowanie user stories, żeby zdefiniować kluczowe funkcje i je priorytetyzować (np. metoda MoSCoW).
Pisz RFP jak UX writer
Pomyśl o dostawcach czytających Twoje RFP jak o użytkownikach. Twoim celem jest pomóc im szybko i jasno zrozumieć Twoje potrzeby.
- Struktura i hierarchia: Używaj jasnych nagłówków, list wypunktowanych i logicznego przepływu. Zacznij od „dlaczego" (problem biznesowy) przed przejściem do „co" (wymagania).
- Jasność ponad żargonem: Unikaj niejednoznacznego języka. Definiuj terminy. Jeśli wymaganie jest złożone, dodaj diagram.
- Dostarczaj kontekst: Nie tylko wymieniaj funkcje. Wyjaśniaj scenariusz użytkownika za każdym wymaganiem.
Stosując te zasady, przekształcasz swoje RFP z mylącego zestawu żądań w jasny, przekonujący brief projektowy, który przyciąga właściwych partnerów.
Idąc naprzód efektywnie
Świetnie jest wrócić na właściwe tory i dzielić się z Wami tymi przemyśleniami. Mój focus przesuwa się w stronę tych bardziej systemowych, operacyjnych wyzwań, bo tam wierzę, że możemy mieć największy wpływ. Lepsze przetargi, RFI i RFP prowadzą do lepszych współprac, lepszych produktów i mniej zmarnowanego czasu i pieniędzy dla wszystkich. A gdy mówimy o przetargach publicznych – to ciężko zarobione pieniądze.
Będę dążył do cotygodniowych wpisów i jestem też podekscytowany rozpoczęciem małej serii na YouTube. Mam nadzieję, że Wam się spodoba.
Bądźmy efektywni!
Źródła
Deborah Stevenson & Jo Ann Starkweather, 2017.
IT Project Success: The Evaluation of 142 Success Factors by IT PM Professionals,
International Journal of Information Technology Project Management (IJITPM), IGI Global Scientific Publishing, vol. 8(3), pages 1-21, July.