Project Scope Statement: Definisi, Contoh, dan Template

Project scope statement adalah dokumen yang mengubah ide proyek yang samar-samar menjadi kesepakatan bersama yang ditandatangani tentang apa yang akan dibangun tim, apa yang tidak akan disentuh, dan seperti apa "selesai" itu. Tanpa dokumen ini, setiap permintaan fitur baru atau keinginan pemangku kepentingan terasa sangat masuk akal, dan jadwal Anda perlahan hancur tanpa disadari.

Apa itu project scope statement?

Key Facts

• Menurut PMBOK edisi ke-7, scope statement adalah dasar dari garis dasar ruang lingkup proyek dan menjadi acuan WBS, jadwal, dan anggaran (PMI, 2021).
• 52% proyek mengalami scope creep, dan penyebab utamanya adalah scope statement yang tidak jelas atau tidak ada saat kickoff (PMI Pulse of the Profession, 2024).
• Proyek dengan scope statement yang ditandatangani saat kickoff 39% lebih mungkin memenuhi anggaran awal mereka (Standish Group CHAOS Report, 2024).

Project scope statement adalah dokumen formal yang mendefinisikan batas-batas lengkap sebuah proyek: pekerjaan apa yang termasuk, apa yang secara eksplisit dikecualikan, hasil kerja apa yang akan diproduksi, dan kriteria yang menentukan apakah setiap hasil kerja telah diselesaikan dengan dapat diterima. Dokumen ini dibuat selama fase perencanaan dan menjadi titik referensi untuk setiap keputusan terkait ruang lingkup sepanjang siklus hidup proyek.

Bayangkan ini sebagai kontrak antara tim proyek dan pemangku kepentingannya. Dokumen ini menjawab tiga pertanyaan yang, jika dibiarkan tidak terjawab, pasti menimbulkan masalah:

• Apa yang akan dihasilkan proyek ini?
• Apa yang tidak akan dihasilkan proyek ini?
• Bagaimana kita tahu kapan setiap hasil kerja selesai?

Scope statement langsung berkontribusi ke struktur rincian kerja, yang memecah hasil kerja menjadi tugas-tugas yang dapat dieksekusi. Dokumen ini juga menjadi jangkar jadwal, anggaran, dan proses kontrol perubahan. Ubah apa pun tentang ruang lingkup, dan setiap rencana yang berasal dari sana perlu ditinjau kembali.

Mengapa scope statement penting

Scope creep adalah penyebab paling umum proyek melebihi anggaran dan melewati tenggat waktu. Ini terjadi secara bertahap: seorang pemangku kepentingan meminta "satu tambahan kecil saja," tim mengatakan ya, dan enam minggu kemudian proyek 40% lebih besar dari yang direncanakan semula sementara tim sudah kelelahan.

Scope statement yang ditandatangani tidak mencegah orang meminta perubahan. Yang dilakukannya adalah memberi manajer proyek garis dasar yang terdokumentasi sebagai acuan. Ketika permintaan baru datang, tim dapat mengevaluasinya terhadap pernyataan tersebut dan berkata dengan jelas, "Itu di luar ruang lingkup yang telah disepakati. Kita bisa menambahkannya, tetapi inilah dampaknya pada jadwal dan anggaran." Percakapan itu jauh lebih mudah daripada mencoba mengingat apa yang disepakati secara informal saat kickoff.

Scope statement juga berfungsi untuk menyelaraskan pemangku kepentingan. Ketika eksekutif, klien, dan tim delivery semua membaca dan menandatangani dokumen yang sama sebelum pekerjaan dimulai, ekspektasi yang tidak sesuai muncul lebih awal, saat murah untuk diperbaiki, bukan terlambat saat sudah mahal.

Keselarasan ini sangat berharga pada proyek yang menggunakan metodologi agile, di mana Backlog sering berubah. Bahkan tim agile mendapat manfaat dari batas ruang lingkup tingkat tinggi yang mencegah pertumbuhan Backlog produk yang tidak terkendali.

Apa yang ada di dalam scope statement (7 komponen)

Scope statement yang lengkap mencakup tujuh area. Melewatkan salah satu dari area tersebut cenderung menciptakan celah yang dimanfaatkan scope creep untuk masuk.

1. Tujuan proyek -- Hasil yang terukur yang harus dicapai proyek. Tujuan harus spesifik dan terikat waktu. "Meluncurkan situs web yang didesain ulang pada 31 Agustus yang mengurangi bounce rate halaman beranda sebesar 15%" adalah tujuan proyek. "Meningkatkan situs web" bukanlah tujuan proyek.

2. Hasil kerja -- Output nyata yang akan dihasilkan proyek. Untuk desain ulang situs web, ini mungkin mencakup halaman beranda baru, lima template halaman interior, panduan gaya, dan dokumen pelatihan CMS. Cantumkan setiap hasil kerja berdasarkan nama agar tidak ada yang diasumsikan.

3. Kriteria penerimaan -- Kondisi spesifik yang harus dipenuhi setiap hasil kerja agar dianggap selesai dan disetujui. Kriteria penerimaan menghilangkan subjektivitas. "Halaman beranda memuat dalam waktu di bawah 2,5 detik pada koneksi 4G" adalah kriteria penerimaan. "Halaman beranda harus terasa cepat" bukan.

4. Item dalam ruang lingkup -- Pekerjaan, fitur, sistem, dan proses yang akan ditangani proyek. Bagian ini mencegah tim secara tidak sengaja mengabaikan hal-hal yang seharusnya termasuk.

5. Item di luar ruang lingkup -- Pekerjaan, fitur, dan sistem yang secara eksplisit tidak akan ditangani proyek. Ini bisa dibilang bagian terpenting. Mendokumentasikan apa yang tidak Anda lakukan adalah hal yang memberi Anda wewenang untuk mengatakan tidak di kemudian hari.

6. Batasan -- Keterbatasan yang diketahui di mana proyek harus beroperasi: batas anggaran, tenggat waktu yang tetap, tumpukan teknologi tertentu, persyaratan regulasi, ukuran tim. Batasan tidak hilang dengan mengabaikannya; menuliskannya berarti semua orang merencanakan berdasarkan kenyataan yang sama.

7. Asumsi -- Kondisi yang diasumsikan tim sebagai kebenaran saat ruang lingkup didefinisikan. Jika asumsi apa pun ternyata salah, ruang lingkup harus ditinjau kembali. Misalnya: "Kami mengasumsikan klien akan menyediakan semua aset merek pada 15 Juni." Jika aset tersebut tiba dua minggu terlambat, jadwal pun berubah.

Scope statement vs piagam proyek vs WBS

Ketiga dokumen ini saling berkaitan erat dan sering dikacaukan satu sama lain. Berikut perbedaannya:

Piagam datang pertama dan bersifat luas. Scope statement mengisi detail selama perencanaan proyek. WBS kemudian mengambil hasil kerja tersebut dan menguraikannya menjadi pekerjaan yang dapat dijadwalkan.

Tidak ada dokumen ini yang menggantikan yang lain. Piagam tanpa scope statement meninggalkan terlalu banyak ruang untuk interpretasi. Scope statement tanpa WBS tetap terlalu abstrak untuk dieksekusi oleh tim.

Cara menulis project scope statement: langkah demi langkah

Langkah 1: Tinjau piagam proyek

Mulailah dengan apa yang sudah disetujui. Piagam berisi tujuan proyek yang dinyatakan, tujuan sponsor, dan batasan yang diketahui. Scope statement Anda harus konsisten dengan piagam, bukan bertentangan. Ambil tujuan dan gunakan secara verbatim atau perbaiki menjadi bentuk yang terukur.

Langkah 2: Daftarkan semua hasil kerja

Bekerja sama dengan tim dan pemangku kepentingan utama untuk mendaftarkan semua yang akan dihasilkan proyek. Jangan hanya mencantumkan output akhir; sertakan hasil kerja perantara seperti prototipe, laporan pengujian, dan materi pelatihan. Gunakan frasa kata benda ("Halaman beranda responsif mobile," "Laporan pengujian penerimaan pengguna") daripada tugas ("Bangun halaman beranda," "Jalankan pengujian"). Hasil kerja adalah benda, bukan aktivitas.

Langkah 3: Definisikan kriteria penerimaan untuk setiap hasil kerja

Untuk setiap hasil kerja, tuliskan seperti apa "disetujui" itu. Libatkan pemangku kepentingan yang akan menandatangani hasil kerja tersebut, karena definisi "selesai" mereka mungkin berbeda dari Anda. Mendapatkan ini secara tertulis sekarang mencegah pengerjaan ulang di kemudian hari.

Langkah 4: Tentukan batas di luar ruang lingkup

Ini adalah langkah yang paling sering dilewatkan tim dan kemudian disesali. Tinjau setiap hasil kerja dan tanyakan: pekerjaan apa yang berdekatan yang mungkin diasumsikan pemangku kepentingan sudah termasuk? Tuliskan hal-hal tersebut secara eksplisit sebagai di luar ruang lingkup. Jika proyek Anda adalah desain ulang situs web, mungkin ada godaan bagi pemasaran untuk mengasumsikan audit SEO sudah termasuk. Jika tidak, katakan demikian.

Bagian ini juga berpadu baik dengan proses matriks RACI: Anda sering menemukan item di luar ruang lingkup ketika mencoba menetapkan tanggung jawab untuk pekerjaan yang tidak secara formal ada dalam rencana.

Langkah 5: Catat batasan dan asumsi

Cantumkan setiap batasan nyata (anggaran, tenggat waktu, teknologi, jumlah staf). Kemudian cantumkan setiap asumsi yang Anda andalkan. Jujurlah tentang keduanya. Tim sering menghindari menulis asumsi karena terasa seperti mengakui ketidakpastian. Namun asumsi yang tidak tertulis adalah risiko tersembunyi. Tuliskan dan buat rencana untuk memvalidasinya sejak awal.

Langkah 6: Dapatkan persetujuan pemangku kepentingan

Scope statement yang tidak ditandatangani siapapun hanyalah draft. Edarkan ke sponsor proyek, pemangku kepentingan utama, dan tim delivery. Selesaikan ketidaksepakatan sebelum penandatanganan, bukan sesudahnya. Setelah ditandatangani, dokumen ini menjadi garis dasar yang digunakan untuk mengukur permintaan perubahan.

Template project scope statement

Salin dan sesuaikan template ini untuk proyek Anda:

PROJECT SCOPE STATEMENT

Nama proyek: [Nama proyek] Manajer proyek: [Nama PM] Tanggal disetujui: [Tanggal] Versi: [1.0]

---

Tujuan proyek [Nyatakan 2-4 hasil yang terukur yang harus dicapai proyek, masing-masing terkait dengan metrik dan tenggat waktu.]

Hasil kerja

1. [Nama hasil kerja] -- [Deskripsi singkat]
2. [Nama hasil kerja] -- [Deskripsi singkat]
3. [Nama hasil kerja] -- [Deskripsi singkat]

Kriteria penerimaan

• [Hasil kerja 1]: [Kondisi spesifik dan terukur untuk persetujuan]
• [Hasil kerja 2]: [Kondisi spesifik dan terukur untuk persetujuan]
• [Hasil kerja 3]: [Kondisi spesifik dan terukur untuk persetujuan]

Dalam ruang lingkup

• [Pekerjaan, fitur, atau sistem yang termasuk]
• [Pekerjaan, fitur, atau sistem yang termasuk]

Di luar ruang lingkup

• [Pekerjaan, fitur, atau sistem yang secara eksplisit dikecualikan]
• [Pekerjaan, fitur, atau sistem yang secara eksplisit dikecualikan]

Batasan

• Anggaran: [Jumlah atau batas]
• Jadwal: [Tanggal akhir tetap atau batasan]
• Teknologi: [Alat/platform yang diperlukan atau dilarang]
• Sumber daya: [Batasan jumlah staf atau keahlian]

Asumsi

• [Kondisi yang diasumsikan benar]
• [Kondisi yang diasumsikan benar]

Persetujuan

Peran	Nama	Tanda tangan	Tanggal
Sponsor proyek
Manajer proyek
Pemangku kepentingan utama

Contoh project scope statement

Berikut bagaimana empat jenis proyek umum dipecah berdasarkan hasil kerja, in-scope, dan out-of-scope:

Perhatikan bagaimana setiap kolom "di luar ruang lingkup" mendokumentasikan pekerjaan yang berdekatan yang umumnya diasumsikan pemangku kepentingan sudah termasuk. Kekhususan itulah yang menjadi inti dari dokumen ini. Pengecualian yang samar tidak melindungi siapapun.

Untuk proyek yang menggunakan Scrum, scope statement berada di tingkat epic. Ruang lingkup Sprint individual dikelola melalui Backlog, tetapi batas tingkat tinggi tetap berlaku.

Cara mencegah scope creep dengan scope statement

Scope statement hanya sekuat proses kontrol perubahan yang menegakkannya. Berikut lima cara untuk membuatnya berhasil dalam praktik:

1. Referensikan dalam setiap status meeting. Jangan biarkan scope statement tersimpan dalam folder dan terlupakan. Buka setiap panggilan status mingguan dengan pengingat 60 detik tentang apa yang masuk ruang lingkup dan apa yang tidak. Ini menjaga garis dasar tetap segar dalam pikiran pemangku kepentingan sebelum mereka mengajukan permintaan baru.

2. Gunakan sebagai filter untuk permintaan perubahan. Ketika seorang pemangku kepentingan meminta pekerjaan baru, mulailah dengan memeriksanya terhadap ruang lingkup yang disetujui. Jika di luar ruang lingkup, jangan langsung katakan tidak. Katakan, "Itu di luar scope statement kami saat ini. Mari kita evaluasi dampaknya." Kemudian jalankan permintaan perubahan formal dengan estimasi yang direvisi. Ini menunjukkan itikad baik tanpa diam-diam menyerap pekerjaan ekstra.

3. Tunjuk daftar di luar ruang lingkup berdasarkan nama. Ketika seseorang meminta sesuatu yang secara eksplisit tercantum sebagai di luar ruang lingkup, referensikan dokumen tersebut: "Kita sebenarnya telah mencatat itu di bagian 4 scope statement sebagai di luar ruang lingkup, karena menambahkannya akan memerlukan X. Apakah Anda ingin membuka permintaan perubahan?" Kekhususan menghilangkan ambiguitas dan menjaga percakapan tetap profesional.

4. Perlakukan perubahan asumsi sebagai pemicu ruang lingkup. Jika asumsi yang dinyatakan ternyata salah, segera nilai kembali ruang lingkup. Tim sering menyerap kegagalan asumsi secara diam-diam, menyesuaikan pekerjaan mereka tanpa meninjau kembali perjanjian formal. Begitulah scope creep masuk melalui pintu belakang.

5. Padukan dengan analisis Gantt chart atau jalur kritis. Ketika pemangku kepentingan melihat dampak jadwal dari penambahan ruang lingkup baru, keberatan abstrak menjadi konkret. "Jika kita menambahkan integrasi CRM, tanggal peluncuran bergeser dari 1 Oktober ke 14 November" adalah argumen yang jauh lebih meyakinkan daripada "itu di luar ruang lingkup."

6. Kaitkan perubahan ruang lingkup dengan persetujuan anggaran. Setiap perubahan yang menambah pekerjaan harus memicu tinjauan anggaran. Ketika ruang lingkup ekstra memiliki angka dolar yang melekat, pemangku kepentingan mempertimbangkannya dengan lebih cermat. Perubahan kecil terasa tidak berbahaya secara terpisah; baris anggaran membuat biaya kumulatifnya terlihat.

Kesalahan umum

Praktik terbaik

• Tulis bagian di luar ruang lingkup sebelum menulis yang masuk. Mulai dengan pengecualian memaksa kejelasan tentang apa yang bukan proyek, yang membuat inklusi menjadi lebih tajam.
• Jaga hasil kerja pada tingkat detail yang tepat: cukup spesifik untuk tidak ambigu, tetapi tidak begitu terperinci sehingga termasuk dalam WBS. Targetkan 5-15 hasil kerja per proyek.
• Kendalikan versi dokumen. Ketika ruang lingkup berubah, perbarui nomor versi dan tanggal. Simpan versi sebelumnya agar Anda dapat melacak apa yang berubah dan mengapa.
• Kaitkan scope statement dengan matriks RACI. Setiap hasil kerja harus memiliki pemilik yang jelas; jika hasil kerja tidak memiliki pemilik, kemungkinan besar itu di luar ruang lingkup.
• Untuk proyek waterfall, bekukan scope statement sebelum perencanaan terperinci dimulai. Untuk proyek agile, perlakukan sebagai output sprint-zero yang hidup yang menetapkan batas luar tanpa mengunci Backlog.
• Gunakan bahasa yang mudah dipahami. Scope statement gagal ketika ditulis dalam bahasa hukum yang dilewati pemangku kepentingan daripada dibaca. Tuliskan sehingga anggota tim baru dapat mengambilnya pada hari pertama dan memahami dengan tepat apa proyek ini.
• Lampirkan scope statement yang ditandatangani ke setiap laporan status proyek agar tetap terlihat selama delivery.
• Tinjau asumsi di setiap gerbang fase. Jika asumsi telah dibatalkan, sampaikan segera daripada membiarkan tim menyerap dampaknya secara diam-diam.

Pertanyaan yang sering diajukan

Apa perbedaan antara scope statement dan scope baseline? Scope statement adalah deskripsi tertulis dari batas-batas proyek: hasil kerja, pengecualian, kriteria penerimaan, batasan, dan asumsi. Scope baseline adalah versi scope statement yang secara resmi disetujui ditambah WBS dan kamus WBS. Garis dasar adalah hal yang Anda ukur kinerjanya dan yang dilindungi oleh kontrol perubahan. Anda menulis scope statement terlebih dahulu; itu menjadi garis dasar setelah disetujui.

Siapa yang menulis project scope statement? Manajer proyek memiliki scope statement, tetapi tidak boleh dituliskan sendirian. Scope statement yang efektif dibuat bersama dengan tim proyek (yang tahu apa yang realistis untuk diserahkan), pemangku kepentingan utama (yang tahu seperti apa keberhasilan), dan pakar materi (yang tahu apa yang layak secara teknis). Tugas PM adalah memfasilitasi percakapan tersebut dan mengkonsolidasikan hasilnya menjadi dokumen yang bersih.

Apakah scope statement bisa berubah di tengah proyek? Ya, tetapi hanya melalui proses kontrol perubahan formal. Jika pemangku kepentingan mengidentifikasi kebutuhan yang sah yang mengubah ruang lingkup, manajer proyek mengevaluasi dampak pada biaya, jadwal, dan sumber daya, mendokumentasikannya dalam permintaan perubahan, dan mendapatkan persetujuan sebelum memperbarui scope statement. Perubahan ruang lingkup yang informal adalah cara persis bagaimana scope creep terjadi.

Seberapa detail scope statement seharusnya? Cukup detail untuk menghilangkan ambiguitas, tetapi tidak begitu detail sehingga terbaca seperti spesifikasi teknis. Aturan praktis yang baik: jika dua pemangku kepentingan berbeda dapat membaca satu bagian dan mendapat interpretasi berbeda tentang apa yang termasuk, itu perlu lebih banyak detail. Jika bagian tersebut lebih dari dua paragraf dan mencakup detail implementasi, kemungkinan besar termasuk dalam dokumen teknis terpisah yang ditautkan dari scope statement.

Apakah scope statement sama dengan statement of work (SOW)? Tidak. Statement of work (SOW) adalah kontrak yang mengikat secara hukum antara dua organisasi (biasanya klien dan vendor) yang mendefinisikan layanan yang akan diberikan, jadwal, ketentuan pembayaran, dan kewajiban. Project scope statement adalah dokumen perencanaan internal yang mendefinisikan apa yang akan dibangun tim proyek. SOW mungkin menginformasikan scope statement, tetapi keduanya melayani tujuan yang berbeda dan memiliki audiens yang berbeda.

Penutup

Project scope statement bukan dokumen paling menarik yang akan Anda tulis dalam sebuah proyek. Tetapi kemungkinan besar itulah yang menentukan apakah proyek berhasil atau perlahan hancur. Setengah jam yang Anda habiskan untuk menulis daftar di luar ruang lingkup yang tepat saat kickoff jauh lebih berharga daripada jam-jam yang akan Anda habiskan dalam negosiasi scope-change enam bulan kemudian.

Tulis lebih awal. Dapatkan tanda tangan. Referensikan sesering mungkin. Dan ketika seseorang meminta "satu tambahan kecil saja," perlakukan scope statement sebagai sekutu Anda, bukan hambatan birokrasi. Dokumen itulah alasan tim dapat mengatakan ya untuk hal-hal yang tepat dan tidak untuk sisanya.

Untuk langkah selanjutnya setelah pendefinisian ruang lingkup, bangun struktur rincian kerja Anda untuk mengurai hasil kerja tersebut menjadi tugas-tugas yang dapat dijadwalkan. Kemudian gunakan teknik perencanaan proyek untuk mengurutkan dan menempatkan sumber daya sebelum kickoff.