Da li je izvrstan Project Manager uvjet bez kojeg nema uspješnog završetka projekta?
•
0 j'aime•605 vues
Da li je izvrstan Project Manager uvjet bez kojeg nema uspješnog završetka projekta? PPM Konferencija 2009, Rovinj
![Uvod ,[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (13)
Similaire à Da li je izvrstan Project Manager uvjet bez kojeg nema uspješnog završetka projekta?
Similaire à Da li je izvrstan Project Manager uvjet bez kojeg nema uspješnog završetka projekta? (10)
Da li je izvrstan Project Manager uvjet bez kojeg nema uspješnog završetka projekta?
- 1. PPM Konferencija Rovinj, listopad 2009. Da li je izvrstan Project Manager uvjet bez kojeg nema uspješnog završetka projekta?
- 25. Q&A Q & A
Notes de l'éditeur
- Pretpostavimo da vam je stalo do uspjeha određenog projekta jer od njegovih rezultata očekujete izuzetne učinke u području vaše odgovornosti. Što vam je za činiti? Koji je to minimum koji morate osigurati kako bi omogućili/osigurali uspjeh tog projekta? Da li je dovoljno angažirati izvrsnog Project Managera (PM) i projekt će svakako biti uspješan? Da li je izvrstan PM garancija za uspjeh projekta bez obzira na ostale sudionike? Ova pitanja možemo postaviti i na drugi način. U poziciji ste da možete angažirati redom izvrsne sudionike projekta – jedan bolji od drugoga. Da li to znači da PM može biti najslabija karika u tom lancu ili da čak možete i bez njega (jer su svi ostali sudionici tako izvrsni)? Koji je taj nužni sastojak koji garantira uspjeh projekta? Da li je to PM, Sponzor, Članovi tima, svi zajedno ili je dovoljno osigurati dobre projektne nagrade? Danas ćete čuti moja viđenja ove tematike podržana primjerima iz stvarnih projekata i njihovih situacija. Za početak Anketa – da utvrdimo polazišnu točku vas prisutnih – što vi mislite o tome?
- Izradi anketu. (Anketi izradi na kraju predavanja pa usporedi rezultate – da li je bilo pomaka?) Rezultati na flipchart pa komentiraj redoslijed. Primjer: Članovi tima 15 Sponzor 10 PM 8 Svi 5 Nagrade 4 Najviše glasova na prvo mjesto, pa tako do kraja. Tko je birao svi izrsni njima preporuči knjigu Utopia – jer to se ne događa u stvarnom životu. Nakon ovog predavanja ponovit ćemo ovu anketu pa ćemo komentirati rezultate prije i nakon predavanja. Da vidimo hoće li ovo predavanja promijeniti vaše stavove ili je sve zacementirano kako jest? Ako je PM odmah prvi onda komentar, vidim da je puno PM u publici a malo Sponzora!
- Predavanje se temelji na dva scenarija – dvije priče. Prvi scenarij je priča o projektu koji je imao sve izvrsne sudionike osim PM, koji je bio prosječan. U drugom scenariju sve je obratno, PM je izvrstan a ostali sudionici su prosječni. Sudionici oba projekta prošli su kroz iste faze, rješavali iste probleme i postigli su različite rezultate. Proći ćemo 7 izazova za svakog od njih. fazu po fazu s oba tima i analizirati kako su se naši PM nosili s rješavanjem istih situacija. Analiza završnih rezultata oba projekta dat će odgovor na pitanje da li je izvrstan PM conditio sine qua non uspješno realiziranog projekta? Svi primjeri su iz stvarnog života i stvarnih projekata ali naravno nisu se svi dogodili na istom projektu već su skupljeni kroz niz projekata.
- Prvi projektni tim nazvat ćemo Zvijezde – zašto? Jer u tom timu su sve zvijezde uključujući i PM-a kojeg ćemo zvati Zvjezdan . Svi sudionici, Sponzor, članovi tima, korisnici svi su redom izvrsni. Kakav je Zvjezdan kao PM? To još ne znamo ali znamo da je izvrstan dizajner koji se postigao izvrsne rezultate u nekoliko dosadašnjih pothvata. Da li će to biti garancija za uspješan projekt vidjet ćemo za nekoliko trenutaka? Idemo redom, predstavit ćemo sve sudionike projekta predstavi sudionike ali predstavi i projekt, što je opseg, rokovi i budget ( na kraju na isti način usporediti rezultat projekta) Sponzor je direktor Sektora, izvrstan poznavatelj svoje domene i prihvaća aktivno sudjelovanje u projektu – znači može i želi biti prisutan na projektnim sastancima svaki tjedan. Članovi tima (BA, Dizajner, Developeri) – svi iskusni s izuzetnim dosadašnjim rezultatima Linijski manageri – shvaćaju važnost projekta za organizaciju i imaju pozitivan pristup prema sudjelovanju «njihovih» članova tima u projektu Vanjski partner – pouzdan i provjeren. Njegovi ljudi su već uspješno sudjelovali na prijašnjim projektima s izvrsnim rezultatima. Korisnici projektnog proizvoda – zovemo ih još po domaći Useri. To svi oni koji će raditi u svakodnevnom radu s novom aplikacijom – proizvodom projekta. U nastavku ćemo reći nešto više o tom proizvodu – aplikaciji. PM – do sada radio kao dizajner s izvrsnim rezultatima. Pretpostavlja se da će kao PM postići još bolje rezultate, posebno jer su i svi sudionici izvrsni. Očekuje se dobitna kombinacija i rezultat u kratkom roku.
- Nakon sudionika da vidimo o čemu se radi u tom projektu, koja su osnovana obilježja projekta? Opseg – glavni proizvodi projekta su aplikacija za rad u maloprodaji – maloprodajni šalter ili Retail Teller ili Retail Front Office, edukacija korisnika i Upute za rad. Ova aplikacija se kupuje kao gotov SW ali očekuju se određene dorade, zvane još customizacija. Ovo su glavni proizvodi, naravno u WBSu ima još međuproizvoda kao Lista zahtjeva, Funkcionalne specifikacije, Nacrt dizajna, plan testiranja, rezultati testiranja. Rok isporuke – 2,5g Složiti graf po fazama analiza, dizajn, razvoj, testiranje, implementacija (bigbang, rollout, edukacija) – usporedit ćemo na kraju sa završnim rezultatom Sad znamo tko su sudionici, što moraju odraditi – opseg 100 transakcija i edukaciju u kojem roku – faze, te koliko će nas to koštati – budget. Zvjezdani tim je spreman za prve izazove!
- Naš drugi tim također se priprema za početak projekta. Tim ćemo nazavti Tiha voda (a vidjet ćemo da li stvarno tiha voda brege dere?). Zašto? U timu je situacija obrnuta od prethodne, nema zvijezdi i puno je nepoznanica. Sponzor je direktor Sektora, dobar poznavatelj svoje domene ali ne može odvojiti puno vremena za projekt. Želi biti uključen samo u kritičnim situacijama i kad je potrebno donijeti ključne odluke. Očekuje da sve ostalo riješi PM – pa zbog toga je tu! Članovi tima (BA, Dizajner, Developeri) – svi novi i bez velikog iskustva i postignutih uspjeha (barem ne na ovom području) Linijski manageri – ne zanima ih važnost projekta za organizaciju i imaju negativan pristup prema sudjelovanju «njihovih» članova tima u projektu Vanjski partner – neprovjeren jer prvi put radimo s njih i nemamo iskustava. Korisnici projektnog proizvoda – nisu previše zadovoljni s postojećim rješenjem ali očekuju da će novo samo donijeti još više glavobolja i problema. PM – do sada radio kao PM s izvrsnim rezultatima ali na drugačijim projektima (druga firma). Očekuje se dobar rezultat od njega ali Management firme baš nema spektakularna očekivanja (više vjeruju u svoje iskusne i pouzdane ljude tkzv zvijezde nego u neke PM vještine i Pm metodologiju) Sukladno imenu tima i PM ćemo zvati Tihi . Za obilježja projekta možemo reći da je to isti projekt kao gore samo ga rade drugi sudionici. Znači u opsegu je aplikacija od 100 transakcija za podršku radu maloprodajnog šaltera. Rok i budget isti kao i gore.
- Projekti su počeli i da vidimo kako su se Zvjezdan i Tihi snašli u prvim izazovima. Izazov br. 1 Faza Analize , izrada korisničkih specifikacija ili funkcionalne specifikacije koje određuju izgled buduće aplikacije. Kod tima zvijezdi prvi problemi. Iako Sponzor želi sudjelovati ne stiže baš na svaki tjedan na sastanak. Kad treba donijeti odluku o određenoj funkcionalosti onda se čeka sljedeći sastanak Stc-a iliti Koordinacije kad će biti prisutan i Sponzor tako da on donese konačnu odluku. PM je redovito podsjećao Sponzora kako je važna njegova prisutnost na sastancima je će u suprotno sve kasniti. Sponzor je uvjeravao PM da već sljedeći tjedan stiže i sve će riješiti. Rezultat: verifikacija funkcionalnih specifikacija se odužila jer Sponzor nije stigao na sve sastanke projektnog tima. Frustrirani su i BA analitičari jer se sporo kreću naprijed a kao što znate oni su već zvijeze pa ih to dodatno frustrira jer ne daju očekivane rezultate. Situacija Akcija Rezultat
- Kod tima Tiha voda PM ima isti situaciju – rad na funkcionalnim specifikacijama se usporio i mogao bi trajati duže od planiranog ako PM nešto ne poduzme. Što naš PM radi u toj situaciji – tražio je od Sponzora da izabere jednu od sljedećih varijanti: ovlašćivanje BA team ledarea za 80% odluka o funkcionalnim specifikacija iako oni nisu «najveći stručnjaci» na tom području ako želi sve sam potvrditi onda mora biti prisutan kad se odlučuje o tome inače sve kasni unedogled Sponzor je izabrao ovlašćivanje: (što većina odabere jer na kraju shvati da ipak neće biti svaki dan s timom a opet žele rezultat) Rezultat: iako bez previše iskustva to ovlašćivanje je dalo krila BA team leaderima. Očekujete da neće sve odluke ovih BA biti baš najbolje ipak nemaju toliko iskustva. Ovdje je bilo očekivano da od 100 odluka u vidu funkcionalne specifikacije 10 bude loše znači 10%. Na kraju se pokazalo da od 100 specifikacija samo 3 su bile s nekim vidom greške ili loše procjene. Kad uspoređujemo trud za dorade po ove 3 specifikacije i trud koji bi bio uložen u nazovi savršeno rješenje (koje ipak nikad ne ugleda svjetlo dana, primjer gore 2 mj duže a specifikacij eopet nisu savršene jer takve ne postoje) to je prava sitnica. Na grafu se vidi da je rok od 4mj održan. Cijena nije mijenjana. Samopouzdanje BA team leadera je poraslo i daje polet izradi funkcionalnih specifikacija.
- Izazov br. 2 Faza Analize , izrada korisničkih specifikacija ili funkcionalne specifikacije koje određuju izgled buduće aplikacije. Kod tima Zvijezdi članovi tima negoduju zašto im nitko nije pojasnio da li se za rad na ovom projektu dobivaju neke nagrade. Sustav nagrađivanja za rad na projektu inače ne postoji u toj firmi. Zvjezdan traži od Sponzora da osigura neke nagrade a Sponzor to jednostavno nije u stanju jer to nije praksa u firmi. Članovi tima kukaju kako je glupo što neće dobiti ništa ekstra i PM kuka s njima. Što čini naš PM on «obećaje» članovima tima da će do kraja projekta sigurno nešto izvući od Sponzora kad se vide prvi rezultati projekta. Rezultat: pošto se ovdje radi o iskusnim članovima tima nitko od njih nije pao na foru obećanje ludom radovanje pa radi koliko se stigne i mora bez izrazite motivacije. Umjesto da svako jutro kad dođu na posao provjere koji defekti i zadaci stoje na njihovoj taskalici za taj taj oni pale Moj posao i provjeravaju da li ima kakav zanimljivi posao. Onda još sat vremena komentiraju to što su vidjeli uz kavu. Radni učinak prava ludnica. Osim toga, svaki ozbiljniji izazov ili problem oko specifikacija prebacuje se na vanjske konzultante nek oni riješe jer tako i tako su 5x bolje plaćeni pa nek to i zarade (zašto bi se ja mučio oko toga). Pak kad to sve neće štimati oni će biti krivi! Uz nezadovoljstvo što verifikacija specifikacija dugo traje ovo nezadovoljstvo samo još produžuje trajanje analize. Na grafu pokazi pomak analize od 2mj, plan 3 mj actual 5mj + i cijena je veća je plaćamo po čovjekdanu te konzultante.
- Kod tima Tiha voda ista situacija – ljudi se raspituju da li ima kakva nagrada ili slično. PM zna da u firmi ne postoji sustav za nagrađivanje rada na projektu ali zna i da mora imati motivirane članove tima. Kako će to uspjeti? Ljudi bi novce a on ih nema? Čime ih motivirati? Jednu od motivacija je već ostvario. Kad je ovlastio ljude za donošenje većine odluka to je dobra motivacija. Ovi BA su mladi i željni dokazivanja i sad imaju priliku odlučivati kako će izgledati buduća aplikacija koju će koristiti više od 1000 šalterskih djelatnika. Inače bi to sve odlučivao Sponzor a sada će oni – to im daje krila. Što može još napraviti? – odrediti jasne uloge i odgovornosti. Već na početku projekta svim članovima tima i sudionicima mora biti jasno koja je njihova uloga i odgovornost. Zamislite to ovako kad dolazite u neki prostor i tamo je sve čisto i uredno i vi se onda ugodno osjećate u tom prostoru. Tako isto kad član tima dolazi na projekt ako je sve čisto i uredno odnosno zna koja je njegova uloga na projektu i koje su sve ostale uloge i odgovornosti (vidi iz org charta projekta) onda mu je puno ljepše raditi na takvom projektu. Ili kad dođete na projekt i vidite da tu svatko radi ono što nije njegov posao, npr. PM dizajnira buduće rješenje a Sponzor piše i odlučuje o funkcionalnim specifikacijama onda zapravo dođete u zmazan i neuredan prostor i tada samo što prije želite otići iz njega (naravno da ne želite sve to počistiti jer to i nije vaš posao). Znači Tihi je osnažio svoje članove tima i pobrinuo se da svatki član zna svoju ulogu i odgovornost te koje su ostale uloge na org chartu projekta. Time je stvarno motivirao članove tima bez da je dao ikakvu nagradu. Svatko voli kad sudjeluje u nečem korisnom, pa tako i ovdje kad ljudi vide da to ima smisla i da može izaći neki pozitivan rezultat onda sudjeluju u suprotnom ako već ne sabotiraju onda samo daju najmanje što se može. Na uspješnom projektu svi su sudjelovali pa čak i oni koji nisu bili ni blizu a na neuspješnom nitko ne želi sudjelovati, kao da smrdi pa svi bježe od njega. Znate kad je na ljeto ukinut onaj vladin ured za ispitivanje učinka propisa? Dok je to bila «uspješna» inicijativa svi su željeli biti blizu, slikati se, nešto reći – mirisalo je na uspjeh. Sad kad to definitivno nije uspjeh sad na kraju nitko nije ni vodio taj projekt nitko nije ni sudjelovao, samo je tamo ostalo nekoliko ljudi koji sad ne znaju kako bi pobjegli od toga. Uspjeh ima puno očeva – svi su zaslužni a neuspjeh je siroče – nitko ga neće. Graf: Na grafu se vidi da je rok od 3mj održan. Cijena nije mijenjana. Svi članovi tima su motivirani posebno činjeicom da do sada nisu postigli neki uspjeh pa vide ovo kao svoju priliku, posebno jer su i okolina, kolege, organizacija sve je ok pa se isplati uložiti i nešto više s njihove strane.
- Faza Dizajna , repozitorij dokumentacije i version control + pitanje backupa Na samom početku Analize dogovoren je način izrade funkcionalnh specifikacija kroz UseCase i GUI te da će se za repozitorij dokumentacije i version control koristiti ClearCase.(IBM rational proizvod). Dobavljač od kojeg smo kupili aplikaciju i s čijim konzultatima radimo analizu i dizajn preporučio nam je ClearCase jer su radili s njim. Kako su se već ranije razmatrala potencijalna rješenja za version control i ClearCase je bio jedna od mogućnosti odlučeno je da se krene s njim na projektu. Kao i sa svakom aplikacijom koja ima neku bazu dogovoren je standardni način backupiranja baze/podataka(jednom dnevno preko noći). Na kraju analize 100 verificiranih Uce Case ova za 100 traženih transakcija (uz pripqdajuće GUI-e) i uz sve njihove verzije nalazile na ClearCase repozitoriju. U fazi Dizajna sva dizajn dokumentacija također se nalazila na Clearcase-u. Na jednom od sastanaka Koordinacije projekta Zvjezdan je tražio potvrdu da li se backupiranje redovito provodi. Na sljedećem sastanku dobio je potvrdu da je sve ok i da backupovi postoje. Kako je taj CC bio instaliran na jednom PC-u koji glumi server ubrzo mu je otišao hard disk (nepovratno izgubljen, nije mu bilo spasa, čuje se tk tk kao kod diesel motora. Pokušaji reanimacije nisu uspjeli pa je bilo potrebno vratiti back up na novi server. Isti je nađen u rekordnom roku jednog dana, isti dan je instalirana CC aplikacija i sad je trebalo samo vratiti staro stanje CC baze. Zašto je bilo bitno sve to brzo obaviti – zato jer cijeli pogon od 20 ljudi čeka i ne radi jer ne mogu do dokumentacije - a mnogi od njih su dosta skupi po danu (konzultanti). Sve je bilo brzo obavljeno u roku istog dana i kad je baza restorirana na CC server rezultat je bio veliko ništa. Backup je postojao ali nitko od nejga nije mogao dobiti staro stanje Cijeli pogon stoji i čeka i naravno da počinju optužbe tko je kriv – cc aplikacija, sistemaši itd. Zvjezdan je tu napravio dobar potez jer nije išao u istraživanje tko je kriv već je tražio način kako vratiti zadnju verziju dokumentacije. Svaki od dizajnera i developera je imao dobar dio toga na lokalnim mašinama pa je dogovoreno skupljanje i krpanje svega. To je potrajalo dva tjedna ali nakon toga su mogli krenuti od tamo gdje je stalo. Izgubljena su dva tjedna i dva tjedna dodatnih konzultantski md-a troškova.
- Faza Dizajna , repozitorij dokumentacije i version control + pitanje backupa Kao što već znate Tihi je imao istu situaciju na svom projektu. CC je repozitorij BA, Design dokumetacije i programskog koda i koristi se kao version control. Backupiranje je dogovoreno na isti način. Kako je Tihi imao loša iskustva s backupiranjem nakon što je isto upogonjeno i potvrđeno da radi Tihi je tražio da mu restoriraju bazu CC-a od određenog dana. Uvjeravali su ga da to nije potrebno i da samo gube vrijeme i da se nema tko time sada baviti jer imaju važnija posla. Tihi je bio uporan i malo lukav pa je ponovo tražio baš određeni dan jer se navodno tog dana nešto dogodilo s CC-om pa je trebalo provjeriti stanje baš na taj dan. Nakon dužeg nagovaranja ipak su mu izašli u susret pa restorirali cc repozitorij na jedan pc/serverčić. Za divno čudo dogodilo se isto ono što i Zvjezdanu. Naravno da taj CC restore nije radio. Onda su si ipak svi dali malo više truda i pronašli što je točno trebalo odraditi. CC sam radi svoj backup i onda backupiraš taj backup a ne direktno bazu (poduka). Kad se nakon 3 mjeseca CC server koji je isto bio jedan običan PC srušio zbog intenzivnog rada. Cijeli restore na novi server je trajao manje od jenog dana i svi člnaovi tima mogli su nastaviti raditi isti dan kad se dogodila havarija. Poanta: nije dovoljno napraviti backup potrebno je i provjeriti da li isti možeš vratiti u živi rad na aplikaciju. Rezultat: ova havarija nije znatno utjecala na rokove i troškove.
- Izazov br. 4 Faza razvoj – development. U toku razvoja pojavili su se dodatni zahtjevi koji nisu pokriveni originalnim opsegom. Sukladno Change management proceduri Koordinacija projekta raspravlja o tim dodatnim zahtjevima i kako ih riješiti. Zvjezdan je izradio prijedlog u kojem za rješavanje dodatnih zahtjeva traži agažiranje dodatnih resursa od vanjskog partnera. Naravno povećava se opseg projekta (novih 20 funkcionalosti u Scope) i povećava se budget projekta za te nove mandaye od partnera. Zvjezdan je ovdje iskoristio priliku pa je resetirao svoje rokove i tražio da mu odobre promjene terminskog plana.Koordiancija StC usvaja prijedlog. Veći opseg, budget, rok. Zvjezdan čeka nove snage raširenih ruku i čini se da je projekt dobio novi zamah. Ipak ti novi ljudi trebaju neko vrijeme da se uhodaju. Na početku im baš ne ide najbolje i najbrže pa rade slabije od onih koji su od početka tu. Zvjezdan počinje prebaciavati krivicu na nove članove projekta i općenito na partnera jer daju sve lošije rezultate. Naravno, ideja za sve okriviti nepozdanog partnera i njegove nepouzdane ljude. Rezulat: isporučen je loš proizvod i svi krive te vanjske partnere i nitko im neće dati ponovo sličan posao. Imamo krivca za loš uspjeh, ali činjenica je da kranji rezulta nije dobar nitko tu nije uspješan pa ni naš Zvjezdan. Na kraju je treba jedan dodatni mjesec za popravljanje tog lošeg rada kroz krugove testiranja i popravljanja i koji su na kraju odradili oni provjereni članovi tima. Znači kasni mjesec dana i na novi odobreni terminski plan. 5
- PM Tihi ima istu situaciju, treba angažirati dodatne resurse za traženi dodatni opseg. Tihi se prvo dogovara s članovima tima iz firme da li su voljni raditi prekovremeno što će im biti plaćeno kao prekovremeno da riješe te dodatne zahtjeve. Napomena: ovi dodatni zahtejvi su bili taman za jedan dodatni angažman – znači nisu radili 2 god prekovremeno (to nije dodatni angažman nego tortura) Tihi je sukladno dogovru s članovima tima izradio prijedlog u kojem za rješavanaje dodatnih zahtjeva traži povećanje budgeta za plaćanje prekovremenog rada članova tima. Znači isto je povećan budget za povećani opseg a rok ostaje isti. Koordinacija je usvojila prijedlog. Pokazalo se da je dodatni angažman dovoljan za rješavanje dodatnih zahtjeva. Ljudi su morali duže biti na poslu ali i svaki mjesec su dobili plaćene prekovremene pa nisu pokazivali nezadovoljstvo što dodatno rade. Posebno jer im je pružena prilika za dogovor. Nije im nametnut prekovremeni. Rezultat: isporučen je dobar proizvod u predviđenom roku.
- Izazov br. 5 Faza završetak razvoja development i testiranje, 30 dana prije početka pilot produkcije aplikacije. 90% funkcionalosti je iztestirano i u sljedećih 30 dana očekuje se pozitivan test za preostalih 10%. Odluka regulatora, vanjsko tijelo koja mijenja svih 100+20 transakcija npr. uvodi se obvezni porezni broj u sve transakcije, to mijenja opseg projekta odnosno funkcionalnu specifikaciju. Potrebno je odraditi analizu, dizajn, izprogramirati i testirati i to sve stići za 30 dana. Zvjezdan odlučuje da se neće mjenjati postojeća funkcionalna specifikacija i da se isporuči ovo što je dogovoreno a da ovi novi zahtjevi i nisu u opsegu projekta pa ih nije ni potrebno raditi. Rezultat: produkcija počinje sukladno planu ali Regulator baš radi nadzor koji je i najavio i utvrđuje da naš sustav ne zadovoljava kriterije koji su propisani i Banka ima problema s obrazloženjima regulatoru zbog čega nisu usklađeni. Projekt svakako nije uspješan. PM krivi regulatora i da su dali jako malo vremena za prilagodbu. Ipak, sve ostale Banke su se uspjele prilagodi bez većih problema.
- Tihi nakon što dobije ovu inforamciju organizira saastanak projektnog tima na kojem se analiziraju mogući scenariji idemo u produkciju po starom bez novih funkcionalosti dodajemo nove funkcionalosti što produžava rok i povećava troškove rok za produkciju ostaje isti i dodajemo nove funkcionalosti ali izbacujemo dio funkcionalosti koje prebacujemo za sljedeću fazu Sponzor onda donosi odluku koji scebarij se prihvaća. Sponzor bira opciju u kojoj dodajemo nove funkcionalosti ali izbacujemo dio starih funkcionalosti jer želimo zadržati rok za produkciju – izbacuje se 10 funkcionalosti. Rezultat: promjena opsega novi zahtjevi unutraa li dio starih zahtjeva van za drugu fazu projekta, rok i budget ostaju nepromijenjeni.
- Izazov br. 6 Faza Implementacije , edukacija korisnika za Bigbang pristup (PM mora biti inovativan) Potrebno je educirati veliki broj ljudi a a funkcionalost aplikacije je završena tek 15 dana prije početka produkcije – big bang. U početku nije planiran Bigbang pristup već Pilot pa Rollout na grupe poslovnica. Ipak zbog tehnoloških razloga početkom pilota i svi ostali morat će mali broj transakcija vezanih za bazu komitenata raditi isključivo kroz novi sustav, tako da za taj manji broj trx imamo neplanirai bigbang. Što sad, nema vremena ni dovoljno edukatora da obiđu sve poslovnice Zvjezdanu je već dosta svega pa odlučuje ne zamari se time. To je samo mali dio funkcionalosti, Uputu za rad već imaju pa će se valjda snaći. To rade tako i tako godinama pa će valjda znati otvoriti novog korisnika – opet, pa imaju uputu. Rezultat: prvi tjedan produkcije svi u državi znaju da imamo novu aplikaciju jer sve ide teško, sporo i s pujno grešaka pa popravljanje tih grešaka traje.
- Tihi je inovativan i predlaže korištenje e-leraning mogućnosti koja već postoji u Banci. Pripremiti elearning (snimljeni ekrani, alat za to složen na vrijeme) Taj prijedlog ide od PM, ne čeka da netko riješi njegov problem. Rezultat: ova edukacija se pokzala iapk boljom nego nikakva edukacija. Ima problema u prvim danima ali ni blizu problemima kod Zvjezdana.
- Izazov br. 7 Faza Closure – završavanje projekta Završila je migracija, sve poslovnice rade na novom sustavu. Zvjezdan radi Exit report. Opseg: isporučeno je 100 originalih i 20 dodatnih funkcionalnosti. Nisu isporučene funkcionalosti vezane za zahtjev regulatora. Zahtjev regulatora je riješen kroz novu satelitsku aplikaciju koja se sad mora naknado uključiti u sustav – što je zahtjev za sljedeću fazu projekta. Nakon početnih problema korisnici su se priviknuli na aplikaciju. Budget:originalni budget je povećan za dodane MD partnera, trošak satelitske aplikacije i trošak povećanog broja MD internih i eksternih resursa. Naravno, nitko nije odobrio one obećane nagrade za članove tima jer Zvjezdan nije ni tražio jer bi bio sigurno odbijen. Rok: dodatnih 4 mjeseca na prvi plan.
- Tihi radi Exit report Opseg: isporučeno je 90 originalih i 20 dodatnih funkcionalnosti. Isporučene su sve funkcionalosti vezane za zahtjev regulatora. 10 izbačenih funkcionalosti rješavat će se u drugoj fazi projekta. Budget :originalni budget je povećan za trošak prekovremenog rada. Rok: u skladu s prvim planom Primopredaja: planirana i realizirana. Nitko ne zove Tihog jer postoji jasna podjela uloga i odgovornosti po pitanju održavanja aplikacije.
- Zaključak: Što je Zvjezdan radio krivo a Tihi dobro? 1. Jasne uloge i odgovornosti! 2. Osnaživanje članova tima! 3. Iskustvo je bitno – ne ponavljati greške već učiti iz njih a posebno učiti iz tuđih grešaka 4. Change mgmt je ključan za uspjeh projekta, PM nije ovlašten odlučiti o opsegu – funkcionalostima u projektu – to odlučuje Sponzor a PM radi prijedloge – Change Management mali primjer: Rok je prvi prioritet na projektu a ni budget baš ne smijemo probijati. Što nam je za činiti. Ono što je ostalo je opseg odnosno smanjivanje funkcionalosti. (teoretski možemo ostaviti i opseg isti a smanjiti kvalitetu isporuka ali to je već sfera muljanja pa nećemo dalje). Da li PM može sam donijeti odluku o smanjenju opsega? 5. Aktualno stanje – da bi uopće razgovarali o change managemenu onda je preduvjet za PM-a da zna u svako doba trenutno stanje na projektu – što je isporučeno od opsega, što je potrošeno iz budgeta i koji je status aktivnosti što kasni i koje su posljedice kašnjenja. Bez aktualnog stanja nema ni Change managementa 6. Primopredaja – od prvog dana planirati primopredaju 7. Motivirani članovi tima – i kad nemate nagrade na projektu mžete imati motivirane članove tima (osnaživanje, uloge i odg). Projekt bez motiviranih članova je sigurna pušiona. Tko je odgovoran za motivaciju – PM!
- Izvrstan PM je conditio sine qua non uspješno realiziranog projekta! Točno/Netočno? Sad već znate odgovor! Bez dobrog PM-a nema uspješnog projekta. Vidjeli smo na primjeru gdje su svi sudionici izvrsni ali PM je podabacio i kakav je rezutat – loš, skuplji, kasni i nije isporučio sve što je potrebno. S druge strane imali smo osrednje sudionike ali izvrsnog PM-a i kao rezultat smo dobili ono što je definirano opsegom, u zadanom roku i okviru budgeta. OK nije sve savršeno neke funkcionalosti su izostavljene – ali to je učinjeno sukladno pravilima struke i korisnik je znao za to, potvrdio to i nije bilo neugodnih iznenađenja ili razočarenja na kraju projekta. Možetze dobiti loše članove tima, lošeg sponzora, neodređen opseg i unatoč tomu dobar PM može sve to riješiti na način da svi izađu zadovoljni i kao pobjednici!! Zbog toga je PM ključni sastojak uspjeha projekta.
- Sad je pitanje da li i vi dijelite to mišljenje nakon ove prezentacije. Kao što smo obećali na početku, ponovit ćemo anketu: Odgovor ostavljam vama. Ako sam uspio podići postotak onih koji smatraju da je PM ključan za uspjeh projekta s onih početnih xx % onda mi je stvarno drago jer je ovo predavanje postiglo svoju svrhu!