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łą specyﬁ-
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.

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 konﬂiktó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 specyﬁczna 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 ﬁrmy, 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
wskaź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, ﬁrmy tworzące oprogramowanie, ﬁrmy 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 ﬁnansowych (banki, ﬁrmy 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ą

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ą ź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 zdeﬁniowane, 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 źródło zagrożeń dla projektów to

zła specyﬁkacja 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 specyﬁkacji 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 ﬁnansowo-księgowa przedsiębiorstwa, każda
ze stron — zarówno zleceniodawca, jaki i wykonawcy — będą używali specyﬁcz-
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ę

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 ź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 ź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 specyﬁki 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ę.

1.2. Źródła porażek

Problemy związane z nieukończeniem projektu czy też opóź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 ﬁrmy;

— 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 deﬁnicja projektu

Deﬁnicja projektu, jaką proponuje Project Management Institute

jest następują-

ca: „Projekt to tymczasowe przedsięwzięcie, mające na celu stworzenie unikalne-
go produktu lub usługi, gdzie tymczasowość oznacza, że przedsięwzięcie ma ściśle

PMI — Instytut Zarządza-

nia Projektami — najwięk-

sza na świecie organizacja

zajmująca się zarządzaniem

projektami (

www.pmi.org

oznaczony początek i koniec, a unikalność, że produkt lub usługa w wyraź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 deﬁnicja 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ść deﬁnicji 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 zdeﬁniowany. 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 specyﬁki
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.

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 deﬁniowany 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, specyﬁkacji wyma-
gań.

— Deﬁnicja 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 deﬁniowania 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 zdeﬁnio-

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

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.

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 wskaź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 deﬁniowania 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 ﬁnalny. 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 modyﬁkacji.
Rozpoznawanie potrzeb jest ściśle związane z prognozowaniem pewnych rozwią-
zań, jakie zostaną przyjęte w rozwiązaniu docelowym.

2.3. Deﬁniowanie potrzeb

Deﬁniowanie 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 ﬁnalny 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 przy-
stąpić do określenia wymagań funkcjonalnych i technicznych. Wymagania
funkcjonalne to nic innego, jak opis funkcji, jakie muszą być realizowane
przez produkt ﬁnalny. 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-
ﬁniowaniu czasu niezbędnego do ich wykonania oraz zarezerwowaniu odpo-
wiednich zasobów.

Warto omówić kilka z tych narzędzi w celu lepszego zrozumienia ich zalet oraz
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 ﬁzycznymi,
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-

Rysunek 1

Schemat deﬁniowania wymagań

użytkownika końcowego

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.

Jak widać na rysunku 2, każde z pięciu wyodrębnionych tu zadań posiada przypi-
saną datę rozpoczęcia i zakończenia, a graﬁczna 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.

Opracowywanie sieci PERT/CPM opiera się na wcześniej przygotowanej struk-
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-

Rysunek 2

Przykład wykresu Gantta

Rysunek 3

Sieć PERT/CPM

— wykres działań węzłowych

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óźniej-
szy moment rozpoczęcie projektu oraz rezerwę czasu. Obrazuje to poniższa tabela.

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 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óźnienia w realizacji zadań na niej położo-
nych odbĳą 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óź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

Kierownik

Specjaliści

od Auto-

CAD-a

Specjaliści od

zagadnień sie-

ciowych

Specjaliści

od okablo-

wania

Elektrycy

Administratorzy

Audyt

Deﬁniowanie wymagań

Sporządzenie planów

Urządzenia aktywne

Urządzenia pasywne

Okablowanie

Serwery

UPS

P — funkcja podstawowa

S — funkcja pomocnicza

Rysunek 4

Macierz zasobów przypisanych

do realizacji zadań

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óź-
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
przypisane do konkretnej osoby. Jeśli ich liczba będzie zbyt duża, rzeczą naturalną
okaże się niewykonanie któregoś z nich w zaplanowanym czasie.

Wykresy rozkładu kosztów skumulowanych.

Metoda ta pozwala na zaplanowanie oraz

póź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 ﬁnalnego 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.

Rysunek 5

Krzywe kosztów
skumulowanych

— planowana i rzeczywista

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ć 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 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

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 modyﬁkacja 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.

Bibliograﬁa

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,

Oﬁcyna 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.

Document Outline

Etapy realizacji projektów

Modul 2 Etapy realizacji projektow

Document Outline