Feeds:
Objave
Komentarji

Archive for the ‘Priprava projekta’ Category

Včasih združba, v kateri se izvaja projekt, ni velika ali ni razdeljena po oddelkih (manjše podjetje, društvo, neformalna skupina), poleg tega je lahko v projekt vključenih le nekaj internih ljudi (zaposlenih, članov društva), večino dela pa izvedejo zunanji izvajalci. V tem primeru ne moremo opredeliti projektne organizacije, prikazane v predhodnih prispevkih. Vseeno pa je zavoljo jasnejše opredelitve razmerij med člani tima smiselno izdelati organigram sodelujočih na projektu.

Navedel sem že, da običajno obstajajo trije nivoji projektnega tima – ožji tim strokovnimi nosilci, širši tim (zaposleni v podjetju oz. člani društva, ki sodelujejo pri izvedbi aktivnosti) ter zunanji izvajalci. Projektni manager in strokovni nosilci koordinirajo delo ostalih, ki jim poročajo o izvedbi aktivnosti. Kdo sodeluje s kom, kdo komu delegira naloge in komu kdo poroča, se običajno prikaže v posebnem organigramu, katerega tuji avtorji imenujejo RBS (Resource Breakdown Structure).

Sicer pa v tuji literaturi poleg RBS najdemo tudi OBS (Organizational Breakdown Structure), a ne gre za različno poimenovanje istega ampak za dva različna organigrama. Oba tipa sta nadgradnja WBS, še bolje rečeno, WBS je osnova za izdelavo OBS in RBS. Razjasnitev razlik med vsemi tremi pojmi sem zasledil v PMBOK (2000) ter pri Levinu (2002):

  • WBS prikaže členitev proizvodov na delovne pakete,
  • OBS prikaže strukturo oddelkov združbe, vključenih v projekt,
  • RBS prikaže členitev tima po skupinah strokovnjakov iste stroke ali oddelka (npr. programerji) ali po sklopu aktivnosti, povezanem z delom obsega projekta, (npr. programska oprema)

Primer RBS – Organizacija gasilske veselice

Organigram izvajalcev projekta*

Newel (2002) navaja, da so v OBS delovne naloge iz WBS povezane z oddelki, ki bodo naloge izvedli, drugi avtorji pa poudarjajo, da OBS prikazuje oddelke združbe, ki so zadolženi za izvedbo sklopa aktivnosti oz. ki prevzamejo zaokroženo celoto obsega del. Fleming še dodaja, da je z OBS prikazana hierarhija odgovornih za izvedbo nalog po WBS-u do najnižjega managerskega nivoja. Vsak oddelek združbe tako lahko jasno vidi, za kaj je odgovoren!

RBS sem prikazal, ko sem opisoval vlogo tipičnih udeležencev projekta. Newel poudarja, da je razlika med OBS in RBS v tem, da prikaže RBS vse posameznike, ki so navedeni kot izvajalci aktivnosti v terminskem planu, OBS pa prikaže le oddelke. Čeprav je res, da oba organigrama v tuji literaturi nista prav pogosto prikazana, pa se mi zdi predvsem uporaba RBS zelo koristna. Z RBS, ki bi ga lahko poslovenili kot organigram izvajalcev projekta, nazorno prikažemo »podtime« (kateri nosilec s katerimi člani širšega tima pokriva določeno področje), poleg tega pa tudi opredelimo, kdo od internih članov tima je zadolžen za komunikacijo in kontrolo delovanja zunanjih izvajalcev. Nasprotno se mi uporaba OBS ne zdi smiselna, če smo predhodno vključene oddelke (in člane tima iz teh oddelkov) prikazali v sklopu matrične organizacije.

Ko smo že pri členitvah izvajalcev projekta, naj povem, da sem našel tudi CBS (contractor breakdown structure, Brandon, 2006), kjer podobno, kot za interne udeležence projekta, izdelamo hierarhično strukturo vseh podizvajalcev. Vendar pa je CBS za končnega naročnika zgolj informativnega značaja, saj nimajo neposrednega vpliva na pogodbene izvajalce, ki so dejansko podizvajalci naročnikovih podizvajalcev (pogodbe, kontroliranja dela).

Advertisements

Read Full Post »

Čeprav bi glede na izkušnje lahko rekel, da sta šibka in močna matrična tisti organizaciji, ki jih osebno najbolj priporočam, pa le redki avtorji prejšnjič prikazano matrično organizacijsko strukturo še podrobneje delijo na šibko, uravnoteženo in močno.

Glavna razlika med vsemi tremi je v pristojnostih managerja projekta in s tem povezano “razpoložljivostjo” članov tima. V primeru uravnotežene naj bi imela linijski in projektni manager enakovreden vpliv na člane tima, ki naj bi projektu posvečali pol svojega časa. Napisal sem “naj”, ker je ta »polovička« nekako težko določljiva, poleg tega pa v PMBOK navajajo, da so pristojnosti managerja projekta nizke do zmerne, kar je tudi zelo”relativno” in močno odvisno od projektne organizacijske kulture. Zato je bolj smiselno razmišljati o šibki ali močni matrični organizaciji, ki sta jasneje določljivi in tudi v praksi manj konfliktni.

Šibka matrična struktura je zelo podobna funkcijski, z eno pomembno razliko – obstaja odgovorna oseba, ki skrbi za učinkovito izvedbo projekta. Običajno se imenuje koordinator projekta in ima nižje pristojnosti kot običajen manager projekta, s tem pa tudi manj odgovornosti. Odgovoren je za planiranje in kontroliranje projekta, kar pa se tiče izvedbe, pa koordinira oddelke, med tem ko so linijski managerji odgovorni za izvajanje aktivnosti. Koordinatorju neposredno ne dodelijo članov tima, čeprav lahko sodeluje z izvajalci iz oddelkov, ki pa se glede na taktične odločitve njihovih nadrejenih lahko menjajo. Koordinator lahko vzporedno koordinira več projektov, uporaba te organizacije pa je priporočljiva za organizacijsko enostavnejše prodajne in inženiring projekte.

Šibka in močna matrična organizacijska struktura

Šibka in močna matrična organizacija*

Močna matrična struktura je z vidika pristojnosti managerja projekta zelo podobna čisti projektni organizaciji, razlikuje pa se v tem, da člani tima ostajajo v matičnih oddelkih, a večino svojega delovnega časa posvečajo enemu projektu. Ker več sodelujejo s projektnim kot z linijskim managerjem ima prvi načeloma tudi več vpliva na izvajalce. Projektni manager je polno odgovoren za projekt, linijski managerji pa mu dodelijo osebje s polnim ali delnim delovnim časom in strokovno svetujejo pri izvedbi aktivnosti. Pri tej organizacijski strukturi manager projekta običajno posveča celoten delovni čas le enemu projektu.

Žal pa si nekateri matrično organizacijo predstavljajo po svoje, kar sem omenil že prejšnjič: »managerji projektov so strokovnjaki, ki poleg strokovnega dela tudi koordinirajo projekt«. Ta rešitev ni priporočljiva, saj združba s tem lahko izgubi vrhunskega strokovnjaka in dobi slabega managerja. Petrovo načelo (človek napreduje do nivoja svoje nesposobnosti) se pri projektnem delu izrazi še hitreje, saj so za management projektov pomembne druge osebnostne lastnosti, znanja in veščine, kot za strokovno delo. Nekateri strokovnjaki so neorganizirani, drugim je nelagodno voditi ljudi, se ukvarjati z dokumentacijo in zapisniki, sprejemati odločitve… Management projekta je zato zanje lahko zelo stresno delo, še posebej, ker jih odvrača od njim ljubšega strokovnega dela.

Zato zelo priporočam šibko in močno matrično organizacijo, s sposobnimi organizatorji (koordinatorji, managerji). Projektni management je svoj poklic in je le izjemoma lahko »dodatek« strokovnemu delu.

V prejšnjem prispevku sem tudi omenil, da obstajajo različni položaji managerja projekta v hierarhiji združbe. Danes prikazujem dva primera (slika), kjer je manager / koordinator zaposlen v projektni pisarni (angl. project management office, PMO). Kot vidite, je PMO lahko organizirana štabno ali pa kot oddelek, enakovreden ostalim poslovnim funkcijam ali enotam. O vlogi in lokaciji PMO v združbi bom še pisal, tokrat pa navajam le nekaj možnih funkcij PMO: administrativna podpora projektom, zagotavljanje enotnega načina izvajanja projektov (pravila, postopki, orodja), izobraževanje, svetovanje in mentorstvo, analize projektov in prenos izkušenj, strateški razvoj združbe…

Read Full Post »

Matrična projektna organizacija je nastala, ko so avtorji poskušali združiti dobre lastnosti (in odpraviti slabosti) funkcijske in projektne strukture. Člani projektnega tima lokacijsko ostanejo v svojih oddelkih, pri čemer lahko opravljajo operativna dela v sklopu matičnega oddelka in hkrati sodelujejo ne enem ali več projektih. Linijski manager poskrbi, da so posamezniki polno zaposleni – če nekdo enemu projektu posveča 30% svojega delovnega časa, ga nadrejeni razporedi še na druge projekte ali mu dodeli druga operativna dela.

Projektni manager tako dobi »na pósodo« ljudi iz različnih oddelkov. Linijski manager je odgovoren, da na projekt razporedi usposobljenega človeka, hkrati pa s svojim znanjem in izkušnjami posredno, preko člana tima, prispeva h kakovostni izvedbi projekta. V primeru, da posameznik projektnih nalog ne izpolnjuje zadovoljivo, oba managerja problem rešujeta skupaj.

Pri matrični organizaciji obstaja več možnih lokacij oz. položajev (fizično, v hierarhiji) managerja projekta – lahko je neposredno podrejen vodstvu (primer na sliki), kar mu daje močno avtoriteto (višje pristojnosti, večja podpora vodstva). Lahko je zaposlen v projektni pisarni, kjer so zaposleni profesionalni managerji projektov, nadrejeni pa je običajno manager portfelja / skrbnik projektov. Zelo pogosto pa so managerji projektov kar strokovnjaki, ki so locirani v svojem matičnem oddelku, poleg svojega strokovnega dela pa tudi koordinirajo projekt. Sledna rešitev ni ravno priporočljiva, več o tem pa naslednjič.

Matrična organizacijska struktura

Prednosti projektno matrične organizacije:

  • optimalna obremenitev članov tima, odpravi se podvajanje dela, strokovnjaki lahko delujejo na več projektih;
  • večja prilagodljivost spremembam v okolju, tehnologiji ali spremenjenim zahtevam kupcev;
  • dobri informacijski tokovi – horizontalno in vertikalno;
  • člani tima ohranjajo stik s stroko, svoje ideje lahko prediskutirajo s kolegi.

Slabosti:

  • problem »dvojnega vodenja« – izvajalec je za izvedbo aktivnosti podrejen managerju projekta, strokovno in disciplinsko pa funkcijski vodji; v primeru konfliktov med nadrejenimi, člani tima trpijo zaradi nedorečenih prioritet svojih nalog in preobremenjenosti;
  • nejasna razmejitev pristojnosti in odgovornosti med projektnim in linijskimi managerji, še posebno v primeru slabo razvite projektne kulture;
  • je kompleksna in težja za upravljanje v multi-projektnem okolju –  v primeru sprememb in reševanja zamud je premeščanje ljudi s projekta na projekt zelo zahtevno.

Pa še to – management projektov v matrični organizaciji je zelo praktičen način izobraževanja, neke vrste trening za bodoče najvišje managerje. Projektni manager mora usklajevati ljudi z različnimi strokovnimi stališči in pogledi, z različnimi vrednotami in načini delovanja. Skozi projekte spozna specifiko posameznih strok in oddelkov, ljudi, način dela in razmišljanja. Po nekaj projektih zelo dobro pozna celotno podjetje…

Read Full Post »

V prejšnjem, uvodnem prispevku s področja organiziranja projektov, sem navedel, da si večina pod »organizacijo projekta« predstavlja tipične organizacijske strukture, s katerimi je opredeljeno razmerje med projektnim timom in nadrejeno organizacijo. Zato bom v naslednjih nekaj prispevkih predstavil te strukture. Za začetek si oglejmo izvajanje projektov v funkcijski organizaciji ter njeno popolno nasprotje, vsaj kar se tiče pristojnosti managerja projekta, (čisto) projektno organizacijo.

Klasično linijsko – funkcijsko organizacijo si predstavljamo z bolj ali manj tipičnimi oddelki (proizvodnja, nabava, prodaja, razvoj…), pri čemer obstajata dva tipa projektov, ki se izvajata v taki organizaciji. Pri prvem večino aktivnosti izvedejo v enem oddelku, manager oddelka pa je odgovoren za projekt (uvajanje spremembe, npr. IT podpore). V drugem primeru pa oddelki zaporedno izvajajo posamezne sklope aktivnosti, brez da bi pri tem resneje sodelovali. Zaradi tega mnogokrat pride do kritiziranja rezultatov aktivnosti predhodnikov, s tem pa do popravil ali celo do vračanje projekta v prejšnjo fazo. V veliko primerih se za te projekte ne določi odgovornega za celoten projekt, ampak je vsak funkcijski manager je odgovoren za svoj del. Zaposleni, ki opravljajo »projektne aktivnosti«, niti ne čutijo pripadnosti projektu, saj so te aktivnosti zanje »vsakodnevno operativno delo«, ki jim ga delegira nadrejeni.

Funkcijska in projektna organizacija*

Takšna organizacija izvajanja projektov je vse manj v uporabi, značilna pa je za združbe z nizko stopnjo projektne organizacijske kulture. Težko bi celo rekli, kdaj je njena uporaba smiselna; mogoče le v manjših podjetjih, kjer projektov ni veliko in niti niso zelo pomembni. Vsekakor pa je pomembno, da določimo nekoga, ki poskrbi za koordinacijo vseh oddelkov v združbi in je odgovoren za celoten projekt. Največkrat ima naziv koordinator projekta (Kerzner govori o »Line staff organisation«), vendar pa je to že neke vrste (šibka) matrična organizacija. O njej pa drugič…

*

PROJEKTI V FUNKCIJSKI ORGANIZACIJI
  • PREDNOSTI
  • fleksibilnost izkoriščanja kadrov v enoti
  • strokovnjaki delujejo na več projektih
  • skupno reševanje problemov v enoti
  • prenos znanja in izkušenj
  • Enostavno nadomeščanje izvajalcev
  • SLABOSTI
  • redno delo ima prioriteto
  • aktivnosti niso strogo usmerjene h kupcu
  • nihče ni odgovoren za celoten projekt
  • ignoriranje projekta s strani izvajalcev
  • šibka motivacija za delo na projektu

*

O projektni organizaciji, ki jo nekateri poimenujejo tudi »čista projektna« (angl. pure; Kerzner, Lock, Meredith & Mantel), govorimo, ko združba ustanovi začasni samostojni oddelek, kamor se iz matičnih oddelkov za čas izvedbe projekta prerazporedijo uslužbenci, člani projektnega tima. V primeru, da kadri s potrebnimi veščinami in znanjem v združbi trenutno niso na razpolago, se jih za čas projekta na novo zaposli. Vsi zaposleni v oddelku so torej člani projektnega tima in delajo celoten delovni čas le na aktivnostih v sklopu projekta. Nadrejeni oddelka je manager projekta, ki prevzame polno odgovornost za projekt in ima popolno avtoriteto – njegove pristojnosti so enake pristojnostim managerjev ostalih oddelkov, pri čemer slednji na projekt nimajo nobenega vpliva.

Organizacija je najbolj primerna za projekte, kjer se večina aktivnosti izvaja na področju ene stroke, za operativno delo v projektno organiziranih IT, inženirskih ali gradbenih podjetjih ali za hitro izvedbo kriznih projektov.

PROJEKTNA ORGANIZACIJA
  • PREDNOSTI
  • celovit pristop k projektu
  • jasne odgovornosti in pristojnosti v timu
  • spodbuja sodelovanje v timu
  • možno sprejemanje hitrih odločitev
  • izkušen uigran tim za nov projekt
  • SLABOSTI
  • konfliktnost z matično organizacijo
  • slabša motiviranost pred zaključkom
  • slabša strokovnost
  • slaba izkoriščenost ljudi
  • višji stroški projekta (delovne ure)

*

 

Read Full Post »

Z današnjim prispevkom prehajam na drugi del priprave projekta – na organiziranje. Pojem »organizacija« ima več pomenov: lahko jo vidimo kot proces zagotavljanja smotrnega delovanja (pogovorno: organizacija dela); kot družbeno (socialno) enoto – združbo, ki deluje zaradi uresničitve skupnega cilja; ter kot sestav medsebojnih razmerij med člani združbe, ki zagotavlja obstoj in razvoj ter smotrno uresničevanje ciljev združbe. Prvi, procesni vidik, smo obdelali s planiranjem projekta, v tem delu pa se bomo posvetili slednjemu.

Večina pod organizacijo projekta najprej pomisli na tipične organizacijske strukture, s katerimi opredelimo razmerje med projektnim timom in nadrejeno organizacijo (npr. matrično ali projektno organizacijo). Tudi večina avtorjev pod tem pojmom v knjigah opisuje značilnosti, prednosti in lastnosti različnih struktur. Vendar pa organiziranje vključuje več stvari – pomembna so še razmerja v projektnem timu ter med vsemi udeleženci projekta (stakeholders), ter jasno opredeljene njihove vloge, pristojnosti in odgovornosti.

Področja organizacije projekta

Organiziranje oz. organizacija projekta*

Pojmi, ki se poleg organizacijskih struktur največkrat pojavljajo v povezavi z organiziranjem in jih bom podrobneje opisal v kasnejših prispevkih, so OBS oz. RBS (Organizational / Resource Breakdown Structure), ki prikaže razmerja med udeleženci projekta (tudi v povezavi z WBS), ter RAC matrika oz. RAM (Responsibility and Competence matrix / Responsibility Assignment Matrix), s katero se določijo vloge, pristojnosti in odgovornosti udeležencev.

Organizacijske strukture se prikažejo z organigramom, ki grafično prikaže oddelke / skupine in posameznike po različnih ravneh, hierarhične odnose, formalne in komunikacijske povezave med njimi. Lahko se nadgradi tudi z opisi delovnih nalog posameznikov in skupin. Višji v hierarhiji določa cilje in delegira naloge nižjim, ki navzgor poročajo o izvedbi nalog.

Organiziranje zagotavlja urejeno delovanje z jasnimi odnosi in odgovornostm ter preprečuje različne možne medosebne konflikte v času izvedbe projekta – npr. izjave, kot so »To pa ni moje delo« ali »O tej zadevi bi nujno morali dobiti še moje mnenje«…

Nekateri med organiziranje vključujejo tudi opredelitev pravil delovanja projektnega tima (npr. način komuniciranja in poročanja), organizacijo obvladovanja dokumentacije in informacij, ter jasno opredelitev sodelovanja z linijskim managementom, svetovalci, naročnikom in drugimi vpletenimi strankami. Omenjena področja bi lahko vključili tudi v plan komunikacij in plan kontrole, a ker jih še nisem podrobneje obravnaval, jih bom prikazal v sklopu organiziranja projekta.

Read Full Post »

Kontroliranje je zadnji korak procesa (projektnega) managementa – potem, ko smo v fazi priprave izdelali plan in opredelili organizacijo projekta, se z vodenjem trudimo, da bi izvajalci čim bolj učinkovito izvajali aktivnosti, s kontroliranjem pa redno preverjamo, če zadeve potekajo po planu. Proces kontroliranja vključuje spremljanje izvedbe, primerjavo stanja s planom, ugotavljanje odstopanj in planiranje ter izvedbo korektivnih akcij / ukrepov, s katerimi zagotovimo, da bo projekt izpeljan v okviru postavljenih ciljev (slika).

O kontroli bo še veliko napisanega v kasnejših prispevkih, ko pridemo do faze izvedbe projekta, tokrat pa bom predstavil le aktivnosti priprave projekta, ki so povezane s kontroliranjem. Kot sem navedel, je »preverjanje poteka« ali »spremljanje izvedbe« projekta (angl. project tracking) prvi korak kontroliranja, zato je del priprave projekta tudi planiranje učinkovitega in zanesljivega načina pridobivanja informacij o stanju izvedbe.

Strokovnjaki navajajo več področij kontroliranja (obseg, čas, kakovost, stroški, tveganja, dobave) zato je smiselno, da se v elaboratu opredeli način pridobivanja informacij o stanju na vseh navedenih področjih.

Kontroliranje projekta – proces, področja, ugotavljanje stanja

KOntroliranje projekta - področja, plan, zahteve *

Poznamo več načinov pridobivanja informacij (slika), od opazovanja izvajalcev in merjenja rezultatov (npr. napredovanje gradnje), preko osebnih stikov in ustnega poročanja (sestanki, razgovori), do pisnih poročil izvajalcev aktivnosti. Zelo priporočljivi so redni kontrolni sestanki (angl. progress meetings), kjer se (npr. tedensko) sestajajo člani ožjega tima, kjer odgovorni za posamezna področja managerju poročajo o stanju na aktivnostih.

Manager projekta tako v elaboratu projekta opredeli pogostost in načine poročanja – vrste (ustno / pisno, po e-pošti, z uporabo obrazca) in ravni poročil (pogostost, področja, komu se posreduje, kateri podatki so vključeni…). Prav tako se že na začetku opredelita termin in lokacija kontrolnih sestankov – sejna soba se npr. rezervira kar za celotno trajanje projekta, poleg tega se teh sestankov v času izvedbe posebej ne sklicuje.

Določeni projekti zahtevajo še posebna orodja in postopke kontroliranja, ki jih je potrebno v začetku projekta razviti ali kupiti. Lahko razvijemo poseben informacijski sistem za potrebe kontroliranja! Poleg tega je potrebno določiti podatke, ki jih je treba zbirati (količine, ure dela, izmere, rezultate testiranj…) ter kdo in kje zbira podatke (člani tima, projektna pisarna, druge službe; na terenu, preko informacijskega sistema, ipd.).

Vseeno pa se plan kontrole, podobno, kot sem navedel že pri prejšnjih dveh prispevkih (nabava, kakovost), vedno ne vključi v elaborat projekta. To velja predvsem za projekte, ki se (bolj ali manj rutinsko) v določenih združbah stalno pojavljajo (npr. razvoj izdelkov, inženiring, IT), zaradi česar je kontroliranje (termini, odgovorni, postopki, način poročanja, ipd.) v veliki meri opredeljeno z organizacijskim predpisom in se za posamezne projekte posebej ne planira.

Read Full Post »

Kot sem napisal v enem zgodnejših prispevkov, je cilj projektnega managerja »ustvariti proizvode projekta z ustrezno kakovostjo, v okviru planiranega časa in predvidenih stroškov”, kar sem naknadno obravnaval tudi pri opredelitvi ciljev in omejitev projektnega managementa. V primeru slabe kakovosti so potrebna popravila, ki zahtevajo dodaten čas in stroške (včasih tudi po zaključku projekta), zaradi česar je kakovost zelo pomemben dejavnik učinkovitega izvajanja projektov.

Skozi razvoj obvladovanja / zagotavljanja kakovosti se je poudarek s kontroliranja (končnih) proizvodov v vmesnem obdobju preselil na kontroliranje izvajanja aktivnosti, kasneje pa na vzpostavljanje celovitih sistemov zagotavljanje kakovosti na vseh nivojih (TQM, total quality management). Lahko bi celo dejali, da je za ustrezno kakovost v osnovi potrebno imeti kakovosten organizacijski predpis za področje izvajanja projektov, ta mora biti usklajen z ostalimi internimi pravilniki, vse skupaj pa naj bi bilo nadgrajeno z ustrezno organizacijsko kulturo (kar pomeni, da ljudje v večji meri upoštevajo pravila, zapisana internih predpisih).

Proces zagotavljanja kakovosti na projektu

Proces zagotavljanja kakovosti na projektu
*

Stroka proces obvladovanja kakovosti na projektih običajno deli na (1) opredelitev (zahtev) kakovosti, (2) planiranje zagotavljanja kakovosti, (3) zagotavljanje in (4) kontroliranje kakovosti. Tokrat se bom usmeril v prva dva področja, več o zagotavljanju ter kontroliranju pa sledi v prispevkih v okviru tem o izvedbi projekta.

Zahtevano (pričakovano) kakovost opredeli naročnik v specifikacijah proizvodov projekta. V osnovi je razvidna iz opisov izgleda, funkcij, ipd. , še natančneje pa jo opredeljujejo morebitni standardi in predpisi, ki jih naročnik definira v specifikacijah ali pa so opredeljeni z zakonodajo za določene vrste projektov (npr. statika objektov, varnostni predpisi za izdelke, število varnostnikov na prireditvi). Projektni manager pa mora pri prevzemu projekta zagotoviti, da so zahteve jasno opredeljene in da jih tako naročnik kot člani tima enako razumejo.

Na podlagi specifikacij, zakonskih in internih predpisov / pravilnikov s področja kakovosti sledi v fazi priprave projekta planiranje konkretnih aktivnosti in postopkov zagotavljanja kakovosti ter odgovornih za njihovo izvedbo. Priporočljivo je za vsako aktivnost projekta, vključeno v plan / WBS , opredeliti zahteve kakovosti in se dogovoriti o zagotavljanju le-te (način dela, uporabljena tehnologija, postopki, orodja, preprečevanje napak,…). Da bi zagotovili ustrezno kakovost, se v plan projekta lahko dodajo tudi nove aktivnosti (npr. usposabljanje ljudi, nabava opreme). Naslednji korak je opredelitev preverjanja / testiranja vmesnih rezultatov zaključenih faz (npr. prototipa, načrtov objekta, zamisli programa prireditve, ipd.).  Izvedba teh preverjanj je lahko zaupana osebam ali institucijam, ki niso vključene v izvedbo projekta (laboratoriji, neodvisni strokovnjaki), včasih pa kakovost vmesnih rezultatov potrdi kar naročnik projekta.

Pa še to: med zagotavljanje kakovosti lahko štejemo tudi opredelitev formalnega procesa obravnavanja (in potrjevanja) sprememb, saj delne in med udeleženci projekta neusklajene spremembe (proizvoda, tehnologije, izvedbe) lahko močno vplivajo na slabšo kakovost!

Read Full Post »

« Newer Posts - Older Posts »

%d bloggers like this: