Download as pdf or txt
Download as pdf or txt
You are on page 1of 40

Grzegorz Zakrzewski

Podstawy zarządzania projektami


Podstawy zarządzania projektami

SPIS TREŚCI

1. Pojęcia projektu i zarządzania projektami, krótka historia projektów ............................................. 3

2. Różnice pomiędzy projektem, programem i portfelem projektów .................................................. 7

3. Podstawowe metodyki zarządzania projektami ......................................................................... 12

4. Podstawowe ograniczenia w projekcie (trójkąt projektu) ........................................................... 19

5. Podstawowe role w projekcie i ich charakterystyka ................................................................... 22

6. Różne struktury organizacji i umiejscowienie w nich projektu..................................................... 28

7. Charakterystyka zespołów rozproszonych i skupionych z zaznaczeniem pozytywnych i negatywnych


cech z tego wynikających z naciskiem na różne czynniki wpływające na zespół wirtualny
(przywództwo; komunikacja; motywacja; różnice kulturowe) ..................................................... 32

8. Cykl życia zespołu projektowego oraz związane z tym style zarządzania oraz rola lidera
w projekcie/organizacji ........................................................................................................... 36

str. 2
Podstawy zarządzania projektami

1. POJĘCIA PROJEKTU I ZARZĄDZANIA PROJEKTAMI, KRÓTKA HISTORIA PROJEKTÓW

Termin „projekt” pochodzi od łacińskiego słowa proiectus, które oznacza „wysunięcie ku przodowi”,
co należałoby tłumaczyć jako przedstawienie opisu rozwiązania jakiegoś zadania, które ma zostać wy-
konane w przyszłości [Stabryła, 2006].
Zgodnie z definicją zawartą w Słowniku języka polskiego, projekt to zamierzony plan działania, po-
stępowania; pomysł; zamysł lub plan, szkic czegoś [Słownik języka polskiego PWN, 1979].
W literaturze przedmiotu napotykamy wiele definicji projektu; może być on definiowany jako:
1. Zbiór czynności, które współuczestniczą razem w realizacji celu jedynego i mierzalnego [Bran-
denburg, 2002].
2. Sekwencja niepowtarzalnych, złożonych i związanych ze sobą czynności, mających wspólny cel,
przeznaczonych do wykonania w określonym terminie bez przekraczania ustalonego budżetu,
zgodnie z założonymi wymaganiami [Wysocki i McGary, 2003].
3. Organizacja powołana czasowo, która jest potrzebna do wytworzenia unikatowych i wcześniej
określonych produktów, w założonym czasie, z wykorzystaniem przewidzianych zasobów [Zało-
żenia metodyki PRINCE2, za: Brandenburg, 2002; Bradley, 2000].
4. Środowisko zarządzania stworzone w celu dostarczenia jednego lub większej liczby produktów
biznesowych stosownie do specyficznych wymagań biznesu [Założenia metodyki PRINCE2, za:
Brandenburg, 2002].
5. Tymczasowe przedsięwzięcie mające na celu stworzenie unikalnego produktu lub usługi, gdzie
tymczasowość oznacza, że przedsięwzięcie ma ściśle oznaczony początek i koniec, a unikalność,
że produkt lub usługa w wyraźny sposób jest inna niż wszystkie podobne produkty lub usługi
[Project Management Book of Knowledge (w skrócie PMBook), za: Pietras i Szmit, 2003].
6. Zbiór czynności zarządzanych w sposób skoordynowany, podjętych przez jednostkę lub organi-
zację, dla osiągnięcia specyficznych celów, przy zdefiniowanym harmonogramie oraz koszcie
[British Standards, 2002].
7. Zbiór czynności podejmowanych dla zrealizowania określonego celu i uzyskania konkretnego,
wymiernego rezultatu. Rezultatem projektu jest produkt, który sam w sobie projektem nie jest,
lecz definiuje jego wymiar techniczny, czasowy oraz finansowy [Pietras i Szmit, 2003].

Projekt ma wiele definicji, a wszystkie wskazują na to, że aby przedsięwzięcie mogło zostać nazwane
projektem, powinno spełniać określone warunki:
 Powinno ono dotyczyć niepowtarzalnego przedsięwzięcia (niepowtarzalność, jednorazowość),
 Powinno być realizowane dla osiągnięcia konkretnego celu (orientacja na cele),
 Realizacja przedsięwzięcia powinna być ograniczona czasowo (tymczasowość)
 Powinno posiadać odrębność strukturalną (wyodrębnienie organizacyjne),
 Jego efektem powinien być unikalny produkt lub usługa (unikatowość).

str. 3
Podstawy zarządzania projektami

W organizacji równolegle z projektami realizowane są procesy. Również w projektach mamy do czy-


nienia z procesami, zatem istotne jest odróżenie projektu od procesu. Cechy charakterystyczne dla
procesów są następujące:
 Proces jest rutynowy, powtarzalny,
 Proces dodaje nową wartość w wyniku przetworzenia (np. zasobów),
 Proces ma charakter ciągły (np. nie ma określonego końca trwania), natomiast na pewno kiedyś
się zaczyna,
 Proces podlega przemianom ewolucyjnym (np. poprzez obserwację identyfikuje się elementy,
które są udoskonalane),
 Proces dysponuje stabilnymi zasobami (coś, co w większości przypadków nie zdarza się w projekcie),
 Charakteryzuje go niewielki poziom niepewności,
 Usprawnianie odbywa się poprzez zwiększanie wydajności i standaryzację samego procesu.

To, co wydaje się najistotniejsze w odróżnianiu projektu od procesu to ich charakter (proces jest
rutynowy, projekt jest unikalny), czas trwania (proces ma charakter ciągły, projekt ma dokładnie okre-
ślony początek i koniec) oraz sposób dostarczania wartości (w przypadku procesu mówimy o przetwa-
rzaniu zasobów, w przypadku projektu o tworzeniu produktu lub usługi)
Zarządzanie projektami definiowane jest, jako zastosowanie wiedzy, umiejętności, narzędzi
i technik do czynności projektowych, w taki sposób, aby spełnić wymagania projektowe (PMI).
Na zarządzanie projektami składają się takie zadania jak:
 Identyfikowanie wymagań,
 Adresowanie wymagań, oczekiwań, potrzeb i wątpliwość interesariuszy projektu,
 Aktywne ustanawianie oraz utrzymywanie komunikacji między interesariuszami projektu w spo-
sób efektywny i kooperacyjny,
 Zarządzanie oczekiwaniami interesariuszy projektu wobec wymagań projektowych oraz efektów
końcowych projektu,
 Planowanie czynności i zadań oraz rozpoznawanie zależności między nimi,
 Efektywne zarządzanie zespołem projektowym,
 Efektywne zarządzanie zasobami projektowymi (maszyny, ludzie, środki pieniężne, materiały,
infrastruktura IT, itp.), które zawsze są ograniczone w środowisku projektowym i niejednokrotnie
muszą być dzielone z innymi projektami,
 Bieżące monitorowanie postępów projektu z uwzględnieniem harmonogramu i kosztów,
 Zarządzanie ryzykiem i problemami projektowymi,
 Zarządzanie zmianą projektową,
 Balansowanie ograniczeniami projektu (temat 4).

Praktyczny rodowód zarządzania projektami jest wynikiem potrzeby planowania i kontroli realizacji du-
żych projektów, niemożliwych do zarządzania za pomocą tradycyjnych metod. Działalność nosząca cechy

str. 4
Podstawy zarządzania projektami

projektów prowadzona była od bardzo dawna i sięga ponad 4500 lat wstecz. Już w działaniach starożytnych
cywilizacji można wyróżnić elementy, które stanowią podstawę współcześnie stosowanych metod i technik
zarządzania projektem, takich jak: tworzenie planów, organizowanie prac, czy też kontrola realizacji pro-
jektu. Prekursorami tych osiągnięć byli Egipcjanie, stosujący określone reguły i praktyki podczas wznoszenia
piramid oraz świątyń. Za pierwszy obiekt budowlany uznaje się piramidę schodkową Dżesera zbudowaną
ok. 2650 p.n.e. w Sakkarze koło Memfis, z kolei za największy (niemal 147m wysokości) piramidę Cheopsa
w Gizie, której powstanie datuje się na 2560 r. p.n.e. Znane są również wspaniałe budowle Rzymian, Gre-
ków, Majów oraz Inków, realizacje greckich projektów urbanistycznych, rzymskich traktów drogowych, muru
chińskiego, czy innych starożytnych projektów cywilnych i wojskowych1.
Projekty z dużym rozmachem realizowano również w czasach nowożytnych (spektakularne budowle,
np. rzymskie Koloseum, indyjskie mauzoleum Tadż Mahal), jednak z powodu braku wiedzy o stosowa-
nych wówczas sposobach zarządzania wyżej wymienionymi przedsięwzięciami, nie można wskazać jed-
noznacznie początku rozwoju tej dziedziny. Skokowy postęp w zakresie zarządzania projektami rozpo-
czął się w drugiej połowie XIX wieku, kiedy gospodarka stawała się coraz bardziej złożona, a poszcze-
gólne państwa, m.in. pod wpływem rewolucji przemysłowej, zaczęły realizować ogromne inwestycje,
w których niezbędne stawały się dobra organizacja oraz współdziałanie wielu różnorodnych podmiotów.
Umownie przyjęto, że pierwszym projektem, prowadzonym zgodnie ze współczesnym pojęciem zarzą-
dzania projektami, była budowa Pierwszej Kolei Transkontynentalnej w latach 60. XIX wieku w Stanach
Zjednoczonych.
Pomimo, że główne założenia idei zostały zdefiniowane już w XIX wieku, to zarządzanie projektami
zaczęło być powszechnie traktowane, jako jedna z metod zarządzania dopiero w drugiej połowie ubiegłego
stulecia. Pierwsze dedykowane projektom metody planowania i kontroli realizacji opracowane zostały pod-
czas realizacji projektu Manhattan poświęconego budowie bomby atomowej. Decyzję o badaniach i w kon-
sekwencji o produkcji bomby atomowej, podjął rząd Stanów Zjednoczonych w 1941 roku. W ramach
projektu Manhattan uruchomiono w 1942 roku w Stagg Field pierwszy reaktor jądrowy do produkcji ma-
teriałów rozszczepialnych. W roku 1945 przeprowadzono pierwszą próbną eksplozję na pustyni Alamo-
gordo w stanie Nowy Meksyk. Projekt był jednoznacznie ukierunkowany na cele wojenne, jednak po za-
kończeniu II wojny światowej energię jądrową wykorzystano na cele cywilne.
Przy okazji tego projektu opracowano metody planowania i koordynacji w zakresie projektowania
technicznego, budżetowania, organizacji zespołów projektowych, procedur implementacji. Ze względu
na tajemnicę wojskową metody te nie były początkowo upowszechniane. Zastosowano je ponownie
i udoskonalono przy okazji realizacji amerykańskich programów wojskowych (np. projekt Polaris) oraz
projektów kosmicznych (np. projekt Apollo).
Pierwsze cywilne zastosowanie metod zarządzania projektami miało miejsce pod koniec lat 40 XX
wieku w związku z programem pomocowym dla Europy po II wojnie światowej (tzw. plan Marshallla).
Dalszy rozwój zarządzania projektami związany był z realizacją dużych projektów zarówno wojskowych
jak i cywilnych. Wybrane projekty, które wpłyneły na rozwój zarządzania projektami zaprezetowane
zostały na poniższym rysunku (rys 1).

1
http://www.ptzp.org.pl/files/konferencje/kzz/artyk_pdf_2015/T1/t1_0798.pdf

str. 5
Podstawy zarządzania projektami

Rys 1. Wybrane projekty, które wpłyneły na rozwój zarządzania projektami.


Na podstawie: Trocki M.: Zarządzanie projektami. Warszawa, Polskie Wydawnictwo Ekonomiczne, 2009

Gdy na przełomie lat 50 i 60 zarządzanie poprzez projekty szeroko rozpowszechniło się w zastoso-
waniach cywilnych, nastąpił znaczny rozwój metod sieciowych, z których największą popularność zy-
skały CPM (Critical Path Method) i PERT (Program Evaluation and Review Technique).
Intensywne prace nad projektami oraz rozwojem teorii kontynuowano w kolejnych latach aż do mo-
mentu, w którym napotkano barierę technologiczną. Pojawienie się tanich i wydajnych komputerów na
przełomie lat 80 i 90 pozwoliło jednak tę barierę pokonać, co zaowocowało opracowaniem najważniej-
szych programów z zakresu zarządzania projektami. Pod koniec ubiegłego wieku dodatkowo teorię za-
rządzania projektami zaczęto wzbogacać o zagadnienia personalne i kulturowe2.

Doświadczenia z projektu Apollo3:


 Otwarta komunikacja z interesariuszami
 Planowanie jest ważne
 Plany powinny być aktualizowane
 Nie daj się powstrzymać ryzyku
 Zadbaj o komunikację z zespołem
 Deleguj zadania
 Zbieraj doświadczenia
 Świętuj sukces
 Naucz się powtarzać sukcesy

2
http://zarzadzanieprojektami.it/11.html
3
https://www.wrike.com/blog/project-management-lessons-learned-apollo-11-moon-landing/

str. 6
Podstawy zarządzania projektami

2. RÓŻNICE POMIĘDZY PROJEKTEM, PROGRAMEM I PORTFELEM PROJEKTÓW

W organizacjach charakteryzujących się projektowym stylem zarządzania wraz z pojęciem projektu


stosuje się terminy programu oraz portfela projektów, odnoszące się do zbioru projektów.
Program (Rys. 2) oznacza zbiór projektów, realizowanych dla osiągnięcia wspólnego celu, a więc pro-
gram to „portfel projektów wybranych, planowanych i zarządzanych w sposób skoordynowany, które razem
osiągają zespół określonych celów biznesowych” [Założenia metodyki PRINCE2, za: Brandenburg, 2002].

Program

Inne powiązane
Projekt Projekt
zadania

Rys 2. Schemat programu

Portfel (Rys. 3) projektów to z kolei „zbiór projektów i/lub programów oraz innych prac zgrupowa-
nych wspólnie, w celu ułatwienia zarządzania tymi pracami, aby zaspokoić strategiczne cele biznesowe
organizacji” [Brandenburg, 2010]; innymi słowy portfel to zbiór projektów, które dzielą, a także konku-
rują o te same zasoby oraz są zarządzane przez tę samą organizację. Portfel może składać się zarówno
z projektów, jak i z programów, a zawarte w nim przedsięwzięcia nie muszą być ze sobą powiązane.

Portfel

Inne powiązane
Program Projekt Projekt
zadania

Inne powiązane
Projekt Projekt
zadania

Rys 3. Schemat portfela

str. 7
Podstawy zarządzania projektami

Reasumując, program realizowany jest dla pewnych, określonych celów biznesowych, natomiast
portfel dla celów strategicznych przedsiębiorstwa [Turner, 2009]. W skład portfela projektów mogą
wchodzić zarówno projekty, programy, jak i inne portfele projektów. Stanowią one komponenty portfela.
Programy oraz projekty będące komponentami portfela projektów nie muszą być od siebie zależne. Ich
zależność określona jest tylko poprzez fakt korzystania z tych samych zasobów.
Istotnym jest zrozumienie, że każde działanie w organizacji – niezależnie od tego czy jest ono częścią
projektu, programu, portfela projektów, czy jest to tylko działanie operacyjne – powinno być wynikiem
strategii organizacji i powinno ją wspierać. Oznacza to, że każda zmiana w strategii organizacji będzie
pociągała za sobą zmianę w portfelach projektów, programach, projektach oraz pracy operacyjnej rea-
lizowanej w organizacji. Trafnie relacje pomiędzy strategią organizacji a portfelami projektów, progra-
mami i projektami obrazuje rys. 4. Organizacja dostarcza strategii do zarządzania portfelem projektów,
w którym to decyduje się, które programy i projekty powinny być realizowane, a które nie oraz jakie
projekty będą miały priorytet w organizacji. Zarządzanie programem dostarcza pewien cel biznesowy,
który jest częścią celu strategicznego (lub wspiera jego osiągnięcie). Zarządzanie projektami dostarcza
pewny zakres pracy, który wspiera cele programu i/lub portfela.

Organizacja
Dostarcza informacji dotyczącej strategii
oraz wytycznych dla zarządzania portfelami,
programami i projektami

Dostosowywane do strategii organizacji


Kreowane przez strategię organizacji

Zarządzanie portfelem projektów


Decyduje o programach i projektach do realizacji
oraz o ich priorytecie w organizacji, w taki sposób,
aby cele strategiczne organizacji zostały spełnione

Zarządzanie programem
Koordynuje zarządzanie projektami celem
osiągnięcia określonych celów biznesowych,
które wspierają cele strategiczne organizacji

Zarządzanie projektem
Zarządzanie zadaniami mającymi na celu
dostarczenie określonego zakresu, który wspiera
cele programu i/lub portfela projektów, a tym
samym także cele strategiczne organizacji

Rys 4. Relacje projektów, programów oraz portfela projektów ze strategią organizacji


Źródło: na podstawie Rita

str. 8
Podstawy zarządzania projektami

Aby zarządzanie projektami wspierało strategię organizacji musi ona posiadać wysoki poziom dojrzałości.
Jak przekonamy się w kolejnym rozdziale poświęconym metodykom projektowym, na zarządzanie projek-
tami składa się pewna grupa procesów projektowych pogrupowanych w obszary wiedzy. Skoro procesy
można udoskonalać, to również procesy projektowe podlegają doskonaleniu. Ze względu na efektywność
procesów możemy określić dojrzałość organizacij. Jednym z modeli określającym dojrzałość organizacji ze
względu na zarządzanie procesami jest model CMM (Capability Maturity Model). Jest to model, który został
opracowany w celu usprawnienia zarządzania procesami tworzenia systemów oprogramowania. W modelu
tym wyróżnić możemy 5 faz charakteryzujących stopień dojrzałości organizacji:

poziom
poziom poziom poziom poziom
powta-
początkowy zdefiniowany zarządzany optymalizacji
rzalny

Rys 5. Dojrzałość Procesowa Organizacji

1. Poziom początkowy. Organizacje, które znajdują się na tym poziomie nie mają z reguły stabil-
nego środowiska zarzadzania projektami. Nawet, jeśli samo zarządzanie poszczególnymi projektami
odbywa się sprawnie, to w firmie nie istnieją ustalone procesy zarządzania projektami. Procesy te
są często wymyślane, realizowane ad hoc i chaotycznie, a sukces projektu zależy od indywidualnego
zaangażowania kierownika projektu oraz jego umiejętności.
2. Poziom powtarzalny. Na tym poziomie znajduje się organizacja, która wprowadziła podstawowe
procesy zarządzania projektami. Procesy dotyczą jednak tylko ograniczonego zakresu. Proces „ewoluo-
wał od jednej czarnej skrzynki do kilku mniejszych, które przekazują sobie sterowanie poprzez punkty
kontrolne (kamienie milowe projektu). Menadżerowie nawet, gdy nie wiedzą, co się dzieje wewnątrz
czarnych skrzynek znają ich produkty i punkty kontrolne pozwalające na identyfikację procesu”4.
3. Poziom zdefiniowany. Na tym etapie procesy są dokumentowane i standaryzowane. We wszyst-
kich projektach stosuje się sprawdzone procesy. W firmie prowadzone są szkolenia i treningi dla

4
http://www.ploug.org.pl/wp-content/uploads/ploug-konferencja-05-18.pdf

str. 9
Podstawy zarządzania projektami

zapewnienia pracownikom i menadżerom odpowiedniej wiedzy i umiejętności wymaganej przy peł-


nieniu przypisanej im roli. Występuje mniejsza zależność powodzenia projektów od jednostek. „We-
wnętrzna struktura czarnych skrzynek tj. procesów w prowadzonych projektach jest zdefiniowana.
Przedstawia ona sposób, w jaki organizacja aplikuje standardy do realizowanych projektów. Łatwo
i szybko da się określić stan projektu w każdym momencie dzięki temu, że zdefiniowane procesy
pozwalają na pełną obserwowalność działań.
4. Poziom zarządzany. Podstawą tego poziomu jest jakość. Organizacja musi opracować metody mie-
rzenia procesów i zastosowania tychże miar do działań korygujących. Procesy są sterowalne. Ponie-
waż nieokreśloność procesów się zmniejsza, trafność decyzji menadżerów rośnie, ze względu na po-
siadane przez nich obiektywne, ilościowe metody wspomagania procesu decyzyjnego. Gdy miary zo-
stają określone, organizacja wstępuje na drogę implementacji ciągłego doskonalenia procesów.
5. Poziom optymalizacji. Na tym etapie stosowane jest ciągłe doskonalenie procesów poprzez
sprzężenie zwrotne. Opracowane na poprzednim poziomie metody pozwalają na doskonalenie ist-
niejących oraz badanie opłacalności nowych procesów.

Modelem dojrzałości organizacji dostosowanym stricte do procesów zarządzania projektami jest, opra-
cowany przez PMI, standard OPM3. Wdrażanie tego modelu ma na celu wprowadzenie w organizacji
dobrych praktyk w zarządzaniu projektami, programami oraz portfelami w taki sposób, aby udoskonalić
dążenie do spełnienia celów strategicznych organizacji. Standard ten dostarcza metodologii, do ujednoli-
cania i usprawniania procesów projektowych i nie tylko. Standard ten dostarcza także ram dotyczących
procesów zarządzania programami oraz portfelami projektów w taki sposób, aby cała działalność związana
z zarządzaniem projektami była ściśle powiązana ze strategią organizacji. W przeciwieństwie do standar-
dowych modeli dojrzałości organizacji, model OPM3 nie określa, jako takich poziomów dojrzałości organi-
zacyjnej (jak np. przedstawiony wcześniej model CMM). Według modelu OPM3 dojrzałość projektowa
organizacji jest miarą tego jak efektywnie procesy zarządzania projektami, programami i portfelami wpi-
sują się i wpierają strategię organizacji. Innymi słowy - możemy zdefiniować OPM3, jako sposób dostar-
czania strategii poprzez portfele, programy, projekty. OPM3 kładzie nacisk na efektywne wykorzystanie
kapitału ludzkiego poprzez rozwijanie kompetencji zarządzania portfelami, programami, projektami. Po-
zwala on na transformację zarządzania portfelami, programami i projektami w wysokiej jakości proces
dostarczania rezultatów, który jest zrozumiały, stabilny, powtarzalny, przewidywalny.

Istnieją 3 podstawowe elementy wdrażania modelu OPM3 w organizacji:


 Wiedza – podstawą modelu dojrzałości projektowej organizacji jest wiedza z zakresu standardu
zarządzania projektami oraz procesów projektowych.
 Ocena – jest to ocena obecnych procesów zarządzania projektami celem zidentyfikowania słabych
stron istniejących procesów, lub brak procesów w pewnych obszarach. Dostarcza ona informacji
o obszarach do poprawy.
 Doskonalenie – jako rezultat oceny, organizacja pozna słabe strony procesów zarządzania projek-
tami. OPM3 dostarcza informacji, w jaki sposób dokonać usprawnień w zidentyfikowanych obszarach.
Elementy te są ze sobą ściśle powiązane. Wiedza napędza ocenę, która napędza doskonalenie.

str. 10
Podstawy zarządzania projektami

Cykl dokonywania usprawnień w procesach zarządzania projektami w organizacji, (aby wpierały


one strategię organizacji) składa się z 5 kroków:
1. Przygotowanie do oceny. Na tym etapie interesariusze procesu muszą zrozumieć koncepcję
modelu OPM3 oraz standardy i procesy dotyczące zarządzania projektami w organizacji. Dzięki
temu etapowi przygotowawczemu uczestnicy będą w stanie zrozumieć, w jaki sposób powinni
dokonać oceny aktualnego stanu procesów w organizacji.
2. Dokonanie oceny. Podczas tego etapu następuje porównanie charakterystyk określających doj-
rzałość projektową organizacji z tymi opisanymi przez model. Ocena przebiega w dwóch fazach.
W pierwszej kolejności ocenia się, które najlepsze praktyki są obecne w organizacji, a z których
organizacja nie korzysta. Następnie organizacja musi określić, które z najlepszych praktyk chce
wdrożyć i jaka będzie kolejność wprowadzania tych praktyk. W drugiej fazie dla wybranych praktyk
dokonuje się szczegółowej analizy organizacji celem określenia, czy organizacja jest gotowa na
wprowadzenie wybranych praktych (czy ma odpowiednie ku temu zasoby, wiedzę, itp.) Podczas
etapu oceny określa się również korzyści, jakie powinny zostać osiągnięte przez wdrożenie okre-
ślonych praktyk.
3. Planowanie usprawnień. Większość organizacji nie będzie w stanie usprawnić wszystkich obsza-
rów jednocześnie. Usprawnienia w jednym obszarze mogą ściśle zależeć od usprawnień w innych
obszarach. Rezultatem etapu oceny będzie lista usprawnień wraz z nadanymi im priorytetami.
4. Wprowadzanie usprawnień. Kiedy już plan wdrażania usprawnień jest gotowy organizacja po-
winna przystąpić do ich wdrażania. Każda taka inicjatywa powinna być traktowana, jako projekt i jako
taki powinna być zarządzana w odpowiedni sposób. Ponieważ wprowadzane zmiany mogą mieć zna-
czący wpływ na organizację (jej strukturę, strategię, model biznesowy) organizacja powinna być
otwarta na monitorowanie zmian i podejmowanie niezbędnych działań, jeżeli w konsekwencji prowa-
dzonych projektów nastąpi zmiana priorytetów i nowe działania będą musiały zostać podjęte.
5. Powtórzenie procesu. Po ukończeniu czynności skupionych na wprowadzaniu usprawnień or-
ganizacji można zrobić jedną z dwóch rzeczy: dokonać ponownej oceny dojrzałości projektowej
organizacji poprzez przejście do kroku 2 (Ocena) lub wrócić do kroku 3 i podjąć jedną ze zidenty-
fikowanych wcześniej luk, która ze względu na niższy priorytet nie podlegała jeszcze usprawnie-
niom. Polecaną przez standard OPM3 opcją jest przejście do kroku 2, a więc dokonanie ponownej
oceny. Wówczas organizacja może zweryfikować, czy wprowadzone przez nią usprawnienia przy-
niosły oczekiwane rezultaty. Może również mieć miejsce sytuacja, w której usprawnienie, które
było kolejne na liście priorytetów nie jest już wymagane, stąd ponowna ocena pozwoli na zwery-
fikowanie tego oraz organiczenie ryzyka podjęcia niepotrzebnych działań.

Korzyści ze stosowania modelu OPM3 w organizacji jest wiele. Przede wszystkim stosowanie standardu
OPM3 dostarcza organizacji sposobu na wspieranie strategii organizacji poprzez realizowane w niej
portfele, programy oraz projekty. Dodatkowo dostarcza on dobrych praktych w zakresie usprawniania
procesów zarządzania projektami oraz pozwala on na ocenę dojrzałości projektowej organizacji.

str. 11
Podstawy zarządzania projektami

Ponadto, do innych korzyści ze stosowania standardu zaliczmy:


 Zwiększenie produktywności,
 Zwiększenie efektywności operacyjnej,
 Redukcja kosztów oraz ponownego wykonywania czynności (rework),
 Zwiększenie przewagi konkurencyjnej,
 Zwiększenie satysfakcji klientów oraz retencji,
 Zwiększeniu udziału w rynku.

3. PODSTAWOWE METODYKI ZARZĄDZANIA PROJEKTAMI

Metodyka jest pojęciem szeroko rozumianym. W tym kontekście metodyka to ogół zasad, które na-
kreślają, w jaki sposób wykonać daną czynność. Na przestrzeni wielu lat, przy realizacji projektów z róż-
nych dziedzin (budownictwo, reklama, itd.), powstała potrzeba, by tą cenną wiedzę w jakiś sposób
uporządkować.
W 1969 roku powstał Project Management Institute (PMI). Nadrzędnym celem tejże instytucji
jest gromadzenie, analiza doświadczeń, by następnie je wykorzystać do rozpowszechniania metod od-
nośnie realizacji projektów. Następnie powstał zbiór reguł z zakresu zarządzania projektami. Ujęto je
w przewodniku PMBOK5.
PMBOK (Project Management Body of Knowledge) opisuje zarządzanie projektami poprzez pryzmat
5 grup procesów oraz 10 obszarów wiedzy.
Grupy procesów zarządzania projektami wg PMI są następujące:
 Grupa procesów inicjalizacji,
 Grupa procesów planowania,
 Grupa procesów wykonywania (egzekucji),
 Grupa procesów monitorowania i kontroli,
 Grupa procesów zamykania.

Obszary wiedzy zarządzania projektami wg PMI są następujące:


 Zarządzanie integracją projektu,
 Zarządzanie zakresem projektu,
 Zarządzanie czasem projektu,
 Zarządzanie kosztami projektu,
 Zarządzanie jakością projektu,

5
http://goprojekt.pl/baza_wiedzy/strona/metodyki_w_zarzadzaniu/

str. 12
Podstawy zarządzania projektami

 Zarządzanie zasobami ludzkimi,


 Zarządzanie komunikacją,
 Zarządzanie ryzykiem,
 Zarządzanie zakupami (i przetargami),
 Zarządzanie interesariuszami projektu.

Z połączenia grup procesów oraz obszarów wiedzy otrzymujemy następującą listę procesów niezbęd-
nych do realizacji projektu (Tabela 1). Procesy zarządzania projektem są ze sobą powiązane poprzez
produkty przez nie wytwarzane oraz nakładają się podczas cyklu życia projektu.
Nie wszystkie procesy muszą być stosowane w realizowanym projekcie. Jest to zadaniem kierownika
projektu, aby przeanalizować procesy oraz realizować, te które pasują do natury projektu i przyczynią
się do jego sukcesu.

Tabela 1. Procesy zarządzania projektem wg PMBOK w podziale na grupy procesów oraz obszary wiedzy.
Źródło: PMBOK

Grupa Grupa Grupa procesów Grupa


Obszary Grupa procesów
procesów procesów monitorowania procesów
wiedzy planowania
inicjalizacji wykonywania i kontroli zamykania

Zarządzanie Wytworzenie Wytworzenie Planu Kieruj oraz Monitoruj Zamknij


integracją karty projektu. zarządzania projektem. zarządzaj pracą i kontroluj pracę projekt
projektu projektową. projektową. lub fazę.
Wykonuj
zintegrowaną
kontrolę zmian
projektowych.
Zarządzanie Zaplanuj zarządzanie Weryfikuj zakres.
zakresem zakresem. Kontroluj zakres.
projektu Zbierz wymagania.
Zdefiniuj zakres.
Stwórz strukturę
podziału pracy.
Zarządzanie Zaplanuj zarządzanie Kontroluj
czasem harmonogramem. harmonogram.
projektu Zdefinuj czynności.
Ustal kolejność
czynności.
Ustal wymagane
zasoby dla czynności.
Ustal czas trwania
czynności.
Stwórz harmonogram.

str. 13
Podstawy zarządzania projektami

Grupa Grupa Grupa procesów Grupa


Obszary Grupa procesów
procesów procesów monitorowania procesów
wiedzy planowania
inicjalizacji wykonywania i kontroli zamykania

Zarządzanie Zaplanuj zarządzanie Kontroluj koszty.


kosztami kosztami.
projektu Oszacuj koszty.
Ustal budżet.
Zarządzanie Zaplanuj zarządzanie Zapewniaj Kontroluj jakość.
jakością jakością. jakość.
projektu

Zarządzanie Zaplanuj zarządzanie Powołaj zespół.


zasobami zasobami ludzkimi. Rozwijaj zespół.
ludzkimi
Zarządzaj
zespołem.
Zarządzanie Zaplanuj zarządzanie Zarządzaj Kontroluj
komunikacją komunikacją. komunikacją. komunikację.

Zarządzanie Zaplanuj zarządzanie Kontroluj ryzyko.


ryzykiem ryzykiem.
Zidentyfikuj ryzyko.
Dokonaj jakościowej
analizy ryzyka.
Dokonaj ilościowej
analizy ryzyka.
Zaplanuj odpowiedź
na ryzyko.
Zarządzanie Zaplanuj zarządzanie Dokonaj Kontroluj zakupy. Zamknij
zakupami zakupami. zakupów. zlecenia.

Zarządzanie Zidentyfikuj Zaplanuj zarządzanie Zarządzaj Kontroluj


interesariu- interesariuszy interesariuszami. zaangażowaniem zaangażowanie
szami interesariuszy. interesariuszy.
projektu

str. 14
Podstawy zarządzania projektami

Metodyka Prince2 (Projects In Controlled Environments) jest standardem zarządzania projek-


tami, który wywodzi się z Wielkiej Brytanii. Właścicielem metodyki jest rząd Wielkiej Brytanii, w imieniu,
którego metodyką zarządza Office of Government Commerce. Metodyka ta jest ogólnodostępna. Meto-
dyka Prince2 wywodzi się z metodyki PROMPT (Project Resource Organization Management Planning
Technique), która powstała w latach 70. XX w. celem wspomagania realizacji projektów informatycz-
nych. W roku 1989 metodyka PROMPT zmieniła nazwę na Prince, a w roku 1996, po opracowniu kolejnej
wersji tejże metodyki, zmieniła ona nazwę na Prince2. W roku 2009 nastąpiła kolejna aktualizacja stan-
dardu Prince2, który obowiązuje do dzisiaj.
Metodyka Prince jest kompleksową i szczegółową metodyką zarządzania projektami, która w naj-
większym stopniu koncentruje się na działaniach zarządczych i procesach decyzyjnych w projekcie.

Metodyka składa się z czterech zintegrowanych elementów, a są nimi:


 Pryncypia, czyli zasady przewodnie i dobre praktyki, które określają czy projekt jest zarządzany
z wykorzystaniem metodyki. W metodyce istnieje 7 pryncypiów
 Tematy, które opisują aspekty zarządzania projektem, którymi należy się zajmować stale i rów-
nolegle w trakcie całego projektu. W metodyce istnieje 7 tematów.
 Procesy, które opisują krok po kroku działania, jakie są podejmowane w całym cyklu życia
projektu. Każdy proces dostarcza listy kontrolne zalecanych czynności, produkty zarządcze oraz
związane z nimi obowiązki.
 Środowisko projektu, czyli odniesienie się metodyki do kontekstu, w którym realizowany jest
projekt (otoczenie biznesowe).

Pryncypia w metodyce Prince2 stanowią fundamenty metodyki. Są to uniwersalne pryncypia o uzna-


nej wartości, wspólne dla wszystkich projektów realizowanych zgodnie z wytycznymi metodyki bez
względu na rozmiar, branżę, stopień złożoności czy obszar geograficzny.

Metodyka Prince2 posługuję się następującymi pryncypiami:


1. Ciągła zasadność biznesowa – istnieje racjonalny, jasno określony powód uruchomienia pro-
jektu. Powód ten jest weryfikowany w trakcie trwania projektu, aby było możliwe jego zamknięcie
w przypadku utraty zasadności. Celem tej zasady jest zapewnienie, że ograniczone zasoby organi-
zacji są wykorzystywane tylko na realizację projektów generujących korzyści dla organizacji.
2. Korzystanie z doświadczeń – zespoły projektowe uczą się, korzystając z przeszłych doświadczeń
projektowych.
3. Zdefiniowane role i obowiązki - określenie jasnej i przejrzystej struktury zarządzania projektem,
umożliwiającej efektywny przepływ informacji i współdziałanie.
4. Zarządzanie etapowe – podejście do realizacji projektu nakazujące jego planowanie, monitoring
i kontrolę zgodnie z kolejnymi etapami zarządczymi,
5. Zarządzanie z wykorzystaniem tolerancji – zastosowanie tolerancji (dopuszczalnych pozio-
mów odchyleń) dla poszczególnych parametrów projektu. Tolerancje najczęściej dotyczą czasu,
budżetu, ryzyka, korzyści oraz jakości.

str. 15
Podstawy zarządzania projektami

6. Koncentracja na produktach – dostarczenie konkretnych, zdefiniowanych i opisanych produk-


tów projektu, ze szczególnym uwzględnieniem kryteriów jakościowych pozwalających na ich odbiór
i akceptację.
7. Dostosowanie do warunków projektu – zapewnienie, że poziom wdrożenia metodyki do da-
nego projektu odzwierciedla stan jego otoczenia, rozmiar i stopień złożoności projektu, stopień
ryzyka, a także dojrzałość organizacji.

Tematy w metodyce Prince2 to zagadnienia przekrojowe, adresowane i zarządzane w trybie ciagłym


w trakcie trwania projektu.

Tematy w metodyce Prince2 to:


1. Uzasadnienie biznesowe - formalne uzasadnienie realizacji projektu.
2. Organizacja – metodyka dostarcza szczegółowy model struktury organizacyjnej. Na czele projektu
stoi komitet sterujący sprawujący strategiczny zarząd nad projektem. W komitecie zasiadają: prze-
wodniczący (będący jednocześnie sponsorem projektu6), główny użytkownik oraz główny dostawca.
Na mocy delegacji uprawnień bieżące zarządzanie projektem leży w gestii kierownika projektu.
W strukturze mogą pojawić się dodatkowi „gracze”: kierownik zespołu zadaniowego, wsparcie pro-
jektu, nadzór projektu, obsługa zmian.
3. Jakość – uwaga kierownika podczas projektu ma zapewnić, że projekt będzie stosował środki,
które zapewnią, że dostarczane produkty będą zgodne z celem i przeznaczeniem.
4. Plany – w celu sterowania projektem oraz zapewnienia odpowiedniej komunikacji niezbędne są
plany opisujące sposób dostarczania produktów projektu. Występują trzy typy planów: plan pro-
jektu, plan etapu, plan zespołu zadaniowego.
5. Ryzyko – w metodyce stosuje się zarządzanie ryzykiem na podstawie standardu Management of
Risk (M_o_R).
6. Zmiana – w metodyce Prince2 występują trzy elementy zmiany: zintegrowane podejście do obsługi
zagadnień, sterowanie zmianami oraz zarządzanie konfiguracją.
7. Postępy – jest to temat umożliwiający monitorowanie przebiegu projektu i porównanie rzeczywi-
stego postępu z planowanym, jak również dostarczanie prognoz realizacji celów projektu, jego wy-
konalności oraz kontroli wszelkich odchyleń.

6
Sponsor projektu nie jest osobą finansującą projekt. O roli sponsora projektu więcej w temacie 6.

str. 16
Podstawy zarządzania projektami

Procesy w metodyce Prince2 stanowią główną i zasadniczą część metodyki. Dzięki nim projekt jest
realizaowany od kontrolowanego startu do jego kontrolowanego zakończenia.
W metodyce wyróżniamy następujące procesy:
1. Przygotowanie projektu
2. Zarządzanie strategiczne projektem
3. Inicjowanie projektu
4. Sterowanie etapem
5. Zarządzanie dostarczaniem produktu
6. Zarządzanie końcem etapu
7. Zamykanie projektu.

Dostosowanie projektu jest nową częścią metodyki i ma ona na celu wykorzystanie odpowiednich
środków do zastosowania metodyki do specyficznego kontekstu projektu przy zachowaniu poziomu za-
rządzania, odpowiedniego planowania, sterowania i kontroli projektu bez nadmiernego obciążania go
zadaniami zarządczymi7.

Oprócz tych metodyk, wyróżnia się jeszcze wiele innych zbiorów zasad. Te ważniejsze z nich to me-
todyka agilowa (zwinna) Scrum oraz metodyka Ten Steps.
Pojęcie Agile (The Agile Manifesto) wiąże się z deklaracją zasad tworzenia oprogramowania, która
została sformułowana w lutym 2001 roku [5] przez zwolenników alternatywnych metod tworzenia opro-
gramowania a wśród nich, uważany za jednego z twórców i propagatora tej metody Ken Schwaber.
Sam manifest spisany przez uczestników został udostępniony na stronie manifestu [5]: „Ludzie i ich
wzajemne interakcje (współdziałanie) ponad procedury i narzędzia. Działające oprogramowanie nad
wyczerpującą dokumentację. Współpracę z klientem nad negocjację umów. Reagowanie na zmiany nad
realizowanie planu.”8
Termin Scrum (pl. młyn) zaczerpnięty został ze sportu rugby i jest rodzajem rzutu wolnego, w któ-
rym dwie splecione drużyny przepychają się ze sobą nad leżącą na ziemi piłką. W zarządzaniu projektami
mianem Scrum określamy lekką metodyką zarządzania projektami opartą na Agile skupiającą się głównie
na dostarczaniu klientowi funkcjonalności w sposób przyrostowy. Metodyka Scrum opisywana jest, jako
metodyka elastyczna, szybka oraz efektywna. Zapewnia ona przejrzystą komunikację oraz stwarza ide-
alne środowisko do współpracy zespołowej. Silną stroną metodyki są samoorganizujące się zespoły,
które dzielą swoją pracę na krótkie cykle, podczas których wytwarzana jest pewna wartość. Cykle te
nazywane są sprintami. Cykl w metodyce Scrum opisuje poniższy schemat (Rys. 6).

7https://depot.ceon.pl/bitstream/handle/123456789/10129/Metodyka%20PRINCE2%20ocr.pdf?sequence=1
8
http://www.ee.pw.edu.pl/~sarwasg/PPIT/MPSI_SCRUM.pdf

str. 17
Podstawy zarządzania projektami

Co-
dzienne
Harmonogram spotka-
releasów nie

Dostarcz.
produkt

Cel Wizja Rejestr Rejestr Zaakcepto-


projektu projektu produktu sprintu wany produkt

Rys. 6. Cykl w metodyce Scrum. Źródło: Scrum Bok

Scrum opiera się na trzech filarach. Pierwszy to Przejrzystość (Transparency), pozwalająca wszystkim
poznać rzeczywisty stan projektu. Jeżeli zespół mówi, że ukończył pracę nad funkcjonalnością, to zna-
czy, że działa, więc klient może z niej korzystać. Jeżeli w projekcie pojawiają się opóźnienia w stosunku
do ambitnych planów Product Ownera, to są one natychmiast widoczne. Jeżeli w organizacji jest jakaś
dysfunkcjonalność (np. członkowie różnych działów ze sobą nie współpracują), to również jest to na-
tychmiast widoczne. Przejrzystość umożliwia Inspekcję (Inspect), czyli przeanalizowanie, co się dzieje
w zespole, produkcie czy organizacji. Tym samym Scrum pozwala szybko zauważyć problemy (np. wolny
czas odpowiedzi systemu), ale również możliwości (np. nowa funkcjonalność otwierająca przed nami
nowy rynek), które mogą zostać zaadresowanie przez Adaptację (Adapt), czyli zmianę planów i dosto-
sowanie procesu czy produktu do rzeczywistości. Może to być na przykład zmiana zakresu, technologii,
czy sposobu działania zespołu9.

Metodyka Zarządzania Projektami TenStep stworzona została na bazie metodologii Project Manage-
ment Body of Knowledge, opracowanej przez Project Management Institute. Rozwiązania zawarte
w TenStep przekształcają zapisy zawarte w metodologii PMBoK do postaci kompletnego, spójnego oraz
łatwego w zastosowaniu i wdrożeniu systemu. TenStep to metodyka elastyczna i w pełni skalowalna.
Jej filozofia jest prosta: „wielki projekt - obszerna metodyka, mały projekt – oszczędne i proste rozwią-
zania”. TenStep dostarcza kierownikowi projektu wszystkiego, co niezbędne do prowadzenia projektów
dowolnej wielkości 10.
Choć terminologia stosowana w metodyce jest w pełni zgodna ze słownikami PMBoK, dla uproszczenia
procesu zarządzania projektami  wprowadzono pojęcie „kroku”. Poszczególne „kroki” („steps”) odpowia-
dają na potrzebę zwiększania dyscypliny zarządzania projektem wraz ze wzrostem jego skali. Na przykład
wg TenStep, każdy projekt powinien zostać zdefiniowany (krok 1), nawet, jeśli harmonogram nie będzie
tworzony w sposób formalny. Jeśli projekt osiągnie pewną skalę, harmonogram stanie się niezbędny
(krok 2). Jeśli harmonogram zostanie stworzony, konieczne stanie się zarządzanie nim (krok 3). Jeśli pro-

9
http://procognita.pl/zasoby/artykuly/czytaj/artykul/co-to-jest-scrum-58/
10
http://osb.edu.pl/images/tenstep/TenStep_opis_proces__w.pdf

str. 18
Podstawy zarządzania projektami

jekt jest niewielki, prawdopodobnie nie jest niezbędne zajmowanie się jego ryzykami czy jakością w spo-
sób ściśle zaplanowany. Jeśli jednak wystąpią problemy krytyczne – trzeba się nimi zająć (krok 4). Jeszcze
większe przedsięwzięcie będzie wymagało zarządzania zmianą (krok 5) itd. Numeracja „kroków” ustala
równocześnie ich priorytety, dlatego odbiega ona od numeracji PMBoK. Obszerne projekty powinny być
planowane (kroki 1 i 2) i zarządzane (kroki 3 do 10) we wszystkich aspektach równolegle. Mniejsze pro-
jekty będą skoncentrowane po prostu na mniejszej liczbie kroków.

Kroki w metodyce Ten Steps są następujące:


Krok 1. Zdefiniowanie pracy do wykonania
Krok 2. Budowanie planu i budżetu
Krok 3. Zarządzanie planem i budżetem
Krok 4. Zarządzanie problemami krytycznymi
Krok 5. Zarządzanie zmianą
Krok 6. Zarządzanie komunikacją
Krok 7. Zarządzanie ryzykiem
Krok 8. Zarządzanie personelem
Krok 9. Zarządzanie jakością
Krok 10. Zarządzanie pomiarem

4. PODSTAWOWE OGRANICZENIA W PROJEKCIE (TRÓJKĄT PROJEKTU)

Każdy projekt ma precyzyjnie określone wymagania, które definiowane są przez następujące para-
metry: zakres (zadania konieczne do wykonania dla osiągnięcia celu), jakość (zgodność rezultatów
z oczekiwaniami), koszt (nakłady związane z wykonaniem wymaganych działań), czas (okres potrzebny
do wykonania wymaganych działań) i zasoby (materiały, pracownicy, informacje, urządzenia i wiedza
potrzebna do wykonania wymaganych zadań).
Parametry te są wzajemnie współzależne, a zmiana któregokolwiek z nich pociąga za sobą zmianę
przynajmniej jednego z pozostałych. W tym kontekście zestaw wymienionych parametrów tworzy trójkąt
ograniczeń projektu. Trójkąt ten jest sztywny. Oznacza to, że zmiana w jednym z obszarów pociąga za
sobą konieczność zmiany w innym.

str. 19
Podstawy zarządzania projektami

Czas Koszty

Zakres

Rys 7. Trójkąt projektu

Zarządzanie projektem wymaga utrzymania trójkąta ograniczeń w równowadze, co wymaga odpo-


wiedniego podejścia, wiedzy i umiejętności. Zarządzanie projektami polega na zapewnianiu, że w trakcie
realizacji projektu zasoby wykorzystywane są w sposób najbardziej efektywny, w taki sposób, że projekt
zakończy się sukcesem. Jako podstawowe cele zarządzania projektami przyjmuje się:
 Spełnienie określonych wymagań projektu,
 Utrzymanie kosztów projektu w wyznaczonym limicie,
 Realizację projektu w wyznaczonym okresie czasu11.

We współczesnym zarządzaniu projektami trójkąt zarządzania projektami został zaaktualizowany ze


względu na zidentyfikowanie dodatkowych ograniczeń nakładanych na projekt. I tak wedle współcze-
snych metodyk zarządzania, rozróżniamy siedem organiczeń projektu, a są to:
 Czas,
 Koszty
 Zakres,
 Jakość,
 Satysfakcja klienta,
 Ryzyko,
 Zasoby.

11
http://www.lbs.pl/projekt/dobrepraktyki2011/files/artykuly/art_Malyszek.pdf

str. 20
Podstawy zarządzania projektami

Relacja pomiędzy ograniczeniami projektu jest taka, że jeżeli jeden z elementów ulegnie zmianie,
przynajmniej jeden inny element zostanie dotknięty tą zmianą.

Czas Koszty

Zasoby Zakres

Ryzyko Jakość

Satysfakcja
Klienta

Rys 8 Ograniczenia projektu

Przykład
Jeżeli harmonogram projektu zostaje skrócony, często budżet wymaga podniesienia celem dodania
dodatkowych zasobów do ukończenia tego samego zakresu prac, w krótszym okresie czasu. Jeżeli pod-
niesienie budżetu nie jest możliwe, wówczas zakres projektu może zostać zredukowany lub jakość może
zostać obniżona, aby zakończyć projekt w krótszym okresie czasu, lecz przy niezmienionym budżecie.
Interesariusze projektu mogą mieć odmienną opinią na temat tego, które ograniczenia są najistotniej-
sze, co powoduje jeszcze większe wyzwania w projekcie. Zmiana wymagań projektu lub jego celów
generuje dodatkowe ryzyko.

Kierownik projektu musi być w stanie ocenić sytuację, zarządzać oczekiwaniami interesariuszy w za-
kresie istotności ograniczeń oraz utrzymywać proaktywną komunikację z interesariuszami, aby zakoń-
czyć projekt z sukcesem.

str. 21
Podstawy zarządzania projektami

5. PODSTAWOWE ROLE W PROJEKCIE I ICH CHARAKTERYSTYKA

W każdym projekcie czy organizacji, będą znajdować się różne funkcje (osoby/grupy), które będą
miały określone zadania do wykonania i będą sprawować różne funkcje zarówno wewnątrz jak i na
zewnątrz projektu. Poniżej wymienione zostały główne role i krótki opis zakresu ich podstawowych
obowiązków. Zrozumienie tego jest niezmiernie ważne, jako że projekt musi działać jak dobrze zapro-
gramowana maszyna i bardzo ważnym jest, żeby poszczególne funkcje rozumiały w jak najlepszy sposób
zakres swoich obowiązków oraz decyzyjność – tak, aby uniknąć duplikowania się oraz nieporozumień
z podejmowaniem decyzji. Poniżej wymieniono główne funkcje występujące w projekcie i zakres ich
działań:
Kierownik projektu – „Twoją rolą jako managera projektu jest wspomaganie ludzi w zespole w ich
zadaniach. Ich sukces jest Twoim sukcesem”. (Jack Welsch)
Powyższy cytat w doskonały sposób oddaje podsumowanie, za co tak naprawdę odpowiedzialny jest
kierownik projektu. W skrócie jest odpowiedzialny kompleksowo za sukces projektu (a także za jego po-
rażkę). Kompetencje i zadania kierownika projektu w dużej mierze będą zależały od struktury organizacji,
w jakiej funkcjonuje projekt (rozdział 6). Przyjmijmy, że znajdujemy się w organizacji projektowej.

Poniżej opisane w bardziej dokładny sposób zadania kierownika projektu12:


 Przydzielanie zadań członkom zespołu projektowego lub koordynatorom projektu
 Aktualizowanie planu projektu poprzez:
 gromadzenie danych przekazywanych przez poszczególnych członków zespołu do tego wy-
znaczonych w formie regularnych raportów
 integrowanie danych przekazanych przez zespół na poziomie planu projektu
 Kompleksową analizę projektu w celu rozwiązywania pojawiających się problemów i zagrożeń
projektowych
 Zapewnienie projektowi odpowiednich zasobów (ludzi, sprzętu, środków finansowych, itp.) po-
przez negocjowanie ich z innymi managerami/działami organizacji
 Informowanie zespołu na bieżąco o postępach w projekcie i szczegółach planu a także jasne
przekazywanie informacji o podziale obowiązków
 Sporządzanie regularnych raportów na temat:
− postępów w osiąganiu kolejnych kamieni milowych,
− stopniu wykonania planu i odchyleń z tym związanych,
− stopniu budżetu oraz kosztów (aktualnych i prognozowanych) a także odchyleń z tym zwią-
zanych,
− problemów i ryzyk projektowych
 Reprezentowanie projektu na „zewnątrz” poprzez raportowanie do zarządu, sponsora czy infor-
mowanie organizacji o wartości dodanej projektu oraz jego statusie
 Zarządzanie interesariuszami projektu

12
Zarządzanie projektami – sztuka przetrwania

str. 22
Podstawy zarządzania projektami

 Integrowanie projektu na poziomie pakietów prac czy poszczególnych podprojektów a także


identyfikowanie zależności pomiędzy różnymi pakietami prac w projekcie
 Zarządzenie eskalacją do kierownictwa wyższego szczebla, czy sponsora projektu
 Współpracowanie z podwykonawcami, którzy dostarczają coś bezpośrednio do projektu
 Monitorowanie wydajności członków zespołu projektowego, dostarczenie na bieżąco informacji
zwrotnej dla członków zespołu projektowego oraz motywowanie zespołu
 Bycie „ambasadorem” projektu dla zewnętrznego świata

Jeśli zaś chodzi o cechy i umiejętności kierownika projektu to jest wiele cech, które muszą silnie
wpływać na zespół i otoczenie. Poniżej zaprezentowane zostało zestawienie pokazujące, jakich cech się
dzisiaj szuka u kierowników projektów.
Przyjrzyjmy się cechom dzisiejszych kierowników projektów tak bardzo poszukiwanych na rynku:
 Zdolności komunikacyjne,
 Przywództwo, budowanie zespołu, motywowanie zespołu,
 Negocjowanie w poszukiwaniu kompromisu,
 Skuteczne zarządzanie konfliktem,
 Zaangażowanie i motywacja,
 Bycie zorganizowanym,
 Umiejętność delegowanie zadań,
 Umiejętność działania pod presją,
 Zdolność szybkiego rozwiązywania problemów,
 Entuzjazm, empatia,
 Posiadanie odpowiednich umiejętności i wiedzy związanych z danym obszarem (na przestrzeni
lat nie jest to już główna cecha poszukiwana u kierowników projektów).

Generalnie, praca kierownika projektu ma bardzo szeroki zakres. Niejednokrotnie kierownik projektu
w różnych artykułach jest porównywany do przysłowiowego Supermana, jako, że nie rzadko prosi się
go o dokonanie niemożliwego.
Najważniejsze to zrozumieć, że jako kierownik projektu musimy skupić się na holistycznym zarządza-
niu całością projektu. W szczególności przy dużych przedsięwzięciach nie możemy za bardzo stosować
„mikromanagementu”, jako że najzwyczajniej w świecie nie będziemy mieli na to czasu i musimy tak
delegować zadania i zarządzać zespołem, aby właściwi ludzie mogli wykonywać właściwe zadania. My-
ślę, że może być trafnym porównaniem, że kierownik projektu ma podobna specyfikę obowiązków jak
właściciel firmy. Zatrudnia ludzi do wykonania pracy, kontroluje finanse i reprezentuje przedsięwzięcie
na zewnątrz. Jak się dobrze zastanowić te funkcje mają ze sobą dużo wspólnego.

str. 23
Podstawy zarządzania projektami

Interesariusz projektu – interesariusz projektu to każda osoba lub instytucja zarówno wewnątrz
projektu (organizacji) lub na zewnątrz, która albo ma jakiś żywotny interes w projekcie lub projekt na
nią wpływa w jakiś sposób.
Spróbujmy wymienić kilka najważniejszych grup interesariuszy:
 Główny odbiorca projektu (może to być klient lub wewnętrzny dział w organizacji)
 Nasz własny zespół projektowy
 Różne działy w firmie, które w jakiś sposób są związane z naszym projektem np.:
− dział finansowy, bo nasz projekt ma obniżyć koszy o 15%,
− dział rekrutacyjny, bo ma nam zatrudnić 2 nowych specjalistów do pracy nad technologią
nieznaną w naszej organizacji,
 Inny projekt w firmie, bo dzielimy z nim zasoby,
 Sponsor projektu,
 Różne instytucje na zewnątrz projektu, od których nasz projekt może być zależny (np. jakiś
urząd, który ma wydać konkretna decyzję administracyjno-prawną potrzebną do wykonania na-
szego projektu),
 Różni poddostawcy i partnerzy, od których jesteśmy zależni albo, którzy dla przykładu, będą
dystrybuować końcowy produkt naszego projektu,

Można by wymieniać bardzo wiele przykładów, natomiast najważniejsze dla kierownika projektu jest
zidentyfikowanie jak najwcześniej, możliwie jak najwięcej interesariuszy projektu (nie piszę tutaj wszyst-
kich, bo w większości przypadków będzie to niemożliwe). Po zidentyfikowaniu, należy interesariuszami
projektu w umiejętny sposób zarządzać, co w praktyce sprowadza się do jasnej analizy:, „czego mój
projekt potrzebuje od kogoś spoza projektu i co mój projekt daje komuś”. Mając tą wiedzę musimy
umiejętnie żonglować i negocjować, czyli zarządzać abyśmy mogli w optymalny sposób wykorzystać
dane otoczenie projektowe.

Koordynator projektu – funkcja koordynatora jest raczej ciężka do zdefiniowania odgórnie.


W praktyce to zastępca kierownika projektu lub w przypadku większych projektów ktoś zarządzający
podprojektem lub większym pakietem prac (w przypadku większych projektów, kierownik projektu może
mieć kilku koordynatorów projektu pracujących dla niego). Ważnym stwierdzeniem jest fakt, że koor-
dynator projektu ma ograniczoną decyzyjność lub nie ma jej wcale (ponownie zależy to od ustaleń
i podziału obowiązków wypracowanych przy ustalaniu struktury organizacyjnej w projekcie).
Dla tych, którzy są fanami „Gwiezdnych Wojen” kierownik projektu to mistrz Jedi a koordynator to
Padawan.

Kierownik programu – to ktoś, kto zarządza powiązaną ze sobą grupą projektów. W tym wypadku
mówimy oczywiście o większych przedsięwzięciach (przeważanie wielomilionowych gdzie warto inwe-
stować w tak duże struktury). Jeśli mówimy o zadaniach i charakterystyce tej funkcji to większość z nich
będzie pokrywała się z zadaniami kierownika projektu (niejednokrotnie kierownik programu jest nadal
nazywany kierownikiem projektu – to wszystko zależy od tego jak bardzo organizacja ma rozwiniętą

str. 24
Podstawy zarządzania projektami

dojrzałość i kulturę projektową) takimi jak: raportowanie, reprezentowanie programu na zewnątrz, za-
rządzanie eskalacją, zapewnienie zasobów tylko o poziom wyżej niż kierownik projektu. Natomiast jest
kilka zadań unikatowych, których kierownik projektu już nie wykonuje na swoim poziomie:
 Priorytetyryzacja poszczególnych projektów w programie – niejednokrotnie trzeba będzie przerzucić
zasoby z jednego projektu do drugiego, który ma większy priorytet dla klienta albo na daną chwilę
jest bardziej eskalowany. To właśnie kierownik programu musi zarządzać i umieć podjąć te decyzje
w ujęciu holistycznym
 Integracja poszczególnych projektów w jedną spójną całość (program). Poszczególni kierownicy
projektu, mogą najzwyczajniej nie wiedzieć lub po prostu nie być zainteresowani informacją jak ich
projekt wpływa na inne projekty w programie. Tutaj właśnie przejawia się główna rola kierownika
programu, aby te powiązania i zależności zidentyfikować i sprawnie nimi zarządzać poprzez umie-
jętne między nimi balansowanie

Kierownik portfela projektów – to także rola wyższego szczebla niż kierowanie projektem. Rola
ta różni się tym od kierownika projektu, tym że portfel projektów składa się z projektów lub programów,
mających na celu osiągniecie założonego celu strategicznego organizacji, ale nie do końca ze sobą po-
wiązanych. Główne zadania kierownika portfela projektów pozostaną nadal zbliżone do pozostałych
dwóch funkcji:
 Zarządzanie zasobami na przekroju całego portfela,
 Ewaluacja ekonomicznej zasadności indywidulanych projektów na poziomie portfela w odniesieniu
do założeń strategicznego celu organizacji,
 Raportowanie statusu portfela,
 Zarządzania finansami,
 Identyfikowanie zależności pomiędzy projektami, jeśli takie istnieją,
 Reprezentowanie portfela projektów na, „zewnątrz” jako całości,

Zespół projektowy – to grupa ludzi powołanych przez kierownika projektu lub organizację (kie-
rownik projektu nie zawsze ma wpływ/wybór, kto dla niego pracuje – w zasadzie to w większości wy-
padków nie ma), która będzie wykonywać zadania projektowe powierzone przez kierownika, sprowa-
dzające się w szczególności do (zakładając, że kierownik projektu wie jak wykorzystać swój zespół):
 Uczestniczenie w budowanie planu projektu, w szczególności zidentyfikowaniu zadań, które mają
być wykonane oraz potrzebnego czasu do ich wykonania,
 Wykonywanie zadań powierzonych przez kierownika projektu w zgodzie z wcześniej opracowanym
planem,
 Wyszukiwanie w planie projektu luk oraz błędów i informowanie o tym kierownika projektu,
 Informowanie kierownika projektu o swojej dostępności w ramach projektu (szczególności ważne
jeśli zasoby w projekcie są dzielone)
 Raportowanie do kierownika projektu statusu wykonania poszczególnych zadań i ewentualnych od-
chyleń od założonego planu

str. 25
Podstawy zarządzania projektami

 Identyfikacja i zgłaszanie ryzyk projektowych, ale także zarządzanie nimi w zakresie swoich kom-
petencji i obowiązków,
 Zgłaszanie zmian projektowych, jeśli zespół widzi, że coś jest nie do wykonania wg przyjętych
wcześniej założeń (np. zmieniła się technologia).

Ważne jest żeby zrozumieć, że coraz rzadziej w projektach mamy luksus posiadania dedykowanego
zespołu projektowego, szczególnie, jeśli chodzi o zasoby techniczne. Jest powszechną praktyką, że dzie-
limy nasze zasoby z innym projektem, co dodatkowo utrudnia zarządzanie zespołem.
Generalnie zespół projektowy to serce projektu i jako kierownik projektu musimy naprawdę z nim
blisko współpracować i tworzyć odpowiednie relacje a nie tylko zarządzać.

Kierownik funkcjonalny – ważna rola, która głównie wchodzi w interakcje z kierownikiem pro-
jektu. Kierownik funkcjonalny to głównie osoba, od której kierownik projektu „wypożycza” zasoby na
czas trwania projektu. Jest bardzo ważne, aby budować relację z kierownikami funkcjonalnymi, jako
jednymi z głównych interesariuszy projektu, jako, że w dzisiejszych korporacjach pozyskiwanie zasobów
przypomina nieskończoną batalię.

Sponsor – jest to osoba lub grupa osób, która dostarcza zasobów do projektu, oraz go wspiera. Jest
to osoba, odpowiedzialna za to, aby umożliwić projektowi osiągnięcie sukcesu. Sponsor może być osobą
zarówno z organizacji kierownika projektu, jak i spoza niej. Sponsor promuje projekt od momentu jego
inicjacji. Kolokwialnie mówiąc, sponsor powinien być dla kierownika projektu swoistym asem w rękawie,
jokerem, którym można zagrać, kiedy wszystko inne zawiodło. Bardzo ważnym jest, żeby używać go
mądrze, co przede wszystkim wiąże się z tym żeby użyć go w odpowiedniej sytuacji i w odpowiednim
czasie (nie za wcześniej i nie za późno)
Główne zadania sponsora zależą od wielkości projektu. W szczególności można przytoczyć poniższe:13
 Zatwierdzenie Karty Projektu
 Dopilnowanie wykonalności projektu z perspektywy wykonalności celów biznesowych
 Rozwiązywanie problemów, wykraczających poza kompetencję kierownika projektu
 Powołanie Komitetu Sterującego, jeśli takowy jest potrzebny
 Zatwierdzenie dodatkowego budżetu w przypadku, kiedy budżet podstawowy się wyczerpał
 Podjęcie decyzji o przerwaniu projektu (decyzja może być podjęta z różnych powodów).

Komitet sterujący14 – jest to organ, który wspiera kierownictwo przedsiębiorstwa w działaniu.


W głównej mierze dotyczy podejmowania decyzji strategicznych, obejmujących zakres realizacji w przy-
szłości. Podejmuje on decyzje przy rozplanowaniu różnych projektów, decydując, który ma wejść w ży-
cie. Jest również odpowiedzialny za jego monitoring oraz zarządzanie, czyli kontrolę na poziomie stra-
tegicznym, czy projekt jest realizowany zgodnie z założonymi wcześniej celami, w zadanym budżecie
oraz terminie. Ocenianie i akceptacja jest wynikiem konsensusu, czyli przy udziale Zespołu Projekto-
wego, który proponuje działania zmierzające do realizacji projektu.

13
Zarządzanie projektami – sztuka przetrwania
14
http://www.projekty.4innovations.pl/tag/komitet-sterujacy-zarzadzanie-projektem/

str. 26
Podstawy zarządzania projektami

Komitet sterujący może służyć jednemu projektowi lub być powołany w organizacji dla toczących się
wszystkich projektów.

Biuro Projektu to instytucja nie zawsze występująca w projektach czy nawet w organizacjach.
Istnienie tego tworu jest zależne od dojrzałości projektowej. Biuro projektowe w zależności od wielkości
projektu może być dedykowane dla danego projektu a może być także na poziomie organizacji, jako
„rada” wspierająca właśnie toczące się projekty. Ponownie ze względu na organizację biuro projektowe
może pełnić różne funkcje:
 Wspierającą – biuro projektowe ma tutaj w większości rolę administracyjną sprowadzająca się do
wsparcia projektu (gromadzenie dokumentacji, dostarczanie formularzy standardowych dokumen-
tów projektowych, raportowanie, itp.)
 Kontrolującą – biuro projektowe wyznacza standardy prowadzenia projektów poprzez trzymanie
się odpowiedniej metodologii i narzędzi. Zajmuje się kontrolowaniem stanu projektów i odpowied-
nim raportowaniem
 Zarządzającą – biuro projektowe ma całkowitą kontrolę nad projektem i nim zarządza

W zależności od stopnia „władzy” biura projektowego może się ono składać albo z pracowników
administracyjnych, w przypadku funkcji wspierającej, przechodząc w najbardziej doświadczonych kie-
rowników projektów w organizacji w przypadku funkcji zarządzającej.
W przekroju całościowym biuro projektowe będzie pełniło następujące zadania:
 Kontrolowanie i zbieranie dokumentacji projektowej w projekcie,
 Zbieranie najlepszych praktyk podczas projektu i na jego końcu (lessons learnt),
 Dostarczanie projektowi formularzy podstawowych narzędzi zarządzania projektem (formularz
zmiany projektowej, formularz zgłoszenia ryzyka, itp.),
 Kontrolowanie finansów w projekcie, a w szczególności stopnia zużycia budżetu oraz kosztów, jakie
deklarują w projekcie poszczególne zasoby w relacji do faktycznego wykonania przez nich pracy,
 Prowadzenie rejestru ryzyk i problemów projektowych a także zarządzanie nimi,
 Prowadzenie rejestru zmian projektowych,
 Kontrolowanie zintegrowanego planu (w przypadku programu),
 Gromadzenie dowodów dostarczania poszczególnych kamieni milowych w projekcie,
 Kontrolowanie przebiegu planu projektu i wynikających z tego odchyleń,
 Organizowanie zasobów projektowych a także wymaganej z tego powodu dokumentacji,
 Kontrolowanie kierowników projektów czy stosują się do wymaganych standardów i metodyk za-
rządzania projektami w danej organizacji,
 Zapewnianie wparcia metodologicznego dla prowadzonych projektów,
 Pomoc w zarządzaniu (lub zarządzanie) podwykonawcami,
 Asystowanie lub formalne zamykanie projektów.

str. 27
Podstawy zarządzania projektami

6. RÓŻNE STRUKTURY ORGANIZACJI I UMIEJSCOWIENIE W NICH PROJEKTU

Zarządzanie projektami odbywa się w środowisku, które jest znacznie szersze niż sam projekt i które
ma znaczący wpływ na jego realizację. Zrozumienie środowiska, w jakim projekt jest realizowany po-
zwala na wykonywanie prac projektowych zgodnie z celami organizacji, a także zgodnie z najlepszymi
praktykami stosowanymi w organizacji.
Kultura, styl oraz struktura organizacji wpływają na to, jak projekty są realizowane. Innymi elemen-
tami, jakie wpywają na sposób realizacji projektów jest dojrzałość projektowa organizacji oraz system
zarządzania projektami w niej stosowany.
Wyróżniamy następujące typy organizacji, w których projekty są realizowane:
 Funkcjonalna,
 Macierzowa,
 Projektowa.

Autorytet kierownika projektu, jak i dostepność zasobów dla celów projektowych jest zróżnicowana,
w zależności od typu struktury orgzanicyjnej (Tabela 2).

Tabela 2. Wpływ struktury organizacyjnej na zarządzanie projektem. Źródło: PMBOK

Struktura
organizacyjna/ Organizacja macierzowa
Organizacja Organizacja
Charakterystyka Funkcjonalna projektowa
projektowa Słaba Zbalansowana Silna

Autorytet
Mały do Średni do Wysoki do
Kierownika Mały lub żaden Mały
średniego wysokiego absolutnego
projektu

Dostępność Niska do Średnia do Wysoka do


Mała lub żadna Niska
zasobów średniej wysokiej absolutnej

Kierownik
Kto zarządza
Kierownik Kierownik funkcjonalny Kierownik Kierownik
budżetem
funkcjonalny funkcjonalny i/lub Kierownik Projektu Projektu
projektu
projektu

W niepełnym W niepełnym W pełnym


Rola Kierownika W pełnym W pełnym
wymiarze wymiarze wymiarze
projektu wymiarze czasu wymiarze czasu
czasu czasu czasu

Zespół
W niepełnym W niepełnym W pełnym
administrowania W niepełnym W pełnym
wymiarze wymiarze wymiarze
projektem wymiarze czasu wymiarze czasu
czasu czasu czasu
(tzw. PMO)

str. 28
Podstawy zarządzania projektami

Klasyczna funkcjonalna struktura organizacyjna (Rysunek 9) to taka hierarchia, w której każdy


pracownik ma jednego przełożonego. Pracownicy są pogrupowani w zespoły (lub departamenty) ze
względu na specjalność, np. marketing, księgowość, itp. Każdy departament w takiej strukturze będzie
realizował projekt niezależnie od innych departamentów.

Szare pola oznaczają pracowników zaangażowanych w projekt

Rys 9. Funkcjonalna struktura organizacyjna. Źródło: PMBOK

Macierzowa struktura organizacyjna stanowi mieszankę pomiędzy strukturą funkcjonalną a pro-


jektową. W zależności od poziomu wpływu oraz władzy kierownika projektu oraz kierownika departa-
mentu w ramach macierzowej struktury organizacyjnej możemy wyróżnić:
 Strukturę macierzową słabą,
 Strukturę macierzową zbalansowaną,
 Strukturę macierzową silną.

Słaba struktura macierzowa (rys 10) jest zbliżona do struktury funkcjonalnej, a rola kierownika
projektu sprowadza się tak naprawdę do koordynatora projektu. W takiej strukturze organizacyjnej
głównymi zadaniami koordynatora projektu jest komunikacja, raportowanie postępu projektu oraz sta-
nowienie funkcji pomocniczej dla zespołu projektowego. Decyzyjność koordynatora projektu jest orga-
niczona (lub nawet żadna).
Silna struktura macierzowa (rys 11) zbliżona jest do struktury projektowej, w której występuje
kierownik projektu w pełnym wymiarze czasu pracy, z dużym autorytetem oraz z dostępnym PMO w peł-
nym wymiarze czasu.

str. 29
Podstawy zarządzania projektami

W zbalansowanej strukturze macierzowej (rys 12) występuje kierownik projektu, jednak nie
posiada on pełnego autorytetu oraz pełnej władzy nad budżetem projektu.

Szare pola oznaczają pracowników zaangażowanych w projekt

Rys 10. Słaba macierzowa struktura organizacyjna. Źródło: PMBOK

Szare pola oznaczają pracowników zaangażowanych w projekt

Rys 11. Silna macierzowa struktura organizacyjna. Źródło: PMBOK

str. 30
Podstawy zarządzania projektami

Szare pola oznaczają pracowników zaangażowanych w projekt

Rys 12. Zbalansowana macierzowa struktura organizacyjna. Źródło: PMBOK

Zupełnie przeciwna do funkcjonalnej struktury organizacyjnej jest projektowa struktura organi-


zacyjna (rys 13). Zespół projektowy jest w pełni zaangażowany w prace projektowe a kierownik pro-
jektu ma dużą niezależność oraz autorytet. Taka organizacja bardzo często posiada jednostki zwane
departamentami, lecz one raportują bezpośrednio do kierowników projektów lub dostarczają wsparcie
do różnych projektów.

Szare pola oznaczają pracowników zaangażowanych w projekt


Rys 13. Projektowa struktura organizacyjna. Źródło: PMBOK

str. 31
Podstawy zarządzania projektami

Większość struktur organizacyjnych posiada różne poziomy zarządzania: poziom strategiczny, poziom
zarządzania średniego szczebla oraz poziom zarządzania operacyjnego. Kierownik projektu podczas re-
alizacji projektu może wchodzić w interakcje z każdym z tych poziomów.

7. CHARAKTERYSTYKA ZESPOŁÓW ROZPROSZONYCH I SKUPIONYCH Z ZAZNACZENIEM


POZYTYWNYCH I NEGATYWNYCH CECH Z TEGO WYNIKAJĄCYCH
Z NACISKIEM NA RÓŻNE CZYNNIKI WPŁYWAJĄCE NA ZESPÓŁ WIRTUALNY
(PRZYWÓDZTWO; KOMUNIKACJA; MOTYWACJA; RÓŻNICE KULTUROWE)

Pojęcie zespołów rozproszonych (potocznie zwanych wirtualnymi) to stosunkowo nowe zjawisko


w zarządzaniu projektami w Polsce. Zespół rozproszony zaczął coraz częściej się pojawiać na arenie
zarządzanie projektami w Polsce w związku z rozwojem usług outsourcingowych w naszym kraju oraz
powstawaniem w głównych aglomeracjach (Kraków; Wrocław; Łódź; Poznań; Gdańsk, Katowice) pol-
skich centr świadczenia usług wspólnych (Shared Service Centers).
Centra te są przedłużeniem europejskich lub amerykańskich siedzib dużych korporacji w obszarach
głównie IT i różnych usług (głównie finansowo – księgowych i kadrowych).
Głównymi czynnikami powstawania tego rodzaju placówek są oczywiście koszty pracy, które w Polsce
są jak na razie zdecydowanie niższe niż w krajach Europy Zachodniej, stosunkowo wysoka jakość świad-
czonych usług w stosunku do tejże ceny, duża podaż młodych i wykształconych ludzi na rynku pracy
a także bliskość w razie konieczności podróżowania do głównych krajów europejskich.
Praca w takich strukturach spowodowała, że ludzie coraz częściej komunikują się za pomocą różnych
narzędzi do pracy na odległość (telekonferencja, email, różnego rodzaju komunikatory oraz różnego
rodzaju wirtualne spotkania). Kontakt bezpośredni jest zminimalizowany do absolutnego minimum albo
w ogóle nie następuje.
W powyższych warunkach toczy się wiele projektów, szczególnie w obszarze IT i ma to zarówno
swoje wady i zalety.
Niektórzy autorzy twierdzą, że zespoły wirtualne są kolejnym logicznym krokiem w ewolucji struktur
organizacyjnych. Nie można, bowiem rozwiązywać problemów dwudziestego pierwszego wieku, takich
jak globalizacja czy digitalizacja, stosując dziewiętnastowieczne metody organizatorskie15.
Przeciwieństwem zespołów rozproszonych są zespoły skupione zwane potocznie zespołami tradycyj-
nymi. Zespoły te, to grupa ludzi pracująca razem w jednej lokalizacji w tych samych przedziałach cza-
sowych. Zarówno jak zespoły wirtualne mają one swoje pozytywne, jak i negatywne cechy.

15
http://www.tstefaniuk.uph.edu.pl/zeszyty/archiwalne/84-2010_11.pdf

str. 32
Podstawy zarządzania projektami

Spróbujmy się przyjrzeć wadom i zaletom poszczególnych zespołów i jak to wszystko wpływa na
prowadzenie projektu w dzisiejszej organizacji:
Oszczędność kosztów – to jedna z najbardziej oczywistych zalet zespołów rozproszonych. Przede
wszystkim pozostawiając komunikację tylko na poziomie wirtualnym nie musimy ponosić kosztów za
kolokowanie członków zespołu projektowego. Pozwala to zaoszczędzić zarówno, jeśli chodzi o podróże,
aby wszyscy mogli pracować w jednej lokalizacji, jak i fakt, że nie musimy zapewniać specjalnej prze-
strzeni biurowej mającej na celu zebranie wszystkich w jednym miejscu. Ma to także ogromne odzwier-
ciedlenie w tym, że możemy także korzystać z „tańszych” zasobów, mając dostęp do oddziałów firmy
w krajach, gdzie powstają centra świadczenia usług. Jest oczywistym faktem, że nasz projekt poniesie
mniejszy koszt za specjalistę IT pochodzącego z Polski lub Indii, niż za takiego samego specjalistę po-
chodzącego z Zachodniej Europy.
Dostępność zasobów – decydując się na pracę w zespole rozproszonym, jeśli pozwala na to struk-
tura firmy, mamy możliwość doboru członków zespołu projektowego z różnych miejsc na świecie. Prze-
kłada się to oczywiście pozytywnie na dostępność do większej ilości wykwalifikowanego personelu i nie
ogranicza nas tylko do danego kraju czy danej lokalizacji.
Oszczędność czasu – kolejną bardzo pozytywną cechą jest oszczędność czasu, (która może się
przekładać zarówno w sposób bezpośredni jak i pośredni na oszczędność kosztów w projekcie). Akcep-
tując w pełni zespoły wirtualne nie tracimy czasu na podróże, które w szczególności przy większych
dystansach mogą konsumować dużą ilość czasu zasobu projektowego, która może być oddana, jako
efektywna praca. Nawet jeśli mówimy o zespołach projektowych w tej samej lokalizacji, firmy coraz
częściej decydują się na telepracę (praca z domu – homeoffice). Wybranie tego wariantu pozwala ogra-
niczyć czas dojazdu do pracy, co niejednokrotnie w dzisiejszych realiach może być nawet liczone w go-
dzinach w przełożeniu dziennym. Oczywiście naturalną konsekwencją będzie także mniejsza utylizacja
biura, co przełoży się na niższe koszty.
Model pracy 24/7 (over the sun) – w większych projektach na szczeblu globalnym posiadanie
rozproszonych zespołów w różnych lokalizacjach na świecie i w różnych strefach czasowych pozwala
nam teoretycznie na pracę 24 godzinny na dobę, jako że jeden zespół może zakończyć pracę i przekazać
zespołowi następnemu, który dopiero tą pracę zaczyna w swojej strefie czasowej. Teoretycznie brzmi
to tak jakbyśmy mogli, mając odpowiednie zaplecze finansowe zrealizować nasz projekt 3 razy szybciej.
W praktyce wygląda to trochę inaczej i nigdy nie będziemy w stanie osiągnąć takiej wydajności, jako,
że zawsze pozostaną jakieś zależności pomiędzy zmianami i ograniczenia zasobów projektowych, któ-
rych nie da się w prosty sposób przenieść jeden do jednego. Musimy także pamiętać, że niezbędna tu
będzie wyjątkowo poprawna komunikacja i koordynacja pomiędzy zmianami, dzięki której możemy od-
czuć pozytywne skutki takiej struktury w projekcie.
Różnice kulturowe i lokalne nawyki pracy - pracując w zespołach rozproszonych w strukturach
globalnych jest to coś, czego nie unikniemy. Różnice kulturowe oraz lokalne nawyki pracy w poszcze-
gólnych krajach (także różne wytyczne prawa pracy w danym kraju) jest czymś, na co na pewno, jako
kierownik projektu musimy zwrócić uwagę w naszym projekcie. Jest niezbędnym, aby na wstępie prze-
analizować charakterystykę, z jaką możemy się spotkać w danej części globu, aby dopasować komuni-
kację i styl zarządzania. Jako kierownik projektu napotkamy różne bariery, które mogą spowodować, że
przez różnice kulturowe i „lokalne zasady” będziemy mieli w projekcie dodatkowe problemy, które nie
wystąpiłyby, jeśli mielibyśmy zespół tradycyjny.

str. 33
Podstawy zarządzania projektami

Warto tutaj także podkreślić różnice językowe. Oczywiście w dzisiejszym świecie zdecydowana więk-
szość, jeśli nie wszyscy, członkowie naszego zespołu projektowego powinni mówić płynnie po angielsku.
W praktyce, jeśli weźmiemy pod uwagę to, że komunikacja odbywa się przez telefon a każdy kraj mimo
używania języka angielskiego, jako języka uniwersalnego, ma swój akcent czy specyficzny sposób mó-
wienia. Może to w znaczący sposób utrudnić komunikację dopóki ludzie nie „nauczą” się ze sobą roz-
mawiać.
Brak fizycznego kontaktu i komunikacja – biorąc pod uwagę wszystkie zalety zespołów rozpro-
szonych zawsze w projekcie wcześniej czy później padnie stwierdzanie „szybciej się dogadamy twarzą
w twarz – (face to face). W pewnych przypadkach nie da się uniknąć posadzenia zespołu w jednym
pokoju, aby wypracowali wspólne porozumienie, zbudowali plan projektowy, albo wypracowali propo-
zycję dla klienta ze względu na zmieniające się wymagania projektowe. Spotkanie takie najczęściej
przybierają formę warsztatów, które będzie bardzo trudno przeprowadzić przez telefon czy nawet wideo
konferencję z wykorzystaniem najnowszych technologii.

To jedna z przyczyn gdzie bezpośredni kontakt może okazać się niezbędny i pełna efektywność nie
zostanie osiągnięta pozostając w strefie wirtualnej:
 „pilnowanie” lub nadzorowanie przez kierownika projektu czy poszczególni członkowie zespołu
wykonują pracę związaną z projektem. Zaletą przebywania w tym samym pomieszczeniu jest pew-
ność, że widzimy, co ludzie robią i nad czym pracują. Mając wszystkich na odległość nie jesteśmy
w stanie do końca sprawdzić, co mogło być przyczyną nie wykonania jakiegoś zadania (tak na-
prawdę może ktoś zamiast pracować oglądał w tym czasie telewizor lub czytał książkę – brzmi
nieprofesjonalnie, ale tak naprawdę nigdy nie mamy 100% pewności, co ktoś może robić w danym
momencie.
 relacje – pracując w środowisku wirtualnym w dużym stopniu zaniknie element relacji budowanych
pomiędzy członkami poszczególnych zespołów. Nie będzie tutaj możliwości krótkiej rozmowy pod-
czas kawy, wspólnego lunchu czy jakiejkolwiek innej formy „small talk”, którą można zaobserwo-
wać, kiedy ludzie przybywają w jednej lokalizacji. Oczywiście członkowie zespołu mogą do siebie
zadzwonić i porozmawiać, ale na pewno nie zastąpi to rozmów przy tak zwanej maszynie do kawy
i codziennej integracji i cementowania więzi pomiędzy zespołem projektowym.
 relacje poza zespołem projektowym. Jest to także niezwykle ważny element. Relacje z klientem
czy innymi interesariuszami jest nieodzownym czynnikiem sukcesu projektu. Klient płacąc za pro-
jekt niejednokrotnie będzie oczekiwał (a nawet wymagał), że kluczowi członkowie zespołu projek-
towego, będą siedzieć i pracować w lokalizacji klienta. Brak takiej możliwości, może być jedną
z największych wad posiadania zespołu rozproszonego przy założeniu, że realizujemy projekt dla
klienta zewnętrznego. W takim przypadku jest niezmiernie ważne, aby na bieżąco pokazywać
klientowi, że rozumiemy jego potrzeby i jako projekt jesteśmy tam dla niego – komunikacja przez
telefon może w znaczny sposób ograniczyć tą możliwość. Podobnie rzecz ma się z dostawcami.

Różnice lokalizacji i czasu – różnica lokalizacji i czasu może być zarówno plusem, jak i minusem.
Pozytywne skutki zostały już opisane powyżej. Natomiast trzeba mieć także świadomość, że posiadanie
zespołu rozproszonego w różnych strefach czasowych i lokalizacjach może się odbić negatywnie na
projekcie, jeśli nie zaadresujemy poniższych punktów:

str. 34
Podstawy zarządzania projektami

 Komunikacja, komunikacja i jeszcze raz komunikacja. Jako kierownik projektu musimy być niezmier-
nie precyzyjni i konsekwentni, jeśli chodzi o komunikację. Kluczem do sukcesu jest fakt, że wszyscy
członkowie zespołu bez względu na lokalizację i strefę czasową mają taki sam poziom informacji na
temat statusu projektu, stopnia wykonania planu jak i ryzyk projektowych. Jest to nasze zadanie,
jako kierownika projektu i powinniśmy poświecić mu maksimum uwagi, każdego dnia.
 Podwójne raportowanie – szczególnie ważne, jeśli struktura naszego projektu jest bardziej roz-
budowana i mamy w różnych lokalizacjach koordynatorów projektów, nadzorujących mniejsze
podprojekty lub pakiety prac. Musimy być pewni, że jako główny kierownik projektu jesteśmy
w stanie zagregować dane i uniknąć, że poszczególne osoby widzą projekt inaczej i raportują
w inny sposób.

Inne standardy w zależności od lokalizacji – mając zespół projektowy w różnych częściach


globu nie unikniemy porównań między członkami zespołu projektowego, jakie standardy pracy posiadają
członkowie zespołu projektowego w różnych lokalizacjach. Może to oczywiście wpłynąć negatywnie na
motywację a przez co wydajność. Podstawowe czynniki na jakie musimy zwrócić uwagę to:
 Różny poziom wynagrodzenia w zależności od kraju. Zawsze może pojawić się pytanie: „czemu
zarabiam 3 x mniej wykonując ta samą pracę w globalnej organizacji”.
 Różny poziom czynników pozapłacowych zapewnianych pracownikom w ramach lokalnego oddziału
firmy. Tutaj też niejednokrotnie dojdzie do porównań, czemu firma w oddziale np. w Anglii zapewnia
wszystkim pracownikom najnowszy model Iphona, jako telefon służbowy a oddział np. w Malezji nie
zapewnia w ogóle telefonu komórkowego (nie mówiąc już o Iphonie). Takie same porównanie może
tyczyć się innych narzędzi pracy, ale także szkoleń, pracowniczych eventów, itp.
 Sposób motywowania i traktowania pracownika – na pewno będzie różny w zależności od loka-
lizacji (ma to też przełożenie na kulturę w danym kraju). Dla przykładu członek zespołu projek-
towego w Europie Zachodniej będzie miał prawdopodobnie o wiele większą swobodę działania
w organizacji niż jego kolega z Indii.

Jako kierownik projektu musimy być pewni, że w zespole projektowym będziemy starali się jak naj-
bardziej wyrównywać te różnicę. Nie oznacza to, że zapewnimy np. członkom zespołu projektowego
samochód służbowy marki BMW tak jak mają go koledzy w Niemczech, ale powinniśmy pracować także
z lokalnym kierownictwem, aby motywować pracowników w tym samym kierunku i wyrównywać ich
szanse na rozwój, jaki może im przynieść uczestnictwo w naszym projekcie.
Jak widać z powyższych opisów nie ma jednoznacznego stwierdzenia, który rodzaj zespołu jest lepszy
do wykonania projektu. Badania wskazują, że coraz więcej projektów, prowadzonych w środowisku
wirtualnym odnosi sukcesy. Natomiast w praktyce kluczem do sukcesu będzie utrzymanie racjonalnego
balansu, wynikającego z potrzeb projektowych i połączenie pozytywnych cech zarówno zespołów roz-
proszonych jak i skupionych, aby otrzymać optimum wydajności w projekcie i wykonać go z zadanym
czasie i budżecie.
Dodatkowo w pozycji literatury (pozycja 5  Zakrzewski G., Wpływ różnych czynników na wydajność
projektowych zespołów wirtualnych) znajdą Państwo dokładny opis czynników wpływających na zespół
wirtualny.

str. 35
Podstawy zarządzania projektami

8. CYKL ŻYCIA ZESPOŁU PROJEKTOWEGO ORAZ ZWIĄZANE Z TYM STYLE ZARZĄDZANIA


ORAZ ROLA LIDERA W PROJEKCIE/ORGANIZACJI

Według dr. Kena Blancharda istnieją cztery etapy w cyklu życia zespołu projektowego:
1. Rozpoznanie
2. Niezadowolenie
3. Integracja
4. Produkcja
Na każdym etapie cyklu życia zespołu ma on inne potrzeby, a co za tym idzie należy zastosować inny
styl zarządzania zespołem, aby umożliwić zespołowi przejście do kolejnej fazy. W pierwszej kolejności
scharakteryzujemy zespoły na poszczególnych etapach oraz określimy, jakie są potrzeby zespołu na tym
etapie.

Pierwszym etapem pracy zespołowej jest etap rozponania (forming). Na tym etapie nie są jasne
role członków zespołu oraz cel, w jaki zespół został utworzony. Członkowie zespołu często się nie znają,
a więc starają się zachować dystans, są niepewni, niechętnie wyrażają swoją opinię.
Zespół podczas etapu rozpoznania można opisać poprzez następujące cechy:
 Umiarkowany zapał;
 Wysokie, często nierealne oczekiwania;
 Obawy związane z rolami, akceptacją, zaufaniem do innych, oczekiwaniami w stosunku do nich;
 Niepewne, uprzejme, spolegliwe zachowanie;
 Brak jasności, co do celu nadrzędnego, norm, ról, zadań, struktury (jak będzie wyglądała
wspólna praca);
 Oczekiwnie instrukcji i wsparcia ze strony zwierzchników;
 Testowanie granic.

Potrzeby zespołu w etapie rozpoznania można opisać następująco:


 Wspólne zrozumienie celu nadrzędnego zespołu;
 Zgoda, co do wartości i norm współpracy;
 Zgoda, co do ról, poszczególnych celów i standardów;
 Zgoda, co do władzy związanej z podejmowaniem decyzji i odpowiedzialności;
 Zgoda, co do struktury i granic – w jaki sposób praca zostanie wykonana i przez kogo, wyznacz-
niki czasu, zadania i wymagane umiejętności;
 Informacja o dostępnych środkach;
 Poznanie się wszystkich członków, by wykorzystać różnorodne talenty i zbudować osobiste więzi.

str. 36
Podstawy zarządzania projektami

Kolejnym etapem pracy zespołowej jest etap niezadowolenia (storming). Członkowie zespołu po-
znali już cele oraz role, wielu z nich jest niezadowolona, ponieważ rzeczywistość odbiega od ich oczeki-
wań. Zespół zaczyna ze sobą współpracować i zaczynają się pojawiać pierwsze konflikty.
Zespół podczas etapu niezadowolenia można opisać poprzez następujące cechy:
 Rozbieżność pomiędzy oczekiwaniami a rzeczywistością;
 Niepewność, co do ról i celów;
 Niezadowolenie z zależności od władzy zwierzchniej;
 Wyrażanie niezadowolenia;
 Tworzenie się koalicji;
 Uczucie niekompetencji, dezorientacji, niskiej pewności siebie;
 Niewielkie zaufanie;
 Realizacja niektórych zadań.

Potrzeby zespołu w etapie niezadowolenia można opisać następująco:


 Jasność, co do ogólnych założeń;
 Ponowne określenie celu nadrzędnego, ról, poszczególnych celów i struktury;
 Ponowne opowiedzenie się za wartościami i normami;
 Rozwijanie procesów komunikacji obejmujących aktywne słuchanie, wymianę nieosądzających
informacji zwrotnych, radzenie sobie z konfliktami i rozwiązywanie problemów;
 Dostrzeżenie wartości różnic zdań;
 Dostęp do informacji i środków;
 Zachęta i wsparcie;
 Uznanie dotychczasowych dokonań;
 Otwarta i uczciwa dyskusja dotycząca kwestii emocjonalnych bloków, koalicji i konfliktów osobowości;
 Wspólne uznanie obowiązków i odpowiedzialność za nie.

Kolejnym etapem pracy zespołowej, jest faza integracji (norming). Członkowie zespołu zaczynają
się docierać. Poznali się na tyle, że potrafią konstruktywnie pracować. Zaczynają czuć się zespołem.
Zespół podczas etapu integracji można opisać poprzez następujące cechy:
 Wzrost zrozumienia i zaangażowania w role, cele, zadania i strukturę;
 Większe zaangażowanie w przestrzeganie norm i wartości;
 Lepsza realizacja zadań – od umiarkowanej do wysokiej;
 Wzrastające zaufanie, spójność, harmonia i wzajemny szacunek;
 Chętne dzielenie się odpowiedzialnością, przywództwem i kontrolą;
 Rozumienie i docenianie różnicy zdań;
 Używanie języka zespołu - „my” zamiast „ja”;
 Tendencja do unikania konfliktów.

str. 37
Podstawy zarządzania projektami

Potrzeby zespołu w etapie integracji można opisać następująco:


 Integracja zespołowych i indywidualnych ról i celów, norm i struktury;
 Dalsze doskonalenie umiejętności;
 Zachęta do dzielenia się różnymi punktami widzenia i konstruktywnego podważanie opinii
 Dalsze budowanie zaufania i pozytywnych relacji;
 Współdzielona odpowiedzialność za przywództwo i funkcjonowanie zespołu;
 Skupienie na wzroście produktywności;
 Ocena i wyciąganie nauki z każdego doświadczenia;
 Dostrzeganie i celebrowanie sukcesów.

Ostatnim etapem pracy zespołowej, jest etap produkcji (performing). Członowie zespołu zaczęli
sobie ufać i wiedzą, w jaki sposób pracować wydajnie.
Zespół podczas etapu produkcji można opisać poprzez następujące cechy:
 Jasność, co do celu nadrzędnego, wartości, ról i poszczególnych celów;
 Umożliwiające decyzyjność procedury postępowania, które wyzwalają energię zespołu i prowa-
dzą do stałego doskonalenia się;
 Relacje i komunikacja oparte na zaufaniu, wzajemnym szacunku i otwartości;
 Elastyczność i współdzielone przywództwo, co pozwala zespołowi odpowiadać na nowe wyzwania;
 Optymalna produktywność i wysokie standardy;
 Dostrzeganie i docenianie osiągnięć indywidualnych i zespołowych;
 Wysokie morale.

Potrzeby zespołu w etapie produkcji można opisać następująco:


 Dalsze skupianie się na produktywności;
 Nowe wyzwania;
 Dostrzeganie i świętowanie osiągnięć zespołu;
 Uznawanie osiągnięć jednostek;
 Autonomia w podejmowaniu decyzji w wyznaczonych granicach.

W innych źródłach możemy znaleźć informację również o piątym etapie cyklu życia zespołu projek-
towego, którym jest faza odroczenia (adjouring). Jest to etap, w którym zespół kończy pracę oraz
opuszcza projekt.

str. 38
Podstawy zarządzania projektami

Morale oraz produktywność zespołu w różnych etapach cyklu życia zespołu opisuje poniższy rysunek
(rys 14.)

Rys 14. Etapy rozwoju zespołu (EZP). Źródło: K. Blanchard. Jednominutowy manager buduje wydajne zespoły.

Przez długi czas sądzono, że są tylko dwa sposoby zarządzania zespołem ludzkim: autokratyczny
i demokratyczny. W przypadku przywództwa autokratycznego nacisk kładziono na instruowanie ludzi,
co mają zrobić, jak to mają zrobić, gdzie to zrobić. Kwestią nadrzędną była wydajność zespołu. Jeśli chodzi
o przywództwo demokratyczne, nacisk kładziono na słuchanie podwładnych, chwalenie ich wysiłków i
ułatwianie interakcji między nimi. Morale zespołu zostało uznane za najlepszy sposób zmaksymalizowania
wydajności zespołu. Wystąpiły jednak dwa problemy związane z obu przeciwstawnymi stylami przywódz-
twa – podejśćie do tematów na zasadzie „albo/albo”, czyli stosowano albo przywództwo autokratyczne
albo demokratyczne. Gdyby przywódca był zbytnio autokratyczny, z czasem zespół zacząłby narzekać, że
jest on zbyt rygorystyczny, kontrolujący i tłumi kreatywność. Czując się źle, w takiej sytuacji przywódca
zmieniłby swój styl zarządzania w drugą skrajność, a więc w styl demokratyczny. Jednak również ten styl
można nadużyć i spowodować, że wszyscy czują się komfortowo w zespole, ale nikt nic nie robi.
Dlatego zasadne jest stosowanie przywództwa sytuacyjnego, w którym w zależności od etapu, na
jakim znajduje się zespół przywódca modyfikuje swoje zachowania w obszarze zachowań wspierających
(zachowań demokratycznych) oraz w obszarze instruowania (zachowań autokratycznych).

Przywództwo sytuacyjne zakłada istnienie czterech stylów przywództwa (Rys 15):


 Pierwszy styl przywództwa (S1 – Strukturyzacja), czyli kierowanie. Ten styl przywództwa
cechuje się niewielkimi zachowaniami wspierającymi ze strony lidera, za to z dużą liczbą dawanych
instrukcji. Ten styl przywództwa stosujemy do zespołu, który jest w fazie rozpoznania. Ne etapie
rozpoznania członkowie zespołu wnoszą w spotkania entuzjazm i zaangażowanie, ale niewiele wie-
dzy, tak, więc potrzebują instruowania.

str. 39
Podstawy zarządzania projektami

 Drugi styl przywództwa (S2 - Analiza i rozwiązywanie), coaching. Ten styl przywództwa
charakteryzuje się duża ilością zachowań zarówno instruujących, jak i wspierających. Styl stoso-
wany na etapie niezadowolenia. Na tym etapie członkowie zespołu nie są ani wysoce kompetentni,
ani mocno zaangażowani.
 Trzeci styl przywództwa (S3 - Współpraca), czyli wspieranie. Ten styl przywództwa cha-
rakteryzuje się dużą ilością zachowań wspierających oraz mała ilością zachowań instruujących. Ten
styl przywództwa stosuje się do zespołów będących w fazie integracji. Na tym etapie członkowie
zespołu mają już umiejętności niezbędne do dobrej pracy, ale nadal potrzebują podbudowania
pewności siebie i morale, tak, więc potrzeba im wsparcia i zachęty,
 Czwarty styl przywództwa (S4 - Zatwierdzanie), czyli delegowanie. Styl ten charakteryzuje
się małą ilością zachowań instruujących i małą ilością zachowań wspierających. Styl ten stosujemy
w stosunku do zespołów będących w fazie Produkcji. Zespół na tym etapie posiada wysokie umie-
jętności i morale, tak, więc lider może się usunąć na bok lub przyłączyć się i pozwolić sobie na pracę
przy zachowaniu minimum ingerencji.

Rys 15. Style przywództwa

Istotne jest, aby dodać w tym miejscu, że zespół osiągnowszy kolejną fazę w cyklu życia, może się
cofnąć do poprzedniej fazy. Dobry manager nieustannie analizuje zachowanie zespołu i kiedy dostrzeże,
że zespół cofnął się do poprzenej fazy (lub na sam początek cyklu) dostosuje swój styl przywództwa,
aby w sposób efektywny zarządzać zespołem na obecnym projekcie i doprowadzić do jego ewolucji do
kolejnego etapu.

str. 40

You might also like