Zmiany w organizacji projektu

Powyżej zarysowałem ogólny trend zmian jakie zachodziły i zachodzą na przestrzeni ostatnich kilkunastu lat, obecnie chciałbym się skupić na tym jaki wpływ miały te zmiany na strukturę organizacyjną projektów po stronie klientów, czyli organizacji będącej odbiorcą efektów projektu. Zmiany te można rozpatrywać z dwóch punktów widzenia. Pierwszy, który możemy nazwać formalno- organizacyjnym związany jest z wprowadzaniem w coraz szerszym zakresie formalnych metod zarządzania projektami, budowaniem struktury zespołów 5 Pod pojęciem użytkownika rozum iem y tutaj zarówno konkretne osoby bezpośrednio pracujące z systemami oraz osoby korzystające z rezultatów pracy systemów, ja k i całe jednostki organizacyjne wykorzystujące systemy informatyczne jako narzędzie realizacji swoich zadań, które dla odróżnienia od działów bezpośrednio związanych z IT, będziemy nazywać działami m erytorycznym i.

29

projektowych, nadawaniem różnego rodzaju organizacyjnego statusu projektom i innym działaniom, co wynika przede wszystkim z roli, jak ą projekty informatyczne zaczęły pełnić w ramach organizacji. Drugim ważnym czynnikiem była obsada poszczególnych stanowisk w zespołach projektowych, dokładniej wymagania kompetencyjne w stosunku do osób, które miały pełnić poszczególne role w ramach zespołu. W dalszej części tego rozdziału przedstawię zarys zmian związanych ze zmianami organizacyjnymi, a następnie skoncentruję się na drugim czynniku, który jest kluczowy dla dalszych rozważań.

Po początkowym, trwającym na szczęście stosunkowo krótko okresie, w którym zdarzało się, że większość działań organizacyjnych po stronie klienta sprowadzała się do wskazania osoby, która oprócz swoich normalnych zadań, miała za zadanie „zajmować się” projektem, dość szybko wprowadzono formalne ramy organizacyjne oparte na sprawdzonych wzorach i uznanych metodach6.

W zależności od wielkości projektu i jego wpływu na dalsze funkcjonowanie organizacji, projekt uzyskiwał również status organizacyjny: od poziomu wydzielonego w ramach pojedynczego działu zespołu ludzi, których głównym i często jedynym zadaniem było właściwe prowadzenie projektu, do poziomu wydzielonej jednostki organizacyjnej podlegającej bezpośrednio zarządowi, gdzie osoba odpowiedzialna za projekt często była członkiem zarządu. W początkowym okresie mieliśmy również dość często do czynienia z sytuacją, w której osoby oddelegowywane do projektów, jako tzw. konsultanci merytoryczni, były wybierane po części na zasadzie selekcji negatywnej. Dotyczyło to głownie działów merytorycznych, które nie angażując się w pełni w prace projektowe, niechętnie udostępniały swoich najbardziej kompetentnych pracowników. Praktyka taka nie trwała zbyt długo i codzienna praktyka, uświadomiła kierownictwu tych działów, że jeżeli chcą uzyskać satysfakcjonujący ich system informatyczny, muszą zaangażować w projekt swoich najlepszych pracowników, gdyż tylko oni są w stanie w sposób kompetentny współtworzyć przyszły system.

Odrębnym czynnikiem była obsada poszczególnych ról w ramach zespołów projektowych. Jak ju ż wspomniałem w początkowym okresie rozwoju liderami większości działań były działy IT, co znajdowało swoje odbicie w składzie zespołów projektowych. Główne role w zespole projektowym pełnili pracownicy działu IT. To do nich należało w większości podejmowanie decyzji o kierunkach prac, rozstrzyganie wątpliwości, ustalanie priorytetów, itd. Była to sytuacja naturalna, wynikająca z faktu, że przyszli użytkownicy nie posiadali wystarczającej wiedzy i doświadczenia, aby móc w sposób kompetentny kształtować wizję przyszłego systemu. Często użytkownicy, którzy nigdy wcześniej nie mieli do czynienia z technologią informatyczną, nie dysponowali wiedzą na temat możliwości tej technologii, nie byli w pełni przekonani o potrzebie bądź konieczności jej stosowania, a także nie potrafili wyobrazić sobie przyszłego systemu. W takiej sytuacji nie byliby oni równorzędnym partnerem dla

6 Często niem ałą rolę w tej zmianie odegrali dostawcy i wykonawcy systemów, którzy po początkowych, nie zawsze pozytywnych doświadczeniach, zaczęli gwarantować sobie w łaściwą organizację pracy ju ż na poziomie przygotowywania umowy.

30

dostawcy i wykonawcy systemu. Stąd pierwszoplanowe rolę brali na siebie pracownicy działów IT, którzy nawet jeżeli formalnie nie kierowali projektem, to w rzeczywistości odpowiadali za jego realizację i podejmowali większość decyzji.

Jak ju ż wspomniałem, sytuacja ta zaczęła ulegać zmianie pod koniec lat 90-tych. Globalna zmiana w podejściu do inwestowania w technologie informatyczne oraz rosnąca rola przyszłych użytkowników w kreowaniu projektów, połączona z ich rosnącą wiedzą, doświadczeniem i świadomością możliwości technologii informatycznych w zakresie zaspokajania ich potrzeb zmieniła obraz sytuacji. Rola działów IT z pozycji lidera zmian zaczęła się przesuwać w kierunku pozycji usługowej - dostarczyciela produktów i usług zgodnie z potrzebami działów meiytorycznych. Na poziomie globalnym organizacji można tą zmianę z punktu widzenia działów IT scharakteryzować następująco: zamiast realizować strategię informatyzacji należy współdziałać w realizacji strategii globalnej zgodnie ze strategią informatyzacji. Większość menadżerów IT ma świadomość tych zmian, o czym świadczą wyniki badań, gdzie te dwa zagadnienia czyli wspieranie strategii globalnej i pozycjonowanie działów IT jako usługowych w stosunku do pozostałych, znalazło się odpowiednio na drugim i trzecim miejscu wśród dziesięciu najbardziej priorytetowych zadań, wyprzedzone jedynie przez kwestię związane z obniżeniem i stabilizacją kosztów[l]a.i.4[l]a.i.5.

Mimo, że na pierwszy rzut oka zmiany te mogą wyglądać na niewielkie i rzadko przybierają postać formalnych zmian organizacyjnych, to często sięgają one bardzo głęboko. Pierwszym istotnym elementem jest wspominana wcześniej zmiana podejścia do przedsięwzięć informatycznych. Organizacje coraz niechętnej przeznaczają środki na działania o charakterze ogólnym jak np. budowa infrastruktury. Zamiast tego przyznają środki na realizację konkretnych przedsięwzięć. Podstawą decyzji nie są już jedynie kwestie mody i prestiżu, ale przewidywane korzyści precyzyjnie udokumentowane i wyliczone, wśród których argumenty ekonomiczne są jednym z najważniejszych kryteriów decyzyjnych.

Inaczej mówiąc w świadomości wyższego szczebla zarządczego wykształciło się przekonanie że inwestycje w IT , jak wszystkie inne, muszą być ekonomicznie uzasadnione. Zmieniło się również podejście do kwestii organizacji przedsięwzięć:

często środki są przyznawane nie na realizację konkretnego projektu, który z założenia jest przedsięwzięciem czasowym, lecz na rozwiązanie konkretnych problemów i zaspokojenie konkretnych potrzeb. I kolejna bardzo ważna zmiana - środki są przyznawane w ramach budżetów celowych, często będących w dyspozycji użytkownika, a nie działu IT. Wytwarza to dodatkową presję na użytkowników, aby wydatkowane środki przyniosły konkretny wymierny efekt końcowy. Zmiany te nie spowodowały formalnych zmian w strukturze organizacyjnej projektu - dalej wiele stanowisk obsadzają pracownicy działu IT, często na kierowniczych stanowiskach, ale decydujące zdanie należy do odbiorcy systemu i jego przyszłego użytkownika. Rola działu IT sprowadza się do roli doradcy technologicznego, pilnującego zgodności ze standardami organizacyjnymi, natomiast priorytety i kryteria podstawowe określa użytkownik. Jeżeli pracownicy działu IT pogodzą się z taką sytuacją, która w stosunku do wcześniejszej, wiodącej

31

roli stanowi pewnego rodzaju degradację, to przy ich pełnym zaangażowaniu i identyfikacją z projektem, w sposób naturalny stają się pomostem pomiędzy wykonawcą i użytkownikiem - pomostem, który dodatkowo wnosi do projektu kompetencje w zakresie metod prowadzenia projektów, wymuszając ich przestrzeganie przez obie strony. W takiej modelowej sytuacji, przedstawiciele działu IT stają się istotnym czynnikiem powodzenia.

Gorzej jeżeli kwestie ambicjonalne wezmą górę nad celem jakim jest końcowy wspólny sukces projektu. Próby budowania własnej dominującej pozycji w projekcie, wynikające z wcześniejszych doświadczeń i przyzwyczajenia, nie zasięganie opinii użytkowników bądź lekceważenie ich stanowiska oraz próby tworzenia barier pomiędzy użytkownikiem, a wykonawcą, może doprowadzić do sytuacji, w której stworzony system spełnia wszystkie założenia projektu, lecz nie spełnia oczekiwań użytkownika.