Zginą albo nauczą się współpracować

Specyfika dużego klienta polega m.in. na tym, że w udział w projekcie informatycznym na stałe zaangażowanych jest nie kilka, a kilkanaście, a niejednokrotnie kilkadziesiąt osób, zaś ad hoc - wielokrotnie więcej. Jak zarządzać zasobami w takim projekcie? Jak się komunikować? Gdzie kryją się największe pułapki?

Specyfika dużego klienta polega m.in. na tym, że w udział w projekcie informatycznym na stałe zaangażowanych jest nie kilka, a kilkanaście, a niejednokrotnie kilkadziesiąt osób, zaś ad hoc - wielokrotnie więcej. Jak zarządzać zasobami w takim projekcie? Jak się komunikować? Gdzie kryją się największe pułapki?

Nazywam się Tomek, Tomek Norman. Pracuję w tym biznesie od piętnastu lat. Jeśli masz jakiś problem, a nie chcesz gadać z Zarządem - przychodzisz do mnie.

Tego dnia siedziałem, jak to ostatnio, w biurze, paląc kiepski tytoń w mojej nieodłącznej fajce i wspominając minione sprawy. Drzwi nagle lekko skrzypnęły, kiedy weszła ona... Mój umysł zawodowego PM uruchomił natychmiast czerwony sygnał alarmowy, już wiedziałem, że będą kłopoty...

Pani wiceCFO oznajmiła ciepłym i miłym głosem: "Mam dla ciebie nowy projekt, no w zasadzie nie nowy, bo już trochę trwa... jak dla ciebie nic wielkiego... w zasadzie wszystko jest już zrobione, tylko trzeba dokończyć... a i z zasobami nie będziesz miał kłopotów, dwadzieścia sześć osób na stałe i ze trzydzieści do wzięcia w każdej chwili...". Po chwili milczenia, którą poświęciłem na zastanawianie się, dlaczego u licha nie zachorowałem dziś na grypę czy też nie miałem jakiejś drobnej stłuczki, która umożliwiłaby mi uzasadnioną nieobecność w pracy, usłyszałem niby-pytanie: "Zgadzasz się, prawda? Możesz zacząć od zaraz, informacja do zespołu już poszła, Zarząd i ja na ciebie liczymy..."

Przebrnąłem przez wiele projektów skazanych przez wszystkich na śmierć i powiem wam jedno, nie ma trudnych spraw, są tylko trudni ludzie.

Zginą albo nauczą się współpracować
No tak, na temat zarządzania ludźmi w projektach napisano i radzono już wiele, wszędzie możemy usłyszeć hasła "zarządzanie przez cele", "komunikacja", "system motywacyjny" i wiele podobnych. Oczywiście zasady kryjące się pod tymi hasłami są same w sobie słuszne, ale z jakiś tajemniczych powodów nie chcą się często przełożyć na efektywny i bezkonfliktowy zespół projektowy (szczególnie jeśli mamy do czynienia z dużą, co najmniej kilkudziesięcioosobową grupą). Uniwersalnego przepisu nie ma, przynajmniej tak długo, jak nierealne jest precyzyjne zamodelowanie i przewidywanie zachowań ludzkich. W tym krótkim artykule chciałbym tym razem pominąć opisywanie procesów, metod, technik mierzenia i rozliczania itd., a w zamian poruszyć kilka różnorodnych zagadnień, bez rozwiązania których najlepsze nawet procesy nie będą działać. Z pewnością nie poruszymy wszystkich aspektów, postaram się jednak opisać te, które z mojego doświadczenia są istotnymi elementami mającymi wpływ na zachowania w zespołach i które w rezultacie mogą pomóc w naszym codziennym, projektowym życiu. Materiał przeznaczony jest zarówno dla ludzi zarządzających, jak i zarządzanych, szczególnie że kością niezgody bywa wzajemne niezrozumienie pomiędzy tymi grupami, ale o tym później.

Cube

Przykład do pierwszego zagadnienia zaczerpnąłem z filmu "Cube" (1997, Kanada, reż. Vincenzo Natali): Kiedyś uruchomiono bardzo ważny projekt, wielu ludzi przychodziło i odchodziło, któregoś dnia odszedł z projektu ostatni człowiek, który znał cel. Machina jednak działała dalej sprawnie, przychodziły kolejne zlecenia, płatności były regularne, więc pracowaliśmy dalej, bo każdy z nas znał swoją rolę. Tak powstał "cube", nie wiemy, ani co, ani po co to jest, ale projekt chyba się udał...

W dużych organizacjach trudno wymagać, aby każdy z pracowników ostatecznie identyfikował się z "najwyższym i jedynie słusznym celem", co więcej, takie wymaganie, z racji swojej utopijności (nikt nie będzie realizował z poświęceniem celu, na który nie ma całościowego wpływu, a odpowiedzialność zbiorowa to brak odpowiedzialności), jest niewłaściwe. Wielu menedżerów próbuje bezskutecznie wpoić swoim zespołom własny cel, osiągając przy tym "ambitne" poziomy frustracji. Często pojawia się charakterystyczne stwierdzenie "Ja się staram, a wam wszystkim nie zależy!", albo jeszcze gorzej "Z tym zespołem nie da się nic zrobić!".

Zawsze się da, to tylko kwestia umiejętności w zarządzaniu, co najwyżej może się to nie opłacać, ale to już zupełnie inny argument.

Trzeba zauważyć, że każdy projekt składa się z mniejszych projektów, schodząc aż do poziomu pojedynczego pracownika. Każdy z tych projektów ma swój cel często pozornie kompletnie niezwiązany z celem nadrzędnym (u pracownika - awans, u szefa działu - przemycenie innych prac pod płaszczykiem i w budżecie większego przedsięwzięcia). Sztuka polega zatem na umiejętności takiego pokierowania celami częściowymi, aby "przypadkiem" zrealizować to, co miało być zrealizowane. Istotne jest tu, aby zarządzać, a nie zwalczać. Energię ludzką trzeba kierunkować, a nie ją powstrzymywać.

Powyższy przykład z filmu, nieco przewrotny, pokazuje doskonałą organizację, gdzie każdy miał własny cel, motywację i miejsce. Zapomniany został jednak główny cel. Takie sytuacje mają miejsce w rzeczywistości, często jednak jest odwrotnie i takie przypadki zasilają ulubione przez firmy konsultingowe statystyki niepowodzeń.

Podsumowując: ludzie muszą znać cel projektu, mieć i rozumieć zależność pomiędzy własnym celem a powodzeniem całości oraz wiedzieć, jaką korzyść przyniesie im zrealizowanie własnego celu.

Wszyscy jedziemy na tym samym wózku

Jedną kwestią jest zrealizowanie własnych celów prowadzących do sukcesu, a inną, co się stanie w przypadku niepowodzenia projektu. Typowe w takich przypadkach jest "polowanie na czarownice", ponieważ rzetelne wskazanie "winnych" zazwyczaj nie jest możliwe. Kto i jak zatem powinien ponosić konsekwencje za porażkę? Naturalne i sprawiedliwe byłoby zapewne proporcjonalne do potencjalnych korzyści rozdanie "razów". Tak jednak w rzeczywistości (czy się nam to podoba, czy nie) nie jest. "Polityczne" zdolności i uwarunkowania powodują, że wielu ludzi (słusznie czy nie) czuje się bardziej pokrzywdzonymi, gdy innych zawsze omijają nieprzyjemności. Obawa przed niepowodzeniem jest w dużym stopniu przyczyną niepowodzenia. Zanim jeszcze zaistnieje realne niebezpieczeństwo, wielu z nas, niezależnie od pełnionej roli próbuje zawczasu "zabezpieczyć swoje interesy", co z góry powoduje konflikty i u zarania generuje potężne ryzyko projektowe. Objawem takiej choroby projektu jest przesadne stosowanie formalizmów, mających na celu jasne wskazanie, że "to nie ja".

Rozwiązanie tej kwestii jest niezwykle trudne. Kluczem do niego jest zrozumienie przyczyny. Typowo mogą one być trzy:

Strach - przewaga ryzyka nad potencjalnymi korzyściami (co ważne, istotne jest nie to, co myśli przełożony, ale odczucie indywidualne) - tu środkiem zaradczym może być opisywane poprzednio jasne uzgodnienie korzyści.

Brak wiary w powodzenie całości - no cóż, zespół, który nie wierzy w powodzenie, zapewne go nie osiągnie, rozwiązaniem może być zmiana osobowa na poziomie zarządu projektu oraz głośne, publiczne przedstawienie i realizowanie planu naprawy; bardzo wskazane jest pozyskanie osób zarządzających o dużej charyzmie, a błędne z reguły wybieranie kolejnego menedżera spośród istniejącego zespołu (to rodzi więcej konfliktów niż zalet mimo pozornej i ułudnej korzyści z tego, że "zna temat").

Brak zainteresowania powodzeniem - "Muszę to zrobić, bo mi kazali, mimo że przeszkadza mi to w mojej pracy" - no cóż, jeśli nie ma umiejętności czy możliwości zdefiniowania korzyści, pozostaje precyzyjne sformułowanie zadań i kryteriów sukcesu oraz jak najszybsze zakończenie współpracy w projekcie; konieczne jest też izolowanie takich postaw od reszty zespołu i jasne traktowanie takiej roli jako "czasowy, zadaniowy podwykonawca zewnętrzny".

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200