Matriks analisis pemangku kepentingan adalah tabel atau grid terstruktur untuk memeriksa hubungan orang dengan proyek dan menentukan cara melibatkan mereka. Dimensi umum mencakup pengaruh dan kepentingan. Tambahkan dampak, bukti, dan tindakan pelibatan yang konkret agar matriks tidak mereduksi orang menjadi label kuadran.
Gunakan matriks setelah mengidentifikasi pemangku kepentingan yang relevan. Matriks membantu memprioritaskan perhatian, bukan memutuskan kepentingan siapa yang boleh diabaikan. Orang dengan pengaruh formal terbatas tetap dapat mengalami konsekuensi besar dari pilihan proyek.
Panduan pelibatan pemangku kepentingan APM membahas pengaruh, kepentingan, dan perspektif pemangku kepentingan sebagai masukan untuk pelibatan proyek. Tabel tambahan di bawah adalah adaptasi praktis, bukan standar penilaian resmi.
Matriks analisis pemangku kepentingan siap salin
| Pemangku kepentingan | Kepentingan terdampak | Pengaruh atas keputusan ini | Dampak perubahan | Bukti dan ketidakpastian | Tindakan pelibatan berikutnya | Pemilik dan waktu |
|---|---|---|---|---|---|---|
| Peran atau kelompok | Hal yang penting bagi mereka | Hal yang dapat mereka sahkan atau ubah | Hal yang mungkin mereka peroleh atau kehilangan | Hal yang diketahui dan diasumsikan | Percakapan atau tinjauan spesifik | Siapa, sebelum keputusan yang mana |
Mulailah dengan kata-kata, bukan angka. “Menyetujui anggaran operasional” lebih jelas daripada “kuasa: 5.” Jika organisasi membutuhkan model numerik, definisikan setiap skor dan simpan penjelasan dasarnya. Jumlah yang tampak presisi tidak dapat menutupi masukan yang samar.
Pisahkan kepentingan dari persetujuan. Seseorang dapat sangat peduli pada hasilnya tetapi menolak pendekatan yang diusulkan. Sebaliknya, sponsor yang mendukung bisa saja tidak punya banyak waktu untuk keterlibatan rutin. Tindakan pelibatan seharusnya mencerminkan apa yang benar-benar perlu dipelajari atau diputuskan tim.
Bagaimana grid kuasa-kepentingan membantu—dan di mana ia gagal
Grid dapat memudahkan pembahasan daftar pemangku kepentingan yang besar. Pengaruh tinggi dan kepentingan tinggi mungkin membutuhkan pelibatan erat. Pengambil keputusan dengan kepentingan lebih rendah mungkin hanya butuh informasi ringkas pada gerbang tertentu. Kelompok pengguna terdampak mungkin membutuhkan riset dan saluran umpan balik meski tidak memiliki wewenang formal.
Masalahnya muncul ketika pola ini dianggap sebagai instruksi otomatis. “Terus beri informasi” tidak cukup jika kelompok perlu menantang perubahan yang sulit dibatalkan. “Kelola dengan erat” dapat menjadi alasan untuk mengadakan rapat status berulang tanpa keputusan.
Gunakan grid untuk menanyakan hal yang lebih baik: bentuk keterlibatan apa yang tepat untuk keputusan dan dampak ini? Jawabannya bisa berupa uji prototipe, tinjauan risiko, permintaan persetujuan, atau penelusuran singkat proses operasional.
Bangun matriks dalam enam langkah
- Sebutkan keputusannya. Analisis pemangku kepentingan terkait pilihan nyata atau tahap proyek.
- Daftar kepentingan terdampak. Jelaskan hal yang ingin dilindungi atau dicapai tiap kelompok.
- Identifikasi pengaruh nyata. Sertakan wewenang formal, pengetahuan spesialis, kendali operasional, dan dependensi terkait.
- Nilai dampak. Pertimbangkan beban kerja, akses, mutu layanan, biaya, dan efek khusus konteks lainnya.
- Beri label pada asumsi. Catat entri yang berasal dari percakapan langsung dan yang masih berupa dugaan.
- Tulis tindakan pelibatan. Tetapkan pemilik dan kaitkan waktunya dengan keputusan.
Validasi matriks bersama orang di luar tim inti proyek. Mereka mungkin menemukan kepentingan yang terlewat, mengoreksi hak keputusan yang diasumsikan, atau menjelaskan alasan kanal komunikasi yang diusulkan tidak akan menjangkau kelompok tersebut.
Contoh lengkap: mengganti proses pelaporan
Contoh hipotetis: tim berencana mengganti laporan manual mingguan dengan tampilan laporan bersama. Grid kuasa-kepentingan pertamanya menempatkan sponsor eksekutif di bagian atas dan pengguna laporan di kuadran dengan pengaruh lebih rendah.
Matriks yang lebih lengkap mengubah rencana pelibatan:
| Kelompok | Temuan penting | Keputusan pelibatan |
|---|---|---|
| Sponsor | Membutuhkan satu ukuran yang dapat dibandingkan antardepartemen | Sepakati definisi sebelum menyetujui tampilan |
| Analis departemen | Mencocokkan pengecualian yang disembunyikan laporan saat ini | Telusuri kasus pengecualian sebelum mengubah logika data |
| Pembaca sesekali | Bergantung pada ringkasan email dan mungkin tidak membuka dasbor | Uji cara mereka menemukan perubahan penting |
| Pemilik operasional | Mendukung akses dan kegagalan data | Pastikan kepemilikan dan eskalasi sebelum peluncuran |
Tim tidak menjadwalkan empat rapat pembaruan yang identik. Setiap kelompok diminta berkontribusi pada keputusan yang paling dipahaminya. Matriks juga menunjukkan konflik: pembaruan otomatis meningkatkan ketepatan waktu tetapi dapat mengubah perbandingan historis. Isu ini membutuhkan keputusan produk dan tata kelola yang jelas, bukan sekadar rencana komunikasi.
Buat tindakan pelibatan menjadi spesifik
Ganti “berkomunikasi secara rutin” dengan “minta dua analis meninjau cara perhitungan yang diusulkan menangani koreksi sebelum definisi data disetujui.” Versi kedua menunjukkan tujuan, audiens, materi, dan tenggat.
Untuk persetujuan, sertakan keputusan yang diminta, opsi, konsekuensi keterlambatan, dan bukti yang tersedia. Jangan mengartikan diam sebagai setuju kecuali organisasi memiliki aturan eksplisit dan tepat untuk keputusan tersebut.
Untuk konsultasi, jelaskan apa yang masih dapat berubah. Meminta umpan balik setelah semua pilihan penting ditetapkan berarti ada partisipasi tanpa pengaruh. Jika suatu batasan tidak bisa dinegosiasikan, sampaikan dan minta masukan untuk pilihan lainnya.
Untuk kelompok terdampak, pertimbangkan akses dan format. Undangan rapat mungkin tidak menjangkau pekerja sif atau orang di luar organisasi. Pilih metode yang memungkinkan perspektif relevan didengar.
Tangani perbedaan pendapat tanpa memberi label kepada orang
Catat kepentingan dan kekhawatiran dengan bahasa netral. “Perlu bukti bahwa proses baru menangani pengecualian” berguna. “Menolak perubahan” adalah penilaian yang dapat menyembunyikan risiko operasional yang sah.
Saat kepentingan bertentangan, catat kompromi, pengambil keputusan, dan cara keputusan akan dijelaskan. Tujuannya bukan membuat setiap pemangku kepentingan mendukung setiap pilihan. Tujuannya agar proyek memahami konsekuensi dan bertanggung jawab atas keputusannya.
Simpan penilaian hubungan yang sensitif dalam catatan dengan pembatasan akses yang sesuai. Jangan menerbitkan dugaan tentang motif pribadi di papan bersama. Matriks seharusnya hanya memuat informasi yang diperlukan untuk pekerjaan pelibatan.
Tinjau matriks saat kondisi berubah
Pengaruh atau kebutuhan pelibatan pemangku kepentingan dapat berubah antara discovery, implementasi, dan operasi. Tinjau kembali entri ketika cakupan berubah, keputusan berpindah ke pemilik lain, atau bukti baru menantang analisis.
Dalam retrospektif agile, tanyakan asumsi pelibatan mana yang gagal dan bagaimana tim dapat memvalidasinya lebih awal. Gunakan papan retrospektif sederhana untuk mencatat pengamatan spesifik alih-alih membahas kepribadian.
Tindak lanjuti satu perubahan, misalnya menambahkan pemilik keputusan pada permintaan persetujuan. Panduan peningkatan retrospektif dapat membantu tim memeriksa apakah praktik itu membuat keputusan lebih jelas.
Pertanyaan yang sering diajukan
Apa perbedaan register pemangku kepentingan dan matriks?
Register mencatat informasi pemangku kepentingan. Matriks menyusun analisis dan pilihan pelibatan. Keduanya dapat berada dalam tabel yang sama jika data kontak, asumsi, dan keputusan tetap dibedakan dengan jelas.
Apakah kami membutuhkan skor numerik untuk pemangku kepentingan?
Belum tentu. Deskripsi dalam bahasa biasa sering mendukung keputusan yang lebih baik. Jika skor diwajibkan, definisikan, cantumkan bukti, dan jangan perlakukan jumlahnya sebagai fakta objektif tentang seseorang.
Apa yang harus dilakukan terhadap pemangku kepentingan dengan kuasa rendah dan dampak tinggi?
Berikan cara yang sesuai untuk berkontribusi dan menantang asumsi. Kuasa formal yang rendah tidak menghapus tanggung jawab proyek untuk memahami dan mempertimbangkan paparan mereka terhadap perubahan.