Bagaimana menulis proposal pengembangan perangkat lunak

Bagaimana menulis proposal pengembangan perangkat lunak yang sukses.

Kevin Languedoc

Tujuan dari proposal pengembangan perangkat lunak adalah untuk menyampaikan solusi yang akan dibaca oleh para pebisnis, jadi tetap sederhana dan to the point; menjauhi istilah teknis sebanyak mungkin. Garis besar berikut dapat digunakan apa adanya untuk menyiapkan proposal pengembangan perangkat lunak yang berhasil. Penting untuk diingat bahwa orang yang akan Anda ajukan proposal tidak memiliki banyak waktu untuk membaca dokumen yang panjang. Anda dapat mengambilnya dari saya, saya telah menulis ratusan proposal selama lebih dari 20 tahun saya di bidang teknologi informasi: para pelaku bisnis hanya menginginkan informasi yang cukup untuk memungkinkan mereka membuat keputusan yang tepat.

Jika Anda menanggapi Request for Proposal (RFP) dan harus menghormati rentang halaman tertentu, karena halaman tersebut telah dicetak sebelumnya atau persyaratan konten memaksa Anda untuk memiliki proposal yang terlalu panjang, maka pertimbangkan untuk menggunakan Ringkasan Eksekutif. Saya telah menambahkan bagian yang menguraikan bagaimana mempersiapkannya di bawah ini.

Panjang Proposal

Saya telah melihat templat dan diskusi yang mendukung proposal yang berjalan selama 50 atau halaman. Percayalah, Anda akan kehilangan minat eksekutif bisnis setelah halaman kelima. Setelah proposal diterima, dokumen desain secara alami akan lebih detail karena akan diperuntukkan bagi tim proyek dan akan menjadi cetak biru kerja untuk sistem. Ini akan berlaku untuk sebagian besar klien tetapi (ya selalu ada tetapi) jika proposal tersebut adalah tanggapan atas Request for Proposal (RFP) maka Anda harus mematuhi RFP. Selain itu, badan pemerintah atau militer mungkin akan memiliki pedoman yang ketat tentang cara menyiapkan proposal pengembangan perangkat lunak dan dapat mencakup beberapa halaman (10, 20, 30, 50 atau lebih) tergantung pada kompleksitas sistem.Aturan ini masih berlaku untuk organisasi besar yang mungkin memiliki proses proposal formal terutama jika mereka adalah perusahaan publik dan harus mematuhi peraturan atau standar Sarbannes-Oxley atau ISO.

Ringkasan bisnis plan

Jika proposal lebih dari 20 halaman, maka Anda dapat mempertimbangkan untuk memberikan Ringkasan Eksekutif yang merupakan satu halaman dari bagian proposal. Anda bahkan dapat memberikan Ringkasan Eksekutif dalam format PowerPoint. Jika Anda berencana menggunakan Ringkasan Eksekutif dalam presentasi proposal pengembangan perangkat lunak, sajikan proposal menggunakan Ringkasan Eksekutif dan eksekutif dapat membaca proposal tersebut di lain waktu, seperti selama penerbangan bisnis.

Template

Garis besar berikut sebenarnya adalah template bagus yang dapat Anda gunakan untuk menyiapkan proposal pengembangan perangkat lunak Anda sendiri. Saya selalu mengingat aturan Pitch Elevator ketika menyiapkan proposal, dan Anda juga harus melakukannya. Pada dasarnya Promosi Elevator menetapkan bahwa proposal Anda tidak boleh lebih lama dari waktu yang dibutuhkan untuk menggunakan elevator dari lantai dasar ke lantai atas sebuah gedung dalam perjalanan Anda untuk mempresentasikan proposal.

Judul Proyek

Dengan Subtitle atau Informasi Ringkas tentang Proposal

Proposal harus memiliki judul dan sub-bagian yang meringkas konteks proposal perangkat lunak. Anda juga memasukkan nama divisi, layanan, departemen atau organisasi yang menjadi tujuan proyek.

Jika Anda menanggapi sebuah RFP (Request For Proposal), maka sertakan informasi apa pun yang diperlukan atau terdaftar sebagai wajib dalam RFP. Saya juga telah melihat RFP yang meminta Anda meletakkan tanda tangan persetujuan sebagai tambahan pada judul di halaman pertama, tetapi dalam contoh ini, saya meletakkan tanda tangan di halaman dengan bagian Perubahan.

Daftar isi

Pada halaman berikutnya, Anda harus memasukkan daftar isi yang mencantumkan bagian-bagian utama proposal. Secara opsional, Anda dapat menyertakan nomor halaman jika proposal melebihi lima halaman atau jika diminta oleh RFP.

Persetujuan

Bagian ini sangat penting untuk proses tersebut, baik itu tanggapan terhadap RFP atau dari templat ini atau dari beberapa sumber lain. Bagian ini mendokumentasikan konfirmasi bahwa proyek berjalan dan memberikan kesepakatan yang mengikat antara berbagai anggota proyek. Anda tidak boleh memulai proyek sampai Anda mendapatkan semua tanda tangan yang diperlukan dan memiliki komitmen dari juara proyek dan pemangku kepentingan untuk memulai proyek. Jika tidak, Anda mungkin akan terjebak jika proyek dibatalkan atau jika lingkup proyek berubah atau hasil.

Dengan adanya Persetujuan, perubahan ruang lingkup dan hasil kerja jauh lebih sulit untuk dilakukan dan jika ada perselisihan, persetujuan yang ditandatangani akan memberikan pemahaman yang jelas (er) tentang apa yang telah disepakati. Tentu saja, selalu ada pertanyaan tentang interpretasi.

Persetujuan harus menyertakan nama orang, gelar mereka, diikuti dengan tanda tangan mereka dan terakhir tanggal dokumen ditandatangani.



Nama	Judul / Peran	Tanda tangan	Tanggal

Perubahan

Bagian Perubahan menyediakan log dari semua perubahan yang dibuat atau akan dilakukan pada dokumen Proposal Pengembangan Perangkat Lunak. Itu tidak mendokumentasikan perubahan apa pun pada ruang lingkup proyek itu sendiri atau aspek lain dari proyek itu. Bagian Perubahan harus menyertakan setidaknya nama orang yang membuat perubahan, tanggal perubahan dan komentar atau deskripsi perubahan.



Penulis	Tanggal Perubahan	Deskripsi atau Komentar

Glosarium dan Akronim

Buat daftar istilah atau akronim dan definisinya. Jangan berasumsi bahwa semua orang tahu arti istilah atau akronim, terutama jika Anda berencana menggunakan konsultan eksternal dan istilah tersebut bersifat internal, tertanam dalam budaya dan bahasa perusahaan Anda. Setiap organisasi memiliki istilah dan akronimnya sendiri. Tidak masalah untuk menggunakannya dalam proposal asalkan didokumentasikan dengan benar.

Juga jika ada akronim khusus industri yang digunakan, akronim tersebut juga perlu didokumentasikan sehingga setiap orang memiliki pemahaman yang jelas tentang arti istilah dan akronim serta merumuskan interpretasi yang lebih baik.

Akronim berikut ini berasal dari template saat ini. Mereka diberikan sebagai contoh.

RFP: Permintaan Proposal
ROI: Laba atas investasi
CAGR: Tingkat Pertumbuhan Tahunan Gabungan
IT: Teknologi Informasi
CAPEX: Belanja Modal
UoM: Satuan Ukuran

Cakupan

Lingkup proposal harus menguraikan pada tingkat tinggi rincian proyek secara keseluruhan, apa yang termasuk dan tidak termasuk. Ruang lingkup harus memberikan gambaran keseluruhan, lamanya proyek, tujuan utama. Apa yang ingin Anda capai dengan investasi ini dalam proyek pengembangan perangkat lunak yang diusulkan.

Linimasa

Bagian ini akan mencakup tanggal mulai dan akhir (perkiraan). Pastikan untuk membangun buffer dan merencanakan kontinjensi. Rule of Thumb yang baik adalah menambahkan buffer 75% ke timeline Anda.

Anggota Proyek

Anggota proyek harus memasukkan juara proyek dan pemangku kepentingan. Juara biasanya adalah seorang eksekutif yang menggerakkan keseluruhan proyek dan anggaran. Pemangku kepentingan biasanya adalah promotor atau sponsor internal. Mereka juga bisa menjadi juara tergantung pada lingkup proyek dan atau jenis organisasi yang meminta proposal pengembangan perangkat lunak. Daftar sisa berisi adalah peran khas yang dilakukan orang dalam sebuah proyek.

Berikut ini hanya diberikan sebagai contoh jenis peran yang mungkin dimiliki peserta proyek. Beberapa orang mungkin memiliki lebih dari satu peran. Bergantung pada ruang lingkup proyek, daftar anggota proyek bisa sangat panjang atau orang yang sama dapat mengambil peran berbeda.

Daftar tersebut harus berisi informasi yang mengidentifikasi orang dengan benar, peran mereka dalam proyek, cara menjangkau mereka dan apa tanggung jawab mereka. Anda dapat memasukkan informasi lain tergantung pada RFP atau jenis organisasi yang akan Anda tangani dan kebijakan internal mereka.



Anggota tim	Wewenang	Kontak informasi	Tanggung jawab
	Juara
	Stakeholder
	Manajer proyek
	Arsitek
	Analis
	Pengembang

Peluang bisnis

Kebanyakan template yang tersedia mendefinisikan bagian ini sebagai "Masalah Bisnis" atau "Pernyataan Masalah" namun saya sering menjumpai para pemimpin bisnis yang tersinggung dengan kenyataan bahwa mereka memiliki masalah dalam unit bisnis atau proses mereka. Saya ingat seorang direktur benar-benar mengusir saya dari kantornya karena saya telah menyatakan bahwa kami sedang memperbaiki suatu proses dan dia mengatakan kepada saya bahwa bukan seseorang dari TI (Teknologi Informasi) yang akan mendikte jika dia memiliki masalah dengan prosesnya atau tidak.

Jadi berhati-hatilah dengan kata-katanya. Saya selalu menggunakan istilah “Business Opportunity” karena pada akhirnya proposal merupakan respon dari peluang bisnis untuk memperbaiki suatu proses, mendukung suatu proses atau mengotomatiskan suatu proses



Pernyataan Bisnis	Bagaimana sistem akan memenuhi kebutuhan
Proses bisnis yang terpengaruh, situasi, masalah	Bagaimana solusi yang diusulkan akan meningkatkan area bisnis sasaran
Kebutuhan apa yang sedang ditangani	Bagaimana proyek saat ini akan mengatasinya

Ikhtisar Solusi

Di bagian Ikhtisar Solusi, Anda dapat memberikan gambaran umum tingkat tinggi dari sistem. Gambaran umum ini dapat mencakup peta navigasi jika proposal ditujukan untuk situs web atau aplikasi web. Anda juga dapat memasukkan diagram alur dari aliran proses. Selain itu, Anda dapat menyertakan diagram komponen utama sistem.

Tujuannya di sini adalah untuk memberi orang yang membuat keputusan informasi yang cukup sehingga mereka memahami apa sistem itu, bagaimana itu akan bekerja, dan apa saja blok bangunan utamanya. Tentu saja, ini hanya pedoman karena sebuah organisasi mungkin memiliki format formal yang menentukan apa yang perlu Anda berikan dalam proposal, terutama jika Anda berurusan dengan lembaga pemerintah atau departemen pertahanan.

Fitur dan Hasil Kerja

Bagian ini menyediakan mekanisme untuk memetakan fitur dari sistem yang diusulkan menjadi penyampaian yang nyata. Saya juga melihat bagian ini berisi perkiraan waktu untuk menyelesaikan pengiriman, tetapi saya tidak suka menggunakan ini karena terlalu membatasi dan menciptakan keterikatan. Saat mengerjakan proyek, hasil mungkin tidak berbaris persis seperti yang tertulis, jadi jika Anda telah berkomitmen di atas kertas untuk menyelesaikan pengiriman pada waktu tertentu, itu menghilangkan atau mengurangi elastisitas di kemudian hari saat Anda benar-benar melakukan proyek.

Kolom lain yang bisa ditambahkan adalah Rilis milik Deliverable. Ini berguna jika proyek akan dikirimkan dalam jangka waktu yang lebih lama dan akan ada beberapa rilis. Ini juga dapat berlaku untuk proyek berbasis Agile atau Lean di mana setiap fitur atau Kisah Pengguna termasuk dalam Rilis.

Konsepnya sederhana; untuk setiap fitur di sistem, berikan nama fitur, deskripsi singkat dan hasil mana yang akan memenuhi persyaratan fitur.



Fitur	Deskripsi	Dapat dikirim

Anggaran dan ROI

Anggaran & ROI mungkin adalah bagian terpenting bagi beberapa eksekutif. Mereka semua sangat ingin mengetahui berapa biaya sistem atau seberapa besar dampak proyek ini terhadap anggaran departemen mereka. Ini terutama benar jika proyek tidak dimasukkan dalam Capex pada awal tahun fiskal.

Kadang-kadang, bahkan jika proyek itu dianggarkan, proyek lain mungkin lebih diutamakan daripada proposal saat ini dan dana dapat dialihkan dari sumber yang dimaksudkan. Seringkali ada sedikit perselisihan politik yang terjadi di tingkat eksekutif dan manajemen untuk menjalankan proyek dan sering kali ada keadaan tak terduga yang mungkin lebih diutamakan daripada proyek yang direncanakan.

Jadi bersiaplah untuk bekerja dengan pemangku kepentingan Anda untuk membantu negosiasi atau bersikap fleksibel dan proaktif untuk memberikan solusi yang berhasil jika situasi anggaran berjalan miring. Lebih baik untuk menyesuaikan proyek dengan realitas anggaran, bahkan menyebarkan kiriman sistem dalam jangka waktu yang lebih lama atau bahkan meninggalkan proyek. Jauh lebih baik untuk pergi daripada mengerjakan sebuah proyek dan tidak dibayar dan harus menggunakan proses pengadilan di kemudian hari.

Tabel berikut ini untuk tujuan demonstrasi hanya untuk memberi Anda gambaran tentang bagaimana menyiapkan anggaran. Biasanya, Anda perlu menambahkan item baris Anda sendiri agar sesuai dengan proyek Anda. Kemudian Anda mengisi kuantitas, harga satuan, satuan ukuran, dan total item baris. Kemudian hitung total item baris di bagian bawah.

Ini akan memberikan gambaran yang baik tentang investasi yang dibutuhkan untuk mengerjakan proyek perangkat lunak. Sebagian besar eksekutif yang pernah bekerja dengan saya ingin tahu berapa tingkat pengembaliannya atau berapa biaya proyek ini dari waktu ke waktu, jadi saya juga menyertakan nilai ROI sederhana dan CAGR, baik menggunakan perkiraan dan asumsi saya sendiri (yang pasti dijelaskan) dalam proposal atau menggunakan perkiraan dan asumsi yang dilengkapi.



Item Proyek	Jumlah	Patokan harga	UoM	Total
Lisensi perangkat lunak
Mesin
Lisensi Server
Lisensi database
Konsultan Pembangunan
Manajemen proyek
Pelatihan (Waktu + Materi)

ROI

Perhitungan ROI sangat mudah. Pada dasarnya rumusnya adalah keuntungan - biaya dibagi biaya. Rumusnya disediakan di bawah ini:

Satu-satunya downside adalah bahwa perhitungannya tidak memperhitungkan waktu, jadi ROI bagus untuk proyek jangka pendek tetapi untuk proyek jangka panjang saya biasanya menyertakan CAGR (Tingkat Pertumbuhan Tahunan Gabungan). Perhitungan CAGR adalah tingkat pengembalian dari tahun ke tahun untuk saat tertentu dalam waktu.

CAGR

Rumus CAGR adalah:

Bagian pertama adalah pembagian nilai akhir dengan nilai awal. Hasilnya dinaikkan ke pangkat 1 selama jumlah tahun yang diinvestasikan. Nilai yang dihasilkan dikurangi dengan 1.

Manfaat

Di bagian ini, Anda mencantumkan keuntungan bisnis yang akan diberikan oleh proyek perangkat lunak. Mereka dapat dicantumkan dalam format peluru selama sesuai dengan tujuan keseluruhan. Mereka harus mendemonstrasikan bagaimana perangkat lunak atau sistem akan meningkatkan nilai bisnis.

Singkatnya, bagaimana solusi yang diusulkan akan membantu bisnis menjadi lebih sukses dan mencapai tujuan pernyataannya? Gunakan kata dan kalimat positif.

Kendala

Bagian batasan harus mencantumkan batasan berwujud dan tidak berwujud yang dapat Anda perkirakan. Hal ini dapat berkaitan dengan peralatan, beberapa faktor musiman seperti penutupan pabrik produksi yang dilakukan oleh sebagian besar pabrik setidaknya setahun sekali sebagai contoh.

Cobalah untuk mengecilkan batasan atau menganggapnya sebagai minimal. Jangan mencantumkan aspek negatif apa pun dari perangkat lunak atau sistem atau jika perlu, berikan solusi alternatif.