Ne radi ništa bez jasne svrhe

Ne bi trebalo da radiš nešto osim ako nema jasnu svrhu. Zamisli dva paralelna sveta gde je sve isto osim toga što u jednom svetu razmišljaš o onome što radiš, a u drugom ne: koliko bi se razlikovala ta dva sveta? Da li je razlika vredna truda da se to (ne) uradi?

Ako ti nije jasna svrha i radiš nešto samo zato što i svi ostali to rade, ili svako kaže da je važno da se to radi, onda:

• Možda u tvom slučaju to nema stvaran benefit, pa stoga ne dobijaš ništa radeći to; ili
• Možda u tvom slučaju ima potencijalne benefite, ali pošto ti nije jasna svrha, način na koji to budeš radio možda ti neće pomoći da ostvariš te benefite.

Primer: Portfolija i programi

Ako si uključen u izbor i inicijaciju projekata, fokusiraj se na benefite i probleme koji treba da se reše pre nego na proizvod koj treba da realizuje ove stvari. Klasičan primer je proizvođač liftova koji je primao žalbe na brzinu svojih liftova, pa je pokrenuo više projekata da bi popravio brzinu liftova, ali bez potpunog uspeha. Ovo se nastavljalo sve dok nisu odlučili da se fokusiraju na problem (dosađivanje ili nelagodnost u liftu) umesto “prirodnog” rešenja (bržih liftova). Rezultat je bio taj da su dodali ogledala u liftove i rešili problem jednostavno i jevtino.

Zapamti da je za projektani menadžment uglavnom važno “raditi stvari na pravi način”, dok je za portfolio menadžment važno “raditi prave stvari”. Nije važno koliko dobro vodiš svojе projektae; neće dobro funkcionisati ukoliko radiš pogrešne projektae. Sve je u svrsi.

Primer: Projekat kao celina

Fleksibilnost proizvoda varira od projekta do projektaa. U nekim IT razvojnim projektaima, proizvod je potpuno fleksibilan i njegov finalni oblik zavisi od povratne informacije koje će uslediti nakon inkrementalnih faza proizvoda kroz projekat, što zahteva adaptivni (Agile) pristup. U praktičnom smislu ovo je kombinacija slojeva portfolija, programa i projekata i potreban je maksimum pažnje posvećen krajnjem cilju. Dobra ideja je dokumentovati svrhu i imati je uvek na dohvat ruke; to je jedna od svrha “vizije proizvoda”, kako se koristi u nekim Scrum projektaima. Akcenat na poslovnu vrednost u Agile projektaima je njegov način osiguranog usklađivanja sa svrhom.

U drugim vrstama projektaa, gde je proizvod relativno fiksan i postoje drugi mehanizami kontrole da proizvod zadovolji svrhu, moguće je da članovi projektanog tima pomere fokus sa svrhe na proizvod (otuda princip “fokus na proizvode” PRINCE2^®), ali u najmanju ruku minimum pažnje posvećen svrsi je još uvek potreban da bi se obezbedilo da ono što se stvara služi svrsi, što se može ostvariti poređenjem predviđenih i očekivanih benefita (otuda princip “kontinualnog poslovnog pravdanja” i “business case” Tema u PRINCE2^®).

Ako se projekat radi za eksternog klijenta, klijent želi svoju sopstvenu svrhu za projekat, a vaša kompanija će imati svoju svrhu. Potrebno je da razumete i koristite obe da bi stvarno uspeli.

Primer: Monitoring projektaa

Fokusiranje na krajnju svrhu je neophodno. Ali možda i previše apstraktno za većinu svakodnevnih primena. Za praktičnu primenu potrebno je uspostaviti hijerarhiju pokretača. Kao prvo, poslovno opravdanje i benefiti projekta definisani su shodno krajnjoj svrsi, a shodno njima eksplicitni i implicitni targeti za projektane varijable (tj. vreme, trošak, kvalitet) da bi se zadovoljilo poslovno opravdanje, što bi na kraju zadovoljilo krajnju svrhu. Ovo su svrhe nižeg nivoa koje su korisne za mnoge od naših dnevnih zadataka.

Kada se radi o monitoringu, monitoring nižeg nivoa u projektu pratiće varijable niženg nivoa, jer možda neće biti moguće pratiti krajnju svrhu. U ovom slučaju, ne treba zaboraviti na svrhu: šta je svrha monitoringa?

Normalan i prihvatljiv odgovor je videti da li dobro pratimo plan, ako ne, inicirati odgovarajuću reakciju koja će nas dovesti nazad na u okvire plana ili ponovo podesiti targete i videti da li konačna svrha još uvek može biti zadovoljena. Naša merenja stoga treba da nam pomognu oko ove svrhe nižeg nivoa, a odgovarajuća merenja su prognoze za projektane varijable na kraju projektaa; npr., kada ćemo moći da zavrišimo projekat? Koliko novca nam je potrebno da završimo projekat?

Sva druga merenja, kao što su planirane i aktuelne vrednost na dan, samo su međuvrednosti koje su nam potrebne da bi kalkulisali prognozu, a ne konačne vrednosti za svrhe menadžmenta.

Primer: Dokumenti

Bez obzria koji development pristup koristimo u projektu, planiranje je uvek neophodno. Važno pitanje je nivo detalja u svakom tipu plana. Ako nema dovoljno detalja u planu, plan neće moći dovoljno da doprinese, a izvršavanje projekta zasnivaće se na ad-hoc odlukama pre nego na integrisanim, holističkim. Sa druge strane, puno ljudi pokušava da bude oprezno, pa dodaje previše detalja u plan, što ga čini teškim za pripremu i održavanje, i previše rigidnim za neizvesnosti u projektu. Kao rezultat, plan postaje nerealan i beskoristan.

Najbolji način da se odluči o nivou detalja je imati svrhu na umu za svaki element u planu. Na primer, ako razmatraš dodavanje resursa u plan, to treba da ima svrhu: kako ćeš ga koristiti? Kako će to pomoći projektu? Koliko The best way to decide about the level of detail is to have a purpose in mind for every element in the plan. For example, if you’re considering the addition of resources to the plan, you should have a purpose for it: How are you going to use it? How will it help the project? Koliko napora će to proizvesti? I da li se isplati?

Ponekad se radi o tome da li želiš neki element u svojim planovima, a nekad o načinu na koji planiraš i pripremaš nešto. Bilo da je business case, projektana povelja, ili izveštaj: uvek se pitaj zašto pripremaš taj dokument i kako može da pomogne projektu.

Traženje raznih “template”-a po web-u je sušta suprotnost činjenja nečeg baziranog na svrsi.

Primer: Statusno izveštavanje

Česta je pojava predugih statusnih izveštaja u mnogim projektaima. Polazeći od ovog NUP-a, treba da se zapitamo koja je svrha izveštaja i kako je možemo postići bez obzira šta drugi rade po tom pitanju.

Ovo nas u mnogo slučajeva može voditi ka pripremi veoma jednostavnih izveštaja na jednoj stranici koje će stakeholderi zaista čitati i razumeti, za razliku od dugih izveštaja. Ovo je poklanjanje pažnje svrsi.

Ako pripremaš izveštaj od jedne strane, doduše neki ljudi mogu da i to zamere i misle da nemaš postavljen adekvatan monitoring sistem. U praksi, ovo kreira tebi sekundarnu svrhu (osim primarne, a to je pomoć stakeholderima da razumeju status projektaa), a da bi to zadovoljili, možete prosto kreirati drugi tip izveštaja koji će biti dugačak. Ipak, ne mešajte ova dva izveštaja, jer im je i svrha različitia.

Primer: Business case i projektana povelja

Pripreme dokumenata kao što je business case i projektana povelja obično je dosadna, jalova, birokratska neophodnost za većinu ljuid, dok svi ovi dokumenti imaju valjanu svrhu koja važi za većinu projekata. Ako pokušaš da pronađeš “template” i popuniš ga, vreme je protraćeno; umesto toga bolje je da proveriš pravu svrhu ovih dokumenata, vidiš da li i kako mogu biti od pomoći u projektu, a onda pripremiš dokument na način kako želiš, isključivo da zadovoljiš svrhu: to će onda biti pravi dokument.

Dok razmišljaš o načinu pripreme dokumenata da bi zadovoljili svoju svrhu, možda nećeš imati na umu svaki scenario i zato nešto propustiti. Da bi to izbegao, proveri sve resurse, kao npr. PRINCE2^®, PMBOK^® Guide, P3.express, I DSDM^® sugestije, i onda evaluiraj ove sugestije zasnovano na svrsi.

Primer: Post-projekat

Sve dok projekat ima specifičnu svrhu (a svrhu možemo preispitivati tokom projektaa) , realizacija svrhe uglavnom se vrednuje na osnovu prognoza nastalih tokom projektaa. Ipak, ne smemo da zaboravimo na to ni kad se projekat završi. Važno je proveriti realizaciju ciljeva nakon kraja projektaa, jer:

• Možemo videti kako se postižu krajnji ciljevi i učiti iz toga za buduće projektae, i,
• Ponekad se ciljevi ostvare samo ako se obave neki dodatni zadaci nakon projektaa, a za razumevanje neophodnosti ovih ekstra zadataka potreban je monitoring.

Post-projektani monitoring je neophodan korak ako smo vođeni svrhom. Ovo je uglavnom odgovornost sistema za upravljanje progama i portfolia, a pošto većina kompanija nema takve nivoe menadžmenta, ovaj korak se obično zanemaruje. Zbog toga metodi kao P3.express and DSDM^® dodaju ovaj korak u svoje metodologije projektanog menadžmenta.

Primer: Jednostavnost

Svet je kompleksan i haotičan, ali naši modeli su apstraktne aproksimacije koje odražavaju delove sveta, pa su stoga jednostavne. Sa druge strane, jednostavni sistemi obično funkcionišu bolje, jer možemo da se fokusiramo na glavnu ideju.

Mnogi od nas pokušavaju da dobiju bolje rezultate dodajući kompleksnost u sistem, nadajući se da će odslikati kompleksnost sveta, čak i ako u praksi ovo otežava rad sa sistemom i obično nas sprečava da zadovoljimo svrhu.

Primer: Prilagođavanje – “krojenje”

Softver za streaming muzike ima različite uslove od onog koji se koristi za opremu u bolnici ili u avionu gde od toga zavise ljudski životi, ili od softvera koji će se koristiti u satelitima gde treba da rade mnogo godina bez “pada sistema”. A svi pomenuti softverski projektai razlikuju se od izgradnje letnje vile, vatrogasne stanice, ili postrojenja za preradu.

Ako imate svrhu na umu, bolje ćete razumeti kako prilagodite – “skrojite” sisteme i artefakte za različite projektae.

▼ PDF