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.

Zarządzanie zakresem

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

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, D_opt), pesymistycznego (najdłuższy czas, D_pes) oraz najbardziej prawdopodobnego dla osoby wykonującej (D_sr) szacowania. Jeśli dostępne są te trzy wartości, do szacowania oczekiwanego czasu trwania czynności (D_e) wykorzystywane jest równanie:

D_e = (D_opt + 4*D_sr + D_pes) / 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 D_ezamiast wartości najbardziej prawdopodobnej (D_sr).

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.

Parametryczne szacowanie projektów software’owych

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

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.

Zarządzanie jakością

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.

Zarządzanie personelem

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.

Organizacja firmy

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).

Organizacja zespołu projektowego

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.

Zatrudnianie personelu

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.

Dynamika zachowań zespołu

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ą

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
Zadanie	Budżet (BCWS)	Uzyskana Wartość (BCWP)	Koszt (ACWP)	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

Zarządzanie ryzykiem

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.

Zarządzanie zaopatrzeniem

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ą

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.

Co zrobić z ustawą Prawo Zamówień Publicznych?

Co zrobić z Urzędem Zamówień Publicznych?

Kto ma wygrywać publiczne przetargi?

Czy najniższa cena oferty gwarantuje najniższy koszt?

Program rozwoju sportu

Wiedza o projektach

Model zarządzania wiedzą o projektach

Wiedza o projektach

Zarządzanie projektami nastawione na wiedzę

Agregaty projektów

Rodziny projektów

Agregaty projektów