Wyobraź sobie…
Właśnie rozpoczynasz nowy projekt. Chciałbyś:

  • nie siedzieć po nocach;
  • mieć możliwie mało roboty;
  • zdążyć w terminie i zmieścić się w budżecie;
  • nie gryźć palców, kiedy widzisz, że wszystko się wali.

Wiesz, że były w firmie już inne, podobne projekty, więc myślisz, że gdybyś wiedział o nich więcej, to może byłoby Ci łatwiej. Szukasz więc po firmie jakiś informacji.

Gdzie ukrywa się wiedza, która powstaje w czasie realizacji projektu?
Czy po jego zakończeniu wyparowuje, czy jest przekazywana dalej?

Bingo!
Znalazłeś odpowiednie dokumentacje projektowe, a w nich:

  • budżety projektów, takie jakie były planowane przed rozpoczęciem;
  • zasoby, takie jakie były zaplanowane;
  • założone harmonogramy, planowane kamienie milowe;
  • listy produktów projektów. Zaplanowanych na początku realizacji.

Przeglądasz dokumenty, ale nic z tego dla Ciebie nie wynika. Ty wolałbyś wiedzieć jakie były:

  • rzeczywisty budżet projektu, z przekroczeniami i oszczędnościami; w jakich pozycjach te przekroczenia wystąpiły, dlaczego i czy możesz ich uniknąć, i jak;
  •  rzeczywiste zasoby. Nie jest ci potrzebny plan zasobów. Plan to ty już masz. Ty chciałbyś wiedzieć, czy ten plan zasobów sprawdził się w realizacji, czy były potrzebne korekty i jeśli tak, to jakie; a może inaczej dysponować dostępnymi zasobami? Jak?
  • rzeczywisty harmonogram realizacji – czy trzeba było korygować początkowy harmonogram? Dlaczego? Co można było zrobić, żeby utrzymać się w czasie?
  • zestawienie produktów dostarczonych w rzeczywistości. Czy były problemy? Jeśli były, to jakie? Z jakością? Z terminem dostarczenia? Z akceptacją? Co można zrobić, żeby było lepiej?

TO są rzeczy, który pomogłyby Ci teraz. TO jest prawdziwa wiedza, która powstaje w projekcie.
Nie dokumentacja projektowa, ale wnioski, do jakich tamte zespoły doszły w trakcie realizacji, ich doświadczenia zdobyte w walce, są tym, co warto przekazać dalej.

Przechwycenie wiedzy wymaga jednak włożenia wysiłku, dodatkowej pracy po zakończeniu projektu. Po zakończeniu, czyli wtedy, kiedy z ulgą chcemy już zapakować dokumentację projektową do szafy i przejść do nastepnego zadania. I 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?

Procesy przechwytywania wiedzy, takie jak jak After Action Review czy Retrospekcja powinny być ujęte w planie projektu. Powinno się przechwytywać wnioski, a nie same pliki projektowe. Projekt mógł robić pewne rzeczy źle, a prawie na pewno, z perspektywy czasu, mógł robić pewne rzeczy lepiej.

Przechwytywanie plików będzie przechwytywało błędy, ale nie będzie przechwytywało wniosków po fakcie, a to jest miejsce, gdzie uczenie się i wiedza rezydują.

  • 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.

Leave a Reply

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *