Proses permintaan perubahan cakupan adalah cara mengevaluasi dan mengotorisasi perubahan yang diusulkan terhadap komitmen proyek yang telah disepakati. Proses ini mencatat apa yang berubah, mengapa hal itu penting, apa lagi yang terdampak, dan siapa yang dapat memutuskan. Tujuannya adalah memperjelas kompromi, bukan mencegah pembelajaran yang berguna.
Association for Project Management menjelaskan kendali perubahan sebagai evaluasi perubahan yang diusulkan terhadap baseline yang disetujui, termasuk persetujuan, penolakan, atau penundaan. Proses ringan di bawah ini merupakan adaptasi untuk penggunaan tim. Terapkan persyaratan kontrak, keuangan, keamanan, dan tata kelola organisasi Anda bila lebih ketat.
Bedakan dulu perubahan dari perincian biasa
Tidak setiap tugas yang baru ditemukan mengubah cakupan. Tim mungkin menemukan pekerjaan implementasi yang diperlukan untuk memberikan hasil yang sudah disepakati. Hal itu memengaruhi perkiraan atau metode, tetapi belum tentu mengubah komitmennya.
Tanyakan apa yang sudah diwajibkan oleh cakupan yang disetujui dan kriteria penerimaan. Permintaan dapat berupa klarifikasi, perbaikan cacat, perubahan deliverable, atau kewajiban baru. Klasifikasinya harus mengikuti kesepakatan, bukan label pilihan peminta.
Pelaksanaan agile juga perlu ruang untuk adaptasi. Menyusun ulang pekerjaan di dalam batas yang diotorisasi berbeda dari mengubah tonggak kontrak atau menambahkan komitmen operasional yang belum didukung. Tetapkan hak keputusan agar pilihan kecil yang dapat dibatalkan tidak menunggu komite, sedangkan perubahan material mendapat tinjauan yang dibutuhkan.
Jika tidak ada yang dapat menyebutkan kesepakatan saat ini, selesaikan ketidakjelasan itu terlebih dahulu. Membandingkan permintaan dengan janji yang hanya diingat seseorang tidak dapat diandalkan.
Gunakan permintaan singkat yang memperjelas keputusan
Permintaan perubahan yang berguna dapat dimulai dengan satu halaman:
| Bidang | Hal yang dicantumkan |
|---|---|
| Kesepakatan saat ini | Cakupan terkait, kriteria penerimaan, dan versi baseline |
| Perubahan yang diusulkan | Perbedaan spesifik, termasuk pengecualian |
| Alasan | Kebutuhan, bukti baru, atau kewajiban yang mendasari permintaan |
| Waktu | Kapan keputusan dan hasil dibutuhkan, serta alasannya |
| Opsi | Terima, kurangi, ganti, tunda, atau tolak |
| Dampak | Pengiriman, biaya, kapasitas, kualitas, operasi, dependensi, dan risiko |
| Rekomendasi | Opsi yang disukai beserta kompromi utamanya |
| Keputusan | Pemilik yang berwenang, hasil, ketentuan, dan tanggal |
Hindari “tanpa dampak” tanpa dasar. Perubahan mungkin hanya menggunakan sedikit waktu pemrograman, tetapi tetap membutuhkan pelatihan, persiapan dukungan, penerjemahan, migrasi data, atau persetujuan eksternal. Tanyakan kepada orang-orang yang akan menanggung kewajiban tersebut.
Gunakan perkiraan beserta ketidakpastiannya. Rentang dan asumsi yang memengaruhinya lebih berguna untuk keputusan daripada angka presisi yang dibuat-buat agar permintaan mudah disetujui.
Ikuti permintaan melalui enam langkah
1. Catat. Beri permintaan sebuah pengenal dan catat peminta serta tanggalnya. Gunakan satu rujukan agar diskusi terkait tidak berkembang menjadi versi yang saling bertentangan.
2. Perjelas kebutuhan. Identifikasi masalah yang hendak diselesaikan oleh permintaan. Fitur yang diminta mungkin hanya salah satu cara untuk memenuhi kebutuhan, bukan satu-satunya jawaban yang dapat diterima.
3. Nilai opsi. Bandingkan tanggapan terkecil yang layak, permintaan penuh, dan tidak melakukan apa pun untuk saat ini. Sertakan dampak pada komitmen lain dan pekerjaan yang perlu digeser.
4. Dapatkan keputusan. Kirim rekomendasi kepada orang atau kelompok yang berwenang atas dampaknya. Catat persetujuan, penolakan, atau penundaan, beserta ketentuan dan alasannya.
5. Perbarui kesepakatan terdampak. Untuk perubahan yang disetujui, perbarui cakupan, jadwal, penerimaan, rencana operasional, dan komunikasi sesuai kebutuhan. Pertahankan versi sebelumnya dan riwayat keputusan.
6. Verifikasi hasilnya. Pastikan perubahan yang diotorisasi telah diterapkan dan diterima serta kewajiban turunannya memiliki pemilik. Persetujuan bukan bukti bahwa pekerjaan selesai.
Upaya administratif harus sebanding dengan dampaknya. Pilihan berisiko rendah mungkin hanya memerlukan keputusan tercatat dari pemilik berwenang. Perubahan komitmen material mungkin membutuhkan tinjauan formal dan bukti pendukung.
Contoh lengkap: permintaan laporan yang mendesak
Dalam skenario hipotetis ini, tim sedang menyiapkan peluncuran pelaporan internal. Seorang pemangku kepentingan meminta ekspor baru seminggu sebelum penerimaan operasional. Peminta menyebutnya “hanya satu tombol lagi.”
Tim memperjelas kebutuhannya: tim keuangan memerlukan berkas rekonsiliasi mingguan. Cakupan saat ini meliputi analisis di layar, bukan ekspor yang didukung. Permintaan penuh akan membutuhkan definisi kolom, aturan akses, kasus uji, dan pemilik untuk perubahan format.
Tiga opsi muncul. Bangun ekspor permanen dan mundurkan peluncuran; sediakan laporan sementara yang disetujui melalui jalur yang ada; atau tunda kebutuhan itu ke fase berikutnya. Opsi sementara juga punya biaya: seorang analis yang ditunjuk harus menyiapkan dan memeriksanya setiap minggu sampai tanggal akhir yang ditetapkan.
Sponsor menyetujui jalur sementara selama empat minggu. Pemilik keuangan menerima formatnya, sementara manajer analis menerima kompromi kapasitas. Ekspor permanen tetap menjadi keputusan terpisah. Tanggal dan durasi ini dibuat untuk penjelasan, bukan rekomendasi pengaturan layanan.
Tim mencatat ketentuan dan tanggal peninjauan. Tanpa batas tersebut, solusi sementara dapat diam-diam berubah menjadi kewajiban dukungan tanpa batas waktu.
Tangani urgensi tanpa kehilangan akuntabilitas
Permintaan mendesak mungkin membenarkan jalur keputusan yang lebih cepat, tetapi urgensi tidak menghapus konsekuensi. Tentukan siapa yang dapat mengotorisasi tindakan darurat, pemeriksaan mana yang tetap wajib, dan apa yang harus ditinjau setelahnya sesuai kebijakan yang ada.
Jangan gunakan papan retrospektif sebagai pengganti catatan persetujuan yang diwajibkan. Diskusi dapat memperjelas dampak dan memunculkan opsi, sedangkan keputusan resmi harus berada dalam sistem proyek yang disetujui.
Jika pengambil keputusan berwenang tidak tersedia, nyatakan hambatan itu secara eksplisit. Tim tidak boleh menganggap izin diberikan hanya karena tidak ada jawaban sebelum tanggal yang diminta. Pilih alternatif yang diizinkan atau eskalasikan melalui jalur yang sudah ditetapkan.
Penundaan juga membutuhkan pemicu. “Nanti” tidak memberi informasi apa pun kepada peminta. “Pertimbangkan kembali setelah tinjauan model operasional, dengan menggunakan definisi berkas yang disetujui” menjelaskan apa yang perlu terjadi berikutnya.
Belajar dari permintaan yang berulang
Satu permintaan mungkin wajar meskipun datang terlambat. Permintaan terlambat yang berulang dapat menunjukkan kurangnya keterlibatan pemangku kepentingan, kriteria penerimaan yang tidak jelas, atau proses perencanaan yang menyembunyikan ketidakpastian.
Bawa sejumlah kecil contoh ke retrospektif tim. Bandingkan kapan kebutuhan diketahui, kapan tim mendengarnya, dan kapan keputusan dibuat. Jangan menganggap peminta menyebabkan masalah hanya karena namanya tercantum di formulir.
Pilih satu perbaikan untuk diuji, misalnya meninjau kewajiban operasional bersama tim penerima sebelum berkomitmen pada peluncuran. Gunakan panduan item tindakan retrospektif untuk menetapkan pemilik, bukti, dan tanggal peninjauan.
Ukuran proses perubahan yang baik bukanlah jumlah permintaan yang ditolaknya. Ukurannya adalah apakah perubahan yang penting mendapat keputusan jelas cukup dini untuk ditindaklanjuti.
Pertanyaan yang sering diajukan
Apakah setiap tugas baru memerlukan permintaan perubahan cakupan?
Tidak. Tugas baru dapat berupa detail implementasi di dalam cakupan yang ada. Bandingkan permintaan dengan hasil yang disepakati, kriteria penerimaan, dan hak keputusan. Gunakan kendali perubahan formal saat baseline terkait atau toleransi yang diotorisasi terdampak.
Siapa yang harus menyetujui perubahan cakupan?
Orang atau kelompok yang berwenang atas dampak terkait. Pimpinan delivery mungkin dapat mengubah implementasi, sedangkan sponsor perlu mengotorisasi perubahan komitmen. Ikuti tata kelola proyek, jangan menganggap peminta berwenang menyetujui.
Bagaimana mencegah perubahan kecil menjadi pekerjaan dukungan permanen?
Sebelum persetujuan, catat pemilik operasional, kapasitas, penerimaan, dan tanggal kedaluwarsa atau peninjauan. Verifikasi kewajiban tersebut setelah implementasi. Solusi sementara membutuhkan kondisi akhir yang eksplisit agar tidak berubah menjadi layanan berkelanjutan yang tak direncanakan.