Błąd 404 - Strona nie znaleziona
Przepraszamy, strona, której szukasz nie została znaleziona
You can go to the homepage

OSTATNIE WPISY

0 916
agile man

Szał na Agile – tak, „szał” to słowo, które wydaje mi się w tym przypadku całkiem odpowiednie – trwa na świecie od kilku dobrych lat (jeśli nie od jakiejś dekady). Komu ten wyraz nic nie mówi, ten obowiązkowo musi zaktualizować swoją wiedzę na temat zarządzania. Agile jest modny. Agile jest trendy. Agile jest potrzebny. Agile dla firm innowacyjnych, które idą z duchem czasu to po prostu „must-have”. A mnie natomiast nowatorskość Agile wydaje się mocno przereklamowana. Hmmm, może powinnam ująć to inaczej: wydaje mi się, że Agile wcale nie jest tak unikatowy i wyjątkowy jakby się na pierwszy rzut oka wydawało. Aaaa, kij w mrowisko – checked. A niech się posypią i te sprzeczne komentarze. Tylko konstruktywnie, proszę! Już rozwijam temat:)

Na czym polega koncepcja Agile? Agile to w bezpośrednim tłumaczeniu „zwinny”. Innymi słowy elastyczny, zmienny, „łatwodostosowalny”. A jakie ma to bezpośrednie przełożenie na zarządzanie projektami? Wiodąca koncepcja Agile mówi, że na początku projektu nie powinniśmy na siłę planować całego jego przebiegu aż po produkt końcowy. Projekt powinniśmy wykonywać „w kawałkach”, tzw. iteracjach. W projektach zwinnych zakres nie jest ściśle określony, na początku projektu często nie wiemy jak ma wyglądać ostateczny wynik. Ustalamy razem z Klientem obszar produktu, nad którym popracujemy w pierwszej fazie (iteracji). Po ukończeniu fazy musimy koniecznie mieć namacalny produkt cząstkowy. Kawałek produktu, który da się zobaczyć, ocenić, by na jego podstawie móc ustalić co robimy dalej, w kolejnych iteracjach. I tak powtarzamy wielokrotnie aż do uzyskania upragnionego efektu końcowego. To co uwielbiam w Agile, to koncepcja zespołów „samoorganizujących się”. Zwinne zespoły to takie, które poniekąd same sobą zarządzają. Same ustalają kto jaką rolę będzie pełnił w danej iteracji, komu jakie zadania zostaną przypisane. Jak się domyślacie, rola lidera w projektach zwinnych jest mocno ograniczona. Zadaniem „przywódcy” jest tutaj ułatwianie pracy zespołowi, pokonywanie przeszkód jakie zespół projektowy napotyka w zderzeniu z otoczeniem pozaprojektowym, np. z ograniczeniami płynącymi z organizacji, w której zespół funkcjonuje. Zatem rolą lidera jest zazwyczaj również kontakt z Klientem. To jedynie zarys ogólnej koncepcji. Jest wiele metodyk, odłamów Agile. O nich może kiedyś w oddzielnych artykułach.

Agile a planowanie w stylu klasycznym

Jak to ma się do projektów zarządzanych klasycznie, stylem waterfall? Styl „wodospadowy” rzeczywiście skupia się na tym, by na początku projektu dobrze określić jego końcowy cel i kryteria sukcesu, by dokonać wszelkich dogłębnych analiz, by jak najwięcej czasu poświęcić na planowanie, bo ten czas podobno w fazie realizacji zwróci nam się z przysłowiową „nawiązką”. Ale ten styl również zakłada iteracje, czyli powtarzalność kroków wewnątrz poszczególnych faz projektowych. Ten styl również mówi o planowaniu kroczącym, które zakłada, że nie jesteśmy w stanie w szczegółach zaplanować całego projektu na samym początku. Co możemy, zrobić, to zaplanować fazy projektowe, podstawowe kroki, które musimy w projekcie wykonać i najbliższą fazę projektową zaplanować w szczegółach. Plany dla kolejnych faz projektowych będziemy doprecyzowywać zbliżając się do tych faz. Jeśli wiem, że pierwsza faza w moim projekcie to rekrutacja, a potem szkolenie, to dokładnie zaplanuję poszczególne kroki i scenariusze rozwiązania w fazie rekrutacji. Szkolenie prawdopodobnie zaplanuję na bardzo ogólnym poziomie, a plan ten doprecyzuję pod koniec rekrutacji. Wtedy dokładnie będę wiedziała ile osób weźmie udział w szkoleniu i jakie są potrzeby szkoleniowe. Czy czegoś Wam to nie przypomina? Jeśli chodzi o zarządzanie ludźmi, to „klasyka” nakazuje liderowi przypisywać zasoby do zadań. Czy znacie jednak teorię przywództwa, która mówi by robić to na siłę?

 Zmiany nieuchronne również w „klasyce”

Owszem, mogą zdarzyć się skrajne przypadki, w których rządzi klasyka. Wyobrażam sobie, że takich znajdzie się sporo w budownictwie, górnictwie, ogólnie w przemyśle. Jak przemyślę swoje doświadczenie, szybko jednak nasuwa się wniosek, że niejednokrotnie intuicyjnie działam w stylu Agile. Członkowie moich zespołów decydują na jakie zadania „rozbić” projekt i kto z nich będzie je wykonywał. Ja ich jedynie w tym zakresie wspieram. Nikt tego oficjalnie Agilem nie nazywa. Wszyscy niby myślą na nutę klasyczną. Tymczasem? Każdy wie, że określony cel projektowy będzie ewoluował w trakcie trwania projektu, że plany pewnie niejednokrotnie się zmienią, zmieni się otoczenie, zmienią się wymagania, zmieni się koncepcja. Tak! Bo rzeczywistość taka po prostu jest. W projektach ciągle się coś zmienia. Jeśli pracujemy dla organizacji, która chce być konkurencyjna, zmiana w projektach jest nieuchronna. Jeśli mogę pozwolić sobie na odrobinę szczerości, niejednokrotnie przysparzało mi to wiele frustracji. Jako świeżo upieczony kierownik projektu, denerwowałam się, że jeszcze wczoraj tak pięknie dopieszczony plan projektowy, dzisiaj już nie obowiązuje i trzeba go zmieniać. Przy dużych zmianach organizacyjnych zespołom tak trudno było doprecyzować finalną koncepcję struktury organizacyjnej i docelowego procesu, że wydawało mi się, iż z fazy planowania nigdy się nie wydostaniemy. I co? I trzeba było tworzyć jedynie zarysy nowej struktury, ramy nowego procesu, adresować obszary na daną chwilę bardziej oczywiste, ruszać z projektem i z czasem doprecyzowywać co dalej.

Agile a klasyczne koncepcje zarządzania ludźmi

Jeśli chodzi o zespoły, w klasycznym stylu zarządzania rzeczywiście może być różnie. Style zarządzania ludźmi i sposoby ich motywowania zależą od kierownika projektu, od kultury organizacyjnej. Jednak mój styl mocno wpasowuje się w Agile. Nie wyobrażam sobie zmusić kogoś do wykonywanej pracy. Wyznaję zasadę, że „z niewolnika nie zrobisz pracownika”. Sama jestem tego chodzącym przykładem. Za każdym razem, gdy moja praca ograniczała się do wykonywania zadań, za którymi nie przepadam, rozglądałam się za nowym zajęciem. Gdy moja nowa szefowa codziennie rozliczała mnie z pracy wykonanej w ciągu dnia, zaczęłam wysyłać CV. Na szczęście zdobyłam się na szczerą rozmowę i pozbyłyśmy się tego problemu w inny sposób. Staram się traktować ludzi tak samo, jak chciałabym być traktowana i w swoich projektach pozostawiam im dużą swobodę. Tak, nie zawsze ludzie wykorzystają tę swobodę w odpowiedni sposób. Z tym problemem jednak boryka się również Agile.

Dla kogo Agile?

Podsumowując, Agile jest świetną koncepcją dla każdej organizacji, niezależnie od branży. Jednocześnie Agile wcale nie jest czymś tak niesamowicie nowatorskim dla organizacji, które w metodzie klasycznej dawały swoim pracownikom dużo swobody i liczyły się z nieuchronnymi zmianami z projektach, czy też godziły się z faktem, że projektu nie da się na samym początku zaplanować od A do Z. Agile jest trudny do wdrożenia szczególnie dla kierownictwa wyższego szczebla przyzwyczajonego do tego, że zawsze widzi efekt końcowy, do którego zmierzamy, zna koszty całego projektu. Choć rzeczywistość dynamicznie rozwijających się organizacji jest taka, że zarówno kształt tego efektu końcowego, jak i koszty całego projektu zmieniają się w trakcie realizacji. I tego doświadczony management jest świadomy. W takich przypadkach organizacje wdrażają często Agile „na dole” struktury, a „góra” bądź Klient nadal dostaje raport w stylu klasycznym. Moim zdaniem to bardzo niekorzystne rozwiązanie i zaakceptowałabym je jedynie jako przejściowe. Owszem, mieszanie metodyk to świetne rozwiązanie. Nie ma jednej metodyki, która idealnie adresuje potrzeby organizacji. Każda organizacja powinna „uszyć sobie metodykę na miarę” swoich potrzeb. I takie rozwiązanie może mieć elementy Agile i waterfallowe. Nie ma w tym nic złego. Jeśli jednak wprowadzam elementy Agile do danego obszaru projektowego, to kompleksowo, w całe strukturze organizacyjnej. Nie ma sensu rozwiązanie, w którym „udaję”, że zakres jest nieokreślony i mogę sobie go doprecyzować w trakcie projektu, jeśli tak naprawdę za projektem jest już kontrakt podpisany z Klientem, w którym dokładnie sprecyzowaliśmy co otrzyma Klient, w jakim czasie i za ile.

To tyle gwoli zarysu fenomenu Agile. Polecam wnikać głębiej i wdrażać w swoich projektach. Osobiście uwielbiam swobodę i otwartość metodyk zwinnych.

0 885
scrum team

Od kilku lat wśród programistów dużą popularnością cieszy się Agile Software Development, czyli zwinne wytwarzanie oprogramowania. Popularność tego zjawiska sprawiła, że w nomenklaturze projektowej pojawiło się Agile Project Management, czyli zwinne zarządzanie projektami. O ile pierwsze można z pewnością z powodzeniem zastosować do wykonywania oprogramowania i innych procesów wytwórczych (z dużym powodzeniem można stosować w marketingu), o tyle zwinne zarządzanie projektami jest sprawą dosyć umowną. Metodyki zaliczane do Agile Project Management, wśród nich m.in. Scrum, są mimo wszystko tylko sposobami samej realizacji projektu.

Analizując główne założenia Scruma pod kątem zarządzania projektem, dochodzimy do wniosku, że brakuje w nich wytycznych dotyczących inicjacji oraz zakończenia projektu. I są to elementy, przez które Scruma tak naprawdę nie powinno się stosować dla całego projektu. Scrum bowiem zakłada wykonywanie kolejnych zadań pochodzących z określonego zbioru, w mniejszym lub większym stopniu zdefiniowanych i gotowych do realizacji, w stałych cyklach realizacyjnych. Zazwyczaj na początku realizacji projektu liczba cykli jest znana, dzięki czemu można powiedzieć, że znany jest także czas i budżet takiego projektu. Scrum zakłada także pracę w grupie, której liczba pracowników jest z góry narzucona, a kompetencje pozwalają wykonać cały projekt. Podstawowe założenia realizacyjne Scruma odnoszą się więc do czegoś wcześniej przygotowanego.

Pojawia się więc pytanie, czy zwinne zarządzanie projektem jest tak naprawdę zarządzaniem projektem. Tradycyjne metodyki wyróżniają, w zależności od metodyki, minimum trzy etapy w projekcie. Faza inicjacji, faza realizacji i faza zakończenia – zgodnie ze sztuką prowadzenia projektów takie etapy (fazy) w każdym projekcie muszą się znaleźć. Czy są one w Agile Project Management? Nie, i wątpliwe jest czy można byłoby je w nim zaimplementować. Został on bowiem stworzony z zupełnie innym zamysłem, zupełnie inna idea mu przyświecała. Miał skutecznie poprawić efektywność projektów, miał sprawić, że projekty będą kończone z sukcesem, nie zaś zarzucane w trakcie realizacji bądź planowania. Agile Software Development był, jak się później okazało, w miarę dobrym narzędziem poprawy wydajności projektowej. Agile Project Management nie zawsze musi być skuteczny, jeżeli chodzi o wykonanie projektu jako całości.

Dlaczego więc mówimy o zwinnym zarządzaniu projektami, dlaczego zyskuje ono coraz większe grono zwolenników, które powoli wykracza już poza sferę informatyki i programowania? Odpowiedź na to pytanie znajdziemy w sposobie działania wielu firm wykonujących na zlecenie pewne usługi. Niech przykładem będzie firma świadcząca szeroki zakres usług marketingowych. Przychodzi do niej klient, który zamawia kampanię reklamową swojego produktu/usługi, do wykonania w określonym budżecie i określonym czasie (na określony moment w czasie). A więc inicjacja projektu za nami. Jeżeli po zakończonej kampanii klient będzie chciał tylko faktury, naprawdę niewiele trzeba, by zainicjować i zamknąć projekt. Kwintesencja takiego projektu, czyli realizacja kampanii marketingowej, może być już wykonana przy pomocy Scruma czy innej metodyki zwinnej. Z takim czymś poradzą sobie one z nawiązką.

WŁĄCZENIE INICJACJI I ZAKOŃCZENIA W SCRUMOWE ITERACJE

Czy istnieje sposób „naciągnięcia” założeń Scruma do objęcia nim całego projektu? Chyba najlepszym sposobem jest włączenie fazy inicjacji w cykle „produkcyjne” Scruma. Od samego początku Scrum Master wraz z trzonem zespołu powinien przygotowywać projekt, a efektami kolejnych cykli jego pracy powinny być dokumenty inicjujące projekt (ich liczba i zakres mogą być zaczerpnięte z jednej z tradycyjnych metodyk zarządzania). Także faza zakończenia, wymagająca zazwyczaj testów odbiorczych, może być włączona pod postacią ostatniego cyklu realizacyjnego.

Czy takie rozwiązanie sprawdzi się w rzeczywistości, zależeć będzie od umocowania Scrum Mastera w hierarchii zarządczej firmy oraz dopuszczeniu go do negocjacji z potencjalnym klientem. Duża korporacja, podzielona na działy, wydziały i oddziały pewnie nie będzie w stanie zrobić niczego takiego. W małej firmie natomiast będzie obawa o to, że Scrum Master będzie miał zbyt dużą władzę decydując o danym projekcie. Dobrym przykładem rozwiązania danego problemu byłoby uczynienie Scrum Masterem lub Product Ownerem osoby związanej z negocjacjami projektu z klientem zewnętrznym lub wewnętrznym. Rola Scrum Mastera dałaby jej władzę, Product Ownera kontrolę nad realizacją projektu. Nie jest także złą sytuacją, gdy Scrum Master (jako kierownik przyszłego projektu) będzie pełnił rolę doradczą w negocjacjach z klientem.

We włączeniu fazy inicjacji w cykle scrumowe można zauważyć jeszcze jedno niebezpieczeństwo, ale także ratunek dla projektu. Pracując z projektem, którego zakres jest zmienny i ściśle nieokreślony, będziemy mogli swobodnie pracować między kolejnymi iteracjami. Taka praca będzie dla nas nawet bardziej komfortowa. Inaczej będzie się miała rzecz, gdy klient będzie wymagał dokumentacji podobnej do tej, jaką zna z metodyk tradycyjnych. W tym wypadku należałoby zrezygnować ze Scruma.

Jest jeszcze jeden aspekt, o którym warto pamiętać, chcąc inicjować projekt scrumowo. Praca w Scrumie nastawiona jest na współpracę z klientem i zaspokojenie jego potrzeb. Inicjowanie projektu często musi zostać wykonane poza wiedzą i świadomością klienta. Tutaj może pojawić się konflikt. Ciężko sobie wyobrazić bowiem wspólną pracę nad dokumentami takimi, jak rejestr ryzyk czy plan komunikacji, w których jako ryzyko będziemy traktowali np. duże ryzyko niewypłacalności klienta, albo założymy, że o problemach ze specjalistami nie będziemy informować klienta. Wybierając to rozwiązanie trzeba będzie się z tym zmierzyć.

WŁĄCZENIE SCRUMA W FAZĘ WYKONANIA PROJEKTU

Rozwiązaniem alternatywnym będzie przygotowanie „pod Scruma” całego projektu, czyli przeprowadzenie fazy inicjacji projektu i potem zakończenia projektu przez niezależnych ekspertów, związanych z tradycyjnymi metodykami. Będziemy pewni, że projekt będzie przygotowany zgodnie z prawami sztuki zarządzania projektami, wszystkie dokumenty będą prawidłowe, a scrumowcom pozostanie tylko odpowiednie wykonanie projektu.

No właśnie, czy będzie to przygotowane dobrze dla osoby korzystającej z metodyk tradycyjnych czy dla osoby posługującej się Scrumem? Trzeba bowiem pamiętać, że wykonanie produktu projektu przy pomocy Scruma będzie wymagała odpowiedniego zainicjowania projektu, jak i jego zakończenia. W fazie inicjowania projektu realizowanego przy pomocy Scruma będziemy musieli uwzględnić takie elementy, jak zaangażowanie klienta (przedstawiciela klienta) w bieżące prace, konieczność przygotowania rejestru produktowego zawierającego krótkie opowieści będące podstawą prac zespołu, tworzenie zamkniętego i w miarę samowystarczalnego zespołu realizacyjnego, czy na końcu cykliczność dostarczania produktów i oceniania postępów prac. W fazie zakończenia trzeba będzie zwrócić uwagę na to, że cykliczne oceny wartości produktu dla klienta powinny znacząco skrócić fazę testów odbiorczych, a zmienny w czasie zakres projektu nie będzie pozwalał na porównanie efektu z zamierzeniem. Wymienione wyżej elementy są jedynie tymi, które w sposób zasadniczy rzutują na sposób przygotowania projektu.

Dla osoby tworzącej tradycyjne dokumenty uwzględniające zwinne rozwiązania jest to nie lada wyczyn. Bo jak tutaj przygotować harmonogram, gdy tak do końca nie wiadomo, co będzie robione w danej iteracji? Bo jak określić odpowiedzialność za poszczególne zadania, gdy każdy z członków zespołu może sobie je „wziąć” z tablicy? Dla każdego dobrego planisty będą to tylko kolejne elementy do zaplanowania w sposób, aby dało się je zrealizować. Najlepszy nawet planista nie zaplanuje jednej rzeczy – Kierownika Projektu, który stanie się Scrum Masterem, aby ponownie powrócić do roli Kierownika Projektu. Trudno wyobrazić sobie jedną osobę, która będzie pełniła obie funkcje, jeszcze trudniej, że którejś z nich nie będzie w realizowanym projekcie. Pozostaje więc zrównoleglenie tych ról projektowych na czas wykonania produktów projektu, aby zoptymalizować proces włączenia Scruma w tradycyjne metodyki zarządzania projektami.

0 1113
egzamin pmp

Część 1. Jak zapisać się na egzamin certyfikacyjny z PMP®?

By podejść do egzaminu PMP® trzeba spełnić następujące wymagania:

  • Ukończyć 35-godzinne szkolenie z zarządzania projektami
  • Osoby z wykształceniem średnim – udokumentować minimum 5 lat (60 miesięcy) doświadczenia z zarządzania projektami, z których przynajmniej 7,500 godzin spędziliście w roli lidera projektu
  • Osoby z wykształceniem wyższym (co najmniej poziom licencjata) – udokumentować minimum 3 lata (36 miesięcy) doświadczenia z zarządzania projektami, z których przynajmniej 4,500 godzin spędziliście w roli lidera projektu

Wymóg szkoleniowy

 Szkolenie może być dostarczone przez tzw. PMI-REP, czyli firmy szkoleniowe posiadające akredytację PMI®, ale nie musi. Można zapisać się na szkolenie do dowolnej firmy oferującej taką usługę. Jeśli ukończyliście studia podyplomowe z zarządzania projektami, to zajęcia stricte dotyczące metodyki project managementu również mogą zaliczać się do edukacji wymaganej przed zapisaniem się na egzamin. Zarejestrować można również naukę w ramach działalności tzw. PMI Community of Practice®, szkolenia wewnętrzne w firmach, czy kursy e-learningowe.

Różnica polega na tym, że szkolenia odbyte u REPów sprawnie przechodzą przez część audytową, tzn. nie są sprawdzane, będąc już zarejestrowanymi w bazie PMI®.

Kryterium szkoleniowe nie ma żadnego ograniczenia czasowego, tzn. mogliście wypracować te 35 godzin nauki kiedykolwiek i w różnych odstępach czasowych. Po prostu łącznie ma wyjść 35 godzin.

Wymóg doświadczenia

Uwaga! Godziny doświadczenia udokumentowane w aplikacji muszą być zdobyte w ciągu ostatnich ośmiu lat (nie dalej) od składania aplikacji.

Natomiast warunek pełnienia roli lidera projektu jest spełniony gdy braliście udział we wszystkich fazach projektu: w fazie inicjacji, planowania, realizacji, monitorowania i kontroli oraz zamknięcia i wykonywaliście w tej fazie konkretne zadania, więcej szczegółów znajdziecie pod tym linkiem.

Nie musieliście przez cały czas pełnić roli kierownika/lidera projektu, ale te obowiązki powinny stanowić co najmniej 80% wymaganego doświadczenia (7,500 godzin z 5 lat, 4,500 godzin z 3 lat).

I jeszcze jedna istotna uwaga: udokumentowane doświadczenie projektowe nie może się nakładać. Tzn. jeśli pracowałeś na projektach zawodowo i wolontariacko, to i tak nie zarejestrujesz wszystkich godzin. Możesz zarejestrować maksimum 8 godzin dziennie. Co więcej, jeśli uczestniczyłeś w dwóch projektach na raz, możesz zarejestrować tylko jeden z nich.

Jeśli jednak chodzi o doświadczenie w zarządzaniu projektem (rola lidera), tutaj może się ono nakładać. Wszystkie godziny liczą się do wymaganego limitu (również te spędzone nad projektami wolontariackimi).

Ogólne doświadczenie projektowe będziemy rejestrować w miesiącach. Doświadczenie w kierowaniu projektami będziemy spisywać w godzinach. Co więcej, trzeba będzie rozpisać je na poszczególne fazy projektowe (co robiliście w fazie inicjacji, planowania, realizacji, monitorowania i kontroli i zamykania projektu).

Dla każdego doświadczenia trzeba podać osobę, która je potwierdzi i kontakt do niej. Powinien to być Wasz przełożony, manager. Zdaje się, że wystarczy adres e-mail.

Uwaga! Jeśli Wasz wniosek znajdzie się w puli aplikacji podlegającej audytowi, będziecie musieli przesłać do PMI® dokumenty potwierdzające zarejestrowaną edukację i doświadczenie. Najlepiej jest więc przygotować taką dokumentację na zaś. Będzie to certyfikat ukończenia kursu, czy pisemne oświadczenie osoby potwierdzającej Wasze doświadczenie projektowe.

Rejestracja i opłaty

Na egzamin rejestrujesz się poprzez stronę pmi.org. Bezpośredni link do strony logowania tutaj.  Trzeba przyznać, że sama aplikacja jest dość skomplikowana. Jeśli jednak przygotujecie sobie wcześniej wyżej wspomniane informacje, powinno pójść gładko. Od momentu rozpoczęcia aplikacji macie 90 dni na jej ukończenie. PMI® będzie Wam o tym regularnie mailowo przypominał. Jak już ukończycie rejestrację Waszego wniosku, organizacja będzie miała 5 dni na jego przegląd i akceptację. Odbędzie się to na zasadzie potwierdzenia kompletności informacji zawartych w aplikacji. Po otrzymaniu mailowego potwierdzenia, że Wasz wniosek pozytywnie przeszedł proces weryfikacyjny, możecie podchodzić do egzaminu w ciągu zbliżającego się roku. Macie zarezerwowane w tej puli trzy podejścia. Teraz przyszedł czas na wniesienie opłaty.

Koszt certyfikatu PMP® to 555 USD dla osoby spoza organizacji PMI® lub 405 USD dla członka PMI®. O tym co daje i ile kosztuje członkostwo w PMI® obiecuję napisać za jakiś czas w oddzielnym wpisie. Opłaty dokonujecie kartą płatniczą online. Podobnie jak w wielu liniach lotniczych, nie musi to być karta kredytowa. Po dokonaniu płatności możecie rejestrować się na egzamin. Chyba, że otrzymacie informację, że Wasz wniosek został wybrany do audytu. Oznacza to, że macie 90 dni na przesłanie materiałów potwierdzających Wasze doświadczenie. Następnie PMI® ma 5-7 dni na weryfikację tej dokumentacji. Jeśli znaleźliście się w puli „szczęściarzy” przechodzących przez audyt, od momentu pozytywnego przejścia przez dodatkową kontrolę możecie zapisywać się na egzamin w ciągu zbliżającego się roku.

Terminy egzaminów

Na egzamin trzeba rejestrować się poprzez stronę www.prometric.com/PMI. Po wypełnieniu niezbędnych informacji pojawi się kalendarz z terminami do wyboru. Egzamin w Polsce zdawać można w dwóch miejscach:

  • W Warszawie, w autoryzowanym centrum edukacyjnym Integral Technologies Sp. Z o.o., na ulicy Waliców 11
  • W Krakowie, w Inifinity, Centrum Testowym Prometric, na Alei 29-go Listopada

W kalendarzu zwykle wyświetla się kilka dostępnych terminów w tygodniu. Można zapisać się od razu lub z kilku tygodniowym wyprzedzeniem. Raczej jest w czym wybierać. Choć ze względu na zmieniający się nieco egzamin od listopada b.r., w październiku może zrobić się nieco tłoczniej.

Termin egzaminu można odpłatnie zmienić lub odwołać:

  • Jeśli zrobicie to wcześniej niż 30 dni przed terminem egzaminu, nie zapłacicie nic.
  • Jeśli zrobicie to z co najmniej 30-dniowym i nie krótszym niż 2 dni wyprzedzeniem, zapłacicie 70 USD.
  • Jeśli zrobicie do z 2-dniowym lub krótszym wyprzedzeniem, stracicie całą kwotę wpisowego.

To tyle na temat samej rejestracji na egzamin. Nie da się ukryć, że zabiera ona trochę czasu. Przede wszystkim radzę by wcześniej przygotować sobie wszystkie informacje potrzebne do aplikacji.

0 616
stos książek

Miło mi poinformować, że jest już dostępny nowy kurs dla Scrum Masterów :) Tym razem przechodzimy do omówienia konkretnych narzędzi, które mogą być przydatne w codziennej pracy Scrum Mastera czy Agile Coacha.

Przedstawione narzędzia dotyczą zarówno kwestii miękkich, przykładowo nawigowanie po poziomach konfliktu, etapy procesu grupowego, dynamiki grupy, jak i konkretnych sposobów i porad na temat dzielenia elementów Product Backlogu czy szacowania relatywnego.

Dla czytelników bloga specjalna zniżka pod linkiem poniżej :)

https://www.udemy.com/course/narzedzia-scrum-mastera/?referralCode=B34C732175AB9F13A7C4

0 1861
sponsor projektu

Kim tak naprawdę jest Sponsor w projekcie i jaką rolę odgrywa?

Definicja sponsora w projekcie

Zarówno w polskim, jak i w angielskim języku, definicja Sponsora brzmi mniej więcej: ‘osoba, która płaci’. Tymczasem w projekcie Sponsor może decydować o przeznaczeniu funduszy na projekt, ale (uwaga) niekoniecznie! A jeśli nawet w naszym projekcie Sponsor jednocześnie płaci za projekt, to nie ta cecha asygnuje go na tak ważną osobę dla Kierownika Projektu.

W project managemencie Sponsor to jednostka (osoba, grupa, a nawet i organizacja), która zamawia u nas projekt. Sponsorem projektów często bywa reprezentant biznesu, zarząd, jednostka odpowiadająca w organizacji za strategię, bądź wybrany program. Sponsor to często właściciel pomysłu na Twój projekt. Ktoś, kto zauważył potrzebę wykonania pewnego zadania i potrzebuje kogoś kto ten pomysł zrealizuje.

W ten sposób Sponsor staje się dla Ciebie głównym wsparciem w organizacji a jednocześnie i skarbnicą wiedzy o projekcie. To Jemu będzie zależało na tym by projekt się udał. To on pomoże Ci zaadresować wiele problemów w organizacji. Sponsor będzie łącznikiem między Tobą i zespołem projektowym a całą resztą regularnego biznesu odbywającego się na co dzień w firmie. Uwierz mi, nie przeceniam Jego roli…

Za co odpowiada Sponsor?

Jako swoisty łącznik między Tobą a biznesem, Sponsor będzie Cię wspierał w tak istotnych przedsięwzięciach jak:

  • Ustalenie składu Komitetu Sterującego, czyli ciała decyzyjnego w projekcie
  • Zidentyfikowanie osób, specjalistów, zespołów, które będą wiedziały najwięcej o zagadnieniu Twojego projektu i prawdopodobnie docelowo stworzą zespół projektowy
  • Uzyskanie przychylności jednostek mających w organizacji największy wpływ na Twój projekt
  • Upewnienie się, że projekt, którym zarządzasz jest ważny dla managementu najwyższego szczebla w organizacji
  • Zdobycie funduszy i zasobów niezbędnych do prowadzenia projektu
  • zapewnienie, że informacje o zmieniającym się otoczeniu projektu, warunkach, wymaganiach i strategii firmy na bieżąco napływają do zespołu projektowego
  • I wiele innych problemów, którym będziesz musiał stawić czoła jako Project Manager

Chyba już nie masz wątpliwości, że ze Sponsorem lepiej nie zadzierać?

Relacje sponsora i kierownika projektu

Przede wszystkim poczucie, że masz wszystko pod kontrolą i na bieżąco informujesz Go o istotnych dla projektu kwestiach. Oczywiście, by taka sytuacja miała miejsce na początku projektu powinieneś dokładnie poznać swojego Sponsora, wiedzieć co uważa za najważniejsze w projekcie, jakie ma preferencje co do zakresu decyzji, w które ma być włączany oraz co do decyzji, w których zostawia Ci wolną rękę. Załóżmy, że Twój projekt zacznie się opóźniać. Jaką podejmiesz decyzję? Poprosisz członków zespołu by zostali w nadgodzinach, upewniając się, że projekt będzie postępował zgodnie z planem? Czy może poinformujesz Komitet Sterujący o opóźnieniu w realizacji planu? Warto wiedzieć co wolałby Sponsor projektu. Takich decyzji jest w projektach wiele i nie po to nim zarządzamy by o każdą błahostkę pytać Sponsora. Rozmowa na temat priorytetów w projekcie ułatwiłaby podejmowanie takich decyzji. Wyobraź sobie również komfort z jakim zarządzasz projektem gdy wiesz, że Sponsor w pełni Ci ufa, nie musisz konsultować z nim każdej najmniejszej decyzji, a potem nie będziesz musiał tłumaczyć się z każdego kroku w projekcie. Uwierz mi – ogromny komfort!

Niestety, jednocześnie mam złą wiadomość: o ten komfort wcale nie jest łatwo…
A to dlatego, że najczęściej zaczynając projekt wiesz o nim o wiele mniej od swojego Sponsora. To Sponsor doskonale zna i rozumie cel biznesowy. Ha! Często sam ten cel sformułował. A to oznacza dla Ciebie następujący zestaw faktów:
•    Sponsor prawdopodobnie jest specjalistą w dziedzinie, której dotyczy projekt
•    Możliwe, że projekt dotyczy jedynej dziedziny, na której Sponsor się zna. Robi na niej karierę w organizacji. To jest Jego przysłowiowy konik i nikt nie wie więcej na ten temat niż on sam.
•    Sponsor ma w głowie już swój własny plan co do sposobu w jaki projekt powinien być wykonany i plan ten, płynąc z jednej głowy, nie uwzględnia wielu zależności, okoliczności, czy też ograniczeń, które prawdopodobnie wypłyną podczas planowania projektu z całym zespołem
Któryś z czynników powyżej wystąpi na pewno już na początku projektu. Każdy z nich sprawi, że Sponsor nie będzie Ci ufał. Uzna Cię za kogoś, kto ma zrealizować Jego pomysł nie posiadając wystarczającej wiedzy (czyli takiej jak on).  Co więcej, wyobraź sobie reakcję Sponsora gdy po przeprowadzeniu burzy mózgów z zespołem ustalicie, że najlepiej będzie wykonać projekt w inny sposób niż zaplanował sam Sponsor…  Tak, trochę tu demonizuję, ale te reakcje występują w realnym świecie. Często po prostu nie widać ich gołym okiem. Jednak gdy wyczujesz je jako Project Manager, od razu będziesz wiedział jak taką sytuacją zarządzać. Na przykład w sytuacji, w której zespół projektowy wypracował inny plan na dostarczenie końcowego produktu projektu, zorganizuj spotkanie samego zespołu razem ze Sponsorem i na spokojnie, krok po kroku wyłóżcie mu kolejne rozwiązania i argumenty za nimi przemawiające. Nie rób tego na większym forum, w ten sposób Sponsor może odebrać to jako podważenie jego opinii. Jeśli przekonasz do swojego planu Sponsora, masz już 80% szans, że zatwierdzi go Twój Komitet Sterujący.

Oczywiście, ile projektów, tyle scenariuszy. Może też być tak, że Sponsor odda Ci projekt i uznając, że już się ktoś nim zajmuje, skreśli go z listy swoich priorytetów i kompletnie przestanie się nim interesować, prawdopodobnie planując rozliczenie Cię z projektu na sam jego koniec. My, PMy nie możemy dopuścić do takiej sytuacji. Niewątpliwie trzeba tutaj wykazać się sporą charyzmą, uporem, zawziętością. Kierownik Projektu dość często musi przysłowiowo ‘wejść oknem jeśli nie da się drzwiami’. Co powinno pomóc uniknąć takiej postawy Sponsora? Wystarczy, że zaczynając projekt jasno określimy role poszczególnych osób, również Sponsora. Informacje te zostaną udokumentowane a nawet zaprezentowane przed Komitetem Sterującym, a w ten sposób szybko staną się wiążące. Pamiętaj, że to Ty jesteś odpowiedzialny za Projekt jako całokształt. Odpowiadasz za zbudowanie odpowiedniej struktury, organizacji na czas projektu, za zbudowanie zespołu, za stworzenie planu, za komunikowanie, za sukces projektu. Jednocześnie odpowiadasz za to by właściwe osoby podejmowały decyzje w projekcie.

Zdarzało mi się pracować z różnymi Sponsorami. Byli tacy, którzy wystawiali mnie na próbę. Twierdzili, że nie znam się na dziedzinie, w której prowadzę projekt, a potem zlecali małe zadanka by sprawdzić jak sobie poradzę. Z czasem przekonali się, że potrafię dotrzeć do każdej informacji. Przyznam, że nie było łatwo. Gdy kończyłam jeden z projektów usłyszałam od swojego szefa, że moim największym sukcesem był fakt, iż nawiązałam dobre relacje z dwiema Paniami pełniącymi rolę Sponsora w moim projekcie. Był to sukces, ponieważ Panie nie przepadały za Project Managerami. I muszę przyznać, że mnie również na początku przetestowały na wiele sposobów, postawiły w kilku trudnych sytuacjach.

Project Manager pracuje w różnych organizacjach, a w tych organizacjach i ich działach panuje swoista kultura, odmienne zasady. Najważniejsze dla nas PMów to pamiętać jaka jest nasza rola, jasno komunikować ją wszystkim i tego się trzymać. Jednej ze wspomnianych wyżej Pań zdarzyło się pewnego razu na telekonferencji zapomnieć, że również w niej uczestniczę. Wypowiadając się na temat innego Kierownika Projektu skomentowała: ,… She is stupid… As all project managers are’. W tym spotkaniu wirtualnym brał udział również mój szef, Program Manager. Oczywiście dość szybko Pani Sponsor zorientowała się jaką popełniła gafę. Na końcu przeprosiła wszystkich za swoje słowa. Jednak wrażenie zostało. Wiedziałam co myśli o Project Managerach: była zawiedziona, że nie są specjalistami i nie wykonują prac projektowych sami, w zamian – potrzebują do tego zespołu.  Jak już wcześniej wspomniałam, nasze relacje znacznie się polepszyły po pewnym czasie. Ten proces kosztował mnie wiele asertywności. Musiałam robić dokładnie to co należy do mojej roli i na każdym kroku udowadniać, że robię to doskonale. W innym przypadku groziło mi zostanie sekretarką Pani Sponsor.

Zarządzałam również projektem, w którym Sponsor podjął szereg złych decyzji, widocznych dla mnie od początku. Projekt był bardzo ważny dla strategii firmy, polityczny, wymagał wiele dyplomacji. Polegał na zamknięciu jednego z działów firmy w zachodniej części Europy i otwarciu tegoż działu w Polsce. Jak już się zapewne zorientowaliście, jedni tracili pracę po to, by inni mogli zostać zatrudnieni. Szybko zrozumiałam, że moje główne zadanie w projekcie to wprowadzenie jak najwięcej dyplomacji  i właściwych zachowań. Musiałam mocno hamować zachowania po stronie Sponsora przyjmującego funkcję, uświadamiać managerów, że ludzie po drugiej stronie tracą pracę, że ten projekt dla durgiej strony oznacza coś innego. Oczywiście druga strona była równie trudna do zarządzania, rzucała wiele kłód pod nóg by projekt nie mógł zakończyć się sukcesem. Praca nad projektem wymagała wzajemnego zaufania, co szybko okazało się niemożliwe. Dużą rolę odegrała tutaj postawa Sponsora z Polski: brak zrozumienia drugiej strony, wrogie nastawienie od samego początku projektu, podejrzliwość wobec drugiej strony… Ten projekt prawie się nie udał. Sponsor swoją postawą tak bardzo zepsuł relacje w projekcie, że współpraca między stronami praktycznie nie istniała. Doszło do tego, że gdy projekt zupełnie się nie udawał, Sponsor po polskiej stronie postanowił uznać go za porażkę, oczywiście obwiniając drugą stronę. Taka odpowiedź nie była możliwa do zaakceptowania dla nikogo. Na projekt wydano do tej pory za dużo pieniędzy. Zmieniono Sponsora po polskiej stronie, tzn. zmieniono kompletnie dział, do którego miała zostać przeniesiona dana funkcja. Nowy Sponsor zastosował podejście pokojowe, skłonne do negocjacji. Nie był to środek zaradczy, który natychmiastowo zadziałał na drugą, bardzo wrogo nastawioną stronę, ale udało się. Z półrocznym opóźnieniem zakończyliśmy projekt. Nauczył mnie jak moderować trudne spotkania, jak negocjować, jak ‘sprzedawać’ pewne rozwiązania by tworzyć sytuację win-win w projekcie. Nauczył mnie również, że jako Project Manager nie zmienię kultury organizacyjnej i sposobu myślenia w całej firmie. Muszę zarządzać tym, czym mogę i trzymać stery mocno w swoich rękach!

Podsumowanie roli Sponsora Projektu

  1. Upewnij się, że wiesz kto jest Sponsorem Twojego projektu (pracę często zleca nam pośrednio szef Biura Projektów i wtedy może to nie być oczywiste)
  2. Zbuduj dobre relacje ze Sponsorem na początku projektu.
  3. Zrozum, który cel projektu jest najważniejszy dla Sponsora, co Sponsor zyska gdy projekt się zakończy.
  4. Zdobądź zaufanie Sponsora.
  5. Ustal jasne zasady co do stopnia zaangażowania Sponsora w projekt.
  6. W trakcie trwania projektu na bieżąco informuj Sponsora o postępach prac, pojawiających się problemach, ryzykach, czy zmianach, które planujesz przedyskutować na większym forum.
  7. Na koniec projektu upewnij się, że Twój Sponsor zaakceptował dostarczony produkt, usługę i uznaje status projektu za zamknięty.

To tyle z najważniejszych lekcji, których osobiście doświadczyłam w projektach a propos roli Sponsora

0 720
skalowanie agile

Ci z Was, którzy znają mnie nie od wczoraj dobrze wiedzą, że nie jestem zwolennikiem żadnej z coraz popularniejszych „metod” skalowania Agile. Często wypowiadam się na ten temat i przeważnie negatywnie.

„Jeśli skalujesz Agile to robisz to źle.”

Wszystkie znane mi do tej pory metody i frameworki z SAFe (Scaled Agile Framework), Scrum of Scrums  i Agility Path na czele próbują narzucić rożne zasady i reguły, które maja być mniej lub bardziej uniwersalne dla każdej organizacji. To po prostu nie ma prawa działać.

Miałem okazję przez ostatnich kilka lat pracować z wieloma organizacjami, niektóre z nich były całkiem duże. Na tyle duże, że musiały zmierzyć się z problemem skalowania. Najczęstszym błędem który podczas takich prób zmierzenia się ze skalowaniem widziałem była próba zastosowania danej metody skalowania bez uprzedniego zastanowienia się nad problemami, które chce się rozwiązać.

Większość promowanych „metod” ze znajomości, których można sobie zrobić (kupić) różne certyfikaty których ładnie brzmiące nazwy możemy sobie później wpisać na linkedin według mnie nie rozwiązuje podstawowych problemów, lecz wręcz przeciwnie poprzez swoją pozorną prostotę i obietnicę naprawienia wszechświata generują więcej problemów niż rozwiązują. Nie – nie neguję wartości tych metod (nie wszystkich i nie całkowicie – tylko trochę) – niektóre z nich świetnie działają w pewnym kontekście. Niektóre pojedyncze elementy tych metod bazują przecież na prawdziwych wartości Agile i Lean jedyne co jest z nimi nie tak to próba zbudowania z nich zamkniętego narzędzia o uniwersalnym zastosowaniu.

Ktoś zarzucił mi nawet że jestem egoistą który twierdzi, że ludzie pracujący w dużych organizacjach nie zasługują na Agile. Hmm, niektórzy ludzie, w niektórych organizacjach – tacy, którzy nie chcą niczego zmienić, albo boją się zmian być może nie tyle nie zasługują na Agile  co Agile mógłby im zaszkodzić więc to raczej nie jest dla nich.

Powyższe nie oznacza, że nigdy z problemem skalowania się nie mierzyłem i nie mam w tym żadnego doświadczenia. Osobiście do tematu skalowania zawsze podchodziłem na kilku płaszczyznach i za każdym razem, w każdej organizacji wygląda to zupełnie inaczej, niemniej jednak często powtarzają się pewne tematy.

Po co skalować Agile?

Pierwsze zadawane przeze mnie pytanie tyczy się tego dlaczego dana organizacja jest na tyle duża, że potrzebuje jakiejś metody skalowania?

To pytanie może wydawać się proste, ale w większości przypadków próba zastanowienia się nad odpowiedzią prowadzi do źródeł wielu innych problemów, których rozwiązanie pozwala uniknąć potrzeby zastosowania metod skalowania. Czasem okazuje się, że wystarczy organizację podzielić na mniejsze, bardziej niezależne komórki skupione wokół poszczególnych produktów lub komponentów i okazuje się, że niczego nie trzeba skalować. Czasem dochodzimy do wniosku, że problemy, które chcemy rozwiązać są gdzieś indziej niż adresują to różne metody skalowania i wystarczy właśnie tam skupić swoją energię. To co niewątpliwie jest potrzebne w każdej organizacji bez względu na wielkość to określona metoda wspomagająca proces Continuous Improvements.

Co to znaczy skalować?

Drugie pytanie dotyczy tego co rozumiemy przez skalowanie?

Skalować możemy organizację zapewniając odpowiedni framework wymiany wiedzy oraz zapewniania transparentności i możliwości ciągłej inspekcji i adaptacji na wielu (wszystkich?) poziomach organizacji. Każda organizacja jest inna i narzucanie tutaj odgórnie struktury (tak jak próbuje to zrobić SAFe) jest raczej wątpliwie skuteczne. Czasem oczywiście (zwłaszcza gdy mamy do czynienia z chaotyczną organizacją o wątpliwej strukturze) narzucenie struktury jest świetnym posunięciem – tutaj SAFE z pewnością się sprawdza (przyznam, że jako konsultant poleciłem kilka razy SAFe właśnie w takich przypadkach).

Skalowanie to również skalowanie produktu. Jeśli mamy do czynienia z monolitycznym produktem, z dużym legacy i długiem technicznym to wartość wdrożenia jakiejkolwiek metody skalowania będzie raczej znikoma. Często do tego problemu docieramy zadając pierwsze pytanie powyżej – to taka architektura często jest przyczyną nadmiernego wzrostu organizacji.

Trzecie pytanie to w zasadzie obserwacja tego jak w tej chwili wygląda organizacja i w jaki sposób podejmowane są decyzje?

Wizualizacja tego procesu często jest już wystarczającym krokiem w kierunku poprawy i usprawnień. Value Stream Mapping i zaangażowanie odpowiednich osób w dyskusję może bardzo pomóc.

Następnie jest czas na pytania o to czy istnieje coś takiego jak wizja organizacji i wizja produktu? Jak ta wizja, misja i deklarowane wartości są reprezentowane przez realne, codzienne działania? Czy wizja jest klarowana i transparentna? Czy wszyscy w organizacji są jej świadomi? Czy mają na nią wpływ? Czy ludzie w organizacji utożsamiają się z wartościami deklarowanymi przez organizację.

Mając jasną wizję produktu możemy ją dekomponować na pracę dla poszczególnych zespołów produktowych. Mając jasną wizję organizacji możemy ją dekomponować i uskuteczniać w pętli Inspect & Adapt na poziomie każdego zespołu i całej organizacji.

W powyższy (opis mocno uproszczony) sposób staram się pracować z organizacjami już od dłuższego czasu dlatego też wczorajszego wieczoru zainteresowała mnie prezentacja mówiąca o „nowym” podejściu do skalowania: Scrum at Scale proponowana przez Scrum Inc. Tak jak w tytule jest to niewątpliwie światełko w tunelu dla osób poszukujących odpowiedzi na pytanie jak skalować organizację. Czy to światełko okaże się oczekiwanym rozwiązaniem wielu problemów czy może raczej nadjeżdżającym pociągiem? Myślę, że wszystko zależy od tego jak to dalej się potoczy i w którym kierunku popchną tą „metodę*” jej „twórcy**”. Na szczęście nie  ma (jeszcze) zmyślnej ścieżki certyfikacji co moim zdaniem daje nadzieję, na to, że ktoś faktycznie chce pomagać organizacjom a nie tylko i wyłącznie trzepać kasę kopiując model szkoleń i certyfikacji CSM i PSM z przed lat (za pierwszym razem to miało sens i wnosiło wartość – teraz certyfikatów na rynku zdaje się być kilkadziesiąt razy więcej niż możliwych do zastosowania w praktyce metod).

Z pewnością w najbliższym czasie będę chciał się bliżej przyjrzeć tej metodzie. Być może za jakiś czas przeczytacie o tym jak bardzo się myliłem i to tylko kolejny marketingowy BS, który ktoś próbuje wcisnąć ludziom z problemami zamiast pomóc im naprawdę te problemy zdiagnozować i rozwiązać…

 

*Scum at Scale cieżko jest mi nazwać metodą – to raczej zbiór kilku celów czy problemów które każda organizacja powinna zastosować. Ciekawą ideą jest wspomniana modułowość  proponowanego rozwiązania.

**Nie jest to też nic nowego bo podstawy są zbliżone chociażby do tego co można było znaleźć w początkowych wersjach SAFe, na pierwszy rzut oka widać też, że twórcy dużo inspiracji czerpią od takich autorów i myślicieli ze świata Lean i Agile jak chociażby Mary i Tom Poppendieck (Lean Software Development) czy Tom Gilb (Evo Method)