Jak skutecznie zarządzać projektami - od planu aż po finał?

ZANIM ZABIERZESZ SIĘ ZA LEKTURĘ

Poniższy tekst dość wyczerpująco odpowiada na pytanie „jak skutecznie zarządzać projektem” (czyli de facto jak go dowieźć). Proszę pamiętaj jednak, że:

To nie storytellingowa opowieść, a gęsta procesowa lektura. Kawa wskazana. Najlepiej na potrójnym espresso.
Skupiamy się tu na „twardej”, procesowej stronie realizacji, praktycznie pomijając kwestie współpracy z zespołem i interesariuszami oraz szereg innych niuansów i „ale”. O nich usłyszysz podczas naszych szkoleń.
Proces ten jest przejrzysty i elastyczny. Jednak w przypadku większości firm warto go choć odrobinę dostosować oraz pomyśleć jak zarządzić priorytetami i zasobami pomiędzy całym portfelem projektów. W tym również chętnie pomożemy.

Dla fachowców i ciekawych: tak, to podejście zwinne, ale ujęte (zgodnie z naszą metodologią zarządzania projektami) w proste i pragmatyczne ramy.

Inspirującej lektury! Zapraszamy też do przejrzenia pozostałych materiałów w bibliotece dobrych praktyk.

SPIS TREŚCI

Rozpoczynanie (bądź nie) projektu.
Ułożenie przepływu komunikacji.
Planowanie:
Przygotowanie do rozruchu.
Realizacja – praca w cyklach i obsługa zmian.
Zmiany i ich obsługa.
Zakończenie i zamknięcie projektu.
Cały proces wizualnie i słowo na koniec.

PRIMO: PO CO, CZYLI BRIEF

Nim ruszymy z projektem na dobre i zaczniemy inwestować weń czas i pieniądze swój, zespołu oraz firmy, warto najpierw ustalić kilka kluczowych spraw.

W tym celu najpierw staramy się wypełnić kartę projektu (szablon). Nie chodzi o biurokrację, o wypełnienie papieru. Chodzi o to, by odpowiedzieć sobie na pytania, bez których rozpoczynanie projektu byłoby działaniem kamikaze.

Dobre przejście przez zagadnienia z briefu wymagać będzie z pewnością porozmawiania z kluczowymi dla projektu osobami. Często warto na etapie takich rozmów zapytać z kim według nich powinniśmy naradzić się jeszcze.

Czy wypełniony brief to sygnał do uruchomienia projektu? Nie! Konieczne będą jeszcze przynajmniej dwa kroki:

Spojrzenie wraz ze sponsorem na całość pod kątem sensu biznesowego. Jak przedstawiają się koszty w stosunku do planowanych zysków, czy to wszystko w ogóle się opłaca?
Weryfikacja dostępnych mocy przerobowych. Prezes, szef biura zarządzania projektami, dyrektor produkcji, czy menedżer portfela – ktoś w firmie powinien mieć pełen przegląd realizowanych projektów. I właśnie ta osoba powinna potwierdzić, że mamy wystarczająco ludzi i narzędzi, by projekt zrealizować oraz kiedy jest najlepszy moment, aby go zacząć.

To naprawdę ważne.

Często nawet jeśli ktoś wypełnia jakiś rodzaj briefu czy karty projektu, to zaniedbywane są owe dwa ostatnie kroki. W efekcie do realizacji przyjmuje się projekty mało opłacalne albo dławi ilością rozpoczętych na raz inicjatyw i w rezultacie nie jest się w stanie żadnej porządnie ukończyć.

Odpowiedzieliśmy sobie na kluczowe pytania? Całość wygląda opłacalnie i mamy siły, by się z nią zmierzyć? Przechodzimy dalej.

SECUNDO: ZESPÓŁ I KOMUNIKACJA

Nawet jeśli na tym etapie nie mamy i nie znamy całości zespołu projektowego, to z pewnością znamy już jego część. Chociaż kluczowe osoby. Nim przejdziemy do kolejnego kroku (planowanie – niżej), na pewno warto:

Pogadać z nimi, pokazać im brief i wyjaśnić o co chodzi w projekcie. Niech wiedzą, przy czym wkrótce będą pracować. Niech zastanawiają się, jak do tego podejść.
Ustalić wspólnie jakieś zasady komunikacji (choćby nowy kanał Slack), z których będzie można skorzystać już na etapie planowania.

Jedną osobą, z którą absolutnie musisz zakończyć ten etap będzie architekt, analityk biznesowy, product manager, czy product owner lub jakakolwiek rola ekspercka w zakresie rozumienia biznesowej i funkcjonalnej natury produktu końcowego (niżej będę używał określenia analityk).

Lider projektu nie jest w stanie i nie powinien odpowiadać jednocześnie za koordynację realizacji i doprecyzowywanie oraz decyzje w zakresie kształtu produktu końcowego, a także utrzymywanie związanej z tym dokumentacji!

Nawet jeśli mamy do czynienia z (wyjątkowym – taka sytuacja ma miejsce głównie w projektach realizowanych jako dodatek przez działy operacyjne) przypadkiem lidera eksperta dziedzinowego – mało prawdopodobne, że będzie on w stanie (bez strat dla działań koordynacyjnych) utrzymywać w porządku dokumentację wymagań (o wymaganiach niżej). W takim wypadku nieodzowna będzie prawa ręka w osobie dokumentalisty czy asystenta.

Działając inaczej ryzykujecie, że w połowie projektu nikt nie będzie już wiedział co, kto, kiedy, komu i w jakiej formie obiecał.

TERTIO: PLANOWANIE – ZAKRES, HARMONOGRAM, RYZYKO

Nie istnieje tajemny bożek zarządzania projektami, który porazi Cię piorunem jeśli nie zachowasz jakiejś tajemnej, świętej sekwencji działań. Wszystko, co dzieje się na tym etapie może być (i często jest) realizowane równocześnie, a efekty poszczególnych działań mogą stanowić dla siebie wzajemny wkład.

Na przykład po pierwszej próbie przełożenia wstępnie zebranych i spisanych wymagań na zadania do realizacji (czyli zakres), może ze strony członków zespołu pojawić się szereg pytań, z którymi trzeba wrócić do interesariuszy. Porządne zajęcie się ryzykiem zwykle powoduje konieczność przeplanowania kilku rzeczy w zakresie i harmonogramie. I tak dalej, i tak dalej…

Od czegoś jednak trzeba całe to planowanie zacząć oraz jakoś je tutaj opisać, dlatego przedstawię je w najbardziej intuicyjnym porządku.

UWAGA: poniższe kroki planistyczne nie zawsze mają sens. Powiem więcej – najczęściej ma sens zastosować je dość wybiórczo. Jeśli spytacie doświadczonych project managerów, czy za każdym razem radośnie przygotowują z pomocą żółtych karteczek plan projektu od zera, prawdopodobnie popukają się w głowę.

Jeśli macie do czynienia z projektem podobnym do jakiegoś, który już realizowaliście, to wasz proces planistyczny będzie dużo krótszy i polegał będzie na modyfikacji planu analogicznego projektu. Tak zazwyczaj jest dużo lepiej i szybciej, niż wymyślać koło od początku. Burza mózgów od zera przyda się jednak zdecydowanie w przypadku gdy:

Macie do czynienia z nowym, nietypowym projektem (tak, jak to było u nas na przykładzie, do którego odnośnik znajdziesz niżej).
Ten poprzedni projekt poszedł bardzo słabo. Warto wtedy zrobić planowanie od nowa.

Warto więc znać dobre, użyteczne metody na to, jak zaplanować projekt od zera. Gotowi? To lecimy!

WYMAGANIA

Zebranie i spisanie wymagań to zadanie dla analityka. Sposób w jaki to zrobić i jak rozmawiać z klientem, to cała osobna dziedzina wiedzy, którą tutaj przedstawiamy w bardzo, bardzo dużym uproszczeniu. Dlaczego? Ponieważ niestety bardzo często musi się też tym zajmować koordynator projektu, co – należy tutaj napisać to wprost – w przypadku projektów od średnich wzwyż (czyli więcej niż 3-4 osoby w zespole i dłużej niż 3 miesiące) – jest wbrew wszelkim dobrym praktykom. Już w średniej wielkości projekcie lider ma na głowie zbyt wiele by mieć czas na porządne zajmowanie się dokumentacją (zbieranie, ale przede wszytskim – aktualizacja) wymagań i w rezultacie albo tego nie robi, albo robi to po łebkach. A to kończy się chaosem, bo nikt nie wie co właściwie ustalono, część jest w jakimś dokumencie, część w mailach a część w głowie prowadzącego ostatnnie spotkanie. Dlatego właśnie w podejściu SCRUM jest osobna rola Product Ownera. Osoby, która jest “managerem do spraw wymagań”. Kompletnie nie zajmuje się koordynacją codziennych prac zespołu, za to dba by w dziedzinie wymagań, ich doprecyzowania czy priorytetów wszytsko było jasne i klarowne.

Wracając do podstawowych dobrych praktyk.

Zaczynamy od zastanowienia się i konsultacji na temat tego kim są osoby, z którymi powinniśmy rozmawiać. Kto może mieć coś do powiedzenia w sprawie tego co i w jaki sposób ma dostarczyć nasz projekt. Sporo problemów w obszarze wymagań nie bierze z nieporozumień, czy braku spójnej dokumentacji (choć i tych jest całe mnóstwo), a z tego że zespół nie skonsultował się (lub zrobił to za późno) z kimś kluczowym. Na przykład działem prawnym albo dyrektorem jednego z departamentów.

Reszta to rozmowy i ich dokumentacja. Forma tej ostatniej zależy od natury projektu, ale zawsze musi być ona pisemna i umożliwiająca wygodne potwierdzenie (koniecznie!!!) z osobami, które zgłosiły dane wymagania, że wszystko się zgadza.

Kilka typowych pułapek na tym etapie (szczególnie w dużej organizacji):

Brak podkreślania (do znudzenia) z waszej strony faktu, że to, że coś zostało przez was zanotowane, nie oznacza, że obiecaliście to dostarczyć (potwierdźcie to potem, po weryfikacji ze sponsorem – patrz niżej).
Brak wzajemnej weryfikacji wymagań pod kątem ewentualnych sprzeczności.
Brak weryfikacji wymagań ze Sponsorem pod kątem budżetu i terminów. Ludzie często zgłaszają wiele świetnych pomysłów, ale realizacja każdego kosztuje czas i pieniądze.
Przyjęcie do realizacji wymagań, które nie mają nic wspólnego z osiągnięciem celu projektu. Pojawia się projekt i wszyscy chcą „podłączać” pod niego swoje marzenia i tajemnice. Naprawdę wspaniale, że chcecie mieć raport środków trwałych, ale co to ma wspólnego z obniżeniem rotacji pracowników….

Wreszcie – bardzo często projekt będzie realizowany w sytuacji, gdzie nie można wszystkiego przewidzieć, a wiele wyjdzie „w praniu”, w trakcie jego trwania. W takim wypadku zbieranie wymagań będzie procesem ciągłym w całym okresie trwania prac projektowych. Jak ugryźć to w takim wypadku, przecież trzeba od czegoś zacząć? Na początku ustalmy to, co wiemy NA PEWNO oraz zidentyfikujmy te obszary zarządzania projektem, które prawdopodobnie będzie trzeba uszczegółowić w trakcie. Następnie zaplanujmy harmonogram tak, by prace zacząć od tych pierwszych, a dzięki uzyskanym w czasie ich realizacji informacjom, móc sukcesywnie uzupełniać i doprecyzowywać plany i koncepcje na realizacje tych drugich.

Tu dodatkowo znajdziesz przykładowy prosty rejestr wymagań (szablon)

ZAKRES

Zakres, czyli lista prac do wykonania na projekcie. Wymagania to lista życzeń interesariuszy , czyli „co mamy dostarczyć”. Zakres to sposób w jaki to wykonamy, czyli „jak to zrobimy”.

Co jest naszym celem podczas wspólnych prac nad określaniem i doprecyzowywaniem zakresu? Minimalizacja przeoczeń – zadań, o których zapomnimy. Chodzi o to, by jak najrzadziej w trakcie realizacji zdarzał się wam okrzyk:

Kurcze-pióro, zapomnieliśmy o …!

Jak najrzadziej, bo (Zero Bullshit!) praktycznie nierealne jest aby pomyśleć i zaplanować o wszystkim. Niektórzy próbują, co często kończy się utknięciem w niekończących się spotkaniach, dokumentach i konferencjach. Ma to nawet swoją ładną nazwę – paralysis by analysis. Paraliż przez (niekończącą się) analizę.

Jak z głową zabrać się za określanie zakresu?

Potrzebna będzie lista wymagań zebranych na poprzednim etapie oraz (jako pomoc i inspiracja) zakres z innych, w miarę podobnych projektów. Wraz z zespołem przeglądacie te materiały, a następnie bierzecie bloczek samoprzylepnych kartek i organizujecie burzę mózgów. W jej trakcie celem jest aby wygenerować jak najwięcej kartek z czynnościami (zadaniami), które trzeba będzie zrealizować w trakcie trwania projektu. Kilka rad:

Najlepiej sprawdzają się niewielkie zespoły (3-6 osób). Zwiększa się zaangażowanie, ciężej się ukryć i obijać.
Czasem warto zaprosić kogoś, kto niekoniecznie będzie pracował na projekcie, ale dobrze zna konkretne obszary zarządzania projektami. Czytaj: eksperta.
Dobrze, gdy dzieje się to na stojąco – jest więcej energii.
Upewniajcie się, że to, co ląduje na kartkach jest notatką dobrej jakości. Jedna kartka – jedna czynność zapisana jasno i jednoznacznie. Nie: „szkolenia”. Tak: „organizacja szkoleń wewnętrznych dla sprzedawców”.
Na oko powinny być to rzeczy do zrobienia w kilka dni. Po prostu nie za wielkie (za wiele umyka) oraz nie za małe (strata czasu i energii).
Broń Boże nie wciągajcie się na tym etapie w dyskusje ile coś potrwa, ani jaka dokładnie będzie kolejność zadań. To paraliżuje waszą kreatywność i odciąga od głównego zadania, którym jest wygenerowanie jak największej ilości zadań, aby o niczym nie zapomnieć. Na układanie przyjdzie czas za chwilę.
Z tego samego powodu dobrze, jeśli pisanie odbywa się równocześnie. Unikaj typowego syndromu „grupa wymyśla, a pan/pani lider ocenia i zapisuje”.
Dobrym znakiem, że wynik będzie dobrej jakości i że grupa angażuje się w realizację są… dyskusje i spory. Przecież to niemożliwe, żeby kilkoro fachowców zgadzało się co do joty odnośnie sposobu, w jaki macie realizować całe przedsięwzięcie!

Całość warto zrobić na dwa-trzy podejścia. Półgodzinna sesja, dzień przerwy, kolejna, dzień przerwy i kolejna. W ten sposób nie znudzicie się pracą (30 min. z kartkami jest fajną zabawą, dwie godziny już średnio) oraz dacie sobie możliwość przemyślenia pewnych rzeczy w międzyczasie.

Tekst ten ma być możliwie krótki i nie wspominamy tutaj o wszystkich możliwych niuansach, czujemy się jednak w obowiązku zaznaczyć: tak, oczywiście że jeśli projekt jest spory, to całość procedury będzie trzeba dostosować do jego skali. Na przykład skupić się na raz tylko na jednej fazie albo rozbić prace nad zakresem na kilka zespołów (np. pod kątem obszaru merytorycznego – backend, marketing, rollout w Niemczech) i w każdym z nich przeprowadzić ww. działania, a potem zebrać wyniki prac wszystkich zespołów w spójną całość.

Ach, oczywiście – praca zdalna. Taką burzę mózgów dobrze jest robić na żywo, ale jeśli nie macie takiej możliwości dobrze sprawdzą się narzędzia takie, jak Mural, czy Miro.

Weź udział w szkoleniu z zarządzania projektami

Nabędziesz z nami umiejętność zwinnego i skutecznego zarządzania projektami, bez bullshitu.

Dowiedz się więcej

HARMONOGRAM I WYCENY CZASOWE

Wiele osób czeka tutaj niespodzianka – nasza metodologia zarządzania projektami zakłada całkowite odejście od wycen czasowych w tradycyjnym tego słowa znaczeniu.

Nie zastanawiamy się czy dane zadanie potrwa 8 czy 12 dni i nie stosujemy rozmaitych formuł na obliczanie wydajności zespołu. To nie znaczy, że uważamy to za coś całkowicie bez sensu. Nie. Są zespoły i projekty, gdzie takie działanie może się sprawdzić, jednak znakomitej większości przypadków, z którymi się zetknęliśmy nie miało to większego sensu.

Co w zamian? Bardzo prosty system – nim przejdziecie do umieszczania zadań na harmonogramie spójrzcie z zespołem na każde z nich i przydzielcie mu „rozmiar” spośród trzech dostępnych: S, M lub L.

Proponujemy tylko te trzy kategorie, ponieważ zmusza to do faktycznego przemyślenia i przedyskutowania tematu w razie wątpliwości. Ludzie mają tendencję, by mając do dyspozycji szeroką skalę 1-20, ocenić coś na 17,5. Zduś ją.
Oczywiście jeśli coś jest ewidentnie za duże (XL!) to po prostu rozbijcie to na mniejsze zadania.
Zobaczysz jakie ta wycena wywoła dyskusje. Często jedni będą mówić „S”, a inni „L”. Czyli znów wyjdzie, że jednak nie to samo mieli na myśli w ramach tego zadania. Takie dyskusje to dobry znak. To właśnie o nie chodzi. O identyfikacje niedomówień i nieporozumień na etapie markera i kartki, a nie rozgrzebanego projektu.

Gdy skończyliście jesteście gotowi do stworzenia harmonogramu pracy w cyklach produkcyjnych (iteracjach, krótkich fazach – możecie nazwać to dowolnie, my będziemy używać tu określenia ‚cykle’). Tworzenie będzie polegało po prostu na narysowaniu a potem rozklejeniu kartek z zadaniami na takiej siatce:

To rodzaj tablicy kanbanowej, gdzie w kolumnach mamy zakresy dat (kolejne cykle), natomiast poziomo, w wierszach wprowadzamy podział na „obszary”. Mogą to być na przykład zakresy kompetencyjne – frontend, backend, testy albo zespołowe (tak, jak na widocznym wyżej przykładzie). Mogą też dowolne inne – chodzi o wprowadzenie dodatkowego podziału, który ułatwi odnalezienie się w gąszczu zadań.

Jak stworzyć harmonogram w taki sposób? Proponujemy kontynuować planowanie z pomocą samoprzylepnych kartek.

Zacznij więc od ustalenia długości standardowego cyklu. Sugerujemy aby była to wartość stała i wynosiła między 2 a 4 tygodnie. Im więcej macie mocy przerobowych (jesteście w stanie ukończyć więcej zadań), tym krótszy cykl.
Sprawdź kalendarz i święta oraz wypisz na osobnych kartkach konkretne ramy dat dla kilku pierwszych cykli. Jeśli coś specjalnego dzieje się w danym przedziale daty (np. święta, urlopy, konferencja branżowa) – zaznacz to, abyście wzięli to pod uwagę pod kątem dostępnych wtedy mocy przerobowych.
Przylep kartki z oznaczeniami kolejnych cykli na ścianę jako oznaczenia kolumn. Następnie zastanów się na jakie obszary podzielicie całość poziomo (wiersze) i też przyklej stosownie opisane kartki. Na tak przygotowaną „siatkę” wraz z zespołem zacznijcie rozklejać zadania.

Pomaga wtedy wcześniejsze oznaczenie zadań jako „L”, „M” lub „S”. Intuicyjnie drga nam potem ręka (czujemy, że to przesada), kiedy w dany cykl ładujemy siódmą z rzędu „L-kę”. Kolejna sugestia to (pozdrowienia dla teamu Red Bull) w przypadku, gdy macie nienaruszalny deadline – rozpoczęcie układania od końca.

Na zakończenie spójrzcie raz jeszcze na całość. Poszukajcie błędów, niespójności oraz miejsc gdzie można coś zoptymalizować lub ścieśnić. Możecie także rozważyć zaznaczenie (np. czerwoną kropą) zadań krytycznych. Takich, których będzie trzeba pilnować szczególnie. Wreszcie warto spojrzeć na zadania, jakie znalazły się w poszczególnych cyklach i na tej podstawie nadać im nazwy. Tak, jak widać to zrzucie ekranu wyżej („przygotowania”, „dopięcie miejsca”, etc.) w ten sposób uzyskujemy ułatwiające komunikację nazwy kamieni milowych.

I tyle. Macie gotowy wygodny, elastyczny i przejrzysty harmonogram! Typowe pytania:

Jak poznamy datę zakończenia całości? Proste – data zakończenia ostatniego cyklu produkcyjnego, w którym są do realizacji jakieś zadania.

Czyli to tę datę mamy ogłosić wszem i wobec? To zależy. Jeśli macie rozsądnego klienta / sponsora, z którym macie dobrą relację i który zrozumie, że w trakcie mogą wystąpić jakieś problemy i opóźnienia – jak najbardziej. Jeśli nie – sugeruję celować wewnętrznie z zespołem w datę, która wynika z porozlepianych kartek, natomiast na zewnątrz ogłosić coś ze stosownym (przeciętnie 10-20%) buforem.

Czy cykle muszę być równej długości? Nie, ale byłoby bardzo dobrze, gdyby były. Taka spójność bardzo ułatwia pracę i planowanie.

Czy zadania „zarządcze” też wrzucać na harmonogram? Zwykłych spotkań raczej nie ma sensu, ale trzydniowy zespołowy warsztat z klientem – zdecydowanie tak.

Co zrobić z zadaniami realizowanymi przez dostawców zewnętrznych? Rozbijcie ją na mniejsze etapy (punkty kontrolne!)” i również umieśćcie na siatce harmonogramu np. w osobnym wierszu.

Co zrobić z zadaniami, które mają stricte określoną datę realizacji albo inną cechę, która sprawia, że nie bardzo pasują do tego systemu? Wychodzimy z założenia, że takie przypadki są zazwyczaj jednostkowe i radzimy załatwiać je „ręcznie”, na przykład zapisując przypomnienie w kalendarzu. Lubimy proste systemy i uważamy, że nie warto komplikować czegoś przejrzystego aby koniecznie obsłużyć jednostkowe, nietypowe przypadki. Skutek zwykle jest taki, że system traci swoją lekkość, a i tak pojawi się coś, czego obsłużyć on nie potrafi.

Czy ja dobrze widzę – ten system nie wspiera zależności zadaniami!?! Zgadza się – nie wspiera ich jawnie. Natomiast realizuje się je układając zadania na siatce kalendarza tak, aby najpierw wypadały te, które są wymagane przez inne. Wychodzimy też z założenia, że zespół cechuje zdrowy rozsądek i nawet jeśli dwa zależne od siebie zadania wylądują w jednym cyklu – najpierw zostanie zrealizowane to właściwe. W szczególnych przypadkach (patrz punkt wyżej) można taką zależność zanotować ręcznie.

Ach tak – znów uproszczenie i zdanie się na rozsądek ludzi, wszystko włącznie z wycenami czasowymi jest u was „na oko”! Cóż – cały nasz system opiera się na wierze, że ludzie to jednak dość rozsądne humanoidy i nie należy owego rozsądku zbytnio krępować.

Odnośnie zaś precyzji – z naszego doświadczenia wynika, że mało kto w realnym życiu pieczołowicie identyfikuje i nanosi na harmonogram wszystkie zależności oraz wycenia szczegółowo każde zadanie. To ogrom pracy, na którą zwyczajnie nie ma czasu. Sądzimy, że paradoksalnie to właśnie nasz sposób jest precyzyjniejszy. Dlaczego?

Dlatego, że dzięki swojej prostocie pozostawia więcej czasu na dokładniejsze przyjrzenie się zadaniom i lepsze ich rozbicie. W skomplikowanych diagramach gro czasu idzie na układanie tego wszystkiego, u nas większość można poświęcić na dyskusję na temat istoty zadań. Jest też bardziej elastyczny. Chorobowe trójki ludzi z zespołu, niewielkie rozszerzenie zakresu czy zwykłe (niestety) opóźnienie może oznaczać w przypadku precyzyjnych harmonogramów iście benedyktyńską robotę przy ich aktualizacji. U nas po prostu przekleja się dwie żółte kartki.

Jakie oprogramowanie wspiera podział na poziome wiersze? Funkcja ta nazywa się swimlanes (ang.: tory pływackie) i niestety nie jest aż tak popularna. Widoczny na zrzucie ekranu program to Kanban Flow (swimlanes dostępne są w wersji premium za 5 USD za miesiąc), funkcję tę wspiera też popularna Jira. Co sugerujemy? Odżałować 60 dolarów rocznie albo pozostać przy planie na ścianie (naprawdę bardzo dobra opcja).

RYZYKO

Krok pierwszy: zdecyduj, czy naprawdę macie czas i energię, aby poświęcić na ten obszar choć dwie-trzy godziny. Jeśli odpowiedź brzmi „spojrzymy na to na chwilę i może coś się urodzi” – odpuść. Większość – nie: niektóre, nie: wiele. Większość planów ryzyka to bezsensowna biurokracja, która nie wnosi do projektu absolutnie niczego poza stratą czasu. Składa się z wydumanych ryzyk i jeszcze bardziej wydumanych strategii radzenia sobie z nimi, do których nikt potem nie zagląda i których nikt nigdy nie wdraża.

Chcesz spróbować? A więc…

Krok drugi: Zbierz zespół i przeglądając sukcesywnie zadania na waszym ściennym harmonogramie, zadawajcie sobie na pytania:

Co tam może pójść źle (zagrożenia)?
Czy może się tam nam w czym poszczęścić (szanse)?

Patrzenie na konkretne zadania sprawi, że wyniki waszych przemyśleń będą o wiele bardziej związane z realną codziennością i przydatniejsze niż dumania na poziomie „co generalnie mogłoby się podziać”. Druga rzecz, która poprawi jakość całość, to dbanie o to, aby wszystko formułować w postaci: przyczyna + skutek. Wpisywanie:

Opóźnienia w harmonogramie.
Oszczędzenie 10% budżetu.

Nie ma absolutnie żadnego sensu. Dlaczego? Ponieważ nic nie można z tym zrobić! Ryzyka identyfikujemy, aby wymyślić dla nich jakieś strategie. Coś, co sprawi że np. zmieni się prawdopodobieństwo ich wystąpienia. Ale żeby coś takiego wymyślić, musimy znać ich przyczyny i to na nich działać. Same skutki nic nam nie dadzą. Sensowne ryzyka to na przykład:

Ludzie zaangażowani w prace operacyjne – niska motywacja do pracy w projekcie i możliwe znaczne opóźnienia.
Ranni na skutek pęknięcia barier na trasie.

Z nimi możemy już coś zrobić. Możemy pogadać z szefami ludzi zaangażowanych w prace operacyjne, możemy wzmocnić bariery albo wpuścić na teren mniej ludzi.

Wyniki waszych przemyśleń, czyli ryzyka notujcie… oczywiście, że na żółtych, samoprzylepnych kartkach.

Krok trzeci: narysujcie na tablicy albo flipcharcie prostą macierz wpływu (niski / średni wysoki) i prawdopodobieństwa (niskie / średnie / wysokie).

Następnie z zespołem oceńcie każde ze zidentyfikowanych ryzyk według tych dwóch kryteriów i przyklejcie w stosownym miejscu na tablicy. Tak, to ocena „na oko”, ale w zupełności wystarczająca. Nie, nie można przyklejać na granicy pól. Albo jedno albo drugie.

Krok czwarty: spójrzcie na rozkład ryzyk i zdecydujcie, którymi się zajmiecie. Lepiej zająć się naprawdę porządnie kilkoma kluczowymi, niż każdym po łebkach.

Sugerowałbym zaczynać od tych o wysokim wpływie i prawdopodobieństwie oraz tworzących pary wysoki / średni, a po resztę wrócić jeśli starczy wam czasu i energii.

Krok piąty: strategia.

Mamy wybrane najważniejsze ryzyka. Czas zastanowić się co z nimi zrobimy. Są dosłownie milijony rozmaitych modeli. My oczywiście zaproponujemy najprostszy – bazujący na pożyczonym z frameworku SAFe modelu ROAM.

Zwołujemy z zespołem spotkanie, na którym omawiamy wybrane ryzyka. Po jego zakończeniu każde z nich musi mieć przydzieloną jedną z kategorii:

Resolved – rozwiązane: kiedy zmieniacie plan / podejście tak, że ono znika (np. zmiana miejsca zawodów, dostawcy sprzętu, technologii etc.).
Accepted – zaakceptowane: kiedy dochodzicie do wniosku, że nie macie możliwości albo nie ma sensu nic z nim robić.
Mitigated – zmitygowane: – wymyślacie coś, co pozwoli zmniejszyć szanse jego wystąpienia lub plan awaryjny na wypadek gdy się zdarzy.
Owned – przypisane – gdy w danym momencie nie bardzo możecie wymyślić sensowną strategię – ktoś z zespołu ma wrócić z propozycją

Zaletą tego modelu jest prostota i brak zbędnych dywagacji. Grunt, że robimy z ryzykiem coś konstruktywnego, a nie że spędziliśmy dodatkowe 20 minut zastanawiając się do jakiej kategorii je przypisać.

Drugą mocną stroną jest kategoria „owned”, ryzyk przypisanych. Prawda jest bowiem taka, że na jednym spotkaniu najczęściej trudno wymyślić coś sensownego dla każdego rozpatrywanego tematu. W takim wypadku podejmujemy decyzję nt. tego, kto zrobi w danym obszarze dokładniejszy research i wróci z propozycją. Przypisane oznacza więc „właściciela” w kontekście wymyślania strategii na dane ryzyko, a nie (jak myśli wiele osób) w kwestii jej późniejszej realizacji.

Dlaczego nie? Ponieważ (znów z doświadczenia) cała ta zabawa w opisywanie w jakimś dokumencie właścicieli i sposobów monitorowania ryzyk zwyczajnie nie działa. Nikt tam nie zagląda, nikt niczego nie monitoruje. Jasne lider projektu powinien niby o tym pamiętać i przypominać, ale kiedy ma dylemat „pilny mail od zarządu albo monitorowanie ryzyka”, zgadnijcie co wybiera?

Dlatego tak kluczowy jest krok szósty, ostatni. Bez niego wszystko powyżej nie ma sensu.

Krok szósty: zmiany w planach.

Zasada jest bardzo prosta:

Cały proces identyfikacji i planowania odpowiedzi na ryzyka ma sens jedynie wtedy, kiedy jako jego konsekwencja znikną, zmienią się albo pojawią nowe zadania na waszym harmonogramie.

Wymyśliliście sposób uniknięcia ryzyka (strategia resolved)? Wróćcie do harmonogramu i usuńcie ryzykowne zadanie, dodając ew. w zamian coś innego. Macie jakieś działanie, które trzeba wykonać, by zwiększyć prawdopodobieństwo ziszczenia się szansy (strategia mitigate)? To jest dodatkowe zadanie, które powinno znaleźć się na harmonogramie! To samo opracowaniem z planu awaryjnego na wypadek wystąpienia danego wydarzenia (znów mitigate).

Wszystko to są działania, który oznacza dodatkową pracę dla członków zespołu i jako takie powinny znaleźć się w harmonogramie. W ten sposób znajdą się ich właściciele, w ten sposób zapewnicie, że coś faktycznie wydarzy się w tym obszarze zarządzania projektem.

Bonus dla ułatwienia: ściągnij listę kontrolną najważniejszych kroków planowania projektu

QUATRO: PRZYGOTOWANIE DO ROZRUCHU

Aż chciałoby się zacząć tę sekcję od słów „zanim ruszycie z pracami…”. Ale nazwa Zero Bullshit Management zobowiązuje. A więc:

Oczywiście, że jakieś prace dawno już mogą być wykonywane! Nie istnieje odgórny zakaz robienia czegokolwiek, nim dotrzecie do tego momentu w procesie przygotowania projektu! Często równolegle do planowania realizuje się np. zadania wymagające relatywnie niskiego nakładu naszych sił, ale długotrwałe. Na przykład:

Wszelkiego rodzaju research technologii, jakie planujemy wykorzystać.
Badania rynku dostawców i partnerów oraz zapytania ofertowe.
Procesowanie umów i inne sprawy formalne.

Niemniej, nim na dobre ruszycie z pracami warto jeszcze przynajmniej:

Spojrzeć gospodarskim okiem na całość planu oraz brief i odpowiedzieć sobie na pytanie „czy to nadal trzyma się kupy”. Często w trakcie planowania odkrywamy i dowiadujemy się nowych rzeczy, które mogą mieć spory wpływ na naszą odpowiedź.
Przygotować tablicę zadań na pierwszy cykl produkcyjny.

Jesteśmy fanami tablic kanbanowych pod każdą postacią. W naszym podejściu do zarządzania projektem sugerujemy użycie przynajmniej dwóch.

Pierwsza – opisana i widoczna na zrzucie ekranu wyżej, w sekcji harmonogram projektu – służy nam do zarządzania zakresem w skali całego projektu oraz widoku z lotu ptaka na całość. Na co dzień będzie jednak potrzebna druga tablica, służąca do codziennego, operacyjnego zarządzania zadaniami.

Dla przejrzystości sugerujemy jedną na każdy zespół / obszar.

Jeśli swój harmonogram podzieliliście poziomo na trzy sekcje, dobrym punktem wyjścia będzie po jednej tablicy dla każdego z tych obszarów. Oczywiście to tylko sugestia. Może okazać się, że dla wygodnego koordynowania prac dwóch zespołów zadaniowych, lepiej zrobić im wspólną tablicę. Może się też okazać, że w danym obszarze jest w danym cyklu produkcyjnym tak mało zadań, że nie ma sensu bawić się w osobne tablice. Najważniejszą zasadą przyświecającą Wam podczas tworzenia swojej konfiguracji powinna być wygoda użycia tego narzędzia w codziennym przydzielaniu i monitorowaniu zadań.

Po dokonaniu wyboru pozostaje więc tylko przygotować tablice operacyjne do pierwszego cyklu produkcyjnego. Wyglądać to może mniej więcej tak:

Typowe pytania:

Czy zadania z harmonogramu przepisujemy do kolumny „do zrobienia” jeden do jeden? Najczęściej nie. Zwykle na harmonogramie znajdą się zadania na nieco wyższym stopniu ogólności i pracochłonności (kilka dni, a czasem więcej). Doświadczenie pokazuje jednak, że na co dzień o wiele lepiej zarządzać czymś do zrobienia za jednym – dwoma posiedzeniami i o pracochłonności nie przekraczającej 8-12 godzin. Do tego właśnie potrzebujemy osobnej tablicy, gdzie rozbijecie, zdekomponujecie i uszczegółowicie dla potrzeb codziennej pracy „grube” zadania z harmonogramu.

Czy stosować tu jakąś wycenę czasową? To zależy. Przede wszystkim od ilości zadań, jakie lądują w „do zrobienia”. Przy małym zespole i małej ilości tematów dosłownie „na oko” widać czy to, co planujecie jest realistyczne, czy można coś dołożyć albo że nie ma szans i koniecznie trzeba coś przesunąć na później (nie radzimy przyjmować do realizacji planów z gruntu nierealistycznych – to demotywuje). Przy większym zespole wprowadzilibyśmy jakieś podstawowe wyceny, znów na poziomie oceny skomplikowania zadania: S, M, L.

Swoją drogą – co to znaczy „większy zespół”? Ten tekst dotyczy procesu, ale nie możemy się ustrzec od kilku uwag z obszarów miękkich, jedna z nich to:

Bardzo trudno blisko zarządzać i koordynować prace więcej niż 8-9 osób na raz. Jeśli projekt jest trudny, dynamiczny, a zespół mniej doświadczony, to granica może przesunąć się nawet sporo niżej. W wypadku, kiedy jesteście ponad nią – trzeba podzielić ludzi na mniejsze zespoły, z których każdy będzie miał swojego lidera i swoją tablicę operacyjną.

Wracając do wycen. Pojawia się jeszcze pytanie – skąd wiedzieć ile S-ek, M-ek i L-ek zmieści się w jednym cyklu produkcyjnym? W pierwszym cyklu przyjmijcie jakąś orientacyjną wartość – np. każdy zrobi jedną L, trzy M i jedną S (S-ek zwykle jest dość mało), a w kolejnych skorygujecie ją na podstawie lekcji wyciągniętych z przebiegu dotychczasowej pracy.

To właśnie jest zwinność – zamiast prób wyliczenia tego z jakichś skomplikowanych współczynników robimy eksperyment, wyciągamy wnioski i dostosowujemy się do realiów. To jedyna droga.

Jakiego narzędzia użyć? Jeśli się tylko da to tablicy fizycznej wiszącej na oczach na ścianie nieopodal. Ale jeśli to niemożliwe – wybór macie szeroki. Jako, że tu nie sugerujemy już podziału na poziome swimlanes (choć oczywiście nie mówimy, że czasem nie może mieć on sensu), możecie swoją tablice stworzyć we wspomnianych JIRa lub Kanban Flow, ale też w Trello lub Asanie.

Czy koniecznie potrzebuję tablic operacyjnych? Jeśli masz naprawdę niewielki projekt z mikro-zespołem, w którym prace dzieją się powoli – na przykład jakąś niewielką inicjatywę realizowaną przez dział zajmujący się głównie pracą operacyjną, prawdopodobnie możesz sobie odpuścić. Jednak w większości przypadków bardzo mocno sugerujemy ten podział. Próba zarządzania zadaniami z pomocą harmonogramu najczęściej kończy się wynalazkami w rodzaju wklejania go do maila i przydzielania tak zadań oraz zbierania statusu, a w konsekwencji chaosem, stratą czasu, paraliżem informacyjnym i frustracją. Harmonogram to nie tablica codziennych zadań.

Zasięgnij porady doświadczonego Project Managera!

Chcesz rozwiązać problem w projekcie lub w relacji z zespołem, klientem, czy też przełożonym? Skorzystaj z konsultacji 1:1.

Dowiedz się więcej

QUINTO: REALIZACJA – PRACA W CYKLACH I OBSŁUGA ZMIAN

Plany planami, ale od ich ilości, objętości i estetyki (te kartki na ścianie…) o wiele ważniejsze jest to, na ile uda się wdrożyć wam je wszystko w życie.

To podczas realizacji jest miejsce na wszystkie umiejętności liderskie – komunikację, motywację, rozwiązywanie problemów i inne. Czyli wszystko, o czym tutaj nie piszemy, ponieważ to materiał skupiony na procesie. Mimo to, chcemy jeszcze raz podkreślić – nawet najlepszy proces niewiele Wam da, jeśli zabraknie ogarniętego lidera, miejsca na dobrą komunikację, odpowiedzialność, zaufanie i wszystko to, co sprawia, że praca faktycznie idzie do przodu.

opóźnienia w projekcie infografika

A jakie twarde i procesowe rzeczy powinny dziać się w tej fazie? Przede wszystkim:

Monitorowanie postępów prac: polecanym przez nas sposobem jest regularne (codziennie lub co kilka dni – w zależności od tempa projektu, ale raczej częściej niż rzadziej) szybkie (max kwadrans) spotkanie robocze, gdzie zaktualizujecie waszą tablicę operacyjną (świetnie robi się to przy fizycznej tablicy) i zidentyfikujecie ew. problemy do rozwiązania.

Ważne, aby było to realizowane sprawnie i nastawione na identyfikację i zapobieganie problemom. Codzienne godzinne spotkania albo odpytywanie ludzi 4 razy dziennie „jaki jest status” to paraliżująca prace i demotywująca zespół patologia.

Doprecyzowywanie wymagań: proces ciągły, o którym wspominaliśmy już wyżej. Projekt trwa i cały czas warto myśleć o tym, co będzie działo się w kolejnych cyklach produkcyjnych. Analityk powinien więc przez cały czas trwania prac w spokoju (a nie w ostatniej chwili, bo zaraz trzeba planować kolejną fazę) konsultować tę przyszłość z interesariuszami.

zarządzanie projektem w trakcie cyklu, fazy infografika

No i przede wszystkim w fazie wykonania czekają was:

ZMIANY, ZMIANY, ZMIANY (I ICH OBSŁUGA)

Co do zasady będą ich trzy rodzaje:

Dodatkowe zadania, które pojawiają się jako konsekwencja realizacji zakresu danego cyklu produkcyjnego. Robimy coś, a w trakcie okazuje się, że przydałoby się jednak zrobić jeszcze coś innego. Na przykład w trakcie konsultacji z jakimś działem, dowiadujemy się wielu ważnych rzeczy oraz tego, że powinniśmy spędzić jeszcze dwa dni nad rozmowami z działem, którego wcześniej nie braliśmy pod uwagę.
Błędy i pilne rzeczy do naprawienia. Kiedy z naszego produktu już korzystają użytkownicy i coś się psuje. Wtedy trzeba rzucać wszystko i naprawiać.
Nowe pomysły do zbadania, zmiana zdania u interesariuszy. Kiedy klient albo inne ważne osoby zmieniają zdanie, chcą coś dołożyć, chcą abyśmy coś zbadali.

Każda z tych sytuacji wymaga nieco innej reakcji, jednak w każdym przypadku zawsze powinniśmy w pierwszej kolejności patrzeć na to, jak nasza zmiana ma się do celu projektu. Czy się w niego wpisuje? Podobnie jak na początku (wspominaliśmy pisząc o wymaganiach), tak też i w trakcie realizacji zwykle pojawia się w stosunku do projektu wiele życzeń i próśb, które nie mają nic wspólnego z jego celem. Jeśli będziemy próbowali realizować je wszystkie, to nie będzie to projekt – wszystko rozejdzie się w waszych rękach, mutując w jakąś kuriozalną akcję spełniania życzeń. Oczywiście potem większości nie spełnicie, a wszyscy będą mieć do was pretensje.

Co więc dokładnie robić z poszczególnymi kategoriami zmian?

Dodatkowe zadania – to zupełnie normalne, że w trakcie realizacji pojawią się takie niespodzianki. Nie da się zawsze pomyśleć o wszystkich niuansach. W takim wypadku odpowiadamy sobie na kilka pytań:

Czy to może poczekać? Jeśli tak – zrobimy w kolejnym cyklu. Jeśli nie:
Czy to się zmieści w tym cyklu? Zawsze mamy jakiś zapas, margines błędu, a nuż wyrobimy się i z dodatkowym zadaniem. Jeśli nie:
Co proponujemy usunąć z zakresu na ten cykl albo zrobić inaczej (np. w mniejszej skali), żebyśmy się wyrobili?

Jeśli ma to znaczący wpływ na końcowy rezultat cyklu, to taką propozycję bezwzględnie konsultujemy i potwierdzamy z kluczową osobą, której obiecaliśmy wcześniej nieco inny zakres. W zależności od tego, jak wygląda Wasza firma może to być klient, sponsor, product manager czy product owner.

Błędy i pilne rzeczy do naprawienia. To niestety też standard. I tutaj także jest kilka możliwości:

Nie dotyczy to produktu, który rozwijacie. Po prostu ludzie z zespołu są „pożyczani” do gaszenia rozmaitych pożarów. To de facto nie jest zmiana w waszym projekcie, ale skutki ma podobne – mniej czasu na pracę. W takim wypadku robisz dwie rzeczy – zastanawiasz się (podobnie jak piszemy oczko wyżej) co proponujesz zrobić (np. usunąć coś z zakresu), aby się jednak wyrobić. Przede wszystkim zaś działasz aby minimalizować takie sytuacje – czy to musi być ktoś od was z zespołu? Czy na pewno, czy sponsor rozumie wpływ jaki to ma na zakładany deadline? A jeśli musi, to czy nie można tego zrobić w sposób w miarę cywilizowany – np. rezerwując jeden dzień w tygodniu na takie atrakcje? I tak dalej.
Dotyczy go i ilość takich problemów jest umiarkowana i w miarę przewidywalna. Wtedy po prostu zakładasz, że część zakresu każdego cyklu będzie poświęcona na naprawy takich problemów i bierzesz to pod uwagę przy planowaniu. Czyli np. choć wiecie, że przeciętnie robicie 6 zadań L, 10 x M i 4 x S, to do zakresu wkładacie 4 x L 8 x M i 4 x S, aby zostawić miejsce na błędy.
Dotyczy go, ale ilość pracy nad błędami przeważa prace rozwojowe i / lub jest totalnie nieprzewidywalna. To znaczy jedno: w typowo projektowy sposób – z deadline’ami, kamieniami milowymi i związanymi z tym datami, takiego czegoś prowadzić się nie da. Przejdź na zarządzanie przepływem zadań z pomocą systemu Kanban (nie mylić z tablicą, która jest jedynie narzędziem). Kontynuujcie Kanbanem do momentu opanowania sytuacji (mniejsza i stabilniejsza ilość problemów), a jeśli sytuacji opanować się nie da – do planowania pracy operacyjnej trzymajcie się Kanbana, a całą otoczkę (wymagania, ryzyko, ogólna roadmapa/harmonogram etc.) róbcie tak, jak w tym poradniku z jednym zastrzeżeniem – zapomnijcie o obiecywaniu i zakładaniu jakichkolwiek dat. Skoro zakres jest nieprzewidywalny, to takie coś jest zwyczajnie niemożliwe.

Nowe pomysły do zbadania, zmiana zdania u interesariuszy. Tutaj zakładamy, że faktycznie wykonaliście wcześniej porządną robotę analityczną. Że owa zmiana zdania nie wynika z niedomówień, których można było uniknąć, tylko jest faktyczną zmianą zdania i nowym pomysłem. W takim wypadku zawsze staramy się wynegocjować realizację w kolejnym cyklu produkcyjnym. Czyli nie mówimy „nie”, tylko „nie dezorganizuj nam roboty, którą przecież wcześniej uznaliśmy za ważną i poczekaj tydzień-dwa”. W tym czasie pomysł może się uleżeć, dojrzeć, być przegadany z analitykiem. Skutki są dwa:

W momencie, gdy weźmiemy go do realizacji będziemy mieć o wiele większą jasność, o co tam chodzi.
Większość pilnych, genialnych pomysłów po odleżeniu 10 dni przestaje być pilna, ważna i genialna. Wcale nie wchodzi do zakresu.

Jeśli nie ma innej opcji, jeśli to koniecznie musi się zadziać – robimy krótkie przegrupowanie z zespołem i wracamy z propozycją jednej-dwóch (najlepiej dwóch – ludzie lubią mieć wybór) rzeczy, których nie dowieziemy w danym cyklu z powodu tej zmiany.

Jak widać naszym zadaniem jest obrona pojedynczego cyklu przed zmianami. Przed wywracaniem do góry nogami zakresu, przedłużaniem długości i tak dalej. A właściwie dlaczego? Dobre pytanie! Robimy tak ponieważ:

Ciągłe zmiany zakresu i przesunięcia dat powodują, że tracimy rytm, że wszystko rozciąga się i rozłazi. Interesariusze radośnie dodają nam kolejne pomysły, „bo i tak się gdzieś wciśnie”, a zespół nie bardzo czuje się zobowiązany do dotrzymywania przyjętych wcześniej założeń, skoro w międzyczasie wszystko pięć razy wywrócono do góry nogami. Dynamiczny, sprawnie idący do celu projekt stopniowo zamienia się w rozlazłą amebę, wypuszczającą zakresowe nibynóżki w losowych kierunkach.

Zwróć też uwagę, że bronić sugerujemy przede wszystkim pojedynczego, bieżącego cyklu produkcyjnego. To nie oznacza, że mamy nie przyjmować do zakresu nowych pomysłów, które sprawią, że efekt końcowy będzie dużo lepszy. Po prostu sugerujemy, by robić to na spokojnie i z głową, zamiast co dwa dni rzucać wszystko i zmieniać koncepcję.

NA KONIEC KAŻDEGO CYKLU

Pracę w regularnych cyklach lubimy tak bardzo m.in. dlatego, że ich koniec jest doskonałą okazją do przegrupowania i zrobienia porządków. Owszem, w tradycyjnym podejściu projektowym zakłada się, że w trakcie realizacji zrobimy jakiś przegląd, aktualizacje planów czy sesję lessons learned. Życie uczy jednak, że potem jakoś zwykle nie starcza na to czasu. Natomiast pracując w regularnych cyklach jest to nieco łatwiejsze – na koniec każdego powinniście zrobić trzy rzeczy:

Przejrzeć i podsumować to, co udało się zrobić. Skonsultować z interesariuszami, uzyskać ich feedback i akceptację. Wyciągnąć wnioski co do dalszego przebiegu harmonogramu. Może w toku prac okazało się, że coś jednak będzie mniej ważne, a coś nagle stanie się ważniejsze? Może coś okazało się zupełnie bez sensu? Może coś koniecznie trzeba dodać albo przebudować jakąś koncepcję? Zróbcie to sprawnie – seria spotkań z zespołem i interesariuszami zrealizowana w ciągu jednego dnia i zakończona ewentualnymi aktualizacjami naszego harmonogramu i/ lub dodatkowa listą zadań dla analityka (często nie wszystko uda się wyjaśnić od razu za jednym zamachem).
Warto też zastanowić się, jak w kolejnym cyklu można usprawnić sposób pracy. To bardzo ważne – zwiększy zaangażowanie zespołu i pozwoli stopniowo udoskonalać sposób w jaki pracujemy. Tak, by stopniowo był coraz lepszy, wydajniejszy, mniej uciążliwy. Prostą i łatwą w realizacji metodą przeprowadzenia takiego mini-lessons-learned będzie spotkanie Lean Cofee. Poza generalnymi optymalizacjami to też na przykład dobry moment, aby zastanowić się nad usprawnieniem naszej tablicy operacyjnej (np. dodatkowa kolumna, zmiana programu z Trello na Kanban Flow etc.) albo czy dobrze przewidzieliśmy naszą wydajność (S/M/L – o ile to robimy – powtarzamy – to nie zawsze ma sens!). Nie da się wymyślić z góry idealnego systemu pracy, da się za to wymyślić wystarczająco dobry, a potem go z cyklu na cykl stopniowo i mądrze optymalizować.
Ostatnia rzecz, to zaplanowanie prac na kolejny cykl. O tym pisaliśmy już wyżej. Warto dodać, że dobrze by działo się to innego dnia niż przegląd prac i dyskusja nad usprawnieniami. Po pierwsze za dużo planowania i dyskusji na raz jest nużące i sprawia, że zespół zaczyna robić to po łebkach. Po drugie – może okazać się, że będzie trzeba kilka spraw (szczególnie po przeglądzie i konsultacjach z interesariuszami) przegadać i doprecyzować, nim będziemy gotowi do planowania kolejnej krótkiej fazy.

Tyle.

SEXTO: ZAKOŃCZENIE I PRZEKAZANIE

A więc zbliża się koniec! To, co trzeba zrobić na tym etapie, można podsumować jednym zdaniem: dopełnij procedury akceptacji i zamknięcia ustalonej na etapie briefu projektu, dopieść wszystkich, doglądnij najważniejszych działań i upewnij się, że nie pozostawiasz po sobie żadnych trupów w szafach.

Niby proste, a jednak bardzo często dzieje się zupełnie inaczej. W projektach wewnętrznych wyzwaniem często jest sama akceptacja i zamknięcie projektu – łatwo wystartować, ale kto i w jaki sposób potwierdzi, że to już koniec? I jeszcze, żebyśmy mieli to pisemnie…? W przypadku projektów realizowanych dla klientów zewnętrznych jest to o tyle prostsze, że taka czy inna forma zamknięcia wymagana jest do wystawienia końcowej faktury. Ale nawet wtedy nie jest idealnie. Po prostu nam się nie chce. Jesteśmy zmęczeni i mało w nas motywacji, aby dopilnować zapięcia wszystkiego na ostatni guzik.

Dlaczego warto?

Ponieważ niezależnie od tego, jak świetnie nie szedłby nasz projekt w trakcie – ostateczne wrażenie będzie w dużej mierze zależeć od tego, co działo się na jego końcu. Wpłynie to na nasze późniejsze relacje z klientem, zespołem i całą naszą organizacją. Poza tym im lepiej zamkniemy wszystkie sprawy, tym mniejsze prawdopodobieństwo pożarów, problemów i pytań, z którymi ktoś może wrócić w najmniej odpowiednim momencie. Na przykład podczas urlopu, albo kiedy zajęci będziemy walką z problemami w kolejnym naszym projekcie. I wreszcie – ponieważ to nasza praca. Ponieważ przejmując projekt podejmujemy etyczne zobowiązanie do tego, że zrealizujemy go porządnie.

O czym warto pamiętać:

Brief briefem, ale jakiś czas przed końcem warto zainteresować się tym, czy wpisany tam (wpisaliście, prawda?) pomysł na akceptację projektu nadal jest aktualny. Jeśli całość wymaga jakiejś większej procedury (np. testy akceptacyjne) – dobrze zacząć przymierzać się do tego z odpowiednim wyprzedzeniem.
Po zakończeniu procedury akceptacyjnej uzyskaj jakiekolwiek pisemne potwierdzenie akceptacji wyników projektu. Choćby trzy słowa mailem.
Upewnij się, że na pewno wszystko zainstalowano, wszystkich przeszkolono, przekazano dokumentację i generalnie wszystko działa. Tak, wiem że zespół Ci to potwierdzał, ale to Ty jesteś liderem tego projektu i naprawdę słabo wygląda to, gdy potem odbiorca przychodzi z problemem, a Ty mówisz „a mówili mi, że to zrobili”.
Podobnie jak z przekazaniem wyników prac – upewnij się, że wszyscy twoi ewentualni podwykonawcy otrzymali płatności faktur.
Zadbaj o archiwizację dokumentów. Nie musi być wszystko pod linijkę, ale niech będzie jedno miejsce, gdzie zrzucicie wszystkie kluczowe dokumenty dotyczące realizacji.
Podziękuj wszystkim, którzy przyczynili się do sukcesu projektu. Zespołowi i sponsorowi przede wszystkim, ale nie zapomnij też o Ryśku z działu prawnego.

CAŁOŚĆ WIZUALNIE I TRZY ZDANIA NA KONIEC

Podobno jeden obraz wart jest tysiąca słów. A więc jeszcze raz to samo w formie obrazkowej:

Mimo, że powyższy tekst liczy bagatela 6000 słów i że spędziliśmy pisząc go bite dwa tygodnie, zdecydowanie nie wyczerpuje tematu. Nawet nie licząc już kwestii komunikacyjno – miękkich, jest przecież jeszcze tyle rozmaitych niuansów. Na przykład co zrobić, kiedy rozszerzający nam zakres interesariusz na pytanie „a co wrzucić w zamian” mówi: „nic mnie to nie obchodzi, musicie wyrobić się ze wszystkim!”.

Jeśli chcesz dowiedzieć się więcej o tym, jak skutecznie zarządzać projektem, serdecznie zapraszamy Cię na nasze szkolenia oraz kurs online.

igor mróz konsulting Autor tekstu:
Igor Mróz – doświadczony Project Manager, CEO Zero Bullshit Management.

Poznaj Podstawy zarządzania projektami, bez bullshitu

NASZ AUTORSKI KURS ONLINE: dwanaście lekkostrawnych lekcji, przykłady, materiały dodatkowe, całość zakończona certyfikatem

Zobacz i kup z gwarancją satysfakcji

Jak skutecznie zarządzać projektem od planu aż po finał?