Definicja projektu w metodyce Zarządzania Projektami PRINCE 2

Wymiary projektu

Organizacja przedsięwzięć poprzez projekty jest typową formą działania w
informatyce, szczególnie przy tworzeniu nowych rozwiązań oraz wdrażaniu systemów. Dla
usprawnienia takiej formuły działań w teorii organizacji i zarządzania rozwinięto
obszar o nazwie Zarządzanie Projektami (ang. PM – Project Management). Według tego
podejścia na czele każdego projektu stoi Szef Projektu (ang. Project Manager), którego
działalność często utożsamiana jest (niestety!) z opracowaniem planów
przedsięwzięcia i kontrolą ich realizacji. Plany muszą objąć cztery główne wymiary
projektu: produkt, czas, budżet i jakość.

Przez produkty projektu rozumie się wszystko, co ma powstać w wyniku jego
realizacji: oprogramowanie, zainstalowane systemy, dokumentację, procedury, przeszkoleni
użytkownicy, zorganizowane służby serwisowe itp. Opracowanie planów w wymiarze
produktów odbywa się na podstawie definicji zakresu projektu. W projektach
realizowanych na rzecz klienta przez zewnętrznego wykonawcę (model dostawca-klient)
podstawą tej definicji jest kontrakt – umowa na realizację przedsięzwięcia. Bardzo
często załącznikiem kontraktu jest część techniczna oferty, opisująca
szczegółowo, co ma być wykonane.
Sensownie napisany kontrakt wyznacza również drugi wymiar projektu: czas. Zwykle
ustalenie to ma postać harmonogramu, którego najpopularniejszą formą prezentacji jest
tzw. Wykres Gantta czyli obraz czynności w skali czasowej, z uwzględnieniem wzajemnych
zależności i następstw, a niejednokrotnie również – zasobów niezbędnych do ich
wykonania. Często niestety błędem w rozumieniu planów projektu jest utożsamienie ich
właśnie z diagramem Gantta, tymczasem technika ta jest wprawdzie niezwykle przydatna do
ukazania bardzo istotnych elementów planu, jednak z pewnością nie stanowi jego
całości.
Z kolei budżet jest zestawieniem kosztów wykonania projektu, z rozbiciem na
poszczególne kategorie (np. koszty osobowe, wyposażenie komputerowe, infrastruktura
administracyjna i komunikacyjna, środki transportu itp.). Jest to więc plan zdobycia zasobów
realizacyjnych przy użyciu pieniędzy.
Wartości graniczne wszystkich tych wymiarów winny być zdefiniowane przed rozpoczęciem
projektu, gdyż są niezbędne dla Szefa Projektu do opracowania uzasadnionych i
wykonalnych planów realizacji.

 

Podejście procesowe – metodyka PRINCE 2

Dla usprawnienia organizacji i prowadzenia projektów powstają na świecie metodyki
Zarządzania Projektami. Tworzone są one przez duże firmy wykonawcze (np.
informatyczne), niezależne firmy doradcze (np. doradcy z Wielkiej Piątki) i organizacje
rządowe i międzynarodowe (np. Unię Europejską).
Jedną z najpopularniejszych obecnie w Europie jest metodyka PRINCE 2, opracowana w 1996
r. przez brytyjską organizację CCTA (Central Computer and Telecommunication Agency),
choć o korzeniach sięgających kilkanaście lat wstecz. Bliskie związki łączą PRINCE
2 z popularną w Polsce metodyką LBMS (firma LBMS była twórcą poprzedniej wersji
PRINCE), jak też z metodyką Unii Europejskiej MAXIME. Obecnie PRINCE 2 jest
obowiązkową metodyką wszystkich organizacji rządowych w Wielkiej Brytanii, jest
również stosowana w innych krajach oraz w organizacjach biznesowych.
Najbardziej może charakterystyczną cechą PRINCE 2 jest podejście procesowe do
zarządzania projektami, a więc opisanie cyklu życia projektu poprzez wyróżnienie jego
faz rozwojowych i zdefiniowanie procesów niezbędnych dla poprawnej ich realizacji.
PRINCE 2 wyróżnia 8 procesów głównych, każdy złożony z kilku podprocesów
szczegółowych.
Celem stosowania metodyki PRINCE 2 jest usprawnienie organizowania i prowadzenia
projektów z dowolnej dziedziny gospodarczej, nie tylko informatycznych. Jedną z
głównych cech metodyki jest więc bardzo wyraźne rozdzielenie wastwy zarządczej
projektu (organizację i kierowanie) od warstwy technicznej (wytwarzanie produktów
opisanych w zakresie projektu). Sfera techniczna jest bardzo zróżnicowana dla każdej
dziedziny zastosowań: informatyki, budownictwa, wojska, przemysłu itp., dlatego też
PRINCE 2 nie zajmuje się podpowiadaniem dobrych zasad wykonywania produktów z żadnej
sfery. Nie znajdziemy więc w niej „recept” na tworzenie czy wdrażanie
systemów informatycznych, nie ma tu sławnych „cykli projektowych”, kolejnych
kroków do wykonania i powstających dokumentów itp. Wyłączną sferą objętą PRINCE 2
jest organizacja i zarządzanie projektem, a więc dobre rozpoczęcie i doprowadzenie do
pomyślnego zakończenia działań, z wytworzeniem niezbędnych produktów, przy
dotrzymaniu planowanego czasu i budżetu.

 

Definiowanie projektu

Niezmiernie dużą wagę przywiązuje PRINCE 2 do właściwego rozpoczęcia projektu.
Podejmowanie działań bez sensownego określenia wszystkich najważniejszych elementów
uznawane jest za główną przyczynę porażek projektów, a w szczególności – tworzenia
produktów nie dających korzyści biznesowych uzasadniających poniesienie nakładów.
Dobre rozpoczęcie projektu musi zacząć się od zdefiniowania jego celów (biznesowych!)
i zadań (technicznych!), zakresu i koncepcji wykonania, jak też głównych parametrów
realizacyjnych. Wszystkie te elementy MUSZĄ być zapisane w spójnym opracowaniu,
noszącym często nazwę Dokumentu Inicjacji Projektu (ang. PID – Project
Initiation Document). Za jego powstanie odpowiadać musi zleceniodawca – Sponsor Projektu,
który tworzy koncepcję najważniejszych treści. Tylko on wie, po co chce uruchomić
przedsięwzięcie i jakich korzyści biznesowych się po nim spodziewa, kto ma korzystać
z wyników pracy (beneficjenci i użytkownicy), on też musi określić, kiedy chce
otrzymać produkty prac i ile pieniędzy chce przeznaczyć na ich wytworzenie.

W metodyce PRINCE 2 zaleca się poprzedzanie PID wcześniejszymi dokumentami:
Wprowadzeniem do Projektu i Uzasadnieniem Biznesowym i Oceną Zagrożeń, nie jest to
jednak niezbędne, gdyż najważniejsze treści obu tych opracowań są uszczegółowione
właśnie w Dokumencie Inicjacji.

Format Dokumentu Inicjacji Projektu

Dokument Inicjacji Projektu

  1. Cel dokumentu
  2. Tło projektu
  3. Cele projektu
  4. Zakres, wyłączenia, interfejsy
  5. Produkty
  6. Ograniczenia
  7. Korzyści biznesowe
  8. Zagrożenia
  9. Organizacja projektu
  10. Plan Jakości
  11. Kryteria akceptacji
  12. Plan Projektu
  13. Kontrola projektu
  14. Obsługa problemów

Poniższy schemat typowego dokumentu PID zalecanego przez metodykę PRINCE 2 zawiera:
nagłówki części (czcionka pogrubiona), charakterystykę zawartości danej części
(czcionka pochyła) i przykładowe fragmenty tekstów, jakie można wpisać w odpowiednim
miejscu (czcionka prosta).

1. Cel dokumentu:

Niniejszy dokument jest definicją projektu, dającą podstawę do zarządzania nim
oraz do oceniania postępu i mierzenia powodzenia. Jest podstawą decyzji Komitetu
Sterującego o przyznaniu zasobów do realizacji, zaś w trakcie prac – podstawą do ocen
postępu i podejmowania decyzji zmieniających dotychczasowe ustalenia w razie
wystąpienia problemów i odchyleń.

W dokumencie tym opisano następujące główne aspekty projektu:

  • Co projekt ma osiągnąć?
  • Dlaczego osiągnięcie tych celów jest istotne?
  • Kto będzie realizował zarządzanie projektem (role i zakresy odpowiedzialności)?
  • Jak i kiedy omówione tu przygotowania zostaną zrealizowane?

2. Tło projektu:

[Wszelkie źródła przedsięwzięcia i jego sponsor, poprzednie raporty czy
dokumentacja, jakie mogą wpływać na prace projektowe, inne powiązane projekty.]

3. Cele:

[Konkretnie i mierzalnie: co projekt ma osiągnąć. Warto rozdzielić cele projektu
(np. oczekiwane daty, profil wydatków) i jego wyniki (co ma być rezultatem produktów
końcowych projektu podczas ich użytkowania po zakończeniu prac)].

4. Zakres, wyłączenia i interfejsy, inne ograniczenia:

[Zakres to główne obszary, funkcje, procesy itp., jakie mają być objęte projektem.
Wyłączenia i interfejsy opisują, co znajduje się w projekcie, a co pozostaje poza nim.
Można opracować prosty „diagram zakresu” lub „diagram kontekstowy”.
Interfejsy to logiczne powiązania z innymi działaniami, np. sposób wykorzystania
tworzonych informacji, dalszy rozwój powstałych produktów itp.]

5. Najważniejsze produkty:

[Lista oczekiwanych i pożądanych produktów/ rezultatów/ wyników, jakie projekt
winien stworzyć lub uzyskać.]

6. Ograniczenia i założenia:

[Ograniczenia pod względem czasu, zasobów, funduszy i akceptacji. Jest to określenie
obszarów projektu, do których nie może on sięgnąć. Uzupełnienie ograniczeń i
wyłączeń, szczególnie odnośnie sfery biznesowej. Wszelkie inne założenia przyjęte
w związku z realizacją projektu.]

7. Uzasadnienie biznesowe i oczekiwane korzyści biznesowe

[Powody podjęcia projektu – z punktu widzenia osób finansujących działania. Projekt
powinien być mierzony również w zakresie korzyści biznesowych, do czego niezbędna
jest Analiza Kosztów i Korzyści.]

8. Wstępny Rejestr Ryzyka:

[Pierwsza, znana na tym etapie, wersja Rejestru Ryzyka – zwykle jako Ocena Zagrożeń
dla sprawnej realizacji projektu, uzupełniona o tematy do rozważenia w przyszłości.]

9. Struktura organizacyjna Projektu:

[Wskazanie osób tworzących Zespół Zarządzania Projektem – Szefa Projektu, Komitetu
Sterującego, Audytora-Szefa Jakości, Szefów Zespołów. Dla każdej z tych ról
KONIECZNIE trzeba wskazać zakresy odpowiedzialności.]

10. Plan Jakości Projektu:

[Opis podejścia stosowanego przez zespół wykonawczy dla dostarczenia produktów
spełniających oczekiwania jakościowe użytkowników. Często wskazuje się tu standardy
jakościowe dostawcy.]

11. Kryteria Akceptacji:

[Zdefiniowanie w kategoriach MIERZALNYCH wszystkiego, co ma powstać jako rezultaty
projektu.]

12. Wstępny Plan Projektu:

[Zestawienie głównych produktów, działań i zasobów niezbędnych dla uzyskania
oczekiwanych wyników projektu. Plan Projektu jest podstawą nadzorowania postępu i
kosztów w każdym etapie prac.]

13. Sposoby kontroli:

[Częstotliwość oczekiwanych przeglądów przez Kierownictwo. Przeglądy te w postaci
Ocen Zakończenia Etapów mają na celu przegląd projektu w jego ważnych momentach
(milestones) dla zatwierdzenia już wykonanych prac i przyznania zasobów na kolejny etap.
Trzeba też opisać organizację raportowania bieżącego (format, przeznaczenie,
częstotliwość): wykonawców dla klienta/użytkownika, zespołów wykonawczych dla Szefa
Projektu]

14. Proces obsługi problemów:

[Wskazanie dopuszczalnej tolerancji projektu, opis Procedury Obsługi Problemów do
stosowania przy wystąpieniu odchyleń od przyjętego planu. Bardzo zalecane jest też
podanie szczegółowej procedury Kontroli Zmian.]

15. Plany awaryjne:

[Określenie planów awaryjnych, jakie zostały przewidziane w planach projektu.
Powinny one być powiązane z Analizą Ryzyka.]

Podpis Szefa Projektu: …. Podpis Klienta/Użytkownika: …
Podpis Przewodniczącego Komitetu Sterującego ……. Data: …

 

Dla sprawdzenia jakości opracowanego Dokumentu Inicjacji Projektu warto
przeanalizować następujące zagadnienia:

  1. Czy dokument dokładnie odzwierciedla projekt?
  2. Czy projekt jest realistyczny, możliwy do wykonania, zgodny ze strategią danej
    organizacji i ogólnymi jej potrzebami?
  3. Czy jest dostatecznie solidną podstawą, żeby na niej rozpocząć projekt?
  4. Czy struktura organizacyjna projektu jest kompletna, wraz z nazwiskami i funkcjami oraz
    zakresami odpowiedzialności? Czy uwzględniono wszystkie funkcje? Czy jasne są relacje i
    poziomy uprawnień?
  5. Czy dokument ukazuje realistyczne sposoby kontroli i raportowania, odpowiednie do skali,
    zagrożeń biznesowych i biznesowej wagi projektu, jak też struktury organizacyjnej (o
    ile jest rozbudowana)?
  6. Czy sposoby kontroli zaspokajają potrzeby Komitetu Sterującego oraz Szefa Projektu i
    Szefów Zespołów? Czy są wystarczające dla zapewnienia jakości?

Jerzy Szych (shake@pol.pl) prowadził kilkadziesiąt projektów informatycznych.
Spędził 10 lat w korporacjach informatycznych w Polsce i za granicą. Obecnie prowadzi
projekty i wykłada Zarządzanie Projektami jako samodzielny konsultant.

Zarządzanie Projektami – recepta na udane przedsięwzięcia

Szanowni Czytelnicy,
Zapraszamy do nowego cyklu tematycznego, omawiającego Zarządzanie Projektami (ang.
Project Management).
Jest to dziedzina stosunkowo mało znana w Polsce, natomiast mająca ogromne znaczenie w
informatyce (i nie tylko). Główne obszary zainteresowania Zarządzania Projektami to:
efektywność ekonomiczna, organizacja i finansowanie przedsięwzięcia, kierowanie
pracami i zespołem wykonawców, kontakty wykonawców z klientami i użytkownikami.
Jakże często zdarza się, że otrzymujemy do wykonania zadanie wymagające naszej
wielkiej wiedzy i umiejętności, wskutek czego jak najspieszniej przystępujemy do jego
realizacji, nie zastanawiając się nad jego KONTEKSTEM BIZNESOWYM.
To szerokie pojęcie obejmuje przede wszystkim analizę, czy nasze prace techniczne mają
sens dla osób wydających na nie pieniądze. Bo przecież każda działalność kosztuje,
w informatyce – nawet całkiem sporo. Jeśli więc znajdzie się ktoś, kto funduje sobie
jakieś rozwiązanie, najczęściej spodziewa się godziwego zwrotu poniesionych
nakładów. Mamy więc do czynienia z normalną działalnością inwestycyjną,
podlegającą standardowym ocenom efektywności. I o tym aspekcie projektów
informatycznych nie możemy nigdy zapominać w czasie naszych przedsięwzięć.
Drugim elementem kontekstu biznesowego jest to, że dążymy do stworzenia pewnych
rozwiązań, które mają komuś przynosić pożytek i ułatwiać pracę. Rozwiązanie ma
więc zapewniać ulepszenie działalności biznesowej albo też tworzyć całkiem nową
jakość: dostarczanie nowych informacji, otwieranie nowych obszarów działalności
biznesowej itp. Musimy zatem pamiętać, iż nasze projekty są robione dla
użytkowników, którzy najczęściej nie są informatykami.
Oba te aspekty biznesowe prac technicznych są niezmiernie ważne w projektach
informatycznych. Dlatego też warto sięgnąć do dziedziny naukowej – podgałęzi Teorii
Organizacji i Zarządzania, która zwraca wielką uwagę na sensowność naszych
przedsięwzięć: do Zarządzania Projektami.


Niestety każdy z nas spotkał się niejednokrotnie z sytuacją, gdy po zainstalowaniu
komputerów, sieci, systemów, przeszkoleniu użytkowników itp. nasze rozwiązanie
okazało się mało przydatne dla użytkowników, często – nie wykorzystywane, nie
ubiane.
Realizacja wszelkich przedsięwzięć w informatyce polega na wykonaniu wielu prac
technicznych: zebraniu wymagań, napisaniu programów, zaprojektowaniu bazy danych,
opracowaniu dokumentacji, przeszkoleniu użytkowników, zainstalowaniu sprzętu i
systemów itp. Dlatego też stosunkowo łatwo ginie nam z oczu bardzo ważny aspekt
wszystkich przedsięwzięć: kierowanie nimi.
Pod tym tajemniczym pojęciem kryje się odpowiednie zorganizowanie pracy, po czym
przeprowadzenie jej w sposób zgodny z oczekiwaniami naszego zleceniodawcy – Sponsora. Po
kontekście biznesowym jest to drugi obszar zainteresowania Zarządzania Projektami: jak
spowodować, żeby nasze prace kończyły się o zaplanowanym czasie, dostarczały produkt
zamówiony przez użytkowników, a w dodatku – nie kosztowały więcej niż przeznaczył
na to sponsor.
Dorobek teorii i praktyki Zarządzania Projektami jest już bardzo znaczny, a mimo to jest
to jedna z najszybciej rozwijających się dyscyplin społecznych. Nieustannie publikowane
są nowe książki i artykuły, działają liczne stowarzyszenia zawodowe, prowadzone są
badania praktyczne.
Wszystkie te działania zmierzają do jednego celu: aby przedsięwzięcia były robione
lepiej, efektywniej i skuteczniej, na czas i nie za drogo.
Drogowskazem na tej drodze są tak zwane metodyki Zarządzania Projektami, czyli
bardziej lub mniej sformalizowane zbiory zasad, reguł, wzorców i technik związanych z
prowadzeniem projektów. Na świecie powstało ich już sporo, jednak po bliższym
przyjrzeniu się we wszystkich metodykach znajdujemy bez trudu większość elementów
wspólnych. Autor niniejszego cyklu omawia poszczególne zagadnienia na podstawie metodyki
rządu brytyjskiego PRINCE 2, ale jego zamierzeniem jest omawianie wybranych istotnych
zagadnień, a nie dostarczenie kursu metodycznego.
A wszystko to – ku zadowoleniu zleceniodawców i użytkowników, a także nas samych.
Niech zawsze w projektach przestrogą będzie dla nas gorzkie stwierdzenie jednego z
doświadczonych informatyków: „W całej swojej wieloletniej karierze
informatycznej zrobiłem wiele wspaniałych, nikomu niepotrzebnych projektów.”


Zapraszamy zatem do Zarządzania Projektami – naszej recepty na powodzenie
przedsięwzięć.

Zaczynamy od początku projektu: od tworzenia jego definicji. Kolejne części pragniemy
poświęcić dalszym zagadnieniom pojawiającym się w trakcie realizacji projektu,
sprawiającym wiele trudności, a decydującym o powodzeniu przedsięwzięcia.