Rencana proyek menjelaskan hasil yang hendak dicapai, cara pekerjaan akan diatur, dan cara tim menangani keputusan serta perubahan. Template rencana proyek yang berguna mencakup hasil, ruang lingkup, penerimaan, kepemilikan, ketergantungan, sumber daya, risiko, tonggak, dan aturan peninjauan. Jadwal hanyalah salah satu bagian dari rencana, bukan keseluruhan dokumen.
Perbedaan ini penting ketika proyek melenceng dari rencana. Linimasa dapat menunjukkan tenggat yang terlewat, tetapi tidak menjelaskan apakah tim salah memahami hasil kerja, tidak memiliki wewenang, atau menerima pekerjaan baru tanpa menyesuaikan kapasitas. Rencana harus membantu menjawab pertanyaan tersebut.
Artikel PMI tentang unsur rencana proyek menyebut ruang lingkup, sumber daya, tonggak, persetujuan, dan manajemen perubahan sebagai beberapa komponennya. Template di sini adalah versi ringan orisinal untuk tim kolaboratif, bukan formulir resmi PMI.
Mulai dari keputusan yang dilayani proyek
Tuliskan hasil dengan istilah yang dapat dipahami orang di luar tim pelaksana. “Luncurkan dasbor” menyebutkan keluaran. “Bantu pimpinan dukungan menemukan eskalasi yang belum memiliki penanggung jawab sebelum tinjauan mingguan” menjelaskan alasan keluaran itu penting.
Selanjutnya, sebutkan sponsor atau pengambil keputusan yang bertanggung jawab serta orang-orang yang akan menggunakan hasilnya. Di organisasi kecil, peran ini mungkin dipegang orang yang sama, tetapi keputusan mereka berbeda. Seseorang harus memutuskan apakah proyek masih layak dilakukan; seseorang perlu memastikan hasil yang diserahkan memenuhi kebutuhan yang disepakati.
Catat batasan secara terpisah dari preferensi. Tenggat kontrak yang sungguhan perlu ditangani berbeda dari tanggal demonstrasi yang diinginkan. Jika tanggal dapat dinegosiasikan, katakan demikian. Jika anggaran dibatasi, tuliskan batasnya dan siapa yang berwenang mengubahnya. Gunakan referensi ke catatan keuangan sensitif daripada menyalin rincian rahasia ke papan kolaborasi publik.
Salin template rencana proyek ini
| Bagian | Pertanyaan panduan |
|---|---|
| Hasil | Perubahan bermanfaat apa yang seharusnya dihasilkan proyek? |
| Ruang lingkup | Keluaran dan pekerjaan apa yang disertakan? |
| Pengecualian | Permintaan masuk akal apa yang sengaja tidak termasuk dalam proyek ini? |
| Penerimaan | Bukti apa dan keputusan siapa yang menetapkan bahwa pekerjaan selesai? |
| Peran | Siapa yang bertanggung jawab atas pelaksanaan, penerimaan, keputusan teknis, dan eskalasi? |
| Pendekatan kerja | Tahap atau iterasi apa yang akan digunakan tim? |
| Ketergantungan | Apa yang harus tersedia, dari siapa, dan kapan? |
| Kapasitas | Peran mana yang tersedia dan komitmen lain apa yang masih berjalan? |
| Tonggak | Kondisi penting apa yang menandakan kemajuan? |
| Risiko dan asumsi | Apa yang dapat membuat rencana tidak berlaku, dan respons apa yang disiapkan? |
| Keputusan perubahan | Siapa yang dapat menerima perubahan ruang lingkup, biaya, atau waktu? |
| Tinjauan | Kapan dan bagaimana rencana akan diperiksa dan diperbarui? |
Jangan mengisi setiap kolom dengan satu paragraf hanya agar dokumen terlihat lengkap. Keputusan yang belum dibuat lebih berguna jika diberi label “belum terselesaikan, pemilik, tanggal keputusan” daripada disembunyikan dengan kalimat umum. Tautkan ke jadwal terperinci dan pelacak pekerjaan alih-alih memelihara beberapa salinan yang saling bersaing.
Contoh lengkap: laporan eskalasi dukungan
Bayangkan sebuah tim hipotetis yang merencanakan laporan eskalasi mingguan. Hasil yang disepakati adalah agar pimpinan dukungan dapat menemukan kasus tanpa penanggung jawab. Keluaran proyeknya adalah laporan yang dibuat dari data tiket yang sudah ada, dengan definisi “tanpa pemilik” yang terdokumentasi. Analisis perkiraan dan penagihan secara eksplisit tidak termasuk.
Penerimaan mengharuskan pimpinan dukungan membandingkan sampel yang ditentukan dengan tiket sumber, menjelaskan perbedaan, dan mengonfirmasi bahwa laporan tersebut mendukung tinjauan mingguan. Tim teknik bertanggung jawab atas implementasi. Tim dukungan memiliki definisi operasional. Sponsor yang disebutkan akan memutuskan permintaan yang memperluas sumber data atau tujuan pelaporan.
Tim menemukan dua ketergantungan: akses ke ekspor tiket dan kesepakatan tentang kepemilikan ketika tiket berpindah antarbagian. Ketergantungan kedua bukan tugas teknis. Pengodean dapat dimulai sebelum keputusan dibuat, tetapi tanggal penerimaan yang dapat dipercaya tidak boleh berasumsi bahwa ambiguitas akan hilang sendiri.
Urutan tonggaknya menjadi: definisi disepakati; sampel dicocokkan; tinjauan operasional pertama selesai; kepemilikan beralih ke tim pemelihara. Tonggak ini lebih informatif daripada “analisis 50% selesai” karena menjelaskan kondisi yang dapat diamati.
Semua rincian dalam contoh ini bersifat ilustratif. Ini bukan studi kasus pelanggan Nextretro dan bukan klaim bahwa satu format perencanaan menjamin keberhasilan pelaksanaan.
Susun jadwal berdasarkan pekerjaan dan ketergantungan
Setelah ruang lingkup dan syarat penerimaan dapat dipahami, mintalah orang yang mengerjakan tugas untuk mengidentifikasi aktivitas dan ketergantungan. Bedakan lama kontribusi dari waktu yang berlalu. Tugas analisis satu hari mungkin harus menunggu beberapa hari untuk ditinjau.
Tandai estimasi sebagai perkiraan. Jika ketidakpastian berdampak besar, gunakan rentang dan sebutkan asumsi di baliknya. “Siap setelah persetujuan akses data, lalu sekitar satu hingga dua minggu untuk implementasi dan pencocokan” lebih jujur daripada tanggal presisi yang diam-diam mengasumsikan persetujuan datang besok.
Roadmap memiliki tujuan berbeda: menyampaikan urutan umum hasil dan ketergantungan utama. Jadwal mengoordinasikan aktivitas dan tanggal. Rencana proyek menghubungkan keduanya dengan tujuan, wewenang, dan batasan proyek. Pilih dokumen yang menjawab pertanyaan audiens daripada mengganti nama linimasa yang sama tiga kali.
Jaga agar rencana tetap hidup dengan tinjauan singkat
Dalam pemeriksaan pelaksanaan rutin, tinjau perubahan asumsi, ruang lingkup, ketergantungan, dan kapasitas. Perbarui rencana ketika keputusan mengubah komitmen. Simpan riwayat secukupnya untuk menjelaskan perbedaan versi saat ini dengan versi awal.
Gunakan papan bersama untuk memunculkan risiko dan pertanyaan selama lokakarya perencanaan. Simpan tanggal, alokasi sumber daya, dan persetujuan formal di sistem proyek yang menjadi sumber resmi. Papan retrospektif membantu orang bernalar bersama; papan itu tidak menggantikan seluruh fungsi perencanaan.
Setelah tonggak penting, adakan retrospektif agile. Tanyakan asumsi perencanaan mana yang membantu, mana yang keliru, dan apa yang perlu berubah sebelum tahap berikutnya. Pilih format dari ide retrospektif yang sesuai dengan ketidakpastian yang ingin diperiksa.
Kesalahan umum yang perlu dihapus sebelum membagikan rencana
Hapus tonggak yang hanya menjelaskan upaya internal tanpa menunjukkan hasil. Ganti “pemangku kepentingan sudah diajak konsultasi” dengan keputusan yang harus dihasilkan dari konsultasi tersebut. Hapus penanggung jawab ganda jika tidak seorang pun tahu siapa yang mengambil keputusan akhir.
Periksa pengecualian terhadap permintaan yang mungkin muncul. Jika semua pemangku kepentingan mengharapkan pelatihan, migrasi data, atau pemeliharaan, tidak menyebutkannya tidak akan membuatnya lenyap. Putuskan apakah pekerjaan tersebut termasuk dalam ruang lingkup dan bagaimana sumber dayanya disediakan.
Terakhir, baca rencana dari sudut pandang anggota tim baru. Dapatkah Anda menjelaskan alasan proyek ini ada, arti selesai, dan kepada siapa keputusan sulit harus dibawa? Jika belum, sederhanakan bahasanya sebelum menambahkan lebih banyak detail.
Pertanyaan yang sering diajukan
Apakah rencana proyek sama dengan jadwal proyek?
Tidak. Jadwal menjelaskan waktu aktivitas dan ketergantungan. Rencana juga mencakup tujuan, ruang lingkup, penerimaan, kepemilikan, sumber daya, risiko, dan keputusan perubahan. Rencana yang baik dapat menautkan jadwal terperinci tanpa menggandakannya.
Seberapa panjang seharusnya rencana proyek?
Cukup panjang untuk menjelaskan komitmen dan keputusan yang penting. Proyek internal kecil mungkin hanya membutuhkan dokumen singkat dengan tautan ke catatan terkait. Pekerjaan kompleks atau yang diatur ketat mungkin memerlukan rencana lebih terperinci dan kontrol formal.
Apakah tim agile perlu menulis rencana proyek?
Rencana dapat berguna jika proyek memiliki ketergantungan lintas tim, keputusan pendanaan, atau komitmen eksternal. Buat detail jangka dekat tetap konkret dan pertahankan kemampuan menyesuaikan pekerjaan di masa depan. Rencana seharusnya mendukung pembelajaran, bukan menyiratkan bahwa setiap tugas mendatang sudah diketahui.