Zadanie projektowe ZPI

Zadanie projektowe ZPI
Zadaniem jest opracowanie Planu Realizacji hipotetycznego projektu. Wymagane jest stworzenie
nast pujcych dokumentów:
• załoenia składajce si z:
• informacji o tym gdzie projekt jest realizowany (wewntrz firmy, na zewntrz),
• informacji o tym w jakiej technologii jest realizowany,
• innych informacji niezb dnych do zrozumienia dalszych dokumentów
• rozpocz cie projektu składajce si z:
• wst pu
• definicji zakresu projektu
• organizacji projektu
• procedur sterowania i kontroli projektu
• zgrubny plan projektu
• analizy ryzyka projektu
Istotne terminy
•
Do 14 kwietnia 2011 – zapoznanie si z zadaniem i zgłoszenie si do prowadzcego w celu
zaproponowania tematyki projektu i wyjanienia wtpliwoci.
•
Do 12 maja 2011 – prezentacja wst pnej wersji
(dokumentacja nie musi by kompletna i dopracowana).
•
Do 2 czerwca 2011 – oddanie ko cowej wersji dokumentacji.
przygotowywanej
dokumentacji
1
Rozpocz cie projektu
Projekt informatyczny jest zwykle dzielony na trzy cz ci - rozpocz cie, prowadzenie i zako czenie.
Rozpocz cie projektu zwizane jest z takimi pracami jak: wygranie kontraktu, przygotowanie
rodowiska i planu prac projektu, okrelenie terminów i kosztów itp. W wyniku rozpocz cia projektu
powinny powsta nast pujce dokumenty:
•
•
•
•
•
zakres projektu,
organizacja projektu,
procedury sterowania i kontroli projektu,
analiza ryzyka,
plan projektu.
Dokumenty te pozwalaj na jasne okrelenie zasad współpracy pomi dzy projektodawc a wykonawc
a take zasad post powania, gdy współpraca nie idzie tak, jak powinna.
Istniej dwie metody wyliczania kosztów projektu. Jedna z nich zakłada, e projektodawca otrzymuje
wyłcznie cen ko cow, bez szczegółowych rozlicze . Takie podejcie pozwala z jednej strony na
zwi kszenie marginesu zysku, ale z drugiej w przypadku pojawienia si problemów trudno jest
pokaza jaki jest ich rzeczywisty koszt. Druga z metod wyliczania kosztów zakłada, e projektodawca
zna dokładnie wszystkie szczegółowe obliczenia kosztów i zysk wykonawcy. Przy tak zdefiniowanej
współpracy mo na modyfikowa ko cow cen projektu w czasie jego prowadzenia, tak by zysk
wykonawcy był stały. Oczywicie taka forma współpracy jest znacznie trudniejsza do
wynegocjowania, ale jest tego warta. Praktyka pokazuje, e kady projekt ma jakie problemy i bez
bardzo duego marginesu zysku metoda pierwsza zawodzi. Jednak niewielu klientów decyduje si na
podpisanie kontraktu bez jasno okrelonej ceny nie wiedzc e ley to take w ich interesie. Zadaniem
kierownika projektu jest przekonanie klienta do takiej formy kontraktu.
Zdefiniowanie zakresu projektu
Jednym z najwaniejszych elementów rozpocz cia projektu zwykle przesdzajcym o jego
powodzeniu jest jasne i cisłe zdefiniowanie zakresu projektu. Zakres projektu jest to dokładne
okrelenie co naley w ramach projektu zrobi. Dobrze zdefiniowany zakres projektu powinien
uwzgl dnia trzy aspekty:
•
•
•
biznesowy - jakie cele biznesowe b dzie mona osign dzi ki systemowi;
uytkowy - jak b dzie mo na to osign z punktu widzenia uytkownika, jakie funkcje b d
dost pne, jak zrealizowana b dzie interakcja z uytkownikiem itp.;
techniczny - jak zbudowany b dzie system (technologia sprz tu i oprogramowania), jak
b dzie zrealizowane zarzdzanie, ochrona i archiwizacja danych itp.
Cel:
• jasno zdefiniowa granice projektu
w sposób który
• identyfikuje typy ogranicze (wymiary projektu) znaczce dla projektu
• bierze pod uwag dotychczasowe zdarzenia z projektem
• pokazuje zbiór moliwych celów i zakresów projektu, które projekt mógłby obj • jasno i dokładnie definiuje co projekt nie obejmuje (ograniczenie interpretacji - patrz GUC)
• jasno i dokładnie definiuje co projekt obejmuje
tak e
• istnieje i jest dost pny dla wszystkich zainteresowanych jasny i zrozumiały cel oraz miara
jego osigni cia. Cel ten pozwala na sterowanie kierunkiem projektu i oszacowanie jakoci
produktu finalnego.
2
Proponowana kolejno czynnoci które naley wykona:
• Uzgodni cele biznesowe
Naley przeprowadzi spotkanie i wywiady z reprezentantami (trzeba ich wybra), tak by
zidentyfikowa główne cele biznesowe i wymagania krytyczne. Co to s wymagania
krytyczne - w du ym skrócie wymagania, których nie spełnienie gwarantuje niepowodzenie
projektu. Cele i wymagania daj nam nie tylko kryteria ocenienia jakoci produktów, ale take
kryteria do stworzenia wymaga ilociowych, estymacji spodziewanych zysków.
• Ustali zakres bada
Zidentyfikowa i uzgodni stopnie swobody rozwizania oraz ograniczenia. Dla kadego ze
stopni swobody okreli, co b dzie zawarte w zakresie projektu a co nie b dzie. Naley
sprawdzi, czy wszystkie aspekty krytyczne dla powodzenia projektu zawarte s w wybranych
stopniach swobody.
Przykładowe stopnie swobody to:
• interface’y zewn trzne (przykład - współpraca z istniejcym systemem)
• lokalizacja geograficzna (przykład - rozproszona baza danych)
• jednostki organizacyjne (dział ksi gowoci, dział kadr itp.)
• informacje biznesowe (
• funkcje biznesowe (obliczanie płac, zarzdzanie portfelem)
Typowe ograniczenia to:
• biznesowe, prawne (zarzdzenia ministra finansów, zasady prowadzenia ksi gowoci)
• otoczeniowe, zasobowe (ludzie do obsługi, przeszkolenie, administracja systemem)
• koszty (ile pieni dzy na projekt jest)
• techniczne (istniejca infrastruktura informatyczna)
• czasowe, zalenociowe (ma by na 22 lipca np., nie da si uruchomi bez zakupu
serwera)
• Wykona propozycj opisow rozwizania
W ramach tej czynnoci naley zaproponowa rozwizanie problemu, tak by pokaza e jest
to moliwe. W ramach propozycji naley wzi pod uwag aspekty niezb dne do
przygotowania efektów biznesowych (jakie korzyci przyniesie to rozwizanie)
Naley sprawdzi czy propozycja ma nast pujce cechy:
• projektowana poprawa w krytycznych rejonach i zwizane z ni zyski
• wymagania techniczne i mozliwoci wykonania projektu
• wpływ rozwizania na zmiany w organizacji
• wpływ na inne projekty
• Ostatnia czynno to dokonanie prezentacji rozwizania i uzyskanie jego akceptacj
Organizacja projektu
Przy rozpocz ciu projektu naley zdefiniowa jego organizacj . Organizacja rozumiana jest jako
zdefiniowanie ról osób biorcych udział w projekcie, ich hierarchii oraz procedur komunikacji i
raportowania pomi dzy nimi. Zwykle proponuje si organizacj projektu składajc si z ciała
kontrolnego i kierownika projektu. Ciało kontrolne ma za zadanie długofalowa kontrol projektu,
podejmowanie decyzji co do jego kierunku itp. Ciało kontrolne zbiera si zwykle na koniec kadego z
etapów projektu. Podczas zebrania kierownik projektu przedstawia raporty okrelajce post py
projektu, wykorzystanie budetu, osigni ta jako, napotkane problemy i dania zmian wraz z
podj tymi działaniami. Ciało kontrolne podejmuje decyzje o zmianach budetu i terminu projektu (lub
zmianie kierownika projektu), akceptacji nowej analizy ryzyka, zmianach w zakresie projektu a take
o jego zatrzymaniu.
Cel:
3
•
Wybra i przygotowa ludzi których zaangaowanie b dzie niezb dne dla osigni cia sukcesu
projektu w sposób który
• jasno identyfikuje role i odpowiedzialnoci
• zapewnia e do wypełniania tych ról i odpowiedzialnoci wybrano najlepszych ludzi
• identyfikuje szkolenia wymagane by ci ludzie mogli pełni te role
• zapewnia odpowiedni alokacj czasu zasobów do projektu
• zapewnia odpowiedni reprezentacj wszystkim grupom zainteresowanych tak e
projekt posiada grup ludzi którzy mog działa w sposób zintegrowany, którzy rozumiej role które
musz gra by projekt osignł sukces.
Organizacja projektu silnie zaley od typu projektu, zada jakie b d w nim wykonywane itp. Jednak
wszystkie metodyki proponuj struktur trójwarstwow składajc si z nast pujcych elementów:
• komitetu nadzorczego
• kierownika projektu
• zespołu lub zespołów wykonuj cych projekt
Komitet Steruj cy
Idea istnienia ciała, którego zadaniem jest kontrolowanie projektu jest stara jak wiat a przynajmniej
jak projekty. Komitet sterujcy powinien zosta utworzony w momencie inicjacji projektu. Najwi cej
pracy ma na pocztku. Musi po pierwsze wybra kierownika projektu. Musi uzgodni z kierownikiem
projektu sposób realizacji projektu (podział na etapy, załoenia projektu, zakres, plan i budet,
organizacja itp.). W trakcie trwania projektu jego obcienie spada - zadaniem jest decydowanie o
kierunkach rozwoju projektu, przydzielaniu dodatkowych zasobów, rozwizywanie problemów,
zatwierdzanie produktów itp. Ogólne zalecenia na tworzenie komitetu sterujcego s nast pujce:
• nie za wiele osób
• musi by główny uytkownik projektu
• dyrektor departamentu informatyki
• sponsor projektu
• kierownik projektu
• reprezentanci uytkownika oraz konsultanci techniczni.
Co daje istnienie komitetu sterujcego? Jeeli posiada odpowiedni władz i ch ci moe zabezpieczy
projekt przed:
• przekroczeniami budetu i czasu (pami tamy pierwszy objaw padania projektu - brak
komunikacji. Tu to wida szczególnie – kierownik projektu moe nie chcie podawa
dokładnych informacji o stanie projektu do komitetu sterujcego, a ono moe albo nie móc
albo nie chcie otrzymywa tych informacji.
• nie osigni cie celów projektu. Po kadym przegldzie, komitet sterujcy ma moc zmieni
kierunek projekt tak, by osign cele
• brak lub nadmierna reakcja na zmiany w wymaganiach, otoczeniu lub zasobach.
Inne osoby, które naley uwzgldni w organizacji projektu
Koordynatorzy projektu
Naley zbada, czy nie przydaliby si koordynatorzy aktywnoci projektu. Jeeli tak, to naley to
okreli w organizacji projektu, wybra osoby które b d pełniły te role i zdefiniowa zakres ich
odpowiedzialnoci i praw. Naley take oszacowa obcienie czasowe tych osób i sprawdzi, czy
wybrani maj a tyle wolnego czasu. Typowi koordynatorzy, którzy s potrzebni to:
• koordynator planowania (np. w przypadku wykonywania wielu projektów)
• koordynator uytkownika (kontrolujcy wykorzystanie uytkowników)
• koordynator techniczny
4
Zasoby
Naley zidentyfikowa jakie zasoby ludzkie i nieludzkie b d potrzebne. Przykłady to tablica, pokój,
sala konferencyjna, ołówki, herbata, konsultant techniczny, biznesowy itp.
Przygotowanie procedur sterowania i kontroli projektu
Procedury sterowania i kontroli projektu mona podzieli na:
• procedury zapewnienia i kontroli jakoci,
• procedury kontroli post pów i wykorzystania budetu,
• procedury kontroli zmian,
• procedury komunikacji w projekcie,
• procedury rozwizywania problemów.
Na etapie rozpocz cia projektu niezb dne jest zdefiniowanie i uzgodnienie z klientem tych procedur.
Procedury komunikacji
Procedury komunikacji mo na podzieli na procedury komunikacji wewntrz zespołu projektowego
oraz na procedury komunikacji zespołu projektowego z uytkownikiem i projektodawc. O ile te
pierwsze s łatwe do zdefiniowania a ich brak zwykle nie przeszkadza w prowadzeniu projektu, o tyle
nie zdefiniowanie i nie uzgodnienie tych drugich moe spowodowa upadek projektu. Aby
zabezpieczy si przed problemami z komunikacj naley zdefiniowa nast pujce jej parametry:
• jakie informacje maj by udost pniane uytkownikowi, projektodawcy i wykonawcy,
• kto jest odpowiedzialny za udost pnienie tych informacji,
• jakie s maksymalne czasy oczekiwania na informacje,
• jakie jest post powanie w przypadku przekroczenia tych czasów.
Zwykle najwi kszy nacisk kładziony jest na udost pnianie informacji i podejmowanie decyzji przez
uytkownika.
Procedury zapewnienia i kontroli jako ci
Problem jakoci w przypadku projektów informatycznych jest szczególnie wany. Zwykle jest on
dzielony na zapewnienie jakoci i kontrol jakoci.
Zapewnienie jakoci s to wszystkie prace majce na celu ułatwienie utrzymania jakoci produktów.
Do działa maj cych na celu zapewnienie jakoci mona zaliczy:
•
•
•
•
•
przygotowanie odpowiedniego rodowiska pracy,
zapewnienie dobrego systemu informacyjnego o projekcie,
zapewnienie odpowiedniego wykształcenia pracowników,
zdefiniowanie i rozpowszechnienie standardów wszystkich produktów podlegajcych kontroli
jakoci,
...
Odpowiednio zdefiniowane i zastosowane procedury zapewnienia jakoci mog w znaczcy sposób
zredukowa koszty projektu.
Kontrola jakoci jest procesem sprawdzania, czy jako wytworzonych produktów jest odpowiednia.
Na etapie rozpocz cia projektu naley zdefiniowa:
•
•
•
które z produktów podlegaj kontroli jakoci,
jakie formy kontroli jakoci s stosowane,
jaka jest procedura poprawiania wykrytych bł dów.
Procedury kontroli postpów i wykorzystania budetu
Na etapie rozpocz cia projektu nale y zdefiniowa jak i kiedy prowadzona b dzie kontrola post pów projektu.
Oczywicie kontrola post pów na bieco prowadzona jest przez kierownika projektu. W skład
kontroli post pów projektu b dzie wchodziło oszacowanie aktualnego stanu prac nad projektem,
5
obliczenie wska ników rónych takich jak Budgeted Cost Of Work Scheduled, Actual Cost of Work
Performed, Budgeted Cost of Work Performed, „wariancja” kosztów = BCWP - ACWP, „wariancja”
planu = BCWP - BCWS, Cost Performance Index = ACWP/BCWP - powinien by w okolicach
jedynki. Jak powyej to le.
Procedury kontroli zmian
Zmiany podczas prowadzenia projektu s zwykle duym problemem dla zarzdzaj cego. Zmiany
najcz ciej bior si z:
•
•
•
•
złego okrelenia wymaga uytkownika,
„uczenia” si uytkownika podczas prowadzenia projektu,
pojawienia si nowych technologii,
...
Nie da si uniemoliwi wprowadzania zmian do projektu. Dlatego naley zdefiniowa procedury
kontroli zmian.
Procedury rozwi zywania problemów
Przez problem rozumie si zdarzenie zewn trzne, które ma wpływ na projekt. Typowe problemy to:
• problemy komunikacyjne z projektodawc,
• problemy z podejmowaniem decyzji przez projektodawc ,
• problemy natury ludzkiej
Na etapie rozpocz cia projektu naley zdefiniowa ogólna metod rozwizywania projektów. Zwykle
proponuje si nast puj cy algorytm:
• identyfikacja problemu,
• okrelenie jego wpływu na projekt,
• wypracowanie metod likwidacji skutków.
Przy projektowaniu procedur rozwizywania problemów naley jasno powiedzie, kto i kiedy płaci za
dodatkow prace zwizan z okreleniem wpływu problemu na projekt oraz kto ponosi koszty wyst pienia
problemu.
Analiza i zarzdzanie ryzykiem
Proces zarzdzania ryzykiem w projektach informatycznych składa si z cyklicznych analiz ryzyka po
których nast puj okresy zarzdzania ryzykiem. Typowo analiz ryzyka wykonuje si przed
rozpocz ciu projektu w celu sprawdzenia, czy warto si za niego bra, a jeeli tak to jaki margines
bezpiecze stwa naley uwzgl dni tworzc estymaty czasu i kosztów. Analiza ryzyka jest zwizana z
identyfikacj zagroe projektu i oszacowaniem zakłóce jakie mog wprowadzi. Zarzdzanie
ryzykiem jest procesem zapobiegania wystpieniu ryzyka a take sprawdzania, czy które z
zidentyfikowanych ryzyk wystpiło i jeeli tak to minimalizowania jego skutków.
Analiza ryzyka
Analiza ryzyka składa si z trzech czynnoci:
• identyfikacja ryzyka
• estymacja ryzyka
identyfikacja ryzyka
Identyfikacja ryzyka ma na celu znalezienie wszystkich mo liwych problemów które mog wystpi
w trakcie trwania projektu/etapu i ich skategoryzowania. Inaczej mówic jest to odpowied na pytanie
„Co moe nie wyj w projekcie?”.
Identyfikacji ryzyka dokonuje si zwykle stosujc nast puj ce kroki:
6
Pierwszym krokiem w celu dokonania identyfikacji ryzyka jest:
• zbieranie informacji w celu zidentyfikowania ryzyka
Mona wykorzysta takie to ródła informacji:
• tradycja
• analogie do znanych przypadków
• eksperymenty lub testy
• dane epidemiologiczne
Róne problemy, które mona wzi pod uwag identyfikuj c ryzyka projektu.
• zbyt ambitny harmonogram
• zbyt ambitnie oszacowana wydajno zespołu
• zbyt optymistyczny budet
• nierealistyczne wymagania klienta
• niezdefiniowane / niezrozumiałe zobowizania kontraktowe
• nieznana, nie wypróbowana, nowa technologia
• nie doszacowanie złoonoci problemu
• nieodpowiedni lub brak metody prowadzenia projektów
• nieznany, nie wypróbowany, nowy sprz t
• niespójne, nie do definiowane, przedefiniowane wymagania uytkownika
le wykwalifikowany, niedowiadczony zespół
•
• cigłe zmiany wymaga
•
le wykwalifikowany, niedowiadczony management
• nieodpowiedni plan projektu
• zła struktura organizacyjna
• zbyt due wymagania na niezawodno
• brak zaangaowania uytkownika w projekt
• brak lub nieodpowiednia analiza i zarzdzanie ryzykiem
estymacja ryzyka
Estymacja ryzyka ma na celu zmierzenie prawdopodobie stwa wystpienia ryzyka oraz jego
konsekwencji. Problemy jakie naley rozwiza podczas tego etapu to:
• wybór odpowiedniej skali w której definiujemy prawdopodobie stwo zajcia zdarzenia oraz jego
skutki.
Tu mamy due pole do popisu. Mona wybra sobie skal :
• nominaln. Za jej pomoc mo na okreli, czy dwa zdarzenia s takie same czy nie. Nie ma relacji
porzdkujcej
• z uporzdkowaniem. To co poprzednio plus relacja porzdkuj ca
• kardynalna. Tu mo na nie tylko powiedzie e jedno wi ksze od drugiego, ale take ile razy
wi ksze
Wybór skali zaley od typu informacji jakie mamy w wyniku identyfikacji ryzyka. Np. w przypadku
ryzyka zwizanego z polityk skala moe si składa z 3 elementów - polityczne samobójstwo,
politycznie neutralne i politycznie poprawne. Natomiast ryzyko zwizane z planem czy te kosztami
wymaga mo e skali, która mówi jakie opó nienie ze sob ono niesie.
Skala z cyferkami jest niebezpieczna - wciska umysł w pułapk . Ale z drugiej strony jeeli si
dokładnie opisze, co dana liczba oznacza, to moe by nie najgorzej. Mona te zastosowa metod
ekspertów.
7
Zarz dzanie ryzykiem
Zarzdzanie ryzykiem ma na celu doprowadzenie projektu do jego celów. Polega ono na badaniu, czy
mo na unikn danego czynnika ryzyka, planowaniu i realizacji planu jak to zrobi na monitorowaniu
czy ryzyko wystpiło a jeeli tak to na planowaniu i realizacji planu minimalizacji skutków ryzyka.
Czyli zarzdzanie ryzykiem składa si take z trzech elementów:
• analiza ryzyka
• planowanie przeciwdziała
• monitorowanie ryzyka
Plan zarz dzania ryzyka
Planowanie polega na znalezieniu takiej strategii zarzdzania ryzykiem, która jest dopuszczalna i
poprawna, a take na proponowaniu taktyki i zasobów które naley wykorzysta eby osign cel. W
trakcie planowania ryzyka powstaje najwaniejszy dokument: Risk Management Plan zawierajcy
opis metod zarzdzania ryzykiem w projekcie. W skład tego dokumentu musi wchodzi:
• identyfikacja wszystkich czynników ryzyka projektu
• identyfikacja wanoci kadego z czynników ryzyka opisujca jak si ma dany czynnik w
stosunku do celów projektu
• oszacowanie prawdopodobie stwa zaj cia kadego z moliwych czynników ryzyka oraz jego
wpływu na projekt
• identyfikacja alternatyw zapobiegajcych wystpieniu ryzyka wraz z ich kosztami
• proponowana strategia zapobiegania ryzyku zawieraj ca dla kadego z czynników ryzyka plan
implementacji
• strategia integracji poszczególnych planów implementacji
• przypisanie zasobów do planu zapobiegania ryzyku wraz z opisem kosztów
• kryteria sukcesu zapobieenia kademu z czynników ryzyka
• punkty w których wykonywana b dzie ponowna analiza ryzyka
Dokument taki wchodzi w ramy project plan’u i pokazuje wysok jako P.M.
Podstawowe strategie zapobiegania ryzyku to:
• redukcja ryzyka polegajca na przygotowaniu działa zmniejszaj cych pdbo wystpienia oraz
wpływ na projekt. Typowa metody to dla ryzyka przekroczenie czasu takie zaplanowanie projektu
eby mie nadmiar czasu, w przypadku czynnika ryzyka uszkodzenie komputera jest kupienie
dobrej maszyny z UPS-em.
• zabezpieczenie przed ryzykiem które polega na takich działaniach, które powoduj e nawet
wystpienie czynnika ryzyka i zwizanych z nim strat nie spowoduje zawalenia si projektu.jest
znana z NASA i medycyny - redundancja. Tu czynnik ryzyka uszkodzenie komputera
minimalizuje si przez posiadanie zapasowego.
• przeniesienie ryzyka zwane czasami ubezpieczeniem od ryzyka. Ide jest podzielenie si
odpowiedzialnoci za ryzyko z kim innym. Mona spróbowa ubezpieczy si na wypadek strat.
• opłacenie ryzyka. Dla wybranego zestawu czynników ryzyka trzymane s w zapasie dodatkowe
zasoby, których zadaniem jest oczekiwanie na jego wystpienie i wkroczenie do akcji w celu
minimalizacji skutków.
8