Ketika perusahaan ingin mengembangkan aplikasi, membangun sistem internal, atau melakukan digitalisasi proses bisnis, menggunakan vendor IT outsourcing bisa menjadi cara untuk mempercepat pengerjaan.
Namun, ada satu hal yang sering dianggap sepele: project brief.
Brief yang terlalu singkat membuat vendor harus menebak kebutuhan perusahaan. Sebaliknya, brief yang terlalu teknis bisa membuat perusahaan terlalu cepat menentukan solusi sebelum memahami masalah yang sebenarnya perlu diselesaikan.
Project brief yang baik berada di tengah-tengah. Isinya cukup jelas untuk membantu vendor memahami konteks, tujuan, scope, dan ekspektasi proyek, tetapi tetap memberi ruang bagi vendor untuk memberikan rekomendasi teknis.
Apa Itu Project Brief?
Project brief adalah dokumen singkat yang menjelaskan gambaran utama sebuah proyek, mulai dari masalah yang ingin diselesaikan, tujuan, target pengguna, scope, deliverables, timeline, hingga batasan proyek.
Dalam proyek IT outsourcing, project brief berfungsi sebagai titik awal komunikasi antara perusahaan dan vendor.
Vendor tidak hanya membutuhkan informasi tentang "apa yang ingin dibuat", tetapi juga perlu memahami mengapa proyek tersebut dibuat, siapa penggunanya, bagaimana kondisi saat ini, dan seperti apa hasil yang dianggap berhasil.
Dengan konteks tersebut, vendor dapat memberikan estimasi, pendekatan teknis, timeline, serta kebutuhan resource yang lebih realistis.
Mengapa Project Brief Penting dalam IT Outsourcing?
Ketika perusahaan menyerahkan sebagian pekerjaan IT kepada vendor, ada jarak antara pihak yang memiliki masalah bisnis dan pihak yang mengerjakan solusi teknis.
Project brief membantu menjembatani jarak tersebut.
Tanpa brief yang jelas, beberapa masalah bisa muncul sejak awal:
- Vendor memiliki interpretasi berbeda mengenai kebutuhan proyek.
- Scope proyek terus berubah selama pengerjaan.
- Estimasi biaya dan timeline menjadi kurang akurat.
- Fitur penting terlewat karena belum dibahas sejak awal.
- Komunikasi antara perusahaan dan vendor menjadi lebih panjang.
- Proses kickoff tertunda karena banyak informasi masih harus dikumpulkan.
Sebaliknya, project brief yang terstruktur memungkinkan vendor memahami konteks proyek lebih cepat dan mengajukan pertanyaan yang lebih relevan.
Apa Saja yang Harus Ada dalam Project Brief IT?
Tidak ada satu format project brief yang berlaku untuk semua proyek. Namun, ada beberapa informasi penting yang sebaiknya selalu tersedia.
1. Project Overview
Mulailah dengan gambaran singkat mengenai proyek.
Tidak perlu langsung menjelaskan detail teknis. Cukup jelaskan apa proyeknya, mengapa proyek dibutuhkan, dan kondisi yang ingin diperbaiki.
Contohnya:
Perusahaan ingin membangun aplikasi internal untuk mengotomatisasi proses approval pengadaan yang saat ini masih dilakukan melalui email dan spreadsheet.
Dari satu paragraf tersebut, vendor sudah mendapatkan konteks awal mengenai proyek dan masalah yang ingin diselesaikan.
2. Business Problem
Bagian ini sering kali lebih penting daripada daftar fitur.
Jelaskan masalah yang sedang terjadi dan dampaknya terhadap bisnis.
Misalnya:
- Proses approval membutuhkan waktu terlalu lama.
- Data tersebar di beberapa spreadsheet.
- Sulit mengetahui status setiap pengajuan.
- Tim harus melakukan input data secara berulang.
- Tidak ada dashboard untuk memantau proses secara real-time.
Hindari hanya menulis "kami membutuhkan aplikasi procurement".
Vendor perlu mengetahui masalah di balik kebutuhan tersebut agar dapat mempertimbangkan solusi yang paling sesuai.
Prinsip ini juga banyak digunakan dalam project brief modern: brief sebaiknya menjelaskan problem dan outcome terlebih dahulu, bukan langsung mengunci solusi.
3. Project Objectives
Setelah masalah dijelaskan, tentukan apa yang ingin dicapai.
Tujuan sebaiknya spesifik dan sebisa mungkin dapat diukur.
Contohnya:
Mengurangi waktu proses approval pengadaan dari rata-rata tiga hari menjadi maksimal satu hari.
Tujuan seperti ini jauh lebih membantu vendor dibandingkan kalimat "membuat proses procurement lebih efisien".
Dengan objective yang jelas, vendor juga dapat mempertimbangkan apakah solusi yang ditawarkan benar-benar mampu menghasilkan outcome tersebut.
4. Target Users
Vendor perlu mengetahui siapa yang akan menggunakan sistem.
Jangan hanya menulis "karyawan".
Jelaskan pengguna utama dan kebutuhan masing-masing.
Misalnya:
- Procurement staff untuk membuat dan memproses pengajuan.
- Manager untuk melakukan approval.
- Finance untuk melakukan validasi anggaran.
- Management untuk memantau laporan.
Informasi ini membantu vendor memahami user journey dan menentukan kebutuhan sistem secara lebih tepat.
5. Current Process
Sebelum menjelaskan sistem yang ingin dibuat, jelaskan bagaimana proses berjalan saat ini.
Bagian ini dapat dibuat sederhana dalam bentuk alur:
Pengajuan → Review Procurement → Approval Manager → Validasi Finance → Selesai
Kemudian jelaskan bagian mana yang menjadi bottleneck.
Misalnya, approval manager sering terlambat karena permintaan dikirim melalui email dan tidak ada notifikasi otomatis.
Informasi seperti ini sangat membantu vendor memahami konteks operasional yang tidak selalu terlihat dari daftar fitur.
6. Scope of Work
Setelah konteksnya jelas, tentukan batas pekerjaan.
Scope menjelaskan apa saja yang termasuk dalam proyek dan apa yang tidak.
Contohnya:
In scope:
- Web application.
- User management.
- Approval workflow.
- Dashboard procurement.
- Notification.
- Integration dengan sistem ERP.
Out of scope:
- Mobile application.
- Pengembangan ERP baru.
- Migrasi seluruh historical data.
Bagian out of scope sering kali dilupakan, padahal sama pentingnya dengan daftar pekerjaan yang harus dilakukan.
Scope yang eksplisit membantu mengurangi risiko scope creep ketika proyek sudah berjalan.
7. Functional Requirements
Berikutnya, jelaskan fungsi utama yang harus tersedia.
Tidak perlu langsung menulis spesifikasi teknis yang sangat detail. Fokus pada apa yang harus dapat dilakukan pengguna.
Contohnya:
User dapat membuat purchase request dan mengirimkannya kepada approver berdasarkan nilai transaksi.
Kemudian:
Approver dapat melihat detail pengajuan, menyetujui atau menolak request, dan memberikan komentar.
Format seperti ini memberi vendor gambaran mengenai kebutuhan tanpa terlalu cepat menentukan bagaimana fungsi tersebut harus dibangun.
8. Technical Requirements
Jika perusahaan sudah memiliki persyaratan teknis tertentu, masukkan di bagian ini.
Contohnya:
- Sistem harus berjalan di cloud.
- Aplikasi harus menggunakan existing API.
- Sistem perlu terintegrasi dengan ERP.
- Database harus mengikuti standar perusahaan.
- Sistem harus mendukung Single Sign-On.
- Infrastruktur harus memenuhi standar keamanan internal.
Namun, bedakan antara requirement dan preferensi.
Jika perusahaan hanya terbiasa menggunakan teknologi tertentu tetapi terbuka terhadap alternatif, sampaikan sebagai preferensi.
Dengan begitu, vendor masih memiliki ruang untuk memberikan rekomendasi teknologi berdasarkan kebutuhan proyek.
9. Existing Systems dan Dependencies
Proyek IT jarang berdiri sendiri.
Biasanya ada sistem, database, API, vendor, atau tim internal lain yang perlu terlibat.
Masukkan informasi seperti:
- Sistem yang akan diintegrasikan.
- API yang sudah tersedia.
- Database existing.
- Cloud environment.
- Third-party services.
- Tim internal yang menjadi PIC.
- Akses yang sudah tersedia.
- Dependency dengan proyek lain.
Semakin awal dependency diketahui, semakin kecil kemungkinan vendor menemukan blocker setelah proyek dimulai.
10. Deliverables
Jelaskan apa yang diharapkan perusahaan terima dari vendor.
Deliverables bisa mencakup:
- UI/UX design.
- Source code.
- Web atau mobile application.
- API.
- Documentation.
- Test report.
- Deployment.
- Training.
- Knowledge transfer.
Jika ada acceptance criteria tertentu, masukkan juga ke dalam brief.
Misalnya:
Aplikasi dapat digunakan oleh minimal 500 concurrent users dengan response time maksimal tiga detik pada kondisi yang telah disepakati.
Acceptance criteria membuat kedua pihak memiliki definisi yang lebih jelas mengenai "selesai".
11. Timeline dan Milestone
Vendor juga membutuhkan gambaran mengenai kapan proyek diharapkan dimulai dan selesai.
Daripada hanya menulis:
Project selesai dalam tiga bulan.
Lebih baik pecah menjadi beberapa milestone:
- Discovery: 2 minggu.
- UI/UX: 2 minggu.
- Development: 6 minggu.
- Testing dan UAT: 2 minggu.
- Deployment: 1 minggu.
Timeline awal tidak harus sempurna. Yang penting, vendor mengetahui target perusahaan dan dapat memberikan feedback apakah target tersebut realistis.
12. Budget atau Budget Range
Tidak semua perusahaan nyaman mencantumkan budget sejak awal.
Namun, jika memungkinkan, memberikan budget range dapat membantu vendor memberikan proposal yang lebih relevan.
Vendor dapat menyesuaikan:
- Scope.
- Resource.
- Technology.
- Timeline.
- Delivery approach.
Jika budget belum ditentukan, perusahaan dapat menuliskan bahwa estimasi diharapkan berasal dari vendor berdasarkan scope yang diberikan.
13. Success Metrics
Bagian ini menjawab pertanyaan sederhana: bagaimana perusahaan tahu bahwa proyek ini berhasil?
Success metric dapat berupa:
- Pengurangan waktu proses.
- Penurunan error.
- Peningkatan user adoption.
- Pengurangan pekerjaan manual.
- Peningkatan system availability.
- Peningkatan transaction volume.
Misalnya, tujuan proyek bukan sekadar "membangun aplikasi procurement", tetapi:
Mengurangi pekerjaan manual tim procurement sebesar 50% dalam tiga bulan setelah implementasi.
Dengan begitu, vendor memahami bahwa keberhasilan proyek tidak hanya diukur dari apakah aplikasi selesai dibuat.
Template Project Brief IT yang Bisa Digunakan
Agar lebih praktis, struktur berikut dapat digunakan sebagai template awal.
Project Brief
1. Project Name
Nama proyek.
2. Background
Mengapa proyek ini dibutuhkan?
3. Business Problem
Masalah apa yang sedang terjadi?
4. Project Objectives
Apa yang ingin dicapai?
5. Target Users
Siapa pengguna utama?
6. Current Process
Bagaimana proses berjalan saat ini?
7. Project Scope
Apa yang termasuk dan tidak termasuk dalam proyek?
8. Functional Requirements
Fungsi utama apa yang dibutuhkan?
9. Technical Requirements
Apakah ada requirement teknologi tertentu?
10. Existing Systems & Dependencies
Sistem apa yang perlu diintegrasikan?
11. Deliverables
Apa yang harus diserahkan vendor?
12. Timeline & Milestones
Kapan proyek dimulai dan apa target setiap tahap?
13. Budget
Berapa budget atau budget range yang tersedia?
14. Success Metrics
Bagaimana keberhasilan proyek akan diukur?
15. Project PIC
Siapa stakeholder dan pengambil keputusan utama?
Format ini sengaja dibuat cukup ringkas agar bisa menjadi starting point sebelum masuk ke dokumen yang lebih detail seperti Statement of Work atau technical specification.
Tips Agar Vendor Bisa Langsung Memahami Project Brief
Project brief yang lengkap belum tentu menjadi brief yang efektif. Ada beberapa hal yang perlu diperhatikan sebelum mengirimkannya kepada vendor.
Gunakan Bahasa yang Jelas
Hindari jargon internal yang hanya dipahami oleh tim tertentu.
Jika ada istilah khusus, berikan definisinya. Tujuannya agar vendor dan tim internal memiliki pemahaman yang sama.
Bedakan Must-Have dan Nice-to-Have
Tidak semua fitur memiliki tingkat prioritas yang sama.
Pisahkan kebutuhan menjadi:
- Must-have: harus tersedia agar proyek dianggap berhasil.
- Should-have: penting tetapi masih bisa disesuaikan.
- Could-have: dapat dikerjakan jika waktu dan budget memungkinkan.
- Out of scope: tidak termasuk dalam proyek.
Pendekatan seperti ini membantu vendor membuat prioritas dan memberikan estimasi yang lebih realistis.
Jangan Mengunci Solusi Terlalu Cepat
Perusahaan biasanya lebih tahu masalah bisnisnya. Vendor mungkin memiliki pengalaman lebih luas mengenai solusi teknis yang bisa digunakan.
Karena itu, hindari brief seperti:
"Kami membutuhkan aplikasi dengan React, Node.js, Kubernetes, dan PostgreSQL."
Jika teknologi tersebut memang wajib digunakan, tentu harus disebutkan. Namun, jika sebenarnya perusahaan hanya membutuhkan sistem yang scalable dan mudah diintegrasikan, berikan requirement tersebut dan biarkan vendor memberikan rekomendasi teknis.
Sertakan Informasi yang Masih Belum Pasti
Tidak semua hal harus sudah diketahui ketika project brief dibuat.
Jika ada informasi yang belum final, tuliskan secara terbuka.
Contohnya:
"Integrasi dengan ERP masih dalam tahap assessment."
Hal ini lebih baik daripada membuat asumsi yang nantinya menjadi masalah ketika proyek berjalan.
Brief yang baik bukan dokumen yang berpura-pura sudah memiliki semua jawaban. Brief yang baik justru membantu vendor mengetahui apa yang sudah pasti, apa yang masih terbuka, dan pertanyaan apa yang perlu dibahas lebih lanjut.
Checklist Sebelum Project Brief Dikirim ke Vendor
Sebelum mengirimkan project brief, lakukan pengecekan sederhana:
- Apakah masalah bisnis sudah dijelaskan?
- Apakah tujuan proyek sudah jelas?
- Apakah target user sudah diketahui?
- Apakah scope dan out of scope sudah dibedakan?
- Apakah requirement utama sudah ditentukan?
- Apakah existing system dan dependency sudah dicantumkan?
- Apakah deliverables sudah jelas?
- Apakah timeline dan milestone sudah tersedia?
- Apakah success metric sudah ditentukan?
- Apakah PIC dan decision maker sudah diketahui?
- Apakah requirement wajib sudah dibedakan dari preferensi?
- Apakah ada informasi penting yang masih berupa asumsi?
Jika sebagian besar pertanyaan tersebut sudah terjawab, vendor akan memiliki konteks yang jauh lebih baik untuk memberikan proposal.
Butuh Partner IT untuk Menjalankan Project Anda?
Project brief yang baik akan membantu vendor memahami kebutuhan, tetapi keberhasilan implementasi tetap bergantung pada kualitas talent dan tim yang menjalankannya.
Jika perusahaan membutuhkan tambahan talenta IT untuk mengembangkan produk, melakukan maintenance, atau menjalankan proyek digital tanpa harus membangun tim dari awal, BINAR IT Outsourcing dapat membantu menyediakan talent sesuai kebutuhan proyek.
Dengan BINAR, perusahaan dapat memperoleh:
- 3.000+ IT talent terkurasi untuk berbagai kebutuhan teknologi.
- Talent yang disesuaikan dengan role, tech stack, dan senioritas yang dibutuhkan.
- Technical screening dan human validation sebelum talent ditempatkan.
- Monitoring dan pengelolaan kinerja talent selama bekerja dengan tim perusahaan.
- Garansi replacement hingga 30 hari jika talent tidak sesuai kebutuhan.
- Proses penempatan yang lebih cepat, sehingga perusahaan dapat segera menambah kapasitas tim IT.
Dengan dukungan talent yang tepat, tim internal dapat lebih fokus pada kebutuhan bisnis sementara pekerjaan teknis dapat ditangani oleh resource yang sesuai dengan kebutuhan proyek.
Jika Anda sudah memiliki project brief dan membutuhkan tambahan IT talent untuk menjalankannya, pelajari lebih lanjut tentang BINAR IT Outsourcing.