Podstępna natura zmiany

Zarządzanie projektem informatycznym często przypomina - ze względu na swoją dynamikę - strzelanie do ruchomego celu albo przyklejanie galarety do ściany.

Zarządzanie projektem informatycznym często przypomina - ze względu na swoją dynamikę - strzelanie do ruchomego celu albo przyklejanie galarety do ściany.

Takimi obrazowymi określeniami posługują się doświadczeni menedżerowie projektów, którym zmienność wymagań w projekcie nieraz uprzykrzyła życie, a którzy jednocześnie doskonale zdają sobie sprawę, że zmiany w projekcie są nieuchronne i dotyczą nie tylko wymagań, ale także narzędzi i środowiska pracy. Tak więc zmiany nie są dopustem Bożym w jakichś wyjątkowych przedsięwzięciach, lecz normą projektów sensownych, potrzebnych, zaspokajających rzeczywiste potrzeby, rozgrywających się w realnych ramach społecznych i organizacyjnych. Tylko wtedy bowiem istnieje presja na zmiany. Świadczy to o tym, że projekt przebiega w interakcji z otoczeniem i musi się z nim liczyć.

Obfite źródła zmian

Ze zmianami zatem nie należy walczyć, nie należy także udawać, że ich nie ma, nie są istotne albo że można sobie z nimi poradzić przy okazji rutynowych prac związanych z projektem. Zmiany pozostawione same sobie zde-zorganizują projekt do tego stopnia, że zagrożą jego terminowemu zakończeniu i zrealizowaniu celu, dla którego został zainicjowany. Do zarządzania zmianami w projekcie trzeba więc mieć odpowiednią metodologię. Obejmuje ona dostrzeganie i rejestrowanie zmian w otoczeniu projektu, wprowadzanie ich do projektu oraz przewidywanie konsekwencji merytorycznych, kosztowych, czasowych itd.

Są cztery obszary, w których występuje najwięcej zmian. Pierwszy obszar to personel, czyli pracownicy, menedżerowie, właściciele organizacji, w której realizowany jest projekt, ale także pracownicy klientów i partnerów. Projekt bowiem zwykle jest przeprowadzany w celu polepszenia kontaktów z nimi, zmniejszenia kosztów, usprawnienia komunikacji, trafniejszego określania wspólnych interesów itd. Każda nowa osoba w projekcie wprowadza do niego swoją wizję. Ma to szczególną wagę, gdy dochodzi do zmiany lidera projektu, jego sponsora czy kluczowych członków zespołu bądź osób poddanych zmianom lub przyszłych użytkowników, np. systemu jakości czy wdrażanego systemu informatycznego, na kierowniczych czy specjalistycznych stanowiskach. Mają oni większą siłę przebicia, są też bardziej zainteresowani projektem. Będą zatem wywierać presję, aby przebieg i cel projektu odpowiadał ich wizji. Nawet jeśli zmiana następuję na poziomie szeregowego pracownika, istnieje duże prawdopodobieństwo, że także on będzie interpretował projekt na swój sposób. Fakt, iż nie będzie tego publicznie demonstrował, może być jeszcze gorszym niebezpieczeństwem niż otwarta walka o wprowadzenie własnych reguł gry. Tworzy to podskórne, długo niezauważalne, a więc narastające zagrożenie dla projektu.

Drugim źródłem zmian jest budżet. Chyba wszyscy menedżerowie - mający na swoim koncie więcej niż jeden projekt - znają taką sytuację, gdy pieniądze, które były zarezerwowane na ich przedsięwzięcie, nagle zostały wycofane. Może się tak stać z wielu powodów, np. nagłych zmian na rynku, a więc reorientacji celów biznesowych, decyzji politycznych - jeśli jest to projekt w administracji, zmiany zarządu albo ofensywy zwolenników konkurencyjnych projektów. Ale najczęściej jest tak, że prawdziwych przyczyn nagłego ograniczenia środków nie sposób dociec, trudno więc opracować strategię przeciwdziałania. Pozostaje przygotować odpowiednie zmiany w merytorycznej warstwie projektu - odpowiednio go zredukować. Jest to istotnie ogromna sztuka. Regułą bowiem jest to, że zmniejszenie zakresu projektu wcale nie powoduje redukcji kosztów w takim samym stopniu, a w znacznie mniejszym.

Trzecie źródło zmian to technologia. Szefowie projektów informatycznych doskonale wiedzą, jak "daje im w kość" szybki postęp technologii informatycznych. Zmiany z nim związane można by wprowadzać niemal co tydzień. Trzeba wiedzieć, kiedy i dlaczego powiedzieć dość, aby z jednej strony nie wprowadzać rozwiązań przestarzałych technicznie, nie rokujących nadziei na rozwój, z drugiej - nie przekształcić projektu w nie ustający eksperyment, pracownię testowania nowości.

Czwartym obszarem twórczego - lub destrukcyjnego - niepokoju jest środowisko biznesowe. Wszystko, co tu się zdarza, może mieć wpływ na projekt. Sztuka zarządzania projektem polega na tym, aby selekcjonować to, co może i powinno zmieniać projekt, i oddzielać od tego, co powinno pozostawać poza zainteresowaniem zespołu projektowego. Wszelkie selekcjonowanie wiąże się z zagrożeniem, że wybór został uczyniony zbyt arbitralnie i zaprzepaszcza szansę na sukces. Jest to duże obciążenie psychiczne, a także zawodowe. Ale ryzyko i umiejętność podejmowania męskich decyzji są wpisane w zawód menedżera projektów.

Typowe sytuacje

Rozmaitość okoliczności, z którymi może spotkać się zarządzający projektem i jego zespół, jest tak duża, że nie sposób ich wszystkich opisać. Są jednak 4 typowe sytuacje, do których powinien być on przygotowany, gdyż prawdopodobieństwo ich wystąpienia jest bardzo duże.

Sytuacja 1. Projekt jest zakrojony na wielką skalę, a przez to kosztowny i angażujący wiele osób. Jego intencją jest np. poszerzenie możliwości biznesu, ponieważ właśnie poprawiła się koniunktura na rynku, albo zaspokojenie takich potrzeb obywateli, które nagle pojawiły się w związku z nasilaniem jakiegoś zjawiska społecznego, np. obsługi bezrobotnych w obliczu rosnącego bezrobocia lub pacjentów w przypadku reformy systemu służby zdrowia. Początkowo takim projektom towarzyszy wielki entuzjazm, potem jednak jego szefowie coraz bardziej odczuwają ciężar odpowiedzialności. Pilnie bowiem obserwują swoje środowisko i zaczynają wątpić, czy są podstawy do aż tak rozległego i kosztownego projektu. Przecież trendy gospodarcze czy społeczne, a także polityczne mogą się odwrócić.

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

TOP 200