programŲ sistemŲ projektŲ ir kokybĖs valdymasvalund/konspektai/ps projektu valdymas.pdf ·...

Vilniaus universitetas

Matematikos ir informatikos fakultetas

Programų sistemų katedra

Valdas UNDZĖNAS

http://www.mif.vu.lt/~valund

PROGRAMŲ SISTEMŲ

PROJEKTŲ IR KOKYBĖS VALDYMAS

Mokymo medžiaga

VILNIUS – 2011

http://www.mif.vu.lt/~valund

Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra

V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011

2

TURINYS

1. PROJEKTŲ VALDYMO ĮVADAS .......................................................................................................................................... 6

1.1. Projekto sąvokos apibrėžimas .................................................................................................................... 6

1.1.1. Kas yra IT projektas? ................................................................................................................................................... 6

1.1.2. IT projektų vadovų bendrosios pareigos ............................................................................................................ 9

1.1.3. IT projektų svarstymo kalba .................................................................................................................................. 10

1.2. Projektų valdymo apibrėžimas ................................................................................................................ 11

1.3. Bendrieji projekto vadovo įgūdžiai ........................................................................................................ 11

1.4. Projekto valdymo procesai ........................................................................................................................ 13

1.5. Projekto gyvavimo ciklas ............................................................................................................................ 15

1.5.1. IT projektų gyvavimo ciklas ................................................................................................................................... 16

1.5.2. IT projekto etapai ir kontroliniai taškai ............................................................................................................ 18

1.6. Organizacijos struktūros įtaka projektams ......................................................................................... 18

1.6.1. Funkcinio tipo organizacija .................................................................................................................................... 18

1.6.2. Matricos tipo organizacija ....................................................................................................................................... 19

1.6.3. Projektinio tipo organizacija .................................................................................................................................. 20

2. PROJEKTO INICIJAVIMAS ................................................................................................................................................ 21

2.1. Prašymas pradėti projektą ......................................................................................................................... 21

2.1.1. Reikalavimų metmenys ............................................................................................................................................ 22

2.1.2. Tiekėjų pasiūlymai ..................................................................................................................................................... 23

2.1.3. Reikalavimų metmenų dokumento rengimas ................................................................................................ 24

2.2. Projektų atranka ............................................................................................................................................ 25

2.2.1. Atrankos būdai ............................................................................................................................................................ 25

2.2.2. Atrankos kriterijai ...................................................................................................................................................... 25

2.3. Projekto akcininkai ....................................................................................................................................... 28

2.3.1. Projekto sponsorius................................................................................................................................................... 28

2.3.2. Kiti projekto akcininkai ............................................................................................................................................ 28

2.3.3. Kas yra jūsų IT projekto akcininkai? .................................................................................................................. 30

2.4. Projekto nuostatai ......................................................................................................................................... 33

2.4.1. Reikalavimų metmenys ............................................................................................................................................ 33

2.4.2. Informacija apie projekto grupę ........................................................................................................................... 33

2.4.3. Uždaviniai ir tikslai .................................................................................................................................................... 34

2.4.4. Projekto pagrindimas ............................................................................................................................................... 34

2.4.5. Formalus projekto patvirtinimas ......................................................................................................................... 35

3. PROJEKTO APIMTIES PLANAVIMAS ............................................................................................................................. 37

3.1. Projekto apimties plano struktūra .......................................................................................................... 37

3.1.1. Projekto apimties aprašas ...................................................................................................................................... 38

3.1.2. Projekto apimties valdymo planas ...................................................................................................................... 40

3.1.3. Projekto suskaidytų darbų lentelė ...................................................................................................................... 41

3.2. IT projekto apimtį įtakojantys veiksniai ............................................................................................... 42

3.2.1. IT įmonės dydis ........................................................................................................................................................... 42

3.2.2. Projekto siekiamų rezultatų apibrėžimo tikslumas ..................................................................................... 42

3.2.3. Darbo su užsakovu aplinkybės ............................................................................................................................. 43

3.2.4. Sėkmės kriterijų apibrėžimo sunkumas ........................................................................................................... 43

3.2.5. Pašaliniai ar neišsiaiškinti elementai ................................................................................................................. 43



3

3.2.6. Santykiai su tiekėjais ................................................................................................................................................. 43

3.2.7. Projekto grupės narių pasitraukimas ................................................................................................................ 44

3.2.8. Projekto darbų dalinimas keliems IT padaliniams ....................................................................................... 44

3.2.9. Testuojami elementai reikalauja gero apibrėžimo ....................................................................................... 44

4. DARBŲ GRAFIKO PLANAVIMAS ..................................................................................................................................... 45

4.1. Darbų eilės tvarka ......................................................................................................................................... 45

4.1.1. Darbų priklausomybių tipai ................................................................................................................................... 45

4.1.2. Darbų priklausomybės pobūdis ........................................................................................................................... 46

4.1.3. Darbų išdėstymo diagrama .................................................................................................................................... 47

4.2. Darbų trukmės vertinimas ......................................................................................................................... 47

4.2.1. Trukmės apibrėžimas ............................................................................................................................................... 47

4.2.2. Trukmės vertinimo būdai ....................................................................................................................................... 48

4.3. Darbų grafiko sudarymas ........................................................................................................................... 49

4.3.1. Kritinio kelio metodas .............................................................................................................................................. 49

4.3.2. Projekto etapai............................................................................................................................................................. 51

4.3.3. Darbų grafiko kontroliniai taškai ......................................................................................................................... 52

4.4. Projekto terminai ir tikrovė ...................................................................................................................... 52

5. PROJEKTO KAINOS PLANAVIMAS ................................................................................................................................. 54

5.1. Išteklių planavimas ....................................................................................................................................... 54

5.1.1. Išteklių tipai .................................................................................................................................................................. 54

5.1.2. Išteklių poreikio nustatymas ................................................................................................................................. 55

5.2. Išteklių kainos vertinimas .......................................................................................................................... 56

5.2.1. Kainos vertinimo būdai ............................................................................................................................................ 56

5.2.2. Vertinimo rekomendacijos ..................................................................................................................................... 59

5.3. Projekto biudžeto sudarymas ................................................................................................................... 60

5.3.1. Projekto biudžetas ..................................................................................................................................................... 60

5.3.2. Biudžeto lėšos projekto etapams ......................................................................................................................... 61

5.3.3. Biudžeto naudojimo kontroliniai taškai ............................................................................................................ 62

5.3.4. Biudžeto sudarymo įrankis - projektų valdymo programinė įranga .................................................... 62

6. PROJEKTO GRUPĖS PLANAVIMAS................................................................................................................................. 63

6.1. Projekto grupės organizacinės struktūros planavimas .................................................................. 63

6.1.1. Projekto sąsajos .......................................................................................................................................................... 63

6.1.2. Projekto grupės narių pareigos ir atsakomybės ............................................................................................ 64

6.1.3. Projekto grupės organizacinės struktūros schema ...................................................................................... 64

6.1.4. Projekto grupės valdymo planas .......................................................................................................................... 64

6.2. Projekto grupės narių atranka ................................................................................................................. 65

6.2.1. Pretendentų į projekto grupę apklausa ............................................................................................................. 65

6.2.2. Tarimasis su organizacijos funkcinių padalinių vadovais ......................................................................... 65

6.2.3. Kiti projekto grupės sudarymo scenarijai ........................................................................................................ 66

7. KOKYBĖS PLANAVIMAS ................................................................................................................................................... 67

7.1. Kokybės užtikrinimo priemonės ir būdai ............................................................................................ 67

7.1.1. Kokybės-naudos analizė .......................................................................................................................................... 68

7.1.2. Lyginamoji analizė ..................................................................................................................................................... 68

7.1.3. Struktūrinė (blokinė) projekto schema ir diagramos ................................................................................. 68

7.1.4. Kokybės kaina .............................................................................................................................................................. 68



4

7.2. Kokybės valdymo planas ............................................................................................................................ 69

8. RIZIKOS PLANAVIMAS ...................................................................................................................................................... 71

8.1. Rizikos veiksnių įvardinimas .................................................................................................................... 71

8.2. Rizikos analizė ................................................................................................................................................ 72

8.3. Reakcija į riziką .............................................................................................................................................. 73

8.3.1. Prevencinės priemonės ............................................................................................................................................ 73

8.3.2. Veiksmai nenumatytais atvejais ........................................................................................................................... 74

9. KOMUNIKACIJŲ PLANAVIMAS ....................................................................................................................................... 75

9.1. Komunikacijų strategija .............................................................................................................................. 75

9.2. Komunikacija su projekto grupės nariais ............................................................................................ 76

9.3. Komunikacija su akcininkais ..................................................................................................................... 77

10. PIRKIMŲ PLANAVIMAS .................................................................................................................................................. 79

10.1. Kurti patiems ar pirkti? ............................................................................................................................ 79

10.2. Sandorių tipai ............................................................................................................................................... 80

10.2.1. Fiksuotos kainos sandoriai .................................................................................................................................. 80

10.2.2. Išlaidas padengiantieji sandoriai....................................................................................................................... 80

10.2.3. Laiko ir medžiagų apmokėjimo sandoriai ..................................................................................................... 80

10.3. Darbo užduotis tiekėjams ........................................................................................................................ 81

10.4. Prašymas tiekėjams teikti pasiūlymus ............................................................................................... 81

10.5. Tiekėjų atrankos kriterijai ....................................................................................................................... 82

11. PROJEKTO BENDROJO PLANO RENGIMAS ............................................................................................................... 83

11.1. Kas yra projekto planas? .......................................................................................................................... 83

11.2. Projekto plano sudėtis .............................................................................................................................. 83

11.2.1. Bendroji dalis ............................................................................................................................................................. 84

11.2.2. Suplanuoti dalykai ................................................................................................................................................... 84

11.2.3. Šablonai ir kontroliniai sąrašai .......................................................................................................................... 85

11.2.4. Šaltinių nuorodos ..................................................................................................................................................... 85

11.2.5. Priedai .......................................................................................................................................................................... 85

11.3. Plano sudarymas ......................................................................................................................................... 86

11.3.1. Plano rašymo organizavimas ir rašymas ....................................................................................................... 86

11.3.2. Plano keitimas ........................................................................................................................................................... 86

11.3.3. Plano peržiūra ........................................................................................................................................................... 87

11.3.4. Projekto planavimo etapo užbaigimas ............................................................................................................ 87

12. PROJEKTO VYKDYMAS ................................................................................................................................................... 89

12.1. Projekto grupės sudarymas .................................................................................................................... 89

12.1.1. Darnios projekto grupės sudarymas ir valdymas ...................................................................................... 89

12.1.2. Mokymai ...................................................................................................................................................................... 91

12.1.3. Skatinimas ir pripažinimas .................................................................................................................................. 91

12.2. Santykiai su kitais akcininkais ............................................................................................................... 92

12.3. Darbų vykdymas pagal planą ................................................................................................................. 94

12.3.1. Duomenų apie projekto eigą rinkimas ............................................................................................................ 94

12.3.2. Projekto eiga pagal kontrolinius taškus ......................................................................................................... 95

12.4. Informacijos apie projekto eigą platinimas ...................................................................................... 96

12.4.1. Projekto grupės susirinkimai .............................................................................................................................. 96



5

12.4.2. Ataskaitos apie projekto eigą .............................................................................................................................. 97

12.4.3. Projekto apžvalgos .................................................................................................................................................. 97

12.5. Sandorių su tiekėjais priežiūra .............................................................................................................. 98

12.5.1. Tiekėjų atliekamų darbų ataskaitos ................................................................................................................. 98

12.5.2. Nesutarimų su tiekėjais aiškinimasis .............................................................................................................. 99

12.5.3. Tiekimų vėlavimai ................................................................................................................................................... 99

12.5.4. Atsiskaitymai su tiekėjais ..................................................................................................................................... 99

12.5.5. Reikalų su tiekėjais tvarkymas ........................................................................................................................ 100

13. PROJEKTO KONTROLĖ ................................................................................................................................................. 101

13.1. Integruotoji keitimų kontrolė ............................................................................................................. 101

13.1.1. Projekto apimties keitimo kontrolė .............................................................................................................. 101

13.1.2. Darbų grafiko kontrolė ....................................................................................................................................... 102

13.1.3. Išlaidų kontrolė ...................................................................................................................................................... 103

13.1.4. Kitų projekto plano elementų keitimo kontrolė ...................................................................................... 103

13.2. Kokybės kontrolė ..................................................................................................................................... 104

13.2.1. Tikrinimas (testavimas) .................................................................................................................................... 104

13.2.2. Kiti kokybės kontrolės būdai ir priemonės ................................................................................................ 105

13.2.3. Veiksmai kokybės neatitikimo atvejais ....................................................................................................... 107

13.2.4. Dokumentų kokybė .............................................................................................................................................. 107

13.3. IT projektų kokybės kontrolė .............................................................................................................. 108

13.3.1. Standartai ................................................................................................................................................................. 108

13.3.2. Standartų organizacijos ...................................................................................................................................... 109

13.3.3. Projektų valdymo kokybės gerinimas .......................................................................................................... 109

13.4. Rizikos valdymo kontrolė ..................................................................................................................... 110

13.4.1. Reakcijos į rizikos veiksnius rezultatų valdymas .................................................................................... 110

13.4.2. Naujų rizikos veiksnių įvardijimas ................................................................................................................ 111

13.4.3. Problemų sprendimo valdymas ...................................................................................................................... 111

13.4.4. Projektas pavojuje ................................................................................................................................................ 112

13.5. Projekto eigos kontrolė ......................................................................................................................... 112

13.5.1. Darbų ataskaitos ................................................................................................................................................... 113

13.5.2. Akcininkų valdymas ............................................................................................................................................. 115

14. PROJEKTO UŽBAIGIMAS .............................................................................................................................................. 118

14.1. Projektų nutraukimo priežastys ........................................................................................................ 118

14.2. Sandorių užbaigimas .............................................................................................................................. 119

14.3. Administraciniai projekto baigiamieji darbai ............................................................................... 119

14.3.1. Projektų archyvo tvarkymas ............................................................................................................................ 119

14.3.2. Formalus projekto rezultatų priėmimas ..................................................................................................... 120

14.3.3. Visapusiška projekto peržiūra (gautos pamokos) .................................................................................. 120

14.3.4. Projekto rezultatų perdavimas naudotojams ........................................................................................... 121

14.3.5. Projekto grupės narių atleidimas ................................................................................................................... 121

15. LANKSTIEJI PROJEKTŲ VYKDYMO METODAI ....................................................................................................... 122

15.1. Grumtynės (Scrum) ................................................................................................................................ 123

15.2. Aukštasis programavimas (XP) .......................................................................................................... 123

SANTRUMPOS ........................................................................................................................................................................ 125

ŠALTINIAI ................................................................................................................................................................................ 127



6

1. PROJEKTŲ VALDYMO ĮVADAS

1.1. Projekto sąvokos apibrėžimas

Naujiems projektų vadovams ir grupių nariams dažnai kyla tokie klausimai: kas priima

sprendimus projektams pradėti, kaip tampama projekto dalyviu, kuo darbas projekte skiriasi nuo

einamosios darbinės veiklos. Dažnai organizacijose ginčijamasi, ar turimas kuklias lėšas reikėtų

skirti sumanytam projektui ar einamajai darbinei veiklai. Tiek projektas, tiek einamoji darbinė

veikla vykdomi pagal kažkokį planą arba yra kažkokių veiksmų seka. Taigi, kuo projektai yra

ypatingi?

Projektų savybės:

- projektai pradedami tuomet, kai norima įgyvendinti (patenkinti) specifinius verslo

tikslus (poreikius). Tai susiję su naujų produktų, paslaugų ar rezultatų kūrimu (gavimu), kurie

galės būti parduodami klientams arba naudojami savo organizacijoje;

- projektai visada būna ribotos trukmės, turi apibrėžtus pradžios ir pabaigos terminus.

Projektų trukmė gali būti nuo keleto savaičių iki keleto metų. Tai priklauso nuo kuriamo

produkto sudėtingumo. Tačiau projektai nėra einamųjų darbinių veiklų rinkiniai;

- projektai turi būti pradedami tik turint aiškius tikslus ir akcininkus (suinteresuotus

asmenis). Apibrėžti tikslai turi būti patvirtinti akcininkų. Projektas baigiamas, kai įgyvendinami

šie tikslai. Žinoma, projektas gali būti ir nutrauktas, jei paaiškėja, kad pasiekti apibrėžtų tikslų

neįmanoma.

Kalbant apie projektų valdymą kartais sutinkama programos sąvoka. Programa yra grupė

susijusių projektų, kurie yra vykdomi reikiamai derinant juos. Programos sąvoka dažniausiai

naudojama gynybos ar dideliuose vyriausybiniuose užsakymuose.

Panagrinėkime informacinių technologijų (IT) srities veiklas, kad pajustume, kada jos

traktuotinos kaip projektai ir kada kaip einamoji darbinė veikla, kokie yra IT projektų ypatumai.

1.1.1. Kas yra IT projektas?

Kokia tvarka turi būti vykdomi projektai ir kaip griežtai reikėtų laikytis nustatytos

tvarkos, priklauso nuo projekto sudėtingumo. Įvairaus dydžio ir sudėtingumo projektų vykdymo

tvarka yra apibrėžta projektų valdymo žinyne [PMBOK].

Panagrinėkime keletą įvairaus pobūdžio IT projektų.

Programų sistemos (PS) kūrimo projektas. PS kūrimo projektuose reikia ne tik griežtai

laikytis projektų valdymo metodikų, bet ir gerai suprasti PS kūrimo metodologiją. Šios mokymo

medžiagos akcentas yra PS kūrimo projektai. Todėl plačiau apie specifines PS projektų valdymo

veiklas rašoma vėliau.

Infrastruktūros kūrimo/gerinimo projektas. Infrastruktūra – tai ryšio kabeliai,

kompiuterių tinklas ir jo įranga. Kartais infrastruktūra apima ir telefonų tinklus.

Pvz., keliantis į naują pastatą, kuriame dar niekas neįrengta, IT infrastruktūros

suprojektavimas ir įrengimas traktuotinas kaip projektas. Sename pastate naujų ar papildomų



7

ryšio kabelių nutiesimas, kompiuterių tinklo rekonstrukcija ar įrangos atnaujinimas taip pat yra

projektas.

Patalpa, į kurią ateina dauguma ryšio linijų, paprastai vadinama duomenų centru

(datacenter), o jame esanti įranga - pagrindine duomenų įranga (MDF–Main Data Facility). Ryšio

kabeliai iš duomenų centro eina į kitose pastato vietose ar net kituose pastatuose esančias

sienines ar kitaip įrengtas spintas. Tokiose spintose montuojama kompiuterių tinklo skirstančioji

ir komutuojančioji įranga (switchgear, routers), kuri vadinama tarpine duomenų įranga (IDF–

Intermediate Data Facilities). Pastate gali būti kelios IDF, tačiau MDF būna tik viena.

Duomenų centro kūrimo/tobulinimo projektas. Duomenų centras yra ta vieta, kur

talpinami serveriai, didieji kompiuteriai (mainframes), atsarginėms duomenų kopijoms saugoti

didelės talpos atminties įrenginiai, telefoninė įranga (pvz., PBX–Post Branch Exchanges). Į kitas

pastato patalpas išeinančių FR–Frame Relay, ATM–Asynchronous Transfer Mode, ISDN–

Integrated Services Digital Network ar kitokio standarto kompiuterių tinklo ryšio linijų pradžia

yra duomenų centro (MDF) riba. Duomenų centras yra atskira zona, į kurią privalu žiūrėti kaip į

ypatingą vietą, kurioje atliekami svarbiausi jūsų organizacijos skaičiavimai ar duomenų

apdorojimas.

Duomenų centrai pasižymi tokiais elementais, kaip pakeltos grindys, po kuriomis

išvedžiojami kondicionuoto oro kanalai serveriams, elektros energijos paskirstymo skydas, oro

kondicionieriai, patekimo į duomenų centrą apsaugos sistema, nepertraukiamo maitinimo

šaltiniai (UPS–Uninterrupted Power Supply), dažnai ir elektros energijos generatoriai, jei

ilgesniam laikui dingtų elektra bendrajame tinkle.

Duomenų centro kūrimo projektu gali būti tokio centro rengimas naujame pastate, jau

veikiančio centro elektros energijos tiekimo ir oro kondicionavimo pasenusios įrangos keitimas,

papildomų lentynų ar stovų rengimas naujiems serveriams, kt. Pastebėkime, kad duomenų

centro kūrimo / tobulinimo projektų nereikėtų būtinai sieti tik su serveriais. Tai daugiau susiję su

serverių laikymo vietos įrengimu.

Serverio / sistemos rengimo projektas. Be įprastų failų serverių, skirtų naudotojų failams

saugoti, rengiami ir kitokie, kurie būtini tam tikroms sistemoms funkcionuoti. Pvz., jums gali

prireikti įrengti didelę duomenų bazę arba įdiegti nupirktą gatavą programinę įrangą (COTS–

Commercial Of The Shelf) jūsų organizacijoje. Taip pat gali tekti diegti jūsų organizacijos

informatikų sukurtą sistemą, turinčią sąsajų su duomenų bazėmis arba kitomis jau

egzistuojančiomis sistemomis. Toks keleto skirtingų sistemų diegimas vadinamas sistemų

integracija ir reikalauja ypač gerų projekto vadovo žinių, kad visos dalys drauge veiktų gerai.

Apskritai, daugumai sistemų būtini serveriai, juose veikianti tinklo operacinė sistema

(NOS–Network Operating System), įvairios taikomosios programos, jungtys su tinklu, testavimo

priemonės. Sistema gali apimti kelias teritorijas, kas yra žymiai sudėtingiau ir kelia didesnius

reikalavimus jos kūrimo projektui.

Saugyklų rengimo projektas. Duomenų saugyklų (SAN–Storage Area Network) įrengimas

yra unikalus IT projektas. Tai specializuota įranga, ir ji gali apimti optinius kabelius, optinių

kanalų jungiklius, didelės talpos atminties įrenginių masyvus, kompiuterių tinklo

komutuojančiąją įrangą, kt. Vidutinio dydžio saugyklos įrengimas yra sudėtingas projektas,



8

kuriam gali prireikti projekto grupės keleto mėnesių darbo. Didelės saugyklos įrengimui gali tekti

ieškoti pagalbos, sudarant sandorį su atitinkama firma.

Įmonės išteklių planavimo programinės įrangos kūrimo projektas. Dideliais ir sudėtingais

IT projektais yra laikomi įmonės išteklių planavimo programinės įrangos (ERP – Enterprise

Resource Planning), kaip, pvz., SAP, Siebel, PeopleSoft, Oracle, kt., diegimo projektai. ERP

programinė įranga yra suprojektuota daugiausia įmonės darbuotojų atlyginimams, gamybos

procesams apskaityti. Ji yra sudėtinga ir mažai kam suprantama, todėl jai įdiegti dažniausia

samdomi patyrę specialistai.

ERP įrangai funkcionuoti paprastai reikia galingų serverių, sujungtų su didelėmis įmonės

duomenų bazėmis, kaip, pvz., Oracle, Microsoft SQL Server, kt. Kadangi ERP įranga gali atlikti

daug įvairių funkcijų, įskaitant portalų realizavimą, vienas žmogus negali žinoti visų jos diegimo

niuansų. Įvairioms verslo apskaitos funkcijoms realizuoti tenka kviestis keletą skirtingas veiklos

sritis išmanančių ekspertų (žinovų), kas veda prie sudėtingų projekto valdymo metodų (matrix

management) naudojimo.

Automatizuotos sistemos projektas. Kai kuriose sistemose rankinius procesus galima

automatizuoti. Imkime kad ir automobilių surinkimą. Pradžioje jie buvo surenkami rankiniu

būdu, o šiandien daug operacijų atlieka robotai.

Taip yra ir kitose pramonės srityse. Pvz., gėrimų gamybos srityje sistema automatizuotai

matuoja produkto tūrį ir pilsto į tarą, taip išlaisvindama daug darbuotojų. IT projektai, kuriais

numatoma automatizuoti rankines operacijas, reikalauja gero atitinkamos veiklos srities funkcijų

išmanymo. Tam gali reikėti nemažai mokymų.

IT projektų ypatumai

IT projekto sėkmė priklauso nuo grupės narių patirties, komunikavimo, atliekamų

procesų. Visuose IT projektuose tenka komplektuoti reikiamus aparatinės ir programinės įrangos

komponentus, išnaudoti žmonių patirtį kiekvienoje srityje ir rūpintis, kad visa įranga veiktų.

Pamąstykime, pvz., apie statybininko, vadovaujančio namo statymo projektui, atsakomybę. Jis

nebūtinai turi žinoti, kaip veikia šimtai įvairių santechnikos įrenginių (kriauklės, vonios, unitazai,

kt.), bet jis turi suprasti, kaip jie jungiami prie pagrindinių vandentiekio/nuotekų vamzdžių. Taip

pat yra ir su IT projektais. Jums nebūtinos nuodugnios žinios apie kiekvieną sistemos

komponentą, bet jūs turite suprasti, kaip jie sąveikauja tarpusavyje.

IT projektų esmei suprasti būtina žinoti procesus, vykstančius magistralėje tarp taško A ir

taško B. Pvz., kas darosi, kai interneto naudotojas atlieka veiksmus savo kompiuteryje,

norėdamas prisijungti prie kažkokios duomenų bazės? Duomenys keliauja per serverius, per

duomenų saugumą užtikrinančias priemones, kabelius, maršrutą nustatančius (routing) ir

junginėjančius (switching) komponentus. Visus šiuos elementus, ar jie susiję su jūsų projektu, ar

ne, būtina žinoti.

Taip pat labai svarbu, kad IT projektą vykdančios grupės nariai tarpusavyje palaikytų

glaudų ryšį. Neturėtų būti galimybės patirties neturinčiam programuotojui nukreipti sistemos

kūrimą neteisinga linkme. Asmens dalykinių savybių patikrinimas (pilot test) padeda išvengti bet

kokių programavimo netikėtumų.



9

1.1.2. IT projektų vadovų bendrosios pareigos

IT projektų vadovų darbas nėra lengvas. Jie turi turėti įvairių sričių žinias, kad gerai

suprastų projektų esmę, sugebėtų atlikti darbus laiku ir neviršydami biudžeto. Žemiau

pateikiama keletas įvairių pareigų, kurias tenka atlikti projektų vadovams.

Projektų vadovas. Kaip projekto vadovas jūs visų pirma esate atsakingas už projekto

grupės sudarymą, užduočių grupės nariams suformulavimą ir paskirstymą, vadovavimą taip, kad

projektas būtų įvykdytas laiku, kokybiškai ir nebūtų viršytas biudžetas.

Verslo analitikas. Nors projekto užsakovas paprastai paskiria savo ekspertus, kurie

padeda sukonkretinti projekto reikalavimus, jūs pats turite turėti šiokį tokį supratimą apie

užsakovo verslą, t. y. būti verslo analitikas. Taip pat jūs turite turėti žinių apie įvairius savo

organizacijos, kurioje dirbate, departamentus ir jų atliekamas funkcijas, galimybes (apribojimus

ir kliūtis) atlikti kažkuriuos darbus, jame dirbančių žmonių tipą, kaip jie yra valdomi, kokią įtaką

jie turi bendram organizacijos tikslui. Iš esmės jūs turite būti savotiškas visų savo organizacijos

departamentų (arba bent pagrindinių) veiklos ekspertas, pajėgiantis apibūdinti juos. To gali

prireikti formuojant projekto vykdytojų grupę.

Sistemų analitikas. Didesniuose projektuose sistemų analitiko funkcijas gali vykdyti ir

kitas asmuo. Nežiūrint to, jūs taip pat turite turėti gerą supratimą apie sistemų analizę ir kūrimo

būdus. Mažesniuose projektuose sistemų analitikas kartu būna ir verslo analitikas.

Derybininkas. Jums gali tekti derėtis ne tik su projekto užsakovu, bet ir su akcininkais,

pardavėjais ir kitokių įmonių vadovais, kurie gali būti projektui reikalingų elementų tiekėjai.

Biudžeto analitikas. Biudžeto analitiko vaidmuo jums tenka todėl, nes reikia sekti projekto

biudžeto eigą. Paprastai jūs gaunate tam tikro dydžio pinigų kapšą projekto tikslams pasiekti ir

būna sunku pasiaiškinti, jei viršijamas biudžetas.

Teisinių klausimų analitikas. IT projektų vadovas taip pat turi žinoti su projektu susijusius

teisės, etikos ir priežiūros klausimus. Pvz., JAV visa tai tapo ypač svarbu, kai buvo priimtas

Sarbanes-Oxley aktas [SOX], įpareigojantis organizacijas laikytis garbingo verslo taisyklių.

Technologas. IT projekto vadovui nebūtinos gilios technologinės žinios, tačiau jis turi

turėti bent minimumą žinių apie IT naudojimą. Jam nebūtina gerai išmanyti kompiuterių tinklus,

pvz., žinoti, kuo skiriasi tiltas (bridge, switch) nuo maršrutizatoriaus (router). Tinklo specialisto

nupieštų schemų jam turėtų visiškai pakakti. Svarbu, kad pokalbių metu jis suprastų minimus

projekto IT elementus. Projekto vadovui neįmanoma būti visų IT dalykų ekspertu. Tačiau, jeigu

bendraujant su kitais sutinkami nežinomi terminai ar sąvokos, būtina išsiaiškinti jų esmę.

Strategas. Ši funkcija glaudžiai susijusi su technologo funkcija. Jūs galite būti susipažinęs

su paskutinėmis IT tendencijomis. Pvz., jūs galite nerekomenduoti senesnio tipo kliento / serverio

sistemos, kai yra paplitusios naršyklėmis pagrįstos technologijos. Tačiau jūsų nauja sistema gali

turėti daugiau naudos iš įprastas komunikavimo priemones turinčių klientų. Taip elgdamiesi,

žinoma, jūs nenorite, kad projektas patektų į bėdą, panaudojus nepagrįstas naujas technologijas.

Ryšių palaikymo atstovas. Preciziškas ir rūpestingas ryšių palaikymas su suinteresuotais

asmenimis yra svarbiausias projekto vadovo darbas. Jūs turite vienų asmenų žinias perduoti

kitiems, rūpintis, kad žmonės laiku būtų informuoti apie projekto stovį. Jums turi rūpėti, kad

svarbūs asmenys, kurie gali tapti sukurto produkto pirkėjais, būtų informuoti apie projektą. Jums



10

teks turėti reikalų su pardavėjais ir subrangovais. Jūs turėsite vesti projekto grupės susirinkimus.

Todėl jūs turite būti geras oratorius, turėti gerus komunikavimo raštu įgūdžius, o taip pat mokėti

išklausyti kitus.

Laiko darbams atlikti vertintojas. IT projekto vadovas turi stebėti visas projekto veiklas ir

pamatęs, kad kažką padaryti vėluojama, išsiaiškinti priežastis.

Grupės sudarytojas. IT projekto vadovas turi mokėti suvaldyti labai įvairių sugebėjimų

žmones projekto tikslams pasiekti. Projekto grupėje bus programuotojai, tinklo specialistai,

serverių administratoriai, saugumo analitikai, internetinių (web) puslapių kūrėjai ir daugelio

kitokių technologijų specialistų. Kad jie tarpusavyje palaikytų tinkamus ryšius ir veiktų kaip

darni grupė, yra nelengvas uždavinys.

Kaip matome, IT projektų vadovų pareigų ratas yra labai platus. Dalis iš jų yra labai

svarbios, bet nepopuliarios. IT projektų vadovai turi žinoti „20-60-20“ taisyklę. Dvidešimčiai

procentų žmonių jūs neįtiksite ką bedarytumėte. Šešiasdešimt procentų žmonių bus neutralūs ir

neprieštaraus jums. Likę 20 procentų bus geros nuomonės apie jus ir pasiryžę drauge nuversti

kalnus. IT projekto vadovui tenka išgirsti labai įvairių nuomonių, barnių, argumentų,

persekiojimų, kt. Kai kuriais jūsų sprendimais ar veiksmais mažiausiai viena ar kita darbuotojų

grupė bus nepatenkinta. Jūs negalite būti populiarus besirungiančiame pasaulyje. Jūs turite veikti

pagal aplinkybes, kad pasiektumėte įmanomai geresnių projekto rezultatų iki numatyto termino

ir neviršydami biudžeto.

Projekto vadovui, dirbančiam su programinės įrangos kūrėjais, labai pravartu žinoti

programinės įrangos kūrimo ciklą (SDLC – Software Development Life Cycle). Taip pat būtina

išmanyti sistemų analizę ir projektavimą, duomenų vaizdavimo diagramas (DFD – Data Flow

Diagrams), objektų sąryšio diagramas (ERD – Entity Relationship Diagrams) ir kitus dalykus,

kurie padeda greičiau įdiegti sukurtas sistemas ir geriau patenkinti naudotojų poreikius.

Verslo poreikių analizės ir reikalavimų rengimo etape reikėtų vengti technologinių dalykų.

Pagrindinis dėmesys turi būti skiriamas verslo procesams.

Nagrinėdami verslo procesus jūs galite įžvelgti šių procesų keitimo galimybes, kas padėtų

palengvinti patį verslą arba leistų jame diegti paprastesnes technologijas. Tai vadinama verslo

procesų reinžinerija (BPR – Business Process Re-engineering), ko sistemų analitikas pirmiausia

turėtų imtis prieš siūlydamas technologinius sprendimus.

1.1.3. IT projektų svarstymo kalba

IT projektų vadovams tenka turėti reikalų su labai įvairiais žmonėmis. Kalbantis, pvz., su organizacijų vadovais tenka taikytis prie jų IT žinių lygio, o kalbantis su programinės įrangos kūrėjais jau tenka pasitikėti savo technologinėmis žiniomis. Pokalbiuose su vadovybe jūs tikriausiai nenaudojate specifinės techninės kalbos arba IT santrumpų. Kalbantis su programinės įrangos kūrėjais, jiems mažiau įdomūs gali būti projekto biudžeto tvarkymo klausimai. Taigi,

visada reikia turėti galvoje, su kuo turite reikalą. IT projekto vadovas turi būti lankstus ir mokėti tiksliai perteikti savo mintis. Su pašnekovais stenkimės kalbėti kiek įmanoma jiems aiškesne kalba. Venkime santrumpų, kol nesame įsitikinę, kad pašnekovai jas gerai supranta.



11

1.2. Projektų valdymo apibrėžimas

Šioje mokymo medžiagoje naudojami projektų valdymo ir su juo susijusių sąvokų

apibrėžimai yra paimti iš pasaulyje plačiai žinomo Projektų valdymo instituto (PMI – Project

Management Institute) parengtų standartų. Vadovaujant PMI yra parengtas Projektų valdymo

žinynas [PMBOK].

Projektų valdymo žinyne [PMBOK] projektų valdymo sąvoka apibrėžiama taip: tai žinių,

įgūdžių, instrumentų ir metodų naudojimas projekto reikalavimams įgyvendinti.

Projekto vadovas yra asmuo, kuris, naudodamas įvairius instrumentus ir metodus, stebi ir

koordinuoja visus projektui įvykdyti reikalingus darbus. Projekto valdymas apima išteklių

komplektavimą, biudžeto sudarymą, rizikos vertinimą, projekto reikalavimų tvarkymą,

komunikavimą su akcininkais, darbų grafiko laikymąsi ir produkto kokybės užtikrinimą. Visa tai

turi būti atliekama laiku. Projektų valdymo žinyne [PMBOK] žinios minėtoms veikloms valdyti

yra paskirstytos į devynias sritis. Vėliau matysime, kaip šios devynios žinių sritys yra susijusios

su penkiomis projekto valdymo procesų grupėmis.

Projekto valdymo procesų grupės turi būti pagrįstos atitinkamų sričių žiniomis.

Išvardinkime projektų valdymo žinių sritis:

1) apimties valdymas; 2) laiko valdymas;

3) kainos valdymas; 4) kokybės valdymas; 5) žmoniškųjų išteklių valdymas; 6) komunikacijų valdymas; 7) rizikos valdymas; 8) pirkimų valdymas; 9) bendrojo plano rengimo (integracijos) valdymas.

Vėliau šiuos dalykus nagrinėsime smulkiau. Priklausomai nuo IT projekto pobūdžio,

valdymo žinių sritys gali būti nevienodai svarbios. Pvz., jeigu jūsų projekte nebus sudaromi

sandoriai su išoriniais tiekėjais, tai pirkimų valdymo srities žinios nebus naudojamos.

1.3. Bendrieji projekto vadovo įgūdžiai

Projekto vadovas turi turėti įvairių gebėjimų. Svarbiausi iš jų yra: - mokėjimas vadovauti; - gebėjimas komunikuoti balsu; - gebėjimas komunikuoti raštu; - mokėjimas išklausyti kitų; - organizaciniai gebėjimai; - gebėjimas skirti laiką; - planavimo gebėjimai; - gebėjimas spręsti problemas; - gebėjimas susitarti (prieiti konsensuso); - gebėjimas spręsti konfliktus; - mokėjimas derėtis; - gebėjimas suburti projekto grupę.



12

Projekto vadovas turi matyti bendrą projekto vaizdą ir mokėti palaikyti ryšį su įvairiais

akcininkais. Projekto sėkmę lemia ne vien techniniai, bet ir vadybiniai projekto vadovo įgūdžiai.

Aptarkime keletą pagrindinių projekto vadovo įgūdžių ir kokią įtaką jie turi jo darbui.

Mokėjimas vadovauti. Projekto vadovas turi turėti gerus vadovavimo įgūdžius. Žmonės

kviečiami į projekto grupę tik projekto vykdymo laikotarpiui, kuris gali trukti tik keletą mėnesių.

Grupės nariai gali turėti labai įvairius gebėjimus ir patirtį. IT projektų grupėse šalia techninių

specialybių atstovų paprastai būna ir rinkodaros, prekybos, klientų aptarnavimo ar mokymo

specialistų. Grupės nariai gali būti nedirbę drauge anksčiau. Dar sudėtingiau būna, kai nariai

įsijungia į projektą ar palieka jį įvairiais laiko momentais.

Projekto vadovas yra atsakingas už projekto strategijos ir bendros plėtros krypties

perteikimą grupės nariams. Geras projektų vadovas žino, kaip reikėtų skirtingo išsilavinimo ir

patirties žmones organizuoti bendram tikslui pasiekti.

Gebėjimas komunikuoti (palaikyti ryšį). Patyrę projektų vadovai sako, kad daug laiko jie

sugaišta ryšiams su įvairiais asmenimis palaikyti. Laikytis netgi labai detalaus projekto darbų

grafiko bus sunku, jei nebus tinkamai komunikuojama.

Projekto vadovas turi parengti komunikacijų su suinteresuotais asmenimis strategiją,

kurios pagrindiniai elementai yra šie:

- kokius klausimus norima aptarti;

- su kuo norima komunikuoti;

- komunikavimo būdas;

- komunikavimo rezultatų valdymas.

Turint šiuos elementus galvoje ir iš anksto parengtą išsamų komunikavimo planą, galima

išvengti daug nesusipratimų projekto eigoje.

Gebėjimas spręsti problemas. Projektų eigoje visada iškyla problemų ir joms išspręsti

projektų vadovai griebiasi įvairių būdų.

Kuo anksčiau suvokiama, kad problemos iš tikro egzistuoja, tuo lengviau būna ateityje.

Rimtai žiūrėkime ne tik į formalias projekto grupės darbo ataskaitas, bet ir į tai, ką grupės nariai

šneka ir daro.

Jeigu jūs norite rimtai išsiaiškinti galimas problemas, skirkite tam pakankamai laiko.

Paviršutiniškas problemos išsiaiškinimas gali atvesti prie klaidingų sprendimų.

Kai problema būna aiškiai ir trumpai įvardinta, projekto vadovas drauge su projekto

grupe turi ieškoti jos sprendimo būdų ir vadovauti priimto sprendimo įgyvendinimui.

Mokėjimas derėtis. Projekto eigoje vadovui dažnai tenka dalyvauti įvairiose derybose,

kurių metu priimami asmenims arba grupėms abipusiai priimtini susitarimai. Priklausomai nuo

įmonės organizacinės struktūros, jūs galite pradėti projektą derybomis su įmonės funkciniais

padaliniais dėl išteklių projektui skyrimo. Projekto grupės nariai gali pageidauti specifinių darbo

sąlygų. Projekto akcininkai gali sumanyti keisti projekto tikslus, kas savo ruožtu pareikalauja

derybų dėl darbų grafiko, biudžeto arba dėl vieno ir kito. Projekto eigoje sumanius keisti

reikalavimus, derybos būna gana sudėtingos, nes akcininkų siūlymai dažnai būna prieštaringi.



13

Jeigu jūsų projektui yra reikalingi išoriniai tiekėjai, jums teks dalyvauti derybose rengiant sandorius. Tai speciali sritis, į kurios darbus įtraukiami organizacijos teisės ir pirkimų padalinių specialistai. Organizaciniai gebėjimai ir gebėjimas skirti laiką. Projekto vadovas prižiūri visus projektui įvykdyti reikalingus darbus. Tipiškos jo pareigos yra prižiūrėti kaip laikomasi darbų grafiko ir biudžeto, reguliariai šaukti projekto grupės susirinkimus, kontroliuoti tiekėjus, palaikyti ryšį su akcininkais, susitikinėti individualiai su grupės nariais, rengti formalias ataskaitas, tvarkyti prašymus pakeitimams daryti. Susirinkimams sugaištama daug laiko. Jų efektyvumas priklauso nuo pasirengimo jiems, gero planavimo. Ar tai būtų formalus grupės susirinkimas, ar individualus pokalbis, projekto

vadovas privalo apibrėžti susirinkimo tikslą ir numatyti svarstomų klausimų darbotvarkę. Labai svarbu apibrėžti kiekvieno klausimo nagrinėjimo trukmę, kad visas susirinkimas baigtųsi numatytu laiku. Projekto sėkmei nemažą įtaką turi dokumentų tvarkymas, kurie turi būti prieinami vos tik

prireikus jų. Projekto vadovas gaiš pernelyg daug laiko stebėjimui, kaip laikomasi darbų grafiko, jei neturės efektyvios dokumentų tvarkymo sistemos. Geras būdas organizaciniams ir laiko skyrimo gebėjimams įgyti yra darbas patyrusio projektų vadovo priežiūroje kažkurį laiką.

1.4. Projekto valdymo procesai

Žinyne [PMBOK] projektų valdymas apibrėžiamas kaip žinių, įgūdžių, instrumentų ir metodų naudojimas projekto reikalavimams įgyvendinti. Visi projekto valdymo procesai (veiklos) dalinami į penkias grupes. Valdymo procesų grupės yra glaudžiai susijusios, nes vienos rezultatai kitoje naudojami kaip įeities duomenys. Ryšiai tarp jų trumpai pavaizduoti 1.1 lentelėje , o plačiau - 1.1 pav. Valdymo procesų grupės persidengia, skiriasi kainos ir išteklių poreikio lygiu (žiūr. 1.2 pav.).

1.1 lentelė. Projekto valdymo procesų grupės

Duomenys gaunami iš procesų grupės

Procesų grupės pavadinimas

Rezultatai perduodami procesų grupei

Iniciatorius Inicijavimas (Initiating) Planavimas

Inicijavimas

Kontrolė Planavimas (Planning) Vykdymas

Planavimas

Kontrolė Vykdymas (Executing) Kontrolė

Vykdymas Kontrolė (Controlling)

Planavimas

Vykdymas

Užbaigimas

Kontrolė Užbaigimas (Closing) Naudotojai

Valdymo procesų grupės yra projektų valdymo pagrindas. Vadovams būtina žinoti jas ir

suprasti jų įtaką projektui.



14

Inicijavimo procesai. Tai veiklos, kuriomis siekiama parodyti, kad reikia pradėti projektą.

Pagrindinės iš jų yra verslo poreikių įvardinimas, reikalavimų metmenų (high-level

requirements) parengimas, kainos numatymas. Plačiau apie tai rašoma šios mokymo medžiagos

2 skyriuje „Projekto inicijavimas“.

Planavimo procesai. Planavimo metu projekto tikslai yra tikslinami ir skaidomi į dalis, kad

jiems įgyvendinti reikalingi darbai būtų lengviau valdomi. Projektų vadovai įvertina projekto

trukmę, kainą, kiekvienam darbui reikalingus išteklius.

Inicijavimas

Projekto iniciatorius /

sponsorius

Įmonės duomenys (įmonės struktūra, žmoniškieji

ištekliai, projektų valdymo informacinė sistema, kt.)

Įmonės organizaciniai dokumentai

(taisyklės, procedūros, kt.) Projekto nuostatai,

preliminari projekto apimtis

Planavimas

Projekto valdymo planas

Vykdymas

Rezultatai, prašymai daryti pakeitimus, pataisymus, šalinti defektus, informacija apie

darbų eigą

Kontrolė

Prašymų daryti pakeitimus,

pataisymus, šalinti defektus

priėmimas ar atmetimas, projekto

valdymo plano, apimties naujinimas,

korekcinių ir prevencinių veiksmų

rekomendacijos, darbų ataskaitos,

prognozės, patvirtinti rezultatai

Užbaigimas Administracinės projekto

užbaigimo procedūros

sandorių užbaigimas

Naudotojai

Galutinis produktas

1.1 pav. Projekto valdymo procesų grupių sąveika



15

Projektų valdyme svarbios yra ir kitos veiklos, kurias taip pat būtina suplanuoti iš anksto.

Tai kokybės, rizikos, komunikacijų, pirkimų valdymas.

Planavimo klausimai aiškinami šios mokymo medžiagos 3-11 skyriuose. Vykdymo procesai. Tai projekte numatyto produkto kūrimo darbai. Projekto vadovas turi

koordinuoti visų projekto grupės narių darbą ir kitų projektui skirtų išteklių naudojimą.

Vykdymo procesų metu vadovaujamasi projekto planu, suformuojama darbo grupė,

tikrinama atliktų darbų kokybė, akcininkams platinama informacija apie projekto eigą. Plačiau

žiūr. 12 skyriuje „Projekto vykdymas“.

1.2 pav. Procesų grupių persidengimas, kainos ir išteklių poreikio lygis

Kontrolės procesai. Kontrolės veiklų paskirtis yra stebėti projekto eigą, kad laiku būtų

pastebėti nukrypimai nuo projekto plano. Prašymų daryti projekto pakeitimus analizavimas ir

atitinkamų sprendimų priėmimas yra šios procesų grupės veiklos.

Kontrolės veiklų grupei taip pat priskiriama projekto išlaidų kontrolė, kokybės kontrolė,

ataskaitų rengimas ir rizikos valdymo kontrolė. Plačiau – 13 skyriuje „Projekto kontrolė“.

Užbaigimo procesai. Tai projekte sukurtos sistemos formalaus priėmimo (užsakovas

priima iš projekto vykdytojo) ir perdavimo einamajam darbiniam naudojimui veiklos.

Užbaigimo veikloms priskiriamas įvairių pareigūnų parašų rinkimas, projekto dokumentų

perdavimas į archyvą, sukurtos sistemos perdavimas priežiūros grupei, projekto grupės narių

atleidimas, gautų pamokų peržiūra. Kai kurios iš jų gali atrodyti labai paprastos, tačiau kitos

nusipelno rimto dėmesio. Apie projektų užbaigimą plačiau rašoma 14 skyriuje „Projekto

užbaigimas“.

1.5. Projekto gyvavimo ciklas

Kiekvienas projektas turi pradinę, viduriniąsias ir baigiamąją fazes. Projekto gyvavimo

ciklas – tai laike išdėstytų fazių rinkinys. Idealiu atveju vienos fazės rezultatai turėtų būti gauti ir

patvirtinti anksčiau nei pradedama kita fazė. Realiame gyvenime įvairios projektų gyvavimo ciklo

Kontrolė

Projekto pradžia Projekto pabaiga

Proceso lygis



16

fazės dažnai būna persidengiančios, t. y. vienai fazei dar nepasibaigus pradedama kita fazė.

Paprastai taip daroma norint sutrumpinti projekto darbų grafiko trukmę.

Skirtingų verslo sričių projektų gyvavimo ciklai gali skirtis. Gali skirtis netgi ciklų fazės.

Tačiau visada projekto gyvavimo ciklas turi atspindėti kiekvienos fazės rezultatus ir reikalingų

išteklių kategorijas. Ciklas turi atspindėti ir užbaigto projekto rezultatų naudojimą.

Panagrinėkime IT projektų gyvavimo ciklą.

1.5.1. IT projektų gyvavimo ciklas

Kiekvienas IT projektas turi gyvavimo ciklą, susidedantį iš kažkokio fazių kiekio.

Programų sistemų kūrimo ciklo (SDLC – Software Development Life Cycle) fazės – planavimas,

analizė, projektavimas, realizavimas, naudojimas ir priežiūra - yra glaudžiai susiję su 1.4 skyriuje

nagrinėtomis projektų valdymo procesų grupėmis. Todėl pravartu sistemų kūrimo ciklo (SDLC)

fazes prisiminti kiek plačiau.

Planavimo fazė. Ši fazė pradedama gavus prašymą sukurti naują sistemą iškilusioms

problemoms spręsti arba patobulinti jau egzistuojančią sistemą. Prašyme išdėstoma problema ir

verslo procesai, kuriems pagerinti reikėtų sukurti sistemą.

Prašymu sukurti sistemą potencialiai siekiama tokių dviejų tikslų: atlikti pirminius verslo

procesų tyrimus ir atlikti jų pagerinimo IT priemonėmis galimybių studiją (ar reikia rengti

studiją, priklauso nuo sistemos dydžio). Pirminiai verslo tyrimai iš esmės susiveda į sistemos

reikalavimų metmenų (high-level requirements) rengimą. Turint juos, gali būti inicijuota

galimybių studija, kad būtų išsiaiškinta prašymo kaina/nauda ir parengtos sistemos kūrimo

rekomendacijos trukmės, ekonominiais, techninių sąlygų ir kitokiais klausimais.

Sistemos planavimo metu gali būti siūloma keisti ir pačius verslo procesus, kad būtų

lengviau įgyvendinti siekiamus tikslus. Kartais automatizacija ir technologijos nepadeda, o

pakeitus verslo procesus norimus rezultatus galima pasiekti lengvai.

Analizės fazė. Šios fazės metu, nusipiešus verslo duomenų judėjimo schemą, rengiamas

loginis sistemos modelis, formuluojami jau detalūs sistemos reikalavimai.

Analizės metu siekiama išsiaiškinti sistemos detales. Apklausinėjant akcininkus, renkant ir

analizuojant faktus, kuriant idėjas, iš ko turėtų susidėti sistema ir ką ji turėtų daryti, kuriami

įvairūs įmonės modeliai su joje cirkuliuojančiais duomenimis. Sistemos prototipų rengimas yra

būdas supažindinti akcininkus su būsima naująja sistema.

Programų sistemų kūrimo ciklo (SDLC) Planavimo ir Analizės fazės atitinka projektų

valdymo Inicijavimo ir Planavimo procesų grupes.

Galutinis sistemos analizės rezultatas yra sistemos reikalavimų dokumentas. Jame

išdėstoma viskas, ką sakė verslo atstovai, ir ko jie nori iš naujos sistemos.

Projektavimo fazė. Šioje fazėje nurodomi visi elementai, įskaitant įvesties ir išvesties

duomenis, reikiamus procesus, kurie turi būti įtraukti į projektą. Taip pat projektavimo metu

nurodomi rankiniai ar automatiniai tikrinimo būdai, kurių reikės norint įsitikinti, ar sukurta

sistema veikia tinkamai. Jei projekte bus kuriama programinė įranga, turi būti parengta sistemos

projekto specifikacija (SDS – System Design Specification), t. y. dokumentas, kuriame



17

atsispindima kuriamos programinės įrangos architektūra. To reikia, kad grupės nariai galėtų

tiksliai kurti norimą sistemą.

Jeigu projekte nereikia kurti naujos programinės įrangos, bet reikia kurti ar tobulinti

duomenų bazę ar infrastruktūrą, labai svarbu, kad visi akcininkai, pradedant vadovais ir baigiant

galiniais naudotojais, suprastų, kas yra suprojektuota ir kaip tai veiks, ir kad techniniai

specialistai būtų pajėgūs sukurti norimą sistemą. Jei rengiamasi naudoti gatavą komercinę

programinę įrangą (COTS – Commercial Of The Shelf), būtina parengti jos integravimo į kuriamą

sistemą projektą.

Į sistemos projektą gali būti įtraukta infrastruktūros plėtra ar naujinimai, naujų ryšio

linijų tiesimas, naujo tipo įrenginių diegimas ir kiti dalykai. Tai gali pareikalauti ir ankstesnės

sistemos programinių elementų atnaujinimo.

Realizavimo fazė. Šios fazės metu sistema jau yra kuriama (gaminama). Bet kuriuo atveju,

ar tai būtų naujų programų rašymas, ar gatavų programų (COTS) pirkimas, ar abiejų minėtų

veiksmų kombinacija, siekiama sukurti visas numatytas funkcijas vykdančią ir gerai

dokumentuotą sistemą.

Sistemos realizavimo fazė apima tokius veiksmus, kaip senų duomenų konvertavimą į

naujo formato duomenis, testavimą, naudotojų mokymą, perėjimą prie naujos sistemos. Taip pat

rengiamas sistemos įvertinimas, kuriame atspindimi būdingi jos bruožai ir ar sistema atitinka

projekto specifikaciją (SDS).

Naudojimo ir priežiūros fazė. Ši programų sistemų kūrimo ciklo (SDLC) fazė tam tikra

prasme atitinka projektų valdymo Užbaigimo procesų grupę. Pastarosios metu sistema

perduodama einamajam darbiniam naudojimui ir pasirenkamas jos priežiūros būdas

sutrikimams šalinti. Tačiau Naudojimo ir priežiūros fazė prasideda pasibaigus projektų valdymo

Užbaigimo procesams. Be to jos metu kartais daromi sistemos keitimai, kuriais siekiama išplėsti

jos funkcijas ar atlikti kitokius patobulinimus.

Projekto koncepcija (reikalavimų metmenys)

Lyginant dvi metodologijas – Projektų valdymą ir jo procesų grupes su Programų sistemų

kūrimo ciklu (SDLC) – reikėtų neišleisti iš galvos vieno kiek kitokio tipo dokumento - projekto

koncepcijos. Projekto pradžioje sistemų analitikas, nagrinėdamas užsakovo prašymą pradėti

projektą, parengia projekto koncepciją, t. y. reikalavimų metmenis (high-level requirements). Šis

dokumentas yra impulsas pradėti projekto planavimą. Sistemų analitikas gali ir nebūti projekto

vadovas. Tam gali būti įvairios priežastys, pvz., analitikas yra kitos organizacijos atstovas arba

projektas yra labai sudėtingas. Bet kuriuo atveju kokybiškai atlikta sistemos analizė ir gerai

parengtas sistemos projektas (planas, angl. design) yra efektingos sistemos sukūrimo laidas.

Projekto koncepcija yra idealus atramos taškas pradėti projektą ir šalių derybas.

Pastebėkime, kad analitikas, tęsdamas savo darbą, iš projekto koncepcijos (reikalavimų

metmenų) rengia detalius reikalavimus, o projektų vadovas turi griežtai laikytis parengtų

reikalavimų.



18

1.5.2. IT projekto etapai ir kontroliniai taškai

Bet kurios programų sistemos kūrimo ciklas (SDLC) dalinamas į etapus (fazes), kas

palengvina projekto eigos stebėjimą. Pvz., el. komercijos projektų etapai yra sistemos sukūrimui

reikalingų priemonių pirkimas, instaliavimas, derinimas, serverių įrengimas. Etapą turėtų

sudaryti labai aiškią pabaigą turinčių užduočių rinkinys. Apie etapo įvykdymą projekto vadovas

turėtų duoti vienareikšmį atsakymą - taip arba ne, kad akcininkai galėtų susidaryti aiškų vaizdą

apie projekto eigą.

Projekto etapai savo ruožtu gali turėti keletą kontrolinių taškų (checkpoints). Juose

nurodomi suplanuoti terminai, iki kada turėtų būti atlikti kažkurie projekto darbai, ir

suplanuotos biudžeto išlaidos. Kontroliniai taškai padeda įvertinti projekto stovį duotais laiko

momentais.

1.6. Organizacijos struktūros įtaka projektams

Projektų valdymui didelę įtaką turi organizacijos struktūra. Nuo to priklauso projekto

vadovui suteikiami įgaliojimai ir projekto vykdymui reikalingų išteklių skyrimas.

Projektų vadovai susiduria su įvairiais rūpesčiais. Daugumos jų priežastis yra

organizacijos, kurioje vykdomas projektas, struktūra ir jos veikla. Todėl būtina suprasti, kaip jūsų

organizacijoje žiūrima į projektus, kad žinotume, kaip reikėtų elgtis sprendžiant įvairius

klausimus.

1.6.1. Funkcinio tipo organizacija

Funkcinio tipo organizacijos sutinkamos dažniausiai. 1.2 pav. parodyta jų struktūra.

Darbuotojai jose yra paskirstyti į funkcinius padalinius (departamentus), pvz., personalo, finansų,

teisės, tinklų priežiūros, IT, klientų aptarnavimo, kt. Kiekvienas padalinio darbuotojas žino, kas

yra jo viršininkas.

Funkcinio tipo organizacijose projektai atliekami kaip atskiri, padaliniams

nepriklausantys darbai. Jie netgi gali būti atskirai valdomi.

Funkcinio tipo organizacijų charakteringas bruožas yra tas, kad jose projektų vadovai turi

labai ribotus įgaliojimus, organizacijos ištekliai projektui naudojami tik dalį laiko, o sprendimus

projektų klausimais dažnai priima kurio nors padalinio vadovas.

Funkcinio tipo organizacijose projektų vadovų padėtis kartais būna kebli, nes atsakomybė

už visą projektą užkraunama jiems, bet jie negali versti projekto grupės narių būti atsakingų už

projekto rezultatus. Nuo funkcinio padalinio vadovo priklauso projekto grupės nario alga,

premijos, darbinė kategorija. Kai kuriose organizacijose projekto vadovui leidžiama teikti

pasiūlymus dėl darbo grupės narių paskatinimo ar kategorijos pakėlimo, o tokių pasiūlymų

svoris gali būti ir neproporcingas grupės nario dalyvavimo projekte laikui.



19

Projekto vadovas funkcinio tipo organizacijoje daugiausia laimi, jei sugeba palaikyti gerus

santykius su funkcinių padalinių vadovais. Projektui sėkmingai užbaigti dažnai tenka prašyti

papildomų išteklių ar aukštesnės kvalifikacijos specialistų. Taigi, panašių klausimų sprendimas

drauge su funkcinių padalinių vadovais yra labai svarbus.

1.6.2. Matricos tipo organizacija

Kitas organizacijų tipas – matricos – parodytas 1.3 pav. Matricos tipo organizacijos,

panašiai kaip ir funkcinio tipo organizacijos, yra padalintos į funkcinius padalinius

(departamentus), tačiau už projektui skirtus išteklius viso projekto metu yra atsakingas projekto

vadovas. Projektų vadovai dažnai sudaro atskirą organizacijos funkcinį padalinį. Projekto grupės

nariai turi du arba daugiau vadovų. Jie yra pavaldūs funkcinio padalinio vadovui ir projekto

vadovui.

Funkcinio

padalinio

vadovas

Funkcinio

padalinio

vadovas

Funkcinio

padalinio

vadovas

Funkcinio

padalinio

vadovas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

1.2 pav. Funkcinio tipo organizacija (paryškintas „Darbuotojas“ – projekto grupės narys)

Organizacijos vadovas

Funkcinio

padalinio

vadovas

Funkcinio

padalinio

vadovas

Funkcinio

padalinio

vadovas

Vyriausiasis

projektų

vadovas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Projekto vadovas

Projekto vadovas

Projekto vadovas

1.3 pav. Matricos tipo organizacija (paryškinti „Projekto vadovas“ ir „Darbuotojas“ – projekto grupė)




20

Matricos tipo organizacijų būdingi bruožai yra vidutinio lygio įgaliojimų suteikimas

projektų vadovams, leidimas jiems naudoti projekto išteklius dalį projekto laiko arba visą jo laiką,

geresnis komunikavimas tarp funkcinių padalinių. Savo ruožtu matricos tipo organizacijos

dalinamos į dvi rūšis: lengvąsias ir griežtąsias. Griežtojo matricos tipo organizacijose projektų

vadovams suteikiami didesni įgaliojimai.

Matricos tipo organizacijose projektų vadovai turi gerai išsiaiškinti su projekto grupės

nariais ir funkcinių padalinių vadovais, kuriems nariai pavaldūs, tokius dalykus: už ką projekto

grupės narys turi atsiskaityti projekto vadovui ir už ką - padalinio vadovui. Grupės narys tam

tikrais klausimais turi atsiskaityti tik vienam vadovui, kad būtų išvengta nesusipratimų. Kita

matricos tipo organizacijose rūpesčių kelianti problema yra ribotų išteklių paskirstymas. Jei

funkcinio padalinio žmogus paskiriamas 50% laiko dirbti viename projekte, tai gali turėti žymų

poveikį to funkcinio padalinio darbui arba kitiems projektams, kuriuose tas žmogus taip pat

dirba.

Išteklių paskirstymo klausimo išsprendimas projekto pradžioje padeda išvengti problemų

ateityje.

1.6.3. Projektinio tipo organizacija

Trečias organizacijų tipas – projektinis – parodytas 1.4 pav. Tai organizacijos, kurių

pagrindinis darbas yra projektų vykdymas.

Projektinio tipo organizacijų pagrindinis bruožas yra visų įgaliojimų suteikimas projektų

vadovams, leidimas jiems naudoti išteklius visą projekto laiką, projektui vykdyti reikalingos

darbo grupės sudarymas.

Projektinio tipo organizacijose projektų vadovai yra atsakingi už visus su projektu

susijusius klausimus. Grupės nariai išdėstomi taip, kad jiems būtų patogu komunikuoti ir

efektyviai dirbti.

Projektinio tipo organizacijų didelė problema, kaip elgtis su darbo grupės nariais

pasibaigus projektui. Ne visada jų laukia naujas projektas. Laiko numatymas žmoniškiesiems

ištekliams didinti ar mažinti yra sudėtingas uždavinys.

Projekto

vadovas Projekto

vadovas

Projekto

vadovas

Projekto

vadovas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

Darbuotojas

1.4 pav. Projektinio tipo organizacija (paryškinti „Projekto vadovas“ ir „Darbuotojas“ – projekto grupė)




21

2. PROJEKTO INICIJAVIMAS

Inicijavimo procesai priklauso pirmai iš penkių projektų valdymo žinyne [PMBOK]

įvardintų procesų grupių. Inicijavimas apima prašymo (užsakymo) priėmimą ir projekto aprašo

parengimą. Priklausomai nuo organizacijos, šis procesas gali būti formalus arba neformalus.

Inicijuojant projektą, užsakymą gavusi organizacija drauge su užsakovu peržiūri jo

pageidavimus, išsiaiškina tikslus ir kaip turi būti matuojamas tikslų pasiekimo lygis, apibrėžia

projekte numatomą sukurti produktą (įrangą, paslaugą ar kt.). Programų sistemų projektuose

produkto apibrėžimas vadinamas reikalavimų metmenimis (high-level requirements), nes geriau

atitinka tokios veiklos sritį.

Inicijuojamų projektų naudingumą būtina įvertinti. Tai ypač aktualu, kai siūloma keletas

projektų. Kuris iš projektų duos didžiausią naudą ir kurio reikėtų imtis visų pirma? Nutarimo

pradėti projektą priėmimui reikalingas projektų atrankos procesas ir kriterijai. Šiame mokymo

medžiagos skyriuje nagrinėjami pagrindiniai projektų atrankos metodai: išlaidų-naudos analizė,

matematiniai vertinimo modeliai, finansinė analizė, ekspertų nuomonės išklausymas.

Supažindinama su projektų rėmėjais: sponsoriumi, akcininkais ir kitais asmenimis, kurie yra

suinteresuoti ir turi įtakos projekto rezultatų pasiekimui.

Galutinis projekto inicijavimo rezultatas yra organizacijos vadovybės patvirtinti projekto

nuostatai (project chart), leidžiantys pradėti projektą, ir formalus projekto vadovo paskyrimas.

2.1. Prašymas pradėti projektą

Projektui pradėti būtinas prašymas (užsakymas). Jam rengti gali būti įvairios priežastys:

- rinkos poreikis naujai įrangai ar paslaugai;

- vidiniai organizacijos poreikiai;

- kitõs (išorinės) organizacijos užsakymas;

- naujos technologijos;

- teisės aktų reikalavimai;

- socialiniai poreikiai, pvz., šalies infrastruktūros plėtra.

Organizacijoje prašymai pradėti projektus gali būti gaunami ne tik iš jos vidinių padalinių,

bet ir iš kitų (išorinių) organizacijų. Organizacijoje gali būti IT veiklos analitikas, kuriam pavesta

rūpintis savo organizacijos padaliniais ir registruoti jų poreikius. Stambesnėse kompanijose gali

vykti keleto departamentų atstovų pasitarimai IT projektų perspektyvoms svarstyti. Vieno

departamento asmuo teikiantis prašymą kitam departamentui traktuojamas kaip klientas arba

užsakovas. Tačiau nemažai organizacijų klientu arba užsakovu laiko tik kitos organizacijos

asmenį. Todėl būtina žinoti, kaip jūsų organizacijoje ši sąvoka yra interpretuojama. Vidinis arba

išorinis užsakovas gali teikti projekto užsakymą tiesiai organizacijos vadovybei.

Nežiūrint to, kas sugalvoja ir teikia prašymą pradėti projektą, organizacijos vadovybė ar

jos įgalioti asmenys turi peržiūrėti prašymą ir priimti sprendimą. Kadangi pradinis prašymas gali

būti ne detalus, reikia surinkti tiek informacijos, kad galima būtų tiksliai įvertinti prašymą.

Vadovybės paskirtas projekto vadovas turėtų susitikti su prašytoju (užsakovu), kad išsiaiškintų



22

prašymo detales, tiksliau apibrėžtų numatomą kurti produktą, apsvarstytų funkcinius ir

techninius reikalavimus, parengtų projekto reikalavimų metmenis (high-level requirements).

2.1.1. Reikalavimų metmenys

Reikalavimų metmenys kitur dar yra vadinami projekto koncepcija, produkto apibrėžimu.

Jiems parengti būtina gerai suprasti problemą ar verslo (veiklos srities) poreikius, dėl kurių

prašoma pradėti projektą, ir, žinoma, savo paties funkcijas, kurių vykdymo žadate imtis.

Problemos apibrėžimas

Projektas gali nukrypti neteisingu keliu, jei projekto vadovas neskirs laiko užsakovo

problemoms ar poreikiams išsiaiškinti.

Užsakovo reikalavimai gali būti neaiškūs arba netiksliai suformuluoti. Projekto vadovo

pareiga yra išsiaiškinti, ko užsakovas iš tikrųjų nori. Tam reikia išnagrinėti užsakovo prašymą ir

išdėstyti jam, kaip jūs supratote jį. Taip gali būti parengta projekto koncepcija, kurioje jūs savais

žodžiais aprašote užsakovo reikalavimus.

Gali kilti keblumų, jei užsakovas reikalavimus išdėsto atsakymų (sprendimų) stiliumi. IT

pasaulyje tai nėra reta, ypač kai užsakovo norai yra specifiniai. Užsakovas gali būti nurodęs būdą,

kaip turėtų būti įgyvendinami jo reikalavimai. Tačiau jūs negalite būti tikri, kad užsakovo

nurodytas būdas yra teisingas. Todėl projekto vadovas turi įsitikinti, kad nurodytas būdas yra

tinkamas užsakovo problemoms spręsti.

Nepakankamas problemos apibrėžimas ir išsiaiškinimas yra viena iš IT projektų žlugimo

priežasčių. Nelaikykime užsakovo nurodyto problemos sprendimo būdo geriausiu, kol

neišsiaiškinsime verslo poreikių. Aiškiai apibrėžta problema sudaro geresnes sąlygas jums ir

užsakovui kuriamos sistemos funkciniams ir techniniams reikalavimams įvardinti.

Reikalavimų kategorijos

Funkciniai reikalavimai. Prisiminkime, kad projektais yra kuriami unikalūs produktai.

Funkciniais reikalavimais apibrėžiama, ką sukurta sistema turės daryti. Funkcinių reikalavimų

akcentas yra, kaip naudotojas sąveikaus su sistema. Užsakovo reikalavimai, kuriam versle

prireikė naujo pavidalo ataskaitų, smarkiai skiriasi nuo reikalavimų užsakovo, kuris nori įsidiegti

naują sistemą. Todėl svarbu yra apibrėžti problemą, prieš pradedant rengti specifinius

reikalavimus. Žinodami problemą jūs galėsite užduoti teisingus klausimus, kad išsiaiškintumėte

užsakovo reikalavimus. Naujo pavidalo ataskaitų atveju jūs turite žinoti, kaip ataskaita turi

atrodyti, o naujos sistemos diegimo atveju jums reikės visiškai kitokių duomenų.

Nors funkciniai reikalavimai gali būti formuluojami bendresnėmis sąvokomis nei

techniniai reikalavimai, projektų vadovas klausinėdamas turi išsklaidyti neaiškumus. Pvz., jei

užsakovo reikalavimuose rašoma, kad sukurta sistema turi būti patogi naudotojui, ar jūs

suprantate ką tai reiškia? Jei nesuprantate, vadinasi, reikalavimai yra neaiškūs ir jūs turite

išsiaiškinti, kaip užsakovas supranta sąvoką „turi būti patogi naudotojui“. Jei nesate tikri, kad

reikalavimas suformuluotas aiškiai, užduokite sau klausimą, kokį testavimo scenarijų rengtumėte

to reikalavimo įgyvendinimui patikrinti. Jei nežinote, kaip reikėtų patikrinti reikalavimo

įgyvendinimą, jūs turite gauti iš užsakovo daugiau duomenų.



23

Verslo reikalavimai. Užsakovo verslo reikalavimai atspindi rodiklius, kuriuos siekiama

pagerinti projektu. Verslo rodiklių pagerėjimu gali būti laikoma bet kas, pradedant pajamų

padidėjimu ir baigiant išlaidų sumažėjimu. Taip pat verslo pagerėjimą gali reikšti organizacijos

darbuotojų sumažėjimas, įdiegus projekto rezultatus.

Techniniai reikalavimai. Techniniai reikalavimai kitaip dar yra vadinami ne-funkciniais

reikalavimais. Tai produkto funkciniuose reikalavimuose išvardintų funkcijų vykdymo

charakteristikos (greitis, tikslumas, saugumas, kt.), kad produktas atitiktų kliento poreikius.

Techniniai reikalavimai būna įvairių kategorijų. Kokios kategorijos reikalavimai yra

reikalingi, priklauso nuo kuriamos sistemos. Dažniausiai sutinkamos techninių reikalavimų

kategorijos: panaudojimo galimybių (usability) reikalavimas, priežiūros patogumo

(maintainability) reikalavimas, teisiniai reikalavimai, eksploatacinių savybių (performance)

reikalavimai, veikimo (operational) reikalavimai, saugumo reikalavimai.

Jei jūs dirbate teisės aktų reguliuojamoje veiklos srityje, pasitikrinkite, kokių

vyriausybinių teisės aktų ar pramoninių standartų turite laikytis projektuodami ir pristatydami

sistemą. Nesilaikymas teisės aktų ar standartų reikalavimų gali būti rimtas nusižengimas, o

pažeidimų šalinimas gali pareikalauti laiko ir lėšų.

Pramoniniai standartai gali turėti įtakos jūsų projekto techniniams reikalavimams, jei

kuriate programinę įrangą, kuri turi turėti sąsajas su jau egzistuojančiomis sistemomis.

Programinės įrangos sąsajos gali reikalauti specifinių programavimo kalbų arba metodologijų.

Tokie reikalavimai turi būti išdėstyti projekto reikalavimų dokumente, nes tai gali būti svarbu

vėliau, planuojant projekto darbų trukmę ir kainą.

IT projektų techninių reikalavimų pavyzdžiai:

- sistemos reakcijos į užklausą laikas turi būti ne ilgesnis kaip 5 sekundės;

- sistema turi būti prieinama kiekvieną dieną nuo 7 iki 21 val.;

- sistema turėtų veikti PC ir Mac architektūros kompiuteriuose.

Jūsų užsakovas gali būti geriau pasirengęs svarstyti funkcinius, o ne techninius

reikalavimus. Todėl jūs turite būti sudarę standartinių klausimų sąrašą. Užsakovų, kuriems

kuriate sistemą, jūs galite prašyti tokių duomenų, kaip, pvz., vienu metu galinčių dirbti naudotojų

kiekis, sistemos darbo valandų kiekis per parą, aparatinės įrangos platforma ir kitų, kurie gali

būti reikalingi projektuojant ir kuriant naują sistemą. Jei organizacija, kurioje jūs dirbate, turi

reikalavimų šablonus ar katalogus, naudokite juos susitikimuose su užsakovais.

2.1.2. Tiekėjų pasiūlymai

Kartais, inicijuojant projektus, būtina atsižvelgti į tokius išorinius veiksnius, kaip tiekėjų,

kurių parduodamos įrangos ar teikiamų paslaugų gali reikėti, pasiūlymai. Dažniausiai to prireikia

diegiant naujas technologijas. Norint pasitelkti tiekėjus, tenka skelbti konkursus jiems parinkti,

rengti kvietimus teikti pasiūlymus (RFP – Request for Proposal), pasirašyti su jais sandorius.

Renkant tiekėją nurodoma darbų užduotis (SOW – Statement Of Work), kurią jis turės

atlikti sutartomis sąlygomis.



24

Išorės tiekėjų pasiūlymai būna įvairūs ir gali neatitikti jūsų projekto. Todėl, sudarant

sandorius, reikia būti atidiems. Sandoriai yra teisiniai dokumentai, vadovaujantis kuriais turi būti

vykdomi sutarti projekto darbai.

RFP, SOW, sandoriai yra pirkimų (procurement) planavimo dalis, apie ką plačiau rašoma

šios mokymo medžiagos 10 skyriuje.

2.1.3. Reikalavimų metmenų dokumento rengimas

Kai išsiaiškinamos užsakovo problemos, apibrėžiami funkciniai, verslo ir techniniai

reikalavimai, tuomet rengiamas reikalavimų metmenų dokumentas.

Reikalavimų metmenys yra formalus pagrindas vadovybei sprendimui dėl projekto

vykdymo priimti. Jis taip pat yra pagrindas projekto apimčiai, kainai, reikalingiems ištekliams,

darbų grafikui nustatyti.

Reikalavimų metmenyse turėtų būti tokia informacija:

1) problemos apibrėžimas:

- kas iššaukė poreikį vykdyti projektą;

- kokius specifinius verslo klausimus užsakovas nori išspręsti;

2) tikslai:

- kaip jūs suprantate sėkmingą projekto pabaigą;

- kokio galutinio rezultato siekiama;

- kokių elementų visuma (pvz., įranga, dokumentai, mokymas) sudarys galutinį

rezultatą;

- kokie tikslai;

- kaip įvertinti (išmatuoti), ar tikslas pasiektas;

3) strateginė vertė:

- kaip sistema atitinka užsakovo strateginę viziją;

- ar yra sąsajų su kitais siūlomais ar vykdomais projektais;

4) reikalavimai:

- kokias funkcijas kuriama sistema turės vykdyti;

- ar reikės sąsajų su egzistuojančiomis sistemomis;

- kokie eksploatacinių savybių (performance) kriterijai;

- kokie sukurtos sistemos palaikymo (priežiūros) reikalavimai;

5) veiksmų ir aplinkybių įvertinimas (timing): < projekto vykdytojo galimybės >

- kada projektas turi būti baigtas;

- ar reikės subrangovų (sandorių su tiekėjais);

- ar bus dideli nuostoliai, jei projektas nebus įvykdytas;

- ar turės įtakos bendrosioms pajamoms, jei projektas vėluos;

6) ankstesnė patirtis (istoriniai duomenys):

- ar buvo panašių projektų anksčiau;

- ar tie projektai buvo sėkmingi;

- ar ankstesnių projektų dalis galima panaudoti šiame projekte?



25

Aiškūs reikalavimų metmenys su išmatuojamais tikslais ir tinkamais duomenimis apie

strateginę vertę, veiksmų ir aplinkybių įvertinimą, ankstesnę patirtį, taip pat nuolatinis

komunikavimas projekto klausimais yra labai svarbūs vadovybei tvirtinant projektą.

2.2. Projektų atranka

2.2.1. Atrankos būdai

Projektų atrankos metu sprendžiami projektų patvirtinimo, leidimo pradėti projektą ir

finansavimo skyrimo klausimai. Tą daro organizacijos vadovybė. Kai kur šiuos klausimus gali

spręsti ir departamento ar kitokio padalinio vadovas.

Sudėtingų projektų atveju rengiamos galimybių studijos (feasibility study) ir tik jų

pagrindu priimami sprendimai dėl projekto vykdymo. Vertinama nauda, rinkos dydis, rizika,

alternatyvos. Tą daro žmonės, nesusiję su prašytojais vykdyti projektą.

2.2.2. Atrankos kriterijai

Projektų atrankos komitetas naudoja tam tikrus kriterijus siūlomiems vykdyti projektams

įvertinti ir atrinkti. Pasirinktas atrankos metodas turi būti vienodai taikomas visiems projektams,

kad priimtas sprendimas geriausiai atitiktų organizacijos strateginius tikslus ir geriausiai būtų

naudojami turimi ištekliai. Kriterijų tikslumas gali varijuoti, tačiau atrankos metodą dažniausiai

sudaro kurio nors sprendimų priėmimo modelio ir ekspertų (patyrusių specialistų) nuomonių

kombinacija.

Sprendimų priėmimo modeliai

Sprendimo priėmimo modelis yra formalus projektų atrankos metodas, padedantis

vadovams geriausiai panaudoti ribotą biudžetą ir žmoniškuosius išteklius. Prašymai pradėti

projektus gali būti susiję su labai įvairiais poreikiais, todėl projekto prioritetui nustatyti gali

reikėti prašymų palyginimo. Besivaržantiems departamentams kiekvienas jų prašymas,

tikriausiai, atrodo aukščiausio prioriteto. Tačiau dėl riboto biudžeto ir žmoniškųjų išteklių vieną

projektą tenka patvirtinti, o kitą atmesti. Priimtas sprendimas gali būti subjektyvus, jei nebus

atliktas prašymų palyginimas. Sprendimo priėmimo modelyje naudojamas kriterijų rinkinys, kurį

nustato projektų atrankos komitetas. Naudodamas tą patį modelį kiekvienam prašymui įvertinti,

komitetas gali priimti labiausiai objektyvų sprendimą. Sprendimo priėmimo modelių gali būti

įvairių, pradedant elementariai sudaroma eile ir baigiant sudėtingais matematiniais modeliais.

Yra dvi pagrindinės sprendimų priėmimo modelių kategorijos: naudą vertinantys metodai

ir dalinės optimizacijos modeliai (constrained optimization models).

Naudą vertinantys metodai. Naudą vertinantys metodai įgalina palyginti prašymų vykdyti

projektus naudą, įvertintą naudojant tokius pačius kriterijus. Jie yra naudojami žymiai dažniau,

nei dalinės optimizacijos modeliai. Yra trys naudą vertinantys metodai: kainos-naudos analizė,

vertinimo balais modelis ir ekonominis modelis.

Kainos-naudos analizės metode (CBA – Cost Benefit Analysis) įvertinama projekto kaina,

numatomi sutaupymai, numatomas pajamų padidėjimas. Praktikoje dažniausiai naudojamas toks

rodiklis: pelno ir kainos santykis (BCR – Benefit Cost Ratio). Tai dėl projekto gautų pajamų ir



26

investuotos į projektą sumos santykis. Jei BCR>1, projektas atsipirko. Kuo BCR didesnis, tuo

projektas patrauklesnis.

Šis metodas gerai tinka tais atvejais, kai projekto atranka remiasi tuo, kaip greitai atsipirks

investicijos į projektą, kiek sumažės organizacijos veiklos išlaidos ar padidės pajamos. Silpnoji

kainos-naudos analizės metodo vieta yra ta, kad neįvertinami kiti svarbūs veiksniai, kaip

strateginė projekto vertė. Per trumpiausią laiką atsiperkantys projektai organizacijai gali būti ir

ne svarbiausi.

Vertinimo balais modelyje naudojami iš anksto nustatyti kriterijai. Vadovaujantis jais,

projektai yra reitinguojami. Kiekvienas kriterijus turi leistiną balų kiekį ir svorio koeficientą.

Vertinimo balais modelis gali apimti finansinius duomenis, rinkos dydį, organizacinę patirtį

vykdyti projektus, inovacijas, bendrąjį organizacijos kultūros lygį. Šis modelis turi objektyvių ir

subjektyvių kriterijų. Konkretaus prašymo vykdyti projektą įvertinimo galutinis balas

apskaičiuojamas nustačius kiekvienam kriterijui balą, padauginus jį iš svorio koeficiento ir

susumavus gautas sandaugas. Kai kurios organizacijos turi nusistačiusios vertinimo balais

modelio minimalias reikšmes. Jei įvertis nesiekia minimalios reikšmės, projektas pašalinamas iš

atrankos proceso. Vertinimo balais modelio nauda yra ta, kad svarbiausiam kriterijui jūs galite

suteikti didžiausią svorį. Naudojant aukštą svorio koeficientą inovacijoms, galima gauti tokį

rezultatą, kad projektas su dviejų metų atsipirkimo laikotarpiu nurungs projektą su pusės metų

atsipirkimo laikotarpiu. Silpnoji vertinimo balais modelio vieta yra ta, kad sudaryta projektų eilė

priklauso nuo kriterijų reikšmių balais ir svorio koeficientų pasirinkimo. Gerą vertinimo balais

modelį sudaryti yra sunku. Tam reikia didelio įvairių žinybų vykdančiosios valdžios atstovų

pasišventimo.

Ekonominis modelis yra serija finansinių skaičiavimų, kurie duoda bendrus projekto

finansinius duomenis. Tai labai plati tema. Čia tik trumpai pateikiame keletą bendriausių

ekonominiame modelyje sutinkamų sąvokų:

1) diskonto norma (d). Tai pinigų nuvertėjimo bėgant laikui rodiklis. Pinigai dabar yra

vertingesni už pinigus ateityje. Diskonto norma kartais dar vadinama kapitalo kaina. Ji

apskaičiuojama taip:

d = (1+N) / (1+I) – 1 + r, kur N – rinkos palūkanų norma (pvz., 0,07. Tai atitinka 7%);

I – prognozuojama infliacija (pvz., 0,03, atitinkamai 3%);

r – rizikos koeficientas (pvz., 0,05).

Esant pavyzdžiuose nurodytoms reikšmėms, gauname d = 0,09;

2) diskontuotas pinigų srautas (DCF - Discounted cash flow). Tai diskontuotas pajamų ir

išlaidų skirtumas per tam tikrą laiko periodą (pvz., metus);

3) grynoji dabartinė vertė (NPV - Net Present Value). NPV sąlyginai parodo pinigų sumos

ateityje ekvivalentą šiandien. Projekto NPV suskaičiuojama kaip diskontuotų pinigų srautų suma

pagal tokią formulę:

NPV = Σn ( Sn / (1+d)n ), kur n = 0, 1, 2, ..., k; k – periodų (pvz., metų) kiekis, t. y. numatoma projekte sukurto produkto

gyvavimo trukmė;



27

Sn – n-tojo periodo pinigų srautas;

d – diskonto norma.

Kai n = 0, tuomet S0 yra išlaidos projekto pradžioje. Kuo NPV didesnis, tuo projektas yra

patrauklesnis;

4) atsipirkimo periodas (payback period). Tai numatomas laiko tarpas, per kurį projektas

atsipirks. Per šį laiką pinigų srauto (DCF) reikšmė pasidaro ir toliau išlieka teigiama;

5) vidinė grąžos norma (IRR - Internal Rate of Return). Tai investicijos arba projekto

pelningumo rodiklis, apskaičiuojamas kaip palūkanų norma, kuriai esant projekto grynoji

dabartinė vertė NPV pasidarytų lygi nuliui per projekto gyvavimo trukmę. Gaunamas pagal

formulę:

0 = Σn ( Sn / (1+IRR)n ),

kur n = 0, 1, 2, ..., k; k – numatomas projekte sukurto produkto gyvavimo periodų (pvz., metų)

kiekis; Sn – n-tojo periodo pinigų srautas.

Kuo IRR didesnis, tuo projektas rentabilesnis (pelningesnis). Pvz., jei diskonto norma d

yra mažesnė už IRR, verta skolintis pinigų ir pradėti projektą. Kitu atveju – ne;

6) atsipirkimo norma (ROI – Return On Investment). Tai gautų pajamų ir investuotos į

projektą sumos skirtumo santykis su investuota į projektą sumą. Jei ROI>0, tai projektas

atsipirko. Kuo ROI didesnis, tuo projektas patrauklesnis.

Matematinio modeliavimo metodai. Vienas iš jų yra dalinės optimizacijos modelis. Kai

kurie iš jų yra labai sudėtingi ir reikalauja gilių statistikos ir kitų matematikos žinių. Šie modeliai

naudojami labai sudėtingiems projektams įvertinti ir atrinkti.

Ekspertų nuomonė

Siūlomus projektus vertinti gali ir ekspertai. Ekspertizę gali atlikti sponsorius,

pagrindiniai akcininkai, kito departamento žmonės, konsultantai, pramonės atstovai. Ekspertų

nuomonė gali būti derinama su vieno iš sprendimo priėmimo modelio rezultatais. To dažniausiai

prireikia, kai atrankai pateiktų projektų įverčiai, gauti naudojant sprendimo priėmimo modelį,

mažai tesiskiria.

Organizacijos, kurios nenaudoja formalios projektų atrankos, gali remtis vien ekspertais.

Nors ekspertai ir gali padaryti paprastesnį projektų atrankos procesą, tačiau pavojus suklysti

išlieka. Nepanašu, kad projektų atrankos komiteto nariai gerai išmanytų visus pristatytus

projektus. Neturint duomenų, kuriuos galima būtų palyginti, projektą patvirtinantis sprendimas

gali būti priimtas remiantis tik tuo, kad projektas geriausiai buvo pristatytas arba kad pranešėjas

yra geriau žinomas.

Ekspertų nuomonei įtakos gali turėti ir politiniai motyvai. Arba, autoritetingas

administratorius gali įtikinti projektų atrankos komitetą patvirtinti tam tikrą projektą.



28

2.3. Projekto akcininkai

Projekto reikalavimų metmenų rengimo ir projektų atrankos metu jūs jau susiduriate su

svarbiais asmenimis – akcininkais. Kaip apskritai suprantamas akcininkas ir kodėl jūs turite

žinoti pagrindinius savo projekto akcininkus?

Akcininkas yra asmuo, kuris aktyviai įsijungia į projektą arba kuriam projektas daro įtaką.

Akcininkai kažką laimi arba praranda, todėl būtina žinoti jų lūkesčius, viltis. Akcininkai gali

susidomėti ir įsijungti į projektą skirtingais laiko momentais.

Kai kurie akcininkai gali neremti jūsų projekto. Jų veiklai didelę įtaką turintis projektas

gali būti traktuojamas kaip tam tikra grėsmė. Pokyčių gali būti bijomasi. Veiklos efektyvumą

didinantys projektai gali būti susiję su darbuotojų kiekio mažinimu. Bijodami netekti darbo, tam

tikri asmenys arba organizacijos gali prieštarauti projektui.

Bendraujant su akcininkais jums gali prireikti daugelio bendrųjų projekto vadovo įgūdžių

(žiūr. 1.3 skyrių). Kai kurie akcininkai gali turėti skirtingus jūsų projekto prioritetus, dėl ko gali

tekti vesti sunkias derybas. Konsensuso (sutarimo) tarp skirtingas nuomones turinčių akcininkų

siekimas pradedamas derybomis projekto inicijavimo etape ir tęsiasi visą projekto laiką.

Smulkiau kai kurie ryšių su akcininkais palaikymo klausimai aptariami 9 skyriuje „Komunikacijų

planavimas“.

Susitikimus su akcininkais ir jų apklausas organizuokime kaip galima anksčiau, kad

sužinotume, kas juos domina ir ko jie tikisi iš projekto. Jei pradžioje kuriuos nors akcininkų

keliamus klausimus ignoruosime, vėliau juos išspręsti bus žymiai sunkiau.

2.3.1. Projekto sponsorius

Projekto sponsorius yra ypatingas akcininkas. Nors projektas turi daug akcininkų, apie

kuriuos rašoma truputį vėliau, tačiau sponsorius yra (turėtų būti) tik vienas.

Sponsorius yra asmuo, kuris remia projektą organizacijos vardu. Jis yra kaip projekto

vadovo patarėjas. Projekto vadovas informuoja sponsorių apie projekto einamuosius reikalus,

įskaitant konfliktus ir galimą riziką. Projekto sponsorius paprastai yra atsakingas už:

- projektui reikalingų finansų gavimą;

- pagrindinių akcininkų analizę;

- derybas su pagrindiniais akcininkais dėl paramos projektui;

- projekto etapų rezultatų priėmimą;

- trukdžių ir sunkumų šalinimą;

- politinio „stogo“ teikimą projekto vadovui.

2.3.2. Kiti projekto akcininkai

Visas akcininkų sąrašas priklauso nuo projekto ir organizacijos, kurioje jūs dirbate. Kuo

didesnis ir sudėtingesnis projektas, tuo daugiau akcininkų jūs turėsite. Aukšto lygio projektuose

akcininkų kartais būna daugiau negu reikia. Todėl rekomenduojama projekto vadovui išnagrinėti,

kurie akcininkai iš tikro yra susiję su projektu, ir jų sąrašą aptarti drauge su sponsoriumi.

Sponsorius gali geriau įvardinti „politiškai“ svarbius akcininkus, t. y. įtakingus žmones tų

organizacijų, kurios išreiškė susidomėjimą projektu.



29

Kai kurie akcininkai yra aiškūs ir nesunku juos įvardinti. Be projekto sponsoriaus

dauguma projektų turi nemažai bendrųjų akcininkų. Išvardinkime juos.

Projekto vadovas. Tai asmuo, kuris vadovauja projekto darbams. Plačiau apie šį asmenį jau

rašyta 1.3 skyriuje.

Projekto grupės nariai. Tai ekspertai (specialistai), kurie vykdys projekto darbus.

Priklausomai nuo jūsų organizacijos struktūros tipo (funkcinė, matricos ar projektinė) šie

žmonės gali būti pavaldūs tiesiog projekto vadovui arba priklausyti kitam departamentui.

Projekto grupės nariai gali būti įdarbinti projekte visą jo laiką arba tik dalį laiko. Daugumoje

projektų vieni nariai įdarbinami visam projekto laikui, kiti – daliai laiko. Jei yra žmonių įdarbintų

tik daliai projekto laiko, jūs turite žinoti ir kitas jų pareigas, kad nebūtų persidengimų (tuo pačiu

metu žmogus negali dirbti ir čia, ir ten).

Jūsų projekto grupėje gali būti ne vien tik IT srities specialistai, bet ir pirkimų, teisės,

viešųjų ryšių, rinkodaros, pardavimų, klientų aptarnavimo specialistų.

Funkcinių padalinių vadovai. Jei projekte įdarbinami jūsų organizacijos funkcinių

padalinių žmonės, šių funkcinių padalinių vadovai, skyrę žmones projektui, yra svarbūs

akcininkai. Paprastai keletas projektų konkuruoja dėl turimų žmoniškųjų išteklių gavimo. Todėl

jūs turite stengtis palaikyti gerus santykius su funkcinių padalinių vadovais. Dokumentuoti

susitarimai dėl žmonių skyrimo projektui kažkuriam laikui ir atsiskaitymai už žmonių darbą gali

apsaugoti nuo nesusipratimų ateityje. Išankstiniai susitarimai su šiais vadovais suteikia duomenų

apie įkainius, algos dydį, žmonių skatinimo galimybes.

Funkcinio padalinio vadovas priima sprendimus minėtais klausimais. Jei jūs sutarsite su

funkcinių padalinių vadovais iš anksto, nuo to aiškesnis taps jūsų vaidmuo ir pakils autoritetas.

Pirkėjas / klientas. Pirkėjas yra projekte sukurto produkto ar paslaugos gavėjas. Kai

kuriose organizacijose šie akcininkai gali būti traktuojami kaip klientai. Pirkėju dažniausiai

vadinama grupė arba organizacija, o ne pavienis asmuo. Gali būti vidiniai pirkėjai, pvz.,

organizacijos prekybos padalinys, prašantis įrengti serverių sistemą. Išorinio pirkėjo pavyzdžiu

gali būti įstaiga, norinti įsigyti naujų sistemos savybių, funkcijų.

Galinis naudotojas. Galiniais naudotojais vadinami asmenys, kurie betarpiškai naudoja

projekte sukurtą produktą. Ši sąvoka dažnai naudojama IT projektuose, siekiant pabrėžti

skirtumą tarp projekto produktą perkančios organizacijos ir grupės žmonių, kurie produktą

naudos kasdieninėje veikloje. Pvz., organizacijos pardavimų padalinys, turintis on-line prieigą

prie sistemos, gali būti laikomas pirkėju, tuo tarpu už organizacijos ribų esantys pardavimų

konsultantai yra tokios sistemos galiniai naudotojai.

Galiniai naudotojai gali dalyvauti kai kurių projekto reikalavimų peržiūrose arba produkto

funkciniuose testavimuose.

Iš bendrųjų akcininkų sąrašo matyti, kad jie atstovauja plačiam su projektu susijusiam

funkcinių sričių, norų ir poreikių ratui. Jų įgyvendinimui stebėti, tikriausiai, norėtumėte sudaryti

akcininkų lentelę ar sąrašą (vieni stebėtų ir nagrinėtų vienus rodiklius, kiti – kitus).



30

2.3.3. Kas yra jūsų IT projekto akcininkai?

Tipiškai IT projekto akcininkais tampa panašia veikla užsiimančių ir prašančių pradėti

projektą verslo organizacijų atstovai. Kadangi IT naudojamos beveik kiekvienoje organizacijų

veikloje, todėl laikui bėgant jūs galite susidurti su įvairiausiais projektais. Dažniausiai

susiduriama su trijų klasių IT projektais, kuriems specifinę įtaką daro akcininkų rato sudėtis:

vienos veiklos srities (single business unit) projektais, keleto veiklos sričių (multiple business

unit) projektais ir įmonių (enterprise) projektais. Smulkiau aptarkime kiekvieną iš jų.

Vienos veiklos srities projektas. Vienos veiklos srities projektuose jums gali tekti

užmegzti glaudesnius ryšius, pvz., su rinkodaros ar pardavimų atstovais, kad jie padėtų parengti

projektą (planą, angl. design) sistemos, kuri atitiktų specifinius jų veiklos poreikius.

Tokiais atvejais, tikriausiai, jums bus pristatoma veiklos srityje naudojama sistema, tačiau

nebeatitinkanti poreikių. Daugeliu atveju veiklos srities akcininkai jau būna atlikę kai kuriuos

tyrimus, ko jie norėtų, ir turi parengę rekomendacijas dėl jau gatavos (COTS) programinės

įrangos įsigijimo, kuri jų manymu tiktų jiems. Kaip projekto vadovas jūs turėtumėte atidžiai

išnagrinėti tą programinę įrangą, nes ji gali neatitikti didesnių organizacijų reikalavimų. Taip pat

būtina įsitikinti, ar ta įranga yra vientisa, patikima, labiausiai reikalinga ir ar jūs pajėgsite tvarkyti

ją.

Kai kuriais atvejais veiklos srities atstovai tiesiog nežino, kokia programinė įranga galėtų

išspręsti jų problemas. Tuomet jie prašo jūsų padėti suformuluoti projekto užduotį. Dar didesnę

veikimo laisvę jūs gaunate štai tokiu atveju. Gatavos (COTS) programinės įrangos šiandien yra

tiek daug, kad jūs sėkmingai galite rasti pakankamai gerai tinkančią veiklos sričiai. Tačiau kai

kuriais atvejais gali būti prašoma sukurti naują programinę įrangą pagal užsakovo specifikaciją.

Tuomet jums, kaip projekto vadovui, pasitelkus sistemų analitiko gebėjimus, reikia priimti

geriausią jums žinomą sprendimą, tinkantį iškeltam uždaviniui.

Keleto veiklos sričių projektas. Kartais dvejom arba daugiau veiklos sričių gali tikti ta pati

sistema jų problemoms spręsti. Pavyzdžiu gali būti dokumentų tvarkymo sistema (DMS –

Document Management System). Keleto veiklos sričių projektas yra toks, kai dvi arba daugiau

organizacijų pareiškia, kad jos bendrai gali finansuoti joms visoms tinkantį DMS projektą.

Šiuo atveju uždavinys yra kur kas sunkesnis, nes jūs turite reikalą su įvairiais akcininkais,

kurių kiekvienas turi savo veiklos sritį, tačiau panašius interesus. Pasiekti akcininkų sutarimą yra

svarbiausias uždavinys.

Papildomas sunkumas yra tas, kad jūs turite įsigilinti į kiekvieną veiklos sritį, norint

sukurti visiems priimtiną sistemą. Vieniems gali nereikėti, pvz., gaunamų dokumentų kontrolės

DMS‘e, nes juos turi tikrinti siuntėjas, laikydamasis teisės aktų reikalavimų. Tuo tarpu kitiems

gaunamų dokumentų kontrolė gali būti reikalinga. Tokių klausimų sprendimas yra svarbus

projektų valdyme.

Įmonės projektas. Dar viena projektų rūšis yra įmonės projektas. Įmonė – tai įvairių jos

padalinių visuma.

Įmonės projektu gali būti, pvz., organizacijos el. pašto sistema arba bendras intranetas.

Visi įmonės darbuotojai naudosis šiomis sistemomis, o jas prižiūrės, greičiausiai, atskiros IT

specialistų grupės.



31

Įmonės projektai kelia įdomius akcininkų rato klausimus. Kas yra jūsų organizacijos

kurios nors sistemos akcininkas? Sistemą tai naudoja visi darbuotojai. Taigi, jūsų žvilgsnis gali

nukrypti į bet kurią ankstesniame šios mokymo medžiagos skyriuje įvardintą akcininkų grupę,

ieškant pagrindinio sistemos akcininko. Pvz., naujoje el. pašto sistemoje įrašai, tikriausiai, bus

tvarkomi bendrai. Todėl asmuo arba grupė, įgaliota parengti įrašų saugojimo tvarką, bus labai

svarbus akcininkas, sprendžiant el. pašto klausimus. Naujame bendrame intraneto projekte visi

naudotojai bus akcininkai, bet, greičiausiai, kiekvienos veiklos srities (organizacijos funkcinio

padalinio) duomenų (content) tvarkytojai bus pagrindiniai projekto akcininkai.

IT projekto grupės nariai. IT projektuose kai kurie grupės nariai (nepamirškime, kad ir jie

yra akcininkai) gali turėti keletą pareigų. IT projektų grupės skiriasi nuo statybų projektus

vykdančių grupių. Statybininkai dirba tik tuos darbus, kuriuos jie geriausiai moka (pvz.,

santechnikas nedirba elektriku). IT projektų grupėse būna narių, kurie specializuojasi vienoje

kurioje nors IT srityje, tačiau gerai išmano ir kitų grupės narių funkcijas. Programinės įrangos

kūrėjai turi gerai suprasti ir duomenų bazes, nes sistemos naudotojų įvedamus duomenis dažnai

tenka rašyti į duomenų bazę. Duomenų bazių administratoriai ypač gerai turi žinoti, ką daro

programuotojai, suprasti, kaip veikia serveriai ir kaip naudotojai kompiuterių tinklais jungiasi

prie duomenų bazių. Serverių administratorius turi suprasti, kad serveriai reikalingi veiklos

funkcijoms atlikti, kad nekrintanti į akis tinklo operacinė sistema (NOS – Network Operating

System) nėra suma to, ką daro serveris. Visame šitame margumyne yra ir sistemų analitikai,

verslo analitikai, atskirų veiklos sričių žinovai ir kiti, kurie drauge siekia projekto rezultatų.

Išvardinkime specialybes žmonių, kurių, priklausomai nuo kuriamo produkto, gali reikėti

IT projekto grupėje.

Programuotojai. Tai dažniausiai sutinkami darbuotojai IT projektuose. Jų kuriami

produktai yra labai įvairūs: serverių taikomosios programos, naudotojų sąsajos, mikroprogramos

(jos veikia aparatinėje įrangoje), duomenų bazėse laikomos procedūros, interneto / intraneto

specializuoti moduliai (spausdintuvams, komunikacijoms).

Serverių administratoriai. Šie grupės nariai yra atsakingi už projekto produktui

funkcionuoti reikalingų serverių įrengimą (Intel, mainframe ar kitokioje bazėje).

Duomenų bazių administratoriai (DBA). Jie yra atsakingi už duomenų bazės struktūros ir

atitinkamų reikalavimų parengimą, duomenų atsarginių kopijų darymo ir atstatymo metodikų

suplanavimą. DBA darbas apima lentelių struktūros paprastinimo greitesniam jų apdorojimui

koncepcijos parengimą. Šis procesas vadinamas normalizacija.

Interneto specialistai. Jų pareiga yra tvarkyti maršrutizatorius (routers), komutatorius

(switches), išvedžioti vietinio kompiuterių tinklo (LAN – Local Area Network) kabelius, rūpintis

jungtimis su plačiuoju kompiuterių tinklu (WAN – Wide Area Network).

Telefonijos specialistai. Žmonės, kurie organizacijoje tvarko telefonų įrangą ir jos veikimą,

vadinami telefonijos specialistais. Šiandien daug sistemų naudoja telefonijos paslaugas.

Prisiminkime telefono principu veikiančią meniu sistemą – interaktyvųjį atsakymą balsu (IVR –

Interactive Voice Response). Jos programinė įranga įgalina reaguoti į skambučius, pateikti

naudotojui meniu sistemą, ką jis gali pasirinkti, ir išduoti atitinkamą atsakymą. IVR programinė

įranga veikia serveryje, sujungtame su telefonų tinklu.



32

Sistemų analitikai. Sistemų analitikai yra ypač kvalifikuoti žmonės ir turintys patirtį IT

srityje. Jie, kurdami sistemos reikalavimus ir iš jų rengdami sistemos projekto (plano, angl.

design) specifikaciją, dirba funkcijų lygiu. Toliau sistemos kūrėjai (gamintojai) naudoja

specifikaciją vykdydami projektą. Šiandien sistemų analitikai turi gerus programinius

instrumentus, kurie padeda jiems greitai ir tiksliai sumodeliuoti sistemą, turint veiklos procesų

sekas.

Veiklos srities analitikai. Dažnai tas pats žmogus būna ir sistemų, ir veiklos srities

analitikas. Jis žino veiklos srities bendrąsias (high level) sąvokas, kad galėtų šnekėtis ir suprasti

veiklos srities poreikius. Tačiau jis moka bendrauti ir su IT specialistais, padėdamas jiems

suprasti, ko veiklos srities atstovai iš tikro nori. Veiklos srities analitiku gali būti IT specialistas,

dirbęs toje veiklos srityje, arba veiklos srities specialistas, dirbantis IT įmonėje.

Sistemų architektai. Sistemų architektai turi aukšto lygio žinias apie sistemas ir yra

pajėgūs parengti siūlomos sistemos planą. Kartais sistemų analitikas būna ir sistemos architektu.

Būna ir taip, kad sistemos kūrėjui (gamintojui) ir net projekto vadovui tenka rengti sistemos

architektūrą. Tačiau, kuriant dideles sistemas, projektų vadovams dažniausiai talkina tikrieji

sistemų architektai.

Biudžeto analitikas. Ypač dideliems projektams reikia biudžeto analitiko, kuris stebėtų

projekto biudžetą ir daromas išlaidas.

Saugumo analitikas. Saugumo analitikas yra palyginus naujas, tačiau būtinai reikalingas

narys daugelio sistemų projektų grupėse. Saugumo analitikas turi rūpintis, kad kuriamoje

sistemoje visos saugumo priemonės būtų įgyvendintos. Ši specialybė yra unikali ir reikalaujama,

kad saugumo analitikas, ypač vidutinio ir didelio masto projektuose, turėtų puikų išsilavinimą ir

būtų patikimas asmuo.

Techniniai redaktoriai. Dideliuose projektuose techninių redaktorių pareiga yra visų

projekto dokumentų rašymas. Tai mokymo dokumentai, naudotojų instrukcijos, pagalbos

naudotojams tarnybos (help-desk) tekstai ir kiti dokumentai.

Šie žmonės turi suprasti techninį žargoną ir santrumpas, mokėti susišnekėti visais

klausimais. Svarbu, kad techniniai redaktoriai būtų draugiški, nebijotų klausti, kas yra padaryta,

ir glaudžiai bendradarbiautų. Projekto grupė turi būti sudaryta iš žmonių, kurie supranta

projekto tikslus ir drauge siekia jų. Kitaip bus chaosas.

Projekto grupės nariai turi būti iniciatyvūs žmonės, galintys vykdyti užduotis be didelės

priežiūros, besilaikantys sistemos projekto (design) specifikacijos. Sistemos projekto grupė nėra

gera vieta tik pradedantiems dirbti, nes čia reikalingi žmonės su patirtimi.

Kaip techninio projekto grupės vadovas, jūs turite suprasti, kad teks dirbti su įvairaus tipo

asmenimis ir kažkaip reikės derinti psichologinius dalykus. Šalia tvirto supratimo apie projekto

rezultatų technologinius niuansus, jūs taip pat turite turėti supratimą apie projekto grupės

dinamiką ir kaip žmonės sąveikauja iškilus sunkumams. Jūs turite būti pasirengęs spręsti

skundus, derinti argumentus, surinkus visus drauge logiškai aiškinti savo veiksmus, kad visi

akcininkai suprastų juos, ir t. t. IT projektų valdyme būtinas aiškus, trumpas ir adekvatus

komunikavimas su akcininkais.



33

Akcininkų sąrašas. Jeigu yra didelis projektas ir daug akcininkų, gali būti sudaromas

akcininkų sąrašas projekto eigai stebėti. Šiame akcininkų sąraše turėtų būti tokia informacija

apie akcininkus:

- vaidmuo projekte;

- projekto poreikis;

- įsitraukimas (dalyvavimas) į projektą;

- įtakos projektui lygis.

Šis sąrašas gali būti naudingas įrankis projekto peržiūrose, kai iškyla konfliktai. Jis gali

padėti projekto vadovui suprasti ir tinkamai reaguoti į įvairias situacijas. Sąrašo reikšmė ypač

svarbi, kai jūsų projektas turi keletą politinių akcininkų.

Kadangi akcininkai gali pasitraukti iš projekto ar įsijungti į projektą skirtingu laiku, labai

svarbu, kad projekto vadovas peržiūrėtų projekto nuostatus ir projekto planą, kai tik akcininkas

įsijungia į projektą.

2.4. Projekto nuostatai

Inicijavimo procesų rezultatas yra projekto nuostatai (project chart). Tai dokumentas

leidžiantis pradėti projektą ir įgaliojantis projekto vadovą naudoti projektui skirtus išteklius.

Projekto nuostatai yra pirmas patvirtinto projekto dokumentas. Projektus paprastai tvirtina

organizacijos ar departamento vadovybė. Ši organizacija nebūtinai turi būti sponsorius.

Projekto nuostatai yra pradinis projekto planas. Galutinis projekto produktas, tikriausiai,

smarkiai skirsis nuo pradžioje sumanyto, tačiau nuostatai yra pirmosios projekto darbų gairės.

Projekto nuostatų formą ir turinį nustato organizacijos, kurioje jūs dirbate, vidiniai

standartai. Jūs, kaip projekto vadovas, turėtumėte pasidomėti, ar nėra kokio nors šablono, kurio

privalu laikytis. Bet kuriuo atveju projekto nuostatuose turi būti reikalavimų metmenys, verslo

poreikių dėstymas ir formalus patvirtinimas, leidžiantis pradėti projektą. Jei jūsų projektas

dalyvavo formaliame atrankos procese, tai, tikriausiai, būsite surinkę daugiau duomenų. Jie

įgalina parengti projekto nuostatus, kuriuose būtų reikalavimų metmenys, informacija dėl

projekto grupės, uždaviniai ir tikslai, projekto pagrindimas ir formalus projekto patvirtinimas.

Projekto nuostatų dalis apibūdinkime plačiau.

2.4.1. Reikalavimų metmenys

Reikalavimų metmenyse nurodomos pagrindinės projekte numatomo kurti produkto

charakteristikos ir tam reikalingi darbai. Remiantis šiais metmenimis vėliau, t. y. projekto

apimties planavimo metu bus rengiami detalūs reikalavimai. Projekto reikalavimų metmenys

atspindi sąryšį tarp numatomo kurti produkto ir verslo poreikių, dėl ko buvo inicijuotas

projektas. Plačiau apie reikalavimų metmenis rašyta 2.1.1 skyriuje.

2.4.2. Informacija apie projekto grupę

Projekto nuostatuose formaliai įvardinamas projekto vadovas ir jam suteikti įgaliojimai.

Aiškus įgaliojimų išdėstymas padeda ateityje išvengti nesusipratimų. Juose turi būti nurodoma:

- ar projekto vadovas galės samdyti ir atleisti darbuotojus;

- ar projekto vadovas galės įtakoti grupės narių algos dydį;



34

- ar projekto vadovas bus atsakingas už projekto biudžeto lėšų panaudojimą;

- pinigų suma, kurią projekto vadovas galės išleisti be sponsoriaus ar kito

administratoriaus leidimo.

Gali būti išvardinti visi žinomi projekto grupės nariai. Tačiau projekto nuostatuose

dažniausiai nurodomos tik reikiamų darbuotojų specialybės, kategorijos. Gali būti vardinami,

pvz., veiklos srities analitikas, sistemų analitikas, programuotojas, testuotojas. Projektų, kuriuose

bus sudaromi sandoriai su išoriniais subrangovais (cross-functional projects), nuostatuose

reikėtų išvardinti reikiamus grupės narius ir iš kitų departamentų, kaip produkto vadybininkas,

sandorių specialistas ar mokymų rengėjas.

2.4.3. Uždaviniai ir tikslai

Projekto nuostatuose turi būti įvardinti projekto uždaviniai ir tikslai. Šioje nuostatų dalyje

aiškiai turi būti nurodyta, kokie projekto rezultatai turi būti gauti ir kaip bus vertinama rezultatų

kokybė. Uždaviniai ir tikslai turi būti aiškūs ir suformuluoti taip, kad galima būtų įvertinti

galutinių rezultatų atitikimą iškeltiems tikslams. Pvz., vietoje formuluotės „įdiegti greitą įrašų

apie pirkėjus paieškos sistemą“ reikėtų naudoti „įdiegti sistemą, kurioje įrašų apie pirkėjus

vidutinė paieškos trukmė būtų 5 sekundės“.

Dirbant su klientais, kiekybiškai išmatuojami tikslai yra projekto sėkmės laidas. Juos

vienodai turi suprasti ir klientas, ir sponsorius, ir pagrindiniai akcininkai, ir projekto vadovas, ir

projekto grupės nariai. Neaiškūs tikslai, kurių įgyvendinimo lygį sunku įvertinti, kelia didelį

pavojų projekto sėkmei.

2.4.4. Projekto pagrindimas

Vadovybės patvirtinti projekto nuostatai reiškia ir projekto pradinio finansavimo

patvirtinimą. Pradinis finansavimas priklauso nuo projekto pagrindimo (business case). Projekto

pagrindime formaliai atspindimi elementai, naudoti projekto vertinimo metu. Tai analizės

metodų ir rezultatų aprašymas.

Projekto pagrindimas yra autonominis dokumentas. Pradžioje jo turinys būna labai

abstraktus, o projekto eigoje daug kartų tikslinamas. Projekto pagrindimas papildomas detalėmis

projekto planavimo procese. Nemažai organizacijų turi projektų pagrindimo šablonus, kurių kai

kurios dalys užpildomos projektų atrankos metu.

Projekto pagrindimas projekto nuostatuose gali turėti apytikrius kainos (išlaidų), naudos ir

atsipirkimo periodo įverčius.

Kaina (išlaidos). Projekto tvirtinimo metu turi būti nurodytas galimų išlaidų

žmoniškiesiems ištekliams išlaikyti, medžiagoms, įrangai įsigyti įverčiai. Šie įverčiai nėra tikslūs,

nes gaunami remiantis anksčiau vykdytų panašių projektų patirtimi arba ekspertų nuomone.

Tipiniame IT projekte skiriamos dvi išlaidų dalys: turtui įsigyti ir žmoniškiesiems

ištekliams išlaikyti. Turto įsigijimo išlaidas sudaro naujos įrangos, kaip serveriai, darbo

kompiuteriai ir pan., įsigijimo kaina. Žmoniškųjų išteklių išlaikymo išlaidos – tai darbuotojų algos,

komandiruotpinigiai, mokymų išlaidos.

Nauda. Pajamos yra pagrindinis naudos rodiklis. Tai pinigų srautas, gaunamas už projekte

sukurto produkto ar paslaugų teikimą išoriniam pirkėjui. Ne visi projektai generuoja pajamas,



35

tačiau tiems projektams, kurių rezultatai parduodami išoriniams pirkėjams, pajamos yra kritinis

rodiklis. Pradinį pajamų dydį įvertina rinkodaros specialistai, remdamiesi numatoma sukurto

produkto kaina ir pardavimų prognoze.

Pajamos yra kiekybiškai išmatuojama nauda. Pvz., gali būti projektuojama, kad per pirmus

metus po produkto sukūrimo (pabaigus projektą) pajamos bus vienas milijonas litų.

Kitus naudos rodiklius, kaip, pvz., padidėjusį pirkėjų pasitenkinimą, sunku išmatuoti

kiekybiškai. Naudą, kurios negalima įvertinti pinigais, vadina nepamatuojama (soft benefit).

Atsipirkimo periodas. Pajamas generuojantiems projektams atsipirkimo periodas reiškia

laiką, per kurį grįžta į projektą investuotos lėšos.

Atsipirkimo periodą taip pat gali turėti ir pajamų negeneruojantys projektai. Pvz., nauja

užklausų aptarnavimo sistema su geru meniu gali padidinti užklausų aptarnavimo centro

efektyvumą, nedidinant darbuotojų kiekio. Taip sutaupomų lėšų dydis gali būti panaudotas tos

sistemos atsipirkimo periodui apskaičiuoti.

2.4.5. Formalus projekto patvirtinimas

Projekto nuostatus turi pasirašyti įgaliojimus turintis administratorius. Tai gali būti

projekto sponsorius, projekto klientas arba projektų atrankos komiteto atstovas. Nuostatus

pasirašiusio asmens parašas reiškia tos organizacijos leidimą pradėti projektą.

Tokiu parašu suteikiami įgaliojimai projekto vadovui pradėti projekto darbus. Tai leidžia

jam pradėti įrangos pirkimus ir derybas su organizacijos funkcinių padalinių vadovais dėl

projektui reikalingų žmoniškųjų išteklių skyrimo.

Užbaigus projekto nuostatus, nuo inicijavimo procesų pereinama prie planavimo procesų.

Nežiūrint to, kas pasirašė projekto nuostatus, dabar pats laikas pradėti rūpintis jūsų projekto

akcininkų parama. Visiems akcininkams reikia išdalinti projekto nuostatų kopijas. Taip pat

reikėtų organizuoti susirinkimą su jais projekto nuostatams apsvarstyti, tolesniems projekto

žingsniams ir rūpimiems klausimams aptarti. Kad ateityje nekiltų ginčų dėl susirinkimo rezultatų,

pagrindiniai svarstyti klausimai ir priimti nutarimai turi būti dokumentuojami ir išsiuntinėjami

visiems akcininkams. Kuo anksčiau problemos įvardinamos, tuo lengviau jas spręsti. Ko nors

ignoravimas ar nepakankamas akcininkų informavimas gali pareikalauti aukštesnių vadovų

įsikišimo, nuvesti projektą klaidingu keliu. Labai svarbu užsitikrinti aukštesnės vadovybės

paramą, palaikant su ja nuolatinį ryšį. Projekto vadovas atsako už tai, kad projekto metu tarp

akcininkų būtų sutarimas.

IT vadovų hierarchija (chain of command). Projekto nuostatuose įvardinami žmonės,

kurie bus atsakingi už projektui reikalingų išteklių naudojimą. Projekto vadovui pravartu žinoti,

kokia yra IT vadovų hierarchija organizacijoje, kas ir kokius įgaliojimus turi. Nors dauguma IT

padalinių yra smulkūs (pvz., programuotojų, serverių administratorių, kt. grupėse yra tik po

keletą žmonių), kiekvienas iš jų turi savo vadovą, savo biudžetą, savo darbuotojus. Pvz., jūsų

projektui prireikė programuotojo, kuris yra pavaldus keturis ar penkis darbuotojus turinčiam

programuotojų padaliniui. Tas padalinys turi savo vadovą, kuris yra atsakingas už šių darbuotojų

kasdieninę veiklą. Šis vadovas turi būti nurodytas projekto nuostatuose, nes jis turi teisę skirti ar

neskirti jūsų projektui reikalingą programuotoją. Tas pats yra ir su kitų sričių specialistais. Jūs



36

negalite kreiptis į kitokio padalinio vadovą dėl programuotojo skyrimo jūsų projektui, nes

programuotojas nepavaldus tam vadovui. Taigi, būtų protinga žinoti organizacijos vadovų

hierarchiją, kas ir kokius technologinius darbus kuruoja.

IT vadovų hierarchija gali priklausyti nuo organizacijos, kurioje jūs dirbate, dydžio ir

išsidėstymo. Kalbant bendrai, gali būti programuotojų, tinklų priežiūros, serverių priežiūros,

telefonijos, saugumo, interneto / intraneto, duomenų bazių, kt. padalinių vadovai. Šie vadovai yra

atskaitingi aukštesnio lygio vadovams. 2.1 pav. parodytas IT organizacijos darbuotojų

hierarchijos pavyzdys, kuriame matome ir projektų valdymo skyrių (PMO – Project Management

Office). Kai kurios organizacijos (pvz., matricos tipo organizacijos) turi PMO. Jame suburiami visi

profesionalūs projektų vadovai. Toks skyrius pajėgus imtis bet kokio organizacijos projekto.

Hierarchijos laikymosi problemos. Projekto nuostatuose nurodomos projektui vykdyti

reikalingų darbuotojų specialybės (pavardžių galime ir nežinoti). Todėl pavaldumo hierarchijos

žinojimas palengvina jūsų darbą, nes žinote į ką organizacijoje reikia kreiptis dėl jūsų projektui

reikiamų specialistų. Pvz., nereikėtų reikalauti skirti programuotoją, nepasitarus su

programuotojų padalinio vadovu, atsakingu už šių žmonių panaudojimą.

IT įmonėse yra tam tikrų problemų dėl darbuotojų pavaldumo (atskaitomybės)

hierarchijos laikymosi. Ne visada pavyksta sutarti su padalinių vadovais dėl jūsų projektui

reikalingų išteklių skyrimo. Tenka įdėti daug planavimo pastangų, darbo su kiekvieno padalinio

vadovais, kad jie skirtų savo žmones projektui tinkamu laiku.

Dar sudėtingesnės problemos kyla, kai keleto mažesnių padalinių vadovai nėra atskaitingi

tam pačiam aukštesniam vadovui.

Deja, nėra idealaus būdo tokioms komplikuotoms situacijoms valdyti. Geriausia

problemas numatyti iš anksto ir projekto darbų grafike skirti papildomą laiką joms spręsti.

IT departamento direktorius

Projektų valdymo skyrius (PMO)

Programuotojų

padalinio vadovas

Tinklų priežiūros

padalinio vadovas

Infrastruktūros

padalinio vadovas

Duomenų bazės

administratorius Programuotojas Serverio

administratorius

Interneto

administratorius

2.1 pav. IT organizacijos darbuotojų hierarchijos pavyzdys



37

3. PROJEKTO APIMTIES PLANAVIMAS

Planavimas yra vienas iš svarbesnių projekto valdymo darbų. Gavus leidimą vykdyti

projektą, natūralu, kad vykdytojams rūpi pradėti jį kuo greičiau. Tačiau projekto vadovas gali

pastebėti, kad organizacija nėra numačiusi laiko planavimo darbams.

Geras planavimo proceso suvokimas padeda projekto vadovui pasirengti pokalbiams su

savo organizacijos vadovybe apie laiko skyrimą projekto valdymo klausimams apgalvoti dar iki

tikrųjų darbų pradžios. Projekto planavimas yra sudėtingas procesas. Jis apima daugybę

klausimų, kaip projekto apimties, darbų grafiko, kainos, darbuotojų kiekio, pirkimų, kokybės,

rizikos planavimą. Pradedant šiuo mokymo medžiagos skyriumi ir baigiant 11 skyriumi „Projekto

bendrojo plano rengimas“, nagrinėjami visi projektų planavimo klausimai. Šis skyrius skirtas

projekto apimties planavimo klausimams.

Projekto apimtis – tai įvykdyti reikalingų darbų kiekis ir dydis. Projekto vadovas turi

žinoti, kokius darbus reikės atlikti projekto eigoje. Apimties planavimas padeda apibrėžti

reikiamą išteklių kiekį ir nustatyti projekto ribas (terminus, kainą, kokybę).

Projekto apimties planavimas siejamas su šių trijų dokumentų parengimu (apimties plane

turi būti šios trys dalys):

- apimties aprašo;

- apimties valdymo plano;

- suskaidytų darbų lentelės (WBS – Work Breakdown Structure).

Apimties apraše pateikiama bendroji projekto samprata, tikslai, laukiami rezultatai

(deliverables). Apimties valdymo plane išaiškinamos procedūros, kurių reikės laikytis norint

daryti kokius nors siūlomus projekto apimties pakeitimus viso jo gyvavimo ciklo bėgyje.

Suskaidytų darbų lentelėje projektas padalinamas į smulkius darbus (užduotis), kad lengviau

būtų įvertinti jų trukmę, reikalingus išteklius, išlaidas.

3.1. Projekto apimties plano struktūra

Projektų valdyme yra savos taisyklės ir procedūros, kurios padeda projektų vadovams

apibrėžti projektų ribas. Projekto apimties planas būtent ir padeda nustatyti projekto ribas.

Prastai apibrėžta projekto apimtis gali būti neteisingų galutinių laiko terminų nustatymo, išlaidų

viršijimo ir klientų nepasitenkinimo priežastis. Geras projekto apimties planas reiškia, kad dėl

projektui įvykdyti reikalingų darbų yra susitarta su akcininkais ir tai yra aiškiai dokumentuota.

Apimties planavimo metu gimsta detalės, kuriomis papildomi inicijavimo etape parengti

projekto nuostatai. Tai darbų, reikalingų projekto nuostatuose nurodytiems tikslams pasiekti,

įvardinimas.

Priklausomai nuo projekto nuostatų detalumo, apimties planavimo metu gali būti

atliekama smulki numatomo sukurti produkto ir projekto naudos / kainos santykio analizė,

siūlomi alternatyvūs sprendimai. Dalis apimties planavimo darbo gali jau būti atlikta projekto

inicijavimo metu, rengiant projekto nuostatus.



38

Projekto apimties planavimo procesas gali būti iteracinis, ne visai nuoseklus, žingsniai

persidengiantys. Nežiūrint nuoseklumo, planavimo eigoje turi būti sukurtas projekto apimties

aprašas, apimties valdymo planas ir suskaidytų darbų lentelė (WBS). Apžvelkime plačiau

kiekvieną iš jų.

3.1.1. Projekto apimties aprašas

Projekto apimties aprašo rengimo metu dokumentuojami susitarimai tarp projekto

vadovo ir akcininkų dėl projekto rezultatų. Aprašas yra įeities duomenys projekto darbų sąrašui

apibrėžti ir bus atramos taškas nagrinėjant siūlymus kažką keisti projekte. Bet kuris pagrindinis

projekto rezultatas, savybė ar funkcija, kurie nebuvo užfiksuoti projekto apimties apraše,

iššaukia projekto keitimus. Dažniausiai projekto apimties aprašą sudaro tokios dalys:

- projekto poreikis;

- projekto reikalavimai;

- pagrindiniai laukiami projekto rezultatai;

- sėkmės kriterijai;

- projekto trukmės ir kainos metmenys;

- prielaidos;

- apribojimai.

Trumpai apžvelkime kiekvieną iš šių dalių.

Projekto poreikis. Šioje projekto apimties aprašo dalyje nurodomos priežastys, dėl ko yra

vykdomas projektas ir kokius organizacijos poreikius numatoma juo patenkinti. Juk turi būti

aiškios prašymo pradėti projektą priežastys. Ar juo bus kuriamas naujas produktas išorės

užsakovui, ar bus kuriama nauja sistema vidinėms organizacijos reikmėms patenkinti, ar yra

teisinis pagrindimas. Projekto poreikio dalyje išdėstomi prašymo pradėti projektą argumentai.

Labai svarbu, kad visi teisės aktai, kuriais yra paremtas prašymas pradėti projektą, būtų

išvardinti šioje projekto apimties aprašo dalyje. Tai priverčia suklusti kiekvieną apimties aprašo

skaitytoją dėl projekto būtinumo.

Projekto reikalavimai. Projekto reikalavimuose aprašomos numatomo kurti produkto

savybės ir funkcijos, akcentuojama, kas naujo bus sukurtame produkte. Tai papildyti, detalizuoti

reikalavimų metmenys, kurie buvo projekto nuostatuose (žiūr. 2.1.1, 2.1.3 skyrius). Projekto

reikalavimuose gali būti naudinga išvardinti ne vien numatomo kurti produkto savybes ir

funkcijas, bet ir kitas, jei nuo to reikalavimai tampa aiškesni. Tam gali būti panaudoti anksčiau

vykdytų projektų aprašuose esantys reikalavimai, atlikus juose pakeitimus ar patobulinimus

naujai gautos informacijos pagrindu.

Pagrindiniai laukiami projekto rezultatai. Projekto apimties aprašo pagrindinių laukiamų

rezultatų dalyje pateikiama suvestinė lentelė rezultatų, kurie turi būti gauti kuriant produktą.

Sudaryti svarbiausių rezultatų sąrašą gali būti lengva, jei turėsime galvoje tik juos. Tačiau

vardinant drauge visus projekto rezultatus, nereikėtų pamiršti galutinio produkto visumos. Pvz.,

galutinis rezultatas gali būti organizacijos pardavimų agentams skirta taikomoji programa. Bet

šalia taikomosios programos reikalinga ir programos naudojimo instrukcija (naudotojo vadovas),

naudotojų mokymas, pagalbos teikimo priemonės, kt.



39

Sėkmės kriterijai. Kaip sėkmės kriterijai projekto apimties apraše turi būti nurodomi

veiklos srities, kurios reikmėms yra vykdomas projektas, pagerėjimo rezultatai. Šių rezultatų

pasiekimo laipsnį turi būti galima įvertinti kiekybiškai. Tai gali būti tokie kriterijai, kaip bendras

pajamų padidėjimas, darbo našumo padidėjimas, atitikimas teisės aktams, darbuotojų kiekio

sumažėjimas. Ši apimties aprašo dalis yra svarbi tuo, kad ji gali būti panaudota kaip projekto

vertinimo instrumentas pabaigus jį. Projekto akcininkai, remdamiesi šia aprašo dalimi, gali

palyginti tikrąjį projekto poveikį jų veiklai su planuotu. Sėkmės kriterijai turėtų būti apibrėžiami

taip, kad atitikimą jiems galima būtų išmatuoti. Tokie kriterijai, kaip, pvz., „tapome pirmaujantys“

arba „teikiame aukšto lygio paslaugas“ skamba gražiai, bet nėra pamatuojami. Kur kas geriau

nurodyti pardavimų kiekio skaičių, pajamų dydį arba klientų gaištamo laiko trukmę, ką galima

išmatuoti ir palyginti su tokiais pat duomenimis, buvusiais iki projekto įvykdymo. Sėkmės

kriterijų nurodymo prasmė yra ta, kad žmonės turėtų matavimo būdus vertindami, ar projektas

buvo sėkmingas ar ne.

Projekto užbaigimo kriterijus. Projekto užbaigimo kriterijus reikalingas tam, kad galėtume

nuspręsti, kada laikysime projektą užbaigtu. Pvz., projekto apimties apraše gali būti reikalaujama,

kad pridavimo metu sistema turi veikti be jokių priekaištų. Arba, gali būti toks reikalavimas, kad

projektas bus laikomas užbaigtu, jei bandomojo periodo (mėnesio ar kelių) bėgyje visi sistemos

komponentai veiks be sutrikimų.

Projekto trukmės ir kainos metmenys. Šiame projekto apimties aprašo skyriuje nurodomi

laiko, kurio reikės visiems projekto darbams atlikti, ir dabartinės projekto kainos metmenys. Tai

labai svarbūs duomenys, kurie gaunami remiantis panašiems jau vykdytiems projektams realiai

sugaištu laiku ir patirtomis išlaidomis arba laikantis kurio nors į projektą įtraukto ir patirtį

panašiuose darbuose turinčio eksperto nuomonės. Tai nėra tikslūs įverčiai. Gali būti nurodomas

projekto trukmės ir kainos intervalas, atspindintis geriausią, blogiausią ir labiausiai tikėtiną

reikšmę.

Jeigu reikia nurodyti projekto pabaigos datą, o tiksliam jos įvertinimui jūs neturite

pakankamai duomenų, nurodykite mėnesį ar metų ketvirtį, bet ne tikslią datą. Nurodydami

projekto pabaigos datą, visada nurodykite ir numatomą projekto pradžios datą, nes gali atsitikti

taip, kad vėluojant pradėti projektą jo vykdymui liks mažiau laiko.

Projekto trukmės ir kainos metmenų tikslumu, gautu projekto apimties planavimo

laikotarpiu, gali būti abejojama. Tačiau projekto vadovas neturėtų sakyti, pvz., kad metmenimis

pasitiki 90%. Sponsorius ar klientai, žinoma, norėtų girdėti tokius patikinimus. Projekto apimties

planavimo laikotarpiu gauti kainos metmenys būna nukrypę iki 75% nuo tikrosios projekto

kainos jo pabaigoje. Tokia yra IT projektų realybė (kitų sričių projektuose taip nėra).

Prielaidos. Prielaida – tai veiksmas, sąlygos ar įvykis, kurio tikimasi. Prielaidų

problema yra ta, kad jos nėra vienodos visiems projekto grupės nariams ar akcininkams.

Prielaidos turi būti išplatintos, dėl jų susitarta ir dokumentuota. Pvz., kuriant kažkokią sistemą

projekto vykdytojai gali manyti, kad ji bus diegiama pas užsakovą jau esančiuose kompiuteriuose,

o užsakovas gali galvoti, kad ir kompiuteriai yra projekto dalis, kad kartu su programomis bus

pateikti ir kompiuteriai.



40

Apribojimai. Yra dviejų tipų apribojimai: taikomi visam projektui ir specifiniai projekto

apribojimai. Su pirmojo tipo apribojimais, kurie susiję su laiku, kaina, kokybe ir/ar apimtim,

susiduriama beveik kiekviename projekte. Kiekviename projekte reiškiasi mažiausiai vienas iš

šių apribojimų. Jei jūs kuriate produktą siaurai rinkai, projektui gaištamas laikas gali būti stipriai

ribojantis veiksnys. Jei turite fiksuoto dydžio biudžetą, pinigai bus ribojantis veiksnys. Jei darbus

riboja kartu ir laikas, ir pinigai, tuomet gali nukentėti kokybė. Projekto apimtį taip pat gali riboti

kartu ir laikas, ir pinigai. Kai projekto eigoje sumanoma keisti projekto apimtį, apimtis tampa

ribojančiu veiksniu (žymiai keisti apimties negalėsime), nes tai iššaukia laiko, kainos arba

kokybės pokyčius.

Antrojo tipo apribojimai yra specifiniai. Jie gali būti susiję su projekto darbų grafiku,

ankstesniais susitarimais dėl žmoniškųjų išteklių, sistemos testavimo galimybėmis.

Su apribojimų „stumdymu“ projekto vadovas susiduria viso projekto metu. Kai projekto

planavimo etape nustatomi laiko, kainos, apimties, kokybės apribojimai, reikia susitikti su

akcininkų grupe ir aptarti apribojimų poveikį projektui. Projektų vadovas turi žinoti, kokiems

apribojimams klientai teikia prioritetą, ir būti pasirengęs tinkamai reaguoti į juos. Pvz., žinodami

projekto planavimo etape numatytą kainą, klientai gali prašyti mažinti funkcionalumą, mažinti

apimtį, peržiūrėti kainą ir nustatyti jiems labiau priimtiną.

Taigi, projekto apimties apraše yra daug svarbios projekto informacijos.

Apimties aprašo peržiūra ir pritarimas jam

Baigus rengti projekto apimties aprašą, šaukiamas visos projekto grupės susirinkimas ir

išsiaiškinama, ar visi nariai pritaria aprašo nuostatoms, ar neliko neišspręstų klausimų. Pašalinus

visus nesutarimus, su aprašu supažindinami visi akcininkai ir reikia gauti sponsoriaus ir klientų

patvirtinimą. Priklausomai nuo jūsų organizacijoje esančių taisyklių, gali reikėti ir kitokių

patvirtinimų.

Jeigu sponsorius ir klientai peržiūros metu daro kokius nors projekto apimties pakeitimus,

jūs turėtumėte šaukti dar vieną projekto grupės susirinkimą ir apsvarstyti šių pakeitimų poveikį

projektui. Projekto vadovo viena iš svarbiausių pareigų yra projekto grupės narių informavimas.

Apie komunikavimą su grupe plačiau rašoma 9.2 skyriuje.

3.1.2. Projekto apimties valdymo planas

Apimties valdymo plane aprašomos procedūros, kurių reikės laikytis norint daryti bet

kokius projekto apimties pakeitimus viso jo gyvavimo laikotarpiu. Apimties valdymas yra

sudėtingas procesas, apimantis visų keitimų įvardinimą, dokumentavimą, valdymą, įvertinimą,

kontrolę ir patvirtinimą.

Apimties valdymo procesui, mažiausiai, reikalingi:

- standartinės formos prašymas keitimams daryti;

- prašomo keitimo poveikio kitiems projekto elementams (kainai, darbų grafikui,

kokybei) analizė;

- prašymo priėmimo arba atmetimo procedūra;

- akcininkų informavimo apie keitimus planas;

- projekto bendrojo (viso) plano koregavimo būdas.



41

3.1.3. Projekto suskaidytų darbų lentelė

Projekto suskaidytų darbų lentelėje (WBS–Work Breakdown Structure) nurodomi

pagrindiniai projekto darbai, suskaidyti į smulkesnes, lengviau valdomas dalis. WBS skaidomas į

keletą lygių tol, kad lygio darbų įvykdymo laipsnį galima būtų išmatuoti ir būtų aišku, kokio

finansavimo jiems reikėtų. Kiekvieno žemesnio lygmens darbų rezultatai naudojami aukštesnio

lygmens darbe. Žemiausią WBS lygmenį sudaro darbų paketas (work package). WBS‘e turi būti

visi darbai, kurių reikia projektui įvykdyti. Bet koks WBS‘e nenurodytas darbas laikomas

nereikalingu projekte. WBS yra vertingiausias planavimo rezultatas. WBS yra projekto trukmės ir

kainos vertinimo, reikiamų išteklių skyrimo pagrindas.

WBS struktūra. WBS lentelėje darbai turi turėti pavadinimus, gali būti ir numeruojami.

WBS su numeruojamais darbais parodytas 3.1 pav.

WBS lentelėje darbai skaidomi į lygius, kur 1 lygis – tai pats projektas (jo pavadinimas). 2

lygio darbai susiję su pagrindiniais laukiamais rezultatais, kurie išvardinti projekto apimties

apraše. Šis lygis parodo projekto etapus, į projektą įtrauktus organizacijos departamentus ar

geografinius dalykus.

WBS rengimo gairės. WBS sudarymas kartais gali atrodyti labai sunkus, neįveikiamas

darbas. Dauguma žmonių, kurie susiduria su šia užduotim, imasi didesnio darbo, nei jie gali

atlikti. Kai jūs pradedate siekiamus projekto rezultatus transformuoti į darbus, yra pagunda

dėlioti darbus iš eilės, vertinti jų trukmę. Elgiantis taip, dažniausiai pamirštami (praleidžiami)

svarbūs siekiami rezultatai arba sudaroma neteisinga darbų eilė. Kad nebūtų neproduktyviai

gaištamas laikas, siūloma vadovautis čia pateikiamomis gairėmis.

Pasitelkite išmanančius žmones. Nesistenkite sudaryti WBS patys, siekdami sutaupyti

laiko.

Visus 2 lygio punktus apgalvokite kruopščiai. Turime suprasti, kad viso projekto siekiamų

rezultatų metmenys (high-level deliverables) atspindimi šiame lygyje. Kol neįvardinti siekiami

rezultatai, tol nereikėtų pradėti jų skaidyti į smulkesnius komponentus. Visą laiką turi būti

remiamasi projekto apimties aprašu.

Projektas

2. Darbų grupė 3. Darbų grupė

1.1. Darbas

1.2. Darbas

1.3. Darbas

2.1. Darbas

2.2. Darbas

3.1. Darbas

3.2. Darbas

3.3. Darbas 2.2.1. Darbelis

2.2.2. Darbelis

1 lygis

................

2 lygis

................

3 lygis

................

t. t.

1. Darbų grupė

3.1 pav. WBS su numeruojamais darbais



42

Kiekvienas žemesnio lygio punktas yra aukščiau esančio lygio komponentas. Surašykime

visus darbus ir tęskime jų skaidymą į komponentus. Įsitikinkime, kad jau pasiekėme tokį lygį, kai

grupės nariai jau yra patenkinti ir kad gali būti rengiami projekto trukmės, kainos ir reikiamų

išteklių įverčiai. Darbų eilės nustatymas, išteklių numatymas, projekto trukmės ir kainos įverčių

gavimas yra atskiros veiklos, kurios vykdomos vėliau, kai baigiama rengti WBS.

Nekurkime pernelyg susmulkintų darbų lentelės. Darbų skaidymas yra pakankamo lygio,

kai jau lengvai galima numatyti konkrečiam darbui reikalingus išteklius, daryti jo įverčius ir

įvardinti siekiamą rezultatą. Kadangi WBS yra vėliau sudaromo darbų grafiko pagrindas,

nenusileiskime iki tokio lygio, kad nebegalėtume kontroliuoti tokių darbų. Pvz., jei projekte reikia

pirkti kažkokias medžiagas, WBS‘e pakanka nurodyti darbą „Medžiagų pirkimas“ ir nereikia

smulkintis iki to, kiek ir kokias medžiagas pirkti.

Patartina naudoti 8/80 taisyklę. Ji sako, kad darbai neturėtų būti trumpesni kaip 8

valandos (viena darbo diena) ir ilgesni kaip 80 valandų.

Kiekvieną punktą skaidykime į tinkamą lygių kiekį.

Naudokime skaitinius numerius kiekvienam WBS punktui. Pvz., 1., 1.1., 1.1.1.

WBS nauda. WBS yra vertingiausias planavimo rezultatas. WBS yra projekto trukmės ir

kainos vertinimo, reikalingų išteklių skyrimo pagrindas. Tai puikus instrumentas, padedantis

bendrauti projekto grupės nariams, bendrauti su užsakovu, stebėti projekto eigą, skiriamus

išteklius, t. t. Gerai parengta WBS gali pasitarnauti kaip šablonas kitiems projektams. Detali WBS

ne tik padeda išvengti neapsižiūrėjimų (užmiršimų), bet ir padeda kontroliuoti daromus projekto

apimties keitimus. Žinoma, tokiais atvejais tenka koreguoti ir WBS.

3.2. IT projekto apimtį įtakojantys veiksniai

Projektų vadovai neturėtų labai nukrypti nuo WBS‘e išvardintų darbų vykdymo. Tačiau

projektus vykdančiose IT įmonėse gali atsirasti priežasčių, verčiančių jas žymiai nukrypti nuo

originalios projekto apimties. Tos priežastys ar aplinkybės neturėtų būti pamestos iš akiračio

projekto apimties vertinimo ir planavimo metu. Panagrinėkime kai kurias iš jų.

3.2.1. IT įmonės dydis

IT įmonės dydis turi tiesioginę įtaką projekto apimčiai. Jei jūsų įmonėje yra tik keletas

darbuotojų, kurie nuolatos dirba tai viename, tai kitame projekte, tai visiškai suprantama, kad

naujo projekto apimtis smarkiai priklausys nuo darbuotojų užimtumo. Pagrindinis ribojantis

veiksnys yra žmoniškieji ištekliai. Jei įmonėje vykdomi keli projektai, mažesnį prioritetą turintys

nustumiami į antrą planą. IT projektuose, kuriuos vykdo minimalus darbuotojų kiekis, dažnai

prastai suformuluojami reikalavimai, prastai parengiama suskaidytų darbų lentelė (WBS), retai

kada prisimenamas kuriamų programų dokumentavimo klausimas. Kad to nebūtų, reikėtų

mažinti projekto apimtį.

3.2.2. Projekto siekiamų rezultatų apibrėžimo tikslumas

Tiksliai apibrėžti projekto siekiamus rezultatus, kuriems gauti yra aiškūs reikalavimai,

nėra sunku. Bet apibrėžti mažai kam suprantamus rezultatus gali būti sunku. Pvz., jūs turite

projektą, kuriuo esamą sistemą reikia pakeisti tobulesne. Kokie bus laukiami projekto rezultatai?



43

Tarkime, tai bus naujas serveris ir, tikriausiai, nauja programinė įranga. Tačiau nereikėtų

pamiršti ir kitų dalykų. Senus duomenis reikės konvertuoti į naują formatą, reikės parengti naują

naudotojo instrukciją, apmokyti žmones, kt. O tam juk reikia ir laiko, ir lėšų. Taigi, būtina matyti

siekiamų rezultatų visumą. Netiksliai apibrėžti siekiami rezultatai atsiliepia projekto apimties

kokybei, dėl ko projekto vykdytojas bus priverstas nukrypti nuo WBS‘e numatytų darbų.

3.2.3. Darbo su užsakovu aplinkybės

Projekto vykdytojas dažniausiai nėra užsakovo organizacijos narys, o tik aptarnauja jį. Dėl

to jis negali turėti didelės įtakos projekto apimčiai. Įsivaizduokime, kad užsakovas prarado

interesą projektu pusiaukelėje. Kadangi užsakovo organizacijos vadovas yra vienas iš projekto

sponsorių, jūs, tikriausiai, negalėsite patenkinamai atlikti darbų be jo paramos.

Arba, įsivaizduokime užsakovą, kuris dėl didelio savo užimtumo nepajėgia teikti projekto

vykdytojams reikiamos pagalbos, kad kuriamas produktas atitiktų jo poreikius. Sunku tikėtis, kad

projekto vykdytojai žinotų užsakovo poreikius, jei negauna duomenų iš tų, kurie tą darbą dirba

kasdieną. Deja, yra nemažai taip vykdomų projektų, todėl jų rezultatai būna prasti.

Būna, kad užsakovas pats ieško gatavos (COTS) programinės įrangos, randa jo manymu

jam tinkančią, tačiau paskutinę minutę persigalvoja ir kreipiasi į jus su prašymu sukurti naują

programą. Tokio užsakovo supratimas apie projekto apimtį gali labai skirtis nuo jūsiškio.

Tokioms arba panašioms situacijoms valdyti, jūs galite dėti atitinkamas nuorodas į

projekto apimties aprašo prielaidų skyrių. Pvz., „Daroma prielaida, kad užsakovas skiria projekto

grupei vieną savo atstovą, kuris dirbs visą darbo dieną pirmus 30% projekto laiko“.

3.2.4. Sėkmės kriterijų apibrėžimo sunkumas

Tarkime, jūs kuriate internetinę el. komercijos programinę įrangą. Vienas iš jos

reikalavimų yra aukštas transakcijų saugumas. Kaip įvertinti tokio reikalavimo įgyvendinimo lygį

ir įrodyti, kad sistema yra saugi? Dar daugiau, kas atsitinka, kai sistemos kūrimo įkarštyje

operacinės sistemos kūrėjas atskleidžia jos saugumo spragas, kurios turi būti pašalintos? Kokią

įtaką tokios naujienos turi jūsų kuriamai sistemai? Ar spragų užlopymas turės įtakos jūsų

sistemos darbui?

Panašūs klausimai kyla, kai reikia rengti metines ataskaitas vadovybei. Kartais sunku būna

rasti matą savo veiklos dydžiui apibūdinti. Tačiau jūs turite tiksliai nurodyti realias priežastis,

kodėl jūs vykdote projektą, kaip užsakovas tikisi panaudoti gautus rezultatus.

3.2.5. Pašaliniai ar neišsiaiškinti elementai

Didžiausios įtakos projekto apimties įverčio tikslumui turi neišsiaiškinti užsakovo veiklos

procesai, kai užsakovas neatskleidžia (ne iš piktos valios) visų savo organizacijos

automatizavimo elementų, transakcijų su kitomis sistemomis, turimų pagalbinių duomenų bazių,

programinės įrangos ar panašiai.

3.2.6. Santykiai su tiekėjais

Naudojantis tiekėjų paslaugomis, nepamirškime, kad jie gali turėti ir kitų užsakymų. Tie

užsakymai iš jų gali pareikalauti laiko, ir jie atidėlios jūsų projekto darbus. Dėl to gali nukentėti

jūsų projekto apimties įverčiai.



44

3.2.7. Projekto grupės narių pasitraukimas

Pagrindinio grupės nario pasitraukimas gali turėti žymų poveikį projekto apimčiai (grupė

kažko nebesugebės padaryti per numatytą laiką ar už sutartą kainą). Kai WBS užduotys būna

išdalintos, ar rasime, kas pakeistų išėjusį darbuotoją?

Vėlgi, projekto apimties aprašo prielaidų dalyje reikėtų nurodyti, kad projekto apimtis

numatyta, tikintis, kad reikiamos kvalifikacijos specialistai bus rasti.

3.2.8. Projekto darbų dalinimas keliems IT padaliniams

Didelėse organizacijose gali būti keletas IT padalinių, aptarnaujančių skirtingas veiklos

sritis. Pvz., organizacijoje gamybos departamentas gali būti toks didelis, kad turi savo IT padalinį.

Taip pat gali būti su teisės departamentu. O jūs vadovaujate dar kitam IT padaliniui. Tarkime, jūs

vykdote projektą, kurio pagrindiniai rezultatai reikalingi visiems organizacijos departamentams.

Jums reikalinga kitų IT padalinių pagalba, kad galėtumėte patenkinti visų sistemos naudotojų

poreikius.

Tokiais atvejais projekto valdymas įgyja politinį diplomatinį atspalvį, ir jūs turite įtikinti IT

padalinius bendradarbiauti, nors šiaip jie nedirba kartu. Suprantama, kad projekto apimčiai

įtakos turės kiekvieno IT padalinio prioritetai projekto atžvilgiu.

3.2.9. Testuojami elementai reikalauja gero apibrėžimo

Daugumos IT projektų elementai yra testuojami, kad įsitikintume, ar jie atitinka jiems

keliamus reikalavimus. Yra trys testavimo atvejai: atskiro vieneto testavimas, integracinis

testavimas ir priėmimo testavimas.

Atskiro vieneto testavimas. Tai sistemos modulio ar komponento, įvardinto bendrame

rezultatų sąraše, testavimas. Pvz., serverio administratorius, instaliuodamas serverį, turi atlikti

daug testų, kad įsitikintų, jog serveris dirba taip, kaip reikia. Programuotojas, užbaigę modulį, turi

leisti įvairius testus, kad įsitikintų, jog modulis dirba taip, kaip tikėtasi. Atskiro vieneto

testavimas paprastai suprantamas kaip vieno žmogaus atliekamas vieno kokio nors elemento

testavimas. Tai nėra griežta taisyklė, o tik aiškinimas, kas yra atskiro vieneto testavimas.

Integracinis testavimas. Šiuo testavimu tikrinamas tarpusavyje sujungtų elementų

visumos veikimas. Pvz., turite keletą serverių, kurie jau yra instaliuoti, tačiau jie turi veikti

drauge, kaip subalansuotų Web serverių masyvas. Šie serveriai testuojami kaip visuma, o ne kaip

atskiri vienetai. Programuotojų komanda gali testuoti keletą modulių, kurie sujungti drauge

sudaro užbaigtą programinį elementą.

Priėmimo testavimas. Tai galutinio produkto, t. y. visos sukurtos sistemos testavimas,

kurį atlieka paskirti naudotojai. Tai svarbiausias iš visų testavimų, nes jis parodo, kaip projekto

grupė atliko savo darbą, kaip naudotojams sekasi sąveikauti su sistema. Reikia būti

pasirengusiems labai griežtam jūsų sukurto produkto vertinimui.

Jei bet kuriame testavimo žingsnyje kas nors neveikia taip, kaip turėtų, atsakingi už tai

darbuotojai, žinoma, turi ištaisyti klaidą. Rimtos testavimo klaidos be abejo veda prie to, kad

reikės gaišti laiką ir leisti pinigus, stengiantis išspręsti problemą. Dėl to projektų vadovai pritaria

idėjai, kad sukurtą produktą turi tikrinti ne vienas, o keli patikimi asmenys. Taip jie būtų tikri, jog

atliktas darbas atitinka įvertinimą.



45

4. DARBŲ GRAFIKO PLANAVIMAS

Turint jau parengtą projekto apimties aprašą, apimties valdymo planą ir suskaidytų darbų

lentelę (WBS), planavimo etape toliau reikia rengti projekto darbų grafiką. Darbų grafike

nurodoma planuojama darbų pradžia ir pabaiga. Geram darbų grafikui parengti sugaištama

nemažai laiko. Būtina suvokti, kokių žinių reikia, kad parengtume gerą darbų grafiką. Visi darbai

turi būti įvardinti, sudėlioti reikiama eilės tvarka, kažkam paskirti, įvertinti laikai jiems atlikti.

Taip gimsta bendras projekto darbų grafikas.

Darbų grafikas projekto vadovui yra reikalingas nuolatos, kol nebus baigtas projektas.

Laikydamasis grafiko, vadovas reguliariai informuoja akcininkus apie projekto eigą.

Projekto darbų grafiko rengimo pagrindas yra WBS, kuri buvo sudaryta projekto apimties

planavimo metu. Faktiškai tuomet buvo apibrėžti darbai. Apibrėžiant juos buvo remiamasi

numatytais projekto galutiniais ir tarpiniais rezultatais.

Prisimenant WBS rengimą, atkreiptinas dėmesys į tai, kad darbų sąrašo smulkinimas, pvz.,

vardijant net 15 min. trukmės darbelius, negarantuoja sėkmingos projekto pabaigos, ir to

nereikėtų daryti. Tai tik apsunkina jų valdymą. Patartina naudoti 8/80 taisyklę. Ji sako, kad

darbai neturėtų būti trumpesni kaip 8 valandos (viena darbo diena) ir ilgesni kaip 80 valandų.

Pagrindinis darbų skaidymo tikslas yra įvardinti visas užduotis tokiu lygmeniu, kad galima

būtų lengvai įvertinti jų atlikimo trukmę ir kainą ir kad nesunku būtų juos kontroliuoti.

4.1. Darbų eilės tvarka

Projekto vadovui būtų lengva, jei visus projekto darbus būtų galima vykdyti lygiagrečiai.

Reikėtų tik kiekvienam projekto grupės nariui nurodyti darbų sąrašą, už kuriuos jis yra

atsakingas, ir kuriuos atlikęs jis galėtų grįžti prie savo ankstesnių pareigų organizacijoje.

Kiekvienas grupės narys turėtų įvertinti laiką, reikalingą jam pavestiems darbams atlikti. Tuomet

viso projekto pabaigos terminas priklausytų nuo ilgiausiai planuojančio dirbti grupės nario. Deja,

numatyti projekto pabaigos terminą nėra taip paprasta. Dalis projekto darbų negali būti pradėti

tol, kol nebus baigti kai kurie kiti darbai. Projekto grupė turi įvardinti darbų priklausomybę ir

nurodyti sąryšio pobūdį tarp dviejų darbų.

Darbų eilės tvarkos nustatymas yra priklausomybės tarp projekto darbų nustatymo

procesas. Visų pirma įvardinamas priklausomybės tipas, o po to nustatomas priklausomybės

pobūdis tarp dviejų darbų. Naudojant šiuos duomenis gaunamas visų priklausomybių vaizdas.

Pirma apžvelkime darbų priklausomybių tipus, o po to priklausomybių pobūdį.

4.1.1. Darbų priklausomybių tipai

Sudarant projekto darbų eilę, susiduriama su trimis darbų priklausomybės tipais.

Privalomoji priklausomybė atsiranda dėl projekte būtinos darbų sekos. Pvz., ryšio kabelių

tiesimo brigada negali patiesti kabelio, kol kita brigada nebus iškasusi griovio.

Laisvai pasirenkama priklausomybė yra tokia, kuriai atsirasti įtakos turi norimas gauti

darbų grafikas. Pvz., tai gali būti sprendimas vykdyti darbus specifine eilės tvarka, kad ji atitiktų

kolektyve nusistovėjusią tvarką, nors ir galima kita darbų eilės tvarka.



46

Išorinė priklausomybė pasireiškia tarp projekte numatyto darbo ir išorinių veiksnių,

turinčių įtakos to darbo atlikimo grafikui. Pvz., naujo serverio paleidimas gali priklausyti nuo to,

kada pardavėjas jį pristatys.

Darbų priklausomybių tipo žinojimas ateityje gali praversti ieškant būdų projekto trukmei

sutrumpinti.

4.1.2. Darbų priklausomybės pobūdis

Nepakanka žinoti, kad tarp dviejų darbų yra priklausomybė. Reikia mokėti atsakyti dar ir į

keletą kitokių klausimų: kokią įtaką priklausomybė daro kiekvieno darbo pradžiai ir pabaigai? Ar

vienas iš darbų turi būti pradėtas anksčiau? Ar galima pradėti kitą darbą, kol nebaigtas pirmasis?

Visi šie klausimai turi įtakos visam darbų grafikui.

Žinant priklausomybę tarp dviejų darbų, reikia nustatyti jos pobūdį (kokią įtaką

priklausomybė daro kiekvienam iš tų dviejų darbų), kad galėtume sudaryti teisingą darbų eilę.

Priklausomybės pobūdžiui paaiškinti įveskime keletą sąvokų.

Pirmuoju darbu (predecessor) vadinkime darbą, kuris iš dviejų priklausomybe susietų

darbų turi būti pradėtas pirma. Antruoju darbu (successor) vadinkime tą, kuris yra susijęs su

pirmuoju.

Galimi keturi pirmojo ir antrojo darbų priklausomybės pobūdžiai. Teisingo pobūdžio tarp

priklausomų darbų nustatymas yra labai svarbus, norint sudaryti tikslų darbų grafiką.

Priklausomybės pobūdis įgalina rikiuoti darbus grafike taip, kad jie būtų atliekami lygiagrečiai

arba kad antrasis būtų atliekamas tik po to, kai bus užbaigtas pirmasis. Klaidingas darbų grafikas

gali sukelti liūdnas pasekmes.

Pabaigos-pradžios priklausomybės pobūdis yra toks, kai antrasis darbas negali būti

pradėtas anksčiau, kol nebus užbaigtas pirmasis. Šio pobūdžio priklausomybės sutinkamos

dažniausiai.

Pradžios-pradžios pobūdžio priklausomybėje antrojo darbo pradžia priklauso nuo

pirmojo darbo pradžios. Tokie darbai gali būti atliekami lygiagrečiai, tačiau jei pirmasis darbas

vėluoja, antrasis negali būti pradėtas. Pvz., sistemos naudotojo instrukcijos rengimas gali būti

pradėtas tuo pačiu metu, kai pradedami rengti sistemos reikalavimai. Jei vėluojama pradėti rengti

reikalavimus, reikia atidėti ir naudotojo instrukcijos rengimą.

Pabaigos-pabaigos pobūdžio priklausomybė yra tokia, kai antrojo darbo pabaiga priklauso

nuo pirmojo darbo pabaigos. Pvz., naujo produkto kūrimas laikomas baigtu, jei yra parengti ir

produkto dokumentai. Jei vėluojama parengti dokumentus, produkto išleidimas atidedamas.

Pirmasis darbas

Antrasis darbas

Pirmasis darbas

Antrasis darbas

Pirmasis darbas

Antrasis darbas



47

Pradžios-pabaigos pobūdžio priklausomybė rodo, kad antrojo darbo pabaiga priklauso

nuo pirmojo darbo pradžios. Tokia priklausomybė sutinkama retai. Pvz., techninė priežiūra

negali būti pabaigta, kol nebus pradėta formuoti priežiūros grupė.

Žinodama darbų priklausomybių pobūdžius, projekto grupė gali sudaryti darbų išdėstymo

diagramą.

4.1.3. Darbų išdėstymo diagrama

Darbų išdėstymas PDM diagrama (PDM –Precedence Diagramming Method; kitur AON –

Activity On Node ) yra vienas iš būdų pavaizduoti darbų eilės tvarką (žiūr. 4.1 pav.). Joje darbai

nurodomi stačiakampiuose, o priklausomybės tarp jų - rodyklėmis.

Dar vienas darbų išdėstymo vaizdavimo būdas yra ADM diagrama (ADM – Arrow

Diagramming Method; kitur AOA - Activity On Arrow). Jis yra paprastesnis už PDM ir naudojamas

tik pabaigos-pradžios pobūdžio priklausomybės darbams. Šiame vaizdavimo būde darbai

nurodomi ant rodyklių. 4.2 pav. parodyta darbų išdėstymo ADM diagrama, atitinkanti 4.1 pav.

PDM diagramą.

4.2. Darbų trukmės vertinimas

Darbo trukmės vertinimas - tai reikalingo dienų ar savaičių kiekio darbui atlikti

nustatymas. Tačiau visų pirma patikslinkime trukmės sąvoką.

4.2.1. Trukmės apibrėžimas

Darbo atlikimo trukmė apima bendrąjį kalendorinį laiką (įskaitant laisvadienius ir švenčių

dienas). Jei darbui atlikti reikia 4 darbo dienų, bet jis pradedamas, pvz., ketvirtadienį, tai jo

pabaiga bus kitos savaitės antradienis. Taigi, darbo trukmė bus šešios dienos. Pailiustruokime tai

grafiškai.

Pirmasis darbas

Antrasis darbas

A darbas Pradžia

B darbas C darbas

D darbas

Pabaiga

4.2 pav. Darbų išdėstymo ADM diagrama

A darbas Pradžia B darbas C darbas

D darbas

Pabaiga

4.1 pav. Darbų išdėstymo PDM diagrama



48

Darbo trukmė perskirta savaitgaliu: 6 kalendorinės dienos, 4 darbo dienos

ketvirtadienis penktadienis šeštadienis sekmadienis pirmadienis antradienis

Nustatant darbų atlikimo terminą nereikėtų pamiršti laisvadienių, šventinių dienų ir netgi

darbuotojų atostogų.

4.2.2. Trukmės vertinimo būdai

Analogiškasis arba iš viršaus-žemyn būdas. Šis darbų trukmės vertinimo būdas remiasi

anksčiau vykdytų projektų panašiems darbams realiai sugaišto laiko perėmimu. Projekto

planavimo pradinėje stadijoje, kai apie projektą turima informacija yra ribota, tai yra dažniausiai

naudojamas darbų trukmės vertinimo būdas. Tai mažiausio tikslumo būdas, nes du projektai

nebūna tiksliai tokie patys. Todėl yra rizika, kad naujam projektui naudojami ankstesnių projektų

analogiškų darbų trukmės įverčiai gali būti netikslūs.

Analogiškojo vertinimo rezultatų tikslumas yra didžiausias, kai darbų trukmę vertinantis

asmuo yra gerai susipažinęs su dabartiniu ir ankstesniu projektais ir gali suvokti panašių darbų

trukmėms įtaką turinčių veiksnių skirtumus.

Ekspertinis būdas (rėmimasis ekspertų nuomone). Šiuo atveju darbų trukmei nustatyti

pasitelkiami projekto darbus gerai išmanantys žmonės. Tačiau gali kilti klausimas, kur tokius

žmones rasti. Nežinant tokių, reikėtų peržvelgti projekto darbo grupės narių dokumentus, gal

kuris nors yra vykdęs panašų projektą, arba ekspertams rasti prašyti akcininkų pagalbos.

Didžiausias darbų trukmės įverčių tikslumas ekspertinio vertinimo būdu gaunamas tada,

kai ekspertas yra projekto grupės narys, įgijęs patirtį anksčiau. Pastebima, kad vyresnio amžiaus

ekspertų įvertintos trukmės būna trumpesnės nei jaunesnių ekspertų.

Kiekybiškasis trukmės vertinimo būdas. Šis būdas naudojamas tuomet, kai gali būti

išmatuota tam tikro darbų kiekio trukmė ir yra formulės viso darbo trukmei įvertinti. Tam dar

būtina žinoti našumo rodiklį arba turi būti nustatytas įmonės standartas nagrinėjamam darbui.

Pvz., jei 5 km ilgio kabeliui nutiesti tipiniu atveju skiriama 1 diena, tai 50 km reikės 10 dienų.

Šis vertinimo būdas gali būti labai tikslus dažnai pasitaikantiems darbams ir kuriems yra

pakankamai našumo duomenų, kad būtų nustatyti standartiniai rodikliai.

Daugelyje projektų naudojama minėtų būdų darbų trukmei vertinti kombinacija.

Kai jau turime pasirinkę projektui geriausiai tinkantį darbų trukmės vertinimo būdą,

projekto grupės nariams, pasiėmus jau anksčiau parengtą darbų išdėstymo diagramą, belieka

įvertinti kiekvieno darbo trukmę ir pasirengti darbų grafiko sudarymui (žiūr. 4.3 pav.).

Pradžia A darbas:

3 dienos

C darbas:

8 dienos

B darbas:

5 dienos

D darbas:

12 dienų

E darbas:

6 dienos

Pabaiga

4.3 pav. Darbų išdėstymo diagramos pavyzdys



49

4.3. Darbų grafiko sudarymas

Darbų grafiko sudarymas – tai pradžios ir pabaigos datų nustatymas kiekvienam projekto

darbui. Grafiko sudarymas yra darbų grafiko planavimo pabaiga. Tikslus darbų grafikas yra toks,

kuriame atsispindi visi darbai, jų atlikimo eilės tvarka ir trukmės. Jis gaunamas sujungus visus

ankstesnius darbų grafiko planavimo rezultatus. Darbų grafikui sudaryti naudojami šie trys būdai

ir priemonės:

- kritinio kelio metodas (CPM – Critical Path Method);

- trukmės suspaudimas;

- projektų valdymo programinė įranga.

Išnagrinėkime juos.

4.3.1. Kritinio kelio metodas

Kritinio kelio metodas (CPM) yra vienas iš matematinio analizavimo būdų. Kritinis kelias

projekto darbų grafike yra ilgiausios darbų sekos kelias projekte, nuo kurio priklauso viso

projekto pabaigos terminas. CPM metodo tikslas yra nustatyti šį kelią. Kritinio kelio darbų

trukmės negali turėti svyravimų. Gali svyruoti (keistis) tik darbo pradžios laikas arba darbui

užbaigti papildomai skiriamo laiko trukmė, tačiau nekeičiant viso projekto pabaigos termino. Jei

kritinio kelio kuris nors darbas nebūna atliktas grafike numatytu laiku ir nėra daromi jokie kiti

grafiko pakeitimai, tai gali turėti poveikį projekto pabaigos terminui.

Be visam projektui užbaigti reikalingo laiko nustatymo CPM padeda gauti ir kitus

naudingus duomenis. Gali prireikti nustatyti darbus, kuriuos galima būtų pradėti vėliau arba

vykdyti ilgiau, negu numatyta grafike, bet nereikėtų keisti viso projekto pabaigos termino. Tokia

informacija gali būti naudinga projekto vadovui, kad jis projekto bėgyje galėtų daugiau dėmesio

skirti tiems darbams, kurie turi didesnę įtaką visam projektui.

CPM metodu darbų grafikas retai sudaromas rankiniu būdu. Tam yra nemažai

programinės įrangos. Kad tokia įranga galėtume pasinaudoti, natūralu, turime turėti projektų

valdymo žinių ir suprasti, ką gi ji daro.

Darbų išdėstymo diagrama ir darbų trukmės įverčiai, kurie gaunami ankstesnių

planavimo etapų metu, yra pagrindiniai duomenys CPM metodui.

Peržiūra pirmyn (forward pass). Kritiniam keliui nustatyti turimoje darbų išdėstymo

diagramoje visų pirma reikia rasti kelius, vedančius nuo projekto pradžios iki pabaigos. Su

kiekvienu diagramoje įvardintu darbu tenka atlikti du skaičiavimus: anksčiausiam pradžios ir

anksčiausiam pabaigos laikui nustatyti.

Anksčiausias pradžios laikas yra darbo pradžios laikas, kada jis gali būti pradėtas

anksčiausiai. Darbų išdėstymo diagramoje pirmo nurodyto darbo anksčiausias pradžios laikas

yra 0. Prie šio laiko pridėjus darbui atlikti reikalingą laiką, gaunamas to darbo anksčiausias

pabaigos laikas.

4.3 pav. parodytos diagramos A darbo anksčiausias pradžios laikas yra 0. Prie šio laiko

pridėjus šiam darbui atlikti reikalingą trukmę (3 dienos) gausime jo anksčiausią pabaigos laiką

lygų 3. Pastarasis laikas tampa su A darbu priklausomybe susieto B darbo anksčiausiu pradžios



50

laiku. Tęsiant skaičiavimus gaunami visų diagramos darbų anksčiausi pradžios ir anksčiausi

pabaigos laikai (žiūr. 4.1 lentelę).

4.1 lentelė. Peržiūros pirmyn iliustracija remiantis 4.3 pav. darbų diagrama

Darbas Anksčiausias pradžios laikas Anksčiausias pabaigos laikas

A 0 3

B 3 8

C 3 11

D 8 20

E 11 17

Šių peržiūros pirmyn skaičiavimų rezultate gavome, kad visas projektas gali būti baigtas

per 20 dienų.

Peržiūra atgal (backward pass). Kitas kritinio kelio nustatymo žingsnis yra peržiūra atgal.

Šiame žingsnyje darbų išdėstymo diagramos analizė pradedama nuo galo ir einama link pradžios.

Tam reikalingi taip pat du skaičiavimai: vėliausiems darbų pradžios ir pabaigos laikams nustatyti.

Vėliausias pabaigos laikas yra laikas, kada darbas gali būti užbaigtas vėliausiai. Vėliausias

pradžios laikas yra laikas, kada darbas gali būti pradėtas vėliausiai.

4.3 pav. darbų išdėstymo diagramoje D darbas yra paskutinis. Vėliausiai jis turi būti

užbaigtas po 20 dienų. Vėliausias šio darbo pradžios laikas gaunamas iš pabaigos laiko atėmus

darbo trukmės laiką ir yra lygus 8 dienoms. Vėliausias D darbo pradžios laikas yra su juo

priklausomybe susieto B darbo vėliausias pabaigos laikas. Tęsiant skaičiavimus gaunami visų

diagramos darbų vėliausi pradžios ir vėliausi pabaigos laikai (žiūr. 4.2 lentelę).

4.2 lentelė. Peržiūros atgal iliustracija remiantis 4.3 pav. darbų diagrama

Darbas Vėliausias pradžios laikas Vėliausias pabaigos laikas

A 0 3

B 3 8

C 6 14

D 8 20

E 14 20

Svyravimų dydis (float). Paskutinis projekto darbų grafiko kritinio kelio nustatymo

žingsnis yra kiekvieno darbo pradžios ir pabaigos terminų svyravimų dydžio nustatymas.

Svyravimų dydis gaunamas radus skirtumą tarp vėliausio ir anksčiausio darbo pradžios laikų

arba tarp vėliausio ir anksčiausio darbo pabaigos laikų. Naudodami 4.1 ir 4.2 lentelių rezultatus

gauname darbų pradžios ir pabaigos svyravimų dydžius, kurie pateikiami 4.3 lentelėje. Pvz., A



51

darbo anksčiausias ir vėliausias pabaigos laikai yra 3 dienos, todėl šio darbo pabaigos laikas

negali svyruoti, nes svyravimo dydis lygus 0.

4.3 lentelė. Darbų laiko svyravimo dydžio iliustracija

remiantis 4.3 pav. darbų diagrama

Darbas Laiko svyravimo dydis

A 0

B 0

C 3

D 0

E 3

Dabar jau esame pasirengę apibrėžti kritinį kelią. Prisiminkime, kad kritinio kelio darbų

trukmės negali turėti svyravimų. 4.3 pav. pateikto pavyzdžio C ir E darbų pradžios ir pabaigos

laikai gali svyruoti, todėl jie neturi būti kritiniame kelyje. Kritinį kelią sudaro A, B ir D darbai, nes

jų pradžios ir pabaigos laikų svyravimai lygūs 0. Jei bet kuris kritinio kelio darbas nepradedamas

laiku arba vykdomas ilgiau, visas projektas gali būti nebaigtas numatytu laiku. Todėl projekto

eigoje turėtume skirti ypatingą dėmesį kritinio kelio darbams.

Tačiau gyvenime pasitaiko atvejai, kai darbų išdėstymo diagrama, apskaičiuotas kritinis

kelias ir nustatyta projekto trukmė yra nepriimtini projekto akcininkams arba neatitinka teisės

aktų reikalavimų. Projekto vadovui atsidūrus tokioje situacijoje, tenka naudoti projektų trukmės

suspaudimo būdus.

Trukmės suspaudimas. Darbų grafiko trukmės suspaudimas atliekamas tada, kai ji yra per

ilga ir neatitinka numatytos projekto pabaigos datos. Yra du trukmės suspaudimo būdai. Vienas iš

jų yra toks, kai projektui papildomai skiriama daugiau išteklių (pvz., darbuotojų). Tai įgalina

sutrumpinti grafiką, bet pareikalauja daugiau lėšų. Čia taip pat reikėtų žinoti, kad padvigubinus

išteklius, darbo trukmės sutrumpinti dvigubai neįmanoma.

Kitas grafiko trukmės suspaudimo būdas – lygiagretus darbų atlikimas, kurie normaliai

būtų atliekami nuosekliai. Naudojant šį būdą reikia būti ypač atsargiems, tokį žingsnį gerai

apsvarstyti su projekto darbo grupe, dokumentuoti, informuoti akcininkus. Gali nukentėti

projekto kokybė.

Įrankis - projektų valdymo programinė įranga

Projektų valdymui skirta programinė įranga gali padėti sutaupyti daug laiko. Darbų

apibrėžimas, darbų išdėstymas eilės tvarka, projekto darbų grafiko sudarymas gali būti atliekami

naudojant projektų valdymo programinę įrangą (pvz., Microsoft Project).

4.3.2. Projekto etapai

Priklausomai nuo jūsų organizacijoje naudojamų metodų, egzistuojančių vidaus taisyklių,

projekto darbų grafike gali reikėti nurodyti etapus (milestones). Etapai atspindi pagrindinius

projekto gyvavimo ciklo įvykius. Jų datos nurodo, kada turi būti gauti svarbūs projekto rezultatai.

Kai kuriose metodologijose etapai atspindi vienos projekto fazės pabaigą ir kitos pradžią.

Projektų darbų grafikuose nustatant etapus labai svarbu, kad:



52

- etapų pabaigos laikas būtų gerai apgalvotas, o atliekamų darbų prasme jie būtų

vienareikšmiai. Neturėtų likti argumentų pasiteisinimams, kad etape buvo neįmanoma

kažko padaryti;

- etapų pabaigoje darbai turi būti vertinami tik taip: atlikti arba neatlikti. Visuose

etapuose įvardyti darbai turi būti atlikti 100 proc.

4.3.3. Darbų grafiko kontroliniai taškai

Kai projekto darbų grafikas jau būna padalintas į etapus, tuomet nustatomi dar ir

kontroliniai taškai (checkpoints), kuriuose nurodoma, kas turėtų būti padaryta iki duoto laiko.

Kontroliniai taškai sudedami pradiniame projekto darbų grafike (vėliau jis gali keistis, prireikus

daryti projekto korekcijas). Jie padeda projekto vadovui sekti projekto eigą ir valdyti jį.

Projekto vadovas su kontroliniais taškais supažindina ir akcininkus. Kiekvienam

akcininkui pateikiama tokio lygio informacija apie kontrolinius taškus, kokio jie pageidauja.

Tačiau, mažiausiai, jiems teikiamoje informacijoje turi būti kontroliniai taškai, kurių datos

sutampa su projekto etapų pabaiga.

4.4. Projekto terminai ir tikrovė

Dažnai organizacijose IT grupės būna perkrautos darbu. Todėl jos labai mažai laiko

kasdieną gali skirti projektams. Jei žmogus sutinka dirbti projekte, tą jis dažniausiai daro po

darbo valandų, t. y. pasibaigus laikui, kai iš tikro reikėtų pilnai pasinerti į projekto užduotis.

Priklausomai nuo organizacijos dydžio, IT srities darbai yra:

- padalinti atskiriems programuotojų, atvirųjų sistemų (UNIX, Linux, Windows)

serverių priežiūros, didžiųjų (mainframe) ir vidutinių kompiuterių priežiūros,

pagalbos teikimo, duomenų bazių administravimo ir kt. skyriams;

arba

- atliekami viename padalinyje, kuriame yra tik po vieną ar du kiekvienos iš paminėtų

sričių specialistą.

Reta organizacija turi specialiai projektams vykdyti skirtą grupę, kurioje būtų įvairių IT

sričių specialistai. Dauguma organizacijų laiko IT specialistus einamiesiems kasdieniniams IT

naudojimo darbams prižiūrėti, o projektų vykdymas yra tik mintyje.

Kadangi yra tokia situacija ir IT skyrių užimtumas yra didelis, norint kviesti jų

darbuotojus dalyvauti projekte, reikia suprasti, iš ko susideda IT skyrių darbuotojų darbo diena.

Serverių administratoriai. Dauguma serverių administratorių savo darbo dieną pradeda

tikrindami kiekvieno serverio log failus, kuriuose registruojama informacija apie įvairius įvykius,

ar nebuvo serverio darbo klaidų. Jei jų buvo, tuomet aiškinamasi, kas gi buvo atsitikę, ir

sprendžiama problema. Po to paprastai serverių administratorius aptarnauja naudotojų

užklausas (pvz., kažkas negali prisijungti prie serverio, nes baigėsi slaptažodžio galiojimo laikas,

kažkam užblokavo prieigą dėl kokių nors priežasčių, kt.). Atlikęs visa tai, jei dar liko laiko, jis gali

imtis projekto darbų.

Duomenų bazių administratoriai (DBAs) taip pat pradeda savo darbo dieną tikrinimu, ar

neatsitiko ko nors blogo su jų prižiūrima baze (peržiūri log‘us). Jei buvo klaidų, aiškinamasi, kas



53

gi buvo nutikę, ir šalinamos atsiradusios kliūtys. Po to DBAs peržiūri indeksus ir trigerius,

užklausas įtraukti ar pašalinti kolonėles ir atlieka reguliavimo darbus, kad duomenų bazė veiktų

greičiau.

Darbą projekte DBAs pradeda naujos duomenų bazės schemos kūrimu, planavimu ir

projektavimu. Visõs naujai suprojektuotos duomenų bazės komponentai gali būti per daug

išplėsti, nes įtraukiama viskas, ko pageidavo užsakovas. Todėl reikalinga duomenų bazės

normalizacija, t. y. kiekvienos lentelės joje optimizavimas, pašalinant logiškai nereikalingus

elementus. Visam tam sugaištama daug laiko, ypač jei duomenų bazė yra didelė.

Programuotojai. Dauguma programuotojų dirba kituose projektuose. Todėl jums gali būti

sunku prisivilioti juos į savo projektą.

Programuotojai gali naudoti įvairias programavimo kalbas ir turėti nevienodą patirtį. Pvz.,

jūsų projektui reikia patyrusio Java programuotojo, galinčio per trumpą laiką sukurti keletą

modulių. Aišku, kad to nesugebės padaryti nei C# programuotojas, nei mažą patirtį turintis Java

programuotojas. O laukti, kol jauni programuotojai išmoks tą daryti, jūs galite neturėti laiko.

Programinę įrangą kuriantys padaliniai ar įmonės nėra pertekę specialistais, todėl seniau

dirbantys ir patyrę programuotojai būna apkrauti darbu. Kartais jie netgi neturi laiko atsakyti į

jaunesnių bendradarbių klausimus ir palieka juos dirbti vienus. Visa tai jums, kaip projekto

vadovui, apsunkina savo projekto darbų grafiko rengimą.

Telekomunikacijų ir interneto specialistai. Labai dažnai šios srities specialistai nėra IT

įmonės darbuotojai ir būna pavaldūs visai kitiems vadovams. Kartais jiems kaip tik trūksta

projektų, o kartais jie turi kitus prioritetus arba dirba kituose projektuose.

Aukščiau aprašyti dalykai skamba niūrokai. Todėl parengti gerą projekto darbų grafiką

nėra lengva. Dalį problemų gali padėti išspręsti bendri interesai. Jei jūsų projektas yra svarbus ir

jūs esate įpareigotas pateikti rezultatus iki nustatyto laiko, tuomet jūs turite svertų paveikti jums

galinčius padėti žmones. Tačiau svarbu, kas gi suteikė jums tuos svertus. Pvz., jeigu projektą

inicijavo realizavimo (prekybos) departamentas, jus rems ir ragins šio departamento vadovai, o

kiti organizacijos departamentai nejaus tokios skubos. Kita vertus, jei projektas rūpi centrinei

organizacijos vadovybei, jūs turėsite mažiau rūpesčių formuodami projekto grupę.

Vadovauti IT projektams nėra lengva, nes jūs neturite iš anksto jums paskirtų žmonių.

Jiems surasti reikės laiko. Todėl svarbu išnagrinėti žmonių darbo krūviu pagrįstą projekto darbų

grafiką ir nustatyti realų darbų pabaigos terminą, atsižvelgiant į aukščiau aprašytas nepalankias

aplinkybes.



54

5. PROJEKTO KAINOS PLANAVIMAS

Projekto vadovas, turėdamas projekto apimties aprašą, suskaidytų darbų lentelę (WBS) ir

jų atlikimo grafiką, turi parengti projekto biudžetą, ir, kai jį patvirtina projekto rėmėjai, tvarkyti

jį.

Pinigai, kaip žinia, dažnai būna karštų diskusijų objektas. Iš projektų vykdytojų

reikalaujama padaryti kuo daugiau mažesnėmis sąnaudomis. Prašyti daugiau pinigų projekto

eigoje nėra malonus reikalas. Todėl projektui reikalingos lėšos turėtų būti suplanuotos kiek

galima geriau. Projekto pradžioje tą padaryti yra sunku, tačiau yra keletas būdų ir priemonių,

padedančių geriau suplanuoti projekto biudžetą.

Išteklių planavimas – tai projektui įvykdyti reikalingų išteklių tipo nustatymas ir jų

paskyrimas kiekvienam projekto darbui. Kainos vertinimas yra projektui reikalingų išteklių

kainos nustatymo procesas. Yra trys kainos įvertinimo būdai: analogiškasis, parametrinio

modeliavimo ir pavyzdinis.

Lėšos numatomos kiekvienam projekto etapui. Biudžeto išlaidoms sekti taip pat yra

naudojami kontroliniai taškai. Minėti klausimai yra nagrinėjami šiame mokymo medžiagos

skyriuje.

5.1. Išteklių planavimas

Pirmasis projekto kainos planavimo žingsnis yra išteklių planavimas. Jis apima

darbuotojus, įrangą ir medžiagas, jų kiekius (pvz., 20 žmogaus darbo valandų, 3 serveriai, kt.).

Išteklių planavimo pradžioje reikėtų peržiūrėti projekto apimties aprašą, darbų sąrašą

(WBS) ir pasidomėti, kur galima būtų gauti informacijos apie anksčiau vykdytų panašių projektų

išteklius. Tokios informacijos turėjimas gali padėti teisingai ir greičiau suplanuoti jūsų projektui

reikalingus išteklius. Taip pat gali būti naudinga peržiūrėti organizacijos specifines išteklių

skyrimo projektams taisykles (pvz., taisyklės gali reikalauti vadovybės leidimo, norint kažkuriam

laikui darbams pasitelkti kito padalinio darbuotojus).

5.1.1. Išteklių tipai

Skiriami trys išteklių tipai: žmoniškieji ištekliai, įranga ir medžiagos.

Žmoniškieji ištekliai. Tai reikiamos kvalifikacijos ir sugebėjimų žmonės. Tačiau apibūdinti

reikiamų savybių žmogų gali būti sunkoka. Ieškant tokių žmonių prašoma nurodyti konkrečius

sugebėjimus, kokiuose ankstesniuose projektuose teko dirbti, kokios trukmės stažas, kt.

Įranga. Tai gali būti pati įvairiausia įranga: specializuota testavimo įranga, serveriai,

papildomi asmeniniai kompiuteriai programuotojams, kt. Kai kurio tipo įrangos pristatymo gali

tekti laukti nemažai laiko nuo paraiškos įteikimo.

Jei kuriama nauja programinė įranga ir ją planuojama leisti organizacijoje esančiame

serveryje, reikėtų pasitikrinti tokios prielaidos teisingumu. Net jeigu serveryje duotu metu yra

laisvos erdvės, ji gali būti suplanuota kitai, o ne jūsų kuriamai programinei įrangai. Arba, jei jūs

numatote intensyvų sukurtos įrangos testavimą, pasitikrinkite, ar turėsite prieigą prie esamos

testavimo įrangos, ar jūsų projektui reikės specialios įrangos.



55

Kai kuriems projekto darbams, pvz., produkto kūrimo, testavimo, pristatymo gavėjui,

atlikti reikia numatyti specialios įrangos reikalingumą, ypač nesusijusios su IT. Jei projekto darbų

grafike numatytas sukurto produkto priėmimo testavimas, kurį atliks užsakovas, išsiaiškinkime,

kaip jis bus atliekamas. Ar yra nurodyta vieta, kur bus testuojama, ar toje vietoje yra testui atlikti

reikalinga įranga?

Medžiagos. Tai labai plati sąvoka, apimanti darbui reikalingą pagalbinę programinę

įrangą, el. energiją, vandenį, kitokius projektui vykdyti reikalingus išteklius ar vartojimo

reikmenis (patalpos, baldai, kompiuterių tinklas, kanceliarinės prekės, kt.).

5.1.2. Išteklių poreikio nustatymas

Projektui reikiamų išteklių dokumentas rengiamas remiantis projekto apimties aprašu,

darbų sąrašu (WBS) ir išteklių tipais. Išteklių poreikio dokumente aprašomi kiekvienam projekto

darbui reikalingi visų trijų tipų ištekliai.

Išteklių planavimo eigoje nebūtina žinoti vardus žmonių, kurie vykdys konkrečius darbus.

Reikia tik nurodyti specialybės pavadinimą ar darbo aprašą, pvz., Web programuotojas, serverio

administratorius ar kt. Kaip ir kur reikėtų ieškoti reikiamų žmonių, rašoma 6 skyriuje „Projekto

grupės planavimas“.

Pareigų aprašai. Sprendžiant projektui reikalingų darbuotojų klausimą, gali praversti

organizacijoje esantis pareigybių sąrašas, jei nėra ribojama prieiga prie jo. Tokiame sąraše yra

trumpas pareigybių aprašas ir gali būti nurodytas kiekvienos specialybės darbuotojų kiekis,

duotu metu dirbančių organizacijoje.

Jei tokios informacijos jūs negalite gauti, reikėtų panagrinėti informaciją apie panašiuose

projektuose dalyvavusius darbuotojus. Ji gali padėti jums įvardinti pareigas ar specialistus,

reikalingus jūsų projektui.

Įrangos ir medžiagų aprašai. Jūsų organizacijoje tipinio įrangos ir medžiagų sąrašo, kaip

kad pareigybių sąrašas, gali ir nebūti. Todėl įvardinti reikiamą įrangą tenka patiems projekto

grupės nariams. Pradedant projektą, jie dažniausiai turi asmeninius kompiuterius, telefonus,

kanceliarines medžiagas, kt. Kai kuriais atvejais dalį projekto grupės gali tekti perkelti dirbti į

kitą vietą. Todėl būtina žinoti, ar organizacijos taisyklės leidžia kartu su darbuotoju perkelti ir

jam skirtą įrangą, ar projekto vadovas taps atsakingas už ją. Jei projekto grupė turi būti perkelta į

kitą vietą, reikia žinoti, ar ten yra tinkamos patalpos, ar projekto biudžete reikia numatyti išlaidas

darbo vietoms įrengti kitur.

Naujos programų sistemos kūrimo projektuose gali reikėti serverių ar galingų

kompiuterių (mainframes) jai įdiegti. Jei yra nustatyta, kokios platformos kompiuteriuose ji

turės dirbti, tokio reikalavimo turi būti laikomasi. Gali būti taip, kad turima aparatinė įranga tinka

jūsų kuriamai sistemai, tačiau gali tekti pirkti ir naują. Jeigu projektas apima ir naujos aparatinės

įrangos pirkimą, jūs turite pagalvoti ir apie tos įrangos veikimui būtinus dalykus, kaip elektros

energijos tiekimą ar ventiliaciją.

Reikiamų išteklių lentelė. Išteklių poreikio apskaitai palengvinti dažnai naudojamos tam

tikros priemonės ar šablonai. Šiems tikslams rekomenduojama sudaryti reikiamų išteklių lentelę.



56

5.1 lentelėje pateikiamas reikiamų išteklių pavyzdys, kuriame parodyti projekto darbai, jiems

atlikti reikalingų išteklių pavadinimai ir jų kiekiai.

Kai nustatomi kiekvienam projekto darbui reikiami ištekliai, toliau vertinama šių išteklių

įsigijimo kaina.

5.1 lentelė. Projektui reikiamų išteklių pavyzdys

Darbas Programuo-

tojai Inžinieriai Ekonomistai

Techn. dokumentų

rengėjai Serveriai

A 1

B 2

C 3 1

D 4

E 1

5.2. Išteklių kainos vertinimas

Išteklių kainos vertinimas yra indėlis į projekto biudžeto formavimą. Tikslesniam

įvertinimui būtina pasitelkti visus prieinamus duomenis ir priemones.

Išteklių kainai įvertinti yra keltas būdų:

- analogiškasis (analogous estimates);

- parametrinio modeliavimo (parametric modeling);

- pavyzdinis (definitive estimates).

Toliau pateikiama keletas minčių, kurios gali praversti vertinant išteklių kainą.

5.2.1. Kainos vertinimo būdai

Aukščiau minėti kainos vertinimo būdai gali būti naudojami įvairiuose projekto planavimo

etapuose. Gali būti ir taip, kad kažkuriam etape naudojamas vienoks vertinimo būdas, o kitame -

kitoks.

Išteklių kainos vertinimo būdų tikslumas gali svyruoti ir todėl gali būti gaunami skirtingi

rezultatai. Apžvelkime tuos būdus.

Analogiškasis vertinimas (analogous estimates). Analogiškasis išteklių kainos vertinimo

būdas, kaip ir darbų trukmės vertinimo būdas projekto darbų grafiko planavimo atveju,

remiasi anksčiau vykdytų projektų patirtimi. Kitaip jis dar vadinamas iš viršaus-žemyn (top

down) arba leistinų ribų (order of magnitude) vertinimo būdu. Šitoks vertinimo būdas

projekto pradžioje naudojamas grindžiant projekto poreikį ir naudą, taip pat rengiant projekto

apimties aprašą inicijavimo etape, kai dar nėra tikslesnių duomenų apie projektą.

Analogiškasis vertinimo būdas naudoja ankstesnių projektų informaciją kartu su ekspertų,

atsakingų už vykdomam projektui reikiamų išteklių kainų įvertinimą, nuomone. Analogiškasis

vertinimo būdas gali būti naudojamas visam projektui, atskiroms jo dalims ar rezultatams.

Tačiau jis nėra naudojamas vertinant išteklių poreikį atskiriems darbams ar jų grupėms.



57

Neįmanoma rasti anksčiau vykdyto projekto, kuris tiksliai atitiktų jūsų dabar vykdomą. Jei

jūsų vykdomas projektas nebūtų unikalus, jis nebūtų projektas tikrąja to žodžio prasme

(prisiminkime, kad projektas – tai veiklų grupė arba veikimo planas unikaliam produktui

sukurti). Todėl analogiškasis vertinimo būdas nėra tikslus.

Analogiškojo vertinimo paklaidos gali svyruoti nuo -25% iki 75% tikrosios projekto

kainos.

Nežiūrint to analogiškasis vertinimo būdas projekto pradžioje, kol neturima tikslesnių

duomenų, gali būti geriausias. Ir labai svarbu, kad su projektu susiję asmenys suprastų, jog toks

vertinimas negali būti tikslus.

Parametrinis modeliavimas (parametric modeling). Parametriniame modeliavime

projektui reikiamų išteklių kainai apskaičiuoti naudojami matematiniai modeliai. Jo tinkamumas

kainai vertinti priklauso nuo projekto tipo. Geriausiai parametriniai modeliai tinka statybų

projektuose. Naujo namo statytojai visą jo kainą įvertina parametrinio modeliavimo būdu, kaip

vieną iš parametrų naudodami kvadratinio metro savikainą.

Programų sistemų kūrimo projektuose labiausiai paplitęs parametrinis modelis yra

konstruktyvusis kainos modelis (COCOMO – COnstructive COst MOdel). Jame naudojami tokie

parametrai, kaip sistemos sudėtingumas, darbo grupės gebėjimai, sistemos kūrimo procesai,

naudojami instrumentai.

Nemažai organizacijų turi savus parametrinius modelius. Yra ir komercinių modelių.

Parametrinio modeliavimo tikslumas priklauso nuo modeliui sukurti panaudotų duomenų

tikslumo. Dažniausiai minimas parametrinio modelio trūkumas – galimybės keisti modelio dydį

nebuvimas.

Informacijos apie COCOMO arba parametrinius modelius galima rasti internete.

Pavyzdinis vertinimas (definitive estimates). Pavyzdinis vertinimo būdas duoda

geriausią tikslumą, nes šiuo atveju vertinama projekto kiekvieno darbo kaina. Pavyzdinio

vertinimo paklaidos dažniausiai svyruoja nuo -5% iki 10% tikrosios projekto kainos. Šis

vertinimo būdas dar vadinamas vertinimu iš apačios į viršų (bottom up estimating). Suskaidytų

projekto darbų lentelė (WBS) ir reikiamų išteklių sąrašas yra pavyzdinio kainos vertinimo būdo

įeities duomenys. Vertinimas pradedamas nuo žemiausio lygmens darbų ir atliekamas

kiekvienam darbui. Šių visų darbų kainų suma yra viso projekto kainos įvertis.

Planuojant projekto darbų grafiką, reikėjo įvertinti kiekvieno darbo trukmę. Vertinant

reikiamų išteklių kainas, būtina remtis pastangų dydžiu. Tai yra ne kas kita, kaip laikas, kurį

žmogus turi sugaišti darbui atlikti. Pastangos dažniausiai matuojamos žmogaus darbo

valandomis. Pvz., planuojant darbų grafiką buvo nustatyta, kad projekto techninių reikalavimų

dokumentui parengti reikia 4 dienų. Planuojant kainas reikia žinoti, kiek valandų per dieną

žmogus skirs šiam darbui. Jei skiriamos 5 val. per dieną, tai pastangų dydžio minėtam darbui

atlikti įvertis yra 20 žmogaus darbo valandų.

Skirtumas tarp darbui atlikti reikalingo laiko ir pastangų dydžio gali atrodyti painus.

Tačiau nereikėtų pamiršti, kad čia turime reikalą su dviem iš esmės skirtingais rezultatais. Darbų

trukmės įverčiai darbų grafike padeda mums nustatyti, kiek gi kalendorinio laiko reikės projektui

užbaigti. Tuo tarpu pastangų dydžio įverčiai, kuriuos gauname projekto kainos planavimo etape,



58

naudojami projekto kainai nustatyti. Darbų grafikui sudaryti jūs turite žinoti, pvz., kad kažkuriam

darbui atlikti reikia 2 savaičių, o projekto kainai įvertinti jūs turite žinoti, kad tam darbui atlikti

reikia 30 žmogaus darbo valandų.

5.2 lentelėje parodytas pastangų dydžio pavyzdys, atitinkantis 5.1 lentelėje parodytus

projektui reikiamus išteklius.

5.2 lentelė. Projekto pastangų dydžio pavyzdys

Darbas Ištekliai Pastangų dydis

A Techn. dokumentų rengėjai (1) 20 val.

B Programuotojai (2) 100 val.

C Inžinieriai (3) 60 val.

C Serveriai N/A

D Programuotojai (4) 200 val.

E Ekonomistai (1) 30 val.

Dar vieni duomenys, kurių reikia pavyzdiniam kainos vertinimo būdui, yra kiekvieno tipo

išteklių kaina (įkainiai). Darbo arba nuomojamos įrangos įkainiai paprastai nustatomi valandoms

arba dienoms. Kitokių išteklių kaina gali būti išreiškiama kaip mokestis (pvz., naudojimosi kokia

nors sistema) ar vertė (pvz., el. energijos kilovatvalandės, kanceliarinės prekės).

Pasirinkti teisingas kainas yra keblus uždavinys, nes medžiagų ar įrangos kainos laikui

bėgant gali keistis. Daugelio IT projektų kainoje didžiausią dalį sudaro darbuotojų ar darbų kaina.

Šią kainą nustatyti yra sunkiausia, nes ji svyruoja priklausomai nuo darbuotojų išsilavinimo ir

patirties. Jūs galite turėti tik vidutines šių išteklių kainas ar kainų intervalą. Darbams, kuriems

reikia labiau patyrusių specialistų, pasirenkami didesni įkainiai, o kur reikia mažiau patyrusių

specialistų - mažesni įkainiai.

5.3 lentelėje parodytas projekto kainos vertinimo pavyzdys, atitinkantis 5.1 ir 5.2 lentelių

duomenis.

5.3 lentelė. Projekto kainos vertinimo pavyzdys

Darbas Ištekliai Pastangų dydis Kaina, įkainis Visa kaina

A Techn. dokumentų

rengėjai (1)

20 val. 30 Lt/val 600 Lt

B Programuotojai (2) 100 val. 50 Lt/val 5 000 Lt

C Inžinieriai (3) 60 val. 40 Lt/val 2 400 Lt

C Serveriai N/A 50 000 Lt 50 000 Lt

D Programuotojai (4) 200 val. 50 Lt/val 10 000 Lt

E Ekonomistai (1) 30 val. 60 Lt/val 1 800 Lt

Iš viso: 69 800 Lt



59

5.2.2. Vertinimo rekomendacijos

Šaukime projekto darbo grupės pasitarimus. Detalus projekto kainos įvertis gaunamas

nustatant kiekvieno darbo kainą ir sumuojant jas. Šiame vertinimo procese jūs galite

neapsižiūrėję praleisti kai kuriuos darbus.

Ar projekto grupei reikalingi specialūs mokymai? Jei projekte kuriama programų sistema,

ar reikia planuoti išvykas pas užsakovą, ar sukurtą sistemą galima bus diegti nuotoliniu būdu.

Projekto grupės susirinkimuose turėtų būti aptariamos įvairios projekto išlaidos. Tai

padeda išvengti galimų klaidų.

Gerai suvokime naudojamą kainos vertinimo būdą. Projekto kainos įvertis sensta labai

greitai. Kadangi nuo to apsisaugoti neįmanoma, reikėtų labai aiškiai suprasti naudojamą

vertinimo būdą.

Jeigu projekto kaina vertinama analogiškuoju būdu ir remiamasi ankstesniu panašiu

projektu, būtina gerai išsiaiškinti, kokio dydžio paklaidą galite padaryti. Būtina atkreipti dėmesį į

kiekvieną reikšmingesnio kainų skirtumo tarp jūsų planuojamo ir ankstesnio projekto, kuriuo

remiatės atlikdami vertinimus, priežastį.

Naudokime kokį nors prieinamą šabloną. Daug organizacijų turi projektų kainoms vertinti

skirtus šablonus ar lenteles. Stenkimės naudoti juos. Matydami juose visus galimus lėšų šaltinių ir

išlaidų kategorijas, būsime labiau tikri, kad viską įtraukėme į savo projekto vertinamą kainą.

Šablonai gali būti geras kainų ar įkainių šaltinis. Projekto vykdytojų algos varijuoja

priklausomai nuo pareigų ir specifinės patirties. Organizacijoje gali būti parengtos standartinės

kainos ar įkainiai projektų kainai vertinti.

Stenkimės gauti įverčius iš darbą atliekančių žmonių. Projektų kainos vertinimo

pavyzdiniu (definitive) arba kitaip vadinamu iš apačios į viršų (bottom up) būdu gero tikslumo

priežastis yra ta, kad įvertinamas kiekvienam projekto darbui atlikti reikalingas pastangų dydis

(žmogaus valandos, kt.). Gero tikslumo nebūtų, jei pastangų dydžio vertinimą atliktų žmonės,

gerai neišmanantys tų darbų. Jei projekte reikės darbų, kurie jūsų organizacijai yra nauji, jums

gali reikėti pagalbos iš išorės jų atlikimo pastangų dydžiui įvertinti.

Numatykime lėšas projekto grupės nariams skatinti. Kiekvienas projekto vadovas nori

paskatinti geru darbu pasižymėjusius grupės narius, skirti premijas, atšvęsti projekto pabaigą.

Tačiau tą sunku padaryti neturint tam lėšų. Ne visos organizacijos projekto grupei skatinti skiria

lėšas, tačiau pritarimo dėl lėšų skyrimo tokiems tikslams galima kreiptis į sponsorių.

Dokumentuokime visas prielaidas. Jei valandiniai įkainiai buvo pagrįsti vidinėmis

organizacijos taisyklėmis, projekto kainos įvertinimo dokumente nurodykime tai. IT projektams

atlikti dažnai naudojami subrangovai, kurie turi kitokius valandinius įkainius. Jei projekto eigoje

iškyla būtinumas sudaryti sandorį su subrangovu, būtina nedelsiant kreiptis į projekto

akcininkus dėl biudžeto pakoregavimo, nes atsirado kitokie kai kurių darbų įkainiai.



60

5.3. Projekto biudžeto sudarymas

Išteklių planavimas ir kainų vertinimas dar nepaverčia projektui numatytų lėšų tikraisiais

pinigais. Taip yra todėl, kad organizacijos privalo laikytis formalių procedūrų, skirdamos finansus

projektams.

Projekto vadovas įvertintą projekto kainą perduoda organizacijos biudžeto tvarkytojams.

Vadovybė patvirtina projektui vykdyti prašomą sumą, ir ji tampa organizacijos biudžeto dalimi.

Toliau sudaromas projekto biudžetas, kur visam projektui patvirtintos lėšos, remiantis kainų

įverčiais, darbų sąrašu (WBS) ir darbų grafiku, paskirstomos atskiriems projekto darbams.

Grupei pradėjus vykdyti projektą, tikrosios išlaidos daromos laikantis biudžete nustatytų dydžių

ir numatytu laiku.

Projekto biudžetas padeda orientuotis, kokio dydžio išlaidos leistinos kiekvieno tipo

ištekliams numatytais laikotarpiais. Dažniausiai biudžetas padalinamas mėnesiais.

Žinoti visus su projekto biudžetu susijusius klausimus nėra lengva, ypač kai esi atsakingas

už jums patikėtus išteklius. Prieš pradėdami projekto darbus susipažinkite su jūsų organizacijoje

galiojančiomis taisyklėmis. Reikėtų išsiaiškinti šiuos su projektų biudžeto tvarkymu susijusius

klausimus:

- ar visos projekto išlaidos pateiktos tvirtinti projekto vadovui?

- ar projekto vadovas turi tvirtinti grupės narių darbo tabelius (timesheets)?

- ar projekto vadovas turi gauti savaitines ataskaitas apie projekto vykdymui sugaištas

darbo valandas?

- ar yra kainų ar kiekių maksimalūs dydžiai, kada reikėtų gauti projekto sponsoriaus ar

užsakovo leidimą?

Turint atsakymus į šiuos klausimus, vėliau galima išvengti problemų.

Projekto išlaidų sekimas ne visada yra projekto vadovo pareiga. Kadangi buvo pateikti

kainų įverčiai ir sudarytas projekto biudžetas, išlaidas iš tikrųjų seka centrinis organizacijos

padalinys (buhalterija ar finansų skyrius). Kai kurios organizacijos turi projektų valdymo skyrius

(PMO – Program Management Office), kurie stebi visų tos organizacijos projektų biudžetų

vykdymą.

5.3.1. Projekto biudžetas

Projekto biudžetas rengiamas remiantis patvirtintu projekto kainos įverčiu ir darbų

grafiku. Tačiau prieš leisdamiesi į projekto biudžeto rengimo detales, atkreipkime dėmesį į du

savarankiškus fondus, kurie gali būti biudžete.

Specialusis fondas (nenumatytoms išlaidoms) ir vadovo rezervinis fondas yra du ypatingi

finansavimo šaltiniai, kurie naudojami kai kuriose organizacijose. Šie fondai skiriami ne visiems

projektams. Jeigu jūsų organizacijoje naudojamas kuris nors iš šių fondų, jūs turite žinoti jų

skyrimo ir įgaliojimų naudotis jais gavimo taisykles.

Specialusis fondas. Tai pinigų kiekis, atskirai paskirtas projektui, kuriuos galima naudoti

nenumatytoms pradinės apimties projekto išlaidoms, kurios nebuvo įvardintos planavimo metu.

Nėra taisyklių, laikantis kurių galima būtų apibrėžti specialiojo fondo dydį. Tačiau organizacijos,

pritariančios tokio fondo buvimui, perveda į jį keleto procentų nuo visos projekto kainos sumą.



61

Specialiojo fondo skyrimu siekiama sudaryti geresnes galimybes projekto rizikos

klausimams spręsti. Jie dažniausiai naudojami priešakiniuose projektuose. Vertinant pastarųjų

kainą nėra galimybės remtis ankstesnių projektų patirtimi (panašių projektų nėra buvę), todėl

paklaidos gali būti didesnės, be to žmonių patirtis tokiose priešakinėse srityse gali būti maža.

Dažniausiai projekto vadovui suteikiami įgaliojimai naudoti specialiojo fondo lėšas.

Vadovo rezervinis fondas. Tai pinigų suma, kurią skiria organizacijos vadovybė ateities

situacijoms spręsti (išeinant už pradinės apimties projekto ribų), kurių nebuvo galima numatyti

rengiant projekto kainos įvertį. Kaip ir specialiojo fondo atveju, vadovo rezervinio fondo dydis

yra kažkoks procentas nuo visos projekto kainos.

Skirtumą tarp specialiojo fondo ir vadovo rezervinio fondo sudaro tai, kas gi jais gali

disponuoti. Pastaruoju fondu projekto vadovas gali pasinaudoti tik gavęs vadovybės patvirtinimą.

Projekto biudžetą organizacijos finansų skyrius paprastai dalina į specifines kategorijas

(straipsnius): darbo užmokesčio, samdomo darbo, aparatinės įrangos, programinės įrangos,

kelionių, mokymo ir medžiagų.

Vienose organizacijose jų finansų skyrių atstovai padeda sudaryti projektų biudžetus.

Kitose, ypač mažesnėse organizacijose už projekto biudžeto sudarymą gali būti atsakingas

projekto vadovas. Bet kuriuo atveju projekto vadovui reikėtų susipažinti su organizacijoje

naudojamomis biudžeto dalių kategorijomis, kad žinotų kaip yra klasifikuojami projekto ištekliai.

Dažniausiai biudžetai būna lentelės pavidalo, padalinti mėnesiais ar metų ketvirčiais.

5.4 lentelėje parodytas projekto biudžeto pavyzdys. Jame panaudoti 5.3 lentelės

duomenys, laikant, kad projekto trukmė yra trys mėnesiai.

5.4 lentelė. Projekto biudžeto pavyzdys

Sausis Vasaris Kovas Suma

Darbo užmokestis 600 Lt 1 200 Lt 3 000 Lt 4 800 Lt

Samdomas darbas

(programuotojai)

5 000 Lt 5 000 Lt 5 000 Lt 15 000 Lt

Aparatinė įranga (serveris) 50 000 Lt 50 000 Lt

Iš viso: 69 800 Lt

Projekto biudžete lėšos nustatomos etapams, kas padeda valdyti projekto eigą.

5.3.2. Biudžeto lėšos projekto etapams

Sudarytą projekto biudžetą turėtų peržiūrėti projekto grupė. Priklausomai nuo to, kas iš

tikrųjų rengė biudžetą, galbūt geriau būtų, kad biudžetą peržiūrėtų organizacijos finansų skyriaus

atstovas. Projekto grupė turėtų žinoti kritinius darbų grafiko ir biudžeto taškus. Visi klausimai

dėl biudžeto lėšų skirstymo į kategorijas (darbo užmokesčiui, įrangai, kt.) ir kaip lėšos yra

paskirstytos laike turėtų būti žinomi grupės nariams.

Kai projekto grupė peržiūri biudžetą, nustatomos lėšos kiekvieno etapo pradžiai. Lėšų

etapo pradžioje žinojimas padeda projekto eigoje sekti, ar daromos išlaidos atitinka planuotąsias.



62

Jos taip pat naudojamos peržiūrint tolesnių (likusių etapų) projekto darbų kainas, remiantis jau

padarytomis išlaidomis ir likusių darbų planuota kaina. Lėšos etapo pradžioje atspindi visas

lėšas, kurios buvo numatytos projekto kainos vertinimo eigoje, išskyrus specialiojo fondo ir

vadovo rezervinio fondo lėšas.

Projekto vadovas turi informuoti projekto akcininkus apie panaudotas lėšas ir likusias

etapų pradžioje. Vieni akcininkai gali norėti žinoti finansinę padėtį tik viso projekto pradžioje,

kiti gali norėti žinoti kiekviename projekto etape padarytas išlaidas. Projekto etapuose išlaidos

daromos laikantis biudžeto naudojimo kontrolinių taškų (budget targets).

5.3.3. Biudžeto naudojimo kontroliniai taškai

Projektų biudžetai paprastai sudaromi taip, kad atitiktų organizacijos finansų skyriaus

reikalavimus. Biudžeto lėšų kategorijos ar mėnesinės ataskaitos teikia neblogas projekto lėšų

leidimo detales, tačiau tai ne vienintelės ar geriausios priemonės biudžetui valdyti.

Projektų vadovams kartais reikia teikti ataskaitas apie išlaidas projektų etapų metu. Todėl

reikėtų nusistatyti biudžeto naudojimo kontrolinius taškus kiekvieno etapo viduje. Kai projektas

yra pradėtas, jūs realiai stebite, kaip laikomasi darbų grafiko ir biudžeto, ir turite žinoti, ar nėra

nukrypimų. Kontroliniai taškai padeda anksčiau gauti perspėjimus apie nukrypimus. Pvz.,

imkime standartinį IT projektą, kurio gyvavimo cikle yra reikalavimų rengimo, projektavimo

(design), kūrimo, testavimo ir diegimo fazės. Planuojant darbų grafiką buvo nustatyta, kad

reikalavimams parengti reikės 4 savaičių ir darbai bus baigti kovo 31 d., o suplanuotame biudžete

tiems darbams numatyta 50000 Lt. Už kovo mėnesį gauta biudžeto ataskaita rodo, kad buvo

išleista 48000 Lt. Bet kas gali pagalvoti, kad reikalai klostosi gerai, sutaupyta truputis pinigų. Bet

pažiūrėję į darbų grafiką matome, kad kovo 31 d. numatyti atlikti darbai dar nepadaryti ir jiems

reikės dar trijų savaičių. Reiškia, jūsų projektas yra pavojuje. Išleidote visus reikalavimams

parengti skirtus pinigus, tačiau parengėte tik apie pusę reikalavimų. Štai kodėl yra svarbu

numatyti biudžeto naudojimo kontrolinius taškus.

Atsidūrę tokioje situacijoje, jūs nesate tikri, kokių veiksmų reikėtų imtis. Kartais, parengę

jūsų manymu gerą biudžetą, galite pastebėti, kad darbų kaina skiriasi nuo planuotosios. Tai

vadinama kainų nuokrypiu (CV – Cost Variance), apie ką plačiau rašoma 13.5 skyriuje.

5.3.4. Biudžeto sudarymo įrankis - projektų valdymo programinė įranga

Kaip ir projekto darbų grafikui sudaryti ar projekto kainai įvertinti, taip ir projekto

biudžetui sudaryti gali būti naudojama speciali projektų valdymo programinė įranga, pvz.,

Microsoft Project.



63

6. PROJEKTO GRUPĖS PLANAVIMAS

Projekto kainos planavimo metu, kalbant apie žmoniškųjų išteklių poreikį, buvo

akcentuojama darbuotojų specialybė, kokius darbus jie turėtų mokėti dirbti. Ten dar nebuvo

kalbama apie konkrečius žmones, apie jų darbo organizavimą.

Projekto grupės planavimas apima jos narių pareigų ir atsakomybių, tinkamos

atsiskaitymo už darbus grupėje schemos ir darbuotojų teisių nustatymą, žmonių įtraukimą į

projektą nustatytam laikotarpiui. Projekto grupės planavimo rezultatas – tai nustatyta grupės

organizacinė struktūra ir kur ieškosime projektui vykdyti reikiamų specialistų. Vėliau, laikui

bėgant, kartais tenka rūpintis ir darbo našumo kėlimo klausimais, spręsti darbuotojų kaitos

problemas.

6.1. Projekto grupės organizacinės struktūros planavimas

Valdyti žmonių grupę, kuriai pavesta sukurti unikalų produktą per nustatytą laiką

(prisiminkime projekto sąvokos apibrėžimą), nėra lengva užduotis. Kiekvienas projekto grupės

narys turi aiškiai suvokti savo pareigas ir žinoti, kam ir kaip jis turi atsiskaityti už savo darbą.

Taip pat grupės nariai ir projekto akcininkai turi žinoti, kokia bus grupės organizacinė struktūra.

Jei jūs turite mažą, pvz., 10 IT specialistų dydžio grupę, jos narių atsiskaitymo už darbą struktūra,

be abejo, smarkiai skiriasi nuo struktūros, kai grupę sudaro 200 žmonių ir kurie dirba skirtingose

organizacijose, įsikūrusiose keliuose miestuose.

Kitas svarbus klausimas, turintis įtakos projektui, yra reikiamų specialistų suradimas. Čia

tenka atsižvelgti į darbuotojų sąjungų susitarimus, organizacijų vidaus taisykles, projekto grupės

prioritetus, grupės narių žinias.

Projekto grupės organizacinės struktūros planavimo metu nagrinėjamos įvairios sąsajos,

kurios gali turėti įtakos grupės valdymui, nustatomos narių pareigos ir atsakomybės,

organizacinė grupės struktūra, parengiamas projekto grupės valdymo planas.

6.1.1. Projekto sąsajos

Įvairių projekto sąsajų žinojimas labai praverčia formuojant projekto darbo grupę ir

ateityje valdant ją.

Organizacinės sąsajos. Tai į projektą įtrauktų įvairių jūsų organizacijos departamentų

savitarpio santykiai, kuriuos būtina valdyti. Todėl galimi įvairūs būdai projekto grupės

susirinkimams organizuoti, grįžtamajam ryšiui su grupės nariais palaikyti, informuoti apie

projekto stovį.

Techninės sąsajos. Šios sąsajos atspindi, kaip turėtų būti atliekami projekto techniškieji

darbai. Pvz., naują programų sistemą kuriantys žmonės turi suprasti ir realizuoti sąsajas su

egzistuojančiomis sistemomis arba darbine platforma, kurioje turi veikti sukurta sistema.

Sąsajos tarp darbuotojų. Tai savitarpio santykiai tarp projekto grupės narių. Idealus

atvejis, kai darbe nekyla konfliktų ar nesutarimų. Realiai gyvenime projekto vadovas turi būti



64

pasirengęs šalinti nesutarimus tarp grupės narių. Žinios apie žmogaus ankstesnius konfliktus gali

turėti įtakos sudarant projekto darbo grupę.

Projekto grupės organizacinės struktūros planavimo įeities duomenys yra išteklių

planavimo dokumentai, kurie buvo parengti projekto kainos planavimo metu. Išteklių poreikio

lentelė (žiūr. 5.1 lentelę) arba kiti išteklių planavimo dokumentai gali būti naudojami nustatant

projekto grupės narių pareigas ir atsakomybes.

6.1.2. Projekto grupės narių pareigos ir atsakomybės

Pareigų ir atsakomybių dokumente surašomos kiekvienos projekto grupelės ar kiekvieno

grupės nario pareigos ir atsakomybė. Į tokio dokumento rengimą kartais įtraukiamas ir projekto

sponsorius. Tai geras būdas projekto vadovui ir sponsoriui išsiaiškinti, kada ir kaip sponsorius

bus kviečiamas į pagalbą.

Pareigų ir atsakomybių dokumento pavidalas gali būti įvairus: lentelė, sąrašas, kt. Laikui

bėgant pareigos ir atsakomybė gali keistis. Nepamirškime laiku atnaujinti šio dokumento.

Pareigų ir atsakomybių svarstymo metu reikėtų iki smulkmenų išsiaiškinti sponsoriaus

suteiktus įgaliojimus projekto vadovui, ypač jeigu projekto nuostatuose (project chart) jie buvo

neaiškūs arba iš viso nebuvo nurodyti. Bet kokie įgaliojimai projekto vadovui samdyti ar atleisti

darbuotojus, naudoti projekto biudžeto lėšas turi būti dokumentuoti.

6.1.3. Projekto grupės organizacinės struktūros schema

Tokia schema ne tik suteikia vaizdumo, bet joje galima įžiūrėti ir tai, kas kam turėtų teikti

ataskaitas. Mažose projektų grupėse ataskaitos dažnai teikiamos tiesiai projekto vadovui. 6.1 pav.

parodytas projekto grupės organizacinės schemos pavyzdys.

6.1.4. Projekto grupės valdymo planas

Šiame plane surašoma visa projektui reikalingų darbuotojų rinkimo informacija.

Nurodoma, kada žmonės bus priimti ir kada bus atleisti, taip pat ką veiks, ypač jei jie bus priimti

ne visam projekto laikui. Projektų vadovas turi žinoti savo organizacijos taisykles, susijusias su

darbuotojų priėmimu ir atleidimu.

Projekto vadovas

Diegimo darbų vedėjas

Testavimo darbų vedėjas

Programavimo darbų vedėjas

1 programuotojas

2 programuotojas

3 programuotojas

1 tikrintojas

2 tikrintojas

1 diegėjas

2 diegėjas

3 diegėjas

6.1 pav. Projekto grupės organizacinės struktūros schemos pavyzdys



65

Jei jūsų projekte yra sudėtingos sąsajos, nesvarbu, organizacinės, techninės ar tarp

darbuotojų, reikia dokumentuoti, kaip numatote jas valdyti. Jeigu visos kuriamos programinės

įrangos testavimas turi būti pavedamas specialiai darbo grupei, būtina tai nurodyti grupės

valdymo plane. Jeigu jūsų grupė yra išbarstyta keliuose miestuose ar keliuose jūsų organizacijos

departamentuose, plane turite nurodyti, kaip valdysite grupę esant tokioms aplinkybėms.

Projekto grupės valdymo planas gali būti įvairaus sudėtingumo. Reikėtų pasidomėti, ar

jūsų organizacijoje nėra šios srities standartų ar šablonų.

6.2. Projekto grupės narių atranka

Projektui reikiamų darbuotojų atrankos būdai, kuriuos naudoja projektų vadovai, yra

labai įvairūs. Geriausia, kai projektų vadovas apklausia pageidaujančius dirbti projekto grupėje ir

turi įgaliojimus priimti tinkančius. Tačiau dažnai projektų vadovas turi tartis su savo

organizacijos funkcinių padalinių (technikos, ekonomikos, teisės, kt.) vadovais, prašydamas skirti

atitinkamos specialybės darbuotoją į projekto grupę.

6.2.1. Pretendentų į projekto grupę apklausa

Projekto vadovo galimybės ar įtaka atrenkant reikiamus darbuotojus priklauso nuo

organizacijoje esančių taisyklių. Jei jūsų organizacija yra matricos arba projektinio tipo, projekto

vadovas turi daugiau galių pasirenkant darbuotojus. Jei numatomi pokalbiai su kiekvienu

pretendentu į projekto grupę, tai reikėtų parengti jiems klausimus ir numatyti veiksnius, kuriais

remiantis bus priimami sprendimai. Rekomenduojamos klausimų grupės ir klausimai yra tokie:

a) darbo įgūdžiai:

- ar asmuo yra mokytas ir turi patirties reikiamiems darbams atlikti;

- ar turima patirtis yra pakankama tiems darbams atlikti;

b) darbo projektuose patirtis:

- ar asmuo anksčiau yra dirbęs projektuose;

- kokio tipo projektuose teko dirbti;

- kokias pareigas užėmė ankstesniuose projektuose;

c) bendravimo su žmonėmis įgūdžiai:

- ar asmuo sugeba dirbti grupėje;

- ar geri asmens bendravimo raštu ir žodžiu įgūdžiai;

- kokios yra stipriosios ir silpnosios kandidato savybės.

Tai tik pradinis klausimų sąrašas. Priklausomai nuo projekto specifikos, galimi klausimai

ir iš kitokių sričių.

6.2.2. Tarimasis su organizacijos funkcinių padalinių vadovais

Tradicinės struktūros organizacijose projektų vadovams tenka tartis su organizacijos

funkcinių padalinių vadovais ieškant projektui reikiamų darbuotojų. Priklausomai nuo to, kaip

organizacijoje tvarkomi darbuotojų klausimai, projekto vadovas gali turėti arba neturėti

galimybės apklausti potencialių kandidatų į projekto grupę. Bet netgi tuo atveju, kai kandidatai

apklausiami, tenka tartis su funkcinių padalinių vadovais, priimant galutinį sprendimą dėl jų

skyrimo į projekto grupę.



66

Funkcinių padalinių vadovai nori žinoti, ar jų darbuotojas projekte reikalingas visą ar tik

dalį darbo dienos. Jeigu projekto vykdymui priimamas žmogus, kuris turi įsipareigojimų kituose

darbuose, būtina išsiaiškinti, kiek valandų per dieną jis galės skirti jūsų projektui.

Matricos tipo organizacijose, kur projekto grupės nariai gali turėti keletą viršininkų (pvz.,

funkcinio padalinio, kuriam jis priklauso, vadovą ir projekto vadovą), labai svarbu išsiaiškinti

grupės narių atskaitomybės klausimą. Grupės narys už tam tikrus rezultatus turi būti

atskaitingas tik vienam vadovui.

Darbo našumo įvertinimas yra dar viena tema, kurią, priimant darbuotojus į projekto

grupę, turi apsvarstyti projekto vadovas ir funkcinių padalinių vadovai.

Projekto vadovas turėtų inicijuoti pasitarimus su kiekvieno susijusio funkcinio padalinio

vadovu, kad aptartų darbuotojų skyrimo klausimus ir priimtų nutarimus. Funkciniuose

padaliniuose dažnai būna didelis darbuotojų kiekis, ir jų vadovai nuolatos yra prašomi skirti

žmones į projektų grupes. Projekto vadovas, eidamas į tokius pasitarimus, turi būti aiškiai

apsibrėžęs savo poreikius ir turėti derybų su funkcinių padalinių vadovais planą. Keletas

patarimų, kad šie procesai būtų sklandesni:

a) pasitarimus su kiekvieno funkcinio padalinio vadovu reikėtų rengti skirtingu laiku.

Kalbėdamasis su funkcinių padalinių vadovais atskirai, projekto vadovas gali geriau susikaupti

ties savo projekto atitinkamais poreikiais ir geriau išnaudoti padalinio vadovo laiką. Svarstomi

klausimai turi būti aiškiai suformuluoti ir jiems aptarti turi būti skirta pakankamai laiko;

b) žinokite asmenis, kurie galėtų padėti jums sudarant projekto grupę. Gerai atlikite savo

namų darbus ir susipažinkite su žmonėmis, kurie pristato medžiagą kiekvieno funkcinio

padalinio vadovui. Naudokite savo parengtą projekto grupės valdymo planą, pareigų ir

atsakomybių lenteles, kt., prašydami reikiamų specialistų;

c) numatykite asmenis, kurių prašysite kiekvieno funkcinio padalinio vadovo. Jei jums

reikia specifinių sugebėjimų žmogaus, funkcinio padalinio vadovui įvardinkite konkretų asmenį

ir priežastis, kodėl jo reikia. Būkite pasirengę trumpai pristatyti projektą, jo strateginę svarbą ir

svarbą žmonių iš to funkcinio padalinio. Turėkite atsarginį planą, jei negaunate jums reikiamų

žmonių, būkite pasirengę deryboms;

d) pirmiausia prašykite labiausiai reikalingų žmonių. Laikydamiesi aukščiau išvardintų patarimų, galbūt ne visada gausite norimus žmones į

projekto grupę, tačiau tai padeda įgyti pasitikėjimą funkcinių padalinių vadovų tarpe, jei savo prašymus teiksite kvalifikuotu lygiu. Kokie susitikimo rezultatai bebūtų, išlaikykite gerus santykius su funkcinių padalinių vadovais. Jų gali prireikti ateities projektams.

6.2.3. Kiti projekto grupės sudarymo scenarijai

Gali būti atvejų, kai galimybių derėtis dėl reikiamų darbuotojų nėra. Pvz., yra tik vienas jums reikiamų sugebėjimų žmogus. Arba projekto sponsorius gali norėti paskirti į projekto grupę tam tikrus žmones. Toks projekto grupės narių paskyrimas gali būti geras arba blogas reikalas. Dar vienas projekto grupės formavimo būdas – tai reikiamų specialistų samdymas iš išorės, jei tokių nėra jūsų organizacijoje.



67

7. KOKYBĖS PLANAVIMAS

Programų sistemos kokybė – tai jos atitikimas projekto apimties apraše apibrėžtiems

funkciniams reikalavimams (ką sistema turės daryti), techniniams reikalavimams (veikimo,

sąsajų su kitomis sistemomis, eksploatacinių savybių, priežiūros), kūrimo standartams.

Projekto kokybės valdymas apima tris procesus: kokybės planavimą, veiklų kokybei

užtikrinti vykdymą ir kokybės kontrolę. Šiame skyriuje nagrinėjamas kokybės planavimas, kurio

tikslas yra įvardinti projektui tinkamus kokybės standartus ir apibrėžti jų taikymą, kad projekte

sukurtas produktas atitiktų numatytus reikalavimus.

Bendrajame projekto plane kokybės valdymo klausimai dažnai pamirštami ar

ignoruojami. Projekto grupės geri norai sukurti kokybišką produktą dar nereiškia, kad taip ir bus.

Kiekvienas iš mūsų kokybę suprantame įvairiai. Jeigu iš anksto nebūsime apsibrėžę kokybės

reikalavimų, tai sunku bus įvertinti projekte sukurto produkto kokybę.

Kokybės valdymas apima kartais sunkiai suprantamus dalykus. Jie nagrinėjami įvairiose

programose ir dokumentuose, kaip, pvz., bendrasis kokybės valdymas (TQM – Total Quality

Management), „Six Sigma“, ISO 9000, ISO 25010 ir kt. standartuose.

Svarbiausias kokybės planavime naudojamas dokumentas yra organizacijoje priimtos

kokybės taisyklės (politika). Projekto vadovui reikėtų išsiaiškinti, ar toks dokumentas yra jo

organizacijoje. Jeigu yra, tai reikėtų peržiūrėti jame nurodytus kokybės standartus ir išsiaiškinti,

kaip tuos standartus reikėtų taikyti jūsų projektui. Jei remiatės organizacijoje priimtomis

kokybės taisyklėmis, peržiūrėkite jas drauge su grupės nariais, projekto akcininkais ir įsitikinkite,

kad visi tas taisykles žino. Šias taisykles būtinai nurodykite jūsų projekto kokybės valdymo plane.

Būtų nepraktiška, jei, siekdami kokybės, tikrintume kiekvieną projekto plane numatytą

darbą. Yra keletas instrumentų ir būdų, kurie padeda projektų vadovams apsispręsti, ką ir kaip

reikėtų tikrinti, kad sukurtas produktas būtų kokybiškas. Priimti sprendimai kokybės vertinimo

klausimais turi būti užfiksuoti projekto kokybės valdymo plane.

7.1. Kokybės užtikrinimo priemonės ir būdai

Natūralu, kad projektų vadovai kelia sau klausimą, kokius gi kokybės užtikrinimo darbus

reikėtų įtraukti į projektą. Tam visų pirma būtina apibrėžti tas projekto veiklas, kuriose kokybės

klausimai yra labiausiai aktualūs ir kurių įtaka galutiniam projekto rezultatui yra didžiausia.

Jūsų organizacijoje esančiose kokybės taisyklėse gali būti nurodytos priemonės ir būdai,

darbų kryptys ir pastangos, naudotini kokybiškam produktui sukurti. Tai gali būti standartinės

priemonės, sutinkamos daugelyje projektų.

Pramoniniai standartai ar vyriausybės teisės aktai yra kita sritis, kurios projektų vadovai

jokiu būdu neturėtų pamiršti. Nesilaikymas jų reikalavimų gali užtraukti baudas ar

baudžiamuosius teismų nuosprendžius. Tokie reikalavimai gali būti susiję, pvz., su darbo sąlygų

arba produkto sauga.

Jei nėra nei jūsų organizacijos kokybės taisyklių, nei kokybę reguliuojančių standartų ar

teisės aktų, jūs galite naudoti keletą savų būdų, spręsdami projekto kokybės klausimus.

Apžvelkime keturias dažniausiai naudojamas priemones ir būdus: kainos-naudos analizę,



68

produkto veikimo išbandymą, struktūrinę (blokinę) schemą ir proceso diagramą bei kokybės

kainą.

7.1.1. Kokybės-naudos analizė

Šis būdas yra naudingas planuojant kokybės valdymą. Reikia įvardinti tas kokybės

užtikrinimo veiklas, kurios duoda didžiausią naudą mažiausiomis sąnaudomis.

Kokybės teikiama nauda – tai patenkinti klientų poreikiai, mažesnės sąnaudos

perdarymams, mažesnė bendroji projekto kaina. IT projektai dažnai turi testavimo planus.

Kainos-naudos analizės būdas gali būti naudojamas projekto kontroliniams taškams nustatyti,

kuriuose reikėtų kažką ištestuoti, taip pat pačiam testavimo tipui įvardinti.

7.1.2. Lyginamoji analizė

Lyginamoji analizė (benchmarking) yra toks tikrinimo būdas, kuriame lyginamos panašios

veiklos. Tai labai naudingas būdas, kai yra daromi turimos sistemos pakeitimai ar naujinimai

(upgrade). Jei keičiama darbo aplinka, norisi žinoti ar naujoji aplinka yra geresnė už buvusią.

IT projektuose gali būti palyginami kuriamos sistemos ir panašių egzistuojančių sistemų

reakcijos į užklausas laikai arba atsakymų išdavimo greičiai. Lyginamoji analizė yra tinkamas

būdas kokybei nustatyti tik tuomet, kai yra teisingi duomenys apie ankstesnės sistemos

galimybes ir yra pakankamai panašumų, kad dviejų sistemų lyginimas būtų prasmingas.

7.1.3. Struktūrinė (blokinė) projekto schema ir diagramos

Proceso struktūrinė schema ir duomenų sekų diagramos (DFD – Data Float Diagram) savo

esme yra panašios, nes jomis stengiamasi grafiškai pavaizduoti proceso eigą.

Struktūrine schema paprastai vaizduojami sąryšiai tarp įvairių projekto elementų.

Sudarius struktūrinę schemą arba DFD, lengviau yra pastebėti projekte galimų problemų

atsiradimo vietą ir laiką. Jūs galite nustatyti kontrolinius taškus, kur reikėtų įvertinti tam tikrų

darbų rezultatų kokybę ir tik po jų patikrinimo daryti kitus darbus.

7.1.4. Kokybės kaina

Kokybei pasiekti reikia papildomo darbo. Kokybės kaina yra visų darbų, kuriais

užtikrinamas projekto rezultatų atitikimas nustatytiems reikalavimams, kaina. Yra trys kokybės

kainos dalys: prevencinė, įvertinimo ir neatitikimų šalinimo.

Prevencinė kaina. Ji siejama su veiklomis, kurios padeda išvengti kokybės problemų. Šią

kainą sudaro kokybės planavimo, darbuotojų mokymo ir kai kurių produktų ar procesų tikrinimo

išlaidos.

Planuojant projekto kainą, prevencinės išlaidos turi būti numatomos programų sistemų

kodų tikrinimo darbams įvairiuose projekto etapuose. Tai gali būti atskirų modulių testavimas,

integracinis testavimas, kai tikrinama keletas sujungtų modulių, o kai kuriais atvejais ir visos

sistemos testavimas. Visų testų tikslas yra kiek galima anksčiau projekto eigoje nustatyti galimas

problemas.

Įvertinimo kaina. Tai išlaidos darbams, kad defektų turintis produktas nepatektų pas

naudotojus. Jų reikia sukurto produkto inspektavimo (apžiūros), testavimo ir formalaus kokybės

audito darbams.



69

Sukurto produkto pridavimo užsakovui metu testavimui išleistos lėšos yra produkto

įvertinimo kaina. Projekto pabaigoje sukurtą produktą testuoja nedidelė naudotojų grupė.

Neatitikimų šalinimo kaina. Jei sukurtas produktas pridavimo užsakovui bandymų metu

neatitinka kažkurių reikalavimų, projekto grupė privalo juos pašalinti. Neatitikimų šalinimo

kainą sudaro baudos už prastovas (vėlavimą), papildoma parama naudotojams, klaidų produkte

šalinimo išlaidos, kt.

Prisiminkime, kad kokybė yra vienas iš projektą ribojančių veiksnių, todėl projekto

vadovai tam turi skirti reikiamą dėmesį. Iš tikrųjų tai yra balansavimas tarp projekto kainos,

sugaišto laiko ir kokybės. Kokybei pasiekti reikia laiko. Todėl projektų vadovai turi numatyti

atitinkamus kokybės užtikrinimo žingsnius ir būti pasirengę paaiškinti neatitikimams šalinti

reikiamų lėšų poreikį.

Specifiniai kokybės užtikrinimo darbai turi būti įvardinti ir nurodyti projekto kokybės

valdymo plane.

7.2. Kokybės valdymo planas

Kokybės valdymo plane surašomi visi projekte kuriamo produkto kokybei užtikrinti

reikalingi darbai, procedūros, kaip tie darbai turi būti atliekami ir tiems darbams atlikti reikalingi

ištekliai.

Aprašant procedūras pateikiama smulkesnė informacija apie laukiamus kokybės

užtikrinimo darbų rezultatus ir žingsnius, kurie bus daromi tikrinant kokybės standartų

laikymąsi projekto eigoje. Kokybės standartai ir tikrinimo būdai, kaip tų standartų laikomasi,

plane turi būti apibrėžti aiškiai. Tikrinimo būduose savo ruožtu naudojamos metrikos,

kontroliniai sąrašai, kriterijai.

Metrika yra išmatuojamas dydis, kuris projekto eigoje turi būti stebimas. Bet kuriai

projekto sričiai galima apsibrėžti metrikas. Pvz., kuriant kažkokią programinę įrangą, jos kokybė

gali būti vertinama matuojant jos dydį (kompaktiškumą), veikimo greitį, tikslumą, parduotų

egzempliorių kiekį (paklausą), priežiūros patogumą, kt.

Kontroliniai sąrašai (checklists) yra priemonė, kurioje nurodomas darbui atlikti būtinų

žingsnių rinkinys. Kai tik žingsnis atliekamas, jis išbraukiamas iš sąrašo. Tokia priemonė padeda

stebėti, ar žingsnis buvo padarytas, kada jis buvo padarytas, kas jį atliko.

Užsakovams testuojant produktą priėmimo metu, kontroliniame kokybės sąraše gali būti,

pvz., tokie punktai:

- testavimo darbų, kuriuos atliks 10 naudotojų, tvarkaraštis;

- 20 testavimo variantų;

- testavimo variantų peržiūra ir naudotojų pritarimas jiems;

- testavimo variantų kopijų parengimas kiekvienam testavimo dalyviui;

- mokymai 10-čiai naudotojų, kaip reikėtų testuoti, ir mokymo rezultatų registravimas;

- naudotojų pastabų peržiūra;

- testuoto produkto neatitikimų reikalavimams registravimas.



70

Testavimo darbams gali būti samdomos nepriklausomos tvirtinimo ir tikrinimo

organizacijos (IV&V - Independent Validation and Verification Companies). Taip elgiamasi

dideliuose IT projektuose.

Kriterijai. Kalbant apie projektų kokybės valdymą, kaip ir projekto darbų grafiko

planavime, naudojama etapo (milestone) sąvoka. Jei jūsų projektas buvo skaidomas į etapus, tai

etapų rezultatams įvertinti gali būti naudojami ir kokybės kriterijai. Tokiu atveju jūsų projekto

kokybės valdymo plane turi būti nurodyti kriterijai, kuriais remiantis bus vertinama, ar

kiekvienas projekto etapas buvo užbaigtas sėkmingai. Programų sistemų kūrimo projektuose

dažnai atliekamos testų serijos, kad patvirtintume kiekvieno etapo rezultatų kokybę.

Kokybės valdymo plane taip pat turi būti nurodyta, kaip projekto sponsoriai ir akcininkai

turėtų peržiūrėti kokybės užtikrinimo darbų rezultatus. Visa tai turi būti dokumentuota. Projekte

sukurtas produktas laikomas užbaigtu, kai priėmimo bandymų rezultatus patvirtina naudotojai

ar užsakovo įgalioti asmenys.



71

8. RIZIKOS PLANAVIMAS

Bet kokio projekto planavimas savo prigimtimi yra optimistinė veikla, nes daroma

prielaida, kad viskas vyks sklandžiai. Tačiau projektų metu dažnai iškyla nenumatytos

problemos. Todėl būtina valdyti riziką (įvertinti pavojus), kad išvengtume netikėtumų arba bent

jau sumažintume problemas. Rizikos valdymas, priešingai projekto planavimui, savo prigimtimi

yra pesimistinė veikla. Tai nesibaigiantis mokymasis iš patirties, tai vertinimas, kokie reikalai gali

pakrypti negera linkme ir kaip to galima būtų išvengti.

Rizika turi būti valdoma visą laiką, nuo projekto pradžios iki jo pabaigos. Viso to tikslas yra

įvertinti riziką (pavojus) anksčiau, kad ji nesukeltų problemų. Tai padeda išvengti krizių, kurioms

įveikti reikėtų mažinti projekto apimtį, daryti kitokius pakeitimus arba ilginti projekto darbų

grafiką.

Kas yra rizika? Rizika tai ne problema. Problema - tai uždavinys, reikalaujantis tyrimo,

sprendimo. Rizika - tai nepageidaujamas dalykas, kuris gali atsitikti, bet gali ir neatsitikti. Rizika

gali būti įvertinta tokiais dydžiais, kaip projekto kai kurių reikalavimų neįgyvendinimas, projekto

darbų grafiko terminų nukėlimas, kainos padidėjimas.

IT projektuose rizikos reikšmingumas yra kur kas didesnis nei kitokio tipo projektuose.

Pvz., statybų projektuose išlaidų padidėjimo 50% rizika yra retas atvejis (jei nesukčiaujama). IT

projektuose rizikos poveikis išlaidoms gali siekti net kelis šimtus procentų.

Rizikos planavimas – tai veiksmų numatymas, projekte iškilus nenumatytoms

aplinkybėms. Jos planavimas susideda iš trijų pagrindinių komponentų: potencialių rizikos

veiksnių (faktorių, priežasčių) įvardinimo, kiekvieno rizikos veiksnio potencialios įtakos

projektui analizės ir reakcijos būdo į kiekvieną rizikos veiksnį numatymo.

Autoriaus filologinė pastaba: lietuvių kalboje žodis „rizika“ turi tik vienaskaitą (pvz., kaip

ir „fizika“). Rizikos veiksnių (faktorių, priežasčių) gali būti daug.

8.1. Rizikos veiksnių įvardinimas

Visi projektai turi riziką (tikimybę neįvykdyti projekto esant nustatytiems ribojimams –

laikui, kainai, kokybei). Projekto grupės nariai gali įvardinti projekto elementus, kurie kelia jiems

abejones. Tai gali būti pernelyg glaustas darbų grafikas, grupės narių patirtis arba

nepasitikėjimas savo, kaip sukurto produkto pardavėjo, sugebėjimais. Deja, dar daug projektų

vadovų neskiria pakankamai laiko projekto rizikos veiksniams aptarti su grupės nariais ir su

akcininkais. Rizikos veiksnių įvardinimas yra procesas, kurio metu nustatomi ir plane

užfiksuojami rizikos veiksniai, dėl kurių gali sutrikti projektas.

Rizikos veiksniai gali būti globalieji, t. y. apimantys visą projektą, ir lokalieji,

atsirandantys projekto eigoje. Globaliesiems rizikos veiksniams priskiriami galimi projekto

finansavimo sutrikimai, bendrasis pagrindinių grupės narių patirties lygis, vadovavimo patirtis ar

strateginė projekto reikšmė. Dažniausiai projektų vadovai, sponsoriai ir klientai kreipia dėmesį

tik į globaliuosius rizikos veiksnius.

Lokaliuosius rizikos veiksnius grupės nariai nurodo, remdamiesi darbų grafiku ir

užduotimis, kurias jie turi atlikti nustatytu laiku ir už numatyto dydžio lėšas. Gali būti rizikos



72

veiksniai, susiję tik su tam tikrais projekto etapais arba su tam tikrais projekto darbais. Lokaliųjų

rizikos veiksnių, galinčių atsirasti projekto eigoje, įvardinime turi dalyvauti pagrindiniai grupės

nariai ir atitinkamų sričių ekspertai.

Projekto grupei gali būti užduota daug klausimų, susijusių su įvairiais projekto etapais ar

darbais (užduotimis). Rizikos veiksniams įvardinti grupės nariams gali būti užduodami tokio

pobūdžio klausimai:

- ar užduotis yra kritiniame projekto darbų kelyje?

- ar užduotis yra sudėtinga?

- ar užduotis susijusi su naujomis ar nežinomomis technologijomis?

- ar užduotis susijusi su viena ar keletu kitų užduočių?

- ar turėjote problemų su panašiomis užduotimis ankstesniuose projektuose?

- ar užduotis priklauso nuo išorės veiksnių (leidimų reikalingumo, kažkokių kursų

išklausymo)?

- ar yra nepatyrusių darbuotojų, paskirtų užduočiai vykdyti?

- ar pakankamo dydžio ištekliai paskirti užduočiai?

- ar užduotis susijusi su sistemų integravimu?

- ar jums žinoma aparatinė ir programinė įranga, kurią naudosite užduočiai vykdyti?

Dėl tų užduočių, kurioms į aukščiau minėtus klausimus atsakoma taip, papildomai kelkite

dar šiuos klausimus:

- kokie ginčai ar problemos gali kilti?

- kokios problemos panašiose užduotyse yra kilę anksčiau?

- kokios gali būti problemų priežastys?

Įvardinus visus galimus jūsų projekto rizikos veiksnius, pereinama prie veiksnių analizės,

kad išsiaiškintume, kokią įtaką projektui jie iš tikro turi.

8.2. Rizikos analizė

Rizikos analizės metu siekiama išsiaiškinti, kurie įvardinti rizikos veiksniai yra

pavojingiausi jūsų projektui.

Yra sukaupta daug informacijos apie rizikos analizę, ir tam gali būti naudojami įvairūs

metodai. Rizikos analizė atliekama kokybiniu ir kiekybiniu požiūriais. Kokybinė rizikos analizė

nagrinėja rizikos atsiradimo tikimybę ir jos galimo poveikio projektui dydį. Kiekybinė rizikos

analizė naudoja sudėtingus matematinius metodus rizikos tikimybei, jos poveikiui projekto

tikslams apskaičiuoti. Modernesni kiekybinės analizės metodai apima jautrumo analizę,

sprendimų priėmimo medžio analizę, modeliavimą Monte Karlo metodu, apklausas.

Organizacijos, naudojančios šiuos rizikos valdymo metodus, dažniausiai turi savus ekspertus,

kurie ir padeda projektų grupėms. Kiekybinės analizės būdų čia mes nenagrinėsime.

Kiek plačiau panagrinėkime kokybinę rizikos analizę., kuriai atlikti nereikia specialių

priemonių ar žinių. Naudodama šablonus arba kriterijų rinkinius, projekto grupė gali

susikoncentruoti ties tais rizikos veiksniais, kurie reikalauja didžiausio dėmesio.

Kokybinės rizikos analizės metu įvardinti rizikos veiksniai charakterizuojami tikimybe ir

galimo neigiamo poveikio dydžiu projektui. Tai sunku išreikšti kiekybiškai, todėl tikimybė ir



73

poveikis dažniausiai nurodomi taip: aukštas, vidutinis arba žemas. Laikantis tokio vertinimo,

sudaroma visų įvardintų rizikos veiksnių apibūdinimo lentelė. Kaip parodyta 8.2 lentelėje, rizikos

veiksnių apibūdinimas gali suteikti informacijos jų prioritetui nustatyti, t. y. kokiam rizikos

veiksniui bus skiriamas didesnis dėmesys, o kokiam mažesnis. Tai padeda sukurti projekto

rizikos valdymo strategiją. Apskritai, aukšto poveikio ir aukštos tikimybės rizikos veiksniams

skiriamas didžiausias dėmesys. Projektuose turi būti skiriama kažkiek išteklių rizikos

padariniams sušvelninti arba projekto reikalavimai, darbų grafikas ir kaina turi būti atitinkamai

derinami.

8.2 lentelė. Rizikos veiksnių apibūdinimo lentelė

Tikimybė

Aukšta Vidutinė Žema

Poveikis

Aukštas Veiksnys Nr. 1

Veiksnys Nr. 6

Veiksnys Nr. 4 ---

Vidutinis Veiksnys Nr. 3 Veiksnys Nr. 2

Veiksnys Nr. 5

Veiksnys Nr. 7

Žemas Veiksnys Nr.8 --- ---

8.3. Reakcija į riziką

Rizikos analizės metu rizikos veiksniai surikiuojami prioritetų tvarka. Reakcijos į rizikos

veiksnius planavimas yra toks procesas, kurio metu nustatoma, kaip reikėtų reaguoti į kiekvieną

rizikos veiksnį. Skiriami tokie keturi reakcijos į rizikos veiksnius būdai:

- rizikos vengimas yra projekto plano keitimas, šalinant iš jo rizikingus darbus.

- rizikos nukreipimas kitiems. Šiuo atveju atsakomybę už riziką stengiamasi perkelti

trečiosioms šalims;

- rizikos mažinimas, t. y. rizikos veiksnių tikimybės ir poveikio dydžio mažinimas. Tai gali

būti riziką keliančių projekto reikalavimų švelninimas. Pvz., rizika, kad sukurtas

produktas nebus priimamas, jei jis neatitinka 2% reikalavimų, gali būti sumažinta,

padidinus šį procentą iki 5%;

- rizikos prisiėmimas. Paprastai prisiimama žemesnio prioriteto rizika arba taip

elgiamasi, kai nėra kitos išeities.

8.3.1. Prevencinės priemonės

Prevencinės (profilaktinės) priemonės – tai potencialių rizikos veiksnių peržiūra, siekiant

išsiaiškinti galimus kelius problemoms išvengti arba jų atsiradimo tikimybei sumažinti.

Prevenciniai veiksmai yra rizikos vengimo ir rizikos mažinimo būdų kombinacija. Sąnaudos

šiems veiksmams atlikti priklauso nuo rizikos veiksnių galimo neigiamo poveikio projektui

laipsnio. Projekto bendrajame plane reikėtų numatyti tokius darbus ir lėšas jiems atlikti. Todėl

projekto grupės narių klausinėjama:



74

- ką galima būtų padaryti, kad išvengtume problemų?

- ką galima būtų padaryti, kad sumažintume problemos atsiradimo tikimybę?

- ar apsimoka daryti tuos veiksmus problemoms išvengti?

- ar yra numatyti ištekliai tokiems veiksmams atlikti?

8.3.2. Veiksmai nenumatytais atvejais

Projekto grupės prisiimama rizika apima ne tik tuos veiksnius, atsakomybę dėl kurių ji

prisiima, bet ir nenumatytus veiksnius. Jei atsiradusi problema nepriklauso projekto grupės

kompetencijai (pvz., teisės aktų pasikeitimai, streikai), veiksmų nenumatytais atvejais plane

turėtų būti nurodytas labiausiai tikėtinas problemos poveikis projektui ir ką reikėtų daryti tokiu

atveju. Reikėtų būti pasiruošusiems atsakyti į tokius klausimus:

- jeigu problema negali būti numatyta, koks galimas didžiausias jos poveikis projektui;

- ką reikėtų daryti, norint sumažinti tokios problemos poveikį projektui?

Projekto rizikos valdymo planas gali būti 8.3 lentelės pavidalo.

8.3 lentelė. Projekto rizikos valdymo plano pavyzdys

Rizikos veiksnys Tikimybė Poveikio dydis Galimos pasekmės Prevencinės arba nenumatytų atvejų

priemonės

Veiksnys Nr.1 aukšta aukštas aukštos priemonės aprašas

Veiksnys Nr. 2 vidutinė vidutinis žemos nėra

Veiksnys Nr. 3 aukšta vidutinis vidutinės priemonės aprašas

Toks rizikos valdymo planas gali būti pateiktas projekto sponsoriui, akcininkams. Jis gali

būti transformuotas ir į kitokį pavidalą, pvz., rizikos stebėjimo planą.



75

9. KOMUNIKACIJŲ PLANAVIMAS

Projektų vadovai didesnę savo darbo laiko dalį (50-80%) sugaišta komunikacijoms su

savo organizacijos vadovybe, darbo grupės nariais, subrangovais, tiekėjais, sponsoriais,

akcininkais. Poreikis komunikuoti atsiranda jau pačioje projekto pradžioje, kai tik parengiami

projekto nuostatai ir jūs formaliai paskiriamas projekto vadovu. Projekto nuostatai yra pirmas

dokumentas, kurį jau reikia aptarti su akcininkais. Nežiūrint to, kad projektų vadovai žino, kiek

daug laiko tenka sugaišti įvairioms komunikacijoms, tačiau retai kada projekto pradžioje

planuojamas tam reikalingas laikas.

Gera komunikacija toli gražu nėra vien raštų (el. pašto žinučių, popierinių dokumentų)

siuntinėjimas. Reikia suplanuoti, kas ir su kuo projekto eigoje turėtų palaikyti ryšį, dalintis

projekto informacija. Komunikacijų planavimas yra procesas, kurio metu nustatoma:

- asmenys ar jų grupės, kurie turi būti informuojami apie projektą;

- kokią informaciją jie turėtų gauti;

- kaip ta informacija turėtų būti perduodama.

Apžvelkime bendruosius komunikacijų principus (strategiją) projekto metu ir keletą

specifinių komunikacijų su projekto grupės nariais ir akcininkais klausimų.

9.1. Komunikacijų strategija

Kiekvienam žmogui tenka bendrauti su kitais darbo arba asmeniniais reikalais. Nežiūrint

to, kad bendrauti tenka nuolatos, komunikacijų planavimui ar organizavimui žmonės skiria per

mažai dėmesio.

Nesvarbu, su kuo mums tektų bendrauti, yra keletas paprastų žingsnių, kurie bendravimą

daro efektyvesnį. Iš anksto apgalvokite tokius dalykus, kaip:

- kokį klausimą norite aptarti;

- su kuo norite aptarti rūpimą klausimą;

- pašnekovo (informacijos gavėjo) palankumas ar šališkumas svarstytinais klausimais;

- kaip reikėtų bendrauti;

- žinutės suformulavimas ir siuntimas.

Apgalvoti diskusijų planą iš anksto yra ypač svarbu, kai reikia svarstyti jautrius arba

prieštaringus klausimus. Daug lengviau būna pradžioje gerai apsvarstyti savo siūlymus ir po to

juos išdėstyti pašnekovui, nei vėliau atsiprašinėti ar atsisakyti savo neapgalvotų siūlymų.

Rengiamame komunikacijų plane reikėtų nurodyti:

- kam reikės informacijos apie jūsų projektą;

- ryšių palaikymo su asmeniu ar grupe tikslus;

- komunikacijų būdą (susitikimai, dokumentų siuntimas, kt.);

- už ryšių palaikymą atsakingus asmenis;

- kaip dažnai turėtų būti kontaktuojama.

Komunikacijų plano pavyzdys parodytas 9.1 lentelėje.



76

9.1 lentelė. Projekto komunikacijų plano pavyzdys

Su kuo palaikomas

ryšys

Komunikacijų

tikslai, klausimai

Komunikacijų

būdas

Už komunikaciją

atsakingas asmuo

Komunikacijų

dažnumas

Projekto grupė Sričių funkcinė

priklausomybė,

projekto tikslai,

kontrolinius taškus

įtakojantys veiksniai,

rizika

Projekto darbų

grafikas,

grupės susirinkimai,

kontrolinis sąrašas

Projekto vadovas Kas savaitę

Projekto sponsorius Projekto eigos

pristatymas

Projekto ataskaita

Projekto vadovas Kas savaitę

Rizika Kontrolinis sąrašas

Finansai Projekto apžvalga,

biudžeto suvestinė

Funkcinės grupės

vedėjas

Kas mėnesį

Projekto vykdytojai

(subrangovai)

Kontroliniai taškai,

finansai

Darbų eigos

ataskaita

Projekto sponsorius Kas mėnesį/

kas ketvirtį

Darbų eiga Pokalbiai telefonu Projekto vadovas Kas savaitę/

kai reikia

Kiti

9.2. Komunikacija su projekto grupės nariais

Projekto vadovo pagrindinis darbas yra palaikyti ryšį su grupės nariais. Jo pareiga yra

užtikrinti, kad visi grupės nariai žinotų projekto tikslus ir savo indėlį į galutinį rezultatą.

Projekto vadovo kontaktai su grupe gali būti formalūs ir neformalūs. Formalūs kontaktai

apima projekto pradžios susirinkimo, darbo grupės planinių susirinkimų organizavimą, rašytinių

ataskaitų rengimą, grupės formavimą ir kitas veiklas, kurias tenka vykdyti su grupe. Neformalūs

kontaktai – tai telefoniniai pokalbiai ar el. laiškų siuntimas ir gavimas iš grupės narių, pokalbiai

susitikus koridoriuje ar ekspromtu (be pasirengimo) vykstantys pasitarimai.

Projekto vadovui labai svarbu mokėti pasirinkti bendravimo su kiekvienu grupės nariu

stilių. Iš grupės narių gaunama informacija gali padėti užmegzti geresnius ryšius su jais. Jeigu jūs

rengiate darbo grupės susirinkimo darbotvarkę, paklauskite narių, ar jie neturi pasiūlymų

darbotvarkei. Grupės nariai gali turėti pasiūlymų dėl susirinkimų vedimo tvarkos ir dažnumo

arba susirinkimo protokolo formato, pagrįstų savo patirtimi ankstesniuose projektuose. Projekto

vadovas gali nepriimti kai kurių pasiūlymų, tačiau laiko skyrimas jiems išklausyti ir pasiūlymams

peržiūrėti padeda suformuoti darnesnę grupę.

Kiekvienas turime labiausiai priimtinus sau bendravimo būdus. Vieni grupės nariai gali

labiau mėgti el. paštą, kiti – telefoninius pokalbius. Neformaliems kontaktams su grupės nariais

palaikyti projekto vadovas turėtų naudoti kiekvienam iš jų labiausiai priimtiną komunikacijos

būdą.



77

9.3. Komunikacija su akcininkais

Kad galėtume parengti komunikacijų su kitais akcininkais planą, visų pirma reikia

sužinoti kas jie yra. Šios mokymo medžiagos 2 skyriuje „Projekto inicijavimas“ nurodėme keletą

tipinių projekto akcininkų: projekto sponsorius, organizacijos funkcinių padalinių vadovai,

pirkėjai, galiniai naudotojai. Prisiminkime, kad akcininku yra tas, kas vienaip ar kitaip priklauso

nuo projekto rezultatų.

Dideliuose projektuose, apimančiuose platų naudotojų ratą, galime pamatyti akcininkų,

kurie nedalyvauja projekte arba gerai nežino savo vaidmens jame. Taip dažniausiai būna su

didelėmis programų sistemomis arba naujais produktais, kurie dislokuojami keliuose

geografiškai nutolusiuose regionuose. Jeigu akcininko atsakingasis atstovas gerai nesupranta,

kokią įtaką projektas turės jų organizacijai, būtina su juo susisiekti ir paaiškinti visa tai. Gali būti

ir taip, kad tas atstovas yra labai užimtas ir todėl nekreipia dėmesio į jūsų projektą. Todėl

žinodami, kad atstovas gali skirti jums tik 5 minutes laiko, labai svarbu išnaudoti šį laiką

protingai.

Tokiais atvejais gali būti naudinga parengti projekto pristatymo planą, kuriame būtų

aprašyti pagrindiniai klausimai, su kuriais norite supažindinti akcininko atstovą. Jame reikėtų:

- nurodyti tuos projekto plano aspektus, kuriuos norite pristatyti;

- išvardinti žinomą arba tikėtiną projekto naudą akcininkui;

- apibrėžti pagrindinę informaciją, kurią būtina perduoti visiems akcininkams.

9.2 lentelėje pateiktas projekto, skirto naujai viešųjų pirkimų sistemai sukurti, pristatymo

akcininkams planas. Šiame pavyzdyje parodyti trys projekto pristatymo variantai, besiskiriantys

savo išsamumu. Labai besidominčiam akcininkui projekto pristatymas gali trukti net porą

valandų. Taigi, toks planas naudingas šiais dviem požiūriais:

- jūs turite kruopščiai apgalvotą projekto pristatymo variantą, kai pristatymo laikas yra

labai ribotas;

- jūs esate pasirengę kitam susitikimui arba galite tęsti esamą, jei akcininkas staiga

paprašytų platesnių paaiškinimų.

Komunikacijų planą jūs turėtumėte peržiūrėti su sponsoriumi. Jeigu jūsų projekte reikia

palaikyti ryšius su darbus administruojančios (prižiūrinčios) grupės nariais, sponsorius gali

padėti parengti komunikacijų planą, įvardindamas tai grupei reikiamą informaciją, kaip ir kada

reikėtų su ja kontaktuoti. Šalia informacijos platinimo būdo komunikacijų plane gali būti

nurodyta, kaip jūs rinksite ir saugosite informaciją, kaip ją galima būtų gauti neplanuotu laiku,

kaip koreguosite komunikacijų planą.



78

9.2 lentelė. Projekto pristatymo akcininkams plano pavyzdys

Projektas: Viešųjų pirkių sistemos sukūrimas. Akcininkų grupė: viešųjų pirkimų specialistai.

Bendroji projekto

apžvalga

(5 minutės)

Pagrindinių projekto

punktų pristatymas

(30 minučių)

Detalus projekto

pristatymas

(1-2 valandos)

Kodėl

(vykdomas projektas)

Platus produkto panaudojimas Akcininkų išlaidų

sumažėjimas

Palanki rinkos tyrimų

prognozė

Ką

(tai reiškia

akcininkams)

Pagerės viešųjų pirkimų

procedūros, reikės specialistų

mokymo

Sistemos funkcijų

išplėtimas ir pagerinimas.

Mokymų nauda

Sistemos funkcijų

detalės.

Sistemos demonstracija

Kaip

(bus pasiekti projekto

tikslai)

Parinktuose taškuose

produktas bus įdiegtas iki

kovo 7 d.

Perkančiųjų organizacijų

tikslai. Specialistų

mokymų datos

Viešųjų pirkimų

specialistų patirtis

Kada

(sistemą pradės platinti

akcininkams)

Tiekimo grupė pradės

sistemos pardavimus lapkričio

9 d.

Mokymų rengimas.

Mokymai naudoti sistemą

Sąsaja su žmoniškųjų

veiksnių grupe, užsakovų

aptarnavimas



79

10. PIRKIMŲ PLANAVIMAS

Daugelyje projektų dalis darbų atliekama pasitelkus vykdytojus iš išorės. Dideliuose IT

projektuose organizacijas taip elgtis verčia tos aplinkybės, kad pasibaigus projektui nemažai

žmonių lieka be darbo ir juos reikia atleisti.

Naudojant išorinius išteklius reikia būti susipažinusiems su pirkimų procedūromis.

Pirkimų planavimas yra procesas, kurio metu įvardinamos jūsų projektui reikalingos prekės ir

paslaugos, kurias reikia įsigyti iš išorinių organizacijų. Tokiais atvejais projekto vadovas tampa

pirkėju. Prekes ir paslaugas teikiančios organizacijos vadinamos įvairiai: pardavėjais, tiekėjais,

konsultantais arba rangovais.

Pirkimo procesas yra sudėtingas, todėl į pagalbą tenka kviestis teisininkus. Didelėse

organizacijose yra netgi atskiri pirkimų departamentai.

Pirkimų planavimas prasideda nuo sprendimo pirkti prekes ar paslaugas priėmimo.

Priėmus tokį sprendimą, būtina išsiaiškinti, kokio tipo sandoris jums būtų geriausias. Toliau

būtina parengti tikslią darbo užduotį (SOW – Statement Of Work), ką atlikti prašysite išorines

organizacijas. Ši užduotis dedama į kvietimą teikti pasiūlymus (RFP – Request For Proposal) ir

išplatinama tiekėjams. Gautiems pasiūlymams įvertinti ir išrinkti laimėjusį tiekėją turi būti

parengti kriterijai.

Visų pirma apžvelkime aplinkybes, kurios gali versti jus pirkti prekes ar paslaugas iš

išorinės organizacijos.

10.1. Kurti patiems ar pirkti?

Pirkimų planui parengti visų pirma reikia atlikti vadinamąją kurti ar pirkti analizę. Tai

kompromiso tarp darysime patys ar pirksime paslaugas arba gatavą produktą iš kitur

pasiekimas. Sprendimui kurti patiems ar pirkti paslaugas arba gatavą produktą priimti įtakos turi

nemažai veiksnių. Panagrinėkime juos.

Įranga. Jeigu jūs kuriate naują programų sistemą ir jai įdiegti reikia naujos aparatinės

įrangos (AĮ, hardware), tokią AĮ jūs turite pirkti iš kitos organizacijos. Yra ir kita galimybė –

nuomoti tokią AĮ. Tačiau tokiu atveju reikia atsižvelgti į keletą kitokių aplinkybių, kaip tikėtina

jūsų sukurtos sistemos gyvavimo trukmė, ar AĮ bus galima dalintis su kitais, kad pasidalintume

nuomos išlaidas, kt.

Darbuotojų samdymas. Žmonės iš išorės gali būti samdomi visam projektui vykdyti arba

tik atskiriems projekto darbams atlikti.

Viso projekto vykdymui žmonės iš išorės dažniausiai samdomi tais atvejais, kai

organizacija neturi patirties projektams vykdyti. Jeigu jūsų programuotojai nemoka programuoti

tokia kalba, kurios reikalauja kuriamas produktas, jūs galite samdyti tokią patirtį turinčius

žmones. Tačiau reikėtų vengti samdyti visus programuotojus, kad įvykdytumėte projektą. Tik

reikiamų sugebėjimų programuotojų samdymas projekto darbams atlikti yra geresnis variantas.

Jei naujoji sistema baigus projektą bus prižiūrima savo darbuotojų jėgomis, plane būtina

nurodyti, kaip turimi darbuotojai bus mokomi arba kad priežiūros darbams bus priimami nauji

darbuotojai.



80

Samdyti darbuotojus iš šalies gali tekti kritinės trukmės projektuose, kai per numatytą

laiką sunku baigti projektą savo specialistų jėgomis.

Kitos prekės ar paslaugos. Projektai gali turėti specifinių tikslų, kuriuos įgyvendinti geriau

pasirengę yra kai kurie tiekėjai. Jeigu jūs diegiate naują komercinę programų sistemą, projekto

darbų grafike galite numatyti organizacijos darbuotojų mokymus savo jėgomis, tačiau galite ir

pirkti mokymo paslaugas. Jei jūs neturite mokymo kursų rengėjų ir vedėjų, matyt, geriau būtų

samdyti tokių paslaugų tiekėjus. Jums reikalingus kursus ir jiems vesti reikalingas priemones kai

kurie tiekėjai jau gali būti seniai parengę.

Projekte kuriamo produkto nepriklausomas tvirtinimas-tikrinimas (IV&V - Independent

Validation and Verification) ir testavimas yra geri samdomų paslaugų pavyzdžiai. Kol jūs

įsteigsite savo organizacijoje formalų testavimo departamentą, galintį dirbti laikantis nustatytų

procedūrų, žymiai geriau yra pasamdyti testavimo srityje jau seniai dirbančius specialistus.

10.2. Sandorių tipai

Sandoris yra teisės dokumentas, kuriame nurodomi sutarti atlikti darbai, kaip už darbą

turi būti atlyginama ir įvairios baudos už susitarimų netesėjimą. Teisininkus rengiančiose

mokyklose skaitomi ištisi sandorių valdymo kursai. Čia mes išsiaiškinkime tik sandorių tipus, nes

šių žinių dažnai prireikia projektų vadovams. Dažniausiai sutinkami šių trijų kategorijų sandoriai:

fiksuotos kainos, išlaidas padengiantieji bei laiko ir medžiagų apmokėjimo. Panagrinėkime juos

smulkiau.

10.2.1. Fiksuotos kainos sandoriai

Fiksuotos kainos sandoriuose tiekėjas pasižada atlikti darbus už fiksuotą kainą. Šio tipo

sandorius geriausia naudoti tada, kai yra gerai apibrėžtas kuriamas produktas ir yra nemažai

informacijos iš ankstesnių panašių projektų. Produktams kurti ar paslaugoms tiekti, kurios nėra

gerai apibrėžtos ar anksčiau tai dar nebuvo daryta, fiksuotos kainos sandoriai yra rizikingi abiem

sandorio pusėms: pirkėjui (užsakovui) ir tiekėjui.

10.2.2. Išlaidas padengiantieji sandoriai

Išlaidas padengiančiuosiuose sandoriuose tiekėjui padengiamos visos išlaidos, kurias jis

patiria pristatydamas produktą, įskaitant mokestį, kuris yra tiekėjo pelnas. Šio tipo sandoriai

pirkėjams yra rizikingiausi, nes jie nežino galutinės kainos. Nors pirkėjų tarpe išlaidas

padengiantieji sandoriai nėra pageidaujami, jie gali būti vienintelė galimybė produktui įsigyti, kai

nėra gero jo apibrėžimo, arba prašoma pateikti kažką, ko anksčiau nėra buvę.

10.2.3. Laiko ir medžiagų apmokėjimo sandoriai

Šio tipo sandoriai yra vidurys tarp fiksuotos kainos ir išlaidas padengiančiųjų sandorių.

Pirkėjas ir tiekėjas susitaria dėl įkainių, pvz., programuotojo darbo valandos kainos, tačiau visa

kaina yra nežinoma, kuri priklausys nuo produktui sukurti sugaišto laiko. Šio tipo sandoriai

naudojami įdarbinant papildomus žmones, kai specifiniams projekto darbams atlikti prireikia

specialistų.



81

Sudarant sandorius, reikiami atlikti darbai nurodomi užduotyje, kurie turi įtakos

pasirenkant sandorio tipą.

10.3. Darbo užduotis tiekėjams

Jei projekte numatoma kviestis į pagalbą tiekėjus, labai svarbu tiksliai perteikti jiems, ko

jūs norite. Darbo užduotyje (SOW – Statement Of Work) detaliai aprašomos prekės arba

paslaugos, kurias jūs norite pirkti. Daugeliu aspektų ji yra panaši į projekto apimties aprašą.

Darbo užduotyje yra projekto nuostatai, pagrindiniai tikslai, sėkmės kriterijai, kai kurios

prielaidos ir apribojimai. Joje taip pat nurodoma, kokias garantijas turi prisiimti tiekėjas ir kokios

bus atsiskaitymo sąlygos (darbų priėmimo-perdavimo aktas). Jūsų projekto apimties aprašo

dalis, susijusi su prašomais atlikti darbais, yra gera pradinė medžiaga darbo užduočiai parengti.

Netgi jei darbo užduotį yra rengęs kitas organizacijos departamentas, projekto vadovas

turi užtikrinti projekto reikalavimų tikslumą. Darbo užduotis turi būti aiški ir tiksli, nes tai gali

turėti įtakos tiekėjo siūlomos prekės ar paslaugos kainai. Bet kokie netikslumai gali būti

nepatenkinamų sandorio rezultatų priežastimi.

Daug kompanijų turi šablonus darbo užduotims rengti. Tai priemonė, padedanti perteikti

tiekėjams išsamią informaciją.

10.4. Prašymas tiekėjams teikti pasiūlymus

Kai jūs apsisprendžiate, kad kažkuriems projekto darbams atlikti į pagalbą kviesitės

tiekėjus, ir parengiate darbo užduotį (SOW), ką jie turės atlikti, reikia tai paskelbti tiekėjams.

Prašymo teikti pasiūlymus (RFP – Request For Proposal) esmė yra gauti tiekėjų pasiūlymus

užduotyje nurodytiems darbams atlikti.

Tipiškai pirkimo dokumentai rengiami tam, kad naudodami juos praneštume

potencialiems tiekėjams apie darbus. Šie dokumentai vadinami įvairiai:

- prašymas teikti pasiūlymus (RFP – Request For Proposal);

- prašymas siūlyti kainą (RFQ – Request For Quotation);

- kvietimas siūlyti kainą (IFB – Invitation For Bid).

Nesvarbu kaip pirkimo dokumentai bebūtų vadinami, juose turi būti darbo užduotis

(SOW), informacija, kaip pasiūlymai turėtų būti apipavidalinti ir pristatyti, bei data, iki kada

pasiūlymai turi būti pateikti. Potencialių tiekėjų gali būti prašoma padaryti formalius pranešimus

arba pateikti tik kainą. Priklausomai nuo to, kokioje ūkio srityje jūs dirbate, pirkimo dokumentų

detalumas gali būti įvairus.

Prieš siųsdami pirkimo dokumentus potencialiems tiekėjams, pasitikrinkite, ar jūsų

organizacijoje nėra patvirtinto tiekėjų sąrašo. Daug kompanijų turi nustatytas procedūras

patikrinti, ar tiekėjas atitinka tam tikrus reikalavimus ir ar gali būti kviečiamas jūsų darbams. Jei

jūsų kompanijoje yra tokios taisyklės, tai darbams galima kviesti tik tiekėjus iš patvirtinto sąrašo.

Jei tokio sąrašo nėra, projekto grupė arba pirkimų departamentas turi ieškoti potencialių tiekėjų

verslo asociacijose, internete arba kituose prieinamuose informacijos šaltiniuose.

Kai pirkimo dokumentai išplatinami (galima ir anksčiau), jūs turite parengti kriterijus

gaunamiems pasiūlymams įvertinti.



82

10.5. Tiekėjų atrankos kriterijai

Laikas, kurį projektų vadovai sugaišta atrinkdami geriausio tiekėjo atrankai, priklauso nuo

to, ar jūsų organizacijoje yra atskiras pirkimų departamentas. Jei toks departamentas yra, jo

darbuotojai patars jums, kokius dokumentus perkant prekes ar paslaugas reikia parengti, padės

atrinkti tiekėją ir prižiūrėti sandorio su juo vykdymą.

Jeigu jūs esate atsakingas už tiekėjo parinkimą, tuomet reikia parengti kriterijus, kuriais

remiantis vertinsite tiekėjų pasiūlymus. Tariantis su sponsoriumi ir akcininkais, iš anksto

numatomi žmonės, kurie bus įtraukti į tiekėjų pasiūlymų vertinimo komisiją. Būtent jie turi

parengti vertinimo kriterijus ir susitarti dėl kriterijų svorio.

Remiantis nustatytais kriterijais sudaroma tiekėjų pasiūlymų eilė. Kriterijai gali būti

objektyvūs ir subjektyvūs. Pvz., gali būti naudojami tokie kriterijai:

- visa pasiūlymo kaina;

- kokiu lygiu tiekėjas supranta užsakovo problemą;

- tiekėjo darbuotojų kvalifikacija vadybiniu ir techniniu požiūriais;

- tiekėjo patirtis dirbant su panašiais produktais;

- tiekėjo ir jūsų organizacijos kultūrinė (dalykinė) atitiktis;

- tiekėjo finansinė padėtis.



83

11. PROJEKTO BENDROJO PLANO RENGIMAS

Ankstesniuose skyriuose nagrinėjome įvairių projekto klausimų planavimą. Jų metu

sukaupiama daug įvairios informacijos. Ką su ja daryti ir kaip ją sekti? Todėl rengiamas bendrasis

(integruotasis) projekto planas, kuriame sujungiama visa projekto apimties, darbų grafiko,

kainos, žmoniškųjų išteklių, kokybės, rizikos, komunikacijų ir pirkimų planavimo metu parengta

informacija.

Tipiškas bendrasis projekto planas (toliau – projekto planas) turi tokias dalis: bendrąją,

planavimo, šablonų ir kontrolinių sąrašų, šaltinių nuorodų ir priedų. Truputį vėliau jos

aptariamos detaliau.

Projekto plano sudarymas nėra vien ankstesnių planavimo dokumentų surinkimas ir

sujungimas. Prasmingam projekto planui sudaryti projekto grupės nariai, sponsorius, akcininkai

turi sugaišti nemažai laiko ir įdėti nemažai pastangų. Visa tai pradedama nuo projekto plano

detalaus turinio (TOC – Table Of Contents) sudarymo.

Baigus rengti projekto planą, jis peržiūrimas, formaliai patvirtinamas. Tuo projekto

planavimo etapas baigiamas (apskritai, vienoks ar kitoks planavimas vyksta viso projekto

bėgyje) ir pereinama prie projekto esminių darbų vykdymo etapo.

11.1. Kas yra projekto planas?

Projekto planas yra dokumentas, kuriame yra sujungti visi planavimo duomenys. Projekto vadovas naudos jį kaip vadovą darbų eigai stebėti, perėjus į projekto vykdymo etapą. Apskritai, projekto planas projekto bėgyje laikas nuo laiko yra peržiūrimas ir koreguojamas. Kai kam gali atrodyti, kad sujungti visus planavimo duomenis į vieną dokumentą nėra svarbu. Tačiau, neturint jo, nuolatos tektų vartyti projekto nuostatus, projekto apimties aprašą, darbų sąrašą ir kitus planavimo dokumentus. O tai nėra patogu. Planavimo procese sukuriama daug svarbių duomenų. Jei jų kruopščiai nesutvarkysime ir nepateiksime reikiamiems asmenims, bus mažai naudos iš jų. Kokybiškas projekto planas labai padeda valdyti projektą, vykdant ir kontroliuojant jo darbus.

Projekto planas yra visų darbų eigos stebėjimo ir reikiamų korekcijų darymo pagrindas. Tai gera priemonė pagrindinei projekto informacijai perduoti akcininkams. Projekto planas yra tas šaltinis, kuris jo skaitytojams padeda išsiaiškinti, kokia yra projekto apimtis, kas yra pagrindiniai akcininkai, kokie turėtų būti pagrindiniai rezultatai, ir daugelį kitų klausimų. Toliau išnagrinėkime projekto plano tipinę sudėtį.

11.2. Projekto plano sudėtis

Daug organizacijų naudoja standartinį šabloną projektų planams. Nors jų formatas ir sudėtis gali varijuoti, tačiau projektų planuose dažniausiai yra tokios dalys:

- bendroji, kur pateikiama informacija apie organizaciją ir patį projektą;

- suplanuotų dalykų, kur talpinami visi planavimo rezultatai; - šablonų ir kontrolinių sąrašų, kurie bus naudojami projekto valdyme; - šaltinių nuorodos; - priedai.



84

11.2.1. Bendroji dalis

Projekto planas gali būti labai ilgas dokumentas. Kad būtų lengviau jį naudoti ir matytume

korekcijų darymo laiką, šioje dalyje paprastai būna tokie skyriai:

- informacija apie dokumentą. Šiame skyriuje nurodoma informacija apie dokumento

naujinimus ir priežiūrą. Dokumento istorijoje nurodomi versijų numeriai ir peržiūrų datos, taip

pat yra kontaktinė informacija, kur galima gauti dokumento kopijas;

- turinys. Jame, kaip ir kiekvienos knygos turinyje, atspindima dokumento organizacinė

struktūra – dalys, skyriai, poskyriai ir nuo kurio puslapio jie yra dokumente, kad skaitytojai

greičiau susirastų reikiamą dalį.

11.2.2. Suplanuoti dalykai

Tai pagrindinė projekto plano dalis. Jos svarbiausi skyriai:

- santrauka (executive summary). Ji paprastai pradedama trumpu projekto nuostatų

pristatymu (verslo poreikiai, kodėl buvo pradėtas projektas, projekto tikslai). Santraukos tikslas

– greitai ir glaustai pristatyti projekto esmę;

- reikalavimai. Šiame skyriuje išdėstomi projekto funkciniai, techniniai ir verslo

reikalavimai, kurie buvo suformuluoti projekto inicijavimo etape;

- apimtis. Čia pateikiamos projekto ribos, atitinkančios klientų sutartus siekiamus

rezultatus;

- akcininkai. Tai sąrašas asmenų, atsakingų už projekto rezultatus. Jame nurodomas

sponsorius, klientai, projekto vadovas, projekto grupės nariai, kiti, kurių paslaugų reikia

projektui sėkmingai užbaigti;

- reikiami ištekliai. Čia vardinami ne žmoniškieji ištekliai, o serveriai, programinė įranga,

kita, ko reikės vykdant projektą. Šiame skyriuje gali būti vardinami ir tiekėjai;

- prielaidos ir apribojimai. Išdėstomos planavimo etape darytos prielaidos ir žinomi

suvaržymai, galintys turėti įtakos projekto baigčiai. Pvz., gali būti tokia prielaida: tiekėjas

pristatys savo prekę iki nustatyto laiko;

- pagrindiniai rezultatai. Išvardinami ne tik laukiami galutiniai projekto rezultatai, bet ir

pagrindiniai etapų rezultatai. Ši informacija gali būti imama iš WBS aukščiausio lygio darbų

aprašų.

Gali būti reikalaujama, kad, pvz., intranete ar kitokioje el. aplinkoje būtų teikiama

informacija apie einamąją darbų grafiko versiją. Projekto darbų grafiko kontroliniai taškai gali

būti aprašyti projekto plano prieduose;

- biudžetas. Šis skyrius gali būti labai trumpas, nurodant tik visą projekto kainą arba ją

išskaidytą į išlaidų kategorijas. Visa kita – projekto plano prieduose;

- rizika. Išdėstomi rizikos veiksniai, galintys turėti įtakos projekto sėkmei, ir planai, kaip

galima būtų sušvelninti jų pasekmes arba išvengti jų;

- valdymo klausimai. Aprašoma tvarka, kaip turi būti keliami su projektu susiję klausimai,

nurodomi atsakingi asmenys už problemų sprendimą, apibrėžiamos keitimų darymo procedūros,

projekto stebėjimo ir informavimo apie jo eigą klausimai. Apibūdinama bendroji projekto



85

vykdymo aplinka, įskaitant kompiuterinius išteklius, politinius, geografinius, sąsajų su kitomis

sistemomis, kt. klausimus;

- komunikacijos. Projekto plano komunikacijų skyriuje nurodomas komunikacijų su

sponsoriumi, klientais, projekto grupe ir kitais akcininkais būdas ir dažnumas. Pvz., gali būti

rašoma taip: susitikimai su sponsoriumi kiekvieną pirmadienį 10 val.; visos projekto grupės

susirinkimai – kas antrą savaitę trečiadienį 14 val; individualūs susitikimai su grupės nariais arba

el. laiškai pagal poreikį viso projekto metu;

- vykdymo planas. Tai projekto darbų grafiko įgyvendinimo bendroji metodologija. Tai

jūsų planas, susijęs su kūrimo darbais, aparatine įranga, kuriamo produkto diegimu, saugumo

užtikrinimu, derinimu, testavimu, kad viskas vyktų sklandžiai pagal darbų grafiką;

- priežiūros planas. Priežiūros plane nurodoma, kaip sukurta sistema turės būti prižiūrima

užbaigus projektą. Priežiūra gali apsiriboti naujos sistemos naujinimais ar dalies aparatinės

įrangos priežiūra arba gali būti steigiama grupė, kuri teiks pagalbą naujos sistemos naudotojams;

- mokymų planas. Jame dėstoma, kaip bus mokomi sukurtos sistemos galiniai naudotojai,

administratoriai, pagalbos teikimo tarnyba ir kitos grupės.

11.2.3. Šablonai ir kontroliniai sąrašai

Jeigu jūs naudojate kokius nors kontrolinius sąrašus arba juos sukūrėte planavimo eigoje,

jų kopijas galite dėti į šį projekto plano skyrių. Kontrolinių sąrašų pavyzdžiai:

- diegimo (instaliavimo) kontrolinis sąrašas;

- testavimo kontrolinis sąrašas;

- kiti kokybės kontroliniai sąrašai.

11.2.4. Šaltinių nuorodos

Šaltinių sąraše nurodomos naudotos metodologijos, standartai, sektini pavyzdžiai (best

practices). Jame gali būti:

- projektų valdymo žinynas [PMBOK];

- jūsų organizacijos kokybės standartai;

- jūsų organizacijos sistemų kūrimo metodologija;

- jūsų organizacijos projektų valdymo metodologija;

- ISO 9000 standartai;

- kiti reikalingi reglamentai ar standartai.

11.2.5. Priedai

Prieduose talpinamos dokumentų kopijos, kurie paprastai nededami į projekto plano

tekstą (dedama tik nuoroda). Tai:

- projekto darbų grafiko kontroliniai taškai;

- projekto biudžeto kontroliniai taškai.

Projekto plano rašymas gali atrodyti sunkus pradedančiajam projektų vadovui. Tačiau

nereikėtų išsigąsti, nes yra nemažai patarimų, kaip reikėtų rašyti projekto planą, kad jame būtų

nurodyti ateityje reikalingi duomenys.



86

11.3. Plano sudarymas

Projekto plano rašymo žingsniai:

- plano rašymo organizavimas ir rašymas;

- plano keitimo procedūrų apibrėžimas;

- plano peržiūra;

- projekto planavimo etapo užbaigimas.

11.3.1. Plano rašymo organizavimas ir rašymas

Prieš pradedant rašyti projekto planą reikėtų visų pirma peržiūrėti turimus dokumentus

ir numatyti jų pateikimo tvarką. Priešingu atveju gali atsitikti taip, kad rašydami planą jūs tuos

pačius duomenis įtrauksite daug kartų arba praleisite svarbius dalykus.

Taip pat būtina apibrėžti dokumentų tvarkymo procedūras, jei jūsų organizacijoje nėra

standartinių. Kaip turi būti daromi dokumento pakeitimai, kokia naujų versijų numeravimo

sistema, kaip turi būti nurodomos versijų datos ir numeriai – tai klausimai, kurie turi būti

išspręsti iki projekto plano išplatinimo. Neturėdami dokumentų tvarkymo taisyklių, jūs

negalėsite tinkamai apskaityti daromų projekto plano pakeitimų.

Šiandieninės bendro naudojimo failų (file-sharing) technologijos įgalina projektų vadovus

platinti projekto duomenis elektroniniu būdu. Taip išvengiama daug rankinio darbo, spausdinant

dokumentus, platinant jų originalą, o vėliau platinant pakeistus dokumento puslapius.

Pradedant rašyti dokumentą reikia apsispręsti, kaip jis bus platinamas: atspausdintas

popieriuje ar elektroniniu būdu. Prieiga prie projekto plano bendro naudojimo faile turi savų

ypatumų. Tenka nustatyti dokumentų saugumo lygius ir sudaryti akcininkams prieigos prie

serverio, kuriame saugomas projekto planas, galimybes (naudojant slaptažodžius, kt.).

Dokumentai serveryje turi būti apsaugoti nuo nesankcionuoto pakeitimo.

Išsprendus aukščiau minėtus organizacinio pobūdžio klausimus, pradedama rašyti

projekto planą. Kadangi planą skaitys daug žmonių iš įvairių jūsų organizacijos padalinių,

ištaisykite gramatines klaidas, įsitikinkite, ar visi plano skyriai užbaigti, ar visi duomenys teisingi.

Tinkamai neperžiūrėtas ir nesuredaguotas planas kelia įtarimą, kad projektas nėra kruopščiai

apgalvotas ir suplanuotas.

11.3.2. Plano keitimas

Projekto grupės parengtą, akcininkų peržiūrėtą ir sponsoriaus patvirtintą projekto plano

pradinį variantą projekto vykdymo etape tenka ne kartą koreguoti.

Projekto plano keitimas yra iteracinis procesas. Tai reiškia, kad projekto eigoje pakeitus

pagrindinius plano komponentus, būtina pakoreguoti įvairius plano skyrius. Pvz., gali būti

keičiama projekto apimtis, gali būti įtraukti nauji akcininkai, gali būti praplėstas pagrindinių

rezultatų sąrašas. Planas, kuris tvarkomas atsitiktinai, greitai pasidaro netikslus ir netenka

projekto vykdymo kelrodžio vertės.

Šiems sunkumams įveikti būtinas projekto plano keitimų darymą reglamentuojantis

dokumentas. Turėtų būti paskirtas asmuo, kuris būtų įgaliotas daryti projekto plano pakeitimus

ir platinti tokią informaciją.



87

Bet kokie projekto plano pakeitimai turi būti daromi griežtai laikantis nustatytos tvarkos.

Pvz., projekto apimties pakeitimai turi būti daromi tik gavus oficialų patvirtinimą, išduotą

laikantis projekto apimties valdymo plane nustatytų taisyklių. Biudžeto ar darbų grafiko

pakeitimams daryti taip pat būtinas oficialus leidimas.

11.3.3. Plano peržiūra

Į projektą įtraukti žmonės turi turėti galimybę dalyvauti plano rengime. Projekto planas

rengiamas keliais žingsniais, palaipsniui plėtojant jį. Nuolatinė jo peržiūra, dalyvaujant

sponsoriui ir akcininkams, yra sėkmės prielaida.

Sponsoriaus peržiūra. Sponsorius įtraukiamas į projekto plano peržiūrą, kai tik

parengiami plano metmenys arba turinys. Taip suteikiama jam galimybė išdėstyti savo pastabas

dėl plano. Jei planas rengiamas pagal patvirtintą šabloną, projekto vadovo pareiga įsitikinti, ar

sponsoriui yra žinomas to šablono turinys.

Sponsorius turi peržiūrėti projekto planą periodiškai, kai tik įvairios plano sekcijos

papildomos naujais duomenimis. Jis turi savo parašu patvirtinti projekto planą, taip suteikdamas

jam oficialaus dokumento statusą. Kaip einama link galutinių rezultatų, sponsorius turi matyti

įvairiuose projekto etapuose.

Akcininkų peržiūra. Projekto plano rengimas suteikia projekto vadovui gerą galimybę

suvienyti akcininkų interesus ir įsipareigojimus. Projekto plano metmenys ar turinys turi būti

pateikiami jiems. Plano duomenys jiems turi būti žinomi, nes kiekvieno lūkesčiai gali skirtis.

Atviras klausimų ar interesų aptarimas padeda parengti geresnį projekto planą.

Sudėtingų projektų išankstinė plano peržiūra turi būti įprastas dalykas. Paprastesniais

atvejais gali pakakti susitikimų tik su atskirais akcininkais, jei jiems iškyla klausimai.

Galutinė projekto plano peržiūra yra formali procedūra, kuria užbaigiamas projekto

planavimo etapas.

11.3.4. Projekto planavimo etapo užbaigimas

Kai projekto planas baigiamas, jis išplatinamas akcininkams. Po to pereinama prie

projekto vykdymo ir kontrolės etapų.

Projekto eigoje nuolat tenka stebėti, ar projektas juda į priekį. Susirinkimas planavimo

etapo pabaigoje yra gera galimybė gauti akcininkų pritarimą projekto tikslams. Jeigu pasikeičia

verslo poreikiai, dėl kurių pradžioje buvo imtasi projekto, dabar yra pats tas laikas, kai turi būti

apsispręsta dėl projekto tęsimo.

Ši peržiūra padeda išsiaiškinti planavimo metu neišspręstus klausimus. Tikimasi, kad visi

anksčiau iškilę klausimai yra išspręsti planavimo etape. Bet nemanykime, kad tokiu klausimų

neliko. Visada klauskite akcininkų, ar jų manymu planavimo etape neliko neišspręstų klausimų.

Yra lengviau išspręsti ginčus, kol projektas dar nepradėtas.

Kitas svarbus plano peržiūros uždavinys yra išsiaiškinti, ar akcininkų lūkesčiai atitinka

detalų projekto planą. Jei kai kurie plano elementai jiems pasirodo netikėti, išsiaiškinkite, ko

akcininkai iš tikro tikėjosi. Projekto vadovo pareiga yra išsiaiškinti, ar visos į projektą įtrauktos

šalys supranta ir remia siekiamus galutinius rezultatus ir pritaria tų rezultatų siekimo būdui.



88

Peržiūros metu atlikus pataisymus, projekto planą formaliai patvirtina sponsorius, o kai

kuriais atvejais - klientai. Patvirtintas dokumentas išplatinamas akcininkams.

Baigiamajame projekto planavimo susirinkime taip pat gali būti aptariami rodikliai, kurie

bus naudojami valdant ir kontroliuojant projektą jo vykdymo etape. Projekto vykdymo rodikliai

yra išmatuojami dydžiai, kuriuos projekto vadovas naudos vertindamas projekto eigą, pvz., ar

nėra nukrypimų nuo darbų grafiko ar biudžeto kontrolinių taškų.

Pereidami iš planavimo etapo į vykdymo etapą, visi projekto dalyviai turi aiškiai žinoti

savo individualų vaidmenį ir stengtis sėkmingai įvykdyti projektą.

7.1 lentelėje pateikiamas projekto plano turinio pavyzdys.

7.1 lentelė. Projekto plano turinio pavyzdys

TURINYS 1. Santrauka

2. Reikalavimai (funkciniai, techniniai, verslo)

3. Apimtis

4. Akcininkai

5. Reikiami ištekliai

6. Prielaidos ir apribojimai

7. Pagrindiniai rezultatai

8. Biudžetas

9. Rizika

10. Valdymo klausimai (pareigos, stebėjimas, aplinka)

11. Komunikacijos

12. Vykdymo planas

13. Priežiūros planas

14. Mokymų planas

Šablonai ir kontroliniai sąrašai

Šaltinių nuorodos

Priedai



89

12. PROJEKTO VYKDYMAS

Projekto vykdymo etapas yra tas laiko tarpsnis, kuomet atliekami realūs projekto darbai.

Projekto vykdymo sėkmė priklauso nuo:

- sudarytos projekto grupės;

- kaip laikomasi projekto plano;

- kaip platinama projekto informacija;

- kaip valdomi sandoriai su tiekėjais.

Projekto vadovui tenka palaikyti ryšį su daugeliu asmenų ir projekto grupe viso projekto

metu. Kalbantis su sponsoriumi, grupės nariais, tiekėjais, klientais, išorinėmis finansinėmis ir

teisinėmis organizacijomis, tenka pasitelkti visus savo, kaip vadovo, sugebėjimus.

Projekto vykdymo sėkmė didžiąja dalimi priklauso nuo sudarytos projekto grupės.

Mokėjimas sudaryti laikinas grupes, organizuoti reikiamus mokymus, diegti tinkamą darbuotojų

skatinimo ir pripažinimo sistemą yra pagrindiniai darnios grupės sudarymo veiksniai.

Projekto sėkmingas vykdymas neįmanomas ir be gerų santykių su akcininkais. Tenka

palaikyti nuolatinį ryšį su sponsoriumi. Kad žinotume, ar projektas vykdomas pagal planą, būtina

rinkti tam tikrus duomenis, lyginti juos su tais, kurie buvo numatyti plano kontroliniuose

taškuose, rengti ataskaitas apie projekto eigą.

Sandorių su tiekėjais valdymas irgi turi įtakos sėkmingam projekto vykdymui. Projekto

vadovas turi sekti tiekėjų darbus, spręsti projekto grupės ir tiekėjų ginčus, reaguoti į tiekimų

vėlavimus, tvarkyti atsiskaitymo su jais dokumentus.

Panagrinėkime projekto sėkmingo vykdymo svarbesnius veiksnius detaliau.

12.1. Projekto grupės sudarymas

Projekto grupės valdymas skiriasi nuo funkcinės darbo grupės valdymo. Kadangi projektų

grupės būna laikinos, surinkti tinkamus žmones būna sunku. Grupėje dirbti sutinkantys žmonės

dažniausiai yra kažkurios IT srities specialistai, bet neturi platesnių žinių apie

kompiuterizuojamą verslo sritį. Projekto vadovo uždavinys yra sudarytą projekto grupę parengti

taip, kad ji galėtų dirbti efektingai ir įvykdytų projektą reikiamu kokybės lygiu, laiku ir

neviršydama biudžeto. Tai nėra lengva, ypač kai viena dalis žmonių įdarbinama puse etato, kita –

visu etatu, kai vieni yra techninio, kiti ne techninio profilio specialistai, o kai kuriais atvejais jie

būna išsidėstę geografiškai plačioje teritorijoje.

Projekto vadovo uždavinys yra, panaudojus tinkamą skatinimo ir pripažinimo sistemą,

pravedus reikiamus mokymus, sudaryti darnią projekto grupę ir valdyti ją.

12.1.1. Darnios projekto grupės sudarymas ir valdymas

Prieš pradedant nagrinėti laikinų grupių valdymo būdus, naudinga prisiminti grupės

plėtros etapus:

- grupės sudarymas. Šio etapo metu žmonės susipažįsta su projekto tikslais, projekto

vadovu ir vieni su kitais;

- kova dėl pareigų. Tai narių kovos už aukštesnes pareigas, įtaką projekto grupės

organizacinėje struktūroje laikotarpis;



90

- santykių nusistovėjimas. Tai etapas, kai projektas įeina į normalias vėžes ir grupės

nariai pradeda naudingai bendradarbiauti;

- našus darbas. Tai paskutinis plėtros etapas, kai darbo grupės nariai suvokia

tarpusavio santykius, pasiekia darną ir aukštą darbo produktyvumą.

Šiems etapams įveikti grupei reikia laiko ir gero vadovavimo. Viso to pradžia galėtų būti

projekto grupės pirmasis susirinkimas (project kickoff).

Projekto grupės pirmasis susirinkimas. Jei žmogus pagalvoja apie savo įgytą patirtį, dėl

kurios buvo priimtas į projekto grupę, tai visos jo mintys ko gero atsako į šiuos klausimus:

- kodėl aš esu projekto grupėje?

- kas aš ir ko iš manęs tikimasi?

- ką aš rengiuosi daryti?

- kaip darysiu savo darbą?

Projektų vadovas turėtų priminti grupės nariams būti pasirengusiems atsakyti į minėtus

klausimus. Geras pirmasis susirinkimas yra toks, kuriame atsakoma į šiuos klausimus ir

sukuriamas pagrindas grupės nariams.

Pirmasis susirinkimas yra gera proga susipažinti grupės nariams ir akcininkams, visiems

jiems išgirstant tą patį ir tuo pačiu metu. Projekto vadovas dažniausiai nepažįsta visų grupės

narių ir neturi galimybės apklausti jų, kokias pareigas jie galėtų užimti. Jis turi supažindinti grupę

su projekto tikslais ir sukurti tokią atmosferą, kad visi grupės nariai jaustųsi jaukiai. Tai būtų

gera pirmo grupės plėtros etapo – grupės sudarymo - pradžia.

Projektų grupių pirmieji susirinkimai gali būti organizuojami labai įvairiai. Štai keletas

tokių susirinkimų darbotvarkės punktų:

- pasveikinimas;

- supažindinimas (pristatomi asmenys, nurodoma jų funkcinės veiklos sritis,

išsilavinimas, pareigos projekte);

- kviestų pranešėjų - sponsoriaus, kurio nors iš akcininkų, klientų - kalbos;

- projekto apžvalga;

- projekto vadovo lūkesčiai;

- klausimai ir atsakymai;

- pasisakymai.

Grupės darbo (performance) valdymas. Projekto vadovas turi teisę įpareigoti grupės

narius daryti darbus ir reikalauti iš jų atsakomybės už rezultatus. Kad grupės nariai pasitikėtų

juo, vadovas turi būti kompetentingas, gerbiamas, sąžiningas ir atviras. Projekto vadovas visada

turi būti pasirengęs geranoriškai padėti grupės nariams, sprendžiant darbo problemas.

Valdymui svarbus yra grupės narių grįžtamasis ryšys. Vadovui nereikėtų nurodinėti

kiekvieno smulkaus darbelio ir reikalauti ataskaitų už juos. Tačiau žmonės vienus darbus moka

geriau, kitus – blogiau. Todėl, aptariant jiems pavestus darbus, reikėtų koncentruotis ties tokiais

klausimais: kokių darbo rezultatų laukiama, kokie galimi darbo nesklandumai, koks atpildas už

labai gerai atliktą darbą, kokios nuobaudos už nusižengimus, kokios specifinės vadovo

sprendimo pasekmės.



91

Darbų grįžtamasis ryšys turi būti savalaikis. Maža naudos, pvz., iš klaidos taisymo, jei ji

buvo padaryta prieš keletą savaičių ir spėjo persiduoti į kitus projekto komponentus. Dar blogiau,

jei žmogus ją pamiršta.

Iškilusiems konfliktams spręsti galimi įvairūs būdai: prisiderinimas, vengimas, ginimasis,

kompromisas, bendradarbiavimas. Dvi konfliktinės situacijos, kurios reikalauja išskirtinio

dėmesio, yra grupės narių ginčai (jiems išspręsti turi įsikišti trečias asmuo - projekto vadovas) ir

irzlių grupės narių, nuodijančių kolektyvo atmosferą, valdymas.

Darniai projekto grupei sukurti, jos darbo našumui didinti padeda mokymai.

12.1.2. Mokymai

Priklausomai nuo projekto pobūdžio, sudarytos projekto grupės mokymai gali būti

pravedami tik kai kuriems arba visiems grupės nariams. Kai kuriose organizacijose kaip šalutinis

tikslas gali būti projekto grupės narių įgūdžių padidinimas arba informacijos apie naujus

produktus ar procesus surinkimas.

Jei jūs kuriate produktą naudodami naują ir besiplėtojančią technologiją, projekte gali būti

numatyti grupės mokymai.

Vienas iš labiausiai paplitusių mokymų projektų grupėms yra projektų valdymo kursai.

Medžiagą jiems gali būti parengęs ir projekto vadovas, o patys kursai gali būti vedami už

organizacijos ribų. Mokymus gali rengti ir specializuotos projektų valdymo organizacijos,

naudodamos standartines metodologijas, įrankius ir šablonus.

Grupės profesinio lygio kėlimas, darbų grįžtamojo ryšio gerinimas yra labai svarbu, bet

neturėtų būti pamiršti ir darbuotojų skatinimo ir pripažinimo klausimai.

12.1.3. Skatinimas ir pripažinimas

Kai kurie projektų vadovai (greičiau ne jie, o projektų sponsoriai) gali sakyti, kad grupės

nariai tik dirba savo darbą ir papildomai už tai jiems nemokama. Tačiau daugelyje organizacijų

puikus darbas pažymimas, mokamos premijos.

Projekto grupės darbas yra sunkus ir kartais pareikalauja išradingumo, kad būtų pasiektas

projekto tikslas. Jei jūsų organizacija yra funkcinio tipo, tai projekto darbai gali ir nesusilaukti

reikiamo funkcinių padalinių vadovų dėmesio. Todėl projekto vadovas turėtų pasirūpinti, kad

projekto grupei būtų taikomos skatinimo priemonės.

Skatinimo sistema yra susijusi su projekto biudžete numatytais pinigais, kuriuos projekto

vadovas gali panaudoti pasižymėjusiems darbuotojams premijuoti arba projekto užbaigimo

pokyliui organizuoti. Priklausomai nuo organizacijos taisyklių, skatinimas gali apsiriboti garbės

raštais ar dovanomis.

Jeigu projekto biudžete arba organizacijos vadovybės specialiajame fonde yra numatytos

lėšos darbuotojų skatinimui, jūs turite būti apibrėžę nuopelnus, už kuriuos žmonės bus

skatinami. Kai žmogus skatinamas, turi būti aiškiai įvardinti darbai, už kuriuos jis nusipelnė

pagarbos.

Gali būti ir visos grupės skatinimai. Tai iškilmingi pietūs ar šventiniai renginiai.

Ne visi projektų vadovai turi lėšų darbuotojams skatinti. Tokiais atvejais reikėtų bent

padėkoti jiems už puikų darbą.



92

Kokia darbuotojų skatinimo ar pripažinimo forma bebūtų, projekto vadovas turi vienodai

taikyti ją visiems grupės nariams. Nevienodas skatinimas dažnai vertinamas kaip favoritizmas.

12.2. Santykiai su kitais akcininkais

Be projekto grupės sudarymo ir darbo su ja projekto vykdymo metu projekto vadovui

dažnai tenka turėti reikalus su sponsoriumi, kitais akcininkais (prisiminkime, kad pagal

akcininko sąvokos apibrėžimą, projekto vadovas ir grupės nariai taip pat yra akcininkai),

klientais. Panagrinėkime šiuos santykius šiek tiek plačiau.

Santykiai su klientais. Daugelyje organizacijų IT grupės santykiai su kitais organizacijos

darbuotojais ar klientais būna savotiškai priešiški. Tai nėra gerai nei projekto grupės nariams, nei

pačiam projektui. Todėl IT projekto vadovui reikėtų išsiaiškinti tuos barjerus, kurie gali trukdyti

efektyviems darbo santykiams su klientais palaikyti.

Klientai gali nežinoti sudėtingų programų sistemų kūrimo plonybių, o projekto vadovas

gali ne viską žinoti apie kompiuterizuojamą verslo sritį.

Klientų techninio išprusimo lygis gali būti labai įvairus. Santykiai su jais bus geresni, jei

išsiaiškinsite, kokias technologijas jie naudoja savo darbe.

Štai keletas gerų santykių su klientais palaikymo principų:

- dažnas bendravimas. Reikėtų klientams teikti ne vien ataskaitas, bet ir laikas nuo laiko

paklausinėti, ar visi projekto aspektai jiems yra aiškūs;

- projekto grupės darbų pristatymas. Reikėtų stengtis (pvz., kviečiant į savo

susirinkimus), kad klientai suprastų, jog jų aktyvus domėjimasis projektu ir

reiškiamos pastabos jums yra svarbu;

- sutarimo siekimas. Jei su klientais buvo bendradarbiaujama projekto inicijavimo etape

derinant reikalavimus, tai juos reikėtų įtraukti ir į projekto problemų sprendimą ir

valdymą. Projekto grupė daugiau būna susikoncentravusi ties techniškais klausimais.

Tai gali iškreipti projekto tikslą, todėl klientų pastabos gali padėti išvengti nukrypimų;

- savalaikis nutarimų vykdymas. Jei iš kliento reikia papildomos informacijos ar

nutarimo patvirtinimo, išaiškinkite jam problemą ir nurodykite, kada nutarimas bus

įvykdytas;

- lūkesčių valdymas. Projekto vykdymo bėgyje klientas gali pamiršti projekto

reikalavimų, prielaidų, ribojimų ir kitą planavimo etape parengtą informaciją.

Nuolatinis projekto vykdymo eigoje gaunamų rezultatų ir suplanuotų dalykų

palyginimas padeda viską prisiminti ir stiprina klientų lūkesčius dėl projekto

rezultatų;

- faktų valdymas. Ginčai tarp projekto vykdytojo ir klientų gali kilti grynai dėl paskalų

ar spėlionių. Jei išgirstate, kad kliento atstovas yra nepatenkintas projekto rezultatais,

išsiaiškinkite faktus ir nepasitenkinimo priežastis. Jeigu rezultatai neatitinka projekto

dokumentuose užfiksuotų reikalavimų, priimkite kliento pastabas ir stenkitės

išspręsti problemą. Jei kliento pastabos išeina už numatytų projekto apimties ir

reikalavimų ribų, atmeskite kliento pastabas ir, jeigu reikia, supažindinkite jį su

projekto apimties keitimo procedūra.



93

Santykiai su sponsoriumi iškilus abejonėms. Visokie nesklandumai gadina projekto

vadovo gyvenimą. Jeigu nesate subūręs darnios projekto grupės ir santykiai su klientais nėra geri,

gali ateiti laikas, kai neteksite ir sponsoriaus paramos. Susvyravusi parama gali pasireikšti

įvairiais būdais. Galbūt bus nukeltas jūsų projekto peržiūros susirinkimas arba sponsorius staiga

nebeturės laiko projekto klausimams aptarti. Sponsorius gali ir permesti savo su projektu

susijusias pareigas projekto vadovui sakydamas, kad projekto problemų sprendimas yra jūsų, o

ne jo reikalas.

Sponsorius gali pradėti šalintis projekto dėl įvairių priežasčių:

- organizacijos vadovybės pasikeitimas gali iššaukti strategijos pokyčius;

- atsiradę gandai gali būti impulsu šalintis projekto;

- padidėjęs darbo krūvis;

- asmeninio gyvenimo problemos.

Nežiūrint priežasčių, dėl kurių pasikeitė sponsoriaus požiūris į projektą, projekto vadovas

turi išsiaiškinti jas ir siekti sprendimo. Reikėtų išsiaiškinti abejones sponsoriui sukėlusias

priežastis, rūpestingai išdėstyti jam savo nuomonę, pasitelkti sąjungininkus ar įtakingus asmenis.

Jei sprendimo nepavyksta pasiekti, projekto vadovas turėtų nuspręsti, ar ieškoti naujo

sponsoriaus, ar rekomenduoti nutraukti projektą. Jei rekomenduojama nutraukti, tai tą reikėtų

daryti iš karto, o ne „marinti“ projektą iš lėto.

Ryšys su funkcinių padalinių vadovais. Projekto vadovui gali atrodyti, kad jo santykiai su

organizacijos funkcinių padalinių vadovais apsiriboja tik projektui reikalingų išteklių gavimu iš

jų. Retai kada atsitinka taip, kad planavimo metu numatyti projektui reikalingi ištekliai staiga

taptų neprieinami. Tačiau jūsų projekto darbams įtakos gali turėti funkcinių padalinių vadovų

pažadų suteikti projektui išteklius (darbuotojus, įrangą) netesėjimas arba išteklių atsiėmimas

nespėjus projekte atlikti numatytų darbų.

Tokiais atvejais būtina šnekėtis su funkcinių padalinių vadovais ir ieškoti visoms šalims

priimtinų sprendimų. Jūs turite žinoti, kodėl ištekliai nebeskiriami ar atitraukiami iš jūsų

projekto ir kaip funkcinių padalinių vadovai siūlo spręsti dėl to projektui iškylančias problemas.

Jei atitrauktų išteklių pakeitimas kitais neturi įtakos galutiniams projekto rezultatams, tai reikėtų

sutikti su tuo, pvz., naujo žmogaus priėmimu į projekto grupę.

Gali pasitaikyti, kad siūlymas keisti darbuotoją pateikiamas kritiniu jūsų projekto

vykdymo laikotarpiu. Jeigu organizacijos funkcinio padalinio vadovas atsiima savo žmogų iš jūsų

projekto grupės, kuomet darbai yra įpusėję ir tuose darbuose jo vaidmuo yra svarbus, projektui

tai gali turėti nemažą neigiamą poveikį. Todėl jūs, kaip projekto vadovas, siekdamas išvengti

problemų, turėtumėte paaiškinti jam vedančiųjų programuotojų keitimo žalingumą tokiose

situacijose.

Jei funkcinio padalinio vadovas nesileidžia į kalbas ir dėl naujo darbuotojo paieškos teks

nukelti projekto įvykdymo terminą, apie susidariusią situaciją jūs turite informuoti sponsorių ir

laukti jo sprendimo. Būkite pasirengę drauge su sponsoriumi pasverti galimas problemų

pasekmes ir išdėstykite vykusių pokalbių su funkcinio padalinio vadovu rezultatus. Sponsorius

gali teikti projektui aukštesnį prioritetą, nei funkcinio padalinio tuo metu atliekamas darbas, ir

pratęsti funkcinio padalinio vadovo pažadėtų išteklių naudojimo laiką projekte.



94

Projekto vykdymo etapo metu atliekami pagrindiniai darbai. Todėl šalia grupės sudarymo,

santykių su akcininkais palaikymo projekto vadovui taip pat tenka sekti ir viso projekto eigą.

12.3. Darbų vykdymas pagal planą

Projekto eigoje vadovas turi užtikrinti, kad viskas vyktų pagal darbų grafiką, būtų

laikomasi biudžeto apribojimų ir kuriamo produkto kokybė atitiktų projekto apimties apraše

numatytus reikalavimus. Tą tenka daryti kiekvieną savaitę. Geram darbų koordinavimui projekto

vadovas turi rinkti duomenis apie atliktus darbus ir lyginti juos su projekto plane numatytų

kontrolinių taškų duomenimis.

12.3.1. Duomenų apie projekto eigą rinkimas

Tinkamam projekto valdymui reikia daug informacijos. Priemonės, kuriomis renkama ši

informacija, yra atliktų darbų ataskaitos, iškilusių problemų sąrašai (issues log), finansinės

ataskaitos.

Darbų ataskaitos. Dauguma jų yra susijusios su darbų grafiku. Turi būti nustatytas

ataskaitos formatas (žiūr. 12.1 lentelę) ir kaip dažnai jos turi būti teikiamos (paprastai – kas

savaitę).

12.1 lentelė. Darbų ataskaitos šablono pavyzdys

Užduotis Dirbta valandų Liko dirbti valandų Atliktų darbų

procentas Pastabos

Jei kai kurie grupės nariai vangiai teikia tokias ataskaitas, reikėtų kviesti susirinkimus ir jų

metu aptarti ataskaitų reikalingumą ir darbų eigos klausimus.

Iškilusių problemų sąrašai. Kiekvieno projekto eigoje atsiranda spręstinų klausimų. Jiems

registruoti ir sekti gali būti naudojamos atitinkamos lentelės, kuriose nurodoma iškilusi

problema, jos įtaka projektui, kas atsakingas už problemos sprendimą, esamas problemos stovis

(žiūr. 12.2 lentelę).

12.2 lentelė. Iškilusių problemų sąrašo šablonas

Problema Įtaka

projektui Atsakingas

asmuo Problemos

stovis Atsiradimo

laikas Išsprendimo

laikas

Problemų sąrašai paprastai peržiūrimi projekto grupės susirinkimuose.

Finansinės ataskaitos. Išleistų pinigų kiekis yra svarbi informacija projekto vadovui.

Dažnai ją tvarko organizacijos finansų padalinys, ir projektų vadovui tai nekelia didelių rūpesčių.

Tačiau nesant tokio padalinio, projekto vadovas pats turi rengti finansines ataskaitas.

Daugelio projektų vadovai peržiūri ir tvirtina savaitines projekto grupės narių ataskaitas

ir projektui panaudotos įrangos ar medžiagų sąrašus.



95

12.3.2. Projekto eiga pagal kontrolinius taškus

Darbų grafiko ir biudžeto plano kontroliniai taškai yra tas kelrodis, kurie padeda vykdyti

projektą taip, kaip buvo suplanuota. Minėtų dviejų dokumentų ir projekto apimties aprašo

duomenys nuolatos yra lyginami su tikraisiais projekto eigos duomenimis. Jei pastebimi kokie

nors nukrypimai nuo kontrolinių taškų, jūs turite imtis reikiamų priemonių.

Išvardinkime dalykus, kuriuos projekto vadovas turėtų stebėti.

Darbų grafiko laikymasis. Projekto grupės nariai gali nukrypti nuo darbų grafiko, o

centrinė projekto administracija, neįsigilinusi į darbų ataskaitas, gali norėti plėsti projektą. Bet

kuriuo atveju projekto vadovas kontroliniuose taškuose turi lyginti tikrąją projekto padėtį su

planuotąja. Ataskaitos apie darbų eigą arba grupės nariai susirinkimuose gali signalizuoti apie

pavojus, tačiau kartais į juos jūs galite nekreipti dėmesio. Kiekvienas grupės narys linkęs

koncentruotis ties jam pavesta užduotim, o ne ties bendru darbų srautu. Užduotis, kuriai atlikti

reikia papildomų dviejų dienų, gali neatrodyti kaip didelė problema. Tačiau jeigu trys kiti

darbuotojai dėl to negali pradėti savo darbų, tai jau yra rimta problema. Taip pat projekto

vadovas gali neturėti laiko kiekvienos nuo kontrolinio taško nukrypusios užduoties analizei,

tačiau jeigu užduotis yra darbų grafiko kritiniame kelyje arba ji yra susijusi su keliomis kitomis

užduotimis, į ją turi būti atkreiptas ypatingas dėmesys.

Biudžeto laikymasis. Oficialios bendrosios projekto biudžeto ataskaitos atspindi

kiekvienos užduoties arba tam tikros biudžeto kategorijos (straipsnio) tikrąsias išlaidas. Projekto

biudžeto ataskaitų duomenys lyginami su planuotaisiais kontroliniuose taškuose ir sprendžiama

apie biudžeto vykdymą. Biudžeto ataskaitos yra išlaidų nukrypimų (CV – Cost Variance) analizės

pagrindas.

Ataskaitos tam tikrais laiko tarpais arba tvirtinimui gauti važtaraščiai gali būti pirmieji

įspėjimo ženklai, kad projektas vyksta ne pagal planą. Jūs privalote atkreipti ypatingą dėmesį į

ataskaitas, kuriose nurodytas grupės narių darbo valandų kiekis viršija planuotąsias. Bet kurios

užduoties įvertis galėjo būti netikslus, tačiau jeigu grupės nariai per savaitę dirba daugiau

valandų nei planuota, jūsų projekto biudžeto išlaidos darbo užmokesčiui yra viršijamos.

Projekto apimties laikymasis. Projekto apimties aprašas yra dar vienas dokumentas, kuris

naudojamas projekto eigai stebėti. Kai baigiamas projekto etapas, pasitikrinkite, ar gauti

rezultatai atitinka nurodytus projekto apimties apraše.

Reikia būti atidiems, kad nepražiopsotume potencialių nukrypimų nuo planuotos projekto

apimties. Jei grupės nariai ypač svarbiems rezultatams gauti pastoviai sugaišta daugiau laiko, nei

buvo planuota, nedelsdami užduokite jiems klausimus. Jei apimtis keičiama be leidimo, greitai

spręskite šį klausimą.

Tvirtinami rezultatai. Specialus dėmesys turi būti skiriamas rezultatams kontroliniuose

taškuose, kuriuos turi peržiūrėti sponsorius ar akcininkai ir kurie turi būti tvirtinami. Jei yra

kokių nors nukrypimų, rezultatų tvirtinimas gali vėluoti, o kai kuriuos darbus gali tekti daryti iš

naujo.



96

12.4. Informacijos apie projekto eigą platinimas

Projekto vadovui tenka peržiūrėti daug duomenų. Daugumą jų reikia apibendrinti ir

pasidalinti su kitais. Informacijos platinimas – tai akcininkams reikalingos informacijos apie

projektą teikimas. Platinama pagal anksčiau parengtą komunikacijų planą, ir tai gali būti

atliekama įvairiais būdais: informuojant projekto grupės susirinkimuose, platinant ataskaitas

apie projekto stovį, formalias projekto apžvalgas.

12.4.1. Projekto grupės susirinkimai

Susirinkimai yra geriausias grupės bendravimo būdas. Jiems turi būti rengiamasi

kruopščiai, būtina turėti aiškią darbotvarkę, svarstytinus klausimus.

Susirinkimų vedimas. Blogai, jei grupės nariai pasibaigus susirinkimui išsiskirsto nieko

naujo nesužinoję. Produktyvus susirinkimas yra toks, kai projekto vadovas nubrėžia tolesnes

darbų gaires ir išsprendžia ginčus dėl kai kurių projekto darbų. Pasirengimas susirinkimui

reikalauja nemažai pastangų projekto planams ir eigos rezultatams peržiūrėti ir palyginti.

Pasirengimo susirinkimui ir jo vedimo žingsniai:

- susirinkimo laiko paskyrimas;

- dalyvavimo susirinkime svarbos pabrėžimas;

- susirinkimo darbotvarkės parengimas ir išplatinimas;

- susirinkimo pradėjimas ir baigimas numatytu laiku;

- laikymasis susirinkimo darbotvarkės;

- prašymas pasisakyti visus susirinkimo dalyvius;

- susirinkimo minučių paskirstymas.

Susirinkimo rezultatai. Projekto grupės susirinkimuose gali būti aptariami ne tik užduočių

vykdymo klausimai. Gerai organizuotas susirinkimas gali pagerinti grupės narių

bendradarbiavimą ir palengvinti įvairių problemų sprendimą.

Susirinkimai yra gera proga stebėti grupės narių bendradarbiavimo lygį. Tikėtina, kad

grupės nariai gali nežinoti visų užduočių niuansų, todėl jų bendradarbiavimas yra būtinas. Jei

reikia, projekto vadovas gali paskirti laiką pagrindinių projekto laukiamų rezultatų tarpusavio

sąsajoms aptarti.

Jei pastebima, kad tarp projekto grupelių yra prastas ryšys ir tai gali turėti įtakos darbų

grafiko kritiniame kelyje esančių užduočių atlikimui, būtina imtis skubių priemonių, kad žmonės

gautų informaciją apie tas užduotis, nuo kurių rezultatų priklauso jų tolesni darbai.

Projekto vadovo pareiga yra skatinti grupės narių glaudų bendradarbiavimą.

Užrašų įvairiais klausimais (issues log) peržiūra turėtų būti kiekvieno projekto grupės

susirinkimo dalis. Tam sugaištama nedaug laiko, nes už kiekvieno užrašuose pasižymėto

klausimo (problemos) išsprendimą iki nurodyto laiko būna nurodytas atsakingas asmuo (žiūr.

12.2 lentelę). Atsakingam asmeniui tereikia informuoti apie esamą padėtį.

Problemų sprendimas. Projekto grupei nuolatos tenka svarstyti rūpesčius keliančias

problemas. Projekto vadovo pareiga padėti grupės nariams spręsti jas. Žmonės dažnai yra linkę

skubėti su sprendimais, todėl būtina įsitikinti, ar problema apibrėžta aiškiai ir ar yra sutarimas



97

dėl jos sprendimo būdo. Skyrus nedaug laiko apmąstymams, gali būti rastas didelių grupės

pastangų nereikalaujantis problemos sprendimo būdas.

Dažniausiai projekto grupės diskusijų tema būna darbų atlikimo vėlavimas. Sprendžiant

šias problemas reikėtų:

- išsiaiškinti vėlavimo priežastis;

- įvardinti už tai atsakingą grupės narį;

- sudaryti koregavimo veiksmų planą;

- atlikti koregavimo veiksmus;

- stebėti rezultatus.

Apie projekto eigą turi būti informuojami ne vien tik grupės nariai, bet ir akcininkai.

12.4.2. Ataskaitos apie projekto eigą

Ataskaitos apie projekto eigą yra kitas informacijos platinimo būdas. Sponsoriui,

akcininkams, klientams nereikia visų detalių apie projektą, kurios reikalingos projekto grupės

nariams. Tačiau jie nori būti informuoti apie projekto eigą. Dėl to daugelio projektų komunikacijų

planuose yra numatytas reguliarus ataskaitų apie projekto eigą platinimas.

Ataskaitos apie projekto eigą gali būti platinamos naudojant bendro naudojimo katalogus

(failus), el. paštą. Specifiniai platinimo būdai turi būti nurodyti komunikacijų plane. Ataskaitų

formatas turėtų būti pastovus. Paprastai jose būna:

- projekto stovio, palyginto su darbų grafiko ir biudžeto kontroliniais taškais,

santrauka;

- pagrindinių rezultatų arba plano kontroliniuose taškuose įvardintų rezultatų

pasiekimo lygis;

- svarbiausių klausimų stovis.

12.4.3. Projekto apžvalgos

Projekto apžvalgos yra daugiau formalus informacijos apie projektą platinimo sponsoriui,

akcininkams ir klientams būdas. Jei ataskaitos apie projekto eigą rengiamos beveik visuose

projektuose, tai apžvalgos nėra privalomos ir jų struktūra priklauso nuo organizacijoje

pasirinktos.

Reguliarios projekto apžvalgos gali būti atliekamos kas mėnesį ar kas metų ketvirtį. Jų

rengimas gali trukti net keletą dienų, dalyvaujant visiems su projekto vykdymu susijusiems

vadovams.

Apžvalgai reikalinga informacija gali priklausyti nuo sponsoriaus ar jūsų organizacinių

poreikių. Sponsoriui skirtą apžvalgą parengti nėra sunku, nes jūs galite žinoti jam rūpimus

klausimus. Jei apžvalga rengiama platesnei auditorijai, reikėtų surinkti pageidavimus, apie ką

klausytojai norėtų išgirsti.

Apžvalgos pristatymo darbotvarkėje reikėtų numatyti laiko tarpą kiekvienam klausimui.

Apžvelgtini klausimai:

- pagrindiniai pasiekimai einamosios apžiūros periode;

- biudžeto suvestinė;

- pagrindiniai klausimai;



98

- rizikos mažinimo ir reakcijos į jos veiksnius planai;

- planuojami pasiekimai kitos apžvalgos laikotarpiui.

12.3 lentelėje parodytas projekto apžvalgos lapo pavyzdys.

12.5. Sandorių su tiekėjais priežiūra

Daugelyje projektų reikalinga išorinių tiekėjų pagalba. Jei jūs esate sudarę sandorius

darbams atlikti, neišvengiamai tenka administruoti juos. Tai stebėjimas ir tikrinimas, ar tiekėjai

laiku atlieka sutartus darbus.

12.5.1. Tiekėjų atliekamų darbų ataskaitos

Tiekėjų darbų ataskaitos yra tiek pat svarbios, kaip ir projekto grupės narių ataskaitos.

Tiekėjų darbų rezultatai turi būti gaunami laikantis jūsų projekto darbų grafiko, ir grupės narių

atliekamos užduotys gali priklausyti nuo jų.

Ataskaitų apie atliktus darbus teikimas turi būti numatytas sandorio darbų užduotyje

(SOW). Ryšiai su tiekėjais yra daugiau formalaus pobūdžio ir turi teisinę potekstę.

12.3 lentelė. Projekto apžvalgos lapo pavyzdys

Projekto apžvalga

Apžvalgą parengė:

Pagrindiniai pasiekimai:

1. Pasiekimas ...

2. Pasiekimas ...

Problemos

Problemos pavadinimas Esamas stovis

Biudžetas

Planuotasis Einamasis

Turimos lėšos

Išlaidos

Pagrindiniai rizikos veiksniai

Rizikos veiksniai, jų galimas poveikis Rizikos mažinimo planas

Galimos kliūtys:

1. Kliūtis ...

2. Kliūtis ...

Planuojami pasiekimai iki kitos apžvalgos:

1. Planuojamas pasiekimas ...

2. Planuojamas pasiekimas ...



99

Netgi jei tiekėjų ataskaitų detalės yra nurodytos darbų užduotyje (SOW), projekto vadovas

turi įsitikinti, ar tiekėjas pateikia reikiamus duomenis ir reikiamo pavidalo. Savaitinėse

ataskaitose turi būti aiški informacija apie tiekėjo pasiektus rezultatus, nurodant atliktų darbų

procentą, rezultatų pristatymo datos patvirtinimą, problemas ir riziką, dėl ko gali būti vėluojama

pateikti rezultatus.

Kai kurie projektų vadovai organizuoja mėnesinius ar kitokio dažnumo susitikimus su

tiekėjais darbų eigai apžvelgti ir problemoms apsvarstyti.

12.5.2. Nesutarimų su tiekėjais aiškinimasis

Projekto grupės nariai ir tiekėjas kai kuriuos užduoties tiekėjams punktus gali suprasti

skirtingai. Gali būti nesutarimų dėl programavimo technologijų (pvz., senųjų ar objektinio

programavimo) pasirinkimo. Neigiamą poveikį gali turėti „ego veiksnys“ (aš esu labai protingas,

darykite kaip pasakysiu). Galimi ginčai ir dėl platformos.

Visi tokie nesutarimai turi būti svarstomi geranoriškai ir siekiama abiem šalims priimtinų

sprendimų. Nepavykus susitarti elgiamasi pagal sandoryje išdėstytas nuostatas.

12.5.3. Tiekimų vėlavimai

Kai gaunama informacija apie tiekimų vėlavimus, apie susidariusią padėtį reikėtų

informuoti suinteresuotus asmenis. Projekto vadovas turėtų imtis tokių veiksmų:

- susitikti su tiekėju ir gauti daugiau specifinės informacijos apie tiekimo vėlavimą. Gal

įmanoma sutrumpinti vėlavimo laiką ar pateikti dalį produkcijos, kokių veiksmų imasi ir kokias

problemas sprendžia tiekėjas tokioje situacijoje;

- informuoti savo organizacijos pirkimų ir teisės departamentus. Be jų sutikimo jūs

neturėtumėte keisti savo darbų grafiko, nutraukti sandorį ar reikalauti baudų;

- peržiūrėti vėlavimo įtaką visam projekto planui. Bet koks tiekimo vėlavimas reikalauja

peržiūrėti projekto apimtį, darbų grafiką, biudžetą, reikalavimus ištekliams. Dėl tiekimo vėlavimo

atsiranda nauji rizikos veiksniai ir būtina peržiūrėti rizikos valdymo planą;

- informuoti sponsorių kaip galima greičiau ir nurodyti jam galimą vėlavimų įtaką

projekto planui. Jei ta įtaka yra svari, sponsorius gali šią problemą kelti į aukštesnį lygmenį,

šnekėtis su tiekėjo vadovybe;

- informuoti akcininkus kaip galima greičiau. Tiekimų vėlavimai gali tapti gandų apie

projekto gyvybingumą priežastimi, todėl geriau, kad ir akcininkai žinotų tuos vėlavimo faktus.

12.5.4. Atsiskaitymai su tiekėjais

Sandoriuose su tiekėjais nurodoma, kaip su jais bus atsiskaitoma. Atsiskaitymai gali būti

reguliarūs arba susieti su atliktų darbų priėmimu. Netgi jei organizacijos finansų departamentas

tvarko atsiskaitymus, projekto vadovas yra pirmasis sąskaitų gavėjas.

Jei jūs esate atsakingas už mokėjimo sąskaitų patvirtinimą, pasitikrinkite, kad suprantate

gautą sąskaitą ir esate dalyvavęs rengiant to mokėjimo garantiją.

Jei tiekėjui turi būti mokama remiantis darbų grafike numatytais rezultatais, jūs turite

patvirtinti tų rezultatų gavimą ir priėmimą. Tam turi būti peržiūrėta ir patikrinta tiekėjo

pristatytos produkcijos kokybė ir tik tada tvirtinamas mokėjimas.



100

Tiekėjo žmonių išlaidoms apmokėti turi būti pateikiami kvitai ir kokiems tikslams tos

išlaidos buvo padarytos. Jei nesate tikras pateiktos sąskaitos teisingumu, kreipkitės į savo

organizacijos finansininką, kad jis peržiūrėtų tą tiekėjo sąskaitą.

Jeigu jums nėra aiški sandoryje nustatyta atsiskaitymų tvarka, kreipkitės į savo

organizacijos pirkimų padalinį ir prašykite paaiškinti. Jie juk yra sandorių ekspertai ir gali padėti

jums. Jei jūsų ir tiekėjo nuomonės dėl atsiskaitymo sumos skiriasi, reikėtų kviestis pirkimų

ekspertą ginčui išspręsti.

12.5.5. Reikalų su tiekėjais tvarkymas

Dalykiški santykiai. Projekto eigoje grupei tenka turėti „aukšto lygio“ santykius su tiekėju.

„Aukštas lygis“ reiškia, kad yra numatyti formalūs susirinkimai, kurių metu jūs ir tiekėjas turite

galimybes kelti problemas ir siūlyti sprendimus teisės aktų ir sandorio ribose. Jei nepavyksta

pasiekti susitarimo dėl sandoryje numatyto, bet darbų užduotyje (SOW) gerai neapibrėžto

kažkokio darbo, projekto eigos svarstymo susirinkime turi būti aiškiai nurodomi trūkumai ir

įvardinamos problemiškos sritys, kuriose tiekėjas nenori toliau tęsti darbų, nes jie nebuvo

numatyti darbų užduotyje.

Apskritai, tiekėjai stengiasi padėti projekto vykdytojams tose srityse, kur jie yra

kompetentingi. Bet jie tampa irzlūs, kai jų prašoma padaryti tai, kas nebuvo aiškiai apibrėžta

sandorio darbų užduotyje. Tai dažniausia projektų vadovų ir tiekėjų ginčų priežastis.

Įsitikinkite, kad tiekėjas gerai supranta jūsų poreikius. Su tiekėju kruopščiai išnagrinėkite

sandorio darbo užduotį (SOW), kad ateityje nekiltų neaiškumų, ką už sutartą sumą reikėjo

padaryti.

Gerai pasirenkite deryboms su tiekėju, būkite griežti ir tikslūs. Kartais manoma, kad

baigus svarstyti kažkokį klausimą yra priimtas ir susitarimas. Ne veltui sakoma, kad kuo didesnis

sandoris, tuo didesni tiekėjo pažadai. Pasistenkite raštu užfiksuoti tuos pažadus ateičiai, kai teks

vėl grįžti prie anksčiau svarstyto klausimo. Tada pokalbį jūs galėsite pradėti sakydami, kad norite

pasitikslinti tai, ką tiekėjas yra kažkada pažadėjęs.

Projekto vykdymo metu tokie numatomi (tylūs) susitarimai sutinkami dažnai. Tarkime,

pvz., jums ir tiekėjui svarstant kokį nors projekto komponentą jis sako: „aš kai ką pasitikrinsiu ir

vėliau grįšim prie to komponento. Aš manau, kad mūsų kompanija gali jį pateikti jums veltui“. Šį

klausimą jūs atidedate kažkuriam laikui. Vykdant projektą jums prireikia to komponento. Jei

pažadas nebuvo užfiksuotas raštu, jūs galite turėti keblumų dėl tiekėjo neįvykdyto pažado.



101

13. PROJEKTO KONTROLĖ

Projekto eigoje vadovas turi pastoviai stebėti gaunamus rezultatus. Nukrypimai nuo

projekto plano gali būti perspėjimas, kad reikia daryti pradinio (originalaus) plano korekcijas.

Projekto eigoje gali atsirasti naujų reikalavimų ir/ar pageidavimų plėsti projekto apimtį. Todėl

būtina numatyti ir apgalvotai vykdyti projekto plano keitimo procedūras.

Integruotoji keitimų kontrolės sistema įvertina bendrąjį keitimų poveikį visam projektui ir

padeda padaryti juos visuose projekto plano elementuose. Pvz., jei daromi projekto apimties

keitimai, tai gali tekti koreguoti ir darbų grafiką, biudžetą.

Projekto plano keitimai verčia akcininkus daryti kompromisą tarp projektą ribojančių

veiksnių: laiko, kainos, kokybės, apimties.

13.1. Integruotoji keitimų kontrolė

Projekto planavimo etape numatytus dalykus vėliau kartais tenka keisti. Keitimų

priežastis gali būti pasikeitusi verslo strategija, konkurencinė grėsmė, naujų technologijų

atsiradimas, kas nebuvo žinoma planavimo metu.

Projekto eigoje gali tekti keisti įvairius plano elementus. Kad išvengtume netvarkos,

pakeitus kažkurį plano elementą, nepamirškime atitinkamai pakoreguoti ir kitų plano elementų.

Tam ir yra reikalinga integruotoji keitimų kontrolės sistema.

Keitimų kontrolė gali būti atliekama įvairiai. Tam, pvz., gali būti sudarytas keitimų

kontrolės komitetas iš sponsoriaus, akcininkų ir projekto vykdytojų, kurie peržiūri visus

prašymus ir leidžia arba neleidžia daryti keitimus, arba prašymus gali svarstyti projekto grupė.

Didesniuose ir sudėtingesniuose projektuose keitimų kontrolė paprastai turi didesnį formalumo

laipsnį. Nežiūrint to, kas peržiūri ir tvirtina projekto plano keitimus, apie projekto plane

numatytas ribas viršijančius keitimus turi būti informuojami akcininkai. Jie išdėsto savo

nuomonę apie tokius keitimus.

Panagrinėkime smulkiau, ką apima projekto apimties, darbų grafiko, kainos ir kitų

projekto plano elementų keitimo kontrolė.

13.1.1. Projekto apimties keitimo kontrolė

Projekto apimties plano (žiūr. 3 skyrių) viena iš dalių yra apimties valdymo planas.

Projekto eigoje, prireikus keisti projekto apimtį, vadovaujamasi šiuo planu. Apimties keitimo

kontrolė yra bet kokių projekto apimties keitimų valdymas ir dokumentavimas.

Štai keletas priežasčių, verčiančių keisti projekto apimtį:

- projekto rezultatų peržiūros metu nustatyta, kad gauta papildomų rezultatų, kurie

nebuvo numatyti projekto plane;

- projekto grupės nariai įrodo, kad reikia keisti projekto reikalavimus;

- yra formalus prašymas papildyti projekto siekiamus rezultatus naujais;

- pasikeitė kuriamo produkto projektas (design).

Idealiu atveju projekto apimtis neturėtų būti keičiama be formalaus patvirtinimo

(leidimo). Tačiau projekto vykdytojai, pasikalbėję su naudotojais arba savo nuožiūra, kartais



102

padaro tai ar taip, kas nenumatyta projekto apimties plane. Jei jūs pastebite, kad tapote

nukrypimo nuo planuotos projekto apimties auka, o pakeitimas jau yra padarytas, reikėtų siekti,

kad būtų išanalizuota pakeitimo įtaka kitoms projekto dalims ir kad pakeitimas formaliai būtų

patvirtintas.

Apžvelkime keletą projekto apimties keitimo žingsnių ir patarimų:

- naudokime standartinės formos prašymą projekto apimties keitimams daryti,

aprašykime norimą keitimą, jo priežastį ir kas yra prašytojas;

- išanalizuokime prašomo keitimo įtaką projekto biudžetui, darbų grafikui, kuriamo

produkto kokybei;

- naudokime patvirtintas procedūras prašymams priimti ar atmesti;

- apie prašymą keisti projekto apimtį informuokime visus akcininkus;

- patvirtintus keitimus įtraukime į projekto planą.

Projekto apimties keitimai gali iššaukti koregavimo veiksmus ir/ar kontrolinių taškų

projekto plane keitimą.

Koregavimo veiksmai. Jūs, kaip projekto vadovas, pakeistai projekto apimčiai galite

nepritarti ir nenorėti plėtoti to pakeitimo. Jums gali tekti ieškoti kelių, kaip sugražinti projektą į

ankstesnes vėžes. Tam gali tekti sugaišti kažkiek laiko. Taip pat jūs galite norėti išsiaiškinti, kodėl

buvo nukrypta nuo projekto planuotos apimties ir ko reikėtų imtis, kad tai neatsitiktų ateityje,

pvz., apšviesti projekto grupės narius apimties keitimo klausimais.

Kontrolinių taškų derinimas. Bet koks planuotas ar neplanuotas projekto apimties

keitimas reikalauja pakoreguoti dalį pradinio projekto plano. Mažiausiai, tenka koreguoti

projekto apimties aprašą. Priklausomai nuo keitimų dydžio, taip pat gali tekti keisti darbų grafiko

ir biudžeto kontrolinius taškus.

Projekto apimties keitimas gali turėti žymią įtaką suplanuotam darbų grafikui.

13.1.2. Darbų grafiko kontrolė

Projekto grupės narių darbo ataskaitų atitikimo projekto darbų grafikui peržiūros tikslas

yra įsitikinti, ar projektas vyksta normalia vaga, ar reikalingi kokie nors keitimai, galintys

pagerinti kritinio kelio darbus. Darbų grafiko kontrolė yra bet kokio darbų grafiko keitimo ir

tokių keitimų dokumentavimo procesas.

Projektams valdyti skirta programinė įranga yra puiki priemonė, įgalinanti kontroliuoti,

kaip laikomasi darbų grafiko. Ji gali pateikti individualių užduočių planuotų pradžios ir pabaigos

laikų palyginimo su tikruoju laiku rezultatą, prognozuoti bet kokių pradinio darbų grafiko

pakeitimų poveikį atskiroms užduotims, kritiniam darbų keliui ir projekto pabaigos terminui.

Taip pat galima modeliuoti įvairius „o kas, jeigu“ scenarijus, stebėti, kokią įtaką atskiriems

projekto etapams ar galutiniam terminui turi užduočių trukmės pakeitimas arba naujos

papildomos užduoties įtraukimas į patvirtintą projekto planą.

Projekto grupės narių darbo ataskaitos ir kitos ataskaitos visų pirma naudojamos kritinio

kelio darbų eigai įvertinti. Prisiminkime, kad kritinis kelias – tai ilgiausias kelias projekto darbų

grafike, ir bet kokios užduoties jame atlikimo vėlavimas gali pailginti viso projekto laiką.



103

Darbų grafiko kontrolės rezultatai – tai grafiko naujinimai, kitų projekto elementų

korekcijos, įgyta patirtis.

Darbų grafiko naujinimai – tai bet kokie projekto darbų grafiko keitimai. Dažniausiai jie

atliekami kas savaitę, remiantis projekto grupės narių darbo ataskaitomis ir gautų rezultatų

palyginamu su grafiko kontrolinių taškų duomenimis.

Kitų projekto elementų korekcijos. Prireikus keisti darbų grafiką, neišvengiamai tenka

koreguoti ir kitus projekto elementus – išteklius, biudžetą, komunikacijas, kokybę, riziką.

Įgyta patirtis. Projekto vykdytojai sužino, dėl kokių priežasčių teko keisti darbų grafiką ir

ką reikėtų daryti, kad kituose projektuose tokių keitimų būtų išvengta.

Projekto apimties ir darbų grafiko keitimai reikalauja papildomų išlaidų.

13.1.3. Išlaidų kontrolė

Tai procesas, kurio metu tikrinamos padarytos išlaidos, nustatomi nukrypimai nuo

biudžeto kontrolinių taškų, imamasi reikiamų korekcijų (pvz., dėl lėšų stygiaus galbūt bus kažko

atsisakoma: funkcionalumo, kokybės, kt.).

Išlaidų kontrolės rezultatas – peržiūrėti kainų įverčiai, kitų projekto elementų korekcijos,

įgyta patirtis.

Įvertintų kainų peržiūra. Laikui bėgant išteklių kainos kinta. Planavimo etapo metu jos

galėjo būti vienokios, o projekto vykdymo metu jos gali būti jau kitokios. Įvertinus planuotos

kainos ir einamosios kainos skirtumą, reikia imtis korekcinių veiksmų.

Kitų projekto elementų korekcijos ir įgytos patirties požiūriu samprotavimai yra panašūs,

kaip ir darbų grafiko kontrolės atveju.

13.1.4. Kitų projekto plano elementų keitimo kontrolė

Projekto apimtis, darbų grafikas, biudžetas yra pagrindiniai kontrolės taikiniai. Tačiau be

jų projekto plane yra ir kitos dalys, kurias taip pat gali reikėti keisti projekto eigoje. Žvilgtelkime

dar į keturių elementų - išteklių, reikalavimų, infrastruktūros ir konfigūracijos - keitimą.

Išteklių keitimas. Kai tik projekto grupė papildoma nauju nariu arba ją palieka narys,

būtina užfiksuoti darbuotojo pasikeitimo priežastį, naujo nario ir išėjusio žmogaus pavardę,

pasikeitimo poveikį projektui.

Reikalavimų keitimas. Tai sudėtinga valdymo sritis. Jei reikalavimai yra papildomi naujais

arba keičiami norint pagerinti jų aiškumą, būtina atkreipti dėmesį į tai, ar tokie pakeitimai neturi

įtakos projekto apimčiai. Bet koks naujas reikalavimas turi praeiti keitimų kontrolę.

Infrastruktūros keitimas. Infrastruktūra – tai tokie elementai, kurie ilgai išlieka pabaigus

projektą. Pvz., projekto grupės narys galėjo planuoti, kad duomenų bazės valdymo sistemą leis

UNIX platformoje, tačiau tinklo tvarkymo grupė projekto eigoje paprašė pastarąją pakeisti į

WINDOWS. Infrastruktūros elementai, kurie gali būti keičiami:

- skaičiavimo sistema;

- programinės įrangos kūrimo aplinka;

- serverio operacinė sistema;

- tinklo infrastruktūra;

- tiekimo metodologijos.



104

Konfigūracijos keitimas. Dažniausiai projekto grupė sprendimus dėl programinės ar

aparatinės įrangos konfigūracijos daro tada, kai mato, jog jų sukurtas produktas geriau dirbtų

kitaip sukonfigūruotoje aplinkoje. Dažnai sutinkamas konfigūracijos keitimo pavyzdys yra toks.

Duomenų bazės projektuotojai pasirenka vienokią indeksų sistemą ir naudoja ją projektuojamoje

bazėje. Bet programuotojai, rašantys programas darbui su tokia baze, gali manyti, kad kitokia

indeksų sistema yra geresnė. Taip gimsta konfigūracijos keitimo prašymas.

Konfigūracijos keitimai gali būti labai paprasti ir gana sudėtingi. Tai priklauso nuo

konfigūracijos prigimties ir ko tikimasi iš programinės ar aparatinės įrangos. Tačiau dažniausiai

konfigūracijai pakeisti nereikia daug laiko (pakanka poros valandų), todėl tai nėra didelė kliūtis

projektams. Nereikėtų pamiršti, kad kai kurie konfigūracijos keitimai reikalauja iš naujo pakrauti

(reboot) sistemą ir todėl konfigūracijos keitimo rezultatai tampa prieinami tik po kažkurio laiko.

13.2. Kokybės kontrolė

Kokybės klausimas dažnai susilaukia mažesnio dėmesio nei projekto apimties, biudžeto ar

darbų grafiko klausimai. Tačiau kokybės kontrolės stoka gali skaudžiai atsiliepti projektui.

Kokybės kontrolė yra procesas, kurio metu stebima, ar projekto rezultatai atitinka nustatytų

standartų reikalavimus, ar nereikia daryti atitinkamų keitimų, kad būtų pašalintos neigiamą

poveikį kokybei darančios priežastys. Kokybės valdymo planas (žiūr. 7 skyrių) yra specifinių

kontrolės veiklų pagrindas.

Kokybė kontroliuojama visą projekto vykdymo laiką. Projekto darbų grafike pažymėti

etapai nurodo, kada turi būti gauti pagrindiniai rezultatai. Kokybės tikrinimo priemonėmis ir

būdais įsitikinama, ar gauti rezultatai yra tinkamo lygio. Kokybės tikrinimo veiklos yra svarbios

projekto etapo užbaigimui patvirtinti.

Tarp įvairių projekto darbų rezultatų kokybės sekimo būdų bene labiausiai išsiskiria

tikrinimas (testavimas). Patikrinus kokybę galimi tokie tolesni žingsniai projekte: užduoties

atlikimas iš naujo, keitimų darymas, rezultatų priėmimas, nežiūrint, kad yra kai kurių defektų.

13.2.1. Tikrinimas (testavimas)

Tikrinimas yra plati sąvoka, apimanti apžiūrą, matavimą, testavimą. IT projektuose

tikrinimas dažniausiai vadinamas testavimu.

Testavimui atlikti paprastai reikia laiko. Testavimas yra įkyrus darbas. Kažkoks modulis

leidžiamas dar ir dar kartą, jo veikimas tikrinamas įvairiais požiūriais.

IT projektams bendros yra šios testavimų rūšys:

Modulio testavimas. Programuotojas, baigęs kurti modulį, turi ištestuoti jį. Kai kurie

moduliai, kurie skirti darbui drauge su kitais moduliais, nesiduoda testuojami. Vis dėlto

programuotojas gali patikrinti kai kuriuos jo elementus. Leisdamas modulio programą per

tikrinimo priemonę (checker) eilutę po eilutės, jis patikrina jo veikimą. Procesas gali būti labai

įdomus arba gniuždantis, jei modulis kažką daro klaidingai, o rasti klaidos programoje nesiseka.

Modulių rinkinio (unit) testavimas. Tai, pvz., modulių rinkinys kažkokio tipo uždaviniams

spręsti: piešti grafikams, apdoroti vaizdams, spausdinti ataskaitoms, kt.



105

Sistemos testavimas. Tai visos sistemos testavimas ir jis gali trukti ilgai. Tikrinamas

funkcionalumas, veikimo greitis, tikslumas, saugumas, t. t.

Tinkamumo naudotojams testavimas (UAT – User Acceptance Testing). Tą atlieka

nedidelis naudotojų ratas kažkurį laiką. Stebima, ar nėra klaidų (bugs), greičio, loginių ar

apkrovos problemų. Sistema turi būti tokia, kokios naudotojai tikėjosi.

Tinkamumo įmonei testavimas (FAT – Factory Acceptance Testing). Dideles sistemas

testuoti yra geriausia tose vietose, kur jos buvo sukurtos. Pvz., orų prognozės radarų sistema,

kuri buvo papildyta nauja aparatine ir programine įranga. Visa tai išbandoma pas kūrėją

(pardavėją) ir tik po to perkeliama į pirkėjų nurodomas vietas. Šitokį testavimo būdą naudoja

didelių valstybinių užsakymų vykdytojai.

Tinkamumo konkrečiai vietai testavimas (Site Acceptance Testing). Produktas

testuojamas pristačius jį į pirkėjo nurodytą vietą. Pvz., anksčiau turėtas radarų sistemos

pavyzdys. Nors ji buvo išbandyta kūrėjo aplinkoje, tačiau dar patikrinama, kaip sistema veikia

pirkėjo aplinkoje.

Testavimas visada yra svarbus IT projekto kokybės patvirtinimo žingsnis. Kai kuriais

atvejais reikia dar daugiau tikrinimų, priklausančių nuo įvairių veiksnių.

Geografiškai išbarstyta grupė. Projekto grupė dažnai būna išdėstyta keliose vietose.

Programinė įranga gali susidėti iš keleto modulių, kuriuos kuria skirtingos programuotojų

grupės. Nors ryšys tarp grupių ir yra geras, tačiau betarpiškų asmeninių kontaktų nebuvimas gali

padidinti skirtingo supratimo riziką, gali iššaukti skirtumus moduliuose, kas turėtų įtakos visam

programų paketui. Tokiais atvejais reikėtų detalesnio kiekvieno modulio testavimo.

Tiekėjų pristatomi produktai. Tiekėjų pristatomų produktų testavimas turi ypatingą

reikšmę. Ypatumas yra tame, kad testavimo būdas ir laikas turi būti numatyti sandoryje. Tiekėjo

pristatyto produkto ir visos likusios sistemos integruotasis testavimas duoda atsakymą, ar

pristatytas produktas yra priimtinas. Tiekėjo produkto priėmimas reiškia, kad jam už darbą turi

būti apmokėta. Taigi šiais testais turi būti patikrintas visų sandorio darbams keltų reikalavimų

įgyvendinimas.

Nors testavimas yra dažniausiai naudojamas IT projektų kokybės kontrolės būdas, tačiau

jis nėra vienintelis.

13.2.2. Kiti kokybės kontrolės būdai ir priemonės

Pareto diagrama. Ji naudojama laiko bėgyje atsirandančių problemų svarbai ir dažniui

pavaizduoti. Pareto (Vilfredo Pareto) diagramos pagrindas yra vadinamoji 80 / 20 taisyklė. Šis

mokslininkas pastebėjo, kad Italijoje 80% turto priklauso 20% jos gyventojų. Šis principas buvo

perkeltas į daugelį disciplinų (pvz., manoma, kad 80% projekto darbų padaro 20% darbuotojų).

Taikant šį principą kokybės kontrolėje, sakoma, kad didžiosios projekto defektų dalies priežastis

yra nedidelis problemų rinkinys. Pareto diagrama padeda atskirti, kurios problemos yra

svarbiausios ir turi didžiausią poveikį projektui. Problemos atvaizduojamos stačiakampiais,

išdėstytais mažėjimo tvarka. Kuo problema sukelia daugiau defektų, tuo didesnis stačiakampis, ir

jai išspręsti turėtų būti skiriama daugiau dėmesio (žiūr. 13.1 pav.).



106

Pareto diagramos tikslas yra dvejopas:

- pavaizduoti defektų reliatyvią svarbą;

- nurodyti problemas, kurioms išspręsti turi būti dedama daugiausia pastangų ir kurios

daro didžiausią poveikį projektui.

13.1 pav. daugiausia defektų atsiranda dėl A ir B problemų (pvz., A problema –prasti

programavimo įgūdžiai). Išsprendus vien tik jas, projekte būtų pašalinta 60-70% visų defektų.

Todėl A ir B problemoms turėtų būti skiriamas pagrindinis dėmesys.

Kontrolinės diagramos yra naudojamos kontroliuojamo parametro svyravimams laike

pavaizduoti. Jos dažniausiai naudojamos apdirbamojoje pramonėje. Tokiose diagramose svarbios

yra vidutinė, viršutinė ir apatinė leistinos reikšmės (žiūr. 13.2 pav.). Pvz., reikia ištekinti tam

tikro diametro detales. Realiai jos bus kažkiek didesnės ar mažesnės. Jei kontrolierius nustato,

kad jų diametras yra tarp viršutinės ir apatinės leistinų ribų, tokios detalės yra tinkamos.

Geriausia, kai jų diametras būna artimas vidutinei reikšmei.

Statistinė atranka. Jeigu jūs turite daugelio darbų rezultatus (pvz., daug ištekintų detalių),

visų jų tinkamumui įvertinti reikėtų atlikti daug matavimų. Tai užimtų daug laiko ir būtų brangu.

Pasitelkus statistinės atrankos metodą, atsitiktinai paimami tik kelių darbų rezultatai, jie

išmatuojami ir sprendžiama apie visų darbų rezultatų (visos detalių partijos) kokybę.

Defektų

dažnumas

1000

750

500

250

A B C D E problema

Suvestinis

defektų

procentas

100%

75%

50%

25%

13.1 pav. Pareto diagramos pavyzdys

5,06

5,00

4,94

Viršutinė riba

Vidutinė reikšmė

Apatinė riba

13.2 pav. Kontrolinės diagramos pavyzdys (taškas – matavimo reikšmė)



107

Projekto struktūrinė (blokinė) schema ir proceso diagrama. Apie jas rašyta 7 skyriuje,

nagrinėjant kokybės planavimo klausimus. Struktūrine schema paprastai atvaizduojami sąryšiai

tarp įvairių projekto elementų. Struktūrinė schema arba duomenų sekų diagramos (DFD – Data

Float Diagram) padeda numatyti galimų problemų atsiradimo vietą ir laiką. Todėl tokios

diagramos gali būti labai naudingos ir projekto rezultatų kontrolės metu, nustatant problemos

atsiradimo priežastį.

Tendencijų analizė. Tai matematiniai metodai, įgalinantys prognozuoti defektų atsiradimą,

remiantis anksčiau sukauptais rezultatais.

Testavimas ar kitokie kontrolės būdai naudojami tam, kad nustatytume, ar nereikia imtis

priemonių, kad gautume geresnius rezultatus.

13.2.3. Veiksmai kokybės neatitikimo atvejais

Jei projekto rezultatų (tarpinių ar galutinių) kokybė neatitinka keliamų reikalavimų,

sprendžiama, kokių veiksmų reikėtų imtis trūkumams pašalinti. Dažniausiai imamasi tokių

veiksmų: perdarymo, projekto vykdymo proceso pareguliavimo, susitaikymo su atsiradusia

blogybe.

Perdarymas. Tai bet kuri defektų šalinimo veikla. Pvz., patikrintame programinės įrangos

modulyje aptikus neatitikimus, perrašoma jo programa.

Perdarymams reikia laiko ir lėšų, todėl gali tekti daryti projekto darbų grafiko ir biudžeto

pakeitimus.

Sprendimas dėl produkto perdarymo priklauso nuo aptikto defekto sunkumo ir jo įtakos

galimybei naudoti produktą. Apie defektą reikėtų informuoti sponsorių, akcininkus, klientus ir

pasitelkti juos priimant sprendimą.

Projekto vykdymo proceso pareguliavimas. Bet kurio proceso pareguliavimas gali

atsiliepti visam projektui. Jeigu neaišku, ar proceso pareguliavimas palies tik nedidelę darbuotojų

grupelę ir neturės platesnių pasekmių, geriausia išanalizuoti proceso pareguliavimo pasekmes ir

gauti formalų leidimą daryti tai.

Susitaikymas su atsiradusia blogybe. Jei projekte sukurto produkto išleidimas numatytu

laiku yra daug svarbesnis už neatitikimų pašalinimą, tuomet tenka sutikti su žemesne produkto

kokybe. Nepašalintų trūkumų (defektų) bendroji įtaka turi būti išanalizuota, su tuo turi būti

supažindinti projekto akcininkai ir gautas jų sutikimas išleisti ne visai kokybišką produktą.

Vėliau, pastebėti produkto trūkumai bus šalinami platinant pataisymus (upgrade).

Dar vienas svarbus kokybės kontrolės aspektas yra projekto dokumentų kokybė.

13.2.4. Dokumentų kokybė

IT projektuose sukuriami techninio ir netechninio pobūdžio dokumentai. Jų kokybe

(turiniu, kalbos taisyklingumu, aiškumu, kt.) taip pat turi būti rūpinamasi. Tai produkto

dokumentai naudotojams, naudotojų mokymo medžiaga, pagalbos teikimo (help-desk) medžiaga,

dokumentai priežiūros grupėms.

Dokumentai naudotojams. On-line būdu teikiamos ar spausdintinės instrukcijos sistemos

naudotojams turi būti parengtos kruopščiai. Daug ką erzina, pvz., toks dalykas, kai paspaudus



108

klaviatūroje funkcinį klavišą F1, kuris paprastai naudojamas pagalbai išsikviesti, gaunamas

atsakymas „Šiuo klausimu pagalba neteikiama“ arba gaunama minimali informacija.

Naudotojų mokymo medžiaga. Sukurtos sistemos naudotojų mokymas gali būti atliekamas

įvairiai: padedant instruktoriams, savarankiškas mokymasis, naudojant tam tikslui išleistas

knygas, arba on-line būdu teikiamą medžiagą. Mokomoji medžiaga, įskaitant demonstracines

priemones, turi būti gerai apgalvota, suprantama ir tinkamai parengta.

Pagalbos teikimo (help-desk) medžiaga. Projekto vykdytojai dažnai pasirūpina, kad būtų

sukurta grupė žmonių, kurie naudotojams teiktų konsultacijas, pagalbą neaiškumų atvejais,

dirbant su projekte sukurta sistema. Vėlgi, tam naudojama medžiaga turi būti kokybiška.

Dokumentai priežiūros grupėms. Prie projekto rezultatų kokybės prisideda tikslūs ir

patogūs dokumentai sukurtos sistemos prižiūrėtojams.

Serverių administratoriai turi žinoti, kokią įtaką serveriams gali turėti naujai įdiegta

sistema. Tas pat taikytina ir asmeninių kompiuterių (PC) prižiūrėtojams, nes įdiegta nauja

sistema gali turėti poveikį ir klientų kompiuteriams. Todėl turėtų būti parengti atitinkami

dokumentai priežiūros klausimais.

Projekte sukurtos sistemos priežiūros dokumentų taip pat gali reikėti duomenų bazių

administratoriams, kompiuterių tinklo ir kitiems specialistams.

13.3. IT projektų kokybės kontrolė

IT projektuose kokybės kontrolė pradedama žiūrint:

- ar laikomasi gerai žinomų ir plačiai paplitusių standartų;

- ar projekto pradžioje buvo sukurta aplinka (teisinė, organizacinė,

technologinė), kuri garantuotų sėkmę.

Minėtiems klausimams spręsti projekto grupė sugaišta daug laiko. Tam reikia supirkti

įvairius dalykus ir būti pasišventusiems projektui. Panagrinėkime kiekvieną iš šių klausimų

atskirai.

13.3.1. Standartai

IT įmonės, kurios laikosi standartų, pasiekia geresnių rezultatų. Pvz., kuriant programinę

įrangą laikomasi tokių standartų:

- naujos programos rašomos taip, kad joms leisti pakaktų XML naršyklės;

- naujose programose naudojamos Web funkcijos, kaip J2EE, o ne savos funkcijos;

- naujose programose perduodant duomenis klientui naudojamas SOAP (Simple Object

Access Protocol) protokolas (prisiminkime, kad tai OSI modelio transporto lygmens

standartų rinkinys).

Minėti standartai greičiausiai nėra visa apimantys, ir IT įmonė gali jais nesivadovauti. Bet

sutikime, kad jie yra pagrindiniai, daugumai suprantami, remiasi visuotinai pripažintais

protokolais kaip rišamąja medžiaga. Diegiant šiuos standartus įgyjamas tvirtas pagrindas naujai

programinei įrangai kontroliuoti plačiame naudotojų rate.

IT projektų vadovai turėtų sukviesti visus akcininkus ir išsiaiškinti, ar numatomi diegti

standartai visiems yra priimtini. Tai galėtų būti šie standartai:



109

- dokumentai, kaip turi būti įrengiami serveriai;

- darbo vietų įrengimo standartai, apimantys operacinę sistemą, kontoros automatinę

įrangą, naršykles, valdymo pulto (panel) nustatymus, kt.;

- programinės įrangos kūrimo standartai;

- kompiuterių tinklo įrengimo standartai, įskaitant tinklo veikimo protokolus.

13.3.2. Standartų organizacijos

Standartų organizacijos rengia pačius įvairiausius standartus. Viena iš jų yra Tarptautinė

standartų organizacija (ISO – International Standards Organization). Kokybės kontrolei įmonės

naudoja ISO 9000 standartą. Kadangi ISO 9000 yra didelis standartas, tikriausiai internete galima

po truputį surinkti informaciją apie jį, sužinoti kaip gimsta ISO standartai ir kokie standartai yra

prieinami.

DMTF (Distributed Management Task Force) standartų organizacija rengia sistemų

valdymo būdų ir sąsajų standartus. Pvz., Microsoft savo leidžiamuose Windows naudoja WBEM

(Web-Based Enterprise Management) standartą, kurį yra parengusi minėta standartų

organizacija.

IEEE (Institute of Electronic and Electric Engineers) yra parengusi plačiai žinomus tinklų

protokolus (protokolas – tai standartų rinkinys). Pvz., IEEE 802.11 yra bevielio vietinio tinklo

(WLAN) standartas.

ITIL (Information Technology Infrastructure Library) yra dar viena naudinga ir įdomi

standartų organizacija, kuri specializuojasi darbinės aplinkos (serverių, tinklo infrastruktūros,

mainfreim‘ų, kt.) valdymo gerinimo srityje. ITIL organizacijai priskiriamas posakis, kad visų

pirma reikia suprasti verslo procesus ir tik po to taikyti technologijas.

ANSI (American National Standards Institute) – tai standartų organizacija, kuri čia mums

įdomi tuo, kad projektų valdymo žinyną [PMBOK] parengė ji.

Standartų organizacijos yra įdėję daug pastangų kurdamos standartus, kad programų

sistemos galėtų sklandžiai sąveikauti tarpusavyje. Projektų vadovai turėtų žinoti standartus ir

laikytis jų.

13.3.3. Projektų valdymo kokybės gerinimas

Yra daug būdų projektų kokybei gerinti. Visų pirma reikėtų įvertinti savo organizacijos

galimybes vykdyti projektus aukštu lygiu. Tam galėtų pasitarnauti CMM (Capability Maturity

Model) modelis [CMM].

CMM modelyje skiriami penki organizacijų gebėjimo lygiai, kur aukštesnieji yra paremti

žemesniaisiais. Dauguma organizacijų pirmuosius savo projektus atlieka žemiausiu, 1-uoju

gebėjimų lygiu. Šie penki gebėjimų (įgūdžių) lygiai CMM modelyje charakterizuojami taip:

1 lygis – pradinis (initial). Šis gebėjimų lygis rodo, kad kiekvienas projektas organizacijoje

vykdomas kaip specialus vienkartinis procesas. Dažnai tai daroma chaotiškai, neorganizuotai,

neturint jokių formalių planų ar taisyklių. Veiklos yra neapibrėžtos ir nekontroliuojamos.

2 lygis – kartojamasis (repeatable). Organizacijoje yra numatyta tam tikra projektų

vykdymo tvarka, padedanti vertinti kainą, rengti darbų grafiką, vertinti rezultatus. Ši tvarka



110

kartojama kiekvieno projekto metu. Tačiau tvarka dar yra tobulintina, todėl kiekviename

naujame projekte daromi žingsniai projektų vykdymui gerinti.

3 lygis – apibrėžtasis (defined). Projektų vykdymo procesas yra apibrėžtas ir

standartizuotas. Visi projektai organizacijoje atliekami laikantis apibrėžtų procesų, naudojami

standartiniai dokumentai, reikalavimai, tvirtinimai ir kiti veiksmai projekto rezultatams pasiekti.

Tačiau informacija apie apibrėžtų procesų (tvarkos ir atliekamų veiklų) efektyvumą nėra

renkama.

4 lygis – kiekybiškasis (quantitative, managed). Projekto vykdymo metu organizacija

renka įvairius rodiklius. Projektas yra valdomas stebint kiekybinius ir kokybinius rodiklius.

Veiklos yra ne tik apibrėžtos, bet ir jų efektyvumas kontroliuojamas naudojant įvairius rodiklius.

5 lygis – opimizuojantysis (optimizing). Projektų vykdymo procesas yra nuolatos

tobulinamas, išnaudojant matuojamus kiekybinius rodiklius kaip grįžtamąjį ryšį.

IT technologijų diegimo sėkmė priklauso nuo projektą vykdančios IT organizacijos

gebėjimo greitai ir protingai įdiegti projektų valdymo metodologijas ir nuosekliai laikytis jų. Tik

suprasdami savo organizacijos galimybes imtis projektų gerinimo veiksmų, diegti plačiai žinomus

standartus, galime tikėtis projektų įvykdymo reikiamu kokybės lygiu.

13.4. Rizikos valdymo kontrolė

Projekto planavimo etape buvo įvardinti rizikos veiksniai (nepageidaujami įvykiai, pvz.,

sumažėjo finansavimas, sugedo įranga, iš darbo išėjo žmogus, kt.) ir parengtas reagavimo į juos

planas. Rizikos valdymas – tai procesas, kurio metu atliekami reakcijos į rizikos veiksnius

veiksmai. Šis procesas nėra vien plane įvardintų rizikos veiksnių stebėsena. Jo metu taip pat

vertinamas atliekamų reakcijos veiksmų efektyvumas.

Rizikos valdymas apima ir naujų rizikos veiksnių įvardijimą, kurie gali atsirasti bet kuriuo

projekto vykdymo metu. Nepaisant rizikos veiksnių įvardijimo detalumo pradiniame projekto

plane, pasikeitusios projekto sąlygos, verslo pokyčiai ir kiti projekto plano komponentų keitimai

gali sukelti naujus rizikos veiksnius, į kuriuos taip pat turėtų būti atsižvelgiama.

Rizikos valdymas turi glaudų ryšį su projekte iškylančių problemų valdymu. Iškilusios

problemos turi būti sprendžiamos, vertinama jų sprendimo eiga, keliamos naujos problemos.

Rizikos valdymo nagrinėjimą pradėkime nuo reakcijos į projekto plane numatytus rizikos

veiksnius rezultatų.

13.4.1. Reakcijos į rizikos veiksnius rezultatų valdymas

Rizikos planavimo metu buvo įvardinti projekto rizikos veiksniai ir, remiantis jų

pasirodymo tikimybe ir galimo poveikio projektui laipsniu, surikiuoti prioriteto tvarka. Reakcijos

į kiekvieną aukštesnio prioriteto rizikos veiksnį plane buvo numatyti veiksmai, kurie padėtų

sumažinti rizikos veiksnio įtaką projektui (žiūr. 8.3 lentelę).

Prevencinės (profilaktinės) priemonės. Rizikos veiksniams, kurių galima būtų išvengti ar

sušvelninti jų įtaką projektui, valdyti yra specifiniai būdai, kaip, pvz., naujų užduočių įtraukimas į

darbų grafiką.



111

Tokiais atvejais turėtų būti atliekami projekto plane numatyti veiksmai ir vertinama, kaip

tie veiksmai padeda pašalinti arba sumažinti rizikos veiksnio įtaką projektui. Jei atliekami

veiksmai nesumažina rizikos, reikėtų peržiūrėti reakcijos į rizikos veiksnį būdą ir arba prisiimti

riziką, arba imtis naujo reakcijos būdo.

Peržiūrint veiksmus (reakcijos būdą), kurie neduoda laukiamų rezultatų, būtina įsitikinti

ar rizikos veiksnys nėra pakitęs dėl kokių nors aplinkybių. Jei pastebite, kad turite reikalą su

pakitusiu rizikos veiksniu, gali reikėti visai kitokio reakcijos į jį būdo.

Veiksmai nenumatytais atvejais. Kai susiduriama su projekto plane nenumatytais atvejais,

naudojamas kitoks reakcijos į rizikos veiksnius būdas. Tokiais atvejais rizika yra valdoma kitaip.

Rizikos planas nenumatytiems atvejams pradedamas naudoti tik tada, kai iš tikro atsitinka

nepageidaujamas įvykis (pasikeitė įstatymai, įvyko streikas, kt.). Tuomet tenka aiškintis ir valdyti

rizikos priežastis (risk trigger), signalizuojančias apie artėjantį pavojų projektui.

Projekto eigoje reikia būti pasirengusiems bet kokiems pavojaus signalams apie rizikos

veiksnių pasikeitimus. Reakcijos į riziką, atsirandančią dėl nenumatytų priežasčių, veiksmų plano

sudarymo sėkmė slypi žinojime (neignoravime), kad gali atsirasti ir nauji rizikos veiksniai.

13.4.2. Naujų rizikos veiksnių įvardijimas

Reakcijos į riziką planas plėtojamas visą projekto laiką. Kai kurie planavimo metu

įvardinti rizikos veiksniai nepasireiškia (neįvyksta), tačiau gali atsirasti naujų, kurių nėra

pradiniame projekto plane. Kai projektas baigiamas, ateičiai turėtume gerai įsidėmėti kiekvieną

naujai atsiradusį neplanuotą rizikos veiksnį.

Nauji rizikos veiksniai gali turėti įtakos sąraše išdėstytų rizikos veiksnių prioritetams.

Naujų rizikos veiksnių pasirodymo tikimybė ir įtakos projektui lygis gali būti aukštesnis už

anksčiau įvardintus rizikos veiksnius. Projekto plano pakeitimai taip gali pareikalauti keisti

rizikos veiksnių prioritetus. Pvz., projekto eigoje darbų grafike gali tekti keisti kritinį darbų kelią,

kas savo ruožtu gali pareikalauti neatidėliotino kai kurių rizikos veiksnių prioriteto keitimo.

Kai daromi projekto plane numatytų reakcijos į rizikos veiksnius veiksmų pakeitimai arba

įvardijami nauji rizikos veiksniai, gali iškilti būtinumas keisti ir visą projekto planą. Reakcijos į

riziką veiksmai gali iššaukti projekto apimties, darbų grafiko ir biudžeto keitimą. Tokiu atveju

reakcijos į riziką keitimo procedūra turi būti panaši, kaip ir darant kitokius projekto pakeitimus.

Problemų registravimo žurnalas yra kitas svarbus dokumentas, kuris projekto bėgyje turi

būti tvarkomas ir atnaujinamas.

13.4.3. Problemų sprendimo valdymas

Problemų sprendimo eigos valdymas yra labai panašus į rizikos valdymą, nes taip pat turi

būti imamasi atitinkamų veiksmų. Nerūpestingas problemų sąrašo tvarkymas (iškilusių

problemų įtraukimas, atsakingo asmens nurodymas, atžymos apie išspręstas problemas, kt.) gali

atvesti prie naujų problemų atsiradimo kiekvieną savaitę arba kad problemos iš viso nebus

išspręstos.

Aptariant problemas projekto grupės susirinkimuose, reikėtų išsiaiškinti, kaip sekasi už

problemų sprendimą atsakingiems asmenims. Kartais problemos lieka neišspręstos savaites ar



112

net mėnesius. Todėl sąraše visada reikėtų registruoti problemos sprendimo planą ir numatomą

išsprendimo datą. Jei problema sprendžiama lėtai, galbūt už ją atsakingam asmeniui reikia

pagalbos arba jis nesupranta problemos. Dėl to gali tekti netgi kreiptis į sponsorių, kad padėtų

įveikti kliūtis.

Visas problemas reikėtų išspręsti kaip galima greičiau, tačiau kai kuriais atvejais

problemos gali būti sprendžiamos jų prioriteto tvarka. Problemų prioritetui nustatyti gali būti

naudojami tie patys būdai, kurie buvo naudoti planuojant riziką. Jeigu keletui problemų spęsti

reikalingi tie patys žmonės, peržiūrėkime problemų poveikio projektui dydį, problemų

prioritetus ir tik tada nutarkime, kurios imsimės visų pirma.

13.4.4. Projektas pavojuje

Kartais projekto grupės narių reakcijos į riziką veiksmai ar problemų sprendimo veiksmai

gali vesti link projekto sužlugdymo. Jeigu tie veiksmai neduoda norimų rezultatų arba atsiranda

nauji, sunkiai suvaldomi rizikos veiksniai, reikia kreiptis į sponsorių ir tartis, ką gi reikėtų daryti.

Kreipimasis į sponsorių dėl pagalbos projekto problemoms spręsti yra delikatus reikalas.

Projektų vadovai nenori užsitarnauti panikuotojo reputacijos, kai iškyla problema ir nesiseka

išspręsti jos griežtais sprendimais. Tačiau, jei padarėte viską, ką jūs galite, ir matote, kad reikalai

negerėja, nedelskite ir kreipkitės į sponsorių. Laiku neinformavus apie projekto sunkią padėtį,

sponsorius taip pat gali nebeturėti galimybių pagelbėti.

Prieš einant pas sponsorių būtina pasirengti aiškiai išdėstyti problemą ar riziką, veiksmus,

kurių ėmėtės, ir jeigu toliau padėtis nesikeis, kokią įtaką tai turės projektui. Pokalbis su

sponsoriumi turi būti trumpas, aukšto lygio. Jam nėra būtina žinoti visų smulkių žingsnių.

Reikėtų prašyti, kad sponsorius imtųsi specifinių veiksmų. Jeigu turite problemų su jūsų

organizacijos kažkuriuo kitu departamentu ir reikalingas atitinkamo lygio sprendimas,

informuokite sponsorių apie tai ir ko jums reikia, kad projektas grįžtų į normalias vėžes.

Kartais pakeisti situacijos būna neįmanoma. Galbūt dėl naujų teisės aktų jūsų projekto

pagrindinės prielaidos tapo negaliojančios arba nauja organizacijos vadovybė pasirinko

strategiją, kuri nebepateisina jūsų projekto. Tokiais atvejais reikėtų rekomenduoti sponsoriui

nutraukti projektą.

13.5. Projekto eigos kontrolė

Projekto eigos kontrolė padeda atskleisti daug svarbios informacijos, kuri rūpi ir

akcininkams. Darbų ataskaitose atspindima esama projekto padėtis ir prognozės dėl projekto

apimties, darbų grafiko, biudžeto ir kokybės. Rizika ir projektui pavojų keliančios problemos turi

būti žinomos ir akcininkams.

Darbų eigos rezultatai turi būti platinami akcininkams laikantis planavimo etape parengto

komunikacijų plano. Ataskaitose turi būti informacija apie nuveiktus darbus iki tam tikro laiko ir

kas dar liko padaryti.

Informacijai apie projekto eigą rinkti yra nemažai analitinių priemonių.



113

13.5.1. Darbų ataskaitos

Darbų ataskaitose turėtų būti daugiau specifinė informacija, o ne vien tik konstatavimas,

ar nėra nukrypimų nuo planuotos projekto apimties, darbų grafiko ar biudžeto panaudojimo.

Nukrypimai gali turėti labai įvairų poveikį visam projektui. Todėl dalis ataskaitos turi būti

skiriama problemų analizei ir jų įtakos projektui įvertinimui.

Nukrypimų nuo projekto plano poveikio dydžiui įvertinti naudojami šie būdai:

nukrypimų analizė, tendencijų analizė, viso projekto kainos tikslinimas, atliktų darbų kainos (EV

- earned value) vertinimas, nuokrypiai, indeksai (santykiai).

Nukrypimų analizė – tai einamųjų projekto rezultatų palyginimas su projekto plane

numatytais rezultatais. Ši analizė dažniausiai naudojama projekto darbų grafikui ir biudžetui.

Projektų valdymo tikslams skirta programinė įranga (pvz., Microsoft Project) dažniausiai

turi funkciją projekto eigos nukrypimams nuo suplanuoto darbų grafiko sekti. Ji įgalina

apskaičiuoti naują galutinį projekto įvykdymo terminą, jei vėluojama atlikti kažkuriuos darbus.

Projekto biudžeto ataskaitose palyginamos atitinkamo laikotarpio kontroliniame taške

numatytos lėšos ir iš tikro padarytos išlaidos.

Kiekybiškai nukrypimo dydis ataskaitoje gali būti nurodomas procentais, pvz., atlikta

50% numatytų darbų ir išleista 35% numatytų lėšų. Negerai, kai darbai padaromi laiku, bet

išleidžiama daugiau lėšų, nei buvo numatyta. Tačiau yra visiškai blogai, kai darbai nepadaromi

laiku ir išleidžiama daugiau lėšų nei numatyta.

Tendencijų analizė. Jau nuveikti darbai gali įnešti aiškumo, ko galima tikėtis atliekant

būsimus darbus. Tendencijų analizė yra pagrįsta matematiniais skaičiavimais ir naudojama

prognozuoti, ar darbų atlikimas gerės ar blogės.

Viso projekto kainos tikslinimas. Kadangi projekto eigoje rengiamos biudžeto ataskaitos, iš

jūsų gali būti prašoma pateikti prognozuojamą viso projekto kainą. Atlikus dalį projekto darbų ir

įgijus patirties, atsiranda galimybė tiksliau įvertinti viso projekto kainą, nei projekto pradžioje.

Viso projekto patikslintos kainos įvertis duotu laiku (EAC – estimate at completion) gaunamas

remiantis jau atliktų ir likusių darbų informacija. Kad geriau suprastume tokį įvertį, pravartu

žinoti šias sąvokas:

- viso projekto kainos įvertis projekto pradžioje (BAC – budget at completion);

- tikrosios (faktinės) projekto išlaidos iki duoto laiko (AC – actual cost);

- nuo duoto laiko iki projekto pabaigos likusių darbų prognozuojama kaina (ETC –

estimate to complete);

- viso projekto patikslintos kainos įvertis duotu laiku (EAC – estimate at completion)

EAC = AC + ETC .

Skirtumas tarp EAC ir BAC yra duotu laiku patikslintos projekto kainos nukrypimas nuo

projekto pradžioje įvertintos projekto kainos (VAC – variance at completion): VAC = EAC - BAC.

Atliktų darbų kainos vertinimas. Dideliuose projektuose tenka skirti dėmesį visoms

finansinėms detalėms. Tai įvairūs indeksai (santykiai), kuriuos nesunku apskaičiuoti naudojant

skaičiuokles arba projektų valdymo programinę įrangą. Kad suprastume, kokie duomenys

naudojami tiems indeksams (santykiams) apskaičiuoti, pateikiame labiausiai reikalingas

sąvokas:



114

- tikrosios (faktinės) projekto išlaidos iki duoto laiko (AC – actual cost);

- iki duoto laiko atliktų darbų vertė (EV – earned value);

- projekto biudžete duotam laikotarpiui skirta suma (PV – planned value).

Šias sąvokas pakomentuokime pavyzdžiu. Planuojant darbų grafiką buvo nustatyta, kad

kažkokiems darbams atlikti reikės 4 savaičių ir darbai bus baigti kovo 31 d., o suplanuotame

biudžete to laikotarpio darbams numatyta 50000 Lt (tai PV). Už kovo mėnesį gauta biudžeto

ataskaita rodo, kad buvo išleista 48000 Lt (tai AC). Galima pagalvoti, kad reikalai klostosi gerai,

sutaupyta truputis pinigų. Bet pažiūrėję į darbų grafiką matome, kad kovo 31 d. atlikti ne visi

numatyti darbai, o atliktų darbų vertė tik 42000 Lt (tai EV). Atliktiems darbams apmokėti išleista

daugiau pinigų, nei reikėjo (EV-AC<0). Reiškia, yra problema.

Nuokrypiai. Nuokrypiai rodo skirtumą tarp suplanuoto projekto biudžeto ir tikrųjų išlaidų

duotu laiku. Teigiamas nuokrypis rodo, kad jūs sutaupėte pinigų arba laiko ir galite juos

panaudoti kitiems projekto darbams. Neigiamas nuokrypis rodo, kad jūs viršijote biudžetą arba

atsiliekate nuo darbų grafiko. Tai reikalauja jūsų korekcinių veiksmų.

Išlaidų nuokrypis (CV – cost variance) yra iki duoto laiko atliktų darbų vertės (EV) ir

tikrųjų išlaidų (AC) skirtumas:

CV = EV – AC .

Darbų nuokrypis (SV – schedule variance) yra iki duoto laiko atliktų darbų vertės (EV) ir

darbų grafike suplanuotų darbų kainos (PV) skirtumas:

SV = EV – PV.

Neigiamos CV ir SV reikšmės rodo, kad yra problemų.

Indeksai (santykiai). Indeksai atspindi santykius tarp biudžeto komponentų. Jie yra

lengvai apskaičiuojami ir ypač naudingi. Jų reikšmė yra mažesnė arba didesnė už 1. Jei santykio

reikšmė yra didesnė už 1, tai projekto darbų vykdymas lenkia darbų grafiką arba projekto

biudžeto išlaidos panaudotos efektingai (biudžetas neviršytas). Jei santykis yra mažesnis už 1, tai

atsiliekama nuo darbų grafiko arba projekto biudžeto išlaidos panaudotos neefektingai (viršytos

biudžeto išlaidos).

Santykiai gali būti išreiškiami procentais, nes tai gali būti patogiau. Pvz., indekso reikšmė

0,94 atitinka 94%. Taip yra patogiau vykdyti atliktų darbų vertės analizę.

Išlaidų indeksas (CPI – cost performance index) atspindi projekto biudžeto išlaidų

panaudojimo efektyvumą. Jis apskaičiuojamas kaip iki duotos datos atliktų darbų kainos (EV) ir

tikrųjų išlaidų (AC) santykis:

CPI = EV / AC .

Jei CPI<1, tai projekto biudžeto išlaidos naudojamos neefektyviai (viršytos biudžeto išlaidos), jei

CPI>1, tai jūs išleidote pinigų mažiau, nei tikėjotės.

Darbų indeksas (SPI – schedule performance index) yra iki duotos datos atliktų darbų ir

darbų grafike suplanuotų darbų kainų santykis:

SPI = EV / PV .

Jei SPI<1, tai jūs atsiliekate nuo darbų grafiko (turite problemų), jei SPI>1, tai darbams jūs

sugaišote mažiau laiko, nei tikėjotės.



115

Darbų tęstinumo indeksas (TCPI – to-complete performance index) yra likusių darbų

kainos ir likusių biudžeto lėšų santykis išreikštas procentais [WL06].

TCPI = (likusių darbų kaina) / (likusios biudžeto lėšos) .

Čia, (likusių darbų kaina) = BAC – EV , (likusios biudžeto lėšos) = BAC – AC , BAC (budget at

completion) yra viso projekto kainos įvertis projekto pradžioje.

TCPI duotu laiku atspindi likusių projekto darbų finansinį suvaržymą. Jei TCPI>1, tai

likusios lėšos likusiems darbams atlikti turi būti naudojamos labai taupiai.

13.5.2. Akcininkų valdymas

Projekto vadovui kartais tenka priimti sunkius sprendimus dėl tolesnės projekto eigos.

Projekto vadovas yra atsakingas ne tik už akcininkų informavimą apie projekto eigos

nukrypimus, bet ir už nukrypimų poveikio projektui įvertinimą ir rekomendacijų, ką reikėtų

daryti, parengimą. Gali tekti daryti kompromisus, norint rezultatyviai užbaigti projektą. Kai

kuriais atvejais nelieka prasmės tęsti projektą, ir dėl jo nutraukimo gali reikėti oficialaus

akcininkų sutikimo.

Pranešimai apie projekto nukrypimus. Analizuojant projekto eigą būtina informuoti

akcininkus apie bet kokius nukrypimus, kurie gali turėti įtakos projekto rezultatams. Projekto

stoviui pristatyti jūs galite rengti papildomas diagramas ar lenteles, kas padėtų aiškiau pristatyti

jūsų analizės rezultatus. Kai kurios diagramos ir ataskaitos gali būti parengtos naudojant

projektų valdymui skirtą programinę įrangą, pvz., Microsoft Project.

Kompromisų valdymas. Prisiminkime, kad visi projektai turi laiko, kainos, kokybės ir

apimties apribojimus. Jei kuris nors iš jų yra keičiamas projekto eigoje, tai, mažiausiai, tenka

keisti dar vieną iš likusių trijų. Keitimus tenka daryti beveik visuose projektuose.

Jei keičiamas bent vienas projekto apribojimas, projekto vadovas turi ieškoti kompromiso

su akcininkais. Pažiūrėkime, kaip vienos srities keitimai įtakoja kitas sritis.

Kompromisas dėl projekto apimties. Prašymai keisti projekto apimtį yra vieni iš

lengvesnių, nes šių keitimų valdymo procesas yra susijęs su keitimo poveikio projektui analize ir

reikalauja akcininkų patvirtinimo.

Jei patvirtintam projektui keliami papildomi reikalavimai, turėtų būti nurodomos

reikiamos papildomos lėšos ir laikas tiems reikalavimams įgyvendinti. Tam gali reikėti

papildomų išteklių ar didesnės projekto grupės. Akcininkai dažnai reiškia norą, kad tie papildomi

reikalavimai būtų įgyvendinti per anksčiau suplanuotą projekto laiką ir už buvusią projekto

kainą. Todėl jiems reikėtų paaiškinti, kad daugiau darbų padaryti per tokį pat laiką ir už tokią pat

kainą galima tik darbų kokybės sąskaita, trumpinant arba iš viso atsisakant darbų rezultatų

testavimo.

Iškilus būtinybei keisti projekto apimtį, reikėtų ieškoti akcininkams priimtinų alternatyvių

sprendimų. Jei papildomi reikalavimai negali būti įgyvendinti nekeičiant darbų grafiko, tai gal

juos galima būtų įgyvendinti ateityje, tobulinant (upgrade) projekte sukurtą produktą. Galbūt yra

ir kiti keliai papildomiems reikalavimams įgyvendinti, todėl visada reikėtų išklausinėti

akcininkus, kad išsiaiškintume, ko jie siekia prašydami keisti projekto apimtį.



116

Kompromisas dėl darbų grafiko. Darbų atlikimo vėlavimo priežastys gali būti įvairios

nelaimės, įrangos gedimai, padarytos klaidos. Todėl ypač svarbu gerai žinoti darbų grafiko svarbą

jūsų projektui. Tarkime, jūs esate nustatytos apimties ir biudžeto 10 mėnesių trukmės projekto

vadovas ir prašote akcininkų atidėti projekto baigimo terminą 3 savaitėmis. Iš pirmo žvilgsnio tai

gali atrodyti kaip pagrįstas prašymas, nes visi žino, kad projekto planavimo etape nustatoma tik

apytikrė projekto trukmė. Daugeliu atveju logiškiau būtų rekomenduoti atidėti baigimo terminą,

nei didinti projekto sužlugdymo riziką dėl skubėjimo. Tačiau jeigu buvo nustatytas privalomas

projekto užbaigimo terminas, tokia rekomendacija gali sumažinti pasitikėjimą jūsų organizacija,

gali užtraukti baudas arba teisines sankcijas. Todėl visada, prieš rekomenduojant atidėti projekto

pabaigos terminą, reikia būt pasvėrus, kas yra geriau.

Jeigu jūs atsiliekate nuo darbų grafiko ir nematote perspektyvaus būdo, kaip galėtumėte

išbristi iš šios bėdos turimais ištekliais, informuokite akcininkus apie susidariusią padėtį. Laikant,

kad projekto užbaigimas laiku turi aukščiausią prioritetą, jūs turite įvertinti, kaip galima būtų tą

padaryti. Jei rūpestį kelia nepakankami ištekliai, paaiškinkite tai akcininkams ir nurodykite

reikiamas papildomas lėšas ištekliams padidinti. Jei išteklių didinimas nepadeda laiku baigti

projekto arba nėra garantijų dėl lėšų padidinimo, reikia būti pasirengusiems aptarti, kokių

projekte kuriamo produkto funkcijų galima būtų atsisakyti.

Kartais gali būti neįmanoma laiku baigti projektą. Jeigu pradiniai reikalavimai nebuvo

aiškūs arba kažkas juose buvo praleista, išsiaiškinus tai gali pasirodyti, kad projektas yra daug

sudėtingesnis, nei buvo tikėtasi. Darbai gali būti pagreitinti sumažinus kuriamo produkto

funkcionalumą, jei dėl to nereikia perdaryti anksčiau atliktų darbų. Jeigu ir tai nepadeda išvengti

darbų grafiko pažeidimo, o projektas vis dar išlieka gyvybingas, jūs turite būti tikri, kad

atidėtame projekto užbaigimo termine yra įvertinti visi daryti projekto plano pakeitimai.

Kompromisas dėl išlaidų. Išlaidų viršijimo priežastis gali būti netiksli sąmata, darbų

grafiko vėlavimai, projekto apimties nukrypimai, biudžeto kritinių straipsnių nepaisymas.

Kadangi išlaidos daromos įvairiose srityse, būtina stebėti, kad būtų mokama tik už atliktus

darbus. Jeigu pagal biudžeto planą kažkuriame projekto etape išleidžiate daugiau lėšų nei buvo

atlikta darbų, galite turėti rimtų problemų.

Jeigu reikalaujama griežtai laikytis nustatyto biudžeto, o jūs matote, kad išlaidų viršijimas

yra neišvengiamas, atsiradusiam skirtumui panaikinti tenka siaurinti projektą. Geriausias būdas

padaryti tai yra susitikti su sponsoriumi ir akcininkais ir prašyti leidimo sumažinti projekto

apimtį tiek, kad nebūtų viršytas biudžetas.

Sponsorius ar akcininkai gali reikalauti išlaikyti senąją projekto apimtį, o kad biudžetas

nebūtų viršytas, išlaidas taupyti trumpinant ar atsisakant testavimo darbų, t. y. kuriamo

produkto kokybės sąskaita. Galimi produkto defektai ateityje bus šalinami atliekant ir platinant

patobulinimus (upgrade).

Kompromisų darymas (bendrų sutarimų ieškojimas) ne visada padeda. Jei nerandama

protingos alternatyvos, reikėtų rekomenduoti nutraukti projektą.

Projekto nutraukimas. Kai kuriais atvejais projekto nutraukimas gali būti geriausias

sprendimas, kai nukrypstama nuo plano. Esant nepakankamam finansavimui ar trūkstant

darbuotojų, geriau nutraukti projektą, nei tęsti jį ir patirti fiasko. Jei projektas buvo patvirtintas



117

neturint tinkamai parengto plano, gali susidaryti situacijos, kurioms išvengti nėra tinkamų

sprendimų. Taip gali atsitikti dėl dažno reikalavimų keitimo arba kai akcininkų lūkesčiai nebūna

suderinti su projekto planu. Tokiais atvejais reikėtų klausti sponsoriaus ir akcininkų, ar yra

prasmė tęsti projektą. Galbūt pasikeitė verslo strategija, projekte reikia keisti daug ką ir todėl

derėtų jį nutraukti.

Rekomendacija nutraukti projektą nereiškia, kad projekto vadovas yra netikęs. Tai reiškia

raginimą sponsoriui ir akcininkams peržiūrėti pradinius projekto tikslus ir nuspręsti, ar šis

projektas vis dar turi prasmę.



118

14. PROJEKTO UŽBAIGIMAS

Projekto užbaigimas – tai formalus viso projekto arba projekto etapų užbaigimas, sukurto

produkto perdavimas naudotojams arba projekto nutraukimas. Pagrindiniai užbaigimo etapo

valdymo darbai yra šie: viso projekto administracinis užbaigimas ir sandorių užbaigimas.

Projekto administracinis užbaigimas

Tai viso projekto arba projekto etapų darbų užbaigimas. Jo metu analizuojami duomenys

ir formuojami rezultatai parodyti 14.1 lentelėje.

14.1 lentelė. Projekto administracinio užbaigimo darbų duomenys ir rezultatai

Įeities duomenys Rezultatai

1. Projekto planas.

2. Sandorių dokumentai.

3. Įmonės aplinkos duomenys.

4. Įmonės organizaciniai dokumentai.

5. Informacija apie atliktus darbus.

6. Projekto rezultatai.

1. Atliktos administracinės baigimo

procedūros.

2. Atliktos sandorių baigimo procedūros.

3. Galutinis projekto produktas.

4. Atnaujinti įstaigos organizaciniai

dokumentai.

Sandorių užbaigimas

Tai kiekvieno sudaryto sandorio užbaigimas ir atsiskaitymas su tiekėju. Sandorių

užbaigimo duomenys ir rezultatai parodyti 14.2 lentelėje.

14.2 lentelė. Sandorių užbaigimo darbų duomenys ir rezultatai

Įeities duomenys Rezultatai

1. Įsigijimų (pirkimų) planas.

2. Sandorių valdymo planas.

3. Sandorių dokumentai.

4. Sandorių baigimo procedūra.

1. Užbaigti sandoriai.

2. Atnaujinti įstaigos organizaciniai

dokumentai.

Projekto užbaigimas taip lakoniškai yra aprašytas [PMBOK] šaltinyje. Apibūdinkime

projekto baigiamuosius darbus kiek smulkiau [HC04].

14.1. Projektų nutraukimo priežastys

Projekto užbaigimo etapas dažniausiai apima formalų projekto rezultatų priėmimą. Tačiau

ne visi projektai būna sėkmingi. Jų baigimo (nutraukimo) priežastys gali būti įvairios:

- rezultatų stoka. Projektas gali būti nutrauktas ar atidėtas neribotam laikui nelaukiant jo

pabaigos. Projektą, kuris niekur neveda, jo vykdytojams gali būti sunku nutraukti, bet

organizacijos vadovybė turi imtis tokio žingsnio. Projektai, kurie atidedami dėl technologijų

nebuvimo ar finansavimo trūkumo, taip pat priklauso niekur nevedančiųjų kategorijai;

- nepatvirtintas projekto planas. Jei planas nėra pagrįstas, natūralu, kad organizacijos

vadovybė tokius projektus atmeta;



119

- išteklių stoka. Tai gali būti lėšų, aparatūros, žmonių ar kitokių dalykų trūkumas. Tokia

situacija gali susidaryti dėl netinkamų įverčių planavimo etape arba jūsų projektui skirti ištekliai

perkeliami kitam, aukštesnį prioritetą turinčiam projektui. Nežiūrint išteklių nepakankamumo

priežasties, projektą tenka nutraukti.

14.2. Sandorių užbaigimas

Kai tiekėjas baigia kurį nors jūsų projekto darbų etapą, reikia užbaigti sandorį su juo.

Sandorio užbaigimas – tai sandorio sąlygų įvykdymas ir gautų rezultatų priėmimo

apiforminimas. Netgi jei sandorius tvarko organizacijos pirkimų departamentas, projekto

vadovas turi pateikti jam informaciją apie tiekėjo darbo rezultatų priėmimą. Tam turi būti

patikrinta gautų rezultatų kokybė. Reikalavimas tiekėjams pašalinti pastebėtus trūkumus

neturėtų jų stebinti.

Pirkimų departamentas turi išduoti tiekėjui oficialų raštą apie jo atliktų darbų priėmimą.

Užbaigus sandorį jūs, kaip projekto vadovas jau nebetenkate išteklių praleistiems darbams atlikti

ar nepastebėtiems defektams ištaisyti. Todėl tiekėjo pristatomų rezultatų kokybę reikia

kruopščiai patikrinti ir tik po to oficialiai su juo atsiskaityti.

Visų užbaigtų sandorių dokumentų kopijas reikėtų dėti į archyvą ir saugoti ateičiai.

Ne visuose projektuose sudaromi sandoriai, todėl su jų užbaigimu susiduria ne visų

projektų vadovai. Tačiau kiekvienam projektų vadovui tenka susidurti su administracinėmis viso

projekto užbaigimo procedūromis.

14.3. Administraciniai projekto baigiamieji darbai

Kai tik projektas baigiamas, kiekvienas projekto vadovas kaip galima greičiau dairosi

naujo projekto. Tačiau užbaigtam projektui reikia atlikti dar keletą svarbių darbų. Tai atlikto

projekto dokumentų surinkimas ir apibendrinimas (sutvarkymas), parašų surinkimas,

suinteresuotų šalių informavimas apie projekto baigtį.

Kai kurie administraciniai darbai yra nuobodūs, tačiau jų rezultatai, įgyta patirtis gali

praversti ateityje vykdant naujus projektus.

Panagrinėkime keletą administracinių darbų: projektų archyvo tvarkymas, formalus

projekto rezultatų priėmimas, visapusiška projekto peržiūra (išmoktos pamokos), projekto

rezultatų perdavimas naudotojams, projekto grupės narių atleidimas.

14.3.1. Projektų archyvo tvarkymas

Projekto eigoje jo priežiūrai sukaupiama daug dokumentų. Jų nauda yra ta, kad jie gali

praversti ateityje vykdant naujus projektus. Įvykdyto projekto planavimo dokumentai ir jų

šablonai gali suteikti informacijos ir būti reikalingi vertinant naujo panašaus projekto kainą,

darbų grafiką.

Projektų archyvo kūrimo keliai yra įvairūs. Kai kuriose organizacijose gali būti atskiros

patalpos, kuriose, kaip mažose bibliotekose, laikomi projektų dokumentai, arba gali būti

centralizuoti projektų archyvai. Prieš atiduodant savo projekto dokumentus į biblioteką ar

archyvą, reikia pasidomėti, kaip dokumentai turėtų būti sutvarkyti.



120

Natūralu, kad plinta elektroniniai archyvai. Organizacijose gali būti serveriai, kur saugomi

projektų dokumentai.

14.3.2. Formalus projekto rezultatų priėmimas

Jei projekte, einant nuo vieno etapo prie kito, drauge su akcininkais buvo kruopščiai

atliekamos gautų rezultatų peržiūros, tai galutinių projekto rezultatų formalus priėmimas

neturėtų kelti didelių rūpesčių.

Galutinių projekto rezultatų peržiūros tikslas yra gauti akcininkų pritarimą ir parašus bei

oficialiai paskelbti projekto pabaigą.

Priklausomai nuo jūsų organizacijoje esančių taisyklių, gali būti projekto užbaigimo

dokumento specialus šablonas parašams surinkti. Projekto vadovas turi išsiaiškinti, kieno parašų

reikės. Vienų projektų baigimo dokumentuose gali reikėti sponsoriaus ir akcininkų parašų, o kitų

– kiekvienos projekte dalyvavusios grupės dalyvio parašo.

Formalaus priėmimo metu būtina išsiaiškinti visus neatsakytus klausimus ir problemas. Iš

tokios peržiūros visi dalyviai turi skirstytis įsitikinę, kad projekto rezultatai atitinka keltus

reikalavimus.

Nors projekto eigoje akcininkai ir buvo informuojami dėl projekto plano keitimo, kai kurie

dalyviai gali neprisiminti visų keitimų. Todėl formalaus priėmimo metu būtina išsiaiškinti, ar visi

vienodai supranta, ko norėta pasiekti projektu. Tai ypač svarbu, jei buvo atsisakyta kai kurių

reikalavimų ar funkcijų, numatytų pradiniame projekto plane.

Kartais akcininkai, projektui einant į pabaigą, prašo papildyti jį įvairiais dalykais. Jei

projekto pabaiga būtų atidėliojama, kol nebus padaryta viskas, ko jie norėtų, dauguma projektų

niekada nesibaigtų. Todėl yra labai svarbu, kad projekto eigoje visiems prašomiems keitimams

būtų gautas patvirtinimas. Geriausia gynyba prieš prašymus papildyti projektą paskutinę minutę

yra akcentavimas to, ko akcininkai pageidavo ir ką patvirtino projekto plane.

Akcininkai taip pat nori žinoti, kuri grupė yra atsakinga už sukurtos sistemos atidavimą į

eksploataciją. Apie tai rašoma truputį vėliau (žiūr. Projekto rezultatų perdavimas naudotojams).

Vienas iš paskutinių projekto vadovo ir grupės narių baigiamųjų darbų yra visapusiška

projekto peržiūra ir gautų pamokų įsidėmėjimas.

14.3.3. Visapusiška projekto peržiūra (gautos pamokos)

Projekto pabaigoje visapusišką projekto peržiūrą atlikti reikėtų tam, kad įvertintume, kas

projekte buvo gerai ir kas sekėsi prasčiau. Šio proceso metu įvertinamas kiekvienas projekto

etapas. Šios rūšies peržiūros suteikia galimybę gerinti būsimų projektų valdymą (prisiminkime

CMM modelio brandos lygius). Užbaigto projekto vertinimas turėtų padėti atskleisti dalykus,

kurių mes išmokome, kokias pamokas gavome. Galbūt tai padės geriau valdyti kitus projektus.

Jeigu jūs buvote keletą organizacijos funkcinių padalinių apimančio (cross-functional)

projekto vadovas, peržiūroje susidursite su techniniais ir netechniniais projekto komponentais.

Keletui įvairių funkcinių padalinių skirtus projektus valdyti yra sudėtinga. Jus galbūt labiau

domina, kaip projekte buvo kuriama ir testuojama sistema, tačiau informacija apie rinkodarą ir

pardavimus taip pat yra svarbi.



121

Popierinio ar elektroninio pavidalo projekto dokumentai yra visapusiškos peržiūros

duomenys. Apibendrinus juos, projektas įvertinamas ir parengiama ataskaita.

Visapusiškos peržiūros metu nagrinėjamos:

- planavimo pamokos;

- organizacinės pamokos;

- projekto vykdymo pamokos.

- projekto vadovavimo (directing) pamokos;

- projekto kontrolės (controlling) pamokos;

- biudžeto tvarkymo pamokos;

- projekto įvertinimas (teigiamos ir neigiamos pusės).

14.3.4. Projekto rezultatų perdavimas naudotojams

Pasibaigus projektui, sukurtą sistemą dažniausiai eksploatuoja ir prižiūri kiti žmonės.

Todėl projekto grupė turi perduoti ją būsimiems naudotojams. Tai nėra paprastas uždavinys.

Dauguma sistemų turi vadinamąsias pagalbos (help desk) funkcijas. Todėl projekto darbų

grafike turi būti numatyti darbai mokymo medžiagai parengti ir pagalbos grupės nariams

apmokyti. Pagalbos grupė turi būti jau pasirengusi teikti paslaugas, kai sukurta sistema įdiegiama

pas naudotojus.

Sukurtos sistemos naudotojams taip pat turi būti parengti sistemos priežiūros

dokumentai ir įrankiai. Jų atnaujinimas jau yra priežiūros grupės narių atsakomybė.

Sistemos priežiūra – tai jos darbingumo išlaikymas visą jos naudojimo laikotarpį. Poreikiai

modifikuoti sistemą yra registruojami ir sekami, nustatoma siūlomų pakeitimų įtaka, keičiamos

programos ir kiti sistemos elementai (pvz., dokumentai), atliekamas testavimas, išleidžiamos

naujos sistemos versijos. Taip pat naudotojai yra mokomi ir jiems teikiama kasdieninė pagalba.

Manoma, kad sistemų priežiūra yra platesnė veiklos sritis nei projektavimas.

Prižiūrėtojai gali pasimokyti iš projekto grupės. Jų kontaktai turėtų užsimegzti kiek galima

anksčiau, ir tai gali sumažinti priežiūrai prireiksiančių pastangų lygį. Kai kuriais atvejais projekto

grupė neturėtų būti verčiama vykdyti užduočių, kurios sukeltų papildomus rūpesčius sistemos

prižiūrėtojams. Sistemos priežiūrai turi būti sukurti atitinkami produktai, programos ar

dokumentai, ir visa tai taip pat turi būti plėtojama ir prižiūrima sistemos gyvavimo kelyje.

14.3.5. Projekto grupės narių atleidimas

Dar projekto planavimo etape turi būti parengtas projekto grupės valdymo planas. Jame numatomos darbuotojų atleidimo procedūros pasibaigus projektui. Bent mėnesį iki projekto pabaigos reikėtų pradėti pokalbius su jūsų organizacijos funkcinių padalinių vadovais ir informuoti juos apie iš tų padalinių projektui vykdyti paimtų darbuotojų tolesnį likimą: ar jie bus traukiami į naują projektą, ar bus gražinami į funkcinį padalinį. Projekto grupės nariai gali būti sunerimę dėl savo ateities, ypač jei jie atleidžiami skirtingu projekto vykdymo metu. Tokiais atvejais reikėtų paaiškinti, kad užbaigus projekto darbus, dėl kurių jie buvo įtraukti į projekto grupę, jie bus atleidžiami. Kadangi jūs turite laikytis darbo sutarties terminų ir žmoniškųjų išteklių taisyklių, suteikite projekto grupės nariams kiek galima daugiau informacijos apie galimą atleidimo datą.



122

15. LANKSTIEJI PROJEKTŲ VYKDYMO METODAI

Programų sistemų kūrimo lankstųjį metodą (agile metodą) pasiūlė „Agile Alliance“

organizacija. Jis naudotinas tais atvejais, kai programų sistemų kūrimo projektai yra sunkiai

valdomi, dažnai keičiasi reikalavimai.

Lanksčiuoju metodu, sudėtingus (ilgalaikius) projektus skaidant į paprastesnius

(trumpesnės trukmės) keleto žmonių dydžio grupės atliekamus projektus, siekiama sumažinti

sudėtingo projekto įvykdymo riziką. Didelėse grupėse sudėtingų programų kūrimas trunka ilgai,

atsiranda komunikavimo problemų. Tipiška programų kūrimo trukmė yra 2-3 savaitės.

Kiekvieno tokios trukmės laikotarpio gale projekto prioritetų peržiūrėjimas leidžia greičiau

prisitaikyti prie kintančių reikalavimų, geriau valdyti rizikos veiksnius.

Pagrindinis lanksčiojo metodo skirtumas nuo tradicinių (krioklio, spiralės) modelių yra

orientacija į principus, o ne į procesą. Visa tai yra išdėstyta vadinamajame Agile manifeste

[BECK01].

Lanksčiojo metodo idėjos:

1) asmenys (projekto grupės nariai, kiti akcininkai) ir jų tarpusavio santykiai yra svarbiau

už procesus ir instrumentus;

2) veikianti programų sistema yra svarbiau už sistemos dokumentų išsamumą;

3) projekto grupės bendradarbiavimas su užsakovu yra svarbiau už įsipareigojimus

sandoryje;

4) reaguoti į siūlymus daryti keitimus yra svarbiau nei laikytis plano.

Lanksčiojo metodo principai:

1) klientų poreikių tenkinimas kiek galima greičiau ir nepertraukiamai teikiant naudingą

įrangą;

2) teigiamas požiūris netgi į projekto pabaigoje siūlomus keitimus. Tai gali padidinti

kuriamo produkto konkurentiškumą;

3) pirmalaikis sukurtos įrangos pristatymas geriau nei darbų grafiko trumpinimas;

4) glaudus užsakovo ir projekto grupės bendradarbiavimas viso projekto metu;

5) projekto grupės narių motyvacija. Jiems turi būti sudarytos geros darbo sąlygos,

teikiama parama ir pasitikima jais;

6) asmeniniai pokalbiai yra efektingiausias informacijos perdavimo būdas projekto

grupės narių ir akcininkų tarpe;

7) sukurta ir veikianti programa yra geriausias darbų judėjimo į priekį rodiklis;

8) lanksčiojo metodo (agile) procesai skatina nuolatinį kūrybingumą. Sponsoriui, projekto

grupei, kitiems akcininkams visada turi būti kažkiek neaiškumų;

9) nuolatinis dėmesys techniniam meistriškumui ir geras projektas (struktūra, design)

didina lankstumą;

10) paprastumas, t. y. gebėjimas nedaryti bereikalingų darbų yra labai svarbu;

11) geriausias sistemų struktūras, reikalavimus ir projektus (design) parengia darnios

(self-organizing) grupės;



123

12) nuolatinės projekto grupės pastangos didinti savo efektyvumą ir prisiderinti prie

aplinkybių.

Plačiau apie lankstųjį metodą rašoma, pvz., šaltinyje [SS07].

15.1. Grumtynės (Scrum)

Grumtynės (scrum) yra vienas iš lanksčiųjų metodų programų sistemoms kurti [KS04;

SS11]. Jis dar vadinamas hiperproduktyvumo įrankiu, nes kai kuriais atvejais žymiai pagerina

projekto grupių produktyvumą, anksčiau naudojusių tradicines (krioklio, spiralės)

metodologijas.

Grumtynių (scrum) metodui būdinga:

- dokumentas, kuriame prioritetų tvarka surašomos nepradėtos ir neužbaigtos projekto

užduotys (living backlog);

- trumpas laikotarpis (sprint) kelioms užduotims įvykdyti;

- trumpi kasdieniniai susirinkimai-grumtynės (scrum) nuveiktiems darbams ir

planuojamiems darbams pristatyti;

- planavimo posėdžiai, kurių metu sudaromas užduočių rinkinys kitam laikotarpiui;

- susirinkimas laikotarpio pabaigoje vykdytoms užduotims aptarti, kodėl joms vykdyti

laiko įverčiai skyrėsi nuo realiai sugaišto laiko;

- per laikotarpį gautų rezultatų demonstracija, kuriuos pristato užduočių vykdytojų

grupės.

Grumtynių (scrum) metode įvardinamas užduoties vykdytojų grupės koordinatorius, nors

jo teisės ir nesiskiria nuo kitų grupės narių. Koordinatoriaus pareiga yra šalinti kliūtis,

trukdančias atlikti užduotis.

Grumtynių (scrum) metodo privalumas - betarpiškai bendraujančios grupės. Metodo

trūkumas yra tas, kad grupėse turi būti pakankamai iniciatyvių narių (organizacinių sugebėjimų

turinčių narių).

15.2. Aukštasis programavimas (XP)

Aukštasis arba ekstremalusis programavimas (angl. eXtreme Programming - XP) – plačiai

paplitusi lanksčiojo metodo atmaina, kurios pradininkai yra Kent Beck, Ward Cunningham ir Ron

Jeffries [XP09].

Aukštojo programavimo (XP) pagrindiniai principai:

- bendravimas tarp užsakovo ir projekto vykdytojo. Tam į aukštojo programavimo

metodu dirbančią grupę įtraukiamas užsakovas, padedantis detalizuoti darbus ir sudėlioti juos

prioritetų tvarka, galintis iškart atsakyti į iškilusius klausimus;

- mokymasis. Tai įgalina sutrumpinti programavimo darbų laiką. Testuojama

programavimo metu;

- programos paprastumas. Kuo programa paprastesnė, tuo didesnė tikimybė, kad ji gerai

veiks. Prireikus, sudėtingos konstrukcijos keičiamos paprastesnėmis ir šalinami

besidubliuojantys elementai. Pernelyg komplikuotos programos perrašomos naujai.



124

- programų peržiūros. Aukštojo programavimo atstovai dirba poromis, prie vieno

monitoriaus ir klaviatūros, todėl visas programos kodas peržiūrimas rašymo metu;

- programos testavimas. Testai rengiami prieš pradedant rašyti programą. Užduotis

laikoma baigta tik tada, kai visi testai baigiami sėkmingai.

Sakoma, kad aukštasis programavimas labiausiai tinkamas mažose, iki 12 žmonių dydžio

grupėse. Aukštojo programavimo metodologijos naudotojai dažnai renkasi dinamiškas

programavimo kalbas, leidžiančias greičiau pasiekti reikiamų rezultatų.

Aukštojo programavimo metodo kritikai laikosi tos nuomonės, kad jo pagrindinis tikslas

yra suteikti programuotojui komfortiškas darbo sąlygas organizacijos vadovybės ir užsakovų

sąskaita. Vadovybė negauna aiškaus projekto plano, negali įvertinti projekto trukmės. Užsakovas

taip pat neturi fiksuoto projekto biudžeto ir sandorio garantijų, kad jam reikalinga programa bus

sukurta, bei turi skirti projektui vieną savo gerai išprususį darbuotoją.

Aukštasis programavimas kritikuojamas dar ir dėl šių aspektų:

- programavimo metu nesukuriami išsamūs dokumentai;

- programuotojai dirba poromis;

- prieš pradedant darbą nėra rengiamas rimtas planas.

Be čia paminėtų Grumtynių (scrum) ir Aukštojo programavimo (XP) lanksčiųjų metodų

yra ir kitų: Crystal Clear, Adaptive Software development, Feature Driven Development, Dynamic

Systems Development Method (DSDM).



125

Santrumpos

AĮ - aparatinė įranga;

ADM - darbų išdėstymo vaizdavimas rodykline diagrama (Arrow Diagramming Method);

AC - tikrosios (faktinės) projekto išlaidos iki duoto laiko (Actual Cost);

BAC - viso projekto kainos įvertis projekto pradžioje (Budget At Completion);

BCR - pelno ir kainos santykis (Benefit Cost Ratio);

BPR - verslo procesų reinžinerija (Business Process Re-engineering)

CBA - kainos-naudos analizės metodas (Cost Benefit Analysis);

CMM - organizacijos gebėjimų modelis (Capability Maturity Model);

COCOMO - konstruktyvusis kainos modelis (COnstructive COst MOdel);

COTS - gatava komercinė programinė įranga (Commercial Of The Shelf);

CPI - išlaidų indeksas (Cost Performance Index);

CPM - kritinio kelio metodas (Critical Path Method);

CV - išlaidų nuokrypis (Cost Variance);

DB - duomenų bazė;

DCF - diskontuotas pinigų srautas (Discounted Cash Flow);

DFD - duomenų sekų diagrama (Data Float Diagram);

EAC - viso projekto patikslintos kainos įvertis duotu laiku (Estimate At Completion);

ETC - nuo duoto laiko iki projekto pabaigos likusių darbų prognozuojama kaina

(Estimate To Complete);

EV - iki duoto laiko atliktų darbų vertė (Earned Value);

IRR - vidinės grąžos norma (Internal Rate of Return);

IT - informacinės technologijos;

NPV - grynoji dabartinė vertė (Net Present Value);

PDM - darbų išdėstymo vaizdavimas stačiakampių diagrama (Precedence Diagramming

Method);

PĮ - programinė įranga;

PMBOK - projektų valdymo žinynas (Project Management Body Of Knowledge);

PMI - projektų valdymo institutas (Project Management Institute);

PMO - projektų valdymo skyrius (Program Management Office);

PS - programų sistema;

PV - projekto biudžete duotam laikotarpiui skirta suma (Planned Value);

RFP - kvietimus teikti pasiūlymus (Request For Proposal);

ROI - atsipirkimo norma (Return On Investment);

SDLC - sistemų kūrimo ciklas (System Development Life Cycle);

SDS - sistemos projekto specifikacija (System Design Specification);

SOW - sandorių darbo užduotis (Statement Of Work);

SPI - darbų indeksas (Schedule Performance Index);

SV - darbų nuokrypis (Schedule Variance);

TCPI - darbų tęstinumo indeksas (To-Complete Performance Index);



126

TQM - bendrasis kokybės valdymas (Total Quality Management);

VAC - viso projekto kainos nuokrypis nuo kainos įverčio projekto pradžioje

(Variance At Completion);

WBS - projekto suskaidytų darbų lentelė (Work Breakdown Structure); XP - aukštasis programavimas (eXtreme Programming).



127

Šaltiniai

[BECK01] Kent Beck et al. Manifesto for Agile Software Development, 2001.

www.agilemanifesto.org .

[CMMI] Software Engineering Institute, “Capability Maturity Model Integration, v1.1”,

CMU/SEI-2002-TR-002, ESC-TR-2002-002, December 2001.

[FF06] Fabrizio Fioravanti. Skills For Managing Rapidly Changing IT projects. IRM press.

2006.

[HC04] W. Heldman, L. Cram. PROJECT+Study guide. Wiley Publishing, Inc., Indianapolis,

Indiana, 434 p., 2004.

[ISO25010] ISO/IEC 25010:2011. Systems and software engineering -- Systems and software

Quality Requirements and Evaluation (SQuaRE) -- System and software quality

models.

[ISO9126] ISO/IEC 9126-1:2001. Software Engineering-Product Quality-Part 1: Quality Model.

[JT06] Jean Tabaka. Collaboration Explained: Facilitation Skills for Software Project

Leaders. Addison Wesley Professional, 456 p., 2006.

[KHR05] Kenneth H. Rose. Project Quality Management. J. Ross Publishing, 2005.

[KS04] Ken Schwaber. Agile Project Management with Scrum. Microsoft Press. ISBN 978-0-

735-61993-7, 2004.

[LPL00] Lawrence P.Leach. Critical chain project management. ArtechHouse, Boston-

London, 337 p., 2000.

[PFR02] Parviz F.Rad, Project Estimating and Cost Management. Management Concepts,

2002.

[PMBOK] A Guide to the Project Management Body of Knowledge, Fourth edition. Project

Management Institute, 459 p., 2008.

[RBC05] Ronald B.Cagle. Your Successful Project Management Career. AMACOM, 224 p.,

2005.

[SOX] Ivy Xiying Zhang. Economic Consequences of the Sarbanes-Oxley 2002. University

of Rochester, 68 p., 2005.

http://w4.stern.nyu.edu/accounting/docs/speaker_papers/spring2005/Zhang_Ivy_Econo

mic_Consequences_of_S_O.pdf .

[SS11] Ken Schwaber and Jeff Sutherland. The Scrum Guide. 17 p., 2011.

http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%202011.pdf

[SW07] James Shore and Shane Warden. The Art of Agile Development. O‘Reilly Media, 418

p., 2007.

[XP09] Extreme Programming: A Gentle Introduction. 2009.

http://www.extremeprogramming.org/ .

[WL06] Walt Lipke. The TCPI indicator. Transforming project performance. Project

management institute (USA), Oklahoma, 7 p., 2006.

http://www.earnedschedule.com/Docs/The%20TCPI%20Indicator%20-%20P&P.pdf

http://www.agilemanifesto.org/

http://en.wikipedia.org/wiki/Microsoft_Press

http://en.wikipedia.org/wiki/International_Standard_Book_Number

http://en.wikipedia.org/wiki/Special:BookSources/978-0-735-61993-7

http://en.wikipedia.org/wiki/Special:BookSources/978-0-735-61993-7

http://w4.stern.nyu.edu/accounting/docs/speaker_papers/spring2005/Zhang_Ivy_Economic_Consequences_of_S_O.pdf

http://w4.stern.nyu.edu/accounting/docs/speaker_papers/spring2005/Zhang_Ivy_Economic_Consequences_of_S_O.pdf

http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%202011.pdf

http://www.extremeprogramming.org/

http://www.earnedschedule.com/Docs/The%20TCPI%20Indicator%20-%20P&P.pdf

programŲ sistemŲ projektŲ ir kokybĖs valdymasvalund/konspektai/ps projektu valdymas.pdf ·...

Documents