Materiały do przedmiotu
ZarzÄ…dzanie projektem
informatycznym
Ścibór Sobieski
Wydział Matematyki UA
, wersja z dnia: 2006-11-17
Spis treści
Wstęp......................................................................
.................5
1 Podstawowe wiadomości......................................................6
1.1 Definicja zakresu problematyki......................................6
1.2 Obszary.................................................
.......................12
1.3 Czynniki krytyczne sukcesu.........................................14
2 Metodyka zarzÄ…dzania projektem informatycznym............22
2.1 Zarządzanie tworzeniem systemówinformatycznych. 23
2.2 Project Management Institute......................................27
2.2.1 ZarzÄ…dzanie integracjÄ… projektu............................28
2.2.2 ZarzÄ…dzanie zakresem..........................................31
2.2.3 ZarzÄ…dzanie czasem...........................................
...34
2.2.4 ZarzÄ…dzanie kosztami...........................................38
2.2.5 Zarządzanie jakością................................
.............40
2.2.6 ZarzÄ…dzanie zasobami ludzkimi............................42
2.2.7 ZarzÄ…dzanie komunikacjÄ….................................
.....45
2.2.8 ZarzÄ…dzanie ryzykiem...........................................48
2.2.9 ZarzÄ…dzanie zaopatrzeniem..................................50
2.3 PRINCE 2.....................................
.................................55
2.3.1 Ogólna charakterystyka........................................56
2.3.2 Przygotowanie założeń projektu............................57
2.3.3 Strategiczne zarzÄ…dzanie projektem.....................59
2.3.4 Planowanie....................................
........................59
2.3.5 Inicjowanie projektu .............................................61
2.3.6 Sterowanie etapem ..............................................64
2.3.7 Zarządzanie dostawą produktów..........................66
2.3.8 ZarzÄ…dzanie zakresem etapu ...............................66
2.3.9 Zamykanie projektu..............................................68
3 ZarzÄ…dzanie projektem.............................
..........................70
3.1 Miary w projekcie informatycznym..............................70
3.2 ZarzÄ…dzanie zakresem projektu informatycznego.......72
3.2.1 Planowanie prac..............................
......................73
3.3 Tworzenie harmonogramu (wykres Gantta, techniki
sieciowe wymiarowanie sieci)............................................76
3.4 ZarzÄ…dzanie zakresem projektu (planowanie prac,
struktura prac, punkty węzłowe).....................................
...76
3.5 Określanie budżetu projektu (szacowanie, sposoby
przenoszenia kosztów........................................................76
3.6 Określanie zasobów potrzebnych do realizacji projektu
..................................................................
.........................76
3.7 Monitorowanie postępów prac.....................................76
3.8 Narzędzia wspomagające............................................76
3.8.1 Narzędzia pracy grupowej.....................................77
3.8.2 Narzędzia programistyczne...................................77
3.8.3 Narzędzia wspomagające zarządzanie..................77
4 ZarzÄ…dzanie zasobami..............................
..........................78
4.1 Tworzenie zespołu...............................
.........................78
4.2 Praca z istniejącym zespołem......................................84
4.2.1 Określanie zadań............................................
.......84
4.2.2 Motywacja, zwiększanie wydajności......................85
4.2.3 Zebrania..............................................
..................85
4.2.4 Przeglądy wewnętrzne i zewnętrzne.....................85
4.3 Zarządzanie czasem zespołu (tworzenie
harmonogramów, rozliczanie czasu pracy)........................85
4.4 Komunikacja w zespole (rola, przepływ, z
ródła)...........85
4.5 Rola kierownika projektu (podstawowe zadania
kierownika, kwalifikacje, umiejętności)..............................85
4.6 Analiza zasobowa harmonogramu...............................86
5 ZarzÄ…dzanie ryzykiem w projekcie informatycznym...........87
5.1 Definicja ryzyka (y
ródła/czynniki)................................87
5.2 Identyfikacja........................................................
.........87
5.2.1 Sesje identyfikacji ryzyka......................................88
5.2.2 Listy kontrolne..........................................
.............88
5.2.3 Metoda Crawforda..............................
...................88
5.2.4 Metoda SWOT..............................................
..........88
5.3 Ocena ryzyka...............................................................88
5.3.1 Model kosztowy (EMV).......................................
....88
5.3.2 Analizy sieciowe....................................................88
5.3.3 Metoda PERT.........................................................
.88
5.3.4 Drzewa zdarzeń (Event Tree Analysis)..................88
5.3.5 Drzewa błędów (Fault Tree Analysis).....................88
5.3.6 Metody eksperckie-delfickie..................................88
5.4 Zapobieganie występowaniu ryzyka............................88
5.4.1 Działania zapobiegawcze......................................88
5.4.2 Metody pomiaru efektywności podjętych działań. 88
5.5 Monitorowanie ryzyka..................................................89
5.5.1 Monitorowanie reaktywne.....................................89
5.5.2 Monitorowanie aktywne........................................89
5.5.3 PrzeglÄ…dy i audyty.......................................
..........89
6 ZarzÄ…dzanie wiedzÄ… w projekcie informatycznym..............90
6.1 y
ródła wiedzy (wewnętrzne, zewnętrzne, ekspertowe)
..................................................................
.........................90
6.2 Gromadzenie wiedzy (sposoby, narzędzia, ludzie)......90
6.3 Przetwarzanie wiedzy (analiza, synteza)......................90
6.4 Magazynowanie wiedzy (narzędzia, wyszukiwanie,
archiwizowanie)..............................................................
....90
6.5 Dokumentacja w projekcie (rodzaje, narzędzia)..........91
6.6 ZarzÄ…dzanie zmianami w projekcie (z
ródła zmian,
priorytet, polityka).............................................................
.91
Bibliografia...........................................................
..................92
Indeks alfabetyczny...................................
............................93
Wstęp
W zamierzeniu to, co Czytelnik trzyma w ręku będzie, o ile
kiedykolwiek tak się stanie, podręcznikiem lub chociaż
skryptem, dla studentów kierunków informatycznych do
przedmiotu zarzÄ…dzanie projektem informatycznym (ZPI).
W chwili obecnej jest to zbiór materiałów do wykładu ZPI
w formie dość luz
nej, nie zawsze uporzÄ…dkowanej i absolutnie
niekompletnej. Niniejsze materiały można traktować jedynie
jako wprowadzenie zagadnień. Stąd też czytasz te materiały
na własną odpowiedzialność i Autor niniejszego opracowania
nie ponosi żadnej odpowiedzialności za stan zdrowia osoby
czytającej, ani też za efekty jakie przyniesie lektura ;-).
Na razie jako lekturę uzupełniającą polecam [Szyjewski
2001]. W ramach tego przedmiotu przyjmuje się, że student
zna zagadnienia wykładane w ramach przedmiotu inżynieria
oprogramowania w zakresie, co najmniej, przedstawionym
w materiałach [Sobieski 2005] lub zapoznał się z innymi tego
typu pozycjami np. [Sommerville 2004].
5
1 Podstawowe wiadomości
1.1 Definicja zakresu problematyki
Gdy będziemy mówili o projekcie będziemy mieli na myśli
wykonywanie prac w ramach pewnego przedsięwzięcia1,
którego celem jest opracowanie, bądz
wdrożenie
nowatorskiego pomysłu. Inaczej mówiąc, z projektem
będziemy mieli do czynienia wtedy, gdy prowadzimy prace,
co do których nie wiemy jak mogą przebiegać, ani też nie
jesteśmy pewni, czy zawsze zakończą się sukcesem2. Co
oczywiście nie znaczy, że sposób prowadzenia tych prac ma
charakter chaotyczny i bałaganiarski. Nic bardziej mylnego 
jeśli prace są wykonywane w sposób niewłaściwy to
zwiększamy ryzyko niepowodzenia projektu. Różnego rodzaju
metodyki prowadzenia projektów3 mają właśnie za zadanie
uporządkowanie tych działań tak, by odnieść możliwie pełny
sukces. W ramach projektu można prowadzić pracę
badawcze, odkrywcze, wdrożeniowe... oraz wszelkie inne, co
do których nie ma jeszcze ustalonych reguł  wytwórczych .
Rozważmy prosty przykład. Jeśli wez
miemy książkę
kucharskÄ… i w oparciu o przepis w niej zawarty upieczemy
1 Zwykle biznesowego, choć można wskazać również projekty w
założeniu nie dochodowe, prowadzone poprzez organizacje non-profit.
2 Zatem projekt może zakończyć się porażką i należy się z tym liczyć.
3 Nie koniecznie projektów informatycznych.
6
ciasto, to można powiedzieć, że wszystko było znane od
początku do końca (każdy krok) i w efekcie zamieniliśmy się
w  maszynę do produkcji ciasta. Jeśli jednak chcemy
wymyśleć nowe ciasto, to nie wiemy ile i jakiego rodzaju
składniki chcemy użyć. Można powiedzieć, że wtedy
prowadzimy działania odkrywcze, czyli realizujemy
eksperyment majÄ…cy na celu stworzenie nowego przepisu na
ciasto. Wtedy te działania można nazwać projektem pod
kryptonimem  moje nowe super ciasto .
Ogólnie, mamy dwa podstawowe rodzaje działań:
" realizację z góry zadanej procedury  takie podejście
zwane jest również realizacją pewnego procesu;
" działania w ramach projektu, których celem może być
opracowanie nowej procedury (choć nie musi).
To, co powiedzieliśmy wcześniej jest prawdziwe dla
każdego rodzaju projektu. Jednak zwróćmy uwagę na pewną
specyfikę związaną z dziedziną informatyki. Przypomnijmy, że
w ramach inżynierii oprogramowania podkreśla się, iż produkt
realizowany w ramach przedsięwzięć informatycznych jest
najczęściej tworzony, a nie produkowany. Przypomnijmy, że
gdy mówimy o produkcji samochodów, to poza fazą projektu,
dalej mamy proces produkcyjny  zmechanizowany, a często
prawie zupełnie zautomatyzowany.
Niestety oprogramowanie można jedyne powielać
w sensie wykonywania kolejnych kopii na nośniku informacji,
nie da się jednak stworzyć automatycznej linii technologicznej
do produkcji gier komputerowych bez udziału ludzi4. Dzieje się
tak, gdyż prawie każdy program jest unikalny i wymagany jest
w tym przypadku proces twórczy, stąd w produkcji
oprogramowania praktycznie wyłącznie mówimy o projektach
informatycznych.
Spróbujmy teraz zastanowić się nad tym, jakie czynniki
4 Tak samo, jak nie bardzo można stworzyć linię produkcyjną
wymyślającą nowe modele samochodów  tu też potrzebny jest
człowiek.
7
muszą wystąpić, byśmy mogli mówić o projekcie:
1. Inwestor  może być to jedna osoba, firma czy
konsorcjum. Dowolna umowna jednostka, która ma
potrzebę by zrealizować pewne przedsięwzięcie
(osiągnąć wyznaczony cel) i realizacja jego jest możliwa
poprzez działania w ramach projektu (lub mówiąc
inaczej, nie można zaspokoić potrzeb inwestora poprzez
dostarczenie mu gotowego, istniejÄ…cego, produktu).
2. Cel (zakres) projektu  wyznacza ramy
przedsięwzięcia, a tym samym zadania konieczne do
wykonania, by ów cel osiągnąć. Jest szalenie istotne, by
na samym początku projektu wypisać możliwie
dokładnie zadania, które mają doprowadzić do
określonego celu. Taki spis pozwoli na kontrolę postępu
prac i przeprowadzenie studium wykonalności5.
3. Ramy czasowe  zwykle inwestor, który finansuje cały
projekt ma pewne oczekiwania, co do czasu jego
realizacji. Oczywiście w trakcie negocjacji i ustaleń
strategicznych z wykonawcą mogą one ulegać pewnym
modyfikacjom. Jednak, jeśli inwestor oczekuje
wykonania danego projektu w ciągu kwartału,
a wykonawca uzna, że jest to możliwe w co najmniej
rok, to może okazać się, że inwestor zmieni charakter
projektu (zmniejszy jego zakres) lub w ogóle
zrezygnuje6.
4. Budżet  bardzo rzadko zdarza się, że inwestor nie
wyznacza ram finansowych dla osiągnięcia celu.
Oczywiście zwykle można negocjować kwotę
przeznaczoną na realizację, jednak pamiętajmy, że
każdy chciałby kupować jak najtaniej.
5 Niestety w projektach należy liczyć się z porażką i im szybciej zdamy
sobie sprawę z niemożności wykonania zadania, tym lepiej z punktu
widzenia ponoszonych kosztów.
6 Zakładając, że możliwa jest rezygnacja i zakładając, że wykonawca
dokonał właściwego oszacowania czasu realizacji, a nie wynika to z
jego bezsilności, zwykle wypływającej ze zbyt małego doświadczenia
oraz braku wiedzy.
8
W literaturze przedmiotu zdarza się również, że autorzy
podręczników uznają tylko punkty 2-4, jako wyznaczniki
projektu. Jednak zauważmy, że bez pierwszego elementu,
czyli podmiotu, u którego zrodził się cel nie ma mowy
o pozostałych. Stąd my przyjmujemy powyższe założenia,
choć często w kolejnych rozważaniach będziemy traktowali
rolę inwestora za tak oczywistą, że nie będziemy jej
szczególnie wyróżniać. Zauważmy dalej, że punkty 2-4 są ze
sobą ściśle powiązane. Nie możemy zwiększyć zakresu
projektu bez podniesienia kosztów jego realizacji7. Oczywiście,
jeśli czas realizacji ulegnie zmianie, to tym najczęściej
również wzrosną koszty. Możemy też wyobrazić sobie
sytuacjÄ™, jak wymienionÄ… w punkcie 3, kiedy zmieniony
zostanie zakres projektu, by można było zrealizować go
w nieprzekraczalnym czasie, bÄ…dz
budżecie.
Osobną sprawą są różnego rodzaju środki, jakie trzeba
zapewnić, by projekt mógł być wykonany. Zwykle stosuje się
następujący podział:
1. Zespół projektowy  grupa osób o zróżnicowanych
umiejętnościach, która współpracuje, by sprawnie
i ekonomicznie zrealizować cele projektu. Mamy tu na
myśli szeroką grupę osób  w skład zespołu będą
wchodziły zarówno osoby po stronie wykonawcy, jak
i inwestora (mogą być to również różnego rodzaju
konsultanci). Więcej informacji na ten temat
w rozdziale 4.
2. Kierownik projektu  bardzo często wyróżnia się tę
rolę w zespole projektowym i podkreśla jego rangę.
Prawdą jest, że kierownik ponosi pełną
odpowiedzialność za wszystko, co dzieje się
w projekcie, w tym za poczynania zespołu. Więcej
informacji na ten temat w punkcie 4.5.
3. Środowisko pracy  zespół projektowy musi mieć
miejsce do pracy, wyposażone we wszystkie niezbędne
7 Być może czas się nie zmieni, jeśli zatrudnimy więcej osób i będzie
można odpowiednio rozdzielić prace.
9
narzędzia i przyrządy. Zatem będą to komputery,
drukarki, skaner, ale również białe tablice, mazaki,
i wiele innych. Samo miejsce powinno też zachęcać do
pracy. Pod tym pojęciem będziemy rozumieli również
oprogramowanie niezbędne, tak do zarządzania
projektem, jak i wykonania działań typowo
inżynierskich, mających doprowadzić do wytworzenia
programu, bÄ…dz
systemu.
Na koniec podsumujmy dotychczasowe rozważania na
temat zakresu zarządzania projektem informatycznym. Można
zauważyć, że samo zarządzanie jest elementem inżynierii
oprogramowania, jako takiej, gdyż inżynieria to zbiór
wszystkich działań, które mają doprowadzić do wytworzenia
oprogramowania. Z drugiej jednak strony zarzÄ…dzanie stoi
ponad nimi wszystkimi, gdyż jego rolą jest koordynacja
wszystkich działań, zarządzanie ryzykiem, kierowanie ludz
mi
i wiele innych o czym piszemy dalej.
ZarzÄ…dzanie projektem informatycznym to zastosowanie
wiedzy, umiejętności, narzędzi i technik w trakcie trwania
działań projektowych, których celem jest osiągnięcie korzyści
jakich spodziewa się Inwestor. Osiągnięcie tych korzyści
wymaga:
1. harmonijnego współdziałania wszystkich uczestników
projektu, zarówno po stronie wykonawcy, jak
i zlecającej, a tym bardzie pomiędzy nimi;
2. zrealizowania zdefiniowanego zakresu przedsięwzięcia
przy założonych ramach budżetowych oraz
w określonym czasie, do tego przy zachowaniu norm
jakościowych;
3. uwzględnienia warunków środowiska, w jakim projekt
jest realizowany i ma działać, w tym zrozumienia
podłoża organizacyjnego dla tworzonego systemu;
4. spełnić wymagania użytkownika w zakresie
niezidentyfikowanych oczekiwań.
Omówmy pokrótce powyższe czynniki. Punkt pierwszy
wydaje się być oczywisty w każdym środowisku, gdzie
10
odbywa się współpraca pomiędzy ludz
mi. Harmonia
współpracy lub jej brak jest szczególnie odczuwalna we
wszystkich projektach, w tym informatycznych. Projekty,
oparte przede wszystkim o myślenie twórcze, odkrywcze
wymagajÄ… skupienia i dobrej wymiany informacji, jej brak
odbije się natychmiast na efektywności lub powodzeniu
przedsięwzięcia.
Punkt drugi jest czytelny i ograniczymy siÄ™ jedynie do
komentarza, że czynnik związany z jakością bywa różnie
traktowany. Otóż część autorów postrzega go jako  czwarty
wymiar w zarzÄ…dzaniu projektami, mamy zatem: zakres,
czas, budżet, jakość. Inni zaś traktują go jako coś
występującego niejako obok, a zarazem wewnątrz zakresu.
Dla nas wydaje się łatwiejsze jawne przyznanie, że jakość jest
bardzo ważna w projektach. Oczywiście w tym momencie jest
ona czynnikiem wpływającym na pozostałe. Wszak nie można
zrealizować dwa razy większego zakresu pracy w tym samym
czasie realizacji nie zwiększając kosztów i do tego zachowując
założony poziom niezawodności8.
Uwzględnienie warunków środowiska, jest szalenie ważne
i bardzo często niedoceniany przez niedoświadczone zespoły
projektowe. Omówimy je szerzej w punkcie 1.3.
Czwarty punkt, dotyczący spełnienia wymagań
użytkownika, może wydawać się dziwny, gdyż można byłoby
stwierdzić, że oczekuje się od realizującego projekt co
najmniej jasnowidzenia. Należy jednak spojrzeć na ten
problem z innej strony. Jasne jest, że klient musi określić
zakres projektu, w tym celu określa zadania, jakie ma
realizować system. Oczywiście, skoro je określił, są one
zidentyfikowane. Jednak praktyka pokazuje, że istnieje grupa
wymagań, których nie można zidentyfikować od razu9. To
właśnie te  ukryte zadania należą do grupy
niezidentyfikowanych wymagań. Zwykle odkrywa się je
8 Jest to jeden z elementów jakości.
9 Istnieje wiele przyczyn takiego stanu rzeczy, więcej na ten temat
można znalez
ć w punkcie (???).
11
w trakcie działań wykonawczych, czasami po prostu klient
sobie coÅ› przypomni, a czasami to wykonawca zaproponuje
pewną funkcjonalność.
Jak to zostało napisane wcześniej, projekt jest
ustanawiany by wykonać coś nowatorskiego i jest
wykorzystywany, jako sposób prowadzenia prac, w wielu
dziedzinach. Wymieńmy tylko kilka przykładów:
" architektura  projekt nowego budynku, mostu czy innej
konstrukcji;
" medycyna - opracowanie nowego leku;
" zarzÄ…dzanie - wprowadzenie nowej struktury
organizacyjnej w firmie czy nowego obiegu
dokumentów;
" telekomunikacja - opracowanie nowego satelity
komunikacyjnego;
" informatyka - opracowanie nowego programu.
My skupimy siÄ™ tylko na zarzÄ…dzaniu projektem
informatycznym na etapie jego tworzenia i ewentualnie
wdrożenia.
1.2 Obszary
W ramach zarzÄ…dzania projektem informatycznym
podejmowane są różnego rodzaju działania, których celem
będzie odniesienie sukcesu, o czym pisaliśmy wcześniej, czyli
mówiąc krótko realizacja zadań postawionych przed nami
przez zleceniodawcÄ™.
Spróbujemy teraz odejść od wcześniejszych ogólnikowych
stwierdzeń i wypiszemy obszary, jakie wchodzą w skład
zarządzania projektem informatycznym i pokrótce je
omówimy. Część z tych obszarów będzie opisana bardziej
szczegółowo w dalszych częściach pracy. Poniższe obszary
można traktować jako pewien podział wszelkich działań
zarządczych - są to punkty skupienia uwagi. Taki podział
pomaga póz
niej śledzić postęp prac nad całością projektu.
12
 1 Projekt
1.1 Zakres
1.1.1 Spójność
1.1.1.1 W zakresie części (modułu)
1.1.1.2 W zakresie całego projektu
1.1.1.3 W zakresie wszystkich realizowanych
projektów
1.1.2 Kompletność (podział podobny, jak w przypadku
spójności)
1.1.3 ZarzÄ…dzanie wiedzÄ…
1.1.3.1 Identyfikacja z
ródeł wiedzy
1.1.3.2 Gromadzenie wiedzy
1.1.4 ZarzÄ…dzanie zmianami
1.1.4.1 Identyfikacja z
ródeł zmian
1.1.4.2 Ustalanie priorytetów
1.1.4.3 Zmiana zakresu projektu
1.2 Koszt
1.2.1 Tworzenie preliminarza kosztów
1.2.2 Tworzenie budżetu
1.2.3 Śledzenie odstępstw od założeń budżetowych
1.2.4 Sygnalizacja zagrożeń dla budżetu
1.3 Czas
1.3.1 Tworzenie harmonogramu
1.3.2 Śledzenie postępów prac
1.3.3 Modyfikacja harmonogramu
2 Jakość
2.1 Procedury postępowania
2.1.1 Tworzenie procedur dla całego projektu
2.1.2 Systematyzacja procedur w księgę jakości
2.1.3 Ewentualne uzyskanie certyfikatu
2.2 Pomiary i ich analiza
2.2.1 Przeprowadzanie różnego rodzaju pomiarów
2.2.2 Analiza statystyczna wyników
2.2.3 Modyfikacja procedur postępowania w celu
podniesienia jakości prac
3 Zasoby ludzkie
3.1 Pracownik
13
 3.1.1 Nabór pracowników
3.1.2 Szkolenia pracowników w zakresie używanych
technologii
3.1.3 Nadzór
3.1.4 Ocena
3.2 Współpraca w grupie
3.2.1 Szkolenia i treningi w zakresie współpracy
3.2.2 Rozwiązywanie konfliktów
3.2.3 Spotkania integracyjne
3.2.4 Szkolenia z narzędzi do komunikacji
4 Zasoby sprzętowo-programowe
4.1 Konfiguracja sprzętu
4.2 Konfiguracja oprogramowania
4.3 Testy wydajności
5 Ryzyko
5.1 Identyfikacja
5.2 Ocena
5.3 Zapobieganie
5.4 Monitorowanie
6 Inne
6.1 Zaopatrzenie
6.2 Organizacja miejsca pracy
6.3 Organizacja szkoleń
6.4 Organizacja spotkań motywacyjnych/treningów
1.3 Czynniki krytyczne sukcesu
Do tej pory koncentrowaliśmy się na tym, czym jest
zarzÄ…dzanie projektem informatycznym, jakie cele stawiamy
oraz w jakich obszarach są podejmowane działania. Teraz
spróbujemy powiedzieć, jakie czynniki są krytyczne by
odnieść sukces.
Wpierw zauważmy, że najważniejszą rzeczą, której do tej
pory nie wymieniliśmy, jest bardzo jasne określenie celu
informatyzacji firmy. Tu może pojawić się pytanie, czemu nas
to interesuje, przecież skoro klient przychodzi i zleca
realizację pewnego zadania, to powód, dla którego to robi jest
14
jego sprawÄ…. Niestety, jak pokazuje praktyka, nie tylko jego.
By lepiej to zrozumieć, spróbujmy się zastanowić, jakie cele
stawia sobie wykonawca (powiedzmy My) w konkretnym
projekcie. Można by powiedzieć: przecież to
oczywiste,chcemy zakończyć projekt, by odnieść sukces. No
dobrze, ale w jakim celu? Można wymienić dwie zasadnicze
motywacje:
1. Zysk  wszak jesteśmy firmą komercyjną, której celem
jest przynoszenie dochodów. Stąd każdy projekt jest dla
nas możliwością ich pomnażania.
2. Prestiż  każdy projekt zakończony sukcesem zwiększa
naszÄ… listÄ™ referencyjnÄ…, a tym samym umacnia naszÄ…
pozycję na rynku, przez co możemy ubiegać się o
kolejne projekty, często większe i trudniejsze.
Wróćmy zatem do naszego klienta, który nie wie po co
dokonuje informatyzacji firmy. Czy jest to ryzyko dla
powodzenia projektu? Z całą pewnością tak10. A co się stanie,
jeśli projekt nie zakończy się sukcesem? Po pierwsze - nie
możemy go dopisać do listy naszych sukcesów, ale co gorsza
może pójść zła fama i będziemy postrzegani, jako nierzetelny
wykonawca. Bardzo trudno będzie wytłumaczyć, że to wina
klienta. Druga sprawa to brak zarobku, albo nawet
poniesienie strat finansowych. Dzieje się tak, ponieważ
nakłady pracy (tym samym ponoszone koszty) są nieliniowe
w trakcie życia projektu. Zwykle na początku są małe, by
potem znacznie wzrosnąć i na koniec znów zmaleć. Spójrzmy
na rysunek 1, przedstawia on przykładową krzywą kosztów
firmy wykonawczej z naniesioną krzywa przychodów. Przy
czym założono przy tworzeniu tego rysunku, że firma
wykonawcza podpisała umowę, w której płatność odbywa się
w ratach, po oddaniu kolejnych, ustalonych wcześniej, etapów
tworzenia systemu11. Widać stąd wyraz
nie, że jeśli umowa
zostanie zerwana, np. po pierwszej fazie, wtedy wykonawca
10 W rozdziale 5, można znalez
ć szersze omówienie zagadnień
identyfikacji ryzyka w projekcie.
11 Taka forma umowy jest spotykana przy dużych projektach, gdy czas
trwania rozkłada się na kilkanaście miesięcy.
15
ponosi znaczne straty. Oczywiście przy dobrze podpisanej
umowie możemy bronić się przed taką sytuacją również w
sądzie, ale i tu pojawiają się pułapki. Klient przy z
le
określonym projekcie może po prostu zbankrutować, stąd też
i pożytek z dobrej umowy dla nas będzie mierny.
Rys 1. Koszty firmy wykonawczej a przychody z tytułu wypłacanych rat.
[Opracowanie własne]
Staje się zatem jasne, że również w naszym interesie jest
by Inwestor miał jasno sprecyzowany cel, dla którego
wprowadza informatyzację w firmie. Ponieważ koncentrujemy
się w tej pracy na dużych przedsięwzięciach, więc tak
naprawdę nie tylko mówimy o celu informatyzacji firmy, bo
ten można lakonicznie nazwać  by było lepiej . Ale często
mówimy o strategii informatyzacji firmy i fakt, że będzie lepiej
po zakończeniu całości projektu, jest skutkiem przemyślanych
i dobrze zaplanowanych kolejnych kroków. Jak pisaliśmy
wcześniej, bardzo ważne jest by klient jasno określił cele chce
osiągnąć, a my powinniśmy starać się te cele dobrze
zrozumieć. Równie ważne jest zrozumienie obecnej sytuacji
klienta. Naszą rolą jest pomóc Inwestorowi tak zaplanować
działania, by realizacja i wdrożenie systemu informatycznego
nie utrudniała zanadto normalnej pracy zarobkowej
przedsiębiorstwa klienta. Zupełnie zaś niedopuszczalne jest
zatrzymanie pracy, gdyż wiąże sie to zwykle z ogromnymi
stratami.
16
Dla przykładu zauważmy, że często banki elektroniczne
ogłaszają na swoich stronach, iż z przyczyn konserwacji
systemu informatycznego usługi... i tu lista, będą nieczynne w
godzinach... Zauważmy dalej, że najczęściej są to 2-3 godziny
w środku nocy, kiedy większość z klientów śpi i nie stanowi to
dla nich dużego utrudnienia. Podobnie my planując proces
tworzenia, a co najważniejsze wdrożenia (uruchomienia)
systemu u klienta powinniśmy się starać tak zaplanować
pracę, by nie utrudniać zwykłych jego działań. Ale by te prace
dobrze zaplanować jest niezbędne określenie strategii
informatyzacji. Pamiętajmy, że przy dużych systemach
informatycznych realizacja takiej strategii będzie wymagała
kilku lat na realizację. By zrealizować cel nadrzędny, jakim
jest powodzenie całości przedsięwzięcia, najprościej podzielić
całość na etapy, które łatwiej rozliczyć i kontrolować - pozwoli
to stwierdzić, czy nie przekraczamy czasu bądz
budżetu.
Można wyróżnić kilka zasadniczych powodów, dla których
Inwestor zdecydował się na informatyzację, bądz
wymianÄ™
istniejÄ…cego rozwiÄ…zania na technologicznie nowsze:
1. Niezbędne  są to wymuszone zmiany poprzez
przepisy bÄ…dz
rozporządzenia, płynące głównie od
ustawodawcy danego kraju. Tutaj bardzo dobrym
przykładem, choć troszkę naiwnym z punktu widzenia
dużych projektów, jest konieczność wysyłania
dokumentów do ZUS z jedynie słusznego programu
Płatnik. Każda firma, zatrudniająca powyżej ustalonej
liczby pracowników, jest zmuszona przesyłać dane
o pracownikach i ich dochodach za pomocÄ… tego
programu. W tym momencie pozostajÄ… dwa
rozwiązania, kupić komputer i robić to samodzielnie,
albo zlecić to do biura księgowego, które taką usługę
wykona. Jest to przykład czynnika zewnętrznego, który
zmusza właścicieli firmy do informatyzacji. W takim
przypadku, trudno mówić o zyskach płynących z takiej
inwestycji.
2. Zmiana techniki pracy  w tym przypadku
17
informatyzacja firmy to inwestycja, taka sama, jak
zakup samochodu do transportu czy też maszyny do
produkcji. A jako taka musi mieć określony czas,
w jakim się zwróci. Zauważmy, że mogą być tutaj co
najmniej dwa podprzypadki. Pierwszy - wprowadzamy
pewne rozwiÄ…zanie, by przy tej samej liczbie
pracowników obsługiwać więcej zleceń, czyli zwiększyć
przychody firmy. Drugi - chcemy wprowadzić
automatyzację pewnych procesów, by obniżyć koszty
usług.
3. Nadążanie za trendami  konkurencja wprowadziła
już rozwiązanie  przyjemniejsze dla ich klienta, stąd
nasz Inwestor stoi przed dylematem, wydać pieniądze
i być  na fali , albo ich nie wydać i liczyć sie z ryzykiem,
że zacznie tracić klientów. Taka sytuacja występuje
bardzo często na runku operatorów
telekomunikacyjnych. Wprowadzane są wciąż nie tylko
nowe telefony, ale przede wszystkim zarzÄ…dzanie
swoim kontem (telefonem) jest możliwe przez coraz to
bardziej wymyślne serwisy internetowe.
4. Prestiż  jasne jest, że nie wszystkie działania firmy
daje się przeliczyć bezpośrednio na pieniądze -
przynajmniej nie od razu. Do takich działań należy
budowanie obrazu firmy, a w efekcie jej prestiżu na
rynku. Zauważmy, że obecnie patrzymy z nieufnością
na dużą firmę, która nie posiada własnej strony WWW,
a w przypadku niektórych firm brak sklepu
internetowego będzie powodował spadek
zainteresowania jej produktami. Właśnie takie działania
są przynoszącymi zysk, który nie znajduje
bezpośredniego przełożenia na wpływy na k
oncie.
Zauważmy jednocześnie, że w zależności od tego, z jakim
 typem projektu mamy do czynienia, możemy spotkać się
z różnym zaangażowaniem klienta. Co więcej, nawet
w ramach pewnego typu, nie jest oczywiste, jak zadziała
Inwestor. Załóżmy, że mamy do czynienia z niezbędnym
projektem. Może się okazać, że Inwestor traktuje go jako zło
18
konieczne narzucone przez ustawÄ™ i interesuje go jedynie
wykonanie niezbędnego minimum, by zaspokoić
ustawodawcę. Z drugiej strony może to być projekt
podłączenia telefonów do zmienionej infrastruktury i tutaj
Inwestor dostrzeże dodatkowe możliwości dla niego, w tym
przypadku poparcie i zaangażowanie będzie bardzo duże.
Kolejnym bardzo ważnym czynnikiem krytycznym sukcesu
jest wybranie odpowiedniej kolejności wdrażania nowych
rozwiązań w firmie. Jest to oczywiście element strategii
informatyzacji firmy, jednak do tej pory mówiliśmy o
wyznaczania jasnych celów, jakie chcemy osiągnąć. Teraz
musimy zaplanować tak działania, by stanowiły one ciąg
logicznie po sobie następujących kroków, które wykonamy
płynnie i w efekcie całą firmę  pokryjemy systemem
informatycznym. Oczywiście poprzez sformułowanie  cała
firmę rozumiemy tak naprawdę te obszary, które nadają sie
do wprowadzania nowych systemów informatycznych i które
chce zinformatyzować Inwestor. Zauważmy, że dzisiejsza
informatyka wkracza w bardzo szeroką gamę działów,
poczÄ…wszy od sterowania liniami produkcyjnymi, poprzez
zarządzanie produkcją, magazynami, a skończywszy na
wystawianiu faktur czy zarzÄ…dzaniu personelem, bÄ…dz

kontaktami z klientami. Stąd też to Inwestor powinien
określić, jakie obszary działalności chce pokryć za pomocą
nowych systemów, oraz jakie zysk mają przynieść dla całości
firmy.
Załóżmy teraz, że mamy wytypowane działy w firmie
Inwestora, które chcemy zinformatyzować. W dalszym etapie
konieczne jest takie zaplanowanie prac, by nie tylko zapewnić
ciągłość pracy firmy Inwestora, o czym pisaliśmy wcześniej,
ale również obniżyć koszty całego projektu. Dla przykładu,
klient chce wdrożyć nowe systemy: Kadry, Płace, Finanse,
CRM i Gospodarkę Magazynową. Jaką kolejność
zaproponować? Niestety nie ma na to uniwersalnej
odpowiedzi. Wszystko zależy od konkretnej sytuacji
(projektu). Złóżmy, że kolejność będzie taka, jak powyżej.
19
Ktoś mógłby powiedzieć, że Gospodarkę Magazynową
powinniśmy wdrożyć zanim wdrożymy Finanse. Jest to
naturalne, gdyż profesjonalny system finansowy faktycznie
zbiera dane prawie ze wszystkich innych systemów w firmie.
Ale jeśli teraz okaże się, że w firmie istnieje już stary system
magazynowy i by go zmienić, trzeba wymienić wpierw nie
tylko sprzęt, na którym on działa, ale również dopisać moduły
do istniejących urządzeń zliczających towar, wydających go
itp. Może się okazać, że system Finanse będzie łatwiej na
jakiś czas wdrożyć w oparciu o istniejący system
magazynowy, a dopiero z czasem testować nowy. Takich
przykładów można podawać wiele. Jeszcze raz podkreślamy -
nie ma na to uniwersalnych reguł. W każdej sytuacji trzeba
przeprowadzać analizę od nowa. I tu uwidacznia się to, co
pisaliśmy wcześniej - by zaproponować właściwą strategię
musimy dobrze zrozumieć to, co już się dzieje u klienta.
Całość zagadnienia komplikuje fakt, że w większości
dużych wdrożeń, klient posiada już jakieś systemy
informatyczne, które pokrywają część obszarów. Na domiar
złego klient wcale nie musi chcieć wymienić ich wszystkich
może oczekiwać systemu, który będzie zbierał dane od
istniejących i wykonywał analizy na potrzeby zarządu. Wtedy
musimy dopisać różnego rodzaju interfejsy, które umożliwiają
zbieranie tych danych.
Ostatecznie możemy stwierdzić, że powyższe rozważania
mające na celu określenie czynników krytycznych sukcesu,
można podzielić na dwa etapy:
identyfikacjÄ™ projektu,
rozpoznanie zagrożeń dla projektu.
Z punktu widzenia wyznaczania czynników krytycznych
jest szczególnie istotne, by dla każdego z nich określić
zagrożenia z nim związane. Do zbioru czynników krytycznych
wkładamy wszelkiego rodzaju elementy, które mogą zagrozić
powodzeniu projektu. Dla przykładu - bardzo często
występującym czynnikiem jest niska kultura informatyczna
20
przyszłych użytkowników systemu12. Oczywistym
rozwiązaniem, które jest stosowane w celu zapobieżenia
problemom wypływającym z braku wiedzy jest organizacja
szkoleń podnoszących kwalifikacje przyszłych użytkowników.
Innym, występującym bardzo często (obok wymienionego
przed chwilą) czynnikiem krytycznym będzie nieufność lub
wręcz wrogość pracowników w firmie Inwestora. Często
postrzegają oni komputery jako zło konieczne, co gorsza jako
zagrożenie ich osób, uważają, że komputery doprowadzą do
redukcji zatrudnienia. Ponownie rolÄ… Inwestora - jest
uświadomienie, że informatyzacja nie oznacza zwolnienia
ludzi, a jedynie usprawnienia pracę13.
12 Poprzez kulturę rozumiemy tutaj zespół czynników tj.: wiedza,
doświadczenie, chęć rozwoju i  wiara w celowość stosowania nowych
technologii.
13 Chyba, że to właśnie redukcja zatrudnienia jest celem Inwestora, wtedy
ten argument nie jest słuszny.
21
2 Metodyka zarzÄ…dzania
projektem informatycznym
W rozdziale 1 mówiliśmy o różnicy pomiędzy projektem
a procesem. W skrócie proces to procedura pozwalająca
wykonywać coś znanego, a projekt jest ustanawiany by
stworzyć coś wcześniej niewystępującego, w którym nie ma
określonych procesów wytwórczych.
Tworzenie oprogramowania, choć wciąż nazywane jest
 projektowaniem , coraz częściej zamieniane jest w proces
produkcji. Szczególnie dobrze widać to na przykładzie
wdrożeń produktów oraz póz
niejszej eksploatacji
oprogramowania. Ta tendencja, odchodzenia od projektu w
stronÄ™ procesu, jest jak najbardziej naturalna. Wszystko, co
jest znane i zdefiniowane, jak w przypadku procesu
wytwórczego, łatwiej kontrolować, można określić
harmonogram prac i koszty przedsięwzięcia. Oczywiście
zawsze problemem w projektach informatycznych będzie
element niewiedzy związany choćby z niepewnością, co do
zakresu wymagań. Niemniej jednak dąży się do tego by jak
najwięcej działań usystematyzować w celu lepszej kontroli
nad nimi.
Już sama inżynieria oprogramowania przynosi nam wiele
podpowiedzi, jak tworzyć oprogramowanie - są to tak zwane
modele cyklu życia oprogramowania. Jednak jest to wiedza
22
zwiÄ…zana z technologiÄ… wytwarzania - nas zaÅ› interesuje
bardziej proces zarzÄ…dzania. Tu na pomoc przychodzÄ…
różnego rodzaju metodyki zarządzania procesem
wytwórczym, przykładowe omówimy w dalszych punktach
niniejszego rozdziału. Wpierw jednak opisany zostanie ogólnie
cykl tworzenia oprogramowania z uwzględnieniem procesów
zwiÄ…zanych z zarzÄ…dzaniem.
2.1 Zarządzanie tworzeniem systemów
informatycznych
W ramach inżynierii oprogramowania wyróżnia się wiele
cykli życia oprogramowania, których celem jest
uporządkowanie prac wytwórczych, dzięki czemu można
łatwiej planować i kontrolować. My skupimy się wyłącznie na
modelu kaskadowym, jako cyklu referencyjnym dla innych i
na jego podstawie pokażemy, w których miejscach pojawiają
siÄ™ konkretne obszary zarzÄ…dzania.
Przypomnijmy, że model kaskadowy składa się
z następujących faz: analiza, projektowanie, kodowanie
(implementacja), testowanie. W praktyce często dodaje się na
końcu fazę instalacji (wdrożenia), i w zależności od umowy
również fazę konserwacji. Jeśli jednak dobrze się przyjrzeć
projektom realizowanym, to okaże się, że większość z nich
jest poprzedzona tzw. fazÄ… strategicznÄ…. Celem tej fazy jest
podjęcie decyzji o ustanowieniu projektu, stąd też bywa tak,
że jest to faza ostatnia, gdyż może sie okazać, że projekt jest
nie realny (przyczyny w tym miejscu pomijamy). Dodatkowo
przez cały czas trwanie projektu realizowanie są równolegle
dwie dodatkowe fazy: dokumentacji i zarzÄ…dzania. Graficznie
można to zobrazować jak na poniższym rysunku.
23
Rys 2. Model kaskadowy z uwzględnieniem dodatkowych faz związanych
z zarzÄ…dzaniem.
[Opracowanie własne]
Przy czym nam wygodniej będzie traktować, że faza
zarzÄ…dzania nie jest czymÅ› oddzielnym, a przenika wszystkie
inne fazy. Omówimy teraz po kolei obszary zarządzania
projektem, z którymi możemy mieć do czynienia we
wszystkich wymienionych fazach.
Faza strategiczna. Wszystkie działania skupione są
wokół pytania: czy projekt ma sens, czy jest on realny?
Odpowiedzi na to pytanie mają ścisły związek z tym, co
pisaliśmy wcześniej. Inwestor powinien zdawać sobie sprawę,
czy to, co zamierza osiągnąć jest właściwe i uzasadnione
ekonomicznie. Wykonawca jest mu potrzebny by osadzić
przedsięwzięcie w realiach technologicznych. Może się
okazać, że dane rozwiązanie jest możliwe technicznie, ale tak
drugie, że dla Inwestora nieopłacalne.
Przy bardzo dużych projektach bywa tak, że faza ta jest
wręcz wydzielone z reszty. W tym celu powołuje sie grupę
ekspertów lub też zleca się przeprowadzenie takiej analizy
firmie konsultingowej. Dopiero wynik prac tych osób jest
podstawą do podjęcia dalszych działań - w szczególności
poszukiwania konkretnego wykonawcy.
Z puntu widzenia zarzÄ…dzania ta faza jest bardzo istotna,
gdyż pozwala odpowiedzieć na pytanie  Czy projekt w ogóle
się rozpocznie ?  . W dalszej części będziemy mogli wstępnie
znać ramy czasowe i budżet. Wszystko to pozwoli oszacować
ile i jakie zasoby14 będą nam potrzebne do realizacji zadania.
14 Poprzez zasoby będziemy zawsze rozumieli wszelkie zasoby, zarówno
24
Na tym etapie spoczywa również duża odpowiedzialność na
decydentach po stronie wykonawczy, gdyż powinni oni umieć
zrobić rachunek sumienia i uczciwie odpowiedzieć, sobie i
Inwestorowi na pytanie, czy podołają temu zadaniu15.
Faza analizy. W tej części odpowiadamy na pytanie: co
należy wykonać? Jednak nie wolno nam poprzestać na
lakonicznej odpowiedzi: program! Musimy zadać pytania o
najdrobniejsze szczegóły dotyczące zarówno funkcjonalności,
jak i aspektów niefunkcjonalnych. Wszystko po to, by na
podstawie tego umieć sporządzić schemat przyszłej aplikacji i
przekazać go do dalszego uszczegółowienia przez
projektantów16.
Kierownik projektu ma w tej fazie możliwość weryfikacji
wcześniej stworzonego harmonogramu prac. Jest to dobra
okazja do weryfikacji wcześniejszych założeń i identyfikacji
pierwszych zagrożeń dla powodzenia projektu. Nie należy
lekceważyć tej fazy, ani też jej bagatelizować, choć jest to
kuszące, gdyż zaangażowanie osób, po stronie wykonawcy, w
tym miejscu projektu jest niewielkie17. Skoro niewiele osób
pracuje, i to zwykle o najwyższych kompetencjach i
kwalifikacjach, to można dojść do wniosku, że nie należy
przejmować się pilnowaniem prac. Jest to bardzo zgubne
założenie. Być może faktycznie osoby te będą z powodzenie
pracować samodzielnie, jednak rolą kierownika jest nie tylko
pilnowanie, czy pracownicy wykonujÄ… swoje zadania, ale
również zbieranie z wszelkich z
ródeł zagrożeń i ustalanie
z komitetem sterujÄ…cym co dalej.
Co więcej, w tej fazie należy podjąć działania
ludzkie jak i sprzętowe czy oprogramowanie, więcej na ten temat w
rozdziale 4.
15 Niestety praktyka pokazuje co innego, często firmy porywają sie na
zadania daleko przekraczające ich możliwości realizacji.
16 Więcej o fazie analizy można znalez
ć np. w [Sobieski 2005].
17 Wszak analitycy po plus konsultanci to zaledwie kilka osób, rzadko
zdarza się by analizę przeprowadzała grupa więcej niż
kilkunastoosobowa, gdyż bardzo trudno w tak dużej grupie jest zebrać
dane i opracować wspólną wizję.
25
przygotowawcze do dalszych etapów, zorganizować pracę
potrzebnych ludzi, być może dokupić lub wypożyczyć sprzęt i
oprogramowanie. Zlecić przygotowanie miejsc pracy (jeśli
takie nie istnieją) oraz przypilnować by stworzono
odpowiednią infrastrukturę techniczną. I nie mniej ważne
stałe informowanie Inwestora o postępach prac.
Faza projektowania. Wynikiem tego etapu powinien być
kompletny projekt techniczny zawierajÄ…cy, w uproszczeniu,
projekt bazy danych, funkcji, ekranów, raportów, innych
wydruków, przepływu danych, eksportu i importu oraz wielu
innych. Można w dużym uproszczeniu powiedzieć, że w
wyniku tego etapu powinniśmy umieć odpowiedzieć na
pytanie: jak TO18 należy wykonać?
Faza implementacji. Etap ten poświęcony jest
wytworzeniu programu jako takiego, nazywa się go również
kodowaniem czy programowaniem. Należy jednak pamiętać,
że nie tylko programowanie wchodzi w skład tego etapu,
również dokumentowanie, walidacja i wiele innych. Co więcej
najczęściej uwzględnia również się integrację z innymi
systemami.
Faza testowania. Na tym etapie dokonujemy wszelkiego
rodzaju testów, by upewnić się, że produkt spełnia
wymagania użytkownika przy założonej niezawodności.
Należy pamiętać, że powyższe etapy występują właściwie
w każdym projekcie informatycznym, niezależnie od
przyjętego cyklu życia oprogramowania. Z tym, że dotyczy to
projektów w których tworzymy program. W przypadku
projektu o charakterze wdrożeniowym etapy te zmieniają się
np. w następujący sposób.
Faza strategiczna. Podobnie jak wcześniej jest to etap
zorientowany na decyzję czy projekt jest realny. Oczywiście
wymaga zebrania mnóstwo informacji o wymaganiach
biznesowych klienta oraz jego oczekiwaniach.
18 TO  wszystko, co wydobyli analitycy od klienta o przyszłym systemie.
26
Faza analizy. W tym etapie zbieramy wszelkiego rodzaju
szczegóły dotyczące potrzeb klienta. Na ich podstawie tworzy
się dokładny harmonogram wdrożenia oraz jego budżet, wraz
ze specyfikacją niezbędnych zasobów (tak ludzkich jak i
sprzętowo-programowych).
Faza integracji. Właściwe wdrożenie, zwykle składające
się z instalacji i integracji sprzętu. W dalszej części instalacji
zasadniczego oprogramowania, następnie jego konfiguracji i
parametryzacji. Na sam koniec prowadzi siÄ™ szkolenia
personelu za zakresu użytkowania oraz administracji
systemem.
Faza wsparcia. Działania na tym etapie koncentrują się
wokół poprawy błędów w programie, oraz, o ile tak
postanowiono, wprowadzania modyfikacji. Długość tej fazy
zależy od umowy jaka została zawarta pomiędzy
kontrahentami. Czasami obejmuje ona pewien umowny czas
 gwarancji 19, a często w dużych systemach jest to
długoletnia umowa o współpracy.
Poniżej przedstawiamy metodologię związane jedynie z
tworzeniem oprogramowania.
2.2 Project Management Institute
Właściwą część metodologii PMI czyli PMBoK stanowi 9
obszarów wiedzy, są to:
1. ZarzÄ…dzanie integracjÄ… projektu.
2. ZarzÄ…dzanie zakresem.
3. ZarzÄ…dzanie czasem.
4. ZarzÄ…dzanie kosztami.
5. Zarządzanie jakością.
6. ZarzÄ…dzanie zasobami ludzkimi.
7. ZarzÄ…dzanie komunikacjÄ….
19 Gwarancja jest czymś bardzo płynnym w przypadku oprogramowania,
zwykle producenci oprogramowania, nie gwarantują bezbłędności
działania aplikacji, a jedynie deklarują, że będą usuwali błędy.
27
8. ZarzÄ…dzanie ryzykiem.
9. ZarzÄ…dzanie zaopatrzeniem.
Omówimy je w kolejnych podpunktach.
2.2.1 ZarzÄ…dzanie integracjÄ… projektu
Proces zajmuje się prawidłową koordynacją różnych
elementów projektu. Obejmuje dokonywanie wyborów między
celami by zaspokoić oczekiwania udziałowców projektu.
ZarzÄ…dzanie integracjÄ… jest wymagane w projektach, gdzie
mamy do czynienia z następującymi sytuacjami: w projekcje
następuje łączenie różnych dziedzin, uwzględnia się udział
osób trzecich jak (specjalistów czy audytorów) oraz gdzie
konieczne jest uzgodnienie zakresu produktu z zakresem
projektu itp.
Obszar ten składa się z następujących procesów:
Tworzenie planu projektu.
Proces ten powtarzalny jest wielokrotnie w trakcie
całego trwania projektu. Prowadzi do utworzenia
zbiorczego dokumentu, który jest używany jako
instrukcja do wykonywania projektu oraz narzędzie jego
kontroli. Plan projektu zawiera zbiór założeń
projektowych, ustalenie komunikacji między
udziałowcami, określenie głównych przeglądów na
poziomie kierownictwa, dotyczÄ…cych rozmiaru czasu
i zawartości projektu.
Wejścia do etapu tworzenia planu projektu:
Ë% polityki organizacyjne firm współpracujÄ…cych przy
danym projekcie,
Ë% zapisy historyczne z poprzednio przeprowadzonych
projektów,
Ë% ograniczenia naÅ‚ożone na czas, budżet i zakres
projektu,
Ë% zaÅ‚ożenie poczynione przed rozpoczÄ™ciem projektu
(potencjalne z
ródło zagrożeń).
Wyjścia z etapu tworzenia planu projektu:
28
Ë% plan projektu - bÄ™dÄ…cy formalnie zatwierdzonym
dokumentem używanym do nadzoru i zarządzania
projektem. Może ulegać modyfikacji oraz
uszczegóławianiu na skutek dostarczania
dodatkowych informacji. Istnieje wiele sposobów
jego prezentowania choć zwykle zawierających
podobne elementy
. Zwykle sÄ… nimi:
Ë% karta projektu - opis strategii oraz struktury
organizacyjnej projektu,
Ë% okreÅ›lenie zakresu, zasobów oraz celów,
Ë% opis hierarchii podziaÅ‚u prac, główny i wymagany
personel,
Ë% okreÅ›lone zasady prowadzenia pomiarów
podstawowych założeń (czas, budżet, zakres),
Ë% kamienie milowe wraz z ich planowanymi terminami
oraz podrzędne plany,
Ë% główne czynniki ryzyka wraz z opisem dziaÅ‚aÅ„
podejmowanych na wypadek ich wystÄ…pienia,
Ë% informacje dodatkowe, wspomagajÄ…ce  wszelkie
informacje nieujęte w planie, dokumentacja
tworzona w czasie realizacji projektu, dokumentacja
techniczna, normy i certyfikaty.
Narzędzia wspomagające realizację procesu:
Ë% wybrana metodologia tworzenia oprogramowania 
dostosowana procedura prowadzenia grupy
projektowej podczas tworzenia planu projektu,
Ë% doÅ›wiadczenie i wiedza poszczególnych uczestników
projektu,
Ë% system informacyjny zarzÄ…dzania projektami 
narzędzia i techniki mające na celu zbieranie,
integracjÄ™ oraz selekcjÄ™ informacji z innych
procesów.
Wykonywanie planu projektu.
Jest podstawowym procesem realizacji planu, w czasie
jego trwania wykorzystywana jest większość budżetu.
Koordynatorem wykonywania planu jest zespół
projektowy. Podobnie jak w poprzednim projekcie
29
zwrócimy uwagę na wejścia, wyjścia z projektu oraz
narzędzie ku temu służące.
Wejścia do procesu realizacji planu:
Ë% plan projektu,
Ë% informacje projektowe zgromadzone podczas
poprzedniego etapu,
Ë% dziaÅ‚ania korygujÄ…ce  wynikajÄ…ce z procesów
kontroli i nadzoru, majÄ…ce na celu realizowanie planu
projektowego rozszerzonego o powstałe zmiany.
Wyjścia z procesu realizacji planu:
Ë% wyniki realizacji planu niezbÄ™dne do procesu
raportowania,
Ë% żądania zmian, jakie zidentyfikowano w czasie
realizacji planu.
Narzędzia wspomagające realizację procesu:
Ë% wrodzone lub nabyte umiejÄ™tnoÅ›ci zarzÄ…dcze,
kompletna wiedza o produkcie,
Ë% stosowany system autoryzacji, zapewniajÄ…cy
właściwe i czasowe wykonanie produktów,
Ë% regularne spotkania przeprowadzane w celu
wymiany informacji,
Ë% formalne i nieformalne procedury wykorzystywane
podczas wykonywania projektu,
Ogólny nadzór zmian.
Proces ma na celu zarzÄ…dzanie zmianami, jakie
następują oraz wpływaniem na czynniki powodujące, że
zmiany przynoszą korzyści. Warto nadmienić, że
wszystkie zmiany wpływają na plan, ale tylko zmiany
zakresu mogą spowodować zmianę realizacji planu.
Dlatego należy zwrócić szczególną uwagę, aby nie
nastąpiła różnica między zakresem projektu a zakresem
produktu. Należy również koordynować zmiany ze
wszystkimi obszarami wiedzy, aby nie nastąpiły
sprzeczności.
Wejścia do procesu ogólnego nadzoru zmian:
Ë% plan projektu,
Ë% raporty wykonania,
30
Ë% żądania zmian.
Wyjścia z procesu ogólnego nadzoru zmian:
Ë% zmiany do planu projektu,
Ë% udokumentowana wiedza zdobyta podczas
rozwiązywania problemów.
Narzędzia wspomagające realizację procesu:
system nadzoru zmian  opracowane procedury i wzory
dokumentów, które wskazują, w jaki sposób należy
przeprowadzać zmiany. Obejmuje on także skróconą
ścieżkę dla nagłych zmian, zagrożeń czy wypadków,
zarzÄ…dzanie konfiguracjÄ… - procedura wspomagajÄ…ca
akceptację kierunków technicznych i administracyjnych,
przeprowadzanie pomiarów  wykorzystuję się w tym
narzędzia dostarczane z ekonomi np. zwrot z inwestycji.
Pomiary służą podejmowaniu decyzji o konieczności
wprowadzenia zmian korygujÄ…cych,
dodatkowe planowanie,
system informacyjny.
2.2.2 ZarzÄ…dzanie zakresem
Proces ma na celu skupienie uwagi na kontroli zakresu
projektu. Dba o to, aby wszystkie prace, które zawiera
projekt, zostały wykonane. Zakres produktu to funkcje i
udogodnienia, które mają być zawarte w produkcie.
Natomiast zakres projektu obejmuje pracę, która musi zostać
wykonana w celu dostarczenia produktu posiadajÄ…cego
określone funkcje i udogodnienia. Zarządzanie zakresem
można rozpatrywać w podziale na następujące etapy:
Inicjacja.
Etap uważany często za formalne rozpoczęcie projektu
lub też moment przejścia do następnej fazy projektu.
Zdarza się, że w wewnętrznych projektach formalne
rozpoczęcie uważane jest dopiero w chwili wykonania
pewnej części pracy, która wymagana jest do uzyskania
zgody na kontynuacjÄ™. Projekty sÄ… zwykle zatwierdzane
w wyniku: stwierdzonego popytu na rynku (dla
31
zaspokojenia popytu), potrzeby biznesu (np. możliwość
osiągnięcia wyższych zysków), żądanie klienta (np.
budowa zintegrowanego systemu zarzÄ…dzania sieciÄ…
hurtowni), postęp technologiczny, wymagania prawne.
Wejścia do procesu inicjacji:
Ë% charakterystyka i opis projektu,
Ë% plan strategiczny wspomagajÄ…cy realizacjÄ™ celów,
Ë% informacje ekonomiczne, historyczne i spoÅ‚eczne
zwiÄ…zane z produktem.
Wyjścia z procesu inicjacji:
Ë% karta projektu zawierajÄ…ca opis produktu oraz
informacje o przyczynach podjęcia projektu,
Ë% menadżer projektu (Kierownik Projektu) - wybierany
przed rozpoczęciem wykonywania planu. Zaleca się
wybranie menadżera jeszcze przed planowaniem
projektu,
Ë% ograniczenia,
Ë% zaÅ‚ożenia.
Narzędzia wspomagające realizację procesu:
Ë% metody wyboru projektu  należące do jednej z
dwóch kategorii: pomiaru korzyści lub optymalizacji,
Ë% metody eksperckie  wykorzystywane przy
szacowaniu wejść.
Planowanie zakresu.
Na tym etapie tworzony jest dokument określający
zakres, jako podstawę do przyszłych decyzji. Dokument
zawiera również określone kryteria wykonania fazy.
Jeżeli projekt ma podprojekty, dla nich także musi
zostać określony zakres na tych samych zasadach.
Wejścia do procesu planowania zakresu:
Ë% opis produktu,
Ë% karta projektu,
Ë% ograniczenia i zaÅ‚ożenia.
Wyjścia z procesu planowania zakresu:
Ë% deklaracja zakresu  zawiera krótki opis projektu,
listę pod produktów, cele projektu wyrażone poprzez
kryteria mierzalne: czas, budżet, jakość,
32
Ë% plan zarzÄ…dzania zakresem - dokument opisujÄ…cy
zarzÄ…dzanie projektem. Zawiera m.in. informacje o
sposobie wprowadzania i ogłaszania zmian.
Narzędzia wspomagające realizację procesu:
Ë% analiza produktu - majÄ…ca na celu lepsze poznanie
produktu,
Ë% analiza korzyÅ›ci i kosztów,
Ë% burza mózgów - poszukiwanie dostÄ™pnych
alternatyw,
Ë% sÄ…dy ekspertów.
Definicja zakresu.
Etap, w którym należy podzielić główne elementy
projektu, określone w deklaracji zakresu, na mniejsze,
łatwiejsze w zarządzaniu oraz kontroli kosztów,
terminów i zasobów.
Wejścia do procesu definicji zakresu:
Ë% deklaracja zakresu,
Ë% ograniczenia, zaÅ‚ożenia,
Ë% informacje historyczne.
Wyjścia z procesu definicji zakresu:
Ë% struktura projektu  okreÅ›lajÄ…ca zakres projektu.
Wszystkie sytuacje nieuwzględnione w strukturze są
wyjściem poza zakres projektu. Często tak
przygotowany dokument zawiera słownik definicji,
ułatwiający zrozumienia zakresu projektu.
Narzędzia wspomagające realizację procesu:
Ë% zakres struktury projektu,
Ë% dekompozycja  podziaÅ‚ projektu na mniejsze
elementy.
Weryfikacja zakresu.
Po zdefiniowaniu zakresu wymagane jest jego
zatwierdzenie przez jego sponsorów, klientów,
udziałowców. Etap ten zakłada przegląd produktów i
wyników pracy w celu sprawdzenie poprawności ich
wykonania. Weryfikacja zakresu różni się od kontroli
jakości tym, że zwraca uwagę bardziej na akceptację
niż na poprawność pracy.
33
Wejścia do procesu weryfikacji:
Ë% wyniki pracy i dokumentacja produktu.
Wyjścia z procesu definicji zakresu:
Ë% formalne zatwierdzenie zakresu.
Narzędzia wspomagające realizację procesu:
Ë% nadzór obejmujÄ…cy pomiary, badania, testy (audyt)
Nadzór zmian zakresu.
Proces podobny do ogólnego nadzoru zmian.
Wejścia do procesu weryfikacji:
Ë% raport wykonania,
Ë% zgÅ‚oszone żądania zmian,
Ë% plan zarzÄ…dzania zakresem.
Wyjścia z procesu definicji zakresu:
Ë% dziaÅ‚ania naprawcze.
Narzędzia wspomagające realizację procesu:
Ë% system nadzoru zmian zakresu,
Ë% dodatkowe planowanie,
Ë% pomiary wykonania.
2.2.3 ZarzÄ…dzanie czasem
ZarzÄ…dzanie czasem w projekcie zawiera wszelkie procesy,
jakie należy wykonać by zakończyć projekt w planowanym
czasie. Obszar ten obejmuje:
Definiowanie działań, które muszą zostać
wykonane dla osiągnięcia celów projektu.
Obejmują one identyfikację i dokumentację działań
podjętych w celu wykonania produktów.
Wejścia do procesu:
Ë% struktura projektu,
Ë% deklaracja zakresu,
Ë% ograniczenia i zaÅ‚ożenia.
Wyjścia z procesu:
Ë% lista dziaÅ‚aÅ„  zawierajÄ…ca wszystkie dziaÅ‚ania
przewidziane w projekcie. Lista jest rozszerzeniem
struktury projektu,
Ë% dokumentacja wszystkich stwierdzonych ograniczeÅ„
34
i założeń,
Ë% zmiany do struktury projektu  np. jeÅ›li wykryto
działania nie zawarte w strukturze.
Narzędzia wspomagające realizację procesu:
Ë% dekompozycja  na poszczególne kroki, a nie - jak w
procesie definiowania - na namacalne elementy,
Ë% szablony - listy dziaÅ‚aÅ„ z poprzednich podobnych
projektów,
Określenie następstw i zależności między
działaniami.
Działania podejmowane podczas realizacji projektu
muszą mieć zachowaną kolejność. To właśnie na tym
etapie opracowuje się następstwa wykonywania
poszczególnych czynności tak, aby możliwe było
przygotowanie harmonogramu. Często w tym celu
wykorzystuje się narzędzia programistyczne.
Wejścia do procesu:
Ë% lista dziaÅ‚aÅ„,
Ë% opis produktu,
Ë% konieczne zależnoÅ›ci  obejmujÄ… ograniczenia
fizyczne,
Ë% dozwolone zależnoÅ›ci  okreÅ›lone przez zespół
projektowy. Zalecane jest dokładne ich
dokumentowanie w celu póz
niejszego zarzÄ…dzania
zmianami.
Wyjścia z procesu:
Ë% diagram sieci projektu  schemat przedstawiajÄ…cy
działania w projekcie, pogrupowane w logiczne
całości,
Ë% zmiany listy dziaÅ‚aÅ„.
Narzędzia wspomagające realizację procesu:
Ë% metoda diagramów nadrzÄ™dnoÅ›ci (PDM) - metoda
polegajÄ…ca na konstruowaniu sieci projektu przy
użyciu symboli reprezentujących działania i
łączących je strzałek. Zawiera ona następujące
relacje:  skończyć, aby zacząć - działanie A musi
się skończyć, aby działanie B mogło się zacząć,
35
 skończyć, aby skończyć - działanie A musi się
skończyć, aby działanie B mogło się skończyć,
 zacząć, aby zacząć - działanie A musi się zacząć,
aby działanie B mogło się zacząć,  zacząć, aby
skończyć - działanie A musi się zacząć, aby
działanie B mogło się skończyć,
Ë% metoda diagramów strzaÅ‚kowych (ADM) - strzaÅ‚ki
reprezentują działania, a punkty - zależności. W tej
metodzie używamy jedynie relacji  skończyć, aby
zacząć ,
Ë% metody diagramów zależnych - techniki
diagramowania, jak GERT i modelowanie systemów
dla niesekwencyjnych działań (np. pętli). ADM i PDM
nie pozwalają na pętle,
Ë% szablony sieci - mogÄ… być używane, gdy elementy
projektu sÄ… identyczne i powtarzajÄ… siÄ™ (np. budowa
stropu w wieżowcu).
Szacowanie czasu potrzebnego dla wykonania
poszczególnych działań.
Proces ma na celu oszacowanie liczbę dni, miesięcy itp.
przewidywanych do wykonania poszczególnych zadań.
Osoba, która najwięcej wie o pracochłonności i
specyfice poszczególnych zadań, estymuje czas ich
trwania (należy pamiętać o uwzględnieniu świąt i dni
wolnych).
Wejścia do procesu:
Ë% lista dziaÅ‚aÅ„,
Ë% ograniczenia,
Ë% zależnoÅ›ci,
Ë% wymagane zasoby i możliwoÅ›ci ich wykorzystania 
wszelkie działa wymagają pewnego zaplecza (np.
sprzęt, doświadczenie pracowników), to zaplecze
należy uwzględnić przy szacowaniu czasu.
Wyjścia z procesu:
Ë% szacunki czasu trwania poszczególnych dziaÅ‚aÅ„,
Ë% dokumentacja z oszacowaÅ„.
Narzędzia wspomagające realizację procesu:
36
Ë% metody eksperckie  opierane na doÅ›wiadczeniu
innych projektantów,
Ë% porównywanie podobnych dziaÅ‚aÅ„, jakie wystÄ…piÅ‚y
we wcześniejszych projektach,
Ë% symulacje  np. metoda Monte Carlo.
Tworzenie terminarza.
Proces obejmuje stworzenie terminarza na podstawie
zebranych we wcześniejszych etapach informacji.
Bardzo ważne jest dokładne oszacowanie dat, ponieważ
wszelkie niedokładności będą wpływać na przesunięcie
momentu ukończenia projektu.
Wejścia do procesu:
Ë% diagramy projektu,
Ë% czasy dziaÅ‚aÅ„,
Ë% wymagane zasoby,
Ë% kalendarze,
Ë% zaÅ‚ożenia,
Ë% ograniczenia, przyspieszenia i opóz
nienia.
Wyjścia z procesu:
Ë% terminarz projektu - zawierajÄ…cy co najmniej terminy
rozpoczęć i zakończeń poszczególnych działań,
Ë% plan zarzÄ…dzania terminarzem,
Ë% zmiany do wymaganych zasobów.
Narzędzia wspomagające realizację procesu:
Ë% analizy matematyczne  na ich podstawie oblicza siÄ™
teoretyczne terminy rozpoczęcia i zakończenia
działań, które są podstawą do stworzenia
terminarza,
Ë% symulacje,
Ë% programy wspomagajÄ…ce zarzÄ…dzanie projektami,
Ë% kompresja czasu trwania  zadania majÄ…ce na celu
maksymalne skrócenie czasu trwania każdego z
zadań.
Kontrola terminów.
To działania mające na celu wpływanie na czynniki,
które mogą spowodować zmiany, a w konsekwencji
opóz
nienia w realizacji projektu.
37
Wejścia do procesu:
Ë% terminarz projektu,
Ë% raporty wykonania,
Ë% żądania zmian,
Ë% plan zarzÄ…dzania terminarzem.
Wyjścia z procesu:
Ë% szacunki czasu trwania poszczególnych dziaÅ‚aÅ„,
Ë% dokumentacja z oszacowaÅ„.
Narzędzia wspomagające realizację procesu:
Ë% zmiany terminarza,
Ë% dziaÅ‚ania korygujÄ…ce,
Ë% nabyta wiedza.
2.2.4 ZarzÄ…dzanie kosztami
Celem zarzÄ…dzania kosztami jest realizacja projektu,
zgodna z przewidzianym budżetem. Proces ten skupia swoją
uwagę głównie na na zasobach potrzebnych do realizacji
projektu. Zaleca się również zwrócenie uwagi na póz
niejszy
koszt użytkowania wytworzonego produktu. Zarządzanie
kosztami obejmuje:
Planowanie zasobów ludzkich, materiało
wych i
maszynowych.
Polega na wskazaniu, jakie fizyczne zasoby oraz w
jakich ilościach, zostaną wykorzystane do wykonania
projektu.
Wejścia do procesu:
Ë% struktura projektu,
Ë% informacje historyczne,
Ë% deklaracja zakresu,
Ë% opis dostÄ™pnoÅ›ci zasobów,
Ë% polityki organizacyjne.
Wyjścia z procesu:
Ë% opis zasobów potrzebnych w projekcie wraz iloÅ›ciÄ… i
miejscem ich przeznaczenia.
Narzędzia wspomagające realizację procesu:
Ë% metody eksperckie  wykorzystywanie wiedzy
38
zewnętrznych kooperantów, dostawców,
konsultantów,
Ë% poszukiwanie alternatyw.
Szacowanie kosztów zasobów.
Proces ma na celu oszacowanie Å‚Ä…cznych oraz
jednostkowych kosztów, jakie pochłoną
wykorzystywane zasoby. Należy rozpatrywać koszty w
relacji koszt-cena, gdyż ma to wpływ na łączny zysk z
produktu.
Wejścia do procesu:
Ë% struktura projektu,
Ë% wymagane zasoby,
Ë% harmonogram dziaÅ‚aÅ„,
Ë% opis dostÄ™pnoÅ›ci zasobów,
Ë% cenniki zasobów,
Ë% struktura kont ksiÄ™gowych  prognozowane koszty
przypisywane są do właściwych kategorii.
Wyjścia z procesu:
Ë% szacunkowe koszty  koszty przyjÄ™to wyrażać w
jednostkach pieniężnych dla ułatwienia porównań
między różnymi projektami,
Ë% dokumentacja podstaw wyliczeÅ„ oraz opis prac
estymacyjnych.
Narzędzia wspomagające realizację procesu:
Ë% estymowanie analogii,
Ë% modelowanie parametryczne  wykorzystuje
charakterystyki projektu do przewidywania kosztów
projektu w modelu matematycznym,
Ë% estymacja szczegółowa  estymacja polega na
szacowaniu samodzielnych elementów, po czym
uzyskane dane szacunkowe sumuje siÄ™ otrzymujÄ…c w
ten sposób sumę kosztów projektu.
Budżetowanie.
Rozmieszczenie ogólnych szacunków kosztów do
poszczególnych elementów pracy, co umożliwi
mierzenie wykonania projektu.
Wejścia do procesu:
39
Ë% szacunki kosztów,
Ë% struktura projektu,
Ë% terminarz projektu,
Ë% opis dostÄ™pnoÅ›ci zasobów,
Ë% cenniki zasobów,
Ë% struktura kont ksiÄ™gowych  prognozowane koszty
przypisywane są do właściwych kategorii.
Wyjścia z procesu:
Ë% ogólny poziom kosztów  przedstawiony za pomocÄ…
krzywej na wykresie zależności kosztu od czasu.
Narzędzia wspomagające realizację procesu:
Ë% narzÄ™dzia i techniki estymacji kosztów.
Kontrola kosztów w budżecie.
Ściśle powiązana z ogólnym nadzorem zmian. Celem
kontroli jest monitorowanie wykonania kosztów,
zapobieganie niewłaściwym zmianom oraz prawidłowe
wprowadzanie koniecznych zmian.
Wejścia do procesu:
Ë% ogólny poziom kosztów,
Ë% raporty wykonania,
Ë% deklaracja zakresu,
Ë% żądania zmian,
Ë% plan zarzÄ…dzania zmianami.
Wyjścia z procesu:
Ë% zmiany do szacunków kosztów,
Ë% zmiany w budżecie,
Ë% prognoza kosztu projektu.
Narzędzia wspomagające realizację procesu:
Ë% system nadzoru zmian kosztów,
Ë% pomiary wykonania,
Ë% dodatkowe planowanie,
Ë% oprogramowanie.
2.2.5 Zarządzanie jakością
Obejmuje wszelkie czynności, które mają zapewnić, że
projekt spełni oczekiwania klienta. Ponadto wszelkie projekty,
40
oprócz akceptacji klienta - muszą być zgodne z serią norm
dotyczących jakości ISO 9000 (norma ISO 10007 opisuje
warunki spełnienia jakości w obszarze zarządzania
projektami). Obszar zarządzania jakością obejmuje:
Planowanie jakości.
Zidentyfikowanie normy jakości, jaką musi spełnić
projekt oraz zaplanowanie w jaki sposób zrealizować
wymagania w projekcie.
Wejścia do procesu:
Ë% polityka jakoÅ›ci,
Ë% deklaracja zakresu,
Ë% deklaracja zakresu,
Ë% opis produktu,
Ë% normy i regulacje.
Wyjścia z procesu:
Ë% plan zarzÄ…dzania jakoÅ›ciÄ…,
Ë% wyznaczone terminy kontroli,
Ë% check-listy  majÄ… na celu weryfikacjÄ™ okreÅ›lonych
kroków.
Narzędzia wspomagające realizację procesu:
Ë% benchmarking - polega na porównywaniu procesów i
praktyk stosowanych przez własne przedsiębiorstwo
ze stosowanymi w przedsiębiorstwach uważanych za
najlepsze w analizowanej dziedzinie. Wynik takiej
analizy służy jako podstawa doskonalenia procesów
biznesowych,
Ë% analiza korzyÅ›ci i kosztów.
Zapewnianie jakości.
Systematyczne wdrażanie zaplanowanych działań
mających na celu doprowadzenie projektu do końca tak,
aby spełniał normy jakości.
Wejścia do procesu:
Ë% plan zarzÄ…dzania jakoÅ›ciÄ…,
Ë% wyniki pomiarów jakoÅ›ci,
Ë% definicje operacyjne.
Wyjścia z procesu:
41
Ë% doskonalenie jakoÅ›ci w projekcie zwiÄ™kszajÄ…ce
korzyści dla klientów projektu.
Narzędzia wspomagające realizację procesu:
Ë% narzÄ™dzia i techniki planowania jakoÅ›ci,
Ë% audyty jakoÅ›ci.
Kontrola jakości.
Monitorowanie rezultatów projektu czy spełniają one
odpowiednie normy.
Wejścia do procesu:
Ë% wyniki pracy,
Ë% plan zarzÄ…dzania jakoÅ›ciÄ…,
Ë% definicje operacyjne,
Ë% check-listy.
Wyjścia z procesu:
Ë% doskonalenie jakoÅ›ci,
Ë% zmiany na niezgodnych elementach,
Ë% dziaÅ‚ania korygujÄ…ce.
Narzędzia wspomagające realizację procesu:
Ë% inspekcja,
Ë% karty kontrolne sÅ‚użące do badania przebiegu
procesów,
Ë% próbkowanie i analiza,
Ë% analiza trendu,
Ë% wykres Pareto - wskazuje na niekorzystne czynniki,
występujące w danym projekcie lub organizacji.
Pokazuje co należy naprawić, na czym się skupić, by
poprawić jakość, a co należy pominąć, gdyż i tak nie
można tego zmienić.
2.2.6 ZarzÄ…dzanie zasobami ludzkimi
Proces obejmuje czynności służące efektywnemu
wykorzystywaniu zasobów ludzkich w projekcie (pracowników,
klientów, kooperantów i sponsorów). Na temat zarządzania
ludz
mi powstało wiele publikacji z zakresu negocjacji,
motywacji, montoringu, budowy zespołów, rozwiązywania
konfliktów, relacji w pracy, które wykorzystywane są w
42
zarządzaniu projektami przez menadżerów personalnych.
Należy jednak zwrócić uwagę że projekty informatyczne maja
charakter czasowy, a więc należy uwzględnić specyfikę tej
działalności. Liczba uczestników może się zmieniać, gdy
projekt przechodzi przez kolejne etapy. ZarzÄ…dzanie zasobami
ludzkimi dzielimy na:
Planowanie organizacyjne.
Proces występuje zazwyczaj w początkowej fazie
projektu i zajmuje sie identyfikacjÄ…, dokumentacjÄ… oraz
przydzielaniem odpowiedzialności za kolejne fazy
projektu poszczególnym pracownikom. Czasem proces
może być powtarzany także w póz
niejszych fazach w
formie przeglÄ…du personelu.
Wejścia do procesu:
Ë% wyniki pracy,
Ë% plan zarzÄ…dzania jakoÅ›ciÄ…,
Ë% definicje operacyjne,
Ë% check-listy.
Wyjścia z procesu:
Ë% doskonalenie jakoÅ›ci,
Ë% zmiany na niezgodnych elementach,
Ë% dziaÅ‚ania korygujÄ…ce.
Narzędzia wspomagające realizację procesu:
Ë% inspekcja,
Ë% karty kontrolne sÅ‚użące do badania przebiegu
procesów,
Ë% próbkowanie i analiza,
Ë% analiza trendu,
Ë% wykres Pareto - wskazuje na niekorzystne czynniki,
występujące w danym projekcie lub organizacji.
Pokazuje co należy naprawić, na czym się skupić, by
poprawić jakość, a co należy pominąć, gdyż i tak nie
można tego zmienić.
Nabór personelu.
Zajmuje siÄ™ przydzielaniem ludzi do pracy w projekcie.
Wejścia do procesu:
43
Ë% plan zarzÄ…dzania personelem,
Ë% praktyki rekrutacji,
Ë% opis dostÄ™pnoÅ›ci personelu  opis możliwoÅ›ci
potencjalnych pracowników.
Wyjścia z procesu:
Ë% przyporzÄ…dkowany personel,
Ë% katalog zespoÅ‚u projektowego.
Narzędzia wspomagające realizację procesu:
Ë% nabycie  zatrudnianie zasobów ludzkich spoza
organizacji, jeżeli nie posiada ona pracowników
pochodzących z zasobów wewnętrznych,
Ë% wstÄ™pne przydzielanie,
Ë% negocjacje  rozmowy prowadzone z menadżerami
funkcjonalnymi, majÄ…ce na celu ustalenie
dostępności odpowiednich pracowników we
właściwym czasie,
Rozwój zespołu.
Ma na celu zwiększenie zdolności zespołu do pracy.
Często zdarza się, że pracownicy podlegają zarówno
szefowi zespołu, jak i kierownikowi funkcjonalnemu,
wówczas sukces projektu zależy od efektywności tego
podwójnego zarządzania.
Wejścia do procesu:
Ë% personel projektu,
Ë% plan projektu,
Ë% plan zarzÄ…dzania personelem,
Ë% raporty wykonania,
Ë% badania możliwoÅ›ci personelu.
Wyjścia z procesu:
Ë% doskonalenie wykonania  indywidualne zdobywanie
doświadczeń, lepsze drogi do osiągnięcia celu,
Ë% wejÅ›cie do oceny wykonania pracy zespoÅ‚u.
Narzędzia wspomagające realizację procesu:
Ë% doÅ›wiadczenie w budowaniu zespołów,
Ë% systemy nagradzania, uznania,
Ë% szkolenia doksztaÅ‚cajÄ…ce,
Ë% kolokacja  umieszczanie czÅ‚onków zespoÅ‚u w
44
jednym miejscu, w celu poprawienia ich zdolności
działania jako zespół.
2.2.7 ZarzÄ…dzanie komunikacjÄ…
Proces zarzÄ…dzania komunikacjÄ… ma na celu terminowe i
właściwe tworzenie, przechowywanie, rozpowszechnianie i
usuwanie wszelkich informacji w projekcie. Komunikacja jest
głównym środkiem potrzebnym do osiągnięcia sukcesu,
dlatego też każdy członek zespołu powinien potrafić odbierać
komunikaty, jak i samemu je formułować w sposób zrozumiały
dla odbiorcy. Należy zwrócić tu uwagę na modele nadawca-
odbiorca, pętle sprzężenia zwrotnego, bariery komunikacji,
rodzaj mediów używanych w komunikacji, metody zapisu,
techniki prezentacji, sposoby organizowania spotkań.
Zarządzanie komunikacją składa się z następujących
etapów:
planowanie komunikacji  wykonywane jako jedna z
pierwszych faz projektu. Obejmuje określanie potrzeb
informacyjnych uczestników.
Wejścia do procesu:
Ë% wymagania komunikacyjne  sÄ… one okreÅ›lone
przez typ, format wymaganej informacji z użyciem
analizy wartości tych informacji. Dane potrzebne do
określenia wymagań komunikacyjnych zwykle
zawierajÄ… siÄ™ w kilku punktach: powiÄ…zania
odpowiedzialności projektu i uczestników, dziedziny i
działy włączone w projekt, informacje o ilości i
rozmieszczeniu uczestników.
Ë% technologia komunikacji  techniki i metody
wykorzystywane w przekazywaniu informacji.
Określenie czasu dostarczania informacji,
dostępnych technologii, zasobów ludzkich i ich
zdolności do obsługi systemu.
Ë% ograniczenia  informacja o potencjalnych
ograniczeniach, bÄ…dz
utrudnieniach w komunikacji.
45
Przykładowo w zespole może być konsultant, który
jest dla nas osiągalny wyłącznie przez jakiś czas.
Ë% zaÅ‚ożenia  informacja o podstawowych
ustaleniach, takich jak preferowane formy
komunikacji, czy magazynowania i wyszukiwania
pozyskanej wiedzy.
Wyjścia z procesu:
Ë% plan zarzÄ…dzania komunikacjÄ…  opisuje metody,
jakie zostaną użyte do pozyskiwania i
przechowywania informacji, charakterystykÄ™
systemu dystrybucji i jej opis formalny, kalendarz
wskazujÄ…cy terminy potrzebnych informacji oraz
metody uaktualniania informacji.
Narzędzia wspomagające realizację procesu:
Ë% analiza potrzeb informacyjnych  zebranie
informacji o potrzebach informacyjnych uczestników
projektu w celu opracowania ogólnego planu potrzeb
informacyjnych oraz ich z
ródeł pozyskiwania.
dystrybucja informacji - oznacza udostępnianie
potrzebnych informacji wtedy, gdy sÄ… potrzebne
uczestnikom.
Wejścia do procesu:
Ë% wyniki pracy,
Ë% plan projektu,
Ë% plan zarzÄ…dzania komunikacjÄ….
Wyjścia z procesu:
Ë% zapisy projektu.
Narzędzia wspomagające realizację procesu:
Ë% doÅ›wiadczenia w komunikacji  umiejÄ™tne
wysyłanie jasnej, kompletnej i jednoznacznej
informacji. Z drugiej strony odebranie informacji w
poprawny sposób oraz upewnienie się ze jest ona
prawidłowa. Komunikacja może być słowna,
mówiona, słuchana, wewnętrzna, zewnętrzna,
formalna lub nieformalna.
Ë% system zdobywania informacji.
Ë% system dystrybucji informacji  dystrybucja
46
może się odbywać przez spotkania, kopie
dokumentów, dostęp do sieci i baz danych, fax,
pocztÄ™ elektronicznÄ…, wideokonferencje, itp.
sprawozdania - służą zbieraniu informacji o stopniu
wykonania zadań. Celem sprawozdań jest zbieranie
informacji o zasobach jakie sÄ… wykorzystywane
osiągnięcia celów projektu.
Wejścia do procesu:
Ë% wyniki pracy,
Ë% plan projektu,
Ë% inne zapisy projektu.
Wyjścia z procesu:
Ë% raporty wykonania  zestawienie informacji i
wyników analiz stanowiące wejścia do innych
procesów.
Ë% żądania zmian.
Narzędzia wspomagające realizację procesu:
Ë% przeglÄ…dy wykonania zadaÅ„  spotkania
organizowane w celu określenia postępu prac.
Ë% analiza odchyleÅ„  porównanie osiÄ…gniÄ™tych wyników
z planowanymi lub oczekiwanymi.
Ë% analiza trendu.
Ë% analiza korzyÅ›ci (earned value analisis)  narzÄ™dzie
uwzględniające zakres, koszty i terminy.
Ë% narzÄ™dzia i techniki dystrybucji informacji.
administracja  zajmuje sie weryfikacjÄ… i
dokumentowaniem wyników projektu w celu formalnej
jego oceny. Zamykanie fazy projektu lub całości etapu
nie może być odkładane na koniec gdyż z
administracyjnego punktu widzenia zamknięcie
możemy uznać wyłącznie po formalnej ocenie jego
wykonania.
Wejścia do procesu:
Ë% dokumentacja pomiarów wykonania,
Ë% dokumentacja produktu projektu,
Ë% inne zapisy projektu.
Wyjścia z procesu:
47
Ë% archiwa projektu  zebrane we wspólnÄ… caÅ‚ość
zapisy z projektu przygotowane do archiwizowania
przez określone jednostki. Szczególną uwagę należy
poświęcić projektom realizowanym z w ramach
kontraktu analizując ich zapisy finansowe i księgowe.
Ë% akceptacja formalna  przygotowana i
rozpowszechniona dokumentacja zaakceptowana
przez klienta.
Ë% zdobyta wiedza.
Narzędzia wspomagające realizację procesu:
Ë% narzÄ™dzia i techniki sprawozdaÅ„.
2.2.8 ZarzÄ…dzanie ryzykiem
ZarzÄ…dzanie ryzykiem w projektach informatycznych jest
jednym z ważniejszych procesów. Dlatego też zagadnieniu
temu zostanie poświęcony odrębny rozdział w dalszej części
skryptu. Pokrótce proces ten obejmuje identyfikację, analizę
oraz działania zapobiegające niepożądanym zdarzeniom. Z
ryzykiem związane są decyzje menadżera, które musi
podejmować w sytuacji wystąpienia zagrożenia. Z punktu
widzenia prawdopodobieństwa wystąpienia ryzyka
wyróżniamy decyzje:
podejmowane w warunkach pewności, kiedy są do
dyspozycji wszelkie potrzebne informacje,
podejmowane w warunkach niepewności, kiedy nie
wiadomo nic o przyszłych stanach systemu i otoczenia,
podejmowane w warunkach ryzyka, kiedy można ocenić
prawdopodobieństwo wystąpienia różnych sytuacji na
podstawie dostępnych informacji.
Ryzyko najczęściej definiowane jest jako sytuacja, która
wpływa negatywnie na projekt przyczyniając się do strat.
Istnieje wiele podziałów ryzyka, jak np:
właściwe, oparte o zasady prawa wielkich liczb  pożar,
klęska,
subiektywne wynikające z błędów i niedociągnięć
48
człowieka, podejmującego decyzje na podstawie
analizy,
obiektywne, takie którego w żaden sposób nie można
przewidzieć  odkrycia.
Ze względu na zmienne warunki działalności gospodarczej
S. Nahotko wyróżnił następujące rodzaje ryzyka:
ryzyko działalności  zależne od popytu i cen,
ryzyko płynności  niemożność natychmiastowego
zbycia wytworzonych aktywów,
ryzyko nieściągalności  brak możliwości
wyegzekwowania zapłaty za odebran
y produkt,
ryzyko rynkowe  uzależnione od globalnych zmian
rynkowych,
ryzyko stopy procentowej  związane z wahaniami stóp
procentowych, kursów walut i papierów wartościowych,
ryzyko siły nabywczej  brak oczekiwanej wielkości siły
nabywczej.
W zależności od ilości i jakości możemy dokonać innego
podziału:
ryzyko normalne  naturalne dla procesów
gospodarczych,
ryzyko dopuszczalne  takie, na które możemy zezwolić,
ryzyko niedopuszczalne  przekraczajÄ…ce poprzedni
poziom,
ryzyko niezbędne  związane z funkcjonalnością lub
elementem, którego nie można wyeliminować.
ZarzÄ…dzanie ryzykiem w projekcie dotyczy rozpoznawania
i identyfikacji ryzyka, z jakim przedsiębiorstwo może się
zetknąć, jego kontrolowania i pomiaru.
Najczęstszymi metodami używanymi do identyfikacji
ryzyka sÄ…:
burza mózgów,
metoda Craforda,
technika delficka,
listy kontrolne,
49
 drzewa zdarzeń.
2.2.9 ZarzÄ…dzanie zaopatrzeniem
ZarzÄ…dzanie zaopatrzeniem (czasami nazywane
zarządzaniem zleceniami) obejmuje zdobywanie dóbr i usług
spoza organizacji wykonujÄ…cej projekt. Obszar ten jest badany
z perspektywy kupujÄ…cego oraz relacji kupujÄ…cy-dostawca.
Relacja ta może istnieć na wielu szczeblach jednego projektu.
Zarządzanie zaopatrzeniem w projekcie skład się z
następujących procesów:
planowanie zleceń  ma kluczowe znaczenie w
rozdzielaniu zleceń. Wskazuje, które z nich mają być
wykonane wewnętrznie, a które opłaca się zlecić
zewnętrznym kontrahentom. Określa kiedy i za ile kupić
wymagany produkt. Każdy zakup produktu traktowany
jest osobno i musi on przejść prze niżej wskazane
procesy. Jeżeli produkt wykonywany jest wewnętrznie
pozostałe procesy nie występują. Takie przypadki
zdarzają się, gdy organizacja nie chce udostępniać
swojej technologii, nie ma właściwych dostawców.
Wejścia do procesu:
Ë% deklaracja zakresu  opisujÄ…ca czego dotyczy
zlecenie.
Ë% opis produktu  bÄ™dÄ…cy podstawowÄ… informacjÄ…
wewnętrzną dla osób podejmujących decyzje o
zleceniach.
Ë% możliwoÅ›ci zleceÅ„  jeÅ›li istnieje zdefiniowany
zespół kontrahentów należy przeanalizować czy jest
on w stanie zrealizować zlecenia, jeśli nie, zespół
projektowy powinien przeanalizować czy będzie
możliwość wykonania zlecenia.
Ë% warunki rynku  należy uwzglÄ™dnić dostÄ™pność
produktów jakie znajdują się na rynku, od kogo one
pochodzÄ… i jakie sÄ… warunki ich zakupu.
Ë% ograniczenia i zaÅ‚ożenia dotyczÄ…ce produktu -
50
różnego rodzaju przeszkody mogące opóz
nić lub
uniemożliwić realizację np. zbyt mały budżet.
Wyjścia z procesu:
Ë% plan zarzÄ…dzania zleceniami - opisuje jak bÄ™dzie
przebiegać zarządzanie zidentyfikowanymi
zleceniami, jakie sÄ… najkorzystniejsze typy
kontraktów, kto będzie odpowiedzialny za
szacowanie kosztów, gdzie można znalez
ć
dokumenty dotyczące zleceń i kto jest za nie
odpowiedzialny; jak przeprowadzić zarządzanie
wieloma dostawcami i skoordynować wszelkie
działania dotyczące zleceń z innymi aspektami
projektu.
Ë% zestawienie prac (wymagaÅ„)  zawiera
szczegółowy opis zlecenia, dzięki któremu
kontrahent jest w stanie stwierdzić czy może
dostarczyć taki produkt, jeżeli opis dotyczy
rozwiązania pewnego problemu wówczas tworzy się
zestawienie wymagań dla zagadnienia. Zestawienie
może się zmieniać w trakcie kolejnych procesów. Na
przykład dostawca może zaproponować lepszą
formę produktu lub tańszy produkt spełniający
wymagania.
Narzędzia wspomagające realizację procesu:
Ë% analiza typu kupić czy zrobić  przeprowadzane
sÄ… rozmowy i analizy dotyczÄ…ce problemu wykonania
produktu we własnym zakresie lub zlecenia go
podwykonawcÄ….
Ë% osÄ…d ekspertów.
Ë% wybór typu kontraktu  generalnie można tu
wyróżnić trzy typy zawieranych kontraktów. Rodzaj
kontraktu zależy od informacji, jakimi dysponujemy
o zamawianym produkcie. Wyróżniamy trzy grupy
kontraktów: ze stałą ceną  wybierany gdy produkt
jest dobrze znany, zarówna jego specyfikacja jak i
cena, zatem ani sprzedawca ani kupujÄ…cy nie ponosi
ryzyka; z sumÄ… globalnÄ…  kontrakt zawiera globalny
51
koszt dostarczenia określonej ilości jednostek
produktu bez względu na zmianę kosztów za
jednostkę w czasie; ze stałą cena za jednostkę 
zawierany gdy kupujemy dany produkt w różnych
odstępach czasu i nie chcemy ponosić kosztów
związanych np ze wzrostem cen paliw (przekłada się
to na rosnÄ…cy koszt jednostki).
planowanie ofertowania  zajmuje siÄ™
przygotowaniem dokumentów do ofertowania.
Wejścia do procesu:
Ë% plan zarzÄ…dzania zleceniami,
Ë% zestawienie prac.
Wyjścia z procesu:
Ë% dokumenty zleceÅ„ - wzory dokumentów sÅ‚użących
do zbierania ofert od dostawców. Często wzory
formularzy zawierajÄ… pozycjÄ™ oferta ceny lub
notowania, z którymi mamy do czynienia w
przypadku zleceń zorientowanych na cenę.
Dokumenty te powinny być bardzo skrupulatnie
sporządzone a jednocześnie pozwalające na
uwzględnienie uwag od dostawców, które mogą
podnieść jakość produktu.
Ë% kryteria oceny  sÄ… niezwykle ważne w procesie
oceny i porównania propozycji zleceń. Kryterium
zawężane jest do ceny jeśli produkt, którego dotyczy
zlecenie jest dobrze znany. W innym przypadku
kryteria zawierają m.in.: stopień zrozumienia
potrzeby przez dostawcÄ™, poziom kosztu, ocena
poziomu wiedzy i technologii dostawcy, zdolność
finansowa dostawcy.
Ë% zmiany do zestawienia prac.
Narzędzia wspomagające realizację procesu:
Ë% standardowe dokumenty  wzory kontraktów,
opisów zleceń.
Ë% osÄ…d ekspertów.
ofertowanie - zdobywanie informacji od dostawców,
nie generuje kosztów dla projektu całkowicie
52
realizowane przez dostawców
.
Wejścia do procesu:
Ë% dokumenty zleceÅ„,
Ë% lista kwalifikowanych dostawców  spis
dostawców , którzy dostali pozytywną opinię w
czasie współpracy z firmą a wykonane przez nie
zlecenia spełniały oczekiwania klienta.
Wyjścia z procesu:
Ë% propozycje - dokumenty przygotowane przez
dostawców, opisujące ich zdolność i chęć do
wykonania określonego produktu.
Narzędzia wspomagające realizację procesu:
Ë% spotkania wyjaÅ›niajÄ…ce  spotkania majÄ…ce na
celu przybliżenie dostawcą specyfikacji produktów.
Najczęściej odbywają się przed sformułowaniem
propozycji.
Ë% ogÅ‚oszenia  jeÅ›li nie istnieje lista dostawców lub
posiadana przez firmÄ™ list nie jest wystarczajÄ…ca
może zostać rozszerzona poprzez zamieszczanie
ogłoszeń bądz
reklam w prasie ogólnej lub fachowej.
selekcja dostawców - dostarczone propozycje są
oceniane na podstawie kryteriów oceny. Cena może być
głównym determinantem, ale okaże się że dostawca
oferujący najniższą cenę nie zapewnia najniższych
kosztów. Często oferty składają się z dwóch części -
technicznej i ekonomicznej w takiej sytuacji oceniana
jest każda z nich osobno. Oceniający może dokonać
rangowania ofert, na podstawie którego będą
przeprowadzane kolejne negocjacje.
Wejścia do procesu:
Ë% propozycje,
Ë% kryteria oceny,
Ë% polityka organizacyjna.
Wyjścia z procesu:
Ë% kontrakt - umowa, która obliguje dostawcÄ™ do
wytworzenia określonego produktu i obliguje
kupującego do zapłacenia za niego.
53
Narzędzia wspomagające realizację procesu:
Ë% negocjacja kontraktu  obejmuje dyskusje
prowadzone w celu uzgodnienia struktury kontraktu.
Umowa zawarta pomiędzy dostawcą a klientem
określa: odpowiedzialność, uprawnienia, przepisy
prawne, podejścia techniczne i ekonomiczne,
finansowanie i cenÄ™ dotyczÄ…ca zamawianego
produktu.
Ë% nadawanie wag  pozwala na zamianÄ™ danych
jakościowych na parametry ilościowe.
Ë% system odsiewajÄ…cy  zakÅ‚ada minimum jakie jest
wymagane do zrealizowania zlecenia. Jeżeli jedno z
kryteriów minimum nie jest spełnione oferta zostaje
natychmiastowo odrzucona.
Ë% niezależne szacunki.
administracja kontraktu  ma na celu kontrolÄ™
poziomu wykonania świadczonego przez dostawcę jest
zgodny z wymaganiami kontraktu. W większych
projektach posiadających wielu dostawców produktów
istotÄ… tego procesu jest zarzÄ…dzanie powiÄ…zaniami
między różnymi dostawcami.
Wejścia do procesu:
Ë% umowa,
Ë% wyniki pracy  ocena zrealizowania zlecenia przez
dostawcÄ™.
Ë% żądania zmian  np. wynikajÄ…ce z wydÅ‚użonym
terminem oczekiwania na towar skutkujÄ…
modyfikacją kontraktu najczęściej na niekorzyść
dostawcy.
Ë% faktury dostawcy.
Wyjścia z procesu:
Ë% korespondencja z dostawcami,
Ë% zmiany do kontraktu,
Ë% żądania pÅ‚atnoÅ›ci.
Narzędzia wspomagające realizację procesu:
Ë% system nadzoru zmian w kontrakcie  jest to
system procedur formalnych, jakie muszą być
54
zrealizowane aby umożliwić zmianę warunków
kontraktu.
Ë% raporty wykonania  raportujÄ… efektywność
dostawcy wywiÄ…zania siÄ™ ze zlecenia.
Ë% system pÅ‚acenia - zwykle wpÅ‚aty dokonywane sÄ…
przez system kont organizacji. W większych
projektach istnieje możliwość stworzenia własnego
systemu.
zamykanie kontraktu - weryfikacja i administracyjne
zamknięcie kontraktu.
Wejścia do procesu:
Ë% dokumentacja kontraktu  skÅ‚adajÄ… sie na niÄ…
wszelkie zawierane umowy, zmiany do kontraktu,
oficjalne terminarze, dokumentacja techniczna
dostawców, dokumenty finansowe itp.
Wyjścia z procesu:
Ë% archiwum kontraktu,
Ë% formalna akceptacja i zamkniÄ™cie  nastÄ™puje w
chwili zatwierdzenia wykonania kontraktu przez
wyznaczona osobę. Akceptacja następuje na pismie i
jest przekazywana dostawcy.
Narzędzia wspomagające realizację procesu:
Ë% audyt zlecenia  przeglÄ…d zlecenia od planowania
przez administrację aż do jego zamknięcia .
2.3 PRINCE 2
Metodyka PRINCE 2 (ang. PRoject IN Controlled
Environments) powstała w Wielkiej Brytanii w roku 1989.
Została stworzona przez Central Computer and
Telecommunication Agency (CCTA) na podstawie istniejÄ…cej
już metodyki PROMPT, opracowanej przez Simpact System w
1975 r. PRINCE 2 zastąpiła metodykę PROMPT i stała się
oficjalnie obowiÄ…zujÄ…cym standardem w Wielkiej Brytanii.
Prototypem dla PRINCE 2 była metodyka PRINCE, która
została rozwinięta w 1996 r do obecnej postaci, dokonano w
efekcie również zmiany nazwy celem odróżnienia i wskazania
55
następnej generacji. Prawa autorskie do metodyki posiada
Korona Królewska Wielkiej Brytanii, natomiast nazwa jest
zastrzeżona przez Office Goverment Commerce. W Polsce
stosuje siÄ™ metodykÄ™ tÄ™ od kilku lat.
PRINCE2 wykorzystywana jest nie tylko w projektach
informatycznych ale również w innych (przez ogół
użytkowników począwszy od małych firm, a kończąc na
wielkich korporacjach).
2.3.1 Ogólna charakterystyka
Metodyka PRINCE 2 wyjaśnia  co i  dlaczego zostało
zrobione w projekcie, ale nie mówi  jak . Daje możliwość
podziału projektu na mniejsze części, które są łatwiejsze w
zarządzaniu. Zwraca szczególną uwagę na aspekty
biznesowe, zaczynając od powodów, dla których rozpoczęto
realizację projektu, a kończąc na jego zamknięciu. PRINCE 2
definiuje projekt, jako organizacjÄ™ stworzonÄ… na jakiÅ› czas, w
celu dostarczenia jednego lub większej ilości produktów
biznesowych, zgodnie z określonym uzasadnieniem
biznesowym. Metodyka ta opiera siÄ™ na kilku podstawowych
zasadach:
projekt musi posiadać początek i koniec;
zarządzanie w projekcie musi przebiegać tak, aby
projekt zakończył się sukcesem;
wszyscy uczestnicy projektu powinni posiadać
odpowiednie kompetencje, doskonale znać swoje
obowiÄ…zki i cele.
Każdy projekt według metody PRINCE 2 powinien:
mieć uzasadnione cele biznesowe;
posiadać określony zbiór produktów głównych i
czÄ…stkowych;
zawierać odpowiedni zestaw czynności służących
wytworzeniu wskazanych produktów;
określać strukturę organizacyjną zespołu;
posiadać zdefiniowane czynności i procesy mające na
56
celu kontrolę projektu oraz jego pomyślne ukończenie;
posiadać skończony czas i środki do jego realizacji.
Metodyka PRINCE 2 wyróżnia osiem procesów
decydujÄ…cych o powodzeniu projektu:
1. przygotowanie założeń projektu,
2. strategiczne zarzÄ…dzanie projektem,
3. planowanie,
4. inicjowanie projektu,
5. sterowanie etapem,
6. zarządzanie dostawą produktów,
7. zarzÄ…dzanie zakresem etapu,
8. zamykanie projektu.
Dla każdego z wymienionych procesów określa się, kto
jest za nie odpowiedzialny. Również każdy z tych procesów
posiada mechanizmy zapewniania jakości. Metodyka rozdziela
bieżące zarządzanie projektem, za które odpowiedzialny jest
kierownik projektu, od decyzji strategicznych, które
przeznacza komitetowi sterujÄ…cemu. Metodyka nie dopuszcza
mieszania ról w projekcie. Omówmy teraz bardziej
szczegółowo te procesy.
2.3.2 Przygotowanie założeń projektu
Celem tego procesu jest przygotowanie projektu do
uruchomienia. Jest to etap poprzedzajÄ…cy projekt, majÄ…cy
zapewnić, że projekt będzie wart ponoszonych kosztów i że da
się go zrealizować. Informacją wejściową dla procesu jest
Zlecenie Przygotowania Projektu (ang. Project Mandate). W
proces zaangażowane jest wyższe kierownictwo organizacji,
które ustanawia i wybiera Komitet Sterujący (ang. Project
Board), który nadzoruje projekt i wybiera Kierownika Projektu.
Uzasadnienie projektu jest zarysowane w Podstawowych
Założeniach Projektu. W zależności od specyfiki projektu
wybierana jest formuła realizacji. Wykonany jest także plan
etapu inicjowania projektu.
W ramach tego procesu wyróżnia się sześć zasadniczych
57
etapów:
1. Mianowanie PrzewodniczÄ…cego Komitetu
SterujÄ…cego i Kierownika Projektu.
Przewodniczący Komitetu Sterującego spełnia rolę
decydenta, podczas gdy Kierownik Projektu pełni rolę
głównego planisty. Obie te osoby są zobowiązane do
dokumentowania swoich działań i decyzji.
2. Projektowanie Zespołu Zarządzania Projektem.
Zespół ten to grupa ludzi odpowiedzialnych za
planowanie, zarzÄ…dzanie i sterowanie projektem.
Tworzony jest on przez PrzewodniczÄ…cego Komitetu
SterujÄ…cego i Kierownika Projektu. Na etapie
projektowania tego zespołu należy zdefiniować zakresy
obowiązków dla każdego z jego członków.
3. Mianowanie członków Zespołu Zarządzania
Projektem.
Obowiązek mianowania członków spoczywa na
Przewodniczącym Komitetu Sterującego, który
ostatecznie ustala zakres obowiązków każdego z nich.
4. Przygotowanie podstawowych założeń projektu.
Zakres zadań obejmujący ustalenie celów, zakresu,
ograniczeń, punktów styku z otoczeniem, wszystkie te
elementy muszą mieć uzasadnienie biznesowe. y
ródło
podstawowe stanowi dokument Zlecenie przygotowania
założeń projektu, który może mieć zarówno nieformalny
charakter, jak i być oficjalną prośbą skierowaną przez
klienta do potencjalnego wykonawcy.
5. Definiowanie formuły realizacji.
Na tym etapie rozpatrywane są możliwe podejścia do
projektu. Dyskusja odbywa sie wraz z PrzewodniczÄ…cym
Komitetu Sterującego, który zatwierdza dokument
inicjujący projekt. Formuła realizacji będzie częścią
Opisu Planu Projektu oraz będzie wejściem do procesu
Inicjowanie projektu.
6. Planowanie etapu inicjowania.
Etap powstawania planu umożliwiający komitetowi
58
sterujÄ…cemu wydanie zezwolenia na opracowanie
dokumentu inicjującego projekt. Należy zaproponować
krótkoterminowy plan dla określonej grupy produktów
wraz działaniami, jakich one wymagają.
Przygotowania założeń projektu oraz inicjowanie projektu
mają bardzo duże znaczenie w metodyce zarządzania PRINCE
2.
2.3.3 Strategiczne zarzÄ…dzanie projektem
Proces ten realizuje funkcje, za które odpowiedzialny jest
Komitet SterujÄ…cy. Na jego etapie Kierownik Projektu
okresowo raportuje Komitetowi SterujÄ…cemu obecny stan
projektu. Bieżące zarządzanie pozostawione jest w wyłącznej
kompetencji Kierownika Projektu. Komitet SterujÄ…cy
podejmuje decyzje, czy należy kontynuować prace
przechodząc do następnego etapu. Fundamentalną zasadą
PRINCE 2 jest zarzÄ…dzanie poprzez wyjÄ…tki (ang. management
by exception), co oznacza, że Komitet Sterujący angażuje się
w podejmowanie decyzji projektowych, gdy uzyska
informacje, że projekt jest zagrożony wyjściem poza zakres
tolerancji.
W ramach tego procesu można wyróżnić następujące
podprocesy:
1. Zezwolenie na inicjowanie projektu.
2. Zezwolenie na realizacjÄ™ projektu.
3. Zezwolenie na realizacjÄ™ etapu lub planu awaryjnego.
4. Podejmowanie decyzji doraz
nych.
5. Zatwierdzenie zamknięcia projektu.
2.3.4 Planowanie
Jest procesem obejmującym cały cykl życia projektu i
podzielić go można na siedem głównych etapów:
1. Projektowanie planu.
Etap poświęcony wyłącznie na przygotowanie
59
planowania projektu. Osoby odpowiedzialne za proces
planowania ustalają stopień szczegółowości
przygotowywanych planów, wybierają narzędzia, jakie
zostaną do realizacji tego celu użyte oraz sposoby
prezentacji planów.
2. Definiowanie i analizowanie produktów.
Celem rozpoczęcia projektu jest wytworzenie pewnych
produktów, które składają się na ostateczny wynik. Etap
definicji i analizy pozwala na ustalenie wszystkich
produktów, jakie mają być wytworzone w czasie trwania
projektu, powiązań i zależności między nimi. Przy
identyfikacji poszczególnych produktów niezbędna jest
lista kontrolna produktów zawierająca krytyczne daty
rozpoczęcia i ich wykonania.
3. Określanie działań i zależności pomiędzy
produktami.
Na tym etapie podstawowym narzędziem jest diagram
przepływy produktów. Jest on przydatny do
przedstawiania zależności pomiędzy działaniami.
4. Szacowanie.
Nie jest łatwo określić dokładne wartości, jakie będzie
zawierać plan projektu. W tym celu szacuje się ich
wielkości za pomocą dostępnych metod. Ten szacunek
danych jest niezbędny do opracowania planu i w
konsekwencji - rozpoczęcia działań. Najpopularniejszą
metodÄ… szacowania jest Delphi. PolegajÄ…ca ona na
poproszeniu specjalistów o udzielenie odpowiedzi, które
weryfikuje się odpowiednimi filtrami, aż do otrzymania
konsensu odnośnie oszacowań najbardziej
optymistycznych, pesymistycznych i prawdopodobnych.
Następnie wykorzystuje się formułę zaproponowaną
przez Kena Bradley' a (K.Bradley 2003, s.144)
((1x najbardziej optymistyczne+ 1x najbardziej
pesymistyczne+4x najbardziej prawdopodobne))/6. ???
5. Harmonogramowanie.
Do stworzenia harmonogramu potrzebne jest
sporzÄ…dzenie diagramu Gantta oraz diagramu
60
sieciowego PERT. Oba narzędzia przedstawiają cykl
zależności pomiędzy działaniami oraz kolejność ich
następstw. Do sporządzenia powyższych diagramów
wykorzystuje siÄ™ zwykle specjalizowane programy
komputerowe. Stworzony w ten sposób plan zawiera
prace do wykonania wraz z dokładnie określonymi
terminami oraz osobami przydzielonymi do ich realizacji
i nadzoru.
6. Analizowanie ryzyka.
Planując projekt należy uwzględnić potencjalne ryzyko,
jakie może wystąpić w trakcie realizacji projektu.
Wszystkie zasoby powinny być analizowane pod kątem
potencjalnych zagrożeń i podejmowanych w związku z
tym działań, aby móc włączyć do planu stosowne
rezerwy. Można wyróżnić wiele z
ródeł ryzyka,
przykładowo: kwestia jakości produktów, zdolność
dotrzymywania terminów, dostępność siły roboczej
o właściwych kwalifikacjach oraz umiejętności kadry
zarzÄ…dzajÄ…cej.
7. Kompletowanie planu.
Etap domykania planu wiąże się z zebraniem
wszystkich elementów razem i przygotowaniem
krótkiego omówienia dotyczącego ważnych punktów.
Do opisu planu dołącza się różne plany i arkusze
analityczne, a do listy kontrolnej produktów dopisuje się
terminy rozpoczęcia i końca wykonywania każdego z
produktów.
2.3.5 Inicjowanie projektu
Akceptacja projektu następuje, kiedy jest on starannie
zaplanowany - na tyle zrozumiale, aby w łatwy sposób
wskazywał, jak mają być zrealizowane cele. Takie
przygotowanie wymaga szczegółowego szacowania kosztów i
pracy, jaka zostanie włożona w realizację projektu. Wszystkie
te parametry stanowią podstawę do zdefiniowania głównego
dokumentu procesu, tj. Dokumentu Inicjującego Projekt, który
61
musi zostać zaakceptowany przez Komitet Sterujący zanim
etap realizacji zostanie uruchomiony.
Inicjowanie projektu obejmuje następujące pod procesy:
Planowanie jakości.
Celem tego procesu jest stworzenie planu jakości
projektu, który odgrywa ważną role w projektach
wykonywanych zgodnie z omawianą. Plan jakości
projektu powinien być zbudowany i dopasowany do
własnych standardów jakości organizacyjnej zarówno
klienta, jak i dostawcy.
Planowanie projektu.
Działanie to musi zostać podjęte już na samym
poczÄ…tku projektu. Wymaga, aby Kierownik Projektu
przedstawił projekt w perspektywie długoterminowej.
Nie jest od niego wymagana znajomość wszystkich
niebezpieczeństw grożących przedsięwzięciu, ale
powinien on spróbować przedstawić w planie jego
przyszłość i zaproponować plan działania w przypadku
wystąpienia nieprawidłowości w realizacji.
Doprecyzowanie Uzasadnienia Biznesowego i
Ryzyka.
Wstępne uzasadnienie biznesowe projektu musi być
zaakceptowane przez Komitet SterujÄ…cy. Uzasadnienie
biznesowe projektu powinno być jasno określone, a po
jego zatwierdzeniu przeglÄ…dane i aktualizowane
podczas przygotowań do każdego przeglądu etapu
zarządczego (szerzej pisaliśmy o tym wcześniej). W tym
miejscu powinno się również zidentyfikować ryzyko
zwiÄ…zane z projektem. Uzasadnienie biznesowe, jak i
ryzyko powinny być razem rozważane ze względu na
ich silne powiÄ…zania.
Ustanowienie elementów sterowania.
W czasie realizacji procesu Inicjowania projektu powoli
zostajÄ… ustalone elementy sterowania projektem.
Elementy te są kluczowym czynnikiem do osiągnięcia
sukcesu każdego projektu. Umożliwiają sterowanie
62
projektem tylko w takim stopniu szczegółowości, w
jakim został on zaplanowany. Można je podzielić na
dwie kategorie:
Ë% Elementy sterowania wykorzystywane przez Komitet
SterujÄ…cy:
% Narada inicjujÄ…ca projekt oraz Inicjowanie
projektu.
% Etapy zarzÄ…dcze.
% Raportowanie odchyleń i zarządzanie
odchyleniami - ocena nadzwyczajna.
% Tolerancje  dla czasu i kosztów; zakresu i jakości;
korzyści i ryzyka.
% Raportowanie o ważnych zdarzeniach.
% Ponowna ocena uzasadnienia biznesowego.
% Oszacowanie ryzyka, reakcje na wystÄ…pienie
zagrożenia i zarządzanie ryzykiem.
% Zamknięcie projektu.
Ë% Elementy sterowania wykorzystywane przez
Kierownika Projektu:
% Punkty kontrolne.
% Przeglądy jakości (nieformalne).
% Przeglądy jakości (formalne).
% Komunikacja codzienna i spotkania nieformalne.
% Ustanowienie dokumentacji projektowej
W metodyce PRINCE 2 nie ma ściśle określonych
zasad dotyczÄ…cych dokumentacji. Metody jej
gromadzenia ustala szczebel zarzÄ…dzajÄ…cy
projektem. Jednym z popularniejszych podejść
jest gromadzenie dokumentów zarówno w postaci
elektronicznej, jak i fizycznej. Wszystkie
zgromadzone w ten sposób dokumenty należy w
ustalony sposób archiwizować.
Zestawienie Dokumentu InicjujÄ…cego Projekt
Wynikiem procesu Inicjowania Projektu jest Dokument
Inicjujący Projekt. Wykorzystywany jest w całym
projekcie. Pomaga zapewnić, by wykonywana praca i
63
wytworzone produkty wspierały główne cele projektu
oraz spełniały potrzeby klienta.
2.3.6 Sterowanie etapem
Projekty realizowane wg metodyki PRINCE 2 sÄ… podzielone
na etapy zarządcze. Dokładna ich ilość nie jest określona,
ponieważ zależy od wielkości konkretnego projektu, poziomu
ryzyka i ilości planowanych punktów decyzyjnych, w których
należy rozstrzygnąć czy projekt jest nadal uzasadniony
biznesowo i czy kontynuować nad nim prace. Sterowanie
etapem jest głównym mechanizmem w projektach
zarządzanych zgodnie z PRINCE 2 (???). Właścicielem
procesu, w którym wykonuje się większość działań
związanych z bieżącym zarządzaniem projektu, jest Kierownik
Projektu.
Sterowanie etapem obejmuje następujące podprocesy:
Zgoda na wykonanie grupy zadań.
Podjecie decyzji (zgoda) o wykonaniu zadania jest
przywilejem Kierownika Projektu i głównym narzędziem
do bieżącego sterowania. Kierownik Projektu
odpowiada za przygotowanie, wydanie i uzgodnienie
grup zadań. Prace do wykonania są przekazywane
Kierownikom Zespołów lub bezpośrednio pracownikom
przy pomocy grup zadań.
Ocena postępów.
Proces ten zapewnia zbieranie informacji dotyczÄ…cych
aktualnego stanu prac w projekcie. Zebrane dane
przekazywane sÄ… do procesu Dokonywanie przeglÄ…du
stanu etapu. Wszelkie informacje pochodzą z raportów
punktów kontrolnych, karty pracy oraz zagadnień
projektowych.
Rejestrowanie zagadnień projektowych.
Pojawiające się zmiany są rejestrowane, a następnie
poddawane dyskusji w celu podjęcia odpowiednich
decyzji. Wszystkie zmiany traktowane sÄ… jako
64
zagadnienia projektowe, które mogą być zgłoszone
przez dowolnÄ… osobÄ™ zwiÄ…zanÄ… z projektem.
Analizowanie zagadnień projektowych.
Etap polega na analizie wszystkich zagadnień
projektowych i ich skutków. Zagadnienia projektowe
powinny być badane z perspektywy klienta, biznesu lub
dostawcy. Odpowiedzialność za tę analizę spoczywa na
Kierowniku Projektu.
PrzeglÄ…danie stanu etapu.
Proces ten zapewnia regularne sprawdzanie stanu
realizacji etapu zarzÄ…dczego w zestawieniu z
zatwierdzonym planem.
Raportowanie o ważnych zdarzeniach.
Polega na, regularnym (zwykle ustalonym z góry),
raportowaniu Komitetowi Sterującemu o ważnych
zdarzeniach. Celem raportu jest dostarczenie
sumarycznych, zebranych w logiczną całość informacji.
Podejmowanie działań korekcyjnych.
Umożliwia Kierownikowi Projektu dokonywania
niewielkich korekt realizowanych prac w ramach
uzgodnionej tolerancji.
Eskalowanie zagadnień projektowych.
Występuje, jeżeli mamy do czynienia z sytuacją, gdy
istniej uzasadnione podejrzenie, że etap zarządczy
może wykroczyć poza granice tolerancji. Kierownik
Projektu musi powiadomić o tym fakcie Komitet
Sterujący poprzez złożenie raportu o odchyleniach.
Odbieranie wykonanych grupy zadań.
Etap ten uwzględnia pomyślnie wykonane grupy zadań,
które przekazywane są organizacji realizującej projekt w
ustalony sposób. Wyniki procesu są używane do oceny
postępu prac poprzez dokonanie zapisu o wykonaniu
zadania i aktualizacji zapisów dotyczących etapu
zarzÄ…dczego i projektu.
65
2.3.7 Zarządzanie dostawą produktów
PRINCE 2 to metodyka oparta na produktach. Produktem
nazywamy zarówno rzecz materialną, np. książkę, jak
i niematerialnÄ…, np. program komputerowy. Wszystko co
zostało wytworzone za pomocą tej metodyki wraz
z dokumentacją zaliczany do produktów. Produkt może być
wytworzony przez kogokolwiek, także przez zewnętrznego
dostawcę. Zarządzanie dostawą produktów jest procesem,
który skupia się na tworzeniu, modyfikowaniu i uzyskiwaniu
produktów projektu, co musi uwzględniać spełnienie
wymaganych kryteriów jakościowych.
Zarządzanie dostawą produktów obejmuje następujące
podprocesy:
Przyjęcie grupy zadań do realizacji.
Wytwarzanie grupy zadań.
Dostarczanie grupy zadań.
2.3.8 ZarzÄ…dzanie zakresem etapu
ZarzÄ…dzanie zakresem etapu ma na celu przekazanie
Komitetowi Sterującemu informacji o zakończonym etapie
wytwórczym oraz zagwarantowanie jakości w pełni
zrealizowanych produktów. Dostarczane są raporty z
harmonogramu, wynikach technicznych i budżecie. To właśnie
te informacje sÄ… podstawÄ… do oceny uzasadnienia
biznesowego i podjęcia decyzji o zakończeniu aktualnego
etapu oraz wydania zezwolenia na rozpoczęcie kolejnego.
Zarządzanie Zakresem Etapu obejmuje następujące
podprocesy:
Planowanie etapu.
W tym miejscu określone zostają produkty, jakie należy
wykonać w rozpoczynającym się etapie. Przy określaniu
produktów należy oszacować nakład pracy oraz
wielkość budżetu potrzebnego na ich wykonanie. Warto
na tym etapie zweryfikować zespół zarządzania
66
projektem, aby zaplanować dostępność
najwłaściwszych ludzi zdolnych do podejmowania
decyzji zwiÄ…zanych z pracami projektowymi.
Uaktualnienia planu projektu.
Wszystkie informacje potrzebne do podejmowania
decyzji zwiÄ…zanych z pracami projektowymi powinny
być stale uaktualniane, aby zapewnić optymalny wybór
środków i metod działania.
Uaktualnienie uzasadnienia biznesowego
projektu.
W metodyce PRINCE 2 właśnie to uzasadnienie
biznesowe jest główna siłą napędową prowadzonego
projektu. Dlatego też zaleca się jego częste aktualizacje
oraz oceny powtarzane przynajmniej na koniec każdego
etapu zarzÄ…dczego.
Uaktualnienie rejestru ryzyka.
Na tym etapie ponownie dokonujemy oceny ryzyka
zwiÄ…zanego z etapem zarzÄ…dczym i projektem.
Zalecane jest wykorzystanie na tym etapie  Listy
kontrolnej analizy ryzyka . Otrzymane wyniki należy
opracować i przedstawić Komitetowi Sterującemu
podczas Oceny końcowej etapu. Jeśli realizacja projektu
przebiega bez większych zmian, rejestr ryzyka powinien
być funkcją malejącą.
Raportowanie końca etapu.
Metodyka PRINCE 2 zakłada, że wyniki etapu
zarządczego muszą być raportowane. Są one
prezentowane w Raporcie końcowym etapu,
podsumowujÄ…cym wyniki etapu zarzÄ…dczego. Raport
informuje Komitet SterujÄ…cy o: kosztach planowanych i
poniesionych,nakładzie pracy planowanym
i poniesionym, terminach planowanych i faktycznych,
dostarczonych produktach. Potwierdza, że spełniły one
określone dla nich kryteria jakości. Osobą
odpowiedzialnÄ… za przygotowanie raportu jest Kierownik
Projektu, któremu pomaga Zespół Zarządzania
Projektem. Opracowany raport powinien zostać
67
przedłożony na około tydzień przed Oceną końcową
etapu.
Opracowanie planu naprawczego.
Opracowanie planu naprawczego następuje w sytuacji,
gdy zaistnieją zbyt duże odchylenia odchylenia w
projekcie, niemieszczÄ…ce siÄ™ w granicach przewidzianej
tolerancji. Wówczas zastępuje on wcześniejszy plan.
Plan naprawczy powinien również zyskać akceptację
Komitetu SterujÄ…cego, tzw.  Zezwolenie na realizacjÄ™
planu etapu lub planu naprawczego .
2.3.9 Zamykanie projektu
Proces Zamykania projektu polega na wykonaniu prac
porządkowych potrzebnych dla właściwego zamknięcia
projektu. Zezwolenie na jego zamknięcie może wydać tylko
Komitet Sterujący. Wszystkie doświadczenia zdobyte w trakcie
prowadzenia projektu sÄ… rejestrowane, tworzony jest
dokument przekazania i planowany jest przeglÄ…d po
wdrożeniowy. Proces ten ma podstawowe znaczenie dla
uporządkowanego i skutecznego zamknięcia projektu.
Zamykanie projektu dzielimy na następujące pod procesy:
Przygotowanie projektu
do zamknięcia.
Celem tego procesu jest uzyskanie akceptacji klienta,
dlatego też należy przygotować projekt do
uporządkowanego zamknięcia, zapewnić gwarancję
oraz wsparcie zakończonego przedsięwzięcia jak
również dostarczyć odpowiednią dokumentację
projektu, która zostanie zachowana na potrzeby
ewentualnego audytu w przyszłości.
Określanie działań następnych.
Proces ma za zadanie odnalezienie niedokończonych
spraw, które zostają na koniec projektu. Najczęściej są
to zagadnienia dotyczÄ…ce niezrealizowanych
funkcjonalności odrzuconych z powodu naruszenia
założonego budżetu lub czas wykonania.
68
 PrzeglÄ…d oceniajÄ…cy projekt.
Jest to proces, w którym następuje zebranie
doświadczeń z przeprowadzonego projektu. Zalecane
jest gromadzenie wszelkich informacji, które zostały
pozyskane w trakcie i po zakończeniu projektu. Warto w
tym miejscu przeprowadzić również analizę
porównawczą, mającą na celu zestawienie celów, jakie
zamierzono osiągnąć realizując projekt z tym, co
faktycznie osiągnięto.
69
3 ZarzÄ…dzanie projektem
3.1 Miary w projekcie informatycznym
Efektywne zarzÄ…dzanie sprowadza siÄ™ do planowania oraz
kontrolowania postępu prac. Kontrola taka jest możliwa
wtedy, gdy stosujemy odpowiednie miary dla każdego rodzaju
prac i porównujemy plan i wykonanie poprzez te miary.
Z wcześniejszych rozdziałów wynika jasno, że
przeprowadzania pomiarów w ramach projektu
informatycznego dokonuje się w wielu płaszczyznach, choćby:
czas pracy, koszty, wydajność, jakość, złożoność, łatwość
pielęgnacji i wiele innych. Oczywiście każdą cechę jaką
chcielibyśmy porównać wygodnie jest sprowadzić do pewnej
wartości liczbowej, gdyż je jest łatwo porównać. Stąd też
zawsze w projekcie wprowadzając nową miarę powinniśmy
określić algorytm określania (przeliczania) cechy na wartość
tej miary.
Spróbujmy opisać kilka przykładowych miar stosowanym
w projektach informatycznych, wskazujÄ…c na ich wady lub
niedoskonałości:
Czas pracy  jest to naturalny sposób dokonywania
pomiarów związanych z wykonaniem każdej pracy, nie
tylko zwiÄ…zanej z projektami informatycznymi. Zwykle
wyraża się go w roboczo godzinach. Miarę tą stosujemy
70
zarówno przy tworzeniu harmonogramu do szacowania
pracochłonności projektu (i kosztów), jak i do bieżącego
rozliczania pracowników. Miara to jest prosta i czytelna,
ale niestety ma wadę polegającą na tym, że w
przypadku pracy twórczej, z jaką mamy do czynienia w
projektach informatycznych, istnieje duża możliwość
nadużyć ze strony pracowników. Zauważmy, że w
przypadku choćby programistów, pisanie 10 linii kodu i
40 linii kodu może zająć tyle samo czasu w zależności
od stopnia trudności. Zasygnalizowany program
prowadzi do konieczności wprowadzenia kolejnej miary
zwiÄ…zanej z kodem programu.
Pracochłonności  jak się okazuje istnieje wiele miar
związanych z pomiarem pracochłonności kodu
programu. Z tego co napisaliśmy w powyższym
wypunktowaniu, nie ma możliwości oceniać program
wyłącznie poprzez ilość linii kodu. Co więcej jasne jest,
że ta sama funkcjonalność będzie inaczej
zaimplementowana w różnych językach
programowania, zatem dla każdego z nich trzeba
wprowadzać bądz
inne miary, bÄ…dz
chociaż
odpowiednie wagi. Większość metod sprowadza się
właśnie do mierzenia ilości kodu wraz z odgałęzieniami
oraz przemnażania to przez odpowiednie wagi.
Procedury są zwykle bardzo złożone i bez odpowiednich
narzÄ…dzi komputerowych praktycznie nie wykonalne.
Pamiętajmy jednak, że i tak nie ma jak zmierzyć
pracochłonności dla bardzo nietypowego algorytmu,
który wpierw należy zrozumieć.
Koszt  obie wymienione powyżej miary można do
jakiegoś stopnia przeliczać na koszt tworzonego
programu, choć pamiętajmy, że koszt to nie tylko
ludzie. Jednym z najlepszych modeli szacowania
kosztów jest COCOMO opisany Bohema i Putnama. Za
jago pomocą możemy oszacować całkowity koszt
tworzenia projektu.
Złożoność  jak to podkreśla Szyjewski, złożoność nie
71
jest szczęśliwą nazwą, gdyż sugeruje, że kod jest
trudno pielęgnować i zmieniać. Stąd też raczej powinno
się mówić o jaką złożoność chodzi, i tak może to być
złożoność obliczeniowa odnosząca się do czasu jaki
dany program potrzebuje by rozwiązać dane zadanie,
jako taka nie wpływa na koszt realizacji przedsięwzięcia.
Możemy też mówić o złożoność psychologicznej jako
pewnym intuicyjnym postrzeganiu miary komplikacji
programu.
Niezawodność  jasne jest, że każdy program
potencjalnie zawiera błędy, co więcej nie można
stwierdzić, że ich nie ma w ogóle. Stąd też do pomiaru,
a raczej szacowania, niezawodności stosuje się metody
statystyczne.
Jakość  podobnie jak niezawodność jest pojęciem
płynnym i trudno mierzalnym, stąd też stosuje się
również metody statystyczne.
3.2 ZarzÄ…dzanie zakresem projektu
informatycznego
Niewątpliwie najważniejszym elementem w zarządzaniu
projektem informatycznym jest sporządzenie planu działań.
Dobre ich zaplanowanie i podział prac wpłynie na prawidłowy
przydział zasobów, obniżenie kosztów i sprawność działań
projektowych. Oczywiście najlepszy plan wez
mie w łeb, jeśli
nie będzie prowadzonego nadzoru nad jego wykonanie.
Jednak nadzór nad wykonaniem nie wchodzi bezpośrednio w
zarzÄ…dzanie zakresem, a raczej sprowadza siÄ™ do nadzoru nad
pracownikami. Niemniej jednak śledzenie postępu prac jest
ściśle związane z kontrolą zakresu prac, gdyż może wpłynąć
na konieczność zawężenia zakresu prac w przypadku
występowania opóz
nień.
Stąd też możemy wymienić następujące etapy związane z
zarzÄ…dzaniem zakresem projektu:
Planowanie  działania skoncentrowane wokół
72
określenia (zdefiniowania) zakresu systemu i działań
niezbędnych do jego realizacji.
Zmiana zakresu  świadome wprowadzania zmian w
poczÄ…tkowym planie, zatem tworzenie
zmodyfikowanego planu w taki sposób by projekt został
zakończony w założonym (bądz
zmodyfikowanym)
czasie i budżecie.
3.2.1 Planowanie prac
Planowanie prac zwykłe odbywa się etapami, w zależności
od przyjętej metody działania ilość tych etapów może być
różna. Spróbujmy zaproponować przykładowy podział:
1. Pozyskanie informacji od klienta  na ich podstawie
których definiowane są zadania do wykonania.
Przypomnijmy, że informacje te to zwykle co najmniej
założenia funkcjonalne jak i niefunkcjonalne.
2. Definicja zadań  na podstawie pozyskany informacji
definiowane sÄ… zadania potrzebne do realizacji celu
projektu.
3. Ocena zadań  powinna być ona przeprowadzana pod
różnym kątem, co najmniej ze względu czasu
potrzebnego na realizacjÄ™ zadania oraz koniecznych
zasobów potrzebnych do realizacji (zarówno ludzi, jak i
sprzętu i oprogramowania). Ale często również,
przeprowadza sie analizę wykonalności, czyli czy dane
zadanie jest w tym zakresie wykonalne. Oczywiście jest
to dobre miejsce do identyfikacji ryzyka w projekcie (o
czym więcej w punkcie ???).
4. Szeregowanie zadań  każde zadanie powinno mieć
zidentyfikowanych swoich poprzedników oraz
następników. To znaczy należy określić, które zadania
są niezbędne do jego wykonania, a które mogę być
wykonane równolegle. Podobnie, musimy mieć
świadomość jakie zadanie nie będą mógł być
zakończone, lub rozpoczęte bez zakończenia
rozważanego zadania.
73
5. Finalny plan  etap łączenia całej wiedzy o zadania w
zbiorczy harmonogram i plan prac.
Zauważmy, że szeregowanie zadań oraz ocena czasu
potrzebnego na ich realizację są ściśle związane i z nich też
wprost wynika harmonogram prac.
Jest oczywiste, że efektem finalnym planowania powinien
być plan, przy czym dąży się do tego, by był on w pewnej
sformalizowanej postaci. Przy czym nie chodzi tu o formalizm
matematyczny, a raczej pewien szkielet dokumentu, który
powinien zawierać elementy niezbędne w każdym planie.
Spróbujmy wymienić te składowe:
Wprowadzenie  część opisowa, której celem jest
podanie ogólnej charakterystyki projektu i jego zakres.
Główne założenia  powinien znalez
ć się tu opis
technologi jakie będą użyte w rozwiązaniu wraz z
uzasadnieniem. Opis metod zarządczych przyjętych w
projekcie, w tym odniesienie do sposobu kontaktu i
rozliczania podwykonawców, jeśli tacy w projekcie
wystÄ…piÄ….
Założenia projektu  część ta powinna zawierać w
postaci skondensowanej wymagania użytkownika, jego
ograniczenia raz potencjał (zasoby przez niego
dostarczane). Ponadto powinno siÄ™ wyraz
nie określić
sposoby komunikacji, skład komitetu sterującego,
procedury przeglądu projektu oraz śledzenia postępów.
Wykaz niezbędnego do realizacji sprzętu i
oprogramowania wraz z terminem dostaw.
Lista zadań  lista kluczowych zadań wraz z
określeniem punktów węzłowych. Każde zadanie
powinno mieć oszacowany czas wykonania wraz z
określeniem jednostek odpowiedzialnych za jego
realizację. W przypadku korzystania z usług
podwykonawców, należy uzgodnić listę zadań z nimi.
Lista zasobów  wykaz wszelkich zasobów, które są do
dyspozycji do realizacji zadań. Jednym z
najważniejszych będą zasoby finansowe inwestora
74
przeznaczone na realizacjÄ™ projektu. Ale powinno siÄ™
również wyszczególnić sprzęt przeznaczony do tych
zadań, biura (pomieszczenia), inne specjalne zasoby.
Jednym z najważniejszych zasobów są ludzie, stąd
powinno się wyszczególnić potrzeby projektu w tym
zakresie. Pamiętajmy, że zapotrzebowanie na siłę
wykonawczą będzie się zmieniało w czasie, ten fakt też
powinien być pokazany. W tym miejscu powinno
również wyszczególnić sie specjalistów i konsultantów
zewnętrznych wraz z chwilą czasową w której będą
niezbędni. Dla personelu wykonawczego należy określić
co oni będą potrzebowali, w tym ilość i rodzaj szkoleń.
Metody kontroli i oceny  lista sposobów kontroli
postępu prac oraz oceny realizacji poszczególnych
zadań.
Ocena ryzyka  wstępna analiza czynników
krytycznych w projekcie, wraz z ryzykiem jakie ze sobÄ…
niosą. Więcej o identyfikacji i ocenie ryzyka znajduje się
w rozdziale 5.
Bardzo dobrze, jeśli plan projektu zawierać będzie
schematy i rysunki ułatwiające zrozumienie zależności
organizacyjnych czy przepływu danych (informacji) w
projekcie. Również lista zadań może być wzbogacona o
wykres Gantta, lub chociaż szkic harmonogramu. Dla
wszystkich miejsc, gdzie da się wyliczyć pewną wartość
dobrze jest dołączyć zarówno algorytm według którego
została ona wyliczona, jak i same obliczenia. Dla przykładu,
gdy szacowane są przepustowości łącz internetowych, czy
wydajność serwerów, można bez większego problemu
dołączyć obliczenia.
Należy pamiętać, że wciąż większość projektów
informatycznych ma unikalny charakter, stąd też może
posiadać odmienny od innych, plan realizacji. Wszelkie
nietypowe zachowania zarzÄ…dcze czy projektowe
(inżynierskie) powinny być opisane juz na tym etapie.
75
3.3 Tworzenie harmonogramu (wykres Gantta,
techniki sieciowe wymiarowanie sieci)
3.4 ZarzÄ…dzanie zakresem projektu (planowanie
prac, struktura prac, punkty węzłowe)
3.5 Określanie budżetu projektu (szacowanie,
sposoby przenoszenia kosztów
3.6 Określanie zasobów potrzebnych do
realizacji projektu
3.7 Monitorowanie postępów prac
3.8 Narzędzia wspomagające
Obecnie coraz więcej działań człowieka wspieranych jest
poprzez różnego rodzaju programy komputerowe. Nie inaczej
jest w przypadku projektów informatycznych, nawet można
spodziewać się zdecydowanie większego wykorzystania
technik informatycznych niż gdzie indziej. Z dużą dozą
pewności możemy stwierdzić, że do każdego typów działań
związanych z projektem można znalez
ć co najmniej kilka
programów, które można wykorzystać do wspomagania
danego procesu. Spróbujemy pokrótce scharakteryzować
niektóre grupy tych programów używając do tego
przykładowych reprezentantów.
Ciężko wprowadzić jednoznaczną klasyfikację, które
czynności projektowe są ważniejsze, stąd też poniższy podział
jest jedynie tematyczny i nie należy się sugerować
kolejnością podpunktów.
76
3.8.1 Narzędzia pracy grupowej
Niewątpliwie ciężko wyobrazić sobie efektywną wymianę
informacji w zespole już kilkuosobowym, bez dodatkowych
narzędzi informatycznych. Należy pamiętać, że zespoły
programistyczne bywają kilkunastu-, a nawet kilkudziesięciu-
osobowe. W takich warunkach, nie tylko należy zapewnić
narzędzia do komunikacji bezpośredniej, ale również
wspierające archiwizowanie ustaleń i zdolne do efektywnego
przeszukiwania dużych zbiorów informacyjnych. Wymieńmy
przykładowe narzędzia:
Poczta elektroniczna  narzędzie już tak powszechne
obecnie, że powoli przestaje się mówić o nim jako
czymś obowiązkowym, gdyż po prostu staje się czymś
oczywistym jak telefon komórkowy. Niemniej jednak
przypomnijmy, że jest to najprostsza metoda
dystrybucji poleceń oraz przekazywania informacji, jak
raporty i sprawozdania. Posiada ona tÄ™ zaletÄ™ w
stosunku do telefonu, że nie zobowiązuje do
natychmiastowego odbioru, zatem nie przerywa
ważnego zebrania. Wszyscy członkowie zespołu powinni
posługiwać się pocztą, choć należy zauważyć, że po
stronie klienta nie musi być to oczywiste narzędzie.
Stąd też mimo oczywistości tego narzędzia wśród
informatyków, powinniśmy w miarę możliwości
przekonać do niego klienta.
Listy dyskusyjne  zwykle stosuje siÄ™ mailowe listy
dyskusyjne, choć można stosować je wymiennie z
forami dyskusyjnymi. Zauważmy, że w przypadku
archiwum mailowej listy dyskusyjnej, dostępnego przez
WWW, funkcjonalność jest podobna. Ta forma
komunikacji jest bardzo pożyteczna jako narzędzie
wymiany informacji pomiędzy grypami osób
pracującymi nad pewnym zadaniem. Można zauważyć,
że zawsze tworząc duży projekt personel jest dzielony
na pewne podgrupy wykonawcze. Co więcej jedna
osoba może być członkiem kilku grup. Wymiana
77
informacji pomiędzy listy dyskusyjne ułatwia
dystrybucje informacji pomiędzy wszystkimi członkami
oraz stanowi automatycznie pewnÄ… bazÄ™ wiedzy, stÄ…d
konieczność archiwum z dostępem przez WWW.
Komunikatory sieciowe (Instant Messaging) 
podobnie jak mail i listy dyskusyjne komunikatory
sieciowe wspomagajÄ… komunikacjÄ™, przy czym kontakt
jeden-do-jednego odpowiada listowi elektronicznemu,
podczas gdy pokoje rozmów stanowią pewien substytut
list dyskusyjnych. Pamiętajmy jednak, że jest to bardzo
dobra forma wymiany informacji doraz
nej, jednak
stosuje ją sie praktycznie wtedy gdy osoba z którą
chcemy porozmawiać jest obecna. Stąd odpowiada to
innej formie komunikacji bezpośredniej jaką jest
rozmowa przez telefon.
Chat  podobnie jak pokoje rozmów realizowanych za
pomocą komunikatorów sieciowych spełnia rolę
narzędzia wspomagającego konwersację grupową za
pomocÄ… sieci.
Narzędzia do ewidencji pracy  każdy członek
zespołu powinien na bieżąco informować o postępach
swojej pracy. Z punktu widzenia śledzenia postępów
prac i monitorowania opóz
nień najwygodniej korzystać
jest z narzędzi, które będą to wspierać.
Bazy wiedzy  do niedawna poprzez bazy wiedzy
rozumiano różnego rodzaju zbiory informacji o
projekcie. W tym spis wymagań funkcjonalnych i
niefunkcjonalnych wraz z kolejnymi uzgodnionymi
zmianami. Kolejnym zbiorem wiedzy jest doświadczenie
twórców w zakresie użytkowanych środowisk
programistycznych. Od pewnego czasu dąży się by
wiedzę tą umieszczać w pewnych specjalizowanych
programach, które będą wspomagały magazynować i
wyszukiwać informację.
Zintegrowane narzędzia pracy grupowej  w
zależności od wielkości projektu, doświadczenia firmy
realizujÄ…cej zadania stosuje siÄ™ coraz bardziej
78
wyrafinowane narzędzia. Jednym z nich są programy do
wspomagania pracy grupowej. Składają się one w
większości z tych cech jaki omówiliśmy powyżej.
Dodatkowo zawierajÄ… kalendarz z organizerem, listÄ™
zadań (TO DO), możliwość wymiany plików 
repozytoria dokumentów, i wiele innych, których celem
jest stworzenie jednego wspólnego miejsca
wspomagającego pracę w dużej grupie osób.
3.8.2 Narzędzia programistyczne
Obecnie chyba wszystkie metodologie tworzenia
oprogramowania mówią o konieczność stosowania narządzi
wspierających tworzenie oprogramowania. W zależności od
przyjętej metody działania są to mniej lub bardziej
zaawansowane i zautomatyzowane programy. Znów
spróbujmy wymienić najważniejsze grypy:
Zintegrowane środowiska programistyczne (IDE)
 jest to w tej chwili tak standardowa rodzina narzędzi,
że nawet nie prowadzi sie o nich dyskusji, ani też nie
wymienia jako obowiÄ…zkowego elementu. Nie ma mowy
o efektywnym tworzeniu aplikacji bez takich narzędzi.
Wynikają one najczęściej z przyjętego sposobu realizacji
zadań. W przypadku klasycznego programowania, będą
to mniej lub bardziej zaawansowane środowiska
programistyczne. Jeśli jednak firma stosuje metodologię
RAD, to zwykle środowiska te zawierają bardzo doże
wsparcie do generowania kodu Å‚Ä…cznie z dokumentacjÄ….
Narzędzia do tworzenia dokumentacji 
przypomnijmy, że w projekcie mamy dwa zasadnicze
typy dokumentacji: projektowa i użytkownika. Do obu z
nich stosuje się podobne narzędzia, są to: edytory
tekstu  do tworzenia opisów, edytory diagramów  do
tworzenia schematów organizacyjnych czy przepływu
danych, narzędzia do opisu baz danych i wiele innych.
Dodatkowo stosuje się specjalizowane narzędzia do
tworzenia plików pomocy, które dołączane są do
79
programu.
Systemy kontroli wersji  jasne jest, że nie ma mowy
o tworzeniu projektu bez wsparcia dla wersjonowania
zmian. Co więcej należy wersjonować nie tylko kod
programu, ale również dokumentację, czy też pliki
związane z uzgodnieniami. Takie podejście zapewnia
Å‚atwiejsze odtworzenie historii zmian. Obecnie na rynku
już jest bardzo dużo systemów kontroli wersji, w
zależności od stopnia skomplikowania projektu można
wybrać prostsze lub bardziej zaawansowane
rozwiązania. Niewątpliwie, należy pamiętać, że przy
dużych projektach nie unikniemy tworzenia kolejnych
wersji programu (tzw. tags) oraz odgałęzień (branches),
zatem wybór powinien oscylować wokół narzędzi, które
wspierają te rozwiązania. Przy dużej ilości osób w
projekcie należy przemyśleć czy nie warto użyć
systemu wspierajÄ…cego tzw
. zmiany atomowe.
3.8.3 Narzędzia wspomagające zarządzanie
Tworzenie harmonogramu  dopóki projekt jest
niewielki, składa sie kilkunastu zadań, można tworzyć
harmonogram wręcz na kartce. W przypadku dużych
projektów nie ma takiej możliwości i zdecydowanie
należy stosować narzędzia, które nie tylko umożliwiają
zapis harmonogramu w postaci wykresu Gantta, ale
dodatkowo pozwalają przydzielać zasoby (w
szczególności ludzkie), wraz z ich zaangażowaniem w
trakcie realizacji konkretnego zadania. Takie narzędzia
po przydzieleniu zasobów i określeniu ich kosztów
pozwalają określać koszt całego projektu, stąd też
ułatwiają budżetowanie.
Śledzenie postępu prac  programy do wspierania
śledzenia postępu prac są zwykle ściśle związane z
programami do tworzenia harmonogramów
przynajmniej w ich części zarządczej. Zatem kierownik
patrząc na harmonogram widzi nałożone na niego
80
wykonania, co pozwala mu w łatwy sposób stwierdzić
ewentualne opóz
nienia czy też szybsze wykonanie prac.
Z punktu widzenia pracownika, sÄ… te programy
powiązane z rozliczaniem czasu pracy, często są to
osobne moduły tego samego programu. Dzięki temu
pracownik wprowadzając postęp prac jednocześnie
informuje kierownika o tym fakcie.
81
4 ZarzÄ…dzanie zasobami
Poprzez zasoby w projekcie informatycznym rozumiemy
zarówno ludzi jak i zasoby w postaci sprzętu komputerowego,
pomieszczeń i inne niezbędne do wykonania zadania.
Poprzez zarządzanie zasobami będziemy rozumieli
wszelkie działania, które mają za zadanie między innymi:
Oszacowanie jakie potrzebujemy zasoby i w jakiej ilości.
Pozyskanie tych zasobów.
Rozplanowanie prac, tak by wykorzystać jak najlepiej
posiadana i pozyskane zasoby.
Skoncentrujemy siÄ™ przede wszystkim na zarzÄ…dzaniu
zasobami ludzki, co wydaję się najważniejszym elementem w
projektach informatycznych. Zarządzanie pozostałymi
zasobami opiszemy na sam koniec.
4.1 Tworzenie zespołu
Zanim zespół zostanie stworzony należy dobrze zrozumieć
co najmniej dwie poniższe rzeczy:
Cel tworzenia zespołu.
Zadania, które zespół ma realizować.
Obie powyższe rzeczy są ze sobą ściśle powiązane, by
wyznaczyć ich zakres niezbędne jest dobre zrozumienia
zakresu projektu. Stąd przed organizacją zespołu musimy go
82
znać. Oczywiście w przypadkach, które omawiamy cel można
strywializować i powiedzieć: celem jest stworzenie lub
wdrożenie pewnego systemu informatycznego. Należy jednak
pamiętać, że tak określony cel składa się określonych kroków
przedsięwzięcia, które można postrzegać właśnie jako
zadania dla zespołu. Dobre zrozumienia ich wszystkich,
pozwoli dobrać właściwych członków zespołu.
Należy pamiętać, że zespół ludzi jest żywym organizmem,
którego celem jest wspólna pracy w efekcie której ma
powstać określony wcześniej projekt. Dobrze działający
zespół w projekcie informatycznym to grupa twórczych ludzi,
który wzajemnie się wspierają, inspirują i motywują do pracy.
Dobrze dobrany zespół charakteryzuje się następującymi
cechami:
Silne, zdecydowane, mądre i rozsądne przywództwo.
Jasno sprecyzowane zadania.
Umiejętność podejmowania szybkich decyzji i
wdrażanie ich w życie.
Perfekcyjne wykorzystanie cech i umiejętności
poszczególnych członków zespołu.
Otwartość i szczerość wymiany informacji i wiedzy.
Harmonia i spokój we współdziałaniu.
Literatura wskazuje, że zwykle dobry zespół, czyli taki,
który ma posiadać wymienione wyżej cechy oraz będzie
działał skutecznie, składa się z 2-25 osób. Faktycznie przy
zespołach twórczych, czyli właśnie takich, z którymi mamy do
czynienia w projektach informatycznych przekraczanie liczby
25 osób jest ryzykowne, gdyż w większych zespołach bardzo
ciężko utrzymać jest spójność projektu. Oczywiście zdarzają
się projekty, które wymagają
Przy szacowaniu ilości osób oraz ich charakteru, należy
brać pod uwagę jakie zadania stoją przed zespołem. Zwykle
wszystkie zadania można podzielić na trzy podstawowe
kategorie:
1. Czynności rutynowe  wszelkie czynności, które mają
83
charakter powtarzalny i zwykle niezależne od innych
członków zespołu. Na przykład wypełniania formularza
indywidualnego rozliczenia czasu pracy.
2. Zadania twórcze  do tych zadań należy większość
działań projektowych. Zarówno analitycznych jak i
programistycznych, choć część działań pisania kodu
jako takiego daje się podciągnąć pod czynności
rutynowe.
3. Zadania ściśle twórcze  wszelkie czynności, które
wymagają ciągłej kreatywności. Zwykle dotyczą one
osób na stanowiskach kierowniczych.
Nie tylko dobór członków do zespołu jest ważny, ale też
organizacja zespołu może mieć kluczowe znaczenia dla
prowadzenia prac. Zwykle mówimy o dwu podstawowych
rodzajach zespołów:
Zespół formalny  zwykle skład osób jest ustalony i nie
ulega częstym zmianom, struktura organizacyjna jest również
formalna z ustalonym zakresem obowiązków dla każdej
funkcji. Zespół taki realizuje powierzone mu zadania, zwykle
rutynowe, i ściśle rozlicza się z ich wykonania. Zwykle też
zadania mu powierzone są ściśle określone. Organizacja
pracy jest ściśle określona i kierownik przestrzega dyscypliny,
w tym prowadzi kontrole i ścisły nadzór nad postępem prac. Z
postępów prac sporządzane są sprawozdania.
Zespół nieformalny  są to robocze grupy pracowników
powołane do realizacji mniejszych zadań o nieprecyzyjnym
zakresie. Rozliczanie prac jest mniej formalne, na przykład w
postaci sprawozdania ustnego. Zadania powierzane takim
zespołom nie mogą być bardzo czasochłonne, gdyż
w przeciwnym razie będzie bardzo trudno rozliczyć ich pracę.
W rzeczywistych projektach informatycznych, zespół
projektowy jest zwykle formalnym zespołem, inaczej byłoby
trudno rozliczyć ich pracę. Natomiast w ramach prac
projektowych kierownik powołuje mniej formalne grupy do
realizacji trudniejszych, lub gorzej określonych zadań. Wtedy
te grupy maja charakter nieformalny. Sposób pracy i jej
84
organizacja zależy od Kierownika Projektu.
Kolejną ważną sprawą jest dobre zrozumie i co ważniejsze
uświadomienie wszystkim członkom zespołu, że tworzenie
projektu informatycznego jest pracą zespołową. Stwierdzanie
to wydaje się oczywiste i trywialne, jednak bardzo często
uczestnicy o tym zapominajÄ… nie potrzebnie udowadniajÄ…
swoje racje. Dzieję się tak przede wszystkim gdyż zespół w
projektach informatycznych składa się z silnych
indywidualności, co więcej zwykle im wyższa funkcja tym
silniejsza osobowość. Takie osoby nie zawsze umieją
współpracować, a za to lubią udowadniać, że są lepsi od
innych. Stąd uświadamianie, że zespół nie jest grupą
rywalizacji a grupą współpracy jest istotne i zwykle jest to
ciągły proces. Nie należy o tym zapominać również na samym
początku, w trakcie tworzenia zespołu, jeśli kierownik ma do
wyboru osoby o tych samych kompetencjach i doświadczeniu,
ale różnicę sie aspektem zdolności pracy w grupie, to pewnie
dokona wyboru osoby, która będzie umiała współpracować.
Dobierając osoby do zespołu należy kierować się myślą o
wzajemnym uzupełnianiu umiejętności i kompetencji. Każda
osoba w zespole posiada pewien zasób wiedzy pewne
zdolności, część z nich może być potrzebna bezpośrednio w
projekcie, część z nich być może będzie potrzebna kiedyś.
Należy dbać o to, by zespół swoimi umiejętnościami pokrywał
całą przestrzeń potrzeb w danym projekcie. Osobną sprawą
jest fakt, że potrzeby projektu zmieniają się w czasie, na
przykład na początku potrzeba więcej analityków a pod koniec
projektu więcej osób testujących. Zatem kierownik musi w
trakcie tworzenia zespołu przewidywać również te zmienne
elementy.
W tym miejscu docieramy do najważniejszego elementu
tworzenia zespołu jakim jest funkcja Kierownika Projektu.
Zespół tworzony jest zwykle przez niego, ale warto również
wiedzieć jakie zadania jemu przypadają w udziale. Szersze
omówienie zakresu zadań Kierownika Projektu znajduje się w
punkcie 4.5.
85
Spróbujmy teraz w oparciu o to co było napisane powyżej
w punktach wypisać na co należy zwracać uwagę dobierając
osoby do zespołu:
1. Przed rozpoczęciem rekrutacji należy sporządzić spis
funkcji jakie będą występowały w zespole wraz z ich
krótką charakterystyką potrzebnych kompetencji. Taki
spis pomoże stwierdzić jakich osób poszukujemy.
2. Dobrze jest wybierać osoby wszechstronnie uzdolnione,
gdyż takie wypełniają swoimi umiejętnościami więcej
obszarów projektu. Pamiętać należy jednak o tym, że
każdy człowiek podsiada jedną głowę i dwie ręce,
zatem nie może pełnić 5 ról i pracować efektywnie.
3. Należy mieć świadomość, że każdy uczestnik zespołu
posiada wady. Należy pamiętać o tych wadach, gdyż
niektóre z nich mogą być z
ródłem ryzyka. Świadomość
wad nie musi przekreślać kandydata, wystarczy
czasami nie powierzyć mu określonego zadania.
4. WybierajÄ…c kandydata z grupy o podobnych
umiejętnościach i doświadczeniu, wybierać należy
takiego, który umie współpracować w grupie i
przyniesie jej jak najwięcej pożytku.
5. Należy szukać osób ze zdolnościami interpersonalnymi.
Takie osoby będą bardzo dobrymi kandydatami do
pracy w grupie, będę umiały powiedzieć nie i tak we
właściwym momencie. Będą rozumiały, że stanowią
element większego organizmu.
6. Należy traktować grupę jak żywy organizm i zwracać
uwagi na jej braki. Jeśli kierownik ma świadomość tych
niewypełnionych miejsc zdolności grupy, to
natychmiast będzie miał odpowiedz
na pytanie kogo
potrzebuje.
7. Należy przedkładać doświadczenie nad wiedzę
teoretyczną. Do zespołu mogą zgłaszać się osoby o
różnym doświadczeniu i różnym zasobie wiedzy
wyniesionej ze szkoły. Należy pamiętać, że wiedza
wyniesiona z książek, choć bardzo ważna nie zapewnia
86
odpowiedniej wyobraz
ni w projekcie, która może dać
doświadczenie.
Z drugiej strony spróbujmy wypisać błędy jakie mogą się
zdarzyć przy tworzeniu zespołu:
1. Nie każda rola/funkcja w zespole jest dla każdej osoby.
Zatem wyznaczajÄ…c pracownika na konkretnÄ… funkcje,
należy kierować sie jego kompetencjami nie zaś
własnymi sympatiami.
2. Nie wolno ufać tylko swoim opiniom. Kierownik Projektu
jest tylko człowiekiem i może się pomylić, wybierając
osobę, powinien korzystać nie tylko z własnego
doświadczenia, wiedzy oraz intuicji, ale może i powinien
skonsultować decyzje z innymi zaufanymi osobami.
3. Nie należy rezygnować z kandydata tylko dlatego, że
nie jest on idealny. Czasami jest lepiej wybrać gorszego
pracownika niż próbować wykonać pracę mniejszą
ilością osób. Bywa tak, że nie znajdujemy idealnego
kandydata, ale być może najlepsza ze znalezionych
osób rokuje szansę rozwoju. Jeśli tak należy to
przemyśleć, gdyż pracę nie zawsze da się wykonać
mniejszą ilością osób.
4. Należy usuwać osoby, które się nie sprawdzają. Nie
należy sądzić, że zespół nie zauważy błędów i braków
innych członków. Jeśli jest osoba w zespole, która
nagminnie się nie sprawdza, należy ją usunąć. Inne
osoby w zespole widzą błędy i nie reagując nie tylko
powierzamy zadania nierzetelnej osobie, ale jeszcze
tracimy bardzo w oczach pozostałych członków.
5. Nie należy zatrudniać osoby o bardzo wąskiej
specjalizacji. Osoby o wÄ…skiej specjalizacji sÄ… trudne do
zagospodarowania, gdy nie ma dla nich pracy. Osoba,
która nie pracuje wpływa de motywująco na zespół.
Jeśli istnieje zapotrzebowanie na umiejętności tej
osoby, a nie ma innego kandydata, należy przemyśleć
możliwość zatrudnienia takiej osoby jako konsultanta na
krótki okres czasu.
87
4.2 Praca z istniejącym zespołem
Dobór początkowy zespołu jest bardzo ważny i od niego
często zależy sukces całego przedsięwzięcia, jednak należy
pamiętać, że przy dużych projektach informatycznych zespół
będzie się zmieniał w czasie i nie wolno tego procesu
bagatelizować. Zauważmy, że mogą następować zmiany
wynikajÄ…ce z kliku przyczyn:
Zmienne w czasie potrzeby projektowe. WynikajÄ… one z
normalnego cyklu życia oprogramowania. Wyraz
nie to
widać na przykładzie modelu kaskadowego. Wpierw
potrzebni są analitycy i właściwie zbędni programiści.
Następnie projektanci, dopiero programiści i na koniec
testerzy.
Naturalna rotacja pracowników. Każdy członek zespołu
ma praco zmienić pracę, z dowolny przyczyn.
Oczywiście kierownik może i powinien go próbować
zatrzymać, jednak nie może tego zrobić na siłę.
Wypadki losowe. Ciężka choroba lub nawet zgon
członka zespołu może być przyczyną zaburzeń w
działaniu całego zespołu.
Oczywiście najbardziej naturalną przyczyną rotacji
pracowników w zespole są zmieniające się potrzeby w
zakresie samego projektu. Niemniej jednak niezależnie od
przyczyny zmian, kierownik musi być przygotowany na takie
sytuacje i powinien reagować natychmiastowo. Powinien
próbować zrównoważyć brak lub nadmiar pewnych
umiejętności w zespole.
Zwykle jednak dba się o to by skład zespołu nie ulegał
częstym zmianą, stąd też i działania kierownika raczej
skupione są na doborze pracowników na samym początku
projektu. Więcej pracy kierownik ma z istniejącym zespołem z
zakresie tak rozdzielania zadań jak i śledzenia wykonania
prac, oraz nie mniej ważne odpowiedniej motywacji
pracowników, o czym piszemy poniżej.
88
4.2.1 Przydział zadań
Z planu projektu wynika jakie zadania muszą być
zrealizowane, by zakończyć kolejne etapy i ostatecznie
zrealizować cały projekt. Rolą kierownika jest skojarzenie
poszczególnych osób z zadaniami, czyli przydzielenie zadań
do realizacji określonym pracownikom.
Przydzielając zadania kierownik musi pamiętać o wielu
aspektach, każdy z nich może niesie ze sobą pewne
konsekwencje. Wymieńmy kilka z tych aspektów:
Zadanie może być, w tym samym czasie,
realizowane przez kilka osób  dość częsta sytuacji
przy zadaniach większych. Nie jest to jednak zawsze
wygodne, choćby z przyczyn rozmycia
odpowiedzialności. W takim przypadku albo należy
wyznaczyć osobę odpowiedzialną za realizację tego
zadania, albo podzielić zadanie na mniejsze.
Jeden pracownik może, w tym czasie, realizować
kilka zadań  znów jest to częsta sytuacja i również
niesie ona za sobą pewne niedogodności. Wszak
pracownik może wykonując jedno z zadań
nieświadomie opóz
niać inne. Jest szalenie ważne, by
każde z zadań miało jasno określony nie tylko termin
realizacji, ale również priorytet, w takim przypadku,
można wykonywać je od najważniejszego do najmniej
ważnego. Oczywiście w przypadku zastosowania
priorytetów, nasuwa się naturalny wniosek, by zadania
jednak ustawić w kolejkę, a za to skrócić czas realizacji
każdego z nich.
Bywają zadania, które musi wykonywać kilka
osób jednocześnie  spróbujmy wyobrazić sobie
zadanie do którego potrzebny jest konsultant, który
weryfikuje od czasu da czasu czy zadanie jest
realizowane zgodnie z założeniami. Znów ciężko
podzielić takie zadanie na wiele mniejszych i określać,
że 1 dzień kodowanie, 2 godziny konsultant, 2 dni
89
kodowanie, 3 godziny konsultant. Taka granulacja
wprowadzi totalny chaos i utrudni kontrolÄ™.
Bywają zadania, które zawsze będą występowały
obok innych  jednym z przykładów takich zadań jest
dokumentowanie kodu. Nie sposób oddzielić tego
zadania i wymusić, by pracownik przez np. 4 dni w
tygodniu pisał program, a przez 1 dzień dokumentował.
Taki podział mógłby tak naprawdę wprowadzić więcej
zamieszania niż pożytku. Oczywiście takie zadanie
można potraktować jako po prostu  kodowanie z
odpowiednią procedurą jakości w której jest zapisane,
że należy kod dokumentować. Jednak będą inne
zadania, które również mają taki charakter i nie należy
zawsze się upierać na zamianie zadań z równoległych
na sekwencyjne.
Przydział zadań powinien opierać się na
kompetencjach pracowników  oczywiste jest, że
najlepiej wykona dane zadanie, osoba, która
zagadnienie rozumie i ma w nim doświadczenie. Jednak
nie zawsze mamy do dyspozycji odpowiedniÄ… liczbÄ™
osób o odpowiednich kwalifikacjach, w takiej sytuacji
należy rozważyć wdrożenie naszych pracowników do
nowego charakteru zadań lub zatrudnienie osób z
zewnÄ…trz. Decyzja o tym jakie rozwiÄ…zanie jest lepsze
powinna być oparta o kalkulacje co przyniesie szybszy i
lepszy efekt. Zauważmy, że nasz pracownik jest
wdrożony w procedury i sposób pracy obowiązujący w
organizacji, ale za to nie posiada odpowiedniej wiedzy
merytorycznej z zakresu rozważanego zadania. Podczas
gdy osoba z zewnątrz będzie posiadał wiedzę
specjalistyczną, ale nie będzie musiał umieć to wykonać
tak jak my tego oczekujemy (zna inne narzędzia, inny
język programowania itp.). Rozważmy pewien przykład.
W projekcie jest zadanie wymagajÄ…ce specjalistycznej
wiedzy za zakresy projektowania konstrukcji
mechanicznych. Można oczywiście potraktować, że
rozwiąże sprawę konsultant, ale spróbujmy przyjąć, że
90
tak nie może się stać i że potrzebujemy własnego
projektanta lub programisty. Pytanie co trwa dłużej,
wdrożenie w organizację czy pozyskanie wiedzy
specjalistycznej, w tym przypadku dość oczywiste jest,
że pozyskanie wiedzy z konstrukcji mechanicznych.
Jednoznaczna odpowiedzialność  każde zadanie
powinno mieć określoną osobę, która będzie
odpowiadała za jego realizację. Jak pasaliśmy wcześniej
osób realizujących może być więcej, ale
odpowiedzialność powinna być skupiona, w przeciwnym
razie może się okazać, że nie będzie winnego w
przypadku niedociągnięć.
Każdy pracownika posiada umiejętności oraz ma
wady  jasne jest, że przydzielając zadanie pewnej
osobie bierzemy pod uwagÄ™ jej kompetencje, jednak nie
wolno ignorować pewnych wad. Wystarczy nadmienić,
że dana osoba nie będzie umiała pracować w grupie, by
ryzykowne było przydzielanie jej zadań gdzie
wymagana jest współpraca z innymi. Wada taka nie
musi oczywiście przekreślać w ogóle takiej osoby jako
pracownika.
Pracownika o szerszych uzdolnieniach Å‚atwiej
przydzielić do zadań  jest to dość oczywiste,
posiadając zespół pracowników o wszechstronnych
uzdolnieniach łatwiej jest rozdzielić pracę i rzadziej
wystąpi sytuacja w której pracownik nie będzie miał
pracy. Wręcz często zaleca się by nie zatrudniać osób o
wÄ…skiej specjalizacji.
Należy mieć świadomość wzajemnych interakcji
członków zespołu  im większa grupa osób, tym
większe ryzyko sytuacji, gdy jedna osoba nie lubi
drugiej, lub nie umie z nią współpracować. Stąd też
należy mieć świadomość takiej sytuacji i w miarę
możliwości nie zmuszać ludzi do pracy z nielubianymi
osobami.
Grupa jest ważniejsza niż jednostka  należy
pamiętać, że tworzenie dużych projektów to praca
91
zespołowa. Stąd mając do wyboru osobę o dużej
wiedzy, ale nieumiejętności współpracy oraz osobę o
mniejszych umiejętnościach, ale łatwo funkcjonującą w
grupie, należy wybrać tę drugą. Nie można oczekiwać,
że zespół dotrze się w trakcie pracy, po prostu grupa
silnych indywidualności nieumiejących współpracować
będzie zawsze trudna do kierowania i nie koniecznie
efektywna.
4.2.2 Motywacja, zwiększanie wydajności
4.2.3 Zebrania
4.2.4 Przeglądy wewnętrzne i zewnętrzne
4.3 Zarządzanie czasem zespołu (tworzenie
harmonogramów, rozliczanie czasu pracy)
4.4 Komunikacja w zespole (rola, przepływ,
z
ródła)
4.5 Rola kierownika projektu (podstawowe
zadania kierownika, kwalifikacje, umiejętności)
Spróbujmy zatem wyszczególnić zadania kierownika w
oparciu o to co wcześniej napisano. Zatem zadania
Kierownika Projektu, to:
Realizacja zadań zespołu przy wykorzystaniu zasobów.
Dbałość o terminowe i zgodne z budżetem
wykonywanie zadań.
Dobór członków zespołu i przydzielenie im funkcji.
92
 Kierowanie zebraniami.
Reagowanie na wszelkie odstępstwa od harmonogramu
prac.
Rozliczanie członków zespołu z powierzonych im zadań,
w tym nagradzanie za bardzo dobre wyniki i wyciÄ…ganie
konsekwencji w przypadku braków efektów.
Lojalność wobec projektu jak i zespołu, w tym
nieunikanie odpowiedzialności za błędy własne.
Inspirowanie i motywowanie członków zespołu do
lepszej i efektywniejszej pracy.
Organizacja spotkań integracyjnych oraz szkoleń
podnoszących kwalifikacje zespołu.
Rozwiązywanie konfliktów w grupie, oraz zrozumienie
wobec problemów indywidualnych członków.
4.6 Analiza zasobowa harmonogramu
93
5 ZarzÄ…dzanie ryzykiem
w projekcie informatycznym
5.1 Definicja ryzyka (y
ródła/czynniki)
5.2 Identyfikacja
94
5.2.1 Sesje identyfikacji ryzyka
5.2.2 Listy kontrolne
5.2.3 Metoda Crawforda
5.2.4 Metoda SWOT
5.3 Ocena ryzyka
5.3.1 Model kosztowy (EMV)
5.3.2 Analizy sieciowe
5.3.3 Metoda PERT
5.3.4 Drzewa zdarzeń (Event Tree Analysis)
5.3.5 Drzewa błędów (Fault Tree Analysis)
5.3.6 Metody eksperckie-delfickie
5.4 Zapobieganie występowaniu ryzyka
5.4.1 Działania zapobiegawcze
5.4.2 Metody pomiaru efektywności podjętych działań
95
5.5 Monitorowanie ryzyka
5.5.1 Monitorowanie reaktywne
5.5.2 Monitorowanie aktywne
5.5.3 PrzeglÄ…dy i audyty
96
6 ZarzÄ…dzanie wiedzÄ… w projekcie
informatycznym
6.1 y
ródła wiedzy (wewnętrzne, zewnętrzne,
ekspertowe)
6.2 Gromadzenie wiedzy (sposoby, narzędzia,
ludzie)
6.3 Przetwarzanie wiedzy (analiza, synteza)
6.4 Magazynowanie wiedzy (narzędzia,
wyszukiwanie, archiwizowanie)
97
6.5 Dokumentacja w projekcie (rodzaje,
narzędzia)
6.6 ZarzÄ…dzanie zmianami w projekcie (z
ródła
zmian, priorytet, polityka)
98
Bibliografia
[Pritchard2002] Pritchard C. L., ZarzÄ…dzanie ryzykiem w projektach.
Teoria i praktyka, WIG-PRESS, Warszawa 2002.
[Sobieski2005] Sobieski Ś., Inżynieria oprogramowania, skrypt w
wersji elektronicznej, A
ódz
2005.
[Sommerville2003] Sommerville I., Inżynieria oprogramowania, Klasyka
Informatyki, WNT, Warszawa 2003.
[Szyjewski2001] Szyjewski Z., ZarzÄ…dzanie projektami
informatycznymi. Metodyka tworzenia systemów
informatycznych, Agencja Wydawnicza PLACET, Warszawa
2001.
Indeks alfabetyczny
budżet..................................... .7, 9 kierownik projektu........................8
cel projektu..................................7 ramy czasowe..............................7
czas projektu............................7, 9 środowisko pracy.........................8
inwestor.......................................6 zakres projektu.........................7, 9
jakość..........................................9 zespół projektowy........................8