Ang Gantt chart baseline ay naka-save na bersyon ng iskedyul ng proyekto na nagsisilbing sanggunian at ipinapakita kasabay ng kasalukuyang plano o aktuwal na progreso. Nagbibigay ito ng paraan para ihambing ang orihinal na inaprubahang oras sa malamang na mangyari ngayon at sa mga nangyari na. Hindi pangako ang baseline na wala nang kawalang-katiyakan.
Mahalagang pag-ibahin ang baseline, forecast, at aktuwal. Pinananatili ng baseline ang napagkasunduang sanggunian. Nagbabago ang forecast habang may natututuhan ang team. Itinatala ng aktuwal na petsa ang mga natapos na pangyayari. Kapag sabay-sabay na ino-overwrite ang mga field na ito, hindi na maipapaliwanag ng chart ang paggalaw ng iskedyul.
Tungkol ang gabay na ito sa pagbasa at team review, hindi sa paggamit ng iisang scheduling application. Retrospective tool ang NextRetro, hindi Gantt scheduling engine; panatilihin ang opisyal na iskedyul sa project-planning system ninyo.
Ano ang dapat laman ng schedule baseline?
Iniuugnay ng kapaki-pakinabang na baseline ang mga kaugnay na aktibidad, dependency, kalendaryo, at milestone. Hindi nagiging kapani-paniwala ang plano dahil lang nag-save ng larawan ng mga arbitraryong petsa. Kumpirmahin kung paano ipinapakita ng iskedyul ang availability ng resources at kung aling mga palagay ang nagtatakda sa mahahalagang petsa ng pagtatapos.
Itinuturing ng U.S. GAO Schedule Assessment Guide na magkahiwalay na gawain sa scheduling ang pagpapanatili ng baseline at pag-update ng iskedyul batay sa aktuwal na progreso. Iniaangkop sa pagpupulong ng maliit na team ang paraan ng review sa ibaba; hindi ito kapalit ng espesyalistang pagsusuri sa iskedyul.
Itala ang petsa ng pag-apruba, scope, bersyon, at mga palagay ng baseline. Tukuyin kung sino ang maaaring mag-apruba ng mga pagbabago. Maaaring mangailangan ng karagdagang kontrol ang proyektong may kontraktuwal o reguladong commitment, lampas sa magagaan na halimbawang ito.
Huwag hintaying matapos ang delivery bago pumili ng sangguniang pinakamaganda ang ipinapakitang performance. Kung gumagamit ang proyekto ng progressive planning, idokumento kung aling bahagi ang detalyado, alin ang hindi pa tiyak, at kung paano pananatilihin ang aprubadong pagpapalawak ng plano.
Basahin nang magkasama ang baseline, forecast, at aktuwal na petsa
Isaalang-alang ang kathang-isip na bahagi ng iskedyul na ito. Inimbento ang mga petsa at aktibidad para sa paliwanag.
| Item | Baseline na pagtatapos | Kasalukuyang forecast | Aktuwal na pagtatapos | Tanong sa review |
|---|---|---|---|---|
| Napagkasunduan ang data mapping | 4 Nob | — | 6 Nob | Bakit mas tumagal ang pagkakasundo? |
| Tapos ang migration rehearsal | 11 Nob | 16 Nob | — | Aling naunang dependency o limitasyon sa capacity ang nagbago? |
| Pagtanggap ng operations | 18 Nob | 23 Nob | — | Tinatanggap ba ng tatanggap na team ang binagong panahon ng readiness? |
Nangangailangan ng aktuwal na petsa ang natapos na item, hindi forecast na patuloy na gumagalaw. Nangangailangan naman ng makatotohanang forecast ang hindi pa tapos na item, hindi lumang baseline na kinopya sa field ng kasalukuyang plano dahil walang gustong mag-ulat ng pagkaantala.
Pag-ibahin din ang lumipas na oras at oras ng trabaho. Magkaiba ang limang araw sa kalendaryo at limang araw ng trabaho. Sabihin kung anong tuntunin ang ginagamit bago magkalkula ng variance, lalo na kapag magkakaiba ang holiday o operating calendar ng mga team.
Hindi lahat ng pagkaantala ay nagpapabago sa petsa ng pagtatapos ng proyekto. Suriin ang lohika ng dependency at natitirang flexibility bago sabihing mahuhuli ang buong proyekto dahil sa nahuling task. Sa kabilang banda, maaaring mas mahalaga ang maliit na pagkaantala sa kritikal na handoff kaysa ilang malalaking pagbabago sa ibang lugar.
30-minutong review ng variance
Dalhin ang kasalukuyang iskedyul, baseline nito, at maikling listahan ng mga item na maaaring magbago ng desisyon kapag gumalaw. Huwag repasuhin ang bawat bar dahil lang nasa chart ito.
Unang limang minuto: magkasundo sa reference version at petsa ng status. Kumpirmahing napapanahon ang aktuwal na progreso. Itala ang alam na kakulangan sa data bago bigyang-kahulugan ang chart.
Susunod na sampung minuto: suriin ang isang mahalagang hanay ng trabaho. Itanong kung ano ang nagbago sa scope, pagkakasunod-sunod, availability, effort, o panlabas na commitment. Ihiwalay ang mga pangyayaring may ebidensya sa mga posibleng paliwanag.
Susunod na sampung minuto: ikumpara ang mga tugon. Maaari bang alisin ng team ang hindi kailangang paghihintay, ligtas na baguhin ang pagkakasunod-sunod, kumuha ng desisyon, o bawasan ang aprubadong scope? Anong gastos o panganib ang maidudulot ng pagpapabilis? Mga opsyon na may kapalit at kahihinatnan ang dagdag na tao o overtime, hindi awtomatikong pagwawasto.
Huling limang minuto: itala ang desisyon, may-ari, at update sa forecast. Kung kailangang baguhin ang commitment, sundin ang itinatag na proseso ng pag-apruba ng proyekto. Panatilihin ang dating baseline at ang dahilan ng anumang aprubadong pagpapalit.
Mga mungkahing oras ito para sa facilitation. Maaaring mangailangan ang komplikadong programa ng mas malalim na pagsusuri sa risk ng iskedyul sa halip na mas maikling meeting.
Halimbawa: hindi lang ang huling task ang sanhi
Sa kathang-isip na software migration, natapos ang rehearsal nang apat na araw ng trabaho lampas sa baseline. Ang unang paliwanag ay “masyadong matagal ang testing.” Babawasan na sana ng team ang susunod na testing window para makahabol.
Sinundan ng review ang ebidensya pabalik. Ang mismong pagsasagawa ng test ay tumagal ayon sa plano. Nahuli ang pagsisimula dahil hindi pa inaprubahan ng operations team na tatanggap sa serbisyo ang test data na kahawig ng production, at hindi available ang pinangalanang approver.
Hindi malulutas ng pagbabawas ng oras sa test ang sanhi at maaari nitong pahinain ang ebidensya ng readiness. Sa halip, nagkasundo ang team na magsagawa ng acceptance check nang mas maaga sa susunod na rehearsal at kumpirmahin ang kapalit na may-ari ng desisyon ayon sa umiiral na patakaran ng approval.
In-update nito ang forecast at nanatiling nakikita ang orihinal na baseline. Itinala ng retrospective ang aral na magagamit muli: tiyakin ang availability ng approver kapag nagpaplano ng dependency sa halip na ipagpalagay na laging available ang pinangalanang may-ari.
May epekto pa rin sa iskedyul. Hindi ito binubura ng magandang paliwanag. Ibinigay sa sponsor ang binagong forecast kasama ang mga opsyon at trade-off, hindi ang pahayag na wala nang halaga ang pagkaantala.
Kailan dapat gumawa ng bagong baseline ang team?
Binabago ng pagbuo ng bagong baseline ang aprubadong sangguniang paghahambingan. Maaari itong maging angkop matapos ang awtorisadong pagbabago sa scope o malaking pagbabago sa commitment sa delivery. Hindi ito dapat maging karaniwang tugon sa hindi magandang variance.
I-archive ang orihinal na baseline, tukuyin ang bagong aprubadong scope at mga petsa, at ipaliwanag kung aling paghahambing ang gagamitin ng mga susunod na ulat. Kung isang work package lang ang nagbago, huwag tahimik na baguhin ang walang kaugnayang kasaysayan.
Makakatulong ang bagong baseline sa pamamahala ng natitirang trabaho habang nananatiling kapaki-pakinabang sa pagkatuto ang luma. Magkatugma ang dalawang layuning ito. Dapat malinaw sa pag-uulat kung ikinukumpara ang isang pahayag sa orihinal na commitment o sa planong inaprubahan kalaunan.
Huwag ipagkamali ang gumaganang forecast at bagong aprubadong baseline. Maaari at dapat maging mas makatotohanan ang forecast nang hindi hinihintay na pormal na muling pag-usapan ang bawat palagay sa pagpaplano.
Gawing kapaki-pakinabang na retrospective ang ebidensya ng iskedyul
Sa susunod na retrospective, pumili ng umuulit na pattern: paghihintay ng approval, minamaliit na integration work, kulang na capacity, o sobrang optimistikong handoff. Iwasang gawing sisihan sa bawat nahuling aktibidad ang meeting.
Itanong kung anong desisyon ang maaari sanang ginawa ng team nang mas maaga gamit ang impormasyong mayroon na. Pagkatapos, magtakda ng eksperimento, gaya ng pagkumpirma sa availability ng reviewer bago mag-commit sa milestone, at ng pagsusuring titingin kung nabawasan ng pagbabagong iyon ang partikular na paghihintay.
Gamitin ang gabay sa retrospective action item para itala ang eksperimento at ang facilitator checklist para ihanda ang talakayan. Nagbibigay ng ebidensya ang iskedyul; nagbibigay ang retrospective ng sinadyang siklo ng pagkatuto.
Mga madalas itanong
Pareho ba ang baseline at deadline?
Hindi. Reference version ng iskedyul ang baseline. Limitasyon o commitment sa oras ang deadline. Maaaring may ilang deadline ang iskedyul, at ipinapakita ng baseline kung paano orihinal na binalak ng team na matugunan ang mga iyon.
Dapat ba naming i-update ang baseline kapag nahuli ang isang task?
I-update ang kasalukuyang forecast para umayon sa realidad. Baguhin lamang ang aprubadong baseline ayon sa napagkasunduang pamamahala ng proyekto, at panatilihin ang dating bersyon at dahilan. Dahil sa palagiang pag-overwrite, mahirap bigyang-kahulugan ang orihinal na performance.
Mapatutunayan ba ng Gantt chart kung bakit nahuli ang proyekto?
Maipapakita ng chart ang oras at mga ugnayan ng dependency, pero hindi nito itinatatag ang lahat ng sanhi. Gamitin ang mga tala ng task, desisyon, ebidensya ng capacity, at salaysay ng mga kalahok para siyasatin ang magkakaibang paliwanag bago pumili ng pagwawasto.