Kierowanie projektem w metodyce Zarządzania Projektami PRINCE2

W dotychczasowych artykułach o Zarządzaniu Projektami (ang. Project Management) zaprezentowane zostały następujące zagadnienia:

  • Wymiary projektu: Produkt, Czas, Budżet i Jakość – parametry definiowania projektu i podstawa do jego oceny i korygowania
  • Metodyka Zarządzania Projektami PRINCE 2 – obowiązkowa metodyka rządu brytyjskiego
  • Pierwsza faza przedsięwzięcia – definicja projektu
  • Organizacja projektu – zdefiniowanie struktur potrzebnych w projektach, z określeniem roli poszczególnych ciał.
  • Planowanie projektu – opracowanie „mapy przyszłości" dla realizacji przedsięwzięcia.
  • Kierowanie projektem – codzienna praca Szefa Projektu w trakcie realizacji.

Metodyki Zarządzania Projektami kładą nacisk na zarządzanie zmianami (ang. Change Control) jako na podstawowy mechanizm umożliwiający pomyślne doprowadzanie projektów do osiągania założonych celów. Chociaż PRINCE 2 nie opisuje szczegółowo poszczególnych elementów tego mechanizmu, traktuje go jako niezbywalny element Zarządzania Projektami.

Jak panować
nad nieoczekiwanym?



Omówione dotychczas kolejne fazy życia projektu: definiowanie, organizacja i planowanie, miały na celu ułatwienie sprawnej realizacji przedsięwzięcia. Ich celem było możliwie precyzyjne ustalenie, jakie są cele działań i miary powodzenia, jakie czynniki potrzebne są do sprawnego wykonania prac, skąd wiadomo, że projekt zmierza do ustalonych celów. W uproszczeniu można powiedzieć, iż wysiłek koncepcyjny na początku przedsięwzięcia ma na celu maksymalnie dokładne przewidzenie rzeczywistości, przyszłych zdarzeń i oczekiwanych sytuacji. Jednak życie nie poddaje się precyzyjnemu planowaniu, zaś rozwój zdarzeń praktycznie zawsze jest inny niż założono. Zamiast bezpłodnie buntować się przeciw dynamice zdarzeń czy pozwolić na swobodną ewolucję projektu w dowolnym kierunku Szef Projektu musi dążyć do zachowania nad nim kontroli. Metodyka PRINCE 2 stawia sprawę kategorycznie: jedynym skutecznym narzędziem pomagającym w panowaniu nad zmianami jest Kontrola Zmian.

Typowe przyczyny zmian


Przyczyny zmian są bardzo różnorodne. Wbrew powszechnemu przekonaniu problemy spowodowane przez członków zespołu projektowego (np. nieterminowe wypełnianie zadań, pominięcie istotnych wymagań podczas definiowania produktów itp.), jak też przez okoliczności losowe, stanowią stosunkowo niewielką część zmian w projektach. Znacznie częściej zmiany występują z przyczyn zewnętrznych, pozostających poza kontrolą zespołu wykonawczego. Wśród najistotniejszych kategorii przyczyn zmian wymienić trzeba:

  • Zmiany w organizacji, w której realizuje się projekt, modyfikacje struktur, profilu działania itp.
  • Zmiany w otoczeniu prawnym, szczególnie pojawianie się nieistniejących dotąd regulacji: rozporządzeń wykonawczych, przepisów
    „powielaczowych" i interpretacji itp.
  • Zmiany na rynku działania firmy, dla której projekt jest realizowany – szczególnie działania konkurencji
  • Postęp techniczny – pojawienie się nowszych, lepszych technik, spadek popularności dotychczasowych produktów firmy, zmiana oczekiwań klientów co do dostępnej dla nich techniki.
  • Problemy z zasobami – niedostateczna wydajność czy jakość pracowników, niechęć pracowników do działań w projekcie, brak lub spadek motywacji itp.
  • Problemy z podwykonawcami i dostawcami – opóźnienia dostaw lub zła ich jakość, niedostateczna komunikacja, brak osób odpowiedzialnych i kontaktowych itp.

Specjalne miejsce należy się problemom z podwykonawcami i dostawcami, jednak szersze ich omówienie związane jest z zagadnieniami Zarządzania Ryzykiem.

Znaczenie zmian w projekcie


Należy pamiętać, iż ZMIANY SĄ NORMALNĄ SYTUACJĄ W PROJEKCIE, nie zaś patologią, czymś nieoczekiwanym i zaskakującym, sytuacją szkodliwą itp. Wynikają z tego stwierdzenia dwa niezmiernie istotne wnioski:

  • Zmiany występują w każdym projekcie, a zatem należy się zawczasu przygotować do ich obsługi
  • Zmiany nie są patologią, lecz rzeczywistością społeczną, dlatego też nie należy szukać winnych, lecz rozwiązań i sposobów zapobiegania problemom.

Uznanie prawdziwości obu powyższych stwierdzeń jest miarą profesjonalizmu Szefa Projektu, a jeszcze bardziej -szefów biznesowych obu stron realizujących przedsięwzięcie. Pominięcie przygotowania obsługi zmian i nie stworzenie na początku projektu odpowiednich mechanizmów powoduje znacznie większe koszty w trakcie realizacji, z całkowitą utratą kontroli nad zdarzeniami włącznie.

Realistyczne zarządzanie projektami oznacza, iż Szef Projektu ma pełną świadomość nieuchronności wystąpienia zmian i ma przygotowaną oraz uzgodnioną z partnerem metodę postępowania w takich sytuacjach. W zachodniej kulturze biznesowej typowe jest podejście
„non-blaming culture", a więc w razie kłopotów szuka się przede wszystkim rozwiązań, wyjść z trudnej sytuacji, pozostawiając szukanie winnych do czasu płacenia rachunku za nieplanowane działania. Można mieć tylko nadzieję, iż taka kultura prowadzenia przedsięwzięć znajdzie wkrótce szersze uznanie i w naszym kraju.

Zakres
stosowalności Kontroli Zmian



Zmiany w projekcie mogą mieć bardzo różną rangę. Tylko w części z nich konieczne jest stosowanie mechanizmu Kontroli Zmian, gdyż zawsze jest to pewna zwłoka, dodatkowa biurokracja itp.
Zmiany mogą dotyczyć wszystkich trzech głównych wymiarów projektu, a więc czasu (opóźnienia!), budżetu (wzrost kosztów), produktów (zła jakość,
nie spełnianie wszystkich parametrów i wymagań). Mechanizm Kontroli Zmian jest stosowany do wszystkich tych kategorii, bez wyjątku, szczególnie mając na uwadze, iż prawie zawsze zmiana wykracza poza jeden wymiar, np. opóźnienia zwykle powodują wzrost kosztów,
nie spełnianie wymagań powoduje nie uzyskanie części korzyści biznesowych itp.

Typowo, w kompetencji Szefa Projektu lub Zarządu Projektu, pozostawia się decyzje odnośnie odstępstw od harmonogramu i budżetu nie przekraczających 10% planowanych wartości, natomiast w zakresie produktów trudno ustalić tak jednoznaczną zasadę. W polskiej praktyce typowe jest, iż każda drobna zmiana w budżecie projektu wymaga decyzji Komitetu, natomiast nawet bardzo poważne opóźnienia są zwykle tolerowane bez oporu i bez eskalacji na szczebel wyższy. Nie jest to zalecane ani praktyczne i zwykle oznacza małą dojrzałość zwierzchników projektu i decydentów biznesowych. Odstępstwo od któregokolwiek wymiaru projektu winno być traktowane tak samo, dlatego niesymetryczne limitowanie uprawnień Szefa Projektu, ograniczone do aspektów pozornie niefinansowych, jest właśnie brakiem profesjonalizmu.

Określenie
i cel Kontroli Zmian



W wyniku kolejnych, niekiedy bardzo głębokich zmian, projekt potrafi bardzo daleko odejść od początkowych planów i założeń. Czy dopuszczając do odchyleń, Szef Projektu wykazuje niefachowość i brak stanowczości, czy powinien być oceniony jako niefachowiec? Metodyka PRINCE 2 mówi, iż jest wręcz przeciwnie: zmiany są nieuniknionym elementem życia, natomiast fachowość wymaga panowania nad nimi, a więc zachowywania kontroli. Ścisłe stosowanie mechanizmów Kontroli Zmian jest zatem uznawane za miarę profesjonalizmu Szefa Projektu.

Zmiany zachodzą w każdym projekcie. Kontrola zmian ma na celu reagowanie na zmiany dla uzyskania powodzenia projektu mimo niepomyślnych zdarzeń w otoczeniu.

Metodyka PRINCE 2 określa Kontrolę Zmian następująco: „Jest to mechanizm służący do zarządzania główną linią projektu poprzez wprowadzanie zgłaszanych zmian wyłącznie w kontrolowany, proceduralny i świadomy sposób". Mechanizm ten składa się z Komitetu Kontroli Zmian i z Procedury Kontroli Zmian.

Słowa wyjaśnienia należą się pojęciu linii głównej projektu (ang. baseline). W każdym momencie linią główną projektu jest jego aktualny plan. Podczas definiowania projektu powstaje pierwsza wersja planu i on właśnie stanowi w tym momencie jego linię główną. Plany są aktualizowane w miarę przyjmowania kolejnych zmian, co powoduje, iż po pewnym czasie różnią się znacznie od swoich początkowych założeń. W każdym stadium projektu linię główną stanowi zatem początkowy plan i wszystkie kolejne zatwierdzone zmiany do niego.

Kontrola Zmian jest to mechanizm umożliwiający zarządzanie linią główną projektu (ang. baseline) poprzez wprowadzanie zmian wyłącznie w świadomy, kontrolowany i proceduralny sposób.

W powyższej definicji podkreślono, iż celem Kontroli Zmian jest zachowanie kontroli nad projektem w każdym momencie jego trwania. Pojęcie kontroli było już omawiane, jednak warto przypomnieć, iż oznacza to, że osoby kierujące projektem wiedzą, co się w nim dzieje, mają świadomość konsekwencji (np. znaczenia opóźnień w niektórych działaniach), są w stanie przewidywać rozwój sytuacji i podejmować świadome działania dla jej rozwoju. Brak kontroli nad przebiegiem zdarzeń jest najczęstszą przyczyną porażek projektów, niekiedy bardzo spektakularnych. Przykładowo w oparciu o doniesienia prasowe (być może
w rzeczywistości sytuacja jest inna) wydaje się, iż bardzo głośny obecnie projekt systemu obsługi składek dla ZUS jest prowadzony bez dostatecznej kontroli, o czym świadczą dyskusje,
i niekończące się pytania kiedy właściwie projekt zostanie zakończony.
W projekcie kontrolowanym w każdej chwili Szef Projektu umie odpowiedzieć na takie pytanie, gdyż ma pełną świadomość niezbędnych zdarzeń i działań, a więc ma plan. Wspomniany przykład ilustruje również pewien ważny aspekt odpowiedzialności Szefa Projektu. W dobrze zdefiniowanym projekcie pełna odpowiedzialność za jego przebieg i wyniki spoczywa na Szefie. Jednak w razie niewyposażenia go w dostateczne uprawnienia decyzyjne (np. pozostawienia wielu decyzji poza projektem) lub przy braku partnerstwa stron (np. ukrywanie części informacji lub wzajemne obarczanie się winą za opóźnienia
– tzw. „blaming culture") ma on tylko ograniczony wpływ na przebieg zdarzeń. Istnieje więc ścisły związek między możliwościami kontrolowania projektu a przekazaniem dostatecznych kompetencji Szefowi Projektu. I niestety nawet doskonała kontrola zmian nie ulepszy takiego projektu
„maszerującego ku klęsce” (określenie wybitnego specjalisty Eda Yourdona).

Jako podsumowanie tej części zagadnienia warto wskazać, iż beneficjantami Kontroli Zmian są obie strony projektu:


  • Zespół Projektowy – kończy projekt, dostarczając oczekiwany produkt w zadanym czasie i koszcie

  • Klient/użytkownik – otrzymuje oczekiwany produkt w znanym czasie i koszcie

No i jako memento przypomnijmy, że przy porażce projektu praktycznie zawsze o wiele większe straty ponosi nie wykonawca, lecz klient. Wszyscy wierzący w przewagę klienta nad wykonawcą powinni dobrze zastanowić się nad projektem systemu ZUS.

Elementy mechanizmu
Kontroli Zmian



Pora na omówienie dwóch elementów tworzących mechanizm Kontroli Zmian: Komitetu Kontroli Zmian i procedury kontroli zmian.

Według PRINCE 2 Komitet Kontroli Zmian musi być powołany w każdym projekcie, gdyż zawsze występują zmiany. W mniejszych projektach do Komitetu wystarczy powołać 2-3 osoby, w większych
– bywa 4-6 osób. Typowym rozwiązaniem jest uczestnictwo w Komitecie Szefów Projektu z obu stron, gdyż są oni najlepiej zorientowani w aktualnej sytuacji, w planach i wpływie zmian na ich modyfikacje. Typowe jest też korzystanie z pomocy ekspertów technicznych (np. architekta systemu, projektanta, reprezentanta użytkownika itp.), gdyż jego wiedza jest zwykle niezbędna do szacowania wpływu zmian. Trzeba jednak pamiętać, iż zasiadając w Komitecie Kontroli Zmian Szef Projektu
„nosi inną czapkę” niż podczas kierowania projektem: nie ma władzy sprawczej i prawa samodzielnych decyzji, lecz ma obowiązek szukania kompromisu i negocjowania decyzji.

Do zakresu odpowiedzialności Komitetu Kontroli Zmian należą:


  • Uzgodnienie procedury Kontroli Zmian (o ile nie została przyjęta w dokumentach wcześniejszych)

  • Stworzenie skutecznych mechanizmów rozstrzygania sporów

  • Uzgodnienie kryteriów przyjmowania zmian, np. z włączeniem zmian budżetu

  • ponad 10% do kompetencji Komitetu Sterującego
  • Wnoszenie pod obrady Wniosków o Zmianę

  • Rozpatrywanie w Komitecie otrzymanych Wniosków, podejmowanie decyzji, eskalacja w razie niemożności osiągnięcia kompromisu

  • Kontrola realizacji zaaprobowanej zmiany, poczynając od aktualizacji planów.

Procedura Kontroli Zmian jest jedną z najważniejszych procedur zarządczych. Odpowiedzialność za jej zdefiniowanie, a następnie ścisłe przestrzeganie spoczywa na Szefie Projektu. Najlepiej definiować ją już na początku projektu
– zwykle w Dokumencie Inicjacji Projektu (PID) lub jeszcze wcześniej – w ofercie (szczególnie w dużych przetargach międzynarodowych). Uzgadnianie procedury jest pierwszym krokiem procesu kontroli zmian, na który składają się również:

  • Wybór członków Komitetu Kontroli Zmian

  • Ustalenie sposobu pracy, stosowanej dokumentacji, trybów negocjacji i mechanizmów, rozstrzygania sporów, zasad korzystania z ekspertów technicznych, dokumentacji działania (Wniosków o Zmianę i dokumentów decyzyjnych)

  • Obsługa zgłaszanych zmian

  • Sprawozdania ze zmian dla Komitetu Sterującego

Prawo zgłaszania Wniosków o Zmianę w zasadzie przysługuje każdemu członkowi zespołu projektowego, przedstawicielowi klienta/użytkownika, członkowi Komitetu Sterującego. Z przyczyn praktycznych zakłada się na ogół, iż przedstawiciele każdej strony kierują Wnioski za pośrednictwem swojego reprezentanta
– Szefa Projektu, który może spełnić rolę „filtra” dla wniosków bezzasadnych, niedostatecznie uzasadnionych, sprzecznych z innymi ustaleniami czy decyzjami szczebla wyższego. Może on też od razu ocenić wpływ zmiany na projekt i namówić zgłaszającego do rezygnacji w przypadku zbyt poważnych konsekwencji, np. zbyt dużego wydłużenia projektu z powodu nowych żądań użytkownika.

Sam Wniosek o Zmianę jest dokumentem o szablonie ustalonym przy definiowaniu procedury (obowiązkowo!). Oprócz samej identyfikacji zmiany (np. opóźnienie dostawy o 2 tygodnie czy zmiana założeń do tworzenia określonego produktu) oraz jej uzasadnienia konieczne jest w nim określenie priorytetu (warto w procedurze ustalić klasyfikację) oraz oszacowanie wpływu zmiany na całość prac. Większość zmian wywołuje bowiem zmiany pochodne, które powiększają koszty bezpośrednie czy dodatkowo wydłużają harmonogram. Oczywiście bywają też zmiany nie mające wpływu na inne elementy projektu, np. gdy jest możliwość ich kompensaty poprzez dodatkowe nakłady czy zasoby przewidziane i tak w budżecie projektu czy też gdy wystarczająca jest zmiana kolejności pewnych działań. Przykładowo w projekcie realizowanym w kilku kolejnych oddziałach opóźnienie przygotowań w jednym z nich nie musi powodować dodatkowych kosztów, wystarczy zmiana harmonogramu pracy ekip wykonawczych. Przy szacowaniu wpływu zwykle sięga się po pomoc odpowiednich specjalistów technicznych (np. programistów i projektantów systemu), niekiedy również skorzystać trzeba z pomocy handlowca (dodatkowe produkty) czy uzyskać aprobatę kierownictwa biznesowego (np. dodatkowe świadczenia dla klienta czy też rezygnacja z pewnych funkcji tworzonego produktu).

Wypełniony wstępnie Wniosek o Zmianę zawiera zatem:

  • Identyfikację i opis zmiany, wraz z jej uzasadnieniem i priorytetem
  • Oszacowanie wpływu według zgłaszającego
  • Ewentualne propozycje sposobu rozwiązania problemu – zalecane jest podanie różnych możliwości, co daje swobodę negocjacji z partnerem

Wniosek trafia do Komitetu Kontroli Zmian (zwykle do przewodniczącego), który prosi drugą stronę o oszacowanie wpływu zmiany, niekiedy też o propozycję modyfikacji planów. Wypełniony przez dwie strony Wniosek podlega negocjacjom w łonie Komitetu. Niekiedy zmiana nie budzi emocji i jest przyjmowana bez zastrzeżeń, częściej
– strony szukają kompromisu („ja coś tobie, ty coś mnie”), dyskutują o sposobach finansowania zmiany, porównują potencjalne opóźnienia i priorytety biznesowe projektu z priorytetami zmiany. Po znalezieniu kompromisu wszyscy członkowie Komitetu przyjmują decyzję i wpisują ją do Wniosku, zobowiązując Szefa Projektu do odpowiedniej aktualizacji planów. W razie jednak niemożliwości znalezienia wspólnego stanowiska, Wniosek jest eskalowany na szczebel wyższy
– do Komitetu Sterującego, gdzie już musi znaleźć rozwiązanie.

Wpływ zmiany na projekt szacuje się w standardowych parametrach projektu: wpływ na harmonogram, na budżet na produkty. Niekiedy oprócz specyficznej wartości wskazane jest podanie uwarunkowań, np. pomoc drugiej strony (dodatkowy ekspert), kryteria umożliwiające wprowadzenie zmiany przy decyzji warunkowej itp. Zwykle zmiana narusza więcej niż jeden wymiar, np. rozszerzenie zakresu wykonywanych produktów powoduje większe koszty.

Przyjmowana decyzja może być jednoznaczna lub warunkowa:

  • Decyzja „tak” – przyjęcie zmiany zgodnie z propozycją wnioskodawcy i uzgodnionym wpływem
  • Decyzja „nie” – odrzucenie zmiany w całości, np. z powodu zbyt poważnego wpływu na projekt, zbyt niskiego priorytetu itp.
  • Decyzja „tak, ale” – wniosek jest przyjęty, jednak nie w całej rozciągłości lub z decyzjami pochodnymi (np. wykonanie dodatkowo pewnych prac w zamian za rezygnację z innych)
  • Decyzja „nie, ale” – wniosek będzie skierowany do realizacji przy zaistnieniu pewnych okoliczności, np. jeśli pozostanie trochę wolnego czasu (do tej kategorii decyzji trafiają tzw. upiększenia produktów
    – ang. nice-to-have)
  • Decyzja „tak, ale nie dziś” – wniosek będzie zrealizowany, ale dopiero po wykonaniu prac o wyższym priorytecie

Przyjęcie praktycznie każdej zmiany powoduje konieczność modyfikacji planów projektu. Wskazane jest, aby proponowane modyfikacje były uwzględniane już podczas rozpatrywania Wniosku. Przyjęcie decyzji jest równoznaczne z aprobatą nowych wersji planów. Plan po modyfikacji stanowi nową linię główną projektu.

Uznając partnerski, a więc równoprawny charakter obu stron: wykonawcy i klienta, trzeba pamiętać, iż do zgłaszania Wniosku o Zmianę mają prawo obie strony. Typowo zmiany harmonogramu (opóźnienia) następują na wniosek wykonawcy, zaś zmiany w wykonywanych produktach
– na prośbę klienta (np. częściowa zmiana specyfikacji).

Z partnerskiego charakteru obu stron projektu: klienta i wykonawcy
– wynika, że do zgłaszania Wniosków o Zmianę mają prawo obie strony. Obie też oceniają wpływ zmiany na projekt i szukają kompromisowej decyzji.

Szukanie kompromisu dotyczy zarówno samej zmiany (np. czy wprowadzać nowe funkcje produktu żądane przez użytkownika), jak też proponowanych działań. Typowe negocjacje odbywają się w ramach opisanej wcześniej
„Maszyny Projektu”, a więc układu pracującego stabilnie przy pewnych położeniach trzech dźwigni: produktu, czasu i budżetu. Oznacza to zatem, iż zwiększając presję w jednym z wymiarów (np. rozszerzając zakres prac) należy zmniejszyć ją w innym wymiarze (np. zwiększyć budżet projektu lub wydłużyć czas pracy). Należy z całą mocą podkreślić, iż prawie zawsze modyfikacja tylko jednego wymiaru bez odpowiedniej zmiany w pozostałych oznacza naruszenie równowagi
„Maszyny”.

Istnieje oczywisty sposób zapobiegania zbyt częstemu modyfikowaniu wszystkich elementów projektu: wbudowanie rezerw do planu. Robi tak każdy doświadczony Szef Projektu i jest to podejście całkowicie uzasadnione regułami sztuki. Rezerwy w harmonogramie i budżecie muszą być przewidziane zawsze i należy z nich korzystać w razie konieczności zmian, jednak w wielu przypadkach samo sięgnięcie po rezerwy nie jest wystarczające.
Przykładowe negocjacje zmiany przez Partnerów mogą wyglądać następująco:

  • Klient zawiadamia o zmianie niektórych przepisów prawnych, co powoduje konieczność zmian w specyfikacji tworzonych produktów.
  • Wykonawca szacuje koszt zmian na dwa osobotygodnie i proponuje zwiększenie budżetu lub wydłużenie harmonogramu.
  • Klient przeznacza swego dodatkowego specjalistę, co skróci dodatkową pracę do jednego tygodnia w harmonogramie – strony przyjmują taką ocenę wpływu zmiany.
  • Klient sprawdza, czy harmonogram nie zawiera odpowiedniej rezerwy. Jeśli tygodniowy poślizg nie jest dopuszczalny, klient podejmuje się wykonania niektórych innych zadań we własnym zakresie, co umożliwia dotrzymanie harmonogramu.
  • Obie strony podpisują się pod decyzją, aktualizują plany projektu i realizują zmianę.

Przyjmując imperatyw partnerskiego podejścia obie strony wykazują dobrą wolę i najczęściej przyjmują propozycję wnioskującego co do zmiany, w praktyce zwykle jednak próbują uzyskać jakąś koncesję drugiej strony. Mamy więc do czynienia z pewnym
„krakowskim targiem”: ja wykonam dodatkową robotę z twojej winy, ale ty wydłużysz mi okres usuwania usterek czy zrezygnujesz z kar umownych. Taki
„handel” tylko pozornie wygląda na niesprawiedliwy. W istocie jest korzystny dla obu stron: zaspokaja potrzeby strony żądającej zmiany, równocześnie pozwalając na zachowanie dobrej atmosfery współpracy, a więc zbliża do uzyskania celów projektu. A to przecież jest najważniejsze.
Kategoryczne obstawanie przy własnej ocenie podczas negocjowania zmiany jest niekorzystne dla obu stron: prowadzi do porażki projektu (np. opóźnień) lub do poważnego zepsucia atmosfery współpracy.

W razie różnic w ocenie lub braku kompromisowej decyzji w łonie Zarządu Projektu konieczna jest eskalacja problemu do Komitetu Sterującego. Arbitraż w procedurze Kontroli Zmian jest jednym z najważniejszych jego zadań. Służą do tego dwie zasady działania Komitetu: reprezentacji obu stron oraz podejmowania decyzji na zasadzie konsensusu (kompromisu). Naruszenie którejkolwiek z tych zasad niweczy sens wprowadzania mechanizmów Kontroli Zmian, a więc stanowi niezmiernie poważne zagrożenie dla powodzenia projektu.

Podsumowując doniosłe znaczenie nadawane Kontroli Zmian przez metodykę PRINCE 2 należy powtórzyć, iż brak takich mechanizmów prowadzi nieuchronnie do utraty kontroli nad projektem, a w konsekwencji
– do jego całkowitej lub częściowej porażki.

Jerzy Szych