Sekarang Senin pagi. Anda telah menghabiskan sebagian besar hari Jumat untuk menarik pembaruan status dari lima manajer proyek yang berbeda, merekonsiliasi tanggal pencapaian di tiga spreadsheet, dan membujuk laporan Power BI menjadi sesuatu yang tidak akan mempermalukan Anda di depan komite eksekutif. Dasbornya terlihat baik-baik saja. Bahkan mungkin bagus. Namun - pertanyaan pertama dalam rapat tersebut adalah: "Bisakah kita mempercayai angka-angka ini?"
Pertanyaan itu adalah mode kegagalan yang sering terjadi pada sebagian besar pengaturan pelaporan portofolio proyek. Bukan kesalahan teknis. Bukan data yang hilang. Hanya erosi kepercayaan secara perlahan yang membuat laporan Anda menjadi titik awal perdebatan, bukan sebagai dasar pengambilan keputusan.
Jika itu terdengar akrab, masalahnya hampir pasti bukan Power BI. Melainkan bagaimana pelaporan portofolio disusun - dan mengapa perbaikan yang biasa dilakukan terus memperburuk keadaan.
Mengapa Pelaporan Portofolio Proyek Rusak di Power BI
Ada serangkaian kondisi tertentu yang mengubah dasbor portofolio Power BI menjadi sesuatu yang menghasilkan lebih banyak pertanyaan daripada jawabannya. Tak satu pun dari mereka yang terlihat jelas dari luar, yang merupakan bagian dari alasan mengapa mereka begitu gigih.
1. Model data dibuat untuk proyek tunggal, bukan portofolio. Sebagian besar implementasi Power BI di lingkungan proyek dimulai dengan satu data proyek - jadwal, anggaran, sumber daya - dan kemudian diperluas untuk mencakup portofolio dengan menumpuk lebih banyak data yang sama. Hasilnya adalah laporan yang dapat menunjukkan status proyek individual dengan cukup baik, tetapi runtuh ketika Anda mencoba menjawab pertanyaan tingkat portofolio: Program mana yang berisiko tidak memenuhi komitmen Q3? Di mana anggaran yang membengkak mengelompok di seluruh portofolio? Model yang mendasarinya tidak pernah dirancang untuk menjawab pertanyaan-pertanyaan tersebut, dan tidak ada tindakan baru yang akan memperbaiki ketidaksesuaian struktural.
2. Data status masuk secara tidak konsisten, dan tidak ada yang memiliki masalah kualitas. Pelaporan portofolio bergantung pada manajer proyek yang mengirimkan pembaruan status secara tepat waktu dan jujur. Dalam praktiknya, beberapa mengirimkan lebih awal, beberapa mengirimkan terlambat, beberapa mengirimkan angka yang optimis untuk menghindari eskalasi. Power BI dengan patuh melaporkan apa pun yang diterimanya. PMO akhirnya bertanggung jawab atas laporan yang tidak sepenuhnya mereka kendalikan - dan pimpinan akhirnya skeptis terhadap angka yang mungkin atau mungkin tidak mencerminkan kenyataan. Ini bukan masalah orang. Ini adalah masalah proses dan tata kelola yang diwarisi oleh lapisan pelaporan.
3. Laporan ini mencoba melayani terlalu banyak audiens sekaligus. Manajer proyek operasional membutuhkan detail tingkat tugas. Manajer program membutuhkan pelacakan tonggak pencapaian. Komite pengarah membutuhkan status RAG tingkat portofolio dan eksposur keuangan. Ketika satu laporan Power BI mencoba melakukan semua ini - biasanya melalui serangkaian halaman dan filter yang luas - akhirnya tidak ada yang melakukannya dengan baik. Pengguna eksekutif berhenti melihatnya karena menemukan apa yang mereka butuhkan membutuhkan waktu terlalu lama. Manajer proyek mengabaikannya karena detailnya tidak sesuai dengan pekerjaan mereka. Dan PMO dibiarkan mengelola laporan yang tidak ada yang sepenuhnya puas.
Apa yang Pertama Kali Dicoba oleh Kebanyakan PMO - dan Mengapa Tidak Berhasil
Naluri ketika dasbor portofolio tidak berfungsi adalah menambahkan lebih banyak lagi. Lebih banyak filter. Lebih banyak penelusuran. Kolom status dengan kode warna yang mengalir melalui tiga tingkat hierarki. Pemformatan bersyarat yang menyoroti semuanya dengan warna merah sampai tidak ada yang menonjol. Saya pernah melihat laporan dengan tujuh belas halaman yang dinavigasi oleh para eksekutif dengan meminta PMO untuk membagikan layar mereka dan mengkliknya.
Langkah umum lainnya adalah membangun kembali pipa data. Struktur SharePoint baru. Transformasi Power Query baru. Terkadang gudang data yang tepat. Ini kadang-kadang merupakan langkah yang tepat - tetapi ini adalah proyek berbulan-bulan yang tidak membahas mengapa laporan yang ada tidak dipercaya. Anda dapat memiliki data yang sangat bersih yang memberi makan laporan yang masih gagal mendorong keputusan.
Ada juga pola yang layak disebut: mengganti Power BI dengan alat PPM khusus, hanya untuk berakhir dengan masalah pelaporan yang sama di antarmuka yang baru. Alatnya berubah. Pertanyaan mendasar tentang apa yang sebenarnya perlu dilihat oleh pimpinan, dan bagaimana data mengalir dari proyek ke portofolio - semua itu tetap tidak terselesaikan.
Sejujurnya: tidak ada solusi di sini. Masalah pelaporan portofolio selalu merupakan sebagian masalah data, sebagian masalah proses, dan sebagian lagi masalah desain. Siapa pun yang mengatakan sebaliknya adalah terlalu menyederhanakan. Tetapi lapisan desain biasanya yang paling cepat diperbaiki, dan hampir selalu ditangani terakhir.
Apa yang Sebenarnya Membantu: Desain untuk Keputusan, Bukan Data
Kerangka kerja yang lebih berguna adalah memulai dari pertanyaan-pertanyaan yang sebenarnya dari komite pengarah - tiga atau empat hal yang mereka perlukan untuk keluar dari rapat setelah memutuskannya - dan mendesain mundur dari sana. Bukan "data apa yang kita miliki" tetapi "apa yang perlu dilihat oleh pemilik portofolio untuk mengambil keputusan untuk melanjutkan atau tidak melanjutkan program yang tertunda?"
Dalam praktiknya, hal ini biasanya berarti pemisahan yang tegas antara pandangan eksekutif dan pandangan operasional. Lapisan pengarah membutuhkan agregasi tingkat portofolio: kesehatan jadwal secara keseluruhan, paparan anggaran berdasarkan program, sinyal yang jelas tentang proyek mana yang menjadi kandidat eskalasi. Ini harus dapat dibaca dalam waktu kurang dari dua menit tanpa mengklik apa pun. Lapisan operasional - yang digunakan oleh manajer proyek dan pimpinan program - dapat memberikan informasi yang lebih detail. Ini adalah dua audiens yang berbeda dengan kebutuhan yang berbeda, dan mencoba untuk melayani keduanya dalam satu laporan adalah di mana sebagian besar dasbor portofolio Power BI mengalami kesalahan.
Pilihan visualisasi lebih penting daripada yang disadari oleh sebagian besar PMO. Status lampu lalu lintas yang tidak menunjukkan tren - apakah sebuah proyek baru saja berubah menjadi kuning atau sudah kuning selama enam minggu - kurang berguna daripada yang terlihat. Ikhtisar pencapaian gaya Gantt yang menunjukkan deviasi jadwal di seluruh portofolio mengkomunikasikan sesuatu yang tidak dapat dikomunikasikan oleh tabel tanggal. Pilihan visual bukanlah dekorasi; ini adalah perbedaan antara laporan yang mendorong keputusan dan laporan yang mendorong pertanyaan.
Ini adalah area di mana visual Power BI yang dibuat khusus untuk konteks manajemen proyek membuat perbedaan nyata. LeapLytics membangun visual khusus bersertifikat khusus untuk ini - hal-hal seperti Visual Gantt Chart dan indikator lampu lalu lintas yang dirancang untuk pelaporan portofolio, tidak digunakan kembali dari kasus penggunaan BI generik. Mereka tidak menyelesaikan masalah model data atau masalah tata kelola, tetapi ketika strukturnya tepat, mereka membuat output jauh lebih mudah dibaca oleh orang-orang yang paling penting.
Sebelum dan Sesudah: Apa yang Berubah Ketika Pelaporan Portofolio Benar-Benar Bekerja
Sebuah PMO infrastruktur berskala menengah - sekitar 40 proyek aktif di empat program - sampai pada titik di mana tinjauan portofolio bulanan mereka memakan waktu tiga jam dan bukannya sembilan puluh menit, sebagian besar karena setiap status yang dilaporkan memicu diskusi lanjutan tentang apakah angka-angka tersebut masih terkini. Manajer proyek mengirimkan pembaruan melalui email. PMO secara manual memperbarui file Excel master. Power BI membaca dari file tersebut. Rantai ini menyebabkan setidaknya satu minggu jeda antara kenyataan dan laporan.
Desain ulang ini memiliki tiga bagian: proses pengajuan status yang terstandardisasi dengan batas waktu tetap pada hari Jumat yang dapat dibaca langsung oleh Power BI, pemisahan yang jelas antara satu halaman eksekutif (portofolio RAG, lima risiko teratas, varians anggaran berdasarkan program) dan tampilan operasional tingkat program, dan penggantian bagan batang bertumpuk umum dengan visual garis waktu tonggak pencapaian yang tepat yang menunjukkan deviasi jadwal dalam sekejap.
Rapat pengarah berkurang dari tiga jam menjadi tujuh puluh menit. Yang lebih penting lagi, pertanyaan pembuka tidak lagi menjadi "dapatkah kita mempercayai hal ini?" dan mulai menjadi "apa yang harus kita lakukan terhadap Program B?" Pergeseran tersebut - dari memvalidasi data menjadi membuat keputusan - adalah tujuan sebenarnya. Segala sesuatu yang lain adalah infrastruktur.
Menurut Penelitian PMI tentang efektivitas PMOorganisasi dengan proses pelaporan portofolio yang matang menyelesaikan lebih banyak proyek secara signifikan tepat waktu dan sesuai anggaran. Pelaporan itu sendiri bukanlah penyebabnya - tetapi pelaporan yang buruk secara aktif menyembunyikan sinyal yang memungkinkan intervensi lebih awal.
Di mana untuk Memulai
Jika laporan portofolio Anda menghasilkan lebih banyak perdebatan rapat daripada mengarahkan keputusan, diagnostik tercepat adalah dengan bertanya: apa yang sebenarnya diputuskan oleh komite eksekutif berdasarkan laporan ini? Jika jawaban yang jujur adalah "tidak banyak," laporan tersebut tidak melakukan tugasnya - terlepas dari seberapa solid secara teknis pembangunan Power BI yang mendasarinya.
Mulailah dari sana. Tentukan tiga keputusan yang perlu dibuat oleh komite pengarah setiap bulan. Bangunlah dari belakang. Kemudian pikirkan tentang visual.
Jika Anda sudah melewati itu dan hambatannya adalah lapisan Power BI itu sendiri, maka Perpustakaan visual LeapLytics layak untuk dicoba - dibuat khusus untuk konteks pelaporan manajemen proyek, disertifikasi oleh Microsoft, dan tersedia untuk dicoba secara langsung. Mulai uji coba gratis di sini dan mengujinya dengan data portofolio Anda yang sebenarnya.
