Baca Juga
OPOSIP - Tujuan dari Proposal Software Development adalah untuk menyampaikan solusi yang akan dibaca oleh orang-orang bisnis, jadi tetap sederhana dan ke titik, tinggal jauh dari istilah-istilah teknis sebanyak mungkin. Garis besar berikut dapat digunakan sebagai untuk menyiapkan proposal pembangunan sukses Software. Penting untuk diingat bahwa orang-orang yang Anda akan hadir proposal untuk tidak memiliki banyak waktu untuk membaca dokumen panjang. Anda dapat mengambilnya dari saya, saya telah menulis ratusan proposal selama 20- plus tahun teknologi informasi: bisnis orang menginginkan informasi hanya cukup untuk memungkinkan mereka untuk membuat keputusan yang tepat.
Jika Anda merespons RFP dan harus menghormati berbagai halaman tertentu karena halaman akan dicetak atau persyaratan kandungan memaksa Anda untuk memiliki Proposal Software Development yang sangat panjang, maka pertimbangkan untuk menggunakan ringkasan eksekutif. Saya telah menambahkan bagian yang menguraikan bagaimana mempersiapkan satu di bawah ini.
Saya telah melihat template dan diskusi yang menganjurkan proposal yang berjalan pada untuk 50 atau halaman. Percayalah, Anda akan kehilangan minat eksekutif bisnis setelah halaman kelima. Setelah proposal diterima, desain dokumen secara alami akan lebih rinci karena mereka akan diperuntukkan bagi tim proyek dan akan bekerja cetak biru untuk sistem. Ini akan berlaku untuk sebagian besar klien namun (ya selalu ada tapi) kecuali tentu proposal adalah dalam menanggapi permintaan untuk Proposal (RFP) dan kemudian Anda harus mematuhi RFP. Juga sebuah badan pemerintah atau militer mungkin akan memiliki pedoman yang ketat tentang bagaimana mempersiapkan Proposal Software Development dan dapat mencakup beberapa halaman (10, 20, 30, 50 atau lebih) tergantung pada kompleksitas sistem. Peraturan ini masih berlaku untuk organisasi besar yang mungkin memiliki proses lamaran resmi terutama jika mereka adalah sebuah perusahaan publik dan harus mematuhi standar atau peraturan ISO, atau Sarbannes-Oxley apapun.
Jika proposal adalah lebih dari 20 halaman, kemudian Anda dapat mempertimbangkan memberikan ringkasan eksekutif yang Pager satu bagian dalam proposal. Anda bahkan dapat memberikan ringkasan eksekutif dalam PowerPoint format. Jika Anda berencana menggunakan ringkasan eksekutif, dalam Software proposal pembangunan presentasi, hadir proposal menggunakan ringkasan eksekutif dan eksekutif dapat membaca melalui proposal saat kemudian dalam waktu, seperti selama penerbangan bisnis.
Yang mengatakan, garis besar berikut adalah benar-benar baik template yang dapat Anda gunakan untuk mempersiapkan proposal softwaredevelopemnt Anda sendiri. Saya selalu diingat aturan Elevator Pitch ketika mempersiapkan proposal, dan Anda harus juga. Pada dasarnya Elevator Pitch menetapkan bahwa proposal Anda tidak boleh lebih lama maka waktu yang dibutuhkan untuk mengambil Lift dari lantai ke lantai atas dari sebuah gedung di jalan untuk mempresentasikan proposal.
Jika Anda merespons RFP (Request For Proposal), maka termasuk informasi apapun yang diperlukan atau terdaftar sebagai wajib di RFP. Saya juga melihat RFPs yang meminta untuk memiliki tanda tangan persetujuan selain judul pada halaman pertama tetapi contoh ini, aku akan menaruh tanda tangan pada halaman dengan perubahan bagian.
Pada halaman berikutnya Anda harus menyertakan daftar isi yang daftar bagian utama proposal. Anda opsional dapat menyertakan nomor halaman jika proposal melebihi 5 halaman atau diharuskan oleh RFP.
Bagian ini sangat penting untuk proses, apakah itu adalah respon untuk RFP dari template ini atau dari sumber lain. Bagian ini dokumen konfirmasi bahwa proyek ini pergi dan memberikan persetujuan mengikat antara berbagai anggota proyek. Anda harus tidak pernah memulai proyek sampai Anda telah memperoleh semua tanda-tangan yang diperlukan dan memiliki komitmen dari juara proyek dan stakeholder untuk memulai proyek. Sebaliknya Anda mungkin menemukan diri Anda dalam mengikat jika proyek dibatalkan atau dalam lingkup perubahan proyek atau penyerahan.
Dengan persetujuan di tempat, Ruang lingkup dan penyerahan perubahan jauh lebih sulit untuk membuat dan jika ada perselisihan, telah menandatangani persetujuan akan memberikan clear(er) yang memahami apa yang disepakati. Tentu saja selalu ada pertanyaan interpretasi.
Persetujuan harus menyertakan nama orang, judul, diikuti dengan tanda tangan mereka dan akhirnya tanggal saat dokumen yang ditandatangani.
Bagian perubahan menyediakan log semua perubahan yang sedang dibuat atau akan dibuat untuk dokumen Proposal pembangunan Software. Itu tidak mendokumentasikan perubahan apapun dalam lingkup proyek atau aspek lain dari proyek. Perubahan bagian harus mencakup minimal nama orang yang membuat perubahan, tanggal perubahan dan komentar atau keterangan perubahan.
Daftar istilah atau singkatan dan definisi mereka. Jangan berasumsi bahwa semua orang tahu arti dari istilah atau akronim, terutama jika Anda berencana menggunakan jasa konsultan eksternal dan ketentuan internal, tertanam dalam budaya perusahaan Anda dan istilah. Setiap organisasi memiliki istilah mereka sendiri dan akronim. It's ok untuk menggunakannya dalam proposal selama sebagai mereka yang didokumentasikan dengan baik.
Juga, jika setiap akronim khusus industri yang digunakan, mereka perlu untuk didokumentasikan serta sehingga setiap orang memiliki pemahaman yang jelas tentang arti istilah dan akronim dan merumuskan penafsiran yang lebih baik.
Akronim berikut berasal dari template saat ini. Mereka disediakan sebagai contoh.
RFP: Request For Proposal (Permintaan untuk Proposal)
ROI: Return on investment (Laba atas investasi)
CAGR: Compound Annual Growth Rate (Laju pertumbuhan tahunan senyawa)
IT: Information Technology (Teknologi informasi)
CAPEX: Capital Expenditure (belanja modal)
UoM: Unit of Measure ( Satuan ukuran )
Lingkup proposal harus menjelaskan pada tingkat tinggi rincian proyek secara keseluruhan, apa yang termasuk dan tidak termasuk. Lingkup harus memberikan gambaran keseluruhan, panjang proyek, tujuan utama. Apa yang Anda coba untuk mencapai dengan investasi dalam proyek pengembangan Software yang diusulkan.
Bagian ini akan mencakup tanggal awal dan akhir (diperkirakan). Pastikan untuk membangun dalam buffer dan rencana kontinjensi. Sebuah aturan yang baik adalah dengan menambahkan buffer 75% ke timeline Anda.
Anggota proyek harus mencakup juara proyek dan stakeholder. Juara adalah biasanya eksekutif yang drive keseluruhan proyek dan anggaran. Para pemangku kepentingan ini biasanya promotor internal atau sponsor. Mereka juga dapat menjadi juara tergantung pada lingkup proyek dan atau jenis organisasi yang meminta Proposal Software Development. Daftar sisa yang khas peran yang orang melakukan dalam proyek.
Berikut ini hanya disediakan sebagaimana contoh jenis partisipan proyek peran mungkin memiliki. Beberapa orang mungkin memiliki peran lebih dari satu. Tergantung pada lingkup proyek, daftar anggota proyek dapat sangat panjang atau orang yang sama mungkin menganggap peran yang berbeda.
Daftar harus berisi informasi yang benar mengidentifikasi orang, peran mereka dalam proyek, bagaimana untuk mencapai mereka dan apakah tanggung jawab mereka. Anda dapat menyertakan informasi lainnya tergantung pada RFP atau jenis organisasi Anda akan bekerja dengan dan kebijakan internal mereka.
Kebanyakan template yang tersedia menentukan bagian ini sebagai "Bisnis masalah" atau "Masalah pernyataan" namun saya sering mengalami pemimpin bisnis yang tersinggung dengan kenyataan bahwa mereka memiliki masalah dalam unit bisnis atau proses. Aku ingat satu Direktur harfiah melempar saya dari kantornya karena saya telah menyatakan bahwa kita sedang memperbaiki proses dan dia mengatakan kepada saya bahwa itu tidak akan menjadi seseorang dari IT (Information Technology) yang akan menentukan apakah ia memiliki masalah dengan proses nya atau tidak.
Jadi berhati-hati dengan kata-kata. Saya selalu menggunakan istilah "Peluang bisnis" karena pada akhirnya, proposal adalah dalam menanggapi kesempatan bisnis untuk meningkatkan proses yang mendukung proses atau mengotomatisasi proses
Di bagian Ikhtisar solusi, Anda dapat memberikan gambaran yang tingkat tinggi dari sistem. Ikhtisar ini dapat mencakup peta navigasi jika proposal adalah untuk situs web atau aplikasi web. Anda juga dapat menyertakan flowchart proses aliran. Juga Anda dapat memasukkan diagram komponen utama dari sistem.
Tujuan di sini adalah untuk memberikan orang yang membuat keputusan informasi yang cukup sehingga mereka mengerti apa sistem ini begitu, bagaimana ia akan bekerja, dan apa yang blok bangunan utama. Tentu saja ini adalah hanya pedoman sebagai organisasi mungkin memiliki format resmi yang mendefinisikan apa yang Anda akan perlu untuk furniss dalam proposal, terutama yang Anda berurusan dengan sebuah badan pemerintah atau Departemen Pertahanan.
Bagian ini menyediakan sebuah mekanisme untuk memetakan fitur dari sistem yang diusulkan untuk nyata penyampaian. Saya juga melihat bagian ini berisi perkiraan waktu untuk menyelesaikan penyampaian, tapi saya tidak suka menggunakan ini karena terlalu ketat dan menciptakan dasi. Ketika bekerja pada proyek, penyerahan mungkin tidak berbaris persis seperti yang ditulis, jadi jika Anda melakukan pada kertas untuk menyelesaikan penyampaian oleh waktu tertentu, menghilangkan atau mengurangi elastisitas setiap kemudian ketika Anda benar-benar melakukan proyek.
Kolom lain yang dapat ditambahkan adalah rilis Deliverable milik. Hal ini berguna jika proyek akan dikirim selama jangka waktu yang lebih lama dan akan ada beberapa rilis. Hal ini juga dapat diterapkan Agile atau Lean berbasis proyek yang mana setiap fitur atau pengguna cerita milik sebuah rilis.
Konsep ini sederhana; untuk setiap fitur dalam sistem, menyediakan nama fitur, deskripsi singkat dan penyampaian yang akan memenuhi kebutuhan fitur.
Anggaran & ROI mungkin adalah bagian paling penting untuk beberapa eksekutif. Mereka semua ingin tahu berapa banyak sistem akan biaya mereka atau berapa banyak dampak proyek ini akan memiliki pada anggaran Departemen mereka. Hal ini terutama berlaku jika proyek tidak disertakan dalam Capex pada awal tahun fiskal.
Kadang-kadang, bahkan jika proyek ini dianggarkan untuk, proyek lain dapat mengambil didahulukan atas proposal saat ini dan dana dapat Dialihkan dari sumber dimaksudkan mereka. Sering ada sedikit politik pertikaian terjadi di tingkat eksekutif dan manajemen untuk mendapatkan sebuah proyek dari tanah dan sering ada keadaan yang tidak terduga yang mungkin mengambil didahulukan atas proyek yang direncanakan.
Jadi bersiaplah untuk bekerja sama dengan pemangku kepentingan Anda untuk membantu dengan negosiasi atau menjadi fleksibel dan proaktif untuk menyediakan solusi yang bekerja jika situasi anggaran yang berjalan miring. Hal ini lebih baik beradaptasi proyek dengan kenyataan anggaran, bahkan menyebarkan penyerahan Sistem periode yang lebih lama waktu atau bahkan berjalan dari project. Hal ini jauh lebih baik untuk pergi kemudian telah bekerja pada sebuah proyek dan tidak dibayar dan harus resor untuk litigasi di jalan.
Tabel berikut ini adalah untuk tujuan demonstrasi hanya untuk Anda memberi Anda gambaran tentang bagaimana mempersiapkan anggaran. Tentu saja Anda akan perlu untuk menambahkan Anda sendiri item baris agar proyek Anda. Kemudian Anda mengisi kuantitas, harga satuan, satuan ukuran dan item baris total. Kemudian menghitung sampai total item baris di bagian bawah.
Ini akan memberikan gambaran yang baik dari investasi yang dibutuhkan untuk melakukan proyek Software. Sebagian besar eksekutif yang saya telah bekerja dengan ingin tahu apa yang akan menjadi tingkat pengembalian atau berapa banyak proyek ini akan biaya dari waktu ke waktu, jadi saya juga memasukkan nilai ROI sederhana dan CAGR, baik menggunakan perkiraan saya sendiri dan asumsi (yang harus dijelaskan) dalam proposal atau menggunakan perkiraan berperabotan dan asumsi.
ROI
Perhitungan ROI ini sangat mudah. Pada dasarnya formula adalah keuntungan - biaya dibagi dengan biaya. Formula yang disediakan di bawah ini:
ROI = (keuntungan-biaya) / biaya
Satu-satunya downside adalah bahwa perhitungan tidak memperhitungkan waktu, jadi ROI baik untuk jangka pendek proyek tapi untuk jangka panjang proyek saya umumnya termasuk CAGR (senyawa laju pertumbuhan tahunan). Perhitungan CAGR adalah tahun selama tahun tingkat pengembalian untuk saat tertentu dalam waktu.
CAGR
Rumus CAGR adalah:
CAGR = ((nilai nilai mulai akhir) ^ (1/nomor tahun)) -1
Bagian pertama adalah divisi dari nilai akhir dengan nilai awal. Hasilnya adalah dibangkitkan untuk kekuatan 1 atas jumlah tahun diinvestasikan. Nilai yang dihasilkan adalah dikurangi 1.
Dalam bagian ini Anda daftar manfaat bisnis yang proyek Software akan memberikan. Mereka dapat didaftarkan dalam format peluru selama mereka mengikat dengan tujuan secara keseluruhan. Mereka harus menunjukkan bagaimana Software atau sistem akan meningkatkan nilai bisnis.
Singkatnya, bagaimana solusi yang diusulkan akan membantu bisnis menjadi lebih sukses dan mencapai tujuan pernyataan. Menggunakan kata-kata positif dan kalimat.
Bagian kendala harus daftar semua tangible maupun intangible kendala yang Anda dapat meramalkan. Ini dapat berhubungan dengan peralatan, beberapa faktor seasonality seperti pabrik produksi yang menutup sebagian besar tanaman yang melakukan setidaknya sekali setahun sebagai contoh.
Mencoba untuk mengecilkan kendala atau melukis mereka sebagai minimal. Jangan daftar setiap aspek negatif dari Software atau sistem atau jika Anda harus, maka memberikan solusi solusi.
Jika Anda merespons RFP dan harus menghormati berbagai halaman tertentu karena halaman akan dicetak atau persyaratan kandungan memaksa Anda untuk memiliki Proposal Software Development yang sangat panjang, maka pertimbangkan untuk menggunakan ringkasan eksekutif. Saya telah menambahkan bagian yang menguraikan bagaimana mempersiapkan satu di bawah ini.
 |
| Proposal Software Development |
Panjang Proposal
Saya telah melihat template dan diskusi yang menganjurkan proposal yang berjalan pada untuk 50 atau halaman. Percayalah, Anda akan kehilangan minat eksekutif bisnis setelah halaman kelima. Setelah proposal diterima, desain dokumen secara alami akan lebih rinci karena mereka akan diperuntukkan bagi tim proyek dan akan bekerja cetak biru untuk sistem. Ini akan berlaku untuk sebagian besar klien namun (ya selalu ada tapi) kecuali tentu proposal adalah dalam menanggapi permintaan untuk Proposal (RFP) dan kemudian Anda harus mematuhi RFP. Juga sebuah badan pemerintah atau militer mungkin akan memiliki pedoman yang ketat tentang bagaimana mempersiapkan Proposal Software Development dan dapat mencakup beberapa halaman (10, 20, 30, 50 atau lebih) tergantung pada kompleksitas sistem. Peraturan ini masih berlaku untuk organisasi besar yang mungkin memiliki proses lamaran resmi terutama jika mereka adalah sebuah perusahaan publik dan harus mematuhi standar atau peraturan ISO, atau Sarbannes-Oxley apapun.
Ringkasan Eksekutif
Jika proposal adalah lebih dari 20 halaman, kemudian Anda dapat mempertimbangkan memberikan ringkasan eksekutif yang Pager satu bagian dalam proposal. Anda bahkan dapat memberikan ringkasan eksekutif dalam PowerPoint format. Jika Anda berencana menggunakan ringkasan eksekutif, dalam Software proposal pembangunan presentasi, hadir proposal menggunakan ringkasan eksekutif dan eksekutif dapat membaca melalui proposal saat kemudian dalam waktu, seperti selama penerbangan bisnis.
Template
Yang mengatakan, garis besar berikut adalah benar-benar baik template yang dapat Anda gunakan untuk mempersiapkan proposal softwaredevelopemnt Anda sendiri. Saya selalu diingat aturan Elevator Pitch ketika mempersiapkan proposal, dan Anda harus juga. Pada dasarnya Elevator Pitch menetapkan bahwa proposal Anda tidak boleh lebih lama maka waktu yang dibutuhkan untuk mengambil Lift dari lantai ke lantai atas dari sebuah gedung di jalan untuk mempresentasikan proposal.
Judul proyek
Sub judul atau informasi yang diringkas pada proposal
Proposal harus memiliki judul dan sub bagian meringkas konteks proposal Software. Anda juga menyertakan nama nama divisi, Layanan, Departemen, atau organisasi yang proyek ini bertujuan untuk.Jika Anda merespons RFP (Request For Proposal), maka termasuk informasi apapun yang diperlukan atau terdaftar sebagai wajib di RFP. Saya juga melihat RFPs yang meminta untuk memiliki tanda tangan persetujuan selain judul pada halaman pertama tetapi contoh ini, aku akan menaruh tanda tangan pada halaman dengan perubahan bagian.
Daftar isi
Pada halaman berikutnya Anda harus menyertakan daftar isi yang daftar bagian utama proposal. Anda opsional dapat menyertakan nomor halaman jika proposal melebihi 5 halaman atau diharuskan oleh RFP.
Persetujuan
Bagian ini sangat penting untuk proses, apakah itu adalah respon untuk RFP dari template ini atau dari sumber lain. Bagian ini dokumen konfirmasi bahwa proyek ini pergi dan memberikan persetujuan mengikat antara berbagai anggota proyek. Anda harus tidak pernah memulai proyek sampai Anda telah memperoleh semua tanda-tangan yang diperlukan dan memiliki komitmen dari juara proyek dan stakeholder untuk memulai proyek. Sebaliknya Anda mungkin menemukan diri Anda dalam mengikat jika proyek dibatalkan atau dalam lingkup perubahan proyek atau penyerahan.
Dengan persetujuan di tempat, Ruang lingkup dan penyerahan perubahan jauh lebih sulit untuk membuat dan jika ada perselisihan, telah menandatangani persetujuan akan memberikan clear(er) yang memahami apa yang disepakati. Tentu saja selalu ada pertanyaan interpretasi.
Persetujuan harus menyertakan nama orang, judul, diikuti dengan tanda tangan mereka dan akhirnya tanggal saat dokumen yang ditandatangani.
Name
|
Title/Role
|
Signature
|
Date
|
|---|---|---|---|
Perubahan
Bagian perubahan menyediakan log semua perubahan yang sedang dibuat atau akan dibuat untuk dokumen Proposal pembangunan Software. Itu tidak mendokumentasikan perubahan apapun dalam lingkup proyek atau aspek lain dari proyek. Perubahan bagian harus mencakup minimal nama orang yang membuat perubahan, tanggal perubahan dan komentar atau keterangan perubahan.
Author
|
Date of Change
|
Description or Comment
|
|---|---|---|
Daftar istilah & akronim
Daftar istilah atau singkatan dan definisi mereka. Jangan berasumsi bahwa semua orang tahu arti dari istilah atau akronim, terutama jika Anda berencana menggunakan jasa konsultan eksternal dan ketentuan internal, tertanam dalam budaya perusahaan Anda dan istilah. Setiap organisasi memiliki istilah mereka sendiri dan akronim. It's ok untuk menggunakannya dalam proposal selama sebagai mereka yang didokumentasikan dengan baik.
Juga, jika setiap akronim khusus industri yang digunakan, mereka perlu untuk didokumentasikan serta sehingga setiap orang memiliki pemahaman yang jelas tentang arti istilah dan akronim dan merumuskan penafsiran yang lebih baik.
Akronim berikut berasal dari template saat ini. Mereka disediakan sebagai contoh.
RFP: Request For Proposal (Permintaan untuk Proposal)
ROI: Return on investment (Laba atas investasi)
CAGR: Compound Annual Growth Rate (Laju pertumbuhan tahunan senyawa)
IT: Information Technology (Teknologi informasi)
CAPEX: Capital Expenditure (belanja modal)
UoM: Unit of Measure ( Satuan ukuran )
Ruang lingkup
Lingkup proposal harus menjelaskan pada tingkat tinggi rincian proyek secara keseluruhan, apa yang termasuk dan tidak termasuk. Lingkup harus memberikan gambaran keseluruhan, panjang proyek, tujuan utama. Apa yang Anda coba untuk mencapai dengan investasi dalam proyek pengembangan Software yang diusulkan.
Timeline
Bagian ini akan mencakup tanggal awal dan akhir (diperkirakan). Pastikan untuk membangun dalam buffer dan rencana kontinjensi. Sebuah aturan yang baik adalah dengan menambahkan buffer 75% ke timeline Anda.
Anggota proyek
Anggota proyek harus mencakup juara proyek dan stakeholder. Juara adalah biasanya eksekutif yang drive keseluruhan proyek dan anggaran. Para pemangku kepentingan ini biasanya promotor internal atau sponsor. Mereka juga dapat menjadi juara tergantung pada lingkup proyek dan atau jenis organisasi yang meminta Proposal Software Development. Daftar sisa yang khas peran yang orang melakukan dalam proyek.
Berikut ini hanya disediakan sebagaimana contoh jenis partisipan proyek peran mungkin memiliki. Beberapa orang mungkin memiliki peran lebih dari satu. Tergantung pada lingkup proyek, daftar anggota proyek dapat sangat panjang atau orang yang sama mungkin menganggap peran yang berbeda.
Daftar harus berisi informasi yang benar mengidentifikasi orang, peran mereka dalam proyek, bagaimana untuk mencapai mereka dan apakah tanggung jawab mereka. Anda dapat menyertakan informasi lainnya tergantung pada RFP atau jenis organisasi Anda akan bekerja dengan dan kebijakan internal mereka.
Team Member
|
Role
|
Contact Information
|
Responsibilities
|
|---|---|---|---|
Champion
| |||
Stakeholder
| |||
Project Manager
| |||
Architect
| |||
Analyst
| |||
Developer
|
Peluang bisnis
Kebanyakan template yang tersedia menentukan bagian ini sebagai "Bisnis masalah" atau "Masalah pernyataan" namun saya sering mengalami pemimpin bisnis yang tersinggung dengan kenyataan bahwa mereka memiliki masalah dalam unit bisnis atau proses. Aku ingat satu Direktur harfiah melempar saya dari kantornya karena saya telah menyatakan bahwa kita sedang memperbaiki proses dan dia mengatakan kepada saya bahwa itu tidak akan menjadi seseorang dari IT (Information Technology) yang akan menentukan apakah ia memiliki masalah dengan proses nya atau tidak.
Jadi berhati-hati dengan kata-kata. Saya selalu menggunakan istilah "Peluang bisnis" karena pada akhirnya, proposal adalah dalam menanggapi kesempatan bisnis untuk meningkatkan proses yang mendukung proses atau mengotomatisasi proses
Pernyataan bisnis
|
Bagaimana sistem akan memenuhi kebutuhan
|
|---|---|
Proses bisnis yang terpengaruh, situasi, masalah
|
Bagaimana akan solusi yang diusulkan akan meningkatkan area bisnis target
|
Kebutuhan apa yang sedang dibahas
|
Bagaimana proyek akan mengatasinya
|
Solusi Tinjauan
Di bagian Ikhtisar solusi, Anda dapat memberikan gambaran yang tingkat tinggi dari sistem. Ikhtisar ini dapat mencakup peta navigasi jika proposal adalah untuk situs web atau aplikasi web. Anda juga dapat menyertakan flowchart proses aliran. Juga Anda dapat memasukkan diagram komponen utama dari sistem.
Tujuan di sini adalah untuk memberikan orang yang membuat keputusan informasi yang cukup sehingga mereka mengerti apa sistem ini begitu, bagaimana ia akan bekerja, dan apa yang blok bangunan utama. Tentu saja ini adalah hanya pedoman sebagai organisasi mungkin memiliki format resmi yang mendefinisikan apa yang Anda akan perlu untuk furniss dalam proposal, terutama yang Anda berurusan dengan sebuah badan pemerintah atau Departemen Pertahanan.
Fitur & penyerahan
Bagian ini menyediakan sebuah mekanisme untuk memetakan fitur dari sistem yang diusulkan untuk nyata penyampaian. Saya juga melihat bagian ini berisi perkiraan waktu untuk menyelesaikan penyampaian, tapi saya tidak suka menggunakan ini karena terlalu ketat dan menciptakan dasi. Ketika bekerja pada proyek, penyerahan mungkin tidak berbaris persis seperti yang ditulis, jadi jika Anda melakukan pada kertas untuk menyelesaikan penyampaian oleh waktu tertentu, menghilangkan atau mengurangi elastisitas setiap kemudian ketika Anda benar-benar melakukan proyek.
Kolom lain yang dapat ditambahkan adalah rilis Deliverable milik. Hal ini berguna jika proyek akan dikirim selama jangka waktu yang lebih lama dan akan ada beberapa rilis. Hal ini juga dapat diterapkan Agile atau Lean berbasis proyek yang mana setiap fitur atau pengguna cerita milik sebuah rilis.
Konsep ini sederhana; untuk setiap fitur dalam sistem, menyediakan nama fitur, deskripsi singkat dan penyampaian yang akan memenuhi kebutuhan fitur.
Feature
|
Description
|
Deliverable
|
|---|---|---|
Anggaran & ROI
Anggaran & ROI mungkin adalah bagian paling penting untuk beberapa eksekutif. Mereka semua ingin tahu berapa banyak sistem akan biaya mereka atau berapa banyak dampak proyek ini akan memiliki pada anggaran Departemen mereka. Hal ini terutama berlaku jika proyek tidak disertakan dalam Capex pada awal tahun fiskal.
Kadang-kadang, bahkan jika proyek ini dianggarkan untuk, proyek lain dapat mengambil didahulukan atas proposal saat ini dan dana dapat Dialihkan dari sumber dimaksudkan mereka. Sering ada sedikit politik pertikaian terjadi di tingkat eksekutif dan manajemen untuk mendapatkan sebuah proyek dari tanah dan sering ada keadaan yang tidak terduga yang mungkin mengambil didahulukan atas proyek yang direncanakan.
Jadi bersiaplah untuk bekerja sama dengan pemangku kepentingan Anda untuk membantu dengan negosiasi atau menjadi fleksibel dan proaktif untuk menyediakan solusi yang bekerja jika situasi anggaran yang berjalan miring. Hal ini lebih baik beradaptasi proyek dengan kenyataan anggaran, bahkan menyebarkan penyerahan Sistem periode yang lebih lama waktu atau bahkan berjalan dari project. Hal ini jauh lebih baik untuk pergi kemudian telah bekerja pada sebuah proyek dan tidak dibayar dan harus resor untuk litigasi di jalan.
Tabel berikut ini adalah untuk tujuan demonstrasi hanya untuk Anda memberi Anda gambaran tentang bagaimana mempersiapkan anggaran. Tentu saja Anda akan perlu untuk menambahkan Anda sendiri item baris agar proyek Anda. Kemudian Anda mengisi kuantitas, harga satuan, satuan ukuran dan item baris total. Kemudian menghitung sampai total item baris di bagian bawah.
Ini akan memberikan gambaran yang baik dari investasi yang dibutuhkan untuk melakukan proyek Software. Sebagian besar eksekutif yang saya telah bekerja dengan ingin tahu apa yang akan menjadi tingkat pengembalian atau berapa banyak proyek ini akan biaya dari waktu ke waktu, jadi saya juga memasukkan nilai ROI sederhana dan CAGR, baik menggunakan perkiraan saya sendiri dan asumsi (yang harus dijelaskan) dalam proposal atau menggunakan perkiraan berperabotan dan asumsi.
proyek Item
|
jumlah
|
harga satuan
|
UoM
|
total
|
|---|---|---|---|---|
lisensi perangkat lunak
| ||||
mesin (s)
| ||||
lisensi server
| ||||
database lisensi
| ||||
konsultan pengembangan
| ||||
manajemen proyek
| ||||
pelatihan (waktu + bahan)
|
ROI
Perhitungan ROI ini sangat mudah. Pada dasarnya formula adalah keuntungan - biaya dibagi dengan biaya. Formula yang disediakan di bawah ini:
ROI = (keuntungan-biaya) / biaya
Satu-satunya downside adalah bahwa perhitungan tidak memperhitungkan waktu, jadi ROI baik untuk jangka pendek proyek tapi untuk jangka panjang proyek saya umumnya termasuk CAGR (senyawa laju pertumbuhan tahunan). Perhitungan CAGR adalah tahun selama tahun tingkat pengembalian untuk saat tertentu dalam waktu.
CAGR
Rumus CAGR adalah:
CAGR = ((nilai nilai mulai akhir) ^ (1/nomor tahun)) -1
Bagian pertama adalah divisi dari nilai akhir dengan nilai awal. Hasilnya adalah dibangkitkan untuk kekuatan 1 atas jumlah tahun diinvestasikan. Nilai yang dihasilkan adalah dikurangi 1.
Manfaat
Dalam bagian ini Anda daftar manfaat bisnis yang proyek Software akan memberikan. Mereka dapat didaftarkan dalam format peluru selama mereka mengikat dengan tujuan secara keseluruhan. Mereka harus menunjukkan bagaimana Software atau sistem akan meningkatkan nilai bisnis.
Singkatnya, bagaimana solusi yang diusulkan akan membantu bisnis menjadi lebih sukses dan mencapai tujuan pernyataan. Menggunakan kata-kata positif dan kalimat.
Kendala
Bagian kendala harus daftar semua tangible maupun intangible kendala yang Anda dapat meramalkan. Ini dapat berhubungan dengan peralatan, beberapa faktor seasonality seperti pabrik produksi yang menutup sebagian besar tanaman yang melakukan setidaknya sekali setahun sebagai contoh.
Mencoba untuk mengecilkan kendala atau melukis mereka sebagai minimal. Jangan daftar setiap aspek negatif dari Software atau sistem atau jika Anda harus, maka memberikan solusi solusi.
Terima kasih. Semoga bermanfaat
Salam Blogger
Salam Blogger
0 Komentar
Gunakanlah form komentar dengan baik dan bijak, hargailah penulis.
Komentar yang mengandung SPAM tidak akan di tampilka penulis
Penulisan markup di komentar