Proposal yang dapat dibandingkan dimulai dari deskripsi pekerjaan yang jelas: 12 informasi penting

Sourcing Playbook Inggris yang berlaku saat ini menyatakan bahwa spesifikasi yang jelas harus memberi calon peserta informasi yang cukup untuk mengambil keputusan yang tepat apakah akan mengajukan proposal. Dokumen itu juga menyebut bahwa tanpa pemahaman bersama atas persyaratan, sulit menghubungkan harga yang diajukan dengan pemahaman pembeli tentang biaya dan hasil yang diinginkan. [1]

Government Commercial Function menyatakannya lebih langsung: spesifikasi yang baik harus memuat informasi yang cukup agar pemasok dapat menghitung biaya barang atau jasa secara tepat, sehingga pembeli dapat membandingkan proposal pada dasar yang setara. [2]

Pada saat yang sama, Digital, Data and Technology Playbook Inggris memperingatkan agar solusi tidak ditentukan secara berlebihan. Panduan itu menyarankan fokus pada pengguna, masalah, dan hasil yang diinginkan sambil memberi ruang kepada pemasok untuk mengusulkan cara pelaksanaan yang efektif. [3]

Jadi kesimpulannya bukan "jelaskan semuanya sedetail mungkin". Aturan yang lebih baik adalah:

jelaskan dengan tepat hal yang harus sama di semua proposal, bukan hal yang secara wajar dapat dirancang sendiri oleh spesialis yang kompeten.

Dua proposal profesional tidak akan pernah benar-benar identik, dan itu bukan tujuannya.

Dapat dibandingkan berarti para spesialis menanggapi masalah yang sama dengan asumsi yang secara umum serupa.

Mereka sebaiknya memiliki pemahaman yang kurang lebih sama tentang:

• tujuan,
• cakupan,
• titik awal,
• hasil yang diharapkan,
• batasan penting,
• jadwal,
• tanggung jawab klien,
• cara harga harus disajikan,
• kriteria penilaian proposal.

Mereka tetap dapat berbeda dalam:

• pendekatan yang diusulkan,
• urutan pekerjaan,
• metode,
• susunan tim,
• alat,
• pembagian tahap,
• cara mengurangi risiko.

Perbedaan seperti ini sering justru bernilai dan harus tetap terlihat.

Mulailah dari masalah, bukan daftar fitur.

Daripada:

"Saya membutuhkan aplikasi dengan panel ringkasan, notifikasi, dan laporan."

cobalah:

"Saat ini lima orang mengelola proses melalui lembar kerja dan surel. Sulit melihat status terbaru suatu kasus, siapa penanggung jawabnya, dan apa langkah berikutnya. Kami ingin mengurangi pelacakan manual dan memiliki satu tempat yang menampilkan keadaan terkini."

Deskripsi kedua belum menentukan aplikasi seperti apa yang harus dibuat.

Namun, deskripsi itu membantu spesialis memahami mengapa proyek ini ada sejak awal.

Federal Acquisition Regulation untuk layanan berbasis hasil menyarankan agar pekerjaan terutama dijelaskan melalui hasil yang diperlukan, bukan cara pekerjaan dilakukan atau jumlah jam yang diberikan. Unsur minimum pernyataan tujuan mencakup hal seperti tujuan, cakupan, latar belakang, hasil yang diperlukan, dan batasan operasional. [4]

Karena itu, jelaskan apa yang harus menjadi mungkin ketika pekerjaan selesai.

Contoh:

• pengguna dapat menyelesaikan proses tertentu sendiri,
• tim dapat melihat status terkini setiap kasus,
• klien menerima analisis dengan prioritas,
• sistem dipindahkan ke lingkungan baru dan bekerja sesuai kriteria yang disepakati,
• materi yang disiapkan siap diterbitkan pada saluran tertentu.

Hasil harus cukup konkret agar kedua pihak memahami arah pekerjaan.

Namun, hasil tidak harus berupa jaminan hasil bisnis yang bergantung pada pasar, perilaku pengguna, atau faktor lain di luar kendali penyedia.

Kebutuhan akhir yang sama dapat memerlukan usaha yang sangat berbeda tergantung dari mana pekerjaan dimulai.

Sebaiknya jelaskan:

• apa yang sudah ada,
• apa yang berfungsi dan harus dipertahankan,
• apa yang tidak berfungsi,
• apakah berkas sumber tersedia,
• apakah dokumentasi tersedia,
• apakah ada data yang harus dipindahkan,
• apakah pekerjaan harus dilakukan pada sistem yang sudah ada,
• materi apa yang sudah siap.

"Situs web baru" dapat berarti membangun dari nol atau membangun ulang situs yang ada sambil mempertahankan konten, alamat halaman, analitik, integrasi, dan data.

Keduanya adalah pekerjaan berbeda meskipun tampilan akhirnya bisa serupa.

Cakupan tidak seharusnya memaksa spesialis menebak bagian masalah mana yang harus mereka hitung.

Contoh:

Dalam cakupan:

• analisis solusi saat ini,
• desain tampilan baru,
• penerapan,
• pemindahan bagian data yang telah ditentukan.

Di luar cakupan:

• membuat konten baru,
• membeli lisensi,
• pemeliharaan setelah bulan pertama,
• membangun ulang sistem pembayaran.

Contoh Terms of Reference dari Bank Dunia menekankan bahwa kebutuhan dan harapan untuk layanan konsultasi harus dijelaskan dengan jelas dan disesuaikan dengan proyek tertentu. [5]

Batas sangat penting ketika dua pekerjaan saling berkaitan secara alami dan mudah diasumsikan bahwa satu pekerjaan mencakup yang lain.

Jika Anda mengharapkan materi atau keluaran tertentu, sebutkan dengan jelas.

Contohnya:

• solusi yang berfungsi,
• berkas sumber,
• laporan,
• dokumentasi,
• desain visual,
• sekumpulan materi,
• konfigurasi lingkungan,
• pelatihan,
• rekaman,
• penyerahan kode dan akses.

Kata seperti "desain", "analisis", atau "penerapan" dapat ditafsirkan secara berbeda.

Daftar bersama tentang hasil serahan utama membantu mencegah situasi ketika satu proposal mencakup jauh lebih banyak daripada yang lain tetapi perbedaannya tersembunyi di balik nama layanan yang mirip.

Tidak setiap batasan merupakan rincian teknis.

Batasan yang relevan dapat berupa:

• sistem atau lingkungan tertentu,
• integrasi wajib dengan layanan tertentu,
• persyaratan aksesibilitas,
• regulasi industri,
• pembatasan penyimpanan data,
• kewajiban mempertahankan infrastruktur yang ada,
• perangkat atau peramban tertentu,
• bekerja dalam jam tertentu,
• pembatasan akses data.

FAR secara tegas memasukkan batasan operasional dalam pernyataan tujuan, sedangkan Digital, Data and Technology Playbook Inggris menunjukkan bahwa solusi tidak perlu ditentukan sebelumnya ketika sebenarnya tidak ada batasan nyata. [4] [3]

Aturan yang berguna:

jelaskan apa yang tidak dapat diubah oleh spesialis, tetapi jangan menciptakan batasan hanya karena Anda terbiasa dengan satu solusi tertentu.

Spesialis perlu tahu tingkat kerja sama yang dapat menjadi dasar proposalnya.

Jelaskan apakah Anda akan menyediakan:

• pengambil keputusan,
• akses sistem,
• materi yang sudah ada,
• data,
• akun pengujian,
• informasi dari tim,
• akses kepada pengguna,
• konten,
• pertemuan rutin,
• tanggapan dalam waktu tertentu.

Jika Anda belum tahu apa yang dapat disediakan, menyatakan hal itu tetap berguna.

Kurangnya akses terhadap data, materi, atau orang dapat mengubah metode, biaya, dan jadwal. Ini bukan rincian administrasi kecil. Ini adalah bagian dari kondisi yang menjadi dasar proposal.

Tidak semua tanggal mempunyai arti yang sama.

Bedakan antara:

• tanggal mulai yang diinginkan,
• tenggat yang tidak dapat diubah,
• tanggal yang terkait peristiwa eksternal,
• tanggal perkiraan,
• tahap yang harus terjadi dalam urutan tertentu.

Jika tenggat benar-benar tidak dapat berubah, jelaskan alasannya.

Jika fleksibel, nyatakan juga.

Dengan begitu spesialis dapat mengusulkan cakupan, urutan, atau pelaksanaan bertahap yang berbeda, bukan menganggap setiap tanggal sebagai syarat mutlak.

Tidak ada satu aturan yang mengatakan klien selalu harus mengungkapkan seluruh anggaran.

Tergantung situasi, Anda dapat memberikan:

• anggaran maksimum,
• kisaran anggaran,
• anggaran untuk tahap pertama,
• keterangan bahwa Anda ingin usulan cakupan terlebih dahulu dan harga setelahnya,
• struktur pemecahan harga yang diharapkan.

Untuk perbandingan, yang terpenting adalah spesialis menyajikan biaya dengan struktur yang serupa.

Contoh:

"Tampilkan harga secara terpisah untuk analisis, desain, penerapan, dan pemeliharaan bulanan. Sebutkan juga biaya layanan pihak ketiga yang tidak termasuk."

Format ini jauh lebih mudah dibandingkan daripada empat total harga yang masing-masing mencakup hal berbeda.

Ketidakpastian tidak hilang hanya karena tidak ditulis.

Jika Anda belum tahu:

• berapa banyak data yang harus dipindahkan,
• apakah antarmuka eksternal mendukung operasi yang dibutuhkan,
• apakah seluruh konten akan siap,
• apakah kode saat ini dapat dikembangkan secara wajar,
• apakah persetujuan yang diperlukan akan diterima tepat waktu,

katakan secara terbuka.

Panduan GAO tentang estimasi biaya yang dapat dipercaya menekankan pentingnya asumsi yang eksplisit serta analisis risiko dan ketidakpastian. [6]

Spesialis yang baik kemudian dapat:

• menambahkan cadangan,
• mengusulkan tahap penelusuran awal,
• memberi harga untuk beberapa pilihan,
• menyebut kondisi yang akan mengubah harga,
• menolak berpura-pura memberi ketepatan yang memang belum dapat dicapai secara jujur.

Ketidakpastian yang dinyatakan lebih baik daripada asumsi yang disembunyikan.

Jika Anda sudah tahu apa yang penting dalam keputusan, sampaikan sebelum proposal disusun.

Anda dapat menilai:

• kesesuaian pendekatan yang diusulkan,
• pengalaman dengan masalah serupa,
• kualitas bukti pekerjaan sebelumnya,
• kewajaran jadwal,
• ketersediaan,
• pendekatan terhadap pengelolaan risiko,
• kemampuan orang yang benar-benar akan bekerja pada proyek,
• harga,
• biaya pemeliharaan,
• kualitas komunikasi.

Panduan Bank Dunia saat ini mengenai Rated Criteria menyebut bahwa kriteria nonharga dapat mencakup kualitas metode dan rencana kerja, pengelolaan risiko, kinerja dan kapasitas, serta personel utama. Kriteria disesuaikan dengan pengadaan dan diberi bobot sesuai kepentingannya. [7]

Ini tidak berarti pekerjaan kecil memerlukan sistem penilaian formal.

Cukup jawab pertanyaan ini sebelum mengirim permintaan:

"Selain harga, apa yang membuat satu proposal lebih baik bagi saya daripada proposal lain?"

Jika Anda benar-benar ingin membandingkan proposal, minta semua pihak menjawab kumpulan pertanyaan dasar yang sama.

Contoh:

1. Bagaimana Anda memahami masalah dan hasil yang diharapkan?
2. Pendekatan apa yang Anda usulkan?
3. Apa tepatnya yang termasuk dalam proposal Anda?
4. Apa yang dikecualikan?
5. Asumsi apa yang Anda gunakan?
6. Bagaimana jadwalnya?
7. Apa yang Anda perlukan dari klien?
8. Apa risiko utamanya?
9. Berapa harganya dan apa tepatnya yang termasuk?
10. Pengalaman serupa atau bukti kerja apa yang relevan untuk pekerjaan ini?

Dalam pengadaan publik, penyeragaman jawaban, kriteria, dan format harga digunakan agar proposal dapat dinilai pada dasar yang sama. Government Commercial Function menekankan perlunya informasi yang cukup untuk menghitung biaya dengan tepat dan membandingkan secara setara. [2]

Format bersama tidak boleh menghapus perbedaan antarspesialis. Format itu hanya perlu membuat perbedaan terlihat pada tempat yang sama.

Itu bergantung pada tujuan permintaan.

Menyampaikan anggaran dapat membantu ketika:

• cakupan dapat disesuaikan dengan dana yang tersedia,
• Anda ingin rekomendasi pilihan terbaik dalam batas tertentu,
• Anda ingin cepat menyaring proposal yang tidak sesuai kenyataan keuangan proyek.

Tidak menyampaikan seluruh anggaran dapat masuk akal ketika:

• Anda terlebih dahulu ingin pandangan independen mengenai cakupan yang tepat,
• Anda belum mengetahui biaya yang realistis,
• Anda membandingkan beberapa model solusi,
• proses memerlukan cara pengumpulan harga yang berbeda.

Situasi terburuk bukan selalu tidak adanya anggaran. Yang lebih buruk adalah tidak menjelaskan jenis jawaban harga yang Anda harapkan.

Spesialis harus tahu apakah perlu memberikan satu total, kisaran, beberapa pilihan, harga per tahap, atau asumsi yang diperlukan untuk estimasi lebih tepat.

Deskripsi pekerjaan yang baik tidak harus menjawab semua pertanyaan.

Deskripsi dapat jujur menyatakan:

• "Kami belum tahu apakah sistem saat ini dapat dikembangkan dengan aman.",
• "Kami belum mengetahui jumlah tepat catatan yang perlu dipindahkan.",
• "Kami belum memutuskan apakah bahasa kedua masuk tahap pertama.",
• "Kami memerlukan bantuan untuk memilih pilihan terbaik."

Ini adalah informasi yang berharga.

Ketidakpastian harus memengaruhi cara proposal disiapkan, bukan menghilang dari dokumen.

Dalam beberapa keadaan, layanan pertama terbaik bukan pelaksanaan penuh, tetapi tahap penelusuran singkat yang berakhir dengan keputusan, cakupan lebih tepat, atau estimasi lebih dapat dipercaya.

1. Memberikan kumpulan informasi berbeda kepada setiap spesialis.

2. Memberi daftar fitur tanpa menjelaskan masalah dan tujuan.

3. Tidak menjelaskan apa yang sudah ada.

4. Menyembunyikan batasan yang kemudian mengubah cara pelaksanaan.

5. Meminta satu harga akhir tanpa menjelaskan apa yang harus termasuk.

6. Menilai proposal dengan kriteria yang tidak Anda tentukan sebelumnya.

7. Menganggap penjelasan rinci tentang masalah sama dengan memaksakan solusi secara rinci.

1. Apakah saya sudah menjelaskan masalah, bukan hanya solusi yang saya bayangkan?
2. Apakah hasil yang ingin dicapai jelas?
3. Apakah spesialis memahami keadaan saat ini?
4. Apakah jelas apa yang harus dipertahankan?
5. Apakah batas tahap pertama jelas?
6. Apakah hasil serahan utama sudah disebutkan?
7. Apakah batasan nyata sudah dijelaskan?
8. Apakah jelas apa yang saya sediakan?
9. Apakah jadwal dijelaskan bersama tingkat keluwesannya?
10. Apakah format harga memungkinkan proposal dibandingkan?
11. Apakah ketidakpastian terpenting sudah dijelaskan dengan terbuka?
12. Apakah saya tahu apa yang akan dinilai selain harga?
13. Apakah semua spesialis akan menjawab pertanyaan yang serupa?
14. Apakah saya memberi ruang untuk solusi yang lebih baik daripada yang saya bayangkan?

Deskripsi pekerjaan yang baik memiliki dua tujuan yang tampak bertentangan.

Deskripsi harus cukup spesifik agar beberapa spesialis menghitung masalah yang sama.

Pada saat yang sama, deskripsi harus cukup terbuka agar masing-masing dapat menawarkan pendekatan sendiri yang mungkin lebih baik.

Urutan yang berguna:

masalah -> hasil -> kondisi saat ini -> cakupan -> hasil serahan -> batasan -> tanggung jawab klien -> jadwal -> format harga -> ketidakpastian dan risiko -> kriteria pilihan -> format jawaban bersama.

Jika setelah menerima proposal Anda menemukan satu orang menghitung seluruh proyek, orang kedua hanya analisis, dan orang ketiga mengasumsikan integrasi tambahan, masalahnya mungkin bukan pada harga.

Mereka mungkin menerima pekerjaan yang berbeda meskipun semua orang mendapat teks yang sama.

[1] UK Government - The Sourcing Playbook
Buka sumber

[2] Government Commercial Function - How to write a procurement specification
Buka sumber

[3] UK Government - The Digital, Data and Technology Playbook
Buka sumber

[4] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
Buka sumber

[5] World Bank - Sample Consultants Terms of Reference
Buka sumber

[6] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
Buka sumber

[7] World Bank - Rated Criteria
Buka sumber

Catatan metodologis: sumber-sumber terutama berasal dari konteks pengadaan publik dan pengelolaan biaya. Sumber tersebut tidak disajikan sebagai aturan langsung untuk pasar spesialis swasta. Artikel hanya menggunakan prinsip yang benar-benar didukung: kejelasan persyaratan, fokus pada hasil, keterbukaan asumsi dan risiko, informasi harga yang dapat dibandingkan, serta penilaian kualitas dengan kriteria selain harga saja.