Naujos IT sistemos diegimas, gamybos linijos perkėlimas, naujo produkto sukūrimas, filialo atidarymas — visa tai projektai. Jie nepanašūs vienas į kitą, bet žlunga stebėtinai panašiai: išsiplečia apimtis, išsitęsia terminai, biudžetas viršijamas, o pabaigoje niekas tiksliai nebeprisimena, ką iš tikrųjų buvo žadėta pasiekti.
Projektų valdymas yra disciplina, kuri šiuos scenarijus paverčia valdomais. Šiame straipsnyje — kas yra projektas ir projektų valdymas, iš kokių etapų susideda projekto gyvavimo ciklas, kuo skiriasi metodikos ir kokie vaidmenys projekte būtini, kad rezultatas būtų pasiektas.
Kas yra projektų valdymas?
Projektas — tai laikina veikla, kuria siekiama sukurti unikalų rezultatą: produktą, paslaugą ar pokytį. Du žodžiai čia esminiai. Laikina reiškia, kad projektas turi aiškią pradžią ir pabaigą — pasiekus tikslą, jis baigiasi. Unikalus reiškia, kad rezultatas kuriamas pirmą kartą — tai ne pasikartojanti rutina.
Projektų valdymas — tai žinių, metodų ir įrankių taikymas projekto veikloms, kad tikslas būtų pasiektas laiku, neviršijant biudžeto ir sutartos apimties. Praktiškai tai reiškia atsakymus į klausimus: ko tiksliai siekiame, kas ką daro, kada, už kiek ir ką darysime, kai kas nors pasikeis — nes pasikeis tikrai.
Riba tarp projekto ir proceso praktikoje painiojama dažniau, nei atrodo — o nuo atsakymo priklauso, kaip veiklą valdyti ir matuoti. Šiam klausimui skyrėme atskirą straipsnį „Projektas ar procesas: kaip atskirti“. Trumpoji taisyklė: jei veikla kartojasi ir turi standartinę eigą — tai procesas; jei kuriate kažką pirmą kartą su aiškia pabaiga — tai projektas.
Kodėl projektams reikia valdymo?
Projektai žlunga ne dėl blogų idėjų — dažniausiai dėl valdymo spragų, kurios kartojasi iš organizacijos į organizaciją:
- Neapibrėžtas tikslas. Startuojama nuo sprendimo („diegiame sistemą“), o ne nuo problemos („mažiname užsakymo apdorojimo trukmę“). Be aiškaus tikslo neįmanoma pasakyti, ar projektas pavyko.
- Apimties plėtra (angl. scope creep) — projekto eigoje „dar šito reikėtų“ kaupiasi tol, kol pradinis biudžetas ir terminas nebeturi nieko bendra su realybe.
- Neaiškios atsakomybės — kai neaišku, kas priima sprendimus, kiekvienas klausimas laukia savaitėmis.
- Rizikos nevaldomos — apie tai, kas gali suklysti, pagalvojama tada, kai jau suklydo.
- Projektas be pabaigos — rezultatas neperduodamas į kasdienę veiklą, ir projekto komanda metų metus „palaiko“ tai, kas seniai turėjo tapti procesu.
Projektų valdymas nė vienos šių problemų nepanaikina automatiškai — bet suteikia struktūrą, kurioje kiekviena jų pastebima anksti, kol dar pigu koreguoti.
Projekto gyvavimo ciklas: 5 etapai
Nepriklausomai nuo metodikos, kiekvienas projektas pereina penkis etapus.
1. Inicijavimas
Apibrėžiama problema ir siekiamas rezultatas, įvertinamas tikslingumas: kokią vertę projektas sukurs ir ar ji verta investicijos. Paskiriamas projekto vadovas ir užsakovas. Svarbiausias šio etapo dokumentas — projekto apibrėžimas, atsakantis į klausimus „kodėl“, „ką“ ir „kas“.
2. Planavimas
Tikslas išskaidomas į darbus, darbai — į terminus ir atsakomybes. Sudaromas biudžetas, identifikuojamos rizikos, sutariama komunikacijos tvarka: kas, kam ir kokiu ritmu atsiskaito. Planavimo gylis turi atitikti projekto dydį — dviejų savaičių projektui nereikia šimto eilučių Ganto diagramos.
3. Vykdymas
Komanda kuria rezultatą pagal planą. Projekto vadovo darbas šiame etape — šalinti kliūtis, valdyti pokyčius ir išlaikyti komunikacijos ritmą, kad problemos iškiltų susirinkime, o ne po termino.
4. Stebėsena ir kontrolė
Vyksta lygiagrečiai su vykdymu: faktas lyginamas su planu — terminai, biudžetas, apimtis, rizikos. Esminis principas — valdyti nukrypimus, kol jie maži. Pokyčiai neuždraudžiami, bet įforminami: kiekvienas apimties pakeitimas turi kainą ir sprendimą, kas ją apmoka — laikas, pinigai ar kita atsisakyta funkcija.
5. Užbaigimas
Rezultatas perduodamas užsakovui ir — jei jis veiks nuolat — aprašomas kaip procesas su savininku. Fiksuojamos išmoktos pamokos: kas pavyko, kas ne ir ką kitą kartą daryti kitaip. Praleidus šį etapą, organizacija kiekviename projekte lipa ant tų pačių grėblių.
Projektų valdymo metodikos: Waterfall, Agile ir hibridas
Waterfall (krioklys) — nuosekli metodika: etapai eina vienas po kito, kiekvienas baigiamas prieš pradedant kitą, o rezultatas išsamiai suplanuojamas iš anksto. Stiprybė — nuspėjamumas ir aiški kontrolė; silpnybė — brangus reagavimas į pokyčius, nes klaida, pastebėta pabaigoje, verčia grįžti į pradžią.
Agile — iteracinis požiūris: rezultatas kuriamas trumpais ciklais, po kiekvieno peržiūrimas su užsakovu ir koreguojama kryptis. Stiprybė — greitas grįžtamasis ryšys ir lankstumas; silpnybė — sunkiau iš anksto įsipareigoti dėl galutinio termino ir biudžeto.
Pasirinkimą lemia ne mada, o neapibrėžtumo lygis: kai reikalavimai aiškūs ir stabilūs (statyba, įrangos perkėlimas), natūraliai tinka Waterfall; kai rezultatas aiškėja eigoje (programinė įranga, nauji produktai) — Agile. Praktikoje dauguma organizacijų dirba hibridiškai: planuoja krioklio rėmuose, o viduje vykdo iteracijomis. Ar šiuos du pasaulius apskritai galima sujungti ir kur slypi spąstai, nagrinėjome straipsnyje „Waterfall vs Agile: ar galima sujungti?“.
Mažiems ir vidutiniams projektams verta žinoti ir lengvąsias metodikas — pavyzdžiui, P3.express, kuri projektų valdymo discipliną sutalpina į minimalų, praktišką žingsnių rinkinį be sunkios biurokratijos. Metodikas ir jų pritaikymą realiuose projektuose nagrinėjame projektų valdymo mokymuose.
Vaidmenys ir atsakomybės projekte
Projekto sėkmei reikia trijų aiškiai atskirtų vaidmenų:
- Užsakovas — apibrėžia tikslą, skiria resursus ir priima galutinius sprendimus. Projektas be aktyvaus užsakovo yra laivas be uosto: komanda dirba, bet niekas nepasako, ar plaukiama ten.
- Projekto vadovas — atsako už kelią iki tikslo: planą, komunikaciją, rizikas, terminus. Svarbu: atsakomybė be įgaliojimų neveikia — jei vadovas negali priimti sprendimų savo mandato ribose, jis tik metraštininkas.
- Komanda — kuria rezultatą ir, ne mažiau svarbu, laiku signalizuoja apie kliūtis.
Kai vaidmenys nesutarti, projektas skęsta suderinimuose: sprendimai laukia, nes neaišku, kas juos priima, o darbai dubliuojasi arba krenta į tarpus. Praktinis įrankis tam sutvarkyti — RACI matrica, kiekvienai veiklai apibrėžianti, kas atlieka, kas atsako, su kuo konsultuojamasi ir kas informuojamas. Kaip ją sudaryti, aprašėme straipsnyje „Rolės ir atsakomybės projekte“.
Rizikų valdymas projekte
Kiekvienas projektas yra unikalus — vadinasi, kupinas neapibrėžtumo. Rizikų valdymas nereiškia jų vengimo; tai sąmoningas sprendimas, kiek ir kokių rizikų organizacija pasirengusi prisiimti siekdama tikslo. Praktiškai tai reiškia: rizikos identifikuojamos planavimo etape, įvertinamos pagal tikimybę ir poveikį, o reikšmingiausioms sutariami atsako veiksmai ir atsakingi žmonės.
Kiek rizikos „leistina“, priklauso nuo organizacijos rizikų apetito — šią sąvoką ir jos nustatymo būdus aptarėme atskirame straipsnyje, o sisteminį požiūrį į rizikas organizacijoje nagrinėjame rizikų valdymo mokymuose.
Kiek projektų valdymo reikia?
Dažna baimė — kad projektų valdymas atneš biurokratiją: ataskaitas, kurių niekas neskaito, ir susirinkimus, kuriuose nieko nenusprendžiama. Ši baimė pagrįsta tada, kai metodika taikoma aklai, ignoruojant projekto mastą.
Sveika taisyklė — valdymo apimtis turi atitikti projekto riziką ir dydį. Mažam projektui užtenka aiškaus tikslo, atsakingų sąrašo ir savaitinio ritmo; dideliam — reikia ir rizikų registro, ir pokyčių valdymo tvarkos, ir formalių etapo vartų. Blogiausi abu kraštutinumai: didelis projektas „ant lapelio“ ir mažas projektas, paskandintas dokumentacijoje.