Scope menedzsment: Hogyan mondjuk nemet?

Kővári Attila 2010. november 15.

A scope, vagy más néven a terjedelem pontos meghatározása különösen fontos az üzleti intelligencia projektek esetében. Ha nincs jól körülhatárolt scope-ja a projektnek, akkor csak a szerencsén és a projektvezetőkön múlik, hogy a projekt sikeres lesz-e vagy sem. Ezt valószínűleg már mindenki tudja. Úgyhogy most nem is erről szeretnék írni, hanem inkább arról, hogy hogyan mondjunk nemet a menet közben érkező, scope-ot érintő kérésekre.

Ezt is tegyétek még bele légyszi

A laza scope-jú projektek egyik jellemzője, hogy sokszor hangzik el a fenti mondat. Ráadásul ez sokszor olyan embertől jön, akinek nehéz nemet mondani. Nehéz mert épp ő a projekt vezetője, vagy a szponzor, vagy egy olyan prominens személy, akitől így vagy úgy de függünk mi is, és a projektünk is.

Sokszor azért is nehéz nemet mondani, mert mi is tudjuk, hogy a kérés olyan dologra irányul, ami javítana a végleges megoldáson. Javítana, mert mondjuk olyan felhasználó igényt elégítene ki, amivel egy csomó potenciális felhasználót adatpiac felhasználóvá konvertálhatnánk, vagy javítana, mert olyan folyamatot támogatna, amely régóta nincs megoldva a vállalatnál.

Egyszóval nemet mondani sokszor nehéz, de néha mégis meg kell tenni. Meg kell tenni, mert tudjuk, hogy a projekt nyúlásával egyenes arányban csökken a siker valószínűsége. Márpedig ettől félünk. Nagyon félünk. Úgyhogy az alábbiakban összeszedem, hogy hogyan mondhatunk nemet az ilyen csúszást eredményező kérésekre:

I. variáció: „Nem volt része a scope-nak, úgyhogy nem tesszük bele"

Ez olyan nagy tanácsadócéges „hamarabb kellett volna gondolkodnod öcsi" típusú válasz. Nem is szeretjük. Nélkülöz minden fajta rugalmasságot, együttérzést. Mintha nem is egy hajóban eveznénk.

Ugyanakkor azzal is tisztában kell lenni, hogy sokszor, - különösen akkor, ha ez már nem az első kérés - nincs más megoldás. A szállító egy darabig teljesíti a megrendelő minden óhaját, de egyszer el kell következnie annak az időnek, amikor álljt kell parancsolni, mert tudjuk, hogy ha ezt nem tesszük meg, akkor el fog úszni a projekt.

II. variáció: „Oké beletesszük, csak mondd meg, hogy mit vegyünk ki helyette"

Laza scope-ú projekteknél ez is ki szokta verni a biztosítékot: „Hogy-hogy mit vegyünk ki belőle?" - szokot visszajönni az értetlen kérdés.

Ez a variáció azonban már sokkal jobban védhető, mint az előző. Általában ilyenkor már a szállító is tudja, hogy hol vannak a projektben azokak az igények, amelyek kielégítése talán nem is olyan fontos, mint amilyennek a projekt indulásakor tűnt. És valahol a megrendelő is érzi, hogy igaza van a szállítónak: Ahhoz, hogy valami újat be tudjunk emelni a határidő és a költségek módisítása nélkül, valami mást ki kell venni.

III. variáció: „Ebbe a fázisba már nem fér bele, de hozzáírjuk a következő fázis feladataihoz"

Első ránézésre talán ez tűnik a legjobbnak. Lehet mögötte egy udvarias elutasítás is és lehet mögötte egy „tényleg meg fogjuk csinálni, csak támogass minket, hogy legyen következő fázis" felhang is. Ám ez is elsülhet fordítva. Előfordulhat, hogy akiknek ezt mondjuk azok elkezdik terjeszteni, hogy jön a következő fázis és hirtelen ettől lesz hangos vállalat folyosója. Ez aztán szép lassan eljut a menedzsment fülébe, akik értetlenkedve néznek majd, hogy miféle következő fázis?

Összefoglalva: Nemet mondani nehéz. Mégis sokszor meg kell tenni. Az üzleti intelligencia projektek talán legkritikusabb sikertényezője a gyors eredmény ami csak úgy tartható, ha tartjuk mangunkat az kijelölt scope-hoz és nemet momdunk ha kell.

Azt pedig már csak halkan jegyzem meg, hogy ahhoz, hogy nemet lehessen mondani az is kell, hogy legyen a projektnek egy pontosan körülhatárolt scope-ja. Ebben még tudok is segíteni ha kell. De ha nincs jól megfogalmazva a scope, akkor nincs mire nemet mondani...

Kővári Attila - BI projekt

BI & DWH projektvezető képzés

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2025. február 26.-i BI és adattárház projektvezető képzésre, vagy rendeljen kihelyezett tanfolyamot! Részletek >>

 
Már készül a következő cikk. Kérjen értesítést a megjelenéséről itt.

hozzászólás

Pajor Gábor

h, 11/15/2010 - 11:26

Sziasztok, Szerintem sohase mondjunk nemet. Különösen nem a Megrendelőnek. Sohase adjunk azonnali választ. Ezeket a kérdéseket minden esetben meg kell beszélni. Nincs kis módosítás, mert sokszor 2 perc alatt nem lehet átlátni a módosítás minden hatását, másrészt 2 perc alatt az sem fog kiderülni, hogy mire gondol a Megrendelő, mit kér pontosan? A megbeszélést minél szélesebb körűen kezeljük. Vegyenek részt benne a Megrendelő felső-vezetői is csakúgy, mint a Megbízó felső-vezetői. Ez azt jelenti, hogy több körös megbeszélésre, egyeztetésre van szükség. Először legyen technikai-technológiai egyeztetés (vezetők nélkül), pontosan tudjuk, hogy miről van szó, mi kell a megvalósításhoz (pl. specifikáció, plusz infó, stb.) annak mi a ráfordítás igénye (hw, sw, ember, szakértelem, stb.). Fentiek alapján legyen egy lehetséges ütemterve, majd egy pénzügyi terve is a módosításnak. A tervekkel lehet eszkalálni a problémát a vezetők felé, döntsenek ők! Nem ajánlom, hogy ezeket a lépéseket megspóroljuk, mert enélkül belevágni a megvalósításba a projekt sikerét veszélyezteti, és később már senkit nem fog érdekelni, hogy mi a csúszás vagy a sikertelenség oka. Én azt mondom, hogy: - türelem - körültekintés - óvakodni az azonnali ígéretektől - bármennyire is forszírozza a Megrendelő. Azt nem mondhatja, hogy a fenti lépések feleslegesek, ha mégis, akkor írásban kell tőle felszólítást kapni, amit hivatalosan is lehet eszkalálni felsőbb szintekre. Várok más ötletekre, stratégiákra is!

Molnár Miklós

szo, 11/27/2010 - 13:56

Jó a téma, jó a címválasztás! :o) * Ha már volt I.variációnak a "teljes elutasítás", akkor én hiányolnék egy olyan IV.variációt, ami kvázi "teljes megengedés", vagyis, ha "nincs közvetlen ellenérv, akkor miért ne kerüljön be a scope-ba". Azt gondolom egyfelöl létezik ökölszabály, másfelöl nem létezik ökölszabály a problémára. ;) Megpróbálok érvelni mindkét - egymással antagonisztikus - szempont mellett. Nincs ökölszabály, mert nem tudjuk milyen a beszállító-megrendelő kapcsolat. Mekkora és milyen távú a bizalom, a két fél tudása. Milyen mélységű árlefaragó versenyt kényszerített a beszállító-versenyzőkre a megrendelő. Mekkora a kockázatipuffer (anyagi, jövőbeli együttműködési, stb). Egy stabil korrekt megrendelő-beszállító viszony többet el tud viselni scope-menedzsmentileg, míg ha idegenként bemegyünk egy boltba, hogy "csak akkor veszek egy liter bort, ha kapok mellé egy másik liter ingyen bort", akkor körberöhögnek és elhajtanak, mert a boltosnak nyílván nem éri egyszeri tranzakcióban az ilyen rugalmasság (nem fog beleférni a "scope-jába"). Van ökölszabály, mert: - megrendelő sem tudhat mindent előre, azaz egyre több információhoz juthat a projekt haladtával. Az élet is rohamléptekben változik körülöttünk. Informatika az egyre kevésbé olyan, mint egy katedrális építése (amin akár generációk dolgozhattak). - informatikai projekteknél korrekt kapcsolatnál szerintem nem fillérre kicentizett a projektköltségvetés. Pont azért mert rendszerint nem a projektköltségvetés szokott rugalmas lenni, hanem a célhoz vezető út. A "teljes elutasítás" tehát kiesik, míg a "teljes megengedés" meg azért esik, egyfelöl generálni fogja az egyre nagyobb sebességre váltó scope-bővülést, másrészt exponenciális elszáll a projekt sikerének valószínűsége a nulla irányába. 1.ökölszabály teház: az élet dinamikusan változik, és alkalmazkodni kell 2.ökölszabály tehát: mederben kell tartani a scope menedzsmenetet. És mi tartaná mederben? Egyfelöl felső korlát a projekthatáridő, a projektköltségvetés, meg a projektben érintettek "elégedettségérzetének" végösszege. Másfelöl tisztában kell lenni, hogy a scope menedzsmentnek _overheadje_ van. Bármilyen scope-bővülés felemlítésének pillanatában azonnal overheadet generál. Ez a tény önmagában lassíthatja a scope-bővülés felpörgését. 3.ökölszabály tehát: minden scope-bővülés felvetésért egyfelöl _felelősséget_ kell vállalni, másfelöl dinamikus alkalmazkodási kötelezettség címén _hatásanalizist_ kell végeznie a beszállítónak (megrendelő addigra már megtette ezt, hiszen felvetette a scope-bővítést). Mennyire nő a beszállító költsége (hatásanalizis + scope-bővítés elvégzése), mennyire veszélyezteti a projekthatáridőt, projektköltségeket, mennyire befolyásolja az összelégedettségérzést, adja-e rá minden projekt-érintett az áldását a scope-bővítésre stb. 4.ökölszabály: mivel a fentiek a hatásanalizis túlspilázás esetén akár a projekt a projektbenné tudhat duzzadni, világosan látnivalónak kell lennie mind a beszállítói, mind a megrendelői projektvezetőnek (valamekkora hatásanalizis után), hogy inkább "igen" vagy inkább "nem" legyen az adott scope-bővítés és ennek megfelelően inkább "áthajtani" vagy inkább "elgáncsolni" célszerű azt. 5.ökölszabályként leszögezhető, hogy az élet nem fekete-fehér-igen-nem. Símán lehet, hogy a beszállító cégvezér jövőbeli aggódásból és szűkebb körű információkra alapozva támogatna inkább minden scope-bővítést, míg a konkrétumokkal jobban tisztában lévő terepen dolgozó projektvezető meg adott esetben inkább nem. Míg a megrendelőnél van akinek a határidő a fontosabb ezért elutasítaná inkább a scope-bővülést, és van akinek a minél tökéletesebb funkcionalitás (projekthaszon-maximalizálás) ezért inkább támogatná. Most arról már nem is beszélve, hogy az egyes résztvevők tekintélye, befolyása, tudása, eléggé különböző tud lenni.

Molnár Miklós

h, 11/29/2010 - 13:45

A nóta vége az lett, hogy a saját blogomon blogposztba torkolott a téma :o) http://liftinstinct.blogspot.com/2010/11/projektvezetes-es-scope-menedzsment.html

Új hozzászólás