Scope creep — gdy „jedna mała zmiana” zaczyna sterować projektem

Scope creep zaczyna się wtedy, gdy kolejne drobne ustalenia przestają być widoczne jako decyzje projektowe. Każde wydaje się niewielkie, ale razem zmieniają skalę przedsięwzięcia.

Co jest zmianą, a co nią nie jest

Nie każde dodatkowe działanie powinno być płatną zmianą zakresu. Jeżeli dostarczona funkcja nie spełnia uzgodnionych kryteriów, jej poprawienie jest realizacją zobowiązania. Doprecyzowanie niejasnego wymagania również wymaga oceny odpowiedzialności obu stron.

Zmianą jest nowa potrzeba albo nowy sposób realizacji, którego nie można rozsądnie wyprowadzić z uzgodnionego zakresu. Oddzielenie tych kategorii zapobiega zarówno nieuzasadnionym kosztom, jak i dokładaniu dostawcy pracy bez wynagrodzenia.

Jak rozpoznać scope creep

• Nowe funkcje są uzgadniane ustnie podczas spotkań.
• Pomysły trafiają bezpośrednio do programistów bez decyzji właściciela produktu.
• Nie ma rejestru zmian albo jest aktualizowany po fakcie.
• Rosną koszty i terminy, ale zakres bazowy formalnie się nie zmienia.
• Każdy dział próbuje dopisać swoje potrzeby do wspólnego wdrożenia.
• Nie wiadomo, co zostało usunięte po dodaniu nowych elementów.
• Zespół nie rozróżnia błędów, doprecyzowań i nowych wymagań.

Każda zmiana ma cenę decyzji

Cena nie zawsze oznacza dodatkową fakturę. W projekcie ze stałym zespołem i budżetem nowa funkcja może zastąpić element o niższym priorytecie. Można również przesunąć termin albo zwiększyć środki.

Niebezpieczna jest sytuacja, w której organizacja chce zachować jednocześnie dotychczasowy zakres, termin i budżet, mimo że ilość pracy rośnie. Wtedy koszt ujawnia się później jako spadek jakości, opóźnienie albo konflikt przy odbiorze.

Minimalny proces zarządzania zmianą

1. Opis potrzeby i uzasadnienie biznesowe.
2. Wskazanie, czy jest to błąd, doprecyzowanie czy nowy zakres.
3. Ocena wpływu na koszt, termin, ryzyko i pozostałe funkcje.
4. Rekomendacja: dodać, odłożyć, zastąpić inny element albo odrzucić.
5. Decyzja osoby posiadającej właściwy mandat.
6. Aktualizacja backlogu, budżetu, harmonogramu i dokumentacji.

Jak zapobiegać przed rozpoczęciem projektu

• Opisać cel i granice przedsięwzięcia.
• Wskazać elementy poza zakresem.
• Ustalić priorytety i zakres pierwszej wersji.
• Przygotować kryteria akceptacji.
• Zapisać w umowie sposób wyceny oraz zatwierdzania zmian.
• Wyznaczyć jednego właściciela decyzji produktowych.
• Zapewnić regularny przegląd rejestru zmian.

Zmiana może być wartościowa

Dobry proces nie służy blokowaniu pomysłów. Pozwala odróżnić zmianę, która zwiększa wartość projektu, od funkcji dodawanej dlatego, że ktoś zobaczył podobny ekran u konkurencji.

Najważniejsze pytanie nie brzmi: „czy potrafimy to dodać?”, lecz: „czy jest to najlepsze wykorzystanie pozostałego budżetu i czasu?”. Bieżącą kontrolę zmian zapewnia nadzór projektu IT.