A kudarcról

Ha projektekről beszélünk, de szerintem analógiásan a vállalatépítésre is igaz), nagyon szeretjük pozitív oldalról megvilágítani a kudarcot, vagy átterelni a fókuszt a sikerre. Szeretjük elkenni a kudarchoz vezető problémákat és mint egy tanulási lehetőségként pozitívan értelmezni azt. És valóban a kudarcnak is van pozitív eredménye, de azt is be kell látni, hogy a kudarc mindig egy lezárást jelent, ami mögött erőforrás égett el. Azért mert egy pozitív nézőpontból értelmezzük a kudarcot, még hordozza a negatív aspektusokat. Meglátásom szerint ez a fajta kommunikációs forma és hozzáállás egyén szinten befolyásolja a kockázatvállalási hajlandóságot, ugyanakkor fontosnak tartom a racionális mérlegelést, és az arra meghozott döntéseket. Vagyis a pozitív és a negatív aspektusokat érdemes egy egészséges egyensúlyi szinten vizsgálni.

Nem tekinthető kudarcnak az, ha számolunk olyan nem kívánatos következményekkel és eredményekkel, amelyek megjelennek a projekt kimenetei között. Az azt jelenti, hogy valóban terveztünk és a várható nem kívánatos eredményeket elfogadtuk, illetve tudomásul vettük azt, hogy lesz még dolog és erőforrás igény a projekt zárását követően. Ez a fajta tudatosság hozzájárul a stratégiai célok, valamint az erőforrás terv esetleges korrekciójához és ugye emlékezzünk arra, hogy ennek a tudatosságnak a kulcsa maga a projekt vezetője.

Kudarc az,

• amire nem számítottunk, vagyis esélyünk sem volt korrigálni
• azonosítható a túlzott optimizmus
• az akkurátus tervezés és mérlegelés hiánya, valamint az elkerülés érdekében meghozott prevenció, és mindez
• stratégiát terhelő, szükségtelen és elkerülhető pénzt, időt és energiát foglalt ki a vállalatból

És hogyan lehet a legkönnyebben kudarcra ítélni egy projektet?

A projektmenedzsment tematikában szinte végtelen mennyiségben érhető el szakirodalom. Esettanulmányokat, tapasztalati és elméleti kutatásokat, valamint kutatási eredményeket bemutató tudományos és kevésbé tudományos könyvek, releváns és nem releváns folyóiratokban vagy weboldalakon megjelent cikkek. A projektmenedzsmentnek több komoly iskolája is van, melyek tanúsítást adnak a sikeres vizsgákért cserébe. Tehát a best practice forrásai szinte korlátlan módon érhetők el bárki számára. Ráadásul azt kell, hogy mondjam, mindegyknek van értelme, és jók.

A sikeres kudarc (micsoda képzavar…) tehát az, ha részben vagy egészben negáljuk, vagy ignoráljuk a best practice-okat, mert

• nem szánunk időt elmélyülni a projektmenedzsment módszertanban
• nincs belső igényünk („nem vagyok hajlandó”) vagy külső nyomás az alkalmazásra
• azt gondoljuk, hogy az elméleti megértés nélkül is menni fog (a csapat és józan paraszti ész megsegít…)
• „majd azt én jobban tudom” megközelítés
• nem érezzük testhezállónak, nem tudunk benne gondolkozni és amúgy majd megoldjuk jólvanazúgy…
• biztos van még lehetséges magyarázat, de talán most ennyi is elég.

Fenntartom azt, hogy az input determinálja az outputot, ezért kimondottan és hangsúlyosan a tervezést előtérbe helyezve fogjuk végig nézni a banánhéjakat.

A tervezést megelőző makrovizsgálat

Minden projektet egy projekt charter nevű dokumentummal kezdünk, mely a projekt ismérveit mutatja be. Meglátásom szerint ez az első olyan releváns input, amely meghatározza a projekt kimenetét. Mert ugye minőséget csak minőséggel lehet teremteni. Ha tehát minőségi áttekintést és tervet készítünk, akkor a projekt sikere hatványosan nő. Mindemellett érdemes szem előtt tartani azt is, hogy a hiányos, vagy elhanyagolt tervezés, illetve az elhanyagolt nekifutás hatással van a projektcsapatra, illetve a teljesítményre is.

A projekt charter egy dokumentált előzetes makrovizsgálat, ami nagyvonalakban választ ad arra, hogy mi a probléma? mi kell a megoldáshoz? hogyan akarjuk azt megvalósítani, milyen erőforrásra van szükség, mikorra lehet kész, és hasonlók. Tehát egy áttekintő, aminek még nem része a részletes tervezés és a kimenetei.

A projekt charter formai célja az, hogy segítse a projekt tervezés gondolatvezetését. A cél az, hogy minél több és alaposabb információ gyűljön össze a projekttel kapcsolatban. Olyan információkat tartalmaz, melyeknek döntéstámogató erejük van, illetve teret nyit és fókuszáltan rámutat a siker valószínűségét növelő korrekciós lehetőségekre. Tehát a projekt charter egy fontos információs halmaz, amin egyszerűen nem éri meg csak úgy túl lendülni.

A paradox helyzet az, ami esetenként fájni is tud, hogy az előzetes vizsgálatot igénybe vevő idő és energia kifejezhető pénzben, és fel lehetne rögzíteni a projekt költségei közé, amire viszont a technikai feltétek még nem állnak rendelkezésre. Ha a projekt nem kerül elfogasára, a vállalati gyakorlatok és állásfoglalások szerint erőforrás égetésnek minősül. De vajon mennyire erőforrás égető egy projekt indító vizsgálat és dokumentum?

Az alábbiakban megnézzük adattételesen azt, hogy miért nem érdemes erőforrás égetésnek tekinteni egy projekt előtanulmányt, és milyen minimum információkat érdemes összeszedni egy fejlesztés indítással kapcsolatban.

Alapadatok, azonosítás

Az alapadatok között mindenképp a projekt azonosítása a legfontosabb. Ennek két egyszerű oka van. Az egyik az, hogy a projekt nem működést biztosító folyamatos költség (OPEX), hanem egy fejlesztéshez szükséges költség kategória (CAPEX). A CAPEX cégérték növelő funkcióval is rendelkezik, vagyis minden szellemi termék, amelynek az előállítási költsége jól elhatárolható, az egy esetleges cég eladásnál bizony beleszámít az árba. Tehát olyan azonosítást kell megadni, ami a könyvelési tételek között is segít a megkülönböztetésben. A másik a projekt adminisztrációval függ össze. A különböző feladatokat, dokumentációt, a gyors kereshetőséget, és a nyomon követést lehet egységesen kezelni az azonosítóval.

Leíró információk

Még el sem kezdődött semmi, de már itt kerülhet szembe kihívással a gyakorlatlan projektmenedzser, mert különbséget kell tenni a projekt célja, hatálya (scope) és egy rövid összefoglaló között. A három között tartalmi és mondatszerkezeti különbségek is vannak, és pontosan ezért mindhárom, ami négy, ajánlatos a charterba.

1. Rövid összefoglaló: Itt kell megadni azt, hogy a projekt miről szól tulajdonképpen, vagyis milyen fejlesztésről van szó. Összefüggő koherens folyó szöveggel. Tényleg rövid. A projekt méretétől függően maximum 5 mondat. Mehetnek a szakmai kifejezések, mert a rövidség fontos.
2. Hatálya: Mit, milyen területet, funkciót, egyéb érint a projekt. Ez mindaddig egy tág és nyitott, relatíve keret nélküli terepet ad a projektnek, amíg nem zárjuk le azzal, amire már nem terjed ki. Itt már fontos az alapos átgondolás és a pontos megfogalmazás, mert ez az első pont, ahol az agilitást be lehet vetni a megvalósítás során.
3. (+1) Nem hatálya: Mit nem érint már a projekt, mire nem terjed ki, mihez nem kell hozzányúlni, mihez nem járul már hozzá a projekt a megvalósítás során. A nem scope-al zárjuk le a scope-t, és adjuk meg kizárásokkal a projekt kereteket. Ez az első olyan pont, ahol csökkenteni lehet az agilitás mértékén és jellegén. Ez is összefüggő koherens folyó szöveggel. Itt is mehetnek a szakmai kifejezések.
4. Projekt célja: Elvárás az, hogy a fejlesztés eredménye mérhető (pl. teljesítmény, pénz, egyéb) legyen, hiszen a projekt igény is jó eséllyel valamilyen mutatóból ered. A célokat lényegében számosítani kell (ami lehet egy egzakt érték is de ha életszerű, akkor tartományt is meg lehet határozni). A célok meghatározásakor releváns elvárás az, hogy konkrét, mérhető, reális, elfogadható és időzített legyen. Ha eddig sikerült elkenni a projekt leírást, akkor ez az első pont, ahol már konkrétumok kellenek, melyek mentén az eredményesség is igazolható. Ez alól kivétel a jogszabályi megfelelés érdekében nyitott projektek.

Előzetes hatásvizsgálat

Az előzetes hatásvizsgálattal azt a kérdést járjuk körbe, hogy a fejlesztés, mint változás, amelynek a megvalósítására projekt keretrendszert választottunk, hogyan, és milyen mértékben jelenik meg, mely működési területeket, egységeket érint, és mely szereplők számára épül be a napi rutin során. Ennek megfelelően milyen módszert érdemes választani a biztonságos és gyors bevezetéshez. Ebben az esetben az adaptációt illető kötelezettség egyértelműen fennáll, vagyis az elutasítást, felülírást, kihelyettesítést, vagy ignorálást nem engedi meg.

Ha a következő kérdéseket (mondjuk egy likert típusú) skálán értékelve szemléltetjük, már kapunk egy jól közelítő benyomást a projekt komolyságáról:

1. Szervezet működésére gyakorolt hatás – Ez arra ad választ, hogy csak egy funkció és a teljes szervezet működése közötti tartományban mekkora a változás mértéke (Informatikai rendszer érintettség esetén: Az informatikai rendszerek működésére gyakorolt hatás)
2. Üzleti kapcsolatokra (üzletmenet folytonosságra, kvázi az árbevételre) gyakorolt hatás – Ez arra ad választ, hogy a változás milyen jelleggel és mértékben hat hány, milyen típusú ügyfelekre vagy együttműködő partnerekre és a velük való interakciókra a napi rutin során (Informatikai rendszer érintettség esetén: Komplexitás – alkalmazások és a közöttük lévő kapcsolatok érintettsége)
3. Becsült idő – Intervallumos megközelítésben. Minden fejlesztésnek van egy bruttó és egy nettó idő igénye. A bruttó időbe jelenik meg a szabadság, a betegség, a várakozási idő pl. egy beszerzés esetén, a meetingek, workshopok, ünnepek, egyéb. Tehát a becslést a korábbi tapasztalatok és az ismert teljesítmény képességek alapján lehet közelíteni (Informatikai rendszer érintettség esetén: Szintén releváns a bruttó-nettó fejlesztési idő közti különbség)
4. Rendelkezésre álló kompetencia – Vagyis mekkora a külsős és a belsős kompetencia jelenlét és arány (Informatikai rendszer érintettség esetén: szintén vizsgálandó a kompetencia bázis)
5. Van-e és milyen mértékű a más projektekkel való függőség – Nagyon fontos az, hogy hiába tervezünk fel egy projektet jól, ha más projektek kimeneteivel, erőforrás igényével ütközik. Vagyis, ha a projektet, mint fejlesztést behelyezzük a vállalati működés kontextusába, és a paralel fejlesztéseket is figyelembe vesszük, akkor a projektet magát is egy magasabb tudatossággal kezeljük
6. A változás menedzsment – Azt érdemes már itt az elején leszögezni, hogy az átadás-átvétel és a bevezetés milyen formában történik. Egy egyszerű emailes értesítés (mely szereplők részére) és egy kvázi teljes beszállítói lánc oktatása közötti tartományban mi fogja támogatni a működés folytonosságot.

Kiegészítő információk

Ha a projektet folyamatos fejlesztés vagy egy releváns szereplő igénye indikálja (organikussan jelenik meg), vagyis nem stratégiából van származtatva, akkor érdemes kitérni és választ adni arra, hogy

• „Miért most kell a fejlesztés?” (projekt keretrendszerben) – Ez a probléma leírása tulajdonképpen, aminek a fenti projekt leíró tartalmakkal koherensnek kell lennie. Mivel a projektnek számszerű céljai vannak, a megoldandó problémának is kell, hogy legyenek számszerű tulajdonságai.
• „Mi van, ha nem történik meg a fejlesztés?” – A „semmi” rossz válasz. Ez az információ azért fontos, mert egyrészt üzenet a stratégia irányába, másrészt pedig a működéssel összefüggő jövőbeni és elkerülhető kockázatokat és veszteségeket lehet megfogalmazni. Ha ez az információ nem támasztja ki a többit, akkor a projektet a döntéshozó eltolhatja az időben, vagy lesöpörheti az asztalról. Ezért ajánlatos a konkrét, tiszta érvelés, ami nem lehet riogatás és félelemkeltés.

A következő információk pedig nem csak az organikus (alulról vagy oldalról szerveződő), hanem a stratégikus (felülről szerveződő) projektekre is értelmezett, mert tovább keretezik a projektet, valamint ezeknek az információknak az alábontása a tervezés része

• „Hogyan képzeljük el a fejlesztést?” – Itt egy olyan pár gondolatos vázlat kell, amiből további következtetéseket lehet levonni a projekt volumenére. Itt még bőven elég a nagyléptékű listázás. Az sem baj, ha hiányos, mert a feladat és költségterv nem ebbe a részbe kerül.
• „Kapcsolódó dokumentumok” – A dokumentáció szintén a projekt eredménynek (szellemi terméknek) a része. Technikai értelemben pedig azért fontos ez, mert ez már egy elképzelés arról, hogy a projekt részletes kidolgozáshoz és nyomon követéséhez milyen jellegű dokumentumok lesznek szükségesek (melyik résztvevő számára) a feladatok pontos elvégzéséhez. Ennek sem kell pontosnak lenni, mert a feladatok meghatározása fogja mutatni azt, hogy milyen dokumentációra van szükség még.
• „Felelősök, szerepek” – Az elsőre látható döntéshozókat érdemes megadni, akiknek egyben hátráltató hatásuk is lehet, ha erőforrás és feladat priorizálásra kerül a sor. Ez nem egy steakholder mátrix, tehát ha hiányos, az sem baj, mert a tervezés során meghatározott feladatok rámutatnak a részletekre.
• „Látható kockázatok” – A látható kockázatokról már lehet egy első benyomás a fenti előzetes hatásvizsgálat alapján. Tehát itt csak folyó szöveggel fellistázzuk azokat a szűkkeresztmetszeti pontokat, amelyek már a makrovizsgálat során láthatóvá válnak és befolyásolják a projekt háromszög megvalósulását.
• „Egyéb” – Ha van még valami, akkor azt így érdemes megadni. Teljesen nyitott kérdés, akár a projektre nézve periférikus vagy közvetett információ is lehet.

Összegezve tehát, még nem beszélgetünk a tervezésről sem, de látható, hogy ha ezt a makrovizsgálatot elvégezzük, már egy jelentős információ mennyiség áll a rendelkezésünkre egy projekt megítéléséhez. Természetesen ezen információk bővíthetők, szűkíthetők, mert nem a feltett kérdések, hanem a mögöttes döntés támogató logika a lényeg. Ha analógiás logikát keresnénk, akkor az ISO struktúrákhoz jól igazodik.