Keresés ebben a blogban

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?

Nincsenek megjegyzések:

Megjegyzés küldése