projmen_jegyzet_3 - NYME Természettudományi Kar - Nyugat ...

Nagy Zsolt
Projektmenedzsment
jegyzet
Nyugat-magyarországi Egyetem
Közgazdaságtudományi Kar
Sopron, 2008.

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
2

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éghezviendı
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égsorozata,
de az Európai Unió támogatási alapjainak forrásaira benyújtott pályázatok is projekteken
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 gazdasá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?
3

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
Hogyan?
Stratégiai akciók és programok
megfogalmazása
Hova akarunk eljutni?
Célmeghatározás
érdekcsoportok elvárásai
küldetés és jövıkép
célok
A stratégiai gondolkodásnak egy adott jelenlegi állapotból egy kitőzött célállapotba
való eljutás áll a középpontjában, a stratégia a két pont között „légvonalban” gondolkodik.
A stratégia megfogalmazása után a konkrétabb szint a projektek szintje, a projektek
jelentik a két pont közötti konkrét utat, amit a valóságban be kell, hogy járjon a vállalat.
Egy-egy projekt a két szélsı pont közötti, konkrét kezdı-, és végponttal kitőzött szakaszt
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.
4

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ó feladatok,
amire folyamatokat fog definiálni, a standard kiváló minıségő folyamat-végrehajtásra
minıségirányítási rendszert mőködtet, ilyen például tipikusan
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 projekteket
fog felállítani, ilyen például a terméktervezés.
Vállalti mőködés: hagyományos vállalati rendszer
vagy projekt keretében
Tevékenységek
Tervezés
Végrehajtás
Ellenırzés
Standard
feladatok
Mőködés (feladatmegoldás) a
meglévı vállalati rendszer
keretében
Testre szabott,
nem standard
feladat
Feladatmegoldás
projektek keretében
5

A két fajta tipikus tevékenységcsoport közötti alapvetı különbséget a menedzsmentnek
fel kell ismernie, testre szabott, nem standard feladatok megvalósítására projektet
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 valamilyen
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épviselı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 érdekviszonyok
között a lehetı legjobb – nyilvánvalóan kompromisszumos – megoldást megtalálják.
6

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), valamint
teljesítésének költségei (erıforrások) meghatározottak, és egy definiált cél (eredmé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őjtö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 kapcsolatos
tevékenységek, amelyek elsı ízben valósítanak meg, ill. meglévı folyamatok
átalakítására irányulnak (Robert J Graham, 1985)
7

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, akkor
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öltsé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)
Az idı/költség/minıség háromszöge
Minıség
Költség
Idı
8

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.
Vállalatvezetı
Projektszponzor
Megrendelı
Projektmenedzser
A projekten dolgozó
csoport (team)
(projektkoordinátor)
A projekttel kapcsolatban a vállalatvezetı általában nem tartja magánál a felelıssé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
9

• 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áérté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ársak,
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állalat
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 Projektkoordiná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
10

Fenti projektdefiníciókból következik a projektek az élılényekhez – melyek megszületnek,
kiteljesednek, majd elhalnak – hasonló tárgyalása, ebbıl az analógiából származtatható
a projekt életciklusa. Valamennyi projektre egyetemlegesen érvényes életciklus-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 projektalapító
okiratban megnevezik a projektet, a projekt célját, hatókörét és a projektmenedzsert.
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,
11

• 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 szervezé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ıkkel
• 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ó feladat.
Átadási teendık:
• bevonás,
• egyeztetés,
12

• elvárások tisztázása.
A Görög Mihály által leírt modellben a projekt „élete” körfolyamatként van szemléltetve.
A többi elmélettel ellentétben ez a forma a tevékenységfolyamat bemutatása mellett
alkalmas arra is, hogy a stratégiai meghatározottságot, valamint a megvalósítási folyamat
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 sugalljá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)
13

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 javaslat.
El kell dönteni, hogy közülük bármelyiket is érdemes-e továbbgondolni. Tehát szüksé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 minden
érdemesnek tőnı javaslat megvalósíthatósági tanulmányának elkészítésére. A tanulmá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 specifiká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 projekttervezés
szakaszában kerül sor.
A szcenárió egy, a megfogalmazott célkitőzések eléréséhez szükséges rendszernek,
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ı elgondolá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ítható
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:
14

• 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 rangsorolá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, rangsorolá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ásokat
az a logika hozza felszínre, hogy a potenciális vevık olyan termékek vásárlását részesítik
elınyben, melyek a versenytárs termékeknél kevésbé ártalmasak a környezetre. Ökoló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ényezı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 biztosí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.
15

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)
16

4. A PROJEKT SZERKEZETE
Mit?
Üzleti célok
Megbízó céljai
Ki?
Projektcélok
Projektjavaslat
Projekt
meghatározás
Szervezet
WBS
Feladatok definiálása
Feladatok
Kompetenciák és felelısségek mátrixa
munkatrs1 munkatrs2 munkatrs3 ……
F1
F2
F3
F4
…
Mivel?
Hogyan?
Hálóterv
Az erıforrás
igények
ütemezése
Mikor?
Gantt-diagram
F1
F2
F3
F4
Mennyibıl?
Erıforrástervezés
Költségkalkuláció
cash flowszámítások
17

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élysé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 projekt
célja
1.
2.
3. 4.
1.1.
1.2.
1.1.1.
1.1.2.
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
18

értékelhetı. A feladatok alábontásban megjelenı logikát jelöléstechnikailag kódszámokkal
tudjuk megmutatni.
A feladatok alábontási rendszere nem foglal állást a feladatok sorrendjét, kivitelezé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.
Új iroda létesítése
1. A helyiségek átalakítása
2. Az iroda bebútorozása
3. Irodatechnika telepítése
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
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:
19

A PROJEKT KIVITELEZÉSÉBEN RÉSZT-
A PROJEKT FELADATAI
VEVİ MUNKATÁRSAK
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 hajtanak
végre. A projektmenedzser koordinálja, és befolyásolja a projekt érintettjeit. Végzetes
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 megfelelı
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 menedzsment
- megrendelı – projektcsoport – projektmenedzser
• Milyen információkra van szüksége? – jóváhagyások – változások - koordiná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.
20

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 Franciaorszá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 haditengeré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ı, sztochasztikus
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 esemé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égjelölés
nem lenne egyértelmő.
21

i
j
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ékenysé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átszattevé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 megelı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
22

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ıtartamot
zárójelek között szerepeltessük a tevékenység azonosítója mögött. Példánkban látszattevékenységgel
mutatjuk meg a D ill. F tevékenységek megelızı, követı logikai kapcsolatait.
A (1) D (2) E (5) F (1)
1 4
5
B (2)
0 2
H (2)
6 7
C (4) G (2)
3
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 legkorábbi
idıpontjához a tevékenységek végrehajtásához szükséges idıtartamot. Definíciószerő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.
2
4
9
A (1) D (2) E (5) F (1)
1 4
5
0
B (2)
0 2
10
H (2)
6 7
2 12
4
C (4) G (2)
3
23

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 kiindulva,
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 vizsgá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 esemé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.
24

2
4
9
A (1) D (2) E (5) F (1)
1 4
5
2
4
9
0
B (2)
0 2
0
2
2
6
10
10
H (2)
7
12
12
4
C (4) G (2)
3
8
4. A kritikus út meghatározása
A fentiek értelmében minden esemény bekövetkezésének meghatároztuk a legkorá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 szakaszban
lesz igazán fontos. Ha viszont az esemény bekövetkezésének legkorábbi és legkésıbbi
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 legkorá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önteni
tudjunk arról, hogy melyik tevékenységet lehet elhalasztani, és melyiket nem. Példánkban
a kritikus út: B – D – E – F – H. Pl. a C tevékenység 4 napos tartalékidıvel rendelkezik
(a C tevékenységet „büntetlenül” késıbb indíthatjuk, vagy csúszhatunk a végrehajtá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ékenysé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.
25

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 fogalmat
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érfö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 kapcsolat
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ésbefejezé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ésleltetési
idı nélküli kapcsolattal (a megelızı tevékenység befejezése után rögtön elkezdı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:
26

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.
1
2
5
1
2
A
D
E
F
H
2
B
4
2
C
G
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.
27

0 1 1
2 2 4
4 5 9
9 1 10
10 2 12
A
D
E
F
H
0 2 2
B
0 4 4
4 2 6
C
G
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
2 2 4
4 5 9
9 1 10
10 2 12
A
D
E
F
H
1 2
2 4
4 9
9 10
10 12
0 2 2
B
0 2
0 4 4
4 2 6
C
G
4 8
8 10
28

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ékidejét
határozzuk meg úgy, hogy a csomópontokban egymás felett lévı kezdési vagy befejezé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.
0 1 1
2 2 4
4 5 9
9 1 10
10 2 12
A
D
E
F
H
1 1 2
2 0 4
4 0 9
9 0 10
10 0 12
0 2 2
B
0 0 2
0 4 4
4 2 6
C
G
4 4 8
8 4 10
Ö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 nyelven
is hozzáférhetı. Sok tevékenységet tartalmazó, összetett projektek tervezését mindenké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.
29

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 foglalkozni.
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égrehajtá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
30

4.5. Erıforrás-tervezés
Az elızı fejezetekben nem foglalkoztunk az erıforrás kérdésével. A projekt tervezé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 rendelkezésünkre
állnak. Ez – leszámítva az ókori uralkodók gigantikus építkezéseit – a valóságban
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 folyamatosan
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 mennyisé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 dolgozunk.
A koordinátatengelyek felrajzolása után tevékenységenként ábrázoljuk az erıforrá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ú, amekkora
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.
31

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 maximá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ı hatá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 kezdjük
el a projekt kezdetekor, egy napot csúsztassuk, a projekt elsı napján az A és a B tevé-
32

kenységekkel induljunk. C tevékenység maga mögött egy nappal hátratolja G tevékenységet,
ezt is megtehetjük, mert G tevékenység 4 napos tartalékidıvel rendelkezik. A projekt
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áltatá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áskorlá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 menedzseri
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 pontossá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álattal
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üggetlenek
a tevékenység idıtartamától, és az erıforrások által végzett munkától. Ilyen költ-
33

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ıforrások
esetén Ft/m 2 , 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 nehé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 ütemterv,
stb.)
• emberi erıforrással kapcsolatos kockázatok (kompetenciahiány, motiválatlanság,
együttmőködési készség hiánya, érdektelenség stb.)
34

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ázatok
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 teendı
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 terveknek
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égminıség
hármas paraméterét.
Kockázatelemzés során azokat a kockázati tényezıket kell számszerősíteni, amelyek
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 figyelemmel
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.
35

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ő
1 2 3 4 5 6 7 8 9 10
Milyen súlyos következményekkel jár?
Jelentéktelen Súlyos Nagyon súlyos
1 2 3 4 5 6 7 8 9 10
Forrás: Peter Hobbs (2000)
A kockázat felbecslésekor figyelembe kell venni, hogy mennyire valószínő, és milyen
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 valószínő
(4), de súlyos következményekkel jár annak bekövetkezése (9). A két adat összeszorzá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.
36

A kockázatokat a vállalat szemszögébıl nézve csoportosítani lehet emberi, technikai,
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 kapcsolatban
é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ökkenté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).
37

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
38

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 munkatá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ı megoldá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 csoporttagok
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élezett
helyzetekben gyakran döntésképtelenné válik, esetleg könnyen befolyásolható;
• megvalósító – fegyelmezett és hatékony, mások ötleteit kivitelezi, gyakorlatias,
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észleteknél.
Optimális esetben a projektteam tagjai harmonikusan dolgoznak együtt a kockázatok
kezelésén, a feladatok végrehajtásán, elkötelezettek a projekt világosan megfogalmazott
céljai mellett. Ez a megállapítás korántsem olyan magától értetıdı. A projektmenedzsernek
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
39

♦ 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 teammel,
♦ 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éningek.
A résztvevık közös tevékenységeket végeznek sokszor játékos formában annak érdeké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 projektszponzort
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 helyzeté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.
40

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.
Elıkészítés
Következı
megbeszélés
A megbeszélés kivitelezése
Leírás és kivitelezés
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ötelezett
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
41

♦ 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 projektmenedzser
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ákra
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 keletkeznek,
á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áltoztatá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 sikeressé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.
42

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 megfelelı
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 hatá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 projektekné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áridı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:
43

• 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ügyelet
és a megvalósítás között.
TERVEZÉS
Elıirányzott
értékek
IRÁNYÍTÁS
Elıirányzott
értékek
Döntések
Intézkedések
ELLENİRZÉS
Tényleges
értékek
MEGVALÓSÍTÁS
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örténjen.
A következı nézıpontokat kell figyelembe venni a vezérlésnél:
44

• 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öltségek
vizsgálatánál,
• megbeszéléseken keresztül folyamatosan informálódnia kell a projekt menetérıl.
45

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 projekt
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 megrendelı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 nevezzü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 teendı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, kezdemé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ı legkorá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.
46

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 megfeledkeznek
a hallottakról. A szükséges információkat célszerő többször az érintettek tudomá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övetkezı,
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 összegyő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ő alaposan
megvizsgálni, hogy a következı projekt alkalmával hasonló hibák ne következzenek
be.
Az emberek szeretik tudni, hogyan vélekednek teljesítményükrıl, különösen akkor,
ha a projektbe rengeteg energiát fektettek. Az értékelés stádiumában minden munkatá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 áttekinté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-
47

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 kevesebbe?
• 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
48

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 projekt
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ó javaslatokkal.
49

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árgyaljuk.
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 szervezetek
á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 hogyan
lesznek egyenrangúak, végül a projektérdek háttérbe szoríthatja a funkcionális szervezetek
á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 kapcsolatos
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.
50

Vállalatvezetı
Projektvezetı
Fejlesztés Termelés Beszerzés Személyügy Pénzügy Logisztika
Alaptevékenységek
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 hozhatnak.
Ezeket a döntéseket a vállalat vezetıjének kell meghoznia. A projektmenedzser ebben
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ézsé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 életben
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árisfunkcionális
struktúráját átalakítani. Így jönnek létre a mátrixszervezetek.. A mátrixszervezetben
szükség lesz egy projektcsoport (projektvezetıi pool) felállítására. Tagjai függelmileg
is ide tartoznak, mind szakmailag, mind projektvezetést tekintve képzett embe-
51

ek. 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.
Vállalatvezetı
Fejlesztés Termelés Beszerzés Személyügy Pénzügy Projektcsoport
Alaptevékenységek
Projektvezetı 1
Projektvezetı 2
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 szakembereket
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 kapnak
utasítást. Éppen ezért a mátrixszervezet kulcskérdése a funkcionális vezetık és a projektmenedzser
közötti kapcsolat, a hatáskör és felelısség megosztása. Fontos a projektmenedzsereket
és a funkcionális vezetıket ugyanúgy motiváló érdekeltségi rendszer kidolgozá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 feleslegessé
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-
52

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 megmaradnak
olyan egységnek, amelyek készen állnak a következı feladat megoldására.
Vállalatvezetı
A Projekt
menedzser
B Projekt
menedzser
Fejlesztés Termelés Pénzügy Logisztika
Projekt tevékenységek
Funkcionális tevékenységek
Ez a szervezeti forma a funkcionális és mátrix szervezethez képest számos elınynyel
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.
53

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éppontjában.
Körülötte azok az elemek láthatóak, amik nélkül ez a szemlélet nem képzelhetı
el, amik nélkül a projektben való gondolkodás nem lesz a vállalati hétköznapok (szakszerőbben
fogalmazva a vállalati kultúra) része.
Ezek a szempontok:
• projektmenedzselési kompetencia – projektmenedzselési ismeretek, tapasztalatok,
alkalmasság a projektmenedzselésnek egyfajta intelligens szerszámként
való használatára, mindez képzéssel, tréninggel elsajátítható
• projektszervezet – a projektmenedzsment és a szervezeti struktúra kapcsolata,
a humán erıforrás gazdálkodás, a szervezés, vezetés témakörébe tartozó
kérdések
• módszertan – a projektek megvalósításának standardizált eljárásrendje, általá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 informatikai
(szoftveres) támogatása
Projektmen.
kompetencia
Informatikai
infrastruktúra
Projektkultúraszemlélet
Projektszervezet
Módszertan
54

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

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 szervezetekné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 foglalkozunk
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ították
ki, hogy kompatibilis legyen a kormányzaton belül használt rendszerfejlesztési módszertanokkal,
é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ó egysé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állapodá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 Alapítvány
1993.
56

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átosságaihoz.
57

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ékenységi
területeket és fı tevékenységet definiálja:
58

Knowledge areas
Process Groups
Initiating Planning Executing
Controlling
Closing
1. Project Integration
Management
1.1 Develop Project Charter
1.2 Preliminary project scope
statement
1.3 Develop Project Management
Plan
1.4. Direct and manage
project execution
1.5 Monitor and control project
work
1.6 Integrated change control
1.7 Close project
2. Project Scope Management
2.1 Scope Planning
2.2 Scope Definition
2.3 Create WBS
2.4 Scope Verification
2.5 Scope control
3. Project Time Management
3.1 Activity definition
3.2 Activity sequencing
3.3 Activity resource estimating
3.4 Activity duration estimating
3.5 Schedule development
3.6 Schedule control
4. Project Cost Management
4.1 Cost estimating
4.2 Cost budgeting
4.3 Cost control
5. Project Quality Management
5.1 Quality planning 5.2 Perform quality
assurance
5.3 Perform quality control
6. Project Human Resource
Management
6.1 Human resource planning 6.2 Acquire project team
6.3 Develop project team
6.4 Manage project team
7. Project Communication
Management
8. Project Risk Management
9. Project Procurement
Management
7.1 Communications planning 7.2 Information
distribution
8.1 Risk Management planning
8.2 Risk identification
8.3 Qualitative risk analysis
8.4 Quantitative risk analysis
8.5 Risk response planning
9.1 Plan purchases and
acquisitions
9.2 Plan contracting
9.3 Request seller
responses
9.4 Select sellers
7.3 Performance reporting
7.4 Manage stakeholders
8.6 Risk monitoring and control
9.5 Contract administration 9.6 Contract closure
Forrás: PMBOK 2004
59

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élyprogramok
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émaanalí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 beavatkozá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égrehajtható
é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.
60

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, identifiká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 informá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üljenek
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
61

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ázisai
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 termé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 alkalmazkodniuk
kell. Ez eredményezi azt, hogy ezeknek a projekteknek az elıkészítése nagyon
körültekintıen, igen távolról (országos és szektoriális elemzések) indul, és csak fokozatosan
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ó projektek
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 tudjuk
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 program
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 projekt
elıkészítését.
Az identifikáció során kerül meghatározására a projektötlet. Ide tartozik a tervezett inté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 szempontjá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ázisnak
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
62

projekt célcsoportjának partnerként történı bevonása jelenti, az, hogy a projektötlet relevanciá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 jellemzı
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 sikeres
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ı szakaszok
megfelelı végigvitele után. A pályázati projekt ezen szakaszának tevékenységei megfelelnek
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 projektjavaslatokat,
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írozá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égsı
soron a közösségi kassza biztonságát jelenti), és a pályázónak egyaránt, hiszen ezen a pon-
63

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 kedvezmé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áljá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 projektcikluselmé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 érdekcsoportok
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 eseté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.
64

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, vajon
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ényeibı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 menedzsment
(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 megfogalmazott
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)?
65

• 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ételezések)?
A logframe mátrix szerkezetileg egy négy oszlopot és négy sort, azaz 16 mezıt tartalmazó
táblázat (legegyszerőbb formájában). A vertikális logika a projekt tevékenységét, az okokozati
ö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 keretében
végzett tevékenységekkel bizonyos erıforrások (inputok) felhasználásával, meghatározott
eredményeket (outputok) kívánunk elérni.
66

Az elıfeltételek, amelyek a legalsó sor egyetlen mezıjét adják, azokat a feltételeket tartalmazzá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ársadalmi
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ı felté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ı hatá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ülnek,
melyeknek elérése esetén a célt megvalósultnak tekintjük. A tevékenységek sorában ebben
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-
67

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övetkezı
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 értelemszerő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özrendszer
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ényeges,
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 keretmá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ényegre
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 terjengı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é-
68

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ı felhaszná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 átfogó
célokig vezetı hatásmechanizmust 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átrix kitöltését ezzel az oszloppal kell kezdeni, majd tovább, a projekt
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, felszerelésben
és humán erıforrásban is ki lehet fejezni. Az outputokat (várt eredmények) a projekt-
69

menedzserek számára kitőzött feladatként kell megfogalmazni, melyet az inputok rendelkezé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 pozitív
következmények kerülnek, melyek a projekt sikeres végrehajtása esetén a projekt kedvezmé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 bizonyos
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 meghaladjá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 projekt
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ányvonalá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 tevékenységek.
Ezután a feltételezések meghatározására (a negyedik oszlopban) kerül sor, lentrı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.
70

A logframe mátrix elkészítésének menete
Forrás: Az Eu pályázatok rendszere és projektmenedzsmentje (2003)
71

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), Budapest
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 Kiadó,
Budapest
Görög Mihály (2003): A projektvezetés mestersége a projektsiker tükrében, Vezetéstudomá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 techniká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., Budapest
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
72

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, Budapest,
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.
73