PRINCE2® wiki
« Tematy

Zmiany

Other languages: en nl fr es pt it English Nederlands Français Español Português Italiano

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ć:

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ń:

Definicja wniosku o zmianę

Definicja odstępstwa

Definicja Problemu/Obawy

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:

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

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:

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).

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:

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.:

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

W trakcie projektu

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:

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

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.

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

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ę

Zagadnienie: Odstępstwo

Zagadnienie: Problem/Obawa

Zakresy odpowiedzialności w kontekście Tematu Zmiana

discussion icon PRINCE2 wiki is open-source and published for free under a Creative Commons license.

discussion icon Written by Frank Turley (his LinkedIn profile)

discussion icon Translated by Cezary Paprocki