|
Ogólna charakterystyka
projektów
Zarządzanie zakresem
Zarządzanie czasem
Parametryczne szacowanie
projektów software’owych
Zarządzanie kosztem
Zarządzanie jakością
Zarządzanie personelem
Organizacja firmy
Organizacja zespołu
projektowego
Zatrudnianie personelu
Dynamika zachowań zespołu
Zarządzanie komunikacją
Zarządzanie ryzykiem
Zarządzanie zaopatrzeniem
Zarządzanie integralnością
Projekt jest to ograniczony
w czasie zbiór działań podejmowanych w celu stworzenia unikalnego produktu
lub dostarczenia usługi. W myśl tej definicji projektami są np:
- Napisanie książki,
- Przeprowadzenie załogowego lotu na Księżyc,
- Zbudowanie domu,
- Przygotowanie szkolenia,
- Utworzenie lub zakupienie systemu
informatycznego.
Projektami nie są:
- Prowadzenie poczty,
- Policyjne pilnowanie porządku,
- Eksploatacja systemu informatycznego,
- Kierowanie firmą.
(Moje uwagi na temat tak
sformułowanej definicji pojęcia „projekt” można znaleźć w tekście
poświęconym krytycznej ocenie standardów PMI).
Projekty są grupowane w
większe zespoły działań, które są nazywane programami. Na przykład
program regulacji polskiego systemu
wodnego może się składać z wielu projektów dotyczących poszczególnych rzek.
Projekty mogą być dzielone na mniejsze jednostki, zwane podprojektami.
Na przykład projekt budowy systemu telefonicznego może się składać w
wyodrębnionych części (podprojektów) mających na celu wytworzenie sprzętu,
położenie sieci i przygotowanie oprogramowania.
Projekty powinny być
podzielone na fazy. Faza jest to część projektu wyodrębniona po to,
żeby zebrać zamknięty zestaw produktów (lub półproduktów) systemu oraz
ocenić status projektu. Celem oceny statusu jest przygotowanie do podjęcia
decyzji w kwestii kontynuowania projektu.
Z projektami powiązane jest
pojęcie udziałowiec. Udziałowcem projektu jest każdy jego wykonawca,
w tym w szczególności kierownik. Udziałowcami są ci, którzy finansują
projekt – firma zlecająca jego wykonanie. Jeśli firma zlecająca projekt
jest firmą zatrudniającą wykonawców, to projekt jest projektem
wewnętrznym. W przeciwnym przypadku mamy do czynienia z projektami
zewnętrznymi. Udziałowcami projektu są przyszli użytkownicy systemu.
Ogólnie: udziałowcem jest każda osoba zaangażowana w projekt lub taka,
która jest zainteresowana wynikiem projektu. Właściwe określenie zestawu
udziałowców i przypisanie im ról (o ile jest to możliwe) jest jednym z
zasadniczych zadań kierownika projektu.
Na zarządzanie projektami
składa się dziewięć obszarów:
- Zarządzanie integralnością,
- Zarządzanie zakresem,
- Zarządzanie czasem,
- Zarządzanie kosztem,
- Zarządzanie jakością,
- Zarządzanie personelem,
- Zarządzanie komunikacją.
- Zarządzanie ryzykiem,
- Zarządzanie zaopatrzeniem.
Celem każdego projektu jest
wyprodukowanie czegoś: towaru albo usługi. Zestaw produktów, które mają być
wyprodukowane w danym projekcie to zakres produktu. Zestaw
czynności, które mają być wykonane w ramach projektu to zakres projektu.
W skład zakresu projektu wchodzą czynności procesu technologicznego – na
przykład w deweloperskim projekcie informatycznym są to wszystkie prace
prowadzące od zbierania wymagań, poprzez specyfikację systemu, projekt
architekturalny aż po wdrożenie i pielęgnację. Poza procesem
technologicznym w każdym projekcie muszą być wykonane prace zarządcze.
Pojęcie zarządzania zakresem
odnosi się bezpośrednio do zakresu projektu. Żeby zrealizować produkt
trzeba wykonać zarówno prace technologiczne jak i prace zarządcze. Ale
produkt projektu jest widoczny przede wszystkim przez pryzmat prac, które
kierownictwo projektu musi zaplanować i doprowadzić do ich wykonania.
Zadaniem kierownika projektu jest zaznaczanie wykonanych prac prowadzących
do pomyślnego – w określonym czasie i budżecie - zakończenia projektu.
Każdy projekt zaczyna się od
podjęcia decyzji o jego rozpoczęciu. Przesłanki do podjęcia tej decyzji
pochodzą z szeroko rozumianej dziedziny biznesowej. Mogą to być motywy
komercjalne, wymagania prawne, ulepszenie metod funkcjonowania firmy.
Przesłanki uruchomienia projektu muszą być zgodne z planem strategicznym
realizującej go firmy: organizacja zajmująca się hodowlą kurczaków nie
powinna tworzyć systemów informatycznych. Firma powinna mieć informacje
historyczne mówiące czy istnieje szansa poprawnego zrealizowania
konkretnego projektu. Decyzję o uruchomieniu projektu powinien zawsze
podejmować ktoś zewnętrzny względem projektu (np. członek zarządu firmy).
Podstawowymi wynikami uruchomienia projektu powinno być wskazanie
kierownika projektu oraz opracowanie dokumentu otwarcia. Dokumentem
otwarcia może (dla projektów zewnętrznych, czyli realizowanych na
potrzeby firmy innej niż realizator projektu) być kontrakt, na podstawie
którego projekt jest realizowany. Dla projektów wewnętrznych, czyli
realizowanych na potrzeby własnej firmy, dokumentem otwarcia powinna być
udokumentowana decyzja osoby upoważnionej do uruchamiania projektów.
Obok kierownika projektu
powinien być wskazany także jego sponsor, czyli osoba podejmująca
zasadnicze decyzje dotyczące przebiegu projektu. Decyzje sponsora dotyczą
kontynuowania lub wstrzymania projektu, istotnych zmian jego zakresu.
Sponsor podejmuje decyzje w zasadniczych sprawach związanych z budżetem
projektu. Odpowiedzialnością sponsora jest także stworzenie warunków do
współpracy organizacji, dla której projekt jest realizowany, z zespołem
projektu.
Drugim etapem przy
rozpoczynaniu projektów powinno być określenie wyników projektu. Poza
zasadniczymi produktami, które będą przekazywane firmie zamawiającej, przy
określaniu wyników projektu należy zawsze pamiętać o produktach, które w
przyszłości będą stanowiły dorobek firmy. Produktami takimi w projektach
informatycznych mogą być np. biblioteki, procedury działania czy
wypracowane w trakcie realizacji projektu standardy. Ubocznym produktem tej
fazy powinien być plan zarządzania zakresem, czyli określenie
odpowiedzialnych osób i procedur związanych ze zmianami zakresu.
Gdy określone są produkty
projektu, na ich podstawie należy zdefiniować Strukturę Podziału Pracy
(SPP, ang. WBS, Work Breakdown Structure). SPP na tym poziomie opracowywania
opisuje prace konieczne do wykonania poszczególnych produktów i
półproduktów. SPP ma zawsze strukturę hierarchiczną. Pierwszy poziom SPP to
technologiczne fazy projektu, wynikające zwykle ze standardowego cyklu
produkcji produktu, oraz wyróżniane jako jeden blok prac, prace zarządcze.
Poziom szczegółowości planowania na tym etapie jest wyznaczany przez zestaw
koniecznych do wytworzenia produktów i półproduktów. Na przykład dla fazy
analizy w projekcie, który jest podzielony na obszary jednostkami planowania
prac mogą być model funkcji, model danych, model wymagań – dla
poszczególnych obszarów. Planowanie prac zwykle odbywa się z wykorzystaniem
narzędzi programistycznych, z których najpopularniejszym jest zapewne MS
Project. Dla projektów informatycznych istnieją standardowe cykle produkcji
(cykle życia systemu), z których najbardziej znane to model kaskadowy,
model spiralny czy model kontrolowanych iteracji.
Uruchomienie projektu,
zaplanowanie jego produktów i koniecznych do wykonania prac odbywa się we
wstępnej, planistycznej fazie projektu. W trakcie realizacji projektu musi
istnieć procedura odbioru wykonywanych prac. Zasadniczymi składnikami
takiej procedury musi być określenie czynności prowadzących do uznania, że
dany półprodukt czy produkt spełnia stawiane przed nim wymagania oraz
wskazanie osób, które mogą podejmować decyzje w sprawie odbioru produktu.
Każdy projekt musi być
przygotowany do wprowadzania w nim zmian dotyczących procesów
technologicznych oraz czynności zarządczych. Przygotowaniem do obsługi
takich zmian jest plan zarządzania zakresem. Każda zmiana musi się odbywać
zgodnie z procedurami opisanymi w planie zarządzania zakresem.
Zarządzanie czasem obejmuje
procesy wymagane do zakończenia projektu we właściwym czasie.
Danymi wejściowymi do
planowania czasu projektu jest wyjście z procesów planowania zakresu pracy
– Struktura Podziału Pracy. Ponieważ w trakcie planowania zakresu utworzono
SPP tylko na poziomie tworzonych produktów, konieczne jest szczegółowe
zaplanowanie prac koniecznych do wykonania tych produktów. Na przykład,
żeby opracować model funkcji dla określonego obszaru tworzonego systemu,
należy zaplanować określoną liczbę spotkań z użytkownikami, przewidzieć
czas na udokumentowanie tych spotkań, musi być także czas uwzględniony na
pracę z narzędziem modelującym. Po zbudowaniu modelu w SPP trzeba
uwzględnić prace nad jego weryfikacją, poprawkami oraz przygotowaniem
dokumentu w formie możliwej do zaprezentowania klientowi. Wynikiem tych
prac jest uszczegółowiony SPP. Często spotykanym podejściem jest tworzenie
SPP na poziomie produktów (zarządzanie zakresem) dla całego projektu oraz
uszczegółowianie go do poziomu czynności przy rozpoczynaniu kolejnych faz.
Zaplanowane czynności muszą
być uporządkowane. Należy określić kolejność wykonywania czynności. Wiele
zależności wynika z natury czynności. Nie jest możliwe dokumentowanie
spotkań przed ich przeprowadzeniem. Nie ma możliwości wyprodukowania
dokumentacji w formie papierowej przed utworzeniem modelu w odpowiednim
narzędziu wspomagającym. Przy określaniu zależności należy uwzględnić także
zdarzenia zewnętrzne względem projektu – na przykład dostawa sprzętu czy
oprogramowania.
Najczęściej spotykanym
rodzajem zależności jest „koniec – początek”, oznaczająca, że określona
czynność może się rozpocząć po zakończeniu innej czynności. Przykłady
podano w poprzednim akapicie.
Zależność typu „koniec –
koniec” oznacza, że zakończenie jednej czynności jest warunkiem zakończenia
innej czynności. Przykład: zakończenie projektowania interfejsu ekranowego
musi się zakończyć po zakończeniu projektowania zestawu realizowanych
funkcji. Zwróćmy uwagę, że nie jest to zależność typu „koniec – początek”,
gdyż projektowanie interfejsu może zawierać elementy niezależne od
realizowanych funkcji (np. standardy postaci menu, standardy układu pól na
ekranie), a więc nie jest konieczne czekanie na pełne zakończenie modelu
funkcji z rozpoczęciem projektowania interfejsu.
Zależność typu „początek –
początek” oznacza, że do rozpoczęcia jednej czynności konieczne jest
rozpoczęcie innej czynności. Na przykład żeby rozpocząć prowadzenie
wywiadów z użytkownikiem konieczne jest rozpoczęcie (ale niekoniecznie
zakończenie) planowania współpracy ze stroną zamawiającą. Niektóre
współczesne metodyki zalecają pracę „na zakładkę”: rozpoczęcie
projektowania a nawet programowania przed pełnym zakończeniem specyfikacji
– warunkiem jest rozpoczęcie i pewne zaawansowanie analizy. To też jest
przykład zależności typu „początek – początek”.
Przy zależnościach typu „koniec
– koniec” oraz „początek – początek” zwykle określa się dodatkowe
opóźnienie pomiędzy wyróżnionymi zdarzeniami. W przykładzie dla zależności
„koniec – koniec” należy przewidzieć pewien czas po zakończeniu modelowania
funkcji, żeby umożliwić dokończenie projektowania interfejsu. Przy pracy na
zakładkę należy przeznaczyć pewien czas na uzyskanie odpowiedniego
zaawansowania jednej ze startujących prac (np. analiza jednak musi osiągnąć
pewien poziom zaawansowania, żeby możliwe było rozpoczęcie projektowania).
Najrzadziej spotykanym
rodzajem zależności jest „początek – koniec”. Oznacza to, że jedna czynność
musi się rozpocząć, żeby inna mogła się zakończyć. Przykładem mogłaby być
sytuacja bezpośredniego komunikowania się dwóch procesów: warunkiem
zakończenia pracy jednego z nich byłoby odebranie wyników przez inny,
rozpoczynany proces.
W praktyce ważne jest, żeby
wyróżnić procesy uszczegółowiania zestawu czynności i określania zależności
pomiędzy nimi. Mając skompletowany zestaw czynności łatwiej jest wyszukiwać
zależności pomiędzy nimi.
Po określeniu zestawu
czynności należy oszacować czas realizacji każdej czynności. Zasadniczą
podstawą do szacowania powinny być dane o wcześniej przeprowadzonych w
firmie analogicznych pracach. Każda firma powinna w sposób systematyczny
zbierać wszystkie możliwe miary dotyczące wykonanych projektów.
Opracowanie systemu zbierania danych o wykonanych pracach jest jednym z
podstawowych zadań każdej organizacji, która w sposób sterowalny zamierza
realizować projekty. Jednak jeśli informacje takie nie istnieją, również
konieczne jest wykonywanie szacunków. Podstawą może być doświadczenie
zespołu wykonującego zadania, a w szczególności kierownictwa projektu.
Kierownictwo może się wesprzeć także wiedzą zewnętrznych ekspertów.
Ponieważ informacje o czasie trwania zadań są zawsze tylko szacunkami,
zalecane jest określanie optymistycznego (najkrótszy czas, Dopt), pesymistycznego (najdłuższy czas, Dpes) oraz najbardziej prawdopodobnego dla osoby
wykonującej (Dsr) szacowania. Jeśli
dostępne są te trzy wartości, do szacowania oczekiwanego czasu trwania
czynności (De) wykorzystywane jest
równanie:
De
= (Dopt + 4*Dsr + Dpes) / 6
Zestaw prac i szacunki czasu
ich trwania stanowią podstawę do określenia ogólnego czasu trwania
projektu. Wydawałoby się, że mając te dane wystarczy podstawić je do SPP i
hierarchicznie zsumować aby otrzymać łączny czas trwania projektu. Takie
podejście jest jednak obarczone dużym ryzykiem. Wiadomo, że zebrane do tego
momentu dane to tylko szacunki. Najbardziej znanymi technikami wyznaczania
harmonogramu są metoda ścieżki krytycznej (Critical Path Method, CPM) oraz
PERT (Program Evaluation and Review Technique). Są to tak zwane techniki
sieciowe. Podstawą technik sieciowych są diagramy sieciowe przedstawiające
zależności czynności i czasy ich trwania.
Ścieżka krytyczna jest to
zestaw nieprzerwanie po sobie występujących czynności, zależnych od siebie
czynności (jedna rozpoczyna się w zależności od zakończenia drugiej),
wyznaczająca długość trwania projektu. Ponieważ projekt kończy się w
momencie zakończenia ostatniego zadania, jest to najdłuższa ścieżka. Każdą
czynność nie leżącą na ścieżce krytycznej można przedłużyć o pewien
czas nie przedłużając w ten sposób czasu trwania projektu. Natomiast
skrócenie każdej czynności leżącej na ścieżce krytycznej skraca
łączny czas trwania projektu. A więc zadaniami nie leżącymi na ścieżce
krytycznej należy manipulować tak (na przykład poprzez zmniejszenie
zasobów), żeby ułatwić realizację zadań leżących na ścieżce krytycznej (na
przykład poprzez zwiększanie zasobów). W CPM do szacowania czasu trwania
czynności używa się najbardziej prawdopodobnej wartości.
Technika PERT jest podobna do
metody CPM. Zasadniczą różnicą jest wykorzystywanie do szacowań wartości
oczekiwanej De zamiast wartości
najbardziej prawdopodobnej (Dsr).
Przy wyznaczaniu harmonogramu
należy uwzględnić dostępność zasobów. Zasadniczym problemem może być
niedostateczna dostępność zasobów koniecznych do wykonania czynności
leżących na ścieżce krytycznej. Aby problem ten zminimalizować należy
najpierw przydzielać zasoby do zadań ze ścieżki krytycznej.
Techniką skracania
harmonogramu może być nakładanie zadań (paralelizacja wykonania). Na
przykład rozpoczęcie planowania interfejsu ekranowego może się rozpocząć
przez zakończeniem wszystkich niezbędnych analiz. Rozwiązanie takie wiąże
się ze zwiększonym ryzykiem ponownego wykonywania nakładanych prac.
Podstawowym problemem
związanym z realizacją harmonogramu są oczywiście opóźnienia. Istnieją cztery
zasadnicze sposoby reagowania na opóźnienia:
·
Zaakceptowanie
opóźnienia
Najgorsze wyjście.
Zadaniem kierownika projektu jest zawsze przeciwstawianie się możliwym
opóźnieniom.
·
Uzyskiwanie
dodatkowych zasobów z zewnątrz projektu
Dodatkowymi zasobami
są zwykle ludzie. Praktyka pokazuje, że w ten sposób można zmniejszyć czas
realizacji projektu o nie więcej niż 20%. Ale tak pozytywny wynik można
uzyskać tylko we wstępnych fazach projektu. Dodawanie nowych ludzi gdy
projekt jest zaawansowany powoduje konieczność ich wprowadzania do
projektu, co dodatkowo powoduje zmniejszenie produktywność doświadczonych
członków zespołu projektowego (zjawisko to jest dokładniej opisane w
książce F. P. Brooksa, Mityczny osobomiesiąc, wyd. polskie WNT 2000).
·
Zwiększenie
obciążeń zespołu wykonawczego
Metoda możliwa do
stosowania na krótką metę. Może prowadzić do zwiększonej liczby błędów oraz
płynności zespołu projektowego.
·
Zmniejszenie
zakresu tworzonego systemu
Jeśli istnieje taka
możliwość – wyjście optymalne. Klient często zgadza się na otrzymanie
„czegokolwiek” w skończonym czasie. Funkcjonalność można podzielić na
krytyczną i poboczną i można rozmawiać z klientem o przeniesieniu
realizacji funkcjonalności pobocznej na czas późniejszy.
Najbardziej rozpowszechniony
ciąg działań prowadzących do oszacowania pracochłonności i czasu trwania
projektów software’owych składa się z szacowania rozmiaru produkowanego
oprogramowania a następnie oszacowaniu na jego podstawie pracochłonności i
czasu trwania projektu.
Metoda
punktów funkcyjnych
Punkt funkcyjny jest to
uniwersalna miara złożoności oprogramowania. Liczbę punktów funkcyjnych
wyznacza się na podstawie następujących parametrów:
- Wejścia zewnętrzne (EI);
- Wyjścia zewnętrzne (EO);
- Zapytania zewnętrzne (EQ);
- Pliki wewnętrzne (ILF);
- Interfejsy zewnętrzne (EIF).
Liczba punktów funkcyjnych
określa zależność:
FP = E(EI, EO, EQ, ILF, EIF)
gdzie jako E jest
wyrażeniem algebraicznym uzyskiwanym na podstawie badań statystycznych i
zależnym od typu projektów, stosowanych narzędzi i innych okoliczności
wpływających na zużycie zasobów.
Najprostszym wyrażeniem
służącym do wyliczania punktów funkcyjnych jest:
FP =
4*EI + 5*EO
+ 4*EQ +
10*ILF + 7*EIF
Punkty funkcyjne są
przeliczane na linie kodu.
Tabela 1. Produktywność
języków programowania w przeliczeniu na punkt funkcyjny
|
Język
|
Linie kodu na Punkt Funkcyjny
|
|
|
320
|
|
C
|
128
|
|
COBOL
|
107
|
|
Fortran 77
|
105
|
|
COBOL 85
|
91
|
|
PL/I
|
80
|
|
Ada
|
71
|
|
Pascal
|
70
|
|
Prolog
|
64
|
|
C++
|
56
|
|
Ada 95
|
55
|
|
Java
|
55
|
|
Visual Basic
|
35
|
Metoda
COCOMO
Oszacowany rozmiar kodu
stanowi podstawę do szacowania pracochłonności i czasu trwania projektów. Najbardziej
znaną metodą szacowania jest COCOMO (COnstructive COst MethOd), opracowana
przez B. Boehma.
W metodzie COCOMO wyróżnia się
trzy rodzaje projektów:
- samodzielne, nie związane ze środowiskiem zewnętrznym;
- pośrednie;
- wbudowane w środowisko (przede wszystkim real-time).
Tabela 2. COCOMO -
Szacowanie czasu trwania i pracochłonności projektów
|
Rodzaj projektu
|
Pracochłonność
(MM, osobo miesiące)
|
Czas trwania
(miesiące)
|
|
Samodzielny
|
3,2 * KDSI 1,05
|
2,5 * MM 0,38
|
|
Pośredni
|
3,0 * KDSI 1,12
|
2,5 * MM 0,35
|
|
Wbudowany
|
2,8 * KDSI 1,20
|
2,5 * MM 0,32
|
KDSI - tysiąc linii
kodu (delivered source instructions)
Zarządzanie kosztem składa się
z procesów mających na celu zapewnienie, że projekt zostanie zakończony w
zaaprobowanym budżecie. Zarządzanie kosztem projektu może być rozszerzone
na wykorzystanie produktu projektu po zakończeniu projektu – mówimy wtedy o
koszcie cyklu życia produktu.
Koszty projektu zależą od
wykorzystywanych zasobów. Pierwszą czynnością w ramach zarządzania kosztem
jest planowanie zasobów. Planowanie zasobów powinno się odbywać gdy
gotowa jest Struktura Podziału Pracy (WBS). Należy zaplanować jakie zasoby
i w jakich ilościach (w jakim czasie) będą wykorzystywane. Planowanie
zasobów powinno być wykonywane na podstawie wiedzy o kosztach tych zasobów
– możliwe jest podejmowanie decyzji dotyczących zasobów jednocześnie
optymalizujących koszty. Zasadniczymi przesłankami do szacowania kosztów
powinny być WBS oraz wiedza o dostępnych zasobach. Firmy realizujące
kontrakty mogą mieć strategie wykorzystania zasobów (np. wykorzystywanie
własnych pracowników vs. zatrudnianie ludzi na okres realizacji projektu
poprzez firmy pośredniczące), które wpływają na szacowanie kosztów.
Informacje te są wykorzystywane przez specjalistów do oszacowania jakie
zasoby będą potrzebne do realizacji zadań znajdujących się w WBS projektu.
Po ustaleniu przewidywanych
zasobów należy wykonać szacowanie kosztów projektu. Jeśli projekt
jest realizowany na podstawie kontraktu, to należy odróżnić szacowanie
kosztów realizacji projektu od ustalenia ceny kontraktu. Powiązanie ceny
kontraktu z kosztami projektu jest decyzją biznesową i pozostaje poza
zakresem szacowania kosztów. Przy szacowaniu kosztów należy rozważyć różne
warianty. Na przykład w projektach deweloperskich warto jest wydać więcej
pieniędzy na fazy analizy i projektowania architekturalnego (zatrudnienie
lepszych specjalistów), gdyż fazy te w sposób zasadniczy decydują o wyższej
jakości produktu. Przy szacowaniu kosztów zasadniczą rolę odgrywa wiedza o
rynkowych cenach realizacji czynności z których składa się projekt. Firmy
powinny prowadzić systematyczną ewidencję kosztów realizowanych przez nie czynności.
Zalecane jest wykorzystywanie informacji o cenach zasobów dostępnych
publicznie – np. komercyjnie czy w publikacjach prasowych.
Istnieją trzy podstawowe
techniki szacowania kosztów:
·
Szacowanie przez
analogię
Szacowanie przez
analogię (szacowanie top-down) polega na porównaniu kosztów planowanego
projektu z kosztami innych wcześniej wykonanych projektów. Ten rodzaj
szacowania może być zalecany, gdy firma ma doświadczenie w realizacji
bardzo podobnych projektów i do realizacji planowanego projektu przewiduje
wykorzystanie ludzi mających doświadczenie ze zrealizowanych podobnych
projektów.
·
Modelowanie
parametryczne
Modelowanie
parametryczne polega na wyodrębnieniu dla pewnej klasy projektów parametrów
decydujących o jego koszcie i zastosowaniu tego modelu do szacowanego
projektu. Precyzja szacowania zależy od dopasowania projektu do
odpowiedniej klasy projektów, na podstawie których model został
wypracowany. Przykładami modelowania parametrycznego w dziedzinie projektów
informatycznych są metody punktów funkcyjnych i COCOMO.
·
Szacowanie
bottom-up
Szacowanie bottom-up
polega na oszacowaniu kosztu czynności elementarnych. Koszty zagregowanych
zadań i czynności uzyskuje się poprzez sumowanie kosztów czynności
składowych. Szacowanie tego rodzaju jest możliwe gdy istnieje bardzo
dokładny plan pracy (WBS).
Wynikiem szacowania kosztów
jest łączny szacunek kosztów potrzebnych do zrealizowania projektu.
Szacunki te zwykle zmieniają się i uszczegółowiają w trakcie realizacji
projektu. Wyróżniane są następujące rodzaje szacunków kosztów:
·
Rzędu wielkości,
·
Pojęciowy,
·
Wstępny,
·
Ostateczny,
·
Kontrolny
(wykonywany w trakcie realizacji projektu).
Poza oszacowaniem kosztów
projektu, dodatkowym wynikiem procesu jest plan zarządzania kosztem
opisujący kto i w jaki sposób może podejmować decyzję związane z
odchyleniami w realizacji budżetu projektu.
Po ustaleniu łącznego kosztu
projektu należy wykonać budżetowanie czynności (przydział budżetu do
wykonywanych czynności). Do budżetowania wykorzystywane są takie same
techniki jak do szacowania łącznego kosztu projektu. Budżet ten jest
podstawą do kontrolowania postępu projektu w wymiarze finansowym. Często
stosowaną techniką kontroli jest analiza wartości uzyskanej opisana w
rozdziale Analiza wartości uzyskanej.
Realizacja budżetu polega na planowym przekazywaniu środków oraz
reagowaniu na odchylenia w realizacji planu kosztów. Zaburzenia w
realizacji planu kosztów mogą prowadzić do tworzenia żądania zmian, obsługiwanych
zgodnie z wcześniej utworzonym planem zarządzania kosztami i ewentualnych
modyfikacji budżetu. Najważniejszym problemem przy realizacji budżetu jest
określenie w przypadku zaistnienia zmian, jaki budżet będzie potrzebny do
ukończenia projektu. Jest to tzw. estymacja kosztu zakończenia projektu
(ang. Estimate At Completion EAC). Wyróżnia się trzy rodzaje EAC:
- EAC = koszt dotychczas poniesiony + zaplanowany
koszt pozostałych czynności
Szacunek wykonywany
gdy w przyszłości nie przewiduje się występowania zaburzeń, które
spowodowały zmiany dotychczasowego budżetu.
- EAC = koszt dotychczas poniesiony + nowe
szacunki pozostałych czynności
Gdy w przyszłości
przewiduje się zaburzenia o innym charakterze niż te, które powodowały
zmiany dotychczasowego budżetu.
- EAC = koszt dotychczas poniesiony + analogiczne
szacunki dla pozostałych czynności
Gdy w przyszłości
przewiduje się zaburzenia takie same jak te, które spowodowały zmiany
dotychczasowego budżetu – np. wzrost inflacji.
Niektóre techniki związane z
zarządzaniem kosztami są opisane w materiale Analiza zysków – kosztów.
Jakość jest to zdolność zbioru
nieodłącznych charakterystyk wyrobu, systemu lub procesu do spełnienia
wymagań klientów lub innych zainteresowanych stron (ISO 9000:2000).
Zasadnicze zagadnienia
związane z jakością to:
- Zadowolenie użytkownika jest zasadniczym kryterium
jakości,
- Zapobieganie jest ważniejsze niż inspekcja,
- Odpowiedzialność kierownictwa – jakość wymaga współpracy
wszystkich członków projektu, ale pozostaje ona w zakresie
odpowiedzialności kierownictwa.
Na zarządzanie jakością składa
się zapewnienie jakości i kontrola jakości.
Zapewnienie jakości jest to
zestaw czynności realizowanych przez cały czas trwania projektu, mających
na celu zapewnienie, że projekt będzie spełniał stawiane przed nim
wymagania związane z jakością.
Kontrola jakości jest to
sprawdzanie produktów projektu w celu stwierdzenia czy są one zgodne ze
standardami jakości oraz w celu wyeliminowania przyczyn usterek.
Procesy te muszą być
zaplanowane, w związku z czym trzecim procesem jest planowanie jakości.
Podstawą do planowania
jakości w projekcie jest ogólna polityka jakości firmy, czyli ogólne
nastawienie firmy do problemów związanych z jakością wyrażone przez
najwyższe kierownictwo firmy. Polityka ta zawsze musi być przystosowana do
konkretnego projektu. Czynnikami, które wpływają na dostosowanie polityki
jakości do projektu są zakres projektu, opis produktu oraz standardy i
regulacje adekwatne do zakresu projektu. Regulacje są to „twarde” normy
prawne organizacyjne i tp. Standardy są to wytyczne dotyczące sposobu pracy
oraz własności produktu. Przy planowaniu jakości należy uwzględnić wyniki
innych planowań, np. zaopatrzenia. Jakość jest ważnym elementem projektu,
ale zarządzanie jakością musi się mieścić w budżecie projektu – a więc tyle
jakości ile budżetu na jakość. W szczególności dla firmy realizującej
projekt zasadnicze znaczenie mają cele biznesowe; zarządzanie jakością może
istotnie obciążyć budżet firmy.
Jakość musi być mierzalna. Dla
każdego projektu należy przygotować zestaw miar, które będą wyliczane w
trakcie jego realizacji. Najprostszymi miarami jakości produktu
deweloperskiego projektu informatycznego jest liczba błędów stwierdzonych w
czasie eksploatacji systemu i czas pomiędzy wystąpieniem błędów. Elementem
planowania jakości mogą być eksperymenty z udziałem użytkownika,
weryfikującego czy przyjęte rozwiązania mu odpowiadają. Dla projektów informatycznych
jest to prototypowanie.
Wynikiem planowania jakości
powinien być plan zarządzania jakością. Przykładowa zawartość takiego planu
dla projektów informatycznych jest opisana w materiale dotyczącym zarządzania jakością..
Proces zapewnienia jakości
są to czynności mające na celu osiągnięcie przez projekt wszystkich
dotyczących go standardów. Zapewnienie jakości jest w projektach zwykle
wykonywane przez zewnętrzny względem projektu, niezależny dział zapewnienia
jakości, ale może także być wykonywane przez wyróżniony zespół wewnątrz
projektu lub przez klienta, dla którego projekt jest realizowany.
Podstawową techniką zapewnienia jakości są audity jakości, czyli
systematyczne przeglądy innych czynności związanych z zarządzaniem
jakością, mające na celu wyszukanie ewentualnych niezgodności z przyjętymi
standardami.
Produktami, półproduktami oraz
wynikami prac zarządczych zajmuje się proces kontroli jakości.
Podstawową techniką kontroli jakości jest inspekcja, czyli sprawdzanie,
przeglądanie lub testowanie produktów w celu stwierdzenia czy obiekt
spełnia stawiane przed nim wymagania. Inspekcje są podstawą do decyzji
zarządczych w kwestii akceptacji produktów pracy. Częste występowanie
analogicznych problemów powinno być podstawą do modyfikacji procesów pracy
prowadzących do wystąpienia tych problemów.
Standardy związane z
zarządzaniem jakością w obszarze IT zostały opisane w rozdziale Jakość w
projektach informatycznych.
80% jakości produktu zależy od
kwalifikacji i motywacji zespołu projektowego. Personel w sposób decydujący
wpływa na wyniki projektu. Zarządzanie personelem polega na maksymalnie
efektywnym wykorzystaniu wszystkich udziałowców zaangażowanych w projekcie.
Podstawową charakterystyką
projektu jest jego ograniczone w czasie trwanie. Oznacza to, że ludzie
zatrudniani w projekcie są z założenia nowi oraz że po zakończenia projektu
będą musieli znaleźć inne zajęcie. Także w trakcie realizacji projektu skład
osobowy zespołu jest płynny. Inne osoby wykonują analizę, inne zajmują się
deweloperstwem jeszcze inne testują i wdrażają systemy. Plan zarządzania
personelem musi więc uwzględniać nie tylko statyczną strukturę zależności
pomiędzy zespołami realizującymi projekt ale także czas istnienia tych
zespołów.
Zespoły projektów są
organizowane w firmach realizujących projekty. Firmy te mają swoją stałą,
„statyczną” strukturę. Dwa podstawowe sposoby organizacji firm realizujących
projekty to organizacja funkcjonalna i organizacja projektowa.
Organizacja funkcjonalna to
taka, w której zespoły są budowane na zasadzie wykonywania takich samych
funkcji. Istnieje zespół analityków, projektantów, testerów, wdrożeniowców
a być może także zespół kierowników projektów. Kierownik każdego zespołu
funkcjonalnego odpowiada za wyszkolenie i jakość pracy członków tego
zespołu. Odpowiada on również za dostępność ludzi na potrzeby realizacji
poszczególnych projektów. Członkowie zespołu funkcjonalnego są delegowani
do zespołów projektowych na czas realizacji projektów. Kierownik projektu
musi zawsze ustalić z kierownikiem zespołu funkcjonalnego zasady
wykorzystania podlegających mu osób. W szczególności musi określić czas
wykorzystania osób. Można powiedzieć, że zespoły funkcjonalne pełnią role
usługowe na rzecz zespołów projektowych. Podstawowym plusem organizacji
funkcjonalnej jest jednorodność metod pracy i wynikająca z tego łatwość
zastępowania członków zespołu projektowego w sytuacjach awaryjnych.
Kierownik projektu nie powinien się troszczyć o poziom wyszkolenia członków
swojego zespołu – jest to zadanie kierownika zespołu funkcjonalnego.
Minusem organizacji funkcjonalnej jest konieczność koordynacji
wykorzystania osób pomiędzy kierownikiem projektu i kierownikiem zespołu
funkcjonalnego. Inne niż planowane (dłuższe lub krótsze) wykorzystanie osób
w projekcie powoduje problemy w koordynacji pomiędzy zespołami
funkcjonalnymi a zespołami projektowymi. Struktura funkcjonalna może być
zalecana gdy firma realizuje wiele projektów o zbliżonej charakterystyce,
wymagających takich samych umiejętności.
W ostatnich czasach istnieje
moda na nazywanie zespołów funkcjonalnych „centrami kompetencyjnymi”.
Organizacja projektowa to
taka, w której statyczna struktura firmy pokrywa się ze strukturą
realizacji projektów. W firmie na stałe, statycznie istnieją zespoły
projektowe. Kierownik zespołu musi sam dbać, żeby w firmie były dostępne
wszystkie osoby potrzebne do realizacji jego projektów. W każdym zespole
muszą istnieć analitycy, projektanci, deweloperzy wdrożeniowcy itd. Taka
struktura jest właściwa, gdy realizowane w firmie projekty mocno różnią się
od siebie. Na przykład jeśli firma z jakichś powodów realizuje wdrażanie
systemów finansowo – księgowych oraz tworzenie oprogramowania do sterowania
samolotami, to niewielkie jest prawdopodobieństwo, że specjalistów będzie
można wymieniać pomiędzy tymi zespołami. Przy takim rozwiązaniu kierownik
projektu nie musi koordynować swojej działalności z innymi kierownikami
zespołów projektowych. Ale także ma niewielkie szanse na uzyskanie pomocy
kadrowej z wnętrza firmy w sytuacjach kryzysowych.
Istnieją rozwiązania
pośrednie, mieszane. Na przykład często stosowanym rozwiązaniem w
organizacjach mających strukturę projektową jest wyróżnienie jednego
zespołu funkcjonalnego – zespołu zapewnienia jakości. Poza (obok) strukturą
projektową lub funkcjonalną w każdej firmie software’owej powinny istnieć
osoby związane z metodyką pracy. W zespole takim powinny być wyróżnione
dwie zasadnicze role: definiowanie procesu pracy oraz nadzór nad procesem
pracy. Czasami spośród osób, których zadaniem jest definiowanie procesu
pracy wyróżnia się osoby odpowiedzialne za narzędzia pracy (środowiska
programistyczne, narzędzia typu CASE).
Tradycyjny sposób organizacji
wewnętrznej zespołu projektowego to podział na zespoły funkcjonalne.
Istnieje zespół analityków, którego zadaniem jest wytworzenie specyfikacji
systemu. Istnieje zespół projektantów, którego zadaniem jest opracowanie projektu.
Zespół deweloperów, testerów wdrożeniowców – każdy ma ściśle przypisane
zadania. Każdy zespół wykonuje swoje zadania i po ich zakończeniu
przekazuje swój produkt do następnego zespołu. Takie podejście jest
właściwe dla realizacji kaskadowego cyklu życia projektów, w którym
warunkiem rozpoczęcia jednej czynności jest zakończenie czynności
poprzedniej. Przypisanie zespołom funkcjonalnym odpowiedzialności za
realizację tylko tej właśnie czynności nie sprzyja identyfikowaniu się
członków z celem zasadniczym jakim jest realizacja całego projektu.
Członkowie zespołów funkcjonalnych nie mają skłonności do uwzględniania
wymagań następnych uczestników procesu wytwórczego. Przy takiej organizacji
na przykład analitycy są skłonni do bycia dobrymi analitykami, a nie
dobrymi członkami zespołu projektowego. Może powstać przeświadczenie, że
odpowiedzialność zespołu funkcjonalnego kończy się w momencie zakończenia
realizacji jego funkcji. Praktyka pokazuje jednak, że wymagania na
oprogramowanie ewoluują i konieczny jest ciągły udział wszystkich osób
zaangażowanych w jego tworzenie w każdej fazie wytwórczej.
Innym sposobem organizacji
zespołu projektowego jest utworzenie Zintegrowanych Zespołów Procesowych
(ang. Integrated Process Team). Główną ideą ZZP jest włączenie do
realizacji zadań osób zainteresowanych wynikami tych zadań. Na przykład w
pracach zespołu analityków (który ma nazwę zmienioną na Zintegrowany Zespół
Wymagań) uczestniczą projektanci i testerzy – ponieważ dla nich
przeznaczone są wyniki prac analitycznych. Uczestnictwo tych osób ma
pozytywne skutki. Po pierwsze osoby, dla których przeznaczone są wyniki
prac mogą na bieżąco wypowiadać się o przydatności wyników do ich zadań. Po
drugie możliwe jest wcześniejsze, przed zakończeniem zadania, rozpoczęcie przygotowywania
lub wykonywania zadania następnego. Po trzecie każdy członek ZZP odczuwa że
jest członkiem zespołu projektowego, którego celem jest realizacja
projektu, a nie tylko wykonanie pojedynczej funkcji.
W wyniku projektowania
struktury zespołu projektowego, uwzględniającego przede wszystkim strukturę
organizacyjną firmy oraz funkcje realizowane w projekcie, powstaje schemat
organizacyjny projektu (zwykle reprezentowany graficznie). W schemacie
organizacyjnym powinno być miejsce na
szczegółowy opis uprawnień i odpowiedzialności wszystkich
zaangażowanych osób. Należy także określić czas, w którym poszczególne
osoby będą w projekcie potrzebne, czyli czas przyjmowania i zwalniania
ludzi z projektu. Zestaw takich informacji zwykle nazywa się planem zarządzania
personelem w projekcie.
Jedną z podstawowych czynności
przy realizacji planu zarządzania personelem jest nabór ludzi do projektu.
Nabór może być wewnętrzny (spośród pracowników firmy) lub zewnętrzny. Jeden
z największych autorytetów w zakresie inżynierii programowania i
zarządzania projektami, Barry Boehm sformułował następujące zasady
zarządzania personelem (B. Boehm, Software Engineering Economics,
Prentice-Hall, 1981):
·
Zasada najwyższych
uzdolnień,
·
Zasada
odpowiedniości zadań,
·
Zasada progresji
kariery,
·
Zasada równowagi
zespołu,
·
Zasada usuwania z
zespołu.
Zasada
najwyższych uzdolnień
Używaj mniejszej liczby
lepszych ludzi. Mówi się, że dobrzy ludzie są wielokrotnie (do dwudziestu
razy) bardziej efektywni niż ludzie gorzej kwalifikowani – a ich
wynagrodzenia nigdy nie są dwadzieścia razy większe. Większa liczba ludzi
powoduje większe problemy w komunikacji, która zwykle w zespołach jest
największym źródłem problemów.
Zasada
odpowiedniości zadań
Ludzie powinni otrzymywać
zadania, które są zgodne z ich umiejętnościami, możliwościami i
motywacjami. Należy zwrócić uwagę, że nie tylko umiejętności ale być może
przede wszystkim możliwości decydują o przydatności osób do wykonywania
zadań. Motywacje zwykle należą do jednej z dwóch grup: dążenie do własnego
rozwoju i motywacje społeczne (potrzeba akceptacji, uznania, przewodzenia).
Zasada
progresji kariery
Ludzie lepiej pracują, jeśli
mają przed sobą perspektywę rozwoju. Nie należy więc osobie, która
aktualnie wykonuje prace kierownicze, proponować czynności technicznych.
Osoba taka będzie traktowała takie zajęcie jako konieczność; nie sprzyja to
oczywiście pełnemu angażowaniu się w pracę. Firma powinna oferować
pracownikom szkolenia stanowiące podstawę do realizacji bardziej
odpowiedzialnych zadań. Należy zwrócić uwagę, że nie dla wszystkich pojęcie
kariery oznacza zarządzanie zespołami ludzkimi (awanse formalne). W
szczególności w branży IT za karierę wiele osób uważa możliwość
opanowywania nowych dziedzin wiedzy.
Zasada
równowagi zespołu
Zasad uzupełniająca zasadę
najwyższych uzdolnień. W każdym zespole muszą być osoby twórcze oraz osoby
wykonujące zadania rutynowe, wspomagające.
Zasada
usuwania z zespołu
Jeśli konieczne jest
wyrzucenie kogoś z zespołu, należy to robić jak najszybciej. Tolerowanie w
zespole osób nie w pełni angażujących się w realizowane zadania poważnie
obniża morale zespołu. Prawo pracy nie powinno przeszkadzać w usuwaniu osób
z zespołu. Lepiej jest płacić przez pewien okres ludziom za pozostawanie w
domu niż tolerować ich demoralizujące zachowania w zespole.
B. Tackman i M. A. C. Jensen („Development
Sequence in Small Groups”, Psychological Bulletin, 6, 1965)
stwierdzili, że zespoły przechodzą przez cztery fazy zachowań:
- Formowanie,
- Burza,
- Normowanie,
- Działanie.
Czyli po zebraniu ludzi
(formowanie) następuje faza sporów. Faza ta kończy się przypisaniem
formalnych i nieformalnych ról. Zespół może wydajnie pracować, gdy
większość jego członków zaakceptowała sytuację swoją i pozostałych osób.
W projektach (w szczególności
informatycznych) ludzie i zespoły są tworzone w różnych momentach. Nie ma
np. sensu na początku zatrudniać pełnego zespołu testerów. Ale ogólna
dynamika zespołu projektowego jest zbliżona do przytoczonego schematu.
Rozkład zachowań wynikający z ogólnych prawideł nakłada się na specyfikę
projektów. W szczególności faza burzy przypada mniej więcej na czas
tworzenia projektu systemu. Faza ta jest trudna, ponieważ w tym czasie od
zespołu wymaga się największej dozy twórczości (zakładamy, że zespół ma
wypracowaną ogólną metodykę pracy i ogólny sposób pracy jest akceptowany).
Dochodzi do ścierania się poglądów. W tej fazie szczególnie ważne jest
umiejętne sterowanie zachowaniami grupy. Warto więc przytoczyć za M.
Cantorem (Object-oriented Project Management with UML, John Wiley and
Sons, 1998 ) kilka podstawowych zasad, które szczególnie ważne są
właśnie w fazie sporów.
Przydzielaj zadania zgodnie
z przekonaniami
Ludzie powinni otrzymywać
odpowiedzialność zadania co do których są przekonani – zarówno jeśli chodzi
o sens zadania jak i sposób ich wykonania.
Dziel się wizją
Ludzie bardziej się angażują w
realizację zadań, jeśli wiedzą jaka jest ich rola w osiągnięciu
całościowego celu projektu. Znane powinny być wszystkie aspekty celu, do
którego zespół dąży: cel klienta, cel zespołu, cel realizującej firmy oraz
korzyści, jakie może osiągnąć każda zaangażowana osoba.
Zamykaj problemy
Problemy, które raz się
pojawiły nie powinny pozostawać bez rozwiązania. Dobrym zwyczajem jest
prowadzenie ewidencji problemów – również tych, które nie są problemami w
„dużym” sensie organizacyjnym, na styku z klientem. Będąc kierownikiem
staraj się pozostawiać problemy do rozwiązania ludziom. Interweniuj
osobiście tylko w ostateczności. Dla kierownika właściwą rolą jest rola
arbitra a nie osoby podającej jedno z kilku rozwiązań (które może nie być
zaakceptowane przez zespół).
Buduj zaufanie i lojalność
Tylko zespół, który ma
zaufanie będzie w stanie podzielić twoją wizję. Każda osoba w zespole musi
mieć zaufanie do ciebie. Nigdy nie krytykuj nikogo publicznie. W krytyce
zwracaj uwagę na meritum a nie na osobę.
Bądź dostępny żeby udzielić
pomocy
Kierownik projektu to taki sam
członek jak inni ludzie w zespole ale z wyspecjalizowanymi zadaniami.
Głównym zadaniem kierownika jest usuwanie ludziom przeszkód, których oni –
zwykle z powodów organizacyjnych – sami nie mogą usunąć. Ale należy także
unikać przedstawiania wszystkich problemów przełożonym. Każdy członek
zespołu musi rozwiązywać problemy, które zostały mu przypisane (patrz
następna zasada).
Nie wykonuj pracy
podwładnych
Kierownik projektu służy do
przydzielania i rozliczania prac. Wykonywanie prac, które miał wykonać
podwładny jest podstawowym, często spotykanym błędem w kierowaniu zespołem.
Okazuj zaufanie
Jeśli przyjąłeś kogoś do
zespołu to znaczy, że obdarzyłeś go zaufaniem. W szczególności zaufanie
musi dotyczyć kontaktów z klientem. Każdy autor rozwiązania powinien mieć
możliwość zaprezentowania wyników swojej pracy klientowi.
Nigdy nie okazuj paniki
Problemy kierownika powinny
pozostać jego własnymi problemami. Pracownicy mają dostatecznie dużo zadań,
żeby zajmować się twoimi obawami.
Depersonalizuj dyskusje
Każda publiczna (lub
dwuosobowa) dyskusja musi się koncentrować na problemach „technicznych”.
Należy być ostrożnym w sformułowaniach. Lepsze są sformułowania: „TO nie
spełnia wymagań” niż „Ty to zrobiłeś źle”. Pozytywne sterowanie zawsze jest
bardziej skuteczne niż sterowanie negatywne.
Mów dziękuję
Nawet takie zalecenia są
formułowane w poważnych opracowaniach :-))
Zarządzanie komunikacją
zajmuje się obsługą informacji koniecznej do realizacji projektu. Obszar
ten obejmuje gromadzenie, przechowywanie, rozpowszechnianie i
archiwizowanie informacji. Zarządzanie komunikacją obejmuje informacje
mające postać papierową, elektroniczną, ustną oraz mającą dowolną inną
postać. Za obieg informacji w projekcie powinna odpowiadać wyróżniona osoba
– zwykle jest ona nazywana asystentem (-tką) kierownika projektu lub
kierownikiem biura.
W przygotowawczej fazie
projektu należy opracować plan zarządzania komunikacją. Ponieważ informacja
ma umożliwić realizację zadań przypisanych osobom realizującym projekt,
zasadniczą częścią planowania komunikacji jest analiza potrzeb udziałowców.
Sponsor projektu musi być informowany o zasadniczych ryzykach, o statusie
projektu (np. projekt idzie zgodnie z planem; projekt jest zagrożony;
projekt nie rokuje szans na pomyślne zakończenie) oraz o wykorzystaniu
zasobów przydzielonych projektowi. Kierownik projektu musi mieć pełną,
szczegółową informację o realizacji prac projektu oraz o sytuacji w
projekcie. Liderzy zespołów technicznych potrzebują głównie informacji o
postępie i jakości prac innych zespołów, potrzebnych do realizacji zadań w
zarządzanych przez nich zespołach. Techniczni wykonawcy prac potrzebują
przede wszystkim informacji technicznych pochodzących od współpracujących z
nimi innych wykonawców.
Wynikiem planowania komunikacji
powinien być plan zarządzania komunikacją. W dokumencie tym należy opisać
źródła i odbiorców (odbiorcą może być repozytorium projektu) informacji,
zawartość informacji, sposób oraz harmonogram przekazywania informacji.
Należy także wskazać sposób gromadzenia informacji (rodzaje i strukturę
repozytoriów projektu) oraz uprawnienia do biernego dostępu do informacji
znajdujących się w repozytoriach. Istotnymi, powiązanymi ze sobą
zagadnieniami, które należy rozwiązać przy planowaniu komunikacji jest sposób
raportowania oraz spotkania w trakcie realizacji projektu.
W projektach zwykle tworzy się
dwa repozytoria: elektroniczne i papierowe. Ostatnio, w związku z rozwojem
możliwości technologicznych, istnieje tendencja do wypierania repozytoriów
papierowych na rzecz elektronicznych. Poza repozytoriami elektronicznymi
pozostają tylko duże dokumenty nie mające postaci elektronicznej (np.
przepisy prawne, dokumentacja techniczna). Repozytorium elektroniczne
powinno zawierać trzy główne katalogi: produkty technologiczne, część
zawierającą materiały zarządcze oraz katalog roboczy, służący do
komunikacji pomiędzy członkami zespołu. Część technologiczna powinna być
uporządkowana według głównych zadań (faz) procesu technologicznego – np.
podkatalogi ANALIZA, PROJEKT, MODUŁY, TESTY, WDROŻENIE. Część zarządcza
powinna być podzielona według poziomów zarządzania, np. podkatalogi
KIEROWNIK PROJEKTU, ZARZĄD, SPONSOR. Zawartość części roboczej nie jest z
góry planowana. Zaleca się, żeby podkatalogi były tam tworzone w przypadku
wystąpienia potrzeby przekazywania informacji w określonej sytuacji.
Każdy członek zespołu
projektowego, niezależnie od miejsca w hierarchii, powinien mieć obowiązek
pisemnego raportowania postępu prac w zakresie swojej odpowiedzialności.
Szeregowi członkowie zespołów
wykonawczych powinni po zakończeniu każdego zadania przygotowywać karty
zadania, zawierające informacje o zrealizowanych pracach i wynikach.
Powinni oni także mieć możliwość wypowiedzenia się o sytuacji na ich
stanowisku pracy – służy do tego raport miesięczny. Poza rutynowymi
informacjami zawierającymi podsumowanie wykonanych i przewidywanych prac
raport taki zawiera informacje o napotkanych i przewidywanych problemach.
Dla przełożonych zawsze istotna jest informacja o zagrożeniach dla realizacji
projektu.
Kierownicy zespołów roboczych
powinni na piśmie przygotowywać tygodniowe i miesięczne raporty. Zadaniem
raportu tygodniowego jest zapewnienie kierownikowi projektu bieżącego
wglądu w realizację projektu (zadania wykonane, zadania w toku, zadania
planowane, inne bieżące istotne dla realizacji projektu informacje).
Raporty te powinny być przedstawiane i omawiane na cotygodniowych
spotkaniach. W raportach miesięcznych poza zbiorczym podsumowaniem prac
muszą się znajdować sekcje dotyczące wykorzystanych zasobów (budżet) oraz
napotkanych problemów.
Kierownik projektu powinien dla sponsora raz na miesiąc
przygotowywać ogólny raport o postępie prac, zagrożeniach i wykorzystaniu
budżetu.
Bardzo ważnym elementem
dokumentacji projektu są protokoły ze spotkań – zarówno technicznych jak i
zarządczych. Ogólną zasadą powinno być: nieudokumentowane spotkanie z
osobami spoza projektu (w szczególności z klientem) należy uznać za
niebyłe. Każdy projekt powinien mieć określoną procedurę zatwierdzania
notatek ze spotkań z klientem. Notatki te stają się oficjalną częścią
dokumentacji projektu.
Analiza
wartości uzyskanej
Techniką służącą do oceny
zaawansowania prac w projekcie jest analiza wartości uzyskanej (ang. Earned
Value Analysis, EVA). Podstawowymi wielkościami występującymi w EVA są:
- Budżetowany koszt zaplanowanej pracy, budżet
(ang. Budgeted Cost of Work Scheduled, BCWS)
Tyle przeznaczono na
wykonanie prac do dnia, w którym analiza jest wykonywana.
- Rzeczywisty koszt wykonanej pracy (ang. Actual
Cost of Work Performed, ACWP)
Tyle
pieniędzy wydano do dnia wykonywania analizy.
- Budżetowany koszt wykonanej pracy, uzyskana
wartość (ang. Budgeted Cost of Work Performed, BCWP)
Tyle
miały kosztować wykonane do dnia analizy prace.
Na podstawie powyższych
wielkości wyliczane są dwie podstawowe miary:
- Wariancja kosztu (ang. Cost Variance, CV)
CV = BCWP – ACWP
O
tyle więcej wydano na zaplanowane prace w porównaniu z planem (uwaga
na znak!).
- Wariancja harmonogramu (ang. Schedule Variance,
SV)
SV = BCWP – BCWS
Do
chwili obecnej nie zrealizowano prac za tę kwotę ( także w przypadku
opóźnień występuje liczba ujemna).
Tabela 3. Przykład
zastosowania analizy wartości uzyskanej
|
Zadanie
|
Budżet (BCWS)
|
Uzyskana Wartość (BCWP)
|
Koszt
(ACWP)
|
Wariancja kosztu
|
Wariancja harmonogramu
|
|
ZŁ
|
%
|
ZŁ
|
%
|
|
1
|
63000
|
58000
|
62500
|
-4500
|
-7,8
|
-5000
|
-7,9
|
|
2
|
64000
|
48000
|
46800
|
1200
|
2,5
|
-16000
|
-25,0
|
|
3
|
23000
|
20000
|
23500
|
-3500
|
-17,5
|
-3000
|
-13,0
|
|
4
|
68000
|
68000
|
72500
|
-4500
|
-6,6
|
0
|
0,0
|
|
5
|
12000
|
10000
|
10000
|
0
|
0,0
|
-2000
|
-16,7
|
|
6
|
7000
|
6200
|
6000
|
200
|
3,2
|
-800
|
-11,4
|
|
7
|
20000
|
13500
|
18100
|
-4600
|
-34,1
|
-6500
|
-32,5
|
|
Suma
|
257000
|
223700
|
239400
|
-15700
|
-7,0
|
-33300
|
-13,0
|
Ryzyko jest to niepewne
zdarzenie, które – jeśli wystąpi – będzie miało pozytywny albo negatywny
efekt na realizację projektu. Inaczej mówiąc, ryzyko jest to zdarzenie
potencjalnie zaburzające planową realizację planu projektu. Istnieją ryzyka
zewnętrzne względem projektu – np. upadek firmy, która miala dostarczyć
oprogramowanie oraz ryzyka wewnętrzne – np. złe zarządzanie projektem.
Ryzyka mogą być akceptowane gdy równoważą się z zyskami. Na przykład
skrócenie cyklu produkcji poprzez usunięcie zewnętrznej kontroli jakości
niektórych produktów może być zaakceptowany dzięki szansie na wcześniejsze
zakończenie projektu.
Pierwszą czynnością związaną z
ryzykiem jest planowanie zarządzania nim. Elementem planowania jest
środowisko projektu (dokument otwarcia, WBS, praktyki związane z
zarządzaniem ryzykiem w firmie). Ponieważ szczegółową, konkretną wiedzę o ryzykach
projektu mają osoby uczestniczące w realizacji projektu, należy
przeprowadzić z nimi wywiady mające na celu poznanie możliwych zagrożeń.
Informacje te stanowią podstawę do opracowania planu zarządzania
ryzykiem, który powinien zawierać:
- Opis stosowanej metodologii (np. SRE),
- Opis ról i odpowiedzialności,
- Budżet przeznaczony na zarządzanie ryzykiem,
- Wstępny harmonogram czynności związanych z
zarządzaniem ryzykiem,
- Metody szacowania ryzyka i ich interpretację,
- Wartości progowe ryzyka,
- Formaty raportowania,
- Sposoby nadzorowanie i dokumentowania
zarządzania ryzykiem.
Następnie, zgodnie z
opracowaną metodologią, należy przeprowadzić identyfikację ryzyka.
Należy wskazać, jakie ryzyka mogą wpłynąć na projekt. W pierwszej fazie
identyfikacji ryzyka powinni uczestniczyć członkowie zespołu projektowego i
zespół oceny ryzyka. Do drugiej iteracji można włączyć osoby zarządzające
projektem (sponsor, kierownik projektu). Analizowane powinny być wszystkie
dostępne dokumenty projektu takie jak dokument otwarcia, WBS, opis
produktu, plan zarządzania kosztem i harmonogramem itd. Dokumenty te
powinny być porównane z dotychczasowymi pracami firmy realizującej dany
projekt oraz z informacjami dostępnymi spoza firmy (np. publikacje prasowe,
książkowe, internetowe). Przy analizowaniu ryzyka należy zwrócić uwagę na
cztery główne kategorie ryzyk techniczne, związane z zarządzaniem,
organizacyjne i zewnętrzne. Technikami analizy ryzyka mogą być burza
mózgów, metoda delficka, wywiady czy analiza SWOT. Dostępne też są listy
standardowych ryzyk dla projektów różnych typów. Wynikiem identyfikacji
ryzyka są ryzyka powiązane z symptomami ich wystąpienia.
Zadaniem jakościowej
analizy ryzyka jest określenie prawdopodobieństwa wystąpienia
zagrożenia i jego wpływu na projekt. Szacunki takie mogą być podstawą do
określania priorytetów opracowywania reakcji na ryzyka. Jeśli jakościowa
analiza ryzyka jest powtarzana kilkakrotnie w trakcie realizacji projektu,
daje ona podstawy do analizy trendów w zakresie ryzyka. Przy analizie
ryzyka należy uwzględnić status projektu (na początku cyklu życia projektu
widocznych jest mniej ryzyk), typ projektu (więcej ryzyk można wcześnie
zidentyfikować jeśli projekt jest realizowany w dobrze znanej dziedzinie)
oraz założenia, które zawsze są źródłem ryzyka. Prawdopodobieństwo ryzyka
jest oceniane zwykle na tradycyjnej skali <0, 1>. Wpływ może myć
szacowany na skali nominalnej lub liczbowej (wygodniejsza w użyciu). Ryzyka
mogą być pogrupowane według obszarów zarządzania (np. koszt, harmonogram,
zakres, jakość). Na przykład dla kosztu za niskie ryzyko uważa się
przekroczenie budżetu o 1% – 2%, zaś za bardzo wysokie przekroczenie
budżetu o więcej niż 20%. Ocena ryzyka to iloczyn prawdopodobieństwa jego
wystąpienia przez wpływ. Oceny ryzyka są zwykle grupowane w trzy grupy.
Jeśli dla wpływu przyjmiemy skalę <0, 1>, to za niską ocenę ryzyka
można przyjąć wartości z przedziału <0.0, 0.1>, za średnią z
przedziału (0.1, 0,2> zaś przedział (0.2, 1> to ryzyko wysokie. Po
wykonaniu jakościowej analizy, ryzyka wysokie i średnie stają się
kandydatami do dalszej, dokładniejszej analizy i ewentualnego przygotowania
planów awaryjnych.
Następnym etapem po analizie
jakościowej jest analiza ilościowa. Jej celami jest określenie prawdopodobieństwa
uzyskania celów projektu, określenie rezerw budżetu i harmonogramu oraz
wyodrębnienie podstawowych ryzyk w celu opracowania planów awaryjnych.
Szczegółowa wiedza o ryzykach związanych z poszczególnymi obszarami
zarządzania projektem może być uzyskana w wyniku wywiadów przeprowadzanych
z udziałowcami projektu. W analizie ilościowej należy określić rozkłady
ważnych dla projektu czynników. Na przykład wiedza ekspertów może być
wykorzystana do szacowań niskich, oczekiwanych i maksymalnych wartości
kosztu czy czasu trwania czynności projektu. Rozkłady tych wartości mogą
być wejściem do symulacji metodą Monte Carlo. W ramach ilościowej analizy
należy wyodrębnić te czynniki ryzyka, które mają najwyższy wpływ na łączne
ryzyko projektu. Dla tych czynników należy przeprowadzić analizę
wrażliwości, której celem jest pokazanie jak się zmienia ogólne ryzyko
projektu dla ich skrajnych wartości. Pomocną techniką jest wykorzystanie
drzew decyzyjnych, pokazująca jakie jest obciążenie ryzykiem istniejących alternatyw.
Dla najważniejszych ryzyk
należy zaplanować odpowiednie reakcje. Reakcja na ryzyko musi być
odpowiednia do jego istotności, musi uwzględniać budżet i harmonogram
projektu. Reakcja na każde ryzyko musi uzgodniona z zainteresowanymi
stronami i musi być przydzielona konkretnej osobie. Cztery podstawowe typy
reakcji na ryzyko to:
·
Unikanie
·
Przeniesienie
ryzyka
·
Mitygacja
·
Akceptacja
Opis reakcji na ryzyko
powinien zawierać osoby odpowiedzialne za obsługę ryzyka i ich czynności,
typ reakcji na ryzyko, określenie wtórnego ryzyka pozostającego po
wykonaniu reakcji, akcje konieczne do zastosowania przyjętej strategii,
koszt i czas reakcji na ryzyko oraz plany awaryjne. Możliwe jest
wystąpienie nowych ryzyk związanych z wdrożeniem planu reakcji na ryzyko.
Zidentyfikowane ryzyka muszą
być monitorowane i sterowane. W trakcie realizacji projektu
konieczne jest wykonywanie prac związanych z identyfikacją nowych ryzyk,
zapewnieniem wykonania planów reakcji na ryzyko i oceną efektywności tych
czynności. Szczegółowymi celami monitorowania ryzyka jest stwierdzenie czy
reakcje na ryzyko zostały wykonane zgodnie z planem, czy są one tak
efektywne jak przewidziano, czy ogólne założenia przyjęte dla projektu są
ciągle ważne, czy narażenie na ryzyko zmieniło się, czy wystąpiły symptomy
ryzyka, czy pojawiły się nowe, nie przewidziane wcześniej ryzyka.
Sterowanie ryzykiem może polegać na wyborze reakcji spośród alternatywnych
strategii, podejmowaniu akcji korygujących, wykonywaniu planów awaryjnych
czy przeplanowywaniu projektu. Osoby odpowiedzialne za ryzyka powinny
systematycznie raportować osobie ogólnie odpowiedzialnej za zarządzanie
ryzykiem o sytuacji w zakresie ryzyk, za które odpowiadają. Reakcje na
ryzyko powinny być poddawane auditom. Częścią spotkań projektu powinien
zawsze być punkt poświęcony ryzykom. W wyniku postępowania z ryzykiem
konieczne może być generowanie żądań zmian w projekcie.
Ważne jest, żeby w trakcie
każdego projektu zebraną uzyskaną wiedzę dotyczącą występujących ryzyk
przekazywać do ogólnofirmowej bazy wiedzy o ryzyku.
Przykład metodyki zarządzania
ryzykiem jest przedstawiony na stronie opisującej ryzyko
w projektach informatycznych.
Zaopatrzenie jest to
dostarczanie do projektu usług i towarów wyprodukowanych poza nim. W
większości projektów informatycznych obszar ten ma niewielkie znaczenie.
Projekty są zwykle realizowane w całości lub w większości własnymi siłami
firm, które podpisały kontrakt lub w inny sposób podjęły decyzję o
realizacji projektu.
Zarządzanie zaopatrzeniem jest
złożonym, wieloetapowym procesem. Pierwszym etapem jest określenie, jakie
dobra (towary lub usługi) potrzebne w projekcie mogą być wyprodukowane poza
nim. Wskazanie takich dóbr odbywa się na podstawie tego fragmentu wyników
procesu zarządzania zakresem, w którym ustalany jest zestaw produktów,
które mają być efektem projektu. Do każdego takiego produktu należy
zastosować analizę typu wyprodukuj-czy-zakup. Analiza taka może być
potraktowana jako rodzaj analizy korzyści i kosztów, gdzie jedną z
alternatyw jest własna produkcja, pozostałe są wyznaczane przez zakupy
dobra spoza projektu (tu może być też kilka alternatyw, na przykład
odnoszących się do różnych wytwórców). Przy uwzględnianiu kosztów zakupu
należy uwzględnić nie tylko cenę zakup ale też czynniki takie jak koszty
własne związane z obsługą zakupu czy dyskonto przyszłej ceny zakupu. Należy
także uwzględnić, czy firma ma komórkę organizacyjną będącą w stanie
obsłużyć zakup. Przy ocenie sposobu uzyskania dobra często stosowaną
techniką jest ocena ekspertów posiadających odpowiednią wiedzę dotyczącą
odpowiedniego obszaru rynku. W wyniki planowania zaopatrzenia dla każdego
dobra, które ma być dostarczone z zewnątrz, należy przygotować określenie
pracy (ang. Statement of Work, SOW). Następne etapy procesu zaopatrzenia są
zwykle wykonywane osobno dla każdego SOW. Ponieważ wykonanie dobra może być
dla wykonującej je firmy dużym przedsięwzięciem, zalecane jest, żeby w tej
fazie przygotowano plan zarządzania kontraktem, w ramach którego dobro jest
dostarczane.
Dla każdego dobra
dostarczanego z zewnątrz należy rozpoznać rynek. Proces ten składa się z
dwóch faz: przygotowania rozpoznania rynku oraz zasadniczej części
rozpoznania. Przygotowując rozpoznanie rynku trzeba podjąć decyzję w jaki
sposób będą wyszukiwani oferenci. Tworzone są zaproszenia do przetargu,
zapytania o cenę, zaproszenia do negocjacji itp. W fazie tej należy także
przygotować sposoby oceny przewidywanych ofert Najprostszą metodą, gdy pozyskiwane dobro
jest dobrze zdefiniowane i dostępu na rynku w gotowej postaci, jest
porównanie cen. Gdy dobro ma być wyprodukowane specjalnie na potrzeby
projektu, system ocen może być bardziej rozbudowany. Wtedy obok ceny w grę
wchodzą możliwości (organizacyjne i finansowe) i techniczne umiejętności
oferenta. Wśród kryteriów oceny czasami wyróżnia się tzw. kryteria
selekcjonujące – są to takie kryteria, których spełnienie jest
konieczne, żeby oferta mogła być dopuszczona do następnego etapu, w którym
wyliczana jest punktowa, łączna wartość oceny. Przykładem kryterium
selekcjonującego, gdy przedmiotem zaopatrzenia jest wyprodukowanie
złożonego systemu informatycznego, może być wcześniejsze wyprodukowanie
przez oferenta co najmniej jednego systemu o podobnej złożoności.
Rozpoznanie rynku odbywa się poprzez rozesłanie dokumentów przetargowych do
wybranego zestawu potencjalnych oferentów lub poprzez nieograniczone
ogłoszenia – w prasie lub w internecie.
Po spłynięciu ofert należy
dokonać oceny porównawczej stosując wcześniej zdefiniowane reguły. Ponieważ
wyobrażenie strony zlecającej może być inne niż strony realizującej
kontrakt, częścią procesu oceny zwykle są negocjacje z potencjalnym
dostarczycielem usług. Jeśli rozbieżności pomiędzy stronami są zbyt duże,
warto jest zalecić wykorzystanie zewnętrznych ekspertów do oceny nakładów i
terminów realizacji przyszłego kontraktu. Wynikiem oceny ofert i negocjacji
jest podpisanie kontraktu na dostawę dobra do projektu.
Elementami, które należy
przewidzieć na czas realizacji kontraktu są sposoby odbioru fragmentów
dostawy (jeśli dostawa jest wieloetapowa), sposoby i terminy płatności oraz
sposoby zarządzania zmianami w kontrakcie. W zależności od rozmiaru
kontraktu w planie zarządzania nim mogą się pojawić elementy zarządzania
wszystkimi obszarami zarządzania projektami (czas, komunikacja,
jakość....).
Każdy proces zaopatrzenia musi
zostać oficjalnie zakończony. W tym celu należy przygotować, zebrać i
uporządkować pełną dokumentację realizacji kontraktu. Zalecane jest
wykonanie auditu zaopatrzenia, w którym powinno być sprawdzona zgodność
realizacji kontraktu z zapisami kontraktu. Upoważniona osoba lub komisja na
podstawie wyników auditu powinna podjąć decyzję w kwestii zamknięcia
kontraktu.
Zarządzanie integralnością
jest to powodowanie, że różne elementy projektu oraz działania związane z
jego otoczeniem są właściwie koordynowane. Projekt musi być koordynowany z
działalnością realizującej go firmy – na przykład w zakresie wykorzystania
personelu, przepływu środków finansowych. Zakres projektu i zakres produktu
(patrz rozdział o zarządzaniu zakresem)
muszą sobie odpowiadać. Najważniejszym i najtrudniejszym zadaniem jest
koordynacja poszczególnych obszarów zarządzania projektami: zarządzanie
zakresem musi być powiązane z zarządzaniem jakością; zarządzanie personelem
ma wpływ na zarządzanie kosztami; zarządzanie ryzykiem ma wpływ na
zarządzanie zakresem projektu (może spowodować włączenie do zakresu
projektu prac związanych z obsługa ryzyka). Trudno jest wskazać parę
obszarów zarządzania projektami, które nie mogłyby na siebie potencjalnie
oddziaływać; koordynować trzeba w projekcie wszystko ze wszystkim.
Ogólną wstępną, planistyczną
techniką zapewnienia integralności projektu jest opracowanie planu
projektu. Plan ten powinien gromadzić wszystkie plany cząstkowe, związane z
pozostałymi ośmioma obszarami zarządzania projektami oraz plan
zasadniczych, technicznych prac (nie zapominajmy, że chociaż w niniejszym
opracowaniu mówimy głownie o działalności zarządczej, to zdecydowanie
dominująca większość nakładów projektów jest wydawana na zasadnicze prace
techniczne!). Według niektórych opinii zasadniczym celem opracowania planu
projektu jest przekonanie decydentów o wykonalności projektu przy
zaproponowanym podejściu w zadanym budżecie i czasie. „Ubocznymi” zadaniami
planu projektu jest opisanie sposobu realizacji projektu, udokumentowanie
głównych założeń przyjętych w trakcie planowania, udokumentowanie podjęcia
decyzji pomiędzy możliwymi głównymi alternatywami, dostarczenie podstaw do
późniejszych ocen postępu prac.
Każda dziedzina zastosowań ma
swoje metodyki opracowywania planów projektów. Odzwierciedleniem tych
metodyk są wzorcowe struktury planów projektów. Przykładowy plan projektu
software’owego, według Institute of Electrical and Electronics Engineers
(IEEE) standard 1058, powinien mieć następującą ogólną strukturę:
1.
Streszczenie
2.
Organizacja
projektu
3.
Plan procesu
zarządzania
3.1. Plany początkowe
3.2. Plan pracy
3.3. Plany zarządzania
3.4. Plan zarządzania ryzykiem
3.5. Plan sposobu zakończenia projektu
4.
Plan procesów
technicznych
5.
Plan procesów
wspomagających
5.1. Plan zarządzania konfiguracją
5.2. Plan weryfikacji i walidacji
5.3. Plan dokumentowania
5.4. Plan zarządzania jakością
5.5. Przeglądy i audity
5.6. Plan rozwiązywania problemów
5.7. Plan zarządzania poddostawcami
5.8. Plan ulepszania procesu technologicznego
6.
Dodatkowe plany.
Gdy powstanie plan projektu i
zostanie on zatwierdzony przez osoby do tego upoważnione, wystarczy plan
ten zrealizować. Zasadniczą częścią projektu jest jego realizacja – w
sposób opisany w planie projektu. Podstawowe spojrzenie kierownika projektu
na projekt zawiera ciąg zadań, które mają być zrealizowane (inne
spojrzenie, które wydaje się być bliższe rzeczywistości zarządczej,
pokazuje projekt jako ciąg problemów, które muszą być rozwiązane). Każde
zadanie, żeby mogło być wykonane musi być zlecone przez przełożonego
odpowiedniemu przełożonemu lub zespołowi wykonawczemu. W każdym projekcie
musi istnieć sposób zlecania zadań do realizacji.
W praktyce projektowej
spotkałem się z kilkoma sposobami zlecania zadań. W jednym z projektów jego
kierownik uważał, że dostatecznym powodem do rozpoczęcia zadania jest jego
istnienie w ogólnodostępnym harmonogramie, bez jawnego udziału
przełożonego. Taki sposób może prowadzić do braków w koordynacji zadań oraz
do niezrozumienia znaczenia i sposobu realizacji zadania. Inny sposób to
ustne zlecanie zadań. Doświadczenia związane z tym sposobem pokazują, że
niepisanie sposobu realizacji zadania wskazuje na brak wiedzy zlecającego o
zadaniu. W takiej sytuacji zadanie nie może przynieść spodziewanych
rezultatów. Pamiętajmy, że odpowiedzialność za zrozumienie zadania zawsze
ciąży na osobie zlecającej zadanie, a nie na wykonawcy. Inaczej mówiąc,
przełożony nie powinien zlecać zadania dopóki nie jest absolutnie
przekonany, że wykonawca rozumie zadanie. Najwłaściwszym sposobem zlecania
zadań jest jego opisanie w karcie zadania. Należy szczegółowo opisać przede
wszystkim postać wyników i – w miarę możliwości – technikę dochodzenia do tych
wyników.
System zlecania zadań do
wykonania zwykle jest hierarchiczny. Sponsor poleca kierownikowi projektu
rozpoczęcie nowej fazy realizacji projektu. Kierownik projektu, znając
sytuację w zespołach technicznych, zleca rozpoczęcie wykonania głównych zadań.
Kierownicy zespołów technicznych przypisują do wykonania pracownikom
konkretne, szczegółowe prace.
Częścią wykonania planu nie
angażującą procedury zarządzania zmianami są tzw. „działania korygujące”.
Działania korygujące są podejmowane w obliczu przewidywanych zakłóceń w
realizacji planu projektu. Najprostszym, bardzo często spotykanym
przykładem organizacyjnych działań korygujących jest motywowanie
pracownika. Za akcję korygującą można uznać także zabieganie kierownictwa
projektu nieterminowym płatnościom, mogącym mieć wpływ na realizację planu
projektu. Techniczne akcje korygujące to na przykład zapewnienie właściwego
sprzętu zastępczego w przypadku przewidywanej awarii zasadniczego
oprzyrządowania. Akcje korygujące mogą być wykonywane w wyniku przeglądów
stanu projektu, w trakcie których członkowie zespołu sygnalizują
pojawiające się zagrożenia.
Na sytuacje gdy akcje
korygujące nie mogą doprowadzić do planowej realizacji projektu, powinny
być przygotowane ogólne procedury zarządzania zmianami. Procedury takie
powinny także obejmować sytuacje, które prowadzą do lepszej niż planowana
realizacja projektu, czyli okazje. Ogólne procedury zarządzania zmianami
powinny zapewnić koordynację zmian w poszczególnych obszarach. Zwykle każda
zmiana w jednym obszarze zarządzania – np. w zarządzaniu zakresem projektu
– powoduje zmiany w innych obszarach – w zarządzaniu kosztem, harmonogramem
czy ryzykiem projektu. Procedura ogólnego zarządzania zmianami powinna
uwzględniać upoważnienia i odpowiedzialności poszczególnych poziomów
zarządzania projektem.
Zarządzanie integralnością,
chociaż sterowane uprzednio przygotowanymi procedurami, wymaga dużej
inicjatywy i przenikliwości kierownictwa projektu. Wyobrażenie sobie
możliwych konsekwencji każdej zmiany musi opierać się na doświadczeniu
kierownika, zarówno w zakresie realizowanej technologii jak i działań
zarządczych. Umiejętność wdrażania zmian jest jednym z zasadniczych
czynników powodzenia projektów. Brak umiejętności przewidywania
konsekwencji zmian może prowadzić do niekontrolowanego „rozłażenia się”
projektu.
|
