Projektni blog

... ali drugače povedano: projekti, kjer se lahko trije, štirje izvajalci za eno mizo sami zmenijo vse.  Ne potrebujejo nobene dokumentacije, nobenih planov, nič sestankov, nobene metodologije ali standardov. Sami se bodo o vsem dogovarjali sproti. Nekateri si bodo (-ste) hitro oddahnili: Huh, kakšno olajšanje - dajmo tudi mi imeti takšne projekte!

Pa takšni projekti obstajajo? ... in ali so to resnično projekti (glej definicijo projekta)? Kako pravočasni so lahko? Zanima me tudi, ali bodo ti trije mojstri čez 2 tedna še vedno složni glede vsebine izza mize, ko so prvič sedeli skupaj. Tudi v detajlih? Brez dvoma o njihovi delovni zagnanosti: kako bodo medsebojno koordinirali aktivnosti, ali bodo sploh komunicirali? Kaj pa če imajo poleg tega projekta še redne službene obveznosti in ostale projekte? Upam, da vam je že jasno, kaj želim povedati...


Projekt Povejmo.si

Povezava do portala Povejmo.si

Udeležen sem bil v projektu razvoja portala povejmo.si, ki je tipičen takšen projekt - manjši. Povrh pa tudi nima zahtevnega zunanjega naročnika in deluje povsem na prostovoljstvu - kar v praksi pomeni veliko skušnjavo po neorganiziranosti, ležernosti in zanašanju na entropijo. Kljub temu nam je uspelo vnesti zdravo mero projektnega vodenja, ki pazi na minimalno dokumentacijo, smiselno obvladovanje tveganj in preudarno komunikacijo. Nekaj tega, kar sem projektu osebno doprinesel in se od njega tudi dodatno naučil, vam bom v nadaljevanju predstavil kot inspiracijo za vaše manjše projekte. Torej ne nujno IT-jevske.

Vodenje manjših projektov

Kriterij, da je nek projekt manjši, je odvisen od konsenza znotraj vsake organizacije. Nekje je meja določena kvantitativno (npr. 30 človek/dni), drugje časovno (trajanje 3 mesece) ali pa kadrovsko (do 6 projektnih članov), pomembno pa je le, da klasifikacija temelji na ključnih posebnostih organizacije. Številčno je manjših projektov ponavadi cca. 5-krat več kot velikih. In razmerje se še povečuje. 

Izpostavljam torej nekaj uporabnih napotkov iz primera povejmo.si, ki karseda elegantno poenostavljajo vodenje slehernega manjšega projekta:

1. obseg projekta - KAJ sledi po možnosti iz pred-projektne dokumentacije (ponudba, pogodba) ali pa je to pomembno začetno vprašanje, na katerega mora manjši projekt še odgovoriti (nastanejo funkcijske specifikacije, VDP, ...). Ker ljudje (izvajalci) na manjših projektih ponavadi dokumentaciji niso naklonjeni in se (zelo pomembnega!) dokumenta z definiranim obsegom projekta ne bodo dnevno posluževali, je najbolj optimalno, da KAJ narišemo v sliko oz. shemo. Nastane WBS, ki razčleni cilj projekta navzdol do povsem konkretnih potrebnih rezultatov in razgrne vse pod-izdelke projekta.
2. terminski plan - KDAJ. Projekt povejmo.si ni imel tipičnega operativnega terminskega plana, pač pa je tudi to vlogo prevzela WBS, ki smo ji dodali časovne označbe (KAJ do KDAJ, skupaj z KDO in opombami). Sicer pa se terminski plan lahko izdela in vodi v gantogramu ali pa se ga tabelarno definira kot akcijski načrt. MS Project za manjše projekte že od nekdaj ni bil najbolj praktično orodje - verjetno zato, ker projektni vodja tu ni profesionalec (dediciran), pač pa primarno eden od izvajalcev.
3. vodenje projekta - KAKO. Pri manjših projektih pride v poštev predvsem agilno vodenje projektov - ki temelji na odnosu, komunikaciji in prilagodljivosti. Projekt povejmo.si si je za osnovo vzel SCRUM agilno metodologijo z eno- ali dvo- tedenskimi šprinti. Kot backlog je priročno služila že izdelana WBS.Vsakemu elementu WBS je bilo možno dodati tudi status in označbo tveganja, s čimer je WBS implicitno postala tudi register tveganj. Določeni odgovori (akcije) na tveganja pa so postali dodatni delovni paketi znotraj WBS.
4. vloge - KDO. Za majhne projekte je vedno značilno prekrivanje vlog - en član bo nosilec več različnih odgovornosti. Npr: projektni vodja bo tudi poslovni analitik, poslovni analitik bo tudi tester... Sam sem tako v I. fazi projekta (razvoj, postavitev), ki je sedaj za nami, prevzel funkcijo konzultanta dobrih projektnih praks, projektnega vodje in izvajalca (programerja v WordPress, PHP, CSS, mySQL in jQuery). Že pri pridobivanju projektne ekipe je potrebno vedeti za kakšno vrsto dela bomo koga potrebovali in ga z njegovim prihodom tudi ustoličili. Aktivnosti z odgovornostmi bodo podrobno definirane v WBS, vloge pa (krovno za celoten projekt) v RICH matriki (Responsible, Informed, Consulted, Helping). RICH matrika je inovativen derivat RACI matrike, ki je nastal tekom projekta povejmo.si, in pomeni prilagojeno RACI matriko za agilne projekte v flat organizaciji. Medtem ko RACI temelji na hierarhični organizaciji projekta in je večinoma primerna za večja korporativna okolja in kompleksne projekte (npr. razlikuje med "odgovoren" in "zadolžen"). Uporaba RICH matrike pa dokazano spodbuja tovarištvo in proaktivnost med člani projektne ekipe.
5. dokumentacija (zapisi) je bila minimizirana na malo (a s tem toliko bolj pomembnih) dokumentov. Dokumenti morajo biti interno dostopni z možnostjo večuporabniškega dopolnjevanja. Sestanki in posledično njihovi zapisniki naj bodo kratki in naj jasno opredeljujejo odgovornosti (s časovnimi roki) posameznih članov ekipe.

Navedeni način je deloval optimalno na projektu izgradnje portala povejmo.si. Ocenjujem, da bi na zelo podoben način uspešno uzakonili tudi izvedbo manjših projektov v profitnih in neprofitnih organizacijah, kjer je "projektni vodja" zgolj začasna odgovornost zaposlenega.