Azt fejlesszük le amit kértek, vagy azt amit szeretnének?

Egy átlagos, rövidhatáridős, fixáras BI projekt menetrendje a következő: A megrendelő kiír egy BI tendert, rábízza valamelyik kollegára az ajánlati felhívás kidolgozását, amit aztán kiküld a potenciális szállítóknak hogy adjanak rá ajánlatot. A szállító kivonul, kérdéseket tesz fel és a válaszok illetve az ajánlati felhívás alapján elkészíti az ajánlatot. Sokszor úgy, hogy csak sejti mit kell megcsinálnia. Konkrétumokat nem ismer, buktatókat nem látja csak a megérzései és tapasztalatai alapján becsüli meg az előtte álló munka nagyságát.

Jó ez így? Nem. Ágálhatunk ellene, hogy nem így kéne csinálni. Sőt! Tudjuk, hogy nem így kéne csinálni, tanítjuk is hogy nem így kell csinálni, de sokszor nincs rá lehetőség, hogy máshogy csináljuk. Így hát belevágunk bízva abban, hogy a tapasztalati úton meghatározott ajánlati ár fedezetet nyújt majd azon igények lefejlesztésére, amelyek csak az igényfelmérések során kerülnek majd felszínre.

Eljön az igényfelmérések ideje és felszínre kerülnek olyan igények is, amelyek nem szerepeltek az ajánlati felhívásban. Jó lenne, ha ilyenkor újraírhatnánk az ajánlatot belekalkulálva az ajánlati felhívásból kimaradt vagy ki nem hangsúlyozott igények megvalósítását, de sajnos az esetek többségében ez nem lehetséges. Marad a dilemma: Azt csináljuk meg amit a megrendelő kért vagy azt amit szeretne?

Nehéz döntés, mert tudjuk hogy az lenne jobb amit szeretne, de szorít a határidő és a rendelkezésre álló büdzsé is. Arról korábban már írtam, hogy hogyan mondjunk nemet, úgyhogy most beszéljünk arról is egy kicsit, hogyha igent mondunk, azt hogyan tegyük.

Ha ugyanis igent mondunk és bevállaljuk hogy megcsináljuk, akkor később már nem lesz módunk visszakozni. Nehezen tudjuk azt mondani, hogy mégsem csináljuk meg. Meg kell csinálni, mert mindenki elkönyvelte hogy meg fogjuk csinálni. Hónapokkal az igényfelmérés után pedig már senki sem fog emlékezni rá, hogy ez nem volt része az eredeti scope-nak. Úgyhogy a határozott igennel nagyon kell vigyázni

Ha azonban azt kommunikáljuk, hogy

„minden tőlünk telhetőt meg fogunk tenni azért, hogy a [.....]-ot is megvalósítsuk jelen projekt terjedelmén belül"

akkor ebben benne van az is hogy szeretnénk megvalósítani azt amit a megrendelő szeretne, de finoman benne van az is, hogy ez nem volt része az eredeti scope-nak. Ha megvalósul annak örülünk, de ha nem akkor tudomásul vesszük, hogy most nem fért bele.

Megj.: Érdekes, de ha a fenti helyett azt mondjuk hogy

„meg fogjuk csinálni, ha marad rá időnk"

akkor az nagy valószínűséggel ki fogja verni a biztosítékot. "Hogy hogy ha marad rá időnk?" Ugyanakkor

„a megcsináljuk, ha úgy látjuk hogy nem veszélyezteti a határidőt"

típusú igen viszont már könnyebben átmegy. A határidő tartása a megrendelő érdeke is és a szállító is könnyen tud érveket felsorakoztatni mellette, hiszen a határidő büntetlen túllépéséhez módosítani kéne a szerződést...

Az elkészített műszaki megoldás szempontjából persze mindegy, hogy hogyan kommunikálunk. Az pont olyan lesz akkor is, ha lehetőségként kommunikáljuk és akkor is ha ígéretként. A projekt szempontjából azonban nagyon nem mindegy. Óriási különbség van a között, ha egy ígéret nem valósul meg és a között, hogy egy lehetőség. Még akkor is, ha az átadott műszaki megoldás ugyanaz...

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 2024. szeptember 25.-i BI és adattárház projektvezető képzésre, vagy rendeljen kihelyezett tanfolyamot! Részletek >>

 

hozzászólás

A projekt sikere jelentős részben az elvárások menedzsmentjétől függ. Az aki értékelni fogja a projekt eredményeit gyakran nem ismeri az ajánlati felhívást részleteiben sőt lehet az érintett témával kapcsolatban is csak elnagyolt elképzelésekkel rendelkezik. Ezért ha a szállító sikeres akar lenni a kíváló műszaki tartalom leszállítása mellett a kezdetektől fogva fel kell mérnie és egyengetnie kell a megoldással szemben támasztott elvárásokat és elképzeléseket. Ez érthető is, hiszen szakértelménél fogva a szállítónak kell tudnia, hogy adott erőforrásokból és környezetben milyen megoldások születhetnek. Összefoglalva a projekt egyik sikertényezője a megfelelő kommunikáció, ahogy azt Attila ki is fejtette ebben és előző cikkeiben is. Tanulság a szállítónak, hogy tervezze be az erre fordítandó tetemes időt projektjébe, hiszen megítélése jelentős részben ettől fog függni.

Szívesen olvasnék valamit a fordított felállásról is. Az világos, hogyan kerülje ki a beszállító az ezt-is-tegyük-még-bele csapdákat, de mit tehet a megrendelő, hogy a beszállítót a menetrend minél pontosabb betartására ösztökélje? :)

Ha a fonákjáról nem is, de "középről" tudok nyilatkozni. Lassan túl vagyunk egy rendszer bevezetésen a cégnél, ami jan. 1-re volt határidős. Nekem és kollégáimnak volt a feladata az igényeket összeállítani, és az ajánlatokat begyűjteni. Persze a nyertes kilétét már nem tudtuk befolyásolni. Mivel mi vagyunk a cég informatikai háttere, ezért az igényeit mi ismerjük a legjobban, ennek megfelelően elég jól sikerült összeállítani a követelményeket, persze nem 100%-osan, de több, mint 90. A nyertes pedig, amint arra számítani lehetett, a legolcsóbb lett. Ez a lehető legrosszabb választás volt (bár ez csak tipp, a többiekkel ne dolgoztunk). Hiába volt biztosítva az erőforrás, az infrastruktúra, a hozzá nem értésük elavult, sok esetben használhatatlan megoldásokat szült.

A megrendelőnek viszonylag kevés lehetősége van annak biztosítására, hogy a szállító tartsa az ütemtervet, de azért vannak eszközei. Ezek egyfelől jogi típusúak, mint például a kötbér vagy a jólteljesítési garancia, amit kapásból érvényesíteni lehet az egyes mérföldkövek elcsúszása esetén. Persze ha ezek nem lettek jól megfogalmazva a szerződés kötésekor, akkor ezekkel az eszközökkel nem igazán tudunk élni. Marad az, hogy megpróbáljuk a szállítót minél jobban kiszolgálni: Folyamatosan böködjük a felhasználókat, hogy tessék tesztelni, tessék időben válaszolni a szállító kérdéseire, kéréseire, stb. Féken tartjuk a felhasználók igényeit, vagy ahogy Ambrus fogalmazta meg helyesen az előző hozzászólásban: menedzseljük az elvárásaikat. IT-s ként pedig biztosítjuk az infrastruktúrát a hatékony munkavégzéshez. Ezek általában segítenek, ha a szállító rendelkezik a szükséges kompetenciával és erőforrással. Ha azonban ez nincs így, akkor a jogi eszközökön kívül nem igazán tudunk máshoz nyúlni. Sajnos.

Erről két dolog jutott eszembe. Az egyik az, hogy egy BI vagy adattárház projekt esetén talán az egyik legfontosabb tényező az ember maga. Az architekt, a fejlesztő, a tanácsadó és mindazok, akik részt vesznek a projekten. Sokszor tapasztalom – akár megrendelő, akár szállító oldalról, hogy a céget, annak referenciáit, pénzügyi helyzetét, mérlegfőösszegét és eredményét 3 évre visszamenőleg kiértékelik, de az emberekkel, - akik a projektet megvalósítják - már nem foglalkoznak. Elhiszik, elhisszük, hogy van kollektív tudás a cégben és ezt értékelik ki ahelyett, hogy a projekten részt vevő (!) személyeket értékelnék ki. Sajnos erre a közbeszerzés rátesz még egy lapáttal azzal, hogy a személyekkel kapcsolatban előírja, hogy azok felkészültsége döntési kritérium nem lehet. A minimum feltételek között felsorolhatjuk, hogy milyen képességgel kell rendelkeznie a nyertes ajánlattevőnek, de az értékelni nem értékelhetjük őket. A másik pedig a legolcsóbb ajánlat esete. Ezzel kapcsolatban az a tapasztalat, hogy sajnos hiába fogalmazzuk meg egzaktul az ajánlati felhívást, hiába írjuk le pontosan hogy mit kell megvalósítani – ahogy valószínűleg Ti is tettétek , mindig lesz aki félreérti a feladatot vagy elegendő tapasztalat hiányában alulbecsüli a munka nagyságát. Épp ezért nagyon kell vigyázni a kiértékelés módszerének meghatározásakor az ajánlati ár súlyára. Különösen közbeszerzés esetén. Nehogy úgy járjunk, hogy a legolcsóbb szállítót kelljen választanunk még akkor is, ha tudjuk (vagy sejtjük), hogy nem rendelkezik elegendő kompetenciával. És nem szabad a mögé bújnunk, hogy „Majd jól megkötbérezzük ha nem teljesít” mert ez nem segít se rajtunk, se a projekt sikerén.

Új hozzászólás