Archive for április, 2011

Egy aktuális munkám kapcsán előkerült nem mai keletű problémáról szeretnék néhány szót ejteni.

Először a fogalmakat járva körül, és magyarázatot adva a furcsa címre, az issue angol kifejezés magyar megfelelőjét keresve évekkel ezelőtt arra a következtetésre jutottam, hogy majdnem probléma, majdnem tennivaló, de néha ezzel még foglalkoznunk kell, azaz nincs (én nem találtam) pontos magyar szót erre a fogalomra. Ezért, habár nem szeretem, de használom az issue kifejezést.

Miről is van akkor szó: Issue = probléma? Issue=Tennivaló?

Magyar Wikipédiából az Issue Management kulcsszó alatt találtam: ”Az angol nyelvben az “issue” szó jelent: hozamot, jövedelmet, eredményt, témát, vitapontot. A gyakorlatban az “issue” alatt azokat a témákat kell érteni, amelyek közérdeklődésre tartanak számot, és amelyekre többnyire nincs egyértelmű megoldás.” – ez szerintem messze áll attól ami minket PM-eket foglalkoztat.

Angol Wikipédiából az Issue Management kulcsszó alatt találtam:  ”In Project Management, the purpose of Issue Management is to ensure that any concerns recognized during a project are addressed in a timely manner and do not go unresolved until they become major problems.” – ez már közelít a megértéshez.

Szerintem: issue alatt az alábbiakat értem – olyan kockázat amely már bekövetkezett és kezelni kell akár problémát jelent akár nem; – olyan jövőbeni esemény/állapot, amelyel a projekt szempontjából foglalkoznunk kell, nem kockázati kategóriába sorolható, de nem is konkrét tevékenység, azaz nem tudom megadni a felelős, határidő, tennivaló hármasból bármelyik kettőt.

Az értelmezési kérdések után visszatérve a címben felvetett kérdésre, nagyon sok projektvezetőnek problémát okoz besorolni és megfelelően kezelni az adott eseményeket valamilyen kategóriába. Amikor projektet vezetek általában kezelnem kell legalább 3, de általában 5 különböző kategóriájú (nyilvántartásba szervezett) eseményt: Tennivaló – ToDo; Kockázat – Risk; Issue (én alapból ezeket szoktam); Probléma – Problem; Constraint – Feltétel. Nem mindig egyértelmű, hogy hova mit kell tenni, de alapvető szabályok mentén el lehet választani a különböző nyilvántartásokat.

Nagy projektek (programok) esetén óhatatlanul felmerül, hogy sok PM kerül különböző fórumokon össze, különböző módon, formában, tartalommal kell előrehaladás- és státusz-jelentéseket leadni és itt keveredhetnek a fogalmak értelmezései, mit hova tegyünk. A leggyakoribb hiba tapasztalatom szerint a kockázat és issue összekeverése, aminek a hátránya kettős lehet: van egy issue nyilvántartásunk amiben megjelennek kockázatok, vagy olyan elemek amik kockázatot hordoznak, így a kockázatkezelés hatóköréből kikerülnek, másrészt kockázatkezelés hatókörébe vonunk olyan eseményeket amivel ugyan foglalkozni kell, de nem kockázat a projekt számára (vagy még nem emelkedett kockázati szintre, és lehet, hogy fog).

Miért kell ezzel egyáltalán foglalkozni, mik a veszélyek?
Egyik esetben kikerül a formális kockázatkezelési folyamat hatálya alól egy olyan esemény amit ha nem vizsgálunk nem derül fény adott esetben valós/komoly kárt okozni képes következményekre, aminek okán a projektet másképp kellene folytatni.
Másik esetben felesleges munkát okozunk a projekt tagoknak, amivel értékes erőforrásokat vonunk el projekt termék létrehozását végző csapattól, hiszen, lássuk be, jellemzően azon embereket bízzuk meg a kockázatok elemzésével akik érdemben átlátják a projektet és a projekteredményt és annak elvárt hatásait is ismerhetik. Ilyen ember nagyon kevés van egy projektben, IT területen jellemzően az “architect” típusú emberek.

Minősítés/átminősítés
Ki minősítse az eseményeket? Erre a válasz egyszerű – a projektvezető – igen ám, de összefüggő projektek, egymásra ható alprojektek, program esetén ez már nem ilyen nyilvánvaló. A projektet vezető, adott esetben üzleti szempontú kiválasztás esetén nincs és nem is kell feltétlenül tisztában legyen pl. az informatikai infrastruktúra szintjén zajló eseményekkel, azok besorolását sem fogja tudni megtenni. Ezért úgy gondolom, hogy az adott szakterületen, alprojekten irányító projektvezetőnek/vagy/szakmai vezetőnek kell besorolni/minősíteni az eseményeket, de ezeket projekt/program szintre fel kell

Mikor kerüljön átminősítésre kockázatból issue-vá egy esemény?
A válasz látszólag egyszerű: ha bekövetkezett, ami az esetek többségében egyszerűen megítélhető, de sokszor nem minősítjük át, nem tesszük át másik nyilvántartásba és ez programok esetén jelenthet adminisztrációs/menedzsment problémát.

Mivel foglalkozzunk és mennyit?
Mivel az issue olyan esemény aminek bekövetkezési valószínűsége 100% ezekkel kell először foglalkozni, hogy a lehetséges negatív hatásokat csökkentsük, de javaslom, hogy többet foglalkozzunk a kockázatokkal, hogy legyünk tisztában hatásukkal, és csökkenjenek azon issue-k számai amik a bekövetkezett negatív kockázatok.

Az előző cikk gondolatmenetét folytatva a projekt menedzsment és a projekt, mint stratégia megvalósítási eszköz témában felmérteket részletezve a jelen blog és saját szakmám, gyakorlatom szempontjából:

Kelet Európára vetve vigyázó szemeinket két pontra hívnám fel a figyelmet a projektmenedzsment szabványok használata a szervezetnél be van vezetve és működik nagyon jellemző a projektekre, míg a megelégedettség a PM szabványokkal nagyon alacsony. Ha ebből a két értékből indulunk ki, akkor vannak szabványok bevezetve, de nem vagyunk elégedettek vele, ami jelentheti, hogy nem a megfelelő szabványokat használjuk, vagy nem jól használjuk a szabványokat. Az elsőre a válasz az, hogy a szabványok nem rosszak, hiszen a többi fejlettebb régióban nincsenek ilyen méretű különbségek (talán Latin Amerikában van Kelet Európához hasonló helyzet), tehát ha más lehetőség nem merül fel, akkor rosszul használjuk a PM szabványokat. Ez figyelmet érdemel.

A probléma megoldására, részben ebből a felmérésből választ kapunk, ha ugyanezen diagramon a „Tanulságok levonása mennyire része a projektjeinknek” kérdést nézzük, amire a válaszadók átlaga Kelet Európában közepes, de ez az összes résztvevő arányában a második legalacsonyabb, az számomra azt jelenti, hogy a projekt zárás után vissza kell térnünk a pozitív és negatív tanulságokra. A projekt tanulságok vállalati szervezetbe történő visszavezetésére energiát kell fordítani, erre rendszert kell kidolgozni. Ezért is fontos egy jól működő, felsővezetői támogatást élvező PMO kialakítása.

Nézzünk a gyakorlati része mögé a fentieknek. Milyen eszközöket használunk a módszertanból, mit nem használunk? Ebből talán arra is választ kaphatunk, hogy mire kell ráerősítenünk, hiszen amit használunk azzal nem vagyunk elégedettek. A mellékelt ábrán látható az eszközök használata:

Koncentráljunk ismét Kelet Európára, a legalacsonyabb értékekre, illetve a legnagyobb negatív értékű eltérésekre a Nyugat Európai átlagtól:

-          Sablonok (Template) alkalmazása: -20 az eltérés

-          Eljárások (Method) alkalmazása: -15 az eltérés

-          Other (RACI mátrix, oktatás): a legalacsonyabb

A két szélső értéket emelném ki: Template-k használata – miért alacsonyabb ez? – mert a tanulási folyamat hiányzik, kevesebb a visszacsatolás, a sikeres dolgokat nem ültettük vissza a gyakorlatba, a felesleges dolgokat nem „gyomláltuk” ki a rendszerből; kinek kellene ezt végezni? – ez egyértelműen PMO felelősség kellene legyen.

Other kategóriából két eszközt emeltem ki: oktatás – ez a fentiekre rímel (megerősítve érzem saját érvelésem J), RACI mátrix – felelősségek, számon-kérhetőség bevezetése a projektjeinken, ha ismerjük a projekt szervezetet, előre megtervezzük a feladatokat mellé tenni nem egy nagy feladat, de ha az előző kettő nem ismert, vagy nem terveztünk elég részletesen nem tudjuk mellé tenni. A felelősség vállalási kedvről nem értekeznék külön, mindenki tapasztalhatja saját projektjein.

— vége —

A felmérés vérehajtása, eredményeinek bemutatása: forrás www.ebs-siie.de 

A felmérés eredményeinek értelmezése, szubjektív vélemény megfogalmazása: forrás PM

Tavalyi év második felében kezdtem neki a Global Project Management Survey – projektmenedzsment felmérés eredményének kivonatos bemutatásába, a számomra érdekes eredmények ismertetésébe. Ezt folytatom ebben a cikkben, illetve összegzem azokat a szubjektív véleményeket amit a kiértékelés során tettem.

Szó volt az általános PM megközelítésről, a kutatás eredményeiről a projektmenedzsment fontosságáról régiónként, PM minősítés gyakoriságáról és fontosságáról szintén régiós bontásban.

Amiről még nem esett szó az a projekt munkával -, a szervezettel – való kapcsolat, az egyéni és szervezeti tudás (kompetencia) projekt sikerrel való összefüggéseiről.

A projekt siker és a projektjellemző elemek egymásra hatását vizsgálva a nem „Nyugat Európa és fejlett országok” eredményeket vizsgálva az eredményt az alábbi diagram foglalja össze:

Érdekes figyelni a Kelet Európai eredményekre ahol a sikeres projektek környezetet leegyszerűsítve az alábbiak szerint írhatnánk le:

-         A hibákat jól tűri

-         Nagyon erős felsővezetői támogatással rendelkezik

-         Nem fontos, hogy szabványok alkalmazásra kerüljenek

-         Legfontosabb tényező a bizalom

-         Alapvetően központosított végrehajtás legyen

-         Elfogadott a nemek közti egyenlőtlenség

Úgy gondolom az eredmények különösebb magyarázatot nem igényelnek, autoriter jellegű vezetési környezethez vagyunk szokva, sokat hibázunk, ezért fontos hogy bízzanak bennünk, mert szakmailag nem vagyunk a csúcson és a szabványokat (számomra jól tervezett, ellenőrzött folyamat) „jó esetben” csak részben tudjuk/akarjuk követni.

A projekt menedzsment és a projekt, mint stratégia megvalósítási eszköz fontossága szempontjából a felmérés eredményei:

A Kelet Európai eredményekre koncentrálva ismételten, megállapítható, hogy a projektek fontossága ebben a régióban a legalacsonyabb így nyilván az elfogadottsága is hasonlóan alakulhat, a stratégiára való hatása is a legalacsonyabb. Kellemetlen de megállapítható, hogy ez a régió a legelmaradottabb „projekt” témában, az okait nem feltétlenül szükséges keresni, történelmünk részben választ ad erre, de ugyanakkor egy jelentős „fejlődési potenciál” van előttünk, ami miatt érdemes pl. ezt a blogot is írnom. J

A sikerre ható legfontosabb egyéni képességek és szervezeti tudás

A sikert meghatározóan befolyásoló tényezők keresésénél több modell jellegű előfeltételezésből indultak ki a felmérést készítők, pl. hogy az egyéni képességeket két nézetben lehet értelmezni, az első „hogyan látjuk magunk”, a másik nézet, hogyan értékeljük mások egyéni képességeit, valamint a szervezeti tudásnál egyszerűsítéssel élve az volt az előfeltételezés, hogy a szervezet leírható 3-3 jól mérhető „hard” jellemzővel és puha „soft” jellemzővel.

A feltárt egyéni képességek:

A fentiek értelmezésre szorulnak, szerintem úgy kell értelmezni, hogy a projekt sikerre ható legfontosabb személyes képességek vezetőképesség „leadership” és a tapasztalat. A vezetőképességet a projekt tagok oldaláról vizsgálták, értem ez alatt azt, hogy az adott tag hogyan látja az adott vezetési stílus hatékonyságát a projekt sikerességéhez viszonyítva. Így általánosan megállapítást nyert, hogy a karizmatikus vezetési stílus minden régióban és minden projekt típus esetén letéteményese a sikernek.

Szervezeti tudás hatása a projektsikerre

A puha „soft” tényezők:

-         szervezeti elkötelezettség (lojalitás)

-         felsővezetői támogatás

-         munkahelyi légkör (bizalom)

Ezen tényezők megjelenése semmilyen meglepetést nem hordoz, mivel ezek általában az ilyen jellegű felméréseken „jól teljesítenek”. Ami számomra meglepő, hogy a legfontosabb tényező a bizalmi légkör. Megnézve az alábbi ábrán furcsa számomra, hogy megelőzi a felsővezetői támogatást (habár minimális a különbség), mert saját méréseim szerint Magyarországon a felsővezetői támogatás hiánya az egyik legfontosabb kudarc tényező a projekteken.

A jól mérhető „hard” tényezők

-         Erőforrás (szervezeti erőforrások: pénzügyi, szakértő)

-         Projekt Menedzsment Szervezet (PMO)

-         Szabványosítás

A rendelkezésre álló erőforrásoknál a mennyiség mellett fontos a rendelkezésre álló szakértelem illeszkedése a projekt jellegéhez, a PMO mint sikertényező úgy értendő, hogy a PMO szervezeti tudástranszfer szerepe van felértékelve mint olyan központi szervezeti elem, amely a projekten felgyülemlő tudást (amely fontos a szervezet számára) átviszi a szervezetbe és képessé teszi a szervezetet a siker megismétlésére. A szabványosítás elsősorban a projekt végrehajtással kapcsolatban lévő szabványok alkalmazását jelentik (úgy PM, mint a projekt termék jellegére tekintettel) és ez a felmérés szerint a projekt minőségre van hatással.

— a szubjektivitás tetten érhető, remélem, még 1 cikk erejéig visszatérek erre a témára —

Forrás: www.ebs-siie.de