RSS Feed (xml)
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
Salam
MYF
--- In Migas_Indonesia@yahoogroups.com, "Alex Iskandar" <axlpce@...> wrote:
>
> 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,
>
> Salam,
> @Iskandar_Alex
> http://axlpce.blogspot.com
> Sent from my BlackBerry® smartphone
>
> -----Original Message-----
> From: "M. P. Budi Arisman" <mp_arisman@...>
> Sender: Migas_Indonesia@yahoogroups.com
> Date: Wed, 26 Oct 2011 13:58:36
> To: <Migas_Indonesia@yahoogroups.com>
> Reply-To: Migas_Indonesia@yahoogroups.com
> Subject: [Oil&Gas] Recovery Schedule Procedure
>
> 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.
>
>
>
> Regards,
>
> MP
>
Portal Industri : http://www.migas-indonesia.com
No E-mail (Web) : Migas_Indonesia-nomail@yahoogroups.com
Daily Digest : Migas_Indonesia-digest@yahoogroups.com
Individual Mail : Migas_Indonesia-normal@yahoogroups.com
Administrator : Migas_Indonesia-owner@yahoogroups.com
Mirror : http://groups.google.com/group/Migas-Indonesia-Google
Untuk pergantian alamat email dan pengiriman attachment
silahkan hubungi webmaster(at)migas-indonesia.com
HAPUS BAGIAN EMAIL YANG TIDAK DIPERLUKAN SEWAKTU REPLY
PENGIRIMAN ATTACHMENT KE MILIS HARUS MELEWATI ADMINISTRATOR
--------------------------------------------------------------
No comments:
Post a Comment