Képzeljük el, hogy van egy olyan komplex projektünk, ahol több csapat (stream) vagy több alvállalkozó dolgozik együtt.
Innen indulunk, innen foglak elvezetni benneteket az ütemtervezési pokol különféle bugyraiba, ahol az út néha tényleg jó szándékkal van kikövezve.
Pici esettanulmányok következnek, amikkel valódi projekteken találkozunk, és azt tapasztaltuk, hogy ezek a csapdák, gyorsan és egyszerűen elkerülhetők egy kis módszertan becsempészésével. Nézzük is!
A pokol tornáca: az ütemtervezés keresztségét nélkülözők
Meglepően sokszor találkozunk azzal a jelenséggel, hogy kiosztásra kerül a feladat a csapatoknak: "készítsétek el az első ütemterv verziótokat, aztán majd összenézzük őket és összeállítjuk a teljes projekt ütemtervét" - és ezzel valóban semmi gond nincsen - egyetlen dolog szokott kimaradni: van -e minden csapatban vagy minden alvállalkozónál elegendő kompetencia - ütemtervezési tudás és szoftver - ahhoz hogy jó ütemterv készülhessen?
Egy hatalmas projekten lettem bevonva megrendelői oldalról ütemtervezőnek, és két nagy és több kisebb alvállalkozó ütemtervét kellett összedolgoznom. Még a platformról is megvolt a megállapodás, mindenki Microsoft Projectben fogja készíteni a tervét. Megérkeztek az ütemtervek, és az időbeli ütemezésük természetesen tökéletes volt, mert a legjobb tudás szerint készült. Viszont olyan technikai hibákat tartalmaztak, ami miatt a későbbi aktualizálás vagy elemzés ellehetetlenült volna. Összegző tevékenységre kötött kapcsolatok, lógó tevékenységek, míuszos időközök, és még néhány kézi ütemezésű tevékenység is előfordult.
Így kerülhető el:
1. Legyen megegyezés a platformról (milyen szoftvert használnak a csapatok) 2. 2. Győződj meg róla, hogy minden stream-ben van megfelelő ütemtervezési kompetencia. Ha hiányzik, vegyél oktatást vagy szakembert a piacról - többszörösen meg fog térülni!
Az ütemtervezési pokol 1. bugyra: Bálványimádás: ragaszkodás a baseline-hoz
Egy hatalmas kivitelezési projekten voltam tanúja, hogy miután rengeteg energiát és időt beletettünk egy összehangolt mindenki által elfogadott ütemterv létrehozásába, és elmentettük az első baseline-t (alaptervet), a vezetőség elkezdett óckodni az ütemterv aktualizálásától. Ez a kőbe vésett terv - mondták - ezt kell betartani.
A baseline-nak nagyon fontos szerepe van, ugyanis ehhez mérünk. De ha az eltéréseket nem vezetjük át, és nem aktualizáljuk az ütemtervünket, akkor csak azt fogjuk tudni kimutatni, hogy mi mindennel késünk. Hogy valójában mikor érünk oda, sőt hogy mit kellene csinálni, hogy gyorsítsunk az nem fog látszódni.
Így kerülhető el:
1. Fogadjuk el, hogy az ütemterv egy élő dokumentum, ami a projekt minden időpillanatában a legjobb tudásunkat fogja mutatni a lefutásról. A baseline mentése nagyon fontos az elemzésekhez és az elvárások tisztán látásához, de aktualizálás nélkül az ütemtervezés csak álmodozás.
2. Aktualizáljunk rendszeresen. Egy jó ütemtervben a múltban csak olyasmi van aminek a készültsége már 100%-os. Ha valami elhúzódott tervezzük újra! Ha már más a logika, tervezzük újra!
3. Készítsünk utolérési tervet! Ha nagy a lemaradás, de tartani kell a határidőt, jöhet az utolérési terv három jól ismert lépése:
- nézzük meg mit lehet párhuzamosítani,
- nézzük meg, hova lehet bevonni még erőforrást,
- nézzük meg van -e olyan tartalom, amit el lehet hagyni.
Az ütemtervezési pokol 2. bugyra: Falánkság: idő spórolása az egyeztetéseken
Tudom, tudom, hogy az ütemtervezés örök kérdése, hogy hol spóroljunk időt. Egyet biztosan mondhatok: NE az ütemterv csapatok közötti egyeztetésén spóroljunk! Ez az egyeztetés ugyanis a projekt egyik legértékesebb rendszeres meetingje lehet. Nézzük is, hogy miért!
Ennek a bűnnek a tipikus esete, hogy miután rengeteg egyeztetéssel a csapatok összeállították a közös ütemtervet, és ráfordulnának a folyamatos aktualizálás időszakára, valaki kitalálja, hogy ÍRÁSOS adatszolgáltatással fognak aktualizálni: azaz mindenki beküldi, hogy a saját feladataival hol tart, és valaki majd központilag ezt adminisztrálja.
Mi az, ami elveszik? Tulajdonképpen minden, ami igazán fontos.
Ha a csapatok nem nézik meg közösen, hogy az egyes tevékenységek késése a másik csapatra milyen hatással volt, ha nem beszélik meg, hogy ki mit fog tudni tenni a lemaradás behozásához, akkor létre fog jönni az a jelenség, amivel a kontrollingban is sokat találkozunk:
A. alvállalkozó beküldi az előrehaladási adatait, sőt még az átfutási időket is aktualizálta, saját véghatárideje október 3.
B. Alvállalkozó is beküldi ugyanezeket az adatokat, de van egy csúszó tevékenysége, ami hatással van A. alvállakozó egyik tevékenységének kezdésére.
Mire A. alvállalkozó viszontlátja a frissített ütemtervet, a saját feladatainak vége október 3.-ról november 14-re változott. És nem érti, hogy miért, mert ő bizony nem ezt adta le...
Itt aztán rossz esetben elkezdődik egy vég nélküli levelezés, hibakeresés, hibáskeresés, és mire rájönnek az összefüggésre, addigra rengeteg felesleges energia ment el ahelyett, hogy egyetlen közös heti meetingen történt volna élőben a frissítés.
Így kerülhető el: Legyen egy szuper ütemterveződ, aki a teljes nagy ütemtervért felel (csak ő szerkesztheti egy személyben!), és add neki feladatul, hogy vezesse le a heti aktualizáló meetingeket. Ezekre a megbeszélésekre minden csapatot vagy alvállalkozót hívj meg. Elképesztő ereje van, hogy látják egymás aktuális munkáinak státuszát.
Minden ilyen meetingen azt kell megnézni:
- mi az, aminek el kellett volna készülnie mára? Hol tart? Ha lemaradásban van behozható -e vagy újratervezés szükséges?
- milyen feladatok vannak a következő néhány hétben, reálisak -e még a lefutások?
- milyen logikai kapcsolódások vannak a követktező néhány hétben a csapatok feladatai között? Ezek továbbra is érvényesek -e?
- amit most átterveztünk, annak milyen hatásai lettek a többi csapatra?
Egy ilyen aktualizáló meetingről a felek úgy állhatnak fel, hogy pontosan tudják, hogy milyen feladatokat kell megvalósítaniuk a következő héten.
Egy nagy IT megaprojekten én voltam az ütemtervező, egyedüli szerkesztési joggal, és szabad kézzel a meetingek levezetésében. A projekt végén a megrendelőnk így fogalmazott rólunk:
"A Nethod az ország egyik legnagyobb informatikai projektjén forradalmasította az ütemtervezést, ami gyorsan a projektvezetés első számú menedzsment eszköze lett. Többezer soros ütemterven keresztül valósult meg az egész projekt előrehaladás mérése és beszámoltatása. Ennek eredményeképpen határidőn és költségkereten belül sikerült leszállítani a teljes terjedelmet."
Az ütemtervezési pokol legmélyebb bugyra: Tékozlás: ütemtervezési koncepcióváltás futó projekten
Nem árulok el nagy titkot, azzal hogy elmondom, hogy egy komplex, többszereplős projekt többezer soros ütemtervének összeállításában rengeteg munkaóra, logikai kapcsolat feltérképezés, egyeztetés, vér és veríték van. Viszont csak egyszer kell nagyot álmodni, utána az aktualizálás már gyerekjáték!
Kivéve ha...
Kivéve ha a projekt közepén lesz valakinek egy ilyesmi remek ötlete:
- Használjunk másik szoftvert az ütemtervezéshez mostantól!
- Struktúráljuk át a teljes ütemtervet, hogy logikusabb legyen!
- Sokat változott a műszaki tartalom, kezdjük elölről!
Ezek mind újraindítják a fenti folyamatot, és általában többe kerülnek, mint amennyit hozni tudnak a konyhára.
Elmesélek egy történetet. Több alvállalkozós projekten minden alvállalkozó elkészítette a saját ütemtervét, a saját logikája szerint. Ezeket egymás alá másoltuk, és közös egyeztetéseken megteremtettük közöttük a logikai kapcsolatokat, tehát a tervek kommunikáltak egymással, létre jött a mester ütemterv. A projekt közepén jött az ötlet, hogy inkább az épület és a technológia logikájában kellene felépíteni a WBS struktúrát, minden tevékenység nyugodtan maradhat, csak tegyük át funkció szerinti főfejezet alá.
Indokolatlan mennyiségű munkát követően, az lett az eredmény, hogy volt egy nagyon szép struktúrában lévő ütemtervünk, amiben egyik alvállalkozó sem ismerte ki magát. Feszültséget okozott minden oldalon, vissza akartak térni a saját fájljaikhoz.
Az előző változat ugyan nem volt ilyen szép, viszont funkcionálisan tökéletesen megfelelt és mindenki már beletanult, megvalósult benne az együttműködés, a projekt irányítása és nyomonkövetése.
Így kerülhető el: Ha valami jól működik, projekt közben eszedbe se jusson lecserélni!