Projektvezetés és scope-menedzsment

A minap egy igen érdekes post jelent meg a BiProjekt blogon Scope menedzsment: Hogyan mondjuk nemet? címmel. A téma szerintem nagyon jó, sőt hirtelen felindulásból még egy hosszabb kommentet is elkövettem ott. Aludva a történtekre, és ugyan továbbra is blogkeretek között maradva, de azért szeretném tágabb kontextusba helyezni az ott vázolt gondolatmenetemet.

Mielött a scope-menedzsmentre térnék, a vonatkozó tárgybeli tágabb kontextusú adatbányász vénájú "modellezésem" veleje, hogy érdemes lehet a projektvezetést egy speciális 2x2 mátrix mentén vizsgálni.

Az egyik "vízválasztó", hogy a projektvezető analizisorientált-e avagy koncepció/intuicióorientált-e.
(1)Az előbbi számolni szeret, számokhoz, tényekhez, objektív információkhoz keres magyarázatot, érveket, érzelmet/támogatást.Az utóbbi intuiciót, inegzakt ám releváns fogódzókat próbál meg számokkal, érvekkel alátámasztani.
(2) Az előbbi legfőbb hibaforrási lehetősége a számokban, részletekben való elveszés (egy lehetséges potenciális adatbányász-analógiával, "túltanulás"). Az utóbbinak az elfogultság, rugalmatlanság kockázata. Senki sem szereti ugyanis az intuicióit pillanatonként vizsgálatnak alávetni, vagy pláne ennek nyomán permanensen kételkedni.
(3) Érezhető, hogy egyik 100% vegytiszta állapot sem az igazi. Nehéz egzaktul és pontosan számokba önteni az élet történéseit, előbb-utóbb korlátokba kell ütköznünk, amikor teret követel magának az intuició. Az intuició is bizonyíthatóan és mérhetően nagyon hasznos, de egy határon túl már inkább lutri, és analizis nékül kuruzslásba csaphat át az egész. Tulajdonképpen vélhető módon csak prioritást állít fel a projektvezető alkata, miszerint analizisből tart az intuició felé, avagy megfordítva.

A másik vízválasztó, hogy mi a célfüggvény. Vagyis a saját avagy a közös profit maximalizálása-e a cél. Símán meglehet, hogy különvéleményen vagyok, de ez szerintem (1) releváns kérdés, (2) valószínűsíthető a különbözőség (nem esnek egybe).

Durva példaként említeném a Microsoftot és desktop operációs rendszereit. Az nem kérdés, hogy Microsoft jó nagy profittal rendelkezik, meg vezére sok-sok évig a világ leggazdagabb embere volt. Az viszont egy másik kérdés, hogy fizető vásárlói mennyire elégedettek, mennyi hasznot termelt nekik a Microsoft-elkötelezettség, milyen költség mellett.Nem mindegy, hogy a termék sikeres-e, avagy konszenzusosan jó-e.

További példa lehet, hogy egy alkalmazott mennyire nézi a kenyéradó cége céljait, ha saját céljai kerülnek fókuszba, Vagy mennyire triviális egy olyan beszállítói gondolatmenet, hogy bár hasznom és bevételem lenne egy projektből, de azért nem csinálom meg, mert a megrendelőmnek nem vagy nem eléggé hasznos. Az adatbányászatban ez a kérdés különösen élesen merül fel. Korábban már említettem itt a blogon ("nagy kihívásoknál"), hogy nézetem szerint nem az a "májer" adatbányászatban, aki a legnagyobbat kaszál a megrendelőjén, hanem az, aki a megrendelőjénél a legnagyobb profitot tudja felmutatni, konstans költség mellett. Kár, hogy ehhez sem a megrendelői visszamérés nem gyakorlat, sem objektív referencia nincs a beszállító-versenyzőkre.

Na és ezek után rátérhetünk a scope-menedzsmentre.

Talán konszenzus van abban, hogy általános érvényű igazságot lehetetlenség mondani (informatikában), hogy egy scope-bővítési kérelemre "igen"-t avagy "nem"-et érdemes mondani. Túl sok - egyenként, különállóan is fontos - tényező befolyásolhatja az optimális választ.
- Milyen a beszállító-megrendelő kapcsolat?
- Mekkora (milyen hatáskörű) a bizalom, a tudás, a tekintély, a befolyás a résztvevők/érintettek körében?
- Milyen mélységű árlefaragó versenyt kényszerített a beszállító-versenyzőkre a megrendelő? (Kedvezmények halmozását szinte sehol a világon nem szokás támogatni)
- Mekkora az anyagi kockázatipuffer/-tartalék?
- Mekkora jövőbeli perspektíva vélt vagy valós kényszerítő ereje?
- Stb.

Ezzel együtt is pár ökölszabály talán mégis megfogalmazható:

* Nem egészséges a "teljes elutasítás" álláspontja.
- 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.
- Az informatika is egyre kevésbé olyan, mint egy katedrális építése (amin akár generációk dolgozhattak).
- Informatikai projekteknél jó eséllyel 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 projektcélhoz vezető út.
(Példa: 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)

* Nem egészséges a "teljes megengedés álláspontja (pusztán csak azon az alapon, hogy nincs ellenérv a scope-bővítés ellen).
- egyfelöl "felhívás a keringőre" alapon egyre nagyobb sebességűre váltha scope-bővülési kérelmek generálódása
- másrészt exponenciálisan szállhat el a projekt sikerének valószínűsége a nulla irányába.

* Az élet dinamikusan változik, és alkalmazkodni kell. Szükséges tehát a mederben tartott scope-menedzsment.
- 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, implementálás nélkül is és legyen neki bármekkora potenciális haszna is. Ez a tény önmagában lassíthatja a scope-bővülés felpörgését, önmagában jelent korlátot.

* 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 célszerű végeznie a beszállítónak (megrendelő vélhetőleg addigra már megtette ezt, hiszen felvetette a scope-bővítést). 
- Mekkora a haszon, 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.

* A hatásanalizis (legyen számolás- avagy intuicióorientált), remek terepe mind megrendelői, mind beszálíltói oldalról egy bővítési kérelem támogatásának avagy elutasításának.Viszont vélhetően nem megúszható (valamilyen formában, mértékben).

* 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á.