Lompat ke konten
Perpustakaan Prompt

Prompt Manajemen Proyek

Penyusunan kerangka, notulensi, penjadwalan, dan manajemen risiko pour proyek yang tepat waktu. Ganti variabel dalam kurung dengan konteks bisnis Anda, lalu salin prompt atau buka langsung di chat.

  • 50 prompt Manajemen Proyek
  • Salin atau buka di chat

Menyusun Kerangka Proyek (Project Charter)

Dokumen untuk menyelaraskan semua pihak sebelum memulai: ruang lingkup, hal di luar lingkup, risiko, dan milestone.

Susun kerangka proyek (project charter) untuk proyek [nama proyek] di [nama perusahaan]. Tujuan proyek: [tujuan]. Sponsor/Pemilik Proyek: [nama]. Tim: [komposisi tim]. Anggaran: [anggaran dalam Rupiah]. Target penyelesaian: [tenggat waktu]. Latar belakang proyek: [konteks].

Struktur dokumen: konteks dan masalah yang ingin diselesaikan (maksimal 3 baris), tujuan yang terukur (KPI), ruang lingkup yang disertakan, hal-hal yang secara eksplisit DIKECUALIKAN (harus detail untuk menghindari scope creep), deliverable dengan kriteria penerimaan, milestone utama dengan tanggal, peran dan tanggung jawab (siapa yang memutuskan, mengerjakan, dikonsultasikan, dan diinformasikan), risiko yang teridentifikasi beserta mitigasinya ([risiko yang sudah terbayang]), serta asumsi dan ketergantungan.

Susun setiap bagian agar potensi ketidaksepakatan muncul SEKARANG saat peninjauan, bukan di tengah jalan. Akhiri dengan 3 pertanyaan kunci yang harus diputuskan oleh komite sebelum peluncuran.

Mengubah Catatan Rapat Menjadi Notulensi Aksi

Notulensi ringkas dengan keputusan dan daftar aksi yang jelas berdasarkan catatan kasar.

Ubah catatan kasar rapat saya menjadi notulensi terstruktur. Rapat: [topik rapat] tanggal [tanggal], peserta: [daftar peserta]. Berikut catatan kasarnya: [catatan kasar].

Format output: keputusan yang diambil (dirumuskan tanpa ambigu, sebutkan siapa pengambil keputusan), daftar aksi (tabel: aksi, penanggung jawab, tenggat waktu; jika salah satu data tidak ada di catatan saya, tulis 'PERLU DIKONFIRMASI' jangan mengarang), poin diskusi tanpa keputusan (maksimal 2 baris per poin), poin yang ditunda beserta tanggal diskusi berikutnya.

Aturan: maksimal satu halaman, jangan mengubah makna asli, hindari bahasa diplomatis yang mengaburkan keputusan (dilarang menggunakan kalimat seperti 'disepakati untuk menindaklanjuti hal tersebut'). Akhiri dengan daftar 'PERLU DIKONFIRMASI' untuk dikirim kembali ke peserta guna validasi.

Memecah Proyek dan Menyusun Jadwal

Transisi dari tujuan ke jadwal kerja: paket kerja, tugas, ketergantungan, dan jalur kritis.

Pecah proyek berikut menjadi paket kerja and susun jadwalnya. Proyek: [deskripsi proyek dan deliverable akhir]. Tenggat waktu: [tanggal]. Tim yang tersedia: [jumlah orang dan ketersediaan, misal 2 orang paruh waktu]. Kendala yang diketahui: [kendala: validasi klien, ketergantungan vendor, periode libur nasional/cuti].

Lakukan langkah berikut: bagi menjadi paket kerja yang menghasilkan deliverable terverifikasi (bukan paket 'koordinasi'), pecah setiap paket menjadi tugas berdurasi 0,5 hingga 3 hari, identifikasi ketergantungan antar tugas dan jalur kritis (critical path), berikan margin waktu eksplisit pada tugas yang tidak pasti daripada menyembunyikan margin di semua tugas.

Output: daftar terstruktur paket kerja -> tugas dengan estimasi, jadwal mingguan dengan milestone validasi, jalur kritis yang disorot, dan 3 tugas yang harus segera dimulai karena menentukan kelanjutan proyek. Beri peringatan jika tenggat waktu [tanggal] tidak masuk akal dengan tim yang ada berdasarkan data, jangan mengecilkan estimasi secara diam-diam.

Menyusun Laporan Mingguan Ringkas (Flash Report)

Laporan kemajuan satu halaman yang benar-benar dibaca pimpinan: status, fakta, dan keputusan yang dibutuhkan.

Susun laporan mingguan (flash report) proyek [nama proyek] untuk [penerima, misal Direksi/Steering Committee]. Data minggu ini: kemajuan [apa yang selesai vs rencana], hambatan [masalah yang dihadapi], perkembangan risiko [risiko], anggaran terpakai [aktual vs rencana], keputusan yang ditunggu [keputusan yang menghambat dan sejak kapan].

Format ketat satu halaman: status proyek (Hijau/Kuning/Merah) dengan SATU kalimat penjelas warna tersebut, 3 fakta utama minggu ini, kemajuan vs rencana (satu baris per paket kerja aktif), risiko dan poin hambatan (hanya yang berubah dari minggu lalu), keputusan yang ditunggu beserta nama pengambil keputusan dan dampak keterlambatannya, prioritas minggu depan.

Aturan: status tidak boleh kembali ke hijau tanpa penjelasan solusi masalah; status kuning dua minggu berturut-turut otomatis menjadi merah; keputusan yang tertunda harus mencantumkan tanggal permintaan awal.

Memandu Retrospektif Akhir Proyek

Persiapan lengkap untuk evaluasi proyek: alur, pertanyaan kunci, dan pembelajaran yang bisa diterapkan.

Siapkan panduan retrospektif untuk proyek [nama proyek] yang baru saja selesai [hasil: tepat waktu, terlambat X hari, dibatalkan]. Peserta: [peserta dan peran]. Durasi: [durasi, misal 90 menit]. Poin penting proyek: [apa yang berjalan baik/buruk, potensi ketegangan].

Output: alur waktu (pembukaan dengan aturan 'mencari penyebab, bukan kambing hitam', pengumpulan ide individual sebelum diskusi kelompok untuk menghindari bias, diskusi poin utama, keputusan), pertanyaan spesifik untuk menggali lebih dalam ('kapan tepatnya kita tahu jadwal akan meleset? apa yang menghalangi kita mengatakannya?'), dan teknik untuk membahas [topik sensitif] tanpa menjadi ajang saling menyalahkan.

Format pembelajaran: setiap poin diubah menjadi aturan aksi untuk proyek berikutnya ('mulai sekarang kita akan...'), lengkap dengan penanggung jawab implementasinya. Maksimal 5 aturan agar benar-benar diterapkan.

Menyusun Studi Kelayakan (Go/No-Go)

Dokumen keputusan terstruktur: urgensi, opsi, biaya, risiko, dan kriteria keputusan.

Anda adalah manajer proyek berpengalaman. Bantu saya menyusun studi kelayakan untuk proyek [nama proyek] di [nama perusahaan]. Masalah atau peluang awal: [konteks]. Manfaat yang diharapkan: [manfaat]. Anggaran maksimal: [jumlah dalam Rupiah]. Alternatif yang diketahui: [opsi lain, termasuk tidak melakukan apa-apa].

Strukturkan dokumen dalam 6 bagian: masalah yang diselesaikan dan biaya jika tidak bertindak (cost of inaction), opsi yang memungkinkan (termasuk status quo) dengan kelebihan dan kekurangan, estimasi kasar biaya dan waktu per opsi dalam rentang lebar, manfaat yang dikaitkan dengan indikator terukur, risiko utama tiap opsi, rekomendasi argumen.

Kendala: setiap manfaat harus terhubung dengan indikator yang bisa diverifikasi, jika tidak masukkan ke kategori 'spekulasi tak terukur'. Susun 5 kriteria keputusan go/no-go untuk dicentang komite. Akhiri dengan daftar informasi yang masih kurang dan siapa yang harus menyediakannya.

Menyusun Piagam Proyek Singkat (Express Charter)

Dokumen satu halaman untuk proyek kecil tanpa kerumitan administrasi berlebih.

Susun piagam proyek satu halaman untuk proyek kecil. Proyek: [deskripsi dalam 2 kalimat]. Pemohon: [nama]. Orang yang terlibat: [nama dan alokasi waktu]. Target selesai: [tanggal]. Anggaran: [jumlah atau tidak ada].

Format wajib maksimal satu halaman: tujuan dalam satu kalimat terukur, deliverable akhir dan indikator selesai, hal yang dikecualikan (minimal 3 baris, ini bagian terpenting), siapa pengambil keputusan akhir, milestone (maksimal 3), risiko utama dan mitigasinya.

Aturan: jangan gunakan jargon manajemen proyek, gunakan kalimat yang dipahami orang awam. Jika informasi saya kurang, tulis 'PERLU KLARIFIKASI dengan [nama]' jangan mengarang. Akhiri dengan 2 pertanyaan kunci untuk pemohon sebelum mulai.

Menyiapkan Wawancara Pengumpulan Kebutuhan

Panduan wawancara per profil untuk menggali kebutuhan riil sebelum menetapkan ruang lingkup.

Saya memulai proyek [nama proyek] di [nama perusahaan] dan perlu mengumpulkan kebutuhan (requirement gathering). Orang yang akan diwawancarai: [daftar profil, misal direksi, staf lapangan, tim IT]. Deliverable proyek: [hasil yang dibayangkan]. Durasi per wawancara: [durasi].

Siapkan panduan wawancara untuk setiap profil: 8-10 pertanyaan terbuka dari umum ke spesifik, bedakan antara pertanyaan operasional saat ini (masalah, solusi sementara, volume kerja) dan kebutuhan masa depan. Tambahkan 2 pertanyaan jebakan untuk memancing kebutuhan tersembunyi, misal: 'apa yang Anda lakukan saat sistem sekarang gagal memenuhi kebutuhan Anda?'.

Aturan: hindari pertanyaan yang mengarahkan jawaban atau pertanyaan ya/tidak. Berikan template ringkasan: kebutuhan eksplisit, kebutuhan implisit, kontradiksi antar profil, dan kutipan (verbatim) penting.

Menyusun User Stories dan Kriteria Penerimaan

Mengubah kebutuhan kasar menjadi user stories yang bisa diuji dengan kriteria validasi yang jelas.

Ubah kebutuhan kasar ini menjadi user stories untuk tim pelaksana. Proyek: [nama dan deskripsi singkat]. Pengguna: [profil pengguna]. Kebutuhan: [daftar kebutuhan].

Untuk setiap kebutuhan, buat: User Story format 'Sebagai [profil], saya ingin [aksi] agar [manfaat]', 3-5 kriteria penerimaan (acceptance criteria) format biner (bisa dijawab ya/tidak, hindari kata 'cepat' atau 'mudah' tanpa angka pasti), dan pertanyaan untuk pemohon jika kebutuhan terlalu samar.

Aturan: satu story harus bisa selesai dalam beberapa hari, jika terlalu besar pecah menjadi beberapa story. Sorot jika ada solusi yang menyamar sebagai kebutuhan dan ubah menjadi kebutuhan murni. Sajikan dalam tabel: story, kriteria penerimaan, estimasi ukuran (S/M/L), pertanyaan terbuka. Akhiri dengan daftar ketergantungan antar story.

Memprioritaskan Backlog yang Menumpuk

Klasifikasi backlog berdasarkan nilai dan usaha (effort) agar keputusan bisa dipertanggungjawabkan.

Bantu saya memprioritaskan backlog proyek [nama proyek]. Daftar permintaan: [daftar permintaan dengan deskripsi singkat]. Kapasitas tim: [misal 15 man-days per bulan]. Tujuan utama kuartal ini: [tujuan]. Konteks internal: [siapa yang paling mendesak].

Evaluasi setiap poin pada dua sumbu: Nilai (kontribusi ke tujuan kuartal, jumlah pengguna terdampak, biaya jika tidak diselesaikan) dan Estimasi Usaha (ukuran relatif). Klasifikasikan ke 4 kategori: Kerjakan Sekarang (nilai tinggi, usaha rendah), Jadwalkan (nilai tinggi, usaha tinggi), Pengisi Waktu (nilai rendah, usaha rendah), Tolak/Tunda (nilai rendah, usaha tinggi).

Aturan: tekanan dari pemohon bukan kriteria nilai, tapi buat daftar terpisah untuk penolakan yang butuh penjelasan khusus. Sajikan tabel klasifikasi dengan justifikasi singkat, lalu buatkan 3 draf pesan penolakan yang paling sensitif secara faktual dan sopan.

Menyusun Roadmap Kuartalan

Roadmap per kuartal yang berorientasi pada hasil, lengkap dengan alasan di balik setiap pilihan.

Susun roadmap untuk 2 kuartal ke depan untuk [produk/proyek] di [nama perusahaan]. Tujuan tahunan: [tujuan]. Kandidat inisiatif: [daftar rencana]. Kapasitas tim: [ukuran tim]. Komitmen yang sudah ada: [janji ke klien/internal yang tidak bisa dinegosiasi].

Organisasikan roadmap per kuartal dengan merumuskan setiap poin sebagai hasil yang diharapkan, bukan fitur (misal: 'mempercepat proses klaim' bukan 'membuat modul X'). Untuk setiap kuartal: maksimal 2-3 inisiatif, target hasil, indikator keberhasilan, ketergantungan.

Aturan: sisakan 20% kapasitas untuk hal tak terduga dan tuliskan secara eksplisit. Daftar hal yang sengaja tidak dikerjakan dan alasannya untuk menghindari pertanyaan 'kenapa X tidak ada?'. Berikan dua versi: versi detail untuk tim dan versi 5 baris untuk direksi. Sorot inisiatif yang nilainya masih terlalu kabur.

Estimasi Beban Kerja Proyek Tanpa Bias

Estimasi menggunakan rentang waktu dengan asumsi eksplisit untuk menghindari optimisme berlebihan.

Bantu saya mengestimasi beban kerja proyek [nama proyek]. Konten: [daftar paket kerja/tugas]. Tim: [profil dan pengalaman]. Data historis: [proyek serupa sebelumnya dan durasi aslinya, jika ada].

Untuk setiap paket kerja: berikan estimasi rentang (optimis, moderat, pesimis) bukan satu angka, tuliskan asumsi (apa yang harus benar agar estimasi ini valid), dan faktor yang bisa memicu skenario pesimis.

Aturan: jika ada data proyek lama, bandingkan estimasi dengan kenyataan masa lalu dan jelaskan perbedaannya. Tambahkan beban kerja yang sering terlupakan: revisi setelah testing, koordinasi, onboarding tim, dan cuti/libur. Sajikan total dalam 3 skenario dengan persentase selisih optimis-pesimis. Jika selisih lebih dari dua kali lipat, sebutkan informasi apa yang dibutuhkan untuk mengurangi ketidakpastian.

Menyusun Anggaran Proyek dan Pelacakan Bulanan

Anggaran proyek lengkap per kategori dengan sistem pelacakan pengeluaran dan peringatan dini.

Susun anggaran lengkap proyek [nama proyek] di [nama perusahaan]. Beban internal: [man-days per profil dan rate harian jika ada]. Pembelian/Vendor eksternal: [daftar]. Durasi: [durasi]. Pagu anggaran: [jumlah dalam Rupiah].

Buat anggaran per kategori: biaya internal, vendor, lisensi/alat, biaya operasional, dan dana cadangan (contingency) dengan justifikasi persentase berdasarkan tingkat risiko. Cek kesesuaian dengan pagu anggaran dan sorot potensi overbudget sejak awal.

Buat sistem pelacakan bulanan: tabel aktual vs anggaran, estimasi sisa kerja (ETC - estimate to complete, bukan cuma sisa uang), proyeksi akhir proyek (EAC), dan 2 ambang batas peringatan yang memicu laporan ke sponsor. Akhiri dengan 3 penyebab kebocoran anggaran paling umum di proyek sejenis dan cara mendeteksinya lebih awal.

Menyusun Daftar Risiko Proyek (Risk Register)

Daftar risiko yang terukur and diprioritaskan, lengkap dengan mitigasi and penanggung jawab.

Susun daftar risiko untuk proyek [nama proyek]. Konteks: [deskripsi proyek, tenggat, urgensi]. Risiko yang sudah terbayang: [risiko awal]. Ketergantungan eksternal: [vendor, tim lain, validasi regulasi].

Lengkapi daftar saya dengan risiko tipikal proyek sejenis dalam 4 kategori: Manusia (resign, overload, kurang skill), Teknis, Organisasi (keputusan lambat, scope creep), Eksternal. Untuk setiap risiko: deskripsi kejadian, probabilitas (Rendah/Sedang/Tinggi), Dampak (Rendah/Sedang/Tinggi), tingkat kritikalitas, indikator awal (early warning), tindakan pencegahan, rencana cadangan (contingency plan), dan penanggung jawab.

Aturan: rumuskan risiko sebagai kejadian spesifik (misal: 'vendor terlambat kirim barang 1 bulan'), bukan tema umum (misal: 'jadwal'). Batasi pada 10 risiko paling kritikal. Tentukan jadwal tinjauan rutin: frekuensi dan pertanyaan evaluasinya.

Memetakan Stakeholder Proyek

Pemetaan pengaruh and dukungan stakeholder, lengkap dengan rencana pendekatan personal.

Petakan stakeholder proyek [nama proyek] di [nama perusahaan]. Aktor yang teridentifikasi: [daftar orang/divisi dan perannya]. Dampak proyek bagi mereka: [dampak]. Dukungan atau hambatan yang dirasakan: [konteks].

Posisi setiap aktor pada dua sumbu: Pengaruh (bisa menghambat, mempercepat, atau netral) dan Dukungan (pendukung, netral, penolak). Untuk setiap aktor berpengaruh: apa keuntungan/kerugian mereka dari proyek ini, potensi keberatan mereka, dan aksi pendekatan yang sesuai (dilibatkan dalam keputusan, laporan rutin, atau diskusi personal sebelum pengumuman).

Aturan: jangan hanya terpaku pada struktur organisasi, sorot aktor tanpa jabatan tinggi tapi punya pengaruh besar. Sajikan rencana dalam tabel: aktor, posisi saat ini, posisi yang dibutuhkan, aksi, pelaksana, tenggat. Akhiri dengan 2 aktor prioritas yang harus ditemui minggu ini.

Menyusun Rencana Komunikasi Proyek

Siapa yang perlu diinformasikan, apa isinya, seberapa sering, and melalui saluran apa.

Susun rencana komunikasi proyek [nama proyek]. Target audiens: [misal sponsor, tim, pengguna, divisi lain]. Durasi proyek: [durasi]. Momen kunci: [milestone, peluncuran, pengumuman]. Saluran yang tersedia: [misal rapat, email, WhatsApp Group, intranet].

Untuk setiap audiens, tentukan: apa yang perlu mereka ketahui (hanya itu saja), frekuensi, saluran, format (ringkasan 2 baris, laporan lengkap, atau rapat), dan siapa pengirimnya. Bedakan komunikasi rutin (update progres) dan komunikasi insidental (kick-off, go-live, insiden, penutupan).

Aturan: setiap komunikasi harus menjawab pertanyaan audiens 'apa dampaknya bagi saya?', jika tidak ada, hapus dari rencana. Siapkan draf pesan untuk kick-off dan go-live. Sajikan dalam tabel ringkas, lalu sebutkan 3 kesalahan komunikasi paling umum dan cara rencana ini menghindarinya.

Menyusun Matriks RACI Proyek

Pembagian tanggung jawab tanpa ambigu pour mendeteksi konflik peran sejak dini.

Susun matriks RACI untuk proyek [nama proyek]. Aktivitas utama: [daftar aktivitas/deliverable]. Aktor: [orang/fungsi yang terlibat]. Ketegangan atau ketidakjelasan yang ada: [konteks, misal dua orang merasa berhak memutuskan hal yang sama].

Untuk setiap aktivitas, tentukan peran: R (Responsible - yang mengerjakan), A (Accountable - pengambil keputusan akhir, hanya satu orang per baris), C (Consulted - dimintai pendapat sebelum aksi), I (Informed - diberitahu setelah aksi). Jelaskan alasan untuk penugasan yang tidak biasa.

Aturan kualitas: dilarang ada dua 'A' dalam satu baris, tidak boleh ada baris tanpa 'R', sorot jika ada aktor yang menjadi 'C' di hampir semua baris (potensi bottleneck) atau aktor tanpa peran sama sekali. Sajikan dalam tabel, lalu sebutkan 3 poin yang paling berisiko konflik dan rekomendasi solusinya.

Menyiapkan Rapat Peluncuran (Kick-off Meeting)

Alur lengkap rapat kick-off pour menyelaraskan tim and membangun komitmen peserta.

Siapkan rapat kick-off proyek [nama proyek]. Peserta: [peserta dan peran]. Durasi: [durasi, misal 60 menit]. Status persiapan: [kerangka proyek sudah valid atau masih draf]. Poin sensitif: [ketegangan, skeptisisme, sejarah proyek gagal sebelumnya].

Output: alur waktu (mengapa proyek ini penting sekarang, hasil akhir konkret, hal di luar lingkup, pembagian tugas, milestone, aturan main tim, sesi tanya jawab), 3 pesan utama yang harus diingat peserta, dan cara membahas [poin sensitif] tanpa merusak suasana namun tetap jujur.

Aturan: kick-off bukan sekadar presentasi satu arah, siapkan 2 momen interaktif (identifikasi risiko spontan, diskusi kendala masing-masing). Berikan draf undangan beserta agenda dan apa yang harus disiapkan peserta, serta daftar hal yang harus divalidasi SEBELUM kick-off agar proyek tidak dimulai dengan ketidakjelasan.

Menyiapkan Agenda and Fasilitasi Steering Committee (COPIL)

Rapat pimpinan yang fokus pada pengambilan keputusan, bukan sekadar membaca laporan progres.

Siapkan rapat Steering Committee (COPIL) berikutnya untuk proyek [nama proyek]. Peserta: [anggota COPIL]. Durasi: [durasi]. Situasi proyek: [progres, hambatan, anggaran]. Keputusan yang dibutuhkan: [daftar keputusan dengan opsinya]. Topik yang berisiko mendominasi diskusi: [topik sensitif].

Susun agenda berdasarkan keputusan yang harus diambil: setiap poin keputusan diberi alokasi waktu, opsi yang disiapkan (2-3 opsi dengan kelebihan, kekurangan, dan rekomendasi), serta dampak jika keputusan ditunda lagi. Update progres dibatasi maksimal 10 menit berdasarkan dokumen yang dikirim sebelumnya.

Output: agenda dengan alur waktu, rumusan tepat untuk setiap permintaan keputusan, teknik memotong pembicaraan yang melantur tentang [topik sensitif] secara sopan, dan template notulensi keputusan yang dikirim dalam 24 jam. Sebutkan dokumen yang harus dikirim ke peserta 48 jam sebelum rapat.

Menyusun Struktur Presentasi Steering Committee

Struktur slide presentasi pimpinan yang ringkas and padat dalam maksimal 10 slide.

Susun struktur presentasi untuk Steering Committee proyek [nama proyek]. Data bulan ini: progres [aktual vs rencana], anggaran [aktual vs budget], risiko [perkembangan], keputusan yang dibutuhkan [daftar], poin penting [kejadian bulan ini].

Buat struktur slide demi slide, maksimal 10 slide: Ringkasan Eksekutif (status, pesan utama, keputusan yang dibutuhkan), Progres per paket kerja dengan varians, Tren Anggaran, Risiko yang berubah statusnya, Fokus pada masalah utama bulan ini dengan opsi & rekomendasi, Permintaan Keputusan (satu slide per keputusan), Langkah Selanjutnya.

Aturan tiap slide: judul harus berupa pesan utama (misal: 'Paket 2 Mengejar Keterlambatan', bukan 'Progres Paket 2'), isi maksimal 5 poin, dan poin pembicaraan (talking points) yang tidak tertulis di slide. Hindari slide latar belakang yang sudah diketahui pimpinan. Akhiri dengan cek: jika pimpinan hanya baca slide 1, apakah mereka paham intinya?

Membangun Alur Manajemen Perubahan (Change Request)

Proses sederhana pour mengelola permintaan perubahan ruang lingkup tanpa merusak jadwal proyek.

Bangun alur manajemen perubahan (change request) untuk proyek [nama proyek]. Konteks: [asal permintaan, misal klien menambah fitur terus, direksi berubah pikiran]. Wadah yang ada: [rapat/komite saat ini]. Margin tersedia: [sisa waktu dan anggaran].

Tentukan: formulir permintaan minimal (deskripsi, pemohon, justifikasi, urgensi riil), 4 pertanyaan evaluasi sistematis (dampak waktu, dampak biaya, dampak ke bagian lain, konsekuensi jika tidak dikerjakan), siapa pengambil keputusan berdasarkan skala dampak (usulkan ambang batas angka), dan cara mencatatnya di Change Log.

Buat 3 draf jawaban: permintaan diterima dengan dampak yang dijelaskan, permintaan ditunda ke fase berikutnya, permintaan ditolak dengan justifikasi. Aturan: alur harus ringkas (setengah halaman) agar dipatuhi, tidak ada perubahan lisan tanpa masuk log. Akhiri dengan cara menjelaskan alur ini kepada pemohon yang paling memaksa tanpa menyinggungnya.

Negosiasi Tenggat Waktu yang Tidak Masuk Akal

Argumen berbasis data and opsi solusi saat tenggat waktu yang diminta mustahil dicapai.

Bantu saya menyiapkan negosiasi untuk tenggat waktu yang tidak masuk akal. Proyek: [nama proyek]. Tenggat yang diminta: [tanggal]. Keyakinan saya: butuh [durasi realistis] karena [alasan: beban kerja, ketergantungan, ketersediaan tim]. Sponsor: [profil sponsor dan prioritasnya]. Urgensi tanggal tersebut: [mengapa tanggal itu dipilih, jika tahu].

Susun: bukti faktual selisih waktu (beban kerja vs kapasitas, dengan angka sederhana), lalu 3 opsi jujur: kejar tanggal dengan mengurangi ruang lingkup (sebutkan fitur yang dibuang), pertahankan ruang lingkup dengan menggeser tanggal, atau tambah sumber daya dengan biaya dan risiko efektivitasnya (orang baru butuh waktu belajar).

Aturan: jangan bilang 'tidak mungkin' tanpa solusi, jangan terima kompromi tanpa hitungan di depan rapat. Siapkan jawaban untuk 3 keberatan sponsor, termasuk 'pokoknya harus selesai' dan 'coba saja dulu'. Format: satu halaman argumen plus tabel perbandingan 3 opsi.

Menyusun Rencana Pemulihan Proyek (Recovery Plan)

Diagnosis keterlambatan and rencana pemulihan yang realistis, bukan sekadar memadatkan jadwal.

Susun rencana pemulihan untuk proyek [nama proyek], yang terlambat [durasi keterlambatan] dari target [tanggal]. Penyebab: [penyebab keterlambatan]. Sisa pekerjaan: [tugas tersisa dengan estimasi]. Tim: [komposisi]. Ruang gerak: [tambahan anggaran, fleksibilitas scope].

Mulai dengan verifikasi diagnosis: apakah karena estimasi terlalu rendah, scope creep, sumber daya ditarik, atau hambatan eksternal? Bangun rencana pemulihan hanya dari tuas riil: pengurangan scope, pengerjaan paralel (fast-tracking), penghapusan tugas non-esensial, atau penambahan tenaga khusus di jalur kritis.

Aturan: dilarang memadatkan estimasi sisa tugas tanpa alasan teknis, dilarang memotong waktu testing/QA. Output: jadwal baru dengan tanggal yang bisa dipercaya, apa yang dikorbankan untuk mencapainya, 2 syarat agar rencana ini berhasil, dan pesan untuk sponsor yang mengakui keterlambatan tanpa berbelit-belit.

Eskalasi Hambatan Tanpa Merusak Hubungan

Pesan eskalasi faktual dengan opsi solusi and biaya jika masalah dibiarkan, siap dikirim.

Siapkan eskalasi hambatan untuk proyek [nama proyek]. Hambatan: [deskripsi, misal keputusan macet, sumber daya tidak diberikan, konflik antar divisi]. Sejak kapan: [tanggal]. Upaya yang sudah dilakukan: [tindakan yang sudah diambil]. Penerima eskalasi: [nama dan jabatan]. Pihak yang terlibat dalam hambatan: [aktor dan potensi sensitivitas].

Susun pesan eskalasi: ringkasan hambatan dalam 3 baris faktual dengan tanggal, konsekuensi konkret jika dibiarkan (hari yang hilang, biaya, milestone terancam), 2-3 opsi solusi dengan rekomendasi saya, keputusan yang diminta dan batas waktunya.

Aturan: hindari serangan personal, biarkan fakta dan tanggal yang berbicara; penerima harus bisa memutuskan hanya dengan membaca pesan ini tanpa perlu rapat tambahan. Siapkan juga versi lisan 60 detik (elevator pitch) dan pesan informasi untuk pihak terkait agar mereka tidak merasa 'dilompati' secara mendadak.

Mengelola Pelacakan Aksi Antar Rapat

Sistem pelacakan and tindak lanjut pour memastikan tugas selesai tanpa terkesan mengawasi berlebihan.

Kelola pelacakan aksi proyek [nama proyek] di antara jadwal rapat. Situasi saat ini: [masalah, misal tugas hanya selesai setengah, pengingat dianggap seperti interogasi]. Frekuensi rapat: [frekuensi]. Alat yang ada: [misal Excel, Trello/Jira, WhatsApp].

Usulkan sistem lengkap: format daftar aksi (aksi dengan kata kerja dan hasil terukur, satu penanggung jawab, tenggat, status), ritual update (siapa, kapan, berapa lama), dan mekanisme pengingat bertahap: pengingat otomatis H-2, pesan personal faktual saat tenggat, dan pembahasan di rapat hanya jika sudah terlambat dua kali.

Buat draf pesan pengingat untuk 3 level tersebut secara singkat dan tanpa nada menyalahkan. Aturan: aksi tanpa tenggat atau tanpa satu penanggung jawab harus ditolak di awal; daftar aksi tidak boleh melebihi kapasitas tim, usulkan aturan pembatasan. Akhiri dengan cara mempresentasikan sistem ini ke tim agar dianggap sebagai bantuan, bukan beban.

Merancang Dashboard Proyek

Indikator kemajuan yang menunjukkan kondisi riil proyek, bukan sekadar ilusi kontrol.

Rancang dashboard untuk proyek [nama proyek]. Jenis proyek: [tipe dan deliverable]. Durasi: [durasi]. Poin kritis yang diawasi: [misal jadwal ketat, anggaran terbatas, kualitas tinggi]. Data yang tersedia: [sumber data].

Pilih maksimal 6-8 indikator dalam 3 blok: Kemajuan (aktual vs rencana dalam deliverable selesai, bukan persentase klaim tugas berjalan), Kesehatan (aksi terlambat, keputusan tertunda dan usianya, risiko yang naik level), Sumber Daya (aktual vs budget, beban kerja tim).

Untuk setiap indikator: definisi, sumber data, frekuensi update, ambang batas peringatan. Aturan: hindari indikator subjektif yang sulit diverifikasi (seperti 'progres 80%') gunakan status biner selesai/belum; setiap indikator harus memicu aksi jika berwarna merah. Jelaskan cara membaca dashboard dalam 15 menit: urutan baca, pertanyaan evaluasi, dan kapan harus menaikkan alarm ke luar tim.

Menyusun Laporan Bulanan pour Direksi

Ringkasan bulanan satu halaman yang berisi tren, keputusan penting, and peringatan dini.

Susun laporan bulanan proyek [nama proyek] untuk [penerima, misal Direksi]. Data bulan ini: pencapaian [apa yang sudah dikirim], varians [keterlambatan/kelebihan biaya], anggaran [aktual vs budget], risiko [perkembangan], keputusan yang diambil [daftar], alarm [masalah kritis].

Format wajib satu halaman: tren keseluruhan dalam 2 kalimat (apakah proyek akan selesai tepat waktu dan sesuai budget, ya/tidak, dan apa yang berubah bulan ini), pencapaian bulan ini dalam 3 poin terkait milestone, varians beserta penyebab dan solusinya (jangan ada varians tanpa rencana aksi), anggaran dalam satu baris dengan proyeksi akhir, alarm untuk direksi beserta permintaan aksi eksplisit.

Aturan: direksi membaca banyak laporan, jangan ada kalimat promosi diri atau pengisi; setiap alarm harus berujung pada permintaan spesifik (keputusan/sumber daya), jika tidak simpan untuk laporan tim. Letakkan varians dan kabar buruk di awal, jangan disembunyikan di akhir.

Arbitrase Sumber Daya Antar Proyek

Metode prioritas antar proyek dengan visualisasi dampak dari setiap keputusan alokasi.

Bantu saya melakukan arbitrase sumber daya di antara beberapa proyek yang berjalan bersamaan. Proyek aktif: [daftar proyek, tenggat, kepentingan, dan progres]. Sumber daya bersama: [orang yang bekerja di beberapa proyek dan alokasi saat ini]. Konflik saat ini: [deskripsi konflik sumber daya]. Pengambil keputusan akhir: [nama/komite].

Buat potret jujur: siapa mengerjakan apa dalam persentase riil (bukan teori), dan siapa yang terbebani lebih dari 100%. Usulkan kriteria arbitrase eksplisit: nilai strategis bagi perusahaan, biaya keterlambatan tiap proyek, urgensi waktu (window of opportunity), komitmen eksternal.

Terapkan kriteria pada konflik saat ini dan buat 2 skenario alokasi. Untuk tiap skenario, jelaskan apa yang didapat dan dikorbankan tiap proyek, serta estimasi tanggal selesai barunya. Aturan: dilarang menyelesaikan konflik dengan membebani orang berlebih atau menjanjikan alokasi 50% di 3 proyek sekaligus; skenario terpilih harus bisa dijelaskan ke manajer proyek yang 'kalah' dengan justifikasi kuat.

Menyiapkan Perencanaan Sprint (Sprint Planning)

Perencanaan sprint dengan target jelas, kapasitas realistis, and komitmen tim yang dapat dicapai.

Siapkan perencanaan sprint berikutnya untuk tim [nama tim] pada proyek [nama proyek]. Durasi sprint: [durasi]. Kapasitas: [jumlah orang, rencana cuti, waktu rutin luar sprint: support, rapat]. Backlog prioritas: [daftar tugas dengan estimasi]. Sisa sprint lalu: [tugas belum selesai].

Strukturkan sesi: hitung kapasitas riil (waktu tersedia dikurangi rutin dan buffer), rumuskan tujuan sprint (Sprint Goal) dalam satu kalimat hasil akhir (bukan daftar tiket), pilih tugas sesuai kapasitas mulai dari sisa sprint lalu, verifikasi pemahaman tim pada setiap tugas.

Aturan: tolak tugas tanpa kriteria penerimaan; jika permintaan melebihi kapasitas, solusinya adalah memilih tugas, bukan memaksakan kerja lembur secara diam-diam. Berikan alur waktu sesi, rumusan tujuan sprint, dan 3 indikator selama sprint yang menunjukkan komitmen mungkin tidak tercapai.

Memandu Retrospektif Sprint yang Berorientasi Aksi

Format retrospektif singkat and rutin dengan variasi agar tim tidak bosan dengan ritual.

Siapkan panduan retrospektif sprint untuk tim [nama tim]. Durasi: [durasi, misal 45 menit]. Suasana tim: [konteks, misal ritual mulai membosankan, ada konflik baru, tim baru]. Kejadian penting: [kejadian selama sprint]. Aksi dari retro sebelumnya: [status aksi sebelumnya].

Output: alur waktu dimulai dengan evaluasi aksi retro sebelumnya (retro tanpa tindak lanjut akan ditinggalkan tim), pilih format fasilitasi yang sesuai dengan [suasana tim] beserta instruksinya, pertanyaan untuk memicu diskusi mendalam, dan metode pemilihan aksi: maksimal 2 aksi perbaikan yang dipilih tim, masing-masing dengan penanggung jawab dan tenggat di sprint berikutnya.

Aturan: hindari aksi abstrak seperti 'komunikasi lebih baik', setiap aksi harus berupa perubahan perilaku yang bisa diamati; masalah di luar kendali tim (organisasi/hierarki) dicatat terpisah untuk eskalasi, jangan dibahas berulang-ulang. Usulkan 2 format alternatif untuk variasi retro mendatang.

Mengatur Daily Standup yang Efektif

Aturan main pertemuan harian singkat pour mendeteksi hambatan, bukan sekadar laporan agenda.

Atur format daily standup untuk tim [nama tim] pada proyek [nama proyek]. Situasi saat ini: [masalah, misal durasi 30 menit, jadi ajang lapor ke bos, peserta tidak fokus]. Ukuran tim: [jumlah orang]. Mode kerja: [WFO, WFH, atau Hybrid].

Usulkan format target: durasi maksimal, jam tetap, dan konten yang fokus pada koordinasi (apa yang selesai sejak kemarin, apa yang menghambat, apa yang butuh bantuan orang lain). Hal di luar koordinasi (debat teknis, problem solving) dicatat dan dibahas setelah standup hanya dengan pihak terkait.

Berikan: aturan fasilitasi untuk menghindari laporan ke atasan (tim saling bicara, rotasi fasilitator), kalimat untuk memotong pembicaraan yang melantur tanpa menyinggung, adaptasi untuk [mode kerja], dan 3 tanda daily standup sudah tidak efektif beserta solusinya. Akhiri dengan pesan pengumuman format baru ke tim yang menjelaskan alasannya.

Menyusun Definition of Done and Kriteria Kualitas

Definisi bersama tentang kata 'selesai' pour menghindari deliverable yang tampak selesai tapi tak kunjung rilis.

Bantu tim [nama tim] menyusun Definition of Done (DoD) untuk proyek [nama proyek]. Jenis deliverable: [misal fitur software, materi pelatihan, dokumen studi]. Masalah yang sering muncul: [gejala, misal tugas dianggap selesai tapi dibuka lagi, kualitas tidak seragam, testing menemukan banyak celah].

Bangun DoD dalam 3 level: kriteria yang membuat tugas benar-benar 'selesai' (bisa diverifikasi: review rekan, sudah dites, dokumentasi ada, divalidasi siapa), hal yang secara eksplisit dikecualikan agar tetap realistis, dan pengecualian yang diizinkan beserta aturan pencatatannya.

Aturan: maksimal 8 kriteria, semua harus bisa dijawab ya/tidak, tidak boleh ada kriteria yang tidak mampu dipenuhi tim saat ini (jika tidak, DoD akan diabaikan saat darurat). Berikan juga: cara memfasilitasi workshop tim untuk menyepakati ini, aturan penerapan pada pekerjaan yang sedang berjalan, dan jadwal tinjauan setelah beberapa minggu penggunaan.

Mengelola Uji Terima Pengguna (UAT) and Berita Acara

Rencana pengujian dengan skenario prioritas, aturan klasifikasi temuan, and berita acara keputusan.

Kelola Uji Terima Pengguna (User Acceptance Test - UAT) untuk proyek [nama proyek]. Deliverable yang diuji: [deskripsi]. Penguji: [profil dan ketersediaan]. Durasi: [durasi]. Kriteria penerimaan awal: [kriteria yang sudah ada, jika ada].

Susun: rencana UAT dengan skenario berdasarkan alur kerja riil pengguna (bukan per fitur), setiap skenario berisi data input, aksi, dan hasil yang diharapkan; prioritas temuan (blocking, mayor, minor/kosmetik); aturan klasifikasi temuan dengan contoh konkret untuk menghindari debat; alur perbaikan dan uji ulang.

Siapkan template Berita Acara Serah Terima (BAST) / UAT: apa yang diuji, daftar temuan per level, keputusan (Diterima, Diterima dengan Catatan beserta tanggal penyelesaian, atau Ditolak) dan penandatangan. Aturan: UAT tanpa data riil tidak valid, jelaskan cara menyiapkan data; catatan yang diterima harus punya penanggung jawab dan tenggat agar tidak menjadi permanen.

Menyiapkan Rencana Go-Live and Checklist Migrasi

Alur kerja per jam saat go-live, lengkap dengan kriteria go/no-go and rencana pemulihan (rollback).

Siapkan rencana go-live untuk [sistem/produk] pada proyek [nama proyek]. Tanggal target: [tanggal]. Pengguna terdampak: [siapa dan berapa banyak]. Jendela waktu (window): [misal akhir pekan, malam hari, jam kerja]. Aktor utama: [nama dan peran]. Kemungkinan rollback: [ya/tidak/parsial, dan caranya].

Susun: checklist pra-migrasi (prasyarat teknis, validasi akhir, komunikasi terkirim, backup terverifikasi, ketersediaan tim kunci), alur go-live per jam dengan penanggung jawab tiap tahap dan indikators keberhasilan yang bisa diamati, titik keputusan go/no-go (siapa yang memutuskan dan kriterianya), rencana rollback yang dipicu oleh indikator apa dan cara eksekusinya, serta pemantauan pasca go-live (hypercare).

Aturan: setiap langkah harus punya kriteria sukses yang jelas, hindari kata 'seharusnya oke'; rencana rollback harus sedetail rencana go-live karena akan dieksekusi dalam kondisi stres. Akhiri dengan draf pesan pengumuman ke pengguna sebelum dan sesudah migrasi.

Menjamin Kontinuitas Bisnis Saat Migrasi

Organisasi periode transisi di mana sistem lama and baru berjalan berdampingan.

Kelola kontinuitas bisnis selama migrasi dari [sistem lama] ke [sistem baru] di [nama perusahaan]. Durasi transisi: [durasi]. Aktivitas kritis yang tidak boleh berhenti: [daftar aktivitas]. Tim terkait: [daftar tim]. Periode risiko tinggi: [misal penutupan buku bulanan, puncak musim belanja].

Tangani masalah kritis transisi: sistem mana yang menjadi acuan (source of truth) untuk tiap jenis data selama masa transisi (aturan jelas per kasus), cara menghindari input ganda atau cara mengaturnya jika terpaksa, siapa yang menangani transaksi yang dimulai di sistem lama dan selesai di sistem baru, serta cara pembekuan data (data freeze) sebelum cut-over.

Output: tabel aktivitas kritis dengan mode operasionalnya selama transisi, aturan 'sistem acuan' per kasus, skema dukungan (support) tambahan di minggu pertama, dan 3 skenario insiden paling mungkin beserta panduan tindakannya.

Menutup Proyek Secara Rapi and Dokumentasi Belajar

Checklist penutupan administrasi, kontrak, and dokumentasi setelah proyek selesai.

Siapkan penutupan proyek [nama proyek] yang deliverable-nya telah diterima pada [tanggal]. Elemen proyek: [vendor terlibat, anggaran, dokumentasi, tim]. Catatan tersisa: [catatan UAT yang belum tuntas].

Susun checklist penutupan lengkap: aspek kontrak (pelunasan vendor, penyelesaian catatan UAT, pencabutan akses eksternal), aspek finansial (penghentian pembebanan biaya, laporan aktual vs budget beserta varians, penutupan kode budget), aspek dokumentasi (arsip di mana, apa yang harus bisa ditemukan 2 tahun lagi), aspek manusia (pengumuman penugasan baru tim, ucapan terima kasih yang tepat), aspek serah terima (siapa penanggung jawab operasional dan dukungan teknisnya).

Aturan: bedakan hal yang menghambat penutupan dan hal yang bisa diselesaikan setelahnya; proyek yang 'selesai 98%' tapi menggantung 6 bulan sangat merugikan, tetapkan tanggal tutup yang tegas. Berikan draf laporan akhir proyek satu halaman: angka kunci, keberhasilan, varians, dan lokasi arsip pembelajaran.

Mengelola Serah Terima Jabatan Manajer Proyek

Dokumen serah terima and rencana pendampingan (handover) agar transisi berjalan mulus.

Kelola serah terima proyek [nama proyek] dari [manajer proyek lama] ke [manajer proyek baru]. Konteks transisi: [alasan dan waktu yang tersedia]. Status proyek: [progres, isu panas, milestone terdekat]. Waktu pendampingan: [durasi handover].

Susun dokumen serah terima dengan memprioritaskan hal yang tidak tertulis di dokumen resmi: sejarah keputusan dan alasannya, janji lisan kepada klien/sponsor, isu sensitif dan karakter stakeholder, risiko yang diawasi secara informal, status riil tiap paket kerja di luar laporan resmi.

Atur jadwal handover: rapat perkenalan dengan sponsor, klien, dan tim; urutan materi yang disampaikan berdasarkan urgensi; dan pesan pengumuman transisi yang menenangkan tanpa berlebihan. Aturan: serah terima harus bisa diuji, siapkan daftar pertanyaan yang harus bisa dijawab manajer baru sendiri di akhir masa handover; hal yang belum sempat diserahterimakan harus dicatat beserta kontak daruratnya.

Onboarding Anggota Tim Proyek Baru

Alur integrasi agar anggota baru bisa berkontribusi cepat tanpa menyita waktu seluruh tim.

Siapkan integrasi [nama/profil baru] yang bergabung dengan tim proyek [nama proyek] pada [tanggal] di tengah proyek berjalan. Status proyek: [progres]. Peran yang diharapkan: [tugas]. Waktu pendampingan tim: [kendala waktu riil].

Susun alur 2 minggu pertama: paket bacaan hari pertama yang esensial saja (kerangka proyek, laporan mingguan terakhir, daftar risiko, glosarium istilah), 4 pertemuan singkat dengan orang kunci beserta tujuannya, satu tugas nyata yang terbatas ruang lingkupnya di minggu pertama (sesuaikan dengan [peran]), dan satu mentor pendamping untuk sesi tanya jawab 10 menit setiap hari.

Aturan: hindari 15 rapat pasif berturut-turut, orang baru belajar dengan bekerja; jelaskan hal-hal implisit: sensitivitas antar aktor, topik terlarang, dan alur keputusan riil. Berikan jadwal 2 minggu, daftar bacaan terurut, dan pertanyaan yang harus bisa dijawab orang baru di hari ke-15 untuk validasi integrasi.

Menangani Konflik Antar Anggota Tim Proyek

Langkah mediasi 3 tahap pour mengatasi konflik yang mulai mengganggu kinerja proyek.

Bantu saya menangani konflik di tim proyek. Konteks: [deskripsi faktual konflik antar dua orang tanpa menghakimi] pada proyek [nama proyek]. Dampak yang terlihat: [efek ke proyek: informasi terhambat, rapat tegang, keterlambatan]. Peran saya: [manajer proyek, tanpa/dengan wewenang struktural]. Sejarah: [durasi konflik, upaya sebelumnya].

Usulkan pendekatan 3 tahap: Wawancara individual (pertanyaan untuk memahami versi masing-masing tanpa memihak atau membocorkan rahasia, hindari menjadi hakim), Pertemuan bersama (aturan main pembukaan, cara mengembalikan ke fakta jika mulai menyerang pribadi, cara mencapai kesepakatan pada 2-3 aturan kerja konkret), Pemantauan (cara cek kesepakatan berjalan tanpa terlihat memata-matai).

Aturan: tetap pada peran manajer proyek, hal terkait SDM/HR atau manajerial struktural diidentifikasi untuk diteruskan bukan diselesaikan sendiri; jangan ada pihak yang dicap bersalah di depan tim. Sebutkan tanda-tanda kapan harus melakukan eskalasi ke atasan segera.

Menegur Vendor Eksternal yang Berkinerja Buruk

Tahapan teguran, mulai dari peringatan faktual hingga persiapan pemutusan kontrak.

Bantu saya menegur vendor yang kinerjanya menurun pada proyek [nama proyek]. Vendor: [nama perusahaan dan layanan]. Masalah: [fakta dengan tanggal: keterlambatan, kualitas buruk, ganti personel tanpa info, janji tak ditepati]. Dasar kontrak: [apa yang tertulis di kontrak: deliverable, tenggat, penalti]. Ketergantungan: [seberapa mudah vendor ini diganti].

Susun tahapan: Pertama, sesi teguran (paparan faktual selisih komitmen vs kenyataan dengan bukti; alur rapat yang menuntut rencana perbaikan formal bukan sekadar maaf), Kedua, pemantauan ketat (milestone pendek, kriteria keluar dari krisis yang jelas, notulensi tertulis tiap sesi), Ketiga, persiapan alternatif jika gagal (mulai cari opsi lain secara diam-diam jika ketergantungan tinggi).

Aturan: semua diformalkan secara tertulis setelah diskusi lisan untuk perlindungan hukum; tetap faktual dan kontraktual, jangan beri ancaman yang tidak bisa dilakukan. Output: tabel daftar penyimpangan, draf email undangan rapat teguran, agenda rapat, dan kriteria objektif untuk pemutusan hubungan.

Menyusun Kerangka Acuan Kerja (KAK) pour Vendor

Dokumen yang menjelaskan kebutuhan and kendala tanpa mendikte solusi teknis kepada vendor.

Susun Kerangka Acuan Kerja (KAK) atau Term of Reference (TOR) untuk pengadaan [objek pengadaan, misal pembuatan website, implementasi ERP] di [nama perusahaan]. Kebutuhan: [deskripsi masalah yang ingin diselesaikan]. Konteks teknis/organisasi: [sistem saat ini, kendala]. Anggaran: [rentang atau dirahasiakan]. Jadwal: [tenggat].

Struktur: profil perusahaan dan konteks (setengah halaman), masalah dan tujuan dalam bentuk hasil yang diharapkan (jelaskan kebutuhan, bukan solusi, kecuali ada kendala teknis wajib), ruang lingkup dan pengecualian, kendala non-negosiasi (teknis, regulasi, waktu), deliverable, kriteria seleksi dan bobotnya, alur pengadaan (tanya jawab, batas kirim, pitching), dan format proposal wajib agar mudah dibandingkan.

Aturan: setiap syarat harus bisa diuji saat serah terima; bedakan syarat wajib (mandatory) dan keinginan (nice-to-have). Akhiri dengan 5 pertanyaan untuk sesi pitching yang bisa mengungkap apakah vendor benar-benar paham kebutuhan kita.

Membandingkan Penawaran Vendor dengan Matriks Objektif

Matriks analisis berbobot pour memilih penawaran terbaik tanpa terjebak oleh tampilan proposal.

Susun matriks perbandingan penawaran untuk [objek pengadaan]. Penawaran: [jumlah penawaran dan ringkasan masing-masing: harga, waktu, pendekatan]. Prioritas kami: [misal ketepatan waktu, dukungan purna jual, biaya total, reputasi vendor]. Sinyal yang dirasakan: [misal harga terlalu murah, jawaban template].

Bangun matriks: kriteria dikelompokkan (pemahaman kebutuhan, metodologi, tim pelaksana, biaya total jangka panjang termasuk biaya tersembunyi, referensi serupa, syarat kontrak), bobot berdasarkan prioritas, skala penilaian dengan deskripsi tiap level untuk mengurangi subjektivitas.

Terapkan matriks pada penawaran yang ada dan sorot: selisih harga yang tidak wajar (harga sangat rendah seringkali menyembunyikan pengurangan scope), tim yang dipamerkan saat pitching vs yang akan bekerja nanti, biaya rutin tersembunyi. Output: tabel perbandingan terisi, daftar pertanyaan klarifikasi per vendor, dan rekomendasi 5 baris.

Menyusun Rencana Manajemen Perubahan (Change Management)

Rencana pendampingan pengguna berdasarkan profil, mulai dari agen perubahan internal hingga pasca-migrasi.

Susun rencana manajemen perubahan untuk [proyek, misal sistem baru, proses baru] di [nama perusahaan]. Kelompok terdampak: [daftar kelompok, jumlah orang, dan apa yang berubah bagi mereka]. Kekhawatiran yang muncul: [resistensi yang diperkirakan]. Jadwal implementasi: [tanggal kunci]. Sumber daya: [waktu, anggaran, agen perubahan].

Untuk setiap kelompok: apa yang berubah secara konkret (keuntungan DAN kerugian, kerugian yang disembunyikan akan menjadi bom waktu), tingkat pendampingan (info saja, pelatihan, atau asistensi melekat), dan pesan kunci dari sudut pandang mereka.

Strukturkan dalam waktu: Sebelum (pengumuman, pembentukan agen perubahan internal yang kredibel, pelatihan), Selama (asistensi intensif, kanal keluhan, perbaikan cepat pada masalah yang dilaporkan), Sesudah (pengukuran penggunaan riil bukan cuma tingkat kehadiran training, penanganan kantong resistensi).

Aturan: jangan buat rencana 'komunikasi lebih banyak' tanpa isi yang jelas; setiap aksi punya pelaksana dan tanggal. Sajikan dalam tabel per kelompok dan jadwal konsolidasi.

Merancang Rencana Pelatihan Pengguna Akhir

Sistem pelatihan per profil pengguna, berbasis kasus nyata and diukur dari tingkat penggunaan.

Rancang rencana pelatihan pengguna akhir untuk implementasi [sistem/proses] di [nama perusahaan]. Pengguna: [profil, jumlah, tingkat literasi digital, lokasi]. Kemampuan yang harus dikuasai: [tugas per profil]. Kendala: [waktu tim, anggaran, tenggat go-live].

Buat skema per profil bukan satu training untuk semua: untuk setiap profil, tentukan 5-10 alur kerja utama (bukan semua fitur), format yang sesuai (sesi grup singkat, tutorial video, pendampingan di meja kerja), durasi, dan materi referensi (lembar panduan satu halaman per tugas, bukan buku manual tebal).

Jadwalkan sesi sedekat mungkin dengan go-live: training 6 minggu sebelum pakai akan terlupakan. Siapkan skema susulan bagi yang absen dan tunjuk 'key user' di tiap lokasi/tim.

Aturan: ukur keberhasilan pada penggunaan riil setelah go-live (kemampuan menjalankan tugas kunci, volume tiket support) bukan pada tingkat kehadiran. Output: tabel rencana per profil dan daftar materi yang harus dibuat berdasarkan prioritas.

Komunikasi Saat Insiden Kritis Proyek

Pesan krisis pour setiap audiens, mulai dari laporan awal hingga pengumuman resolusi.

Terjadi insiden kritis pada proyek [nama proyek]: [jenis insiden, misal gagal migrasi, data hilang, layanan mati, penyimpangan anggaran besar]. Dampak: [siapa yang terkena dan bagaimana]. Status perbaikan: [apa yang diketahui, apa yang belum]. Audiens: [direksi, tim internal, klien, mitra].

Susun urutan komunikasi: pesan pertama yang cepat (apa yang diketahui, apa yang belum, apa yang sedang dilakukan, dan kapan update berikutnya. Janjikan jam update, bukan jam selesai), update berkala sesuai janji meski belum ada perkembangan baru, dan pesan resolusi beserta langkah pencegahan agar tidak terulang.

Sesuaikan pesan per audiens: Direksi butuh dampak dan keputusan, tim internal butuh panduan kerja sementara, klien butuh kepastian data mereka aman. Aturan: jangan spekulasi penyebab sebelum terbukti, jangan cari kambing hitam, jangan ingkar janji tenggat update: kredibilitas Anda taruhannya. Output: draf pesan siap pakai dan aturan siapa bicara kepada siapa.

Menyusun OKR Tim

Tujuan kuartalan and hasil kunci yang terukur, selaras dengan prioritas perusahaan.

Bantu tim [nama tim] di [nama perusahaan] menyusun OKR untuk kuartal [kuartal]. Prioritas perusahaan: [prioritas]. Tugas rutin tim: [aktivitas tetap]. Inisiatif baru: [proyek/ide]. Jumlah anggota: [jumlah].

Buat maksimal 2-3 Objective: masing-masing berupa perubahan status yang inspiratif tapi konkret (bukan daftar tugas), terhubung ke prioritas perusahaan. Untuk setiap Objective, buat 2-4 Key Results: terukur dengan nilai awal dan target, mengukur hasil (outcome) bukan aktivitas (misal: 'menurunkan waktu proses dari X ke Y' bukan 'implementasi alat Z').

Aturan: operasional harian (run) jangan jadi OKR, itu dikelola terpisah; Key Result yang tidak tahu cara mengukurnya harus diubah atau dibuang; sorot tujuan yang di luar kendali penuh tim. Output: usulan OKR, pertanyaan untuk workshop tim, dan ritual pelacakan: frekuensi, format 15 menit, dan tindakan jika Key Result meleset.

Memandu Tinjauan Kuartalan OKR

Evaluasi akhir kuartal yang jujur, mengambil pelajaran, and menyiapkan kuartal berikutnya.

Siapkan tinjauan akhir kuartal OKR untuk tim [nama tim]. OKR kuartal lalu: [tujuan dan hasil kunci dengan tingkat pencapaian]. Kejadian penting: [konteks: hal tak terduga, perubahan prioritas, resign]. Peserta: [peserta]. Durasi: [durasi].

Strukturkan tinjauan dalam 3 tahap: Penilaian jujur tiap Key Result berdasarkan angka riil (KR tak terukur dianggap tidak tercapai), Analisis varians (bedakan masalah eksekusi, ambisi terlalu tinggi, atau faktor eksternal), Keputusan kuartal depan (apa yang dilanjutkan, dihentikan, atau disesuaikan).

Aturan: tinjauan bukan ajang pembelaan diri, hindari slide konteks yang panjang dan langsung ke angka; tujuan yang tercapai 100% di bulan pertama menandakan kurang ambisius, sama seperti pencapaian 20% menandakan masalah eksekusi. Output: alur waktu, matriks penilaian, pertanyaan analisis per KR, dan draf ringkasan untuk dibagikan setelah rapat.

Melakukan Post-Mortem Insiden Tanpa Menyalahkan

Analisis insiden secara objektif, fokus pada penyebab sistemik and tindakan pencegahan.

Siapkan sesi post-mortem untuk insiden [deskripsi insiden] yang terjadi pada [tanggal] di proyek [nama proyek]. Kronologi: [urutan kejadian dengan jam jika ada]. Pihak terlibat: [aktor]. Suasana: [konteks, misal ada yang merasa disudutkan, pimpinan cari yang salah].

Strukturkan dokumen dan rapat: Kronologi faktual kolektif (jam demi jam, tanpa interpretasi), Analisis penyebab (Root Cause Analysis) melampaui kesalahan individu (kesalahan manusia adalah gejala: apa yang memungkinkan itu terjadi, sistem apa yang seharusnya mencegahnya), hal yang berjalan baik saat deteksi & respon, dan aksi pencegahan.

Aturan pembukaan: kita mencari celah sistem, bukan siapa yang salah; orang yang berani bilang 'saya salah' adalah pahlawan bagi tim dan tidak boleh menyesalinya. Aturan: maksimal 5 aksi, masing-masing dengan penanggung jawab dan tenggat, prioritaskan aksi yang menghilangkan kemungkinan kesalahan daripada aksi 'lebih waspada'. Output: template dokumen dan alur rapat.

Mengubah Pembelajaran Menjadi Standar Tim

Transisi dari sekadar 'pelajaran yang didapat' menjadi aturan kerja yang benar-benar diterapkan.

Bantu saya mengubah pembelajaran (lessons learned) yang dikumpulkan oleh [tim/perusahaan] menjadi standar operasional. Data yang ada: [sumber: notulensi retro, laporan akhir proyek, post-mortem, keluhan rutin]. Masalah saat ini: [gejala, misal kesalahan yang sama berulang, laporan akhir hanya jadi pajangan].

Langkah: kelompokkan pembelajaran per tema dan cari yang berulang (pengulangan menunjukkan prioritas standar), ubah setiap poin menjadi aturan aksi satu kalimat dengan pemicunya (misal: 'setiap mulai proyek, kita wajib melakukan X'), tentukan di mana aturan ini disimpan agar terlihat di waktu yang tepat: masukkan ke template dokumen atau checklist yang sudah ada, bukan di dokumen terpisah yang jarang dibuka.

Aturan: maksimal 10 aturan total, setiap aturan punya pemilik; buat jadwal tinjauan semesteran untuk menghapus aturan yang sudah tidak relevan. Output: usulan aturan berdasarkan waktu penggunaan, media integrasinya, dan pesan pengumuman ke tim.

Menyiapkan Audit atau Tinjauan Kualitas Proyek

Persiapan tinjauan proyek: dokumen, pengakuan titik lemah, and simulasi wawancara.

Siapkan proyek [nama proyek] untuk audit atau tinjauan kualitas oleh [auditor: audit internal, klien, sertifikasi, direksi] pada [tanggal]. Ruang lingkup audit: [apa yang diperiksa]. Kondisi riil proyek: [kekuatan dan kelemahan, kelengkapan dokumen]. Urgensi: [apa yang dipertaruhkan: dana, kepercayaan klien, sertifikasi].

Kelola persiapan: daftar dokumen referensi (kerangka, keputusan, log risiko, notulensi, anggaran) dengan sorotan pada dokumen yang mungkin hilang/kadaluwarsa untuk segera diperbaiki, daftar pertanyaan yang kemungkinan besar diajukan auditor, dan untuk setiap titik lemah siapkan posisi jujur: akui, tunjukkan bahwa itu sudah teridentifikasi dan dikelola, serta tunjukkan rencana aksi dengan tanggal pasti.

Aturan: jangan pernah memalsukan dokumen atau memundurkan tanggal (backdate), titik lemah yang diakui dengan rencana kredibel lebih baik daripada fasad yang runtuh saat wawancara; beri pengarahan kepada tim untuk menjawab berdasarkan fakta, bukan sekadar 'bahasa marketing'. Output: checklist dokumen, daftar pertanyaan & jawaban, dan jadwal persiapan mundur (backward planning).

Uji prompt Manajemen Proyek ini dengan data Anda

Salin prompt, buka di GPTPro, dan bandingkan jawaban dari Claude, GPT, Gemini, serta Mistral untuk kasus Anda.