Co zrobić gdy toniesz w morzu zadań? Jak priorytetyzować pracę zespołu?

Toniesz w morzu zadań? Właśnie kończy się piątek a Twoja lista „to do” na ten tydzień wcale nie zmalała? Co zrobić?

Metody są różne:

  1. Wyrzuć listę do kosza wychodząc dziś punkt 17:00 z biura. W poniedziałek zacznij od nowa, czekając aż niektóre zadania z listy niejako zgłoszą się do Ciebie same: a to przez rozzłoszczonego szefa, a może przez niezadowolonego klienta, albo też przez sfrustrowanego Ciebie we własnej osobie. A może zadania wcale nie dadzą Ci spokojnie spędzić weekendu?

Tej metody stanowczo nie polecam.

  1. Zostań dziś w biurze do północy. Zrób wszystko by wyczyścić listę. Możliwe, że część zadań wykonasz na przysłowiowe półgwizdka, a części i tak nie da się z różnych powodów niezależnych od Ciebie dziś zrobić. Zawsze możesz jednak zostać po godzinach by uśpić swoje wyrzuty sumienia i przynamniej porozsyłać wszystkim maile, tak by każdy temat był niejako przez Ciebie „zaopiekowany”, jeszcze w tym tygodniu.  W poniedziałek wrócisz do pracy i zajmiesz się wszystkim od nowa.

Tej metody również szczerze nie polecam.

  1. Zastosuj Macierz Eisenhowera.

W tym celu uprzątnij swoje biurko. Pozbądź się trzech kubków po kawie, luźnych kartek w postaci brudnopisów, żółtych karteczek oblepiających Twój monitor z zadaniami do wykonania, wycisz telefon, zdjęcie z wakacji możesz jak najbardziej zostawić 😉

Weź dwa głębokie wdechy. Trzeci też nie zaszkodzi.

Spójrz w okno.

Jeśli nadal czujesz się spięty, zrób sobie 1-minutowy spacer, najlepiej z zaczerpnięciem świeżego powietrza.

Wróć do biurka. Usiądź i stwórz listę wszystkich zadań, które planowałeś wykonać w tym tygodniu. W tym celu możesz zweryfikować swoją aktualną listę, która spędza Ci sen z powiek.

Lista może mieć 6 pozycji, 20 albo 100. To nie ma znaczenia.

Jak już będzie gotowa, zastanów się, które z elementów na tej liście są PILNE. Pilne będą zadania z najkrótszym terminem realizacji. Często zaplanowane na dziś, a nawet na wczoraj. Niewykonanie tych zadań może, ale nie musi wiązać się z poważniejszymi konsekwencjami. Najważniejszy jest termin, a właściwie jego bliskość. Wszystkie z zadań na liście określ jako pilnie lub niepilne. Nie ma tutaj taryfy ulgowej. Myśl tylko o terminie.

W drugiej kolejności zastanów się które z tych zadań są WAŻNE. Jakie zadania będą ważne? Odpowiedź na to pytanie nie jest już taka zero-jedynkowa jak w przypadku pilności. Jeśli masz do czynienia z projektem, rozważ ważność zadania w odniesieniu do celu projektu, do korzyści jaką projekt ma zrealizować. Jeśli dane zadanie wpływa na cel projektu, jest ważne. Gdybyś nadal miał wątpliwości możesz wesprzeć się dodatkowymi pytaniami (tzw. pytaniami kartezjańskimi):

  1. Co się stanie, jeśli to zrobisz?
  2. Co się stanie, jeśli tego nie zrobisz?
  3. Co się nie stanie, jeśli to zrobisz?
  4. Co się nie stanie, jeśli tego nie zrobisz?

Oczywiście pytania możesz modyfikować odpowiednio do kontekstu, np. Które wymaganie klienta zostanie spełnione, jeśli to zrobię? Który cel nie zostanie zrealizowany, jeśli tego nie zrobię? Jakie ryzyko się zmaterializuje, jeśli tego nie zrobię?

Wszystkie zadania na Twojej liście muszą być opisane jako ważne lub nieważne, pilne lub niepilne.

W następnym kroku umieszczasz je na macierzy Eisenhowera:

Jak priorytetyzować zadania w zespole? Anna Jaszczołt zarzadza-projektami.pl

Jeśli w tym momencie pomyślałeś o prezydencie Stanów Zjednoczonych, strzeliłeś w dziesiątkę. To właśnie Eisenhowerowi, prezydentowi USA, dowódcy wojsk amerykańskich, człowiekowi wybitnie efektywnie zarządzającemu swoim czasem przypisuje się prawa autorskie do wspomnianej macierzy (nazywanej również macierzą priorytetów). Eisenhower oczywiście nie poprzestał na klasyfikacji zadań, ale również sformułował następujące zasady:

  1. Ważność jest istotniejsza od pilności.
  2. Ważne zadania, należy wykonywać zanim staną się pilne.
  3. Jeśli zadanie nie jest ani ważne, ani pilne, nie zajmuj się nim.

W myśl tej zasady wzór na priorytetyzowanie zadań w projekcie mógłby wyglądać następująco:

Jak planować zadania zespołu? Jak zdecydować co jest najważniejsze? Anna Jaszczołt, zarządzanie projektami

Niech posłuży Wam jako ściąga. U mnie wisi na ścianie nad biurkiem – serio! 🙂

Całe zadanie możecie wykonać razem z zespołem projektowym – gorąco polecam! Szybko okaże się jak różnie interpretujecie pilność i ważność zadań. Warto stawić temu czoła. Można to zrobić wspólnie z właścicielem biznesowym, Product Ownerem, klientem, sponsorem.

Używam tego narzędzia gdy tylko czuję, że zaczynam nieefektywnie spędzać czas, żonglując między kilkoma zadaniami naraz. Albo gdy nie mogę porozumieć się z Klientem co do priorytetów w projekcie, bądź co do wymagań wobec produktu.

O czym warto pamiętać stosując macierz Eisenhowera?

  1. Jest to obrazek sytuacji w projekcie. Nie jest to konkretna miara, statystyka, czy wyliczenia ze wzoru.
  2. Zadania, które dzisiaj są ważne i pilne jutro mogą być mniej ważne i zupełnie niepilne. Wszystko zależy od perspektywy i zmieniających się okoliczności.
  3. Z dwóch ważnych zadań jedno może być ważniejsze, umieszczenie ich w odpowiednim miejscu na macierzy pozwala zarządzić również tym aspektem.

Idąc krok dalej, przy nieskomplikowanym projekcie, można by taką macierzą potraktować nasz product backlog i już wiemy czym zająć się w pierwszej iteracji. Szybko też zidentyfikujemy najbardziej krytyczne obszary. Będą dotyczyły wymagań ważnych i pilnych, ale niemożliwych do zrobienia w pierwszych iteracjach. O nich też warto wiedzieć, które to są. Dzięki temu możemy efektywnie zarządzać naszymi interesariuszami.

Ciekawe czy Wam się przydało? 🙂

Anna Jaszczołt

 

PMP® – nie tylko dla kierowników projektów w NASA

Jest i on! Kolejny przedłużony certyfikat PMP®. Pierwszy z nowym nazwiskiem. To już 6 lat odkąd stałam się jego szczęśliwą posiadaczką. Kosztował mnie wiele wysiłku. Do tego stopnia, że wracając z Warszawy płakałam w pociągu ze zmęczenia i ulgi. No ale tak to bywa gdy przygotowujemy się do niego w dwa tygodnie (wieczorami), w tym ostatnie 48 godzin na okrągło, bez snu. Nikomu nie polecam!

Kiedy stosować PMBoKa?

 

Egzamin zdałam, zgodnie z zasadą 3Z – szybko zapomniałam. PMBoKa zrozumiałam w ciągu kolejnych lat praktyki. A już totalne obłaskawienie wiedzą i rozumieniem nastąpiło gdy zaczęłam prowadzić szkolenia przygotowujące do egzaminu PMP®. Jak mawiał Einstein: Jeżeli nie potrafisz czegoś prosto wyjaśnić – to znaczy, że niewystarczająco to rozumiesz. Trzeba było sprostać zadaniu.

Szkoda, że nadal spotykam wiele osób, które twierdzą, że standardy opisane w PMBoKu nadają się do projektów powadzonych w NASA. Tak ich nauczono na szkoleniach. Tymczasem PMBoK to takie wdzięczny, elastyczny zapis.  Nie róbcie mu krzywdy, drodzy trenerzy!

PMBoK to zbiór dobrych praktyk, narzędzi, spośród których możesz wybrać te, pasujące do Twojego projektu.

Anna Jaszczołt, PMP

Nie musisz stosować analizy Monte Carlo jeśli wdrażasz kolejnego ERPa. Niekoniecznie przyda Ci się znajomość Six Sigmy gdy zarządzasz projektem zmiany organizacyjnej. Nie musisz rzeźbić oficjalnego planu komunikacji gdy w Twoim zespole pracuje kilka osób. Ani tworzyć analizy jakościowej ryzyk, gdy zidentyfikowałeś ich 5, bo Twój projekt nie jest skomplikowany itd… itd… itd…

Aurea mediocritas kochani, jak mawiał klasyk Horacy.

A jakie są Wasze doświadczenia ze stosowania standardów zapisanych w PMBoKu? Zapraszam do dyskusji w komentarzach. Ciekawam ja, co stosujecie, a przed czym się wzbraniacie.

Anna Jaszczołt

PS. Przy okazji przypominam swój wpis o tym jak przedłużyć certyfikat PMP. Przeczytacie tutaj.

 

7 sekretów skutecznego Kierownika Projektu

7 sekretów

Ten moment – kiedy chcesz koniecznie rozwiązać temat, a nie da się od razu. Więc robisz cokolwiek, np. odpisujesz na maila. Piszesz o tym co wiesz na dzień dzisiejszy. Nie wnosisz wiele, ale przecież jakoś zareagować musisz by sprawić wrażenie, że masz wszystko pod kontrolą. Pchasz taczkę, ale pustą.

Miałam kiedyś takiego kolegę w pracy, nazwę go Rakietą. Rakieta działał ekspresowo, potrafił lecieć w tempie błyskawicznym prosto do celu. Rozwiązywał problemy tu i teraz, aż ludzie z którymi pracował byli do pewnego stopnia przerażeni tempem i konkretami jakie im serwował.

Sama czasem łapię się na pokusie tego popularnego myślenia:

– Nie zadzwonię o 9 rano, dam człowiekowi chwilę na rozruch;

– Nie będę od razu naciskała na działania, poczekam aż zespół się przyzwyczai do nowiny i potem zadziałamy;

– Podejmę decyzję jutro, może dzisiaj jeszcze coś się wydarzy.

Nie mylcie tego z prokrastynacją. Tutaj chodzi o reagowanie, ale totalnie nieskuteczne. Zabieranie się za coś, po to by się zabrać, niekoniecznie z jakimś wymiernym efektem. To tak jak wpisać na listę rzeczy do zrobienia coś, co tak naprawdę możemy załatwić od razu:

– zadzwonić do urzędu,

– wypełnić wniosek,

– przeczytać umowę,

– porozmawiać z szefem,

– ustalić coś z zespołem.

Tak, jestem za planowaniem dnia i niepozwalaniem na to by tzw. bieżączka rozbiła mi dzień pracy. Wszystko w rozsądnych proporcjach.

Tymczasem często wkrada się myślenie w stylu: nie mogę zrobić czegoś teraz, więc wpiszę to na swoją listę rzeczy do zrobienia. W mojej głowie powstaje niebezpieczne przekonanie, że coś już z tym problemem zrobiłam – wpisałam go na listę by się nim zająć (sic!). Najzabawniejsze jest to, że zanim zabiorę się za tę listę niejednokrotnie problem jest nieaktualny. Jeśli rozwiązał się sam – fantastycznie! Gorzej gdy ktoś go rozwiązał za mnie…

W projektach często chowamy się za mailami, prezentacjami, raportami, spotkaniami i tabelkami. Komunikujemy co wiemy i rozkładamy ręce w bezsilności:

– Podejmiemy tę decyzję, gdy Pan x wróci z wakacji.

– Zajmiemy się tym problemem gdy będziemy w pełnym składzie.

– Zrobimy budżet projektowy gdy będziemy znać pełen zakres itd.

Tymczasem sekretem skutecznych Project Managerów, których podziwiają moi klienci jest bycie MISTRZEM DZIAŁANIA, REAGOWANIE NATYCHMIAST. Dobry Kierownik Projektu stoi po stronie rozwiązania i działania. Każdy problem próbuje od razu rozwiązać, nie odkładając go na bliżej nieokreślone „później”. Zamiast: pisania maila, ustawiania spotkania na piątek, wysyłania raportu pt. „to co wiem na dziś”, często wystarczy po prostu zadzwonić i porozmawiać z kilkoma osobami i sprawa załatwiona.

Są takie kultury organizacyjne (sama w takiej pracowałam), w których pracownicy przytłoczeni nadmiarem spotkań i maili nie mają czasu odbierać telefonów, odbywać spotkań ad hoc i na bieżąco wypracowywać rozwiązań pojawiających się problemów. W ciągu dnia biegają ze spotkania na spotkanie, odpisują na maile, a na biurku leży lista z zadaniami do wykonania, która rozrasta się z godziny na godzinę. Na koniec dnia zostają z tą listą i poczuciem „dzisiejsza praca dopiero przede mną”.

Tkwimy w planie spotkań, który powstał tydzień, dwa tygodnie temu, tymczasem rzeczywistość zgotowała nam zupełnie inne wyzwania od tych wczorajszych (nie mówiąc o tych z zeszłego tygodnia). Ile razy zorganizowałeś spotkanie, którego temat po tygodniu okazał się nieaktualny w dniu spotkania?

Pocieszę Was, mój kolega, Rakieta właśnie w takim otoczeniu działał i nie przeszkadzało mu działać po swojemu. Nie czekał na odpowiedź na maila dniami, nie czekał na miejsce w kalendarzu na ważne spotkanie decyzyjne. Po prostu działał, organizował, załatwiał. Nie spotkałam nigdy później kogoś bardziej skutecznego niż on. Jego podejście baaaaardzo dużo mnie nauczyło. Miało też wady – wiele osób nie chciało z nim pracować. Bali się, że naprawdę będą musieli zrobić to, co trzeba. Kochali go szefowie. Z różnych przyczyn (również tu nie wspomnianych) nienawidziły go zespoły.

Jakie płyną z tego wnioski?

  1. W swych działaniach postaw na bezpośredni kontakt.
  2. Konfrontuj problem od razu.
  3. Myśl rozwiązaniem, nie problemem.
  4. Nie chowaj się za raportem, tabelką, prezentacją, kolejnym spotkaniem, nieobecnością jednej osoby w biurze, czy na spotkaniu.
  5. To że w Twojej firmie panuje pewna kultura pracy, nie oznacza, że musisz działać tak jak wszyscy*.
  6. Analizując problem, zastanów się co możesz zrobić by rozwiązać go już dziś.
  7. Zanim wyślesz maila albo zorganizujesz spotkanie – przemyśl to dwa razy.

Gdy zaczniesz postępować w ten sposób, inni bardzo szybko zarażą się Twoim zachowaniem. Zdziwisz się jak szybko ludzie zaczną być skuteczni. Polecam wypróbować jeszcze dziś, przy pierwszym napotkanym problemie.

                                                                                                               Anna Jaszczołt

 

*Dotknęłam tu głębszego tematu, jakim jest kultura organizacyjna, w której pracujemy. Uważam, że nie zawsze powinniśmy tkwić w otoczeniu, które nam nie odpowiada mając nadzieję, że zmienimy świat. „Zmiana zaczyna się od Ciebie” – tak, w rozsądnych okolicznościach. O tym w oddzielnym wpisie.

PS. Dołączam ściągę w zweryfikowanej postaci syntetycznej:

5 zasad skutecznego Kierownika Projektu-5

MoSCoW – czyli jak nadać znaczenie wymaganiom w projekcie.

MoSCoW to metoda priorytetyzowania zakresu projektu, którą poznałam stosunkowo niedawno – jakieś dwa, trzy lata temu – i od razu pożałowałam, że nie znałam jej wcześniej. Odkąd zaczęłam stosować MoSCoW życie moje i klientów mych stało się relatywnie o parę ciężkich westchnień lżejsze.

MoSCoW

MoSCoW to narzędzie pierwotnie stosowane przy priorytetyzacji wymagań do oprogramowania. Swoje korzenie ma w metodyce DSDM (Dynamic Software Development Method). To jedna z pierwszych (jeśli nie pierwsza) metod Agile. Powstała w 1994 roku kiedy to jeszcze iteracyjne podejście do wytwarzania produktu brzmiało jak pomysł polecenia klientowi by wykąpał się zimą w przeręblu w Wiśle, a sama nazwa Agile po prostu nie istniała. Ale o tej metodyce bardzo chętnie, innym razem 😉 Skupmy się na narzędziu.

MoSCoW daje nam przepis na posortowanie wymagań projektu odpowiednio co do istotności.

Kategorie istotności wymagania

MUST haves (muszą być) – zbiór wymagań inaczej nazywany Minimum Usable SubseT. Mówimy zatem o wymaganiach, bez których projekt nie ma sensu. W przypadku oprogramowania będą to funkcjonalności bez których nowa aplikacja nie ma szans zaistnieć, a bynajmniej nie może spełnić swojej podstawowej użyteczności. Dla przykładu, w projekcie bankowości mobilnej byłaby to możliwość logowania na konto przez klienta.

SHOULD haves (powinny być) – zbiór wymagań, które nie są krytyczne dla projektu, jednak są istotne, wartościowe z punktu widzenia użytkownika. Na przykład, w naszym projekcie bankowości mobilnej mogłaby to być możliwość zapisywania odbiorców. Bez tej funkcji nadal mogę robić przelewy z każdego urządzenia na całym świecie. Jednak opcja tworzenia listy odbiorców to standard, którego oczekuje każdy użytkownik.

COULD haves (mogłyby być) – zbiór wymagań, które są mile widziane i mogłyby zostać zapewnione bez większego wysiłku, czy kosztu. Jeśli pojawi się zagrożenie nie skończenia projektu na czas, te wymagania jako pierwsze nie zostaną zrealizowane. W przypadku naszego przykładu bankowości mobilnej mogłaby to być dodatkowa funkcja kalkulatora na rachunku mobilnym.

WON’T haves (nie będzie) – zbiór wymagań, które chcemy mieć zrealizowane, jednak nie w tej fazie, nie w tym projekcie, nie w tym sprincie. Inaczej klasyczne out of scope.

Kiedy stosować MoSCoW?

MoSCoW można zastosować zarówno do zakresu całego projektu, jak i do zakresu kolejnych faz, czy sprintów. Narzędzie to jest obecnie bardzo popularne wśród zespołów działających zwinnie, choćby scrumowo. Dzięki niemu, możemy tworzyć elastyczne plany z naturalnie wbudowanym buforem. Takim zapasem stają się wszystkie wymagania z kategorii Could haves i Should haves. Zatem MoSCoW to narzędzie idealne dla projektów, w których działa timeboxing.

Z kim klasyfikować istotność wymagania?

Dla praktyków zarządzania projektami to pytanie z kategorii pytań „co się kręci: słońce, czy ziemia”.  Jednak by potraktować temat holistycznie, powiedzmy sobie wprost. Wymagania biorą się od interesariuszy, a zatem od: klientów, użytkowników, zespołów realizacyjnych, instytucji regulujących rynek, na którym funkcjonuje nasz produkt, konkurencji itd. Pamiętajcie więc, by nie tylko zebrać od nich wymagania, ale i zapytać, przeanalizować istotność wymagań z ich punktu widzenia.

Skąd wiedzieć co jest SHOULD, a co COULD?

Przychodzę na spotkanie i mówię: słuchajcie, tu jest taka metoda MoSCoW, które z Waszych wymagań to Must haves? STOP, nie do końca to tak wygląda. W dojrzałym zespole scrumowym na pewno tak. Ale u klienta, dla którego prowadzę projekt po raz pierwszy lub u klienta spoza branży IT takie rozpoczęcie miałoby dwa skutki:

  • Kompletna konsternacja,

po chwili otrząśnięcia:

  • Wszystkie wymagania sklasyfikowane jako MUST haves.

W myśl zasady „dostosuj swój komunikat do odbiorcy”, czasem nawet nie wymieniam nazwy narzędzia. Jeśli zapytam, które z wymagań jest najważniejsze, zazwyczaj dowiaduję się, że wszystkie są krytyczne dla projektu. Klientom bardzo często wydaje się, że wszystko jest ważne i pilne.

Pamiętajcie: takie odpowiedzi dostajecie, jakie zadajecie pytania.

Oto przykłady pytań, które można zadać:

MUST haves

Bez czego ten produkt nie zadziała?

Kiedy ten produkt nie będzie miał sensu?

Które funkcjonalności są krytyczne z punktu widzenia użytkownika?

Które wymagania bezpośrednio spełniają cel użytkowy produktu?

Które wymagania realizują korzyść biznesową?

Bez których wymagań produkt nie będzie spełniał zasad bezpieczeństwa?

Bez których wymagań produkt nie będzie zgodny z przepisami?

SHOULD haves i COULD haves

Aby uzyskać te dwie kategorie, najlepiej jest przejrzeć listę MUST haves i do każdego (czasem ponownie) zadać pytanie:

Czy bez tej funkcjonalności produkt będzie działał?

Kolejna metoda to uszczegółowienie MUST haves, a dokładnie: rozpisanie ich na mniejsze wymagania. W ten sposób, w myśl zasady granulacji, otrzymamy również SHOULD haves i COULD haves.

Różnica między tymi dwoma kategoriami jest taka, że brak realizacji SHOULD haves jest bolesny w skutkach. Zazwyczaj niesie ze sobą jakieś konsekwencje, np. musimy napisać procedurę, zrobić dodatkowe testy, naprawić coś innego. Pominięcie COULD haves nie wiąże się z poważniejszymi konsekwencjami (poza nieco niezadowolonym zamawiającym, który chciał wszystko).

WON’T haves:

Czego nie zrobimy tym razem?

Co możemy zaadresować w kolejnej fazie projektu?

Ile MUST, a ile reszty?

Dobre praktyki mówią, że powinniśmy dążyć do podzielenia listy wymagań na:

60% MUST haves

20% SHOULD haves

20% COULD haves

W ten sposób tworzymy sobie wspomniany wcześniej bufor. Jesteśmy w stanie zobowiązać się do ukończenia np. sprintu w danym terminie wiedząc, że w razie niedoszacowań, problemów, będziemy mogli zrezygnować z części COULD haves, a w najbardziej czarnym scenariuszu dowieziemy jedynie MUST haves. Skąd te proporcje? Otóż statystyki mówią, że minimum, które realizujemy w większości projektów, to właśnie 60-65% pierwotnego planu.

Konieczność aktualizacji

Oczywiście Wasz MoSCoW nigdy nie będzie wykuty w skale. Będzie się zmieniał tak często, jak często klient zmienia zdanie, jak często zmienia się otoczenie projektowe. Już na początku projektu warto ustalić cykle, w których będziecie przeglądać listę wymagań celem aktualizacji priorytetów.

Korzyści ze stosowania MoSCoW

MoSCoW to narzędzie szczególnie przydatne w metodykach zwinnych, w których mamy do czynienia z timeboxami. Chroni czas realizacji projektu i jakość produktu. Najpierw skupiamy się na tym, co krytyczne, bez konieczności obniżania jakości wykonania by zdążyć również z pozostałymi funkcjonalnościami. MoSCoW idealnie sprawdzi się w projektach regulowanych, w których termin końcowy projektu jest z góry określony. Można też go zastosować wobec budżetu, w projektach, w których koszty stanowią nieelastyczne ograniczenie.

——————————

Pisząc ten artykuł też miałam swoje wymagania:

Must – ma być opisane narzędzie, mają być przykłady, narzędzie praktyczne w rzeczywistości, nie w teorii, narzędzie uniwersalne, poprawna polszczyzna

Should – załączony fajny obrazek do tekstu

Could – nie powinno być dłużej niż 2 strony w Wordzie

Won’t – tym razem nie ma być o zarządzaniu zespołami, strategią, ani o komunikacji

Mój timebox to był wieczór. Zaczęłam po północy i jest prawie 5 rano, więc wyszło trochę dłużej, ale w ostatecznym terminie – przed wyjazdem na urlop – się zmieściłam 😉

Jedno mnie teraz martwi – moje wymagania, spisałam je chybcikiem, fragmentarycznie i (nazwijmy to po imieniu) flejtuchowato. Przy takim wyimaginowanym projekcie można sobie na to pozwolić. W rzeczywistości nigdy nie mogłabym sobie pozwolić na niedbale spisane wymagania (komu się to zdarzyło, ten wie jakie piekło to oznacza). Ale o tym może następnym razem…

Anna Jaszczołt

Co czytać z zarządzania projektami (i nie tylko) Cz. 3

Obiecana kontynuacja cyklu „Co czytać…” Ciekawa jestem co już przeczytaliście, a co widnieje na Waszej liście?

Co czytac czesc 3

Ja obecnie zaczytuję się w Jurgenie Appelo: Managing for happyness. Pozycja uwieczniona w części 2 cyklu. Pięknie wydana książka, inspirująca i oddająca sedno współczesnych trendów. Lubię język i styl pisania Jurgena. Ciekawie przedstawia temat nawiązując do swoich doświadczeń i tego, co powiedzieli inni, znani w branży. Sporo żartuje i używa wizualizacji, a dokładnie: własnoręcznie stworzonych obrazków, co bardzo mi odpowiada, bo sama od jakiegoś czasu się tym fascynuję. Jego mocną stroną jest też nawiązanie do teorii naukowych, ale tego akurat więcej doświadczycie w Management 3.0.

Kolejna pozycja, którą aktualnie zgłębiam to Strategia Błękitnego Oceanu. Klasyka marketingowa traktująca o strategii tworzenia własnej marki. Ciekawa koncepcja wsparta rzeczywistymi przykładami. Widnieje na powyższej liście.

Pozdrawiam, życząc udanej lektury!

Anna Jaszczołt

PS. Część pierwszą cyklu znajdziecie tutaj, a drugą tutaj.

 

 

Gdy chcemy zrobić dużo naraz, przydaje się plan strategiczny

Anna Jaszczołt, Zarządzanie strategiczne

Wiem, długo nie pisałam. Trochę przez intensywny czas zawodowy i prywatny. Trochę przez pułapkę myślową, którą ostatnio regularnie sama na siebie zastawiam.

Wpadłam w schemat myślenia pt. „to już było”, „to jest oczywiste”, „o tym wszyscy wiedzą”, „nic nowego”. To myślenie strasznie zabija każdy kolejny pomysł na artykuł. Do tego doszedł jeszcze jeden aspekt: zdałam sobie sprawę z tego, że nie lubię się wymądrzać.

I wtedy pomyślałam sobie: hej Ania, przecież to tak samo jak z projektami, które prowadzisz. Nie blokuj się, zrób sobie listę zagadnień, które chcesz zgłębić w książkach, artykułów, które chcesz napisać. Taką odważną listę, bez skrupułów i zahamowań. Potem zaplanuj co zrobisz najpierw. Nie, nie rób planu na dwa lata. Po prostu ustal jaką książkę przeczytasz pierwszą, jaki wpis napiszesz, i po skończeniu zobaczy się co dalej. O! I to jest zwinne działanie w praktyce.

Myślenie o wszystkich zadaniach, które trzeba wykonać blokuje działanie.

To trochę jak jazda autem w nocy. Wiem dokąd zmierzam, ale nie znam w szczegółach całej drogi. Światła oświetlają mi dokładnie kolejne kawałki trasy, na których się skupiam. Jak zbliżam się do miasta, moim celem jest sprawnie przez nie przejechać. Skupiam się na tym co pokazuje nawigacja i na sztuce jazdy. Nastawiam zmysły na takie przedmioty jak: znaki, skrzyżowania, piesi, dziury w drodze, radary itd. Gdy jadę przez las, zwalniam, włączam długie światła, skupiam się na niebezpiecznych zakrętach, a na długiej prostej dodaję gazu i modlę się, żeby nie wskoczyła mi sarna na maskę;)

„podejście projektowe”

W pierwszym kroku zastanowiłam się po co ja w ogóle piszę. Tak, zrobiłam to po raz kolejny, może nawet dziesiąty. Ostatni raz był chyba z pół roku temu – jak dla mnie całkiem niedawno. Taka analiza upewnia mnie w działaniu, dodaje motywacji. Następnie zaczęłam tworzyć listę pomysłów na wpisy. Odnalazłam notes, który zaczęłam zapisywać lata temu gdy tworzyłam tego bloga. Tam znalazłam sporo fajnych pomysłów. Za kolejne źródło posłużył notatnik w telefonie – też kilka perełek się znalazło (mam tam taką listę, którą rozbudowuję przy okazji rozmaitych autorefleksji). Lista zaczęła automatycznie się uzupełniać. Przyznam Wam, że uśmiech zaczął pojawiać się na twarzy, tętno przyspieszyło – entuzjazm gotowy! Pomyślałam sobie, że jeszcze brakuje mi trzeciego źródła – Waszych sugestii. Więc już nie po raz pierwszy zwrócę się do Was z zapytaniem:

o czym chcielibyście czytać na tym blogu?

Oczywiście czekanie na Wasze pytania nie blokuje mnie w pisaniu tego, co sama zaplanowałam. Mogę wybrać sobie temat z listy i pisać, jednocześnie rozbudowując listę. Takie proste to i oczywiste, ale pozwolę sobie jeszcze przedstawić Wam graficznie:

pisanie

Zauważcie, że nie stworzyłam szczegółowego planu działania z zadaniami, harmonogramu z poszczególnymi tematami. Kiedyś tak robiłam. To podejście zabijało chęć do pisania. Bo zazwyczaj po napisaniu pierwszego artykułu pojawiał się pomysł na kontynuację. Często też wydarzało się coś ciekawego w moich działaniach zawodowych, czytelnik zgłaszał zainteresowanie konkretnym tematem, wpadła mi ciekawa książka w rękę, albo spadała na mnie inspiracja na konferencji, czy z Internetu. Tym razem więc określiłam sobie podejście do pisania na blogu:

  1. Ustaliłam jakie korzyści daje mi pisanie artykułów i prowadzenie bloga, co chcę przez to osiągnąć (Opisywać trendy? Ściągać zainteresowanie czytelników? Uczyć się opisując coś nowego? Utrzymywać ruch na stronie?…)
  2. Zaplanowałam etapy, w których podejdę do działania, a w ramach tych etapów ustaliłam:
    • Czy warto dzielić działania na etapy i czym się dany etap będzie wyróżniał?
    • Jaki ma być efekt końcowy etapu?
    • Jaka korzyść powstanie dla mnie?
    • W jaki sposób zrealizuję dany etap (krytyczne działania, zasoby itd.)?
    • W jaki sposób zadecyduję co dalej, jaki będzie kolejny etap?
  3. Teraz pozostaje odświeżać sobie to podejście za każdym razem gdy się zagubię lub zdemotywuję do pisania na blogu.

To, co opisałam powyżej i nazwałam podejściem do projektu mądre książki nazywają

planem strategicznym.

Taki plan przydaje się zawsze i bez niego ani rusz z projektem. Robicie takie plany w Waszych projektach? Komu powierzylibyście robienie planu strategicznego w świecie biznesu i co jeszcze mogłoby się w nim znaleźć?

Poniżej mała ściąga dla Was:

Planowanie Strategiczne, by Anna Jaszczołt

Anna Erdmańska-Jaszczołt

Jak skupiać się na tym co ważne w projektach i nie utonąć w morzu działań, możliwości, opcji, rozwiązań i pomysłów?

PMPiada 2017, postanowiłam postawić na praktykę, nie teorię, podzielić się doświadczeniem projektowym i nie tylko. Tym razem zapraszam na post w formie wideo.

W swej wypowiedzi zaadresowałam problem dynamicznie zmieniającej się rzeczywistości i natłoku różnych możliwości. Prywatnie i zawodowo nieustannie stajemy przed koniecznością dokonywania wyborów i podejmowania niełatwych decyzji. Jak sobie z tym radzić?

Wypowiedź z założenia miała trwać 20 minut, nie dłużej. Tak, trudno się siebie ogląda i słucha. Tak wiele zrobiłoby się inaczej. Właśnie dlatego doświadczenie zaliczam do tych wartych przeżycia pod kątem rozwojowym.

Zapraszam na krótki film, który znajdziecie pod linkiem.

A tu krótka fotorelacja z PMPiady:

A tutaj moje slajdy:

Anna_Erdmanska_Zarządzanie_integracją_projektu

Anna Jaszczołt (wcześniej Anna Erdmańska)

Zmiany w PRINCE2 – ile można zaoszczędzić, a ile stracić?

Dzisiaj zapraszam Was do lektury tekstu, który poczyniłam na stronie PMQ.

  • Jeśli planujecie zdawać egzamin PRINCE2, którykolwiek z poziomów…
  • Jeśli w niedalekiej przyszłości czeka Was re-certyfikacja…
  • Jeśli stosujecie metodykę PRINCE2 w swoich projektach…

…warto wiedzieć jakiego rodzaju zmiany nadchodzą.

Tekst pod linkiem.

pmq prince2

O tym, z czym my, PMowie zmagamy się w pracy, czyli 12 mitów na temat roli Kierownika Projektów

Tym razem zapraszam Was do krótkiej i przyjemnej lektury wpisu natury nieformalnej, który zaczęłam pisać (uwaga!) dwa lata temu 🙂 Ten tekst pokazuje jak różnorodnie rozumiana może być rola project managera i jak często fakt ten jest w różnych celach wykorzystywany.

Oto 12 mitów na temat roli kierownika projektu. Mam nadzieję,  że raczej się pośmiejecie, niż popłaczecie nad tym tekstem. A może i dodacie coś od siebie?

danbo-1870370

12 MITÓW NA TEMAT ROLI KIEROWNIKA PROJEKTÓW

  1. Kierownik Projektów jest od robienia slajdów.
  2. My tu nie potrzebujemy kolejnego PMa, który stworzy tabelkę w Excelu, wstawi tam jakieś daty i będzie nas z nich rozliczał.
  3. PM to osoba od ścigania. Niczego nie rozumie, mało co wie, obchodzi go tylko dotrzymanie terminu.
  4. Z PMem lepiej nie gadać o kwestiach merytorycznych projektu, i tak nic nie zrozumie.
  5. PM to osoba, której można przypisać wszystkie zadania koordynacyjno-asystenckie. Zorganizuje biurko, zamówi komputer, naprawi drukarkę. …to by było na tyle.
  6. Dla PMa liczy się tylko jedno: DEADLINE.
  7. Kierownik Projektu to osoba od prowadzenia spotkań.
  8. PMa nie ma co wtajemniczać w problem, i tak nic nie załatwi, tylko eskaluje niepotrzebnie jakieś małe nieporozumienie.
  9. Przepraszam, że znowu Cię nagabuję, ale jestem PMem i moją rolą jest ścigać ludzi.
  10. Główną kompetencją Kierownika Projektu jest znajomość procedur, przepisów i obowiązującej polityki.
  11. Kierownik Projektów musi przede wszystkim mieć wiedzę i umiejętności techniczne.

No i na podsumowanie:

  1. Brakuje nam człowieka, który zająłby się „tym” i jeszcze kilkoma innymi sprawami. Hmm… Jakby nazwać to stanowisko…? Kierownik Projektu! Pasuje idealnie!

Trochę to śmieszne, trochę frustrujące. Grunt, żeby umieć z takimi mitami walczyć, a przede wszystkim samemu takiego obrazu Kierownika Projektu nie tworzyć.

Pozdrawiam Was przez pryzmat krzywego zwierciadła 😉

Co determinuje sukces w biznesie?

Tym razem gościnnie na blogu PMQ.PL. Kilka słów o tym, że liczy się skuteczność, a nie jakieś tam tabelki, wykresy, czy slajdy. Coś, o czym już dawno chciałam napisać. Zapraszam do lektury tutaj 🙂