Pokazywanie postów oznaczonych etykietą Project management. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą Project management. Pokaż wszystkie posty

wtorek, 6 września 2016

Pryncypia w Agile C.D.N.

Część następna, części poprzedniej...


4 - Nigdy nie idź na kompromis w kwestii Jakości

Wymaga w kierunku  zespołu:

- Ciągłego testowania w możliwe wczesnej fazie;
- Ustalenia na początku oczekiwanego poziomu jakości;
- Odpowiedniego planowania, udokumentowania i właściwego testowania;
Zapewnienia, że jakość nie stanie się wartością zmienną;
- Wbudowywania jakości przez przeglądy z odpowiednimi osobami, wykonywane w sposób ciągły.

To pryncypium jest wspierane przez:

- Periodyczne przeglądy w cyklu życia;
- Testowanie uzyskanych produktów;
- Wczesne i integracyjne testowanie;
- Kluczowe techniki to MoSCoW i Stosowanie Okienek Czasu


Jak wiecie - Gwarancja jest JAK...ości
Znaczy to nie mniej, nie więcej jak to, że Jakość powinna spędzać wam sen z powiek. tylko ona gwarantuje długoterminowe zadowolenie interesariuszy.


5 - Buduj "przyrostowo" na solidnych podstawach

Wymaga to od zespołu :

Ciągłego potwierdzania, że budowane rozwiązanie jest poprawne;
- Dążenia do jak najwcześniejszego dostarczenia korzyści biznesowych tam, gdzie to jest
możliwe;
- Formalnego dokonywania ponownej oceny zasadności projektu i właściwych priorytetów, po każdym przyroście;

Wspierane jest przez :


- Cykl życia - stworzenie solidnej podstawy (Wykonalność i Podstawy) przed rozwojem przyrostowym (przez Inżynierię i Eksplorację)


6 - Rozwijaj w sposób iteracyjny

Rozwój Iteracyjny pozwala zespołowi w sposób ciągły zbliżać się do odpowiedniego rozwiązania


Wymaga to od zespołu :

Zaakceptowania faktu, że większość szczegółów pojawi się później niż wcześniej;
- Wykonania tylko wystarczającego projektowania na początku (enough design up front EDUF), po to by stworzyć solidne podstawy;
- Ciągłej kreatywności, właściwego eksperymentowania, nauki oraz ewoluowania;
- Budowania produktów za pomocą podejścia iteracyjnego - przyrostowego;
- Wbudowania (feedbacku) informacji zwrotnej od klienta w każdą iterację;
- Wykorzystania zmian, dobre rozwiązanie nigdy nie będzie ewoluowało bez nich.


Zmiana jest nieuchronna, wykorzystaj jej skutki - jest to wspierane jest przez :

- Iterację i przeglądy - zapewniają, że ewoluujące rozwiązanie jest zgodne z rzeczywistymi

potrzebami biznesu.


7 - Komunikuj się ciągle i jasno

Wymaga to od zespołu:

- Przeprowadzania Codziennych Zbiórek (daily stand-up);
Utrzymywania zwięzłej i aktualnej dokumentacji - nie chodzi tutaj o ilość papieru, lecz zwięzłość i aktualność zapisów;
- Wykorzystywania Warsztatów Facylitowanych;
Wspierania nieformalnej komunikacji „twarzą w twarz” na wszystkich możliwych poziomach;
- Korzystania z modelowania, prototypowania;
- Przedstawiania przyrostów rozwijanego rozwiązania często i wcześnie;
- Ciągłego zarządzania oczekiwaniami interesariuszy.

Jest to wspierane przez:

- Upoważnianie użytkowników i ich zaangażowanie; 
- Codzienne Zbiórki i Warsztaty Facylitowane;
- Jasno zdefiniowane role;

- Modele i prototypy – w celu unaocznienia rozwiązania w początkowym stadium rozwoju.


8 - Demonstruj właściwą kontrolę

Wymaga aby zespół, a przede wszystkim Kierownik Projektu i Lider Zespołu:

Zarządzali proaktywnie;
- Ciągle mierzyli postępy poprzez dostarczanie produktów;
- Używali odpowiedniego stopnia (nie zbyt dużego, ani zbyt małego) formalizmu dla śledzenia i raportowania;
- Zapewnili, że plany i informacje o postępach były widoczne dla wszystkich 
- Ciągle oceniali, w oparciu o cele biznesowe, zasadność dla projektu .

Wspierane jest to przez:

- Kluczową technikę : Stosowanie Okienek Czasu;
Produkty planowania;
- Ciągłe przeglądy;

Plany Okienek Czasu oraz Podstawy Zarządzania.


 ...that's all folks !... i pamiętajcie :


Traktuj każde odejście od zasad jako ryzyko.
Złamanie którejkolwiek z zasad stanowić powinno poważne ryzyko dla sukcesu procesu zwinnego i sukcesu projektu

Na początku każdego projektu otwarcie przedyskutuj z zespołem projektowym Pryncypia. Upewnij się, że wszyscy są one jasne i akceptowalne dla wszystkich.



wtorek, 30 sierpnia 2016

Pryncypia w Agile

Dziś zajmiemy się PRYNCYPIAMI, po wprowadzeniu które już nastąpiło. Czym są pryncypia i czemu służą, oto mała "wyliczanka" :

- Wszystkie pryncypia razem pozwalają organizacji dostarczyć rozwiązania o najwyższej wartości (dla biznesu / interesariuszy);

- Pryncypia uwydatniają postawę i sposób myślenia zespołu;

- Ryzykiem są ustępstwa wobec pryncypiów, podważają one filozofię;

- Chcąc uzyskać maksymalną korzyść należy zastosować wszystkie pryncypia.



1 - Bądź skoncentrowany na potrzebie biznesowej 

Decyzje oparte na celu biznesowym :

- należy dostarczać biznesowi tego co potrzebuje dokładnie wtedy kiedy tego potrzebuje

To pryncypium wymaga od zespołu :

- Stworzenia solidnego uzasadnienia biznesowego;
- Głębokiego zrozumienia właściwych priorytetów biznesowych;
- Powodowania zaangażowania i ciągłego sponsorowania ze strony biznesu;
- Zapewnienia dostarczenia Minimalnego Użytecznego Podzbioru (Minimum Useable Subset).

Jest wspierane przez:

- Odpowiednie role biznesowe;
- W fazie Podstaw Produkty biznesowe są uzgodnione;
- Kluczowe techniki - MoSCoW i Stosowanie Okienek Czasu (timeboxing).




2 - Dostarczaj na czas

Wymaga to od zespołu :

- Upartego stosowania Okienek Czasu;
- Skoncentrowania na przyznaniu pierwszeństwa dla biznesu;
- Pewnego dotrzymywania ostatecznych terminów.

Wspierane jest przez :

- Te same kluczowe techniki : MoSCoW i Timeboxing;
- Budowanie reputacji dostarczania na czas i zgodnie z przewidywaniami.



3 - Współpracuj

Wymagania dla zespołu :

- Zaangażowania w odpowiednim czasie odpowiednich zasobów w postaci interesariuszy w trakcie trwania całego projektu;
- Zapewnienia, że decyzje są podejmowane przez członków zespołu do tego upoważnionych, w imieniu tych których reprezentują; 
- Budowy kultury jednego spójnego zespołu;
- Ciągłego aktywnego angażowania przedstawicieli biznesu.

Jest to wspierane przez :

• Role biznesowe;

• Kluczową technikę: Warsztaty Facylitowane (facilitated workshops).


C.D.N. - czyli Ciągle Dalej Niżej ;) - w części następnej...

Podstawy Agile - fundamenty

Czas aby przedstawić podstawy filozofii AGILE, poniżej ikonografika "pięknej wręcz urody" - ma ona na celu przedstawić istotę zarządzania zwinnego AGILE, jej podstawy.


Pamiętać należy, że projekty AGILE muszą być powiązane w sposób jasny i ścisły z celami strategicznymi organizacji. 

Podczas wyboru zarządzania Zwinnego należy kierować się rzeczywistym dostarczaniem (we wczesnej fazie) produktów (korzyści) dla biznesu.

Jakie zatem są warunki sukcesu tego rozwiązania ?

Otóż takie :


  1. AKCEPTACJA, faktu że zmiana jest nieunikniona;
  2. UPOWAŻNIENIA, są istotne i rozdzielone tylko dla odpowiedniego poziomu zarządczego;
  3. Należy DOSTARCZAĆ na czas w planie zgodnie z priorytetem biznesu;
  4. CELE BIZNESU, są jasne i klarowne a przede wszystkim rozumiane przez kluczowych interesariuszy projektu;
  5. Nieunikniona jest WSPÓŁPRACA, w celu osiągnięcia i zrealizowania zamierzonego rozwiązania;
  6. rozwiązanie, którego szukają interesariusze będzie odpowiadać swojemu PRZEZNACZENIU.
Następnym razem zajmiemy się PRYNCYPIAMI...ale tym razem w ujęciu AGILE

poniedziałek, 30 maja 2016

Procesy - Zamykanie Projektu / Processes - Project Closure

Celem procesu Zamykanie Projektu jest przede wszystkim zweryfikowanie akceptacji dla produktów, wykonywane przez użytkownika. Tutaj także uzyskujemy zapewnienie że klient jest w stanie wspierać produkty danego projektu. Dokonujemy w procesie Zamykanie Projektu przeglądu dla efektywności realizacji projektu. 
Nie mniej ważne cele to między innymi ocena zrealizowanych korzyści i aktualizacja prognoz dla korzyści. Zamknięcie Projektu pomaga nam również w zapewnieniu rozpatrzenia wszelkich nierozwiązanych zagadnień i ryzyk jak również zaleceń dla działań następczych.
Istotnym celem tego procesu jest także zaplanowanie przeglądu korzyści.

Cyt. " proces Zamykanie Projektu służy do wskazania ustalonego punktu, w którym zostanie potwierdzona akceptacja produktu końcowego projektu oraz potwierdzenia, że cele określone w pierwotnej Dokumentacji Inicjowania Projektu zostały osiągnięte, albo że projekt nie ma już nic więcej do wniesienia"

Co ważne :
- proces Zamykanie Projektu jest realizowany również wtedy gdy projekt zamykany jest przedwcześnie;
- cechą charakterystyczną projektu jest skończony czas trwania;
- zakończenie projektu powoduje koniec odpowiedzialności zespołu zarządzania projektem;
- dokumentowania wymagają wszelakie działania następujące, dotyczące przekazywanych produktów;
- zakończenie projektu przekazuje również odpowiedzialność na stronę klienta, za jego produkty.

Proces Zamykanie Projektu zawiera/może zawierać w sobie poniższe czynniki :


  • Przygotowanie planowego zamknięcia;
  • Przygotowanie przedwczesnego zamknięcia;
  • Przekazywanie produktów;
  • Ocenianie projektu;
  • Rekomendowanie zamknięcia projektu.

To był ostatni przeze mnie opisany proces występujący w metodologii Prince2

wtorek, 10 maja 2016

Procesy - Zarządzanie Końcem Etapu / Processes - End of Stage Management

Oczywiście i ten Proces ma służyć Komitetowi Sterującemu, ale nie tylko. A po cóż on temu Komitetowi, jest on potrzebny z paru powodów :


  • Komitet Sterujący musi w jakiś sposób dokonywać przeglądu osiągnięcia celów bieżącego etapu;
  • Komitet Sterujący musi w jakiś sposób dokonywać przeglądu uaktualnionego Planu Projektu;
  • W jakiś sposób (właśnie dzięki Zarządzaniu Końcem Etapu) Komitet zatwierdza Plan następnego Etapu;
  • Jest to "narzędzie" dzięki któremu łatwo jest potwierdzić dalszą zasadność biznesową projektu i tak zwaną "akceptowalność" ( poziom dopuszczalnych ) ryzyk
  • Tutaj jest miejsce na stwierdzenie sytuacji nadzwyczajnej i opracowanie Raportu Nadzwyczajnego oraz Planu Nadzwyczajnego, który zatwierdzany jest jak Plan Etapu
Czego jeszcze możemy oczekiwać od Procesu Zarządzanie Końcem Etapu - na pewno przeglądu i uaktualnienia Dokumentacji Inicjowania Projektu.

Mała dygresja  - DIP to :

  1. Opisy ról i struktury zespołu zarządzania projektem;
  2. Uzasadnienie Biznesowe;
  3. Plan Projektu;
  4. Strategie Zarządzania (są to strategie zarządzania : Konfiguracją, Jakością, Komunikacją, Ryzykiem);
  5. Mechanizmy sterowania Projektem;
  6. Opis (definicja) projektu i jego forma realizacji;
  7. Opis dostosowania metodyki (bo PRINCE2 jest skalowalny - prawda ;) ?)
Bardzo istotnym jest również zarejestrowanie informacji i doświadczeń w odpowiednich rejestrach - będą one pomocne przy realizacji dalszych etapów ( i możliwe że przy innych projektach).

A po co ten proces Kierownikowi Projektu ? Jest on konieczny dla Uzyskania zezwolenia na rozpoczęcie Kolejnego Etapu.
To czy projekt jest skoncentrowany na osiągnięciu celu i uzasadniony biznesowo, jest każdorazowo potwierdzane właśnie tym procesem. 
Należy również pamiętać,że decyzja o zaniechaniu kontynuowania projektu nie jest porażką.

Tutaj raportowanie zakończenia etapu da nam odpowiedź , czy otrzymamy akceptację Planu Etapu / Planu Nadzwyczajnego - oczywiście raport należy rozesłać wszelakim interesariuszom.

czwartek, 5 maja 2016

Procesy...Zarządzanie Strategiczne Projektem / Programme Management

Jesteśmy na saaaamej górze...kto by tu nie chciał siedzieć ?

Tak PRINCE2 mówi o tym że Zarządzanie Strategiczne umożliwia przyjęcie odpowiedzialności przez Komitet Sterujący, ale przecież to jest właśnie ta "śmietanka z tortu".

To właśnie dzięki temu procesowi Komitet jest w stanie podjąć kluczowe decyzje, deleguje uprawnienia, takie jak bieżące zarządzanie projektem ( kierownikowi).

Zarządzanie strategiczne polega na weryfikacji i kontroli czy dany projekt pozostaje zasadny, polega również na upewnieniu się że istnieje przepływ informacji między poziomami zarządzania. Dzięki temu procesowi Komitet Sterujący jest w stanie przeglądać korzyści projektowe (czyli CLUE zabawy w projekt;)).

Zarządzanie Strategiczne jako proces rozpoczyna sie zaraz po Przygotowaniu Projektu, i dzięki Tolerancjom Komitet Sterujący jest w stanie działać we wspomnianym procesie, jednocześnie powodując jak najmniejszą ingerencję

Nie chodzi o to by Komitet interesował się nawet najmniejszym etapem i cząstką projektu, dzięki delegacji uprawnień i przypisaniu odpowiednich tolerancji, może zająć się innymi projektami - dzięki temu doglądając kilku naraz

Komitet Sterujący, dzięki procesowi Zarządzanie Strategiczne Projektem zezwala na :
- zainicjowanie projektu;
- realizację projektu;
- realizację Planu Etapu, lub Planu Nadzwyczajnego;
- podejmowanie decyzji doraźnej
- zamknięcie projektu

czwartek, 28 kwietnia 2016

Pryncyp 7 - dmy - Dostosuj Metodykę do warunków projektu / Just adjust your methodology to project environment

To jest, że tak powiem "Last but not Least" z pryncypiów, zarazem mój ulubiony. PRINCE2 nakazuje, by metodykę dostosować do warunków projektu. Zacna to teza, i trafne stwierdzenie. Nie jest to co prawda "unikanie odpowiedzialności" za niepowodzenia projektu, ale raczej "krojenie na miarę potrzeb".

Co bierzemy pod uwagę:

1. Warunki konkretnego projektu - czy chodzi nam o wykształcenie pięknego ABS, czy też o zdobycie medalu mistrzostw świata, tak jak pisałem wcześniej. Warunki są różne projekty są jeszcze bardziej zróżnicowane - chodzi o to by PRINCE2 dostosować, ale dlaczego PRINCE2...może lepiej Agile PM - ten jest jeszcze bardziej "giętki", nie posiada wad w postaci opasłych ram formalnych. pamiętajmy, zawsze możemy użyć metodyki Kaskady (Waterfall), ona sprawdza się w środowiskach nieskomplikowanych z ustalonymi z góry i przewidywalnymi "zmiennymi".

2. Rozmiar Projektu, jasne jest tutaj stanowisko metodologii, ponieważ opisuje ona jak bardzo można "ścisnąć" dokumentację dla mniejszego projektu, które role można łączyć etc. natomiast w przypadku wielkiego projektu, PRINCE2 dostarcza wszelkich instrumentów do kontroli i pomocy w jego realizacji zgodnie z założonym Uzasadnieniem Biznesowym.

3. Złożoność Projektu, metodologia daje nam wybór ilości faz projektu, daje nam możliwość w podziale produktów na produkty cząstkowe. To wszystko umożliwia sprawne zarządzanie nawet najbardziej złożonymi projektami gdy oprzemy się na metodologii.


4. Znaczenie Projektu, wiadomo że dla każdego Kierownika Projektu jego projekt jest najważniejszy, jest nieco inaczej z Komitetem Sterującym, który może brać udział i rozdzielać swój czas pomiędzy inne projekty. Tutaj zarządzanie tolerancjami, odpowiedzi zdefiniowanie ról i obowiązków pomaga zaoszczędzić czas decydentom - definiując zarazem znaczenie konkretnego projektu.

5. Możliwości i Ryzyko, metodyka PRINCE2 w przypadku ryzyka odsyła nas do odrębnego działu -  MOR (Management Of Risk). Gdybyśmy jednak chcieli znać podstawy i pragnęli zabezpieczyć się w podstawowy ( często wystarczający ) sposób, ryzyko jesteśmy w stanie "ogarnąć" również przy pomocy dostępnych w PRINCE2 / Agile metodologii. Każdy projekt ma inne możliwości, myślę że ten truizm jest jasny sam w sobie.

Dodam jeszcze tylko, że metodykę PRINCE2 można stosować w każdej kulturze pod warunkiem spełnienia wszystkich siedmiu pryncypiów.

To w jaki sposób metodykę dostosowano do warunków danego projektu powinno być opisane w DIP, czyli Dokumentacji Inicjowania Projektu.


środa, 27 kwietnia 2016

Produkt / Product – to wszystko przez niego ten cały PRINCE2

No bo gdyby go nie było, to by PRINCE2 nie było… tak mądrym wstępem pragnę zacząć. Czymże jest produkt – niby każdy wie. Wie pan, wie pani…wie społeczeństwo…ale jak się okazuje nie do końca. Koncentracja na produkcie w podejściu PRINCE2 jest bardzo dobrze opisana – jako „clue” całej tej zabawy.

Zależnie od klienta – poziomu odbioru – produktu widzimy specyfikację i określenie produktu finalnego i cząstkowego.  To od klienta zależy, jaki produkt będzie dla niego odpowiedni, od klienta zależą również tolerancje dla niego na różnych zakresach.

Zależnie od kryteriów jakościowych wiemy jak dobrze jest opisany produkt – dzięki temu powinniśmy wiedzieć czy będzie on odpowiadał opisowi produktu końcowego.

To Opis Produktu mówi nam o wszelakich właściwościach wytwarzanego przez nas produktu, niezależnie od tego czy produktem będzie: dokument, decyzja, kubek do kawy, kosiarka, impreza charytatywna, koncert, czy też książka… etc.


Dlaczego jest to tak istotne – jest to zdrowe podejście dla wszelakich metodyk Agile, przyczyną działań powinien być produkt końcowy, choć jak pisałem w Agile PM – akceptuje się czasem inny jego wygląd , dla sprostania „stałym” funkcjom „trójkąta”. To i tak musi to być zawsze produkt akceptowalny przez interesariuszy, oraz ogólnie rzecz biorąc rynek/odbiorcę, czyli klienta (w rozumieniu pejoratywnym).

czwartek, 14 kwietnia 2016

Etapy / Stages

Etapy etapami, Panie Kierowniku, ale my jesteśmy w czarnej ...
Jak jest "ZAZWYCZAJ"

Panie Kierowniku - tym razem naprawdę...damy radę...
Jak powinno być

poniedziałek, 11 kwietnia 2016

Zdefiniowane role i obowiązki / Roles Defined.

Zdefiniowane role i obowiązki pojawiają się w każdym projekcie, jako kolejne z koniecznych pryncypiów.

Jest koniecznym i standardowym podejściem w metodologii PRINCE2, ustanowienie jasnych zakresów obowiązków, choć dopuszcza się czasem przy założeniu, że projekt jest niewielki – łączenie ról. Standard zaleca jednak by role pozostały rozdzielone w taki sposób, aby umożliwić przepływ danych i rozdział kompetencji, dając tym samym pracującym ludziom wszystkie potrzebne narzędzia do wykonywania swoich obowiązków.

Istotnym jest zdefiniowanie interesariuszy – z punktu widzenia „koncepcji ruchu” – są to ludzie, których „zawsze coś rusza”, w odniesieniu do projektu. Czyli mają na projekt wpływ lub projekt na nich wpływa – w konsekwencji wywołując ruch.

Mówi się często o TRZECH stronach interesu w projekcie :




czwartek, 7 kwietnia 2016

Korzystanie z doświadczeń / Lessons Learned.


Tak jest to jedno z siedmiu pryncypiów według PRINCE2, które jest koniecznym by projekt był realizowany w zgodzie z metodyką.  W języku angielskim używa się czasem pojęcia „Lessons”, ponieważ to właśnie doświadczenia, te Lekcje z „pola walki” są najistotniejszymi dla powodzenia realizacji projektu. Jeśli już raz udało nam się przetrzeć szlaki i wykarczować las niebezpieczeństw i terminów oraz zazębiających się zadań oraz ułożyć z tego spójną drogę przez proces prowadzenia projektu. Logicznym jest, że prawdopodobnie uda nam się za drugim i trzecim razem. 

Choć praktycy powtarzają, że każdy projekt jest inny, każdy ma inne uwarunkowania. Najistotniejsze jest jednak z punktu widzenia tego pryncypium to, że dzięki doświadczeniu unikamy popełniania tych małych błędów. Ponieważ nawet największa podróż zaczyna się od pierwszego kroku. Ważnym jest by nie skręcić kostki na samym początku i uniknąć stałych niebezpieczeństw, które towarzyszą każdemu przedsięwzięciu biznesowemu.


Jeśli realizujemy mały projekt w ramach małego przedsięwzięcia, zazwyczaj korzystamy z notatnika albo innej formy bazy danych, bardziej nieformalnej. Korporacyjne podejście jest bardziej usystematyzowane. To cała gałąź „ Lessons Learned” osnuta jest w ideologię, politykę i opasłe systemy informatyczne do przechowywania danych i doświadczeń, po to by wykorzystać je podczas kolejnej działalności, kolejnego „startu” projektu. Ma to swoją drugą stronę medalu taką, że często ilość danych przerasta czytelnika / odbiorcę, co w gruncie rzeczy prowadzić może do zniechęcenia i zaniechania korzystania z takiego źródła. 

Negatywne efekty - to popełnianie tych samych błędów przy każdym projekcie, brak motywacji do poprawiania działań. 

środa, 6 kwietnia 2016

A torcik znacie ? / Do you recognize that cake ?

Co mówi PRINCE2 na temat słodyczy... / What PRINCE2 says about sweets...

Ruch w biznesie - movement within business

Jak zapewne wiecie zasadność biznesowa,  jest bardzo istotnym czynnikiem PRINCE2 opisuję ja jako „pryncypium”. Ni mniej ni więcej, należy się jej 100% uwagi bo to klient musi dbać o swój biznes i dostawca również robi to dostarczając swój produkt na czas. Nieodzownym jednak czynnikiem jest badanie tej ZasadnościBiznesowej – czy jest ona CIĄGŁA.



Brak Ciągłości w najlepszym wypadku może spowodować wyjście poza zakres lub , zbliżenie się do tolerancji (czasu, lub zasobów pieniężnych) w najgorszym może jak najbardziej prowadzić do klęski. 

Ponieważ PRINCE2 definiuje SIEDEM PRYNCYPIÓW, brak jakiegokolwiek z nich eliminuje nasz projekt z rozpatrywania go, jako projekt oparty na wspomnianej metodologii.  Nie wyklucza go jednak z zarządzania metodami bardziej zwinnymi… ale to już całkiem inna bajka. 

Pamiętać należy jedno, by weryfikować i sprawdzać czy zasadność biznesową istnieje, czy na każdym etapie realizacji jest sens ciągnąć projekt dalej. Ponieważ okazać się może, że takowy będzie miał rację bytu w formie, jakiej jest (AGILE), a dalszy rozwój przyniesie tylko większe straty lub zysk, który nie pokryje alokowanych kosztów.

wtorek, 5 kwietnia 2016

Ruch wewnętrzny - internal movement

Zapewne już znacie wszystkie szczegóły dotyczące podstawowej zależności – PlanujDelegujMonitoruj Kontroluj


coś na kształt koła Deminga


To jest specyfika w zarządzaniu projektem, która świetnie się wpisuje w koło Deminga.  Ruszając się wewnątrz projektu musimy pamiętać o parametrach efektywności projektu. PRINCE2 jasno je deklaruje, jest ich sześć:

- Koszty;
- Terminy;
- Jakość;
- Zakres;
- Ryzyko;
- Korzyści;

Mając na uwadze te zależności, łatwo określić siły wpływu wewnątrz każdego projektu. Są to siły przeciwstawne, ponieważ silnie powiązane, mają niesamowity – nieodzowny wpływ na powodzenie naszego przedsięwzięcia.

Jest to podstawowa logika:  Jakość ma wpływ na Koszty, Koszty na terminy, Zakres ma wpływ na Ryzyko a wszystko zależne jest za zwyczaj od Korzyści, etc..



Niezależnie od tego jak będziecie zabierali się do projektów ważnym jest by nie zapominać o wewnętrznych siłach współdziałających w waszym „specyficznym” projekcie. Od tego powinno zależeć wasze podejście i wybór właściwej ścieżki zarządzania: przecież niekoniecznie musi być  Agile, skoro PRINCE2 daje radę, a może właśnie adaptacja podejścia Klasycznego Kaskadowego lub właśnie SCRUM da radę. 

sobota, 19 grudnia 2015

Ruch w przypadku procedury SCRUM, Agile PM, PRINCE2, Kaskada

Więc o co chodzi z tym ruchem w PM, chodzi o to żeby będąc członkiem choćby najmniejszego zespołu projektowego  - wiedzieć gdzie się ruszać i jak poruszać. Co prawda SCRUM i Agile mówią o tym że nie należy przekładać procedur ponad podejście zdroworozsądkowe i współpracę międzyludzką, powiedzmy sobie jednak szczerze - rzadko się to udaje. Minimalny, elementarny i rzekłbym nawet funkcjonalnie opisany szkielet procedury jest wymagany, by choćby najmniejszy projekt przeprowadzić osiągając sukces. Wiadomo, że inaczej będzie określony sukces dla Agile PM, a inaczej dla PRINCE2. W ujęciu kaskadowym o sukcesie moża natomiast mówić gdy wszystkie procedury zostaną wypełnione ale jest do drugi kraniec szali, o którym dziś mniej będzie.
Jakie zatem procedury wprawią w ruch nasze projekty - na pewno "nie opasłe", tzn. lekkie i zwinne i powiewne. Nie muszą być opasłymi tomiskami, najważniejsze by spełniały swoją rolę. Chcę was przestrzec przed tworzeniem "papierologii stosowanej" bo :
  • dokumenty-procedury trzeba tworzyć;
  • trzeba nią zarządzać, czasem jak w przypadku zarządzania konfiguracją, potrafi to być bardzo upiorne;
  • papierologię trzeba przechowywać i przypominać wszystkim by ją czytali, a to przecież NVAA ;)
Podsumowując zgrabnie - ruch w procedurze ma sens gdy procedurę da się przesunąć, poruszyć jednym małym palcem... 

So, what is all about this movement in PM, it is just a hint for you , when you are a member of even the smallest project team - to know where to move or how to move. That is true SCRUM and Agile defines its attitude to procedures in short sentence, that you shouldn't take procedures too serious, clear thoughs and interpersonal communication is far more important, but let's be honest - it is so rare to give effective succes. Small, elementary and let me say functionally defined backbone of procedure is needed, to lead even not very big project with success. It is known, that success itself will be defined differently for Agile PM, PRINCE2 and success for Waterfall attitude we may say only when all procedures will be fulfilled , but this is the other end, I won't be describing that today.
So which procedures will make our project to move  - for sure lightweight, and agile, light as breeze. these do not have to be heavy volumes, the most important is fact that they must work. I want to warn you against creation of " documentation faculty", because:

  • documents - procedures must be created;
  • documents must be managed, sometimes in scope of configuration management this could be creepy
  • documents must be saved, reminded to everyone and this of course creates NVAA

To sum it up - movement within procedure is wise whet prcedure can be moved with your little finger...

czwartek, 17 grudnia 2015

Ruch w PM, a nie w MP - Project Management - specyficzna forma ruchu

Ruch jest jasno określony i bardzo dobrze by było gdyby miał swój cel. Dlatego tak istotnym jest wiedzieć gdzie się zmierza ;)
Chcę w paru słowach opisać tutaj moje ostatnie zainteresowanie dotyczące PM, czyli Project Management.
Dlaczego ?


  • Project Management , czyli zarządzanie projektami to taka sympatyczna praca w której głównie się cały czas i przeciągle i bez zatrzymania -  rusza;
  • Jest to niesamowita przyjemność patrzeć na zmieniające się słupki i powiązane z nimi MoR (Management of Risk) oraz Change Management, czyli zarządzanie zmianą;
  • Człowiek z natury leniwa postać, nie potrafi się zmusić do ruchu samoistnie, dlatego łatwiej się mu zorganizować, gdy widzi Projekt i Plan J



Na początek, myślę że to wystarczy jako powody – reszta wyjdzie w praniu, jak zwykle (pewnie raczej w formie AGILE, a nie PRINCE2, ani też Kaskadowo)

Movement is of course clearly defined and that is OK if it would have own purpose. Therefore it is so important where you are going ;)
I would like to define here in few words my latest interest regarding PM, which stands for Project Management.
Why ?


  • Project Management it is such nice work, where you must move yourself - mainly, constantly and all the time, without any stoppage;
  • It is enormous pleasure to see charts which are changing in relation to MoR (Management of Risk) and Change Management;
  • Man as for nature, is a bit lazy, can not force him/herself to move a little, that is why it is easier for him/her to organize, when Project or Plan is visible J


As for the beginning it should be enough, for reasons – rest will be “washout” (excuse me this translation was made by intention ;)) added in future, it means as usual ( rather in form of AGILE, not PRINCE2, or waterfall )

ta-da !