Program Kerja Nampak Lengkap — Tapi Tidak Boleh Digunakan

Pernah jumpa program kerja projek yang nampak lengkap… tapi tidak dapat digunakan di tapak untuk membantu pelaksanaan dan mengawal kemajuan projek?

Aktiviti ada.
Logic ada.
Duration ada.

Semua nampak “betul”.

Tetapi bila masuk tapak — jadual itu langsung tidak dirujuk.

Program Kerja Projek yang tidak digunakan… sebenarnya bukan Program Kerja

Ramai melihat program kerja sebagai dokumen untuk submission.

Selagi:

• boleh “print”
• nampak tersusun
• ada critical path

…ia dianggap “siap”.

Tetapi realitinya berbeza.

Program Kerja tidak diuji semasa submission.
Ia diuji semasa pelaksanaan.

Dan di situlah kebanyakan program kerja projek mula “gagal”.

Di atas kertas vs di tapak: jurang yang jarang dibincangkan

Di atas kertas:

• Urutan kerja nampak logik
• Aktiviti disusun rapi
• Tarikh mula dan siap jelas

Tetapi di tapak:

• Urutan kerja tidak boleh diikuti
• Kerja tidak boleh bermula seperti dirancang
• Kemajuan tidak boleh diukur dengan jelas

Apa yang berlaku seterusnya?

Pasukan berhenti merujuk program kerja.

Kerja tetap berjalan…
Tetapi tanpa panduan sebenar.

Masalah sebenar: bukan software — tetapi struktur

Ini bukan isu Microsoft Project.
Bukan juga isu Primavera P6.

Ini isu yang lebih asas.

Program Kerja Projek dibina tanpa berpandukan cara kerja sebenar di tapak.

Apabila struktur asas salah:

• Logic jadi kosmetik
• Critical path jadi tidak bermakna
• Progress update jadi sukar dipertahankan

Akhirnya, program kerja hanya tinggal sebagai dokumen — bukan alat kawalan.

Kesan ini bukan hanya pada pelaksanaan—
tetapi juga pada bagaimana kemajuan projek dilihat dan dilaporkan.

Apabila program kerja tidak digunakan sebagai asas pelaksanaan,
laporan kemajuan masih boleh kelihatan “baik”—walaupun kawalan sebenar sudah mula hilang.

Ini menjelaskan kenapa S-Curve boleh kelihatan lancar,
tetapi tidak mencerminkan keadaan sebenar projek:
S-Curve kelihatan lancar — tetapi projek sebenarnya sudah bermasalah

Diagnostic Lens: 5 tanda awal program kerja tidak boleh digunakan

Program kerja yang gagal digunakan di tapak jarang berlaku secara tiba-tiba.

Kebiasaannya, kelemahan ini sudah wujud sejak peringkat pembangunan program kerja lagi.

Berikut beberapa petunjuk awal yang boleh dikenal pasti:

1. Aktiviti tidak jelas kaitannya dengan deliverable fizikal

Aktiviti ditulis secara umum:

• “Kerja struktur”
• “Kerja kemasan”

Tetapi apa sebenarnya output yang boleh disahkan di tapak?

Jika tiada deliverable jelas, kemajuan juga tidak boleh diukur secara meaningful.

2. Urutan kerja tidak mencerminkan sequence sebenar tapak

Logic mungkin “betul” secara teori.

Tetapi:

• tidak ikut zoning sebenar
• tidak ikut flow kerja seperti dirancang oleh pengurus projek atau pengurus pembinaan
• tidak ambil kira akses, ruang kerja, atau kekangan sebenar

Program kerja projek nampak logik — tetapi tidak boleh dilaksanakan.

3. Terlalu banyak aktiviti berjalan serentak tanpa kekangan sebenar

Di atas kertas, semuanya boleh jalan parallel.

Di tapak:

• tenaga kerja terhad
• ruang kerja terhad
• peralatan terhad

Jika program kerja tidak mengambil kira realiti ini, ia akan gagal digunakan.

4. Progress tidak boleh diukur secara fizikal

Kemajuan deliverable hanya boleh diukur melalui:

• peratus anggaran
• nilai kewangan

Tetapi tidak berdasarkan kerja sebenar yang siap di tapak.

Ini tanda struktur WBS dan aktiviti tidak dibina dengan betul.

Program kerja nampak “smooth” — tetapi tidak boleh dibina

Tiada gangguan.
Tiada konflik.
Semua nampak lancar.

Tetapi apabila cuba digunakan:

• sequence tidak practical
• aktiviti tidak boleh dimulakan
• dependency tidak realistik

Program kerja kelihatan cantik — tetapi tidak boleh dilaksanakan.

Apa yang membezakan program kerja yang “boleh digunakan”?

Apa yang membezakan program kerja yang benar-benar boleh digunakan bukan pada rupa atau susunannya di atas kertas, tetapi pada bagaimana ia dibina sejak awal.

Jika dirujuk kepada garis panduan penjadualan projek JKR, pembangunan program kerja bukan sekadar menyusun aktiviti — ia bermula dengan struktur WBS yang jelas, diikuti dengan penyusunan logic yang mencerminkan urutan kerja sebenar, sebelum barulah tempoh dan sumber ditentukan.

Ia juga mesti selari dengan realiti pelaksanaan.

Antara ciri asas:

• Disusun berdasarkan sequence pembinaan sebenar
• Dibina berasaskan deliverable fizikal (bukan sekadar trade)
• Membolehkan kemajuan diukur secara jelas di tapak
• Mencerminkan cara pasukan benar-benar bekerja

Apabila langkah-langkah ini tidak diikuti dengan betul, program kerja mungkin masih nampak lengkap — tetapi tidak mempunyai asas yang cukup kuat untuk digunakan dalam mengawal pelaksanaan projek di tapak.

Dari “Approval” ke “Defensible” ke “Control”

Ramai berhenti di peringkat ini:

✔ Program kerja dihantar
✔ Program kerja diluluskan

Tetapi itu belum cukup.

Soalan sebenar:

• Bolehkah program kerja ini dijelaskan dengan yakin?
• Bolehkah ia dipertahankan semasa review?
• Bolehkah ia digunakan untuk mengawal kerja di tapak?

Jika tidak —
program kerja itu belum mencapai tahap defensible.

Dan tanpa defensibility —
tiada kawalan sebenar.

Program kerja projek bukan untuk kelihatan betul — tetapi untuk digunakan

Banyak program kerja wujud dalam rekod submission.

Sangat sedikit yang wujud dalam pelaksanaan.

Perbezaannya bukan pada software.
Bukan pada formatting.

Tetapi pada bagaimana program kerja itu dibina dari awal.

Nak tahu sama ada program kerja projek anda benar-benar boleh digunakan?

Jika program kerja anda:

• sudah dihantar berkali-kali
• sukar dijelaskan semasa review
• atau nampak betul… tetapi tidak digunakan di tapak

Mungkin isu sebenar bukan pada “submission”.

Tetapi pada struktur asas program kerja itu sendiri.

Saya membantu pasukan projek dan reviewer untuk menilai sama ada sesuatu jadual:

• benar-benar selari dengan keperluan penjadualan projek JKR
• boleh dipertahankan semasa penilaian
• dan boleh digunakan untuk kawalan sebenar di tapak

Jika anda ingin lihat di mana kelemahan sebenar program kerja projek anda,
anda boleh mula dengan satu semakan berstruktur — sebelum ia menjadi isu di tapak.

Semakan ini bukan sekadar melihat kepada susunan aktiviti atau tarikh,
tetapi menilai sama ada program kerja tersebut benar-benar boleh digunakan sebagai alat kawalan projek—
daripada struktur WBS, logik turutan kerja, hingga kepada kebolehukuran kemajuan di tapak.

https://coachirwan.com/schedule-health-check

Melalui penilaian ini, isu yang biasanya tersembunyi di peringkat awal boleh dikenal pasti lebih awal — sebelum ia memberi kesan kepada pelaksanaan, koordinasi, dan akhirnya, tempoh siap projek.