|
Projekty publiczne
|
Metodyka jest to usystematyzowany zbiór wytycznych
(zaleceń) dotyczących sposobu realizacji prac w określonym obszarze.
Najbardziej znanymi przykładami metodyk w obszarze zarządzania projektami
są Prince 2 czy PMI Project Management Body of Knowledge. Zwróćmy przy
okazji uwagę, że PMBoK spełnia powyższą definicję
metodyki. Definicję tę spełniają również grubsze i cieńsze wydawnictwa
książkowe opisujące mniej lub bardziej ogólnie sposoby zarządzania
projektami. Większość z nich, zgodnie z powyższą definicją, mogłoby w
tytule używać nazwy „metodyka”. Aktualnie uważa się, że zasadniczą częścią
metodyki zarządzania projektami powinien być opis pełnego procesu
zarządzania projektami. Taki sposób definiowania metodyk nie jest jednak
ani jedynym możliwym, ani najbardziej zaawansowanym. Opisując podejście do
zarządzania projektami oparte na wiedzy (21st IPMA World Congress, Knowledge
Oriented Project Management), zauważyłem, że
istnieje kilka podejść do definiowania metodyk w obszarze zarządzania
projektami (a być może i w innych obszarach działalności zorganizowanej).
Podejścia te uporządkowałem według poziomu ich dojrzałości. Za dość
oczywiste kryterium uporządkowania poziomów dojrzałości przyjąłem ich wzrastającą
przydatność do zastosowania w praktyce zarządzania projektami.
Pierwszym obszarem zarządzania projektami, który skupił
uwagę praktyków i teoretyków zarządzania, było harmonogramowanie, aktualnie
rozszerzone do obszaru zarządzania czasem. Dla obszaru tego opracowano
wiele coraz bardziej wymyślnych technik (funkcji), wspomagających
wytworzenie ostatecznego harmonogramu projektu. Aktualnie najbardziej
znanymi spośród nich są technika ścieżki krytycznej oraz technika łańcucha
krytycznego (powiązana także z innymi obszarami, jak zarządzanie zasobami
czy zarządzanie ryzykiem). Wcześniej w obszarze zarządzania czasem
opracowano techniki, wspomagające opracowanie harmonogramu, takie jak Precedence Diagramming Method
czy Arrow Diagraming Method. Na ówczesnym
poziomie wiedzy o zarządzania projektami techniki te obejmowały większość
wiedzy o zarządzaniu projektami, były więc zgodne z definicją metodyki. W
tym samym obszarze opracowano kilka podejść do szacowania czasu realizacji
czynności: szacowanie parametryczne, szacowanie przez analogię czy
szacowanie wstępujące (bottom-up). Ogólnie, we
wczesnym okresie zainteresowania tym obszarem działalności, zdecydowana
większość wiedzy dotyczyła funkcji, które trzeba zrealizować, aby sprawnie
wykonać projekt. Metodyka miała więc postać zestawu technik (funkcji).
Rozwój metodyk polegał na udoskonalaniu poszczególnych funkcji.
Ten rodzaj metodyk zarządzania projektami nazwałem
metodykami nastawionymi na funkcje (Function oriented project management methodologies).
Realizowane funkcje są bardzo ważną składową wiedzy o
zarządzaniu projektami, ale dostarczenie w postaci metodyki wyłącznie ich
opisów pozostawia kierownikom projektów wiele pracy, którą muszą wykonać
planując każdy projekt. Praca ta to uporządkowanie realizowanych funkcji w
czasie oraz przypisanie odpowiedzialności za wykonywanie funkcji członkom
zespołów wykonujących projekt – czyli zdefiniowanie procesu realizacji
projektu. Ponieważ procesy, podobnie jak funkcje, mogą być powtarzane w
trakcie realizacji projektów, ich definicje zostały włączone, a następnie
stały się podstawą metodyk realizacji projektów. Metodyki takie opisują
większą część obszaru zarządzania projektami, niż
metodyki nastawione wyłącznie na funkcje i w sposób bardziej kompletny
wspomagają prace kierowników projektów. Zapewne najbardziej znanymi
aktualnie metodykami tego rodzaju są wcześniej wspomniane Prince 2 oraz PMBoK.
Metodyki takie nazwałem metodykami nastawionymi na
procesy (Process oriented project management methodologies).
Dojrzałość metodyk nastawionych na procesy może być
oceniona bardziej dokładnie. Ponieważ cechą wyróżniającą tę klasę metodyk jest
proces, podstawą do oceny dojrzałości jest dojrzałość opisu procesu, a
mówiąc dokładniej – poziom jego integracji. W rzeczywistości w realizacji
każdego projektu występuje jeden proces jego realizacji: ciąg
uporządkowanych zdarzeń od uruchomienia projektu do jego zakończenia. W
procesie tym, dla uproszczenia opisu, wyróżnia się podprocesy. Rozpoczynane
i kończone są fazy, fazy składają się z czynności, z czynnościami związana
jest obsługa ryzyka czy zarządzanie kosztami lub zaopatrzeniem, sposób realizacji
czynności może być zmieniony itd. Wszystkie te działania są ze sobą
powiązane (zintegrowane) w sposób naturalny i nierozerwalny. Dojrzała
metodyka powinna więc również zawierać jeden spójny proces realizacji
projektu od jego początku do końca. Taką metodykę nazywam zintegrowaną
metodyką nastawioną na procesy. Paradoksalnie charakterystyczną cechą
metodyk zintegrowanych jest to, że nie wyróżnia się w nich osobnych funkcji
czy procesów mających na celu integrowanie innych procesów – ponieważ
proces jest zintegrowany sam w sobie. Niezaawansowana metodyka nastawiona
na procesy składa się z zestawu osobnych opisów z osobnych obszarów
zarządzania (np. zarządzania zakresem, zarządzania kosztami czy zarządzania
jakością). Taką metodykę nazywam niezintegrowaną metodyką nastawioną na
procesy. Pośrednim poziomem dojrzałości metodyk nastawionych na procesy są
metodyki, w których opisane są procesy z różnych obszarów, połączone za
pomocą funkcji i procesów ze sztucznie wprowadzonego obszaru zarządzania
integralnością. Taki rodzaj metodyki nazywam metodyką pół-zintegrowaną
(semi-integrated methodology).
Przykładem zintegrowanej metodyki nastawionej na procesy jest Prince 2, zaś
przykładem metodyki pół-zintegrowanej jest PMBoK, w którym obszar zarządzania integracją wprowadzono
jako ostatni w wydaniu z 1996 roku.
Rysunek 1. Dojrzałość metodyk nastawionych na
procesy
Dwa lata temu firma IT, w której byłem zatrudniony,
zleciła firmie doradczej opracowanie metodyki zarządzania projektami w
kilku obszarach. Jednym z tych obszarów było zarządzanie ryzykiem. W wyniku
swych prac doradcy dostarczyli produkt w postaci definicji procesów
zarządzania ryzykiem, zaś zamawiający okazali swoje niezadowolenie.
Przecież opis procesu zarządzania ryzykiem można znaleźć w wielu miejscach,
jak na przykład w PMBoK. Zamawiającemu w
rzeczywistości potrzebna była zaś wiedza o najczęściej ryzykach, które
najczęściej mogą wystąpić w projektach informatycznych.
Nieporozumienie to nie tylko dostarczyło doświadczeń
związanych z brakiem precyzji komunikacji, ale także stało się podstawą do
moich rozważań na temat dojrzałości metodyk zarządzania projektami, które
doprowadziły do opracowania prezentowanej tutaj klasyfikacji.
Żeby zrozumieć znaczenie wiedzy w metodykach zarządzania
projektami, proponuję zadać sobie pytanie: co jest ważniejsze w obszarze
zarządzania kosztami: znajomość procesu planowania kosztów, czy znajomość
cennika dóbr, które muszą być zakupione dla projektu? Na poziomie
funkcjonalno-procesowym metodyka zapewne będzie zawierać tu zalecenia typu:
pomnóż liczbę jednostek przez cenę i przekaż otrzymaną wielkość do
zatwierdzenia. Analogiczne pytania można zadać dla każdego obszaru
zarządzania. Wniosek płynący z tych pytań i odpowiedzi jest jeden: bez
dostarczenia kierownikowi projektu wiedzy o obiektach występujących w
obszarach zarządzania, nie jest możliwe sprawne zaplanowanie i
zrealizowanie projektu. Oczywiście nie ma powodu, żeby kierownik projektu
za każdym razem od początku zdobywał wiedzę o interesujących go cenach czy
zagrażających ryzykach. Wiedza ta powinna być zawarta w dostarczanej mu
metodyce. Metodykę, oprócz funkcji i procesów zawierającą także wiedzę,
nazywam metodyką zorientowaną na wiedzę (Knowledge oriented project management methodology).
Osobnym problemem jest możliwość ogólnego definiowania
metodyk zorientowanych na wiedzę. Problemem jest poziom stosowalności
wiedzy. Wiedza z niektórych obszarów zarządzania może być stosowana
globalnie (np. sposób konstruowania zespołów projektów), wiedza z innych
obszarów może być tylko lokalna (np. cenniki), zaś z jeszcze innych
częściowo lokalna, zaś częściowo globalna – przykładem jest wiedza z
obszaru zarządzania ryzykiem, w którym niektóre ryzyka mogą wystąpić w
każdym projekcie (np. niestabilność wymagań), zaś niektóre – wyłącznie w
danym kraju czy przedsiębiorstwie. Wynika z tego, że metodyki nastawione na
wiedzę powinny być definiowane lokalnie.
Dojrzałość metodyk nastawionych na wiedzę może być
oceniana bardziej szczegółowo. Najbardziej ogólnym, najmniej zaawansowanym
sposobem prezentacji wiedzy jest poziom jednostek wiedzy. Metodyka taka wskazuje wyłącznie, jakie
jednostki wiedzy są potrzebne do realizacji procesów. Na przykład do
zarządzania kosztami potrzebne są cenniki. Do zarządzania zakresem
potrzebne są elementy WBS. Do zarządzania poddostawcami konieczna jest
wiedz o poddostawcach. Drugi w kolejności poziom opisu wiedzy to poziom atrybutów. Jednostki wiedzy są
charakteryzowane przez wykazy ich danych elementarnych (atrybutów). Na
przykład w skład opisu towaru wchodzą identyfikator, nazwa, opis, jednostka
miary, cena jednostkowa i producent (wskazanie innej jednostki danych).
Trzeci, najbardziej zaawansowany poziom metodyki nastawionej na wiedzę,
jest to poziom pełnej wiedzy,
zawierający wypełnione struktury z poziomu atrybutów. Na tym poziomie mówi
się, na przykład, że Jan Kowalski jest programistą oraz specjalistą od
jakości oprogramowania, jest zaangażowany w realizację projektów od 12 lat,
brał udział w wytworzeniu systemów X1, Y2 oraz A3.
Rysunek 2. Dojrzałość metodyk nastawionych na
wiedzę
Z punktu widzenia ich zawartości, metodyki nastawione na
wiedzę są najbardziej dojrzałe.
Ze wspomnianych w poprzednim podrozdziale doświadczeń
dotyczących definiowania metodyk można wyciągnąć jeszcze jeden wniosek.
Firma IT zlecała firmie doradczej wykonanie metodyk w poszczególnych
obszarach zarządzania. Taka organizacja prac była spowodowana nie tylko
sposobem określania zakresu prac dla podwykonawcy. Zgodnie z PMBoK kierownicy projektów nie zawsze muszą zarządzać
wszystkimi obszarami. Najczęściej podawanym przykładem selektywnego
zarządzania jest nieuwzględnianie obszaru zarządzania poddostawcami – nie w
każdym projekcie poddostawcy są potrzebni. Z praktyki wdrażania narzędzi
Primavera znane są mi przykłady firm, które nie są zainteresowane
zarządzaniem kosztami w projektach, gdyż koszty zewnętrzne nie występują, a
koszty wewnętrzne nie są rozliczane. Wydaje się, że jedynymi obszarami
zarządzania projektami, występującymi we wszystkich projektach jest
zarządzanie zakresem i zarządzanie czasem. Pozostałe obszary mogą
występować lub nie występować w poszczególnych firmach czy nawet
projektach. Potrzeby takiego, selektywnego podejścia do planowania projektu
projektów powinny być uwzględniane przy definiowaniu metodyk zarządzania
projektami. Kierownicy projektów powinni otrzymywać do dyspozycji
komponenty, zawierające procedury, wiedzę, zalecenia i inne składowe,
potrzebne do zaplanowania zarządzania w tych obszarach zarządzania, które
dotyczą aktualnie realizowanego projektu. Metodyki, które pozwalają na
łatwy wybór potrzebnego podzbioru zaleceń, potrzebnych w projekcie,
nazwałem metodykami komponentowymi (Component
oriented project
management methodologies). Dobrze zbudowana
metodyka komponentowa musi zawierać wszystkie te składowe, które zawierają
wcześniej przedstawione formy metodyk i dlatego uważam, że ten rodzaj
metodyki jest bardziej dojrzały niż rodzaje metodyk wcześniej
przedstawione.
Rysunek 3. Poziomy dojrzałości metodyk
zarządzania projektami
Co z tego wynika?
Powyższe rozważania są wynikiem teoretycznych
zainteresowań autora i jego skłonności do pojęciowego porządkowania
otoczenia. Ale model ten może też mieć zastosowanie praktyczne.
Najważniejszym, nie do końca oczywistym zastosowaniem przedstawionego
modelu jest zapewne rozróżnienie metodyk nastawionych na procesy oraz
metodyk nastawionych na wiedzę. Metodyki nastawione na funkcje to już
przeszłość w rozwoju wiedzy o zarządzaniu projektami, zaś metodyki
komponentowe znajdują się na przeciwnym końcu osi czasu, czyli przed nami.
Natomiast rozróżnienie metodyk nastawionych na procesy od metodyk
nastawionych na wiedzę może być praktycznie przydatne – na przykład przy
określaniu zakresu wdrażania rozwiązań z zakresu zarządzania projektami.
Wdrożenie wyłącznie procesów zarządzania projektami bez dostarczenia
odpowiedniego ładunku wiedzy jest pracą niepełną, która rozwiązuje tylko
część problemów osób zaangażowanych w zarządzanie projektami.
Pobierz
tekst o dojrzałości metodyk zarządzania projektami w postaci PDF
|
