Etiskah Fixed-Price Project ?

IT Comments (3)

Sebagai software developer atau penyedia jasa software development, tentu kita sudah terbiasa pada permintaan customer untuk penentuan harga, jadwal dan scope pada awal project. Memang nggak ada yang salah dengan menentukan harga di awal, cuma masalahnya…kita juga harus memastikan jadwal dan scope project. Dan ini adalah keputusan beresiko tinggi bagi kita.

Hal ini disebut fixed-price project, fixed-price project berbeda dengan fixed-budget project. Fixed-price project adalah penentuan harga atau biaya, jadwal dan scope diawal lifecycle. Sedangkan fixed-budget project adalah penentuan bujet biaya, tapi scope dan jadwal bisa saja bervariasi.

Kita tahu bahwa fixed-price project bukanlah ide yang bagus, dan customer kita pun tahu bahwa itu ide buruk juga. Tapi sangat sulit bagi kita untuk mengabaikan pendekatan ini dalam industri software development, karena sudah menjadi pendekatan yang jamak dan umum.

Pendekatan fixed-price project dikatakan berisiko tinggi karena mengurangi fleksibilitas pada kedua belah pihak baik customer maupun software provider, selain alasan2 lain yang akan disampaikan dibawah ini.

Tapi kenapa ya customer selalu menginginkan fixed-priced sebelum project dimulai ? ada beberapa alasannya, antara lain :

• Mengurangi resiko keuangan. Customer yakin bahwa dengan meminta vendor untuk set price dari awal, mereka mengurangi potensi kerugian keuangan dan mengalihkan resiko keuangan tersebut pada vendor penyedia jasa.
• Untuk mendapatkan project dengan ROI tertinggi. Customer memiliki banyak pilihan untuk menginvestasikan dana mereka, dan project TI adalah salah satunya. Dengan meminta kita untuk fixed-price diawal proyek, maka mereka dapat membandingkan biaya dan kelebihannya “apple to apple” serta mendapatkan opsi terbaik dari yang ada.
• Untuk memaksa kita menyiapkan rencana yang matang. Dengan memaksa kita untuk memberikan estimasi yang akurat, maka kita akan termotivasi secara efektif untuk berpikir bagaimana kita dapat melakukan pekerjaan ini dengan sempurna.
• Sebagai perbandingan diantara beberapa software provider. Customer ingin mendapatkan deal terbaik sehingga mereka mengeluarkan RFP (request for proposal) kepada beberapa software provider untuk mengirimkan bid-nya. Hal ini memberikan customer kesempatan untuk memilih dan memotivasi para software provider untuk mengurangi marjin mereka dalam kompetisi harga.
• Untuk mendukung bujet tahunan. Teknologi informasi adalah komponen kritikal pada bujet setiap perusahaan, biasanya 2.15% dari keseluruhan bujet, jadi customer ingin tahu berapa banyak uang yang harus dialokasikan untuk proyek TI pada masa yang akan datang.

Alasan-alasan diatas terlihat masuk akal, tapi sayangnya nggak realistis pada prakteknya. Kenyataan yang terjadi di lapangan pada saat implementasi tidak mendukung teori dibalik pendekatan fixed-price.

Strategi estimasi biaya seperti COCOMO I/II, Function Points, Feature Points, dan SLIM, berdasarkan pada strategi fundamental yang sama, yaitu:

Pertama, kita identifikasikan terlebih dahulu scope sistem dan arsitektur solusi yang tepat untuk scope tersebut. Semakin detail spesifikasi yang kita buat, semakin besar kemampuan kita untuk mengestimasikan secara akurat effort yang dibutuhkan.

Kedua, kita kumpulkan sedikit demi sedikit item yang dapat mempengaruhi besar kecilnya scope berdasarkan spesifikasi tadi.

Ketiga, ambil patokan dari data project yang sudah pernah kita kerjakan, idealnya yang mirip dengan project yang akan dikerjakan.

Keempat, letakkan seluruh data yang didapat ke dalam “magic formula” dimana dapat memberikan estimasi project. Ukuran dan formula dapat bervariasi diantara teknik estimasi, tapi proses di level atas tetap sama.

Sebagai hasilnya, strategi estimasi biaya formal ini ternyata masih bermasalah dengan beberapa hal sebagai berikut:

• Secara praktek, ternyata banyak penyedia jasa software development tidak memiliki kemampuan estimasi yang bagus. The Standish Group’s “Chaos Report” (www.standishgroup.com) menemukan bahwa hanya 31% dari proyek TI yang reasonable dalam hal waktu dan bujet dan pada rata-rata biaya proyek adalah 189% dari estimasi awal. Hasil ini semakin memperkuat keyakinan bahwa fixed-price project malah memperbesar pengeluaran keuangan dan menjadi sangat beralasan untuk membandingkan nilai proyek akhir dengan estimasi awal. Menjadi sangat sulit untuk mengidentifikasikan potensial ROI pada proyek TI, untuk membandingkan respon pada RFP, atau untuk perform bujet tahunan yang akurat.
• Secara teori, penyedia jasa software development juga tidak dapat memberi estimasi yang bagus. Di tahun 1987, Chris Kemerer melaporkan pada “An Empirical Validation of Software Cost Estimation Models” (Communications of the ACM, May 1987) bahwa teknik formal estimasi memiliki tingkat kesalahan antara 85.772% ketika diaplikasikan. Kabar buruknya adalah studi ini dilakukan pada tahun 1980, dimana kita masih menggunakan teknologi yang jadul (Cobol, C). Laporan ini hanya sebagai salah satu contoh diantara banyak yang menunjukkan bahwa strategi formal estimasi tidak dapat bekerja sebaik secara praktek dimana para protagonis klaim.
• Tidak ada relasi yang teruji bagus antara teori dan praktek. Magne Jxrgensen dan Martin Shepperd melaporkan pada “A Systematic Review of Software Development Cost Estimation Studies” (IEEE Transactions on Software Engineering, January 2007) bahwa masih ada kebutuhan untuk riset secara signifikan pada pengaplikasian teknik estimasi software, khususnya dalam dunia nyata. Walaupun mereka mencantumkan ratusan referensi pada laporan estimasi, mereka tidak dapat menemukan studi tunggal yang mengevaluasinya. Banyak yang menggunakan actual historical data, tapi tidak ada studi yang dieksplore bagaimana strategi estimasi itu diaplikasikan secara praktek. Singkatnya, terlihat masih banyak blind faith pada teknik estimasi up-front.
• Setiap orang diciptakan berbeda. Awal 1968, Sackman, Erikson, dan Grant melaporkan rasio produksi 20 banding 1 antara programer terbaik dan terburuk (”Exploratory Experimental Studies Comparing Online and Offline Programming Performance,” Communications of the ACM, January 1968). Semenjak itu kekurangan pada metodologi mereka ditunjukkan, dan rasio 10 banding satu menjadi lebih realistis. Akhir-akhir ini, Barry Boehm melaporkan rasio 10-banding-1 pada Software Cost Estimation with Cocomo II (Addison-Wesley 2000). Intinya adalah kecuali anda tahu secara pasti siapa yang akan mengerjakan, atau paling tidak memiliki jaminan kriteria orang yang mengerjakan project, kemudian historic data anda yang akan membuktikan segala pertanyaan.
• Customer tahu bahwa kita tidak dapat mengestimasi diawal secara efektif. Dr. Dobb’s 2007 Project Success Survey (see Defining Success) menemukan bahwa 87% business stakeholders secara jelas lebih tertarik mendapatkan ROI yang bagus daripada investasi dibawah budget.
• Ketidakakuratan data historis. Teknik estimasi formal bergantung pada data histori, dan kalopun data itu ada sangat jarang akurat. Lebih dari satu dekade data histori adalah nilai yang kecil ketika teknologi yang kita gunakan berubah2 setiap tahun, ketika komposisi tim kita berubah, dan ketika kemampuan staf kita berubah. Sebagaian dari pondasi dimana estimasi kita bergantung secara konstan meningkat, mengurangi kemmapuan kita untuk tepat.
• Estimasi di muka mengakibatkan Big Requirements Up Front (BRUF), dimana menimbulkan pemborosan yang signifikan. Untuk mengurangi resiko ketidakpastian pada estimasi kita, kita harus meningkatkan level informasi yang masuk pada estimasi-estimasi ini. Hal ini memotivasi kita untuk melakukan detail modelling dari kebutuhan dan bahkan arsitektur kita. The “Chaos Report” menunjukkan bahwa proyek yang menggunakan pendekatan BRUF hingga delivering system, dimana 45% dari fungsionalitas belum dimanfaatkan oleh stakeholders. Jadi, dengan memaksakan strategi fixed-price, seringkali untuk meminimalkan resiko keuangan, dapat dipastikan bahwa rata-rata separo bujet pengembangan akan terbuang. Ya, estimate di awal akan memotivasi IT provider untuk membuat rencana yang detail, tapi sayangnya tidak sebagus ketika dipraktekkan.
• Ketatnya manajemen perubahan yang mengakibatkan customer tidak mendapatkan apa yang mereka inginkan sesungguhnya. Opsi yang paling nyata untuk memproteksi kita sendiri dari resiko fixed-price proyek TI adalah mengadopsi strategi manajemen perubahan tradisional yang ketat dimana membuat customer sulit untuk memodifikasi requirement mereka. Proses ini biasanya berat, membuat potensi jadwal yang tidak meleset secara eksplisit dan biasanya membuat customer membayar secara fair untuk setiap perubahan. Faktor-faktor ini mengurangi minat customer untuk merubah requirement yang sudah ditentukan mereka, walaupun memang requirement mereka berubah, dan merubah strategi manajemen perubahan kepada strategi pencegahan perubahan. Bukan hanya strategi pencegahan perubahan yang memperburuk tantangan yang berkaitan dengan BRUF, mereka juga dipertanyakan dari segi etika karena kita secara memotivasi customer untuk membayar fungsionalitas yang mungkin saja sebetulnya tidak mereka inginkan. Strategi manajemen perubahan yang cerdas memperlakukan requirements seperti rak prioritas yang dimanaje oleh stakeholders, dan tim development tinggal menarik pekerjaan dari rak paling atas secara berturut-turut ke bawah, sehingga menghasilkan ROI terbaik yang diinginkan stakeholders. Ini membuat stakeholders memanage scope, sehingga mendapatkan software yang betul2 sesuai dengan kebutuhan dan mereka harus bertanggungjawab atas segala perubahan scope.
• Pemborosan waktu dan tenaga pada estimate awal yang terlalu dipaksakan untuk tepat. Customer seringkali tidak sadar akan nilai effort yang dibutuhkan untuk mendapatkan sedikit kesamaan pada estimasi kita.

Jadi, Apakah Fixed-Price itu Etis ?

Untuk menjadikan fixed-priced proyek TI dapat dikatakan etis, maka ada 3 kriteria yang harus dipenuhi.

Pertama, ada unsur pemaksaan secara eksplisit dari pihak customer untuk penerapan fixed-priced.

Kedua, customer sudah diberitahu segala resiko terkait dengan fixed-priced.

Ketiga, customer sudah diberikan beberapa pilihan seperti pembayaran per tahap pengembangan sebagaimana umumnya dilakukan pada proyek TI besar atau pembayaran secara kontinyu mengalir seperti pada pelaksanaan proyek yang ‘agile’ (cepat), dan mendapatkan informasi untung rugi metode tersebut, namun customer tetap memilih secara eksplisit untuk menggunakan pendekatan fixed-priced project TI.

Banyak profesional TI yang menyerah ketika menghadapi permintaan customer untuk fixed-priced proyek TI, padahal itu meningkatkan resiko proyek. Kita harus berhenti menerima status quo dan mendorong balik kepada customer serta membantu mereka berpikir ulang akan strategi ini.

Kesimpulannya, pada dasarnya kita tahu bahwa fixed-priced proyek TI adalah metode yang buruk, dan customer kita pun sadar akan hal itu juga. Ketika customer memaksakan untuk menggunakan pendekatan fixed-priced pada proyek TI, maka secara etika kita harus mencoba mengajak mereka menjauhi metode yang berbahaya ini.

Kalau kita tidak mulai memberikan argumentasi perlawanan yang konsisten akan metode fixed-priced project, maka kita tidak akan pernah keluar dari masalah ini. Kita harus mulai secara aktif mengurangi resiko yang ada pada industri bisnis kita, dan keinginan customer akan fixed-priced proyek TI adalah problem dan resiko terbesar yang kita hadapi.

sumber: http://www.ddj.com

Ade Aan @ August 10, 2008 595 views