Project Scope Management-Part 1

Salah satu aspek manajemen proyek yang paling penting dan paling sulit adalah menentukan ruang lingkup proyek. Ruang lingkup mengacu pada semua pekerjaan yang terlibat dalam menciptakan produk dari proyek dan proses yang digunakan untuk menciptakannya. Scope Management mencakup proses yang terlibat dalam menentukan dan mengendalikan pekerjaan apa yang termasuk dalam sebuah proyek. Hal ini guna memastikan bahwa tim proyek dan stakeholders memiliki pemahaman yang sama tentang produk apa yang akan dihasilkan oleh proyek dan proses apa yang akan digunakan tim proyek untuk memproduksinya. Enam proses utama dilibatkan dalam scope management yaitu :

1. Perencanaan scope management melibatkan penentuan bagaimana ruang lingkup dan persyaratan proyek akan dikelola. Tim proyek bekerja sama dengan stakeholders yang tepat untuk membuat rencana pengelolaan ruang lingkup dan rencana manajemen requirements.
2. mengumpulkan persyaratan (requirements)  meliputi menentukan dan mendokumentasikan fitur dan fungsi produk untuk serta proses yang digunakan untuk membuatnya. Tim proyek membuat dokumentasi requirements dan  requirements traceability matrix sebagai keluaran dari proses pengumpulan requiremets.
3. Mendefinisikan scope meliputi meninjau rencana pengelolaan ruang lingkup, project charter, requirements documents, dan organizational process assets untuk membuat pernyataan scope, menambahkan lebih banyak informasi saat requirements dikembangkan dan permintaan perubahan disetujui. Output utama dari definisi scope adalah pernyataan dari lingkup proyek dan pembaruan dokumen proyek.
4. Membuat WBS melibatkan pembagian kembali deliverable proyek utama ke komponen yang lebih kecil dan mudah diatur. Output utama mencakup garis besar scope dan pembaruan dokumen proyek.
5. Memvalidasi scope melibatkan formalisasi penerimaan proyek. Stakeholders, seperti sponsor memeriksa dan kemudian secara formal menerima selama proses ini. Jika tidak diterima, sponsor biasanya akan meminta perubahan. Hasil utama dari proses ini adalah proyek yang diterima, perubahan permintaan, informasi kinerja kerja, dan pembaruan dokumen proyek.
6. Kontrol scope melibatkan pengendalian perubahan pada scope proyek selama masa proyek yang merupakan tantangan pada banyak proyek IT. Perubahan pada scope sering kali mempengaruhi kemampuan tim untuk memenuhi target time dan cost, sehingga manajer proyek harus mempertimbangkan dengan cermat biaya dan manfaat dari perubahan scope tadi. Output utama dari proses ini adalah informasi kinerja pekerjaan, perubahan permintaan, dan pembaruan rencana pengelolaan proyek, dokumen proyek dan  organizational process assets.

1. Perencanaan Manajemen Ruang Lingkup (Plan Scope Management)

Langkah pertama dalam project scope management adalah merencanakan bagaimana ruang lingkup akan dikelola sepanjang masa proyek. Setelah meninjau rencana manajemen proyek, project charter, faktor lingkungan perusahaan, dan aset organisasi, tim proyek menggunakan pertimbangan dan rapat untuk mengembangkan dua output penting yaitu rencana pengelolaan ruang lingkup (scope) dan rencana pengelolaan requirements.

Rencana pengelolaan ruang lingkup merupakan bagian dari rencana manajemen proyek. Bisa bersifat informal dan luas atau formal dan rinci berdasarkan kebutuhan proyek. Sebenarnya, proyek kecil mungkin tidak memerlukan rencana pengelolaan ruang lingkup secara tertulis, namun proyek besar atau proyek yang sangat teknis seringkali mendapatkan keuntungan dari proyek tersebut. Secara umum, rencana pengelolaan scope mencakup informasi berikut :

• Bagaimana mempersiapkan detail terperinci dari proyek. Misalnya, adakah template atau pedoman yang harus diikuti ?
• Cara membuat WBS. Seringkali sulit membuat WBS yang bagus. Bagian dari rencana pengelolaan ruang lingkup ini akan memberikan saran, contoh, dan sumber daya untuk menciptakan WBS.
• Bagaiman mempertahankan dan menyetujui WBS. WBS awal sering berubah, dan anggota tim proyek terkadang tidak setuju mengenai apa yang harus disertakan. Rencana pengelolaan ruang lingkup menjelaskan pedoman untuk memelihara WBS dan mendapatkan persetujuan untuk itu.
• Cara untuk mendapatkan penerimaan proyek yang telah selesai secara formal. Sangat penting untuk memahami proses penerimaan penerimaan proyek yang diterima terutama proyek diaman pembayaran didasarkan pada penerimaan formal.
• Cara mengendalikan permintaan dan perubahan pada lingkup proyek. Organisasi sering memiliki pedoman unutuk mengirimkan, mengevaluasi dan menyetujui perubahan pada ruang lingkup, dan bagian dari cakupan rencana pengelolaan ini akan menentukan bagaimana menangani perubahan permintaan untuk proyek tersebut.

Output penting lain dari project scope management adalah rencana pengelolaan requirements. Daftar istilah IEEE 1990 tentang terminologi Rekayasa Perangkat Lunak mendefinisikan requirements sebagai berikut :

1. Suatu kondisi atau kemampuan yang dibutuhkan oleh pengguna untuk memecahkan suatu masalah atau mencapai suatu objektif.
2. Suatu kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh sistem atau komponen sistem untuk memenuhi kontrak, standar, spesifikasi atau lainnya secara dokumen formal yang dipaksakan.
3. Representasi terdokumentasi suatu kondisi atau kemampuan seperti dalam poin 1 dan 2.

Untuk beberapa proyek IT, sangat membantu untuk membagi pengembangan requirements kedalam kategori yang disebut elicitation, analysis, spesification, dan validation. Kategori ini mencakup semua kegiatan yang terlibat didalam mengumpulkan, mengevaluasi, dan mendokumentasikan requirements untuk perangkat lunak atau produk yang mengandung perangkat lunak. Penting juga untuk menggunakan pendekatan iteratif untuk menentukan requirements karena seringkali tidak jelas di awal proyek.

Rencana Pengelolaan Persyaratan (Requirements Management Plan) mendokumentasikan bagaimana requirements proyek akan dianalisis, didokumentasikan, dan dikelola. Rencana pengelolaan requirements mencakup informasi berikut :

• Bagaiman merencanakan, melacak dan melaporkan aktivitas requirements.
• Bagaimana melakukan aktivitas manajemen konfigurasi.
• Bagaimana memprioritaskan requirements.
• Craa menggunakan matriks produk.
• Bagaimana cara melacak dan menangkap atribut requirements.

2. Mengumpulkan Persyaratan (Collecting Requirements)
Langkah kedua dalam Project Scope Management adalah mengumpulkan persyaratan, seringkali yang paling sulit. Konsekuensinya apabila langkah kedua ini tidak dikerjakan dengan baik adalah pengerjaan ulang, yang dapat menghabiskan hingga setengah dari biaya proyek tersebut, terutama untuk pengembangan proyek Perangkat Lunak.  Pada gambar dibawah ini ditunjukkan bahwa biaya lebih diperuntukkan pada tahap pengembangan selanjutnya daripada memperbaikinya dalam fase ini. Sementara dalam tahap kedua ini penggunaan biaya adalah paling sedikit.

Bagian tersulitnya adalah seseorang sering tidak mempunyai proses yang cukup baik untuk mengumpulkan dan mendokumentasikan persyaratan proyek tersebut. Ada beberapa cara untuk mengumpulkan persyaratan atau requirements. Melakukan interview para stakeholders secara pribadi seringkali sangat efektif, meski mampu mengeluarkan biaya yang mahal dan menyita waktu. Kuesioner dan survei dapat menjadi cara yang efisien untuk mengumpulkan persyaratan selama stakeholders memberikan informasi yang jujur dan menyeluruh. Pengamatan juga bisa menjadi teknik yang baik untuk mengumpulkan persyaratan terutama untuk proyek yang melibatkan perbaikan proses dan prosedur kerja. Untuk proyek pengembangan Perangkat Lunak, prototipe dan analisis dokumen adalah teknik umum untuk mengumpulkan persyaratan, seperti diagram konteks yang membantu memperjelas antarmuka dan batasan proyek atau proses. Benchmarking atau menghasilkan gagasan dengan membandingkan proyek ataupun karakteristik produk tertentu dengan proyek atau produk lain didalam ataupun diluar organisasi atau perusahaan juga dapat digunakan untuk mengumpulkan persyaratan.
Meskipun ada banyak cara untuk mengumpulkan persyaratan, orang-orang yang mengerjakan proyek Perangkat Lunak pada khususnya memiliki cukup banyak kesulitan untuk menentukan dan mengelola requirements tersebut. Sebuah studi ditahun 2011 mengungkapkan beberapa statistik menarik :

• 88% proyek Perangkat Lunak melibatkan peningkatan produk yang ada daripada menciptakan produk baru.
• 86% responden mengatakan bahwa kepuasan pelanggan adalah matrik yang paling penting untuk mengukur keberhasilan pembangunan proyek, 82% mengatakan bahwa feedback dari pelanggan dan mitra merupakan sumber utama gagasan dan requirements produk dan 73% mengatakan tantangan yang paling penting bagi tim mereka adalah mendapatkan pemahaman yang jelas tentang apa yang diinginkan pelanggan, diikuti dengan mendokumentasikan dan mengelola requirements.
• 75% responden mengelola proyek dengan setidaknya 100 requirements, 20% mengelola proyek dengan lebih dari 1.000 requirements.
• 70% responden menghabiskan setidaknya 10% waktu mereka untuk mengelola perubahan pada requirements, 30% menghabiskan lebih dari 25% waktunya untuk perubahan tersebut
• Mayoritas tim pengembangan Perangkat Lunak menggunakan metodologi hybrid, 26% menggunakan teknik waterfall dan 19% menggunakan teknik agile.
• 83% tim pengembangan Perangkat Lunak masih menggunakan aplikasi Microsoft Office seperti Word dan Excel sebagai alat utama mereka untuk mengkomunikasikan requirements.
• Responden mencatat "Kolaborasi Requirements dan Manajemen Software" dan "Pemodelan Requirements dan Visualisasi" sebagai dua Perangkat Lunak teratas dalam daftar keinginan mereka, diikuti oleh Manajemen Uji dan Manajemen Proyek.

Ukuran proyek, kompleksitas, kepentingan dan faktor lainnya mempengaruhi seberapa banyak usaha yang dihabiskan untuk mengumpulkan persyaratan. Sama seperti tim proyek dapat mengumpulkan persyaratan dengan beberapa cara, ada beberapa cara untuk mendokumentasikan persyaratan. Tim proyek pertama harus meninjau Project Charter karena mencakup high level-requirements untuk proyek tersebut, dan mereka harus mengacu pada plan scope management. Mereka juga harus meninjau stakeholder management plan untuk memastikan bahwa semua stakeholders memiliki pendapat dalam menentukan requirements. Format untuk mendokumentasikan stakeholders requirements tersebut bisa hanya diselembar kertas hingga berbentuk buku catatan. Dokumen persyaratan sering dihasilkan oleh Perangkat Lunak mencakup teks, gambar, diagram, video dan media lainnya. Persyaratan sering dipecah menjadi beberapa kategori yang berbeda seperti persyatan fungsional, persyaratan layanan, persyaratan kinerja, persyaratan mutu, dan persyaratan training.

Selain menyiapkan dokumentasi requiremnets sebagai output pengumpulan persyaratan, tim proyek sering membuat matriks keterlusuran persyaratan.  Requirement Traceability Matrix (RTM) adalah tabel yang mencantumkan persyaratan, berbagai atribut, dan status persyaratan untuk memastikan semuanya ditangani. Contoh dari RTM ini seperti gambar dibawah ini :

Sumber : Kathy Schwalbe, Ph.D., PMP, Augsburg College, Information Technology PROJECT MANAGEMENT 7e.