Badanie 1-R. Zasadności definiowania struktur projektowych

Badanie zostało przeprowadzone w ramach projektu pilotażowego wdrożenia systemu Rational Team Concert (RTC) w firmie PSE INFO. W realizację projektu zaangażowany był zespół powołany w Zakładzie Zarządzania Technologiami Informatycznymi Politechniki Gdańskiej na zlecenie dostawcy oprogramowania RTC — firmy IBM. Projekt realizowany był od stycznia 2009 r. do końca lipca 2009 r. Założenia do badania 1-R przedstawiono w tabeli 5.2

Tabela 5.2 Założenia do badania 1-R

Kod badania 1-R

Cel Celem badania jest weryfikacja zasadności definiowania struktur projektowych przez kierowników projektów.

Środowisko badania

Projekt wdrożenia oprogramowania do zarządzania projektami dla klienta z krajowego sektora energetycznego.

Początek realizacji Marzec 2009 Zakończono Termin

zakończenia

Wrzesień 2009 Zakończono

Źródło: opracowanie własne

Opis przebiegu badania

Przeprowadzone badanie miało na celu wykazanie, jak złożona może być struktura projektowa poprzez wykazanie istnienia możliwych elementów tej struktury. Oznacza to zatem, że weryfikując warstwę wiedzy na poziomie definiowalnym modelu szczegółowego a2M należy sprawdzić możliwość wyodrębnienia podstawowych elementów struktury, które następnie należy przekształcić do postaci agentów opisywanych cechami oraz zachowaniami.

Klient omawianego projektu, w ramach którego przeprowadzano eksperyment, oczekiwał rozwiązania usprawniającego przepływy pracy (tzw. workflow) podczas realizacji przez niego różnych projektów (również informatycznych) na własne potrzeby. Oczekiwania klienta ukierunkowane były przede wszystkim na zastosowanie takiej technologii, dzięki której podniesie się komfort pracy zespołowej. Oczekiwano również usprawnienia komunikacji w zespole oraz usprawnienia przepływu dokumentów.

W związku z problemami organizacyjnymi klient omawianego projektu zwrócił się z prośbą o wdrożenie produktu do dostawcy oprogramowania (firmy IBM). W celu usprawnienia procesów w organizacji klienta zaproponowano wdrożenie oprogramowania Rational Team Concert oraz zmodyfikowanie tego narzędzia do potrzeb klienta. Jednocześnie dostawca oprogramowania zwrócił się do jednostki naukowo-badawczej, jaką jest Zakład Zarządzania Technologiami Informatycznymi, z propozycją przeprowadzenia pilotażowego wdrożenia oprogramowania RTC. W Zakładzie prowadzono prace badawcze nad tymi technologiami i dysponowano specjalistami. Stąd też jednostka naukowo-badawcza reprezentowała dostawcę oprogramowania.

Na podstawie podanego opisu stwierdzono obecność podstawowych elementów struktury projektowej, które występują w rzeczywistych projektach:

 organizacja klienta, która ma problemem z wdrożeniem systemu informatycznego,

 dostawca oprogramowania, która udostępnia swój produkt,

 jednostka naukowo-badawcza, która może wesprzeć realizację projektu informatycznego swoimi zasobami (pracownicy i studenci).

Kolejnym ustaleniem w ramach omawianego projektu było powołanie organu mającego nadzorować przebieg projektu. W skład tego organu wchodziły trzy osoby — po jednej z każdej organizacji zainteresowanej realizacją omawianego projektu. Przy czym ustalono, że prace związane

z wdrożeniem zostaną powierzone młodym zespołom złożonym ze studentów, którzy zrealizują zadania w ramach praktyk ukierunkowanych na zdobycie doświadczenia projektowego. Jednocześnie uznano, że należy wyłonić osobę zarządzającą projektem, która będzie organizować pracę zespołom studentów. Z uwagi na rozwojowy charakter projektu oraz konieczność integracji nowo wdrażanego systemu z istniejącymi już w organizacji klienta, powołano 3 zespoły projektowe.

Badanie miało na celu wyłonienie wszystkich elementów struktury projektowej, które zostaną wyodrębnione podczas ustaleń pomiędzy klientem a dostawcą. Jak wynika z podanego opisu, projekt realizowany był w oparciu o strukturę złożoną z organu zarządzającego projektem (analogia do agentowego systemu zarządzania).

Należy dodać, że w trakcie realizacji projektu struktura projektowa została poddana modyfikacjom w wyniku kolejnych ustaleń między dostawcą a klientem. Powołano kierownika podległego organowi nadzorującemu i powierzono mu kierowanie pracami trzech kilkuosobowych zespołów w ramach tego projektu. Stwierdzono istnienie złożonej struktury projektowej składającej się z podmiotów powiązanych relacjami hierarchicznymi oraz potwierdzono, że kierownik projektu uwzględniał potrzebę takich struktur w zarządzanym przez siebie projekcie informatycznym.

Po zdefiniowaniu podstawowych ról projektowych w ramach zespołów kierownik wyznaczył również liderów poszczególnych grup, których zadaniem było monitorowanie postępów i kierowanie pracami powierzonych im zespołów. Oprócz organu nadzoru, kierownika i zespołów pojawili się także liderzy prowadzący pomniejsze grupy projektowe. Okazało się również, że przedstawiciel klienta wchodzący w skład organu nadzorującego prace nie jest w stanie uczestniczyć w pracach projektowych i wydelegował do tego celu dwóch pracowników działu informatycznego. Stąd też pojawił się w projekcie zarówno przedstawiciel klienta, jak i przedstawiciel użytkownika końcowego.

Uznano również, że w celu lepszej organizacji zadań związanych z wdrożeniem nowego oprogramowania w firmie klienta, dostawca (producent) oprogramowania zapewni wsparcie techniczne, powołując ze swojej strony dwóch mentorów, którym powierzono wspieranie zespołów projektowych podczas wdrażania wspomnianego oprogramowania. W ten sposób struktura projektowa powiększyła się o kolejne osoby, które bezpośrednio nie wchodziły w skład zespołu, ale stały się podmiotami zainteresowanymi przebiegiem projektu. Mentorzy powołani przez firmę IBM stanowili więc ekspertów dziedzinowych w rozumieniu modelu agentowego. Zgodnie z założeniem, że struktury projektów są coraz bardziej rozbudowane, a kierownicy powinni je dokładnie analizować przed dobraniem dobrych praktyk zarządzania projektami informatycznymi, przystąpiono do definiowania tej struktury. Kierownik projektu przygotował odpowiednie dokumenty pokazujące rolę każdego uczestnika w realizowanym projekcie.

Okazało się także, że klient nie do końca jest w stanie określić sposób funkcjonowania swojej organizacji za pomocą oferowanych na potrzeby zarządzania technologii. Stąd też jeden z trzech zespołów projektowych przygotował warianty wykorzystania technologii, które zaprezentował klientowi w celu wybrania najlepszego. Przygotowanie wariantów spowodowało jednak to, że pojawiło się zapotrzebowanie na odpowiednie modele ocenowe tych technologii, które posłużyły do wartościowania przedstawianych klientowi rozwiązań. Jednocześnie podczas prezentacji wariantów rozwiązań dla klienta poproszono o wsparcie pracowników Zakładu w celu weryfikacji proponowanych przez zespoły wariantów. W ten sposób struktura omawianego w eksperymencie projektu rozszerzyła się o kolejne nowe osoby. Zauważono także, że zwykła struktura projektowa składająca się z klienta, zespołu i kierownika nie jest wcale taka oczywista i może składać się z wielu innych powiązanych elementów.

Wnioski

Tak przeprowadzone badanie wykazało znaczenie struktury projektowej dla planowania i realizacji późniejszych zadań w projekcie. Pozwoliło na identyfikację poziomu definiowania modelu szczegółowego a2M oraz warstwy wiedzy. Wskazało także na tworzenie struktur hierarchicznych

typowych dla poziomu zarządzania. Wskazało także na mechanizmy tworzenia poziomu zarządzania modelu szczegółowego a2M, który w analizowanym projekcie ma charakter iteracyjny. Nie stwierdzono istnienia w realizowanym projekcie poziomu adaptacji. Nie stwierdzono także istnienia procesów adaptacyjnych. W tabeli 5.3 zebrano wyniki badania 2-R

Tabela 5.3 Wnioski z badania 1-R

Kod badania: 1-R

Realizacja celu badania

Cel badania osiągnięty

Zidentyfikowane poziomy modelu szczegółowego a2M

Definiowania

Zarządzania Nie istnieją

procesy adaptacji Zidentyfikowane

warstwy modelu szczegółowego a2M

Wiedzy

Przetwarzania Nie istnieją

procesy adaptacji Źródło: opracowanie własne

Zgodnie w powyższymi wnioskami zastanawiano się, jak przeprowadzone badanie wpływa na strukturę modelu szczegółowego a2M. Niewątpliwie potwierdzono, że w najniższej warstwie modelu wspierającego zarządzanie projektami należy definiować wszystkie składniki, co do których kierownik projektu może podejmować późniejsze decyzje. Pozostaje jednak pytanie, jak kierownik może tę strukturę definiować oraz jakie zastosować działania, aby zapewnić właściwą współpracę w ramach tak złożonych struktur. Przeprowadzone badanie potwierdziło słuszność definiowania struktury projektowej, ale wykazało, że niektóre elementy tej struktury (jak mentorzy — eksperci) pojawiają się już po rozpoczęciu projektu.

Przeprowadzone badanie wykazało, że należy nie tylko analizować i definiować struktury w projektach informatycznych, lecz jeszcze należy uwzględniać ich dynamikę. Struktura bowiem może się zmieniać, ulegać modyfikacjom w czasie i zmieniać swój poziom złożoności. Badanie wykazało także jak złożona może być taka struktura projektowa i jakie interakcje mogą zachodzić pomiędzy tymi elementami. Mogą być one odwzorowane poprzez relacje hierarchiczne (jak opisana podległość kierownika projektu wobec organu nadzoru czy podległość liderów względem kierownika), ale również jako relacje oparte na przepływie wiedzy, jak relacja pomiędzy mentorami a członkami zespołów. Stąd też zasadne wydaje się, aby model szczegółowy a2M uwzględniał również relacje, co założono na poziomie zarządzanym modelu i co stanowić będzie podstawę weryfikacji w kolejnych badaniach.

Ważnym wnioskiem płynącym z przeprowadzonego eksperymentu jest również możliwość identyfikacji elementów struktury projektowej, które są w stanie dostarczać merytoryczną wiedzę osobom uczestniczącym. Ten wniosek jest istotny z dwóch powodów. Po pierwsze stanowi wskazówkę dla kierownika projektu, aby uwzględnić możliwość korzystania z wiedzy i doświadczenia mentorów (zapotrzebowanie na AGENTA EKSPERTA). Po drugie obecność takich osób w projekcie świadczy o tym, że struktury projektowe mają charakter dynamiczny, czyli mogą zmieniać się w czasie. Potwierdza to potrzebę włączenia mentorów w omawianym badaniu.

Wnioskiem, który także wynika z przeprowadzonego badania, jest fakt, że w projekcie informatycznym może nastąpić zapotrzebowanie nie tylko na osoby dostarczające wiedzę, ale również na inne źródła wiedzy oraz technologie informatyczne wspomagające realizację zadań w projekcie.

Takim źródłem wiedzy wykorzystanym w badaniu były np. modele ocenowe pozwalające na wartościowanie wariantów rozwiązań przedstawianych klientowi. Takim źródłem wiedzy może też być zestaw dobrych praktyk zarządzania projektami zawarty w formalnych metodach zarządzania projektami.

5.1.2 Badanie 2-R. Ocena możliwości identyfikacji elementów struktury projektowej