Viena iš opiausių IT projektų problemų yra neplanuotai didėjantys projektų biudžetai ir vėlavimas. Užsakovai bando apsisaugoti fiksuotos kainos sutartimis bei baudomis už vėlavimą. Vykdytojai – išvengti apimties didėjimo tobulindami reikalavimų pasikeitimų valdymą, reikalaudami papildomo laiko ir apmokėjimo pakeitimams atlikti. Norėdami kovoti su šiomis problemomis, turime suprasti ir pašalinti jos priežastis.
Viena iš opiausių IT projektų problemų yra neplanuotai didėjantys projektų biudžetai ir vėlavimas. Užsakovai bando apsisaugoti fiksuotos kainos sutartimis bei baudomis už vėlavimą. Vykdytojai bando išvengti apimties didėjimo tobulindami reikalavimų pasikeitimų valdymą, reikalaudami papildomo laiko ir apmokėjimo pakeitimams atlikti.
Deja šios priemonės dažniausiai problemos neišsprendžia, bet padidina užsakovo ir vykdytojo konfrontaciją. Norėdami kovoti su projektų trukmės ir biudžeto didėjimo problema, turime suprasti ir pašalinti jos priežastis.
Bet kuris projektas turėtų prasidėti nuo projekto apibrėžimo
Pagrindinis IT projekto vadovo tikslas yra užtikrinti suformuotos projekto komandos darbą ir įtraukti į projekto vykdymą užsakovą, vartotojus ir kitus susijusius asmenis. Šio tikslo yra siekiama visose pagrindinėse projekto valdymo veiklose.
Pradiniame projekto apibrėžimo etape projekto vadovas sukuria projekto vykdymo aplinką, palankią visiems projekto dalyviams dirbti vienoje komandoje:
- sudaromas projekto dalyvių sąrašas ir įvertinamos jų rolės projekte, apibrėžiami sutartiniai įsipareigojimai,
- išsiaiškinami projekto dalyvių lūkesčiai, turintys įtakos formuluojant projekto tikslus,
- įvertinama projekto apimtis: apibrėžiamas galutinis laukiamas rezultatas bei tarpiniai darbo produktai,
- pateikiami pradiniai biudžeto ir tvarkaraščio pasiūlymai,
- pasirašoma sutartis.
Vėliau projekto vadovas parengia detalų projekto planą:
- tiksliai įvertinama projekto apimtis,
- parengiamas detalus užduočių aprašymas ir jų vykdymo planas,
- suplanuojami projekto resursai.
Vykdant projektą projekto vadovas ne tik kontroliuoja projekto komandos darbą, tikrina, kaip laikomasi suplanuoto tvarkaraščio, bet ir informuoja užsakovą apie projekto eigą, seka užsakovo poreikių keitimąsi, pateikia pasiūlymus ir įvertinimus, kaip optimaliai integruoti pasikeitusiu reikalavimus į vykdomą projektą.
|
Paprastai iki sutarties pasirašymo neatliekama detali projekto dalyvių analizė, neskiriama laiko projekto tikslams suformuluoti. Vykdytojas dažniausiai nenori investuoti laiko ir pastangų iki sutarties patvirtinimo. Statistikos duomenimis tik vienas iš 10 preliminarių pasiūlymų yra baigiami sutartimi. Užsakovas kreipęsis į keletą vykdytojų taip pat neskiria lėšų ir laiko projekto apibrėžimo darbams su kiekvienu potencialiu vykdytoju. Sutartis dažniausiai yra pasirašoma atlikus labai paviršutinišką analizę ir susipažinus su užsakovo pateiktais pirminiais vartotojo poreikiais. Užsakovas ir vykdytojas pasirašydami sutartį turėtų įvertinti, kad pateikti kainos ir trukmės vertinimai yra preliminarūs, ir numatyti kaip bus valdoma apimties, kainos bei trukmės kitimo rizika. |
|---|
Ilgalaikė IT projektų patirtis rodo, kad fiksuotos projekto trukmės ir apimties įvertinimas neturint profesionaliai išanalizuotų ir suformuluotų reikalavimų yra vienas iš pagrindinių IT projektų rizikos šaltinių, sukeliantis projekto biudžeto viršijimo ir trukmės pailgėjimo rizikas. Trumpai apžvelgsiu iš kur kyla ši rizika ir kaip reikėtų ją valdyti.
Pirmoji problema, su kuria susiduria projekto vadovas ir projekto užsakovas yra nesutarimas dėl projekto pradžioje atliekamo projekto apimties įvertinimo tikslumo.
Vertinimo metodikos apibrėžia tris įvertinimo tikslumo lygius:
- pirminį spėjimą,
- preliminarų įvertinimą,
- tikslų įvertinimą.
Priminis spėjimas yra naudojamas kaip priemonė pasiūlymų atrankai, o preliminarus įvertinimas ir tikslus įvertinimas yra naudojami apimties įvertinimui projekto eigoje.
Preliminarus įvertinimas pagrįstas vartotojo poreikių analize ir statistine informacija apie panašių projektų apimtį. Lietuvoje nėra išsamios IT projektų statistikos, todėl IT kompanijos priverstos vadovautis tik savo patirtimi. Kai statistinė informacija nekaupiama įmonės viduje – lieka pasikliauti tik projekto vadovo patirtimi. Dėl šių priežasčių preliminarių įvertinimų patikimumas Lietuvoje yra sunkiai prognozuojamas ir mažai patikimas.
Tiksliam projekto įvertinimui reikia:
- parengti IT sistemos reikalavimus pagal turimus vartotojo poreikius,
- paruošti užduočių sąrašą ir įvertinti kiekvienos užduoties apimtį.
Kai reikalavimai parengti korektiškai – įvertinimo tikslumas siekia 90 procentų. Tačiau vartotojo poreikių analizė ir sistemos reikalavimų parengimas paprastai užima 20–30 procentų viso IT projekto laiko, todėl atlikti šį darbą per preliminarų sutarties sąlygų aptarimą yra neįmanoma.
Užsakovai siekdami kuo tiksliau suplanuoti projekto biudžetą ir trukmę pageidauja sudaryti fiksuotos kainos kontraktus. Sutartyje nurodytą projekto apimtį jie traktuoja kaip tikslų projekto apimties įvertinimą. Tuo tarpu projekto vadovas ir vykdytojas, turėdamas tik pirminius vartotojo poreikius, pačiu geriausiu atveju gali pateikti tik preliminarų projekto apimties įvertinimą. Dėl šio užsakovo ir vykdytojo nesusikalbėjimo projekto biudžetas ir detalus projekto planas ruošiamas pagal preliminarų (netikslų) įvertinimą. Toks biudžetas ir tvarkaraštis yra vadinamas nerealistiniu.
Barry Boehm'o, vieno iš programinės įrangos rizikų valdymo pradininkų vertinimu, būtent nerealistiniai biudžetai ir tvarkaraščiai yra antroji priežastis pagal dažnį ir svarbą 10 svarbiausių programinės įrangos rizikų sąraše. Jie turinti įtakos ne tik projekto vėlavimui ir biudžeto augimui, bei ir su tuo susijusiam IT projekto žlugimui.
Pagrindinė programinės įrangos projekto vadovo užduotis – identifikuoti šią, netikslaus apimties įvertinimo riziką, supažindinti užsakovą ir pateikti rizikos valdymo pasiūlymus.
Praktikoje dažniausiai taikomi du pagrindiniai netikslaus apimties įvertinimo rizikos valdymo būdai:
- Valandinio įkainio kontraktai. Esant neaiškiems reikalavimams projekto biudžetas ir trukmė apibrėžiami labai abstrakčiai ir užsakovas moka vykdytojui už darbo laiką pagal sutartą valandinį įkainį. Tokiuose kontraktuose užsakovas dažniausiai skiria projekto vadovą, kuris planuoja ir kontroliuoja projekto komandos darbą.
- Fazinis apimties įvertinimas fiksuotos kainos kontraktuose. Projekto pradžioje projekto vadovas pateikia preliminarų apimties įvertinimą visam projektui ir tikslų įvertinimą artimiausiai fazei. Po kiekvienos fazės patikslinamas preliminarus įvertinimas likusiai projekto daliai ir pateikiamas tikslus būsimos fazės įvertinimas. Klasikinis programinės įrangos kūrimo projekto fazinio įvertinimo pavyzdys pateiktas 1 paveiksle.
1 pav. Fazinio įvertinimo pavyzdys programinės įrangos projektui.
Programinės įrangos užsakovas turi atsižvelgti į tai, kokia informacija disponuoja projekto vadovas konkrečiame projekto etape, realistiškai vertinti projekto vadovo galimybes pateikti tikslius įvertinimus ir pasirinkti jam priimtinus netikslaus įvertinimo rizikos valdymo būdus.
Kita, aktuali apimties įvertinimo problema yra įvertinimo patikimumas. Nėra paslaptis, kad užsakovai, pateikę pirkimo pasiūlymus keletui potencialių vykdytojų gauna skirtingus preliminarius įvertinimus. Šiuo atveju, vertintojams gavus vienodą pirminę informaciją, vertinimų skirtumams turi įtakos vertintojo kvalifikacija.
Yra keletas apimties įvertinimo taisyklių, kurias privalo žinoti projekto vadovas:
Vertinimo patikimumas bus mažas, kai turimi pradiniai duomenys netinka taikomai metodikai. Pavyzdžiui projekto vadovas gauna pirminį užsakovo poreikių dokumentą, parengia užduočių sąrašą ir pritaiko tikslaus vertinimo metodiką. Gautas apimties įvertinimas yra labai netikslus, kadangi nebuvo atlikta užsakovo poreikių analizė ir programinės įrangos reikalavimų parengimas, kurio metu atrandama 30-50 proc. paslėptų reikalavimų. Deja jų įgyvendinimui nenumatytas laikas pateiktame apimties įvertinime.
Maksimalus įvertinimo tikslumas nebus pasiektas, kai pasirinkta vertinimo metodika nepakankamai panaudoja turimus pradinius duomenis. Pavyzdžiui užsakovas pateikia parengtą programinės įrangos reikalavimų dokumentą, tačiau vykdytojas, taupydamas vertinimo laiką, nedaro tikslaus apimties įvertinimo kiekvienam reikalavimui. Jis pasirenka vertinimo iš viršaus būdą ir pateikia preliminarų vertinimą, paremtą analogiškų projektų patirtimi.
Įvertinimo patikimumas priklauso nuo pradinių duomenų patikimumo. Didžioji vertinimo metodikų dalis pagrįsta statistiniais duomenimis arba iš statistinių duomenų gautomis empirinėmis formulėmis, kurių patikimumas tiesiogiai priklauso nuo turimų statistinių duomenų patikimumo. Pavyzdžiui projekto vadovo nuolatinė veikla – interneto svetainių kūrimo projektais. Iš patirties jis žino, kad tokio tipo projektuose apie 60 proc. programavimo laiko užima vartotojo sąsajos sukūrimas, o 40 proc. laiko užima serverio programavimo darbai. Vertindamas interneto pardavimų sistemos sukūrimo projektą projektų vadovas peržiūri vartojo sąsajos langus, įvertina kiek reikės laiko jų sukūrimui ir pritaikęs 40/60 paskirstymo formulę, įvertina serverio dalies programavimo laiką. Šiuo atveju įvertinimo paklaida bus didelė dėl to, kad pritaikyta paskirstymo formule netinka interneto pardavimų sistemos įvertinimui. Formulėje 40/60 neįtraukta pardavimų sistemoje reikalinga verslo logika, dėl kurios serverio programavimo laikas yra ilgesnis nei paprastos interneto svetainės.
Siekiant didesnio įvertinimo tikslumo labiau pasireiškia įvertinimą atliekančio asmens patirties ir kvalifikacijos įtaka. Preliminarų įvertinimą galima gauti panaudojus statistinių duomenų bazę ir automatizuotus įrankius. Kai atliekamas tikslus užduoties apimties įvertinimas, vertintojas privalo suprati užduotį, įvertinti jos sudėtingumą, turėti užduočiai atlikti reikalingą kvalifikaciją. Projekto vadovas tikslų vertinimui turėtų pasitelkti tinkamus žmones.
Projekto apimties įvertinimas apima ne tik projekto įgyvendinimo trukmę ir kaštus, bet ir projekto rizikos valdymo kaštus. Rizikos valdymo įvertinimas yra numatytas iš kaštų ir laiko buferio, įvertinime skirto neįtrauktoms projekto problemoms spręsti.
Projekto įvertinimas turi būti pagrįstas. Įvertinimą pateikęs projekto vadovas turi mokėti argumentuotai pagrįsti gautas darbo valandas ir kainą.
Vadovaudamasis šiomis taisyklėmis, projekto vadovas ne tik pateiks tiksliausią įvertinimą, bet ir galės argumentuotai paaiškinti užsakovui, koks yra pateikto įvertinimo tikslumas ir kodėl jis yra būtent toks. Programinės įrangos užsakovas yra pagrindinis pateikto projekto apimties įvertinimo tikrintojas. Užsakovas turi pareikalauti vertintojų ataskaitos, kaip buvo atliktas įvertinimas ir kaip įvertintos projekto rizikos. Lyginant skirtingų vykdytojų pateiktus projekto apimties įvertinimus turi būti svarstomas ne tik galutinis valandų skaičius ar kaina, bet ir pasirinktos vertinimo metodikos tinkamumas, pateikto įvertinimo patikimumas, rizikos įvertinimas. Sprendimo priėmimo procesas, kurį reiktų atlikti analizuojant skirtingų vykdytojų pateiktus įvertinimus, parodytas 2 paveiksle.
2 pav. Sprendimo priėmimo procesas renkantis projekto vykdytoją pagal pateiktus projekto apimties įvertinimus.
Projekto apimties įvertinimo tikslumas turi įtakos projekto sėkmei, todėl abu svarbiausi projekto dalyviai – projekto vadovas ir užsakovas – turi siekti maksimaliai tikslių įvertinimų. Projekto vadovas turi įgyti reikalingą kvalifikaciją tiek susipažindamas su esamomis vertinimo metodikomis, tiek ir išmokdamas jas taikyti konkrečiose situacijose. Be asmeninių projekto vadovo pastangų būtinas kompanijos vadovybės palaikymas ir užtikrinimas, kad kompanijoje būtų renkama, apdorojama ir kaupiama reikalinga statistinė informacija, įsigyjami reikalingi darbo įrankiai. Užsakovas turi kontroliuoti įvertinimo procesą, reikalauti iš vertintojo pagrįstų įvertinimo dokumentų ir turėti pakankamą kvalifikaciją pateikto įvertinimo patikimumui patikrinti.
