Etapy realizacji projektów
Wstęp 2
1. Projekty a poziom dojrzałości organizacji 3
1.1. Najczęściej popełniane błędy 4
1.2. y
ródła porażek 6
1.3. Szczegółowa definicja projektu 6
1.4. Cykl życia projektu 8
2. Realizacja projektu 10
2.1. Decyzja o rozpoczęciu projektu 10
2.2. Rozpoznawanie potrzeb 10
2.3. Definiowanie potrzeb 10
2.4. Planowanie 11
2.5. Realizacja 14
2.6. Kontrola 15
2.7. Ocena 15
2.8. Zakończenie 15
Bibliografia 17
Wstęp
W wielu przedsiębiorstwach praktycznie codziennie realizowane są najróżniejsze
projekty. Nie są to, co prawda, tylko i wyłącznie projekty informatyczne, ale i in-
ne, które muszą również być zakończone sukcesem. Większość działań wykonywa-
nych w każdej organizacji, to tak naprawdę działania rutynowe, które realizuje się
już po raz kolejny. Inne są zupełną nowością i właśnie te inne to projekty. Podczas
realizacji tych projektów, wykorzystywane są różnego rodzaju techniki i narzędzia
zwiększające prawdopodobieństwo osiągnięcia sukcesu. Projektami da się skutecz-
nie zarządzać, ale konieczne jest nauczenie się wielu technik, które pozwolą uni-
kać typowych błędów, jakie bardzo często popełniane są w procesie zarządzania.
Do podstawowych zaliczyć można błędy związane ze złą organizacją, złą specyfi-
kacją potrzeb odbiorców, złym planowaniem, złym nadzorem nad projektem. War-
to w tym miejscu zwrócić uwagę na fakt, że kurs ten nie przedstawi konkretnych
rozwiązań, które będzie można przenieść do dowolnego projektu, a ma być jedynie
zbiorem różnego rodzaju przykładów, uwag i sugestii, których umiejętne wykorzy-
stanie może przyczynić się do sukcesu projektu.
2
1. Projekty a poziom dojrzałości
organizacji
W chwili obecnej przedsiębiorstwa, ze względu na poziom swojej dojrzałości, mogą
w różny sposób podchodzić do realizacji projektów (Balser, 2000):
 projekty, jakie wykonują mogą być realizowane ad hoc,
 zarządzanie projektami może odbywać się na poziomie operacyjnym,
 zarządzanie projektami może odbywać się na poziomie strategicznym,
 organizacja jest zorientowana na realizację projektów.
Krótka charakterystyka sposobów podejścia do projektów oraz najczęściej osiąga-
ne efekty pozwolą na podjęcie określonych działań, które powinny zapewnić osią-
gnięcie sukcesu.
Projekty realizowane ad hoc z reguły charakteryzują się brakiem precyzyjnego
określenia celów i efektywnie działających zespołów zadaniowych, co w konse-
kwencji prowadzi do powstawania konfliktów między zespołem a organizacją,
dla której projekt jest realizowany. W projektach tego typu pracownicy są najczę-
ściej słabo zmotywowani, a sam projekt niesie ze sobą wysokie ryzyko nieukoń-
czenia.
W przypadku projektów, którymi zarządzanie odbywa się na szczeblu operacyj-
nym, istnieje już koordynacja działań projektowych zarówno w strukturach pro-
jektowych, jak i przedsiębiorstwie, dla którego projekt jest realizowany. Podejście
tego typu wpływa na wzrost pewność zakończenia projektu z sukcesem, jednakże
tylko nieliczne taki sukces osiągają.
W przypadku projektów zarządzanych na szczeblu strategicznym wypracowana
jest już jednolita i specyficzna koncepcja zarządzania, co w konsekwencji przekła-
da się na bardzo duże szanse zakończenia projektu z sukcesem.
W przypadku projektów realizowanych przez firmy, które są zorientowane na pro-
jekty, brak jest tradycyjnych schematów organizacyjnych. Praca realizowana jest
przez zespoły o wysokiej kulturze pracy, a to przekłada się na bardzo wysokie
wskaz
niki powodzenia projektów i wysoki stopień motywacji pracowników.
Dążenie do budowania organizacji zorientowanej na projekty może być kluczową
sprawą dla co najmniej trzech typów przedsiębiorstw i branż, a mianowicie (Pie-
tras, Szmit, 2003):
 przedsiębiorstw generujących dochody przez bezpośrednie wykonywanie pro-
jektów (biura projektowe, firmy tworzące oprogramowanie, firmy doradcze),
 przedsiębiorstw, których codzienna działalność jest w znacznym stopniu deter-
minowana przez realizację złożonych projektów innowacyjnych (przemysł mo-
toryzacyjny, elektrotechniczny, lotniczy, farmaceutyczny),
 wybranych działów zajmujących się badaniami lub rozwojem technologii infor-
macyjnych, będących częścią dużych przedsiębiorstw przemysłowych, usługo-
wych czy finansowych (banki, firmy ubezpieczeniowe).
Działania organizacji zmierzające do orientacji na realizację projektów będą
przekładały się w konsekwencji na określone zmiany organizacyjne. W przedsię-
biorstwie pojawią się osoby, które będą pełnić określone funkcje, a zespoły będą
3
w odpowiedni sposób zarządzane. Więcej szczegółów na temat rodzajów zespo-
łów projektowych i sposobów zarządzania nimi przedstawionych zostanie w dal-
szej części kursu.
1.1. Najczęściej popełniane błędy
Jak powiedziano na wstępie, istnieje kilka obszarów, które są z
ródłem błędów, pro-
wadzących w konsekwencji do upadku całego projektu. Pierwszy z tych obszarów
to obszar samej organizacji projektu. Realizacja projektu często przypomina pospo-
lite ruszenie  zadania nie są jasno zdefiniowane, nie wiadomo, kto jest odpowie-
dzialny za realizację projektu ani jaki jest termin jego zakończenia. Wszystkie te
elementy są dowodem na to, że nie tyle zła jest organizacja projektu, co wręcz jej
nie ma. Taką sytuację często spotyka się w projektach realizowanych ad hoc. Tym-
czasem realizacja projektu powinna być odpowiednio przygotowana, bez względu
na jego wielkość. Projekt powinien mieć odpowiednie struktury organizacyjne.
Dla prawidłowej realizacji projektu powinny  w ramach organizacji, która bę-
dzie go wykonywała  powstać wyodrębnione struktury. Podobnie strona, która
jest zleceniodawcą takiego przedsięwzięcia, również ze swoich struktur powinna
wyodrębnić osoby, które będą związane z projektem. Strony odpowiedzialne za
realizację projektu powinny wytworzyć pewien partnerski układ. Jest to koniecz-
ne, aby dla wszystkich uczestników jasne było, kto jest kim. Potrzeba również, aby
pojawiły się odpowiednie kanały wymiany informacji i podejmowania decyzji, aby
wszyscy uczestnicy projektu, po jego obu stronach, mieli jasno określone zakresy
obowiązków oraz odpowiedzialności.
Kolejne z
ródło zagrożeń dla projektów to zła specyfikacja potrzeb odbiorców. Czę-
sto zdarza się, że realizacja projektu sprowadza się do określenia bardzo ogólnego
tematu czy tytułu. Brak jest jasno określonych wymagań ze strony zleceniodawcy.
Konsekwencje tego stanu są takie, że projekt zostaje rozpoczęty, realizowane są
pierwsze jego elementy, przyszli użytkownicy stwierdzają, że nie o to im chodziło
i prace rozpoczynają się ponownie. Przygotowanie dobrej specyfikacji potrzeb od-
biorców jest kluczowym zadaniem dla grupy przeprowadzającej audyt. Jest to zna-
ny i bardzo często pojawiający się scenariusz. Prawidłowe ustalenie potrzeb odbior-
ców nie jest możliwe przez samodzielne działanie którejkolwiek ze stron projektu
 musi to być praca zbiorowa. Obie strony muszą być tak samo zainteresowane
tym, aby projekt, czy to informatyczny, czy każdy inny, został zrealizowany z suk-
cesem. Konieczne jest, aby każda ze stron wyodrębniła osoby odpowiedzialne za
przygotowanie założeń. Jeśli do opracowania będzie system komputerowy, którego
zadaniem jest kompleksowa obsługa finansowo-księgowa przedsiębiorstwa, każda
ze stron  zarówno zleceniodawca, jaki i wykonawcy  będą używali specyficz-
nego języka, co może przekładać się na niską jakość powstającego oprogramowa-
nia. Konieczne, czy wręcz niezbędne, jest, aby po obydwu stronach były osoby za-
angażowane w projekt, oraz aby posiadały one odpowiednią motywację i wiedzę
merytoryczną. Obie strony w projekcie muszą porozumiewać się tym samym języ-
kiem i dopóki nie będą się nawzajem rozumiały, dopóty projekt będzie właściwie
stał w miejscu.
Kolejny obszar generujący problemy w projektach to złe planowanie. Problemy zwią-
zane ze złym planowaniem projektu są nagminne. Wynika to ze złego podziału za-
dań, braku przypisania zadań do poszczególnych wykonawców, nieustalenia ter-
minów realizacji zadań. Bardzo często po prostu stawia się do realizacji zadanie,
ale nie określa się, kiedy powinno zostać ono wykonane. Jeśli nawet określa się
4
wykonawcę oraz zespół, który będzie je realizował, to już bardzo rzadko dokonu-
je się odbioru wykonanych prac. Efektem takiego działania jest to, że mimo chęci,
jeśli nie wszystkich, to dużej grupy pracowników, powstaje projekt niespełniają-
cy oczekiwań odbiorcy. W takiej sytuacji niezbędne jest wprowadzenie poprawek,
a to powoduje konieczność zmiany harmonogramu realizacji zadań. Prowadzi to
w konsekwencji do tego, że projekt jako całość staje się droższy. Rodzi to niezado-
wolenie wykonawcy oraz odbiorcy. Każda ze stron w jakiejś części będzie musiała
ponieść te dodatkowe, niezaplanowane koszty. Aby eliminować tego typu zagro-
żenia należy po pierwsze ustalić dla każdego zadanie, jakie jest do zrealizowania
w ramach projektu. Po drugie, konieczne jest, aby zespół, który będzie realizował
zadanie składał się z osób kompetentnych, dla których jego realizacja będzie zada-
niem priorytetowym. Wiąże się to ściśle z zagadnieniami związanymi z samą orga-
nizacją projektu i z procesem wyodrębnienia struktur projektowych ze struktur or-
ganizacyjnych przedsiębiorstwa. Po trzecie, konieczne jest, aby wszyscy uczestnicy
projektu, a kierownicy poszczególnych zespołów w szczególności, posiadali pełen
obraz prac, jakie są wykonywane w projekcie. Prezentacja wzajemnych relacji mię-
dzy zadaniami wraz z terminami rozpoczęcia i zakończenia zadań powoduje, że
zespół nabiera przeświadczenia, że od wyników poszczególnych osób zależy praca
innych. Poczucie wzajemnej zależności zespołów prowadzi do tworzenia więzi pro-
jektowej. Niekiedy stwarza to dobre warunki do rywalizacji zespołów między sobą
 w pozytywnym tego słowa znaczeniu. Czwarty element konieczny do wykona-
nia to sprawdzanie realizacji zadań. Nie chodzi o szukanie winnych niedotrzyma-
nia terminów realizacji zadań, a jedynie o przeciwdziałanie takim zjawiskom już
w momencie, kiedy pojawiają się pierwsze negatywne symptomy. Jest to konieczne,
aby projekt zakończył się sukcesem. Często wprowadza się w projektach elementy
raportowania postępu prac, które pozwalają określić, czy prace przebiegają zgod-
nie z założonym harmonogramem. Jeśli pojawiają się jakieś problemy, stosuje się
odpowiednie środki zaradcze. Wykorzystanie czterech wymienionych elementów
w procesie planowania działań może w konsekwencji doprowadzić do pozytywne-
go zakończenia projektu.
Ostatnie z
ródło zagrożeń dla projektów to zły nadzór nad przedsięwzięciem. Zagad-
nieniu nadzoru nad projektem poświęcono nieco uwagi przy okazji omawiania z
ró-
deł związanych ze złym planowaniem. Często w projektach brakuje elementu od-
bioru wyników prac od zespołów realizacyjnych. Zespoły wykonują pracę, ale tak
naprawdę nie wiedzą, jaką część całości ona stanowi. Często spotyka się pogląd, że
ludzie zaangażowani do projektu są odpowiedzialni i nie ma konieczności stosowa-
nia w stosunku do nich nadzoru  nie ma bardziej błędnej tezy. Każdy powinien
być nadzorowany, bez względu na zajmowane stanowisko oraz pełnioną w projek-
cie funkcję. Oczywiście odrębną kwestią jest to, w jaki sposób nadzór ten będzie
zorganizowany. Można wprowadzić elementy samokontroli lub nadzór w postaci
wydzielonych służb, które będą kontrolować cały projekt. Każde rozwiązanie ma
swoje plusy i minusy. W zależności o tego, jaki projekt i w jakich warunkach jest
realizowany, sposoby kontroli mogą być różne. Jedno jest pewne  przyjęte me-
tody muszą być skuteczne. Zaletą dla systemu scentralizowanej kontroli jest posia-
danie obiektywnych ocen na temat pracy wszystkich zespołów oraz szczebli struk-
tury projektowej. System oparty na samokontroli posiada tę zaletę, że uczestnicy
projektu obdarzeni są bardzo dużym zaufaniem. Wybór odpowiedniej struktury
czy też modelu nadzorowania projektu zależy od specyfiki projektu, doświadcze-
nia uczestników oraz decyzji kierownika projektu. Kierownik projektu powinien
podjąć decyzję na temat tego, jak należy nadzorować projekt, gdyż to on odpowia-
da za jego realizację.
5
1.2. y
ródła porażek
Problemy związane z nieukończeniem projektu czy też opóz
nieniami w jego reali-
zacji mogą mieć swój początek w naturze organizacyjnej i przejawiać się:
 tym, że nieprawidłowo dokonano podziału zadań, władzy, kompetencji
 tym , żę wadliwie funkcjonuje w przedsiębiorstwie system przekazywania infor-
macji czy  tak jak zdarza się w wielu przypadkach  po prostu nie ma takiego
systemu;
 tym, że nadmiernie wyizolowano strukturę projektową z macierzystej organi-
zacji, co w konsekwencji prowadzi do tego, że realizatorzy projektu pracują dla
zupełnie nieznanej im firmy;
 walką o wpływy i władzę związaną z tym, że realizacja projektu (informatycz-
nego w szczególności) wiąże się z koniecznością przeprowadzenia dosyć dużych
zmian w schemacie organizacyjnym przedsiębiorstwa. Już na etapie realizacji
projektu dochodzi do walki o to, kto będzie w przyszłości realizował określone
zadania i kto jaką pozycję będzie miał w  nowym przedsiębiorstwie, powsta-
łym po zakończeniu projektu;
 trudnościami w przepływie informacji wynikającymi stąd, że panuje powszech-
ne przeświadczenie, że kto posiada informację, ten posiada władzę. Niewiedza
uczestników projektu na temat postępu prac, na temat tego, w którym miejscu
całego projektu się znajdują, z jakimi problemami się spotykają i jak sobie z nimi
radzą prowadzi do tego, że wszyscy pracują  na wyczucie . Oczekiwania kie-
rownictwa projektu są duże, ale tak naprawdę realizatorzy projektu nie bardzo
wiedzą, co mają robić, aby te oczekiwania zrealizować;
 zbyt precyzyjnymi oczekiwaniami odbiorcy, prowadzącymi do tego, że projekt
staje się zbyt sztywny i nie pasuje do panujących realiów. Projekty są realizowa-
ne w zmieniających się zewnętrznych warunkach prawnych (ustawy, rozporzą-
dzenia itp.) oraz wewnętrznych, wynikających z realizacji projektu (zmiany re-
gulaminów itp.). Niekiedy oczekiwania odbiorcy są zbyt ogólne, a to prowadzi
do tego, że wykonany projekt nie będzie spełniał oczekiwań odbiorcy;
 w procesie planowania, w wyniku którego dokonano zbyt pobieżnego zaplano-
wania prac, jakie są do wykonania. Pobieżne planowanie zwykle sprowadza się
do ustalenia zadań do realizacji, bez wizji tego, jak poszczególne komponenty
całego systemu będą ze sobą współgrać;
 rezygnacją ze sprawdzonych wzorców z zakresu zarządzania projektami. Po-
dejmowane działania mają charakter intuicyjny i nieprzemyślany. Zdarza się,
że w procesie planowania zapomina się o analizie słabych i mocnych punktów
określonych działań, co w konsekwencji prowadzi do problemów na etapie re-
alizacji projektu;
 w zbyt złożonym procesie monitorowania, powodującym, że nakłady ponoszo-
ne na proces kontroli są nieadekwatne do realizowanego projektu. Uczestni-
cy projektu są zmęczeni ciągłymi kontrolami, a mechanizmy raportowania są
zbyt złożone i uciążliwe. Jeśli natomiast mechanizmy kontroli będą zbyt słabe,
w konsekwencji projekt praktycznie będzie poza kontrolą.
1.3. Szczegółowa definicja projektu
1
PMI  Instytut Zarządza-
nia Projektami  najwięk-
Definicja projektu, jaką proponuje Project Management Institute1 jest następują-
sza na świecie organizacja
ca:  Projekt to tymczasowe przedsięwzięcie, mające na celu stworzenie unikalne-
zajmująca się zarządzaniem
go produktu lub usługi, gdzie tymczasowość oznacza, że przedsięwzięcie ma ściśle projektami (www.pmi.org).
6
oznaczony początek i koniec, a unikalność, że produkt lub usługa w wyraz
ny spo-
sób jest inna niż wszystkie podobne produkty lub usługi .
Jak już wcześniej napisano, projekt to dowolne przedsięwzięcie, które posiada na-
stępujące cechy:
 jest zorientowane na cel,
 polega na koordynowanym podejmowaniu powiązanych ze sobą działań,
 ma skończony czas trwania, początek i koniec,
 jest do pewnego stopnia wyjątkowe.
Przytoczona definicja projektu jest dosyć złożona. Wynika to ze złożoności prak-
tycznie każdego projektu, skali tego typu przedsięwzięć, liczby zaangażowanych
w realizację osób oraz kosztów. Złożoność definicji wymaga zatem bliższego omó-
wienia poszczególnych jej elementów.
Każdy projekt jest zorientowany na cel, co oznacza, że jego pomyślna realizacja spo-
woduje osiągnięcie pewnych wymiernych efektów. Cel projektu powinien być bar-
dzo precyzyjnie i jednoznacznie zdefiniowany. To, czy cel jest jednoznaczny moż-
na sprawdzić w ten sposób, że po przedstawieniu go kilku osobom jego sens zosta-
nie jednakowo zinterpretowany przez każdą z nich. Kolejnym niezmiernie ważnym
elementem, o którym często się zapomina, jest realność celu. Niezwykle często pla-
nuje się realizację projektu, a zapomina się o braku wystarczających zasobów, ro-
zumianych bardzo ogólnie  ludzi, niezbędnego sprzętu, funduszy. Istnieje bardzo
dużo przykładów projektów, gdzie w momencie ich uruchomienia sponsor zasta-
nawia się, jak pozyskać odpowiednie, wystarczające fundusze, aby dokonać zakupu
sprzętu niezbędnego do realizacji przedsięwzięcia. Jakże często zdarza się  do-
tyczy to głównie projektów z branży budowlanej  że w momencie uruchomienia
projektu rozpoczynają się negocjacje w sprawie gruntów, na których ma być reali-
zowana inwestycja, czy też jak mają przebiegać kanały teleinformatyczne.
Koordynacja działań wynika ze złożoności przedsięwzięcia, jakim jest projekt. Sto-
pień złożoności zależy od branży, w jakiej projekt jest realizowany oraz zlecenio-
dawcy i wykonawcy projektu. Mnogość zadań do zrealizowania w ramach projek-
tu rodzi konieczność koordynacji działań. Już na etapie planowania należy mieć
świadomość tego, które zadania można realizować równolegle, a które zależą od
innych. Metod i narzędzi, które pomagają w prawidłowym zaplanowaniu, a na-
stępnie koordynacji działań jest wiele. Część z nich zostanie omówiona w dalszej
części kursu. Wybór narzędzia zależy, tak jak wspomniano wcześniej, od specyfiki
projektu oraz stopnia złożoności.
Cechą charakterystyczną wszystkich projektów jest ich tymczasowość. Każdy projekt
posiada względnie jasno określony początek oraz koniec. Użycie pojęcia względnie
jasno określony początek i koniec wynika z faktu, że o ile dość precyzyjnie można
określić początek projektu, o tyle jego koniec zależy od tak dużej liczby czynników
 które nie są znane i na które nie ma wpływu  że trudno jest ten termin określić
precyzyjnie. Dodatkowo, tak naprawdę projekt nie kończy się w momencie przeka-
zania zleceniodawcy gotowego dokumentu projektowego czy też produktu. Rozpo-
czyna się wtedy rzeczywiste dopasowywanie produktu do potrzeb klienta. Element
ten jest niezwykle ważny w przypadku projektów informatycznych.
Każdy projekt jest przedsięwzięciem niepowtarzalnym i jedynym w swoim rodza-
ju, a zatem charakteryzuje się wyjątkowością. Im bardziej wyjątkowy jest projekt,
tym większe jest ryzyko i niepewność, czy zostanie on zrealizowany. Świadomość
tego należy mieć od momentu uruchamiania projektu, a na każdym etapie jego re-
alizacji należy starać się do minimum zmniejszyć ryzyko niepowodzenia. O tym,
w jaki sposób minimalizować ryzyko projektowe, będzie mowa w dalszej części
kursu.
7
1.4. Cykl życia projektu
Bez względu na to, jaki projekt będzie realizowany, będzie można wyróżnić w nim
pewne fazy. W przypadku projektów informatycznych liczba tych faz będzie większa.
Klasycznie wyróżnia się cztery podstawowe fazy projektu:
 Wyobrażenie projektu i planowanie  faza, w której dokonuje się podziału
całego projektu na konkretne zadania, a następnie przypisuje się zadania do
poszczególnych wykonawców. W tej fazie sporządzany jest harmonogram re-
alizacji projektu i definiowany jest budżet. Dla większości projektów w tej fazie
organizowane są struktury projektowe.
 Realizacja  faza, w której wykonywany jest projekt. Polega ona na wykonaniu
wcześniej zaplanowanych zadań w sposób skoordynowany. W trakcie realiza-
cji tej fazy projektu nie można zapomnieć o dwóch dodatkowych elementach
 kontroli i ocenie działań. Kontrola polega na bieżącym sprawdzaniu, czy po-
jawiają się odchylenia od przyjętego planu. Kontrola z reguły sprawowana jest
przez pracowników zespołu projektowego. Ocena  drugi z elementów  wy-
konywana jest po zakończeniu pewnej grupy zadań i z reguły przeprowadzana
jest przez niezależny zespół, na przykład audytorów  niezwiązanych ze zle-
ceniodawcą ani z zespołem projektowym. Niezależność zespołu oceniającego
niezbędna jest do jak najbardziej obiektywnej oceny wykonanej pracy.
 Wdrożenie  faza, w której produkt jest już prawie gotowy. Następuje najtrud-
niejszy etap, kiedy to produkt jest na bieżąco dostosowywany, dopasowywany
do potrzeb końcowego odbiorcy.
 Zakończenie  faza, w której rozwiązuje się struktury projektowe. Część służb,
jakie uczestniczyły w projekcie zamienia się w służby serwisowe stworzonego
produktu. W fazie tej następuje przekazanie całej dokumentacji projektowej zle-
ceniodawcy.
W przypadku projektów informatycznych liczba faz została rozszerzona do sześciu:
 Rozpoznanie potrzeb  faza, w której dochodzi do przeprowadzenia audytu
przedsiębiorstwa i przygotowania np. oferty przetargowej, specyfikacji wyma-
gań.
 Definicja wymagań  wspólna faza życia projektu dla zespołu realizacyjnego
i dla zleceniodawcy. Pracownicy, mając już za sobą fazę wstępnego rozpozna-
wania potrzeb, przystępują do definiowania wymagań dla poszczególnych kom-
ponentów systemu. Wyniki prac posłużą do dokładnego zaplanowania etapów
realizacji, przydziału zadań i określenia harmonogramu.
 Projektowanie systemu  faza, w której dochodzi do przetworzenia zdefinio-
wanych wymagań klienta w produkt. Z reguły w tej fazie powstaje prototyp,
wersja bazowa lub inna wersja testowa oprogramowania. Jest ona przekazywana
odbiorcy, którego zadaniem jest wniesienie korekt do zaproponowanego przez
wykonawcę rozwiązania. W tej fazie odbywają się testy oprogramowania na te-
stowych danych, w testowych środowiskach.
 Wdrożenie  faza, w której  mając już gotowe oprogramowanie  przy-
stępuje się do jego instalacji w rzeczywistych warunkach. Zwykle wdrożenie
ma charakter etapowy. Początkowo wdrażanie odbywa się w kilku wybranych
jednostkach, wydziałach, z czasem rozszerzane jest na wszystkie jednostki.
Fazę wdrożenia często poprzedza się pilotażem nowej wersji oprogramowania.
Wszystkie te zabiegi prowadzi się po to, aby do minimum zmniejszyć ryzyko
niepowodzenia projektu.
 Testowanie  w fazie tej następuje przetestowanie oprogramowania w rze-
czywistych warunkach, pod pełną kontrolą wykonawcy. Bywają takie projek-
ty, w których proces testów odbywa się tylko w środowisku testowym. Jed-
nak oprogramowanie zawsze kiedyś będzie musiało rozpocząć swoje działanie
8
w warunkach rzeczywistej pracy przedsiębiorstwa. Lepiej jest, kiedy odbywa się
to pod okiem wykonawcy, który posiada narzędzia umożliwiające błyskawiczne
usunięcie błędów, które nie zostały wykryte we wcześniejszych fazach.
 Obsługa  ostatnia faza, w której wykonawcy projektu sprawują nadzór serwi-
sowy nad wykonanym oprogramowaniem. Projekt właściwie został zakończony
 gotowy produkt funkcjonuje w przedsiębiorstwie.
9
2. Realizacja projektu
2.1. Decyzja o rozpoczęciu projektu
Podjęcie decyzji o rozpoczęciu projektu jest niezmiernie ważne z uwagi na to, że
wymaga przyjęcia określonych zobowiązań na przyszłość. Jak już wcześniej wspo-
mniano, niezwykle istotnym elementem są zasoby każdej ze stron, które muszą
być przypisane do projektu na czas jego trwania. Zasobami tymi są ludzie, pie-
nią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 eta-
pie przystępowania do realizacji projektu przyjmuje się  jako pewien wyznacznik
jego opłacalności  parametr korzyści utraconych w przypadku niezrealizowania
przedsięwzięcia. Wszystkie tego typu wskaz
niki mają charakteryzować planowane
przedsięwzięcie, określać jego zyskowność oraz realność. W momencie podejmo-
wania decyzji o rozpoczęciu projektu z reguły rozpoczyna się proces rozpoznawa-
nia, a następnie definiowania potrzeb.
2.2. Rozpoznawanie potrzeb
Rozpoznawanie potrzeb końcowego użytkownika musi być procesem wykonywa-
nym świadomie, ponieważ w zależności od tego, jak dobrze zostanie to wykonane,
tak dobry będzie produkt finalny. Poza tym należy pamiętać, że rozpoznanie po-
trzeb użytkownika końcowego nie jest aktem jednorazowym, ale procesem, który
trwa do momentu zakończenia projektu. Dobrze, jeśli w momencie uruchamiania
projektu zostaną stworzone formalne procedury, dzięki którym możliwe będzie
systematyczne rozpoznawanie potrzeb użytkowników. Wiele metodyk zarządza-
nia projektem posiada wbudowane procedury wprowadzania zmian i modyfikacji.
Rozpoznawanie potrzeb jest ściśle związane z prognozowaniem pewnych rozwią-
zań, jakie zostaną przyjęte w rozwiązaniu docelowym.
2.3. Definiowanie potrzeb
Definiowanie potrzeb to kolejny proces, podczas którego dochodzi do określenia
konkretnych wymagań użytkownika końcowego. Po przeprowadzeniu całego sze-
regu rozmów z przyszłymi użytkownikami, wszelkie oczekiwania zostaną zamie-
nione 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 przypadku może okazać się, że wymaga-
nia będą niekompletne i produkt finalny nie będzie spełniał oczekiwań klienta. De-
finiowanie potrzeb powinno odbywać się według schematu zaprezentowanego na
rysunku 1.
10
W momencie, kiedy zostaną zdefiniowane wymagania klienta, można przy-
stąpić do określenia wymagań funkcjonalnych i technicznych. Wymagania
funkcjonalne to nic innego, jak opis funkcji, jakie muszą być realizowane
przez produkt finalny. Na podstawie wymogów funkcjonalnych zostaną sfor-
mułowane wymagania techniczne. Wymagania techniczne bardzo często są
punktem wyjścia dla pracy zespołu projektowego, gdyż są uzupełnieniem
wymagań funkcjonalnych, zgłoszonych przez użytkownika i pozwalają na
ich implementację w konkretnym, zamówionym przez klienta środowisku.
2.4. Planowanie
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:
 struktury podziału pracy,
 wykresy Gantta,
 harmonogramy sieciowe PERT/CPM,
 wykresy alokacji zasobów,
 wykresy odpowiedzialności,
 wykresy rozkładu kosztów skumulowanych,
 diagramy belkowe.
Wszystkie wymienione tu narzędzia mają pomóc kierownikowi zespołu re-
alizacyjnego oraz jego członkom w odpowiednim zaplanowaniu zadań, zde-
finiowaniu czasu niezbędnego do ich wykonania oraz zarezerwowaniu odpo-
wiednich zasobów. Rysunek 1
Schemat definiowania wymagań
Warto omówić kilka z tych narzędzi w celu lepszego zrozumienia ich zalet oraz
użytkownika końcowego
możliwości zastosowania ich w ramach planowania konkretnego projektu.
Struktura podziału pracy to podstawowe i najczęściej wykorzystywane narzędzie
wspomagające fazę planowania projektu. Zbudowana struktura, czyli lista wszyst-
kich jednostkowych zadań, jakie będą do wykonania w ramach projektu jest punk-
tem wyjścia do stworzenia harmonogramu pracy. Na ogół, podczas tworzenia
struktury podziału pracy, stosowana jest metoda przechodzenia od ogółu do szcze-
gółu. W pierwszej kolejności określane są główne grupy zadań do wykonania, a na-
stępnie są one uszczegóławiane, aż do momentu określenia pojedynczych czynno-
ści, które będą mogły zostać przypisane konkretnej osobie. Przykładem może być
podział pracy dla projektu sieci komputerowej, na grupy zadań związanych z:
1) planami i rysunkami,
2) projektem logicznym sieci,
3) urządzeniami aktywnymi,
4) urządzeniami pasywnymi,
5) zabezpieczeniami fizycznymi,
6) zasilaniem awaryjnym,
7) instalacją ppoż. i klimatyzacją,
8) telefonią.
Każdą z tych grup zadań należy rozpisać na bardziej szczegółowe czynności. Licz-
ba poziomów, z których będzie składała się struktura podziału pracy zależy mie-
dzy innymi od wielkości projektu oraz indywidualnych preferencji kierownika.
Przy tego typu podejściu do defragmentacji projektu zaczyna się zarysowywać jego
hierarchiczna struktura oraz łatwiej jest sobie wyobrazić wzajemne zależności po-
11
szczególnych grup zadań oraz kolejność, w jakiej powinny być one wykonane w ce-
lu osiągnięcia sukcesu.
Wykresy Gantta pozwalają na szybkie określenie czasu rozpoczęcia i zakończenia
konkretnego zadania. Narzędzie to również bardzo często wykorzystywane jest do
kontrolowania stopnia realizacji projektu i jego poszczególnych elementów składo-
wych. Na poniższym rysunku przedstawiono przykład wykresu Gantta sporządzo-
nego za pomocą MS Project.
Rysunek 2
Przykład wykresu Gantta
Jak widać na rysunku 2, każde z pięciu wyodrębnionych tu zadań posiada przypi-
saną datę rozpoczęcia i zakończenia, a graficzna prezentacja ułatwia wyobrażenie
sobie, które z zadań będą wykonywane w tym samym czasie, a które z nich będą
tworzyły pewien ciąg, gdzie zakończenie jednego zadania umożliwi przystąpienie
do realizacji kolejnego. Wykresy Gantta należą do najpowszechniej stosowanych
narzędzi, służących do planowania i monitorowania projektów. Wykresy Gantta,
mimo powszechności ich stosowania, posiadają jednak kilka wad. Najczęściej wy-
mieniane jest to, że nie informują one o konsekwencjach zmian terminów realizacji
poszczególnych zadań dla całego projektu. Wykresy Gantta, choć w pewien sposób
łączą zadania i pokazują, jakie są między nimi zależności, to jednak mimo wszyst-
ko traktują je jako do pewnego stopnia mikroprojekty realizowane w ramach du-
żego projektu.
Kolejnym narzędziem są harmonogramy sieciowe PERT/CPM, które zostały stwo-
rzone miedzy innymi w celu wyeliminowania niedostatku informacji na temat
konsekwencji zmian terminów realizacji poszczególnych zadań. Obie z tych metod
(PERT  Program Evaluation and Review Technique oraz CPM  Critical Path
Metod) funkcjonują obecnie jako hybryda PERT/CPM, która wykorzystuje najlep-
sze cechy każdej z nich.
Rysunek 3
Sieć PERT/CPM
Opracowywanie sieci PERT/CPM opiera się na wcześniej przygotowanej struk-
 wykres działań węzłowych
turze podziału pracy projektu. Zadania, jakie zostały przeznaczone do realizacji
w ramach projektu umieszcza się prostokątach w takiej kolejności, w jakiej będą
one realizowane. Linie łączące poszczególne pola pokazują zależności między po-
12
szczególnymi zadaniami. Na poniższym rysunku przedstawiono przykład sieci
PERT/CPM dla zadania polegającego na przygotowaniu kompletu planów budyn-
ków, z naniesioną instalacją energetyczną i siecią logiczną.
Dla każdego z zadań, jakie są do wykonania, ustala się najwcześniejszy i najpóz
niej-
szy moment rozpoczęcie projektu oraz rezerwę czasu. Obrazuje to poniższa tabela.
Zadanie Moment najwcześniejszy Moment najpóz
niejszy Rezerwa
Wykonanie pomiarów 0 0 0
Instalacja oprogramowania 0 3 3
Wykonanie planów 2 5 3
Przekazanie gotowych planów pomieszczeń 15 15 0
Naniesienie instalacji energetycznej 16 18 2
Naniesienie instalacji logicznej 16 16 0
Zebranie planów w spójną całość 18 18 0
Na rysunku 3 pogrubioną linią zaznaczono ścieżkę krytyczną, czyli ścieżkę, której wy-
konanie traw najdłużej. Dla zadań, które położone są na ścieżce krytycznej nie ma re-
zerwy czasowej, a zatem jakiekolwiek opóz
nienia w realizacji zadań na niej położo-
nych odb3
ą się na czasie trwania całego projektu. W taki sposób można zaplanować re-
alizację 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óz
nienia.
Wykresy alokacji zasobów są to wszelkiego rodzaju zestawienia zasobów material-
nych i ludzkich, jakie zostały przypisane do realizacji konkretnych zadań w ramach
projektu. Zestawienia te mogą być elementami składowymi na przykład wykresów
Gantta, gdzie do każdego zadania zostanie przypisany odpowiedzialny za nie czło-
nek zespołu lub mogą zostać stworzone odrębne macierze zasobów. Na poniższym
rysunku przedstawiono przykład przypisania poszczególnych specjalistów do reali-
zacji zadań w ramach projektu.
Zasoby
Specjaliści Specjaliści od Specjaliści
Kierownik od Auto- zagadnień sie- od okablo- Elektrycy Administratorzy
CAD-a ciowych wania
Audyt P S S S
Definiowanie wymagań P S S S
Sporządzenie planów S P
Urządzenia aktywne P S
Urządzenia pasywne S P
Okablowanie P S
Serwery S P
UPS S P
P  funkcja podstawowa
Rysunek 4
S  funkcja pomocnicza
Macierz zasobów przypisanych
do realizacji zadań
13
Zadania
Jak widać na powyż-
szym rysunku, do re-
alizacji poszczególnych
zadań zawsze przypi-
sywane są co najmniej
dwie osoby  jedna
pełniąca funkcje pod-
stawowe i druga, peł-
niąca funkcje pomoc-
nicze. Taki sposób
przypisywania zadań
ma na celu uchronienie
projektu przed opóz
-
nieniami związanymi
na przykład z chorobą
pracownika. Przy two-
rzeniu zestawień alo-
kacji zasobów należy
zwracać uwagę na licz-
bę zadań, jakie zostały
Rysunek 5
przypisane do konkretnej osoby. Jeśli ich liczba będzie zbyt duża, rzeczą naturalną
Krzywe kosztów
okaże się niewykonanie któregoś z nich w zaplanowanym czasie.
skumulowanych
 planowana i rzeczywista
Wykresy rozkładu kosztów skumulowanych. Metoda ta pozwala na zaplanowanie oraz
póz
niejszą kontrolę łącznych wydatków, jakie zostały poniesione w projekcie. Na
poniższym rysunku przedstawiona została krzywa kosztów skumulowanych, zapla-
nowanych i rzeczywiście wydatkowanych w ramach realizacji projektu. Na rysun-
ku 5 pokazane jest również odchylenie budżetu od przyjętego planu.
2.5. Realizacja
Realizacja to faza, podczas której następuje wykonanie wcześniej zaplanowa-
nych i przydzielonych zadań, mających na celu stworzenie produktu spełniającego
oczekiwania i potrzeby użytkownika końcowego. W zależności od rodzaju pro-
jektu, 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
zrealizowania w czasie trwania projektu. W trakcie realizacji projektu pojawiają
się różnego rodzaju zagrożenia, które mogą powodować, że jego realizacja w za-
planowanym czasie lub w ramach zaplanowanego budżetu stanie się niemożliwa.
Należy zatem podejmować różnego rodzaju działania zaradcze, eliminujące lub
minimalizujące to ryzyko. W cały proces realizacji projektu powinny być wbudo-
wane mechanizmy: kontroli oraz wprowadzania zmian i korekt do projektu. Jak
wiadomo, zmiany są o tyle istotne, że z jednej strony zwiększają stopień dopaso-
wania finalnego produktu do oczekiwań klienta, z drugiej jednak burzą przyjęty
harmonogram realizacji prac, a to w konsekwencji może doprowadzić do upadku
projektu. Zabezpieczeniem przed tego typu sytuacją  upadkiem projektu na sku-
tek wprowadzonych zmian  jest sformalizowany mechanizm ich wprowadzania
do projektu. W procesie tym powinien pojawić się element akceptacji przez zle-
ceniodawcę nowych elementów (zmian) projektowych oraz nowych harmonogra-
mów i budżetów.
14
2.6. 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ć odpowiedz
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 projekt należy gromadzić i analizować dane dotyczące
pojawiających się rozbieżności. Zdobyta wiedza pozwoli w porę reagować na od-
chylenia, które przekraczają akceptowalny próg tolerancji. Aby proces kontroli pro-
jektu przebiegał prawidłowo, należy zbudować mechanizm raportowania zdarzeń,
które odbiegają od przyjętego progu akceptacji i nakazać jego stosowanie wszyst-
kim członkom zespołu. Budując mechanizm kontroli w projekcie należy pamiętać
o znalezieniu punktu równowagi między kosztami, jakie będzie za sobą niosła kon-
trola a wynikami pracy. Dla przykładu, jeśli projekt będzie bardzo złożony i reali-
zowany przez wiele osób warto, aby mechanizm ten był rozbudowany. W przypad-
ku projektów o charakterze podobnym do tych, które były realizowane w prze-
szłości, można pozwolić sobie na mniej szczegółowe procedury kontrolne. Proce-
sy 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 reali-
zacji całego zadania.
2.7. Ocena
Jaka jest różnica między oceną a kontrolą, która została opisana wcześniej? Kon-
trola polega na ciągłym nadzorowaniu postępów projektu. Ocena to natomiast
okresowe sprawdzanie sytuacji, jaka istnieje w projekcie. Ocena jest działaniem
bardziej ogólnym  odnoszącym się do całości projektu, podczas gdy kontrola
skupia się na szczegółach. Kontrolą zwykle obejmuje się wybrany obszar projektu,
który interesuje wykonawcę w danej chwili. Oceny z reguły dokonuje grupa nie-
związana bezpośrednio z projektem  ocenia ona cały projekt. Kontrolą zajmuje
się przeważnie grupa wyodrębniona ze struktur projektowych. Za kontrolę projek-
tu odpowiada jego kierownik.
2.8. Zakończenie
Ostatnia faza projektu, o której bardzo często zapomina się podczas realizacji
przedsięwzięć, to zakończenie projektu. Brak realizacji fazy zakończenia wynika
z tego, że interesujące zadania zostały już zrealizowane i członkowie zespołu goto-
wi są do przyjęcia kolejnych zadań w ramach innych projektów. Zakończenie pro-
jektu to szereg prac organizacyjnych. Wiąże się ono ze zgromadzeniem szeregu do-
kumentów  dokumentacji projektowej, dokumentacji użytkownika, materiałów
szkoleniowych, faktur itp. Dokumenty te bezwzględnie muszą zostać gdzieś zar-
chiwizowane. Zespół, który zrealizował zadanie o najwyższym priorytecie zaczyna
15
już przygotowywać się do nowego przedsięwzięcia, ewentualnie część pracowni-
ków wraca do wcześniej wykonywanych zadań. Jest to bardzo niebezpieczna sytu-
acja, gdyż może spowodować, że część dokumentacji ulegnie bezpowrotnej utracie.
Nieprawidłowe zakończenie projektu może spowodować poważne konsekwencje
dla każdej ze stron zaangażowanych w projekt. Zespoły realizacyjne mogą utracić
wiedzę, jaka została zgromadzona w trakcie realizacji projektu. Zdobyte doświad-
czenia  zarówno dobre, jak i złe  można wykorzystać przy kolejnych przedsię-
wzięciach. Dokumentacja projektowa będzie potrzebna w trakcie życia produktu.
Każda zmiana czy modyfikacja w przyszłości  na przykład na wniosek zlecenio-
dawcy  będzie pociągała za sobą konieczność sięgnięcia do materiałów zgroma-
dzonych w archiwum projektu. Konieczne jest takie zorganizowanie tej fazy pro-
jektu, aby po zakończeniu prac zespołów realizacyjnych można było zebrać wszyst-
kie dokumenty i dopiero wtedy dokonać formalnego zakończenia projektu.
16
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 A
ódzkiej, A
ódz
.
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, A
ódz
.
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.
17