Podręcznik zarządzania projektami….
Firma Octigo na swoim blogu udostępniła do pobrania za darmo, podręcznik zarządzania projektami, który powstaje na bazie wpisów na blogu. Póki co podręcznik zawiera cztery rozdziały (80 stron) i traktuje między innymi o tym jak zaplanować zakres w postaci WBS, ułożyć harmonogram, zarządzać czasem, skracać projekt, czym jest jakość i jak ją zapewnić, jak monitorować koszty projektu. Podręcznik jest sukcesywnie rozwijany.
Przyczyny niepowodzeń projektów IT
Jakiś czas temu pisałem o przyczynach niepowodzeń w projektach IT. Na stronie IAG Consulting znalazłem ciekawy filmik traktujący o przyczynach owych niepowodzeń. Zachęcam do obejrzenia.
Nieustannie na liście jednej z podstawowych przyczyn porażek gości brak dobrej specyfikacji wymagań.
Po egzaminie Prince2 Foundation (v.2009)
Dwa tygodnie temu zdałem egzamin Prince2 Foundation. W tym poście chcę odpowiedzieć na pytanie czy warto iść na szkolenie akredytowane czy może lepiej zdawać egzamin W British Council bez akredytowanego szkolenia (bo też jest taka możliwość).
Przed pójściem na akredytowane szkolenie Prince2 Foundation wahałem się czy iść na nie czy lepiej odrazu podejść do egzaminu (wcześniej sam przygotowywałem się na podst. książki Skuteczne Zarządzanie Projektami Prince2). Według mnie, jeśli ma się możliwość pójść na takie szkolenie to naprawdę warto, a to przede wszystkim z dwóch powodów.
Pierwszym powodem jest to, iż samo tłumaczenie podręcznika Skuteczne Zarządzanie Projektami Prince2 nie jest idealne (szczególnie jak na podręcznik za 300 zł). Oprócz kilku literówek i błędów stylistycznych pojawiają się nieścisłości merytoryczne, które akredytowany trener jest w stanie uwypuklić na szkoleniu. Jedną z takich nieścisłości było słowo "szacować" (w kontekście Planowania). Podręcznik sugeruje czytelnikowi iż, szacować znaczy "określać w przybliżeniu" (bez przejmowania się za bardzo superdokładnością). Sam tak też tak rozumiałem. Z kolei wersja anglojęzyczna mówi o tym, iż przedmiot owego "szacowania" należy określić jak najbardziej dokładnie. Słowo szacować można zastąpić tu słowem wyznaczyć, obliczyć, określić. Doświadczony trener z pewnością zwróci uwagę na takie detale.
Drugim powodem dla, którego warto pójść na szkolenie akredytowane (niestety na rynku pojawiają się szkolenia krzaki bez akredytacji OMG), jest to, iż doświadczony trener wnosi szerszy kontekst nauki tej metodyki zarządzania projektami. Szkolenie poparte licznymi przykładami jest naprawdę o wiele bardziej skuteczne niż suche przeczytanie książki (do egzaminu Prince2 Practicioner wymagane wręcz kilkukrotne) - no chyba, iż osoba chcąca zdać egzamin jest wieloletnim praktykiem a certyfikat potrzebny jest tylko jako wymaganie w przetargu 
Jeszcze słowo o samym przygotowaniu się do egzaminu - egzamin sam nie jest wcale banalny (OMG podniosło ostatnio poziom trudności egzaminu). Mocno zachęcam do rzetelnego przestudiowania podręcznika i częstych powtórek rozdziałów. Ponadto warto przestudiować również dodatki na końcu podręcznika.
Za jakiś czas relacja "po egzaminie z Prince2 Practicioner"
PMblogs.pl – agregator blogów o tematyce zarządzania projektami
Jakiś czas temu popełniłem serwis PMblogs.pl - agregator polskich blogów o tematyce zarządzania projektami. Agregator prezentuje tytuł i pięć najnowszych wpisów na blogu. Blogi sortują się od ostatnio zaktualizowanego do najstarszego. Liczba blogów ciągle się zwiększa.
Jeśli znasz ciekawy serwis bądź blog związany w jakikolwiek sposób z zarządzaniem projektami - napisz...z pewnością umieszczę go na PMblogs.pl Możesz również skorzystać z formularza. Wpis na stronie pojawi się dopiero po zatwierdzeniu przeze mnie.
Szablony dokumentów do Prince2
English
German
Spanish
Swedish Polecam stronę ajwilcox.co.uk na której można znaleźć szablony dokumentów do metodyki Prince2 (v.2005). Ciekawym pomysłem jest zebranie ich w formie mapy myśli.
Polecam również (niestety już archiwalne) źródło, w którym również można znaleźć gotowe do pobrania szablony dokumentów jak również istotne wskazówki co do ich wypełniania.
Dlaczego projekty upadają, czyli przyczyny niepowodzeń projektów IT
Rozpatrując różne metodyki zarządzania projektami, należy sobie zadać pytanie w jakim celu one zostały sporządzone i czy nawet zastosowanie się do wszystkich wytycznych konkretnej metodyki gwarantuje sukces projektu.
Związki pomiędzy cechami w trójkącie zależności są bardzo silne – modyfikując jeden parametr wpływamy w znaczący sposób na inny zaburzając hierarchię wartości. To zadanie z pozoru wydające się proste, w rzeczywistych warunkach prowadzenia przedsięwzięcia informatycznego jest niezwykle trudne do prawidłowego przeprowadzenia, o czym stanowią wyniki badań amerykańskiej firmy „The Standish Group”.
W swoim raporcie „The Chaos Report” z roku 1995 można zauważyć, że aż 31,1 % projektów informatycznych (ponad 80 000) zostało anulowanych przed zakończeniem prac. Ważną informację jest również to, iż ponad połowa ogółu przedsięwzięć (52,7 %) przekroczyła swój pierwotny budżet.
„The Standish Group” wyliczyło, że tylko w roku 1995 amerykańskie firmy wydały 81 miliardów dolarów na projekty, które nie zostały ukończone. Koszty samego dofinansowania projektów, aby mogły zostać w ogóle ukończone, w tym samym roku wyniosły ponad 51 miliardów dolarów.
Przeciętnie tylko 16,2 % projektów zostało ukończonych zgodnie z założonym budżetem oraz w wyznaczonych ramach czasowych. Sytuacja jeszcze gorzej wyglądała w przypadku największych firm, gdzie zaledwie 9 % przedsięwzięć kończyło się pełnym sukcesem.
Biorąc pod uwagę tak duży odsetek projektów zakończonych porażką lub też niepełnym sukcesem, należy zadać sobie pytanie co tak naprawdę jest powodem tego, że niektóre przedsięwzięcia okazują się być wielkim sukcesem a inne porażką. Raport przygotowany przez firmę „The Standish Group” wskazuje na dziesięć głównych przyczyn porażek:
1) brak informacji kluczowych od klienta/sponsora projektu,
2) brak kompleksowego zdefiniowania wymagań i funkcjonalności projektu,
3) zmiana wymagań i funkcjonalności w czasie trwania projektu,
4) brak wsparcia ze strony kierownictwa projektu,
5) brak wystarczającej wiedzy i doświadczenia w danej dziedzinie,
6) niekompletny zespół,
7) zbyt wygórowane oczekiwania klienta,
8) zbyt słabo zdefiniowane cele,
9) trudne do spełnienia ramy czasowe projektu,
10) nowe technologie.
Pomimo tego, że analiza przyczyn porażek przedsięwzięć została przeprowadzona głównie dla branży IT, są to jednak czynniki, które są uniwersalne, niezależnie od obszaru gospodarki w której występują.
Czynnikiem który niejednokrotnie wpływa na to, iż projekt kończy się nieosiągnięciem celu, jaki między innymi jest zmieszczenie się w przydzielonych zasobach bądź całkowitą jego porażką jest oprócz umiejętnego zarządzania ryzykiem przez kierownika projektu bądź grupę prowadzącą przedsięwzięcie biegłe zarządzanie realizacją harmonogramu oraz budżetu. Rzeczywisty odsetek projektów z branży IT, które ukończyły się w granicach założonego budżetu oraz w założonym wcześniej czasie jest stosunkowo niewielki, wręcz marginalny.
Aby jeszcze lepiej zrozumieć przyczyny porażki i podnieść skutecznej poziom ich eliminacji, dwie firmy (VirtalSmarts oraz The Concours Group) sporządziły tzw. pięć krytycznych obszarów zarządzania, na które składają się:
1. Zbyt szczegółowe planowanie harmonogramu (włącznie z datami i zasobami), które w znaczny sposób odbiegają od rzeczywistości, skazując przedsięwzięcie na porażkę.
2. Brak odpowiedniego zaangażowania w projekt i wsparcia grupy ją realizującej ze strony sponsorów projektu – poświęcają zbyt mało czasu i uwagi aby doprowadzić projekt do końca.
3. Lekceważenie priorytetów zadań przez członków zespołu.
4. Bagatelizowanie i nieujawnianie problemów – lider projektu oraz członkowie zespołu nie sygnalizują występujących w projekcie problemów – czekają aż ktoś inny o tym powie lub zapyta.
5. Członkowie zespołu nie posiadają odpowiedniej wiedzy i doświadczenia aby skutecznie zrealizować powierzone im zadania lub nie są w stanie/nie chcą zaangażować się w efektywną realizację projektu.
Z przeprowadzonych badań zawartych w raporcie wynikało jednoznacznie, iż jeżeli chociaż jedno z powyższych krytycznych obszarów zarządzania przedsięwzięciem zostanie zaniedbane i nie zostaną z wyciągnięte z tego żadne wnioski to prawdopodobieństwo zakończenia projektu porażką (zdefiniowane jako przekroczenie budżetu, ram czasowych oraz niespełnienie wymagań co do wymaganej funkcjonalności oraz jakości) wzrasta nawet do 85%. Natomiast jeśli zarówno zespół jak i kierownik projektu przykładają odpowiednią wagę do tych obszarów prawdopodobieństwo zakończenia przedsięwzięcia porażką spada nawet do 50-70% (na podstawie ankiety przeprowadzonej na ponad 1000 menedżerów projektów oraz dyrektorów z 40 firm z najróżniejszych dziedzin gospodarki w USA i Europie.)
Na podstawie przeprowadzonych badań „The Standish Group” określiła również jedenaście najważniejszych cech, które pośrednio przekładają się na ostateczny sukces projektu:
Cecha / Waga cechy [%]
Zaangażowanie klienta/sponsora / 15,9
Wsparcie kierownictwa / 13,9
Dobrze określone wymagania / 13,0
Odpowiednie planowanie / 9,6
Realistyczne cele / 8,2
Małe odstępy pomiędzy kamieniami milowymi / 7,7
Kompetencje pracowników / 7,2
Odpowiedzialność zespołu / 5,3
Jasno zdefiniowane cele i wymagania / 2,9
Ciężko pracujący pracownicy / 2,4
Pozostałe / 13,9
Z powyższego raportu jasno wynika, że główną przyczyną upadków projektów są błędy w warstwie zarządzania. Dopiero w dalszej części dotyczą bezpośrednio pracy zespołu oraz kompetencji jej członków. Od razu nasuwa się wniosek, iż nawet najlepszy zespół projektowy, będzie miał ogromne problemy z realizacją projektu, jeśli ten będzie po prostu źle prowadzony. Dlatego właśnie kwestia metodyk zarządzania projektami, skupiająca się szczególnie na poziomie zarządzania przedsięwzięciem ma tak krytyczne znaczenie w kontekście ewentualnego sukcesu lub porażki.
Tak jak zostało powiedziane powyżej, rozróżnia się wiele metodyk zarządzania przedsięwzięciami. Nie ma jednej uniwersalnej metodyki dobrej na wszystkie bolączki kierowników projektów, gdyż należy pamiętać iż, metodyka nie mówi jak coś zrobić lecz daje szerszy obraz projektu jako całości, uwypuklając pewne, newralgiczne miejsca
w projekcie, które kierownik projektu powinien umieć zauważyć, odpowiednio zanalizować i skutecznie reagować na nie.
Metodyka jest pewnym zbiorem wzorców, zasad oraz etykiet, które pomagają w uniknięciu błędów, lecz nie niwelują ich zupełnie. Pomimo tego, konsekwentnie wdrożona daje gwarancję szeregu bardzo ważnych elementów:
• pełna kontrola przedsięwzięcia od jego początku aż do zakończenia,
• pełne i odpowiednie zaangażowanie wszystkich zainteresowanych stron,
• gwarancja aktualnego uzasadnienia biznesowego przedsięwzięcia, a więc bezpieczeństwo biznesu sponsora
Źródła:
• http://www.it-cortex.com/Stat_Failure_Rate.htm
• http://www.cognitive-it.pl/projekt-it-zarzadzanie-projektami-it-projekty informatyczne,d9
• http://www.artzi.net/content/view/93/89/
• http://www.standishgroup.com/