Podejście kaskadowe (15000 lat testów) oferuje uporządkowanie i przewidywalność, przynajmniej teoretycznie. Z góry przemyślany produkt finalny, dowożony w terminie i koszcie. W praktyce oferuje natomiast inną korzyść – porządek w dużej skali.
Estymacje mogą okazać się błędne, natomiast jeżeli projekt prowadzony jest metodycznie, to wiadomo dokładnie, w którym miejscu znajduje się błąd i jakiej jest skali. To w konsekwencji umożliwia realizację nawet dużych inwestycji bez wpadania w chaos.
Podejście zwinne (30 lat testów) oferują zaś sprawność działania, przynajmniej teoretycznie. Jednak zbudowanie postaw, modelu mentalnego nastawionego na obserwacje i akceptację zmian zwiększa responsywność projektu na nowe pomysły. To w efekcie ma prowadzić do większej wartości, kosztem utraty kontrolowalności projektu. Ta utrata kontroli mści się ze spotęgowaną siłą, gdy skala projektu rośnie. Zaryzykuję tezę, że agile jest raczej dla projektów małych.
Hybrydowe zarządzanie projektami (dalej będę używał skrótu HPM) powinno być hybrydowe w różnych wymiarach. Zatem dalsze rozważania przeprowadzę po kolei według zakresu, czasu, kosztu, jakości i zespołu.
Zakres
WBS kontra Product Backlog. WBS super moce:
Uporządkowanie odgórne.
Możliwość uporządkowanego poruszania się po nawet bardzo dużym zakresie, o ile wprowadzono sensowną strukturę.
Zgodność z metodami ścieżki krytycznej i wartości wypracowanej. Dla projektów kaskadowych dużą wartością jest możliwość precyzyjnej kontroli stanu. Dzięki WBS jest możliwe wykorzystanie precyzyjnych metod kontroli.
WBS słabości:
Odporność na zmiany. WBS zniechęca kierownika projektu do wprowadzania zmian w zakresie.
Konsekwencje zmian w WBS w innych wymiarach. Przykładowo zmiana tylko sposobu poukładania komponentów w WBS może wysadzić w powietrze wskaźniki wartości wypracowanej.
Ryzyko niekontrolowanego pełzania zmian w sytuacji, gdy planowany produkt finalny nie odpowiada potrzebom klienta.
Product backlog super moce:
Niski próg wejścia. Każdy kto miał mamę, pamięta listy zakupów. Backlog to taka lista zakupów tyle, że posortowana według ważności a nie kategorii.
Elastyczność wobec zmian. Gdy pojawia sie nowy, ważniejszy pomysł, po prostu ląduje na górze backlogu.
Zgodność z tablicą Kanban.
Słabości backlogu:
Próbowaliście kiedyś zarządzać backlogiem mającym 200 pozycji? Już przy backlogu długim na dwa ekrany pojawia się problem z utrzymaniem jego aktualności.
Brak wewnętrznej logiki i struktury. Backlog to po prostu worek życzeń. Gdyby święty Mikołaj nie był w stanie zapamiętać wszystkich dzieci na świecie, to pewnie używałby backlogu.
W naturalny sposób pojawia się pytanie, dlaczego nie można połączyć obu podejść. I wybrane systemy do zarządzania projektami czynią w tym kierunku kroki. W Trello można wstawiać podzadania do zadania w formie checklisty, w Proofhub dopuszczalne są dwa poziomy zagłębień zadań, w Teamwork karta wymagania może być zdekomponowana na zadania i dopiero one wędrują po kanbanie.
Sam również pokusiłem się, o takie rozwiązanie i byłem strasznie zadowolony, gdy udało mi się je zaimplementować.
Czas
Kaskadowe projekty zakładają istnienie harmonogramu z datami, miejscami alokacji zasobów ludzkich i nieludzkich. Dzięki temu można identyfikować wąskie gardła, optymalnie przydzielać ograniczone zasoby do wielu projektów naraz, przewidywać przepływy finansowe oraz kontraktowe zobowiązania.
Silne strony podejścia kaskadowego:
subiektywne poczucie władzy nad czasem,
transparentna komunikacja mapy drogowej.
Słabości:
niska wiarygodność estymacji,
skomplikowane zarządzanie, gdy wprowadzimy wiele zależności do ścieżki krytycznej.
Zwinne projekty zakładają istnienie stałego rytmu (iteracji) i niezdeterminowanego końca.
Silne strony podejścia zwinnego:
duża elastyczność zmian wymagań,
przejrzystość zadań,
wsparcie samoorganizacji zespołu,
oparcie na empirycznych czasach a nie teoretycznych estymacjach.
Słabości:
łatwość zabałaganienia w przypadku większych projektów,
nie odzwierciedlenie różnych procesów produkcyjnych zadań.
nie odzwierciedlenie zależności i ograniczeń zadań.
Ta rozbieżność rodzi ryzyka, że projekt kaskadowy zawierający w sobie zwinny rozjedzie się w czasie.
Silne strony filozofii zwinnej:
budowanie motywacji wewnętrznej,
wzmacnianie postaw nastawionych na innowacji i dostarczanie wartości.
Słabe strony:
rozproszenie odpowiedzialności,
chaos komunikacyjny w większych zespołach,
brak twardego rozliczania i narzędzi motywacji negatywnej w przypadku porażek.
W podejściu hybrydowym często obarczamy kierownika projektu ryzyko rozjazdu sprintów z Ganttem. Większość systemu do kanbana pozwala na wprowadzenie dat zadań (co jest w istocie niezgodne z ideą kanbana), a wiele z nich również pozwala na wyświetlenie widoku kanbana na kalendarzu albo na uproszczonym Ganttcie.
Koszt
Tu mam największą zagwozdkę. Bo agile nic nie mówi o koszcie projektu a waterfall dużo.
Jednak mając rozliczone co do godzin zadania (co jest nie do końca zgodne z ideą autonomii zespołu) można śledzić zużycie środków finansowych w czasie i śledzić szansę zmieszczenia się w budżecie. Raportowanie kosztu wspiera większość systemu do kanbana, np. Proofhub, Monday, Clickup, Jira, a nawet Trello po zainstalowaniu odpowiedniego pluginu.
Zespół
I tutaj mamy największy rozjazd stylów współpracy. Kaskada wspiera przywództwo w stylu dziel i kontroluj. PM dekomponuje zadania, deleguje je na członków zespołu, a potem odpytuje, czy praca idzie zgodnie z planem.
Silne strony podejścia kaskadowego:
nieograniczone możliwości skalowania zespołu przez delegowanie i pionizowanie struktury organizacyjnej,
jasny podział odpowiedzialności.
Słabości:
redukcja motywacji wewnętrznej i innowacyjności zespołu,
kierownik projektu może stać się wąskim gardłem.
Natomiast w agile nie ma kierownika projektu. Zespół zbiorowo odpowiada za zadania i autonomicznie je sobie przydziela.
Myślę, że dużo zależy od stylu. Jeżeli mamy kierownika projektu, który z jednej strony potrafi wyciągnąć estymacje czasu i kosztu z zespołu, a z drugiej strony kontroluje postęp prac w sposób nieinwazyjny, wspiera w trudnych momentach i ufa ludziom, to ma to szansę zadziałać. Przyjazna dyktatura jest kwestią stylu.
Podsumowanie
Od kilku lat zaczyna się pojawiać, narazie nieśmiało, hasło hybrydowego zarządzania projektami. Poniżej zamieszczam wykres Google Trends pokazujący jego rosnącą popularność.
Dlaczego HPM może okazać się nowym trendem? Bo ciągle pozostaje problem skalowalności agile’a. SAFe spotyka się dzisiaj z olbrzymią falą krytyki, ale potrzeba organizacji, aby jednocześnie dać autonomię i otworzyć projekty na zmiany oraz zapewnić kontrolę i uzgadnianie z zadaną strategią pozostaje.
Bo projekty kaskadowe lepiej zapobiegają nieprzewidzianym kosztom zmian, a projekty zwinne lepiej odkrywają wartość dla użytkownika końcowego.
Na tytułowym obrazku hybrydowy project manager według koncepcji MidJourney. Żeby nie zostać posądzonym o seksizm, załączam też wersję ilustracji kobiecą.
Jeżeli podasz kod Octigo10, to uzyskasz rabat w wysokości 10% na wejście na kongres zarządzania projektami.
Poniżej informacja od organizatorów:
Dzień 1 to dzień PMIthonu, czyli pierwszego w Polsce hackathonu dla Project Managerów. Będziecie mogli spróbować swoich sił w rozwiązaniu przygotowanego zadania. Nie zabraknie dyskusji i dzielenia się doświadczeniami. Jesteśmy pewni, że nie będziecie się nudzić.
Dzień 2 i 3 to tradycyjne dni prelekcji i warsztatów, na których nasi prelegenci i prelegentki poruszą tematy dotykające tegorocznego motywu przewodniego Kongresu – Transform | Project | Value
Przy okazji niedawnego szkolenia w ręce wpadła mi metodyka PRISM przygotowana przez stowarzyszenie Green Project Management. Postanowiłem się podzielić moimi spostrzeżeniami na temat tej metodyki i w ogóle podejścia Green Project Management.
GPM jest stowarzyszeniem przypominającym nieco PMI 40 lat temu. Chyba stowarzyszeniem, bo trudno mi było znaleźć na ich witrynie konkretne dane rejestrowe. Ale odnoszę wrażenie, że grupa woluntariuszy zorganizowała się wokół wspólnej idei uczynienia inwestycji projektowych bardziej zielonymi.
GPM oferuje 3 poziomy certyfikatów, które w formule ich zdobywania bardzo przypominają PRINCE2 Foundation i Practitioner. Krótkie test albo studium przypadku i rozmowa. Szybki test ilości ogłoszeń o pracę wymagających któregoś z tych certyfikatów pokazuje, że jeszcze długa droga przed nimi. Dla porównania PMP w momencie pisania tego tekstu występował w Polsce w ponad 5000 ogłoszeń, GPM-b + GPM-s + GPM-m w żadnym, dosłownie zero ogłoszeń. Rozszerzyłem wyszukiwanie na USA i wyniki były identyczne 347 000 do zera na korzyść PMP. Nie oceniam w żadnym wypadku merytoryki tych certyfikatów tylko popularność wśród pracodawców, ale uważam, że ten wskaźnik jest niestety bardziej pragmatyczny.
Wiedza na certyfikacji bazuje na kolejnym komponencie, czyli metodyce PRISM. De facto nie zdefiniowałbym PRISM jako metodyki, ale raczej nakładki na metodykę, która podkreśla istotność pewnych obszarów. Czyli PRISM nie powie, jak prowadzić projekt, tylko, jakie postawy i zachowania są pożądane w projekcie.
A te postawy należą do trzech grup: środowisko naturalne, lokalna społeczność i prawa człowieka. PRISM promuje prowadzenie projektów zgodne z prawem, promujące lokalną ekonomię, dbanie o interesy lokalnej ludności, poszanowanie praw człowieka takich, jak work-life balance, uczciwa płaca, brak dyskryminacji itp.
Problemem dla mnie jest fakt, że te dobre praktyki są przedstawione na poziomie bardzo ogólnym. PRISM nie mówi, co operacyjnie robić, tylko, co warto mieć na uwadze. Oznacza to, że z dużą łatwością można wdrożyć PRISM bardzo fasadowo. Wystarczy zademonstrować kiika przykładów właściwych starań.
PRISM jest metodyką kaskadową. Promuje się z góry zdefiniowany cykl życia projektu składający się z inicjacji, 4 etapów projektowych i etapu obserwowania korzyści po projekcie. Fajne jest uwzględnienie zarządzania korzyściami, którego brakuje w PMBOK a jest obecne w Standard for Program Management PMI.
Godne uznania jest też ujęcie w cyklu życia etapu eksploracji, w trakcie którego zespół zdobywa wiedzę o możliwych do realizacji koncepcjach. Jak widać eksploracja przebija się powoli do świadomości w różnych inicjatywach.
Za wyjątkiem jednak kilku praktyk brakuje w PRISM konkretów. Brakuje operacyjności, czyli wiedzy jak wdrożyć PRISM w konkretnej sytuacji. Jest to szczególnie istotne, bo GPM proponuje audyt organizacji w zakresie wdrożenia ich metodyki.
Podsumowując, GPM jest mało znaną inicjatywą, która od kilkunastu lat próbuje się przebić na rynek. Przebija się za pomocą certyfikatów, metodyki PRISM oraz audytów organizacji PSM3. Jednak odnoszę wrażenie, że o ile jakaś regulacja unijna nie wymusi malowania projektów na zielono, to długa droga przed GPM, aby osiągnąć status zbliżony do PRINCE, IPMA, czy PMI.
Emilia wysłała mi informacje rejestracyjne GPM, które udało się odnaleźć po rejestracji znaku towarowego. GPM okazuje się być spółką z ograniczoną odpowiedzialnością (LLC) zlokalizowaną w Fort Wayne.
W październiku rusza kolejna edycja studiów Zarządzanie projektem IT oraz Zarządzanie wymaganiami i analiza biznesowa na Akademii Koźmińskiego.
Jak co roku wprowadziliśmy kilka modyfikacji. W przypadku ZPIT to zredukowanie czasu na zarządzanie ryzykiem ilościowe charakterystyczne dla projektów kaskadowych, a rozszerzenie o jeden dzień rozważań na temat zarządzania wymaganiami (BPMN i UML) oraz elementy zarządzania eksploracją.
W przypadku ZWAB dodaliśmy moduł na temat zastosowania sztucznej inteligencji, a dokładnie modeli językowych, w analizie wymagań na bazie naszych doświadczeń zdobytych przy tworzeniu narzędzi takich, jak Dot Chart, GoodBA i Sopulo.
I teraz ważna informacja. Już zrekrutowaliśmy po jednej grupie na ZPIT i ZWAB, ale ponieważ zebrała nam się kolejka chętnych na oba kierunki, to wspólnie z Akademia Koźmińskiego uruchomiliśmy rekrutację na dodatkowe, równoległe grupy, które uruchomią się miesiąc później. Serdecznie zapraszamy wszystkich chętnych.
Postanowiłem zrobić kolejny krok, analizując możliwości sztucznej inteligencji w analizie wymagań. Napisałem system, który na podstawie wczytanej dokumentacji ma zadanie napisać instrukcję stanowiskową.
Prosi o wczytanie dokumentów opisujących dany proces. Następnie je automatycznie analizuje od strony zawartości.
Prosi o wybranie sekcji dokumentu SOP, które mają pojawić się w finalnym dokumencie. Użytkownik może dowolnie poprzestawiać ich kolejność przez przeciąganie i upuszczanie.
Każda sekcja może zostać automatycznie wygenerowana przez algorytm sztucznej inteligencji. Jeżeli użytkownikowi spodoba się rezultat, może przejść dalej. Jeżeli nie, to może ponowić generowanie, albo cofnąć się do kroku wcześniejszego i wczytać więcej dokumentacji.
Na kolejnej zakładce użytkownik może edytować wygenerowane treści według własnego uznania.
Wreszcie całość można pobrać w formacie PDF lub DOC do dalszej obróbki.
SOP (standard operating procedure) to dokument opisujący, w jaki sposób powinien zachować się pracownik w ramach pracy w danym procesie. Z jednej strony ujmuje proces w zawężonej perspektywie wybranej roli/aktora, a z drugiej strony dodatkowo zawiera informacje o oczekiwaniach jakościowych pracy, etykiecie, sposobie rozmowy z klientem, warunkach brzegowych, sposobach poprawnego wykonania zadania itd.
Idea tworzenia SOP powstała w wojsku amerykańskim, a stamtąd przeniosła się do procedur medycznych. Dzisiaj rozlewa się na świat biznesu. Odbiorcą SOP jest konkretny operator w procesie i celem jest zwiększenie jakości i powtarzalności wykonywanej pracy.
To wciąż jest prototyp i ciągle jest poprawiany. Natomiast to, co mnie przede wszystkim interesuje to, czy nawyki i oczekiwania pracowników zmieniają się w kierunku wykorzystywania takich narzędzi jak Sopulo zamiast ręcznego pisania dokumentacji.