Konflikt w zespole projektowym

Jak wspomniałem, zmiana roli poszczególnych działów w ramach zespołu projektowego, może prowadzić do powstania konfliktu ambicjonalnego. Konflikt ten może przebiegać na dwóch poziomach: organizacyjnym i indywidualnym. W pierwszym przypadku terenem konfliktu jest cała organizacja, a konflikt w projekcie jest jedynie skutkiem szerszych sporów. W drugim przypadku, źródłem konfliktu są ambicje pojedynczych osób z zespołu projektowego, które w zależności od tego czy konflikt obejmuje całą organizację czy nie, działają z poparciem bądź bez poparcia swoich przełożonych. Kolejnym ważnym czynnikiem jest poziom nasilenia konfliktu: czy przebiega on w sposób ukryty dając o sobie znać tylko co jakiś czas, czy jest raczej zjawiskiem permanentnym, którego przejawy możemy zaobserwować na każdym kroku. W zależności od sytuacji możemy spotkać się z następującymi symptomami:

> częste spory występujące pomiędzy członkami zespołu projektowego, nie zawsze dotyczące spraw istotnych, w skrajnych przypadkach mający charakter pozamerytoryczny,

> organizowanie spotkań w podgrupach, bez wszystkich zainteresowanych danym zagadnieniem, przy bagatelizowaniu stanowiska osób nieobecnych, próby kanalizowania kontaktów pomiędzy użytkownikami a wykonawcą,

> brak chęci współpracy pomiędzy członkami zespołu projektowego ze strony klienta, przeciągające się kwestie uzgodnień czy też, zajęcia konkretnego stanowiska,

> brak jednoznacznie określonych kompetencji lub niepoczuwanie się do nich, odwlekanie decyzji lub uzależnianie ich od stanowiska innych osób, często nie będących członkami zespołu projektowego,

> wyraźnie bierna i wyczekująca postawa osób, które z racji pełnionych funkcji powinny być aktywne i zaangażowane,

> wzajemne podważanie kompetencji przez członków zespołu projektowego, żądania potwierdzania ich opinii i decyzji przez ich zwierzchników,

32

> przenoszenie decyzji operacyjnych na poziom Komitetu Sterującego w sytuacjach tego niewymagających,

> brak inicjatywy, ograniczanie się jedynie do realizacji poleceń.

Nie są to oczywiście wszystkie możliwe symptomy, jak również ich pojawienie się nie musi oznaczać występowania omawianego konfliktu. Niemniej jednak zaistnienie takich zachowań lub ich nasilanie się, powinno być sygnałem dla wykonawcy, że należy dokładniej rozważyć taką możliwość i wziąć to pod uwagę, jako istotny czynnik ryzyka.

Kolejnym ważnym zagadnieniem, są możliwe skutki zaistnienia konfliktu personalnego w zespole projektowym po stronie klienta. Z najpoważniejszych konsekwencji można tu wyliczyć:

> rozminięcie się z oczekiwaniami i potrzebami użytkowników, nieuwzględnienie zmian jakie zaszły w trakcie trwania projektu, a w dalszej kolejności konieczność dokonywania zmian wj u ż gotowym oprogramowaniu, w końcowej fazie prac,

> paraliż decyzyjny, objawiający się niechęcią do podejmowania decyzji operacyjnych, odwlekaniem tych decyzji czy przenoszeniem ich na wyższe poziomy struktur projektowych /kierownictwo projektu, komitet sterujący/ lub wręcz poza te struktury,

> niemożność szybkiego i skutecznego uzgodnienia kwestii szczegółowych, brak szybkiego dostępu do istotnych informacji lub mnożenie przeszkód proceduralnych w dostępie do nich,

y wielokrotnie zmienianie założeń i wymagań, kwestionowanie wcześniejszych uzgodnień.

Wszystkie te zjawiska w konsekwencji prowadzą do zagrożenia możliwości zakończenia projektu sukcesem. Zagrożone są wszystkie podstawowe kryteria sukcesu czyli funkcjonalność, czas i koszty. Paraliż decyzyjny oraz niemożność szybkiego i skutecznego uzgodnienia kwestii szczegółowych powoduje, że projekt już od samego początku zaczyna się opóźniać w stosunku do harmonogramu. Optymizm dostawcy połączony z deklaracjami klienta o chęci współpracy sprawia, że początkowe niewielkie opóźnienia tłumaczone są jako skutek braku zgrania zespołu projektowego i przedstawiane jako możliwe do nadrobienia w kolejnych etapach. W miarę narastania opóźnień pojawiają się argumenty o czynnikach obiektywnych lub następuje faza, w której strony konfliktu obarczają się wzajemnie odpowiedzialnością za powstałą sytuację, w często w końcowym etapie starają się przerzucić całą odpowiedzialność na dostawcę, który powinien przewidzieć zaistniałą sytuację i uwzględnić ją w harmonogramie. Z punktu widzenia dostawcy systemu, każde opóźnienie oznacza dodatkowe koszty, szczególnie dotkliwe gdy wynikają np. z braku decyzji, która powinna być już dawno podjęta. Wpływa to również na morale zespołu wykonawczego, który najpierw czeka na podjęcie decyzji, a później próbuje z różnym skutkiem nadgonić stracony czas. Z kolei rozmijanie się z oczekiwaniami użytkowników i częste zmienianie założeń powoduje, że mimo iż projekt początkowo przebiega zgodnie z harmonogramem, to rośnie ilość pracy do wykonania w kolejnych etapach. W konsekwencji spiętrzenie problemów pojawia

33

się w końcowych etapach projektu i również skutkuje opóźnieniami w zakończeniu projektu.

Czy można przeciwdziałać pojawieniu się konfliktu i jego skutkom?

Oczywiście że można i należy przeciwdziałać, choć trzeba mieć świadomość, że nie jest to łatwe, gdyż z subiektywnego punktu widzenia wszystkim członkom zespołu projektowego zależy na sukcesie, z tym że poza bezdyskusyjnymi aspektami, postrzegają oni ten sukces w różny sposób. Oznacza to w szczególności, że trudno jest wskazać pojedyncze, konkretne działania szkodzące projektowi, gdyż przeważnie łatwo jest je uzasadnić dbałością o projekt lub uzasadnionymi wątpliwościami. I jest to po części prawda, bo działania te nie są kierowane „przeciwko” projektowi, lecz przeciwko pojedynczym osobom lub grupom osób, czasami nawet nie zaangażowanym bezpośrednio w projekt.

Dodatkowo osoba podejmująca takie działania może nie być świadoma skutków, jakie mają one dla projektu. Niemniej jednak suma skutków takich pojedynczych

działań może skazać projekt na porażkę.

Konflikt w zespole projektowym jest znanym czynnikiem ryzyka i jako taki był już wielokrotnie opisywany w pracach związanych z zarządzaniem zespołem projektowym. Różnica tkwi jedynie w źródłach konfliktu. Oznacza to, że w najprostszym przypadku, gdy mamy do czynienia jedynie z konfliktem ambicjonalnym na poziomie pojedynczej osoby, możemy z powodzeniem stosować znane już metody. Przykładowo najskuteczniejszą metodą jest zastąpienie jej inna osobą lub gdy nie jest to możliwe, zabezpieczanie się przed możliwymi skutkami, starając się wyprzedzać pewne działania i unikać sytuacji mogących prowadzić do wystąpienia spraw ambicjonalnych?. Znacznie poważniejsza sytuacja ma miejsce, gdy skala konfliktu obejmuje całą organizację.

Wtedy jedyną metodą poradzenia sobie z problemem, jak ą można zaproponować, jest próba jego lokalnego złagodzenia w ramach realizowanego projektu. Oznacza to, że dostawca, oprócz wszystkich innych zadań, musi wziąć na siebie rolę mediatora i pośrednika pomiędzy użytkownikami, a pracownikami działu IT zaangażowanymi w projekt. Nie może on równocześnie liczyć na znaczące wsparcie w realizacji tego zadania ze strony organizacji i jej kierownictwa, a wręcz przeciwnie musi się liczyć z działaniami, które będą w tym przeszkadzać. Czy oznacza to że, jest skazany na porażkę? Nie, choć musi się liczyć z taką ewentualnością. W takiej sytuacji bardzo dużo zależy od pojedynczych osób, poziomu ich zaangażowania i identyfikacji z projektem, a w konsekwencji podejmowania działań nie zawsze zgodnych ze stanowiskiem ich formalnych przełożonych.

7 Więcej informacji na tem at możliwych sposobów przeciwdziałania powstawaniu i skutkom różnych czynników ryzyka można znaleźć m.in. w [l]a.i.6 [l]a.i.7.

Przedstawione sposoby działania obejm ują znacznie szersze aspekty, lecz znaczną część z nich można z powodzeniem stosować w analizowanym przez nas konflikcie.

34

3. Podsumowanie

Obecna sytuacja na rynku, charakteryzująca się bardzo wysokim poziomem konkurencji między dostawcami, sprawia że harmonogram projektu i jego koszty, rzadko i w niewielkim stopniu uwzględniają rezerwę na zajście zjawisk niezaplanowanych, a trudno planować konflikt w zespole projektowym u klienta. Nawet jeżeli dostawca ma świadomość istnienia takiego konfliktu, to uwzględnienie go na poziomie oferty czy negocjacji umowy jest praktycznie niemożliwe. Dodatkowo, większość obecnie podpisywanych umów to umowy na dzieło, które rozliczne są na zasadzie efektu, a nie nakładu i czasu pracy. Oznacza to, że z punktu widzenia klienta najbardziej zagrożone jest terminowe zakońtzenie projektu, natomiast z punktu widzenia dostawcy jego efekt ekonomiczny, gdyż przedłużające się prace oznaczają dodatkowe koszty, nie zawsze rekompensowane przez dodatkowe wpływy. Reasumując, szybkie wykrycie istnienia konfliktu w zespole projektowym i podjęcie wszelkich działań przeciwdziałających jego skutkom, jest ważnym czynnikiem mogącym zapewnić zakończenie projektu sukcesem, zarówno z punktu widzenia użytkownika jak i dostawcy.

W niniejszym artykule skoncentrowałem się jedynie na jednej z możliwych przyczyn powstawania konfliktów w zespole projektowym. Nie jest to jedyna możliwość i konflikty takie wcale nie muszą mieć miejsca tylko po stronie klienta, lecz jest to nowy czynnik, z którym spotkałem się już kilkukrotnie w mojej praktyce zawodowej. Rodzi on duże problemy i może być brzemienny w skutkach, wydaje się jednak że ma on charakter przejściowy i że jego znaczenie oraz możliwość wystąpienia powinna w miarę upływu czasu maleć.

Literatura

1. D.Konowrocka „Informatyka do zwrotu”, Computerworld nr.28/536, 29 lipca 2002

2. D.Konowrocka „ROI i kwadratura koła”, Computerworld nr. 15/571, 14 kwietnia 2002

3. L.Maśniak „ Walka z uzależnieniem”, Computerworld nr.9/565, 3 marca 2003 4. D.Konowrocka , JColeiny rok na starcie,\ Computerworld 7/563,

17 lutego 2003

5. I.D.Bartczak „Dylematy dla zaawansowanych”, Computerworld 16/524, 22 kwietnia 2002

6. B.Czarnacka-Chrobot p rzy c zyn y niepowodzeń projektów informatycznych - z kronik chaosu Standish Group” Efektywność zastosowań systemów

informatycznych, tom III, str. 55-69, Szczyrk 2001, wyd. WNT Warszawa 7. E.Yourdon „Marsz ku klęsce -p o rad nik dla projektanta systemów”, WNT

Warszawa 2000 Dr Dariusz Dymek

Akademia Ekonomiczna w Krakowie Katedra Informatyki

e-mail: eidymek@cyf-kr.edu.pl

35

, ' W T ( i , t i 4 é - ^ 1 ^ / k ! Í ' S

-^:?‘ÍS.vK;:S ' % ' ; , « ? ? { ■ & " - : ^ V ' V i r a r r ^ - i - V ^ J-'iïÿ :; ' \K p í.;¿ í W . X V í ^ ’ i í v . v ^ - ^ i

. • ' ' r - . 1' '- • -__ . 1...• '..-;V -V j;-,í * ■ . i , V « : .■:••■■■ - • ' .. , . ■ ■ j << '

V A * & C ’ 1 > , ^ - ■ * ~ ' •'■* '■" ^ ' í r v V ” i

-.iA ^{i f - f} '- Y^ ■ ; Y , ; ' ■■:, 7 :''c- ; ' ;

TECHNOLOGIA ARKUSZA KALKULACYJNEGO