Organizacja projektu w metodyce zarządzania projektami Prince 2

Zarzadzanie projektami

Propozycja zamieszczenia dodatkowej informacji:
Dobra wiadomość dla Szefów Projektów: istnieje już pierwsze w Polsce
Stowarzyszenie Project Management Polska z siedzibą w Gdańsku. Zapraszamy wszystkich
zainteresowanych na stronę www.spmp.org.pl.

W pierwszej części cyklu artykułów o Zarządzaniu Projektami (ang.
Project Management) 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 – definicja projektu zebrana w Dokumencie Inicjacji
    Projektu (ang. PID – Project Initiation Document)

Teraz kolej przychodzi na przedstawienie drugiego elementu metodyki
PRINCE 2 – organizacji projektu.

Definicja projektu w metodyce PRINCE 2

Przedsięwzięcia podejmowane przez zespoły ludzi w dowolnej
dziedzinie mogą przyjmować rozmaite struktury i kierować się różnymi regułami.
Specyficzną ich klasą, zalecaną do przedsięwzięc gospodarczych ze względu na dużą
skuteczność, jest działanie zespołów w formule PROJEKTÓW. Metodyka PRINCE 2
definiuje projekt następująco:

Jest to sposób prowadzenia przedsięwzięć gospodarczych zmierzający
do wytworzenia produktu uzasadnionego biznesowo, w ramach określonego czasu, budżetu, z
odpowiednią strukturą organizacyjną, rolami i zakresami odpowiedzialności.

Znajdujemy tu wymienione uprzednio trzy główne wymiary projektu,
uzupełnione o wskazanie konieczności uzasadnienia biznesowego dla każdego podejmowanego
przedsięwzięcia, jak też z podkreśleniem konieczności wprowadzenia odpowiedniej organizacji
zespołu projektowego
.

Organizacja projektowa firmy

Organizacja działań zespołów ludzi powstaje przez wyróżnienie w
grupie ról i związanych z tym zakresów odpowiedzialności, jak też wskazanie zasad
podejmowania decyzji, a więc ustalenie struktury organizacyjnej.

Typowym błędem jest zrozumienie stworzenia struktury organizacyjnej
jako narysowanie "piramidy" podległości stanowisk, typowej dla odwiecznego
prezentowania struktur organizacyjnych. Tymczasem faktyczny projekt struktury
organizacyjnej polega przede wszystkim na wyróżnieniu i sprecyzowaniu ról. Staje się
to jasne po uzgodnieniu, że celem tworzenia struktury organizacyjnej jest:

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

Tym właśnie celom podporządkować trzeba wszystkie decyzje
organizacyjne, niezależnie od wszelkich innych istniejących struktur. Uwaga ta ma
niezmiernie ważne znaczenie dla wszystkich instytucji i jednostek gospodarczych
funkcjonujących w tradycyjnym stylu, a więc opartych na hierarchicznej strukturze
organizacyjnej – nadal dotyczy to większości istniejących podmiotów gospodarczych.
Wprowadzenie pracownika do organizacji polega na przydzieleniu mu stanowiska znajdującego
się w odpowiednim miejscu hierarchii, a także wyznaczenie zakresu obowiązków, zasad
podległości i raportowania, ścieżki kariery itp. Pracownik zajmuje stanowisko do czasu
awansu (zwykle w górę hierarchii) lub degradacji, wypełnia z grubsza ustalone zadania,
podlega ustalonym mechanizmom itp. Tymczasem koncepcja projektowej organizacji instytucji
zakłada, że pracownik nieustannie obejmuje nowe role, zależnie od czasowego przydziału
do określonych projektów. W koncepcji tej nie obejmuje się więc stanowiska
programisty, kierownika, dyrektora, sekretarki czy portiera, lecz czasowo pełni się
określoną funkcję zgodnie z potrzebami danego projektu. Podkreślanie czasowego
przydziału ról ne jest przypadkowe: przecież jedną z głównych cech projektu jest
jego ograniczenie w czasie, ścisłe ustalenie daty rozpoczęcia i zakończenia projektu.
Oznacza to również, iż dany pracownik w jednym projekcie może pełnić rolę
specjalisty technicznego (np. projektanta), w innym – kierownika zespołu technicznego
(np. szefa programistów), w kolejnym staje się asystentem szefa projektu, zaś w jeszcze
innym – szefem projektu czy szefem jakości. Co więcej: możliwe jest równoczesne
pełnienie różnych ról w różnych projektach, o ile nie jest niezbędne poświęcenie
całego czasu pracy na jedno z tych przedsięwzięć.

Teoretycy nowoczesnej organizacji podkreślają, iż dla
bezkonfliktowego i skutecznego wprowadzenia struktury projektowej konieczne jest
zaistnienie dwóch warunków:

  • maksymalnie odhierarchizowana struktura całej firmy czy instytucji – tradycyjne
    hierarchie zwykle ograniczone są do pomocniczych służb technicznych (np. księgowość)
    i rutynowych form działalności (np. biuro obsługi klientów)
  • konsekwentne i pełne wprowadzenie zasad wewnętrznych rozliczeń finansowych między
    jednostkami organizacyjnymi

Pierwszy z tych warunków spełniany jest dziś przez niewiele firm.
Najczęściej dotrzymują go organizacje niewielkie i średnie, szczególnie
zatrudniające głównie wysoko kwalifikowanych specjalistów. Wymienianym wielokrotnie
przykładem wielkiej korporacji o strukturze całkowicie projektowej jest firma Nokia.
Wprowadzenie takich zasad funkcjonowania było jednym z głównych haseł reorganizacji
podjętej kilka lat temu przez nowego CEO, wymieniane jest też wśród najważniejszych
powodów osiągania znakomitych wyników przez tę firmę.

Zasadom wewnętrznej organizacji finansowej poświęcić trzeba
odrębne omówienie. Jako minimum trzeba jednak wspomnieć, iż brak tych reguł oznacza
de facto pozbawienie projektów jednego z trzech podstawowych wymiarów: budżetu, odgrywa
też niezmierną rolę w pozbawieniu szefa projektu odpowiednich narzedzi do kierowania
zespołem (motywowania ludzi, zakupu specjalistów na rynku, substytucji zasobów itp.)

Interesujące przykłady organizacji projektowej spotkać można w
niektórych powszechnie znanych nam wszystkim instytucjach publicznych. W szpitalach
lekarz w zasadzie jest członkiem typowej hierarchii: ordynatorem, kierownikiem kliniki
czy przychodni. Jednakże po wejściu na salę operacyjną staje się szefem projektu,
ustalającym wszystkie reguły, wprowadzającym organizację, powierzającym określone
zadania wszystkim członkom zespołu i kontrolującym ich realizację, całkowicie
odpowiadającym za wynik pracy swojej grupy.

Organizacja projektowa w działalności gospodarczej ma dziś
niezmiernie szerokie zastosowanie, należy więc mieć nadzieję, iż wkrótce upowszechni
się również w Polsce.

Perspektywy widzenia projektu

Dla uporządkowania i ułatwienia skutecznej organizacji zespołów
metodyki Zarządzania Projektami wyróżniają i definiują typowe role, jakie muszą
występować w każdym projekcie, jak też jakie zalecane są do zespołów zależnie od
wielkości i skali czasowej przedsięwzięcia.

Uznając istnienie kilku odmiennych optyk widzenia projektu (szefów
biznesowych, wykonawców, użytkowników, klientów i dostawców) PRINCE 2 formułuje
konieczność tworzenia ról z uwzględnieniem tych właśnie perspektyw. Dla
uzmysłowienia potrzeby definiowania ról z uznaniem różnych perspektyw wystarczy
wspomnieć typowe pytania zadawane przez różnych ludzi patrzących na projekt:

  • Szef biznesu – optyka efektywności gospodarczej
    • Czy projekt jest opłacalny
    • Czy jego realizacja nie przekracza zaplanowanego budżetu i czasu
    • Czy uzyskiwane wyniki nadal zapewniają opłacalność ekonomiczną przedsięwzięcia
    • Czy nie zaistniała potrzeba zatrzymania projektu z uwagi na zmiany w środowisku
      gospodarczym (np. powstanie konkurencji na danym rynku, zmiany strategii organizacji)
  • Szef projektu – optyka sprawności działania:
    • Czy projekt jest dobrze zaplanowany i zorganizowany
    • Czy realizacja utrzymuje się w zadanych parametrach
    • Czy członkowie zespołu są właściwie obciążani zadaniami i rozliczani z nich
    • Czy tworzone produkty są zgodne z wymaganiami i kryteriami jakości
  • Użytkownicy – optyka użyteczności produktów:
    • Czy produkty są przydatne do naszej pracy
    • Czy spełnione są kryteria akceptacji
    • Czy produkty techniczne są dostatecznie uzupełnione przekazywaną wiedzą i
      umiejętnościami
    • Czy korzystanie z produktów jest zgodne z procedurami pracy

Role w projekcie

W metodyce PRINCE 2 obowiązkowe, a więc niezbędne w każdym
projekcie są następujące role:

  • Sponsor Projektu
  • Komitet Sterujący
  • Szef Projektu
  • Zespoły techniczne
  • Komitet Kontroli Zmian

Zależnie od skali i potrzeb danego projektu PRINCE 2 zaleca
rozważenie potrzeby określania dalszych ról:

  • Szef Projektu ze strony klienta
  • Szefowie zespołów technicznych
  • Komitet Akceptacyjny i zespoły do spraw testów akceptacyjnych
  • Szef Jakości
  • Sekretariat Projektu

W projektach mniejszych, nie wymagających licznej obsady kadrowej,
należy dążyć do maksymalnego uproszczenia struktury organizacyjnej, a więc stworzenia
ról obowiązkowych. Zasady sensownej organizacji w projektach większych wskazują z
kolei potrzebę wyróżniania ról dodatkowych.

Zakresy odpowiedzialności uczestników projektu

Sponsor projektu – decyzje strategiczne

Sponsor projektu jest jego "właścicielem". On właśnie
określa potrzebę biznesową leżącą u podstaw rozpoczęcia przedsięwzięcia, on jest
fundatorem – osobą finansującą prace, on też jest najważniejszym beneficjentem
uzyskanych korzyści. Sponsorem powinna być osoba stojąca wysoko w hierarchii
organizacyjnej klienta projektu, zwykle jest to członek Zarządu lub jego bezpośredni
przedstawiciel. Wyznaczanie Sponsora projektu zbyt wysoko (np. CEO czy prezesa) nie jest
wskazane, gdyż z uwagi na liczne zwykle obowiązki nie będzie on w stanie poświęcić
dostatecznej ilości czasu na zagadnienia projektu. Jednakże zbyt niska pozycja sponsora
w organizacji jest również szkodliwa: w razie potrzeby decyzji czy wprowadzenia zmian we
własnej firmie nie będzie on miał dostatecznych uprawnień, a więc nie wspomoże
projektu należycie.

Wbrew powszechnej w Polsce praktyce podkreślić trzeba, iż SPONSOR
PROJEKTU NIE MOŻE BYĆ SPECJALISTĄ TECHNICZNYM, lecz przedstawicielem biznesu. Typowe
powierzanie roli sponsora głównemu informatykowi jest oczywistym błędem w zdecydowanej
większości projektów. Nie są one przecież realizowane dla informatyków, lecz dla
użytkowników biznesowych: księgowych, operatorów, referentów, kasjerów itp.
Informatyk nie jest władny wprowadzić niezbędnych zmian organizacyjnych (np. nowych
procedur pracy czy regulaminów), nie ma też podstaw do uznania, czy koszty projektu
będą dostatecznie uzasadnione osiąganymi korzyściami biznesowymi. Informatycy, nie
dajcie się wrabiać szefom w role wam nienależne.

Na początku projektu do Sponsora należą następujące zadania:

  • Sformułowanie zadań przedsięwzięcia i uzasadnienia biznesowego
  • Wyznaczenie budżetu projektu
  • Ogólne ustalenie głównych produktów
  • Mianowanie Przewodniczącego Komitetu Sterującego, zatwierdzenie pozostałych
    członków Komitetu

W trakcie realizacji projektu Sponsor ma trzy zadania:

  • Odebranie produktów projektu, ocenienie uzyskanych korzyści
  • Decydowanie w kluczowych momentach projektu, np. zatrzymanie prac w razie zmian
    technologicznych czy ponoszenia nadmiernych kosztów, przydzielenie dodatkowych zasobów
    finansowych itp.
  • Zajmowanie pozycji mediatora we wszystkich ważnych konfliktach, niemożliwych do
    rozstrzygnięcia na niższych szczeblach struktury projektu

Komitet Sterujący (Rada Projektu) – decyzje taktyczne

O ile nie zachodzi ważna potrzeba (kluczowe decyzje, mediacja w
sporach), Sponsor uczestniczy w projekcie właściwie w dwóch momentach: na początku i
na końcu. W pozostałym czasie najwyższą władzą w projekcie jest Komitet Sterujący.

Przewodniczącym Komitetu powinien być koniecznie przedstawiciel
biznesu (organizacji klienta lub wręcz użytkowników). Mianowany jest on przez Sponsora
na samym początku, po czym sam proponuje pozostałych członków Komitetu.

Komitet zbiera się w kluczowych dla projektu momentach: na początku,
na końcu i zwyykle w tzw. punktach krytycznych (ang. milestones) – najczęściej
związanych z odbiorami znaczących faz projektu. W projektach dłuższych zalecane jest
odbywanie spotkań okresowych, np. miesięcznych, jednak możliwe jest też
"obradowanie wirtualne": przekazanie miesięcznego raportu o stanie projektu do
wszystkich członków Komitetu i odbycie fizycznego spotkania jedynie w sytuacji budzącej
zaniepokojenie któregoś z nich.

PRINCE 2 wprowadza koncepcję tzw. Etapów Zarządczych (zostaną
wyjaśnione w kolejnych artykułach) i podkreśla konieczność odbywania spotkań
Komitetu na zakończenie każdego z nich. Podejmowane wówczas decyzje dotyczą
zatwierdzenia (przyjęcia) zakończonego właśnie etapu i decyzję co do kontynuacji
pracy w kolejnym etapie (a więc zatwierdzenie planów i przyznanie środków).

W Komitecie Sterującym winni być reprezentowani wszyscy istotni
uczestnicy: sponsor, użytkownicy i dostawcy. Każdy z nich winien wyznaczyć przynajmniej
jedną osobę do reprezentowania swoich interesów.

Należy podkreślić, iż Komitet podejmuje decyzje nie poprzez
demokratyczne głosowanie, lecz na zasadzie consensu. Podyktowane jest to
koniecznością równoprawnego uwzględniania interesów wszystkich reprezentowanych
stron.

Do zadań Komitetu należą:

  • mianowanie Szefów Projektu,
  • okresowa i etapowa ocena stanu projektu i zatwierdzanie planów dalszych prac (w tym:
    przyznawanie środków i zasobów osobowych i rzeczowych),
  • rozstrzyganie sporów w razie niemożności uzgodnienia decyzji na szczeblu Szefów
    Projektu
  • zatwierdzanie Wniosków o Zmianę
  • akceptacja produktów projektu

Szef Projektu – decyzje taktyczne i operacyjne

Szef Projektu (ang. Project Manager) jest kluczową rolą w całym
przedsięwzięciu. W nowszych ujęciach Szefów powinno zawsze być dwóch: ze strony
dostawcy i klienta. Wspólnie tworzą oni Zarząd Projektu, a więc operacyjne ciało
kierujące pracą wszystkich zespołów technicznych.

W praktyce przedsięwzięć inicjatywa i odpowiedzialność za przebieg
projektu spoczywają zwykle na dostawcy, jego więc przedstawiciel odpowiada za pomyślny
przebieg pracy. Jednakże w wielu projektach spotyka się obecnie powierzanie tej roli
przedstawicielowi klienta, co jest dopuszczalne pod warunkiem uzyskania przez niego
odpowiedniej dyspozycji nad wszystkimi zasobami (a więc również pracownikami dostawcy
oddelegowanymi do projektu).

Praktyka większości Szefów Projektu pokazuje, iż wprawdzie są oni
na ogół najwyższą władzą operacyjną w projekcie. Niestety pełnią także rolę
"chłopca do bicia": odpowiadają za wszystkie zdarzenia – pomyślne i
niepomyślne, muszą naprawiać błędy popełnione przez siebie i przez wszystkich innych
członków zespołów, muszą też koordynować pracę poddostawców i podwykonawców.

Według British Standard BS 4335:1987

Szefem Projektu jest osoba, której przekazano UPRAWNIENIA I
ODPOWIEDZIALNOŚĆ w celu ogólnego zarządzania zasobami projektu (w aspektach
technicznych i kosztowych) oraz motywowania wszystkich zainteresowanych.

Rola Szefa Projektu zasługuje na odrębne omówienie w osobnym
artykule. Należy więc jedynie tutaj wskazać główne obszary jego pracy i
odpowiedzialności:

  • planowanie i organizacja projektu, aktualizacja planów w trakcie projektu
  • uzgodnienie założeń projektu, wymagań użytkowników, kryteriów akceptacji
  • operacyjne zarządzanie, podejmowanie wszelkich niezbędnych działań korekcyjnych
  • dostarczanie produktów do testów i akceptacji
  • raportowanie stanu i postępu projektu (produkt, czas, budżet, jakość)
  • kierowanie zespołami (wyznaczanie prac, obsada stanowisk kierowniczych, rozliczanie
    rezultatów, motywowanie)
  • zarządzanie zmianami
  • zarządzanie jakością i ryzykiem
  • wyłączne reprezentowanie projektu na zewnątrz (m.in. wobec klienta i poddostawców)

Na kategoryczne podkreślenie zasługuje stwierdzenie:

NAJWAŻNIEJSZE ZADANIE SZEFA PROJEKTU: OSIĄGNIĘCIE CELÓW PROJEKTU.

Wszystkie inne cele i zadania są jedynie drogą do celu. Pamiętajmy
więc, iż dobry Szef Projektu to osoba skuteczna, rozliczana przede wszystkim z
osiągniętych wyników. I nie szukajmy wytłumaczeń w razie porażki: za wszystko, co
się zdarza w projekcie odpowiada Szef, za odniesione sukcesy i porażki w
szczególności.

Komitet Kontroli Zmian – zarządzanie zmianami

Komitet Kontroli Zmian jest kolejnym ciałem niezbędnym w każdym
projekcie. Zarządzanie Zmianami zostanie omówione w odrębnym artykule, jednakże
ogólnie należy wskazać, iż od jakości pracy tego Komitetu zależy w ogromnej mierze
powodzenie projektu w fazie jego realizacji.

Podstawą prac i rozliczania postępu jest tzw. Linia Główna
projektu
, którą stanowią: plan i wszystkie zatwierdzone później zmiany.

Na początku jest to pierwszy plan zatwierdzony przez Komitet
Sterujący
do realizacji. W trakcie dalszych etapów prac opracowywane są kolejne
plany szczegółowe, również podlegające zatwierdzaniu przez Komitet. PRINCE 2 nakazuje
czynić to w czasie obowiązowych przeglądów zatwierdzania etapów zarządczych.

Jednakże w trakcie realizacji w projekcie wynika konieczność
wprowadzania mniej lub bardziej istotnych zmian do planów. Odbywa się to poprzez
procedurę Kontroli Zmian: Wnioski o Zmianę składane przez Szefów Projektu zawierają
propozycje modyfikacji planów produktowych, czasowych, rzeczowych i finansowych. Decyzje
odnośnie tych Wniosków wymagają natychmiastowej aktualizacji planów przez Szefa
Projektu. W ten sposób Linią Główną jest zawsze ostatni zatwierdzony plan. Marzeniem
każdego Szefa Projektu jest, aby zmiany nie były "bombą z opóźnionym
zapłonem" podkładanym przez Komitet do jego projektu. Nadmiar zmian lub
nierealistyczne żądania rzadko kiedy przyczyniają się do sukcesu projektu.

Komitet Kontroli Zmian również MUSI składać się z przedstawicieli
obu stron: dostawcy i klienta, gdyż jest ciałem mediacyjnym. Często (choć
niekoniecznie) w Komitecie uczestniczą obaj Szefowie Projektu, zwykle wspomagani przez
najważniejszych specjalistów technicznych (np. projektanta systemu, architekta sieci,
szefa testów itp.). Również ten Komitet podejmuje decyzje na zasadzie consensu, a nie
głosowania większością. Tylko w ten sposób można uszanować usprawiedliwone interesy
obu stron przedsięwzięcia i uniknąć klęski (merytorycznej lub biznesowej)
którejkolwiek z nich. Naruszanie zasady równości stron nigdy nie kończy się sukcesem
projektu lub kolejnych wspólnych przedsięwzięć. Tę fundamentalną zasadę
Zarządzania Projektami warto przypominać w Polsce nieustannie, gdyż obecnie sytuacja
pozostawia wiele do życzenia.

Komitet spotyka się zawsze wtedy, gdy należy rozpatrzyć złożone
Wnioski o Zmianę. W razie niemożliwości uzyskania wspólnego stanowiska przez obie
strony (np. rozbieżne oceny wpływu zmiany na projekt) Wniosek jest przedkładany do
decyzji Komitetu Sterującego.

Komitet Kontroli Zmian podlega nominacji i ocenie Komitetu
Sterującego.

Szef Jakości- zarządzanie jakością

Podobnie jak Komitet Kontroli Zmian również Szef Jakości jest
mianowany przez Komitet Sterujący i jemu też podlega. Jednakże jego praca nie ma
absolutnie charakteru "sędziego – kontrolera" Szefa Projektu. W poprawnie
zdefiniowanych projektach obaj Szefowie ściśle współpracują ze sobą, wspólnie
przyczyniając się do sukcesu przedsięwzięcia. Zdrowym układem jest mianowanie Szefem
Jakości bardzo doświadczonego szefa projektów, gdyż w razie potrzeby może on
służyć swemu koledze radą i zdrowym krytycyzmem w stosunku do wszystkich spraw
występujących w projekcie.

Kompetencji Szefa Jakości podlegają wszystkie zagadnienia związane z
projektem: plany i wszelka dokumentacja zarządcza, tworzone produkty i ich testy,
jakość pracy zespołów technicznych i kontakty z poddostawcami, gospodarka finansowa i
zarządzanie ryzykiem. Ogólnie mówiąc Szef Jakości powinien uczestniczyć we
wszystkich pracach wszystkich zespołów, zarządczych i technicznych, od opiniowania
budżetu i proponowanych planów, aż do sprawdzania przecinków w dokumentacji.

Mimo tak szerokiego zakreślenia roli Szefa Jakości nie jest to zwykle
praca "na pełny etat" w danym projekcie. Nawiązując do poprzednich
wyjaśnień o zmienności ról warto wspomnieć, iż bardzo często Szefem Jakości w
jednym projekcie jest osoba pełniąca rolę Szefa Projektu w innym przedsięwzięciu,
zwykle większym czy bardziej złożonym.

Komitet Akceptacyjny- odbiór produktów

Komitet Akceptacyjny również najczęściej jest ciałem mieszanym,
złożonym z przedstawicieli obu stron (dla skrócenia czasu na podjęcie decyzji),
jednakże niejednokrotnie spotyka się obsadzanie go jedynie przez przedstawicieli
klienta. Ciałem zwierzchnim jest Komitet Sterujący, zaś ciałem podległym – zespół
ds. testów akceptacyjnych.

Na podstawie wyników testów wykonanych przez odpowiednich
specjalistów technicznych Komitet podejmuje decyzję o rekomendowaniu przyjęcia lub
odrzucenia produktów (decyzję tę podejmuje Komitet Sterujący). Zasadność istnienia
Komitetu Akceptacyjnego wynika z faktu, iż bardzo rzadko produkty przechodzą testy
całkowicie bez zastrzeżeń. Zwykle wykrywa się w nich sporo usterek (błędy krytyczne
powodują kategoryczne odrzucanie produktu), dla których należy ustalić postępowanie
naprawcze, po czym wskazane jest przyjęcie produktów. Ocenę krytyczności błędów i
usterek musi wykonać właśnie Komitet, w oparciu o ocenę testerów i wyjaśnienia
wykonawców (reprezentowanych przez Szefa Projektu lub głównego specjalistę
technicznego).

Szefowie Zespołów, zespoły techniczne- wykonanie produktów

Zespoły techniczne organizuje Szef Projektu zależnie od charakteru
pracy i wykonywanych produktów. Od prawidłowego doboru ludzi – specjalistów
technicznych zależy oczywiście powodzenie przedsięwzięcia. Śmiało można więc
powiedzieć, iż mają oni "klucz do sukcesu".

Zalecane jest, aby zespoły nie były zbyt liczne (5-20 osób), często
też wskazane jest odrębne grupowanie specjalistów z różnych dziedzin (np. od sieci i
bazy danych). Specyficznym zespołem o bardzo dużym znaczeniu jest Zespół Testów,
wykonujący sprawdzenie poprawności wykonanych produktów przedstawianych do odbioru
przez Szefa Projektu.

Zespoły Techniczne winny być kierowane przez odpowiednich
specjalistów. Najczęściej są to doświadczeni fachowcy z danej dziedziny, posiadający
również umiejętności kierowania grupą ludzi. Ich umiejętności techniczne są
niezbędne nie tylko do właściwej obsady kadrowej poszczególnych zadań (odpowiednia
osoba do każdej pracy), ale również do wskazania ogólnego sposobu realizacji zadania,
oszacowania pracochłonności, ustalenia kryteriów pomiaru i testowania itp.

Szefowie Zespołów Technicznych są nie tylko reprezentantami licznych
nieraz wykonawców prac, lecz są również "gwardią przyboczną" Szefa
Projektu, jego najbliższymi współpracownikami. Pomagają mu w definiowaniu produktów,
planowaniu, ocenie Wniosków o Zmianę, czuwaniu nad realizacją zadań przez
pracowników, przygotowywaniu raportów. W większych projektach Szef Projektu ma
sporadyczny kontakt z większością specjalistów technicznych, znacznie więcej czasu
poświęcając zarządzaniu ogólnemu i kontaktom z klientem. Powierzanie pracy i
rozliczanie z uzyskanych wyników wykonują właśnie Szefowie Zespołów. Rozliczanie
Szefa Zespołu wykonuje bezpośrednio Szef Projektu.

Typową ścieżką rozwoju kariery jest pełnienie roli Szefa Zespołu
Technicznego w jednym z projektów, po czym objęcie roli Szefa Projektu w kolejnym
przedsięwzięciu.

Sekretariat Projektu – organizacja i dokumentacja

W większych projektach zalecane jest tworzenie wydzielonego
Sekretariatu (Biura Projektu), stanowiącego bardzo użyteczne narzędzie wspomagające
dla Szefa Projektu, który jest bezpośrednim zwierzchnikiem tego ciała. Do typowych
zadań Sekretariatu należą:

  • Prowadzenie całej biblioteki projektu, w tym: planów i raportów, Wniosków o Zmianę
    itp.
  • Zarządzanie korespondencją, dokumentacja spotkań
  • Zbieranie i konsolidowanie raportów z zespołów technicznych, przygotowanie
    materiałów do raportów Szefa Projektu
  • Sprawy osobowe (urlopy, rozliczenia finansowe, sprawy pracownicze itp.)
  • Rozliczenia finansowe z dostawcami zewnętrznymi i z klientem (nadzorowane przez Szefa
    Projektu)

W większych projektach w Sekretariacie sytuuje się Szefa Konfiguracji
(ang. Configuration Manager), Szefa Biblioteki Projektu (ang. Librarian), planistę (ang.
Planner). W mniejszych projektach wszystkie te funkcje spełnia osobiście Szef Projektu.

Użytkownicy – odbiorcy produktów

Jak wszyscy wiemy, projekty robi się dla użytkowników. Ta prosta
prawda jest niekiedy gubiona z pola widzenia Szefów pochłoniętych uporczywą walką z
przeciwnościami, dlatego też zasługuje na stałe przypominanie. Użytkownicy są
konsumentami wyników naszej pracy, są też ich recenzentami (niekiedy pozbawionymi
głosu). Zapewniam każdego Szefa Projektu, iż trudno o większą satysfakcję zawodową
niż pozytywne oceny użytkowników naszych produktów. Dla zobaczenia ich zadowolonych
min warto przykładać się do roboty i przechodzić trudne chwile.

Oczywiście użytkownicy mają nie tylko przywilej oceniania produktów
i korzystania z nich, mają też obowiązki:

  • określenie wymagań dla produktów
  • określenie kryteriów akceptacji i testów
  • zaplanowanie i wykonanie testów, spisanie uwag i usterek
  • nabycie odpowiedniej wiedzy i umiejętności do korzystania z produktów (w tym –
    odbycie szkoleń i zapoznannie się z dokumentacją)
  • często – przygotowanie sensownych danych testowych i napisanie dokumentacji
    użytkownika końcowego
  • opracowanie i wprowadzenie niezbędnych zmian w swojej organizacji (np. w procedurach
    pracy, dokumentach źródłowych)

Powyższa lista zobowiązań jest niestety równie często zaniedbywana
przez użytkowników, co niedoceniana przez ich szefów – ze Sponsorem na czele.

Projekty mogą się udawać jedynie przy pełnym współdziałaniu obu
stron, każda pracująca jak najlepiej we własnym zakresie obowiązków.

Czego sobie i Państwu życzę !!!

Jerzy Szych

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

Podsumowanie struktury organizacyjnej projektu

Ciało organizacyjne/ rola Zakres odpowiedzialności Uczestnicy
Sponsor Projektu Określenie celów i zadań projektu, uzasadnienia
biznesowego przedsięwzięcia, ogólnych parametrów (czas, budżet, metoda realizacji).
Mianowanie Przewodniczacego Komitetu Sterującego. Przyjmowanie produktów do
użytkowania. Zatwierdzanie istotnych zmian w projekcie. Mediacja w sporach nie
rozstrzygniętych przez Komitet Sterujący. Zapewnienie niezbędnych zmian w organizacji
klienta.
1 osoba z kierownictwa organizacji klienta (członek
Zarządu firmy)
Komitet Sterujący Kieruje całością projektu. Odpowiada za wszystkie wyniki
prac, zapewnienie środków i zasobów finansowych, ludzkich i rzeczowych. Zatwierdza
zmiany w projekcie. Przyjmuje wyniki projektu (produkty). Mianuje i rozlicza Szefa
Projektu, Komitet Kontroli Zmian, Szefa Jakości, Komitet Akceptacyjny.
3-7 osób

Reprezentant Sponsora –
przewodniczący Komitetu

Reprezentanci użytkowników

Reprezentanci Dostawców

Szef Projektu ze strony dostawcy Organizacja projektu i prac. Ustalanie standardów i zasad.
Prowadzenie i gromadzenie dokumentacji. Kontrola postępu i raportowanie. Organizacja prac
Komitetu Sterującego. Kontakty z poddostawcami. Zapewnienie zasobów dostawcy i warunków
pracy zespołów technicznych. Realizacja zatwierdzonych zmian. Eskalacja problemów.
Dostarczenie produktów do testów i odbioru. Mianowanie Szefów Zespołów i
Sekretariatu.
1 osoba
Szef Projektu ze strony klienta Współorganizacja projektu i prac – w większości zadań
Szefa Projektu ze strony dostawcy.

Prowadzenie i gromadzenie
dokumentacji. Zapewnienie warunków pracy zespołów technicznych i zasobów ze strony
klienta. Realizacja zatwierdzonych zmian. Eskalacja problemów.

1 osoba (często – główny informatyk)
Szef Jakości Ustalenie standardów jakości, kontrola ich przestrzegania. 1 osoba (ze strony dostawcy lub klienta – niekiedy
główny informatyk)
Sekretariat Projektu Obsługa zadań administracyjnych. Prowadzenie Biblioteki
Projektu. Gromadzenie dokumentacji do raportów. Aktualizacja planów. Zarządzanie
konfiguracją.
1-4 osoby (mianowane przez Szefów Projektu)
Szefowie zespołów technicznych (ze strony dostawcy) Bezpośrednie kierowanie przebiegiem prac w zakresie
poszczególnych systemów Raportowanie do Szefa Projektu. Pomoc w planowaniu projektu,
określaniu produktów, testach, akceptacji. Powierzanie zadań specjalistom, rozliczanie
z wyników.
1-n specjalistów technicznych (mianowani przez Szefa
Projektu)
Szefowie zespołów technicznych (ze strony klienta) Przekazanie wymagań i kryteriów akceptacji. Przygotowanie
i przeprowadzenie testów. Przekazanie informacji do Protokołów Akceptacji. Użytkowanie
przyjętych produktów.
1-2 osoby (mianowani przez Szefa Projektu ze strony klienta)
Komitet Kontroli Zmian Opracowanie procedury Kontroli Zmian. Realizacja procedury
– obsługa Wniosków o Zmianę. Kontrola realizacji przyjętych zmian.
2-4 osoby (z obu stron)
Komitet Akceptacyjny Przyjęcie kryteriów akceptacji. Analiza i decyzje
odnośnie protokołów testów. Rekomendacje przyjęcia produktów przez Komitet
Sterujący.
2-4 osoby (z obu stron lub ze strony klienta)