Olvasói kérdésre válaszolva a projekt portfólió menedzsment kérdéskörében.

Olvasói kérdésre válaszolva a projekt portfólió menedzsment kérdéskörében.

Viktor vetette fel egy másik poszthoz írt megjegyzésében, hogy:

„Esetleg szoftver projekt portfolió menedzsmentben vannak tapasztalataid, best practice-eid? Érdekelne, hogy szokás megoldani az eroforrástervezést olyan helyen, ahol van mondjuk 5-10 nagyobb projekt egy évben és hogy lehet kezelni a bizonytalanságaikat ( például, hogy ha az egyik csúszik, akkor csúsztatja a másikat is, ha az egyik eleszi a teszteloi eroforrásokat, akkor a másik sem mehet emiatt stb, mit lehet ilyenkor tenni, mennyire lehet ezt megtervezni )”

Éppen most lesz a május 18-án a PMSZ rendezésében erről szó, lásd Körkapcsolás a Projekt Portfolió Menedzsment elméletének és gyakorlatának mérkőzéséről

Személyes tapasztalatok:

A projektek bizony csúsznak. Az ember év elején kap egy listát, ceruzával beírja a neveket, aztán jön az Élet és mindent felborít. Egyszer az a baj, hogy a kolléga ugyan kapott egy projektet, de az nem indult el, és ezért nincs munka. Aztán meg beindul a projekt, de rácsúszik a következőre, és akkor 2 helyen kellene lenni egyszerre.

Nagyjából 4 probléma van, amit el kell kerülni:

1) Mivel a munka hektikus (egyszer sok, máskor kevés), a kulcsemberek (lásd PM, rendszerszervező, üzleti elemző) megtartása nehézzé válik. A jó szakértő nem 1 zsák krumpli vagy 1 darab biorobot, hogy csak úgy kidobom ha nincs munka és leakasztok egy másikat amikor kell.

2) A tudás megtartása kritikus. Ugyebár fontos az adott ügyfélnél, adott közegben szerzett tapasztalat, és jó lenne ha folyamatosan ugyanazak az emberek dolgoznának projekteken. Amikor egy szakembernek lejár a projektje és kisétál az ajtón, viszi a tudást és a know-how-t.

3) A nagyobb projekteknél nem csak a tudással, hanem a mennyiséggel is gond van. Nem lehet egyik napról a másikra 12 fejlesztőt felvenni, illetve nem lehet azt mondani a jelölteknek, hogy fel foglak venni, de nem tudom mikor, mert X igazgató elment nyaralni és nem tudom mikor írja alá a megrendelést.

4) Habár a projektszervezet szükség szerint tud növekedni vagy csökkenni, de bizonyos erőforrások száma kötött és nem változtatható. Például ha a tesztelői erőforrások száma kötött, vagy maga a szoftver kód egy kötött erőforrás (ugyanazon a kódrészleten egyszerre csak 1 projekt tud dolgozni).

Néhány gyakorlati tipp e problémák megoldására:

Csapat növelése, felelősségek összefonása: Az erőforrás igények hullámzása csökkenthető, ha a kulcsemberek, a „kemény mag” nem csak projektek dolgozik, illetve ha nem csak 5 projekten.

Az előbbi szerint a projektmunkát összevonják más feladatokkal, pl a napi támogatással, tehát amikor sok a projekt, akkor az emberek inkább azon dolgoznak, amikor pedig kevés, akkor support ügyeket intéznek, kódot tisztítanak, korábban félretett ügyeket húznak elő.
A másik módszer szerint a projekteket vivő csapatokat vonjuk össze, tehát 5-10 projekt helyett 15-20 projekten kell dolgozni. Ettől nagyobb lesz a merítés, nagyobb a valószínűsége hogy mindig lesz munka, kisebbek lesznek a hullámok.

Szétbontani a csapatot „kulcsemberekre” és „munkásokra”: A tudást meg akarjuk tartani, ezért azonosítani kell, hogy ez a tudás hol, kinél van. Kellenek kulcsemberek, akik folyamatosan a cégnél maradnak és megőrzik a tudást, miközben a többi projekttagot az aktuális igényeknek megfelelően alakítjuk (növeljük vagy csökkentjük a csapatot). Gondoskodni kell arról, hogy amikor a „munkások” kisétálnak az ajtón, akkor átadják a tudást a „kulcsembereknek” – akik viszont maradnak.

Árnyék erőforrások (shadow resource): Egy technika amit mi használunk, nem feltétlenül tökéletes megoldás mindenki számára. Az árnyék erőforrás olyan erőforrás, aki ugyan az account-on van és dolgozik, de nincs kiszámlázva. Tehát van mondjuk egy 5 fős fejlesztői csapat, de valójában 6-an vannak. A 6. fejlesztő nincs kiszámlázva, ő csak azért van ott hogy tanuljon.
Amikor hirtelen jön egy újabb munka, vagy egy újabb projekt, akkor ő is számlázhatóvá válik és „hivatalosan” elkezd dolgozni.

Bürokratikus akadályok: Alapvetően a projekteknek nem lenne szabad csúszni, hiszen a megrendelőnek fontos a határidő betartása. Sajnos a valóságban sokszor épp a megrendelő az, aki miatt csúszunk. Ennek csökkentésére meg lehet növelni a bürokratikus akadályokat, pl. formok kitöltésével vagy aláírások beszerzésével – amelyek leküzdésével a megrendelő bizonyítja, hogy neki tényleg fontos a projekt és tényleg mindent megtesz érte.

A projekt szponzor aláírása: Mondanom sem kell, egy projektet csakis onnantól lehet komolyan venni, hogy a projekt szponzor aláírta a projektindító dokumentumot, tehát többek között elfogadta az ütemtervet és a költségvetést.

CIO vagy IT Menedzser, mint stakeholder: Habár az ütemtervet érintő döntéseket a megrendelő hozza, de ne felejtsük el, hogy az IT Menedzser is fontos szereplője a történetnek. Akárki akármit mond, de a projekten csak akkor és addig lesznek fejlesztők, amíg az IT menedzser mondja. Ha a projekt csúszik vagy komolytalan, akkor nemet kell mondani.
(Nekünk most van egy projekt, ami nagyon csúszik -> megmondtam a megrendelő üzleti oldalnak, hogy fejlesztője csak december 31-ig lesz, és ossza be.)

Tudom, hogy nemet mondani nem egyszerű, különösen ha fejlesztésből élünk. De ahhoz, hogy a többi projektet, a többi ütemtervet tartani tudjuk, ahhoz időnként nemet kell mondani, elkerülendő a konfliktust.

Lehet, hogy akkor és ott nem fog tetszeni, de a másik oldala a történetnek az, hogy ha azt mondom, hogy LESZ erőforrás, akkor biztosra vehetik, hogy bármi áron, de meglesz. Szóval vagy rohangálok a bizonytalan célok után, vagy kemény de szavahihető vagyok.

Az IT Menedzser, mint döntéshozó: Az előző ponthoz kapcsolódóan, az IT Menedzser nem csak stakeholder, hanem jóváhagyója a projektnek. Az ilyen jóváhagyáskor elsősorban a szűk keresztmetszetet szoktam megvizsgálni, ilyen lehet a példában szereplő tesztelési erőforrás. Ha több projekt sorsa múlik ugyanazon erőforráson, akkor ott bizony komolyan el kell gondolkodni, és nem továbbengedi az egyiket.

Krízis menedzsment: Ha csúszik a projekt, akkor az önmagában egy krízishelyzet. Nem lehet automatikusan az a válasz, hogy jó akkor 1 hónappal tovább dolgozunk – hiszen a csúszás az IT-n kívül mindenki mást is ugyanúgy érint. Csúszás esetén az összes stakeholder bevonásával (IT is) új tervet kell készíteni, a tervet validálni. Ilyenkor meg kell vizsgálni az erőforrások elérhetőségét és módosítani az erőforrás tervet.

Őszinteség: Való igaz, hogy egy projekt végrehajtása során vannak váratlan események. De a jó menedzser, a jó szakember tisztában van azzal, hogy a projekt hogyan áll, mi várható a következő fél évben, mennyit fog a projekt csúszni, és mi jelenti a szűk keresztmetszetet. Ha a projekt „bizonytalan”, azaz a lefektetett ütemterv nem tartható, ha a határidőhöz közeledve hirtelen kiderül, hogy még kell pár hónap – az ott nem bizonytalanság, hanem a projekt menedzser rosszul végzi a munkáját. Két eset van: vagy az a probléma, hogy a PM-nek gőze sincs saját projektjéről, vagy hazudik – bármelyik eset is áll fenn, fenéken kell billenteni.

(Láttam már összeomló vagy sokat késő projektet – minden résztvevő pontosan tudta, hogy mi a valóság, csak senki sem merte a valóságot kommunikálni felfelé.)

Prioritás lista: Ha fennáll a lehetősége, hogy a projektek egymás lábát tapossák és szűk keresztmetszet lép fel, akkor célszerű felállítani egy prioritás listát a projektek között. Igaz, hogy mindegyik projekt, mindegyik munka fontos valakinek (a kevésbé fontosak is), de jobb tisztázni, adott helyzetben melyik munka szenvedjen hátrányt. Ezt a priorizálást az üzleti döntéshozóval kell egyeztetni, és utána ezt az egyeztetést meghivatkozni a későbbi vitákban.
Ki a megfelelő döntéshozó? Meg kell találni azt a menedzsert a megrendelő oldalon, aki a legmagasabb szinten van, és a szava az összes projektben számít.

(Nem mellesleg ez a lista és az „high level overview” egyben vezetői dashboard-ként is funkcionál, pontos és naprakész információt adva a felsővezetésnek a projektek állásáról. Normális esetben ilyennek léteznie KELL valahol.)

Békebíró: Mi a teendő, ha ugyanattól az ügyféltől több projekt is érkezik egymástól független osztályoktól, akik nem akarnak egymással beszélni? Meg kell találni a közös pontot, valakit aki az egész produkciót az összes projekttel együtt koordinálja, illetve elsimítja a vitákat. A projekteket nem külön-külön tekinteni, hanem egységes egészként, és megszervezni, hogy a megrendelőnél különböző menedzserek egymás között megegyezzenek, mi mennyire fontos.
Ha az kap erőforrást, aki a leghangosabban kiabál, akkor mindenki kiabálni és fenyegetőzni fog – pokollá téve a beszállító életét.
Amennyiben nem találni üzleti oldalon olyan embert, aki „szuper megrendelő” vagy „békebíró” lenne, akkor egyszerűen a megrendelő IT osztálya alá kell betagozódni, és ott keresni egy önkéntest a priorizálásra és a békebíró szerepre. (feltehetőleg nem fognak tiltakozni e szerep ellen)