Transcript PS projektu valdymas.. - Matematikos ir Informatikos fakultetas

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
Dalykas skaitomas Programų sistemų 4 kurso bakalaurams
2013 m.
1
Programų sistemų projektų ir kokybės valdymas
Bendrieji užsiėmimų klausimai
Užsiėmimų forma
a) paskaitos;
b) pratybos. Įvairiais aspektais nagrinėjama dalyko medžiaga.
Atsiskaitymas už dėstomą dalyką
a) medžiagos įsisavinimo testai pratybų metu;
b) egzaminas;
c) svoris galutiniame įvertinime: 40% - pratybų testai; 60% - egzaminas.
Šaltiniai
1. A Guide to the Project Management Body of Knowledge (PMBOK),
Fourth edition. 459 p., 2008.
2. V.Undzėnas. Programų sistemų projektų ir kokybės valdymas.
Mokymo medžiaga, VU MIF, 2011, 136 p. http://mif.vu.lt/~valund .
3. Standartai; internete ir kitur randami šaltiniai.
2
Programų sistemų projektų ir kokybės valdymas
Bendrieji užsiėmimų klausimai
Mokomojo dalyko skyriai
1) projektų valdymo įvadas;
2) projekto inicijavimas;
3) projekto apimties planavimas;
4) darbų grafiko planavimas;
5) projekto kainos planavimas;
6) projekto grupės planavimas;
7) kokybės planavimas;
8) rizikos planavimas;
9) komunikacijų planavimas;
10) pirkimų planavimas;
11) projekto bendrojo plano
rengimas;
12) projekto vykdymas;
13) projekto kontrolė;
14) projekto užbaigimas;
15) lankstieji metodai.
3
I. Projektų valdymo įvadas (1)
Projektų valdymo svarba
1. 1995 m. Standish Group studija (CHAOS) nustatė, kad tik 16.2 % iš visų
IT projektų yra sėkmingai įvykdomi (projekto tikslai pasiekiami numatytu laiku ir
neviršijant biudžeto).
2. The Standish Group's just-released report, "CHAOS Summary 2009"
"This year's results show a marked decrease in project success rates, with 32% of
all projects succeeding ...; 44% were challenged ...; 24% failed ...“
http://www1.standishgroup.com/newsroom/chaos_2009.php
3. Iš interviu su valstybės kontroliere R.Budbergyte: „Nustatyta, kad
pasaulyje tik 16 proc. projektų įgyvendinama laiku. Apie 50 proc. jų dėl blogos
vadybos pabrangsta 220 proc., o jų įgyvendinimo laikas pailgėja iki 167 proc.
Neinvestuojam į kvalifikuotą žmogų, kad jis vadovautų projektui, ir taip padarom
nuostolių valstybei. ...“ [„Valstybės tarnybos aktualijos“, 2007 liepa, Nr. 8,
„NIEKO NEKEISDAMI, PRIEISIME LIEPTO GALĄ”].
4
I.I. Projektų
Projektų valdymo
valdymo įvadas
įvadas (0b)
(2)
4. Tarptautinė projektų valdymo asociacija (IPMA) nustatė, kad geras
projektų valdymas leidžia sutrumpinti projektų atlikimo trukmę vidutiniškai 20–
30 %, o išlaidas sumažinti 10–15 %.
5. Projekto sėkmei didesnę įtaką turi geras valdymas nei technologiniai
veiksniai.
6. Žurnalas “International Journal of Project Management” paskelbė:
“21 a. projektų valdymas pakeis tradicinę funkcinę vadybą”.
5
I. Projektų valdymo įvadas (3)
(1)
1. Projekto sąvokos apibrėžimas
1.1. Kas yra IT projektas?
Tai unikalių produktų ar paslaugų kūrimo veikla, kurie galės būti parduodami
klientams arba naudojami savo organizacijoje. Projektai visada būna ribotos
trukmės, pradedami tik turint aiškius tikslus ir akcininkus.
Programa yra grupė susijusių projektų.
1.2. IT projektų vadovų bendrosios pareigos
Projekto vadovo pareigos: projekto vadovas, verslo, programų sistemų,
biudžeto, teisinių klausimų analitikas, derybininkas, technologas, strategas, ryšių
palaikymo atstovas, laiko skirstytojas, projekto grupės sudarytojas.
1.3. IT projektų svarstymo kalba
Su pašnekovais stenkimės kalbėti kiek įmanoma jiems aiškesne kalba.
6
I. Projektų valdymo įvadas (4)
2. Projektų valdymo apibrėžimas
Projekto valdymas - tai žinių, įgūdžių, instrumentų ir metodų
naudojimas projekto reikalavimams įgyvendinti.
Žinių sritys, kuriomis remiasi projektų valdymas:
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.
7
I. Projektų valdymo įvadas (5)
3. Bendrieji projekto vadovo įgūdžiai
1) mokėjimas vadovauti;
2) gebėjimas komunikuoti
(palaikyti ryšį) balsu;
3) gebėjimas komunikuoti
raštu;
4) mokėjimas išklausyti kitų;
5) organizaciniai gebėjimai;
6) mokėjimas skirstyti laiką;
7) planavimo gebėjimai;
8) gebėjimas spręsti problemas;
9) gebėjimas susitarti
(prieiti konsensuso);
10) gebėjimas spręsti konfliktus;
11) mokėjimas derėtis;
12) gebėjimas suburti projekto
grupę.
8
I. Projektų valdymo įvadas (6)
4. Projektų valdymo procesai (veiklos)
Procesų grupės
pavadinimas
Rezultatai perduodami
procesų grupei
Inicijavimas
Planavimas
Inicijavimas
Kontrolė
Planavimas
Vykdymas
Planavimas
Kontrolė
Vykdymas
Kontrolė
Vykdymas
Kontrolė
Planavimas
Vykdymas
Užbaigimas
Kontrolė
Užbaigimas
Duomenys gaunami
iš procesų grupės
Iniciatorius
Naudotojai
9
I. Projektų valdymo įvadas (7)
Trumpas projektų valdymo procesų apibūdinimas:
1) inicijavimas. Tai veiklos, kuriomis siekiama parodyti, kad reikia pradėti
projektą: verslo poreikių įvardinimas, reikalavimų metmenų parengimas,
kainos numatymas. Sprendimo vykdyti projektą priėmimas;
2) planavimas. Detalizuojami projekto tikslai, įvertinama projekto trukmė,
kaina, kiekvienam darbui reikalingi ištekliai, parengiamas projekto planas;
3) vykdymas. Projekte numatytos sistemos kūrimo darbų valdymas. Projekto
vadovas koordinuoja projekto grupės narių darbą ir projektui skirtų išteklių
naudojimą;
4) kontrolė. Stebima projekto eiga, nukrypimai nuo projekto plano.
Analizuojami prašymai daryti projekto pakeitimus, priimami sprendimai;
5) užbaigimas. Projekte sukurtos sistemos formalus priėmimas (užsakovas
priima iš projekto vykdytojo) ir perdavimas einamajam darbiniam
naudojimui.
10
I. Projektų valdymo įvadas (8)
Įmonės aplinka
(organizaciniai aspektai, projektų
valdymo informacinė sistema,
žmoniškieji ištekliai)
Įmonės org. dokumentai
(taisyklės, procedūros, standartai,
apibrėžti procesai, kt.)
Projekto iniciatorius
/sponsorius
Inicijavimas
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
Naudotojai
Galutinis produktas,
paslaugos, rezultatai
Administracinės projekto
užbaigimo procedūros,
sandorių užbaigimas
11
I. Projektų valdymo įvadas (9)
Projekto valdymo procesų persidengimas,
kainos ir išteklių poreikio lygis
Proceso lygis
Kontrolė
Projekto pradžia
Projekto pabaiga
12
I. Projektų valdymo įvadas (10)
5. IT projektų gyvavimo ciklas
Projekto gyvavimo ciklas – tai laike išdėstytų fazių (etapų) rinkinys. Jis
bendriausiu būdu atspindi kiekvienos fazės rezultatus ir darbams reikalingų
išteklių kategorijas, užbaigto projekto rezultatų naudojimą.
Programų sistemų kūrimo ciklo (SDLC – Software Development Life Cycle)
fazių atitikmuo projektų valdymo procesams:
SDLC fazės
Projektų valdymo procesai
1. Planavimo fazė
Inicijavimas, planavimas
2. Analizės fazė
Inicijavimas, planavimas
3. Projektavimo (design) fazė
Planavimas
4. Realizavimo fazė
Vykdymas, kontrolė
5. Naudojimo ir priežiūros fazė
Užbaigimas
13
I. Projektų valdymo įvadas (11)
IT projekto etapai ir kontroliniai taškai
Bet kurios programų sistemos kūrimo ciklas (SDLC) dalinamas į etapus
(milestones), kas palengvina projekto eigos stebėjimą. Etapą sudaro labai aiškią
pabaigą turinčių užduočių rinkinys. Apie etapo įvykdymą raportuojama
vienareikšmiškai - taip arba ne.
Projekto etapai savo ruožtu gali turėti keletą kontrolinių taškų (baselines,
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.
14
I. Projektų valdymo įvadas (12)
6. Organizacijos struktūros įtaka projektams
Projektų valdymui didelę įtaką turi organizacijos struktūra, kurioje yra
vykdomas projektas. Nuo to priklauso projekto vadovo įgaliojimai ir projekto
vykdymui reikalingų išteklių skyrimas.
Yra trijų tipų organizacijos:
1) funkcinio;
2) matricos;
3) projektinio.
15
I. Projektų valdymo įvadas (13)
6.1. Funkcinio tipo organizacija
Darbuotojai jose yra paskirstyti į funkcinius padalinius (departamentus), pvz.,
personalo, finansų, teisės, tinklų priežiūros, IT, klientų aptarnavimo, kt.
Organizacijos vadovas
Funkcinio
padalinio
vadovas
Funkcinio
padalinio
vadovas
Funkcinio
padalinio
vadovas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
( asmuo
Funkcinio
padalinio
vadovas
Darbuotojas
Darbuotojas
Darbuotojas
– projekto grupės narys )
16
I. Projektų valdymo įvadas (14)
Funkcinio tipo organizacijose projektai atliekami kaip atskiri, funkciniams
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.
17
I. Projektų valdymo įvadas (15)
6.2. Matricos tipo organizacija
Matricos tipo organizacijos, panašiai kaip ir funkcinio tipo organizacijos, yra
padalintos į funkcinius padalinius (departamentus).
Organizacijos vadovas
Funkcinio
padalinio
vadovas
Funkcinio
padalinio
vadovas
Funkcinio
padalinio
vadovas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Vyriausiasis
projektų
vadovas
Projekto vadovas
Projekto vadovas
Projekto vadovas
( asmuo – projekto grupės narys )
18
I. Projektų valdymo įvadas (16)
Matricos tipo organizacijose 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.
19
I. Projektų valdymo įvadas (17)
6.3. Projektinio tipo organizacija
Šio tipo organizacijų pagrindinis darbas yra projektų vykdymas. Pagrindinis
jų bruožas - aukšti įgaliojimai projektų vadovams, leidimas jiems naudoti išteklius
visą projekto laiką, projektui vykdyti reikalingos darbo grupės sudarymas.
Organizacijos vadovas
Projekto
vadovas
Projekto
vadovas
Projekto
vadovas
Projekto
vadovas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
( asmuo – projekto grupės narys )
20
II. Projekto inicijavimas (1)
1. Prašymas (užsakymas) pradėti projektą
Prašymo rengimo 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.
21
II. Projekto inicijavimas (2)
Reikalavimų metmenys (koncepcija, high-level requirements)
1)
2)
3)
4)
problemos apibrėžimas;
reikalavimų kategorijos: funkciniai, verslo, techniniai (nefunkciniai);
tiekėjų pasiūlymai;
reikalavimų metmenų dokumento rengimas, jo sudėtis:
- problemos apibrėžimas;
- tikslai;
- strateginė vertė;
- reikalavimai;
- aplinkybių įvertinimas (projekto vykdytojo galimybės);
- ankstesnė patirtis (istoriniai duomenys).
22
II. Projekto inicijavimas (3)
2. Projektų atranka
1) atrankos būdai. Sprendžiami leidimo pradėti projektą ir jo finansavimo
klausimai. Tą daro organizacijos vadovybė, departamento ar kitokio
padalinio vadovas. Sudėtingų projektų atveju rengiamos galimybių
studijos (feasibility study) ir tik jų pagrindu priimami sprendimai.
Vertinama nauda, rinkos dydis, rizika, alternatyvos. Tą daro tretieji
(nesusiję) asmenys;
2) atrankos kriterijai:
- sprendimų priėmimo modeliai;
- ekspertų nuomonė.
23
II. Projekto inicijavimas (4)
Sprendimų priėmimo modeliai
1) naudą vertinantys modeliai:
- kainos-naudos analizė (CBA – Cost Benefit Analysis). Vertinama projekto
kaina, numatomi sutaupymai, prognozuojamas pajamų padidėjimas. Praktikoje
dažniausiai naudojamas pelno ir kainos santykis (BCR – Benefit Cost Ratio). Jei
BCR > 1, projektas atsipirko. Kuo BCR didesnis, tuo projektas patrauklesnis;
- vertinimo balais modelis (weighted scoring model). Naudojami iš anksto
nustatyti kriterijai, remiantis kuriais projektai yra reitinguojami. Kiekvienas
kriterijus turi leistiną balų kiekį ir svorio koeficientą;
- ekonominis modelis. Keletas jame naudojamų bendriausių sąvokų:
d – diskonto norma. d = (1+N) / (1+I) – 1 + r ,
kur N – palūkanų norma, I – infliacija, r - rizika;
DCF (Discounted Cash Flow) – diskontuotas pinigų srautas. Tai diskontuotas
pajamų ir išlaidų skirtumas per laiko periodą (pvz., metus);
24
II. Projekto inicijavimas (5)
NPV - grynoji dabartinė vertė (Net Present Value). Ji parodo pinigų sumos
ateityje ekvivalentą šiandien. Apskaičiuojama kaip diskontuotų pinigų srautų
suma:
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ė; Sn – n-tojo periodo pinigų
srautas; d – diskonto norma. S0 yra išlaidos projekto pradžioje.
Kuo NPV didesnis, tuo projektas yra patrauklesnis;
atsipirkimo periodas (payback period). Tai numatomas laiko tarpas, per kurį
projektas atsipirks;
IRR - vidinės grąžos norma (Internal Rate of Return). Gaunamas pagal
formulę:
0 = Σn ( Sn / (1+IRR)n ), kai NPV = 0.
Kuo IRR didesnis, tuo projektas rentabilesnis (pelningesnis). Pvz., jei d < IRR,
verta skolintis pinigų ir pradėti projektą. Kitu atveju – ne;
25
II. Projekto inicijavimas (6)
ROI - atsipirkimo norma (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;
2) matematiniai optimizacijos modeliai.
Šie modeliai naudojami labai sudėtingiems projektams įvertinti ir atrinkti,
reikalauja gilių statistikos ir kitų matematikos žinių. Tai tiesiniai, netiesiniai,
dinaminiai ir kitokie programavimo algoritmai, sprendimų medžiai ir kita.
Ekspertų nuomonė
Ekspertizę gali atlikti sponsorius, pagrindiniai akcininkai, konsultantai,
pramonės atstovai. Ekspertų nuomonė gali būti derinama su sprendimo priėmimo
modelio rezultatais. To prireikia, kai atrankai pateiktų projektų įverčiai, gauti
naudojant sprendimo priėmimo modelį, mažai tesiskiria.
Nors ekspertai ir daro paprastesnį projektų atrankos procesą, tačiau pavojus
suklysti išlieka.
26
II. Projekto inicijavimas (7)
3. Projekto akcininkai
1) sponsorius.
Projekto sponsorius yra ypatingas akcininkas ir jis turėtų būti tik vienas.
Sponsorius yra asmuo, kuris remia projektą organizacijos vardu. 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.
27
II. Projekto inicijavimas (8)
2) kiti projekto akcininkai:
- projekto vadovas;
- projekto grupės nariai;
- organizacijos funkcinių padalinių vadovai;
- pirkėjai/klientai;
- galiniai naudotojai;
3) kas yra jūsų projekto akcininkai?
- vienos veiklos srities projektas;
- keleto veiklos sričių projektas;
- įmonės projektas;
- projekto grupės nariai;
- akcininkų sąrašas.
28
II. Projekto inicijavimas (9)
4. Projekto nuostatai (project chart)
Tai pradinis projekto dokumentas (projekto pagrindas). Jo sudėtis:
- reikalavimų metmenys (high-level requirements);
- informacija apie projekto grupę. Projekto vadovo įgaliojimai,
reikiami specialistai, subrangovai;
- uždaviniai ir tikslai;
- projekto pagrindimas. Kaina, nauda, atsipirkimo periodas;
- formalus projekto patvirtinimas. Vadovų hierarchija.
29
III. Projekto apimties planavimas (1)
Projekto apimtis (project scope) - jam įvykdyti reikalingų darbų kiekis
ir dydis. Apimties planavimo metu apibrėžiamas reikiamas išteklių kiekis ir
nustatomi projekto apribojimai (terminai, kaina, kokybė).
Projekto nuostatai yra įeities duomenys projekto apimties planui rengti.
1. Projekto apimties plano struktūra
Sukurtame projekto apimties plane turi būti šios trys dalys:
- apimties aprašas;
- apimties valdymo planas;
- suskaidytų darbų lentelė (WBS – Work Breakdown Structure).
30
III. Projekto apimties planavimas (2)
1.1. Projekto apimties aprašas
- projekto poreikis;
- reikalavimai;
- pagrindiniai laukiami rezultatai;
- sėkmės kriterijai;
- projekto užbaigimo kriterijus;
- trukmės ir kainos metmenys;
- prielaidos;
- apribojimai.
Projekto poreikis
Išdėstomi prašymo pradėti projektą argumentai, teisės aktai, kuriais yra
paremtas prašymas.
31
III. Projekto apimties planavimas (3)
Reikalavimai
Aprašomos sistemos savybės ir funkcijos, akcentuojama naujovės. Tai
papildyti, detalizuoti reikalavimų metmenys, kurie buvo projekto nuostatuose.
Laukiami projekto rezultatai
Pateikiama suvestinė lentelė rezultatų, kurie turi būti gauti kuriant produktą.
Pvz., sistema, naudojimo instrukcija, mokymo medžiaga, pagalbos naudotojams
priemonės.
Sėkmės kriterijai
Nurodomi veiklos srities, kuriai yra vykdomas projektas, pagerėjimo
rezultatai. Jų pasiekimo laipsnį turi būti galima įvertinti kiekybiškai. Kriterijų
pavyzdžiai: bendras pajamų padidėjimas, darbo našumo padidėjimas, atitikimas
teisės aktams, darbuotojų kiekio sumažėjimas.
32
III. Projekto apimties planavimas (4)
Projekto užbaigimo kriterijus
Juo parodoma, kada laikysime projektą užbaigtu. Pvz., gali būti reikalaujama,
kad pridavimo metu sistema turi veikti be jokių priekaištų.
Trukmės ir kainos metmenys
Projekto trukmės ir dabartinės projekto kainos metmenys gaunami remiantis
panašių jau vykdytų projektų duomenimis arba patirtį panašiuose darbuose
turinčio eksperto nuomonės. Tai nėra tikslūs duomenys. IT projektuose kainos
metmenų paklaida būna iki 75%.
Prielaidos
Prielaida – tai veiksmas, sąlygos ar įvykis, kurio tikimasi.
Apribojimai
Jie yra dviejų tipų. Pirmieji susiję su laiku, kaina, kokybe, apimtim. Antrieji
yra specifiniai ir siejami su darbų grafiku, žmoniškaisiais ištekliais, sistemos
testavimo galimybėmis.
33
III. Projekto apimties planavimas (5)
1.2. Projekto apimties valdymo planas
Aprašomos procedūros, kurių reikės laikytis norint daryti bet kokius
projekto apimties pakeitimus viso jo gyvavimo ciklo bėgyje.
Apimties valdymo procesui, mažiausiai, turi būti parengti:
- standartinė prašymų forma keitimams projekte 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;
- viso projekto plano koregavimo būdas.
34
III. Projekto apimties planavimas (6)
1.3. Projekto suskaidytų darbų lentelė
Projekto suskaidytų darbų lentelėje (WBS – Work Breakdown Structure)
nurodomi pagrindiniai projekto darbai. Darbai skaidomi į keletą lygių tol, kad
žemiausio lygio darbų įvykdymo laipsnį galima būtų išmatuoti ir būtų aišku, kokio
finansavimo jiems reikėtų.
Projektas
1 lygis
................
2 lygis
1. Darbų grupė
2. Darbų grupė
3. Darbų grupė
................
3 lygis
................
t. t.
1.1. Darbas
2.1. Darbas
3.1. Darbas
1.2. Darbas
2.2. Darbas
3.2. Darbas
1.3. Darbas
3.3. Darbas
2.2.1. Darbelis
2.2.2. Darbelis
WBS su numeruojamais darbais
35
III. Projekto apimties planavimas (7)
WBS rengimo gairės
- pasitelkime išmanančius žmones. Nesistenkime viską daryti patys;
- kiekvienas žemesnio lygio punktas yra aukščiau esančio lygio
komponentas. Skaidykime darbus į tiek lygių, kad jau galėtume
rengti darbų trukmės, kainos ir reikiamų išteklių įverčius;
- nekurkime pernelyg smulkių darbų lentelės. Remkimės 8/80 taisykle:
darbai ne trumpesni nei 8 valandos ir ne ilgesni nei 80 valandų;
- kiekvieną punktą skaidykime į tinkamą lygių kiekį;
- naudokime skaitinius numerius kiekvienam WBS darbui.
WBS nauda
WBS yra projekto trukmės ir kainos, reikalingų išteklių vertinimo pagrindas.
Tai instrumentas, padedantis bendrauti projekto grupės nariams, bendrauti su
užsakovu, stebėti projekto eigą, kt.
36
III. Projekto apimties planavimas (8)
2. IT projekto apimtį įtakojantys veiksniai
- IT įmonės dydis;
- projekto siekiamų rezultatų apibrėžimo tikslumas;
- darbo su užsakovu aplinkybės;
- sėkmės kriterijų apibrėžimo sunkumas;
- pašaliniai ar neišsiaiškinti elementai;
- santykiai su tiekėjais;
- projekto grupės narių pasitraukimas;
- projekto darbų dalinimas keliems IT padaliniams;
- testuojami elementai reikalauja gero apibrėžimo.
37
IV. Darbų grafiko planavimas (1)
Projekto darbų grafiko (schedule) rengimo įeities duomenys yra WBS, kuris
buvo sudarytas projekto apimties planavimo metu.
1. Darbų eilės tvarka
1.1. Darbų priklausomybių tipai
- privalomoji priklausomybė;
- savarankiškai nustatoma priklausomybė;
- išorinė priklausomybė.
38
IV. Darbų grafiko planavimas (2)
1.2. Darbų priklausomybės pobūdis
a) pabaigos-pradžios
b) pabaigos-pabaigos
Pirmasis darbas
Pirmasis darbas
Antrasis darbas
Antrasis darbas
c) pradžios-pradžios
d) pradžios-pabaigos
Pirmasis darbas
Pirmasis darbas
Antrasis darbas
Antrasis darbas
39
IV. Darbų grafiko planavimas (3)
1.3. Darbų išdėstymo diagramos
a) darbų išdėstymas PDM (Precedence Diagramming Method) diagrama.
Kitur vadinama AON – Activity On Node.
D darbas
Pradžia
Pabaiga
A darbas
B darbas
C darbas
b) darbų išdėstymas ADM (Arrow Diagramming Method) diagrama.
Kitur vadinama AOA – Activity On Arrow.
D darbas
Pradžia
A darbas
B darbas
C darbas
Pabaiga
40
IV. Darbų grafiko planavimas (4)
2. Darbų trukmės vertinimas
2.1. Trukmės apibrėžimas
Darbo atlikimo trukmė apima bendrąjį kalendorinį laiką (įskaitant laisvadienius
ir švenčių dienas).
2.2. Trukmės vertinimo būdai
a) analogiškasis arba iš viršaus–žemyn.
Remiamasi anksčiau vykdytų projektų panašiems darbams realiai
sugaišto laiko perėmimu. Žemas tikslumas;
b) ekspertinis.
Pasitelkiami projekto darbus gerai išmanantys žmonės;
c) kiekybiškasis.
Naudojamas, kai yra išmatuota tam tikro darbų kiekio trukmė ir yra
formulės viso darbo trukmei apskaičiuoti. Tiksliausias būdas.
41
IV. Darbų grafiko planavimas (5)
Darbų išdėstymo diagramos pavyzdys:
Pradžia
A darbas:
3 dienos
B darbas:
5 dienos
D darbas:
12 dienų
Pabaiga
C darbas:
8 dienos
E darbas:
6 dienos
42
IV. Darbų grafiko planavimas (6)
3. Darbų grafiko sudarymas
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.
3.1. Kritinio kelio metodas
Kritinio kelio metodas (CPM) yra matematinio analizavimo būdas. Kritinis
kelias projekto darbų grafike yra ilgiausios darbų sekos kelias projekte, nuo kurio
priklauso viso projekto pabaigos terminas. Kritinio kelio darbų trukmės negali
turėti svyravimų. Gali svyruoti tik darbo pradžios laikas arba darbui užbaigti
papildomai skiriamo laiko trukmė.
43
IV. Darbų grafiko planavimas (7)
CPM metodo eiga:
a) peržiūra pirmyn. Visų pirma randamos darbų sekos, vedančios nuo
projekto pradžios iki pabaigos. Kiekvienam darbui apskaičiuojamas anksčiausias
pradžios laikas ir anksčiausias pabaigos laikas;
b) peržiūra atgal. Darbų išdėstymo diagramos analizė pradedama nuo galo
ir einama link pradžios. Kiekvienam darbui apskaičiuojama vėliausia darbo
pradžia ir vėliausia darbo pabaiga;
c) laikų svyravimų radimas. 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ų.
Kritinis darbų kelias bus tas, kuriame visų darbų laikų svyravimai lygūs 0.
44
IV. Darbų grafiko planavimas (8)
Kritinio darbų kelio nustatymo iliustracija, remiantis turėta darbų diagrama.
B darbas:
5 dienos
A darbas:
3 dienos
Pradžia
D darbas:
12 dienų
Pabaiga
C darbas:
8 dienos
E darbas:
6 dienos
Darbas
Anksčiausia
pradžia
Anksčiausia
pabaiga
Vėliausia
pradžia
Vėliausia
pabaiga
Svyravimai
A
0
3
0
3
0
B
3
8
3
8
0
C
3
11
6
14
3
D
8
20
8
20
0
E
11
17
14
20
3
45
IV. Darbų grafiko planavimas (9)
d) 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:
- papildomų išteklių (pvz., darbuotojų) skyrimas;
- lygiagretus darbų atlikimas, kurie normaliai būtų atliekami nuosekliai.
Minėtiems darbų grafiko planavimo darbams atlikti yra įrankiai: projektų
valdymo programinė įranga, pvz., Microsoft Project.
46
IV. Darbų grafiko planavimas (10)
3.2. Projekto etapai
Etapai turi atspindėti pagrindinius projekto gyvavimo ciklo įvykius. Jų datos
nurodo, kada turi būti gauti svarbūs projekto rezultatai.
Projekto darbų grafike etapų pabaigos laikai nustatomi tokie, kad juose
įvardintus darbus būtų galima be išlygų atlikti 100 proc. Etapo darbų atlikimas turi
būti vertinamas vienareikšmiškai: atlikta arba neatlikta.
3.3. Darbų grafiko kontroliniai taškai
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į.
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.
47
IV. Darbų grafiko planavimas (11)
4. Projekto terminai ir tikrovė
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.
Parengti gerą projekto darbų grafiką nėra lengva. Dalį problemų gali padėti
išspręsti bendri organizacijos interesai. Jei jūsų projektas yra svarbus ir 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.
48
V. Projekto kainos planavimas (1)
Projekto vadovas, turėdamas projekto apimties aprašą, darbų sąrašą (WBS) ir
jų atlikimo grafiką, turi parengti projekto biudžetą, ir, kai jį patvirtina projekto
rėmėjai, tvarkyti jį.
Lėšos yra numatomos kiekvienam projekto etapui. Biudžeto išlaidoms sekti
taip pat yra naudojami kontroliniai taškai.
1. Išteklių planavimas
Išteklių planavimo pradžioje reikėtų pasidomėti, kur galima būtų gauti
informacijos apie anksčiau vykdytų panašių projektų išteklius.
1.1. Išteklių tipai
- žmoniškieji ištekliai;
- įranga;
- medžiagos.
49
V. Projekto kainos planavimas (2)
1.2. Išteklių poreikio nustatymas
Išteklių poreikio dokumente aprašomi kiekvienam projekto darbui reikalingi
visų trijų tipų ištekliai. Tam rengiami:
- pareigų aprašai;
- įrangos ir medžiagų aprašai;
- reikiamų išteklių lentelė (pavyzdys žemiau).
Darbas
Programuotojai
Inžinieriai
Ekonomistai
A
B
E
Serveriai
1
2
C
D
Dokumentų
rengėjai
3
1
4
1
50
V. Projekto kainos planavimas (3)
2. Išteklių kainos vertinimas
2.1. Kainos vertinimo būdai
a) analogiškasis. Remiasi anksčiau vykdytų projektų patirtimi. Kitaip jis
dar vadinamas iš viršaus-žemyn (top down) arba leistinų ribų (order of magnitude)
kainos vertinimo būdu.
Naudojamas visam projektui, atskiroms jo dalims ar rezultatams. Tačiau jis
nėra naudojamas vertinant išteklių poreikį atskiriems darbams ar jų grupėms.
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.
51
V. Projekto kainos planavimas (4)
b) parametrinis modeliavimas. Tai matematiniai modeliai. Geriausiai tinka
statybų projektuose. 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.
52
V. Projekto kainos planavimas (5)
c) pavyzdinis vertinimas (definitive estimates). Duoda geriausią tikslumą,
nes 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). Projekto
darbų (WBS) ir reikiamų išteklių sąrašai 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.
Vertinant reikiamų išteklių kainas, būtina remtis pastangų dydžiu, kas
matuojama žmogaus darbo valandomis.
Skirtumas tarp darbui atlikti reikalingo laiko ir pastangų dydžio yra tas, kad
trukmės įverčiai darbų grafike padeda mums nustatyti, kiek gi kalendorinio laiko
reikės projektui užbaigti, o pastangų dydžio įverčiai naudojami projekto kainai
nustatyti
53
V. Projekto kainos planavimas (6)
Projektui įvykdyti reikalingų pastangų dydžio pavyzdys
Ištekliai
Darbas
Pastangų dydis
A
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): valandos arba dienos kaina, mokestis
(pvz., naudojimosi sistema) ar vertė (pvz., el. energijos kilovatvalandės,
kanceliarinės prekės).
54
V. Projekto kainos planavimas (7)
Projekto kainos vertinimo pavyzdys:
Darbas
Ištekliai
Pastangų dydis
Kaina, įkainis
A
Dokumentų rengėjai (1)
20 val.
30 Lt/val
600 Lt
B
Programuotojai (2)
100 val.
50 Lt/val
5000 Lt
C
Inžinieriai (3)
60 val.
40 Lt/val
2400 Lt
C
Serveriai
N/A
50000 Lt
50000 Lt
D
Programuotojai (4)
200 val.
50 Lt/val
10000 Lt
E
Ekonomistai (1)
30 val.
60 Lt/val
1800 Lt
Iš viso:
Visa kaina
69800 Lt
55
V. Projekto kainos planavimas (8)
2.2. Kainos vertinimo rekomendacijos
- šaukime projekto darbo grupės pasitarimus;
- gerai suvokime naudojamą kainos vertinimo būdą;
- naudokime kokį nors prieinamą šabloną;
- stenkimės gauti įverčius iš darbą atliekančių žmonių;
- numatykime lėšas projekto grupės nariams skatinti;
- dokumentuokime visas prielaidas.
56
V. Projekto kainos planavimas (9)
3. Projekto biudžeto sudarymas
Projekto vadovas įvertintą projekto kainą perduoda organizacijos biudžeto
tvarkytojams (pvz., finansų departamentui). 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 paskirstomos atskiriems
projekto darbams.
Projekto biudžetas padeda orientuotis, kokio dydžio išlaidos leistinos
kiekvieno tipo ištekliams numatytais laikotarpiais. Dažniausiai biudžetas
padalinamas mėnesiais.
Prieš pradėdami projekto darbus susipažinkite su jūsų organizacijoje
galiojančiomis taisyklėmis, projekto vadovo įgaliojimais tvarkyti projekto
biudžeto klausimais.
57
V. Projekto kainos planavimas (10)
3.1. Projekto biudžetas
Projekto biudžetas rengiamas remiantis patvirtintu projekto kainos įverčiu ir
darbų grafiku.
Atkreiptinas dėmesys į du savarankiškus fondus, kurie gali būti biudžete:
- specialųjį fondą. Juo siekiama sudaryti geresnes galimybes projekto rizikos
klausimams spręsti. Dažniausiai naudojami priešakiniuose projektuose, kai
nėra galimybės remtis ankstesnių projektų patirtimiir kainų įverčių
paklaidos gali būti didelės. Dažniausiai projekto vadovui suteikiami
įgaliojimai naudoti specialiojo fondo lėšas;
- vadovybės rezervinį fondą. Jį skiria organizacijos vadovybė situacijoms
spręsti (išeinant už pradinės apimties projekto ribų), kurių nebuvo galima
numatyti rengiant projekto kainos įvertį. Pastaruoju fondu projekto vadovas
gali pasinaudoti tik gavęs vadovybės patvirtinimą.
58
V. Projekto kainos planavimas (11)
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ų.
Dažniausiai biudžetai būna lentelės pavidalo, padalinti mėnesiais ar metų
ketvirčiais.
Projekto biudžeto pavyzdys:
Sausis
Darbo užmokestis
Samdomas darbas
(programuotojai)
Aparatinė įranga
(serveris)
Vasaris
Kovas
Suma
600 Lt
1200 Lt
3000 Lt
4800 Lt
5000 Lt
5000 Lt
5000 Lt
15000 Lt
50000 Lt
50000 Lt
Iš viso:
69800 Lt
59
V. Projekto kainos planavimas (12)
3.2. Biudžeto lėšos projekto etapams
3.3. Biudžeto naudojimo kontroliniai taškai
3.4. Įrankis biudžetui sudaryti – projektų valdymo programinė įranga
60
VI. Projekto grupės planavimas (1)
Projekto kainos planavimo metu, kalbant apie žmoniškųjų išteklių poreikį,
buvo akcentuojama darbuotojų specialybė, kokius darbus jie turėtų mokėti dirbti.
Projekto grupės planavimo rezultatas – tai nustatyta grupės organizacinė
struktūra ir kur ieškosime projektui vykdyti reikiamų specialistų.
1. Projekto grupės organizacinės struktūros planavimas
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.
61
VI. Projekto grupės planavimas (2)
1.1. Projekto sąsajos
- organizacinės;
- techninės;
- tarp darbuotojų.
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ė.
Šio dokumento pavidalas gali būti įvairus: lentelė, sąrašas, kt
Svarstymo metu iki smulkmenų išsiaiškinami sponsoriaus suteikti įgaliojimai
projekto vadovui, ypač jeigu projekto nuostatuose (project chart) jie buvo
neaiškūs arba iš viso nebuvo nurodyti. Įgaliojimai projekto vadovui samdyti ar
atleisti darbuotojus, naudoti projekto biudžeto lėšas turi būti dokumentuoti..
62
VI. Projekto grupės planavimas (3)
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.
Projekto grupės organizacinės struktūros schemos pavyzdys:
Projekto vadovas
Programavimo darbų
vedėjas
Testavimo darbų
vedėjas
Diegimo darbų
vedėjas
1 programuotojas
1 tikrintojas
1 diegėjas
2 programuotojas
2 tikrintojas
2 diegėjas
3 programuotojas
3 diegėjas
63
VI. Projekto grupės planavimas (4)
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.
2. Projekto grupės narių atranka
Geriausia, kai projektų vadovas apklausia pageidaujančius dirbti projekto
grupėje ir turi įgaliojimus priimti tinkančius. Tačiau dažnai jam tenka tartis su
savo organizacijos funkcinių padalinių vadovais, prašydamas skirti atitinkamos
specialybės darbuotoją į projekto grupę.
64
VI. Projekto grupės planavimas (5)
2.1. Pretendentų į projekto grupę apklausa
Jei jūsų organizacija yra matricos arba projektinio tipo, projekto vadovas turi
daugiau galių pasirenkant darbuotojus. Numatomiems pokalbiams su
pretendentais į projekto grupę reikėtų parengti klausimus:
a) apie darbo įgūdžius:
- kokia asmens kvalifikacija ir patirtis 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.
Priklausomai nuo projekto specifikos, galimi ir kitokie klausimai.
65
VI. Projekto grupės planavimas (6)
2.2. Tarimasis su organizacijos funkcinių padalinių vadovais
Jeigu projekto vykdymui priimamas žmogus, kuris turi įsipareigojimų kituose
organizacijos darbuose, būtina išsiaiškinti, kiek valandų per dieną jis galės skirti
jūsų projektui.
Svarbus grupės narių atskaitomybės klausimas. Už tam tikrus rezultatus jis
turi būti atskaitingas tik vienam vadovui – organizacijos funkcinio padalinio
vadovui arba projekto vadovui.
Projekto vadovas turėtų inicijuoti pasitarimus su reikalingų funkcinių
padalinių vadovais darbuotojų skyrimo ir kitiems klausimams aptarti. Keletas
patarimų:
- su kiekvieno funkcinio padalinio vadovu tarkitės skirtingu laiku;
- sužinokite asmenis, kurie galėtų padėti jums sudarant projekto grupę;
- numatykite asmenis, kurių prašysite funkciniame padalinyje;
- pirmiausia prašykite labiausiai reikalingų žmonių.
66
VI. Projekto grupės planavimas (7)
2.3. Kiti projekto grupės sudarymo scenarijai
Projekto sponsorius gali norėti paskirti į projekto grupę tam tikrus
žmones.
Reikiamų specialistų samdymas iš išorės, jei tokių nėra jūsų
organizacijoje.
67
VII. Kokybės planavimas (1)
Projekto kokybės valdymas apima tris procesus: kokybės planavimą, veiklų
kokybei užtikrinti vykdymą ir kokybės kontrolę. Čia nagrinėjamas tik kokybės
planavimas, kurio tikslas yra įvardinti projektui tinkamus kokybės standartus ir
apibrėžti jų taikymą, kad projekte sukurtas produktas atitiktų numatytus
reikalavimus.
Svarbiausias kokybės planavimo komponentas yra organizacijoje priimtos
kokybės taisyklės (politika). Projekto vadovui reikėtų išsiaiškinti, ar toks
dokumentas yra jo organizacijoje.
1. Kokybės užtikrinimo priemonės ir būdai
Jūsų organizacijoje esančiose kokybės taisyklėse gali būti nurodytos
priemonės ir būdai, darbų kryptys ir pastangos. Tai gali būti daugelyje projektų
sutinkamos standartinės priemonės.
Pramoninių standartų ar vyriausybės teisės aktų projektų vadovai taip pat
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.
68
VII. Kokybės planavimas (2)
1.1. Kokybės-naudos analizė
Įvardinamos kokybės užtikrinimo veiklos, 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.
1.2. Lyginamoji analizė
Lyginamoji analizė (benchmarking) yra toks tikrinimo būdas, kuriame
lyginamos panašios veiklos. Naudingas, kai yra daromi turimos sistemos
pakeitimai ar naujinimai (upgrade).
69
VII. Kokybės planavimas (3)
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ą, nustatyti kontrolinius taškus, kur
reikėtų įvertinti tam tikrų darbų rezultatų kokybę ir tik po jų patikrinimo daryti
kitus darbus.
1.4. Kokybės kaina
Kokybės kaina yra visų kokybės užtikrinimo darbų kaina:
- prevencinė (planavimas, darbuotojų mokymas, modulių tikrinimas);
- įvertinimo (sukurto produkto apžiūra, testavimas, kokybės auditas;
- neatitikimų šalinimo.
70
VII. Kokybės planavimas (4)
2. Kokybės valdymo planas
Šiame plane surašomi visi projekte kuriamo produkto kokybei užtikrinti
reikalingi darbai, procedūros, tikrinimo būdai ir tiems darbams atlikti reikalingi
ištekliai.
Tikrinimo būduose nurodomos 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 - kompaktiškumą, veikimo greitį,
tikslumą, 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.
Testavimo darbams gali būti samdomos nepriklausomos organizacijos. Taip
elgiamasi dideliuose IT projektuose.
71
VII. Kokybės planavimas (5)
Kriterijai. Jei projektas buvo skaidomas į etapus, tai etapų rezultatams
įvertinti gali būti naudojami ir kokybės kriterijai. Tokiu atveju 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.
72
VIII. Rizikos planavimas (1)
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 - 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. IT projektuose rizikos poveikis išlaidoms gali siekti net kelis šimtus
procentų.
Rizikos planavimas – tai veiksmų numatymas, projekte iškilus nenumatytoms
aplinkybėms.
73
VIII. Rizikos planavimas (2)
1. Rizikos veiksnių įvardinimas
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ė.
Lokalieji rizikos veiksniai yra susiję su tam tikrais projekto etapais arba su
tam tikrais projekto darbais.
74
VIII. Rizikos planavimas (3)
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 įranga, kurią naudosite užduočiai vykdyti?
75
VIII. Rizikos planavimas (4)
2. Rizikos analizė
Rizikos analizės metu aiškinamasi, kurie įvardinti rizikos veiksniai yra
pavojingiausi projektui, ir jie surikiuojami prioritetų tvarka.
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 apskaičiuoti, jos poveikį projekto tikslams ir padarinius
visam projektui.
Modernūs 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.
76
VIII. Rizikos planavimas (5)
Kokybinės analizės metu įvardinti rizikos veiksniai charakterizuojami
tikimybe ir galimo neigiamo poveikio dydžiu projektui. Tikimybė ir poveikis
dažniausiai nurodomi taip: aukštas, vidutinis arba žemas. Laikantis tokio
vertinimo, sudaroma visų įvardintų rizikos veiksnių apibūdinimo lentelė.
Rizikos veiksnių apibūdinimo lentelės pavyzdys:
Tikimybė
Aukšta
Poveikis
Vidutinė
Žema
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
---
---
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.
77
VIII. Rizikos planavimas (6)
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 rizikingus darbus.
- rizikos nukreipimas kitiems. Atsakomybė už riziką perkeliama trečiosioms
šalims;
- rizikos mažinimas. Rizikos veiksnių tikimybės ir poveikio dydžio
mažinimas;
- rizikos prisiėmimas. Paprastai prisiimama žemesnio prioriteto rizika arba
taip elgiamasi, kai nėra kitos išeities.
78
VIII. Rizikos planavimas (7)
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:
- 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?
79
VIII. Rizikos planavimas (8)
3.2. Veiksmai nenumatytais atvejais
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?
80
VIII. Rizikos planavimas (9)
Projekto rizikos valdymo planas gali būti, pvz., toks:
Rizikos
veiksnys
Tikimybė
Poveikio
dydis
Galimos
pasekmės
Prevencinės arba
nenumatytų atvejų
priemonės
Veiksnys Nr. 1
Auš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.
81
IX. Komunikacijų planavimas (1)
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.
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.
82
IX. Komunikacijų planavimas (2)
1. Komunikacijų strategija
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.
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.
83
IX. Komunikacijų planavimas (3)
Projekto komunikacijų plano pavyzdys:
Su kuo
komunikuojam
Projekto grupė
Projekto
sponsorius
Subrangovai
Komunikacijų
tikslai, klausimai
Komunikacijų būdas
Projekto tikslai,
Darbų grafikas,
kontroliniai taškai, grupės susirinkimai,
rizika, kt.
kontrolinis sąrašas
Projekto eiga,
Projekto ataskaita
Rizika
Kontrolinis sąrašas
Finansai
Biudžeto suvestinė
Kontroliniai
taškai, finansai
Darbų ataskaita
Darbų eiga
Telefonu
Atsakingas
asmuo
Komunikacijų
dažnumas
Projekto
vadovas
Kas savaitę
Projekto
vadovas
Kas savaitę
Funkcinės
grupės vedėjas
Projekto
sponsorius
Projekto
vadovas
Kas mėnesį
Kas mėnesį /
kas ketvirtį
Kas savaitę /
kai reikia
Kita
84
IX. Komunikacijų planavimas (4)
2. Komunikacija su projekto grupės nariais
Projekto vadovo pagrindinis darbas yra palaikyti ryšį su grupės nariais,
užtikrinti, kad visi žinotų projekto tikslus ir savo indėlį į rezultatą.
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 svarbu mokėti pasirinkti bendravimo su kiekvienu grupės
nariu stilių. Neformaliems kontaktams vieni grupės nariai gali labiau mėgti el.
paštą, kiti – telefoninius pokalbius.
85
IX. Komunikacijų planavimas (5)
3. Komunikacija su akcininkais
Kad galėtume parengti komunikacijų su kitais akcininkais planą, visų pirma
reikia sužinoti kas jie yra. Prisiminkime, kad akcininku yra tas, kas vienaip ar
kitaip priklauso nuo projekto rezultatų.
Jeigu akcininko atsakingasis atstovas gerai nesupranta, kokią įtaką projektas
turės jų organizacijai, būtina su juo susisiekti ir paaiškinti visa tai. Atstovas gali
būti labai užimtas ir todėl neskiria reikiamo dėmesio į jūsų projektą. Žinodami,
kad atstovas gali skirti jums tik 5 minutes laiko, labai svarbu išnaudoti šį laiką
protingai.
Naudinga parengti projekto pristatymo planą, kuriame būtų:
- nurodyti tuos projekto plano aspektus, kuriuos norite pristatyti;
- išvardinti žinomą arba tikėtiną projekto naudą akcininkui;
- apibrėžti pagrindinę informaciją, būtiną akcininkams.
86
IX. Komunikacijų planavimas (6)
Projekto, skirto naujai viešųjų pirkimų sistemai sukurti, pristatymo
akcininkams plano pavyzdys. jame parodyti trys projekto pristatymo variantai.
Bendroji projekto
apžvalga
(5 minutės)
Pagrindinių projekto
punktų pristatymas
(30 minučių)
Detalus projekto
pristatymas
(1-2 valandos)
Kodėl (vykdomas Platus produkto
projektas) 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ų
plėtimas ir gerinimas.
Mokymų nauda
Sistemos funkcijų
detalės. Sistemos
demonstracija
Kaip (pasieks
projekto tikslus)
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, klientų
aptarnavimas
87
X. Pirkimų planavimas (1)
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.
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.
88
X. Pirkimų planavimas (2)
1. Kurti patiems ar pirkti?
Sprendimui kurti patiems ar pirkti paslaugas arba gatavą produktą priimti
įtakos turi nemažai veiksnių.
Įranga. Jei yra kuriama nauja programų sistema ir jai įdiegti reikia aparatinės
įrangos (AĮ, hardware), tokią AĮ galima pirkti iš kitos organizacijos arba
nuomoti. Tik būtina atsižvelgti į įvairias aplinkybes: sukurtos sistemos gyvavimo
trukmę, ar AĮ reikės dalintis su kitais, kt.
Darbuotojų samdymas. Žmonės iš išorės gali būti samdomi visam projektui
vykdyti arba tik atskiriems projekto darbams atlikti. Tačiau reikėtų vengti
samdyti visus programuotojus, kad įvykdytumėte projektą. Galvokim ir apie
būsimą sistemos priežiūrą.
Kitos prekės ar paslaugos. Pvz., gali būti geriau pirkti mokymų paslaugas,
nepriklausomus testuotojus. Patiems susikurti tam reikiamą infrastruktūrą gali
neapsimokėti.
89
X. Pirkimų planavimas (3)
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. Šių
žinių dažnai prireikia ir projektų vadovams.
Dažniausiai sutinkami šių trijų kategorijų sandoriai:
- fiksuotos kainos. Geriausia naudoti tada, kai yra gerai apibrėžtas kuriamas
produktas ir yra nemažai informacijos iš ankstesnių panašių projektų;
- išlaidas padengiantieji. Jie pirkėjams yra rizikingiausi, nes nežino
galutinės kainos. Tačiau 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ę;
- laiko ir medžiagų apmokėjimo. Naudojami įdarbinant papildomus
žmones, kai specifiniams projekto darbams atlikti prireikia specialistų.
90
X. Pirkimų planavimas (4)
3. Darbo užduotis tiekėjams
Darbo užduotyje (SOW – Statement Of Work) detaliai aprašomos prekės arba
paslaugos, kurias jūs norite pirkti.
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.
Netgi jei darbo užduotį yra rengęs kitas organizacijos departamentas (pvz.,
pirkimų), projekto vadovas turi užtikrinti projekto reikalavimų tikslumą.
Daug kompanijų turi šablonus darbo užduotims rengti. Tai priemonė,
padedanti perteikti tiekėjams išsamią informaciją.
91
X. Pirkimų planavimas (5)
4. Prašymas tiekėjams teikti pasiūlymus
Prašymo teikti pasiūlymus (RFP – Request For Proposal) esmė yra gauti
tiekėjų pasiūlymus užduotyje nurodytiems darbams atlikti.
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.
5. Tiekėjų atrankos kriterijai
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. Pvz., galimi tokie kriterijai:
- visa pasiūlymo kaina;
- 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.
92
XI. Projekto bendrojo plano rengimas (1)
1. Kas yra projekto planas?
Projekto planas yra dokumentas, kuriame sujungti visi planavimo duomenys.
Projekto vadovas naudos jį kaip vadovą darbų eigai stebėti. Apskritai, projekto
planas laikas nuo laiko yra peržiūrimas ir koreguojamas.
Projekto planas yra visų darbų eigos stebėjimo ir reikiamų korekcijų darymo
pagrindas.
2. Projekto plano sudėtis
Dažniausiai projekto plane yra tokios dalys:
- bendroji. Pateikiama informacija apie organizaciją ir patį projektą;
- suplanuoti dalykai. Talpinami visi planavimo rezultatai;
- šablonai ir kontroliniai sąrašai. Naudojami projekto valdyme;
- šaltinių nuorodos;
- priedai.
93
XI. Projekto bendrojo plano rengimas (2)
2.1. Bendroji dalis
Šioje dalyje paprastai būna tokie skyriai:
- informacija apie dokumentą. Nurodoma informacija apie dokumento
naujinimus ir priežiūrą, versijų numeriai ir peržiūrų datos, kontaktinė
informacija;
- turinys. Atspindima dokumento organizacinė struktūra – dalys, skyriai,
poskyriai ir nuo kurio puslapio jie yra dokumente.
2.2. Suplanuoti dalykai
Tai pagrindinė projekto plano dalis. Jos pagrindiniai skyriai:
- santrauka (executive summary). Trumpai pristatomi projekto nuostatai
(verslo poreikiai, kodėl buvo pradėtas projektas, projekto tikslai);
- reikalavimai. Projekto funkciniai, techniniai ir verslo reikalavimai, kurie
buvo suformuluoti projekto inicijavimo etape;
94
XI. Projekto bendrojo plano rengimas (3)
- apimtis. Pateikiamos projekto ribos, atitinkančios klientų sutartus
siekiamus rezultatus;
- akcininkai. Sąrašas asmenų, atsakingų už projekto rezultatus - sponsorius,
klientai, projekto vadovas, projekto grupės nariai, kt.;
- reikiami ištekliai. Išvardinami ne žmoniškieji ištekliai, 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;
- 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šų;
95
XI. Projekto bendrojo plano rengimas (4)
- biudžetas. Nurodoma tik visa projekto kaina arba išskaidyta į 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 eigos stebėjimo
klausimai;
- komunikacijos. Nurodomas komunikacijų su sponsoriumi, klientais,
projekto grupe ir kitais akcininkais būdas ir dažnumas;
96
XI. Projekto bendrojo plano rengimas (5)
- vykdymo planas. Tai 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. 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. Dėstoma, kaip bus mokomi sukurtos sistemos galiniai
naudotojai, administratoriai, pagalbos teikimo tarnyba ir kitos grupės.
2.3. Šablonai ir kontroliniai sąrašai
Kontrolinių sąrašų pavyzdžiai:
- diegimo (instaliavimo) kontrolinis sąrašas;
- testavimo kontrolinis sąrašas;
- kiti kokybės kontroliniai sąrašai.
97
XI. Projekto bendrojo plano rengimas (6)
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 ir projektų valdymo metodologija;
- kiti reikalingi reglamentai ar standartai.
2.5. Priedai
- projekto darbų grafiko kontroliniai taškai;
- projekto biudžeto kontroliniai taškai.
98
XI. Projekto bendrojo plano rengimas (7)
3. Projekto 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.
3.1. Plano rašymo organizavimas ir rašymas
Prieš pradedant rašyti projekto planą visų pirma peržiūrimi turimi
dokumentai ir numatoma jų pateikimo tvarka.
Apibrėžiamos dokumentų tvarkymo procedūros: kaip turi būti daromi
dokumento pakeitimai, kokia naujų versijų numeravimo sistema, kaip turi būti
nurodomos versijų datos ir numeriai.
Apsisprendžiama, kaip planas bus platinamas: atspausdintas popieriuje ar
elektroniniu būdu.
99
XI. Projekto bendrojo plano rengimas (8)
3.2. Plano keitimas
Plano pradinį variantą projekto vykdymo etape tenka ne kartą koreguoti.
Projekto plano keitimas yra iteracinis procesas. Projekto eigoje pakeitus
pagrindinius plano komponentus, būtina pakoreguoti įvairius plano skyrius.
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ą.
Bet kokie projekto plano pakeitimai turi būti daromi griežtai laikantis
nustatytos tvarkos. Jie turi būti daromi tik gavus oficialų patvirtinimą, išduotą
laikantis projekto apimties valdymo plane nustatytų taisyklių.
3.3. Plano peržiūra
Projekto planą peržiūri sponsorius ir akcininkai. Atviras klausimų ar interesų
aptarimas padeda parengti geresnį projekto planą. Galutinė projekto plano
peržiūra yra formali procedūra, kuria užbaigiamas projekto planavimo etapas.
100
XI. Projekto bendrojo plano rengimas (9)
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ėsena, aplinka)
11. Komunikacijos
12. Vykdymo planas
13. Priežiūros planas
14. Mokymų planas
Šablonai ir kontroliniai sąrašai
Šaltinių nuorodos
Priedai
101
XII. Projekto vykdymas (1)
Projekto vykdymo sėkmė priklauso nuo:
- sudarytos projekto grupės;
- kaip laikomasi projekto plano;
- kaip platinama projekto informacija;
- kaip valdomi sandoriai su tiekėjais.
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.
1.1. Darnios projekto grupės sudarymas ir valdymas
Grupės plėtros etapai:
a) grupės sudarymas;
b) kova dėl pareigų;
c) santykių nusistovėjimas;
d) našus darbas.
102
XII. Projekto vykdymas (2)
Darbas su projekto grupe:
1) pirmasis susirinkimas (project kickoff). Projektų vadovas turėtų prašyti
grupės narių atsakyti į tokius klausimus:
- kodėl aš esu projekto grupėje?
- kas aš ir ko iš manęs tikimasi?
- ką aš rengiuosi daryti?
- kaip darysiu savo darbą?
Geras pirmasis susirinkimas yra toks, kuriame atsakoma į šiuos klausimus ir
sukuriama bendradarbiavimo atmosfera projekto grupės nariams, akcininkams.
Keletas tokio susirinkimo 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.
103
XII. Projekto vykdymas (3)
2) Grupės darbo (performance) valdymas. Projekto vadovas turi teisę
įpareigoti grupės narius daryti darbus ir reikalauti iš jų atsakomybės už rezultatus.
Vadovas turi būti kompetentingas, gerbiamas, sąžiningas, atviras.
Valdymui svarbus yra grupės narių grįžtamasis ryšys. Darbų grįžtamasis
ryšys turi būti savalaikis.
Iškilusiems konfliktams spręsti galimi įvairūs būdai: prisiderinimas,
vengimas, gynimasis, kompromisas, bendradarbiavimas.
Dvi konfliktinės situacijos, kurios reikalauja išskirtinio dėmesio:
- grupės narių ginčai (jiems išspręsti turi įsikišti projekto vadovas);
- irzlių grupės narių, nuodijančių kolektyvo atmosferą, valdymas.
Darniai projekto grupei sukurti, jos darbo našumui didinti padeda mokymai.
104
XII. Projekto vykdymas (4)
1.2. Mokymai
Kai kuriose organizacijose kaip šalutinis tikslas gali būti projekto grupės
narių įgūdžių gerinimas arba informacijos apie naujus produktus ar procesus
rinkimas.
Jei kuriant produktą naudojama nauja ir besiplėtojanti technologija, 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.
105
XII. Projekto vykdymas (5)
1.3. Skatinimas ir pripažinimas
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, kt. Priklausomai nuo organizacijos taisyklių, skatinimas gali apsiriboti
garbės raštais ar dovanomis.
Kai žmogus skatinamas, turi būti aiškiai įvardinti darbai, už kuriuos jis
nusipelnė pagarbos.
106
XII. Projekto vykdymas (6)
2. Santykiai su kitais akcininkais
Santykiai su klientais. Klientai gali nežinoti sudėtingų programų sistemų
kūrimo plonybių, o projekto vadovas gali ne viską žinoti apie kompiuterizuojamą
veiklos sritį.
Keletas gerų santykių su klientais palaikymo principų:
- dažnas bendravimas;
- projekto grupės darbų pristatymas;
- sutarimo siekimas;
- savalaikis nutarimų vykdymas;
- lūkesčių valdymas;
- faktų valdymas.
107
XII. Projekto vykdymas (7)
Santykiai su sponsoriumi iškilus abejonėms. 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 sponsoriaus parama gali pasireikšti įvairiais
būdais.
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.
Jei sprendimo nepavyksta pasiekti, projekto vadovas turėtų nuspręsti, ar
ieškoti naujo sponsoriaus, ar rekomenduoti nutraukti projektą.
108
XII. Projekto vykdymas (8)
Santykiai su funkcinių padalinių vadovais. 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ų.
Jei atitrauktų išteklių pakeitimas kitais neturi įtakos galutiniams projekto
rezultatams, tai reikėtų sutikti su tuo, pvz., naujo žmogaus priėmimu į grupę.
Jei dėl naujo darbuotojo paieškos teks nukelti projekto įvykdymo terminą,
apie susidariusią situaciją informuokite sponsorių ir laukite jo sprendimo.
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.
109
XII. Projekto vykdymas (9)
3. Darbų vykdymas pagal planą
Geram darbų koordinavimui projekto vadovas turi rinkti duomenis apie
atliktus darbus ir lyginti juos su projekto plane numatytų kontrolinių taškų
duomenimis.
3.1. Duomenų apie projekto eigą rinkimas
Priemonės informacijai rinkti 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 ir kaip dažnai jos turi būti teikiamos (paprastai –
kas savaitę).
Darbų ataskaitos šablono pavyzdys:
Užduotis
Dirbta valandų
Liko dirbti
valandų
Atliktų darbų
procentas
Pastabos
110
XII. Projekto vykdymas (10)
Iškilusių problemų sąrašai. Spręstiniems klausimams 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škilusių problemų sąrašo šablono pavyzdys:
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.
111
XII. Projekto vykdymas (11)
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.
Išvardinkime dalykus, kuriuos projekto vadovas turėtų stebėti:
- darbų grafiko laikymasis;
- biudžeto laikymasis;
- projekto apimties laikymasis;
- tvirtinami rezultatai. Specialus dėmesys skiriamas rezultatams
kontroliniuose taškuose, kuriuos turi peržiūrėti sponsorius ar
akcininkai ir kurie turi būti tvirtinami.
112
XII. Projekto vykdymas (12)
4. Informacijos apie projekto eigą platinimas
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.
4.1. Projekto grupės susirinkimai
Susirinkimų vedimas. Produktyvus susirinkimas yra toks, kai projekto
vadovas nubrėžia tolesnes darbų gaires ir išsprendžia ginčus dėl projekto darbų.
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.
113
XII. Projekto vykdymas (13)
Susirinkimo rezultatai. Susirinkimai yra gera proga stebėti grupės narių
bendradarbiavimo lygį.
Užrašų įvairiais klausimais (issues log) peržiūra turėtų būti kiekvieno
projekto grupės susirinkimo dalis. Už kiekvieno užrašuose pasižymėto klausimo
(problemos) išsprendimą iki nurodyto laiko būna nurodytas atsakingas asmuo
(žiūr. Iškilusių problemų sąrašo šablono pavyzdį). Atsakingam asmeniui tereikia
informuoti apie esamą padėtį.
Problemų sprendimas. 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.
114
XII. Projekto vykdymas (14)
4.2. Ataskaitos apie projekto eigą
Sponsoriui, akcininkams, klientams nereikia visų detalių apie projektą, kurios
reikalingos projekto grupės nariams. Jiems reguliariai teikiamos ataskaitos apie
projekto eigą.
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.
115
XII. Projekto vykdymas (15)
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.
Apžvalgos daromos kas mėnesį ar kas metų ketvirtį. Jų rengimas gali trukti
net keletą dienų, dalyvaujant visiems su projekto vykdymu susijusiems vadovams.
Apžvelgtini klausimai:
- pagrindiniai pasiekimai einamosios apžiūros periode;
- biudžeto suvestinė;
- pagrindiniai klausimai;
- rizikos mažinimo ir reakcijos į jos veiksnius planai;
- planuojami pasiekimai kitos apžvalgos laikotarpiui.
116
XII. Projekto vykdymas (16)
5. Sandorių su tiekėjais priežiūra
Daugelyje projektų reikalinga išorinių tiekėjų pagalba. Jei yra sudaryti
sandoriai, tenka administruoti juos. Tai stebėjimas ir tikrinimas, ar tiekėjai laiku
atlieka sutartus darbus.
5.1. Tiekėjų atliekamų darbų ataskaitos
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ę.
Projekto vadovas turi įsitikinti, ar tiekėjas pateikia reikiamus duomenis ir
reikiamo pavidalo.
Kai kurie projektų vadovai organizuoja mėnesinius ar kitokio dažnumo
susitikimus su tiekėjais darbų eigai apžvelgti ir problemoms apsvarstyti.
117
XII. Projekto vykdymas (17)
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ų, dėl
platformos, kt.
Visi tokie nesutarimai turi būti svarstomi geranoriškai ir siekiama abiem
šalims priimtinų sprendimų. Nepavykus susitarti elgiamasi pagal sandoryje
išdėstytas nuostatas.
5.3. Tiekimų vėlavimai
Tiekimų vėlavimo atvejais projekto vadovas turėtų imtis tokių veiksmų:
- susitikti su tiekėju ir gauti daugiau informacijos apie tiekimo vėlavimą;
- informuoti savo organizacijos pirkimų ir teisės departamentus;
- peržiūrėti vėlavimo įtaką visam projekto planui;
- informuoti sponsorių ir akcininkus.
118
XII. Projekto vykdymas (18)
5.4. Atsiskaitymai su tiekėjais
Sandoriuose su tiekėjais nurodoma, kaip su jais bus atsiskaitoma.
Jei tiekėjui turi būti mokama remiantis darbų grafike numatytais rezultatais,
projekto vadovas turi patvirtinti tų rezultatų gavimą ir priėmimą. Turi būti
peržiūrėta ir patikrinta tiekėjo pristatytos produkcijos kokybė ir tik tada
tvirtinamas mokėjimas.
5.5. Reikalų su tiekėjais tvarkymas
Dalykiški santykiai. Sandoryje numatyti, bet darbų užduotyje (SOW) gerai
neapibrėžti darbai turi būti svarstomi ir aiškiai nurodomi trūkumai, įvardinamos
problemiškos sritys, dėl ko tiekėjas nenori toliau tęsti darbų.
Į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.
119
XIII. Projekto kontrolė (1)
1. Integruotoji keitimų kontrolė
Nukrypimai nuo projekto plano gali būti perspėjimas, kad reikia daryti
pradinio (originalaus) plano korekcijas.
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ą.
1.1. Projekto apimties keitimo kontrolė
Projekto apimties plano viena iš dalių yra apimties valdymo planas.
Apimties keitimo kontrolė yra bet kokių projekto apimties keitimų valdymas ir
dokumentavimas laikantis valdymo plano.
120
XIII. Projekto kontrolė (2)
Keletas priežasčių, verčiančių keisti projekto apimtį:
- projekto rezultatų peržiūros metu pastebėta, 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;
- pasikeitė kuriamo produkto projektas (design).
Projekto apimtis neturėtų būti keičiama be formalaus patvirtinimo (leidimo).
Keletas projekto apimties keitimo žingsnių ir patarimų:
- naudokime standartinės formos prašymą 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, 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ą.
121
XIII. Projekto kontrolė (3)
Projekto apimties keitimai gali iššaukti koregavimo veiksmus ir/ar
kontrolinių taškų projekto plane keitimą.
Koregavimo veiksmai. Ieškoma kelių, kaip sugražinti projektą į ankstesnes
vėžes. Aiškinamasi, kodėl buvo nukrypta nuo planuotos projekto apimties ir ko
reikėtų imtis, kad tai neatsitiktų ateityje.
Kontrolinių taškų derinimas. Bet koks projekto apimties keitimas reikalauja
pakoreguoti projekto planą. Priklausomai nuo keitimų dydžio, gali tekti keisti
darbų grafiko ir biudžeto kontrolinius taškus.
1.2. Darbų grafiko kontrolė
Darbų grafiko kontrolė yra bet kokio darbų grafiko keitimo ir tokių keitimų
dokumentavimo procesas. Projekto grupės narių ir kitos ataskaitos visų pirma
naudojamos kritinio kelio darbų eigai įvertinti.
Darbų grafiko kontrolės rezultatai – tai grafiko naujinimai, kitų projekto
elementų korekcijos, įgyta patirtis.
122
XIII. Projekto kontrolė (4)
1.3. Išlaidų kontrolė
Tai procesas, kurio metu tikrinamos padarytos išlaidos, nustatomi nukrypimai
nuo biudžeto kontrolinių taškų, imamasi reikiamų korekcijų.
Išlaidų kontrolės rezultatas – peržiūrėti kainų įverčiai, kitų projekto elementų
korekcijos, įgyta patirtis.
1.4. Kitų projekto plano elementų keitimo kontrolė
Projekto apimtis, darbų grafikas, biudžetas yra pagrindiniai kontrolės
taikiniai. Be jų taip pat gali keistis kitų projekto plano elementų duomenys:
išteklių, reikalavimų, infrastruktūros ir konfigūracijos.
Išteklių keitimas. Keičiantis darbuotojams, būtina užfiksuoti naujo žmogaus
pavardę, pasikeitimo poveikį projektui.
Reikalavimų keitimas. Jei reikalavimai yra papildomi naujais arba keičiami
gerinant jų aiškumą, būtina įsitikinti, ar tai neturi įtakos projekto apimčiai. Bet
koks naujas reikalavimas turi praeiti keitimų kontrolę.
123
XIII. Projekto kontrolė (5)
Infrastruktūros keitimas. Infrastruktūra – tai tokie elementai, kurie ilgai
išlieka pabaigus projektą. Pvz., UNIX keičiant į 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.
Konfigūracijos keitimas. Įrangos konfigūracija keičiama tada, kai
pastebima, jog sukurtas produktas geriau dirbtų kitaip sukonfigūruotoje aplinkoje.
Konfigūracijos keitimas nėra didelė kliūtis projektams. Tik kai kurie
konfigūracijos keitimai reikalauja iš naujo pakrauti (reboot) sistemą ir todėl
rezultatai tampa prieinami tik po kažkurio laiko.
124
XIII. Projekto kontrolė (6)
2. Kokybės kontrolė
Kokybės kontrolės metu stebima, ar projekto rezultatai atitinka nustatytų
standartų reikalavimus, ar nereikia daryti keitimų, kad būtų pašalintos neigiamą
poveikį kokybei darančios priežastys. Kokybės valdymo planas yra specifinių
kontrolės veiklų pagrindas.
Kokybės tikrinimo veiklos yra svarbios projekto etapų užbaigimui
patvirtinti. Patikrinus kokybę, galimi tokie tolesni žingsniai: užduoties atlikimas iš
naujo, keitimų darymas, rezultatų priėmimas, nežiūrint, kad yra kai kurių defektų.
Yra įvairios kokybės tikrinimo priemonės ir būdai.
2.1. Tikrinimas (testavimas)
Tikrinimas yra plati sąvoka, apimanti apžiūrą, matavimą, testavimą.
IT projektuose tikrinimas dažniausiai vadinamas testavimu.
125
XIII. Projekto kontrolė (7)
IT projektams bendros yra šios testavimų rūšys:
- modulių testavimas;
- modulių rinkinio (unit) testavimas;
- sistemos testavimas;
- tinkamumo naudotojams testavimas (UAT – User Acceptance Testing).
Nedidelis naudotojų ratas kažkurį laiką tikrina, ar sistema yra tokia,
kokios tikėtasi;
- tinkamumo įmonei testavimas (FAT – Factory Acceptance Testing).
Dideles sistemas testuoti yra geriausia tose vietose, kur jos buvo sukurtos.
Išbandoma pas kūrėją ir tik po to perkeliama į užsakovo nurodytą vietą;
- tinkamumo konkrečiai vietai testavimas (Site Acceptance Testing).
Sistema testuojama įdiegus ją užsakovo nurodytoje vietoje. Nors ji buvo
išbandyta kūrėjo aplinkoje, tačiau dar patikrinama, kaip sistema veikia
užsakovo aplinkoje.
126
XIII. Projekto kontrolė (8)
Kai kuriais atvejais reikia sudėtingesnių testavimų:
- modulius kuria geografiškai išbarstyta projekto grupė. Betarpiškų
asmeninių kontaktų nebuvimas gali būti skirtingo supratimo, modulių
nesuderinamumo priežastimi. Tokiais atvejais reikėtų detalesnio kiekvieno
modulio testavimo;
- produktus pristato tiekėjai. 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.
2.2. Kiti kokybės kontrolės būdai ir priemonės
Pareto diagrama. Ji naudojama projekte kylanč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%
gyventojų. Šis principas buvo perkeltas į daugelį disciplinų. Kokybės kontrolėje
laikoma, kad 80% defektų priežastis yra 20% kylančių problemų. Taip pat
manoma, kad 80% projekto darbų padaro 20% projekto grupės narių.
127
XIII. Projekto kontrolė (9)
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.
Pareto diagramos pavyzdys:
Suvestinis
defektų
procentas
100%
Defektų
dažnumas
1000
75%
750
50%
500
25%
250
A
B
C
D
E
Problema
Dažniausiai iškylančios problemos yra A ir B (pvz., A problema – prasti
programavimo įgūdžiai). Išsprendus vien tik jas, būtų atsikratyta apie 60% visų defektų.
128
XIII. Projekto kontrolė (10)
Kontrolinės diagramos. Jos yra naudojamos kontroliuojamo parametro
svyravimams laike pavaizduoti. Dažniausiai sutinkamos apdirbamojoje pramonėje.
Tokiose diagramose svarbios yra vidutinė, viršutinė ir apatinė leistinos parametro
reikšmės (pvz., tekinamos detalės diametras).
Kontrolinės diagramos pavyzdys:
5,06
Viršutinė riba
5,00
Vidutinė reikšmė
4,94
Apatinė riba
(taškas – matavimo reikšmė)
129
XIII. Projekto kontrolė (11)
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ę.
Projekto struktūrinė (blokinė) schema ir proceso diagrama. Taip
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.
130
XIII. Projekto kontrolė (12)
2.3. Veiksmai kokybės neatitikimo atvejais
Perdarymas. Tam reikia laiko ir lėšų, todėl gali tekti daryti projekto darbų
grafiko ir biudžeto pakeitimus.
Projekto 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. 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).
131
XIII. Projekto kontrolė (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.
Dokumentai naudotojams. On-line būdu teikiamos ar spausdintinės
instrukcijos sistemos naudotojams turi būti parengtos kruopščiai.
Naudotojų mokymo medžiaga. Sukurtos sistemos naudotojams mokomoji
medžiaga, įskaitant demonstracines priemones, turi būti apgalvota, suprantama ir
tinkamai parengta.
Pagalbos teikimo (help-desk) medžiaga. Neaiškumų naudotojams
atvejais pagalbos teikimo tarnybų naudojama medžiaga turi būti kokybiška.
Dokumentai priežiūros grupėms. 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.
132
XIII. Projekto kontrolė (14)
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ę.
3.1. Standartai
Standartų besilaikančios IT įmonės pasiekia geresnių rezultatų. Pvz., kuriant
programinę įrangą paprastai laikomasi tokių standartų:
- naujos programos rašomos taip, kad joms leisti pakaktų XML naršyklės;
- naujose programose naudojamos Web funkcijos, o ne savos funkcijos;
- naujose programose perduodant duomenis klientui naudojamas SOAP
(Simple Object Access Protocol) protokolas ( OSI modelio transporto
lygmens standartų rinkinys).
Taip įgyjamos geresnės galimybės kontroliuoti naują programinę įrangą
plačiame naudotojų rate.
133
XIII. Projekto kontrolė (15)
IT projektų vadovai turėtų sukviesti visus akcininkus ir išsiaiškinti, ar
numatomi diegti standartai visiems yra priimtini. Tai galėtų būti:
- 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 protokolus.
3.2. Standartų organizacijos
ISO (International Standards Organization) – tarptautinė standartizacijos
organizacija. Kokybės kontrolei įmonės naudoja ISO 9000 standartą.
DMTF (Distributed Management Task Force) standartų organizacija rengia
sistemų valdymo standartus.
IEEE (Institute of Electronic and Electric Engineers) yra parengusi plačiai
žinomus tinklų protokolus.
ANSI (American National Standards Institute). Ji mums įdomi tuo, kad
parengė projektų valdymo žinyną [PMBOK].
LST – Lietuvos standartizacijos departamentas. Perima kitų standartus.
134
XIII. Projekto kontrolė (16)
3.3. Projektų valdymo kokybės gerinimas
Yra daug būdų projektų kokybei gerinti. Visada reikėtų įvertinti savo
organizacijos galimybes vykdyti projektus aukštu lygiu. Tam galėtų pasitarnauti
CMM (Capability Maturity Model) modelis.
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). Projektai dažnai vykdomi neorganizuotai,
neturint formalių planų ar taisyklių. Veiklos neapibrėžtos, nekontroliuojamos.
2 lygis – kartojamasis (repeatable). Organizacijoje yra numatyta tam tikra
projektų vykdymo tvarka, padedanti vertinti kainą, rengti darbų grafiką, vertinti
rezultatus. Ši tvarka kartojama kiekvieno projekto metu, tačiau ji tobulintina.
135
XIII. Projekto kontrolė (17)
3 lygis – apibrėžtasis (defined). Projektų vykdymo procesas yra apibrėžtas
ir standartizuotas. 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šį.
Projektų vykdymui aukštu kokybės lygiu būtina suprasti savo organizacijos
galimybes valdyti projektus, diegti plačiai žinomus standartus.
136
XIII. Projekto kontrolė (18)
4. Rizikos valdymo kontrolė
Rizikos valdymas – tai procesas, kurio metu atliekami reakcijos į rizikos
veiksnius veiksmai. Šis procesas nėra vien projekto plane įvardintų rizikos
veiksnių stebėsena. Jo metu taip pat vertinamas reakcijos veiksmų efektyvumas,
įvardijami naujai atsirandantys rizikos veiksniai.
Rizikos valdymas turi glaudų ryšį su projekte iškylančių problemų valdymu.
Problemos turi būti sprendžiamos, vertinama jų sprendimo eiga, keliamos naujos.
4.1. Reakcijos į rizikos veiksnius rezultatų valdymas
Prevencinės (profilaktinės) priemonės. Rizikos veiksniams išvengti ar
sušvelninti yra įvairūs būdai, pvz., naujų užduočių įtraukimas į darbų grafiką.
Atsitikus rizikos veiksniui atliekami projekto plane numatyti veiksmai ir
vertinama, kaip tie veiksmai padeda pašalinti arba sumažinti rizikos veiksnio įtaką
projektui. Jei jie nesumažina rizikos, peržiūrimas reakcijos į rizikos veiksnį būdas
ir rizika prisiimama arba imamasi naujo reakcijos būdo.
137
XIII. Projekto kontrolė (19)
Veiksmai nenumatytais atvejais. Rizikos planas nenumatytais atvejais
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.
4.2. Naujų rizikos veiksnių įvardijimas
Kai kurie projekto planavimo etape į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į.
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ą veiksmų keitimas gali iššaukti projekto
apimties, darbų grafiko ir biudžeto keitimą. Todėl reakcijos į riziką veiksmų
keitimo procedūra turi būti panaši, kaip ir darant kitokius projekto pakeitimus.
138
XIII. Projekto kontrolė (20)
4.3. Problemų sprendimo valdymas
Problemų valdymas yra labai panašus į rizikos valdymą, nes taip pat turi būti
imamasi atitinkamų veiksmų.
Problema tai ne rizika. Problema - tai uždavinys, reikalaujantis tyrimo,
sprendimo. Rizika - tai tik nepageidaujamas dalykas, kuris gali atsitikti, bet gali ir
neatsitikti.
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 net mėnesius. Todėl sąraše visada reikėtų registruoti
problemas, jų sprendimo planą, atsakingą asmenį, numatomą išsprendimo datą.
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ą.
139
XIII. Projekto kontrolė (21)
4.4. Projektas pavojuje
Kartais reakcijos į riziką ar problemų sprendimo veiksmai gali neduoti
norimų rezultatų arba pagimdyti naujus, sunkiai suvaldomus rizikos veiksnius.
Tokiais atvejais reikia kreiptis į sponsorių ir tartis, ką gi reikėtų daryti.
Laiku neinformavus apie projekto sunkią padėtį, sponsorius taip pat gali
nebeturėti galimybių pagelbėti.
Jeigu yra problemų su jūsų organizacijos kažkuriuo 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ų arba
naujos strategijos jūsų organizacijoje projektas tapo neperspektyvus. Tokiais
atvejais reikėtų rekomenduoti sponsoriui nutraukti projektą.
140
XIII. Projekto kontrolė (22)
5. Projekto eigos kontrolė
Projekto 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ų.
5.1. Darbų ataskaitos
Ataskaitose turi būti problemų analizė ir jų įtakos projektui įvertinimas.
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 programinė įranga (pvz., Microsoft Project) 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.
141
XIII. Projekto kontrolė (23)
Tendencijų analizė. Jau nuveikti darbai gali įnešti aiškumo, ko galima
tikėtis atliekant būsimus. Tendencijų analizė yra pagrįsta matematiniais
skaičiavimais ir naudojama prognozuoti, ar darbų atlikimas gerės ar blogės.
Viso projekto kainos tikslinimas. Atlikus dalį projekto darbų, atsiranda
galimybė tiksliau įvertinti viso projekto kainą, nei projekto pradžioje.
Tokiam įverčiui suprasti reikia žinoti šias sąvokas:
AC (actual cost) - tĩkrosios (faktinės) projekto išlaidos iki duoto laiko;
ETC (estimate to complete) - nuo duoto laiko iki projekto pabaigos
likusių darbų kainos įvertis;
EAC (estimate at completion) - viso projekto patikslintos kainos įvertis duotu
laiku. Jis gaunamas remiantis jau atliktų ir likusių darbų informacija:
EAC = AC + ETC;
BAC (budget at completion) - viso projekto kainos įvertis projekto pradžioje.
VAC (variance at completion) - skirtumas tarp EAC ir BAC yra duotu laiku
patikslintos projekto kainos nukrypimas nuo projekto pradžioje įvertintos projekto
kainos.
142
XIII. Projekto kontrolė (24)
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ą. Tiems skaičiavimams suprasti labiausiai reikalingos sąvokos yra:
AC (actual cost) - tĩkrosios (faktinės) projekto išlaidos iki duoto laiko, ACWP;
EV (earned value) - iki duoto laiko atliktų darbų vertė, BCWP;
PV (planned value) - projekto biudžete duotam laikotarpiui skirta suma, BCWS.
Nuokrypiai. Rodo skirtumą tarp suplanuoto projekto biudžeto ir tikrųjų
išlaidų duotu laiku.
CV (cost variance) - išlaidų nuokrypis. Jis apskaičiuojamas taip:
CV = EV – AC.
SV (schedule variance) - darbų nuokrypis. Jis apskaičiuojamas taip:
SV = EV – PV.
Neigiamos CV ir SV reikšmės rodo, kad yra problemų.
143
XIII. Projekto kontrolė (25)
Indeksai (santykiai). Indeksai atspindi santykius tarp biudžeto komponentų.
Jie yra lengvai apskaičiuojami ir ypač naudingi. Jei santykio reikšmė yra didesnė
už 1, tai projekto darbų vykdymas lenkia darbų grafiką arba projekto biudžetas
neviršytas. Jei santykis yra mažesnis už 1, tai atsiliekama nuo darbų grafiko arba
išlaidos viršija numatytąsias projekto biudžete.
Santykiai gali būti išreiškiami procentais, nes tai gali būti patogiau. Pvz.,
indekso reikšmė 0,94 atitinka 94%.
CPI (cost performance index) - išlaidų indeksas. Atspindi projekto biudžeto
išlaidų panaudojimo efektyvumą. Jis apskaičiuojamas taip:
CPI = EV / AC .
Jei CPI<1, tai išlaidos panaudotos neefektyviai, jei CPI>1, tai išleista pinigų
mažiau, nei tikėtasi.
144
XIII. Projekto kontrolė (26)
SPI (schedule performance index) - darbų indeksas. Tai iki duotos datos
atliktų darbų ir darbų grafike suplanuotų darbų kainų santykis:
SPI = EV / PV .
Jei SPI<1, tai atsiliekama nuo darbų grafiko, jei SPI>1, tai darbams sugaišta
mažiau laiko, nei tikėtasi.
TCPI (to-complete performance index) - darbų tęstinumo indeksas. Tai
likusių darbų kainos ir likusių biudžeto lėšų santykis išreikštas procentais.
TCPI = (likusių darbų kaina) / (likusios biudžeto lėšos),
(likusių darbų kaina) = BAC – EV , (likusios biudžeto lėšos) = BAC – AC ,
BAC (budget at completion) - 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.
145
XIII. Projekto kontrolė (27)
5.2. Akcininkų valdymas
Projekto vadovas yra atsakingas už akcininkų informavimą apie projekto
eigos nukrypimus, už nukrypimų poveikio projektui įvertinimą ir rekomendacijų,
ką reikėtų daryti, parengimą. Tenka daryti kompromisus, norint rezultatyviai
užbaigti projektą. Kartais nelieka prasmės tęsti projektą, ir dėl jo nutraukimo gali
reikėti oficialaus akcininkų sutikimo.
Pranešimai apie projekto nukrypimus. Pojekto eigoje būtina
informuoti akcininkus apie bet kokius nukrypimus, kurie gali turėti įtakos projekto
rezultatams. Projekto stoviui, analizės rezultatams pristatyti rengiamos diagramos
ar lentelės. Kai kurios diagramos ir ataskaitos gali būti parengtos naudojant
projektų valdymo programinę įrangą.
146
XIII. Projekto kontrolė (28)
Kompromisų valdymas. 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 ir papildomos lėšos ir laikas tiems reikalavimams įgyvendinti.
Daugiau darbų padaryti per tokį pat laiką ir už tokią pat kainą galima tik darbų
kokybės sąskaita, trumpinant arba iš viso atsisakant rezultatų testavimo.
Visada reikėtų išklausinėti akcininkus, kad išsiaiškintume, ko jie siekia
prašydami keisti projekto apimtį.
147
XIII. Projekto kontrolė (29)
Kompromisas dėl darbų grafiko. Darbų atlikimo vėlavimo priežastys gali
būti įvairios nelaimės, įrangos gedimai, padarytos klaidos. 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 užtraukti baudas arba
teisines sankcijas. Prieš rekomenduojant atidėti projekto pabaigos terminą, reikia
būt pasvėrus, kas yra geriau.
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.
148
XIII. Projekto kontrolė (30)
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.
Jei 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.
Išlaidas galima taupyti 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ą.
149
XIII. Projekto kontrolė (31)
Projekto nutraukimas. Kai kuriais atvejais projekto nutraukimas gali būti
geriausias sprendimas. Esant nepakankamam finansavimui ar trūkstant darbuotojų,
geriau nutraukti projektą. Sunkios situacijos, kurioms išvengti nėra tinkamų
sprendimų, gali susidaryti 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 projektas vis dar turi prasmę.
150
XIV. Projekto užbaigimas (1)
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: viso projekto administracinis
užbaigimas ir sandorių užbaigimas.
1. Projektų nutraukimo priežastys
Ne visi projektai būna sėkmingi. Jų užbaigimo (nutraukimo) priežastys gali
būti įvairios:
- rezultatų stoka. 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;
- išteklių stoka. Tokia situacija gali susidaryti dėl netinkamų įverčių
planavimo etape arba jūsų projektui skirti ištekliai perkeliami kitam.
151
XIV. Projekto užbaigimas (2)
2. Sandorių užbaigimas
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ė.
Visų užbaigtų sandorių dokumentų kopijas reikėtų dėti į archyvą ir saugoti
ateičiai.
3. Administraciniai projekto baigiamieji darbai
Užbaigus projektą reikia atlikti dar keletą svarbių darbų:
- perduoti projekto duomenis į archyvą;
- sutvarkyti formalius projekto rezultatų priėmimo dokumentus;
- visapusiškai peržiūrėti projektą (ką išmokome, kokią patirtį įgijome);
- perduoti projekto rezultatus naudotojams;
- atleisti projekto grupės narius.
152
XIV. Projekto užbaigimas (3)
3.1. Projektų archyvo tvarkymas
Projekto eigoje 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ą.
Prieš atiduodant savo projekto dokumentus į biblioteką ar archyvą, reikia
pasidomėti, kaip dokumentai turėtų būti sutvarkyti.
3.2. Formalus projekto rezultatų priėmimas
Galutinių projekto rezultatų peržiūros tikslas yra gauti akcininkų pritarimą ir
parašus bei oficialiai paskelbti projekto pabaigą.
Projekto vadovas turi išsiaiškinti, kieno parašų reikės.
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.
153
XIV. Projekto užbaigimas (4)
3.3. Visapusiška projekto peržiūra (gautos pamokos)
Užbaigto projekto vertinimas turėtų padėti atskleisti dalykus, kurių
išmokome, kokias pamokas gavome. Galbūt tai padės geriau valdyti kitus
projektus.
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).
154
XIV. Projekto užbaigimas (5)
3.4. Projekto rezultatų perdavimas naudotojams
Sukurtą sistemą dažniausiai eksploatuoja ir prižiūri kiti žmonės. Todėl
projekto grupė turi perduoti ją būsimiems naudotojams, perduoti sistemos
priežiūros dokumentus ir įrankius. Jų atnaujinimas jau bus priežiūros grupės
atsakomybė.
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.
Kadangi būtina laikytis darbo sutarties terminų ir žmoniškųjų išteklių
taisyklių, projekto grupės nariai turėtų būti informuoti apie galimą atleidimo datą.
155
XV. Lankstieji metodai (1)
Programų sistemų kūrimo lankstieji metodai (agile metodai) naudotini tais
atvejais, kai programų sistemų kūrimo projektai yra sunkiai valdomi, dažnai
keičiasi reikalavimai.
Lanksčiuoju metodu sudėtingi (ilgalaikiai) projektai skaidomi į paprastesnius
(trumpos trukmės) 2-3 žmonių atliekamus projektus. Taip sumažinama sudėtingo
projekto įvykdymo rizika.
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
greitai prisitaikyti prie kintančių reikalavimų, geriau valdyti rizikos veiksnius.
Pagrindinis lanksčiojo metodo skirtumas nuo tradicinių (krioklio, spiralės
modeliai) modelių yra orientacija į principus, o ne į procesą. Visa tai yra išdėstyta
vadinamajame Agile manifeste. Susipažinkime su jais.
156
XV. Lankstieji metodai (2)
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 į prašymus daryti keitimus yra svarbiau nei laikytis plano.
157
XV. Lankstieji metodai (3)
Lanksčiojo metodo principai (1):
1) klientų poreikių tenkinimas tiekiant naudingą įrangą kiek galima greičiau;
2) teigiamas požiūris netgi į projekto pabaigoje prašomus daryti 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;
158
XV. Lankstieji metodai (4)
Lanksčiojo metodo principai (2):
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 – gebėjimas nedaryti bereikalingų darbų – yra labai svarbu;
11) geriausius reikalavimus, projektus (design) ir sistemas sukuria darnios
(self-organizing) grupės;
12) nuolatinės projekto grupės pastangos didinti savo efektyvumą ir
derintis prie aplinkybių.
159
XV. Lankstieji metodai (5)
1. Grumtynės (Scrum)
Grumtynės (scrum) yra vienas iš lanksčiųjų metodų programų sistemoms
kurti. Šiam 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 (sprint);
- laikotarpio pabaigoje rengiamas susirinkimas 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.
160
XV. Lankstieji metodai (6)
2. Aukštasis programavimas (XP)
Aukštasis arba ekstremalusis programavimas (eXtreme Programming - XP) –
plačiai paplitusi lanksčiojo metodo atmaina. Jo pagrindiniai principai:
- bendravimas tarp užsakovo ir projekto vykdytojo. Į grupę įtraukiamas
užsakovas, padedantis detalizuoti darbus ir sudėlioti juos prioritetų tvarka,
galintis iškart atsakyti į iškilusius klausimus;
- mokymasis. Sutrumpina programavimo darbus. Testuojama programavimo
metu;
- programos paprastumas. Kuo programa paprastesnė, tuo didesnė
tikimybė, kad ji gerai veiks. Sudėtingos konstrukcijos skaidomos į
paprastesnes;
- programų peržiūra. Aukštojo programavimo atstovai dirba poromis. Todėl
visas programos kodas peržiūrimas rašymo metu;
- programos testavimas. Testai rengiami prieš pradedant rašyti programą.
Užduotis laikoma įvykdyta tik tada, kai visi testai baigiami sėkmingai.
161
Programų sistemų projektų ir kokybės valdymas
Pabaiga
162