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. 2.2.
3.
MEGVALÓSÍTHATÓSÁG ....................................................................................14 3.1. 3.2. 3.3.
4.
A PROJEKTEK SZEREPLİI.......................................................................................9 A PROJEKT-ÉLETCIKLUS MODELL ........................................................................10 MEGVALÓSÍTHATÓSÁGI TANULMÁNY .................................................................14 MŐSZAKI MEGVALÓSÍTHATÓSÁG ........................................................................14 PÉNZÜGYI MEGVALÓSÍTHATÓSÁG .......................................................................15
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. 5.2. 5.3.
6.
A PROJEKT ÁTADÁSA ÉS ÉRTÉKELÉSE.......................................................46 6.1. 6.2.
7.
A PROJEKTTEAM MEGBESZÉLÉSE A KIVITELEZÉS SORÁN .....................................39 VÁLTOZTATÁSOK A PROJEKTEN ..........................................................................42 PROJEKTKONTROLLING .......................................................................................43 A PROJEKT ÁTADÁSA ..........................................................................................46 A PROJEKT ÉRTÉKELÉSE ......................................................................................47
PROJEKTMENEDZSMENT ÉS SZERVEZETI STRUKTÚRA ......................50 7.1. 7.2. 7.3.
PROJEKTMEGVALÓSÍTÁS LINEÁRIS-FUNKCIONÁLIS STRUKTÚRÁBAN ..................50 PROJEKTMEGVALÓSÍTÁS MÁTRIX STRUKTÚRÁBAN .............................................51 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?
Hova akarunk eljutni?
Helyzetelemzés, pozíció-
Célmeghatározás
analízis
érdekcsoportok elvárásai
belsı adottságok:
küldetés és jövıkép
erısségek, gyengeségek külsı környezeti tényezık:
célok
lehetıségek, veszélyek Hogyan? Stratégiai akciók és programok megfogalmazása
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
Standard feladatok Mőködés (feladatmegoldás) a meglévı vállalati rendszer keretében
Végrehajtás
Ellenırzés
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
8
Idı
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.
10
A projekt-életciklus modell
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:
12
•
bevonás,
•
egyeztetés,
•
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 min-
den é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:
16
•
megtérülési idı (payback period method)
•
nettó jelenérték (NPV)
•
belsı megtérülési kamatláb (IRR)
4.
A PROJEKT SZERKEZETE
Mit?
Üzleti célok Megbízó céljai
Ki?
Projektcélok Projektjavaslat Projekt meghatározás Szervezet
WBS
Kompetenciák és felelısségek mátrixa munkatrs1 munkatrs2 munkatrs3 ……
Feladatok definiálása
F1 F2 F3 F4 …
Feladatok
Mivel? Erıforrástervezés
Hogyan?
Hálóterv
Mikor? Gantt-diagram F1 F2 F3 F4
Az erıforrás igények ütemezése
Mennyibıl? 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.
1.1.
1.2.
1.1.1.
1.1.2.
3.
4.
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 1.1 helyszíni felmérés 1.2 változtatások tervei
4.2.
2. Az iroda bebútorozása 2.1 bútorok megrendelése 2.2 bútorok elhelyezése
3. Irodatechnika telepítése 3.1 irodatechnika megtervezése 3.2 irodatechnika elhelyezése 3.3 irodatechnika ellenırzése
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 A PROJEKT FELADATAI
PROJEKT
KIVITELEZÉSÉBEN
RÉSZT-
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 A B C D E F G H
Tevékenység Terület elıkészítése Anyagok beszerzése Szivattyú beszerzése Kútköpeny elıkészítése Kút ásása Szivattyú beszerelése Személyzet kiképzése Próbaüzem
Közvetl. megelızı
A, B D C, E C F, G
A CPM háló létrehozásának lépései: 1. a háló felrajzolása
22
Idıtart. [nap] Személyz. [fı] 1 2 2 1 4 1 2 1 5 2 1 1 2 1 2 1
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) 1
E (5) 4
F (1) 5
B (2) 0
H (2) 2
6
C (4)
7
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
A (1) 1
0
4
9
E (5)
F (1)
5
2
B (2)
0
4
D (2)
10
2
6
4
C (4)
12
H (2) 7
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
A (1)
4
D (2)
1
4 2
0
F (1)
5 4
9
2
B (2)
0
9
E (5)
10
2 0
6 2
7 10
4
C (4)
12
H (2)
12
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ı-
Korai befejezés
tartam 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 C
2 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 A
0
2 2 B
0
4 4 C
2
2 4 D
4
5 9 E
4
2 6 G
9
1 10 F
10 2 12 H
3. A tevékenységek késıi kezdési és befejezési idıpontjának meghatározása – idıtervezés visszafelé haladva. A hálóban visszafelé végezzük az idıtervezést. Definíciószerően a projektet záró tevékenység korai befejezési idıpontja (ami egyben a projekt befejezési idıpontja is) megegyezik a késıi befejezési idıponttal. A CPM technikánál követett eljáráshoz képest ügyeljünk arra, hogy itt nem csak egy végpontja lehet a hálónak. Hasonlóan a CPM háló tárgyalásánál már részletezett logikának megfelelıen, visszafelé felé haladva a hálóban kivonunk. 0
1 1 A
2
2 4 D
4
5 9 E
9
1 10 F
1
2
2
4
4
9
9
10
0
2
2
B 0
0
2
4
4
4
C 4
28
2
6
G 8
8
10
10 2 12 H 10
12
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
A 1 1 2
0
2
2
2
4
D 2 0 4
4
5
9
E 4 0 9
9
1 10
10 2 12
F 9 0 10
H 10 0 12
2
B 0 0 2
0
4 4 C 4 4 8
4
2 6 G 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/m2, Ft/folyóméter) A projektköltségek felmérési módszereinek elemei:
4.7.
•
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
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 1
2
Valószínő 3
4
5
6
Nagyon valószínő 7
8
9
10
Milyen súlyos következményekkel jár? Jelentéktelen 1
2
Súlyos 3
4
5
6
Nagyon súlyos 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
38
•
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
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 A megbeszélés kivitelezése Következı megbeszélés
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. Elıirányzott értékek
TERVEZÉS
Elıirányzott értékek
IRÁNYÍTÁS
Döntések
ELLENİRZÉS
Intézkedések
MEGVALÓSÍTÁS Tényleges értékek
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 pro-
jekt eredményét átadja a megrendelınek. Az átadás a gyakorlatban mindkét fél részére különös jelentıséggel bír. Ha az átadás nem egy meghatározott ponton történik, a projekt részvevıi úgy érezhetik, hogy erıfeszítéseik hiábavalóak voltak. Ebben az esetben annak a veszélye is fennáll, hogy a csapattagoknak továbbra is foglalkozniuk kell a 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
rek. A mátrixszervezetben irányított projektmegvalósításkor a különféle tevékenységeket a megfelelı funkcionális szervezetek munkatársai végzik a projektmenedzser horizontális, valamint a funkcionális vezetık vertikális irányítása mellett.
Vállalatvezetı
Fejlesztés
Termelés
Beszerzés
Személyügy
Pénzügy
Projektcsoport
Projektvezetı 1
Alaptevékenységek 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
Projekt tevékenységek
Fejlesztés
Termelés
Pénzügy
Logisztika
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
Módszertan
54
Projektszervezet
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 Ala-
pí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
Process Groups Knowledge areas 1. Project Integration Management
Initiating 1.1 Develop Project Charter 1.2 Preliminary project scope statement
Planning 1.3 Develop Project Management Plan
Executing 1.4. Direct and manage project execution
Controlling 1.5 Monitor and control project work 1.6 Integrated change control
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.6 Schedule 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 4.1 Cost estimating 4.2 Cost budgeting 5.1 Quality planning
4.3 Cost control
4. Project Cost Management 5. Project Quality Management
6.1 Human resource planning 6. Project Human Resource Management 7. Project Communication Management
7.1 Communications planning
8. Project Risk Management
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. Project Procurement Management
9.1 Plan purchases and acquisitions 9.2 Plan contracting
5.2 Perform quality assurance 6.2 Acquire project team 6.3 Develop project team
5.3 Perform quality control
7.2 Information distribution
7.3 Performance reporting 7.4 Manage stakeholders 8.6 Risk monitoring and control
9.3 Request seller responses 9.4 Select sellers
9.5 Contract administration
Closing 1.7 Close project
6.4 Manage project team
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 pon63
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ód67
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
