Feeds:
Objave
Komentarji

Archive for the ‘Pojmovnik’ Category

PMIS sem omenil že v prispevku »Plan obvladovanja informacij in dokumentacije projekta«, kjer sem izpostavil pomembnost omenjenega področja ter predlagal plan komuniciranja za primere enkratnih projektov, na katerem prvič dodeluje več različnih združb. Nasprotno pa v se združbah, kjer izvajajo veliko projektov, v fazi priprave projekta ne ukvarjajo s komunikacijami in dokumentacijo če imajo vpeljan poseben »projektni« informacijski sistem za podporo projektnemu delu.

Projektni informacijski sistem (PMIS, angl. project management information system) je po mnenju strokovnjakov zbir (običajno računalniško podprtih) orodij, ki podpirajo planiranje aktivnosti in virov ter zbiranje in prenos informacij (Heldman, 2005; Brandon, 2006). Je tudi sistem za sledenje napredovanja (www.maxwideman.com) in kontroliranja projekta ter zagotavlja učinkovito komuniciranje (Verma, 1995).

Projektni informacijski sistem je lahko sestavljen iz več delov, katere lahko delimo glede na tipe dokumentov (vsebinsko) ali glede na orodja, ki se uporabljajo (baze, dokumenti, gantogrami, e-pošta). Načeloma so meje med temi deli le teoretične, so pa smiselne, zaradi večje preglednosti dokumentacije. Nekateri so lahko tudi združeni, struktura pa je odvisna od programske opreme, ki jo uporabljamo. Nekaj tipičnih vsebinskih področij sem prikazal na sliki.

Vsebinska področja PMIS

Kar se tiče komuniciranja, informiranja in prenosa dokumentov, obstajata dve možnosti:

  • informacije se prenašajo preko e-pošte in vsak si gradi svojo »informacijsko bazo« ali arhiv – urejenost je seveda odvisna od posameznika;
  • informacije in dokumenti se hranijo na centralnem mestu (portal projekta) in deležniki poiščejo ustrezno informacijo, ko jo potrebujejo (ne pošiljamo zapisnikov po e-pošti, ampak so objavljeni na portalu).

Druga izvedba je vsekakor boljša, zahteva pa sistematičnega skrbnika PMIS in ustrezno urejenost vseh dokumentov, da jih uporabnik hitro najde (1 minuta!). Tak informacijski portal omogoča tudi razne preglednice za boljše informiranje deležnikov v stilu »kaj je novega«, ki si jih vsak lahko ogleda vsako jutro pred začetkom dela. Primeri: spremembe zahtev, korektivne akcije (krajše naloge na podlagi sklepov kontrolnih sestankov), odkrite napake in težave (za odpravo), druge novosti.

In kakšno programsko orodje lahko uporabimo za PMIS? Menim, da je večina od vas že slišala za MsProject, kot najbolj razširjeno orodje za podporo managementu projektov. Moram opozoriti, da to ni PMIS, ampak le orodje za planiranje in kontroliranje časa, virov in stroškov projekta. Šele povezava z drugimi orodji omogoča tudi obvladovanje dokumentacije. Žal pa zadeva kljub kakovosti ni tako poceni, zato so se mnogi uporabniki začeli ozirati po brezplačnih, odprtokodnih rešitvah.

Kolega Marko Nemec Pečjak si je zadnjo zimo večere krajšal z analizo funkcij PMIS, ki jih je našel na spletu. Za 101 program je preveril, če omogočajo klasično planiranje časa in virov, pa tudi ali omogočajo skupinsko delo, sledenje problemov, management dokumentacije in management portfelja projektov. Poleg tega je preveril, če obstaja spletna verzija, pa seveda, ali je paket brezplačen. Slednjih je našel kar 24, od tega jih 12 omogoča obvladovanje časa in virov, pet »brezplačnikov« pa ima vse zgoraj navedene funkcije: Daptiv PSA Solution, Endeavour Sw Project Mgm, Openpoint Project, Project.net in Project-Open. Sicer pa rezultate analize lahko ogledate na njegovi prezentaciji z letošnjih DSI.

Advertisements

Read Full Post »

Kdor ne ve, kaj je gantogram, nas bo težko prepričal, da je kdaj (resno) vodil projekt! Eno najpomembnejših orodij, tako rekoč osnovno delovno sredstvo managerja projekta, ki služi časovnemu planiranju in kontroliranju izvedbe, se v originalu imenuje »Gantt chart«, po Ganttu, ki naj bi ga »izumil« že davnega leta 1917. Gantogram grafično prikazuje časovni razpored in trajanje izvedbe posameznih aktivnosti, ki so nanizane ena pod drugo. Za vsako aktivnost se tako hitro in jasno razbere, kdaj naj bi se začela in kdaj zaključila.

S tem, ko so prikazani konkretni datumi začetkov in koncev aktivnosti, so prikazani tudi dnevi, ko naj bi izvajalci aktivnosti posvetili svoj čas projektu. V gantogramu so lepo vidni zaključeni sklopi / faze projekta z mejniki (zaključki faz), pa tudi časovne rezerve nekritičnih aktivnosti, ki se lahko izkoristijo za uravnavanje obremenitev ljudi (o tem več naslednjič). Čeprav je imel gantogram prvotno eno veliko slabost v primerjavi s kasneje razvitim mrežnim planiranjem – ni vključeval povezav med aktivnostmi, so sodobna računalniška orodja to omogočila, zaradi česar se klasično mrežno planiranje vse bolj opušča.

Primer gantograma s prikazano kritično potjo

Gantogram - terminski plan projekta* Mimogrede, ko sem preverjal, kako »domača« je beseda »gantogram«, mi je »stric Google« ponudil kar 90.700 slik s primeri gantogramov. Preverite še sami…

Verzuh (2008) o gantogramu pravi: »Slika pove več kot 1000 besed!«, Pinto (2009) pa izpostavlja naslednje prednosti: je nazoren in razumljiv, zelo enostavno poveže mrežni plan in naročnikove želene roke, uporaben je za kontrolo in enostaven za posodabljanje, služi pa tudi ugotavljanju potreb po virih. Omogoča tudi hiter in enostaven izračun oziroma preverjanje več možnih scenarijev izvedbe oziroma simulacij ukrepov in posledic v procesu managementa tveganj. S pomočjo gantograma usklajujemo aktivnosti članov tima z aktivnostmi, ki jih mora v sklopu projekta izvesti naročnik, ter s tistimi, ki jih bomo zaupali pogodbenim izvajalcem.

Če sem pri mrežnem planiranju navedel, da je možno projekt skrajšati s krajšanjem kritičnih aktivnosti, nam gantogram omogoča tudi krajšanje s prekrivanjem aktivnosti. Če je potrebno »pohitriti« izvedbo (tudi že v fazi planiranja, velikokrat pa pri reševanju zamud v fazi izvedbe), lahko npr. aktivnost, ki naj bi se sicer začela takoj po zaključku predhodne, začnemo izvajati nekaj časa prej in tako obe povezani aktivnosti krajši čas potekata vzporedno. Seveda se aktivnosti in s tem projekt krajšajo tudi tako, da na neko aktivnost razporedimo več ljudi (čeprav trajanja ne moremo kar deliti s številom ljudi, kot to meni Dilbertov šef) ali pa aktivnost zaupamo pogodbenim izvajalcem.

Pri mrežnem planiranju sem napisal le, da aktivnostim pripišemo predvideno trajanje. Čeprav je zelo enostavno napisati številko (dneve ali tedne trajanja), je to ena najbolj kritičnih aktivnosti planiranja projekta. Avtorji poudarjajo, da se trajanje aktivnosti oceni na podlagi izkušenj planerjev (managerja, ožjega tima, predvidenih izvajalcev). K realnejši oceni pomagajo plani in poročila o izvedbi podobnih predhodnih projektov, plani tipskih projektov, sodelujejo lahko sodelavci iz projektne pisarne (s statističnimi »normativi«, ugotovljenimi z analizami zaključenih projektov). Pomagamo si tudi s ponudbami podizvajalcev, ali z izkušnjami s podobnih projektov v drugih združbah (sošolci,  znanci, strokovna združenja). Kerzner (2009) pa predlaga, da naj trajanje ocenijo kar linijski managerji, ki naj bi imeli najbolj bogate izkušnje.

Read Full Post »

Aktivnosti, ki jih je potrebno izvesti, da bi dosegli cilje projekta, bi načeloma lahko izvajali eno za drugo, kot smo jih zapisali v WBS, vendar pa bi bilo to zelo neracionalno, saj je možno določene aktivnosti izvajati vzporedno, s čimer se projekt lahko veliko hitreje izvede. Pristopu, s katerim zagotavljamo racionalno izvedbo za vidika časa, rečemo mrežno planiranje. Moram povedati, da projektni managerji s pojavom modernih računalniških orodij, s katerimi pripravljamo terminske plane (gantograme, ki jih bom predstavil naslednjič), mrežnih planov skoraj ne uporabljamo več, a filozofijo planiranja projekta je nekako najlažje obrazložiti prav z mrežnim planiranjem.

Obstajata dva grafična prikaza mrežnega plana. Pri enem uporabljamo »puščice in krogce«, pri drugem z linijami povezujemo pravokotnike (primer na sliki). Pri prvem, imenovanem puščični (angl. arrow diagram, poznan tudi kot TOA, task-on-the-narrow), s puščicami prikažemo aktivnosti, krogci pa označujejo »dogodke« – začetke in konce aktivnosti oz. povezavo več aktivnosti (kadar mora biti zaključenih več aktivnosti, da začnemo z naslednjo ali z več naslednjimi). Pri drugem, »aktivnostnem« mrežnem diagramu (Lock ga imenuje precedence logic diagram, Kerzner precedence network, Wysocki pa govori o PDM metodi – precedence diagramic method), pa pravokotniki predstavljajo aktivnosti, linije med njimi pa povezavo. Pri tem linije vedno tečejo iz desne stranice pravokotnika predhodne aktivnosti v levo stranico naslednje aktivnosti.

Primer enostavnega mrežnega plana s prikazano kritično potjo

CPM mrežni plan*

Glavna slabost puščičnega plana je, da moramo uporabljati »navidezne aktivnosti«, pri aktivnostnem pa je lahko nejasna »večstranska« povezava več aktivnosti. V oba tipa diagramov lahko vnašamo tudi različne (najzgodnejše ali najkasnejše) začetke in konce aktivnosti, s katerim prikažemo časovno rezervo »plavajočih« aktivnosti, ipd. Da ne grem preveč v podrobnosti – podrobneje bom metodi obrazložil v knjigi.

Kot sem že omenil, vhod v mrežno planiranje je WBS. Postopek izdelave pa gre nekako takole: vnesemo prvo aktivnost, pri naslednji pa se vprašamo: »Ali mora biti prva aktivnost zaključena, da lahko začnemo izvajati to, ki jo želimo vrisati?« Če je odgovor NE, potem jo narišemo vzporedno, če pa je DA, jo narišemo za njo (desno) in ju povežemo. Pogoj za zaporednost je običajno »tehnološki« (npr. dovoljenja za gradnjo ne moremo zaprositi, če nimamo izdelanih načrtov). Z morebitnim pomanjkanjem kadrov, zaradi katerih dveh aktivnosti ne bi mogli izvajati vzporedno, se tu še ne ukvarjamo. Podobno nadaljujemo z vsemi ostalimi aktivnostmi do konca seznama, pri čemer se pri vsaki vprašamo “Katera aktivnost mora biti nujno zaključena, da začnemo s to, ki jo vnašamo v plan…?” Pa še to: pri risanju mrežnega plana ni pomembno, kako so aktivnosti strukturirane v WBS.

Ko zaključimo z risanjem, vsaki aktivnosti pripišemo predvideno trajanje (slika: 6w = šest tednov) in poiščemo kritično pot. To so tiste medsebojno povezane aktivnosti, katerih seštevek trajanj je najdaljši (slika: rdeče aktivnosti). Njihov seštevek je tudi pričakovano trajanje projekta – prej kot v tem času projekta ne bo možno izvesti. Govorimo o metodi kritične poti (CPM, critical path method). Kritične aktivnosti moramo poznati, da vemo, katere aktivnosti krajšati, da bi skrajšali projekt, ter da damo večji poudarek tveganjem na kritični poti. Poleg tega pa je v fazi izvedbe pomembno vedeti, da zamujanje kritične aktivnosti pomeni neposredno tudi zamujanje projekta.

Za konec pa še nekaj: kadar izvajamo veliko podobnih projektov, s skoraj identičnimi aktivnostmi, potem nima smisla tratiti časa s pripravo WBS-a in mrežnega plana, ampak raje uporabimo terminski plan enega od predhodnih projektov. Z nekaj dopolnitvami in prilagoditvami nato dokaj hitro pripravimo zelo kakovosten plan novega projekta.

Read Full Post »

Kratica WBS v originalu pomeni work breakdown structure, kar Hauc prevaja kot »retrogradna členitev projekta«, Rozman »struktura projekta«, Semolič »strukturirana členitev projekta«, Nemec Pečjak pa kot »strukturirana členitev dela«. Ker govorimo o planiranju aktivnosti, mi je zadnji prevod še nekako najbližji. Mogoče pa bi metodo lahko poslovenili kot »členitev projekta«, rezultat pa poimenovali »struktura del«? Cilj oziroma bistvo členitve pa je, da se izdela seznam vseh aktivnosti, s katerimi bomo učinkovito izvedli projekt.

Členitev projekta in izdelava seznama aktivnosti je načeloma prvi korak (podrobnega) planiranja projekta, čeprav je res, da se okvirni plan z mejniki izdela že v fazi snovanja. Nekateri avtorji pa tudi predlagajo, naj tim pred podrobnim planom aktivnosti skupaj z naročnikom najprej doreče okvirni način (taktiko) izvedbe (nekaj o tem sem napisal v zadnjem odstavku). Vseeno pa, tudi če taktika ni posebej (pisno) opredeljena, se tim o njej pogovarja, ko členi projekt. Vhodni podatki za pripravo strukture del so obseg in specifikacije proizvodov projekta, včasih pa si timi pomagajo tudi z zahtevanimi mejniki projekta, ki delno nakazujejo tudi že taktiko izvedbe, kot jo vidi naročnik.

Primer Strukture del projekta

WBS členitev projekta*

Običajna, grafična oblika »WBS diagrama« je podobna organigramu (primer na sliki), možno pa je delo členiti samo tekstovno, v enem stolpcu, s pomočjo zamikov alinej (kot je to prikazano v orodjih za planiranje projektov). Za večjo preglednost se posameznim nivojem pripišejo ustrezne številke (2. Razvoj, 2.2 SW, 2.2.3 Splet, 2.2.2.1 Radio, ipd.)

Različni avtorji navajajo dva izhodišča členitve projekta. Največkrat je osnova za členitev kar obseg projekta, skupaj z specifikacijami, kot je to prikazano na sliki (PBS = product breakdown structure). Lahko bi mu rekli »vsebinski način členitve«. Našel pa sem tudi členitve, kjer so za izhodišče vzete tipične zaporedne faze izvedbe projekta, ki so povezane z mejniki projekta (npr. načrtovanje, gradnja, opremljanje). Ta pristop bi lahko poimenovali »fazni način«. V praksi pa sem naletel tudi na kombinacijo obeh, a več o tem bom napisal v knjigi.

Izdelava kakovostne členitve dela je zelo pomembna, saj je WBS osnovna vhodna informacija za vse ostale plane projekta –  za mrežni in terminski plan, plan virov in stroškov, ter plan obvladovanja tveganj! Poleg tega je tudi osnova za porazdelitev del med naročnikom, izvajalci in podizvajalci, oziroma med partnerji, ki bodo izvedli projekt.

Prav zaradi slednjega nekateri avtorji predlagajo, da tim pred členitvijo projekta najprej opredeli »taktiko izvedbe«, pri čemer je z vidika členitve projekta potrebno razmisliti, katere dele projekta se bo zaupalo zunanjim izvajalcem oziroma, ali se bodo določene stvari (npr. sestavni deli) kar kupile pri dobaviteljih. Če bo namreč del projekta izvedel pogodbeni izvajalec, nam ni potrebno podrobno členiti njegovega dela, ampak v seznam aktivnosti vključimo aktivnosti od iskanja primernih izvajalcev do podpisa pogodbe.

Read Full Post »

S potrjenim (internim) »Naročilom projekta«, kot smo na zadnjem debatnem večeru poslovenili »project charter«, projekt preide v drugo fazo – začne se priprava projekta. V omejenem času (rok je običajno tudi naveden v Naročilu) naj bi ožji projektni tim (manager projekta in nosilci posameznih strokovnih področij) izdelal podroben plan izvedbe projekta in organiziral vse deležnike projekta tako, da bi delo potekalo brez nesporazumov, napak, ipd.

Zanimivo, da tuji avtorji večinoma pišejo le o planiranju projekta, organiziranja pa ne obravnavajo kot procesa, ampak večinoma le navedejo možne organizacijske strukture, njihove značilnosti, prednosti in slabosti. Nekateri delno govorijo o organiziranju v sklopu planiranja. Newel (2002) proces poimenuje »organizacijsko planiranje« (organisational planning), kar bi lepše poimenovali »planiranje organizacije«. Meredith in Mantel (2009) na WBS takoj vežeta RAC matriko (pristojnosti / odgovornosti), Burke (2008) omenja plan komunikacij, Kleim in Ludin (1998) pa navajata »project manual«, kot pravilnik delovanja tima.

Kot sem zapisal že v enem od zgodnejših prispevkov, se je kake tri desetletja nazaj pojavil »project start-up«, ki naj bi načeloma združeval vse aktivnosti med snovanjem in izvedbo projekta, torej proces planiranja in organiziranja. Zasledil sem ga pri več avtorjih (Lock, 2009; PRINCE2, Turner in Simister, 2000; Young, 2000), ki pa »start-up« opredeljujejo dokaj različno. Hauc je fazo poimenoval zagon, sam pa sem nekako bolj naklonjen izrazu »Priprava projekta«.

Priprava projekta – proces in dokumenti

Priprava (zagon) projekta - planiranje, organiziranje*

O planiranju in organiziranju sem tudi že pisal, a na kratko lahko opredelitve ponovimo. Poenostavljeno povedano se s planiranjem je opredeli “kaj, kdaj in kdo” bo kaj naredil na projektu, s čim (oprema) ter koliko bo to stalo. Večina avtorjev vključuje tudi plan obvladovanja tveganj, plan financiranja, itd. (glej sliko). Pri opredelitvi organiziranja bi najlažje povzel Newel-a (2002) – določitev vlog, pristojnosti in odgovornosti deležnikov projekta ter opredelitev načina poročanja na projektu. Ne smemo pa pozabiti na komuniciranje, prenos informacij in management dokumentacije projekta, kar bi prav tako lahko vključili v organiziranje projekta. Vse dokumente, ki nastanejo v fazi priprave projekta, lahko združimo v enega, ki ga združbe v Sloveniji največkrat poimenujejo elaborat projekta.

 

Pa še tale misel… Ko razmišljam o tem, kako podrobno pripraviti projekt, se vedno spomnim na trditev, ki sem jo zasledil pred leti v eni knjigi (žal sem pozabil avtorja). Zapisano je bilo nekako takole: »Vrhunski projektni manager (lahko) igra cele dneve golf!« To nekako pomeni, da lahko v primeru idealnega plana manager projekta enkrat tedensko pride samo preverit, če zadeve tečejo po planu. In seveda tečejo, ker je med pripravo projekta s svojim timom izdelal realen plan, jasno razdelil vloge in opredelil razmerja med deležniki, predvidel morebitne zaplete in jih uspel preprečiti… No, to je v današnjem spreminjajočem se času bolj »pravljica«, kot resničnost, kar še ne pomeni, da se dobri managerji ne trudijo čim bolj približati »idealnemu«. In kot pravi stari slovenski pregovor – dobra priprava je pol narejenega!

Read Full Post »

Sedaj je že čas, da podrobneje opredelim dokument, ki predstavlja končni proizvod snovanja projekta in naznanja prehod projekta iz snovanja v pripravo. Omenil sem že, da bi ga lahko poimenovali »listina projekta« (angl. project charter), odločba za pripravo ali naročilo projekta.

Spet moram poudariti, da dokument ni različno poimenovan le v slovenskih združbah, ampak sem poleg pojma »project charter«, ki ga navaja večina avtorjev (med njimi tudi Kerzner ter PMBOK), naletel tudi na »project brief« (PRINCE2, Young), »POS – Project overview statement« (Wysocki), »Business Plan« (Brandon) ter »Project mandate« (Andersen).

Poleg tega sem pri tujih avtorjih ugotovil, da eni pod »charter« dejansko razumejo zaključni dokument faze snovanja, spet drugi (Burke, Verzuh, Thomsett) pa ga predstavljajo kot elaborat projekta, torej kot končni dokument priprave projekta s podrobnim planom in organizacijo. Kar neizkušenega projektnega managerja lahko še bolj zmede, je to, da nekateri avtorji dokument poimenujejo z dvema nazivoma, ki jih sicer drugi uporabljajo za dva različna dokumenta – Thomsett: »charter or business case«; Snedaker: »statement of work or project charter«. Da bo zmeda popolna, Verzuh pod vsebino »charterja« predstavi elaborat, sicer pa navaja še »proposal«, ki pa je po vsebini identičen »charterju« drugih avtorjev.

Sicer pa je najbolj pogosta definicija naslednja: »Project charter« je uradni »lansirni« dokument, ki naznanja obstoj projekta, in ki zagotavlja jasno sliko oziroma enako videnje projekta s strani vrhnjega managementa, skrbnika projekta in projektnega tima. Managerju projekta zagotovi potrebne pristojnosti ter mu da »uradno pravico«, da svoj delovni čas lahko posveti projektu, ter da lahko začne s pridobivanjem internih kadrov za izvedbo projekta (Prince2 celo navaja, da s podpisom skrbnik in manager skleneta pogodbo o izvedbi projekta). Poleg tega je vhodni dokument v fazo priprave projekta in prikaže pričakovanja ter omejitve, kot vodilo projektnemu timu pri planiranju projekta.

Primer: Listina oz. odločba za pripravo projekta

Predlog oz. listina projektaVir: Wysocki, 2009

Nekateri avtorji prikazujejo »charter« kot enostranski obrazec, kjer so prikazane bistvene informacije, v prilogi pa se nahajajo ostali dokumenti faze snovanja (idejna rešitev in študija izvedljivosti). Spet drugi pa predlagajo obširnejši dokument, z vsemi vsebinami. Mislim, da je najbolje, če je to skupen dokument, ki ima na prvi strani standarden obrazec s povzetkom najpomembnejših informacij.

Sicer pa avtorji najpogosteje navajajo naslednjo vsebino dokumenta:

  • Osnovne informacije: številka in naziv projekta, skrbnik, manager, (stranka)
  • Ozadje projekta – problem / priložnost
  • Idejna rešitev, obseg proizvodov in zahteve (specifikacije)
  • Študija izvedljivosti
  • Analiza deležnikov
  • Omejitve projekta in predpostavke
  • Proračun in okvirni terminski plan (mejniki in končni rok)
  • Kadrovske zahteve oz. ključni kadri

Našel sem tudi naslednjo opredelitev vsebine: skrbnik opredeli zakaj, kaj, kdo, kdaj, kje, kako in za koliko naj bi se izpeljal projekt – za doseganje strateških ciljev združbe! (Burke, 2010).

In kdo pripravi dokument? Večina avtorjev navaja, da je za pripravo odgovoren skrbnik (sponzor) projekta, torej “vplivnejši predstavnik” tistih, ki bodo koristili rezultate projekta. Naletel sem tudi na navedbo, da v praksi dokument pripravi (bodoči) manager projekta, vendar se na koncu pod njega podpiše skrbnik. Vsekakor naj bi veljalo, da odgovornost za pripravo sloni na skrbniku, pri pripravi pa mu lahko pomagajo pobudnik projekta, predvideni manager projekta ter drugi strokovnjaki, ki imajo določena znanja in informacije, potrebne za dobro pripravljeno končno naročilo oziroma odločbo za pripravo / izvedbo projekta.

Read Full Post »

Naslednji korak procesa snovanja projekta je podrobna opredelitev končnega proizvoda (izdelka, rezultata, storitve, dogodka ali sestavine) – »kaj naj bi nastalo« ob zaključku oziroma do zaključka projekta in »kako bo izgledalo«? Vhodni dokument za opredelitev proizvodov je predlagana rešitev, ki pa jo je potrebno natančneje opredeliti na podlagi potreb uporabnikov. Napisal sem »proizvodov«, saj običajno projekt ne ustvari le enega – projekt razvoja novega izdelka ima npr. naslednje »proizvode«: nov izdelek, dokumentacijo (navodila za uporabo, promocijski brošuro, ipd.), zagotovljene proizvodne zmogljivosti s priučenimi delavci, pridobljene tipske odobritve na ciljnih trgih, ipd.

Celoten nabor predvidenih proizvodov projekta stroka vključuje v »obseg«, ki sem ga časom že na kratko predstavil. Po navedbah avtorjev obstajata dva »tipa« obsega – obseg dela (angl. scope of work ali project scope) in obseg proizvodov (angl. product scope, PMBOK 2004). V fazi snovanja projekta govorimo seveda o slednjem (to, kar sem opisal v prejšnjem odstavku), medtem ko se obseg dela običajno izdela v fazi priprave projekta (taktika izvedbe in planiranje aktivnosti), kar pa je že naloga projektnega tima.

Če smo torej z obsegom opredelili, kaj bo potrebno ustvariti, morajo snovalci v naslednjem koraku te proizvode natančno opredeliti (oblika, karakteristike, funkcionalnost…), dokument pa se običajno imenuje specifikacije (proizvodov), v Sloveniji poimenovan tudi »tehnični zahtevnik« ali pa »projektna naloga«. Pri več avtorjih sem našel delitev specifikacij na »funkcionalne« in »tehnične«. Frame (2003) navaja, da funkcionalne zahteve opisujejo karakteristike proizvodov v običajnem, »netehničnem« jeziku, saj morajo biti razumljive uporabnikom. Tehnične zahteve pa opisujejo karakteristike proizvodov s »tehničnim« jezikom (parametri, strokovni izrazi, pogoji delovanja, ipd.).

Priprava specifikacij – proces in primer

Opredelitev specifikacij projekta*

Na podlagi obsega in specifikacij projektni tim točno ve, kaj se od njega pričakuje, predstavlja osnovo za pripravo plana izvedbe, ob zaključku projekta, ob predaji proizvodov, pa na podlagi specifikacij naročnik (stranka) preveri ustreznost oziroma usklajenost proizvodov s specifikacijami.

Poleg obsega proizvodov so vhod v pripravo specifikacij predvsem zahteve (angl. requirements) uporabnikov, zato je naloga pobudnika in snovalcev projekta, da čim bolj analizirajo želje in potrebe uporabnikov. Če se bo projekt izvedel za lastne potrebe (npr. razvoj IT podpore procesu), potem se analiza izpelje neposredno s pogovori z uporabniki, v primeru razvoja novega izdelka za trg, pa se zahteve opredelijo s pomočjo tržne analize.

V primeru, da je podjetje v vlogi (pod)izvajalca in naj bi izvedlo projekt proti plačilu za zunanjega naročnika, pa pričakuje, da bo večino zgoraj omenjene dokumentacije pripravil naročnik. Pri tem je seveda vprašljiva strokovnost snovalcev in uporabnikov pri naročniku (sicer bi mogoče projekt izvedli kar sami), zato je smiselno, da obe združbi specifikacije izdelata skupaj. Kdaj se podpiše pogodba in ali vključuje tudi storitev priprave specifikacij, bomo govorili kdaj drugič.

V povezavi s zahtevami in specifikacijami pa moram omeniti še »konfiguracije« in management konfiguracij (angl. configuration management), ki sem ga tudi že omenil. Burke (2010) navaja, da je konfiguracija (skupaj s študijo izvedljivosti in taktiko izvedbe) vhod v opredelitev obsega del, vendar je še bolj pomembno to, kar navaja Cleland (1999) – da management konfiguracije vključuje obvladovanje funkcionalnih in fizičnih karakteristik proizvodov skozi celoten projekt. Predvsem se to nanaša na morebitne spremembe proizvodov – glavna naloga managementa konfiguracij po potrjenih specifikacijah proizvodov je, da poskrbi za formalno obravnavo predlaganih sprememb specifikacij (vključno z oceno posledic spremembe), ter da s spremljanjem nastajanja proizvodov zgodaj odkrije morebitne poskuse nekontroliranega spreminjanja.

Nekateri avtorji vključujejo pripravo obsega in specifikacij med naloge projektnega managerja, vendar bi se osebno tukaj raje držal drugih priporočil – manager projekta mora predvsem zagotoviti, da so zahteve (obseg, specifikacije) pred začetkom planiranja projekta čim bolj podrobne in nedvoumne, da bo plan realnejši, da ne bo kasnejših konfliktov in sprememb. Poleg tega pa, kot pravi Thomsett (2002), naj manager projekta ne bi bil pobudnik projekta, zaradi česar ne bo »čustveno vezan« na pričakovane proizvode in bo lažje zastopal načelo »povejte mi, kaj naj naredimo, in to bomo storili«. Seveda tako on, kot člani tima lahko sodelujejo pri snovanju (oziroma je celo priporočljivo), a le kot svetovalci – poznajo zmožnosti tehnologije, predlagajo tehnične rešitve, alternative … a na koncu se odločajo uporabniki ali skrbnik projekta! Včasih specifikacije lahko nastanejo šele v sklopu priprave projekta, ko je ožji projektni tim že sestavljen, a še vedno imajo glavno besedo uporabniki…

Read Full Post »

Older Posts »

%d bloggers like this: