Michael S. Zambruski, PMP
Kiedy zjawiam się w organizacji, która nigdy nie korzystała z formalnych analiz biznesowych ani procesów zarządzania projektami, jednym z pierwszych wyzwań jest rozwianie niepewności i zdezorientowania związanego z podstawowymi pojęciami i narzędziami. Na przykład, niemal od razu po rozpoczęciu pierwszego spotkania z decydentami stykam się z takimi pytaniami:
• Na czym polega różnica między wizją, misją i celami firmy?
• Czy dokument wymagań biznesowych (BRD) różni się od karty projektu?
• Po co nam karta projektu?
• Po co tworzyć specyfikację zakresu prac, skoro mamy BRD?
• Czy naprawdę potrzebujemy tych wszystkich procesów, żeby uruchomić projekt?
Choć dla zawodowego analityka biznesu czy kierownika projektu są to pytania retoryczne, zdradzają one zasadniczy brak uporządkowanego i zdyscyplinowanego zarządzania procesami u osób, które je zadają. W takiej sytuacji moje zadanie staje się jasne: muszę uświadomić im wartość formalnych procesów i procedur, przedstawiając je w postaci przystępnych i ważnych pojęć, technik oraz narzędzi. W tym celu stworzyłem poniższe cztery pomoce:
• Hierarchia celów firmy
• Szablon specyfikacji zakresu prac
• Wytyczne do zarządzania projektami
• Słowniczek pojęć
Hierarchia celów firmy
Hierarchia celów firmy przedstawiona na Rycinie 1 ma zorientować decydenta lub lidera zespołu w logice przebiegu prac od etapu pomysłu do etapu wdrożenia, z uwzględnieniem jasno określonych produktów cząstkowych każdego etapu. Na przykład w domenie biznesowej, którą nazywam obszarem nad żółtą linią, mamy do czynienia z wizją firmy (PRZYSZŁOŚĆ), jej misją (TERAŹNIEJSZOŚĆ) oraz rozmaitymi, konkretnymi celami wspierającymi realizację wizji i misji.
Pod żółtą linią znajduje się domena projektu, w której bardziej abstrakcyjne elementy wizji, misji i celów firmy są sprowadzane na ziemię i przyjmują postać konkretnych zadań do wykonania. Karta projektu jest tu przedstawiona jako dokument autoryzacyjny, który zawiera numer projektu (najprawdopodobniej nadawany przez centralną komórkę kontrolującą projekty) oraz upoważnienie do korzystania ze środków pieniężnych. W zasadzie jest to zezwolenie na zaangażowanie zasobów, potrzebne do formalnego zaplanowania i zebrania wymagań biznesowych, które rozpoczyna się od planu opracowania wymagań (RWP), a kończy się sporządzeniem dokumentu wymagań biznesowych (BRD).
Przygotowanie karty, RWP i BRD kończy fazę analizy projektu. Teraz organizacja dokładnie wie, dlaczego zaakceptowała ten projekt i jakie korzyści przyniosą firmie jego produkty końcowe. Ten etap ma zasadnicze znaczenie dla zarządzania i kontrolowania kolejnych prac, które opisuje się w kolejnym dokumencie, czyli specyfikacji zakresu prac (SOW).
Specyfikacja zakresu prac
Specyfikacja zakresu prac to jedno z tych pojęć, które dla różnych odbiorców znaczy co innego, dlatego trzeba zadbać o jednakowe zrozumienie i konsekwentne stosowanie tego dokumentu, przygotowując szablon zawierający rubryki wymienione w poniższym spisie treści:
1. Opis projektu
a. Cel
b. Metodyka
c. Taktyki
d. Priorytety
e. Kamienie milowe
f. Wyłączenia z zakresu
2. Zespoły projektu
a. Zespół kierujący
b. Zespół operacyjny
c. Personel zapasowy/zmiennicy
3. Kryteria sukcesu
a. Główne produktu
b. Mierniki jakościowe
c. Macierz identyfikowalności
4. Założenia
5. Ograniczenia
6. Proces kontroli zmian
7. Załączniki
a. Dokument wymagań biznesowych
b. Budżet projektu
c. Plan projektu
d. Plan zarządzania ryzykiem
e. Rejestr ryzyka
f. Zasady zgłaszania problemów
g. Plan komunikacji
h. Zasady dokumentacji
i. Strategia testów
j. Strategia szkoleń
Na tym etapie kładę szczególny nacisk na odróżnianie uporządkowania od usztywnienia. Uporządkowanie oznacza korzystanie z szablonu specyfikacji zakresu prac jako standardowej, powtarzalnej metody dającej pewność, że niczego nie pominiemy. Z tej przyczyny SOW musi być sporządzana dla każdego usankcjonowanego projektu. Z drugiej strony usztywnienie wymaga ścisłego trzymania się szablonu, co byłoby niepraktyczne, bo każdy projekt jest inny. Dlatego struktura SOW jest zawsze taka sama, ale szczegóły odzwierciedlają specyficzne uwarunkowania, więc w każdym projekcie będą inne. Dla przykładu, chociaż każdy projekt ma jakieś zasady zgłaszania problemów, dla jednego projektu może obowiązywać okres jednodniowy a dla innego tygodniowy. Elastyczność sytuacyjna ma zasadnicze znaczenie dla skutecznego stosowania standaryzowanych narzędzi, takich jak SOW.
Wytyczne do zarządzania projektami
Poniższe wytyczne opisują zasady, procedury, techniki i produkty potrzebne do ujednoliconego zarządzania projektami w całej organizacji. Wszystkie te środki, łączące standaryzację z odpowiedzialną elastycznością i sprawdzonymi rozwiązaniami, mają na celu kończenie projektów w budżecie i w terminie, drogą starannego zarządzania zakresem, jakością i ryzykiem.
Autoryzacja projektu
Projekty są przyjmowane do realizacji w celu stworzenia produktów czy rezultatów określonych w oficjalnym dokumencie wymagań biznesowych (BRD), zgodnym z wizją, misją i nadrzędnym celem (lub celami) organizacji sponsorującej.
Rozpoczęcie projektu
Po potwierdzeniu BRD, przyznania środków i wskazanego sponsora następuje oficjalne rozpoczęcie projektu przy pomocy niżej wymienionych dokumentów.
Specyfikacja zakresu prac (SOW)
wyszczególnia cel projektu, ogólną metodykę i taktyki wiodące do osiągnięcia celu, ramowy terminarz z głównymi kamieniami milowymi, szczegóły finansowania, kryteria sukcesu, założenia, ograniczenia oraz odniesienia do udokumentowanych wymagań biznesowych. Elementem zasadniczym dla SOW jest klarowna specyfikacja wszystkich prac z zakresu oraz wskazanie prac nie wchodzących w zakres.
Lista priorytetów
Hierarchia najważniejszych celów szczegółowych lub inicjatyw prowadzących do osiągnięcia celu projektu, stanowiących podstawę kompleksowego planu projektu. Można ją zarejestrować w osobnym dokumencie lub włączyć do SOW.
Skład zespołu projektu
Listę członków zespołu głównego, w tym pracowników dostawcy/wykonawcy, należy zestawić jak najwcześniej. Przy każdej osobie należy podać dane kontaktowe, specjalizację, zakres obowiązków i ewentualnego zmiennika. Te informacje można zarejestrować w osobnym dokumencie lub włączyć do SOW.
Plan projektu
ten dokument pełni rolę głównego mechanizmu kontroli, wyszczególniając fazy projektu i rozkładając te fazy na konkretne zadania wraz z terminami wykonania, zasobami, zależnościami logicznymi i produktami. W trakcie realizacji projektu pełni też rolę narzędzia oceny statusu, pokazując stan zaawansowania prac. Zwykle stanowi Załącznik C do SOW i może mieć format pliku Microsoft® Project czy Excel albo Adobe® pdf.
Realizacja projektu
Kiedy tylko rozpocznie się formalna analiza projektu, należy zdefiniować i regularnie powtarzać poniższe procedury.
Zarządzanie ryzykiem
Identyfikacja, analiza, rejestrowanie i zarządzanie ryzykiem to wymaga współpracy zespołu projektu i sponsora. Należy je rozpocząć zaraz po zatwierdzeniu projektu, a najpóźniej w momencie rozpoczęcia wykonania projektu. Zwykle stanowi Załącznik D do SOW.
Zgłaszanie problemów
Zwłaszcza w projektach złożonych potrzebne są formalne zasady zgłaszania problemów, żeby zapewnić terminowe wykonywanie zadań, rozwiązywanie problemów i podejmowanie decyzji wymagających negocjacji czy rozstrzygnięcia sporu. Zwykle stanowi Załącznik F do SOW.
Komunikacja
Format, środki przekazu (w tym elektroniczne) oraz kontrola rozpowszechniania informacji wśród członków zespołu i interesariuszy. Główne elementy skutecznej komunikacji to spójny przekaz, obszerne informowanie w poziomie i w pionie oraz terminowość. Protokoły komunikacyjne dotyczą też spotkań roboczych w projekcie, określając ich częstotliwość, czas trwania, miejsce, uczestników i stałe punkty programu. Jednym z pierwszych zebrań w projekcie powinno być spotkanie organizacyjne, na którym interesariusze i kluczowe osoby z zespołu projektu szczegółowo omawiają SOW. Plan komunikacji zwykle stanowi Załącznik G do SOW.
Dokumentacja
Sposób prowadzenia dokumentacji, miejsce przechowywania i kontrolę wersji dokumentów projektu należy formalnie określić, a potem stale ich przestrzegać. Udokumentowane wymagania, zakres, plany prac, zasady (w tym zgłaszanie problemów i zarządzanie ryzykiem), skład zespołu i kontrakty z dostawcami projektu muszą być łatwo dostępne i zawsze aktualne. Zasady dokumentacji zwykle stanowią Załącznik H do SOW.
Testowanie
Należy zaplanować i przeprowadzić kompleksowe testy potwierdzające zgodność z miernikami jakościowymi określonymi w SOW, żeby mieć absolutną pewność, że produkty cząstkowe spełniają wymagania biznesowe. Należy też opracować i przeprowadzać okresowe testy weryfikacyjne, które umożliwiają ocenę stanu zaawansowania i łagodzenie ryzyka. Protokoły testów zwykle stanowią Załącznik I do SOW.
Szkolenia
Dla każdej fazy projektu należy ocenić potrzebę opracowania i przekazania materiałów edukacyjnych, żeby ustalić czy i na jakie szkolenia istnieje zapotrzebowanie.
Słowniczek pojęć
Poniższy słowniczek pojęć może być dla twojej organizacji sposobem na ujednolicenie słownictwa i zrozumienia kwestii biznesowych.
Cel firmy to ważny kamień milowy w realizacji wizji i/lub misji.
Misja firmy określa OBECNY kierunek firmy.
Wymagania biznesowe to wyszczególnienie elementów celu firmy.
• RWP = plan opracowania wymagań opisuje prace niezbędne do zebrania, udokumentowania, analizy i potwierdzenia wymagań biznesowych
• BRD = dokument wymagań biznesowych zawiera oficjalnie zatwierdzone wymagania biznesowe, które stają się produktami lub rezultatami projektu
Wizja firmy określa strategiczną PRZYSZŁOŚĆ organizacji.
Karta projektu to oficjalna zgoda na realizację celów firmy wymienionych w BRD.
Cel projektu to spełnienie wymagań biznesowych.
Specyfikacja zakresu prac (SOW) to scenariusz realizacji celu projektu.
Brak ogólnej wiedzy o projektach w organizacji może być niemal tak groźny jak brak zarządzania projektami. Hierarchia celów firmy, szablon specyfikacji zakresu prac, wytyczne do zarządzania projektami i słowniczek pojęć powinny pomóc twojej organizacji w uporaniu się z tą kwestią, a także przybliżyć was do większych sukcesów w realizacji projektów.
Michael S. Zambruski, PMP, Dyrektor Biura Zarządzania Projektami w Ośrodku Medycznym UMass Memorial w Worcester w stanie Massachusetts, dyplom MBA Uniwersytetu Południowego Illinois. Pracował w telekomunikacji, informatyce, służbie zdrowia, ochronie środowiska, nieruchomościach, przemyśle lotniczym i instytucjach federalnych. Prowadzi wykłady na Uniwersytecie Quinnipiac, jest też starszym instruktorem ESI International w dziedzinie zarządzania projektami. Jego książka, “The Business Analyzer & Planner”, została wydana przez American Management Association.
ESI International, Inc., 2006. All rights reserved.
