1. DISKUSIJA
Utjecaj voditelja projekta na kvalitetu
isporuke
23.05.2011, Primošten
Voditelji:
Sanja Zagajšek (PBZ)
Alan-Mirko Poldrugač (RBA)
Vladimir Vuk

2. Trajanje: 60 minuta
Sadržaj:
- Uvod (sudionici, tema, sadržaj predavanja)
- Scenariji (3 scenarija)
- Zaključak (utjecaj voditelja projekata na kvalitetu isporuke)

3. UVOD
Realizacija
Eskalacija
Planovi
Vodstvo
Rezultati
Planiranje
Atmosfera
Odlučivanje
Kvalitetno ljudstvo
Dogovori
Odgovornost
Faziranje
Upravljanje
Sredstva
KVALITETNA ISPORUKA?

4. UVOD
Sto je kvaliteta?
-NEKOLIKO IDEJA-
“Quality itself has been defined as fundamentally relational: 'Quality is the ongoing
process of building and sustaining relationships by assessing, anticipating, and fulfilling
stated and implied needs”
"Quality is fitness for use"
"Quality is meeting or exceeding customer expectations at a cost that represents a value
to them."
"Quality should be defined as surpassing customer needs and expectations throughout
the life of the product."
“Review of a deliverable by a person who is considered an expert in the area. “

5. SCENARIJI
Predstavljamo tri scenarija iz prakse.
Princip glasanja:
1. Scenarij se pročita
2. Postavljaju se mogući odgovori
3. Sudionici mogu odabrati samo jedan od ponudjenih odgovora
- To se ponavlja za sva tri scenarija –

6. SCENARIJI
Scenarij 1:
Počelo je kao zajednička inicijativa svih sektora u kompaniji.
Svima to treba, potrebno je zajedničko rješenje bazirano na jedinstvenoj i usuglašenoj metodologiji koja mora biti
provjerena od kompetentnih sektora kompanije. Znači, strateški važan projekt i uključeni su svi sektori.
Drugačiji pogled na isto: Svi kažu da im treba ali to nije njihovo dijete, tj netko drugi to treba odraditi.
Odabran je sponzor, voditelj projekta... ključni poslovni tehnolozi...sve odobreno na Upravi.
Radi se o implementaciji softvera (ne razvoj softvera u kući već kupnja od stranog vendora te kastomizacija i
implementacija). Preduvjet za implementaciju je definirana metodologija, te na temelju nje, izrađene i usuglašene
poslovne specifikacije. Metodologiju trebaju izraditi i usuglasiti poslovni sektori i ista se treba odobriti na Upravi.
Sa ciljem definiranja metodologije PM organizira radionice sa poslovnim tehnolozima i vanjskim konzultantima. Na
radionice se ne dolazi redovito, šalju se pripravnici....Opseg projekta nije moguće u cijelosti definirati dok nije
usuglašena metodologija i izrađene specifikacije. Poslovna pravila nisu standardizirana ni dovoljno dobro definirana
za potrebe softvera koji se implementira (a to je preduvjet za implementaciju). A 'Best practice' koji donosi
konzultant je plod višegodišnjeg razvoja naprednih inozemnih kompanija...
Softver se bazira na analitičkim podacima kojih u nekim sustavima (naravno da kompanija leži na više što povezanih,
što manje povezanih softverskih rješenja) nema, ili se ne dovlače u DWH iz kojeg se crpe podaci za implementaciju
SWa. To znači da je, uz navedeno, potrebna dorada internih SW rješenja i sučelja.

7. SCENARIJI
Da ne bude sve jednostavno tu su i 'Organizacijsko/ resursni' poslovni problemi: reorganizacije sektora, novi ljudi
na pozicijama, ljudi angažirani na linijskim aktivnostima zbog tih reorganizacija (reorganizacija je nastupila iza
uspostave i odobrenja projekta).
Rezultati radionica trebaju biti definirane (i usklađene) metodologije koje su nužne za implementaciju SWa. Voditelj
projekta ,na temelju dogovora s radionica, sastavlja radne zadatke na koje nitko ne reagira, dokumenti se šalju na
čitanje i očitovanje no nitko ih ne čita ..... samo na sastancima se dobiju neke informacije.... PM prijeti, sponzor šalje
mejlove.. sada na sastanke dolazi više predstavnika pojedinih poslovnih područja (sektora) koji se na sastanku ne
mogu međusobno složiti i dogovoriti :-))
PM (ipak/konačno) izrađuje dokument s metodologijom kojeg potpisuju svi uključeni poslovni sektori, no upitno je
da li su uopće čitali materijale, oni koji su pročitali komentiraju dokument i traže neke izmjene. PM je u dokumentu
naveo što neće biti u opsegu projekta (trenutno maše s tim dokumentom jer su pritisci sa strane za promjenom
opsega!!).
Plan projekta revidiran često. Sponzor redovno obavještavan o kašnjenjima i neadekvatnoj uključenosti nekih
sektora (vrlo nepopularno tužakati kolege!!) ..no kako je kašnjenje zbog kašnjenja odluka visokog menadžmenta
...ostaje kako je....nema nekih rezova.
Projekt je podijeljen na dio koji s zna/koji je definiran pa da se bar nešto pusti u produkciju....ali čak i taj dio koji je
definiran doživljava promjene i to traje...
Dolazi do promjene metodologije, promjene modela....u tim fazama je moto 'dont't worry about deadlines' ,ali
takvo raspoloženje traje samo par tjedana..
Konzultanti iz vanjske firme se počinju osipati (prebačeni na druge poslove) ..zbog perioda u kojem se 'ništa' nije
događalo , pa je i dobavljač postao usko grlo.
Rok na projektu prekoračen za 30-40 % inicijalne procjene trajanja. Na neke odluke se čekalo i pola godine.
U međuvremenu je došao period godišnjih.....
Uz metodološka pitanja tu je bio i problem kvalitete podataka, analiza podataka je kompleksna i traje, testovi
također....zbog nedostatka nekih podataka potrebno je raditi aproksimacije. To ugrožava kvalitetu konačnih
isporuka.

8. SCENARIJI
Status: metodologija odobrena na Upravi. SW se testira. Krajnje isporuke dosta općenite. Planira se pratiti
korištenje...vrijeme će pokazati da li će rezultati zadovoljiti sve sektore (u smislu metodologije), ako ne, uvijek
postoji druga faza projekta :-((
Pitanje: što je mogao PM promijeniti, kako je mogao utjecati na rokove i kvalitetu isporuke?
1. nakon prvih neuspjeha na radionicama ustanoviti da ne može voditi takav projekt
2. nakon prvih neuspjeha na radionicama revidirati dokument s ovlastima, zaduženjima i odgovornostima,
eskalirati svako nepoštivanje dogovora
3. revidirati plan projekta koliko god puta treba, ako je sponzor ok sa novim rokovima

9. SCENARIJI
Scenarij 2: NOVI ZAHTJEVI
Projekt Novi Front Office je u fazi razvoja; 90% funkcionalnosti je isporučeno na test na kojem je
potvrđena spremnost za produkciju. U sljedećih 30 dana očekuje se isporuka i testiranje preostalih
10% funkcionalosti (transakcija).
Početak produkcije je planiran za 01.07., znači za nekih malo više od mjesec dana.
Projektni tim je do sada funkcionirao savršeno i rezultati su izuzetni. Očekivanja za početak produkcije
su sukladna projektnom planu i aplikacija bi trebala biti 100% spremna, znači svih 100%
funkcionalosti u produkciji bez defekata.
23.05. Voditelj projekta prima informaciju da je još 15.02. regulator (HNB npr.) usvojio propis koji
obvezuje primjenu OIB-a klijenata u svim šalterskim transakcijama s datumom primjene od 30.06.
ove godine. Ta odluka je bila zaprimljena u Banci još 16.02. ali do danas nije stigla do projektnog tima.

10. SCENARIJI
Voditelj projekta mora brzo odlučiti što dalje?
Odaberi od ponuđenog, što je najgore po rezultat projekta, što Voditelj projekta može učiniti:
1. PM odlučuje da se ne mijenja postojeća funkcionalna specifikacija, te da se isporuči ono što je planirano (znači
bez OIB-a). Očekivani rezultat: aplikacija u produkciji u roku 01.07, u budžetu i s planiranim funkcionalnostima, OIB
funkcionalnost će se dodatni naknadno. Dodatno PM otvara kampanju traženje "krivca" kako je moguće da tako
kasno projektni tim sazna za ovu ključnu promjenu?
2. PM odlučuje dodati OIB funkcionalnost u Opseg projekta. Time produžava projekt i povećava trošak (dodatni MD)
projekta. Očekivani rezultat: početak produkcije se odgađa na 01.09. ali aplikacija sadrži traženu IOB funkcionalnost.
3. PM odlučuje dodati OIB u Opseg projekta ali zbog potrebe da rok ostane isti, izbacuje sve nezavršene
funkcionalnosti (10%), odnosno pomiče ih na fazu iza početka produkcije. Očekivani rezultat: početak produkcije
ostaje 01.07. s OIB funkcionalnosti ali bez 10% fukcionalosti (koje su ujedno i najkompliciranije i najmanje se
koriste).
4. PM nije ovlašten donositi gore navedene odluke. PM organizira sastanak projeknog tima na kojem se radi analiza
mogućih scenarija te se rezultati šalju Sponzoru projekta.
Dodatno pitanje: što je najbolje po rezultat projekta što PM može učiniti u ovoj situaciji?

11. SCENARIJI
Scenarij 3: HURA! PROJEKT JE NAS!
Pregovori oko ponude su zavrsili uspjesno i glavni account manadzer je trljao ruke znajuci da ce
sljedece dvije godine njegova firma XYP d.o.o. imati dovoljno posla za 15 ljudi kod novog klijenta.
Ujedno, njemu slijedi ljepi bonus, jer dogovoriti posao od nekoliko desetina milijona kuna, nije mala
stvar.
U prvih dva do tri mjeseca, voditelj tog velikog projekta (isto iz XYP d.o.o), nije se previse brinuo.
Opseg posla nije bas bio previse jasan, ali po prirodi takvih projekata, to i nikad na pocetku nije jasno.
Tako je on, znajuci da ni klijent ne zna koliko se toga treba napraviti, nije previse brinuo. Projekt,
dakle budget i vrijeme, ce se prilagodjavati situaciji u ovisnosti o opsegu. Jer, dvije godine su duge i
puno toga se moze desiti. Ono sto je PM-a ipak cinilo pomalo nervoznim je cinjenica da je to fixed-
price project: 15 procesa treba dizajnirat I automatizirat. Iako DNK d.o.o nema svo potrebno iskustvo,
intiligencija mladih ljudi i dobri sub-kontraktori ce zasigurno rijesiti sve probleme.
6 mjeseci kasnije….
Razvoj je na papiru isao po planu. Od deset procesa koje su korisnici morali opisati, 6 ih je bilo gotovo
i pocela su testiranja softverskog rjesenja. Ali kod svekog testiranja, se cinilo da se rijesi jedan, a javi 6
novih problema.

12. SCENARIJI
Scenarij 3: HURA! PROJEKT JE NAS!
Vodje timova su znali sto bi trebalo biti rjesenje: bolji programeri, koji bolje programiraju, a i bolje
komuniciraju sa korisnicima. Ali to se nisu usududjivali reci ni samom sebi jer bi to znacilo da ni oni ne
znaju voditi posao kako treba. Pa su tako, krivicu za situaciju prebacivali na klijenta i kompleksnost
njegove situacije. Ujedno, znali su sto bi im PM rekao. Nek ih motivira, vodi, a ako treba, moze se
ubaciti jos koji student koji ce pomoci oko testiranja. A svi skupa, znali su dobro da sve to vodi ka
gorkom kraju. Kao kad padas sa 50-og kata, I tamo negdje oko 20tog kata viknes: ”Za sad, ide dobro!”
Kljucni korisnici koji su bili u istim timovima su sve vise imali osjecaj da tim testiranjima I
razgovaranjim nema kraja i da je znanje vanjskih programera ustvari upitno. Gube vrijeme. Ocekivali
su vise od XYP d.o.o i njegovih savjetnika: znanje poslovanja i poznavanje aplikacija. To jos nisu jasno
artikulirali, jer svaki put kad PM dodje kod njih u tim, on ih uspije poslozit, uvjerit kako ce sve biti ok,
dati rjesenja za neke probleme, a za neke kaze da ce on to srediti.
Za PMa je bilo bitno da se ide po planu i budzetu, jer je u medjuvremenu pocela diskusija oko rokova i
budzeta. Zvanicno je dobio direktivu da zaostri planiranje i kontrolu. Nezvanicno je razumio da razlog
za sve promjene u projektu nekako mora staviti na teret klijentu. I to moci dobro argumentirati.
Situacija se lagano zaostravala, a procesi nikako da se zavrse te da se pocne sa testiranjem. Go-live
datum je za 3 mjeseca. Medju ljudstvom XYP d.o.o. lagana panika, kod klijenta lagano ogorcenje.

13. SCENARIJI
ODABERITE KLJUCNI MOMENT U KOJEM JE OVAJ PROJEKT POCEO ICI NIZ BRDO, A NA KOJI JE
VODITELJ PROJEKTA (PM) MOGAO UTJECATI. UJEDNO, RAZMISITE STO JE PM TREBAO NAPRAVITI U
TOM TRENUTKU.
1. Pocetak: PM nije bio prisutan kod podpisivanja ugovora
2. Prva tri mjeseca: PM je vodio projekt, iako je bilo jasno da opseg nije jasno definiran
3. Prva tri mjeseca: PM je vodio projekt, a nije eskalirao problematiku nejasnog opsega, i dogovorio
adekvatni nacin poslovanja
4. Nakon 6 mjeseci: PM je znao da programeri nemaju dovoljno znanja, i nije ih na vrijeme zamijenio
sa boljima
5. Nakon 6 mjeseci: PM je znao da opseg projekta lagano izlazi iz dosadasnjih gabarita, ali je to
ignorirao, nadajuci se boljem.
6. Nakon 6 mjeseci: PM nije jasno, otvoreno i iskreno komunicirao situaciju sa vodstvom projekta
(XYP d.o.o i klijent) u cilju smirivanja situacije i trazenja novih rjesenja.

14. ZAKLJUCAK
Quality is a much more complicated term than it appears. There are a variety of perspectives that
can be taken in defining quality (e.g. customer's perspective, specification-based
perspective). Quality professionals constantly debate this question.
Kako god, cini se da se pojam kvalitetne isporuke ipak definira na nivou individue, ili kolektiva.
Svaki voditelj projekta treba razumjeti sto je kvaliteta za doticnog klijenta, ustanoviti da li ona/on
to moze zadovoljiti, te na osnovu toga odluciti da li uzeti projekat ili ne.
A onda….ide ona stara “ Ako zi zagrizao dr.. onda ga i pojedi.”

15. ZAKLJUCAK
HVALA!