Zašto IT projekti ne uspevaju?

Dok radite na projektu, glavni cilj je uvek uspešno završiti proizvod projekta, a samim tim i sam projekat. Uspešno završen projekat znači pravovremeno ostvarenje rezultata u okviru dodeljenog budžeta, ispunjavanje željenih standarda kvaliteta, ostvarenje poslovnih ciljeva, poslovnih koristi kao i zadovoljstvo korisnika finalnim proizvodom.

U ovom članku ćemo se baviti nekim od najčešćih razloga za neuspeh IT projekata.

Najčešći razlozi zašto IT projekti ne uspevaju

Upoznavanjem i razumevanjem uobičajenih grešaka koje neki projekat vode ka neuspehu, bićete (možda – kažem možda jer je moguće da okruženje u kome vodite projekat to jednostavno ne dozvoljava) u mogućnosti da preduzmete odgovarajuće korake kako biste sprečili da vaš projekat prođe istim putem.

Evo nekih uobičajenih problema koji rezultiraju neuspesima projekata:

1. Nedostatak podrške od strane menadžmenta
2. Smanjenja troškova
3. Nedostatak pravilnog planiranja
4. Pogrešan izbor tehnologija
5. Loša komunikacija
6. Previše optimističan (nerealan) raspored faza i radova na projektu
7. Kratak period testiranja ili preskakanje testiranja

Obratićemo se svakoj stavki ponaosob, i daćemo neka moguća rešenja.

Ali, pre nego što to uradimo moramo da postavimo jedno ključno pitanje:

Da li je u svim ovim slučajevima korišćena neka metodologija za upravljanje projektima?

Ukoliko je odgovor NE, onda se ne bavimo projektima, nego radimo stihijski i bez reda, pa i nije čudo što nismo uspešni.

Ukoliko je odgovor DA, mogući uzroci za nastanak svih gore navedenih problema su uglavnom sledeći:

• Nedovoljno poznavanje metodologije od strane svih zainteresovanih strana (pojedinaca uključenih u projektni tim). Na primer situacije u kojima je jedina osoba koja zaista poznaje metodologiju sam projektni menadžer, dok uprava i tehnički tim nisu edukovani ni za jednu od metodologija ili okvira. To dovodi to loše komunikacije, tj nerazumevanja između uprave i tehničkih uloga na projektu.
• Slepo praćenje metodologije, tj. bavljenje metodologijom i njenom administracijom a ne samim projektom. Na primer, bitnije je da se ispoštuje forma i hijerarhija nego da se napravi dobar i kvalitetan proizvod
• Korišćenje metodologije bez njene ugradnje u same poslovne procese. To znači da smo izabrali metodologiju, upoznati smo sa njom ali nam je bitnije da kažemo da radimo npr. po ovoj ili onoj priznatoj metodologiji, nego da je zaista primenimo. Tj. nismo je ugradili u sam način rada, što je ključni princip nekoh projektnih metodologija.

Hajde sada da opišemo svaki od gore pomenutih problema i damo neka rešenja.

Nedostatak podrške (interesovanja) menadžmenta:

U nekim situcijama (kako poslovnim tako I životnim) uprava (menadžment, država, bilo koja strana koja nam daje zadatke) ima pogrešan stav, a taj stav je nama iz IT sektora veoma poznat: ne razumem ja taj  IT vokabular. Taj stav stvara tendenciju da prepuste IT projekte IT timovima u potpunosti, bez interesovanja i upita.

Ovakav način razmišljanja rezultira nedostatkom interesovanja uprave što za direktnu posledicu ima to da tehnički tim dobija više slobode u donošenju svojih odluka.

Šta je tu problem?

Zar Self-Empowering tim nije stub dobrog Agilnog načina rada?

Pa, sloboda samostalnog donošenja odluka jeste jedan od principa Agilnih timova. I to je dobro. Međutim, to podrazumeva pravilno kreiran i edukovan tim sa svim podrazumevanim ulogama u timu. (NPR po Scrum-u moramo imati Product owner-a, Scrum Mastera i plus ceo development tim)

Ukoliko to nije slučaj nastaju problemi, jer tehnički timovi generalno ne razumeju dobro poslovne ciljeve i mogu se slučajno (ili namerno) suprotstaviti poslovnim ciljevima kako projekta tako i same organizacije.

Rukovodstvo treba da posveti dužnu pažnju IT projektima i da redovno prati i interesuje se za napredak radova na projektu.

Ako vaš tehnički tim ne ume da im prezentuje to šta kako radi, možda im nedostaje edukacije za upravljanje projektima, a možda i ne zna šta tačno treba da radi i koji je glavni cilj projekta.

Kako to rešiti?

Postoje dva odgovora na ovaj problem.

Prvi je pravilan izbor Upravljačkog tima projekta.

Po Prince 2 metodologiji upravljanja projektima, svaki dobar Projektni tim mora da ima sva tri poslovna interesa zastupljena.

Ti interesi su:

1. 1. Biznis  – tj. Organizacija koja će direktno dobiti korist samim proizvodom projekta.
   2. Korisnik,  – tj. Uloga koja će koristiti taj proizvod u budućnosti radi ostvarivanja pomenute koristi
   3. Dobavljač,  – tj. Uloga koja treba da napravi taj proizvod koji će korisnik da koristi radi ostvarivanja koristi

Te tri uloge po PRINCE 2 metodologiji čine Projektni Odbor. (Project Board)

Taj Odbor (čitaj uprava) delegira upravljanje projektom Projektnom menadžeru.

Da bi projektni menadžer mogao uspešno da vodi projekat sam odbor se formalno dogovori o svim glavnim aspektima projekta, i te odluke delegiraju projektnom menadžeru da ih sprovodi u samom projektu.

Jedna od glavnih odlika je upravo pravovremena komunikacija. Ta komunikacija je definisana pre samog projekta, i odbor time ima uvid u na trenutno stanje radova na projektu u realnom vremenu.

Drugi odgovor je izbor projektne metodologije i njena primena kako na projektima tako i u samim poslovnim procesima.

Na primer, po Prince 2, Projektni menadžer nije odgovoran za finalni proizvod projekta već za sam projekat u celini, odnosno upravljanje istim. Ako korisnik i biznis nisu dobro definisali proizvod koji žele da dobiju projektom odgovornost je na njima.

Pošto Odbor delegira upravljanje projektom samom projektnom menadžeru, daje mu i alate za uspešan rad i kontrolu nad svim aspektima projekta.

Što znači da komunikaciju sa odborom (upravom) ne obavlja tehnički tim. Tehnički tim komunicira (izveštava) sa projektnim menadžerom, a on komunicira sa upravom.

Sama metodologija daje zajednički jezik i bolje razumevanje svim zainteresovanim stranama. Sa jedne strane upravi je jasno šta se i kako radi na projektu, a sa druge strane, tim je svestan da ima podršku i razumevanje od uprave za rad na svojim dnevnim aktivnostima na projektu.

Smanjenja troškova

Svi biznisi žele da uštede novac kada su u pitanju izdaci. Ta inicijativa zvuči sjajno, ali to može koštati i više od planirane uštede ako primenite taj pristup na svim svojim IT projektima.

Dodela nedovoljnih i malih budžeta za vaše projekte rezultiraće nabavkom lošijih resursa za taj projekat.

Inicijalno nedovoljno finansirani projekti imaju jako loš i veoma kasan (a često i nikakav) povraćaj investicije, i često nedostaju funkcije ili imaju problema sa kvalitetom. Pouka je jednostavna. Izdvojite dovoljno budžeta da zaposlite prave ljude za posao. Definišite dovoljan budžet da biste angažovali sve resurse koji su potrebni za uspeh tog projekta. Samo programeri ne grade tim za IT projekat; potrebni su vam i poslovni analitičar, testeri i projektni menadžer.

Tu opet postoji ponovo problem sa komunikacijom.

Na primer:

Finansijski tim (koji je u većini slučajeva i inicijator smanjenja troškova, što je i razumljivo jer je tom sektoru taj cilj uvek strateški prioritet), ne razume IT jezik, a sa druge strane IT tim ne govori finansijski jezik. I tu dobijemo uglavnom lost in translation situaciju ?.

Dugogodišnje iskustvo u IT sektoru, pogotovo na upravljačkim pozicijama mi je pokazalo da Finansije nikada neće naučiti da čitaju i govore IT jezik.

Što znači da mi iz IT na srednjim i visokim pozicijama moramo da naučimo da govorimo i pišemo finanskijskim jezikom da bi sprečili ili odbijanje budžeta ili neproporcionalna smanjenja troškova.

Naime, moramo da naučimo da sve što prezentujemo Finansijama (a i samom biznisu) možemo da formulišemo u dva termina na jeziku finansija, a to su Ukupna Cena Koštanja (TCO – total cost of ownership) i Povraćaj investicije (ROI – Return of Investment).

Pravilna primena projektne metodologije može pomoći u tome. Primenom i ugradnjom PRINCE 2 u sam biznis omogućavamo IT sektoru da brže nauči finansijske termine (kao npr. Business benefit – poslovna korist), kako da merljivo prezentuje poslovne koristi IT projekata, i uspešno realizuje te koristi kroz IT projekte.

Nedostatak pravilnog planiranja

IT timovi su uglavnom brzi i agilni – skloni su da uskoče i pokrenu stvari odmah. Što je i jedna od ideja koja stoji iza AGILE načina rada i samog AGILE manifesta.

Međutim, rezultat toga može biti odsustvo ili nedostatak odgovarajućeg planiranja projekata.

Mnogi IT projekti započinju bez detaljnog razumevanja obima i rezultata projekta. Bilo koji projekat je osuđen na propast ukoliko su ciljevi nejasni i sve se upravlja i vodi stihijski.

Imajte na umu da uspešan projekat ne znači samo „isporuka finalnog softverskog proizvoda“, već podrazumeva stvaranje željenog rezultata projekta u ciljanom vremenskom periodu i budžetu, ondosno onoga što se naziva poslovna korist (business benefit). Ta poslovna korist je i razlog za pokretanje IT projekata,

Odsustvo odgovarajućeg planiranja donosi brojne probleme projektu kao što su:

– Nejasan obim i cilj projekta

– Konfuzija oko uloga i odgovornosti

– Neefikasno korišćenje resursa

– Nedostupnost resursa u kritičnom momentu

– Neravnomerno opterećenje zadacima u samom timu

– Netačne procene vremena

– Netačne procene troškova

– Loše performanse i kvalitet finalnog proizvoda

Sve ovo može takođe biti eliminisano primenom PRINCE 2 metodologije.

Edukacija projektnih menadžera i svih članova projektnih timova, uz efikasnu ugradnju i primenu metodologije u poslovanju daje veću uspešnost u procesima planiranja.

PRINCE 2 je metodologija koja se fokusira na proizvod projekta kao osnov za sam proces planiranja i sadrži planiranje kao posebnu temu sa alatima i procesima koji umnogome mogu da omoguće pravilno planiranje na svim nivoima, kako projekta tako i samog poslovanja ukoliko je pravilno prilagođena samom tipu biznisa u kome se primenjuje.

Pogrešan Izbor tehnologija

Dobar izbor tehnologija sprečava tehničke probleme na projektima. Nijedan projektni menadžer ne može da sačuva vaš projekat ako su izabrani alati i tehnologije pogrešni. Nove, napredne tehnologije i trendovi u razvoju su naravno zavodljivi i primamljivi, i naravno da treba ići u korak sa vremenom i pratiti trendove, ali ne po svaku cenu.

Neki rukovodioci razvoja biraju programski jezik i okruženje zbog ličnih preferencija; drugi biraju ono što je u trendu i u nastajanju.

Ključna stvar ovde je razumeti poslovni problem i ispitati prirodu problema.

Kada shvatite ‘zašto’ i ‘šta je cilj, možete da nastavite sa “kako” odnosno dizajnom rešenja.

Glavni princip kojim svi projektni menadžeri (i u IT sektoru i u van njega) moraju uvek imati u vidu je činjenica da Biznisu (Organizaciji) nije bitna tehnologija, već rešenje koje je dovoljno dobro za taj biznis, naravno i uz minimalne troškove ulaganja.

Projekat tehnički ne može uspeti ako odaberete razvojno ili radno okruženje koje nije usklađeno sa potrebom samog biznisa za koji radimo taj projekat.

Još jedan potencijalni problem se pojavljuje kada napravite pravi izbor alata i tehnologija, a nemate kvalifikovane resurse za te izabrane alate i tehnologije.

Proverite da li imate potrebne resurse (ljude) koji mogu obaviti posao u tim alatima i tehnologijama.

Pored tehničkog rešenja, potrebni su vam i neki alati za obavljanje pratećih aktivnosti upravljanja projektima. Ovi alati su neophodni da bi vam pomogli da upravljate životnim ciklusom razvoja softvera.

Te alate vam daje PRINCE 2. Kao što smo pomenuli, PRINCE 2 je fokusiran na proizvod projekta, to jest na poslovne koristi koje taj proizvod donosi ili će doneti samom biznisu.

Ne zaboravite: Vi radite na IT projektu, ali taj projekat radi za biznis koji to sve finansira i očekuje neki povraćaj te investicije. Taj povraćaj (korist) može biti profit, ali može biti takođe i poboljšanje servisa i usluga koje taj biznis nudi svojim korisnicima i klijentima i potrošačima.

Loša komunikacija

Loša komunikacija je čest razlog neuspeha projekata. Ovaj problem se takođe može povezati sa nedostatkom primene metodologije upravljanja projektima.

Uspešna i efikasna komunikacija sa svim zainteresovanim stranama, menadžmentom i projektnim timom od vitalnog je značaja za uspeh projekta. Odgovornost je projekt menadžera da članovima tima dostavi sve odobrene zahteve i odluke.

Menadžer projekta može da ponese svu potrebnu komunikaciju, ali komunikacija unutar tima ostaje izazov. Uobičajene greške u komunikaciji u IT projektima događaju se kada je neki član tima izostavljen iz komunikacijske strukture.

Često se dogodi da ste blizu roka, a viši nivoi tima komuniciraju češće – odstupajući znatno od nižih nivoa.

Kada se bilo koji član tima ne oseća kao važan deo tima, može izgubiti motivaciju, što na kraju utiče na njegov rad.

Iz ličnog iskustva znam da su programeri toliko zauzeti u svom poslu da im nije važno (ili zaborave) da informišu relevantne resurse za kontrolu kvaliteta o svim promenama zahteva, koje je odobrio projektni tim.

Kontrola kvaliteta u tom slučaju nastavlja testiranje aplikacije bazirano na neizmenjenim tolerancijama i postavkama i daje pogrešne savete i preporuke. Ovaj scenario uvećava troškove, vreme i trud.

Ugradnja i primena PRINCE 2 obezbeđuje tačnu i pravovremenu komunikaciju svim članovima projektnog tima, kao što je već pomenuto.

Tema promene vodi računa da su sva odobrena odstupanja od proizvoda projekta u skladu sa poslovnom politikom samog biznisa, i da su sve zaintersovane strane na projektu a prvenstveno projektni tim informisane o svim usvojenim izmenama.

Osim toga tema kvaliteta, u sprezi sa komunikacijom obezbeđuje da su sve aktivnosti koje se preduzimaju na kontroli i obezbeđenju kvaliteta proizvoda, ažurirane i pravilno vođene.

Previše optimističan (nerealan) raspored faza i radova na projektu

Svi smo mi u nekom trenutku bili žrtva situacije u kojoj se neki menadžer dogovori nešto sa klijentom i nametne rok za projekat bez provere raspoloživosti resursa. Razlozi za to mogu biti brojni. Na primer, menadžer smatra da projekat treba da bude završen do određenog datuma ili klijent želi da uživa u svom odmoru i želi da se projekat završi pre toga.

Rukovodioci projekata stoga razvijaju previše optimistične rasporede da bi ispunili nasumične rokove. Previše optimističan raspored ujedno prati i ogroman pritisak na članove tima. Članovi tima mogu uložiti dodatne napore kako bi na kraju dovršili svoje zadatke, ali kašnjenje bilo kojeg pojedinca loše utiče na ostale. Stoga takav raspored projekta zahteva projektnu metodologiju.

PRINCE 2 ima sve mehanizme za pravilno vođenje čak i projekata sa limitiranim rokovima i budžetima.

Osnovni princip PRINCE 2 je upravljanje po fazama, a tema planiranja i tema progresa vode računa da se rad na ciljevima projekta pravilno prioritizuje da bi se projekat završio u dogovorenim tolerancijama.

Kratak period testiranja ili preskakanje testiranja

Neki od vođa timova za IT projekte su pod pogrešnim utiskom da je razvoj i samo razvoj ključ za uspešne projekte. Ne. Svaka faza ciklusa razvoja softvera jednako je važna. Vaš  proizvod može biti potpuno neuspešan ako preskočite fazu testiranja ili je ostavite za kraj.

U IT industriji svi smo se dobro upoznali sa situacijom kada je verzija nekog rešenja već u produkciji, a u tom trenutku dolaze novi zahtevi korisnika ili developeri nastavljaju da popravljaju stare probleme, zaboravljajući na testiranje. Često odlažemo testiranje da bi dobili na vremenu ili ispoštovali nerealno dogovorene rokove.

Posledica je očigledna: ili ne registrujete sve probleme ili imate malo ili nimalo vremena za popravljanje problema. Pored toga što se premašuju rokovi, stvara se nered.

Problem može biti izbegnut ako vršite ispitivanje manjih komponenti paralelno kako se kreiraju. Agilni pristup kreiranja MVP (Minimal Viable Product) je dobar primer.

Naime, po SCRUM okviru, cilj jedne faze razvoja (sprint) je kreiranje MVP funkionalnog dela softvera koji se može dati na testiranje.

Međutim, i pored toga što agilni pristup prihvata promene, čak i u ranim fazama razvoja, bez pravilno primenjene projektne metodologije, to može ponovo dovesti do istih situacija sa rokovima i testiranjima.

Često se desi da projekt menadžer previdi znakove upozorenja koji se javljaju tokom procesa ispitivanja ili pod pritiskom odluči da ta pitanja budu rešena kasnije. To može takođe da uzrokuje prekoračenja, kako vremenskog opsega, tako i troškova.

Redovan i organizovan proces testiranja i kontrole je od suštinskog značaja za kreiranje kvalitetnih proizvoda projekta.

Pravilna primena PRINCE 2 metodologije obezbeđuje da se sve dogovorene i odobrene promene na svi, aspektima projekta (vreme, troškovi, obim, itd) pravilno implementiraju, tako da se projekat završi uspešno i u odobrenim tolerancijama.

Čak i uz primenu agilnih okvira (npr SCRUM) za sam rad na razvoju, PRINCE 2 kao metodologija upravljanja obezbeđuje okvir da se sve promene vode pravilno.

Primera radi, recimo da smo definisali naš finalni proizvod i krenuli u razvoj. Sve ide kako treba, kad u poslednjoj fazi projektna desi se situacija da korisnik zahteva promenu uz obrazloženje da je ta funkcionalnost ključna i potrebna.

PRINCE 2 tema promene će vam omogućiti da pravilno prioritizujete te zahteve pod uslovom da budu odobreni od sva tri zastupljena interesa (korisnik, dobavljač i biznis).

Zaključak

Potencijalni problem ili rizici koji mogu da utiču na uspešnost svakog projekta su prilično široki.

Ono što je zajedničko svima je činjenica da bez pravilne primene i korišćenja projektne metodologije, ti problemi i rizici postaju kočnica projekata i dovode do njihovog odlaganja ili gašenja.

PRINCE 2 metodologija, ukoliko se pravilno primenjuje, ili ugradi u same polise i procedure poslovanja omogućava ne samo pravilno i uspešno vođenje projekata, već daje i samom biznisu za koji radimo projekte veću sigurnost i poslovnu zrelost. Ta poslovna zrelost je pogotovo važna za konkurentnost na tržištu, status i renome svakog biznisa.