Niekontrolowane wnioski o zmianę są częstą przyczyną problemów na projekcie. W miarę postępu prac klient wnosi coraz więcej zmian, PM się na nie zgadza i kończy w sytuacji przegranej.
O sekrety zarządzania zmianami zapytano Aleksandra Kriuczkowa, PMa z 17-letnim doświadczeniem w zarządzaniu projektami IT.
A Wioletta Saweczina, mentorka kursu zarządzania projektami IT, podzieliła się własnym doświadczeniem, w jaki sposób zarządzanie zmianą pomogło jej uniknąć dodatkowych wymagań klienta, które zagrażają harmonogramowi i kosztom projektu.
Skąd się biorą zmiany
W dzisiejszych „elastycznych” projektach zmiana jest znajomą częścią procesu, ale niektóre z nich mogą mieć duży wpływ na czas i koszty, więc ta część powinna być zawsze pod kontrolą.
Głównymi źródłami zmian w projekcie są korekty i doprecyzowanie wymagań, ograniczenia techniczne oraz zmiany interesariuszy klienta.
Korekta i doprecyzowanie wymagań
Na początku projektu klient nie zawsze ma pełne pojęcie o tym, co będzie wynikiem i jak gotowe rozwiązanie będzie wykorzystywane w biznesie. W fazie realizacji, kiedy klient widzi już pierwsze demo funkcjonalności, idea rozwiązania staje się jaśniejsza. Dlatego klient ma coraz więcej nowych życzeń i poprawek w systemie.
Korekty, niewielkie na pierwszy rzut oka, takie jak zmiana kolejności bloków informacji, kolorów, marginesów czy długości linii, mogą prowadzić do znacznych opóźnień czasowych ze względu na ilość edycji.
Tutaj projekt manager musi dokładnie przestrzegać wcześniej udokumentowanych umów, mieć na uwadze główny cel i wartość projektu, nie popadając w perfekcjonizm i wieczne poprawianie tego, co już zostało stworzone.
Ograniczenia techniczne
Czasami zmiany związane są z technicznymi ograniczeniami i możliwościami rozwiązania. Klienci posiadający wiedzę techniczną mogą przynieść wam zamiast wymagań biznesowych, już gotowe rozwiązanie.
Od pierwszego dnia project manager musi pracować nad tym, aby klient postrzegał zespół projektowy jako doświadczony i słuchał jego rad i sugestii.
Gdy klient proponuje rozwiązanie niekorzystne dla projektu, należy otwarcie wyjaśnić, na czym polega trudność lub specyfika realizacji. A następnie pracować z klientem nad znalezieniem rozwiązania, biorąc pod uwagę interesy wszystkich stron.
Zmiana zespołu po stronie klienta
W dużych projektach korporacyjnych interesariusze klienta mogą się zmieniać z czasem. Projekty w przedsiębiorstwie trwają dłużej niż rok i istnieje duże prawdopodobieństwo, że projekt będą sprzedawać dla jednych osób, a realizować go będą już z innymi.
Ostatnio spotkałem się z sytuacją, w której do grupy roboczej po stronie klienta przyszły nowe osoby. Każda z nich miała swój własny pogląd na rozwiązanie, więc dodawała własne wymagania, które nie zawsze były priorytetem dla projektu na obecnym etapie. Niektóre życzenia były nawet sprzeczne z pierwotnymi wymaganiami projektu, ale powodowały znaczne zwiększenie kosztów i czasu.
Wioletta Saweczina, mentorka kursu zarządzania projektami
Wraz ze zmianą interesariuszy, zmieniają się również wymagania. Dlatego w projekcie Fixed Price bardzo ważne jest udokumentowanie wszelkich uzgodnień i ustalanie scope przed podpisaniem kontraktu. Na początku projektu jednym z pierwszych zadań będzie opracowanie macierzy Interesariuszy ( macierz RACI) w celu określenia kto ma prawo na „ostateczną decyzję” w sprawie skopu i jego zmian.
Do czego prowadzi bezmyślne podążanie za życzeniami klienta
Jest mało prawdopodobne, że chcesz zrobić jak najwięcej funkcji i dostać się do Księgi Rekordów Guinnessa. Albo spełnić absolutnie wszystkie życzenia klienta. Jednak zdarzają się sytuacje, w których, aby zadowolić klienta, project manager bezwarunkowo akceptuje wszystkie życzenia i wymagania.
Jeśli nie będziesz zarządzał zmianami, to prędzej czy później przyjdzie do Ciebie klient i zapyta:
– Drogi PM, mamy releas za dwa tygodnie, prawda?
A PM odpowie:
– Jakie dwa tygodnie? Mamy jeszcze 3 miesiące pracy, bo zobacz, ile jest zmian! W każdym sprincie przychodzisz z jakąś prośbą: przesuwasz przyciski, zmieniasz system, prosisz o inny design itd.
Po takiej odpowiedzi klient będzie, delikatnie mówiąc, niezadowolony i dojdzie do konfliktu. A potem jest bardzo trudna sytuacja, kiedy project manager nie ma czym udowodnić całej tej ilości zmian od klienta. Albo nie ma czym tego szybko udowodnić.
Manager może oczywiście wyciągnąć jakieś maile, rejestry rozmów i poświęcić na to kilka dni. I może udowodnić niezadowolonemu klientowi i kierownictwu, że naprawdę było dużo zmian, a PM nie ponosi winy za niedotrzymanie terminu. A może nie.
Bezpośrednie rozwiązywanie zadań, bez analizowania życzeń, jest narażone na ciągłe zmiany. Zespół tworzy funkcję za funkcją, nie zastanawiając się nad zakładanymi konsekwencjami. Później potrzebna będzie niejednokrotna zmiana kodu, co będzie miało bezpośredni wpływ na czas i koszty.
Jak prawidłowo zarządzać zmianami
Przyjrzyjmy się przykładowi, jak wygląda cykl życia dowolnego życzenia od klienta. Załóżmy, że robisz projekt na 20 przewidywanych sprintów.
Na dziesiątym sprincie przychodzi klient i mówi:
– Słuchajcie, mamy formularz rejestracji użytkownika. Powinien on mieć taki układ i wygląd.
Co powinien zrobić PM, jeśli na początku ten design nie był zgłoszony w backlogu? Pierwszą rzeczą, którą należy zrobić, jest złożenie wniosku do rejestru zmian.
Wpisanie do rejestru
Rejestr zmian, jeśli istnieje i jest właściwie prowadzony, pozwala w minutę odpowiedzieć na wiele pytań, ponieważ raportuje stan skopa. W rejestrze można szybko zobaczyć i pokazać klientowi liczbę i status wniosków: ile ich wpłynęło, jakie wnioski są w fazie analizy, ile zostało zatwierdzonych lub odrzuconych. I co najważniejsze, jak zatwierdzone wnioski wpłynęły na datę wydania.
Wioletta Saweczina, mentorka kursu zarządzania projektami
Kiedyś trafiłam na projekt, który rozpoczął się bez szczegółowego scopu i bez ustalonego baseline. Klient po prostu sformułował ogólny cel produktu. Napisaliśmy koncepcję, a zespół zabrał się do pracy.
Na etapie pośrednim demo, zaczęły pojawiać się konflikty, ponieważ interesariusze po stronie klienta nie mogli uzgodnić między sobą wymagań. Zespół pokazywał pracę, a klienci sprzeczali się między sobą, czy to rzeczywiście jest to, czego chcieli.
Z każdym nowym krokiem i demonstracją gotowej funkcjonalności, klient generował dużą ilość poprawek i zmian, których nie można było odmówić, ponieważ linia bazowa projektu nie była ustalona.
Musieliśmy kilkakrotnie przerabiać tę samą funkcjonalność, ponieważ wymagania wciąż się zmieniały i nie było rejestru tego, co faktycznie byliśmy winni klientowi.
Na koniec spisaliśmy wszystkie wymagania, które znaliśmy lub zakładaliśmy w danym momencie, a następnie zatwierdziliśmy je z klientem. Wszystko, co nie znalazło się w tym dokumencie, nie było traktowane jako scope, a wszelkie dodatkowe prośby były zapisywane w rejestrze zmian.
Dopiero wtedy rozpoczął się jakiś proces zarządzania zmianą, bo było na czym bazować. Kiedy musieliśmy udowodnić klientowi, że jego życzenie jest zmianą, odwoływaliśmy się do dokumentu z jasną listą cech. Jeśli określonej cechy nie było na liście, to był to overscope.
Po wpisaniu do rejestru BA lub PM analizuje, czy prośba będzie zmianą czy nie. Analiza dokonywana jest pod kątem formalnym, np. czy prośbaw23e klienta koliduje z ustalonymi elementami backlogu lub założeniami. Następnie oceniany jest wpływ zmiany na projekt.
Ocena wniosku o zmianę
Każde doprecyzowanie lub zmiana scope w większości przypadków wpłynie na harmonogram i budżet projektu, dlatego zmianami należy zarządzać w każdym projekcie – bez względu na to, czy jest to kontrakt, Time and Materials czy Fixed-Price. Należy jednak pamiętać, że klient nie zawsze zdaje sobie sprawę z wpływu zmian na harmonogram i zakres projektu. Klient może przyjść z prośbą, która wydaje się dla niego całkowicie oczywista, a odkryje, że dodaje ona nieco dodatkowej pracy.
Klient może powiedzieć, że np. każdy system ma interfejs administratora. Więc nie ma znaczenia, czy uzgodniliśmy to, czy nie, tylko proszę o dodanie interfejsu za darmo.
W prawdziwej sytuacji, twój związek z klientem i jego skłonność do manipulacji ma duży wpływ. Ale formalne zastrzeżenie, że to, co jest w uzgodnionym dokumencie, jest w nim zawarte, a reszta to wnioski o zmianę, bardzo pomaga w negocjacjach.
Składasz wniosek do rejestru, a potem na spotkaniu z klientem PM lub BA może powiedzieć: – Drogi kliencie, twój wniosek jest zmianą, ponieważ w naszym backlogu i w opisie scope nie znaleźliśmy wzmianki o interfejsie administratora.
Następnie PM mówi ile będzie kosztowało stworzenie interfejsu. Klient przekazuje swoją opinię, o niektóre zmiany się kłócicie, o niektóre dostajecie decyzję – robić lub nie robić.
Zmiana może wpłynąć nie tylko na przyszły, ale i już zrealizowany scope. Być może będziesz musiał przerobić trzy gotowe User Story. A może wniosek wpływa na przyszły scope, więc trzeba ocenić nie tylko sam wniosek, ale także ponownie ocenić inne user story i zmienić połowę backlogu. To również należy wziąć pod uwagę.
Podczas omawiania każdej zmiany upewnij się, że jest ona zgodna z celami biznesowymi release’u/projektu i nadaj pracom odpowiednie priorytety.
Celem biznesowym może być np. pozyskanie finansowania dla jakiegoś projektu. W tym przypadku musimy spotkać się z inwestorami w określonym terminie, aby pokazać prototyp aplikacji. Albo klient podpisał umowę z nowym klientem i dostosowujemy produkt dla tego klienta, a on zdecydowanie potrzebuje tych funkcji. Zawsze jest jakiś kontekst biznesowy, który pozwala nam ustalić priorytety.
Jeśli ty i klient dobrze zarządzacie іscopem i macie dobrego biznes analityka, on może powiedzieć klientom
– Słuchajcie, to jest zmiana w scope. I oprócz tego, że zajmuje dodatkowy czas, nie spełnia waszych celów dla tego release’u. Skupiacie się teraz na automatyzacji sprzedaży, a tu chodzi o zakup. Odłóżmy to na później.
W tym przypadku klient nie pomyśli, że wypełniasz jego życie biurokracją, lecz będzie Ci wdzięczny. Bo podpowiedziałeś mu, na co nie warto tracić czasu.
Na przykład, na prośbę o nowy design dla formularza rejestracji użytkownika, po analizie mógłbyś powiedzieć klientowi co idzie dalej:
– Szanowny Kliencie, dziękujemy za przesłanie szablonu formularza rejestracji użytkownika. Wdrożyliśmy już tę stronę dwa miesiące temu i miała ona inny wygląd, więc – jest to wyraźne wniosek o zmianę.
Wdrożenie nowego designu zajmie 2 dni, więc trzeba będzie przesunąć datę realise’u o 2 dni. I będziesz musiał zapłacić dodatkowe 400 dolarów.
Jeśli nie masz nic przeciwko temu, weźmiemy tę zmianę do pracy. Jeśli nie, to zostawiamy datę release tak jak jest, bo terminy są dla Ciebie ważniejsze. I ta zmiana zostaje odłożona do następnego release’u, a może w ogóle wyrzucona.
Dogadać się z klientem
Wioletta Saweczina: Mieliśmy projekt Fixed Price, w którym na początku wymagania były takie same, a potem z różnych powodów większość wymagań się zmieniła. Kiedy klient wprowadzał zmiany, które były mniej więcej pasujące do zakresu, spełnialiśmy je. Ale były takie zmiany, które nigdzie wcześniej nie były zapowiadane i stanowiły spory blok prac, wpływając nie tylko na bieżącą funkcję, ale także na funkcjonalność, która została już zrealizowana.
Przez cały czas trwania procesu zbierania i formowania wymagań prowadziłam rejestr zmian, zapisując i analizując każde żądanie.
Kiedy stało się jasne, że finalizujemy wymagania, zwołaliśmy spotkanie z klientem, aby omówić sytuację ze zmianami w projekcie.
Rozmawialiśmy o rejestrze:
- jak brzmiało wymaganie na etapie sprzedaży;
- jak bardzo zmiana zwiększy nakład pracy;
- jak przesuwa się termin uruchomienia projektu.
Przejrzeliśmy listę kilka razy, trochę podyskutowaliśmy i poszliśmy na wzajemne ustępstwa. Globalne pytanie, które interesowało klienta, brzmiało: „Co trzeba zrobić, żeby się uruchomić?”.
Po analizie okazało się, że są dwie realne zmiany, ale bez nich nie uruchomimy nic. I są pewne zadania, od których klient się odmówił w ramach projektu.
Projekt był Fixed Price, więc zaproponowaliśmy to:
– Zróbmy te dwie duże zmiany, żeby rozliczyć zadania, z których zrezygnowaliście. A pozostałe niekrytyczne prośby przełóżmy na etap rozwoju.
Klient zgodził się.
Terminowe rejestrowanie zmian oraz udokumentowany stan wyjściowy projektu pozwoliły na uzasadnienie niepotrzebności dużej części zmian. Pomogło to nie wydłużać terminu i odłożyć niekrytyczne poprawki na przyszły rozwój projektu.
Kiedy zarządzanie zmianą nie jest potrzebne
Podejście „po prostu bierzemy i robimy to” sprawdza się tylko tam, gdzie pierwotnie uzgodniono, nie tylko w umowie, ale 20 razy ustnie i potwierdzono mailami, że ani sprzedawca, ani PM nie odpowiadają za zmiany w czasie i budżecie.
Jeśli masz projekt, w którym w ogóle nie dogadywaliście się o skope, to prawdopodobnie nie potrzebujesz zarządzania zmianą. Że tak powiem, sprzedałeś zespół agile i zacząłeś pracować również w Agile. Klient przysiągł, że nie będzie Ci robił wyrzutów, że nie dotrzymałeś terminu po tym jak ciągle zmieniał scope.
Manager w takim projekcie to faktycznie koordynator zespołu, scrum master, ale nie jest to PM w sensie odpowiedzialności za trójkąt projektowy (zakres-czas-pieniądze).
Z drugiej strony, dla każdego klienta ważne jest zrozumienie, kiedy dana funkcja lub release będzie gotowy i ile to zajmie. Klient nie chce znaleźć się w sytuacji, w której wszyscy mają nadzieję na release za dwa tygodnie, ale w rzeczywistości jest on oddalony o trzy miesiące i dopiero teraz o tym wiadomo.
Właściwe zarządzanie zmianą pomaga uniknąć takich sytuacji, okazuje się więc, że zarządzanie zmianą jest potrzebne w każdym projekcie, nawet jeśli nie jest to projekt typu Fixed Price.
Zarządzając scopem, PM ratuje projekt przed niedotrzymaniem terminów i przekroczeniem budżetu, chroni klienta przed marnowaniem pieniędzy, a siebie i swój zespół przed stresem i przepracowaniem.
Nauczyć się pracy ze zmianą poprzez przeczytanie jednego artykułu to chyba mało możliwe. Ale całkiem realne jest doskonalenie swoich umiejętności zarządzania na praktycznym kursie PM Hard Skills: Planning. Program kursu zawiera tematy, których każdy PM potrzebuje, aby naprawdę zarządzać projektem i procesem.