Stage Gate

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

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

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

Ü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:

1. 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...
2. Pénzügyi megtérülés
3. 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

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:

1. Megtérül-e egy CRM rendszer kifejlesztésére és bevezetésére fordított költség a rendszer üzembe helyezésekor?
2. 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?
3. Megtérül-e egy projekttámogató informatikai rendszer bevezetése  a rendszer üzembe helyezésekor?
4. 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:

1. 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.
2. 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.
3. Az IT projekt célja a működési hatékonyság javítása, a stratégiai érintettség elenyésző
4. 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)
5. 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:

1. 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.
2. 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.
3. 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.
4. A változás sokkal kiterjedtebb, általában átlépi a szervezeti egységek határait is.
5. 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:

1. 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)
2. 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.
3. 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.
4. 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.
5. 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.
6. 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

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

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.