Modul_2.indd

1. Decyzja o rozpoczęciu projektu

Podjęcie decyzji o rozpoczęciu projektu jest niezmiernie ważne z uwagi na to, że wy-
maga przyjęcia określonych zobowiązań na przyszłość. Niezwykle istotnym elemen-
tem są zasoby każdej ze stron, które muszą być przypisane do projektu na czas jego
trwania. Zasobami tymi są ludzie, pieniądze, sprzęt, pomieszczenia. W zależności
od projektu — tego, jak jest on duży oraz jak rozłożony w czasie — zasoby te
będą różnej wielkości. Często już na etapie przystępowania do realizacji pro-
jektu przyjmuje się — jako pewien wyznacznik jego opłacalności — parametr
korzyści utraconych w przypadku niezrealizowania przedsięwzięcia. Wszyst-
kie tego typu wskaźniki mają charakteryzować planowane przedsięwzięcie,
określać jego zyskowność oraz realność. W momencie podejmowania decyzji
o rozpoczęciu projektu z reguły rozpoczyna się proces rozpoznawania, a na-
stępnie deﬁniowania potrzeb.

Rozpoznawanie potrzeb końcowego użytkownika musi być procesem wyko-
nywanym świadomie, ponieważ w zależności od tego, jak dobrze zostanie
wykonane, tak dobry będzie produkt końcowy. Poza tym należy pamiętać,
że rozpoznanie potrzeb użytkownika końcowego nie jest aktem jednorazo-
wym, ale procesem, który trwa do momentu zakończenia projektu. Dobrze,
jeśli w momencie uruchomienia projektu zostaną stworzone formalne proce-
dury, dzięki którym możliwe będzie systematyczne rozpoznawanie potrzeb
użytkowników. Wiele metodyk zarządzania projektem posiada wbudowane
procedury wprowadzania zmian i modyﬁkacji. Rozpoznawanie potrzeb jest
ściśle związane z prognozowaniem pewnych rozwiązań, jakie zostaną przyję-
te w rozwiązaniu docelowym.

Deﬁniowanie potrzeb to kolejny proces, podczas którego dochodzi do okre-
ślenia  konkretnych  wymagań  użytkownika  końcowego.  Po  przeprowadze-
niu całego szeregu rozmów z przyszłymi użytkownikami, wszelkie oczekiwa-
nia  zostaną  zamienione  na  konkretne  rozwiązania,  które  usprawnią  pracę.
Ważne  jest,  aby  proces  ten  został  zrealizowany  z odpowiednią  grupą  osób
— z faktycznymi przyszłymi użytkownikami — gdyż w przeciwnym przypad-
ku może okazać się, że wymagania będą niekompletne i produkt końcowy nie
będzie spełniał oczekiwań klienta. Deﬁniowanie potrzeb powinno odbywać
się według schematu zaprezentowanego na rysunku 1.

W momencie, kiedy zostaną zdeﬁniowane wymagania klienta, można przystąpić
do określenia wymagań funkcjonalnych i technicznych. Wymagania funkcjonalne
to nic innego, jak opis funkcji, jakie muszą być realizowane przez produkt końco-
wy. Na podstawie wymogów funkcjonalnych zostaną sformułowane wymagania
techniczne. Wymagania techniczne bardzo często są punktem wyjścia do pracy
zespołu projektowego, gdyż są uzupełnieniem wymagań funkcjonalnych, zgłoszo-
nych przez użytkownika i pozwalają na ich implementację w konkretnym, zamó-
wionym przez klienta środowisku.

Rysunek 1

Schemat deﬁniowania wymagań

użytkownika końcowego

2. Planowanie realizacji projektu

W fazie planowania projektu sporządzana jest mapa, która pokazuje sposób przej-
ścia od jednego etapu realizacji do następnego.

Do stworzenia planu projektu wykorzystuje się szereg narzędzi, takich jak:
1.

Struktury podziału pracy

— to podstawowe i najczęściej wykorzystywane narzę-

dzie wspomagające fazę planowania projektu. Zbudowana struktura, czyli lista
wszystkich jednostkowych zadań, jakie będą do wykonania w ramach projektu
jest punktem wyjścia do stworzenia harmonogramu pracy. Na ogół podczas two-
rzenia struktury podziału pracy stosowana jest metoda przechodzenia od ogółu
do szczegół. W pierwszej kolejności określane są główne grupy zadań do wyko-
nania, a następnie są one uszczegóławiane, aż do momentu określenia pojedyn-
czych czynności, które będą mogły zostać przypisane konkretnej osobie.

Wykresy Gantta

— pozwalają na szybkie określenie czasu rozpoczęcia i zakończe-

nia konkretnego zadania. Narzędzie to również bardzo często wykorzystywane
jest do kontrolowania stopnia realizacji projektu i jego poszczególnych elemen-
tów składowych.

Harmonogramy sieciowe PERT/CPM

— zostały stworzone w celu wyeliminowania

niedostatku informacji na temat konsekwencji zmian terminów realizacji po-
szczególnych zadań. Obie z tych metod (PERT — Program Evaluation and Re-
view Technique oraz CPM — Critical Path Metod) funkcjonują obecnie jako hy-
bryda PERT/CPM, która wykorzystuje najlepsze cechy każdej z nich. Opraco-
wywanie sieci PERT/CPM opiera się na wcześniej przygotowanej strukturze po-
działu pracy projektu. Zadania, jakie zostały przeznaczone do realizacji w ra-
mach projektu umieszcza się w prostokątach w takiej kolejności, w jakiej będą
one realizowane. Linie łączące poszczególne pola pokazują zależności między
poszczególnymi zadaniami. Na rysunku 2 przedstawiono przykład sieci PERT/
CPM dla zadania polegającego na przygotowaniu kompletu planów budynków
z naniesioną instalacją energetyczną i siecią logiczną.

Dla każdego z zadań, jakie są do wykonania, ustala się najwcześniejszy i najpóź-
niejszy moment rozpoczęcie projektu oraz rezerwę czasu. Obrazuje to poniższa
tabela.

Rysunek 2

Sieć PERT/CPM

— wykres działań węzłowych

Zadanie

Moment

najwcześniejszy

Moment

najpóźniejszy

Rezerwa

Wykonanie pomiarów

Instalacja oprogramowania

Wykonanie planów

Przekazanie gotowych planów pomieszczeń

Naniesienie instalacji energetycznej

Naniesienie instalacji logicznej

Zebranie planów w spójną całość

Na rysunku 2 pogrubioną linią zaznaczono ścieżkę krytyczną, czyli ścieżkę, któ-
rej wykonanie traw najdłużej. Dla zadań, które położone są na ścieżce krytycz-
nej nie ma rezerwy czasowej, a zatem jakiekolwiek opóźnienia w realizacji za-
dań na niej położonych odbĳą się na czasie trwania całego projektu. W taki spo-
sób można zaplanować realizację wszystkich grup zadań, jakie są do wykonania
w ramach projektu i na bieżąco kontrolować, czy nie pojawiają się zagrożenia,
które mogą generować opóźnienia.

Wykresy alokacji zasobów

— są to wszelkiego rodzaju zestawienia zasobów ma-

terialnych i ludzkich, jakie zostały przypisane do realizacji konkretnych zadań
w ramach projektu. Zestawienia te mogą być elementami składowymi na przy-
kład wykresów Gantta, gdzie do każdego zadania zostanie przypisany odpowie-
dzialny za nie członek zespołu, lub mogą zostać stworzone odrębne macierze za-
sobów. Na rysunku 3 przedstawiono przykład przypisania poszczególnych spe-
cjalistów do realizacji zadań w ramach projektu.

Zasoby

Kierownik

Specjaliści od

AutoCAD-a

Specjaliści od

zagadnień

sieciowych

Specjaliści od

okablowania

Elektrycy

Administra-

torzy

Audyt

Deﬁniowanie wymagań

Sporządzenie planów

Urządzenia aktywne

Urządzenia pasywne

Okablowanie

Serwery

UPS

P — funkcja podstawowa

S — funkcja pomocnicza

Jak widać na rysunku 3, do realizacji poszczególnych zadań zawsze przypisy-
wane są co najmniej dwie osoby — jedna pełniąca funkcję podstawową i dru-
ga pełniąca funkcję pomocniczą. Taki sposób przypisywania zadań ma na celu
uchronienie projektu przed opóźnieniami związanymi na przykład z chorobą
pracownika. Przy tworzeniu zestawień alokacji zasobów należy zwracać uwagę
na liczbę zadań, jakie zostały przypisane do konkretnej osoby. Jeśli ich liczba bę-
dzie zbyt duża, rzeczą naturalną okaże się niewykonanie któregoś z nich w za-
planowanym czasie.

Wykresy rozkładu kosztów skumulowanych

— metoda ta pozwala na zaplanowanie

oraz późniejszą kontrolę łącznych wydatków, jakie zostały poniesione w projek-
cie. Na rysunku 4 przedstawiona została krzywa kosztów skumulowanych, za-
planowanych i rzeczywiście wydatkowanych w ramach realizacji projektu. Na

Rysunek 3

Macierz zasobów przypisanych

do realizacji zadań

rysunku pokazane jest również odchylenie budżetu od przyjętego planu. Metoda
ta pozwala na zaplanowanie oraz późniejszą kontrolę łącznych wydatków, jakie
zostały poniesione w projekcie.

Wszystkie wymienione tu narzędzia mają pomóc kierownikowi zespołu realizacyj-
nego oraz jego członkom w odpowiednim zaplanowaniu zadań, zdeﬁniowaniu cza-
su niezbędnego do ich wykonania oraz zarezerwowaniu odpowiednich zasobów.

Jeśli znany jest zakres prac do wykonania, ramy czasowe, w jakich należy zrealizo-
wać projekt, istnieje zespół ludzi, którzy mają wykonać to zadanie i tworzą pewną
strukturę, nadchodzi czas, aby przystąpić do etapu planowania całego przedsię-
wzięcia.

Mówiąc o planowaniu, konieczne jest wyodrębnienie listy zadań (Z), jakie należy
wykonać, i przypisanie ich do osób, które będą odpowiedzialne za ich wykonanie
w ściśle określonym czasie. W trakcie dalszych prac planistycznych i samej realiza-
cji projektu zostanie dokładnie określony budżet.

Zadaniem zespołu będzie wygenerowanie faktycznych zadań, jakie są do wykona-
nia w projekcie, na podstawie zebranych w trakcie audytu danych i stworzonej listy
wymagań, zapisanej w umowie między zleceniodawcą a zespołem realizacyjnym.
Lista ta powinna być dużo bardziej szczegółowa i powinna odzwierciedlać czynno-
ści, jakie należy wykonać w trakcie realizacji projektu.

W chwili, gdy przygotowana zostanie szczegółowa lista zadań, kierownik projek-
tu musi dokonać ich przypisania poszczególnym członkom zespołu, starając się
w maksymalny sposób dopasować zadania do wiedzy i umiejętności poszczegól-
nych osób. W wyniku takiego dopasowania kierownik powinien otrzymać nastę-
pującą macierz:

Rysunek 4

Krzywe kosztów
skumulowanych

— planowana i rzeczywista

Zadanie

Z10

Z11

Z12

Z13

Osoba:

O10

Przygotowując taką macierz, należy pamiętać o równomiernym obciążeniu pra-
cą poszczególnych członków zespołu. Dodatkowo należy pamiętać o zagrożeniach
projektowych i zagwarantowaniu, że każde z zadań będzie realizowane przez co
najmniej dwie osoby, aby w przypadku na przykład choroby pracownika nie do-
szło do opóźnień w realizacji zadania lub całego projektu. Po przypisaniu zadań do
poszczególnych uczestników w naturalny sposób zostały wyodrębnione mniejsze
podzespoły, które będą odpowiedzialne za wykonanie pojedynczych zadań czy też
grup zadań. Konieczne jest, aby dla każdego zadania została wskazana osoba od-
powiedzialna za jego prawidłową i terminową realizację. W przykładzie macierzy
zaprezentowanej powyżej wyróżniamy następujące grupy (G):
G1 — Z1 — O1, O4, O8,
G2 — Z2 — O2, O6, O9,
G3 — Z3 — O3, O7, O10,
G4 — Z4 — O2, O5,
G5 — Z5 — O4, O8, O10,
G6 — Z6 — O3, O7,
G7 — Z7 — O1, O6, O9,
G8 — Z8 — O4, O8,
G9 — Z9 — O3, O7, O10,
G10 — Z10 — O2, O5, O9,
G11 — Z11 — O4, O8, O10,
G12 — Z12 — O3, O6, O9,
G13 — Z13 — O5, O8, O10.

Jeśli zadania zostały przypisane poszczególnym osobom w zespole projektowym,
można przystąpić do zaplanowania harmonogramu realizacji. W celu zbudowania
harmonogramu można tworzyć odpowiednie zestawienia tabelaryczne:

Grupa

Data rozpoczęcia

Data zakończenia

Uwagi

G1
G2
G3

G4
G5
G6
G7
G8
G9

G10
G11
G12
G12
G13

Harmonogram zadań można zaprezentować w formie wykresu Gantta:

ś (

)

eń (

)

12T

G1
G2
G3
G4
G5
G6
G7
G8
G9
G10
G11
G12
G13

Jeszcze innym sposobem prezentacji harmonogramu realizacji zadań są diagramy
sieciowe:

Rysunek 5

Diagram sieciowy

Wsparcie dla użytkownika stanowią również różnego rodzaju kalendarze (mie-
sięcznie, tygodniowe), które w obrazowy sposób pokazują, jakie zadania zostały
przypisane danej osobie do wykonania w ramach realizacji projektu. Narzędzie
to przydaje się również w sytuacji, kiedy planuje się przedsięwzięcie i ustala czas
niezbędny do jego zrealizowania. Należy unikać bardzo ogólnych określeń, takich
jak: Zadanie zostanie zrealizowane za tydzień. Należy pamiętać, że tydzień nie jest
równy tygodniowi — w danym przedziale dat mogą pojawić się dni wolne od pracy
(święta, urlopy), co w konsekwencji uniemożliwi wykonanie zadania w zadeklaro-
wanym tygodniu. Lepiej podawać termin realizacji zadań w osobodniach, co prze-
łoży się na określoną liczbę dni, która może być różna w różnych okresach trwania
projektu. Jest to bezpieczniejsze dla zespołu oraz bardziej uczciwe w stosunku do
zleceniodawcy.

Zadania mogą być zaplanowane na cały czas trwania projektu, ale mogą również
być tak rozłożone, że — po wykonaniu części zadań wstępnych — dana osoba przy-
stąpi do dalszej realizacji projektu dopiero w końcowej jego fazie. Takie informa-
cje dają z jednej strony uczestnikowi projektu możliwość przygotowania się do wy-
konania określonych zadań, z drugiej zaś dają kierownikowi projektu możliwość
udostępniania lub wykorzystywania danej osoby w innym projekcie, który jest re-
alizowany równolegle. Taka sytuacja bardzo często spotykana jest w przypadku
osób o bardzo wąskiej specjalizacji, które po zakończeniu pracy w jednym projek-
cie przechodzą do pracy w innym.

Realizacja każdego zadania może spotkać się z różnymi problemami, które począt-
kowo są rozwiązywane na szczeblu zespołu, ale mogą również traﬁć na najwyż-
szy szczebel organizacyjny w projekcie. Pojawiające się problemy muszą być reje-
strowane z dwóch powodów. Po pierwsze, aby zostały na pewno rozwiązane i nie
umknęły z pamięci uczestników, a po drugie, aby zbudować bazę wiedzy, w opar-
ciu o którą łatwiej będzie rozwiązywać problemy w przyszłości. Każdą specyﬁkację
opisującą problem warto przypisać do konkretnego zadania w projekcie i do osoby,
która jest odpowiedzialna za jego eliminację.

Jak wiadomo, w trakcie realizacji dowolnego projektu powstaje szereg dokumen-
tów, którymi również należy zarządzać. Dokumenty pojawiają się w nowych wer-
sjach, są uzupełniane i zmieniane, a zatem warto, aby wszyscy uczestnicy projektu
w czasie rzeczywistym mieli dostęp do ich aktualnych wersji. Dbałość o dokumen-
tację projektową już od pierwszego dnia projektu jest niezwykle istotnym elemen-
tem wpływającym na jego sukces. Należy przechowywać wszystkie wersje doku-
mentacji częściowej, gdyż może zaistnieć konieczność powrotu do rozwiązań, któ-
re były proponowane w początkowych planach, a potem z jakichś powodów z nich
zrezygnowano. Posiadanie starszych wersji dokumentów — obrazujących prze-
bieg prac — pokazuje, jak wyglądała ewolucja całego przedsięwzięcia. Dodatkowo
wszystkie dokumenty, które powstają w projekcie stanowią bazę wiedzy i propozy-
cji rozwiązań, jakie mogą zostać wykorzystane przez zespół podczas realizacji ko-
lejnych projektów.

Niezwykle ważnym elementem w realizacji każdego przedsięwzięcia jest komunika-
cja między jego uczestnikami. Dobrze jest, jeśli już na etapie planowania całego pro-
jektu zostaną przemyślane i zdeﬁniowane odpowiednie kanały przepływu informa-
cji i decyzji. Jest to ważne, ponieważ wprowadzenie zbyt wielu kanałów komunika-
cyjnych i ich rozpowszechnienie na wszystkich członków zespołu może wprowadzić
chaos informacyjny. Zbyt mała liczba kanałów informacyjnych też nie jest dobra,
gdyż doprowadzi do izolacji członków zespołu od innych zadań, które są realizo-
wane w projekcie. Zadaniem kierownika jest zatem znalezienie optymalnego roz-
wiązania. Przykładem takiego rozwiązania może być forum dyskusyjne, na którym
grupa może przedstawić i zaprezentować swoje stanowiska, wszystkie argumenty za
i przeciw oraz dokonać wyboru tego, który w danej chwili jest najlepsze.

3. Realizacja projektu

Realizacja to faza, podczas której następuje wykonanie wcześniej zaplanowanych
i przydzielonych zadań mających na celu stworzenie produktu spełniającego ocze-
kiwania i potrzeby użytkownika końcowego. W zależności od rodzaju projektu,
faza jego realizacji jest bardziej lub mniej skomplikowana. Absolutnie nie można
przyjmować założenia, że jest to jedno z rutynowych działań, jakie są do zrealizo-
wania w czasie trwania projektu. W trakcie realizacji projektu pojawiają się różne-
go rodzaju zagrożenia, które mogą powodować, że jego realizacja w zaplanowa-
nym czasie lub w ramach zaplanowanego budżetu stanie się niemożliwa. Należy
zatem podejmować różnego rodzaju działania zaradcze, eliminujące lub minimali-
zujące to ryzyko. W cały proces realizacji projektu powinny być wbudowane me-
chanizmy: kontroli oraz wprowadzania zmian i korekt do projektu. Jak wiadomo,
zmiany są o tyle istotne, że z jednej strony zwiększają stopień dopasowania pro-
duktu końcowego do oczekiwań klienta, z drugiej jednak burzą przyjęty harmo-
nogram realizacji prac, a to w konsekwencji może doprowadzić do upadku pro-
jektu. Zabezpieczeniem przed tego typu sytuacją — upadkiem projektu na skutek
wprowadzonych zmian — jest sformalizowany mechanizm ich wprowadzania do
projektu. W procesie tym powinien pojawić się element akceptacji przez zlecenio-
dawcę nowych elementów (zmian) projektowych oraz nowych harmonogramów
i budżetów.

4. Kontrola

Realizacja projektu związana jest z określonymi odchyleniami poszczególnych
działań od przyjętych założeń. Kontrola polega na ciągłym nadzorowaniu postę-
pów projektu. Kontrola realizacji projektu powinna dać odpowiedź na pytanie, czy
odchylenie, z którym ma się do czynienia jest na akceptowalnym poziomie. W pro-
cesie kontroli nie można przyjąć założenia, że nie będą występowały odchylenia.
Pytanie, jakie się rodzi dotyczy tego, czy są one do przyjęcia przez realizatorów
i zleceniodawcę.

W trakcie trwania całego projektu należy gromadzić i analizować dane dotyczą-
ce pojawiających się rozbieżności. Zdobyta wiedza pozwoli w porę reagować na
odchylenia, które przekraczają akceptowalny próg tolerancji. Aby proces kontroli
projektu przebiegał prawidłowo, należy zbudować mechanizm raportowania zda-
rzeń, które odbiegają od przyjętego progu akceptacji i nakazać jego stosowanie
wszystkim członkom zespołu. Budując mechanizm kontroli w projekcie, należy pa-
miętać o znalezieniu punktu równowagi między kosztami, jakie będzie niosła z so-
bą kontrola a wynikami pracy. Dla przykładu, jeśli projekt będzie bardzo złożo-
ny i realizowany przez wiele osób, warto, aby mechanizm ten był rozbudowany.
W przypadku projektów o charakterze podobnym do tych, które były realizowa-
ne w przeszłości, można pozwolić sobie na mniej szczegółowe procedury kontro-
lne. Procesy kontroli pociągają za sobą określone koszty oraz pochłaniają czas,
a to z kolei zmniejsza opłacalność całego przedsięwzięcia dla wykonawcy i wydłu-
ża czas realizacji całego zadania.

6. Zakończenie projektu

Podczas realizacji bardzo wielu projektów, w momencie, kiedy zostaną wykonane
ostatnie prace wyszczególnione w harmonogramie, kiedy jest już gotowy produkt,
uznaje się, że projekt został zakończony. Uwolnione zostają zasoby niezbędne do
realizacji nowych zadań, a produkt jest przekazywany zleceniodawcy. Taki błąd
popełniany jest bardzo często i równie często jest on przyczyną wielu problemów.
Ważne jest, aby w końcowej fazie realizacji projektu — kiedy produkt jest już go-
towy, a do wykonania zostały jedynie prace organizacyjne — uczestniczył w nich
cały zespół. Udział całego zespołu gwarantuje, że dokumentacja projektu będzie
kompletna. Dodatkowo, jeśli pojawią się jakiekolwiek problemy w trakcie wdra-
żania produktu, będą one rozwiązywane w sposób sprawny. W trakcie kończenia
projektu konieczne jest zatem wykonanie pewnych czynności, z których najważ-
niejsze to:
1) analiza projektu po jego zakończeniu,
2) ocena projektu,
3) ocena dokonań zespołu,
4) spisanie końcowego dokumentu potwierdzającego odbiór produktu,
5) deklaracja sukcesu lub porażki projektu.

Czynności te, choć na pozór może mało istotne dla samego projektu, są niezwy-
kle ważne dla kierownika projektu i członków zespołu realizacyjnego, w kontek-
ście zebrania doświadczeń, które zostaną wykorzystane przy realizacji kolejnych
projektów.

6.1. Analiza jakości produktu końcowego

Jednym z najważniejszych zadań, jakie spoczywa na kierowniku projektu w fazie
kończenia projektu jest weryﬁkacja jakości produktu końcowego. Bez względu na
to, czego dotyczył projekt, konieczne jest sprawdzenie jego zgodności ze specyﬁka-
cją wymagań, jaka została przyjęta na początku. Końcowa ocena ma na celu sko-
rygowanie ewentualnych niezgodności przed przekazaniem ostatecznego produktu
w ręce klienta. W zależności od tego, co jest produktem wykonanym w projekcie,
różne będzie podejście do oceny. Ocena produktu końcowego musi być wykona-
na z punktu widzenia klienta. Musi być ona bardzo dokładna i krytyczna. Jeśli po-
jawią się jakieś niezgodności lub błędy, istnieje jeszcze możliwość ich wyelimino-
wania. Usunięcie nieprawidłowości powinno nastąpić przed formalnym oddaniem
produktu w ręce klienta. Choć błędy nie powinny pojawiać się na tym etapie prac
(powinny one zostać usunięte wcześniej), to jednak warto poświęcić czas na prze-
gląd produktu końcowego, aby uniknąć problemów z odbiorem końcowym.

6.2. Wartość projektu

W fazie zakończenia projektu niezbędne jest przeprowadzenie kalkulacji mającej
na celu wyliczenie rzeczywistej wartości wykonanej pracy. Dla każdego projek-
tu rezerwowany jest budżet, z którego zespół projektowy rozlicza się na bieżąco.
Podczas oceny wartości produktu końcowego należy odpowiedzieć sobie na py-
tanie: Ile udało się zarobić dzięki przystąpieniu do wykonania tego przedsięwzię-
cia?. Przy tej ocenie należy uwzględnić wszystkie poniesione koszty — zarówno te
zaplanowane, jak i wszelkie koszty dodatkowe. Odejmując otrzymaną wartość od
ceny brutto projektu, otrzyma się wartość netto projektu. Ustalenie wartości pro-
jektu jest niezbędne do zaprezentowania sponsorowi korzyści, jakie niesie z sobą
realizowanie projektów. Dodatkowo wiedza ta może być wykorzystana przy ko-
lejnych projektach do przygotowywania szacunkowych budżetów i kalkulowania
przyszłych zysków z realizacji nowych przedsięwzięć. Do oceny wartości projek-
tu mogą zostać wykorzystane różne metody matematyczne o mniejszym lub więk-
szym stopniu skomplikowania, które z różną dokładnością pozwalają na obliczenie
zyskowności. Oczywiście podczas wyliczania wartości projektu nie należy zapomi-
nać o pewnych trudnych do zmierzenia korzyściach. Jeśli produkt końcowy będzie
spełniał oczekiwania klienta, a końcowi użytkownicy będą się o nim pochlebnie
wyrażali, to można spodziewać się dobrych referencji, w wyniku których możliwe
będzie otrzymanie zlecenia na nowe, podobne projekty. Wycena tych wartości jest
trudna, ale na pewno może w przyszłości przynieść wymierne korzyści ﬁnansowe.

Wiele projektów w końcowej fazie realizacji, przed przekazaniem produktu końco-
wego w ręce klienta, poddawana jest ocenie niezależnych ekspertów. Działanie ta-
kie ma na celu uzyskanie niezależnej opinii, która nie będzie tylko oceną pojedyn-
czego produktu, ale może być również jego oceną na tle innych, podobnych pro-
duktów realizowanych przez inne ﬁrmy.

Wszelkie oceny wartości projektu — bez względu na to, czy są one robione we-
wnętrznie, czy też zlecane na zewnątrz — powinny odnosić się do zagadnienia
oceny rzeczywistego zwrotu z inwestycji (ROA). Takie podejście gwarantuje, że
obiecane przez wykonawcę korzyści, wynikające z realizacji projektu, faktycznie
będą miały miejsce. Weryﬁkacja tych korzyści jest niezbędna nie tylko ze względu
na ocenę zwrotu z inwestycji dla bieżącego projektu, ale także na ewentualne plany
dotyczące przyszłych projektów.

6.3. Odbiór projektu — końcowe porozumienie

Odbiór końcowego projektu może odbywać się w drodze nieformalnej lub formal-
nej. W przypadku nieformalnego odbioru projektu nie są spisywane umowy do-
tyczące zakończenia projektu czy nawet przyjęcia efektów końcowych. Projekty
odbierane w sposób nieformalny są z reguły projektami wewnętrznymi, realizo-
wanymi w ramach konkretnej organizacji. Przykładem takiego projektu może być
instalacja w sieci nowego modelu drukarek przez informatyków danego przedsię-
biorstwa w ramach jego centrali i podległych oddziałów. Ryzyko niepowodzenia
projektu jest niewielkie. W przypadku pojawienia się nieprzewidzianych trudności
łatwo jest powrócić do stanu pierwotnego lub inaczej zorganizować proces wymia-
ny urządzeń. W takim przypadku nie ma konieczności dokumentowania takiego
projektu. Zakończenie i odbiór produktu końcowego (nowych drukarek) może od-
bywać się bez jakichkolwiek dokumentów.

W przypadku projektów realizowanych dla ﬁrmy zewnętrznej, sformalizowanie
odbioru produktu końcowego staje się konieczne. Formalna akceptacja ma zwykle
postać umowy dotyczącej odbioru produktu, która jest podpisywana przez stronę
zlecającą i wykonującą projekt. Dokument ten powinien jasno określać, jakie ele-
menty będą przedmiotem odbioru oraz jakimi zasadami będzie kierował się zlece-
niodawca przy odbiorze produktu końcowego. W przypadku projektów informa-
tycznych umowa taka z reguły zawiera listę punktów kontrolnych (ang. check lists)
ze zdeﬁniowanymi wymaganiami, które będą sprawdzane.

6.4. Audyt po zakończeniu projektu

Na zakończenie projektu, podobnie jak w momencie jego uruchamiania, koniecz-
ne jest przeprowadzenie audytu. Celem końcowego audytu jest uzyskanie informa-
cji na temat sukcesu projektu oraz analiza samego projektu, efektywności zespołu
realizacyjnego, wartości końcowych rezultatów oraz uzyskanie końcowej aprobaty
ze strony zleceniodawcy.

W pierwszej kolejności należy dokonać sprawdzenia, czy projekt zapewnił realiza-
cję tych celów, jakie zostały postawione na początku. Jeśli nie udało się osiągnąć
zaplanowanego celu, konieczne jest ustalenie przyczyn takiego stanu.

Kolejne zadanie to ocena tego, czy projekt przez cały okres realizacji wykonywa-
ny był zgodnie z przyjętym harmonogramem. Odchylenia od przyjętych terminów
mogły dotyczyć pojedynczych zadań, ale mogły również odnosić się do całego pro-
jektu. Jeśli projekt został zrealizowany w innym terminie, niż zostało to pierwotnie
zaplanowane, należy odnaleźć przyczyny zmian harmonogramu i zastanowić się,
w jaki sposób tworzyć harmonogramy przy kolejnych projektach.

Trzecim elementem poddawanym audytowi końcowemu jest ocena korzyści bizne-
sowych, jakie przyniesie projekt. Przy wycenie wartości projektu uwzględnia się
niekiedy wskaźnik ROI (zwrotu z inwestycji).

Ostatnim elementem, jaki musi być przedmiotem audytu jest ustalenie, czy efek-
tem realizacji projektu jest dodatkowa wiedza, która może zostać wykorzystana
w ramach organizacji realizującej projekty. Jak powiedziano wcześniej, wszelkie
doświadczenia, jakie zdobywa zespół realizacyjny, gromadzone są w bazie wiedzy.
Wiedza ta może być wykorzystana przy realizacji kolejnych projektów w oparciu
o tę samą metodologię, ale również może posłużyć do modyﬁkacji procesów wy-
konywanych w ramach tej metodologii. Usprawnianie procesów w ramach meto-
dologii prowadzenia projektów ma na celu stworzenie optymalnego rozwiązania,
gwarantującego zrealizowanie projektu zgodnie z założonym zakresem, harmono-
gramem, budżetem oraz z wysoką jakością.

6.5. Raport końcowy

W fazie zakończenie projektu niezbędne jest tworzenie odpowiedniej dokumenta-
cji. Cała dokumentacja tworzona w trakcie realizacji poszczególnych zadań projek-
towych stanowi trzon raportu końcowego. Do wcześniej opracowanych dokumen-
tów dołączane są inne, specyﬁczne dla końcowej fazy realizacji i na ich podstawie
otrzymywany jest raport końcowy.

Stworzenie raportu końcowego wymaga ponownego:

1)  sformułowania wizji, która zapoczątkowała uruchomienie projektu,
2)  spisania propozycji technicznych realizacji projektu,
3)  określenia zakresu prac do wykonania,
4)  zdeﬁniowania wymaganych nakładów pracy,
5)  zdeﬁniowania harmonogramu realizacji zadań,
6)  zdeﬁniowania podziału  projektu  na  zadania  wykonywane  przez  poszczegól-

nych członków zespołu realizacyjnego,

7)  zamieszczenia protokołów ze wszystkich spotkań projektowych,
8)  dołączenia zatwierdzonych formularzy z wnioskami o zmiany do projektu,
9)  dołączenia raportów niezgodności z założeniami,

10)  dołączenia informacji o kontaktach zespołu realizacyjnego ze zleceniodawcą,
11)  zestawienia łącznych kosztów projektu,
12)  umowy zatwierdzenia zakresu projektu,
13) dołączenia raportu z audytu przeprowadzonego po zakończeniu projektu.

Dodatkowym elementem, jaki wchodzi w skład raportu końcowego jest ocena po-
szczególnych członków zespołu. Taka ocena może wpływać na wysokość uposaże-
nia, warunki zatrudnienia, awansu w organizacji lub na rozwiązanie umowy. Ele-
ment ten jest istotny z punktu widzenia wykorzystania w przyszłości poszczegól-
nych osób. Oceny powinny być trafne, uczciwe i profesjonalne — aby takie były,
konieczne jest dokumentowanie prac we wszystkich fazach realizacji projektu.

6.6. Ocena końcowa projektu

Należy wystawić ocenę dla całego projektu, bez względu na wyniki poszczegól-
nych ocen cząstkowych wystawionych poszczególnym półproduktom. Ocena koń-
cowa jest deklaracją sukcesu lub porażki projektu. Projekty, które kwaliﬁkuje się
do kategorii projektów niezakończonych lub kończących się niepowodzeniem sta-
nowią znaczny odsetek wszystkich rozpoczynanych projektów, a zatem konieczne
jest sporządzanie końcowych ocen również dla nich. Ocena końcowa w przypadku
projektów kończących się niepowodzeniem jest o tyle istotna, że pozwala na wy-
ciągnięcie wniosków i naniesienie niezbędnych korekt w całym procesie realizacji
projektu. Zmiany mogą sprowadzać się jedynie do zmiany zespołu realizacyjnego
i kierownika projektu lub mogą być znacznie szersze i odnosić się do całkowitej
zmiany podejścia do sposobu realizacji projektu.

W przypadku projektów, które z różnych powodów są przerywane, ocena końco-
wa pozwala na wprowadzenie odpowiednich zmian i korekt (jak w przypadku pro-
jektów zakończonych niepowodzeniem), ale również pozwala na przeprowadzenie
szacunków kwot, jakie udało się zaoszczędzić, przerywając przedsięwzięcie.

Bez względu na to, czy projekt kończy się porażką, czy sukcesem, zadaniem kie-
rownika projektu jest opracowanie raportu końcowego, który umożliwi zarządowi
lub sponsorowi projektu analizę i ocenę prac nad projektem. W raporcie takim mu-
szą znaleźć się wyniki weryﬁkacji zakresu prac, jakie były do wykonania oraz audy-
tu projektu po jego zakończeniu lub podjęciu decyzji o jego zaniechaniu.

7. Monitoring i ewaluacja projektu

Monitoring to uzyskiwanie informacji i danych o przebiegu projektu, dzięki czemu
można określić postęp działań w stosunku do założonego w fazie planowania oraz
uniknąć błędów i nieprawidłowości, które mogą zagrozić jego realizacji

. Działania

monitorujące wpływają niewątpliwie na jakość zarządzania projektem i wspierają
związane z nim procesy decyzyjne, a także umożliwiają zgromadzenie wiarygod-
nych danych o zaawansowaniu projektu.

Ze względu na podmiot wykonujący monitoring wyróżnia się monitoring we-
wnętrzny i zewnętrzny.

Monitoring wewnętrzny

jest wykonywany przez projektodawcę i polega na kontro-

lowaniu toku prac, nadzorowaniu przebiegu projektu oraz szybkim reagowaniu
w przypadku odchyleń do planu. Najczęściej wykorzystywanymi narzędziami mo-
nitoringu wewnętrznego jest kontrola dokumentacji rzeczowej i ﬁnansowej, a tak-
że nadzór nad wykonaniem zadań przez poszczególne komórki organizacyjne.

Monitoring zewnętrzny

jest przeprowadzany przez instytucję zewnętrzną, np. przeka-

zującą dotację na sﬁnansowanie projektu. Instrumentami tego monitoringu, oprócz
kontroli dokumentacji rzeczowej i ﬁnansowej, są wizyty monitorujące w miejscu
realizacji projektu oraz raportowanie.

Ze względu na cel badań monitoring można podzielić na rzeczowy i ﬁnansowy.

Monitoring rzeczowy

dostarcza informacji o postępie prac, działań w ramach wdra-

żania projektu, umożliwiających ocenę jego wykonania w stosunku do harmono-
gramu, celów i wskaźników ustalonych w projekcie. Natomiast

monitoring ﬁnanso-

informuje o ﬁnansowych aspektach realizacji projektu, tzn. o tym, czy środki

wydatkowane są zgodnie z budżetem projektu, czy istnieje płynność ﬁnansowa.

Podstawowym elementem monitoringu jest sprawozdawczość w formie raportów
z realizacji projektów. Aby przygotować taki raport, należy

1) określić na podstawie harmonogramu, jak daleki od osiągnięcia celu jest reali-

zowany projekt,

2)  opisać, jakie zmiany zaszły w stosunku do pierwotnego planu,
3)  określić postępy w realizacji projektu,
4)  przedstawić zadania postawione i zadania wykonane,
5)  jeśli jakieś działania nie zostały wykonane, podać, dlaczego tak się stało,
6)  opisać rezultaty działań w poprzednim okresie,
7)  podać, jakie wydatki zostały poniesione i wyszczególnić, na jakie cele,
8) zaplanować wydatki na następny okres.

Raport najczęściej składa się z trzech części:
1)

części ogólnej

— zawierającej dane teleadresowe oraz dane instytucji, do której

składany jest raport,

części rzeczowej

— w której opisuje się postępy realizacji planu rzeczowego,

przedstawia aktualny stan i przebieg realizacji, a także zadania wykonane i nie-
wykonane oraz planowane na następny okres sprawozdawczy,

części ﬁnansowej

— obejmującej opis aspektów ﬁnansowych wdrażania projektu

z uwzględnieniem faktycznie poniesionych wydatków.

Właściwie prowadzony monitoring projektu dostarcza ważnych informacji, które
zostaną wykorzystane w przyszłych działaniach ewaluacyjnych.

Barszcz I., 2007: Monito-

ring i ewaluacja projektu,

[w:] Zarządzanie projek-

tami współﬁnansowanymi

z funduszy publicznych,

(red.) M. Szwabe, Wolters

Kluwer Polska Sp. z o.o.,

Warszawa, s. 263.

Tamże, s. 267.

Ewaluacja projektu

to systematyczna i obiektywna ocena trwającego lub zakończo-

nego projektu. Ewaluacja jest badaniem mającym zawsze jakiś cel. Celem ewaluacji
jest najczęściej określenie skuteczności i efektywności danego projektu, zrozumie-
nie sposobów jego funkcjonowania, usprawnienie działań.

Ewaluację projektu ze względu na moment prowadzenia ewaluacji można podzie-
lić na:
1)

ewaluację wstępną

(ex ante) — jest ona przeprowadzana przed rozpoczęciem re-

alizacji projektu; jej celem jest weryﬁkacja założeń projektu, sprawdzenie, czy
oczekiwane oddziaływanie jest realistyczne, oszacowanie rezultatów;

ewaluację ciągłą (bieżącą)

(on-going) — jest ona przeprowadzana w trakcie reali-

zacji projektu; jej celem jest dogłębna analiza pytań, kwestii i problemów, które
pojawiają się w trakcie realizacji projektu, a także zaproponowanie konkretnych
rozwiązań;

ewaluację w połowie okresu realizacji

(mid-term) — kładzie ona nacisk na ocenę

dotychczasowego sposobu realizacji projektu, weryﬁkuje kierunek oraz aktual-
ność założeń, identyﬁkuje pierwsze efekty, a także proponuje bieżące korekty;

ewaluację końcową (pełną)

(ex post) — jest ona wykonywana po zakończeniu projek-

tu, skupia się na ocenie rezultatów długookresowych i określeniu rekomendacji.

Proces ewaluacji składa się z następujących etapów:
1)

planowanie ewaluacji

— w tym etapie należy uwzględnić następujące kwestie:

określenie celów ewaluacji, zakresu (co jest przedmiotem badania, jaki jest prze-
dział czasowy), momentu badania ewaluacyjnego, odbiorców ewaluacji, identy-
ﬁkacja dostępnych danych wyjściowych;

projektowanie ewaluacji

— w tym etapie powstaje koncepcja ewaluacji, tzn.

uszczegółowienie przedmiotu ewaluacji, sformułowanie listy pytań szczegóło-
wych, zakresu zadań, wymagań i procedur prowadzenia badania;

realizacja ewaluacji

— badanie ewaluacyjne można podzielić na cztery etapy:

(I) strukturyzacja, wybór i określenie kryteriów i elementów, które mają być
poddane ewaluacji, (II) zbieranie danych niezbędnych do analizy, (III) anali-
za, interpretacja zebranych danych, oszacowanie efektów projektu, zestawienie
i porównanie danych, (IV) ocena efektów projektu w odniesieniu do uprzednio
sformułowanych pytań ewaluacyjnych; realizacja ewaluacji kończy się sformuło-
waniem wniosków i rekomendacji;

raportowanie

— raport jest źródłem informacji o wynikach ewaluacji; struktu-

ra raportu powinna być dostosowana do potrzeb podmiotu zlecającego bada-
nie; najczęściej raport składa się z następujących elementów: (I) przedmiot ba-
dania, (II) procedura badawcza (zastosowana metodologia), (III) wyniki badań,
(IV) wnioski z ewaluacji, (V) rekomendacje.

Podczas realizacji ewaluacji stosuje się kilka metod badawczych. Uważa się, że naj-
pełniejszy obraz daje połączenie metod ilościowych i jakościowych. Pozwala to na
uzupełnienie informacji zdobytych jedną metodą innymi. Zebrane informacje moż-
na podzielić na dane pierwotne i wtórne oraz dane ilościowe i jakościowe.

Dane pierwotne

to dane uzyskiwane bezpośrednio ze źródła ich pochodzenia i zbie-

rane na potrzeby prowadzonej ewaluacji (np. wywiady, kwestionariusze, studia
przypadków).

Dane wtórne

to dane, które zostały wcześniej zgromadzone i są przetworzone. Są to

wszystkie dane dostępne w chwili rozpoczęcia badania (np. statystyki, raporty).

Dane ilościowe

dotyczą informacji liczbowych i podlegają analizie statystycznej.

Dane jakościowe

nie są wyrażone w liczbach, dotyczą opisu badanych zjawisk, są

niezbędne do właściwej interpretacji danych liczbowych.

Podstawowe metody zbierania danych to: analiza dokumentów, wywiady indywi-
dualne, kwestionariusze, zogniskowane wywiady grupowe, obserwacja, techniki
grupowe.

W końcowej fazie procesu ewaluacji stosuje się różnorodne metody, których celem
jest ocena efektów projektu. Najczęściej stosowane metody to:
1)

panel ekspertów

— metoda ta polega na wykorzystaniu wiedzy niezależnych specja-

listów w dziedzinie objętej badaniem, którzy — w oparciu o dostępne dokumenty
i dane — oceniają efekty projektu w kontekście kryterium ewaluacyjnego,

analiza SWOT

— to analiza mocnych i słabych stron danego przedsięwzięcia oraz

szans i zagrożeń, jakie wynikają z czynników zewnętrznych,

benchmarking

— to ocenianie efektów projektu przez porównanie ich z efektami

podobnych działań, które zostały uznane i mogą służyć jako przykład,

analiza kosztów i korzyści projektu dla beneﬁcjentów

modele ekonometryczne

— są wykorzystywane do oszacowania wpływu projektu

na funkcjonowanie danego zjawiska.

8. Przykładowe metodyki

realizacji projektów

Realizacja projektu zgodnie z pewnymi przyjętymi przez zespół realizacyjny regu-
łami jest o tyle ważna, że wszyscy uczestnicy projektu powinni w trakcie jego reali-
zacji posługiwać się tym samym językiem, a procedury ich postępowania powinny
być jednakowe.

Praktycznie każde przedsięwzięcie jest obecnie realizowane w oparciu o określoną
metodykę. Wiele znaczących ﬁrm posiada swoje własne metodyki — przykładem
może być IBM, Microsoft i inne. Wiele ﬁrm realizuje projekty w oparciu o pewne
uniwersalne metodyki, takie jak PRINCE2 czy PMI (Project Management Institute),
które są modyﬁkowane do potrzeb konkretnego projektu.

Należy pamiętać, że każda metodyka — zarówno ﬁrmowa, jak i uniwersalna — jest
modyﬁkowana w oparciu o zdobyte w kolejnych projektach doświadczenia i dosto-
sowywana do aktualnie panujących warunków środowiskowych, w jakich realizo-
wane są projekty.

8.1. Metodyka ﬁrmy IBM

Metodyka ﬁrmy IBM oparta jest na modelu kaskadowym, gdzie odpo-
wiednie, kolejne fazy realizacji projektu następują po sobie. Najważniejsze
w tym modelu są dwie fazy: faza wstępna i faza realizacji — dzieje się tak
z uwagi na to, że zawierają one elementy, które mają niebagatelne znaczenie
dla ukończenia całego projektu. Na rysunku 6 przedstawiony został model
metodyki IBM.

Niezwykle ważnym elementem w metodyce IBM jest moment wyboru, wy-
stępujący po zebraniu wymagań projektowych. Decyzja o możliwości za-
niechania realizacji projektu bądź też o przemodelowaniu założeń może
być podjęta tylko w określonym momencie — między fazą wymagań pro-
jektowych a fazą ustanowienia projektu. Jeżeli zostanie podjęta decyzja
Tak, konieczne staje się ukończenie projektu.

W metodyce IBM można wyodrębnić następujące fazy:
1. Identyﬁkacja projektu — czyli bardzo precyzyjne określenie założeń i ce-

lów ustanawianego projektu. Faza ta musi zostać zrealizowana z należytą
starannością z uwagi na fakt, że po jej zakończeniu musi zapaść decyzja
dotycząca tego, czy projekt będzie realizowany. Jeśli decyzja będzie po-
zytywna, nie ma już możliwości przemodelowania założeń, należy tylko
zrealizować projekt w zaproponowanym kształcie. Zbierane materiały,
które są punktem wyjścia do założeń projektowych, muszą być rzetelne
i precyzyjne, co oznacza, że informacje te musza być uzyskane od najbar-
dziej kompetentnych osób. W tej fazie muszą zostać wyjaśnione wszelkie
wątpliwości i niedomówienia między zleceniodawcą a realizatorami projektu.
Po zebraniu założeń deﬁniowany jest zakres projektu, szacowane są jego koszty,

Rysunek 6

Model metodyki IBM

tworzony jest harmonogram realizacji poszczególnych zadań. Dodatkowo przyj-
mowane są wymagania jakościowe, które musi spełniać końcowy produkt, aby
był do zaakceptowania przez klienta. Po wykonaniu tych operacji tworzony jest
zespół projektowy i deﬁniowane są role poszczególnych osób w nowym projek-
cie. Należy pamiętać, że niekoniecznie muszą to być role tylko i wyłącznie reali-
zatorów projektu — mogą to być role, jakie będą pełnić użytkownicy końcowi
po zrealizowaniu projektu

Na zakończenie tej fazy przygotowywany jest doku-

ment projektowy, który zawiera wszystkie wymienione wcześniej elementy. Na
jego podstawie podejmowana jest decyzja o uruchomieniu projektu bądź jego
zaniechaniu. Jak powiedziano wcześniej, podpisanie decyzji jest równoznaczne
z uruchomieniem projektu w kształcie, jaki został zaproponowany w dokumen-
cie i nie ma możliwości jego zmiany. Zmiany oczywiście będą konieczne, ale ich
zakres nie może naruszać pewnego zaproponowanego i przyjętego szablonu. Jak
widać, ta faza realizacji projektu jest niezwykle istotna dla uruchomienia projek-
tu, a następnie zakończenia go z sukcesem.

2. Deﬁnicja projektu — faza, w której określa się pojęcia, jakimi będzie posługi-

wał się zespół projektowy. Tworzony jest słownik pojęć i deﬁnicji, w celu jedno-
znacznej interpretacji zadań realizowanych przez wszystkich jego uczestników.
Element  ten  zapewnia,  że  komunikacja  między  uczestnikami  projektu  będzie
przebiegała bardzo sprawnie. W przypadku dużych projektów, o dużej złożono-
ści, w które zaangażowana jest duża grupa osób, sprawna komunikacja ma nie-
bagatelny wpływ, gdyż zapewnia, że informacje i decyzje będą podejmowanie
szybko i będą oparte na wiarygodnej i rzetelnej informacji. Aby elementy komu-
nikacji działały w sposób prawidłowy, konieczne jest zorganizowanie spotkania
całego zespołu projektowego, podczas którego przedstawione zostaną wszystkie
zasady, jakie będą obowiązywały w trakcie realizacji projektu. Podczas takie-
go  spotkanie  prezentowana  jest  z reguły  cała  struktura  organizacyjna  projek-
tu, przedstawiani są główni „aktorzy”: sponsor, kierownik projektu oraz osoby
odpowiedzialne za zrealizowanie zadań w poszczególnych obszarach. Podczas
realizacji tej fazy projektu konieczne jest również określenie zasad postępowa-
nia z zagrożeniami, jakie na pewno pojawią się w projekcie. Uczestnicy projek-
tu muszą wiedzieć, czy problemy mają rozwiązywać we własnym zakresie, czy
też przenosić je na wyższe poziomy struktury organizacyjnej. Dobrze jest, jeśli
forma informowania o zagrożeniach jest z góry określona. Aktualnie najczęściej
przybiera ona postać formularzy elektronicznych, którymi zarządza odpowied-
nia aplikacja wspomagająca cały projekt (dotProject, MS Project). Kolejny ele-
ment deﬁniowania samego projektu to dokumentacja projektowa. Jest ona nie-
zwykle  istotna  —  gwarantuje,  że  wszystkie  działania  będą  udokumentowane
i w przypadku pojawienia się jakichkolwiek rozbieżnych stanowisk będzie moż-
na prześledzić sposób realizacji zadania. Dokumentacja będzie również niezbęd-
na w momencie zakończenia realizacji projektu i przekazywania produktu użyt-
kownikowi końcowemu. Z reguły do zadania związanego z prowadzeniem do-
kumentacji projektowej powołuje się jedną osobę, odpowiedzialną tylko i wy-
łącznie za to zadanie.

3. Realizacja projektu — faza, w której tak naprawdę zespół rozpoczyna realizację

całego przedsięwzięcia w oparciu o przyjęte na wstępie założenia oraz zgodnie
z przyjętymi zasadami postępowania. Wraz z rozpoczęciem prac rusza proces
dokumentowania prac. Przydatne stają się tutaj narzędzia wspomagające pracę
grupową (była już o nich mowa wcześniej). W momencie rozpoczęcia projektu,
w oparciu o wcześniej ustalone założenia projektowe przygotowywane są szcze-
góły związane z realizacją przedsięwzięcia. Należy dokładnie ustalić, jakie za-
dania, w jakim czasie, w jakiej kolejności, przez kogo i z wykorzystaniem jakiej
technologii będą realizowane. Taki szczegółowy plan przekazywany jest zespo-
łowi, który zaczyna realizować zadania. Szczegółowe plany muszą zawierać: za-
dania do wykonania, węzłowe punkty, informacje na temat przydzielonych zaso-

bów, terminy testów i szkoleń, terminy spotkań podsumowujących zakończenie
poszczególnych zadań oraz kontrole prawidłowości realizacji całego projektu.
W trakcie takich kontroli sprawdzana jest zarówno terminowość realizacji prac,
jakość prac, jak i wykorzystanie budżetu. Realizacja samego projektu może prze-
biegać współbieżnie, co oznacza, że w tym samym czasie pracę realizuje kilka ze-
społów. Członkowie poszczególnych zespołów realizują zadania merytoryczne,
natomiast kierownicy są odpowiedzialni za koordynację wszystkich działań. Na
kierownikach poszczególnych zespołów w tej fazie realizacji projektu spoczywa-
ją również obowiązki związane z dokumentowaniem postępu prac. Według tej
metodyki wszystkie procesy realizacyjne (planowanie, realizacja, testy i wdroże-
nie) traktowane są jako jedna spójna całość. Takie podejście wynika z faktu, że
projekty są z reguły bardzo złożone i konieczne jest kompleksowe prowadzenie
tych wszystkich prac.

4. Ukończenie projektu — jest to ostatnia faza realizacji projektu. W tej fazie do-

konywany  jest  odbiór  produktu  końcowego,  wykonanego  zgodnie  z przyjęty-
mi  na  początku  założeniami,  w zaplanowanym  terminie  i przy  wykorzystaniu
przyznanego  budżetu.  Jeżeli  w trakcie  realizacji  projektu  pojawiały  się  jakieś
nowe założenia, to nie były one włączane do już realizowanego projektu, ale
były przygotowywane do nowego projektu. W fazie ukończenia projektu odby-
wa się formalny odbiór produktu końcowego. Ważne jest, aby był on sformalizo-
wany i wiązał się z przekazaniem całej dokumentacji projektowej, rozliczeniem
z zasobów, jakie zostały przydzielone do jego realizacji (uwolnieniem zasobów)
oraz aby dokonane zostało rozliczenie budżetu. W fazie zakończenia następuje
również podsumowanie całego projektu, w celu zebrania wszystkich doświad-
czeń i przekazania ich do prowadzonej w organizacji bazy wiedzy. Wiedza i do-
świadczenia zebrane podczas realizacji każdego projektu mogą zostać wykorzy-
stane przy realizacji kolejnych projektów.

8.2. Metodyka PRINCE2

Metodyka prowadzenia projektów PRINCE2 została stworzona przez Central
Computer and Telecommunications Agency (CCTA) i wykorzystywała założenia
zaczerpnięte z metodyki opracowanej przez Simpact System Ltd., znanej pod na-
zwą PROMPT. Od 1979 roku metodyka ta stała się standardem obowiązującym
na Wyspach Brytyjskich i była wykorzystywana we wszystkich realizowanych tam
projektach. Metodyka ta była na tyle uniwersalna, że możliwe stało się jej stosowa-
nie nie tylko do projektów inżynierskich, ale także do dowolnych projektów (po
wprowadzeniu odpowiednich modyﬁkacji). Metodyka PRINCE2 podpowiada roz-
wiązania, jakie można wykorzystać, aby efektywnie zarządzać przedsięwzięciem.
W metodyce tej pod pojęciem projekt kryje się:
1) proces, który ma swój początek i koniec,
2) proces, w którym wszyscy jego uczestnicy mają jasno określone cele do zrealizo-

wania, wiedzą, w jaki sposób je realizować oraz mają przydzielone role i zakres
odpowiedzialności.

Projekty wykorzystujące metodykę PRINCE2 muszą spełniać następujące warunki:
1) muszą odnosić się do wszystkich procesów ukierunkowanych na stworzenie sku-

tecznego środowiska do zarządzania projektem,

2) muszą posiadać konkretnie zdeﬁniowane uzasadnienie biznesowe, prezentujące

korzyści i ryzyko przedsięwzięcia,

3) muszą posiadać precyzyjne wyobrażenie produktu końcowego,
4) muszą posiadać określone sposoby osiągania wyznaczonych celów,

5) muszą posiadać określone zasoby (ludzi, materiały, sprzęt) niezbędne do zreali-

zowania projektu,

6) muszą posiadać odpowiednią strukturę organizacyjną, z jasno określonymi za-

kresami obowiązków oraz odpowiedzialności za realizację zadań.

Zarządzanie projektem z wykorzystaniem metodyki PRINCE2 opiera się na proce-
sowym podejściu do takiego przedsięwzięcia.

W metodyce prowadzenia projektów PRINCE2 organizacja prac oraz prowadze-
nie dokumentacji zostało ograniczone do czterech głównych etapów, pokazanych
na rysunku 7:
1) projektowania wstępnego,
2) mobilizacji projektu,
3) kierowania projektem, w skład którego wchodzi realizacja etapu, wytwarzanie

produktu i jego testowanie,

4) zamykania projektu.

Podczas wstępnego projektowania przygotowywana jest specyﬁkacja użytkowa
— zbierane są wymagania użytkownika. Następnie określana jest niezbędna infra-
struktura techniczna i organizacyjna dla całego projektu, określane są uwarunko-
wania realizacyjne i legislacyjne, wybierani są wykonawcy poszczególnych zadań
czy też grup zadań i ustalany jest budżet. W wyniku tych prac powstaje koncepcja
projektu, który jest punktem wyjścia dla wszelkich dalszych prac oraz punktem od-
niesienia w procesie kontroli. Koncepcja projektu, zgodnie z metodyką PRINCE2,
powinna określać:
1) jaki zakres prac zostanie wykonany,
2) jaki jest powód realizacji zadań,
3) kto będzie realizował poszczególne zadania,
4) jaki będzie sposób realizacji zadań,
5) w jakim terminie zostaną wykonane te zadania.

Zgodnie z tą metodyką, na etapie mobilizacji projektu należy kierować się nastę-
pującymi zasadami:
1) projekt jest procesem, który ma z góry zaplanowaną datę rozpoczęcia i zakoń-

czenia,

Rysunek 7

Procesowe ujecie zarządzania

projektem, zgodnie z metodyką

PRINCE2

2) wszystkie elementy tego przedsięwzięcia zostały jasno określone, znane są cele,

jakie należy osiągnąć, określona jest odpowiedzialność uczestników oraz ich
role w projekcie,

3) dobrze zorganizowany proces zarządzania daje szansę na zakończenie projektu

sukcesem.

Na tym etapie deﬁniowane są cele, ustalane produkty końcowe prac poszczegól-
nych zespołów, zakres realizacji przyjętych założeń oraz wszelkiego rodzaju uwa-
runkowania, jakie mogą mieć wpływ na kształt produktu końcowego. Dodatkowo
określane są założenia jakościowe, sposoby identyﬁkacji ryzyk projektowych, opra-
cowywany jest proces kontroli projektu oraz szczegółowy plan kolejnego etapu
— kierowania projektem. Na tym etapie powstaje również formalny dokument, bę-
dący podstawą do rozpoczęcia dalszych prac.

Proces kierowania projektem odbywa się na wszystkich etapach projektu — od jego
rozpoczęcia do zakończenia. W jego skład wchodzą:
1) sterowanie projektem, co gwarantuje przyjęcie optymalnych rozwiązań meryto-

rycznych i organizacyjnych,

2) przyjęcie projektu do realizacji,
3) zatwierdzenie rozpoczęcia realizacji kolejnych etapów projektu oraz reagowanie

na pojawiające się w projekcie zagrożenia dla realizacji poszczególnych zadań,

4) sterowanie zakresem prac przez zarządzanie przydzielonymi do projektu zaso-

bami,

5) podejmowanie doraźnych decyzji, będących konsekwencją monitorowania po-

stępu prac,

6) podjęcie decyzji o zakończeniu projektu.

Proces ten odbywa się dwupoziomowo: na poziomie operacyjnym — bieżącego wy-
konywania zadań projektowych, oraz na wyższym poziomie, gdzie podejmowane
są decyzje biznesowe i organizacyjne, kluczowe dla całego projektu. Z powodu zło-
żoności tego procesu zostały w nim wyróżnione fazy wykonawcze, związane z sa-
mą realizacją danego etapu oraz wytwarzaniem i testowaniem produktu.

W fazie realizacji zatwierdzane są grupy zadań do wykonania, przygotowywane
są informacje o postępie prac oraz monitorowane są zmiany w stosunku do przy-
jętych planów. Wykonywana jest również cała sprawozdawczość oraz zatwierdza-
ne są wszelkie działania korygujące i naprawcze, jakie należało wykonać na skutek
pojawiających się zagrożeń.

W fazie wytwarzania i testowania odbywa się sprawdzenie zgodności funkcjonal-
ności produktu z wymaganiami klienta, jakie zostały złożone w momencie rozpo-
częcia projektu, terminowości realizacji zadań, realizacji budżetu przyznanego na
projekt oraz kontrola jakości produktu końcowego.

Ostatni etap to zamykanie projektu, w trakcie którego weryﬁkowana jest zgod-
ność produktów z założonym celem oraz badane są wskaźniki jakościowe produk-
tu. W następnej kolejności dokonywany jest formalny odbiór produktu i przekazy-
wana jest dokumentacja. Doświadczenia te przenoszone są do bazy wiedzy, która
wykorzystywana jest przy kolejnych projektach.

8.3. Metodyka ﬁrmy Microsoft

Dotychczas zaprezentowane metodyki odnosiły się do projektów realizowanych na
zlecenie konkretnej osoby — sponsora projektu. W przypadku projektów realizo-

wanych dla bardzo szerokiej rzeszy odbiorców istnieje kilka barier, które uniemoż-
liwiają realizację takich przedsięwzięć z wykorzystaniem tych metodyk. Podsta-
wowym problemem jest kwestia zebrania założeń dotyczących kształtu produktu
końcowego. Z takim problemem spotkała się ﬁrma Microsoft, realizująca projekty
dla bardzo szerokiego grona użytkowników końcowych, o różnych preferencjach
i wymaganiach. W związku z powyższym została opracowana metodologia, która
ogranicza wpływ tego typu ograniczeń do akceptowalnego minimum.

W metodyce ﬁrmy Microsoft zostało zastosowane podejście spiralne, gdzie pod-
czas kolejnych iteracji dochodzi się do produktu końcowego. Model ten zakła-
da spiralne dochodzenie do docelowych rozwiązań, przez powtarzanie sekwencji
pewnych działań.

W podejściu ﬁrmy Microsoft działania, które mają doprowadzić do rozwiązania
wykonywane są cyklicznie: od koncepcji do wyprodukowania kolejnej wersji wy-
puszczanego na rynek oprogramowania. Propozycje modyﬁkacji i nowe koncepcje
wprowadzania zmian do produktu uzyskiwane są od użytkowników końcowych.

Etapy, na jakie podzielony jest jeden cykl spirali wytwarzania oprogramowania
zgodnie z metodyką Microsoft, to:
1) opracowanie wizji produktu,
2) planowanie,
3) wytwarzanie,
4) stabilizacja.

Każdy z tych etapów dzielony jest na mniejsze fragmenty, w których ustalane są
punkty węzłowe. W przypadku fazy związanej z zatwierdzeniem wizji projektu
ustalone są trzy punkty węzłowe: sformułowanie trzonu zespołu realizacyjnego,
opracowanie pierwszej wersji dokumentu opisującego wizję produktu oraz pierw-
szej wersji analizy ryzyka. W fazie planowania powstaje pierwsza wersja specyﬁka-
cji funkcjonalnej produktu, pierwsza wersja ogólnego planu realizacji projektu oraz
pierwsza wersja ogólnego harmonogramu realizacji. Jako produkt końcowy tej fazy
zatwierdzany jest plan realizacji projektu. W fazie wytwarzania oprogramowania

Rysunek 8

Model spiralnej metodyki

ﬁrmy Microsoft

realizowane są kolejne jego wersje, aż do otrzymania wersji odpowiadającej założo-
nej na początku funkcjonalności. Ostatnia faza to stabilizacja wytworzonego pro-
duktu — powstaje w niej produkt, który może zostać przekazany użytkownikom
końcowym.

W spiralnej metodyce Microsoft niezwykle ważnym elementem jest kierowanie
zespołem. Odrzucane są w niej modele hierarchiczne — wszyscy członkowie ze-
społu są jednakowo ważni i każdy od początku spełnia jasno określoną rolę, któ-
ra jest odzwierciedleniem jego pozycji w zespole. Podział władzy w projekcie jest
rozproszony między wszystkich członków i ulega zmianie w zależności od etapu
prac. Kluczowe decyzje podejmowane są kolektywnie, na zasadzie jednomyślności
wszystkich uczestników projektu. Na rysunku 9 pokazany jest model zespołu wy-
konawczego.

Jak widać na przykładzie trzech powyżej zaprezentowanych metodyk zarządzania
projektami, każda z nich w nieco inny sposób podchodzi do projektu. Jest to zwią-
zane ze specyﬁką realizowanych z jej wykorzystaniem projektów, pewnych uwa-
runkowań historycznych oraz możliwością posiłkowania się doświadczeniami uzy-
skanymi we wcześniejszych projektach.

Rysunek 9

Model zespołu wykonawczego

w metodyce Microsoft

Document Outline