Akár jól, akár rosszul megy a projektünk, akár az elején, akár a végén tartunk, időnként ki kell állnunk valamilyen plénum elé, és bemutatni az aktuális projektstátuszt. Minél nagyobb, komolyabb hierarchiával, és szigorúbb szabályokkal rendelkező szervezetben dolgozunk, annál nagyobb jelentősége lesz ezeknek az alkalmaknak. Sokszor projektünk alapvető megítélése és saját karrierünk is állhat vagy bukhat egy-egy jól vagy rosszul sikerült beszámolón, nézzük hát meg, hogyan lehet sikeresen venni ezt az akadályt!

Hogy egy kicsit élőbbé és megfoghatóbbá tegyük a dolgot, szakítva az eddigi hagyományokkal egy esettanulmányon keresztül járjuk körbe a témát. A fiktív projekt egyik kedves olvasónk fórumos kérdéséből származik: ehhez fogunk most prezentációt készíteni.

Kitalált projektünk a következő: a cél egy termékkalkulátor elkészítése egy banknak. A szoftvert a bank back office és értékesítési részlegei is használni fogják, ez a két szakterület a két szponzora a projektnek. Természetesen más és más elvárásaik vannak a majdani rendszerrel szemben: a back office egy Excel táblából nagyon széles körűen konfigurálható rendszert szeretne, kifinomult jogosultsági rendszerrel. Az értékesítés elvárása az, hogy egy okostelefonon is elérhető, látványos felülete legyen a kalkulátornak, amivel az ügynökök terepen is elkápráztathatják a reménybeli ügyfeleket. Az élesítés határideje 2012. március lett volna, de a tervezés során a back office igényei nem lettek kellőképpen figyelembe véve, így az eddig elkészült szoftver nem tartalmazza az általuk elvárt funkciókat, ezért nem élesíthető. Az élesítés az eredeti tervekkel ellentétben így augusztusra csúszhat, borul az eddig tervezett büdzsé: ezt a nem túl vidám helyzetet kell tálalnunk a projekt szponzorai (értékesítési igazgató, back office igazgató, projektiroda vezető) felé. Ezt a plénumot szokták még Projekt Irányító Bizottságnak, Steering Committee-nek, Project Board Meeting-nek is hívni, ez ízlés és szervezeti kultúra kérdése.

A helyzet meleg, nagy a gáz, hiszen egy szponzornak a csúszásnál csak az fáj jobban, amikor még több pénzt kell valamire adnia. A célunk egyértelmű: elkerülni az ordítozást, azt az üzenetet közvetíteni, hogy bár nem a tervezettnek megfelelően alakultak a dolgok, az eseményeket kézben tartjuk és a most bemutatandó korrekció után sínen lesz újra a projekt. Egyszerűen kell fogalmaznunk, olyan embereknek fogunk beszélni, akik valószínűleg nem sokat tudnak a projekt részleteiről, és azt is régen elfelejtették már, amit egy hónappal ezelőtt az előző bemutatón bemutattunk nekik. Ennek oka nem az, hogy gyengeelméjűek, hanem az, hogy ezer más dologgal is foglalkoznak és egyszerűen erre a témára ez az egy órájuk jut egy hónapban.

A bemutatóra mindenképpen csiszolt, céges sablont követő prezentációval érkezzünk. (A PowerPoint lesz most a jó választás. Mostanában terjed a Prezi is: én nagyon szeretem, de egy bankban egy ilyen helyzetben nem a parasztvakításra koncentrálnék.) Egyszer úgy mentem el egy ilyenre, hogy nem csináltam póverpointot, mert iszonyú sok dolgom volt a projektben, gondoltam minek ezzel a prezentációra való készüléssel egy napot eltölteni, hiszen egy hajóban evezünk, legalább hatékonyabbak leszünk, blablabla. Na akkora botrány volt, mint a Watergate: az (egyébként ugyancsak banki) vezetők vérig voltak sértve, hogy nem évezhették végig a szokásos műsorukat. Akkor értettem meg, hogy legtöbbször az ilyen helyzetekben a szertartás fontosabb a hatékonyságnál.

A beszámoló általában a projekt aktuális helyzetének bemutatásával, illetve eddig elért eredményeivel kezdődik.  Két-három dián érdemes a következő dolgokat megjeleníteni:

• Eddigi események egy időskálán (kezdés, tervezés, fejlesztés)
• Eddig elkészült projekt termékek (elemzési és tervezési dokumentumok, működő rendszerrészek)
• Aktuálisan érvényes büdzsé és az ebből eddig elköltött összegek, főbb költséghelyek szerinti bontásban
• Projekt általános állapota (itt szoktak zöld, sárga meg piros lámpákat használni a könnyebb érthetőség kedvéért például) 

Ha nem lenne akkora slamasztikában a projekt, mint amekkorában van, akkor a következő témákat lenne érdemes végigbeszélni:

• Ismert kockázatok és kezelési módjuk
• Eszkalált (a projektvezető és főnöke hatókörén túlmutató)
• A következő időszak eseményei
• Ismert külső függőségek ismertetése, az ezek kezeléséhez szükséges támogatás megszerzése

1. A problémás pont ismertetése: az előzetes felhasználói tesztek megkezdésekor kiderült, hogy egy nagy csomag felhasználói igény nem került megvalósításra.
2. Az okok bemutatása: a funkcionalitás kimaradásának kettős oka volt. Egyrészt a back office terület csak felületesen lett interjúztatva, illetve a készülő tervezési dokumentumokat a back office terület nem véleményezte kellő sebességgel, illetve a véleményezők nem rendelkeztek kellő hatókörrel az elvárásokkal kapcsolatos döntések meghozatalához. 
3. Azonnali beavatkozás, hogy ez ne fordulhasson elő többet: a felmérési módszertanon változtattunk a projektben. Az elemzői csapat kéthetente félnapos workshopot tart mind az értékesítés, mind a back office megfelelő szintű vezetőivel (kérés: az Irányító Bizottság tagjai jelöljék ki területükről a felelősöket!) Ezeken a személyes jelenlét kötelező, a döntéseket dokumentumok küldözgetése helyett élőben, azonnal konszolidálva hozzuk mostantól meg. 
4. Döntési helyzet bemutatása: a rendszert vagy a jelenlegi terjedelemmel élesítjük nagyjából az eredeti ütemezés szerint (ekkor kimaradnak a back office által elvárt funkciók), vagy a projektet átütemezzük, és mindent megvalósítunk.
5. Az átütemezés terveinek bemutatása 1: a hiányzó funkcionalitás felsorolása magas szinten, üzleti előnyök
6. Az átütemezés terveinek bemutatása 2: új magas szintű projektterv, erőforrásterv, költségterv.

A bemutató közben és után záporoznak majd a kérdések, rosszabb esetben a vádak és a támadások. Készüljünk erre, és mutassunk határozottságot, sugározzuk azt, hogy kézben tartjuk az eseményeket. Soha ne tegyünk föl nyitott kérdéseket („Most akkor mit csináljunk?”), mindig eldöntendőkkel dolgozzunk. Ne állítsunk kényszerpályát sem a feletteseink elé: jelen példánkban is értelmes és vállalható döntés lehet a rendszer élesítése 50%-os scope-pal.

A prezentáció tartalmát érdemes a felettesünkkel (jelen esetben a projektiroda vezetőjével) egyeztetni, jóváhagyatni. Sőt, az igazán furfangosak a rossz hírt (csúszás) minden Irányító Bizottsági tagnak elhintik valamilyen formában a rossz híreket a bemutató előtt (direkt vagy indirekt), hogy ne ott kapjanak sokkot, hanem már a megoldásra fordíthassák azt a jajjjj de drága idejüket. Projektorról gondoskodjunk, és nyomtassuk ki a prezentációt a meghívottak száma plusz két példányban , nehogy valami váratlan és fontos vendégnek ne jusson, aki emiatt sértve érezze magát. Használjunk újrafeldolgozott papírt, hogy az esőerdők se váljanak projektünk martalékává! :)

Hatalmas sikerre ne számítsunk egy ilyen helyzetben, de kellő határozottsággal és pragmatizmussal tovább lendíthetjük a projektet a krízishelyzeten. Ugyancsak fontos eredmény lehet, hogy magunk mögött tudjuk a felsőbb vezetők támogatását egy új, hatékonyabb működési modellhez. Ha végeztünk, ne felejtsük el kitűzni a résztvevőkkel a következő Projektbemutató időpontját, még aznap emlékeztetőt írni a találkozóról és kiküldeni a megjelenteknek!

Sok sikert és bátorságot mindenkinek a következőhöz, ne felejtsétek el megírni, ha valamelyik bemutatótok különösen jól, vagy rosszul sikerült!