Benrauf Project

14/09/2024

Iklan Jawatan Kosong:
Mencari Graduan Kejuruteraan Awam untuk PROTEGE (batch kedua)
Fresh graduate digalakkan memohon.
Lokasi: Iskandar Puteri, Johor.
Terima kasih.

01/02/2023

Iklan Jawatan Kosong:
Mencari Graduan Kejuruteraan Awam untuk PROTEGE
Fresh graduate digalakkan memohon.
Lokasi: Iskandar Puteri, Johor.
Terima kasih.

Send a message to learn more

17/11/2022

BAGAIMANA MENJANA PLANNED PROGRESS & BASELINE S-CURVE DI MS PROJECT TANPA MEMBUAT KERJA YANG BERULANG-ULANG.

Secara umum di Malaysia, dari aspek jumlah pengguna, lebih ramai pengurus projek menggunakan Microsoft Project (MSP) berbanding Primavera P6. Ini mungkin didorong oleh faktor harga perisian MSP yang lebih mampumilik berbanding P6 membolehkan lebih ramai pengurus projek yang memilih MSP sebagai perisian perancangan projek.

Walau bagaimana pun dari sudut pandang perancang projek, MSP mempunyai banyak kekurangan berbanding P6. Sebagai contoh, di P6, apabila kita menetapkan baseline, baseline tersebut akan disimpan sebagai sebuah program kerja berasingan yang terhubung dengan program kerja semasa, lengkap dengan semua maklumat-maklumatnya. Tetapi di dalam MSP, baseline hanya boleh disimpan sebagai data di dalam program kerja yang sama, dan maklumat yang tersimpan terhad kepada column-column yang tersedia di dalam MSP.

Oleh kerana kekangan ini, MSP tidak boleh menjana kemajuan dirancang (Planned Progress) secara terus di dalam program kerja yang dikemaskini (Updated work program). Kebiasannya, apa yang dilakukan oleh hampir majoriti pengurus dan perancang projek di Malaysia adalah mengemaskini program kerja Baseline untuk mendapatkan kemajuan dirancang, dan seterusnya memindahkan maklumat tersebut ke dalam column kosong di dalam program kemaskini (Updated program).

Ini tentunya melecehkan bagi kebanyakan perancang projek kerana maklumat kemajuan dirancang (Planned progress) tidak dapat dijana secara langsung, tidak seperti ketika menggunakan P6. Tambah menyusahkan apabila ada sebahagian pengurus dan perancang projek yang menggunakan kaedah yang sama ini untuk menghasilkan S-Curve Baseline. Jika ada 300 cutoff date dalam S-Curve yang perlu dikemaskini, pengurus projek akan mengulangi proses ini sebanyak 300 kali juga. Jika sewaktu projek berjalan, berlaku perubahan tarikh cutoff date, pengurus dan perancang projek tersebut akan mengulangi semula proses yang panjang ini.

Sebenarnya, ada kaedah yang jauh lebih mudah dan menjimatkan banyak masa untuk mendapatkan maklumat kemajuan kemaskini dirancang bagi sesuatu projek. Satu kelebihan pada MSP adalah ia membenarkan perancang projek untuk membuat customized formula menggunakan column-column kosong yang disediakan di dalam program kerja.

Terdapat banyak formula yang boleh digunakan bergantung kepada kekreatifan perancang projek dan maklumat yang ingin diperolehi. Di dalam video ini ada ditunjukkan sedikit demonstrasi bagaimana program kerja yang menggunakan customized formula dapat menjana maklumat kemajuan dirancang (Planned Progress) hanya dengan menukar Status Date (Tarikh terkini) program kerja semasa sahaja.

Begitu juga dalam penghasilan Baseline S-Curve. Masih ramai pengurus dan perancang projek yang mengulang kemaskini program Baseline bagi mendapatkan data S-Curve dirancang, terutamanya bagi projek yang menggunakan pemberat masa (Duration weightage). Sebenarnya terdapat banyak kaedah yang boleh digunakan bagi menjana S-Curve yang lebih pantas dan tepat. Contohnya dengan menggunakan Task Usage view, penjanaan pivot table, ataupun penjanaan laporan (Report) bergantung kepada kreativiti perancang projek masing-masing.

Kongsikan pengalaman anda p**a. Bagaimana biasanya anda mengemaskini kemajuan dirancang untuk projek anda?

Benrauf Project juga mengucapkan selamat menunaikan tanggungjawab mengundi kepada seluruh pembaca dan rakyat Malaysia. Ke arah Malaysia yang maju, sejahtera dan menjunjung demokrasi.

Like page Benrauf Project untuk mendapatkan lebih informasi berkaitan pengurusan projek.

26/09/2022

Cara-Cara Membina Pile Cap tanpa Piling. (Isu berkenaan "negative lag" dan "positive lag")

Dalam satu pembinaan bangunan yang biasa, kita mulakan dengan kerja-kerja penanaman cerucuk (piling). Logiknya jika ada 2000 batang cerucuk yang perlu ditanam, kita tidak akan menunggu keseluruhan 2000 batang cerucuk selesai ditanam untuk memulakan kerja-kerja seterusnya seperti topi cerucuk (Pile Cap). Katakan kerja Pile Cap dimulakan selepas cerucuk ke 785 selesai ditanam, bagaimana anda menunjukkan aliran kerja ini di dalam program kerja anda?

Pertama yang paling biasa adalah dengan memecahkan kerja kepada zon-zon yang lebih terperinci sewaktu penstrukturan Work Breakdown Structure (WBS). Contohnya Zon 1 untuk Piling 1-785, Zon 2 untuk Piling 786-1572 dan Zon 3 untuk Piling 1573-2000 dan seterusnya. Dengan membuat zoning, adalah lebih mudah untuk menunjukkan kenapa dan bagaimana sesuatu kerja "Successor" boleh bermula tanpa menunggu kerja "Predecessor"nya selesai sepenuhnya. Walau bagaimana pun, ada beberapa keadaan di mana kerja-kerja yang berkaitan ini tidak dapat dizonkan secara terperinci. Contohnya bagi skop kerja yang terlalu kecil atau skop kerja yang terlalu banyak untuk dizonkan secara keseluruhan. Di sini kebiasaanyanya pengurus projek akan menggunakan Tundaan atau "Lag". Lag adalah satu tempoh yang ditetapkan sebelum kerja "Successor" boleh dimulakan.

Dalam kaedah ini, ada sebahagian pengurus projek yang menggunakan hubungan "Finish-to-Start" (FS) dan Tundaan Negatif (-ve lag), dan ada p**a yang menggunakan hubungan "Start-to-Start" (SS) dan Tundaan Positif (+ve lag) untuk menggambarkan situasi kerja "Successor" bermula sebelum "Predecessor" siap. Di antara kedua kaedah ini yang mana yang lebih tepat dan benar? Adakah betul teori-teori konspirator yang mengatakan penggunaan -ve lag dalam program kerja adalah salah dan bakal menghuru-harakan program kerja? Sebenarnya kedua-dua kaedah ini adalah bergantung kepada perancangan sebenar dan logik aktiviti.

Dari sudut pandang perancangan projek, aspek yang paling penting adalah Aktiviti Kritikal (Critical works) dan Laluan Kritikal (Critical Path) program kerja tersebut. Tahap kritikal sesuatu kerja ditentukirakan dengan tempoh Kelegaan (Float). Jika dibandingkan kedua-dua kaedah FS & -ve lag, dan SS & +ve lag, kita mendapati tempoh float kedua-dua kaedah ini adalah sama (dalam peringkat penyediaan program). Jadi adakah wujud perbezaan di antara kedua kaedah ini? Seperti yang dimaklumkan, pemilihan kaedah yang sesuai hendaklah melihat kepada apa perancangan sebenar dan logik aktiviti-aktiviti yang terlibat. Bagi contoh yang diberi di atas, pengurus projek hendaklah membuat analisis aliran kerja.

1. Adakah benar kerja Pile Cap boleh dimulakan selepas satu tempoh kerja Piling dimulakan (Hubungan SS & +ve lag). Jika benar, kemungkinan hubungan SS & +ve lag boleh digunakan untuk menunjukan aliran kerja ini. Kita teruskan dengan soalan seterusnya.

2. Bolehkan kerja Pile Cap disiapkan tanpa kerja Piling disiapkan? Tentu sahaja tidak. Bagaimana p**a kerja menanam Piling hendak dibuat jika bongkah Pile Capnya sudah terbina di atasnya. Pile Cap hanya boleh dibina selepas cerucuk telah selesai ditanam. Oleh itu, perlulah ada hubungan di antara penyiapan (Finish) kerja Piling dengan permulaan (Start) Kerja Pile Cap. Justeru, hubungan yang paling sesuai untuk menunjukkan aliran kerja ini adalah FS & -ve lag dan bukan SS & +ve lag.

Apa impaknya pada program kerja jika pengurus tetap memilih hubungan SS? Kita tahu bahawa di peringkat penyediaan program kerja, tempoh float kedua-dua kaedah ini adalah sama. Oleh itu tiada sebarang masalah jika penyediaan program kerja itu bertujuan untuk program kerja awalan, atau program kerja rujukan. Tiada perbezaan (yang ketara) dari jumlah Float bagi kedua-dua kaedah yang digunakan. Akan tetapi, perbezaan yang sangat signifikan akan terjadi apabila program ini digunakan bagi tujuan pengemaskinian kemajuan (Progress Update).

Bagi aliran kerja yang menggunakan hubungan SS, sebaik sahaja kerja predecessor bermula (mempunyai peratus kemajuan), hubungan di antara predecessor dan successor telah disempurnakan, atau dalam perkataan lain hubungan ini telah terputus. Predecessor tidak lagi mempunyai hubungan dengan successornya. Oleh yang demikian, float kerja predecessor akan terus melonjak naik sehingga tempoh tamat projek. Ini kerana permulaan kerja successor hanya bergantung kepada permulaan kerja predecessor, tanpa mengira sama ada kerja tersebut siap atau tidak. Baki tempoh kerja predecessor kini tidak akan memberi sebarang pengaruh atau halangan kepada kerja predecessor.
Apa-apa kelewatan pada predecessor tidak lagi mempengaruhi penyiapan successor. Ini menyebabkan aliran kerja tidak lagi tepat dan MS Project tidak dapat merancang tarikh penyiapan dengan betul. Kita mungkin akan menemui kes-kes aneh seperti kerja Pile Cap disiapkan lebih awal dari Piling, atau Suspended Beam/Slab lebih awal dari Ground Column.

Berbeza dengan hubungan FS & -ve lag, hubungan yang terjalin tidak terputus apabila kerja predecessor bermula kerana pergantungan kerja successor adalah kepada penyiapan ("Finish") kerja predecessor. Hubungan ini hanya akan dianggap sempurna selepas kerja predecessor telah selesai sepenuhnya (seratus peratus "100%"). Oleh itu predecessor akan sentiasa memberi pengaruh kepada successornya selagi kerja tersebut belum disiapkan. Lewat siap predecessor, lewat jugalah successornya.

Berkenaan dakwaan penggunaan FS dan -ve lag akan menghuru-harakan program kerja, setelah merujuk kepada beberapa pengurus program dan perancang berpengalaman, setakat ini tiada sebarang masalah signifikan berpunca dari kewujudan -ve lag kecuali akibat zoning yang tidak terperinci. Masalah ini juga akan turut akan dialami jika menggunakan SS & +ve lag. Justeru larangan menggunakan -ve lag tidak akan menyelesaikan masalah ini, bahkan menambah lagi masalah yang baru. Secara kesimp**annya, ketakutan terhadap -ve lag ini berkemungkinan hanyalah sebuah konspirasi tidak berasas oleh golongan maksum yang mempunyai banyak masa lapang. Bagaimana p**a dengan pendapat anda. Kongsikan pengalaman dan ilmu bermanfaat anda.

Like page Benrauf Project untuk mendapatkan lebih informasi berkaitan pengurusan projek.

05/07/2022

CANCER SPLIT

"Kerja seminggu boleh jadi sebulan"

Fungsi Ceraian (Split) untuk menunda sebahagian tempoh daripada sesuatu task lebih lewat berbanding bahagian sebelumnya. Split boleh terjadi secara terancang (Planned Split) yang dibuat sewaaktu perancangan asal atau kerana proses penjadualan semula (Rescheduling Split) task yang terlewat.

Selain dari dua jenis split di atas, terdapat split yang tidak dikehendaki yang dinamakan "Cancer Split". Cancer split terjadi kerana kecuaian pengurus program kerja ketika mengemaskini kemajuan.

Kesan daripada cancel split adalah, kelewatan task yang memiliki cancer split akan menjadi lebih tinggi berbanding kelewatan yang sepatutnya. Ini kerana tempoh (duration) yang dimiliki oleh cancer split akan menolak baki tempoh (remaining duration) task tersebut ke depan.

Task A dalam rajah mempunyai 11.5 hari baki duration. Walau bagaimana pun, terdapat 2 cancer split yang mempunyai tempoh keseluruhan sebanyak 6.5 hari. 6.5 hari cancer split ini akan menolak 11.5 baki duration Task A ke depan mengakibatkan Task A hanya dapat disiapkan pada hari ke 18 daripada cutoff date.

Bagi mengelakkan berlakunya cancer split, langkah berikut boleh diambil.

1. Kemajuan sesuatu task mestilah lebih tinggi atau sama dari laporan sebelumnya.

2. Jika terdapat pengubahsuaian kemajuan pada program kerja laporan sebelumnya, gunakan fail sebelum daripada program kerja yang diubahsuai. Jika pengubahsuaian diperlukan untuk program minggu lepas, gunakan fail 2 minggu sebelumnya.

3. Sesetengah pengurus program juga lebih s**a membuat kemaskini menggunakan fail asal (baseline). Ini juga boleh mengelakkan terjadinya cancer split.

Like page Benrauf Project untuk mendapatkan lebih informasi berkaitan pengurusan projek.

02/07/2022

PRO & KONTRA PENGGUNAAN DURATION [% Complete] DALAM PENENTUAN KEMAJUAN FIZIKAL PROJEK. PROJECT AHEAD TAPI PROGRESS MEROSOT?

/*Disclaimer. Post ini panjang*/

Umumnya ada 3 kaedah penentuan kemajuan fizikal (Physical Progress) yang paling biasa dipraktikkan dalam projek-projek di Malaysia:

i. Kemajuan projek yang dinilai berasaskan manhour. Ini adalah definisi Physical Progress yang paling tepat. Kaedah ini biasa digunakan bagi projek yang mempunyai data resource yang lengkap. Dalam , ia ditunjukkan sebagai [% Work Complete]. Pengiraannya didefinisikan sebagai Progress = [Actual Manhour](cumulative manhour used as at cutoff date)÷[Total Manhour].

ii. Kemajuan projek yang dinilai berasaskan kos kerja-kerja fizikal. Kaedah ini sama seperti pengiraan kemajuan kewangan (Financial Progress), cuma tidak memasukkan kos bukan fizikal seperti prelim, tax dsbg. Kaedah ini diperkenalkan kerana pertama, bagi pihak klien, tentulah lebih berminat mengetahui berkenaan kos yang dibelanjakan berbanding melihat jumlah manhour yang telah dilaksanakan. Informasi berkaitan manhour ini sebenarnya lebih memanfaatkan kontraktor kerana kebiasaannya kos untuk sesuatu kerja yang dibayar oleh klien adalah malar (jika tiada perubahan) regardless berapa resource dan masa yang diperlukan oleh kontraktor. Pengiraannya didefinisikan sebagai Progress = [Actual Cost](cumulative cost spent as at cutoff date)÷[Total Cost].

iii. Satu lagi kaedah yang biasa digunakan di Malaysia adalah kemajuan projek yang dinilai berasaskan tempoh (duration) kerja. Dalam , ia ditunjukkan sebagai [% Complete]. Kaedah ketiga ini akan dibincangkan dalam post ini.

Penggunaan duration dalam pernilaian kemajuan projek sering digunakan oleh projek-projek yang menggunakan . Ini kerana adanya column [% Complete] yang telah disediakan dalam .

Pengiraannya didefinisikan sebagai Progress = [Actual Duration](total duration lapsed as at cutoff date)÷[Total Duration].

Bagi pengiraan kemajuan untuk Summary Task p**a, Progress (Summary) = Σ[Actual Duration] (Hasil tambah [actual duration] bagi semua subtask)÷Σ[Total Duration] (Hasil tambah [duration] bagi semua subtask).

PRO menggunakan Duration dalam penentuan kemajuan:
1. Kemajuan dapat ditentukan hanya berdasarkan pecahan kerja (WBS/Work Breakdown Structure), dan tidak memerlukan maklumat pecahan kos (CBS/Cost Breakdown Structure) dan resource (RBS/Resource Breakdown Structure). Ini memudahkan bagi pengguna asas .
2. Penentuan kemajuan juga mudah kerana telah ada column [% Complete] berbanding jika menggunakan kaedah berasaskan Cost yang memerlukan customized formula. Sebahagian pengurus projek juga menganggap [% Complete] adalah sempurna dan maksum dan tidak gemar menggunakan customized formula.
3. Kaedah ini juga paling banyak digunapakai di Malaysia, kerana telah lama diaplikasikan dalam kebanyakan projek-projek kerajaan kerana penggunaan yang lebih meluas berbanding .

KONTRA menggunakan Duration dalam penentuan kemajuan:
1. Pengagihan pemberat (weightage) yang tidak tepat. Ini adalah keburukan yang signifikan dan terbesar dalam penggunaan kaedah Duration.

Contoh Kes 1: Task yang memerlukan duration yang pendek, tetapi mempunyai subtask yang banyak, boleh memiliki weightage yang lebih besar berbanding task yang memerlukan duration yang panjang tetapi tidak dipecahkan atau mempunyai subtask yang sedikit. Ini kerana weightage bagi Summary Task adalah hasil tambah semua Duration bagi subtask-subtasknya. Sebagai contoh bandingkan kedua task A dan B di bawah.

Task A: 1/1 - 29/2 (60 hari)
Subtask A1: 1/1 - 31/1 (31 hari)
Subtask A2: 1/2 - 28/2 (29 hari)

Jumlah weightage Task A = 31 + 29 = 60 hari

Task B: 1/1 - 14/1 (14 hari)
Subtask B1: 1/1 - 3/1 (3 hari)
Subtask B2: 1/1 - 4/1 (4 hari)
Subtask B3: 2/1 - 10/1 (9 hari)
Subtask B4: 3/1 - 11/1 (9 hari)
Subtask B5: 3/1 - 13/1 (11 hari)
Subtask B6: 4/1 - 13/1 (10 hari)
Subtask B7: 5/1 - 14/1 (10 hari)
Subtask B8: 7/1 - 12/1 (6 hari)
Subtask B9: 10/1 - 13/1 (4 hari)
Subtask B10: 10/1 - 14/1 (5 hari)
Subtask B11: 14/1 - 14/1 (1 hari)

Jumlah weightage Task B = 3 + 4 + 9 + 9 + 11 + 10 + 10 + 6 + 4 + 5 + 1 = 72 hari

∴ Walaupun Duration Task A (60 hari) lebih besar dari Task B (14 hari), Task B mempunyai weightage yang lebih besar (72 hari) berbanding Task A (60 hari) kerana hasil tambah duration subtasknya yang lebih banyak, padahal kemungkinan Task A juga mempunyai lebih banyak subtask berbanding Task B tetapi tidak dipecahkan kerana kekurangan maklumat atau untuk meringkaskan kerja pemantauan kemajuan.

Contoh Kes 2: Kerja yang siap awal mempunyai weightage yang lebih rendah, manakala kerja yang siap lambat mempunyai weightage yang lebih tinggi berbanding program kerja asal.

Program Kerja Asal (Baseline Work Programme)
Overall Project: 1/1 - 31/3
Task C: 1/1 - 31/1 (31 hari)
Task D: 1/2 - 31/3 (60 hari) /*tahun lompat*/
Task E: 1/3 - 31/3 (31 hari)

Dalam program kerja asal, weightage Duration yang diberikan oleh setiap task adalah seperti berikut:
Σ[Total Duration] = 31 + 60 + 31 = 122 hari (100%)
Weightage Task C = 31/122 = 25.4%
Weightage Task D = 60/122 = 49.2%
Weightage Task E = 31/122 = 25.4%

Walaubagaimana pun weightage setiap task biasanya akan berubah dan tidak sama semasa projek berlangsung kerana tarikh mula dan siap sebenar (actual start & actual finish) setiap task dalam program kerja sebenar tidak sama dengan program kerja asal.

Program Kerja Sebenar (Actual Work Programme)
Overall Project: 1/1 - 30/4
Task C: 1/1 - 14/1 (14 hari)
Task D: 15/1 - 31/3 (77 hari)
Task E: 31/3 - 30/4 (31 hari)

Weightage setiap task terkini
Σ[Total Duration] = 14 + 77 + 31 = 122 hari (100%)
Weightage Task C = 14/122 = 11.5%
Weightage Task D = 77/122 = 63.1%
Weightage Task E = 31/122 = 25.4%

Task C yang siap awal, iaitu 14 hari berbanding 31 hari seperti yang dirancang mengalami penurunan weightage daripada 25.4% kepada hanya 11.5%.

Task D yang siap lewat, iaitu 77 hari berbanding 60 hari seperti yang dirancang, mengalamai peningkatan weightage daripada 49.2% kepada 63.1%.

Kurang kesedaran terhadap perubahan weightage ini menyebabkan timbul isu kenapa "Projek ahead tapi progress merosot" atau "Project delay tapi progress meningkat".

Like page Benrauf Project untuk mendapatkan lebih informasi berkaitan pengurusan projek.

09/04/2022

Delay Analysis.
What cause a delay? Who own the delay? How to justify it?