Czy nieistniejącym formalnie projektem można zarządzać zgodnie z kodeksem etycznymi i dobrymi praktykami propagowanymi przez PMI?
W świecie projektów czyli bytów z definicji unikalnych mogą zaistnieć projekty tak unikalne, że aż nie istniejące. Przynajmniej oficjalnie nie istniejące. Czy coś takiego można w ogóle nazwać projektem? Czy kierowanie takim projektem może być zgodne z kodeksem etyki PMI? Czy jest możliwe zastosowanie dobrych praktyk zakreślonych w PMBOK® Guide zgodnie z ich intencją i z ich celem? Jak w takiej sytuacji nazwać rolę sponsora, kierownika projektu oraz kluczowych interesariuszy?
Geneza przykładowej samowolki
Elementem fuzji dwóch dużych spółek w ramach grupy kapitałowej jest m. in. ujednolicenie systemów informatycznych. Jedne systemy są pozostawiane, a ich zasięg stosowania rozszerza się. Inne systemy są zastępowane. Decyzje podejmowane są w oparciu o analizy ekonomiczne i nie budzą większych wątpliwości. Projekty typu roll-out są częścią programu projektów, jakim zazwyczaj jest fuzja.
W ślad za ujednoliceniem systemów reorganizowane są m.in. struktury utrzymania systemów. W przypadku, gdy ten sam system jest już w każdej ze spółek, decyzja o umiejscowieniu utrzymania jest bardzo trudna. Należy spodziewać się bezpardonowej walki o przetrwanie pomiędzy dwoma zespołami z dwóch spółek. Oczywistym jest, że walka ta będzie kosztowna i z całą pewnością nie zmieści się na liście świadomie planowanych projektów w ramach fuzji. Koszt tej walki to niechciany koszt fuzji. Czy na pewno konieczny? Kilkoro wysoko postawionych osób z obu spółek, zaangażowanych w fuzję, rozważyło podjęcie próby wypracowania docelowego rozwiązania organizacyjnego, z zaangażowaniem potencjalnie skonfliktowanych zespołów. Za wiedzą i milczącą zgodą owych VIP-ów, osoba ciesząca się ich zaufaniem i autorytetem powołała do życia projekt i ogłosiła się jego kierownikiem. Project charter został opracowany, opublikowany i… rozpoczął się projekt, który nigdy nie został formalnie zarejestrowany ani w programie projektów (w fuzji), ani w portfelu projektów dowolnej z łączących się spółek. Samowolka?
Samowolka a dobre praktyki zarządzania projektem
Zgodnie z PMBOK® Guide, Fifth Edition, projekt zostaje powołany za pomocą project charter. Wśród kryteriów, które musi spełniać project charter, jest wymóg jego akceptacji przez sponsoring entity. Ten warunek nie został spełniony. Dlaczego? Oto odpowiedzi:
- Sponsoring entity to program projektów (fuzja). Program nie posiadał specjalnej procedury powoływania projektów, stosowano przede wszystkim szeroko rozumiane dobre praktyki połączone formalnym procesem podejmowania decyzji przez osoby właściwie umocowane. Te osoby podjęły decyzję o powołaniu projektu i jednocześnie podjęły decyzję o nie rejestrowaniu projektu formalnie w programie.
- Sponsoring entity teoretycznie mogłaby być każda ze spółek lub obie spółki łącznie. Była na to nieformalna zgoda, ale – ze względu na przekonanie o nieuchronnej walce – nikt nie chciał tego projektu formalnie autoryzować. Porażka była zbyt prawdopodobna, a szybkie zamknięcie niezarejestrowanego projektu – łatwe.
- Do momentu zakończenia fuzji nie istniał jeszcze komplet procedur spójnych i wspólnych dla połączonych organizacji. Należało wniknąć w intencje istniejących procedur i zastosować te intencje. Zastosowanie właśnie wygasających/zmienianych i niespójnych wzajemnie procedur każdej ze spółki prawdopodobnie uniemożliwiłoby uruchomienie projektu.
- W każdym wariancie sponsoring entity bezwzględnie konieczne jest przestrzeganie procedur zamówień zewnętrznych i budżetowania. Za wyjątkiem zewnętrznego project managera zakontraktowanego na długi termin do programu projektów znacznie wcześniej, zamówień zewnętrznych nie było. Zespół projektowy skompletowano z pracowników obu spółek, z ówczesnych struktur utrzymania systemu. W tej sytuacji procedury budżetowe i zakupowe i tak nie byłyby stosowane.
Tryb powołania projektu w sposób minimalnie sformalizowany i szybki miał zapewnić równie szybką możliwość przerwania i zamknięcia projektu. Była to tania strategia testująca ryzyko kosztownej walki o przetrwanie. Zależnie od wyniku, planowano wykorzystać szansę na współpracę albo, rozumiejąc konflikt lepiej, szukać innej strategii. Ze względu na wysokie prawdopodobieństwo materializacji oraz istotne skutki, to ryzyko musiało zostać obsłużone w pierwszej kolejności. Risk response strategy wypracowane już w momencie tworzenia project charter nie jest błędem w sztuce.
Samowolka a kodeks etyczny
Kodeks etyczny PMI wytycza zasady postępowania zgodne z ogólnie pojętą uczciwością, szacunkiem do innych, odpowiedzialnością za swoje działania i zaniechaniem działania na szkodę. W tym projekcie etyka miała szczególne znaczenie, ponieważ nie działały (i z opisanych wyżej powodów nie mogły działać) metody standardowo przyjętego nadzoru performing organisation nad swoim projektem. Bez cienia wątpliwości, powołanie tego projektu było korzystne dla organizacji:
- Eksplorowano szansę na wykreowanie nowego procesu utrzymania systemów (jedno z obowiązkowych deliverable fuzji) przy minimalnym nakładzie czasu i pracy.
- Projekt ten, w przypadku osiągnięcia porozumienia, dawał szansę zatrzymania wysoko wykwalifikowanej kadry. Kadry, która mogła bardzo łatwo zmienić pracę, która nie musiała walczyć o swoje miejsce w świecie po fuzji.
VIP-owie przyjęli odpowiedzialność za ten projekt, jednocześnie minimalizując skutki jego wysoce prawdopodobnego szybkiego zamknięcia. Odpowiedzialność ta była udokumentowana. E-maile i dokumentacja w repozytorium projektu była tego dowodem.
Jednak najważniejsza w kontekście etyki zawodowej jest tu próba wyeliminowania prawdopodobnego konfliktu interesów i zastąpienia go scenariuszem win-win. Interes zespołu utrzymania systemów z danej spółki mógł być przecież sprzeczny z interesem docelowej organizacji po fuzji. Postanowiono temu przeciwdziałać lub co najmniej zrozumieć przyczyny.
Warto też zauważyć, że nie było innej kadry VIP-ów niż owa potencjalnie skonfliktowana w obu spółkach. VIP-owie ci mieli w ramach fuzji współpracować. Podjęto więc decyzję o zaangażowaniu zewnętrznego project maganera nie będącego stroną w konflikcie interesów, obdarzonego autorytetem i zaufaniem kadry z obu spółek, zdolnego do pokierowania pracami w kierunku znalezienia rozwiązania win-win. Zastosowano podstawową zasadę zarządzania konfliktem: zasadę zarządzania z zewnątrz. Project manager został zaangażowany do zarządzania konfliktem, z prawem do eskalacji spraw do dyrektora programu projektów (fuzji). To był “approved mitigation plan“, zgodnie z pkt 4.3.4 PMI’s Code of Ethics and Professional Conduct.
Finał przykładowej samowolki
Pierwsze dwa tygodnie wspólnej pracy w projekcie ujawniły wolę docelowej współpracy, wolę podziału zadań utrzymania systemów według kryteriów merytorycznych i ekonomicznych, i wreszcie wolę pozostania wysoko wykwalifikowanych inżynierów – informatyków w nowym, połączonym przedsiębiorstwie. Propozycja reorganizacji utrzymania systemów została przyjęta, a projekt „samowolka” zakończono. W jego miejsce powołano projekt mający zbudować nową organizację utrzymania zgodnie z propozycją. Ten projekt również zakończył się sukcesem. Inicjalny konflikt interesów okazał się twórczym impulsem.
Czy samowolki są dopuszczalne?
Regulacje prawne co do zasady nigdy nie nadążają za rzeczywistością. Jest to znany fakt. Część obowiązujących nas przepisów jest już martwa, część jeszcze nie istnieje, część nie jest dopasowana do rzeczywistości. Jeśli projekt znajdzie się w otoczeniu regulacji prawnych istotnie nie nadążających za rzeczywistością, samowolka – w kontekście obowiązujących procedur/regulacji – może być jedynym sprawnym rozwiązaniem. Od kierowników projektów oczekuje się przecież działania proaktywnego i pro-klienckiego. Musi być to jednak działanie bez cienia wątpliwości korzystne dla performing organisation, realizowane zgodnie z kluczowymi dobrymi praktykami zarządzania projektem oraz za wiedzą i zgodą decydentów.
Trener w firmie ValueTank, niezależny kierownik dużych projektów wdrożeniowych IT oraz niezależny doradca w dziedzinie zarządzania. Specjalizuje się w kierowaniu projektami o wysokim ryzyku niepowodzenia, budżetowaniu projektów oraz controllingu w IT. Prowadzi zajęcia z zarządzania projektami ma studiach MBA na Akademii Leona Koźmińskiego oraz z controllingu i budżetowania w IT na studiach podyplomowych „Efektywne Zarządzanie IT w przedsiębiorstwie” w Szkole Głównej Handlowej. Posiada certyfikat PMP, PRINCE2 Foundation oraz Gartner TCO Ekspert. Jest członkiem PMI Poland Chapter.