A kihívás

Manapság egyre inkább elfogadott a fejlesztéseket projekt keetrendszerbe helyezni, aminek a következtében a projekt menedzserekre is nő a piaci igény. A gyakorlott projekt menedzserek és az összes tervezett, vagy futó projektek aránya egy laza becslésem szerint nem 1:1, hanem inkább 0,5:1. Instant megoldásként a gyakori a belső kiválasztás és kinevezés jobb esetben validált teljesítmények és képességek alapján, rosszabb esetben egy jobb képességű bárki is megteszi. Ez összességében nem róható fel senkinek, hiszen a projekt keretrendszerben elvégzett fejlesztések, a mára kistabilizált és megbízható projekt módszertanokkal a befejezett és sikeres fejlesztést ígéri. Azonban itt jelenik meg a kihívás is, hiszen ha a módszertan elsajátítására nincs idő, akkor marad az (amúgy még mindig megbízható) józan paraszti ész, vagy a kinevezett projektmenedzser kézivezérlése. A „felmatricázott”, önjelölt vagy tapasztalatlan projekt menedzsereknek a steakholder kifejezés jelentősége és értelme lehet képlékeny, ami miatt tudják azt lazán kezelni. Pedig itt is arról van szó, hogy adott egy csapat és annak a vezetője.

A steakholder menedzsment jelentősége

A steakholderek azok, akik a csapatot képzik, akik analógiásan a közös vállalkozásban részt vesznek, szerepet, funkciót és feladatot kapnak egy cél érdekében. Előfordulhat az, hogy egy steakholder a projekt nem minden szakaszában vesz részt, pl. egy munkavédelmi hatóság általi jóváhagyó, vagy egy IT teszter. Vannak azonban olyan steakholderek, akiknek folyamatosan részt kell venniük és jelen kell lenniük a projekt minden szakaszában és idejében. Ilyen a projekt menedzser maga is. Láttam sikeres, megfelelő és sikertelen projektet is. A steakholderek azonosításának és a velük való szisztematikus és strukturált (együttesen a projekt céljaival összeegyeztető módon harmónikusan) együttműködésének a jelentőségén való túllendülés, eredendően determinálja a projekt sérülését. Megint csak analógiásan, mintha egy vállalkozást úgy működtetünk, hogy nem vonjuk be, vagy rapszodikusan és kaotikusan vonjuk be azokat a szereplőket, akik a működtetéshez és a növekedéshez szükségesek, viszont rendelkezésre állnak mint kompetencia és bér van nekik fizetve.

A projekt csapat felrendezhető egy szervezeti hierarchia ábrára, de inkább a mátrix megjelenési forma az elfogadott, ahol minél több információt érdemes megadni magáról a személyről (pl. projektvezető helyettes) vagy csoportról (pl. egy külsős építés kivitelezési csapat), aki egy steakholderként értelmezhető. A legkevesebb információ, amit meg kell adni az elérhetőségük, a projektben azonosított szerepük, feladatuk, felelősségük, hatáskörük, és jogosultságaik. Szerencsés, ha a projekt szakaszaiban is meg van jelölve a helyük. Izgalmas további információ az, hogy mekkora és milyen jellegű a hatása a projektre, valamint az, hogy milyen érdeke fűződik a projekt eredményéhez. Azon túl tehát, hogy leírjuk ezeket az információkat adat szinten, a sikeres projekthez vezető helyes dinamikákhoz ezeket nagyon komolyan meg is kell érteni.  Ezeket a projektmenedzsment módszertanok tanítják, úgyhogy nem megyek bele ennek a mélységébe, inkább megmaradok a jelentőségén.

Miért a projektmenedzser a siker kulcsszereplője?

Nagyjából általánosan elmondható az, hogy egy projekt a menedzserén múlik. Természetesen számtalan kockázat és váratlan hátráltató tényező merül fel egy projekt során, hiszen bármely steakholder bármikor húzhat egyet keresztbe, de ha egy projekt sikertelen, a projekt tulajdonosai a projektmenedzsert tudják kitenni felelősnek, a csapattagok pedig, ahogy egy vállalkozásban a dolgozók emlegetik azt a bizonyos halat. Vagyis a projekt menedzsere igazából egy alulról és felülről beszorított helyzetben van.

Ezért nagyon fontos az, hogy

• • ismerje a projektmenedzsment szakmát mélységeiben is, annak az elemeit és értse meg azok jelentőségét, fontosságát és hasznát (ha már annyi ember tette bele a több évtizedes energiáját a módszerek kialakításába és kutatásába)
  • értse meg a projektet (scope-hoz tartozó környezet) legalább rendszer-, és folyamatszemléletben is
  • biztosítsa a projekt feladatokhoz szükséges feltételeket (ha más ismerete nincs, Ishikawa halszálka modell segítség lehet)

• • legyen sikeres és sikertelen projektre vonatkozóan legalább elméleti ismerete (ha már könyvek is születnek ezekről)

• • legyenek meg azok a humán skill-jei, amelyekkel a projekt dinamikát a csapatot és a kommunikációt ezáltal pedig az egész projektet megfelelő mederben, sebességben és egyensúlyban tudja tartani, végül
  • tartson egészséges távolságot a steakholderek között (pl. tulajdonos, szponzor vs megvalósítók)

• • értse meg a felelősségét és a szerepét a projektben. Ne égesse ki saját magát bármilyen motiváció mentén vagy oknál fogva (pl. bizonyítási kényszer, idő menedzsment hiányosság, delegálásra való képtelenség, egyéb), vagyis figyeljen önmagára (a korlátaira és az erősségeire) és az egészségére is

A legjobb eset az, ha a projektmenedzser csapata a „követő tábora” is egyben, mert az jelenti azt a legnagyobb fokú bizalmat a steakholderek részéről, amellyel a legnagyobb teljesítményeket tudják kihozni magukból. Hétköznapi nyelven ezt úgy próbálják körül írni, hogy rendelkeznie kell az általános vezetői képességekkel is, mint a változás megfelelő képviselete, a motivációs képesség, a célra fókuszáló kommunikáció és amit még ide szoknak sorolni. 

Végül, ha a projekt menedzsere kiesik, az ő pótlása legjobb eséllyel csak egy átmeneti zavart, rosszabb esetbe a projekt hátralévő részére teljes káoszt tud okozni. Ezért hangsúlyos a kiégés kockázatát szem előtt tartani. Sajnos én nem tudok olyanról, hogy lenne kimondottan projektmenedzsereknek szisztematikus kiégés elleni/kezelő programok, úgyhogy feltételezem ők is a vezetői kiégés elleni/kezelési programokat vehetik igénybe.

A projektek humán dinamikája

Egy gondolat erejéig kitérnék a projekt humán dinamikájára, mert ezt egy képzésen nem tanították (pedig tanultam párszor projektmenedzsmentet), de még pályafutásom elején tanította nekem egy projektmenedzser 18 éve. Ez a projektmenedzser azt tanította nekem (és ezt alkalmaztam is sikeresen), hogy a projekt csapatot

a projekt elején szigorúan kell fogni a csapatot, hogy megtanulják az éppen ahhoz a projekthez szükséges együttműködés szabályait, és ne törjék el együttesen a projektet már az elején. Fel kell venni a projekt „utazó sebességét”.

a projekt közepén lehet kicsit lazítani és barátkozni, mert itt már van rutin együttműködés, a projektnek megvannak a folyamatai, a kommunikációs szabályai, csatornái, van szervezett probléma megoldás és elvileg megy a harmonikus csapatmunka.

a projekt végére pedig megint szigorúan kell fogni a csapatot, mert a projekt az utolsó hajrában van, ahol már az átadás-átvétel előkészítése is megjelenik a projekt lezárása mellett, vagyis a projekt akkor zárható le sikeresen, ha az átadás-átvétel is sikeresen megtörtént.

A projekt csapat védelme

Bár elsőre furcsán hangzik, a projekt megvalósításában résztvevő egységeket, egyéneket védeni kell. Ez a védelem nem a személyükre vonatkozik elsősorban, hanem a munkavégzés folytonosságának a biztosításáról szól. A projektmenedzser ilyenkor egy egészséges távolságban tartja a steakholdereket egymástól (ami nem kizárja a kapcsolatokat és az esetlegesen szükséges egyeztetéseket), mert az érdekek ütközése akadályozza az előrehaladást. Ha a projektmenedzser „szitaként viselkedik”, lehetetlen (pl. bár agilis, de scope-n kívüli) követelményeket kommunikálhat be és próbálhat meg érvényesíteni a megvalósító csapattal szemben (pl. teljesítés határideje), amely garantáltan konfliktushoz vezet, illetve a projekt előrehaladását is hátráltatja. Ha nem látja az előrehaladást rendesen (ami amúgy elemi hiba), a feladatokat képes turbulensen adagolni a megvalósító csapat felé, ami pedig relevánsan járul hozzá a csapat kiégéséhez. 

Szintén a védelemhez tartozik az eredmények megvalósításához szükséges feltételek biztosítása. Visszakanyarodva a feketedoboz szemléletre, eredményt jelent minden projektfázis outputja akár kívánatos, akár nem. Ha nagyon nincs mihez nyúlnunk a feltételek megértését illetően, elegendő az, ha megnézünk egy Ishikawa halszálka modellt (ami amúgy egy hiba gyökérok elemző módszer vizuális eszköze), ugyanis a feketedoboz módszer szerint az outputban keresett hiba valójában az inputban rejlik. Tehát preventív megközelítéssel érdemes az input oldalt az output oldali lehetséges hiba kategóriák szerint vizsgálni és kezelni.

Az a helyzet, hogy ha projektmenedzser nem védi a csapatot, a csapat kihátrál mögüle. Vagy azért mert a csapattagok simán kiégtek, vagy egyszerűen mert elvesztette a vezetői státuszát a csapat szemében. Mindkettő megjelenik a teljesítményben és garantált a projekt háromszög sérülése. Mindettől függetlenül, ha a nincs megfelelő lession learned és egy őszinte önreflexió, mivel a projektnek egyszer lesz vége, a projekt menedzsere bármit kommunikálhat a „sikeres projektjeim” beszámolójában, és tudja a körülményekre fogni a véleményes eredményeket, mert senki nem fog utána nézni. 

Milyen hibákkal találkoztam a steakholder menedzsment témakör kapcsán?

A projektmenedzser

• • fel lett matricázva, mert a self marketing-je sikeres volt
  • nem vonta be szisztematikusan a sikeres projekthez szükséges szakértőket – az eredmény átadás-átvételekor hibásan funkcionált és más szakterületre nem tervezett terhelést gyakorolt
  • nem tudta moderálni a megbeszéléseket – a megbeszéléseknek csekély mértékű hasznos kimenete volt
  • sikeresen lezárta a projektet, viszont a változást részben sikerült adaptálni a napi rutinhoz szükséges humán erőforrás hiány okán – a projekt eredményének a hiánya időről időre visszatérő módon felmerül
  • centralizáltan tartotta a kapcsolatot a projekt csapat tagjaival – az eredménynek voltak váratlan melléktermékei
  • nem készített elő project chartert – nem volt tiszta a projekt folyamán nagyjából minden egyéb mellett az, hogy
    • milyen feladatok által kell megvalósítani a projektet, amihez kik és milyen szakterületek szükségesek
    • mely részlegeket érint, milyen már létező funkciókkal kell kapcsolódni az eredmény érdekében, vagy az eredménynek
  • nem mozdult ki helyszínre, így nem sikerült releváns steakholderekkel kapcsolatot kialakítania – nem tudta rendesen nyomonkövetni az eseményeket
  • annyi meetinget szervezett a saját megértésének a fenntartása érdekében – hogy az már a napi rutin és a projekttel összefüggő feladatoktól vette el a hasznos időt
  • nem ismerte a projekt dokumentációt részleteiben (ami egy ajtótámasz méretű könyv volt) – projekt auditkor nehezen és hiányosan referált
  • felcserélte a humándinamikákat a projekt különböző szakaszaiban – a projekt csapat tagjai előtt elvesztette minden tekintélyét
  • szitát játszott a határidők tekintetében, illetve a munkához szükséges feltételeket (pl. adatigény megvalósítási tanulmányhoz) nem képviselte a tulajdonos felé
  • kiégett, elfáradt és elengedte a projektet