13.06.2017

Projekt jako proces

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 (felieton ten można przeczytać tu: http://organizacjahoryzontalna.pl/czy-proces-jest-projektem-a-projekt-procesem/). Wspomniałem też wtedy, że samo zarządzanie projektem jest procesem.  Teraz pora na rozwinięcie tej myśli.

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.

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”.  Ale jeśli ktoś z czytających dokonał rozbioru PRINCE2 na procesy w celu umieszczenia np. w swoim systemie zarządzania ISO, to proszę o kontakt. Jak zobaczę, to uwierzę.

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óry ma 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ę wyznaczoną 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żemy 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?

Patrząc od góry organizacji, najczęstszym błędem rodzącym zamieszanie jest zestawianie i porównywanie ze sobą różnych poziomów zarządzania: porównujemy więc jabłka i ziemniaki. A chodzi o to, żeby porównywać jabłka z jabłkami…

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.

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.

A w rzeczywistości stanowi on 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 – to proces i to proces. 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. 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 kompletną 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. W porównaniu ze standardowymi procesami projekty, co do zasady, niosą ze sobą znacznie większą niepewność i ryzyko niepowodzenia. 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ńcem 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, co tylko zwiększa ryzyko katastrofy, a sam projekt staje się planowaniem porażki…

Chcesz skomentować, podyskutować lub nawiązać kontakt z autorem? Napisz: andrzej.bogusz@abconsult.pl

Czytaj też: Matura procesowa

dr Andrzej Bogusz 

Manager i konsultant z szerokim doświadczeniem (bankowość, informatyka, konsulting). Ekspert z zakresu zarządzania i optymalizacji procesów biznesowych, zarządzania projektami, bezpieczeństwa teleinformatycznego, zarządzania ryzykiem. Szef projektów zmian organizacyjnych i projektów informatycznych. Właściciel firmy AB CONSULT, zajmującej się doradztwem operacyjnym i strategicznym