# 5 Projektijuhtimine

Selle teema materjale läbi töötades saad põhiteadmised IT projektide juhtimisega seotud teemadest.

# A.5.1 Infosüsteemide projektid

Selle alateema materjale läbi töötades saad teada:

• mis on projekt
• millised on projekti kõige iseloomulikumad tunnused
• mille poolest erinevad IT projektid äriprojektidest
• kuidas projekte klassifitseeritakse
• mida projektides juhitakse
• mida tuleb teha selleks, et jõuda eduka projektini
• millised tegurid takistavad edukate projektideni jõudmist.

# Mis on projekt?

Sõna projekt on tänaseks muutunud igapäevaselt kasutatavaks enamikes eluvaldkondades. Projektidest ning nende läbiviimisest räägitakse nii koolis kui ehitusfirmas, nii pangas kui transpordiettevõttes. Ilma uuringuteta võib väita, et väga suure tõenäosusega on täna raske leida ettevõtet või organisatsiooni, kus ei oleks viimastel aastatel ellu viidud ühtegi projekti.

Tavaliselt defineeritakse projekti, kui ühekordset kindla alguse ja lõpuga ettevõtmist. Sõnal "projekt" on Eestis aga oluliselt laiem tähendus.

Seetõttu peab alati kindlaks määrama, mis kontekstis projektist räägitakse, sest sõnal "projekt" on vähemalt neli tähendust:

1. ühekordne töö
2. joonised koos seletuskirjadega (näiteks maja projekt)
3. kaasrahastamise taotlus (näiteks Leonardo praktikaprojekt)
4. dokument, mis ei ole veel valmis (näiteks eelnõu projekt)

Edaspidi räägime me projektist, kui täpselt määratletud eesmärgiga ühekordsest tööst, mis tuleb ära teha kindla aja jooksul ning mille tegemiseks mõeldud raha hulk on piiratud.

# Projekti kõige iseloomulikumad tunnused

Kõik projektid, mis käivitatakse ja ellu viiakse kutsuvad mingil kujul esile muutusi, täiustusi või edasiarendusi.

Kõiki projekte iseloomustab:

• ühekordsus
• tähajastatus
• uudsus
• valdkondadevahelisus
• riskirohkus
• planeerimise ja juhtimise keerulisus

Projektid on ühekordsed , sest täpselt samasugust ülesannet ei tule enam lahendada või on analoogse ülesande lahendamise vajadus lähemal ajal ebatõenäoline.

Projektid on tähtajastatud , sest kindlaks on määratud kuupäev, millal projekt peab olema lõpetatud.

Projektid on uudsed , sest täpselt sellisel kujul ei ole ülesannet varem esinenud. Isegi enamike algtingimuste samasuse korral on midagi, mis muudab projekti uudseks. Kõige sagedamini on selleks uudseks elemendiks aeg või siis organisatsioon, kus projekti läbi viiakse.

Projektid on valdkondadevahelised , sest projekti läbiviimiseks ei piisa ainult ühe kitsa eriala spetsialistidest.

Projektid on riskirohked , sest me ei oska kõiki eesmärgini jõudmiseks vajaminevaid tegevusi ette näha ning seetõttu jääb projektidesse väga palju määramatust, mis muudab ta riskantseks.

Projektid on keerulised planeerida ja juhtida , kuna täpselt sellist ülesannet samade algtingimustega ei ole varem esinenud.

Projektid on konfliktsed , sest tuues endaga kaas muutusi tavategevuses kätkevad nad endas alati mingite huvigruppide vastuseisu.

# A.5.1.1 Mille poolest erinevad IT ja äriprojektid?

Eelmises alalõigus välja toodud tunnused on omased nii IT- kui äriprojektidele. Vaatamata nendele sarnasustele on IT- ja äriprojektidel olulisi erinevusi. Erinevuste paremaks väljatoomiseks võrdleme IT projekti konkreetse maja ehitamise projektiga.

Olulisemad erinevused on:

• kliendipoolse lähteülesande täpsuses
• lõpptulemi hoomatavus
• planeerimiskindluses
• projekti edenemise hindamises
• väljundis
• muutustega seotud vastuseisus.

Ehitusprojekti lähteülesanne on ehitajale väga konkreetne ja selge. Selleks on arhitekti ja kliendi koostöös sündinud projekt. IT projektide puhul on aga lähteülesanne sageli kliendi ebamäärane ettekujutus sellest, mida võiks või peaks uus tarkvaralahendus tegema.

Ehitusprojekti korral on kliendil arhitektuurse lahenduse ja jooniste kaudu võimalik saada üpris selge ettekujutus sellest, milline maja välja nägema hakkab. IT lahenduse kliendile arusaadavaks tegemine on aga väga keeruline, sest visuaalselt ei ole alguses midagi demonstreerida.

Ehitusprojekti ajalise kestuse määramine läbi töömahtude on suhteliselt täpne. IT projektide korral on ajalise kestuse määramine üks keerukamaid ülesandeid, sest arendustegevuse käigus võib ette tulla hulgaliselt muutusi, mis nõuavad täiendavat aega.

Ehitusprojekti vahetulemuste hindamisel ei teki küsimust, kui suur osa tööst on tehtud. Vahetulemused on lihtsalt hinnatavad ja vaheakteerimise teostamine ei ole keeruline. IT projektide korral on aga vahetulemusele hinnangu andmine sageli võimatu, sest tulem ja selle kvaliteet selguvad tihti alles peale kogu töö lõppu.

Väljund on ehitusprojektil ja IT projektil absoluutselt erinevad. Ühel juhul tekib materiaalne objekt teisel juhul immateriaalne väärtus.

Kui ehitusprojekti korral on sellega kaasnevatesse muutustesse suhtumine pigem positiivne, siis IT projektidega kaasnevatesse muutustesse suhtutakse tihtipeale negatiivselt, sest uue tarkvaralahenduse kasutajad peavad hakkama ümber õppima.

# A.5.1.2 Kuidas projekte klassifitseeritakse?

Projekte võib kõige üldisemalt liigitada arendus ja teostusprojektideks. Arendusprojektide eesmärgid ei ole alati konkreetsed vaid sageli hoopis nägemuslikud. Juhul, kui firma otsustab käivitada firmasisese arendusprojekti, siis tuleb sageli alustada kõigepealt projekti abil lahendatava probleemi määratlemisega. Arendusprojektide korral ei ole tavaliselt ka eesmärkide saavutamiseks vajaminevad tegevused alati teada. Väga keeruline on selliste projektide puhul määrata ühe või teise tegevuse kestust.

Teostusprojektid on vähem unikaalsed, kui arendusprojektid. Teostusprojektide korral on eesmärgid selged ja konkreetsed. Projekti ülesandeid teatakse hästi ja ülesannete kestuse määramine on suhteliselt lihtne.

Samas ei ole olemas ühtegi projekti, mis oleks puhtalt arendusprojekt või puhtalt teostusprojekt. Kõikides projektides on sees mõlemat komponenti. Skemaatiliselt võiks seda kujutada järgmiselt:

Kui enamiku projektide korral on alguses ülekaalus arenduslik moment, siis mida aeg edasi, seda vähemaks jääb projektis arenduslikkust ning kasvab teostuslikkuse moment. Samas ei kao ka päris projekti lõpus ära arenduslikkus, sest veel viimasteski etappides ning ka kõige viimase töö juures võib vaja minna mingit uudset, loomingulist lähenemist.

# Mida projektides juhitakse?

Projektides juhitakse üheksat komponenti:

Eesmärgi juhtimine scope management peab andma selge vastuse küsimusele, mida peab tegema või kuhu tuleb antud projekti jooksul välja jõuda. See ei ole ühekordne tegevus projekti käivitamisel vaid eesmärgi juhtimisega tuleb tegeleda kogu projekti jooksul. Eriti oluline on see IT arendusprojektide korral, kus sageli juhtub see, et esialgne eesmärk kipub silmist kaduma.

Aja juhtimine time management peab andma vastuse küsimustele, mis järjekorras tuleb töid teha ja mis ajal tuleb mingit tööd teha. Need on kõikide projektide korral kriitilised küsimused, mis määravad suuresti kogu projekti edukuse.

Kvaliteedi juhtimine quality management peab tagama vahe- ja lõpptulemuste vastavuse kehtestatud nõuetele. Ilma kvaliteedi juhtimiseta ei ole võimalik jõuda tellijat rahuldava lõpptulemini.

Kulude juhtimine cost management peab projekti alguses välja tooma selle, kui palju töö ja muud ressursid maksavad. Projekti käigus peab aga kulude juhtimine tagama pideva ülevaate sellest, kui palju on projektis kulutatud ja kui palju veel on vaja tulemini jõudmiseks kulutusi teha.

Inimeste juhtimine human resources management peab kavandamise etapis näitama, kui palju ja milliseid inimesi on projekti elluviimiseks vaja. Projekti käigus on aga vaja tegeleda inimeste motiveerimisega, informeerimisega, konfliktide käsitlemisega, tegevuste kontrollimisega jms..

Infovahetuse juhtimine communication management peab määratlema, kellega millise info vahetust peab korraldama.

Riskijuhtimine **integration management**peab tagama pideva ülevaate sellest, milline on projektiga seotud määramatuse aste ja millised faktorid võivad ohustada projekti eesmärgi saavutamist.

Allhangete juhtimine procurement management peab tagama õiged kokkulepped õigel ajal ja õigete allhankijatega ning katma kõik allhanketööd korrektsete lepingutega.

Seoste juhtimise integration management korral on tegemist seostega nii projektis eneses kui ka projektiväliste seostega. Erinevate seoste (rahaline, ajaline, vahenditega seotud seosed jms) arvestamata jätmine on ohtlik, sest see võib viia projekti ebaõnnestumiseni.

# A.5.1.3 Kuidas jõuda eduka projektini?

Edukaks projektihalduse eelduseks on see, et

• projekt on osa laiemast visioonist, strateegiast või eesmärgist
• ressursid, ajakava ja kvaliteet on tähtsuse järjekorda seostud ja seda tähtsusjärjekorda jälgitakse kogu projekti jooksul
• vormistatud on väga korrektne projekti lähteülesanne
• kvaliteedi nõuded on määratletud ja kogu projekti vältel ohjatud
• ajakava ja ressursid on selgelt paika pandud ja kõikide osapooltega kooskõlastatud
• piisavalt on põhjendatud, miks antud projekt käivitatakse
• täpselt on paigas:
  • milline roll on igal projektis osalejal
  • kes, mille eest vastutab
  • millised on projektijuhi/osalejate otsustusõiguse piirid
• moodustatud on pädev meeskond, kellel on:
  • erialane kompetentsus
  • projektitöö alane kompetentsus
• koostatud on korrektne projekti plaan
• täpselt on paika pandud muudatuste tegemise protsess
• projekti riskid on määratletud ja riski maandamise võimalused läbi kaalutud
• määratletud on projektispetsiifilised väärtused ja reeglid
• koostatud on kommunikatsiooniplaan, mida projekti jooksul jälgitakse.

# A.5.1.4 Mis takistab edukate projektini jõudmist?

Edukat projektihaldust takistavad eelkõige see, et:

• projekte alustatakse liiga hilja
• projektid katkestatakse
• püüeldakse perfektsete lahenduste poole
• palju ideid, mis ei vii kuhugi
• nõrk kontroll projektide edenemise üle
• organisatsiooni tasandil ei ole projektid prioritiseeritud või on prioriteetsus ebaselge
• projektide eesmärgid on ebaselged
• organisatsioon ei jälgi olemasolevat võimekust projekte ellu viia
• projektijuhtimist mittetoetav organisatsioonistruktuur
• kardetakse võtta riske või ignoreeritakse projektiga kaasnevaid riske
• lähteülesanne on ebaselge
• puudub seos organisatsiooni- ja projektieesmärkide vahel
• tekkivad konfliktid projekt- ja põhiorganisatsiooni vahel
• puudub selge ülevaade projektidest ja ressurssidest
• ei teata, millised on projektide vahel olevad seosed
• käivitatakse pidevalt uusi projekte arvestamata juba toimuvate projektidega

# A.5.1 Kordamisküsimused

# A.5.2 Kvaliteet, aeg, ja kulud

Selle alateema materjale läbi töötades saad teada:

• kuidas on seotud omavahel aeg, kulud ja kvaliteet
• mis on väärtusanalüüs
• millised on aja, kulude ja kvaliteedi ebakindlust mõjutavad tegurid.

# A.5.2.1 Kuidas on omavahel seotud aeg, kulud ja kvaliteet?

Iga projekti kolm kõige olulisemat suurust on aeg, kulud ja kvaliteet. Need on omavahel väga tihedas seoses. Sageli nimetatakse nende omavahelisi seoseid raudseks kolmnurgaks, mida kujutatakse alljärgnevalt.

Joonis 5-1. "Raudne kolmnurk" (The Iron Triangle). Parem tulemus nõuab reeglina rohkem aega ning rohkem ressursse (raha)

Kui nn "raudsest kolmnurgast" ühte komponenti muuta, siis tuleb arvestada sellega, et muutuvad kohe ka teised komponendid. Näiteks kui tellija soovib esialgsest kvaliteetsemat tulemust siis kindlasti läheb selle tulemuseni jõudmiseks rohkem aega ja ka raha kulub rohkem. Kui aga kärbitakse projekti eelarvet või ajalist kestust, siis tuleb arvestada sellega, et tulemus ei saa olla enam nii kvaliteetne, kui alguses kavandati.

# A.5.2.2 Mis on väärtusanalüüs?

Väärtusanalüüsi juhtimine on projektijuhtimise tehnika, mida kasutatakse projekti edenemise eesmärkidest lähtuvaks hindamiseks. Väärtusanalüüsi teostamiseks on vajalik:

• projekti plaan kus on näha hindamise hetkeks teostatud tööd
• plaanitud väärtused (aeg, raha, töömaht) hindamise hetkeks
• tegelikud väärtused (aeg, raha, töömaht) hindamise hetkeks.

Väärtusanalüüsi meetodi korral seotakse kõik erinevad projekti iseloomustavad näitajad ühtseks tervikuks ning projekti edenemise kontroll toimub kasutades üheselt mõistetavaid numbrilisi näitajaid. Eelkõige kasutatakse selle meetodi korral projekti edenemise hindamiseks teostatud tööde mahtu, eelarve täitmist ja ajakavas püsimist.

Seda meetodit kasutades toimub pidev projekti edenemise jälgimine läbi selle, et hinnatakse tegelikult saavutatut väärtust kontrolli hetkeks kavandatud väärtusega. Kontrolli hetkel liidetakse kokku kõikide teostatud tööde väärtused ja võrreldakse seda väärtusega, mis kavandati selleks ajahetkeks saavutada.

# A.5.2.3 Aja, kulude ja kvaliteedi ebakindlust mõjutavad tegurid

Iga projekt on seotud kas suuremal või vähemal määral määramatusega. See muudab aga aja, kulude ja kvaliteedi kavandamise ebatäpseks.

Eelkõige tuleneb ebakindlus nende suuruste määratlemisel sellest, et projektide korral ei suudeta või osata sageli:

• määratleda konkreetse töö mahtu

  töö maht ja töö teostajate hulk määrab ära aga selle, kui kaua see töö ajaliselt kestab.

• kirjeldada milline peaks olema projekti lõpptulem

  mida ebamäärasem on lõpptulem, seda keerulisem on paika panna projekti kvaliteedi kriteeriumit ning tööde teostamise ajalist kestust ja kulusid.

• liigendada projekti pea- ja alamtöödeks

  mida paremini on tööd liigendatud pea- ja alamtöödeks, seda lihtsam on kogu kavandamine. Tööde liigendamine pea ja alamtöödeks on projektide kavandamise üks nurgakivisid.

• määratleda kliendi ootusi

  see viib projekti käigus tööde ümber tegemiseni ning kavandamise etapis paika pandud tähtajad lähevad nihkesse, kulud suurenevad ning kvaliteet halveneb.

# A.5.2 Kordamisküsimused

# A.5.3 Projekti organisatsioon

Selle alateema materjale läbi töötades saad teada:

• kuidas on võimalik tööd projekti plaanides osadeks jaotada
• mida tuleb kooskõlastada projektgrupi liikmetega
• kuidas on võimalik projektorganisatsiooni üles ehitada
• millised on vastutusvaldkondade üliformaalse jagamise eelised ja puudused
• millised on põhilised töörollid projektides.

# A.5.3.1 Kuidas on tööd projekti plaanides osadeks jaotada?

Iga projekt koosneb suurest hulgast töödest. Projekte kavandada ja ellu viia on alati lihtsam siis, kui kogu projekt on loogiliselt jagatud pea ja alamtöödeks.

Projekti struktureerimist võib läbi viia lähtuvalt:

• objektidest
• funktsioonidest

Siin ei ole õiget ega valet lähenemist, et üks on õige ja teine on vale ning sageli rakendatakse projekti struktureerimisel ka segavorme. Küll kehtib aga reegel, et projekti tööpakettideks jaotamisel tuleb kinni pidada sellest, et:

• tagatud oleks terviklikkus
• ei oleks kattuvusi
• tööpaketid peavad olema ülevaatlikud ja selgelt teineteisest eristuvad.

Projekti struktuurplaani koostamisel peab selguma kogu täitmisel kuuluv töömaht, mis tuleb pärast projektgrupi liikmete ja alltöövõtjate vahel ära jagada.

# Mida kooskõlastada projektgrupi liikmetega?

Erinevate projektgrupi liikmete töötulemused tuleb omavahel kooskõlastada. Vastasel juhul ei pruugi projekti lõpptulemusse integreeritavad üksiklahendused omavahel sobida. Eriti oluline on töötulemuste kooskõlastamine sellisel juhul, kui töötatakse paljude projekti alagruppidega, kes töötavad geograafiliselt eri kohtades.

Kooskõlastada tuleb:

• eesmärgid

  Kui vähegi võimalik tuleb töötulemust võrrelda projekti eesmärkidega ja kontrollida, kas ei ole kõrvalekaldeid.

• alternatiivid

  Lahendust tuleb võrrelda teiste alternatiividega ja kontrollida, kas pakutu on parim.

• osade tulemused

  Projekti osade tulemused sõltuvad üksteisest. Seetõttu tuleb neid omavahel võrrelda ja kooskõlastada, saavutamaks ühtset ja homogeenset lõpptulemust. Kontrollida tuleb eelkõige osa tulemuse sobivust üldkontseptsiooni.

# Kuidas projektorganisatsiooni üles ehitada?

Projekti juhtimisstruktuur on formaalsete koostöösuhete skeem, mis kujutab endast koostisosade paigutusest ja nende omavahelistest seostest tulenevat eripärast põimikut või mustrit.

Projektorganisatsiooni ametlik ülesehitus esindab ametikohti ja nende rühmitusi (allüksusi), mille seovad üheks kogumiks nendevahelised ametlikud õigusseosed. Ülesehitus aitab paremini mõista organisatsiooni olemust ja osa ning temaga seonduvaid probleeme.

Projektide korral eristatakse:

• puhast projektorganisatsiooni
• maatriks projektorganisatsiooni ja
• projekti koordineerimist.

Puhta projektorganisatsiooni korral luuaks projekt ettevõtte juurde nii, et ta ei puuduta ettevõtte seniseid funktsioone või tegevusvaldkondi.

Maatriks projektorganisatsiooni korral luuakse projekt ettevõtte juurde nii, et projektgrupp koostatakse firma olemasolevate töötajate baasil.

Projektide koordineerimise korral luuakse projektide läbiviimiseks pidevalt muutuvad töörühmad. Töösse haaratakse töötajad lühiajaliselt sellest allüksusest, kus on olemas konkreetse ülesande lahendamiseks sobiv oskusteave.

# A.5.3.2 Projekti vastutusvaldkondade jagamise eeliseid ja puudusi

Projekti organiseerimisel on vastutusvaldkondade jaotamine väga tähtis tegevus. Paljud segadused ja ebakohad projektides tekivad tööjaotuse ja vastutuse, eeskätt seal esinevate puuduste pinnal.

Vastutusvaldkondade väga täpse määratlemise eelisteks on:

• töötajate keskendumine oma vastutusvaldkonnale
• töötajate motivatsiooni tõus
• projekti kulgemise parem jälgitavus
• suurem tõenäosus püsida ajagraafikus
• suurem tõenäosus püsida eelarves
• lihtsam on tagada tulemuse kvaliteeti
• lihtsam on anda tehtule hinnangut
• kergem on arvestada inimeste individuaalsete võimete ja kompetentsidega
• õpitakse kiiremini projektidega saadavast kogemusest.

Vastutusvaldkondade väga täpse määratlemise puudusteks on:

• projektorganisatsiooni paindlikkuse vähenemine
• projektgrupi liikmete keskendumine ainult oma ülesannetele ja huvi vähenemine kogu projekti tulemuste vastu
• loomingulisuse kahanemine
• sünergiaefekti tekkimise tõenäosuse vähenemine.

# A.5.3.3 Põhilised töörollid projektides

Selles peatükis tutvud tellija, projektijuhi, juhtrühma, projektirühma liikme, peakasutaja ja lõpptarbija rolliga projektides.

# Tellija

Igal projektil on tellija. Selleks võib olla oma ettevõtte juhtkond, osakonna või valdkonna juht. Neid nimetatakse ettevõtte sisesteks tellijateks ja tavaliselt on siis tegemist ettevõtte arendusprojektidega. Teise võimalusena võib projekti tellijaks olla kas üksikisik või ettevõte väljastpoolt firmat. Olenemata sellest, kas tegemist on ettevõtte sisese või välise tellijaga on tal kindlad ülesanded, mis on seotud:

• projekttellimuse esitamisega
• projektijuhi ametissenimetamisega (ettevõttesiseste tellimuste korral)
• projektorganisatsiooni põhivormi määratlemine (ettevõttesiseste tellimuste korral)
• tsustusõiguste sätestamine
• projekti sõlmpunktide/faaside kindlaksmääramine
• projekti prioriteetide määratlemine
• tsuste langetamine sõlmpunktides
• projektijuhi toetamine.

Tellija peaks suutma määratleda, mis on konkreetse projekti juures kõige olulisem. Kas selleks on aeg, kulud, kvaliteet, keskkonnasõbralik lahendus jms. Prioriteetide järjestamine annab projektijuhile aluse plaanimise käigus tehtavatele otsustele.

# Projektijuht

Projektijuht plaanib, ohjab ja kontrollib projektigrupi tööd nii sisulisest, personaalsest, tähtajalisest kui ka eelarvelisest aspektist.

Projektijuhi põhiülesanded on seega seotud projekti:

• plaanimisega
• ohjamise ja koordineerimisega

# Projekti plaanimine

Projektijuhi sellest ülesandest rääkides tuleb eristada lühi- ja pikaajalist plaanimist. Detailsete plaanide koostamine on alati projektijuhi ülesanne, üldplaanide koostamine aga ei pruugi seda alati olla.

# Projekti ohjamine/koordineerimine

Projekti ohjamise ja koordineerimise käigus peab projektijuht:

• jälgima projektiplaanist kinnipidamist
• juhtima alluvaid
• rakendama projektigrupi liikmeid
• teostama sisuliselt ja erialaselt kompetentselt projekti tegevused
• valmistama ette vajalikud vahendid
• informeerima
• looma vajalikke kontakte
• valmistama ette otsuseid.

# Projekti kontroll

Projekti kontrollimisega seoses on projektijuhil kaks ülesannet:

• kontroll, mis hõlmab
• projekti realiseerimise kontrolli
• projekti lõpptulemuse kontrolli
• aruandlus
• projektijuht annab projekti tellijale aru projekti realiseerimise käigust.

Projekti kontroll on projekti ohjamise ja lõpptulemuse saavutamise seisukohast kohustuslik.

# Juhtrühm

Väliste tellijate ja suurte projektide korral luuakse sageli projekti juhtrühm, kes peaks:

• lema ühenduslüli tellija ja projektimeeskonna vahel
• tegelema protsessi üldise koordineerimisega
• lema initsiaator eesmärkide püstitamisel ja prioriteetide määratlemisel
• võtma vastu eelotsuseid projekti sõlmpunktides
• toetama projektgruppi.

# Projektgrupi liige - spetsialist

Projektgrupi liikme ülesanneteks on:

• toetada projekti erialase oskusteabega
• saleda situatsiooni analüüsis ja detailsete eesmärkide formuleerimisel
• saleda tähtaegade, ressursside ja kulude planeerimises
• teostada spetsiifilisi erialaseid töid
• saleda lahendustele hinnangu andmises
• järgida kinnitatud projektiplaani.

# Peakasutaja

Peakasutaja ülesanneteks on:

• lla ühenduslüliks lõpptarbijate ja projekti meeskonna vahel
• lähteülesande koostamise organiseerimine
• projekti vajalikkuse ja eesmärkide selgitamine organisatsioonis
• lahenduse juurutamise ettevalmistamisele kaasa aitamine
• uue rakendusega kaasnevate probleemide fikseerimine ja projektijuhile edastamine

# Lõpptarbija

Lõpptarbija ülesanneteks on:

• lähteülesandesse omapoolse sisendi andmine läbi oma vajaduste kirjeldamise
• juurutamisperioodil kõikidest vigadest ja probleemidest teavitamine.

# A.5.3 Kordamisküsimused

# A.5.4 Projekti plaanimine ja järelevalve

Selle alateema materjale läbi töötades saad teada:

• mis on Gantti graafik
• miks on vaja teada projekti kriitilist teed
• millal on või ei ole projektijuhtimise tarkvara projektijuhile abiks.

# A.5.4.1 Gantti graafik

Projekti tähtajastamise tehnikaid on mitmeid, kuid täna on kõige enam levinud Gantti graafik, mis kujutab endast joongraafikut mille abil seotakse omavahel tegevused, nende tegemise kalendaarne ja ajaline kestus. Projekti tähtajastamise tulemusena tekkinud ajaplaanid aitavad jälgida projekti graafikus püsimist.

Joonis 5-2. Gantti graafik, kus on näha pea- ja alamtööd ning punasega on näha kriitiline tee tööd (joonise tegemisel on kasutatud projektijuhtimise vabavara OpenProj)

# A.5.4.2 Miks on vaja teada projekti kriitilist teed?

Projekti kriitiline tee moodustab ajaliselt kõige kauem kestvatest sündmustest. Seega on kogu projekti kestvus võrdne kriitilise tee ülesannete kestvuste summaga. Kriitilisel teel olevatel ülesannetel langevad kokku varaseim ja võimalik hiliseim algusaeg ning samuti varaseim ja hiliseim võimalik lõpetamisaeg.

Kriitilise tee määratlemine ja selgeltmõistetav eristamine on vajalik selleks, et:

teada, milliste tööde korral kõrvalekalle ajas mõjutab projekti lõpetamise tähtaega

• oleks võimalik määrata projekti ülesannete prioriteetsust
• õigeaegselt kasutusele võtta meetmeid projekti tähtaegseks lõpetamiseks
• kulutada vähem aega projekti kontrollile.

Kuna kriitilisel teel olevatel ülesannetel ei ole ajavaru, siis iga ajaline kõrvalekalle mõjutab projekti lõpetamise tähtaega. Samas annab kriitilise tee ülesannete väljaselgitamine projekti õigeaegse lõpetamise tagamiseks hea abivahendi. Kui projekti läbiviijad on teadlikud, millised tegevused on projekti edukuse seisukohalt kriitilised, on nende tööde kulgemist võimalik tähelepanelikumalt jälgida. See küll ei garanteeri, aga annab võimaluse kindlustada kogu projekti edukus.

# A.5.4.3 Projektijuhtimise tarkvara

Projektijuhtimise tarkvara aitab projektijuhti eelkõige kavandamise ja kontrolli läbiviimisel. Samas on ka kõige täiuslikuma tarkvara võimalused piiratud.

Alljärgnevas tabelis on ära toodud, kus tarkvara võib projektijuhti abistada ja kus mitte:

# Projektijuhtimise tarkvara aitab, kui on vaja:

• hallata suuri andmehulki
• teha tööd standardplaanidega
• viia sisse muutusi projekti plaani
• optimeerida projektiplaani
• analüüsida hetkesituatsiooni andmeid kavandatuga
• simuleerida ühe või teise muutuse mõju
• visualiseerida projekti struktuuri ja näidata tegevuste omavahelisi sõltuvusi
• vahetada informatsiooni projektis osalejate vahel

# Projektijuhtimise tarkvara ei aita, kui on vaja:

• defineerida projekti eesmärk
• luua projektorganisatsioon
• struktureerida projekt tööpakettideks
• määrata ühe või teise töö tegemiseks kulunud aega
• määrata üksikute tegevuste omavahelised sõltuvused
• läbi viia meeskonna nõupidamisi
• lahendada probleeme, mis on seotud projekti inimliku küljega

# A.5.4 Kordamisküsimused

# A.5.5 Projekti hindamine

Selle alateema materjalide läbitöötamise järel tead sa:

• kuidas läbi viia projekti riskianalüüsi
• miks on vaja projektiplaani
• kuidas liigitatakse projekti kulusid
• kuidas hinnata projekti tulemust.

# A.5.5.1 Kuidas viia läbi projekti riskianalüüsi?

Riske võime jaotada teadvustatud ja teadvustamata riskideks. Projekti eduka kulgemise huvides on see, et enamik teostusega kaasnevaid riske oleks projekti läbiviijate poolt teadvustatud. Teades varakult projekti läbiviimisega kaasneda võivaid probleeme on võimalik õigeaegselt reageerida ja rakendada vastumeetmeid.

Projekti riski võib defineerida kui sündmust, mis toimudes võib ohustada projekti edukat läbiviimist.

Projekti riskide analüüsil tuleb tegeleda:

• riski allikatega

  Olenevalt projektist võivad riski allikad olla väga erinevad. Liigitada võib neid ettevõttesisesteks ja välisteks.

• riskiliikidega

  Põhilised projektide edukust mõjutavad riskide liigid on:

  • majanduslikud (maksete laekumine, raha väärtuse muutus jms.)
  • tehnilised (projekti tehnilised lahendused ja nende realiseerimine)
  • juriidilised (lepingud ja seadused)
  • personaalsed (personali ebapiisav kvalifikatsioon, haigused)

• riski hindamisega.

  Erinevate riskide esinemise tõenäosus ja mõju on erinev. Seetõttu tuleks riske hinnata nende tähenduse järgi. Hinnata tuleks:

  • riski esinemise tõenäosust (suur, keskmine, väike)
  • mõju, mis riskil on kui ta esineb (suur, keskmine, väike)
  • vastumeetmete mõjusust.

Riskianalüüsi vorm:

Nr	Risk	Esinemise tõenäosus	Mõju	Meetmed riski esinemise tõenäosuse või mõju vähendamiseks

# A.5.5.2 Miks on vaja projektiplaani?

Projekti õnnestumine sõltub otseselt plaanija oskustest, tööst, hoolikusest ja ajast, mis ta kulutab plaanimisele. Projekti plaanimise käigus luuakse konkreetne mudel, millega kirjeldatakse ära tulemuseni jõudmiseks vajalikud tegevused ja ressursid. Plaanimise peamiseks eesmärgiks on luua kõikehõlmav ülevaade kogu projektist.

Loodud projektiplaan peab võimaldama:

• jaotada projekti ressursse
• vältida üle- ja alakoormust
• tagada projekti käigus ühtlast töötempot
• teadvustada kriitiliste tööde olemasolu
• ennetada riske
• valitseda tegevusvaldkonnas toimuvaid muutusi.

Plaanimise tulemusena valmiv projektiplaan peab olema süstemaatiline ja loogiline esitus projekti sisust ja vajaminevast panusest (raha, aeg, tehnoloogia jm). Esitus peaks olema lakooniline, selge ja kõigile üheselt mõistetav.

Projektiplaan võib olla:

• juhtrühmale otsusetegemise aluseks ja toeks
• projektijuhile töö juhtimise vahendiks
• juhtrühmale ja projektijuhile projekti edenemise kontrolli aluseks
• arhiivmaterjaliks, mis jääb järgmistele projektidele toeks ja taustinformatsiooniks või siis lihtsalt informeerimisevahendiks.

# A.5.5.3 Projekti kulud

Peale seda, kui projektiplaan ja ajagraafik on valmis, saab alustada eelarve koostamisega. Varem ei saa seda teha seetõttu, et kõik kavandamisel tehtud otsused mõjutavad ühel või teisel viisil projekti elluviimiseks vajalikku raha hulka.

# Projekti kululiigid

Projekti kulusid võib liigitada väga mitmeti. Kõige tavapärasemad jaotused on:

• otse- ja kaudsed kulud
• projekti läbiviimise kulud ja uue rakendatava süsteemi kulud.

# Otsekulud ja kaudsed kulud

Otsekulud on need kulutused, mida saab dokumentaalselt tõestada ja mis on projekti teostamiseks otseselt vajalikud.

Kaudsed kulud on need, mida ei ole võimalik täpselt fikseerida. Sageli nimetatakse neid ka üldkuludeks.

# Projekti läbiviimise kulud ja uue rakendatava süsteemi kulud

Projekti läbiviimise kulud on sellise jaotuse korral reeglina projekti käigus tekkivad ühekordsed töötajate palgakulud.

Süsteemi kulud on projekti tulemusena loodud uue süsteemi rakendamisel tekkivad kulud. Jaotada võib neid:

• ühekordsed kulud
• püsikulud.

Rakendatava süsteemi ühekordsed kulud on kõik need kulud, mis tekkivad projekti käigus loodava süsteemi loomisel ja ei ole projektikulud.

Rakendatava süsteemi püsikulud on kulud, mis tekivad projekti käigus loodud süsteemi ekspluateerimise käigus.

Erinevat tüüpi projektikulude illustreerimiseks vaatame järgmist näidet.

Näiteks otsustab ettevõte välja vahetada kogu kasutatava riist- ja tarkvara ning tellida uus infotehnoloogiline lahendus.

Projektikuludeks on siis:

• uue infosüsteemi loomisega seotud kulud
• riistvara paigaldusega ja tarkvara installeerimisega seotud kulud
• kasutajakoolitusega seotud kulud.

Rakendatava süsteemi ühekordseteks kuludeks on:

• riist ja tarkvara eest makstud hind.

Rakendatava süsteemi püsikuludeks on

• infosüsteemi ekspluateerimisel tekkivad kulud. (Põhiliselt on nendeks hooldus kulud ning tark- ja riistvara uuenduste kulud.)

# A.5.5.4 Kuidas hinnata projekti tulemust?

Projekti peamiseks eesmärgiks on lõpptulemuseni jõudmine ja tulemuste kasutamise tagamine. Projekti tulemuseks on asi, nähtus, psühholoogiline seisund või üldiselt igasugune objekt, mis tekitatakse projektis. Võib eristada vahe­tulemusi (nt. süsteemi kavand) ja lõpptulemusi (valmis süsteem).

Tulemuse hindamise aluseks on projekti lähteülesanne. Projekti lõpptulemust võrreldakse püstitatud eesmärgiga, kusjuures on eriti oluline välja tuua kõik kõrvalekalded plaanitust.

Tulemust võib hinnata vastates järgmistele küsimustele:

• Kuivõrd on tulemus vastavuses kavandatud eesmärgiga?

• Kui oli kõrvalekaldeid, siis kui suur on kõrvalekalle kavandatust?

• Kas projekti eesmärki muudeti projekti jooksul?

• Millised olid eesmärgi muutmise põhjused?

• Kuivõrd vastab tulemus muudetud eesmärgile?

• Kas kehtestatud kvaliteedinõuetest peeti kinni?

• Kas kõrvalekalded kavandatud kvaliteedist fikseeriti?

• Kas kvaliteedi tagamise meetmeid rakendati õigeaegselt?

Enamike projektide lõpptulemusele on võimalik anda täiesti adekvaatne hinnang ja seda ilma suuremate raskusteta. Problemaatiline on aga paljudes projektides vahetulemuste hindamine.

Keeruline ei ole see konkreetsete teostusprojektide korral kus valmib mingi käegakatsutav tulemus nagu näiteks maja ehitamine. Täiesti üheselt on siin võimalik hinnata seda, kui palju on tehtud, millise kvaliteediga on tehtu ja kui palju on veel teha.

Raske on aga hinnata vahetulemust paljude arendusprojektide ja eriti just IT arendusprojektide korral. Siin on keeruline hinnata nii tulemust ja selle kvaliteeti kui ka tegemata töö hulka. Seetõttu saab paljudel juhtudel hinnangu tulemusele ja selle kvaliteedile anda alles projekti lõpus. See aga nõuab kontrollijatelt ja hindajatelt väga suurt objektiivsust, sest vastasel juhul võivad hinnangud olla valed ja hinnatavate töömotivatsioon võib oluliselt langeda.

# A.5.5 Kordamisküsimused

# A.5.6 Projektijuhtimine ja lepingute haldus

Peale selle alateema materjalide läbitöötamist sa tead:

• millised on tüüpilise IT projekti faasid
• milleks vajatakse projektis lepinguid
• millised on lepingu kohustuslikud elemendid
• miks on vaja projekti vahehindamisi
• kuidas kinni pidada tähtaegadest.

# A.5.6.1 Tüüpilise IT projekti faasid

Klassikalistes käsitlustes koosneb IT projekt järgmistest etappidest:

• eelanalüüs ja valik
• analüüs
• projekteerimine
• teostus
• juurutamine

Kindlasti ei ole aga nii, et enne alguses tehakse üks, siis teine, siis kolmas. Kõige parem on teha neid asju paralleelselt või tsüklitena üha uuesti ja uuesti.

# A.5.6.2 Milleks vajatakse projektis lepinguid?

Üks olulisemaid dokumente projektide korral on leping. Tellija ja teostaja vahel sõlmitud formaalne leping on see, mis kaitseb mõlemat osapoolt juhul, kui tekkivad vastastikkused pretensioonid. Teostajale esitatakse lähteülesanne, mille täitmisel tuleb arvestada kehtivaid piiranguid. Teostaja võib omakorda kasutada allhankijaid. Ka sellisel juhul tuleb sõlmida leping, sest siingi on kaks osapoolt, kelle huvid vajavad kaitsmist. Mõne projekti korral on leping küll sõlmitud, kuid vaja teda ei lähe. Need on need projektid, kus kõik sujub ja osapoolte vahel ei ole lahkarvamusi. Sellisel juhul tundub, et lepingu koostamine ja sõlmimine oli üleliigne, kuid see ei ole õige. Projektid on seotud riskidega ja lepingu tõeline väärtus ilmneb siis, kui projektis juhtub midagi sellist, mida ei osatud ette näha või siis, kui osapoolte vahel tekivad lahkarvamused.

Lepinguga reguleeritakse projekti osapoolte vahelised suhted. Leping on kokkulepe, mille alusel kohustub üks subjekt, teostaja, tegema omal riisikol teise subjekti, tellija, ülesandel kindlaksmääratud tööd kas siis tellija või oma materjalist. Tellija aga kohustub tehtud töö vastu võtma ja selle eest tasuma vastavalt lepingus määratud tingimustel.

# A.5.6.3 Millised on lepingu kohustuslikud elemendid?

Kõikide projekti alguses sõlmitavate lepingute kohustuslikud elemendid on:

• tellija ja teostaja rekvisiidid (nimed, juriidilised vormid, aadressid, registreerimise ja litsentside numbrid)
• lepingu objekti kirjeldus ehk projekti eesmärk
• tähtaeg, mis ajaks peab projekt olema lõpetatud
• töömeetodid, kuidas tuleb eesmärgini viivad tegevused ellu viia
• mõlema osapoole, tellija ja teostaja, kohustused
• mõlema osapoole vastutus
• tööde teostajate kvalifikatsioon
• kvaliteedi juhtimise süsteem
• sanktsioonid lepingu mittekorrektse täitmise eest
• projekti juhtimise korraldus.

# A.5.6.4 Miks on vaja projekti vahehindamisi?

Projekti juhtimise ajal peab projektijuht olema aktiivselt tegutsev, mitte sündmustele reageeriv. Ainult nii käitudes on võimalik mõjutada projekti kulgu ja tagada aja- ja tulemusgraafikutes püsimine. Kehtestades projekti vahetähtajad ja viies läbi regulaarseid ülevaatusi kontrollpunktides saab projektijuht tagada seda, et projekti käik vastaks varem kavandatule.

Projekti graafikus püsimist tagavad üksikmeetmed on seda kvaliteetsemad, mida rohkem projektijuht ja meeskond nende kavandamiseks ja elluviimiseks aega kulutavad. Hea kavandamine tagab ka selle, et kõrvalekallete korral on rohkem reageerimisvõimalusi.

Projekti vahehindamiste kavandamise eesmärk on luua selline eelhoiatussüsteem, mis võimalikult varakult ja võimalikult täpselt näitaks, millal on vaja reageerida plaanist kõrvalekalletele.

Projekti vahehindamise käigus kogutud andmete õigeks interpreteerimiseks tuleb neid põhjalikult analüüsida. Eesmärgiks on välja selgitada, milline on hetkesituatsiooni mõju varem kavandatule. Meetodeid kuidas mõju hinnata on mitmeid. Kõige lihtsamaks ja samas ka kõige rohkem kasutatavaks on nn "on/peab olema" meetod. Võrreldaks hetkel saavutatut varem plaanituga. Selle alusel püütakse hinnata kõrvalekallete mõju projekti edasisele kulgemisele.

Kui andmeid analüüsides on selgunud, et projekti edasise arengu käigus võib tekkida probleeme kulude, tähtaegade, kvaliteedi jms siis tuleb kavandada meetmed tekkida võivate probleemide kõrvaldamiseks.

# Kuidas kinni pidada tähtaegadest?

Kui tekkib oht, et mõnest tähtajast ei ole võimalik kinni pidada, siis on võimlik kasutada järgmisi meetmeid:

• kriitilise tee tööde kestuste lühendamine

  Selleks saab kasutada kas efektiivsuse tõstmist (välise spetsialisti kaasamine, koolitus, tööde järjekorra parem läbimõtlemine jms.) või kasutatavate ressursside suurendamist (ületunnid, lisatööjõud, prioriteetide muutmine jms.)

• kavandatud töö hulga vähendamine

  Mõningate tööde või kogu projekti tööhulka vähendatakse. Samaks jääva personali hulga korral väheneb projekti kestus. Seda võtet on võimalik kasutada siis, kui tegu on mahukate projektidega, mille töö hulk oli esialgu ülehinnatud.

• tööde järjekorra muutmine

  Projekti käiku üle vaadates viiakse seni järjestikku kulgenud tööd paralleelseteks või osaliselt paralleelseteks. Võimalik on seda kasutada nende tööde juures, mille tegemiseks ei vajata kogu personali ja kus see on tehnoloogiliselt võimalik.

• tähtaegade nihutamine

  Üksikute sõlmpunktide või võimaluse korral kogu projekti tähtaegu tuleb nihutada. Seda võtet on võimalus kasutada siis, kui jõutakse tellijaga kokkuleppele ja nihutamist põhjustanud asjaolud on projektgrupist sõltumatud.

# A.5.6 Kordamisküsimused

# A.5.7 Kvaliteedikontroll

ehh "Kvaliteedijuhtimine ja infosüsteemide uuendamine"

Peale selle alateema materjalide läbitöötamist tead sa:

• mida nimetatakse projekti kvaliteediks
• mida toob endaga kaasa kvaliteedijuhtimise puudumine
• miks on kvaliteedijuhtimine üks osa IT projekti juhtimisest
• millised on standardite kasutamise põhjused
• millised on kvaliteedijuhtimise põhilised metoodikad
• kuidas on võimalik IT projekti kvaliteeti hinnata
• mille poolest erineb kvaliteedijuht projektijuhist
• mis on staatiline ja mis dünaamiline testimine.

# A.5.7.1 Mida nimetatakse projekti kvaliteediks?

Sõna kvaliteet tuleb ladina keelsest sõnast qualitas ja tähendab omadust, laadi, väärtust või headust. Kvaliteedi all mõeldakse tavaliselt toote tehnilisi omadusi, st. toote kõikide mõõdetavate ja objektiivselt fikseeritavate omaduste kogumit. Projekti kvaliteedi määramise keskpunktis on alati tellija ja tema ettekujutused ja nõudmised projekti lõpptulemusele. Samuti on olulisel kohal see, kuidas klient projekti läbiviimise käigus seda kvaliteeti tajus. Seega võib öelda, et projekti kvaliteet on väga paljuski subjektiivne suurus, mis sõltub tellijast.

Eelpooltoodust lähtuvalt võib projekti kvaliteeti defineerida, kui projekti lõpptulemuse vastavust tellija poolt kehtestatud nõuetele ja üldtunnustatud normidele.

Kvaliteediplaani kaudu sätestatakse kvaliteedi eesmärgid, kirjeldatakse projekti riske ja järjestatakse nad tähtsuse alusel. Samuti määratletakse kvaliteediplaaniga kvaliteedi tagamise meetmete tähtsusjärjekord.

Kvaliteedi plaanimine hõlmab endas projekti lõpptulemuse kvaliteeditunnuste fikseerimist ja on aluseks hilisemale kvaliteedi kontrollile.

Eristada on võimalik :

• kvantitatiivseid kvaliteedi tunnuseid

näiteks (rikete esinemise välde, töökiirus jne.)

• kvalitatiivseid kvaliteedi tunnuseid

näiteks (kasutajasõbralikkus, korrektsus jne.).

IT projekti lõpptulemuse kvaliteeti iseloomustavateks märksõnadeks võivad olla:

• kasutajasõbralikus
• hooldamiskergus
• rikete esinemise sagedus
• funktsionaalsus
• efektiivsus
• kiirus
• ökonoomsus jne.

# Mida põhjustab kvaliteedijuhtimise puudumine?

Kvaliteedi hindamisel on üheks levinumaks meetodiks toote elutsükli jaotamine kaheks: tootmiseks ja kasutamiseks. Kõrgem kvaliteet tootmisel toob reeglina kaasa suurema maksumuse. Kasutamisel toob aga suurem kvaliteet kaasa madalamad kulud. Täpselt nii on see ka enamiku IT projektide korral. Et leida õiget kvaliteedinivood tuleb elutsükli kulud kokku liita ja lähtuda sellisest kvaliteedinivoost, mille puhul kogukulud on kõige väiksemad. Selliselt leitud kvaliteeditaset võib nimetada optimaalseks kvaliteediks.

Puudulik kvaliteedijuhtimine aga võib viia selleni, et me leiame küll läbi elutsükli kogukulude optimaalse kvaliteedi, kuid projekti oodatud maksumus kasvab oluliselt suuremaks. Kvaliteedi tagamiseks tuleb teha lisatöid, kas projekti käigus või süsteemi kasutamise ajal ning see kõik maksab. Lõppkokkuvõttes on puuduliku kvaliteedijuhtimise tagajärjeks rahulolematu tellija ning firma maine langus. Kõige sellega loomulikult kaasneb kasumlikkuse langus.

# A.5.7.2 Miks on kvaliteedijuhtimine üks osa IT projekti juhtimisest?

Kvaliteeti saab juhtida ainult sellisel juhul, kui on määratletud selged kvaliteedi kriteeriumid. Sel juhul on kvaliteet vastavus nendele kriteeriumitele. Keeruliste toodete või teenuste puhul, mille hulka kuulub ka IT, on vastavust kõikidele kvaliteediparameetritele väga raske kontrollida. Seetõttu on siin oluline, et arendusprotsess oleks jälgitav ja vastaks kindlatele kriteeriumitele.

Infotehnoloogiline projekti koosneb väga erinevatest komponentidest, mis kõik mõjutavad lõpptulemuse kvaliteeti ja peavad olema kvaliteedijuhtimise objektid. Nendeks võib olla nii kasutatav riist- ja tarkvara, arendusprotsess tervikuna kui ka projektidokumentatsioon, tegijate kvalifikatsioon ja töö teostamise metoodika.

Enamikes infotehnoloogilises projektis tuleb kvaliteetse tulemuse saavutamiseks tegeleda:

• Vigade otsingu ja dokumenteerimisega
• Lähtekoodi testimisega
• Tehnilise ülevaatusega
• Terviklikkuse testimisega
• Süsteemi testimisega

Eriti komplekssete tarkvarasüsteemide korral ka beeta-testimisega, kus testijateks on ettevõttevälised eksperdid, kliendid või avalikkus.

# Millised on standardite kasutamise põhjused?

Standardeid võib liigitada:

• ametlikud standardid (vastu võetud tunnustatud standardiorganisatsiooni poolt);
• tööstuslikud ehk de facto standardid (ei pruugi olla ametlikult kinnitatud, kuid on üldlevinud);
• tehnilised raamstandardid (standardite kogumikud, juhendid nende kasutamiseks);
• riiklikud soovitused (kajastavad tüüpiliselt riigi kui kliendi vaadet);
• firmasisesed standardid.

IT vahendite ja süsteemide standardiseerimine ettevõttes tagab süsteemi osade hea ühilduvuse ning töökindluse ja võimaldab kogu süsteemi efektiivsemalt (kiiremini ja väiksemate kuludega) hallata.

Sisestandardite rakendamise põhjused:

• kulutuste minimeerimine
• komponentide vahetatavus
• komponentide koostöökulu minimeerimine (jääb ära liideste tegemine)
• protseduuride lihtsustamine ja parendamine (saab teistelt ettevõtteilt kindlalt töötavaid protseduure üle kanda)
• kvaliteedihaldus.

# Millised on kvaliteedijuhtimise põhilised metoodikad?

Kvaliteeti saab juhtida mitmeti, alates lihtsate põhimõtete rakendamisest ja lõpetades keerukate kvaliteedisüsteemidega, mida toetab vastav tarkvara.

Tarkvara kvaliteedi hindamise rahvusvaheline standard ISO/IEC(9126) on loodud kahetasandilisena tuues ära põhilised kvaliteedi kriteeriumid ja kõikide kriteeriumite juures ka alamkriteeriumid alljärgneval:

• funktsionaalsus (vastavus ülesannetele – kas kõik funktsioonid on olemas; täpsus; koostöövõime teiste süsteemidega; vastavus normidele, näiteks seadused, turvalisus)
• töökindlus (valmidus – kui tihti on tõrkeid; veakindlus – kuidas reageerib väliskeskkonna vigadele; taastatavus – kui raske on tõrke puhul uuesti tööd alustada);
• efektiivsus (ajaefektiivsus, ressursiefektiivsus)
• kasutatavus (kontseptuaalne selgus; õpitavus; kasutusmugavus)
• hooldatavus (analüüsitavus – kui raske on leida muutmise kohta; muudetavus – kui raske on muuta; stabiilsus – kui tugevalt muudatused mõjutavad süsteemi; testitavus)
• ülekantavus (adapteeruvus – kas saab üle kanda; installeerimise mugavus – kui raske on ülekanne; vastavus normidele; asendatavus).

Kvaliteedijuhtimise hindamisel on võimalik kasutada ka tarkvaraprotsessi küpsuse mudelit Capability Maturity Model / CMM mis eristab tarkvara­protsessi küpsu­ses viit taset, olenevalt teatud võtmeprotsesside realiseerituse astmele:

• Tase 1: kaootiline ja ettearvamatu, kõrge riskiastmega (70%); protsessid on määratlemata ning tarkvaraarenduse edu sõltub üksikisikute jõupingutustest.
• Tase 2: projektide täitmise tase on konstantne, ilma oluliste kõikumisteta projektist projekti (15%); rakendatakse põhilisi projektijuhtimise võtteid jälgimaks kulutusi, ajagraafikut ja funktsionaalsust,
• Tase 3: projektide kulude, ajagraafiku ja kvaliteedi paranemine järgnevate projektide täitmisel (10%); tarkvaraarendus­protsess on dokumenteeritud, standardiseeritud ja integreeritud kogu organisatsiooni ühtsesse arendustegevusse protsessi.
• Tase 4: ühe või mitme parameetri osas oluline edasiminek järgnevate projektide korral (5%); nii tarkvaraarendusprotsessi kui toote kvaliteedi osas teostatakse detailseid mõõtmisi, mille alusel tagatakse nii ühe kui teise osas pidev taseme tõus;.
• Tase 5: praktiliselt kõikide parameetrite osas on saavutatud optimaalne tase (1%); protsessist saadakse pidevalt kvantitatiivset tagasisidet; testitakse ja rakendatakse innovatiivseid tehnoloogiaid.

IT valdkonna standardite kehtestajaks on maailma juhtiv standardeid loov organisatsioon IEEE, kus luuakse igal aastal ligemale 1000 standardit erinevatele tegevusvaldkondadele nagu elekter, biomeditsiin, nanotehnoloogia, telekommunikatsioon, infotehnoloogia jm.

# Kuidas hinnata IT projekti kvaliteeti?

IT või IS projekti kvaliteeti võib hinnata ka läbi kasutaja rahulolu. Me võime projekti tulemuse kliendile üle anda õigeaegselt ja täpselt sellises konfiguratsioonis nagu tellija soovis. Kui me aga lähteülesande koostamisel ei mõelnud kliendi tegelikule vajadusele, siis võime saavutada kliendi rahulolematuse ja me ei saa öelda, et meie töö oli süsteemi luues kvaliteetne.

Iga projektijuht ja eriti IT projektijuht seisab seetõttu pea alati küsimuse ees: kas teha seda, mida klient soovib või seda, mida klient vajab. Loomulikult on ainuõige vastus, et tuleb teha seda, mida klient vajab. Ainult nii on võimalik tagada kliendi rahulolu ja öelda, et me tegime kvaliteetset tööd. Probleem on siin sageli selles, et klient ei ole IT valdkonna spetsialist ja temal on ainult umbmäärane ettekujutus sellest, millised on IT võimalused ning kuidas võiks uus infosüsteem tema äritegemist toetada. Siin tulebki projektijuhil asuda projekti alguseetapil juhtivasse rolli ja väga põhjalikult välja selgitada kliendi vajadused. See on esimene, aga otsustav samm kvaliteetse tulemi poole.

Kui nüüd pakutud lahendus lähtub küll kliendi vajadusest, aga:

• on keeruline kasutada
• ei ole turvaline
• on täis selliseid vigu, mis takistavad normaalset tööd
• on raskesti õpitav jms

siis ei saa me mingil moel öelda seda, et projekti lõpptulemus on kvaliteetne. Kõik eelpoolnimetatu mõjutab kliendi rahulolu ja hinnangut kvaliteedile negatiivses suunas.

# A.5.7.3 Mille poolest erineb kvaliteedijuht projektijuhist?

Kvaliteedijuhi ülesanne on tegeleda kogu ettevõttega, samal ajal, kui projektijuht tegeleb projekti või projektidega.

Kui kvaliteedijuhi tegevus on suunatud eelkõige ettevõttesse sisse, siis projektijuhi tegevus võib olla suunatud nii ettevõttesse (ettevõtte sisene arendusprojekt) kui ettevõttest välja (kliendi tellimuse täitmine).

Kvaliteedijuht	Projektijuht
Juhib kvaliteedijuhtimissüsteemi rakendamist	Juhib projekti või projekte
Kontrollib koostatud kvaliteedijuhtimissüsteemi dokumentide ja nende muudatuste vastavust ettevõtte üldistele eesmärkidele	Kontrollib projekti dokumentatsiooni ja nende muudatuste vastavust projekti eesmärkidele
Kooskõlastab kvaliteedijuhtimissüsteemi dokumentatsiooni enne kinnitamisele esitamist	Kooskõlastab projekti plaanid enne projekti alustamist tellija ja oma ettevõtte juhtkonnaga.
Juhib ja toetab tööd kvaliteediplaanidega	Teeb tööd projekti plaaniga nii kavandamise kui projekti elluviimise etapis
Arendab kvaliteedi informatsioonisüsteemi	Kavandab projekti informatsiooni kogumise ja jaotamise süsteemi
Planeerib kvaliteedi siseauditeid ning toetab siseaudiitoreid auditite ettevalmistamisel ja läbiviimisel	Planeerib projekti sisest kontrolli ja viib selle läbi.
Töötab läbi, hindab ja valmistab ette juhtkonnapoolseks ülevaatuseks vajaliku informatsiooni	Analüüsib projekti läbiviimisega seotud andmeid ja valmistab ette kontrollpunktides tehtavaid otsuseid
Juhib kvaliteedijuhtimissüsteemi pideva parendamise protsessi	Juhib projektist kogutud info talletamist, et saadud kogemust kasutada tulevaste projektide paremaks juhtimiseks
Kavandab ja viib ellu kvaliteedijuhtimissüsteemi teadlikkuse tõstmist ettevõttes	Kavandab vajadusel projektis osalejate kvalifikatsiooni tõstmise meetmeid
Informeerib viivitamatult ettevõtte juhti asjaoludest, mis teevad võimatuks teenistuskohustuste täitmise	Informeerib viivitamatult ettevõtte juhti ja tellijat asjaoludest, mis võivad saada takistuseks projekti edukale lõpetamisele

# A.5.7.4 Staatiline ja dünaamiline testimine

Tarkvara testimine jaotatakse staatiliseks ja dünaamiliseks testimiseks.

Staatilise testimise põhiülesandeks on leida vigu juba programmi projekteerimise ja spetsifitseerimise faasides. Staatilise testimise käigus saab kontrollida ka süsteemi omadusi nagu näiteks hooldatavus, töökindlus, analüüsitavus.

Staatilise testimise teostamine võib oluliselt vähendada tarkvara arendamise kulusid ning tarkvara arendamisele kuluvat aega. Samas tuleb meeles pidada, et staatiline testimine ei asenda dünaamilist testimist ning ei garanteeri, et ainult staatilise testimise läbinud tarkvara töötab veatult. Staatilise analüüsi vahendid teavitavad tarkvara arendajaid vigadest nagu kasutamiskõlbmatu programmi kood, kirjeldamata muutujad jne.

Dünaamiline testimine jaotatakse:

• funktsionaalseks testimiseks
• struktuurseks testimiseks.

Funktsionaalse testimise tehnikad on tuntud ka kui nn Black Box (must kast) ja sisend / väljund testimise tehnikad. Seda seepärast, et antud testimise tehnikat kasutades ei huvita testijat tarkvara ise vaid sisend ja väljund. Testija ei pea teadma ega omama teadmisi programmi koodi ja struktuuri kohta, ta keskendub tarkvara funktsionaalsuse testimisele huvitudes küsimusest, mida tarkvara teeb, mitte kuidas tarkvara seda teeb.

Struktuursete testimise tehnikate puhul tulenevad sooritatavad testid tarkvara sisemisest struktuurist ja neid nimetatakse ka White Box (valge kast) tehnikateks, kuna nende kasutamisel peab omama teadmisi kuidas tarkvara on juurutatud ning kuidas ta töötab. Üldjuhul kasutavad neid tehnikaid tarkvara arendajad ise. Struktuurse testimise tehnikad on tüüpilised moodulite testimise tehnikad, mille käigus testitakse ainult tarkvara süsteemi osi.

# A.5.7 Kordamisküsimused