''Oprzyrządowanie projektu'' tworzy zeń zorganizowaną maszynę, działającą wedle jasnych, ustalonych reguł.

Wszystko jest projektem - mówi Łukasz Majer, kierujący działem produkcji w DRQ. Projektem jest budowa systemu, jest nim wdrożenie standardowego rozwiązania, integracja, ale także np. przygotowanie oferty pod zapytanie. Mnogość i różnorodność przedsięwzięć realizowanych w firmie kazała dopracować się pewnego standardowego modelu. Wdrożono go z sukcesem w roku 2004, posiłkując się specjalistami od metodyki PMI/PMBOK. Efektem jest opis tego modelu oraz towarzyszące mu szablony, systemy oraz praktyki organizacyjne.

Projekt dzieli się na trzy zasadnicze fazy: uruchomienie, realizacja i zamknięcie. W pierwszej z nich określane są trzy podstawowe "wymiary" projektu - zakres, budżet i harmonogram. Oczywiście wybierany jest także Project Manager - osoba, która od początku do końca będzie nadzorowała przedsięwzięcie. Organizowane jest także środowisko projektowe, czyli tworzony jest plan w systemie PPS, zakładane są odpowiednie "bazy projektowe" (służące do pracy grupowej, prowadzenia korespondencji z klientem i składowania dokumentacji), a w systemie wersjonowania kodu i systemie śledzenia błędów - o ile projekt ma charakter programistyczny - powoływany jest nowy obszar (katalog), do którego trafią źródła i zgłoszenia błędów.

Szefa projektu wspiera stale tzw. Project Office - niezależny dział spełniający funkcje administracyjne i nadzorcze. Przez cały czas trwania przedsięwzięcia jego pracownicy dbają o to, by dokumenty i informacje dotyczące projektu oraz puli projektów były kompletne i prawidłowe.

Znajdź właściwych ludzi...

Większość przedsięwzięć wymaga zróżnicowanych umiejętności i kilku ról. W standardowym modelu zespołu projektowego jest - oprócz Project Managera - miejsce dla lidera technicznego. Jego podstawową odpowiedzialnością jest cała merytoryczna część rozwiązania. W przypadku budowy systemów informatycznych osoba ta będzie odpowiadała za element technologiczny: dobierze właściwe narzędzia, zatwierdzi architekturę, określi interfejsy, zweryfikuje produkty analityczne itd. W skład zespołu projektowego wchodzą także realizatorzy - czyli po prostu członkowie tego zespołu. W zależności od rodzaju zadania będą to programiści, analitycy, inżynierowie sieciowi, szkoleniowcy, graficy, dokumentaliści itd.

Baza kompetencji składowana w systemie PPS, o którym mowa w sąsiednim artykule, bardzo przydaje się w znajdowaniu osób o odpowiednich kwalifikacjach. Warto dodać, że każdy pracownik jest charakteryzowany przez unikatową kombinację ponad 100 zdefiniowanych kompetencji. Tak się bowiem składa, że informatycy często dysponują kilkoma umiejętnościami, potwierdzonymi różnymi certyfikatami. Gdyby nie scentralizowana informacja o kwalifikacjach i kompetencjach osób, nie dałoby się szybko wyszukać odpowiedniego człowieka do odpowiedniego zadania.

Czasami nie ma odpowiednich osób wewnątrz firmy. Co wtedy zrobić? Problem można rozwiązać na trzy sposoby. Jeden to kształcenie. Jeżeli projekt nie jest realizowany pod presją czasową, można wysłać pracownika na odpowiedni kurs, kupić mu literaturę, dać trochę czasu na potrenowanie i zdobędzie wymagane przez DRQ kompetencje. Pomaga w tym specjalna baza dostępnych szkoleń i planowanie ścieżki rozwoju pracowników. Druga możliwość to rekrutacja. Dane kandydatów przechowywane są dokładnie w takim samym formacie, jak dane o pracownikach, dlatego odszukanie człowieka do danego przedsięwzięcia jest równie proste. I wreszcie ostatnia, niemniej stosunkowo często wykorzystywana możliwość, to wynajęcie na pewien czas pracownika z firmy należącej do puli stałych podwykonawców DRQ.

Zaplanuj...

Mając zespół, zakres i wstępny harmonogram, można się wziąć za planowanie właściwe. Tutaj wiele zależy od zadania, jedno jest wszakże wspólne: klient i dostawca muszą mieć dokładnie to samo rozumienie co ma być dostarczone, na kiedy i jakie będzie za to wynagrodzenie. Służy temu seria uzgodnień i oczywiście umowa szczegółowa. Jej elementem jest harmonogram. DRQ używa narzędzia PPS do planowania projektów na potrzeby menedżera projektu i zespołu, ale klientowi wysyła informacje w plikach eksportowanych do standardu MS Project.

Harmonogram projektu musi posiadać pewne podstawowe cechy, których kontrolą zajmuje się Project Office. Przede wszystkim powinien być strukturalnie i merytorycznie poprawny. Powinien mieć więc początek, koniec, wyraźnie oddzielone fazy (zgodne ze standardowym modelem) z rozsądną długością i zadanymi proporcjami pomiędzy nimi. W projektach, w których wytwarzane są produkty inżynierskie (np. oprogramowanie), przed ich oddaniem powinna nastąpić faza testowania. W DRQ zajmuje się tym wydzielony zespół testowy, którego odpowiedzialność ostatnio znacznie poszerzono.

System PPS, wytworzony wewnątrz firmy na bazie długoletnich doświadczeń, jest dobrze przystosowany do specyfiki pracy w firmie. PPS dobrze radzi sobie z bilansowaniem pracy w wielu projektach w oparciu o te same zasoby. Pozwala racjonalnie zagospodarować czas pracy pracowników (pamiętajmy, że ten sam człowiek może pracować przy kilku projektach jednocześnie), od razu wykrywając ewentualne przeciążenia konkretnej osoby. Dzięki niemu można także planować i monitorować urlopy. Wszystko to sprawia, że harmonogram stworzony przy użyciu tego narzędzia jest realistyczny i realizowalny - co jest pierwszym zasadniczym warunkiem sukcesu projektu.

I wreszcie ostatnia rzecz, jaka podlega planowaniu, to ryzyko. Każdy szef projektu na chwilę siada przed stosownym formularzem i zastanawia się: co może pójść nie tak, dlaczego, co się wtedy stanie i jak temu zaradzić. Z oczywistych względów nie ma wpływu na pewne czynniki (np. sytuacje losowe), jednak dobry menedżer planuje z wyprzedzeniem sposób postępowania na wypadek ich zaistnienia.

Generalnie, zamknięcie fazy planowania projektu musi być poprzedzone przeglądem i "odhaczeniem" pewnych standardowych pytań na przygotowanej na potrzeby Project Office liście. Pozwala to uniknąć sytuacji, gdy mocno obciążony Project Manager coś przeoczy, zrobi nie dość szczegółowo. Project Office jest jednocześnie źródłem informacji zarządczej, pozwalającej kierownictwu działu technicznego zarządzać niejako "z lotu ptaka" - nie każdym przedsięwzięciem z osobna, a wszystkimi razem.