Cone of Uncertainty: Mengapa Estimasi Awal Selalu Meleset

Oleh Tara Minh · Diperbarui 10 Oktober 2026

Cone of uncertainty adalah model yang menunjukkan bahwa estimasi proyek paling tidak andal di awal dan baru menjadi lebih andal setelah hal-hal yang belum diketahui terjawab. Versi Steve McConnell menempatkan estimasi perangkat lunak di tahap awal pada kisaran 0,25x hingga 4x dari hasil akhir, lalu menyempit menuju 1,0x seiring keputusan demi keputusan diambil.

Fakta Utama

• 4x ke kedua arah: Estimasi yang dibuat pada tahap Initial Concept bisa meleset 4x ke sisi atas maupun 4x ke sisi bawah (0,25x), yaitu selisih 16x dari yang terendah hingga tertinggi, menurut white paper Cone of Uncertainty dari Construx.
• Skenario terbaik, bukan janji: Cone ini menunjukkan akurasi terbaik yang dapat dicapai estimator terampil. Hasil yang lebih buruk mudah terjadi, sedangkan hasil yang lebih akurat hanya mungkin berkat keberuntungan (white paper Construx yang sama).
• Asal-usul subjektif: Barry Boehm menggambar versi pertamanya dalam buku Software Engineering Economics (1981), dan rentangnya ditetapkan berdasarkan penilaian sebagai batas keyakinan 80%, bukan diukur dari data proyek (Bossavit, The Leprechauns of Software Engineering).
• Mempersempit itu kerja nyata: Sebagian besar penyempitan terjadi pada sekitar 20 hingga 30% awal waktu kalender, dan hanya karena tim mengambil keputusan yang mengurangi variabilitas (Construx).

Apa itu cone of uncertainty?

Bayangkan sebuah corong yang direbahkan. Di sisi kiri, pada awal proyek, corong itu lebar. Di sisi kanan, mendekati penyerahan hasil, corong itu mengerucut menjadi satu titik. Sumbu vertikal menunjukkan seberapa jauh estimasi effort, biaya, jadwal, atau ruang lingkup bisa menyimpang dari hasil akhir yang Anda serahkan. Sumbu horizontal adalah waktu, ditandai dengan tonggak pencapaian: konsep awal, definisi produk yang disetujui, kebutuhan selesai, desain selesai, dan proyek rampung.

Gagasannya sederhana. Di awal proyek, Anda belum tahu persis apa yang akan dibangun, siapa yang membangunnya, risiko mana yang akan muncul, atau kebutuhan mana yang akan berubah. Setiap ketidakpastian itu menambah variasi pada estimasi. Begitu masing-masing terjawab, rentang hasil yang masuk akal pun mengecil.

Itulah bagian yang sering dikutip orang. Bagian yang dilewatkan adalah apa yang dikatakan McConnell tepat di sebelahnya: ketidakpastian tidak menyusut hanya karena waktu berlalu. Ia menyusut karena ada yang mengambil keputusan. White paper Construx menyatakannya dengan lugas, bahwa satu-satunya cara mengurangi variabilitas estimasi adalah mengurangi variabilitas proyek itu sendiri. Meminta tim "satu minggu lagi untuk menyempurnakan estimasi" tidak ada gunanya jika tidak ada hal dalam proyek yang menjadi lebih jelas selama minggu itu.

Dari mana cone ini berasal

Barry Boehm membuat sketsa versi paling awal dalam Software Engineering Economics (1981), dan menyebutnya funnel curve. Pada tahap paling awal, estimasi bisa meleset dengan faktor 4 ke kedua arah: white paper Construx dari McConnell menetapkan rentang Initial Concept pada 4x ke atas hingga 0,25x ke bawah, selisih 16x.

Steve McConnell kemudian memberinya nama "cone of uncertainty" dan memasukkannya ke dalam buku-buku estimasinya, termasuk Software Estimation: Demystifying the Black Art (Microsoft Press, 2006). Construx, perusahaan yang ia dirikan, masih menerbitkan model ini sebagai white paper.

Ada catatan jujur yang perlu disampaikan. Analisis Laurent Bossavit atas sejarah cone ini menemukan bahwa rentang Boehm berasal dari penilaian, bukan dari kumpulan data terukur. Bossavit juga merujuk data Todd Little tahun 2006 dari laporan status proyek nyata, yang dipublikasikan di IEEE Software, dan datanya tidak cocok dengan corong simetris itu. Proyek nyata jauh lebih sering terlambat daripada selesai lebih awal, dan banyak yang bertahan di "90% selesai" dalam waktu lama.

Jawaban McConnell, dalam makalah Construx, adalah bahwa cone ini merupakan skenario terbaik dan bahwa proyek yang dikelola dengan buruk menghasilkan "awan" ketidakpastian yang tidak pernah menyempit. Jadi perlakukan cone ini sebagai model pengajaran yang berguna dan disiplin perencanaan, bukan hukum statistik. Pelajaran praktisnya tetap berlaku: angka awal layak diberi rentang yang lebar.

Cone of uncertainty vs konsep estimasi lainnya

Cone ini bukan teknik estimasi. Ia adalah lensa untuk menilai seberapa besar Anda boleh memercayai hasil teknik apa pun pada satu titik waktu. Itulah sebabnya cone ini berpasangan dengan metode di bawah ini, bukan menggantikannya.

Aturan praktis yang berguna: pilih metode yang presisinya sepadan dengan lebar cone. Estimasi bottom-up hingga hitungan jam di tahap initial concept adalah presisi semu. Estimasi analogis kasar justru boros setelah desain selesai dan ruang lingkup dikunci.

Mengapa estimasi awal meleset

Menyalahkan estimator memang menggoda. Biasanya estimator bukan sumber masalahnya. Ada empat hal yang melebarkan cone di awal proyek.

Kebutuhan masih samar. "Bangun portal pelanggan" bisa berarti halaman login dan daftar faktur, atau platform swalayan lengkap dengan pembayaran. Keduanya pembacaan yang wajar. Selisih effort di antara keduanya sangat besar.

Ruang lingkup terus bergerak. Pemangku kepentingan menambah dan mencabut fitur setelah melihat sesuatu yang nyata. Ini adalah perluasan ruang lingkup dalam bentuk awalnya, bahkan sebelum ada baseline yang bisa diperluas.

Ketergantungan belum diketahui. Anda belum tahu bahwa tim pembayaran memiliki antrean enam minggu, atau bahwa sistem lama harus ditulis ulang sebelum bisa diintegrasikan.

Tim belum stabil. Keterampilan, ketersediaan, dan velocity hanyalah tebakan sampai orang-orangnya benar-benar bekerja bersama pada proyek yang sebenarnya.

Lalu ada lapisan manusianya. Optimisme adalah pengaturan bawaan, dan angka yang diucapkan dalam rapat cenderung menjadi janji. Jika sponsor mendengar "sekitar empat bulan" di tahap initial concept, angka itu akan masuk ke rencana, anggaran, dan terkadang kontrak pelanggan. Tidak ada yang ingat bahwa angka itu datang bersama rentang "satu hingga enam belas."

Construx menyebut ini sebagai bahaya sesungguhnya. Organisasi yang berkomitmen saat cone masih lebar, dalam kata-katanya, merusak prediktabilitas dan meningkatkan risiko. Berkomitmen pada tahap initial concept atau definisi produk berarti harus menanggung galat estimasi 2x hingga 4x.

Cara menggunakan cone of uncertainty (langkah demi langkah)

Anda tidak bisa membuat cone ini lenyap, tetapi Anda bisa memanfaatkannya secara sengaja. Berikut urutan kerja yang bisa dipakai.

Langkah 1: Sebutkan tahapnya dengan jujur

Tentukan posisi proyek saat ini: ide awal, ruang lingkup disetujui, kebutuhan selesai, desain selesai, atau sedang dibangun. Bersikaplah kritis. Proyek dengan anggaran yang sudah disetujui tetapi dokumen kebutuhan yang baru separuh jadi tetap berada di sisi yang lebar.

Langkah 2: Berikan rentang, bukan satu titik

Ubah estimasi terbaik Anda menjadi nilai terendah dan tertinggi. Pada tahap initial concept, model Construx mengizinkan 0,25x hingga 4x, sehingga tebakan 100 hari menjadi 25 hingga 400 hari. Di slide, angka itu terlihat tidak masuk akal, dan memang itu tujuannya. Jika selisihnya membuat orang cemas, mereka akan menyetujui pekerjaan yang mempersempitnya.

Untuk rentang di tingkat tugas, three-point estimation memberi Anda cara yang dapat dipertanggungjawabkan untuk menghasilkan nilai rendah, paling mungkin, dan tinggi.

Langkah 3: Daftar hal tak diketahui yang menciptakan lebar rentang

Tuliskan setiap pertanyaan terbuka yang menggeser estimasi: kebutuhan yang belum final, integrasi yang belum dikenal, staf yang belum dipastikan, teknologi yang belum terbukti. Urutkan berdasarkan seberapa besar rentang yang ditambahkan masing-masing. Daftar ini juga menjadi awal dari risk register Anda.

Langkah 4: Jadwalkan pekerjaan yang menghilangkan ketidakpastian

Perlakukan discovery sebagai hasil kerja. Tetapkan visi produk, termasuk apa yang berada di luar ruang lingkup. Selesaikan kebutuhan. Buat prototipe untuk antarmuka paling berisiko. Jalankan technical spike pada integrasi yang belum pernah dicoba siapa pun. Masing-masing menghilangkan variabilitas, dan masing-masing perlu pemilik serta tanggal.

Langkah 5: Tunda komitmen yang mengikat

Panduan McConnell menyatakan bahwa komitmen yang berarti tidak mungkin dibuat di bagian awal cone yang lebar, dan organisasi yang efektif menunggu sampai mereka berhasil mempersempitnya. Makalahnya menyebut komitmen yang dibuat sekitar 30% dari perjalanan proyek sebagai sesuatu yang mungkin dan layak. Jika bisnis membutuhkan angka lebih cepat, berikan rentangnya dan beri label bahwa itu rentang.

Langkah 6: Estimasi ulang di setiap tonggak pencapaian

Jalankan ulang estimasi setiap kali satu hal penting yang belum diketahui terjawab, bukan berdasarkan kalender. Bandingkan setiap rentang baru dengan yang sebelumnya. Jika tidak menyempit, berarti yang Anda hadapi adalah awan, dan proyek memerlukan pembicaraan tentang ruang lingkup, staf, atau pendekatan.

Langkah 7: Tetapkan baseline setelah rentang sempit

Ketika rentang sudah cukup sempit untuk didanai sponsor dan dijanjikan tim, catat sebagai baseline proyek. Lacak varians terhadap angka itu mulai saat itu.

Template siap salin: pelacak rentang estimasi

Salin tabel ini ke rencana proyek Anda dan perbarui di setiap tonggak pencapaian. Kolom "Lebar" hanyalah nilai tertinggi dibagi nilai terendah, yang menunjukkan sekilas apakah cone sedang menyempit.

Cara mengisinya:

1. Rendah dan tinggi berasal dari three-point estimate yang dijumlahkan di seluruh pekerjaan, atau dari pengali cone yang diterapkan pada satu tebakan terbaik.
2. Hal tak diketahui yang terjawab adalah daftar sederhana keputusan yang diambil sejak baris sebelumnya. Jika sel ini kosong dan lebarnya tidak berubah, itu memang wajar.
3. Komitmen diizinkan? adalah kolom kebijakan. Sepakati bersama sponsor sejak awal agar tidak ada yang berdebat di awal proyek.

Jika kolom lebar berhenti turun selama dua tonggak pencapaian berturut-turut, eskalasikan. Ada sesuatu dalam proyek yang tidak mengerucut.

Contoh berdasarkan fungsi bisnis

Cone ini tidak terbatas pada perangkat lunak. Pekerjaan apa pun dengan ruang lingkup yang belum jelas dan langkah yang asing berperilaku seperti ini. Angka di bawah ini adalah hitungan ilustratif yang menerapkan pengali tahap awal cone (0,25x hingga 4x) pada tebakan pertama yang kasar, bukan tolok ukur.

Ambil contoh peluncuran marketing. "Delapan minggu" terdengar masuk akal sampai Anda bertanya apa saja yang tercakup. Jika brief belum disetujui, siapa yang menyetujui copy, dan apakah tim legal perlu meninjau klaim, maka "delapan minggu" hanyalah harapan. Setelah brief, sitemap, dan rantai persetujuan ditetapkan, proyek yang sama mungkin bisa dikutip dengan jujur sebagai enam hingga sepuluh minggu.

Logika yang sama berlaku pada peluncuran operasional. Sebelum pemetaan proses, angka $200,000 tidak punya dasar yang lebih kuat daripada $600,000. Setelah pemetaan dan daftar pendek vendor, rentangnya mungkin mengetat menjadi sesuatu yang bisa ditandatangani seorang direktur keuangan.

Cone dan tim Agile

Keberatan yang umum: "Kami Agile, jadi cone ini tidak berlaku." Cone ini tetap berlaku, hanya dengan cara berbeda.

Makalah Construx sendiri menyatakan bahwa pada proyek iteratif, Anda melewati sebuah cone mini di setiap iterasi. Sebelum pekerjaan kebutuhan untuk satu iterasi, Anda berada di bagian definisi produk yang disetujui pada cone. Dengan iterasi pendek, tim dapat melewati tahap kebutuhan dan desain UI dalam hitungan hari, menurunkan variabilitas dari 4x menjadi 1,6x untuk potongan pekerjaan itu. Jika jadwal ditetapkan tetap, variabilitas tersebut muncul sebagai ketidakpastian tentang fitur mana yang muat, bukan tentang tanggal akhir.

Yang dikorbankan, menurut makalah itu, adalah prediktabilitas jangka panjang atas gabungan biaya, jadwal, dan fitur beberapa iterasi ke depan. Banyak tim memilih jalan tengah: menetapkan sebagian besar kebutuhan di awal, lalu membangun dalam iterasi pendek. Makalah itu menyebut pendekatan ini menurunkan variabilitas dari cone hingga sekitar plus minus 25%.

Dalam praktiknya, artinya tim Agile tetap membutuhkan rentang untuk roadmap dan tanggal rilis, dan metode ukuran relatif seperti story points bekerja paling baik untuk pekerjaan jangka dekat. Item yang masih jauh layak diberi ukuran kasar dan pernyataan jujur "kita akan tahu lebih banyak nanti."

Dos and don'ts cone of uncertainty

Dos

• Sebutkan rentang sejak awal. Katakan "empat hingga enam belas bulan" di tahap konsep, bukan "delapan bulan." Rentang melindungi Anda dan mengedukasi sponsor.
• Kaitkan penyempitan dengan keputusan yang disebutkan namanya. Setiap baris pelacak Anda harus menunjukkan apa yang terjawab sejak estimasi terakhir.
• Estimasi ulang di tonggak pencapaian. Estimasi baru setelah kebutuhan selesai lebih berharga daripada pembaruan bulanan yang tidak membawa hal baru.
• Gunakan rentang untuk memprioritaskan discovery. Hal tak diketahui yang paling menambah lebar dikerjakan lebih dulu.
• Pisahkan estimasi dari komitmen. Estimasi adalah apa yang Anda harapkan. Komitmen adalah janji. Keduanya tidak boleh dicampur dalam satu kalimat.
• Padukan cone dengan metode kuantitatif seperti Monte Carlo simulation setelah Anda memiliki cukup detail untuk dimodelkan.

Don'ts

• Jangan menganggap cone menyempit otomatis. Berlalunya waktu tidak mempersempitnya. Keputusanlah yang melakukannya, dan makalah Construx menyatakan cone dapat berubah menjadi awan ketika proyek tidak dikendalikan dengan baik.
• Jangan menjanjikan akurasi yang tidak sanggup diberikan model ini. Estimator terampil sekalipun tidak bisa mengalahkan cone. Mereka hanya bisa meleset lebih jauh.
• Jangan menyempitkan rentang demi menyenangkan sponsor. Angka yang lebih ketat tanpa informasi baru di baliknya hanyalah risiko yang lebih besar.
• Jangan abaikan kemiringan. Proyek nyata lebih sering terlambat daripada selesai lebih awal, jadi jangan berasumsi ujung rendah dan tinggi sama-sama mungkin. Condongkan rentang Anda ke sisi pesimistis.
• Jangan biarkan estimasi satu titik lolos dari ruangan. Begitu "sekitar empat bulan" ada di email tanpa rentangnya, itu sudah menjadi janji.
• Jangan gunakan metode presisi di tahap yang masih samar. Estimasi bottom-up per jam pada konsep satu halaman hanyalah sandiwara.

Kesalahan umum dengan cone

Sebagian tim mendengar "estimasi awal tidak andal" lalu menyimpulkan bahwa perencanaan itu percuma. Tidak demikian. Cone ini mengatakan agar Anda merencanakan sebanding dengan apa yang Anda ketahui, dan menghabiskan upaya awal untuk menjawab hal tak diketahui terbesar alih-alih memoles sebuah angka.

Yang lain menafsirkan bentuk simetrisnya terlalu harfiah. Kritik Bossavit adalah pengingat yang baik bahwa diagram yang rapi bukan bukti distribusi yang rapi. Gunakan pengali tersebut sebagai titik awal diskusi, lalu sesuaikan dengan riwayat Anda sendiri. Jika proyek-proyek lalu di organisasi Anda rata-rata melampaui estimasi 40%, masukkan itu ke dalam hitungan.

Kesalahan ketiga adalah memakai cone untuk membenarkan tidak adanya baseline. Setelah ruang lingkup dan desain stabil, cone sudah menunaikan tugasnya. Pada titik itu, varians dari baseline adalah persoalan manajemen, bukan persoalan ketidakpastian. Trade-off antara ruang lingkup, jadwal, dan biaya menjadi pembicaraan yang tepat.

Poin-poin utama

Cone of uncertainty memberi Anda jawaban yang dapat dipertanggungjawabkan atas pertanyaan yang selalu diajukan sponsor: "Berapa lama ini akan selesai?" Jawaban awal yang jujur adalah sebuah rentang, dan lebar rentang itu sendiri adalah informasi. Persempit dengan mengambil keputusan, bukan dengan menunggu. Tahan komitmen yang mengikat sampai cone menyempit. Dan tinjau kembali angka Anda setiap kali satu hal nyata yang belum diketahui terjawab.