WARUNKOWANIE PROCESU EFEKTYWNEGO ZAMYKANIA PROJEKTU PRZEZ INTERESARIUSZY

CONDITIONING OF THE PROCESS OF EFFECTIVE PROJECT CLOSURE BY STAKEHOLDERS 

Summary: The paper presents the effects of improper stakeholder characterization carried out during the definition of the project. When preparing the RACI table, a stakeholder for the functionality group was indicated as a decision-making stakeholder. By cooperating with him during the creation of the functionality group throughout the duration of the project, he approved the functionality group. After the acceptance tests, however, it turned out that the stakeholder with whom the cooperation was carried out did not have such competences. Writing the functionality returned to the initial phase with already competent approval stakeholder. 

1. Wstęp

Zamykanie projektu ma zastosowanie zarówno po zakończeniu prac projektowych na skutek przekazania zakresu projektu do eksploatacji jak i zmian w celach projektowych podczas jego trwania, jeżeli zostanie podjęta taka decyzja.  Decyzja taka może pojawić się na skutek  zmian oczekiwań interesariuszy wyrażonych w specyfikacji (wymaganiach). Należy jednak pamiętać, iż zamknięcie projektu nie oznacza zakończenia wszelkich czynności związanych z projektem. Tak więc kluczowym wskaźnikiem od którego zależy sposób zamknięcia projektu jest stopień realizacji celu/celów biznesowych projektu przemnożony przez % wykorzystanego czasu trwania projektowego  założonego przy jego inicjacji. 

Jak widać, o zamykaniu projektu należy już myśleć podczas jego definiowania, a więc podczas fazy przygotowania projektu. 

1.1 Cel pracy

Praca została zainspirowana przypadkiem opisanym przez jednego ze studentów na zajęciach przedmiotu „Zarządzanie cyklem życia aplikacji” prowadzonych przez autora w semestrze letnim roku 2022 dla studentów 3 roku Informatyki Wyższej Szkoły Ekonomii i Informatyki  w Krakowie. Dwóch studentów opisało zdarzenie w swojej pracy. Zdarzenie jest opisane w podrozdziale Case study. 

Celem pracy jest wskazanie sposobu postępowania podczas projektu, aby uniknąć zdarzeń opisanych w Case study. Praca wykonana została z zastosowaniem metody heurystycznej.  

1.2 Case study

Projekt był prowadzony w metodyce Agile. Prace wykonywane były na podstawie BackLogu. Praca nad jedną z grup funkcjonalności rozciągała się na kilka sprintów. Osoba zatwierdzająca zmiany w priorytecie tych funkcjonalności oraz ich   jako Interesariusz Zatwierdzający wyspecyfikowany w jednej z kolumn BackLogu  cały czas pozostawała ta sama. Zatwierdzała na bieżąco zmiany w specyfikacji, potwierdzała prawidłowość realizacji pozycji BackLogu na zakończenie sprintu na podstawie testów jednostkowych. Gdy przyszło jednak do zatwierdzenia testów akceptacyjnych, okazało się że Interesariuszem Zatwierdzającym była inna osoba.  Nie dokonała odbioru finalnego funkcjonalności powodując konieczność pisania grupy funkcjonalności od nowa. 

2 Cele biznesowe Projektu

W realizacji założeń lub wymagań projektowych można wyróżnić podejście holistyczne i analityczne (liczbowe). Podejście holistyczne (bardzo często stosowane) polega na tym, że realizujemy wymagania aż do zadowolenia klienta, które wyrazi interesariusz o odpowiednim umocowaniu w projekcie zgodnie z umową realizacji. Tylko że czasami to zadowolenie wykracza poza ramy projektu, staje się pretekstem do modyfikacji wymagań dopiero na etapie odbioru. Jak temu zapobiec? 

Osoby z pewną praktyką realizacji projektów już widzą, gdzie będzie klucz do realizacji celu a więc zamknięcia projektu. Tym kluczem są interesariusze i odpowiednio zdefiniowane cele biznesowe. 

Już samo słowo cel niesie w sobie konieczność zdefiniowania. O ile w języku polskim jest to słowo uniwersalne, o tyle po angielsku jest już kilka znaczeń słowa cel. Są to np.: goal, aim, purpose, objective, destination, target. Tutaj nie będą jednak rozważane niuanse słowa cel i jego zastosowania.  Pozostaje znaczenie terminu cel jako stan do osiągnięcia. Ale i przy takim zawężeniu określenia, proponowane są różne podejścia do definiowania celów, np.: 

• SMART 
• CLEAR czy też 
• OKRS. 

Wymienione w sekwencji czasowej proponowanych jako właściwe dobre praktyki w definiowaniu celów.
Najpowszechniej znane podejście do definiowania celów to podejście SMART, czyli zadbanie o to by cel był: 

• Skonkretyzowany
  Precyzyjny, zrozumiały, prosty , konkretny. 

• Mierzalny
  Pożądane wskaźniki liczbowe jako miara wykonania. Jak ma wyglądać sytuacja po  osiągnięciu celu? 

• Atrakcyjny atrakcyjny i akceptowalny.
  Czy mieści się w granicach możliwości  i czy  motywuje? 

• Rzeczywisty
  Realny do zrealizowania i spójny z innymi politykami czy celami długoterminowymi lub do realizacji innych projektów. 

• Terminowy 
  Perspektywa czasowa. Termin osiągnięcia. 

Według autora niniejszej pracy, o zakończeniu i zatwierdzeniu projektu należy myśleć już na etapie formułowania wymagań. Otóż według ogólnie przyjętego w IT podejścia, wymagania ustala się z interesariuszami. Mamy więc na początku projektu listę wymagań i przypisanych do nich interesariuszy. Tylko czy są to odpowiedni interesariusze? 

Po pierwsze co to znaczy odpowiedni interesariusz? Odpowiedni to jest taki interesariusz, który jest władny (zgodnie z pozycją i kompetencjami w firmie) zatwierdzić realizację wymagania, a więc potwierdzić że wykonane zostało to,  co zbyło zamówione, ma odpowiednie właściwości, jest wystarczającej jakości i jest tym co zostało wyspecyfikowane przy zawieraniu umowy z uwzględnieniem wprowadzonych w trakcie trwania projektu zmian. Jak to zweryfikować? 

Według autora można posłużyć się tabelą RACI czy zwanej też z polska OWSI(Odpowiedzialny, Wykonujący, Skonsultowany, Informowany). Tabela OWSI będzie użyteczna, jeżeli jej zawartość będzie odpowiadała rzeczywistym kompetencjom interesariuszy. 

Obecnie coraz częściej, szczególnie w zastosowaniu do metodyk zwinnych stosuje się określenie celów jako CLEAR: 

• Collaborative –  stawiając na kolaborację, ściślejszą współpracę niż kooperacja, przy pełnym obustronnym zaangażowaniu i zaufaniu, 
• Limited – stosując technikę wyraźnego zarysowania granic wymagań, między innymi poprzez wyspecyfikowanie czego nie będziemy wykonywać, 
• Appreciable  – znaczący, czyli spełniający oczekiwania,  
• Refinable – jasny, dobrze określony

Przy zastosowaniu definiowania celów zgodnie z akronimem CLEAR, zastępujemy definiowanie i określanie tabeli OWSI z interesariuszami poprzez dążenie do osiągnięcia z nimi konsensusu.

Wymaganie projektowe 

Skoro cele w tym biznesowe są tak niejednoznacznie rozumiane, to skąd czerpać wiedze w projekcie o stanie, który może być uważany za końcowy stan PROJEKTU/ można tutaj zaproponować wymagania PROJEKTOWE. Tutaj już jednak należy rozważyć różnice pomiędzy metodykami kaskadowymi (np. PM-book, PRINCE2[2]), zwinnymi(Agile, Scrum, PRINCE2Agile, Prince DSDM) i pozostałymi.  

3. Definiowanie efektów projektu poprzez wymagania projektowe 

O ile zmiana wymagań projektowych przy realizacji projektów zwanych metodykami zwinnymi nie budzi wątpliwości, o tyle warto chwilę poświęcić wymaganiom w metodykach kaskadowych.  O ile powszechnie są znane wymagania projektowe w metodykach takich jak PMBOK[1], czy też IBM Rational [3]. W warunkach realizacji projektów według metodyk Waterfall zmiana definicji wymagań następuje w procesie Zarządzania Zmianą Wymagań. Nazwane jest tak wprost w przypadku . Metodyka PRINCE2 podchodzi do tego nieco inaczej. Zarządzanie wymaganiami przesunięte zostało do zarządzania produktami. W tej metodyce posunięto się nawet dalej, definiując framework PRINCE2Agile stosując wprost techniki Agile do definiowania i zarządzania wymaganiami w odniesieniu do produktów dokładnie tak, jakby to były wymagania Scrum czy Agile.  

4. Zatwierdzanie wymagań przed zamknięciem projektu.  

Jeżeli we właściwy sposób zdefiniujemy wymagania oraz sposób ich zatwierdzenia (np. scenariusze testowe) to nie będzie trudno przekonać interesariuszy o realizacji poszczególnych wymagań. Oczywiście pod warunkiem, że dobrze zdefiniujemy także tabelę OWSI podczas definiowania wymagań lub rozciągniemy osiągnięty podczas specyfikacji wymagań konsensus na etap zamykania projektu. 

5. Podsumowanie 

W pracy wykazano, iż warunkiem koniecznym poprawnego zamknięcia projektu IT prowadzonego zarówno w oparciu o metodyki zwinne jak i kaskadowe kluczowe znaczenie ma wczesne rozpoznanie i przypisanie w sposób prawidłowy interesariuszom ról według konwencji OWSI. Pozwoli to na uniknięcie trudnych pod koniec projektu negocjacji i ustaleń dotyczących wykonania zakresu projektu. 

Literatura 

PMBOK GUIDE sixth edition Project Management Institrute 2017 

PRINCE2 – Skuteczne Zarządzanie Projektami , AXELOS  01 lipca 20013 

Mastering Requirements Management with Use Cases IBM Software Group Rational University 2003 

A Guide to the  Business Analysis Body  of  Knowledge version 3.0  2016 

Łabuda W.,(2009)Wybrane aspekty planowania w metodyce PRINCE2, Zeszyty Naukowe  – Warszawska Wyższa Szkoła Informatyki, nr 69-85, Warszawa. 

Project Management Institute (2013), Guide to the Project Management Body of Knowledge (PMBOK® Guide), Fifth edition, wydanie polskie, Management Training & Development Center, Warszawa. 

Tchórzewski S. (2015), Bariery w procesie transferu doświadczeń ze zrealizowanych projektów – badania wstępne, Zeszyty Naukowe Politechniki Śląskiej, z. 78, Gliwice. 

Wysocki R. K.(2013), Efektywne zarządzanie projektami: tradycyjne, zwinne, ekstremalne; Wydanie VI, Helion, Gliwice. 

 

AFILIACJA 

Dr inż. Mirosław Bobrowski jest od 3 lat wykładowcą w Zakładzie Informatyki Wyższej Szkoły Ekonomii i Informatyki w Krakowie. Prowadził tam zajęcia : 

• Business Intelligence w Excelu 
• Zarządzanie cyklem życia aplikacji 
• DevOps 
• Analiza Biznesowa 
• Prowadzenie Projektów Informatycznych 

Ponadto od 2010 roku współpracuje jako wykładowca z Wyższą Szkołą Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie, gdzie wykładał takie przedmioty jak : 

• Analiza Biznesowa 
• Utrzymanie systemów IT 
• Prowadzenie projektów 
• SOA 
• Zastosowanie bibliotek ITIL w utrzymaniu Systemów IT 

Oraz wypromował 11 inżynierów i 7 magistrów. 

Współpracował także przez 2 semestry prowadząc wykłady Elektronika dla Informatyków Akademii Ekonomiczno-Humanistycznej w Warszawie  

Posiada praktyczną znajomość prowadzenia projektów IT nabytą podczas współpracy z Takimi firmami jak SII, IBM, ABB, HSBC, UBS, Atos, Asseco, Krakowska Fabryka Armatur, TAMEL Tarnów, Mercator Medical.  Znajomość zagadnień prowadzenia projektów potwierdzona certyfikatami PRINCE@ Foundation, Practitioner, AGILE DSDM Foundation, ITIL Foundation.