A projektmenedzsment vagy a projektmenedzsment a projektek zavartalan lebonyolításának és a célok elérésének megszervezése . Ez a módszerek, technikák és specifikus irányítási eszközök alkalmazásából áll a projekt különböző szakaszaiban, a lehetőség értékelésétől a projekt befejezéséig.
Általánosságban elmondható, hogy a „ projekt ” olyan tevékenységek és cselekvések összehangolt összessége, amelyeket annak érdekében hajtanak végre, hogy meghatározott időn belül reagáljanak egy szükségletre a rá elkülönített erőforrások mozgósításával. Számos pontosabb definíció létezik együtt:
A projekteket megkülönböztetjük a műveletektől. A műveleteket fenntartható, folyamatos és ismétlődő folyamatokkal és erőforrásokkal hajtják végre. A projektek lényegében ideiglenesek, olyan jellemzőkkel rendelkeznek, amelyek egyedivé teszik őket (innováció, változás, a termék vagy szolgáltatás jellemzői), és sajátos megközelítést igényelnek.
Végrehajtása során a projekt mozgósítja a meghatározott erőforrásokat (emberi, anyagi, felszerelési, nyersanyagok, információk és pénzügyek).
A projekt várható eredményeit nevezzük kellékeknek, termékeknek vagy „ teljesítéseknek ” .
A projektmenedzsment hasonló a menedzsmenthez általában, de magában foglalja a projektek ideiglenes jellegét és egyediségét. Megkülönböztetünk:
Az általános projektmenedzsment módszerek függetlenek a termék megvalósítási folyamataitól. Így léteznek olyan általános projektmenedzsment-szabványok és adattárak , mint a PMBOK ( Project Management Body Of Knowledge ), a PRINCE2 ( PRojects IN Controlled Environments ), ICB ( International Project Management Association Competence Baseline ) és az ISO 21500 nemzetközi szabvány . Iránymutatásokat és bevált gyakorlatokat kínálnak, és javasolják a módszerek hozzáigazítását az egyes projektek sajátosságaihoz. Az ágazati projektmenedzsment módszerek integrálhatják a három komponenst, miközben magukban foglalják a jó üzleti gyakorlatot is.
Amikor a projektmenedzsment ugyanazon célkitűzéshez hozzájáruló projektek halmazához kapcsolódik, akkor programirányításról , projektprogramról, projektmenedzsmentről vagy projektportfólió- menedzsmentről beszélünk, az iparágaktól és az érintett projekt méretétől függően. A program olyan kapcsolódó vagy kapcsolódó projektek csoportja, amelyek irányítását összehangolják az előnyök, előnyök és az ellenőrzés ellenőrzése érdekében, ami nem lenne lehetséges a projektek egyénileg történő kezelésével. A programmenedzsmentet koordinálják, összekapcsolják, egyeztetik és figyelemmel kísérik, hogy az együtt csoportosított projektek megtarthassák stratégiai hozzájárulásukat.
A gyakorlatban „a projekt a végső cél felé fordult, alkalmazkodni kell a gyakori módosításokhoz, de ellenőrizni és megtervezni. Tehát minden módosítást meg kell tervezni. Különösen a projektnek dinamikusnak kell maradnia, és folyamatosan egyensúlyba kell hoznia a műszaki, költség- és időbeli korlátokat. ” Az összes művelet és taktika teszi a projektet háromszögbe, amely képviseli a minőség - költség - idő (QCD) egyensúlyát .
A projekt irányítása a szponzor feladata (angolul " Sponsor "). Nagyobb projektek esetében ezt a felelősséget együttesen egy szponzor elnökletével működő irányítóbizottság vállalhatja.
Felelősséget vállal a projekt menedzsment terheli a projekt vezetője . A projekt fontosságától és a hierarchikus szinttől függően ezt a szerepet egy projektmenedzser töltheti be .
A projektet egy projektcsoport végzi a projektmenedzser felelősségével.
Bonyolultabb projektek esetén a projektcsapat több független csapatból állhat, csoportvezető felelősségével. A projektmenedzser és a csoportvezetők ezután megalakítják a projektmenedzsment csapatot, amelybe a projekt koordinálásában részt vevő többi szereplő integrálható.
A kontextustól függően a projektben részt vevő szereplők vagy szervezetek szerepet kaphatnak a projektmenedzsmentben vagy a projektmenedzsmentben (lásd még a projektmenedzsment jellemzőit ).
Az érdekelt felek mindazok, akik közvetlenül részt vesznek a projektben, valamint a projektben részt vevő külső érdekeltek, akiket a projekt vagy annak eredményei befolyásolhatnak, függetlenül eredeti szervezeti felépítésüktől és hierarchikus szintjüktől. Azok a nagy projektek, amelyek valószínűleg jelentős hatással lesznek többre, időnként megkövetelik az érdekelt felek kezelő szoftverének használatát .
Az értékteremtési modell abból áll, hogy azonosítanak és kiválasztanak egy lehetőséget a projekt előtt. A projekt ezután létrehoz egy terméket, amely megfelel a célkitűzéseknek. Miután a projekt befejeződött, ez a termék hatásai révén eredményt („ eredményt ”) generál . Ez az eredmény hosszú távon lehetővé teszi az előnyök kihasználását.
A projekt eredményei a következők lehetnek:
A célkitűzéseket öt szempont kombinációjával lehet jellemezni:
Jó gyakorlat a „ SMARTE ” célok (specifikus, mérhető, megvalósítható, reális, időhöz kötött , etikus) használata.
A projekt szerződés tárgyát képezheti . Ez a szerződés belső lehet a vállalat számára az innovációhoz kapcsolódó fejlesztések esetében, vagy a specifikációk alapján kereskedelmi. A megosztott kockázat mértékétől függően a kereskedelmi szerződést több típus közül választják ki, és szerződéses tárgyalások útján alkalmazzák. Például: kézben lévő egykulcsú szerződés, a szerződés előrehozása, költségtérítési szerződés ( költségtérítés ), amely tartalmazhat bónuszokat és büntetési gondokat ( rezsi ).
A projekt csapat irányításának pszichoszociális aspektusát illetően Maders öt egymást követő fázist különböztet meg:
Ezenkívül a projekt utáni felülvizsgálatként ismert hatodik szakasz is ajánlott, különös tekintettel a terméktervezési projektekre.
A komplex projektek gyakran több szakma és tudományág bevonását igénylik. A nagy kihívás tehát az, hogy hozzon létre egy multidiszciplináris csapat, amely egyesíti a szakértők képes lefedni az igényeinek a különböző osztályok alkotó jogi , marketing , informatikai , műszaki szervezés , a személyzet képzése, szervezés , logisztika , stb kommunikáció , stb
A legújabb tanulmányok azonosítják a 4 Ps-t, amelyek együttesen leírják a projektcsoportok teljes kultúráját:
A projektmenedzsment a következő folyamatcsoportokat igényli : kezdeményezés, tervezés, megvalósítás (vagyis a projekt befejezése), ellenőrzés vagy elsajátítás (azaz felügyelet és nyomon követés) és lezárás (azaz befejezés). Ezek a folyamatcsoportok nem a projekt egymást követő szakaszai, hanem olyan tevékenységeknek felelnek meg, amelyek az egész életciklus alatt alkalmazhatók. Tehát, ha például a tervezés a projekt kezdetén történik, akkor az a tág körvonalakra korlátozódhat, és fázisonként vagy akár munkacsomagonként is megvalósítható.
Általánosságban elmondható, hogy a projekt elindításáról szóló döntés előtti tevékenységek a következő tevékenységeket tartalmazhatják:
A projekt eldöntése után a tevékenységek a következők:
A projekt elindításától kezdve elengedhetetlen a különféle eszközök ( irányítópult , kockázatkezelés , tervezés , projektellenőrzés stb.) Bevezetése, amelyek lehetővé teszik a projekt teljes élettartama alatt történő irányítását a siker biztosítása vagy javasolja esetleges elhagyását.
A tét a projekt előrehaladásának reprezentatív egy vagy több mérföldkőjének meghatározása vagy meghatározása minden szakaszhoz . Ez lehetővé teszi a projekt megfelelő felépítését az idő múlásával azáltal, hogy garanciákat nyújt a projektvezetőnek. Ez megkönnyíti az ütemezés és a munka előrehaladásának nyomon követését. A felülvizsgálat és az ellenőrzési terv szervezi az előrehaladás és a minőség mérését.
A mérföldkövek a projekt előrehaladását mutatják. Ellenőrzési pontként szolgálhatnak (angolul: „ project gate ”), és feltételezhetik a következő szakasz bekapcsolását. A fázisváltozás felülvizsgálata során hozott döntések stabil elemek, amelyekre a projekt többi része felépíthető. A tét kevésbé foglalkozik az egyes fázisok tartalmával, mivel eredményének értékelése, az ügyfél (vagy a projekt tulajdonosa ) köteles dönteni.
A mérföldkövek a projekt életciklusától függenek, például:
Néhány további megjegyzés:
A projekteket szakaszokra lehet bontani. Ezek aztán megfelelnek a célok eléréséhez szükséges fő lépések egymásutánjának. Mindenekelőtt kronologikus felosztás. Minden fázis tevékenységek részcsoportjaira bontható, egyszerű funkcióval: feladatok. Minden feladatot a szükséges alapanyagok, termékek vagy alkatrészek jellemeznek: ezek az inputok vagy előfeltételek (dokumentum, specifikáció, elérhetővé tett gép, szabvány, képzett és operatív operátor, tesztkészlet stb.). A feladat egy vagy több kimeneti terméket biztosít, ezek a kimenő vagy leadható objektumok ( szoftver , reklámfüzet, tanfolyam támogatás, műszaki lap stb.). Az egyik feladatból érkező eredmények szükséges inputként szolgálhatnak egy másik feladathoz: ekkor függőség van a két feladat között.
A projekt összetettebb hierarchikus bontásnak is alávethető. Általánosan használt módszer a projektmunkák lebontásának szerkezete ( OTP) , más néven munkabontási struktúra (WBS).
Legmagasabb szinten ez a bontás lehet időrendi (fázisok), termékek / alkatrészek mintájára, vagy akár szervezeti (például: termelőhelyek, kereskedések, részlegek). Ezeket az elemeket ezután maguk is egyszerűbb elemekre bontják, és így tovább, amíg a feladatok megtervezéséhez és végrehajtásához elemi bontás megfelelő szintjét el nem érik. Ennek a folyamatábrának a legrészletesebb szintje megfelel a munkacsomagoknak (angolul " munkacsomag "), amelyekhez a szükséges inputok, teljesítések, folyamatok és a csoportra vagy kinevezett személyre bízott felelősség (a munka méretétől függően) projekt), és ez a bontás optimális szintjén szükséges:
Az OTP módszer nagyon rugalmas. Valójában statikusan alkalmazható, az egész OTP-t ezután meghatározzuk a projekt kezdetekor, vagy dinamikusan, a kezdeti OTP-t a bomlás első szintjeire korlátozzuk, és a részletesebb bontást szakaszonként, fázisonként hajtjuk végre. Ezt az utolsó alkalmazási módot "progresszív kidolgozásnak" nevezik, és különösen alkalmas innovatív projektek számára.
A hierarchikus lebontás egy másik változata a termékbontási struktúrát használja . Ez abból áll, hogy a projekt által előállított terméket egyre több elemi komponensre bontják. Az eredmény felhasználásával folyamatábrát készítenek, amely bemutatja a termék függőségeit. Szükség esetén OTP származhat belőle.
A tervezés olyan eszköz, amely lehetővé teszi a projekt előrehaladásának nyomon követését, az emberi és pénzügyi erőforrások elosztásának prioritása és az esetleges intézkedések előrejelzését, amelyek lehetővé teszik a különféle mérföldkövek betartását , különösen a kritikus út elemzésével, az alábbiakkal : kritikák és rendelkezésre álló források.
Az ütemezésnek meg kell határoznia a feladatok ütemezését, figyelembe véve a projekt különböző szakaszai vagy munkacsomagjai közötti feladatok függőségét , e feladatok korlátjait és a szükséges erőforrásokat.
Az ütemezési technikák közül például megemlíthetjük:
A projektmenedzsment egy nehéz művészet, amelyben a projektvezetőnek legjobb esetben improvizálnia kell. A kockázatok csökkentése vagy a projekt entrópiájának ésszerű szinten tartása érdekében a tapasztalatok kiemelik a fő elveket. Alan Davis 201 alapelvet sorolt fel, amelyek a szoftverprojektekre vonatkoznak.
Ezenkívül James O. Coplien a Projektmenedzsment jelenségének a gyakorlatra összpontosított aspektusát kínálja . A gyakorlat egy elv hivatalos alkalmazása, amely összehasonlítható a szoftverfejlesztésben alkalmazott tervezési mintával . Ebben az értelemben az Extreme programozási módszer olyan gyakorlatokat is kínál, mint:
Ezek a gyakorlatok útmutatást nyújtanak a kiválasztott szervezeti bontásban. Az Agile módszer szerint , ahogy a szoftveres tervezési minták összekapcsolhatók, a szervezeti tervezési minták grafikon és így szervezeti nyelv formájában is össze vannak szervezve . Ezek a minták ezután megfelelnek a projektmenedzser rendelkezésére álló eszközöknek, amelyek összehasonlíthatók a zenész mérlegével. Ez a nyelv lehetővé teszi annak a szervezetnek a kiválasztását (az okot), amelyet be lehet integrálni a projekt-csapatba.
Ez a korlátozott választás a vállalati kultúrához hasonló jelenséggel magyarázható . Az üzleti életben a változás kezelése a legnehezebb. A cégnek szüksége van rá, az egyének elutasítják. Bár ezt az elutasítást az élvezet elve magyarázza (amely az energiatakarékos vélemény elve, amely további magyarázatot érdemel ), azt fogjuk találni, hogy a csapatot alkotó emberek számára a lehető legkellemesebb tartomány a lehető legegyszerűbb átmenetek végrehajtása .
Tehát, ahogy azt egy néhány sornyi kódot, hogy menjen a Singleton a Design Pattern Factory , mozgó pár programozás gyakorlat megköveteli a kis erőfeszítést, hogy a gyakorlatban a kollektív kód Tulajdonosi (kód tartozik mindenkinek)..
Ez egy módszer, amelyet a projekt vezetésére használnak, nem a tervezésre és a feladatok végrehajtására összpontosítva, hanem a projekt értelmére és céljára: a kérdésekre összpontosítva . Ez a módszer különösen alkalmas innovációs projektekhez , különösen akkor, ha az alkalmazott technológiák és a piaci igények folyamatosan fejlődnek .
Egy-három mester vagy vezető kérdést kell meghatároznia a projekt csapatának, hogy megadja a projekt átfogó jelentését . Ezután generáljuk az upstream téteket, amelyek egymást követő célok, amelyek lehetővé teszik a főtét (ek) elérését.
A projekt életciklusa a termék megvalósításának fázisainak és feladatainak megszervezése. Ez attól az iparágtól és szakmáktól függ, amelyekre a projektmenedzsmentet alkalmazzák, valamint a választott gyártási folyamatoktól.
A vízesés modellje egy projekt lineáris és szekvenciális felosztásának felel meg. A szakaszok egymásutánja reagál a feladatspecializáció logikájára.
A számítástechnikában a szoftverfejlesztés területén ez a modell általában fázisok egymásutánját tartalmazza: az igények (vagy követelmények ) kifejezése , elemzés , tervezés, programozás , tesztek és üzembe helyezés. Az egyik változat tartalmaz egy upstream tervezési fázist. A "programozás" kifejezést gyakran a "megvalósítás", a "megvalósítás" vagy a "megvalósítás" váltja fel a szoftver megvalósításához szükséges egyéb tevékenységek figyelembevétele érdekében. Minden lépés meghatározza a következő fázisokban használt teljesítéseket.
Ez a módszer ellentmondásos, mivel nehéz a reális tervezés a projekt előtt, és fennáll annak a kockázata, hogy a tesztek során azt találják, hogy a szoftver nem felel meg a valós igényeknek. Ironikus módon a cikk, amely ezt a módszert népszerűsítette, valójában kiemelte főbb kockázatait, és ötféle fejlesztést szorgalmazott a modellben, hogy figyelembe vegyék az egymást követő lépések iteratív jellegét, különös tekintettel a követelmények kidolgozására.
A projekt szakaszokra osztása az 1980-as évektől általánosan alkalmazott módszer a projekt befejezéséhez, a minőség, a költség és az idő elveinek tiszteletben tartása mellett.
Mindegyik fázishoz tartozik egy lépésenkénti felülvizsgálat (gyakran szerződéses ), amelynek célja a letelt fázis érvényesítésének formalizálása, mielőtt továbblépnénk a következő szakaszba. A felemelkedő rész (validálás) fázisai mindegyike a leereszkedő résszel (tervezés) ellentétes fázisra utal, így az érvényesítési szakasz részletességi szintje pontosan megegyezik a tervezés fázisának részletességi szintjével (például integrációs tesztek) műszaki előírásokhoz kapcsolódnak).
Az agilis módszerek megjelenése iteratív és inkrementális életciklusokat eredményezett. A fázisok lebontását ekkor már nem a feladatok specializálódásával (ellentétben a kaszkádmodellel vagy az V-ciklussal) végzik el, hanem a termék egymást követő változatával, amelyek mindegyike megfelel a termék érési szintjének.
Ezután az igényeket a projekt kezdetekor már nem teljesen és kimerítően azonosítják, hanem nagy vonalakban azonosítják, majd a projekt előrehaladása során dinamikusan és a felhasználókkal szoros együttműködésben (fejlesztés progresszív) elmélyítik vagy finomítják. Az agilis projekt életciklusai gyakran használják a blokkidő-kezelést az egymást követő iterációkhoz.
Ebben a szakaszban a cél a projekt célkitűzéseinek meghatározása, azaz annak meghatározása, hogy mi fog szerepelni a projekt célkitűzéseiben.
A projektmenedzsment célját világosan meg kell határozni, számszerűsíteni és keltezni kell. Az eredménynek meg kell felelnie az előre meghatározott minőségi és teljesítményi előírásoknak, a legalacsonyabb költséggel és a lehető legrövidebb idő alatt.
Egyrészt megbecsülik, hogy a várható haszon arányos lesz-e az elvégzett beruházásokkal és a projekt becsült költségével. Sok projekt esetében ez határozza meg a beruházás várható megtérülését (vagy pontosabban: megtérülését ). Meg kell azonban jegyezni, hogy minden projektnek nem feltétlenül van célja a pénzügyi nyereség elérése: egy projekt elindítható azzal a céllal, hogy javítsa az adminisztráció felhasználói számára nyújtott szolgáltatásokat, vagy javítsa a társaság társadalmi légkörét - ezekben esetekben a befektetés megtérülése nem feltétlenül mennyiségi.
Másrészt a megvalósíthatósági tanulmány meghatározza azt is, hogy a szervezet képes-e befejezni a projektet. Különösen az a kérdés, hogy rendelkezik-e a szükséges készségekkel, erőforrásokkal és forrásokkal.
Elemezzük:
A projekt csak akkor indul igazán, ha ez az első szakasz sikeres.
Indítási vagy inicializálási szakaszEz az inicializálási szakasz lehetőséget nyújt a következők meghatározására:
Mivel egy projekt definíció szerint egy újítás a szervezet számára, sok ismeretlen dolognak van kitéve. Különböző összetevőit (tervezés, feladatok, ütemezés stb.) Ezért rendszeresen újra kell értékelni, hogy azok fejlődjenek, ugyanakkor garantálni kell, hogy a projekt továbbra is indokolt maradjon az eredetileg elvégzett értékeléssel kapcsolatban (a beruházás megtérülése, a jelentőségi kockázatok) stb.).
Általános tanulmányi szakasz és részletes tanulmány (vagy specifikációk)Ennek a szakasznak a célja annak megtervezése vagy meghatározása, hogy mit kell tenni vagy gyártani a cél elérése érdekében (esetleg specifikáció kidolgozása ). Ezek a tanulmányok magukban foglalják a projektmenedzsmentet és a projektmenedzsmentet .
Néha beszélünk kifejezése szükségletek vagy általános előírásokat, amikor ezeket teljesítéseket a „funkcionális” és a felhasználók által kifejezett, és mi majd ezt a kifejezést előírásokat (vagy részletes leírások) további műszaki dokumentáció, illetve minden esetben, amelyek részletezik, valamint a belső működésére a szoftver (például egy informatikai projekt esetében) várható.
Kutatási szakasz és megoldások meghatározása a projektvezető számáraEz a szakasz különböző technikai és funkcionális megoldások vagy architektúrák tanulmányozásából áll, a készségek, a felszerelés, a határidők, valamint a pénzügyi és marketing szempontok szerint. Ezután a döntéseket modellek vagy prototípusok gyártásával és esetlegesen tesztpiacon történő forgalmazással kell igazolni . A mért eltérések lehetővé teszik a választások korrigálását.
Az informatikai projektekben ez a szakasz figyelembe veszi az urbanizációt és az építészeti szempontokat .
A piacon létező megoldás kiválasztásakor ( különösen a szoftvercsomagok esetében ) ez a szakasz az ajánlati felhívás körül forog .
A megvalósítás és az ellenőrzés vagy a gyártás szakaszaEbben a szakaszban hajtják végre vagy gyártják a projektet, vagyis azokat a feladatokat hajtják végre, amelyek lehetővé teszik az új termék, áru vagy szolgáltatás megvalósítását. Az informatikai projektekben ez a szakasz teszi lehetővé a szoftver felépítését .
E feladatok előrehaladásának és a határidők betartásának ellenőrzésére projektmenedzsment eszközöket használnak, különösen olyan szoftvert, amely késedelem vagy határidők túllépése esetén lehetővé teszi a projekt többi részének újratervezését.
Ebben a fázisban elvégzik a teszteket is : egység tesztelés , integrációs tesztelés , rendszer tesztelés .
Bevételelemzési lépésAmint a szállítmány elérhetővé válik vagy beérkezik, ellenőrzéseket kell végrehajtani annak ellenőrzése érdekében, hogy a gyártott eredmény megfelel-e a specifikációk során leadott megrendelésnek. Az ellenőrzéseket szigorú elfogadási tesztek formájában hajtják végre az elkészített tesztkönyvekből.
Az elfogadó szakasz végén aláírják a végleges elfogadási jelentést.
A projekt összetettségétől függően globális ellenőrzési szekvenciákra lehet szükség.
Amikor alvállalkozói szerződést alkalmaztak, a recept vége fontos stádiumot jelent, mert kiváltja a jogi garancia időszakát, amely alatt a kérelmező felléphet szolgáltatójával szemben.
Terjesztési vagy bevetési szakaszA terméket a piac vagy a felhasználók számára elérhetővé teszik, itt a kommunikációs politika és általában véve a kísérő változás között mozog.
Ebben a szakaszban a projekt befejeződött, és eredménye (termék, szolgáltatás, szervezetváltás stb.) Belép az üzemeltetési szakaszba. A projekt eredményéért a felelősséget átruházzák a menedzsmentre (projekt szponzor), amelynek meg kell szerveznie a projekt utáni szakaszát:
A monitoring eszközöket a projekt előkészítése után azonnal létrehozták, egyúttal a teljesítmény és a minőség célkitűzéseinek meghatározásával .
Projekt utáni áttekintés vagy PPRA projekt utáni felülvizsgálatnak három fő előnye van. Először is, a korábbi projektekből való tanulás segíthet megvédeni a már elkövetett hibák ismétlését. További előny, hogy a levont tanulságok terjesztése fontos, és a PPR egy másik kiegészítő módszert jelent, saját előnyökkel az adatbázisok és a személyzet rotációja szempontjából. Végül a PPR hozzájárul a vállalat folyamatos fejlesztési folyamatához .
A PPR megvalósításába beavatkozó számos tényező befolyásolja annak hatékonyságát, különösen a tudásmegosztás tekintetében. Különösen megjegyezték, hogy az időzítés, a kiválasztott résztvevők, a hely, a moderátor jelenléte, időtartama, a tárgyalt téma, az ismeretek létrehozásának ösztönzésére tett intézkedések, az alkalmazott dokumentáció és az ismeretek terjesztésének módszerei. pozitívan befolyásolhatja a projekt utáni felülvizsgálatok hatását .
A kockázatkezelés arról szól, hogy biztosítsuk az összes jelentős kockázat ellenőrzését. Annak érdekében, hogy ne feledkezzünk meg egy kockázat kezeléséről, folytatjuk a készletüket (kockázati portfóliójuk). A népszámlálás összefoglalója a projekt kockázati irányítópultja. Az összefoglaló projektkockázati irányítópult létrehozása a kockázatok kezelésében elért eredmények nyomon követésére szolgál.
A tisztán számviteli módszer esetében a megközelítés abból áll, hogy a kockázatokat nem valószínű és valószínűre osztják. A valószínűségeket haladó vagy elemi megközelítések, például FMEA és Farmer diagramja segítségével kategorizálják. Ez abból áll, hogy meghatározzák a kockázati szinteket, figyelemmel kísérik a kockázati szint változásait és a projekt végrehajtása során megjelent új kockázatokat annak érdekében, hogy prioritásként kezeljék a kockázat mérséklése érdekében végrehajtandó intézkedéseket . Ez segítséget nyújt a projektvezető , felügyelője, auditorok, menedzserek, kockázatkezelés és esetlegesen az érintett üzleti szektort igazgató bírák vagy vezető hatóságok döntéshozatalában , ha van ilyen.
A kockázatelemzés a kockázatok súlyosságának meghatározásából áll. Ettől a súlyosságtól függően választanak egy kockázati reakciót. Ez a döntés lehet a semmittevés vagy a cselekvési terv elkészítése:
A projektmenedzsmentben gyakran felmerülő problémák egy része az idő és a költségvetés túllépése. A Standish Group által évente végzett tanulmány szerint az Egyesült Államokban az informatikai projektek csupán 16,2 % -a van időben, költségvetésben és specifikációban. Másrészt a projektek 52,7 % -a túllépi költségvetését, befejezési határidejét és / vagy nem felel meg a specifikációknak. Még 31,1 % -os lemorzsolódás is van. Hasonló a helyzet az építőiparban és a közmunkában, ahol sok a sodródás. Flyvbjerg és munkatársai tanulmánya. Hasonlóképpen, az építési és a közmunkaügyi szektorban mind a tervezés, mind pedig a költségvetés tekintetében nagyon magas a túllépés.
| Túllövések | Útvonalak | Hidak és alagutak | Energia | Vasutak | Gátak | Szoftver | olimpiai játékok |
| A költségvetés túllépése | 20% | 34% | 36% | 45% | 90% | 107% | 156% |
| A túllépés gyakorisága | 10-ből 9 | 10-ből 9 | 10-ből 6 | 10-ből 9 | 10-ből 7 | 10-ből 5 | 10-ből 10 |
| A szállítás késedelme | 38% | 23% | 38% | 45% | 44% | 37% | 0% |
| Időtartam években | 5.5 | 8.0 | 5.3 | 7.8 | 8.2 | 3.3 | 7.0 |
Sok kutatás célja a kudarc okainak azonosítása. Többféle lenne: keretbe foglalja, hiányos vagy pontatlan specifikációkat, a költségek és a határidők alábecsülését, előre nem látható technikai nehézségeket, erőforrások hiányát, koordinációt, a zöld fény hatását, ahol az egyes alprojektek zöld utat adnak, miközben összességében nem működik. De minden erőfeszítés ellenére Hofstadter törvénye érvényes: "egy projekt mindig hosszabb ideig tart, mint gondolnád, még a Hofstadter törvényét is figyelembe véve". A megfigyelt súlyos korlátozásokra tekintettel a projekt folyamatának másik fogalomalkotására lenne szükség, amely elkerüli a projekt szakaszainak pontos analitikai lebontását. Ezt a fajta fejlődést már régóta remélték, a minőségi megoldásnak van néhány lehetősége.
Egyáltalán nem szabad megfeledkeznünk az emberi vonatkozásról és a kommunikációról. A projekt érintettjeinek be kell tartaniuk a célkitűzéseket, és a projekt során ragaszkodniuk kell ahhoz, hogy ne szóródjanak szét különböző célkitűzések között. Ezenkívül a projekt különböző szakaszaiban, különféle formákban, a közvetetten érintettekkel is kommunikálni kell.
A projekt igazgatója vagy a projektmenedzser természeténél fogva felelős a projekt sikeréért, vagyis a meghirdetett ütemtervben és költségvetésben szereplő célok eléréséért. Ennek eredményeként nehéz számukra, hogy mind „kívül”, mind pedig “belül” legyenek, hogy megkapják a szükséges távolságot ahhoz, hogy a projekt egészének előrehaladásáról teljesen objektív képet kapjanak.
Hogy támogassa a projektigazgatót vagy a projektmenedzsert projektje sikerében, először egy új funkciót fejlesztettek ki először Kanadában: a "projektóra" .
Feladata:
Van egy sor szabvány, módszer és modell, amely bemutatja a legjobb gyakorlatokat.
A projektmenedzsment különböző érettségi modelljei között találunk néhány közös jellemzőt :
Az európai űriparban a projekt irányítója a következőket kezeli: