U složenim ICT projektima rani problem često se vidi kao trend odstupanja od plana, a ne kao propušten rok. Pomicanje ključnih aktivnosti, veći utrošak čovjek-dana, nedostupni resursi i neispunjeni preduvjeti mogu najaviti da dinamiku treba prilagoditi. Kada nekoliko projekata istodobno traži iste stručnjake, voditelji projekata, tehnički voditelji i nadležni organizacijski rukovoditelji zajednički usklađuju prioritete. I nove korisničke zahtjeve treba procijeniti prije prihvaćanja, budući da i manja izmjena može tražiti dodatni angažman ili pomaknuti povezane aktivnosti. Tada se razmatraju utjecaji na tehničko rješenje, opseg, troškove, rokove i kvalitetu, a odluku potvrđuje sponzor projekta.
Završena implementacija potvrđuje ispunjenje projektnih obveza, ali ne govori sama po sebi kakvu je korist rješenje donijelo korisniku. Poslovni učinak može se procijeniti nakon određenog razdoblja korištenja, kroz učinkovitost procesa, dostupnost sustava ili kvalitetu usluge. O ranom prepoznavanju odstupanja, usklađivanju resursa i praćenju vrijednosti nakon implementacije, ističe za ICTbusiness Media - ICTbusiness.info Veronika Petrović, voditeljica projekata u Combisovu Uredu za upravljanje projektima.
Koji su najvažniji rani pokazatelji da projekt izlazi iz ugovorenih financijskih, vremenskih ili tehničkih okvira i koji se mehanizmi primjenjuju kako bi se problem prepoznao i riješio prije nego što preraste u ozbiljnu krizu?
Najvažniji rani pokazatelj da projekt izlazi iz planiranih okvira nije samo kašnjenje, nego trend odstupanja od plana. To može biti kontinuirano pomicanje ključnih aktivnosti, veći utrošak čovjek-dana od planiranog, nedostupnost ključnih resursa, neispunjeni preduvjeti ili tehnički izazovi koji počinju utjecati na sljedeće aktivnosti. Zato su redovito praćenje plana, resursa, rizika i otvorenih pitanja te pravodobna komunikacija među projektnim timom, korisnikom i ostalim dionicima ključni.
U praksi smo imali slučajeve u kojima određeni preduvjeti nisu bili ostvareni prema planiranoj dinamici. Nismo čekali da se problem pretvori u kašnjenje cijelog projekta, nego smo odmah pogledali na koje aktivnosti utječe, prilagodili prioritete ili redoslijed i s projektnim timom dogovorili što možemo napraviti da projekt ostane na dobrom putu. Dobar projektni menadžment ne znači da nema odstupanja, nego da ih prepoznajemo dovoljno rano da još uvijek imamo prostor za djelovanje.
Kako se rješavaju sukobi prioriteta kada nekoliko velikih projekata istodobno zahtijeva iste stručnjake, a korisnici očekuju ispunjavanje ugovorenih rokova, funkcionalnosti i kvalitete?
Kad više velikih projekata istodobno treba iste stručnjake, najvažnije je na vrijeme vidjeti gdje imamo konflikt i otvoreno dogovoriti prioritete. Gledamo koji su rokovi kritični, koje aktivnosti ovise baš o tom stručnjaku i kakav bi utjecaj njegovo pomicanje imalo na ostale projekte.
Takve situacije rješavamo zajedničkim usklađivanjem voditelja projekata, tehničkih voditelja i voditelja nadležnih organizacijskih jedinica. Gledamo možemo li promijeniti redoslijed aktivnosti, angažirati drugog stručnjaka ili dio posla odraditi paralelno. Primjerice, ako isti stručnjak treba sudjelovati u kritičnoj fazi dvaju projekata, prvo gledamo mogu li se aktivnosti vremenski razdvojiti ili dio posla preuzeti drugi član tima.
Ako raspoloživi kapaciteti ipak nisu dovoljni, problem se eskalira prema sponzoru projekta kako bi se prioriteti uskladili na razini šire od pojedinog projekta. Važno je da pritom svima bude jasno što određena odluka znači za rok, opseg i kvalitetu te da korisnika pravodobno uključimo ako postoji utjecaj na preuzete obveze. Ne možemo uvijek izbjeći konflikt oko resursa, ali možemo ga dovoljno rano prepoznati i zajedno odlučiti gdje su ti resursi u tom trenutku najpotrebniji.
Koliko promjene korisničkih zahtjeva utječu na troškove, rokove i profitabilnost projekata, tko donosi konačnu odluku o njihovom prihvaćanju i kako se korisnicima komuniciraju posljedice takvih promjena?
Promjene korisničkih zahtjeva normalan su dio projekta, ali prije prihvaćanja moramo jasno znati što one donose. I zahtjev koji na prvi pogled izgleda kao mala promjena može tražiti dodatni angažman stručnjaka, pomaknuti povezane aktivnosti ili povećati troškove, a time utjecati na rok isporuke i profitabilnost projekta.
Kada se pojavi novi ili izmijenjeni zahtjev korisnika, prvo zajedno s projektnim timom procijenimo njegov utjecaj - tehnički voditelj gleda što se time mijenja u tehničkom rješenju, a voditelj projekta procjenjuje kako se to odražava na opseg, potreban angažman i rokove. Promjenu zatim potvrđujemo sa sponzorom projekta, nakon čega korisniku jasno komuniciramo što ona znači za provedbu projekta u praksi – primjerice, koji će se rokovi produljiti ili redoslijed kojih će se aktivnosti morati promijeniti.
Promjene su sastavni dio projekta. Ključno je da ih prihvaćamo tek kada svi jasno razumijemo njihov utjecaj na rok, trošak i kvalitetu.
Kako se u Combisu prati uspješnost projekta nakon završetka implementacije, provjerava ostvarenje početno definiranih poslovnih ciljeva i razlikuje formalno uspješna isporuka od stvarne vrijednosti koju je korisnik ostvario?
Uspješno završena implementacija i stvarno ostvarena vrijednost za korisnika nisu nužno ista stvar. Projekt možemo formalno smatrati uspješnim kada je rješenje isporučeno u dogovorenom opsegu i kvaliteti, provedeno testiranje i prihvat te završena primopredaja. Time potvrđujemo da smo ispunili projektne obveze.
Poslovna vrijednost često se može realno procijeniti tek nakon određenog vremena korištenja rješenja. Tada više nije dovoljno gledati jesmo li isporučili ono što je ugovoreno, nego je važno provjeriti donosi li rješenje korisniku ono zbog čega je projekt pokrenut, primjerice učinkovitiji proces, veću dostupnost sustava ili kvalitetniju uslugu. Projekt završava isporukom, ali njegova se prava vrijednost potvrđuje tek kroz rezultate koje korisnik ostvaruje korištenjem rješenja.
