ZARZĄDZANIE PROCESEM

TWORZENIA ZSI (2)

e-mail:

[e-mail]

Konsultacje

Ś wtorek i roda w dziekanacie w godzinach przyj ć

dr inż. Jacek Florek

Instytut Informatyki

Katedra Modelowania i Projektowania Systemów Informatycznych

Zagadnienia



plan projektu



organizacja projektu



struktura prac w projekcie



realizacja zarz dzania w podstawowych obszarach przedsi wzi cia

Jednym z istotniejszych czynników krytycznych sukcesu jest

wła ciwe

planowanie prac projektowych. Pozwala ono na

okre lenie prac

koniecznych do wykonania

Prace planistyczne w systemie informatycznym

można upodobnić do

do

podej cia przy budowie domu wyróżniaj c w kaskadowym cyklu

życia siedem podstawowych faz:

1. Faza definicji -

okre lany jest problem w dokumentacji wymaga

(budynek powinien

mieć ogrzewanie, kanalizacj , o wietlenie,

okre lon powierzchni mieszkaln , ...)

2. Faza analizy - wykonywana jest specyfikacja funkcjonalna

(lokalizacja budynku, sposób ogrzewania, wymagania

dotycz ce

klimatyzacji,

poł cze telefonicznych, ...)

3. Faza projektowania -

formułuje si propozycj rozwi zania

problemu (system dzieli

si na komponenty i okre la zasady ich

współdziałania; tworzy si projekty pomieszcze , wentylacji, kabli,

rur,...)

4. Faza programowania - odpowiada fazie budowy domu

5. Faza testowania - polega na sprawdzeniu

działania elektryczno ci,

kanalizacji, przewodów kominowych, ...

6. Faza akceptacji - klient sprawdza czy dom

został zbudowany

zgodnie z

założeniami, odbiera go i realizuje płatno ci

7. Faza operacyjna - klient przeprowadza

si do nowego domu

Plan projektu

Proces planowania

można przedstawić graficznie

CELE I OGRANICZENIA

Rezultaty, czas, koszty,

zasoby

DEFINIOWANIE

ZADA

SZEREGOWANIE

ZADA

OCENA CZASU

REALIZACJI ZADA

OCENA ZASOBÓW

(ludzie, koszty, sprz t, materiały)

OPRACOWANIE

HARMONOGRAMU

SCALANIE PLANU

Co?

W jakiej kolejno ci?

Jak długo?

Kto i czym?

Za ile?

Co i kiedy?

Plan projektu

Plan powinien

być zrozumiały (nie tylko dla twórców) przede wszystkim

dla wykonawców

Plany

mog być rozwijane i modyfikowane oraz uzupełniane przez

zespoły planistyczne w zależno ci od skali problemu/
Planowanie jest procesem wielokrotnie powtarzanym w kolejnych
fazach prac projektu. Jest

materiałem na którym pracuje zespół

realizuj cy projekt - może być przekazywany jak zadania realizacyjne w

ła cuchu prac.
Plan jest dokumentem

opisuj cym sposób osi gania założonego celu

projektowego - droga

doj cia od stanu obecnego do stanu docelowego

Plan projektu

Planowanie

jest

realizowane

w

różnych fazach z różn

szczegółowo ci . Jest zbiorem wielu elementów.
Plan podstawowy (bazowy,

główny) jest elementem kontraktu i stanowi

dokument, który opisuje ustalenia

dotycz ce sposobu wykonania

wszystkich prac projektowych. Zawiera

wi c:

Streszczenie - krótkie streszczenie opisu

założe i celów projektu,

ogólnego zakresu,

okre lenie uczestników tworzenia projektu, struktury

zarz dzania projektem, wyspecyfikowanie punktów w złowych
Opis celu projektu wraz z

okre leniem korzy ci i zmian w technologii i

sprz cie po wdrożeniu
Główne założenia rozwi zania - opisuj rozwi zania techniczne

prowadzenia prac projektowych,

technologi i sposoby wykonania prac

(wraz z uzasadnieniem wyboru),

podział zada mi dzy wykonawcami.

Elementy planu projektu

Założenia kontraktu - zawieraj wszystkie wymagania zgłoszone przez

użytkownika, informacje o zasobach dostarczanych, zasady

komunikacji,

skład komitetu doradczego, przegl dy projektu i

procedury

kontrolne,

uwarunkowania

zawierania

umów

z

podwykonawcami, terminy i specyfikacje dostaw, opis procedur

ulegaj cych zmianie w wyniku realizacji projektu
Lista

zada wykaz wszystkich istotnych zada do realizacji wraz z

wyróżnieniem punktów w złowych, przybliżony czas realizacji zada z

podziałem odpowiedzialno ci (również podwykonawców)
Wyszczególnienie zasobów - zawiera

podział budżetu na poszczególne

zadania, wykaz innych potrzebnych do realizacji projektu zasobów
(maszyny,

specjali ci, powierzchnia biurowa, materiały. Zasoby mog

także dotyczyć zada nie wyszczególnionych w li cie zada a

wymagaj ce użycia zasobów (logistyka, działania kontrolne, itp.)

Elementy planu projektu

Charakterystyka personelu - ludzie

s najważniejszym zasobem, st d

konieczne jest wyspecyfikowania potrzeb na

okre lone zespoły ludzkie

w

różnych fazach realizacji projektu

Metody oceny

zawieraj opis procedur kontrolnych, sposób kontroli

oraz planowane terminy, a

także zasady tworzenia historii projektu

Opis potencjalnych problemów -

wst pna analiza czynników

krytycznych sukcesu

umożliwia wskazanie potencjalnych zagroże i

problemów. W opisie

należy opisać uwarunkowania realizacyjne planu

(np. lista

założe przy których opracowano plan) - typowy przykład:

plan opracowano przy

okre lonym kursie dolara, je li kurs uległ

radykalnej zmianie w trakcie realizacji

należy pomy leć o korekcie

planu finansowego.

Elementy planu projektu

Specyfika

zarz dzania projektem oraz najcz ciej zespołowy charakter

prac projektowych zmusza do

okre lonej organizacji projektu.

Podstawow trudno ci , zwłaszcza w przedsi biorstwach o klasycznej,

hierarchicznej strukturze

zarz dzania, jest konieczno ć kompromisu

pomi dzy:



utworzeniem nowej, sprawnie i skutecznie

działaj cej struktury dla

projektu



a zachowaniem dotychczasowej organizacji,

niezb dnej do

prawidłowego funkcjonowania przedsi biorstwa w ramach jego

działalno ci podstawowej.

Należy dodać, że nowo tworzona struktura ma charakter tymczasowy i

po

zako czeniu projektu ulegnie ona rozwi zaniu, natomiast relacje i

zależno ci, które powstały mi dzy pracownikami zaangażowanymi w

projekt, jeszcze przez

długi okres czasu b d funkcjonować, pozostaj c

w

sprzeczno ci z now sytuacj .

Planuj c tworzenie struktury organizacyjnej projektu trzeba mieć wi c

na uwadze

również sytuacj , jaka b dzie po jego zako czeniu.

Z uwagi na kluczowy charakter zagadnienia utworzenie

wła ciwej

struktury dla projektu jest zadaniem dla

Zarz du przedsi biorstwa.

Organizacja projektu

Struktura organizacyjna utworzona dla realizacji celu projektu

może mieć

różny skład i charakter.

Sponsor

Reprezentant

klienta

Doradca

techniczny

Kierownik

projektu

Biuro

projektu

Zwi zki

zewn trzne

Zespół kontroli

jako ci

Kierownik

projektu I

Kierownik

projektu II

Kierownik

projektu N

.....

Zespół ń

Zespół 2

......

Zespół N

....

Komitet steruj cy

Na

przykład:

Organizacja projektu

Inna wersja struktury organizacji projektu.

KOMITET STERUJ CY



komitet

steruj cy

KOMITET WYKONAWCZY



komitet wykonawczy

grupy

pomocnicze

PODZESPOŁY WYKONAWCZE

ZESPÓŁ A

ZESPÓŁ B

ZESPÓŁ C

grupy

funkcjonalne

grupy

pomocnicze

grupy

funkcjonalne

grupy

pomocnicze

grupy

funkcjonalne



podzespoły wykonawcze

Organizacja projektu

Komitet

steruj cy to gremium strategicznego zarz dzania całym

przedsi wzi ciem, powoływane po podpisaniu kontraktu, a w jego

skład wchodz :



sponsor

przedsi wzi cia (wła ciciel biznesowy systemu) -

najcz ciej

członek

kierownictwa

(zarz du,

dyrekcji)

informatyzowanego

przedsi biorstwa

-

koordynator,

upoważniony do podejmowania decyzji dotycz cych zmian

organizacyjnych, kontroli

terminowo ci i zgodno ci z budżetem,



główny kierownik projektu ze strony wykonawcy (integratora) -

projektant

(analityk)

znaj cy

system

i

specyfik

informatyzowanego

przedsi biorstwa,



kierownik

projektu

ze

strony

informatyzowanego

przedsi biorstwa - zwykle jeden z kluczowych użytkowników

lub

główny informatyk odpowiedzialny za koordynacj grup

pracowników

oddelegowanych

do

prac

projektowo-

wdrożeniowych,



do wiadczeni konsultanci zewn trzni - w pełni niezależni

wzgl dem realizatora (integratora) systemu,



przedstawiciele

użytkowników kluczowych

Organizacja projektu

Komitet wykonawczy to gremium taktycznego

zarz dzania całym

przedsi wzi ciem, w jego skład wchodz :



główny kierownik przedsi wzi cia ze strony wykonawcy

(integratora) ZSI,



kierownik

przedsi wzi cia ze strony informatyzowanego

przedsi biorstwa,



kierownicy dziedzinowi -

do wiadczeni wdrożeniowcy w

zakresie poszczególnych

modułów funkcjonalnych,



użytkownicy kluczowi (np. gł. ksi gowy, gł. analityk, specjalista

ds. organizacji i

zarz dzania, specjalista informatyk, ...

Podzespoły wykonawcze to gremia (4-6 osobowe) przypisane do

modułów funkcjonalnych SI, w jego skład wchodz :



analitycy,



projektanci,



konsultanci,



szkoleniowcy,



przyszli

użytkownicy modułów

Organizacja projektu

Struktura prac w projekcie jest odzwierciedlana w postaci planu

projektu. Plan to opis drogi

doj cia od stanu obecnego do stanu

docelowego.

Opis stanu docelowego to pierwszy etap prac w projekcie:



jakie produkty

zostan dostarczone w ramach projektu,



opis nowego oprogramowania,



opis

sprz tu,



sposób

poł czenia nowego systemu z innymi systemami,



opis dokumentacji,



sposób modyfikacji dotychczasowych procedur

Inwentaryzacja stanu obecnego (w aspekcie ustanawianego projektu) to

drugi etap:



inwentaryzacja zasobów ludzkich,

sprz towych, finansowych, itp.

do realizacji projektu



inwentaryzacja koniecznych prac do wykonania,



sprawdzenie

zgodno ci rozwi za technicznych, kryteriów

współpracy i kryteriów akceptacji produktu ko cowego

Okre lenie drogi przej cia od stanu obecnego do punktu docelowego

to trzeci etap - opis sekwencji kolejnych

działa przekształcaj cych

aktualna

sytuacj w stan docelowy

Punkt

wyj cia

Punkt

docelowy

Struktura prac w projekcie

Okre lenie drogi przej cia to zespół działa tworz cych pewn struktur ,

która musi

znaleźć odzwierciedlenia w planie projektu.

Struktura

zada to najcz ciej lista dekomponowana na podzadania w

zależno ci od potrzeb tworz ca układ hierarchiczny.

Popularn metod dekompozycji jest WBS - Work Breakdown Structure.

Tworzy

si drzewo ilustruj ce zwi zki pomi dzy składowymi projektu.

Sposób tworzenia takiego drzewa

może być bardzo różny zależny od

koncepcji realizacji prac preferowany przez kierownika (to samo inaczej).

Przykład pierwszego poziomu hierarchicznej struktury:

1. Projekt dzielimy na:



podprojekt 1 -

realizuj cy jedn z funkcji



podprojekt 2 -

realizuj cy inn funkcj



podprojekt 3 -

realizuj cy kolejn funkcj



dokumentacja

całego systemu



testowanie i integracja

2. Projekt dzielimy na:



oprogramowanie



sprz t

3. Projekt dzielimy na:



prace realizowane przez

zespół A w jednej lokalizacji



prace realizowane przez zespół B w innej lokalizacji



integracja



integracja



wdrożenie

prace realizowane jak

w

podziałach wyżej

przedstawionych

Struktura prac w projekcie

PROJEKT

DOKUMENTACJA

PODPROJEKT 1

PODPROJEKT 2

INTEGRACJA I TESTY

SPRZ T

DOKUMENTACJA

SIEĆ

TERMINALE

SYSTEM A
SYSTEM B

Poł czenie z serwerem

Sieć lokalna

POZIOM 0

POZIOM 1

POZIOM 2

POZIOM 3

POZIOM 4

lub ten sam projekt ......

Struktura prac w projekcie

PROJEKT

DOKUMENTACJA

SPRZ T

INTEGRACJA I TESTY

PODPROJEKT 1

PODPROJEKT 2

SIEĆ

TERMINALE

Poł czenie z serwerem

Sieć lokalna

POZIOM 0

POZIOM 1

POZIOM 2

POZIOM 3

POZIOM 4

Struktura prac w projekcie

Forma struktury prac

też może być różna (graficzna - patrz poprzednia)

lub lista

Realizacja oprogramowania bankomatu

Opracowanie specyfikacji funkcjonalnej

Obsługa klienta

Identyfikacja klienta
Wyznaczanie limitu wypłaty
Wypłata
Rejestracja operacji

Sytuacja awaryjna

Nieprawidłowa identyfikacja klienta
Przekroczony limit wypłaty
Próba włamania
Brak zasilania

Oprogramowanie

Projekt oprogramowania
Realizacja oprogramowania
Testowanie oprogramowania
Dokumentacja oprogramowania

Przygotowanie kart magnetycznych
Zakup i montaż bankomatu
Akcja marketingowa

Projekt

Struktura prac w projekcie

lub lista numerowana

1000 Realizacja oprogramowania bankomatu

1100 Opracowanie specyfikacji funkcjonalnej

ńńńŃ Obsługa klienta

1111 Identyfikacja klienta
ńńń2 Wyznaczanie limitu wypłaty
ńńń3 Wypłata
1114 Rejestracja operacji

1120 Sytuacja awaryjna

ńń2ń Nieprawidłowa identyfikacja klienta
ńń22 Przekroczony limit wypłaty
ńń23 Próba włamania
1124 Brak zasilania

1200 Oprogramowanie

1210 Projekt oprogramowania
1220 Realizacja oprogramowania
1230 Testowanie oprogramowania
1240 Dokumentacja oprogramowania

2000 Przygotowanie kart magnetycznych
3ŃŃŃ Zakup i montaż bankomatu
4000 Akcja marketingowa

Struktura prac w projekcie

Niezależnie od przyj tej koncepcji istniej pewne ogólne zasady

wydzielania i opisu prac:



rezultatem

każdej czynno ci umieszczonej w strukturze musi być

konkretny produkt

ko cowy



nie

umieszczać w strukturze czynno ci polegaj cej na cz ciowej

realizacji

jakiego zadania



każda czynno ć musi być możliwa do zidentyfikowania z punktu

widzenia konkretnej osoby lub

zespołu odpowiedzialnego za

realizacj



czynno ci musz mieć okre lony czas realizacji i budżet



czynno ci powinny być łatwe do oceny i weryfikacji

oraz



zadania z

wyższych poziomów s dekomponowane na kolejne

grupy

czynno ci i każdy z tych podziałów może być budowany

według oddzielnych zasad (koncepcji)



struktura prac nie powinna

być zbyt szczegółowa (zbyt ogólna też) -

najcz ciej przyjmuje si cztery poziomy

Struktura prac w projekcie

Hierarchiczna struktura prac

może być różnie wykorzystywana w

dalszych pracach projektowych.
W

szczególno ci może pomóc w nast puj cych czynno ciach:



Okre lanie zakresu projektu



Szacowanie kosztów



Wyznaczanie

kolejno ci realizacji



Definiowanie rezultatów prac



Koordynacji prac



ledzenia i kontrolowania procesu wytwarzania



Definiowania zakresów

odpowiedzialno ci



Identyfikacji ryzyka



Tworzenia standardowych modeli dla podobnych projektów

Struktura prac w projekcie

Zadaniem struktury prac jest stworzenie kompletnej listy

zada do

realizacji - nie

należy jej utożsamiać z kolejno ci realizacji prac czy

doszukiwać si zwi zków przyczynowo-skutkowych.
Hierarchiczna struktura prac stanowi punkt

wyj cia do dalszych prac

planistycznych.
Wła nie na potrzeby planowania dobrze jest wyróżnić z tej hierarchii

czynno ci istotne ze wzgl du na proces realizacji i na zrozumienie

projektu.
Te

wyróżnione czynno ci oznaczaj wykonanie pewnej fazy prac

projektowych i

okre lane s poj ciem punktów w złowych projektu.

Punkt

w złowy to kluczowe zdarzenie na li cie zada , wyszczególnione

z pewnych

ważnych powodów.

Struktura prac w projekcie

Przykładem punktu w złowego może być realizacja celu cz stkowego

projektu: jeden z podsystemów informatycznych oddanych do

samodzielnej eksploatacji; jeden z bloków mieszkalnych dla projektów

budowlanych

dużego osiedla;

Realizacja zarządzania w podstawowych obszarach

przedsięwzięcia

Przypomnijmy,

że standard PMI wyróżnia 9 obszarów (dziedzin) zarz dzania

projektem.
W tym miejscu

wskażemy na najistotniejsze problemy obejmuj ce tylko

niektóre obszary

…..

A mianowicie

zarz dzanie:



zakresem



czasem



budżetem



komunikacj



ryzykiem



jako ci



zmianami

Realizacja zarządzania w podstawowych obszarach

przedsięwzięcia

Poj cie zakresu może odnosić si zarówno do projektu, jak i produktu.

Zakres produktu to funkcje i
udogodnienia, które

maj być

zawarte w produkcie

Zakres projektu obejmuje

prac , która

musi

zostać wykonana w celu

dostarczenia produktu

posiadaj cego

okre lone funkcje i udogodnienia.

Zarz dzanie zakresem projektu obejmuje procesy służ ce zapewnieniu, iż

wszystkie prace (i tylko te prace)

obejmuj ce projekt, zostan wykonane

gwarantuj c jego uko czenie z sukcesem.

W procesie

zarz dzania zakresem można wyróżnić kilka faz

(aspektów):

1. inicjacja
2. planowanie zakresu
3. definicja zakresu
4. weryfikacja zakresu
5. nadzór nad zmianami zakresu

Realizacja zarządzania w podstawowych obszarach

przedsięwzięcia

Zarz dzanie czasem obejmuje procesy wymagane dla zapewnienia

uko czenia projektu we wła ciwym czasie. Obszar ten obejmuje:

1.

identyfikacj działa , które musz zostać wykonane dla osi gni cia

celów projektu (definiowanie

działa )

2.

identyfikacj i udokumentowanie zależno ci mi dzy działaniami

(okre lanie nast pstwa)

3.

estymowanie czasu potrzebnego dla wykonania poszczególnych

działa (szacowanie czasu trwania)

4.

analizowanie

kolejno ci działa , czasów trwania oraz wymaganych

zasobów pod

k tem stworzenia harmonogramu (tworzenie

terminarza)

5.

nadzorowanie zmian do harmonogramu (kontrola terminów)

Realizacja zarządzania w podstawowych obszarach

przedsięwzięcia

Budżet projektu jest jednym z najistotniejszych składników zasobu projektu

Budżet okre la si najcz ciej jako parametr projektu wskazuj cy na

szacunek kosztów koniecznych dla realizacji wszystkich

zada projektowych

Zarz dzanie budżetem składa si z procesów maj cych na celu zapewnienie,

że projekt zostanie zako czony w zaaprobowanym kosztowo wymiarze.

Zarz dzanie kosztem projektu może być rozszerzone na wykorzystanie

produktu projektu po

zako czeniu projektu – mówimy wtedy o koszcie cyklu

życia produktu.

W ramach

zarz dzania budżetem rozróżnić można nast puj ce kroki (etapy,

działania):

1. planowanie zasobów

2. szacowanie kosztów

3.

budżetowanie

4. realizacja

budżetu

Realizacja zarządzania w podstawowych obszarach

przedsięwzięcia

Zarz dzanie komunikacj obejmuje procesy służ ce zapewnieniu

terminowego i

wła ciwego:

• tworzenia informacji

• gromadzenia informacji

• rozpowszechniania informacji

• przechowywania informacji

• usuwania informacji

Czyli

zarz dzanie komunikacj zajmuje si obsług informacji koniecznej do

realizacji projektu.

Każdy zatrudniony w projekcie musi być przygotowany do wysyłania i

odbierania komunikatów w

j zyku projektu i musi rozumieć jak komunikacja,

w której

bior udział jako osoby wpływa cało ć projektu.

Etapy:

1. planowanie komunikacji,
2. dystrybucja informacji,
3. sprawozdania,
4.

administracyjne zamkni cie

Realizacja zarządzania w podstawowych obszarach

przedsięwzięcia

Ryzyko

najcz ciej definiowane jest jako niebezpiecze stwo poniesienia

straty,

możliwo ć wyst pienia wydarzenia szkodz cego lub nieosi gni cia

celu.

Można je także okre lić jako tak sytuacj , w której przyszłych warunków

gospodarowania nie

można przewidzieć z cał pewno ci , znany jest

natomiast

rozkład prawdopodobie stwa wyst pienia tych warunków.

Ryzyko jest naturalnym zjawiskiem gospodarczym i nie

można go

wyeliminować. Można je natomiast ograniczać (redukować) poprzez



rozpoznawanie,



kształtowanie,



badanie

możliwych stanów przyszło ci,



odpowiedni kontrol realizacji zada ,



dywersyfikacj działalno ci



racjonalizacj ryzyka (czyli podejmowanie decyzji z uwzgl dnieniem

wyników analiz poziomu ryzyka).

Zarz dzanie ryzykiem obejmuje procesyŚ

1. identyfikacji
2. analizowania
3. optymalizacji
4. kontroli.

Realizacja zarządzania w podstawowych obszarach

przedsięwzięcia

Zarz dzanie jako ci obejmuje procesy, które maj zapewnić, że projekt

zaspokoi potrzeby, dla których

został rozpocz ty.

Procesami, które

składaj si na zarz dzanie jako ci s :

1. planowanie

jako ci - obejmuje identyfikacj wła ciwych norm

zwi zanych z projektem oraz okre lenie jak spełnić zawarte w nich

wymagania.

2. zapewnienie

jako ci - zaplanowane i systematycznie wdrażane

działania w systemie jako ci służ ce zapewnieniu, że projekt spełni

odpowiednie normy

jako ciowe.

3. kontrola

jako ci - monitorowanie rezultatów projektu czy spełniaj

one odpowiednie normy.

Proces

zarz dzania zmianami rozpoczyna si w momencie zaistnienia

potrzeby wprowadzenia zmiany.

Czy

i

dlaczego

dana

zmiana

powinna

być

wprowadzenia?

Należy ocenić:



jaki

wpływ b dzie miała ta propozycja na projekt



czy jest zgodna z jego celami



jak zmieni ona podstawowe atrybuty: zakres, termin

i koszty.

Należy również przeprowadzić analiz ryzyka w zwi zku

z wprowadzanymi zmianami gdzie

szczególn uwag

należy po wi cić kosztom jej zaniechania.
Zgromadzić wszystkie dane, które s niezb dne do

podj cia decyzji.

W efekcie procesu decyzyjnego

może nast pić odrzucenie

zmiany,

odłożenie do powtórnego rozpatrzenia w terminie

późniejszym lub akceptacja.

Wieloaspektowa analiza

Proces decyzyjny

W przypadku akceptacji zmiany

należy uaktualnić

wszelkie

plany

i

harmonogramy,

ustalić

odpowiedzialno ć za wprowadzenie zmian do projektu

oraz

ustalić odpowiedzialno ć za sprawdzanie i

podpisanie zmian do projektu.

Niezależnie od rodzaju podj tej decyzji informacja o

niej

wraz

z

uzasadnieniem

powinna

być

rozpowszechniona

w ród wszystkich podmiotów

zaangażowanych w projekt.

Odrzucenie

Akceptacja

Odłożenie

Po formalnym wprowadzeniu zmiany do projektu dalsze

czynno ci wykonywane s już

w ramach standardowego procesu

zarz dzania projektem.

Mimo to

każda wprowadzona zmiana powoduje jednak pewn destabilizacj i

zaburzenie rytmu prac, dlatego

też należy starać si , aby wszelkie zmiany wprowadzać

do projektu

możliwie łagodnie, grupuj c w pakiety zmiany o podobnym charakterze.

Realizacja zarządzania w podstawowych obszarach

przedsięwzięcia

Dokonuj c uogólnienia różnych modeli realizacji projektów można

stwierdzić, iż typowy model powinien zawierać cztery podstawowe

fazy (etapy):

• identyfikacja projektu
• definicja projektu
• realizacja projektu
•

uko czenie projektu

Model realizacji projektów

Faza identyfikacji projektu - ma na celu precyzyjne

okre lenie założe i

celów projektu. Faza ta decyduje o powodzeniu

przedsi wzi cia.

Istotne

przedsi wzi cia:



ustalić cel projektu i przesłanki, które stały si podstaw projektu



ustalić autentyczne potrzeby i wymagania użytkownika, które pozwol

przedstawić użytkownikowi wariantowe rozwi zania i skonfrontować

wizj użytkownika z wizj realizatora



ustalenie

wst pnego zakresu projektu pozwoli na okre lenie kosztów i

korzy ci z realizacji - jest to podstawa dla ustanowienia projektu, st d

konieczno ć zaangażowania gremiów kierowniczych



przeanalizować główne zagrożenia i czynniki krytyczne sukcesu

(„zgrubnie” - niektóre zagrożenia mog stanowić czynnik

uniemożliwiaj cy realizacj )

Faz t powinno ko czyć opracowanie dokumentu zawieraj cego opis

przeprowadzonych analiz i

uwarunkowa oraz wszystkich rozważanych

wariantów

rozwi za . B dzie to wi c okre lenie



głównych parametrów projektu,



oczekiwa użytkownika



ramowych

założe organizacji procesu projektowania.

Podpisanie takiego dokumentu jest równoznaczne z

podj ciem decyzji o

realizacji projektu.

Model realizacji projektów - identyfikacja projektu

Faza ta jest

konsekwencj i kontynuacj fazy identyfikacji. Wi że si z

precyzyjnym zdefiniowaniem istotnych elementów projektu i parametrów

organizacyjnych:



ostateczny zakres prac projektu

okre la co należy wykonać w ramach

projektu i co zostanie

pomini te oraz przypisać granice

odpowiedzialno ci poszczególnych uczestników projektu



na podstawie zakresu ustalany jest

budżet i czas realizacji projektu

(niekiedy

podstaw jest czas realizacji do którego dopasowuje si

pozostałe czynniki - zakres i budżet; innym razem podstaw może być

zakres zmian -

„trójk t zarz dzania projektem”)



okre lić ramow struktur prac: wyznaczenie w złowych punktów i

czasów ich

osi gania oraz koszty - wst p do planowania

szczegółowego



ustalenie definicji podstawowych

poj ć dla jednoznacznego

rozumienia projektu



okre lenie obszarów potencjalnego ryzyka - wst pna identyfikacja i

oszacowanie



ustalenie systemu raportowania, zasad komunikacji w zespole,

post powania w sytuacjach awaryjnych



stworzenie biura projektu i

okre lenie potrzeb dokumentacyjnych

Model realizacji projektów - definicja projektu

Faz t powinno ko czyć opracowanie dokumentu (raportu)

zawieraj cego główne ustalenia stron (przydatne przy tworzeniu

kontraktu).

Realizacja projektu rozpoczyna

si od słowa „start” - krótkie a dużo pracy

Model realizacji projektów - realizacja projektu

Wykonanie wszystkich prac

inicjuj cych i organizacyjnych (inicjacja i

definicja) stwarza warunki

umożliwiaj ce formalne rozpocz cie projektu.

„Start” wymaga odpowiedniego przygotowania i zaplanowania wielu

czynno ci.



faz t rozpoczyna zatwierdzenie ostatecznej wersji definicji projektu



zbudowanie

zespołu projektowego



rozpocz cie procesu dokumentacyjnego przez biuro projektu (ksi żka

projektu - opis i historia projektu)



rozpocz cie prac planistycznych (plan ogólny - kierownik projektu,

plany

szczegółowe - kierownicy podprojektów)

Planowanie dostarcza odpowiedzi na kluczowe pytania:

• co

należy zrobić?

• w jakim czasie?

• w jakiej

kolejno ci?

• z wykorzystaniem jakich zasobów?

•

według jakiej technologii?

i obejmuje wszystkie obszary i aspekty projektu

Model realizacji projektów - realizacja projektu

Realizacj monitoruj kierownicy (porównanie realizacji z planem)

prowadz c jednocze nie dokumentacj : post p prac odnotowywany jest

w raportach i omawiany podczas

spotka zespołów.

Monitoring (raporty i wnioski ze

spotka ) jest podstaw procesu

prognozowania

dotycz cego projektu i ewentualnych zmian w planach.

W trakcie realizacji

mog wyst pić sytuacje wyj tkowe (zakłócenia w

realizacji planu spowodowane

bł dami, zł analiz ryzyka lub zmianami w

projekcie).
Sytuacje

wyj tkowe winny być dokumentowane (analiza przyczyn,

omówienie

działa naprawczych, podj te decyzje, ...)

REALIZACJA

MONITORING

Plan

odchylenia?

Raporty

Spotkania

DECYZJE

TAK

NIE

ANALIZA

DOKUMENTOWANIE

Model realizacji projektów - realizacja projektu

Termin

zako czenia projektu („Stop”) jest zapisany w kontrakcie.

Zako czenie oznacza pełn realizacj prac zgodnie z definicj projektu

(zakres) oraz odbiór przez

zlecaj cego.

W przypadku systemu informatycznego

naturaln tendencj jest d żenie

do

rozwini cia przedsi wzi cia (dopasowanie do nowej technologii,

piel gnacja, ...). Tego typu działania powinny znaleźć si w nowym

projekcie.
Odbiór efektów prac powinien

być realizowany na podstawie ustalonych

procedur, a fakt akceptacji

(osi gni cie celów projektu) formalnie

potwierdzony.
Uko czenie projektu to także rozwi zanie zespołów i zako czenie pracy

systemu

zarz dzania projektem, a tym samym stworzony obiekt musi

zintegrować si z otoczeniem bez zakłócenia jego działania i przynosić

korzy ci.

Model realizacji projektów -

ukończenie projektu

Rozumienie

zagadnie poruszonych na wykładzie prosz skonfrontować z pozycj

1.Barczak. A., Florek J., Sydoruk T.: Projektowanie zintegrowanych systemów
informatycznych

zarządzania, Wyd. AP, Siedlce 2006

2.Philips J.:

Zarządzanie projektami IT. Helion. 2005

3.

Flasi ski M.: Zarządzanie projektami informatycznymi. PWN. 2006

4.Project Management Body of Knowledge. Project Management Institute
2000.

http://www.pmi.org

5.Szyjewski Z.:

Zarządzanie projektami informatycznymi. Metodyka tworzenia

systemów informatycznych. Agencja Wydawnicza Placet. Warszawa 2001

DZI KUJ ZA

UWAG Ą