Projektmenedzsment

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 (Székely, 2002). 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 észszerűen megválasztott, erőforrás (idő, pénzt, emberek, anyagok, energia, hely) felhasználással járó tevékenységek sorozata.

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 pennsylvaniai 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 első 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, 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 interkontinentá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.

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]

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.

Kezdeményezé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 projektalapí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áltozott 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öltségek ugyan veszteséget jelentenek, de összehasonlíthatatlanul kisebbet, mint egy sikertelen projekt teljes költsége.

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ő.

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.

Követési és felügyeleti 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ó.

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.

A projektmenedzsment tíz 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
	Projektérintett-menedzsment

A PMBOK (6. kiadás) szerint a projektmenedzsment alapvetően az alábbi 10 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észt vevő ö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.
Projektérintett-menedzsment: A terület feladata a projektrésztvevők és érintettek (stakeholders) elkötelezettségének és projekt támogatottságának növelése

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 szemlé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.

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ó előállítása 4 napba telik, de csak 2 napnyi tényleges munkaráfordítás szükséges hozzá.

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 például 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égeket é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éppen 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.

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.

További korlátok

A tradicionális hármas korlát mellett további korlátokat is szokás említeni:

minőség
ügyfélelégedettség
kockázat

Minőség

Az 1960-as években megjelent a minőség, mint egyre fontosabb szempont a – nem csak projekt – menedzsment folyamatokban. E szempont előtérbe kerülése magával hozta a minőségi szemlélet megjelenését a – nem csak projekt – menedzsment folyamatokban.

A projektek esetében minőség alatt általában az "elvárásoknak való megfelelés mértékét" értjük, ahol az elvárások a projekt menedzsment folyamatainak előírásai. Némileg leegyszerűsítve a kérdést, azt mondhatjuk, a projekt minőségi mutatója az, hogy a végrehajtása alatt mennyire követi (vagy tér el) a folyamatokban meghatározott előírásoktól, szabályoktól (például a változáskezelés, dokumentációs, kommunikációs szabályok, jelentések tartalmi és formai követelményei, kockázatkezelési eljárások követése, betartása stb.).

A projektekben megjelentek a minőségbiztosítók, akik vizsgálják az eltéréseket, és javaslatokat adnak, milyen módon lehet minél teljeskörűbben követni ezeket az előírásokat.

Alapvetően meg kell különböztetnünk a projekten belül a termék minőségbiztosítást a projekt minőségbiztosítástól: a termék minősége alatt a projekt eredményeként létrejövő termék(ek)et értjük, míg a projekt "saját" termékei a menedzsment folyamatok saját, belső termékei (tervek, szerződések, jegyzőkönyvek, emlékeztetők, jelentések stb.)

Mindezek a tevékenységek idő- és erőforrás ráfordításokkal járnak, tehát mindenképpen növelik a projekt költségeit, és a minőséggel kapcsolatos járulékos tevékenységek újabb idő- és/vagy költség és erőforrás ráfordításokat jelentenek, tehát (ellentétes) hatással vannak a költség-, időkorlátokra.

A projektvezető

A projektvezető felelős a projektcélok megvalósulásáért. A projektvezető ritkán vesz részt közvetlenül a projekt végeredményének előállításához szükséges tevékenységekben, viszont biztosítja a folyamatos előrehaladást, és a különböző résztvevők közötti kölcsönösen hatékony együttműködést annak érdekében, hogy a projekt sikeres legyen.

Projektmenedzsment tevékenységek

A projektmenedzsment számos különböző típusú tevékenységet foglal 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 és végrehajtása
Dokumentációs és kommunikációs tevékenységek

Főbb projektmenedzsment dokumentumok

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

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
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
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 (például 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.

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 rendelkezésre. Meg kell jegyezni, hogy az általánosan elterjedt 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.

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 elfoglalt szerepeitől és felelősségeitől is.

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 hajtják végre az összes szakaszt, 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émamegoldá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.

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öltsé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 alkotni, mint például az extrém programozást és a scrum technikát a szoftver fejlesztéshez. Az extrém programozási technika általánosításával más projektekre kialakult az extrém projektmenedzsment, amely kombinálható a folyamat modellezéssel és a emberi kölcsönhatás menedzsment elveivel.

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 – szoftverfolyamatok fejlesztése és képessé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 együttműködések szemszögéből vizsgálja. Ez a közelítési mód alapvetően eltér a tradicioná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.

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.

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 nem jelenti azt, hogy nem jelentkezik túllépés akár időben, akár költségben (legrosszabb esetben mindkettőben) – 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ő ellenőrzési szintet: a túl sok ellenő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 feladataikat. Fontos viszont, hogy az auditor teljesen 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 ellenőrizheti, hogy a folyamatok valóban a terveknek 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

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 Archiválva 2010. október 10-i dátummal a Wayback Machine-ben)
International Project Management Association (IPMA)
Association for Project Management (UK) (APM)
Australian Institute of Project Management (AIPM)
International Project Management Commission (IPMC)
Hírközlési és Informatikai Tudományos Egyesület (HTE) Projektmenedzsment Szakosztály (TIPIK)

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:2003, Minőségmenedzsment – Minőség a projektmenedzsmentben
JPACE Archiválva 2006. augusztus 21-i dátummal a Wayback Machine-ben (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.

Szakmai minősítések

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

Lásd még: An exhaustive list of standards (fejlettségi modell) Archiválva 2006. szeptember 23-i dátummal a Wayback Machine-ben

Esettanulmányok

A Massawai kikötő megmentése, Eritrea 1942: A kikötőben kaotikus állapotok uralkodtak: gyakorlatilag megközelíthetetlen volt az elsüllyedt 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íttatta az elsüllyedt hajókat, rendbehozták a nagy úszó dokkot, a kikötői épületeket és berendezéseket pedig helyreállították. Bár a kapitá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ól képzett munkaerő, ő saját maga tervezte és menedzselte a munkákat. Ellsberg, mint rutinos szerző, 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öztetett halottról sikeresen elhitette a németekkel, hogy az egy repülő szerencsétlenség magas rangú katonai áldozata, "William Martion őrnagy", akinél, beosztá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, s elhitték, hogy a titkos haditervek valódiak, ezért átcsoportosították védelmi erőiket. Az akcióban részt vevő 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, 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.

Kapcsolódó szócikkek

Jegyzetek

↑ Principles-Of-Scientific-Management.Com. [2007. január 18-i dátummal az eredetiből archiválva]. (Hozzáférés: 2007. január 7.)
↑ Booz Allen Hamilton - History of Booz Allen 1950s. [2007. június 7-i dátummal az eredetiből archiválva]. (Hozzáférés: 2007. január 7.)
↑ Archivált másolat. [2007. március 22-i dátummal az eredetiből archiválva]. (Hozzáférés: 2007. január 7.)
↑ The PRINCE2 Guide - A to Z, FAQ and 1000+ Exam Questions. [2007. szeptember 27-i dátummal az eredetiből archiválva]. (Hozzáférés: 2007. január 7.)
↑ Gilinda: Hatékony projekttervezés: hogyan kerüld el a zsákutcákat? (angol nyelven). Gilinda new, 2023. február 21. (Hozzáférés: 2023. április 14.)

Irodalom

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

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

Megaprojects and Risk, Bent Flyvberg 2003, Cambridge University Press (ISBN 0-521-00946-4)

További információk

[1] Principles-Of-Scientific-Management.Com. [2007. január 18-i dátummal az eredetiből archiválva]. (Hozzáférés: 2007. január 7.)

[2] Booz Allen Hamilton - History of Booz Allen 1950s. [2007. június 7-i dátummal az eredetiből archiválva]. (Hozzáférés: 2007. január 7.)

[3] Archivált másolat. [2007. március 22-i dátummal az eredetiből archiválva]. (Hozzáférés: 2007. január 7.)

[4] The PRINCE2 Guide - A to Z, FAQ and 1000+ Exam Questions. [2007. szeptember 27-i dátummal az eredetiből archiválva]. (Hozzáférés: 2007. január 7.)

[5] Gilinda: Hatékony projekttervezés: hogyan kerüld el a zsákutcákat? (angol nyelven). Gilinda new, 2023. február 21. (Hozzáférés: 2023. április 14.)

[1]

[2]

[3]

[4]

[5]