Trabahong kailangang gawin ang task ng proyekto. Mahalagang pangyayari o tagumpay ang milestone na ginagamit upang markahan ang progreso. Task ang “patakbuhin ang acceptance test”; milestone ang “nakumpirma ang operasyonal na pagtanggap.” Nakakatulong ang pagkakaibang ito para makita kung nakagawa ng kahandaan o desisyong kailangan ang natapos na aktibidad.
Iba pa rito ang deadline: kinakailangang petsa ito. Maaaring may deadline ang milestone, pero hindi patunay ng pagkamit nito ang pagdating ng petsa. Mahalaga ang tapat na pagtatala sa pagkakaibang ito kapag umaasa sa plano ang mga stakeholder.
Ipinagkakaiba ng GAO Schedule Assessment Guide ang mga milestone at aktibidad sa iskedyul ng proyekto. Iniaangkop ng mga halimbawang ito ang pagkakaibang iyon sa team review at handoff; kathang-isip ang mga ito, hindi salaysay ng customer project.
Ihambing ang task, milestone, deadline, at deliverable
| Item | Kinakatawan nito | Halimbawa | Ebidensya ng pagkumpleto |
|---|---|---|---|
| Task | Trabahong nangangailangan ng pagsisikap at oras | I-rehearse ang migration | Nagawa ang rehearsal at naitala ang mga obserbasyon |
| Deliverable | Nagawang item o kakayahan | Migration runbook | Natugunan ang napagkasunduang nilalaman at pamantayan sa kalidad |
| Milestone | Mahalagang pangyayari o tinanggap na estado | Tinanggap ng operations ang responsibilidad | Naitala ang awtorisadong pagtanggap pati anumang kondisyon |
| Deadline | Kinakailangang petsa | Dapat matapos ang transition bago mag-expire ang kontrata | Ihambing ang aktuwal o inaasahang petsa ng milestone sa kinakailangang petsa |
Sa karaniwang pag-iiskedyul, mino-model ang milestone bilang puntong walang tagal. Hindi ibig sabihin nito na agad-agad nangyayari ang trabahong kailangan para maabot ito. Iugnay ang aktuwal na paghahanda, pagsusuri, at pagtanggap sa halip na itago ang mga ito sa isang diamond na may label na “handa.”
Maaaring sumaklaw sa maraming task ang summary activity. Hindi ito awtomatikong milestone. Kapag tinawag na milestone ang anim na linggong yugto, maaaring hindi malinaw kung trabaho ng yugto, petsa ng pagtatapos nito, o desisyon sa hangganan nito ang tinutukoy.
Pangalanan ang mga milestone para ma-verify ang mga ito
Mas piliin ang estadong o pangyayaring may malinaw na tatanggap: “Tinanggap ng service owner ang pilot,” “Inaprubahan ang kinakailangang access,” o “Nasuri ang unang kumpletong outcome cohort.” Iwasan ang mga label na “phase two” at “malapit nang matapos” na kailangan pang ipaliwanag ng orihinal na tagaplano.
Para sa bawat milestone, itala ang:
- Pangyayari o tinanggap na estadong kinakatawan nito.
- Ebidensyang kailangan para kumpirmahin ito.
- Tao o papel na may awtoridad magkumpirma.
- Kailangang naunang trabaho at panlabas na dependency.
- Petsa ng limitasyon, kung mayroon.
- Paghawak sa mga kondisyon, exception, o bahagyang pagtanggap.
Hindi nito hinihingi ang malaking dokumento para sa bawat maliit na pangyayari. Maaaring makaiwas sa magastos na hindi pagkakaunawaan ang isang malinaw na pangungusap ng pagtanggap. Dapat tumugma ang detalye sa magiging epekto ng maling pagdedeklarang tapos na ang milestone.
Kung posible ang “tinanggap nang may kondisyon,” tukuyin ang mga kondisyon at ang may-ari ng natitirang trabaho. Huwag itago ang hindi pa nalulutas na gawain bilang hindi nakikitang talababa para lang manatiling berde ang status.
Halimbawa: hindi nangangahulugang handa na ang serbisyo kapag tapos na ang training
Iniaabot ng isang kathang-isip na team ang reporting service sa operations. May milestone sa plano na “kumpleto na ang training.” Naganap sa iskedyul ang tatlong training session at minarkahan ng proyekto na handa na ang transition.
Nang maglaon, natuklasan ng tatanggap na team na hindi nito maibalik ang nabigong nakaiskedyul na report. Saklaw ng training ang karaniwang operasyon, pero hindi pa kumpleto ang mga tagubilin sa access at recovery.
Hindi walang silbi ang training. Ang problema, binibilang ng milestone ang mga aktibidad sa halip na katawanin ang desisyon tungkol sa kahandaang inaakala ng mga stakeholder.
Sa binagong plano, nagiging milestone ng transition ang “tinanggap ng operations ang responsibilidad sa support.” Kabilang sa ebidensya ang napagkasunduang pagdaan sa karaniwang paghawak, naaangkop na recovery exercise, kumpirmadong access, at malinaw na pagtanggap sa listahan ng natitirang limitasyon. Nananatiling mga task na sumusuporta sa kahandaan ang mga training.
Mga halimbawa ang pamantayang ito at kailangang iangkop sa panganib at pangangailangan sa operasyon ng serbisyo. Hindi ito pangkalahatang pamantayan para sa operasyonal na pagtanggap.
Nagdaragdag din ang proyekto ng hiwalay na task para sa acceptance review mismo. Hindi libre sa oras ang pagsusuri ng tatanggap sa ebidensya dahil lang ipinapakita ng iskedyul ang huling milestone bilang isang punto.
Pumili ng sapat na milestone para magabayan ang mga desisyon
Maaaring bulagin ng iskedyul na “simula” at “tapos” lang ang mga stakeholder sa mga panganib sa pagitan. Kapag may milestone ang bawat maliit na aksiyon, mahirap makita ang mahahalagang pangyayari.
Pumili ng milestone sa mahahalagang pagbabago: pahintulot na magpatuloy, tinanggap na palagay sa disenyo, nagagamit na kakayahan, kahandaang magsubok, o paglilipat ng responsibilidad. Itanong, “Anong desisyon ang magiging posible kapag nakumpirma ang pangyayaring ito?”
Sa exploratory work, maaaring pagsusuri ng ebidensya ang makahulugang milestone, hindi patunay na nagtagumpay ang napiling ideya. Maaaring mas tapat ang “desisyon sa pilot batay sa napagkasunduang ebidensya” kaysa “matagumpay ang pilot” kapag idinisenyo ang eksperimento para malaman kung gumagana ang isang paraan.
Panatilihing sapat ang detalye ng delivery tracking para maipakita kung paano maaabot ang milestone. Kapaki-pakinabang sa mga stakeholder ang high-level na view, pero hindi nito dapat ihiwalay ang ipinangakong pangyayari sa mga gawain at dependency na nasa ilalim nito.
Suriin ang nanganganib na milestone bago ang deadline nito
Kapag umurong ang forecast, siyasatin ang hanay ng mga paunang kailangan. Hindi ba kumpleto ang deliverable, hindi ba available ang reviewer, malabo ba ang acceptance criterion, o hindi kumpirmado ang dependency? Magkakaibang tugon ang kailangan ng mga problemang ito.
Kapaki-pakinabang na tanong sa review ang: “Ano ang pinakahuling petsa para makapagpasya pa tayo nang iba?” Maaaring mas maaga ito kaysa deadline ng milestone. Kung kailangang pumili ng supplier dalawang linggo bago testing, huli na ang babala sa araw ng testing.
Huwag ilipat ang baseline date ng milestone para lang tumugma ito sa kasalukuyang forecast. Panatilihin ang sangguniang commitment at itala ang mga awtorisadong pagbabago. Mas detalyadong ipinapaliwanag ng Gantt baseline guide ang paghahambing na iyon.
Kung nahuli ang pagkamit sa milestone, itala ang aktuwal na petsa at dahilan na suportado ng ebidensya. Makakatulong ang kasaysayang ito sa susunod na pagpaplano nang hindi ginagawang paninisi ang talakayan.
Isama ang milestone sa retrospective kung mahalaga
Hindi dapat ulitin ng retrospective ang bawat update sa status ng proyekto. Pumili ng milestone na may itinuro sa team tungkol sa paraan nito ng pagtatrabaho: nahuling pagtanggap, nakakagulat na dependency, o palagay sa kahandaang hindi nagkatotoo.
Itanong kung ano ang paniniwala ng team noong nagpaplano, anong ebidensya ang kumuwestiyon dito kalaunan, at anong maliit na pagbabago ang makakatulong sa susunod na desisyon. Halimbawa, subukan ang acceptance criteria kasama ang tatanggap na may-ari bago simulan ang susunod na work package.
Gumamit ng team retrospective para suriin ang pattern at gabay sa action item para sa follow-up. Maaaring pagdausan ng NextRetro ang diskusyon; nananatili sa project-planning system ang aprubadong iskedyul.
Mga madalas itanong
Maaari bang magkaroon ng tagal ang milestone?
Sa karaniwang pag-iiskedyul, punto sa oras na walang tagal ang milestone. Nangangailangan ng oras ang paghahanda, inspeksiyon, at desisyon sa paligid nito kaya dapat lumitaw ang mga ito bilang mga aktibidad. Tingnan ang gawi ng planning tool kung pinapayagan nito ang ibang representasyon.
Palagi bang milestone ang pagtatapos ng deliverable?
Hindi. Nagawang item o kakayahan ang deliverable. Maaari itong maging milestone kapag mahalagang pangyayari ang pagkumpleto o pagtanggap dito, pero hindi kailangan ng gayong antas ng pag-uulat ang bawat maliit na deliverable.
Ano ang gagawin kapag bahagya pa lang kumpleto ang milestone?
Ilarawan ang aktuwal na estado at natitirang kondisyon. Gumamit ng tinukoy na tuntunin para sa conditional acceptance kung mayroon ang proyekto. Kung wala, panatilihing hindi pa nakakamit ang milestone sa halip na gumamit ng porsiyentong nagpapahiwatig ng pagtanggap na hindi naman nangyari.