Wiedza jest ważna. To truizm. Jednak w projektach wiedza ma szczególny wymiar.
Poniżej opiszę, jakie są główne sposoby zarządzania wiedzą w projektach, które można napotkać lub których nie można napotkać, ale zaleca je metodyka.
Dobrze obrazuje to poniższy wykres przyrostu wiedzy w trakcie projektu.
Wiedza w projekcie przyrasta sukcesywnie, im więcej zakresu jest wykonane i im więcej czasu upłynie. Na końcu wiemy zdecydowanie więcej, niż na początku. Główne wyzwanie polega na tym, że większość decyzji podejmujemy na początku, gdy musimy zgadywać.
Drugi aspekt funkcjonowania wiedzy to rosnąca zmienność projektu w czasie, co symbolicznie ilustruje poniższy diagram.
Jeżeli na pionowej osi zaznaczylibyśmy trafność prognoz, na przykład terminu, kosztu, pracochłonności, różnych aspektów jakościowych, a na poziomej czas projektu, to okazałoby się, że błąd prognoz rośnie w czasie. Rośnie aż do sytuacji, gdy projekt wymyka się spod kontroli. W wynika to z faktu, że po drodze pojawia się szereg czynników środowiskowych, które pozostają poza kontrolą oraz z tego, że poprzednie etapy sprzedają swoje problemy następnym. Jeden dzień opóźnienia na etapie planowania, staje się pięcioma albo więcej dniami opóźnienia na etapie odbiorów.
Zatem, w jaki sposób zarządza się wiedzą w projektach w praktyce. Podzieliłbym to na dwa sposoby: formalny i nieformalny.
Formalny to taki, w którym istnieje jakaś procedura, sposób postępowania, której należy przestrzegać. Wiedza projektowa uzyskuje tu namacalną formę. W ramach tego podejścia wyróżniłbym dwie kolejne kategorie: ilościowe oraz jakościowe.
Jakościowe formalne to podejście zalecane przez PRINCE2, PMBOK Guide i oznacza ono tyle, że po projekcie należy siąść i spisać raport poprojektowy. Warto w nim opisać przebieg projektu, wnioski, dobre praktywki, problemy etc. dla potomnych. Takie podejście zakłada, że z projektu na projekt będą gromadziły się raporty, tworząc obszerną bibliotekę. A następnie każdy kolejny kierownik projektu będzie z niej korzystał, aby ustrzec się podobnych błędów. Moim zdaniem to nie działa, ale fajnie brzmi.
Ilościowe formalne to podejście, w którym ktoś z boku przygląda się różnym projektom. Gromadzi dane o nich na wybrany temat. Na przykład, gdy dla firmy ważne jest pilnowanie kosztów, to zbiera dane o planach i wykonaniach kosztów w różnych projektach. Ma je pogrupowane na rozmaite sposoby, jak data, rodzaj klienta, rodzaj kosztu, wielkość, etap, osoba decydująca o koszcie, miejsce i wiele innych. Następnie, gdy taki analityk już uzbiera dość danych, to zaczyna się przez nie przekopywać. Poszukuje powtarzających się zależności i czynników środowiskowych na przestrzeni wielu projektów. Na tej podstawie wyciąga wnioski i proponuje modyfikację procesów projektowych. Przykładowo może ustalić, że koszt materiału A zawsze jest o 10% niższy, gdy zamawia go doświadczony kierownik projektu. To oznacza, że warto by przeszkolić pozostałych kierowników, aby uzyskać oszczędności na poziomie 10%. Takie podejście, moim skromnym zdaniem, może naprawdę świetnie działać. Wymaga niestety dużych ilości danych z projektów oraz sprytnego analityka, który raz na jakiś czas siądzie do nich i zada sobie pytanie „co tu się powtarza?”.
Nieformalne podejście ostatnio stało się popularne pod nazwa retrospektywa. Jednak nie jest to wcale nowa filozofia postępowania. W armiach różnych krajów przykładowo od tysięcy lat istniała praktyka omawiania ostatniej operacji, dzisiaj nazywana After Action Review. w obszarze zarządzania produkcją od kilkudziesięciu lat znany jest termin koła jakości. Tak czy siak, idea, by grupa ludzi jadących na tym samym wózku na chwilę odłożyła narzędzia lub maczugi i zastanowiła się, w jaki sposób zoptymalizować swoją pracę jest atrakcyjna. Wszystko jedno, czy chodzi o większą produktywność kolejnego sprintu, eliminację defektów, czy zabijanie wroga. Moim zdaniem, retrospektywa może być niesłychanie skuteczna.
O tym dlaczego uważam, że formalne jakościowe zarządzanie wiedzą w praktyce słabo działa, a retrospektywa czy analiza danych dobrze, napiszę w kolejnym wpisie.
Ps.
Tematyka zarządzania wiedzą w projektach jest mi szalenie bliska z racji napisanego doktoratu oraz systemu zarządzania wiedzą, który onegdaj projektowałem i koordynowałem realizację w ramach nieistniejącej już firmy Pyton.
