Zarządzanie ryzykiem to proza życia kierowników projektów. Z jednej strony doświadczony kierownik projektu powinien doskonale radzić sobie z ryzykiem, z drugiej zaś strony praktyka projektów pokazuje, że efekty są niestety słabe bo ok. 90% IT na świecie ma przekrocozne budżety i terminy . Jednym z ciekawszych narzędzi zarządzania ryzykiem jest mało popularny tak zwany stożek niepewności. Ogólna zasada planowania mówi, że im bardziej w przyszłość wybiegają prognozy tym bardziej są one niepewne. Jest nie tylko intuicyjne ale i udowodnione matematycznie. Stożek niepewności to wykres pokazujący związek pomiędzy kosztami projektu a…
Uszczegóławianie wymagań odkładamy "na ostatni moment". W ten sposób "kwartał po kwartale" doprecyzowujemy wymagania na kolejny etap i realizujemy go. Co zyskujemy? Nie wyrzucamy do kosza nadmiernie szczegółowej i rozległej dokumentacji wymagań, nie ponosimy koszów projektowania czegoś co może "wylecieć" z zakresu za pół roku z powodów np. zmian na rynku, możemy w dowolnym momencie zmienić kolejne planowane komponenty, usunąć jedne i opracować nowe bez ryzyka zbędnych kosztów.Pierwszy etap ma pewną cechę: tworzy jeden wspólny model wszystkich projektów dla danej organizacji o wdzięcznej nazwie Architektura Korporacyjna. Kolejne konkretne komponenty architektury IT to kolejne projekty, cechujące się umiejscowieniem w całości organizacji i wiarygodnym, spójnym z całością zakresem.Dlatego z reguły nie mają sensu:wdrożenia departamentowe oderwane od reszty (np. Dział Handlowy sobie funduje sam system CRM),
projekty trwające dłużej niż trzy kwartały (ostatni kwartał to kolejne planowanie budżetu na kolejny rok czyli planowanie zmian),
mega projekty ERPII czyli "all in one" dla firmy w ramach jednego projektu.
Więc jak zjeść słonia by się nie udławić? Powoli i po kawałku...
Krótki wpis po pewnej nie długiej dyskusji na pewnym forum. Jeden z dyskutantów przytoczył definicję zakresu projektu publikowaną w WIKI:Zakres projektu jest to możliwie jak najdokładniejsze i całkowite określenie oczekiwanego wyniku projektu.Zakres nigdy nie określa konkretnych zadań mających na celu realizację projektu. Odpowiada na pytanie, co powinno być zrobione w projekcie. Wyznacza ramy do oszacowania kosztu projektu i czasu realizacji projektu. Zakres, koszt i czas tworzą parametry projektu, tzw. ?magiczny trójkąt?. (Zakres projektu ? Wikipedia, wolna encyklopedia).Tak więc mamy pytanie: "co powinno być zrobione w projekcie"? Pytanie jakie ja postawiłem: "czyim projekcie"? Zakres projektu dla kogo? [...] W moich oczach nie ma nic bardziej ryzykownego niż przekazanie Opisu Księgowej od razu programistom do wykonania. Bo mamy tak na prawdę trzy zakresy projektu, każdy inny, każdy ma innego adresata i każdy należy udokumentować inaczej, ale zawsze jednoznacznie postawić zadanie.Praca bez tego typu dokumentów, bez jasnego wydzielenia poszczególnych etapów analizy, tak często praktykowana przez wiele firm IT, to atak na twierdzę bez mapy terenu i strategii...
