Posts Tagged ‘issue’

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.