Są to wszystko fakty, z którymi zetknęłam się sama lub były udziałem moich kolegów. Wszystkie dotyczą projektów polegających na wdrażaniu nowoczesnego, zaawansowanego oprogramowania. Projektów, gdzie występuje klient, który kupił system oraz dostawca, którego zadaniem jest ten system zainstalować, uruchomić, dostosować do potrzeb i wdrożyć. Piszę z punktu widzenia dostawcy. Takie jest moje zawodowe doświadczenie. Zdecydowałam także uporządkować tekst posługując się terminologią zaczerpniętą z PRINCE2 i odnosząc się do procesów tej metodyki, gdyż ją właśnie cenię najbardziej i staram się stosować. Oto kilka najważniejszych z nich.

1. Przygotowanie projektu

Najczęściej spotykanym odstępstwem od zasad metodyki jest powierzenie, mniej lub bardziej świadomie, prowadzenia tego procesu projektowego - dostawcy. Marketing firm-dostawców kreuje potrzeby biznesowe, zaś handlowcy szukają u klientów budżetu podsuwając założenia stosowne do sprzedawanego systemu i uzasadniając jego wybór. Konsekwencją takiej praktyki jest zaniedbanie istotnych elementów tej fazy. Dostawca wskazuje swojego pracownika na kierownika projektu i oczekuje wskazania dla niego po stronie klienta partnera, którego już nie zawsze nazywa się kierownikiem. Pamięta też o sponsorze, ale bywa, że zapomina o roli i odpowiedzialności Komitetu Sterującego.

Inną charakterystyczną nieprawidłowością jest przerost Komitetu Sterującego. Zaleceniem wszystkich znanych mi metodyk jest, aby liczebność tego ciała wyrażała się jedną cyfrą. Mimo to większość projektów, w których uczestniczyłam, nadzorowana była przez Komitety kilkunastoosobowe, a największy, z jakim się spotkałam, liczył ponad 40 członków. Oczywiście, tak liczne zespoły nie mogą działać sprawnie. Spośród takiego grona w naturalny sposób wyłania się mniejsza grupa faktycznie podejmująca decyzje, niestety nieformalna.

2. Inicjowanie projektu i zarządzanie strategiczne

Podstawowym efektem tego procesu powinien być Dokument Inicjujący Projekt (DIP) - swoista konstytucja projektu zawierająca m.in. opis produktów projektu, plan jakości, analizę ryzyka, strukturę organizacyjną i zakresy obowiązków, plan komunikacji i tolerancje. Dokument ten ma stanowić podstawę do podjęcia ostatecznej decyzji uruchamiającej realizację projektu.

Niestety zdarza się, że DIP traktowany jest jako czysta formalność, a jego zestawienie powierza się dostawcy, niekiedy już po rozpoczęciu prac. Po czym odkłada na półkę. Kiedyś napisałam taki właśnie DIP, myślałam jednak, że była to sytuacja wyjątkowa. Ponieważ uczęszczałam w tym czasie na studia podyplomowe, opowiedziałam o tym prowadzącemu zajęcia profesorowi. Nie zdziwił się. Ze smutkiem stwierdził, że to często spotykana praktyka, zwłaszcza w firmach przejętych niedawno przez duży międzynarodowy koncern, który narzucił swoje standardy nie dbając o wytłumaczenie celu ich stosowania.