Fixed Price vs Time and Materials: Memilih Kontrak yang Tepat untuk Proyek Software

Fixed Price vs Time and Materials: Memilih Kontrak yang Tepat untuk Proyek Software

Klien sering tanya pricing model mana yang lebih murah. Itu pertanyaan keliru. Fixed price dan time and materials (T&M) bukan soal murah atau mahal. Keduanya soal risiko. Sebagian besar harga yang dibayar sebenarnya adalah biaya untuk memindahkan risiko ke pihak lain.

Bayangkan seperti asuransi mobil: premi lebih mahal karena perusahaan asuransi yang menanggung kalau mobil ringsek. Kalau Anda pilih bayar sendiri per kerusakan, tarifnya lebih murah, tapi risikonya jadi tanggungan Anda. Begitu dilihat dari sudut ini, memilih pricing model software tidak lagi jadi tebak-tebakan.

Pertanyaan sebenarnya: siapa menanggung risiko

Dalam kontrak fixed-price, klien sepakat soal harga sebelum kerja dimulai. Penjual yang menanggung risikonya kalau meleset. Kalau pengerjaan molor, margin vendor yang menyusut, bukan tagihan klien. Ini cuma berjalan mulus kalau scope sudah rinci dan kecil kemungkinan berubah.

T&M membalik posisi itu. Buyer membayar untuk jam kerja dan material yang benar-benar terpakai, jadi risiko biaya ada di pihak buyer. Dalam kerangka procurement ala PMBOK, T&M diperlakukan sebagai hybrid antara fixed-price dan cost-reimbursable, dengan risiko yang di atas kertas dibagi bersama. Praktiknya lebih condong ke buyer, kecuali kontrak memasang batas atas.

Milestone hybrid ada di tengah-tengah keduanya: mematok harga per deliverable sambil tetap fleksibel antar-fase. Tidak ada yang "paling bagus" di antara ketiganya. Masing-masing cuma jawaban berbeda untuk satu pertanyaan: siapa yang menanggung ketidakpastian.

Kenapa quote fixed-price tidak pernah sekadar cost plus margin

Penawaran fixed-price bukan estimasi jujur vendor ditambah margin begitu saja. Itu estimasi plus risk premium, karena begitu kontrak diteken, setiap hal tak terduga jadi tanggungan vendor. API pihak ketiga yang ternyata dokumentasinya setengah jadi. Integrasi "sederhana" yang ternyata tidak sederhana. Fixed-price memindahkan risiko ke penjual, dan penjual sudah menagih harga risiko itu di muka, sebelum risikonya benar-benar terjadi.

Praktisi industri umumnya menyebut markup 15-30% untuk premium ini, di atas estimasi T&M yang jujur untuk scope yang sama. Perlu saya tandai: angka itu patokan kasar yang beredar dari vendor ke vendor, bukan statistik terukur dari studi yang dipublikasikan. Arahnya tetap benar walau persentase pastinya tidak ilmiah. Makin tidak pasti scope-nya, makin tebal buffer yang dipasang vendor mana pun yang waras.

Kenapa buffernya lebih besar dari perkiraan kebanyakan klien

Estimasi software di tahap awal memang wajar meleset jauh. Rentang yang sering dikutip, ditelusuri ke riset Barry Boehm soal estimasi, menaruh estimasi tahap konsep awal di kisaran 0.25x sampai 4x dari biaya sebenarnya nanti. Itu bukan tanda vendor asal-asalan. Sebelum desainnya ada, memang cuma segitu yang bisa diketahui siapa pun.

Quote fixed-price yang dibuat di tahap ini, seperti kata satu tulisan industri, ibarat polis asuransi yang mahal untuk segala hal yang belum bisa dilihat siapa pun. Dihitung untuk skenario terburuk yang masuk akal, bukan skenario rata-rata.

Ini bukan sekadar teori. McKinsey dan University of Oxford meneliti lebih dari 5.400 proyek IT. Proyek besar (di atas $15 juta) rata-rata meleset 45% dari budget dan 7% dari jadwal. Nilai yang dihasilkan 56% lebih rendah dari yang dijanjikan, dan 17% berujung jadi "black swan" — overrun parah yang mengancam kelangsungan perusahaan. Vendor yang menawarkan fixed-price untuk scope ambigu sudah pernah merasakan angka semacam ini di proyeknya sendiri, meski tidak pernah membaca studinya. Premium yang mereka pasang lahir dari pengalaman itu.

Kapan T&M justru lebih murah dalam praktik

Ini bagian yang jarang diungkap vendor: kalau risiko yang tadinya dihitung dalam premium fixed-price ternyata tidak pernah terjadi, klien sudah bayar asuransi yang tidak terpakai. Seperti kata satu analisis, "klien tetap membayar premium ini terlepas dari apakah risikonya benar-benar terjadi... kalau proyek berjalan lancar, klien sekadar kelebihan bayar." Di T&M tidak ada buffer yang menganggur seperti itu. Fitur yang ternyata lebih sederhana dari perkiraan langsung terlihat sebagai tagihan lebih kecil, bukan margin vendor yang lebih gemuk.

T&M juga memungkinkan tim mengubah prioritas di tengah proyek, bukan terus menggarap spec yang sudah terkunci. Tim fixed-price bisa saja terus membangun fitur yang sudah tidak ada yang butuh, karena kontraknya bilang begitu. Di T&M, jam kerja itu bisa dialihkan ke sesuatu yang lebih berguna.

Untuk engagement yang roadmap-nya memang cenderung berubah — kebanyakan produk tahap awal, kebanyakan sistem SME yang ditumpuk di atas operasi yang sudah berjalan — fleksibilitas itu menghemat uang sungguhan. Ini salah satu alasan proyek software yang dikerjakan tim eksternal cenderung berjalan lebih mulus dengan T&M, begitu hubungan kerja sudah melewati rilis pertama.

Milestone hybrid: harga tetap, fase fleksibel

Milestone-based pricing mematok harga untuk tiap potongan pekerjaan yang jelas, sambil tetap memberi ruang menyesuaikan antar-potongan. Sepakati scope dan harga untuk "user authentication dan admin dashboard." Bayar begitu selesai dan diterima sesuai checklist. Lalu tentukan scope milestone berikutnya berbekal pelajaran dari milestone sebelumnya.

Klien membayar saat provider menyelesaikan cakupan kerja tertentu yang sudah disepakati di awal — dan "di awal" di sini berarti sebelum fase itu dimulai, bukan sebelum seluruh proyek dimulai.

Model ini memaksa kedua pihak tetap jujur — sesuatu yang tidak bisa diberikan fixed-price atau T&M murni. Milestone fixed-price memberi vendor alasan untuk benar-benar menyelesaikan dan mendemokan software yang jalan, bukan sekadar menagih jam kerja tanpa hasil jelas. Checkpoint dengan acceptance criteria memberi klien pegangan untuk menerima hasil dengan tegas, bukan malah terseret scope creep di tengah fase.

Gesekannya tetap ada: perselisihan muncul kalau hasil kerja tidak jelas-jelas cocok dengan checklist-nya. Checklist-nya harus cukup spesifik untuk memutus perdebatan, bukan sekadar menuliskan niat baik. Proses acceptance tertulis harus ada di kontrak, di tempat yang sama kontrak menetapkan siapa yang memiliki kode yang dihasilkan.

Capped T&M: tuas kedua

Klausul not-to-exceed adalah solusi lebih sederhana kalau milestone tidak cocok: maintenance berkelanjutan, tim kecil yang menempel di tim klien, pekerjaan yang tidak bisa dipecah rapi jadi deliverable. Jam kerja dan material tetap ditagih, tapi totalnya tidak boleh melewati batas atas yang disepakati tanpa change order.

Buyer mendapat kepastian biaya ala fixed-price tanpa kehilangan fleksibilitas T&M. Vendor tetap punya keleluasaan soal bagaimana budget dipakai. Tanpa perlindungan ini, T&M memang berisiko nyata bagi buyer — jam kerja bisa melebar tanpa titik henti yang jelas. Cap adalah asuransi murah untuk risiko itu, dan vendor yang serius akan menyetujuinya tanpa berdebat panjang.

Red flag dari kursi konsultan

Di engagement fixed-price, waspadai vendor yang memperlakukan setiap pertanyaan klarifikasi dari Anda sebagai change order. Waspadai juga kualitas yang merosot diam-diam begitu budget mulai ketat — tim yang margin-nya tertekan berhenti menulis automated test atau menunda refactoring yang baru terasa mahal belakangan. Scope yang terkunci ditambah gesekan change order lama-lama membuat vendor dan klien berhadap-hadapan seperti lawan — kebalikan dari alasan Anda menyewa konsultan.

Di T&M, red flag-nya justru kebalikannya: tidak ada klausul not-to-exceed, tidak ada milestone, tidak ada laporan rutin soal ke mana jam kerjanya terpakai. Vendor yang menawarkan T&M open-ended tanpa satu pun pengaman itu sebenarnya sedang meminta Anda menanggung 100% risiko biaya tanpa bisa melihat ke mana uangnya mengalir. Itu bukan pricing model. Itu cek kosong. Minta cap-nya, milestone-nya, atau keduanya sebelum tanda tangan.