(2020.07.14 - Szalay Imre, Kovács Kálmán, Arora Barbara, Dr. Sándor Zoltán)

Felmérés eredmény

A Profexec Kft. kezdeményezésére és szakmai szervezésében 2020. márciusában és áprilisában internetes kérdőív segítségével tettünk fel kérdéseket annak érdekében, hogy jobban megértsük, hogyan működnek a projektirodák (PMO-k) a vírusválság ideje alatt.

Végül is 21-en válaszoltak, ez 21 különböző szervezetet is jelent, így ez a kör már megfelelően reprezentálja a hazai PMO társadalmat.

A felmérés eredményét megvitattuk a Profexec Kft. által rendszeresen szervezett PMO klubban, valamint egy a Magyar Szolgáltatóipari és Outsourcing Szövetség (HOA, Hungarian Service and Outsourcing Association) rendezvényén. Az ezeken, ezúttal online, beszélgetéseken elhangzott véleményeket is beépítettük a felmérésről szóló összefoglalónkba.  

A felmérésben résztvevők összetétele

A 21 válaszadóból 9 PMO az IT és Telecom ágazati, 4 pénzintézeti és 5 ipari ill. energetikai szektorbeli, 2 közigazgatási és 1 tanácsadási PMO volt.

A vállalatok méretére is rákérdeztünk és ahogy vártuk, többségében nagyobb szervezetek igénylik a PMO szolgáltatásait, hiszen itt is 4 közepes, 12 nagy és 2 óriás szervezetből kerültek ki a válaszadók és 3 kicsi szervezet reprezentálta magát.

Bár többféle PMO működést ismerünk, projekt kompetencia központként működő, portfólió menedzsment funkciót ellátó vagy éppen projektvezetőket tömörítő szervezetet. A mi értelmezésünkben a vállalatirányításhoz szervesen kapcsolódó szervezeti egységet vesszük elsősorban, ami működteti a projekt portfóliót és meghatározza a projekt kultúrát támogató keretrendszereket és folyamatokat.

A projektvezetők száma is iránymutató egy szervezet projekt kultúra fejlettségére vonatkozóan, ezért arra is rákérdeztünk. A megoszlás úgy alakul, hogy a 10 válaszadónál 10-20 körüli projektvezető van, 5-nél 50-nél is több, 6-nál 5-nél kevesebb. Ezek az adatok segítenek értelmezni a vállalati besorolást, pláne, ha hozzátesszük a válaszadók közt vannak multik, ahol a PM-k száma a több százat is meghaladja.

Projektvezetők által használt eszközök

A csoportmunkát, megbeszéléseket támogató eszközök közül a Skype és a Teams emelkedett ki. A  Webex, Zoom használatának korlátozására több helyen is a biztonsági résekről szóló információk miatt került sor. Kiváló projekt kommunikációs eszköznek bizonyult a Slack többek elmondása szerint.

 Jó pár esetben a PPM tool fejlesztését gyorsították fel vagy fejezték be annak érdekében, hogy az információ megfelelően áramoljon és a menedzsment többlet információs igényét jobban ki tudják elégíteni.

Az adat és információ megosztó, együttműködést biztosító eszközök (Sharepoint, Onedrive, Google drive esetleg más file megosztók) használata is jobban előtérbe került.

Azt fontos hozzátennünk, hogy a válaszadók (írásbeli és szóbeli) megerősítették azt is, hogy legtöbb esetben VPN-en keresztül kapcsolódtak a vállalati rendszerekhez és kommunikáltak egymással. Sok esetben kihívás volt a megfelelő sávszélesség biztosítása.

Nehézségek az új munkarendben

Természetesen sok esetben okozott nehézséget az új munkarend, ami alapvetően a személyes jelenlétet vesztette el. Ez azokon a munkahelyeken okozott kellementlenségeket, ahol a home-office újdonság volt a munkarendben.

Meglepetés volt sok munkahelyen a vezetés számára, hogy milyen egyszerűen és gyorsan sikerült a hazaköltözés és a dolgozók milyen gyorsan alkalmazkodtak az új körülményekhez. Más felmérés is megerősítette, hogy sok esetben a virtuális csoportokkal való munkavégzés hatékonyabb volt, de emellett több előkészületet jelentett mindenki számára. A work-life ballance is felborult, összefolyt a munka és a magánélet, gyakran este vagy kora reggel is megbeszélések voltak. Így az otthon dolgozók nem mindig tudtak megfelelően pihenni és szórakozni, és persze nem szabad elfeledkezni arról sem, hogy a gyerekek is otthon voltak, rájuk felügyelni, vagy velük tanulni kellett, nem beszélve az otthon levő család teljes és folyamatos  ellátásának feladatairól.

Azt is jelezték kollégák, hogy egyszerre 3-4 kommunikációs csatornán is tartották a kapcsolatot, a különböző csatornákon más és más eszköz volt az elvárt kapcsolódási platform.

A megbeszélések száma növekedett, a videókonferenciák intenzitása megnőtt, és a korábban szokás heti 2 helyett most napi 2-3 videóhívás volt. És volt olyan cég, ahol meeting mentes napot vezettek be, hogy akkor a dolgozók a heti adminisztrációs munkákat el tudják végezni.

Továbbá beszámoltak arról, hogy a Budapesten 4000 és globálisan 400.000 dolgozót foglalkoztató nagyvállalat egy hét alatt papírmentes irodává alakult.

Sok esetben a dolgozók munkahelyük elvesztésétől vagy éppen bérük csökkenésétől is féltek hallván a híreket. Szerencsére a válaszolók közül egy esetben jeleztek PM létszán csökkentést. 

Ezek a nehezítő tényezők a PMO-t és a projektet vezetőktől érzékenyebb reagálást igényelt felismerni a speciális helyzeteket és rugalmasan kezelni a problémákat. Az új helyzetben új motivációs eszközökre van szükség: a csoport vagy projekt tagok mind többlet figyelmet igényelnek, többet kellett beszélni velük, hogy az egyéni munkaszervezési és motiváltsági problémákat megfelelően kezelni lehessen.

Prioritások változása

Természetesen a vállalati prioritások is megváltoztak.  A legtöbb új projekt célja a home office feltételeinek kialakítása volt eszközök, adat és IT biztonság terén (akár számítógépek otthoni vagy éppen megfelelő internet biztosítása mellett), valamint az alapműködés stabilitásának átgondolása.  Könnyebb volt azokat a portfóliókat újra priorizálni, ahol már megvolt egy priorizálási rendszer.

A beszélgetéseken az is kijött, hogy olyan ágazatokban, ahol a személyes jelenlét az ügyféllel elengedhetetlen volt idáig, digitalizálni kellett a folyamatokat (kozmetikai termékek értékesítése, biztosítási termékek értékesítése), több fejlesztés is elindult ezekkel kapcsolatban. Máshol a partner bolt hálózat védelme érdekében alapítottak projektet, hogy a vírus időszak miatt lecsökkent vagy éppen megszűnt forgalom miatti gazdasági összeomlást valamilyen formában elkerüljék, hogy az élet rendeződése után tovább folytathassák partneri értékesítési tevékenységüket. De a home office kikényszerítette az elektronikus aláírással kapcsolatos fejlesztéseket is. Természetesen a dolgozók egészségvédelme is alapvető volt, ami nem csak a hazaköltözésben testesült meg, hanem pl. fiókhálózatokban kialakított új folyamatok és munkarend kialakításában.

Projekt leállások

Projektek száma  10 esetben változott, 7 esetben nem változott, 4 esetben átütemezések voltak. A  változások indokai sokrétűek: stratégiai okokra is hivatkoztak, de óvatosságból költségcsökkentés miatt is több projekt leállt és az emberi erőforrások – elsősorban a fizikai jelenlétet feltételező projektekben  - egészségvédelmével is indokolták.

Legtöbb helyen a projektvezetők száma nem változott. Ha volt változás, akkor a külsős, szerződéses projektvezetőket építették le és helyüket belsős kollégák vették át, akiknek mentorálásra volt szükségük, hogy folytassák a megkezdett munkát. Itt a hatékonyságot nem mérték, hogy az eredetileg a projektre kiválasztott projektvezető és a belülről áthelyezett és mentorált kolléga teljesítményét illetően.

A projekt  összetétel változtatásában az alábbi megfontolások játszották a legfontosabb szerepet:

• Mindent későbbre halasztanak, amit lehetséges
• Ahol nem lehet azonnal vagy a közeljövőben eredményt elérni vagy felmutatni, leállították
• Ha kis kockázata volt a leállásnak, akkor IT fejlesztéseket függesztettek fel
• Jogszabályi megfelelés és COVID-19-es krízisre reagáló fejlesztési projektek futnak

Projektportfólió irányításának változásai

Érdekelt minket, hogy a vállalatirányítás hogyan változott, megmaradt-e a projektportfóliót irányító testület, a PMO szerepe, eleve a portfólió szemlélet?

A visszajelzések azt mutatták, hogy a projekt portfólió menedzsmentre szemlélet inkább erősödött, még jobban támaszkodtak erre a szervezet irányítási eszközre a válságkezelés során. A PMO munkája fontossága nem változott, tartalmában volt átalakulás.

A PMO konkrét szerepváltozásában a hívó szavak:  a válság menedzsment, többlet kommunikáció, többlet információadás a vezetés számára, emberi erőforrások gyors átszervezéséhez naprakész jelentések,  a budget csökkentéshez szükséges információk nyújtása, újra priorizálás. 

Hogyan változott a PMO munkája?

A PMO szerepe a válságmenedzsmentben:

14 esetben maradt vagy erősödött az irányító testület is (ügyvezetés, portfólió tanács, projekt panel stb.) hasonlóan az előző gyakorlathoz vagy fókuszáltabban működött a válság során. A PMO szervezet és a PMO vezető szerepe megerősödhet a szervezetben, ha segíteni tudja a felsővezetést, hogy a válság kezelése ne csak rövidtávú tűzoltás, hanem a hosszabb távú újraindítás, újjáépítés-tervezés  alapja is legyen, hogy a szükséges kompetenciát és erőforrásokat is meg tudják őrizni, sőt  a folyamatos foglalkoztatásukról is gondoskodjanak a projektekben.

Működik-e az irányító testület?

Idézetek a beszélgetések során elhangzottból a PMO szerepéről:

• Kommunikálni, kommunikálni, kommunikálni. Cégen belül és cégen kívül.
• A helyzet napi szinten változik, ezt ne felejtsük!
• Fő a pozitív gondolkozás.
• A PMO nem pánikolhat: Nyugalom, magabiztosság

Nem a tréningek ideje volt a válság alatti karantén

Azzal a feltételezéssel éltünk, hogy a válság nem csak a válságkezelő tréningek igényét növeli, hanem az utazások megtakarításával, a több otthon töltött idő, lehetőséget ad, igényt teremt a tanulásra ill. az esetleges feladatcsökkenést a cégek tréningekre használják fel.

Ezt nem igazolták vissza a válaszadók. 

A válságkezelő tréningek kevés esetben szerveződtek, s az egyéb képzésekben sem dúskáltak a munkatársak. Inkább volt jellemző volt a belső erőforrásokon alapuló tréning a büdzsé megszorítások miatt.

Válságkezelő tréningek

Felhasználják a helyzetet a munkatársak képzésére

Konklúziók

Az is célunk volt a felméréssel, hogy olyan jó gyakorlatokat osszuk meg egymással, amiket a továbbiakban lehet alkalmazni akár „békeidőben”, akár egy újabb járvány kitörése esetén felkészültebbek legyünk. A fentiekben ezek többségét megemlítettük de az alábbiakban is felsorolunk néhányat: 

• „békeidőkre” kidolgozni a home office feltételeit – folyamatok, beszámoltathatóság
• jövő a hibrid?! (heti 2-3 nap home office lehetőségének felajánlása a dolgozóknak)
• no meeting day bevezetése
• katasztrófaterv készítés
• elektronikus aláírás elterjesztése
• ahol lehet projekteknél a hibrid, rögtön az indulásnál kialakítani a feltételeket
• vezetői videók gyakrabban, informatívabban
• az emberek igénye az emberekkel való találkozóra, az emberi kapcsolatok tőkéjének értéke kirajzolódott
• a vészhelyzeti hatékonyság nem várható el „békeidőben”

A PMI PMBOK Guide-ot a képzések során szeretem profi projektmenedzsment szakácskönyvnek nevezni, mert egy olyan jól strukturált eszköztár és módszer gyűjtemény, amely gyakorlott projektmenedzserek számára nyújt igazán segítséget és megoldásokat a napi munka során is. A PMI a PMBOK Guide 6. kidolgozása során úgy döntött, hogy hallgatva az idők szavára, valamilyen érdemi módon foglalkozni akar az adaptív/agilis projektfejlesztési módszerekkel és rendszerekkel. A megoldás az lett, hogy a PMBOK Guide kiegészült egy kisebb lélegzetvételű második kötettel, ami eredetiben az Agile Practice Guide címet kapta. A könyvet a PMI az Agile Alliance-el együttműködésben, közösen adta ki, így ez garanciát jelent arra, hogy a leírtak mind projektmenedzsment, mind agilis szempontból relevánsak és helytállók. A közelmúltban a PMI Budapest, Magyar Tagozat támogatásával elkészült és a boltokba került a mű nagyon színvonalas magyar fordítása is, amit remélek, hogy minden hazai projektmenedzser polcára és tudásába bekerül.

Ha a PMBOK Guide-ról azt mondhatom, hogy egy profi projekt szakácskönyv – azaz igazából csak olyan gyakorlott projekt szakácsok számára releváns segítség, akik már tapasztaltak a projektmenedzsment eredménykifőzési folyamatokban –, akkor az Agilis gyakorlati útmutatót egy olyan induló és iránymutató szakácskönyvnek nevezném, amelyet az agilis témában még nem jártas projekt szakemberek is hasznosan forgathatnak és megkóstolhatnak. A szerkesztése is sokkal olvasóbarátabb, mint a PMBOK Guide. Ehhez a könyvhöz le lehet ülni egy karosszékbe és egyszerűen elolvasni. Érdemileg körülbelül 140 oldal csak a terjedelem, de a lényeget a véleményem szerint nagyon jól megfogja.

A könyv természetesen a megszokott módon az agilitás alapfogalmaival és a megközelítéssel kezdi. Örülök, hogy nem állítja szembe az adaptív megközelítést a prediktív projektmenedzsment folyamattal. Mindkettő eszköznek megvannak az alkalmazási feltételei, keretei és határai – sok elem pedig kölcsönösen használható is a projektek sikerre vitele során. A könyv minden fejezete tartalmaz érdekes információkat és agilis alkalmazási példákat, de én szeretném azt a néhány érdekes részt kiemelni és ismertetni, amelyek leginkább felkeltették az érdeklődésemet.

Nagyon érdekelt az a rész a könyvben, amely az adaptív/prediktív hibrid módszereket mutatja be. Azért volt ez számomra különösen érdekes, mert projektmenedzser kollégákkal beszélgetve inkább negatív valós tapasztalatokról hallottam eddig a hibrid módszertanok alkalmazása kapcsán. A valós működésben gyakrabban jelenik meg a hátrányok ötvözése a hibrid megközelítésekben, mint az előnyök realizálása.  Ugyanakkor a könyv hibrid módszerekről szóló fejezete számomra meggyőzően magyarázza, hogy melyek a kulcstényezők a sikerhez, illetve bemutat négy különböző hibrid megoldási modellt is. Úgy gondolom, hogy mindenféle szituációhoz választható alkalmas (akár hibrid) modell, a siker a folyamatot működtetni és sikerre vinni akaró vezetőkön és csapattagokon fog múlni!

A következő számomra különösen érdekes szakasz a könyvben az agilis projektek mérésével foglalkozik. A szélesebb körben is már ismert burndown és burnup diagramokon túl szerintem nemcsak agilis projektekben lehetnek hasznosak a következők:

• A követelmények időbeli megvalósítását leíró időintervallum értékek Kanban tábla használata mellett:
  • válaszidő – a munka megkezdéséig tartó várakozási idő
  • ciklusidő - egy tétel feldolgozásához szükséges idő
  • átfutási idő – egy tétel leszállításához szükséges összes idő (válaszidő+ciklusidő)
• Agilis megtermelt érték (earned value) diagram és mutatószámok
• Funkciók halmozott áramlási diagramja

Az agilis módszerek bevezetésének elsődleges sikertényezője, hogy miként sikerül a szükséges szervezetfejlesztés, illesztés és agilis gondolkodásmód meghonosítása a vállalatnál. A könyv egy egész fő fejezetet szentel a kérdéskörnek. Meghatározza azokat a szervezeti jellemzőket, amelyek elősegítik az agilis bevezetést: pl. a szervezet és a vezetők változási hajlandósága; eleve meglévő magas szintű csapat felhatalmazások, empowerment és decentralizáció; tudatos tehetségmenedzsment. Akadályozó szervezeti jellemzők lehetnek: részlegekre és funkciókra bontott működés; rövidtávú ár és költségoptimalizálási stratégia; kompetencia specializációra ösztönző rendszer; egyidejűleg futó sok kezdeményezés. A szakaszban ismertetésre kerülnek azok a szervezeti kultúra szempontjából lényeges tényezők, amelyek egy agilis bevezetésnél kiemelkedő fontosságúak. Több oldalon keresztül foglalkozik a könyv a PMO szerepével és feladataival is olyan helyzetben, amikor a vállalat agilis üzleti érték teremtési modellben gondolkodik.

A könyv talán számomra leginkább hasznos eszközét az X3-as függelékben találtam meg az „Agilis alkalmassági szűrőeszközök” cím alatt. Ez a függelék egy azonnal használható, kilenc osztályozási kritériumot figyelembe vevő kvalitatív felmérő eszköz, amellyel gyorsan eldönthető, hogy a vállalati kultúra, a csapat és a projekt jellemzői alapján alapvetően agilis, hibrid vagy prediktív projekt megközelítést válasszunk-e. A modell nemcsak a döntéshozatalban segít, hanem abban is, hogy melyek lesznek a projektcsapat számára a lényeges kihívások a megvalósítás során. Az egyik felmérő kérdés így szól: Meg fogja-e kapni a projektcsapat az autonómiát ahhoz, hogy meghozza a munkavégzés módjával kapcsolatos helyi döntéseit? A kérdésre 1-10-es skálán kell választ adni, ahol az 1-es a „határozott igen”, 5-ös a „valószínűleg” és 10-es a „nem valószínű” válasz. A felmérés eredményét radardiagramon lehet bemutatni és értékelni.

Minden projektmenedzser kollégának őszintén a figyelmébe ajánlom az Agilis gyakorlati útmutató elolvasását és tanulmányozását!

Lipi Gábor, PMP – lipi.gabor@pmpvizsga.hu

Egy ideális projekt controlling rendszernek rengeteg tulajdonsággal kell rendelkeznie. Ezekből el lehet hagyni egyes elemeket, bevezetésénél azonban mindig arra kell törekedni, hogy RENDSZER szemléletben dolgozzunk, tehát lehetőség szerint ismerjük fel és kerüljük el a sziget rendszereket.

A cikkben bővebben a projekt controlling-ról >>

Üdvözlet mindenkinek!

Újraindul a PROJEKTblog. Lipi Gábor vagyok és szívesen felvállaltam, hogy a blogban időnként megjelentetek projektmenedzsment írásokat, új gondolatokat.

Elsőként egy angol nyelvű cikket ajánlok a figyelmetekbe amely a Projektmenedzseri kiégés három legfontosabb jelére figyelmeztet. Ha bármelyiket tapasztaljátok magatokon, gyorsan forduljatok szakemberhez! 

Az egyre jobban terjedő agilis projektmenedzsment kapcsán köztudatba került az önszerveződő teamek fogalma. Az agilis teamek többé-kevésbe önállóan működnek, saját hatáskörben hoznak döntést, ütemeznek, kezelik rugalmasan a változásokat, közvetítő nélkül egyeztetnek az ügyféllel. A projekt sikere nem a PM módszertantól, hanem a kiváló csapatmunkától függ.

Igen ám, de hogyan lesz erre a működésre alkalmas, igazi önszerveződő csapatunk a hierarchizált világban szocializált tagokból? Milyen is egy igazi önszerveződő team? (Nem biztos, hogy az agilis team minden részletében ilyen.)

Az önszerveződő teamekben a feladatnak megfelelően változik, ki tartozik bele, merre mozognak, milyen sebességgel. Nem beosztások, hanem a tagok személyes kompetenciái alapján önként vállalt szerepek vannak, amik szintén változnak, ahogy a munka megköveteli. Nincs formális vezetés, mindenkinek a szerepéhez tartozó hatásköre van. A szerepek természetesen nyilvánosak, mindenki tudja mindenkiről, miben számíthat rá.  Minden szükséges szerep a team tagjaiban él: a beszerző, az ügyfélkapcsolattartó, a pénzügyes, stb. is a team tagja, nem egy központi egységben dolgozik. Egyenrangúság van, de a tudás, szakértelem, tapasztalat alapján vannak, akiknek komplexebb szerepeik vannak, vagy éppen mentorként is működnek: hozzájuk fordulnak szalmai tanácsért.

A döntéseket nem „felülről” várják és kapják, hanem maguk a tagok hozzák meg. Saját maguk döntenek arról, kit vesznek fel a teambe, a csapattagok  - és nem egy vezető – értékelik egymás munkáját.

Az információkat nyíltan kezelik, a problémákat, ötleteket mindenkinek felelőssége és kötelessége felvetni – nem elfogadott a „nem az én dolgom” hozzáállás. A projektek menedzselése a lehető legegyszerűbb: mivel maguk hozzák a döntéseket, nem kell jóváhagyásokra várniuk. A projekt addig él, amíg értelme van – amíg a team hasznosnak látja. (Aki látott már régen értelmét vesztett, végeláthatatlanul elnyúló projektet, az tudja, micsoda nagy dolog ez. )

Furcsa lehet, hogy vezetés nélkül dolgozó csapatokról beszélünk. Valóban, alapfeltétel, hogy a vállalat vezetése szívből, őszintén kiálljon emellett, és biztosítsa a szükséges környezetet ehhez. Ezek teamek – az első benyomás ellenére – nem össze-vissza, hanem nagyon is keretek között, szabályozottan működnek. Feltétel az is, hogy a csapattagok egyénenként érettek és képzettek arra, hogy így dolgozzanak.

Milyen szabályok szükségesek? Teamenként, cégenként változhat, de többnyire szabály van

- a döntéshozatalra (Pl. az  „Advice process” – vagyis meg van határozva, hogy a döntéshozó csapattag meg kell hogy kérdezze az érintetteket, valamint a szakértőt a témában. Utána ő hoz döntést, és felelősséget is vállal érte.),

- a problémafelvetésekre, ötletek kezelésére (Pl. a Logbook – mindent be kell írni, hozzá lehet szólni, és rendszeres átnézés kapcsán eldöntik, melyik felvetéssel foglalkoznak.),

- problémamegoldásra, közös döntéshozatalra (Pl. strukturált, csoportos problémamegoldó módszereket kell használni.),

- konfliktusok kezelésére (Pl. meghatározott lépések vannak: először szemtől-szembe kell tisztázni azzal, akivel problémám van, utána lehet mediációt kérni, stb... vagyis tilos szétteríteni a konlfiktust, bevonni másokat.),

- egymás értékelésére (Pl. saját munka- és fejlődési célokat állítanak fel, amit bemutatnak, és amik alapjául szolgálnak ahhoz, hogy egy munkatárs majd értékelje őket.).

Azok a vállalatok, amelyek önszerveződő teamekben dolgoznak, minden egyes munkatársukat képzik együttműködő, erőszakmentes kommunikációra, konfliktuskezelésre és mediációra, strukturált csoportos döntéshozó módszerekre. A munkatársaknak – nemcsak a vezetőknek – egyéni coaching áll rendelkezésükre, és a csapatok is kapnak team-coachot, megbeszéléseikhez facilitátort, ha igénylik. Ezek a segítők a tartalmi kérdésekbe nem szólnak bele, csak hozzásegítik a teamet, hogy saját maguk megoldják a problémáikat, javítsák a működésüket.

Az agilis projektmenedzsment terjed – de nem tud igazán működni, ha a vezetők és  benne dolgozók a régi hozzáállásukat, viselkedési mintáikat hozzák magukkal. Az agilis teameket – és környezetüket - alkalmassá kell tenni arra, hogy valóban önállóan működjenek!

A legutóbbi tréningen valaki azt kérdezte, hogy biztosíthatná, hogy minden team-tagnak egyértelmű legyen, mi az ő dolga?

Két  eszközt használhatunk erre: a feladatlebontási struktúrát (Work Breakdown Structure) és a munkacsomag leírást. Elég ronda nevük van, de nem olyan bonyolultak...

Először megkerestük a leszállítandóinkat, utána fellistázzuk azokhoz vezető feladatokat. Vagy a mind map-et használhatjuk erre, vagy egyszerű post-ites módszerrel dolgozhatunk. Kell egy csomagolópapír a falra, sok post-it,  amikre egy-egy feladatot írunk, és felragasztjuk a csomagolópapírra. Egyelőre ahogy eszünkbe jut, mert utána fogjuk rendezni őket.

A rendezés módszere:

Főtevékenységek (5-8 / projekt): nagyobb összefüggő feladatkupacok, amik majd kisebb rész-lépésekre bonthatók.

Rész-tevékenységek (5-15/ főtevékenység): olyan munkalépések, feladatok, amiket nem érdemes tovább bontani, egy emberre rábízhatók.

Így néz ki (a kódszám későbbi munkánkat könnyíti):

Egy-egy résztevékenységet tehát ki akarunk adni egy munkatársnak. Ha szeretnénk, hogy önállóan dolgozzon, és azt tegye, amire szükség van, készítsünk munkacsomag leírást minden résztevékenységre.

Ez így néz ki:

 Miért szükséges ennyi minden? Gondoljuk meg, ha a projektmenedzser csak annyit mond Zénónak, hogy az ő dolga „lehetséges helyszínek keresése a vevőtalálkozónak” (és ő még nem csinált ilyet), akkor előfordulhat, hogy Zénó

- megjelenik egy netről leszedett címlistával, de semmit nem tud a helyekről,

- megjelenik egy listával, de nincs információ arról, hogy lehet-e svédasztalos meleg ételt rendelni,

- megjelenik egy db címmel,

- megjelenik egy szerződéssel, hogy ő kiválasztotta, megrendelte,

- talált egy helyet, ami éppen akkor zár be, amikor a rendezvényt tartanánk...

Ha a projektmenedzser agyában a fenti táblázat tartalma volt, Zénó egyik megoldásától sem lenne boldog.

Ez a táblázat eszközt ad Zénó kezébe, hogy

- lássa, pontosan mi mindent kell elvégeznie, milyen keretek között, milyen szempontok figyelembevételével,

- milyen információt kap meg ehhez és kitől (lobogtathatja Béla felé, hogy szüksége van az infóra),

- mit kell leszállítania, és kinek,

- mikorra,

- miben dönthet ő maga.

 Ha minden rész-tevékenységre van munkacsomag-leírásunk, tuti, hogy nem marad ki lépés, pontosabban tudjuk tervezni, melyik lépéshez mennyi időre (és milyen egyéb erőforrásokra) van szükség. Hogy mi mindenre jó még a feladat-struktúra, hogyan használható tervezésre, a következő posztban írom le.

Számos definíció létezik a „projekt”-re.

Ezek között  van,ami úgy fogalmaz, hogy a projekt azért jön létre, mert van egy probléma, amit meg kell oldani: a jelenlegi, nem megfelelő  állapotból el kéne jutni a kívánatos állapotba.

Sok projektnél kérdéses, hogy a valós problémát oldjuk-e meg.  Vagy csak egy tünetet kezelünk, az első eszünkbe jutott „megoldással”? Felderítjük-e szisztematikusan a látható, érezhető tünetek alapvető, kiváltó okát vagy okait?

A vállalkozásoknál sok értekezlet azért jön létre, mert „van itt egy probléma, amit meg kéne oldanunk”. Elhangzik a kérdés: mi a helyzet?  A válaszok, amiket megfogalmaznak  egymásra licitálva a dominánsabb, hangosabb résztvevők, tartalmaznak tüneteket,  hibáztatásokat, megoldási javaslatokat, (feltételezett) okokat, egyedi eseteket, magyarázatokat, és lehetne tovább sorolni... Az értekezlet vége felé pedig kiragadnak egy "megoldást", és indítanak erre egy projektet...

Ugyanez a helyzet, amikor projekt közben merül fel valami probléma. Nem a megfelelő módon, ütemterv szerint, vagy tartalommal megy a projekt, és ezért kezdünk neki a „problémamegoldás”-nak.

Strukturált, kreatív, és ezért hatékony problémamegoldó folyamat a legritkább esetben jön létre. Sokkal inkább parttalan vita, hiányos, egyoldalú nézőpontok hangoztatása, szűk területen való gondolkodás, hagyományos megoldások sorolása. Már azt is másképpen látjuk, mi a probléma, és ebben sem egyezünk meg. Így van aki erre, van, aki arra keres „megoldást”. Kitalálunk valamit, összevissza haladva, majd találomra döntést hozunk arról, mit fogunk tenni. Vajon az a „megoldás”, ami így indul, sikeres lesz-e valóban?

Ehelyett mit lehet tenni?

Első javaslat – a folyamatról:

Problémamegoldó folyamataink egyik hibája, hogy együtt, keveredve jelenik meg benne a kreatív, ötletgeneráló lépés és az ötletek értékelése. Az első folyamat csapongást, fantáziát, jobb agyféltekés gondolkodást, inspirációt kíván, míg a második bal agyféltekés, rendszerezett, logikus, kritikus gondolkodást. Ha ezt a kettőt nem választjuk szét időben, egyik sem  tud kibontakozni igazán.

Amikor szabályozott kreatív problémamegoldási módszereket használunk,

•          meghatározott fázissorrendben haladunk,
•          megfelelő módszerekkel, eszközökkel felszínre hozzuk a kreativitást (mindkét agyféltekénket használva), és
•          minden szempontot, ötletet, információt felhasználva, bevonva az érintetteket,

sokkal jobb eredményre jutunk.

Sok csoportosan használható módszer áll rendelkezésünkre[1], hogy végigvigyünk egy teljes problémamegoldó folyamatot:

1.        a sok tünetből, probléma halmazból kiválasztani a fókuszt, amivel dolgozunk,
2.        kreatív ötletgenerálást, majd
3.        az ötletek értékelését és a megoldás kiválasztását.

Második javaslat – a résztvevőkről:

A másik tényező, ami nagyban befolyásolja a problémamegoldás folyamatát és a döntéshozatalt, a döntéshozó csoport összetétele és működése. Érdekek, hatalmi harcok, személyes ellentétek zavarják a tisztánlátást, és azt,  hogy arról beszéljünk, ami a valós probléma és optimális megoldása. Ez teljesen természetes emberi dolog, de a  problémamegoldó folyamatot keretek között tartva,  csoportos módszereket szakértő módon használva ez is kiiktatható.

A problémamegoldó módszerek technikái biztosítják, hogy a folyamatban minden résztvevő azonos intenzitással, nyíltsággal járulhat hozzá az okok és megoldás kereséséhez. Hol egy csendben végzendő feladattal, hol névtelen kártyára írt javaslatok begyűjtésével, hol kisebb csoportokban való beszélgetésekkel lehet ezt megoldani. De minden eszköznél fontos egy megfelelő facilitátor, moderátor jelenléte, aki gondoskodik a szabályok betartásáról és a technikák helyes alkalmazásáról.

Az sem mindegy, hogy kiket hívunk be a problémamegoldó folyamatba: szakértőket, stakeholdereket (érintetteket), a projekt célcsoportjának képviselőit, a projektben dolgozó különböző szakmák / szervezeti egységek képviselőit, stb.. Ennek felmérése és a résztvevői kör meghatározása is a facilitátor feladata.

Probléma felmerülésekor hajlamos a projektmenedzser vagy egyedül, vagy egy-két szakembert megkérdezve dönteni a megoldásról, azt feltételezve, hogy így gyorsabb, és a különböző szakemberek úgyis nehezen értenének szót. A csoportos technikák éppen azt segítik, hogy együtt gondolkozva, dolgozva közös nevezőre jussanak a résztvevők, függetlenül szakmájuktól, pozíciójuktól, személyiségüktől.

[1] Kaszás György: Gondolkodjunk, mert vagyunk! (HVG Kiadó, 2011.)

Legegyszerűbb módon a jól ismert három pont köré csoportosítottam a cégvezetők és a projektmenedzserek együttműködési és ütközési felületeit. Van még egy aspektus, ami szinte mindig problémaforrást jelent: a projektmenedzser vezetői autoritása – hogyan kezelik ezt a cégen belül?

1. Mit kell csinálni? Cél, eredmény, terjedelem, minőség....

Az együttműködést javítja, és a konfliktusokat megelőzi:

• Ha a cégvezető bevonja a leendő projektmenedzsert az elvárt eredmény kitalálásába, elviszi a megrendelőhöz, vele egyetértésben vállalja el a megbízást,
• nem fogadnak el kritika nélkül minden – esetleg kivitelezhetetlen vagy értelmetlen – igényt,
• ha a projektmenedzser megérti, hogy a cégvezetésnek fontos a megbízás, a projekt, és javaslatokkal segíti a célok meghatározását, nem csak kritizál vagy ellenáll,
• ha a cégvezető informálja a projektmenedzsert arról, hogyan illeszkedik a projekt a cég stratégiai céljaiba, miért és mennyire fontos, mik az ő elvárásai,
• és a projektmenedzser képviseli ezeket az üzleti szempontokat a team felé.
• Ha a cégvezetés – például az ügyfél kérésére - nem módosítja, nem tágítja menetközben a projekt terjedelmét, nem hozza lehetetlen helyzetbe ezzel a projekt teamet,
• és a team sem módosít egyoldalúan, nem hozza váratlan, kényelmetlen helyzetbe a cégvezetést.
• Ha a cégvezető és a projektmenedzser előre megegyeznek abban, mi az elvárt minőség, és időközben sem a team nem akar ezeroldalú csiszolt gyémántot készíteni (persze plusz idő és pénz árán), sem a cégvezetés nem akar szakmailag alacsony szintű eredményt ráerőltetni a teamre (spórolás céljából).
• Ha a cégvezetés megérti tudomásul veszi, hogy a projekt kockázatosabb, mint a rutin operatív működés – a költség- és időtervek becslésen alapulnak, lehet, hogy nem úgy, lehet, hogy nem akkorra, sőt, - innovációs projekteknél - lehet, hogy egyáltalán nem sikerül! Ugyanakkor a projektmenedzser profi módon felméri és kezeli a kockázatokat, hogy a céget ne hozza nehéz helyzetbe, ne okozzon fölösleges költségeket.

2. Mennyi idő alatt kell megcsinálni? Időterv, csúszás, gyorsítás...

Az együttműködést javítja, és a konfliktusokat megelőzi:

• ha az ügyvezető és a projektmenedzser egyezteti a projekt időtervét, hogy az harmóniában legyen az üzleti tervekkel,
• ha a projektmenedzser a lehető legjobb becsléssel, gondos tervezéssel határozza meg a szükséges időt és erőforrásokat, ezt őszintén megbeszéli az ügyvezetővel,
• ha a tervben történő változásokat mindketten előre jelzik, vagy váratlan esemény kapcsán azonnal közlik a másikkal.
• Ha az ügyvezető megérti, hogy a csúszás – bizonyos mértékben – következik a projektmunka jellegéből (ismeretlen terület, új megoldások – becsült idők),
• a projektmenedzser viszont mindent megtesz a csúszás elkerüléséért, mert érti, hogy a cég számára mit jelent a későbbi befejezés, a plusz költségek,
• és tisztában van vele, hogy bizonyos mértékű csúszás után a cég érdeke úgy diktálhatja, hogy a projektet leállítják, befejezik.
• Ha az ügyvezető nem gyakorol túlzott nyomást a gyorsítás érdekében, mert az a minőség rovására mehet, vagy egyszerűen technológiai okokból nem lehetséges,
• cserébe viszont a projektmenedzser csak indokolt időtartamot ad a szakmai munkára, és ezt alátámasztja szakmai érvekkel az ügyvezető számára.

3. Mibe kerül? Költségek, erőforrások és hasznok...

Az együttműködést javítja, és a konfliktusokat megelőzi:

• ha a projektmenedzser gondosan tervezi mind a változó, mind a fix költségeit a projektnek, tudatában van annak, hogy az emberek bérköltsége, az infrastruktúra használata akkor is költség, ha éppen „semmi nem történik” a projektben,
• ha az ügyvezető és a projektmenedzser együtt határozzák meg a költségkeretet, a projektmenedzser alátámasztott gondos tervei alapján,
• és az ügyvezető sem húz belőle nyomós indok nélkül...
• Ha a projektmenedzser megtesz mindent, hogy számszerűsítse a projekt várható hasznát, segítve ezzel az ügyvezetőt a költség/haszon tényező mérlegelésében.
• Ha az ügyvezető formálisan is kinyilvánítja, hogy az emberi erőforrások melyik részét, milyen arányban, mikor dedikálja a projekthez.

Mi kell még ahhoz, hogy a projektmunka szervesen illeszkedjen a cég működésébe?

Egy fontos kérdés: a projektmenedzser vezetővé válik a projekt időtartamára, tehát úgy is kell kezelni. A projektben komoly szűk keresztmetszetté, hátráltató tényezővé válik, ha minden egyes aláírást, döntést csak az ügyvezető tehet meg, ha nélküle senki egy lépést sem tehet. A projektmenedzsernek igazi autoritást, hatáskört kell adni a projektben, a vezetői csapat tagjának kell tekinteni, és persze ezzel a felelősséget is átruházni rá.

Ehhez az szükséges, hogy az ügyvezető/cégvezetés:

• olyan embert válasszon projektmenedzsernek, akit nem szakmai, hanem vezetői készségei tesznek erre a szerepre alkalmassá,
• a projektmenedzsert képeztesse,
• a projekt keretein belüli hatáskörét, felelősségét, döntési jogosítványait mindenki számára transzparenssé tegye (legitimitás),
• megossza vele a cég hosszútávú terveit, hogy értse a projekt jelentőségét abban,
• bizalmat adjon neki, de pontosan közölje vele a cégvezetés elvárásait.

A projektmenedzsernek viszont:

• értenie kell a projekt helyét a szervezetben, az üzleti tervekben, a cégvezetés hosszútávú szempontjait (amik ellene hathatnak a projekt céljainak),
• és ezek figyelembe vételével meg kell tanulnia a projekt (team) érdekeit képviselni, erőforrásokért harcolni,
• ki kell érdemelnie a bizalmat, hatáskört – megbízhatósággal, folyamatos őszinte, nyílt kommunikációval,
• vezetőként kell viselkednie (példamutatás).

Az előző posztban írtam arról, hogy juthatunk el oda, hogy összegyűjtsük a teendőket, amelyek elvezetnek a projekt eredményéhez. Természetesen, ha valaki már sok projektet megtervezett, az ott leírt első lépés (mind map) kihagyható.

Az elmetérképre felírt teendőket most átírhatjuk egy listára – lehet ez egy egyelőre kockás papír, Excel tábla vagy egy egyszerű projekttervező szoftver. Jó, ha a projektünket al-projektekre bontjuk, vagyis az összefüggő teendőket összerendezzük.

• Az előző példánál maradva: külön al-projekt a helyszín, egy másik az előadók, egy harmadik a személyzet biztosítása, és így tovább. Ennek akkor lesz jelentősége, amikor felelősöket akarunk hozzárendelni a feladatokhoz: jó, ha egy al-projektet felügyel valaki, mert ő látja az egymás után következő lépéseket és a közöttük lévő függőségeket.

Gyakorlottabbak tudják már rögtön időrendben írni a feladatokat, de az sem baj, ha nem sikerül elsőre – amikor meghatározzuk a közöttük lévő függőségeket, úgyis kiderül, ha valamit rossz helyre tettünk. Itt már könnyíthet a dolgunkon, ha Excelben, de még inkább, ha projekttervezőben gyűjtöttük a feladatokat: ezekben sokkal egyszerűbb cserélgetni a helyüket, mint kockás papíron.

A következő lépés a feladatok adatainak kitöltése: időtartam, felelős, melyik másik feladattal függ össze.

• Nagyon fontos az időtartam jó meghatározása: ha alultervezzük, nem lehet az adott feladatot annyi idő alatt elvégezni, akkor csúszás lesz, és ez veszélyeztetheti a projekt sikerét. Ha a szükségesnél több időt hagyunk a feladatra, a végén kell majd megfeszülni, hogy elérjük a végső határidőt. Ehhez már kell egy kis tapasztalat, ismeret: pl. jó, ha valaki tudja, mennyi idő keresni egy jó rendezvény helyszínt, hánynak a megnézését lehet bevállalni, ez mennyi időt igényel, hány nap egy bérleti szerződés letárgyalása és megkötése, stb..
• Az összefüggés a feladatok között többféle lehet. Ezek között a legfontosabb, ha az egyik feladat eredménye (kimenete, „output”-ja) szükséges a másik feladat elkezdéséhez. Az ilyen feladat-sorozatok fogják meghatározni a projekt hosszát (kritikus út). Példánknál maradva: amíg nem szerződtünk le a kiválasztott helyszínnel, addig nem tudjuk megírni a meghívókat a résztvevőknek. Amíg nincsenek meg az előadóink, addig nem tudjuk a végleges programot közzétenni. De lehet olyan összefüggés is, hogy bizonyos feladatok csak egyszerre tudnak kezdődni (ugyanaz a kezdeti feltétel, „input” kell hozzájuk). Például amíg nincsenek meg az előadóink, nemcsak a program nem végleges, hanem azt sem tudjuk megmondani a helyszínnek, hogy milyen technikát igényelnek az előadók. Fordítva is igaz: van feladat, amihez több input szükséges: pl. a meghívók megírásához nem csak a helyszín, hanem a vendégek elérhetősége, címe is kell.
• Az al-projektért vagy egy feladatért felelős nem azt jelenti, hogy a megjelölt személynek egyedül kell végeznie az adott tevékenységet. Bevonhat, dolgoztathat másokat is, de ő a felelős azért, hogy az adott feladat eredménye megszülessen – és ezért mindent meg kell tennie. Komplex, többszereplős feladatoknál érdemes RACI mátrixot  használni, amiben rögzítjük, kinek milyen rész-feladat jutott.

Az időterv „összeállása” általában iteratív folyamat: előrefelé és hátrafelé is kell tervezni. Előrefelé: minden feladatnak adunk szükséges időt – ha ez a végén túlcsúszik a rögzített végső határidőn, akkor elkezdjük visszafelé nézni: min lehet rövidíteni? Így jutunk lépésről lépésre közelebb egy konzisztens időtervhez. Excel-ben így néz ki egy időterv (egyelőre felelősök nélkül).

Ez az iteráció láthatóvá teszi a legfontosabb projekttervezési szempontot: ahány teendőt csak lehet, párhuzamosra kell tervezni! A legtöbb, tervezés nélküli folyamat ezért szokott elbukni: azokkal a teendőkkel is megvárják a többit, amit lehetett volna párhuzamosan csinálni. Nem gondolkoznak több lépéssel előre, mindig csak a következő feladatban – és későn derül ki, hogy azt már régen el lehetett volna kezdeni! És a projekt nyúlik, mint a rétestészta.

A finomhangolásról a következő posztban.

Azt hiszem, már írtam arról, hogy a menedzsment szempontjából a projekt legfontosabb része a tervezés. Jó terv = 80% siker. Arról is írtam, hogy nem kell szofisztikált projekttervező szoftver, főleg, ha egy kis vállalkozásnak kisebb, nem túl komplex projektjei vannak. De a legkisebb projekthez is kell egy alap, egy terv.

De addig, amíg eljutunk oda, hogy begépeljük egy dokumentumba a tervet, lényeges dolgokat kell tennünk. Csak tapasztalt projektmenedzser tudja egyből a tervet a gépbe vinni.

Fogjunk sok színes filctollat és egy nagy üres papírt, írjuk fel a közepére egy dobozba a projekt termékét, eredményét - ezt hívják leszállítandónak, ami nagyon szemléletes kifejezés, mert ez a valami, kézzelfogható, ami megszületik a projekt végén. Például: „vevőtalálkozó", „weboldal". Képzeljük el a terméket kész állapotban milyen lesz, mi minden kell hozzá, milyen részekből áll. Kezdjük el szétszedni ezekre a részekre és ezeket a részeket egy-egy szóval írjuk fel egy-egy vonalra, ami a terméket tartalmazó dobozból ágazik el. Például a „vevőtalálkozó" részei lehetnek: „helyszín", „személyzet", „ellátmány", „vendégek", „program", „ajándékok". A „weboldal" részei lehetnek a „tárhely", „sablon", „design", „funkciók", „szerkezet", „tartalom", stb..

A vonalakból újabb ágakat rajzolhatunk: a „helyszín" ágai lehetnek pl. „terem", „technikai eszközök", „dekoráció", a „személyzet" felbontható: „hostessek", „előadók", „cégünk munkatársai", „videós", „fotós", stb.. Mindenki, aki ott dolgozni fog. Lesznek olyan ágak, amiket nem lehet tovább bontani, pl. az „ajándékok".

Fontos, hogy az így kapott részek listája teljes legyen! Ha ebben a fázisban mindenre gondolunk, amire szükségünk van a sikeres termékhez, akkor nagy baj már nem lehet.

A részek ágaiból most más szempont szerint húzunk újabb faágakat: milyen lépéseket kell tenni ahhoz, hogy biztosítsuk őket. Például a „terem" biztosításához meg kell néznünk többet, ajánlatot kell kérnünk, ki kell választanunk, le kell foglalnunk, meg kell mondanunk, hogyan rendezzék be, stb.. A „vendégek" biztosításához össze kell állítanunk vevőink listáját, ki kell választani a meghívottakat, ki kell küldeni nekik a meghívókat, fel kell hívni őket, hogy jönnek-e, stb... Ezek a teendők egy-egy kis ágacskát kapnak megint. Itt még nem kell törődnünk azzal, hogy ezek milyen sorrendben logikusak, csak írjuk, hagyjuk, hogy minden eszünkbe jusson. Ezt minden szálra el kell végeznünk.

Jó, ha az ágacskákat és rajtuk a feliratot (ami mindig csak egy-két szó!!!) különböző színekkel rajzoljuk, írjuk, mert így jobb agyféltekénket is dolgoztatjuk, és több minden eszünkbe fog jutni.

Ezekből a teendő-ágacskákból lesznek a projekt feladatai.

Nézzünk rá a pókhoz hasonló ábránkra (ami egy elmetérkép, vagyis mind map): keressük meg, vannak-e olyan termékrészek , amik összefüggenek valahogy? Vegyünk egy olyan színest, amit még nem használtuk, és kössük össze őket, hullámos, pontozott vagy más nem sima vonallal. Ha az egyik befolyásolja a másikat, használjunk nyilat az összekötésükre. Például a „terem" adottságai meghatározzák a lehetséges „dekoráció"-t, akkor húzzunk egy nyilat a „terem"-től a „dekoráció" felé. Ugyanígy keressük meg az összefüggéseket a teendők között. Például a „terem lefoglalása" után tudjuk „meghívni a vendégeket".

Most, hogy megvannak a projekt feladatai, és a közöttük lévő összefüggések is, kezdhetjük átalakítani ezeket az információkat projekt tervvé. A következő posztban.

Ha team tagjaid nem veled együtt, az irodában dolgoznak:

• Először is: légy tudatos afelől, miben más a virtuális team, és ennek mi a hatása. Milyen más vezetői stílust, eszközöket igényel tőled.
• Egyenként beszélgess  Skype-on minden team taggal, rendszeresen, állandó időben (tervezhető).
• Hozz létre csevegőszobát (chat room) - úgy működtesd, mint egy irodát: amikor bejövünk, bejelentkezünk, köszönünk, kérdezünk, ötleteket osztunk meg. Ebben mutass példát: vegyél részt, és másokat is bátoríts erre.
• E-mail helyett telefonálj: lehet, hogy kevésbé hatékonynak tűnik, de spontánabb, jobban megismered a személyt, a metakommunikációból plusz infót vehetsz le.
• Légy tisztában vele, hol élnek a team tagok – kis dolgok: pl. milyen idő van (meleg?), meccs van, amire az egész város figyel, stb...
• Vidd át a céges kultúrát pl. ha az irodában megbeszélések közben kávéztok, bátorítsd őket is, ha a ház elől, cigizés közben hívod, küldjetek egymásnak fotókat közben erről...
• Amikor csak teheted, menj oda.
• Küszöböld ki a legtöbb mikromenedzselést: legyenek előre megadott világos elvek, szabályok, formák pl. beszámolóra, időtáblára, stb. – ilyeneket ne kérdezgessenek, mert széttöredezik a napod, nem hatékony!
• Ünnepeljétek meg a mérföldköveket – alkalom motivációra és célratartásra.
• Biztosíts lehetőséget spontán ötletelésre – gyakran ezekből lesznek a legjobb megoldások.
• Legyél pro-aktív! Nem igaz, hogy a „no news = good news”. Kérdezz rá, mindenkinél, egyenként,  a múlt heti aktivitásra, eredményekre, az e heti prioritásokra, lehetséges akadályokra, kockázatokra. Ne várd meg, amíg belefutnak, és utólag szólnak róla. Előre azonosítsátok a kockázatokat, és előre legyen rá megoldási stratégia!
• Rendszeresen definiáld / erősítsd meg a célt, prioritásokat, időkereteket, sikertényezőket! Ne gondold, hogy ha egyszer megbeszéltétek, vagy körbeküldted, attól még szem előtt tartják.
• Tölts annyi időt a megismerésükkel, mintha helyben lenne az alkalmazottad. Értsd meg az igényeiket és a korlátaikat is!
• Igyekezz minél jobban megismerni a team tagok egyediségét – hogy ki tudd használni az egymást kiegészítő adottságokat, testre szabottan tudj feladatot kiosztani, stb.
• Rendszeresen kérj visszajelzést saját munkádra!
• Legyen közös szervező, (felület), hogy a tagok ne csak sajátjaikat, hanem az összes feladatot, előrehaladást lássák.
• Tuti biztosan szinkronizálva legyenek a közös file-ok!
• Precízen határold el a feladatokat:  távoli teamtagokkal nehezebben derül ki a párhuzamosság, vagy, ha valamit senki nem csinál.
• Mindenkivel tarts kapcsolatot, és/vagy nevezz ki mentort valaki mellé. Személyes kapcsolata legyen mindenkinek a teammel.

Image courtesy of maen_cg at FreeDigitalPhotos.net

Alapok:

• Tiszta struktúrára: a vízió, küldetés, célok tisztázására. A különböző helyszíneken dolgozó team tagok eltérő információkkal rendelkeznek, eltérő kontextusban értelmezik az információkat – ebből félreértések keletkeznek.
• Összhang teremtésére: a  mindennapi viselkedés, együttműködés módjának szabályozására.
• Érzelmi kapcsolatokra: közös feladat átélésére, a részvétellel való személyes azonosulásra, a siker érzelmi mozgató erejére.  Amikor távol vannak a vezetőtől, azt fogják tenni, ami nekik fontos, amik személyes prioritásaikból keletkeznek – ezért személyes prioritássá kell tenni a közös célokat.
• Az egyenlőség érvényesítésére: a vezető dolga azt biztosítani, hogy a vele egy helyszínen dolgozók ne legyenek előnyben a döntési folyamatokban, az elismerésben, a vezetővel való személyes kapcsolatban. A távoli csoporttagok számára különösen fontosak a vezetőtől kapott személyes üzenetek, a munkához való hozzájárulásuk elismerése, minél több személyes találkozás, ötleteik, javaslataik figyelembe vétele, fontosságuk, a csoporthoz tartozásuk tudatának erősítése.

Mit várnak el a projekt menedzsertől a virtuális teamek tagjai?

• Folyamatos, rendszeres kommunikációt – egyedileg, személyesen mindenkivel.
• Elérhetőséget, gyors válaszokat.
• Precíz, írásos, részletes feladatkiosztást (úgy kell összeállítani, hogy ha nem vagy elérhető, a legtöbb kérdésükre találjanak benne választ).
• Részletes agendát a megbeszélésekre.
• Telefonos vagy videó megbeszélés közben időközönként összefoglalást, hol tartotok, miről született eddig döntés, stb.
• Lehetőséget közös aktivitásokra (a magányt enyhítendő), pl. csevegő szoba, lehetőség személyes találkozókra.
• Bizalmat, minél kevesebb mikromenedzselést.
• Egyensúlyt a technikai és az interperszonális készségek között (prioritás: interperszonális készségek).
• Megbízhatóságot, ígéretek megtartását, saját PM feladatainak elvégzését.
• Folyamatos információadást, rész-információkat is.

Hogyan kommunikálj, ha virtuális teamet vezetsz?

• Legyen teljesen világos a cél, időterv és felelősség. Sok csatornán kell tudatni, legyen rajta minden dokumentumon. NEM 10 oldalas projekt dokumentációban – ezt nem olvassák el.
• A felelősség minden leszállítandóért világosan legyen kommunikálva (mindenkié mindenki felé: a stakeholderek lássák a neveket).
• Legyen közös nyelv (céges kódokat használni, vagy, ha nincs: csinálni a projektre).
• Válaszd megfontoltan a kommunikációs eszközt. Egyszerű info-cserére telefont vagy  e-mailt, stratégiai információk átadására, megbeszélésre skype-ot vagy telekonferenciát, fontos vagy rossz közlésére a lehető legszemélyesebb módot.
• Tervezz be rendszeres webes értekezleteket és tartsd is meg őket! Ezeken használjatok olyan hatékony eszközt, ami sok csatornás kommunikációt tesz lehetővé (file küldés, képernyő megosztás, stb..).
• Ne csinálj a projektmenedzsmentből külön projektet: egyszerű, átlátható és kevés dokumentumot használj.
  • Feladatlista (heti), max. 20 tétel, prioritással és felelős megnevezésével.
  • Kockázatok listája, karbantartva, és az első 10-nek legyen felelőse.
  • Heti jelentés – töltelék szöveg nélkül, összesen 3 rovat: „Kész” / „Teendő a héten” / „Heti legfontosabb témák” a Kockázatok listájáról.
• Gyakori kommunikáció! Ne felejtsd el: a team tagok állandóan döntéseket hoznak, a rendelkezésükre álló vagy feltételezett információk alapján. Legyen náluk valós infó! Akkor is, ha csak rész-információ. Ez is több, mint a semmi.

Hogyan motiváld a virtuális team tagjait?

• „Erősítsd a „családot” – pl. ha lehet, mindig máshol legyenek a személyes találkozók. Ismerj meg minden helyszínt, ahol dolgoznak.
• Bátorítsd és oszd meg az ötleteket. Bátorítsd problémamegoldásra a team tagokat – nem kell mindent neked megoldani. Használd ki az előnyét annak, hogy valaki távolról más szemszögből látja – ezt mondd is ki.
• Jutalmazd az újításokat, amik a projekt sikerét,  a hatékonyabb munkát, vagy a kisebb terhelést mozdítják elő.
• Mozdítsd ki a dobozukból a team tagokat: gondolkozzanak az egész projektben.
• Menedzseld a teljesítményt: legyenek jó, ügyfél-orientált mérőszámok, publikusan. Egymást is, és ne csak a mérhető dolgokat értékeljék a teamtagok. Legyen rendszeres visszacsatolás, megfelelő csatornán.

Image courtesy of digitalart at FreeDigitalPhotos.net

Egyre több az olyan projekt, amin földrajzilag nem egy helyen tartózkodó kollégák dolgoznak. Az IT eszközök lehetővé tették, hogy közös ügyeinket  másik irodából, másik városból vagy földrészről, vagy akár egyszerűen csak otthonról  intézzük.

Egy ilyen team vezetése feladja a leckét a projekt menedzsernek. Miért nehezebb, mint egy olyan csapattal bánni, akik egy helyen dolgoznak? Gondold meg,

• mennyivel könnyebben, és ezért gyakrabban osztasz meg információt azzal, akivel egy szobában ülsz, vagy naponta összefutsz a folyosón,
• hányszor születik meg egy probléma megoldása, vagy egy döntés kávézás vagy ebéd közben,
• egy „ad hoc”, de személyes beszélgetés közben, egymást inspirálva,  mennyi ötlet bukkan fel,
• van egy közös alapotok, közérzetetek azáltal, hogy egy szobában ültök: te is érzed, ha front van, ha el vagytok havazva, vagy történt valami a környezetetekben, ami hat rátok,
• azonos szervezeti kultúrában éltek: normáitok, írott és íratlan szabályaitok, eljárásaitok közösek,
• tudtok egymás – munkát is befolyásoló - bánatáról, nehézségeiről, öröméről ,
• egymás, és a projekt menedzser „szeme előtt” vagytok, így a teljesítmény látható, kontrollálható,
• hamarabb kiderül, ha baj van, elakadt a projekt valahol,
• mennyivel szívesebben kérdezel vagy kérsz segítséget attól, akit személyesen ismersz,
• mennyivel hatékonyabb az azonos idejű, kétirányú kommunikáció: látod, hogy partnered érti-e, amit mondasz, az ő befogadókészségéhez tudod igazítani a mondandódat, vagyis azonnal visszajelzést kapsz,
• mennyivel árnyaltabban fogalmazol, amikor valakivel személyesen, szemtől-szembe kell konfrontálódnod,
• és így tovább....

Ha a team egy része együtt dolgozik, néhányan pedig távolabbról, fellép a „mostohagyerek” szindróma is: magány, kívülállóság, céges kultúrától való leszakadás érzése. Ennek van előnye is:  a távollévők nem vesznek részt a folyosói pletykákban, panaszkodásban. De ugyanakkor kívülállónak érezhetik magukat, sőt, azt érezhetik, hogy őket kiközösítették, vagy nem látják az eredményeiket. Mindig az az érzésük, hogy a projektmenedzser közelében dolgozók  többet tudnak, jobban látszanak. (ami így is van)

A közös munkához alapvetően bizalom szükséges. A személyes ismeretség hiánya, az IT eszközökkel végzett, általában szegényesebb kommunikáció, a távolság okozta kapcsolat-hiány nehezíti a bizalom felépítését. Ugyanakkor, mivel nem látható nap mint nap, hogy a team tagok dolgoznak-e, a dolgok jó irányba haladnak-e, pont erre a bizalomra építhetné a projekt menedzser a befolyását, hatalmát. A vezető ereje ilyenkor a bizalmon alapuló kapcsolat minőségén múlik.  A virtuális team formálisabb, láthatóbb, kevésbé rugalmas  vezetést igényel. Ha az informális vezetés híve vagy, erre külön figyelni kell.

Image courtesy of jscreationzs at FreeDigitalPhotos.net

Ha már van cél, van projekt menedzser, alakul a terv is – akkor kell egy csapat. Amikor összeáll néhány szakember egy projekt megvalósítására, bármennyire szeretné a projekt menedzser, az még nem csapat. Nem tud rögtön magas teljesítményt nyújtani, kihasználni a szinergiákat, egymással kapcsolódva többet nyújtani, mint emberek véletlenszerű halmaza. Sőt, ahogy az emberi kapcsolatok alakulnak, egy időre még vissza is eshet a teljesítménye. A csoport fejlődéséhez idő és befektetett energia kell, hogy a különböző fázisokon keresztülmenjenek. Mik ezek a szakaszok?[1]

Orientációs szakasz (Forming):

A csoport tagjai visszafogottak, tapogatóznak, figyelik egymást, vonakodnak kifejezni nézeteiket, igyekeznek elkerülni a vitát. Bár már rejtett rokon- és ellenszenvi viszonyok kezdenek kialakulni, valódi érzéseiket eltitkolják. Próbálják meghatározni saját helyüket és szerepüket a csoportban. A vezetőtől várnak irányítást, támogatást és rajta keresztül kapcsolódnak egymáshoz is. A kezdeti feszültség csökken, amikor a tagok a szükséges információkat megszerzik és a működésre vonatkozó első megállapodások megkötődnek közöttük.

A projektmenedzser feladata ebben a szakaszban, hogy eligazítást, támogatást nyújtson, teremtsen formális és informális ismerkedési lehetőségeket. Nyílt megbeszéléseken tisztázzák a közös munka kereteit, a célokat, feladatokat, szabályokat („szerződések” kötése).

Polarizáció és belharc (Storming):

Felszínre törnek az első és szinte mindig negatív személyes érzelmek, olyan ellentétek merülnek fel, amelyek lappangva már korábban léteztek. Gyakran két pólus alakul ki. Folytatódik a helyzet többé vagy kevésbé burkolt definiálása és harc alakulhat ki a szerepek körül. Lehetséges, hogy hatalmi harc folyik a vezetésért, miközben bírálják a csoportvezető tevékenységét, a fennálló kereteket, körülményeket és az eljárást. Sokszor először a formális vezető ellenében jön létre egység. Ezek a konfliktusok természetes és szükségszerű velejárói a csoportfejlődésnek, lehetővé teszik a kölcsönös megismerést. Valójában egy alkudozási folyamatot látunk a csoportban, amely az összehangolódásért és a jövőbeni együttműködésért történik. Ebben a szakaszban a teljesítmény időlegesen csökken.

A projektmenedzsernek ilyenkor az a dolga, hogy segítse az értékek és igények nyílt kifejeződését, tisztázást, problémamegoldást, lehetőséget adjon mindenkinek a megszólalásra, és vegye komolyan azokat. Nem szabad versenyeztetni a csapattagokat, kivételezni. Legfontosabb, hogy hitelesen viselkedjen.

Konszolidációs fázis (Norming):

A csoport a belső egyensúlyát keresi, a résztvevők aktivitása fokozódik, egyre több személyes jelentőségű információt juttatnak kifejezésre, lassan nő a bizalom. A csoport meghatározza saját feladatait, céljait, szokásokat és normákat alapoznak meg, kidolgozzák munkamódszerüket. A kényes problémákkal szembenéznek és foglalkoznak vele, kialakul az elkötelezettség a célok, az eljárások és a többi csoporttag irányába.

A projektmenedzsernek ebben a szakaszban nyílt légkört kell teremtenie, segítenie a normák kialakulását, méghozzá úgy, hogy saját értékrendjét határozottan képviseli. Mivel egyre inkább a feladatmegoldás kerül előtérbe, ehhez biztosítania kell az információkat és az erőforrásokat. Jó, ha támogatja az önálló törekvéseket.

Munka vagy produktív fázis (Performing):

A csoport már jól kezeli a problémákat, megbecsülik és célszerűen használják az egyéni erőforrásokat. Bizonyos feladatokban megosztják a vezetői funkciókat, egyformán figyelnek a feladatteljesítésre és a kapcsolatok ápolására. Kialakul a csoportidentitás, a "mi-tudat", a csoport sikeres társas egységgé vált, és képes önszabályozással fenntartani önmagát, és a fejlesztő külső hatásokat felerősítve önmagába beépíteni. Igazi hatékony munkavégzés ebben a fázisban várható.

A projektmenedzser feladata, hogy biztosítsa a munkavégzés feltételeit, támogassa az egyének fejlődését, gondoskodjon az értékek érvényesítéséről, a közös rituálék fenntartásáról, a sikerek megünnepléséről. Ebben a fázisban lehet a vezetői szerepet megosztani, bizonyos feladatokat delegálni.

 Befejező vagy terminális szakasz: 

Ha a csapat felbomlik a projekt végeztével, gyászreakcióhoz hasonló hatások érik a tagokat. Sokan ekkor látják át  a csoport fejlődését és teljesítményét, így a csoport - akár visszamenőleg is - felértékelődik. Ilyenkor fontos (lenne), hogy a csoporttagok kiértékeljék tapasztalataikat, áttekintsék a megtett utat, összefoglalják a következtetéseket, és megbeszéljék azt is, hogy a csoportban tanultakat hogyan tudják alkalmazni, mikor egyedül és más keretek között lesznek. Sajnos, ez sokszor nem történik meg.

A projektvezetőnek formálisan is le kell zárnia a projektet,  bejelenteni – akár egy „búcsúszertartás” keretében - a csoport felbomlását, elismerni a csoportot és visszajelzést kérni saját szerepére.

Ezek a folyamatok akkor is végbemennek, ha nem tudatosulnak a vezetőben és a tagokban. Mivel a projekt határidőre kell, hogy eredményt produkáljon, jó, ha a projektmenedzser tudatosan figyel arra, hol tart a csoport, és megfelelő viselkedéssel támogatja, gyorsítja a folyamatot – hogy minél előbb a produktív fázisba érjenek.

Már írtam a projekt menedzserről, ideje megnézni, ki is ez a kulcsszereplő, és mit csinál?

 Ahány vállalat, annyi szokás, annyi megnevezés. A projektek koordinálási gyakorlatában többféle szerepfelfogás  létezik, és bármelyiket hívhatják – vállalati kultúrától, szabályoktól, eljárásoktól függően - projekt menedzsernek.

• Van, aki tulajdonképpen  projekt adminisztrátor, vagyis minden fázisban elkészíti a szükséges dokumentációkat, esetleg jelez, ha valamit kell csinálni, időpontokat egyeztet, stb., vagyis olyan adminisztratív feladatokat hajt végre, amihez nem kell különösebb PM képzettség és tudás.
• Van, akinek lehet, hogy képzettsége is van, de  csak projekt monitorként működik, vagyis ellenőrzi, hogy mit történik a tervhez képest, koordinál, áramoltatja az információkat, részt vesz az egyeztetéseken, stb..
• Sok helyen  a projekt menedzser IPMA, PMI, vagy egyéb képzettséggel rendelkezik, gyakorlata van PM szoftverek és a vállalati PM rendszer ahsználatában, és főleg ezekre támaszkodva menedzserként működik, vagyis tervez, szervez, ellenőriz, kifelé képviseli a projektet, stb..
• És van, aki elnevezésétől függetlenül,  vezeti a projektet, vagyis irányt mutat, hosszútávon tervez és gondolkodik, motivál, inspirál, csapatot épít, stb..

Egy cikk szerint, ha megkérdeznének valakit, hogy kiket tart  sikeres, eredményes projekt menedzsernek, és azokra mi jellemző, ilyesmiket mondana:

• Vezetői hozzáállás, viselkedés és készségek
• Jó kommunikációs készségek
• Állhatatosság
• Fókuszáltság
• Motiváció
• Inspirálás
• Cselekvő
• Energikus

Ezek pedig nem azok a szempontok, amiket értékelnek a PM-ek működésekor – főleg nagyvállalatoknál: módszertani ismeretek, eljárások ismerete, projektterv készítés, beszámolók készítése, értekezletek vezetése, szoftver alkalmazások... Ugye?

A szakmában, szakirodalomban is, a projektek sikertényezői közül ma már egyértelműen a projektmenedzser vezetői készségeit tartják fontosnak:

• kommunikációs készség
• eredményorientáltság
• feladatkiosztás és delegálás
• rendszerszemlélet
• információmenedzselés
• konfliktuskezelés
• ügyfélközpontúság
• bizalomépítés
• csapatépítés
• stratégiai gondolkodás

Egy másik cikk szerint mindenképpen projektvezető szükséges, ha:

• a projekt új területekre merészkedik (nem a 20. szoftverfejlesztés, amit sztenderd folyamatként már begyakoroltak), tehát az innovatív szemlélet, kreativitás, kockázatvállalás,  vízió fontosabbak, mint a szakmai-technikai ismeretek,
• a csapatban erős egyéniségek vannak, és konfliktusok várhatóak, legalábbis külön erőfeszítés lesz együttműködésre bírni őket,
• a csapatban sok különböző szakma képviselői vannak (interdiszciplináris), és elő kell segíteni a köztük zajló kommunikációt, megértést, kompromisszumkeresést,
•  a projekt szoros keretek között (pl. hatósági előírások) kell, hogy működjön, szűk tűréshatár van a határidőkre, minőségre, vagyis várhatóan kreativitásra, új megoldásokra, gyors reagálásokra, döntésekre lesz szükség.

Vállalkozóként tehát az első lépés annak meghatározása, milyen projekt indul, ahhoz milyen vezetés szükséges - és ehhez a szerephez kell keresni a megfelelő embert.

Image courtesy of digitalart at FreeDigitalPhotos.net

Honnan veszed észre, hogy a cégednél valami baj van a projektmunkával?

Az embereid nem tudnak világos választ adni, ha megkérdezed őket, hogy

• mi a projekt célja, és miért lesz ez jó a cégnek,
• mi a feladatuk pontosan a projektben,
• mit kell letenniük az asztalra és mikorra,
• kivel kell együtt dolgozniuk saját feladatuk során,
• ki fog dolgozni az általuk letett eredményből, és neki milyen igényeik vannak ezzel kapcsolatban,
• kit kell megkérdezniük, ha döntésre van szükségük,
• milyen döntések születtek a legutóbbi értekezleten, és miért,
• ki milyen feladatot kapott a legutóbbi értekezleten,
• milyen kritikus folyamatok vannak a projektben, és az ő munkájuk hogyan kapcsolódik ezekhez,
• hol tart most a projekt, tartják-e az időtervet, vagy meg kell egy kicsit hajtani, mert csúszás van.

Te, a vállalkozás vezetője nem tudod,

• pontosan mit fogsz kapni a projekt végén,
• mikorra várható az eredmény, illetve mikor vannak a főbb mérföldkövek (részeredmények),
• az eredeti tervhez képest hogyan áll a teljesítés időben és költségekben,
• várható-e idő és/vagy költség túllépés,
• milyen kritikus folyamatok határozzák meg a végeredményt, és ezek hogy állnak,
• milyen kockázatok láthatók előre, és mit tettek a megelőzésükre, kivédésükre,
• kihez kell fordulnod, hogy mindezekre választ kapj.

Jelenségek, amiket tapasztaltok:

• a vezetők és a projekt vezetője idegesen futkos, és azt hajtogatja, hogy a projektnek márpedig mennie kell,
• az értekezletek hosszúak, strukturálatlanok, és utólag nem tudjátok visszaidézni, mi volt a lényeg,
• projekt közben derülnek ki újabb és újabb feladatok, döntési pontok, költségek,
• újra kell csinálni valamit, mert nem volt jól definiálva a feladat, és nem az készült el, amit használni is lehetne,
• az emberek egymásra mutogatnak, ha arról van szó, mi kinek a dolga,
• az emberek egymásra mutogatnak, amikor arról van szó, hogy most éppen hol tart a projekt és miért van csúszás, vagy állás,
• az emberek arra hivatkozva nem végzik a dolgukat, hogy
  • nem született döntés,
  • nincsenek felhatalmazva valaminek az elvégzésére,
  • valakire / valamire várnak,
• az emberek személyeskednek, vagy szakmainak álcázott konfliktusokba bonyolódnak,
• az emberek ellenkeznek, vagy kihátrálnak, ha projektbe akarják bevonni őket.

Amikor a „projektalapú gondolkodásról"  írtam, ígértem, hogy bővebben fogok írni a kulcs szereplőről: a projekt menedzserről (továbbiakban PM). Kis vállalkozásnál a jó PM kiválasztása kulcsfontosságú a projekt sikeres befejezése szempontjából. Ez a téma több posztot is megér, kezdjük az alapokkal.

Személyes véleményem és tapasztalatom szerint a jó PM sikerét 20%-ban a technikai készségek („hard skills"), 80%-ban az emberi, személyes kompetenciák („soft skills") biztosítják. Ami előzőt illeti, természetes, hogy tudnia kell kezelni a tervezés, ellenőrzés, szervezés eszközeit, folyamatait – erre most több szót nem is vesztegetnék. Az előző posztban írtam róla, hogy a lehető legegyszerűbb eszközöket kell használni, amit mindenki könnyen tud kezelni.

Frappáns megfogalmazást és összegzést találtam egy blogban: a PM az ellentmondások mestere.

Én inkább azt mondanám, hogy az egyensúlyozás mestere: az ellentétek két pólusát önmagában egybeolvasztva kell megtalálnia mindig a legjobb viselkedést.

Elég magabiztosnak kell lennie ahhoz, hogy mind a megbízók, mind a team tagok higgyenek a sikerben, ugyanakkor legyen benne vezetői alázat, hogy a siker nagy részét a teamnek tulajdonítsa. Tudjon feladatot kiadni, megvédeni az álláspontját, kiállni a projektért és a csapatért, de tudjon –a szó legjobb értelmében – szolgálatára lenni bárkinek, akinek a munkájához erre szüksége van. Mint a curlingben a söprögető... 

Egyszerre vezető és menedzser – hosszútávú célokat, irányt mutat, ugyanakkor hatékonyan szervezi a konkrét lépéseket. Vagyis rendelkeznie kell mindkét szerephez szükséges készségekkel. Általában a menedzseri készségekkel nincs hiba, mert egy jól szervező, koordináló munkatársat szoktak kinevezni PM-nek. Ugyanilyen fontos azonban, hogy a PM olyan valaki legyen, akit követnek, és nem azért, mert formális címe-rangja van...

Kezelnie kell tudni a projektek komplexitását, ezzel egy időben a dolgokat minél világosabban kell láttatnia és a folyamatokat minél egyszerűbbé tennie. Mind a team tagoknak, mind az érintetteknek elegendő információval kell rendelkezniük, azonban számukra érthető formában: nem szükséges a komplexitással terhelni őket, de érteniük kell, mi miért történik. A munkafolyamatok, illetve összefüggéseik maguktól is bonyolultak lehetnek, jó, ha a PM nem visz bele plusz köröket, pl. felesleges adminisztratív előírásokkal.

Szerintem az egyik legnehezebben teljesíthető kívánalom: a PM-nek egyszerre kell stratégiai gondolkodónak lennie, nagyban látni az egész projektet és környezetét („helicopter view"), ugyanakkor otthon lenni a részletekben, a napi feladatokban. Minden egyes döntését úgy kell meghoznia, hogy figyelembe veszi a hosszútávú és az azonnali hatásokat is. A hosszútávú célok képviselete biztosan olyan dolog, amit senki másra nem bízhat, nem delegálhat – a teamtagok óhatatlanul saját szempontjaik szerint preferálnak egy-egy megoldást. Ugyanakkor könnyen tévútra vezet, ha a PM nem érti a napi munka problémáit, rosszul méri fel azok jelentőségét, vagy hatását. Én ez utóbbi szempont miatt szoktam amellett kiállni, hogy a PM-nek igenis értenie kell bizonyos mértékig a szakmákhoz, amiket koordinál.

A projektnek tartani kell a határidőket, ugyanakkor kiváló minőségben kell szolgáltatnia a végeredményt. Ehhez a PM-nek türelmetlennek kell lennie, néha „hajtania" a többieket, néha pedig türelmesen kivárnia, amíg a precíz munka minőséget produkál, amíg alaposan körbejárnak egy problémát, krízishelyzetet, vagy amíg „összeérnek" a csoport tagjai, kialakul a bizalom és az együttműködés.

A „stakeholder” helyett nem tudok olyan magyar kifejezést, ami teljesen kifejezné ugyanazt a jelentést. Talán ezért is, a magyar projektmenedzserek és szakirodalom is ezt használja. Ebben az írásban „érintettek”-ként fogom emlegetni őket.

„Stakeholder”, vagyis érintett  alatt én mindenkire gondolok, akit érdekel vagy érint a projekt eredménye és/vagy folyamata, illetve akikre szükség van a projekt sikeréhez. Projektmenedzserek jól tudják, hogy a siker mennyire nem csak a csapat tagjaitól függ. Mind az előrevivő erőkbe, mind a kockázatokba be kell számítani mindazokat, akik tehetnek a projekt sikeréért vagy ellene. Ezért a projektmenedzser feladatai közé tartozik a érintettek kezelése – ennek első lépése, hogy felismerjük, a könnyebb kezelés érdekében pedig csoportokba soroljuk őket.

A projekt folyamata során érintettek és az eredményben érdekeltek

Az, hogy ki érdekelt a projekt eredményében, könnyen megállapítható: aki az eredményt használni fogja, mindenki, akinek változást hoz az életébe, és mindenki, aki  a projektben dolgozik érte. Ugyanakkor vannak, akiket nem érint a végeredmény, de akikkel a projekt folyamata során érintkezésbe kerülünk, életükre kisebb-nagyobb hatással vagyunk. Elsőre lehet, hogy úgy tűnik, velük nem kell különösebben törődnünk, de ez nem így van.

Tegyük fel, hogy kis átalakítást tervezünk az üzletünk bejáratánál, vagy például klímaberendezést szereltetünk fel a  falára. Mivel a ház küllemét érinti a dolog, természetesen bevonjuk a házban lakókat, megmutatjuk nekik a terveket, beleegyezésüket kérjük az eredményhez. De érintett lehet a szomszéd ház lakója is, akinek időlegesen el kell viselnie a zajt, esetleg az utcán gyűlő építési anyagokat, vagy éppen az ő háza elé is parkoló szállító autókat. A saját érdekünkben jobb, ha előre beavatjuk abba, ami készül, még akkor is, ha a végeredményhez nincs köze, és előre azt sem tudjuk pontosan, milyen mértékben érinti majd a projekt.

Lehet, hogy egy IT projektet indítunk, melynek eredménye az, hogy a cég egy  csoportja egy új alkalmazást fog használni, tehát az eredmény közvetlenül őket érinti majd. De az a tárgyaló, amiben a projekt értekezleteket fogjuk tartani, egy másik csoport folyosóján található – náluk a következő hetekben egy kicsit több lesz a jövés-menés, a konyhájukban nagyobb lesz a forgalom. Biztosan jobb, ha előre jelezzük nekik, és nem tekintjük úgy, hogy „nincs közük hozzá”, mert a tárgyaló és a konyha is tulajdonképpen a cégé, és jogunk van igénybe venni.

Gondoljuk végig,

• kik érdekeltek a projekt végeredményében, és
• kiket érint majd a projekt, munka közben.

A kis család és a távoli rokonok

Vannak az érintettek között, akik olyanok, mint szűkebb családunk: szeretnek mindenről tudni, ami történik, előre felkészülni vagy akár részt is venni az eseményekben.  Őket – akárcsak családtagjainkat  – jól kell ismernünk, ki milyen mértékű bevonásra tart igényt ahhoz, hogy biztonságban érezze magát  a változások közepette. Személyreszóló bánásmód, tájékoztatás jár nekik. A távoli rokonok jobban szeretik, ha nem terheljük őket a mindennapi történésekkel, megelégednek azzal, ha a fontosabb eseményekről (mérföldkövekről) értesítjük őket, vagy akkor fordulunk hozzájuk, amikor konkrétan kérni szeretnénk valamit tőlük. Ők annak örülnek, ha a projektről kapott hírekben kiemeljük a lényeges tudnivalókat, és rájuk bízzuk, elolvassák-e a részleteket.

Amikor például átköltöztetjük a céget, „családtagjaink és közeli barátaink” – vagyis munkatársaink - szeretnek bevonódni: megbeszéljük velük a céljainkat, a keresést, a megnézett ingatlanokat, kikérjük a véleményüket döntés előtt, és együtt örülünk a projekt eredményének. Egyéb partnereink, ügyfeleink egyszerűen kapnak egy értesítést, hogy ne keressenek a régi címen, és megkapják az új elérhetőségeinket egy tájékoztatással, hogy váltottunk. Mindannyian érintettek a projekt végeredményében, de más-más kezelésmódot igényelnek.

Szervezeten belüli projektnél is számba kell vennünk,

• kik tartoznak az első csoportba, tehát alapos, részletes,előzetes tájékoztatást kell nekik adni,
• és kik a második csoportba, akiket csak a fontosabb eseményekről, eredményekről kell értesíteni.

Konfliktusban álló felek

Tekintsünk úgy az érintettekre, mint konfliktusban álló felekre. Nagyon kicsi a valószínűsége annak, hogy az érintettek érdekei, céljai, igényei egybeesnek – és a projekt, mint a mesében, minden érintett támogatását élvezve akadály nélkül révbe ér...

A projektmenedzsernek úgy kell viselkednie, mint egy mediátornak: a lehető legteljesebben meg kell értenie a feleket, tudni kell gondolkozni az ő fejükkel. Nem csak a kimondott, számszerűsíthető célokat, elvárásokat kell tőlük megtudni, hanem a ki nem mondott, személyes indítékokat, rejtett szándékokat is. Meg kell találni a közös nevezőt, azt, hogy hogyan lehet legnagyobb a közös nyereség, hogyan lehet elviselhetővé tenni az egyéni veszteségeket.

Előfordul, hogy a projekt menedzser nem érti, hogy a vezető, akinek a csoportja új, gyorsabb, hatékonyabb IT alkalmazást kap, vele új laptopokat, miért hoz fel újabb és újabb szakmai (-nak álcázott) kifogásokat az IT vezető felé, ezzel késleltetve a projektet. Pedig  szemmel láthatóan „mindenki jól jár”. Lépjünk bele a vezető cipőjébe:  a projekt számára azt is hozza, hogy csökkentenie kell a csoportja létszámát – ez egy könnyen átlátható következmény. De azt is észre kell vennünk, ha például ő egy kimondottan konfliktuskerülő ember, akinek a szokottnál is nagyobb stressz az elbocsátás, vagy azt, ha a vállalati kultúrában a vezetői hatalom egyik fokmérője a beosztottak száma... Nem fogja teljes mellszélességgel támogatni a projektet, akkor sem, ha racionálisan ő is belátja, hogy ez cégérdek. A felszínen ez két vezető konfliktusaként jelenhet meg, amit a projektmenedzsernek kell kezelnie.

Listázzuk fel,

• melyik érintettnek mik lehetnek a szemmel látható, kimondható érdekei, elvárásai,
• milyen egyéb, ki nem mondott érzései, rejtett szándékai lehetnek a projekttel kapcsolatban.

Különböző szerepek

A érintettek szerepük szerint is megkülönböztethetők. Vannak Partnerek, akik hozzájárulásukkal támogatják a projektet pl. pénzeszközökkel, emberi erőforrásokkal, stb., Szponzor(ok), aki (k) a projekt eredményességében alapvetően érdekeltek, esetleg ők kezdeményezték, hozták létre azt.  Találhatunk Ügyvédeket, akik ugyan legitim hatalommal nem rendelkeznek a projektet illetően, de segíthetnek elérni az eredményt, vagy elnyerni mások támogatását. A Változás bajnokai azok, akik véghez viszik a projektet, akár hatalommal rendelkező támogatóként, akár a projekt team tagjaiként. Végül, de természetesen nem utolsósorban van a Célcsoport, akik a projekt fókuszában állnak, akik a projekt „kedvezményezettjei” (majdnem áldozatot írtam... J).

Ne tévedjünk: bár a szervezetben elfoglalt helyük automatikusan kijelöli az emberek szerepét a projektünkben, ettől még nem lehetünk biztosak abban, hogy megkönnyítik a projekt végrehajtását. A szervezetben elfoglalt pozíció nem jelöli ki a valós erőbeli viszonyokat, és nem mutatja az emberi, személyes tényezőket. Vajon hogy fog „Partnerként” támogatni az, aki esetleg személyes antipátiával viseltetik irántunk, vagy „Szponzorként” az, akinek pozíciója van, de igazi hatalma már kevesebb? Elvileg a „Célcsoport” együtt kéne, hogy működjön, de fognak-e, ha a változás rosszabb körülményekkel kecsegteti őket? Az ügyes projekt menedzser azonban megtalálhatja azokat, akik nagy kapcsolati hálóval, informális hatalommal rendelkeznek, megszerezheti támogatásukat, megnyerheti az ellenállókat, formálhatja a érintettek szemléletét.

Ehhez azonban tisztában kell lennie azzal, kik ők, és mik valódi elvárásaik, érdekeik. Bármelyik csoportosítást is használja, ezek segítik, hogy megtervezze, hogyan fogja kezelni őket.

A bejegyzést inspirálta: http://www.projectsmart.co.uk/

- kérdezte valaki, amikor elkezdtem írni ebbe a blogba, és a látogatókat buzdítottam, hogy írják meg, miről szeretnének itt olvasni. Ez a blog azért született, hogy segítsen a kis- és közepes vállalkozásoknak, hogy hatékonyan tudják saját projektjeiket vezetni. Méghozzá úgy, hogy a posztokban sorra bemutatja, miben nyilvánul meg a "projekt alapú gondolkodás"...

Szerintem ez a következőket jelenti:

• A vállalkozás ismerje fel, ha egy feladat nem az operatív, mindennapi, már kialakult folyamatok és feladatmegosztások mentén lesz megoldható. És hívja ezt projektnek. A blog első bejegyzése segít megállapítani, mikor áll fent ez a helyzet.
• Ezeknek a feladatoknak a megoldásához a vállalkozásnak a projektmenedzsment szemléletét, gondolkodásmódját, és eszközeit célszerű használnia.  Ebben segít ez a blog.

 Szemlélet és gondolkodásmód:

• A projekt egy határozott kezdettel és véggel rendelkező folyamat, egymással összefüggő feladatok sorozata, ami a szervezet több egységét érinti, több egységből „használ” emberi és egyéb erőforrásokat, és külön felelős vezetője van. Olyan, mintha létrejönne a szervezetben egy ideiglenes szervezet (projekt team vagy csapat), egy konkrét feladatra, majd megszűnik.
• A projekt legfontosabb jellemzője, hogy egy terv szerint működik. A jó terv szerintem legalább 80%-ban meghatározza a projekt sikerét. A terv tartalmazza az elvégzendő feladatokat, azok összefüggéseit (egymás után vagy párhuzamosan végezhetők),  a feladatokat végzőket, a felelősöket, a határidőket. A „kezdjük el, aztán majd lesz valami” hozzáállás nem szül sikeres projektet.
• A terv készítéséhez és szem előtt tartásához egyszerre kell távlatokban, hosszútávú célokban és ugyanakkor részletekben gondolkodni: látni kell, hogy a mai és holnapi lépés a távlati cél felé vezet-e?
• Rendszerszemlélet kell hozzá: látni az összefüggéseket, például azt, hogy egy adott feladat elvégzése, vagy az ott felmerült probléma hogyan hat az egész projektre.
• A projektnek konkrét célja van, ami a szervezet stratégiai céljaival összevág – ha nem, nem érdemes csinálni.
• A projektnek van egy felelős vezetője, akinek hatáskört kell adni: pontosan definiálni, hogy mire van jogosultsága és mire nem. A projekt vezetője a szervezet többi vezetőjének sorába emelkedik – a projekt időtartamára. A többieknek tudomásul kell venni, hogy döntéseket hozhat, utasításokat adhat ki, feladatok elvégzéséről beszámolót kérhet, azokat ellenőrizheti – hiszen ez a dolga.  Előre jó megállapodni abban, hogyan használhatja más vezetők erőforrásait. (Ha a szervezetnél vannak komolyan vett Munkaköri Leírások, érdemes számára készíteni egyet.)
• A projektben dolgozóknak is meg kell szokniuk, hogy két főnökük van: saját szervezeti vezetőjüktől, és a projektvezetőtől is kaphatnak feladatot.
• A projektben a közös cél és terv a legfontosabb: mindenkinek úgy kell a saját feladatát végezni, hogy a közös cél lebegjen a szeme előtt. Ez sokszor túlórát, sokszor szakmai vagy egyéb kompromisszumokat, intenzív információcserét jelent! Nem elég saját közeli kollégáit és azok munkáját ismerni, tisztában kell lenni a többi team-tag területeivel is – hiszen csak így tudja megítélni, milyen hatással van a munkája a többiekére.
• A projektnek van egy határozott kezdete. Ekkor alakul ki a közös cél, a terv, a munkamegosztás és az együttműködés szabályai.
• A projekt valami új dolog bevezetéséről, a szervezetbe való beillesztéséről szól. Ezért a team tagjainak jól kell kezelnie az újfajta feladatokat, a bizonytalanságot, az előre nem pontosan tervezhető eredményeket. Egy projekt során sok váratlan esemény is történhet, ezekkel együtt a projektet célra kell tartani – ez rugalmas, de kézben tartott változáskezelést igényel. Ez egy egyébként rugalmatlan szervezetben komoly kihívás.
• A projektbe a témához értő kollégákat kell bevonni, és az együtt dolgozóknak igazi csapattá kell érniük, minél előbb – ehhez nyitottság, jószándék, nyílt kommunikáció, információmegosztás, konfliktuskezelés szükséges!

Vagyis azért fontos a projektalapú gondolkodás, mert ez más, a mindennapi rutintól eltérő, szokatlan megoldásokat hoz a szervezetbe, és ezt érdemes nagyon tudatosan kezelni!

Ami az eszközöket illeti, nem kell feltétlenül méregdrága szoftverekre vagy szofisztikált munkamódszerekre gondolni – ha a projektszemlélet helyén van, a JPÉ (józan paraszti ész) megteszi.

• Kell egy projektindító dokumentum, ami a projekt célját és főbb paramétereit rögzíti, ami iránymutatással szolgál végig, mindenkinek. Tartalma a projekt fajtájától (céljától) függ, de itt található egy egyszerű verzió.  
• Kell egy eszköz a projektterv átlátható, egyszerűen használható, mindenki számára érthető bemutatására. Szöveges (táblázatos) vagy grafikus (Excel, MS Project), amit leginkább elfogadnak a team tagok. Verziókat kell tudni kezelni.
• Kellenek időszakos státusz beszámolók: ki, melyik feladatával hol tart. A projekt nagyságától függően szóban, egy értekezleten, vagy írásban a projektvezető felé, vagy Sharepointon, közös dokumentumban, ami a legjobban fekszik a csapatnak.
• Kellenek előre meghatározott kommunikációs szabályok: ki, miről kit, milyen formában értesít. Ki, kitől, milyen információkat kap meg – és mikor.
• Kellenek megbeszélések: problémamegoldásra, döntésre, vagy egyszerűen a státusz gyors áttekintésére. Ez kritikus pont, itt látható néhány nagyon jó tanács.

Persze, kell egy jó projektmenedzser is – erről később több bejegyzést is fogok írni.

 És mi van, ha nem így gondolkodunk?

Sajátos jelensége a szakmának, hogy ha a projektmenedzsment jól működik egy szervezetben, akkor nem látszik. Ha nem látszik, akkor nem becsülik, sokszor nem tudják, mire jó, miért szükséges. Ha minden aránylag olajozottan megy, a fogaskerekek egymásba illenek, működik a szerkezet, akkor nem tűnik fel, hogy ezt valakinek össze kellett így rendeznie. Ha csak a curling követ figyeljük a pályáján, és az akadály nélkül siklik a megfelelő irányba, nem látjuk, micsoda munka előtte úgy söprögetni, hogy az időben a megfelelő célba érjen.

Amikor egy szervezetben azt látom, hogy nem becsülik értékén a projektmenedzsmentet és a projektmenedzsereket, eljátszom a gondolattal, hogy ki kéne próbálni, milyen lenne nélkülük. Mondjuk, pár napig nem mennének be dolgozni, nem vennék fel a telefonokat, nem válaszolnának a kérdésekre... (A projektmenedzserek erre tiltakozni szoktak, miszerint semmi kedvük ahhoz, hogy utána  szétszálazzák az összegubancolódott fonalakat, tisztázzák a félreértéseket, kibékítsék az összeveszett feleket...)

Olvastam egy jó hasonlatot: a projektmenedzsment a projektet összetartó láthatatlan ragasztó.

Nehéz észrevenni és számon tartani azokat az erőfeszítéseket, azt az időt, amit a PM azzal tölt, hogy

-          összeköti a projekttagokat,

-          tárgyalásokkal megegyezéseket hoz létre,

-          reális célokat és időtervezést alakít ki,

-          kiosztja a szerepeket és

-          mindenkinek a megfelelő feladatokat,

-          ellenőriz, számonkér, problémát old meg, és így tovább.

Ahhoz, hogy egy szervezet belássa, saját érdeke, hogy e szakma és művelői megkapják megfelelő helyüket és hatáskörüket, el kell adni a projektmenedzsmentet.

Ehhez pedig publicitás kell: megmutatni, kommunikálni: milyen haszna van a projektmenedzsmentnek a szervezet számára? Illetve: hogyan nyilvánul meg ez a haszon a szervezet vezetőinek életében, terheik egy részének átvállalásában?

Ragasztó: ahogy már előbb írtam, a PM egy cél felé összerendezi, összetartja az összefüggő tevékenységeket és együttműködő embereket. Ezzel a szervezet vezetőit tehermentesíti.

Információs központ: nem csak a team-tagok, hanem a szervezeti vezetők is profitálnak abból, ha egy projektről összefoglalt, lényegretörő – vagy éppen személyre szabott – információt kaphatnak, nem kell azokat különböző helyekről „összevadászni”.

Döntéshozó vagy döntéselőkészítő: akár ő maga jogosult meghozni egy-egy döntést a projektben, akár egy magasabb beosztású szervezeti vezető, mindenképpen hatalmas segítség, ha széleskörű és naprakész tájékozottság  birtokában alternatívákat állít fel a projektmenedzser, mérlegeli a következményeket és javaslatot ad.

Felderítő és problémamegelőző: rengeteg erőforrást (időt, költséget) takarít meg azáltal, hogy folyamatosan előre gondolkodik, ismeri az összefüggéseket, felismeri a potenciális problémahelyzeteket és időben beavatkozik.

Ösztönző, lelkesítő és csapatépítő: ha jó a projektmenedzser, a teamtagok motivációjának feladatát is (részben) átveszi a szervezeti vezetőktől. Figyel arra, kit mivel lehet motiválni, kihasználja az egyéni erősségeket és szinergiákat hoz létre.

Mediátor: az egész szervezet hatékonyságát növeli, ha a PM észreveszi és megfelelő módon kezeli a konfliktusokat, legyenek azok személyes, szakmai, vagy szakmaiba bújtatott személyes nézeteltérések. A projekt érdekében elengedhetetlen, hogy ezeket időben feloldja –  ezzel az együttműködést javítja az egész szervezetben.

Tolmács: legendás megnemértések és félresiklott ügyek születnek abból, hogy az egyes szakmák nem értik egymást, hiszen különböző nyelveket beszélnek. A PM a projekt érdekében kénytelen megtanulni mindegyikük nyelvét, és állandóan „fordítani” közöttük. A szervezet számára minden megelőzött félreértés haszon.

Nagykövet: A PM képviseli a projektben szervezeti célokat. Egy jó PM olyan, mint egy jó vezérigazgató: víziót ad, kívánatos jövőt fest a team tagok elé. Ügyel arra, hogy a sok egyéni és csoportcél nem húzza szét a közös munkát, azok mindig összerendeződjenek a szervezeti célok irányába.

Ezeket a szerepeket akkor tudja a PM betölteni, ha megfelelő helyen van a szervezetben és megfelelő hatáskört kap hozzá. Néha úgy tűnik, ehhez azonban még egyszerep megtanulása szükséges: jó értékesítőnek kell lennie. Meg kell találni azokat a kommunikációs formákat, csatornákat, alkalmakat, amikor megmutathatja mindazokat az előnyöket, amiket a projektmenedzsment „szállít” a szervezetnek – természetesen a sikeres projektek mellett.

Mitől sikeres vagy mitől pokol egy együttműködés? Mi az a Projekt alapú gondolkodás és miért van rá szüksége egy KKV-nak?

A sikeres EGYÜTTMŰKÖDÉS titka! from Tamas Szurmik on Vimeo.

Minden Projektmenedzser és Cégvezető ismeri azt az érzést, amikor kiadja a feladatokat, határidőt szab, majd beszámoltat, de csak azt látja, hogy senki sem lelkes, mert nem tetszik nekik a rájuk rótt feladat.

Szabad a vásár

A klasszikus, majd mi megmondjuk „mi a tuti” irányítás helyett, adjunk egy feladat listát a Projektcsapatnak (ne a projekttagoknak egyenként), majd bízzuk rájuk a döntést, hogy ki mit vállal, ki melyik feladatot érzi testhezállónak. Ha kell szervezzünk ezért egy megbeszélést vagy használjunk valamilyen online csoportmunka felületet.

Adjunk egy határidőt, 1-2 nap, majd válaszként kérjünk egy listát, amiben szerepelnek a következő:

• ki, melyik feladatot mikorra vállalt,
   
• a vállalt feladatnak milyen alfeladatai vannak és ezeknek mi a határideje (legalább 4-5 alpont legyen),
   
• mindenki írja le, hogy milyen függőségeket lát a feladata ellátásában, kitől vár információt, milyen másik alfeladat befejezésétől függ az ő munkája. Mi az, ami hiányzik neki a feladat elvégzéséhez.

Ezzel azt érjük el, hogy

• a csapat minden tagja (legtöbb) lelkes lesz a kiválasztott feladattal kapcsolatban, magáénak érzi azt és előre gondolkodik a végrehajtás lépéseiről,
   
• kapunk egy részletes feladat listát határidőkkel, amiben már előre mindenki egyetértett, így ez tökéletesen használható a státusz jelentéshez és a munka ellenőrzéséhez,
   
• nekünk, mint Projektmenedzsernek csak annyi feladatunk marad, hogy priorizáljuk az egyes alfeladatokat és kezeljük az felmerült függőségeket.

Próbáljátok ki és várom a tapasztalatokat!

Úgy érzed valami kimaradt? Véleményed vagy ellenvéleményed van a témával kapcsolatban? Szólj hozzá!

Beszéltünk már arról, hogy mi szükséges egy projekt indításához, hogy egy projekt mikor sikertelen, de eddig azt még nem vizsgáltuk, hogy mi az, ami sikeressé tesz egy projektet?

A válasz természetese, hogy a „jó Projekt Menedzser és a kiváló Projekt Csapat”!

Viszont, van mikor ez is kevés, lássuk, mire felejtenek el sokan odafigyelni:

1. Egyetértés a célokban
   Hiába van kiválóan meghatározott célja a projektednek, ha a projekt tagok nem értenek benne egyet. Addig tilos tovább lépni, amíg mindenki el nem fogadta a közös célt….vagy később ne lepődj meg, hogy furcsa megoldásokat és értetlen fejrázást kapsz a csapatod tagjaitól.
    
2. Kidolgozott terv
   A „projekt tervezés” a projekt menedzsment „alkotás része”. Legyen mindig leírt, részletes terv, minden feladatnak legyen határideje, felelőse és ezek a határidők legyenek számon kérve és betartva.
   
   Ügyelj a Költség – Idő – Minőség egyensúlyra és ne feledd: bármelyik is változik, vele változik a másik kettő is!
    
3. Hatékony kommunikáció
   A legtökéletesebb projektterv sem ér semmit, ha arról csak a Projektmenedzser tud. Igenis, tessék folyamatosan informálni a projektcsapatot, még azokat is, akiknek abban a pillanatban nincs semmi konkrét teendője.
   
   A projekt-összefoglaló (státusz riport) legyen rendszeres (pl minden Péntek délután menjen ki), mindig adott időpontban és kapja meg minden projekttag.
   
   Legyen benne megemlítve:
   
   • minden eddigi eredmény, ami történt,
   • minden befejezett feladat
   • minden most következő esemény, feladat
   • minden változás, ami felmerült a projektben
   • a menedzsment és a környezet elismerő véleménye a projektről
4. Projekt hatókörének szabályozása
   Sokan elfelejtenek és sokan nem mernek határt húzni, hogy mi az adott projekt része és mi nem. Sokszor nem került rögzítésre, hogy miért felelős a Projekt, a Projektmenedzser és miért nem. Mik azok a kérdések, amiben a Projektmenedzser hoz döntést és mi az, amiben a Menedzsment a felelős.
   
   Ez mind legyen előre leírva, annyira részletesen, amennyire csak lehet, szánjunk rá időt és később sok fejfájástól megkíméljük magunkat.
    
5. ( +1 ) A Menedzsment támogatása
   Széllel szemben v….ni badarság! Így van ez a projektmenedzsmentben is, ha a projekt indításakor nem kaptuk meg a Menedzsment támogatását, akkor a projekt végig vitele kínkeserves lesz. Egyetlen Projektmenedzsernek sincs akkora szava egy cégben, mint egy Menedzsment tagnak.
   
   Ezért térképezzük már fel az elején:
   
   • Kikértük-e az összes érintett terület vezetőjének jóváhagyását írásban?!
   • Melyik vezetőt kell bevonni az operatív döntésekben?
   • Melyik vezető fogja értékelni a projektet?
   • Melyik vezető rendelkezik vétójoggal a „Mi” döntéseinket illetően?
   • Van-e Mentorunk és neki milyen befolyása van a többi vezetőségi tag felett?

Úgy érzed valami kimaradt? Véleményed van a témával kapcsolatban? Szólj hozzá!

Azt követően, hogy azonosítottad projektjeidet a legfontosabb feladat, hogy meghatározd azok célját, azokat az eredményeket, amiket elérve sikeresnek tekintheted a projektet.

Miért is hasznos, ha jól vannak megfogalmazva a projekt célok?

• A projekt céljait bármikor össze tudod vetni vállalkozásod céljaival és egyből látod, hogy ez a projekt hasznos-e számodra vagy csak az idődet rabolja. Ha ez utóbbi, akkor itt az ideje kidobni a projektet.
   
• Több projekted is van egyszerre, de nem tudsz dönteni, hogy melyikkel foglalkozz. Amennyiben rendesen meghatároztad a projektek céljait, akkor ez segít eldönteni, melyik projekttel kell előbb foglalkoznod és melyik várhat még.
  
  Vizsgáld meg a projektek céljait és nézd meg, hogy melyik cél fontosabb cégednek, melyik cél hozd neked több hasznot és egyből megvan a döntés, hogy melyik projekttel kell foglalkoznod.
   
• Nem tudsz dönteni egy fontos kérdésben? csak vedd elő a projekt céljait, vizsgáld meg a lehetőségeket abból a szempontból, hogy melyik visz közelebb a projekt céljaihoz és egyből megvan a megoldás.
   
• Céltalan projektben senki sem szeret részt venni és ez igaz a projekt tagokra is. Lelkesítsd projekt csapatod, állítsd őket az ügy mellé, mutasd meg nekik a projekt céljait, beszélj róla, fontos hogy megértsék és higgyenek benne. Legyenek fontos számukra. Hidd el egy kicsi, de lelkes csapat százszor többet ér, mint egy háromszor akkora „semmit nincs kedvem magamtól csinálni” csapat.

Milyen a jól megfogalmazott projekt cél?

• maximum 3-4 mondat, amit mindenki 1 perc alatt el tud olvasni és meg tud érteni
• legyen tömör és koncentráljon a lényegre
• legyen reális, teljesíthető cél
• olyan cél legyen, amiben mindenki egyetért, elfogad és hisz benne, hogy teljesíthető

Példák:

Weboldal frissítés: A Weboldal frissítés célja,hogy felkerüljenek az új termékeink leírása, készüljön egy frissített arculat, ami követi a mai online trendeket. Ezen túl indítsuk be a céges blogot és teremtsük meg a hírlevélre való feliratkozás lehetőségét.

Marketing kampány: Szeptember 1 és 30 között kerüljön kidolgozásra egy az új vevőket megcélzó kampány, a kampány koncentráljon a lokális vevők megtalálására és becsábítására az üzletünkbe. A projekt akkor sikeres, ha októberben 1000 új érdeklődő adatait tudjuk felvenni az üzletben.
 

Szerinted mikor hasznos még, ha van célja a projektednek? Szerinted milyen az igazán jó projekt cél? Mond el véleményed!

Fájdalmas beismerni, de van, hogy egy projekt sikertelen. Hiába vagyunk mi a világ legjobb projektmenedzserei, akkor is előfordul, hogy „elbukunk”.

Arra a kérdésre, „Hogy mikor sikertelen egy projekt?” előbb-utóbb, mindenki megszüli a maga válaszait, mint:

• nem az készült el, amit terveztünk, amit megálmodtunk,
• nem készült el határidőre,
• túllépte a költségkereteket.

Vegyük észre ez már csak végeredmény! Sokkal fontosabb, a „miértet” keresni:

• Miért nem az készült el, amit kértünk?
• Miért nem készült el határidőre?
• Miért került kétszer annyiba, mint eredetileg terveztük?

Amint megvannak a miértek, vagyis az okok, akkor tudunk rájuk figyelni és elkerülni őket.

A 13 leggyakoribb oka az elbukott projekteknek:

1. rosszak, irreálisak, teljesíthetetlenek a projekt céljai
2. nem megfelelő a projekt csapat, nem jó alvállalkozót választottuk
3. nincs meg minden szakértelem a projekt csapaton belül
4. rossz a tervezés, az egyes feladatokra tervezett idő és ember erőforrás kevés
5. nincs pontosan megfogalmazva az elvégzendő feladatok és azok részfeladatai
6. nincs írásosan dokumentálva a projekt, túl sok a szóbeli megbeszélés és megegyezés
7. nem „egy nyelvet beszélnek” a projekt tagok, nem ugyanazt értik az egyes megfogalmazásokon és meghatározásokon
8. nem definiáltak a projekt határai, vagyis mi tartozik a projekt feladatai közé és mi nem
9. nem definiáltak az egyes feladatok felelősei és határidői
10. a projekt tagjai nem értenek egyet a projekt céljaival
11. a projekt tagjai nem ismerik
    • a projekt céljait,
    • a határidőket
    • a saját feladataikat,
    • mások feladatait
    • a projekt során bekövetkezett változásokat
12. nincs rendes projekt-ütemezés és nincsenek nyomon követve a projekt események
13. nincs rendes projekt-költség tervezés

Amennyiben úgy látod, hogy még hiányos a lista, írd meg a hozzászólások között, hogy szerinted mi az, ami miatt elbukhat egy projekt