LISTA CZYNNIKÓW RYZYKA DLA HARMONOGRAMU

Zarządzanie Projektem Informatycznym
LISTA CZYNNIKÓW RYZYKA DLA HARMONOGRAMU
Steve McConnell, Rapid Development, Microsoft Press, 1996
tłumaczenie Janusz Górski
1. PLAN
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
Harmonogram, zasoby i definicja systemu zostały narzucone, i nie są spójne (są nierealne)
Harmonogram jest optymistyczny “najlepszy przypadek”, a nie realistyczny “oczekiwany
przypadek”
Plan nie uwzględnia zadań, których wykonanie będzie konieczne
Plan opracowano przy załoŜeniu dostępności konkretnych ludzi, których dostępności nie da się
zagwarantować
Nie da się zbudować produktu w takiej skali przy tak zaplanowanych nakładach
Produkt jest większy niŜ to oszacowano (LOC, FP czy % rozmiaru poprzedniego produktu)
Nakłady są większe niŜ oszacowano (na LOC, FP, moduł itp)
W wyniku poślizgu projektu, powtórne oszacowanie jest zbyt optymistyczne i ignoruje historię
projektu
Nadmierna presja ze strony terminów zmniejsza produktywność
Termin uległ skróceniu bez odwzorowania tego faktu w dostępnych zasobach lub zakresie
projektu
Opóźnienie jednego zadania powoduje “efekt domina” – opóźnienie zadań zaleŜnych
Nieznane (w stosunku do których brak doświadczenia) obszary wymagają większych niŜ się
spodziewano nakładów (projekt i implementacja)
2. ORGANIZACJA I ZARZĄDZANIE
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
Projekt nie ma (efektywnego) sponsora w najwyŜszym kierownictwie
Projekt grzęźnie na zbyt długo w (rozmytym) stadium poczatkowym
Przestoje i zmiany kierunku zmniejszają potencjał i skuteczność zespołu
Kierownictwo lub marketing upiera się przy decyzjach technicznych, które powodują
wydłuŜenie projektu
Nieefektywna struktura zespołu zmniejsza produktywność
Cykl oceny i podejmowania decyzji ze strony kierownictwa jest zbyt długi w stosunku do
oczekiwanego
Cięcia budŜetowe zakłócają plany projektu
Kierownictwo podejmuje decyzje, które obniŜają motywacje zespołu
Zadania stowarzyszone (wykonywane na zewnątrz) zabierają więcej czasu niŜ się spodziewano
(zatwierdzanie budŜetu, zakup sprzętu i wyposaŜenia, opinie prawników, zatwierdzanie przez
róŜne szczeble itp.)
Planowanie nie jest realizowane w sposób, który wspiera niezbędne tempo realizacji projektu
Palny projektu są zarzucane w obecności róŜnych nacisków i praca jest wykonywana
chaotycznie i nieefektywnie
Kierownictwo bardziej preferuje “herosów” niŜ rzetelną informacje o stanie projektu, co
zmniejsza zdolność do wykrywania i korygowania problemów
3. ŚRODOWISKO WYTWÓRCZE
[25]
[26]
[27]
[28]
Środki nie są dostępne na czas
Środki są dostępne, ale są nieadekwatne (np. brak telefonów, infrastruktury sieciowej, mebli,
wyposaŜenia biurowego itp.)
Warunki pracy są złe (zatłoczenie, duŜy poziom hałasu, brak moŜliwości skupienia się)
Niezbędne narzędzia nie są dostępne wtedy gdy są potrzebne
Strona 1 / 4
Zarządzanie Projektem Informatycznym
[29]
[30]
Narzędzia wspomagające wytwarzanie nie funkcjonują zgodnie z oczekiwaniami - inŜynierowie
zuŜywają czas na ich dopasowanie do potrzeb lub na zaznajamianie się z nowymi narzędziami
Narzędzia wspomagające nie są wyselekcjonowane na bazie ich wartości technicznej i nie mają
oczekiwanej wydajności
4. UśYTKOWNICY KOŃCOWI
[31]
[32]
[33]
[34]
UŜytkownicy upierają się przy wprowadzeniu nowych wymagań
UŜytkownicy oceniają dostarczane im produkty jako niezadowalające, co powoduje
konieczność powtórzenia etapu projektowania i powtórzenia wykonanej pracy
UŜytkownicy nie włączają się do projektu i w konsekwencji nie dają niezbędnego wsparcia
Poglądy uŜytkowników nie są zbieŜne i w konsekwencji produkt nie spełnia wszystkich
oczekiwań i musi być przeprojektowany
5. KLIENT
[35]
[36]
[37]
[38]
[39]
[40]
[41]
[42]
[43]
[44]
[45]
Klient upiera się przy nowych wymaganiach
Przeglądy i decyzje Klienta dotyczące planów, prototypów i specyfikacji są wolniejsze niŜ
oczekiwano
Klient nie uczestniczy w przeglądach planów, prototypów i specyfikacji lub jest niezdolny do
ich wykonywania – co skutkuje niestabilnością wymagań i wielokrotnymi zmianami
Komunikacja z Klientem (np. w zakresie uzgodnień i wyjaśnień dotyczących wymagań) jest
wolniejsza niŜ to oczekiwano
Klient upiera się przy decyzjach technicznych, które skutkują wydłuŜeniem czasu realizacji
Klient wtrąca się w szczegóły kierowania projektem, co skutkuje zwolnieniem realizacji
planów projektu
Elementy dostarczane przez Klienta są niespójne z wytwarzanym produktem, co wymaga
dodatkowej pracy projektowo-integracyjnej
Elementy dostarczane przez Klienta mają niską jakość co wymaga dodatkowego testowania,
projektowania i nakładów na integrację oraz dodatkowych nakładów na zarządzanie relacją z
Klientem
Środowisko i narzędzia po stronie Klienta są niekompatybilne, mają niską wydajność lub
nieadekwatną funkcjonalność, co zmniejsza produktywność
Klient nie akceptuje dostarczonego produktu pomimo tego, Ŝe spełnia on wszystkie wymagania
Klient ma odnośnie szybkości wytwarzania oczekiwania, których dostawca nie jest w stanie
wypełnić
6. ZLECENIOBIORCY
[46]
[47]
[48]
Zleceniobiorca nie dostarcza produktu na czas
Zleceniobiorca dostarcza komponenty o nieakceptowanej jakości i potrzeba dodatkowego czasu
na poprawę ich jakości
Zleceniobiorca nie włącza się w projekt i w konsekwencji nie realizuje swoich zadań na
wymaganym poziomie wydajności
7. WYMAGANIA
[49]
[50]
[51]
[52]
Wymagania zostały zamroŜone ale wciąŜ pojawiają się nowe zapotrzebowania na zmiany
Wymagania są słabo zdefiniowane, a ich poprawa powoduje poszerzenie zakresu projektu
Dodawane są nowe wymagania
Zgrubnie zdefiniowane wymagania dotyczące produktu wymagają więcej pracy niŜ oczekiwano
Strona 2 / 4
Zarządzanie Projektem Informatycznym
8. PRODUKT
[53]
[54]
[55]
[56]
[57]
[58]
[59]
[60]
[61]
[62]
[63]
[64]
[65]
[66]
Błędorodne moduły wymagają więcej nakładów na testowanie, projektowanie i implementację
niŜ oczekiwano
Niska jakość wymaga więcej nakładów na testowanie, projektowanie i implementację jej
poprawy niŜ oczekiwano
Wytworzono niewłaściwe funkcje oprogramowania, które wymagają przeprojektowania i
ponownej implementacji
Wytworzono niewłaściwy interfejs uŜytkownika, który wymaga przeprojektowania i ponownej
implementacji
Wytworzenie nadmiarowych funkcji, które nie były wymagane (“pozłacanie”) wydłuŜa
realizację
Spełnienie wymagań wydajnościowych wymaga więcej czasu niŜ oczekiwano, włączając w to
czas na przeprojektowanie i ponowną implementację
Wymagania dotyczące zgodności z juŜ istniejącym systemem wymagają więcej czasu na
testowanie, projektowanie i implementację niŜ oczekiwano
Wymagania związane z interfejsami z innymi systemami lub systemami, które nie leŜą w
zakresie kontroli projektu wymagają więcej czasu na testowanie, projektowanie i
implementację niŜ oczekiwano
Wprowadzenie do projektu najnowszych osiągnięć technologicznych wydłuŜa pracę w sposób
niezaplanowany
Wymaganie aby produkt działał na róŜnych platformach (systemy operacyjne) wymaga więcej
czasu na testowanie, projektowanie i implementację niŜ oczekiwano
Zastosowanie nieznanego wcześniej i niepewnego środowiska programistycznego powoduje
nieprzewidziane problemy
Zastosowanie nieznanego wcześniej i niepewnego środowiska sprzętowego powoduje
nieprzewidziane problemy
Wytworzenie komponentu, z którym nie było dotychczas doświadczeń zabiera więcej czasu niŜ
oczekiwano
UzaleŜnienie od technologii niedojrzałej (wciąŜ w trakcie rozwoju) wydłuŜa czas realizacji
9. ŚRODOWISKO ZEWNĘTRZNE
[67]
[68]
Produkt jest uzaleŜniony od uregulowań i przepisów, które uległy niespodziewanej zmianie
Produkt jest uzaleŜniony od standardów, które uległy niespodziewanej zmianie
10. PERSONEL
[69]
[70]
[71]
[72]
[73]
[74]
[75]
[76]
[77]
[78]
[79]
[80]
Zatrudnienie potrzebnych ludzi trwa dłuŜej niŜ oczekiwano
Przygotowanie do realizacji zadań (np. szkolenie, zakończenie innych projektów, pozyskanie
zgody na zatrudnienie) nie moŜe być zakończone w zaplanowanym terminie
Wadliwa relacja pomiędzy zespołem wytwórczym i kierownictwem zwalnia procesy decyzyjne
i tempo pracy
Członkowie zespołu nie utoŜsamiają się z projektem i w konsekwencji nie pracują tak wydajnie
jak oczekiwano
Zespół ma niska motywację i morale, co obniŜa wydajność
Brak jest niezbędnej specjalizacji, co zwiększa liczę defektów i potrzebę ponawiania pracy
Personel potrzebuje dodatkowego czasu na zaznajomienie się z narzędziami i środowiskiem
pracy
Personel potrzebuje dodatkowego czasu na zaznajomienie się ze środowiskiem sprzętowym
Personel potrzebuje dodatkowego czasu na zaznajomienie się nieznanym wcześniej językiem
programowania
Personel kontraktowy zwalnia się przed zakończeniem projektu
Stały personel zwalnia się przed zakończeniem projektu
Nowy personel jest włączany do projektu w stadium znacznego zaawansowania, co wymaga
nakładów na szkolenie, komunikację oraz obniŜa efektywność całego zespołu
Strona 3 / 4
Zarządzanie Projektem Informatycznym
[81]
[82]
[83]
[84]
[85]
[86]
[87]
[88]
[89]
[90]
[91]
[92]
Członkowie zespołu nie współpracują ze sobą efektywnie
Konflikty w ramach zespołu powodują słabą komunikację, wadliwe rozwiązania projektowe,
błędy interfejsów i w efekcie dodatkową pracę
Członkowie zespołu, którzy powodują problemy nie są usuwani z zespołu, co niszczy
motywację całego zespołu
Personel o najbardziej poŜądanych kwalifikacjach nie jest dostępny w projekcie
Personel o najbardziej poŜądanych kwalifikacjach jest dostępny ale nie jest wykorzystywany z
innych powodów (np. lokalna polityka)
Nie moŜna znaleźć personelu o najbardziej poŜądanych (krytycznych dla projektu)
kwalifikacjach
Kluczowy personel jest dostępny jedynie w ograniczonym czasie (np. część etatu)
Nie ma wystarczającej liczby personelu na realizację projektu
Przypisanie zadań członkom zespołu nie odpowiada ich potencjałowi
Personel pracuje wolniej niŜ oczekiwano
SabotaŜ ze strony kierownictwa skutkuje nieefektywnym harmonogramowaniem i planowaniem
SabotaŜ ze strony personelu skutkuje zbędną pracą lub niską jakością, wymagającą powtórzenia
pracy
11. PROJEKTOWANIE I IMPLEMENTACJA
[93]
[94]
[95]
[96]
[97]
[98]
[99]
[100]
Nadmiernie skomplikowany projekt skutkuje nadmiarową i nieproduktywną pracą podczas
implementacji
Niewłaściwy projekt powoduje potrzebę przeprojektowania i powtórnej implementacji
Wybór nieznanej wcześniej metodologii powoduje nakłady na dodatkowe szkolenie, nakłady
pracy na poprawę błędów wynikających z niezrozumienia i niewłaściwego jej zastosowania
Produkt jest implementowany w języku niskiego poziomu (np. asembler) co powoduje, Ŝe
wydajność jest niŜsza od oczekiwanej
Niezbędnej funkcjonalności nie da się zaimplementować na bazie wybranych bibliotek;
wytwórcy muszą zacząć stosować inne biblioteki lub zrealizować niezbędne funkcje “od zera”
Wykorzystywane biblioteki kodu i klas mają niską jakość co wymaga dodatkowych nakładów
na testowanie, poprawę błędów i ponawianą pracę
Przeszacowano zyski czasu z zastosowania narzędzi zwiększających wydajność (np. generacja
kodu)
Komponenty wykonane niezaleŜnie nie dają się zintegrować co wymaga dodatkowych
nakładów na przeprojektowanie i poprawę implementacji
12. PROCES
[101]
[102]
[103]
[104]
[105]
[106]
[107]
[108]
[109]
Zbiurokratyzowanie procesu (nadmiar pracy “papierkowej”) zwalnia tempo projektu
Nieadekwatne śledzenie projektu powoduje, Ŝe zbyt późno zauwaŜono, Ŝe projekt jest
opóźniony
Wstępujące (upstream) działania pro-jakościowe (przeglądy, inspekcje) zostały zaniechane, co
powoduje wzrost nakładów i ponawianie pracy w dalszych etapach (downstream)
Nieadekwatne śledzenie jakości powoduje, Ŝe problemy z jakością są zauwaŜane dopiero w
ostatnich fazach projektu
Zbyt słabe sformalizowanie pracy (brak przestrzegania zasad i standardów) powoduje
nieporozumienia, problemy z jakością i potrzebę ponawiania pracy
Przebiurokratyzowanie pracy (zbyt ścisłe, sformalizowane przestrzeganie zasad i standardów)
powoduje zbędny, czasochłonny narzut
Sprawozdawczość na potrzeby kierownictwa projektu zabiera więcej czasu (który mógłby być
poświecony na pracę wytwórczą) niŜ oczekiwano
Zdawkowe zarządzanie ryzykiem powoduje, Ŝe nie dostrzeŜono powaŜnych zagroŜeń
Zarządzanie ryzykiem zajmuje więcej czasu niŜ oczekiwano
Strona 4 / 4