Zdecydowanie rzadziej myślimy o najlepszych praktykach zarządzania ryzykiem w kontekście jednostek sektora finansów publicznych. Moje pierwsze skojarzenie z zarządzaniem ryzykiem w tym kontekście to standardy kontroli zarządczej dla jednostek sektora finansów publicznych oraz wytyczne Ministra Finansów, wydane na podstawie art. 69 ust. 4 ustawy z dnia 27 sierpnia 2009 r. o finansach publicznych.

Małe wprowadzenie w temat

Celem standardów kontroli zarządczej jest pomoc we wdrożeniu w sektorze finansów publicznych spójnego i jednolitego modelu kontroli zarządczej w zgodzie ze standardami międzynarodowymi. Obejmują one pięć podstawowych obszarów takich jak:

• środowisko wewnętrzne,
• cele i zarządzanie ryzykiem, 
• mechanizmy kontroli,
• informacja i komunikacja,
• monitorowanie i ocena.

Każdy z tych obszarów jest opisany na dużym poziomie ogólności. Standardy mówią nam, że przynajmniej raz w roku powinniśmy ryzyka zidentyfikować, zanalizować i zaplanować dla nich najbardziej adekwatne reakcje na ryzyko.

I tu pojawia się pytanie jak i kiedy zrobić to w praktyce?

Jak dostosować proces zarządzania ryzykiem do codziennej pracy?

1. Identyfikacja ryzyka

Dobrym momentem na identyfikację ryzyka jest czas kiedy tworzymy plany roczne, podejmujemy się nowych inwestycji czy rozpoczynamy realizację programów i projektów. Punktem startowym w identyfikacji ryzyka powinno być dobre zrozumienie celów i zadań, które stoją przed naszą jednostką ponieważ to w odniesieniu do nich będziemy identyfikować ryzyka.

Za identyfikację ryzyka odpowiedzialny jest kierownik danej jednostki, obszaru czy projektu.  Jednak nie powinien podejmować się tego zadania samodzielnie. Warto zaprosić do współpracy swoich współpracowników, kontrahentów oraz przedstawicieli szerzej rozumianej społeczności ponieważ większość technik identyfikacji ryzyka jest rekomendowanych do pracy warsztatowej.

Identyfikację ryzyka warto rozpocząć od analizy czynników zewnętrznych i wewnętrznych, które mogą wpłynąć na naszą organizację. Następnie skorzystajmy z wcześniejszych doświadczeń. Przejrzyjmy rejestry ryzyka z ostatniego roku (w przypadku działalności operacyjnej) czy z poprzednich podobnych projektów (w przypadku realizacji projektu) i spróbujmy odpowiedzieć sobie na pytanie czy zidentyfikowane wcześniej ryzyka będą nadal aktualne w kolejnym roku/projekcie. Jeśli tak to poddamy je dalszej analizie. Po zebraniu wcześniejszych doświadczeń warto zanalizować dokumentację naszego przedsięwzięcia (dokumentację przetargową – jeśli nas dotyczy), przyjrzeć się przyjętym założeniom oraz ograniczeniom – wynikającym zarówno z zewnętrznych regulacji, jak i naszych wewnętrznych standardów, procedur, regulaminów.  

Analiza dokumentacji to też weryfikacja naszych kontrahentów w ogólnodostępnych rejestrach (np. CEiDG, KRS czy Biała lista podatników VAT). Przeprowadźmy też krótki wywiad z osobami zarządzającymi naszą jednostką – ich, często wieloletnie, doświadczenie może być bardzo pomocne w identyfikacji potencjalnych ryzyk. Zorganizujmy również warsztat identyfikacji ryzyka z wykorzystaniem np. burzy mózgów i technik kategoryzacji ryzyka – najlepiej poprowadzony przez facylitatora warsztatów.

Więcej technik identyfikacji ryzyka możesz poznać na naszym szkoleniu z zakresu metodyki M_o_R.

2. Analiza ryzyka

Kolejny krok rekomendowany przez standardy kontroli zarządczej to analiza ryzyka, która pozwoli nam spriorytetyzować zidentyfikowane wcześniej ryzyka. W trakcie analizy należy określić akceptowany w naszej jednostce poziom ryzyka oraz ocenić prawdopodobieństwo wystąpienia ryzyka i jego potencjalne skutki. Większość metodyk i modeli zarządzania ryzykiem rekomenduje użycie 5-stopniowej skali do oceny prawdopodobieństwa wystąpienia ryzyka (np. jego częstotliwości czy krotności) oraz do oceny wpływu ryzyka na cele i zadania naszej jednostki. Jednak dla nas wiążące są skale, które już obowiązują w naszej organizacji. Ocenione ryzyka możemy przedstawić w formie graficznej na mapie ryzyka.

3. Reakcje na ryzyka

Dla ocenionych i spriorytetyzowanych ryzyk należy przygotować konkretne reakcje na ryzyko, które w idealnej sytuacji pozwolą nam na unikniecie lub zminimalizowanie zagrożeń oraz zmaksymalizowanie szans. Planując reakcję na ryzyko należy uwzględnić poziom akceptowalnego ryzyka w naszej jednostce, priorytet ryzyka oraz jej efektywność kosztową (uwzględniając zarówno koszty finansowe wdrożenia danej reakcji, jak również koszty pozafinansowe np. koszty społeczne). 

Jeżeli priorytet ryzyka jest niski to najczęściej będziemy tolerować ryzyko (w sposób aktywny – wpiszemy je do naszego rejestru ryzyka i regularnie będziemy je monitorować). Dla ryzyk o wyższych priorytetach możemy zastosować reakcje typu przeniesienie, wycofanie się czy działanie.

• Reakcja typu przeniesienie ryzyka będzie polegało na przeniesieniu ryzyka na stronę trzecią, np. na ubezpieczyciela czy naszego wykonawcę/podwykonawcę (ubezpieczenie składników majątku naszej jednostki jest przykładem tego typu reakcji).
• Jeśli ryzyko jest wysokie możemy zastosować reakcje typu wycofanie się – reakcja ta będzie polegała na rezygnacji z działań czy projektów, które wystawiają naszą organizację na ryzyka.
• Najpopularniejszą jednak reakcją na ryzyko jest redukowanie zagrożenia/przybliżenie okazji (nazywane również działaniem) – czyli sytuacja w której będziemy podejmować działania mające na celu zmniejszenie lub zwiększenie prawdopodobieństwa wystąpienia ryzyka lub jego wpływu ( przykłady takich reakcji to: przeprowadzenie kampanii medialnej promującej działalność naszej jednostki by zwiększyć zainteresowanie naszą ofertą, np. badaniami profilaktycznymi dla seniorów lub skanowanie dokumentów, aby zredukować wpływ ryzyka związanego z zaginięciem dokumentów).

Zarządzanie ryzykiem

W ramach zarządzania ryzykiem w Waszych jednostkach rekomenduję Wam m.in.

• dywersyfikację ryzyka (np. poprzez zróżnicowanie swoich dostawców i wykonawców zamiast korzystania z usług jednego monopolisty),
• ochronę swoich zasobów ludzkich i fizycznych (np. poprzez zastosowanie dobrej jakości odzieży ochronnej,
• regularne wykorzystywanie kopii zapasowych czy ograniczenie dostępu i monitorowanie naszej infrastruktury),
• szkolenie pracowników (np. w zakresie obowiązujących standardów czy pożądanych zachowań).

Kilka praktycznych przykładów i wskazówek dot. zarządzania ryzykiem znajdziecie w Wytycznych do planowania i zarządzania ryzykiem: (https://www.gov.pl/attachment/9c82233b-fd33-4879-a301-0f744857c002) opublikowanych w serwisie Rzeczypospolitej Polskiej.

Przepis na sukces?

Skuteczność wdrożenia zarządzania ryzykiem do naszych jednostek nie wymaga stosowania skomplikowanych narzędzi i dedykowanego oprogramowania. Wystarczy zestaw dość prostych technik i metod stosowanych regularnie, aby zarządzanie ryzykiem dało Waszej organizacji realną korzyść i przestało być traktowane przez naszych pracowników jedynie jako przykry obowiązek wynikający z zewnętrznych regulacji. Po więcej informacji zapraszam Cię na szkolenie z metodyki M_o_R lub dedykowane warsztaty, które przygotujemy dla Twojej jednostki.

Monika Olejniczak
Akredytowana Trenerka metodyki M_o_R, przez 16 lat pełniła funkcję Pełnomocnika Wójta w jednostce samorządu terytorialnego.

Artykuł Złapmy byka za rogi! Zarządzanie ryzykiem w praktyce pochodzi z serwisu Inprogress Akredytowane Szkolenia.

„Nie zdefiniowano jasno celu biznesowego…”
„Biznes nie miał czasu na pracę z analitykami…”
„Klienci uznali, że wszystkie wymagania są krytyczne…”
„Klienci zatwierdzili wymagania, a później ciągle je zmieniali…”
„Żądanie zmiany zostało zgubione i nikt nie wie jaki jest jego status…”
„Klienci poprosili o pewną funkcjonalność, a później nikt z niej nie korzystał…”

Brzmi znajomo? No ba! Tak wygląda codzienność w zespołach realizujących projekty IT. Analitycy Biznesowi, Product Ownerzy, zespoły deweloperskie czy Project Managerowie każdego dnia borykają się z problemami, które utrudniają im skuteczne realizowanie celów projektowych. Zanim poszukamy rozwiązań, na początek garść statystyk.

Większość projektów IT kończy się porażką…

Według badań przeprowadzonych przez Standish Group, aż 83,8% projektów kończy się częściową lub całkowitą porażką. Częściowa porażka to przekroczenie założonego budżetu lub czasu trwania projektu, zaś całkowita porażka to zawieszenie lub anulowanie projektu. Oznacza to, że tylko 16,2% projektów kończy się sukcesem – rozumianym jako projekt zrealizowany w założonym czasie, budżecie i z zaplanowanym zakresem funkcjonalności oprogramowania.

Przyczyny porażek w projektach IT

Jednym z głównych powodów niepowodzeń jest brak lub błędnie przeprowadzony proces analizy wymagań. Typowym symptomem niewłaściwie przeprowadzonej inżynierii wymagań są brakujące, niejasne lub nieprawidłowe wymagania. Jest to spowodowane w szczególności przez:

• pospieszne budowanie systemu,

• problemy komunikacyjne między zaangażowanymi stronami,

• założenie, że wymagania są oczywiste,

• niewystarczająca wiedza i umiejętności w zakresie inżynierii wymagań.

Koszty usuwania błędów – związanych z brakiem lub niejasnymi wymaganiami – na późniejszych etapach projektu mogą być bardzo wysokie. Należy zatem zadbać o prawidłowe podejście do inżynierii wymagań już od samego początku projektu.

Inżynieria wymagań w projekcie IT

Prawidłowo przeprowadzona Inżynieria wymagań wnosi wartość w proces wytwarzania i rozwoju systemu przez:

• zmniejszenie ryzyka wytworzenia niewłaściwego systemu,

• umożliwienie lepszego zrozumienia problemu,

• wsparcie oszacowania wysiłku i kosztu wytwarzania,

• zapewnienie warunków wstępnych do testowania systemu.

Wiemy już, że w ramach projektów IT warto solidnie i rzetelnie przeprowadzić proces inżynierii wymagań. Zobaczmy jakie główne zadania w procesie inżynierii wymagań definiuje IREB (z ang. International Requirements Engineering Board):

„Głównymi zadaniami inżynierii wymagań są pozyskiwanie, dokumentowanie, walidacja oraz zarządzanie wymaganiami. Aby poprawnie wykonać czynności związane z inżynierią wymagań, z szerokiego zakresu możliwości należy dobrać odpowiedni proces inżynierii wymagań.”

Zgodnie z powyższą definicją, inżynieria wymagań obejmuje szereg czynności, które należy wykonać w ramach całego cyklu życia projektu IT. Kiedy wiemy już „co i jak” należy zrobić, to pozostaje odpowiedź na pytanie „kto” będzie odpowiedzialny za realizację zadań inżynierii wymagań.

Jaką rolę pełni inżynier wymagań

Inżynier wymagań zazwyczaj nie jest nazwą stanowiska, ale rolą realizowaną przez osoby, które:

• w ramach swoich obowiązków pozyskują, dokumentują, walidują i/lub zarządzają wymaganiami,

• posiadają dogłębną wiedzę na temat inżynierii wymagań,

• mogą wypełniać lukę pomiędzy problemem a potencjalnymi rozwiązaniami.

W praktyce jest tak, że powyższe zadania realizują m.in. analitycy biznesowi, specjaliści ds. aplikacji, właściciele produktów, inżynierowie systemów, a nawet programiści.

Certyfikat IREB CPRE Foundation – dlaczego warto

Jeżeli pełnisz w swojej firmie jedną z wymienionych wyżej ról lub planujesz karierę w analizie biznesowej czy systemowej, to szkolenie IREB CPRE Foundation umożliwi Ci zdobycie wiedzy o najlepszych praktykach w dziedzinie inżynierii wymagań.

Dlaczego jeszcze warto wziąć udział w szkoleniu IREB CPRE?

• nauczysz się identyfikować interesariuszy i rozmawiać z klientem,
• zrozumiesz zadania analityka biznesowego,
• nauczysz się ograniczać ryzyka w projekcie przez inżynierię wymagań,
• poznasz międzynarodowy standard realizacji inżynierii wymagań,
• pozyskasz wiedzę umożliwiającą pracę na różnych etapach projektu – tworzenie dokumentacji, negocjowanie wymagań oraz zarządzanie zmianą wymagań,
• przygotujesz się do egzaminu do certyfikacji na poziomie CPRE Foundation Level,
• po zdanym egzaminie, otrzymasz międzynarodowy, uznawany na całym świecie certyfikat IREB CPRE Foundation – mający dożywotnią wartość.

Opinie uczestników szkolenia:

„Szkolenie z inżynierii wymagań IREB CPRE umożliwiło mi uporządkowanie i ugruntowanie wiedzy o wymaganiach, którą zdobyłem przez lata pracy w IT. Z całego programu szkolenia najbardziej zapamiętałem rozdział dotyczący źródeł wymagań i technik ich pozyskiwania. Do tej pory robiłem to intuicyjnie” Rafał, Product Owner (12 lat w branży IT)

„Dopiero rozpoczynam swoją karierę w analizie biznesowej i postanowiłam zdobyć certyfikat, który pomoże mi zdobyć nową wiedzę i awans na Mid BA. Nie sądziłam, że inżynieria wymagań dotyczy tak wielu obszarów w projekcie” Monika, Junior BA (1 rok w branży IT)

Źródło: artykuł napisany w oparciu o oficjalny „Sylabus IREB wersja 3.1.0, 1 listopada 2022 r. @IREB e.V.”

Grzegorz Kropacz, trener IREB

Artykuł Inżynieria wymagań IREB – czy to dla Ciebie? pochodzi z serwisu Inprogress Akredytowane Szkolenia.

Nowości!

Zgodnie z Wikipedią cyfra siedem symbolizuje całość, dopełnienie i doskonałość. Czy taki jest PRINCE2 w nowej, właśnie siódmej odsłonie? Cóż, dążenie do doskonałości to proces ciągły, jednak z pewnością możemy tu mówić o dopełnieniu.

Wersja siódma ma to, czego brak doskwierał w wersjach poprzednich – skupienie na ludziach i ich motywacjach, aspekty przywódcze i wreszcie – cały ogrom praktycznych przykładów, które pozwalają na bieżąco odnosić teorię PRINCE2 do rzeczywistości projektowej. Ogromna zmiana, zdecydowanie na plus!

Z ludźmi w centrum

PRINCE2 v 7 to naprawdę duże zmiany – schemat pryncypia>tematy>procesy odchodzi w zapomnienie, ustępując miejsca nowemu wzorcowi, gdzie w centrum wszystkich aktywności projektowych stawiani są LUDZIE.

Perspektywa osób tworzących projekt szczególnie zmieniła sposób przedstawienia tematów (obecnie: praktyk) w PRINCE2 – w nowej wersji znajdziecie tu np. omówienie takich kwestii jak to, że kierownik projektu nie zawsze ma wpływ na to, z kim pracuje, nie zawsze może na te osoby oddziaływać, nie zawsze wystarcza mu autorytetu i sprawczości by pewne zadania egzekwować. 

Zmiany w pigułce

Zmian jest jednak znacznie więcej, przy czym wyraźnie trzeba zaznaczyć, że wersja siódma nie jest w żadnym razie “zupełnie nowym PRINCem”. Procesy, pryncypia i tematy, podobnie zresztą jak produkty zarządcze pozostają niezmienione – jednak dzięki dokładniejszemu opisaniu pewnych zagadnień, zwróceniu uwagi na aspekty, które wcześniej były ledwie wspomniane, osadzeniu tego w konkretnych przykładach i zapisaniu prostszym językiem, stały się łatwiejsze do zrozumienia i uporządkowania. PRINCE2 w wersji 7 to zmiany małe i duże, metodyczne i językowe, ważne i takie, które zauważą wyłącznie prawdziwi koneserzy 😊 Po dokładnej lekturze angielskiej wersji podręcznika przygotowaliśmy dla Was spis najważniejszych z nich: 

• nowy PRINCE2 to naprawdę dużo przykładów – całą książka bazuje na czterech scenariuszach praktycznych, które są rozwijane przez wszystkie rozdziały, pomagając praktycznie zilustrować omawiane techniki i procesy, 
• pojawiła się nowa zmienna projektowa – w wersji angielskiej jest to “sustinability”, czyli zrównoważony rozwój, 
• mamy też zupełnie nowy, przełomowy rozdział 3 zatytułowany “People”. Tu dowiemy się jak zarządzać zespołem, tworzyć efektywne środowisko pracy, jaka w tych wszystkich aspektach jest rola kierownika projektu, 
• drobne, ale znaczące zmiany można zauważyć także w nazwach pryncypiów i praktyk – przykładowo zamiast “zdefiniowanych ról i obowiązków” mamy “zdefiniowanie ról, odpowiedzialności i relacji”, natomiast dotychczasowe “changes” to teraz “issues”, 
• książka przedstawia ogromną ilość technik wspierających kierownika projektu – w kontekście samego tylko uzasadnienia biznesowego omawia się metody scenariuszowe, multi-case model, whole life costs, net benefits, ROI, payback, NPV, internal rate of return, options analisys oraz sensitivity analiss*, 
• opis roli kierownika projektu został znacząco rozbudowany, szczególnie o aspekty związane z dbaniem o well-being zespołów, 
• znacznie wzrosła rola wsparcia projektu – zdecydowanie nie są to już osoby wyłącznie od pracy administracyjnej, 
• z zespołu zarządzania projektem wyłączono natomiast obsługę zmian – przy czym rola ta wciąż jest obecna na poziomie organizacji, 
• mamy nowe produkty zarządcze – między innymi bardzo ciekawy Project Log czy digital and data management approach. Jednocześnie, ilość produktów zarządczych zmalała – z dwudziestu sześciu do piętnastu, 
• wszystkie tematy są wzbogacone o opis użycia korespondujących z nimi technik zwinnych – np. w temacie jakości pojawia się definition of done, definition of ready, story points, pojęcie wymagań funkcjonalnych, niefunkcjonalnych, 
• całkowicie zmieniła się też kompozycja podręcznika – każdy temat jest omówiony w sposób wyczerpujący, nie trzeba już wertować całej książki w poszukiwaniu treści dotyczących tych samych zagadnień, zostało to przedstawione w sposób bardzo spójny i przemyślany, 
• diagramy są przedstawione w czytelniejszy sposób, co powinno ułatwić pracę z książką,  
• wszystkie aspekty projektu omówione są w trzech kontekstach – dostarczania linearnego, iteracyjnego i hybrydowego, 
• dodatek “A” został wyposażony w nowy aspekt, tzw. “usage”, pokazujący, kiedy i po co warto skorzystać z konkretnych produktów zarządczych, 
• skorygowano także błąd merytoryczny, który w edycji 5 i 6 był obecny w przykładzie planowania produktowego. 

Dużo? To i tak tylko część zmian – o pozostałych z nich, chętnie opowiemy na szkoleniu PRINCE2 Foundation! 

*Ze względu na tymczasowy brak polskiego tłumaczenia, pewne wyrażenia z anglojęzycznego podręcznika zostały tu umieszczone w wersji oryginalnej. 

Paulina Polatowska
Trenerka PRINCE2

Artykuł Nowa, 7. wersja metodyki PRINCE2®. Co się zmienia? pochodzi z serwisu Inprogress Akredytowane Szkolenia.

„PRINCE2 to jedna z najpopularniejszych na świecie metodyk…”

Masz wrażenie, że słyszałeś już to stwierdzenie kilkaset razy? Pewnie się zastanawiasz, czy to faktycznie prawda, czy może tylko slogan reklamowy – tym bardziej, że nijak nie można sprawdzić, ile osób faktycznie legitymuje się tym certyfikatem. Wydaje się jednak, że dużo – przecież w większości ogłoszeń o pracę zauważasz adnotację, że kandydat powinien być posiadaczem certyfikacji PRINCE2, na LinkedIn co kilka dni ktoś informuje o zdaniu właśnie tego egzaminu. Z poniższego artykułu dowiesz się, jak jest naprawdę – czy PRINCE2 to tylko certyfikacja widmo, służąca przede wszystkim do poprawienia wyglądu Twojego CV, czy może jednak, zupełnie niebezpodstawnie “jedna z najpopularniejszych metodyk”, której znajomość pozwoli Ci lepiej zarządzać projektami. 

“Co 4 minuty ktoś na świecie zdaje egzamin PRINCE2 Foundation, gdyby certyfikaty ułożyć koło siebie na ziemi, to powstałaby linia długości prawie 300 km, ponad milion osób ma już certyfikat”…

To wszystko jest prawdą – a raczej było, w 2012 roku. Rok później, metodyka PRINCE2 stała się własnością prywatnej firmy Axelos (obecnie PeopleCert) i podobne dane przestały być udostępniane – dlatego też dziś nie wiadomo, ile dokładnie osób posiada certyfikację.
Czy więc stwierdzenie o “jednej z najpopularniejszych metodyk” nadal jest prawdziwe? Nie wiadomo – nie ma na to sztywnych, statystycznych danych, podobnie zresztą, jak nie ma jednoznacznych danych dotyczących popularności innych metodyk.

Zalety metodyki PRINCE2

Bez wątpienia jednak PRINCE2 jest metodą stosowaną powszechnie i sprawdza się w wielu, naprawdę różnych przedsiębiorstwach. Jest uniwersalny – bazuje na założeniu, że każdy projekt musi mieć zasadność biznesową, opierać się na podzielonym na etapy planie, umożliwiać określonym rolom kontrolę i ciągłe uczenie się, dążyć do stworzenia pożądanego produktu i robić to wszystko w sposób dopasowany do wymogów danej organizacji. Zakłada też, że przed rozpoczęciem projektu trzeba go dobrze przemyśleć, potwierdzić jego wykonalność i zasadność, a następnie stworzyć solidne podstawy, które to udokumentują. 
Metodyka PRINCE2 skupia się na wyzwaniach, które w tym procesie czekają kierownika projektu – opisuje konieczność zarządzania ryzykiem i zmianami, skupia się na różnych poziomach planowania i związanych z nimi potrzebami informacyjnymi, pokazuje, jak monitorować projekt i obsługiwać sytuacje nadzwyczajne zapewniając jednocześnie jego ciągłą zasadność. Obejmuje cały cykl życia projektu, a jego siłą jest procesowość, jasne przypisanie odpowiedzialności i dążenie do ciągłego zapewniania ładu i kontroli. 

Druga strona medalu

PRINCE2 ma też jednak wady, wśród których wymienić trzeba… procesowość, jasne przypisanie odpowiedzialności i dążenie do ciągłego zapewniania ładu i kontroli. Tak, dokładnie, nie regulujcie odbiorników – największe zalety PRINCE2 mogą być postrzegane, szczególnie wśród zwolenników bardziej zwinnego podejścia do projektów, jako jego największe wady. W wersji 6, obowiązującej do 2023 roku, PRINCE2 po pobieżnym przeczytaniu faktycznie mógł się wydawać restrykcyjny i sztywno osadzony w procesach. Choć już w tej wersji podkreślano konieczność stosowania np. priorytetyzacji czy dostarczania przyrostowego, to jednak osoby szukające większej elastyczności sięgały raczej po PRINCE2 Agile – tam bowiem napisano wprost, jak można zwinnie wykorzystywać PRINCE2.

Idzie nowe i… lepsze?

To już jednak przeszłość – najnowsza, siódma wersja PRINCE2 silnie integruje podejście zwinne z tradycyjnym i absolutnie uniemożliwia już postrzeganie PRINCE2 jako synonimu podejścia kaskadowego. Nowy PRINCE2 to przede wszystkim silna orientacja na ludzi i konieczność uwzględniania ich motywacji i potrzeb w procesie planowania projektu, to także inkorporowanie technik jednoznacznie zwinnych, takich jak daily stand up, wykresy burn czy tablica kanbanowa, w znane procesy P2.
Nowa wersja P2 ma wszystko, czego potrzeba być stać się nie tylko “jedną z najpopularniejszych metodyk”, ale wręcz “najpopularniejszą metodyką”. Jest też w moim odczuciu pierwszym oficjalnym podręcznikiem do zarządzania projektami, który ze względu na naprawdę znaczną ilość przykładów praktycznych pozwala zrozumieć metodykę także osobom z niewielkim doświadczeniem projektowym. Nowy format książki proponuje bowiem czytelnikowi cztery scenariusze opisujące historie różnych firm, dostarczających różne produkty (od administracji publicznej po aplikację), po to by później, na przestrzeni wszystkich rozdziałów, powracać do tych przykładów i pokazywać, jak konkretnie w kontekście mniej lub bardziej zwinnej firmy, stosowanie danej praktyki może wyglądać. Niesie to naprawdę ogromną wartość poznawczą – niezależnie od tego, jak bardzo czytelnik jest doświadczony w zarządzaniu projektami. 

Jak to więc jest z tym PRINCE2 – warto, nie warto?

Moim zdaniem zdecydowanie warto – niezależnie od poznanej wersji książki, PRINCE2 zawsze zapewniał uwspólnianie rozumienia projektowej rzeczywistości, pozwalał na jasne przypisanie ról i odpowiedzialności, a także osadzenie działalności projektowej w procesach, które są naprawdę dobrze przemyślane i korzystne dla wszystkich interesariuszy. Dobrze jest znać PRINCE2 – bo to pomaga w codziennej pracy, daje odpowiedzi przede wszystkim na pytanie “jak dobrze zacząć projekt”, powstrzymuje też kierownika projektu przed podejmowaniem wszystkich decyzji – jasno bowiem wyznacza tolerancje jego uprawnień i decyzyjności właśnie. Dobrze jest też spojrzeć na nową wersje PRINCE2 – choćby dla samych scenariuszy i przykładów zastosowania metodyki; one naprawdę pomagają usystematyzować wiedzę i zrozumieć, jak czerpać z P2 największe korzyści.
A czy warto mieć certyfikat? Cóż, z całą pewnością ani ten, ani żaden inny certyfikat nie jest niezbędny do zarządzania projektami – chyba, że pracujemy np. przy projekcie unijnym, gdzie taki wymóg formalny faktycznie może się pojawić. Zazwyczaj jednak nie ma takiej konieczności – niemniej nie ulega wątpliwości, że certyfikat potwierdza zdobycie naprawdę rzetelnej wiedzy z zakresu zarządzania projektami i – co nie bez znaczenia – wyróżnia nasze CV spośród innych. Nie trzeba więc go robić, ale… zdecydowanie warto 😊 

Paulina Polatowska
Trenerka PRINCE2

Artykuł Cała prawda o metodyce PRINCE2. Czy nadal warto z niej korzystać? pochodzi z serwisu Inprogress Akredytowane Szkolenia.

• była atrakcyjna, aby ludzie sami chcieli przez nią przechodzić,
• wiedzieć jaki wysiłek, trzeba będzie włożyć w jej dokonanie,
• znaleźli się ludzie, którzy szybko ją podejmą i aby łatwo osiągać i pokazywać korzyści, które przyjdą z jej wprowadzenia,
• potrafić ją śledzić i wzmacniać, kiedy początkowa formuła się wyczerpie.

Autor naświetla krytyczne punkty, o które należy zadbać, aby zmianę przeprowadzić skutecznie i zwraca uwagę, na najważniejsze zadania, które zresztą, w dużej ogólności, zgodne są z curriculum szkolenia Change Management.

Koncepcja dyfuzji innowacji

Wystartujemy od omówienia koncepcji dyfuzji innowacji Everetta Rogersa, ponieważ artykuł bezpośrednio odnosi się do niej jako do istotnej z perspektywy rozprowadzania zmiany w organizacji.

Jest to koncept wywodzący się z lat 60. ubiegłego wieku. Rogers opisuje zmianę z perspektywy reakcji ludzi, których zmiana ta dotyczy – od osób, które będą rozentuzjazmowane na samą myśl o zmianie, aż po osoby, które do ostatniej możliwej chwili będą ociągały się z jej podjęciem. Według koncepcji Rogersa na tej podstawie możemy wyróżnić pięć grup:

• innowatorów,
• wczesnych naśladowców,
• wczesną większość,
• późną większość,
• i maruderów.

Innowatorzy to grupa entuzjastów, zwykle najmniejsza liczebnie, którzy nie mogą doczekać się, aby sprawdzić nowe rozwiązania w praktyce. Zapisują się do wersji beta nowej aplikacji albo ustawiają się w kolejce, aby móc skorzystać z rozwiązania zanim trafi na rynek.
Wcześni naśladowcy to grupa, która lubi nowe zjawiska, jednak czeka aż trochę się upowszechnią i staną choć odrobinę stabilne. To Ci, którzy korzystają z najnowszych sprzętów chwilę po premierze. Grupy te będą krzewicielami zmiany. To ludzie, których entuzjazm koniecznie powinniśmy wykorzystać do szerzenia zmiany. Ich pozytywne nastawienie przekuć można w pilotaże i testy – próby działania zmiany, w małej skali. Będą oni stosunkowo odporni, na różnego rodzaju nadarzające się trudności i problemy, które pojawią się przy tej okazji i chętnie udzielą nam informacji zwrotnej co można byłoby zrobić lepiej. Należy jednak pamiętać, aby nie zawieść ich oczekiwań, bo pomimo swojej odporności uwzględnienie ich feedbacku będzie dla nich istotne.
Wczesna większość to ci, którzy przyjmują nowinki wcześniej niż pozostali, ale np. czekają, aż oprogramowanie dostanie wszystkie niezbędne łatki.
Późna większość to ludzie, którzy z dozą ostrożności podchodzą do wszystkich zmian, ale decydują się ostatecznie na ich zastosowanie.
Obie większości to grupy, których przekonanie świadczy o dokonaniu zmiany. Najłatwiej dotrzeć do nich poprzez pokazywanie historii sukcesów z grupy innowatorów i wczesnych naśladowców. Dobry przykład jak zmiana ułatwi ich życie jest wart więcej niż nawet najlepsza rozpiska korzyści, które planujemy osiągnąć.
Maruderzy to ci, którzy będą ociągać się ze zmianą aż nie stanie się ona konieczna. W końcu po co zmieniać telefon na smartfon – skoro stary wciąż działa i można z niego dzwonić i pisać smsy, a nowy jest taki trudny w obsłudze? Maruderzy będą bronić się do końca. Czasami będzie to spowodowane tym, że nie potrafią zastosować nowego sposobu działania, a czasami z powodu obaw z nią związanych, np. doświadczeń z podobnymi zmianami w przeszłości. Jest to grupa, której punkt widzenia może być zupełnie różny od tego z czym spotkaliśmy się do tej pory. Być może to grupa, która z jakiegoś powodu jest na marginesie i nie została wcześniej wysłuchana. Tej grupie powinniśmy zapewnić odpowiednie wsparcie i koniecznie zebrać jej doświadczenia, ponieważ mogą przynieść ważne wnioski, które poprawią zmianę dla wszystkich.

Projektując zmianę powinniśmy pamiętać o wszystkich grupach z typologii Rogersa. Każda z grup będzie miała swoje zadanie w zmianie i każdej z grup powinniśmy poświęcić uwagę osobno angażując ją w odpowiednich momentach.

Human-Centered Design

W tym celu mogą przysłużyć się metody spod parasola projektowania skoncentrowanego na człowieku (Human-Centered Design). Głównym zadaniem takich metod jest wsłuchanie się w potrzeby różnych grup interesariuszy, a następnie zaprojektowanie takiego rozwiązania, które na nie odpowie. Aspekt, który szczególnie chciałbym naświetlić to wykorzystanie kompetencji projektanckich do tworzenia i przeprowadzania zmiany organizacyjnej. Jak wykorzystać projektowanie skoncentrowane na człowieku, aby angażować interesariuszy? Jak wykorzystać zbudowane podczas projektowania zaangażowanie, aby ludzie pożądali innowacji zamiast przed nią oporować i wreszcie jak włączyć koncepcje zarządzania innowacjami do wspierania zmiany.

Źródła:

Singh, Sudhir. 2020. „Council Post: Goodbye, Change Management; Welcome, Change Design”. Forbes. 8 kwiecień 2020.

Smith, Richard, David King, Ranjit Sidhu, Dan Skelsey, i APMG. 2014. The Effective Change Manager’s Handbook: Essential Guidance to the Change Management Body of Knowledge. Kogan Page Publishers.

Michał Eromin

Artykuł Projektowanie zmiany – o czym warto pamiętać pochodzi z serwisu Inprogress Akredytowane Szkolenia.

W tym celu stworzono Praxis Framework – reprezentujący holistyczne podejście do zarządzania projektami i programami, które dostarcza kompleksowego zestawu narzędzi, technik i procesów w celu osiągnięcia sukcesu.

Czym jest Praxis Framework, komu może przynieść korzyści oraz jak można go wykorzystać w pracy?

Czym jest Praxis Framework?

Praxis Framework to konstrukcja integrująca koncepcje, które możemy odnaleźć w różnych metodykach i podejściach do zarządzania projektami i programami, takich jak np. PRINCE2®, MSP® (Managing Successful Programmes), PMBOK czy APM Body of Knowledge.

Jego celem jest dostarczenie organizacjom wspólnego języka i struktury do efektywnego zarządzania projektami i programami. Przy czym to wszystko ujęte jest w jednolitej konstrukcji. W skrócie: wystarczy poznać Praxis Framework, aby skutecznie zarządzać projektami lub programami, bez konieczności zapoznawania się z osobnymi podejściami do zarządzania projektami i programami, np. PRINCE2 i MSP. Zamiast uczyć się dwóch osobnych metodyk z osobnymi zestawami pojęć, mamy „wszystko w jednym”.

Elementy metodyki

Framework składa się z czterech elementów: wiedzy, metody, kompetencji i zdolności.

• WIEDZA – definiuje zasady, tematy i procesy zarządzania projektami i programami.
• METODA – dostarcza szczegółowych wskazówek dotyczących zastosowania zasad i procesów frameworku.
• KOMPETENCJA – skupia się na umiejętnościach i zdolnościach niezbędnych do skutecznego wdrożenia.
• ZDOLNOŚĆ – dotyczy dojrzałości organizacyjnej i zdolności do ciągłego doskonalenia praktyk zarządzania projektami i programami.

Dla kogo jest Praxis Framework?

Praxis Framework został stworzony z myślą o zaspokojeniu potrzeb różnych organizacji – od małych firm po duże przedsiębiorstwa, działające w różnych sektorach. W szczególności może przynieść korzyści:

• Menedżerom projektów i programów: Praxis Framework dostarcza wszechstronnego zestawu narzędzi dla menedżerów projektów i programów, pozwalając im skutecznie planować, realizować i monitorować swoje inicjatywy. Zapewnia on jednolity język i strukturę działania, co ułatwia zarządzanie projektami o różnym zakresie i skali.
• Zespołom projektowym: Framework ten oferuje wytyczne i techniki, które mogą być stosowane przez zespoły projektowe na różnych etapach pracy. Pomaga w zrozumieniu i skoordynowaniu działań, a także w skutecznym wykorzystaniu zasobów i narzędzi.
• Zarządzaniu portfelem: Praxis Framework wspiera zarządzanie portfelem projektów i programów, umożliwiając organizacjom lepszą kontrolę nad alokacją zasobów, priorytetami i harmonogramami.

Jak można wykorzystać Praxis Framework w pracy?

Praxis Framework może pomóc w rozwiązaniu wielu problemów związanych z zarządzaniem projektami i programami, takich jak:

1.  Brak spójnego podejścia: Praxis Framework dostarcza kompleksowych wytycznych, które umożliwiają organizacjom przyjęcie spójnego podejścia do zarządzania projektami i programami na wszystkich poziomach.

2.  Nieefektywne planowanie i monitorowanie: Framework ten oferuje strukturyzowane procesy, które ułatwiają planowanie projektów i programów oraz śledzenie ich postępów. Dzięki temu menedżerowie są w stanie lepiej kontrolować zasoby, harmonogramy i koszty.

3.  Niskie umiejętności i kompetencje: Praxis Framework skupia się również na rozwoju umiejętności i kompetencji zespołów projektowych poprzez dostarczanie narzędzi szkoleniowych i certyfikacyjnych.

Praxis Framework jest wszechstronnym narzędziem, które umożliwia organizacjom skuteczne zarządzanie projektami i programami. Może przynieść korzyści menedżerom projektów, zespołom projektowym oraz działom zarządzania portfelem. Wykorzystanie Praxis Framework w pracy pozwala rozwiązywać problemy związane z brakiem spójności, nieefektywnym planowaniem i monitorowaniem oraz niskimi umiejętnościami i kompetencjami. Dzięki temu organizacje mogą osiągnąć lepsze rezultaty w swoich projektach i programach, co prowadzi do sukcesu i wzrostu biznesowego.

Rafał Kulpiński

Artykuł Praxis Framework – kilka słów o nowej metodyce pochodzi z serwisu Inprogress Akredytowane Szkolenia.

Związek zarządzania zmianą i Design Thinking najlepiej pokazać na bazie siedmiu pryncypiów angażowania interesariuszy. Każde z nich wspierać możemy poprzez odpowiednie wykorzystanie kompetencji projektanckich i procesów Design Thinking:

1. MOŻESZ ZAPOMNIEĆ O WAŻNYCH INTERESARIUSZACH, ALE ONI NIE ZAPOMNĄ O TOBIE

W ramach DTMethod, metody prowadzenia warsztatów Design Thinking, jedną z pierwszych aktywności warsztatowych jest właśnie identyfikacja i badanie interesariuszy. Projektowane rozwiązanie ma bowiem odpowiadać na żywotne potrzeby zainteresowanych osób, zatem oprócz poznania i omówienia status quo przechodzimy od razu do znalezienia tych, których projektowana zmiana dotknie i to na nich w dalszej części pracy będziemy się skupiać.

2. IDENTYFIKACJA INTERESARIUSZY JEST PROCESEM CIĄGŁYM – PODCZAS ZMIANY WYŁANIAJĄ SIĘ NOWI INTERESARIUSZE, STARZY ODCHODZĄ W CIEŃ

DTMethod powinno stosować się jako podejście iteracyjne, aktywne i uczące się. Poszukiwanie ludzi w jakiś sposób dotkniętych przez projektowane rozwiązanie powinno przebiegać dokładnie tak samo. Gdy tylko zespół projektantów zdobędzie wiedzę o interesariuszach, powinien natychmiast zacząć nad nią pracować, a w przyszłości aktualizować swoją bazę wiedzy i interesariuszy równolegle do prowadzonych działań. Wielokrotnie może okazać się, że trzeba przeprowadzić kilka iteracji identyfikacji i badania interesariuszy.

3. PRIORYTETYZACJA I SEGMENTACJA INTERESARIUSZY DOTYCZY AKTUALNEJ SYTUACJI. KONIECZNA JEST CIĄGŁA OBSERWACJA I KONTROLA

Dodatkowo pamiętać należy, że działania Design Thinking to procesy krótkie i dynamiczne. W DTMethod raptem po kilkunastu godzinach pracy warsztatowej projektanci wracają do kontaktu z interesariuszami. Podczas tego powrotu pytają ich o zdanie na temat tworzonego rozwiązania i zbierają od nich informację zwrotną. Przy okazji tego feedbacku mogą wyłonić się potencjalni nowi interesariusze, których potrzeby trzeba będzie zaspokoić.

4. NIEKTÓRYCH INTERESARIUSZY NAJLEPIEJ ANGAŻUJE SIĘ PRZEZ INNYCH

O wpływie innowatorów i wczesnych naśladowców we wprowadzaniu zmiany pisałem w zeszłym tygodniu. Dlatego tylko krótko podsumowując – są to grupy, które z chęcią angażują się w sprawdzanie i testowanie zmiany na wczesnym etapie, właśnie wtedy kiedy projektujemy zmianę i testujemy ją w małej skali. DTMethod pozwala na wysłuchanie potrzeb tych grup, a następnie ich zaspokojenie, dzięki czemu zwiększa szansę, na to, że staną się oni żywą reklamą naszych działań

5. NAJPIERW STARAJ SIĘ ZROZUMIEĆ, A POTEM BYĆ ZROZUMIANYM

Jednym ze sposobów opisu Design Thinking, a zatem również DTMethod jest model Double Diamond.

Opisuje on proces jako podwójny cykl myślenia dywergentnego (rozszerzanie, badania i eksploracja) i myślenia konwergentnego (zawężanie, analiza selekcja).

Pierwsza część tego cyklu (diament) dotyczy właśnie zrozumienia problemu – zidentyfikowania, zrozumienia i zdefiniowania potrzeb interesariuszy. Dopiero po dogłębnej analizie potrzeb, w drugim cyklu przejdziemy do odpowiadania na problem za pomocą rozwiązania.

6. EMOCJE PRZEWAŻAJĄ NAD ROZSĄDKIEM

Aby osiągnąć sukces we wprowadzaniu zmiany warto opierać jej wprowadzanie właśnie na zbudowaniu emocjonalnego zaangażowania. Świetnym sposobem jest zaangażowanie interesariuszy w pomoc przy tworzeniu zmiany i wykorzystanie tzw. „efektu Ikea” , czyli przeceniania wartości stworzonego przez siebie rozwiązania (Norton, Mochon i Ariely, 2012). W DTMethod pomoc interesariuszy indukowana jest przez samą strukturę – najpierw pytamy ludzi o ich potrzeby, a niedługo potem wracamy do nich aby podpowiedzieli nam czy tworzone rozwiązanie spełnia ich potrzeby.

7. PRZYKŁAD JEST LEPSZY NIŻ ARGUMENT

Elementem definicji Design Thinking bywa często wizualizacja tworzonych rozwiązań (Hassi and Laakso, 2011). Tak samo jak w angażowaniu interesariuszy – wielokrotnie lepiej na wyobraźnie działa pokazanie zastosowania czegoś w praktyce niż nawet najlepszy opis. DTMethod cały trzeci etap procesu poświęca właśnie na przekucie słownego opisu w pełnoprawny prototyp – coś namacalnego, aby pokazać to coś interesariuszom. Prototypowanie i testowanie, (szczególnie jeśli wnioski są konstruktywne, a kolejne iteracje pokazują usprawnienia) to również wspaniała okazja aby zaszczepić w interesariuszach wizję potencjalnego sukcesu, która może zmotywować uczestników do działania.

Zarządzanie zmianą i Design Thinking to obszary, których drogi przecinają się na wielu płaszczyznach i jedną z nich jest właśnie angażowanie interesariuszy. Sposób myślenia i pracy wykorzystywany w DTMethod zasadza się na tych samych teoriach z których korzysta Change Management. Umiejętne wykorzystanie sprawdzonej metody Design Thinking w projektowaniu zmiany, buduje fundament pod dalsze jej krzewienie i zwiększa szansę na osiągnięcie sukcesu. Właśnie dlatego DTMethod może okazać się świetnym uzupełnieniem „narzędziowni” każdej osoby odpowiedzialnej za zmianę w organizacji.

Źródła:

1. Hassi, L. and Laakso, M. (2011) ‘Conceptions of design thinking in the management discourse’, European Academy of Design Conference, Porto, Portugal, 4.-7.5.2011, pp. 341–351.
2. Norton, M.I., Mochon, D. and Ariely, D. (2012) ‘The IKEA effect: When labor leads to love’, Journal of Consumer Psychology, 22(3), pp. 453–460. Available at: https://doi.org/10.1016/j.jcps.2011.08.002.
3. Smith, Richard, David King, Ranjit Sidhu, Dan Skelsey, i APMG. 2014. The Effective Change Manager’s Handbook: Essential Guidance to the Change Management Body of Knowledge. Kogan Page Publishers.
   

Michał Eromin

Artykuł Zastosowanie Design Thinking w zarządzaniu zmianą – 7 pryncypiów angażowania interesariuszy pochodzi z serwisu Inprogress Akredytowane Szkolenia.

Jeśli zaglądacie regularnie na naszego bloga na pewno pamiętacie artykuł o Wartości w Scrumie

Skoro o wartości już było, to czy warto pisać o niej w kontekście ITIL? Przecież ITIL to zestaw najlepszych praktyk w zarządzaniu usługami, nie może stać w kontrze do innych dzisiaj praktykowanych przez nas podjeść. Zerknijmy.

Czym jest wartość

„Wartość – dostrzegane korzyści, użyteczność lub określone znaczenie”

ITIL®Foundation, Wydanie ITIL4, 4th Edition, Axelos

Niezwykle krótka definicja, prawda? Ale czy daje nam poczucie, że rozumiemy bez żadnych wątpliwości co w praktyce kryje się pod nią? Niestety nie jest to takie oczywiste, bo przemyślenia, do których kieruje nas ITIL to fakt, że jeśli wartość ma być dostrzegana, to przecież każdy z nas może postrzegać inne cechy, produkty czy usługi za wartościowe. Walidujemy wartość indywidualnie, a każdy z nas ma inne filtry poznawcze.

Wynikają one z naszych wartości, potrzeb, sytuacji, doświadczenia, planów na przyszłość, czy przyjętej strategii rozwoju w kontekście organizacji. ITIL sugeruje wprost, że wartość jest subiektywna i zależy od wielu czynników.

To, czy coś jest dla nas użyteczne będzie zależne od planowanych przez nas działań albo wyzwań, które na nas czekają. Samochody są przecież użyteczne, ale czy mieszkając w ścisłym centrum dużego miasta gdzie korzystanie z szerokiego wachlarza publicznych albo alternatywnych środków transportu jest ekonomiczną i organizacyjną oczywistością będę stać na stanowisku, że koniecznie potrzebuję samochodu, aby stresować się korkami czy brakiem parkingu? Pewnie nie. Ale jeśli moja praca wymaga ciągłego przemieszczania się do miejscowości okolicznych, gdzie transport publiczny może nie wspomagać mojej mobilności prawdopodobnie jednak zaliczę samochód do potrzebnych mi narzędzi.

Dwa elementy wartości zgodnie z ITIL

Ale to podejście przecież nie wyróżnia ITIL’a od innych praktyk czy metodyk. To co dodatkowego możemy znaleźć w publikacjach ITIL? ITIL mówi o dwóch dodatkowych elementach:

1. „Przeznaczeniem organizacji jest tworzenie wartości dla interesariuszy.”

ITIL®Foundation, Wydanie ITIL4, 4th Edition, Axelos

Niezależnie czy działamy komercyjnie, czy jesteśmy wolontariuszami, organizacją non-profit, działamy w jakimś celu. Publiczny zakład opieki działa w celu spełnienia przysięgi Hipokratesa, Urząd Gminy działa na rzecz wsparcia swoich mieszkańców. Jak się chwilę zastanowimy to nawet komercyjnie działająca organizacja pozwala na realizację wielu punktów strategii – czasem działamy dla czystego zysku, czasem marząc o nowych rynkach zbytu, gdzie wejście na rynek jest związane z niższą marżą, albo wręcz jak Patagonia, zmieniamy definicję komercyjnej działalności.

Każdy z nas działa na rzecz tworzenia wartości, a jej postrzeganie jest subiektywne, bo wprost zależy od interesariuszy indywidualnego przedsięwzięcia.

2. „Aby tworzyć wartość, organizacja nie może tylko świadczyć usługi, musi robić coś więcej. Musi również współpracować z korzystającymi w ramach relacji usługowych.”

ITIL®Foundation, Wydanie ITIL4, 4th Edition, Axelos

Wartości nie da się dostarczyć. Nie bardzo uda się ją zapakować w karton i przesłać kurierem. Wielokrotnie w organizacjach słyszymy po zakończeniu projektu, że produkt wytworzony przez zespół został dostarczony, więc wartość została osiągnięta. Czy rzeczywiście? Najszybszym testem tego założenia jest mój ulubiony „test telefonu”. Zerknijcie do Waszych smartfonów. Ile aplikacji dostarczonych przez developerów jest przez Was aktywnie używanych, a ilu z nich nie otworzyliście przez ostatnie, powiedzmy, 6 m-cy? Czy ta ostatnia grupa kolorowych ikonek co do których nie pamiętamy nawet do czego służą, jest dla nas użyteczna, ma dla nas jakiekolwiek znaczenie, daje nam jakieś korzyści? Jeśli nie potrafimy znaleźć potwierdzającej odpowiedzi na te pytania to … pewnie należałoby je wykasować i zwolnić co nieco miejsca w pamięci telefonu, bo ta grupa aplikacji nie ma obecnie dla nas wartości.

Tworzenie wartości w ITIL

Jak więc wypełnić nasz cel? Jak tworzyć wartość?

ITIL na to proponuje bardzo proste rozwiązanie. Angażujemy się w relacje, którą są dla nas wartościowe. 

A jak zrozumieć co jest wartościowe dla zaangażowanych osób (interesariuszy)?
Potrzebne będzie trochę starań, żeby siebie nawzajem zrozumieć, poznać cele, oczekiwania. Dyskusję jak działać na rzecz współtworzenia wartości w ITIL otwiera szkolenie ITIL 4 Foundation, a następnie w wielu kontekstach wsparcie znajdziemy w każdym kroku ścieżki certyfikacyjnej.

Agnieszka Góra-Wołoszyn, trener PRINCE2, ITIL

Artykuł Wartość według ITIL’a pochodzi z serwisu Inprogress Akredytowane Szkolenia.

MSP 4th a MSP 5th edition

Poprzednią 4 edycję MSP (Managing Successful Programmes) opublikowano w 2011 roku. To co było i ciągle jest aktualne to potrzeba posiadania ustrukturyzowanego podejścia do wprowadzania strategicznych zmian w organizacjach. Jednak ostanie 10 lat to okres narastających zmian. Rewolucja cyfrowa, zwinne sposoby pracy, niejednoznaczność i pogłębiająca się niepewność we wszystkich obszarach ludzkiej działalności powodują, że zarządzanie programami musi ewaluować, aby sprostać nowym wymaganiom.

Piąta edycja MSP stara się dorównać tym wyzwaniom. W szczególności kładzie nacisk na większą elastyczność, zdolność do adaptacji i szybkość reakcji na nowe informacje poprzez przyjęcie przyrostowego podejścia do cyklu życia programu. Pojedynczy program lub projekt może łączyć różne podejścia do wytwarzania, np. agile, kaskada, czy cykl ciągłego udoskonalania.

3×7 w MSP 5th edition

Strukturę MSP 5th edition można opisać jednym wyrażeniem „3 x 7”. Metodyka ta składa się z 7 Zasad, 7 Tematów (poprzednio 9) i 7 Procesów (poprzednio 6).

7 Zasad:
1. Kieruj z celem,
2. Współpracuj ponad granicami,
3. Radź sobie z niejednoznacznością,
4. Dostosuj się do priorytetów,
5. Wdrażaj różnorodne umiejętności,
6. Osiągaj wymierne korzyści,
7. Nadawaj tempo i twórz wartość
Zasady są nadal opisane jako uniwersalne, samopotwierdzające się i wzmacniające osiąganie wartości z zarządzania programami ale zostały zmienione, aby zapewnić ich ważność w zmienionym środowisku biznesowym. Zasady stanowią podstawę wszystkich tematów. Ich przestrzeganie ma zapewnić wartość ze stosowania zarządzania programami.

7 Tematów:
1. Organizacja,
2. Projektowanie,
3. Uzasadnienie,
4. Struktura,
5. Wiedza,
6. Nadzór,
7. Decyzje
identyfikuje i opisuje kluczowe role i obowiązki oraz informacje potrzebne min. do:
– stworzenia wizji i zaprojektowania docelowego modelu operacyjnego organizacji,
– opracowania uzasadnienia biznesowego i jego powiązania z planowaniem finansowym i korzyściami,
– opracowania strategii i planów w celu wytworzenia potencjałów, dzięki którym program dostarczy rezultaty i korzyści wspierające osiągnie celów strategicznych organizacji,
– podejmowania decyzji, które umożliwią wprowadzanie zmian projektowych i biznesowych na podstawie wiarygodnych informacji.

7 Procesów:
1. Identyfikowanie programu,
2. Projektowanie rezultatów,
3. Planowanie przyrostowego dostarczania,
4. Dostarczanie potencjałów,
5. Wdrażanie rezultatów,
6. Ocena nowych informacji,
7. Zamykanie programu
składa się na cykl życia programu. Pierwszy i ostatni proces zapewniają odpowiednio kontrolowane rozpoczęcie i zakończenie programu. Pozostałe tworzą grupę cyklicznych procesów dostarczania, w ramach której pożądane wyniki biznesowe są projektowane, planowane, wdrażane (osadzane), a korzyści dostarczane w cyklicznych transzach. Końce transz są „punktami docelowymi” (Eng. landing point), w których można ocenić postępy w osiąganiu celów strategicznych i na podstawie nowych informacji oraz zebranych doświadczeń podjąć decyzję o kontynuowaniu lub zamknięciu programu. Każdy rozdział poświęcony procesowi wyjaśnia w jaki sposób Tematy są stosowane w tym procesie oraz opisuje odpowiedzialności kluczowych ról w ramach każdego procesu.

MSP 5th edition jest ciągle źródłem wiedzy i inspiracji dla osób pragnących rozwijać swoje kompetencje w obszarze zarządzania programami.

Krzysztof Jaworski

Artykuł MSP® 5th edition – czas na zmianę pochodzi z serwisu Inprogress Akredytowane Szkolenia.

Wszystko zaczęło się od rozmowy

– Zmieniam swoje życie! Dzieciaki odchowane, kredyt prawie spłacony, no muszę zaryzykować, jak nie teraz to kiedy! Młodsza nie będę!

– Farbujesz się na blond? Jedziesz na trekking po Kilimandżaro? Założyłaś konto na Tinderze?

– NIE! Głupia jesteś, jaki Tinder, jakie Kilimandżaro. Zmieniam pracę, będę Project Managerem, zawsze mówiłaś, że się nadaję.

– Asia, ale Ty jesteś specjalistką ds. sprzedaży, świetną specjalistką, ale… project management?

– Wychowałam bliźniaki pracując na pełen etat, w między czasie postawiłam dom. Nie powiesz mi, że to nie jest zarządzanie projektem! Ba, nawet trzema!

– Ekm, no metodycznie to nie jest projekt, to pierwsze to raczej działalność operacyjna…

– PRZESTAŃ! I pomyśleć, że idę na to szkolenie do Ciebie.

– ?! To nowa praca czy tylko szkolenie?

– No nie pomyślałaś, chyba że od razu, prosto z POLSPRZEDu pójdę na PM-a? Kto by mnie nie zatrudnił, potrzebuję jakiejś konkretnej, ugruntowanej wiedzy, najlepiej z przykładami. Dlatego najpierw idę na takie łączone szkolenie. Jeden dzień ten klasyk, drugi – metody zwinne, potem jeszcze dwa dni praktyki, certyfikat, egzamin i już. To się nazywa…no.…czekaj, mam na mejlu, PrinceEndAgile? PrinceOrAgile…?

– PRINCE2 Agile…?

– TAK! To. Szkolisz przecież z tego, prawda? Pojutrze też?

– Tak, szkolę. Ale Aśka…. zapłaciłaś już za to…?

– Nie, jeszcze nie.

– Doskonale. Natychmiast to odwołaj. To szkolenie w tym momencie nie ma dla Ciebie najmniejszego sensu.

Ale jak to „odwołaj szkolenie”?!

Ta rozmowa faktycznie miała miejsce – na początku tego roku moja kuzynka poinformowała mnie o chęci zmiany ścieżki kariery. Nic dziwnego, że rozmawiała ze mną – pracuję w zarzadzaniu projektami od ponad dwunastu lat, od dawna też mówię jej, że jest stworzona do tej branży.

Aśka to urodzona „ogarniaczaka”, wszystko załatwi, wszystkiego się dowie, a do tego wszyscy poczują się wysłuchani i docenieni. Zepsuł się piec na działce? Za dwa dni wpadnie ekipa, która nie tylko ten piec naprawi dobrze (bo kuzynka patrzy surowym okiem), ale też tanio – bo jako specjalistka od sprzedaży jest też świetną negocjatorką. Dziadek wylądował w szpitalu? Telefon tu, telefon tam, za chwilę jakieś konsylium, badanie, tyle zamieszania (kontrolowanego!), że na koniec sam ordynator do niej wpada z kwiatami, za to, że tak pięknie pokierowała leczeniem. Asia jest też bardzo empatyczna, potrafi się świetnie komunikować, aktywnie słucha – naprawdę, ma wszystkie najważniejsze kompetencje miękkie niezbędne na stanowisku project managera.

Czy więc powinna aplikować od razu na to stanowisko? Oczywiście, że nie, musi najpierw zdobyć jakąś wiedzę na temat zarządzania projektami. Czy w tym pomoże jej szkolenie PRINCE2 Agile? Tak – ale największą korzyść osiągnie z niego, jeśli wcześniej choć trochę pozna temat zarządzania projektami.

W takim razie warto czy nie warto?

PRINCE2 Agile to szkolenie bardzo intensywne i wymagające – pierwszego dnia kursanci omawiają cały (!) proces PRINCE2[1], a następnego poznają metody zwinne. W ciągu sześciu godzin usłyszą więc o Manifeście Agile, Scrumie, Kanbanie, Lean StartUpie, poznają takie terminy jak retrospektywa czy warsztat facylitowany, a z tego wszystkiego zostanie jeszcze wykrojony czas na ćwiczenie w grupach i przygotowanie do egzaminu. Czy to się da? Oczywiście – niemniej osoby, które nigdy wcześniej nie słyszały o zarządzaniu projektami mogą czuć się takim szkoleniem przytłoczone i nie osiągnąć z niego maksimum wartości. Jeśli jednak nawet najbardziej poczatkujący w dziedzinie zarządzania projektami kursant przed samym szkoleniem przeczyta chociażby tzw. „materiały przedkursowe” gwarantowane przez Inprogress, może weźmie udział w darmowym webinarze z podstaw zarządzania projektami na udemy.com, lub chociaż obejrzy kilkanaście filmików z tego zakresu na youtube.com, – to wówczas uzyska solidny fundament, na którym to szkolenie pozwoli zbudować głębokie zrozumienie najważniejszych połączeń między PRINCE2 a metodami zwinnymi.

Metodyka okiem naszej trenerki Pauliny Polatowskiej

PRINCE2 Agile to dla mnie, zarówno jako trenera jak i project managera, najciekawsza i najbardziej przydatna metoda zarządzania projektami. Oczywiście, jak na każdym innym szkoleniu i tu znajdziemy pewne definicje i wyliczenia, których trzeba się nauczyć „pod egzamin”, i tu pewne tłumaczenia będą niedokładne – ale sama metoda, obdarta z rzeczy „pod egzamin” jest świetna, jest tym, co NAPRAWDĘ ma szanse zadziałać w projekcie. Żeby to jednak zrozumieć, docenić i jak najszybciej wykorzystać w przyszłości, żeby poza wiedzą uzyskać także jej faktyczne zrozumienie, należy spędzić z tą metodą trochę czasu – zarówno przed szkoleniem, jak i po jego zakończeniu. Gwarantuję jednak, że to się opłaci, a szkolenie, poza certyfikatem, przyniesie prawdziwą wartość, która będzie miała szanse przełożyć się na realne korzyści.

[1] Najkrótsze szkolenie z PRINCE2, PRINCE2 Fast Track trwa 16h. Na P2A proporcjonalnie mniejszy wolumen treści omawia się w 7h.

Autor: Paulina Polatowska

PRINCE2®, PRINCE2 Agile® są zarejestrowanymi znakami towarowymi należącymi do AXELOS Limited i używanymi za zgodą AXELOS. Wszelkie prawa zastrzeżone.

Artykuł Historia, o tym, że (nie) warto iść na szkolenie PRINCE2 Agile® pochodzi z serwisu Inprogress Akredytowane Szkolenia.