Trzecie wydanie Zarządzanie projektami dla początkujących w drodze

Trzecie wydanie Zarządzanie projektami dla początkujących w drodze

O czym chcielibyście przeczytać? Czego wam brakowało? O co uzupełnić trzecią edycję Zarządzania projektami dla początkujących? Wczoraj wydawnictwo Helion zaproponowało, aby rozpocząć prace nad nową wersją książki.

Myślałem o rozdziale na temat analizy biznesowej, o motywowaniu zespołu, albo o projektach w startupach. Jeżeli macie propozycje tematów ważnych dla początkującego kierownika projektu, to chętnie się z nimi zapoznam.

W czerwcu prawdopodobnie poszerzony tekst zostanie oddany do druku, przez wakacje będzie trwała jego korekta i skład, a drukiem ukaże się prawdopodobnie na jesień.

Tutaj załączam linka do drugiej edycji książki.

PMI – narodziny imperium

PMI – narodziny imperium

PMI przyjęła strategię tworzenia Imperium. Fakty: w sierpniu zeszłego roku zakupiło Disciplined Agile Delivery, kilka miesięcy temu wprowadziło zmiany w samej książce PMBOK Guide 7, ogłosiło nowy sposób uczenia się do PMP, teraz opublikowało nowy cennik dla firm, które chcą oficjalnie szkolić w tym zakresie. Te wszystkie informacje składają się na spójną strategię. Aby dodatkowo upewnić się, że mam rację, z Witryny PMI, ściągnąłem dane o 26 000 posiadaczy PMP, to znaczy tylko daty i kraje, w których zdali ten egzamin. Oto jak wygląda sytuacja.

(więcej…)

Zgubiłem się, czyli zmiany w PMBOK Guide i PMP, czyli Dezyderata, Dezyderata…

Zatytułowałbym artykuł na temat zbliżających się zmian w standardach PMI “Nadchodzą wielkie zmiany”, albo “Co nowego szykuje dla nas PMI”, ale bardziej pasuje do całej sytuacji tytuł “Wielka konfuzja”.

Fakty są takie:

  1. Egzamin PMP zmienia się znacząco od 1 lipca 2020. Połowa pytań ma od tego momentu dotyczyć agile. Terminy takie jak samoorganizujący się zespół, sprint, retrospektywa, motywacja wewnętrzna, backlog, opowiastki użytkownika z pewnością są dobrze znane i wykorzystywane przez kierowników budów, portów, konstruktorów dźwigów, linii wysokiego napięcia, mostów, leków, przezbrajających linie technologiczne w fabrykach aut, mebli i cukierków oraz stawiających nowe fabryki. Sądzę, że to dla was ta zmiana będzie wyzwaniem.
  2. Zmiana w testach PMP pociągnie za sobą zmianę struktury dziedzin wiedzy na egzaminie. Odnoszę wrażenie, że PMI chce skupić się bardziej na weryfikacji miękkich kompetencji kierownika projektu, a nieco mnie sprawdzaniu znajomości technik i procesów.
  3. PMI podkreślił, że zakres materiału na egzamin PMP to wiele więcej książek niż tylko PMBOK Guide, publikując je na osobnej stronie. 4 na 10 dotyczą przede wszystkim projektów IT, więc kierunek rozwoju stowarzyszenia wydaje jasny. 5 na tych 10 to encyklopedie zarządzania projektami, w tym samym PMBOK Guide, co oznacza spore rozszerzenie zakresu wiedzy wymaganej na egzaminie.
  4. Dwa miesiące temu wyszło polskie tłumaczenie książki w wersji 6. Tydzień temu opublikowano draft wersji 7, która jest zupełnie inaczej skonstruowana. Przykładowo zamiast ponad 600 ma 37 stron i zawiera złote rady mówiące, co to znaczy być dobrym kierownikiem projektu. Ciekawe, że PMI nie uznaje polskiego tłumaczenia za oficjalne skoro nie ma go wymienionego na stronie PMBOK Guide. Jest za to 11 innych języków. Jaka będzie rola polskiego PMBOK Guide, jeśli kolejna wersja wyjdzie na koniec tego roku?
  5. Draft standardu zarządzania projektami wersja 7 zawiera ogólne zalecenia dotyczące bycia wzorowym PMem. Jak chcecie sami możecie się z nim zapoznać, logując się na PMI i przechodząc do edycji draftu. Najlepiej, jak streszczę całego PMBOKa, to będziecie szybciej wiedzieli, o co chodzi. Dowiemy się z niego, że:
    1. Projekty wchodzą w skład portfeli i programów.
    2. Projekt kiedyś się kończy i ma dostarczyć cele.
    3. Zespoły projektowe dostarczają zakres a różne sposoby, dosłownie “a broad range of approaches”.
    4. Koordynacja zespołu jest bardzo ważna.
    5. Wśród ról w zespole można wymienić: lider, coach, członek, przedstawiciel biznesu, ekspert, klient, sponsor, komitet.
    6. Lider może być kierownikiem projektu, scrum masterem lub inną osobą, która napędza projekt. Dalej leci opis na pół strony każdej z powyższych ról.
    7. Na projekt ma wpływ otoczenie.
    8. Zaś organizacja może zastosować swój know-how, aby wspomóc projekt.
    9. Produkt projektu to coś, co projekt dostarcza.
    10. Dalej lecą przykazania kierownika projektu:
      • bądź pilny, pełny szacunku i troskliwy.
      • dbaj o szacunek.
      • gadaj z udziałowcami.
      • skup się na wartości.
      • reaguj, jak coś się dzieje.
      • motywuj, ucz i wpływaj na innych.
      • dostosuj sposób prowadzenia projektu do potrzeb.
      • dbaj o jakość.
      • używaj swojej głowy.
      • analizuj okazje i zagrożenia.
      • bądź elastyczny.
      • wspieraj zmiany.
      • Można by jeszcze dodać: nie słuchaj głośnych i napastliwych swą udręką… A tutaj link, jakbyście chcieli posłuchać PMBOKa na żywo.
    11. I to jest naprawdę cała książka. Domyślam się, że uzupełnieniem jej mają być owe 10 książek, o których wspominałem wcześniej.
  6. Ok, trochę przesadziłem w poprzednim punkcie, bo PMI ogłosił, że na koniec roku zamierza opublikować PMBOK Guide 7, którego częścią będzie powyższy 37 stronicowy standard. Jedyne, co wiadomo oficjalne, to to, że reszta tej książki będzie składać się z 8 obszarów wiedzy: zespół, interesariusze, cykl życia, planowanie, niepewność, dostarczanie, efektywność, praca w projekcie. Jest to totalna przebudowa struktury względem PMBOK Guide 6. Jeżeli dobrze rozumiem zapowiedzi, to zrezygnuje się z proponowania procesów projektowych. Pytanie, czy w książce znajdą swoje miejsce techniki i narzędzia?
  7. PMI miesiąc temu ogłosił, że wkrótce afiliowane firmy szkoleniowe, tzw. REP, będą musiały korzystać z materiałów szkoleniowych przygotowanych przez PMI oraz że trenerzy będą musieli być certyfikowani. Dziś certyfikuje się tylko firmę, a trener musi mieć PMP. Zasugerowano między wierszami, że zmieni się sposób opłacania przez firmę szkoleniową za posiadanie tytułu REP z płaskiego rocznego abonamentu na płatność per szkolenie. Wydaje mi się, że takim model istnieje w PRINCE2, tylko, że tam sam egzamin jest elementem szkolenia. W PMI kandydat może uczyć się dowolnie i sam idzie na egzamin w Pearson/Vue. Zastanawia mnie, na ile bycie REP przestanie być w związku z tym opłacalne dla firm szkoleniowych.

Wniosek

Po pierwsze, jeżeli ktoś akurat ma zebrane odpowiednie doświadczenie i chciałby zdać PMP, to niech się pośpieszy. Szczególnie, jeżeli nie pracuje w środowisku IT. Jest styczeń, do czerwca pozostało pięć miesięcy, więc zdąży jeszcze zdać po staremu.

Po drugie, jeżeli ktoś nie zdąży przez pierwszym lipca, to sugeruję, aby poczekał, aż nowa baza pytań się uleży, aż pojawi się tłumaczenie na polski (dziś nie wiadomo, kiedy to nastąpi). Proponuję poczekać do nowego roku, tj. 2021, bo wtedy wyjdzie nowy PMBOK Guide i będzie wiadomo więcej.

Jestem zagubiony w ocenie, w którą stronę idzie rozwój tej organizacji. Dotychczasowa książka choć trudna w odbiorze, bo napisana suchym językiem, była spójną i uporządkowaną encyklopedią. Teraz jej pierwsza część to charakterystyka kultury organizacyjnej wioski smerfów, a druga jest wielką zagadką wciąż. Rośnie waga projektów IT, ignorując inne sektory. Rośnie ranga samoorganizujących się zespołów, redukując rolę kultury kontroli i dyrektyw. Ma wrażenie, że środowisko zachłysnęło się podejściem zwinnym. Natomiast moim zdaniem ono nie przystaje do każdej sytuacji. W sytuacji kryzysowej przydaje się jednoosobowe kierownictwo i krótkie jasne procesy decyzyjne. Jak gaszę pożar, to chcę znać procedurę i wiedzieć, kto dowodzi.

Szkolenie PMP 9-12 marca

Serdecznie zapraszamy chętnych a szkolenie przygotowujące do PMP we Wrocławiu od 9 do 12 marca.

Szkolenie wprowadzi Cię w świat PMBKO Guide 6. Opowiemy o samym procesie uzyskiwania certyfikacji PMP, przebiegu egzaminu. Będziesz miał również możliwość napisania próbnego egzaminu.

Poruszmy również krótko załącznik do PMBOK, czyli Agile Practice Guide.

Tutaj możesz przeczytać więcej o samym szkoleniu

Frameworki skalujące zwinne podejście do zarządzania projektami

Frameworki skalujące zwinne podejście do zarządzania projektami

Scrum zadomowił się już na dobre w polskich organizacjach IT (firmach i działach). Teraz na krzywej hype cycle koncepcji biznesowych wspinają się tzw. frameworki rozszerzające zwinną filozofię na duże przedsiębiorstwa. W jednym z poprzednich wpisów (patrz: Defiliada koncepcji biznesowych) przedstawiłem analizę z 2016 roku koncepcji zarządzania projektami i wówczas Enterprise Agile Frameworks było na samym początku drogi, jeszcze przed dostrzeżeniem przez biznes, w fazie zwanej Innovation Trigger.

Rzut oka na raport State of Agile z 2019 roku (tytułowy wykres kołowy) pokazuje, że na razie jedną trzecią rynku zagarnął SAFe, a po nim Scrum of Scrums. Jednak opcji jest dużo więcej. Przykład rozwoju metodyk zwinnych dowodzi, że po okresie rozkwitu dziesiątków podejść, nastąpiło wymieranie i trzy czwarte rynku zagarnął Scrum z technikami zapożyczonymi z Kanban, XP, czy Lean. Moim zdaniem ten scenariusz powtórzy się również na poziomie enterprise agile. Na placu boju za parę lat pozostaną dwa lub trzy frameworki, przy czym pierwsze z nich zgarnie zdecydowaną większość rynku… Albo cała idea skalowanego agile’a ustąpi miejsca kolejnemu pomysłowi na organizację pracy dużych zespołów.

Poniżej widać diagram z Google Trends dotyczący zapytań o ‘Enterprise Agile Framework’ od roku 2004 do dzisiaj. Jak widać nieznaczny trend wzrostowy wystąpił w 2016 roku i od tego momentu zainteresowanie tym hasłem utrzymuje się na stałym poziomie.

Wiele dużych korporacji sięga po różne modele skalowalnego agile. Powodów zainteresowanie może być wiele: chwilowa moda, chęć pochwalenia się przed kolegami z zarządów innych korporacji, naciski ze strony pionu HR, bo chwilowa moda lub chęć pochwalenia się przed kolegami z pionów HR innych korporacji, albo bardziej merytorycznie potrzeba pokazania kandydatom do pracy, że mimo swojej skali organizacja ma przyjazną kulturę organizacyjną lub wreszcie rzeczywiste pragnienie podniesienia efektywności organizacji, w sytuacji, gdy inne, bardziej tradycyjne podejścia nie przyniosły wystarczających owoców. Nie znam raportu Gartnera z 2019 roku (nie jest dostępny za darmo), ale według raportu z 2016 roku faktycznie ta koncepcja była na początku swojej drogi.

Metodyki zwinne świetnie sprawdzają się w niewielkich zespołach. Moim zdaniem oprócz rozmiaru takie zespoły powinny mieć jeszcze kilka cech:

  • brak czynników nastawiających negatywnie do pracy, jak frustracja, niechęć do kolegów lub firmy, brak pieniędzy na podstawowe potrzeby,
  • brak konfliktów na bazie rywalizacji o lepsze zadania, pensję, wdzięki współpracowników,
  • brak próżniactwa społecznego w zespole, czyli “wożenia się” na pracy wykonywanej przez innych,
  • conajmniej przeciętne kompetencje w obszarze merotyrycznym projektu, np. w danej technologii. Moim skromnym zdaniem, jeżeli cały zespół jest na poziomie “nie wiem, że nie wiem”, albo innymi słowy na początkowym wzniesieniu wykresu Krugera-Dunninga.
  • wstawienie zespołu pod klosz Scruma, w którym mogą mieć poczucie autonomii.

Jak to się ma natomiast do dużych, macierzowych organizacji. Można tu znaleźć szereg czynników ograniczających stosowalność filozofii zwinnej:

  • budżetowanie – na ogół w cyklu rocznym planuje się i rozlicza budżety działów, świat projektów jednak nie rządzi się taką kalendarzową dynamiką.
  • hierarchia dowodzenia – kadra menadżerska bierze większe pieniądze za to, że jest odpowiedzialna za większy fragment organizacji, to oznacza, że będzie starała się kontrolować działania w podległych obszarach. Szczególnie ważne będą dla niej aspekty organizacji, za które menadżerowie mogą zostać zwolnieni lub dostać większą premię albo awans. Posiadanie władzy i rywalizacja o dostęp do pysznej termitiery, padłego mamuta, stada samic, czy pokoju na dwudziestym piętrze są stałą cechą naszego gatunku.
  • raportowanie do zagranicznych właścicieli lub na giełdę – na duże firmy nakładane są rozmaite obowiązki kontrolne, które mogą zaburzać autonomię zwinnych zespołów.
  • wielozadaniowość ludzi – macierzowość struktury organizacyjnej oznacza, że pojedynczy specjalista może przynależeć do wielu zespołów realizujących równolegle odmienne zadania. To z kolei prowadzi do błędnego planowania prac i przeciążenia ludzi.
  • trudne sytuacje decyzyjne – istnieją sytuacje, których rozwiązywanie wspólnym konsensusem jest najprostszą drogą do wojny domowej. Znajomy opowiadał mi o zwinnym zespole, który stanął przed wyzwaniem podzielenia między siebie premii. Oczywiście pieniędzy było za mało, aby zadowolić wszystkich. Zawsze jest za mało, bo tu włącza się teoria perspektywy. Podwyżka o 10% przestaje cieszyć, gdy ta wredna jędza siedząca biurko obok otrzymała 15%.

Pomocą we wdrażaniu kultury zwinnej starają się być tzw. frameworki. Poniżej krótko jest scharakteryzowałem i dokonałem ich porównania. Najpopularniejsze to SAFe 5.0, Scrum@Scale, Nexus, model Spotify, Large Scale Scrum, DAD 4.

SAFe

Aktualnie najpopularniejszy framework zwinny, ale z pretendentem depczącym mu po piętach (patrz DAD). Obejmuje poziom zespołu, wielu zespołów, portfela, wielu portfeli projektów, w końcu kultury całej organizacji. Zaczyna od definiowania strategii i uzasadnień biznesowych, a następnie przechodzi przez poziom portfela i dochodzi do pojedynczego zespołu.

Na poziomie zespołu SAFe czerpie ze Scrum, wymieniając typowe role, spotkania i cykl życia projektu. Zakłada się, że zespoły zwinne pracujące w swoich obszarach kompetencji mogą łączyć się, aby wspólnie stworzyć funkcjonującą całość, np. zwinny zespół z marketingu może zacieśniać współpracę ze zwinnym zespołem IT.

Z perspektywy zakresu prac na najwyższym poziomie mamy strategię, potem portfolio wspierane przez Kanban, a następnie release’y, które zbierają wykonane funkcjonalności z różnych zespołów. Ciekawie w SAFe ukazana jest perspektywa finansowania strategii. Zakłada się partycypacyjne podejmowanie decyzji o wydatkach, budżetowanie strumieni korzyści, a nie projektów oraz kategoryzowania inwestycji z perspektywy horyzontów zdarzeń.

Typowe techniki to business/lean canvas, epic, agile release trains, design thinking, scrum, kanban i wiele innych.

To króciutkie omówienie może sprawiać wrażenie zbagatelizowania, czym SAFe jest, więc jeszcze raz podkreślę, że jest to rozległy framework wspierający zarządzanie całą organizacją oraz kilkanaście ról i dziesiątki technik. Jednak w przeciwieństwie do DAD, SAFe stara się pełnić rolę metodyki, czyli konkretnych wytycznych działań, które powinny być wykonywane, aby być zgodnym z tym frameworkiem.

Disciplined Agile Delivery

Zbiór wiedzy nazywany DAD adresowany jest przede wszystkim do zespołów produkujących oprogramowanie. Jednak DAD stara się podejść szeroko do tej kwestii. Nie tylko opisuje moment produkowania funkcjonalności, ale również ich projektowanie, utrzymanie, wdrażanie. Stąd twórcy proponują aż 10 ról, 21 procesów zarządzania projektami oraz inspiruje się całym wachlarzem różnych innych metodyk, 6 cyklów życia projektów, technik. Takim podejście przypomina nieco PMBOK Guide, które nie jest metodyką, a encyklopedią. Z resztą na pierwszy rzut oka DAD wygląda, jak groźna konkurencja tegoż w świecie zwinnych projektów… Zaraz, przecież PMI pozbył się tej konkurencji, wykupując ją w sierpniu zeszłego roku :).

Podsumuję krótko, bo DAD jest naprawdę obszerny i wymaga osobnego artykułu. DAD to encyklopedia dobrych praktyk zwinnych projektów poukładana trochę na wzór PMBOK Guide. Z niej dopiero tworzy się firmową metodykę do różnych celów: zwinnego zarządzania całym przedsiębiorstwem, albo poprowadzenia dużego projektu.

Możemy też spodziewać się, albo równoległego body of knowledge wypuszczonego przez PMI (w formie dodatku do PMBOK o nazwie Agile Practice Guide), albo rozszerzenia PMBOK Guide o framework DAD. Tak, czy siak życzę powodzenia na przyszłych egzaminach PMP!

LESS

Robi wrażenie konkretnej metodyki zarządzania wieloma zespołami. Koncentruje się na produkcji oprogramowania w dużych projektach. Podstawową jednostką organizacyjną jest zespół Scrumowy, zakres jest dekomponowany na sprinty z użyciem backlogu itp. To, co pojawia się ponad Scrum, to:

  • Planowanie zakresu prac najpierw na poziomie wielu zespołów, a potem dopiero przydzielanie do konkretnego. Mamy też dwie role: product owner i area product owner.
  • Product backlog refinement odbywa się również dwupoziomowo, dla wszystkich zespołów razem, a potem każdy indywidualnie.
  • Analogiczna sytuacja dwupoziomowego działania ma miejsce przy retrospective.
  • W przypadku sprint review sugeruje się dokonywanie tego przez wszystkie zespoły razem ale z użyciem tzw. bazaru. Przypomina to Obeya, postery na konferencji naukowej, albo metodę wernisażową. Klient ma zaprezentowane oddawane funkcjonalności i sam kieruje się tam, gdzie są rzeczy, które go interesują.

Na to została nałożona filozofia myślenia w stylu Lean, w której z konkretów wymienia się: kaizen, 5why, WIP, VA/NVA, rodzaje strat, czas cyklu i wizualizację w zarządzaniu, karty A3. Rola kadry menadżerskiej została zredukowana do komunikacji z właścicielem produktu i zapewniania finansowania, a także usuwania przeszkód administracyjnych. Metodyka LESS adoptuje szereg technik inżynierii oprogramowania, jak TDD, RAD, automatyzację testów.

Scrum of Scrums

Podobną do LESS filozofię skalowania Scruma przyjmuje SOS, czyli Scrum of Scrums. Duży zespół dekomponuje się na mniejsze 5-10 osobowe, różnica polega na tym, że każdy taki mały zespół wybiera przedstawiciela, który komunikuje się i współpracuje na wyższym poziomie. Backlog ma dwa poziomy, codzienne spotkania są dwupoziomowe, product owner ma dwa poziomy.

Z nowych rzeczy sugeruje się utworzenie Enterprise Action Team, czyli zespołu składającego się z kluczowych menadżerów w organizacji, z Chief Product Ownerem w składzie. Ta formuła może okazać się znajoma dla członków zarządów, którzy dotychczas zasiadali w komitetach sterujących projektów.

Scrum at Scale

Kolejny framework i kolejne dwupoziomowe klonowanie Scruma. Obie koncepcje, SoS i S@S używają nawet podobnych terminów: chief product owner, scrum of scrums, EAT. Z nowości jest tutaj nawet Chief Scrum of Scrums Master w skrócie SOSM oraz Executive Meta Scrum Team, taki grupowy product owner na poziomie całej firmy. Koncepcja S@S zakłada fraktalność organizacji, więc jak mamy Scrum of Scrums (SoS), to za chwilę możemy mieć SoSoS, czyli trzy poziomową skalowalność scruma. Z resztą załączam fraktalną strukturę organizacyjną z dokumentacji tej metodyki.

Model Spotify

To właściwie nie tyle jest model zwinnego prowadzenia prac (tu rozległy artykuł na ten temat), co ogólne wytyczne dotyczące kultury organizacyjnej i sposobu formowania zespołów. Same praktyki zwinne w modelu Spotify pozostawione są poszczególnym zespołom. Spotify podkreśla, że właśnie częścią zwinnej kultury jest pozostawienie swobody zespołom, co do sposobu organizacji pracy. A to oznacza, ograniczoną egzystencje standardów.

Techniki, które Spotify promuje to: daily standup, retrospective, fail board, wspólnoty praktyków zwane tu gildiami, małe, autonomiczne zespoły, rola właściciela produktu, dekompozycja strategii na mniejsze, bardziej operacyjne części, które są zarządzane przez owe zespoły.

Plusem Spotify jest to, że skupia się nie tylko na produkcji nowych funkcji i usług przez zespoły IT, ale stara się zapewnić bazę do strategicznego zarządzania firmą. Z mojej perspektywy słabością jest zaś to, że ze względu na niewielką ilość konkretnych reguł, ról, praktyk i technik, nie jest metodyką. To oznacza, że musi polegać na zapale, konsekwencji i osobowości zarządu korporacji. Gdy tego zabraknie, cała układanka może się szybko rozsypać.

Podsumowanie

Cechą wspólną wszystkich wymienionych frameworków jest:

  • Silne skupienie się na daniu ludziom autonomii, co jest zgodne z Agile Manifesto, na które się powołują.
  • Przyjęcie, że najmniejszą jednostką organizacyjną jest zespół zwinny, zwykle Scrumowy.
  • W związku z poprzednim punktem pojawienie się typowo scrumowych ról.
  • Conajmniej dwupoziomowa dekompozycja zakresu prac: poziom Scrum of Scrums i poziom podstawowy Scruma.
  • Użycie backlogu jako podstawowego narzędzie planowania zakresu.

W mojej osobistej opinii rywalizację wygrają najbardziej rozbudowane frameworki, które skutecznie przekonają zarządy dużych firm, czyli SAFe i DAD. Pozostałe mogą się rozwodnić w krajobrazie różnych mutacji Scruma. Bo, gdy przychodzi do uzwinnienia całej firmy, już nie da się działać lokalnie, trzeba przekonać prezesa.

Zapisz się na nasz newsletter

Zapisz się na nasz newsletter

Twój e-mail został zapisany