A klasszikus projektmenedzsment azt jelenti, hogy határidőn belül szállítsuk le a kívánt megoldást a meghatározott pénzügyi kereteken belül. Ennyi? Ennyi. Vagyis három elemre kell figyelni:

• Időkeret
• Megoldás / termék megfelelősége
• Pénzügyi keret

Első lépésben maradjunk ennél a klasszikus projektmenedzsmentnél, mivel nagyon gyakran tapasztalható, hogy még ez is nehézséget okoz, akár egy szenior projektmenedzser számára. A probléma általában ott kezdődik, projektterv elkészültét követően „történnek váratlan dolgok”. Rögtön szögezzük le, hogy a leváratlanabb, ami történhet az, hogy minden az eredeti terv szerint zajlik. Ilyen projekttel még nem találkoztam. Vagyis kell tudni kezelni a „váratlant”. Ami alapvetően lehet bármi. Igazán nem az az érdekes, hogy mi a váratlan, mert azért váratlan, mert nem tudjuk előre, hanem hogy az, hogy mit teszünk ilyenkor.  Hogyan reagálunk az előre nem látható történésekre.

Amikor létre hozzuk a projektet, meghatározzuk a célokat, az ebből meghatározott leszállítandó termékeket, az erőforrásokat (pénz és emberek), illetve az ütemtervet. Ennyi? Nem, ez biztos, hogy nem elég.

Meg kell határozni az ún. governance struktúrát (magyarul irányítási struktúrának nevezném), hogy ki miben dönt, mikor találkoznak és mikor kell különböző kérdéseket eszkalálni. Ha ezt meghatározzuk már a projekt elején (és a kijelölt személyek ezt fel is vállalják), akkor automatikusan meg van a válasz alapja a fenti kérdésre, mit teszünk, ha bekövetkezik a „váratlan”.

A struktúrának része a rendszeresre betervezett megbeszélések. Ezeket célszerű megtartani akkor is, ha nem volt előrelépés a projektben. Egyrészt természetes nyomást gyakorol a résztvevőkre, hogy ne halasszák tovább a határidős feladatot, mert erre rákérdeznek, másrészt felhívja a figyelmet arra, hogy esetleg fel kellene gyorsítani szükséges folyamatokat, hogy haladjon a projekt. Nem kevés olyan projektnek voltam a vezetője, ahol a heti meeting 10-perces volt, és igen gyorsan végig beszéltük a státuszt, mi maradt el, mi nem. A hatékonyság része, hogy ezeket a megbeszéléseket MS Teams-en tartjuk (vagy bármilyen más online platformon).

Nagyobb projekteknél több szereplő és szerepkör van a Projektmenedzseren (PM) kívül, talán itt van az egyik legnagyobb félreértés: A PM nem szükségszerűen a terület szakértője, nem várjuk el tőle, hogy értsen minden szakmai részlethez. A szakértőt angolul SME-nek hívnak, Subject Matter Expertize, magyarul téma szakértő. Azonban fontos, hogy a PM lássa át és értse a területet olyan szinten, hogy tudjon kommunikálni úgy az SME-vel, mint a projektirányítási szervekkel és ha ezen túl van szakkompetenciája, az további előnyt jelenthet. Pl. biztos, hogy nem vállalnék PM szerepet egy atomerőmű megépítésénél, vagy egy játékfilm elkészítésében.

Mit tartok a legfontosabb PM képességeknek? Itt kihagyom a szervezettséget, mivel azt alapképességnek tekintem. Lényeglátás, bátorság és ítélőképesség. Legyen képes átlátni komplex struktúrákat. Legyen bátor, hogy merje meghozni a szükséges döntéseket, de ugyanakkor legyen képes megítélni, hogy mikor szükséges egy döntést vagy továbblépést halasztani, illetve mikor szükséges eszkalálni a kérdést, legyen ez döntés vagy figyelemfelhívás.

Én ezt úgy oldottam meg, hogy a rendszeres riportomban (amit akkor is megírok, ha nem történt semmi, ilyenkor jó a Copy-Paste) bevezettem a „Red és Yellow Flag”-eket, vagyis vörös és sárga zászlót. Szó szerint a riportban szerepelnek zászlók. A „Red Flag”-et akkor alkalmazom, amikor valami projektszinten veszélyezteti a haladást és/vagy azonnali beavatkozást igényel, és a „Yellow Flag”, ha valami kezd rosszra fordulni, de még vagy nem annyira horderejű a probléma vagy nem igényel azonnali beavatkozást. Egyébként szoktam alkalmazni a zöld zászlót is, ha egy nehéz szakaszon sikeresen túl vagyunk.

Egy hagyományos távközlési költségelemzés esetén, ha a számlaösszeg egyes jelentős eleme a szokásoshoz képest több, mint 30 – 50%-kal nő egy adott hónapban, akkor az egy határozott Red Flag, ha 10%-nál több, akkor Yellow Flag.

Ha idáig eljutottunk, megvannak az alapok, hogy megfelelően végrehajtsunk egy olyan projektet, mely nem jelent jelentős változást az érintett emberek munkájában és emiatt nem igényel változásmenedzsmentet. Tipikus ilyen projektek az IT területen a mindenfajta infrastruktúra fejlesztések vagy más olyan fejlesztés, ami a háttérben történik. Példa erre egy adathálózatbővítés vagy szerverbővítés, amig már a mobilszolgáltatóváltás már kisebb változásmenedzsmentet igényel és egy új rendszer vagy rendszerelem bevezetése esetén a változásmenedzsment jelentős részt tesz ki egy projektnek. A most remélhetőleg a vége felé járó Covid pandémia és ezzel járó Home Office gyakorlat nagyon jó példa arra, amikor szükség van vagy lett volna a jelentős felhasználó támogatásra és változásmenedzsmentre. Gyakorlatban volt látható ennek elmaradása hatékonyságcsökkenésben. És akkor is, ha erre akkor nem volt idő, ezt lehetett volna pótolni a későbbiekben. A SciamuS csinált már ilyet.