Aš jums čia papasakosiu šį bei tą labai paprasto, bet sunkiai suvokiamo apie kai kokius projektų valdymo niuansus, nes visi žino, kad stebuklų nebūna. Ypač projektų valdyme, kur būna tik katastrofos. Bet gal pirmiausiai apie realybę. Žodžiu, yra toksai vadybinis dviejų trečiųjų dėsnis, plačiausiai žinomas iš vieno puikaus ir seno žydiško anekdoto.
Ateina klientas pas geriausią miesto siuvėją:
– Norėčiau pas jus užsisakyti kostiumą, nes visi sako, kad jūs ir greitai mokate siūti, ir pigiai, ir kokybiškai…
– Žinoma, kad taip. Galiu ir greitai, ir pigiai, ir kokybiškai. Kuriuos du iš šitų trijų norų renkatės?
Išties tai yra tiesiog projektų valdymo reikalavimai – „on time, on budget, on scope“ arba OTOBOS, tik kitaip išreikštas: ar laiku, ar už priimtiną (sutartą) kainą ir ar viskas bus suteikta taip, kaip klientas nori. Protingi ir sąmoningi kriterijai, tiesa?
Deja, labai jau dažnai, o tiksliau, praktiškai visada būna taip, kad bedarant bet kokį projektą, tenka rinktis, kurį reikalavimą paaukoti vardan kitų. T.y., kurį trečdalį atmesti. Priežasčių labai daug, pradedant kliento durnumu (kai tikimasi pirkti mersedesą už zapuko kainą, nes tipo esą zapukas juk mašina, o mersas irgi mašina, tai kainuoti turi vienodai) ir baigiant labai paplitusiu įvairių pardavėjų įpročiu klientams žadėti aukso kalnus, kad tik jie pirktų, o ar vykdytojai sugebės tai padaryti – visiškai nesvarbu.
Su patirtimi projektų vadovai įsisamonina vieną dalyką: nėra tokio projekto, kuris negalėtų baigtis bloguoju. Ir skirtingai nei kokiam balete, išsitėškusiam projektų vadovui publika neplos.
Aišku, neretai įmanoma suvaldyti šitus reikalus, nes dažniausiai pardavėjui galima įkalti į galvą, o klientui išaiškinti, kad tas dviejų trečiųjų dėsnis yra visai ne anekdotinis. Galima suvaldyti tai ir kitaip, užtikrinant visokius reikalavimus, įvedant kainos paskaičiavimo metodikas ir panašiai. Daugelis projektų vadovų bando visaip gudriai balansuoti ir kažkaip įvykdyti viską, dėl to prikuria ir visokių metodologijų. Bet tai veikia ne visada.
Su programine įranga, deja, suvaldyti projektų dažniausiai nepavyksta (juk ne veltui IT laikoma bene sunkiausiai suvaldoma veiklos rūšimi). Kur tik atsiranda projektai, susiję su tikslingai klientui kuriamais programinės įrangos sprendimais, kažkodėl labai jau dažnai vietoje dviejų trečiųjų ima veikti vienos trečiosios dėsnis*. Nelaimingam klientui lieka tik tokie variantai:
- Gauti programinę įrangą, kuri daro daugmaž tai, ką reikia, bet projektas užtrunka krūvą metų ir ne tik nepavyksta jo sutrumpinti, bet terminai persikeldinėja krūvą kartų, o viskas ima veikti tik nuo trečios versijos**, o negana to, dar ir atsieina krūvą tiesioginių ar netiesioginių išlaidų, kurios paaiškėja besančios dešimtis kartų didesnėmis, nei tikėtasi.
- Gauti programinę įrangą laiku, bet ji būna visiškai neadekvati, daro tai ko nereikia, nedaro to, ko reikia ir negana to, kainuoja baisius pinigus. Kitaip tariant, beperkant klientui atrodo, kad jis gaus kažką naudingo, o nusipirkus paaiškėja, kad arba tas daiktas daro visai ką kitą, arba išvis neaišku, ką jis išvis daro.
- Gauti programinę įrangą pigiai, bet ji visvien atsiranda pavėluotai ir būna neadekvati: tiekimo terminai vėluoja neįsivaizduojamai, tiekėjas kažkodėl tempia gumą, per kelias dienas turėję įvykti dalykai tęsiasi kažkiek savaičių, paskui ir mėnesių, o galų gale netgi metų, o galutinis rezultatas – artimas nuliui, nes galų gale tasai daiktas pasirodo besąs niekam netinkamu.
Būdinga, kad visi tokie vienos trečiosios atvejai labai paplitę. Dargi tiek smarkiai, kad apie dviejų trečiųjų atvejus išgirsti pasitaiko pakankamai retai, kad jie atrodytų lyg neįtikėtina sėkmė, l visi šitie tragiški vienos trečiosios atvejai atrodo kaip kažkas visai normalaus. Bet jei pasižiūri į tai, kaip viskas vyksta realybėje, pasidaro aišku, kad kažko kito tikėtis dažniausiai net ir nevertėtų. Nebent išmoksite daryti stebuklus.
