Persyaratan ideal akan datang kembali

Di bagian sebelumnya

Pada bagian pertama, saya mengumumkan serangkaian artikel tentang pekerjaan analis di pra-proyek. Itu daftar masalah, solusi dan prinsip yang perlu Anda ingat ketika memulai proyek TI.

Pada bagian kedua, saya berbicara tentang masalah yang sering terjadi pada pra-proyek.

Dalam posting terakhir, kami membahas bagian pertama dari prinsip-prinsip dasar:

• Desain sistem TI dan klasifikasi produk TI.
• Level model V dan siklus hidup sistem.
• Pandangan pada sistem sebagai aset keuangan.

Dalam catatan ini, kita akan mengakhiri dengan deskripsi "bagaimana", untuk membahas lebih lanjut apa yang harus dilakukan jika tidak berhasil dengan benar.

Apa yang akan Anda pelajari dari catatan ini:

• Pada fase kerucut ketidakpastian dan desain.
• Tentang cara kerja evaluasi.
• Tentang ruang lingkup penuh tugas fase pra-proyek dan nilai-nilai yang direalisasikan dalam proses ini.
• Tentang cara mendapatkan sumber daya yang cukup untuk pra-proyek.

Jika Anda tidak ingin menunggu bagian siklus berikutnya, Anda dapat menonton video laporan saya, berdasarkan seri artikel ini ditulis.

Siklus Hidup Sistem dan Kerucut Ketidakpastian

Cone of Uncertainty adalah salah satu konsep utama desain dan manajemen proyek modern. Inti dari konsep: semakin sedikit informasi yang kita miliki, semakin besar ketidakpastian yang dapat diungkapkan dalam bentuk penyebaran dalam hal dan biaya proyek.



Setiap fase membangun sistem menghilangkan bagian dari ketidakpastian. Ketika melewati fase khas suatu proyek, ketidakpastian menurun secara eksponensial:

• Ketika kami memiliki gagasan yang dinyatakan dalam setengah halaman singkat, penyebaran biaya dan pengembalian dapat mencapai beberapa urutan besarnya.

• Ketika ada persyaratan bisnis, ketika rencana bisnis atau model bisnis dikembangkan, kami mengurangi penyebaran biaya / pengembalian ke pesanan.

• Untuk mengurangi penyebaran, Anda perlu membuat keputusan penting tentang penampilan dan desain sistem. Studi ini mengurangi penyebaran menjadi setengah-setengah. Terlepas dari kenyataan bahwa sebarannya masih besar, analisis hubungan antara pengembalian dan biaya memberikan keputusan utama - apakah kita akan membangun sistem atau mencari sesuatu yang lebih menguntungkan.

• Dengan menentukan kondisi di mana sistem akan dibangun (siapa yang akan melakukannya dan dalam jangka waktu berapa), kita dapat mengurangi penyebaran biaya ke nilai-nilai yang dapat dikerjakan dengan metode manajemen proyek, meletakkan cadangan dan menangani risiko. Kondisi yang ditentukan dicatat dalam laporan kerja.

• Hanya desain teknis yang memberikan perkiraan yang hampir akurat dengan kesalahan yang dapat diterima oleh bisnis.

Apa yang mengikuti dari ini:

• Dari sudut pandang alokasi sumber daya, kita harus punya waktu untuk mengurangi proyek sebelum kita menghabiskan sebagian besar biaya jika tidak lagi menguntungkan. Fase dari brief ke desain teknis harus menempati sebagian kecil dari total biaya sistem.

• Anda juga perlu memahami bahwa Anda tidak dapat menemukan ide dan segera menetapkan biaya. Ketika Anda diberitahu bahwa ada 20 juta di sini dan itu sudah pasti, hanya memiliki brief - jangan percaya, itu tidak benar.

• Persyaratan bisnis dan pengembangan konseptual perlu dilakukan, karena menghilangkan ketidakpastian, tetapi ini mungkin tidak menangkis jika proyek tidak dimulai. Akibatnya, fase-fase harus semurah mungkin, tetapi meringankan ketidakpastian dengan cara yang berkualitas.

Bagaimana cara kerja evaluasi?

Ada kesalahpahaman umum yang mencegah peluncuran normal pekerjaan pra-proyek: jika kita tidak dapat dengan cepat memberikan penilaian yang akurat, maka kita tidak perlu repot dengan persyaratan sama sekali. Ini tidak benar. Jumlah perkiraan yang tidak akurat, lebih tepatnya, adalah fakta dari teori probabilitas.



Dalam hal ini, studi pra-desain harus memberikan pembagian sistem dan rencana kerja menjadi beberapa lusin bagian yang sebanding, dan penilaian untuk setiap bagian harus dilakukan dengan analogi atau metode yang lebih akurat. Jumlah peringkat akan memiliki spread yang lebih kecil dari setiap peringkat individu.
Jika kualitas studi konseptual tidak memungkinkan kami untuk mendapatkan pembagian sistem menjadi bagian-bagian yang dapat diterima untuk penilaian, maka kami tidak mengurangi penyebaran penilaian dan tidak ada gunanya menghubungkan dengan studi seperti itu.

Tahapan proyek dari sudut pandang mode evaluasi adalah sebagai berikut:

• Ketika ada ide yang diungkapkan dalam setengah halaman singkat, kami dapat mengevaluasi dengan analogi.

• Ketika kami telah mengerjakan persyaratan bisnis, rencana bisnis atau model bisnis, kami dapat menyoroti parameter kunci sistem dan melakukan penilaian dengan analogi menggunakan faktor skala besar.

• Konsep ini memberikan pembagian menjadi beberapa lusin bagian dan pekerjaan, yang memungkinkan Anda untuk merangkum perkiraan yang dibuat dengan analogi dan menghitung rencana manajemen risiko utama.

• Kerangka acuan menggantikan penilaian bagian-bagian sistem dengan analogi dengan kewajiban pemasok berdasarkan jenis pekerjaan. Perkiraan bagian yang dibuat dengan analogi dikonversi ke perkiraan ahli. Risiko kesalahan dalam penilaian diteruskan ke pemasok.

• Desain teknis memungkinkan membagi sistem menjadi ratusan dan ribuan bagian, yang masing-masing dievaluasi secara ahli atau dengan penggunaan statistik pada implementasi proyek sebelumnya.

Jika esensi yang dijelaskan di atas tidak diletakkan dalam karya pra-desain, lebih baik tidak melakukannya. Untuk mencapai pengurangan nyata dalam ketidakpastian, perlu tidak hanya untuk meningkatkan ketebalan bundel dokumentasi untuk sistem, tetapi juga untuk memastikan bahwa persyaratan dan solusi yang terukur dan layak diletakkan di sana.

Gagasan umum lainnya adalah: "Persyaratan bisnis tidak dapat diukur." Ingat - ini bohong!

Apa yang perlu Anda capai dalam pra-proyek

Di bagian sebelumnya, ini disebutkan dalam hal masalah. Sekarang ulangi secara singkat tugas apa yang harus ditetapkan dan diselesaikan dalam setiap pra-proyek:

1. Memahami waktu dan biaya untuk merencanakan biaya dan membuat keputusan go / not go. Dianjurkan untuk memprediksi efek dan kembali untuk mempercepat keputusan ini.
2. Untuk menjual sistem:
   
   
   • Tunjukkan pada pelanggan pengertian tentang tujuannya.
   • Tunjukkan pada pengguna solusi untuk masalah mereka.
   • Berhasil menyelesaikan penawaran untuk anggaran (selalu ada).
3. Untuk membuat dasar untuk penerimaan (kontrak untuk volume dan kualitas hasilnya adalah tugas teknis), jangan lupa untuk memasukkan ke dalam rencana validasi sistem yang dihasilkan dari sudut pandang pembenaran praktis dari harapan semua pihak.
4. Tentukan sumber daya: jenis, tahapan, jadwal, volume pekerjaan, dan sumber daya untuk mengkonfirmasi perkiraan pelaku dan memperbaiki biaya sistem.

Jika tugas-tugas tersebut tidak ditetapkan secara eksplisit dan solusinya tidak direncanakan, lebih baik tidak membuang-buang waktu sama sekali - proyek ini dapat menjadi sukses hanya secara kebetulan.

Mengapa itu mungkin tidak (atau bahkan tidak bisa) bekerja

Sebagai hasil dari semua pertimbangan sebelumnya, kami memiliki 3 kondisi yang saling bertentangan:

1. Analisis pradesain perlu dilakukan dengan cepat.
2. Analisis pradesain harus dilakukan dengan murah.
3. Analisis pra-desain harus dilakukan secara kualitatif.

Mereka yang terbiasa dengan aturan desain segitiga memahami bahwa ini tidak terjadi.

Ada beberapa kesulitan tambahan:

1. Analisis pra-proyek dapat menunjukkan pengembalian yang rendah atas solusi yang diusulkan, dan ini tidak akan menarik bagi pelanggan dan sponsor.
2. Analisis pra-proyek dapat meningkatkan volume proyek atau total biaya kepemilikan relatif terhadap asumsi awal, dan ini lagi-lagi akan menjadi tidak menarik bagi pelanggan dan sponsor.
3. Analisis pra-proyek dapat mengurangi volume proyek sehubungan dengan asumsi awal, dan ini seringkali tidak menarik bagi kontraktor eksternal.

Sehubungan dengan semua kesulitan ini, saya ingin Anda dan saya memahami satu hal: masalah pra-proyek tidak dapat diselesaikan jika kita tidak memihak sponsor dan tidak memandang proyek TI sebagai aset keuangan.

Dalam komentar pada artikel sebelum terakhir, pendapat tersebut disuarakan: “Pra-proyek harus dibuka sedini mungkin, tetapi harus diingat bahwa ruang lingkup pra-proyek dibatasi oleh efektivitasnya. Pra-proyek semacam itu dianggap efektif, setelah itu proyek akan diluncurkan. Ini adalah indikator utama utama efektivitas pra-proyek. ” (c) WizardryIB

Ini adalah sudut pandang yang cukup umum di antara manajer proyek, karena jika sesuatu dipercayakan kepada Anda, Anda harus bunuh diri, memeras tim ke tetes terakhir, menyerahkan senjata Anda ke pemasok sebelum melanggar, memperkosa pelanggan, tetapi mencapai tujuan.

Di sisi lain, jika manajer proyek menutup proyeknya sendiri, ia akan mengurangi tempat kerjanya sendiri.

Pendekatan yang tepat adalah menyingkirkan aset yang buruk sesegera mungkin. Tugas analis dan manajer dalam pra-proyek adalah melakukan ini.

Cara mendapatkan anggaran untuk pra-proyek

Untuk menapaki jalan menuju penghapusan ketidakpastian yang konstruktif dan konsisten di sekitar proyek TI, perlu diklarifikasi dengan pelanggan dan sponsor posisi umum mengenai sikap terhadap proyek sebagai aset keuangan.

Gambar menunjukkan rasio normal dari ketidakpastian, investasi dan pengembalian.



Selama ketidakpastian itu besar, kita harus berinvestasi sedikit dan menguranginya.

Setelah ketidakpastian dengan rasio investasi dan manfaat menjadi tingkat yang dapat diterima, Anda dapat menginvestasikan sebagian besar sumber daya untuk kembali. Pada akhir setiap fase, keputusan yang jujur ​​harus dibuat: bekerja pada atau menutup proyek.

Untuk melakukan ini, pada akhir setiap fase harus ada penilaian rasio investasi dan pengembalian pada tingkat akurasi yang alami untuk fase saat ini.

Pelanggan perlu menunjukkan tingkat ketidakpastian saat ini, penilaian manfaat dan biaya yang wajar saat ini. Jika manfaat melebihi biaya, masuk akal untuk membahas penghapusan ketidakpastian lebih lanjut.

Retorika mungkin seperti ini: "Kami melihat perkiraan manfaat yang secara signifikan melebihi biaya sistem, mari kita habiskan sebagian kecil dari nilai yang diperkirakan atau manfaat untuk memperbaiki perkiraan dan memutuskan awal sistem."

Rekomendasi saya (sangat rata-rata) tentang rasio biaya komponen pra-proyek:

• Segala sesuatu yang terjadi sebelum pembangunan seharusnya tidak memakan biaya lebih dari 10-30% dari proyek.

• Pra-proyek harus mengurangi biaya urutan yang lebih kecil - ini adalah 1-3% dari biaya yang diproyeksikan dari sistem.

• Pada tahap awal, selama tidak ada persyaratan bisnis, mungkin tidak ada nilai yang diprediksi dan harus ditolak dari pengembalian yang dihitung - Anda dapat mengambil 0,1-0,2% untuk umur sistem pada anggaran untuk membuat persyaratan bisnis (dengan mempertimbangkan bahwa itu tidak dimulai setiap proyek yang diusulkan).

Misalnya, jika kita menjual sistem yang harganya ~ 100 juta (dengan analogi). Ini masuk akal jika pengembalian operasinya setidaknya ~ 300-500 juta, mengingat akurasi rendah dari semua perkiraan.

Dalam hal ini, biaya berikut dapat dianggap normal:

• Persyaratan bisnis - 0,5-1 juta rubel.

• Konsepnya adalah 1-3 juta rubel.

• Proyek teknis - 10-30 juta rubel.

Penyimpangan ke segala arah dimungkinkan di sini. Tetapi prinsip umumnya adalah ini: sumber daya yang diinvestasikan harus dikorelasikan dengan prediksi laba dan probabilitas penerimaannya, tergantung pada tingkat ketidakpastian saat ini.

Ringkasan singkat

Di sini kami menyelesaikan peninjauan pra-proyek yang benar dan mengulangi hal yang paling penting:

1. Proyek harus dianggap sebagai aset keuangan yang berisiko.
2. Tingkat ketidakpastian harus diketahui oleh semua dan dibahas di antara semua pihak yang berkepentingan.
3. Biaya analisis harus terkait dengan manfaat yang diprediksi dan kemungkinan penerimaannya.
4. Dalam proses pengembangan, perlu untuk mencapai kualitas persyaratan yang cukup untuk menilai biaya dan persyaratan dengan akurasi yang melekat pada fase saat ini.
5. Secara khusus, persyaratan bisnis harus sudah dapat diukur.
6. Penting untuk mengingat daftar lengkap tugas dari fase pra-proyek, penghilangan yang masing-masing meningkatkan kemungkinan kegagalan proyek dengan urutan besarnya.

Kehidupan menunjukkan bahwa karena berbagai alasan tidak selalu mungkin untuk mematuhi prinsip-prinsip ini. Dalam beberapa kasus, proyek yang rusak sebelum diluncurkan dapat disimpan, atau setidaknya sedikit ditingkatkan. Kita akan membicarakan ini di bagian selanjutnya dari seri ini.