Šiame įraše kalbėsiu apie keletą projekto valdymo aspektų, kurie man neduoda ramybės darbe.

Keisdamas darbo specifiką tolstu nuo praktinės veiklos. Jau kuris laikas dirbu svetimomis rankomis. Pagrindiniais darbo įrankiais tapo Excel’is, Word’as, Powerpoint’as ir Project’as. Skirtingai nuo programavimo, vadybos negali pasitreniruoti sėdėdamas prie kompiuterio per naktį. Todėl retkarčiais sąmoningai pasiimu darbų įvairesnėms smegenų dalims pramankštinti. Kai kurie projektai tampa smėlio dėžė naujiems darbo metodams išbandyti.

Sakoma, kad “apetitas auga bevalgant”, šis dėsnis ypatingai stipriai veikia informacinių technologijų srityje. Dauguma freelancerių ir UAB’ų skundžiasi, kad užsakovų poreikiai nuolat keičiasi, todėl kinta darbų apimtis, auga sąnaudos, projektai vėluoja. Užbaigus projektus paaiškėja, kad rezultatas neatitinka lūkesčių. Darau prielaidą, kad tikslingai ir pakankamai komunikuojant, atliekant pakankamai biurokratijos, galima išvengti apimties didinimo, pakeitimų ir terminų nesilaikymo, ir galų gale po to sekančios raganų medžioklės.

Klasikinėje projektų valdymo literatūroje aprašomos stadijos, kurias praeina blogai valdomas projektas:

1. Entuziastinga pradžia
2. Iliuzijų praradimas
3. Chaosas
4. Kaltųjų ieškojimas
5. Nekaltųjų nubaudimas
6. Nenusipelniusiųjų apdovanojimas
7. Reikalavimų apibrėžimas

Pabandysiu išvardinti  biurokratines projekto vadovo užduotis ir praktikas, kurios padeda išvengti minėto scenarijaus.

1. Projekto aprašymas.
   Padeda susiderinti supratimą apie tai ko norima pasiekti vykdant projektą. Aprašymas turi būti lengvai suprantamas, toks kokį galėtum išberti važiuodamas liftu per 30 sek.
2. Galimybės.
   Verslo kalba aprašyti motyvai, kodėl vykdomas projektas. Aiškinantis šią vietą dažnai galima nuspręsti kas yra must have ir kas yra nice to have.
3. Tikslai.
   Nepamirškime apie SMART akronimą. Verčiant į lietuvių kalbą, tikslas turi būti: paprastai ir aiškiai įvardintas, pamatuojamas, paskiriamas, realistinis, apibrėžtas laike. Šaltiniuose galima rasti ir kitokių vertimų, tačiau šis man atrodo pakankamai tikslus.
4. Uždaviniai
   Įvardinant uždavinius paaiškėja, kokias veiklų grupes reikės daryti norint pasiekti tikslų.
5. Poveikis.
   Projekto įgyvendinimo poveikis verslui, operacijoms, darbui, kitiems projektams, technologijai ir sistemoms. Aiškinants šią dalį paaiškėja ar atsižvelgta į visus dalyvius. Išaiškėja ką pamiršome.
6. Apribojimai.
   Išoriniai veiksniai ribojantys projekto įgyvendinimą. Resursai, laikas, biudžetas…
7. Projekto apimtis.
   Tiksliai įvardintos projekto ribos. Nustatoma kas bus daroma projekte ir kas nebus daroma projekte. Tariantis dėl darbų apimties dažnai susitariama, kad dalis pageidaujamų veiklų nebus vykdoma dėl laiko ar resursų stokos. Pasibaigus projektui tokie susitarimai dažnai pasimiršta. O tada įrodyk, kad ne kupranugaris :) Jeigu lygintume 6 ir 7 aspektus – apribojimai yra sunkiai keičiami ar visai nekeičiami išorės veiksniai, o projekto apimtis, sąmoningai projekto vadovo įvardintos veiklų ribos apibrėžiančios darbus.
8. Sėkmės kriterijai.
   Pamatuojami rodikliai, kad projektas jau pabaigtas. Paprastai labai panašu į tikslus, bet įvardinami detaliau. Vienam tikslui pasiekti gali būti keli kriterijai.
9. Komandos struktūra ir atsakomybės.
   

   Atsakomybės

   
   Paaiškėja kas ką daro ir už ką atsako. Galų gale, paaiškėja, kas nebus padaryta, nes nėra kam to daryti. Pasitaiko sričių “našlaičių”, už kurias niekas neatsako, o tai yra potenciali bėda.

10. Biudžetas.
    Kiek kainuos projektas. Kada vykdomi atsiskaitymai. Kada gaunamos įplaukos. Finansininkai kartais reikalauja biudžetą išdėlioti pamėnesiui ar ketvirčiais, kad galėtų planuoti pinigų srautus.
11. Komunikacijos planas.
    Projekto vadovas yra tarpininkas tarp užsakovo, projekto komandos ir savo valdžios. Užsakovas gali būti atstovaujamas vadybininko, tačiau reikia nepamiršti ir jo vadovų. Projekto komandą gali sudaryti žmonės iš tarpusavyje nesusijusių ir retai komunikuojančių padalinių. Valdžiai informacija įdomi ne taip dažnai ir ne taip detaliai. Dažniausiai su jais reikia kalbėti per laiko ir biudžeto parametrus.
12. Darbų planas.
    Geriausia, kai darbų planą sudaro darbo pavadinimas, pradžia, pabaiga, atsakingas asmuo, trukmė valandomis ir darbo aprašymas. Aprašymas reikalingas, nes skaitantieji planą ne visada vienodai supranta ką reiškia vienas ar kitas terminas ar kokiomis priemonėmis jis turės būti atliktas. Praverčia ganto diagramos. Iš gerai parengto plano lengva išfiltruoti kiekvieno komandos nario asmenines užduotis.
13. Rizikos planas.
    Priverčia susimąstyti apie galimas bėdas. Padeda joms pasiruošti. Koreguoja lūkesčius. Dažniausiai pasitaikančios rizikos: techninės klaidos, komandos kaita, komandos narių kompetencijos trūkumas, laiko viršyjimas, biudžeto viršyjimas, reikalavimų pasikeitimai, nepakankamas vadybos dėmesys projektui, nepakankamai greitas užsakovo atsakymas į klausimus ir sprendimų priėmimas, planavimo klaidos, plane pražiopsoti darbai, prioritetų pasikeitimas, neteisingas mokymosi kreivės nustatymas, nekokybiški įrankiai.
14. Darbų ataskaitos.
    Atrodo savaime suprantama :) Bet praktikoje sunkiai įgyvendinama. Ši dalis iš projekto vadovo reikalauja didelio užsispyrimo. Projekto komanda juk ir taip turi labai daug darbų. Tačiau tai yra viena iš pagrindinių projekto sveikatos indikacijų. Yra toks terminas, kaip MBWA “Management by wondering around”. Lietuviškai: vadovavimas vaikštinėjant. Projektų vadovas sukiojasi prie komandos ir apie projekto būseną sužino neformaliais būdais. Tačiau ką daryti, kai komanda keliuose miestuose? Kaip išklausti tikslesnių prognozių. Ne visi komandos nariai yra atviri. Ne visi sugeba racionaliai įvertinti darbų progresą ir esamos situacijos įtaką rytojaus darbams. Atsižvelgiant į tai, manau, kad ataskaitos apie darbus turėtų būti teikiamos formaliai. Jose turėtų atsispindėti faktiškai prie užduoties sugaištas laikas, kad projektų vadovas galėtų atlikti plano ir fakto analizę. Labai sveika šiose ataskaitose numatyti vietą plano korekcijų įvardinimui.
15. Pakeitimų valdymas
    Visi projekto komandos, užsakovo ar vadovybės inicijuoti pakeitimai turi būti dokumentuojami. Turi būti vertinamas jų poveikis projektui. Projekto vadovas yra vienintelis žmogus žinantis, darbų visumą ir apimti, todėl jo pareiga paaiškinti aplinkiniams kaip vienas ar kitas pakeitimas įtakos projektą. Per lengvai sutinkant su siūlomais pakeitimais, projektų vadovas stato visą projektą į pavojų.
16. Prielaidos
    Projektui įvykti turi būti sukurtos tam tikros prielaidos. Skirti resursai ar padaryti organizaciniai pokyčiai. Tai yra išoriniai, neprojektiniai veiksniai, kurių buvimas sąlygoja projekto sėkmę.

Aptartos temos yra klausimai apie kuriuos projektų vadovas turi pagalvoti ir darbai, kuriuos turi padaryti. Priklausomai nuo pasitikėjimo savimi, atsakymus galima aprašyti ir pasirašyti. Galima palikti galvoje. Bet nepagalvoti apie juos negalima.

Tokią praktiką taikau daugelyje savo projektų, tačiau vieno, žmogaus projektai yra per mažos apimties, kad galima būtų prieiti išvadų. Todėl klausiu Jūsų: ką byloja Jūsų patirtis? Dirbdami informacinių technologijų ar susijusiose srityse tikriausiai dažnai susiduriate su panašiomis problemomis. Kokia Jūsų patirtis projekto valdymo klausimu? Kur slypi didžiausios rizikos? Apimtis, laikas, lūkesčiai? Gal turite praktinių patarimų?

Naudota literatūra:
Organizations Through the Eyes of a Project Manager (2002)