PManager.pl

W ramach mojego ostatniego projektu realizowałem szkolenie użytkowników. Szkolenie obejmowało 90 osób z całej Polski. W ramach szkolenia należało przenieść infrastrukturę IT (serwer, sieć, 16 stanowisk komputerowych) do wynajętej sali szkoleniowej, przygotować materiały, scenariusze szkolenia, zorganizować catering, zapewnić logistykę (transport, zakwaterowanie), sporządzić grafik dla trenerów. Ten etap projektu został rozpisany na prawie 40 pakietów prac. Przygotowania trwały ponad miesiąc. Samo szkolenie trzy dni. Przy okazji tych działań naszła mnie refleksja na temat tego, co tak naprawdę wchodzi w zakres projektu informatycznego.

Metodyki zwinne zarządzania projektem takie jak SCRUM, skupiają się na procesie wytwórczym oprogramowania. Jednak z punktu widzenia zdefiniowanego na poziomie uzasadnienia biznesowego celu bezpośredniego projektu samo oprogramowanie jest tylko jednym z celów produktowych. Być może najważniejszym, ale na pewno nie jedynym. Biorąc pod uwagę uzasadnienie biznesowe projektu informatycznego samo wytworzenie oprogramowania i zainstalowanie go w infrastrukturze IT klienta nie zapewni zaspokojenia potrzeby biznesowej, która jest bezpośrednim wyzwalaczem wszystkich działań, które zwykliśmy nazywać projektem. W ramach realizacji projektu informatycznego, poza wytworzeniem oprogramowania zwykle podejmujemy czynności noszące znamiona projektu organizacyjnego czy też inwestycyjnego:

• Szkolimy użytkowników
• Tworzymy dokumentację
• Rozbudowujemy infrastrukturę IT
• Modyfikujemy wspierane przez oprogramowanie procesy biznesowe

Z tego punktu widzenia zarządzanie projektem IT przy użyciu metodyki, która opisuje tylko i wyłącznie proces wytwórczy oprogramowania wydaje się być nadużyciem. Z tego też powodu uważam, że efektywne zarządzanie projektem IT wymaga podejścia, które stanowi połączenie elementów podejścia zwinnego na poziomie wytwarzania oprogramowania z uniwersalną metodyką pozwalającą zarządzać ogółem działań związanych z realizacją celu bezpośredniego będącego odzwierciedleniem uzasadnienia biznesowego projektu. Takie podejście zapewni odpowiednią elastyczność na poziomie wytwarzania oprogramowania a jednocześnie pozwoli na pełną kontrolę rzeczywistego zakresu projektu.

Podejście takie nie jest niczym nowym – w literaturze i opracowaniach możemy spotkać się z takimi pojęciami jak APF – Adaptive Project Framework, czy też XPRINCE – eXtremal PRINCE. Takie podejście wymaga od Project Managera dużej elastyczności a wręcz tolerancji w stosunku do stojących na dwóch przeciwległych biegunach podejść do zarządzania projektem: tradycyjnego i zwinnego tak, żeby wybrać z nich to, co najlepsze.

Moim zdaniem kluczem do pogodzenia tych dwóch koncepcji jest zasada związana z planowaniem etapu w metodykach tradycyjnych. Podstawową jednostką pracy do której planuje kierownik projektu jest grupa zadań (pakiet prac). Ten pakiet prac zgodnie z procesami zarządczymi metodyki PRINCE2 (SE1 – WP1) jest przekazywany kierownikowi zespołu realizacyjnego, który planuje prace dla swojego zespołu. Przy odpowiednio skonstruowanej macierzy kompromisów projektowych, planie komunikacji i tolerancjach możliwe jest takie „opakowanie” przez Project Managera aby kierownik zespołu realizacyjnego mógł wraz ze swoim zespołem realizować go technikami zwinnymi. Oczywiście, w trakcie planowania projektu zgodnie z technikami adaptacyjnymi APF pojawia się szereg innych problemów związanych z iteracyjnością podejścia zwinnego, poziomem odpowiedzialności i kompetencji czy też komunikacją. Pogodzenie obu podejść wymaga sporo wysiłku, jednak daje bardzo duże korzyści polegające na połączeniu zalet podejścia tradycyjnego i zwinnego.