PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS

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

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 2

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 3

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 4

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 5

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ų 6

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, 7

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ų. 8

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 9

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. 10

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ę. 11

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. 12

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 Kontrolė Vykdymas Planavimas (Planning) Vykdymas (Executing) Kontrolė (Controlling) Vykdymas Kontrolė 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. 13

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. Į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.) Inicijavimas Projekto nuostatai, preliminari projekto apimtis Projekto iniciatorius / sponsorius 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, Naudotojai Galutinis produktas Užbaigimas Administracinės projekto užbaigimo procedūros 1.1 pav. Projekto valdymo procesų grupių sąveika 14

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. Proceso lygis Kontrolė Projekto pradžia Projekto pabaiga 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 15

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 16

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ų. 17

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. 18

Organizacijos vadovas 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) 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. Organizacijos vadovas Funkcinio padalinio vadovas Funkcinio padalinio vadovas Funkcinio padalinio vadovas Vyriausiasis projektų vadovas Darbuotojas Darbuotojas Darbuotojas Projekto vadovas Darbuotojas Darbuotojas Darbuotojas Projekto vadovas Darbuotojas Darbuotojas Darbuotojas Projekto vadovas 1.3 pav. Matricos tipo organizacija (paryškinti Projekto vadovas ir Darbuotojas projekto grupė) 19

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. Organizacijos vadovas 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ė) 20

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ų 21