W poprzednim wpisie opisano jak zabrać się do wdrażania standardów zarządzania projektami. Teraz przedstawione zostaną bardzo uproszczone kroki postępowania. Oczywiście (drobne zastrzeżenie) jest bardzo schematyczny opis, który przede wszystkim ma wzmóc głód wiedzy i wskazać kierunek do najbliższej restauracji, niż gotowy, syty obiad.
W obszarze kompetencji warto w pierwszej kolejności dostarczyć ludziom przynajmniej podstawowych umiejętności, które pozwolą im zrozumieć, czym jest projekt, zakres, WBS, kamień milowy, harmonogram, dlaczego konieczne jest planowanie, w dalszej perspektywie zaś, jak działa proces projektowy w naszej firmie, w jaki sposób korzystać z narzędzi (tak z 1-2 dni szkoleniowe na uczestnika projektu). Chodzi o to, aby umieli się porozumieć z kierownikiem projektu, gdy ten prosi o WBS, albo zapotrzebowanie na zasoby.
Niezależnie ludzi trzeba otworzyć na zmiany i uświadomić im, że kierownictwo będzie konsekwentnie poprawiało efektywność realizacji projektów. Nic nie działa lepiej motywacyjnie, jak świadomość nieuniknioności zmian. Konieczne jest też uświadomienie im, jaka jest natura konfliktów, które sobie generują, do czego prowadzi słabe koordynowanie projektów i problemy z komunikacją. Celem budowania postaw powinno być także integrowanie ludzi wokół strategii firmy, celów projektu czy wspólnej pracy w dziale. Podstawowym wyzwaniem tutaj jest walka z tzw. silosami funkcjonalnymi (myślenie jedynie w obszarze własnej szufladki) i uprzedzeniami na linii my-oni. Silosami, czyli działami firmy, w których dyrektorzy okopali się, blokując informacje i możliwości współpracy. Aby to osiągnąć, nie wystarczy szkolenie, czy wysłanie okólnika. Trzeba pracownikom zademonstrować, co w praktyce niesie konflikt i jak go rozwiązać. Najbezpieczniej dokonać tego przez zaangażowanie ich w symulację, w której sami sobie spowodują kryzys i przy pomocy trenera wydostaną się z niego.
Kulturę organizacyjną buduje się od góry, tzn. postawy pracowników kształtują się na przykładzie zachowań ich przełożonych.
Drugi tor to zasady pracy i ścieżki podejmowania decyzji związanych z projektami. Innymi słowy to wprowadzenie administracji projektami. Najprostszy schemat postępowania – najzwyczajniej w świecie zrobić listę projektów w firmie. Wypytać menadżerów, nad czym pracują ich ludzie, nie licząc pracy bieżącej. W wielu firmach prezentacja takiej listy aktywnych projektów wzbudziła żywe dyskusje, bo okazywało się, że mnóstwo inicjatyw nie miało wcale wsparcia zarządu. Mając taką listę, wystarczy teraz wypytać decydentów, sponsorami których projektów deklarują się być. Kilka z projektów pewnie nie będzie miało szczęścia i zostaną bez sponsora, nikt się do nich nie przyzna. To są tzw. projekty sieroty. Naturalną decyzją po przeanalizowaniu ich uzasadnienia jest ich skasowanie. Powodem do skasowania może też być brak możliwości zasobowych ich realizacji w najbliższym czasie. Przykład kilku dużych firm pokazuje, że nawet 30% projektów zidentyfikowanych na liście może zostać usuniętych. Co oznacza, że 30% wysiłku było inwestowane w niechciane inicjatywy. To też oznacza, że wprowadzenie administracji projektami zwraca się w pierwszym miesiącu działalności.
Sponsor projektu to kluczowy decydent w firmie, tzw. właściciel uzasadnienia biznesowego projektu – wie, po co projekt został uruchomiony. Ktoś, kto w razie problemów będzie bronił projektu na wysokim szczeblu.
Aby w przyszłości zapobiec pojawianiu się nowych projektów-sierot, należy przejąć kontrolę nad procesem uruchamiania projektów. Wbrew pozorom bywa to trudne, bo ludzie lubią robić projekty z różnych przyczyn: hobbystycznie, dla wpisania sobie do CV, dla poznania nowej technologii, dla usprawnienia sobie pracy, aby zapewnić sobie przyszłość w firmie i innych. Zatem, kiedy zabroni im się prowadzić projekt oficjalnie, to będą próbowali realizować je „pod stołem”. Jednym ze sposobów jest regularne robienie przeglądów projektów i omawianie, czym ludzie zajmują się poza pracą bieżącą (o tym dalej). Innym sposobem jest uzgodnienie z szefami działów, że nie podejmują się żadnych zleceń, jeżeli nie mają one autoryzacji sponsora (np. numeru nadanego przez biuro projektów za zgodą sponsora).
Aby przejąć kontrolę nad uruchamianiem nowych inicjatyw, należy zdefiniować, co w naszej organizacji nazywać będziemy projektem, a co nadal może być robione bez angażowania żadnych komitetów i formalizmów. Przykładowa definicja może stwierdzać, że projekt to przedsięwzięcie angażujące inny dział na więcej niż 10 osobodni, albo przedsięwzięcie o budżecie większym niż 5 000 złotych. Dzięki temu też uniknie się przesadnej biurokracji dla małych inicjatyw, a i będzie można rozliczyć pracowników, gdy nie zgłoszą oficjalnie inicjatywy dużej.
Większość projektów charakteryzuje się podobnym przebiegiem. Mają różny, zakres, klientów, czas, jednak tzw. cykl życia (zestaw etapów) jest podobny. Przykładowo projekty witryn internetowych mogą mieć cykl życia: planowanie, zebranie wymagań od klienta, projekt, programowanie, wstawienie treści, publikacja. Albo inny przykład, projekt programistyczny może składać się z etapów: planowanie, definiowanie wymagań, specyfikacja, programowanie, testy, wdrożenie. Albo konstrukcyjny: planowanie, studiów wykonalności, definiowanie wymagań, projektowanie, produkcja, montaż.
Mając większość projektów przypisanych do wspólnego cyklu życia, można je porównywać do siebie, obserwować ich postęp oraz analizować, na jakim są statusie. Ważne też, że zwykle każdy z etapów realizowany jest przez inny zespół i wymaga innej technologii. Zawsze projektowanie realizują konstruktorzy, definiowanie wymagań – kierownicy projektów, a produkcja – wiadomo, dział produkcji. Najprostszą metodą monitorowania projektów jest zatem zbieranie dat końców poszczególnych etapów. Trik polega na tym, że robimy to z upiorną systematyczności, np. co 2 tygodnie, zbierając do tabelki kolejne prognozy. Po kilku tygodniach takiej obserwacji portfela zobaczymy, które projekty nam pełzają, a które posuwają się naprzód zgodnie z planem. Da to wówczas pretekst do dyskusji na temat efektywności i problemów poszczególnych przedsięwzięć.
Wreszcie warto zorganizować tzw. komitet sterujący. Czyli ciało złożone z kluczowych decydentów zainteresowanych kondycją portfela projektów. W jednych firmach będzie to zarząd, w innych wybrani dyrektorzy, jeszcze w innych prezes i kilku kierowników projektów. Ważne, aby spotkania odbywały się regularnie i aby omawiać na nich kondycję wszystkich projektów. Elementem takich spotkań jest niekiedy wspólne planowanie prac działów zaangażowanych w projekty, czyli np. kompletowanie najbliższej wersji systemu informatycznego, układanie grafiku prac konstruktorów lub grafików komputerowych itd. Po spotkaniu KS, ktoś powinien spisać podjęte decyzje i zaprezentowany status projektów.
Powyższy krótki tekst nie wyczerpuje rzecz jasna zagadnień związanych z zarządzaniem portfelem projektów, ale naszą intencją było w możliwie najprostszy i najbardziej syntetyczny sposób przybliżyć specyfikę wdrażania tzw. metodyki zarządzania projektami. Należy go traktować raczej jako listę kontrolną zagadnień, o których należy pamiętać, niż całościowy podręcznik. Ponadto warto pamiętać, że życie może dopisać tuziny kolejnych kroków na drodze ku doskonałości, czego wszystkim zainteresowanym życzę.
