Wykonaj...

W trakcie trwania projektu pracownicy DRQ realizują zadania przydzielone im przez ich menedżerów lub lidera technicznego. Warto powiedzieć, że struktura zespołu projektowego konstruowana jest dynamicznie, na potrzeby danego projektu. Ustala ona relacje przełożony-podwładny w kontekście danego projektu, niejako "w poprzek" stałej hierarchii organizacyjnej.

Do monitorowania zużycia zasobów na projekt służy dodatkowe narzędzie. Raz dziennie każdy pracownik DRQ, włączając w to członków kierownictwa firmy, za pomocą prostej aplikacji deklaruje, ile czasu spędził w danym dniu nad danym zadaniem. Dane te na bieżąco trafiają do bazy systemu PPS. W ten sposób zarówno menedżer projektu, jak i menedżerowie całego działu oraz Project Office mogą odpowiedzieć sobie na zasadnicze pytanie: na ile nasze zużycie pracy (koszty!) na zadany projekt nadal mieści się w ramach, które zostały określone podczas fazy planowania.

Przedmiotem szczególnej troski jest oczywiście harmonogram. Wewnętrzne regulacje DRQ wymagają, by kontrolować wykonanie co najmniej raz w tygodniu. Jeżeli projekt ma określone "kamienie milowe" - a w myśl wewnętrznych regulacji powinien mieć - kontrola postępu to przede wszystkim kontrola poszczególnych produktów, które projekt miał dostarczyć do zadanej daty. Pojawiają się - projekt idzie dobrze; nie pojawiają się - projekt idzie źle i w takiej sytuacji firma uruchamia mechanizmy awaryjne. Na przykład posyła do pomocy dodatkowych specjalistów albo stara się uzgodnić z klientem przesunięcie terminu.

Naturalną cechą projektu jest to, że w trakcie jego trwania klient zgłasza zmiany lub precyzuje swoje oczekiwania w stopniu, który wymusza dostosowania przygotowywanego rozwiązywania. Kontrola zmiany jest więc ważnym - jeśli nie najważniejszym - procesem zarządczym w fazie realizacji projektu.

DRQ przyjmuje jedną zasadę: cała komunikacja z danym klientem przechodzi przez tę samą bazę projektową, posiadającą charakterystyczny dla projektu adres e-mail; korespondencja taka automatycznie trafia do wiadomości account managera zarządzającego relacją z danym klientem. Z każdej strony wskazane są osoby uprawnione do podejmowania konkretnej grupy decyzji i każda istotna zmiana zakresu, harmonogramu lub ceny całego przedsięwzięcia wymaga jawnej autoryzacji. W ten sposób w jednym miejscu zgromadzona jest cała historia uzgodnień z danym klientem i ewentualne odtworzenie kto, kiedy i jaką podjął decyzję jest względnie proste. Warto zauważyć, że account manager aż do odbioru projektu uczestniczy w podejmowaniu istotnych decyzji i rozwiązywaniu problemów w projekcie na styku z klientem. To właśnie różni account managera od prostego handlowca - ten pierwszy nie składa obietnic, których nie mógłby potem dotrzymać.

Dla produktów software'owych DRQ wykonuje cztery rodzaje testów, w których pomaga narzędzie śledzenia błędów: beta testy, testy wewnętrzne w specjalnie zasymulowanym środowisku, a także testy w środowisku docelowym u klienta. Ostatni rodzaj testów to testy akceptacyjne klienta, które kończą się protokołem odbioru, w którym klient ostatecznie potwierdza, że rzeczywiście otrzymał to co zamówił i jest z tego zadowolony.

Rozlicz

Tak jak koniec wieńczy dzieło, tak faza rozliczenia projektu zamyka go i podsumowuje. W tej części menedżer projektu z DRQ ma obowiązek uporządkować wszystkie ostateczne wersje dokumentów projektowych (np. diagramów analitycznych czy umów) oraz upewnić się, że repozytorium kodu zapewnia pełną i aktualną wersję produktów software'owych. Z reguły, jeżeli przedmiotem projektu było dostarczenie fizycznego produktu, element ten objęty jest przez pewien okres gwarancją i menedżer powinien oszacować koszty, które świadczenie gwarancyjnych usług serwisowych będzie wywoływało w firmie.

A skoro o kosztach mowa, rozliczany jest też budżet - przy czym mowa zarówno o budżecie dosłownym, czyli w ujęciu gotówkowym, jak i budżecie godzin, które na projekt przewidziano - i ostatecznie wykorzystano. I znowu - przekroczenie budżetu, które zaburza rentowność przedsiębiorstwa, jest przedmiotem dodatkowej analizy na szczeblu szefów komórek i działu.

Obowiązkiem szefa przedsięwzięcia jest też stworzenie tzw. raportu poprojektowego, w którym z grubsza opisze problemy, które wystąpiły podczas jego trwania, jaki wpływ miały one na realizację zadania i w jaki sposób można było ich uniknąć. Taki raport jest następnie przedmiotem analizy menedżerskiej i służy do nieustającej optymalizacji procesu zarządzania przedsięwzięciami w DRQ.

Często w ramach projektu pozyskano pewną wiedzę, np. na temat klienta, jego biznesu, nowej technologii czy segmentu rynku. Bardzo ważne jest, aby wiedza ta została odpowiednio "zmaterializowana", opisana i udostępniona w firmowej bazie wiedzy (Techopedii) - tak, by pozostali pracownicy firmy mogli z niej korzystać w dalszych projektach.

Last but not least, ta faza projektu to dobry czas, by również ocenić jego uczestników. Jeżeli ktoś sprawnie i szybko rozwiązywał powierzone mu zadania, w porę mitygował ryzyka, a na dodatek pozyskał wiedzę na temat nowej technologii - to informacja ta znajdzie się w jego dossier w bazie kompetencji, a on sam odczuje uznanie, jakim darzy go szef projektu. Jeżeli zaś mimo permanentnego przepracowania dostarczał produkty miernej jakości, popełniał gafy w komunikacji z klientem i na dodatek przyczynił się do zwiększonych kosztów usług gwarancyjnych - może być pewien, że w DRQ są w stanie ten fakt zmierzyć i wyciągnąć odpowiednie wnioski na przyszłość.

Warto dodać, że z punktu widzenia klienta współpraca z DRQ w projekcie nie kończy się na fazie jego zamknięcia; projekt ma swoją kontynuację w powoływanych po jego zamknięciu "działalnościach". Oczywiście działalności te powoływane są do życia na mocy analogicznych jak dla projektów procedur, a więc są odpowiednio zarządzane.

Jak fabryka

Całe to "oprzyrządowanie projektu" przywodzi na myśl zorganizowaną maszynę, działającą wedle jasnych, ustalonych reguł. Jednocześnie maszyna ta posiada mechanizmy regulujące, które - w przypadku wystąpienia problemów w jakimś elemencie - szybko przywrócą poprawną pracę. Przed DRQ jeszcze jeden ważny krok: przesunięcie się od modelu "fabryki" do modelu "żywego organizmu", czyli wbudowanie mechanizmów optymalizujących i regenerujących.