Ukryci zabójcy projektu – ich charakterystyka

Czas czytania 7 minut




Końcem stycznia, pisałem (tutaj) o wydarzeniu, które odbyło się 20 lutego. Dotyczyło ono ciekawego tematu, jakim jest kwestia “Ukrytych zabójców projektu” oraz możliwości ich wyeliminowania.

Even się już odbył, ale przemyślenia nadal trwają.

 

Muszę przyznać, że zarówno frekwencja jak i poziom spotkania był imponujący. Oczekiwania miałem dosyć wysokie, a i tak pozytywnie zostałem zaskoczony.

 

W jaki sposób jestem w stanie z taką śmiałością to stwierdzić, że event był udany? Przede wszystkim, dzięki długości dyskusji po wystąpieniu.  Wiele osób wzięło udział w konwersacji, która przerodziła się wręcz w debatę. To naprawdę cieszy.

Ale, podążając dalej tym tematem, przemyśleniami, a także obietnicami złożonymi uczestnikom, czuję potrzebę rozwinięcia 2 kwestii. Dotyczą one tematów, które w szczególności wzbudziły zainteresowanie:

 

Numer 1:

Zła komunikacja w firmie nigdy nie jest prawdziwym problemem organizacji (jest to moja subiektywna ocena, zaraz wyjaśnię dlaczego ;)).

 

Numer 2:

Harmonogram projektu, jeżeli do czegokolwiek ma posłużyć, nie może być zbiorem

małych  zadań i mikrooperacji (to z kolei jest wynik moich wieloletnich obserwacji).


 

Zatem, wyjaśniając numer 1:

 

„Mamy duży problem z komunikacją w firmie!”

Czyżby? Na pewno z komunikacją?

Ile razy to słyszałem? Dziesiątki? Setki? Z całą pewnością na tyle często, by w ogóle nie kupować tej argumentacji… Wobec tego w czym dokładnie jest problem, skoro widzimy, że ludzie w ogóle się nie komunikują, robią to źle, przesadnie, niewystarczająco, nieprecyzyjnie itd. itp.

 

Czy na pewno problem może być gdzie indziej? Odpowiadając krótko: TAK.

Przyjrzyjmy się temu, co  faktycznie ludzie określają jako problem. Nawet bez wybitnych zdolności analitycznych, możemy zauważyć, że ta tak zwana “zła komunikacja” jest efektem czegoś. Czego? Istniejącego, ukrytego i trudniejszego do zdefiniowania problemu.

Zła komunikacja, jest tylko efektem końcowym problemu, który pojawia się wcześniej.

Z moich obserwacji najczęściej (chociaż nie jest to zamknięta lista) problemy wynikają z:

 

1. Miar i sposobów, w jaki sposób pracownicy są rozliczani.

Przykładowo, gdy:

 

  • ceni się wyłącznie działanie, na przykład przerzucanie kamieni z jednej strony budynku na drugi,
  • dopinguje się do otwierania maksymalnej liczby zadań i równoległej pracy nad każdym z nich,
  • lub (wręcz) czyni z informacji jedyne istotne aktywo w firmie (płacimy za to, co kto wie i usłyszał),
to oczywiste jest, że dzieląc się informacjami, pracownicy działają na swoją niekorzyść.

 

2. Braku transparentności w zakresie odpowiedzialności innych osób w firmie.

Szalenie częsty problem. Ludzie po prostu nie wiedzą komu/gdzie/co/w jakiej formie wysłać lub zakomunikować. Jaki mają wówczas wybór? Wysyłać mailem wszystko, mając wszystkich na CC? Słabo to wygląda…

 

3. Wiary, że jeden kanał  informacyjny wystarczy.

Moim zdaniem nie wystarczy. Jeżeli próbujemy mieć tylko 1 kanał informacyjny, np. CRM w dziale sprzedaży, sharepoint, wewnętrzny komunikator itd.  i równocześnie próbujemy dopingować wszystkich, by wszystko, co się da, tam umieszczali, to będzie problem. Ludzie w swojej trzeźwej ocenie zauważą, że to szaleństwo i że muszą chronić swój czas, „karmiąc”, a raczej “zapychając”  system wyłącznie na poziomie minimalnym. Jeszcze gorzej może być, jeżeli do tego, działa równocześnie reguła źle dobranych miar i sposobów oceny ludzi w firmie. Negatywny efekt tylko będzie się potęgować.

 

Jaki jest morał z moich obserwacji? Poważnie, zanim ponownie uwierzysz, że tym razem, naprawdę rozwiążesz problem z komunikacją poprzez zakup kolejnego, super narzędzia, wydania kilku złotych na usługi usługi firm wdrożeniowych oraz szkolenia - zastanów się.  Pomyśl przez  chwilę, zanim przystąpisz do działania ( i wydawania), czy przypadkiem nie próbujesz leczyć skutków,  gdy przyczyna pozostaje nietknięta.


 

Pora na wyjaśnienie punktu numer 2.

 

Harmonogram projektu - gruby jak najedzony kot. Kompletnie bezużyteczny (oczywiście nie mam na myśli kota :) ). Mówiąc językiem przykładów z życia wziętych, bez podawania ich nazwy. Tak jak w serialach, bądź kabaretach, zbieżność z sytuacjami rzeczywistymi wyłącznie przypadkowa :). 

Zatem: mamy projekt 6-cio miesięczny. W harmonogramie  zadań: 300. Kamieni milowych: 40. Etapów: 6. Wszelkie relacje między zadaniami: Zakończ-Rozpocznij; Zakończ-Zakończ; Rozpocznij-Rozpocznij. Poziomy zagłębienia: 4 etc. To nie jest zadanie matematyczne, ale dobrze wykonana praca PM, z której i tak nikt nie skorzysta.

Dlaczego?

Ponieważ działa wyłącznie to, co jest zrozumiałe, co jest proste i łatwe do interpretacji.

Rozumiem, dlaczego ciągle są tworzone tak skomplikowane harmonogramy. Wynikają one ze szczytnych misji, polegających na perfekcyjnym przygotowaniu projektu do realizacji. Dołączamy do tego wykształcenie i zdobyte certyfikaty, które nie mieszczą się na LinkedIn i pojawiające się zobowiązanie, aby wszystko to, czego się nauczyliśmy używać, korzystać z tego. I tutaj zaczyna się budowanie muru.

 

Uwierzcie mi – nikt (poza Wami mam nadzieję) nie będzie tego rozumieć. Wszyscy będą kiwać głową, twierdząc, że te kwestie są dla nich jasne. Bardzo często, to co jest oczywiste jest najtrudniejsze do wdrożenia, docenienia.  Ponownie - dlaczego to wszystko nie działa? I ponownie taka sama odpowiedź - działa tylko to, co ludzie rozumieją od razu.

 

Z języka przykładów – ktoś z Was ma jakikolwiek produkt Apple? Była tam jakaś instrukcja obsługi? Coś przeoczyłem?

(P.S. Piszę na starym i dobrym laptopie z Window :) - koniec kryptoreklamy).

 

Wobec tego, co proponuję?

 

  • Harmonogram jest potrzebny tylko w przypadku projektów klasycznych lub hybrydowych. W przypadku projektów zwinnych – absolutnie nie.
  • Tworzymy go wyłącznie na poziomie Executive. Obrazujemy sekwencję wyłącznie na poziomie pakietów pracy z przypisaną odpowiedzialnością za nie i zespołami realizacyjnymi. Estymujemy czas realizacji. Wyznaczamy ścieżkę krytyczną.
  • Całą  resztę przenosimy na poziom listy zadań przypiętych do pakietów pracy – lista zadań musi być zarządzana przez osoby odpowiedzialne za zadania, a nie przez PM. Listy te i ich „flow” muszą być widoczne dla PM. Stosujemy regułę pełnej transparentności w projekcie.

 

Voilà! W ten sposób integrujemy ten  300 zadaniowy harmonogram na poziomie 15-30 zadań i zarządzamy na 2 poziomach:

- harmonogramu executive (Poziom PM),

- listy zadań dotyczących pakietów pracy (Poziom TM).

 

Może się wydawać, że to tylko subtelna, techniczna zmiana. Być może tak to wygląda. Ale w praktyce, wdrażając równocześnie efektywne zasady monitorowania i aktualizacji pakietów pracy, dokonujemy prawdziwej zmiany w sposobie zarządzania projektem.

 

W kolejnych tekstach postaram się przybliżyć, na czym polega wspomniane efektywne monitorowanie i aktualizacja pakietów pracy w projekcie.

 

P.S.

Wciąż uważam, że czym tekst krótszy, ale treściwy tym lepszy. Jednak mimo wszystko, czasami warto rozwinąć i dogłębnie przeanalizować pewne kwestie, zwłaszcza takie jak ta, dotycząca “Ukrytych zabójców” projektów i ich eliminacji.


 

Pozdrawiam,

Tomek Wrzesiewski

autor