Podejście do zmiany to jeden z kluczowych czynników, który odróżnia podejście klasyczne, waterfallowe od podejścia zwinnego. W podejściu klasycznym zmiana jest – powiedzmy to wprost – niemile widziana. I nie ma się czemu dziwić, skoro im później zgłoszona, tym bardziej kosztowna. Jak wygląda zarządzanie zmianą w projekcie waterfallowym? Zapraszam do lektury.
Zwykle zaczyna się tak: przychodzi klient do PMa i mówi: „Chcę zmienić zakres i dodać taki mały drobiazg”. Co na to powinien odpowiedzieć PM?
To oczywiście nie jest jedyne źródło zmiany. Może nim być (przykłady z mojego doświadczenia):
- błąd, którego nie zdążymy naprawić przed zakończeniem projektu i chcemy wypuścić w świat produkt nieidealny,
- przesunięcie terminu realizacji jakiegoś kamienia milowego, etapu lub całego projektu w związku z jakąś sytuacją,
- pozyskanie dodatkowych funduszy, żeby dokończyć projekt (w terminie lub nie).
Zapewne jesteś w stanie dopisać tu swoje przykłady.
Jak powinno wyglądać zarządzanie zmianą w projekcie?
Na etapie zgłoszenia zmiany trudno jest wyrokować, czy jest ona dobra czy zła. Z jednej strony chęć modyfikacji zakresu może być wynikiem „widzimisię” klienta, bo przecież „przy okazji można to zrobić, skoro i tak tam coś robicie”. Z drugiej strony może być przemyślaną decyzją, popartą analizą oczekiwanych korzyści. Dlatego nie zaczynaj ani od stanowczego nie, ani od kiwania głową na tak.
Pierwszym krokiem jest weryfikacja, jak proponowana zmiana wpłynie na harmonogram, budżet, jakość, ryzyka, zasoby oraz korzyści biznesowe. Bez wątpienia ten wpływ będzie.
Kolejnym krokiem jest sprawdzenie wszystkich opcji – czy możemy daną zmianę wprowadzić bez konieczności zmiany terminu i budżetu? Z pomocą przyjdą Ci techniki, z których korzystałeś podczas tworzenia i kompresowania harmonogramu – crashing i fast tracking.
W trzecim kroku konieczne jest przygotowanie formalnego zgłoszenia zmiany (ang. change request).
Zgłoszenie to – w kolejnym kroku – podlega zatwierdzeniu/odrzuceniu (pamiętaj, że nie każda zmiana będzie zatwierdzona). W zależności od tego, jaki wpływ na projekt ma zmiana i jakie w tym zakresie uprawnienia ma menedżer projektu, potrzebne będzie uzyskanie zgody CCB (skrót od Change Control Board) lub też nie. Jeśli jest taka konieczność, menedżer projektu prezentuje zmianę na spotkaniu CCB. Tam też podejmowana jest decyzja o zatwierdzeniu lub odrzuceniu propozycji zmian w projekcie.
Zatwierdzona zmiana jest następnie wprowadzana do planów projektu. Od tego momentu kontynuujesz realizację projektu zgodnie z nowym, zaktualizowanym planem.
Nie zapomnij również poinformować wszystkich zainteresowanych stron, że taka zmiana została wprowadzona.
Podsumowując
Zarządzanie zmianą w projekcie jest wymagające. Stosunkowo łatwo jest dokonać zmian, jeśli jesteśmy na etapie planowania projektu. Jeśli produkt przechodzi fazę testów, decyzja o modyfikacji projektu będzie bardzo trudna.
Pamiętaj, zmiana w jednym obszarze pociąga za sobą zmiany w innych obszarach – najczęściej w terminach i kosztach projektu. Dlatego zawsze rozważ wszystkie dostępne opcje i wybierz te, które mają najmniejsze skutki przy jednocześnie największych korzyściach.
