IT Project
Zarządzanie organizacją i Projektami IT
Czy PM musi znać produkt, który wdraża?
To pytanie wraca do mnie regularnie — w rozmowach z menedżerami, klientami, a czasem nawet z PM-ami, którzy dopiero zaczynają swoją drogę. Po latach prowadzenia projektów małych, średnich i dużych mogę powiedzieć jedno: to zależy. A najlepiej widać to w historii moich własnych projektów.
Gdy doświadczenie PM-a staje się kluczem
W jednym z dużych projektów, które prowadziłem, produkt był dla mnie nowy. Nie znałem go szczegółowo, ale miałem doświadczenie, które pozwalało mi szybko ustalić priorytety, zadawać właściwe pytania i wyłapywać ryzyka, zanim zdążyły się ujawnić. Zespół tłumaczył mi niuanse zagadnień, a ja skupiałem się na tym, aby zespół sam nazwał problem i znalazł rozwiązanie. Nie musiałem znać produktu dogłębnie, żeby prowadzić projekt skutecznie. Jednak czasem trzeba było zejść dużo głębiej, aby zidentyfikować ryzyka oraz problemy jeszcze nie nazwane, a mogące istotnie wpłynąć na projekt, które wynikają z doświadczeń z innych projektów.
Ale też obserwowałem projekt, w którym PM (z firmy consultingowe, zaraz po studiach) — z niewielkim doświadczeniem, ale ambitny, świetnie zorganizowany — nie znał produktu. Widziałem, jak projekt zaczyna go powoli przerastać. Zamiast prowadzić zespół, zespół sprowadził go do funkcji pomocniczych typu organizacja spotkań, pisanie notatek, rozliczenia godzin, trzymając go na dystans od zarządzania projektem. Wartość dodaną generował zespół, a PM w zasadzie był bardziej „obecny” na projekcie.
To wtedy utwierdziłem się w przekonaniu, że brak wiedzy o produkcie przy małym doświadczeniu PM-a to ryzyko, które szybko staje się problemem.
Przy okazji chciałby zwrócić uwagę, że są firmy IT, które sprowadzają PMa do roli organizatora, zarządcy, administratora projektu często odbierając mu prawo do zabierania głosu w sprawach merytorycznych. To moim zdaniem to duży błąd. Czasem zadawanie prostych, logicznych i zdroworozsądkowych pytań przez PMa pozwala spojrzeć zespołowi z innej perspektywy na problem. Nie należy zapominać że, PM jest niejako przedłużeniem ręki zarządu firmy w projekcie. Często to od jego dobrych oraz złych decyzji w znaczący sposób zależy sukces projektu, a tym samym sukces firmy.
Złożoność produktu — lekcja pokory
W projektach z bardzo złożonymi produktami nauczyłem się jednego: PM musi mieć wysokie kompetencje zarządcze, ale nie może być ekspertem od rozwiązania (w przeciwnym wypadku powinien zmienić rolę z PMa na architekta, czy konsultanta).
W jednym z projektów produkt był tak skomplikowany, że nawet eksperci czasem musieli wracać do dokumentacji. Moja rola polegała na czymś innym: upraszczaniu złożonych problemów, moderowaniu dyskusji, zadawaniu pytań, aż do momentu, gdy wszyscy widzieli sedno sprawy.
W projektach prostych bywa odwrotnie — tam PM może wejść głębiej w produkt, czasem nawet powinien, choć nadal warto zachować granicę między zarządzaniem a wdrażaniem.
Zespół — czynnik, który zmienia wszystko
W mojej praktyce najwięcej zależy od zespołu. Ciekawe? Nie od produktu?
Gdy zespół jest mocny
W projektach z doświadczonymi ekspertami najlepsze, co mogłem zrobić jako PM, to… nie przeszkadzać. Skupiałem się na usuwaniu przeszkód, organizacji zasobów, dbaniu o rytm pracy. Zespół sam generował wartość, a moją rolą było stworzenie mu warunków do działania.
To wymaga pokory i umiejętności odnalezienia się w środowisku, gdzie wszyscy wokół są ekspertami w swojej dziedzinie. No i zaufania że zespół wie co robi. Acz stare powiedzenia „ufaj i kontroluj” zawsze na czasie 😊
Gdy zespół jest słabszy
W projektach z mniej doświadczonymi zespołami sytuacja była odwrotna. Musiałem znać produkt lepiej, niż chciałem. Musiałem prowadzić zespół krok po kroku, czasem mikrozarządzać — choć tego nie lubię.
W takich projektach PM bez wiedzy o produkcie po prostu nie ma wiedzy i narzędzi, żeby właściwie poprowadzić zespół.
Moja odpowiedź po latach projektów
Czy PM musi znać produkt, który wdraża? Po moich doświadczeniach mogę powiedzieć tak:
PM powinien znać produkt na tyle, by rozumieć kontekst, ale nie na tyle, by stać się konsultantem. Czasem musi znać produkt bardzo dobrze. Czasem wystarczy, że wie, o co zapytać. Czasem nie musi znać go prawie wcale.
To zależy od trzech rzeczy:
- doświadczenia PM-a,
- złożoności produktu,
- kompetencji zespołu.
Na to należy jeszcze nałożyć dwa czynniki: czas i zakres projektu. Im większy zakres i krótszy czas projektu, tym doświadczenie PMa staje się bardziej kluczowe
Ale niezależnie od projektu, zawsze staram się zainteresować tym, co wdrażam. To buduje relacje, rozwija mnie jako PM-a i sprawia, że każdy projekt staje się historią, z której można wyciągnąć kolejną lekcję.
#ITProjectManagement #PMO #ProjectManagement #ERPImplementation #SystemImplementation #ChangeManagement
Zaproszenie
Jeśli interesuje Ciebie jakaś tematyka, która warta jest opisania w blogu lub chciałbyś się podzielić własnym tekstem lub przemyśleniami, proszę skontaktuj się ze mną, prześlij propozycję teksu. Ten blog może być forum wymiany myśli na temat zarządzania organizacją, czy też Projektem IT.
Zaproszenie
Jeśli interesuje Ciebie jakaś tematyka, która warta jest opisania w blogu lub chciałbyś się podzielić własnym tekstem lub przemyśleniami, proszę skontaktuj się ze mną, prześlij propozycję teksu. Ten blog może być forum wymiany myśli na temat zarządzania organizacją, czy też Projektem IT.