LABAS visiems projektų ir laiko planavimo entuziastams!
5 likę žingsniai
Apie pirmuosius penkis jau kalbėjome, tad iškart pratęsikim apie likusius:
6️⃣ Išteklių (pakartotinis) įvertinimas. Rekomenduotina palyginti critical path ir WBS (work breakdown structure) su kitomis kirtinėmis vietomis: su projektu nesusiję įsipareigojimai; asmeninės ir valstybinės šventės; skiriamos valandos užduočiai atlikti vs realiai sugaištamas laikas; komandos įgūdžiai ir gebėjimai (junior lygio specialistas beveik niekada nedirbs tokiu tempu kaip senior); stakeholder’ių skirti deadline’ai ir t.t., kas tiesiogiai ar netiesiogiai gali daryti įtaką projekto tvarkaraščiui.
7️⃣ Rizikos (viena mėgstamiausių mūsų temų 😁). Tikėtina, kad priėjus iki šio žingsnio, kelios rizikos jau išryškėjo ir buvo identifikuotos. Šis step’sas skirtas šiek tiek atidžiau pagalvoti apie jas (nepamirštam - susijusias su tvarkaraščiu, ne visu projektu) ir uždokumentuoti. Taip, tai papildomas darbas, bet labai praverčiantis. Peržiūrim deadline’us, pamąstom, kiek gali užtrukti gauti, pavyzdžiui, report’us ir reikiamus feedback’us, pridedam šiek tiek laiko rezervo (pvz., 20%) ir turim jau dar stipresnę tvarkaraščio versiją.
8️⃣ Susidarom pati grafiką / planą / tvarkaraštį. Šitoj tvarkaraščio stadijoj jau turim turėti išgrynintas užduotis, jų trukmes ir milestone’us, dalimis išskirstyto projekto vaizdą su task’ais ir jų owner’iais, identifikuotas priklausomybes, sukurtą critical path, įvertintus išteklius ir rizikas. Turint visą šią informaciją, lieka tik iki galo suplanuoti projekto eigą ir išskirstyti visas užduotis komandai. Pabaiga jau visai netoli. 😁
9️⃣ Peržiūra ir korekcijos. Labai svarbu kartas nuo karto šiek tiek atsitraukti ir sugrįžus peržiūrėti planą ,,šviežiomis” akimis. 😀 Šį žingsnį rekomenduojam atlikti kartu su komanda, kad iki galo būtų suprasti expectation’ai, peržiūrėti deadline’ai ir pan. Labai dažnai būna, kad ką nors pamirštam, tad šis žingsnis skirtas būtent tokioms smulkmenoms.
🔟 Periodinė peržiūra. Kad ir kokį gerą planą / tvarkaraštį susidarom, veiksmo eigoj bus nuklydimų. Ir tai visiškai normalu ir tai nereiškia, kad planas buvo blogas. Vykstant pokyčiams, vertėtų grįžti prie aiškaus plano vaizdo, peržiūrėti, ką galima pastumdyti - kažką padaryti greičiau, kažkam duoti šiek tiek daugiau laiko. Turint prieš akis tą aiškų vaizdą, nesunku laviruoti bet kokią situaciją, nekeičiant svarbiausių datų ar perkelinėjant projekto pabaigos datą (jei aiški data egzistuoja).
Manau, kad kiek įdirbio įdėsim į projekto plano (šiuo atveju - tvarkaraščio) kūrimą, tiek lengviau bus paties projekto eigoje. Gal visai verta pasėdėti ir prie tokios “biurokratijos”? 😎
Su geriausiais linkėjimais,
Dovilė 🚀
Comentarios