Project és Portfolio Management

Stage Gate

noreply@blogger.com (Pap Tibor) — Thu, 23 Dec 2010 09:11:00 +0000

Stage Gate

Néhány hete beszélgettem egy ügyféllel Project Server 2010 bevezetéséről. A beszélgetés közben nem meglepő módon szóba kerültek a projektmenedzsment folyamatok, illetve, hogy azokat hogyan támogathatná a rendszer. Beszélgetőtársam elmondta, hogy korábban minden projektre meg voltak állapítva úgynevezett kapuk, vagy fázisváltások. Ha egy projekt odaért egy ilyen kapuhoz, akkor addig nem mehetett tovább, amíg egy bizottság jóvá nem hagyta a folytatást.

Ezt a rendszert azonban megszüntették, mivel nem látták már értelmét. Nagyon gyakran fordult elő, hogy a projektnek mennie kellett tovább, a bizottság azonban egészen egyszerűen nem ért rá dönteni. A kapuknál bizonyos ISO rendszerben előírt dokumentumok meglétét ellenőrizték, de ezek hiánya valójában nem akasztotta meg a projekt végrehajtását, legfeljebb felszólították a projektvezetőt, hogy később pótolja őket. Vagyis a rendszer túl bürokratikusnak bizonyult, meg is érdemelte, hogy megszüntessék.

A stage gate process azonban hasznos eszköz lehetne, ha nem engednénk, hogy elbürokratizálódjon.
Egy projekt indításakor általában az igénylő szervezet kitölt egy igénylő űrlapot. Ezen az űrlapon jó esetben megindokolják, hogy miért fontos a projekt, milyen stratégiai előnyöket jelent a szervezet számára annak megvalósítása. Meghatározzák a projekt várható megtérülését, számolnak a kockázatokkal. Ezek figyelembe vételével pedig születik egy go döntés.

Legtöbb szervezetnél az igénylő űrlap ezután bekerül a fiókba, és többet senki sem foglalkozik vele. Azonban minden információ, ami ezen az igénylő űrlapon szerepel, egyrészt egy pillanatnyi állapotot rögzít, másrészt pedig még abban az adott pillanatban is csupán becslésnek tekinthető. Amikor elkezdik végrehajtani a projektet, egyre jobban tisztul a kép, egyre jobban elmélyednek az üzleti igényekben, egyre jobban megismerik az alkalmazandó technológiákat. Az idő előrehaladtával ráadásul a környezet és az igények is változnak.
Fentiek miatt érdemes lenne időnként újra elővenni az igénylő űrlapot, ismét átszámolni a projekt megtérülését most már a projekt várható végrehajtásának pontosabb ismerete alapján. Ilyenkor újra át kell gondolni minden információt, ami alapján döntöttünk, vajon releváns-e még, nem változott-e meg.

A stage gate process pontosan ezt szolgálja. Határozzunk meg a projektekre olyan ellenőrzési pontokat, ahol a projekt eddigi szakaszának végrehajtásából származó információkkal is gazdagodva újra értékeljük a projektet. A projekt indításakor csupán az első ellenőrzési pontig hagyjuk jóvá a projekt finanszírozását, ha az ellenőrzési ponton nem megy át, akkor nincs miből folytatni a projektet. Nem ISO dokumentumok meglétét írjuk tehát elő, hanem információkét, melyeket aktívan fel is használunk.
Egy IT projekt esetén például ilyen ellenőrzési pont lehet egy előzetes megvalósíthatósági tanulmány elkészítése, a szoftver magas szintű specifikációjának, vagy egy működő prototípus elkészítése. Ezek mind hozzásegítenek ahhoz, hogy az üzleti megrendelő pontosabban lássa a várható bekerülést, valamint azt, hogy a szoftver végül milyen üzleti előnyöket fog nyújtani a szervezet számára.

Nem szabad hagynunk tehát, hogy a stage gate process egy bürökratikus eszközzé váljon, helyette okosan alkalmazva csökkenthetjük vele a kockázatokat, biztosíthatjuk, hogy a projekt portfólió folyamatosan alkalmazkodjon a változó körülményekhez.

Kell egy csapat

noreply@blogger.com (Pap Tibor) — Tue, 02 Mar 2010 15:32:00 +0000

Kell egy csapat

A magányos hősök ideje lejárt. Ma már mindenhol csapatokban dolgozunk, van projektcsapat, az a funkcionális szervezeti egység is egy csapat, amelyhez tartozunk, vannak vezetői csapatok, és így tovább.

Mindenki azt mondja, hogy egy jó csapat sokkal több mint a tagok összessége. Gyakran előfordult már, hogy azt mondták, "ti egy jó csapat vagytok" vagy "messzebbre juthattunk volna, ha jobban tudtok csapatként együtt dolgozni". De vajon mik azok a jelek, amikből lehet arra következtetni, hogy emberek csoportja jó csapat vagy sem. Sőt, mit lehet tenni annak érdekében, hogy jó csapattá váljunk. Nálunk minden évben van legalább egy csapatépítő tréning, de azon kívül, hogy jól érezzük magunkat, nem nagyon látom, hogy sokkal jobban dolgoznánk együtt csapatként.

Egy ideje keresgéltem a könyvesboltokban egy jó könyvet a témában, mígnem ráakadtam Patrick Lencioni Kell egy csapat című könyvére.

A könyv alcíme: A sikeres együttműködés 5 akadálya. Erről a könyvről írnék most pár gondolatot, és ajánlom mindenkinek elolvasását mivel nagyon jó.

A könyvre jellemző, hogy nem egy száraz szakkönyv, hanem tulajdonképpen egy tanmese a végén értékeléssel. A történet középpontjában egy kezdetben nem túl sikeres technológiai vállalat áll, melynek újdonsült vezérigazgatója ráébreszti a felsővezetői csapatot, hogy a sikerük legfőbb akadálya az, hogy ők mint felsővezetők nem működnek hatékony csapatként együtt. A felismerést követően egy hosszú és rögös út veszi kezdetét, mely során egyesek lemorzsolódnak, de a végére egy hatékony vezetői csapat kovácsolódik össze, és természetesen a cég sikerein is lemérhető ennek eredménye.

A könyv szerint a hatékony együttműködés 5 akadály az alábbi:

Nagyon érdekes, ahogy bemutatja, hogy miben mutatkoznak meg és miből táplálkoznak az egyes rendellenességek:

Bizalom hiánya: Nagyon könnyű kimondani, hogy bízunk egymásban, de vajon tényleg így van? A bizalom a csapat tagjai közt azt jelenti, hogy nem félnek megmutatni egymásnak a saját gyengeségüket, hibáikat. A hatékony csapatok nem rejtegetik egymás közt a szennyest. A bizalom hiánya általában a sebezhetetlenség iránti vágyból táplálkozik.
Félelem a konfliktusoktól: a bizalom hiányából következően a csapattagok között nincsenek nyílt, konstruktív, előremutató konfliktusok. Ehelyett a felszínen látszólagos egyetértés, a mélyben azonban játszmák, klikkesedés alakul ki.
Elkötelezettség hiánya: mivel nincsenek nyílt konfliktusok, végül a döntések mellett nem köteleződik el teljes mértékben a csapat minden tagja. Nehéz olyan döntés mellett kiállnod, amiről előzőleg nem hallgatták meg a véleményedet, észérveidet ellene vagy mellette. Ez nem jelenti feltétlenül a konszenzus szükségességét, de az észérvek ütköztetését igen.
Számonkérés kerülése: A számonkérés eleve nehéz és kényes helyzet, hiszen alapvetően súrlódáshoz vezet a csapat tagjai között, főleg, ha egy csapat egyenrangú tagjairól van szó. Senkit nem fogunk azonban számonkérni, ha előzőleg nem fogadtuk el teljes mértékben a döntést. Az elkötelezettség hiánya tehát szinte lehetetlenné teszi a számonkérést, pedig e nélkül a csapat nem teljesít megfelelően.
Eredmények elhanyagolása: a csapat tagjai hajlamosak lehetnek az egyéni sikerek hajszolására ahelyett, hogy a csapat eredményeire koncentrálnának. Pedig ha a csapat veszít, mindenki veszít, mindegy milyen jó is volt valakinek az egyéni teljesítménye! Ahhoz, hogy csapatként tudjanak az egyének viselkedni, közösen elfogadott közös, konkrét és mérhető célok kitűzése szükséges. Az igazi csapatban az egyes tagok háttérbe tudják szorítani saját egyéni (akár karrier) céljaikat a csapat céljai érdekében.

Hát röviden ennyit a könyv ismertetéséről, én megtaláltam benne azt amit kerestem. Akit bővebben érdekel, olvassa el, nem egy nehéz olvasmány.

Az mindenesetre érdekes, hogy mennyire láthatóan kiütköznek egyes csapatokban a fenti hibák. Konkrétan leglátványosabban a bizalom hiánya és az egyéni célok előtérbe helyezése mutatkozik meg.

Projekt kockázatok

noreply@blogger.com (Pap Tibor) — Fri, 29 Jan 2010 08:48:00 +0000

Projekt kockázatok

Tegnap láttam egy tudósítást a híradóban, ami ráirányítja a figyelmet az IT projekt kockázatkezelésének fontosságára.

Január 1-től megváltozott az anyakönyvezetés rendszere, ezért azok a szülők, akik nem házasok és nem is élnek regisztrált élettársi kapcsolatban, a korábbiaktól eltérő módon igazolhatják az apaságot és anyakönyveztethetik a gyereküket. Az új jogszabályhoz azonban nem készült el időben az informatikai rendszer, ezért a szülők nem tudják anyakönyveztetni a gyereket, így addig nem vehetik igénybe a támogatásokat, szülési szabadságot. Bővebben az esetről a következő linken: http://www.rtlhirek.hu/cikk/302029

A kockázatok kezelése érdekében első lépésként fel kell mérnünk a potenciális fenyegetéseket, bekövetkezési valószínűségüket, és azok várható hatását. A bekövetkezési valószínűséget százalékban mérhetjük, a hatás nagyságát pedig általában valamilyen előre meghatározott skálán becsüljük. Ha a médiában cikkeznek egy projekt sikertelenségéről ezen a skálán elég magasra szokták értékelni.

A kockázat súlyosságát a bekövetkezési valószínűség és a várható hatás szorzata adja meg. A kockázatokhoz kezelési terveket készítünk. A kezelési tervek a kockázat súlyosságának csökkentését célozzák, ez elérhető egyrészt a bekövetkezési valószínűség csökkentésével, másrészt a várható hatás csökkentésével. Sosem lehet azonban minden kockázatot teljesen megszüntetni, mindig lesznek maradék kockázatok.

Kicsit hasonló ez a projekt portfólió menedzsmenthez, hiszen a kockázatkezelés nyilván plusz költséggel jár, arra kell tehát törekednünk, hogy megfelelően mérjük fel a potenciális kockázatokat, a súlyosságuknak megfelelően priorizáljuk azokat, és a prioritásaik mentén döntsük el, hogy figyelembe véve a lehetőségeinket, mely kockázatok kezelésére fordítjuk szűkös erőforrásainkat.

A cél az, hogy a maradék kockázatok súlyossága a kockázattűrő képességünket ne haladja meg. Véleményem szerint, ha egy projekt sikertelensgéről és annak következményeiről az esti híradóban hallunk, az nem tekinthető elfogadható maradék kockázatnak, itt tehát valószínűleg érdemes lett volna valamilyen módon csökkenteni ennek súlyosságát.

Nézzük meg milyen terveket lehetet volna kidolgozni jelen esetben:

A fejlesztő IT cég szempontjából:

Elképzelhető, hogy már a szerződéskötés pillanatában látszik, hogy a fejlesztést nem lehet határidőre elkészíteni. Ebben az esetben lehet, hogy jobb nem elvállalni a feladatot, hiszen a médiában megjelenő hírek jelentősen rontják a fejlesztő jó hírét, ezzel súlyos károkat okozva. (Bár jelen esetben nem nevezték még meg a fejlesztőt)
Agilis fejlesztési módszertan alkalmazása. Az agilis módszertanok többek között abban segítettek volna, hogy a határidőt szentnek és sérthetetlennek tartva inkább a nem annyira lényeges követelményekből engedve a rendszer biztosan üzembe helyezhető lett volna a kitűzött határidőben. Bizonyos kényelmi funkciókat aztán meg lehetett volna valósítani a későbbiek során is.
...

Fentiek a bekövetkezési valószínűséget képesek csökkenteni jelen esetben. A fejlesztő IT cég persze nem tud tenni semmit, ha még csak most kötnek vele szerződést, és így ezután kezdi csak a munkát. Kockázat kezelésre tehát a megrendelő oldalán is szükség van:

A kockázat bekövetkezése esetén a hatás nagyságát tudja csökkenteni a megrendelő azzal, hogy felkészül arra az esetre, ha az IT rendszert nem lehet üzembe helyezni határidőre. Ebben az esetben is végre kell tudni hajtani a legfontosabb üzleti/ügyviteli folyamatokat, ehhez pedig üzletmenet folytonossági terv szükséges, ami megmondja, hogy hogyan lehet papíron, kézi munkával kiállítani a szükséges igazolásokat. Ez nyilván lassabban és kevésbé hatékonyan fog működni, de a családok legalább megkaphatják a nekik járó támogatásokat, és az eset valószínűleg nem kerül be a híradóba. (Az üzletmenet folytonossági terv a későbbiekben is jól fog jönni, ha az informatikai rendszer valamilyen okból kifolyólag működésképtelenné válik)
Körültekintő projekttervezéssel lehetne arról gondoskodni, hogy a jogszabályt csak akkor léptessék hatályba, amikorra annak feltételeit biztosítani lehet. Persze ez már vezetői, sőt jelen esetben politikai döntés, amit gyakran nagyon nehéz befolyásolni.
...

A konkrét esetről nem tudok többet, mint ami a fenti linken olvasható, ezért ez a cikk csupán a kockázatkezelés fontosságára hívja fel a figyelmet, elképzelhető hogy ebben az esetben egyébként egész más okok játszottak szerepet a végkimenetelben.

Üzleti érték az államigazgatásban

noreply@blogger.com (Pap Tibor) — Thu, 31 Dec 2009 08:06:00 +0000

Üzleti érték az államigazgatásban

Az IT Fejlesztés üzleti értéke című bejegyzésemhez érkezett egy hozzászólás az államigazgatási projektekkel kapcsolatban: "...az államigazgatási projekteket a lakossági oldalról mérném, mert -elvileg- az állampolgárokért történik minden fejlesztés." Ezzel teljes mértékben egyetértek, sőt azt gondolom, hogy a magánszférában is el kell egy kicsit gondolkodnunk azon, hogy mit is értünk üzleti érték alatt. Az előző bejegyzésben ezt a témát szándékosan kerültem, mivel így is elég hosszúra sikerült, nem akartam túlfeszíteni a húrt.

Az államigazgatásban nehéz pénzügyi megtérülést várni a projektektől, hiszen nem a profitérdekeltség hajtja ezeket a szervezeteket, bár ideális esetben jelentkezhet pénzügyi megtérülés csak éppen nagyon áttételesen, nemzetgazdasági szinten. Például az elektronikus ügyintézés bevezetése, de leginkább az adminisztráció csökkentése lebontja a gazdasági aktivitás növekedése előtt tornyosuló akadályok egy részét, ez végső soron magasabb GDP-ben és ezzel együtt magasabb adóbevételekben tükröződik.

A kérdés az, hogy miért is fektetjük be erőforrásainkat a projektjeink megvalósításába. Az nem lehet helyes válasz, hogy kizárólag a rövid távú pénzügyi megtérülés reményében, hiszen ebben az esetben valószínűleg egyszerűbb lenne a tőzsdén, vagy valamely egzotikus pénzügyi termékben megforgatni a pénzünket.

Tételezzük fel például, hogy egy bank nagyon erős a lakossági piacon, de nincs jelen a vállalati szektorban. Ez a bank úgy dönt, hogy kiterjeszti tevékenységét, és belép a vállalati szegmensbe, mivel a lakossági piacon már nem tud megfelelő növekedést elérni. Ez a döntés alkotja a bank üzleti stratégiájának egyik lábát, ha úgy tetszik ez egy stratégiai célkitűzés. A program portfólió aktualizálásakor többek között két javasalat versenyez egymással az erőforrásokért. Az egyik a lakossági piacon a bank egy már létező termékének továbbfejlesztése, a másik belépés a vállalati szegmensbe egy új termékkel. Az első javaslat valamivel jobb pénzügyi megtérülést mutat, és kevesebb kockázattal is kell számolni, hiszen meglévő termék ismert piacon áll szemben egy új termék új, ismeretlen piacra történő bevezetésével. A banknak mégis érdemes lehet előnyben részesíteni a második javaslatot, mivel az a kitűzött stratégiai cél megvalósítása irányába tett első lépésnek tekinthető. A bank pedig nyilván azért tűzte ki a stratégiai céljait, mert úgy gondolja, hogy hosszú távon így tudja biztosítani a legjobb jövedelmezőséget.

A pénzügyi megtérülés csak egy szempont a sok közül, valójában az alábbi három dimenzió mentén kell értékelnünk az előttünk álló lehetőségeket:

Illeszkedés, azaz hogyan illeszkedik a projekt a szervezet stratégiai célkitűzéseihez, vagy a tulajdonosi kör elvárásaihoz vagy a törvényi előírásokhoz stb...
Pénzügyi megtérülés
Kockázat, azaz mekkora a valószínűsége annak, hogy a kitűzött üzleti célokat valóban el is érjük.

De hogyan lehet mérni egy javasalat üzleti értékét a fenti kritériumok alapján? Nincs szükség arra, hogy megállapítsuk egy javaslat abszolút értékét. Nem arra vagyunk kíváncsiak, hogy mennyi üzleti értéket jelent számunkra egy program javaslat. A helyes kérdés ugyanis az, hogy az összes javaslat közül melyek jelentik számunkra a legtöbb üzleti értéket, tehát az egyes javaslatok relatív értékére van szükségünk annak érdekében, hogy el tudjuk dönteni, mely lehetőségekre fordítsuk a korlátos erőforrásainkat.

A relatív érték tulajdonképpen azt mutatja meg, hogy az összes lehetőség közül melyek a legfontosabb javaslatok a szervezet számára. Ennek meghatározásához szükséges módszerek rendelkezésünkre állnak, erről bővebben írtam már az AHP, illetve a Mi a fontos? című bejegyzésemben.

Visszatérve az államigazgatásra, ha a fenti három kritérium szerint értékelünk a pénzügyi megtérülés kizárólagossága helyett, akkor a javaslatok itt is összehasonlíthatóvá válnak. Semmi akadálya tehát, hogy az államigazgatási projekteket a lakossági oldalról (is) mérjük.

Az állam célkitűzései között jelenleg is szerepel az adminisztrációs terhek csökkentése annak érdekében, hogy lebontásra kerüljenek a gazdasági tevékenység előtt álló akadályok, így hozzájárulva a GDP növekedéshez. Az elektronikus ügyintézés bevezetését célzó beruházások üzleti értékét tehát a fenti stratégiai célkitűzéshez történő illeszkedés adja. Gond csak akkor van, ha kizárólag egy az ügyfélkapuhoz csatlakozó informatikai rendszer kiépítésével akarjuk letudni a feladatot. Olyan programot kell ugyanis definiálni, melynek célkitűzése az adminisztrációs teher mérhető csökkentése. Például az átlagos ügyintézési idő csökkentése 5-10 nappal, vagy a sikeresen zárult ügyek számának növekedése, vagy az ügyfél elégedettség mérhető (Pl.: elégedettségi kérdőívek segítségével) pozitív változása. Ezt pedig önmagában egy informatikai rendszer segítségével nem fogjuk elérni, ezért szükséges lehet még például:

Az érdekeltek, azaz első sorban a potenciális ügyfelek igényeinek felmérése és figyelembe vétele;
Az ügyintézési folyamat teljes felülvizsgálata, a szűk keresztmetszetek feltárása és kiküszöbölése, egyszóval egy teljes BPR;
Az ügyintézéshez szükséges adatok, igazolások szükségességének, felhasználásuk módjának felülvizsgálata (jelenleg nagyon sok ügytípus nem nyújtható be elektronikusan azért, mert eredeti igazolás szükséges hozzá, ami elektronikus formában nagyon ritkán áll rendelkezésre);
Szükség esetén jogszabályváltoztatások végrehajtása;
Mérési rendszer kialakítása, melynek segítségével folyamatosan nyomon követhető az adminisztráció mértéke, az ügyintézés gyorsasága;
Akár az ügyintézők javadalmazási és jutalmazási rendszerének átalakítása, hogy érdekeltek legyenek a gyorsabb, hatékonyabb ügyintézésben, mindez a mérési rendszerre alapozva;
Az ügyintézők továbbképzése;
És további feladatok, amiket az államigazgatás működéséhez jobban értő szakemberek tudnának meghatározni.

És ezzel máris megtettük az első lépéseket egy komplex change management program definiálása felé. Elmúlt már az az idő, amikor egy IT rendszer üzembe helyezése automatikusan üzleti értékhez juttatta a szervezetet. Ma már az IT csupán egy katalizátor, ami lehetővé teszi a hatékonyság javítása érdekében szükséges változások végrehajtását.

Az IT fejlesztés üzleti értéke

noreply@blogger.com (Pap Tibor) — Sun, 06 Dec 2009 20:12:00 +0000

Az IT fejlesztés üzleti értéke

A minap olvastam egy cikket arról, hogy egy projekt sikerét nem feltétlenül határozzák meg a szokásos mérési módszerek, vagyis, hogy határidőre költségkereten belül megvalósította-e a kitűzött terjedelembe tartozó célokat. Aztán kaptam egy másik cikket is, amely a fejlesztési projekt sikerének vagy bukásának megítéléséről szól a különböző szerepkörök nézőpntjából szemlélve a dolgokat, úgy mint:

Fejlesztő csapat: - A siker mércéje az elégedett Product Owner (scrum)
Menedzsment - A projekt addig sikeres, amíg a vevő a leszállított rendszert használja, és hajlandó finanszírozni azt.
Vevő: - Pozitív megtérülés, azaz onnantól kezdve, mikortól a szoftver kifejlesztésére fordított befektetés költségei megtérülnek és elkezd hasznot hajtani, a projekt sikeres

Ez mind nagyon jól hangzik, de úgy vélem, érdemes egy kicsit tovább gondolni a vevő, egészen pontosan a szoftverfejlesztésbe beruházó cég menedzsmentjének a szempontja mögé. A menedzsment szemében minden projekt egy befektetés, és a befektetéseinktől természetesen megtérülést várunk el. De tudunk-e válaszolni az alábbi kérdésekre:

Megtérül-e egy CRM rendszer kifejlesztésére és bevezetésére fordított költség a rendszer üzembe helyezésekor?
Megtérül-e az államigazgatás számára egy egyablakos elektronikus ügyintézést lehetővé tevő informatikai rendszer kifejlesztése a rendszer üzembe helyezésekor?
Megtérül-e egy projekttámogató informatikai rendszer bevezetése a rendszer üzembe helyezésekor?
Megtérül-e egy vállalati intranet portál kialakítása és bevezetése a rendszer üzembe helyezésekor?

Amikor az informatikai fejlesztési projekt lezárul, azaz leszállította a célként kitűzött informatikai rendszert minden szereplő megelégedésére, a megtérülés még hátra van, vagyis a menedzsment elégedettsége még korai lenne. Nem dőlhetünk tehát hátra a székünkben, sőt tovább megyek, önmagában az informatikai rendszer leszállítása és üzembe állítása szükséges, de nem elegendő ahhoz, hogy sikert érjünk el. Ha sikert akarunk elérni, akkor további projekteket kell sikerre vinnünk, ezek azonban nem informatikai projektek lesznek, hanem olyan projektek, melyek a vállalat működésének megváltoztatására irányulnak.

Milyen megtérülést várhatunk például önmagában egy projekttámogató informatikai rendszer bevezetésétől. Ettől még a projektvezetőink nem lesznek jobb projektvezetők, a projekttagok sem fognak jobban dolgozni, maximum a rendszerből kinyerhető információk segítségével a vezetés jobban képbe kerülhet az aktuális helyzettel kapcsolatban. Ha eredményt akarunk elérni, szükség lehet egy projektmenedzsment módszertan bevezetésére, mely meghatározza a felelősségeket, folyamatokat. Ez együtt jár adott esetben szervezeti változásokkal, kialakítható egy projektiroda, mely többek között azért felelős, hogy folyamatosan fejlődjön a projektmenedzsment tevékenység a vállalaton belül. A projektvezetők számára képzésekkel egybekötött fejlődési lehetőséget, karrierutat kell felmutatni... Hopp, észre sem vettük, és máris ott tartunk, hogy egy szimpla informatikai projekt helyett szervezeti változásról, egy komplex változás menedzsment programról beszélhetünk, annak minden velejárójával együtt.

A megtérülést vagy méginkább az üzleti értéket tehát attól a szervezeti működési változtatástól várhatjuk, amit az informatikai fejlesztésre támaszkodva tudunk végrehajtani.

Erről a témáról szól John Thorp The Information Paradox című könyve. A könyvben vázolt módszertanra építve az ISACA és az ITGI a szerző közreműködésével dolgozta ki a ValIT keretrendszert. A könyvben Thorp az informatika fejlődését három nagy szakaszra osztja:

Automatizálás: Az informatikai rendszerek segítségével a munkafolyamatokat automatizálják. Ilyen például egy iratkezelő rendszer, egy könyvelő vagy bérszámfejtő program. A munka automatizálás jellegű IT beruházások jellemzői:

A szervezetben a munkát továbbra is ugyanúgy hajtják végre, nagyrészt változatlanok az üzleti folyamatok, csupán amit eddig papíron végeztek, azt innentől számítógépen végzik.
A siker érdekében elég a felhasználóknak elsajátítaniuk az IT rendszer használatát, más változás nem nagyon van a cég életében.
Az IT projekt célja a működési hatékonyság javítása, a stratégiai érintettség elenyésző
Az ilyen jellegű IT beruházások jellemzően a vállalat egy adott szervezeti egységét érintik csupán, nem terjednek ki a teljes vállalati szintre (Pl.: Bérszámfejtő program a HR, Könyvelő program a számvitel szintjén áll meg)
Ha jó IT rendszert sikerül csinálni, azaz sikeres az IT projekt, üzembe helyezik, tulajdonképpen a kitűzött üzleti érték elérése biztosítva van.

Információ menedzsment: A folyamatok automatizálása során olyan információk halmozódtak fel az azt támogató informatikai rendszerekben, melyek korábban elképzelhetetlenek voltak. Ezekra az információkra alapozva olyan fejlesztéseket lehet megvalósítani, melyek már nem egyszerűen automatizálnak, hanem megváltoztatják a folyamatokat is. Az információkra támaszkodva üzleti döntéseket lehet hozni, melyek befolyásolják a vállalat működését.

Például egy CRM rendszer nem csak arra használható, hogy vezérelje az ügyféllel való kapcsolattartás folyamatát, hanem a CRM rendszerben felgyülemlő információk alapján feltárhatók többek között a keresztértékesítési lehetőségek (Sőt sokkal inkább erre való, mintsem a folyamat vezérlésére). Az információ menedzsment jellegű IT fejlesztések jellemzői:

Az IT fejlesztés szerepe csökken, az IT fejlesztés mellett szükség van más, nem IT jellegű projektek végrehajtására is.
Nem elegendő megtanulni az informatikai rendszer használatát, tudni kell élni azzal az információval, amit a rendszer nyújt és tudni kell ezek alapján megfelelő döntéseket hozni.
Megváltozik a munkavégzés módja, nem egyszerűen ugyanazt csináljuk, amit korábban papíron. Változnak a folyamatok, nem lehet automatikusan és szigorúan az előre megtervezett folyamatok mentén dolgozni, az információk birtokában minden szinten folyamatosan döntéseket kell hozni.
A változás sokkal kiterjedtebb, általában átlépi a szervezeti egységek határait is.
Fentiekből kifolyóan a bevezetés során nem elegendő egy informatikai rendszer használatának oktatására koncentrálni, elő kell segíteni a gondolkodás megváltozását is. A változásban már érintett a szervezeti kultúra is.

Üzleti transzformáció (Business Transformation): Az üzleti transzformáció során pedig olyan informatikai megoldásokat vezetünk be, melyek segítségével alapvetően változtatjuk meg azt az üzleti játékteret, ahol a vállalat működik. Az üzleti transzformáció jellegű IT fejlesztések jellemzői:

Nem az IT fejlesztésé a főszerep, az legfeljebb egy katalizátor, ami elősegíti, támogatja az új működés kialakítását (angol kifejezéssel élve ez egy IT enabled change)
Egy ilyen változtatás elindítása egyértelműen stratégiai döntés, a stratégia jelentősége sokkel nagyobb, mint az IT jelentősége.
A változás nagy kiterjedésű, ami azt jelenti, hogy nem áll meg egy szervezeti egység szintjén, sőt, akár egy egész iparágra kiterjedhet. Ugyanakkor a változás nemcsak arra van hatással, ahogyan a munkatársak ellátják a feladataikat, hanem arra is, hogy mi a feladatuk.
Fentiekből következően nem elegendő egy IT rendszer használatára megtanítani a felhasználókat, hanem új feladatok elvégzésére, új gondolkodásmódra van szükség, ami egyértelműen szervezeti kultúra változással jár együtt. A szervezeti kultúra változáshoz sok idő és energia szükséges.
A jó IT rendszer leszállítása, azaz a sikeres IT projekt nem elégséges a sikerhez, ahhoz további nem IT jellegű projekteket kell végrehajtani. Az eredmények nem fognak jönni maguktól, ha üzembe helyezzük az IT rendszert.
Például a Just In Time módszerek bevezetéséről az autóiparban senki nem gondolhatja, hogy sikerült volna, ha csupán egy jó JIT IT rendszert fejlesztenek. Ehhez át kellett alakítani a logisztika teljes működését, raktárakat szüntettek meg, átszervezték a gyártási folyamatokat, sőt új szerződéseket kellett kötni a beszállítókkal. Mindez azt eredményezte, hogy a beszállítóknak tulajdonképpen egy teljesen új üzleti modell szerint kellett szolgáltatniuk az autógyártók felé. A változás tehát nem IT központú volt, nem állt meg egy szervezeti egység határainál, sőt kiterjedt a vállalat határain túlra a teljes beszállítói láncolatra is, valójában egy egész iparágat átdefiniált.

De milyen hatással kell legyen mindez a projekt és portfólió menedzsmentre? Talán a projektmenedzsmentre nem kell, hogy különösebb hatással legyen. A projektvezetőknek továbbra is az a feladata, hogy határidőre költségkereten belül leszállítsa a célként kitűzött termék(ek)et, legyen az IT projekt vagy mondjuk HR projekt.

A projektmenedzsment felett azonban meg kell jelennie a program menedzsment funkciónak is. Sikereket úgy érhetünk el, ha az IT projekt mellett végrehajtjuk mindazokat a nem IT projekteket is, amik a változás végigvitele érdekében szükségesek. Az üzleti érték nem keletkezik automatikusan egy projekt zárásakor, a program menedzsment funkciónak ezért az a feladata, hogy az ötlet felmerülésétől kezdve az üzleti érték megteremtéséig bezárólag vigye sikerre a programot. Nem egyszerűen arról van tehát szó, hogy több projektet összefogunk és kezeljük az összefüggéseket. A program menedzsment funkció minőségileg is különbözik a projektmenedzsmenttől nem csak mennyiségileg.

A portfólió menedzsmentben az egyik legfontosabb változás, hogy nem a projektek szintjén kell döntéseket hozni, a feladat nem az ideális projekt portfólió összeállítása és fenntartása, hanem az ideális program portfólió összeállítása és fenntartása.

Az üzleti környezet folyamatosan változik egy program teljes időtartama alatt, továbbá az induláshoz képest folyamatosan egyre több és pontosabb információnk van arról a változásról, amit a program megcéloz, és a várható üzleti értékről. Fentiekből kifolyóan egy program sorsáról nem lehet egyszer, az induláskor dönteni, rendszeres felülvizsgálatra van szükség az új információk birtokában.

Ahhoz, hogy a mai kihívásoknak megfeleljünk, át kell tehát alakulnia a portfólió menedzsmentről való gondolkodásunknak, a projekt és portfólió menedzsmentért felelős szervezeti egységeknek, be kell vonni a felső vezetőket, hiszen stratégiai döntések csak az ő szintjükön születhetnek. Ez az alkalmazkodás ha úgy vesszük szintén egy üzleti transzformáció, nyilvánvalóan nem lehet tehát egy projekt és portfólió menedzsment informatikai rendszer bevezetésével elintézni.

Projekt Portfolió Menedzsment

noreply@blogger.com (Pap Tibor) — Fri, 02 Oct 2009 09:56:00 +0000

Szinergia cikk a Projekt Portfolió Menedzsmentről

Az alábbi cikk jelent meg a legfrissebb Szinergia újságban a Projekt Portfolió Menedzsmentről:

Projekt Portfolió Menedzsment

Ha azt halljuk projekt, általában az első, ami eszünkbe jut, a cél, határidő, költség hármasa. Akkor tekintünk sikeresnek egy projektet, ha e hármas korlát mindegyike teljesül, ennek felelősségét pedig a projektvezetők veszik a vállukra. Annak érdekében, hogy ezt sikerrel teljesítsék, rengeteg eszköz áll rendelkezésükre a különböző praktikáktól, módszertanoktól kezdve a projekttervezést és nyomon követést támogató szoftverekig.

Az elmúlt évek során mi is számos esetben segítettük a Synergon ügyfeleit a projektekkel kapcsolatos problémáik megoldásában azzal, hogy ezt támogató informatikai megoldásokat vezettünk be a szervezetben. Ezek a megoldások lehetővé teszik a projektek egységes elvek szerinti tervezését, a humán erőforrás konfliktusok előre jelzésével a proaktív beavatkozást, a vezetés számára pedig naprakész, megbízható információkat szolgáltatnak a projektek előrehaladásáról.

Ezek a projektmenedzsment technikák és eszközök azt szolgálják, hogy a projekt megvalósítására fordított erőforrásainkat a terveknek megfelelően, hatékonyan hasznosítsuk a célok érdekében. Abban az esetben azonban, ha a megvalósításra kerülő projekt a szervezet számára nem a megfelelő projekt, a hármas kritérium rendszer leghatékonyabb kezelése ellenére is pazarlás minden forint és minden emberóra, amit az adott projektre fordítunk. Ezzel pedig máris áteveztünk a projekt portfolió menedzsment (PPM) vizeire.

A vállalat tulajdonosai és felső vezetői számára minden projekt egy befektetés, melyhez pénzt és erőforrást biztosítanak, cserébe pedig valamely üzleti cél elérését várják el. Az erőforrások azonban mindig korlátosan állnak rendelkezésre, ezért kell nagy figyelmet fordítanunk arra, hogy a szervezet céljainak megfelelő projekt portfoliót tartsunk fenn. A PPM hiányának egyik legfontosabb jele általában az, hogy a szervezetben burjánzanak a projektek, a nagy és fontos projektek gyakran azért csúsznak vagy buknak el, mert kevésbé fontos feladatokon dolgoznak a kollégák, azaz a szervezet képtelen megfelelően fókuszálni erőforrásait. A PPM arra koncentrál, hogy olyan projekt portfoliót tartsunk fenn, mely maximális mértékben hozzájárul a szervezet hosszú távú sikerességéhez. Az ideális portfolió:

Támogatja a vállalat céljainak elérését, azaz, a projektek összhangban vannak a stratégiai célokkal;
A befektetéseinktől megtérülést várunk, tehát közvetlenül vagy közvetve, de a projektek is pozitív eredményt mutatnak fel;
A céloknak és a prioritásoknak megfelelően, hatékonyan hasznosítja a rendelkezésre álló erőforrásokat;
Kockázatai összhangban vannak a szervezet kockázattűrő hajlandóságával;

Leegyszerűsítve tehát a PPM a megfelelő projektek kiválasztásáról és a portfolió folyamatos nyomon követéséről, felülvizsgálatáról szól, amibe természetesen beletartozhat a nem megfelelően teljesítő, vagy okafogyottá vált projektek leállítása is. Mire van szükség a PPM sikeressége érdekében?

Menedzsment: A befektetési döntések felelősségét egyértelműen a vállalat menedzsmentjének kell felvállalnia, ezért az ő aktív részvételük feltétlenül szükséges a PPM működéséhez.
Módszerek: A nemzetközi gyakorlatban elterjedt értékelési módszerek például a különböző megtérülési számítások (NPV, ROI), kockázat értékelő, illetve döntéstámogató eljárások, mint például az Analytic Hierarchy Process (AHP) állnak rendelkezésünkre. Ezek közül minden szervezet kiválaszthatja a számára legmegfelelőbbet.
Informatikai támogatás: Ma már elérhetőek olyan PPM szoftver csomagok, melyek a fenti módszerekre támaszkodva, például „mi lenne ha” elemzésekkel, diagramokkal segítik összevetni a szóba jöhető portfoliók hatását a vállalati stratégiára, így támogatva az optimális, kiegyensúlyozott projekt portfolió összeállítását. Ezek a megoldások átlátható módon biztosítanak naprakész információkat a portfoliót alkotó projektek teljesítményéről, ami alapján a rendszeres felülvizsgálat során meghozhatók a további döntések is.

A Synergon az évek során felhalmozott tapasztalatokkal, bevált bevezetési módszertannal, és többirányú gyártói kapcsolatainak köszönhetően a vezető PPM eszközök képességeinek ismeretével tudja segíteni Ügyfeleit a projektmenedzsment és projekt portfolió menedzsment problémák megoldásában.

Felsővezetői részvétel

noreply@blogger.com (Pap Tibor) — Fri, 11 Sep 2009 14:32:00 +0000

A Projekt Portfolió Menedzsment nem működik, ha nincs meg a felső vezetés támogatása, sőt, nem elég a támogatás, aktív részvételre van szükség. A Projekt Portfolió Menedzsment célja a vállalat erőforrásainak hatékony, megtérülő befektetése a stratégiai célok elérése érdekében. Márpedig az ilyen befektetési döntésekért a felelősség egyértelműen a felső vezetésé.

De hogyan lehet szemléletesen bemutatni a megfelelő Portfolió Menedzsment módszerek alkalmazásának szükségességét, ha a vezetők nincsenek erről meggyőződve. Erre egy jó példa a Crompton Corporation-nál alkalmazott módszer.

A Crompton Corporation egy az olajiparban tevékenykedő vállalat, 1995-ben az elsők között vezetett be Projekt Portfolió Menedzsment megoldást. Az induláskor azonban nem volt minden vezető számára egyértelmű ennek szükségessége. A technológiai oldal vezetői tisztában voltak vele, hogy valamit tenni kell, ami nem csoda, hiszen rajtuk csattant az ostor, nekik kellet kiszolgálni a folyamatosan burjánzó fejlesztési igényeket. Vajon hogyan tudták meggyőzni a többi vezetőt?
Tartottak egy portfolió review-t külső helyszínen, egy szállodában. Ott volt a divízió vezetője az üzleti és a technológiai menedzserek. Egy táblára felragasztottak pontosan 52 db papírt, melyek mindegyike egy futó projektet, vagy projektjavaslatot reprezentált. Minden papírra felírták az adott projekt erőforrás igényét. Minden jelen lévő zsetonokat kapott, melyekre az ő embereinek a monogramja volt felírva. Minden zseton 1 emberhónap munkát jelentett, így emberenként 12 db zsetont kaptak. Ezután megkérték a vezetőket, hogy helyezzék el zsetonjaikat a projekteket reprezentáló papírokon úgy, hogy lehetőleg minden projektet meg lehessen valósítani.
Végül alig a projektek negyedét sikerült teljes egészében ellátni a megfelelő mennyiségű zsetonnal, mielőtt azok elfogytak volna. A megbeszélés végére mindenki számára világos lett, hogy ennyi projekt megvalósítására képtelen lesz a szervezet, ezért a szűkös erőforrásokat koncentrálni kell a valóban fontos projektek megvalósítására.
Azt gondolom ez mindenféle számítógépes chartok és adatsorok nélkül, kellőképpen szemléletes és világos bemutatása volt annak, hogy miért van szükség a projekt portfolió menedzsmentre. A Crompton azóta is, most már több mint 10 éve a felső vezetők teljes támogatásával és részvételével sikerrel alkalmazza az akkor bevezetett megoldásokat.

A Crompton Corporation teljes esettanulmánya elolvasható Harvey A. Levine Project Portfolio Management című könyvében.

Analytic Hierarchical Process (AHP)

noreply@blogger.com (Pap Tibor) — Mon, 20 Jul 2009 11:07:00 +0000

Analytic Hierarchical Process (AHP)

Korábbi bejegyzésemben bemutattam, hogyan lehet priorizálni stratégiai céljainkat annak érdeklben, hogy fel tudjuk állítani a projektjavaslatok közti prioritási sorrendet. Az ott bemutatott módszer a Microsoft Project Portfolio Server-ből származik, azonban természetesen a fejlesztők sem a spanyol viaszt találták fel, csupán alkalmazták amit mások már kitaláltak. Ez pedig nem más, mint az Analytic Hierarchic Process (AHP), mely kiválóan alkalmas komplex döntési helyzetek feloldására, amikor több kritérium szerint kell értékelni az alternatívákat. Ilyen lehet egy autó vásárlás, lakás vásárlás, vagy akár projektjavaslatok kiválasztása. A módszer lényege:

A döntési helyzetet egy hierarchiaként ábrázoljuk, melynek csúcsa a cél, ezt bontjuk tovább 1 vagy több szinten döntési kritériumokra. A hierarchia alján az egyes alternatívák álnak.
Páros összehasonlítással priorizáljuk a kritériumokat, így állítjuk fel a kritériumok prioritási sorrendjét
Az egyes alternatívákat is a páros összehasonlítás módszerével értékeljük minden egyes döntési kritériumra vonatkozóan
Végül felállítjuk az egyes alternatívák sorrendjét

Bővebben nem írnám le a módszert, a wikipedián kitűnően le van írva, ott egy példán keresztül részletesen be is mutatják, hogyan alkalmazható. Itt pedig található egy online tutorial és egy Excel tábla is, amely a kiértékeléseket és a prioritási értékek felállítását segíti.

A Project Portfolio Server kissé leegyszerűsíti a módszert, ugyanis az egyes alternatívák kiértékelésekor már nem alkalmazza a páros összehasonlítást, de alapvetően e szerint működik a stratégiai célok és a projektjavaslatok priorizálása.

A műtét sikerült

noreply@blogger.com (Pap Tibor) — Thu, 16 Jul 2009 06:14:00 +0000

A műtét sikerült, a beteg meghalt

Sokszor hallom idézni a különböző felméréseket, melyek arról szólnak, hogy a projektek milyen arányban voltak sikeresek vagy sikertelenek az elmúlt időszakban. Legutóbb például a 2009-es Chaos report kapcsán, mely szerint az IT projektek mindössze 32%-a volt sikeres az elmúlt 1 évben.

Egyből felmerül azonban a kérdés, hogy mit is tekintünk sikeres projektnek? A Chaos report szerint például az az IT projekt a sikeres, mely a kitűzött költség keretek között, határidőre befejeződik, és leszállítja a követelményekben előírt funkciókat. Igen, általában így szokták mérni a projekteket: cél, költség, határidő. A költség és a határidő jól definiálható, de mi a helyzet a céllal?

Tegyük fel például, hogy indítunk egy projektet egy új vírusvédelmi rendszer bevezetésére. A projekt sikeresen lezárul, vagyis, minden számítógépre telepítve lett a megfelelő szoftver a megfelelő beállításokkal, mindezt határidőre és az előre kitűzött költségkeretek között. Fentiek alapján ez a projekt sikeres volt. Fél évvel a projekt zárása után a vállalat vezetői elemzik az informatikai biztonsági helyzetet, és azt tapasztalják, hogy a várttal szemben nem csökkent a vírus incidensek száma. A műtét sikerült, a beteg meghalt.

A fenti példa azt mutatja, hogy a célokat több szinten lehet és kell értelmezni:

Üzleti cél (az angol terminológiában goal): Az üzleti cél magas szinten fogalmazza meg azt a problémát, elérendő célt amiért a projektet létrehozzuk. Például lehet az üzleti célunk: a vállalat projektjeinek hatékonyabb megvalósítása (alacsonyabb költséggel, gyorsabban, jobb eredménnyel). Az üzleti célra jellemző:

Magas szintű, ennek megfelelően nem feltétlenül egy db projekt indításával tudjuk elérni. A fenti üzleti cél érdekében például indíthatunk projektet projektmenedzsment módszertan bevezetésére, képzésre vagy informatikai rendszer bevezetésére is.

Az üzleti cél üzleti előnyök elérésére törekszik (hatékonyság növelés, pénzbeli előny...)

Általában nem, vagy nehezen mérhető

Projekt cél (az angol terminológiában: objective): A projektcél konkrét célkitűzés, ami meghatározza, hogy a projekt mit akar elérni. A projektcél alacsonyabb szintű, konkrétabb mint az üzleti cél, és a projekt befejezésekor egyértelműen eldönthető, hogy sikerült-e elérni. Általában a projektcélból kiindulva egyértelműen meghatározhatóak azok a leszállítandók, amit a projektnek nyújtania kell. Amennyiben ez nem határozható meg a projektcélból, akkor túl magas szinten definiáltuk a célt. Amennyiben viszont a leszállítandó termékek jellemzőit is rögzíti a projektcél, túl mélyen definiáltuk a célt, így azok már nem célok, hanem követelmények. A fenti példánál maradva ilyen projektcél lehet például a projektmenedzsment támogató informatikai rendszer bevezetése.

A projekt sikerességének megítélésekor tehát nem elegendő csak a projektcélokkal foglalkozni, az üzleti célok teljesülését is ellenőrizni kell. Ugyanígy, ha egy projekt életében változáskezelés szükséges, érdemes megvizsgálni, hogy a változás nem veszélyezteti-e az üzleti célok elérését, hiszen csak ebben az esetben van értelme a projekt folytatásának a megváltozott feltételekkel.

A projekt, mint befektetés

noreply@blogger.com (Pap Tibor) — Fri, 03 Jul 2009 13:05:00 +0000

Az embernek a megtakarított pénzével kezdeni kell valamit (már azon szerencséseknek, akiknek van J ). Ilyenkor mérlegelni kell a különböző lehetőségeket, és dönteni kell az ideális befektetésről. Van, aki a tőzsdére viszi, van, aki állampapírt vesz és van, aki bankbetétbe teszi a pénzét. A döntést többnyire a várható hozam és saját hozamelvárásunk alapján hozzuk. Mérlegeljük, mennyi pénzt kell betennünk, mennyi pénzt fogunk várhatóan visszakapni, és mikor juthatunk a pénzünkhöz.

A vállalat életében egy projekt elindítása ugyanilyen befektetés. A vállalat beteszi a pénzét a projektbe a várható megtérülés érdekében, a döntés tehát ugyanígy a várható hozam és a vállalat hozamelvárásának figyelembe vételével kell, hogy történjen. A várható hozam kifejezésére a nettó jelenértéket szokták használni, mely figyelembe veszi, hogy a kiadások és bevételek nem egy időpontban keletkeznek.

A várható hozam azonban önmagában még kevés a döntéshez, hiszen ha így lenne, akkor mindenki nagy tőkeáttétel mellett határidős pozícióba tenné az összes megtakarítását, hiszen nagyjából így lehet a legnagyobb hozamokat elérni. Azonban mérlegeljük a befektetésünk kockázatát is, hiszen a várható hozam nem biztos, hogy bekövetkezik, a pénzünket akár el is veszíthetjük. Ha korrekt döntést akarunk hozni, a várható hozamot tehát korrigálnunk kell a projekt kockázataival is, hiszen a projekt bukása, vagy a nem megfelelő eredmény előállítása ugyanúgy a projektbe fektetett pénzünk részleges vagy teljes elvesztéséhez vezet. A kockázatok értékelésénél figyelembe kell vennünk a negatív esemény bekövetkezésének valószínűségét, és az ebből eredő várható veszteséget.

Akkor most vizsgáljuk meg a projektportfoliót és dobáljuk ki az összes kockázatos projektet? Nem mindenkinek azonos a kockázattűrő képessége. Van, aki csak bankbetétben hajlandó tartani a pénzét, és van, aki nem riad vissza a határidős piactól, vagy az összetettebb származtatott termékektől sem a magasabb hozam reményében. Azt azonban mindenképpen kijelenthetjük, hogy a magasabb kockázat vállalásáért cserében magasabb hozamot várunk el, ez a kockázati felár (Elég sokat hallhatjuk ezt a fogalmat manapság a Magyar államkötvények és a jegybanki alapkamat kapcsán L).

Azonban a kockázatokat kedvelő és magas haszonra törekvő befektetők sem kizárólag magas kockázatú befektetéseket tartanak a portfoliójukban, hanem törekednek a számukra megfelelő mix összeállítására. Ennek alapját Harry Markowitz
Modern Portfolio Theory elmélete alapozza meg. Bár az elmélet csak korlátok közt alkalmazható projektekre, azért az igaz, hogy alapvetően az egyes projektek kockázata helyett, az egész projekt portfolió számunkra ideális kockázati szintjére kell törekednünk. Amennyiben a portfolióban van 1-2 az elfogadhatónál magasabb kockázati értéket képviselő projekt, a portfoliót ki lehet egyensúlyozni alacsonyabb kockázati értékű projektek beválasztásával.

A Business Case

A profi befektetőknek rengeteg eszköz áll rendelkezésükre, hogy értékeljék a különböző vállalatok részvényeit. A tőzsdei cégek kiadják negyedéves jelentéseiket, az elemzők fundamentális és technikai elemzéseket tesznek közzé. A projektek esetében a Business Case szolgáltatja mindazokat az információkat, ami alapján a döntést meghozhatjuk. Sajnos nagyon gyakran a business case-t egyszerűen nem veszik elég komolyan. Az igazat megvallva sok esetben jómagam is úgy tekintettem erre, mint egy űrlapra, amit valakinek ki kell töltenie, tovább kell küldenie, ahhoz, hogy megkapja az aláírást és elindulhasson a projekt. Pedig a korrekt business case az, ami megalapozza a döntést a projekt indításakor, és a későbbiek során pedig ez segít eldönteni, hogy teret engedhetünk-e a projektben óhatatlanul bekövetkező változásoknak. A business case-nek 4 fő kérdésre kell választadnia:

A megfelelő dolgokat csináljuk? (Stratégia) A befektetés összhangban van a stratégiánkkal, optimális értéket termel elfogadható költséggel?

A megfelelő módon csináljuk? (Architektúra) Beleillik a megoldás a vállalati architektúrába? (A folyamatok, emberek, technológiák)

Meg tudjuk csinálni? (Végrehajtás) Van elég tudásunk, erőforrásunk, pénzünk, stb… hogy a tervezett képességeket kifejlesszük?

El fogjuk érni a kívánt hasznot? (Érték) A várható haszon egyértelmű és mérhető meghatározása

A business case struktúrájáról és elkészítésének módjáról az IT Governance dolgozott ki kifejezetten IT befektetésekre vonatkoztatva egy keretrendszert.

Mi a fontos?

noreply@blogger.com (Pap Tibor) — Wed, 01 Jul 2009 12:25:00 +0000

Korábbi bejegyzésekben írtam arról, hogy a portfoliómenedzsment feladata egyrészt az optimális projektportfolió kiválasztása, másrészt a kiválasztott projektportfolió végrehajtásának nyomon-követése. A kiválasztás során az egyik szempont az, hogy a szűkös erőforrásainkat a fontos dolgokra koncentráljuk. De mik azok a bizonyos fontos dolgok?

A projektportfoliónk létrehozásának és végrehajtásának célja tulajdonképpen a szervezet operatív működésének megváltoztatása, vagyis a szervezet stratégiai céljainak elérése. Fentiek alapján azt mondhatjuk, hogy olyan projektek megvalósítására szeretnénk felhasználni az erőforrásainkat, melyek közvetlenül vagy közvetve a stratégiában megfogalmazottak elérését támogatják. A projektek priorizálása során tehát ez lesz az egyik szempont. Ahhoz, hogy ezt végre tudjuk hajtani, mérhető stratégiai célokat kell kitűznünk, és egyértelműen meg kell tudnunk mondani, hogy egy adott projekt végrehajtása milyen mérhető eredményeket fog hozni ezen területeken.

Végső soron minden profitorientált szervezet ugyanarra törekszik, vagyis a profitját szeretné maximalizálni. Azonban minden vállalat más és más úton próbálja ezt elérni, hiszen más a történelmük, kultúrájuk, mások az erősségeik gyengeségeik, így mások a lehetőségeik is. Ha összevetjük például a Sony és az Orion márkákat mondjuk a szórakoztató elektronikai termékek piacán, azt látjuk, hogy a Sony a magasabb minőségű, élvonalbeli technológiákat alkalmazó, magasabb árkategóriájú termékekkel van jelen, míg az Orion az olcsó kategóriában versenyez. Mindkettejük célja a profitmaximalizálás, de más úton érik ezt el. Milyen hatással kell lennie ennek a különbségnek a két vállalat projekt portfoliójára? A Sony valószínűleg nagyobb hangsúlyt fektet termékfejlesztésre, az új technológiák kutatására és alkalmazására, míg az Orion erre kevésbé pazarolja szűkös erőforrásait, inkább a gyártásoptimalizálás, a költséghatékonyság javítása a célja, és ilyen projektekbe fektet be, hiszen olcsó termékeket kell előállítania nagy tömegben.

Példák a célokra:

A piacon kiemelkedő minőséget szállítani;
Belépés új piacokra, új termékekkel;
Munkavállalói fluktuáció csökkentése;
Költségek csökkentése, hatékonyság növelés;
…

Fontos, hogy ezek a célok mérhetőek legyenek. Például az új piacokra való belépés esetén mérhető, hogy egy adott új piacon vagy piaci szegmensben mekkora bevétele keletkezett a társaságnak egy adott időszakban. Így az erre irányuló termékfejlesztési projektjavaslatok felszínre kerülésekor lehet becsülni, hogy mekkora bevétel növekedés várható, vagyis mennyire támogatja az adott stratégiai célt, másrészt a projekt megvalósítása után visszamérhető, hogy milyen mértékben teljesültek ezek a célok.

Ha a célokat arra akarjuk használni, hogy ezek mentén felállítsuk a projekt prioritásokat, akkor először is maguk a célok közt kell meghatároznunk a prioritásokat. Erre alkalmazható például a páros összehasonlítás módszere:

Forrás: Microsoft Office Project Portfolio Server

Minden egyes célt összehasonlítva megadjuk, hogy melyik fontosabb a másiknál, ebből generálható egy prioritási lista. A priorizált célrendszerhez mérhetjük ezután a projektjavaslatokat, vagyis amelyik projektjavaslat egy magasabb prioritással rendelkező célt támogat, az magasabb prioritással fog rendelkezni.

Cél prioritási lista, forrás: Microsoft Office Project Portfolio Server

A páros összehasonlításból következően elképzelhető, hogy a prioritási listánk nem lesz konzisztens, hiszen mondhatjuk azt, hogy A fontosabb B-nél, B fontosabb C-nél és C fontosabb A-nál. A döntésünkben tehát nem önellentmondás lehet. Az ilyeneket ki kell szűrnünk. Ugyanakkor az egyes célok fontosságáról a vállalat vezetőinek eltérő véleménye lehet, ezt összhangba kell hozni.

Azért állítottuk fel a priorizált célrendszert, hogy a projektjavaslatokat fontossági sorrendbe tudjuk tenni, ehhez az kell, hogy minden egyes projektjavaslatot megvizsgáljunk, milyen mértékben járul hozzá egy adott stratégiai célkitűzés megvalósulásához.

Forrás: Microsoft Office Project Portfolio Server

Miután a projektjavaslatokat összemértük a stratégiai céljainkkal már kialakul egy egy projekt prioritási lista. Ez a sorrend azonban még csak a stratégiai célok támogatását vette alapul, más tényezőket nem. Például két azonos célokat támogató projekt közül nyilván azt fogjuk kiválasztani, amelyik ezt alacsonyabb költséggel, és kevesebb kockázattal tudja elérni. A prioritási listánk tehát még további szempontokkal finomítható.

Fenti módszerekben természetesen felfedezhető a szubjektivitás. Az adott stratégiai célokat szubjektív megítélése szerint az egyik vezető így priorizálja, a másik pedig úgy. A projekt célokkal való összevetéskor is elkerülhetetlen a szubjektív megítélés még akkor is, ha igyekszünk számszerűsíthető célokat kitűzni. Ezek a módszerek természetesen nem képesek ezt teljes mértékben kiszűrni. Mondjuk 100 projektjavaslat prioritási sorrendbe állítása fenti módszerek nélkül azonban még nehezebb lenne, és még kevésbé lehetne ezt objektíven végrehajtani. Összességében azt gondolom, ezek a módszerek egyszerűsítik a feladatok, és habár megszüntetni nem tudják, de mindenképpen csökkentik a szubjektivitást is.

Válasszunk okosan!

noreply@blogger.com (Pap Tibor) — Wed, 24 Jun 2009 10:35:00 +0000

Miután látjuk, hogy a megfelelő projektek kiválasztása és következetes végrehajtása rendkívül fontos a szervezet életében, hiszen ez jelenti az egyik kulcsot a stratégia sikeres megvalósításához, természetesen jelentkezik az igény, hogy akkor próbáljunk meg mindent megtenni annak érdekében, hogy jó, megalapozott döntéseket hozzunk.

Nézzük meg, milyen szempontokat érdemes figyelembe venni:

Koncentráljuk erőforrásainkat az igazán fontos dolgokra. Lefordítva, olyan beruházásokat hajtsunk végre, melyek összhangban vannak a kijelölt stratégiával;
Vegyük figyelembe a várható megtérülést, vagyis mind a pénzügyi és nem-pénzügyi hasznot is, melyet az adott beruházás megvalósítása hozni fog;
Ne fektessük erőforrásainkat kockázatos beruházásokba, ha a céljainkat kisebb kockázatok mellett is el tudjuk érni. Itt figyelembe kell venni a megvalósítási kockázatot (sikerül-e befejezni a projektet), illetve annak kockázatát is, hogy esetleg egy sikeresen befejezett projekt mégsem hozza azt a hasznot, amit vártunk, vagy mégsem visz bennünket közelebb a stratégia megvalósításához;
Vannak bizonyos kötelezően végrehajtandó beruházások, amiket nem hagyhatunk ki. Pl.: Egy bankot a felügyelet felszólíthatja bizonyos fejlesztések végrehajtására;
Olyan projekt portfoliót állítsunk össze, melyet meg is tudunk valósítani, azaz van rá elegendő pénzünk, és rendelkezésünkre áll a szükséges szakmai kompetencia (akár cégen belül, akár a piacon megvásárolva)

Legegyszerűbb esetben egy kisvállalat vezetőjének kell két beruházási lehetőség között választani. Ebben az esetben arra törekszik mindenki, hogy lehetőleg minden releváns információt beszerezzen a lehetőségekről, mérhető módon összehasonlít, majd továbbmegy valamelyik irányba. Már ez a helyzet is okozhat azonban bonyodalmakat, hiszen gyakran almát kell hasonlítani a körtével.

Más esetben azonban tovább bonyolódik a helyzet, mivel több lehetőség közül kell választanunk, másrészt többen is beleszólnak a végső döntés meghozatalába. Ilyenkor gyakran az "erősebb kutya ugat" elv alapján dől el, hogy melyik javaslatok kerülnek megvalósításra.

Az Erősebb kutya helyzet elkerülése érdekében egy olyan keretrendszer alkalmazása lehet indokolt, mely a fenti szempontok figyelembe vételével lehetőleg a szubjektivitás csökkentésével segít eldönteni, hogy mely projektjavaslatok kerüljenek megvalósításra.

Nagyvállalati projekt és portfolió menedzsment

noreply@blogger.com (Pap Tibor) — Fri, 19 Jun 2009 11:32:00 +0000

Nézzük meg, milyen feladatokat, megválaszolandó kérdéseket ró egy nagyvállalatra a projekt és a projekt portfolió menedzsment témaköre. Ehhez először is azt a kérdést kell megválaszolnunk, hogy milyen szerepet játszanak egy szervezet életében a projektek.

A szervezeteket két nagy csoportba oszthatjuk ebből a szempontból.

A mindennapi operatív tevékenységük projektszerű. Ebbe a csoportba tartoznak például a tanácsadó cégek, építőipari kivitelező cégek, informatikai cégek.

A mindennapi tevékenységük folyamat orientált. A legjobb példa talán a bankok, hiszen egyszerűen belátható, hogy a hiteligénylés és bírálat folyamata messze nem illik bele a projekt fogalmába.

Azt gondolhatnánk, hogy a projekt és portfolió menedzsment az 1. csoportba tartozó vállalatok életében fontos szerepet játszanak, míg a 2. csoportba tartozó szervezetek életében elhanyagolható a jelentőségük. A helyzet azonban ettől teljesen eltérő, számos nagy bank vezetett be projekt és vagy portfolió menedzsment támogató módszereket, informatikai rendszereket.

Ezt az ellentmondást akkor tudjuk feloldani, ha megértjük, hogy minden szervezet működésének két elkülöníthető rétege van. Az első réteg az operatív réteg. A bank a mindennapi működése során hitelt nyújt és betéteket gyűjt. Erre jól bevált és rögzített folyamatai vannak, melyekhez kidolgozásra kerültek az azokat megfelelően támogató informatikai rendszerek.

Azonban semmi sem állandó, a Bank is folyamatosan fejlődni szeretne, ráadásul a folyamatosan változó környezethez is alkalmazkodnia kell, ezért folyamatosan meg kell újítania az operatív működését. Például hatékonyabb, gyorsabb, az ügyféligényeknek jobban megfelelő folyamatokat kell alkalmaznia, új termékeket vezet be a piacra, ehhez más informatikai rendszerekre, más képzettségű munkatársakra van szüksége, és így tovább.

A szervezet működésének második rétege tehát az a stratégiai réteg, mely azzal foglalkozik, hogy hogyan újítsa meg az operatív működést, hogy a szervezet a környezet változásaihoz is alkalmazkodva elérje kitűzött stratégiai céljait. A stratégiában megjelenő víziót stratégiai akció tervekre, akciókra bontják le, ezek megvalósításához pedig projekteken keresztül vezet az út. A projektek célja tulajdonképpen nem más, mint olyan új eljárások, termékek, megoldások bevezetése az operatív működésbe, melyek segítik a stratégiában kitűzött célok elérését.

Ha mindezt jól akarjuk csinálni, akkor tulajdonképpen két kérdéskörrel kell foglalkoznunk:

Mit is kell csinálni ahhoz, hogy elérjük a céljainkat? Azaz határozzuk meg azokat a feladatokat, melyeket végrehajtva elérhetjük céljainkat, de vegyük figyelembe a szűkös erőforrásokat és a várható kockázatokat. Tehát a projektötletekből, a rendelkezésünkre álló pénzből, humán erőforrásból ki kell kevernünk azt az optimális projekt portfoliót, melyet meg tudunk valósítani, és a lehető legközelebb visz bennünket az áhított célhoz. Ha pedig sikeresen megugrottuk ezt a feladatot, akkor folyamatosan figyelemmel kell kísérnünk ezt a projekt portfoliót, hogy vajon a kijelölt úton haladunk-e, illetve vizsgálnunk kell, hogy figyelembe véve a közben végbement változásokat még mindig ez-e az ideális portfolió. Tulajdonképpen erről szól a projekt portfolió menedzsment.

Gondoskodni kell arról, hogy minden egyes kiválasztott projekt elérje a kitűzött célját a kitűzött keretek (pénz, erőforrás, határidő) között, azaz csináljuk jól a kitűzött feladatokat. Tulajdonképpen erről szól a projektmenedzsment kérdésköre. Gondoljunk bele, hogy amennyiben egy adott projekt nem teljesít megfelelően, az nem csak az adott projektre van hatással, hiszen veszélyezteti a teljes portfolióval kitűzött célok elérését, más feladatok elől rabol értékes erőforrásokat, pénzt időt, stb…

A továbbiakban első sorban ezzel a két nagy témakörrel, a felmerülő problémákkal és az azokra adható válaszokkal, módszerekkel, és természetesen az ezeket támogató informatikai eszközökkel fogok foglalkozni.

Projektmenedzsment alapok

noreply@blogger.com (Pap Tibor) — Thu, 13 Nov 2008 12:21:00 +0000

Alapfogalmak

Kezdjük az alapoknál. Szeretnék tisztázni néhány alapfogalmat a projektmenedzsmenttel kapcsolatban, mivel én ezek mentén gondolkodom a témában, és a további írásaim is ezek mentén értelmezhetőek.

Olyan fogalmakra gondolok, minthogy mi a projekt, ki a projektvezető, stb... Ezeket persze sokan meghatározták már, de számomra mindig nehéz volt elolvasni és értelmezni azokat a jól megfogalmazott meghatározásokat, amiket a téma doktorai papírra vetettek. Megpróbálom egy kicsit ezért a saját gondolataim mentén megfogalmazni ezeket, közben talán megvilágítani az összefüggéseket. Hátha más is úgy van a definíciókkal mint én :)

Akit inkáb a pontos és szabatos definíciók fognak meg, olvasson inkább itt: http://hu.wikipedia.org/wiki/Projekt

Induljunk ki onnan, hogy mik azok a főbb kritériumok, amik meghatároznak egy projektet.

Van célja, amit el kell érnünk

Van egy határidő, amikorra el akarjuk érni a célt

Van egy erőforráskeret, amit ehhez felhasználhatunk

http://cmapspublic.ihmc.us/servlet/SBReadResourceServlet?rid=1234080430343_2078818310_15239&partName=htmltext

Ezek alapján persze projektnek tekinthetnénk az esti vacsorafőzést is, hiszen van célja (jól akarunk lakni :), van határidő (estére kész kell lennie), és van erőforráskeret (ami épp van otthon a hűtőben). Mégis, viszonylag ritkán készítünk projekttervet erre a feladatra.
Projektről tehát csak akkor beszélhetünk, ha komplex feladatról van szó, hiszen egy egyszerű feladat végrehajtása érdekében felesleges bevetnünk a projektmenedzsment teljes eszköztárát.
Végül nem beszélhetünk projektről akkor sem, ha egy folyamatosan ismétlődő feladatot kell végrehajtanunk. Ennek oka, hogy egy jól begyakorolt ismétlődő feladat érdekében ugyancsak felesleges volna a projektmenedzsment módszerek alkalmazása, hiszen valószínűleg rutinszerűen is végrehajtható.

Nézzük meg mi az összefüggés a három fő kritériumunk között.
A három kritérium egymásra hatással van. Amennyiben a célt változtatjuk (Pl.: 1 helyett 2 hidat kell építenünk) változik az erőforrás szükséglet és a határidő is. Ezt az alapvető összefüggést gyakran hajlamosak elfelejteni a megrendelők.

Ha már tisztáztuk, hogy mi a projekt, meg tudjuk határozni azt is, hogy mi a projektmenedzsment. Tulajdonképpen az a tevékenység, amit azért hajtunk végre, hogy a kitűzött célunkat az előre meghatározott erőforráskeretek mellett határidőre elérjük.

A Projektmenedzser pedig az a személy, aki egy személyben felel azért, hogy a projekt a kitűzött keretek között elérje a célját.

Ha felelősséget rendeltünk hozzá, akkor természetesen hatáskörrel is rendelkeznie kell. Ez praktikusan azt jelenti, hogy a projekthez rendelt erőforrások felett szintén csak a kitűzött keretek között, de szabadon rendelkezhet. Ez megint csak egy olyan pont, amit könnyen el lehet fogadni, de annál nehezebb megvalósítani. Hiszen gondoljunk csak bele, ez a gyakorlatban azt jelenti, hogy ha az Erőforrásgazda odaadta a projektre az emberét egy időkeretben, akkor abban az időszakban ő már nem rendelkezhet vele, tehát nem adhat neki más feladatot. A projektszervezetekben tipikus jelenség, hogy az erőforrásgazdák kihúzzák a projekt alól az egyszer már odaadott erőforrásokat, veszélyeztetve ezzel a projektet.

noreply@blogger.com (Pap Tibor) — Mon, 27 Oct 2008 13:24:00 +0000

Startup

Blogolni jó dolog. Ezt hallom mindenkitől, és még kézzelfogható előnyök is társulnak hozzá. Ilyen például, hogy a saját szakmai fejlődés egyik kitűnő eszköze a blogolás. Az ember leírja, és ezzel egyben rendszerezi saját gondolatait, elképzeléseit egy adott témában. Ez már önmagában is jó dolog, de lássuk be, erre elegendő volna egy saját kis dokumentum valahol az ember gépének rejtett szegletében. Blogolás esetén azonban, ehhez jönnek a hozzászólók észrevételei, amikből lehet tanulni, plusz még annak esélye, hogy talán sikerül valami hasznosat hozzátenni a nagy Internetes közösség tudásához, ezzel némi nyomot hagyva az Univerzumban. Úgy döntöttem hát, hogy teszek egy próbát, meglátjuk mire jutok vele.

A témaválasztás

Hogy miről lehet majd olvasni itt? Nagyjából azokról a dolgokról, amikkel a mindennapjaim során foglalkozom, vagyis: projekt és portfolió menedzsment, és ezeket támogató informatikai alkalmazások. Portálok, tartalom és dokumentum kezelés, csoportmunka, együttműködés, Web2 és Enterprise 2.0. Meg egyébként ami még alakul.

Jó olvasást...