Inicjowanie i planowanie projektu to fazy mające największy wpływ na sukces projektu, a jednocześnie często pozostawiane na marginesie głównych działań projektowych. Postanowiliśmy zebrać nasze doświadczenia i pokazać rozwiązania dotyczące tych obszarów. W tekście tym, będziemy również dotykali przyczyn tej niebezpiecznej dla przedsiębiorstw sytuacji. Spójrzmy teraz na autorskie "best practices" definiowania i planowania projektu.

Referat wygłoszony na IX Konferencji Project Management, Warszawa, 2005

Autorzy: dr Jerzy Stawicki i Daniel Wojewódzki

Analizy przedprojektowe

Punktem startowym każdego projektu powinny być naszym zdaniem dwojakiego rodzaju analizy: analizy udziałowców i analizy problemów. Analizy udziałowców powinny umożliwić zidentyfikowanie osób, jednostek zainteresowanych wynikami projektu oraz dokonanie oceny ich wpływu na projekt.
Najczęściej stosowane metody analizy udziałowców to:

• Macierz analizy udziałowców
• Analiza SWOT
• Diagramy Venna
• Diagramy pająka

Spośród w/w metod autorzy najczęściej stosowali macierze analizy udziałowców w połączeniu z diagramem Venna. Pierwsza z tych metod daję uporządkowaną listę udziałowców wraz z takimi ich charakterystykami, jak interesy i ich wpływ na problem będący źródłem projektu oraz możliwości i motywach je spowodowania zmian, niezbędnych podczas realizacji projektu. Druga z nich przedstawia w postaci różnej wielkości owali poszczególnych udziałowców oraz siłę ich wpływu, wzajemne powiązania i "odległości". Ich łączne zastosowanie pozwala na łatwą identyfikację udziałowców oraz zrozumienie ich interesów i oddziaływania na przyszły projekt. Mamy, więc istotne informacje wykorzystywane w dalszych krokach inicjowania i planowania projektu. I o ile analizy udziałowców realizowane są w praktyce projektowej dość często i wymieniają je standardy zarządzania projektami, takie jak PMBOK® Guide, to analizy problemów przeprowadzane są już znacznie rzadziej. Zdrowy rozsądek wskazuje, że projekt i jego cele oraz produkty powinny wynikać z analizy problemów, lub potrzeb klienta. Teraz zajmiemy się, więc analizą problemów.

Analiza problemów polega na zebraniu kilku najpoważniejszych symptomów/problemów z danego obszaru, ich opisaniu, przeprowadzeniu analizy każdego z nich i opracowaniu diagramu analizy problemu podstawowego, który powoduje istnienie symptomów. Znając przyczynę problemów możemy ustalić kierunek rozwiązania. Wcześniej jednak należy sprawdzić, czy prawidłowo zidentyfikowaliśmy problem podstawowy. Narzędzia, które znajdują tu zastosowanie pochodzą z Zarządzania Ograniczeniami. Przyjrzyjmy się teraz temu podejściu na przykładzie środowiska projektowego. Działamy w obszarze badań i rozwoju pewnego przedsiębiorstwa.
Problemy:

• Rzeczywiste koszty projektów znacznie przekraczają zaplanowane
• Często przerywamy pracę w istniejących projektach, aby wykonać "nagłe zlecenia"
• Terminy nie są dotrzymywane
• Zmiany zakresu projektu opóźniają realizację
• Zarząd jest pod ciągłym naciskiem zwiększania zasobów

Wykonujemy analizę, co pokażemy to na przekładzie problemu czwartego (rys.1).

Rys.1. Analiza problemu – przykład

Po wykonaniu analiz minimum trzech wybranych problemów dokonujemy konsolidacji diagramów (rys.2). Poprzez konsolidację rozumiemy znalezienie takich stwierdzeń, w których zawierają się stwierdzenia z odpowiednich komórek każdego z wykonanych diagramów. Mając diagram problemu podstawowego identyfikujemy założenia, które powodują jego istnienie. W ten sposób ustalamy przyczyny problemów i możemy określić kierunki rozwiązania. Wcześniej jednak należy sprawdzić, czy prawidłowo zidentyfikowaliśmy problem podstawowy w naszym dziale B&R. Można zrobić to budując na podstawie diagramu analizy problemu podstawowego drzewo logicznych zależności: CRT – Current Reality Tree, opisujące obecną sytuację w danym obszarze, lub całym przedsiębiorstwie. Jeżeli zidentyfikowany został właściwy problem, to cel projektu powinien być jego rozwiązaniem.

Rys.2. Schemat konsolidacji Diagramów Analizy Konfliktu

Mając cel projektu możemy określić jego powiązanie z celami nadrzędnymi (np. celami strategicznymi firmy, czy celami rozwojowymi jednostki samorządu terytorialnego), czyli jesteśmy na etapie tworzenia Karty Projektu – dokumentu definiującego projekt.

Definiowanie celów i produktów projektu

Nasze praktyczne doświadczenia związane z definiowaniem projektu wskazują, że często mylone są cele z rezultatami i produktami projektu. Równie często nie bierze się pod uwagę celów wyższego poziomu (celów strategicznych), których realizacji służyć przecież muszą cele projektu. W praktyce projektowej zwykle wykorzystywane są wzorce dokumentu definiującego projekt – czyli Karty Projektu, zawierające miejsce do wpisania tych podstawowych elementów projektu, jakimi są uzasadnienie, cele i produkty projektu oraz założenia i ograniczenia. Zbyt często zawierają one za ogólne informacje, lub wręcz niewłaściwe informacje, utrudniające dalsze planowanie projektu.

Z doświadczeń autorów wynika, że pomocą na tym etapie jest tzw. Mapa definiowania projektu, nazywana często macierzą logiczną (ang. LFM – Logical Framework Matrix). Jest ona jednym z elementów metodyki UE: Project Cycle Managemet (PCM), wykorzystywanej głównie do projektów rozwojowych. Może być ona stosowana praktycznie w każdym projekcie, niekoniecznie rozwojowym. Pozwala ona na zapisanie – krok po kroku, w ściśle zdefiniowanej kolejności i zgodnie z precyzyjną i konsekwentną logiką – zarówno celów strategicznych, celów projektu, rezultatów, jak i związanych z nimi wskaźników, a także metod i źródeł ich weryfikacji.

Układ takiej mapy wraz z kolejnością wypełniania poszczególnych pól przedstawia rys. 3.

Rys.3. Mapa definiowania projektu

Zgodnie z kolejnością podaną na rys. 3 praca z mapą odbywa się początkowo metodą top-down (definicja celów, produktów i działań), następnie bottom-up (założenia), W dalszej kolejności definiowane są wskaźniki i źródła ich weryfikacji (także metodą top-down).

Przy precyzyjnym zdefiniowaniu czym są cele (zarówno strategiczne, jak i cele projektu), rezultaty/produkty oraz działania dzięki realizacji kroków 1-4 bardzo łatwo można zdefiniować te elementy dla naszego projektu. Narzędziem pomocniczym, umożliwiającym sprawdzenie poprawności zdefiniowania tych elementów projektu jest tzw. logika interwencji mapy. Wykorzystuje ona podejście "środki-cele", stwierdzające przykładowo: "jeśli dysponujemy odpowiednimi zasobami, to można realizować działania" i stosująca to stwierdzenie w zmodyfikowanej postaci dla kolejnych elementów (wierszy) mapy. Innym narzędziem sprawdzenia jest tzw. logika wertykalna, sprawdzająca, czy spełnienie założeń związanych z elementem niższego wiersza mapy, umożliwi realizację elementu z wiersza położonego bezpośrednio nad nim. Podejście to przedstawia rys. 4.

Rys. 4. Powiązania pomiędzy założeniami a elementami definicji projektu

Zarówno standardy zarządzania projektami, jak i różne metodyki projektowe wskazują, że cele powinny być SMART, tj. być – m.in. – konkretne i mierzalne. W praktyce projektowej, choć pamiętamy o tym zaleceniu, to jednak rzadko je realizujemy. Macierz LFM umożliwia prostą realizację tego postulatu, zarówno w odniesieniu do celów projektu, jak i w odniesieniu do rezultatów projektu poprzez kolumny: "wskaźniki" i "źródła weryfikacji".

Podejście to było z powodzeniem stosowane przez autorów zarówno w projektach infrastrukturalnych, finansowanych ze środków UE, projektach wdrożeń systemów klasy ERP, jak i w projekcie audytu sposobu zarządzania projektami. Ze względu na swoją prostotę, logikę i możliwości weryfikacji podejścia było stosunkowo łatwo przyjmowane przez zespoły projektowe po stronie klienta.

Dzięki dotychczasowym krokom projekt został niemal (bo potrzebna jest jeszcze formalna akceptacja) – wg terminologii PMBOK® Guide – zainicjowany. Odbyło się to w sposób prosty, a jednocześnie precyzyjny, oparty na rzeczywistym rozwiązaniu faktycznego problemu, przy uwzględnieniu udziałowców projektu. Wyniki dotychczasowych kroków, zawarte w mapie definiowania projektu stanowią punkt wyjścia do dalszych kroków planowania projektu: definiowania zakresu oraz tworzenia harmonogramu.

Definiowanie zakresu projektu

Kolejnym krokiem planowania projektu jest szczegółowe definiowanie zakresu: produktów projektu i działań służących ich wytworzeniu. Informacjami tymi uzupełniamy macierz LFM. Nasze doświadczenia praktyczne wskazują na celowość wykorzystania w tym kroku, wywodzącego się z TOC, podejścia Network Building Process (NBP), uzupełnionego o szablony proponowane przez metodykę PRINCE2^® w Produkt Based Planning. NBP pomaga nie tylko zbudować dobry plan projektu; również angażuje kluczowe dla sukcesu osoby już na etapie planowania. W procesie tym punktem wyjścia jest lista przeszkód stojących na drodze do osiągnięcia celu, a wynikiem sieć logicznie powiązanych zadań, służących wytworzeniu produktów projektu, z przydzielonymi zasobami i oszacowaniami czasu ich trwania. Dodatkowo zarówno produkty, jak i zadania są szczegółowo opisane, łącznie z kryteriami ich zakończenia oraz przypisaniem menedżera zadania. W procesie tym wykorzystujemy naturalną dla ludzi zdolność do przewidywania przeszkód. W pierwszym jego kroku powoływany jest zespół planistów w skład, którego wchodzą ludzie posiadający wiedzę merytoryczną pozwalającą na przygotowanie wykonalnego, dobrego planu projektu. W trakcie realizacji będą oni również liderami wspierającymi, lub realizującymi kluczowe dla projektu zadania. W kroku drugim każdy zgłasza przeszkody uniemożliwiające osiągnięcie celu. Krok trzeci to określenie rozwiązań wylistowanych przeszkód. Rozwiązania te stanowią produkty projektu i dzielą nasze działania na etapy. Następnie ustala się powiązania logiczne pomiędzy produktami. W kroku piątym spotykamy się z klasyczną Strukturą Podziału Pracy (WBS), czyli listujemy zadania konieczne do realizacji każdego z produktów.  W kroku szóstym wspierając się siecią produktów tworzymy sieć powiązań logicznych pomiędzy zadaniami. Jest to jeden z najtrudniejszych kroków, a logika zależności jest wielokrotnie poprawiana zanim uzyska się prawidłowe zależności. W kroku siódmym pozostaje nam przydzielenie zasobów. Tą prace najczęściej wykonuje samodzielnie kierownik projektu. Choć na pierwszy rzut oka różnice w stosunku do tradycyjnych podejść nie są duże, to w praktyce ze względu na orientację na przeszkody, pracę zespołową i szybkie tworzenie sieci zależności proces ten okazuje się być znacznie skuteczniejszy od powszechnej praktyki.
W tym momencie przeprowadzamy szczegółowe oszacowanie kosztów zadań, a w konsekwencji projektu i porównanie z planowanymi zyskami z projektu. To umożliwia podjęcie decyzji o zatwierdzeniu projektu do realizacji.

Tworzenie harmonogramu projektu

Także dla etapu tworzenia harmonogramu (planowania czasu wg PMBOK® Guide) można wymienić szereg praktyk, które umożliwiają i ułatwiają stworzenie realnego harmonogramu, będącego skutecznym narzędziem kontroli projektu w ręku project managera. Należą do nich:

• Szacowanie czasu trwania zadań wg różnych metod, w tym metody dwu-punktowej, wykorzystywanej w CCPM
• Wprowadzanie – jako zabezpieczenie przed niepewnością – różnego typu buforów
• Analiza obciążenia zasobu krytycznego, warunkującego możliwości realizacyjne projektu w firmie.

Jednym z najważniejszych praktycznych problemów harmonogramowania jest dokładność szacowania czasu trwania poszczególnych zadań projektowych. Warto wiec, rozszerzając gamę zwykle stosowanych podejść (jak np. PERT), stosować tzw. metodą dwu-punktową, związaną z podejściem CCPM (Critical Chain Project Management). Mówi ona, że przy przygotowywaniu harmonogramu należy zapytać wykonawców o dwie następujące wartości:

• Czas bezpieczny, przy którym istnieje około 90%-owe prawdopodobieństwo zrealizowania zadania w tym właśnie czasie
• "Czas agresywny, lecz możliwy", czyli czas w którym możliwe, choć niezmiernie trudne jest wykonanie tego zadania, a który – jak wynika z praktyki – może wynosić nawet do 50% czasu bezpiecznego.

Przyjęcie do harmonogramu drugiego z w/w czasów może doprowadzić do skrócenia czasu trwania całego projektu, do ograniczenia wielozadaniowości i skupieniu się wykonawcy na tym jednym zadaniu, jak i do wyeliminowania – powszechnym w środowisku projektowym – zjawisk: prawa Parkinsona i syndromu studenta. Jak jednak wskazują doświadczenia autorów stosowanie "czasu agresywnego" musi związana z dodatkowymi zmianami w sposobie zarządzania projektami, takimi jak np. sposób oceny kierownika projektu i zespołu, czy styl pracy zespołu.

Inną "najlepszą praktyką" w obszarze szacowania czasu trwania jest dostosowanie metody szacowania do charakterystyk konkretnego zadania projektowego, przede wszystkim do jego zmienności. Inaczej bowiem należy do podchodzić do zadań o dużej zmienności, a zupełnie inaczej do zadań dobrze zdefiniowanych, o stałym charakterze.
Innym rozwiązaniem wartym upowszechnienia na etapie harmonogramowania może być wprowadzenie tzw. buforów, Bufory stanowią rodzaj "wirtualnych zadań", wprowadzanych na etapie harmonogramowania dla zabezpieczenia projektu i zadań przed różnymi zdarzeniami zakłócającymi przebieg projektu. Na etapie realizacji mogą być one albo "konsumowane", albo – jeśli zakłócenia nie występują – niewykorzystywane. Podejście to jest powszechnie wykorzystywane w CCPM, Może  być także wykorzystane w połączeniu z tradycyjnymi wykresami Gantta, dając tzw. zbuforowane wykresy Gantta.

Rozwiązaniem sprawdzającym się w praktyce projektowej – jak wynika z doświadczeń autorów – jest identyfikowanie i analiza obciążenia tzw. zasobu krytycznego danej organizacji, lub danego projektu. Zasób krytyczny to zasób (specjalista, dział, urządzenie) warunkujący możliwości realizacyjne danego projektu lub zbioru projektów w firmie. W naszej praktyce zwykle takim zasobem okazywał się konsultant integracyjny, dział testowania, czy unikalne urządzenie. Uwzględnienie takiego zasobu oraz jego możliwości realizacyjnych zmienia harmonogram projektu, lub projektów. Daje jednak zasadniczą korzyść: stworzony harmonogram jest harmonogramem realnym.

Podsumowanie

Przedstawione w niniejszym referacie i związane z praktycznymi doświadczeniami autorów, "best practices" inicjowania i planowania projektu obejmują kilka zagadnień. Są to zarówno analizy przedprojektowe (analiza udziałowców, analiza problemów), ze szczególnym zwróceniem uwagi na metody analizy problemu, który ma być adresowany przez projekt, jak i definicja projektu – jego podstawowe elementy ( cele, produkty, założenia, mierniki). Są to także praktyki definiowania zakresu (związane z tzw. Network Building Process), jak i praktyki tworzenia harmonogramu.
Jeśli zaś w/w zagadnienia uzupełnimy dodatkowo o planowanie ryzyka, szczegółowe szacowanie kosztów, czy planowanie komunikacji, to powstanie w pełni profesjonalny plan projektu pozwalający na osiągnięcie rzeczywistych korzyści biznesowych.

Literatura

1. Lisa J. Scheinkopf; Thinking for a Change: Putting the TOC Thinking Processes to Use
2. Frank Patrick; Taking Advantage of Rusing Resistance to Change; www.focusperformance.com
3. A Guide to the Project Management Body of Knowledge, Third Edition; Project Management Institute 2004
4. Aid Delivery Methods, volume 1: Project Cycle Management Guidelines; European