Modul_3.indd

1. Zarządzanie zakresem projektu

Determinantami projektów są zawsze: zakres, czas i koszty. Określa się je zazwy-
czaj jako „magiczny trójkąt” parametrów projektu, co wcale nie oznacza, że w każ-
dym przedsięwzięciu są jednakowo istotne.

Cele, dla których ustanowiono projekt, wyznaczają zakres prac i są odzwiercie-
dleniem zapisanych w kontrakcie oczekiwań użytkownika. Powinny być jasno, bez
ogólnikowych stwierdzeń oraz z należytą starannością (stanowią podstawę deﬁnio-
wania zakresu) ujęte w kontrakcie, aby uniknąć w przyszłości ewentualnych niepo-
rozumień i różnic w interpretacji zapisów. Opis celów projektu powinien uwzględ-
niać określenie korzyści zmian organizacyjnych, zmian w technologii i sprzęcie po
wprowadzeniu projektu.

Podstawą deﬁniowania zakresu przedsięwzięcia są również możliwe do wyspecyﬁ-
kowania na wstępnym etapie prac uwarunkowania i ograniczenia realizacji projek-
tu. Ze względu na ścisły związek zakresu, terminów realizacji i budżetu, uwarun-
kowania czasowe i ﬁnansowe mogą być istotnym utrudnieniem prac i spełnienia
zobowiązań kontraktowych przez kierownika projektu. Ograniczenia mogą wyni-
kać z funkcjonowania ﬁrmy, w której projekt jest realizowany i mieć charakter or-
ganizacyjny lub być pochodną kompetencji i zasobów zespołu wykonawców. Szcze-
gólna innowacyjność projektu może być np. czynnikiem skłaniającym kierownika
projektu do zaplanowania specjalistycznych szkoleń zespołu lub korzystania z wie-
dzy zewnętrznych zasobów — konsultantów. Napięte terminy, gdy np. projekt jest
częścią większej całości lub jest zarządzany w oparciu o datę zakończenia (np. pro-
jekt oddania do użytku systemu informatycznego obsługi wyborów), są trudnym
uwarunkowaniem realizacyjnym, zmuszającym niewątpliwie do mobilizacji, ale
również do pracy w niszczącej nerwy atmosferze. Czynnik kosztów to także czę-
ste uwarunkowanie realizacyjne wpływające na zakres projektu i przyjętą organi-
zację prac.

Bardzo istotna dla precyzyjnego określenia zakresu prac projektowych jest wie-
dza i umiejętności kierownika projektu. Wiedza ta nie może dotyczyć tylko same-
go produktu końcowego. Kierownik powinien zadbać również o płynne, bezkon-
ﬂiktowe zintegrowanie nowego rozwiązania informatycznego z funkcjonowaniem
organizacji. W tym celu kierownik może korzystać z pomocy fachowców z innych
dziedzin, ale przygotowanie użytkownika do stosowania nowej technologii to za-
danie równie ważne, jak zastosowanie najodpowiedniejszych rozwiązań projekto-

Rysunek 1

Powiązania głównych

ograniczeń projektowych

Źródło:

http://biznet.gotdns.org/in-

dex.php?title=Zarz%C4%85dza-
nie_projektem

wych. Zmiana technologiczna wprowadzona przez projekt pociąga za sobą naj-
częściej konieczność przystosowania otoczenia. Działania związane z modyﬁkacją
otoczenia projektu mogą stanowić oddzielny — powiązany z pierwotnym — pro-
jekt lub być jego podprojektem.

Doświadczenia historyczne z realizacji podobnych przedsięwzięć pozwalają rów-
nież precyzyjniej określić zakres prac projektowych. Wskazane jest, aby w przy-
padku kolejnej realizacji twórczo wykorzystać pozytywne doświadczenia poprzed-
nich realizatorów, ale uniknąć ich błędów.

Efektem deﬁnicji zakresu projektu jest hierarchiczna struktura prac. Powinna ona
zawierać wszystkie prace i działania, jakie należy wykonać w ramach projektu. Na-
leży pamiętać o uwzględnieniu w niej czynności kontrolnych i działań związanych
z zarządzaniem projektem.

Hierarchiczny podział prac jest jednym z najważniejszych konceptów stosowanych
przy zarządzaniu projektami. Ustanawia on związek między projektem i jego za-
kresem. Obejmuje wszystkie działania, które należy zrealizować, aby osiągnąć za-
łożone cele projektowe. Działania te tworzą pewną strukturę, która może być róż-
nie przedstawiana np. jako wykres lub tabela obejmująca wszystkie prace — od
głównych do podzadań. Najczęściej wykorzystywana jest metoda

WBS

—

Work

Breakdown Structure

(struktura prac projektowych) — dekompozycji wszystkich

prac w projekcie, pozwalająca na uzyskanie hierarchicznej struktury prac. Pozwa-
la ona na tworzenie wielopoziomowego, dowolnie rozwĳanego planu projektu.
Struktura ta pokazuje, na jakie mniejsze części można podzielić projekt oraz jakie
czynności tworzą pewne nadrzędne zadania.

WBS przedstawia zależności między celami cząstkowymi, pakietami roboczy-
mi i pojedynczymi zadaniami. Pakiet roboczy tworzy grupa zadań jednoznacz-
nie zakończona określonym rezultatem. Może on być przydzielony do wykonaw-
cy lub jednej z jednostek organizacyjnych. Każdy pakiet powinien być zdeﬁniowa-
ny w formie osobnego opisu, który zawiera jasne sformułowanie celu, stanowiące
podstawę działań jego realizatorów. Pakiet jest więc swego rodzaju miniprojektem
w ramach projektu.

Podział strukturalny pracy powinien być przeprowadzony do poziomu umożliwia-
jącego jasne raportowanie dla zarządu lub klientów. Należy dążyć do tego, aby
struktura prac nie była zbyt szczegółowa. W praktyce stosuje się maksymalnie czte-
ry poziomy rozwinięcia, gdyż ich większa liczba uniemożliwia efektywną anali-
zę związków między zadaniami. Dla dużych, złożonych projektów wyodrębnienie
czterech poziomów może się jednak okazać niewystarczające. Stosuje się wówczas
dalsze rozwĳanie elementów na najniższym poziomie, tak aby zachować podział na
kolejne (maksymalnie cztery) poziomy.

Projekt można podzielić na mniejsze jednostki według różnych kryteriów, stąd lo-
gika WBS — odzwierciedlająca koncepcję podejścia do wykonania projektu — za-
leży  od  specyﬁki przedsięwzięcia i od uwarunkowań realizacyjnych. WBS, two-
rzony  w oparciu  o podział  na  realizowane  funkcje,  będzie  miał  inną  postać  niż
w przypadku  prezentacji  zgodnie  z kolejnością  realizacji  prac.  Należy  pamiętać
o konieczności stosowania jednolitego kryterium podziału w ramach tego samego
poziomu struktury.

Nie ma żadnej jednolitej reguły wskazującej, na podstawie jakich kryteriów nale-
ży tworzyć plan struktury projektu. Sposób podejścia do dekompozycji prac usta-
la kierownik projektu, przy czym każdy poziom hierarchicznej struktury może być
rozwĳany według innej koncepcji. Nie powoduje to wcale wyznaczenia innego za-
kresu prac, ale oznacza przyjęcie innego sposobu ich realizacji.

Hierarchiczna struktura prac może być zorientowana na:
1) funkcje — np. podsystem pierwszy obsługujący jedną z funkcji, jednostka funk-

cjonalna druga obsługująca drugą funkcję, podsystem trzeci realizujący kolejną
funkcję,

2) etap realizacji — np. specyﬁkacja wymagań, projektowanie, implementacja, te-

stowanie, wdrożenie,

3) obiekty — np. opracowanie poradnika zarządzania projektami, wybór oprogra-

mowania do zarządzania projektami,

4) organizację — np. badania i rozwój, produkcja, marketing, dystrybucja.

W praktyce, na wyższych szczeblach często występuje struktura obiektowa, a na
niższych etapowo-realizacyjna. Najniższy szczebel struktury tworzą z reguły poje-
dyncze zadania.

Struktura prac może mieć postać listy, gdzie każde zadanie posiada numer, w za-
leżności od poziomu w hierarchii (przykład w tabeli 1).

Numer w WBS

Nazwa zadania

Czas trwania

Rozpoczęcie projektu

0 dni

2 2

Identyﬁkacja i deﬁnicja celu projektu

18 dni

2.1 3

Warsztaty z audytorem zewnętrznym

2 dni

2.1.1 4

Określenie celu projektu i wybór kierownika projektu

1 dzień

2.1.2 5

Określenie dalszej struktury organizacyjnej projektu

1 dzień

2.2 6

Analiza wykonalności przedsięwzięcia

1 tydzień

2.3 7

Analiza opłacalności

2 tygodnie

2.4 8

Sporządzenie wstępnego planu projektu

1 dzień

Podpisane zlecenie projektowe

0 dni

4 10

Opracowanie poradnika zarządzania przedsięwzięciami

47,63 dni

4.1 11

Opracowanie słownika pojęć i terminów

2 tygodnie

4.2 12

Opis organizacji projektowej

1 tydzień

4.3 13

Opis cyklu realizacji projektu

1,5 tygodnia

4.4 14

Metody zarządzania projektem

1 tydzień

4.5 15

Opis systemu przepływu informacji i dokumentacja projektowa

3 tygodnie

4.6 16

Opis zarządzania wieloprojektowego

1 tydzień

4.7 17

Wyznaczenie osoby odpowiedzialnej za aktualizację poradnika

1 godzina

Zatwierdzenie poradnika

0 dni

6 19

Wybór informatycznego systemu do zarządzania projektami

8 dni

6.1 20

Określenie wymagań wobec systemu

2,5 tygodnia

6.2 21

Rynek systemów do zarządzania projektami

8 dni

Jeśli np. dane zadanie byłoby trzecim podzadaniem zadania położonego na dru-
gim poziomie, miałoby numer 2.3. Dodatkowo dla wyróżnienia zadań sumarycz-
nych (posiadających swoje podzadania i zliczających ich czasy trwania) ich nazwy
umieszcza się na liście odmiennym stylem czcionki, np. boldem (jak w tabeli 1).
Nie należy jednak przywiązywać zbyt dużej uwagi do numeru na liście. Przy two-
rzeniu WBS najważniejsza jest kompletność działań, które należy wykonać, aby
osiągnąć cele projektowe, nie analizuje się jeszcze chronologii ich realizacji ani za-
leżności logiczno-czasowych między nimi.

Do przedstawienia poziomu w hierarchii wykorzystuje się również

akapitowanie

i — podobnie jak na listach numerycznych — używa się odmiennego stylu czcionki
dla zadań sumarycznych, najczęściej jest to czcionka pogrubiona (tab. 2). Niezależ-
nie od przyjętego sposobu prezentacji istnieją pewne uniwersalne zasady wydziela-
nia i opisu zaplanowanych prac. Istotne jest, aby rezultatem każdej czynności wy-
odrębnionej w strukturze był

konkretny produkt końcowy

. Nie umieszcza się w struk-

Tabela 1

Zastosowanie listy numerycznej

do przedstawienia poziomów

w hierarchicznym podziale

prac dla fragmentu planu

przykładowego projektu

dotyczącego wprowadzenia

zarządzania przedsięwzięciami

w danej organizacji

turze prac, które nie spełniają tego warunku, chociaż czasami mogą to być długie
i złożone zadania.

Ponadto powinna istnieć możliwość przypisania do każdego zadania w strukturze
przewidzianych zasobów. Dla prac uwzględnionych w strukturze należy określić
czas trwania oraz budżet. Wskazane jest również, aby wydzielone czynności dawa-
ły się łatwo weryﬁkować. WBS zwiększa czytelność prac projektowych i umożliwia
lepsze zrozumienie złożoności projektu. Jest bardzo istotnym elementem, który ma
wpływ na kompletne określenie zakresu oraz obarczenie mniejszym błędem estyma-
cji podstawowych parametrów projektu. Stanowi podstawę wyznaczenia kolejności
zadań do realizacji. Pozwala również na zdeﬁniowanie produktów końcowych, któ-
re powinny być rezultatem każdej wydzielonej czynności. Dzięki WBS istnieje moż-
liwość lepszej koordynacji pracy wykonawców oraz monitorowania i kontroli reali-
zacji zadań. Rozpisanie zakresu projektu w postaci WBS pozwala na wyznaczenie
odpowiedzialności za poszczególne zadania i na lepszą ocenę ryzyka realizacyjne-
go. Ponadto w przypadku systemów informatycznych można twórczo wykorzystać
szkieletowe WBS opracowane we wcześniejszych, podobnych projektach.

WBS powinien uwzględniać wszystkie prace, jakie należy wykonać w ramach pro-
jektu, również czynności kontrolne i działania związane z zarządzaniem projek-
tem. W dużych przedsięwzięciach wydziela się zarządzanie projektem jako samo-
dzielny podprojekt na najwyższym poziomie. Dla mniejszych przedsięwzięć prak-
tykuje się dołączanie do każdego zadania na najniższym poziomie narzutu cza-
su związanego z zarządzaniem projektem. Zarówno pierwszy, jak i drugi sposób
umożliwia uwzględnienie prac obejmujących cały cykl życia projektu, które trudno
zakwaliﬁkować do konkretnego poziomu struktury.

Hierarchiczna struktura wynika z rozwiązań dotyczących organizacji prac nad
projektem. Przyjęcie pewnej koncepcji realizacji wyznacza więc porządek wykona-
nia i kolejność zapisu w strukturze prac.

Dekompozycja prac projektowych pozwala na lepsze oszacowanie kosztów poszcze-
gólnych zadań i w rezultacie całego budżetu. Łatwiej dobrać dla pojedynczych za-
dań najodpowiedniejszą metodę estymacji kosztów — w ten sposób koszty całego
projektu jako suma kosztów zadań są obarczone mniejszym błędem szacunku.

Dzielenie projektu na mniejsze jednostki, których rezultatem są konkretne produkty
końcowe, ułatwia odbiór zadań i pozwala na efektywniejsze śledzenie postępów prac.

Nazwa zadania

Czas trwania

Rozpoczęcie projektu

0 dni

Identyﬁkacja i deﬁnicja celu projektu

18 dni

Warsztaty z audytorem zewnętrznym

2 dni

Określenie celu projektu i wybór kierownika projektu

1 dzień

Określenie dalszej struktury organizacyjnej projektu

1 dzień

Analiza wykonalności przedsięwzięcia

1 tydzień

Analiza opłacalności

2 tygodnie

Sporządzenie wstępnego planu projektu

1 dzień

Podpisane zlecenie projektowe

0 dni

Opracowanie poradnika zarządzania przedsięwzięciami

47,63 dni

Opracowanie słownika pojęć i terminów

2 tygodnie

Opis organizacji projektowej

1 tydzień

Opis cyklu realizacji projektu

1,5 tygodnia

Metody zarządzania projektem

1 tydzień

Opis systemu przepływu informacji i dokumentacja projektowa 3 tygodnie
Opis zarządzania wieloprojektowego

1 tydzień

Wyznaczenie osoby odpowiedzialnej za aktualizację poradnika

1 godzina

Zatwierdzenie poradnika

0 dni

Wybór informatycznego systemu do zarządzania projektami

dni

Określenie wymagań wobec systemu

2,5 tygodnia

Rynek systemów do zarządzania projektami

8 dni

Systematyczne i staranne monitorowanie dużych projektów wymagających zaan-
gażowania wielu wykonawców, o budżecie stanowiącym znaczny procent zasobów
ﬁnansowych danej organizacji, jest skomplikowane. Dzięki WBS istnieje jednak
możliwość śledzenia postępów prac na różnych poziomach szczegółowości i zle-
cania działań kontrolnych kierownikom niższych szczebli. Taka organizacja prac
umożliwia koncentrację na najważniejszych elementach danej fazy projektu.

Kierownik jako osoba odpowiedzialna za postęp prac w całym projekcie nie powi-
nien wnikać w szczegóły konkretnych zadań, ale przydzielać prace wyodrębnione
za pomocą WBS innym członkom zespołu projektowego. W ten sposób przekazuje
wykonawcom odpowiedzialność i określa ich kompetencje przy realizacji zadań.

Dzięki stworzeniu listy zadań o określonej kolejności realizacji i przypisaniu do
prac ich wykonawców można szybciej, zwłaszcza w dużych projektach, uzyskać in-
formacje o ewentualnym pokrywaniu się zadań realizowanych przez tych samych
ludzi lub sprzęt oraz zorientować się w konﬂiktach terminów, np. rezerwacji nie-
zbędnych pomieszczeń w tym samym czasie. Hierarchiczny podział prac wpływa
więc również na efektywniejszą alokację zasobów i lepszą koordynację prac.

Dekompozycja projektu na poszczególne zadania i przydzielenie odpowiednich
wykonawców umożliwia również lepszą ocenę ryzyka realizacji projektu. Ryzyko
całego projektu jest określane na podstawie identyﬁkacji źródeł zagrożenia realiza-
cji poszczególnych zadań. Wyodrębnione prace mają mniejszy obszar oddziaływa-
nia i pozwalają na precyzyjniejszą analizę warunków ich wykonania.

Nigdy nie zdarza się, że każdy nowy projekt jest realizowany w takich samych wa-
runkach, technologii, organizacji, przez ciągle tego samego kierownika. Można
więc spróbować stworzyć pewne rozwiązania uniwersalne i dla konkretnego pro-
jektu uwzględnić jego charakterystyczne szczegóły i uwarunkowania realizacyjne,
np. można wyróżnić kilkanaście kategorii systemów informatycznych, które są do
siebie zbliżone. Bazowanie na standardowym, szkieletowym rozwiązaniu poprawia

Tabela 2

Zastosowanie akapitowania

dla przedstawienia poziomów

w hierarchicznej strukturze

prac dla fragmentu planu

przykładowego projektu

jakość prac przez skrócenie czasu planowania oraz zmniejsza ryzyko błędnego osza-
cowania parametrów projektu. W przypadku systemów informatycznych wykorzy-
stuje się systemy szkieletowe, zapewniające realizację określonych funkcji, ale nie-
zawierające szczegółowych algorytmów obliczeniowych czy też przetwarzania da-
nych. Podejście takie pozwala wykorzystać dotychczasowe rozwiązania i doskonalić
ramowe modele w kolejnych zastosowaniach. Jest wykorzystywane w tzw. zstępują-
cej (top-down) metodzie szacowania czasów trwania zadań. W metodzie tej zwykle
nie bierze się pod uwagę poziomu umiejętności konkretnych wykonawców.

Na hierarchicznej liście zadań zazwyczaj uwzględniany jest czas trwania prac, zaso-
by potrzebne do ich realizacji i inne dane. Metoda wstępująca (bottom-up) wyko-
rzystuje te dodatkowe informacje oraz — przez oszacowanie czasów trwania każ-
dej czynności na najniższym poziomie i ich zsumowanie — umożliwia wyznaczenie
czasu realizacji całości przedsięwzięcia lub jego większych etapów. Metoda ta wy-
maga użycia bardzo szczegółowego podziału prac i minimalizuje ryzyko pominię-
cia któregoś z zadań. Stwarza jednak poczucie złudnego bezpieczeństwa, opartego
na myleniu szczegółowości z dokładnością.

Na podstawie listy zadań składających się na projekt można także budować wiele
innych przydatnych tabel, jak np. macierz — tabelę odpowiedzialności zasobów za
wyodrębnione prace — Responsibility Matrix (przykład w tabeli 3).

Opracowanie hierarchicznej struktury zadań wymaga należytej staranności i od-
powiedniej szczegółowości, jest ona bowiem podstawowym elementem planu pro-
jektu.

Kto\Co

2.1.1

2.1.2

2.2

2.3

2.4

...

sponsor

—

kierownik
projektu

—

konsultant
zewnętrzny

—

...

—

członek
zespołu
projektowego

—

Tabela 3

Macierz odpowiedzialności dla

fragmentu numerycznej listy

zadań do realizacji (numery

zadań dotyczą prac ujętych

w tabeli 2)

O — odpowiedzialny, D — dora-

dzający, W — współpracownik,
n — zadanie n-te.

2. Zarządzanie czasem projektu

— budowanie harmonogramu

Czas jest podstawowym parametrem, który podlega zarządzaniu w projekcie za
pomocą odpowiednich metod i technik.

Data ukończenia projektu zapisana jest w kontrakcie i z jej dotrzymania rozliczany
jest kierownik przedsięwzięcia. Wyznaczenie terminu realizacji projektu jest ele-
mentem fazy planowania, a najprostszą techniką wyliczania daty zakończenia jest
harmonogramowanie. Jest to pojęcie węższe niż planowanie. Harmonogram odpo-
wiada na pytania:
1) jakie prace należy wykonać, aby osiągnąć cele projektowe?
2) jaki jest szacowany czas trwania zadań wyodrębnionych w hierarchicznej struk-

turze prac?

3) jakimi relacjami są połączone zadania w projekcie?
4) w jaki sposób zadania są umieszczone w kalendarzu projektu?

Z planu użytkownik dowiaduje się dodatkowo, kto jest realizatorem poszczegól-
nych prac projektowych i za pomocą jakich narzędzi, metod i technik wykonuje
swoje zadania.

Harmonogramowanie najczęściej ma na celu wyznaczenie daty zakończenia pro-
jektu oraz określenie terminu rozpoczęcia i zakończenia każdego z zadań.

Harmonogramowaniem (tab. 4) jako narzędziem planistycznym można posługiwać
się jednak w przypadku projektów o prostej, przejrzystej strukturze oraz nieskom-
plikowanych relacjach między zadaniami.

Nazwa zadania

Dzień

początkowy

Czas trwania

(dni)

Dzień

końcowy

Osoba

odpowiedzialna

Prace zmierzające do podpisania zlecenia
projektowego

2-01-2002

17-01-2002

—

Tworzenie i obsada zespołu projektowego

18-01-2002

23-01-2002

—

Spotkanie otwierające projekt

18-01-2002

—

Przygotowanie sesji otwierającej projekt

18-01-2002

24-01-2002

—

Sesja otwierająca projekt

25-01-2002

—

Prace nad planem struktury projektu

28-01-2002

29-01-2002

—

Opracowanie WBS projektu

30-01-2002

6-02-2002

—

Oszacowanie nakładów

30-01-2002

4-02-2002

—

Optymalizacja planu

7-02-2002

18-02-2002

—

10 Analiza ryzyka

30-01-2002

12-02-2002

—

11 Opracowanie budżetu ryzyka

13-02-2002

14-02-2002

—

12 Zatwierdzenie planu

19-02-2002

—

Tworząc plan, należy określić dni robocze i godziny pracy dla całego projektu, dla
grup i dla pojedynczych zasobów. W tym celu wykorzystuje się kalendarze. Dla
każdego projektu trzeba ustalić jego unikatowy kalendarz efektywnych prac. Ka-
lendarze uwzględniające specyﬁkę danego przedsięwzięcia mogą np. wskazywać
dni wolne od pracy lub dni robocze inne niż ogólnie przyjęte.

Tabela 4

Harmonogram dla fragmentu

projektu

Wyróżnia się dwa typy kalendarzy:
1) bazowe, które stosuje się do wyznaczenia dni roboczych i godzin pracy oraz dni

świątecznych dla całego projektu lub dla grup zasobów (np. pracowników zmia-
nowych),

2) zasobów, które zawierają — oprócz ustaleń tych samych, co w kalendarzu ba-

zowym — dodatkowe informacje o urlopach, godzinach nadliczbowych, pracy
zmianowej czy specyﬁcznej dostępności indywidualnego zasobu.

Problemów planistycznych mogą przysparzać prace, w których konieczna jest do-
stępność kilku zasobów o różniących się, indywidualnych kalendarzach. Propozy-
cją rozwiązania takich sytuacji jest stosowanie kalendarzy względnych, w których
określany jest maksymalny czas pracy danego zasobu w tygodniu, bez wyszczegól-
niania konkretnych godzin od–do w ramach dnia roboczego.

Szacowanie czasu trwania poszczególnych zadań, a w związku z tym wyznacza-
nie terminu zakończenia prac projektowych dokonywane jest jednak w oderwaniu
od konkretnego kalendarza realizacji przedsięwzięcia. Oznacza to, że czas trwa-
nia pojedynczego zadania czy całego projektu nie przekłada się automatycznie na
konkretne daty kalendarzowe, określające termin realizacji. Pracochłonność prac
projektowych oblicza się w jednostkach typu roboczogodzina, roboczodzień, robo-
czotydzień czy roboczomiesiąc, pozwalających określić, ile pracy należy wykonać,
aby zrealizować dane zadanie. Termin zakończenia zadania — a w efekcie całego
projektu — zależy więc nie tylko od konkretnego układu kalendarza realizacji za-
dania, ale również od przyjętej technologii i organizacji wykonania prac oraz od
ilości przydzielonych zasobów.

Układając harmonogram, należy brać pod uwagę zależność czasu trwania wykona-
nia zadania od przydzielonych zasobów.

Ponadto w pracy zespołowej kierownik projektu musi liczyć się ze stratami efek-
tywnego czasu pracy na komunikację wewnętrzną. W skrajnych przypadkach zbyt
duże zespoły wykonawców mogą cały czas przeznaczać na dokonywanie uzgod-
nień. W takiej sytuacji zwiększanie liczebności zespołu może od pewnego momen-
tu wydłużyć czas realizacji zadania.

2.1. Wykres Gantta i metody sieciowe

Literatura przedmiotu wymienia wiele metod i narzędzi zarządzania czasem. Czę-
sto używaną w praktyce techniką jest

wykres Gantta

. Czasowi trwania zadania od-

powiada tu długość słupka, a podziałkę na skali czasu dostosowuje się do założone-
go poziomu szczegółowości harmonogramowania (rys. 2). Dodatkowo, gdy zazna-
czy się na osi czasu linię daty bieżącej, uzyskuje się czytelny obraz zadań ukończo-
nych, w trakcie realizacji i do wykonania w przyszłości. Można również uwzględ-
nić w nich zadania węzłowe z zerowym czasem trwania, tzw. kamienie milowe, po-
zwalające zyskać rozeznanie co do kluczowych dat w realizacji przedsięwzięcia.

Wykresy słupkowe Gantta są wyjątkowo wygodną, jasną i przejrzystą techniką pre-
zentacji planu projektu. Wywodzą się z Ameryki, gdzie wykorzystano je do przed-
stawienia prac nisko wykwaliﬁkowanych robotników, często analfabetów lub ob-
cokrajowców, zatrudnionych przy budowie kolei oraz w górnictwie. Plany takie
wywieszano w ogólnie dostępnym miejscu tak, aby robotnicy mogli szybko odna-
leźć kolorowy słupek zadań swojego zespołu i wiedzieli, gdzie i jakiego dnia mieli
zgłosić się do pracy.

a z

s t

ia z

ia w d

h (

1 k

a — 1 d

eń)

1. P

ce z

ąc

e d

o p

a z

a p

2. T

e i o

a z

łu p

3. S

ie o

ją

ce p

4. P

ie s

ji o

ją

j p

5. S

ja o

ją

ca p

6. P

ce n

ad p

m s

ry p

7. O

ie W

BS p

Rysunek 2

Wykres Gantta dla fragmentu projektu wraz z zaznaczon

kolorem czar

nym

ście

żk

ytyczn

Innymi technikami harmonogramowania są

metody sieciowe

, które wywodzą się

ze Stanów Zjednoczonych, gdzie w trakcie realizacji dużych projektów niezbędne
było zarządzanie wieloma powiązanymi zadaniami, a tradycyjne uchwycenie zależ-
ności między nimi okazało się niemożliwe.

Formalnymi elementami planów sieciowych są węzły i strzałki. Węzeł jest punktem
połączeń, a strzałka ukierunkowanym połączeniem między dwoma węzłami.

Za pomocą formalnych elementów można przedstawić elementy strukturalne, któ-
rymi są zadania, zdarzenia i zależności.

Przez zadania należy rozumieć pracę lub grupę prac, dającą w efekcie określony
produkt końcowy, posiadającą zdeﬁniowany początek i koniec. Zadanie jest iden-
tyﬁkowane za pomocą nazwy, np. Opracowanie specyﬁkacji wymagań użytkowni-
ka. Z realizacją zadania wiąże się zużycie zasobów.

Zdarzenie to stan uzyskania określonego rezultatu, niewymagający zużycia za-
sobów. Każde zadanie zaczyna się i kończy określonym zdarzeniem. Dla zadania
Opracowanie specyﬁkacji wymagań użytkownika zdarzeniem początkowym będzie
na przykład pobranie odpowiedniego formularza, a zdarzeniem kończącym prze-
kazanie formularza specyﬁkacji kierownikowi projektu.

Sieć to z kolei kombinacja zadań połączonych strzałkami, które określają relacje lo-
giczne lub logiczno-czasowe między działaniami. Przyporządkowania logiczno-cza-
sowe to takie, które uwzględniają dodatkowo odstęp czasowy między zadaniami.

Modele sieciowe oraz wykresy słupkowe Gantta powinny być dobierane jako gra-
ﬁczne narzędzia planowania przebiegu prac w zależności od wielkości projektów.
W małych i nieskomplikowanych przedsięwzięciach warto posługiwać się diagra-
mem belkowym lub harmonogramem. Dla projektów o bardziej złożonej struktu-
rze odpowiedniejszy jest wykres Gantta lub proste plany sieciowe. Duże i złożone
projekty wymagają planowania z wykorzystaniem technik sieciowych i wykresów
słupkowych.

2.2 Metody ścieżki krytycznej

Każda sieć zadań ma swój początek i koniec. Z kolei zadania połączone relacjami
tworzą ścieżki. Biegną one od pierwszego do ostatniego zadania w sieci.

Podstawą wyznaczania tzw. ścieżki krytycznej są zależności — relacje między za-
daniami. Ścieżka krytyczna jest nieprzerwanym ciągiem zadań, od początku do
końca sieci, o łącznym najdłuższym czasie trwania. Wszystkie zadania położone na
tej ścieżce są krytyczne, ponieważ od terminowości ich realizacji zależy data ukoń-
czenia projektu.

Po raz pierwszy metodę ścieżki krytycznej — Critical Path Method — zastosował
zespół z koncernu Du Pont, kierowany przez Kelley’a i Walkera, przy upraszcza-
niu skomplikowanych remontów instalacji. Opracowano wówczas nowy sposób
prezentacji planu, nazwany grafem zamkniętym skierowanym. Nowa metoda po-
zwoliła na wyznaczenie najwcześniejszego możliwego terminu zakończenia przed-
sięwzięcia. Dzięki CPM kierownictwo mogło również uzyskać informacje o zada-
niach rzeczywiście istotnych dla zakończenia całego projektu w terminie oraz do-
wiedziało się, ile najmniej trzeba dopłacić, aby termin ten przyspieszyć. Firmy bu-
dowlane z powodzeniem zastosowały nową metodę — jako rekordowy przykład
możliwości przyspieszenia budowy podaje się dom z San Diego z 1992 r. Przez

mniej niż trzy godziny budował go zespół liczący 350 osób. Prace planistyczne przy
tej budowie trwały sześć miesięcy.

Chcąc prawidłowo wyznaczyć ścieżkę krytyczną, należy podzielić przedsięwzięcie
na zadania, właściwie określić relacje logiczne i logiczno-czasowe między działa-
niami oraz dysponować trafnymi oszacowaniami przewidywanych czasów trwa-
nia poszczególnych operacji. Do znalezienia ścieżki krytycznej przyjmuje się deter-
ministyczny czas trwania poszczególnych operacji, oszacowany zgodnie z przyjętą
strategią realizacji projektu i przydzielonymi zasobami.

Na podstawie średniego czasu trwania poszczególnych operacji oblicza się następ-
nie całkowite i swobodne zapasy czasu dla zadań.

Całkowity zapas czasu

(Total Slack)

to ilość czasu, o który może opóźnić się zadanie, nie opóźniając całego projektu.

Jeżeli zadanie nie ma całkowitego zapasu czasu — wynosi on zero — to jest nazy-
wane zadaniem krytycznym i jego przedłużenie wydłuży całe przedsięwzięcie.

Natomiast

swobodny zapas czasu

to okres, o który można opóźnić zadanie, nie po-

wodując opóźnienia żadnego zadania będącego jego następnikiem.

Dla niewielkich projektów ścieżkę krytyczną można szybko odnaleźć na wykresie
Gantta (patrz rys. 2). W przypadku dużych projektów diagramy belkowe są jednak
mało czytelne — ścieżkę krytyczną można wówczas łatwiej wyznaczyć na planach
sieciowych, stosując specjalny algorytm. Najczęściej wykorzystuje się tutaj przyczy-
nowo-skutkowy model sieci, w którym każde zadanie i jego parametry wpisywane
są w prostokąty, a strzałki określają typ relacji logicznych lub logiczno-czasowych
między zadaniami.

Algorytm wyznaczania ścieżki krytycznej przebiega w dwóch etapach. W ramach
pierwszego etapu graf jest przeglądany „w przód”, zaczynając od pierwszego zada-
nia w sieci i obliczane są najwcześniejsze możliwe terminy rozpoczęcia i zakończe-
nia poszczególnych działań. Przyjmuje się jako równy 1 najwcześniejszy termin roz-
poczęcia zadania pierwszego. Przy obliczaniu najwcześniejszego terminu rozpoczę-
cia pozostałych zadań należy uwzględniać relacje między pracami i wzory:

najwcześniejsze rozpoczęcie

= największa z wartości

najwcześniejsze zakończenie poprzednika + 1

najwcześniejsze zakończenie

= najwcześniejsze rozpoczęcie + czas trwania – 1

Termin najwcześniejszego zakończenia zadania nie jest jedynie sumą najwcześniej-
szego rozpoczęcia i czasu trwania. Rozpoczęcie należy bowiem przyjmować jako
początek danej jednostki, a zakończenie jako koniec jednostki. Oznacza to, że za-
dania trwające jeden dzień roboczy rozpoczynają się na początku dnia pracy (np.
o godz. 8.00) i kończą tego samego dnia (np. o 16.00 przy ośmiogodzinnym dniu
pracy).

W drugim  etapie  obliczeń  przeglądamy  graf  „od  końca”,  przy  czym  podstawę
obliczeń  stanowi  czas  zakończenia  przedsięwzięcia.  Jest  on  równy  wyliczonemu
w pierwszym  etapie  najwcześniejszemu  czasowi  zakończenia  ostatniego  zadania
w sieci. Stanowi również najpóźniejszy możliwy czas jego zakończenia. Dla termi-
nów najpóźniejszych zachodzą równości:

najpóźniejsze rozpoczęcie

= najpóźniejsze zakończenie – czas trwania + 1

najpóźniejsze zakończenie

= najmniejsza z wartości

najpóźniejsze rozpoczęcie następnika – 1

Uzyskane w dwóch etapach wyniki pozwalają na obliczenie zapasów czasu. Zada-
nia, dla których całkowity zapas czasu jest równy zero, będą tworzyły ścieżkę kry-

tyczną. Zamiennie zapasy czasu określane są jako luzy czasowe i wyznaczane we-
dług wzorów:

całkowity zapas czasu

= najpóźniejsze rozpoczęcie – najwcześniejsze rozpoczęcie

swobodny zapas czasu

= minimum z wartości

najwcześniejsze rozpoczęcie następnika – najwcześniejsze zakończenie – 1

CPM ma na celu skrócenie całego przedsięwzięcia przez doinwestowanie operacji
krytycznych. Jest bardzo wygodnym narzędziem dla kierownika projektu, dzięki
któremu — w zależności od przyjętej strategii i taktyki prowadzenia przedsięwzię-
cia — może on odnaleźć:
1) najkrótszy możliwy czas realizacji projektu,
2) najmniejszy koszt przedsięwzięcia przy zachowaniu pierwotnego czasu realizacji,
3) minimalny koszt skrócenia realizacji projektu do założonego czasu.

Kierownik wyznaczy najkrótszy możliwy czas realizacji przedsięwzięcia, znajdu-
jąc długość ścieżki krytycznej przy maksymalnym doinwestowaniu wszystkich jej
operacji. To doinwestowanie może polegać np. na zatrudnieniu dodatkowych lu-
dzi, zwiększeniu liczby dni pracy, zakupie gotowych rozwiązań czy też przyspiesze-
niu dostaw. Chcąc maksymalnie skrócić czas realizacji przedsięwzięcia, kierownik
może dodatkowo zmienić szeregowe zadania na ścieżce krytycznej w równoległe
i skracać zadania najwcześniejsze, najdłuższe i najłatwiejsze. Zyski wynikające ze
skrócenia czasu realizacji przedsięwzięcia przez skrócenie czasu wykonania ope-
racji krytycznych muszą być większe od poniesionych nakładów. Związane są np.
z uzyskaniem znacznie lepszej ceny sprzedaży produktu lub wyprzedzeniem kon-
kurencji i zdobyciem większej części rynku.

Najmniejszy koszt przedsięwzięcia z zachowaniem pierwotnego czasu realizacji to
koszt po obniżeniu nakładów i wydłużeniu czasu realizacji tych zadań, które po-
siadają zapasy czasu. W pierwszej kolejności kierownik powinien wziąć pod uwagę
zadania, których wydłużenie spowoduje największy spadek kosztów.

Kierownik obliczy minimalny koszt skrócenia realizacji przedsięwzięcia do zadane-
go czasu, skracając czas wykonania na ścieżce krytycznej tych operacji, których przy-
spieszenie jest najmniej kosztowne. Skrócenie czasu wykonania zadania może dopro-
wadzić do zmiany ścieżki krytycznej i konieczności jej ponownego wyznaczenia.

O ile informacje o relacjach logicznych między zadaniami i niezbędnych zasobach
nie są trudne do uzyskania dla kierownika projektu informatycznego, o tyle okre-
ślenie czasu niezbędnego do wykonania poszczególnych prac, zwłaszcza twórczych
(np. analiza wymagań użytkownika, projektowanie systemu), może być kłopotli-
we i obarczone dużym błędem. Dodatkowo metoda ścieżki krytycznej zakłada ko-
nieczność posiadania informacji o zależnościach czasu trwania zadań od ponie-
sionych nakładów, a wyznaczenie takiej zależności w różnych przedsięwzięciach
może być bardzo trudne.

2.3. Zarządzanie czasem za pomocą metody PERT

W metodzie PERT (Program Evaluation and Review Technique), będącej modyﬁ-
kacją metody ścieżki krytycznej, przyjmuje się, że zakończenie zadania zależy od
prawdopodobieństwa. Czas trwania każdego zadania określają tu trzy estymaty:
pesymistyczna T

, optymistyczna T

i najbardziej prawdopodobna T

. Na ich pod-

stawie wyliczany jest średni czas trwania zadania T

śr

, który wykorzystuje się do

znalezienia ścieżki krytycznej.

Rozkład prawdopodobieństwa terminu zakończenia można opisać teoretyczną
krzywą Gaussa — dzwonową. Jest to tzw. rozkład normalny.

W praktyce okazuje się jednak, że dla zadań — zwłaszcza w przedsięwzięciach in-
westycyjnych — rozkład ten nie jest symetryczny, lecz pochylony. Jest to właśnie
przyjęty w metodzie PERT rozkład β.

W latach pięćdziesiątych XX wieku w US Navy, przy budowie rakiety Polaris, wy-
liczono przybliżoną medianę (punkt odpowiadający prawdopodobieństwu 50%)
dla rozkładu β, posługując się uproszczonym rozkładem trójkątnym (rys. 3).

śr

jest średnią ważoną wymienionych trzech estymat, dla których arbitralnie do-

biera się wagi tak, aby ich suma nie była większa niż 6:

śr

Dla projektów o dużej liczbie etapów przyjmuje się następnie, korzystając z tzw.
centralnego twierdzenia granicznego, że rozkład prawdopodobieństwa czasu trwa-
nia całego przedsięwzięcia jest rozkładem normalnym i oblicza się jego parametry
na podstawie danych dotyczących poszczególnych zadań. Wyznaczone parametry
rozkładu prawdopodobieństwa całego projektu mogą posłużyć do obliczenia np.
prawdopodobieństwa przekroczenia konkretnego terminu zakończenia prac.

Praktyczne wykorzystanie w przedsięwzięciach trzech terminów: T

, T

śr

, T

— wy-

znaczanych za pomocą metody PERT — jest ograniczone. W zleceniu projektowym
wpisuje się tylko jeden termin realizacji projektu. Jest to najczęściej termin średni
wykorzystywany w metodzie CPM.

2.4. Zarządzanie czasem

za pomocą metody łańcucha krytycznego

W 1991 r. Eliahu Goldratt opracował nową metodę i nazwał ją

metodą łańcucha

krytycznego.

Po raz pierwszy zastosowano ją dla Harris Corporation przy budowie

nowej fabryki produkującej mikroelektronikę w Massachusetts. Zarząd zatwier-
dził realizację budowy w 27 miesięcy. Zespół odpowiedzialny za budowę opraco-
wał według metody Goldratta nowy harmonogram, przewidując 18 miesięcy dla
tej inwestycji. Budowę zakończono sukcesem w 13 miesięcy, mimo że przedsię-
wzięcia tej skali i tego typu trwają średnio 28–30 miesięcy.

Rysunek 3

Wyliczenie mediany w oparciu

o rozkład trójkątny

Metoda łańcucha krytycznego bierze za podstawę plan sieciowy i ścieżkę krytycz-
ną, a dodatkowo zawiera elementy psychologii organizacji.

Przyjmuje się tutaj, że rozkład prawdopodobieństwa czasów trwania zadań jest
typu β. Goldratt zauważył, że w wielu przypadkach podawany przez wykonawcę
zadania termin realizacji jest zbliżony do terminu pesymistycznego i leży daleko
poza terminem przeciętnym i poza medianą, gdzieś pod koniec krzywej β. Podanie
przez wykonawcę terminu zawierającego 85–90% bezpieczeństwa (utożsamiane-
go z prawdopodobieństwem) to jednak dwukrotne wydłużenie terminu względem
mediany.

Następnym ﬁlarem metody Goldratta jest zachęcanie wykonawców i pracowników
do dobrowolnego zmniejszania planowanych okresów realizacji swoich zadań. Jest
to najtrudniejszy element tej metody, ale możliwy do realizacji przez motywowanie
całego zespołu do osiągnięcia celu. W USA stosuje się w takich przypadkach np.
motywowanie akcjami ﬁrmy.

Kierownik projektu i członkowie jego zespołu muszą jednak wcześniej negocjo-
wać kryteria swojej nagrody za odniesienie wspólnego sukcesu. W takim układzie
członkowie zespołu projektowego chętnie pomagają sobie nawzajem, aby w efekcie
indywidualnie uzyskać nagrodę za osiągnięcie wspólnego celu.

Stosując odmienny mechanizm motywacji, trudno jest uzyskać wymagany poziom
współpracy potrzebny do realizacji projektu w jak najkrótszym czasie, do czego
dąży się w metodzie łańcucha krytycznego. Odgórne narzucenie norm przez kie-
rownika projektu spotka się najpewniej z oporem ze strony zespołu.

Trzecim ﬁlarem tej metody jest koncentracja kierownictwa na rzeczach najważniej-
szych. W efekcie oznacza to w tych przedsięwzięciach, w których najbardziej zależy
na czasie, przywrócenie pierwszorzędnej wagi ścieżce krytycznej. Nie należy jednak
poprzesuwać w planach zadania na najpóźniejsze możliwe terminy. Uzyskałoby się
wtedy plan złożony z samych ścieżek krytycznych. W takim planie nie ma mowy
o koncentracji na ścieżce krytycznej, ponieważ wszystkie zadania są krytyczne i na
pewno nie zostanie dotrzymany planowany termin zakończenia projektu.

W metodzie łańcucha krytycznego bezpieczeństwo jest zapewniane nie dla poje-
dynczych zadań, lecz dla całych ścieżek zadań, przede wszystkim dla ścieżki kry-
tycznej. Plan to — w uproszczeniu — dobrowolnie poskracane przez członków ze-
społu czasy zadań z dodanymi buforami bezpieczeństwa.

Po skróceniu czasów trwania zadań i dodaniu głównego bufora bezpieczeństwa
na końcu ścieżki krytycznej należy uzyskać czas realizacji całego przedsięwzięcia
krótszy niż przed zastosowaniem metody Goldratta. Bufor powinien odzwiercie-
dlać sumę ryzyka na ścieżce. Przeciętnie bufor to około 1/4 ścieżki. Przy małym
ryzyku, dysponując np. sprawdzonymi wykonawcami lub technologią, bufor może
stanowić kilka procent całej ścieżki. Duże ryzyko powinno obligować kierownika
projektu do utrzymywania bufora wynoszącego 50% i więcej estymowanego cza-
su trwania ścieżki.

Dojście do ścieżki krytycznej należy również zabezpieczyć buforami chroniącymi
tę ścieżkę tak, aby zadania niekrytyczne nie spowodowały opóźnienia przedsię-
wzięcia (rys. 4). Od tego momentu kierownik projektu zarządza skróconą czasowo
siecią PERT, ale z dodatkowymi buforami.

2.5. Punkty węzłowe i analiza ich trendu w planie projektu

Do potrzeb efektywniejszego planowania wyróżnia się zadania szczególnie istotne
dla realizacji projektu. Czynności te oznaczają wykonanie pewnej ważnej fazy prac
projektowych i nazywane są punktami węzłowymi projektu lub kamieniami milo-
wymi (milestones).

Wynik i końcowy termin pakietu roboczego zwykle stanowią kamień milowy pro-
jektu. Wskazane jest jednak, aby zakończenie tylko rzeczywiście przełomowych
pakietów było traktowane jako kamienie milowe.

Punkt węzłowy musi dotyczyć konkretnego, pojedynczego rezultatu — produktu,
który jest istotny dla całości projektu i powinien być łatwy do identyﬁkacji.

Kamienie milowe stanowią miejsca kontroli przewidzianych w ramach projektu.
Śledzenie trendu punktów węzłowych pozwala kierownikowi reagować na odchy-
lenia od planowanego postępu prac. Jest to instrument kontroli wewnętrznej wy-
magający niewielkich nakładów.

Chcąc analizować trend kamieni milowych, należy na trójkącie prostokątnym, na
osi pionowej odkładać planowane terminy punktów węzłowych, a na osi poziomej
nanosić terminy raportowania, czyli te, w których będzie aktualizowany stan pro-
jektu. Jednostki na obu osiach muszą obejmować ten sam okres. Wymagane jest ich
wyskalowanie, np. w dniach, cyklach dwutygodniowych, miesiącach lub kwarta-
łach (rys. 5 uwzględnia skalę miesięczną).

Rysunek 4

Ścieżka krytyczna projektu

zabezpieczona buforami

czasu w metodzie łańcucha

krytycznego

Warunkiem  stosowania  TKM  jest  posiadanie  realistycznego  planu  terminowego
i hierarchicznego, zorientowanego na wyniki podziału prac. Przy czym zarządowi
przedsiębiorstwa  przedstawiany  jest  tylko  najwyższy  poziom  struktury,  podczas
gdy bardziej szczegółowe informacje dotyczące kamieni milowych otrzymują kie-
rownicy podprojektów. Ponadto, ponieważ szacunki określające osiągane terminy
są z natury rzeczy subiektywne, istotne jest, aby kierownik projektu zadbał o taką
atmosferę pracy, w której przyznawanie się do błędów nie byłoby karane. W przy-
padku  nierealistycznego  planowania  lub  opóźnień  w informowaniu  o przesunię-
ciach terminów

będą powstawały krzywe przedstawione na rysunku 6 (w odnie-

sieniu dla kamienia milowego drugiego).

W sytuacji, gdy osoby odpowiedzialne za osiągnięcie danego kamienia milowe-
go podają diametralnie sprzeczne informacje lub plan jest nierealistyczny, krzywe
TKM mają wygląd jak na rysunku 6 (rozważana sytuacja dotyczy kamienia milo-
wego drugiego). Stosując TKM, należy również pamiętać, że zapewnia on wizu-
alizację, ale nie jest narzędziem do badania przyczyn opóźnień w realizacji projek-
tu. TKM koncentruje się na komunikacji między osobą przeprowadzającą kontrolę
terminowości a osobą odpowiedzialną za osiągnięcie poszczególnych zadań węzło-
wych projektu.

Można również przeprowadzać tzw. analizę trendu zasobów — ATZ. Na osi pio-
nowej odkładane są wówczas nakłady (np. w osobodniach czy osobomiesiącach)
niezbędne do osiągnięcia poszczególnych kamieni milowych.

Rysunek 6

Krzywe TKM przy sprzecznych

oszacowaniach lub błędach

w planowaniu dla kamienia

milowego drugiego

W takich przypadkach

otrzymywany jest przebieg

oszacowań przy zastoso-

waniu tzw. taktyki salami,

w której prawda ujawnia-

na jest tylko „w plaster-

kach”.

3. Zarządzanie budżetem projektu

3.1. Składniki budżetu projektu

Budżet całego przedsięwzięcia jest sumą budżetów wszystkich zadań wyróżnionych
w hierarchicznej strukturze prac, czyli w WBS.

Kierownik projektu, dysponując określoną kwotą przyznaną mu przez sponsora na
realizację prac projektowych, powinien ją przede wszystkim podzielić na

budżety

zadań

. Kwota ta jest zapisana w kontrakcie, a za osiągnięcie celów projektu w jej ra-

mach odpowiedzialny jest kierownik.

Nie znając jeszcze docelowych wykonawców zadań, kierownik przeznacza czę-
ści kwoty, którą dysponuje, na poszczególne zadania, w zależności od czasów ich
trwania. Gdy wiedza kierownika na temat tego, jakie zasoby będą realizatorami
konkretnych prac zwiększa się, może on przystąpić do kalkulacji budżetów zadań
z wykorzystaniem jednej z trzech metod:
1) kalkulacji sterowanej zasobami,
2) kalkulacji ze stałym czasem trwania zadania,
3) kalkulacji z niezmiennymi łącznymi nakładami pracy na zadanie.

Budżet pojedynczego zadania może mieć maksymalnie trzy składowe:
1) koszty stałe zadania,
2) koszty stałe generowane przez konkretny zasób,
3) koszty zmienne pracy zasobów.

Składowa 2. i 3. tworzą łącznie koszty zmienne zadania.

Budżetem pojedynczego zadania może być również jedna z trzech powyższych
składowych lub też suma dowolnych dwóch spośród nich.

Składowe budżetu pojedynczego zadania przedstawia rysunek 7.

W sytuacji, gdy powstały koszty, a nie mamy zasobów, którym moglibyśmy je przy-
dzielić, należy zakwaliﬁkować je jako

koszty stałe zadania

. Załóżmy, że dla realizacji

Rysunek 7

Składowe budżetu

pojedynczego zadania

przykładowego zadania Wyłonienie kierownika projektu sponsor przewidział opi-
saną koncepcję. Miał trzech kandydatów na kierownika projektu. Zdecydował, że
wyjedzie z nimi na weekend do ośrodka wypoczynkowego i po dwóch dniach po-
dejmie ostateczną decyzję, kto zostanie kierownikiem przedsięwzięcia. Za okres
pobytu w ośrodku czterech osób (sponsor i trzech kandydatów na kierownika pro-
jektu) narósł koszt (np. noclegów i wyżywienia). Komu przydzielić te koszty? Naj-
lepiej, gdyby pokrył je sponsor, ale gdy ma on odmienną koncepcję, należy postąpić
inaczej. Na pewno nie byłoby sprawiedliwe, gdyby obciążyć nimi ludzi, którzy od-
padli w konkursie na kierownika. Z drugiej strony, dlaczego koszty czterech osób
miałyby obciążyć tylko jednego — docelowego kierownika projektu? Najrozsąd-
niej takich kosztów nie przydzielać zasobom, ale uznać je za koszty stałe zadania
polegającego na wyłonieniu i wyborze kierownika projektu.

Natomiast

koszty zmienne

mogą dzielić się na koszty zmienne pracy zasobu i koszty

stałe generowane przez konkretny zasób.

Koszty zmienne pracy zasobu

to koszty, które powstają jako wynik pracy zasobów

w określonym czasie za zadeklarowaną stawkę. Na przykład, jeśli kierownik prze-
pracował przy danym zadaniu jeden dzień (ośmiogodzinny) w oparciu o stawkę za-
deklarowaną w arkuszu zasobów (dla projektu jest to np. stawka 400,00 zł/godz.),
to powstał koszt 3200,00 zł (8 godz. · 400,00 zł/godz.).

Koszty stałe generowane przez zasób

są narzędziem często wykorzystywanym przez

kierowników projektów dla utrzymania budżetu zadania, i w efekcie całego pro-
jektu, w ramach kwoty przyznanej przez sponsora.

Dla wyjaśnienia mechanizmu funkcjonowania kosztów stałych generowanych
przez zasób załóżmy, że przykładowe zadanie Oszacowanie wartości zidentyﬁko-
wanych ryzyk projektowych, za wykonanie którego odpowiedzialny jest kierownik
projektu, trwa jeden dzień roboczy. Gdyby kierownik sam wykonał zadanie, wów-
czas powstałby koszt zmienny jego pracy w kwocie 3200,00 zł (8 godz. · 400 zł/
godz.). Kierownik wie jednak, że na realizację tego zadania może przeznaczyć jedy-
nie 2000,00 zł, ponieważ w przeciwnym razie nie utrzyma zadania i całego przed-
sięwzięcia w ramach budżetu przewidzianego w kontrakcie projektu. Postępowa-
nie kierownika projektu może być wówczas następujące:
1) uzna on, że omawiane zadanie będzie wykonywał wspólnie z jedną osobą z ze-

społu projektowego, która zna się na szacowaniu zagrożeń projektowych i pra-
cuje w oparciu o stawkę 50,00 zł/godz.,

2) praca jednej osoby z zespołu projektowego przez jeden dzień spowoduje powsta-

nie kosztu zmiennego 400,00 zł (8 godz. · 50,00 zł/godz.).,

3) pozostałą do wykorzystania kwotę 1600,00 zł (2000,00 zł – 400,00 zł) kierow-

nik zakwaliﬁkuje jako koszty stałe swojej pracy.

W przypadku kosztów stałych generowanych przez zasób zawsze należy korzystać z me-
tody kalkulacji budżetu ze stałym czasem trwania zadania

, gdyż są sytuacje przy kalku-

lowaniu kosztów prac projektowych, gdy przydzielanie kolejnych zasobów jako re-
alizatorów nie skraca czasu trwania zadania i na odwrót. Załóżmy, że przykładowe
zadanie polega na przewiezieniu samochodem z Łodzi do Szczyrku sprzętu kompu-
terowego i wykładowcy na organizowane tam szkolenie. Samochód jadący z bez-
pieczną prędkością nie przejedzie trasy Łódź–Szczyrk szybciej niż w 2,5 godziny.
Fakt, że kierownik projektu może przydzielić kolejnego kierowcę i samochód nie
ma wpływu na skrócenie czasu realizacji zadania, ponieważ jest to niemożliwe.

4. Zarządzanie jakością

Zarządzanie jakością to proces, który ma za zadanie stałe kontrolowanie postępu
prac oraz poprawności i kompletności wszystkich rezultatów.

Proces zarządzania jakością nabiera w projektach coraz częściej dużego znaczenia
ze względu na fakt, że zleceniodawca — przy bardzo dużej konkurencji na rynku
wśród ﬁrm realizujących projekty — oczekuje, że produkt, który zamówił będzie
najwyższej jakości.

W związku z realizacją procesu zarządzania jakością konieczne jest wykonanie
przez zespół projektowy pięciu procesów podrzędnych, które przebiegają w kolej-
nych fazach projektu. Są to:
1) zdeﬁniowanie strategii, standardów i procedur zarządzania,
2) przegląd jakościowy,
3) audyt jakościowy,
4) pomiar jakościowy,
5) ocena jakości.

W ramach

deﬁniowania strategii, standardów i procedur zarządzania

należy sformuło-

wać lub uaktualnić plany deﬁniujące sposób, w jaki procesy obszaru zarządzania
jakością będą wspomagać realizację zakresu, celów i podejścia do projektu.

Część standardów może zostać zdeﬁniowana podczas formułowania planu jakości,
ale mimo to będą musiały powstawać dodatkowe standardy zarządzania jakością
w miarę postępu prac związanych z realizacją projektu. Niniejszy podproces umoż-
liwia progresywne formułowanie i aktualizację standardów i procedur zarządzania
jakością wraz z postępem prac w ramach projektu.

Dokumentacja bazowa powinna obejmować:
1) zakres, cele i podejście — dokument ten służy do sformułowania fundamentu

strategii, standardów i procedur zarządzania jakością,

2) politykę zarządzania jakością — w której należy przeanalizować znaczące ele-

menty polityki konsultingowej, dotyczące zarządzania jakością, w celu określe-
nia jej oddziaływania na projekt; klient może kierować się własną polityką za-
rządzania jakością

oraz opcjonalnie:
3) plan jakości.

W trakcie

przeglądu jakościowego

przeprowadzane są przeglądy produktów mają-

ce na celu upewnienie się, że spełniają one przyjęte standardy i potrzeby projektu.
Sprawdzane jest, czy są one pełne, prawidłowe, spójne i zwięzłe.

Przeglądy jakościowe należy przeprowadzać podczas realizacji projektu zgodnie
z założeniami przyjętymi w planie jakości. Do każdego z przeglądów należy przy-
gotować arkusz uwag z przeglądu.

Dokumentacja bazowa powinna obejmować:
1) plan jakości — zawierający strategie zarządzania jakością,
2) procedurę przeglądu jakościowego — określającą sposób realizacji podrzędnego

procesu przeglądu jakościowego.

W ramach

audytu jakościowego

przeprowadzane są audyty projektu mające na celu

dokonanie oceny stopnia jego realizacji w stosunku do przyjętego planu oraz jego

zgodności ze standardami i procedurami. Celem niniejszego procesu jest potwier-
dzenie, że procedury zostały zdeﬁniowane, są wdrażane i właściwe z punktu wi-
dzenia projektu.

Audyty jakościowe należy przeprowadzać przez cały czas realizacji projektu, zgod-
nie z założeniami planu jakości. Przed przeprowadzeniem kolejnych audytów na-
leży przygotować i uzupełnić raporty z poprzednich badań oraz formularze zakre-
su działań, w celu zdeﬁniowania kwestii spornych wymagających uwagi. Kwestie
sporne rozwiązywane są albo w ramach struktur zespołu projektowego, albo są
przenoszone na wyższy stopień zarządzania — do grupy doradczej.

Dokumentacja bazowa powinna obejmować:
1) procedurę audytu jakościowego — określającą sposób realizacji podrzędnego

procesu audytu jakościowego,

2) plan jakości — deﬁniujący wymagania dotyczące audytów jakościowych.

W przypadku

pomiaru jakościowego

następuje kalkulacja kosztów, czasu oraz ocena

jakości, mająca na celu usprawnienie zarządzania procesem realizacji całego pro-
jektu oraz wdrożenia udoskonaleń w miarę postępujących prac.

Konkretne pomiary mogą być związane na przykład z problemami napotkanymi
podczas testowania na każdym z poziomów realizacji projektu, zagrożeniami oraz
kwestiami spornymi (rozstrzygniętymi lub nie) z konkretnego okresu. Proces obej-
muje prowadzenie zapisów dotyczących czasochłonności realizacji konkretnego za-
dania w porównaniu z przyjętymi szacunkami. Propozycja aktualizacji elementów
objętych pomiarem może być następnie przekazana stronie odpowiedzialnej za do-
konywanie rekalkulacji szacunków.

Dokumentacja bazowa powinna obejmować:
1) procedurę pomiaru jakościowego — określającą sposób realizacji podrzędnego

procesu pomiaru jakościowego,

2) plan jakości — określający strategię dotyczącą pomiarów jakościowych.

W ramach

przeprowadzania oceny jakości

następuje przeprowadzenie oceny komplet-

ności przyjętych elementów kontroli jakości (przeglądy, audyty, testy) oraz podję-
cie decyzji mających na celu rozwiązanie problemów, które służą bieżącej ocenie
zakończenia projektu.

Ocena jakościowa może być przeprowadzona przez członka zespołu projektowe-
go (odpowiadającego za inne zadania związane z zagadnieniami jakości) lub przez
konsultanta ds. jakości, niewchodzącego w skład zespołu, działającego w pewnym
sensie niezależnie. Wynikiem realizacji tego podprocesu jest dokument (produkt)
Raport jakościowy.

Dokumentacja bazowa powinna obejmować:
1) plan jakości — deﬁniujący wymagania względem oceny jakości,
2) formularz zakresu działań oraz raporty z audytów — stanowiące dowód kom-

pletności działań związanych z kontrolą jakości projektu,

3) dziennik problemów oraz uwagi do przeglądów — w których odnotowywane są

wszelkie sporne kwestie oraz wskazana jest liczba nierozwiązanych spraw doty-
czących jakości produktów projektu w momencie przeprowadzania oceny.

5. Zarządzanie ryzykiem projektowym

5.1. Źródła i czynniki ryzyka

Na potrzeby kursu

ryzykiem

będziemy nazywać potencjalne, niepożądane zdarze-

nie, którego zaistnienie może doprowadzić do tego, że cele projektu nie zostaną
osiągnięte lub nastąpią istotne zakłócenia w realizacji prac projektowych.

W literaturze przedmiotu wymienia się następujące źródła ryzyka:
1) wewnętrzne, czyli spowodowane przez specyﬁczne cechy projektu,
2) narzucone, czyli związane z uwarunkowaniami realizacyjnymi: technologiczny-

mi, kosztowymi czy też harmonogramem wykonania prac,

3) wprowadzone, czyli wynikające z niedostatecznej wiedzy lub zaniedbań kierow-

nika projektu czy też osób przez niego upoważnionych.

Niezależnie od źródeł ryzyka należy nim zarządzać i jest to jeden z obszarów od-
powiedzialności kierownika projektu. Powinien on stworzyć system zarządzania
ryzykiem, umożliwiający jego ocenę i podejmowanie odpowiednich działań zapo-
biegawczych.

Zarządzając ryzykiem, należy pamiętać o pewnej zależności — ryzyko zawsze idzie
w parze z zyskiem. Wzrost jednej wielkości wywołuje zwiększenie drugiej. Podej-
mowanie zbyt ryzykownych decyzji może być tak niebezpieczne dla projektu, że
dalsza jego kontynuacja będzie mniej opłacalna niż jego wstrzymanie.

Czynniki ryzyka mogą być różne, ale wszystkie zidentyﬁkowane czynniki należy
poddać ocenie i podjąć właściwe działania zaradcze. Czynnikiem ryzyka może być
na przykład niewłaściwa ocena sytuacji początkowej. W fazie identyﬁkacji projek-
tu należy realnie i rzetelnie ocenić stan początkowy, umiejętności wykonawców
i uwarunkowania realizacyjne. Tymczasem realność oceny może być zniekształco-
na ze względu na początkowe bardzo optymistyczne nastawienie realizatorów i de-
cydentów. Emocje nieznajdujące wytłumaczenia w wynikach oceny stanu począt-
kowego nie powinny być przesłanką zbyt ryzykownych decyzji ani ignorowania za-
uważonych zagrożeń.

Czynnikiem ryzyka przy nadzwyczaj szybkich zmianach w otoczeniu projektu jest
również długi harmonogram działań, skłaniający do słabego tempa prac począt-
kowych. W projektach z długim harmonogramem po powolnym starcie następuje
spiętrzenie prac, w wyniku którego jakość działań może ulec obniżeniu i mogą po-
jawić się problemy realizacyjne.

Korzystanie z usług wykonawców zewnętrznych, mimo że pozwala na lepszą orga-
nizację prac i optymalne wykorzystanie zasobów, stwarza zagrożenia ze względu
na brak bezpośredniego nadzoru nad realizacją zleconych zadań. Poza tym w przy-
padku usług podwykonawców zewnętrznych nawet bardzo rzetelne planowanie
może okazać się mało skuteczne w przypadku poślizgu czasowego w dostawach
czy ich złej jakości.

Czynniki ryzyka i ich natężenie zmieniają się wraz z realizacją działań projektowych.
Bardzo ważne jest prawidłowe i staranne przygotowanie działań projektowych od
strony merytorycznej i organizacyjno-prawnej. Szczególnie w kontrakcie, ale rów-
nież w planach, należy unikać nieformalnych zapisów i dwuznacznych sformułowań.

Przy formułowaniu kontraktu zalecane jest korzystanie z zasady używania liczebni-
ków zamiast przymiotników — w tych miejscach, gdzie jest to możliwe.

Podczas realizacji projektu mogą wystąpić czynniki ryzyka określane jako tzw. siły
wyższe, na które ani decydenci, ani realizatorzy nie mają wpływu. Do tej grupy
czynników zalicza się wszelkiego rodzaju katastrofy wynikające z nieprzewidywal-
nych zjawisk, ale również niewypełnianie zobowiązań przez uczestników projektu
i złą jakość wykonywanej przez nich pracy.

5.2. System zarządzania ryzykiem

5.2.1. Identyﬁkacja obszarów ryzyka projektowego

Za budowę formalnego systemu zarządzania ryzykiem odpowiedzialny jest kie-
rownik projektu. Graﬁczny schemat budowy sugerowanego systemu zarządzania
ryzykiem przedstawiony jest na rysunku 8. W modelu tym
zakłada się cykliczne powtarzanie działań odbywających się
w obrębie bloków: identyﬁkacji, analizy, zapobiegania i mo-
nitorowania.

Identyﬁkację zagrożeń należy przeprowadzać cyklicznie, ale
najcenniejsze jest wstępne określenie zagrożeń. Odbywa się
ono zaraz po ustanowieniu projektu, między innymi jako
wynik odpowiedzi na pytania:
1) jakie cele mają zostać osiągnięte przez ustanowienie i re-

alizację projektu?

2) w jakiej sferze działalności konkretnej organizacji ma być

wprowadzona zmiana jako rezultat prac projektowych?

3) co konkretnie należy wykonać?
4) jaki jest zakres przeprowadzanej zmiany?
5) kiedy chcemy zakończyć realizację projektu?
6) kto jest wykonawcą prac projektowych?
7) czy w organizacji istnieją już jakieś wzorce i doświadcze-

nia w realizacji przedsięwzięć?

8) do jakiej kategorii projektów należy aktualnie rozważany

projekt (czy do życiowo istotnych dla ﬁrmy, czy po pro-
stu modnych)?

W zależności od celów i kategorii projektu inne będzie po-
dejście do identyﬁkowania zagrożeń i inne priorytety będą
nadawane konkretnym, rozpoznanym, negatywnym zda-
rzeniom. Inaczej będzie również analizowane ryzyko w róż-
nych fazach realizacji projektu.

W fazie identyﬁkacji podstawą analiz powinny być zagrożenia celów biznesowych
stawianych przed projektem. Należy uwzględnić zagrożenia:
1) decydujące o powodzeniu przedsięwzięcia — na przykład cena projektu; cena

oszacowana „dla wygrania klienta” może skutkować problemami w fazie reali-
zacji podczas wykonywania prac przy bardzo ograniczonych środkach; z kolei
zbyt wysoka cena może nie zostać zaakceptowana przez klienta lub spowoduje
trudności z płatnościami ze strony klienta, a to może zakończyć się niepowodze-
niem całego projektu;

Rysunek 8

System zarządzania

ryzykiem projektowym

2) powiązane z zaspokojeniem wymagań i rzeczywistych potrzeb klienta — nieod-

powiednie przygotowanie klienta, zmieniające się cele czy brak kadry potraﬁą-
cej korzystać z przygotowywanego systemu może doprowadzić do ﬁaska całe-
go przedsięwzięcia; analiza zachowania i stanu przygotowania klienta (zwłasz-
cza użytkownika końcowego) do akceptacji wprowadzanej zmiany jest istotnym
czynnikiem ryzyka;

3) uwzględniające uzyskanie oczekiwanego zysku — nie tylko ﬁnansowego, ale

przede wszystkim polegającego na zdobyciu mocniejszej pozycji na rynku, rów-
nież zdobyciu większego doświadczenia; przy czym, identyﬁkując tutaj obszary
ryzyka, należy brać pod uwagę różne cele poszczególnych uczestników procesu
projektowego.

Wymagania klienta są najczęściej zamieszczone w kontrakcie na projekt i powinny
być obowiązujące dla kierownika projektu. Jako obszar ryzyka związany z podpi-
sanym kontraktem należy identyﬁkować zmiany oczekiwań klienta w trakcie prac
projektowych, wpływające na parametry projektu. Typ kontraktu zawartego mię-
dzy uczestnikami procesu projektowego również może stanowić obszar ryzyka. Dla
kontraktów ze stałą ceną za wykonanie działań projektowych zagrożeniem dla pro-
jektu może być niechęć wykonawcy do ponoszenia dodatkowych kosztów związa-
nych z modyﬁkacjami zwiększającymi użyteczność projektu. W przypadku kontrak-
tów zawierających klauzulę płatności za wykonane prace ryzyko będzie stanowić ce-
lowe wydłużanie prac, bez względu na to, czy cele zostały osiągnięte, czy też nie.
Niektóre typy kontraktów mogą dodatkowo skutkować przydzielaniem do realizacji
prac niewystarczających zasobów lub udostępnianiem zasobów złej jakości.

Zagrożenia są przede wszystkim identyﬁkowane podczas specjalnie organizowa-
nych sesji identyﬁkacji ryzyka. Sesje te to formalne spotkania czy warsztaty, na któ-
rych uczestnicy przedsięwzięcia określają obszary potencjalnego ryzyka. Dla iden-
tyﬁkacji potencjalnych zagrożeń korzysta się z różnych narzędzi, metod i technik,
jak na przykład listy kontrolne czy spotkania, w trakcie których stosuje się tech-
nikę burzy mózgów. Powstają one w wyniku doświadczeń zgromadzonych pod-
czas realizacji wcześniejszych projektów i umożliwiają porównanie wcześniej zi-
dentyﬁkowanych obszarów ryzyka z warunkami realizacji konkretnego projektu.
Listy kontrolnej, z której się aktualnie korzysta, nie należy nigdy traktować jako
zamkniętej i kompletnej, ponieważ zawsze w rozważanym projekcie mogą wystą-
pić nowe, niezidentyﬁkowane dotychczas zagrożenia.

Sesje identyﬁkacji ryzyka powinny mieć charakter formalny, a ich uczestnikami po-
winni być: kierownik projektu, specjaliści techniczni i wszyscy inni istotni uczest-
nicy projektu oraz wszystkie osoby, których pomoc jest wskazana przy rozpozna-
waniu obszarów zagrożeń dla projektu. Jako wynik ustaleń podjętych podczas sesji
identyﬁkacji ryzyka powinien powstać formalny raport, w którym oprócz rozpo-
znanych źródeł i czynników ryzyka należy wskazać osoby odpowiedzialne za okre-
ślone ryzyko. Wstępnie powinny być również określone priorytety i oceny w rapor-
cie zidentyﬁkowanych zagrożeń.

W przypadku, gdy sesja identyﬁkacji ryzyka ma postać spotkania z moderatorem
i stosuje się na nim technikę burzy mózgów, należy zadbać o podsumowanie dys-
kusji przez wydanie końcowej oceny analizowanej sytuacji budzącej obawy. Zada-
niem moderatora w trakcie takich spotkań jest zbieranie zgłoszeń o sytuacjach ne-
gatywnych dla projektu, rozważanie ich i podsumowanie dyskusji.

Etap identyﬁkacji ryzyka jest bardzo ważny dla sukcesu projektu, ponieważ umoż-
liwia określenie przedmiotu analizy zagrożeń odbywającej się w kolejnym bloku
działań w ramach systemu zarządzania ryzykiem.

5.2.2. Etap analizy ryzyka projektowego

W drugim bloku działań, w systemie zarządzania ryzykiem projektowym, ocenia się
prawdopodobieństwo wystąpienia zagrożenia oraz szacuje wysokość potencjalnych
strat. Analiza ryzyka powinna być wielowariantowa, tj. prowadzona dla całego pro-
jektu, dla poszczególnych obszarów i zadań projektowych. Łączne ryzyko dla całego
projektu należy oszacować na podstawie ocen pojedynczych zagrożeń i ich wzajem-
nych relacji przyczynowo-skutkowych. Przy interpretacji zagrożeń wymagane jest
zawsze uwzględnianie uwarunkowań realizacyjnych rozważanego projektu.

Ryzyko oceniane jest na podstawie typu realizowanego projektu i wagi, jaką do
projektu przywiązuje klient. Niekiedy kierownik projektu jest nakłaniany przez
klienta do podejmowania dużego ryzyka, ale zawsze kierownik powinien przewi-
dzieć następstwa ryzykownych działań przed ich podjęciem i w sposób formalny
informować o niebezpiecznych konsekwencjach.

Ryzyko może być szacowane na podstawie:
1) hierarchicznej struktury prac (WBS),
2) harmonogramów uwzględniających alokację zasobów,
3) wiedzy i doświadczenia kierownika projektu,
4) zgromadzonych danych historycznych z realizacji wcześniejszych przedsię-

wzięć,

5) innych opracowań wykonanych na potrzeby przeprowadzenia działań projek-

towych.

W zależności od wagi wpływu danego ryzyka dla projektu jako całości stosuje się
różne miary dla szacowanego zagrożenia. Ryzyko może być szacowane według ska-
li trzystopniowej:
1) wysokie,
2) średnie,
3) niskie.

Spotyka się również pięciostopniową skalę ryzyka, gdzie skala trzystopniowa roz-
szerzana jest dodatkowo o grupę zagrożeń bardzo wysokich i bardzo niskich.

W przypadku ryzyka, które jest wysoce priorytetowe dla rozważanego projektu,
określane są dokładne wskaźniki wyrażone jako prawdopodobieństwo wystąpienia
danego negatywnego zdarzenia.

Podczas oceny ryzyka należy być świadomym względności oceny negatywnych zja-
wisk, mogących zakłócić planowany porządek prac projektowych. Niektóre indy-
widualne, ryzykowne zdarzenia mogą mieć bowiem pozytywny wpływ na realiza-
cję projektu jako całości.

Na kompleksową ocenę ryzyka powinny składać się dwa elementy:
1) ocena prawdopodobieństwa wystąpienia negatywnego zjawiska,
2) wysokość potencjalnych strat związanych z wystąpieniem niepożądanego zda-

rzenia.

Jedną ze stosowanych metod oceny ryzyka jest analiza przyczyn, skutków i wagi
błędów (Failure Mode, Effect and Criticality Analysis — FMECA). Wykorzystanie
tej analizy do zarządzania projektem ma na celu zidentyﬁkowanie i wyeliminowa-
nie przyczyn błędów w odniesieniu do projektu, który traktuje się jako produkt,
lub do samego procesu projektowania.

Kolejną metodą oceny ryzyka jest analiza wrażliwości projektu na zakłócenia. Inną
metodą jest badanie przebiegu projektu przy rozmaitych prawdopodobnych scena-
riuszach.

W opracowaniach dotyczących oceny ryzyka podaje się, że pięciostopniowa skala
szczegółowości miary zagrożenia jest w praktyce wystarczająca.

Z kolei korzystając z modelu kosztowego, poziom ryzyka oblicza się ze wzoru:

S = P · K,

gdzie:
S — wartość potencjalnych strat,
P — prawdopodobieństwo wystąpienia zdarzenia wyznaczone z macierzy poziomu
ryzyka, uwzględniającej pięciostopniowe prawdopodobieństwo wystąpienia ryzy-
ka i trzystopniową skalę ewentualnych strat (straty wysokie, średnie, niskie),
K — szacowany koszt poniesienia strat w przypadku zaistnienia zdarzenia.

Model kosztowy znajduje zastosowanie zwłaszcza przy szacowaniu poziomu ryzy-
ka dla określonego, indywidualnego zdarzenia. Jest szczególnie przydatny do usta-
lenia priorytetów ważności dla różnych rozpoznanych zagrożeń, w celu ich dalszej
analizy.

Szacowanie ryzyka ukierunkowane jest na szacowanie łącznego ryzyka dla całego
projektu. Znajdują tutaj zastosowanie następujące metody:
1) analizy sieciowe,
2) drzewa zdarzeń,
3) listy kontrolne,
4) metody punktowe w analizie sieciowej,
5) metody eksperckie.

Kierownik projektu, odpowiedzialny za zarządzanie ryzykiem, powinien wykazać
się odpowiednim doświadczeniem w doborze najodpowiedniejszych metod szaco-
wania zagrożeń.

W metodach sieciowych podstawą analizy ryzyka jest ocena sieci CPM (Critical
Path Method) lub PERT. Z uwagi na fakt, że zakłócenia w realizacji zadań krytycz-
nych mają bezpośredni wpływ na zakończenie projektu, szczególnej analizie pod-
dawane są zadania leżące na ścieżce krytycznej. W sieciach analizie poddawane są
nie tylko podstawowe parametry zadań, powinny być również brane pod uwagę re-
lacje między powiązanymi z sobą zadaniami i uwarunkowania realizacyjne rozwa-
żanych zadań lub inne uwarunkowania (np. wynikające z alokacji zasobów). Jako
rezultat analizy sieci powinny zostać określone najbardziej zagrożone zadania na
ścieżce krytycznej. W sytuacji, kiedy wystąpiły negatywne wydarzenia, powinny
zostać wyznaczone nowe ścieżki krytyczne i przeprowadzone dla nich nowe obli-
czenia. Przykładowo, można wskazać miejsca spiętrzenia prac i w związku z tym
zwiększonego zapotrzebowania na zasoby na podstawie analizy zasobowej.

W szczególności przeprowadzanie przeglądów punktów węzłowych w projekcie jest
uproszczoną metodą wykorzystującą harmonogramy dla oceny ryzyka łącznego.

Zadania w sieci mogą być połączone określonymi typami relacji przyczynowo-
-skutkowych. Relacje te powinny być brane pod uwagę przy analizie ryzyka, ponie-
waż negatywne zjawisko w którymś z zadań najczęściej ma wpływ na inne, połą-
czone z danym, zadania. Ryzyko nie jest jednak przenoszone z jednego zadania na
inne tak, jak powiązania w sieci. W metodzie drzewa zdarzeń tworzone jest wła-
śnie drzewo zdarzeń i wyliczane jest ryzyko ich wystąpienia. Zdarzenia w ramach
drzewa można skojarzyć z konkretnymi decyzjami podejmowanymi w różnych fa-
zach projektu. Drzewo zdarzeń umożliwia przeprowadzenie oceny skutków wy-
specyﬁkowanych decyzji na różnych poziomach. W metodzie tej korzysta się na-
stępnie z modelu kosztowego w celu wyliczenia potencjalnych strat rezultatów zda-
rzenia inicjującego oraz potencjalnych strat łącznych. Na rysunku 9 przedstawio-
no przykładowe drzewo zdarzeń, w którym zdarzenie inicjujące generuje w wyni-
ku trzy rezultaty z prawdopodobieństwem ich wystąpienia odpowiednio 0,5, 0,3
i 0,2. Wymienione rezultaty powodują przedstawione stany projektu, zaznaczone
na rysunku, z odpowiednio oszacowanym prawdopodobieństwem 0,8 i 0,2 dla sta-
nów z pierwszej grupy, 0,6, 0,1 i 0,3 dla drugiej i odpowiednio 0,5 i 0,5 dla trze-
ciej grupy stanów. Każdy z uwzględnionych na rysunku stanów przyczynia się do
powstania oszacowanych indywidualnie strat.

Należy zauważyć, że dla jednego ze stanów oszacowana wartość strat jest ujemna.
Jeśli stan taki jest pomyślny dla prac w projekcie, to właśnie oszacowane wartości
strat mogą przyjmować wartość ujemną. Wartość ujemną może mieć również wy-
sokość kar umownych związanych z niewykonaniem zadania przez podwykonaw-
cę. Przeprowadzając obliczenia zgodnie ze wzorem modelu kosztowego, otrzymu-
jemy łączną wartość potencjalnych strat dla zdarzenia inicjującego w kwocie 864
w rozważanym przykładzie.

W innej metodzie oceny ryzyka — w listach kontrolnych — każdemu ujętemu na
liście zdarzeniu przypisywana jest proponowana wartość punktowa, wynikająca
z analizy wcześniej realizowanych projektów. Wartości analizowanych zagrożeń są

Rysunek 9

Kalkulacja wartości

potencjalnych strat dla

przykładowego drzewa zdarzeń

z kolei podstawiane do wzoru na kompleksowy poziom ryzyka. Wzór ten najczę-
ściej nie stanowi prostej sumy czy średniej wartości poszczególnych zdarzeń, ale
powinien, w oparciu o wiedzę danej organizacji, uwzględniać wagi dla poszczegól-
nych obszarów ryzyka.

W analizie ryzyka nie należy ograniczać się do oceny łatwo mierzalnych parame-
trów ryzyka. Powinno się pamiętać, że ważniejsza od precyzji obliczeń jest umie-
jętna interpretacja otrzymanych wielkości — i to w warunkach realizacyjnych kon-
kretnego zadania i projektu. Wszystkie dane wykorzystywane w analizie ryzyka są
jedynie szacunkami, które najczęściej nie uwzględniają ryzyka wtórnego.

5.2.3. Zapobieganie ryzyku

W ramach tego etapu podejmowane są działania zapobiegawcze, ukierunkowane
na zmniejszenie prawdopodobieństwa wystąpienia zagrożenia oraz na minimaliza-
cję strat związanych z wystąpieniem negatywnego zdarzenia.

Wszystkie działania zapobiegawcze pociągają za sobą dodatkowe nakłady, a zatem
również generują koszty. Ponosząc określone nakłady na minimalizowanie ryzyka,
nigdy nie będziemy wiedzieli, czy negatywne zdarzenie nie zaszło wskutek działań
prewencyjnych, czy też dzięki naturalnemu biegowi spraw.

W ramach działań zapobiegających ryzyku należy przeprowadzić analizę poten-
cjalnych strat w zestawieniu z kosztami. Dopiero jako wynik takiej analizy powin-
ny zostać podjęte prace zmniejszające potencjalne straty. Zwiększenie kosztów na
działania zapobiegawcze powinno w efekcie prowadzić do zmniejszenia ryzyka wy-
stąpienia straty. Przeznaczanie za dużych kosztów na minimalizowanie ryzyka jest
jednak ekonomicznie nieuzasadnione z uwagi na fakt, że od pewnego momentu
koszty te mogą przewyższać wartość potencjalnych strat. Optymalne rozwiązanie
to takie, w którym wyznaczono minimum kosztów łącznych, będących sumą na-
kładów na przeciwdziałanie i wartości potencjalnych strat.

W wyniku starannie przeprowadzonej identyﬁkacji ryzyka i jego oceny kierownik
projektu dysponuje listą uporządkowaną pod względem priorytetów zagrożeń. Po-
dejmując działania zapobiegające ryzyku, kierownik ma do dyspozycji różne me-
tody. Najmniej wyszukaną jest rezygnacja z najbardziej ryzykownych zadań przez
zmniejszenie zakresu projektu lub podzielenie go na części. Inną metodą jest po-
dział projektu na oddzielnie rozliczane etapy. Rozwiązanie takie pozwala ograni-
czyć straty w przypadku wystąpienia rozpoznanych zagrożeń.

Kolejnym działaniem zaradczym jest poszukiwanie innego rozwiązania dla działań
projektowych, które zmniejszy ryzyko. Jeżeli projekt miał polegać na stworzeniu
określonego systemu informatycznego dla przykładowej organizacji, to działaniem
zapobiegawczym może być odstąpienie od tworzenia przez dostawcę oprogramo-
wania i zakup przez klienta gotowego systemu o podobnej funkcjonalności. Takie
rozwiązanie zmniejszy spodziewany zysk z projektu, ale jednocześnie uczyni reali-
zację projektu bezpieczniejszą.

Wczesna informacja o zagrożeniach oraz znajomość ich skali pozwala zmniejszać
ryzyko ﬁnansowe przez wynegocjowanie odpowiednich zapisów dotyczących ry-
zyka w ramach kontraktu lub dołączenie ich jako aneksów do umowy. Często sto-
sowaną w praktyce metodą redukcji ryzyka jest bardzo szczegółowe zdeﬁniowanie
kontraktu na realizację projektu. W umowie znajdują się wówczas wszystkie szcze-
góły wykonawcze, precyzyjne opisy dotyczące wyboru narzędzi, zastosowanych
technologii i zapisy na temat wiedzy i doświadczenia osób realizujących projekt.
W ramach kontraktu powinny znaleźć się klauzule zawieszenia i zaniechania prac,
wraz ze szczegółowym opisem uwarunkowań tych działań. Elementem kontraktu
powinny być plany awaryjne na wypadek negatywnych zdarzeń. Niezbędnym ele-

mentem umowy powinny być procedury i kryteria formalnego odbioru całości pro-
jektu i wyników pośrednich.

Metodą minimalizowania zagrożenia jest współdzielenie ryzyka przez klienta i do-
stawcę. W przypadku systemów informatycznych dylematem dla kierownika projek-
tu może być podjecie decyzji, czy realizując system, zastosować najnowszą, ale nie
do końca znaną technologię, czy skorzystać z technologii bardzo dokładnie spraw-
dzonej, która jednak po przekazaniu systemu użytkownikowi może wydawać się
przestarzała. W takich przypadkach doświadczony kierownik projektu powinien
poinformować przedstawiciela klienta o szansach i zagrożeniach nowej technologii
i — jako wynik współodpowiedzialności tych dwóch najistotniejszych uczestników
procesu projektowego — powinna zapaść uzgodniona wówczas decyzja.

Zmniejszeniu ryzyka sprzyja odpowiednie podzielenie projektu na oddzielnie roz-
liczane etapy. Dla projektów informatycznych taka sytuacja ma miejsce, gdy zosta-
nie podzielony kontrakt realizacji systemu informatycznego na kontrakty zawiera-
ne sukcesywnie, zgodnie z cyklem życia systemu. Redukując ryzyko do pojedyn-
czych etapów ujętych w oddzielnych kontraktach, stwarzamy pole do powstania
nowego ryzyka polegającego na realizacji kolejnego etapu prac przez nowy zespół
wykonawców. Taka sytuacja może też bardzo niepokoić klienta, który może oba-
wiać się, że wykonawca-dostawca wycofa się z projektu po wykonaniu „łatwych”
początkowych etapów.

Redukcję ryzyka uzyskujemy przez sprawny system monitorowania zagrożeń w ca-
łym cyklu życia projektu, poprawne funkcjonowanie formalnego systemu zarzą-
dzania zmianami zakłócającymi porządek działań projektowych, a także efektyw-
ną komunikację między uczestnikami przedsięwzięcia.

5.2.4. Monitorowanie ryzyka

Każde zidentyﬁkowane ryzyko wymaga nieustannego monitorowania. Tylko cią-
głą obserwacja i kontrola ryzyka pozwala wyeliminować jedne, a obsługiwać inne
zagrożenia. Wyniki kontroli zagrożeń umożliwiają modyﬁkowanie planów działań
zapobiegawczych odpowiednio do zaistniałej sytuacji.

W dziedzinie zarządzania ryzykiem wyróżnia się dwa sposoby monitorowania ryzy-
ka — reaktywne i aktywne. Podejście reaktywne jest podejściem ex post, tzn. uru-
chamia działania zmierzające do zminimalizowania skutków negatywnego zdarze-
nia dopiero po jego wystąpieniu. Podejście drugie — aktywne — zakłada przewi-
dywanie możliwości wystąpienia negatywnych zdarzeń i przeciwdziałanie im przed
ich wystąpieniem. Działania takie są drogie i ich koszty zwiększają koszty projektu.
Kierownik projektu powinien umiejętnie stosować obydwa podejścia, w zależności
od uwarunkowań realizacyjnych projektu, za który jest odpowiedzialny.

Z chwilą ujęcia w kontrakcie wszystkich zidentyﬁkowanych zagrożeń oraz opisów
działań zapobiegawczych należy rozpocząć monitorowanie ryzyka. Zalecane jest
(w metodyce ﬁrmy IBM), aby jednym z tematów seminarium poświęconego deﬁ-
nicji projektu był system zarządzania ryzykiem. Ustalenia w tej sprawie powinny
mieć charakter formalny, najlepiej planów działań zapobiegających ryzyku, a plany
te powinny być realizowane z taką samą starannością jak np. harmonogram dzia-
łań projektowych uwzględniający alokację zasobów.

Po zidentyﬁkowaniu zagrożeń kierownik projektu powinien umieć sprostać sytu-
acji, w której nie wystąpiły rozpoznane zagrożenia, a nieoczekiwanie pojawiły się
inne, nieuwzględnione w kontrakcie. Sytuacje takie wymuszają na kierowniku po-
dejmowanie decyzji w bardzo krótkim czasie. Na przykład, kiedy przy wdraża-
niu systemu informatycznego, który ma uwzględniać rozproszenie terytorialne da-
nej organizacji, pojawiły się poważne komplikacje przy instalacji oprogramowa-

Document Outline