Z natury projektów wynika szczególna zależność, która nie jest wprost opisana przez standard PMBOK® Guide jednak przewija się przez niego w tle. Można ją dostrzec między innymi w samej definicji projektu.
Ciekawe jest też to, że istnienie tej zależności ma wpływ na całą konstrukcję metod i procesów zarządzania projektami począwszy od baseline’owania, przez progresywne planowanie, etapowanie, zarządzanie ryzykiem po raporty poprojektowe.
W definicji proponowanej przez PMBOK® Guide uznaje się, że projekt dostarcza unikalne produkty. Unikalne, czyli takie, odnośnie których nasz poziom wiedzy jest niewielki. Zatem projekt, drugi atrybut, realizujemy progresywnie. Metodą kolejnych przybliżeń, bo z unikalnym działaniami jest jak z pszczołami – nigdy nic nie wiadomo.
To dodatkowo podkreśla praktyczne spostrzeżenie, że wiedza w projekcie na jego starcie jest z reguły niska. Zgadujemy, czy określoną koncepcja uda się wykonać, czy nowy produkt dobrze się sprzeda, czy dostaniemy pozwolenie w terminie, czy zespół zrealizuje zadania w zadeklarowanych budżetach i czasach, czy klient zapłaci itd.
Wiedza na koniec projekt, kiedy wszystko co złe i dobre już się wydarzyło, jest pełna. Znamy faktyczne czasy zadań, wiemy, ile projekt kosztował, wiemy, czy klient jest zadowolony, znamy nasze silne strony i słabości. No chyba, że nie zastanawiamy się nad tym, co się stało i z radością zamykamy kłopotliwy rozdział naszej kariery.
Zatem przez czas życia projekt wiedza o nim rośnie do umownego poziomu 100% od niemal zera. Jednocześnie na początku projektu zmuszeni jesteśmy podejmować najistotniejsze decyzje. To oznacza, że mamy poważny paradoks, gdy obarczeni jesteśmy największym ryzykiem, najwięcej musimy decydować. Podpisujemy umowy, gdy dysponujemy wstępnymi szacunkami, wybieramy technologię, gdy jeszcze jej nie przetestowaliśmy, tworzymy założenia produktu, gdy nie znamy naszych klientów. To zgadywanie prowadzi do problemów.
Wiedza w potrzebna w projekcie obejmuje rozmaite obszary, np.:
- wiedza o kompetencjach i postawach zespołu projektowego,
- wiedza o nastawieniu i celach udziałowców projektu,
- wiedza o technologii, szansach i trudnościach z nią związanych,
- wiedza o sytuacji biznesowej klienta albo dostawcy,
- wiedza o innych projektach realizowanych równolegle w organizacji,
- wiedza o procesach biznesowych i produkcyjnych oraz związanej z nim biurokracji,
- wiedza o środowisku naturalnym albo prawnym, w którym robiony jest projekt.
Poniższy rysunek prezentuje sytuację, gdy projekt może skorzystać z wiedzy organizacji (niebieska linia) wyciągniętej między innymi z poprzednich projektów. PMBOK® Guide nazywa to ogólnie Organizational Process Assets, czyli kapitałem intelektualnym firmy. Różnica między tradycyjną sytuacją, a możliwością skorzystania z dodatkowego know how to po prostu start zespołu projektowego z lepszej pozycji, tj. przy wyższym poziomie wiedzy o przyszłym projekcie. Na przykład mając bazę dostawców, wiemy kogo omijać przy przetargu, mając bazę historycznych czasów zadań, wiemy jak ocenić efektywność ludzi i wiarygodność ich prognoz.
Jednym z celów zarządzania jest przyśpieszenie wiedzy o projekcie, aby jak najbardziej zmniejszyć obszar niepewności, albo rozsądnie odłożyć ryzykowne decyzje w czasie. Czyli spowodować, aby krzywa uczenia się była jak najbardziej wypukła w górę, co przedstawia zielona linia.
W trakcie projektu możemy wszak uczyć się szybciej lub wolniej. Możemy tygodniami czekać na rezultat dużego pakietu prac, a na koniec zdziwić się, że otrzymaliśmy bubel, bo wykonawca był niekompetentny. Albo podzielić prace na mniejsze pakiety, wprowadzić regularną kontrolę u dostawcy i zareagować już po pierwszym tygodniu, gdy zauważymy, że coś jest nie tak.
Z drugiej strony, gdy projekt prowadzony może być w chaosie, gdy zespół nie uzgodnił wymagań, koncepcji, zakresu i w kółko przeżywa te same konflikty, wiedza o projekcie będzie przyrastać wyjątkowo wolno. Wciąż i wciąż możemy się dziwić, że kluczowy ekspert ciągle nie dostarczył zadania na czas (a wszak od samego początku nie ma w ogóle czasu na nasz projekt), albo że wszystkie szacunki budżetu znacznie są przekraczane (choć gdyby spojrzeć na spokojnie to okaże się, że są przekraczane o dokładnie 20%, co wynika z niedoszacowanego zakresu albo zmian cen na rynku). W końcu, gdy projekt cudem finiszuje następuje wielkie UFFF! albo ACHA! Wtedy zespół uświadamia sobie jak bardzo to wszystko było bezsensu i wystarczyło od początku usunąć kilka podstawowych problemów. Na przykład wystarczyło solidnie zaplanować zakres i podpisać rozsądną umowę z klientem.
No i na koniec warto wspomnieć, że pomocna może tu być koncepcja wachlarza, czyli wyboru spośród setek teoretycznych wariantów decyzji, ale o tym innym razem. 😉
PMI, PMBOK, PMP, PMI-ACP, PgMP, PfMP are registered mark of the Project Management Institute, Inc.
