Okruszki, Kod Leonarda Da Vinci i komunikacja w projektach

Carl Pritchard, PMP

Jeśli czytaliście Jasia i Małgosię albo Kod Leonarda Da Vinci, czytaliście opowieść o podążaniu po śladach i szukaniu wskazówek. Jednak w obu przypadkach tropy wiązały się z niebezpieczeństwem i zagrożenia można było pokonać tylko nadzwyczajnymi środkami. W naszych projektach często wcielamy się w rolę „rzucających okruszki”. Rzucający okruszki to osoby, które zostawiają za sobą ślady dla innych (lub dla siebie), tak jak Jaś i Małgosia próbujący wydostać się z lasu. Rzucający okruszki odpowiadają za zachowanie tropu w nienaruszonym stanie, zapewnienie jego trwałości i dopilnowanie, by zawarte w nim informacje nadawały mu jakąś wartość. Pojedynczy okruszek na szlaku nie ma żadnego znaczenia, ale sznureczek zmyślnie rozrzuconych okruszków wytycza wyraźną ścieżkę i wyznacza kierunek.

Co ciekawe, kierownicy projektów czasami nie traktują takich informacji jako znaków drogowych, lecz otaczają je aurą tajemniczości, zupełnie jak w Kodzie Leonarda Da Vinci. Słówko wyjaśnienia dla osób, które nie czytały książki ani nie widziały filmu: intryga Kodu Leonarda Da Vinci obraca się wokół starannego przygotowania całego szeregu przemyślnie ukrytych wskazówek, które rozszyfrować i podjąć może tylko ekspert. W tej historii zasadnicze informacje są starannie maskowane, by tylko nieliczni mogli je wychwycić i zrobić z nich jakiś użytek.

Zaglądacie czasem do diagramu sieciowego? Być może dla was jest zrozumiały, ale niewprawny obserwator może uznać go za narzędzie dezorientacji. Studiujecie wykresy wykorzystania zasobów? Są trochę bardziej oczywiste niż diagram sieciowy, ale i tak dla niektórych stanowią zagadkę. Tabela wartości wypracowanej? Dla wielu taki dokument równie dobrze mógłby być napisany hieroglifami.

Tragiczny w tych dokumentach (i wielu innych tworzonych w ramach zarządzania projektem) jest brak czegoś, co w Kodzie Leonarda Da Vinci było akurat na porządku dziennym. Otóż brakuje w nich spójnej legendy. Brakuje kluczy, instrukcji obsługi i opisów umożliwiających rozszyfrowanie tego, co mówią, udostępniają lub wyjaśniają.

Tworzenie „kluczy” do projektu

W bajce Jaś i Małgosia okruszki były rzucane wyłącznie na użytek samych dzieci, które chciały zaznaczyć sobie drogę powrotną przez las. W Kodzie Leonarda Da Vinci wskazówki były przeznaczone dla wąskiego kręgu wtajemniczonych. Nasza misja w zarządzaniu projektami jest niemal dokładnie odwrotna. Rejestrując informacje i tworząc zestawy danych musimy udostępniać klucze jak najszerszemu gronu. Dlaczego? Nie wiadomo, czy jutro jeszcze tu będziemy, żeby w miarę potrzeby otwierać drzwi. (Nie ma w tym nic ponurego – możemy akurat być na Bahamach!) Nie wiadomo, czy będziemy w pobliżu, żeby objaśnić co i jak zostało zrobione i co to wszystko znaczy.

Rozwiązaniem jest tworzenie kluczy. Prosty opis słowny można dołączyć w zasadzie do każdego pliku, albo w jego treści (MPP, DOC, XLS, itp.), albo w rubryce „Komentarze” dostępnej we „Właściwościach” pliku. Sam diagram sieciowy jeszcze nie wystarczy. Krótka instrukcja dołączona do diagramu może pomóc w jego rozszyfrowaniu nawet osobom, które nie rozumieją jego podstawowej struktury.

To jest diagram następstw. Każdy prostokąt przedstawia pracę złożoną z nie więcej niż 80 roboczogodzin, wykonywaną przez jeden zespół lub komórkę organizacyjną w jednej lokalizacji. Strzałki łączące prostokąty oznaczają kolejność wykonywania prac. Prostokąty przekreślone jedną linią to prace w toku. Prostokąty przekreślone znakiem „X” to prace zakończone. Diagram nie jest wyskalowany na osi czasu.

Nawet członkowie zespołu, którzy nigdy nie studiowali zawiłości diagramów następstw, zyskają pewne pojęcie o tym, jak skonstruowany jest diagram i na co wskazują niektóre oznaczenia. Niektórzy kierownicy projektów utrzymują, że takie informacje nie powinny być podawane, ponieważ ludzie czytający dokumentację projektu z założenia powinni się w niej orientować, a jeśli jej nie rozumieją, to nie powinni jej czytać. To niedorzeczne. Przy całym bogactwie informacji, które trzeba rejestrować w projekcie i tak szerokim polu do nieporozumień otwarta komunikacji tworzy sposobność do nauki i rozwiewania niejasności bez konieczności codziennych interwencji ze strony kierownika projektu.

Składnica informacji („cache”)

W języku angielskim „cache" to wspaniałe słowo. Brzmi jak „cash”, czyli gotówka, sugerując coś wartościowego. Kojarzy się ze skarbem (chociażby w wyrażeniu „ukryty skład złota”). Ma też związek z nowoczesną technologią, ponieważ oznacza pamięć podręczną wykorzystywaną w każdej przeglądarce internetowej. Każdy projekt ma swoją pamięć podręczną czy składnicę informacji. Jest to bogaty zbiór archiwalnych lub aktualnych danych, takich jak korespondencja w ramach projektu, dane historyczne, plany, kontrakty i wszelkie inne detale administracyjne gromadzące się w trakcie projektu.

Bohaterowie Kodu Leonarda Da Vinci większość czasu poświęcają na przemierzanie globu w poszukiwaniu odpowiedzi. Właśnie wokół tego obraca się cała intryga. Jednak w realiach projektu poszukiwanie kluczy nie powinno się upodabniać do szukania świętego Graala (chociaż niektórzy kierownicy projektów mają do tego talent). Powinniśmy raczej dążyć do stworzenia wspólnych zbiorów informacji i jasnych wskazówek ułatwiających dotarcie do danych. Skróty dostępne w programach Microsoft® są przeraźliwie niedocenianą funkcją. Wcale nie trzeba tworzyć setek kopii dokumentów projektu. Kilka sensownie umieszczonych skrótów do głównego katalogu projektu pełni rolę drogowskazów prowadzących do miejsca, w którym znajdują się dane. Nie jest to złożone przedsięwzięcie, a jedynie funkcja stworzenia głównego folderu projektu i zapewnienie wsparcia poprzez swobodne udostępnienie go innym.

Protestujący i Graal

W Kodzie Leonarda Da Vinci celem jest poszukiwanie Graala. Cel ten jest jasny dla tych, którzy dokładnie wiedzą, czym jest Graal. W naszych projektach musimy wykazywać taką samą dozę koncentracji i zapału w dążeniu do celu i określaniu naszych celów. Każdy, kto śledził nerwową reakcję opinii publicznej na Kod Leonarda Da Vinci wie, że spór sprowadza się do kwestii komunikacji i informacji. Co jest herezją? Co nią nie jest?

Co najdziwniejsze, w realiach projektu też istnieje – przynajmniej zdaniem niektórych kierowników projektów – coś takiego jak herezja związana z udostępnianiem informacji. Niektórzy kierownicy projektów uważają, że otwarty styl zarządzania projektem stwarza okazję do nadużyć i niewłaściwego wykorzystywania informacji. Inni sądzą, że udostępnione informacje dają siłę i władzę całemu zespołowi projektu, umożliwiając zarządzanie pozytywne i skuteczną realizację projektu.

Bez względu na punkt widzenia, konieczna jest wspólna definicja celu lub, jeśli wolicie, naszego Graala. Jeśli dana osoba lub organizacja nie potrafi jasno powiedzieć, co mamy znaleźć na końcu ścieżki z rozsypanych okruszków, ułożenie okruszków w odpowiedniej kolejności i pozyskanie innych do współpracy będzie trudne. I właśnie o to warto się postarać.

Carl Pritchard jest starszym instruktorem ESI oraz Dyrektorem Pritchard Management Associates z siedzibą w Frederick w stanie Maryland. Jest wykładowcą o międzynarodowej renomie, autorem i konsultantem. Napisał The Project Management Communications Toolkit (Artech House), Risk Management: Concepts & Guidance (wydanie 3) oraz wyprodukował (wraz z J. LeRoy Wardem) Conversations on Passing the PMP Exam. Jest amerykańskim korespondentem brytyjskiego czasopisma PM Today poświęconego zarządzaniu projektami. Carl posiada certyfikat Project Management Professional, prowadzi szkolenia oraz doradza w dziedzinie zarządzania projektami i ryzykiem na całym świecie. Jego adres e-mail to carl@carlpritchard.com.

Źródło: ESI Horizons. All rights reserved.