Ile kosztuje zmiana zakresu (i dlaczego scope creep zjada marżę)

Zmiana zakresu w trakcie projektu wygląda niewinnie: „dorzućcie tylko logowanie przez Google", „dodajmy jeszcze jeden raport". Każda wydaje się drobiazgiem. Razem potrafią pochłonąć cały zysk z projektu – jeśli nikt ich nie wycenia.

Skąd bierze się strata marży

Scope creep to nie margines: według PMI (Pulse of the Profession) doświadcza go około połowy projektów – 52%, i odsetek rośnie (wzrost z 43% pięć lat wcześniej).

Przy stałym budżecie każda niewyceniona zmiana to praca, za którą nikt nie zapłacił – finansujesz ją z własnej marży. Zwykle pokusa jest ta sama: „to drobiazg, zrobimy", bo policzenie zmiany na szybko jest trudne, a powiedzenie Klientowi „to kosztuje dodatkowo" niewygodne. Łatwiej wziąć tę pracę na siebie.

Po kilku takich drobiazgach projekt, który na papierze miał zarobić, schodzi pod kreskę. Nie przez jedną wielką pomyłkę, tylko przez serię małych ustępstw, których nikt nie policzył.

Kto naprawdę za to płaci

Konkretna kwota zależy od projektu, ale mechanizm zwykle jest podobny: praca poza zakresem ma realną cenę, a przy stałym budżecie płaci ją wykonawca, nie Klient. Im więcej takich zmian weźmiesz na siebie, tym bliżej do projektu, na którym dokładasz zamiast zarabiać.

Skala potrafi być duża: w badaniu McKinsey i Uniwersytetu Oksfordzkiego (5400 projektów IT) duże wdrożenia przekraczały budżet średnio o 45% i dostarczały 56% mniej wartości, niż zakładano. To akurat projekty prowadzone z dużym rygorem – w mniejszym projekcie bez kontroli zmian budżet rozjeżdża się jeszcze łatwiej.

Dlatego część agencji sprzedaje samo doprecyzowanie zakresu (tak zwane discovery) jako osobną, płatną usługę, a wycenę większej zmiany traktuje jak nową pozycję w ofercie, nie gratis.

Dlaczego agencje tego nie liczą

Nie z lenistwa. Rzetelne wycenienie zmiany jest trudne: trzeba policzyć ją tą samą metodą co pierwotna wycena, żeby wynik był porównywalny z pierwotną ofertą, a potem uzasadnić ją Klientowi. Liczenie „na oko" albo w Excelu ad hoc kończy się tak, że albo zaniżasz, albo nowa wycena traci spójność z pierwotną. Tak czy inaczej tracisz: albo dokładasz z własnej marży, albo zmiana w ogóle zostaje nierozliczona.

Jak to robić dobrze: licz zmianę jako różnicę

Nie przeliczaj całego projektu od zera. Policz różnicę: co dochodzi do zakresu, co z niego znika, o ile zmienia się budżet i termin. Różnica policzona tą samą metodą co pierwotna wycena jest spójna – Klient widzi ten sam sposób liczenia, tylko zastosowany do zmiany.

Potem pokaż mu „przed i po": budżet i czas sprzed zmiany obok budżetu i czasu po zmianie. To przenosi rozmowę z „czemu liczycie dodatkowo" na „ta zmiana kosztuje tyle i przesuwa termin o tyle – robimy?". Decyzja wraca do Klienta, a Tobie łatwiej pilnować marży projektu.

Jeśli roboczodni (MD) są dla Ciebie czymś nowym, zacznij od sprawdzenia, czym jest roboczodzień, a potem – co musi zawierać dobra wycena.

Policz samą zmianę

Do tego służy wycena zmiany zakresu: wklejasz pierwotny zakres i opis zmiany od Klienta, a otrzymujesz różnicę w roboczodniach i kartę „przed/po" (budżet i czas) gotową do wysłania. Policzona tą samą metodą co pełna wycena z briefu – więc jest spójna z pierwotną ofertą.

Źródła

• PMI, Pulse of the Profession 2018 – 52% projektów doświadczyło scope creep (wzrost z 43%): pmi.org.
• McKinsey i Uniwersytet Oksfordzki (2012), Delivering large-scale IT projects on time, on budget, and on value – 45% przekroczenia budżetu, 56% mniej wartości (5400 projektów): mckinsey.com.