Utjecaj Project Managera na kvalitetu isporuke
0 likes395 views
Dokument analizira utjecaj voditelja projekta na kvalitetu isporuke kroz tri konkretna scenarija iz prakse. Uključuje ključne izazove poput nedostatka definiranja opsega projekta, kašnjenja, i nedovoljne suradnje među sektorima, što može ugroziti isporuku i kvalitetu rezultata. Na kraju se naglašava važnost razumijevanja kvalitete iz perspektive klijenta i odgovornosti voditelja projekta u održavanju standarda kvalitete.
Utjecaj Project Managera na kvalitetu isporuke
- 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!