Jak wykorzystujemy Project Server 2007 w moim dziale

Kilka zdań wstępu. Ten dokument nie prezentuje w jaki sposób Microsoft wykorzystuje Project Server 2007. Microsoft to bardzo duża firma, składająca się z setek działów i oddziałów, rozmieszczonych na całym globie. Metodologia wykorzystania technologii naszej firmy może się różnić w poszczególnych działach, tak jak różne mogą być wymagania czy doświadczenie w ich wykorzystaniu. Ten dokument prezentuje w jaki sposób jeden z działów Microsoftu, dział Operation Services w Dublinie wykorzystuje Project Server 2007. Ten dokument nie został napisany pod dyktando mojej firmy, a jest jedynie efektem chęci podzielenia się moimi doświadczeniami z innymi osobami.

Początki

W 2007 roku stworzyłem aplikację, która na bazie Infopath i SharePoint pozwalała nam śledzić tok życia naszych projektów. Aplikacja ta była odpowiedzią na wymagania naszego kierownictwa. Wpis o nazwie “Zabawy mydłem, czyli one person project” daje zarys tego, co zrobiłem. Jak skomentował to wtedy Paweł, było to takie wymyślanie koła na nowo. Podobne implementacje już istniały, jak choćby Project Server, ale my nie byliśmy jeszcze na tym etapie, by wdrażać tak duże rozwiązania.W dodatku, moja wiedza nt. PS była znikoma.

Pamiętam, że dostawałem wtedy wiele pochlebnych komentarzy nt. mojej  małej aplikacji. Dostawałem też całą masę pytań związanych z tym, jak coś zrobić, czy coś jest możliwe, etc. Wraz z rosnącą ilością projektów, które były raportowane, rósł też mój apetyt na coś większego i lepszego.

Były to okolice maja 2008, blisko rok temu, kiedy szef mojego działu zatrudnił nową osobę. Celem tej osoby miało być zorganizowanie z prawdziwego zdarzenia biura PMO – Project Management Office. Darren przyszedł z workiem doświadczenia prowadzenia dużej ilości międzynarodowych projektów i potrzebnej businessowej praktycznej i teoretycznej wiedzy. Ja byłem na etapie uczenia się czym jest Project Server i jak można go u nas wykorzystać.

Project 2.0

Uruchomiliśmy projekt, który nazwaliśmy Project 2.0. Po niezliczonej ilości konsultacji z innymi działami, dziesiątek godzin spędzonych nad czytaniem i pisaniem dokumentacji i najważniejsze – ciągłego szukania poparcia u naszego kierownictwa, w sierpniu 2008 roku ogłosiliśmy, że nasz serwer jest gotowy do użytku. Naszymi użytkownikami było około 40 osób w naszym biurze w Dublinie i łączna ilość projektów około 20.

Dostaliśmy do tego serwer HP z Dual Core Xeon 2.3GHz, 16GB RAM, dwoma dyskami w RAID1 na OS i trzema w RAID5 na dane, działającym na Windows Server 2003 x64 Enterprise. Wykorzystaliśmy SQL Server x64 2005 Enterprise Edition. Sprzęt i system operacyjny zarządzany jest przez Microsoft’owe IT, resztą, czyli SQL, SharePoint 2007 i Project Server 2007 zajmuję się ja. W tym miejscu chciałbym dodać, że serwer ten jest także naszym działowym serwerem SharePoint 2007 (MOSS). Obecnie baza dnych dla SharePoint ma około 2GB, więc nie jest to bardzo duża implementacja. Mamy tam także drugą instancję SQL dla jednego z naszych podwydziałów – około 30GB danych.

Coś, czego od samego początku nam brakowało, to dobre raportowanie. Chcieliśmy zautomatyzować w jaki sposób postępy w projektach wysyłane są do kierownictwa i chcieliśmy, by wszystkie raporty wyglądały w ten sam sposób. PS2007 nie dawał takiej opcji wprost z pudełka, więc musieliśmy skonstruować coś sami. Przypatrywaliśmy się wielu opcjom, ale jedna wydała się najbardziej zachęcająca – SQL Reporting Services.

Pewne kwestia warta wyjaśnienia, pisząc w liczbie mnogiej – wymyśliliśmy, skonstruowaliśmy, uruchomiliśmy mam na myśli dwie osoby – Darrena i mnie, gdzie on był odpowiedzialny za wymagania, marketing i kontakty z klientami (naszymi kolegami i kierownictwem działu), a ja byłem człowiekiem od technologii. Od sierpnia 2008 nas dwoje jest odpowiedzialnych za PMO.

I tak z pomocą Christophe Fiessinger’a i kilku osób z jego działu oraz dwójce programistów z grupy SQL Reporting Services z Redmond, udało nam się stworzyć w pełni automatyczny i bardzo elastyczny system raportowania stanu projektów. Mamy dwa podstawowe typy raportów. Pierwsze to tygodniowe raporty dla kierownictwa, które zawierają listę projektów wraz ze statusami dot. czasu, “risk and issues” i postępów w pracy. Drugie to raporty dla menedżerów projektów i zespołów zawierające bardziej szczegółowe, niż raporty dla kierownictwa, dane. Wśród innych raportów mogę wymienić raport dot. “milestones” dla wszystkich projektów, raporty ilustrujące fazy w których są projekty, raporty z rozbiciem na dział, w którym projekty startują, raport ilustrujący perspektywy czasowe wykonania projektów, etc. Elastyczność SQL Reporting Services jest bardzo duża.

Nasze początki były dość skromne. 10 projektów i 36 użytkowników PS i Project Professional 2007. Po zorganizowanej serii szkoleń dla naszych pracowników byliśmy w stanie potroić ilość projektów na serwerze. Nasze kierownictwo wymogło na pracownikach, by każdy projekt wydziałowy był odnotowany na serwerze.

Rozwój

Tymczasem wieść o naszej implementacji rozniosła się po firmie. Nasz siostrzany dział, Operation Services z Redmond, zaczął się przyglądać możliwości wykorzystania naszego rozwiązania w ich projektach. To wymaga dużej ilości analiz, ponieważ mają 100+ projektów i 100+ użytkowników. W trakcie, kiedy wciąż trwają analizy dla Redmond, nam udało się przyciągnąć nasz dział z Singapuru do korzystania z PS2007 i raportowania. Dział Microsoft Licensing (MSLI) z Reno wykorzystał przy kilku okazjach nasze doświadczenie z SQL Reporting Services do budowania raportów finansowych na potrzeby działu księgowości.

Na chwilę obecną mamy na serwerze 28 raportów, kolejne 20 w archiwum. Z serwera korzysta już ponad 100 użytkowników z Azji, Europy i USA. Nasze raporty docierają do ponad 100 osób.

Podsumowanie

Z perspektywy czasu widzę, że wiele rzeczy można było zrobić inaczej, lepiej. Przez ostatni rok dużo się nauczyliśmy. Ja dopiero teraz jestem gotowy wstąpić na ścieżkę certyfikacji z EPM. Przede wszystkim jednak, nauczyliśmy się, że to nie implementacja narzędzia stwarza najwięcej problemów, ale przekonanie użytkowników i kierownictwa do jego używania. Gdyby nie czas, jaki spędzialiśmy odpowiedając na pytania, szkoląc grupowo i indywidualnie naszych uzytkowników, a przede wszystkim wiele pomysłowość i elastyczność w odpowiadaniu na ich potrzeby, nasz projekt nie miałby tak dużego powodzenia.

Wciąż borykamy się z problemami, jak choćby użycie RTF w raportach. Ale dzięki temu uczymy się jak nie popełniać ich w przyszłości. Byłoby nam o wiele trudniej, gdyby nie pomoc dziesiątek osób ze Stanów i Dublina, które odpowiadały na nasze pytania. Dla mnie bardzo duże znaczenie w zrozumieniu EPM miała konferencja Microsoft Office Project Conference 2007 EMEA, jaka miała miejsce w grudniu 2007 roku w Madrycie. Otworzyła mi oczy na to, jak inni zaimplementowali EPM i dostosowali to narzędzie do swoich potrzeb. Pamiętam, że jednym z prelegentów była osoba z Polski – Michał Czarnocki z Polkomtela (ich opis wdrożenia).

O nas

Dział Operation Services to dział Microsoftu zajmujący się finalnym etapem wypuszczania oprogramowania naszej firmy na rynek. Nasze pododdziały zajmują się kwestiami ustalania cen produktów, wyglądem i zawartością pudełek z oprogramowaniem, kanałami dystrybucji, kluczami produtku, podpisem cyfrowym plików, walką z piractwem, współpracą z producentami oprogramowania antywirusowego w celu zapobiegania false positives, produkowaniem płyt CD i DVD z oprogramowaniem, i innymi aspektami dostarczania oprogramowania na rynek. Główną siedzibą naszego działu jest Redmond, WA, USA z oddziałami w innych miastach USA, Irlandii, Danii, Singapurze i Puerto Rico.