PMO vs Agile PM - case study jak połączyć te dwa światy

Właściwe zarządzanie projektami to przepustka do nowych biznesowych możliwości i osiągnięcia maksymalnej efektywności. W tym zakresie dysponujemy wieloma alternatywnymi podejściami i narzędziami. Choć wydaje się, że PMO i Agile PM się wzajemnie wykluczają, wcale nie musi tak być.

Projekty stały się sercem współczesnego biznesu. Rządzą coraz częściej nie tylko światem wielkich korporacji, ale również zdecydowanie mniejszych podmiotów. Właściwie prowadzone i zarządzane przynoszą znakomite rezultaty niezależnie od rozmiaru firmy i branży, w której działa. Siłą rzeczy powstało także wiele rozwiązań, pozwalających na właściwe sterowanie procesami i posiadanymi zasobami. Dwa podstawowe z nich różnią się przede wszystkim podejściem do samej kwestii realizacji projektu. Metoda klasyczna (kaskadowa, waterfall) stawia na jasne określenie założeń i skrupulatne trzymanie się planu, szeroka metodyka Agile zakłada natomiast zwinne reagowanie na zmiany i stawianie na kontakty interpersonalne. PMO, czyli Project Management Office, kojarzy się głównie z zarządzaniem w tym pierwszym, bardziej formalnym środowisku. Takie podejście to błąd. PMO może dać znakomite rezultaty również w Agile PM. Musi być jednak zgodne z podstawowymi ideami, stojącymi za tą koncepcją zarządzania projektami.

Weź udział w "Project Management Forum" >>

PMO vs. metodyka Agile? To mit

Biuro zarządzania projektami jest sercem wielu organizacji wykorzystujących model kaskadowy. Nic w tym dziwnego, jego kompetencje są bardzo szerokie i umożliwiają koordynowanie działań, nadzorowanie przebiegu prac oraz kontrolę dochowywania najwyższych standardów. Jednocześnie często, zwłaszcza podczas przejścia na metodykę Agile, słyszy się o tym, że utrzymywanie PMO nie ma najmniejszego sensu i jest jedynie bezużytecznym reliktem przeszłości. Agile PM jest w końcu w zdecydowanie większym stopniu zdecentralizowane, a cała procedura towarzysząca realizacji założeń i codziennych obowiązków wygląda zupełnie inaczej. Chociaż w większości z nich brakuje miejsca dla klasycznego project managera, nie niknie wcale potrzeba sprawnego zarządzania, zwłaszcza jeżeli organizacja zajmuje się wieloma procesami jednocześnie. Czy metodyka Agile wyklucza wobec tego PMO? Absolutnie nie. Wymaga jednak zupełnie innego podejścia do tej struktury.

Zwinność w sercu projektu

Niezależnie od wybranego podejścia, decydując się na przejście na metodykę Agile, należy przede wszystkim skupić się na podstawowych wartościach, wokół których jest ona skupiona. Wbrew pozorom to nie takie trudne: zostały zebrane w manifeście Agile, zawierającym zaledwie cztery ogólne, łatwe do interpretacji punkty:

• jednostki i interakcje są ważniejsze od procesów i narzędzi
• działanie produktu jest ważniejsze od towarzyszącej mu dokumentacji technicznej
• współpraca z klientem ma wyższy priorytet od negocjowania kontraktów
• reagowanie na zmiany jest ważniejsze od restrykcyjnej realizacji założonego planu.

Czy PMO wyklucza wcielenie ich w życie? Oczywiście, że nie. Chyba że wizja jednostki odpowiedzialnej za nadzorowanie projektów uniemożliwi realne implementowanie w organizacji metodyki Agile. Łatwo w takim przypadku o fasadowe zmiany, które w rzeczywistości będą oznaczały jedynie modyfikacje na poziomie nomenklatury, w rzeczywistości nie przełożą się natomiast w żadnym stopniu czy to na przyjęty model pracy, czy na realną zmianę podejścia do kwestii wykorzystywania zasobów i organizację relacji zarówno wewnątrz zespołów, jak i w kontaktach z klientem.

Zwinne PMO? To możliwe, ale nie takie proste

PMO istniejące wewnątrz organizacji wykorzystującej metodykę Agile powinno spełniać dwie podstawowe funkcje: 

• zapewniać odpowiednie środowisko organizacyjne, okazujące pomoc we właściwym sterowaniu konkretnymi projektami i weryfikujące stopień przyswojenia oraz realizacji zasad Agile PM. Pod tym względem może okazać się zbawienne zarówno dla konkretnego projektu, jak i całej organizacji. Łatwo wyobrazić sobie w końcu sytuację, w której kryjąca się w samej nazwie metody zwinność przekształca się w chaos i pewnego rodzaju anarchię. Często wynika to z błędów popełnianych na samym starcie i kryjących się w błędnie pojmowanych założeniach metodyki Agile: lekceważenie procedur i przyjętych standardów sprawia, że zarządzanie projektami staje się coraz mniej wydajne, a realizacja obowiązków nie ma już nic wspólnego ze „zwinnością”.
• PMO nie może „dusić” zespołów. Z drugiej strony istnieje także spore zagrożenie: nazwa Agile PM nie wzięła się znikąd i aby metodyka przyniosła oczekiwane rezultaty, nie może zostać zduszona nawałami biurokracji i dodatkowych – wykraczających poza przyjęte schematy – procedur. PMO, które źle przejdzie proces transformacji, może przeobrazić się w instancję, która na dobrą sprawę uniemożliwia wyzwolenie pełni potencjału.

Poszukiwania złotego środka są trudne, ale jak najbardziej potrzebne. Zawiodą się jednak te osoby, które oczekiwałyby uniwersalnej recepty, pozwalającej na natychmiastową optymalizację procesów w dowolnym podmiocie. Każda organizacja jest inna, ma unikalny profil, potrzeby oraz listę potencjalnych zagrożeń. Dlatego też tak ważne jest zdobywanie wiedzy i umiejętna analiza doświadczeń specjalistów, którzy odnieśli sukcesy w tym zakresie. Znakomitym sposobem na ich poznanie będzie konferencja Project Management Forum, pozwalająca na zdobycie narzędzi niezbędnych do przeprowadzenia transformacji zgodnej z metodyką Agile.

Dwa scenariusze: dobry i zły

„Mam dwie wiadomości: dobrą i złą”. W ten sposób rozpoczyna się wiele dowcipów i opowieści. Zasadniczo w taki sposób możemy również rozpocząć rozważania na temat współistnienia PMO i Agile PM. Chociaż to dwa skrajne przykłady, w rzeczywistości wcale nie tak trudno o ich zaistnienie, a ostatecznie nawet uplasowanie się pomiędzy nimi odbierze nam wiele korzyści wynikających z wykorzystywania metodyki Agile. Lektura dwóch potencjalnych scenariuszy powinna uzmysłowić nam natomiast, że dobre PMO, wykorzystujące pełnię zwinnego potencjału, znakomicie sprawdzi się w środowisku Agile.

Zły scenariusz: PMO niszczy Agile PM

Metodyka Agile zakłada szeroko pojmowaną autonomię zespołu. Spłaszczona struktura sprawia, że hierarchia ma nieporównywalnie mniejsze znaczenie, zmienia się również rola lidera: jego zadaniem jest okazywanie wsparcia członkom teamu, koordynowanie prac oraz poszukiwanie nowych możliwości. Niezbyt wiele jest więc tutaj miejsca na „nadzorowanie i karanie”, które na szczęście odchodzi do lamusa. Dzięki takiemu podejściu udaje się osiągnąć maksimum potencjału zarówno konkretnych pracowników, jak i całego zespołu. Agile PM ma jednak także swoją wewnętrzną organizację i matryce, pozwalające na ewaluację dokonań i znajdowanie nowych możliwości. W SCRUM-ie, jednym z najpopularniejszych systemów Agile, jest to np.

• Daily – codzienne krótkie spotkanie członków zespołu.
• Sprint Planning – spotkanie, zwykle angażujące również przedstawicieli klienta, podczas którego planuje się kolejne etapy działań,
• Sprint Review – spotkanie podsumowujące efekty prac i poczynione postępy,
• Sprint Retrospective – spotkanie pozwalające na ocenę jakości prac, diagnozowanie problemów, które wystąpiły, i poszukiwanie sposobów na ich unikniecie w przyszłości.

Jeżeli SCRUM Master, odpowiedzialny za właściwe wykorzystywanie Agile PM, będzie w odpowiedni sposób zarządzał pracami, udaje nam się zamknąć w tym schemacie cały cykl życiowy danej części projektu. Wszystko odbywa się natomiast w atmosferze pozwalającej skupić się na pracy i poszukiwaniu nowych możliwości przy jednoczesnym zachowaniu kontroli nad procesami. Łatwo wyobrazić sobie jednak, że w tym momencie w scenariuszu pojawia się PMO, domagające się tworzenia dodatkowych raportów (czym zaburza ustaloną ścieżkę raportowania i wytwarza de facto równoległy system). W rezultacie pozostawia coraz mniej przestrzeni na kreatywność, coraz więcej czasu, który mógłby być wykorzystany zdecydowanie lepiej, trzeba poświęcać natomiast na mnożenie dokumentacji. Oczywiście można założyć również zdecydowanie większą ingerencję, opierającą się na kontrolowaniu i weryfikowaniu nieuwzględniającym wewnętrznego rygoru Agile PM. W takim przypadku nie ma mowy o transformacji Agile, a zarządzanie projektami może wkrótce zamienić się w nieefektywną hybrydę.

Dobry scenariusz: PMO wspiera Agile PM

Jak wygląda to w prawidłowym scenariuszu? Opracowywaniem projektu zajmują się trzy jednostki: zespół, SCRUM Master oraz reprezentujący interesy klienta Product Owner. Harmonogram prac, zgodny z metodyką Agile, przebiega bez zakłóceń, a regularnie powtarzane schematy po prostu dają efekt: pozwalają wykorzystać pełnię talentu każdego członka teamu, jednocześnie zapewniają również właściwą komunikację z klientem oraz możliwość znajdowania nowych możliwości. PMO nie jest natomiast obecne w samym procesie, co nie oznacza oczywiście, że jego rola nie jest ważna: powinno koordynować działania na poziomie całej organizacji, ewaluować postępy w realizacji konkretnych projektów, dbać o finansowanie i poszukiwać możliwości rozwoju zarówno we własnej, organizacyjnej pespektywie, jak i w odniesieniu do każdego zespołu. PMO może zajmować się polityką finansową projektów, dbać o działania employer brandingowe, poszukiwać narzędzi, które jeszcze bardziej udoskonalą metodykę Agile wykorzystywaną w przedsiębiorstwie. Zadań jest więc bardzo dużo. Aby zapewnić właściwą „zwinność” procesów, nie mogą jednak nakładać się na obowiązki realizowane przez zespoły projektowe. 

Autor: Paweł Łaniewski