TUDÁSTÁR _

Hasznos információk, tanácsok

Folyamatosan bővülő tudástárunkat azért hoztuk létre, hogy hasznos információkkal, tanácsokkal szolgáljunk látogatóinknak az üzleti élet alábbi területein:

A projekt vezetésről általában

„A projekt nemcsak hogy időre elkészült, de maradéktalanul teljesítette a kitűzött célokat és még a költségkeretet sem lépte túl." Így hangozna egy projektzáró vacsora ünnepi beszéde… a paradicsomban. A mi világunkban sokszor másképpen történnek a dolgok.

Az emberek minden korszakban végeztek feladatokat, egyszerűbbet vagy komplexet, de a projekt és a projekt menedzsment kifejezések, ilyen értelemben viszonylag új szavai az emberiségek. A projekt tehát egy egyszeri, komplex feladat, amelynek vannak céljai, költségvetése és határideje. Ez az ún. 'projekt szentháromság' vagy mágikus háromszög, amely keretet szab a feladatnak. Ezt a háromszöget terjesztettük ki a DLM gyakorlatában.

Manhattan Project. Ez az első alkalom, az atombomba kifejlesztése, amikor egy nagyszabású feladatot ezzel a szóval illetnek. A szó eredetileg a latinból jön és azt jelenti: valamit előre dobni, hajtani. Később a menedzsment tudományok egyre nagyobb térhódításával a projekt menedzsment is önálló tudományággá vált. Az ötvenes évektől kezdve aztán egyre népszerűbb project módszertanok segítették az olyan újításokat, mint a színes televízió kifejlesztése, az Apolló-program vagy az Airbus megalakotása.

Projekt vezető portré

„Az operatív vezetés fenntartja a működést, a stratégia megmutatja az irányt, de a projektmenedzsment az a hajtóerő, amely előre viszi a szervezetet.” -

Joy Gumz

(Project Audit, ISAO)

A projekt menedzsment népszerű eszközei egészen Ford idejéig nyúlnak vissza. Henry Ganttnak, aki a tömeggyártás időbázisú tervezésével foglalkozott, köszönhetjük a Gantt-diagramot. Alkotótársa Frederick Winslow Taylor, a tudományos menedzsment atyja, aki kitalálta a tevékenységfelbontási rendszert (WBS – work breakdown structure). A hadiipar, az építőipar és tömeggyártás számára ezek az eszközök sokszor forradalmasították a gyártást, a feladatok szervezését és végrehajtását. Az ötvenes években aztán további tudományos módszerekkel egészült ki a már meglévő módszertan. Ezek a PERT (programkiértékelési és felülvizsgálati technika) és a kritikus út számítás voltak. Mindkettő azt a célt szolgálja, hogy feladatokat, azok kapcsolódásait megmutassa, illetve segítsen azonosítani a kritikus tevékenységeket.

A hatvanas évekig javarészt az Egyesült Államok az, amely ország leginkább gazdagítja ezt a menedzsment tudományágat, később azonban Európa is felzárkózik. 1969-ben az USA-ban megalakul a PMI (Project Management Institution), amely európai versenytársa, az IPMA (International Project Management Association) megalapítására adott válasz volt. Mindkét szervezet a projekt menedzsment tudományok népszerűsítésére és a módszertanaik terjesztésére törekedtek.

A háromszög szárai

A projektháromszög minden szára egy-egy korlátot jelent: terjedelem (scope), határidő és költségek. Az egység egyben azt is mutatja, hogy nem lehet egyik korlátot sem megmozdítani, változtatni a többi változása nélkül.

Üzleti tervezésnél sokszor használják a S.M.A.R.T modellt, azaz a cél legyen pontos (specific), mérhető (measurable), megvalósítható (achievable) lényeges (relevant)) és határidős (time-bound).

Idő

Egy projekt időbeni lefutását általában az elkülöníthető feladatok időigényének összeadásával számoljuk ki. A munka ilyen módon való megbontását tevékenységfelbontási rendszernek (WBS – work breakdown structure) hívjuk. Az időzítésben legfontosabb, hogy kiszámítsuk a kritikus utat, amely azon tevékenységek láncolata, amelyben nem szenvedhetünk időbeni csúszást, mert akkor a projekt véghatárideje is csúszik.

Költségek

A projekt költségvetése többféle költségnemből áll össze. Itt is vannak fix és változó költségek, amelyeket viszonylag könnyű tervezni és figyelemmel kísérni, és vannak nem explicit költségek, mint például a projekt csapat erőforrás elvonása a szervezettől. Manapság a projektek vezetésére készített szoftverek megfelelő paraméterezés után nagy segítséget jelentenek a költségek tervezésében és nyomon követésében.

Terjedelem

A terjedelem minél részletesebb meghatározása a legfontosabb feladat. Ennek fényében lehetséges meghatározni az idő és költségtervet. A terjedelem, idegen szóval scope, a projekt által elérni kívánt eredményeket tartalmazza. A célok meghatározásánál törekedni kell, hogy minél egzaktabb és mérhető módon határozzuk meg azokat, hiszen csak így lehetséges a projekt teljesítményének pontos mérése.

A projektmenedzsment klasszikus háromszögét mindenki ismeri, aki valaha részt vett projektben vagy projektmenedzsment tréningen. Mi azonban a gyakorlatban azt látjuk, hogy ez a háromszög valójában egy ötszög: két olyan további tényezővel egészül ki, amelyek nélkül nem lehet sikeres egy projekt.

Elégedettség

Az egyik – és talán a legfontosabb – a projekt által érintettek elégedettsége: akár a vevők, a döntéshozók, a projekten dolgozó kollégák és a teljes szervezet, amelynek el kell fogadnia a változást. Az ő elvárásaik felmérése már a tervezés fázisában fókuszt kell kapjon. A projekt kivitelezése során az érintettek körének megfelelő menedzselése nélkül a projekt nem tud valódi eredményt hozni, így a projektnek kiemelt figyelmet kell fordítani a változáskezelésre is.

Minőség

A másik kulcselem a minőség. Ha nem tartjuk folyamatosan fókuszban, könnyen áldozatul eshet az időnyomásnak vagy a költségkeretnek. Minden újratervezésnél fel kell tenni a kérdést: hogyan hat ez a leszállítandók minőségére? Ha a terjedelemből engedünk a határidő tartása érdekében, vajon sérül-e az elvárt szint? És létezik-e jobb megoldás, amellyel mindegyik cél megőrizhető?


A projekt termékei

A projekt különböző szakaszaiban úgynevezett projekt termékek készülnek. Ezek olyan dokumentációk, amelyek egy-egy területre vonatkozólag tartalmazza a projekt feladatit, elvárásait. A legfontosabb dokumentumok a teljesség igénye nélkül a következők:

Megvalósíthatósági tanulmány

A leginkább business case néven emlegetett dokumentum célja, hogy bemutassa a szükséget és alternatívát vagy több variációt is bemutasson annak betöltésére. Az ilyen dokumentumok szerves része a pontozó kártya (score card), amely egy a végső döntést objektív adatokkal támogató eszköz.

Projekt alapító dokumentum

Ez a projekt alkotmánya. Itt részletezzük a működés kereteit, az elvárásokat, a terjedelmet, határidőket, a projektcsapatot.

Követelmény specifikáció

A projekt fajtájától függően szükség lehet egy olyan dokumentációra, amely nagy mélységben foglalkozik a megvalósítandó célokkal. Ezeket gyakran külső tanácsadó cég segítségével készítik el.

Változáskezelési eljárás

Ebben a dokumentumban azt az eljárásmódot szokás lefektetni és bemutatni, amely az induláskor elfogadott terjedelemben vala-milyen módosulást okozó események kezelésére szolgál. Az eszkalációs eljáráson túl azt is lefektetik, hogy milyen szem-lélettel kell megítélni az esetleges változásokat, azaz mi tekinthető még a projekt eredeti terje-delmének és mi nem.

Kockázatkezelési terv

Ebben a dokumentumban váz-oljuk fel azt az eljárási módot, ahogyan a kockázatokat kezeljük. Bemutatásra kerülnek a kockázatok értékelési módjai, illetve a különböző felelősök és felelősségi területek. Használatban ez az eszköz a projekt során beazonosított kockázatok listáját tartalmazza, illetve tételesen a kockázatok kezelésének részletes tervét, és  a kapcsolódó lépések leköve-tését.

Változáskezelési és Kommunikációs terv

A változáskezelési terv összesíti a változáshoz szükséges tevékeny-ségeket és leszállítandó doku-mentumokat. Ezekből az egyik legfontosabb a kommunikációs terv, melyben összefoglalásra kerül a projekt külső és belső érintettjeivel való kommunikációs stratégia. Kikkel, miről, milyen gyakran és milyen csatornán kommunikálunk?

Projekt terv és PMO dokumentumok

A projekt tervben felvételre kerülnek a feladatok, azok határidői, felelősei, a különböző feladatok közötti függőségek. Leggyakrabban ezt valamilyen célszoftverrel készítik és vezetik a projekt teljes időtartama alatt. A projekt tervhez kapcsolódnak a PMO dokumentumok, melyekben részletesebben vezetjük a feladatokat és azok státuszát, kockázatokat, függőségeket, erőforrás igényeket.

Projektzáró dokumentum

A projekt végén ez a dokumentum összegzi az erőfeszítések végeredményét. Amiképpen a projekt a projekt alapító dokumentummal indul, úgy a projekt lezárása nem képzelhető el a projektzáró dokumentum nélkül. Bemutatja, hogy a célokat elérték-e, milyen minőségben; és hogy a projekt cél időben és minden érdekelt szervezet megelégedés-ére készült-e el.

Tanulságok adatbázisa

Egy-egy projekt rengeteg új tanulsággal szolgálhat. A tanulságok adatbázisa egy olyan tudásbázis, amelybe a projektvezető felvezeti a tanulságokat, azokat a módszereket, megoldásokat, amelyeket a projekt során ismert meg a projek-tcsapat.

Csapat munkában

Módszertanok, megközelítések

A legtöbb esetben a projekteket valamilyen módszertan szerint vezetik. Mint az élet oly sok más területén, itt sincsenek abszolútumok. Hit kérdése, hogy ki mire esküszik, mint üdvözítő projekt módszertan. Nagyobb vállalatok, egyetemek, tanácsadó cégek mind-mind rendelkeznek saját módszertannal, legtöbbször ezek nagyjából átfedésben vannak, leginkább a hangsúlyokban vannak különbségek.

A különböző projekt megközelítésekben azonban már vannak jelentős eltérések. A legfőbb megközelítéseket érdemes pár szóban bemutatni.

A tradícionális megközelítés

Ebben az esetben a projekt jól definiált, lineárisan egymást követő fázisokból áll. A megrendelés és a feladat meghatározása az elején történik meg és nehézkes közben változtatni. Nagyon alapos, részletes tervezést igényel. Előnye a nagyon részletes dokumentáció, a könnyen nyomon követhető folyamatok és a világos felelősségi határok. Hátránya pedig, hogy egyrészt nehéz tesztelni, mert az teljesen csak a végén lehetséges, másrészt, ha változik a megrendelő által kívánt elvárás, a projekt nem rugalmas.

RUP módszer

A fent említett bizonytalanságok miatt került a RUP kifejlesztésre. Ez a módszertan az IBM leányvállalatának, a Rational Software Corporation-nak a terméke. Ennek a módszertannak a lényege, hogy kezdetben egy alaprendszer terveit teszi le, majd a jóváhagyás után rendszeres, inkrementális fejlesztési eljárással szállítja a különböző verziókat. Így lépésenként, a megrendelő folyamatos visszajelzései mellett folyhat a fejlesztési munka.

Programkiértékelés és felülvizsgálati technika (PERT)

Legtöbbször ezzel a módszerrel dolgozunk, hiszen ezzel a legelőször az Egyesült Államok haditengerészetének kifejlesztett módszerrel könnyen kezelhetünk komplex projekteket. A fókusz itt a feladatokon van, azok idején és a feladatok kapcsolatán. A klasszikus PERT módszerben a határidőkre három, egy pesszimista, egy normál és egy optimista becslést is adunk és ennek az átlagolásával számolunk.

Kritikus-lánc modell (CCPM)

Ebben a megközelítésben a fókusz az erőforrásokon van. Multiprojekt környezetben lehet hatásos, ahol simítással (leveling) lehet az erőforrásokat a különböző projektek között allokálni. Ez nagyfokú rugalmasságot is megkövetel, hiszen egy-egy erőforrás több részmunkán is dolgozhat egymás után.

Agilis projektvezetés

Ez a módszertan igen fiatal, szoftverfejlesztésekre találták ki és valóban igen agilis. A hangsúly itt az iteráción, nyitottságon, együttműködésen van a projekt teljes életszakaszában. A megrendelőt egy dedikált személy képviseli a fejlesztések során, ahol gyors, rövid fejlesztési szakaszokban adják át a terméket, folyamatos kiértékelések és újítások mellett. A lényeg, hogy a lehető legkisebb, önmagában működő funkciókra bontsák a teljes projektet. Azaz, a terjedelem menet közben pontosodik és alakul ki. A dokumentálás helyett a hangsúly a személyes kommunikáción van.

Az agilis projektvezetési megközelítések családjában tartozik az extrém projektvezetési módszertan is.

Mint ebből a rövid kis bemutatóból is láthattuk a projektvezetés mára önálló menedzsment tudományággá nőtte ki magát. Nincsenek egyedül üdvözítő utak, minden helyzetben más és más lehet a legjobb megközelítés, bátran lehet elegyíteni több módszertan elemeit is.

Agilis munkamódszer

NE ELKEZDJÜK,
                        FEJEZZÜK BE!

                                                                                                            # agile