utworzone przez Marcin Żmigrodzki
autor zdjęcia: charlesdeluvio
Analiza biznesowa oferuje kilkadziesiąt technik zbierania i analizowania wymagań. Ktoś nieobeznany z taką mnogością narzędzi, może poczuć się zagubiony w ich gąszczu. Sam grad skrótów może doprowadzić do bólu głowy: VSM, CtQ, BPMN, UML, SIPOC, PBI, DoD, DoR, BPM, WBS, UAT, SoW.
Ostatnie rozmowy z uczestnikami szkoleń zainspirowały mnie do uporządkowania nieco podejścia do analizy. Główne pytanie, jakie przewijało się to „Jak zacząć?”. Zatem poniżej zamieszczam krótką odpowiedź na to pytanie.
(więcej…)
utworzone przez Marcin Żmigrodzki
4 maja ukaże się moja książka na temat Scruma pod tytułem Zwinni. Zbrodnia i Scrum.
Tutaj możecie znaleźć linka do sklepu wydawnictwa Helion, gdzie będzie można ją nabyć. Prawdopodobnie ukaże się też w Empiku i internetowych księgarniach.
Zanim będzie dostępna postanowiłem napisać kilka słów, o czym jest. Zwinni… to powieść w gatunku kryminału. Szajka przestępców zostaje zmuszona lub zachęcona do przeprowadzenia kradzieży ponad sześciotonowego dzieła sztuki. Ze względu na jego wielkość ów przedmiot trzeba zwinąć kawałek po kawałku, co staje się pretekstem do zorganizowania projektu scrumowego.
Około 90% książki to fabuła i akcja, natomiast 10% to pokazanie w praktyce zastosowań technik i metod zwinnych. Jest parę trupów, miłość i pieniądze, jak to w projektach.
Zależało mi jednak przede wszystkim na zilustrowaniu czegoś ulotnego, co jednak decyduje o tym, że projekt jest zwinny lub nie. Chciałem pokazać wartości projektu zwinnego, postawy te właściwe i te niewłaściwe w takim projekcie. Aby je dobrze pokazać, musiałem wprowadzić sytuacje konfliktowe, dylematy bohaterów, spadki motywacji i kryzysy. Jak to mówią, na dobre czasy, to i PRINCE2 da radę, dopiero w kryzysie ujawnia się duch zespołu.
Chciałem pokazać też coś jeszcze bardziej ulotnego. Z różnorodności osobowości członków zespołu, z tarć pomiędzy nimi i okazywanego wsparcia rodzi się duch zespołu. W trakcie kolejnych przełomów banda indywiduów staje się zgraną drużyną. Zależało mi na tym, aby na końcu czytelnik pomyślał sobie „chciałbym być częścią tej ekipy”.
Głównym bohaterem książki jest niedoświadczony Scrum Master, który ma za zadanie zorganizować projekt, w którym jeszcze nie brał udziału – kradzież dzieła sztuki. Głównym bohaterem jest też mafioso, który ku swojemu zdziwieniu i rozbawieniu jest wtłaczany w rolę sponsora projektu. Głównym bohaterem jest również dziewczyna, na której zlecenie odbywa się cała akcja, która nieporadnie próbuje odgrywać rolę product ownera. Wreszcie najbardziej głównym bohaterem jest zespół, który nawet nie ma świadomości, że jest zwinny, ale ta ignorancja niespecjalnie mu przeszkadza.
Jeżeli jesteście ciekawi, czy mi się udało, zapraszam do lektury. Tutaj będziecie mogli znaleźć książkę.
Aby przekonać wydawnictwo, że jest to nadal podręcznik, to na końcu książki dodałem słownik terminów ze świata agile. Także jest pełna profeska.
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.
