Nagy Zsolt

Projektmenedzsment jegyzet

Nyugat-magyarországi Egyetem Közgazdaságtudományi Kar

Sopron, 2008.

2

TARTALOMJEGYZÉK

1. MI A PROJEKT? ......................................................................................................3

2. A PROJEKTMENEDZSMENT ELEMEI ÉS JELLEMZ İI ÁLTALÁBAN .....9

2.1. A PROJEKTEK SZEREPLİI.......................................................................................9 2.2. A PROJEKT-ÉLETCIKLUS MODELL........................................................................10

3. MEGVALÓSÍTHATÓSÁG....................................................................................14

3.1. MEGVALÓSÍTHATÓSÁGI TANULMÁNY .................................................................14 3.2. MŐSZAKI MEGVALÓSÍTHATÓSÁG........................................................................14 3.3. PÉNZÜGYI MEGVALÓSÍTHATÓSÁG.......................................................................15

4. A PROJEKT SZERKEZETE.................................................................................17

4.1. FELADATOK ALÁBONTÁSI RENDSZERE................................................................18 4.2. A FELADATOK KIVITELEZİINEK MEGHATÁROZÁSA.............................................19

4.2.1. Kommunikációs terv készítése....................................................................20 4.3. A PROJEKT HÁLÓTERVÉNEK KIDOLGOZÁSA.........................................................20

4.3.1. CPM – tevékenységélő háló .......................................................................21 4.3.2. MPM – tevékenység csomópontú háló.......................................................26

4.4. A PROJEKT IDİTERVE..........................................................................................30 4.5. ERİFORRÁS-TERVEZÉS.......................................................................................31 4.6. A PROJEKT KÖLTSÉGEINEK A FELMÉRÉSE............................................................33 4.7. KOCKÁZAT..........................................................................................................34

4.7.1. Kockázati tényezık felismerése és elemzése ..............................................35 4.7.2. A kockázati tényezık kezelése ....................................................................36

4.8. A PROJEKTINDÍTÓ DOKUMENTÁCIÓ.....................................................................38

5. A PROJEKT KIVITELEZÉSE..............................................................................39

5.1. A PROJEKTTEAM MEGBESZÉLÉSE A KIVITELEZÉS SORÁN.....................................39 5.2. VÁLTOZTATÁSOK A PROJEKTEN..........................................................................42 5.3. PROJEKTKONTROLLING.......................................................................................43

6. A PROJEKT ÁTADÁSA ÉS ÉRTÉKELÉSE.......................................................46

6.1. A PROJEKT ÁTADÁSA..........................................................................................46 6.2. A PROJEKT ÉRTÉKELÉSE......................................................................................47

7. PROJEKTMENEDZSMENT ÉS SZERVEZETI STRUKTÚRA ......... .............50

7.1. PROJEKTMEGVALÓSÍTÁS LINEÁRIS-FUNKCIONÁLIS STRUKTÚRÁBAN ..................50 7.2. PROJEKTMEGVALÓSÍTÁS MÁTRIX STRUKTÚRÁBAN.............................................51 7.3. PROJEKTMEGVALÓSÍTÁS PROJEKTKÖZPONTÚ STRUKTÚRÁBAN...........................52

8. ÁTTEKINTÉS..........................................................................................................54

9. PROJEKTMENEDZSMENT MÓDSZERTAN ...................................................56

9.1. PRINCE2 ...........................................................................................................56 9.2. PMBOK .............................................................................................................58 9.3. PROJEKT CIKLUS MENEDZSMENT (PCM).............................................................60

9.3.1. Logikai keretmátrix (Logical Framework Approach – logframe) .............65

IRODALOMJEGYZÉK..................................................................................................72

3

1. MI A PROJEKT?

A projektek lényege mindig valamilyen elınyös változtatás megvalósítása, ezért

az élet minden területén találkozunk velük. Amikor meghatározott cél érdekében véghez-

viendı tevékenységsorozat megtervezésérıl van szó, akkor már projektrıl beszélünk.

Projekt a vállalatok különleges, egyszeri céljaik elérése érdekében végzett tevékenységso-

rozata, de az Európai Unió támogatási alapjainak forrásaira benyújtott pályázatok is pro-

jekteken alapulnak. Elıször a projekt ötlete születik meg, amelyhez meg kell keresni azt a

pályázati formát, amelytıl támogatásra számíthat a tervezett tevékenység.

Mindenütt célszerő felkészíteni a szervezetet projektek kezelésére, ugyanis a gaz-

dasági-üzleti környezet gyors változása miatt manapság aligha lehet olyan céget találni,

ahol ne lennének projektek, vagyis ne kellene pl. egy új érdekeltségi vagy informatikai

rendszert bevezetni.

Rendkívül szerteágazóak és változóak lehetnek a projektek, egy pár munkatárs

néhány napos vagy hetes erıfeszítésétıl kezdve tucatnyi vagy több száz ember éveken

keresztül történı foglalkoztatásáig. A több milliárdos költségvetéső projekt végrehajtása

az alapelvek szempontjából semmiben sem különbözik egy mindössze kéthetes projekttıl.

Ezeknek az alapelveknek, módszereknek a tárgyalására vállalkozik ez a jegyzet.

Mi a projekt?

4

A projekt fogalmát a vállalatok, vállalkozások világára koncentrálva három kü-

lönbözı úton szeretnénk megközelíteni.

1. A vállalat menedzsmentje projekteken keresztül valósítja meg a stratégiát. A

stratégia három fı kérdés köré épül fel:

Hol tartunk most?

Helyzetelemzés, pozíció-

analízis

belsı adottságok:

erısségek, gyengeségek

külsı környezeti tényezık:

lehetıségek, veszélyek

Hova akarunk eljutni?

Célmeghatározás

érdekcsoportok elvárásai

küldetés és jövıkép

célok

Hogyan?

Stratégiai akciók és prog-

ramok megfogalmazása

A stratégiai gondolkodásnak egy adott jelenlegi állapotból egy kitőzött célállapot-

ba való eljutás áll a középpontjában, a stratégia a két pont között „légvonalban” gondol-

kodik. A stratégia megfogalmazása után a konkrétabb szint a projektek szintje, a projek-

tek jelentik a két pont közötti konkrét utat, amit a valóságban be kell, hogy járjon a válla-

lat. Egy-egy projekt a két szélsı pont közötti, konkrét kezdı-, és végponttal kitőzött sza-

kaszt jelent. Például az adott vállalat megfogalmazta a versenyképességének növelésére

irányuló stratégiát, a kivitelezésen dolgozva épp egy új szolgáltatás bevezetésére irányuló

projektet valósít meg.

5

Végrehajtás Ellenırzés Tervezés

Standard feladatok

Testre szabott, nem standard

feladat

Feladatmegoldás projektek keretében

Mőködés (feladatmegoldás) a meglév ı vállalati rendszer

keretében

Vállalti mőködés: hagyományos vállalati rendszer vagy projekt keretében

Tevékenységek

2. Amikor vállalat vezetése végiggondolja a tipikus vállalati tevékenységeket, két

csoportot tud elkülöníteni:

• rutinszerően ismétlıdı, a meglévı rendszer keretében megoldandó felada-

tok, amire folyamatokat fog definiálni, a standard kiváló minıségő folya-

mat-végrehajtásra minıségirányítási rendszert mőködtet, ilyen például ti-

pikusan a tömeggyártás,

• egyedi célok megvalósítására irányuló, nagykockázatú, változó összetételő

csoportok (teamek) együttmőködésén alapuló feladatmegoldás, amire pro-

jekteket fog felállítani, ilyen például a terméktervezés.

6

A két fajta tipikus tevékenységcsoport közötti alapvetı különbséget a menedzs-

mentnek fel kell ismernie, testre szabott, nem standard feladatok megvalósítására projek-

tet kell életre hívni.

Rutinszerően ismétlıdı Projekt

Feladat jól ismert szokatlan

Munkatársak kinevezett, ismert változó, ideiglenes

Feladatkörök kialakult minták bizonytalan, változó

Szervezeti kultúra szerep vagy hatalom feladat

Munkakapcsolat bejáratott együttmőködés eldöntendı

Hatáskörök egyértelmő, pozíció szerint nem mindig egyértelmő

Koordináció hierarchikus hálózat (mátrix)

Információforrás kialakult, rutin új, bizonytalan

Tanulás, változás kívánatos létfontosságú

Mozgatórugó a rendszer által fenntartott a rendszert veszélyezteti

Idıtávlat hosszú távú körülhatárolt, véges

3. A projektmenedzsment alapvetı funkciói közé tartozik a projekt által érintett

funkcionális szakterületek tevékenységeinek integrálása. Ha ugyanis a projektet valami-

lyen funkcionális szakterülethez rendelnénk, természetesen az ı szempontjai lennének

dominánsak, nyilvánvalóan a többi szakterület rovására. Papp Ottó (2002) szemléletes

példát mutat be arról, hogy mihez vezetne az, ha egy termékfejlesztési feladatot sorra a

K+F, a minıségbiztosítás, a marketing, a gyártás kapna meg egyedül. Milyen lenne az így

kifejlesztett termék, ami a K+F, a minıségbiztosítás, a marketing, a gyártás szakembere

számára a legjobb megoldás.

A projektteam egy olyan csoport, ahova minden szakterület küld egy-egy képvise-

lıjét, így a feladatmegoldás során mindenki a saját szakmai érdekviszonyait képviseli.

Ebbıl következik, hogy a projekt konfliktussal jár, a projektmenedzser feladatai között

fontos szerepet játszik a konfliktuskezelés, amíg a konfliktusban álló érték-, és érdekvi-

szonyok között a lehetı legjobb – nyilvánvalóan kompromisszumos – megoldást megta-

lálják.

7

A fenti meggondolások után álljon itt három projekt definíció:

„Projekt minden olyan tevékenység, amely egy szervezet számára olyan egyszeri

és komplex feladatot jelent, amelynek teljesítési idıtartama (kezdés és befejezés), vala-

mint teljesítésének költségei (erıforrások) meghatározottak, és egy definiált cél (ered-

mény) elérésére irányul”. (Görög Mihály, 2001)

A projekt

• konkrét célok és eredmények érdekében,

• adott idı-, költség-, és erıforrás-korlátok között,

• meghatározott minıségi és teljesítménykövetelmények mellett,

• lehetıleg minimális „vagyonelem” (ill. erıforrás) felhasználásával,

• elfogadható kockázati szint mellett, és

• valamilyen egyértelmően definiált „termék” (létesítmény, szolgáltatás)

létrehozására irányuló tevékenység (ill. egymással összefüggı tevékenységsor).

(Papp Ottó, 2002)

A projekt emberek és más erıforrások ideiglenes együttese, amelyeket azért győj-

töttek egybe, hogy meghatározott célt érjenek el, rendszerint kötött költségvetéssel és

rögzített idıtartammal. A projektek általában olyan termékekkel vagy folyamatokkal kap-

csolatos tevékenységek, amelyek elsı ízben valósítanak meg, ill. meglévı folyamatok

átalakítására irányulnak (Robert J Graham, 1985)

8

Az idı, a költség és a minıség három olyan tényezı, amely minden projektben

megtalálható, amellett, hogy fontossági sorrendjük esetenként változik. Sok esetben az

idı a legfontosabb tényezı, nincs lehetıség a tervezett befejezési, átadási idıpont eltolá-

sára, ilyen ok lehet a médiaszereplés vagy általunk nem befolyásolható külsı körülmény,

pl. kiállítás, vásár megnyitója. A mérnöki vagy orvosi projektek esetében általában a tö-

kéletes minıség a legfontosabb, még akkor is, ha ezzel meghosszabbodik a kivitelezési

idı, és megnınek a költségek. Ha a megrendelıvel már megállapodtunk a díjazásról, ak-

kor a költségek a kulcsfontosságúak, az adott költségvetés keretein belül kell maradnunk.

Mire van szükség ahhoz, hogy egy projekt sikeres legyen? A projektet határidıre, a költ-

ségvetésen belül, kiváló minıségben kell befejeznünk. Összegezve azt mondhatjuk, hogy

mindhárom szempontot ellenırzésünk alatt kell tartanunk, a bővös háromszögön belül

kell maradnunk, hogy a projektünk sikeres legyen.

„Aki tornyot akar építeni, nem ül-e le elıbb, hogy kiszámítsa a költségeket, vajon

futja-e pénzébıl, hogy fel is építse? Nehogy azután, hogy az alapokat lerakta, de

befejezni nem tudta, mindenki, aki csaj látja, kicsúfolja.” (Lukács 14, 28-29)

Idı Költség

Az idı/költség/minıség háromszöge

Minıség

9

2. A PROJEKTMENEDZSMENT ELEMEI ÉS JELLEMZ İI ÁLTALÁBAN

Az elızı fejezetben megfogalmazottak szerint a továbbiakban is a vállalkozásokra

koncentrálunk, a projektmenedzsment eszközeit a vállalati projektek esetére értelmezzük,

de ezek természetesen kiterjeszthetıek a nonprofit vagy az intézményi körre is.

2.1. A projektek szereplıi

A szereplıket a projekttel kapcsolatos szerepük különbözteti meg. A következı

ábra egy leegyszerősített modellt mutat be, a további tárgyaláshoz feltétlenül szükséges

szereplıkre korlátozódik.

A projekttel kapcsolatban a vállalatvezetı általában nem tartja magánál a felelıs-

séget, hanem vezetıtársai közül megnevez egy Projektszponzor-t, aki a projekt tervezési

és megvalósítási szakaszában a projektmenedzser partnere lesz, meghozza a projektet

érintı döntéseket, rendelkezik a szükséges erıforrások felett.

A projektszponzor feladatai:

• segít a projekt érdekeit érvényesíteni a vállalaton belül

• döntést hoz arról, hogy a projekt egyik életciklus-fázisából a következıbe

léphessen

• döntés a megvalósításról

• sikeresnek vagy sikertelennek nyilvánítja a projektet

Projektmenedzser

A projekten dolgozó csoport (team)

(projektkoordinátor)

Vállalatvezetı

Projektszponzor Megrendelı

10

• a megvalósítás során a változtatások engedélyezése

• a megvalósítás során rendszeres ellenırzés

• a minıségi ellenırzés irányítása

• értékeli a projektet.

A Projektmenedzser felel a projekt hatékony mőködéséért. A fenti kommunikációs

ábra középpontjában helyezkedik el. A projekt sikere legfıképpen az ı szakmai hozzáér-

tésétıl és eredményes munkájától függ.

A projektmenedzser feladatai:

• a projekt tervének elkészítése

• csapatépítés, a csapaton belüli kompetenciák és felelısségek meghatározá-

sa

• a csapattagok motiválása

• az ellenırzési pontok, mérföldkövek megállapítása

• kommunikáció a projektcsoporton belül és a többi érintettel

• a tervezetthez képesti változtatások dokumentálása

• jelentések készítése (projektindító dokumentáció, a projekt zárójelentése)

• a tervezett és a ténylegesen megvalósított munka összehasonlítása.

A projekt eredményét a Megrendelı fogja majd hasznosítani a projekt befejezése

után. Vegyünk például egy olyan projektet, ami egy ISO szabvány szerinti minıségirányí-

tási rendszer kiépítésére irányul. A végfelhasználók ebben az esetben azok a munkatár-

sak, akik munkájuk során alkalmazni a fogják a minıségirányítási rendszer elıírásait. A

projekt sikere szempontjából kulcsfontosságú, hogy a rendszerrel kapcsolatos elvárásaik

kiderüljenek, a rendszerépítés során bevonják ıket, és folyamatos egyeztetés legyen kö-

zöttük és a projektcsoport között.

A projekten dolgozó csoport felállításáról a fentiekben már kiderült, hogy a válla-

lat különbözı funkcionális szakterületei delegálnak oda munkatársakat, de ha ez indokolt,

külsı szakértıkkel is kiegészülhet. Nagyobb projekteknél szükség lehet egy Projektkoor-

dinátorra, aki a projektmenedzser munkáját segíti, természetesen kisebb projekteknél a

költségvetés ezt nem teszi lehetıvé.

2.2. A projekt-életciklus modell

11

Fenti projektdefiníciókból következik a projektek az élılényekhez – melyek meg-

születnek, kiteljesednek, majd elhalnak – hasonló tárgyalása, ebbıl az analógiából szár-

maztatható a projekt életciklusa. Valamennyi projektre egyetemlegesen érvényes életcik-

lus-modell nem létezik, Weiss és Wysocki (1994) ír le egy ötfázisú modellt:

A fı szakaszok közötti átfedı területek azt érzékeltetik, hogy az egyik szakaszból

a másikba történı átmenet nem éles.

A projekt kialakítási szakasza egy definiálási fázis. Akkor kezdıdik, amikor a pro-

jektalapító okiratban megnevezik a projektet, a projekt célját, hatókörét és a projektme-

nedzsert. A projektalapító okirat a jogkörök hivatalos elismerése. A projekt kialakítási

szakaszban javaslatok kerülnek kialakításra, a megvalósíthatóságuk kerül értékelésre. A

projektjavaslat indítja el a projektet. A projektjavaslat összefoglalja a szükséges informá-

ciókat a projektszponzor számára. Egy „menjen/ne menjen” döntés zárja le ezt a szakaszt.

A definiálási szakasz lezárásaként a projektmenedzser az elvárások összehangolása és az

egyetértés elérése érdekében elkészíti a munkakimutatást. A munkakimutatás minimális

tartalma:

• célmeghatározás,

• a projekt hatókörének meghatározás,

• elérendı eredmények,

• költség-, és ütemtervbecslés,

• célokat mérı eredmény (mutatató, indikátor),

• stakeholderek,

12

• szolgálati út.

A munkakimutatás hivatalos egyetértést jelent a projekt stakeholderei között a

projekt céljaiban és feltételeiben.

Egy pozitív „menjen” döntés után a projekt a tervezési szakaszba lép.

A tervezési szakaszban elvégzendı feladatok:

• A feladatok alábontási rendszere (WBS - Work Breakdown Structure)

(MIT?)

• A feladatok kivitelezıinek meghatározása (Kompetenciák és felelısségek

mátrixa - KFM) (KI?)

• A feladatok közötti logikai kapcsolat alapján a kivitelezés technológiája –

A projekt hálóterve (HOGYAN?)

• A feladatok végrehajtásának idıbeli tervezése – Gantt-diagram (MIKOR?)

• A kivitelezéshez szükséges erıforrások megtervezése – Erıforrás-tervezés

(MIVEL?)

• A projekt költségeinek a felmérése (MENNYIBİL?)

A tervezési szakasz végére elkezdıdhetnek a szervezési szakasz munkái. A szer-

vezési szakasz alatt az a cél, hogy a projekt és a szervezet kapcsolata, a projektteam, az

ellenırzés, a módszerek, a következı szakaszban igényelt kommunikáció kialakításra

kerüljenek.

A következı szakasz a végrehajtás/megvalósítás szakasza. Ebben a szakaszban

fontos tevékenységek:

• kommunikáció a vezetıkkel, megrendelıvel, kivitelezıkkel, megrendelık-

kel

• változtatások a projekten

• a projekt ellenırzése, nyomon követése a kivitelezés során

• a költségek figyelemmel kísérése

• minıségellenırzés

A projektciklus végsı szakasza a projektzárás. A projektcsapat átadja a projekt

eredményének a megrendelınek. Az értékelés az átadás után következı, tehát záró fel-

adat.

Átadási teendık:

• bevonás,

• egyeztetés,

13

• elvárások tisztázása.

A Görög Mihály által leírt modellben a projekt „élete” körfolyamatként van szem-

léltetve. A többi elmélettel ellentétben ez a forma a tevékenységfolyamat bemutatása mel-

lett alkalmas arra is, hogy a stratégiai meghatározottságot, valamint a megvalósítási fo-

lyamat egészének és a stratégiai célok teljesülésének kölcsönös összefüggéseit is kiemelje.

Fontos elem a modellben a döntési pontok megjelenése. Ezeknek, az adott fázist határoló,

lezáró feladatuk mellett elıre mutató az a szerepük, hogy rögzítik a projekt céljait, illetve

teljesítésük az eredmény elfogadását is. A modell fent felsorolt elemei már szinte sugall-

ják azt a szemléletet, amely a ciklus során elıtérbe helyezi a folyamatos monitoring és a

visszacsatolás szerepét

Forrás: Görög Mihály (2001)

14

3. MEGVALÓSÍTHATÓSÁG

A 2.2. fejezetben a projekt életciklusának bemutatásakor röviden foglalkoztunk a

projekt kialakítás szakaszával. Feltételezzük, hogy rendelkezésre áll egy vagy több javas-

lat. El kell dönteni, hogy közülük bármelyiket is érdemes-e továbbgondolni. Tehát szük-

séges a megvalósíthatóságukat értékelni.

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

A projekten dolgozó csoport (a projektmenedzser vezetésével) feladatot kap min-

den érdemesnek tőnı javaslat megvalósíthatósági tanulmányának elkészítésére. A tanul-

mánynak meg kell kísérelnie olyan szcenáriók (forgatókönyvek) kidolgozását, amelyek

elfogadásra szóba jöhetı megoldások. A különbözı változatok olyan funkcionális specifi-

kációkat tartalmaznak, amelyek világosan leírják egy javaslat terjedelmét, célkitőzéseit,

pénzügyi és idıbeli korlátait, választ adnak a mőszaki és gazdasági megvalósíthatóság

kérdéseire. Egy specifikáció megmondja, hogy mit kell tenni, és mindezt milyen korlátok

között. Biztosítja, hogy legalább egy megfelelı módja legyen a megvalósításnak, de nem

adja meg, hogy a célkitőzést milyen módon kell elérni. Erre a lépésre majd a projektter-

vezés szakaszában kerül sor.

A szcenárió egy, a megfogalmazott célkitőzések eléréséhez szükséges rendszer-

nek, folyamatnak vagy eljárásmódok összességének tömör leírása. Minden célkitőzéshez

számos lehetséges stratégia adódhat. A főnyírás célkitőzése kielégíthetı többféle módon

is: végezhetjük magunk, beszerezhetünk elektromos vagy benzinmotoros főnyírót, de

kölcsön is kérhetjük az eszközt barátainktól, tarthatunk kecskét, ami lelegeli a füvet, vagy

a szolgáltatást megvásárolhatjuk egy erre vállalkozó kertésztıl. A felszínre kerülı elgon-

dolásokat alaposan meg kell vizsgálni, módosítani, válogatni, vagy elutasítani.

3.2. Mőszaki megvalósíthatóság

A kockázat minimalizálásának szemszögébıl meg kell vizsgálnunk, hogy a vá-

lasztott technológia életképes-e.

A sajátosságok elemzése a különbözı, de azonos célt szolgáló és összehasonlítha-

tó termékekrıl származó információk győjtésére és rendszerezésére szolgáló módszer. A

sajátosságok elemzésének problémái többnyire nyilvánvalóak:

15

• minden sajátossághoz nagyszámú alkotóelem tartozhat,

• a sajátosságokat azok viszonylagos fontossága szerint kell súlyozni,

• a csupán kvalitatív módon rangsoroló rendszereket nehéz elemezni,

• ritkán létezik teljes körő rendszer a sajátosságok súlyozásánál és rangsoro-

lásánál.

A sajátosságok elemzése nagyon hasznos lehet, mert segíti a teamet abban, hogy

egy rendszer fontosnak tartott sajátosságairól objektív meghatározást, értékelést, rangso-

rolást alakítson ki.

A mőszaki tényezıkön túl egyre nagyobb mértékben mérlegelik az ökológiai té-

nyezıket minden terv megvalósíthatóságának értékelésénél. Az ökológiai megfontoláso-

kat az a logika hozza felszínre, hogy a potenciális vevık olyan termékek vásárlását része-

sítik elınyben, melyek a versenytárs termékeknél kevésbé ártalmasak a környezetre. Öko-

lógiai szempontból nemcsak magának a terméknek és a gyártásnál képzıdı szennyezı

anyagoknak a vizsgálata fontos, hanem a gyártáshoz felhasznált nyersanyagoknak és a

keletkezı hulladékoknak az áttekintése is.

A megvalósíthatóság értékelésekor egyre inkább elıtérbe kerül a szociális ténye-

zık értékelése is. A szociális tényezık jelentik a projekttel kapcsolatban a csoporton vagy

irodán belüli kapcsolatrendszert, a munkaerı foglalkoztatását, a munkatársak egészségét

vagy akár a társadalmi megítélést befolyásoló tényezıket.

3.3. Pénzügyi megvalósíthatóság

Mielıtt egy lehetséges projekt kiválasztása és megvalósíthatósága tekintetében

elırelépés történne a befektetést illetıen, két kérdéscsoport megvizsgálására van szükség:

• Érdemes-e a forrásokat egy adott projektbe befektetni? Mennyire éri meg a

befektetés?

• Ahol a források befektetésére több lehetıség áll fenn, melyik változat biz-

tosítja a legmagasabb hozamot?

A költség-haszon elemzés olyan módszer, amelyik magában foglalja:

• a költségek azonosítását, mértékük megállapítását, és értékelését a teljes

elıirányzott élettartamra,

• a javaslat hasznának azonosítását, mértékének megállapítását, és értékelé-

sét a teljes elıirányzott élettartamra.

16

Meg kell érteni a befektetés és a bevétel közötti különbséget, azt, hogy mik a

pénzügyi mőveletek költségei, az általános költségek, értékcsökkenés és infláció.

Értékelési módszerek:

• megtérülési idı (payback period method)

• nettó jelenérték (NPV)

• belsı megtérülési kamatláb (IRR)

17

4. A PROJEKT SZERKEZETE

Feladatok definiálása

Mit?

Üzleti célok Megbízó céljai

Projektcélok Projektjavaslat

Projekt meghatározás

WBS

Ki?

Hálóterv

Gantt-diagram F1

F2

F3

F4

Feladatok

Hogyan?

Mikor?

Kompetenciák és felelısségek mátrixa munkatrs1 munkatrs2 munkatrs3 ……

F1 F2 F3 F4 …

Mivel? Erıforrás-tervezés Az erıforrás igények ütemezése

Szervezet

Költség-kalkuláció cash flow-számítások

Mennyibıl?

18

4.1. Feladatok alábontási rendszere

A feladatok alábontási rendszere (Work Breakdown Structure WBS) az az eszköz,

aminek segítségével eljutunk a projekt céljának megfogalmazásától a konkrét feladatok

definiálásáig. A WBS egy olyan fastruktúra, amelyben az elvégzendı munka elıször

munkacsoportokra van bontva, majd ezek kisebb egységekre, és így tovább olyan mély-

ségig, ahogy ezt a projekt megkívánja, illetve az adott fázisban elıre látható. A legalsó

szinten jelennek meg a feladatok, amit egy adott szakembernek kell végrehajtania.

A feladatok pontosan meghatározott eredménnyel rendelkeznek, elvégzésükért

egy személy felelıs. A kivitelezıt hivatalosan, és nem hivatalosan is meghatározhatjuk, a

kivitelezés költségeit egyszerően meg lehet határozni, a kivitelezés minısége könnyen

A projekt célja

3. 4. 2. 1.

1.2. 1.1.

1.1.2. 1.1.1.

19

értékelhetı. A feladatok alábontásban megjelenı logikát jelöléstechnikailag kódszámok-

kal tudjuk megmutatni.

A feladatok alábontási rendszere nem foglal állást a feladatok sorrendjét, kivitele-

zésük módját, idıtartamát, és a végrehajtáshoz szükséges személyek számát illetıen. A

kapott feladatok jelentik az alapját, a kiindulópontját a projekt szerkezete ábrán található

többi eszköznek.

4.2. A feladatok kivitelezıinek meghatározása

Az egyes személyek különbözı típusú részvételét a feladatokban a kompetenciák

és felelısségek mátrixa segítségével lehet ábrázolni:

Új iroda létesítése

2. Az iroda bebútoro-zása

3. Irodatechnika tele-pítése

1. A helyiségek átala-kítása

1.1 helyszíni felmérés 1.2 változtatások tervei

2.1 bútorok megrendelése 2.2 bútorok elhelyezése

3.1 irodatechnika megtervezése 3.2 irodatechnika elhelyezése 3.3 irodatechnika ellenırzése

20

A PROJEKT KIVITELEZÉSÉBEN RÉSZT -

VEVİ MUNKATÁRSAK A PROJEKT FELADATAI

1. 2. 3. 4. 5. 6.

A mátrix minden sora egy-egy feladatot jelent, az oszlopok a feladatok teljesítésé-

ben résztvevı személyeket. Az adott sor és oszlop metszéspontjában lévı cellába olyan,

az adott vállalatra egyezményes betőt írunk, ami megmutatja, hogy az adott személy az

adott feladat teljesítésében milyen feladattal, felelısséggel van felruházva. (pl. D – dönt a

végrehajtásról, V – végrehajt, É – értesítést kap a végrehajtásról, T – támogat)

4.2.1. Kommunikációs terv készítése

A projekt megvalósítása során emberek döntéseket hoznak, tevékenységeket haj-

tanak végre. A projektmenedzser koordinálja, és befolyásolja a projekt érintettjeit. Végze-

tes hiba lehet hagyni, hogy a kommunikáció magától létrejöjjön. A kommunikációs terv a

kommunikációs stratégia írott változata, arra a célra, hogy a megfelelı emberek a megfe-

lelı információt a megfelelı idıben kapják meg. A kommunikációs terv kulcskérdései:

• Kinek van szüksége információra? – projektszponzor – funkcionális me-

nedzsment - megrendelı – projektcsoport – projektmenedzser

• Milyen információkra van szüksége? – jóváhagyások – változások - koor-

dináció

4.3. A projekt hálótervének kidolgozása

A hálós tervezési rendszerek fejlıdése az 50-es évek végén indult meg. Ezen idı-

szak eredménye a CPM, az MPM és a PERT technikák kifejlesztése.

21

A CPM (Critical Path Method) a DuPont Corporation és a Remington Rand nevé-

hez főzıdik. A CPM háló két alapeleme a tevékenység és az esemény. A CPM egy

tevékenységélő háló, egy olyan gráf, aminek a csúcspontjai az események, élei a tevé-

kenységek.

Az MPM (Metra Potencial Method) kifejlıdése 1958-ban kezdıdött Franciaor-

szágban. Az MPM háló abban különbözik a CPM-tıl, hogy a gráf csomópontjaiban ábrá-

zoljuk a tevékenységeket, és a gráf élei a tevékenységek közötti kapcsolatot jelentik. Az

MPM tehát egy tevékenység-csomópontú háló.

A PERT (Program Evaulation and Review Technique) technikát az amerikai hadi-

tengerészet számára fejlesztették ki. Olyan hálótechnikára volt szükség, ami képes kezelni

a nagy kockázattal rendelkezı projekteket. A PERT technika véletlentıl függı, sztochasz-

tikus tevékenységidıkkel (olyan tevékenységidıkkel, aminek ismerjük a valószínőségi

eloszlását) dolgozik.

Ebben a fejezetben a CPM és az MPM eljárást tárgyaljuk, a PERT technikával

ezek között a keretek között nem foglalkozunk.

4.3.1. CPM – tevékenységélő háló

A CPM háló szerkesztésénél az alábbi szabályokat kell betartani:

A háló két alapeleme a tevékenység és az esemény, a gráf élei a tevékenységek, a

csomópontok az események. A tevékenységet nyíllal ábrázoljuk, mert egy kezdıponttól

egy befejezési pont felé irányul. Egy eseménybe tevékenységek futnak be. Az adott ese-

mény akkor következik be, ha a befutó tevékenységek mindegyike befejezıdött, és ezután

kezdıdhetnek el az eseménybıl kiinduló tevékenységek is.

A hálónak csak egy kezdı-, és egy végpontja lehet.

A háló nem tartalmazhat kettıs, ill. többszörös tevékenységeket. Ezt a szabályt az

indokolja, hogy i eseménybıl induló és j eseménybe érkezı tevékenységet az i,j

számpárral azonosítjuk, ha megengednénk a kettıs tevékenységet, akkor a tevékenységje-

lölés nem lenne egyértelmő.

22

A háló hurkot nem tartalmazhat, hiszen ez azt jelentené, hogy egy tevékenység

csak akkor kezdıdhet el, amikor a logikailag ıt követı tevékenység már befejezıdött.

Bevezetjük a látszattevékenység fogalmát. A látszattevékenység olyan tevékeny-

ség, ami nem része a projektnek, nem valós tevékenység, használatát ábrázolástechnikai

szempontok indokolják. Látszattevékenység segítségével mutatjuk meg, hogy egy adott

tevékenység elkezdése összefügg az ıt megelızı tevékenység befejezıdésével. A látszat-

tevékenységeket szaggatott vonallal jelöljük.

A háló felrajzolásának kiinduló pontja az ún. megelızési lista, az a táblázat, ami

tartalmazza, hogy a WBS eredményeként megszületett tevékenységek között milyen meg-

elızési, követési logikai kapcsolat tárható fel.

Példánkban az átláthatóság miatt a tevékenységeket betőkkel, az eseményeket

számokkal jelöljük. Példaprojektünk egy minden lakott településtıl távoli tanya vízellá-

tására szolgáló kút telepítésérıl szól. Ha a fentiekre példát keresünk a táblázatunkban, F

tevékenység csak akkor kezdhetı el, ha C és E tevékenység befejezıdött.

Kód Tevékenység Közvetl. megelızı Idıtart. [nap] Személyz. [fı] A Terület elıkészítése 1 2 B Anyagok beszerzése 2 1 C Szivattyú beszerzése 4 1 D Kútköpeny elıkészítése A, B 2 1 E Kút ásása D 5 2 F Szivattyú beszerelése C, E 1 1 G Személyzet kiképzése C 2 1 H Próbaüzem F, G 2 1

A CPM háló létrehozásának lépései:

1. a háló felrajzolása

i j

23

A megelızési lista információinak a felhasználásával, a fenti hálórajzolási szabá-

lyok betartásával felrajzoljuk a hálót. A tevékenységek végrehajtásához szükséges idıtar-

tamot zárójelek között szerepeltessük a tevékenység azonosítója mögött. Példánkban lát-

szattevékenységgel mutatjuk meg a D ill. F tevékenységek megelızı, követı logikai kap-

csolatait.

2. Az események bekövetkezésének legkorábbi idıpontját határozzuk meg a háló-

ban – idıtervezés elıre haladva.

A kezdı esemény bekövetkezésének legkorábbi idıpontja definíciószerően 0. A

kezdı eseménybıl kiindulva hozzáadjuk a megelızı esemény bekövetkezésének legko-

rábbi idıpontjához a tevékenységek végrehajtásához szükséges idıtartamot. Definíciósze-

rően a látszattevékenység végrehajtási idıtartama 0. Ha több tevékenység fut be egy adott

eseménybe, akkor a különbözı utakon (a különbözı tevékenységeken keresztül) kapott

összegek közül a legnagyobbat vesszük figyelembe. Elıre felé haladva a hálóban tehát

összeadunk. Az adott esemény bekövetkezésének legkorábbi idıpontját az esemény jobb

felsı sarkába írjuk. A záróesemény bekövetkezésének legkorábbi idıpontja megadja az

egész projekt végsı határidejét. Ez esetünkben 12 nap.

0 2

1 4

3

5

6 7

A (1) D (2) E (5) F (1)

H (2) B (2)

C (4) G (2)

0 2

1 4

3

5

6 7

A (1) D (2) E (5) F (1)

H (2) B (2)

C (4) G (2)

0

4

10

9 4 2

2 12

24

3. Az események bekövetkezésének legkésıbbi idıpontját határozzuk meg a háló-

ban – idıtervezés visszafelé haladva.

Definíciószerően a záróesemény bekövetkezésének legkésıbbi idıpontja egyenlı

a bekövetkezésének legkorábbi idıpontjával. Ebben a lépésben a záróeseménytıl kiindul-

va, visszafelé haladunk a hálóban. A vizsgált esemény bekövetkezésének legkésıbbi idı-

pontját úgy kapjuk, hogy az ıt közvetlenül követı esemény bekövetkezésének legkésıbbi

idıpontjából levonjuk a két esemény között ábrázolt tevékenység idıtartamát. Ha a vizs-

gált eseménybıl több tevékenység indul, akkor a különbözı utakon kapott különbségek

közül a legkisebbet vesszük figyelembe. Visszafelé haladva a hálóban tehát kivonunk. Az

adott esemény bekövetkezésének legkésıbbi idıpontját az esemény jobb alsó sarkába

írjuk. Ha már a projekt végrehajtási szakaszában a megvalósítást figyeljük, ha egy ese-

mény a tervezett legkésıbbi idıpontig nem következik be, ez a késlekedés a projekt végsı

tervezett határidejét borítja fel.

25

4. A kritikus út meghatározása

A fentiek értelmében minden esemény bekövetkezésének meghatároztuk a legko-

rábbi és a legkésıbbi idıpontját. Ha a két idıpont nem azonos, azt jelenti, hogy az adott

esemény bekövetkezésénél tartalékidıvel számolhatunk. Ez ismét a végrehajtási szakasz-

ban lesz igazán fontos. Ha viszont az esemény bekövetkezésének legkorábbi és legkésıb-

bi idıpontja azonos, másképpen nincs az eseménynek tartalékideje, akkor az esemény a

végsı határidı tarthatósága miatt kritikus. Kritikus út azokon az eseményeken keresztüli

tevékenységek sorozatát jelenti, amelyeknek nincs tartalékidejük, a bekövetkezési legko-

rábbi és legkésıbbi idıpontok azonosak. A fenti lépéssorozat nélkül kevés alapunk lenne

arra, hogy szükség esetén (elıre nem tervezett akadályok már pedig mindig vannak) dön-

teni tudjunk arról, hogy melyik tevékenységet lehet elhalasztani, és melyiket nem. Pél-

dánkban a kritikus út: B – D – E – F – H. Pl. a C tevékenység 4 napos tartalékidıvel ren-

delkezik (a C tevékenységet „büntetlenül” késıbb indíthatjuk, vagy csúszhatunk a végre-

hajtásával úgy, hogy a 8. napra befejezzük).

Összegezve a CPM technika különösen több tucat (akár száznál is több) tevékeny-

ség ill. esemény esetén meglehetısen bonyolult, sok kötöttséggel és hibalehetıséggel járó

eljárás, viszont azzal, hogy a tevékenységeken túl eseményeket is tartalmaz, grafikailag

nagyon jól áttekinthetı hálót eredményez.

7 0 2

1 4

3

5

6

A (1) D (2) E (5) F (1)

H (2) B (2)

C (4) G (2)

0

0

8

4

10

10

9

9

4

4

2

2

2

2

12

12

26

4.3.2. MPM – tevékenység csomópontú háló

Az MPM technika lényegesen egyszerőbb a CPM eljárásnál, mert eseményeket

nem tartalmaz, a háló csomópontjaiba a tevékenységek kerülnek. Eseményt, mint fogal-

mat nem használ, viszont rendkívüli fontosságú eseményeket, un. mérföldköveket tudunk

ábrázolni úgy, hogy speciális, zérus idıtartamú tevékenységeknek értelmezzük ıket. Mér-

földkı lehet olyan fontos esemény, ami a WBS-bıl közvetlenül nem értelmezhetı, pl. az

adott vállalat a teljesített munkacsomag alapján kapja a szerzıdött díját, a fizetési pontok

lehetnek a mérföldkövek. Mérföldkıvel jelölhetjük azt is, ha az egyik projektszereplı a

másiknak információt ad, pl. egy pályázati projektben projekt elırehaladási jelentést

(PEJ) kell küldeni a finanszírozó számára.

A háló csomópontja az adott tevékenységrıl részletes információkat tartalmaz:

Korai kezdés Tevékenység idı-

tartam

Korai befejezés

Tevékenységnév vagy azonosító

Késıi kezdés Teljes tartalékidı Késıi befejezés

A háló felrajzolásánál egyszerően ábrázoljuk a tevékenységeket, majd azok közé a

tevékenységek közé húzzuk be a háló éleit, amelyek között megelızési, követési kapcso-

lat van (ld. megelızési lista). A megelızı és követı tevékenységek kapcsolatában négyfé-

le kapcsolattípust értelmezhetünk (befejezés-kezdés BK, kezdés-kezdés KK, befejezés-

befejezés BB, kezdés-befejezés KB), a kapcsolat típusa mellett megadhatunk késleltetési

idıt (lag time) is. Ezek között a keretek között csak BK kapcsolattípussal (a megelızı

tevékenység befejezése kapcsolódik logikailag a követı tevékenység kezdéséhez) és kés-

leltetési idı nélküli kapcsolattal (a megelızı tevékenység befejezése után rögtön elkez-

dıdik a követı tevékenység) foglalkozunk.

Az MPM háló több kezdı-, és végponttal rendelkezhet. Az MPM hálóban nincs

szükség a látszattevékenység használatára.

Az MPM háló létrehozásának lépései:

27

1. a háló felrajzolása

A háló felrajzolása nem olyan idıigényes, mint a CPM technikánál. A fentiek

alapján elıször a tevékenységeket, majd a köztük lévı logikai kapcsolatot ábrázoljuk. A

kapcsolatokat ábrázoló hálóélek keresztezhetik egymást. Példaprojektünk MPM hálójá-

nak a felrajzolása után elsı lépésként a tevékenységazonosítón túl csak a tevékenyég idı-

tartamot tudjuk kitölteni. A háló három kezdıponttal és egy végponttal rendelkezik.

2. A tevékenységek korai kezdési és befejezési idıpontjának meghatározása – idı-

tervezés elıre haladva.

A fentiekhez hasonlóan a hálóban elıre haladva végezzük az idıtervezést. Definí-

ciószerően a projektet kezdı tevékenységek korai kezdési idıpontja 0. Hasonlóan a CPM

háló tárgyalásánál már részletezett logikának megfelelıen, elıre felé haladva a hálóban

összeadunk. Az adott tevékenység korai kezdési és befejezési idıpontját a csomópont

megfelelı cellájába írjuk.

1

A

2

D

5

E

1

F

2

H

2

B

4

C

2

G

28

3. A tevékenységek késıi kezdési és befejezési idıpontjának meghatározása – idı-

tervezés visszafelé haladva.

A hálóban visszafelé végezzük az idıtervezést. Definíciószerően a projektet záró

tevékenység korai befejezési idıpontja (ami egyben a projekt befejezési idıpontja is)

megegyezik a késıi befejezési idıponttal. A CPM technikánál követett eljáráshoz képest

ügyeljünk arra, hogy itt nem csak egy végpontja lehet a hálónak. Hasonlóan a CPM háló

tárgyalásánál már részletezett logikának megfelelıen, visszafelé felé haladva a hálóban

kivonunk.

0 1 1

A

2 2 4

D

4 5 9

E

9 1 10

F

10 2 12

H

0 2 2

B

0 4 4

C

4 2 6

G

0 1 1

1 2

A

2 2 4

2 4

D

4 5 9

4 9

E

9 1 10

9 10

F

10 2 12

10 12

H

0 2 2

0 2

B

0 4 4

4 8

C

4 2 6

8 10

G

29

4. A kritikus út meghatározása

A hálóban elıre és visszafelé haladó idıtervezés után a tevékenységek tartalékide-

jét határozzuk meg úgy, hogy a csomópontokban egymás felett lévı kezdési vagy befeje-

zési idıpontokat kivonjuk egymásból. Az eredményt az alsó, középsı táblázatrészbe a

teljes tartalékidı cellájába írjuk be. A fentiekben részletezettek szerint azok a tevékenysé-

gek a kritikusak, amelyek tartalékideje 0. Példánkban a kritikus út ugyanúgy, mint a CPM

technikánál: B – D – E – F – H.

Összegezve az MPM hálót a CPM technikánál egyszerőbben, motorikusabban

(könnyen algoritmizálható módon) tudjuk létrehozni, viszont a kapott háló nem olyan

„szép”, grafikailag nem olyan áttekinthetı, mint a CPM háló. A projekttervezést támogató

szoftverek MPM hálótechnikával dolgoznak. A Microsoft Office 2003 programcsomag

tartalmaz projekttervezı szoftvert, sıt a Microsoft Office Project 2003 már magyar nyel-

ven is hozzáférhetı. Sok tevékenységet tartalmazó, összetett projektek tervezését min-

denképp ajánlatos nem papíron, hanem szoftveres támogatással végezni. A projekttervezı

szoftverek elterjedésével az MPM lett a leggyakrabban használt hálótervezési technika.

0 1 1

1 1 2

A

2 2 4

2 0 4

D

4 5 9

4 0 9

E

9 1 10

9 0 10

F

10 2 12

10 0 12

H

0 2 2

0 0 2

B

0 4 4

4 4 8

C

4 2 6

8 4 10

G

30

4.4. A projekt idıterve

Henry Gantt a XX. század elején publikálta dolgozatát az ütemezési problémákról.

Az ı munkája alapján kifejlesztett eszközt Gantt-diagramnak vagy sávos ütemtervnek

nevezzük. Az 50-es évekig szinte egyedüli projekttervezı eszköz volt, de a hálós tervezé-

si rendszerek kifejlıdése óta a hálóterv elkészülte után ajánlott az idıtervezéssel foglal-

kozni. A Gantt-diagramban a tevékenységeket soronként, egymás alatt, a táblázat fejléc-

ében az idıtengelyt helyezzük el. A tevékenység mellett feltüntetett sáv azt jelöli, hogy az

adott tevékenységet mikor kell elkezdeni, és mikor befejezni.

Példaprojektünk Gantt-diagramjához annyi a hozzáfőzni való, hogy a szombat,

vasárnap alapértelmezés szerint nem munkaidı, de a projektnaptár segítségével a projekt

idejére munkaidınek definiáltuk. Az idıtengelyen a hét napjait betőkkel azonosítjuk, a

hét elsı napjának dátuma azonosítja a hetet. Példaprojektünk (ami a fentiek alapján 12

napos) 2005. aug. 1-én, hétfın indul, és aug. 12-én, pénteken fejezıdik be.1

A Gantt-diagram könnyen érthetı, egyszerő eszköz. Hátránya, hogy nem mutatja a

tevékenységeknek a megelızıekkel való kapcsolatát (ezt a szolgáltatást a projekttervezı

szoftverekkel készített Gantt-diagramok már tudják). A feladatok végrehajtásának idıbeli

tervezésén túl használata tipikusan az elkészült projektterv kommunikálására, ill. a végre-

hajtás szakaszában a projekt tényleges és tervezett elırehaladásának az összevetésére irá-

nyul.

1 a Gantt-diagram Microsoft Office Project Professional 2003 szoftverrel készült

31

4.5. Erıforrás-tervezés

Az elızı fejezetekben nem foglalkoztunk az erıforrás kérdésével. A projekt ter-

vezésénél figyelmen kívül hagytuk, hogy a tevékenységek végrehajtásához erıforrásokra

is szükség van, tulajdonképp azt feltételeztük, hogy az erıforrások korlátlanul a rendelke-

zésünkre állnak. Ez – leszámítva az ókori uralkodók gigantikus építkezéseit – a valóság-

ban természetesen soha nem igaz. Az erıforrás-tervezésnél számba vesszük, hogy az

egyes tevékenységekhez milyen erıforrásra, milyen mértékben van szükség, majd ezt a

korábban elkészített hálótervbıl vagy Gantt-diagramból kiindulva az idı függvényében

ábrázoljuk.

Az erıforrások között munka és anyag típusúakat különböztetünk meg.

Munka típusú erıforrások:

• a szakemberek, pl. programozó, mérnök, kımőves, villanyszerelı,

• a gépek, szerszámok, berendezések, pl. fúrógép, markoló

Az anyag típusú erıforrások raktározhatóak, a projekt elırehaladtával folyamato-

san kerülnek felhasználásra, ilyen a beton, csempe, járólap, villanyvezeték.

A munka és anyagtípusú erıforrások között az a különbség, hogy a munkatípusúak

nem raktározhatóak, ezért meg kell adni a belılük rendelkezésre álló maximális mennyi-

séget (pl. a kivitelezésnél max. három villanyszerelı áll rendelkezésre), a rendelkezésre

állásukkal kapcsolatban naptárt értelmezhetünk (pl. pihenınapok, szabadságolás).

Az erıforrás-szükséglet ábrázolásánál annyi koordinátarendszerre van szükség,

ahány féle erıforrást a tevékenységek igényelnek. Példaprojektünkben az egyszerőség

kedvéért egy erıforrással, egy „univerzálisan képzett” személyzet nevő erıforrással dol-

gozunk. A koordinátatengelyek felrajzolása után tevékenységenként ábrázoljuk az erıfor-

rásigényt. Egy adott tevékenység erıforrásigénye egy olyan téglalap, aminek a vízszintes

oldala olyan hosszú, ameddig a tevékenység tart, függıleges oldala olyan hosszú, amek-

kora az erıforrás szükséges mennyisége. A koordinátarendszerbe elıször a kritikus útra

esı tevékenységekhez tartozó téglalapokat rajzoljuk be (B – D – E – F – H), ezt követıen

a többi tevékenységet. Ennek a sorrendnek az okát majd késıbb indokoljuk.

32

Az erıforrás-szükségletet értelmezve az elsı nap 4 fıre van szükségünk, közülük

egy-egy a B és a C tevékenységgel foglalkozik, kettı az A tevékenységgel. A projekt

elırehaladtával minden nap le tudjuk olvasni a szükséges erıforrás-mennyiséget. A ma-

ximális erıforrásigény 4.

Általában a projektek erıforrásigénye az idıben jelentıs hullámzást mutat, ezért

érdemes elgondolkodni, hogy a tevékenységek csúsztatásával találunk-e egyenletesebb

terheléső megoldást. Példaprojektünkben ez a téglák vízszintes tologatását jelenti. Ezért

kerültek a kritikus tevékenységek téglái alulra, mert azok tologatása a projekt végsı ha-

táridejének eltolását is jelentené, ezért ezt, ha csak lehetséges el kell kerülni.

Megoldásunk: C tevékenységet (ami 4 napos tartalékidıvel rendelkezik) ne kezd-

jük el a projekt kezdetekor, egy napot csúsztassuk, a projekt elsı napján az A és a B tevé-

33

kenységekkel induljunk. C tevékenység maga mögött egy nappal hátratolja G tevékeny-

séget, ezt is megtehetjük, mert G tevékenység 4 napos tartalékidıvel rendelkezik. A pro-

jekt végrehajtásához így egy az eredetinél egyenletesebb erıforrás-kihasználást eredmé-

nyezı megoldásra jutottunk, a maximális erıforrás-igényünk három fı lett. Manapság

nem kell ezen az optimalizálási problémán papíron, ceruzával bajlódnunk, ezt a szolgálta-

tást a projekttervezı szoftverek felajánlják (erıforrás-terhelés simítása).

Gyakori, hogy az erıforrás-tervezés végeztével azt kell, hogy megállapítsuk, hogy

nem rendelkezünk a szükséges számú erıforrással. Azt az esetet, amikor a meglévı erı-

forráskorlátokat be kell tartani, akkor is, ha a projekt átfutási ideje megnı, erıforrás-

korlátos allokálásnak nevezzük.

A másik esetet, amikor az átfutási idı nem változhat, tehát a szükséges erıforrá-

sokat egy estleges terhelés-simítás után tőzön-vízen keresztül (akár költségtúllépés árán

is) biztosítanunk kell, idıkorlátos allokálásnak nevezzük.

4.6. A projekt költségeinek a felmérése

A projekt költségeinek minél pontosabb becslése alapvetı fontosságú a menedzse-

ri döntések és az ellenırzés szempontjából. A költségek pontos becslése a projekt kezdeti

fázisában nehezen megvalósítható feladat, ugyanakkor a késıbbi szakaszokban a pontos-

ság egyre nyilvánvalóbban elvárható. A költségkalkuláció két módszere:

A paraméteres költségbecslési eljárás lényege, hogy a korábbi hasonló projektek

költségei alapján becsüljük meg a tervezett projekt költségeit. Pontatlansága miatt csak a

projekt kezdeti szakaszában lehet létjogosultsága.

A tevékenységalapú költségbecslés pontosabb. Költségeket az eddigi szóhasználat-

tal a tevékenységekhez vagy az erıforrásokhoz rendelhetünk.

A tevékenységhez rendelt költségek (fix költségek) olyan költségek, amelyek füg-

getlenek a tevékenység idıtartamától, és az erıforrások által végzett munkától. Ilyen költ-

34

ség pl. építési projekteknél különbözı engedélyezési eljárásokhoz kapcsolódó költségek,

pályázatoknál a pályázati dokumentáció ára.

Az erıforrásokhoz rendelt költségeknél fajlagos összegeket rendelünk az adott

erıforráshoz (pl. munkadíj vagy gépek bérlése esetén Ft/óra, Ft/nap, anyag típusú erıfor-

rások esetén Ft/m2, Ft/folyóméter)

A projektköltségek felmérési módszereinek elemei:

• munka költségei

• anyagi költségek

• szolgáltatások költségei (szerzıdéses kivitelezık)

• gépesítés és felszerelések költségei

• projektmenedzsment költségei

• a vezetés és az adminisztráció költségei

• járulékok, adók, biztosítások és licencek költségei

• inflációs költségek

4.7. Kockázat

Bizonyos összefüggésekben elmondható, hogy a projektmenedzsment egyfajta

kockázatmenedzsment, hiszen a projektmenedzser célja, hogy a projektet veszélyeztetı

számtalan kockázati tényezı fölött úrrá legyen.

Kockázatnak minısül minden olyan tény, hatás, rendszerfunkció, összefüggés

stb., amely a projekt sikeres megvalósulását gátolja, kritikus esetben lehetetlenné teszi. A

kockázatok lehetnek:

• külsı kockázatok (települési, politikai, környezetvédelmi stb.)

• pénzügyi kockázatok (rossz vagy felületes költségtervezés, likviditási ne-

hézség, tárgyi eszközöket érı elemi kár stb.)

• tevékenységbıl fakadó kockázatok (mőködési zavarok, alacsony haté-

konyságú információáramlás, helytelen ütemezés vagy nem betartott ütem-

terv, stb.)

• emberi erıforrással kapcsolatos kockázatok (kompetenciahiány, motiválat-

lanság, együttmőködési készség hiánya, érdektelenség stb.)

35

A kockázatok azonosítását, valamint a projekt elırehaladása során a kockázatok

súlyának követését, módosulását a projektek teljes folyamatában követni kell. A kockáza-

tok azonosításához segítséget nyújt a következı szempontrendszer:

• kockázat megnevezése,

• kockázat azonosításának forrása,

• kockázat kifejtése,

• kockázat értékelése.

Ez a munka lényegében két tényezıbıl áll:

• a kockázati tényezık felismerésébıl és elemzésébıl (Risk Identification,

Risk Analysis), és

• a kockázati tényezık kezelésébıl.

A kockázati tényezık felismerése és elemzése a kockázati esemény bekövetkezé-

sének esélyeivel és a projektre gyakorolt esetleges hatásaival foglalkozik. A kockázati

kezelése viszont a veszély elhárítása, illetve káros hatásainak mérséklése érdekében teen-

dı lépéseket takarja.

4.7.1. Kockázati tényezık felismerése és elemzése

Projektek esetében fel kell készülni olyan lehetıségre, hogy valami nem a tervek-

nek megfelelıen alakul. A tervezés és megvalósítás folyamán számos területen, számos

tényezı jelenthet kockázatot, amelyek különösen veszélyesek, ha érintik az idı- költség-

minıség hármas paraméterét.

Kockázatelemzés során azokat a kockázati tényezıket kell számszerősíteni, ame-

lyek a projekt végrehajtásában befolyással vannak. Ilyen tényezı például a vezetıség rá-

termettsége, a munkacsoportok szakértelme, a határidık, vagy a projekt jellege. A kocká-

zati tényezık értékelése lehetıvé teszi a menedzsment számára a kockázati tényezık fi-

gyelemmel kísérését a megvalósítás során, és elısegíti az esetleges gyors beavatkozást.

A kockázat megítélésekor kétféle adatot kell megnézni:

� a kockázat fokát, illetve

� az adott tényezı kockázata milyen súlyozással szerepel a projekt teljes

kockázatának megítélésekor.

36

Mindezt egy 10-es skálán lehet osztályozni:

Mennyire valószínő?

Valószínőtlen Valószínő Nagyon valószínő

Milyen súlyos következményekkel jár?

Jelentéktelen Súlyos Nagyon súlyos

Forrás: Peter Hobbs (2000)

A kockázat felbecslésekor figyelembe kell venni, hogy mennyire valószínő, és mi-

lyen következményekkel jár az adott kockázat bekövetkezése.

Ez alapján mérlegelni lehet például a szállítási késedelem kockázatát. Nem túl va-

lószínő (4), de súlyos következményekkel jár annak bekövetkezése (9). A két adat össze-

szorzásával egy 100 alatti számot kapunk (36), ami a kockázat kezelésének fontosságát

jelzi. Amennyiben a szám 25 fölötti, szükséges annak körültekintı figyelembe vétele. Ez

esetben ajánlatos a szállítással kapcsolatos kockázatokkal elızetesen is foglalkozni.

A kockázati tényezık értékelése magába foglalja:

� az egyes kockázati tényezık azonosítását,

� a tényezıknek a végrehajtás menetére, a költségekre, az ütemtervekre és a

minıségre gyakorolt hatása szempontjából történı elemzését,

� a projekt megvalósítása során várható érvényre jutásuk esélyeinek becslé-

sét, a projekt

� veszélyeztetettségének meghatározását,

� a kockázati tényezıkre – azok halmozott érvényre jutásának valószínősé-

ge, hatása és az okozott problémák nagysága függvényében meghatározott

prioritások felállítását.

4.7.2. A kockázati tényezık kezelése

A kockázatokat megelızni, kezelni és kikerülni lehet. A lehetı legrosszabb eset,

amikor szemet hunyunk az esetleges veszélyforrások felett. Ezzel szemben a legjobb

megoldás, ha idıben meghatározzuk a projekt összes lehetséges kockázatát és kezelésé-

nek módját, csökkentve így a projektterv módosításának szükségességét.

1 2 3 6 4 5 7 8 9 10

1 2 3 4 5 9 8 7 6 10

37

A kockázatokat a vállalat szemszögébıl nézve csoportosítani lehet emberi, techni-

kai, pénzügyi, politikai, jogi, környezeti forrásokból eredı kockázatokra.

A kockázatelemzés során beazonosított kockázati tényezıket az alábbi sorrendben

célszerő megvizsgálni:

1. nagy hatású, nagy bekövetkezési valószínőségő kockázati tényezık,

2. nagy hatású, kisebb bekövetkezési valószínőségő kockázati tényezık,

3. kisebb hatású, nagy bekövetkezési valószínőségő kockázati tényezık.

A kisebb hatású, kis bekövetkezéső valószínőségő kockázati tényezıkkel kapcso-

latban érdemes a kockázat elfogadását, egyszerő tudomásul vételét megfontolni.

Minden külön kezelésre szoruló kockázati tényezı estében a projektmenedzsernek

a kockázat csökkentésére hatékony megoldást kell találnia. Az ellenintézkedés lehet:

� a kockázati tényezı teljes kiiktatása,

� a kockázat mértékének (bekövetkezési esélyének vagy hatásának) csök-

kentése,

� a kockázatviselés áthárítása másokra (biztosítás),

� vészelhárítási tervek készítése (a kockázati esemény bekövetkezésének

esetére,

� a kockázati tényezı elfogadása (egyszerő tudomásul vétele).

38

4.8. A projektindító dokumentáció

A tervezési szakaszt a projektindító dokumentáció összeállítása zárja le, amit a

projektmenedzser letesz a projektszponzor asztalára, ami alapján döntés születik a

megvalósításról.

Tartalmazza:

• az üzleti ötlet vagy szükséglet leírását, melyet a projekttel oldunk meg

• a projekt megrendelıjét

• a projekt kulcsfontosságú követelményeit és korlátait

• a projekt eredményeit és annak használóit

• a projekt WBS struktúráját

• a projekt hálótervét

• a projekt idıtervét

• a projekthez szükséges erıforrások tervét

• a projekt költségeinek tervét

• a projekt finanszírozásának tervét

• a projektet kivitelezı szervezet leírását, a kompetenciák és felelısségek

meghatározásával

• a projekt kockázatainak meghatározását, és azok elhárításának módját

• a projekt-kivitelezés ellenırzı rendszerének meghatározását

39

5. A PROJEKT KIVITELEZÉSE

5.1. A projektteam megbeszélése a kivitelezés során

A projektszponzor „menjen” döntése után a projekt a kivitelezés szakaszába lép. A

projektteam felállítása vagy a projektmenedzser feladata, vagy – és ez inkább a tipikus –

„hozott anyagból dolgozik”, a funkcionális területek vezetıi delegálják egy-egy munka-

társukat a csoportba. A teamekben jellegzetes szerepek alakulnak ki. Bögel György és

szerzıtársai (2001) szerint:

• ötletember – kreatív, jó képzelıerıvel, könnyen elszakad a meglévı meg-

oldásoktól, bonyolult problémákra is talál megoldást, gyengesége lehet,

hogy nem figyel a részletekre és a korlátokra;

• elnök – a kitőzött cél lebeg a szeme elıtt, nyugodt, szisztematikusan építi a

csapatot, másokat dolgoztat, nem biztos viszont, hogy a kreatív csoport-

tagok közé tartozik;

• hajcsár – dinamikus, szereti a feszültséget, hajtja a többieket, könnyen

provokál másokat, keveset törıdik az érzelmekkel;

• csapatmunkás – józan, szeret kooperálni, diplomatikus, figyel másokra,

többféle szempontot mérlegel, kompromisszumos megoldást keres, kiéle-

zett helyzetekben gyakran döntésképtelenné válik, esetleg könnyen befo-

lyásolható;

• megvalósító – fegyelmezett és hatékony, mások ötleteit kivitelezi, gyakor-

latias, néha nem eléggé rugalmas, nehezen tér le a megkezdett útról;

• specialista – nagyon jó szakember a maga területén, fontos információk,

elképzelések forrása, nehezen fogad el másfajta megközelítési módokat,

gyakran szem elıl téveszti a végsı célt, könnyen leragad egyes részletek-

nél.

Optimális esetben a projektteam tagjai harmonikusan dolgoznak együtt a kockáza-

tok kezelésén, a feladatok végrehajtásán, elkötelezettek a projekt világosan megfogalma-

zott céljai mellett. Ez a megállapítás korántsem olyan magától értetıdı. A projektmene-

dzsernek fontos feladata a csapatépítés, aminek kulcselemei:

� a megfelelı emberek megtalálása;

� a csoporton belüli bizalom megteremtése;

� pozitív team-környezet kialakítása

40

♦ a team mőködését leíró játékszabályok világos megfogalmazása,

♦ a közös cél iránti elkötelezettség, a csoporttagok azonosulása a team-

mel,

♦ egymásra figyelés képessége,

♦ projektmegbeszélések eredményes menedzselésének képessége.

A csapatépítést szolgálják a gondosan elıkészített házon kívüli (outdoor) trénin-

gek. A résztvevık közös tevékenységeket végeznek sokszor játékos formában annak ér-

dekében, hogy növeljék a tagok közötti kölcsönös megértést és bizalmat.

A projektmenedzser elsı lépésként nyitóértekezletet (kick off meeting) hív össze.

A kick off egy összefoglaló a projektrıl. Ezzel az összefoglalóval segítséget nyújtanak a

résztvevı tagoknak, a tervezés és a teljesítés nyomon követése érdekében hozzák létre.

A projektteamnek az elsı megbeszélés után rendszeresen kell megbeszéléseket

tartani, hogy áttekintsék a projekt alakulását. A megbeszélések eredményérıl a projekt-

szponzort is tájékoztatni kell. A megbeszélések gyakorisága általában a projekt nagyságá-

tól függ. Rövid (6 hónapnál rövidebb), vagy sok tevékenységet magába foglaló projektek

esetében hetente, kéthetente célszerő megbeszéléseket tartani. Hosszabb vagy kevesebb

tevékenységet tartalmazó projektnél elegendı havi rendszerességgel találkozni.

A megbeszélés eredményességének érdekében a projektmenedzsernek, aki egyben

a tárgyalások levezetıje is, alaposan fel kell készülnie. Célszerő napirendet készíteni,

amit a csoport tagjainak elızetesen a tudomására kell hozni.

A megbeszélésen a csoport tagjai beszámolnak feladataik vagy alprojektjeik hely-

zetérıl. Ezeken a megbeszéléseken a csoport áttekinti a projektmegvalósítás folyamatát,

összehasonlítja az aktuális állapotot a tervvel, megtárgyalja az eltéréseket, azok okait.

Megvizsgálja a határidık betarthatóságát. Fontos, hogy rögzítsük a megbeszélt tennivaló-

kat, minden feladathoz felelıst és határidıt rendeljünk.

41

A megbeszélés után lehetıleg egy napon belül készítsük el a jegyzıkönyvet vagy

emlékeztetıt, azt juttassuk el a csoporttagokhoz. A megbeszélést lezáró dokumentum

egyben a következı megbeszélés elıkészítését is szolgálja.

A döntéshozatalra számos lehetısége van a csoportnak:

� konszenzus – az egész team egyetértésre jut a döntésben

♦ elınye: mindenki részt vett a döntéshozatalban, a team nagymértékben

elkötelezett lesz a döntés iránt

♦ hátránya: a konszenzus kialakítása nagyon sok idıt vesz igénybe, kü-

lönösen nagy létszámú csoport esetén

� szavazás - egyszerő többségi szavazattal döntenek

♦ elınye: gyors, sok ember bevonására alkalmas

♦ hátránya: ha a választási lehetıségek bonyolultak, kicsi a valószínősé-

ge, hogy mindenki pontosan megérti; a vesztes oldal kevésbé elkötele-

zett a döntés iránt

� delegálás – a vezetı átengedi a döntést egy vagy több team tagnak, akik a

szükséges információkkal és szakértelemmel rendelkeznek

♦ elınye: leegyszerősíti a döntési folyamatot, mert kevesebb emberre van

szükség

♦ hátránya: a teljes csoportnak meg kell bíznia a döntéshozók informá-

cióiban és szakértelmében

� autokratikus – a döntést a projektmenedzser hozza meg

♦ elınye: a csoport vezetıjének gyakran más a gondolkodásmódja és a

felelıssége, ami alkalmassá teszi a döntés meghozatalára

Elıkészítés

A megbeszélés kivite-lezése

Leírás és kivi-telezés

Következı megbeszélés

42

♦ hátránya: a team elkötelezettségét a döntés iránt az határozza meg,

hogy mennyire elkötelezett a projektmenedzser iránt; ha a projektme-

nedzser mindig autokratikus döntéseket hoz, és a team nem ért egyet

ezekkel a döntésekkel, akkor megrendül a vezetıbe vetett bizalmuk, és

csökken a team elkötelezettsége.

5.2. Változtatások a projekten

Általánosságban elmondható, hogy még a legalaposabban megtervezett projektek

sem valósulnak meg teljes mértékben a tervezett módon, váratlanul felmerülı problémák-

ra mindig számítani lehet. A változtatásokat két csoportba sorolhatjuk:

• külsı, finanszírozott változások, és

• belsı, nem finanszírozott változások.

A külsı, általában a megrendelı által kért változtatások automatikusan a projekt

megfelelı részének módosulásához vezetnek. A változtatások többnyire a költségek nö-

vekedéséhez vezetnek, amit a megrendelınek kell finanszíroznia.

A belsı változtatások költségeit, amik elıre nem látható problémákból keletkez-

nek, általában a megrendelı nem fizeti meg. A belsı változtatási igényeket a projektteam

tagjai kezdeményezik. A folyamat lépései a következık:

1. Minden esetben meg kell vizsgálni a változtatási igény jogosságát.

Amennyiben a team tagok olyan szervezeti, szabályozási vagy technikai változá-

sokat tapasztalnak, amelyek befolyásolhatják a projektet, javaslatot kell tenniük a változ-

tatásra, hogy a problémát megoldják, vagy elkerüljék.

A változtatási javaslatokat nem lehet kritika nélkül elfogadni. Minden esetben

meg kell vizsgálni, hogyan szolgálja a javaslat a vevı elégedettségét, a szervezet sikeres-

ségét, a projekt céljait.

2. Amennyiben a javaslat elfogadásra került, és nem jár a projektterv módosításá-

val, be kell vezetni.

3. Ha a változtatás a projektterv módosításával jár, meg kell határozni a befolyá-

sát a tervre, és el kell készíteni a változtatási kérelmet.

A változtatási kérelem olyan dokumentum, aminek tartalmaznia kell a javaslat le-

írását, a projektre, a projekt kockázataira, a költségekre és az ütemezésre gyakorolt hatá-

sát.

43

4. A változtatási kérelem elfogadtatása és bevezetése.

Általában a projektszponzor hagyja jóvá a változtatási kérelmet.

5. A projektterv aktualizálása a változtatások beillesztésével.

A projektmenedzser felelıssége a változtatások beillesztése a projektterv megfele-

lı helyére. Azonnal értesítsünk mindenkit, akit a módosítás érint.

5.3. Projektkontrolling

A projektkontrolling egyrészrıl az ellenırzésbıl és felügyeletbıl, másrészrıl

azokból az intézkedésekbıl áll, amelyek az ellenırzés során felmerült eltérések kijavítá-

sához szükségesek. Szempontjai:

• A terv szerint halad a megvalósítás?

• A kitőzött célok felé halad a kivitelezés?

• Folyamatos információgyőjtés és elemzés

• A gyengeségek felismerése, fejlesztése

• Rugalmas megoldáskeresés

• Visszacsatolás a tervezéshez, tanulságok

• Dokumentálás

A projektkontrolling fı lépései a következık:

1. Meg kell határozni az ellenırzés gyakoriságát, amely során az ütemezés, a ha-

táridık és a költségek aktuális állapotát értékelik.

Rövid, két hónapos projektek esetén célszerő hetente, hosszú, akár több éves pro-

jekteknél elegendı havonta az ellenırzést elvégezni.

2. Össze kell hasonlítani az aktuális állapot ütemezett feladatait, a határidıket és

a költségeket a tervekkel, valamint vizsgálni kell az eltéréseket.

Döntı jelentısége van annak, hogy a rendszer teljesítménye, a minıség, a határ-

idık és a költségek közötti kapcsolat elemzésre kerüljön.

Az eltérések okai a következık lehetnek:

• nem reális tervezés

• elıre nem látható szükséges változtatások

• a tevékenységmegvalósításnál hibás munkavégzés.

A költségek túllépésének okai lehetnek:

44

• a projekt pontatlan behatárolása – szükséges tevékenységek hiányoznak

• hibás menedzsment döntések – ahhoz, hogy tartani tudjuk a szerzıdést, túl

sokat vállaltak

• meggondolatlan változtatások

• az idıbeli csúszások behozási szándéka

• alacsony, nem reális költségbecslés

• elıre nem látható technikai nehézségek.

3. Dönteni kell a szükséges intézkedésekrıl a felismert eltérések esetén.

Amennyiben eltérés tapasztalható a tervekhez képest, a teamnek további lépéseket

kell tenni. Meg kell vizsgálni, hogy létezik-e ésszerő magyarázat az eltérésekre. Ha az

eltérés a projekt további tevékenységeit befolyásolja, akkor a projekttervet módosítani

kell. A változtatást az elızı fejezetben tárgyaltak szerint kell végrehajtani.

A következı ábrán láthatóak a lényeges kapcsolatok a tervezés, irányítás, felügye-

let és a megvalósítás között.

Forrás: Hans-D Litke (1995)

A projektirányítás a projektmenedzser összes projekttevékenységét tartalmazza,

amelyek szükségesek ahhoz, hogy a projekt folyamata a tervezett értékek keretében tör-

ténjen.

A következı nézıpontokat kell figyelembe venni a vezérlésnél:

TERVEZÉS

ELLENİRZÉS MEGVALÓSÍTÁS

IRÁNYÍTÁS

Elıirányzott értékek

Tényleges értékek

Elıirányzott értékek

Döntések Intézkedések

45

• A projektmenedzsernek nem szabad a tervezett projektet magára hagyni,

hanem aktívan irányítania kell,

• azonnal be kell avatkoznia, ha eltérések merülnek fel a határidık és a költ-

ségek vizsgálatánál,

• megbeszéléseken keresztül folyamatosan informálódnia kell a projekt me-

netérıl.

46

6. A PROJEKT ÁTADÁSA ÉS ÉRTÉKELÉSE

6.1. A projekt átadása

A projektben meghatározott tevékenységek befejezése után a projektcsapat a pro-

jekt eredményét átadja a megrendelınek. Az átadás a gyakorlatban mindkét fél részére

különös jelentıséggel bír. Ha az átadás nem egy meghatározott ponton történik, a projekt

részvevıi úgy érezhetik, hogy erıfeszítéseik hiábavalóak voltak. Ebben az esetben annak

a veszélye is fennáll, hogy a csapattagoknak továbbra is foglalkozniuk kell a megrende-

lıkkel, így nem összpontosíthatnak újabb feladataikra. Az átadás pillanatától kezdve a

megrendelınek feladatai és kötelezettségei vannak a projekt eredményével kapcsolatban.

Elsısorban el kell sajátítania a használatát. Az elınyök felismerése ellenére az emberek

nehezen fogadják el a változásokat, különösképpen ha azokat a megkérdezésük nélkül,

felülrıl erıltetik rájuk. „Átadási teendıknek” azokat a módszereket, feladatokat nevez-

zük, amelyeket végrehajtva a felhasználók számára világossá válhat, mire számíthatnak a

projekt eredményével kapcsolatban, és mire van szükségük az átálláshoz. Az átadási te-

endıknek három csoportját szokás elkülöníteni. Ezek a bevonás, egyeztetés és az elvárá-

sok tisztázása.

A sikeres átadás alapja az érintettek, különösképpen a felhasználók minél korábbi

bevonása az estleges változtatásokba. Az érintetteket meg kell ismertetni az elképzelé-

sekkel, és ki kell kérni a véleményüket. Javaslataik és ötleteik meghallgatása, megvitatása

és beépítése a projektbe segít elfogadtatni a változásokat, hisz ily módon részesei, kezde-

ményezıi lesznek a projektnek. Az érintettek bevonását célszerő a projekt minél korábbi

szakaszában, lehetıség szerint már a projekt meghatározása során megtenni.

A kivitelezés szakaszában folyamatos párbeszédnek, egyeztetésnek kell zajlania a

projektcsapat és a felhasználók között. A felhasználónak tudnia kell, hogy mit, mikor, és

milyen feltételek mellett fog megkapni. Ki kell emelni a projekt elınyeit, de nem szabad

elhallgatni a hátrányait sem. A projektet érintı változásokról a megrendelıt a lehetı leg-

korábban értesíteni kell. A projekt során dokumentumokat, információkat (változtatási

dokumentációkat, a megbeszélések jegyzıkönyveit, stb.) el kell juttatni az érintettekhez.

Szükség esetén elıadások tartásával lehet a felmerülı kérdéseket megvilágítani.

47

Az emberek tudni akarják, milyen változásokat hoz a munkájukban a projekt

eredménye. Erre fel kell készíteni ıket. A projekt eredményét be kell mutatni, használatát

meg kell tanítani nekik. Ezt a folyamatot nevezik az elvárások tisztázásának. Lényeges

szempont az idızítés. A túl korai tisztázás azzal a veszéllyel jár, hogy az érintettek megfe-

ledkeznek a hallottakról. A szükséges információkat célszerő többször az érintettek tu-

domására hozni.

6.2. A projekt értékelése

A szervezet minden projektjét egyfajta tanulási lehetıségként érdemes kezelni. A

projekt értékelési szakasza éppen ezt a célt szolgálja. Az értékelés az átadás után követke-

zı, tehát a projekt záró szakasza. A projektteam és a vállalat érdekei is azt kívánják, hogy

az értékelés minél szigorúbb vizsgálat legyen. Az értékelésnek nem csak a hibák össze-

győjtése és elemzése a célja. Ugyancsak fontos megjegyezni azokat a mozzanatokat a

projektbıl, amik a vártnál is jobban sikerültek. Az elıforduló hibákat azért célszerő ala-

posan megvizsgálni, hogy a következı projekt alkalmával hasonló hibák ne következze-

nek be.

Az emberek szeretik tudni, hogyan vélekednek teljesítményükrıl, különösen ak-

kor, ha a projektbe rengeteg energiát fektettek. Az értékelés stádiumában minden munka-

társ teljesítményét összegezni kell. Amennyiben a csapattagok kezdettıl tisztában vannak

azzal, hogy elemzik és dokumentálják a munkájukat, nagyobb erıfeszítéseket tesznek a

siker érdekében. A projektszponzor értékeli a projektmenedzser munkáját, aki ugyanezt

teszi a csapat tagjaival.

A projekt átadását követıen mielıbb célszerő értékelı megbeszélést tartani. Az át-

tekintés halogatása lényeges mozzanatok elfelejtésével járhat. Az értékelésnek ki kell

terjednie a projekt folyamatára és az eredményére is. Az értékelés során felszínre kerül-

48

hetnek olyan projektterületek, amelyeket nem sikerült kielégítıen feldolgozni, ill. hol van

szükség további fejlesztésre.

Az értékelési szempontokat Peter Hobbs (2000) hét pontban foglalta össze:

1. A határidıkkel és az idıtervekkel kapcsolatos értékelı szempontok

• Mennyire haladt az elızetes tervek szerint a projekt?

• Mely területek igényeltek több ráfordítást?

• Milyen tapasztalatokat lehet leszőrni a projekt ütemezésébıl?

2. A költségekkel és a költségtervekkel kapcsolatos értékelı szempontok

• Mennyire tudta a projekt a tervezett költségvetést tartani?

• A projekt mely tevékenységei kerültek a tervezettnél többe vagy keveseb-

be?

• Mi okozta a költségvetés pontatlanságát?

3. A projekt eredményével kapcsolatos értékelı szempontok

• A projekt eredménye mennyire elégítette ki a megrendelı igényét?

• Hogyan lehet az igényeket pontosabban meghatározni?

4. A projektben közremőködıkkel kapcsolatos értékelı szempontok

• Megfelelı volt a feladatok elosztása a projektteamben?

• A munkatársak megfelelıen értelmezték szerepüket?

• Sikeres volt a teljesítmény értékelése?

5. A kommunikációval kapcsolatos értékelı szempontok

• Az emberek tisztában voltak a munka menetével?

• Idıben megkaptak minden szükséges információt?

• A problémákat gyorsan jelezték?

• Az érintettek nem zártak ki senkit a kommunikációból?

• Milyen javítási lehetıségei vannak a kommunikációnak?

6. Módszerekkel kapcsolatos értékelı szempontok

• A projekt meghatározásához és tervezéséhez használt módszerek eredmé-

nyesek voltak?

• Hogyan valósult meg a folyamatok és változások ellenırzése?

• A projektmunka során vezettek be új módszereket?

7. A projekttel kapcsolatos összbenyomás értékelése

49

Dokumentumszerően a projektmenedzser a projekt zárójelentésével zárja le a

projektteam mőködését. Ez a dokumentum a projektindító dokumentációval együtt a pro-

jekt két legfontosabb dokumentuma.

A projekt zárójelentése:

• A projekt megvalósított céljainak felsorolása.

• Annak felsorolása, hogy mit nem valósítottak meg, és miért nem.

• Jelentés a terv realizálásáról (idı, források, költségek, pénz).

• A projektmenedzser jelentése a projekt eredményei terén való lehetséges

további munkára, illetve hasonló projektek megvalósítására vonatkozó ja-

vaslatokkal.

50

7. PROJEKTMENEDZSMENT ÉS SZERVEZETI STRUKTÚRA

Minden vállalat saját elképzelésekkel rendelkezik szervezetének kialakításáról és

munkájáról. Azonos terméket gyártó vállalatokat összehasonlítva azt találhatjuk, hogy

szervezeti felépítésük jelentısen különbözik. Az eltéréstıl függetlenül ezek a vállalatok

mind sikeresek lehetnek. Ezért nem lehetséges egyértelmően meghatározni azt a vállalati

struktúrát sem, amely a projektek szempontjából a legmegfelelıbb.

A projektmenedzsment és a szervezeti struktúra kapcsolatát három lépésben tár-

gyaljuk.

A tipikusan lineáris-funkcionális szervezeti felépítéső vállalat életében megjelenik

a projekt. Ha egyre sőrőbben dolgoznak projekteken, érdemes ezt a szervezetnek is kö-

vetnie, ajánlatos a szervezetet ennek megfelelıen átalakítani, a lineáris-funkcionális

struktúrát mátrix struktúrává fejleszteni. A harmadik állapot, a projektközpontú struktúra,

olyan vállalatok esetében tipikus, ahol a projektben való mőködés a meghatározó. Ilyenek

például a beruházó, építıipari vagy a kutatás-fejlesztéssel foglalkozó vállalkozások.

Érdekes lesz vizsgálni a kétfajta érdek, a projektérdek és a funkcionális szerveze-

tek által képviselt szakmai érdekek kapcsolatát. Leegyszerősítve azt állíthatjuk, hogy a

három lépés megfeleltethetı annak a logikának, hogy a projektérdek és a funkcionális

szervezetek által képviselt szakmai érdekekhez képest elıször héttérbe szorul, majd ho-

gyan lesznek egyenrangúak, végül a projektérdek háttérbe szoríthatja a funkcionális szer-

vezetek által képviselt szakmai érdekeket.

7.1. Projektmegvalósítás lineáris-funkcionális struktúrában

A lineáris-funkcionális szervezeti struktúrában történı projektmegvalósítás során

a projekthez tartozó tevékenységeket a funkcionális egységek látják el. A projekttel kap-

csolatos lényegi döntéseket a vállalat vezetıje hozza meg. A projektmenedzser sajátos

módon helyezkedik el ebben a szervezetben. Munkáját a vállalatvezetı közvetlen irányí-

tásával látja el. A lineáris-funkcionális szervezeti struktúrában történı projektmegvalósí-

tás kapcsolatrendszerét a következı ábra szemlélteti.

51

Ebben a szervezeti elrendezésben a projektmenedzsernek nincs közvetlen utasítási

joga a funkcionális szervezetek számára. Ugyanakkor az osztályvezetık hatásköre is csak

az osztályaik határáig terjed, azaz a projekt egészére vonatkozó döntéseket nem hozhat-

nak. Ezeket a döntéseket a vállalat vezetıjének kell meghoznia. A projektmenedzser eb-

ben a szervezeti formában sokkal inkább egy információközpont szerepét tölti be, mint a

projekt irányítója és szervezıje. Szerepe elsısorban információgyőjtésbıl, elemzésbıl,

tanácsadásból – és persze adminisztrációból - áll. Ebbıl következıen a projektmenedzser

befolyása a döntéshozatalra és a döntések végrehajtására meghatározó lehet. Nagy nehéz-

ség, hogy az emberek kétfelé dolgoznak, a projektmunka mellett a szokásos munkájukat

is ellátják, az osztályérdekek háttérbe szoríthatják a projektérdekeket. Erısen hierarchikus

szervezetekben jellemzıbb a szerepkultúra, mint a feladatkultúra, vagyis a rang az, ami

számít. Ilyen szervezetekben a projektmenedzsernek csak akkor lehet esélye a sikerre, ha

átmenetileg olyan rangra emelik, mint amilyen a funkcionális osztályvezetıknek van,

különben rendkívül nehéz lesz velük kommunikálnia. Feladatkultúrájú szervezetekben ez

nem gond, ott a szakmai kompetenciák szabják meg valakinek az elfogadottságát.

7.2. Projektmegvalósítás mátrix struktúrában

Az elızıekben vázolt problémák már egyetlen projekt esetében is jelentkezhetnek,

de ekkor még nincs értelme a jól mőködı struktúrát módosítani egy korlátozott ideig élet-

ben maradó projekt kedvéért. Megváltozik a helyzet, amikor a szervezet egy idıben több

projektet szándékozik megvalósítani. Ebben az esetben a szervezet kénytelen a lineáris-

funkcionális struktúráját átalakítani. Így jönnek létre a mátrixszervezetek.. A mátrixszer-

vezetben szükség lesz egy projektcsoport (projektvezetıi pool) felállítására. Tagjai füg-

gelmileg is ide tartoznak, mind szakmailag, mind projektvezetést tekintve képzett embe-

Vállalatvezetı

Fejlesztés Termelés Beszerzés Személyügy Pénzügy Logisztika

Alaptevékenységek

Projektvezetı

52

rek. A mátrixszervezetben irányított projektmegvalósításkor a különféle tevékenységeket

a megfelelı funkcionális szervezetek munkatársai végzik a projektmenedzser horizontá-

lis, valamint a funkcionális vezetık vertikális irányítása mellett.

A projekt teljesítésével kapcsolatos döntések megoszlanak a funkcionális egysé-

gek vezetıi és a projektmenedzser között. Amennyiben igénylik, az osztályokból szak-

embereket jelölnek a projektteambe. A mátrixstruktúra sajátosságából következik, hogy a

szervezetileg különféle funkcionális egységekhez tartozó munkatársak két felettestıl kap-

nak utasítást. Éppen ezért a mátrixszervezet kulcskérdése a funkcionális vezetık és a pro-

jektmenedzser közötti kapcsolat, a hatáskör és felelısség megosztása. Fontos a projekt-

menedzsereket és a funkcionális vezetıket ugyanúgy motiváló érdekeltségi rendszer ki-

dolgozása.

Ennél a szervezeti felépítésnél problémát jelenthet, ha egy projekt befejezése után

nem indul újabb projekt, amit a team felvállalhat. Ha ugyanis akár csak egy ember feles-

legessé válik a befejezés után, akkor a többiek úgy gondolják, hogy nem szabad efféle

munkáért a karrierlehetıségeiket kockára tenni.

7.3. Projektmegvalósítás projektközpontú struktúrában

Az elıbbi problémák folyamatosan megszőnnek, amint a szervezet egyre inkább

projektközpontúvá válik. A projektre orientált szervezeti struktúrában a projektmegvaló-

sítás tevékenységeit különálló egység irányítja a projektmenedzser vezetésével. Ez a

szervezet magába olvasztja a számára fontos funkcionális tevékenységeket A projekt tel-

Vállalatvezetı

Fejlesztés Termelés Beszerzés Személyügy Pénzügy Projektcsoport

Alaptevékenységek

Projektvezetı 1

Projektvezetı 2

53

jesítésével összefüggı lényegi döntéseket a projektmenedzser hozza meg, aki a vállalat

felsıszintő vezetıjének irányításával látja el feladatát. A projektmenedzser szerepköre a

projektre orientált struktúrában egyértelmően szervezı és döntéshozó jellegővé válik. A

többi szervezeti formától eltérıen, ebben a projektteamek nem oszlanak fel, inkább meg-

maradnak olyan egységnek, amelyek készen állnak a következı feladat megoldására.

Ez a szervezeti forma a funkcionális és mátrix szervezethez képest számos elıny-

nyel rendelkezik. Erıssége mindenekelıtt abban nyilvánul meg, hogy a feladat elvégzé-

séhez egyetlen egységbe integrálja a szükséges kapacitásokat és így erıforrásait - vezetıi

erıforrásokat, egyéb emberi és tárgyi erıforrásokat - egy adott feladat teljesítésére tudja

összpontosítani. A projektfelelısség és a hatáskör világosan megállapított, a team vagy a

projekt könnyen kezelhetı költségcentrumként. A projektköltségvetés egyértelmően

meghatározható és ellenırizhetı. Fejlett a kommunikáció a felsı vezetés és a projektek

között. A szervezetben erıs a teamtudat és a lojalitás.

Hátránya ugyanakkor, hogy konfliktus esetén a projektérdek háttérbe szoríthat

más, a funkcionális szervezetek által képviselt szakmai érdekeket.

Vállalatvezetı

B Projekt menedzser

Fejlesztés Termelés Pénzügy Logisztika A Projekt menedzser

Projekt tevékenységek Funkcionális tevékenységek

54

8. ÁTTEKINTÉS

Elsı gondolataink között fogalmaztuk meg, hogy „mindenütt célszerő felkészíteni

a szervezetet projektek kezelésére”. Az alábbi ábra fogalmaival az tehát a célunk, hogy az

adott szervezetnél kialakítsuk a projektkultúra szemléletet. Ezt találjuk az ábra közép-

pontjában. Körülötte azok az elemek láthatóak, amik nélkül ez a szemlélet nem képzelhe-

tı el, amik nélkül a projektben való gondolkodás nem lesz a vállalati hétköznapok (szak-

szerőbben fogalmazva a vállalati kultúra) része.

Ezek a szempontok:

• projektmenedzselési kompetencia – projektmenedzselési ismeretek, tapasz-

talatok, alkalmasság a projektmenedzselésnek egyfajta intelligens szer-

számként való használatára, mindez képzéssel, tréninggel elsajátítható

• projektszervezet – a projektmenedzsment és a szervezeti struktúra kapcso-

lata, a humán erıforrás gazdálkodás, a szervezés, vezetés témakörébe tar-

tozó kérdések

• módszertan – a projektek megvalósításának standardizált eljárásrendje, ál-

talában egy külsı szakértı cégtıl vásárolja meg, és specifikáltatja a saját

képére az adott vállalat

• informatikai infrastruktúra – a projekttervezés és megvalósítás informati-

kai (szoftveres) támogatása

Projektkultúra- szemlélet

Projektmen. kompetencia

Projekt- szervezet

Módszertan

Informatikai infrastruktúra

55

Ez az ábra a leltárkészítésre is alkalmas, segítségével elgondolkodhatunk azon,

hogy az eddigi keretek között mivel sikerült foglalkoznunk, és mi az, ami eddig kimaradt

a tárgyalásból.

56

9. PROJEKTMENEDZSMENT MÓDSZERTAN

Léteznek széleskörően elfogadott és alkalmazott projektmenedzsment metodoló-

giák (PMBOK, PRINCE2, Logframe). Rövid áttekintést adunk a profitorientált szerveze-

teknél tipikus PMBOK, PRINCE2 módszer alkalmazásáról. A pályázati projektek esetén

tipikus projekt ciklus menedzsment (PCM) és a Logframe módszer alkalmazásával fog-

lalkozunk részletesebben.

9.1. PRINCE2

A PRINCE a brit kormányzat informatikai részlegeinek projektirányítási ajánlása

(www.prince2.com), de szabadon felhasználható a kormányzaton kívül is.2 Úgy alakítot-

ták ki, hogy kompatibilis legyen a kormányzaton belül használt rendszerfejlesztési mód-

szertanokkal, és elımozdítsa azok használatát a fejlesztés szakmai részében. A szabvá-

nyos módszerek használatának bátorításán keresztül, a PRINCE könnyedén illeszkedik a

kormányzati informatikai szabványokhoz. A PRINCE fıként az SSADM-en alapuló

rendszerfejlesztési projektekhez nyújt irányítási keretet.

Egy projekt több szakaszra bomlik, amelyek vezetıi szempontból különálló egy-

séget alkotnak. Ahogy a projektnek, úgy egy szakasznak is vannak meghatározott termé-

kei és tevékenységei, szervezeti felépítése valamint véges lefutási ideje. A szakasz végét a

benne meghatározott termékek elıállítása jelenti, amennyiben azok kielégítik a megálla-

podás szerinti minıségi feltételeket.

A PRINCE meghatározza a projektnek és szakaszainak szervezeti felépítését, a

projekttervek tartalmát és szerkezetét, valamint ellenırzési pontokat annak biztosítására,

hogy a munkálatok a tervek szerint folynak. E három, valamint a termékek és az azokat

elıállító tevékenységek, foglalják magukba a PRINCE alkotóelemeit.

A PRINCE2 egy eljárásalapú megközelítésben vezeti le a projektet. Az eljárások

meghatározzák azokat a tevékenységeket, amikre szükség van a projekt ideje alatt. Ezen

túlmenıen a módszertan meghatározza azokat a komponenseket, amiket alkalmazni kell a

megfelelı tevékenység során.

2 : Skobrics Tibor: Bevezetés a PRINCE projektirányítási módszertanba, MTA Információtechnológiai Ala-pítvány 1993.

57

A következı ábra azt mutatja, hogy ezek a komponensek hogyan csoportosulnak a

központi eljárásmodell köré. A módszertan eredeti nyelve az angol, mivel a magyar fordí-

tás néhol félreérthetı lehet, az ábra angol nyelvő.

A PRINCE2 komponensek és a központi eljárások viszonya

A PRINCE2 eljárásmodell, ahogy azt a következı ábra mutatja, nyolc jellegzetes

menedzsment eljárásból áll. Ezek összefoglalják a tevékenységeket, a projekt felállításá-

tól, a projektfeladatok menedzselésén és az ellenırzésen keresztül, egészen a projekt lezá-

rásáig.

Minden PRINCE2 módszertannal futtatott projekt esetén ezeket az eljárásokat kell

követni valamilyen formában. Természetesen az a cél, hogy a konkrét esetben sikeresen

alkalmazzuk az eljárásmodellt, hozzá kell, hogy igazítsa az eljárásokat a projekt sajátos-

ságaihoz.

58

9.2. PMBOK

A projektmenedzsment szakma „de facto” szabványára, a PMI (Project

Management Institute – www.pmi.org) által kifejlesztett PMBOK (Project Management

Body of Knowledge). A PMBOK metodológia a következı projekt fázisokat, tevékeny-

ségi területeket és fı tevékenységet definiálja:

59

Process GroupsKnowledge areas

1.1 Develop Project Charter1.2 Preliminary project scope statement

1.3 Develop Project Management Plan

1.4. Direct and manage project execution

1.5 Monitor and control project work1.6 Integrated change control

1.7 Close project

2.1 Scope Planning2.2 Scope Definition2.3 Create WBS

2.4 Scope Verification2.5 Scope control

3.1 Activity definition3.2 Activity sequencing3.3 Activity resource estimating3.4 Activity duration estimating3.5 Schedule development

3.6 Schedule control

4.1 Cost estimating4.2 Cost budgeting

4.3 Cost control

5.1 Quality planning 5.2 Perform quality assurance

5.3 Perform quality control

6.1 Human resource planning 6.2 Acquire project team6.3 Develop project team

6.4 Manage project team

7.1 Communications planning 7.2 Information distribution

7.3 Performance reporting7.4 Manage stakeholders

8.1 Risk Management planning8.2 Risk identification8.3 Qualitative risk analysis8.4 Quantitative risk analysis8.5 Risk response planning

8.6 Risk monitoring and control

9.1 Plan purchases and acquisitions9.2 Plan contracting

9.3 Request seller responses9.4 Select sellers

9.5 Contract administration 9.6 Contract closure

1. Project Integration Management

2. Project Scope Management

3. Project Time Management

4. Project Cost Management

Controlling Closing

9. Project Procurement Management

Initiating Planning Executing

5. Project Quality Management

6. Project Human Resource Management

7. Project Communication Management

8. Project Risk Management

Forrás: PMBOK 2004

60

9.3. Projekt ciklus menedzsment (PCM)

A projekt ciklus menedzsment (PCM) módszert az Európai Bizottság vezette be az

1990-es évek elején, azzal a céllal, hogy a projekttervezés és projektirányítás minıségének

javításával növelje az általa finanszírozott segély-programok eredményességét.

A PCM módszer az OECD Fejlesztés-támogatási Bizottsága által a fejlesztési segély-

programok eredményességére vonatkozóan elvégzett elemzésekbıl fejlıdött ki az 1980-as

évek végén.

A modellben a projektek életciklusának kiindulópontja a helyzetelemzésre, probléma-

analízisre épülı programozás, amelynek része a problémák, korlátok és lehetıségek feltárása

és elemzése, amely alapján kijelölésre kerülnek a stratégiai irányok, prioritások és beavatko-

zási területek.

A programozásra építve lesznek azonosíthatóak az egyes projektek, ezután indul meg

ezek kidolgozása, az operatív projekttervek elkészítése és végrehajtása, valamint a projekt

értékelése. A ciklus tehát egy projekt-ötletbıl indul ki, majd az adott elképzelést egy végre-

hajtható és értékelhetı feladatsorrá fejleszti. A projekt-ciklus olyan szerkezetet, olyan keretet

kínál, amely biztosítja az érdekcsoportok véleményének megismerését és a fontos informáci-

ók folyamatos rendelkezésre állását, így a projekt egészének folyamán, legfıképpen annak

kulcsfontosságú szakaszaiban kellıen megalapozott döntéseket lehet hozni.

61

Forrás: Az Eu pályázatok rendszere és projektmenedzsmentje (2003)

A modell szerint az általános projekt-ciklus hat szakaszból áll: programozás, identifi-

káció, kidolgozás, finanszírozás, végrehajtás és értékelés. Az egyes szakaszok projektenként

eltérı tartalommal bírhatnak, az eljárások különbözıségeinek függvényében. A ciklusnak

három olyan közös jellemzıje van, amely minden projekt esetében azonos:

• minden szakaszra vonatkozóan meghatározza a legfontosabb döntéseket, az in-

formációs követelményeket és a felelısségi köröket,

• szakaszai egymásra épülnek – a következı szakaszhoz csak az elızı szakasz

teljesítése után lehet sikerrel hozzákezdeni,

• az értékelés célja az, hogy a már végrehajtott projektek tapasztalatai beépülje-

nek a jövıbeni programok és projektek tervezésébe.

A projekt-ciklus szakaszainak tartalma az alábbiakban foglalható össze:

A programozási szakasz keretében országos és szektorális szintő elemzésekre kerül

sor, amelyek feltárják egy lehetséges beavatkozási terület problémáit, lehetıségeit és korlátait.

Az elemzés eredményei körvonalazzák hogy melyek azok a területek, amelyek fejlesztési

tevékenységek tárgyát képezhetik. Itt fontos a fejlesztési tevékenységek átfogó céljainak

62

meghatározása és egyeztetése az ágazat prioritásaival. Ezáltal egy olyan megvalósítható, reá-

lis, valós igényeken és lehetıségeken alapuló keretprogram kerül kialakítása, amelyen belül

már ki lehet jelölni, és elı lehet készíteni a konkrét projektet.

A programozási szakasszal az általánosnak tekinthetı projekt ciklus elképzelések fázi-

sai nehezen megfeleltethetıek (még a koncepciós vagy projektkialakítási fázishoz áll a legkö-

zelebb), azokban inkább csak egyes elemei lelhetıek fel, azok is csak csíráikban. Az Európai

Unió támogatási alapjaira benyújtott pályázatok mögött álló projektek elıkészítı szakasza

valójában sokkal tagoltabb, részletesebb, alaposabb, mint az általános, beruházási vagy ter-

mékorientált projektek hasonló fázisa. A pályázati projektek bonyolultabb helyzetben kell,

hogy megfeleljenek, hiszen a piac törvényei mellett a pályázati rendszer feltételeihez is al-

kalmazkodniuk kell. Ez eredményezi azt, hogy ezeknek a projekteknek az elıkészítése na-

gyon körültekintıen, igen távolról (országos és szektoriális elemzések) indul, és csak fokoza-

tosan konkretizálódik a projekt. Az elıkészítı szakasz valójában három részre tagolódik, a

programozásit követi az identifikációs és a kidolgozási szakasz.

Maga a programozás elve fontos eleme az Európai Unió támogatási rendszerének,

alapgondolata az, hogy a komplex fejlesztési programok összhatása sokkal jelentısebb, mint a

külön finanszírozott kisebb akcióké. Ez az egyes pályázatok, illetve az azok mögött álló pro-

jektek nyelvére lefordítva annyit jelent, hogy a sikeres pályázáshoz szükséges az is, hogy az

egyébként jó ötleten alapuló projektet tágabb környezetében is megfelelıen el kell, hogy tud-

juk helyezni, fontos az ágazat gazdasági jellemzıinek ismerete, de a legfontosabb az, hogy a

pályázat megfelelıen illeszkedjen az adott pályázati kiírás, illetve az egész támogatási prog-

ram irányvonalához, céljaihoz. Nem csak a pályázat konkrét eredménye fontos a bírálatnál,

hanem az is, hogy az hogyan segíti a támogatási program sikerét. Ehhez valóban széles körő

elemzés, megfelelı keretprogram kidolgozása szükséges, amely megalapozza a konkrét pro-

jekt elıkészítését.

Az identifikáció során kerül meghatározására a projektötlet. Ide tartozik a tervezett in-

tézkedések kedvezményezett célcsoportjával történı konzultáció, konkrét problémáik elemzé-

se és azok lehetséges kezelési módjainak meghatározása. Ezt követıen döntést lehet hozni a

projektötlet relevanciájáról (mind a kedvezményezett célcsoport, mind a program szempont-

jából), valamint arról, érdemes-e továbbvinni a tervet a kidolgozási szakaszba.

Az identifikációs a programozási szakaszhoz hasonlóan a projektkialakítási fázishoz

tartozna az általánosnak tekinthetı projekt ciklus elképzelések között, azonban ennek a fázis-

nak az elhatárolása a projekt elıkészítés többi elemétıl, illetve a szakasz tevékenységei

mondhatni kizárólag a pályázati projektekre jellemzı. Az identifikációs szakasz lényegét a

63

projekt célcsoportjának partnerként történı bevonása jelenti, az, hogy a projektötlet relevan-

ciájáról, a probléma lehetséges kezelési módjáról a velük való konzultáció alapján döntenek.

A partnerség, a programozáshoz hasonlóan az Európai Unió Strukturális Alapjai mőködésé-

nek alapelvei közé tartozik. A pályázatok szintjén a partnerség horizontális dimenziójáról van

szó, ami az adott fejlesztésben érdekeltek bevonását jelenti, a fejlesztési programok legitimá-

lása, elfogadtatása érdekében. A pályázati projektek elıkészítésének teljes folyamatára jel-

lemzı a partnerség elvének követése, így a következı, a kidolgozási szakaszra is.

A kidolgozási szakaszban a releváns projektötletek alapján operatív projekttervek ké-

szülnek. A projektterv részletes kidolgozásába bevonásra kerül (lehetıleg) az összes érintett

érdekcsoport. Az elkészült projektterv értékelésre kerül a megvalósíthatóság (várhatóan sike-

res lesz-e a projekt?) és fenntarthatóság (képes lesz-e hosszú távon elınyöket biztosítani a

projekt a kedvezményezetteknek?) szempontjából. Az értékelés alapján döntés születik arról,

hogy érdemes-e formális projektjavaslatot készíteni, és finanszírozási forrásokat, pályázatokat

keresni a projekthez.

A kidolgozási szakasz részben az általánosnak tekinthetı projekt ciklus elképzelések

projekt kialakítási, részben pedig terv, illetve szervezési fázisának elemeit tartalmazza. Ez a

fázis adja a pályázati projektek elıkészítésének tulajdonképpeni gerincét, persze az elızı sza-

kaszok megfelelı végigvitele után. A pályázati projekt ezen szakaszának tevékenységei meg-

felelnek az általános projektciklus következı feladatainak: megvalósíthatósági tanulmány

készítése, feladatok azonosítása, célok kitőzése, operatív projektterv elkészítése (idı, költség

és humánerıforrás tervezés). A speciális, csak a pályázati projektekre jellemzı tevékenység

ebben a szakaszban a projekt hatásának hosszú távú fenntarthatóságát vizsgáló értékelés.

A finanszírozási szakasz során a finanszírozó intézmények megvizsgálják a projektja-

vaslatokat, pályázatokat és döntenek a projektek finanszírozásáról. A finanszírozó intézmény

és a kedvezményezett megállapodnak a projekt finanszírozására és végrehajtására vonatkozó-

an, és ezeket a megállapodásokat rögzítik a támogatási szerzıdésben.

Ez a projekt-ciklus szakasz még mindig a projekt kialakítás területe. Speciálisan a pá-

lyázati projektekre jellemzı fázis, hiszen az általánosnak tekinthetı projekteknél a finanszíro-

zás, illetve a költségek tervezésének elfogadása a projekt kialakítás szakaszában történik. A

pályázatok esetében a projekttervek, még meg kell, hogy feleljenek a finanszírozó intézmé-

nyek vizsgálatának is. Ez a fázis, a mellet persze, hogy további nehézséget jelent a pályázó-

nak, nagyobb biztonságot jelent a finanszírozó intézménynek (az európai unió Strukturális

Alapjaira benyújtott pályázatok esetében ez a Kifizetı Hatóság, az Európai Bizottság, és vég-

sı soron a közösségi kassza biztonságát jelenti), és a pályázónak egyaránt, hiszen ezen a pon-

64

ton még kiderülhet, hogy a projekt tervezésébe hiba csúszott. Még mindig jobb, ha egy pályá-

zatot ezen a ponton utasítanak el (és az újragondolt- és tervezett projekttel a következı pályá-

zati kiírásnál ismét lehet próbálkozni), mintha a megvalósítás közben, sok felesleges idı és

energia befektetése után derül ki egy projektrıl, hogy nem mőködik, nem életképes.

A végrehajtási szakaszban történik a projekt beindítása és megvalósítása. A projekt

végrehajtása során szükség lehet szakmai segítségnyújtási-, munkavégzési illetve szállítási

pályázatok kiírására és szerzıdések megkötésére is. A végrehajtás során folyamatos a projekt

monitoringja, azaz a projekt megvalósulásának nyomon követése, és a begyőjtött információk

döntésekben való figyelembe vétele. Ezen belül megkülönböztethetı a pályázó által végzett

(„belsı”) monitoring, amely a szerzıdı partnerek jelentéseinek elemzésén, a projektben

résztvevı munkatársakkal folytatott megbeszéléseken és a projektek helyszíni ellenırzésén

alapszik, valamint az irányító hatóság által vezetett („külsı”) monitoring. Ennek keretében a

projekt irányító hatóság, illetve az általa megbízott közremőködı szervezet a pályázat ked-

vezményezettjeivel és az érintett érdekcsoportokkal konzultálva folyamatosan értékeli, hogy a

tervekhez képest milyen tényleges elırelépéseket sikerült elérni, és ennek alapján megvizsgál-

ják, hogy a projekt megfelelıen halad-e a kitőzött célok megvalósítása felé. Ha szükségessé

válik, nem csak a projekt irányát, de bizonyos célkitőzéseit is módosítani kell, illetve módosí-

tani lehet a projekt kidolgozása óta eltelt idı változásai miatt.

Ez a fázis a szervezési és a végrehajtási, illetve másik megközelítésben a teljesítési

vagy az operációs szakasznak felel meg, és alapvetı feladata mindegyik projektciklus-

elméletben a projekt rendszerének mőködtetése, a projekt céljának megvalósítása. A projekt

helyzetének áttekintése, a monitoring tevékenység, a visszacsatolás ugyancsak általánosan

érvényes mindegyik projektciklus modellre. A pályázati projektek monitoringjára is jellemzı

a korábban már említett partnerség elve, tehát ezeknél a projekteknél az érintett érdekcsopor-

tok ebbe a fontos tevékenységbe is bevonásra kerülnek.

Az idıtervezés szempontjából fontos figyelembe venni a végrehajtási szakasz során

esetleg szükségessé váló szállítási, munkavégzési és egyéb pályázatok kiírásának, elbírálásá-

nak és szerzıdéskötésének lebonyolításához szükséges idıt. Ezek a tevékenységek például az

állami és önkormányzati szervezetek számára kötelezı közbeszerzési eljárás lefolytatása ese-

tén jelentıs idı és humánerıforrás igénnyel lépnek fel a végrehajtás során.

Az értékelési szakaszban a finanszírozó intézmény (a Strukturális Alapok esetében az

Irányító hatóság, illetve a megbízott közremőködı szervezet) a projektgazdával együtt kiérté-

keli, hogy a projekt milyen eredményeket ért el, mik a munka tapasztalatai. Az értékelés során

levont tanulságokat felhasználják a jövıbeni programok és projektek tervezése során.

65

Ez a projekt szakasz csak annyiban tér el az általánosnak tekinthetı projektek hasonló

ciklusaitól, hogy az értékelést a projektgazda a finanszírozó intézménnyel együtt végzi. A

projekt tapasztalatait nem csak a pályázó használhatja fel a következı pályázati projektnél, de

a finanszírozó intézmény is a következı pályázatok elbírálásánál, a nyertes pályázókkal való

együttmőködésben, a vagy például a következı pályázati kiírás elkészítésénél.

A projekt-ciklus elıbbiekben bemutatott sajátos felosztása fontos feltétel a pályázati

projektek hatékony elıkészítéséhez, pontos végrehajtásához, és értékeléséhez.

A legfontosabb az azonosítási (identifikációs) és a kidolgozási szakasz különválasztá-

sa. A projektek elıkészítése olyan társadalmi és politikai összefüggésrendszerben történik,

ahol gyakran egymással ellentétes igényeket és törekvéseket kell összehangolni. Az azonosí-

tási szakasz következetes végigvitele lehetıséget ad arra, hogy meghatározásra kerüljön, va-

jon a projektterv valós igényeken alapszik-e, még mielıtt az elıkészítési folyamat túlságosan

elırehaladna. A kidolgozási szakasz során már sor kerülhet a projekttervek részletes kimunká-

lására, annak a tudatában, hogy az abban szereplı célok a kedvezményezettek valós igényei-

bıl következnek, és a projekt által érintett fıbb érdekcsoportok is azonosulnak azokkal.

9.3.1. Logikai keretmátrix (Logical Framework Approach – logframe)

A logikai keretmátrix (LFA vagy logframe) az Egyesült Államok külhoni segélyekért

felelıs szervezete, a USAID által a hetvenes években kifejlesztett módszertan. Kifejlesztésé-

nek célja az volt, hogy segítségével átláthatóbbá és egyszerőbbé váljon a szervezet fejlesztési

tevékenységeinek tervezése, lebonyolítása, ellenırzése és értékelése. A logframe a projektek

strukturálásának általánosan használt eszközévé vált, és alkalmazását átvette az Európai Unió

is. Az Európai Bizottság az 1990-es évek elején vezette be, mint a projekt ciklus menedzs-

ment (PCM) fontos elemét, hogy javítsa az általa finanszírozott segélyprogramok eredmé-

nyességét.

A logikai keretmátrix a projekt szempontjából legfontosabb kérdésekre megfogalma-

zott válaszokat foglalja össze:

• Miért kerül végrehajtásra a projekt (beavatkozási logika)?

• Mit szeretne elérni a projekt (beavatkozási logika és indikátorok)?

• Hogyan tervezi ezt elérni a projekt (tevékenységek, eszközök)?

• A projekttervezés során milyen külsı tényezıket kell figyelembe venni (felté-

telezések és kockázatok)?

66

• Hol találjuk meg a projekt értékeléséhez szükséges információkat (ellenırzés

forrásai)?

• Milyen eszközökre van szükség a projekt megvalósításához (eszközök)?

• Mekkora a projekt költségvetése (költségek)?

• Milyen elıfeltételezéseket kell teljesíteni a projekt elindításához (elıfeltétele-

zések)?

A logframe mátrix szerkezetileg egy négy oszlopot és négy sort, azaz 16 mezıt tartal-

mazó táblázat (legegyszerőbb formájában). A vertikális logika a projekt tevékenységét, az ok-

okozati összefüggéseket és a fontos feltételezéseket, illetve a projekt-menedzser beavatkozási

körén kívül esı bizonytalansági tényezıket határozza meg. A horizontális logika azáltal, hogy

meghatározza a fıbb mérési mutatókat, valamint a mérések ellenırzéséhez szükséges eszkö-

zöket, a projekt hatásainak, és felhasznált erıforrásainak méréséhez kapcsolódik.

Forrás: Rádics Balázs (2004)

A táblázat négy sora az egymásra épülı célok hierarchiáját jelképezi. A projekt kere-

tében végzett tevékenységekkel bizonyos erıforrások (inputok) felhasználásával, meghatáro-

zott eredményeket (outputok) kívánunk elérni.

67

Az elıfeltételek, amelyek a legalsó sor egyetlen mezıjét adják, azokat a feltételeket tar-

talmazzák, amelyekre a projekt elkezdéséhez feltétlenül szükség van. A projekt elkezdése

feltételezi ezek meglétét, arra a projekt menedzsmentjének nincsen ráhatása, ezért is szerepel

a késıbb bemutatásra kerülı feltételezések oszlopban.

A tevékenységek azok a lépések, cselekvések, akciók, amelyeket az eredmények eléré-

se érdekében meg kell tenni. Ez tulajdonképpen a projektvégrehajtás szintje.

A tevékenységeknek kapcsolódni kell az eredményekhez, vagyis egyértelmően össze

kell kötni a tevékenységet és az annak termékeként létrejövı outputot. Ez a célok elsı szintje.

Az eredmények lehetıvé teszik a projekt közvetlen céljainak megvalósítását. Ez lesz a táblá-

zat második szintje.

A projekt közvetlen célja az, az eredményszinten jelentkezı konkrét cél, amit a projekt

megvalósításával közvetlenül el kívánunk érni. Konkrét cél alatt azt a pozitív következményt

kell érteni, amely az eredmények megvalósítása következtében a projekt kedvezményezettjei

számára, a projekt közvetlen környezetében elıáll. Minden projektnek csak egy konkrét célja

lehet.

Végül a táblázat negyedik, legfelsı sorába azt az átfogó célt, magasabb szintő társa-

dalmi célkitőzést írjuk, amelynek eléréséhez – sok más fejlesztés mellett – a mi projektünk

hatásai is hozzájárulnak hosszú távon. Az átfogó, stratégiai szintő célt a projekt önmagában

nem tudja elérni, eléréséhez szükség van további projektek megvalósítására, illetve külsı fel-

tételek teljesülésére is.

A logikai keretmátrix mind a négy sora négy oszlopra van osztva. Az elsı oszlopba

kell írni az elıbb említett célokat.

A projekt alapjául szolgáló stratégiát, a tevékenységektıl az átfogó célokig vezetı ha-

tásmechanizmust az intervenciós (v. beavatkozási) logikának nevezik. A logframe mátrixban

az intervenciós logikán, annak egyes szintjein keresztül történik meg a projekt leírása – vagyis

ez kerül majd a mátrix elsı oszlopába.

A második oszlopba azok a számszerősített, mérhetı célértékek (indikátorok) kerül-

nek, melyeknek elérése esetén a célt megvalósultnak tekintjük. A tevékenységek sorában eb-

ben az oszlopban nem mutató szerepel, hanem a projekt megvalósításához szükséges emberi

és dologi erıforrások felsorolása, természetesen konkrétan és számszerősítve.

A harmadik oszlopban azt kerül leírásra, hogy a szóban forgó indikátort ki, mikor és

hogyan ellenırzi, azaz, hogy honnan lehet megtudni az indikátor értékét. Ebben az oszlopban

a mátrix felsı három sorában a különbözı szintő célok illetve az eredmények elérését igazoló

információforrások szerepelnek. Ha szükséges, a teljesítmény igazolásához szükséges mód-

68

szerek is itt kerülnek leírásra. A tevékenységek sorában (legalsó sor) az emberi és tárgyi erı-

források költségei kerülnek feltüntetésre.

Végül a negyedik oszlopba azok a külsı tényezık (feltevések és kockázatok) kerülnek,

amelyekre a projektmenedzsmentnek nincsen ráhatása, éppen ezért az elıfeltevések gondos

mérlegelése a reális tervezés egyik legfıbb garanciája. Fontosságuk abból adódik, hogy mivel

teljesülésük (vagy kockázatok esetén éppen az elkerülésük) szükséges ahhoz, hogy a követke-

zı szint (sor) elsı oszlopában leírtak megvalósulhassanak, mindenképpen tisztában kell lennie

fennállásuk, illetve bekövetkezésük következményeivel. A legfelsı sor utolsó mezıje érte-

lemszerően üres marad. A feltevések egyesével, gondos mérlegelésre szorulnak:

1. Tényleg a projektmenedzsment hatókörén kívül álló tényezıkrıl van-e szó?

2. Valóban nem lehetséges a teljesülésüket, illetve az elkerülésüket új tevékenysé-

gekkel elısegíteni, illetve elkerülni?

3. Ha az elızı kérdésre nem kielégítı a válasz, akkor nem válik-e túl kockázatossá a

projekt?

A logikai keretmátrix kidolgozása:

A logframe módszerben az alternatívák elemzése, a megfelelı stratégia és eszközrend-

szer kiválasztása után következik a projekt részletes megtervezésének szakasza, azaz a logikai

keretmátrix kitöltése.

A keretmátrix kitöltésénél több fontos elvet is figyelembe kell venni. Egyrészt lénye-

ges, hogy a logikai keretmátrix egyes mezıibe mérhetı és számon kérhetı dolgok kerüljenek.

A másik fontos elv az, hogy minden projekttervnél törekedni kell a tömörségre. Minden ke-

retmátrixnak (még a legbonyolultabb projektek esetében is) rá kell férnie egy A/4-es oldalra.

Ez a terjedelmi korlát a projekt írója számára, bár egyes komplex projekteknél nehézséget is

jelenthet, mégis elsı sorban segítségként jelentkezik, mivel rákényszeríti arra, hogy a lényeg-

re koncentráljon.

A projekt sikerességét tekintve pedig többek között azért lényeges a tömörség, mert a

pályázat bírálóinak ideje véges, az esetlegesen több száz pályázat átolvasása közben a terjen-

gısen megfogalmazott pályázati anyagokat valószínőleg nem fogadnák kitörı lelkesedéssel.

Az idıhiány mellett persze sokkal objektívabb érvek is szólnak a logikai keretmátrix mellett.

A bírálókat egyértelmően és eltéveszthetetlenül rávezeti a pályázati projekt logikai hibáira és

következetlenségeire. E mellett az is fontos és jellemzı információt ad egy pályázóról, hogy

képes-e céljait és elérésük tervezett módját tömören megfogalmazni. Ha ezt nem tudja elvé-

69

gezni, akkor feltételezhetı, hogy nincs is teljesen tisztában a céljaival, a pályázati rendszer

követelményeivel, valamint a megvalósítás mikéntjével, ezért a támogatás megfelelı felhasz-

nálására is képtelen lenne.

Intervenciós logika:

Intervenciós logikának a projekt alapjául szolgáló stratégiát, a tevékenységektıl az át-

fogó célokig vezetı hatásmechanizmust nevezik. A logframe mátrixban az intervenciós logi-

kán, annak egyes szintjein keresztül történik meg a projekt leírása – vagyis ez kerül majd a

mátrix elsı oszlopába. A mátrix kitöltését ezzel az oszloppal kell kezdeni, majd tovább, a pro-

jekt logikájának sorrendjében haladva.

A logikai keret mátrix felépítése

Forrás: Az Eu pályázatok rendszere és projektmenedzsmentje (2003)

Elsıként szükség van bizonyos inputokra (erıforrásokra), melyeket pénzben, felszere-

lésben és humán erıforrásban is ki lehet fejezni. Az outputokat (várt eredmények) a projekt-

70

menedzserek számára kitőzött feladatként kell megfogalmazni, melyet az inputok rendelke-

zésre állása esetén mindenképpen garantálniuk kell. Az outputokat meg kell számozni, és

egyértelmően a különbözı részcélokhoz kell rendelni. A közvetlen célok mezıbe azok a pozi-

tív következmények kerülnek, melyek a projekt sikeres végrehajtása esetén a projekt kedvez-

ményezettjei számára elıállnak.

A kitőzött eredmények (outputok) összessége elvben megvalósítja a kitőzött célt, cé-

lokat. Ez az összefüggés azonban – ellentétben az inputok és outputok kapcsolatával – csak

bizonyos külsı, a projektmenedzserek által nem ellenırizhetı feltételek teljesülése és bizo-

nyos kockázatok elkerülése esetén lesz igaz. Ezek a külsı feltételek szerepelnek a táblázat

negyedik oszlopában (Assumption and Riske).

Az átfogó, vagy tágabb cél (wider objective) olyan hosszú távú célkitőzés, melynek

eléréséhez a projekt hozzájárul. Egy projektben egyetlen tágabb célt kell megfogalmazni.

Az átfogó cél és a közvetlen célok közötti összefüggés ahhoz a kapcsolathoz hasonlít

(bár még annál is lazább), amely az eredmények (outputok) és a közvetlen célok között is

fennáll. Az átfogó cél eléréséhez szükséges erıforrások ugyanis a legtöbbször jócskán megha-

ladják a projekt kereteit. Ezért megvalósításához nagyszámú külsı tényezınek is teljesülnie

kell, illetve sok más projektet is sikeresen végre kell hajtani.

Az átfogó (vagy tágabb) cél kitőzése ennek ellenére igen fontos, mert a pályázati pro-

jekt létjogosultságáról, indokoltságáról a donort is meg kell gyızni. Amint azt már korábban

említettem (programozás elve), az EU a támogatások folyósítására csak akkor hajlandó, ha

annak hasznát a tágabb közösség, a magyar adófizetık – és végsı soron az Unió lakossága –

is élvezik. Az átfogó cél megfelelı megfogalmazásával azt bizonyíja a pályázati projekt írója,

hogy tisztában van a megpályázott közösségi forrás, az adott támogatási program irányvona-

lával, céljaival, azokhoz illeszkedı projekttel pályázik.

Összefoglalva tehát a logframe mátrix elkészítésének menete (azaz a projekt tervezé-

sének logikája) a következı: elıször az elsı oszlopot kell elkészíteni, fentrıl lefelé haladva,

így elkészül a stratégiából levezetve a projekt célrendszere, és meghatározásra kerülnek a te-

vékenységek. Ezután a feltételezések meghatározására (a negyedik oszlopban) kerül sor, lent-

rıl felfelé haladva, kezdve az elıfeltételezésekkel. Végül az alsó sorból kiindulva vízszintesen

haladva kell kitölteni a hiányzó mezıket, elıször meghatározva az indikátorokat, majd azok

forrását.

71

A logframe mátrix elkészítésének menete

Forrás: Az Eu pályázatok rendszere és projektmenedzsmentje (2003)

72

IRODALOMJEGYZÉK

Aggteleky Miklós – Bajna Miklós (1994): Projekttervezés - Projektmenedzsment,

Közlekedési Dokumentációs Rt., Budapest

Bernard Abrignani, Rui Gomes, Dirk de Vilder (2003): Projektmenedzsment T-kit,

Mobilitás Nemzetközi Igazgatósága, Budapest

Bögel Gy. - F. Ható K. - Keresztes J. – Salamonné – Zárda S. (2001): Szervezési és

vezetési ismeretek, SZÁMALK Kiadó, Budapest

Chikán Attila-Demeter Krisztina (1999): Az értékteremtı folyamatok menedzsmentje,

Aula Kiadó Kft., Budapest

Az EU pályázatok rendszere és projektmenedzsmentje (2004), Nemzeti Fejlesztési

Hivatal Strukturális és Kohéziós Alapok Képzéskoordinációs Központ (SAKK), Bu-

dapest

Görög Mihály (1996): Bevezetés a projektmenedzsmentbe, Aula Kiadó, Budapest

Görög Mihály (1999): Általános projektmenedzsment, Aula Kiadó, Budapest

Görög Mihály – Ternyik László (2001): Informatikai projektek vezetése, Kossuth Ki-

adó, Budapest

Görög Mihály (2003): A projektvezetés mestersége a projektsiker tükrében, Vezetés-

tudomány 2003/2, Budapest (39-47)

Hobbs, Peter (2000): Projektmenedzsment, Scolar Kiadó, Budapest

Kotter, John P. (1999): A változások irányítása, Kossuth Könyvkiadó Rt., Budapest

Litke, Hans-D (1995): Projectmanagement, Methoden, Techniken, Verhaltensweisen,

Wien

Lock, Dennis (1998): Projektmenedzsment, Panem Könyvkiadó Kft., Budapest,

Lockyer, Keith – Gordon, James (2000): Projektmenedzsment és hálós tervezési tech-

nikák, Kossuth Könyvkiadó Rt, Budapest

Microsoft Project 2002, Szak kiadó, Budapest 2003

Moss, Geoffrey (1999): A vezetıi eredményesség abc–je, Bagolyvár Kiadó Kft., Bu-

dapest

Papp Ottó (1995): Projekt menedzsment, Budapesti Mőszaki Egyetem, Budapest

Papp Ottó (2002): Projektmenedzsment a gyakorlatban, LSI, Budapest

Rapcsák János, Heil Péter (2002): Phare - kézikönyv Osiris Kiadó, Budapest

73

Rádics Balázs (2004): Az EU pályázatok rendszere és projektmenedzsmentje (oktatási

anyag), BR Grant Consulting Kft., Budapest

Skobrics Tibor: Bevezetés a PRINCE projektirányítási módszertanba, MTA Informá-

ciótechnológiai Alapítvány 1993.

Szekeres Ádám (2006): Európai Uniós pályázati projektek tervezésének kérdései,

NyME KtK diplomadolgozat, Sopron

Szőcs István (2000): Projektmenedzsment a vezetés szolgálatában, Vezetéstudomány

2000/1, Budapest, (56-62)

Tátrai Tibor (1999): MS Project 98, ComputerBooks, Budapest

The Open University: Projektmenedzsment, Mőegyetemi Távoktatási Központ, Buda-

pest, 1997.

Útmutató a projekt elıkészítı dokumentumok kialakításához (1996), Miniszterelnöki

Hivatal, Informatikai Koordinációs Iroda, Budapest

Weiss, J. W. and Wysocki, R. (1994): 5-Phase Project Management: A practical

planning and implementation guide, Addison- Wesley, Reading, Mass.