Zarządzanie Projektami – Jak zorganizować projekt

część 1

Jerzy Szych
shake@shake.com.pl

W poprzednich odcinkach cyklu
o zarządzaniu projektami (ang. Project Management) omówiono podstawowe pojęcia
tej dziedziny: projekt, zarządzanie projektem, wymiary projektu, interesariusze,
role uczestników projektu oraz właściwe przygotowanie biznesowe projektu.

W niniejszej części znajdą się wskazówki co do
zalecanych zasad organizowania projektu. Niedostateczna uwaga zwrócona na tę
kwestię może spowodować poważne utrudnienia w realizacji lub nawet porażkę
projektu.

***

W pierwszych częściach cyklu artykułów o Zarządzaniu
Projektami zaprezentowane zostały następujące zagadnienia:

  • Wymiary każdego projektu: Produkt, Czas, Budżet i
    Jakość – najważniejsze kryteria definiowania projektu, sposób jego
    oceniania i korygowania;
  • Metodyki Zarządzania Projektami,
    w szczególności PRINCE 2 (obowiązkowa metodyka rządu brytyjskiego);
  • Pierwsza faza przedsięwzięcia – uzasadnienie
    biznesowe i zdefiniowanie projektu (Dokument Inicjacji Projektu, ang. PID –
    Project Initiation Document).

Pora teraz na przygotowanie organizacji projektu, a więc
zespołu ludzi, którzy mają doprowadzić go do sukcesu.

Organizacja a definicja projektu

Wiele definicji projektu podkreśla,
że realizacja projektu, a więc przedsięwzięcia, wymaga utworzenia pewnej tymczasowej
struktury
osobowej i jej uporządkowanie w strukturę organizacyjną
projektu. Przykładowo, jedna z cenionych metodyk zarządzania projektami PRINCE
2 podaje dwa określenia, co to jest projekt:

  1. „środowisko zarządzania utworzone dla dostarczenia
    jednego lub kilku produktów biznesowych zgodnie ze zdefiniowanym Przypadkiem
    Biznesowym”;
  2. „tymczasowa organizacja mająca na celu
    wyprodukowanie unikatowego
    i zdefiniowanego wyniku, w określonym czasie i przy wykorzystaniu
    zdefiniowanych zasobów”.

W obu tych określeniach zwraca uwagę nacisk na tymczasowość
struktury organizacyjnej. Chodzi o to, że za projekt uznaje się przedsięwzięcie
o pewnym stopniu nietypowości, unikatowości (upraszczając: „robimy coś
po raz pierwszy”). Do nietypowego zadania najlepsza jest nietypowa
organizacja ludzi, stworzona specjalnie pod kątem najlepszego wypełnienia tego
właśnie zadania.

Organizacja projektowa firmy

Tradycyjna organizacja firm ma postać hierarchii, w której
kolejne szczeble pracowników podporządkowane są pracownikowi szczebla wyższego,
tworząc powszechnie znaną „piramidę” struktury organizacyjnej.

Nowemu pracownikowi przydziela się stanowisko leżące w
odpowiednim miejscu hierarchii i wyznacza się zakres jego obowiązków,
wskazuje przełożonego itp. Ścieżka kariery jest prosta: zmiana stanowiska
następuje przez awans (rzadko: degradację). Pracownik funkcjonuje w
zdefiniowanych względnie trwale mechanizmach (np. raportowania), wykonuje mniej
więcej podobne prace itp.

W ostatnich latach wielką karierę zrobiła jednak
projektowa organizacja firmy, w której kluczowe znaczenie ma pojęcie ROLI (będzie
wyjaśnione dalej).

Zakłada się, że każdy pracownik nie otrzymuje stanowiska,
lecz na pewien czas otrzymuje jakąś rolę, gdyż jest czasowo przydzielony do
określonego projektu. Nie piastuje się więc stanowiska programisty,
kierownika, dyrektora, sekretarki czy portiera, ale pełni się pewną rolę w
projekcie przez jakiś czas, po czym w następnym projekcie można otrzymać rolę
zupełnie inną. A przede wszystkim – można znaleźć się w całkowicie
nowym zespole, różniącym się trochę lub całkowicie od poprzedniego, gdyż
takie było chwilowe zapotrzebowanie firmy. Oczywiście, role przydziela się
zgodnie z posiadanymi umiejętnościami i możliwościami. Jeśli więc
pracownik jest ściśle wyspecjalizowany i umie wykonywać jedynie prace pewnego
rodzaju (dotyczy to wielu specjalistów technicznych, np. programistów stosujących
określone narzędzia), jest duża szansa, że w kolejnych projektach będzie pełnił
taką samą rolę (np. programisty).

Organizacja projektowa sprzyja jednak szybkim awansom. Po
nabyciu pewnego doświadczenia w projektach, specjalista techniczny może łatwo
awansować do roli kierownika zespołu technicznego (np. szef programistów
odpowiedzialny za pewien fragment tworzonego systemu), potem – objąć rolę
szefa większego zespołu,
w następnym projekcie może mu przypaść w udziale praca przy testowaniu lub
szkoleniu użytkowników (np. szef testerów czy kierownik testów użytkowych).
Droga kariery jest szybka, ale miewa też powroty: z szefa zespołu można
ponownie wrócić do roli programisty, jeśli taka jest potrzeba chwili. W większości
przypadków szef zespołu zajmuje się nie tylko kierowaniem swoimi ludźmi, ale
równocześnie pełni rolę techniczną, np. wiodącego programisty dla tematu
przydzielonego jego zespołowi.

Jak widzimy, możliwe jest równoczesne pełnienie różnych
ról w projekcie. Można też w jednym okresie być przydzielonym do różnych
przedsięwzięć i pełnić w nich różne role (np. szefa testów w jednym, zaś
programisty – w drugim). Wówczas mamy do czynienia z pewną formą
organizacji macierzowej, jednak podporządkowanej projektowej organizacji firmy.

W literaturze podkreśla się, iż dla skutecznego
funkcjonowania struktury projektowej w firmie niezbędne jest spełnienie dwóch
warunków:

  • bardzo dalekie odejście od tradycyjnych struktur
    hierarchicznych – można to zrobić nawet w tradycyjnych pionach, np. w
    księgowości, gdzie jednego pracownika można przydzielić do kilku projektów
    (może w nich pełnić taką samą rolę, ale jego zadania są przydzielone
    tylko na czas trwania projektu),
  • wprowadzenie rzetelnych zasad wewnętrznych rozliczeń
    finansowych między jednostkami organizacyjnymi firmy – każdy pracownik
    przydzielony do projektu oraz każde działanie realizowane na rzecz projektu
    kosztują określone pieniądze, nawet jeśli oznacza to tylko zapisy księgowe.

Projektowa struktura organizacyjna jest częściej spotykana
w firmach niewielkich i średnich, szczególnie jeśli podstawą ich działania
są wysoko kwalifikowani specjaliści, zaś większość prac jest realizowana
dla klientów zewnętrznych. Kilka lat temu wyłom
w tej zasadzie zrobiła znana wszystkim Nokia, która stworzyła strukturę
projektową w całej organizacji. Obecnie struktury projektowe są często
spotykane również w wielkich korporacjach, szczególnie w branżach IT,
telekomunikacji, budownictwa, energetyki, przemysłu metalowego (montaże
konstrukcji). Reorganizacja projektowa Nokii uznawana jest za jeden z ważnych
powodów osiągania przez nią bardzo dobrych wyników, nawet jeśli ostatnio
nie są już one tak olśniewające jak dawniej.

Problemy wynikające
z organizacji projektowej

Trzeba też wspomnieć o trzech bardzo istotnych problemach
organizacji projektowej: kwalifikacjach ludzi, ich wykorzystywaniu i określaniu
odpowiedzialności
.

  • Przy projektowym kształtowaniu zespołów trzeba
    zatrudniać bardzo wszechstronnych, elastycznych ludzi, umiejących pracować w
    różnych zespołach, rolach, sytuacjach. Jest to problem olbrzymi, wymagający
    wielkich zmian
    w mentalności i sporych nakładów na przygotowanie pracowników. Każdy zespół
    musi „się zrosnąć”, dopasować i nauczyć optymalnej współpracy,
    a to kosztuje.
  • Pracownik zwalniany z zakończonego projektu musi być
    jak najszybciej przydzielony do kolejnego projektu. Inaczej staje się
    nadmiernym kosztem. Wiele prac mogą wykonywać ludzie na umowach (tzw.
    kontraktorzy, ang. freelancers), kontraktowani dopiero po uruchomieniu projektu.
    Istnieje jednak niebezpieczeństwo, iż konkretna, sprawdzona osoba może nie
    czekać na kolejną naszą propozycję i stanie się niedostępna. Wiele firm
    nie idzie na takie ryzyko – i słusznie. Ale bardzo często zatrudnia się
    też pracowników „na wszelki wypadek”, a to generuje koszty. Trzeba
    więc zachować zdrowy balans między kontraktorami a pracownikami etatowymi.

Warto pamiętać:

W Polsce Kontraktor czyli pracownik na umowę jest obecnie
mniej więcej o połowę tańszy od pracownika etatowego. Po uwzględnieniu
kosztów przygotowania pracownika etatowego i jego niepełnego wykorzystania, ta
różnica staje się
o wiele większa.

  • Kierownik Projektu prawie automatycznie naraża się
    na konflikty z szefami organizacyjnymi „kupowanego” pracownika. Z
    powodu jakby „podwójnej podległości” pojawić się może
    „podwójna lojalność” pracownika. Wyjściem jest jedynie bardzo
    precyzyjne określanie zakresów uprawnień i odpowiedzialności Kierownika
    Projektu w organizacji, ustalenie bardzo silnej jego pozycji wobec innych
    kierowników.

Organizacja i budżet projektu

Jak wiemy, projekt ma 3 parametry (wymiary): zadania
(produkty), budżet i czas. Bez konsekwentnych zasad wewnętrznego rozliczania
się wszystkich komórek firmy między sobą, nie da się skonstruować prawidłowego
budżetu projektu. Bardzo często występuje też zjawisko niedostatecznej jakości
pracy w jednym projekcie na rzecz zwiększonego wysiłku w innym – zgodnie
z priorytetami bezpośredniego szefa. Jest to dość często szkodliwe dla całej
firmy. Niestety, brak dobrze zdefiniowanego kosztorysu (a więc: uwzględniającego
wszystkie koszty wewnętrzne) osłabia również kompetencje szefa projektu:
pozbawia go narzędzi kierowania zespołem (motywowania ludzi, szukania
specjalistów na zewnątrz firmy, zastępowania pracowników znakomitych lecz
drogich specjalistami wystarczającymi a tańszymi itp.).

Planując projekt Kierownik Projektu musi m.in. opracować
budżet. Główne kategorie kosztów to: zakupy materialne (np. narzędzia czy
produkty), infrastruktura (np. pomieszczenia biurowe, narzędzia komunikacji)
i oczywiście – ludzie. Problem ten ma wielkie znaczenie w Polsce, gdzie
nadal jest rozumiany niewłaściwie.
W wielu organizacjach uznaje się, że zasoby posiadane przez firmę, a więc również
ludzie, są „za darmo” i nie trzeba planować kosztów ich zakupu.
Oczywiście jest to błąd, którego naprawa jest automatyczna w organizacji
projektowej: tworząc strukturę organizacyjną swojego projektu Kierownik
Projektu zwraca się do różnych jednostek organizacyjnych po zasoby –
„kupuje” je i musi na to mieć budżet. Można specjalistę
„kupić” wraz z jego wyposażeniem (biurko, komputer, telefon), można
„kupić” tylko część jego czasu, można świadomie poczekać na
konkretną osobę – aktualnie zajętą, np. jeśli jest ona tańsza. Można
też zrezygnować z niektórych umiejętności ludzi własnej firmy
i kupić je na zewnątrz, jeśli przemawia za tym koszt lub dostępność. Jest
to ważny krok ku zastanawianiu się, co właściwie powinna robić firma (np.
czy powinna mieć rozmaite służby pomocnicze), czy zatrudnia odpowiednich
ludzi (jeśli nie są oni „kupowani” do projektów), czy wszyscy
muszą mieć komórki i biurka (można ich trzymać w domu z dobrą linią do
Internetu – odpada wiele problemów z kontrolą pracy) itp.

Role

Ludzie są przydzielani („kupowani”, obsadzani)
do projektu w ściśle określonych rolach. Jest to pojęcie zupełnie różne
od tradycyjnego „stanowiska”. Określenie roli członka zespołu
projektowego wymaga ustalenia:

  • nazwy roli (np. szef zespołu testerów, kontroler
    finansowy projektu, programista GUI);
  • określenia zadania, czyli jak najbardziej
    precyzyjnego opisania, co pracownik
    w danej roli ma robić – najlepiej „zrobić”. Nie chodzi o
    igraszkę słowną, lecz o zadaniowy sposób powierzania pracy ludziom.
    Najlepiej przydzielając rolę określić, co ma być jej końcowym produktem,
    odbieranym przez Kierownika Projektu po wykonaniu pracy;
  • określenie zakresu uprawnień i odpowiedzialności
    oraz zasad podejmowania decyzji (kto o czym decyduje,
    o czym – sam pracownik, o czym – jego szef).

Różnica między „stanowiskiem”
a „rolą”:
stanowisko się piastuje, zaś rolę –
pełni (okresowo).

W ten sposób powstaje STRUKTURA ORGANIZACYJNA.

Kardynalnym acz powszechnym błędem jest tworzenie struktury
organizacyjnej przez rysowanie „piramidy” podległości stanowisk.
Tymczasem określenie struktury organizacyjnej polega przede wszystkim na wyróżnieniu
i sprecyzowaniu ról, a więc: zadań, uprawnień i odpowiedzialności oraz
kompetencji decyzyjnej. Chodzi więc nie o określenie, kto kim rządzi, lecz
co, z kim i jak kto robi. Różnica jest fundamentalna, filozoficzna
i praktyczna, podobnie jak między rolą a stanowiskiem. Rola sprzyja budowaniu
współpracy, a to ma wielkie znaczenie w projektach. Łatwo to zrozumieć pamiętając,
że celem tworzenia struktury organizacyjnej jest:

  • rozdział pracy pomiędzy wszystkich uczestników –
    członków zespołu projektowego i otoczenia projektu dla zapewnienia sprawnej
    realizacji celów
    i zadań;
  • ustalenie zasad współpracy, komunikacji,
    rozstrzygania konfliktów i podejmowania decyzji.

Decyzje co do struktury organizacyjnej muszą wynikać z
potrzeb projektu (jak wyżej), przydatności ludzi do pełnienia ról (umiejętności,
wydajność, możliwości współpracy w konkretnej grupie ludzi – np.
znajomość języka) i wymagań praktycznych (np. w większości przypadków
szef zespołu nie powinien mieć więcej niż 5 osób bezpośrednio podległych
– ang. direct reports).

Dla ukazania, iż problem ma charakter ogólny, warto wskazać
przykład medyczny. W szpitalu lekarz jest członkiem typowej hierarchii
organizacyjnej: ordynatorem, kierownikiem kliniki czy przychodni lub też jednym
z wielu lekarzy na oddziale. Jednak gdy wchodzi na salę operacyjną, przekształca
się w kierownika projektu
o nazwie „Operacja pacjenta X”, ustalającego reguły działania,
organizującego pracę innych, powierzającego zadania członkom zespołu i
kontrolującego ich wykonanie. Wyjątkowo ważne jest to, że lekarz prowadzący
operację jest całkowicie odpowiedzialny za wynik pracy zespołu, za każdy
jego aspekt i za wszystkich ludzi (pielęgniarkę, anestezjologa, asystenta
itd.). Warto ten przykład przypominać sobie zastanawiając się, jaki zakres
odpowiedzialności spoczywa na kierowniku projektu
– każdego
projektu. Jedyna poprawna odpowiedź to: całkowita odpowiedzialność.

Tworząc strukturę organizacyjną
w najmniej rozwiniętej postaci tworzy się zatem tabelę o następującej
„główce”:

Rola Zadania Odpowiedzialność Uprawnienia Raportowanie Osoba

Każda tabela ma jednak również
„boczek”, ale do niego dojdziemy
za chwilę.

Projekt i otoczenie

Każdy projekt odbywa się w pewnym środowisku, tzw.
otoczeniu. Zalicza się do niego zarówno elementy biznesowe (np. szefowie
biznesowi Kierownika Projektu, użytkownicy wytworzonych produktów, bank
kredytujący projekt), jak i zewnętrzne (np. mieszkańcy miasta, w którym
realizowany jest projekt). Wszystkich zainteresowanych przebiegiem projektu w
jakikolwiek sposób określa się mianem Interesariuszy (ang.
Stakeholders). Każda ich grupa ma inny punkt widzenia na projekt, np. przyszli
użytkownicy systemu informatycznego cieszą się, że ułatwi im on pracę, zaś
Zarząd firmy martwi się,
że system tak dużo kosztuje.

Jak wyjaśnialiśmy w poprzedniej części cyklu, projekt
jest odpowiedzią na potrzeby, które zgłaszają przedstawiciele biznesu. W
taki sam sposób określa się również zleceniodawców projektu w
organizacjach niekomercyjnych, np. w administracji publicznej. Potrzebę taką
zgłosić może wiele osób, ale ostatecznie formułuje ją osoba na wysokim
szczeblu decyzyjnym w organizacji, oczywiście z powodu pieniędzy. Przecież każdy
projekt kosztuje, więc ktoś musi płacić rachunek, a więc musi mieć na to
budżet. Taka osoba w projekcie przyjmuje rolę Sponsora, a więc zarówno
opiekuna projektu, jak i jego prawodawcy (rozstrzyganie konfliktów i inne
decyzje kluczowe), a w szczególności – kasjera, który wypłaca pieniądze
(budżet projektu) i pilnie baczy, czy mu się to opłaca (korzyści biznesowe).

Projekt tworzy produkty, które trafią do rąk użytkowników,
zaś przyniosą korzyści beneficjentom. W obu przypadkach mogą to być
te same osoby, ale niekoniecznie. Na przykład użytkownikiem systemu na poczcie
jest „panienka z okienka”, zaś beneficjentem – klient, który
krócej stoi w kolejce. Obie te grupy powinny mieć swoich przedstawicieli w
strukturach projektu (np. metodyka PRINCE 2 mówi, że jest to obowiązkowe).

Są też interesariusze „polityczni”, np. władza
zainteresowana zadowalaniem swoich obywateli, są „kibice” (np. sąsiedzi
nowej placówki pocztowej – zainteresowani w braku tłoku przed
budynkiem), jest opinia publiczna (wszędobylskie media). No i oczywiście
bardzo często jest bank – „dobry wujaszek” zainteresowany częściową
porażką projektu („żeby kosztował jak najwięcej”), ale i pragnący
sukcesu (żeby było z czego spłacać). Te grupy interesariuszy mają niekiedy
duży wpływ na realizację projektu, ale prawie nigdy nie mają swoich
reprezentantów w strukturach projektu.

No i oczywiście w projekcie uczestniczą Wykonawcy
– reprezentowani przez Kierownika Projektu członkowie zespołów
projektowych. Oni pełnią najwięcej ról w strukturze organizacyjnej.

Metodyki zarządzania projektami zwykle podpowiadają
i definiują typowe role, jakie muszą występować w każdym projekcie oraz
inne, które są zalecane w projektach o odpowiedniej wielkości, złożoności
(np. struktur wykonawczych) i długości trwania.

Bardzo pomocne w zrozumieniu różnic między kluczowymi
rolami w projekcie jest spojrzenie na typowe pytania istotne dla nich (oczywiście
są to przykłady, a nie pełna lista):

  • Szef biznesowy – zwykle Sponsor – optyka
    efektywności gospodarczej:
    – Czy projekt jest nadal opłacalny (saldo nakładów
    i zysków);
    – Czy jego realizacja nie przekracza zaplanowanego
    budżetu i czasu;
    – Czy trzeba już zatrzymać projekt z powodu
    zmian
    w otoczeniu (np. nowa strategia firmy, spadek cen na rynku).
  • Kierownik projektu – optyka sprawności działania:
    – Czy projekt jest dobrze zaplanowany i
    zorganizowany, czy plan wymaga zmian;
    – Czy realizacja utrzymuje się w oczekiwanych
    parametrach;
    – Czy członkowie zespołu mają właściwe
    zadania, czy są dobrze rozliczani;
    – Czy tworzone produkty są zgodne z wymaganiami i
    kryteriami jakości.
  • Użytkownicy – optyka użyteczności produktów:
    – Czy produkty przydadzą się w naszej pracy;
    – Czy spełniają kryteria akceptacji;
    – Czy dostajemy wystarczające szkolenia o
    produktach;
    – Czy stosowanie produktów jest zgodne z
    procedurami pracy.
  • Wykonawcy – optyka realizacji/ wytwarzania
    produktów:
    – Czy wiem dokładnie co mam zrobić (jakość
    wymagań dla produktu), w jakiej jakości (testy), na kiedy;
    – Czy potrzebuję współpracy (np. użytkownika)
    lub pomocy (np. od Kierownika Projektu);
    – Czy spodziewam się bliskich problemów (np. z
    kooperantami).

Zalecane role w projekcie

Najpoważniejsze metodyki zarządzania projektami uznają za
obowiązkowe określenie pewnych ról w każdym projekcie. Są to:

  • Sponsor Projektu,
  • Komitet Sterujący,
  • Kierownik Projektu,
  • Zespoły techniczne,
  • Komitet Kontroli Zmian.

W większych projektach zalecane jest również uwzględnienie
dalszych ról:

  • Kierownik Projektu ze strony klienta (gdy realizuje
    projekt zewnętrzny wykonawca);
  • Kierownicy zespołów technicznych (przy większych
    zespołach wykonawczych);
  • Komitet Akceptacyjny i zespoły do spraw testów
    akceptacyjnych (przy bardziej złożonych i trudniejszych w testowaniu oraz przy
    zróżnicowanych produktach);
  • Szef Jakości (szczególnie w projektach dla
    administracji publicznej);
  • Sekretariat Projektu lub Biuro Projektu.

W projektach mniejszych, nie wymagających licznej obsady
kadrowej, dąży się do upraszczania struktury organizacyjnej, a więc
stworzenia jedynie ról obowiązkowych.


Jerzy Szych (shake@shake.com.pl)
Prowadził kilkadziesiąt projektów informatycznych. Spędził 10 lat
w dużych korporacjach informatycznych w Polsce i za granicą. Obecnie jako
samodzielny konsultant prowadzi projekty i wykłada Zarządzanie Projektami. Członek
Polskiego Towarzystwa Informatycznego
i Stowarzyszenia Project Management Polska. Certyfikowany Project Manager.