Recovery Schedule, sesuai dengan arti harfiahnya, Recover: kembali ke keadaan semula. Artinya schedule yang telah terlambat dan kemudian diperlukan percepatan, baik paralel working maupun akselerasi dengan penambahan manpower etc, yang digambarkan didalam setiap garis-garis aktifitasnya didalam jadwal kerja (schedule).

Tanya – ‘M. P. Budi Arisman’

Dear rekans migas,

Mungkin dari rekans sekalian pernah membuat procedure tentang Recovery Schedule, saya mohon bantuannya untuk bisa memberi masukan.
Appreciate for your kind favor. Thanks.

Tanggapan 1 – ‘Alex Iskandar’

Halo pak Arisman,

Kalau boleh saya menerangkan, sebatas pengetahuan saya.

Recovery Schedule, sesuai dengan arti harfiahnya, Recover: kembali ke keadaan semula…

Artinya schedule yang telah terlambat dan kemudian diperlukan percepatan, baik paralel working maupun akselerasi dengan penambahan manpower etc, yang digambarkan didalam setiap garis-garis aktifitasnya didalam jadwal kerja (schedule).

Sehingga kalau digambarkan dalam S-curve, S-curve dari actual progress (karena terlambat dari rencana awal), kemudian akan diteruskan oleh curva recovery plan ini, kemudian akan melampaui / bertemu dengan kurva rencana awal. Dan S-curve recovery ini akan terlihat menanjak tajam (accelerate) dibanding dengan curva rencana awal. Sementara end datenya tetap (dan memang seharusnya tetap, karena namanya recovery plan).

Jadi menurut saya, apabila diperlukan prosedure untuk melakukan Recovery Schedule, maka yang paling penting untuk dituliskan adalah requirement2 nya untuk dapat mengejar progres kembali, yang mana perlu diberi penjelasan tentang:

– percepatan/akselerasi program apa saja yang digunakan,

– paralel works yang bisa dilakukan,

– double efforts dlsb

Disinilah perlu adanya keterangan dan penjelasan dari recovery plan tersebut dengan menunjukkan sequence logic dan data-data yang bisa dipertanggung jawabkan. (Agresif – Realistic Plan).

Selanjutnya pertanyaannya kapankah perlu dilakukan recovery plan? Karena pada kenyataannya keterlambatan proyek sudah jamak terjadi.

Dari beberapa referensi yang saya dapatkan, biasanya recovery plan diperlukan kalau progres sudah selisih 5-10% dari rencana awal, dan nilai selisih progress ini bisa berbeda dari satu perusahaan dg yang lain, sesuai dg referensi dan prosedur yang digunakan.

Link berikut merupakan penjelasan mengenai Recovery schedule sebagai referensi juga:

http://www.warnercon.com/articles/Article%2012%20-%20Recovery%20Schedules.pdf

Namun kalau ternyata yang dimaksud adalah perubahan Jadwal Kerja (Schedule) yang sudah berubah dari milestones2 yang telah disepakati bersama, artinya ini sudah termasuk dalam Perubahan Lingkup Kerja (PLK) atau yang biasa disebut dalam mekanisme Change Order.

Secara prosedural, dalam pembuatan perubahan jadwal kerja (bukan recovery schedule lagi), dalam sebuah proyek yang terikat dalam kontrak, harus merujuk pada kontrak dokumen yang telah disepakati oleh para pihak. Terutama dalam exhibit: Schedule / Jadwal Kerja dan juga Exhibit: Changes / Perubahan.

Disanalah diatur tentang bagaimana menangani perubahan terhadap schedule dengan mekanisme Changes Management.

Inisiasi perubahan juga (biasanya) diatur, bisa dari Kontraktor (initiated by Contractor) maupun sebaliknya, dari pihak pemberi kerja (Klien).

Dan dikarenakan perubahan jadwal kerja sangat erat kaitannya dengan perubahan biaya (begitupun sebaliknya), maka bisa jadi ada cost Impact terhadap perubahan tersebut, apabila dikarenakan faktor2 yang dapat digunakan sebagai inisiasi perubahan bukan merupakan kesalahan kontraktor, maka Cost Impact nya dapat di bebankan kepada klien sebagai pekerjaan tambah.

Tentunya hal ini diperlukan pembuktian dengan data dan informasi yang valid.

Begitupun sebaliknya, bila memang tidak ada satupun faktor2, yang secara kontraktual dapat digunakan sebagai landasan inisiasi perubahan, sebagai basis untuk merubah jadwal kerja,

Maka biasanya klien akan meminta Recovery Schedule (tanpa merubah end date) seperti yang saya tuliskan diatas, dan konsekwensi dari terlambat ini biasanya adalah pinalti yang besarnya 1/mil perhari dari nilai kontrak, dari setiap keterlambatan setiap milestones yg disepakati.

Maka disinilah disputes sering terjadi dalam sebuah kontrak. Terutama dalam konteks ini, perubahan jadwal kerja.

Oleh karena itu, sebagai pembelajaran, sangat diperlukan dokumentasi, filing dan korespondensi yang baik sehingga dapat dijadikan ‘hard evidence’ dalam sebuah disputes dalam proyek.

Semoga saja bermanfaat,

Tanggapan 2 – Rusydi

Saya hanya menambahkan.

Recovery plan hanya diperlukan bila terjadi keterlambatan aktivitas2 yg berakibat pada keterlambatan project completion date secara keseluruhan.

Step2 yg perlu dilakukan untuk membuat recovery plan adalah sbb:

1. Identifikasi Aktivitas2 yg terlambat/delay yang menyebabkan keterlambatan proyek secara keseluruhan. Jadi, aktivitas2 yg berada di jalur kritis saja yg di analisa. Namun tidak menutup kemungkinan aktivitas diluar jalur kritis bisa menjadi kritis akibat delay yg berkepanjangan. Identifikasi dilakukan dengan melihat float dr msg2 aktivitas tersebut (dgn menggunakan software MSP/P6). Bila floatnya negatif maka aktivitas tersebut dinyatakan terlambat dan bisa berakibat keterlambatan keseluruhan proyek.

2. Selanjutnya aktivitas2 tersebut dianalisa berapa hari durasi yang tersisa untuk menyelesaikan aktifvitas tersebut, apa penyebab keterlambatannya. Apakah akibat kekurangan manpower, material, perubahan design, faktor cuaca atau karena efek keterlambatan dari aktifitas predecessornya. dll.

3. Langkah berikutnya adalah membuat recovery plan pada aktivitas2 tersebut sedemikian rupa sehingga keterlambatan bisa dikejar dan target completion datenya bisa dipertahankan. Pada recovery plan ini juga harus dijabarkan langkah2 yg diambil untuk mengejar keterlambatan tersebut. Seperti, menambah waktu kerja (lembur), menambah manpower, menambah peralatan, mengubah metode kerja, dll.

4. Bila recovery plan yg dibuat telah di setujui untuk di laksanakan, maka langkah selanjutnya adalah memonitor pelaksanaannya.

Hal yg sering menjadi pertanyaan adalah pihak mana yang menanggung extra cost yang timbul akibat recovery plan tersebut. Untuk ini maka perlu analisa lebih lanjut untuk mengetahui apakah keterlambatan diakibatkan oleh kontraktor atau owner.

Tanggapan 3 – ‘Yusranil’

Pak Alex, thanks atas pencerahan dan share link articlenya, maaf ikutan nimbrung nanya, walau agak sedikit meleset..

Saya tertarik dengan statement ini dalam artikel tsb.

‘By creating a recovery schedule, the contractor may be admitting that the delays are his responsibility’.

Diluar masalah clause contract, apakah fakta recovery schedule bisa dianggap dan dijadikan dalih bagi owner/client untuk membebaskannya dari tanggung jawab jika mereka (client) yang menyebabkan delay?? let say delay in approval procedure?

Dan berikutnya, kapan sebenarnya waktu yang tepat bagi Contractor untuk mulai menghitung opportunity terhadap potensi additional worksnya, karena ngomong additional works di awal eksekusi dengan client, (sering) berdampak pada kurang harmonisnya proses eksekusi project tsb.

Thanks atas pencerahannya.

Tanggapan 4 – ‘Sketska N.’

Pak Yusranil,

Seandai nya ikut discuss seminar tentang Management of Change (MOC) maka akan cukup membantu memahami hal ini.

Ditempat saya bekerja, dalam lingkup prosedur kita ada ‘Excuseable Delay’ yg pada inti nya Sched delay disebabkan karena Client. Technically, ini saya hitung lalu di input kan secara sederhana dgn software yang kita gunakan ie. MSP atau Primavera. Bergantung Client nya bapak dan cek betul2 prosedur mereka.

Bicara approval, di push benar2 dan buatkan resmi karena project kita bicara Legal – Formal. Mungkin ‘zaman dahulu’ bisa koboi akan tetapi hari ini kita semakin improve dan professional.

VO / Variation Order, jangan pernah berharap banyak terkecuali jika sudah ada Legal – Formal nya.

Jadi bapak yang lebih memahami (Beyond of understanding) apa tujuan dari Recovery Schedule?

Jika prosedur nya belum ada, maka sebagai Kontraktor dapat mengajukan nya kepada Client. Sukses dengan project nya disana.

Tanggapan 5 – Cahyo Laksono Hadinoto

Dear Pak Yusranil,

Wah, pertanyaan yang menggelitik nih, hehe…

Jikalau saya baca statement ”By creating a recovery schedule, the contractor may be admitting that the delays are his responsibility’.

Disitu ada kata2 ‘May be’,

Sebenarnya recovery schedule tidak bisa spenuhnya dapat dimanfaatkan oleh Client untuk berdalih bahwa keterlambatan diakibatkan oleh pihak Contractor.

Dan ini tentu wajib hukumnya bagi seorang planner benar2 memahami betul clausal2 didalam document contract.

Jadi ingat dulu, setiap pergerakan yang berdampak baik langsung maupun tidak langsung terhadap berjalannya progress, akan selalu ter-record, terdokumentasi dengan baik.

Banyak diantara record tersebut perlu mendapatkan confirmasi dari pihak Client, yang mana nantinya ‘dapat bermanfaat’ dikemudian hari.

Mungkin disinilah celah2 untuk dapat ber-argument dengan Client untuk schedule recovery dimana ‘May Be’ tadi tidak dimanfaatkan oleh Client.

Tentu, semua itu tidaklah lepas dari document contract.

ngomongin additional work diawal project, bisa2 termin pembayaran tersendat,

Meski biasanya pada saat bidding period pun kita2 yang di posisi kontraktor sudah memikirkan + memperhitungkan ‘additional work’,

Tanggapan 6 – ‘Alex Iskandar’

Sama-sama pak Yusranil, Senang juga bisa bermanfaat…

Rekan Cahyo, pak Yusranil,

Saya kira statement di makalah itu memang merupakan best practices, dan memberikan gambaran mengenai options ketika kontraktor menerima request utk membuat recovery schedule secara resmi dari owner. Dan advise step by step dalam posisi kontraktor, untuk MENGHINDARI ‘admitting that the delays are contractor responsibility’….

Silahkan dibaca lagi makalah tersebut…

http://www.warnercon.com/articles/Article%2012%20-%20Recovery%20Schedules.pdf

Seperti komentarnya mbak Vinny dan Hal yang ditambahkan pak Rusydi, yang sangat bagus sekali tentang step2 dalam pembuatan recovery schedule, juga menyebut soal cost impact yang kemudian menjadi disputes: ‘pihak mana yang menanggung extra cost yang timbul akibat recovery plan tersebut? Untuk ini maka perlu analisa lebih lanjut untuk mengetahui apakah keterlambatan diakibatkan oleh kontraktor atau owner’

Dan seperti yang saya tuliskan sebelumnya dan ditegaskan lagi oleh Sketska. Bahwa ‘VO / Variation Order, jangan pernah berharap banyak terkecuali jika sudah ada Legal – Formal nya’

Mungkin dapat diambil kesimpulan bahwa:

1.DOKUMENTASI: Dalam setiap pembuatan recovery schedule, sebaiknya diberikan analisa secara logis, sebab-sebab terjadi keterlambatan.

– Approval drawing etc dari client yang lama?

– Keterlambatan material dari client / contractor supplied items?

– permasalahan custom clearence / master list ?

Dst..

Semua itu harus dibandingkan dengan rencana awal yang telah disepakati bersama dalam Master Project Schedule, artinya Recovery Schedule ini yang nantinya akan menggantikan MPS yang sdh obsolute.

Dan perlu diingat, semua ini harus TERTULIS dan TERCATAT dalam dokumen resmi yang mempunyai legal standing (berdasarkan kontrak)

Tanpa semua itu maka semua claim dapat dabaikan karena ketidak tersediaan data yang memenuhi syarat.

2. TIMING: Soal timing untuk memberitahukan kepada Client, ini juga soal yang sangat penting karena biasanya Contractor malu atau ‘jengah’ dengan memberitahukan kepada client soal ini, karena dianggap akan mengganggu relationship yang bagus, (atau sengaja mempersiapkannya diakhir periode kontrak ??)

Tapi ini adalah bad practicess, yang menyimpan bom waktu di akhir proyek.

Apalagi dalam proyek lingkupan BPMIGAS, telah banyak diatur bahwa capping Change Order maksimal 10% dari plafon AFE (walaupun masih ada kemungkinan dengan persetujuan BPMIGAS tentunya). Termasuk mekanisme pelaporannya yang sekarang lebih rigid dan harus menginformasikan lebih awal dalam PTK 007 rev.2 yang baru ini.

Tanggapan 7 – insy rahman

Dear Pak Arisman dan All,

Menambahkan dari keterangan rekan Alex ya:

Recovery Schedule bermakna mengembalikan schedule pada posisi semula/ kondisi baseline dengan pencapaian tanggal finishnya sesuai kontrak lagi…

ada 2 metode yang digunakan untuk menterjemahkan Recovery Schedule:

1. Fast track: Melakukan pekerjaan secara pararel, terutama pada lintasan kritis

2. Crash program: memendekkan durasi pekerjaan, terutama pada lintasan kritis

kedua metode diatas akan mengakibatkan penambahan biaya, tetapi ini adalah bagian dari resiko keterlambatan.

Mengenai keterlambatan yang disebabkan oleh owner/ client, maka ada pasal ‘Excusable Delay’ seperti yang diterangkan oleh rekan sketska, dimana akan diberi perpanjangan durasi pekerjaan, namun seandainya pihak client/owner mengiginkan Recovery Schedule, maka masuk dalam pasal Acceleration Schedule dan kontraktor berhak mengajukan Change Order/pekerjaan tambah..

cmiiw

Tanggapan 8 – ‘Yusranil’

Dear Bapak2

Thanks atas sharingnya,

Kalau saya perhatikan intinya adalah pemahaman Project management baik dari sisi Kontraktor maupun Client, dengan mengacu ke contract legal formal, namun itu dalam kondisi ideal.

Sayangnya, di negara kita tercinta ini, terutama di project-project non Migas, tidak semua client memiliki team Project Management yang memiliki pemahaman tentang rules Project Management yang baik, dan pendekatannya lebih sering ke arah ‘non teknis’. Dan ini tantangannya.

Ketika berhadapan dengan project2 Migas, hampir semua masalah bisa tercapture dengan contract maupun procedure2 yang kita (Client & Contractor) develop. Mulai dari Contract document, project Contrtol Plan, bahkan sampai Recovery Schedule Procedure yang sebenarnya (aslinya) mau dibahas disini.

Tantangan bagi seorang Scheduler yang memahami Project Management rule ketika harus berhadapan dengan Client yang mempunyai project dengan contract yang banyak potensi disputenya terutama scope of worksnya, client selalu meminta schedule ahead, sementara Variation Order menjadi issue yang sensitive. Kondisi seperti ini memang memiliki ketidak pastian yang tinggi, namun terlihat tetap ada opportunity.

Concern saya, bagaimana menyiasati Client, terutama client dengan top management dari Asia Selatan dengan eksekutor lapangan orang kita yang lebih suka pendekatan non teknis.

Sehingga Team project management sukses mengeksekusi project tsb tanpa harus menyebut pengadilan, dan team marketing tetap dapat menjaga peluang untuk upcoming project2 lainnya.

Sekali lagi terima kasih banyak kepada Bapak2 atas sharingnya, semoga diskusi PMT ini semakin menarik untuk pencerahan terutama yang junior seperti saya.