Moscow Method
Pakar Dai Clegg dan Richard Barker mengusulkan metode MoSCoW ini dalam makalah mereka yang berjudul “Case Method Fast-Track: A RAD Approach” pada tahun 1994. Pada awalnya metode ini dimaksudkan untuk digunakan dengan Dynamic Systems Development Method (DSDM), namun sejak lama metode ini telah diadopsi di banyak wilayah bisnis.
Metode MoSCoW merupakan cara pembagian prioritas dengan level yang ditentukan untuk suatu kebutuhan (requirement/customer need), fungsi dari produk ataupun bagian dari proyek yang akan dibuat. Metode MoSCoW paling efektif digunakan untuk memprioritaskan kebutuhan, fungsi atau bagian dalam proyek dengan tenggat waktu tetap atau ketat. Hal ini dapat dilakukan dengan memahami gagasan bahwa semua kebutuhan, fungsi, atau bagian proyek dapat dianggap penting namun harus diprioritaskan untuk memberikan manfaat terbesar dalam jangka waktu tercepat.
MoSCoW sendiri adalah akronim yang dirancang untuk mencerminkan empat kategori yang digunakan oleh metode ini untuk menentukan prioritas yaitu Must, Should, Can, Won’t. Huruf kecil “o” ditambahkan hanya untuk memudahkan akronim untuk diucapkan.
Dalam membagi kebutuhan, fungsi, atau bagian proyek kedalam empat kategori MoSCoW dapat digunakan beberapa pedoman berikut :
| Must | Should | Could | Won’t |
| Hal yang termasuk dalam kategori ini harus dicapai dalam solusi atau produk akhir | Hal yang termasuk dalam kategori ini merupakan hal yang penting bagi solusi atau produk akhir namun tidak harus dicapai dalam pengerjaan yang sedang berjalan | Hal yang termasuk dalam kategori ini merupakan tambahan pemanis atau dikenal sebagai “nice-to-have” bagi solusi atau produk akhir | Hal yang termausk dalam kategori ini merupakan hal yang tidak penting atau kritis bagi produk atau solusi akhir |
| Merupakan hal yang kritis untuk produk atau solusi yang ada | Merupakan hal yang memiliki prioritas tinggi sehingga harus dicapai bila waktu dan sumber daya memungkinkan | Solusi atau produk akhir dapat tetap digunakan atau dianggap layak tanpa memiliki hal dalam kategori could | Merupakan hal dengan nilai terkecil bagi klien atau pengguna dan tidak mempengaruhi keberhasilan proyek |
| Jika tidak berhasil dicapai dalam solusi atau produk akhir, maka solusi atau produk akhir akan dianggap gagal | Bukan merupakan hal yang kritis bagi solusi atau produk akhir tetapi memberikan nilai tambah yang besar bagi pengguna atau klien | Dapat meningkatkan kepuasan pengguna atau klien dengan tambahan sumber daya proyek yang kecil | Dapat berupa sebuah permintaan klien atau pengguna yang tidak termasuk dalam ruang lingkup proyek untuk waktu yang ditentukan |
Setelah membagi fungsi, kebutuhan, dan bagian proyek dalam empat kategori prioritas yang ada maka pengembangan solusi atau aplikasi dapat dilakukan dengan memfokuskan pembagian usaha, sumber daya, dan waktu pengerjaan. Dari 100% usaha total, 80% usaha, sumber daya, dan waktu maksimum pada awal proyek akan difokuskan kepada pengerjaan kategori must dan should. 60%-nya harus difokuskan dalam menyelesaikan hal-hal yang termasuk dalam kategori must sedangkan 20% -nya harus difokuskan dalam penyelesaian kategori should. 20% sisa usaha, sumber daya, dan waktu yang ada akan digunakan dalam penyempurnaan solusi atau produk akhir, dan jika terdapat sisa waktu maka dapat dilakukan penyelesaian hal-hal dalam kategori could.
