utworzone przez Marcin Żmigrodzki
Po 30 wywiadach z praktykami projektów ekstremalnych zaczęła zapełniać mi się lista narzędzi, które są stosowane w takich projektach. I często słyszę o wielu z nich po raz pierwszy. Inne, mimo, że znane, natomiast są wykorzystywane w nietypowy sposób.
Poniżej zamieszczam listę narzędzi wspierających zarządzanie projektami bardzo zmiennymi i ryzykownymi, który stosują przedstawiciele uczelni, startupów, agencji reklamowych, korporacji, czy zespołów studenckich.
Przy okazji mam roboczy tytuł nowej książki Bardziej niż Agile. Co sądzicie? (więcej…)
utworzone przez Marcin Żmigrodzki
Pod hasłem projekt ekstremalny, eksploracyjny, eksperymentalny odnalazłem przedsięwzięcia z różnych obszarów:
- Hackathony – to bardzo krótkie projekty od 24 do 36 godzin zwykle. Ekstremalność w nich wynika z innowacyjności rozwiązania i krótkiego czasu na produkcję.
- Początkowe fazy startupów – przez kilka pierwszych lat (od 2 do 5) istnienia startupy często podlega on rewolucyjnym zmianom modelu biznesowego, obietnicy wartości, sposobu organizacji. Nazywane są one pivotami a wynikają z olbrzymiej niepewności rynkowej i czasem technologicznej młodego biznesu.
- Testowanie nowych technologii – takie projekty można spotkać w dużych korporacjach, np. lotnictwie, jak i w mniejszych firmach, które niekiedy wręcz specjalizują się w usługach walidowania nowych technologii. Na wejściu projektu jest hipoteza, że określona technologia zadziała, a na wyjściu jest prototyp albo negatywna informacja zwrotna. Taką technologią może być prototyp urządzenia albo model AI.
- Projekty naukowe – ich niepewność wynika z obszaru, w którym są realizowane. Jeżeli celem projektu jest dokonanie odkrycia naukowego, to musi on być niepewny. Paradoksalnie instytucje finansujące takie badania często wymuszają planowanie i kontrolę takich projektów w sposób kaskadowy.
Koncepcję prowadzenia projektów w sposób bardziej elastyczny niż oferuje to Scrum pojawia się w wielu miejscach, np.:
Prowadząc rozmowy z kilkudziesięcioma praktykami projektów bardziej zwinnych niż agile zauważyłem kilka cech wspólnych. Za każdym razem wywiad prowadzony był w formie pytań otwartych i starałem się unikać naprowadzania rozmówcy na z góry założone wnioski. Mimo tego wielu rozmówców przywoływało podobne spostrzeżenia. Poniżej prezentuję pierwsze z nich. Kolejne będę publikował w późniejszych wpisach oraz w książce, którą prawdopodobnie skończę pisać po wakacjach 2022.
Zmienne iteracje
Cechą powszechnie wymienianą w tytułowych projektach jest to, że iteracje trwają różne odcinki czasu. Jeden z rozmówców wskazał, że u nich sprint w jednym projekcie może trwać od kilku godzin do dwóch tygodni.
Kiedy sprint powinien się skończyć? Otóż wymienia się tutaj dwa warunki. Po pierwsze, gdy zostanie dostarczona wiedza albo wykonany zadany zakres. Estymacje czasowe są tak niepewne, że regularnie sprint trwa krócej lub dłużej niż zakładano. Czasem długi czas wynika z tego, że trzeba czekać wiele dni na wyniki, a czasem dlatego, że zadania są niedoszacowane. Po drugie iteracje może zakończyć „zwrotnica” (termin użyty przez jednego z rozmówców). Projekt dochodzi do punktu, gdy pojawia się rozbieżność nie do wyeliminowania w ramach bieżących założeń. Sprint jest wówczas zakańczany, a zespół musi rozwiązać kolizję, stworzyć nową koncepcję i zaplanować dalszy zakres.
Ponadto generalnie iteracje są dużo krótsze niż w typowym projekcie Scrumowym. Zdarza się, że zespół integruje rozwiązanie co 2 dni i na nowo je planuje.
Mały zespół niezależnych ekspertów
Generalnie zespoły w takich projektach są conajmniej o połowę mniejsze niż w Scrumie. Typowy zespół to 4-6 osób, ale niektórych firmach zajmujących się sztuczną inteligencją podano mi przykłady zespołów dwuosobowych.
Dodatkowo często członkowie zespołu tak planują prace, aby móc działać niezależnie od pozostałych. Wszelkie interface’y między zadaniami tylko podnoszą złożoność projektu, a przez to ryzyko niepowodzenia. Super, gdy ludzie w ekipie projektowej mają rozdzielne kompetencje, np. ktoś od hardware, ktoś od programowania, ktoś od prezentacji, ktoś od modelu AI.
Współpraca stacjonarna
Nawet w hackathonach zdalnych zespół regularnie spotyka się u kogoś w mieszkaniu lub w biurze. Praca twórcza wymaga spędzania ze sobą czasu. Przykuwanie uwagi do problemu, szczególnie, gdy zespół jest zmęczony lub zestresowany, wymaga spotykania się. Jeżeli zespoły pracują w osobnych lokalizacjach to i tak regularnie się spotykają, aby uzgodnić postęp prac.
Powraca spostrzeżenie, że efektywność działań innowacyjnych w formule zdalnej spada i to znacząco. Brakuje dynamiki, brakuje poczucia wspólnego rytmu dowożenia zadań, brak koncentracji na celu, brakuje nieformalnego komunikacji, która potrafi przenosić góry w kilka minut.
Zmienne przywództwo
Wydawało mi się, że w projektach bardziej zwinnych niż Scrum lider będzie wzorem servant leadershipu. Pomyłka! Projekty tak zwinne często doświadczają pivotów, zmian kierunków, koncepcji, wizji. Dodatkowo są narażone na dużą presję ograniczeń czasu, kosztu, wymogów jakościowych. Ktoś musi podejmować szybkie decyzje.
To, co jest często wymieniane to lider z silną wizją, niekiedy wpadający w autokratyzm. Jednocześnie jednak taki, który w chwilach spokojnego produkowania zadanego zakresu oddaje władzę ludziom. Gdy wiadomo, co robić servant leader, gdy trzeba narzucić kierunek – autokrata. To działa w startupach i na hackathonach. Co więcej członkowie zespołów zdają się doceniać takie podejście, bo to dużo porzadkuje.
Podsumowanie
Na liście mam jeszcze kilkanaście wniosków, które nasuwają się po ponad 30 rozmowach z praktykami skrajnie niepewnych projektów. Chętnie będę o nich opowiadał w miarę zdobywania nowej wiedzy od moich rozmówców. Więc jeśli interesuje was tematyka projektów ekstremalnych, to wracajcie do bloga Octigo.
utworzone przez Marcin Żmigrodzki
Zdjęcie autorstwa fauxels z Pexels
PMI wśród kilkunastu certyfikatów oferuje jeden, który cały czas ustawiany jest na pozycji unikalnego tytułu. I tak chyba ma pozostać? W Polsce jest ich 20, a na świecie mniej niż 1000, mimo, że tytuł ma około piętnaście lat.
PgMP (Program Management Professional) to certyfikat potwierdzający umiejętności i doświadczenie w zarządzaniu strategicznym rozwojem organizacji przez powiązane ze sobą projekty, czyli program. Programy coraz częściej spotyka się z biznesie, ale i w sektorze publicznym, choć nie zawsze tak się je nazywa. Ostatni o takim programie za kilka miliardów złotych miałem przyjemność posłuchać, a dotyczył regulacji naszych największych rzek.
PMI zaklasyfikował PgMP do grona certyfikatów dla seniorów. Jednak na szczęście dla kandydatów ostatnio obniżył nieco wymogi jego zdobycia, bo obniżył cenę do 800$, zrezygnował z oceny 360 stopni, jak na początku była wymagana, zezwolił, aby 4 lata doświadczenia w projektach były zastąpione przez posiadanie PMP, skrócił test do 170 pytań. Tak więc w minimalnym zakresie, kiedy mamy PMP, wystarczy, że:
- zostaniemy członkiem PMI na rok – 120$,
- zapłacimy 800$,
- udowodnimy 4 lata doświadczenia w zarządzaniu programami,
- zdamy egzamin.
W praktyce to egzamin jest największą przeszkodą. Oficjalne kandydat powinien w praktyce znać techniki i metody z PMBOK Guide 6 i Standard for Program Management 4. Jego zawartość nie zmieniła się od 2011 roku (co ciekawe sam Standard for Program Management jest z 2017 roku 🙂), bo z tego okresu datowany jest syllabus. Aktualnie trwają prace nad nowym standardem i zakończą się we wrześniu 2022 roku. Potem pewnie PMI da sobie około pół roku na przygotowanie nowych pytań i na wakacje 2023 będziemy mieli nowy egzamin PgMP.
Na liście referencyjnej książek nie jest to napisane wprost, ale cały czas obowiązuje PMBOK 6, nie 7! Obowiązuje też zestaw książek na temat egzekucji strategii za pomocą projektów. I tą kompetencję przede wszystkim będą sprawdzać na teście.
PMI chce się upewnić, że jesteśmy prawdziwym program managerem. To znaczy, że zarządzamy programem, a nie większym projektem. Tak, jest tu spora różnica. Na przykład program manager nie dostarcza sam zakresu, tylko ma od tego kierowników projektów. Nie tylko stosuje metodykę, ale i ją tworzy dla innych. Nie tylko zarządza kosztami, ale i finansowaniem programu, czyli szuka źródeł pieniędzy na pokrycie kosztów dla swoich project managerów.
Ostatnio odbyłem sesję mentoringową z kandydatem do PgMP i na jego prośbę przygotowałem kilkadziesiąt scenek, których celem jest rozróżnieniem między kierownikiem projektu a programu. To jest główny haczyk na egzaminie! Poniżej wrzucam trzy z nich z komentarzem, może to pomoże wam się przygotować do tego certyfikatu.
You are vice president of a retail network responsible for sales. One of your employees spotted an opportunity to increase sales by installing parcel machines at parkings of every store. The CEO asked you to prepare a brief evaluation of the idea before you apply for the budget. Which SPM activities would you use to achieve this objective? Who can be responsible for doing this task?
Program menadżer to często kluczowy lider w firmie, na przykład członek zarządu. Odpowiada za biznes. W tym wypadku za nawiązanie współpracy strategicznej. PMI będzie chciał sprawdzić, czy pracowaliśmy w podobnej roli. Dobrą odpowiedzią, oprócz zacytowania fragmentów SPM, będzie zlecenie pracy jakiemuś analitykowi, zorganizowanie warsztatów z potencjalnym partnerem, sformowanie zespołu do analizy wykonalności technicznej itd. Patrzymy na wyzwanie z pozycji top-level. Złą odpowiedzią będzie zakasanie rękawów i pisanie samodzielne prezentacji dla zarządu.
You run a program for releasing a new line of toys on the market. A marketing specialist told you that they analyzed competitive offers in this segment, and showed concepts of new toys to their kids, and they fit perfectly on the market. However you are afraid that you don’t have enough reliable data supporting this decision. What techniques would you use to validate if new toys were attractive for prospect customers?
Znowu, perspektywa top-level. Jako lider programu zorganizujemy warsztaty, ale niekoniecznie sami będziemy brali w nich udział. Być może w ogóle opracujemy proces analizy biznesowej dla nowych zabawek, żeby kolejne projekty musiały nim podążać. A skoro tak, to jak z rękawa powinniśmy sypać technikami typu grupa focusowa, design thinking, model Kano, prototypowanie itd. Raczej poziom governance i myślenia strategicznego niż operacyjny. Błędną odpowiedzią byłoby skupienie się na opracowaniu wymagań dla nowej zabawki.
Two project managers in your program discuss which project should cover a common part of work. They couldn’t come to an agreement, so they invited other project managers to discuss this issue. As a result they took the initiative to go to the program sponsor and ask him for initiating another project. Their argument is that this component aim is to test technology readiness and it doesn’t fit any particular project in the program. Program sponsor agreed because as he stated this would give additional benefit to the program. What should you do in this situation as a program manager?
Tutaj mamy do czynienia z próbą obejścia nas, czyli program menadżera. Nasi kierownicy projektu idą bezpośrednio do sponsora. To nasza rola, aby dodać nowy komponent, jeżeli jest zgodny z ograniczeniami i planem benefitów programu. Więc po pierwsze powinniśmy zareagować, że takie postępowanie jest niezgodne z governance. A następnie przedyskutujmy z nimi założenia nowego projektu. Złą odpowiedzią byłoby zachowanie się pasywnie. Program menadżer odpowiada za dostarczenie benefitów i z tego powodu musi kontrolować zakres, czyli zbiór komponentów programu.
Podsumowując, sam egzamin po skróceniu do 170 pytań nie powinien stanowić wyzwania w wymiarze czasowym. Nie można go nadal zdawać online, co tylko potwierdza, że jest rzadko wybierany. Problemem jest natomiast dobre zrozumienie roli program menadżera tak, jak ją rozumie PMI. I tu spodziewajmy się pułapek. Samo wykucie PMBOK Guide, czy SPM nie wystarczy.
utworzone przez Marcin Żmigrodzki
Właśnie wziąłem udział w przedsięwzięciu, które spełnia cechy projektu choć nie spodziewałem się, że projektem się stanie. Spisuję wspomnienia, bo może kogoś zainteresują moje wnioski przy pisaniu własnej książki. Gdy redaktor z wydawnictwa usłyszała, że udało mi się namówić do współpracy tzw. „beta readerów”, zapytała „Ilu ich pan ma?”, odparłem, że na początku było 30 osób. Usłyszawszy to powtórzyła pytanie „Ilu?!”. Ale od początku.
(więcej…)
utworzone przez Marcin Żmigrodzki
Na rynku jest wiele firm, które realizują projekty, których celem jest pozyskanie nowej wiedzy, albo realizowane w tak niepewnym środowisku, że nawet Scrum tu nie poradzi. Postanowiłem porozmawiać z nimi i dowiedzieć się więcej na temat tego, w jaki sposób prowadzą te projekty.
Temat projektów bardziej zwinnych niż Srum od jakiegoś czasu mnie na tyle zaintrygował, że postanowiłem zacząć pisać na ten temat kolejną książkę. Mam już nawet umowę z wydawnictwem na taki tytuł. Wierzę, że gdzieś tam w głowach geeków i nerdów ukrywa się metodyka projektów ekstremalnych i eksploracyjnych. Nie ma sensu tworzyć ją teoretycznie. Mądrzej będzie zapytać praktyków.
Znalazłem już pierwszych kandydatów do rozmów, ale gdybyście znali firmy lub zespoły, których projekty spełniają poniższe kryteria:
- Są obarczone wyjątkowo dużą niepewnością odnośnie efektu końcowego lub sposobu implementacji.
- Zespół jest świadomy tej niepewności i stosuje rozmaite patenty, techniki, metody, aby się z nią uporać.
- Zespół osiąga w subiektywnym odczuciu lub w obiektywnych wskaźnikach sukcesy w takim zarządzaniu.
- Zespół składał się z conajmniej 3 ludzi, aby pojawiła się konieczność zarządzania.
To mam gorącą prośbę o podesłanie sugestii porozmawiania z konkretnymi osobami. Można to zrobić na Linkedin: https://www.linkedin.com/in/ziemba/ lub na e-mail szkolenia@octigo.pl.
Raczej chciałbym unikać firm, które po prostu stosują Scrum lub Kanban. Firm, które robią bardzo ryzykowne projekty, ale to ryzyko wynika tylko z tego, że mają gigantyczny bałagan :).
Naturalnymi kandydatami są startupy, firmy technologiczne, np. IT lub medyczne. Ale może inne też się znajdą. Chętnie dowiem się więcej.
Taka rozmowa prawdopodobnie zajmie jedno lub dwa spotkania na wideo. Ja przygotowuję zestaw pytań, który będzie pretekstem do porozmawiania o sukcesach i bolączkach w projektach eksperymentalnych.
Po pierwszych kilkunastu rozmowach widzę, że do klasy projektów Ex wpadają projekty:
- Startupowe – główne ryzyko, to czy klient kupi rozwiązanie, mały zespół, ograniczone finansowanie, wysoka motywacja
- Związane z nowoczesnymi technologiami – czy opanujemy technologię i czy dostarczy spodziewane rezultaty, np. AI, lotnictwo, materiały, IT, firmy różnych wielkości od małych od korporacji, metodyki od lekkich, bo rozbudowane
- Biznesowe w korporacjach – testowanie nowych usług i produktów zanim zostaną skomercjalizowane, korporacje.
- Hackatonowe – krótki termin realizacji, nowatorska idea, wysoka motywacja.
- Naukowe – i tu zaskoczenie, bo nie znalazłem nikogo z tego obszaru, kto chciałby porozmawiać, a spodziewałem się, że tu dużo się dzieje. A może nie mam racji? Może polskie uczelnie wcale nie są innowacyjne.
utworzone przez Marcin Żmigrodzki
Na prośbę naszego partnera PMI Poland Chapter publikujemy komunikat o zbliżającej się konferencji. Konferencja tym razem odbędzie się głównie online z wyjątkiem ostatniego dnia warsztatów.
PMI Poland Chapter szykuje dla Was wydarzenie, które będzie pełne wiedzy przekazanej przez 3 dni wirtualnie oraz 1 dzień stacjonarnie w Warszawie! Już dzisiaj możecie nabyć bilety i być pewni swojego miejsca podczas tego wydarzenia!
Tematy jaki pojawią się na Kongresie to m.in.:
- Strategia PMI 4.0
- Social Network Analysis
- Disciplined Agile
- Industry 4.0
- Today’s ECO World
Obecna cena biletów będzie obowiązywać do 14 listopada.
Członkowie PMI – 699 złotych brutto
Standard – 799 złotych brutto
Bilety dla Grup – prosimy o indywidualny kontakt na:
congress@pmi.org.pl
Wydarzenie: https://www.facebook.com/events/850179372270393
Bilety: https://congress.pmi.org.pl/
