World of though, through share and action..

Dalam menyusun kontrak dokumen hindari bahasa kontrak yang abu-abu, pastikan semua definitive, jangan sampai ada dua atau bahkan lebih persepsi terhadap kata-kata /wording didalam kontrak. Ini akan menjadi awal dari perbedaan, argumen dan akhirnya menjadi sebuah disputes... dan akhirnya menjadi sebuah perubahan (Changes)
Peranan kontrak admin dan Project Engineer sangatlah dominan disini.


1. Sepanjang sepengetahuan saya, IMHO, saya belum menemukan referensi "Program of Performance" dari standard PM yang saya ketahui.
Namun apabila yang dimaksudkan dengan Project Performance Plan / program (rencana).. dan derivatif nya seperti, Project performance Indicator, KPI , Progress measurement , EVM technique dll, dimana semua itu adalah merupakan tools yang digunakan dalam melakukan proses Monitoring dan Controlling dalam sebuah project life cycle.
Biasanya disebutkan dalam Project Execution Plan (PEP) dan PEP adalah summary dari semua rencana pekerjaan dan performance yang ingin didapatkan.


Berikut sedikit referensi yang saya dapatkan tentang project performance.


http://www.arcom.ac.uk/publications/procs/ar2002-545-555_Takim_and_Akintoye.pdf

disitu dituliskan , indikator apa saja yang dibutuhkan , seperti contoh nya yaitu : Progress deviation, Cost deviation, Decision dan effectiveness.

Untuk penulisan dalam bahasa kontrak, seperti uraian saya diatas sangat tergantung dari "kebiasaan" atau standard / templates perusahaan anda.
Saya menulis secara general saja: "Terms and Condition Performance" dalam sebuah Contract, IMO, secara ringkas dapt dibagi menjadi :
A. Schedule Performance : dibuatlah Timeline yang biasanya dibuat dalam bentuk Contract Schedule, dan milestones. Disini harus definitive (pasti) tanggalnya:
- Kapan kontrak dimulai (mm/dd/yy).
- Kapan kontrak berakhir (mm/dd/yy).
- Kapan Commisioning dimulai (mm/dd/yy)
- Kapan Final acceptance dimulai.(mm/dd/yy)
Non conformance dari kriteria kontrak milestones yang dipilih (Final acceptance misalnya) Akan berakibat adanya Delay Liquidated Damages, yang arti dalam terjemahan bebasnya : "Kerugian yang harus dibayar oleh kontraktor kepada Owner terhadap keterlambatan / tangal yang telah disepakati"
yang biasanya dalam kontrak besar 1/mil perhari. Biasanya diterapkan maksimum 5%, walaupun PTK007 BPMIGAS mensyaratkan boleh sampai dengan 10% CMIIW
perubahan terhadap tanggal-tanggal tersebut memerlukan Change Order yang perlu diotorisasi sebagai kontrak ammendment. (lagi-lagi ini tentang Change Management)

B. Cost Performance- karena untuk proyek LumpSum , maka yang perlu diperhatikan adalah fokus pada prosedur Progress Measurement Systemnya, establishment baseline , S-Curve, progress payment plan dst ...termasuk juga mekanisme invoicing contractor.

C. Quality - referensi nya ada pada Exhibit Scope Of Work. Dimana akan banyak merefer kepada spesifikasi, datasheet etc...

2. Untuk Project Performance (program), biasanya disebutkan dalam bagian Exhibit (Lampiran) Contract Requirments -
Sebagai contoh: Regular Periodic Progress Reporting yang dijelaskan secara general dalam contract, seperti: Project Reporting requirements
(Monthly, Weekly dan Daily (as approriate) dll.

Dan kemudian akan diatur tersendiri dalam prosedur-prosedur Project Control (PC) yang
memang dibuat spesifik untuk project tersebut
(ie: Project Reporting Requirements., Project WBS systems & standard (agar allign dengan WBS owner), Project Management of Changes dst ..)
Kemudian prosedur-prosedur ini akan dijadikan referensi bidder (/kontraktor) dalam mereka membuat prosedur untuk kita.
Karena yang bisa membuat prosedure PC dalam kontrak tersebut adalah orang-orang Project Control, makanya orang Contract akan menyerahkan prosedure dan content nya kepada PC group. begitupun dengan prosedure prosedur / spesifkasi project spesifik yang lain. Akan konyol kalau Contract Manager akan mengerjakannya sendiri (apa artinya Project team work?). Namun karena Contract Admin / Manager yang mengkoordinasi dan mengkonsolidasikan semua bagian kontrak, semua team dalam PMT (termasuk PC group) akan memberikan masukan kepada Contract admin.
Dan yang diminta kepada Contractor sebagai Company Required Documentation Bentuk nya kebanyakan adalah dalam bentuk deliverables ..

3. Betul , jadi tergantung dari requirement spesifik Project nya apa saja yang diinginkan (yang ditulis dalam lampiran Tablel Required Documentation) .. kapan harus disampaikan, dan disebutkan dalam semacam list /table deliverable yang harus disubmit oleh kontraktor.

IMO, Yang perlu sekali di pastikan bahwa Project baseline (Schedule dan Cost) harus sesegera mungkin di sepakati (maksimal 2 minggu setelah kontrak efektif)