Blog, debatni večeri, raziskave, knjiga…

Category: O projektih Page 1 of 2

Uspešnost (in učinkovita izvedba) IT projektov v Sloveniji

Najbrž ste opazili, da sem prispevke na tem blogu aktivneje objavljal le dve obdobji – v času pisanja obeh knjig. Z željo, da bi pomagal slovenskim projektnim timom k uspešnejši izvedbi projektov, sem vsebino knjig na blogu predstavil v strnjeni obliki – praktično je tretjina knjig prikazana tukaj, knjigi pa sta bogatejši za podrobnejšo razlago, moja razmišljana, predloge za prakso in primere iz prakse.

Pred časom pa sem prejel zanimivo vprašanje: »Ali imate morda kakšne novejše podatke glede uspešnosti IT projektov v Sloveniji?« Ker menim, da odgovor na to vprašanje zanima več ljudi, sem se odločil, da ga objavim tukaj na blogu. Odgovor sloni na moji raziskavi iz leta 2020, ko sem pripravljal knjigo »Agilno!?«. V raziskavi je sodelovalo 286 podjetij in drugih združb (tukaj je nekaj ključnih ugotovitev), med temi pa se je četrtina odgovorov nanašala na IT projekte.

Preden pa predstavim ugotovitve raziskave, pa naj še enkrat opozorim na razlikovanje pojmov učinkovito in uspešno (kar sem podrobneje razložil tukaj). Uspešen projekt naj bi bil tisti, pri katerem – finančno gledano – koristi, ki izhajajo iz rezultatov projekta (prihranki, prihodki), povrnejo investiran denar. Če pa govorimo o tem, ali je bil projekt zaključen pravočasno (in v proračunu), pa uporabljamo pojem učinkovite izvedbe. Seveda obstaja tudi vrsta nefinančnih sodil uspešnosti projektov, ki si jih tudi lahko ogledate v že omenjenem prispevku.

Dilema glede pojma »uspešnost« IT projektov pa ni prisotna le v Sloveniji, zato priporočam, da vedno, ko preberete, da je npr. “le 37% projektov uspešno zaključenih“, preverite, na osnovi katerih sodil so prišli do te ocene. Lahko, da je projekt zamudil za petino planiranega časa, a je prinesel zelo zadovoljive rezultate – torej je bil uspešen, kljub neučinkoviti izvedbi.  Razlikovanje obeh pojmov je pomembno tudi z vidika odgovornosti – manager projekta je predvsem odgovoren za učinkovito izvedbo, uspešnost pa je odvisna tudi od drugih deležnikov oz. dejavnikov.

No, po daljšem uvodu poglejmo, kako smo IT projekte izvajali v letu 2020. Kot sem omenil, je vzorec je vseboval 77 podjetij, katerih predstavnike sem pozval, naj navedejo povprečne vrednosti sodil za svoje projekte – stanja torej ne prikazujemo na osnovi 77 projektov, ampak na osnovi kakih 3500 (povprečje števila izpeljanih projektov na leto v obravnavanih podjetjih je skoraj 50). Naj povem še to, da je bilo govora o širokem naboru IT projektov (razvoj in uvajanje IT rešitev, razvoj aplikacij za osebne računalnike in pametne telefone, ERP sistemske rešitve, podpora obvladovanju dokumentacije, postavitev spletnih strani, ipd.).

Prva slika prikazuje odstotek projektov, ki so bili (po posameznih sodilih) izpeljani po planu, druga pa povprečno odstopanje projektov, ki niso bili izpeljani po planu. Naj še omenim, da je 27 (35%) sodelujočih navedlo, da projekte izvajajo ciklično (agilno), zato na slikah prikazujem tri podatke.

Seveda me je zanimala tudi uspešnost projektov. Ker sem raziskoval različne tipe projektov (ne le IT), žal nisem uporabil poglobljenega nabora sodil uspešnosti, ki jih predlaga Atkinson (to prepuščam drugim raziskovalcem). Zato prikazane ugotovitve mogoče niso ravno najbolj uporabne (majhen razpon ocen, med 2,3 in 2,8), vseeno pa lahko ugotovimo, da je pred nami še kar nekaj dela, da bi dosegli raven »vzorno«.

Ocena uspešnosti: 1 – manj zadovoljivo, 2 – zadovoljivo, 3 – dokaj zadovoljivo, 4 – vzorno

V nadaljevanju pa prikazujem še nekaj zanimivih ugotovitev glede dejavnikov, ki vplivajo na učinkovito izvedbo in uspešnost projektov. Če pogledamo (ne)sistematičnost uporabe metod projektnega dela, lahko rečemo, da je stanje dokaj zaskrbljujoče, hkrati pa to nekako pojasnjuje nizek odstotek učinkovito izpeljanih projektov. Gledano z bolj optimističnega vidika pa lahko rečemo, da dobro vemo, kje in kako se lahko izboljšamo 😊, kar je odlična osnova za začetek izboljševanja našega delovanja.

Pa še pojasnilo ocen v spodnjih slikah. Anketiranci so ocenili pogostost uporabe pristopov, metod in tehnik: 1 pomeni nikoli, 2 redko, 3 pogosto, 4 pa redno.

Tradicionalni in ciklični projektni življenjski cikel

V naslovu sem namenoma uporabil besedo “tradicionalni”, namesto “slapovni” (ang. waterfall), katerega sicer uporablja večina promotorjev agilnih pristopov. Razlog je v tem, da v podjetju, v katerem sem delal v času »informacijske revolucije«, že v zgodnjih 90-tih nismo več uporabljali klasičnega slapovnega pristopa, ampak (delno) sočasnega, kar pomeni, da so se sicer zaporedne faze prekrivale. Lahko bi rekli, da je bil v slovenski praksi klasični »waterfall« že zdavnaj »iz mode«, ko se je pojavil agilni manifest…

Dilemo glede poimenovanja »ne-agilnega« pristopa pa so razčiščevali tudi avtorji priročnika Agile practice guide (PMI, 2017). Ti poleg slapovnega omenjajo še pojme, kot so plansko usmerjan (ang. plan driven) in serijski (ang. serial), priporočajo pa uporabo pojma predictive, s katerim pa imam sam nekaj težav glede prevoda. Napovedni, predvidljivi…? V komentarju bi bil vesel kakšnega vašega predloga 😊.

Sicer pa literatura poleg agilnega in tradicionalnega življenjskega cikla projekta (PMLC, project management life cycle) omenja še dve vrsti, o čemer sem nekaj pisal že pred leti. Takrat sem povzel Wysockega (2009), tu pa se ponovno naslonimo na Agile practice guide, ki omenja še:

  • ponavljajoč pristop (ang. iterative), ki omogoča oziroma zagotavlja povratne informacije o nedokončanem delu za izboljšanje in spreminjanje le-tega, ter
  • postopen pristop (ang. incremental), ki vsakem ciklu zagotovi delujoč delni izdelek, ki ga je že mogoče uporabiti.

Agilni pristop pa naj bi bil tako ponavljajoč, kot postopen – pristop, ki s pomočjo povratnih informacij stalno dostavlja uporabne (pol)izdelke.

Kontinuiteta življenjskih ciklov projektov

Življenjski cikli projektov (Agile Practice Guide, PMI, 2017)

Poglejmo še, v katerih primerih bi bila najbolj smiselna uporaba posameznih pristopov. Kot je prikazano na sliki, naj bi izbira slonela na dveh dejavnikih: možnosti dobav oziroma uporabnosti vmesnih rezultatov (oz. pogostosti dobave le-teh) ter stopnji spremembe oz. novosti, ki jo prinaša projekt.

Tradicionalni pristop naj bi se tako uporabljal, ko so rešitev in zahteve dokaj jasno določene in se naj ne bi veliko spreminjale, pri tem pa delnih rezultatov uporabniki ne morejo koristiti. Wysocki (2009) še navaja, da so projekti rutinski in ponovljivi, uporabljajo pa se preizkušene metode. Vse navedeno bi vsekakor veljalo za gradnjo in druge inženiring projekte.

Ponavljajoč pristop je uporaben za projekte, ko rešitev in zahteve niso jasno dorečene, glede na izkušnje iz preteklih projektov pa tim lahko pričakuje tudi kar nekaj sprememb. Wysocki dodaja, da tim pri tem dokaj dobro pozna možne alternative rešitev. Tudi pri tem pristopu pa delnih rezultatov ni mogoče koristiti. Glede na navedeno, je pristop primeren za razvoj izdelkov z malo neznankami (kjer ni potrebnih raziskav), sploh pri prilagajanju izdelkov po željah kupca.

Postopen pristop naj bi se koristil, ko je možno koristiti delne rezultate, zahteve pa so dokaj jasno določene in se naj ne bi veliko spreminjale. Lahko bi rekli, da je je uporaben za izobraževanje, razvoj (nekaterih) storitev.

Glede na vse navedeno naj bi torej agilen pristop uporabili, ko rešitev in zahteve niso jasno dorečene, delne rezultate pa lahko koristimo, poleg tega pa mogoče niti vnaprej ne vemo, katere metode bomo uporabili pri delu. To je vsekakor značilno za raziskovalne projekte, v novejšem času pa seveda za razvoj programske opreme (kjer so se agilni pristopi tudi razvili in uveljavili), predvsem spletnih rešitev in aplikacij za telefone. Vsekakor je v tem primeru možno koristiti rešitve z osnovnimi funkcijami, dodatne pa se razvijajo postopno, glede na želje (in ideje) uporabnikov.

Ali je povsem agilen pristop uporaben tudi za razvoj izdelkov? Mogoče delno kombiniran, v začetku tradicionalni, nato agilen? Več o tem bom napisal v knjigi, kjer bom predstavil tudi rezultate raziskave, ki sem jo izvedel v maju. Vse skupaj nas najbrž tudi zanima, kateri pristop bi bil pravi za druge vrste projektov … organizacijske (interna reorganizacija ali tista, povezana s prevzemi in združitvami), kateri za organizacijo dogodkov. Tu so še marketinški projekti, pa produkcija televizijskih oddaj, snemanje filmov…

Zaključno poročilo in ugotavljanje uspešnosti projekta

Ne glede na to, ali je projekt uspešno končan ali zaradi kateregakoli razloga prekinjen, se ob koncu (ali prekinitvi) izdela zaključno poročilo, ki vsebuje predstavitev rezultatov, odstopanja le-teh od planiranih, razloge za ta odstopanja, analizo napak in morebitnih zamud projekta ter finančno poročilo. V poročilo je priporočljivo vključiti tudi vse pridobljene izkušnje ter analizo tveganj in sprememb.

Poročilo izdela manager projekta, lahko tudi s pomočjo projektne pisarne. Aktivnosti za izdelavo končnega poročila se naj ne bi odlagale do zaključka projekta – vsaka faza projekta se običajno zaključi z vmesnim poročilom, tudi zato, da se ne bi izgubila kakšna pomembna informacija. Izdelava končnega poročila je za “striktnega” managerja projekta tako le povzetek faznih oziroma rednih vmesnih poročil. Tako kot vsa dokumentacija projekta, se tudi končno poročilo po formalni odobritvi arhivira za potrebe kasnejših projektov.

Zaključno poročilo se običajno predstavi ključnim deležnikom projekta, v prvi vrsti skrbniku in nadrejenim managerjem. Posebej se predstavi zunanjemu naročniku (običajno brez informacij o stroških izvedbe), tretja možna predstavitev pa je namenjena drugim managerjem projektov v združbi. Namen izdelave poročila je namreč dvojen: prvič, tim si izdela »čisto sliko« o kakovosti svojega dela (del tega je prejšnjič predstavljena ocena izvedbe); in drugič, s poročilom se pridobljene izkušenje prenesejo na kasnejše projekte. V javnem sektorju, kjer se projekti financirajo s proračunskih sredstev, poznajo še tretji namen poročila – revizijo projekta (ki preveri, če so bila javna sredstva racionalno trošena). V tem primeru je poročilo podrobnejše in obsežnejše predvsem z vidika financ.

Priprava in vsebina zaključnega poročila projekta

Pri nekaterih avtorjih sem naletel na trditev, da zaključno poročilo vsebuje tudi oceno uspeha, učinka ali prihodkov projekta oziroma, da koristi primerjamo s tistimi iz predloga projekta. Tu bi bralca spomnil, da je potrebno razlikovati med uspešnostjo in učinkovitostjo (več o tem…).

Poslovni uspeh projekta seveda lahko takoj, še pred pripravo zaključnega poročila, pomerimo v primeru izvedbenih projektov za zunanjega naročnika (takojšnje plačilo) ali pri organizaciji prireditev. Pri večini ostalih vrst (internih) projektov bi koristi lahko prvič »pomerili« ob koncu poskusnega delovanja (izvajanja, uporabe) prenovljenega procesa, nove IT podpore, nove metode dela, nova proizvodne linije ali prenovljenega objekta, ipd. Poskusno delovanje je namreč običajno del obsega in ena od aktivnosti projekta, zato se zaključno poročilo izdela šele po koncu tega preizkusnega obdobja. Nasprotno pa prihodke trženja novo razvitega izdelka ali pa nove poslovalnice ne moremo ugotoviti takoj, ker je potreben čas za uveljavitev na trgu.

Ne glede na to, če smo po poskusnem delovanju pomerili učinke (hitrejši proces, manj ur dela, manj napak, prihranek pri materialu, energiji…) in jih finančno ovrednotili, je potrebno za »čisto sliko« učinke projekta spremljati daljše obdobje (npr. eno leto), kar pa ni nujno, da izvaja projektni manager, sploh pa ne člani tima, ki so po predaji proizvodov prevzeli naloge na drugih projektih ali so se vrnili na vsakodnevna opravila v sklopu matičnega oddelka. Za merjenje učinkov je torej potrebno določiti osebo ali oddelek (predstavnik uporabnikov, kontroling, projektna pisarna) ter opredeliti metriko, pogostost merjenja in način poročanja.

Čeprav dejansko ugotovljene koristi za projektni tim, ki je izvedel projekt, niso nujno potrebna informacija, jim je vsekakor priporočljivo sporočiti ugotovitve merjenja, ki so lahko dodatna povratna informacija kakovosti njihovega dela, če pa je projekt zelo uspešen, pa je to še en razlog za odprtje šampanjca. Po koncu projekta uspeh lahko proslavimo trikrat, a o tem več prihodnjič.

Zaključevanje projekta

Čeprav zaključevanje projekta, bolj kot katera koli druga faza, zahteva izjemno raznolik nabor tehničnih, organizacijskih in vodstvenih veščin, raziskave na žalost kažejo, da je to v praksi najbolj “prezrta” in najmanj sistematično izpeljana faza. Projekt se ne zaključi sam od sebe, z zadnjo izpeljano aktivnostjo faze izvedbe, ampak je naloge in opravila zaključevanja projekta potrebno skrbno načrtovati, usklajevati in kontrolirati!

Večino avtorjev navaja, da je zaključevanje projekta samostojna faza s tipičnimi aktivnostmi, čeprav za razliko od drugih faz projektnega cikla ne obstaja močna razmejitev med fazo izvedbe in zaključevanja, kakor prehod med fazama tudi ne vključuje sestanka z ostalimi deležniki, ki bi potrdili, da projekt lahko preide v fazo zaključevanja (kot to lahko velja za prehod med posameznimi fazami izvedbe).

Dva sklopa aktivnosti zaključevanja projekta

Stroka običajno deli aktivnosti zaključevanja v dva sklopa, pri čemer eni pišejo o zaključevanju del in administrativnem zaključku (kot je to prikazano na sliki), drugi pa zaključevanje del poimenujejo zaključevanje pogodb, ki pa tudi vsebuje predajo in verifikacijo proizvodov projekta. Zasledil sem tudi delitev na štiri sklope – aktivnosti v povezavi z naročnikom (predaja in potrjevanje rezultatov, usposabljanja), organizacijsko učenje (dobre in slabe prakse, zaključno poročilo), kadrovske zadeve (ocena članov tima in nagrajevanje) ter upravno administrativne zadeve (plačila in zaprtje računov, arhiviranje dokumentacije).

Pri nekaterih avtorjih sem naletel na predlog, da se v začetku zaključevanja projekta pripravi terminski plan vseh opravil z odgovornimi (angl. punch list schedule & punch list RAM), podobno, kot se pripravi terminski plan aktivnosti projekta, pri čemer naj bi večina aktivnosti lahko potekala vzporedno ali z rahlim prekrivanjem. Izvedba zaključnih aktivnosti se pogosteje kontrolira kot je to običajno v fazi izvedbe, kakor so tudi pogostejši sestanki projektnega tima z drugimi deležniki projekta, še posebej z naročnikom.

Včasih pa se zgodi, da se projekt zaradi dogodkov v okolju projekta (zakonske spremembe, aktivnosti konkurence, problem financiranja, odločitev naročnika) prekine ali celo zaključi pred planiranim koncem, ne da bi dosegli zastavljene cilje. Čeprav v tem primeru običajno odpade nekaj aktivnosti zaključevanja del, pa je potrebno opraviti večino na sliki omenjenih nalog. Konec koncev smo se tudi na tem projektu nekaj naučili, kar bi bilo smiselno upoštevati v kasnejših projektih (zaključno poročilo!) in zakaj tudi v tem primeru ne bi organizirali zaključne zabave?

Potrjevanje, izbira in prioriteta projekta

Mogoče se zdi naslov današnjega prispevka malce nerazumljiv, a ga bom takoj obrazložil. Ob koncu snovanja projekta pristojni v združbi (običajno vrhnji management, za manjše projekta pa tudi linijski managerji) sprejmejo odločitev, da se bo projekt izvedel (= potrjevanje), s potrditvijo pa preide v fazo priprave (planiranja). Večkrat se zgodi, da smo zasnovali več projektov, glede na omejene vire (ljudje, denar) pa v danem trenutku lahko izpeljemo le tretjino predlaganih projektov. Katere? (= izbira). Pri tem bodo eni projekti hitreje povrnili vložena sredstva in bodo predvidoma donosnejši ali pa so kako drugače pomembnejši za združbo, zato si zaslužijo “posebno obravnavo” (= večjo prioriteto). Skupno vsem trem pojmom je, da se za odločanje uporabljajo ista orodja oziroma kazalniki, ki jih bom predstavil v tem prispevku.

Zanimivo je, da za opredelitev kriterijev ocenjevanja projektov kar nekaj bolj znanih strokovnjakov v svojih najnovejših knjigah še vedno upošteva priporočila Sounder-ja iz 1973 (Kerzner, 2009; Pinto, 2010; Meredith & Mantel, 2009). Sounder poudarja, da naj bi model za oceno in izbiro projektov zagotavljal smiselnost in realnost ocen, omogočal oceno kompleksnih projektov, a bil vseeno enostaven za uporabo, omogočal vključevanje novih kriterijev ali spremembo obstoječih, pri čemer ocenjevanje ne bi zahtevalo veliko finančnih sredstev. Pinto dodaja še šesti kriterij učinkovitega modela – primerljivost različnih alternativ projekta, Meredith & Mantel pa kot šestega dodajata možnost računalniške podpore.

Večina avtorjev za oceno projektov uporablja le finančno poslovne kriterije, ki smo jih navedli kot del študije izvedljivosti – analizo stroškov in koristi, neto sedanjo vrednost (NSV), dobo vračanja vloženih sredstev ter interno stopnjo donosnosti (IRR). V redkih novejših delih pa sem našel tudi širše nabore kriterijev – poleg omenjenih so dodani tudi poslovni kriteriji, ki jih je težje finančno oceniti, dodani pa so tudi tehnični kriteriji.

Ocena projekta – enostaven odločitveni model

Kriteriji / model ocene projektaPrirejeno po: Heldman (2002), Kerzner (2009), Pinto (2010)

Kerzner (2009) na primeru novega izdelka (po Souderju) oceno projekta prikaže s 25 kriteriji v petih kategorijah (povzemam nekaj tipičnih kriterijev):

  • vrhnji management – ROI, doba vračanja, velikost investicije, vpliv na rast delnic,
  • inženiring – potrebna oprema, znanje, razpoložljivost ljudi,
  • raziskave – možnost patentiranja, znanje, stroški projekta, razpoložljivost ljudi,
  • trženje – življenjska doba izdelka, velikost trga, število konkurentov,
  • proizvodnja – proizvodljivost, razpoložljivost opreme.

Meredith in Mantel (2009) 44 kriterijev razporedita malce drugače kot Kerzner. Navajata proizvodne kriterije (14), tržne (8), finančne (7), kriterije osebja (7) ter poslovne in administrativne (8).

Kerzner predlaga, da se vsak kriterij oceni od -2 (nesprejemljivo) do +2 (odlično), vmesne stopnje pa so slabo, sprejemljivo in dobro (ocene bi bile lahko tudi od 1 do 5). Če želimo poenostaviti izračun, lahko dodelimo skupno oceno skupini kriterijev ali pa izberemo najpomembnejše kriterije, npr. dobičkonosnost, poslovna tveganja in proizvodljivost. Posameznim kriterijem lahko s ponderji določimo višjo pomembnost, kar pomeni, da je npr. ocena dobičkonosnosti “več vredna” od ocene proizvodljivosti (glej sliko). Projekte tako primerjamo med seboj glede na končni seštevek vseh upoštevanih kriterijev.

Kaj pa prioritete? Projekt z višjo vsoto ocen kriterijev naj bi imel višjo prioriteto! Pinto v zvezi s tem poudarja povezanost projektov s strateškimi usmeritvami združbe – visoka pomembnost strategije, iz katere izhaja projekt (strateški cilj = namen projekta), lahko neposredno pomeni tudi visoko prioriteto projekta. Ali pa je to le en od vplivnejših kriterijev.

In kaj prioriteta pomeni za projekt? Pomembnejši projekt naj bi imel vplivnejšega skrbnika z več pristojnostmi, izkušenejšega managerja, prednost pri izbiri članov tima in koriščenju opreme, prednost pri reševanju kriz in problemov… Vseeno pa prioriteta projekta nima “enake teže” skozi celoten projekt oziroma ne velja v vseh primerih. Nesmiselno bi bilo na primer dati prednost neki manj pomembni aktivnosti (ki ni na kritični poti) projekta z visoko prioriteto pred reševanjem zaostanka projekta z manjšo prioriteto, sploh če je slednji bliža zaključku in bo morebitni prepozni zaključek povzročil poslovno škodo združbi!

Snovanje projekta

V tuji literaturi najdemo dva tipična naziva uvodnih faz projekta – conception in initiation. Kot sem navedel v prispevku, kjer sem opredelil faze življenjskega cikla projekta, Oxfordov slovar conception opredeljuje kot proces snovanja ideje ali plana (angl. the process of forming an idea or a plan), slovar tujk pa koncept kot okvirni načrt, koncipiranje pa kot zamišljanje nečesa. Initiation po Oxfordovem slovarju bolj opredeljuje trenutek, kot proces (angl. the act of starting something), a glede na preučene opredelitve obeh pojmov v literaturi, načeloma vsebujeta dokaj podobne aktivnosti. Glede na prevod »koncipiranja« sem se odločil, da bom uvodno fazo poimenoval snovanje projekta.

Frame (2003) navaja, da se projekt začne s potrebo in z željo, da se to potrebo zadovolji. Drugi avtorji »potrebo« prikažejo kot (poslovni) problem (npr. premajhna zmogljivost proizvodnje) ali priložnost (npr. izkoriščanje tržne niše). V večini primerov ima avtor ideje pripravljen tudi že predlog rešitve (nova proizvodna linija, nov izdelek / storitev). Ker pa imajo združbe omejene vire za uresničevanje vseh idej, ideje pa včasih tudi niso tako »genialne«, kot si jih predstavljajo predlagatelji, je potrebno »idejni predlog projekta« še podrobneje oceniti z vidika pričakovanih koristi in zmožnosti izvedbe.

Idejo se zato predloži vodstvu združbe, ki običajno najprej preveri skladnost s poslanstvom in strateškimi usmeritvami združbe, nadalje pa se na podlagi subjektivne ocene smotrnosti ideje odloči, ali bi bila izvedba projekta smiselna. S potrditvijo ideje in določitvijo “snovalnega” tima se začne faza snovanja projekta. Pri tem je potrebno poudariti, da tim, ki zasnuje projekt, načeloma ni isti, kot tim, ki projekt izvede. Vsekakor je bodoči manager projekta lahko član tega tima, ni pa nujno.

Proces in vsebina snovanja projekta

Faza snovanja projekta

Poglejmo še nekaj definicij faze snovanja:

  • Snovanje je prva faza projekta, v kateri se preuči potrebo, ocenijo alternative, ter določijo cilji in skrbnik (sponsor) projekta. Wideman, spletni pojmovnik
  • Snovanje je faza, ki vključuje študijo izvedljivosti projekta, s katero raziščemo zmožnost izvedbe in pričakovane koristi, opredelijo se proizvodi projekta in okvirni plan izvedbe. Charvat (2002)
  • Prva faza projektnega cikla, ki vsebuje obravnavo ideje, odobritev in začetek projekta. Opredelijo se namen in proizvodi projekta. Heldman (2002)
  • Prva faza, kjer se na podlagi zamisli o projektu  ter ocene tehnološke in ekonomske izvedljivosti izdelata okvirna predhodna ocena stroškov ter grobi plan projekta. Kliem & Ludin (1998)
  • Začetna faza, v kateri se opredelijo usmeritve in omejitve projekta. Martin & Tate (2001)
  • Začetna faza projekta, kjer se opredelijo poslovne potrebe, opredli proizvod projekta ter določi managerja projekta. Philips (2004)


V fazi snovanja, ki je običajno v domeni naročnika projekta (uporabnikov), se torej na podlagi idejnega predloga projekta, ki vključuje poslovni problem oz. priložnost ter možne rešitve, oceni smotrnost projekta (kot primerjava zmožnosti in okvirnih stroškov izvedbe ter pričakovanih koristi projekta). Izbere se najboljša rešitev in opredeli obseg projekta. Pri tržno usmerjenih projektih je za večjo zanesljivost potrebno preveriti trg in delovanje konkurence ter oceniti poslovna tveganja. Predvsem v primeru internih projektov, so (bodoči) manager projekta in nekateri člani projektnega tima tudi lahko že člani »snovalnega« tima, kjer sodelujejo kot strokovna pomoč pri opredelitvi zmožnosti izvedbe ter specifikaciji proizvodov projekta.

Podrobneje bomo posamezna področja in dokumente opredelili v kasnejših prispevkih.  Za konec pa še ena dilema. V prispevku, kjer sem opredelil najpomembnejše dokumente projekta, sem navedel, da na koncu faze snovanja nastane »predlog projekta«. Sedaj, po proučevanju »snovanja« pa nisem več prepričan.. Mogoče bi dokument poimenovali kar »Odločba za pripravo projekta«? Kaj menite? Očitno bo to tema za naslednji debatni večer!

V tuji literaturi najdemo dva tipična naziva uvodnih faz projekta – conception in initiation. Kot sem navedel v prispevku, kjer sem opredelil faze življenskega cikla projekta, Oxfordov slovar conception opredeljuje kot proces snovanja ideje ali plana (angl. the process of forming an idea or a plan), slovar tujk pa koncept kot okvirni načrt, koncipiranje pa kot zamišljanje nečesa. Initiation po Oxfordovem slovarju bolj opredeljuje trenutek, kot proces (angl. the act of starting something), a glede na preučene opredelitve obeh pojmov v literaturi, načeloma vsebujeta dokaj podobne aktivnosti. Glede na prevod »koncipiranja« sem se odločil, da bom uvodno fazo poimenoval snovanje projekta.

 

Frame (2003) navaja, da se projekt začne s potrebo in z željo, da se to potrebo zadovolji. Drugi avtorji »potrebo« prikažejo kot (poslovni) problem (npr. premajhna zmogljivost proizvodnje) ali priložnost (npr. izkoriščanje tržne niše). V večini primerov ima avtor ideje pripravljen tudi že predlog rešitve (nova proizvodna linija, nov izdelek / storitev). Ker pa imajo združbe omejene vire za uresničevanje vseh idej, ideje pa včasih tudi niso tako »genialne«, kot si jih predstavljajo predlagatelji, je potrebno »idejni predlog projekta« še podrobneje oceniti z vidika pričakovanih koristi in zmožnosti izvedbe.

 

Idejo se zato predloži vodstvu združbe, ki običajno najprej preveri skladnost s poslanstvom in strateškimi usmeritvami združbe, nadalje pa se na podlagi subjektivne ocene smotrnosti ideje odloči, ali se ideja še podrobneje opredeli. S potrditvijo ideje in določitvijo odgovornega tima se začne faza snovanja projekta. Pri tem je potrebno poudariti, da tim, ki zasnuje projekt, načeloma ni isti, kot tim, ki projekt izvede. Vsekakor je bodoči manager projekta lahko član tega tima, ni pa nujno.

 

Poglejmo še nekaj definicij faze snovanja:

· Wideman, ki ima na spletu zelo obsežen pojmovnik projektnega managementa, navaja, da je snovanje prva faza projekta, v kateri se preuči potrebo, ocenijo alternative, ter določijo cilji in skrbnik (sponsor) projekta.

· Snovanje je faza, ki vključuje študijo izvedljivosti projekta, s katero raziščemo zmožnost izvedbe in pričakovane koristi, opredelijo se proizvodi projekta in okvirni plan izvedbe. Charvat (2002)

· Prva faza projektnega cikla, ki vsebuje obravnavo ideje, odobritev in začetek projekta. Opredelijo se namen in proizvodi projekta. Heldman (2002)

· Prva faza, kjer se na podlagi zamisli o projektu  ter ocene tehnološke in ekonomske izvedljivosti izdelata okvirna predhodna ocena stroškov ter grobi plan projekta. Kliem & Ludin (1998)

· Začetna faza, v kateri se opredelijo usmeritve in omejitve projekta. Martin & Tate (2001)

· Začetna faza projekta, kjer se opredelijo poslovne potrebe, opredli proizvod projekta ter določi managerja projekta. Philips (2004)

V fazi snovanja, ki je običajno v domeni naročnika projekta (uporabnikov), se torej na podlagi idejnega predloga projekta, ki vključuje poslovni problem oz. priložnost ter možne rešitve, oceni smotrnost projekta (kot primerjava zmožnosti in okvirnih stroškov izvedbe ter pričakovanih koristi projekta). Izbere se najboljša rešitev in opredeli obseg projekta. Pri tržno usmerjenih projektih je za večjo zanesljivost potrebno preveriti trg in delovanje konkurence ter oceniti poslovna tveganja. Predvsem v primeru internih projektov, so (bodoči) manager projekta in nekateri člani projektnega tima tudi lahko že člani »snovalnega« tima, kjer sodelujejo kot strokovna pomoč pri opredelitvi zmožnosti izvedbe ter specifikaciji proizvodov projekta.

Podrobneje bomo posamezna področja in dokumente opredelili v kasnejših prispevkih.

Za konec pa še ena dilema. V prispevku, kjer sem opredelil najpomembnejše dokumente projekta, sem navedel, da na koncu faze snovanja nastane »predlog projekta«. Sedaj, po proučevanju »snovanja« pa nisem več prepričan, da je bi »project charter« prevedel v predlog projekta. Mogoče bi dokument poimenovali kar »Odločba za pripravo projekta«? Kaj menite? Očitno bo to tema za naslednji debatni večer…

Metodologije in standardni projektnega managementa

Že kar nekaj časa me je mučilo vprašanje, ali sploh obstaja kakšna »uradna« metodologija projektnega managementa, zato sem malo pobrskal po literaturi in internetu. V SSKJ je zapisano, da je metodologija »skupek metod, ki se uporabljajo pri raziskovanju«, Dinsmore (2010) pa jo opredeli kot »zbir metod in pravil v znanosti ali stroki«.

Lahko bi torej rekli, da je metodologija nabor metod, vprašanje pa je, ali metodologija predpisuje proces, zaporednost uporabe metod ter ali je uporaba metod »obvezujoča«, saj se projektni cikel razlikuje glede na vrsto in obseg projekta. Četudi nekateri omenjajo več projektnih metodologij, bi med njimi tudi težko našli večje razlike, saj vse vključujejo metode WBS, CPM, EVA, enake organizacijske strukture, podobno se lotevajo projektnih tveganj, ipd.!

Sicer pa se v praksi največ omenja tri »metodologije« – IPMA, PMI in PRINCE, vendar bi le slednjo pogojno lahko uvrstili med metodologije. Razvita je bila v 80-tih za potrebe obvladovanja projektov v britanski javni upravi, druga verzija, PRINCE2 iz leta 1996, pa je bila zastavljena širše, saj je pri pripravi menda sodelovalo kar 150 organizacij. Osebno menim, da je dokaj omejeno uporabna, a naj si vsak ustvari svoje mnenje… Priročnik PMBOK ni PMI metodologija, ampak – kot navaja Dinsmore – nabor znanj v sklopu stroke, neke vrste priročnik, ki se običajno upošteva kot »standard dobre prakse«. No, avtorji so ga uspeli tudi uradno »standardizirati« (več v nadaljevanju). IPMA pa zaenkrat sploh nima metodologije, čeprav se govori, da naj bi »za svojo« prevzela PRINCE2.

Torej, namesto, da iščemo »najboljšo splošno metodologijo«, bi bilo primerneje narediti nabor vseh možnih metod s priporočilom kdaj in na katerem tipu projekta naj se uporabijo…

Razvoj “lastne” metodologije združbe

Metodologija projektnega managementa / vodenja*

Kaj pa standardi? SSKJ opredeli »standard« kot predpis, ki opredeljuje mere, kakovost, postopke, ipd. Za področje projektnega managementa sta najbolj poznana standarda ISO 21500: 2008 Project Management – Guide to project Management (prej ISO 10006: 2004) ter ANSI PMI 99-001: 2008, ki je nastal na podlagi PMBOK-a. Kdor se kdaj ukvarjal z ISO standardi ve, da zagotavljajo urejeno poslovanje (procesi, postopki, obrazci…), ki naj bi posledično omogočilo učinkovito delovanje in nižje stroške poslovanja. Slabost standardov pa je, da večinoma bolj opredeljujejo “kaj” je potrebno delati (narediti), ne pa “kako”.

Sicer pa standardi lahko nastanejo načrtno (določi se skupina strokovnjakov, ki pripravi standard) ali pa standard nastane na podlagi metodologije, priporočil, ipd., kot je bil PMBOK osnova za ameriški standard in PRINCE2 za britanskega. Mogoče čaka podobno usodo tudi trenutno »neuradni standard« IPMA ICB V3, ki »predpisuje« priporočljive kompetence / veščine projektnih managerjev, IPMA model projektne odličnosti, ali pa kakšnega od zrelostnih modelov. Pomembno pa je tudi dejstvo, da na podlagi uradnih in neuradnih standardov združbe in posamezniki lahko pridobijo certifikate, ki jih lahko koristijo tudi v tržne namene…

Kaj torej upoštevati pri svojem delu? Pri Dinsmoreju in pri Kerznerju (2009) smo zasledili navedbo, da naj bi združba imela enoten pristop, neke vrsto svojo interno metodologijo, ki naj bi omogočala čim bolj racionalno izvajanje projektov. Priporočilo omenjenih avtorjev je, da naj bi bila metodologija prej skupek priporočil in obrazcev, kot pa pravil in procedur, čeprav menim, da moramo opredeliti tudi slednje. Vsekakor pa mora biti metodologija zadosti prilagodljiva, da se lahko uporabi za različne vrste projektov v združbi, priporočljivo pa je tudi, da je prilagojena organizacijski kulturi združbe in ne obratno – napačno je mišljenje, da le z novim organizacijskim predpisom lahko korenito spremenimo odnos zaposlenih do projektov. Wisocky (2009) pa dodaja, da je odličnost projektnega managementa v upoštevanju zdrave pameti!

Torej, z veliko mero zdrave pameti je pri organiziranju projektov v združbi potrebno upoštevati standarde in priporočila, uporabiti preizkušene metode, upoštevati naravo dela v združbi ter pripraviti svojo metodologijo. In ne pozabiti, da se projekti izvajajo tudi v sodelovanju z drugimi (partnerstvo, podizvajalci)…

Tipični udeleženci projektov in njihove vloge (2)

Stranka ali naročnik (angl.customer) je razlog, zaradi katerega projekt sploh obstaja, saj po zaključku projekta koristi rezultate projekta. V prvi vrsti opredeli namen in cilje projekta, sodeluje s projektnim managerjem pri razčiščevanju zahtev, potrjuje vmesne rezultate in potrdi ter prevzame končni proizvod projekta. Naročnik projekta je lahko notranji, v okviru združbe, kjer se projekt izvaja (služba, oddelek, skrbnik procesa) ali pa zunanji. Kot sem zapisal že ob  opisu razlik med projekti glede na naročnika, je naziv »naročnik« dostikrat rezervirano za vrhnji management združbe, ki projektnemu timu naroči izvedbo. Zato bi bilo mogoče smiselno razmisliti, da bi »customer-ja« poimenovali stranka ali uporabnik, ali pa tistega, ki interno odobri projekt imenovati “odobritelj”. Na žalost v SSKJ nimamo pojma za tistega, ki nekaj odobri.

Vloge udeležencev pri pripravi projekta po Verzuh-u

Management vodenje projektov - vloge v pripravi projekta*

Projektni tim sestavljajo izvajalci projektnih aktivnosti in morajo imeti za to potrebna strokovna znanja. Po navedbi avtorjev obstajata dva nivoja tima:

  • ožji tim sestavljajo najožji sodelavci managerja projekta, ki so običajno strokovni nosilci posameznih strokovnih področij, ki jih vključuje projekt. Člani ožjega tima, ki projektu posvetijo vsaj 60% (običajno pa 100%) svojega delovnega časa za celoten čas projekta, so največkrat določeni že pred začetkom priprave projekta, lahko na predlog skrbnika, managerja projekta ali sveta projekta. Zaradi strokovnega znanja in izkušenj je zelo pomembna njihova vloga v fazi priprave projekta (strategija izvedbe, potrebne aktivnosti, trajanje aktivnosti in potrebna količina dela, tveganja, ipd.).
  • širši tim sestavljajo ostali izvajalci projektnih aktivnosti, ki delujejo pod neposrednim vodstvom strokovnih nosilcev. Člani širšega tima se določijo v fazi planiranja projekta, nekateri pa celo med izvajanjem projekta (primer: v planu se določi, da se za montažo potrebuje pet monterjev, monterje pa izbere vodja šele tik pred izvedbo). Za člane širšega tima ni nujno, da so na projektu prisotni celoten čas.

»Tretji nivo« tima predstavljajo zunanji pogodbeni izvajalci.

Poslovno – funkcijski managerji (Young jih imenuje kar »Managerji virov«) kadrujejo svoje podrejene na projekt in so odgovorni, da projektnemu managerju zagotovijo usposobljene strokovnjake, da le-ti niso preobremenjeni z drugimi nalogami ter da so rezultati dela članov oddelka kakovostni in učinkovito doseženi. Po potrebi sodelujejo kot strokovni svetovalci.

Young meni, da ima projekt dva ključna vplivna udeleženca, skrbnika in stranko, ter ostale vplivne subjekte v okviru ali izven združbe. Po vzoru PMBOK, ki jih angleško imenuje influencers jih bom imenoval vplivneži projekta (po SSKJ je vplivnež nekdo, ki ima velik vpliv). Notranji vplivneži so lahko vplivni managerji v združbi, zunanji pa posamezniki, družbeno – politične ali interesne organizacije. Kot smo že omenili, vplivneži lahko s formalno ali prikrito podporo ali nasprotovanjem močno vplivajo na izvajanje in doseganje rezultatov projekta, ter tudi na spremembe ciljev in načina izvedbe projekta. Zato mora projektni tim identificirati potencialne vplivneže, dognati njihove interese in njihov vpliv ter poiskati način zadovoljitve interesov ali način izogibanja možnosti vpliva (Burke).

V kolikor celotnih sredstev za izvedbo projekta ne zagotovi matično podjetje, so pomembni udeleženci tudi (so)financerji projekta. Predvsem pri gradnji družbeno koristnih objektov so to lahko lokalne skupnosti in država. Lahko najdemo sovlagatelje, pokrovitelje, si pomagamo s kreditom, možno pa je tudi pridobiti nepovratna sredstva s strani EU ali države. Potrebno se je zavedati, da sofinancerji želijo imeti svoj vpliv pri opredelitvi ciljev in izvedbe projekta, poleg tega pa zahtevajo stalna in redna poročila o izvedbi.

Običajna razmerja med udeleženci so prikazana na sliki v prejšnjem prispevku.

Tipični udeleženci projektov in njihove vloge (1)

Projekt naj bi zadovoljil interese vseh udeležencev, med katere šteje Kerzner dobavitelje, stranke, zaposlene, posojilodajalce, delničarje in tudi konkurente. Udeleženci projekta (angl. stakeholders, v Sloveniji se vse več uporablja izraz deležniki) so posamezniki ali organizacije, ki so aktivno udeleženi na projektu oziroma katerih interes lahko pozitivno ali negativno vpliva na izvajanje ali zaključek projekta (PMBOK). Nekateri avtorji jih delijo na aktivne udeležence (angl. key players), kateri so vključeni v projektno organizacijo in formalno sodelujejo pri izvajanju projekta, ter na vplivneže projekta (angl. influencers), ki posredno lahko vplivajo na doseganje rezultatov projekta s formalno ali prikrito podporo ali nasprotovanjem.

V nadaljevanju navajam opredelitev tipičnih udeležencev projekta, povzeto po različnih virih (Kerzner, Verzuh, Young, PMBOK). Pri tem moram opozoriti, da navajam tipične vloge, pri čemer lahko na posameznem projektu ena oseba »igra« več vlog – vodja Prodaje je npr. lahko hkrati naročnik in skrbnik projekta.

Udeleženci projektov

Management vodenje projektov - udeleženci*

Osrednja oseba projekta je projektni manager, ki je osebno odgovoren za učinkovito izvedbo projekta (čas, stroški, kakovost), kar naj bi dosegel z ustreznim planiranjem, organiziranjem, vodenjem tima in kontroliranjem izvedbe. Ker ta blog v osnovi obravnava management projekta, bo o nalogah projektnega managerja še veliko napisanega v nadaljevanju.

Vodstvo združbe (uprava, direktor / predsednik uprave) skrbi, da so cilji projektov usklajeni s strateškimi usmeritvami združbe, odloča o usodi projekta (o začetku, izvedbi, prekinitvi), dodeljuje vire za podporo projekta (denar, ljudi, opremo, ipd.), določa prioritete projektov, nadzoruje projekt skozi celoten življenjski cikel projekta in sodeluje pri pomembnih vsebinskih odločitvah. Vodstvo združbe lahko določi odgovorno osebo, ki v njihovem imenu odloča o projektih, potrjuje elaborate, ipd. To je lahko član uprave, direktor projektne pisarne (direktor portfelja projektov) ali kdo od linijskih managerjev.

Predvsem v večjih združbah, kjer se izvaja veliko projektov, vodilni manager za nadzor projekta določi nadzornika ali skrbnika projekta, katerega nekateri po vzoru angleške literature imenujejo kar sponzor (angl. sponsor). To je običajno kdo od izkušenejših linijsko – funkcijskih managerjev, ki naj bi skrbel, da bo imela združba čim višjo korist od projekta, ki izbere managerja projekta, potrdi plan / elaborat projekta, sodeluje pri pomembnih odločitvah na projektu, nadzira delo tima in napredek projekta, rešuje konflikte med udeleženci ter potrjuje morebitne spremembe. Poleg nadzora projekta naj bi s svojim vplivom in izkušnjami tudi pomagal managerju projekta pri reševanju organizacijskih problemov na projektu. Glede na navedeno lahko ugotovimo, da naziv »nadzornik« ni najbolj ustrezen, saj je vloga skrbnika širša kot le nadziranje delovanja projektnega tima. Angleško slovenski slovar izraz »sponsor« prevaja kot odgovorna oseba, porok, boter, pokrovitelj. Ker večina prevodov opredeljuje preozko pojmovanje, se strinjam z Golobom, da je najustreznejši naziv »skrbnik« (po SSKJ = kdor skrbi za kaj sploh), čeprav menim, da bi bil »boter« še najprimernejši, a na žalost ima izraz preveč negativnih predznakov.

Naloge skrbnika lahko prevzame tudi kolektivni organ – svet projekta (imenovan tudi usmerjevalna skupina). V primeru internih projektov so poleg skrbnika člani sveta lahko tudi naročnik in linijski managerji, katerih podrejeni so člani projektnega tima. Pri zunanjih projektih, predvsem na področju gradnje objektov, kjer projekt pomembno vpliva na širše družbeno okolje, pa so v svetu lahko predstavniki naročnika, vlagateljev, lokalne skupnosti, ipd. Naloge sveta so podobne nalogam skrbnika, predvsem pomembno pa je potrjevanje vmesnih rezultatov ob mejnikih projekta in odobravanje predlogov sprememb, katere bi občutneje dvignile stroške projekta ali ogrozile izvedbo v okviru rokov.

Vzroki za neuspeh projekta – izvedba projekta

Najprej naj izpostavim vzroke, ki v bistvu izhajajo iz slabe organizacije (priprave) projekta, pa jih v prejšnjem prispevku nisem omeni. Konflikti med udeleženci projekta v fazi izvedbe se velikokrat pojavijo zaradi nejasne vloge udeležencev, kar je posledica pomanjkljive porazdelitve odgovornosti za izvedbo aktivnosti, odločanje, potrjevanje rezultatov… Saj poznate izraze »Za te stvari pa nisem jaz zadolžen« ali »Zakaj pa se niste posvetovali z mano?« Pomembno orodje, ki ga je smiselno uporabiti, da preprečimo te probleme, je matrika pristojnosti in odgovornosti.

V literaturi nadalje najdemo kar veliko vzrokov za slabšo izvedo projektov, ki izhajajo iz neustreznega delovanja managerja (vodje tima) in ostalih udeležencev projekta (članov tima, nadrejene združbe) – pomanjkanje sodelovanja, slabe komunikacije in pretok informacij, nizka motiviranost izvajalcev. Vse to več ali manj izhaja iz organizatorske in voditeljske (ne)sposobnosti vodje tima. K temu lahko dodamo še neučinkovito kontroliranje in prepozno ukrepanje ob odstopanjih. Lahko bi rekli, da je osnovni vzrok izbira neustreznega managerja projekta, kar je lahko tudi del organizacijske kulture v podjetju. Še vedno se vse preveč poudarja strokovno / tehnično znanje, vrhunski strokovnjaki pa so praviloma slabši organizatorji. Poleg tega ustvarjalna in organizacijska dela povzročajo »konflikt interesov« v glavi managerja projekta, na žalost pa običajno na račun kreativnih del trpi koordinacija projekta.

Vzroki za neučinkovito izvedbo projekta, drugič

Management vodenje projektov - vzroku neuspeha 2*

Pri enem izmed avtorjev sem naletel tudi na neodločnost oziroma nezmožnost managerja, da bi sprejemal težje odločitve. S tem se vsekakor strinjam, vseeno pa bi sporočil vsem managerjem, da ni potrebno, da vse odločitve sprejemajo sami. Odločno je potrebno poskrbeti, da se s kar največ informacijami čim prej sprejme prava odločitev – pomembno je vključevanje članov tima in tudi ostalih strokovnjakov v združbi!

Pomemben vzrok za neučinkovito izvedbo so spremembe. Dejstvo je, da se projekt nikoli ne izpelje natančno po planu. Problem pa je, če je teh sprememb veliko (kar je lahko tudi posledica neustrezne opredelitve projekta) in če se uveljavljajo nekontrolirano. Dve stvari sta pomembni – prvič, projekta ne začnemo planirati (kaj šele izvajati), dokler vsem ni jasno, kaj bo ob zaključku projekta nastalo in kako bo »izgledalo« oz. »delovalo«. In drugič – na začetku projekta je tudi potrebno določiti proces obravnave in odobravanja sprememb, ter se med izvedbo projekta tega »protokola« tudi držati. Poleg tega »kaj« ustvariti, je pomemben vidik tudi »kako« – nedorečen in neusklajen plan je prvi vzrok, seveda pa lahko med izvedbo pride do novih idej in rešitev – le-te morajo biti »uradno« obravnavane in načrtno vpeljane.

Omenil sem že projektno organizacijsko kulturo, ki je pomemben dejavnik (ne)učinkovite izvedbe projektov v združbah. Kako celotna združba sprejema projekte in kakšne pristojnosti imajo managerji projektov (ne samo na papirju, tudi v resnici)? Kultura verjetno ni problem v »projektnih« podjetjih, kjer je vsak posel projekt (npr. inženiring, IT podjetja,…), veliko vlogo pa ima pri podjetjih, kjer projektni pristop uporabljajo redkeje, za uvajanje sprememb delovanja. Pokazatelji nizke kulture so npr. nezanimanje vodstva za projekte, nedorečenost prioritet projektov, premajhna podpora s strani skrbnikov projektov. Dogaja se tudi, da izvajalci niso na voljo, ko so potrebni na projektu (čeprav so bili planirani). Vzrok je v tem, da linijski managerji ne čutijo odgovornosti za izvedbo projekta; ne takrat, ko (s figo v žepu) delegirajo (neustrezne)  ljudi na projekt, ne kasneje, ko morajo te ljudi razbremeniti drugih opravil, da lahko izvedejo »projektne« aktivnosti, pri tem pa jih tudi strokovno pomagati. Še tako sposoben manager bo težko učinkovito izpeljal projekt v združbi z nizko kulturo, da frustracij in obupovanja nad projektom ter okoljem sploh ne omenjam…

Page 1 of 2

Powered by WordPress & Theme by Anders Norén