Blog “Owymaganiach.pl”
Polecam blog Owymaganiach.pl, w którym autor porusza obszar zarządzania wymaganiami w IT. Jest to jedna z nielicznych i bardziej sensownych stron w Polsce poruszających zarządzanie wymaganiami w tak obszerny i zarazem ciekawy sposób.
BABOK 2.0 dostępny za darmo
Business Analyst Body of Knowledge 2.0, czyli BABOK 2.0 został udostępniony online za darmo w google books.
BABOK jest tym czym PMBOK dla PMI, czyli "skrzynką z narzędziami" (zbiorem metod, narzędzi, dobrych praktych).
Ci którzy chcą posiąść wersję w standardowej formie muszą liczyć się z wydatkiem rzędu około 30$. W dalszym ciągu dla członków IIBA ta wersja jest bezpłatna. Więcej informacji na stronie IIBA.
Ryzyka w projektach IT wg PMI oraz PRINCE2
Aby zdać sobie sprawę z różnic i podobieństw w podejściach zarządzania ryzykiem, należy zadać sobie pytanie, czym tak naprawdę jest samo pojęcie ryzyka.
Według PMBOK ryzyko jest to niepewne wydarzenie lub okoliczność, które jeśli zajdzie może mieć zarówno negatywne jak również pozytywne konsekwencje przynajmniej na jeden z celów projektu, takich jak koszt, czas, zakres lub jakość. Ryzyko może mieć jedną lub więcej przyczyn oraz w przypadku wystąpienia jeden lub więcej obszarów skutków. Już sama definicja ryzyka wg PMI jest w pewien sposób niekonsekwentna z tym na czym metodyka PMI skupia się w procesie zarządzania ryzykiem – głównie na procesie wykrywania, monitorowania oraz zarządzania ryzykami mających przede wszystkim negatywny wpływ na projekt. Pomimo tego, że jest wspomniane o pozytywnym wpływie nieprzewidzianych czynników na cele projektu, nie jest przewidziany żaden proces mający za zadanie obsługę szans.
Sytuacja ta ma związek z bardzo małym prawdopodobieństwem wystąpienia skutków pozytywnych w porównaniu z negatywnymi oraz nieopłacalnością zarządzania szansami – bardziej opłaca się niwelować zagrożenia niż liczyć na pojawienie się przychylnych okoliczności podczas trwania projektu. Nie oznacza to jednak, że regułą jest niepodejmowanie zarządzania szansami w sytuacji gdy taka okoliczność zaistnieje.
Oprócz standardowego podziału na zagrożenia i okazje amerykańska metodyka zarządzania przedsięwzięciami dzieli ryzyka dodatkowo na:
- techniczne, związane z wszystkimi czynnikami skupiającymi się na proces wytwarzania produktu, jego jakością, wielkością, stopniem skomplikowania itp.,
- zarządcze, związane z obszarem zarządzania projektem, priorytetowania zadań, rozliczania, kontroli itp.,
- organizacyjne, związane z odpowiednim przydzielaniem zasobów do przedsięwzięcia,
- zewnętrzne, które powstają w otoczeniu którego działa projekt (np. zmiana wymagań klienta, zmiany ustawowe itp.)
Z kolej metodyka Prince2 definiuje pojęcie ryzyka, jako narażenie projektu na negatywne konsekwencje przyszłych wydarzeń. Brak jest w tym wypadku jakiejkolwiek wzmianki o pozytywnym wpływie na cele projektu.
Prince2, jako metodyka typowo organizacyjna, dzieli ryzyka na dwie grupy:
- biznesowe, które są powiązane z zaburzeniem procesów biznesowych w organizacji, które umożliwiłyby osiągnięcie określonych zysków, jak np. niedostarczenie funkcjonalności na czas, zmiany w prawie. Należy zauważyć, że są to zarówno zaburzenia w odniesieniu do konkretnych korzyści zarówno ze strony firmy realizującej dane przedsięwzięcie jak również jej klienta
- projektowe, związane przede wszystkim z osiągnięciem celów projektu zgodnie
z zaplanowanym harmonogramem
W dalszej części są one klasyfikowane jako:
- związane z kontrahentami,
- czynniki organizacyjne,
- zagadnienia techniczne
Z kolei z samego pojęcia ryzyka, możemy wyodrębnić tzw. składniki ryzyka, na które składają się:
- Zdarzenie – zjawisko, które może nastąpić, lub przekształcenie potencjalnego ryzyka na faktyczne wydarzenie;
- Prawdopodobieństwo – stopień pewności wystąpienia zdarzenia;
- Skutki wystąpienia – stopień, w jakim zdarzenie może wpłynąć na koszty, harmonogram lub jakość papieru
Dzięki takiemu rozbiciu ryzyka na składowe, możemy w przejrzysty sposób zidentyfikować ryzyko w przedsięwzięciu i w konsekwencji nim zarządzać. Sam proces zarządzania opiera się na systematycznej identyfikacji, analizie oraz reakcji.
Szablony dokumentów do PRINCE2
Polecam stronę ajwilcox.co.uk na której można znaleźć szablony dokumentów do metodyki Prince2. 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.
IBM Business Analyst e-Kit
Na stronie firmy IBM można znaleźć wiele cennych informacji związanych z analizą biznesową. Niektóre z nich można znaleźć tutaj , jako swego rodzaju Business Analyst e-Kit (white paper, dema, podcasty).
Dostęp wymaga zalogowania i jest darmowy. Polecam.
Z serii nigdy tego nie rób… czyli jeśli nie chcesz “położyć” projektu to…
Ostatnio przeczytałem interesujący artykuł Laury Branedburg, która w ciekawy i momentami wydający się wręcz przesadny sposób pokazuje jak w kilku prostych krokach można "położyć projekt". Oto kilka czynników na które zwraca szczególną uwagę:
- Zbytnia wiara w najnowsze technologie, które "gwarantują sukces przedsięwzięcia",
- Brak dogłębnej znajomości technologii, w której ma zostać wykonany projekt,
- Lekka ręka do wydawania pieniędzy na szkolenia zespołu, zakup oprogramowania, itp,
- Pomieszanie kolejności podejmowania pewnych decyzji,
- Brak dogłębnej analizy otoczenia biznesowego projektu,
- Brak dogłębnej analizy potrzeb/wymagań klienta,
- Brak poprawności w definiowaniu kamieni milowych oraz ich późniejsze nie przestrzeganie,
- Dopuszczanie myśli, że projekt się nie uda i mówienie o tym klientowi,
- Przechodzenie do pisania kodu według własnej, wyidealizowanej wizji a nie wizji biznesu,
- Ignorowanie kontaktu z osobami, które mają bezpośrednio używać system,
- Brak testów aplikacji,
Część z tych punktów wydać się może lakoniczna, ale często takie proste do przewidzenia w skutkach błędy się zdarzają. Oczywiście nie wszystkie te czynniki muszą zaistnieć w projekcie aby przedsięwzięcie okazało się fiaskiem ale warto zdawać sobie z nich sprawę i postępować rozsądnie od samego momentu inicjacji projektu aż do jego zakończenia.
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ę:
- 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ę.
- 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.
- Lekceważenie priorytetów zadań przez członków zespołu.
- 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.
- 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/