Jedna z najbardziej istotnych zasad filozofii Kaizen głosi, że wielkie efekty są sumą wielu małych zmian nagromadzonych w czasie. Wprawdzie mam wielki szacunek i sentyment dla tej filozofii zarządzania, ale kiedy obserwuję, jak zarządza się zakresem w wielu projektach nie mogę powstrzymać się od twórczej, choć – przyznaję – nieco cynicznej trawestacji tej zasady: wielkie problemy w projektach są sumą wielu małych niekontrolowanych zmian nagromadzonych w czasie.
Nie mogę się przy tym nadziwić, dlaczego ludzie zaangażowani w tych projektach z wielkim zapałem opowiadają o niezliczonych kłopotach związanych z niedotrzymanymi terminami, niekompetentnymi członkami zespołu i przekroczonymi budżetami, ale zdają się zupełnie nie zauważać katastrofalnych skutków fatalnego podejścia do zarządzania zakresem, a w szczególności do zarządzania zmianami. Nie waham się stwierdzić, że jest to jeden z najbardziej zaniedbanych i nielubianych tematów dotyczących zarządzania projektami.
Zjawisko niekontrolowanego poszerzania się zakresu projektu doczekało się swojej nazwy – scope creep (czy jak wolą zwolennicy upowszechniania naszej rodzimej mowy, do których sam się również chciałbym zaliczać, rozrost bądź pełzanie zakresu). Najlepszym zaś potwierdzeniem doniosłości i wszechobecności tego problemu jest obserwacja jednego z najbardziej uznanych autorytetów w dziedzinie zarządzania projektami, Harolda Kerznera. W jednej ze swoich książek stwierdził on: „There are three things that most project managers know will happen with almost certainty; death, taxes, and scope creep”1. I można odnieść wrażenie, że w większości projektów nie poprzestaje się na stwierdzeniu tej nieuchronności, ale też traktuje się rozrost zakresu jak złego smoka, którego nie sposób ukatrupić, więc lepiej omijać go jak najszerszym łukiem i udawać, że nie istnieje. No i wtedy jakoś to będzie. A jeśli nawet zdarzają się projekty, w których podejmuje się próby zapanowania nad bestią, to najczęściej niestety sprowadzają się one do wyboru jednej z dwóch nieskutecznych metod.
Pierwsza polega na całkowitym zakazie nie tylko proponowania zmian, ale nawet wspominania o nich. Metodzie tej towarzyszy zwykle bardziej lub mniej nieudana próba „kompletnego” określenia zakresu, która – co należy stwierdzić z pewnym smutkiem – jest z góry skazana na niepowodzenie z powodu pewnej cechy zakodowanej w DNA każdego projektu. Mam oczywiście na myśli unikatowość powodującą, że projekty cechuje znacznie większy poziom niepewności niż w jakiejkolwiek innej formie działań prowadzonych przez organizacje. I choć wytrwałość stróży pilnujących przestrzegania wspomnianego zakazu jest godna największego podziwu, to i tak nie zapobiega ona rozrostowi zakresu. Przynajmniej w kilku projektach miałem okazję obserwować pełną paniki reakcję na moje stwierdzenie, że to, o czym właśnie mówimy na spotkaniu statusowym jest zwyczajnym wnioskiem o zmianę, czy jak wolą inni „CRem”. Bardzo szybko przestawało mnie to bawić, ponieważ okazywało się, że zakazane jest tylko nazywanie zmian po imieniu, a same zmiany i tak żyją własnym życiem.
Druga metoda sprowadza się do ekwilibrystycznego gaszenia pożarów wywoływanych zmianami wciskającymi się do projektu każdą możliwą dziurą. Niezależnie od kreatywności wykazywanej przez zwolenników tej metody, opanowany w jednym miejscu płomień pojawia się w chwilę potem ze zdwojoną intensywnością w innym obszarze projektu. Zupełnie jak krety niszczące mój ogród.
Czy rzeczywiście nie ma innego sposobu na skuteczne zarządzanie zmianami w projektach? Czy rozrost zakresu jest faktycznie równie nieuchronny i niezwyciężony jak śmierć? W moim przekonaniu skuteczna metoda nie tylko jest wyobrażalna, ale jest już od dawna rozpoznana i dobrze opisana. Wymaga ona jedynie nieco odmiennego wykorzystania umiejętności, które w nadmiarze eksploatowane są w ramach dwóch wspomnianych przeze mnie metod. Wytrwałości i kreatywności.
Jakie elementy powinno się uwzględnić projektując skuteczne podejście do zarządzania zmian w projektach?
Przede wszystkim trzeba sobie uświadomić, że podstawą skutecznego zarządzania zmianami w projekcie, a w gruncie rzeczy kluczem do skutecznego zarządzania projektami, jest skupienie się na należytej inżynierii wymagań w projekcie. W największym skrócie – sukces projektu zależy od tego, jak zaplanuje się, a następnie zrealizuje sposób podejścia do wydobywania, dokumentowania, analizowania, specyfikowania i zarządzania wymaganiami w kontekście konkretnej potrzeby biznesowej oraz konkretnego zbioru uwarunkowań definiującego środowisko danego projektu. Skuteczne procesy inżynierii wymagań na poziomie projektu powinny zapewniać między innymi:
- Aktywne zaangażowanie w wydobywanie wymagań różnych interesariuszy. W wielu projektach nie uwzględnia się na przykład w należytym stopniu wymagań użytkowników zapewniających wsparcie operacyjne lub odpowiedzialnych za utrzymanie produktu projektu w trakcie jego eksploatacji. W rezultacie nie tylko pomija się cechy i funkcje produktu istotne z perspektywy tych interesariuszy, ale również traci się możliwość zoptymalizowania kosztów utrzymania i eksploatacji produktu.
- Specyfikowanie wymagań w sposób pozwalający na ich priorytetyzację i mierzalność. Zdefiniowanie hierarchii istotności wymagań niezwykle ułatwia późniejsze zarządzanie zakresem w projekcie. Planowanie kolejnych iteracji działań wytwórczych, definiowanie zakresu kolejnych wersji czy wydań produktu, ocena i hierarchizacja zmian proponowanych w projekcie to tylko niektóre obszary, w których przypisanie priorytetów wymaganiom zawartym w specyfikacji okazuje się bezcenne. Równie ważne jest uzupełnienie wymagań o wymierne kryteria akceptacji, obejmujące metryki, jasno sprecyzowane warunki i metody przeprowadzania akceptacji oraz związane z akceptacją odpowiedzialności.
- Przejrzysty i jednoznaczny mechanizm zatwierdzania bazowej specyfikacji. Brak takiego mechanizmu w którymkolwiek z obszarów planowanych w projekcie praktycznie uniemożliwia skuteczną komunikację i kontrolę w tym obszarze. Z punktu widzenia zarządzania zmianami, wszelkie niejasności dotyczące bazowej specyfikacji wymagań bardzo ograniczają możliwość pełnego oszacowania skali i skutków zmiany oraz podjęcie świadomej decyzji dotyczącej jej akceptacji lub odrzucenia.
To jedynie wybrane elementy skutecznych procesów inżynierii wymagań. Trzeba zwrócić uwagę na wiele innych, ale gotowych źródeł inspiracji nie brakuje. Znakomita większość metodyk i standardów zarządzania projektami oraz analizy biznesowej dostarcza wystarczającej ilości narzędzi, dobrych praktyk i gotowych rozwiązań, które można wykorzystać w niemal każdym potencjalnym projekcie. Potrzeba jedynie wytrwałości w przekonywaniu interesariuszy projektu, że jest to krok, na który warto poświęcić odpowiednią ilość czasu i wysiłku oraz kreatywności w budowaniu podejścia odpowiedniego dla danego projektu.
Kolejnym elementem jest rozbudzenie w interesariuszach projektu świadomości znaczenia zarządzania zakresem dla sukcesu projektu. Otwarta, transparentna komunikacja i kultura zarządzania zachęcająca do kreatywności w proponowaniu zmian zwiększających wartość tworzonych w projektach rozwiązań połączona z wytrwałym i rygorystycznym przestrzeganiem ustalonych standardów i procesów mogą w istotnym stopniu przyczynić się do okiełznania rozrostu zakresu. Chcę tutaj podkreślić, że według mnie nie powinniśmy próbować uśmiercić tej bestii, ponieważ w rezultacie wywrócilibyśmy do góry nogami istotę projektów jako nośnika ważnych zmian w organizacjach. Można jednak – a nawet trzeba – tę bestię udomowić.
Wreszcie, potrzeba mechanizmów i narzędzi, które spowodują, że procesy inżynierii wymagań, stosowane przez świadome zespoły zarządzające projektami, będzie można z powodzeniem realizować w każdym projekcie w organizacji. Miarą skutecznego zarządzania projektami we współczesnym świecie nie jest już zdolność do „zaliczenia” spektakularnego sukcesu w jednym czy dwóch projektach. Skuteczne zarządzanie zakresem, a w szczególności skuteczne zarządzanie zmianami w projektach należy potraktować jako wyzwanie dla całej organizacji i jako element zarządzania portfelem, a nie tylko problem takiego czy innego projektu. Potrzeba zatem rozwiązań systemowych, które zapewnią należytą staranność oraz wsparcie dla stosowania procesów inżynierii wymagań w skali całego portfela. Nie sposób wyobrazić sobie takiego systemu bez jednoznacznego sprecyzowania zakresów odpowiedzialności, a jednocześnie zapewnienia odpowiednich uprawnień dla analityków biznesowych, kierowników projektu i organizacyjnego PMO wspierającego i nadzorującego skuteczne stosowanie procesów na poziomie portfela oraz zapewniającego skuteczny transfer wiedzy i doświadczeń między projektami. Każda z tych kluczowych dla projektu ról powinna się wykazać wytrwałością i kreatywnością w doskonaleniu podejścia do zarządzania zakresem w projekcie.
Kiedy wsłuchuję się w głos autorytetów i wizjonerów zauważam niezwykłą zmianę. Jeszcze kilka lat temu rozrost zakresu traktowany był jednoznacznie jako zjawisko negatywne, które trzeba w taki czy inny sposób pacyfikować i eliminować. Dziś otwarcie przyznaje się, że nie tylko nie da się tego zjawiska wyeliminować z projektów, ale że pod wieloma względami jest to zjawisko pozytywne, ponieważ jeśli tylko jesteśmy w stanie je zrozumieć i „oswoić” to może się ono stać źródłem dodatkowej wartości uzyskiwanej w projektach. W moim przekonaniu przedstawione powyżej rozważania stanowią dobry punkt wyjścia do zrozumienia kluczowego znaczenia procesów zarządzania zakresem dla sukcesu projektu i podjęcia działań zmierzających do ich optymalizacji.
- Harold Kerzner, Project Management Metrics, KPIs, and Dashboards, John Wiley & Sons, 2011.
Kierownik projektu, facylitator, trener, analityk i konsultant biznesowy z ponad 20-letnim doświadczeniem. Zaangażowany w projekty edukacyjne, projekty optymalizacji procesów biznesowych, wdrożenia standardów, metodyk zarządzania projektami. Autor polskiego wydania PMBOK® Guide. Jeden ze współzałożycieli polskiego oddziału stowarzyszenia IIBA®. Przez lata był związany z firmami MTDC i WHITECOM, prowadząc szkolenia oraz projekty doradcze i wdrożeniowe.