Projektmenedzsment

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

A projektmenedzsment az erőforrások szervezésével és azok irányításával foglalkozó szakterület, melynek célja, hogy az erőforrások által végzett munka eredményeként egy adott idő- és költségkereten belül sikeresen teljesüljenek a projekt céljai. A projekt időszaki vállalkozás, melynek célja, hogy egyedi terméket vagy szolgáltatást hozzon létre. "Időszaki" abban az értelemben, hogy a projektnek van kezdete és vége (nem összetévesztendő az átfutási idővel). "Egyedi" abban az értelemben, hogy a termék vagy szolgáltatás a projekt végén valamilyen módon eltér a jelenlegitől. Az egyediség azt is jelenti, hogy a projekt alapjaiban különbözik a folyamatoktól és az üzemeltetéstől, amelyek állandóak vagy csaknem állandóak abban az értelemben, hogy gyakorlatilag azonos terméket vagy szolgáltatást eredményeznek, akármikor és akárhányszor is hajtják ezeket végre. Az ismétlődő tevékenységek (folyamatok vagy üzemeltetés) és az egyszeri tevékenységek (projektek) menedzselése alapvetően más technikai ismereteket és megközelítést igényel.

A projektmenedzsment első kihívása, hogy az eredményt adott, előre meghatározott korlátok figyelembevételével kell elérnie. A második, még komolyabb kihívás, hogy a projekt az előre definiált célok eléréséhez a szükséges eszközöket optimálisan és integrált módon használja fel. A projekt tehát az előre definiált célok elérése érdekében tett ésszerűen megválasztott, erőforrás (idő, pénzt, emberek, anyagok,energia, hely) felhasználással járó tevékenységek sorozata.

Tartalomjegyzék 1 A projektmenedzsment története 2 Definíciók 3 Projektmenedzsment folyamatok 3.1 Indítási folyamatcsoport 3.2 Tervezési folyamatcsoport 3.3 Végrehajtási folyamatcsoport 3.4 Kontroll folyamatcsoport 3.5 Zárási folyamatcsoport 4 A projektmenedzsment kilenc területe 5 A tradicionális hármas korlát 5.1 Idő 5.2 Költség 5.3 Hatókör 6 Főbb projektmemedzsment dokumentumok 7 Projektek ellenőrzése 8 Közelítési módok 8.1 Tradicionális közelítési mód 8.2 Kritikus lánc 8.3 Folyamat-alapú (agile) menedzsment 9 Projektek rendszerei 9.1 Projekt ellenőrzés rendszerei 10 Projekt menedzsment szervezetek 10.1 Nemzetközi szabványok 10.2 Szakmai minősítések 11 Esettanulmányok 12 Lásd még 13 Referenciák 14 Irodalom 15 Külső hivatkozások

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

Projekteket azóta terveznek, mióta az emberek nagyobb feladatokat közösen végeznek. Legyen akár szó egy hadjárat megtervezéséről és felszereléséről, egy templom vagy erődítmény megépítéséről, egyik sem volt elképzelhető anélkül, hogy az ezért felelős emberek ne tervezték volna meg ezeket a „projekteket”. Azonban hosszú ideig mindez keretek nélkül történt, az adott személy tudásán és tapasztalatán alapult; csak a 20. században gyűjtötték össze és rendszerezték ezeket az informális eljárásokat, és alakították ki a tudományos formáját, melyet ma projektmenedzsmentnek nevezünk.

Az 1900-as évek elején Frederick Taylor egy Pennsylvania-i acélműben kezdte el tanulmányozni, hogy a munkások által végzett feladatok részekre bontásával és mérésével hogyan lehet növelni a hatékonyságot. Érdeklődésének középpontjában az állt, hogy lehet-e jobb eredményeket elérni a már ismert módokon ("dolgozz többet és keményebben") kívül. Munkái a menedzsmenttudományok alapjainak tekinthetőek^[1].

Taylor munkatársa volt Henry Gantt, aki az I. világháború alatt az Amerikai Haditengerészetnél tanulmányozta a hadihajók építésének folyamatát és a folyamat menedzsmentjét. A hajóépítést folyamatokra és feladatokra bontotta, a feladatok végrehajtását mérte és dokumentálta, és ehhez saját maga alkotott speciális grafikonokat. Ezekkel átlátta és elemezni tudta a hajóépítés egyes folyamatait és összefüggéseit, és nyomon tudta követni, hogy hogyan halad előre az építés (terv szerint haladnak, késésben vannak stb.). A Gantt-diagram az elmúlt majd 100 évben végig fontos eszköze maradt a projektmenedzsmentnek, Gantt munkái előfutárai voltak több mai, modern menedzsment eszköznek, többek között az erőforrásallokációnak és a WBS-nek (work breakdown structure).

A modern projektmenedzsment kialakulásának kezdete az 1950-es évekre tehető, amikor az amerikai rakétaprogram a szovjetekhez képest hátrányban volt. Nemzetbiztonsági kérdéssé vált, hogy az Egyesült Államok minél hamarabb képes legyen interkontinetális ballisztikus rakétát előállítani. Egészen addig a projekteket ad hoc módon, gyakran a Gantt-diagram segítségével, de leginkább informális technikák használatával menedzselték az USA-ban is. A Polaris rakéta projekt során ezernél is több beszállító dolgozott; ehhez a rendkívül komplex és nagyméretű projekthez az addig használt módszerek nem vezettek volna elég gyorsan eredményre. A Polaris projekt során fejlesztette ki 1958-ban a Booz Allan Hamilton Inc. nevű tanácsadó cég alvállalkozóként a projektek tervezésére és ütemezésére használt első tudományos modellt, az ún. PERT modellt (Program Evaluation and Review Technique - program kiértékelési és felülvizsgálati technika)^[2]. Nagyjából ebben az időben fejlesztette ki a DuPont Corporation és a Remington Rand Corporation közösen a projektek tervezésére és ütemezésére használt másik matematikai hátterű algoritmust, a kritikus út módszert (Critical Path Method). Ezek a matematikai módszerek nagyon gyorsan elterjedtek a civil vállalatok körében, akik - a katonai programok sikerét követően - használni kezdték a hadsereg által finanszírozott kutatások és fejlesztések eredményeit.

1969-ben alakult meg a Project Management Institute (PMI) abból a célból, hogy a projektmenedzsment iparág érdekeit szolgálja. 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 jóváhagyta a később Projektmenedzsment Útmutató (The Guide to the Project Management Body of Knowledge - PMBOK) néven ismertté vált dokumentum kifejlesztését, amely tartalmazza a szakmában széleskörűen elfogadott szabványokat és gyakorlati útmutatókat.

[szerkesztés] Definíciók

• PMBOK (Project Management Institute - PMI) szerint:"A projektmenedzsment a projektkövetelmények teljesítése érdekében végzett tevékenységek során a tudás, képességek, eszközök és technikák alkalmazása."^[3]

• DIN 69901-1 szerint (Német Szabványügyi Intézet - Deutsches Institut für Normung): "A projekmenedzsment a projekt végrehajtása során alkalmazott vezetéssel kapcsolatos feladatok, technikák, eszközök, valamint a vezetésszervezés összessége."

• PRINCE2 projektmenedzsment módszertan szerint: "A projektmenedzsment a projekt valamennyi szempont szerinti megtervezése, követése és ellenőrzése, és mindazok motiválása, akik részt vesznek a projekt céljainak az előre meghatározott időben, költségkereteken belül és megfelelő minőségben történő megvalósításában."^[4]

[szerkesztés] Projektmenedzsment folyamatok

A használt projektmenedzsment módszertantól függetlenül, a projektmenedzsment folyamatok indítási, tervezési, végrehajtási, kontroll valamint zárási folyamatcsoportokba sorolhatóak.

[szerkesztés] Indítási folyamatcsoport

Ebbe a csoportba tartoznak azok a folyamatok, amelyek az új projekt vagy projektfázis formális jóváhagyását hivatottak előkészíteni és segíteni.

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 üzleti igényeket, ismerjék az üzleti és szervezeti környezetet, és kellően jól mérjék fel a kezdeti kockázatokat.

Az indítási szakaszban készül el a projekt alapító dokumentuma (project charter), amely ideális esetben definiálja és leírja:

• A különböző érdekeltek, szponzorok, ügyfelek igényeit, követelményeit és elvárásait
• Az üzleti igényeket
• Projekt által elérendő (lehetőleg mérhető, objektív) célokat és a projekt végrehajtásának indokait
• A projektvezető személyét és működésének határait
• A projekt végrehajtásának költségvetését, hozzávetőleges ütemezését, és a résztvevőket
• A befektetés megtérülését alátámasztó pénzügyi elemzést (business case)
• A kezdeti kockázatokat, feltételezéseket és ismert korlátozó tényező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 felsorolt 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ések, javaslatok alapján az a döntés születik, hogy a projekt nem indul el, vagy nem lép a következő szakaszba. Például előfordulhat, hogy egy projekt összes előkészítő elemzése és dokumentuma elkészül, de a pillanatnyi pénzügyi helyzet vagy egyéb, időközben megváltoztott körülmény miatt a projekt 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ési folyamatcsoport

Ebbe a csoportba tartoznak azok a folyamatok, amelyek a projekt céljainak pontosításával és a projekt célkitűzéseinek eléréséért végrehajtandó lépések megtervezésével függnek össze. A tervezési folyamatcsoportba tartozó főbb folyamatok:

• a hatókör (terjedelem) pontos meghatározása
• a projekt részfeladatokra bontása
• a részfeladatokhoz tartozó elvégzendő tevékenységek meghatározása, a közöttük levő összefüggések megtervezése
• a tevékenységekhez tartozó erőforrás és időbecslések elkészítése
• a fentiek alapján a projekt ütemtervének és költségvetésének megtervezése

Ide tartozik néhány fontos segédfolyamat, mint a kommunikációs és kockázatkezelési terv elkészítése, a minőségtervezés és a beszerzési terv elkészítése. A fenti tervezési folyamatok eredményeként előálló rész-terveket a projektmenedzsment terv fogja össze, mely a projekt végrehajtási tervének tekinthető.

[szerkesztés] Végrehajtási folyamatcsoport

A végrehajtás fő feladata az elkészült tervek alapján a projekttevékenységek irányítása és összehangolása, annak érdekében, hogy a projekt elérje célját. Ebbe a folyamatcsoportba tartoznak még a minőségbiztosítási folyamatok, a projektcsapat fejlesztésével és teljesítményértékelésével, az információ megfelelő elosztásával és a beszállítók kiválasztásával kapcsolatos folyamatok.

[szerkesztés] Kontroll folyamatcsoport

Ez a folyamatcsoport a projekt tervezett végrehajtása és a tényleges végrehajtása közötti különbségek folyamatos ellenőrzésével foglalkozik, annak érdekében, hogy az esetleges problémákat idejében észleljék és megfelelően tudjanak reagálni rá. Két fő folyamat tartozik ide:

• A projekt teljesítményével és működésével kapcsolatos információk összegyűjtése, feldolgozása és az információ eljuttatása az érdekeltekhez
• Az integrált változáskezelés

A két fő folyamatot szintén számos másik folyamat segíti, mint például az ütemezés, költségek és kockázatok kontrollálása, projekttermékek ellenőrzése, jelentések készítése, szerződésadminisztráció.

[szerkesztés] Zárási folyamatcsoport

A zárás magában foglalja a projekt adminisztratív és pénzügyi lezárását: a függő kifizetések elrendezését, szerződések lezárását, 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ását stb. Nagyon fontos, hogy a projekt pozitív és negatív tapasztalatait a projektcsapat, 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.

[szerkesztés] A projektmenedzsment kilenc területe

Integráció- menedzsment	Terjedelem- menedzsment	Ütemezés- menedzsment
Költség- menedzsment	Minőség- menedzsment	Emberi erőforrás- menedzsment
Kommunikáció- menedzsment	Kockázat- menedzsment	Beszerzés- menedzsment

A PMBOK szerint a projektmenedzsment alapvetően az alábbi 9 területtel foglalkozik:

• Integrációmenedzsment: A terület feladata a projekt különböző elemeinek összehangolása. A projektmenedzsment standardok segítik ennek a végrehajtását.
• Terjedelemmenedzsment (scope management): A projekt terjedelmének menedzsmentje biztosítja, hogy a kitűzött projektcélok (és csak azok) megvalósuljanak. Azonban ennek a területnek nem csak az eredeti cél szem előtt tartása a feladata, hanem az is, hogy a projekt végrehajtása során felmerülő új vagy megváltozó célokat azonosítsa, beépítse a projektbe, és a szükséges újratervezéseket elvégezze.
• Ütemezésmenedzsment: A terület feladata az eredeti ütemezés betartása, melynek során kommunikációs eszközként a projekt ütemezését (projekttervet) használja.
• Költségmenedzsment: A terület feladata a költségvetés keretein belül történő végrehajtás biztosítása, a költségtúllépés felismerése és az esetlegesen szükséges korrekciós tevékenységek végrehajtása.
• Minőségmenedzsment: A terület feladata, hogy biztosítsa a projekt eredményeinek az elvárt és specifikált paraméterekkel (minőséggel) történő leszállítását.
• Emberi erőforrás menedzsment: Ide tartozik az emberi erőforrásoknak a képesség és rendelkezésre állás figyelembevételével történő optimális felhasználása, beleértve az erőforrások képzését és fejlesztését is.
• Kommunikációmenedzsment: A terület feladata a projektben résztvevő összes érdekelt személy és szervezet megfelelő mennyiségű, minőségű és rendszerességű tájékoztatása.
• Kockázatmenedzsment: Ide tartozik a minőségi és mennyiségi kockázatelemzés, elkerülési és tartaléktervek kidolgozása
• Beszerzésmenedzsment: A terület feladata a beszállítókkal és partnerekkel történő együttműködés és integráció szabályozása.

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

A projektek végrehajtásának is vannak bizonyos korlátai. Három fő korlátot szoktak felsorolni:

• idő (a projekt végrehajtására rendelkezésre álló idő véges)
• költség (a projekt költségvetésében szereplő összeg véges)
• hatókör (a projekt által megvalósítandó feladatok végesek)

Ezeket a korlátozó tényezőket gyakran háromszögként személtetik (projektmenedzsment háromszög), ahol a háromszög egy-egy oldala a fent említett korlát egyike. A szemléltetés lényege, hogy lehetetlen megváltoztatni a háromszögnek csak az egyik oldalát: ha egyik oldal változik, az kihat a többire is. Lefordítva: nagyobb hatókört (terjedelmet) csak nagyobb költség és/vagy idő ráfordítással lehet megvalósítani, rövidebb határidő magasabb költségeket és csökkentett hatókört (terjedelmet) jelenthet, a szűkös költségvetés hosszabb végrehajtást és csökkent hatókört (terjedelmet) jelenthet.

Negyedik korlátként szokták említeni a minőséget vagy teljesítményt.

A szakterület eszköztárában szerepelnek azok a technikák és eszközök, amelyek lehetővé teszik a projektcsapatnak (és nem csak a projektvezetőnek), hogy úgy szervezzék a munkájukat, 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, feladatok 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ő, végrehajtásuk jól követhető és ellenőrizhető és megfelelő terméket szolgáltatnak. A párhuzamosan végrehajtható tevékenységek miatt a teljes projekt végrehajtási ideje általában kisebb, mint a teljes ráfordított idő összege. Meg kell különböztetni a feladat végrehajtásának időtartamát (angolul duration) a feladat végrehajtásához szükséges időráfordítástól (angolul work). Például gondoljunk egy padló cseréjére, ahol egy nap a padló lerakása, egy nap a lakkozás és két nap a lakk száradási ideje, azaz a kész padló ellőállítása 4 napba telik, de csak 2 napnyi tényleges munkaráfordítás szükséges hozzá.

[szerkesztés] Költség

A projekt végrehajtásának költsége több tényezőtől függ, mint például a munkaerő költsége, anyagköltségek, eszközök, épületek, berendezések bérlésének vagy megvásárlásának költségei, kockázati tartalékok, de tágabb értelemben ide számíthatók a pl. a tőkelekötés (a projekt végrehajtást finanszírozó tőke) költségei is. A költségek lehetnek változó költségek, amikor is a költség az igénybevétel idejével vagy mennyiségével arányos, vagy lehetnek fixek (anyag-, vagy eszközköltség). A fix költség alatt olyan költségket értenek, amelyek nagysága nem függ az igénybevétel idejétől, például egy, a projekt végrehajtásához szükséges eszköz beszerzési költsége - gyakorlatilag - nem időfüggő.

A projekteknél értelmezhető az úgynevezett ROI (Return of Investment - a befektetés megtérülése). Ezt a mutatót a projekt befejeződése után, egy megadott időben lehet meghatározni: amikor a projekt meghozta az eredményét. A mutatónak - speciális projektektől eltekintve - egynél mindenképen nagyobbnak kell lennie: a projektnek legalább annyi eredményt kell hoznia, mint amennyibe került. Az eredmény ebben az esetben a projekt eredményeként előállt változás hozta eredmény, nem a projekt költsége. Elméletileg a megtérülési mutatónak jobbnak kell lennie (a projekt eredményeként keletkező haszonnak legalább akkorának kell lennie, mint a projekt költsége, ezen felül még gazdasági eredményt is kell hoznia), mintha a projekt bekerülési költségét banki betétbe fektetnék.

Mivel a projekt ROI-ja, mint ahogyan a projekt indítási döntése kívül esik a projekt hatáskörén, a projektmenedzser felelőssége a költségkeret betartásáig terjed csak.

[szerkesztés] Hatókör

A hatókör (angolul scope, magyarul néha terjedelem) határozza meg, hogy a projektnek mi a feladata, milyen végeredményeket kell a projektnek előállítania, beleértve a végeredmény minőségét is. A hatókör egyben kijelöli, hogy mivel nem kell a projektnek foglalkoznia, ezeket hatókörön kívül eső (out of scope) feladatoknak nevezik.

A projekt hatóköre a körülmények változása, a kiindulási igények változása vagy egyéb, a tervezéskor nem látott, vagy várt események miatt változhat, viszont ez általában vagy a határidő, vagy a költségek módosulását vonja maga után. Lehetnek természetesen olyan hatókört érintő változások, amikor bizonyos feladatok 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 hatókörrel kapcsolatos változások kezelésére szolgálnak a projektmenedzsment változás kezelési eljárásai.

[szerkesztés] Főbb projektmemedzsment dokumentumok

A sikeres projektek dokumentálják az elérendő célokat és a termékeket. Ezeknek a dokumentumok biztosítják, hogy az érdekelteket (szponzorok, ügyfelek, projektcsapat) összhangban legyenek.

1. Projekt alapító dokumentum (Project Charter): Célja, hogy a projektet hivatalosan felhatalmazza a feladat elvégzésére és az ehhez szükséges erőforrásokat a projekt rendelkezésére bocsátja
2. Hatókör meghatározás (Scope Definition): Meghatározza, hogy mit fog megvalósítani a projekt: mi tartozik a projekt hatókörébe és mi nem, milyen termékeket kell a projektnek előállítania
3. Projektmenedzsment terv (Project Management Plan): Meghatározza, hogy hogyan fog megvalósulni a projekt

A projekt dokumentumok a legtöbb esetben egy mindenki által elérhető tárolóhelyen (pl. intranet, saját web lap) találhatóak. Az elfogadott dokumentumokon történő változtatás csak a projekt változáskezelési tervében leírt módon történhet.

[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, hatókör, 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, hatókör é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] 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:

1. Projekt indítási szakasz;
2. Projekt tervezési szakasz;
3. Projekt végrehajtási szakasz;
4. Projekt ellenőrzési és követési rendszer;
5. 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 menedzsment szervezetek

Számos olyan nemzetközi és szakmai szervezet létezik a világon, amelyek terjesztik és fejlesztik a projekt menedzsmentet és a projekt menedzsment szakmát. Néhány a tekintélyesebb szakmai szervezetek közül:

• Project Management Institute (PMI)
• International Project Management Association (IPMA)
• International Association of Project and Program Management (IAPPM)
• International Project Management Commission (IPMC)
• Association for Project Management (UK) (APM)
• Australian Institute of Project Management (AIPM)

[szerkesztés] Nemzetközi szabványok

Számos kísérlet történt a projektmenedzsment szabványosítására:

• Project Management Body of Knowledge (PMBOK Guide)
• PRINCE2 (PRojects IN a Controlled Environment - projektek ellenőrzött környezetben)
• APM Body of Knowledge 5th ed. (APM - Association for Project Management (UK))
• P2M (A guidebook of Project & Program Management for Enterprise Innovation, japán harmadik generációs projekt menedzsment módszertan)
• V-Modell (német projekt menedzsment módszertan)
• HERMES (Svájci általános projekt menedzsment módszertan, Luxembourgban és nemzetközi szervezetek által használt módszertan)
• Organizational Project Management Maturity Model (OPM3)
• ISO 10006:1997, Minőségmenedzsment - Minőség a projektmenedzsmentben
• JPACE (Justify, Plan, Activate, Control, and End - The James Martin Method for Managing Projects (1981-present))

Eddig nem készült olyan projekt menedzsment szabvány, amely a GNU Free Documentation License alá tartozna.

[szerkesztés] Szakmai minősítések

• Certified Project Manager (IAPPM minősítés)
• Project Management Professional, Certified Associate in Project Management. (PMI minősítések)
• Master Project Manager Certification from IPMC Commission

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

[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önyvben 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 hatókör - 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] Referenciák

1. ^ http://www.principles-of-scientific-management.com/
2. ^ http://www.boozallen.com/about/history/history_5
3. ^ http://www.pmi.org/info/PP_OPM3ExecGuide.pdf
4. ^ http://www.ruleworks.co.uk/cgi-bin/TUaz.exe?Guide=Prince2&XL=P&t=PRINCE2%20Knowledgebase

[szerkesztés] Irodalom

• Berkun, Scott (2005). Art of Project Management. Cambridge, MA: O'Reilly Media. ISBN 0 596 00786 8.
• Brooks, Fred (1995). The Mythical Man-Month, 20th Anniversary Edition, Adison Wesley. ISBN 0 201 83595 9.
• Heerkens, Gary (2001). Project Management (The Briefcase Book Series). McGraw-Hill. ISBN 0 07 137952 5.
• Kerzner, Harold (2003). Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 8th Ed., Wiley. ISBN 0 471 22577 0.
• Lewis, James (2002). Fundamentals of Project Management, 2nd ed., American Management Association. ISBN 0 8144 7132 3.
• Meredith, Jack R. and Mantel, Samuel J. (2002). Project Management : A Managerial Approach, 5th ed., Wiley. ISBN 0 471 07323 7.
• Project Management Institute (2003). A Guide To The Project Management Body Of Knowledge, 3rd ed., Project Management Institute. ISBN 1 930699 45 X.
• Stellman, Andrew and Greene, Jennifer (2005). Applied Software Project Management. Cambridge, MA: O'Reilly Media. ISBN 0 596 00948 8.
• Thayer, Richard H. and Yourdon, Edward (2000). Software Engineering Project Management, 2nd Ed., Wiley-IEEE Computer Society Press. ISBN 0 8186 8000 8.
• Whitty, S. Jonathan (2005). A Memetic Paradigm of Project Management. International Journal of Project Management, 23 (8) 575-583.
• Whitty, S.J. and Schulz, M.F. (2007). The impact of Puritan ideology on aspects of project management. International Journal of Project Management, 25 (1) 10-20.
• Pettee, Stephen R. (2005). As-builts – Problems & Proposed Solutions. Construction Management Association of America.
• Verzuh, Eric (2005). The Fast Forward MBA in Project Management, 2nd, Wiley. ISBN 0 471 69284 0 (pbk.).

• Görög, Mihály (2001). Projekt menedzsment. Kossuth.

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

• Troubled Project Specific Interest Gruop
• American Academy of Project Management
• Association for the Advancement of Cost Engineering, International
• International Research Network on Organizing by Projects
• International Project Management Association
• Project Management Association of America
• Association for Project Management
• The Project Management Institute
• The Australian Institute of Project Management
• The Institute of Project Management of Ireland
• Interactive Project Management Wiki