Többen kérdezték tőlem, hogy hogyan lesz valakiből projektvezető. Tapasztalatom szerint az emberek nem úgy vágnak neki az egyetemnek, hogy "na, akkor én projektvezető leszek", hanem elvégeznek egy szakot (pl. informatikus, építész, egyéb mérnök) és ha már megfelelő időt eltöltöttek a szakmában, akkor előléptetés gyanánt rájuk bíznak egy projektet. Mindenféle projektvezető képzettség és előélet nélkül, természetesen. Úgyhogy a válaszom arra a kérdésre, hogy mi kell ahhoz, hogy projektvezető legyél: szerencse. Legyél jó helyen, jó időben. És meg is érkeztünk a Halo effektus fogalmához: ennek lényege, hogy az ember egy bizonyos tulajdonsága alapján ítélik meg az egész embert -> azaz feltételezik, hogy ha valaki jó szakember, akkor jó menedzser is lesz. A frászt. Attól, hogy tökéletes programokat ír valaki, még közel sem biztos, hogy tud bánni másokkal, hatással tud lenni csapatokra, be tudja osztani az időt és még sorolhatnék sok olyan dolgot, ami mind elengedhetetlen a jó projektvezetéshez.
Egyébként töredelmesen bevallom, ezt az utat jártam végig én is, sokáig programozóként dolgoztam, és ahol dolgoztam, nem is voltak kimondott projektek, főleg nem projektvezetők. Volt a főnököm, aki egy személyben szerezte a munkát, ápolta az ügyfélkapcsolatokat, hajtott minket a határidők miatt. Aztán ahogy sokasodtak a munkák, néhány régóta ott dolgozó programozót megkértek, vezessen egy-egy "projektet", így jutottam én is lehetőséghez. Természetesen nem volt kialakult metodológia (sőt, nem is tudtuk, hogy mi az), egy dolog számított: időben és jó minőségben szállítsuk a szoftvert az ügyfélnek, az ügyfél pedig legyen elégedett. Volt, aki bevált, mint projektvezető, volt, aki nem. Volt, aki elkezdte képezni magát, volt, aki nem. Én úgy gondolom, hogy azon kívül, hogy valakinek érzéke van a dolgokhoz, az önképzés elengedhetetlen. A projektvezetésben is vannak trendek, segédszoftverek, kapcsolódó tudományterületekben felfedezések, szóval ildomos képben lenni.
2022. május 4., szerda
2022. május 3., kedd
80/20 szabály, avagy a Pareto-elv
Vilfredo Pareto a múlt század elején élt olasz közgazdász megfigyelése szerint egy ország vagyonának 80%-át a lakosság 20%-a birtokolja. Ez az eredeti Pareto-elv (más néven 80/20-as szabály), amit aztán később kiterjesztettek más területekre is. Például legtöbbször igaz az, hogy a vállalatok bevételének 80%-át a vevők 20%-a hozza. Ami leginkább érdekes lehet projektvezetés (és minőségirányítás) szempontjából, az a Dr. Joseph Juran által megfogalmazott tétel, miszerint a hibák 80%-át az okok 20%-a okozza. Tehát ha megszüntetjük a hibaforrás kis részét (20%), azzal megoldhatjuk a problémák nagy részét (80%).
Az elemzéshez jól jön egy diagram (Pareto-chart), amire ránézve rögtön megállapíthatjuk, hol szorít a cipő.
Nézzünk egy példát az informatika területéről. Megbízónknak egy szoftvert fejlesztünk, és a felhasználó tesztelés során nagyon sok hiba jön elő. Szeretnénk tudni, hogy mi okozza ezeket a hibákat, és a fő okokat megszüntetni.
Csináljunk egy kis táblázatot, ahol az okokat a hibák száma alapján sorba rendezzük:
Ez egy egyszerű kis példa, már a táblázatból is látszik (a kumulált oszlopból), hogy az első három probléma okozza a hibák 80%-át (egész pontosan 83).
Pareto-charton még szemléletesebb:
A bal oldali függőleges tengely a hibák számát mutatja, a vízszintes pedig a kategóriákat. Ebből összeáll egy egyszerű oszlopdiagram (bar chart). A Pareto chart abban különleges, hogy van egy jobb oldali függőleges tengelye is, ez pedig a kumulált %-okat adja. Ha ezt a vonalat rárajzoljuk az oszlopdiagramra, máris látszik, hogy hol érjük el a 80%-ot (zölddel jelöltem). Fontos, hogy a kategóriákat mindig érték szerinti csökkenő sorrendbe rendezzük, különben fals eredményt kapunk.
Az elemzéshez jól jön egy diagram (Pareto-chart), amire ránézve rögtön megállapíthatjuk, hol szorít a cipő.
Nézzünk egy példát az informatika területéről. Megbízónknak egy szoftvert fejlesztünk, és a felhasználó tesztelés során nagyon sok hiba jön elő. Szeretnénk tudni, hogy mi okozza ezeket a hibákat, és a fő okokat megszüntetni.
Csináljunk egy kis táblázatot, ahol az okokat a hibák száma alapján sorba rendezzük:
Pareto-charton még szemléletesebb:
 |
| Pareto-chart |
Projekt megtérülés
A Projekt és Üzemeltetés bejegyzés végén már pedzegettem, hogyan lehet kiszámolni, mennyi hasznunk lesz egy adott projekten, ott azonban csak egy egyszerű példát mutattam, csomó egyéb tényezőt (pl. jelenérték, jövőbeli érték) figyelembe sem véve.
Úgy gondolom, ebben a témában még van annyi, hogy bővebben írjak róla.
A projekt megtérülésének kiszámolására, illetve több projekt összehasonlítására különféle mérési módszereket használhatunk.
Költség-haszon elemzés (Cost-benefit analysis, CBA)
Tulajdonképpen ez az, amiről a Projekt és Üzemeltetés bejegyzésben írtam. Vesszük az összes költséget, az összes bevételt (hasznot) és ezt összehasonlítjuk.
Nézzük a már bemutatott példát:
Ügyviteli szoftver implementációjával bíznak meg minket. 25.000.000 Ft implementációs díjat kapunk érte, a szoftver átvétele után pedig havi 800.000 Ft support díjat fizet az ügyfél.
Az implementáció maga 40.000.000 Ft-ba kerül (programozók, tesztelők, projektvezető, fejlesztői gépek, fejlesztői, teszt környezet, szoftverek, stb.), 10 hónapig tart és a havi support költség 400.000 Ft.
Implementáció után -15.000.000 Ft-on állunk (25.000.000 - 40.000.000). Havonta 400.000 Ft marad meg a support díjból (800.000 - 400.000), azaz 10 (implementáció hossza) + 37.5 (15.000.000 / 400.000) hónap alatt fog megtérülni a befektetés (3.96 év).
Viszont nem vettük figyelembe az inflációt, sem azt, hogy a supportból befolyó összeg csak havonta csordogál, míg ha megkapnánk egy összegben, betennénk a bankba arra legalább 6% kamatot fizetnének. Tehát ami pénzt a jövőben kapok meg, az biztos, hogy kevesebbet ér, mintha azt ma megkapnám.
Például, ha a support összeget 3 évre előre kifizetné az ügyfél, akkor 3*12*800.000 = 28.800.000 Ft-ot kapnánk. Ezt 6%-os kamattal betéve a bankba a 3. év után 34.301.260 Ft-unk lenne. Jobban hangzik, ugye? Ezt az értéket úgy hívjuk, hogy jövőbeni érték (angolul Future Value, FV).
Képlete: FV = PV(1 + i)n, ahol
FV - jövőbeli érték (Future Value)
PV - jelenérték (Present Value)
i - kamatláb
n - periódus
azaz
FV = 28.800.000* (1 + 0.06)3 =34.301.260 Ft
Pont ezért ha lehet, akkor a projektjeinkért járó pénzt minél előbb zsebeljük be! Nagyon rossz konstrukció az, amikor pl. az ügyfél csak a projekt legvégén, egy összegben fizet. Természetesen abba a megrendelő sem szokott belemenni, hogy az elején mindenféle biztosíték nélkül nekünk adja az összes pénzt, viszont ki lehet kötni mérföldköveket, amihez fizetési ütemezés tartozik. Például:
Nézzük ezt a példát számszerűsítve. 10.000.000 Ft-ért fejlesztünk egy szoftvert 10 hónap alatt, a felhasználói tesztek pedig 2 hónapig tartanak, ez után élesítjük a rendszert. 3 lehetőség van:
PV = 10.000.000 / (1+0.06)1 =9.433.962 Ft
10 hónap múlva kapunk 30%-ot, azaz 3.000.000 Ft-ot, ami mai értéken (6% éves kamat -> 0.5% havi kamat, hiszen nem egész évvel számolunk, ezért az n, vagyis az időszak értéke a képletben 10 lesz):
PV = 3.000.000 / (1+0.005)10 = 2.857.143 Ft
12 hónap múlva (1 év) kapunk 30%-ot, azaz 3.000.000 Ft-ot, mai értéken
PV = 3.000.000 / (1+0.06)1 = 2.830.189 Ft
Ha a 3 fázist összeadjuk 4.000.000 + 2.857.143 + 2.830.189 = 9.687.322 Ft.
Látható, hogy természetesen akkor járnánk legjobban, ha az ügyfél az elején kifizetne mindent, de ha ez nem lehetséges, akkor érdemes arra törekedni, hogy legalább egy része minél előbb befolyjon.
Úgy gondolom, ebben a témában még van annyi, hogy bővebben írjak róla.
A projekt megtérülésének kiszámolására, illetve több projekt összehasonlítására különféle mérési módszereket használhatunk.
Költség-haszon elemzés (Cost-benefit analysis, CBA)
Tulajdonképpen ez az, amiről a Projekt és Üzemeltetés bejegyzésben írtam. Vesszük az összes költséget, az összes bevételt (hasznot) és ezt összehasonlítjuk.
Nézzük a már bemutatott példát:
Ügyviteli szoftver implementációjával bíznak meg minket. 25.000.000 Ft implementációs díjat kapunk érte, a szoftver átvétele után pedig havi 800.000 Ft support díjat fizet az ügyfél.
Az implementáció maga 40.000.000 Ft-ba kerül (programozók, tesztelők, projektvezető, fejlesztői gépek, fejlesztői, teszt környezet, szoftverek, stb.), 10 hónapig tart és a havi support költség 400.000 Ft.
Implementáció után -15.000.000 Ft-on állunk (25.000.000 - 40.000.000). Havonta 400.000 Ft marad meg a support díjból (800.000 - 400.000), azaz 10 (implementáció hossza) + 37.5 (15.000.000 / 400.000) hónap alatt fog megtérülni a befektetés (3.96 év).
Viszont nem vettük figyelembe az inflációt, sem azt, hogy a supportból befolyó összeg csak havonta csordogál, míg ha megkapnánk egy összegben, betennénk a bankba arra legalább 6% kamatot fizetnének. Tehát ami pénzt a jövőben kapok meg, az biztos, hogy kevesebbet ér, mintha azt ma megkapnám.
Például, ha a support összeget 3 évre előre kifizetné az ügyfél, akkor 3*12*800.000 = 28.800.000 Ft-ot kapnánk. Ezt 6%-os kamattal betéve a bankba a 3. év után 34.301.260 Ft-unk lenne. Jobban hangzik, ugye? Ezt az értéket úgy hívjuk, hogy jövőbeni érték (angolul Future Value, FV).
Képlete: FV = PV(1 + i)n, ahol
FV - jövőbeli érték (Future Value)
PV - jelenérték (Present Value)
i - kamatláb
n - periódus
azaz
FV = 28.800.000* (1 + 0.06)3 =34.301.260 Ft
Pont ezért ha lehet, akkor a projektjeinkért járó pénzt minél előbb zsebeljük be! Nagyon rossz konstrukció az, amikor pl. az ügyfél csak a projekt legvégén, egy összegben fizet. Természetesen abba a megrendelő sem szokott belemenni, hogy az elején mindenféle biztosíték nélkül nekünk adja az összes pénzt, viszont ki lehet kötni mérföldköveket, amihez fizetési ütemezés tartozik. Például:
- Szerződéskötéskor az implementációs díj 40%-a
- UAT-ra átadáskor az implementációs díj 30%-a
- Élesítéskor az implementációs díj 30%-a
Nézzük ezt a példát számszerűsítve. 10.000.000 Ft-ért fejlesztünk egy szoftvert 10 hónap alatt, a felhasználói tesztek pedig 2 hónapig tartanak, ez után élesítjük a rendszert. 3 lehetőség van:
- Megkapjuk a 10.000.000 Ft-ot a szerződés aláírásakor
- A 10.000.000 Ft-ot élesítés után kapjuk meg, azaz 8 hónap múlva. Ez akkor mai értéken (ha 6%-os kamatlábbal számolunk)
PV = 10.000.000 / (1+0.06)1 =9.433.962 Ft
- A fent említett megosztásban kapjuk meg a pénzt (40%, 30%, 30%):
10 hónap múlva kapunk 30%-ot, azaz 3.000.000 Ft-ot, ami mai értéken (6% éves kamat -> 0.5% havi kamat, hiszen nem egész évvel számolunk, ezért az n, vagyis az időszak értéke a képletben 10 lesz):
PV = 3.000.000 / (1+0.005)10 = 2.857.143 Ft
12 hónap múlva (1 év) kapunk 30%-ot, azaz 3.000.000 Ft-ot, mai értéken
PV = 3.000.000 / (1+0.06)1 = 2.830.189 Ft
Ha a 3 fázist összeadjuk 4.000.000 + 2.857.143 + 2.830.189 = 9.687.322 Ft.
Látható, hogy természetesen akkor járnánk legjobban, ha az ügyfél az elején kifizetne mindent, de ha ez nem lehetséges, akkor érdemes arra törekedni, hogy legalább egy része minél előbb befolyjon.
2022. május 2., hétfő
A projekt scope-ja
A wikipedia szerint (ők pedig a PMBOK-ból vették - erről majd később) a projekt scope a következő: "The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions."
A szónak nem nagyon hallottam még magyar megfelelőjét, de most gyorsan utána néztem az Interneten, és bizonyos helyeken 'terjedelem'-ként hivatkoznak rá. Logikus, hiszen azt jelenti, hogy mire terjed ki a projekt: milyen munkát kell elvégezni ahhoz, hogy a projekt céljaként meghatározott eredményt elérjük. Mindenesetre én furcsán érezném magam, ha scope helyett terjedelmet használnék, úgyhogy a jövőben sem fogom :)
Fontos, hogy egy projektnek jól körülhatárolt legyen a scope-ja, nagyot lehet bukni, ha ez nincs pontosan definiálva, és nem tudatosul a projekt résztvevőkben kellőképpen.
Projektvezetőként az a feladatunk, hogy a projektet a scope-on belül tartsuk, illetve ha valami változás merül fel, akkor azt megfelelően kezeljük. A projekteknél van egy "szentháromság": scope, költség, határidő. Ez a három igen szoros kapcsolatban van egymással, ha az egyik változik, akkor az hatással van a többire.
Tegyük fel, hogy van egy projektünk, aminek a scope-jába tartozik A funkció, B funkció, C funkció, 600.000 Ft-os budget-vel 2 hónap alatt el kell készülni.
Ha a vezetőség azt mondja, tegyük még bele D funkciót, akkor PM-ként (project manager, projektvezető) azt mondjuk: ok, de akkor adjatok rá több pénzt, vagy vegyük ki helyette B funkciót.
Ha azt mondják, rövidítsük le a határidőt, akkor egy PM erre azt mondja: ok, de akkor többe fog kerülni, vagy vegyük ki A funkciót a scope-ból.
Tehát az ilyen tipikus ügyfél igényekre, amik úgy kezdődnek, hogy "ezt még bele kellene tenni", határozottan és bátran mondjuk azt: természetesen lehet, de így többe fog kerülni és/vagy később készülünk el. Így is kell? El lehet magyarázni a háromszöget is, az ügyfél ha látja, hogy tényleg nem csak kekeckedésből mondjuk, hogy ezt így nem lehet, másként fog hozzáállni az egészhez.
Viszont ahhoz, hogy mindezt ilyen szépen működtethessük, az kell, hogy a scope az elején minél pontosabban definiálva legyen. Ha nincs leírva, hogy A, B és C funkció tartozik a scope-ba, akkor honnan tudná az ügyfél, hogy D már nem fér bele? És mi milyen alapon mondunk nemet?
A szónak nem nagyon hallottam még magyar megfelelőjét, de most gyorsan utána néztem az Interneten, és bizonyos helyeken 'terjedelem'-ként hivatkoznak rá. Logikus, hiszen azt jelenti, hogy mire terjed ki a projekt: milyen munkát kell elvégezni ahhoz, hogy a projekt céljaként meghatározott eredményt elérjük. Mindenesetre én furcsán érezném magam, ha scope helyett terjedelmet használnék, úgyhogy a jövőben sem fogom :)
Fontos, hogy egy projektnek jól körülhatárolt legyen a scope-ja, nagyot lehet bukni, ha ez nincs pontosan definiálva, és nem tudatosul a projekt résztvevőkben kellőképpen.
Projektvezetőként az a feladatunk, hogy a projektet a scope-on belül tartsuk, illetve ha valami változás merül fel, akkor azt megfelelően kezeljük. A projekteknél van egy "szentháromság": scope, költség, határidő. Ez a három igen szoros kapcsolatban van egymással, ha az egyik változik, akkor az hatással van a többire.
Ha a vezetőség azt mondja, tegyük még bele D funkciót, akkor PM-ként (project manager, projektvezető) azt mondjuk: ok, de akkor adjatok rá több pénzt, vagy vegyük ki helyette B funkciót.
Ha azt mondják, rövidítsük le a határidőt, akkor egy PM erre azt mondja: ok, de akkor többe fog kerülni, vagy vegyük ki A funkciót a scope-ból.
Tehát az ilyen tipikus ügyfél igényekre, amik úgy kezdődnek, hogy "ezt még bele kellene tenni", határozottan és bátran mondjuk azt: természetesen lehet, de így többe fog kerülni és/vagy később készülünk el. Így is kell? El lehet magyarázni a háromszöget is, az ügyfél ha látja, hogy tényleg nem csak kekeckedésből mondjuk, hogy ezt így nem lehet, másként fog hozzáállni az egészhez.
Viszont ahhoz, hogy mindezt ilyen szépen működtethessük, az kell, hogy a scope az elején minél pontosabban definiálva legyen. Ha nincs leírva, hogy A, B és C funkció tartozik a scope-ba, akkor honnan tudná az ügyfél, hogy D már nem fér bele? És mi milyen alapon mondunk nemet?
Projekt és üzemeltetés
Ahogy az első bejegyzésben írtam, a projekt egyszeri, kezdő és végdátum közé szorított esemény, aminek a végén ott a produktum. Amikor pedig a projekt véget ér, akkor jön az üzemeltetés (support, rendszertámogatás, ki hogy hívja - én a supportot szoktam meg, legtöbbször ezt fogom használni, viszont az angol nyelvű szakirodalom gyakran emlegeti 'operations'-ként ezt a fázist, érdemes tehát ezt is megjegyezni).
És hogy mi a support? Az, ami nem projekt. Igaz, hogy van kezdő dátuma (megegyezik a projekt végdátumával), de nincs vége: míg a projekt egy átmeneti dolog, addig a support folyamatosan ismétlődő eseményekből áll. A support során a projekt végtermékét támogatjuk, tehát nem mondhatjuk, hogy egyetlen egyedi terméket állítunk elő.
Nézzünk egy hétköznapi példát: az, hogy befüvesíted a kerted egy projekt. Elkezded egy adott napon, felásod a földet, elszórod a fűmagot, locsolgatod és a végén kinő a fű. A projektet sikeresen lezárhatod. Ez után már csak nyírnod kell, mondjuk minden második hét végén. Na ez már viszont üzemeltetés. Hiszen nincs végdátuma (hacsak ki nem szárad a fű), ismétlődő cselekvéseket végzel és nem hozol létre új terméket.
A 5-10 fősnél nagyobb cégeknél ez a két terület általában szervezeti szinten is szétválik: vannak, akik projekteken dolgoznak, és van az ún. support csapat. A kettő között gyakran van jövés-menés, de az is lehet, hogy a projekt lezárása után a projekt csapat tagjai egy újabb projekten kezdenek el dolgozni, és onnantól minden felmerülő problémát a supportosok oldanak meg. Ebben az esetben célszerű már a projekt során néhány embert a supportról bevonni a munkába, hogy megfelelően képzett legyen, ismerje a terméket, a sajátosságokat és az ügyféllel is "megbarátkozzon".
Kis cégeknél egyébként az a gyakoribb, hogy a projekten dolgozók foglalkoznak a későbbiekben is a termék támogatásával, és minél nagyobb egy vállalat, annál inkább szétválik a két terület.
Pont a végtelensége miatt a support sokszor nagyobb üzlet, mint maga a projekt, hiszen évekig, évtizedekig tartó, folyamatos bevételt jelent a cég számára. Éppen ezért, mikor egy projektet árazunk, beleszámoljuk azt is, hogy ez a projekt a lezárás után bizony még pénzt fog termelni, úgyhogy általában 3 év support bevételt hozzáveszünk még a tervezéshez, így sokkal alacsonyabb árat tudunk megadni az ügyfélnek, mintha csak a projekt bevételből várjuk a megtérülést. Hogy mondjak egy egyszerű példát: egy ügyviteli szoftver elkészítésére írnak ki pályázatot. A követelményeket elemezzük és úgy becsüljük, hogy kb. 40.000.000 Ft-ból ki tudjuk hozni. Ha csak ezt néznénk, akkor az ügyfélnek adnánk egy 50 milliós ajánlatot, ő hanyatt vágná magát és elfogadná valaki más ajánlatát, aki ennél kevesebbet kér. Ehelyett figyelembe vesszük azt is, hogy a projekt lezárása után havi 800.000 Ft-ért rendszert követünk az ügyfélnek, ami azt jelenti, hogy éves szinten 9.600.000 Ft fog befolyni tőle. Természetesen a supportot végző embereknek is van költségük, legyen mondjuk havi 400.000 Ft. Ha csak 3 évet veszünk, akkor 3 év alatt 28.880.000 jön be, 14.400.000 Ft megy el költségekre, azaz 14.400.000 marad. Ha ezt levonjuk az eredetileg ajánlott 40 millióból, akkor simán adhatunk egy 25 milliós ajánlatot, amivel az ügyfél nagyon boldog lesz. És mi is, mert 3 év alatt bejön a ráfordítás, utána pedig minden év support mondhatni már csak ajándék.
És hogy mi a support? Az, ami nem projekt. Igaz, hogy van kezdő dátuma (megegyezik a projekt végdátumával), de nincs vége: míg a projekt egy átmeneti dolog, addig a support folyamatosan ismétlődő eseményekből áll. A support során a projekt végtermékét támogatjuk, tehát nem mondhatjuk, hogy egyetlen egyedi terméket állítunk elő.
Nézzünk egy hétköznapi példát: az, hogy befüvesíted a kerted egy projekt. Elkezded egy adott napon, felásod a földet, elszórod a fűmagot, locsolgatod és a végén kinő a fű. A projektet sikeresen lezárhatod. Ez után már csak nyírnod kell, mondjuk minden második hét végén. Na ez már viszont üzemeltetés. Hiszen nincs végdátuma (hacsak ki nem szárad a fű), ismétlődő cselekvéseket végzel és nem hozol létre új terméket.
A 5-10 fősnél nagyobb cégeknél ez a két terület általában szervezeti szinten is szétválik: vannak, akik projekteken dolgoznak, és van az ún. support csapat. A kettő között gyakran van jövés-menés, de az is lehet, hogy a projekt lezárása után a projekt csapat tagjai egy újabb projekten kezdenek el dolgozni, és onnantól minden felmerülő problémát a supportosok oldanak meg. Ebben az esetben célszerű már a projekt során néhány embert a supportról bevonni a munkába, hogy megfelelően képzett legyen, ismerje a terméket, a sajátosságokat és az ügyféllel is "megbarátkozzon".
Kis cégeknél egyébként az a gyakoribb, hogy a projekten dolgozók foglalkoznak a későbbiekben is a termék támogatásával, és minél nagyobb egy vállalat, annál inkább szétválik a két terület.
Pont a végtelensége miatt a support sokszor nagyobb üzlet, mint maga a projekt, hiszen évekig, évtizedekig tartó, folyamatos bevételt jelent a cég számára. Éppen ezért, mikor egy projektet árazunk, beleszámoljuk azt is, hogy ez a projekt a lezárás után bizony még pénzt fog termelni, úgyhogy általában 3 év support bevételt hozzáveszünk még a tervezéshez, így sokkal alacsonyabb árat tudunk megadni az ügyfélnek, mintha csak a projekt bevételből várjuk a megtérülést. Hogy mondjak egy egyszerű példát: egy ügyviteli szoftver elkészítésére írnak ki pályázatot. A követelményeket elemezzük és úgy becsüljük, hogy kb. 40.000.000 Ft-ból ki tudjuk hozni. Ha csak ezt néznénk, akkor az ügyfélnek adnánk egy 50 milliós ajánlatot, ő hanyatt vágná magát és elfogadná valaki más ajánlatát, aki ennél kevesebbet kér. Ehelyett figyelembe vesszük azt is, hogy a projekt lezárása után havi 800.000 Ft-ért rendszert követünk az ügyfélnek, ami azt jelenti, hogy éves szinten 9.600.000 Ft fog befolyni tőle. Természetesen a supportot végző embereknek is van költségük, legyen mondjuk havi 400.000 Ft. Ha csak 3 évet veszünk, akkor 3 év alatt 28.880.000 jön be, 14.400.000 Ft megy el költségekre, azaz 14.400.000 marad. Ha ezt levonjuk az eredetileg ajánlott 40 millióból, akkor simán adhatunk egy 25 milliós ajánlatot, amivel az ügyfél nagyon boldog lesz. És mi is, mert 3 év alatt bejön a ráfordítás, utána pedig minden év support mondhatni már csak ajándék.
2022. május 1., vasárnap
Earned Value
A projektvezetők szeretnek mindenféle kimutatásokat, számításokat végezni (na jó, az enyhe túlzás, hogy szeretnek, maradjunk annyiban, hogy kell), ami alapján meg tudják állapítani, hogy éppen hogy áll a projekt, mennyit költöttek rá, mennyi pénzt hoz, megpróbálják megjósolni, a végén mennyibe kerül, stb.
Ezek közül az egyik legtöbbet használt az Earned Value Management (EVM). Ennek lényege, hogy a tervezett és a ténylegesen elvégzett munka egy adott pillanatban történő összehasonlításával meg tudjuk mondani, hogyan alakulnak a költségeink, valamint a határidők.
És hogy mindez miért jó nekünk? Többek közt azért, mert
Tegyük fel, hogy egy szoftvermodult kell fejleszteni, a tervek szerint 4 hét alatt végzünk vele, a költségeket minden héten egységesen 200.000 Ft-ra becsüljük.
Jelenleg a 3. hét végén vagyunk és a következőképpen állunk:
A következő táblázat az EVM-tel kapcsolatos fogalmakat és számításokat mutatja:
Még egy kis szösszenet a témához: az, hogy egy munkát mikor tekintünk elvégzettnek, és a kész/nem kész értékpárokon kívül mit veszünk még figyelembe tulajdonképpen mindegy, a lényeg, hogy a projekt elején határozzuk meg és a mérés során mindig ugyanazt a módszert használjuk. Pl. egy feladatot akkor tekintünk elvégzettnek, ha teljesen kész van (0% - 100%). De lehet, hogy ha már belekezdünk, akkor 20%, tesztre átadáskor 80%, élesítéskor 100%.
Ezek közül az egyik legtöbbet használt az Earned Value Management (EVM). Ennek lényege, hogy a tervezett és a ténylegesen elvégzett munka egy adott pillanatban történő összehasonlításával meg tudjuk mondani, hogyan alakulnak a költségeink, valamint a határidők.
És hogy mindez miért jó nekünk? Többek közt azért, mert
- Jelzi, hogy itt bizony probléma van, túlcsúszunk a pénz- és/vagy időkereten.
- Ha valaki megkérdezi, hogy állunk, konkrét mérőszámot tudunk mondani a készültségre, nem csak annyit, hogy "jól" vagy "rosszul".
- Adott időpontban nagy biztonsággal meg tudjuk becsülni a projekt végköltségét és a teljesítés időpontját.
Tegyük fel, hogy egy szoftvermodult kell fejleszteni, a tervek szerint 4 hét alatt végzünk vele, a költségeket minden héten egységesen 200.000 Ft-ra becsüljük.
Jelenleg a 3. hét végén vagyunk és a következőképpen állunk:
- Az első hétre tervezett munkákat gond nélkül elvégeztük, és az erőforrás költség 200.000 Ft volt.
- A második héten egy olyan technológiai problémába ütköztünk, ami eddig nem fordult még elő a cég életében, ezért bevontunk egy plusz erőforrást (szakértőt), és a többiek idejéből is jócskán elment, így a hétre tervezett feladatokat nem tudtuk befejezni és a költségek is felkúsztak 220.000 Ft-ra.
- A harmadik héten sikerült befejezni a 2. hétre tervezett munkát, valamint a 3. heti adag felét. Menet közben a plusz erőforrást levettük a projektről és egy másik emberünk lebetegedett, így a harmadik hét költsége 140.000 Ft lett.
A következő táblázat az EVM-tel kapcsolatos fogalmakat és számításokat mutatja:
| Jel | Név | Jelentés | Számítás | 3. hét végén |
| PV | Planned Value (Tervezett érték) | Azon munka becsült értéke, amit adott időpontig el kell(ett volna) végezni | becsült költség | PV = 200.000 + 200.000 + 200.000 (vagy egyenlő költségek esetén 200.000 * 3)= 600.000 |
| EV | Earned Value (Megtermelt érték) | Adott időpontig ténylegesen elvégzett munka értéke | ténylegesen elvégzett munka becsült költség | EV = 200.000 + 200.000 + 100.000 (a 3. heti munka felét végeztük csak el) = 500.000 |
| AC | Actual Cost (Aktuális költség) | A projekt tényleges költsége adott időpontig | tényleges költség | AC = 200.000 + 220.000 + 140.000 = 560.000 |
| CV | Cost Variance (Költségeltérés) | Adott pillanatban túlléptük -e a költségkeretet vagy sem. A negatív érték azt jelenti, hogy túlléptük. | CV = EV - AC | CV = 500.000 - 560.000 = -60.000 (60.000 Ft-tal túlléptük a keretet) |
| SV | Schedule Variance (Ütemterv eltérés) | Adott pillanatban tartjuk -e az ütemtervet. A negatív érték azt jelenti, hogy le vagyunk maradva. | SV = EV - PV | SV = 500.000 - 600.000 = -100.000 (100.000 Ft-nyival el vagyunk maradva az ütemterv által elvárt megtermelt értéktől) |
| CPI | Cost Performance Index (Költségindex) | A költséghatékonyság mérőszáma. Azt mutatja, hogy mennyi értéket termelek a befektetett összeghez képest. 1-nél kisebb érték nem jelent jót. | CPI = EV / AC | CPI = 500.000 / 560.000 = 0.89 (Minden befektetett 100 Ft után 89 Ft-nyi értéket termelek... nem túl jó) |
| SPI | Schedule Performance Index (Ütemterv teljesítési index) | Azt mutatja, hogy az eredetileg tervezetthez képest hogyan haladok. | SPI = EV / PV | SPI = 500.000 / 600.000 = 0.83 (Az eredetihez képest 83%-on állok) |
| BAC | Budget At Completion | A projekt teljes költsége (ezt az értéket becsültük a projekt elején) | tervezett költség | BAC = 200.000 + 200.000 + 200.000 + 200.000 (vagy egyenlő költségek esetén 200.000 * 4) = 800.000 |
| EAC | Estimate At Completion | Adott időpontban ennyire becsüljük a projekt teljes költségét a befejezésig | EAC = BAC/CPI | EAC = 800.000 /0.89 = 900.000 (a projekt valószínűleg 900.000 Ft-ba fog kerülni az eredetileg tervezett 800.000-hez képest) |
| ETC | Estimate To Complete | Adott időpontban mennyi költséget becsülünk a befejezésig | ETC = EAC-AC | ETC = 900.000 - 560.000 = 340.000 (valószínűleg még 340.000 Ft-ot kell ráköltenem a projektre a befejezésig) |
| VAC | Variance At Completion | Várhatóan mennyivel lépjük túl a költségkeretet (vagy mennyivel kerül kevesebbe a projekt, ami valljuk be, elég ritka). Ha az érték negatív, akkor költségtúllépés van. | VAC = BAC - EAC | VAC = 800.000 - 900.000 = -100.000 (100.000 Ft-tal túl fogjuk lépni a budget-t) |
Még egy kis szösszenet a témához: az, hogy egy munkát mikor tekintünk elvégzettnek, és a kész/nem kész értékpárokon kívül mit veszünk még figyelembe tulajdonképpen mindegy, a lényeg, hogy a projekt elején határozzuk meg és a mérés során mindig ugyanazt a módszert használjuk. Pl. egy feladatot akkor tekintünk elvégzettnek, ha teljesen kész van (0% - 100%). De lehet, hogy ha már belekezdünk, akkor 20%, tesztre átadáskor 80%, élesítéskor 100%.
Mi az a projekt?
A wikipedia szerint a projekt egyszeri vállalkozás, melynek célja, hogy egyedi terméket, szolgáltatást vagy végeredményt hozzon létre.
Ezt szerintem nem is nagyon kell magyarázni. Tehát ami fontos, hogy a projekt mindig egyszeri, van kezdete, vége és a végén van valami egyedi eredmény (termék, szolgáltatás). Ebből következik, hogy folyamatosan ismétlődő folyamatok és azonos termékek előállításakor nem beszélünk projektről.
Ezt szerintem nem is nagyon kell magyarázni. Tehát ami fontos, hogy a projekt mindig egyszeri, van kezdete, vége és a végén van valami egyedi eredmény (termék, szolgáltatás). Ebből következik, hogy folyamatosan ismétlődő folyamatok és azonos termékek előállításakor nem beszélünk projektről.
Feliratkozás:
Bejegyzések (Atom)