Czynności związane z zakończeniem projektu
2. Analiza jakości produktu finalnego
2.2. Odbiór projektu — końcowe porozumienie
2.3. Audyt po zakończeniu projektu
Czynności związane z zakończeniem projektu
2. Analiza jakości produktu finalnego
2.2. Odbiór projektu — końcowe porozumienie
2.3. Audyt po zakończeniu projektu
2
Wstęp
W poprzednich modułach zostały omówione podstawowe procesy realizowane
w ramach wykonywania projektu:
— kontrola i raportowanie,
— zarządzanie pracą,
— zarządzanie zasobami,
— zarządzanie jakością,
— zarządzanie konfiguracją.
Prawidłowe wykonywanie tych procesów jest gwarancją, że projekt zrealizowany
będzie zgodnie z przyjętymi założeniami, a dodatkowo nie zostaną przekroczone
terminy w przyjętym harmonogramie oraz założony budżet. Również jakość pro-
duktu finalnego musi być na poziomie akceptowalnym przez zleceniodawcę.
Ostatnim procesem przygotowania projektu jest zarządzanie konfiguracją, w któ-
rym to — w ostatniej jego fazie — dochodzi do przekazania wszelkich narzędzi
umożliwiających sprawne zarządzanie. W trakcie realizacji tego procesu należy
wykonać również pewne czynności, o których bardzo często się zapomina, a które
są niezwykle istotne dla prawidłowego zrealizowania projektu jako całości. Czyn-
ności te związane są z zakończeniem projektu.
3
1. 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:
— analiza projektu po jego zakończeniu,
— ocena projektu,
— ocena dokonań zespołu,
— spisanie końcowego dokumentu potwierdzającego odbiór produktu,
— 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.
4
2. Analiza jakości produktu finalnego
Jednym z najważniejszych zadań, jakie spoczywa na kierowniku projektu w fazie
kończenia projektu jest weryfikacja jakości produktu finalnego. Bez względu na
to, czy produktem tym jest sieć komputerowa, czy też oprogramowanie, koniecz-
ne jest sprawdzenie jego zgodności ze specyfikacją wymagań, jaka została przyję-
ta na początku. Końcowa ocena ma na celu skorygowanie ewentualnych niezgod-
noś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.
W przypadku oprogramowania ocena będzie polegała na dokładnym przetestowa-
niu wszystkich aplikacji i sprawdzeniu, czy działają poprawnie. W przypadku sieci
komputerowej ocena będzie sprowadzała się do przeprowadzenia testów działania
wszystkich urządzeń (stacji roboczych, drukarek), dostępu do sieci Internet, czy
wreszcie przepustowości tej sieci. 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,
gdyż powinny one zostać usunięte wcześniej, to jednak warto poświęcić czas na
przegląd produktu końcowego, aby uniknąć problemów z odbiorem końcowym.
2.1. 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 projektu
rezerwowany jest budżet, z którego zespół projektowy rozlicza się na bieżąco. Pod-
czas oceny wartości finalnego produktu należy odpowiedzieć sobie na pytanie: 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 zaplanowa-
ne, jak i wszelkie koszty dodatkowe. Odejmując otrzymaną wartość od ceny brutto
projektu otrzyma się wartość netto projektu. Ustalenie wartości projektu jest nie-
zbędne do zaprezentowania sponsorowi korzyści, jakie niesie ze sobą realizowa-
nie projektów. Dodatkowo wiedza ta może być wykorzystana przy kolejnych pro-
jektach do przygotowywania szacunkowych budżetów i kalkulowania przyszłych
zysków z realizacji nowych przedsięwzięć. Do oceny wartości projektu mogą zo-
stać wykorzystane różne metody matematyczne o mniejszym lub większym 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 zapominać o pew-
nych, trudnych do zmierzenia, korzyściach. Jeśli produkt finalny będzie spełniał
oczekiwania klienta, a końcowi użytkownicy będą się o nim pochlebnie wyraża-
li, 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 finansowe.
Wiele projektów w końcowej fazie realizacji, przed przekazaniem produktu final-
nego 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-
5
czego produktu, ale może być również jego oceną na tle innych, podobnych pro-
duktów, realizowanych przez inne firmy.
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. Weryfikacja 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.
2.2. 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 finalnego (nowych drukarek) może od-
bywać się bez jakichkolwiek dokumentów.
W przypadku projektów realizowanych dla firmy zewnętrznej sformalizowanie od-
bioru 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ę zle-
ceniodawca przy odbiorze finalnego produktu. W przypadku projektów informa-
tycznych umowa taka z reguły zawiera listę punktów kontrolnych (ang. check lists)
ze zdefiniowanymi wymaganiami, które będą sprawdzane.
2.3. Audyt po zakończeniu projektu
Na zakończenie projektu, podobnie jak w momencie jego uruchamiania, koniecz-
ne jest przeprowadzenie audytu. Celem końcowego audyt 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
6
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 niekiedy uwzględ-
nia się wskaźnik ROI (zwrotu z inwestycji).
Ostatnim elementem, jaki musi być przedmiotem audytu jest ustalenie, czy efektem
realizacji projektu jest dodatkowa wiedza, która może zostać wykorzystana w ra-
mach organizacji realizującej projekty. Jak powiedziano we wcześniejszych modu-
łach, wszelkie doświadczenia, jakie zdobywa zespół realizacyjny, gromadzone są
w bazie wiedzy. Wiedza ta może być wykorzystana przy realizacji kolejnych projek-
tów w oparciu o tę samą metodologię, ale również może posłużyć do modyfikacji
procesów wykonywanych w ramach tej metodologii. Usprawnianie procesów w ra-
mach metodologii prowadzenia projektów ma na celu stworzenie najbardziej opty-
malnego rozwiązania, gwarantującego zrealizowanie projektu, zgodnie z założo-
nym zakresem, harmonogramem, budżetem oraz z wysoką jakością.
2.4. 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, specyficzne dla końcowej fazy realizacji i na ich podstawie
otrzymywany jest raport końcowy.
Stworzenie raportu końcowego wymaga ponownego:
— sformułowania wizji, która zapoczątkowała uruchomienie projektu,
— spisania propozycji technicznych realizacji projektu,
— określenia zakresu prac do wykonania,
— zdefiniowania wymaganych nakładów pracy,
— zdefiniowania harmonogramu realizacji zadań,
— zdefiniowania podziału projektu na zadania, które będą wykonywane przez po-
szczególnych członków zespołu realizacyjnego,
— zamieszczenia protokołów ze wszystkich spotkań projektowych,
— dołączenia zatwierdzonych formularzy z wnioskami o zmiany do projektu,
— dołączenia raportów niezgodności z założeniami,
— dołączenia informacji o kontaktach zespołu realizacyjnego ze zleceniodawcą,
— zestawienia łącznych kosztów projektu,
— umowy zatwierdzenia zakresu projektu,
— 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.
7
2.5. Deklaracja sukcesu lub porażki
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 kwalifikuje 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ńcowa
pozwala na wprowadzenie odpowiednich zmian i korekt, jak w przypadku projek-
tów zakończonych niepowodzeniem, ale również pozwala na przeprowadzenie sza-
cunkó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-
sza znaleźć się wyniki weryfikacji zakresu prac, jakie były do wykonania oraz audy-
tu projektu po jego zakończeniu lub podjęciu decyzji o jego zaniechaniu.
8
Bibliografia
1. Balser T., 2000: Ewolucja przedsiębiorstwa — od realizowania projektów do
orientacji na projekty, [w:] Project Management — efektywne zarządzanie
przedsięwzięciami, WEKA, Warszawa.
2. Bays M. E., 2001: Inżynieria oprogramowania. Metodyka wprowadzania opro-
gramowania na rynek, WNT, Warszawa.
3. Chong Y. Y., Brown E. M., 2001: Zarządzanie ryzykiem projektu, Dom Wy-
dawniczy ABC, Kraków.
4. Chrościcki Z., 2001: Zarządzanie projektem — zespołami zadaniowymi, Wy-
dawnictwo C. H. Beck, Warszawa.
5. Frame J. D., 2001: Zarządzanie projektami w organizacjach, WIG-PRESS, War-
szawa.
6. Lewandowski J., 1999: Projektowanie systemów informacyjnych. Zarządzanie
w przedsiębiorstwie, Wydawnictwo Politechniki Łódzkiej, Łódź.
7. Metodyki zarządzania projektami informatycznymi, 2004: Wydawnictwo Pla-
cet, Warszawa.
8. Morris P. W. G., 1981: Managing Project Interfaces; Key Point for Project Suc-
cess In Cleand and King. Project Management Handbook, Prentice-Hall, Engle-
wood Cliffs, N. J.
9. Phillips J., 2004: Zarządzanie projektami IT, Wydawnictwo Helion, Gliwice.
10. Pietras P., Szmit M., 2003: Zarządzanie projektem. Wybrane metody i techniki,
Oficyna Księgarsko-Wydawnicza, Łódź.
11. Project management — efektywne zarządzanie przedsięwzięciami, 2001: praca
zbiorowa, Wydawnictwo Informacji Zawodowej WEKA sp. z o.o., Warszawa.
12. Szczepańska K., 1999: Techniki menedżerskie w TQM, Wydawnictwo Norma-
lizacyjne ALFA-WERO, Warszawa.
13. Szyjewski Z., 2001: Zarządzanie projektami informatycznymi. Metodyka two-
rzenia systemów informatycznych. Czynniki sukcesu. Wymiarowanie projektu,
Agencja wydawnicza Placet, Warszawa.