Spis treści5 sekcji
Projekt został wyceniony, zakres zaakceptowany, harmonogram ustalony. Realizacja przebiega zgodnie z planem, aż klient zaczyna zgłaszać kolejne „drobne" prośby.
Nowy filtr w panelu. Dodatkowe pole w formularzu. Jeszcze jeden wariant widoku. Zmiana wcześniej zaakceptowanego procesu. Mała integracja, która „przecież nie powinna zająć dużo czasu".
Każda z tych próśb osobno wydaje się zbyt niewielka, aby rozpoczynać formalną procedurę zmiany zakresu. Zespół chce utrzymać dobrą relację z klientem, więc realizuje zadanie w ramach projektu.
Po kilku tygodniach okazuje się jednak, że dodatkowe prace zajęły kilkadziesiąt godzin, budżet czasowy został przekroczony, a zakładanna marża niemal zniknęła.
Wiemy, jak to jest, gdy projekt nie traci rentowności przez jeden duży błąd, lecz przez serię małych decyzji podejmowanych każdego dnia.
Scope creep w projekcie IT zaczyna się właśnie wtedy, gdy zakres rośnie bez równoczesnej aktualizacji ceny, terminu i budżetu. Aby go ograniczyć, trzeba odróżnić poprawkę od nowej funkcjonalności, rejestrować każdą zmianę i pokazywać jej łączny wpływ na koszt projektu.
Projekt został wyceniony, zakres zaakceptowany, harmonogram ustalony. Realizacja przebiega zgodnie z planem, aż klient zaczyna zgłaszać kolejne „drobne" prośby.
Dlaczego bezpłatne poprawki tak szybko obniżają marżę projektu IT?
Klient nie zawsze świadomie próbuje rozszerzyć zakres bez dodatkowej opłaty. Często dopiero podczas realizacji lepiej rozumie produkt, zauważa nowe potrzeby albo zmienia wcześniejsze założenia.
Problemem nie jest sama zmiana. Problem pojawia się wtedy, gdy zespół wykonuje ją bez oceny wpływu na budżet.
„To tylko dwie godziny" powtarza się wiele razy
Pojedyncza prośba może rzeczywiście zająć dwie godziny. Trzeba jednak uwzględnić także:
- analizę wymagania,
- konsultację z zespołem,
- zmianę projektu UX lub UI,
- development,
- testy,
- code review,
- wdrożenie,
- komunikację z klientem,
- aktualizację dokumentacji,
- ewentualne poprawki po odbiorze.
Zadanie, które z perspektywy klienta wygląda jak szybka zmiana, może angażować kilka osób i wygenerować znacznie większy koszt.
Jeżeli podobne prośby pojawiają się co tydzień, ich łączna wartość przestaje być nieistotna.
Zespół chce pomóc klientowi
Specjaliści zwykle koncentrują się na rozwiązaniu problemu. Jeżeli klient prosi o zmianę, developer albo designer często zaczyna szukać sposobu jej wykonania, zamiast najpierw analizować wpływ na zakres umowy.
W firmach usługowych działa też silny mechanizm psychologiczny:
- nie chcemy utrudniać współpracy,
- klient może uznać nas za mało elastycznych,
- prygotowanie wyceny zajmie więcej czasu niż sama poprawka,
- nadbrymy te godziny w kolejnym etapie,
- to ważny klient, więc zróbmy wyjątek.
W efekcie decyzja finansowa zostaje podjęta przez osobę, która nie zawsze zna budżet i aktualną marżę projektu.
Brakuje jasnej definicji poprawki
Jednym z największych źródeł konfliktu jest brak rozróżnienia między błędem a zmianą zakresu.
Poprawką błędu jest doprowadzenie rozwiązania do stanu zgodnego z zatwierdzoną specyfikacją.
Zmianą zakresu może być natomiast:
- nowa funkcjonalność,
- zmiana wcześniej zaakceptowanego rozwiązania,
- dodatkowa integracja,
- kolejny wariant widoku,
- rozszerzenie liczby użytkowników lub procesów,
- nowe wymaganie techniczne,
- dodatkowy etap migracji,
- zmiana wynikająca z nowej decyzji biznesowej klienta.
Jeżeli umowa i proces projektowy nie definiują tej różnicy, klient może traktować każdą zmianę jako poprawkę objętą ceną.
Dodatkowe godziny znikają w ogólnym czasie projektu
Nawet gdy zespół raportuje czas, dodatkowa praca często trafia do zwykłych zadań projektowych.
Po kilku miesiącach firma widzi, że budżet został przekroczony, ale nie potrafi odpowiedzieć:
- ile godzin wynikało z błędnej estymacji,
- ile przeznaczono na poprawki błędów,
- ile zajęły nowe wymagania klienta,
- jaka była wartość prac wykonanych bezpłatnie,
- które zmiany zostały zaakceptowane,
- jaki wpływ miały na marżę.
Bez takiego podziału trudno wyciągnąć wnioski i przygotować rzeczową rozmowę z klientem.
Jak ograniczyć scope creep w projekcie IT?
Skuteczne zarządzanie zmianą nie polega na odmawianiu klientowi każdej dodatkowej prośby. Chodzi o to, aby każda zmiana była świadomą decyzją biznesową.
1. Zdefiniuj zakres i kryteria odbioru przed rozpoczęciem prac
Im bardziej ogólny zakres, tym więcej miejsca na różne interpretacje.
Dokumentacja powinna określać:
- jakie funkcjonalności zostaną wykonane,
- jakie procesy obejmuje projekt,
- które integracje są częścią wyceny,
- ile wariantów projektowych przewidziano,
- ile rund poprawek obejmuje cena,
- co oznacza zakończenie etapu,
- jakie są kryteria odbioru,
- czego projekt nie obejmuje.
Warto również opisać procedurę postępowania w przypadku nowych wymagań.
2. Wprowadź prosty proces zgłaszania zmian
Procedura nie może być tak rozbudowana, aby zespół omijał ją przy każdej mniejszej prośbie.
Każda zmiana powinna otrzymać:
- krótki opis,
- osobę zgłaszającą,
- datę zgłoszenia,
- projekt i etap,
- ocenę, czy mieści się w zakresie,
- szacowaną liczbę godzin,
- koszt,
- wpływ na harmonogram,
- status akceptacji.
Dzięki temu nawet niewielkie zgłoszenia nie znikają w wiadomościach, rozmowach i komentarzach do zadań.
3. Oddzielaj błędy, poprawki w zakresie i prace dodatkowe
Każde zgłoszenie warto zakwalifikować do jednej z kategorii:
Błąd wykonawcy
Rozwiązanie nie działa zgodnie z zaakceptowaną specyfikacją. Koszt poprawy obciąża wykonawcę.
Poprawka w ustalonym zakresie
Zmiana mieści się w uzgodnionej liczbie rund lub buforze projektowym.
Nowy zakres
Klient zmienia wymaganie albo dodaje element, którego nie uwzględniono w wycenie. Praca wymaga osobną akceptacji.
Taki podział porządkuje komunikację i ogranicza dyskusje o tym, kto powinien pokryć koszt.
4. Pokazuj łączny wpływ zmian na budżet
Pojednicza zmiana może być niewielka, ale klient powinien widzieć ich sumę.
Przykład:
- zmiana formularza: 4 godziny,
- dodatkowy widok: 10 godzin,
- nowy raport: 12 godzin,
- rozszerzenie integracji: 16 godzin,
- kolejne konsultacje: 6 godzin.
Łącznie to 48 dodatkowych godzin.
Jeżeli firma pokaże klientowi wyłącznie ostatnią zmianę, może ona wydawać się nieistotna. Zestawienie całego dodatkowego zakresu pokazuje rzeczywistą skalę zaangażowania.
Jak rozwiązaliśmy scope creep w Administy?
Prowadząc agencje i realizując projekty cyfrowe, sami wielokrotnie wykonywaliśmy dodatkowe prace bez formalnej zmiany zakresu.
Najczęściej nie wynikało to z jednego dużego zlecenia. Problemem były drobne prośby klienta:
- jeszcze jedna wersja projektu,
- dodatkowa podstrona,
- nowy wariant formularza,
- kolejna integracja,
- zmiana wcześniej zaakceptowanego widoku,
- dodatkowe spotkanie,
- poprawka wynikająca z nowej decyzji biznesowej.
Każda z osobna wydawała się niewielka. Zespół realizował ją, ponieważ nie chciał zatrzymywać projektu ani komplikować relacji z klientem.
Błąd polegał na tym, że dodatkowe godziny trafiały do ogólnego czasu projektu. Widzieliśmy rosnące wykorzystanie budżetu, ale nie zawsze potrafiliśmy jednoznacznie wskazać, jaka część kosztu wynikała z rozszerzenia zakresu.
Dlatego zaczęliśmy rejestrować dodatkowe prace jako osobne pozycje.
Każda zmiana otrzymuje:
- opis dodatkowego wymagania,
- szacowaną liczbę godzin,
- osoby potrzebne do realizacji,
- indywidualny koszt pracy specjalistów,
- wpływ na termin,
- status akceptacji,
- przychód dodatkowy lub informację o pracy wykonanej bezpłatnie.
Następnie godziny są przypisywane bezpośrednio do danej zmiany, a nie tylko do całego projektu.
W Administy łączymy:
- wartość kontraktu,
- podstawowy budżet godzinowy,
- rzeczywiste czas pracy,
- koszt każdego specjalisty,
- dodatkowe prace,
- koszty zewnętrzne,
- bieżąca marżę,
- prognozowaną marżę końcową.
Dzięki temu widzimy nie tylko, że projekt wykorzystał więcej godzin. Możemy również sprawdzić, dlaczego tak się stało.
Przykładowo projekt może wykazywać 120 godzin ponad plan, z czego:
- 25 godzin wynikało z błędnej estymacji,
- 15 godzin przeznaczono na usunięcie błędów,
- 80 godzin dotyczyło dodatkowych wymagań klienta.
Taka informacja zmienia sposób zarządzania.
W pierwszym przypadku trzeba poprawić proces wyceny. W drugim jakość realizacji. W trzecim procedurę zarządzania zmianą i rozliczania prac dodatkowych.
Systemowe rejestrowanie zmian pozwala też wcześniej zauważyć, że:
- liczba dodatkowych próśb rośnie,
- klient wykorzystał już cały bufor,
- dodatkowe godziny obniżają prognozowaną marżę,
- część prac nie została wyceniona,
- zespół wykonuje zadania przed uzyskaniem akceptacji,
- projekt wymaga renegocjacji zakresu lub terminu.
Najważniejsza zmiana polega na tym, że scope creep przestaje być niewidocznym kosztem.
Zamiast mówić klientowi:
„Mamy znacznie więcej pracy, niż zakładaliśmy"
możemy pokazać:
„Od początku projektu zaakceptowaliśmy 12 dodatkowych zmian, które zwiększyły zakres o 86 godzin i obniżyły prognozowaną marżę o określoną kwotę".
To daje podstawę do rzeczowej rozmowy o dodatkowej wycenie, przesunięciu terminu albo ograniczeniu dalszych zmian.
Elastyczność nie powinna oznaczać bezpłatnej pracy
Dobra współpraca wymaga elastyczności, ale każda zmiana ma swój koszt.
Scope creep w projekcie IT można ograniczyć, jeżeli firma jasno definiuje zakres, odróżnia błędy od nowych wymagań, rejestruje dodatkowe prace i pokazuje ich łączny wpływ na budżet.
Brak takiego procesu prowadzi do sytuacji, w której klient otrzymuje coraz szerszy zakres, a wykonawca stopniowo traci marżę.
Sprawdź, ile kosztują dodatkowe prośby klientów
Administy pomaga połączyć czas pracy, indywidualne koszty zespołu, dodatkowe pozycje i prognozowaną marżę projektu w jednym miejscu.
Umów prezentację Administy i zobacz, jak rejestrować dodatkowe prace oraz reagować, zanim drobne poprawki wykorzystają cały budżet projektu.
