PRINCE2® dla IT – fakty i mity

0
721

Projekty kojarzą się bardzo często z kłopotami, nieporozumieniami, niedotrzymanymi terminami i dyskusyjną jakością produktu końcowego.

Natomiast projekty, które są związane z produktami informatycznymi, kojarzą się wielu osobom z BARDZO dużymi kłopotami, między innymi z walką IT z tzw. Biznesem, niemożnością zaangażowania owego Biznesu do projektów, trudnościami w ustaleniu co jest potrzebne, niechęcią do potwierdzania ustaleń i wykonywania testów odbiorczych.

Jak temu zaradzić?

Czy ktoś pamięta jeszcze jak 20 lat temu staliśmy w kilkugodzinnych kolejkach, aby wypłacić swoje pieniądze z tzw. książeczki oszczędnościowej? Czy ktoś dzisiaj poważnie traktowałby bank, który nie udostępniłby swoim klientom internetowego dostępu do konta z możliwością opłacenia rachunków, przelewów oraz wypłat w bankomacie?

Chyba nikt nie zaprzeczy jak ważną role w zwykłej, codziennej działalności biznesowej pełnią techniki informatyczne. Dziś nie sposób wyobrazić sobie żadnego banku, operatora telekomunikacyjnego czy nawet firmy szkoleniowej, która nie stosowałaby informatyki we wsparciu swoich procesów biznesowych.

Jedna grupa specjalistów wskazuje na to, że to coraz bardziej liberalizujący się rynek wpływa na rozwój i wykorzystywanie nowych technologii. Po to, aby zaoferować produkt lub usługę lepszą, bardziej atrakcyjną i tańszą. Druga grupa specjalistów uważa odwrotnie, że to nowe technologie były i są pierwotnym czynnikiem zmiany i wzrostu liberalizmu rynkowego w takich obszarach jak bankowość, usługi telekomunikacyjne czy ubezpieczenia. Ta druga grupa twierdzi nawet, że to nowe techniki informatyczne spowodowały koniec komunizmu w Europie. Trudno orzec, kto ma w tym sporze rację, ale na pewno zgodzimy się, że bez informatyki nie moglibyśmy się już obejść.

Kontekst

Wszystkie zmiany biznesowe każdej organizacji wprowadzane są dzięki projektom lub – w przypadku większych, transformacyjnych zmian biznesowych – poprzez programy.

Projekty kojarzą się bardzo często z kłopotami, nieporozumieniami, niedotrzymanymi terminami i dyskusyjną jakością produktu końcowego. Projekty, które są związane z produktami informatycznymi, kojarzą się wielu osobom z BARDZO dużymi kłopotami, między innymi z walką IT z tzw. Biznesem, niemożnością zaangażowania owego Biznesu do projektów, trudnościami w ustaleniu co jest potrzebne, niechęcią do potwierdzania ustaleń i wykonywania testów odbiorczych. „Oni nie potrafią zrobić dla nas tego czego potrzebujemy” – mówi Biznes. „Oni nie potrafią nam powiedzieć, czego potrzebują i nie chcą uczestniczyć w projektach informatycznych” – odpowiada IT.

Takie rozmowy są codziennością w wielu organizacjach. Potwierdzają to opinie uczestników szkoleń z zarządzania projektami, które prowadzę jako akredytowany trener, oraz moje osobiste obserwacje gdy jako kierownik projektu lub ekspert przy wdrażaniu najlepszych praktyk zarządzania projektami współpracuję z przedstawicielami różnych organizacji.

Diagnoza

Postanowiłem zdiagnozować, co jest źródłem tych kłopotów i może także coś doradzić. Przyjrzałem się zatem objawom chorobowym i odniosłem je do doskonałej (nie tylko moim zdaniem) metodyki zarządzania projektami jaką jest PRINCE2.

Objaw nr 1: Syndrom projektu „informatycznego”

W wielu organizacjach używane jest pojęcie projektu „informatycznego”. Projekty zdaniem wielu dzielą się bowiem na „informatyczne” i „nieinformatyczne”. Podobno trzeba je inaczej prowadzić, odmiennie nimi zarządzać i rzeczywiście – do tych informatycznych stosuje się osobne procedury, które czasem są udokumentowane a częściej jednak mają charakter zwyczajowy. Zadaję często pytanie w jaki sposób można odróżnić projekt „informatyczny” od „nieinformatycznego”? Czy jeżeli używamy notebooka do prowadzenia korespondencji w projekcie to znaczy, że projekt jest już „informatyczny”, czy to może jeszcze nie jest wystarczające kryterium do takiej nobilitacji?

Aby odnieść się do pojęcia projektu „informatycznego” wypada przytoczyć samą definicję projektu zawartą w metodyce zarządzania projektami PRINCE2:

Projekt to organizacja tymczasowa, powołana w celu dostarczenia jednego lub więcej produktów biznesowych według uzgodnionego Uzasadnienia Biznesowego.

 

A więc wszystkie projekty są biznesowe(!), albowiem projekty dostarczają produkty biznesowe. Nie ma projektów „informatycznych”.

Owszem, wśród produktów biznesowych projektu mogą być PRODUKTY informatyczne (np. nowy system, nowa lub zmodyfikowana funkcjonalność), ale raczej nie będą one jedynymi produktami, jakie projekt powinien dostarczyć. Gdyby produkty informatyczne miały być jedynymi produktami projektu, a tak często się planuje, to mielibyśmy do czynienia z chorobowym zjawiskiem fragmentacji projektu, co opisano dalej.

W każdym bądź razie wydzielanie projektów „informatycznych” z puli wszystkich projektów organizacji nie buduje właściwej struktury zespołu i nie ułatwia zaangażowania użytkowników w projekcie. Chcę bardzo podkreślić, że „czepiam się” projektów „informatycznych” nie dla tego, że jest to żargon i nie dlatego, że metodyka zarządzania projektami ich nie wyróżnia, ale przede wszystkim, że patologicznie jest to zasłona używana do izolowania się działów IT i funkcjonowania ich we własnym kręgu, usprawiedliwienie dla braku zaangażowania użytkowników w projekt („skoro projekt jest „informatyczny” to niech go robią sami informatycy”) i braku przyjmowania na siebie przez kogokolwiek odpowiedzialności za całość zmiany biznesowej, jaką ma umożliwić projekt.

Objaw nr 2: Syndrom dwóch Kierowników Projektu: Kierownik Projektu od IT i Kierownik Projektu od Biznesu

W wielu organizacjach mamy projekty z dwoma Kierownikami Projektu. Jeden jest nazywany „od IT” lub „informatyczny” a drugi „od Biznesu” (lub „biznesowy”). Metodyka zarządzania projektami jest w ocenie tego syndromu bezlitosna: w projekcie może być tylko jeden Kierownik Projektu. Tylko jedna osoba może w danej chwili pełnić obowiązki Kierownika Projektu – kierownika całego projektu biznesowego, który dostarcza wiele różnych produktów.

Tymczasem taki Kierownik Projektu „od IT” interesuje się wyłącznie tym, co robi dział czy pion IT. Zarządza specjalistami od programowania, baz danych, serwerów. Kieruje specjalistami odpowiedzialnymi za rozwojowe prace informatyczne, ale nie myśli w kategoriach zmiany biznesowej całej organizacji. A tego wymaga się od właściwego Kierownika Projektu.

Na egzaminie z podstaw PRINCE2 pojawia się czasami pytanie o wskazanie takiej roli w strukturze zespołu zarządzania projektem, która pracuje na rzecz wszystkich kategorii / grup interesariuszy projektu, czyli Dostawcy, Użytkownika i Biznesu. Przyjrzyjmy się ramowej strukturze zespołu zarządzania projektem.

Prawidłową odpowiedzią na to pytanie z egzaminu jest oczywiście Kierownik Projektu. Tylko on wykonuje prace dla wszystkich grup interesariuszy i myśli w kategorii całości przedsięwzięcia. Kierownik Projektu nie może być utożsamiany z rolą Dostawcy czy Wykonawcy w projekcie, a niestety tak bardzo często się dzieje. Gdybym mógł zaproponować inną nazwę dla tej roli to uważam, że „Kierownik Przygotowania Zmiany Biznesowej” byłoby adekwatną nazwą w stosunku do obowiązków jakie Kierownik Projektu powinien podjąć. Występujący w wielu organizacjach tzw. Kierownik Projektu „od Biznesu” z reguły nie spełnia tego obowiązku, gdyż w ramach projektu Kierownik Projektu „od IT” mu nie podlega i działają oddzielnie rozmywając odpowiedzialność za cały projekt.

A czy właściwie rozumiany Kierownik Projektu może być specjalistą informatykiem? Oczywiście!

Metodyka nie zabrania specjalistom IT pełnić obowiązków Kierownika Projektu i jednocześnie współdzielić rolę Kierownika Zespołu IT, pod warunkiem że w ramach obowiązków Kierownika Projektu będzie to kierowanie CAŁYM projektem, a nie tylko obszarem dostarczania produktów informatycznych. To może być bardzo trudne lub nawet niemożliwe, gdyż często specjalista informatyk ma wiedzę specjalistyczną, potrafi kierować zespołem specjalistów informatyków, ale nie ma kwalifikacji do kierowania CAŁYM projektem. Może też się zdarzyć, że organizacja nie jest wystarczająco dojrzała, aby komukolwiek pozwolić na kierowanie całym projektem w układzie macierzowym ponad poszczególnymi działami.

W wielu poważnych modelach organizacyjnych zakłada się istnienie niezależnej jednostki specjalistycznych Kierowników Projektów, spośród których do każdego projektu mianowany jest jeden i podlegają mu zespoły informatyczne, techniczne oraz zespoły użytkowników – kierowane odpowiednio np. przez Kierownika Zespołu IT, Kierownika Zespołu Techniki Sieciowej, Kierownika Zespołu Sprzedaży itp. W niektórych kulturach organizacyjnych unika się używania nazwy Kierownik Projektu „od …”. Zamiast tego mamy koordynatorów działowych, ale to nie zmienia istoty problemu, gdy koordynator myśli wyłącznie perspektywą swojego działu.

Obserwowane przeze mnie w wielu przedsiębiorstwach patologie prowadzą do konkluzji, że większość projektów naprawdę wcale nie ma Kierownika Projektu. Nikt nie dba o cały projekt, dba się natomiast przede wszystkim o interesy własnych działów. Całe projekty nie mogą być zatem efektywnie realizowane w takim środowisku.

Objaw nr 3: Syndrom fragmentacji projektu

Opowiadano mi o przypadku, gdzie pewna firma ubezpieczeniowa wpadła na pomysł, aby z okazji Świąt zaproponować promocję na zakup różnych polis ubezpieczeniowych, pod warunkiem że klient zakupi kilka od razu (np. polisę na samochód, mieszkanie, życie). Został powołany projekt, pod nadzorem Kierownika Projektu „od IT” dokonano stosownych i wcale niemałych zmian w kilku systemach informatycznych tak, aby można było „w paczce” sprzedawać i obsługiwać wiele polis oraz łącznie obliczać należności. A gdy do Call Centre zadzwonił pierwszy klient, który chciał zakupić wszystko na raz po promocyjnej cenie, obsługa była zaskoczona. Pracownicy Sprzedaży nie tylko nie zostali bowiem przeszkoleni z nowego produktu i zasad jego sprzedaży, ale nawet nie wiedzieli, że wszedł on do oferty firmy. Kierownik Projektu „od IT” nie czuł się w żadnym wypadku odpowiedzialny za ten stan rzeczy, bo przecież dział IT skutecznie wykonał interfejsy między różnymi systemami i bazami danych. „One przecież działają” – twierdził.

W tym projekcie nie było Kierownika Projektu (całego) i doszło również do nieprawidłowego określenia produktu końcowego projektu (lub nawet nie określono go wcale). Zjawisko to nazywam fragmentacją projektu i ilustruję słuchaczom następującym rysunkiem.

Oznaczony przerywaną linią największy prostokąt, to ten obszar, którym nikt nie zarządza i który jest tym, co w wyniku projekt powinien dostarczyć jako produkt końcowy. Wewnętrzne prostokąty to zakres, do którego poczuwają się poszczególne działy. Niektóre zakresy w sposób nieskoordynowany pokrywają się, ale są też obszary, którymi od początku nikt się nie zajmuje (często zostają odkryte pod koniec lub nawet po zakończeniu projektu i następuje próba ich wykonania na zasadzie tzw. „wrzutek”). Tu Dział IT zmodyfikował systemy informatyczne, niezależnie Dział Marketingu dokonał internetowej promocji nowego produktu, a o Dziale Sprzedaży zapomniano.

Co zatem powinno być produktem końcowym wspomnianego projektu z polisami ubezpieczeniowymi? Na pewno nie „Zmodyfikowane systemy IT”. Raczej „Organizacja w pełni przygotowana do sprzedaży i obsługi zintegrowanej polisy”.

Gdyby istniał właściwy Kierownik Projektu i stosował technikę planowania opartą na produktach, to produkt końcowy tego projektu składałby się z produktów jak na powyższym diagramie struktury produktów i objąłby również szkolenie Działu Sprzedaży. Wykonanie projektu w zakresie jedynie produktów IT i wykonanej ad hoc poza projektem promocji marketingowej zakończyło się fatalnym rezultatem biznesowym.

Objaw nr 4: Syndrom budżetowania projektów na działy IT

Jeżeli na podstawie analizy poprzednich objawów nie ma już wątpliwości, że projekt to zmiana biznesowa w całej organizacji i że powinna angażować wiele obszarów funkcjonowania firmy, to oczywiste jest również, że nie wolno dopuścić do rozumienia, że to jakiś dział / pion / wydział lub inna jednostka liniowa prowadzi projekt. To cała organizacja prowadzi (a przynajmniej powinna prowadzić) projekty i programy w ramach zarządzanego portfela wszystkich zmian.

Dlatego przypisywanie budżetu projektów na poszczególne komórki organizacyjne, w tym na dział IT (dla tzw. projektów „informatycznych”, o czym było wcześniej), jest tylko pogłębianiem przyczyn złego stanu rzeczy. Nie buduje się wówczas zespołowości pracy nad projektem, ani poczucia, że to cała organizacja wprowadza zmianę. Projekt powinien mieć swój budżet określony na etapie Przygotowaniu Projektu przez Kierownika Projektu wspieranego przez Kierowników Zespołów (w tym Zespołu IT) i pod nadzorem Komitetu Sterującego. Tylko takie wnioski budżetowe powinny być rozpatrywane.

Co się dzieje, gdy pomijamy proces Przygotowania Projektu i wnioski budżetowe mogą składać poszczególne działy może być tematem osobnej rozprawy lub artykułu.

Objaw nr 5: Metodyki dla IT i nie dla IT

Ten objaw chorobowy pojawia się coraz rzadziej, ale zdarza się, że specjaliści IT negują potrzebę metodyki takiej jak PRINCE2. „Przecież my stosujemy np. RATIONAL lub SCRUM” – można czasem usłyszeć. Lub „Nasza baza danych ma własną metodykę”.

Oczywiście nikt nie broni specjalistom IT stosowania specjalistycznych metodyk dostawczych lub wytwórczych np. dla produkcji oprogramowania. Wprost przeciwnie, należy je również rozwijać i doskonalić. Takie specjalistyczne metodyki ani nie są sprzeczne ale nie zastąpią metodyk zarządzania zmianą biznesową: np. PRINCE2 dla zarządzania projektami czy MSP® dla zarządzania programami. PRINCE2 i MSP dotyczą bowiem zarządzania ważnymi obszarami funkcjonowania organizacji. RATIONAL czy SCRUM pomagają natomiast w efektywnym tworzeniu oprogramowania.

Jak zatem leczyć?

Przede wszystkim trzeba sobie uprzytomnić, że leczenie nie należy do obowiązków poszczególnych działów tylko Zarządu całej organizacji. Za Ład (piszę go wielką literą, mówimy bowiem o ważnym obszarze zarządzania organizacją, tak samo ważnym jak Księgowość, Finanse, Kadry) w obszarze zarządzania projektami, programami i portfelem zmian odpowiada Zarząd lub osoba bądź jednostka mająca kompetencje w tym zakresie i odpowiedzialność powierzoną przez Zarząd, wraz z mechanizmami egzekwowania Ładu.

Szkolenia dotyczące najlepszych praktyk zarządzania (w tym PRINCE2) mogą być jedynie wstępem do kompleksowego programu wdrożenia Ładu np. opartego na poradniku P3O®. Sposobem na Ład są bowiem Biura Projektów, Programów i Portfolio, które wprowadzają standardy procesu projektowego, zapewniają wsparcie merytoryczne, nadzór zewnętrzny i nawet zasoby z konkretnymi umiejętnościami (np. Kierownicy Projektów i Programów). Wprowadzenie standardu P3O dokonuje się poprzez transformacyjną zmianę w organizacji (na przykład programem zarządzanym metodyką MSP).

Wprowadzanie Ładu nie może się udać, gdy bierze się za to jakiś dział (np. IT) lub gdy chce go narzucić innym jednostkom organizacyjnym. To musi być strategiczna decyzja Zarządu z bardzo mocnym i konsekwentnym wsparciem dla jej wykonania w całej organizacji (wszystkich działach).

Co można doradzić Działom IT na zasadzie doraźnej?

  • Promować najlepsze metodyki na terenie organizacji i uświadamiać Zarząd o konieczności wprowadzenia kompleksowego Ładu w organizacji obejmującego projekty, programy i portfel zmian
  • Nie brać odpowiedzialności za wprowadzenie metodyki zarządzania projektami w całej firmie – to się nie uda! Działy IT nie są od zarządzania projektami w całej firmie.
  • W projektach specjaliści IT powinni występować jako zorganizowane zespoły zarządzane przez Kierownika Zespołu – nigdy nie powinni nazywać się Kierownikiem Projektu „IT” i kategorycznie zaprzeczać istnieniu tzw. projektów „informatycznych”, zarządzanych rzekomo inaczej niż inne
  • Wskazywać na potrzebę mianowania Kierownika Projektu, z którym Kierownik Zespołu IT (i Kierownicy innych zespołów) mogliby efektywnie współpracować
  • Nie wnioskować o budżety projektowe – niech robią to raczej użytkownicy

 

Zdaję sobie sprawę, że wkładam kij w mrowisko. Może nawet ktoś poczuł się oburzony, bo funkcjonował w świecie projektów „informatycznych” i wszystkie negatywne zjawiska z tym związane traktował jako nieunikniony lub wręcz konieczny skutek uboczny projektów.

Tak być jednak nie musi. Może być Ład! Opisują go wszystkie metodyki i poradniki OGC. Metodykę PRINCE2 i wynikające z niej przemyślenia związane z Ładem projektowym gorąco polecam wszystkim. Nie tylko specjalistom od IT. Przede wszystkim Zarządom, gdyż to one odpowiadają za efektywne zarządzanie organizacją. A o tę efektywność tutaj przecież chodzi.

Autor – Krzysztof Małus – jest ekspertem w dziedzinie zarządzania projektami i programami. Od kilkunastu lat zarządza zmianami w praktyce w firmach z branż telekomunikacyjnej, informatycznej i mediowej oraz w administracji publicznej. Akredytowany trener PRINCE2® i MSP®, certyfikowany Project i Programme Manager (PMP®, PRINCE2® Practitioner, MSP® Advanced Practitioner). Współautor polskiej wersji podręcznika PRINCE2® oraz polskiej wersji podręcznika MSP®. Konsultant w zakresie budowy biur projektów (PMO). Udziałowiec i wiceprezes OMEC Sp. z o.o.

PODZIEL SIĘ
Redakcja 4PM.pl
Misją 4PM.pl jest pomaganie Project Managerom w ich codziennej pracy poprzez dostarczanie informacji i wiedzy z zakresu zarządzania projektami.

BRAK KOMENTARZY

ZOSTAW ODPOWIEDŹ