Professional Documents
Culture Documents
Podstawy Zarządzania Projektami
Podstawy Zarządzania Projektami
SPIS TREŚCI
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
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
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
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.
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
Program
Inne powiązane
Projekt Projekt
zadania
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
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
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
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
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
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.
str. 10
Podstawy zarządzania projektami
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
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.
5
http://goprojekt.pl/baza_wiedzy/strona/metodyki_w_zarzadzaniu/
str. 12
Podstawy zarządzania projektami
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
str. 13
Podstawy zarządzania projektami
str. 14
Podstawy zarządzania projektami
str. 15
Podstawy zarządzania projektami
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
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.
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
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
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
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.
12
Zarządzanie projektami – sztuka przetrwania
str. 22
Podstawy zarządzania projektami
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.
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).
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
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).
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
Kierownik
Kto zarządza
Kierownik Kierownik funkcjonalny Kierownik Kierownik
budżetem
funkcjonalny funkcjonalny i/lub Kierownik Projektu Projektu
projektu
projektu
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
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.
str. 30
Podstawy zarządzania projektami
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.
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.
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
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.
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ń.
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
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.
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).
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.
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