W maju miałem okazję prowadzić warsztaty podczas spotkania kierowników projektów dla jednej z instytucji. Jako główny temat spotkania został wybrany temat zarządzania zmianą w projektach. Temat bardzo mnie ucieszył, bo na co dzień jest on pomijany i nie do końca doprecyzowany na poziomie projektu, czy programu.
Spójrzmy na kluczowe aspekty zarządzania zmianą w projektach. Na co warto zwrócić uwagę? Kiedy podejść bardziej formalnie do zmian? I czy projekt Agile oznacza, że nie muszę się martwić o zmiany?
Co jest zmianą?
Pierwszym, nie do końca nawet oczywistym tematem jest – co jest zmianą i co powinno być obsługiwane poprzez wniosek o zmianę? Popatrzmy na przykład wdrożenia systemu informatycznego dla klienta przez jednego z integratorów oprogramowania. W połowie 18-miesięcznego projektu w firmie informatycznej został wdrożony system do zarządzania ryzykiem projektów. PMO postanowiło usprawnić i automatyzować ten obszar w całej organizacji i tym samym narzuciło na wszystkie toczące się i przyszłe projekty konieczność zastąpienia poprzedniego rejestru ryzyk w Excelu na dedykowany centralny system do zarządzania ryzykami w projektach. Czy taka sytuacja generuje nam zmianę do projektu? Czy naszą opinię zmienimy, jeżeli pracochłonność wdrożenia systemu do zarządzania ryzykiem do tego projektu oszacowano na 60 osobodni, wycenianych na tamten moment na 60 000 zł kosztów wewnętrznych? Jest to zmiana zakresu, budżetu czy terminu z punktu widzenia klienta? Nie, ale jest to zmiana sposobu organizacji projektu. To kto w takim razie powinien zapłacić te 60 000 zł? Niezależnie od tego, czy mamy tolerancję i bufory pozwalające nam sfinansować tę pracochłonność to powinniśmy potraktować taką sytuację jako zmianę do projektu.
I to właśnie tolerancja ma stanowić nasze zabezpieczenie, że nie każdą zmianę do projektu musimy akceptować ze sponsorem lub komitetem sterującym. Drobne, dodatkowe prace dla klienta często nie są nawet analizowane, drobne dniówki często akceptowane są zbiorowo postfactum, a kierownik, który na niektórych rzeczach oszczędził, w ogóle się nie martwi, bo pomimo dodatkowych kosztów, prognoza całości projektu jest dalej w ryzach.
Musimy też rozróżnić sytuację, kiedy projekt jest realizowany jako pojedyncze przedsięwzięcie, a co innego jako element większego programu. W takiej sytuacji nawet drobne opóźnienie w projekcie, ale wpływające poprzez zależności na inne projekty, musi być traktowane jako zmiana!
Czynniki wpływające na zmianę
Planując projekt i zasady zarządzania zmianą w nim musimy zastanowić się, skąd przyjdą zmiany, jakiego będą rodzaju, jak je będziemy obsługiwać i czy możemy się przed tym zabezpieczyć? Każda organizacja na inną częstotliwość występowania danych zjawisk, ale całościowo jesteśmy w stanie zweryfikować, które czynniki / kierunki i rodzaje zmian są dla nas najczęściej występujące, a które najbardziej wpływają na sukces naszego projektu. Przykład takiej analizy można zobaczyć na rys. nr 1.
Rys. 1 Czynniki i wpływ czynników zmian
Żródło: Opracowanie własne.
W badaniu jednej firmy jako najczęściej występujący czynnik pojawiania się konieczności zmian w projektach okazały się zmiany regulacyjne i prawne (nr 14). Miały one też największy wpływ na sukces projektu. Na drugim miejscu pod względem częstotliwości pojawiły się zmiany wymagań interesariuszy (nr 1), ale już ich wpływ na sukces projektu był stosunkowo nieduży. Kierownicy projektów w tej organizacji wiedzą jak radzić sobie z ciągłymi zmianami oczekiwań interesariuszy. No i wieczna bolączka wielu organizacji – zasoby ludzkie (nr 5) o drugim, największym wpływie na losy projektu. Nie tylko brak dostępności osób, ale również brak przydzielonych odpowiednich osób do potrzeb kompetencji oraz motywacja stanowią cały czas spore wyzwanie w wielu organizacjach.
Co z taką wiedzą możemy zrobić? Możemy wdrożyć rozwiązania na poziomie projektu lub na poziomie całej organizacji. Przykładem tego pierwszego jest zmiana sposobu kolejności wykonywania prac w projekcie, aby niestabilny zakres przenieść na dalsze etapy projektu. Oczywiście taka zmiana najczęściej wymaga od nas dodatkowej pracochłonności albo bardzo często jest ona mniejsza niż ryzyko ponownych prac w tym obszarze (po wejściu finalnych regulacji). Natomiast na poziomie organizacji jako menedżer portfela projektów lub PMO możemy wprowadzić jasne zasady reagowania i obsługi kluczowych typów zmian dla naszej organizacji. Czyli wprowadzić dedykowaną ścieżkę postępowania dla danego typu zgłoszenia. Firmy wprowadzają również zasady współpracy kierowników projektów przykładowo z działem prawnym, aby zapewnić bieżącą informację o planowanych zmianach regulacyjnych.
Zmiana w projektach Agile
Czy w takim razie powinniśmy martwić się i analizować zmiany w projektach zwinnych? Przecież to podejście zakłada po prostu wprowadzenie zmian do backlogu bez żadnej akceptacji i formalnej procedury (tylko priorytet będzie decydował czy i kiedy wejdzie do realizacji). Nic bardziej mylnego! Po pierwsze analiza wprowadzonych zmian do backlogu na podstawie analizy ich tempa przyrostu w wykresie burndown chart pozwala nam określić potencjalny termin realizacji wszystkich wymagań. Czyli ile więcej sprintów będziemy potrzebowali, jeżeli planowalibyśmy je ponownie na podstawie aktualnego rejestru, ale również prognozy pojawienia się nowych wymagań. Po drugie, większość projektów zwinnych w praktyce jest realizowanych w modelu hybrydowym, gdzie kierownik projektu, pomimo realizacji prac w sprintach czy iteracjach i tak musi odpowiadać za całościowo zaakceptowany budżet i czas realizacji projektu. Z punktu widzenia decydentów musi on pokazywać, a nawet akceptować zmiany do projektu.
Analiza zmiany
W ramach analizy zmiany warto rozważyć trzy elementy: moment analizy, analizowane obszary oraz szczegółowość jej wykonania.
Bardzo często spotykam się z sytuacją, kiedy ciągłe zmiany lub pomysły na zmiany rozbijają efektywność zespołu. Ciągłe zapytania o wyceny i wpływ takiego pomysłu powoduje, że zespół jest odrywany od zaplanowanej pracy. Warto określić w ramach projektu, na jakich zasadach i kiedy wnioski o zmianę będą analizowane oraz monitorować, jak bardzo jest to pracochłonny proces dla naszego projektu. Przykładem rozwiązań, które miałem okazję stosować nawet na poziomie umowy z klientem, było określenie momentów w harmonogramie, kiedy zmiany będę analizowane i obsługiwane przez zespół (oczywiście poza sytuacjami, że zmiany podważają nasz aktualny plan prac).
Standardowo wszyscy przy zmianie analizują jej wpływ na zakres, budżet i harmonogram. Cały czas spotykam się z sytuacjami, że nie jest analizowana pracochłonność wewnętrzna zmiany (bo i tak ludziom płaci się pensję). Również wpływ na jakość rozwiązania czy ryzykowność całego projektu może być kluczowa, nie mówiąc już o wpływie na korzyści i uzasadnienie biznesowe projektu. Warto dodać te elementy do analizy wpływu zmiany.
I ostatni element to szczegółowość przygotowanej analizy. Pamiętajmy, że czasami wstępny szacunek jest wystarczający dla decydentów, aby określić kierunek dla zmiany. Mamy też scenariusze, możliwe opcje wprowadzenia zmiany i zespół spędza dużo czasu na analizie każdej z opcji. W praktyce szybka weryfikacja wstępnych opcji z decydentami pozwala odrzucić jakiś scenariusz od początku nieakceptowalny i tym samym zmniejszyć pracochłonność zespołu obsługi zmian.
Decyzje i wdrażanie
Projektując proces dot. zmian, musimy uwzględnić dwa obszary: wytyczne firmy w tym zakresie narzucone przez PMO, dyrekcję czy zarząd oraz specyfikację i skalę projektu. Oba obszary musimy uwzględnić w planie zarządzania projektem. Oczywiście najbardziej wygodna sytuacja dla wszystkich jest taka, że zmiany są od razu integrowane we wszystkie obszary zarządzania projektem: aktualizujemy harmonogram projektu, budżet, zakres, wprowadzamy ryzyka do rejestru związane ze zmianą i zawsze mamy aktualną wersję, na której będziemy pracować.
Mistrzostwem w zarządzaniu zmianą wykazał się jeden z dostawców informatycznych, który już w pierwszych miesiącach projektu świadomie zebrał uwagi od wielu osób opiniujących rozwiązanie po stronie klienta i mając pełną listę uwag, błędów i zmian, sam ją przeanalizował i wykorzystał do rozszerzenia zakresu projektu. A mianowicie pogrupował wszystkie uwagi opiniujących i przyszedł na spotkanie z klientem, prezentując długą listę zmian. Lista to została podzielona na 3 sekcje: zmiany do rozwiązania, które akceptujemy (błędy, doprecyzowania, elementy zgodne z umową), elementy dyskusyjne (trzeba by powołać prawników, aby ustalić, czy było to w zakresie, czy nie), oraz elementy poza zakresem (nowe wymagania). „Przy okazji” na spotkanie przyniesiono już wycenę elementów poza zakresem oraz specjalną ofertę elementów dyskusyjnych. Klient nie chcąc walczyć z dostawcą, a przede wszystkim z szerokim zespołem oceniającym (i tracić czas w projekcie), zdecydował się rozszerzyć zakres i dopłacić dostawcy za nowe wymagania i częściowo za elementy dyskusyjne.
Co warto zastosować?
Podsumowując całość, oprócz oczywistych elementów zarządzania zmianą, warto zwrócić uwagę na wpływ zmiany na ryzyka i ryzykowność projektu, pracochłonności obsługi zmian w projekcie, termin ich analizy i wprowadzania (nie zawsze musimy od razu rzucać wszystko), delegować odpowiedzialność za monitorowanie zmian i jasno określić uprawnienia do decydowania o zmianach w projekcie (Kierownik projektu powinien mieć uprawnienia do decydowania o „małych” zmianach).
Rys. 2 Podsumowanie kluczowych rekomendacji zarządzania zmianą w projektach
Żródło: opracowanie własne
Na koniec warto uwzględnić procedurę zarządzania zmianą w planie komunikacji, aby wszyscy byli świadomi jak zgłaszać zmiany (forma, adresat, częstotliwość itp.).
Zachęcam do przeanalizowania swojego projektu pod kątem tego obszaru, bo zazwyczaj wprowadzenie kilku z ww. punktów pozwala na lepsze uporządkowanie całości projektu oraz dodatkowo pozwala na budowanie świadomości odnośnie do powodów, dlaczego ciągle zakres, harmonogram i budżet nie jest taki, jak planowaliśmy na początku.
Ekspert w zakresie zarządzania projektami, portfelem projektów i PMO. Specjalizuje się w obszarze usprawnień organizacji poprzez wdrożenie zarządzania portfelem projektów i PMO oraz w obszarze rozwoju kierowników projektów. Od 2003 roku związany z PMI®, gdzie pełnił m.in. funkcję Prezesa Oddziału Polskiego. Z centralą PMI® w USA związany od 2010 roku – obecnie pracuje w Komitecie do Spraw Certyfikacji (CIT). Od 2010 roku prezes firmy WHITECOM Project Experience specjalizującej się w szkoleniach, ustawianiu PMO oraz zarządzaniu projektami i portfelem projektów. Współautor książki PMO. Praktyka zarządzania projektami i portfelem projektów w organizacji.