Zmiany

Z PRINCE2 Polskie
Skocz do: nawigacja, szukaj

Niniejszy artykuł jest również dostępny w językach Angielskim, Hiszpański, Francuskim, Portugalski.

Jednym z poważniejszych problemów, jakie mają Kierownicy Projektów jest umiejętność mówienia „nie” a przynajmniej jak powinni zareagować proszeni o uwzględnienie dodatkowych wymagań w projekcie. Oczywiście wszystko zależy od organizacji, ale Kierownicy Projektów mówiący „nie” są postrzegani, jako osoby nieumiejące pracować zespołowo i szybko dorabiają się opinii indywidualistów. Niektóre projekty rozpoczynane są w pośpiechu i w konsekwencji nie przeznacza się w nich wystarczającego czasu na identyfikację wymagań i przygotowanie Oposów Produktów, chociaż budżet jest już ustalony. W późniejszych fazach staje się oczywiste, że potrzebne są dodatkowe funkcjonalności i Kierownik Projektu powinien wiedzieć, jak w takiej sytuacji postępować.

To, co mi się najbardziej podoba w Temacie Zmiana to to, że Kierownik Projektu proszony o dodanie nowych funkcjonalności nie musi mówić „tak” lub „nie” a nawet będzie wdzięczny osobie proponującej zmianę, oferując jej pomoc i udostępniając do wypełnienia formularz Wniosku o zmianę. W dalszej kolejności Kierownik Projektu będzie śledził losy takiego wniosku, informując osobę zgłaszającą o decyzjach podejmowanych przez Obsługę Zmian / Komitet Sterujący.

W Temacie Zmiana zawarte są również opisy ról i odpowiedzialności Komitetu Sterującego i jego Przewodniczącego jest to bardzo potrzebne, jako że czasami będziesz i musiał im przypominać o ich obowiązkach. Widziałem już kilka projektów gdzie Przewodniczący Komitetu Sterującego naciskał na Kierownika Projektu na rozszerzenie zakresu projektu nie udostępniając jednocześnie potrzebnych dodatkowych zasobów. Temat Zmiana opisuje jak w takich sytuacjach postępować.

Większość Kierowników Projektów ma świadomość tego, że powinni kontrolować to, co się w dzieje z poszczególnymi produktami w trakcie i po zakończeniu projektu. Nazywa się to Zarządzanie konfiguracją. Zarządzanie konfiguracją dotyczy głownie śledzenia zmian, pewności, że tylko właściwe osoby mają dostęp do zatwierdzonych ostatnich wersji dokumentów i zapewnienia jednego dostępnego miejsca do przechowywania dokumentacji projektu. Niektóre firmy mają łatwe w użyciu systemy informatyczne do zarządzania informacją w projekcie, w innych te systemy są nieprzyjazne i trudne w użyciu, co kończy się zazwyczaj tym, że nie są używane. Dobra wiadomość jest taka, że obecnie w sieci dostępnych jest on-line wiele dobrych systemów tego typu, oferujących wszystkie wymagane podstawowe funkcjonalności wraz z zapewnieniem bezpiecznego dostępu do informacji.

Ostatnie zagadnienie, jakie chcę poruszyć zanim przejdziemy dalej to to, że Kierownicy Projektów nie rezerwują sobie czasu na Zarządzanie konfiguracją wierząc, że jest to coś, co mogą zrobić wieczorem przy okazji jakiegoś spotkania. A przecież zaplanowanie tej pracy to naprawdę dobry pomysł.

Przeznaczenie Tematu Zmiana

Wiedza zawarta w Temacie Zmiana jest dedykowana zasadom identyfikacji, oceny i kontroli wszystkich potencjalnych zmian produktów, które zostały zatwierdzone i uznane za obiekty odniesienia. Temat Zmiana nie jest dedykowany wyłącznie obsłudze wniosków o zmianę, dotyczy on również obsługi zagadnień, jakie pojawiają się w trakcie projektu. Lepszym stwierdzeniem będzie to, że Temat Zmiana dotyczy powszechnego podejścia do kontroli zagadnień i zmian.

Zmiana jest nieodłączną częścią każdego projektu i co za tym idzie każdy projekt powinien dysponować dobrym podejściem do identyfikacji, oceny i kontroli zagadnień, które takimi zmianami mogą skutkować. Niniejszy temat dotyczy właśnie kontroli zagadnień i zmian.

Kiedy mamy do czynienia z kontrolą zagadnień i zmian?

Kontrola zagadnień i zmian ma miejsce w całym cyklu życia projektu. Pamiętaj, ze zadanie nie polega na unikaniu zmian, ale na ich uzgodnieniu i zatwierdzeniu zanim zostaną przeprowadzone.

Każdy projekt wymaga Systemu zarządzania konfiguracją, który pozwoli na śledzenie produktów, zapisywanie informacji, kiedy produkty zostały zatwierdzone i stały się obiektami odniesienia oraz zapewnienia, że używane i dostarczane do klienta są właściwe wersje tych produktów.

Definicje dotyczące zarządzania zmianą

Zarządzanie konfiguracją

Zarządzanie konfiguracją jest technicznym i administracyjnym działaniem związanym ze zbudowaniem i eksploatacją systemu kontroli zmian i konfiguracji produktów. Ładnie można powiedzieć, że zarządzanie konfiguracją dotyczy opieki nad produktami.

Obiekt konfiguracji

Obiektem konfiguracji nazywamy produkt specjalistyczny lub zarządczy podlegający zmianom, dla którego zdefiniowany został bazowy punkt odniesienia. Na przykład dla nowego komputera może to być:

  • Część składowa komputera (wentylator, pamięć itp.)
  • Komputer widziany, jako całość
  • Wydanie komputera w konkretnej konfiguracji (definicja wydania – niżej)

Można też powiedzieć, że obiekt konfiguracji to coś, co chcemy śledzić w trakcie projektu.

Wydanie

Wydaniem jest kompletny i spójny zestaw produktów, które są zarządzane, testowane i przekazywane użytkownikom, jako pojedynczy byt. Przykładem wydania niech będzie komputer z określonym systemem operacyjnym, procesorem, określonym BIOS’em i określonymi wersjami aplikacji.

Zagadnienia

W metodyce PRINCE2 termin zagadnienie jest używany w odniesieniu do zdarzenia, które zaszło, nie było planowane i wymaga określonych działań zarządczych (np. problem, obawa lub żądanie zmiany). Wyróżnia się 3 typy zagadnień:

  • Wniosek o zmianę
  • Odstępstwo
  • Problem/Obawa, co może też być pytaniem (zawierającym potwierdzenie lub negację)

Definicja wniosku o zmianę

  • Propozycja dokonania zmiany w produkcie będącym obiektem odniesienia to jest takim, który został zatwierdzony. Może to być np. Opis Produktu do wytworzenia w danym projekcie.
  • Przykład: Żądanie interesariusza, aby produkt obsługiwał jeszcze jedną wersję językową.

Definicja odstępstwa

  • Jest to coś, co zostało uzgodnione, ale nie zostało(lub nie będzie) przez dostawcę dostarczone i z tego powodu jest niezgodne ze specyfikacją, czyli odstępstwem od specyfikacji.
  • Przykład: Dostawca nie jest w stanie zapewnić funkcjonalności pozwalającej na automatyczne odzyskiwanie hasła i z tego powodu funkcja ta będzie realizowana ręcznie przez administratora.

Definicja Problemu/Obawy

  • Każde inne zagadnienie, które Kierownik Projektu musi rozwiązać lub eskalować. Może ono mieć dla projektu zarówno charakter korzystny jak i nie korzystny.
  • Przykład: Jeden z członków zespołu projektowego został z niego oddelegowany na tydzień do innych zadań.

Podejście do zmian w metodyce PRINCE2

Sposób podejścia do zarządzania zagadnieniami i zmianą jest rozstrzygany w pierwszym etapie projektu (Etap inicjowania). Ustalone podejście może być na koniec każdego etapu zarządczego przeglądane i ewentualnie modyfikowane w ramach procesu Zarządzanie Końcem Etapu.

PRINCE2 definiuje sześć produktów zarządczych (dokumentów) mających zastosowanie w zarządzaniu zagadnieniami, zmianami i konfiguracją. Są to:

  • Strategia Zarządzania Konfiguracją
  • Zapis Obiektu Konfiguracji
  • Zestawienie Statusu Produktów
  • Dziennik Projektu
  • Rejestr Zagadnień
  • Raport o Zagadnieniu

Poniżej znajdziesz krótką charakterystykę tych produktów.

  • Strategia Zarządzania Konfiguracją : dokument zawiera informacje na temat tego jak będą obsługiwane w projekcie zagadnienia i zmiany (tzn. jak produkty będą identyfikowane, kontrolowane i jak będzie weryfikowany ich status).
  • Zapis Obiektu Konfiguracji : zawiera zestaw informacji dla konkretnego produktu (Na przykład w bibliotece centralny katalog zawiera fiszki (Zapisy Obiektów Konfiguracji) dla każdej książki (produktu)).
  • Zestawienie Statusu Produktów : jest raportem zawierającym aktualny spis produktów wraz z informacjami o ich statusie. (Np. status wszystkich produktów dostarczanych w 3 etapie przez dostawcę X).
  • Dziennik Projektu : jest rodzajem pamiętnika używanego przez Kierownika Projektu do przechowywania informacji dotyczących projektu o charakterze nieformalnym. Informacja o charakterze formalnym jest umieszczana w rejestrach.
  • Rejestr Zagadnień : zapisywane są informacje dotyczące zagadnień, mające charakter formalny.
  • Raport o Zagadnieniu : raport opisuje szczegółowo zagadnienie. Zgodnie z PRINCE2 zagadnieniem może być wniosek o zmianę odstępstwo lub problem/obawa. Raport może też zawierać informacje o innych powiązanych zagadnieniach.

PL Ch 10 1.png

Strategia Zarządzania Konfiguracją

Strategia Zarządzania Konfiguracją zawiera informacje na temat tego jak będą obsługiwane w projekcie zagadnienia i zmiany. Jednym z pierwszych pytań, jakie powinien zadać Kierownik Projektu jest to czy: Mamy w organizacji jakieś standardy kontroli zagadnień i zmian?

Jeżeli projekt jest realizowany w środowisku programu to zazwyczaj wytyczne do budowy strategii dla projektu będą dostępne. Strategia Zarządzania Konfiguracją powinna odpowiedzieć na następujące pytania:

  • P1: Jak produkty będą identyfikowane i kontrolowane(zarządzanie konfiguracją)?
  • P2: Jak będą obsługiwane zagadnienia i zmiany?
  • P3: Jakich narzędzi użyjemy do śledzenia zagadnień i informacji o produktach (np.Clarity, SharePoint)?
  • P4: Jakie informacje o każdym produkcie będą przechowywane (Zapis Obiektu Konfiguracji)?
  • P5: Jak często Kierownik Projektu będzie przeglądał sposób kontroli zagadnień i zmian (np. raz na tydzień, dwa razy w miesiącu)?
  • P6: Ko, za co będzie odpowiadał? Innymi słowy, jakie będą role i odpowiedzialności (np. kto będzie pełnił rolę Obsługi Zmian).
  • P7: Jak zagadnieniom i zmianom będą nadawane priorytety? Jakie skale zostaną zastosowane?
  • P8: Wedle jakiej skali będą oceniane priorytet i waga zagadnień (np. 1 do 4 - pomijalne, ważne itd.)?
  • P9: Jaki poziom zarządzania będzie zaangażowany w obsługę zagadnień w zależności od ich wagi?

Tak jak i trzy pozostałe dokumenty dotyczące innych strategii tak i Strategia Zarządzania Konfiguracją jest przygotowywana Przez Kierownika Projektu w Etapie Inicjowania i zatwierdzana przez Komitet Sterujący.

Jak nadawać zagadnieniom priorytety i określać ich istotność?

Jest wiele sposobów ustalania priorytetów dla żądań zmian. PRINCE2 wprowadza technikę określaną jako MoSCoW gdzie poszczególne priorytety są oznaczane jako: Musi być (Must have), Powinno być (Should have), Mogłoby być (Could have), Na razie nie musi być (Won’t have for now).

  • Musi być :(Must have) Zmiana jest kluczowa dla zasadności projektu i jej niewprowadzenie wpłynie na cele projektu (np. produkt nie będzie działał zgodnie z oczekiwaniami).
  • Powinno być :(Should have) Zmiana jest ważna i jej niewprowadzenie może osłabić Uzasadnienie Biznesowe, chociaż projekt może ciągle osiągnąć swoje cele.
  • Mogłoby być :(Could have) Zmiana jest użyteczna ale jej niewprowadzenie nie wpłynie na Uzasadnienie Biznesowe.
  • Na razie nie musi być :(Won’t have for now) Zmiana nie jest istotna lub ważna i może poczekać.

W praktyce może się okazać, że trudno nam będzie wyjaśnić takie podejście do nadawania priorytetów osobie żądającej zmiany, ponieważ ta ostatnie zawsze będzie twierdziła, że przedmiotowa zmiana jest bardzo ważna. Poniżej przedstawiono kilka pytań, jakie możemy zadać osobie oczekującej zmiany:

  • Czy produkt nie będzie działał bez tej zmiany? Jeżeli TAK to Musi być.
  • Czy bez tej zmiany Uzasadnienie Biznesowe będzie gorsze/lepsze? Jeżeli TAK to Powinno być a jeżeli nie to być może Mogłoby być?
  • Czy zmiana jest ważna, chociaż nie wpływa na Uzasadnienie Biznesowe? Jeżeli TAK to Mogłoby być w przeciwnym razie Na razie nie musi być.

Priorytet i istotność

Technika MoSCoW sprawdza się przy nadawaniu wnioskom o zmianę priorytetów, ale niewiele pomaga przy ustalaniu wagi zagadnienia. W tym ostatnim przypadku może na przykład: Użyć skali 1 do 5 albo określeń takich jak: pomijalne, istotne, krytyczne itp. Możesz też powiązać istotność z rolą. Np.:

  • Istotność Niewielka > Wsparcie Projektu
  • Istotność Normalna > Kierownik Projektu
  • Istotność Znacząca > Obsługa Zmian
  • Istotność Kluczowa > Komitet Sterujący
  • Istotność Krytyczna > Kierownictwo Programu (np. projekt poza tolerancjami)

Obsługa Zmian i budżet zmian

Obsługa Zmian to osoba lub grupa osób uprawniona do rozpatrywania wniosków o zmianę lub odstępstw. Jest to nominalnie odpowiedzialność Komitetu Sterującego, ale w przypadku, kiedy liczba zmian w projekcie może być duża Komitet Sterujący może delegować to uprawnienie na Obsługę Zmian.

Jakie osoby mogą pełnić taką rolę?

Wszystko zależy od skali i wartości projektu oraz od budżetu zmian, pieniędzy, jakie może Obsługa Zmian przeznaczyć na sfinansowanie zmian w projekcie. Może to być równie dobrze sekretarz Przewodniczącego Komitety Sterującego, członek Komitetu Sterującego, osoba odpowiedzialna za finanse w firmie albo inna osoba upoważniona.

Obsługa Zmian będzie dysponować budżetem zmian, który jest pulą pieniędzy, jakie klient i dostawca chcą przeznaczyć na pokrycie kosztów ewentualnych zmian. Zaleca się, aby każdy projekt taki budżet zmian posiadał. Komitet Sterujący może ten budżet ograniczyć maksymalnym kosztem ewentualnej zmiany albo ilością pieniędzy, jakie możemy wydać w każdym etapie.

Proces kontroli zmian ma dla Kierownika Projektu znaczenie kluczowe. Pozwól, że posłużę się przykładem. Członek zarządu organizacji prosi cię o wprowadzenie w projekcie pewnej zmiany a ty nie chcesz wyjść na osobę nastawioną negatywnie lub wprowadzić do projektu coś, co spowoduje w nim kłopoty. Mając w zanadrzu proces kontroli zmian mówisz: „Oczywiście, tu jest formularz Wniosku o zmianę. Proszę go wypełnić – mogę w tym pomóc a następnie przekazać do Obsługi Zmian do decyzji”. W ten sposób nigdy nie mówisz „nie” i cały czas jesteś postrzegany jako osoba bardzo pomocna.

Procedura zarządzania konfiguracją

Czym jest zarządzanie konfiguracją?

Zarządzanie konfiguracją jest zbiorem wszystkich działań związanych z utrzymywaniem i kontrolą zmian każdego produktu w całym cyklu życia projektu i po jego zakończeniu. Mówiąc prościej zarządzanie konfiguracją dotyczy opieki nad produktami projektu. Metodyka PRINCE2 sugeruje dla zarządzania konfiguracją 5 następujących działań:

Na starcie projektu

  • Planowanie - zakres zarządzania konfiguracją.
  • Identyfikacja - sposób oznaczania produktów.

W trakcie projektu

  • Sterowanie - działania takie jak zatwierdzanie obiektów odniesienia, archiwizowanie itp.
  • Zestawianie statusu – sprawdzanie i raportowanie o stanie grup produktów.
  • Weryfikacja i audyt – czy rzeczywisty stan produktów jest zgodny z dokumentacją?

Na starcie projektu

Planowanie: Co się dzieje podczas planowania? Zdecyduj, które dokumenty i produkty będą kontrolowane, czyli co według ciebie jest ważne. Np. w projekcie wdrożenia sytemu CRM pewno zechcesz kontrolować wszystkie główne produkty składające się na system, projekt, procesy, dokumentacje użytkownika itd.

Np. w projekcie spotkania ze 100 głównymi klientami zechcesz kontrolować zaproszenia, teksty wystąpień prelegentów, materiały przekazywane uczestnikom, catering, umowy z wynajemcami infrastruktury itp. 10.10.2 Identyfikacja: Co się dzieje podczas identyfikacji? Zdecyduj jak będą oznaczane poszczególne produkty (wybór systemu nadawania oznaczeń) Np. <kod>-<właściciel>-<wersja> (np. 045-CEPA-v04)

W trakcie projektu

Kontrolowanie: Co się dzieje podczas sprawowania kontroli nad konfiguracją? Kontrolowanie (w sensie działanie) polega na kontrolowaniu wszelkich zmian, jakie są dokonywane w produktach w trakcie projektu. Z chwilą, kiedy produkt zostaje zatwierdzony „nic nie może być ruszane i zmieniane bez autoryzacji”. Produkty odniesienia (zatwierdzone) służą również do porównywania sytuacji bieżącej z pierwotnymi celami. Kontrola oznacza też przechowywanie i udostępnianie dokumentacji, kontrolę dostępu, archiwizację i inne działania w odniesieniu zarówno do produktów zarządczych jak i specjalistycznych

Wskazówka: Pomyślcie o swoim ostatnim projekcie i o tym jak kontrolowaliście dostęp do dokumentów i ochranialiście je przed nieautoryzowanym zmianami w sytuacji gdy zostały już zatwierdzone.

Zestawianie statusu: Co oznacza zestawianie statusu? Zestawianie statusu to coś, co być może nigdy nie było twoim udziałem. Ale dobrze jest zdawać sobie sprawę, że takie działanie istnieje i może być w razie potrzeby przeprowadzone. Zestawienie statusu jest głownie związane z informacjami zawartymi w Zapisach Obiektów Konfiguracji zawierającymi następujące pozycje:

  • Identyfikator, Wersja, Data ostatniej aktualizacji, Bieżący status.
  • Właściciel, Lista użytkowników, Data następnego odbioru, Elementy powiązane etc.

Pozwólcie, że przedstawię dwa przykłady Zestawień Statusu Produktów.

  • Bibliotekarz może poprosić o raport z bazy danych książek.
  • Zapytanie: Autor = George Orwell, Data = 1940 do 1947, Status = w bibliotece.
  • Szef zaopatrzenia otrzymał fakturę z firmy X i pyta ciebie, jako Kierownika Projektu, jaki jest status produktów dostarczonych przez X w etapie 3.
  • Zapytanie: Dostawca = X, Etap, w którym produkt powstaje = 3, Obecny status = „pokaż”.

Zestawianie statusu jest rodzajem raportowania opartego o historyczne i bieżące dane dotyczące produktów w formacie dokumentu o nazwie Zestawienie Statusu Produktów.

Weryfikacja i audyt: Na czym polega weryfikacja i audyt? Zadanie sprowadza się do sprawdzenia czy faktyczny stan i status produktów odpowiada informacjom zawartym w Zapisach Obiektów Konfiguracji. Na przykład: Czy określeni użytkownicy mają dostęp do właściwych wersji produktów? Czy produkty znajdują się tam gdzie powinny? Czy mają właściwe oznaczenia? Czy są zabezpieczone przed nieautoryzowanym dostępem?

Procedura sterowania zmianami i zagadnieniami

Sterowanie zmianami i zagadnieniami dotyczy tego jak będziemy obsługiwali pojawiające się zagadnienia, które mogą być wnioskiem o zmianę, odstępstwem lub problemem/obawą. Procedura sterowania zmianami i zagadnieniami składa się z 5 kroków: Rejestrowanie, Analizowanie, Proponowanie, Decydowanie, Wdrażanie.

  • Rejestruj: Określ typ zagadnienia – formalne, nieformalne itp.
  • Analizuj: Oceń wpływ zagadnienia na cele projektu.
  • Proponuj: Zaproponuj działania – opcje, ewaluacja opcji, rekomendacja.
  • Decyduj: Ktoś musi podjąć decyzję czy zatwierdzić, odrzucić lub zarekomendować działanie.
  • Wdrażaj: Wykonanie zarekomendowanego działania (podjęcie działań naprawczych).

PL Ch 10 2.png

Na powyższym rysunku zwróć uwagę na:

  • Powiązania między Rejestruj, Analizuj, Proponuj, Decyduj i Wdrażaj.
  • Zagadnienia są eskalowane na wyższy poziom zarządzania. Może to być Komitet Sterujący, Obsługa Zmian czy wreszcie Kierownik Projektu (szczegóły alej).
  • Wszystkie informacje mogą być przechowywane w Dzienniku Projektu, Rejestrze Zagadnień i Raporcie o Zagadnieniu.

Przy założeniu, że dany etap projektu pozostaje w tolerancjach, określone decyzje mogą być podejmowane przez Kierownika Projektu. Sytuacje te powinny być określone na początku projektu w dokumencie Strategia Zarządzania Konfiguracją. Np. może się pojawić zapis ze kierownik projektu może samodzielnie podejmować decyzje odnośnie zagadnienia, jeżeli implikowane przez nie koszty nie przekraczają 500 EUR i dotyczą tylko jednego produktu.

Obsługa zagadnień projektowych

Rysunek 10.5 obrazuje jak są obsługiwane trzy różne typy zagadnień projektowych. Zagadnienie: Wniosek o zmianę

  • Formularz Wniosku o zmianę (Raport o Zagadnieniu ze statusem „wniosek o zmianę”) wypełniony informacjami takimi jak: opis, priorytet, koszty, opcje przeprowadzenia, opcja rekomendowana itp.
  • Decyzje odnośnie zmiany podejmie Obsługa Zmian.

Zagadnienie: Odstępstwo

  • Zostanie przygotowany Raport o Zagadnieniu opisujący szczegóły odstępstwa
  • Decyzje odnośnie odstępstwa podejmie Komitet Sterujący.

  Zagadnienie: Problem/Obawa

  • To wszystkie inne zagadnienia mogące mieć zarówno skutek pozytywny jak i negatywny.
  • Te zagadnienia może obsłużyć Kierownik Projektu, jeżeli utrzyma dany etap w tolerancjach lub eskalować zagadnienie na poziom Komitetu Sterującego.

PL Ch 10 3.png

Zakresy odpowiedzialności w kontekście Tematu Zmiana

  • Kierownictwo firmy lub programu
    • Udostępnienie korporacyjnej Polityki sterowania zmianami, rozwiązywania zagadnień i zarządzania konfiguracją.
  • Przewodniczący Komitetu Sterującego
    • Powołuje Obsługę Zmian i określa budżet zmian.
    • Definiuje skale do oceny istotności zagadnień i priorytetów.
    • Udziela na żądanie Kierownika Projektu wskazówek.
    • Podejmuje decyzje odnośnie zagadnień eskalowanych przez Kierownika Projektu.
  • Główny Użytkownik
    • Dziela na żądanie Kierownika Projektu wskazówek.
    • Podejmuje decyzje odnośnie zagadnień eskalowanych przez Kierownika Projektu.
  • Główny Dostawca
    • Udziela na żądanie Kierownika Projektu wskazówek.
    • Podejmuje decyzje odnośnie zagadnień eskalowanych przez Kierownika Projektu.
  • Kierownik Projektu
    • Stosuje procedurę zarządzania konfiguracją.
    • Stosuje procedurę sterowania zmianami i zagadnieniami.
    • Tworzy i utrzymuje Rejestr Zagadnień oraz przeprowadza działania korygujące.
  • Kierownik Zespołu
    • Prowadzi działania korygujące zlecone przez Kierownika Projektu.
  • Nadzór Projektu
    • Służy radą przy ocenie i rozwiązywaniu zagadnień. Sprawdza czy procedury opisane w Strategii Zarządzania Konfiguracja są właściwie stosowne.
  • Wsparcie Projektu
    • Administruje zarządzaniem konfiguracją (opieka nad produktami).
    • Pełni funkcje administracyjne dla procedury kontroli zagadnień i zmian.
    • Utrzymuje Zapisy Obiektów Konfiguracji dla poszczególnych produktów.

Odnośniki