Przeczytaj cały artykuł (w formacie PDF)

Transkrypt

Przeczytaj cały artykuł (w formacie PDF)
Megaprojekty
Rzecz nie jest tak prosta jak opowiadanie o tym …
Autor: dr Tadeusz Lis
(Artykuł po raz pierwszy ukazał się w magazynie „Zarządzanie Projektami” nr 2(9)/2015 )
Zeszłoroczny listopad zamknął się znaczącym wydarzeniem, jakim był kongres PMI. Doskonała
organizacja, tematyka na czasie, kilku ciekawych prelegentów - wszystkie te elementy sprawiły, że
polski oddział PMI ma prawo do uzasadnionej dumy.
Obie sesje, w których uczestniczyłem, zrobiły na mnie ogromne wrażenie, choć z zupełnie różnych
powodów. W tym artykule chciałbym podzielić się refleksjami po wysłuchaniu wybranych referatów
wygłoszonych podczas sesji poświęconej wielkim przedsięwzięciom. To, co dla mnie było
najbardziej zaskakujące, to próba przekonania słuchaczy, że istnieje gotowa metodyka pozwalająca
z dużym prawdopodobieństwem zrealizować takie przedsięwzięcie. Aby zrozumieć istotę wyzwania,
przyjrzyjmy się temu bliżej, jako inżynierowie systemowi od projektowania współczesnych,
wysokosprawnych organizacji.
Zastanówmy się, z czego w praktyce składa się dowolny system zarządczy. Jest on (a przynajmniej
powinien być) harmonijnym połączeniem siedmiu elementów.
Są to:
1. Język opisu, w którym definiujemy w specjalnym słowniku pojęcia używane w konstrukcji
naszego systemu zarządczego.
2. Procesy zarządzania działaniami w ramach programów i tworzących je projektów, których
celem jest dostarczenie przedmiotów dostawy. Są one realizowane przez zespoły
wykonawcze, zarządzane przez kierowników projektów.
3. Procesy nadzorczo-sterujące, realizowane przez zlecających podjęcie działań sponsorów (w
niektórych przypadkach ciała kolegialne, takie jak komitety sterujące).
4. Struktury zarządcze, realizujące powyższe procesy, opisane przez stanowiska funkcyjne
oraz role biznesowe.
5. Wewnętrzne akty normatywne o ścisłym przeznaczeniu i określonych zależnościach, takie
jak polityki, regulaminy, procedury, instrukcje czy listy kontrolne. Akty te konstytuują formalny
system zarządczy, nadając odpowiednie uprawnienia wszystkim uczestnikom systemu i
nakładając na nich konkretne obowiązki.
6. Metody, techniki i narzędzia do realizacji różnych typów zaplanowanych działań.
7. Wykształceni, zmotywowani w odpowiedni sposób ludzie, którzy zajmują się wyłącznie tym,
czym mają się zajmować (podejście lean).
Pomyślmy teraz, gdzie jest miejsce dla ewentualnie gotowej metodyki zarządzania projektami i
sprawdźmy po kolei obszary naszych zainteresowań.
JĘZYK OPISU SYSTEMU ZARZĄDCZEGO
Z naszego doświadczenia wynika, że używanie gotowych metodyk jest mało użyteczne, a w
przypadku wielkich projektów - wyraźnie niewskazane. Standardy metodyczne, takie jak PMBOK,
PRINCE2, SCRUM, XP i inne, oferują tutaj kompletny i starannie przemyślany aparat pojęciowy,
którego zaletą jest to, że jest rozumiany w sposób jednolity na całym świecie. To oznacza, że
zawodowy menedżer projektu, legitymujący się stosownym certyfikatem kompetencji, będzie się nim
sprawnie posługiwał.
Zatem nie należy:
a. ani zmieniać powszechnie rozumianych pojęć,
b. ani uzupełniać słownik o rzeczy niekonieczne - brzytwa Ockhama powinna być często
używanym narzędziem.
Nie jest tu trudno o wypadek przy pracy. Przykład: wprowadzane w metodykach pojęcie z żargonu
korporacyjnego issue management, które doskonale można wyrazić przy pomocy pojęć z zakresu
PMBOK i PRINCE2, takich jak zmaterializowane ryzyko i ograniczenia projektu. Czy standardowy
aparat pojęciowy jest wystarczający dla wielkiego przedsięwzięcia? Oczywiście nie, ponieważ każda
organizacja wytwarza swój specyficzny język jako ważny element kultury korporacyjnej.
W tym języku dyrektora programu możemy nazwać dyrektorem kontraktu, kierownika projektu menedżerem projektu, liderem zespołu projektowego, kierownikiem odcinka robót itp. Dokument
inicjujący projekt może być nazywany kartą lub opisem projektu, a także wnioskiem inwestycyjnym.
Z kolei etap projektu może być np. makrozadaniem. Każda z tych nazw jest uprawniona, o ile jest
zgodna z kulturą językową zespołu realizującego przedsięwzięcie, a interpretacja pojęć jest
jednoznaczna i nie pokrywa się znaczeniowo z pojęciami języka potocznego.
Dobre praktyki wykonawcze:
1. Przeanalizuj wcześniejsze inwestycje klienta w wiedzę z zakresu PPP (zarządzanie programami,
projektami i portfelami). Pozyskanie życzliwości szefa HR jest tutaj kluczowe. Zwracaj uwagę nie
tylko na szkolenia, ale również na studia podyplomowe oraz standardy metodyczne, jakie były
dotychczas stosowane przy realizacji podobnych przedsięwzięć.
2. Zaprojektuj i przeprowadź badanie stanu wiedzy z obszaru zarządzania PPP, wykorzystując
jeden z dobrze sprawdzonych modeli (np. CMMI) oraz ankiety, i na ich podstawie opracuj
wywiady pogłębione, które pozwolą Ci prawidłowo zinterpretować wyniki.
3. Cennym źródłem uzupełniającym są wewnętrzne akty normatywne typu strategie, regulaminy,
polityki i procedury operacyjne. Zaoszczędzisz dużo czasu, jeśli do wykonania tej pracy użyjesz
dobrze przetestowanego programu do analiz statystycznych tekstów. Trick: dla ćwiczenia spróbuj
użyć tego oprogramowania: http://tools.seochat.com/tools/page-keyword-density-analysis/ dla strony
http://www.pmgloss.com/about/ - czyli słownika PMI. Porównując to z bazą tekstów organizacji, dla
której projektujesz system do zarządzania wielkim przedsięwzięciem, od razu będziesz miał
cenne wskazówki dotyczące tego, jak budować ekonomicznie uzasadniony słownik.
4. Zaprojektuj słownik korporacyjny przedsięwzięcia wraz z tzw. konkordancją rzeczową, czyli
przykładowymi kontekstami występowania danych definicji i określeń. Zwróć szczególną uwagę
na synonimy oraz terminy wieloznaczne. Pamiętaj, że potencjalnymi beneficjentami Twojej pracy
będą prawnicy korporacyjni, przygotowujący umowy z wykonawcami i podwykonawcami.
5. Uzupełnij słownik o brakujące pojęcia, ale uwaga: nie trzymaj się dogmatycznie żadnego ze
standardów zarządczych. Przykładowo, budując słownik, możesz przyjąć jako ramę pojęciową
PMBOK, ale jeżeli będzie to wygodne, wprowadź pojęcie planowania zorientowanego na produkt
(przedmiot dostawy) lub pojęcie przeglądu etapowego.
6. Po kontroli kompletności uzupełnij słownik o synonimy i przedstaw go do zatwierdzenia.
Oczywiście słownik jest strukturą żywą, ale jeżeli dobrze wykonałeś swoją pracę, to liczba zmian
do końca projektu nie powinna przekroczyć kilku - kilkunastu procent.
7. Jeżeli jednak do budowy systemu spróbujesz używać niszowych metodyk typu home made, to
prędzej niż później doświadczysz kłopotów w implementacji procesów sterowania obiegiem
informacji zarządczej.
GOTOWE PROCESY WYKONAWCZE PROWADZENIA PROJEKTU
Wydawać by się mogło, że w metodyce istnieje możliwość zestandaryzowania sekwencji działań,
takich jak definiowanie projektu lub zarządzanie jakością. Oczywiście można, ale użyteczność tego
dla wielkiego przedsięwzięcia jest tak mała, że w praktyce nigdy nie skorzystaliśmy z tych procesów.
Realizacja każdego z procesów zarządczych, podobnie jak przyjęcie języka opisu, ściśle zależy od
wewnętrznych uwarunkowań środowiska, w którym realizowane jest przedsięwzięcie. W każdym
naszym wdrożeniu procesy te były unikalne, choć często nosiły identyczne nazwy.
Przyjrzyjmy się prostemu procesowi określenia pracy do wykonania (SOW) - statement of work.
Występuje tutaj kilkanaście czynników decyzyjnych, które doświadczony projektant systemu musi
wziąć pod uwagę, np. czy proces ma być uniwersalny dla każdego typu projektu składowego
tworzącego program (czyli być niezależny dziedzinowo), czy też powinien uwzględniać dziedzinę
(techniczną, organizacyjną, rynkową, itp.) już na poziomie sekwencji czynności. Czy punktem startu
są wcześniej wykonane studia wykonalności, czy też mają stać się one elementem procesu. Czy
definicja projektu jest autorstwa kontraktowego menedżera, czy może zespołu sponsora
zlecającego pracę itd.
Dobre praktyki wykonawcze:
1. Przy projektowaniu procesów i operacyjnych procedur wykonawczych dla konkretnego wielkiego
przedsięwzięcia nie trać czasu na wzorce z „gotowych metodyk” - zamiast tego opracuj je od
początku (od czystej kartki papieru) w konwencji typowej dla operacyjnych procesów
wytwórczych klienta, który zamówił u Ciebie usługę zaprojektowania systemu.
2. Jeżeli nie istnieje taki standard wewnętrzny, to użyj wytycznych z systemów zarządzania jakością
lub też standardów dojrzałych instytucji rządowych, realizujących duże programy inwestycyjne
(USA, Wielka Brytania, Australia).
3. Do rysowania procesów używaj wyłącznie notacji BPMN 2.0, ale - w zależności od sytuacji wybierz rozsądny podzbiór symboli. Opanuj dobrze ten język, tak abyś rozumiał logikę opisu
procesów przy użyciu jego symboli o szczegółowości adekwatnej do poziomu modelowanego
procesu.
4. Dbaj o poprawność przebiegu procesu zarządczego z punktu widzenia symulacji kontroli jego
czterech głównych parametrów, tj.:
a. skuteczności (np. zarządzania wytwarzaniem przedmiotów dostaw),
b. efektywności Gest to ważne zwłaszcza przy dużych przedsięwzięciach, o których mówimy),
c. jakości (czyli zgodności procesu z zatwierdzonymi standardami),
d. zarządczych ryzyk operacyjnych (parametr często w ogóle nie uwzględniany w żadnej ze
znanych nam gotowych metodyk PPP, a tym samym nagminnie pomijany przez początkujących
hobbystów, zaczynających swoją przygodę z projektowaniem tej klasy systemów. Oczywiście
nie należy mylić tych ryzyk z ryzykami procesów wytwarzania przedmiotów dostaw, np.
technologicznymi lub środowiskowymi.
5. Przed implementacją danego procesu opracuj kilka jego wariantów, wylicz wartości powyższych
parametrów w drodze symulacji matematycznej. To nie jest trudne - wystarczy kilkaset linii
relatywnie prostego kodu w języku VBA MS Office plus jakaś darmowa baza danych, np.
Postgres.
6. Przedstaw sponsorowi do akceptacji wariantowe modele procesów wraz z obliczeniami,
wskazując model rekomendowany plus uzasadnienie.
7. Pamiętaj o poniższych bardzo ważnych rzeczach:
a. każdy zaprojektowany przez Ciebie proces powinien być przeanalizowany pod kątem
integracji z już istniejącymi procesami zarządczymi klienta, dla którego projektujesz system (np.
procedurami budżetowania),
b. równolegle z modelami procesów projektuj od razu operacyjne procedury zarządcze,
wzorce dokumentów (patrz dalej) oraz - w szczególnych przypadkach - specyfikację
funkcjonalną systemu workflow uwzględniającą istniejące u klienta oprogramowanie. Takie
postępowanie, choć wymaga od Ciebie stosunkowo wszechstronnej wiedzy, daje najniższy
koszt jednostkowy oraz najkrótsze czasy osiągnięcia gotowości operacyjnej systemu. A przy
pewnej wprawie nie jest to wcale takie trudne.
c. do pisania procedur nie używaj w żadnym wypadku edytora tekstów! W dużym projekcie nie
poradzisz sobie z kontrolą wersji oraz odtworzeniem porządku prawnego na dany moment w
przeszłości - co jest niezbędne dla potrzeb audytów lub kontroli przez zewnętrzne instytucje,
takie jak NIK lub CBA. Jest to istotny element zapewnienia bezpieczeństwa prawnego
zarządów Twoich klientów, o którym warto pamiętać. W praktyce do automatycznego tworzenia
aktów normatywnych tworzących system zarządczy od wczesnych lat 90. używamy systemu
QualiMan™, który poza kontrolą
wersji zapewnia nam możliwość tzw. integralności
referencyjnej aktów prawnych, w tym badania wrażliwości projektowanego systemu na
patologie typu koncentracja zbyt dużych uprawnień decyzyjnych w jednym ręku lub wadliwe
modele kompetencyjne,
d. użyteczny trick: jeżeli nie dysponujesz takim systemem, zbuduj szybko prowizoryczne
rozwiązanie, wykorzystując darmowe bazy danych, takie jak MySQL lub MS SQL Server
Express z interfejsem składającym się z elementów zaprojektowanych w darmowym
generatorze formularzy. Tak robimy w prowadzonych przez nas społecznie projektach, w
których skromny budżet nie pozwala na zakup lub dzierżawę profesjonalnego systemu
wspomagającego tworzenie aktów normatywnych i ich utrzymania w spójności w dłuższym
okresie czasu.
Jak widać, dla dużych przedsięwzięć nie ma praktycznie miejsca na wykorzystywanie rozwiązań z
gotowej metodyki, ponieważ gdyby faktycznie zawierała ona modele nadające się do implementacji
(czy chociażby adaptacji) procesów wykonawczych, to musiałoby ich być tysiące, a sam sposób
nawigowania w takim zbiorze pochłonąłby wszystkie korzyści płynące z gotowej metodyki.
GOTOWE PROCESY NADZORCZO - STERUJĄCE
W żadnej znanej nam gotowej metodyce autorzy nie zaproponowali właściwych modeli takich
procesów. Tymczasem ta klasa działań jest kluczowa dla sukcesu wielkiego przedsięwzięcia z
67
oczywistych powodów. Wynika to z faktu, że w większości przypadków takie przedsięwzięcia są
mało wrażliwe na błędy pojedynczych kierowników projektów, za to bardzo wrażliwe na błędy w
koordynacji (integracji) działań w projektach składowych. Czy te procesy można zaprojektować jako
standard? Oczywiście, że nie. Są one istotnie różne dla rozbudowanych struktur hierarchicznych
oraz płaskich struktur procesowych. Implementujemy je zupełnie inaczej dla firm z ciężką
infrastrukturą techniczną, niż dla firm handlowych czy takich, gdzie głównym przedmiotem działań
są usługi (a te z kolei zależą od typu rynku usług).
Zatem, przywołaną w tytule iluzją jest to, że można tutaj opracować jakiekolwiek wzorce projektowe.
Dotyczy to oczywiście w tym samym stopniu struktur zarządczych. Zawsze bardzo starannie
badamy, czy dla danego przedsięwzięcia warto jest powołać komitet sterujący (czasami warto,
czasami nie - reguły są tutaj ścisłe), a jeżeli go powołujemy, to czy ma mieć charakter ciała
decyzyjnego, czy też doradczego dla głównego sponsora (i w tym wypadku reguły są ścisłe).
Wybrane dobre praktyki wykonawczej
1. Projektuj procesy nadzorczo-sterujące, biorąc pod uwagę fakt, że na kluczowe przesądzenia
dotyczące ich kształtu ma wpływ model ładu organizacyjnego, który jest podstawą organizacji
klienta, dla którego pracujesz. Zwróć uwagę, że w Polsce niekoniecznie musi to być model
niemiecki. Coraz częściej spotykamy modele łacińskie, a nawet amerykańskie oraz angielskie.
2. Zwróć również uwagę, że w modelach tych nie tylko inaczej funkcjonują mechanizmy audytu, ale
nawet inaczej jest definiowany obowiązek lojalności. Nie uwzględniając tych faktów, możesz
niechcący narazić zarząd Twojego klienta na trudny do obrony zarzut nienależytej staranności
nadzoru nad wielkim przedsięwzięciem. Unikanie takich sytuacji jest cechą profesjonalistów
projektujących i wdrażających takie systemy. Ponieważ różnice często są subtelne i wymagają
wnikliwej analizy organizacyjno- -prawnej, nie ma tu miejsca na żadne gotowe rozwiązania.
3. W konstrukcji systemów nadzorczych używaj precyzyjnych, dystynktywnych pojęć.
4. Pamiętaj, że w wielkim przedsięwzięciu zaniedbanie pozornie prostej rzeczy, jak nieprecyzyjne
określenie okoliczności, w których należy stosować działania w uzgodnieniu, zamiast działań w
porozumieniu, może łatwo narazić Twojego klienta na kosztowny spór sądowy, co w przypadku
kontraktów, jakimi się zajmujemy, może całkowicie przekreślić zdolność osiągnięcia zadanego
celu.
5. Właściwe umocowanie formalne dla procesów zarządczo-sterujących w tej klasie przedsięwzięć
musi być zawarte już w umowie inwestycyjnej.
6. Użyteczny trick: w przypadku wielkiego przedsięwzięcia zawsze rozważaj powołanie celowej
spółki operacyjnej (SPV - special purpose vehicle) do jego realizacji. Może to uprościć wiele
kwestii organizacyjnych. Może również wywołać kłopoty z czymś, co w żargonie nazywamy
„bankowalnością realizacji”.
7. Nie decyduj zbyt pochopnie o wyborze sposobu realizacji, tj. modelu GRI, inwestora zastępczego
lub inwestora bezpośredniego. W przypadku inwestycji infrastrukturalnych dobrze nam się
sprawdzają modele FIDIC, które stosujemy w ścisłej współpracy ze Stowarzyszeniem
Inżynierów, Doradców i Rzeczoznawców (SIDiR).
8. Pomyśl o tym, że w przypadku konkretnego wyboru nie tylko zmieni się radykalnie miejsce
umocowania funkcji nadzorczo-sterujących, ale również sam sposób ich wykonywania (np. gdy
zdecydujesz się na powołanie inżyniera, w Polsce nazywanego często inżynierem kontraktu),
zwłaszcza w przedsięwzięciach typu EPC lub EPCM charakterystycznych dla polskiej energetyki.
GOTOWE WZORY DOKUMENTÓW
Wartością gotowych metodyk mają być wzorce dokumentów projektowych. Jednak w praktyce, w
naszych działaniach okazywały się zazwyczaj prawie całkowicie bezużyteczne. Dlaczego?
Ponieważ ich ogólna zawartość merytoryczna jest dostatecznie dobrze opisana w wymienionych
wyżej standardach prowadzenia projektów oraz programów. Jeżeli jednak potrzebujesz inspiracji, w
Internecie znajdziesz tysiące wzorcowych przykładów - nie płać więc za coś, za co nie musisz.
A jeśli chodzi o szczegółowy wygląd? Niestety, znów trzeba zacząć od czystej kartki papieru - musi
być zaprojektowany od początku. W wielkich projektach wzorce te są silnie zdeterminowane
istniejącymi już w dużych firmach standardami dokumentacyjnymi, począwszy od struktury JRWA
(Jednolitego Rzeczowego Wykazu Akt) poprzez standardy kodowania regulacji wewnętrznych aż do
wymagań odnośnie przetwarzania danych w systemach workflow oraz business intelligence itp.
Ponadto w większości znanych nam metodyk proponowane wzorce zawierają liczne błędy zarówno merytoryczne, jak i strukturalne. Nie są one krytyczne w małych projekcikach, ale w dużych
z pewnością okażą się źródłem kłopotów (dotyczy to zwłaszcza projektów inwestycyjnych).
Przykładem mogą być szeroko propagowane wzorce skomplikowanych dokumentów zarządzania
jakością (Quality Plan). W prawidłowo zaprojektowanym systemie zarządczym nie ma potrzeby
komplikowania go - wystarczy na danym etapie cyklu życia projektu umieścić:
a. w sekcji zarządczej harmonogramu wybrane działania związane z planowaniem jakości (np.
zadania: „Wypracowanie propozycji kryteriów jakości zarządzania projektem oraz kryteriów
jakości przedmiotów dostaw” i „Uzgodnienie i zatwierdzenie kryteriów jakości zarządzania
projektem oraz kryteriów jakości przedmiotów dostaw”), a także kontrolą jakości zarządzania
(przykład: „Kontrola jakości dokumentacji zarządczej w etapie X”)>
b. w sekcji realizacji przedmiotów dostaw umieść wszystkie zadania związane z
zapewnieniem jakości oraz kontrolą jakości, związane w naturalny sposób z wytwarzaniem i
przekazywaniem do eksploatacji przedmiotów dostaw [przykład zadań: „Kontrola uprawnień
spawaczy wykonujących skraplacz wysokociśnieniowy”, ale też: „Kontrola ciśnieniowa (próba
wodna) gotowego skraplacza”].
Wybrane najlepsze praktyki wykonawczej
1. W konstrukcji dokumentów tworzonych „od czystej kartki papieru" dla wielkiego przedsięwzięcia
dbaj od początku o precyzję pojęć, używając ich wyłącznie z zatwierdzonego wcześniej słownika
korporacyjnego. Prawidłowo opracowany plan zarządzania jakością otrzymamy jako wydruk
podzbioru zadań z aktualnego harmonogramu. Kluczem selekcji będzie oznaczenie ich
prawidłowo w odpowiednim polu jako zadania planowania, zapewnienia i kontroli jakości.
2. Projektując ten wydruk, unikaj błędu strukturalnego, w którym zachęcasz opracowującego plan
do licznych opisów słownych, nienadających się do automatycznego przetwarzania (jakość nie
powinna być rozumiana jako postulaty przyłożenia się do staranniejszej pracy).
3. Zamiast tego, po prostu zamieść listę działań z harmonogramu, w której obok nazwy zadania
podasz jego unikalny identyfikator (klucz główny zadania) oraz standardowe informacje, tj.:
a. kiedy zaczyna się i kończy działanie,
b. jakie zasoby są w nim zużywane,
c. gdzie w repozytorium przedsięwzięcia znajduje się dokumentacja techniczna opisująca
sposób wykonywania zadania oraz kryteria odbiorowe (link),
d. dodatkowe (opcjonalne) wskazówki związane z zapewnieniem wysokiej jakości danego
zadania, powiązane np. z aktualnymi warunkami jego realizacji, wpływającymi na jakość jego
wykonania (np. na budowie - warunki meteo).
4. Projektuj tak, aby każde pole dowolnego dokumentu można było jednoznacznie zinterpretować w
obrębie całego systemu zarządczego dla wielkiego przedsięwzięcia.
5. Jeżeli nie jest to absolutnie konieczne, nie redefiniuj w dokumentach słów powszechnie
używanych w innym znaczeniu ani nie używaj ich w dwuznacznym kontekście. Na przykład
używa się określenia monitoring, podczas gdy z kontekstu planu jakości wynika, że chodzi o
nadzór jakościowy oraz dalej operacyjną kontrolę jakości w procesie wytwarzania przedmiotu
dostaw.
GOTOWE NARZĘDZIA - NA PRZYKŁAD OPROGRAMOWANIE
Z naszego doświadczenia wynika, że funkcjonalność oferowanych na rynku narzędzi jest bardzo
ograniczona, w szczególności w stosunku do wielkich przedsięwzięć. Dlaczego tak się dzieje?
Ponieważ ich siłą jest właśnie uniwersalność. Przykład: weźmy popularny, ceniony przez nas
produkt, jakim jest MS Project. Ma on wiele zalet. W skali wielkiej inwestycji nic nie kosztuje, ma
przyjazny interfejs podobny do innych aplikacji pakietu MS Office. Co ważne, większość wstępnych
szkiców harmonogramów można wykonać natychmiast po wyjęciu oprogramowania z pudełka. Ale
czy uda się poprowadzić przy jego pomocy (nawet gdy będzie wpięty w MS Project Server) duże
przedsięwzięcie? Zdecydowanie nie, gdyż nie zawiera on szeregu dedykowanych mechanizmów
automatyzujących pracę, np. wspierających nadzór nad realizacją postanowień konkretnej umowy.
Wybrane dobre praktyki wykonawczej
1. Unikaj egzotycznych, niszowych rozwiązań - prędzej czy później wynikną z tego kłopoty z
niezawodnością i brakiem wsparcia technicznego.
2. Potraktuj każde dobrze znane i popularne oprogramowanie (np. MS Project, Primavera, Clarity)
jako środowisko developerskie, w którym w krótkim czasie nie tylko zbudujesz potrzebne Ci
dedykowane funkcjonalności, ale również sprawnie ukryjesz funkcjonalności zbędne.
3. Przykład praktyczny: wyłącz na wstępie automaty typu resource leveling, które - przy braku
doświadczenia - potrafią mocno (i niestety niezauważalnie) zaburzyć harmonogram, lub zablokuj
możliwość zmiany ustalonych przez Ciebie terminów wymagalnych (time-frame schedule
approach).
4. Integruj w maksymalnym zakresie środowisko programowe PPP z istniejącymi systemami
wewnętrznymi. Przykład: synchronizacja kalendarzy zasobów z firmowym systemem HR,
implementacja automatycznych sekwencji działań dla określonych typów robót (spawalniczych,
budowlano-montażowych, kolejowych itp.), automatyczna dekompozycja kosztów na subanalityki
w systemie FK, czy automatyczne przydzielanie zasobów zgodnie z modelami kompetencyjnymi.
Należy podkreślić, że jest to zawsze specyficzne zarówno dla firmy, jak i przedsięwzięcia, zatem
szukanie tutaj gotowych rozwiązań w dowolnej gotowej metodyce jest z góry skazane na
porażkę. Przykładem może być realizacja projektów z dofinansowaniem unijnym, co wymaga
prowadzenia odpowiedniej, dość specyficznej rachunkowości.
5. Integruj narzędzia z zewnętrznymi bazami danych referencyjnych, np. serwerami prognozującymi
kursy walutowe, danymi Eurostat itp. Zaoszczędzisz w ten sposób dużo czasu na pracach
związanych z zapewnieniem Integralności danych.
6. W operacyjnych procesach zarządczych wykorzystuj w rozsądny sposób urządzenia mobilne, ale
ogranicz się do ścieżek opisujących postępowanie w sytuacjach szczególnych ¡awaryjnych, a
także unikaj spamu Informacyjnego.
GOTOWE SZKOLENIA Z METODYKI
Z naszego punktu widzenia ich użyteczność jest bardzo niewielka w stosunku do poniesionych
nakładów oraz kosztów, będących wynikiem odrywania ludzi od codziennych zajęć. Oczywiście
można dla celów marketingowych twierdzić, że dedykowane szkolenie powstałe w wyniku
gruntownej adaptacji elastycznej, skalowalnej metodyki zarządzania projektami, jest tym, czego
najbardziej potrzebujemy przy rozpoczęciu wielkiego przedsięwzięcia. Ale jest to równie zasadne,
jak twierdzenie, że elastyczna
skalowalna metodyka przygotowania udanego przyjęcia
wigilijnego nadaje się doskonale do budowy systemu zarządzania inwestycjami - wystarczy jedynie
zmienić metody, techniki, narzędzia, procedury oraz przepisy kulinarne.
Dobre praktyki wykonawcze:
1. Zaprojektuj, tak szybko, jak to możliwe, najważniejsze mechanizmy zarządcze poziomu
operacyjnego.
2. Opracuj na ich bazie proste, dedykowane szkolenie oparte o studia przypadków, zbudowane
wyłącznie na kanwie doświadczeń klienta. Uczy to konkretnych, dedykowanych procesów
zarządczych.
3. Podziel ćwiczenia na działania w sytuacjach standardowych oraz szczególnych i awaryjnych.
4. Wykorzystaj pytania i wątpliwości słuchaczy do udoskonalenia systemu poprzez jego
uproszczenie.
5. Zadbaj o to, aby szkoleni natychmiast dostali przydział do ról w rzeczywistych projektach współpraca z PMO oraz działem HR jest absolutnie niezbędna.
6. Zapewnij coaching w rozsądnym zakresie - dopasuj kształty krzywych uczenia do rzeczywistych
potrzeb. Nie przyspieszaj procesu uczenia, jeżeli nie jest to wymuszone restryktywnymi
terminami - postępowanie przeciwne zmniejsza pewność uzyskania trwałych rezultatów szkoleń.
ZAMIAST PODSUMOWANIA
Czy gotowa metodyka zarządzania projektami ma jakąkolwiek wartość dla profesjonalisty znającego
solidne ramy metodologiczne PMBOK, PRINCE2, Agile oraz doskonały model kompetencyjny
IPMA? Odpowiedź brzmi - i tu zaskoczę Czytelników - zdecydowanie tak. Jej miejsce jest na półkach
supermarketów zarządczych dla małych (ale już nie średnich) przedsięwzięć i takich też firm (przez
analogię do gotowego oprogramowania typu shrink wrap). Trzeba tylko pamiętać, iż założenie, że w
miarę wzrostu skali i wagi projektu będziemy włączać do systemu kolejne procesy zarządcze, jest
błędne.
W przedsięwzięciu dowolnej skali trzeba zawsze wykonywać wszystkie procesy zarządcze.
Faktyczna różnica powinna być widoczna jedynie w stopniu formalizacji procesów, złożoności
struktur zarządczych oraz adekwatności technik (głównie ilościowych). Proponowane wyżej
podejście można zilustrować następującym przykładem. Mamy za zadanie zaprojektować dwa
samochody: komfortową limuzynę do touringu oraz małe, kompaktowe autko miejskie. W
proponowanej metodyce limuzyna, zgodnie z zasadami, będzie miała wszystko, co mieć powinna. A
jeśli chodzi o małe autko miejskie? Value proposal mówi: ograniczmy się do wyposażenia go w
silnik, trzy i pół koła, kierownicę, pół siedzenia z nieheblowanej deski na dwóch cegłach (bo to prosty
projekt). Hamulce, chłodnica, instalacja elektryczna i szyby - to zbędne detale.
Jakoś trudno jest się nam przekonać do tej wizji...
Ale wracając do spraw poważnych, nadmienić trzeba, że nawet duża firma komercyjna nie jest w
stanie wytworzyć wartościowych rozwiązań we wszystkich obszarach zarządzania
przedsięwzięciami - to jest po prostu zbyt drogie. Jednak względy komercyjne nakazują oferować
kompletność rozwiązań. Ale Ty, jako projektant rozwiązań, nie będąc przedstawicielem żadnej
metodyki, masz znacznie większe pole decyzyjne - po prostu nie musisz się przejmować ani
konfliktem lojalności, ani narzuconymi przez zagraniczną centralę planami sprzedażowymi.
Wykorzystuj zatem wartościowe elementy z wielu podejść metodologicznych. Nie bądź
dogmatyczny - to hańbiące dla umysłu inżyniera. Podziwiaj jasność opisu procesów PMBOK,
zachwyć się solidną ramą metodyczną MoR i dojrzałością równoważenia interesów stron w
PRINCE2. Pochyl się z szacunkiem nad modelem kompetencyjnym IPMA. Miej w przyborniku
zestaw lekkich narzędzi agile’owych - słowem: bądź otwarty i uważny oraz unikaj konfliktów
etycznych.
Nie propaguj nieprzemyślanych, choć chwytliwych tez z zakresu pop managementu, jak np. w
zarządzaniu portfelowym wykorzystanie narzędzi i technik do realizacji celów przedsiębiorstwa w
możliwie najkrótszym czasie i najniższym budżecie - to podważa zaufanie do zawodu, który
wykonujemy wspólnie.
Cele mają być realizowane w zadanym czasie ustalonym w procesie harmonizacji głównego
programu rozwoju. Ich koszt ma być adekwatny, a rozkład nakładów i źródeł finansowania
zharmonizowany z wytycznymi korporacyjnego departamentu skarbca lub kontrolingu. Nie myśl ani
przez chwilę o systemie zarządzania projektami jako o wydzielonej, autonomicznej strukturze.
Projektuj go w oparciu o integrację z pozostałymi podsystemami zarządczymi, tj. systemami
zarządzania strategicznego oraz zarządzania operacyjnego. Jeżeli nie będziesz tego przestrzegał,
łatwo popełnisz fundamentalne błędy, a system, prędzej czy później, zostanie wypluty przez firmę.
Na zakończenie ostatnia praktyczna wskazówka. Jeżeli masz mało czasu i nagle stanęło przed
Tobą wyzwanie zbudowania systemu dla wielkiego przedsięwzięcia, to bezcennym poradnikiem
będzie dla Ciebie książka pod redakcją prof. Michała Trockiego pt. Metodyki zarządzania projektami
(Warszawa 2011). Jest to doskonałe kompendium, z głęboko przemyślanym wprowadzeniem
metodycznym, porządkującym omawiany temat w pierwszych trzech rozdziałach. Powinno Cię ono
zachęcić do poznania wymienionych tam metodyk, a następnie ich twórczego, konsekwentnego i
świadomego odrzucenia, gdy już zaczniesz szkicować projekt systemu zarządczego dla wielkiego
przedsięwzięcia.