Autor ANDRZEJ BOGUSZ
Projekt jako proces – jak rozumieć i stosować zarządzanie procesowe w zarządzaniu projektami
Projekty są zazwyczaj przedstawiane jako przeciwstawny biegun do procesów. Tymczasem samo zarządzanie projektami jest na wskroś procesowe, a niejasności i kontrowersje najczęściej wynikają z niewłaściwej perspektywy patrzenia na obie rzeczywistości.
Projekt jako anty-proces
Jakiś czas temu pisałem o rozróżnianiu projektów i procesów – oraz o tym, jak często są mylone te dwie rzeczywistości zarządcze (Procesy i projekty: w czym są podobne, a czym się różnią. Dlaczego lepiej ich nie mylić w biznesie.). Wspomniałem wtedy, że samo zarządzanie projektem jest procesem. Czas na rozwinięcie tej myśli.
Na początek chcę zaznaczyć, że nic nowego ani odkrywczego nie zamierzam pisać. Metodyka PRINCE2 jest (cytuję jej podręcznik) „podejściem do zarządzania projektami opartym na procesach”. Mało jest jednak organizacji, które budując swoja metodykę zarządzania projektami dokonała rozbioru PRINCE2 na procesy w celu umieszczenia w swoim systemie zarządzania ISO.
Chwilka przypomnienia i ujednolicenia terminologii. Proces to zestaw działań, zasobów i kompetencji przekształcający określone wejście w wyjście. Jego wynikiem jest produkt (produkty), które mają za zadanie zaspokoić potrzebę klienta procesu. Realizując procesy dążymy do ich powtarzalności, bezbłędności, mierzalności i coraz większej optymalności. Na procesach opiera się podstawowa działalność każdej organizacji.
Projekt to tymczasowa organizacja wewnątrz firmy. Powoływana w celu osiągnięcia unikatowych rezultatów, koniecznych dla osiągnięcia korzyści sponsora projektu. Z założenia projekt wprowadza zmianę, narusza stabilną sytuację wyznaczona przez powtarzalne procesy. Projekt jest więc unikalny, ograniczony w czasie, ma nieokreśloną początkowo, a później unikalną strukturę, jest ukierunkowany na zmiany, no i ma spore ryzyko niepowodzenia. W tych aspektach projekt jest „antyprocesowy”.
High-level, czyli perspektywa zarządcza
Ale jeśli spojrzymy z bliska (bardzo bliska) na przebieg procesu, to możne zobaczyć podobny obrazek: każdy wyrób jest w jakiś sposób unikalny (ma np. swój numer seryjny), mamy ograniczenie czasowe (zaczynamy produkować samochód i po pewnym czasie kończymy), zasoby się zmieniają (bo kto inny pracuje dziś, a kto inny jutro), ryzyko błędu istnieje zawsze, a świat zmienia się gdy wyprodukujemy kolejną partię gwoździ… A więc czyżby proces był projektem?
Cały wic polega na tym, aby porównywać jabłka z jabłkami, a nie z ziemniakami. Choćby te jabłka były różnych gatunków:
Najczęstszą przyczyną zamieszania jest występujące często podobieństwo, a czasem wręcz nieodróżnialność, produktu końcowego projektu i wyrobu będącego przedmiotem produkcji. Taka sytuacja występuje np. w sytuacji tworzenia nowej linii technologicznej dla nowego wyrobu. Powstający w takim przedsięwzięciu, traktowanym (zazwyczaj słusznie) jako projekt, produkt końcowy, będący prototypem, jest często w pełni zdatny do użytku jak i do sprzedaży, nie odróżnia się niczym od wyrobów, które na jego bazie będą w przyszłości produkowane seryjnie.
Tymczasem „produktem” procesu zarządzania projektami nie jest produkt końcowy projektu, ale… zdefiniowany, zaplanowany, zrealizowany i udokumentowany projekt. W rzeczywistości produkt projektu (nie procesu) w powyższym przykładnie stanowi wyłącznie wzorzec przyszłego wyrobu. Skomplikowane? Warto spojrzeć na obrazek od góry. Z poziomu organizacji widzimy zarówno proces produkcyjny, jak i proces zarządzania projektami, na tym samym poziomie – obydwa są procesami. Proces produkcyjny będzie zajmował się różnymi wyrobami (w jednej fabryce możemy produkować dżemy, konserwy i płatki, w zależności od potrzeb, możliwości i strategii) i analogicznie zarządzanie projektami będzie obejmowało w danym czasie różne projekty (rozpoczęte ze względu na aktualne potrzeby, strategię i możliwości). Znów podobnie. Ale już konkretny projekt będzie wytwarzał dość uniwersalną dokumentację zarządczą projektu i jednocześnie całkowicie unikalny właściwy produkt końcowy (który też może być dokumentacją). A podczas produkcji powstają seryjnie takie same wyroby (często odróżnialne prawie wyłącznie numerem seryjnym) i dokumentacja produkcyjna.
Z odpowiedniej perspektywy problem okazuje się więc pozorny, wynikający po części z abstrakcyjności samego projektu i konkretności wyrobów.
Projekt jako proces
Warto się pokusić o pewne przybliżenie: czym jest faktycznie to procesowe podejście do zarządzania projektami, o którym mówi, między innymi, PRINCE2?
Na najwyższym poziomie projekt odpowiada na potrzebę organizacji, jaką jest dokonanie zmiany w niej samej. To jest impuls, początek. Ta potrzeba zmiana wynika z przekonania, że dzięki niej osiągniemy korzyści w biznesie – rozwiniemy się, zyskamy – lub ograniczymy koszty i straty. To przekonanie stanowi uzasadnienie biznesowe projektu. Posiadając odpowiednie zasoby, kompetencje, infrastrukturę, projekt przekształca tę potrzebę w realizację samej zmiany. Nie było drugiej hali fabrycznej? – już jest. Potrzeba było sformalizować kontrolę jakości? – oto wdrożona procedura tego dotycząca. Stary system ERP nie spełniał wymagań? – mamy wdrożony nowy system, spełniający nasze potrzeby. Przy okazji powstaje cała ewidencja projektu, harmonogramy, budżet, rejestr ryzyka, itp. – która pozwala na porównywanie projektów pomiędzy sobą: czy (i o ile) przekroczyliśmy termin, ile zaoszczędziliśmy budżetu, na ile kompletna dokumentację dostarczyliśmy, itp. Mamy więc możliwość określania KPI dla tego, nomen omen, procesu.
Na niższym poziomie architektury, projekt w dalszym ciągu zachowuje się procesowo. W poszczególnych etapach pojawiają się procesy niższego poziomu, mające swoje wejścia i wyjścia (standardowe wymagania dokumentacyjne), dostawców i odbiorców (którymi są często inne procesy projektu), sekwencje kroków, określone role, możliwość monitorowania i określania miar, itp. W pewnym uproszczeniu (pomijając np. sytuacje nadzwyczajne), wygląda to tak:
Mamy więc w pełni powtarzalny proces. A że bardziej abstrakcyjny niż większość innych? Taka jego uroda.
Na koniec jeden element, który może budzić wątpliwości. Projekty, co do zasady, niosą ze sobą znacznie większą niepewność, ryzyko niepowodzenia – w porównaniu ze standardowymi procesami. Czy rzeczywiście w odniesieniu do zarządzania projektami można i trzeba zakładać inne miary ryzyka? Takie mniemanie również bierze się z niewłaściwej perspektywy spojrzenia. Przedmiot projektu, jego produkt, który stanowi zmianę w organizacji, niesie zwiększone ryzyko. Ryzyko polegające na niespełnieniu wymogów postawionych temu produktowi, ryzyko opóźnień lub przekroczeń terminów, ryzyko zamknięcia przed końce z powodu zmiany priorytetów, itp. Nie zmienia to natomiast faktu, że projektem – nawet tym opóźnionym, z przekroczeniami lub przedwcześnie zamykanym – można dobrze zarządzać, zawsze zgodnie z regułami określonymi w procesie zarządzania projektami. Czym innym jest niepowodzenie projektu (często niezawinione), a czym innym niedbałe zarządzanie nim, które tylko zwiększa ryzyko katastrofy, a sam projekt staje się planowaniem porażki…
Autor: Andrzej Bogusz
Artykuły tego Autora
