Brief proyek yang hebat membuat semua orang berada di halaman yang sama sebelum proyek dimulai—apa yang sedang dibangun, mengapa hal itu penting, siapa saja yang terlibat, dan bagaimana keberhasilan akan diukur. Dengan Trupeer, Anda dapat menghemat berjam-jam untuk menulis brief proyek dengan memulai dari template brief proyek gratis, menyesuaikannya dengan identitas brand Anda, lalu mengubah brief menjadi ringkasan video singkat yang dapat ditonton pemangku kepentingan dalam 3 menit.

Apa itu template brief proyek, dan kapan ditulis?

Brief proyek adalah dokumen singkat yang ditulis tepat di awal proyek, sebelum rencana ada, yang menjelaskan untuk apa proyek ini, mengapa penting saat ini, siapa yang terdampak, seperti apa keberhasilannya, dan apa saja batasannya.

Dokumen inilah yang ditandatangani orang untuk mengotorisasi pekerjaan, dan menjadi acuan yang akan diperdebatkan semua orang enam bulan kemudian. Brief dibuat sengaja singkat, biasanya satu atau dua halaman, karena ditulis pada saat informasi masih paling minim.

Template memberi Anda bagian-bagiannya. Latar belakang, tujuan, ruang lingkup, deliverables, timeline, anggaran, pemangku kepentingan, kriteria keberhasilan. Setiap versi yang Anda temukan umumnya menawarkan hal-hal tersebut, dan tidak ada yang salah dengan itu.

Masalah dengan brief hampir tidak pernah ada pada bagian-bagiannya. Masalahnya ada pada apa yang dimasukkan ke dalamnya.

Kebanyakan brief menyatakan solusi, bukan masalah

Ini keluhan yang dibuat setiap tim delivery, agensi, dan kelompok engineering tentang brief—diungkap dengan cara yang sama di setiap industri: kami diberi brief tentang solusinya.

"Bangun portal pelanggan." "Buat intranet baru." "Kirim aplikasi seluler." "Redesain alur onboarding." Masing-masing adalah sesuatu yang harus dibangun, seolah-olah itu adalah persyaratan, padahal sebenarnya itu adalah jawaban seseorang atas pertanyaan yang tidak pernah disebutkan dalam brief.

Hal itu terjadi karena alasan yang masuk akal. Siapa pun yang menginisiasi proyek biasanya sudah memikirkannya selama berminggu-minggu dan sampai pada sebuah kesimpulan. Menulis kesimpulan terasa seperti kejelasan, sedangkan menulis masalah terasa seperti ketidakjelasan.

Hasilnya, solusi termurah dihilangkan sebelum siapa pun sempat melihatnya. Begitu brief menyebut portal, proyek menjadi proyek portal, dan opsi yang seharusnya bisa menyelesaikan 80% masalah dengan 5% biaya tidak pernah dievaluasi, karena tidak ada yang diminta untuk mengevaluasi apa pun.

Brief yang menyatakan masalah mengundang jawaban. Brief yang menyatakan solusi mengundang estimasi.

Cara menyesuaikan template ini di Trupeer

Langkah 1: Buka Bagian Templates

Buka bagian Templates dari navigasi utama.

Langkah 2: Pilih dan Buka Template

Klik pada template apa pun yang ingin Anda gunakan untuk membukanya.

Langkah 3: Perluas Tampilan Template

Jika perlu, perluas tampilan template untuk melihat tata letak dan detailnya dengan jelas.

Langkah 4: Edit Template

Klik Edit untuk mulai memodifikasi template yang dipilih.

Di dalam editor, Anda bisa:

• Menambahkan bagian baru

• Menentukan atau memperbarui aturan pemformatan

• Menambahkan logo dan menyesuaikan posisinya serta pengaturan terkait

Langkah 5: Simpan Template yang Disesuaikan

Setelah melakukan semua perubahan yang diperlukan, klik Save untuk menyimpan template yang diperbarui sebagai milik Anda.

Langkah 6: Pratinjau dan Penyempurnaan Template

Saat Anda ingin melihat seperti apa tampilan template yang disesuaikan, buka Preview.

Dari layar pratinjau, Anda dapat terus melakukan penyesuaian secara langsung jika diperlukan, sehingga template tampil persis seperti yang Anda inginkan.

Dengan template brief proyek, Anda bisa:

• Menghemat waktu untuk menulis: Lewati halaman kosong dengan struktur brief yang sudah terbukti.

• Menyelaraskan pemangku kepentingan dengan cepat: Brief satu halaman membuat persetujuan dan penyelarasan lebih cepat.

• Tetap sesuai brand: Terapkan logo, font, dan warna Anda menggunakan brand kit Trupeer—sempurna untuk brief agensi dan klien.

• Pitch dengan dampak: Ubah brief menjadi ringkasan video—bagus untuk sales enablement dan pitch pemangku kepentingan.

• Standarisasi di seluruh proyek: Gunakan format brief yang sama untuk setiap inisiatif.

• Menjangkau tim global: Terjemahkan brief ke 65+ bahasa hanya dengan satu klik.

Tiga jawaban untuk menguji setiap brief proyek

Dua menit, dan ini satu-satunya uji brief yang layak dilakukan.

Baca brief dan sebutkan tiga hal yang benar-benar berbeda yang akan memenuhinya.

Bukan tiga variasi dari hal yang sama. Tiga pendekatan berbeda: bangun sesuatu, ubah proses, beli sesuatu, hapus satu langkah, komunikasikan dengan cara berbeda, lakukan lebih sedikit.

Jika Anda bisa menyebutkan tiga, brief tersebut menggambarkan sebuah masalah dan proyek memiliki keputusan nyata di depannya.

Jika Anda hanya bisa menyebutkan satu, brief tersebut menggambarkan sebuah solusi. Itu tidak otomatis salah, karena kadang keputusan memang sudah diambil dengan alasan yang baik, dan dalam kasus itu, hal yang jujur adalah mengatakan demikian serta menyebut dokumen tersebut sebagai spesifikasi, bukan brief. Yang tidak jujur adalah menyajikan kesimpulan yang sudah diputuskan sebagai pertanyaan terbuka lalu terkejut karena tidak ada yang menantangnya.

Jalankan uji ini pada brief sebelum diedarkan, bersama seseorang yang tidak terlibat dalam penulisannya. Orang yang menulisnya selalu bisa menyebutkan tiga, karena mereka tahu apa yang mereka tolak. Orang lain tidak bisa, karena brief tidak memuatnya.

Cara menulis masalah, bukan deliverable

Empat kebiasaan, dan tidak ada satupun yang memakan waktu lebih lama daripada menulis solusi.

Mulailah dengan observasi dan angka. Bukan "pelanggan kesulitan memeriksa pesanan mereka" melainkan "pelanggan menghubungi kami enam ribu tujuh ratus kali bulan lalu untuk menanyakan di mana pesanan mereka". Angka melakukan dua hal: memastikan masalah itu nyata, dan menentukan nilai yang layak dari sebuah solusi.

Jelaskan apa yang terjadi sekarang. Bagaimana masalah tersebut saat ini ditangani, dengan buruk, termasuk workaround yang diciptakan orang. Deskripsi kondisi saat ini memungkinkan seseorang mengusulkan jawaban yang lebih murah.

Pisahkan batasan dari persyaratan. Anggaran adalah batasan. Tenggat waktu adalah batasan. Harus terintegrasi dengan sistem gudang yang sudah ada adalah batasan. "Harus ada login" adalah persyaratan yang disamarkan sebagai batasan, dan biasanya muncul dari gambaran mental seseorang tentang solusi.

Tetapkan keberhasilan sebagai perubahan pada angka, bukan sebagai keberadaan deliverable. Mengurangi kontak tersebut setengah dalam enam bulan adalah kriteria keberhasilan. Meluncurkan portal adalah tonggak.

Jika Anda memang memiliki solusi yang terbayang, masukkan ke bagian yang diberi label dengan jelas yang menyatakan demikian, sebagai salah satu kandidat, bukan sebagai brief.

Template brief proyek gratis: struktur yang bisa dicontoh

Salin dari sini. Satu atau dua halaman, dan tahan diri untuk tidak menambah.

Header. Nama proyek, sponsor, penulis, tanggal, versi, dan keputusan yang dicari.

Masalah. Observasi dengan angka, seberapa sering terjadi, dan biayanya. Dua atau tiga kalimat.

Bagaimana ditangani sekarang. Proses saat ini, termasuk workaround, dan mengapa itu tidak cukup baik.

Kenapa sekarang. Apa yang berubah sehingga layak dilakukan pada kuartal ini, bukan tahun depan.

Siapa yang terdampak. Orang atau pelanggan yang terlibat, dan kira-kira berapa jumlahnya.

Kriteria keberhasilan. Angka apa yang bergerak, seberapa besar, dan kapan. Satu atau dua, dinyatakan sebagai outcome.

Batasan. Anggaran, tenggat waktu, sistem yang tidak bisa berubah, kewajiban regulasi atau kontrak, serta orang yang tidak tersedia. Semua yang benar-benar tetap, dan tidak ada yang sebenarnya hanya preferensi.

Di luar cakupan. Apa yang tidak akan ditangani proyek ini, disebutkan secara spesifik agar tidak menimbulkan perdebatan.

Pendekatan kandidat, jika ada. Solusi yang sudah dipertimbangkan, diberi label jelas sebagai kandidat, bukan sebagai brief, beserta alasan tiap kandidat ada dalam daftar.

Keputusan yang dicari dan oleh siapa. Apa yang Anda minta dan siapa yang mengotorisasinya.

Salin sampai di sini. Jika brief melewati dua halaman, penyebab umumnya adalah latar belakang, yang seharusnya masuk ke lampiran yang tidak akan dibaca orang, dan itu tidak apa-apa.

Peritel yang membangun portal yang tidak didaftarkan siapa pun

Ashfold Group adalah peritel spesialis dengan sekitar sembilan puluh toko dan bisnis online yang cukup besar.

Briefnya dua halaman, ditulis dengan baik, dan disetujui tanpa kesulitan. Isinya: bangun portal layanan mandiri pelanggan agar pelanggan bisa masuk untuk melihat status pesanan, mengunduh faktur, dan mengajukan pertanyaan. Anggaran tiga ratus empat puluh ribu poundsterling. Sembilan bulan.

Proyek diserahkan tepat waktu dan mendekati anggaran, yaitu tiga ratus tujuh puluh satu ribu.

Enam bulan setelah peluncuran, ada tiga ribu seratus akun terdaftar dibandingkan kira-kira empat puluh enam ribu pelanggan aktif, jadi di bawah tujuh persen. Volume kontak ke pusat layanan tidak berubah.

Tinjauan setelah implementasi mengajukan pertanyaan sederhana: masalah apa yang dibangun untuk diselesaikan? Tidak ada yang bisa menunjuknya dalam brief, karena brief tersebut telah menggambarkan sebuah solusi.

Jadi seseorang pergi dan mencari masalahnya. Pusat layanan menangani sekitar sebelas ribu kontak per bulan. Sampel lima ratus menunjukkan enam puluh satu persen adalah versi dari "di mana pesanan saya", yang kira-kira enam ribu tujuh ratus kontak per bulan.

Dari pelanggan tersebut, delapan puluh empat persen sudah menerima email pengiriman yang berisi tautan pelacakan. Entah mereka tidak melihatnya, atau mereka kembali ke tautan itu setelah tautan kedaluwarsa pada 14 hari.

Masalah dominannya, oleh karena itu, bukan karena pelanggan tidak punya cara untuk memeriksa. Masalahnya adalah cara yang sudah mereka miliki tidak berfungsi.

Tiga pendekatan yang lebih murah tidak pernah dievaluasi, karena brief tidak mengundang apa pun. Memperpanjang masa berlaku tautan pelacakan. Mengirim ulang tautan secara berkala hingga pengiriman. Menambahkan status pesanan ke area akun yang sudah ada, yang diperkirakan setelahnya sekitar delapan belas ribu poundsterling.

Portal tersebut adalah solusi yang sah untuk masalah nyata. Portal itu bukan masalah terbesar, dan portal itu membutuhkan pendaftaran, yang tidak pernah dilakukan oleh sembilan puluh tiga persen pelanggan.

Brief untuk proyek tindak lanjut ditulis dengan cara yang berbeda. Pelanggan menghubungi kami enam ribu tujuh ratus kali per bulan untuk menanyakan di mana pesanan mereka. Delapan puluh empat persen dari mereka sudah menerima tautan pelacakan. Kurangi kontak tersebut setengah dalam enam bulan. Batasan: tidak ada perubahan pada integrasi operator, seratus lima puluh ribu poundsterling, dan harus berfungsi tanpa mengharuskan pelanggan mendaftar.

Tiga tim mengusulkan tiga jawaban yang benar-benar berbeda. Yang dipilih biayanya enam puluh dua ribu poundsterling dan mengurangi kontak tersebut sebesar lima puluh delapan persen dalam lima bulan.

Perbedaan antara dua brief tersebut adalah bahwa brief kedua bisa dijawab dengan tiga cara. Brief pertama bisa dijawab dengan satu cara, dan cara itu sudah dipilih.

Elemen kunci yang dibutuhkan setiap brief proyek

Dua baris yang paling berbobot adalah kondisi saat ini dan batasan, dan keduanya biasanya tipis. Kondisi saat ini adalah yang memungkinkan seseorang mengusulkan jawaban yang murah. Batasan, yang dipisahkan secara jujur dari preferensi, adalah yang mencegah sebuah brief berubah menjadi spesifikasi secara tidak sengaja.

Cara menulis brief proyek dalam lima langkah

Satu. Tulis masalah dengan angka. Jika Anda tidak bisa mendapatkan angka, luangkan waktu satu sore untuk mendapatkannya. Brief tanpa angka adalah preferensi.

Dua. Jelaskan kondisi saat ini, termasuk bagaimana orang mengatasinya hari ini.

Tiga. Tetapkan keberhasilan sebagai perubahan pada angka itu, dengan tanggal.

Empat. Daftar batasan dan tantang masing-masing. Untuk setiap item, tanyakan siapa yang memutuskan ini dan apa yang terjadi jika itu berubah. Kira-kira sepertiga biasanya bisa, dan setiap batasan yang bisa berubah memperluas rentang jawaban yang mungkin.

Lima. Jalankan uji tiga jawaban dengan seseorang yang tidak menulisnya. Jika gagal, baik buka brief atau beri label ulang dokumen secara jujur.

Setelah itu, edarkan, dan harapkan jawaban yang Anda terima setidaknya memuat satu hal yang belum pernah Anda pikirkan. Jika tidak ada yang mengejutkan Anda, kemungkinan brief tersebut adalah spesifikasi.

Batasan, dan bagaimana batasan diselipkan sebagai persyaratan

Di sinilah sebagian besar brief diam-diam berubah menjadi spesifikasi, dan itu terjadi tanpa ada niat dari siapa pun.

Batasan yang benar-benar nyata adalah sesuatu yang berada di luar kendali proyek. Anggaran adalah apa adanya. Tenggat waktu regulasi sudah tetap. Sistem gudang tidak diganti tahun ini. Tim memiliki empat orang.

Preferensi yang dibungkus sebagai batasan terdengar identik. Harus berupa aplikasi seluler. Perlu dasbor. Pengguna harus memiliki login. Masing-masing adalah gambaran mental seseorang tentang jawaban, dan begitu masuk ke bagian batasan, itu dianggap tidak bisa diganggu oleh semua pihak setelahnya.

Ujiannya adalah bertanya, untuk setiap item, siapa yang memutuskan ini dan apa yang terjadi jika itu berubah. Batasan yang nyata memiliki pemilik di luar proyek dan konsekuensi jika dilanggar. Preferensi tidak memiliki keduanya, dan biasanya orang yang menulisnya akan dengan senang hati menjatuhkannya jika diminta secara langsung.

Jalankan percakapan itu sebelum brief diedarkan. Butuh dua puluh menit dan sering kali merupakan nilai tertinggi dari dua puluh menit dalam seluruh proyek, karena setiap batasan yang dihapus menambah kemungkinan jawaban.

Brief proyek, business case, atau rencana proyek?

Tiga dokumen di awal proyek, berurutan, dengan pekerjaan yang berbeda.

Dokumen brief menyatakan masalah, batasan, dan kriteria keberhasilan. Dokumen ini ditulis pertama, singkat, dan mengotorisasi penyelidikan atau pelaksanaan.

Dokumen business case membenarkan pengeluaran. Dokumen ini berisi opsi dengan biaya dan manfaat, dan biasanya disetujui oleh fungsi keuangan atau dewan investasi. Brief yang menjadi panjang dan penuh angka biasanya adalah business case dengan nama yang salah.

Dokumen project plan mencakup bagaimana pendekatan yang dipilih akan dijalankan: ruang lingkup, jadwal, sumber daya, dependensi, dan risiko. IT project plan template kami mencakup lapisan tersebut.

Urutannya penting. Brief, lalu opsi, lalu business case, lalu rencana. Menulis rencana sebelum brief—yang terjadi lebih sering daripada yang diakui siapa pun—berarti pendekatan sudah dipilih sebelum masalah dinyatakan.

Begitu rencana sudah ada, brief harus secara eksplisit digantikan, bukan dibiarkan sebagai arsip sumber kedua untuk ruang lingkup yang disepakati. Dua dokumen yang mengklaim otoritas adalah cara agar sengketa ruang lingkup menjadi tidak bisa diselesaikan.

Varian brief proyek: kreatif, desain, perangkat lunak, dan konstruksi

Strukturnya tetap sama di berbagai jenis, sementara penekanannya bergeser.

Brief kreatif dan pemasaran membutuhkan audiens dan pesan, dan ini paling rentan terhadap solution-briefing, karena klien datang dengan format yang sudah mereka bayangkan. Masalah di sini biasanya adalah perilaku yang ingin Anda ubah, bukan sesuatu yang ingin Anda buat.

Brief desain membutuhkan pengguna, konteks penggunaan, dan batasan dari sistem yang sudah ada. Hampir setiap brief dalam kategori ini mendapat manfaat dari uji tiga jawaban, karena brief desain yang menentukan tata letak telah menghilangkan desainnya.

Brief proyek perangkat lunak membutuhkan masalah dan workaround saat ini lebih dari apa pun, dan sebaiknya tetap bebas dari fitur sepenuhnya. Begitu fitur masuk ke dalam cakupan, Anda sedang menulis dokumen persyaratan, yang dicakup oleh lean PRD template kami.

Brief konstruksi dan desain membawa batasan yang benar-benar adalah batasan: lokasi, perencanaan, regulasi, anggaran. Di sini, bagian batasan adalah substansi, bukan risikonya.

Proyek yang berat pada pengadaan perlu brief menyatakan apa yang dibeli sebagai outcome, bukan sebagai spesifikasi, karena keputusan kematangan spesifikasi datang belakangan dan procurement management plan template kami mencakup hal itu.

Bisakah saya mendapatkan template brief proyek dalam Word atau Excel?

Word atau Google Docs. Brief adalah prosa, satu atau dua halaman, dan akan dikomentari sebelum disetujui. Tidak ada yang menginginkan spreadsheet di dalamnya.

Excel layak digunakan hanya jika Anda menjalankan banyak proyek dan ingin membuat register: proyek, sponsor, masalah dalam satu baris, kriteria keberhasilan, batasan anggaran, status, dan tanggal persetujuan. Register itu benar-benar berguna untuk menemukan pola yang tidak terlihat jika tidak, yaitu berapa banyak proyek Anda yang memiliki kriteria keberhasilan yang dinyatakan sebagai deliverable, bukan sebagai angka.

PDF untuk versi yang disetujui, diekspor saat penandatanganan. Karena brief adalah acuan untuk sengketa di kemudian hari, membekukan versi yang disetujui dengan tanggal lebih penting di sini dibandingkan untuk kebanyakan dokumen.

PowerPoint adalah wadah yang buruk. Brief yang disajikan sebagai slide cenderung kehilangan pernyataan masalah dan tetap mempertahankan solusinya, karena alasan yang sama yang dijelaskan di seluruh halaman ini.

Cara menunjukkan masalah, bukan mendeskripsikannya

Bagian tersulit dari brief yang baik adalah membuat masalah terasa nyata bagi orang yang tidak mengalaminya. Angka membantu. Sebuah paragraf jarang membantu.

Ada alternatif yang murah yang hampir tidak pernah digunakan: rekam masalah yang sedang terjadi.

Dua menit dari agen layanan yang menangani panggilan "di mana pesanan saya", atau dari seseorang yang mengatasi langkah yang rusak dengan tiga tab browser dan spreadsheet, menyampaikan lebih banyak daripada satu halaman deskripsi dan sangat sulit untuk diperdebatkan. Lampirkan ke brief.

Trupeer AI membuat hal itu menjadi mudah, karena rekaman layar berubah menjadi video sekaligus panduan tertulis dari proses saat ini—tepat seperti yang dibutuhkan bagian kondisi saat ini dalam brief. Ini juga memberi tim delivery sesuatu untuk dirujuk saat mereka memutuskan di antara pendekatan, alih-alih hanya mengandalkan kata-kata dalam brief berbulan-bulan kemudian.

Rekam. Branding. Terjemahkan. Trupeer-kan.

Rekaman yang sama juga berguna setelahnya sebagai kondisi sebelum saat Anda mengukur apakah proyek berhasil. Materi tersebut tersimpan di knowledge base Anda dengan branding yang konsisten, dan instruksi penyiapannya ada di panduan penyiapan template dokumen.

Pertanyaan yang Sering Diajukan

Apakah ada template brief proyek gratis di Word?

Struktur di atas langsung ditempel ke Word atau Google Docs. Tidak ada unduhan berpagar dan tidak ada formulir. Dua bagian yang perlu ditulis pertama adalah masalah beserta angkanya dan batasannya, karena semuanya mengikuti dari keduanya dan dua template paling lemah biasanya ditangani oleh dua bagian tersebut.

Apakah ada template brief proyek gratis di Excel?

Excel cocok untuk register brief di seluruh portofolio, bukan untuk brief individual. Kolom untuk proyek, sponsor, masalah dalam satu baris, kriteria keberhasilan, batasan anggaran, status, dan tanggal persetujuan. Memindai register tersebut untuk kriteria keberhasilan yang dinyatakan sebagai deliverables adalah cara cepat untuk menemukan proyek mana yang tidak memiliki outcome yang terukur.

Di mana saya bisa menemukan contoh brief proyek dalam PDF?

Contoh yang dipublikasikan mudah ditemukan, termasuk dari badan sektor publik dan organisasi kesehatan, dan layak dibaca untuk urutan bagian. Bacalah secara kritis, karena sebagian besar brief yang dipublikasikan adalah brief solusi, dan membacanya tanpa kritis memperkuat kebiasaan bahwa halaman ini membahas hal tersebut.

Berapa lama brief proyek seharusnya?

Satu atau dua halaman. Brief yang lebih panjang biasanya membawa latar belakang yang seharusnya masuk ke lampiran, atau mereka telah menyerap business case. Jika brief tidak bisa dibaca dalam lima menit oleh sponsor, brief itu akan di-skim, dan bagian yang di-skim pertama adalah pernyataan masalah.

Siapa yang seharusnya menulis brief proyek?

Sponsor atau orang yang memiliki masalah tersebut, dengan seseorang dari tim delivery yang membacanya sebelum diedarkan. Pembaca kedua inilah yang menangkap solution-briefing, karena mereka adalah orang yang seharusnya menghabiskan sembilan bulan untuk membangun jawaban yang salah.

Apa perbedaan antara brief proyek dan creative brief?

Sebagian besar perbedaannya ada pada domain, bukan pada struktur. Creative brief menambahkan audiens, pesan, nada, dan kanal, dan biasanya ditulis oleh klien untuk agensi. Keduanya sama-sama menderita solution-briefing, dan uji tiga jawaban berlaku untuk keduanya tanpa modifikasi.

Kapan brief proyek harus disetujui?

Sebelum perencanaan atau estimasi apa pun dimulai, dan khususnya sebelum siapa pun berkomitmen pada sebuah pendekatan. Brief yang disetujui setelah pendekatan dipilih adalah formalitas, dan tidak akan membantu saat ruang lingkup diperdebatkan nanti, karena semua orang akan mengingat pendekatannya, bukan dokumennya.

Apa yang terjadi pada brief setelah rencana proyek ada?

Brief harus secara eksplisit digantikan dan ditandai demikian, dengan rencana menjadi satu-satunya sumber ruang lingkup yang disepakati. Membiarkan brief tetap aktif sebagai otoritas kedua adalah yang membuat sengketa ruang lingkup tidak bisa diselesaikan, karena kedua pihak bisa mengutip dokumen. Simpan brief sebagai catatan tentang masalah apa yang sedang diselesaikan, yang benar-benar berguna saat penutupan.