Cara Menentukan Harga Proyek Dan Mengelola Scope Creep

Saya yakin Anda telah membaca artikel tidak realistis yang menyarankan ada beberapa pendekatan ilmiah untuk penetapan harga yang secara ajaib akan memungkinkan Anda membuat penawaran yang akurat. Anda mungkin juga telah dituntun untuk percaya bahwa scope creep harus dihindari dengan segala cara, tetapi di dunia nyata, itu akan selalu terjadi.

Sudah waktunya bagi kita untuk berhenti memainkan permainan konyol ini dan mulai menjalankan proyek dengan cara yang tidak seperti perjudian dan lebih seperti mengikuti proses yang kuat dan andal.

Apakah saya melebih-lebihkan? Mungkin, tapi mari kita lihat di mana hal-hal yang sering salah dengan proyek digital.

Masalah Dengan Proses Proyek Kami

Dalam pengalaman saya, sebagian besar organisasi di semua industri menjalankan proyek dengan cara yang kurang lebih sama:

1. Seseorang dalam manajemen meminta proyek diselesaikan. Sayangnya, permintaan ini sering kurang detail dalam hal hasil dan cenderung hanya memiliki tujuan yang tidak jelas.
2. Sebuah komite pemangku kepentingan dibentuk untuk mendefinisikan proyek secara rinci dan memutuskan ruang lingkupnya.
3. Lingkup rinci kemudian dibawa ke tim yang akan membangunnya, dan mereka diminta untuk memperkirakan berapa lama dan berapa biayanya.
4. Proyek disampaikan sesuai spesifikasi, menekankan pengiriman tepat waktu dan sesuai anggaran. Akibatnya, scope creep menjadi musuh.
5. Proyek disampaikan, dan semua orang pindah ke proyek berikutnya dalam daftar tugas mereka.

Pendekatan ini jauh dari ideal, terutama untuk proyek digital. Digital memberi kami umpan balik yang belum pernah terjadi sebelumnya tentang perilaku pengguna dan membuatnya relatif mudah untuk menerapkan perubahan (dibandingkan dengan produk fisik). Namun, setelah ruang lingkup telah ditentukan dan penawaran diberikan, proyek menjadi terkunci, dengan semua orang enggan untuk membuat perubahan saat proyek berlangsung.

Namun mau tidak mau, ruang lingkupnya akhirnya berubah, terutama karena pemangku kepentingan memiliki interpretasi yang berbeda-beda tentang apa yang akan dibangun atau karena mereka menyadari di tengah proyek bahwa elemen-elemen penting salah.

Sebenarnya, tidak ada yang salah dengan scope creep . Tetap fleksibel dan beradaptasi saat Anda belajar lebih banyak adalah dasar untuk menciptakan layanan digital yang sangat baik. Masalahnya bukan pada scope creep tapi cara kita menjalankan proyek.

Sayangnya, karena tenggat waktu dan biaya telah disepakati, kami berusaha untuk memberikan perubahan ini dalam batasan tersebut, yang mengarah ke pemotongan sudut.

Bukan karena jadwal dan biayanya akurat sejak awal. Proyek digital rumit, seringkali melibatkan spesialis dan pemangku kepentingan yang bekerja bersama. Akibatnya, mereka sangat sulit untuk memperkirakan secara akurat.

Saya telah membaca banyak artikel yang mengusulkan metodologi untuk memperkirakan secara akurat. Namun, mereka tidak praktis di dunia nyata di hampir semua kasus, terutama karena terlalu memakan waktu untuk diterapkan. Memperkirakan sebuah proyek bermuara pada intuisi, pengalaman, dan tebakan yang terpelajar!

Seperti yang akan dikatakan siapa pun yang pernah bekerja di bidang ini kepada Anda, sebagian besar perkiraan adalah karya fiksi . Kami biasanya tidak cukup tahu sebelumnya bahkan untuk menentukan apa solusi yang tepat atau bagaimana pengguna dapat menanggapinya. Oleh karena itu tidak mungkin untuk secara akurat memperkirakan seluruh proyek di muka.

Sayangnya, ambiguitas ini sering kali mengarah pada pembagian kesalahan yang tidak adil ketika proyek pasti melewatkan tenggat waktu dan melampaui anggaran.

Untungnya, ada cara untuk memberikan perkiraan yang akurat, dan mengelola scope creep yang melibatkan perubahan proyek yang dijalankan. Rahasianya terletak pada pemecahan proyek menjadi bagian-bagian yang lebih kecil. Pendekatan ini menghindari mengambil proyek-proyek besar dan kompleks.

Pecah Proyek Menjadi Serangkaian Keterlibatan yang Lebih Kecil

Saya harus jelas pada saat ini. Saya tidak menyarankan bahwa program kerja yang ambisius itu salah. Saya bekerja untuk klien besar di situs web substansial dan program kerja yang luas. Namun, saya jarang memperlakukan keterlibatan ini sebagai satu proyek besar. Sebagai gantinya, saya memecahnya menjadi proyek yang lebih mudah dikelola yang saya cakup satu per satu.

Ketika seorang klien mendekati saya ingin melakukan proyek digital (baik besar atau kecil), saya biasanya memecahnya menjadi empat tahap yang terjadi dalam urutan berikut:

1. Penemuan,
2. Alfa,
3. Produk yang layak minimum,
4. Iterasi dan optimasi yang sedang berlangsung.

Setiap tahap adalah keterlibatan terpisah dengan hasil yang jelas. Oleh karena itu, saya tidak berkomitmen untuk keseluruhan proyek tetapi hanya untuk tahap pertama. Itu membuat memperkirakan dan mengelola ruang lingkup jauh lebih mudah.

Misalnya, Anda hanya perlu menentukan ruang lingkup tahap selanjutnya. Itu memungkinkan Anda untuk mengelola scope creep dengan lebih baik karena Anda dapat mengakomodasinya saat Anda menentukan tahap berikutnya , setelah tahap sebelumnya telah selesai.

Alih-alih memperkirakan seluruh program kerja, Anda memperkirakan proyek berikutnya dalam program itu. Selain itu, Anda dapat menggunakan tahap sebelumnya untuk membantu Anda memperkirakan dengan lebih akurat.

Setiap tahap membantu untuk menentukan dan memperkirakan tahap berikutnya, dimulai dengan penemuan.

1. Penemuan

Pada fase penemuan, saya bekerja dengan pemangku kepentingan untuk memvalidasi proyek. Bergantung pada ukuran keseluruhan proyek, ini bisa sesederhana beberapa pertemuan atau bisa jadi seluruh program kerja.

Biasanya itu mencakup elemen-elemen seperti:

• melakukan riset pengguna;
• menganalisis kompetisi;
• mengidentifikasi indikator kinerja utama;
• mendefinisikan seperti apa kesuksesan itu;
• memahami kendala;
• mengumpulkan pendapat pemangku kepentingan.

Idenya adalah bahwa fase penemuan akan memberikan definisi proyek yang lebih terinformasi, termasuk kebutuhan pengguna, tujuan bisnis, dan apa yang perlu dibuat.

Yang terpenting, ini akan memvalidasi bahwa proyek akan memberikan nilai yang diperlukan.

Kami kemudian dapat menggunakan hasil ini untuk menentukan dan memperkirakan pekerjaan yang diperlukan dalam fase alfa. Melakukannya membuat perkiraan kami lebih akurat dan juga menyesuaikan ruang lingkup berdasarkan apa yang telah kami pelajari.

2. Alfa

Fase alfa adalah saat kami menentukan bagaimana layanan digital (apakah itu aplikasi web atau situs) akan bekerja dan memastikan bahwa pengguna memiliki pengalaman positif menggunakannya.

Itu biasanya dilakukan melalui pembuatan prototipe. Pada proyek yang lebih kecil, ini mungkin tidak lebih dari beberapa maket desain. Pada proyek yang lebih besar, ini bisa menjadi prototipe fungsional yang dapat dicoba orang.

Apapun masalahnya, idenya adalah untuk memvisualisasikan layanan digital yang Anda bangun.

Kami melakukan ini karena tiga alasan.

• Pertama, visualisasi akan memastikan semua pemangku kepentingan memiliki visi bersama tentang apa yang Anda buat. Sebuah dokumen dapat diinterpretasikan dalam berbagai cara, tetapi itu jauh lebih sulit dilakukan dengan prototipe.
• Kedua, sebuah prototipe akan membuatnya lebih mudah untuk mengidentifikasi apa pun yang mungkin telah diabaikan sehingga menghindari ruang lingkup merayap lebih jauh ke bawah ketika lebih mahal untuk ditangani.
• Akhirnya, jika kita memiliki sesuatu yang nyata, kita dapat mengujinya dengan pengguna untuk memastikan bahwa itu akan sesuai dengan tujuan sebelum kita pergi ke biaya membangun hal yang nyata.

Jika tesnya buruk, kami masih memiliki ruang sebelum fase berikutnya untuk beradaptasi tanpa merusak anggaran atau mengacaukan timeline.

Seperti pada fase penemuan, kita dapat menggunakan alfa untuk memperkirakan pekerjaan yang diperlukan pada tahap berikutnya. Memiliki visualisasi tentang apa yang perlu dibangun membuat memperkirakan pekerjaan yang dibutuhkan jauh lebih mudah bagi semua pemangku kepentingan yang terlibat. Mereka dapat melihat apa yang diminta untuk mereka bangun.

Selain itu, kita dapat menggunakan pelajaran dari pengujian alpha untuk mengadaptasi apa yang akan kita buat, sekali lagi menciptakan ruang untuk perubahan dalam ruang lingkup tanpa menggagalkan proyek.

Setelah kami memiliki alfa, kami kemudian dapat bergerak dengan percaya diri ke dalam build, mengetahui bahwa kami akan membuat hal yang benar dan bahwa pengguna akan meresponsnya secara positif.

3. Produk Minimum yang Layak

Saya dulu menyebut tahap ini sebagai 'membangun'. Namun, saya menemukan bahwa pemangku kepentingan mengaitkan penyelesaian pembangunan dengan penyelesaian proyek. Pada kenyataannya, layanan digital tidak pernah selesai, karena mereka harus terus-menerus diulang untuk memastikan mereka seefektif mungkin.

Untuk menghindari masalah ini, saya mulai menyebut tahap ini sebagai produk yang layak minimum (MVP). Pada tahap ini, kami membangun dan meluncurkan versi awal layanan digital.

Dengan menyebutnya sebagai produk minimal yang layak, kami menekankan bahwa akan ada iterasi pasca-peluncuran. Itu memberi kami cara untuk menangani scope creep dan kompleksitas tak terduga dengan mendorongnya kembali hingga pasca-peluncuran. Itu memastikan proyek tetap pada jalurnya dan mempertahankan momentumnya.

Tidak dapat dihindari selama pembuatan, kami akan mengesampingkan beberapa hal hingga pasca-peluncuran. Elemen-elemen ini kemudian menjadi dasar untuk menentukan tahap akhir kami, memungkinkan kami membuat perkiraan awal untuk pengoptimalan pasca-peluncuran.

4. Iterasi dan Optimasi yang Berkelanjutan

Fase pasca-peluncuran berkaitan dengan fungsionalitas, kompleksitas, dan masalah lain yang tidak kami tangani di MVP. Daftar peningkatan ini relatif mudah untuk dicakup pada titik ini dan dapat diperkirakan dengan akurasi yang masuk akal.

Namun, selain pekerjaan ini, harus ada proses pemantauan, iterasi, dan pengujian berkelanjutan yang semakin menyempurnakan efektivitas layanan digital.

Memperkirakan seberapa banyak pekerjaan yang Anda lakukan ini harus didasarkan pada ukuran dan kompleksitas layanan digital. Perkiraan Anda juga harus proporsional dengan investasi di sisa proyek.

Dengan memecah proyek Anda menjadi empat fase ini dan menyelesaikan masing-masing secara terpisah, Anda akan menghilangkan banyak tantangan yang kami hadapi saat menggunakan pendekatan manajemen proyek tradisional.

Mengapa Memecah Proyek Berhasil

Empat manfaat signifikan muncul dari pemecahan proyek dengan cara ini:

• Setiap fase didefinisikan dengan lebih baik .
  Karena hasil dari fase sebelumnya menentukan setiap tahap, itu berarti ada visi arah yang jelas. Itu membantu pemangku kepentingan memahami ke mana arahnya dan menghindari kejutan yang tidak menyenangkan nanti.
• Proyek diperkirakan lebih akurat .
  Misalnya, daripada harus menebak berapa lama waktu yang dibutuhkan untuk memberikan proyek yang signifikan dan samar-samar dengan sejumlah besar hal yang tidak diketahui, Anda hanya memperkirakan fase berikutnya dan melakukannya berdasarkan hasil dari fase sebelumnya.
• Ini menghasilkan layanan digital yang lebih baik .
  Karena ide proyek divalidasi dan diuji dengan pengguna, Anda dapat lebih yakin bahwa produk akhir akan sesuai dengan tujuannya. Ini juga memungkinkan ruang untuk menyesuaikan ruang lingkup dan fungsionalitas antar fase untuk memastikan Anda memberikan hasil terbaik.
• Ini adalah pendekatan yang kurang berisiko .
  Perusahaan yang menugaskan layanan digital tidak perlu berkomitmen untuk seluruh proyek di muka. Jika fase penemuan gagal untuk memvalidasi kelayakan proyek, dapat dijatuhkan dengan kerugian kecil. Demikian pula, jika prototipe alfa tidak diuji dengan baik dengan pengguna, itu dapat disesuaikan sebelum semuanya menjadi terlalu mahal.

Poin terakhir ini meyakinkan jika pemasok luar digunakan untuk pertama kalinya. Alih-alih mendaftar agensi untuk proyek besar tanpa mengetahui apakah mereka dapat memberikan, klien dapat melibatkan mereka untuk fase penemuan untuk melihat seperti apa mereka. Jika mereka baik, mereka dapat terus bekerja dengan mereka. Jika tidak, mereka dapat membawa temuan itu ke agensi lain tanpa kehilangan apa pun.

Jika Anda menjalankan agensi atau pekerja lepas, Anda mungkin berpikir ini terdengar seperti ide yang buruk. Dapat dimengerti bahwa Anda lebih suka mendaftarkan klien untuk keseluruhan proyek. Namun, saya telah menghindari banyak tender kompetitif dengan pendekatan ini karena klien tidak merasa bahwa mereka mengambil risiko dengan investasi awal yang begitu kecil. Selain itu, mereka tidak merasa perlu untuk berbicara dengan berbagai pemasok karena jika mereka tidak menyukai saya, mereka dapat dengan mudah beralih.

Selain itu, menggunakan pendekatan bertahap ini akan membuat pelingkupan dan penetapan harga proyek harga tetap Anda berikutnya jauh lebih mudah. Tentu, itu tidak akan secara ajaib memberikan perkiraan atau mencegah scope creep. Namun, itu akan membuat estimasi lebih mudah dikelola karena Anda hanya melingkupi satu bagian pada satu waktu. Ini juga akan, memungkinkan Anda untuk bekerja dengan scope creep, daripada mencoba menekannya.

Jadi saran saya, apakah Anda bekerja di dalam atau di luar, di situs besar atau kecil, adalah berhenti mencoba memperkirakan dan melingkupi proyek tanpa memecahnya menjadi beberapa fase. Alih-alih, atasi satu fase pada satu waktu dan gunakan apa yang Anda pelajari untuk menginformasikan fase berikutnya . Jika ya, Anda akan memperkirakan lebih akurat, memiliki ruang untuk beradaptasi berdasarkan apa yang Anda pelajari, dan menemukan bahwa manajemen proyek lebih mudah.