TABLE OF CONTENTS:
Odpowiednio zarządzane projekty, z zastosowaniem właściwych metodyk zarządzania projektami IT mają większą szansę na ich skuteczną realizację. Z treści tego artykułu dowiesz się m.in., które metodyki zarządzania projektami są najbardziej popularne. Czy istnieje jedyny właściwy sposób prowadzenia projektu? Jak to się stało, że używając dowolnej metodyki, która ma swoje wady i zalety, doprowadzamy w Solwicie projekty do efektywnego końca i zamykamy kontrakty z pełną satysfakcją po stronie Klienta.
W związku ze zmianą rzeczywistości biznesowej, większość aktywności komercyjnych ubierana jest w ramy projektu. Takie podejście pozwala łatwiej zarządzać wielością zadań, a sam portfel projektów jest bardziej przejrzysty. Samo ubranie pakietu zadań w projekt pozwala łatwiej zdefiniować cel takiego przedsięwzięcia, a dzięki temu ocenić, czy nakłady jakie musimy ponieść, są współmierne do celu, jaki chcemy osiągnąć. Inna rzecz, że same „projekty” są dziś po prostu modne i łatwiej jest pozyskiwać z rynku pracy osoby, które zarządzają projektami, niż menadżerów, którzy „koordynują”. Za tą potrzebą uruchomił się także inny rynek. Rynek, który dostarcza zarówno produkt, jak i rozwiązanie wszystkich problemów: „metodyka zarządzania projektem”.
Od niespełna dziesięciu lat frazy jak: metodyki projektowe, metodyki zarządzania projektami IT, zwinne metodyki zarządzania projektami, PMI, Scrum, Kanban, Kaizen, Six Sigma, ITIL, SAFe i Prince2 odmieniane są przez wszystkie przypadki. Firmy prześcigają się we wdrażaniu kolejnych sposobów na efektywne prowadzenie projektu. Nie tak rzadkim zjawiskiem jest sytuacja, gdy duża firma lub korporacja nie wdrożyła jeszcze dobrze jednej metodyki, a już wdraża kolejną. Mimo różnych efektów takich wdrożeń, zainteresowanie jednak nie maleje, gdyż w wymaganiach, w ofertach pracy, jasno nawiązuje się do znajomości tej, czy innej metodyki zarządzania projektami. Wdrożenia metodyk, na ogół, są bardzo drogie i najprawdopodobniej unika się potem oceny opłacalności i efektywności takiego wdrożenia.
Nie mniej, jeżeli chcesz zaistnieć na rynku IT, albo na tym rynku rozwijać swoją karierę, to „musisz umieć w projekty”. Tylko, że certyfikaty i biegła znajomość pakietu metodyk może nie pomóc w skutecznym doprowadzeniu przedsięwzięcia do końca, z pełnym sukcesem.
W obecnym kształcie rozwijają się dwa kierunki zarządzania projektami. Waterfall, polska nazwa: model kaskadowy oraz Agile, polska nazwa: zwinne metodyki zarządzania projektami. Oba podejścia mają po równo swoich zwolenników, jak i przeciwników. Prawdą jest, że obie mają swoje wady i zalety. Nieprawdą jest, że któraś jest lepsza, a któraś gorsza. Każda metodyka jest lepsza niż żadna i każdy sposób powinien być dobierany z uwzględnieniem specyfiki zadania, które mamy przed sobą. Pokrótce przedstawię najbardziej popularne i najczęściej stosowane podejścia.
Głównym reprezentantem takiego podejścia jest PRINCE2. Błędnie określany jako przeładowany dokumentacją i ociężały. Obecnie na rynku dostępne są również jego zwinne odmiany. Skupię się jednak na tej wersji PRINCE2, który jest najczęściej wykorzystywany przez administrację publiczną, czyli wersji waterfallowej. Cały model kaskadowy oparty jest na tym, że już na początku wiemy, co chcemy wytworzyć i jesteśmy w stanie określić budżet takiego projektu. Nie ma tu ani limitów czasu na etapy, ani limitów (lub dobrych praktyk) na rozmiary zespołów. Metodyka jest złożona z tematów i procesów, a wszystko stoi na fundamentach pryncypiów, które są istotą metodyki.
Framework obejmuje określenie uzasadnienia biznesowego dla projektu, wspiera organizację projektu, proponując konkretne role i odpowiedzialności. Wskazuje, jak zarządzać ryzykiem, jakością, postępem i zmianą oraz wspiera planowanie. PRINCE2 świetnie nadaje się zarówno na grunt korporacyjny, gdzie wymagane jest duże zaplecze dokumentów, jak i do małych zespołów, gdzie nie potrzeba aż tyle dokumentacji a zespoły nie są tak rozbudowane.
Stosowanie tej metodyki się nie uda jeżeli ignoruje się pryncypia. I to jest najczęstszy powód stosowania tzw. PINO (ang.: PRINCE in Name Only, pl.:PRINCE tylko z nazwy). Kluczowym jest:
Jak można łatwo zauważyć, te pryncypia są praktycznie tożsame z ideami metodyk zwinnych, o czym później. PRINCE bardzo kompleksowo nadaje ramy praktycznie wszystkim aspektom projektu IT i stanowi kompletne know-how, jak projekty prowadzić i na co uważać. Nowe przewodniki i podręczniki wyposażone są także w prawdziwe case’y, co ułatwia zrozumienie poszczególnych elementów metodyki.
Oczywiście PRINCE2 dostarcza też program certyfikacji. Poziom pierwszy można uzyskać na czas nieokreślony. Dyplom na poziomie praktyka uzyskuje się raz na 5 lat. PRINCE stosuje się zarówno w projektach IT, jak i w projektach budowlanych, eventowych i innych. Stworzona na potrzeby rządu brytyjskiego, świetnie sprawdza się w administracji publicznej, ale też w szeroko rozumianym biznesie.
Samo PMI nie jest metodyką. Skrót należy rozwinąć następująco: Project Management Institute, co oznacza po prostu organizację / zrzeszenie. Owocem prac tej organizacji są kolejne wersje podręcznika PMBoK (Project Management Book of Knowledge). To bardzo rozbudowany i kompleksowy zbiór praktyk i narzędzi upchnięty w 5 grup procesów i 10 obszarów wiedzy. W książce tej znajdziesz wszystko co potrzebne do prowadzenia projektu.
W PMI szybko zorientowano się, że model kaskadowy ustępuje miejsca zwinnym metodykom (przynajmniej jeśli mówimy o modzie), w związku z czym co chwilę pojawiały się nowe wersje PMBoK, który starano się „uzwinnić” tak bardzo, że obecnie PMBoK traktowany jest jako reprezentant sztuki zwinnej.
IPMA, natomiast, to kolejna organizacja: International Project Management Association. Podejście IPMA jest mniej techniczne, a bardziej opiera się na kompetencjach miękkich i ludzkim aspekcie projektów. IPMA też nie jest metodyką, a wręcz korzysta ze wszystkich innych metodyk i na nich opiera swoje jestestwo.
Obie organizacje mają mniej lub bardziej, rozbudowany system certyfikacji, a im wyżej w certyfikacji jesteśmy, tym droższe są podejścia do kolejnych, coraz trudniejszych egzaminów.
Ciężko określić PMBoK jako konkretną metodykę. Łatwiej jest rozumieć ten podręcznik jako zbiór dobrych praktyk, sposobów, technik, które czasem są niezbędne, a czasem po prostu dobrze je znać i stosować.
Nazwa pochodzi od młynka stosowanego przez amerykańskie drużyny futbolowe. Cała metodyka, czysta zwinność, miała dać „kopa” projektom, ograniczyć dokumentację i wyrabiać się ze zmianami w biznesie tak, aby produkty już dostarczone były użyteczne w zastanej sytuacji biznesowej.
Zasady są proste:
To wszystko opatrzone retrospektywami, które mają udrażniać wąskie gardła i być swoistym lessons learned.
W teorii wygląda to dobrze i ma sens. Ze stosowaniem (podobnie jak w poprzednich metodykach) bywa różnie. Ciężko też SCRUM określić jako metodykę zarządzania projektem. To bardziej metodyka wytwórcza, która pomaga zapanować często nad pracownikami-artystami. Wprowadza sztywne reguły i wydarzenia, dzięki którym zespoły same się pilnują i są zdyscyplinowane. Na pewno w takich metodykach zwinnych nie jest łatwe panowanie nad budżetem, dlatego jeżeli obie strony nie godzą się na pewną zwinność i zaufanie, to często SCRUM staje się waterfallem, tylko pozostają sprinty i kilka innych elementów zwinnych.
Metodyki Agile, nawet jeżeli myślimy tylko o SCRUM, nadają się również nie tylko na rynek IT. Mogą być stosowane w innych projektach pod warunkiem, że projekty te są relatywnie małe. Jeżeli chcemy zarządzać dużymi projektami, albo jako o projekcie myślimy o usługach utrzymania (maintenence), to metodyki zwinne mogą okazać się zabójcze.
Rynek nie lubi próżni i na te niedociągnięcia agile również znaleziono rozwiązanie. To korporacyjne metodyki, jak choćby SAFe, które kumulują przeróżne procesy agile i w konsekwencji znów wracamy do dość ociężałych procesów spowalniających pracę.
Możliwość „zobaczenia” swojego projektu jest bezcenna. Metodyka Kanban, która opiera się na codziennych iteracjach i ciągłym dostarczaniu, „wprowadziła” narzędzie, które zostało zaadoptowane do wszystkich metodyk, nie tylko w SCRUM, ale również stosowana jest w PRINCE itd. Tablica kanban, bo o niej mowa, to zbiór kolumn, które odzwierciedlają etapy procesu wytwórczego, po których przesuwane są kolejne zadania. Dzięki temu łatwo można zobaczyć, co nie zostało jeszcze rozpoczęte, nad czym obecnie pracujemy, co jest w testach, a co jest gotowe (to przykładowy podział kolumn). Sam Kanban świetnie się może sprawdzić w projektach utrzymaniowych, gdzie nie wytwarzamy konkretnego produktu, a pracujemy na incydentach i zmianach i te zagadnienia musimy umieć sprawnie obsłużyć.
Codzienne spotkania, spoglądanie na tablice i systematyczna analiza tego, co na tablicy kanban się znajduje, pozwala uniknąć momentu zaskoczenia, gdy nie wiemy co się dzieje w projekcie i coś po prostu „wybucha”. Kanban, podobnie jak SCRUM, tę systematyczność w projektach zwinnych pomaga otrzymać. Tablica kanban – jednakże – pokaże obecny etap w projekcie. Jego obecną sytuację. Dlatego to nie jest narzędzie typu Gantt, gdzie możemy zobaczyć sobie cały projekt. Warto o tym pamiętać.
O ile dobór właściwej metodyki lub praktyk jest ważny, bo określa ramy całego projektu i wyznacza sposób postępowania, o tyle dobry plan projektu to najlepszy sposób na minimalizację ryzyka niepowodzenia lub przestoju. Zależnie od sposobu prowadzenia projektu, albo planujemy prace na najbliższe sprinty, albo planujemy cały projekt i tylko krok po kroku uszczegóławiamy kolejne etapy projektu. Choć efekt jest podobny, to w konsekwencji możemy mniej lub bardziej widzieć całość projektu. Samo planowanie projektu to moment, na którym czasu nie warto oszczędzać.
Podstawowa pułapka, w jaką wpadają kolejni project managerowie to planowanie zadań, których nie da się rozpocząć. Nazywam to fikcją planistyczną. Co to znaczy, że zadania nie da się rozpocząć? Na przykład: nie mamy właściwych kompetencji w zespole, może nie wiemy co jest do wykonania, może nie ma zebranych wymagań, może brakuje makiet, a może UXowiec jeszcze dogaduje szczegóły. To, o czym mowa, to tzw. definition of ready. Co to oznacza? Nic innego jak definicja tego, kiedy dane zadanie jest gotowe do startu. To znaczy, że mam wszystko co potrzebne do wystartowania zadania i do jego zakończenia.
Oczywiście, nigdy w projekcie nie jest tak, że sto procent zadań do zaplanowania ma status „ready”, ale najważniejsze jest nie planować takiego zadania w najbliższej iteracji lub etapie, jeżeli nie ma cienia szans, że status „ready” otrzyma nie później niż w pierwszej połowie czasu zarezerwowanego na etap lub sprint. Takie podejście do planowania, choć w jakimś procencie, uchronić nas może przed brakiem możliwości zrealizowania planu projektu z uwagi na blokadę zadania.
Nie jest tajemnicą, że systematyczność działa i się sprawdza. Jeżeli przyjrzysz się jakiemukolwiek procesowi wynikającemu z tej czy innej metodyki zarządzania projektami, łatwo rozpoznasz, że skonstruowane są one w ten sposób, abyś w projekcie i jego kontroli był po prostu systematyczny. Plan przeglądów jak w PRINCE, czy też codzienne daily w SCRUM, to nic innego jak systematyczna kontrola i ekspresowe identyfikowanie odstępstw od planu projektu.
Ignorowanie podstawowych elementów procesu tej czy innej metodyki zarządzania projektami jest bardzo prawdopodobną przyczyną niepowodzeń wdrożeń metodyk w organizacjach. Choć można spierać się o szczegóły propozycji podejścia projektowego: czy lepsze są metodyki zwinne czy klasyczne, to trzeba uznać, że oba podejścia się sprawdzają, jeżeli towarzyszy im systematyczność.
Wracając do pytania, które postawiłem na początku: jak to się stało, że używając dowolnej metodyki, która ma swoje wady i zalety, doprowadzamy projekty do efektywnego końca i zamykamy kontrakty z pełną satysfakcją po stronie Klienta? Odpowiedź jest prosta. Klient jest takim samym członkiem zespołu i systematycznie kontroluje wszystkie fazy projektu, bierze udział we wszystkich wydarzeniach, punktach kontrolnych i w tak zwanych spotkaniach „review”. Dzięki temu łatwo identyfikować wszystkie sygnały wczesnego ostrzegania i korygować wszelkiego rodzaju odchylenia od jakości, budżetu, ale także samego przedmiotu zamówienia, jakim jest na przykład oprogramowanie.
Jak wiemy, plan projektu przestaje być aktualny w chwili podpisania. Dlatego systematyczna kontrola i obserwacja wszystkich parametrów projektu oraz błyskawiczne reagowanie na odstępstwa poprzez sprawne podejmowanie decyzji, a także działanie w zgodzie z podstawowymi pryncypiami tej czy innej metodyki, zbliży Cię do sukcesu szybciej niż myślisz. Dlatego rozmowa o tym, która metodyka jest lepsza mija się z celem. Jako kierownik projektu sam musisz podjąć decyzję, która metodyka do danego projektu będzie lepsza, a projekt prowadzić systematycznie pamiętając o tym, że siłą każdego zespołu są ludzie, którymi zarządzasz oraz Klienci, dla których tworzysz innowacyjne produkty.
