PMBOK 6 czy PMBOK 7 na egzamin PMP a może oba

PMBOK 6 czy PMBOK 7 na egzamin PMP a może oba

Od dwa lat PMI postawił kandydatów do PMP w niezręcznej sytuacji. Opublikowano PMBOK Guide 7 (tu możesz przeczytać jego recenzję), który został tak naprawdę napisany od nowa. Jednocześnie nie anulowano oficjalnie poprzedniej wersji PMBOK 6. Wersja 7 zmieniła się kompletnie, największą zmianą były usunięcie procesów projektowych i ITTO, czy samego nadzienia wersji 6.

Natomiast na egzaminie obowiązywała wiedza z obu książek. Intensywnie przeglądałem witrynę pmi.org, zapytywałem na grupach dyskusyjnych PMI i nigdzie nie mogłem dostać oficjalnej odpowiedzi. PMI na swojej stronie sprytnie informuje do dzisiaj, że obowiązuje PMBOK Guide ale bez podania wersji (sami zobaczcie). Natomiast przedstawiciele firm szkoleniowych mówili, że najlepiej uczyć się z obu. Mocno niekomfortowa sytuacja zważywszy, że wersja 6 ma ponad 600 stron, wersja 7 – ok. 400 stron, załącznik agile ponad 300 stron. Takim stosem książek można wykoleić tramwaj.

Jednak sytuacja zmieniła się na lepsze. W październiku wyszedł Proces Groups Practice Guide (tu można go pobrać), który ma zastąpić PMBOK 6. Zawiera on wszystkie procesy z PMBOK 6 z inputami, outputami i technikami, ale usunięto opisy technik oraz wstęp. Z tego powodu książka z 600 stron schudła do 390 stron. Ewidentnie skopiowano rysunki i spis treści z PMBOK 6, tylko pousuwano niektóre sekcje.

Na dowód załączam fragment opisu jednego z procesów z tej książki.

Na stronie na temat nowości w standardach PMI informuje co prawda, że kandydaci do CAPM nadal mogą uznać PMBOK 6 za użyteczny, ale jego koniec jest już bliski.

W pliku z FAQ dotyczącymi PMBOK 6 napisano: It is important to remember that the PMP® exam is not based on the PMBOK® Guide.

Pamiętajcie, że „na egzaminie PMP może znaleźć się dowolne pytanie z dziedziny zarządzania projektami, o ile można znaleźć do niego odniesienie w conajmniej dwóch książkach z tego obszaru”, czyli np. PMBOK 6 i 7 :D.

Także ten tego… powodzenia na egzaminie robaczki! 🙂

 

 

Trendy w zarządzaniu projektami

Trendy w zarządzaniu projektami

Spójrz proszę na poniższy wykres. Prezentuje trend wyszukiwań dwóch haseł w Google w USA. Zwróciłeś uwagę, jak czerwona linia opada i przecina się z rosnącą linią niebieską? Otóż czerwona linia to hasło „pmbok”, a niebieska to „agile waterfall”.

Wielokrotnie w artykułach na blogu odnosiłem się do analiz firmy Gartner o nazwie Hype Cycle. Jednak dziś po spędzeniu poranka na przeglądania tuzinów wykresów hype’u w różnych kategoriach nie znalazłem odpowiedzi, co będzie trendem w zarządzaniu projektami w najbliższym okresie.

Sięgnąłem więc do drugiego źródła – aplikacji Google Trends. Google Trends pokazuje częstotliwość wyszukiwań wybranych haseł. Choć nie wyświetla bezwzględnej wartości w danym okresie, to pozwala na porównanie różnych haseł do siebie oraz spojrzenie wiele lat wstecz, aby dostrzec trendy.

Uznałem, że dla potrzeb prognoz tego, co się będzie działo w biznesie dobrze jest wybrać duży, dojrzały rynek, który inspiruje często resztę planety, czyli USA.

Oczywiście hasło „agile waterfall” może być użyte w wielu różnych kontekstach. Na przykład dla poczytania o różnicach między tymi podejściami, znalezienie rozwiązania na projekty hybrydowe, dowiedzenia się w ogóle więcej na temat tego, co dzieje się w świecie project management. Podobnie „kanban” może być wyszukiwany w kontekście zarządzania projektami, jak i produkcją lub magazynem. To są dwa różne światy. Ale zaryzykuję stwierdzenie, że ogólna dynamika i wzajemne proporcje popularności tych terminów są symptomatyczne.

Dla porównania kolejny wykres pokazuje takie terminy, jak: „scrum” (niebieski), „kanban” (czerwony), „pmbok” (źółty), „prince2” (zielony). Nie użyłem słowa „waterfall”, bo ma ono jeszcze inne znaczenia, co bardzo zaburzyłoby wykres.

Jak widać w 2004 wszystkie te hasła za wyjątkiem „prince2”, były na tym samym poziomie popularności. Ale… „pmbok” od lat powoli tracił, a „kanban” i „scrum” zyskiwały. Teraz widać, dlaczego PMI tak mocno przebudował PMBOK Guide w kierunku zwinności.

Dla porównania przyjrzałem się jeszcze innym czterem terminom: „pmbok” jako punkt odniesienia (niebieski), „kaizen” (czerwony), „six sigma” (żółty), „scrum” (zielony). Jak widać niesłychanie niegdyś modna Six Sigma w USA, zalicza spadek, choć wyhamowujący. Zgaduję, że odnalazła swoją niszę i tam jest stosowana, ale jest to dużo mniejszy obszar niż niegdyś. Podobnie ma się sytuacja z Kaizenem.

Moja interpretacja

Sądzę, że metody zwinne z sukcesem zdobywają kolejne dziedziny gospodarki i teraz sięgnęły do obszarów, które były zarządzane w sposób tradycyjny. Albo pracownicy z tych obszarów chcą dowiedzieć się, o co chodzi z tym agilem, albo szukają sposobu na wdrożenie go. Jeżeli prawdą jest, że próbuje się go wdrażać w dziedzinach nie związanych z produkcją oprogramowania, to zobaczylibyśmy to na wykresie popularności słów w wyszukiwaniach.

I… ta dam. Niebieska linia to słowo „pmbok”, a czerwona to „hybrid project”.

Widzisz trend opadający tej pierwszej i wznoszący tej drugiej?

Moja teza jest taka, że aktualnie mnóstwo organizacji poszukuje formuły połączenia filozofii kaskadowej ze zwinną. Z jednej strony chcą zachować kontrolę nad kosztami, celami, efektywnością zespołów i całych firm, a z drugiej chciałyby dać zespołom operacyjnym więcej autonomii, bo zauważają, że poczucie sprawczości wzmacnia motywację wewnętrzną, zwiększa reaktywność na zmiany oraz podnosi poziom innowacyjności. Przy okazji organizacją chcą jeszcze załatwić sobie problem skalowania Scruma do dużych struktur.

Jest pewna koncepcja, która obiecuje skalowalność Scruma, poczucie kontroli na poziomie strategicznym oraz pozostawienie zwinności na dole. To Scaled Agile Framework (SAFE). W internecie można znaleźć mnóstwo artykułów o zaletach i być może jeszcze więcej o słabościach tej koncepcji. Jednego nie można jej jednak zabrać, jest coraz bardziej popularna. Kilka lat temu PMI próbował gonić SAFE, nabywając metodykę Disciplined Agile Delivery (DAD). Jednak zobaczcie na efekty.

Żółta linia to właśnie „discipllined agile delivery”, to ta której nie widać. Czerwona to dla porównania „pmbok”, zaś niebieska to „scaled agile framework”.

Widzisz, drogi czytelniku, jak przecięły się w 2016 roku i jaką dynamikę mają teraz?

Nie sądzę, aby SAFE załatwił problem hybrydowości zarządzania. Zbyt wiele jest problemów przy jego wdrażaniu. Jednak jestem bardzo przekonany, że projekty hybrydowe oraz powiązane z tym skalowanie zwinności, będą istotnym trendem w przyszłości. Pewnie pojawią się kolejne koncepcje, aż w końcu znajdziemy coś, co będzie dostatecznie dobre.

Dodam jeszcze mój osobisty wkład w hybrydyzację projektów. Idea połączenia zwinności z kaskadą chodziła za mną od dłuższego czasu. Szczególnie interesował mnie wymiar zakresu. Z jednej strony mamy WBS, czyli hierarchiczną strukturę prac. Jest wygodny, bo zachowuje logikę, pozwala przechodzić od ogółu do szczegółu, a dzięki temu jest skalowalny. Z drugiej strony mamy Product Backlog, którego zaletą jest łatwość zarządzania, przejrzystość oraz prezentacja istotności poszczególnych wymagań.

Jakiś czas temu wymyśliłem koncepcję połączenia tych dwóch technik i wyszło mi coś takiego. Pierwsze wrażenia są bardzo obiecujące, sam własne projekty trzymam w takiej tablicy. Możliwość budowania hierarchii ułatwia utrzymanie porządku na liście zadań, a możliwość automatycznej konwersji do tablicy Kanban pozwala na płynne przejście do zarządzania ich wykonanie. Nie spotkałem takie funkcjonalności w komercyjnych systemach i ciekaw jestem, czy Ty, drogi czytelniku, gdzieś już ją widziałeś. Jeżeli tak, to koniecznie daj mi znać.

 

 

 

Niepewność, czy pracochłonność

Niepewność, czy pracochłonność

Mam wrażenie, że jedną z najważniejszych strategicznych kompetencji jest umiejętność rozróżnienia tego, co jest tylko pracochłonne od tego, co totalnie niepewne. Korzyść ucieczka ze ślepej uliczki zanim zmarnujemy w niej lata naszego życia i furmanki pieniędzy.

Od kilku miesięcy siedzę w wolnym czasie nad serwisem, który wspiera tworzenie map procesów (https://dotch.art). Początkowo nie miałem pojęcia jak rysować wektorowo na stronie HTML, jak animować obiekty, jak wyliczać kąty krzywych Beziera, czy wreszcie jak stworzyć plik XML, który będzie rozumiany przez Draw.io, czy Cawemo. Ale… to wszystko nie miało znaczenia. Wystarczy skończona liczba godzin, dostęp do stackoverflow, czy innej dokumentacji i wcześniej, czy później te wyzwania technologiczne staną się banalne. To nie było niepewne tylko pracochłonne.

Najważniejszym problemem i główną hipotezą było i nadal jest to, czy serwis Dot Chart dostarcza jakąkolwiek wartość użytkownikom. Czy ludzie będą do niego wracać, polecać znajomym i wreszcie płacić za korzystanie? To jest właśnie niepewność. Wątpliwość jest nie bez podstaw, bowiem jeden z moich znajomych o olbrzymim doświadczeniu biznesowym wprost zadał pytanie: „Marcin, a po co ty to robisz? Nie lepiej zająć się czymś sensownym?”.

Stwórzmy w głowie tabelę o dwóch wymiarach: niepewność i pracochłonność. Z takiej tabeli 2×2 możemy uzyskać cztery podstawowe sytuacje. Oczywiście jest to olbrzymie uproszczenie, które wprowadzam na potrzeby tego wpisu. Projekt, zadanie, inwestycja jest:

  1. Tani i pewny
  2. Tani i niepewny
  3. Pracochłonny i pewny
  4. Pracochłonny i niepewny

W pierwszym przypadku po prostu warto coś zrobić. Przykładowo bank posiadający tysiące klientów może mieć pewność, że 2% klientów skusi się na nową usługę, co daje bardzo przewidywalny wynik. Albo producent gry mobilnej z 100 tysiącami aktywnych graczy wie, że dodanie nowej mikrotransakcji sprowokuje do konwersji 0.5% graczy. W takim projekcie po prostu trzeba coś policzyć i zrobić.

W drugim przypadku na horyzoncie jawi się okazja. To, czy zaklasyfikujemy ją jako niepewną lub pewną zależy od subiektywnego odbioru sytuacji. Jednak mam wrażenie, że biznesmeni mają tendencję do przeceniania swojej wiedzy i przesadnego kwalifikowania rzeczy wątpliwych jako pewne. W takiej sytuacji niska pracochłonność może uzasadniać podjęcie ryzyka i po prostu zrobienie projektu. Trochę tak jest z pewnym systemem społecznościowym, przy którym dzisiaj pomagam. Postawienie go zajmuje mojemu koledze godzinę, a nie wiemy, czy uda się przekierować darmowy ruch użytkowników. Jeżeli się uda, to jesteśmy bogaci, a jak nie to zmarnowaliśmy parę godzin. Co w takiej sytuacji? Po prostu to zrobić i zobaczyć, jak wyjdzie. Minusem jest to, że według analiz trzeba poczekać 3-6 miesięcy na zebranie danych. A ponieważ koszt jest tak niski, to można dodatkowo jeszcze odpalić 10 takich systemów na różne tematy, aby zdywersyfikować wyniki.

Albo inny przykład. Jak ustalić, czy usługi weterynaryjne online mogą być rentowne? Dwa dni na postawienie strony i linka do płatności, tydzień na kampanię, współpraca z weterynarzem i tadam! Mamy realne dane o elastyczności cenowej, koszyku, konwersji itd.

Trzecia z tych sytuacji to obszar tradycyjnych projektów kaskadowych lub zwinnych. Mamy coś dużego do zrobienia, znamy rezultat oraz dysponujemy w zespole kimś, kto już to robił, to po prostu wdrażamy, konstruujemy, produkujemy. Jakbym miał wdrożyć system CRM w firmie, która ma kilkadziesiąt tysięcy transakcji miesięcznie, to pewnie byłbym w takiej sytuacji.

Wreszcie czwarty obszar jest najgorszy. Duża niepewność i spory koszt, aby zweryfikować ją, aby zdobyć wiedzę. Tutaj najbardziej moim zdaniem przydać się może podejście eksploracyjne, o którym już wielokrotnie pisałem i któremu poświęcam wolny czas w tym roku. Problem trzeba pociąć na małe części, zebrać zaangażowany zespół unikalnych fachowców, zaakceptować brak kontroli nad wydatkami, by krok za kroczkiem przekonywać się, czy inwestycja miała sens. W ten sposób rozwijane są przez lata startupy, nowe urządzenia, czy opanowywane nowe technologie. Tu ważna jest wiara oraz dzielenie tej niepewnej drogi na małe odcinki i ich ciągła racjonalizacja.

Problem z niepewnością komplikuje jeszcze jedna rzecz. Brakuje mi dobrego terminu, więc nazwę to niepewnością ukrytą pod płaszczem przekonania o swoim geniuszu. Niepewność zaskakuje. To wynika z jej definicji. Jednak to, że może zaskakiwać jest regularnie ignorowane przez biznesmenów. Często widzę arkusze kalkulacyjne wyliczające sprzedaż nowej usługi na miliony, a po wdrożeniu okazuje się, że nikt tego nie chce.

Często na starcie nie wiemy, że coś jest niepewne. Ukryte są konflikty techniczne, których nie da się obejść, ukryte jest niska jakość rozwiązania, której nie ma sposoby podnieść, ukryty jest brak popytu klientów na usługę, ukryte są wysokie koszty pozyskania klienta itd. Niepewność ukryta ujawni się w trakcie, bo ona tam siedzi, ale wprowadza nas na starcie w błąd. Zamiast sądzić, że mamy do czynienia z projektem ryzykownym, to wydaje się nam, że może i jest pracochłonny, ale przewidywalny. Da się go zatem zbudować krok po kroczku i na pewno osiągniemy sukces.  A jak jeszcze dopiszemy do tego projektu termin końca i całkowity koszt, to wszystko stanie się bezpieczne. Co może pójść nie tak? Zupełnie jak w przypadku nowego bloku elektrowni w Ostrołęce. Wszystko!

 

montecarlo

Szacowanie trendów

https://docs.google.com/spreadsheets/d/19WOda89SDjHzeXIMZjRljgMzslCokRKqaBTg-e71p0U/edit?usp=sharing

Porównanie zespołów sprzedażowych

https://docs.google.com/spreadsheets/d/1Vtn-cWqzr8_cMOWNHqc_ClZpoNTpSrIDZEbM6W8jz_4/edit#gid=0

Liczenie korelacji

https://docs.google.com/spreadsheets/d/1sIf4pfFKEv7kqWVfQv_66u2t0-9i63wsPWw0V7c8LdU/edit#gid=0

Czyszczenie danych

https://docs.google.com/spreadsheets/d/154unnW_Y8OX-2vkzb63p7_aiLwp3A8mq3jGk9fzAxo4/edit?usp=sharing

Model dla reklamacji

https://docs.google.com/spreadsheets/d/1ksFUeJnjwmHt4XTLlf1IX8Hu4i0BF6qp0MgtPByDwoo/edit?usp=sharing

Funkcje Dot Chart

Funkcje Dot Chart

System Dot Chart oferuje wiele funkcji, których cel jest jeden. Przyśpieszyć rysowanie mapy procesu.

Potrzebujesz szybko narysować przepływ pracy? Stwórz diagram dot chart. Możesz:

  • Dodawać role w procesie
  • Dodawać zadania w procesie
  • Wstawiać „kółka”, które pokażą, kto zajmuje się, czym
  • Połączyć „kółka” strzałkami, aby uwidocznić logikę
  • Dodawać komentarze do poszczególnych „kółek”
  • Możesz to wszystko edytować, zmieniać i przestawiać
  • Możesz tworzyć mapę w grupie w formule zdalnej. System na bieżąco będzie aktualizował stan mapy.
  • Jeżeli mapa ma służyć do optymalizacji procesu, możemy zapisać problemy, pomysły na usprawnienia i w miarę ich realizacji zmieniać ich status.

Możesz automatycznie skonwertować dot chart na mapę w formacie swimlane. Wystarczy nacisnąć jeden przycisk. Mapa wyświetla start, koniec, zdania, tory pływackie, bramki. Możesz następnie wyeksportować mapę do pliku graficznego, PDF, XPDL.

Ponowna edycja dot chart powoduje automatyczną aktualizację swimlane.

Kolejna możliwość to wygenerowanie tabeli RACI. Możemy przypisać „kółka” na dot chart do poszczególnych zakresów odpowiedzialności. Zostanie to pokazane za pomocą kolorów. Następnie wystarczy nacisnąć przycisk, aby automatycznie wygenerować tabelę RACI.

Następnie możemy zapisać ją w postaci obrazka lub PDF.

Możemy wreszcie zacząć rysowanie mapy od stworzenia tablicy z rolami i ich zadaniami w procesie, a dopiero później zrobienie. Można sobie wyobrazić, że najpierw uczestnicy procesu samodzielnie wypełniają tabelę ról, a potem analityk wspólnie z nimi tworzy dot chart, który na koniec zapisuje w postaci BPMN.

Wejdź na https://dotch.art, aby zacząć korzystać z systemu.

Dotch.art – narzędzie do szybkiego mapowania procesów

Dotch.art – narzędzie do szybkiego mapowania procesów

Przedstawiam nietypowe narzędzie do rysowania procesów: Dotchart. Nietypowe, bo jest najważniejszym celem i wyróżnikiem jest szybkość i łatwość.

Założenie jest takie, że proces rysujemy w schemacie diagramu kropkowego, a potem automatycznie konwertujemy go na inne formy, jak na przykład tabela RACI lub mapa BPMN.

Diagram kropkowy (dotchart) był już kilka lat temu opisywany na naszym blogu. Tworzy się go w ten sposób, że w tabeli spisuje się role w procesie w wierszach i zadania w kolumnach. Na przecięciu zaś wstawia się kropki wskazujące, kto robi co. Następnie kropki łączy się strzałkami, aby pokazać logikę procesu.

Ta technika czerpie trochę z RACI, a trochę z flowchart. Przewagą nad RACI jest pokazanie przepływu i logiki procesu. Natomiast przewagą na typowym flowchart, np. w stylu swimlane, jest prostota i szybkość. W praktyce taki diagram rysowałem często, jednocześnie rozmawiając z osobami zaangażowanymi w proces.

System jest też ciekawy z tego względu, że pozwala na równoległą edycję mapy kropkowej przez wielu ludzi naraz. Wystarczy przesłać linka kolegom lub klientowi, aby zacząć wspólną edycję. W czasie rzeczywistym mapa aktualizowana jest na podstawie zmian wprowadzanych przez jej użytkowników.

Na obrazkach obok macie pokazane jak wyglądają RACI i BPMN automatycznie utworzone na podstawie Dotchart.

System Dotchart pozwala na eksport map do PDF lub do obrazka.

System pozwala również na wstawianie komentarzy do zadań, w których można zapisać na przykład zidentyfikowane problemy w procesie, albo pomysły na usprawnienia.

W trakcie tworzenia jest funkcjonalność pozwalająca na import i eksport pliku z mapą do uniwersalnego formatu XPDL, który jest obsługiwany przez najbardziej znane systemu zarządzania procesami, jak na przykład Adonis, Bizagi, Camunda.

Wówczas możliwe będzie szybkie zrobienie szkicu procesu w Dotchart, a później jego dalsza obróbka i włączenie do bazy procesów w narzędziach korporacyjnych.

Dodatkowo, aby jeszcze bardziej uprościć tworzenie mapy procesu, zaoferowano funkcję tworzenia i edycji tablicy procesu. Tablica procesu przypomina tablicę kanban, tylko, że zawiera role w kolumnach, a w nich zadania w procesie realizowane przez daną rolę. Za jej pomocą można szybko spisać, co wiemy o procesie, a potem automatycznie wygenerować wstępny wykres Dotchart, który dalej można obrabiać, na przykład, aby dodać strzałki, albo typy odpowiedzialności zgodnie z RACI.

Jeżeli byście chcieli skorzystać z systemu Dotchart, to można bez żadnych ograniczeń wejść na ten adres: https://dotch.art.

Zapisz się na nasz newsletter

Zapisz się na nasz newsletter

Twój e-mail został zapisany