Lessons Learned dalam Manajemen Proyek: Template dan Proses

Lessons learned adalah wawasan terdokumentasi yang ditangkap tim proyek tentang apa yang berjalan baik, apa yang tidak, dan apa yang akan mereka lakukan secara berbeda. Sebagian besar proyek mengumpulkannya. Jauh lebih sedikit yang benar-benar menggunakannya pada proyek berikutnya.

Kesenjangan antara mendokumentasikan dan menerapkan itulah tempat sebagian besar nilai organisasi bocor. Panduan ini membahas proses lengkap: kapan menangkap, apa yang ditangkap, cara menjalankan sesi, dan cara memastikan hasilnya menjangkau orang yang membutuhkannya di lain waktu.

Apa itu lessons learned?

Lessons learned adalah catatan terstruktur tentang pengetahuan yang diperoleh selama proyek. Catatannya mencakup temuan positif (praktik yang berhasil dan harus diulangi) dan temuan negatif (masalah yang terjadi dan harus dicegah). Tujuannya bukan untuk menetapkan kesalahan. Tujuannya adalah memberi tim proyek masa depan keunggulan dari awal.

Catatan lessons learned yang lengkap menangkap bukan hanya apa yang terjadi, tetapi mengapa itu terjadi dan apa yang harus dilakukan tim secara berbeda. Kedalaman itulah yang membedakan pengetahuan institusional yang berguna dari daftar keluhan yang diajukan saat penutupan proyek dan tidak pernah dibuka lagi.

Lessons learned berbeda dari retrospektif Sprint dalam hal cakupan: retro adalah upacara singkat yang spesifik untuk Sprint; lessons learned mencakup proyek penuh dan sering menjadi masukan aset proses organisasi yang digunakan tim yang bukan bagian dari proyek asli.

Fakta Penting

• Penelitian PMI menemukan bahwa organisasi yang secara konsisten menangkap dan menerapkan lessons learned menyelesaikan lebih banyak proyek tepat waktu dan sesuai anggaran dibandingkan yang tidak, namun kurang dari setengah organisasi memiliki proses formal untuk melakukannya.
• Temuan yang banyak dikutip dari penelitian proyek IT adalah bahwa sekitar 70% proyek mengulangi kesalahan dari proyek sebelumnya karena pengetahuan yang ditangkap saat penutupan tidak pernah dikonsultasikan saat inisiasi.
• Project Management Body of Knowledge (PMBOK Guide) mengklasifikasikan register lessons learned sebagai aset proses organisasi, artinya diharapkan kembali menjadi masukan cara sebuah organisasi merencanakan dan melaksanakan pekerjaan masa depan.

Kapan menangkap lessons learned

Kesalahan paling umum adalah memperlakukan lessons learned sebagai acara akhir proyek yang hanya terjadi sekali. Pada saat Anda mencapai penutupan, banyak detail penting yang telah memudar. Tim yang efektif menangkapnya secara berkelanjutan, kemudian mengkonsolidasikan pada Milestone kunci.

Jika tim Anda menggunakan metode agile, setiap retrospektif Sprint langsung menjadi masukan register lessons learned. Anda sudah melakukan pekerjaan ini. Perbedaannya adalah apakah pengetahuan tersebut ditangkap dalam format yang bertahan melampaui memori tim saat ini.

Lihat siklus hidup proyek lengkap untuk memahami bagaimana fase-fase ini terhubung.

Apa yang ditangkap

Format entri lessons learned itu penting. Catatan samar seperti "komunikasi pemangku kepentingan sulit" hampir tidak ada nilainya bagi manajer proyek berikutnya. Entri terstruktur berbeda.

Bidang "akar penyebab" dan "rekomendasi" adalah tempat sebagian besar tim bersikap samar. Dorong kekhususan. "Lakukan latihan pemetaan pemangku kepentingan di minggu pertama menggunakan template RACI" adalah berguna. "Komunikasi yang lebih baik" tidak.

Untuk panduan tentang menyusun pelajaran terkait pemangku kepentingan, matriks RACI memberikan kerangka kerja konkret untuk masalah kejelasan peran yang sering muncul sebagai pelajaran berulang.

Cara menjalankan sesi lessons learned

Sesi terfasilitasi 60 hingga 90 menit saat penutupan proyek adalah sarana standar untuk menangkap pelajaran konsolidasi. Berikut cara menjalankannya untuk menghasilkan keluaran yang dapat ditindaklanjuti.

Langkah 1: Persiapkan sebelumnya

Kirim survei singkat dua hingga tiga hari sebelum sesi. Minta peserta datang dengan dua atau tiga contoh spesifik di setiap kategori: apa yang berjalan baik, apa yang perlu ditingkatkan, dan apa yang akan mereka lakukan berbeda dari awal. Ini mencegah kebuntuan saat rapat dan memberi anggota tim yang lebih pendiam waktu untuk merumuskan pemikiran mereka.

Ambil data relevan dari proyek: varians jadwal, varians biaya, volume log perubahan, entri RAID log, dan eskalasi apa pun. Angka-angka memberi percakapan sebuah jangkar.

Langkah 2: Kumpulkan masukan

Buka sesi dengan aturan dasar. Ini bukan tinjauan kinerja. Tujuannya adalah perbaikan proses, bukan menetapkan kesalahan. Masukan pra-sesi anonim dapat membantu jika tim memiliki dinamika yang sensitif.

Gunakan struktur sederhana untuk mengumpulkan masukan: "Apa yang harus kita mulai lakukan, hentikan, dan pertahankan?" Atau adaptasi format retro: "Apa yang berjalan baik / apa yang tidak / apa yang kita lakukan selanjutnya?" Keduanya berhasil. Konten spesifik lebih penting dari formatnya.

Langkah 3: Fasilitasi diskusi

Kelompokkan masukan serupa bersama untuk menghindari diskusi yang berulang. Untuk setiap tema yang dikelompokkan, dorong untuk menemukan akar penyebab. "Ruang lingkup terus berubah" adalah titik awal, bukan pelajaran. Gali lebih dalam mengapa: Apakah rencana komunikasi tidak jelas tentang siapa yang memiliki otoritas perubahan? Apakah pertemuan kickoff proyek tidak memiliki perjanjian pembekuan ruang lingkup?

Alokasikan lebih banyak waktu untuk item yang dinilai tim sebagai berdampak tinggi. Tidak semua pelajaran berhak mendapat waktu yang sama.

Langkah 4: Dokumentasikan secara real-time

Tugaskan pencatat yang menangkap entri terstruktur selama sesi, bukan sesudahnya. Menunggu hingga nanti memperkenalkan kesenjangan dan kecenderungan alami untuk memperlunak bahasa. Setiap entri harus memiliki: kategori, apa yang terjadi, dampak, akar penyebab, dan rekomendasi.

Targetkan 10 hingga 20 entri substantif dari proyek penuh. Lebih dari 30 menunjukkan Anda menangkap kebisingan bersama dengan sinyal.

Langkah 5: Bagikan dan terapkan

Dokumen lessons learned yang tersimpan di drive jaringan yang tidak dikunjungi siapa pun bukanlah aset organisasi. Itu adalah kuitansi rasa bersalah.

Buat pelajaran mudah ditemukan. Tandai dengan metadata yang dapat dicari (jenis proyek, industri, metodologi, dan fase). Jika organisasi Anda menggunakan alat manajemen proyek atau basis pengetahuan, tautkan register dari daftar periksa penutupan proyek sehingga manajer proyek berikutnya menemukannya saat perencanaan.

Lebih baik lagi, tugaskan pemilik untuk meninjau pelajaran yang ada saat inisiasi proyek dan mengambil lima entri paling relevan ke dalam register risiko proyek baru.

Template lessons learned

Gunakan struktur ini sebagai titik awal. Sesuaikan daftar kategori agar sesuai dengan mode kegagalan umum organisasi Anda.

Simpan ini sebagai spreadsheet bersama, halaman di wiki proyek Anda, atau bagian khusus di platform manajemen proyek Anda. Formatnya tidak terlalu penting dibandingkan disiplin menggunakannya.

Contoh lessons learned

Berikut tiga entri lengkap yang diambil dari pola proyek umum:

Setiap entri ini cukup spesifik sehingga manajer proyek pada proyek serupa di masa depan dapat segera menindaklanjutinya.

Praktik terbaik

Buatlah tanpa menyalahkan. Begitu sesi lessons learned dikaitkan dengan akuntabilitas atas kegagalan, orang berhenti berkontribusi dengan jujur. Bingkai setiap sesi di sekitar proses dan sistem, bukan individu. Jika seseorang membuat kesalahan, pertanyaan sistemnya adalah: proses apa yang seharusnya menangkap atau mencegahnya?

Buatlah mudah ditemukan. Pelajaran yang tersimpan dalam folder proyek yang diarsipkan pada hari pertama penutupan tidak berguna. Tandai entri dengan metadata yang dapat dicari (jenis proyek, teknologi, departemen, metodologi). Tujuannya adalah agar manajer proyek yang memulai proyek serupa menemukan lima pelajaran paling relevan dalam lima menit.

Benar-benar gunakan kembali. Disiplin yang memisahkan organisasi proyek berkinerja tinggi dari yang lainnya sederhana: tinjau pelajaran yang ada saat inisiasi, bukan penutupan. Bangun langkah tinjauan ke dalam piagam proyek atau daftar periksa kickoff Anda. Ambil tiga hingga lima pelajaran relevan dan dokumentasikan dalam fase perencanaan sebagai risiko yang diketahui atau komitmen proses.

Kesalahan umum

Diarsipkan dan dilupakan. Mode kegagalan paling umum: dokumen lessons learned dibuat saat penutupan, disimpan di suatu tempat yang wajar, dan tidak pernah dirujuk lagi. Tim berikutnya menemukan kembali roda yang sama. Solusinya bersifat struktural: bangun tinjauan pelajaran ke dalam startup proyek sebagai langkah yang diperlukan, bukan opsional.

Hanya menangkap hal negatif. Tim cenderung fokus pada apa yang salah. Tetapi pelajaran positif sama berharganya. Jika teknik estimasi, hubungan vendor, atau kadena komunikasi tertentu bekerja dengan luar biasa baik, dokumentasikan agar tim berikutnya dapat mereplikasinya secara sengaja.

Menunggu hingga penutupan. Pada akhir proyek, orang telah secara mental beralih. Detail memudar. Tim mungkin tidak berada di ruangan yang sama lagi. Menangkap pelajaran di gerbang fase dan setelah peristiwa signifikan mempertahankan akurasi. Log yang terus diperbarui sepanjang proyek membutuhkan lima menit per entri dan menghasilkan keluaran yang jauh lebih kaya daripada sesi satu jam enam bulan kemudian.

Bahasa yang umum. "Komunikasi bisa lebih baik" tidak membantu siapa pun. Setiap entri harus cukup spesifik sehingga seseorang yang tidak ada dalam proyek dapat memahami apa yang terjadi, mengapa, dan apa yang harus dilakukan secara berbeda.

Pertanyaan yang sering diajukan

Apa perbedaan antara lessons learned dan retrospektif Sprint? Retrospektif Sprint adalah upacara agile yang diadakan di akhir setiap Sprint, biasanya 30 hingga 90 menit, berfokus pada bagaimana tim bekerja sama selama iterasi spesifik tersebut. Lessons learned adalah praktik manajemen proyek yang lebih luas yang mencakup siklus hidup proyek penuh dan sering menjadi masukan basis pengetahuan organisasi yang digunakan tim masa depan. Dalam praktiknya, retro Sprint adalah masukan yang baik untuk register lessons learned, tetapi bukan pengganti sesi konsolidasi akhir proyek.

Siapa yang memiliki lessons learned dalam proyek? Manajer proyek biasanya memiliki prosesnya: menjadwalkan sesi, memastikan dokumentasi terjadi, dan mengarahkan register akhir ke tempat organisasi menyimpan pengetahuan proyek. Tetapi kepemilikan entri individual harus didistribusikan. Setiap lead tim atau pemilik fungsional harus bertanggung jawab atas entri di domain mereka. Satu orang yang mencoba mendokumentasikan segalanya untuk proyek besar akan menghasilkan catatan yang tidak lengkap dan berkualitas rendah.

Kapan sesi lessons learned harus diadakan? Minimal sekali saat penutupan proyek. Untuk proyek yang lebih panjang, jalankan sesi singkat di setiap gerbang fase atau Milestone utama. Tim agile harus memperlakukan setiap retrospektif Sprint sebagai sesi lessons learned mini dan mengkonsolidasikan temuan kunci di akhir rilis atau proyek.

Apakah lessons learned berlaku untuk proyek agile? Ya. Upacara retrospektif Sprint adalah padanan agile dari sesi lessons learned. Perbedaannya adalah kadena dan formalitas. Tim agile menjalankan retro setiap Sprint; proyek tradisional menjalankannya di gerbang fase dan penutupan. Untuk organisasi yang menjalankan proyek agile dan waterfall, repositori lessons learned bersama yang menerima masukan dari kedua format adalah pendekatan yang paling efisien.

Berapa panjang dokumen lessons learned? Cukup panjang untuk berguna, cukup singkat untuk dibaca. Proyek khas menghasilkan 10 hingga 25 entri. Program yang sangat besar dan kompleks mungkin menghasilkan 50. Hindari pengisian. Setiap entri harus memenuhi satu uji coba: apakah manajer proyek pada proyek masa depan yang serupa menemukan ini cukup spesifik untuk ditindaklanjuti?

---

Lessons learned hanya menciptakan nilai ketika mereka menyelesaikan siklus: ditangkap, disimpan di tempat yang mudah ditemukan, dan ditinjau ketika proyek serupa baru dimulai. Sesi dan template adalah bagian yang mudah. Membangun kebiasaan memulai proyek baru dengan tinjauan pelajaran masa lalu adalah bagian yang sulit, dan satu-satunya yang benar-benar mengubah hasil.

Untuk pandangan lebih luas tentang bagaimana lessons learned cocok dalam struktur manajemen proyek formal, project management office (PMO) biasanya memiliki perpustakaan aset proses organisasi tempat register ini disimpan.