Zarządzanie Projektami – Porządek w papierach. Część 4.

Jerzy Szych szych_jerzy@poczta.gazeta.pl

 

W poprzednich odcinkach cyklu o zarządzaniu projektami omówiono podstawowe pojęcia zarządzania projektami, jak też fazy planowania i organizowania oraz realizacji przedsięwzięcia.

Niniejszy artykuł pozostaje w tematyce realizacji i opisuje zagadnienia administrowania projektem (techniki Dziennika Projektu, notatki ze spotkań), Biblioteki projektu (teczki techniczne i zarządcze), Podręcznika Projektu i Biura Projektu.

***

 


Rys. 1.
Cykl życia projektu.

 

Jak podaliśmy w poprzednim artykule, w fazie realizacji specjaliści techniczni wykonują i dostarczają uzgodnione produkty, zaś Kierownik Projektu czuwa nad realizacją całości, śledzi postęp, reaguje na sytuacje niepożądane i prowadzi projekt do pomyślnego zakończenia.

Główne zadania dokumentacji o charakterze administracyjno-zarządczym to:

  • rejestracja zachodzących zdarzeń dla potrzeb monitorowania i raportowania,
  • tworzenie niezbędnej dokumentacji kontraktowej.

REJESTROWANIE ZDARZEŃ

W ramach nadzoru nad realizacją projektu Kierownik Projektu musi znać jego historię, od samego początku (założenia, cele, plany) aż do chwili bieżącej. Jest to łatwiejsze, jeśli od początku projektem kieruje jedna osoba, jednak przy dłuższych lub bardziej rozbudowanych przedsięwzięciach łatwo się pogubić, zapomnieć o czymś istotnym itp. Jeszcze trudniej jest przy zmianach osoby pełniącej rolę Kierownika Projektu, a takie sytuacje występują w projektach często.

 


Rys. 2.
Zmiana Kierownika w trakcie projektu.

 

Od czego profesjonalny Kierownik obejmujący projekt w czasie jego trwania zaczyna swoje poznawanie przedsięwzięcia? Oczywiście od kontraktu podpisanego między Zlecającym (Klientem) a Wykonawcą (Dostawcą). W każdym projekcie powinien istnieć dokument odpowiadający kontraktowi, nawet w projektach wewnętrznych. Niekiedy nosi on nazwę Zlecenia Projektowego, kiedy indziej taką rolę pełni Dokument Inicjacji Projektu (PID – Project Initiation Document), choć często jest on zbyt mało szczegółowy. W każdym przypadku Kierownik Projektu musi go uważnie przestudiować, gdyż jest to najważniejszy opis zobowiązań podjętych przez zespół projektu.

W dokumencie takim nowy Kierownik Projektu powinien znaleźć odpowiedzi na pytania o główne parametry projektu: co? (dostarczane produkty), kiedy? (harmonogramy), za ile? (koszty). Metodyki zalecają także zaznajomienie się z zagadnieniami: po co? (korzyści biznesowe), jak? (organizacja, sposób realizacji).

Po rozpoznaniu tej charakterystyki projektu, Kierownik musi szczególnie uważnie pochylić się nad planami. Warto przypomnieć, iż sporządzone na początku plany nie muszą być w pełni aktualne w trakcie realizacji. W miarę rozwoju sytuacji w projekcie zachodzą zmiany (o zarządzaniu zmianami będzie mowa w odrębnym artykule), które natychmiast po zatwierdzeniu muszą być uwidocznione w planach. Zmodyfikowany plan tworzy tzw. Plan Bazowy (ang. Baseline) i do jego realizacji zobowiązany jest Kierownik.

Kierownik powinien wreszcie poznać najważniejsze zdarzenia, które dotychczas nastąpiły w czasie projektu. Szczególnie ważne są: stan produktów (np. odbiory częściowe, testy), stan finansów i wszelkie zdarzenia finansowe (faktury, transze kredytów), istotne kontakty z przedstawicielami Klienta, inne zobowiązania podjęte wobec najrozmaitszych stron (np. mieszkańców miasta, w którym realizowany jest projekt).

Jeśli dotychczasowy Kierownik prowadził Dziennik Projektu (patrz dalej), jest to nieocenione źródło wiedzy o przebiegu przedsięwzięcia i jego aktualnej sytuacji.

Na zakończenie procesu indukcji nowego Kierownika, koniecznie powinien on odbyć osobiste spotkania z najważniejszymi osobami w projekcie: kierownikami swoich zespołów technicznych i innymi osobami funkcyjnymi (np. Szef Jakości), reprezentantami podwykonawców oraz innych udziałowców projektu (np. banku, lokalnej władzy itp.), no i oczywiście powinien poznać najważniejszych przedstawicieli Klienta. Warto podkreślić znaczenie osobistych spotkań, gdyż nigdy nie wolno zapominać, iż:

 

Projekty robi się dla ludzi i z ludźmi.

 

Dziennik Projektu

Wyjątkowo użytecznym narzędziem pracy Kierownika jest Dziennik Projektu (ang. Project Register, Project Diary). Jest to dokument prowadzony przez Kierownika lub jego asystenta od pierwszego do ostatniego dnia projektu, w którym skrótowo rejestrowane są najważniejsze zdarzenia.

W dwóch dziedzinach prowadzenie Dziennika jest nakazane przez prawo: w budownictwie (Dziennik Budowy) i żeglarstwie (Dziennik Pokładowy). Odpowiednie przepisy szczegółowo definiują sposób prowadzenia tych dokumentów, określając kto i co musi rejestrować. Dziennik Projektu jest techniką wzorowaną na tych doświadczeniach. Nie jest wymagany przez żadne prawo ani metodykę zarządzania projektami, jednak jego przydatność potwierdza każdy praktyk zarządzania, który choć raz stosował go we własnym przedsięwzięciu.

Dziennik Projektu jest nieoceniony przy wszelkiego rodzaju retrospektywach, a więc raportach, odtwarzaniu historii zdarzeń, kontroli wykonania podjętych zobowiązań itp. Oczywiście większość potrzebnych faktów można znaleźć w odpowiednich dokumentach źródłowych (np. notatkach ze spotkań), jednak Dziennik pełni rolę przewodnika, swoistego spisu treści do tych dokumentów. W bardzo wielu przypadkach przy dobrze prowadzonym Dzienniku, Kierownik musi sięgać do szczegółowych dokumentów tylko sporadycznie; na co dzień wpisy z Dziennika całkowicie zaspokajają jego potrzeby informacyjne.

Przykład typowej zawartości Dziennika znajduje się na końcu artykułu, warto jednak wspomnieć o najważniejszych praktycznych zasadach jego prowadzenia:

  • Zapisuj pozycje dziennika codziennie, nie zostawiaj wpisów na później. Osoby zawsze mające laptop przy sobie mogą zapisywać wprost w komputerze, inni powinni korzystać ze zwykłego notatnika, okresowo przepisywanego do komputera. Najważniejsze jest zapisywanie faktów jak najbliżej momentu zdarzenia.
  • Przy dłuższej nieobecności (np. z powodu urlopu) przekaż prowadzenie dziennika swojemu zastępcy, wprowadź go w sposób tworzenia zapisów.
  • Zacznij Dziennik od „książki telefonicznej” – wykazu głównych osób ze struktury organizacyjnej: nazwisk, ról, sposobów kontaktu, inicjałów używanych dla nich w dalszych zapisach. Podobnie spisz wykaz najważniejszych firm i jednostek organizacyjnych, które często przewijają się w Dzienniku.
  • Rejestruj ważne zdarzenia wewnętrzne (również ważniejsze spotkania i rozmowy) oraz większość zdarzeń zewnętrznych w zakresie kontaktów z Klientem, dostawcami, podwykonawcami, innymi udziałowcami projektu.
  • Rejestruj zarówno korespondencję papierową, jak i elektroniczną, jak też ważne rozmowy telefoniczne i spotkania.
  • Spotkania i korespondencję rejestruj przez wskazanie omawianych tematów i podjętych postanowień i ich terminów, szczegóły pozostaw w notatce ze spotkania lub w treści listu.
  • Notuj decyzje (postanowienia, osoby, terminy) podjęte na spotkaniach wewnętrznych zespołu projektowego.
  • Wpisuj do Dziennika zdarzenia, w których uczestniczyłeś jako Kierownik Projektu, ale także inne istotniejsze zdarzenia wykonane przez ważne osoby w projekcie (np. przyjęcie zmian przez Komitet Kontroli Zmian, testy i odbiory produktów wykonywane przez Klienta, dokument Szefa Jakości itp.).
  • Każdy nowy miesiąc rozpocznij od narysowania kalendarza projektu, zaznaczając w nim planowane/znane daty najważniejszych zdarzeń (np. odbiorów), dni wolne, okresy niedostępności (np. urlopów) kluczowych osób (np. użytkowników zatwierdzających czy opiniujących produkt).
  • W treści Dziennika zapisuj dane o fakturach otrzymywanych i wystawianych (powód faktury, kwota, termin płatności). Na końcu Dziennika prowadź zwięzły rejestr faktur do zapłacenia (przedmiot, wystawca, data, termin, kwota, data wykonanej płatności).

Przy braku prawnych czy metodycznych wymagań nie ma jednego optymalnego sposobu prowadzenia Dziennika. Każdy Kierownik musi dopracować się własnego podejścia. Jednak zalety tej techniki są tak ogromne, że z pełnym przekonaniem warto ją polecić wszystkim adeptom zarządzania projektami.

Dokumentacja spotkań

W dzisiejszych czasach opisywanie zasad organizowania, odbywania i dokumentowania spotkań można uznać za zbędne i wręcz nietaktowne wobec Czytelnika. Ponieważ jednak zmiany w polskiej kulturze biznesowej są dość świeżej daty, wspomnijmy w maksymalnym skrócie o najważniejszych zasadach.

  • Spotkania są często czasochłonne i nielubiane przez wielu ludzi, jednak w wielu sytuacjach są niezbędne. Również dlatego, że projekty robi się dla ludzi i z ludźmi. Szczególnie dotyczy to kontaktów o charakterze „politycznym”: z przedstawicielami Klienta, władzy lub jednostek zewnętrznych (np. dziennikarzy).
  • Osoba inicjująca spotkanie proponuje (z wyprzedzeniem) agendę spotkania: omawiane tematy, orientacyjny czas, osoba referująca. Dzięki temu strona zapraszana może dodać własne propozycje tematów oraz zaproponować dodatkowe osoby (np. ekspertów).
  • Do propozycji agendy trzeba dołączyć komplet potrzebnych materiałów, np. raport okresowy, decyzje Komitetu Kontroli Zmian, wyniki testów, charakterystykę techniczną wyrobu, notatkę z poprzedniego spotkania itp. Pozwala to drugiej stronie przygotować się do dyskusji, jak też dostarczyć własne materiały. Wręczanie materiałów podczas spotkania stanowi bardzo, bardzo złą praktykę biznesową i może być traktowane jako próba nie do końca uczciwego załatwienia pewnych spraw, np. uzyskania zgody drugiej strony bez solidnej analizy sytuacji. Grozi też stratą czasu na czytanie otrzymanych materiałów podczas spotkania. Najczęściej jednak osoba zaskoczona w ten sposób odkłada decyzje czy opinię do następnego razu, przez co spotkanie jest częściowo zmarnowane.
  • Spotkanie należy rozpocząć od przeglądu stanu realizacji postanowień/decyzji z poprzedniego spotkania. Jest to najlepszy sposób na poważne traktowanie zobowiązań przez osoby za nie odpowiedzialne.
  • Przebieg spotkania powinien być notowany lub nagrywany. Powstałe w ten sposób zapisy są później wykorzystane do sporządzenia Notatki ze spotkania. Przy bardziej sformalizowanych relacjach, na koniec spotkania obie strony podpisują prowizoryczne notatki, po czym każda otrzymuje jedną kopię.
  • Notatka ze spotkania jest absolutnie obowiązkowa, jest to jedna z ważnych różnic pomiędzy spotkaniem biznesowym a klubem dyskusyjnym czy zebraniem na imieninach u cioci. Notatkę sporządza strona wyznaczona na spotkaniu (zwykle gospodarz) i wysyła do drugiej strony dla zgłoszenia propozycji zmian. Wynegocjowana (niekiedy w kolejnych iteracjach) Notatka jest często podpisywana na kolejnym spotkaniu. Warto pamiętać, że podpisane obustronnie Notatki są ważnym prawnie dokumentem kontraktowym, a więc mogą być użyte podczas rozstrzygania sporów (w tym: sądownie).
  • Niekiedy Notatka obrazuje przebieg dyskusji, a więc kolejne wypowiedzi. Najczęściej jednak wystarcza forma skrócona, której przykład znajduje się na końcu artykułu. Nie prezentuje on jedynego możliwego standardu, jednak zawiera większość istotnych elementów, które powinny znajdować się w takim dokumencie.

Inna dokumentacja administracyjna

W małych lub krótkich projektach należy minimalizować prace administracyjne, a więc i ilości tworzonych dokumentów. Jednak w większości sytuacji „papiery” są niezbędne dla rzetelnego udokumentowania zdarzeń istotnych np. z punktu widzenia finansowego, często też stanowią niezbędny materiał do planowania i bieżącego zarządzania.

Przykładem może być Ewidencja czasu pracy członków zespołu projektowego.

W zasadzie powinien ją prowadzić każdy kierownik zespołu dla swoich podwładnych; z kolei właśnie kierownicy zespołów, jak też osoby pełniące specjalne role w projekcie (np. Szef Jakości) stanowią bezpośrednich podwładnych Kierownika Projektu. Ewidencja przepracowanego czasu jest często podstawą do rozliczeń wynagrodzeń, jednak ważne jest też planowanie nieobecności, szczególnie plany szkoleń i urlopów. Niedostateczna staranność w tym zakresie może prowadzić do poważnych kłopotów z ludźmi lub ich zadaniami.

Podobną rolę pełni ewidencja pracy całych zespołów, szczególnie obcych (podwykonawcy, specjaliści na zlecenie itp.), kontraktowanych na wykonanie określonych prac i rozliczanych po ich wykonaniu.

Inną ważną kategorią dokumentów administracyjnych są wszelkie papiery związane z zakupami i dostawami produktów. Są one niezbędne dla rozliczeń, ale nieraz mają też znaczenie dla akceptacji (np. dostarczenie klientowi gwarancji producenta czy licencji wraz z dostawą urządzenia). Szczególne miejsce zajmują tu faktury, które zwykle są rozliczane przez służby księgowe, jednak doświadczony Kierownik rejestruje je także w swoim Dzienniku.

Bardzo ważne znaczenie mają kontakty Wykonawcy z Klientem, dlatego też należy solidnie je dokumentować w postaci Rejestru Korespondencji oraz opisanych już Notatek ze spotkań. Praktyka pokazuje, że Kierownik musi sięgać do nich znacznie częściej niż początkowo sądził, szczególnie w razie nieporozumień czy problemów.

Kierownik Projektu szczególnie odpowiada za tworzenie, aktualizację i gromadzenie rozmaitych planów projektu, które były omawiane w poprzednich artykułach.

Inne rodzaje dokumentacji typowo występującej w projektach związane są z zarządzaniem zmianami, zarządzaniem ryzykiem oraz z komunikacją, jednak ich omówienie znajdzie się w osobnych artykułach.

W większości projektów (w projektach większych jest to wręcz obowiązkowe) Kierownik Projektu odpowiada za uzgodnienie określonych procedur i standardów. Oczywiście standardy techniczne związane z produktami są opisane w odpowiednich specyfikacjach, natomiast standardy zarządcze określają np. zasady komunikacji wewnętrznej, sposób zarządzania ludźmi w zespołach i raportowania tych kwestii, współpracę różnych służb w ramach firmy wykonawczej (np. z księgowością) itp. Z kolei procedury opisują przede wszystkim najważniejsze zasady współdziałania i interakcji z Klientem, np. mechanizm zarządzania zmianami, wymiany informacji, odbiorów i akceptacji produktów itp.

Procedury stosowane wobec Klienta są często uzgodnione w kontrakcie, a jeśli tak się nie stało, to powinny być uzgodnione w Dokumencie Inicjacji Projektu (PID).

Podręcznik Projektu i zarządzania konfiguracją

Wszelkie standardy i procedury są często zbierane w tzw. Podręcznik Projektu (ang. Project Manual), stanowiący swoistą Biblię postępowania dla osób pełniących specjalne role w projekcie. Bardzo często firma realizująca projekt opiera się w tym zakresie na gotowych procedurach i standardach, adaptując do konkretnego projektu istniejące już elementy własnej metodyki zarządzania projektami. Podręcznik Projektu musi być zaakceptowany przez Klienta przynajmniej w zakresie procedur i standardów bezpośrednio go dotyczących, dlatego też wskazane jest zaproponowanie odpowiednich jego elementów już w kontrakcie lub w Dokumencie Inicjacji Projektu (akceptowanym formalnie przez obie strony). Zalecane jest, aby Podręcznik Projektu opisywał nie tylko zasady postępowania pracowników Wykonawcy, ale i Klienta np. jego służb logistycznych i finansowych w zakresie przyjmowania i rozliczania dostaw. Takie podejście jest przydatne dla obu stron – szczególnie w przypadku, gdy dostawcą (wykonawcą) jest doświadczona firma światowa, zaś klientem – mniej doświadczona firma lokalna. Wówczas przyjęty obustronnie Podręcznik daje okazję do nabycia ważnych doświadczeń.

Praktyka wskazuje, że w dużych projektach, szczególnie o charakterze konstrukcyjnym (duże budowy), czy związanych z masowymi dostawami, gdzie zaangażowane są liczne służby przedsiębiorstwa oraz firmy zewnętrzne, Podręcznik Projektu jest niezbędnym elementem zarządzania projektem.

Specjalne miejsce należy się dokumentom związanym z dostarczaniem produktów. Mają one zarówno charakter ściśle techniczny (np. instrukcje, specyfikacje i ich zmiany uzgodnione poprzez Zarządzanie zmianami itp.), jak też logistyczny (dostawy, gwarancje, licencje, faktury) oraz zarządczy, a więc najbardziej istotny dla Kierownika Projektu. Do tej ostatniej kategorii należą przede wszystkim wszelkie protokoły (testów, odbiorów, usterek, uzgodnień itp.), często uzupełniane szczegółowymi wykazami i charakterystyką produktów.

Wszystkie te rodzaje dokumentów powinny być odpowiednio zarządzane, wchodząc w skład tzw. Zarządzania konfiguracją. Określenie to pochodzi z informatyki, gdzie konfiguracja oznacza sposób zestawienia odpowiednich elementów i ustawienia ich parametrów w ramach systemu, niekiedy wraz z opisem sposobu działania (funkcjonowania), a więc z procedurami operacyjnymi. W zarządzaniu projektami pojęcie „zarządzanie konfiguracją” ma szerszy zakres i obejmuje nie tylko produkty techniczne czy inne materialne, ale wszelkie produkty (np. szkolenia), wraz z definicją procedur służących do ich wytwarzania i obsługi (dostarczania, aktualizowania, wersjonowania, odbiorów itp.).

Biblioteka projektu

Wszelką dokumentację powstającą w projekcie można podzielić na:

  • Techniczną;
  • Zarządczą.
Załącznik 1: Przykładowy Dziennik Projektu01/02/2009

Mianowanie Szefa Projektu (P.Kowalski) i Przew. Rady (J.Malinowski) przez Zarząd Banku

05/02/2009

Mianowanie 4 członków Komitetu Sterującego przez Przewodniczącego. Dostałem pismo.

08/02/2009

Spotkanie w Banku (11.00-14.00): J.Kowal, P.Łopata, J.Szych. Temat: Plan.

Przedłożenie pierwszej wersji Planu do zatwierdzenia przez Komitet do 12/02.

11/02/2009

Zatwierdzenie Planu przez Komitet. Faktura z 06/02/2009 za opinię prawną (7500 PLN). Umówiłem spotkanie z Szefami Zespołów na jutro – mają przynieść swoje założenia do planu szczegółowego.

12/02/2009

Przełożyłem spotkanie z Szefami – muszę jechać do Banku do Prezesa.

U Prezesa (9.00-9.30, jest też Antek) – chce dalsze Oddziały – do 15/02 będzie Wniosek z wyceną (ewentualnie Aneks do kontraktu). Poleciłem Jankowi wycenę mebli i sieci. Z HP mam faks, że dadzą więcej bez opóźnienia.

15/02/2009

Zatwierdzili Wniosek z ceną wyższą o 1000. Zamówiłem wszystkie maszyny w HP – będzie na 15/04 (kontakt: Maliniak 725-22-34). Mamy plany pomieszczeń w dwóch oddziałach, nie wiadomo kiedy będzie trzeci (mam dzwonić 17/02 do Tadka). Rachunek od Basi (Drobex 5000 za projekt i 2000 za ekspertyzy – płatne do 1/03).

20/02/2009

Z Antkiem uzgodniłem procedurę odbioru. Da mi dwóch elektryków, sam zmierzy napięcie, ja tylko daję plany.

22/02/2009

HP opóźni się o tydzień – zrobimy w tym czasie kable.

26/02/2009

U Antka (10.00-12.00) – zatwierdził plan i przyjął fakturę za Drobex (płatne do kwietnia). Podpisał notatkę ze spotkania 12/02 i 20/02. Umawiamy Komitet Sterujący na 3/03 – Zatwierdzenie większego zamówienia, przyjęcie procedury odbioru i formularzy protokołów odbioru – organizuje Antek.

29/02/2009

Sprawozdanie dla Komitetu za luty – Problemy: przygotowanie planu instalacji (brak specjalistów od sieci).

Plany: robimy budowlankę, potem sieć i pomiary. Podkłady budowlane muszą być do 5/03.

Musimy też uzgodnić ich udział w testach – chcę dostać specjalistę elektryka.

 

Wspólnie tworzą one tzw. Bibliotekę projektu.

Dokumentacja techniczna obejmuje wszelkie dokumenty związane bezpośrednio z dostarczanymi produktami, np. ich projekty czy opisy, charakterystyki i wyniki testów, wykazy usterek i ustalenia co do ich usuwania, podręczniki szkoleniowe, dopuszczenia do użytku przez odpowiednie władze, powiązane dokumenty prawne, materiały prasowe i informacyjne (np. foldery reklamowe), dokumenty zapewniania jakości, procedury użytkowania czy operowania, techniczne szczegóły dotyczące zarządzania zmianami, szczegółowe plany awaryjne.

Dokumentacja zarządcza natomiast wiąże się z samym zarządzaniem projektem i obejmuje wszelkie dokumenty, za które bezpośrednio odpowiedzialny jest Kierownik Projektu i osoby w podobnych rolach. Początkowo są to definicje projektu i plany powstałe w fazie przygotowania, po czym dochodzą kolejno wszelkie dokumenty wytwarzane podczas zarządzania projektem (np. raporty, notatki, procedury, standardy). Specyficzną częścią jest korespondencja i dokumentacja kontaktów zewnętrznych. Oczywiście do tej kategorii należy także Podręcznik Projektu.

Przykładowo – analiza techniczna Wniosku o zmianę, czy szczegółowe działania na wypadek awarii zwykle są zaliczane do dokumentacji technicznej, natomiast sam Wniosek o zmianę, czy też ogólne elementy planu awaryjnego są częścią dokumentacji zarządczej. Podobnie wykaz usterek wykrytych w testach produktu jest dokumentem technicznym, natomiast protokół akceptacji warunkowej (odbiór z usterkami i planem ich usuwania) jest dokumentem zarządczym. W przypadku szkoleń, podręcznik do szkolenia stanowi produkt techniczny, zaś protokół z odbycia szkolenia jest dokumentem zarządczym.

Podział taki jest ma charakter częściowo umowny, choć można na ogół jednoznacznie określić kategorię, do której dany dokument należy. Jednak klasyfikacja taka jest przydatna dla określenia osób odpowiedzialnych za dany fragment dokumentacji: za ich tworzenie, aktualizację, gromadzenie i archiwizację na koniec projektu. Za dokumentację techniczną odpowiadają specjaliści techniczni, za zarządczą – Kierownik Projektu.

Dokumentacja logistyczna (dostawy), finansowa (faktury, płatności) i związana z zarządzaniem zasobami (ewidencja czasu pracy, dokumenty płacowe) mają w zasadzie charakter zarządczy, jednak na ogół (jako bardziej szczegółowe) są gromadzone i obsługiwane w odpowiednich służbach poza ciałem projektu, np. w księgowości. Typowe jest również, że zajmują się nimi jedynie kierownicy zespołów, którzy nie przekazują dokumentów szczegółowych do Kierownika Projektu.

Klasyfikacja dokumentacji umożliwia jej gromadzenie w umownych „Teczkach” dokumentacji projektu: „Teczkach Technicznych” i „Teczce Zarządczej”.

Teczek Technicznych może być wiele (np. specyficzne dla określonych produktów lub zespołów). Są one obsługiwane (tworzone, gromadzone) przez specjalistów technicznych lub kierowników odpowiednich zespołów technicznych, a część tych dokumentów trafia bezpośrednio do użytkownika dostarczonych produktów. Na ogół dokumenty z Teczki technicznej nie są archiwowane na zakończenie projektu, chyba że są wprowadzane do firmowej „bazy wiedzy”.

Za Teczkę Zarządczą odpowiada całkowicie Kierownik Projektu, a znaczna część znajdujących się tam dokumentów podlega archiwizacji, nie tylko w ramach „bazy wiedzy” – do wykorzystania przy kolejnych projektach, lecz także jako dokumentacja kontraktowa, niekiedy o wymaganiach archiwizacji określonych przez prawo. Szczególnie ważne są protokoły odbiorów, gdyż umożliwiają wykazanie, że wymagania kontraktowe zostały zrealizowane.

Zwykle obszerną część tej teczki stanowi korespondencja, która na ogół jest archiwizowana tylko w niewielkiej części (lub w całości, ale w formie elektronicznej).

Na koniec projektu dołączane są też dokumenty zamknięcia projektu: ostateczne protokoły, raport z projektu i Lessons Learnt, podsumowania rozliczeń finansowych.

Biuro Projektu

Biuro Projektu jest dziś modne w Polsce, jednak w praktyce nadal jest rzadko stosowane. Najczęściej taką jednostkę organizacyjną spotkać można w dużych organizacjach/ firmach, w których realizowanych jest równocześnie wiele projektów. Każdy z nich wymaga odpowiedniego nadzoru, każdy też sięga po profesjonalne wsparcie świadczone przez dobrze wyposażonych specjalistów. Warto jednak utworzyć Biuro dla większego pojedynczego projektu, np. ze złożoną strukturą wykonawców i podwykonawców, z dużą liczbą dostaw i faktur, z dużym zespołem realizacyjnym.

Biuro Projektu może się ograniczać do roli pomocy dla Kierownika Projektu, ale może też (i tak się dzieje w dużych organizacjach) pełnić dla niego funkcję kontrolną.

W Biurze Projektu można ulokować ogromną większość powstającej „papierologii”, poczynając od planów i czuwania nad ich realizacją, poprzez wszelkie bardziej i mniej szczegółowe dokumenty techniczne, aż do większości dokumentów zarządczych. Biuro można traktować jako sekretariat i składnicę – archiwum wszystkich dokumentów, wyposażone w odpowiednie mechanizmy (np. rejestr korespondencji, aparat organizowania spotkań), ale można też jego funkcje rozszerzyć na aktywne tworzenie wielu dokumentów, które normalnie leżą w zakresie odpowiedzialności Kierownika Projektu. Przykładowo tworzenie planów i ich aktualizację, jak też kontrolę realizacji i opracowywanie raportów z postępu można w całości zrealizować w Biurze, wyposażonym w doświadczonych asystentów i odpowiednie narzędzia (np. MS Project czy Primavera). Podobnie obsługa korespondencji może prawie w całości (poza najbardziej „polityczną”) leżeć w gestii Biura, odciążając Kierownika Projektu od mozolnej codziennej dłubaniny.

Trzeba jednak podkreślić, iż przekazanie do Biura Projektu dowolnego zakresu prac, nie zdejmuje z Kierownika Projektu pełnej odpowiedzialności za wszystkie te dokumenty. Każdy plan, każdy list, każdy raport i podobne dokumenty powstające w Biurze muszą być zatwierdzane podpisem Kierownika, gdyż tylko na nim spoczywa odpowiedzialność za te elementy. Biuro pełni wyłącznie funkcje techniczne i wspomagające, nie posiada kompetencji decyzyjnej ani samoistnej odpowiedzialności. Każdy błąd w dokumentach obciąża Kierownika Projektu tak samo, jakby on osobiście je wytworzył.

Biuro Projektu może być utworzone specjalnie dla danego projektu, może też istnieć w organizacji jako samodzielna jednostka do wykorzystania przez wiele projektów. Zatrudnieni tam specjaliści są dostępni dla każdego z Kierowników Projektu w uzgodnionym zakresie.

Natomiast funkcjonowanie Biura Projektów, jako wyodrębnionej jednostki organizacyjnej o zadaniach poszerzonych o funkcje doradcze i kontrolne, jest charakterystyczne dla dużych organizacji i służy do Zarządzania Portfelem Projektów, co nie jest tu omawiane.

Dalsze aspekty pracy Kierownika Projektu w fazie realizacji, a więc zarządzanie komunikacją, zmianami i ryzykiem oraz odbiory produktów i kierowanie zespołem będą przedstawione w odrębnych artykułach.

 

Jerzy Szych (szych_jerzy@poczta.gazeta.pl) prowadził kilkadziesiąt projektów informatycznych w Polsce i za granicą. Obecnie jest samodzielnym doradcą zarządzania projektami. Członek Polskiego Towarzystwa Informatycznego i Stowarzyszenia Project Management Polska. Asesor certyfikacji indywidualnej IPMA-SPMP i firmowej IPMA Project Award.

Załącznik 2: Przykładowa Notatka ze spotkania

Temat: Przegląd sytuacji w projekcie Data: 2007/10/01 12.30-14.00 Uczestnicy: ABC: J.Kowalski (JK), P.Malinowski (PM), DEF: J.Szych (JSz) Miejsce: ABC Opracował J.Szych, 2007/10/02

 

Agenda:

 

  1. Przegląd decyzji z poprzedniego spotkania – Wizyty w oddziałach
  2. Sieć WAN – operatorzy telekomunikacyjni
  3. Harmonogram dostaw w projekcie
  4. Sprawy różne

 

Szczegóły:

1. Wizyty w Oddziałach

 

  • Do odbycia pozostały: Kraków (JK), Katowice (PM) – będą odbyte do 7/11/2007
  • W Katowicach jest nowe okablowanie, trzeba sprawdzić, czy jest wystarczające
  • Problemy napotkane podczas wizyt już odbytych: – Poznań – Biuro w trakcie przeprowadzki (pomieszczenia są rozpoznane) – Sochaczew – nie ma decyzji ABC co do połączenia budynków – orientacyjny koszt 120 tys. zł. – można zmieścić w kosztach projektu – decyzja ABC do 15/11/2007
  • Decyzje co do Sochaczewa i Poznania nadzoruje JK – pomieszczenia powinny być gotowe do końca roku

 

2. Sieć WAN – operatorzy telekomunikacyjni

 

  • Odbyły się spotkania z operatorami – pozostały kandydatury TPSA, PLUS
  • Oferta PLUS przyjdzie do 7/11 – odpowiada PM
  • Dla dotrzymania harmonogramu trzeba uzgodnić warunki do końca 01/2008

 

3. Harmonogram dostaw w projekcie

 

  • DEF pracuje nad opracowaniem pełnego, szczegółowego harmonogramu dostaw
  • Po zatwierdzeniu przez ABC, harmonogram będzie podstawą terminowej realizacji prac

 

4. Sprawy różne

 

  • Call Manager – JSz. zorganizuje prezentację Cisco, ale decyzje muszą zapaść do 30/10
  • Podpisano Notatkę ze spotkania 22/09/2007

Datę następnego spotkania ustalono na 07/11/2007.