PMO wyżej niż PM? Nieporozumienie, które kosztuje projekty

cze 8, 2026

W 2019 spotkałem project managera w krakowskim startupie, który dostał zawału, gdy usłyszał, że ma raportować do PMO. Przez 3 tygodnie próbował wyjaśnić zarządowi, że „to nie ma sensu”, bo przecież PMO to tylko biuro, a on zarządza realnym projektem wartym pół miliona złotych. Problem w tym, że pytanie „czy PMO jest wyżej niż PM” zakłada hierarchię tam, gdzie jej naprawdę nie ma.

Biuro, nie szef

PMO nie jest szefem project managera. Według PMBOK Guide, Project Management Office to struktura zarządzająca, która centralizuje i koordynuje procesy projektowe. W praktyce PMO definiuje standardy, pilnuje zgodności z metodologią, wspiera PMów narzędziami. Nie wydaje poleceń konkretnym projektom, nie decyduje o budżetach poszczególnych inicjatyw. PRINCE2 idzie jeszcze dalej i rozdziela role: komitet sterujący podejmuje decyzje biznesowe, project manager wykonuje projekt, a PMO siedzi z boku i dopilnowuje, żeby wszyscy używali tych samych szablonów.

W firmie 120-osobowej, którą obserwowałem w 2021, PMO składało się z 3 osób. Kierowali 8 project managerów prowadzących 14 projektów jednocześnie. Formalnie PMO miało „nadzorować” prace, ale w praktyce PMowie przychodzili do nich po szablony harmonogramów, pytali o interpretację procedur i prosili o wsparcie w eskalacji do zarządu. PMO nie mówiło im, jak prowadzić projekty. Mówiło, jak je dokumentować.

Prawo Conwaya w akcji

Melvin Conway już w 1968 zauważył, że organizacje projektują systemy będące kopią własnych struktur komunikacyjnych. Jeśli firma ma osobne działy IT, biznes i PMO, które nie rozmawiają ze sobą, projekty wychodzą podzielone na trzy niezależne moduły, które jakoś nie chcą ze sobą współpracować. W jednej korporacji finansowej PMO raportowało do CFO, project managerowie do CIO, a komitet sterujący PRINCE2 składał się z ludzi, którzy widzieli się raz na kwartał przy kawie. Rezultat: 18-miesięczny projekt wdrożenia CRM padł, bo każda ze stron miała inne wyobrażenie o tym, co budujemy.

Problem nie był w tym, że PMO było „wyżej” albo „niżej”. Problem był w tym, że strukturę organizacyjną zaprojektowano tak, jakby PMO, PM i sponsor projektu żyli w równoległych światach. Conway miał rację – dostali system, który dokładnie odzwierciedlał ten chaos.

Trzy modele, które faktycznie działają

Supportive PMO siedzi w kącie i podaje narzędzia. PMowie przychodzą, gdy potrzebują, ignorują, gdy nie. Działa w startupach i zespołach, gdzie autonomia jest ważniejsza niżstandaryzacja. Controlling PMO pilnuje compliance – audyty, procedury, check-listy. PMowie muszą raportować według ustalonych wzorów, ale wciąż sami zarządzają projektami. Directive PMO przejmuje kontrolę: PMowie są przypisani do biura, dostają projekty z góry, raportują linia po linii. Brzmi jak koszmar? W branży farmaceutycznej, gdzie jedno pominięcie kroku w walidacji kończy się mandatem od FDA, directive PMO uratowało więcej projektów niż jakikolwiek charyzmatyczny PM.

Żaden z tych modeli nie stawia PMO „ponad” project managerem w sensie hierarchii służbowej. PMO może mieć władzę metodologiczną, może kontrolować budżet szkoleniowy, może blokować projekty niezgodne ze strategią. Ale nie wydaje poleceń operacyjnych. To nie jest szef PMa. To infrastruktura, w której PM działa.

Kiedy się sypie

Najgorsze projekty, które widziałem, to te, gdzie ktoś próbował zrobić z PMO linię raportowania. PM dostaje zadanie od sponsora, raportuje do PMO, PMO raportuje do zarządu, zarząd pyta sponsora, co się dzieje. Po 6 tygodniach nikt nie wie, kto za co odpowiada. Albo odwrotnie: PM ignoruje PMO kompletnie, bo „oni nic nie rozumieją z mojego projektu”. Po roku okazuje się, że 5 projektów używało 5 różnych metodologii, żadna nie była zgodna ze strategią firmy, a audyt wewnętrzny znalazł 200 stron dokumentacji, której nikt nigdy nie otworzył.

Melvin Conway pewnie pokiwałby głową. Struktura organizacyjna była bezsensowna, więc projekt wyszedł bezsensowny.

Źródła

  1. Project Management Institute, \“PMBOK Guide\”, pmi.org
  2. AXELOS, \“PRINCE2 Manual\”, axelos.com
  3. Conway M.E., \“How Do Committees Invent?\”, Datamation, 1968

Zdjęcie: Gustavo Fring / Pexels

TL;DR

  • PMO nie jest przełożonym project managera – to struktura metodologiczna, która centralizuje standardy i wspiera projekty narzędziami
  • Według PMBOK i PRINCE2, PMO definiuje procesy, nie wydaje poleceń operacyjnych konkretnym projektom
  • Prawo Conwaya z 1968 roku pokazuje, że jeśli struktura organizacyjna jest chaotyczna, projekty wychodzą chaotyczne
  • Trzy modele PMO (supportive, controlling, directive) różnią się zakresem kontroli, ale żaden nie stawia PMO nad PMem w sensie hierarchii służbowej
  • Najgorsze projekty padają, gdy ktoś próbuje zrobić z PMO linię raportowania zamiast funkcji wspierającej

Zobacz też: