Projektmenedzsment

A Wikipédiából, a szabad lexikonból.

Ezt a szócikket át kellene olvasni, ellenőrizni a szövegét, tartalmát. További részleteket a cikk vitalapján találhatsz.

A projektmenedzsment az erőforrások szervezésével és azok irányításával foglalkozó szakterület, amely célja, hogy az erőforrások által és segítségével végzett munka eredményeként egy adott idő- és költségkereten belül sikeresen teljesülnek a projekt céljai. Ezeket a célokat a projekt kiterjedése határozza meg.

Egy projekt valójában bizonyos korlátozásokkal rendelkező erőforrások felhasználásával egy egyedi, nem megismételhető termék vagy szolgáltatás előállítását, illetve nyújtását jelenti. Az egyedi és nem megismételhető jellemzők azt jelentik, hogy a projekt alapjaiban különbözik egy folyamattól, vagy egy tevékenység sorozattól, amelyek állandók vagy csaknem állandóak abban az értelemben, hogy a munka felhasználásával gyakorlatilag azonos terméket eredményeznek, akármikor és akárhányszor is hajtják végre. Ez utóbbi két rendszer (folyamat vagy tevékenység sorozat) menedzselése alapvetően más technikákat és elméleti ismereteket igényelnek, mint amit a projektmenedzsment.

A projektmenedzsment első kihívása, hogy az eredményt adott, előre meghatározott korlátozások mellett kell elérnie. A második, elég ellentmondásos kihívás bizonyos optimitás: úgy kell az erőforrásokat biztosítani és az együttműködésüket meghatározni, hogy azok eredményei feleljenek meg előre meghatározott céloknak. A projektnek ezért nagyon megfontoltan kell megválasztania és kezelnie az erőforrásait, (az időt, a pénzt, az embereket, az anyagokat, az energiát, a helyet, az ellátást (minden értelemben), a kommunikációt, a minőséget, a kockázatokat, stb.) hogy teljesüljenek az előre kitűzött célok.

A projekt sikeressége két szinten értelmezhető:

szűkebb értelemben sikeres egy projekt, ha az adott korlátokat (idő, költség, kiterjedés) nem (vagy csak minimális mértékben) lépi át.
tágabb értelemben sikeres a projekt akkor, ha üzletileg elvárt hatását teljesíti (és szűkebb értelemben is sikeres). Ez a hatás a projekt befejezése után több évvel mérhető. Mivel az üzleti célok, elvárások meghatározása, kijelölése - általában - kívül esik a projekt menedzser hatáskörén, ugyan gyakran részese e döntésnek, az esetleges sikertelenség nem a projektmenedzser felelőssége.

[szerkesztés] A projektmenedzser

A projektmenedzser egy speciális ismeretekkel, jogosítványokkal és felelőségekkel rendelkező személy, a projekt vezetője. A projektmenedzser ritkán vesz részt közvetlenül a projekt céljának elérését biztosító munkákban, viszont szervezi, vezeti, a menedzsment folyamatokon keresztül állandó interaktív kapcsolatot tart a prokjet résztvevőivel, és igyekszik a lehetséges kockázatokat és hibákat folyamatosan elhárítani. Ez nem jelenti azonban azt, hogy a projekt tárgyáról ne rendelkezzen kellő mélységű ismeretekkel.

Bármilyen típusú termék vagy szolgáltatás - épület, jármű, elektronika, program, pézügyi szolgáltatás, stb. - esetében igaz, hogy a projektmenedzsernek át kell látnia a megvalósítás folyamatát, de a tényleges előállítási, gyártási folyamat részleteit már egy másik szakembernek - a termékmenedzsernek - kell ismernie.

[szerkesztés] A tradicionális hármas korlát

Mint minden emberi vállalkozásnak, a projekt végrehajtásának is vannak bizonyos korlátai. Tradicionálisan ezek a korlátok a következők: *kiterjedés,

idő,
költség.

A mai elemzések két újabb korlátot is felfedeztek: a minőséget és a hatékonyságot. A hatékonyságot az idő és költség korlátból - több-kevesebb munkával - le lehet vezetni, a minőséget azonban nem. Ugyanakkor ezek a korlátok erősen hatnak egymásra, általában ellentétesen. Más szavakkal: nagyobb kiterjedést csak költség és/vagy idő ráfordítással lehet megvalósítani. A szakterület eszköztárában szerepelnek azok a technikák és eszközök, amelyek biztosítják, hogy a projektcsapat (nem csak a projektmenedzser) úgy szervezze a munkáját, hogy az adott korlátokat ne lépjék át.

[szerkesztés] Idő

A projekt teljes időszükséglete az elemi tevékenységek időráfordításaiból számolható. Az elemi tevékenységek alatt olyan tevékenységeket értünk, amelyek erőforrás- és időszükséglete már jól becsülhető, és megfelelő terméket szolgáltatnak. A párhuzamosan végrehajtható tevékenységek miatt a teljes projek végrehajtási ideje általában kisebb, mint a teljes ráfordított idő összege. Meg kell különböztetni két időfogalmat:

egy termék elkészülési ideje
egy termék elkészítésének időráfordítása.

A termék elkészültének ideje egyrészt az elkészítés idejéből, másrészt esetleges technológiai vagy egyéb okok miatti késleltetés(ek)ből áll össze. Például gondoljunk egy padló cseréjére, ahol egy nap a padló lerakása, 1 nap a lakkozás és 2 nap a lakk száradási ideje, azaz a kész padló elkészítésére 4 nap szükséges, de csak 2 nap a tényleges munkaráfordítás. A projektek esetében a kezdési - és befejezési idő adott, és nagyon szoros korlát, a ráfordított munkaidő pedig becsülhető, és főként ennek költségvonzata a jelentős. Általában a projekten dolgozók egyéb elfoglaltságai miatt önmagában az időráfordítás nem jellemző, sokkal kritikusabb annak a tényleges felhasználása, azaz akkor kell az adott szakértelmet igénybe venni, amikor szükség van rá, vagy amikor lehetséges. Az ilyen típusú belső függőségek is okozhatnak látszólag indokolatlan késleltetéseket.

[szerkesztés] Költség

A projekt költségei több tényezőtől függenek. Néhány fő költségtípus:

munkaerő költsége,
anyag költség,
kockázatkezelés költségei,
eszközök, épületek, berendezések igénybevételének vagy megvásárlásának költségei,
iroda, távközlés költségei,
oktatási költségek,
tőke lekötés költsége.

A költségek vagy arányos költségek: az igénybevétel idejével arányosak, vagy fix költségek (anyag, eszköz). Adott projekthez egy adott költség tartozik, természetesen bizonyos tartalékokkal, de álatlában a költségkorlát nem léphető túl.

[szerkesztés] Kiterjedés

A követelmények határozzák meg a végső eredményt. A projekt végeredményének meg kell felelni a követelményeknek, viszont bizonyos követelményekből adódó korlátok kezelésére a projekt nem képes. A projekt kiterjedése - a scope - azokat a területeket határozza meg, amelyek befolyásolására a projekt képes, vagy fel van hatalmazva, illetve meghatározza, mely területek azok, amelyekkel a projeknek "nem kell törődnie". A projekt kiterjedése a körülmények változása vagy egyéb, a tervezéskor nem látott, vagy várt események miatt viszonylag gyakran változhat, viszont ez általában vagy a határidő, vagy a költségek változását is jelenti. Lehetnek természetesen olyan kiterjedés változások, amelyben bizonyos dolgok kikerülnek a projekt hatóköréből, és mások pedig bekerülnek, és ez esetleg nem jár sem határidő-, sem pedig költségváltozással. A kiterjedés változások kezelésére szolgálnak a projektmenedzsment változás kezelési eljárásai.

[szerkesztés] Projektmenedzsment tevékenységek

A projektmenedzsment számos különböző típusú tevékenységet fogalal magába, többek között:

A célok és/vagy a munkák megtervezése
A célok elemzése és meghatározása
Kockázatok felmérése és elkerülése
Erőforrás szükséglet becslése
Erőforrások biztosítása, lekötése
A munka szervezése
Az emberi- és más erőforrások beszerzése
Feladatok kiosztása
Vezetési tevékenységek
A projekt végrehajtásnak ellenőrzése
Előrehaladás követési és jelentési feladatok
Korrekciós akciók tervezése is végrehajtása
Dokumentációs és kommunikációs tevékenységek

[szerkesztés] Projektmemedzsment termékek

Minden sikeres projektnél elengedhetetlen, hogy dokumentálva legyenek a célok és a termékek, valamint a végrehajtás folyamata. Ezeknek a dokumentumoknak a tartalmát korlátozottan módosíthatják a szponzorok, az ügyfelek és a projekt csapat tagjai az elvárásaik és igényeik szerint.

Project Charter vagy projekt alapító dokumentum - a projekt alapdokumentuma
Üzleti megoldás - business case - a megoldási lehetőségek üzleti szempontú elemzése, kiválasztása
Kiterjedés meghatározás - mi tartozik a projekt hatókörébe és mi nem
Work Breakdown Structure - elemi feladatok meghatározása
Változás kezelési terv - az alapvető kiindulási feltételek változásainak kezelési terve
Kockázat kezelési terv - risk management plan - kockázat kezelési terv(ek)
Kommunikációs terv
Vezetési modell - a vezetés, a végrehajtás folyamatainak meghatározásai
Kockázatok gyűjtője
Eltérések gyűjtője
Erőforrás kezelési terv
Ütemezés - a projekt tevékenységeinek ütemezése
Állapotjelentések
Gantt Chart
Felelősség hozzárendelési mátrix - a projektben résztvevők felelősségi területeinek meghatározásai

Ezeket a dokumentumokat normál esetben egy mindenki által hozzáférhető, megosztott tárolóhelyen (pl. intranet, saját web lap) tárolják, és áttekintésre hozzáférhetők a projekt fő döntéshozói (stakeholder) számára. A változások átvezetését, naprakészre hozásukat a projekt konfiguráció menedzsment eljárásai szabályozzák - vagy a változáskezelési terv.

[szerkesztés] Projektek ellenőrzése

A projektmenedzsment elsősorban a sok negatív hatást okozó tényezők közül a kockázatok ellen próbál védekezni:

kockázat: lehetséges negatív hatás. A legtöbb kockázat (vagy lehetséges negatív hatás) kezelhető és minimalizálható, ha elegendő tervezési kapacitás, idő és költség áll rendelekzésre. Meg kell jegyezni, hogy az általánosan elterjed kockázatdefiníciótól eltérően, a projektmenedzsmentben (például a PMBOK harmadik kiadás) a kockázatok osztályozásánál használják a "pozitív" jelzőt, ami azt jelenti, hogy egy előre vivő lehetőség, ami a projekt gyorsabb, olcsóbb befejezését okozhatja (nem várt piaci helyzet, valamilyen korlátozás megszűnése, stb.).

A megbízók (mind a külső- mind pedig a belső projektszponzorok), a külső szervezetek (mint például kormányhivatalok és törvények/szabályok) megszabhatják ennek az időnek, költségnek, lehetőségnek a nagyságát. A maradék változó (kockázat) kezelése, menedzselése a projekt csapat feladata, ideális esetben megfelelő becslések alapján működő elkerülő, vagy hatást csökkentő akciók tervezésén és végrehajtásán keresztül. A végső célok, idő, költség, kiterjedés, kockázatok egy, a fő döntéshozókkal történő egyeztetési folyamat után kerülnek meghatározásra és rögzítésre a projekt alapító dokumentumában vagy valamilyen szerződésben.

Ezeknek a változóknak a kezeléséhez a projekt menedzsernek kellő mélységű ismereteinek és gyakorlatának kell lennie az említett négy területtel kapcsolatosan (idő, költség, kiterjedés és kockázat), ezen felül nagy gyakorlatának kell lennie még hat egyéb területen is: integráció, kommunikáció, emberi erőforrás kezelés, minőség, ütemezés tervezés és beszerzés.

[szerkesztés] A projektmenedzsment története

A projektmendzsment, mint különálló szakterület, több különálló terület - építés, ipari berendezések szerelése, építése, katonai műveletek - közös részeiből alakult ki. Az Egyesült Államokban a projektmenedzsment előfutára Henry Gantt volt, akit a tervezés és ellenőrzés atyának is neveztek, ő használta először a róla elnevezett "oszlop" diagrammot, mint projekt menedzsment eszközt. A fejlődésban nagy része volt Frederick Winslow Taylor könyvének „A tudományos irányítás alapelvei”, valamint a flotta hajóinak építésével és ennek menedzselésével kapcsolatos munkáinak. A munkái előfutárai voltak több mai, modern menedzsmenteszköznek, többek között az erőforrásbiztosításnak és a work breakdown structure (WBS) alkalmazásának.

Az 1950-es évek jelentették a modern projektmenedzsment korszak kezdetét. Ezt megelőzően az USÁ-ban a projekteket ad hoc módon, de gyakran a Gantt diagramm segítségével, és informális technikák használatával menedzselték. Ebben az időben fejlesztették ki a projektek ütemezésénél használt két matematikai modellt: (1) a "Program Evaluation and Review Technique" - program kiértékelési és felülviszgálati technika - vagy röviden PERT, amelyet az USA hadiflottája fejlesztett ki (a Lockheed Corporation-nal együtt) a Poláris rakétákkal felszerelt tengeralattjáró program támogatására; és a (2) the "Critical Path Method" - kritikus út módszer - vagy (CPM), amelyet a DuPont Corporation és a Remington Rand Corporation egy közös vállalata fejlesztett, főleg karbantartási projektek részére. Ezek a matematikai módszerek nagyon gyorsan elterjedtek a civil vállalatok körében.

1969-ben a Project Management Institute (PMI) lefektette a projektmenedzsment iparág alapjait. A PMI alapfeltevése az volt, hogy a projektmenedzsment eszközök és technikák közösek még az olyan egymástól távol álló területek között is, mint a szoftver-fejlesztés vagy az építőipar. 1981-ben a PMI vezető testülete úgy döntött, hogy kidolgoztatja a The Guide to the Project Management Body of Knowledge - útmutató a projektmenedzsment alapismeretekhez - dokumentumot, amely egy átfogó, teljes szakmai alapmű.

[szerkesztés] Közelítési módok

A projektek menedzselésének több közelítési módja is elfogadott, és alkalmazható, a projektek sajátságainak függvényében. A legismertebb ezek közül az agile - fürge - , az iterációs, az növekményes (incremental), valamint a fázisos közelítési mód.

A megfelelő közelítés kiválasztása - túl a projekt sajátosságain - függ még a projekt környezetétől, a céljaitól és fontosságától, valamint a résztvevők és a fő döntéshozók projektben elfogalat szerepeitől és felelőségeitől is.

[szerkesztés] Tradicionális közelítési mód

Egy tradicionális, fázisos közelítés a befejezéshez vezető lépések sorrendjét határozza meg. Ebben a tradicionális közelítésben a projektet 5 különálló szakaszra bontják (4 projekt szakasz valamint az ellenőrzés) a tervezés folyamán:

Projekt indítási szakasz;
Projekt tervezési szakasz;
Projekt végrehajtási szakasz;
Projekt ellenőrzési és követési rendszer;
Projekt befejezési, zárási szakasz.

Nem minden projekt esetében kerül végrehajtásra az összes szakasz, főleg, ha a projekt hamarabb befejeződik, mielőtt eredményt érne el. Néhány projektnek valószínűleg nincsen tervezési szakasza és/vagy nincsen ellenőrzési rendszere. Néhány projekt viszont többször is végigmegy a 2, 3 és 4-es szakaszokon.

Náhány iparág a fenti szakaszok különféle variációit használja. Például a téglát és maltert használó építészeti tervezés tipikus projektjei a következő folyamaton haladnak végig: elő-tervezés, koncepcionális tervezés, sematikus tervezés, terv kifejlesztés, építési tervek/rajzok (vagy szerződéses dokumentumok), és építési adminisztráció.

A szoftver fejlesztésben a tradicionális a közelítési módot gyakran nevezik 'vízesés modell'nek, ugyanis minden következő lépés csak az előző befejezése után indul, így egymást követő szakaszok sorozata a projekt. Vízesés modell alapján történő fejlesztés valójában kis, jól definiált projektek sorozata, viszont ez nem megfelelő a nagy, nem pontosan meghatározott vagy kevéssé ismert célú projektek számára. Míg a nevek iparágról iparágra változhatnak, a szakaszok valójában a probléma megoldás közösen elfogadott lépéseit követik: probléma meghatározás, lehetőségek elemzése, súlyozása, a követendő út kiválasztása, megvalósítás és kiértékelés.

[szerkesztés] Kritikus lánc

A kritikus lánc a tradicionális kritikus út módszer bővítése.

A projekt menedzsmentet kritizáló tanulmányok gyakran felvetik, hogy az alapvető PERT-alapú modellek a mai cégen belüli több-projektes környezetre nem jól alkalmazhatók. Ezek közül a legtöbb nagyon széles skálájú, egyidejű, nem-rutinszerű projekt, és manapság csaknem minden menedzsment "projekt menedzsment". Komplex modelleket használva ezekre a "projektere" (vagy "feladatokra") kiderül, hogy sok esetben néhány hét alatt jelentős felesleges kölség keletkezhet, ugyanakkor nagyon kicsi a mozgástér ennek elkerüléséhez. A projekt menedzsment szakértők inkább megpróbálnak különféle "könnyű-súlyú" modelleket megalkotni, mint például az Extreme Programming-ot a szoftver fejlesztéshez és a Scrum - csomó - technikát. Az Extreme programming technika általánosításával más projektekre kialakult az extrém projekt manedzsment, amely kombinálható a folyamat modellezéssel és a emberi kölcsönhatás menedzsment elveivel.

[szerkesztés] Folyamat-alapú (agile) menedzsment

Szintén új koncepció a projekt ellenőrzésben együttműködés a folyamat-alapú menedzsmenttel. Ez a terület az érettségi modell használatán alapul, mint például a CMMI (Capability Maturity Model Integration - képességek érettségi modelljének integrálása) és az ISO/IEC15504 (SPICE - Software Process Improvement and Capability Determination - szoftver folyamatok fejlesztése és képeség meghatározása), amelyek egyre sikeresebbek lesznek.

A folyamat alapú (agile) menedzsment megközelítés az emberi kölcsönhatás menedzsment elvein alapul, és a folyamatokat az emberi egyműködések szemszögéből vizsgálja. Ez a közelítési mód alapvetően eltér a tardiciolális közelítési módtól: az agile szoftver fejlesztési vagy a flexibilis termék fejlesztési közelítés szerint egy projekt inkább relatíve kis feladatok sorozata, a helyzettől függően elképzelve és végrehajtva, mint egy előre eltervezett, teljes folyamat.

[szerkesztés] Projektek rendszerei

Amint azt a fentiekben már láttuk, tradicionálisan a projekt tervezés 5 fő elemből áll: a projekt ellenőrzési rendszere és a 4 szakasz.

[szerkesztés] Projekt ellenőrzés rendszerei

A projekt kontroll, projekt ellenőrzés több szinten értelmezhető: a projekt megfelelően halad-e, időben van-e, illetve költségkereten belül van-e. Az előzőekben elmondottak alapján világos, hogy önmagában az, hogy a projekt haladása megfelelő, még jelenti azt, hogy akár időben, akár költségben, (legrosszabb esetben mindkettőben) túllépés jelentkezik - a tervezettnél több időt kellett a projektre fordítani, és még járulékos költségek is jelentkeztek, de a projekt előrehaladása megfelelő. Ez egyébként egy pillanatnyi állapotra igaz, ezért gyakran előrejelzést is készítenek, hogy láthatók legyenek a trendek.

A projekt ellenőrzés a kezdeti időkben egy, a tervezést követő megvalósítás utáni ellenőrzést jelentett, majd ezek az ellenőrzések a főbb szakaszok végén történtek meg, de mindig utólagos jelleggel.

Minden projekthez ki kell választani a megfelelő elenőrzési szintet: a túl sok elenőrzés sok időt (és költséget) igényel, a kevés pedig, a késői beavatkozási lehetőség miatt esetleg jelentős veszteségeket okozhat. Az ellenőrzés költségeihez hozzá kell még számítani az esetleges audit költségeit, főleg akkor, ha az ellenőrző rendszer megvalósítása nem volt megfelelő.

Az ellenőrző rendszernek ki kell terjednie a költségekre, a kockázatokra, a minőségre, a kommunikációra, az időre, a változásokra, a beszerzésekre valamint az emberi erőforrások területére. Az auditor - többnyire - a projekt pénzügyi helyzetét vizsgálja, főleg a fő döntéshozók informálásának céljából, de egy általános projekt audit az említett területek mindegyikére ki kell hogy terjedjen. Mivel az említett területek annyira speciálisak, hogy az auditorok nem rendelkeznek a szükséges szakismeretekkel, gyakran konzultánsok bevonásával hajtják végre feladatikat. Fontos viszont, hogy az auditor teljesn független legyen akár az érintett szervezettől, akár a megrendelőtől.

Az üzleti terület gyakran használ formális rendszerfejlesztési folyamatokat. Ezek felmérése nagyban hozzájárul a fejlesztés sikeréhez, és az auditor könnyen elleőrizheti, hogy a folyamatok valóban a treveknek megfelelően kerültek-e végrehajtásra. Egy jó formális rendszerfejlesztési terv a következő fő részekből áll:

Egy stratégia ami a szervezet átalakítás céljait (és határait) és lépéseit határozza meg
Az új rendszerrel kapcsolatos szabványok, előírások
A projekt menedzsment fő irányai (határidők és költségek)
Folyamatleírások

[szerkesztés] Projekt fejlesztési stratégiák

A használt projekt menedzsment módszertantól függetlenül, egy projekt fejlesztése a következő fő szakaszokra bontható: indítás, tervezés, végrehajtás valamint zárás és karbantartás.

[szerkesztés] Indítás

Az indítás az a szakasz, amely meghatározza projekt típusát és tervezési módját. Ha ezt a szakaszt nem végezték el megfelelően, akkor nagy az esélye, hogy a projekt sikertelen lesz, az üzleti elképzelések nem teljesülnek. A legfontosabb, hogy a projekt indításakor a résztvevők megértsék az üzelti igényeket, ismerjék az üzleti és szervezeti környezetet, és kellően jól mérjék fel a kezdeti kockázatokat. Ha a általuk kért információk nem állnak rendelkezésre, akkor azt haladéktalanul jelezni kell a megbízók (fő döntéshozók) felé, akiknek ezt/ezeket biztosítniuk kell.

Az indítási szakaszban egy egységes dokumentumot kell elkészíteni, ami kiterjed a következő területekre:

Az üzleti igények elemzése és mérhető célokká transzformálása.
A jelenlegi helyzet, folyamat(ok), eljárások, szervezet stb. áttekintése.
A végső eredmény/termék elérésének/elkészítésének átfogó, felső szintű terve.
Eszköz követelmények.
Pénzügyi elemzés a befektetés megtérüléséről, ideértve a prokjet költségvetését és/vagy finanszírozását.
A fő döntéshozók, érdekeltek kiválasztása, idelértve a felhasználókat, a támogatókat, az ellenérdekelt feleket, és a projekt résztvevőit.
Azokat a kezdeti kockázatokat és előfeltevéseket, amelyek alapján a projekt indítását jóváhagyták.
Egy projekt alapító dokumentum (project charter) amely meghatározza a költségkeretet, ütemezést, a termékeket és a főbb feladatokat, valamint a résztvevőket.

Meg kell jegyezni, hogy sok, úgynevezett projekt javaslat, vagy projekt kezdeményezés az elemzések eredményeként már el sem jut abba a fázisba, hogy projekt legyen belőle. A fentiekben felsorol területek egyben döntési pontok is: elfogadják a kidolgozott dokumentumot, vagy módosításokat írnak elő, esetleg kiderül, hogy az elemzésk, javaslatok alapján a folyamat leáll. Mint minden projekt belső folyamat, az indítás is ciklikus, iteratív folyamat. Ennek ellenére gyakran előfordul, hogy pl. egy projekt összes dokumentuma elkészül, minden jóváhagyás megvan, de pillanatnyi pénzügyi helyzet vagy egyéb, időközben megváltoztott körülmény miatt a projet alapító dokumentumát a vezetés mégsem hagyja jóvá - az eddig ráfordított kötségek ugyan veszteséget jelentenek, de összehasonlíthatalanul kisebbet, mint egy sikertelen projekt teljes költsége.

[szerkesztés] Tervezés

Az indítási fázis után a projekt részeletes tervezése következik, ideértve a termék prototípusának elkészítését, a teszetlést az átvételt, okatatást stb. Természetesen a szükslges módosítások átvezetése, integrálás, kapcsolatok megvalósítása is mind, mind ide tartoznak. Az ellenőrzések két területre terjednek ki: egyrészt aprojekt megvalósításának ellenőrzése (költség, idő, minőség), másrészt pedig a termék és követelmények, célok teljesülésére. Külön kell fogalkozni a menedzsment folyamatok tervezésével, ideértve a kockáztok folyamatos kezelését is. A tervezési szakasz végén előáll a teljes projekt - vagy egy részének, ha nem a tradicionális módszert követik - végrehajtási terve. Ez a terv magában foglalja a termék(ek) elkészítésének lépéseit, kibővítve az elkészítéshez szükséges egyéb tevékenységeket, és ezek együttes ütemezését is. Gyakran a projet - és a tervezés is - több lépésből áll. A tervezést mindíg az aktuális szakasz, folyamat, termék előállításnak részletes tervezése, illetve a következő szakaszok előrelátható, de igen kevéssé részletezett tervezése szerint - ezt nevezik "gördülő tervezésnek" is - kell végrehajtani. Egy nagy termék prototípusának elkészítése után hosszas elemzések következhetnek, amelyek ereménye akár az is lehet, hogy a projektnek nincsen folytatása - ez főként termékfejlesztésnél gyakori. Alapelv: mindig csak annyit tervezzünk meg részletesen amennyit feltétlenül szükséges, ezzel is erőforrást takaríthatunk meg. A projekt tervek egy sajátossága, hogy nagyon gyakran változnak, természetesen ezek a változások ritkán vonatkoznak a fő határidőkre, hanem az aktuális feladatok szintjén jelentkeznek. Ezeknek a kisebb változásoknak a kezelése a konfigurációkezelési folyamatok alapján történik, a nagyobb, teljes projektre, annak alapvető részeinek változását a változáskezelési folyamatok alapján kell kezelni. Itt is igaz, hogy a tervezés ciklikus és iteratív, legyen az a kezdeti tervezés, vagy a napi , úgynevezett naprakész terv "karbantartás".

[szerkesztés] Végrehajtás

A végrehajtási szakaszban "csak" a tervek szerinti tevékenységek végrehajtása, azok ellenőrzése, és az esetlegesen szükséges korrekciós intézkedések megtétele történik. Ebben a szakaszban végzik el a szükséges oktatásokat. Gyakorlati tapaszatalatok alapján, a projekt munkaráfordításinak 60-90%-át erre a szakaszra fordítja. A projekt menedzsment feladatai: a végrehajtás követése, ellenőrzése, jelentések készítése, koordináció, a tevek naprakész állapotba hozása/tartása, illetve egyéb vezetési és operatív tevékenységek. Az auditorok a projekszerű működést vizsgálják: mennyire tartja be a projekt működés során az előre meghatározott és elfogadott szabályokat, előírásokat.

[szerkesztés] Zárás és karbantartás

A zárás magában foglalja a formális átvételi eljárást, és a projekt adminisztratív és pénzügyi lezárását: a függő kifizetések elrendezését, teljes pénzügyi zárást, a szükséges dokumentumok archiválását, a részvevők megfelelő helyekre történő visszairányítását, a bérelt eszközök visszaadást, stb. A zárási feladatokat a projekt menedzsment szleng a "felmosni a folyósót és leoltani a lámpákat" összefoglaló kifejezéssel emlegeti. Nagyon fontos, hogy a projekt pozitív és negatív tapasztalatait a projekt csapat, vagy annak egy része, kiértékelje, és a legfontosabb tapasztalatokat egy későbbi felhasználás céljára összegyűjtse és dokumentálja.

A karbantartás egy folyamatos tevékenység, amibe a következők tartoznak általában:

A felhasználók folyamatos támogatása (pl. HelpDesk)
A felmerülő hibák kijavítása
Szoftver karbantartás, naprakész állapotba tartása

Ebbe a szakaszban az auditorok az vizsgálják, mennyire gyorsan és hatékonyan oldják meg a felhasználói problémákat a támogató csapat tagjai.

[szerkesztés] Projekt menedzsment szervezetek

Számos olyan nemzetközi és szakmai szervezet létezik a világon, amelyek elősegítik a projekt menedzsment módszertanok fejlesztését, és a projekt menedzsment szakma elismerését és fejlesztését. Ezek közül a legtekintélyesebb szakmai szervezetek a

The Australian Institute of Project Management (AIPM)
The International Project Management Association (IPMA)
The Project Management Institute (PMI)

[szerkesztés] Szakmai anyagok, szabványok

Néhány dokumentum, amelyek mutatják a projekt menedzsment módszertanok és kapcsolódó területek széles választékát:

ISO 10006:1997, Minőség menedzsment - Mminőség a projekt menedzsmentben
A Guide to the Project Management Body of Knowledge (PMBOK Guide)
APM Body of Knowledge 5th ed. (APM - Association for Project Management (UK))
P2M (A guidebook of Project & Program Management for Enterprise Innovation, egy japán harmadik generációs projekt menedzsment módszertan)
PRINCE2 (PRojects IN a Controlled Environment - projektek ellenőrzött környezetben) az egyik legelterjedtebb projekt menedzsment módszertan
V-Modell (német projekt menedzsment módszertan)
HERMES (A svájci általános projekt menedzsment módszertan, Luxembourgban a nemzetközi szervezetek által használandó módszertannak választották )
ISEB Project Management Syllabus
JPACE (Justify, Plan, Activate, Control, and End - The James Martin Method for Managing Projects (1981-present))

Lásd még: An exhaustive list of standards (fejlettségi modell)

Eddig nem készült olyan projekt menedzsment szabvány, amely a GNU Free Documentation License alá tartozna, viszont javaslat szinten a Project Management XML Schema ilyen.

A PMI erőfeszítéseket tesz abban az irányba, hogy egy kialakítson egy egységes szabványt. Ez a The Practice Standard for Scheduling, (ami jelen állapotában - 2006 május - még csak munkaanyag, de legalább készülnek az folyamat fejlesztési szabványok.)

[szerkesztés] Esettanulmányok

A Massawai kikötő megmentése, Eritrea 1942: A kikötőben kaotikus állapotok uralkodtak: gyakorlatilag megközelíthetetlen volt az elsülyedt hajóktól, a kikötői berendezések pedig szét voltak roncsolva. Edward Ellsberg kapitány, az amerikai flotta mentési szakértője a Szövetségesek kereskedelmi flottájának segítségével kiemeltette/eltávolítatta az elsülyedt hajókat, a rendbehozták a nagy úszó dokkot, a kikötői épületeket és berendezéseket pedig helyreállították. Bár a kaptitánynak csak nagyon korlátozott erőforrások álltak a rendelkezésére, a projekt-szerűen végzett erőfeszítések megmutatták, hogy így is hatalmas munkák végezhetők el. Ellsbergnek nem voltak segítői, kevés volt a jólképzett munkaerő, ő saját maga tervezte és menedzselte a munkákat. Ellsberg, mint egy rutinos szerző, egy könyvben örökítette meg az esetet: Under the Red Sea Sun (A Vörös-tengeri nap alatt) (New York: Dodd, Mead & Company, 1946).
Vagdalthús művelet (Operation Mincemeat), 1943: A rendkívül sikeres megtévesztő művelettel sikerült megzavarni a Német Főparancsnokságot a Szövetségesek földközi-tengeri hadműveleti terveivel kapcsolatosan. Az Angol Titkosszolgálat egy felöltöztett halottal sikeresen elhitette a németekkel, hogy az egy repülő szerencsétlenség magasrangú katonai áldozata, "William Martion őrnagy", akinél, besztásánál fogva, titkos haditervek lehetnek - és voltak is. A holttestet egy tengeralattjáróról a névlegesen semleges Spanyolország partjaihoz közel a tengerbe engedték. A németek hozzájutottak a holttesthez és a táskájában lévő iratokhoz, elhitték, hogy a titkos haditervek valódiak, ezért átcsoportosították védelmi erőiket. Az akcióban résztvevő tiszt, Ewen Montagu könyvet írt az esetről, amely a "vagdalthús művelet" nevet kapta. A könyv a The Man Who Never Was (Philadelphia: Lippincott, 1954), magyarul a "Sohasem volt ember" címmel jelent meg a 60-as években. 1956-ban The Man Who Never Was címmel film készült a regényből, amelyben Montagu szerepét Clifton Webb játszotta.
A nagy szökés, 1944: egy 1944-ben lejátszódó, német hadifogoly táborból való szökés története, amelyet The Great Escape (New York: Norton, 1950) címmel Paul Brickhill könyben is megörökített. Ebben az esetben egy nagy, decentralizált szervezet dolgozott azon a terven, amely hosszú idő alatt sok Szövetséges hadifogoly szökést biztosította. A eset bemutatta, hogy hogyan lehet véletlenül felismert, szétszórt tehetségek munkáját egy központosított cél érdekében összefogni, úgy hogy közben mindezt még titkolódzással is övezni kell. Az esetből film készült, 1963-ban azonos címmel (A nagy szökés). A történetet még Alan Burgess The Longest Tunnel - A leghosszabb alagút címmel újra feldolgozta.

[szerkesztés] Lásd még

Képesség fejlettségi modell
Commonware
Költség túlfutás
Kritikus lánc
Kritikus út módszer
Függőségi struktúra mátrix
Earned value módszer
becslés
Flexibilis projekt menedzsment
Funkcionalitás, megbizatás és kiterjedés - Functionality, mission and scope creep
Gantt diagramm
Vezetés
emberi kölcsönhatás menedzsment
Menedzsment
Megaprojektek
Mérések
Projekt elszámolás
Program menedzsment
Project management szoftver (Projekt menedzsment szoftverek listája)
Folyamat kialakítás
RACI diagramm
Szoftver projekt menedzsment
Az ember-hónap mítosz
Időjelentés
Work Breakdown Structure

[szerkesztés] Irodalom

Edgett and Kleinschmidt, Drs. Cooper, 2001: Portfolio Management for New Products, Second Edition. Perseus Publishing, ISBN 0738205141

[[1]]

Fred Brooks, 1995: The Mythical Man-Month, 20th Anniversary Edition. Adison Wesley, ISBN 0201835959

Project Management Institute, A Guide To The Project Management Body Of Knowledge, 2003: 3rd ed. Project Management Institute, ISBN 193069945X

[[2]]

Jack R. Meredith, Samuel J. Mantel, 2002: Project Management : A Managerial Approach, 5th ed. Wiley, ISBN 0471073237

James Lewis 2002: Fundamentals of Project Management, 2nd ed. American Management Association, ISBN 0814471323

Scott Berkun, 2005: Art of Project Management. O'Reilly Media, Cambridge, MA, ISBN 0596007868

[[3]]

Andrew Stellman, Jennifer Greene, 2005: Applied Software Project Management. O'Reilly Media, Cambridge, MA, ISBN 0596009488

[[4]]

Gary Heerkens, 2001: Project Management (The Briefcase Book Series). McGraw-Hill, ISBN 0071379525

Richard H. Thayer, Edward Yourdon, 2000: Software Engineering Project Management, 2nd Ed. Wiley-IEEE Computer Society Press, ISBN 0818680008

Harold Kerzner 2003: Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 8th Ed. Wiley ISBN 0471225770

Stephen Jonathan Whitty, 2005: A Memetic Paradigm of Project Management. International Journal of Project Management, 23 (8) 575-583

[[5]]

Görög Mihály, 2001: Projekt menedzsment, Kossuth,

Görög Mihály, Ternyik László, 2002: Informatikai projektek menedzsmentje, Kossuth

[szerkesztés] Külső hivatkozások

A lap eredeti címe "http://hu.wikipedia.org../../../p/r/o/Projektmenedzsment.html"

Kategóriák: Lektorálandó lapok | Lektorálandó lapok 2006 augusztusából | Termék életciklus menedzsment | Projekt menedzsment