Projekt az egész világ, és projektmenedzser benne minden férfi és nő. Vagy nem.

Projekt az egész világ, és projektmenedzser benne minden férfi és nő. Vagy nem.

Volt egy időszak, amikor körülöttem mindenki projektmenedzsernek nevezte magát, drága öltönyökben járt és nagyon fontos embernek tűnt. Jobban belegondolva több projektmenedzser dolgozott a projekten, mint ahány fejlesztő. Ugyanazon a projekten.

Nem is lett kész határidőre. Pedig sok pénzről volt szó.

Ez a „projekt” dolog túl van misztifikálva, és az emberek nagy része nem is tudja, pontosan mi az. Mindent projektnek nevezünk és mindenki (állítólag) tapasztalt benne. A projektmenedzser ténykedése misztifikált és homályos, nincsenek tiszta célok és nem mérik az eredményességet.

Viszont ha jobban megnézzük ezeket a „projekteket” és „projektvezetőket”, akkor kiderül, hogy sokszor ez csak egy álca. Valójában ami ott zajlik, az nem projekt.

Például amikor egy létező szoftvert kell támogatni, az nem projekt. A hibajavítás nem projekt. Még a változáskérelmek kezelése is csak kivételes esetben projekt. Az Operations Management egy szép terület, ami nagyon nem ugyanaz mint a Project Management.

Ha például a projektünk során priorizálni kell a feladatokat, akkor az valójában nem projekt. A priorizálás azt jelenti, hogy bizonyos feladatokat a lista aljára teszünk és azok feltehetőleg nem készülnek el. A valódi projekt ismérve az, hogy a teljes scope-ot igyekszik leszállítani.

Ettől még a priorizálás értelmes tevékenység és szükség van rá. Például az Operations Management során. Csak ez nem projektvezetés.

További fontos ismérve a „nem projektszerű működésnek” a határidők kezelése. Az IT cégek – különösen a kicsik – szeretnek best effort alapon dolgozni. Azaz ami belefér az időbe azt megcsináljuk, ami nem fér bele azt nem. Ha jut rá idő akkor szép és felhasználóbarát lesz a szoftver. Ha pedig nem jut rá idő, nos akkor gyorsan összetákolunk valamit és imádkozunk hogy jó legyen.

Ennek megint csak nincs köze a projektvezetéshez. A projektvezetés arról szól, hogy pontosan azt és pontosan akkor leszállítjuk. Amikor ezt nem tudjuk garantálni, akkor ott nincs projektvezetés.

Tipikusan amikor time&material alapon mérnökórákat adunk el az ügyfélnek, az nem projekt. Az nem több, mintha kölcsönadnánk a kalapácsot. Viszont ha mérnökóra helyett határidőre szoftver funkciót szállítunk le az ügyfélnek, az már projektszerű. A különbség remélem világos.

A különbség ugyanis nem csak a számlázás módjában van, hanem a kockázatvállalásban is. Ha csak mérnökórát adunk el, akkor minden kockázat az ügyfélé. Lehet hogy kifejlesztünk egy új funkciót, amiről kiderül hogy másképp kell működnie. Ilyenkor az ügyfél fizet, hiszen a programozó x óráig írta a kódot, és fizet a funkció újraírásáért +y órát.

Viszont ha x óra fejlesztés helyett az új funkciót adtuk el, és arról derül ki hogy másképp kell csinálni, akkor nekünk kell grátiszban y órát dolgozni. Ezt senki sem akarja, ezért extra lépéseket kell tenni a félreértések elkerülése érdekében: pontosan megismerni az igényeket, tervezni, jóváhagyni a terveket, folyamatosan ellenőrizni a munkát, és persze folyamatosan kommunikálni az ügyféllel a félreértések elkerülése miatt.

Pontosan ezek a dolgok (is), amik a projektmenedzsment tárgykörébe tartoznak.

Nagyon hasznos tisztába tenni azt minden cégnél, tud-e, akar-e projektszerűen működni. Bevállalja hogy nem projektezik csak mérnököket ad el. Vagy bevállalja a projekteket, és akkor azt megpróbálja jól csinálni.

A probléma a köztes területtel van, a szürke zónával, amikor valaki kifelé projektszerűen próbál dolgozni de belül nem az van. IT-ban nagyon jellemző, hogy valaki látott már kívülről projektet, esetleg fejlesztett már szoftvert projekt keretein belül, ezért azt hiszi hogy tudja mi az.

És persze ott a másik irány: amikor házon belül szigorú projektszerű munka zajlik, tervezéssel, jóváhagyásokkal és bürokráciával, viszont az ügyfél rugalmas hozzáállást és gyors reakciót vár. Ilyenkor a megírt dokumentumok és elkészített tervek csak kidobott pénzt, vízfejet jelentenek, ami nem termel értéket.