Nem párkapcsolati terápiáról, a férfi-nő viszonyának boncolgatásáról szeretnék írni, hanem a tipikus ügyfélről. Arról, aki elképzel valamit, le is specifikálja, el is készül a mű, de valahogy az átadás környékén - már ha van egyáltalán - mégsem őszinte a mosolya. A szája szegletében ott van egy keserű vonás: ő nem pont erre gondolt. A specifikáció számít vagy az eredmény használhatósága? Örök dilemma. Egy projektvezető esetén majdnem olyan fontos kérdés, mint a lenni vagy nem lenni.
Tételezzük fel, hogy valamilyen módon megszületett egy, az ügyfél által is ismert és esetleg jóváhagyott specifikáció. (Az is megér egy misét, hogy mit is jelent végső soron a jóváhagyás, miért van a kék színű tintának komoly pszichés és perdöntő ereje, erről majd talán egy külön bejegyzésben.)
Szóval létrejött egy specifikáció, amit meg kell valósítani. Akkor jutunk a pénzünkhöz és érezzük úgy, hogy sikerrel zártuk a projektet, ha megcsináljuk a specifikációban foglaltakat, az ügyfél pedig értelemszerűen átveszi az elkészült eredményterméket, hiszen a specifikációt ő hagyta jóvá. Elvileg tiszta ügy. Valahogy a gyakorlatban mégsem így működik. Nagyon ritka az a klasszikus eset, amikor betűről-betűre pontosan az készül el, ami korábban – jó pár hónappal azelőtt – leírásra került. De mi ennek az oka és egyátalán: hogyan lehet kezelni ezt a szituációt?
Kezdjük a miérttel. A sok éves, számos különböző projektből vett tapasztalatunk az, hogy az ügyfelek sajnálatos módon korlátozottan alkalmasak arra, hogy összeszedjék, rendszerezzék és végül a szállítónak megmondják, hogy milyen rendszert is szeretnének. Szép példája ennek, mikor egy nagy multinacionális cég vezérigazgatója abban a 3 percben, mikor épen volt ezzel ideje foglalkozni a vezetői információs rendszer számára fontos riportját a következőképp definiálta: „Férjen rá egy A4-es lapra és tükrözze hűen a vállalat helyzetét! Viszontlátásra.” Erre varrjunk gombot, ahogy mondani szokás.
Ha belegondolunk, nem csoda, mindenki nyakig a saját munkájában, fogalma sincs mit csinálnak a kollégák a szomszéd szobában, se ideje, se energiája leülni és végiggondolni akár a saját igényeit, és akkor még a teljes rendszerről nem is beszéltünk. Gondoljunk arra, ahogy házat építünk. Meg tudjuk mondani pontosan előre, hogy a konyhában hol lesz a villanykapcsoló, hogy a fürdőszoba szellőzése tényleg megoldott-e, biztos fa nyílászárók lesznek és nem műanyagok? Nyilván nem. Egy szintig látjuk, de teljes részletezettséggel biztosan nem. És akkor még nem számoltunk azzal, hogy a feleségünk mégis inkább megcserélné a fürdőszobát a konyhával, illetve a magas talajvíz szint miatt speciális szigetelés kell a szerelőaknába.
Legalább két oka van a specifikáció (igények) folyamatos változásának: egyrészt lehetetlen ezt teljes részletezettséggel megmondani az elképzelések kialakulásának idején, másrészt változnak a körülmények, a projektben résztvevő vagy épp a döntéshozó személyek, prioritások. Egy féléves-éves projekt esetén egészen bizonyosan így van. Az eredmény tehát majdnem biztosan az lesz – és ezzel nem árt, ha a projekt legelején komolyan számolunk! -, hogy az ügyféligény akár kimondva, akár hallgatólagosan változik, valahogy a helyzetet mégis kezelni kell.
Erős adminisztrációval és projektkultúrával rendelkező projektszervezet esetében van erre hivatalos eljárás (Change Request Process), van fóruma, többé-kevésbé bevett gyakorlatok: elindul a játszadozás a ráfordításokkal, a függőségekkel, a funkciókkal. Kihagyom ezt, de helyette szeretném azt, ráadásul két héttel előbb. Biztos, hogy minden projektvezető találkozott már ezzel a gyakorlatban. Nem egyszerű, de végül is menedzselhető, csupán az a titka, hogy nagyon komolyan kell venni a ráfordítás becsléseket és a függőségek nyilvántartását.
Ennél egy fokkal nehezebb a helyzet, ha az ügyfél nem vállalja fel a változtatási igényt – nagy szervezetben tipikus helyzet és számtalan oka lehet – csak érezzük, hogy ez így nem lesz jó. Mit valósítsunk meg? Ami le van írva papírra és amire rákerült az a bizonyos perdöntő kék színű szignó, vagy azt, ami az ügyfél fejében van (és amiről esetleg mi is úgy gondoljuk, hogy talán az lenne az ésszerűbb)?
Az első esetben nagy valósszínűséggel az ügyfél kifizeti a projektdíjat, bár maga a rendszer nem lesz jól használható. A második esetben az ügyfél ugyan elégedett lesz az eredménnyel, de elszámolási gondok lehetnek, különösen akkor, ha más a két szereplő: az első például egy üzleti terület, a második meg a projektiroda. Hogyan kerüljünk ki ebből a kutyaszorítóból? Azt gondolom a kulcsszó a kooperáció. Tisztában kell lennünk azzal az alapvető ténnyel, hogy ügyfelünk jóváhagyása nélkül nem térhetünk el az írásban egyeztetett specifikációtól. Legalább projektvezetői szinten szükséges az egyetértés, egy cinkos összehunyorítás, minimum a megrendelő oldali PM támogatását kell bírnunk, de még jobb a helyzet, ha a megrendelő valamelyik döntéshozó személye is „a csapatban van”. Ezzel természetesen vállaljuk a teljesítés elfogadásának kockázatát, de azt gondolom, hogy egy, a végeredménnyel alapvetően elégedett ügyfelet utólag rávenni a változtatások elfogadására nagyságrendileg könnyebb feladat, mint egy elégedetlen vagy netán ideges ügyfélnek elmagyarázni, hogy de hát mi pontosan azt csináltuk, amit ti akartatok.
Summa summárum én azt gondolom, , hogy a szállítói felelősségbe igenis beletartozik az ügyfél fejével történő gondolkozás, az előrelátás, a jóindulatú befolyásolás („vezessük a kezét, amikor a specifikációt írja”) még akkor is, papíron nem pont erre szerződtünk: a projekt sikeressé tétele kell, hogy a végső célunk legyen, és ennek a fentiek elengedhetetlen előfeltételei.