Inicjowanie i prowadzenie projektów innowacyjnych w firmie cz II

Autor jest absolwentem Wydziału Elektroniki Telekomunikacji i Informatyki Politechniki Gdańskiej. Przez całe swoje zawodowe życie związany jest z realizacją projektów informatycznych. Od blisko 3 lat pracuje na stanowsku szefa zespołu i jest odpowiedzialny za realizacje projektów informatycznych w branży systemów zabezpieczeń. W 2008 roku ukończył podyplomowe studia Zarządzanie Projektem.

SCRUM

Nazwa metodyki (SCRUM - młyn) wywodzi się z terminu występującego w grze rugby. Pomysłodawcami jej są Hirotaka Takeuchi i Ikujiro Nonaka, którzy w artykule The New New Product Development Game, jaki ukazał się w Harvard Business Review (styczeń-luty 1986), przedstawili ogólne założenia metodyki. Ken Schwaber w roku 1995, sformalizował definicję i samą metodykę. Metodyka SCRUM powstała, aby móc sprawnie zarządzać projektami o nieznanych lub wysoce zmiennych wymaganiach. W tym celu zdecydowanie skrócono proces decyzyjny, powierzając podejmowanie wielu decyzji projektowych zespołowi oraz redukując ilość czasu poświęcaną na planowanie projektu.
W metodyce SCRUM produkty powstają w 30 dniowych cyklach, po których następują przeglądy oraz decyzje o formie kontynuacji projektu. W efekcie znacznie skracany jest proces komunikacji pomiędzy klientem i developmentem, a więc również pomiędzy inwestycją, a dostarczaną wartością biznesową.
W metodyce SCRUM wyróżniane są trzy role:

1. SCRUM master – jego rola jest nieco inna od roli project managera. Autorytet SCRUM mastera wynika głównie z wiadomości, jakie posiada on o metodyce SCRUM i z umiejętności ich zastosowania. Pełni on funkcję doradcy dla właściciela produktu podczas dobierania elementów zapisanych w tzw. product backlog, czyli elementach pozostałych do wykonania. Ponadto ma za zadanie dbać o dobre warunki dla realizacji projektu i usuwać ewentualne trudności poza projektowe. Rola SCRUM mastera jest więc bardziej rolą doradcy oraz autorytetu na temat metodyki niż typową rolą nadzorcy projektu.
2. Właściciel produktu – tę rolę sprawuje klient lub odbiorca produktu. Jest on źródłem wiedzy o wizji i kierunku rozwoju produktu. Właściciel produktu bezpośrednio kontaktuje się z zespołem projektowym. Nad przebiegiem komunikacji czuwa SCRUM master.
3. Zespół – na podstawie ustalonego zestawu funkcjonalności zapisanych w product backlog, zespół pracuje przez 30 dni, aby na koniec sprintu dostarczyć produkt realizujący opisane funkcjonalności. SCRUM master sprawuje opiekę nad zespołem, uczestnicząc w codziennych spotkaniach zespołu oraz świadcząc wsparcie w zakresie wiedzy o metodyce. Jednak decyzje, co do sposobu realizacji przedstawionych funkcjonalności, podejmują członkowie zespołu. Członkowie zespołu są również odpowiedzialni za przedstawienie efektów swojej pracy właścicielowi produktu.

Metodyka SCRUM stosowana jest w projektach innowacyjnych. Przyjmuje się, że jeśli w projekcie nie ma nic do odkrycia, prawdopodobnie nie potrzebujemy metodyki SCRUM.

Wizja

Projekt rozpoczyna się od wizji tego, co chcemy zrealizować. Początkowo wizja ta może być bardzo ogólna i wyrażona w języku marketingowym, ale wraz z realizacją kolejnych faz będzie się coraz bardziej krystalizować.

Na tym etapie powstaje tzw. product backlog. W dokumencie tym właściciel produktu umieszcza wszystkie funkcjonalne i niefunkcjonalne wymagania, których realizacja spowoduje realizacje wizji produktu.

Plan sprintu

Idea metodyki SCRUM zawarta jest w tak zwanych sprintach. Sprint jest pojedynczą 30-dniową iteracją. Rozpoczyna ją faza planowania sprintu. W tej fazie właściciel produktu oraz zespół projektowy ustalają, co powinno zostać wykonane w najbliższym sprincie.

Spotkanie dotyczące planowania sprintu jest ograniczone czasowo do 8 godzin. Chodzi o to, aby jak najszybciej rozpocząć pracę nad projektem, zamiast myśleć o pracy. Efektem spotkania jest zebranie wszystkich funkcjonalności przeznaczonych do realizacji w sprincie w formie tzw. sprint backlog. Natomiast zespół projektowy weryfikuje wykonalność tych zadań na koniec sprintu

Sprint

W tej fazie zespół projektowy realizuje funkcjonalności zebrane w sprint backlog. Faza sprintu trwa zawsze 30 dni. Każdego dnia organizuje się 15 minutowe spotkania, na których członkowie projektu wymieniają się informacjami o tym, co już zrobili i co planują zrobić w najbliższym czasie. Celem tego spotkania jest synchronizacja wiedzy o projekcie pomiędzy jego uczestnikami. W ramach tego spotkania każdy z członków zespołu odpowiada na trzy pytania:

1. Co zrobiłem w projekcie od ostatniego spotkania?
2. Co planuję zrobić do następnego spotkania?
3. Jakie przeszkody stoją na drodze realizacji zadań dla aktualnego sprintu

Przegląd sprintu

W tej fazie zespół projektowy przedstawia efekty swojej pracy podczas sprintu oraz podejmowane są decyzje, co do kierunku dalszego rozwoju projektu. Elementy tej fazy to:

• Spotkanie podsumowujące – na koniec sprintu organizowane jest spotkanie podsumowujące aktualny sprint. Na tym 4 godzinnym spotkaniu zespół prezentuje właścicielowi produktu oraz wszystkim zainteresowanym efekty swojej pracy podczas sprintu. Następnie podejmowane są decyzje co do dalszego rozwoju projektu,
• Retrospekcja – jest to 3 godzinne spotkanie z zespołem projektowym, organizowane przez SCRUM mastera. Jego celem jest zebranie wszystkich spostrzeżeń na temat procesu i metodyki oraz wprowadzenie modyfikacji, które uczynią proces bardziej efektywnym,
• Aktualizacja product backlog – w efekcie przeglądu sprintu aktualizowany jest zestaw funkcjonalności zapisany w tzw. product backlog, który stanowi wejście dla kolejnego sprintu.

Extreme Project Management (xPM)

APF i xPM narodziły się jako metodyki mniej więcej w tym samym czasie. Trudno więc powiedzieć, która wywodzi się z której. Tak czy owak xPM zajmuje się projektami, w których cel nie jest jasno określony i tym samym nie można zdefiniować rozwiązania. Wśród metodyk zarządzania projektami TPM zajmuje tę granicę, gdzie jest najwyraźniej określony zakres i cel projektu, natomiast xPM znajduje się na drugim biegunie. Po środku znajduje się APF, a nieco bliżej do xPM - SCRUM.

Metodyka xPM zajmuje się projektami ekstremalnymi, które charakteryzują się następującymi cechami:

• Duża szybkość – projekty realizowane z użyciem xPM to zazwyczaj projekty innowacyjne, krytyczne dla organizacji i bardzo ważne dla sponsorów. Oznacza to, że rezultaty oczekiwane są tak szybko, jak to możliwe. Szybkość, z jaką produkt ukazuje się na rynku jest często krytycznym czynnikiem sukcesu,
• Duża niepewność – projekty ekstremalne są projektami innowacyjnymi tak więc nikt nie wie, co czeka projekt w przyszłości. Kierunek wybrany przez klienta i project managera być może ulegnie zmianie o 180 stopni, ale tego nie wie nikt. Co więcej, czas, jaki jest potrzebny do zakończenia projektu również nie jest znany,
• Częste zmiany – Niepewność, co do celu lub rozwiązania oznacza, że w trakcie trwania projektu zespół będzie odkrywał i uczył się, podobnie jak w APF. Zmiany pojawiające się w xPM mogą kompletnie zmienić kierunek rozwoju projektu. Możemy odkryć sytuacje, które spowodują zatrzymanie bieżącego projektu i otworzenie kilku innych projektów bazujących na pomysłach z zamkniętego projektu.

Metodyki xPM i APF są wariacjami tego samego podejścia, w którym nauka i odkrycia pchają projekt naprzód. Obie metodyki są adaptacją Flexible Project Model, który został wprowadzony w 2000 roku przed Douga DeCarlo w „eXtreme project management workshop”.

XPM składa się z czterech faz: inicjacji, spekulacji, inkubacji i przeglądu. Od angielskich nazw tych faz (INitate, SPeculate, Incubate, REview) pochodzi określenie INSPIRE dla określenia metodyki xPM. Podobnie jak APF i SCRUM, xPM jest podejściem iteracyjnym. Projekt realizowany jest w nieokreślonej liczbie krótkich (1 – 4 tygodni) iteracji, w których poszukiwane jest rozwiązanie. Projekt może zakończyć się znalezieniem rozwiązania lub przerwaniem projektu w sytuacji, kiedy rozwiązanie nie zostanie odnalezione. xPM różni się od APF tym, że na początku projektu nie jest znany jego cel, lub co najwyżej znana jest niejasna wizja tego, co powinien zawierać produkt. Klient opisuje często spodziewany rezultat słowami, „będę wiedział, że to jest to, kiedy to zobaczę”. Ponadto w xPM angażuje się klienta nie tylko pomiędzy cyklami (jak to miało miejsce w APF), ale także w trakcie samych cykli.

W xPM nie obowiązuje trójkąt zakresu, jak to ma miejsce w TPM czy APF. W przypadku projektów realizowanych w tych metodykach, określone są fundusze oraz ramy czasowe dla projektu. W przypadku projektów xPM, są dwa możliwe warunki stopu projektu. Pierwsza możliwość, kiedy w ramach prac projektowych zostanie znalezione rozwiązanie. Wówczas projekt kończy się sukcesem. Druga możliwość to brak zgody sponsorów na kontynuowanie projektu ze względu na brak satysfakcjonujących rezultatów. W takim przypadku projekt kończy się klapą. Z tego powodu na koniec każdego cyklu zespół projektowy określa ścieżkę rozwoju dla dalszych cykli na podstawie tego, czego nauczył się w poprzednich i przedstawia dotychczasowe wyniki sponsorom, aby udowodnić sensowność kontynuacji projektu.

Inicjacja

W fazie inicjacji przede wszystkim należy „sprzedać” pomysł na projekt sponsorom. Jest to więc faza opisywania projektu wartościami biznesowymi. Następnie realizowane są burze mózgów dla wyłowienia różnych podejść do stawianego problemu.
Faza inicjacji jest również fazą budowania zespołu projektowego, a więc zbierania uczestników pod wspólny szyld oraz tchnięcia w uczestników entuzjazmu dla podejmowanego tematu.
Zanim projekt zostanie uruchomiony, szefowie muszą zostać przekonani, co do sensowności projektu, tak więc pomysłodawcy projektu muszą przedstawić wartość biznesową, jaką ze sobą niesie.

• Definiowanie celu projektu – cel w projekcie xPM jest bardziej wizją tego, co ma zostać osiągnięte. W tego typu projektach cel wyłania się w trakcie realizacji a znany jest dopiero na końcu projektu.
• Formułowanie dokumentu POS – podobnie jak w TPM i APF tak i tutaj należy sformułować dokument POS,
• Kryteria sukcesu projektu – gdy cel jest jedynie niejasną wizją, kryteria sukcesu są również niejasne. Ten element często pozostawia się niedookreślony,
• Ryzyka i przeszkody – identycznie jak we wszystkich innych metodykach, tak i tu staramy się opisać potencjalne ryzyka i przeszkody, na jakie może natrafić projekt,
• Określanie kosztu i ram czasowych – inaczej niż APF i TPM, xPM nie ma określonego kosztu i czasu. Tutaj określanie kosztu i czasu oznacza raczej, że klient spodziewa się osiągnięcia rezultatów w pewnym czasie i przy użyciu pewnych środków.
• Ilość i czas cykli – na początek zaleca się krótkie cykle, w których testowane będą nowe pomysły,
• Kompromisy w trójkącie zakresu – mimo że w xPM nie ma jako takiego trójkąta zakresu, należy jednak określić, w jaki sposób wypracowywany będzie kompromis pomiędzy kosztem, zakresem, jakością, czasem i zasobami dla projektu.

Spekulacje

W tej fazie rozpoczynany jest nowy cykl. Faza ta zawsze zaczyna się od burzy mózgów, w której dyskutowany jest wstępny opis celu projektu z fazy inicjacji (w przypadku pierwszego cyklu) lub wnioski i doświadczenia z poprzednich cykli. Celem tej burzy mózgów jest sformułowanie kierunku rozwoju oraz zdefiniowanie pomysłów, nad którymi należy pracować w kolejnej fazie inkubacji. Jako, że xPM rozwija projekty wysoce innowacyjne, żaden pomysł lub idea nie powinny zostać w tej fazie bez komentarza. Kolejne etapy to:

• Definiowanie jak projekt będzie kontynuowany – oznacza określenie kierunku rozwoju projektu,
• Warunki satysfakcji – w metodykach TPM i APF określenie warunków satysfakcji jest obowiązkowe jednak w xPM ten punkt jest opcjonalny. Jeśli oczekujemy w cyklu konkretnych efektów, możemy określić, co jest dla nas satysfakcjonujące na koniec tej fazy,
• Scenariusze i przypadki użycia – opisują generalnie jak odbiorca produktu końcowego chce korzystać z tego, co dostarczamy,
• Priorytety dla wymagań – zestaw scenariuszy i przypadków użycia dostarcza zestawu wymagań, jakie musi spełniać dostarczany produkt. Należy je teraz uporządkować pod względem priorytetów. Identyfikujemy więc wymagania, które koniecznie musi spełniać produkt, te które powinien spełniać oraz takie które są jedynie dodatkami,
• Identyfikacja produktów pierwszego cyklu – kiedy wymagania są już posortowane, należy zdefiniować, które z nich dostarczymy w pierwszym cyklu, pamiętając, że pierwsze cykle powinny być dość krótkie. Ograniczamy więc listę produktów pierwszego cyklu tak, aby móc je dostarczyć w ciągu tygodnia lub dwóch,
• Decyzja o kontynuacji – tu sponsor decyduje czy zdefiniowany plan rozwoju na sens i czy warto wg niego kontynuować projekt.

Inkubacja

Inkubacja jest fazą realizacji konkretnych zadań. Jednak, mimo że w fazę inkubacji projekt wchodzi w uporządkowaną listą produktów do dostarczenia, manager musi dbać o ducha eksploracji. Nie należy zapominać o tym, że nauka i odkrywanie nowych możliwości jest jednym z celów tej fazy.

• Przydzielanie zasobów – faza zaczyna się od przypisania członkom zespołu poszczególnych produktów, nad którymi będą pracować. Ważne jest zaangażowanie w ten proces członków zespołu, aby mogli uczestniczyć w realizacji produktów zgodnych z ich osobistymi preferencjami,
• Ustalanie planu cyklu – po ustaleniu zespołów realizujących poszczególne produkty, nadchodzi czas na sformułowanie, w jaki sposób będzie przebiegała praca nad poszczególnymi produktami. Nie zapominajmy jednak, że zespół w projekcie xPM musi być przygotowany na zmiany w każdym momencie. Więc ustalany plan nie może być traktowany jako nienaruszalna świętość,
• Wspólne tworzenie produktów – wspólne to słowo klucz w tym punkcie. Ze względu na eksploracyjny charakter projektu współpraca między członkami zespołu może zaowocować rozwiązaniami problemów.

Przegląd

Wejściem do tej fazy są wszystkie efekty (czyli produkty oraz wiedza i odkrycia) uzyskane w fazie inkubacji. Te elementy są wejściem do burzy mózgów, która ma odpowiedzieć na następujące pytania:

• Czego się nauczyliśmy?
• O co możemy rozszerzyć cel projektu?
• Jakie pojawiły się nowe pomysły, które należałoby zbadać?
• Czym powinniśmy się zając w następnym cyklu?
• Najważniejszą decyzją, zapadającą w tej fazie, jest decyzja o kontynuacji projektu, która jest podejmowana przez klienta. Kolejnymi działaniami w tej fazie są:
• Zastosowanie odkryć z ostatniego cyklu – czyli uporządkowanie tego, czego się dowiedzieliśmy lub odkryliśmy i określenie, jak tę naukę możemy wykorzystać w kolejnych cyklach,
• Rewizja celu projektu – tutaj zespół projektowy zastanawia się, czy biorąc pod uwagę aktualny stan wiedzy należałoby inaczej sformułować cel projektu,
• Ponowna priorytetyzacja wymagań – wraz ze zmienionym celem projektu mogą pojawić się nowe wymagania, zaś dotychczasowe mogą stracić swoje znaczenie dla końcowego produktu,
• Decyzja o kontynuacji – podejmowana przez klienta na podstawie aktualnych rezultatów.

Porównanie metodyk

Poniższa tabela przedstawia kilka cech omawianych projektów, które są istotne z punktu widzenia projektów innowacyjnych.



Z tego krótkiego zestawienia bardzo wyraźnie widać, że metodyka TPM jest zdecydowanie nieodpowiednia dla projektów innowacyjnych. Projekt innowacyjny charakteryzuje się dużą nieokreślonością celu projektu oraz zakresu. Nie sposób dla takiego projektu przedstawić konkretny plan, ani rozpisać szczegółową strukturę podziału prac. Stąd też dla projektów innowacyjnych odpowiednie są metodyki SCRUM i xPM. Ten fakt nie jest żadnym zaskoczeniem, jako że właśnie z myślą o takich projektach opracowano te metodyki.

W następnej części -  realizacja projektów innowacyjnych