Ipinapaliwanag ng plano ng proyekto kung ano ang layong makamit ng proyekto, paano aayusin ang gawain, at paano haharapin ng team ang mga pasya at pagbabago. Saklaw sa kapaki-pakinabang na template ng plano ng proyekto ang mga resulta, saklaw, pagtanggap, pagmamay-ari, dependency, yaman, panganib, milestone, at tuntunin sa pagsusuri. Bahagi lamang ng plano ang iskedyul, hindi ang buong dokumento.
Mahalaga ang pagkakaibang ito kapag lumilihis ang proyekto sa plano. Maipakikita ng timeline ang hindi naabot na petsa, ngunit hindi nito masasabi kung mali ang pagkaunawa ng team sa deliverable, kulang ito sa awtoridad, o tumanggap ito ng bagong gawain nang hindi binabago ang kapasidad. Dapat masagot ng plano ang mga tanong na iyon.
Inilalarawan ng artikulo ng PMI tungkol sa mga bahagi ng plano ng proyekto ang saklaw, yaman, milestone, pag-apruba, at pamamahala ng pagbabago bilang ilan sa mga bahagi nito. Orihinal at magaan na bersiyon para sa kolaboratibong team ang template rito, hindi opisyal na form ng PMI.
Magsimula sa pasyang sinusuportahan ng proyekto
Isulat ang resulta sa paraang mauunawaan ng taong wala sa delivery team. Pangalan ng output ang “Ilunsad ang dashboard.” Ipinapaliwanag naman ng “Tulungan ang mga pinuno ng suporta na matukoy ang mga escalation na walang may-ari bago ang lingguhang pagsusuri” kung bakit mahalaga ang output na iyon.
Pagkatapos, pangalanan ang sponsor o tagapagpasiyang may pananagutan at ang mga gagamit ng resulta. Maaaring iisang tao ang gumaganap sa mga tungkuling ito sa maliit na organisasyon, ngunit magkaiba ang kanilang mga pasya. Kailangang may magpasya kung kapaki-pakinabang pa ang proyekto; kailangang may magkumpirma na natutugunan ng naihatid na gawain ang napagkasunduang pangangailangan.
Itala nang hiwalay ang mga limitasyon at kagustuhan. Kailangan ng ibang pagtrato ang totoong deadline sa kontrata kaysa sa gustong petsa ng demo. Sabihin kung mapag-uusapan pa ang petsa. Kung may takdang hangganan ang pondo, ilahad ito at ang awtoridad na kailangan upang baguhin iyon. Gumamit ng sanggunian sa sensitibong talaang pinansiyal sa halip na kopyahin ang kumpidensiyal na detalye sa pampublikong collaboration board.
Kopyahin ang template ng plano ng proyektong ito
| Seksyon | Gabay na tanong |
|---|---|
| Resulta | Anong kapaki-pakinabang na pagbabago ang dapat gawin ng proyektong ito? |
| Saklaw | Aling mga deliverable at gawain ang kasama? |
| Hindi kasama | Aling mga makatwirang kahilingan ang sadyang wala sa proyektong ito? |
| Pagtanggap | Anong ebidensiya at kaninong pasya ang magpapatunay na kumpleto na? |
| Mga tungkulin | Sino ang may-ari ng paghahatid, pagtanggap, pasyang teknikal, at pag-escalate? |
| Paraan ng paggawa | Aling mga yugto o pag-ulit ang gagamitin ng team? |
| Dependency | Ano ang kailangang maging handa, mula kanino, at kailan? |
| Kapasidad | Aling mga tungkulin ang may oras at anong ibang pangako ang nananatili? |
| Mga milestone | Aling makahulugang kondisyon ang magpapakita ng progreso? |
| Panganib at palagay | Ano ang maaaring magpawalang-bisa sa plano, at anong tugon ang nakahanda? |
| Mga pasya sa pagbabago | Sino ang maaaring tumanggap ng binagong saklaw, gastos, o oras? |
| Pagsusuri | Kailan at paano susuriin at ia-update ang plano? |
Huwag punan ng talata ang bawat field para lang magmukhang tapos ang dokumento. Mas kapaki-pakinabang na markahang “hindi pa nalulutas, may-ari, petsa ng pasya” ang pasyang wala pa kaysa itago ito sa pangkalahatang pananalita. Maglagay ng link sa detalyadong iskedyul at tracker ng gawain sa halip na panatilihin ang mga kopyang nagkakatalo.
Halimbawang may paliwanag: ulat ng mga escalation sa suporta
Isipin ang isang kathang-isip na team na nagpaplano ng lingguhang ulat ng mga escalation. Ang napagkasunduang resulta ay matukoy ng mga pinuno ng suporta ang mga kasong walang may-ari. Ang deliverable ay ulat na binuo mula sa kasalukuyang datos ng ticket, na may dokumentadong kahulugan ng “walang may-ari.” Tahasang hindi kasama ang pagtataya at pagsusuri ng pagsingil.
Para tanggapin ang output, kailangang paghambingin ng pinuno ng suporta ang tinukoy na sample at ang mga ticket na pinagmulan nito, ipaliwanag ang mga pagkakaiba, at kumpirmahing nakatutulong ang ulat sa lingguhang pagsusuri. May-ari ng pagpapatupad ang engineering. May-ari ng operasyonal na kahulugan ang suporta. Magpapasya ang pinangalanang sponsor sa mga kahilingang nagpapalawak sa mga data source o layunin ng pag-uulat.
Dalawang dependency ang natukoy ng team: access sa export ng mga ticket at kasunduan tungkol sa may-ari kapag tumatawid ng departamento ang ticket. Hindi teknikal na gawain ang ikalawa. Maaaring magsimula ang coding bago magpasya, ngunit hindi dapat ipagpalagay ng kapani-paniwalang petsa ng pagtanggap na kusang mawawala ang kalabuan.
Nagiging ganito ang pagkakasunod ng mga milestone: napagkasunduan ang mga depinisyon; itinugma ang sample; natapos ang unang operasyonal na pagsusuri; nailipat ang pagmamay-ari sa team na magpapanatili nito. Mas nagbibigay-kaalaman ang mga ito kaysa “50% kumpleto na ang pagsusuri” dahil inilalarawan nila ang mga kondisyong mapagmamasdan.
Halimbawa lamang ang lahat ng detalye rito. Hindi ito case study ng customer ng Nextretro o pahayag na ginagarantiyahan ng isang format ng pagpaplano ang paghahatid.
Buuin ang iskedyul mula sa gawain at mga dependency
Kapag nauunawaan na ang saklaw at mga kondisyon ng pagtanggap, hilingin sa mga gagawa ng trabaho na tukuyin ang mga aktibidad at dependency. Pag-ibahin ang oras ng aktuwal na ambag at kabuuang lumipas na oras. Maaaring isang araw lang ang pagsusuri ng datos ngunit ilang araw itong maghintay sa tagasuri.
Markahan bilang pagtataya ang mga pagtataya. Kung mahalaga ang kawalang-katiyakan, gumamit ng saklaw ng halaga at pangalanan ang palagay sa likod nito. Mas tapat ang “Handa matapos aprubahan ang access sa datos, saka tinatayang isa hanggang dalawang linggo para sa pagpapatupad at pagtutugma” kaysa eksaktong petsang tahimik na nag-aakalang bukas darating ang pag-apruba.
Iba ang layunin ng roadmap: ipinakikita nito ang malawak na pagkakasunod ng mga resulta at mahahalagang dependency. Iniuugnay ng iskedyul ang mga aktibidad at petsa. Ikinakabit naman ng plano ng proyekto ang dalawang iyon sa layunin, awtoridad, at mga limitasyon ng proyekto. Piliin ang dokumentong sumasagot sa tanong ng mambabasa sa halip na palitan ng pangalan ang iisang timeline nang tatlong beses.
Panatilihing buhay ang plano sa pamamagitan ng maikling pagsusuri
Sa regular na pagsusuri ng paghahatid, tingnan ang mga pagbabago sa palagay, saklaw, dependency, at kapasidad. I-update ang plano kapag binago ng pasya ang pangako. Panatilihin ang sapat na kasaysayan upang maipaliwanag kung bakit naiiba ang kasalukuyang bersiyon sa orihinal.
Gumamit ng shared board upang ilantad ang mga panganib at tanong sa mga workshop ng pagpaplano. Itago ang mga petsa, alokasyon ng yaman, at pormal na pag-apruba sa opisyal na sistema ng proyekto. Tinutulungan ng retrospective board ang mga tao na mag-isip nang magkakasama; hindi nito pinapalitan ang lahat ng tungkulin sa pagpaplano.
Pagkatapos ng mahalagang milestone, magsagawa ng agile retrospective. Itanong kung aling palagay sa pagpaplano ang nakatulong, alin ang pumalya, at ano ang dapat baguhin bago ang susunod na yugto. Pumili ng format mula sa mga ideya para sa retrospective na akma sa kawalang-katiyakang susuriin.
Mga karaniwang pagkakamaling dapat alisin bago ibahagi
Alisin ang mga milestone na naglalarawan lamang ng panloob na pagsisikap nang walang ipinakikitang resulta. Palitan ang “nakonsulta na ang mga stakeholder” ng pasyang dapat magmula sa konsultasyon. Alisin ang dobleng may-ari kung walang nakaaalam kung sino ang may huling pasya.
Suriin ang mga hindi kasama laban sa malamang na mga kahilingan. Kung inaasahan ng lahat ng stakeholder ang pagsasanay, paglilipat ng datos, o pagpapanatili, hindi mawawala ang mga paksang iyon dahil hindi binanggit. Pagpasiyahan kung kabilang ang mga ito sa saklaw at kung paano bibigyan ng yaman.
Panghuli, basahin ang plano na para kang bagong kasapi ng team. Maipapaliwanag mo ba kung bakit umiiral ang proyekto, ano ang ibig sabihin ng pagkumpleto, at kanino dadalhin ang mahirap na pasya? Kung hindi, pasimplehin ang pananalita bago magdagdag ng detalye.
Mga madalas itanong
Kapareho ba ng iskedyul ng proyekto ang plano ng proyekto?
Hindi. Inilalarawan ng iskedyul ang oras at dependency ng mga aktibidad. Saklaw din ng plano ang layunin, saklaw, pagtanggap, pagmamay-ari, yaman, panganib, at mga pasya sa pagbabago. Maaaring mag-link ang kapaki-pakinabang na plano sa detalyadong iskedyul sa halip na doblehin ito.
Gaano kahaba dapat ang plano ng proyekto?
Sapat upang malinaw ang mahahalagang pangako at pasya. Maaaring kailangan lamang ng maikling dokumentong may mga link ang maliit na panloob na proyekto. Maaaring mangailangan ng mas detalyadong plano at pormal na kontrol ang komplikado o reguladong gawain.
Dapat bang gumawa ng plano ng proyekto ang agile team?
Kapaki-pakinabang ito kapag may dependency sa iba’t ibang team, pasya sa pagpopondo, o pangakong panlabas ang proyekto. Panatilihing kongkreto ang detalye ng malapit na panahon at nababago ang gawain sa hinaharap. Dapat suportahan ng plano ang pagkatuto, hindi magpahiwatig na alam na ang bawat susunod na gawain.