Az információs projekt feladatai, erőforrásai, költségei, kontrollingja

1. Vállalati információ-menedzsment Az információs projekt feladatai, erőforrásai, költségei, kontrollingja Görög Mihály: Informatikai projektek vezetése Bőgel – Forgács: Informatikai beruházás (6. fejezet) Risztics Péter BME: Információrendszerek fejlesztése

2. Mi az (IT) projekt? 1. Tudatos tevékenység-irányítási, szervezési módszertan és keretrendszer. 2. Komplex feladat megoldására kialakított és optimálisan szervezett tevékenységek összessége. Miért kell menedzselni? • Mert komplex feladat: emberek, gépek, szervezet, külsősök • Sok együttműködő, köztük „nehéz/drága” emberek • Magas szintű munkamegosztás, fegyelem igénye • Időben (és térben) nagy kiterjedésű lehet; közben sok változással • Kockázatminimalizálás szükséges: ICT IA veszélyei, a rendszer tovagyűrűző hatásai miatt • Költséghatékonysági követelmény: ez a beruházás „feje” • Dokumentáltság-követelmény: a külső finanszírozás követelményei, a belső kontrolling követelményei, a „szervezeti tanulás” követelményei

3. Az IT projekt-menedzsment feladatai „A tevékenységek ütemezése, az együttműködők koordinációja” A formalizálás feladatai: • szervezeti keretek definiálása (ki-kit utasít, kinek jelent) • a működtetés szabályozása (erőforrások igénybevétele, hatáskörök) • eljárásrend kialakítása (mit, mikor, kivel, módosítások) • dokumentálás (belső, külső és tanuláshoz) A Projekt attribútumai 1. Objektum, a megoldandó feladat, pl. bérszámfejtési rendszer 2. Ütemezés, időzítés: véghatáridőhöz (kötbérhez) kötött 3. Erőforrások: emberek, gépek, bizonytalanság 4. Költségek - nos, itt jövünk mi a képbe!

4. Az igény-feltárás módszerei A/ Az ún. kemény rendszerelemzési technikák konkrét eljárásokat fogalmaznak meg az információs igények feltárására: kvantifikált ellenőrzés, regisztrálható adatigények, interjúk, dokumentum-elemzés. A strukturált folyamatelemzési technikák megvizsgálják az output dokumentumokat, s ezekről gyűjtik le az igényeket; az adatelemző eljárások az adatforrásokból, az adatbázisok elemzéséből építik fel az új logikai adatmodellt. B/ A puha rendszertervezési módszerek azt feltételezik, hogy a felhasználó nem tudja megfogalmazni, hogy adott szituációban milyen információkra lesz szüksége; a problémák jellegéről nincs vállalati egyetértés. A módszer: humán technikák, tárgyalás, iteratív tervezés, szervezeti szituációk számbavétele, közös megoldások. C/ A szocio-technikai tervezési módszertanok a fentiek kombinálásával dolgoznak: az erőteljes technológiai beruházások és az emberi tényezők, a szervezetek- csoportok együttműködésének párhuzamos vizsgálata képezik a módszerek súlypontját. ETHICS ETHICS & ISAC ISAC

5. IR -elemzési technikák “Kemény” rendszerelemzés: - strukturált folyamatelemzési technikák, pl. SADT, Ross, 1977, IBM BSP, 1962 ARDOSZ, MSz 1976 SSADM, NCC, ITB, 1978EuroMethod, EU 1994 UML technikák, stb. - adatelemző eljárások pl. Warnier - Orr, 1976, Jackson-diagramok, Data Structured System Devl. - prototípus-módszer, PRINCE proj. mgmt - CASE-eszközök feltételek? www.itb.hu/ajanlasok Sic: NEM üzleti-folyamat elemzés!

6. További eljárások “Puha”tervezési módszerek: - a felhasználói kommunikáció hatékonyságának javítása - egyetértés a megoldásokban is, participatív tervezés - a problémák komplexitásának csökkentése - iteratív, személyes, konzultatív eljárások - a problémás szituációk egyedi feldolgozása lehetőségek?

7. További technikák Szocio-technikai tervezési módszertanok - Az ETHICS eljárás: a "részvételi demokrácia” - Az ISAC “emberközpontú” módszertan: felhasználó-centrikus feltárás - A Multiview "többszempontú módszertan" Mire jók a tanácsadói módszertanok? - hatékonyabban, gyorsabban, precízebben jutunk el az igényekig - a kommunikációs lehetőségek jobbak - jobb ellenőrzési lehetőségeket ad - jó minőségű dokumentáció készül - a szerepek, a felelősségek ismertek - a vezetői információs igényhalmaz konzisztens lesz.

8. Tipikus ETHICS kérdések - Tényleg kell ez a változás? - Hol vannak a rendszer határai? - Milyen információkkal dolgozik a mostani rendszer? - Mik a részterületek (szerep, cél, résztvevők)? - Funkciók és felelősségek rendszere? - Jó megoldásokat adnak a mostani eljárások? - Milyen hatékonysági igények vannak? - Elégedettek a vezetők a szolgáltatásokkal? - Mit várnak a jövőtől? - Súlyozható a fenti két terület egy skálán? - Leírható egy szükségleti és egy célrendszer? - Tervezzük meg az új szervezetet! - Tervezzük meg a technikát, válasszunk optimális megoldást! - Menjünk le az információs munkalépések szintjére: tervezzünk! - Indítsuk el a rendszereket - Értékeljük ki: ki, mit kap, mennyiért, mennyire elégedett, stb. ETHICS

9. A puha ISAC módszer „ Information Systems Work & Analysis of Changes” - A változás szükségességének elemzése - Az egyes tevékenységek részletes tanulmányozása - Az információ-ellátás és az igények „szöveges” összevetése ------------------------------------- - Az adatkezelő rendszer tervezése, ún. „ISAC-gráfok” segítségével - Az információkezelő eszközrendszer illesztése ISAC ETHICS & ISAC

10. Projekt-menedzsment: a lépések Projekt-előkészítés (cél, „mandátum”, pénz) Projekt-indítás (alapvető módszerek, szervezet, költségbecslés, „business case”-CBA igazolása, kockázatok lefektetése, vezetés, mérföldkövek és felelősségek; Projekt-Alapító-Doku (PAD)) Projekt-irányítás (proj.mgmt szerepe; ellenőrzési mechanizmusok, napló; szakasz-menedzsment; változás-kezelés – engedély, jegyzőkönyv-; minőségbiztosítás; mérföldkő-elemzés és projekt-termékek) Projekt-kockázatok: költségek részben és egészben; határidők és mérföldkövek, ütemterv zavarai; személyek-kompetencia-tudás allokálása; minőség részben és egészben; célok-kiterjedés változása; projekt-tulajdonos és vezetés figyelme, támogatása

11. A projekt üzleti értéke • A vezetői döntés:azt a projektet indítjuk, aminek nagyobb a várható üzleti értéke • A választás lehetősége: • Választás a szervezet általános üzleti igényei, tervei alapján: van igény, van vezetői támogatás, van finanszírozás – pl. egy CRM vízió megvalósítása • Választás projekt-kategóriák között: fontosság, időtartam (van értelme?), határidő (meg lehet addig csinálni?); problémára-reagálás vagy direktíva, utasítás miatt kell? • Választás gazdasági számítások (NPV, stb., ) alapján – vagy Mintzberg patkó-modellje: abszolút pénz, vagy abszolút más célok (stakeholder-elemzés) (pl. munkahelyek, alvállalkozók helyzetbehozása, stb akármi) • Választás súlyozott kritériumok alapján (pl.: üzleti célok támogatása, belső támogatási erő, ügyfelek támogatása, technológiai szint, rövid megvalósítás, NPV pozitív, kicsi a költségek/kiterjedés/idő és más kockázati mutatója, stb.)

12. Egy SAP projekt céljai (N.Welti, 1999) • Vevőmegkeresések válasza 2 óra alá csökkentése • Válaszok pontosságának javítása • Rutin értékesítési adminisztráció javítása 100 000 • Vevőigények-anyagok biztosítása egyensúly javítása • Fizetési határidők 5 napos kurtítása 40 000 • Rutinjellegű pénzügyi admin optimalizálása 40 000 • Rendelések átfutási idejének felezése • Készletek átlagos állományának 40%-os csökkentése 580 000 • Készletforgási sebesség megduplázása 370 000 • Termelési költségek csökkentése • Teljesítmény-javulás: tervezés, programozás 900 000 • A teljes „output” 2,5%-os növelése, azonos létszámmal 500 000 Becsült teljes megtakarítás / év 2 530 000 Példa tényleges TCO-ra: www.classroomtco.org

13. Példa: egy CRM projekt megtérülése Pozitív tételek: • Az eladott mennyiséget növeljük, kereszt-értékesítéssel • A szolgáltatási díjak növelése jobb piac-szegmentálással • Értékesítési költségek csökkentése a vevőhűség erősítésével, célzott marketinggel • Készletszintek csökkentése piaci előrejelzésekkel • Követelés-állomány csökkentése a rossz vevők kiszűrésével (adatbányászat) Negatív tételek: • A folyó kiadások növekedése az új ICT rendszer miatt • A tárgyi eszközök állományának növekedése (beruházások)

14. Ami egyszerűbb: IT-Mgmt • Amiért fontos (Szabó Z.) - Az IT háttér nélkülözhetetlen, SOP jellegű, esetenként stratégiai - A beruházás és a fenntartás egyre többe kerül - Az új technika terjedése gyors, a „vevő” igényesebb - A hálózatok és a biztonság miatt a rendszerek egyre bonyolultabbak - Compaq felmérés: 25-ből csak egy pénzügyi döntéshozó veszi figyelembe, hogy az IT-beruházások költségeinek kb. 80%-a az üzemeltetés során lép fel.- BEIS (Brian Seitz): 1/5 projekt sikeres pénzügyileg, 1/3 leállításra kerül, „CIO means Career Is Over” • A szokásos kérdések- Indokolható a jelenlegi csúcstechnológia követelése? - Illeszthető a tervezett eszközrendszer a meglévőkhöz? - Mekkora az egyszeri és folyamatos járulékos költség-növekedés? • Amit tehetünk (viselkedési stratégiák): A/ Extenzív beruházás a technikába („több memória”, új processzorok, mindenkinek PC és Internet - aztán majd lesz valahogy) B/ Túlélés: tűzoltó jellegű beavatkozások („legalább egy gépen menjen”, „ a főnöknek van Internetje”, „igen, megvettük, 5 gépre”) C/ Figyelni, tervezni, előkészíteni, beruházni, fenntartani...

15. Az IT-projekt management modelljei • REJ Rapid Economic Justification, (Microsoft és Intellectual Arbitrage Co.): nem csak költség (TCO), hanem hasznok is • BEIS (Business Enviromental/Economic Impact Statement), a REJ-jel párhuzamosan, annak „bátyjaként” fejlődött. Több részletes módszertani adatot és technikát tartalmaz, integrálva; inkább gyakorlati természetű. (Seitz, 1999) • IT outsourcing megoldások

16. Az MS- REJ modell elvei • A BEIS számos technikát, eszköztés megoldási utat foglal magában, ezzel szemben a REJ maga egy konkrét, lehetséges megoldási út IT-projektek értékelésére • A REJ célja: kiegyensúlyozott megközelítésmód, az értékelés egyensúlyának (C/B) lehetősége, szemben a szimpla költségmodellekkel (pl. TCO) • A REJ a gazdasági elemzések adatait és folyamatát gyorsan végrehajtható és nagymértékben fókuszált lépések sorozatába koncentrálja, melyek mindegyikéhez jól meghatározott kimenetet és javasolt végrehajtási technikát ajánl. • A legtöbb egyszerű projekt esetében a REJ elegendő ahhoz, hogy egyszerre elégítse ki az igényeket és megfeleljen az „időben gazdaságos” elemzés feltételének. Ha a gyors elemzés elengedhetetlen, a „Rapid” EJ a megfelelő választás.

17. A REJ modell elemei • A REJ-keretrendszer az üzleti feladatokra, mint kritikus sikertényezőkre (Critical Succes Factor – CSF) hivatkozik.Képes együttműködni más elemző eljárásokkal (pl. IT-portfolió menedzsment, Balanced Scorecard és a különböző, élettartam alatti költséget elemző módszerek). • Egy REJ-tanulmány elkészítése három fázisból áll:A/ Csapat-szerepek és -felelősségek definiálása: sok szakterületről összeállított szakembergárda működtetéseB/ Előkészületek az üzleti tanulmány elkészítésére (irányvonal, célok, magyarázó[!] részek gazdasági vezetőknek a haszonról, relatív haszon a konkurrens projektek vezetőinek!)C/ A tanulmány elkészítésének folyamata (technikák és eszközök a vizsgálat elvégzéséhez,Microsoft SolutionFramework -MSF)

18. A REJ lépései

19. Az 5 REJ lépés és résztvevői: 1. Az üzleti helyzet felmérése, stakeholder identification, CFS definition, Key Performance Indicators (KPI): interjúk, értéklánc-elemzés, stb.

20. és: 2. A megoldás meghatározása: A csapat meghatározza a vállalat CSF-aihoz legjobban kötődő tevékenységeket, s a lehetséges IT támogatást (Required Enabler – RE) 3. A hasznok és költségek felbecslése: Megbecsülik a potenciális hasznokat és az ezek elérése közben felmerülő költségeket. Cash-flow tervezés (Cash-Flow Statement), lényegében „munkaktsg-megtakarítás” használható.Nem egyszerűen egy szokásos „Total Cost”: fogalmazzák meg maguk a résztvevő döntéshozók (Business Decision Makers, BDMs), mik az előnyök: írjanak le szcenáriókat, vitassák meg, mi-lenne-ha módon!

21. és: 4. A kockázatok meghatározása: A csapat azonosítja és számszerűsíti a projekt bizonytalan területeit, risk-mgmt módszerekkel (alignment-, pénzügyi feasibility-, operational-, beneficial-risks). Kockázati kategóriák: • annak kockázata, hogy az implementációs költségek eltérnek a tervezettől; • annak kockázata, hogy az üzemeltetési költségek magasabbak lesznek a becsülteknél; • annak kockázata, hogy a hasznok alacsonyabbak lesznek a vártnál. A REJ ehhez egy komplexmátrixot használ (vizualizálás): az események bekövetkezésének valószínűségét és hatásának mértékét becsülteti fel:

22. és végül: 5. Finanszírozási mérőszámok számítása: Időtényezővel és a kockázatokkal módosított cash-flow számítások, mérőszámokkal kimunkálása (diszkontált cash-flow, NPV, IRR, EVA - economic value added - , megtérülési idő – pyback period – etc.). Az eredmény: egy tömör, komplex, sokoldalú report, egy „business case”, amely vezetői és finanszírozói (!) döntéstámogatáshoz használható

23. Példa az öt lépésre ELEMZÉS: legyen az “értékesítés hatékonysága” elfogadott CSFNagyobb IT-támogatás eredményes lehet: - A fogyasztókat termékinformációkkal látjuk el- Termékbemutatókat tartunk kiválasztott fogyasztóknak- A versenyző árajánlatokra azonnal (real-time) válaszolunk- Az értékesítési eseményeket online módon elemezzük, stb. MEGOLDÁS: ha a “termékinformációk vizsgálata” egy kulcstevékenység, pl. az idő 50%-át viszi el (árak, specifikációk, stb.), akkor csináljunk adatbázist, intraneten, és adjuk ki azt laptopokra, frissítéssel, tegyük extranetre, stb. CBA elemzés: - Direkt munkaköltség-megtakarítások - A tudásalapú dolgozók munkaidő-alapja növekszik - A döntések ciklusideje csökken - A felhasznált működő tőke csökken - A támogatási és infrastrukturális költségek csökkennek - A végeredményt tekintve a bizonytalanság és a kockázat csökken. RISK MANAGEMENT, mutatószámok, kockázatok pontozása TANULMÁNY, pénzügyi mutatók: sROI, NPV, IRR, Economic Value Added – EVA, megtérülési idő, Earnings Per Share – EPS).

24. A BEIS modell tulajdonságai Business Environmental/Economic Impact Statement - értékelő tanulmány • A BEIS mélyebb vizsgálatot, statisztikai korrelációk és az üzleti stratégiához való viszony elemzését is lehetővé teszi. • A REJ-től eltérő utak használata jóval több időt és erőfeszítést emészt fel, és nem ajánlott olyan vállalatoknak, melyeknek nincs gyakorlatuk az IT-megvalósíthatósági tanulmányok kidolgozásában.

25. A projektek értékelésének nehézségei /1 • Legtöbbször nem egy projekt fut, hanem több, párhuzamosan • Ma már csak nagyon komplex szoftver-rendszerek vannak • Több-helyszínes, akár több-országos projektek futnak • A célrendszer nem világos, a határok és stakeholderek nehezen azonosíthatóak, változnak • A technológia menet közben megváltozik, integrálni is kell • A legtöbben részmunkaidőben vesznek részt egy informatikai projektben: ez nem építőipar! • A projektek hosszúak és bonyolultak: mikor lesz „sikeres”? Mikor „failed”? • A sok helyi sajátosság miatt minden projekt „más”

26. Mi a probléma az ICT projektekkel? /2 • Nincsenek egzakt mutatószámok, amelyekkel a projekt sikerét, kimenetét mérni lehet (nem úgy, mint egy ipari beruházásnál) • A projektek nagy százalékban (50-60%!) kudarcot vallanak, módszertan, szakértők hiányában, s ez bizonytalanná teszi a vezetőket – mindent alábecsülnek! • Az ismeret- és információhiány nem biztosítja a szükséges vezetői támogatást • A technológia és a létrehozott rendszerek bonyolultak, gyorsan változnak • A szállítók garanciáját egyedül a referencia-munkák jelentik, azok megítélése pedig bizonytalan • Az örökölt rendszerek megtartásának igénye akadályozza a projekt előrehaladását • Egyes örökölt rendszereket integrálni kell, az adat-migráció súlyos probléma • A meglévő informatikai csapat nehezen vehető rá az együttműködésre, nehéz a csapatépítés, külsősökkel kell dolgozni • A beszállítói kockázatok miatt a projektek sokat késnek, költségeik nehezen tervezhetőek. CHAOS

27. A kudarcok okai (Bőgel György nyomán)

28. (Bőgel György nyomán)

29. Példa: szoftverhibák kijavításának költségei Mikor észleli a hibát? Költségek nagysága USD A felhasználói igények meghatározásakor 100 – 1,000 A programozás során és a modulok belső tesztelésekor 1,000 – plusz A rendszer össz-tesztelésekor 7,000 – 8,000 Az elfogadási tesztnél, a felhasználó jelenlétében 1,000 – 100,000 Implementálás és átvétel után, a teljes rendszer éles futásakor, szervezeti és folyamat-átalakításokután feltárt hibáknál milliós nagyságrend Menet közbeni kérdések: - Amikor rájövünk, hogy így nem megy tovább, de már benne van X millió, mit tegyünk ezzel? Hova számoljuk? Újrakezdjük? - Mennyi tartalékot képezzünk a valószínűsíthető problémákra?

30. ICT projekt-menedzsment: a kommunikációs gát

31. Láttuk az Info Arch keretében: PRINCE2stands for 'PRojects IN Controlled Environments', it was developed by the UK Office of Government Commerce (OGC) back in the 1990s. PRINCE2 is a de facto standard developed and used extensively by the UK government and is widely recognised and used in the private sector, both in the UK and internationally. It embodies established and proven best practice in project management.

32. PRINCE: brit ajánlás a projektekhez • A PRINCE projektirányítási módszertan az LBMS (Learmonth and Burchett Management Systems') cég módszerének (PROMPT) továbbfejlesztése. A PRINCE (Projects IN Controlled Environments) a brit kormányzat informatikai részlegeinek projektirányítási ajánlása (CCTA -(Central Computer and Telecommunications Agency A gyakorlatban a PRINCE nem alkalmazható nagyon kis projektek esetén, amelyek kevesebb mint három embert foglalkoztatnak, vagy három hónapnál rövidebb ideig tartanak. A PRINCE nem rendszerfejlesztési, hanem projektirányítási módszertan. A PRINCE főként az SSADM-en (Structured System Analysis and Design Method) alapuló rendszerfejlesztési projektekhez nyújt irányítási keretet. Ezenkívül támogatja következők használatát is: • A konfigurációkezelési módszer (KKM) a rendszer struktúrájának és tartalmának ellenőrzéséről gondoskodik a fejlesztés során; • CRAMM (CCTA's Risk Analysis ans Management Methodology): tevékenységek, amelyek a kockázatokat megfelelően csökkenthetik. PRINCE

33. PRINCE: IT projekt-módszertan 1. A PRINCE-ben a projektnekvéges élettartama, megadott felelősségi körökkel rendelkező szervezeti struktúrája, meghatározott és egyedi termékei, a termékek előállításához szükséges tevékenységei, valamint e tevékenységek elvégzésére alkalmas erőforrásai vannak. Egy projekt több szakaszra bomlik, egy szakasznak is vannak meghatározott termékei és tevékenységei, szervezeti felépítése, valamint véges lefutási ideje. A szakasz végét a benne meghatározott termékek előállítása jelenti, amennyiben azok kielégítik a megállapodás szerinti minőségi feltételeket. A PRINCE meghatározza a projektnek és szakaszainak szervezeti felépítését, az egyes projekttervek tartalmát és szerkezetét, valamint ellenőrzési pontokat annak biztosítására, hogy a munkálatok a tervek szerint folyna, a termékek „elkészülnek”. . A PRINCE projekt minden terméke egy jól meghatározott és összefüggő nyilvántartási rendszerben van elhelyezve, amelyben az irányítási, műszaki és minőségbiztosítási termékek egymástól elkülönülnek. Egy tipikus rendszerfejlesztés esetén a projekt szakaszai a rendszerfejlesztés életciklusának felelnek meg. Eszerint a szakaszhatárok a specifikáció, (megvalósíthatósági tanulmány), tervezés kivitelezés és üzembehelyezés fontosabb termékeinek teljesítéséhez igazodnak.

34. PRINCE: az életciklusok Elképzelés Megvalósíthatósági tanulmány Hatáselemzés Feladat-specifikáció Tervezés Fejlesztés Tesztelés Üzembe helyezés Üzemeltetés Változtatás Termék-életciklus Projekt-életciklus

35. PRINCE projekt-módszertan 2. A PRINCE tervek hierarchikus struktúrát alkotnak, a szervezet szintjeihez igazodó tervezési szintek formájában.

36. A PRINCE és a tanácsadó 1. Az IT projekt megtervezése - a “van” helyzet: információgyűjtés - problémák azonosítása, igénylisták készítése, szűrés - strukturális terv: mit akarunk elérni, kiket fog ez érinteni, milyen lépésekre van szükség - erőforrás-terv: költségek, emberek, idő, stb. - és egy vázlatos tevékenységi terv, legtöbbször hálóterv / GANTTformájában. 2. A projekt irányítása Rendszertervező helyett: “művezető” IT-menedzser, vezető programozó, felhasználói projektmenedzser? Emberi problémák (életkor, képzettség, attitűdök); mérési problémák; minőségbiztosítási problémák; ellenőrzés és számonkérés nehézségei. Koordinálás, rugalmasság, jó kommunikációs készségek, szaktudás, gyakorlat... a KÉZBENTARTÁS kérdése PRINCE

37. És láttuk: „célvezérelt projekt-menedzsment…” 3. A projekt ellenőrzése- célvezérelt szemlélet - mérföldkövek ellenőrzése, személyhez kötés - eltérések magyarázata - változás-menedzsment, korlátozások - erőforrás-felhasználás - eredménymérés: auditálás.

38. Az e-projektek specialitásai • eBusiness: a cég kulcsfolyamatainak teljes elektronizálása, Internet szolgáltatásokkal • A szokásos eBusiness architektúra: • Ügyfél-oldali (kliens) felület (browser, vagy spéci terminál) • Központi szerver (adatbázis, szoftverek, fizetés) • Üzemeltetés-támogató rendszerek (monitorozó szoftverek, üzenetközvetítés, portál-technikák) • Távközlési infrastruktúra • A speciális projekt-követelmények: • 7 x 24 x 365 folyamatos üzemeltetés, rendelkezésre állás • Alacsony válaszidő, tartalmi értelemben is (Toys ‘R Us) • A teljesítmény-igény ingadozik, nem becsülhető (Harry Potter) • Erős biztonságtechnikai igények vannak (szegmentálás, szakértelem) • Nincs idő sok fejleszthetőségre (RAD, PRINCE) c. Szabó Zoltán, BKAE

39. Egy módszertan: • A „célvezérelt” projektmenedzsment azt diktálja, hogy a projekt vezetése során a legfontosabb a cél-hierarchia felépítése, figyelése, a tevékenységek célra-orientálása • A főbb fogalmak: • cél-lebontási struktúra (Mission Breakdown Structure) pontos felépítése • a környezet állandó figyelése: • az érdekcsoport-elemzés (Stakeholder Analysis) és • a bizonytalanság-elemzés (Uncertainty Analysis) kidolgozására összpontosít. • az átfogó tervezés egy többsávos mérföldkő-tervezésre épít és alapul szolgál a részletes tervezéshez, a projekt-követéshez és a kontrollhoz. • Forrás: http://gdpm.hu/; GDMP kézikönyv

40. Véry Zoltán Old Economy: IT a költség-csökkentésért New Economy: IT/IM a profit-növelésért