Wiedza projektowa to wiedza, która pojawia się projekcie.
Jest niezbędna do realizacji projektu.
Ale wiedza może też powstawać w wyniku jego realizacji.
Wiedza organizacji to wiedza, która już w organizacji jest, a która pochodzi z poprzednich projektów albo została wcześniej dostarczona z zewnątrz.
Częściowo te obszary nakładają się.
Najlepiej by było, gdyby cała wiedza projektu stała się częścią wiedzy organizacji, tak aby inne projekty mogły z niej korzystać. I odwrotnie – żeby nasz zespół miał do dyspozycji całą wiedzę innych projektów.
Tak może być, ale trzeba w to włożyć wysiłek.
Przed rozpoczęciem
Przed rozpoczęciem projektu zespół powinien poszukać w organizacji wiedzy, która będzie im potrzebna. Najprostszą i bardzo efektywną metodą jest Peer Assist.
W trakcie
W trakcie projektu zespół i organizacja powinny synchronizować swoją wiedzę. To można wykorzystać np. Community of Practice do dystrybuowania nowej wiedzy wśród ludzi, których to dotyczy. Z tym zastrzeżeniem, że wiedzę trzeba rutynowo przechwytywać w trakcie projektu, nie można przechodzić nad tym co się dzieje do porządku dziennego. After Action Review, czy też Proces Lessons Learned powinny być stale wykorzystywane.
Po zakończeniu
Po zakończeniu projektu, jeżeli zespół w trakcie realizacji zdobył nową wiedzę, powinien podzielić się tą wiedzą z innymi projektami. Można wykorzystać tu dobrze zdefiniowane procesy, takie jak Retrospekcja czy Knowledge Handover.
Przechwycenie wiedzy po zakończeniu projektu wymaga jednak włożenia wysiłku, dodatkowej pracy.
I ta praca ma być wykonana zaraz po zakończeniu, czyli wtedy, kiedy z ulgą chcemy już zapakować dokumentację projektową do szafy i przejść do następnego zadania.
I to właśnie wtedy trzeba usiąść i zastanowić się:
- Co było zaplanowane w projekcie?
- Co wyszło inaczej, niż planowaliśmy?
- Co powinniśmy powtórzyć?
- Co powinniśmy zrobić inaczej?
- Jakie rady i wskazówki, z perspektywy czasu, możemy dać przyszłym projektom?
Wnioski, a nie pliki
Powinno się przechwytywać wnioski, a nie pliki projektowe. Pliki to tylko informacje, nie niosą wiedzy. Projekt zapewne robił pewne rzeczy źle, a prawie na pewno, z perspektywy czasu, mógł zrobić coś lepiej. Tu właśnie jest miejsce na zastanowienie. Tak uczy się człowiek, zespół i organizacja. Grzechem jest trwanie w błędach, a nie ich popełnianie. Przechwytywanie wniosków po fakcie to miejsce, gdzie uczenie się i wiedza rezydują.
Dobre rady:
- Nie przechwytuj więc pakietu ofertowego prezentowanego klientowi; przechwycić tę ofertę, jaką powinieneś przedstawić; cenę, jaką powinieneś dać; pakiet, jaki powinieneś zastosować. Wszystkie te rzeczy powinny wyjść w trakcie po-ofertowego przeglądu. Każdy przetarg, wygrany czy przegrany, jest dostawcą wiedzy, poprawiającym szanse w przyszłych zamówieniach.
- Nie przechwytuj planowanego wzoru produktu, przechwyć wzór powykonawczy, w którym były zrobione poprawki i powiedz, dlaczego były zrobione.
- I tak dalej, i tak dalej.
Ale uwaga:
Aby zespoły projektowe dobrze zarządzały wiedzą projektową muszą wiedzieć JAK to zrobić. I muszą wiedzieć, dlatego projekty wymagają swojej własnej Struktury Zarządzania Wiedzą. Procesy przechwytywania wiedzy, takie jak jak After Action Review czy Retrospekcja powinny być ujęte w planie projektu.
