Wespół w zespół

Nie istnieją jedynie słuszne zasady dobierania członków zespołu projektowego. Tworzenie go zawsze wiąże się z ryzykiem natknięcia się na niekompetencję lub brak dobrej woli. Długo trwające projekty wypalają pracowników, z biegiem czasu coraz trudniej jest utrzymać wysoki poziom motywacji, zespół coraz bardziej się zżywa, ale jednocześnie narastają konflikty. Jest to nieuniknione, ponieważ zespoły w projektach informatycznych składają się z przedstawicieli działów firmy mówiących różnych językiem - od konstruktora technologa przez specjalistę od marketingu do pracowników działu księgowości. Jeśli zbyt długo nie widać efektów pracy, niektórzy mogą odejść. Zdaniem doświadczonych kierowników projektów, wymiana nawet 30% całego zespołu w czasie trwania projektu nie stanowi jeszcze zagrożenia, o ile ciężar wdrożenia i wiedza o projekcie nie spoczywa na dwóch, trzech specjalistach. "Jeśli projekt jest przewidziany na trzy lata, należałoby tak go zaplanować, by w ciągu roku zakończyć etap stanowiący pewną logiczną całość, a w ciągu następnych dwóch lat system rozbudowywać i usprawniać. Inaczej narażamy się na dużą rotację członków zespołu projektowego, zniechęconych brakiem efektów pracy, i być może konieczność redefiniowania rozciągniętego w czasie projektu" - wyjaśnia Andrzej Sieradz. Wiele projektów pada ofiarą słabo określonych struktur organizacyjnych, zakresów odpowiedzialności poszczególnych członków zespołu. Wskutek tego w niektórych dziedzinach brak jest osób odpowiedzialnych, w innych chętnych do podejmowania decyzji jest zbyt wielu. "Przed rozpoczęciem prac wykonawczych musi istnieć dobrze zdefiniowana ścieżka określająca kolejne etapy projektu. Inaczej możemy mieć do czynienia z ukrytą walką kompetencyjną między kierownikami poszczególnych grup projektowych, którzy w trakcie projektu mogą próbować forsować własne rozwiązania. Stawia to w trudnej sytuacji ciągłych wyborów kierownika całego projektu i powoduje niezadowolenia w zespole" - mówi kierownik jednego z dużych projektów.

Czy ryzykować ryzyko?

Czasem doprowadzenie do sytuacji kryzysowych może być wręcz pożądane. Jednym z najważniejszych czynników określających powodzenie całego projektu jest prawidłowe zbudowanie początkowych założeń, określenie spójnych celów wdrożenia i osiągnięcie zrozumienia istoty całego wdrożenia przez najważniejsze strony projektu: zarząd przedsiębiorstwa, końcowych użytkowników reprezentujących poszczególne jego części i członków zespołu projektowego ze strony dostawcy rozwiązania. Często zrozumienie jest pozorne, a w zespole projektowym znajdują się ludzie przeciwni zmianom. "Jeden z naszych projektów zakończył się niepowodzeniem ze względu na początkową nie ujawnioną niezgodność interesów w obrębie przedsiębiorstwa i niezrozumienie zakresu i celów wdrażanego systemu. Nie doceniliśmy wagi czynników mentalnych i socjologicznych, koncentrując się na wskaźnikach, harmonogramach i wysokości budżetu" - stwierdza Bogumił Dałkowski. Doprowadzenie do sytuacji konfliktowej i otwartej konfrontacji stanowisk pozwoli wcześnie ujawnić popełnione błędy i skorygować podjęte decyzje.

Deficyt informacji

Kluczem do zarządzania ryzykiem jest ciągła obserwacja środowiska projektu, pozyskiwanie nowych informacji i otwarta komunikacja ze wszystkimi osobami nim zainteresowanymi. Ryzyko wynika właśnie z działania w warunkach niepełnej informacji, a zarządzanie nim jest "przemianą nieznanego w znane". Sama jednak komunikacja jest źródłem wielu problemów. Stworzenie rozwiązania nie przystającego funkcjonalnie do profilu przedsiębiorstwa zazwyczaj jest wynikiem braku zrozumienia między posługującymi się językiem technicznym dostawcami rozwiązania a nastawionymi biznesowo jego końcowymi użytkownikami, którzy często nie są w stanie wskazać potrzeb, skazując dostawcę na tworzenie prototypów metodą prób i błędów. Dlatego często uznaje się, że podstawową cechą dobrego kierownika projektu powinna być umiejętność komunikowania się, pozyskiwania odpowiednich informacji i przekazywania ich odpowiednim osobom. Możliwość aktualizacji planu ryzyka zależy od tego, czy we właściwym momencie człowiek, który zauważył niepokojące symptomy narastania problemów, przekaże tę informację szefowi projektu i co on z nią zrobi. Ale do tego tak naprawdę nie wystarczy stworzenie odpowiednich struktur przepływu informacji. Potrzebna jest dojrzałość wszystkich osób biorących udział w projekcie, autentyczne zainteresowanie, zaangażowanie i poczucie odpowiedzialności za losy projektu.