„Három dolgot csinálsz egyszerre, közben a menedzsment is nyaggat” – ezért olyan nehéz a projektek eleje | LABA HU
Для отслеживания статуса заказа — авторизируйтесь
Введите код, который был выслан на почту Введите код с SMS, который был выслан на номер
Код действителен в течение 5 минут Код с sms действителен в течение 5 минут
Вы уверены, что хотите выйти?
Сеанс завершен
На главную
LABA Tartalomgyár

Keresés

content

„Három dolgot csinálsz egyszerre, közben a menedzsment is nyaggat” – ezért olyan nehéz a projektek eleje

A projektek kezdetére szánt időt gyakran elbagatellizálják, pedig a projektmenedzsernek ilyenkor van a legkeményebb dolga – mondja a területet oktató Acsay Csaba.

cover-min-662a28c5ba6fc064891399-6630fd1488dab490139927.webp

Gyakori probléma, hogy a rossz információátadás miatt a projekttervező workshop fele arról szól, hogy az új embereket képbe kell hozni – mondja oktatónk, Acsay Csaba, a ZF Group Senior International IT Project Manager munkatársa. A területen több mint másfél évtizedes tapasztalattal bíró szakember interjúnkban számos más okot és körülményt is felsorol, melyek miatt megcsúszhat egy-egy projekt. Emellett a projektmenedzserekre (PM) nehezedő nyomás emberi oldaláról és a karrierutak mellékágairól is beszélgettünk vele.

Miért néz szembe mindennel egyedül a projekt kezdetén annak vezetője?

Amikor egy PM megkap egy új projektet, első körben általában a fő feladata a csapatot megtalálni hozzá. Ezért van ilyenkor még az esetek legnagyobb részében teljesen egyedül. Ha kap is hozzá támogatást a projektirodától, az így bekapcsolódó kollégákat is be kell illeszteni a projektcsapatba, meg kell határozni a feladataikat.

Egy-két héten vagy hónapon belül szervezni kell egy tervezési workshopot, ami néha felér egy rendezvényszerzező feladataival. A PM-nek így épp a projekt elején van a legtöbb szervezési és tervezési feladata, ami a projekt beindulásával lényegesen csökkenhet. A projektindítással járó ideiglenes leterheltség enyhítésére azonban nem szoktak több PM-et kirendelni a projekt elejéhez, így az elejét egyszerűen ki kell bírni.

Egy projekt mennyire hierarchikusan épül fel?

A klasszikus módszereket követő projekteknek tradícionálisan van egy erős hierarchiája. A projekt egy ideiglenes szervezeti felépítés, ahol minden projekttag a projektvezetőnek felel a projekthez rendelt munkaórái erejéig. 

A junior PM-eknek sokszor elég ijesztő is lehet, ha hirtelen egy tizenöt éve a szakmában dolgozó ember fölé kerülnek karrierjük első pár projektjében.

De ennek ilyen a felépítése, ilyenkor ő felel a rábízott erőforrásokért, azaz a kollégákért is és ez néha konfliktusokkal jár. Nem véletlenül beszélünk egy magas hozzáadott értékű pozícióról, amellyel az átlag felett is lehet keresni. 

Sokan a projektcsapatból úgy gondolják, hogy mivel már több PM-mel is együtt dolgoztak, ezért tudják ők is, hogyan kell ezt csinálni, és bele is szólnak a projetkvezető munkavégzésébe. Ez nem feltétlenül baj, a kérdés inkább az, hogyan teszik mindezt. Van, aki örül is annak, ha egy tapasztaltabb kolléga elmondja neki a jógyakorlatokat, mást ugyanakkor zavar, ha folyamatosan ezzel kell foglalkoznia. A kollégákkal való jó együttműködés és a csapat összekovácsolása tanulható képességek ugyan, de azért van, akinek ez természetesen jön és van, akinek nagyon tudatosnak kell ehhez lennie.

Mit jelent a tervezést megelőző projektkezdeményezési fázis és ez miért olyan fontos szakasz?

A projektek kezdeményezési fázisát még főleg az úgynevezett projektszponzoroknak kell elvégezniük, hiszen ebben a fázisban jelölik ki a PM-et is. A szponzorok olyan vezetőket jelentenek, akik tudnak pénzt és erőforrást allokálni a projektre és érdekeltek is annak a sikerében. A projekt hivatalos indításához a jógyakorlatok szerint többek között egy körülbelüli ütemtervet és költségvetést kell meghatározni, ezek ismeretében lehet dönteni a projekt indításáról. Ez lesz a projekt átfogó tervezéséhez a kiindulási alap. 

Gyakran mire a projekt eljut a tervezés azon tevékeny szakaszához, ahol elkészülnek a részletes tervek, már rég több hónapot csúszott.

Ha ugyanis a megfelelő emberek nélkül készülnek el a tervek, amilyekben valamelyik fél – mondjuk a felhasználói vagy technikai oldal – nincs képviselve, akkor azok a tervek vagy nagyon gyenge lábakon állnak, vagy nem lesznek széles körben jóváhagyva.

A multiknál jellemzően különféle erőforrás-igénylési folyamatokon kell végigmenni, aminek olykor egy hónap csak a jóváhagyása – például, ha havonta egyszer ülésezik csak az erről döntő testület. Ha nem voltunk elég proaktívak, akkor ilyen esetben az első hónapban már biztosan nem lesz tervezői workshop. A kulcsemberek azonosítását, beszervezését és munkaképes állapotba hozását a katonai zsargonból átvett módon a projektcsapat mobilizálásának is hívják. 

Ha mindezekre odafigyelünk, megelőzhető a komolyabb lemaradás?

A projekttervezési workshop eredményeképpen elkészül – vagy legalábbis közel végleges állapotba kerül – a projekt termékének műszaki terve, a projekt ütemezése, erőforrásterve, költségbecslése, vagyis ilyenkor az alapokat már látjuk. A workshopon az is egyértelművé válik, hogy a projektvezető hogyan is szeretné a projektet vezetni. Ha a workshop sikertelen és a várt eredményeinek idővonala elcsúszik, általában minden vele csúszik.

Először is azt érdemes a PM-nek átgondolnia, hogy mi kell a sikeres projekttervezési workshophoz. Onnan visszafelé tud tervezni azzal kapcsolatban, hogy minek mikor kell megtörténnie.

A workshopra fel kell készülni, érdemes javaslatokkal érkezni például a projekt felépítéséről. Ha például egy nagyobb program tervezési workshopjára készülünk, akkor lesznek olyan napirendi pontok, ahol mindenki ott van, és lesznek, melyeket az alprojektek, munkacsoportok szintjén érdemes megtartani. Egy új alkalmazás bevezetésének például lesz egy fejlesztési, egy tesztelési és egy üzembe állítási fázis, ahol mások a szereplők, akik a tervezést is elvégzik. Az alkalmazás egyes moduljait is érdemes lehet külön-külön tervezni. Ezek miatt fontos az előre felállított projektstruktúra, mert annak a mentén terveznek meg minden mást. 

Hogy minden flottul menjen, ahhoz, gondolom, fontos a belső kommunikáció, de mi kell még hozzá?

A belső kommunikáció a projektirányítás fontos része. De azon kívül még sok mindenen el tud bukni egy projekt. Az említetteken túl adminisztratív feladatokon is el lehet csúszni – például, hogy az emberek nem tudják, hova könyveljék el a munkaóráikat és ezért nem hajlandók elkezdeni dolgozni a projekten. Vagy hiába szervezem meg a workshopomat, ha nem hagyták még jóvá annak az utazás költségeit. 

Gyakori probléma az is, hogy a projektindítás előtt megbeszélteket nem adják át a frissen kinevezett projektvezetőnek és a csapattagoknak, akik így tervezés közben hallanak sok mindenről először. Egy jó példa erre, amikor úgy tervezzük meg az ügyfél számára a projektet, hogy nem tudjuk, hogy mit írtunk alá a szerződésben. A helyben rögtönzés pedig nem mindenkinek megy. Vannak olyan témák, melyeknél pedig kutatni, elemezni kell a követelményeket és szempontokat, ezért is fontos, hogy a háttérinformációkat mindenki megkapja. Ennek hiányában sokszor teljesen eredmények nélkül zárul a tervezési workshop.

Ajánlott cikk:

image-2-60dd747b372fe897442166.jpg

Mielőtt belevágunk a projektbe: a projektindító értekezlet 8 titka

Olvass tovább

Egyébként miért az elején felhalmozott csúszás a legkritikusabb?

Amikor egy projektet elindítanak, még csak egy nagyon homályos-ködös megfogalmazás áll rendelkezésre arról, hogy miről is szól az egész. Amíg legalább az úgynevezett magas szinten nincsenek meg a tervek, addig nem tudunk továbblépni a részletes tervezésre. 

Ha egy alkalmazásnál például még nem döntöttük el, hogy a cég saját szervereit használjuk vagy inkább felhő irányba menjünk el, addig az infrastuktrúra részletes tervezése nem tud elindulni.

Ha nincsenek részletes tervek, addig a fejlesztők sem valószínű, hogy elkezdhetnek dolgozni, mert nem akarnak rossz irányba indulni. Szóval a magas szintű projektterv és a műszaki terv nélkül nem tud elindulni a munka érdemi, végrehajtó része. 

Ha ezután be lehet hozni a lemaradást, akkor valószínűleg valaki rosszul, túl nagy ráhagyással tervezte meg az időkeretet. Ami ilyenkor jól jön, de ha mindenki jelentős ráhagyással számol, akkor végül olyan költség- és ütemterv készül, ami általában nem illeszkedik az ügyfél üzleti elképzeléseihez. Szóval ez egy veszélyes terület. Ha viszont nem számoltunk nagy ráhagyással, akkor a projekt elején elszenvedett csúszást nem tudjuk már behozni.

Mik a PM-ek legnagyobb nehézségei az induláskor?

Egy PM-nek általában három területen van dolga. Tervez, szervez, illetve kontrollál – azaz ellenőrzi, ahogyan a többiek dolgoznak. A harmadik talán kevésbé domináns a projekt elején, hiszen olyankor még nincsenek jóváhagyott tervek. 

Ezt a három dolgot neki egyszerre kell csinálnia, a menedzsment közben állandóan nyaggatja, hogy hogy állunk, mikor pont arra lenne szüksége, hogy hadd fókuszáljon a tervezésre és a szervezésre, mert attól indul be ténylegesen a projekt.

A projekt elején a haladás nagyrészt attól függ, hogy a PM milyen gyorsan tudja a projektcsapatot produktív fázisba hozni. Ez egyáltalán nem egy könnyű feladat és minden mást maga mögé utasít, például a dokumentációt is. Nagyon sok olyat láttam, hogy az első letisztázott, átfogó projektmenedzsment-terv az indulás után hat hónap után készült el. Az elején ugyanis annyira leterhelt volt a PM, hogy nem volt ideje leírni, hogy miként vezeti a projektet. Kérdezhetnénk teljes joggal, hogy hat hónap után pedig már minek írja le.

Ezt a helyzetet a menedzsment mennyire szokta jól kezelni?

Ez elég változó. Menedzsmentje válogatja, hogy ki az, aki már a projekt elején is hetente riportokat szeretne látni, mert annyira tudni akarja, mi a státusz, és hol tud beszállni vagy segíteni. Ez rengeteg plusz feladatot ad a PM-nek. Máshol viszont a PM-nek kell sok kutatás útján összeállítania a projektirányító bizottságot, mert a menedzsment úgy van vele, hogy most már ott a PM, ő majd mindent elintéz helyettük. 

Miért vannak sokszor irreális elvárások, mint hogy már az elején hetente riportoljanak?

Aki ezt még nem csinálta, annak nehéz elképzelnie, hogy a projekt elején mennyi mindennel foglalkozik a projektvezető. Volt két év a karrieremben, amikor rengeteg szerződésajánlathoz készített projekttervet láttam, amit olyanok készítettek, akik nem vittek még végig projektet az indulástól a végéig. Ezekben a tervekben elbagatellizálták a projektindításhoz szükséges időt: az erőforrások mobilizálására beterveztek egy hetet, a projekttervek elkészítésére pedig még egyet. Ez már egy ötfős projektcsapatnál sem biztos, hogy megállja a helyét, nem is beszélve egy százfős programról. Láttam olyat, ahol a projektindulás hetére már kitűzték a tervezési workshopot, mert azt akarták mutatni az ügyfélnek, hogy milyen fontos az a projekt és milyen elkötelezettek a végrehajtásán. Ez valóságban azt jelentette volna, hogy a projektindulás előtt megvesszük a repülőjegyeket a workshopra.

Emberileg mennyire nehéz ezt a fázist megélni?

Ez a PM-eknek egy nagyon nehéz időszak, ezért sokszor a nagy teher miatt leromlanak a konfliktuskezelési képességeik.

Irritáltak, türelmetlenek lesznek pont abban az időszakban, amikor elvárás, hogy ők legyenek a jófej új főnökök, akikkel együtt fogunk dolgozni sok hónapig, készítsék fel a csapatukat, szolgáljanak ki minden igényt és kezeljék az időnyomást is. De a túlterheltség miatt sokszor pont a résztvevőkkel kapcsolatos csapatvezetési (people management) munkákra nem jut elég idő. Azaz megismerni egymást, felmérni, hogy ki milyen feltételek közt tud jól dolgozni.

A projektindítás a tapasztaltabbaknak sem rutinfeladat. Az idejük nagy részében ugyanis értelemszerűen ők is a projekt további fázisain dolgoznak. A folyamatosan változó vállalati környezetben pedig két projektindítás között sok minden megváltozhat. Például az, hogy hogy kell erőforrást igényelni, hogyan kell a büdzsét jóváhagyatni, milyen résztvevők és feltételek vannak, melyik csapat felelős egy-egy területért, kik a vezetői ezeknek a csapatoknak és így tovább.

Hogy fordulhat elő, hogy hónapok után sem egyértelmű, kik a tagok egy projektben? 

Amíg nem világos a magas szintű terv szintjén, hogy mit is kell a projektnek leszállítania, addig nem tudjuk véglegesíteni a szükséges erőforrásokat. Az előbbi példánál maradva: ha végül a felhő architektúra mellett döntenek, akkor ahhoz értő architect, fejlesztő és tesztelő kollégák kellenek. Ezért is olyan kritikus, hogy mikorra készül el a magas szintű műszaki terv, mert ez kvázi tolja maga előtt az összes többi tervezést. 

A sokat emlegetett tervezői workshopon már azoknak az embereknek kell terveznie, akik később végre is fogják hajtani az egészet. Nálam alapelv, hogy az tervez, aki később végrehajtja. Ha ez nem teljesül, az ugyanis kockázat. A tervezői workshopon készült terv számonkérhető a projektvezetőn és a projekttagokon. Ezzel szemben a projektindulás előtt készült tervek inkább csak az ügyfél igényeit tükrözik, mint a realitást.

Mitől függ, hogy milyen forgatókönyvet érdemes követni a projekt indulásakor?

Ezt szervezete válogatja. Változó ugyanis, mikor indítanak hivatalosan projektet. Valahol, ha van egy jó ötlet, arra azonnal elindítanak egyet, aminek része lesz az ötlet kidolgozása is. Máshol viszont ehhez előbb szerződést kell kötni valakivel – mondjuk egy ügyféllel – annak a végrehajtásáról. Ebben az esetben a tervből még nem lesz automatikusan projekt, viszont ahhoz, hogy szerződni tudjak valakivel, el kell jutni addig a fázisig, amikor már el tudom mondani nagyjából, hogy mi a cél, arra kapunk egy ajánlatot és utána nevezik ki a PM-et. Addig még a sales terület dolgozik rajta, tendereztetés zajlik és így tovább, de a tényleges projekt csak a szerződéssel indul el. 

Valamikor pedig szükség van egy pilotra, meg kell nézni, hogy az elképzelés egyáltalán működöképes-e. Ez a pilot is egy miniprojekt, amelynek során, ha az derül ki, hogy megvalósítható az ötlet, akkor indulhat el a nagy, hivatalos projekt. Gyakran pedig van egy programunk, amire vonatkozóan különböző alprojekteket indítunk, ilyenkor sok minden már adott. Például ismertek a vonatkozó döntéshozók, az erőforrás-tervezés már korábban lezajlott, a már létező programhoz allokáltak büdzsét. Így az alprojekt vezetőjének már sokkal könnyebb dolga van az elindulással.

Mikor érdemes projektalapon dolgozni?

A projektalapú működés alternatívája a szolgáltatás-, illetve operációmenedzsment. Sokszor ugyanakkor ez a három működésmód keveredik is. 

Ha mondjuk egy telekommunikációs cég átveszi egy globális nagyvállalat adathálózatának az üzemeltetését öt évre, az egy ötéves projekt. Ugyanakkor az egy öt évig tartó szolgáltatás is egyszerre. Tehát párhuzamosan tekintünk rá mindkét módon.

A különbség ezek között, hogy a projektek lényege, hogy újat alkossunk. Ott a hangsúly egy változás minél jobb megvalósításán van, annak a megtervezésén és a végrehajtásán. Szolgáltatásmenedzsment esetén pedig az a hangsúlyos, hogy milyen jól tudom ugyanazt csinálni, egyre kevesebb költséggel és egyre megbízhatóbban. Tehát előbbi jó tervezési képességet igényel, utóbbinál az az előny, ha valaki nagyon pontosan érti a szolgáltatást és folyamatosan fejleszteni, javítani tudja azt. Egy PM gyakran fél évig az egyik témán dolgozik, utána fél évig teljesen máson. Ezzel előtérbe kerülnek az általánosabb, nem technikai jellegű képességek és egy szinten túl nem is elvárás, hogy mély szakmai tudása legyen az embernek a területről.

Ez a fajta munkaszervezés nem való mindenkinek?

De, hiszen a projektek a változások megbízható kezelésére indulnak. Változások pedig minden cégnél vannak. Az első PM tréningjeimet én például könyvelőknek tartottam, akiknek számos futó projektjük szokott lenni, még ha idejük nagy részét a havi, évi, negyedévi zárások teszik is ki. Például, ha kapnak egy új rendszert, amit le kell tesztelni, vagy éppen át kell szervezni a csapatukat, mert áthoznak pozíciókat egyik országból egy másikba. Ezek is változások, amelyeknek van eleje-vége, konkrét leszállítandó eredményei. De ha csak a saját csapatépítő rendezvényünkre gondolunk, annak is van egy határideje, döntéshozója és koordinátora. 

Vagyis különböző projektek igazából minden szervezetben, folyamatosan jelen vannak. Éppen ezért olyanoknak is érdemes elsajátítania ennek az alapjait, akik hivatalosan nem PM pozícióban dolgoznak.

Milyen karrierutak léteznek PM-ek számára azon kívül, hogy egyre nagyobb projekteket kap és egyre feljebb megy a ranglétrán?

Ami általában a fejekben van a PM karrierutakról, az az, hogy valaki elkezdi, mint projektkoordinátor, nagyon egyszerű projekteket vezet, utána pedig jönnek az egyre komplexebbek, nagyobbak, egész programok és a végén programigazgató lesz. A különböző szintekhez ugyanakkor másféle skillek, másféle személyiségjegyek kellenek. Az elején sokat számít, hogy valaki hogyan tudja mikromenedzselni a csapatát. Ha már egy 50-60 fős projektről beszélünk, ez a készség háttérbe szorul és inkább az a fontos, valaki hogyan tudja kialakítani a struktúrát. Hiszen ott már nem közvetlenül neki kell a munkát felügyelnie, sokkal inkább ki kell alakítania egy koordinátorokból álló szintet, akik ezt megteszik. 

Közben itt bejönnek olyan képességek, hogy valaki mennyire jól érti az üzlet igényeit vagy milyen jól tud beszélni a menedzsmenttel. A legmagasabb, programigazgatói szinten pedig már inkább a PM-eket kell hosszútávon menedzselni. Ez már sokkal inkább egy csapatvezetési irány. Ott az a cél, hogy az alá tartozó szenior kollégáknak minden adott legyen ahhoz, hogy a munkájukat jól végezzék el. 

Azért, mert valaki szeret projektkoordinátorként projekteket a részletekbe menően megtervezni és a csapatával azt végrehajtani, nem biztos, hogy tíz évvel később egy teljesen más készségeket igénylő programmenedzseri pozícióban a vállalatvezetéssel szeretne a cég jövőjét meghatározó stratégiai projekteken együtt dolgozni.

Nem biztos, hogy ez az, ami fekszik neki. Felmerül tehát a kérdés: ez akkor azt jelenti-e, hogy nem is tud feljebb lépni a ranglétrán? Ez el is bizonytalaníthat embereket, hogy rálépjenek-e a PM karrierútra, ha nem akarnak később programigazgatók lenni, mert az nem illik hozzájuk.

És feljebb tud?

Igen! Hiszen szerencsére van több mellékága a PM karrierútnak, amiben – miután projektkoordinátori vagy PM szerepkörben eltöltött pár évet – szinte mindenki megtalálja, amit szeretne. A programmenedzser jobb keze például nem feltétlenül egy klasszikus asszisztensi állás, lehet egy szenior PM-állás is. Ebben a szerepkörben a programvezető felelőssége és stressz-szintje nélkül, de akár több tízmillió eurós büdzsének a pontos felügyeletét kell megoldani. Ez abszolút egy szenior szintű feladat. 

A projekttervezők például akkor jönnek be képbe, ha egy beszállító tesz egy ajánlatot egy pályázati felhívásra. A tervezőnek akár hetente több átfogó projekttervet is készítenie kell több száz embert foglalkoztató projektekhez. Ő rakja össze a magas szintű ütemtervet, a költségtervet és így tovább. Ezek a projekttervezők gyakran már nem vesznek részt a projekt végrehajtásával járó stresszes feladatokban. Ők nem kerülnek abba a „számonkérő főnök” szerepbe, ami sokaknak kellemetlen. 

Van még kockázatmenedzsmenttel, riportálással, adatbányászattal, statisztikákkal foglalkozó „mellékág” is. Analitikus, introvertált beállítottságú emberek is lehetnek ugyanis projektmenedzsment-szakértők. Ha egy cégnek van ötszáz projektje és azoknak az éves költségvetését kell elemezni, az már inkább egy pénzügyi feladat, mégis a projektmenedzsment területhez szorosan kapcsolódik. Minél nagyobb egy cég, annál valószínűbb, hogy ezek a mellékágak megjelennek projektmenedzsmenttel foglalkozó szervezetrészben.

Szeretne egy összefoglalót kapni a cikkekről?

Hetente egy levél a legjobb anyagokkal. Iratkozz fel, hogy ne maradj le semmiről.
Köszönjük az előfizetést!