Extracted Pages From PMI Project Management Body of Knowledge PMBoK 151-200 Id

Subscribe to DeepL Pro to translate larger documents.
Visit www.DeepL.com/pro for more information.
Rencana Perusahaan 4.3

Manajemen /Organisasi Mengarahka
Proyek n dan
• Permintaan perubahan yang disetujui Mengelola
• Faktor Pekerjaan
lingkungan Proyek
Rencana manajemen proyek perusahaan
• Rencana manajemen perubahan • Aset proses
• Rencana manajemen konfigurasi organisasi 8.3
• Cakupan dasar Kualitas
• Jadwalkan garis dasar • Permintaan perubahan yang disetujui Kontrol
• Garis dasar biaya
Dokume 12.3
n Proyek Pengadaan
• Permintaan perubahan yang disetujui Kontrol
Dokumen proyek
• Dasar estimasi-
• Matriks penelusuran persyaratan Rencana
• Laporan risiko Manajemen
Pembaruan Proyek
rencana
4.5 manajemen proyek
Memantau • Komponen apa
dan 4.6
saja
Mengendalik Melakukan
an Pekerjaan Pengendalian
- Piagam
Proyek Perubahanproyek
Terpadu Dokume
• Laporan prestasi kerja n Proyek
• Permintaan perubahan Pembaruan dokumen
proyek
• Ubah log
• Permintaan
perubahan
4.3 13.4
9.3 10.3 12.1
Mengarahka Memantau
n dan Memperol Memantau Merencanakan Keterlibatan
Mengelola eh Komunikasi Manajemen Pemangku
Pekerjaan Sumber Pengadaan Kepentingan
Proyek Daya
5.5 9.4 11.5 12.2

Memvalidasi Kembangka Merencanakan Melakukan
Ruang n Tim Tanggapan Risiko Pengadaan
Lingkup
5.6. 9.5 11.6 12.3

Lingkup Kelola Tim Menerapkan Pengadaan
Kontrol Tanggapan Risiko Kontrol
6.6 9.6 11.7 13.1

Jadwal Sumber Memantau Identifikasi
Kontrol Daya Kontrol Risiko Pemangku
Kepentingan
13.3
7.4. 8.2 8.3
Mengelola
Biaya Mengelola Kualitas Keterlibatan
Pengendali Kualitas Kontrol Pemangku
an Kepentingan
Bagian 1 -
114
Panduan
Gambar 4-13. Melakukan Kontrol Perubahan Terpadu: Diagram Aliran Data
115
Proses Perform Integrated Change Control dilakukan sejak awal hingga akhir proyek dan merupakan tanggung
jawab utama manajer proyek. Permintaan perubahan dapat berdampak pada ruang lingkup proyek dan ruang lingkup
produk, serta komponen rencana manajemen proyek atau dokumen proyek apa pun. Perubahan dapat diminta oleh
pemangku kepentingan yang terlibat dalam proyek dan dapat terjadi kapan saja sepanjang siklus hidup proyek.
Tingkat kontrol perubahan yang diterapkan tergantung pada area aplikasi, kompleksitas proyek tertentu,
persyaratan kontrak, serta konteks dan lingkungan tempat proyek dilakukan.
Sebelum baseline ditetapkan, perubahan tidak perlu dikontrol secara formal oleh proses Perform Integrated
Change Control. Setelah proyek ditetapkan, permintaan perubahan harus melalui proses ini. Sebagai aturan umum,
rencana manajemen konfigurasi setiap proyek harus mendefinisikan artefak proyek mana yang perlu ditempatkan di
bawah kontrol konfigurasi. Setiap perubahan dalam elemen konfigurasi harus dikontrol secara formal dan
memerlukan permintaan perubahan.
Meskipun perubahan dapat dimulai secara lisan, perubahan tersebut harus dicatat dalam bentuk tertulis dan
dimasukkan ke dalam manajemen perubahan dan/atau sistem manajemen konfigurasi. Permintaan perubahan
mungkin memerlukan informasi tentang perkiraan dampak jadwal dan perkiraan dampak biaya sebelum disetujui.
Kapan pun permintaan perubahan dapat berdampak pada salah satu baseline proyek, proses kontrol perubahan
terintegrasi yang formal selalu diperlukan. Setiap permintaan perubahan yang didokumentasikan harus disetujui,
ditunda, atau ditolak oleh individu yang bertanggung jawab, biasanya sponsor proyek atau manajer proyek. Individu
yang bertanggung jawab akan diidentifikasi dalam rencana manajemen proyek atau dengan prosedur organisasi. Jika
diperlukan, proses Perform Integrated Change Control mencakup change control board (CCB), yang merupakan
kelompok yang disewa secara resmi yang bertanggung jawab untuk meninjau, mengevaluasi, menyetujui, menunda, atau
menolak perubahan pada proyek dan untuk mencatat dan mengkomunikasikan keputusan tersebut.
Permintaan perubahan yang disetujui dapat memerlukan estimasi biaya baru atau revisi, urutan kegiatan, tanggal
jadwal, kebutuhan sumber daya, dan/atau analisis alternatif respons risiko. Perubahan ini dapat memerlukan
penyesuaian pada rencana manajemen proyek dan dokumen proyek lainnya. Persetujuan pelanggan atau sponsor
mungkin diperlukan untuk permintaan perubahan tertentu setelah persetujuan CCB, kecuali jika permintaan tersebut
merupakan bagian dari CCB.
◻
◻
Bagian 1 -
116
Panduan
4.6.1 MELAKUKAN KONTROL PERUBAHAN TERINTEGRASI: MASUKAN
4.6.1.1 RENCANA MANAJEMEN PROYEK
Dijelaskan dalam Bagian 4.2.3.1. Komponen rencana manajemen proyek termasuk namun tidak terbatas pada:
◆ Rencana manajemen perubahan. Dijelaskan di Bagian 4.2.3.1. Rencana manajemen perubahan memberikan
arahan untuk mengelola proses pengendalian perubahan dan mendokumentasikan peran dan tanggung
jawab dewan pengendalian perubahan (CCB).
◆ Rencana manajemen konfigurasi. Dijelaskan di Bagian 4.2.3.1. Rencana manajemen konfigurasi menjelaskan
item-item yang dapat dikonfigurasi dari proyek dan mengidentifikasi item-item yang akan dicatat dan
diperbarui sehingga produk proyek tetap konsisten dan dapat dioperasikan.
◆ Cakupan dasar. Dijelaskan di Bagian 5.4.3.1. Garis dasar ruang lingkup menyediakan definisi proyek dan produk.
◆ Jadwal baseline. Dijelaskan di Bagian 6.5.3.1. Baseline jadwal digunakan untuk menilai dampak dari
perubahan jadwal proyek.
◆ Garis dasar biaya. Dijelaskan di Bagian 7.3.3.1. Garis dasar biaya digunakan untuk menilai dampak
perubahan terhadap biaya proyek.
4.6.1.2 DOKUMEN PROYEK
Dokumen proyek yang dapat dipertimbangkan sebagai masukan untuk proses ini termasuk namun tidak terbatas pada:
◆ Dasar estimasi. Dijelaskan dalam Bagian 6.4.3.2. Dasar estimasi menunjukkan bagaimana estimasi durasi,
biaya, dan sumber daya diperoleh dan dapat digunakan untuk menghitung dampak perubahan waktu,
anggaran, dan sumber daya.
◆ Matriks ketertelusuran persyaratan. Dijelaskan di Bagian 5.2.3.2. Matriks penelusuran persyaratan
membantu menilai dampak perubahan pada ruang lingkup proyek.
◆ Laporan risiko. Dijelaskan di Bagian 11.2.3.2. Laporan risiko menyajikan informasi tentang sumber risiko
proyek secara keseluruhan dan individu yang terlibat dalam perubahan yang diminta.
4.6.1.3 LAPORAN PRESTASI KERJA
Dijelaskan di Bagian 4.5.3.1. Laporan kinerja pekerjaan yang menjadi perhatian khusus dalam proses Perform Integrated
Change Control meliputi ketersediaan sumber daya, data jadwal dan biaya, laporan nilai yang diperoleh, dan grafik burnup
atau burndown.
117
4.6.1.4 PERMINTAAN PERUBAHAN
Banyak proses yang menghasilkan permintaan perubahan sebagai output. Permintaan perubahan (dijelaskan di
Bagian 4.3.3.4) dapat mencakup tindakan korektif, tindakan pencegahan, perbaikan cacat, serta pembaruan pada
dokumen atau hasil kerja yang dikontrol secara formal untuk mencerminkan ide atau konten yang dimodifikasi atau
tambahan. Perubahan mungkin berdampak atau tidak berdampak pada baseline proyek - terkadang hanya kinerja
terhadap baseline yang terpengaruh. Keputusan tentang perubahan tersebut biasanya dibuat oleh manajer
proyek.
Permintaan perubahan yang berdampak pada garis dasar proyek biasanya harus menyertakan informasi tentang
biaya pelaksanaan perubahan, modifikasi tanggal yang dijadwalkan, kebutuhan sumber daya, dan risiko. Perubahan
ini harus disetujui oleh CCB (jika ada) dan oleh pelanggan atau sponsor, kecuali jika perubahan tersebut merupakan
bagian dari CCB. Hanya perubahan yang disetujui yang boleh dimasukkan ke dalam baseline yang direvisi.
4.6.1.5 FAKTOR LINGKUNGAN PERUSAHAAN
Faktor-faktor lingkungan perusahaan yang dapat memengaruhi proses Perform Integrated Change Control termasuk
namun tidak terbatas pada:
◆ Pembatasan hukum, seperti peraturan negara atau lokal;
◆ Standar pemerintah atau industri (misalnya, standar produk, standar kualitas, standar keselamatan, dan standar
pengerjaan);
◆ Persyaratan dan/atau batasan hukum dan peraturan;
◆ Kerangka kerja tata kelola organisasi (cara terstruktur untuk memberikan kontrol, arahan, dan koordinasi
melalui orang, kebijakan, dan proses untuk memenuhi tujuan strategis dan operasional organisasi); dan
◆ Batasan kontrak dan pembelian.
4.6.1.6 ASET PROSES ORGANISASI
Aset proses organisasi yang dapat mempengaruhi proses Perform Integrated Change Control termasuk namun tidak
terbatas pada:
◆ Prosedur pengendalian perubahan, termasuk langkah-langkah yang digunakan untuk memodifikasi standar
organisasi, kebijakan, rencana, prosedur, atau dokumen proyek apa p u n , dan bagaimana setiap perubahan
akan disetujui dan divalidasi;
◆ Prosedur untuk menyetujui dan menerbitkan otorisasi perubahan; dan
◆ Basis pengetahuan manajemen konfigurasi yang berisi versi dan garis dasar dari semua standar resmi
organisasi, kebijakan, prosedur, dan dokumen proyek apa pun.
Bagian 1 -
118
Panduan
4.6.2 MELAKUKAN PENGENDALIAN PERUBAHAN TERPADU: ALAT DAN TEKNIK
4.6.2.1 PENILAIAN AHLI
Dijelaskan dalam Bagian 4.1.2.1. Keahlian harus dipertimbangkan dari individu atau kelompok yang memiliki
pengetahuan khusus atau pelatihan dalam topik-topik berikut:
◆ Pengetahuan teknis tentang industri dan area fokus proyek,
◆ Undang-undang dan peraturan,
◆ Hukum dan pengadaan,
◆ Manajemen konfigurasi, dan
◆ Manajemen risiko.
4.6.2.2 ALAT KONTROL PERUBAHAN
Untuk memfasilitasi konfigurasi dan manajemen perubahan, alat bantu manual atau otomatis dapat digunakan. Kontrol
konfigurasi difokuskan pada spesifikasi hasil dan proses, sedangkan kontrol perubahan difokuskan pada identifikasi,
dokumentasi, dan persetujuan atau penolakan perubahan pada dokumen, hasil, atau baseline proyek.
Pemilihan alat harus didasarkan pada kebutuhan pemangku kepentingan proyek termasuk pertimbangan dan/atau
kendala organisasi dan lingkungan. Alat bantu harus mendukung aktivitas manajemen konfigurasi berikut ini:
◆ Identifikasi item konfigurasi. Identifikasi dan pemilihan item konfigurasi untuk memberikan dasar bagi
konfigurasi produk yang ditetapkan dan diverifikasi, produk dan dokumen diberi label, perubahan dikelola,
dan akuntabilitas dipertahankan.
◆ Merekam dan melaporkan status item konfigurasi. Perekaman dan pelaporan informasi tentang setiap item
konfigurasi.
◆ Melakukan verifikasi dan audit item konfigurasi. Verifikasi konfigurasi dan audit konfigurasi memastikan bahwa
komposisi item konfigurasi proyek sudah benar dan bahwa perubahan yang sesuai didaftarkan, dinilai, disetujui,
dilacak, dan diimplementasikan dengan benar. Hal ini memastikan bahwa persyaratan fungsional yang didefinisikan
dalam dokumentasi konfigurasi terpenuhi.
119
Alat bantu juga harus mendukung aktivitas manajemen perubahan berikut ini:
◆ Mengidentifikasi perubahan. Mengidentifikasi dan memilih item perubahan untuk proses atau dokumen proyek.
◆ Mendokumentasikan perubahan. Mendokumentasikan perubahan ke dalam permintaan perubahan yang tepat.
◆ Memutuskan perubahan. Meninjau perubahan; menyetujui, menolak, menunda, atau membuat keputusan lain
tentang perubahan pada dokumen, hasil, atau baseline proyek.
◆ Melacak perubahan. Memverifikasi bahwa perubahan telah didaftarkan, dinilai, disetujui, dan dilacak, serta
mengkomunikasikan hasil akhir kepada para pemangku kepentingan.
Alat bantu juga digunakan untuk mengelola permintaan perubahan dan keputusan yang dihasilkan. Pertimbangan
tambahan harus dibuat untuk komunikasi guna membantu anggota Dewan Pengendalian Perubahan (CCB) dalam
menjalankan tugasnya, serta mendistribusikan keputusan kepada pemangku kepentingan yang tepat.
4.6.2.3 ANALISIS DATA
Teknik analisis data yang dapat digunakan untuk proses ini termasuk namun tidak terbatas pada:
◆ Analisis alternatif. Dijelaskan di Bagian 9.2.2.5. Teknik ini digunakan untuk menilai perubahan yang diminta dan
memutuskan mana yang diterima, ditolak, atau perlu dimodifikasi untuk akhirnya diterima.
◆ Analisis biaya-manfaat. Dijelaskan di Bagian 8.1.2.3. Analisis ini membantu menentukan apakah perubahan yang
diminta sepadan dengan biaya yang dikeluarkan.
4.6.2.4 PENGAMBILAN KEPUTUSAN
Teknik pengambilan keputusan yang dapat digunakan untuk proses ini termasuk namun tidak terbatas pada:
◆ Pemungutan suara. Dijelaskan dalam Bagian 5.2.2.4. Pemungutan suara dapat berupa suara bulat,
mayoritas, atau pluralitas untuk memutuskan apakah akan menerima, menunda, atau menolak permintaan
perubahan.
◆ Pengambilan keputusan otokratis. Dalam teknik pengambilan keputusan ini, satu individu bertanggung
jawab untuk membuat keputusan bagi seluruh kelompok.
◻
◆ Analisis keputusan multikriteria. Dijelaskan di Bagian 8.1.2.4. Teknik ini menggunakan matriks keputusan untuk
memberikan pendekatan analitis sistematis untuk mengevaluasi perubahan yang diminta sesuai dengan
◻
serangkaian kriteria yang telah ditetapkan.
Bagian 1 -
120
Panduan
4.6.2.5 PERTEMUAN
Rapat kontrol perubahan diadakan dengan dewan kontrol perubahan (CCB) yang bertanggung jawab untuk
bertemu dan meninjau permintaan perubahan dan menyetujui, menolak, atau menunda permintaan perubahan. Sebagian
besar perubahan akan berdampak pada waktu, biaya, sumber daya, atau risiko. Menilai dampak perubahan merupakan
bagian penting dari rapat. Alternatif terhadap perubahan yang diminta juga dapat didiskusikan dan diusulkan. Terakhir,
keputusan dikomunikasikan kepada pemilik atau kelompok permintaan.
CCB juga dapat meninjau aktivitas manajemen konfigurasi. Peran dan tanggung jawab dewan ini didefinisikan
dengan jelas dan disepakati oleh para pemangku kepentingan yang sesuai dan didokumentasikan dalam rencana
manajemen perubahan. Keputusan CCB didokumentasikan dan dikomunikasikan kepada para pemangku
kepentingan untuk mendapatkan informasi dan tindak lanjut.
4.6.3 MELAKUKAN KONTROL PERUBAHAN TERINTEGRASI: KELUARAN
4.6.3.1 PERMINTAAN PERUBAHAN YANG DISETUJUI
Permintaan perubahan (dijelaskan di Bagian 4.3.3.4) diproses sesuai dengan rencana manajemen perubahan
oleh manajer proyek, CCB, atau anggota tim yang ditugaskan. Hasilnya, perubahan dapat disetujui, ditunda, atau
ditolak. Permintaan perubahan yang disetujui akan diimplementasikan melalui proses Mengarahkan dan Mengelola
Pekerjaan Proyek. Permintaan perubahan yang ditangguhkan atau ditolak akan dikomunikasikan kepada orang atau
kelompok yang meminta perubahan.
Disposisi semua permintaan perubahan dicatat dalam log perubahan sebagai pembaruan dokumen proyek.
4.6.3.2 PEMBARUAN RENCANA MANAJEMEN PROYEK
Setiap komponen yang dikontrol secara formal dari rencana manajemen proyek dapat diubah sebagai hasil dari
proses ini. Perubahan pada garis dasar hanya dilakukan dari garis dasar terakhir ke depan. Kinerja masa lalu tidak diubah.
Hal ini untuk melindungi integritas baseline dan data historis kinerja masa lalu.
4.6.3.3 PEMBARUAN DOKUMEN PROYEK
Setiap dokumen proyek yang dikontrol secara formal dapat diubah sebagai hasil dari proses ini. Dokumen proyek
yang biasanya diperbarui sebagai hasil dari proses ini adalah log perubahan. Log perubahan digunakan untuk
mendokumentasikan perubahan yang terjadi selama proyek berlangsung.
121
4.7 MENUTUP PROYEK ATAU FASE
Menutup Proyek atau Fase adalah proses menyelesaikan semua aktivitas untuk proyek, fase, atau kontrak. Manfaat
utama dari proses ini adalah informasi proyek atau fase diarsipkan, pekerjaan yang direncanakan selesai, dan
sumber daya tim organisasi dilepaskan untuk mengejar upaya baru. Proses ini dilakukan sekali atau pada titik-titik yang
telah ditentukan dalam proyek. Input, alat dan teknik, serta output dari proses ini digambarkan pada Gambar 4-14.
Gambar 4-15 menggambarkan diagram aliran data untuk proses tersebut.
Menutup Proyek atau Fase
Masukan Alat & Teknik Keluaran

.1 Piagam proyek .1 Penilaian ahli .1 Pembaruan dokumen proyek
.2 Rencana manajemen proyek .2 Analisis data • Daftar pelajaran yang dipetik
• Semua komponen • Analisis dokumen .2 Transisi produk,
.3 Dokumen proyek • Analisis regresi layanan, atau hasil akhir
• Log asumsi • Analisis tren .3 Laporan akhir
• Dasar estimasi • Analisis sidik ragam .4 Pembaruan aset proses
• Ubah log .3 Rapat organisasi
• Log masalah
• Daftar pelajaran yang
dipetik
• Daftar pencapaian
• Komunikasi proyek
• Pengukuran
kontrol
kualitas
• Laporan kualitas
• Dokumentasi
persyaratan
• Daftar risiko
• Laporan risiko
.4 Hasil kerja yang diterima
.5 Dokumen bisnis
• Kasus bisnis
• Rencana pengelolaan
manfaat
.6 Perjanjian
.7 Dokumentasi pengadaan
.8 Aset proses organisasi
◻
Gambar 4-14. Menutup Proyek atau Fase: Masukan, Alat & Teknik, dan Keluaran
◻
Bagian 1 -
122
Panduan
4.1
Mengembangk
an Piagam
Proyek
• Piagam Proyek
Rencana
Manajemen
Proyek
Rencana manajemen Pelanggan

proyek • Transisi produk,
• Semua komponen layanan, atau hasil
akhir
Dokumen
Proyek
4.7 Dokumen
Dokumen proyek Proyek
Menutup Pembaruan dokumen proyek
• Log asumsi
• Dasar estimasi Proyek
- Piagam
• Daftar pelajaran yang
atau Fase dipetik
• Ubah log proyek
• Log masalah
• Daftar pelajaran yang dipetik
• Daftar pencapaian
• Komunikasi proyek
• Pengukuran kontrol kualitas
• Laporan kualitas
• Dokumentasi persyaratan Perusahaan/Or
• Daftar risiko ganisasi
• Laporan risiko • Laporan akhir
• Pembaruan aset
proses organisasi
5.5
Memvalidasi
Ruang
Lingkup
• Hasil kerja yang
diterima
12.1
12.2 Dokumen
Merencanakan Perusahaan/Or
Melakukan Proyek ganisasi
Manajemen
Pengadaan
Pengadaan
• Dokumentasi pengadaan • Perjanjian • Kasus bisnis - Aset proses organisasi

• Rencana pengelolaan manfaat
Gambar 4-15. Menutup Proyek atau Fase: Diagram Aliran Data
123
Saat menutup proyek, manajer proyek meninjau rencana manajemen proyek untuk memastikan bahwa semua
pekerjaan proyek telah selesai dan proyek telah memenuhi tujuannya. Aktivitas yang diperlukan untuk penutupan
proyek atau fase secara administratif termasuk namun tidak terbatas pada:
◆ Tindakan dan aktivitas yang diperlukan untuk memenuhi kriteria penyelesaian atau keluar dari fase atau proyek
seperti:
◼ Memastikan bahwa semua dokumen dan hasil kerja adalah yang terbaru dan semua masalah telah diselesaikan;
◼ Mengonfirmasi pengiriman dan penerimaan formal hasil kerja oleh pelanggan;
◼ Memastikan bahwa semua biaya dibebankan ke proyek;
◼ Menutup akun proyek;
◼ Menugaskan kembali personel;
◼ Berurusan dengan material proyek yang berlebih;
◼ Mengalokasikan kembali fasilitas, peralatan, dan sumber daya proyek lainnya; dan
◼ Menguraikan laporan tugas akhir seperti yang dipersyaratkan oleh kebijakan organisasi.
◆ Kegiatan yang terkait dengan penyelesaian perjanjian kontrak yang berlaku untuk proyek atau fase proyek
seperti:
◼ Mengonfirmasi penerimaan resmi atas karya penjual,
◼ Menyelesaikan klaim terbuka,
◼ Memperbarui catatan untuk mencerminkan hasil akhir, dan
◼ Mengarsipkan informasi tersebut untuk penggunaan di masa mendatang.
◆ Kegiatan yang diperlukan untuk:
◼ Mengumpulkan catatan proyek atau fase,

◼ Mengaudit keberhasilan atau kegagalan proyek,
◼ Mengelola pembagian dan transfer pengetahuan,
◼ Mengidentifikasi pelajaran yang dapat dipetik, dan
◼ Mengarsipkan informasi proyek untuk digunakan di masa mendatang oleh organisasi.
◆ Tindakan dan kegiatan yang diperlukan untuk mentransfer produk, layanan, atau hasil proyek ke tahap
◻
berikutnya atau ke produksi dan/atau operasi.

◻
◆ Mengumpulkan saran untuk memperbaiki atau memperbarui kebijakan dan prosedur organisasi, dan
mengirimkannya ke unit organisasi yang sesuai.
◆ Mengukur kepuasan pemangku kepentingan.
Proses Close Project atau Fase juga menetapkan prosedur untuk menyelidiki dan mendokumentasikan alasan
tindakan yang diambil jika proyek dihentikan sebelum selesai. Agar berhasil mencapai hal ini, manajer proyek perlu
melibatkan semua pemangku kepentingan yang tepat dalam prosesnya.
Bagian 1 -
124
Panduan
4.7.1 MENUTUP PROYEK ATAU FASE: MASUKAN
4.7.1.1 PIAGAM PROYEK
Dijelaskan di Bagian 4.1.3.1. Piagam proyek mendokumentasikan kriteria keberhasilan proyek, persyaratan
persetujuan, dan siapa yang akan menandatangani proyek.
Dijelaskan di Bagian 4.2.3.1. Semua komponen dari rencana manajemen proyek merupakan masukan untuk proses ini.
Dokumen proyek yang dapat menjadi masukan untuk proses ini termasuk namun tidak terbatas pada:
◆ Log asumsi. Dijelaskan di Bagian 4.1.3.2. Catatan asumsi berisi catatan semua asumsi dan kendala yang
memandu spesifikasi teknis, perkiraan, jadwal, risiko, dll.
◆ Dasar estimasi. Dijelaskan di Bagian 6.4.3.2 dan 7.2.3.2. Dasar estimasi digunakan untuk mengevaluasi
bagaimana estimasi durasi, biaya, sumber daya, dan pengendalian biaya dibandingkan dengan hasil aktual.
◆ Log perubahan. Dijelaskan di Bagian 4.6.3.3. Log perubahan berisi status semua permintaan perubahan di seluruh
proyek atau fase.
◆ Log masalah. Dijelaskan di Bagian 4.3.3.3. Log masalah digunakan untuk memeriksa bahwa tidak ada masalah
terbuka.
◆ Daftar pelajaran yang dipetik. Dijelaskan di Bagian 4.3.3.1. Pelajaran yang dipetik dalam fase atau proyek
akan difinalisasi sebelum dimasukkan ke dalam repositori pelajaran yang dipetik.
◆ Daftar pencapaian. Dijelaskan di Bagian 6.2.3.3. Daftar pencapaian menunjukkan tanggal akhir
pencapaian proyek yang telah dicapai.
◆ Komunikasi proyek. Dijelaskan dalam Bagian 10.2.3.1. Komunikasi proyek mencakup setiap dan
semua komunikasi yang telah dibuat selama proyek berlangsung.
◆ Pengukuran kontrol kualitas. Dijelaskan dalam Bagian 8.3.3.1. Pengukuran kontrol kualitas mendokumentasikan
hasil dari aktivitas Kontrol Kualitas dan menunjukkan kepatuhan terhadap persyaratan kualitas.
◆ Laporan kualitas. Dijelaskan dalam Bagian 8.2.3.1. Informasi yang disajikan dalam laporan kualitas dapat
mencakup semua masalah jaminan kualitas yang dikelola atau dieskalasi oleh tim, rekomendasi untuk perbaikan,
dan ringkasan temuan dari proses Kontrol Kualitas.
◆ Dokumentasi persyaratan. Dijelaskan dalam Bagian 5.2.3.1. Dokumentasi persyaratan digunakan
untuk menunjukkan kepatuhan terhadap ruang lingkup proyek.
125
◆ Daftar risiko. Dijelaskan di Bagian 11.2.3.1. Daftar risiko memberikan informasi tentang risiko yang telah terjadi
selama proyek berlangsung.
◆ Laporan risiko. Dijelaskan di Bagian 11.2.3.2. Laporan risiko memberikan informasi tentang status risiko dan
digunakan untuk memeriksa bahwa tidak ada risiko terbuka di akhir proyek.
4.7.1.4 HASIL YANG DITERIMA
Dijelaskan dalam Bagian 5.5.3.1. Hasil kerja yang diterima dapat mencakup spesifikasi produk yang disetujui, tanda
terima pengiriman, dan dokumen pelaksanaan pekerjaan. Hasil kerja parsial atau interim juga dapat disertakan untuk
proyek yang bertahap atau dibatalkan.
4.7.1.5 DOKUMEN BISNIS
Dijelaskan dalam Bagian 1.2.6. Dokumen bisnis termasuk namun tidak terbatas pada:
◆ Kasus bisnis. Kasus bisnis mendokumentasikan kebutuhan bisnis dan analisis manfaat biaya yang
menjustifikasi proyek tersebut.
◆ Rencana pengelolaan manfaat. Rencana manajemen manfaat menguraikan target manfaat proyek.
Kasus bisnis digunakan untuk menentukan apakah hasil yang diharapkan dari studi kelayakan ekonomi yang digunakan
untuk menjustifikasi proyek telah terjadi. Rencana manajemen manfaat digunakan untuk mengukur apakah manfaat
proyek tercapai sesuai rencana.
4.7.1.6 PERJANJIAN
Dijelaskan dalam Bagian 12.2.3.2. Persyaratan untuk penutupan pengadaan formal biasanya ditentukan dalam
syarat dan ketentuan kontrak dan disertakan dalam rencana manajemen pengadaan. Proyek yang kompleks dapat
melibatkan pengelolaan beberapa kontrak secara bersamaan atau berurutan.
4.7.1.7 DOKUMENTASI PENGADAAN
Dijelaskan dalam Bagian 12.3.1.4. Untuk menutup kontrak, semua dokumentasi pengadaan dikumpulkan, diindeks, dan
◻
diarsipkan. Informasi mengenai jadwal kontrak, ruang lingkup, kualitas, dan kinerja biaya beserta semua dokumentasi
perubahan kontrak, catatan pembayaran, dan hasil pemeriksaan dibuatkan katalog. Rencana/gambar "as-built" atau
◻
dokumen "as-developed", manual, pemecahan masalah, dan dokumentasi teknis lainnya juga harus dipertimbangkan
sebagai bagian dari dokumen pengadaan saat menutup proyek. Informasi ini dapat digunakan sebagai bahan
pembelajaran dan sebagai dasar untuk mengevaluasi kontraktor untuk kontrak di masa mendatang.
Bagian 1 -
126
Panduan
Aset proses organisasi yang dapat memengaruhi proses Close Project atau Fase termasuk namun tidak terbatas pada:
◆ Pedoman atau persyaratan penutupan proyek atau fase (misalnya, pelajaran yang dipetik, audit proyek akhir,
evaluasi proyek, validasi produk, kriteria penerimaan, penutupan kontrak, penugasan ulang sumber daya, penilaian
kinerja tim, dan transfer pengetahuan).
◆ Basis pengetahuan manajemen konfigurasi yang berisi versi dan garis dasar dari semua standar resmi
organisasi, kebijakan, prosedur, dan dokumen proyek apa pun.
4.7.2 MENUTUP PROYEK ATAU FASE: ALAT DAN TEKNIK
Dijelaskan di Bagian 4.1.2.1. Keahlian harus dipertimbangkan dari individu atau kelompok yang memiliki pengetahuan
atau pelatihan khusus dalam topik-topik berikut:
◆ Pengendalian manajemen,
◆ Audit,
◆ Hukum dan pengadaan, dan
◆ Undang-undang dan peraturan.
Teknik analisis data yang dapat digunakan dalam penutupan proyek termasuk namun tidak terbatas pada:
◆ Analisis dokumen. Dijelaskan di Bagian 5.2.2.3. Menilai dokumentasi yang tersedia akan memungkinkan
untuk mengidentifikasi pelajaran yang dapat dipetik dan berbagi pengetahuan untuk proyek-proyek masa
depan dan peningkatan aset organisasi.
◆ Analisis regresi. Teknik ini menganalisis keterkaitan antara berbagai variabel proyek yang berkontribusi
pada hasil proyek untuk meningkatkan kinerja pada proyek-proyek selanjutnya.
◆ Analisis tren. Dijelaskan di Bagian 4.5.2.2. Analisis tren dapat digunakan untuk memvalidasi model yang
digunakan dalam organisasi dan untuk mengimplementasikan penyesuaian untuk proyek-proyek di masa
depan.
◆ Analisis varians. Dijelaskan di Bagian 4.5.2.2. Analisis varians dapat digunakan untuk meningkatkan metrik
organisasi dengan membandingkan apa yang awalnya direncanakan dan hasil akhirnya.
127
4.7.2.3 PERTEMUAN
Rapat digunakan untuk mengonfirmasi bahwa hasil kerja telah diterima, memvalidasi bahwa kriteria keluar telah
terpenuhi, meresmikan penyelesaian kontrak, mengevaluasi kepuasan para pemangku kepentingan,
mengumpulkan pelajaran yang didapat, mentransfer pengetahuan dan informasi dari proyek, dan merayakan
keberhasilan. Peserta yang hadir dapat mencakup anggota tim proyek dan pemangku kepentingan lain yang terlibat
atau terpengaruh oleh proyek. Pertemuan dapat dilakukan secara tatap muka, virtual, formal, atau informal. Jenis
rapat termasuk tetapi tidak terbatas pada rapat pelaporan akhir, rapat penutupan, rapat penutupan pelanggan, rapat
pembelajaran, dan rapat perayaan.
4.7.3 MENUTUP PROYEK ATAU FASE: KELUARAN
Semua dokumen proyek dapat diperbarui dan ditandai sebagai versi final sebagai hasil dari penutupan proyek.
Yang menarik adalah daftar pelajaran yang dipetik, yang difinalisasi untuk menyertakan informasi akhir tentang fase
atau penutupan proyek. Daftar pelajaran yang dipetik akhir dapat mencakup informasi tentang manajemen
manfaat, keakuratan kasus bisnis, siklus hidup proyek dan pengembangan, manajemen risiko dan masalah,
keterlibatan pemangku kepentingan, dan proses manajemen proyek lainnya.
4.7.3.2 TRANSISI PRODUK, LAYANAN, ATAU HASIL AKHIR
Sebuah produk, layanan, atau hasil, setelah diserahkan oleh proyek, dapat diserahkan kepada kelompok atau
organisasi lain yang akan mengoperasikan, memelihara, dan mendukungnya selama siklus hidupnya.
Output ini mengacu pada transisi produk akhir, layanan, atau hasil yang telah disahkan untuk diproduksi oleh
proyek (atau dalam kasus penutupan fase, produk, layanan, atau hasil peralihan dari fase tersebut) dari satu tim ke
tim lainnya.
4.7.3.3 LAPORAN AKHIR
Laporan akhir memberikan ringkasan kinerja proyek. Laporan ini dapat mencakup informasi seperti:
◻
◻
◆ Deskripsi tingkat ringkasan proyek atau fase.
◆ Tujuan ruang lingkup, kriteria yang digunakan untuk mengevaluasi ruang lingkup, dan bukti bahwa kriteria
penyelesaian telah terpenuhi.
◆ Sasaran kualitas, kriteria yang digunakan untuk mengevaluasi proyek dan kualitas produk, verifikasi dan
tanggal pengiriman tonggak pencapaian aktual, dan alasan terjadinya perbedaan.
◆ Sasaran biaya, termasuk kisaran biaya yang dapat diterima, biaya aktual, dan alasan untuk setiap perbedaan.
◆ Ringkasan informasi validasi untuk produk, layanan, atau hasil akhir.
Bagian 1 -
128
Panduan
◆ Jadwalkan tujuan termasuk apakah hasil mencapai manfaat yang ingin dicapai oleh proyek. Jika manfaat tidak
tercapai pada akhir proyek, tunjukkan tingkat pencapaiannya dan perkirakan realisasi manfaat di masa
mendatang.
◆ Ringkasan tentang bagaimana produk, layanan, atau hasil akhir mencapai kebutuhan bisnis yang diidentifikasi
dalam rencana bisnis. Jika kebutuhan bisnis tidak terpenuhi pada akhir proyek, tunjukkan tingkat pencapaiannya
dan perkirakan kapan kebutuhan bisnis tersebut akan terpenuhi di masa mendatang.
◆ Ringkasan risiko atau masalah yang dihadapi dalam proyek dan cara mengatasinya.
4.7.3.4 PEMBARUAN ASET PROSES ORGANISASI
Aset proses organisasi yang diperbarui termasuk namun tidak terbatas pada:
◆ Dokumen proyek. Dokumentasi yang dihasilkan dari aktivitas proyek; misalnya, rencana manajemen
proyek; ruang lingkup, biaya, jadwal, dan kalender proyek; dan dokumentasi manajemen perubahan.
◆ Dokumen operasional dan dukungan. Dokumen yang diperlukan organisasi untuk memelihara, mengoperasikan,
dan mendukung produk atau layanan yang diberikan oleh proyek. Dokumen-dokumen ini dapat berupa dokumen
baru atau pembaruan terhadap dokumen yang sudah ada.
◆ Dokumen penutupan proyek atau fase. Dokumen penutupan proyek atau fase, terdiri dari dokumentasi formal
yang menunjukkan penyelesaian proyek atau fase dan pengalihan hasil proyek atau fase yang telah selesai
k e p a d a p i h a k lain, seperti grup operasi atau ke fase berikutnya. Selama penutupan proyek, manajer
proyek meninjau dokumentasi fase sebelumnya, dokumentasi penerimaan pelanggan dari proses Validasi Ruang
Lingkup (Bagian 5.5), dan perjanjian (jika ada) untuk memastikan bahwa semua persyaratan proyek telah
diselesaikan sebelum menyelesaikan penutupan proyek. Jika proyek dihentikan sebelum selesai,
dokumentasi formal menunjukkan mengapa proyek dihentikan dan memformalkan prosedur untuk pengalihan
hasil kerja yang sudah selesai dan yang belum selesai dari proyek yang dibatalkan kepada pihak lain.
◆ Repositori pembelajaran. Pelajaran yang didapat dan pengetahuan yang diperoleh selama proyek ditransfer ke
repositori pembelajaran untuk digunakan oleh proyek-proyek selanjutnya.
129
5
MANAJEMEN RUANG LINGKUP PROYEK
Manajemen Ruang Lingkup Proyek mencakup proses yang diperlukan untuk memastikan bahwa proyek mencakup
semua pekerjaan yang diperlukan, dan hanya pekerjaan yang diperlukan, untuk menyelesaikan proyek dengan sukses.
Mengelola ruang lingkup proyek terutama berkaitan dengan mendefinisikan dan mengendalikan apa yang termasuk dan
tidak termasuk dalam proyek.
Proses Manajemen Lingkup Proyek adalah:
5.1 Plan Scope Management-Proses pembuatan rencana manajemen ruang lingkup yang mendokumentasikan
bagaimana ruang lingkup proyek dan produk akan didefinisikan, divalidasi, dan dikendalikan.
5.2 Mengumpulkan Persyaratan-Proses menentukan, mendokumentasikan, dan mengelola kebutuhan dan
persyaratan pemangku kepentingan untuk memenuhi tujuan proyek.
5.3 Tentukan Ruang Lingkup-Proses pengembangan deskripsi rinci tentang proyek dan produk.
5.4 Membuat WBS-Proses membagi hasil proyek dan pekerjaan proyek menjadi komponen yang lebih kecil dan
lebih mudah dikelola.
5.5 Validasi Ruang Lingkup-Proses memformalkan penerimaan hasil proyek yang telah selesai.
5.6 Control Scope-Proses pemantauan status proyek dan ruang lingkup produk serta mengelola perubahan pada
baseline ruang lingkup.
Gambar 5-1 memberikan gambaran umum tentang proses Manajemen Lingkup Proyek. Proses Manajemen
Ruang Lingkup Proyek disajikan sebagai proses terpisah dengan antarmuka yang ditentukan sementara, dalam
praktiknya, proses-proses tersebut saling tumpang tindih dan berinteraksi dengan cara yang tidak dapat dirinci secara
◻
lengkap dalam Panduan PMBOK®.

◻
Bagian 1 -
130
Panduan
Gambaran Umum Manajemen
Ruang Lingkup Proyek
5.1 Ruang Lingkup 5.2

Rencana Mengumpulkan 5.3 Tentukan Ruang Lingkup
Manajemen Persyaratan
.1 Masukan
.1 Masukan .1 Masukan .1 Piagam proyek
.1 Piagam proyek .1 Piagam proyek .2 Rencana manajemen proyek
.2 Rencana manajemen proyek .2 Rencana manajemen proyek .3 Dokumen proyek
.3 Faktor lingkungan .3 Dokumen proyek .4 Faktor lingkungan
perusahaan .4 Dokumen bisnis perusahaan
.4 Aset proses organisasi .5 Perjanjian .5 Aset proses organisasi
.6 Faktor lingkungan .2 Alat & Teknik
.2 Alat & Teknik
perusahaan .1 Penilaian ahli
.1 Penilaian ahli
.7 Aset proses organisasi .2 Analisis data
.2 Analisis data
.3 Rapat .2 Alat & Teknik .3 Pengambilan keputusan
.1 Penilaian ahli .4 Keterampilan interpersonal dan tim
.3 Keluaran .5 Analisis produk
.2 Pengumpulan data
.1 Rencana pengelolaan ruang
.3 Analisis data .3 Keluaran
lingkup
.4 Pengambilan keputusan
.2 Rencana manajemen .1 Pernyataan ruang lingkup proyek
.5 Representasi data
persyaratan .2 Pembaruan dokumen proyek
.6 Keterampilan interpersonal
dan tim
5.4 Membuat WBS .7 Diagram konteks
.8 Prototipe
5.6 Ruang Lingkup Kontrol
.1 Masukan .3 Keluaran
.1 Rencana manajemen proyek .1 Dokumentasi persyaratan
.2 Dokumen proyek .1 Masukan
.2 Matriks penelusuran
.3 Faktor lingkungan persyaratan .1 Rencana manajemen proyek
perusahaan .2 Dokumen proyek
.4 Aset proses organisasi .3 Data prestasi kerja
5.5 Validasi Ruang .4 Aset proses organisasi
.2 Alat & Teknik Lingkup
.1 Penilaian ahli .2 Alat & Teknik
.2 Dekomposisi .1 Analisis data
.1 Rencana manajemen proyek
.1 Masukan
.3 Keluaran .2 Dokumen proyek .3 Keluaran
.1 Cakupan dasar .3 Hasil kerja yang terverifikasi .1 Informasi prestasi kerja
.2 Pembaruan dokumen .4 Data prestasi kerja .2 Permintaan perubahan
proyek .3 Pembaruan rencana
.2 Alat & Teknik manajemen proyek
.1 Inspeksi .4 Pembaruan dokumen proyek
.2 Pengambilan keputusan
.3 Keluaran
.1 Hasil kerja yang diterima
.2 Informasi prestasi kerja
.3 Permintaan perubahan
.4 Pembaruan dokumen proyek
Gambar 5-1. Gambaran Umum Manajemen Lingkup Proyek
131
KONSEP KUNCI UNTUK MANAJEMEN RUANG LINGKUP
PROYEK
Dalam konteks proyek, istilah "ruang lingkup" dapat

merujuk pada:
◆ Cakupan produk. Fitur dan fungsi yang menjadi ciri produk, layanan, atau hasil.
◆ Ruang lingkup proyek. Pekerjaan yang dilakukan untuk memberikan produk, layanan, atau hasil
dengan fitur dan fungsi yang ditentukan. Istilah "cakupan proyek" terkadang dianggap mencakup cakupan
produk.
Siklus hidup proyek dapat berkisar di sepanjang kontinum dari pendekatan prediktif di satu sisi hingga pendekatan
adaptif atau lincah d i s i s i lain. Dalam siklus hidup prediktif, hasil proyek ditentukan di awal proyek dan setiap
perubahan pada ruang lingkup dikelola secara progresif. Dalam siklus hidup adaptif atau tangkas, hasil proyek
dikembangkan melalui beberapa iterasi di mana ruang lingkup terperinci didefinisikan dan disetujui untuk setiap iterasi
saat dimulai.
Proyek dengan siklus hidup adaptif dimaksudkan untuk merespons perubahan tingkat tinggi dan membutuhkan
keterlibatan pemangku kepentingan yang berkelanjutan. Keseluruhan cakupan proyek adaptif akan diuraikan
menjadi serangkaian persyaratan dan pekerjaan yang harus dilakukan, terkadang disebut sebagai product
backlog. Pada awal iterasi, tim akan bekerja untuk menentukan berapa banyak item dengan prioritas tertinggi
dalam daftar backlog yang dapat diselesaikan dalam iterasi berikutnya. Tiga proses (Mengumpulkan Persyaratan,
Mendefinisikan Ruang Lingkup, dan Membuat WBS) diulang untuk setiap iterasi. Sebaliknya, dalam proyek prediktif,
proses-proses ini dilakukan di awal proyek dan diperbarui seperlunya, menggunakan proses kontrol perubahan yang
terintegrasi.
Dalam siklus hidup yang adaptif atau gesit, sponsor dan perwakilan pelanggan harus terus terlibat dalam proyek untuk
memberikan umpan balik tentang hasil yang dibuat dan untuk memastikan bahwa backlog produk mencerminkan
kebutuhan mereka saat ini. Dua proses (Validasi Ruang Lingkup dan Ruang Lingkup Kontrol) diulang untuk setiap iterasi.
Sebaliknya, dalam proyek prediktif, Validate Scope terjadi dengan setiap tinjauan hasil atau fase dan Control Scope adalah
proses yang berkelanjutan.
Dalam proyek prediktif, baseline ruang lingkup untuk proyek adalah versi yang disetujui dari pernyataan ruang lingkup
proyek, struktur rincian kerja (WBS), dan kamus WBS yang terkait. Baseline dapat diubah hanya melalui prosedur kontrol
◻
perubahan formal dan digunakan sebagai dasar perbandingan saat melakukan proses Validasi Ruang Lingkup dan Kontrol
Ruang Lingkup serta proses pengendalian lainnya. Proyek dengan siklus hidup adaptif menggunakan backlog
◻
(termasuk persyaratan produk dan cerita pengguna) untuk mencerminkan kebutuhan mereka saat ini.
Penyelesaian ruang lingkup proyek diukur berdasarkan rencana manajemen proyek, sedangkan penyelesaian ruang
lingkup produk diukur berdasarkan persyaratan produk. Istilah "persyaratan" didefinisikan sebagai kondisi atau kemampuan
yang harus ada dalam produk, layanan, atau hasil untuk memenuhi perjanjian atau spesifikasi lain yang diberlakukan
secara formal.
Validate Scope adalah proses memformalkan penerimaan hasil proyek yang telah selesai. Hasil kerja terverifikasi yang
diperoleh dari proses Control Quality merupakan masukan untuk proses Validate Scope. Salah satu output dari
Validate Scope adalah hasil kerja yang diterima yang secara formal ditandatangani dan disetujui oleh pemangku
kepentingan yang berwenang. Oleh karena itu, pemangku kepentingan perlu terlibat sejak awal selama perencanaan
(terkadang juga sebagai pemrakarsa) dan memberikan masukan tentang kualitas hasil kerja sehingga Control
Quality dapat menilai kinerja dan merekomendasikan perubahan yang diperlukan.
Bagian 1 -
132
Panduan
TREN DAN PRAKTIK-PRAKTIK YANG MUNCUL DALAM MANAJEMEN RUANG LINGKUP PROYEK
Persyaratan selalu menjadi perhatian dalam manajemen proyek dan terus mendapatkan lebih banyak perhatian
dalam profesi ini. Ketika lingkungan global menjadi lebih kompleks, organisasi mulai menyadari bagaimana
menggunakan analisis bisnis untuk keunggulan kompetitif mereka dengan mendefinisikan, mengelola, dan
mengendalikan aktivitas persyaratan. Kegiatan analisis bisnis dapat dimulai sebelum proyek dimulai dan manajer
proyek ditugaskan. Menurut Requirements Management: A Practice Guide [14], proses manajemen kebutuhan
dimulai dengan penilaian kebutuhan, yang dapat dimulai dalam perencanaan portofolio, dalam perencanaan
program, atau dalam proyek terpisah.
Menggali, mendokumentasikan, dan mengelola persyaratan pemangku kepentingan terjadi dalam proses
Manajemen Lingkup Proyek. Tren dan praktik yang muncul untuk Manajemen Ruang Lingkup Proyek termasuk
namun tidak terbatas pada fokus pada kolaborasi dengan profesional analisis bisnis untuk:
◆ Menentukan masalah dan mengidentifikasi kebutuhan bisnis;
◆ Mengidentifikasi dan merekomendasikan solusi yang tepat untuk memenuhi kebutuhan tersebut;
◆ Mengumpulkan, mendokumentasikan, dan mengelola persyaratan pemangku kepentingan untuk memenuhi tujuan
bisnis dan proyek; dan
◆ Memfasilitasi keberhasilan implementasi produk, layanan, atau hasil akhir program atau proyek [7].
Proses ini diakhiri dengan penutupan persyaratan, yang mengalihkan produk, layanan, atau hasil kepada
penerima untuk mengukur, memantau, merealisasikan, dan mempertahankan manfaat dari waktu ke waktu.
Peran dengan tanggung jawab untuk melakukan analisis bisnis harus ditugaskan kepada sumber daya dengan
keterampilan dan keahlian analisis bisnis yang memadai. Jika analis bisnis ditugaskan untuk sebuah proyek,
aktivitas yang berhubungan dengan persyaratan adalah tanggung jawab peran tersebut. Manajer proyek
bertanggung jawab untuk memastikan bahwa pekerjaan yang berhubungan dengan kebutuhan d i p e r h i t u n g k a n
dalam rencana manajemen proyek dan bahwa kegiatan yang berhubungan dengan kebutuhan dilakukan tepat
waktu dan sesuai anggaran dan memberikan nilai.
Hubungan antara manajer proyek dan analis bisnis haruslah merupakan kemitraan kolaboratif. Sebuah proyek akan
memiliki kemungkinan lebih tinggi untuk berhasil jika manajer proyek dan analis bisnis saling memahami peran dan
tanggung jawab masing-masing untuk mencapai tujuan proyek dengan sukses.
◻
◻
133
PERTIMBANGAN YANG DISESUAIKAN
Karena setiap proyek bersifat unik, manajer proyek perlu menyesuaikan cara penerapan proses Manajemen Lingkup
Proyek. Pertimbangan untuk menyesuaikan termasuk namun tidak terbatas pada:
◆ Manajemen pengetahuan dan persyaratan. Apakah organisasi memiliki sistem manajemen pengetahuan
dan persyaratan formal atau informal? Pedoman apa yang harus dibuat oleh manajer proyek untuk persyaratan
yang a k a n digunakan kembali di masa depan?
◆ Validasi dan kontrol. Apakah organisasi memiliki kebijakan, prosedur, dan panduan terkait validasi dan
kontrol formal atau informal?
◆ Pendekatan pengembangan. Apakah organisasi menggunakan pendekatan yang gesit dalam mengelola proyek?
Apakah pendekatan pengembangan bersifat iteratif atau inkremental? Apakah pendekatan prediktif
digunakan? Apakah pendekatan hibrida akan produktif?
◆ Stabilitas persyaratan. Apakah ada area proyek dengan persyaratan yang tidak stabil? Apakah kebutuhan yang
tidak stabil memerlukan penggunaan teknik lean, agile, atau teknik adaptif lainnya hingga kebutuhan tersebut
stabil dan terdefinisi dengan baik?
◆ Tata kelola. Apakah organisasi memiliki kebijakan, prosedur, dan pedoman audit dan tata kelola formal
atau informal?
PERTIMBANGAN UNTUK LINGKUNGAN YANG LINCAH/ADAPTIF
Dalam proyek dengan persyaratan yang terus berkembang, risiko tinggi, atau ketidakpastian yang signifikan,
ruang lingkup sering kali tidak dipahami di awal proyek atau berkembang selama proyek berlangsung. Metode agile
dengan sengaja menghabiskan lebih sedikit waktu untuk mencoba mendefinisikan dan menyepakati ruang lingkup
pada tahap awal proyek dan menghabiskan lebih banyak waktu untuk membangun proses untuk penemuan dan
penyempurnaan yang sedang berlangsung. Banyak lingkungan dengan kebutuhan yang muncul menemukan
bahwa sering kali ada kesenjangan antara kebutuhan bisnis yang sebenarnya dan kebutuhan bisnis yang
dinyatakan pada awalnya. Oleh karena itu, metode agile dengan sengaja membangun dan meninjau prototipe dan
versi rilis untuk menyempurnakan persyaratan. Hasilnya, ruang lingkup didefinisikan dan didefinisikan ulang sepanjang
proyek. Dalam pendekatan agile, persyaratan merupakan backlog.
Bagian 1 -
134
Panduan
5.1 MANAJEMEN RUANG LINGKUP RENCANA
Plan Scope Management adalah proses pembuatan rencana manajemen ruang lingkup yang mendokumentasikan
bagaimana ruang lingkup proyek dan produk akan didefinisikan, divalidasi, dan dikendalikan. Manfaat utama dari proses ini
adalah memberikan panduan dan arahan tentang bagaimana ruang lingkup akan dikelola selama proyek berlangsung.
Proses ini dilakukan sekali atau pada titik-titik yang telah ditentukan dalam proyek. Input, alat dan teknik, serta output dari
proses ini digambarkan pada Gambar 5-2. Gambar 5-3 menggambarkan diagram aliran data dari proses tersebut.
Manajemen Lingkup Rencana

.1 Piagam proyek .1 Penilaian ahli .1 Rencana pengelolaan ruang lingkup
.2 Rencana manajemen proyek .2 Analisis data .2 Rencana manajemen
• Rencana manajemen mutu • Analisis alternatif persyaratan
• Deskripsi siklus hidup .3 Rapat
proyek
• Pendekatan pengembangan
.3 Faktor lingkungan
perusahaan
Gambar 5-2. Manajemen Ruang Lingkup Rencana: Masukan, Alat & Teknik, dan Keluaran
4.1
Mengembangkan
Piagam Proyek
• Piagam proyek
Rencana 5.1 Rencana

Manajemen Manajemen Manajemen
Proyek Lingkup
- Piagam • Rencana pengelolaan Proyek
Rencana proyek ruang lingkup
• Rencana
• Rencana manajemen mutu manajemen
• Deskripsi siklus hidup proyek persyaratan
• Pendekatan
pengembangan
Perusahaan/Organ
isasi
• Faktor lingkungan perusahaan

• Aset proses organisasi
Gambar 5-3. Manajemen Lingkup Rencana: Diagram Aliran Data
135
Rencana manajemen ruang lingkup adalah komponen dari rencana manajemen proyek atau program yang
menjelaskan bagaimana ruang lingkup akan didefinisikan, dikembangkan, dipantau, dikendalikan, dan divalidasi.
Pengembangan rencana manajemen ruang lingkup dan perincian ruang lingkup proyek dimulai dengan analisis
informasi yang terkandung dalam piagam proyek (Bagian 4.1.3.1), rencana anak perusahaan yang terakhir disetujui
dari rencana manajemen proyek (Bagian 4.2.3.1), informasi historis yang terkandung dalam aset proses organisasi
(Bagian 2.3), dan faktor lingkungan perusahaan yang relevan (Bagian 2.2).
5.1.1 MANAJEMEN RUANG LINGKUP RENCANA: MASUKAN
Dijelaskan di Bagian 4.1.3.1. Piagam proyek mendokumentasikan tujuan proyek, deskripsi proyek tingkat tinggi,
asumsi, kendala, dan persyaratan tingkat tinggi yang ingin dipenuhi oleh proyek.
◆ Rencana manajemen mutu. Dijelaskan dalam Bagian 8.1.3.1. Cara proyek dan ruang lingkup produk
akan dikelola dapat dipengaruhi oleh bagaimana kebijakan, metodologi, dan standar kualitas
organisasi diimplementasikan pada proyek.
◆ Deskripsi siklus hidup proyek. Siklus hidup proyek menentukan serangkaian fase yang dilalui proyek dari
awal hingga akhir proyek.
◆ Pendekatan pengembangan. Pendekatan pengembangan menentukan apakah pendekatan pengembangan
waterfall, iteratif, adaptif, tangkas, atau hibrida akan digunakan.
Faktor-faktor lingkungan perusahaan yang dapat mempengaruhi proses Manajemen Lingkup Rencana termasuk
namun tidak terbatas pada:
◻
◆ Budaya organisasi,
◻
◆ Infrastruktur,
◆ Administrasi personalia, dan
◆ Kondisi pasar.
Bagian 1 -
136
Panduan
Aset proses organisasi yang dapat mempengaruhi proses Manajemen Lingkup Rencana termasuk namun tidak
terbatas pada:
◆ Kebijakan dan prosedur, dan
◆ Repositori informasi historis dan pembelajaran.
5.1.2 MANAJEMEN RUANG LINGKUP RENCANA: ALAT DAN TEKNIK
Dijelaskan dalam Bagian 4.1.2.1 Keahlian harus dipertimbangkan dari individu atau kelompok yang memiliki
pengetahuan atau pelatihan khusus dalam topik-topik berikut:
◆ Proyek-proyek serupa sebelumnya, dan
◆ Informasi dalam bidang industri, disiplin ilmu, dan aplikasi.
Teknik analisis data yang dapat digunakan untuk proses ini termasuk namun tidak terbatas pada analisis
alternatif. Berbagai cara untuk mengumpulkan persyaratan, menguraikan proyek dan ruang lingkup produk,
menciptakan produk, memvalidasi ruang lingkup, dan mengendalikan ruang lingkup dievaluasi.
5.1.2.3 PERTEMUAN
Tim proyek dapat menghadiri rapat proyek untuk mengembangkan rencana manajemen ruang lingkup. Peserta
yang hadir dapat mencakup manajer proyek, sponsor proyek, anggota tim proyek terpilih, pemangku kepentingan terpilih,
siapa pun yang bertanggung jawab atas proses manajemen ruang lingkup, dan pihak lain yang diperlukan.
137
5.1.3 MANAJEMEN RUANG LINGKUP RENCANA: KELUARAN
5.1.3.1 RENCANA MANAJEMEN RUANG LINGKUP
Rencana manajemen ruang lingkup adalah komponen dari rencana manajemen proyek yang menjelaskan
bagaimana ruang lingkup akan didefinisikan, dikembangkan, dipantau, dikontrol, dan divalidasi. Komponen rencana
manajemen ruang lingkup meliputi:
◆ Proses untuk menyiapkan pernyataan ruang lingkup proyek;
◆ Proses yang memungkinkan pembuatan WBS dari pernyataan ruang lingkup proyek yang terperinci;
◆ Proses yang menetapkan bagaimana baseline ruang lingkup akan disetujui dan dipelihara; dan
◆ Proses yang menentukan bagaimana penerimaan formal dari hasil proyek yang telah selesai akan diperoleh.
Rencana manajemen ruang lingkup dapat bersifat formal atau informal, dibingkai secara luas atau sangat rinci,
berdasarkan kebutuhan proyek.
5.1.3.2 RENCANA MANAJEMEN PERSYARATAN
Rencana manajemen persyaratan adalah komponen dari rencana manajemen proyek yang menjelaskan bagaimana
persyaratan proyek dan produk akan dianalisis, didokumentasikan, dan dikelola. Menurut Business Analysis for
Practitioners: A Practice Guide [7], beberapa organisasi menyebutnya sebagai rencana analisis bisnis. Komponen
rencana manajemen persyaratan dapat mencakup tetapi tidak terbatas pada:
◆ Bagaimana aktivitas persyaratan akan direncanakan, dilacak, dan dilaporkan;
◆ Aktivitas manajemen konfigurasi seperti: bagaimana perubahan akan dimulai; bagaimana dampaknya akan
dianalisis; bagaimana perubahan akan ditelusuri, dilacak, dan dilaporkan; serta tingkat otorisasi yang diperlukan
untuk menyetujui perubahan ini;
◆ Proses penentuan prioritas kebutuhan;
◆ Metrik yang akan digunakan dan alasan penggunaannya; dan
◆ Struktur ketertelusuran yang mencerminkan atribut persyaratan yang ditangkap pada matriks ketertelusuran.
◻
◻
Bagian 1 -
138
Panduan
5.2 MENGUMPULKAN PERSYARATAN
Mengumpulkan Persyaratan adalah proses menentukan, mendokumentasikan, dan mengelola kebutuhan dan
persyaratan pemangku kepentingan untuk memenuhi tujuan. Manfaat utama dari proses ini adalah memberikan dasar
untuk mendefinisikan cakupan produk dan cakupan proyek. Proses ini dilakukan sekali atau pada titik-titik yang telah
ditentukan dalam proyek. Input, alat dan teknik, serta output dari proses ini digambarkan pada Gambar 5-4. Gambar
5-5 menggambarkan diagram aliran data dari proses tersebut.
Kumpulkan Persyaratan

.1 Piagam proyek .1 Penilaian ahli .1 Dokumentasi persyaratan
.2 Rencana manajemen proyek .2 Pengumpulan data .2 Matriks penelusuran
• Rencana pengelolaan ruang • Curah pendapat persyaratan
lingkup • Wawancara
• Rencana manajemen • Kelompok fokus
persyaratan • Kuesioner dan
• Rencana pelibatan survei
pemangku kepentingan • Pembandingan
.3 Dokumen proyek .3 Analisis data
• Log asumsi • Analisis dokumen
• Daftar pelajaran yang .4 Pengambilan keputusan
dipetik • Pemungutan suara
• Daftar pemangku • Analisis keputusan
kepentingan multikriteria
.4 Dokumen bisnis .5 Representasi data
• Kasus bisnis • Diagram afinitas
.5 Perjanjian • Pemetaan pikiran
.6 Faktor lingkungan .6 Keterampilan interpersonal
perusahaan dan tim
.7 Aset proses organisasi • Teknik kelompok nominal
• Observasi/percakapan
• Fasilitasi
.7 Diagram konteks
.8 Prototipe
Gambar 5-4. Mengumpulkan Persyaratan: Masukan, Alat & Teknik, dan Keluaran
139
4.1
Mengembangk
an Piagam
Proyek
• Piagam proyek
Rencana
Manajemen
Proyek
Rencana manajemen proyek

• Rencana manajemen persyaratan
• Rencana pengelolaan ruang
lingkup
• Rencana pelibatan pemangku
kepentingan
Dokumen
Proyek 5.2
Kumpulkan Dokumen
Persyaratan
- Piagam • Dokumentasi
Proyek
Dokumen proyek proyek persyaratan
• Log asumsi • Matriks
• Daftar pelajaran yang penelusuran
dipetik persyaratan
• Daftar pemangku
kepentingan
Dokumen
Bisnis
Dokumen bisnis
• Kasus bisnis
12.2
Melakukan
Pengadaan
• Perjanjian
Perusahaan/Or
ganisasi

◻

◻
Gambar 5-5. Mengumpulkan Persyaratan: Diagram Aliran Data
Bagian 1 -
140
Panduan
Panduan PMBOK® tidak secara khusus membahas persyaratan produk karena persyaratan tersebut bersifat spesifik
untuk setiap industri. Perhatikan bahwa Analisis Bisnis untuk Praktisi: Panduan Praktik [7] memberikan informasi yang
lebih mendalam tentang persyaratan produk. Keberhasilan proyek secara langsung dipengaruhi oleh keterlibatan
pemangku kepentingan secara aktif dalam penemuan dan penguraian kebutuhan menjadi persyaratan proyek dan
produk dan oleh kehati-hatian dalam menentukan, mendokumentasikan, dan mengelola persyaratan produk,
layanan, atau hasil proyek. Persyaratan mencakup kondisi atau kemampuan yang harus ada dalam produk,
layanan, atau hasil untuk memenuhi perjanjian atau spesifikasi lain yang diberlakukan secara formal. Persyaratan
mencakup kebutuhan dan harapan yang dikuantifikasi dan didokumentasikan dari sponsor, pelanggan, dan
pemangku kepentingan lainnya. Persyaratan ini perlu ditimbulkan, dianalisis, dan dicatat dengan cukup rinci untuk
dimasukkan ke dalam ruang lingkup dasar dan diukur setelah pelaksanaan proyek dimulai. Persyaratan menjadi dasar
dari WBS. Biaya, jadwal, perencanaan kualitas, dan pengadaan semuanya didasarkan pada persyaratan ini.
5.2.1 MENGUMPULKAN PERSYARATAN: MASUKAN
Dijelaskan di Bagian 4.1.3.1. Piagam proyek mendokumentasikan deskripsi proyek tingkat tinggi dan
persyaratan tingkat tinggi yang akan digunakan untuk mengembangkan persyaratan terperinci.
◆ Rencana pengelolaan ruang lingkup. Dijelaskan di Bagian 5.1.3.1. Rencana manajemen ruang lingkup berisi
informasi tentang bagaimana ruang lingkup proyek akan didefinisikan dan dikembangkan.
◆ Rencana manajemen persyaratan. Dijelaskan di Bagian 5.1.3.2. Rencana manajemen persyaratan memiliki
informasi tentang bagaimana persyaratan proyek akan dikumpulkan, dianalisis, dan didokumentasikan.
◆ Rencana pelibatan pemangku kepentingan. Dijelaskan dalam Bagian 13.2.3.1. Rencana pelibatan
pemangku kepentingan digunakan untuk memahami persyaratan komunikasi pemangku kepentingan dan
tingkat pelibatan pemangku kepentingan untuk menilai dan beradaptasi dengan tingkat partisipasi pemangku
kepentingan dalam kegiatan persyaratan.
141
Contoh dokumen proyek yang dapat dipertimbangkan sebagai masukan untuk proses ini termasuk namun tidak terbatas
pada:
◆ Catatan Asumsi. Dijelaskan di Bagian 4.1.3.2. Log asumsi mengidentifikasi asumsi tentang produk, proyek,
lingkungan, pemangku kepentingan, dan faktor lain yang dapat memengaruhi persyaratan.
◆ Daftar pelajaran yang dipetik. Dijelaskan di Bagian 4.4.3.1. Daftar pelajaran yang dipetik digunakan
untuk memberikan informasi tentang teknik pengumpulan kebutuhan yang efektif, terutama untuk proyek
yang menggunakan metodologi pengembangan produk yang berulang atau adaptif.
◆ Daftar Pemangku Kepentingan. Dijelaskan dalam Bagian 13.1.3.1. Daftar pemangku kepentingan digunakan
untuk mengidentifikasi pemangku kepentingan yang dapat memberikan informasi tentang persyaratan.
Daftar ini juga menangkap persyaratan dan harapan yang dimiliki pemangku kepentingan untuk
proyek.
5.2.1.4 DOKUMEN BISNIS
Dijelaskan di Bagian 1.2.6. Dokumen bisnis yang dapat memengaruhi proses Pengumpulan Persyaratan adalah
kasus bisnis, yang dapat menggambarkan kriteria yang diperlukan, diinginkan, dan opsional untuk memenuhi
kebutuhan bisnis.
5.2.1.5 PERJANJIAN
Dijelaskan dalam Bagian 12.2.3.2. Perjanjian dapat berisi persyaratan proyek dan produk.
Faktor lingkungan perusahaan yang dapat memengaruhi proses Pengumpulan Persyaratan termasuk namun tidak
terbatas pada:
◆ Infrastruktur,
◻

◻
◆ Kondisi pasar.
Aset proses organisasi yang dapat memengaruhi proses Collect Requirements termasuk namun tidak terbatas pada:
◆ Kebijakan dan prosedur, dan
◆ Informasi historis dan repositori pembelajaran dengan informasi dari proyek-proyek sebelumnya.
Bagian 1 -
142
Panduan
5.2.2 MENGUMPULKAN PERSYARATAN: ALAT DAN TEKNIK
Dijelaskan dalam Bagian 4.1.2.1. Keahlian harus dipertimbangkan dari individu atau kelompok yang memiliki
pengetahuan atau pelatihan khusus dalam topik-topik berikut:
◆ Analisis bisnis,
◆ Elisitasi persyaratan,
◆ Analisis persyaratan,
◆ Dokumentasi persyaratan,
◆ Persyaratan proyek pada proyek-proyek serupa sebelumnya,
◆ Teknik pembuatan diagram,
◆ Fasilitasi, dan
◆ Manajemen konflik.
5.2.2.2 PENGUMPULAN DATA
Teknik pengumpulan data yang dapat digunakan untuk proses ini termasuk namun tidak terbatas pada:
◆ Curah pendapat. Dijelaskan di Bagian 4.1.2.2. Curah pendapat adalah teknik yang digunakan untuk menghasilkan
dan mengumpulkan berbagai ide yang terkait dengan persyaratan proyek dan produk.
◆ Wawancara. Wawancara adalah pendekatan formal atau informal untuk mendapatkan informasi dari para
pemangku kepentingan dengan berbicara langsung dengan mereka. Wawancara biasanya dilakukan dengan
mengajukan pertanyaan yang telah dipersiapkan dan spontan, serta mencatat jawaban-jawaban yang
diberikan. Wawancara sering kali dilakukan secara individual antara pewawancara dan orang yang diwawancarai,
tetapi dapat melibatkan beberapa pewawancara dan/atau beberapa orang yang diwawancarai.
Mewawancarai peserta proyek yang berpengalaman, sponsor, eksekutif lain, dan ahli bidang tertentu dapat
membantu dalam mengidentifikasi dan mendefinisikan fitur dan fungsi hasil produk yang diinginkan.
Wawancara juga berguna untuk mendapatkan informasi rahasia.
◆ Kelompok fokus. Kelompok fokus mempertemukan para pemangku kepentingan yang telah memenuhi syarat dan
para ahli di bidangnya untuk mempelajari ekspektasi dan sikap mereka terhadap produk, layanan, atau hasil
yang diusulkan. Seorang moderator terlatih memandu kelompok melalui diskusi interaktif yang dirancang
agar lebih bersifat percakapan daripada wawancara tatap muka.
143
◆ Kuesioner dan survei. Kuesioner dan survei adalah serangkaian pertanyaan tertulis yang dirancang untuk
mengumpulkan informasi dengan cepat dari sejumlah besar responden. Kuesioner dan/atau survei paling tepat
digunakan untuk audiens yang bervariasi, ketika diperlukan hasil yang cepat, ketika responden tersebar secara
geografis, dan ketika analisis statistik mungkin sesuai.
◆ Pembandingan. Dijelaskan di Bagian 8.1.2.2. Pembandingan melibatkan perbandingan produk, proses, dan
praktik aktual atau yang direncanakan dengan organisasi yang sebanding untuk mengidentifikasi praktik
terbaik, menghasilkan ide untuk perbaikan, dan memberikan dasar untuk mengukur kinerja. Organisasi yang
dibandingkan selama pembandingan dapat bersifat internal atau eksternal.
Dijelaskan di Bagian 4.5.2.2. Teknik analisis data yang dapat digunakan untuk proses ini termasuk namun tidak
terbatas pada analisis dokumen. Analisis dokumen terdiri dari peninjauan dan penilaian informasi terdokumentasi
yang relevan. Dalam proses ini, analisis dokumen digunakan untuk mendapatkan persyaratan dengan menganalisis
dokumentasi yang ada dan mengidentifikasi informasi yang relevan dengan persyaratan. Ada berbagai macam dokumen
yang dapat dianalisis untuk membantu mendapatkan persyaratan yang relevan. Contoh dokumen yang dapat dianalisis
termasuk tetapi tidak terbatas pada:
◆ Perjanjian;
◆ Rencana bisnis;
◆ Proses bisnis atau dokumentasi antarmuka;
◆ Repositori aturan bisnis;
◆ Arus proses saat ini;
◆ Literatur pemasaran;
◆ Log masalah/masalah;
◆ Kebijakan dan prosedur;
◆ Dokumentasi peraturan seperti undang-undang, kode, atau tata cara, dll.;
◆ Permintaan proposal; dan
◆ Kasus penggunaan.
Bagian 1 -
144
Panduan
Teknik pengambilan keputusan yang dapat digunakan dalam proses Mengumpulkan Persyaratan termasuk namun tidak
terbatas pada:
◆ Pemungutan suara. Voting adalah teknik pengambilan keputusan kolektif dan proses penilaian yang memiliki
beberapa alternatif dengan hasil yang diharapkan dalam bentuk tindakan di masa depan. Teknik ini dapat
digunakan untuk menghasilkan, mengklasifikasikan, dan memprioritaskan persyaratan produk. Contoh teknik
pemungutan suara meliputi:
◼ Kebulatan suara. Keputusan yang dicapai ketika semua orang menyetujui satu tindakan.
◼ Mayoritas. Keputusan yang dicapai dengan dukungan yang diperoleh dari lebih dari 50% anggota kelompok.
Memiliki ukuran kelompok dengan jumlah peserta yang tidak merata dapat memastikan bahwa keputusan akan
tercapai, daripada menghasilkan keputusan seri.
◼ Pluralitas. Keputusan yang diambil dengan cara blok terbesar dalam suatu kelompok memutuskan,
meskipun mayoritas tidak tercapai. Metode ini umumnya digunakan ketika jumlah opsi yang diajukan lebih
dari dua.
◆ Pengambilan keputusan otokratis. Dalam metode ini, satu individu bertanggung jawab untuk membuat
keputusan bagi kelompok.
◆ Analisis keputusan multikriteria. Sebuah teknik yang menggunakan matriks keputusan untuk memberikan
pendekatan analitis sistematis dalam menetapkan kriteria, seperti tingkat risiko, ketidakpastian, dan penilaian,
untuk mengevaluasi dan memberi peringkat pada banyak ide.
5.2.2.5 REPRESENTASI DATA
Teknik representasi data yang dapat digunakan untuk proses ini termasuk namun tidak terbatas pada:
◆ Diagram afinitas. Diagram afinitas memungkinkan sejumlah besar ide diklasifikasikan ke dalam kelompok-
kelompok untuk ditinjau dan dianalisis.
◆ Pemetaan pikiran. Pemetaan pikiran mengkonsolidasikan ide-ide yang dibuat melalui sesi curah pendapat
individu ke dalam satu peta untuk merefleksikan kesamaan dan perbedaan pemahaman dan untuk
menghasilkan ide-ide baru.
5.2.2.6 KETERAMPILAN INTERPERSONAL DAN TIM
Dijelaskan di Bagian 4.1.2.3. Keterampilan interpersonal dan tim yang dapat digunakan dalam proses ini
termasuk namun tidak terbatas pada:
◆ Teknik kelompok nominal. Teknik kelompok nominal meningkatkan curah pendapat dengan proses
pemungutan suara yang digunakan untuk menentukan peringkat ide yang paling berguna untuk curah
pendapat lebih lanjut atau untuk penentuan prioritas. Teknik kelompok nominal adalah bentuk curah
pendapat terstruktur yang terdiri dari empat langkah:
145
◼ Sebuah pertanyaan atau masalah diajukan kepada kelompok. Setiap orang secara diam-diam menghasilkan dan
menuliskan ide-ide mereka.
◼ Moderator menuliskan ide pada flip chart sampai semua ide tercatat.
◼ Setiap ide yang direkam didiskusikan sampai semua anggota kelompok memiliki pemahaman yang jelas.
◼ Setiap orang memberikan suara secara pribadi untuk memprioritaskan ide-ide, biasanya menggunakan
skala 1 - 5, dengan 1 sebagai nilai terendah dan 5 sebagai nilai tertinggi. Pemungutan suara dapat
dilakukan dalam beberapa putaran untuk mengurangi dan memfokuskan ide. Setelah setiap putaran,
suara dihitung dan ide dengan skor tertinggi dipilih.
◆ Observasi/percakapan. Pengamatan dan percakapan memberikan cara langsung untuk melihat individu di
lingkungan mereka dan bagaimana mereka melakukan pekerjaan atau tugas mereka serta melaksanakan proses.
Hal ini sangat membantu untuk proses yang mendetail ketika orang yang menggunakan produk mengalami
kesulitan atau enggan mengartikulasikan kebutuhan mereka. Pengamatan juga dikenal sebagai "bayangan
pekerjaan". Biasanya dilakukan secara eksternal oleh pengamat yang melihat ahli bisnis melakukan
pekerjaan. Hal ini juga dapat dilakukan oleh "pengamat partisipan" yang benar-benar melakukan proses atau
prosedur untuk mengalami bagaimana hal itu dilakukan untuk mengungkap persyaratan yang tersembunyi.
◆ Fasilitasi. Dijelaskan di Bagian 4.1.2.3. Fasilitasi digunakan dengan sesi terfokus yang menyatukan para
pemangku kepentingan utama untuk mendefinisikan persyaratan produk. Lokakarya dapat digunakan
untuk mendefinisikan persyaratan lintas fungsional dengan cepat dan mendamaikan perbedaan pemangku
kepentingan. Karena sifatnya yang interaktif, sesi yang difasilitasi dengan baik dapat membangun kepercayaan,
membina hubungan, dan meningkatkan komunikasi di antara para peserta, yang dapat mengarah pada
peningkatan konsensus pemangku kepentingan. Selain itu, masalah dapat ditemukan lebih awal dan
diselesaikan lebih cepat daripada sesi individu.
Keterampilan fasilitasi digunakan dalam situasi berikut ini, namun tidak terbatas pada:
◼ Desain/pengembangan aplikasi bersama (JAD). Sesi JAD digunakan dalam industri pengembangan
perangkat lunak. Sesi yang difasilitasi ini berfokus untuk menyatukan para ahli bisnis dan tim
pengembangan untuk mengumpulkan persyaratan dan meningkatkan proses pengembangan perangkat
lunak.
◼ Penerapan fungsi kualitas (QFD). Dalam industri manufaktur, QFD adalah teknik fasilitasi lain yang membantu
menentukan karakteristik penting untuk pengembangan produk baru. QFD dimulai dengan
mengumpulkan kebutuhan pelanggan, yang juga dikenal sebagai suara pelanggan (VOC). Kebutuhan ini
kemudian diurutkan dan diprioritaskan secara obyektif, dan tujuan ditetapkan untuk mencapainya.
◼ Cerita pengguna. Cerita pengguna, yang merupakan deskripsi tekstual singkat tentang fungsionalitas yang
dibutuhkan, sering kali dikembangkan selama lokakarya persyaratan. Cerita pengguna menggambarkan
peran pemangku kepentingan, siapa yang diuntungkan dari fitur tersebut (peran), apa yang harus dicapai
oleh pemangku kepentingan (tujuan), dan manfaat bagi pemangku kepentingan (motivasi).
Bagian 1 -
146
Panduan
5.2.2.7 DIAGRAM KONTEKS
Diagram konteks adalah contoh dari model ruang lingkup. Diagram konteks secara visual menggambarkan ruang
lingkup produk dengan menunjukkan sistem bisnis (proses, peralatan, sistem komputer, dll.), dan bagaimana orang
dan sistem lain (aktor) berinteraksi dengannya (lihat Gambar 5-6). Diagram konteks menunjukkan input ke sistem
bisnis, aktor yang menyediakan input, output dari sistem bisnis, dan aktor yang menerima output.
Sistem Manajemen Bakat SDM Perusahaan ABC
Pengguna Internal Pengguna Eksternal
Mempek Agen Perekrutan

erjakan
Manajer
Internal Eksternal
Pengguna Pekerjaan
Profil Postingan Penc
ari Kerja
Rekan
Kerja
Internal Internal Eksternal
Pekerjaan Pengguna
Postingan Profil
Situs
Web
Purna Pekerjaa
Waktu n
Internal dan Eksterna
Pengguna Internal Pengguna Eksternal l
Kontraktor
Paruh
Waktu
LEGEND
Pengguna Aliran Data Internal Pengguna Eksternal Aliran Data Eksternal

Internal
A
Gambar 5-6. Diagram Konteks Diagram Konteks
147
5.2.2.8 PROTOTIPE
Prototipe adalah metode untuk mendapatkan umpan balik awal tentang persyaratan dengan memberikan model
produk yang diharapkan sebelum benar-benar membangunnya. Contoh prototipe adalah produk berskala kecil,
model 2D dan 3D yang dibuat dengan komputer, mock-up, atau simulasi. Prototipe memungkinkan para pemangku
kepentingan untuk bereksperimen dengan model produk akhir daripada hanya terbatas pada mendiskusikan
representasi abstrak dari kebutuhan mereka. Prototipe mendukung konsep elaborasi progresif dalam siklus berulang dari
pembuatan mock-up, eksperimen pengguna, pemberian umpan balik, dan revisi prototipe. Ketika siklus umpan balik yang
cukup telah dilakukan, persyaratan yang diperoleh dari prototipe sudah cukup lengkap untuk beralih ke tahap desain
atau pembangunan.
Storyboard adalah teknik pembuatan prototipe yang menunjukkan urutan atau navigasi melalui serangkaian gambar
atau ilustrasi. Storyboard digunakan pada berbagai proyek di berbagai industri, seperti film, periklanan, desain
instruksional, dan pada proyek pengembangan perangkat lunak tangkas dan lainnya. Dalam pengembangan
perangkat lunak, storyboard menggunakan mock-up untuk menunjukkan jalur navigasi melalui halaman web, layar,
atau antarmuka pengguna lainnya.
5.2.3 MENGUMPULKAN PERSYARATAN: KELUARAN
5.2.3.1 DOKUMENTASI PERSYARATAN
Dokumentasi persyaratan menjelaskan bagaimana persyaratan individu memenuhi kebutuhan bisnis untuk
proyek. Persyaratan dapat dimulai dari tingkat yang tinggi dan menjadi semakin rinci seiring dengan semakin
banyaknya informasi tentang persyaratan yang diketahui. Sebelum menjadi dasar, persyaratan harus jelas (terukur
dan dapat diuji), dapat dilacak, lengkap, konsisten, dan dapat diterima oleh para pemangku kepentingan utama.
Format dokumen persyaratan dapat berkisar dari dokumen sederhana yang mencantumkan semua persyaratan
yang dikategorikan berdasarkan pemangku kepentingan dan prioritas, hingga bentuk yang lebih rumit yang berisi
ringkasan eksekutif, deskripsi terperinci, dan lampiran.
◻
◻
Bagian 1 -
148
Panduan
Banyak organisasi mengkategorikan persyaratan ke dalam berbagai jenis, seperti solusi bisnis dan teknis, yang
pertama mengacu pada kebutuhan pemangku kepentingan dan yang terakhir tentang bagaimana kebutuhan
tersebut akan diimplementasikan. Persyaratan dapat dikelompokkan ke dalam klasifikasi yang memungkinkan untuk
penyempurnaan lebih lanjut dan detail saat persyaratan diuraikan. Klasifikasi ini meliputi:
◆ Persyaratan bisnis. Hal ini menggambarkan kebutuhan tingkat yang lebih tinggi dari organisasi secara
keseluruhan, seperti masalah atau peluang bisnis, dan alasan mengapa sebuah proyek dilakukan.
◆ Persyaratan pemangku kepentingan. Hal ini menggambarkan kebutuhan pemangku kepentingan atau kelompok
pemangku kepentingan.
◆ Persyaratan solusi. Hal ini menggambarkan fitur, fungsi, dan karakteristik produk, layanan, atau hasil yang
akan memenuhi kebutuhan bisnis dan pemangku kepentingan. Persyaratan solusi selanjutnya dikelompokkan ke
dalam persyaratan fungsional dan nonfungsional:
◼ Persyaratan fungsional. Persyaratan fungsional menggambarkan perilaku produk. Contohnya termasuk
tindakan, proses, data, dan interaksi yang harus dijalankan oleh produk.
◼ Persyaratan nonfungsional. Persyaratan nonfungsional melengkapi persyaratan fungsional dan
menjelaskan kondisi atau kualitas lingkungan yang diperlukan agar produk menjadi efektif. Contohnya meliputi:
keandalan, keamanan, kinerja, keselamatan, tingkat layanan, kemampuan dukungan,
retensi/penghapusan, dll.
◆ Persyaratan transisi dan kesiapan. Ini menggambarkan kemampuan sementara, seperti konversi data dan
persyaratan pelatihan, yang diperlukan untuk bertransisi dari kondisi saat ini ke kondisi masa depan yang
diinginkan.
◆ Persyaratan proyek. Ini menggambarkan tindakan, proses, atau kondisi lain yang harus dipenuhi oleh
proyek. Contohnya termasuk tanggal pencapaian, kewajiban kontrak, kendala, dll.
◆ Persyaratan kualitas. Ini mencakup kondisi atau kriteria apa pun yang diperlukan untuk memvalidasi
keberhasilan penyelesaian hasil proyek atau pemenuhan persyaratan proyek lainnya. Contohnya termasuk
pengujian, sertifikasi, validasi, dll.
5.2.3.2 MATRIKS PENELUSURAN PERSYARATAN
Matriks penelusuran persyaratan adalah kisi-kisi yang menghubungkan persyaratan produk dari asalnya hingga
hasil yang memuaskan mereka. Penerapan matriks penelusuran persyaratan membantu memastikan bahwa setiap
persyaratan menambah nilai bisnis dengan menghubungkannya ke tujuan bisnis dan proyek. Matriks ini menyediakan
sarana untuk melacak persyaratan di seluruh siklus hidup proyek, membantu memastikan bahwa persyaratan yang
disetujui dalam dokumentasi persyaratan disampaikan pada akhir proyek. Terakhir, menyediakan struktur untuk
mengelola perubahan pada ruang lingkup produk.
149
Persyaratan penelusuran termasuk namun tidak terbatas pada:
◆ Kebutuhan, peluang, sasaran, dan tujuan bisnis;
◆ Tujuan proyek;
◆ Ruang lingkup proyek dan hasil kerja WBS;
◆ Desain produk;
◆ Pengembangan produk;
◆ Strategi pengujian dan skenario pengujian; dan
◆ Persyaratan tingkat tinggi hingga persyaratan yang lebih rinci.
Atribut yang terkait dengan setiap persyaratan dapat dicatat dalam matriks penelusuran persyaratan.
Atribut-atribut ini membantu mendefinisikan informasi utama tentang persyaratan. Atribut yang umum digunakan dalam
matriks penelusuran persyaratan dapat mencakup: pengidentifikasi unik, deskripsi tekstual dari persyaratan, alasan
penyertaan, pemilik, sumber, prioritas, versi, status saat ini (seperti aktif, dibatalkan, ditangguhkan, ditambahkan, disetujui,
ditugaskan, diselesaikan), dan tanggal status. Atribut tambahan untuk memastikan bahwa persyaratan telah
memenuhi kepuasan pemangku kepentingan dapat mencakup stabilitas, kompleksitas, dan kriteria penerimaan.
Gambar 5-7 memberikan contoh matriks penelusuran persyaratan dengan atribut yang terkait.
Matriks Ketertelusuran Persyaratan

Nama Proyek:
Pusat Biaya:
Deskripsi Proyek:
Kebutuhan WBS
ID Tujuan Desain Pengemb Kasu
ID Deskripsi Persyaratan Bisnis, Peluang,
Asosi Proyek Kiriman Produk angan s Uji
Sasaran, Tujuan
asi Produk
1.0
1.1
001
1.2
1.2.1
2.0
002 2.1
◻
2.1.1
3.0
◻
003 3.1
3.2
004 4.0
005 5.0
Gambar 5-7. Contoh Matriks Penelusuran Persyaratan
Bagian 1 -
150
Panduan
5.3 TETAPKAN RUANG LINGKUP
Define Scope adalah proses pengembangan deskripsi rinci tentang proyek dan produk. Manfaat utama dari
proses ini adalah proses ini menjelaskan batasan produk, layanan, atau hasil dan kriteria penerimaan. Input, alat dan
teknik, serta output dari proses ini digambarkan pada Gambar 5-8. Gambar 5-9 menggambarkan diagram aliran
data dari proses tersebut.
Tentukan Ruang Lingkup

.1 Piagam proyek .1 Penilaian ahli .1 Pernyataan ruang lingkup proyek
.2 Rencana manajemen proyek .2 Analisis data .2 Pembaruan dokumen proyek
• Rencana pengelolaan ruang • Analisis alternatif • Log asumsi
lingkup .3 Pengambilan keputusan • Dokumentasi
.3 Dokumen proyek • Analisis keputusan persyaratan
• Log asumsi multikriteria • Matriks penelusuran
• Dokumentasi .4 Keterampilan interpersonal persyaratan
persyaratan dan tim • Daftar pemangku kepentingan
• Daftar risiko • Fasilitasi
.4 Faktor lingkungan .5 Analisis produk
perusahaan
Gambar 5-8. Menetapkan Ruang Lingkup: Masukan, Alat & Teknik, dan Keluaran
151
4.1
Mengembangkan
Piagam Proyek
• Piagam proyek
Rencana
Manajemen
Proyek
• Pernyataan ruang lingkup
proyek
Rencana manajemen
proyek
ruang lingkup 5.3 Dokumen
Tentuk Proyek
Dokumen an - Piagam Pembaruan dokumen proyek
Proyek Ruangproyek • Log asumsi
Lingku • Dokumentasi persyaratan
p • Matriks penelusuran persyaratan
• Daftar pemangku kepentingan
Dokumen proyek
• Log asumsi
• Dokumentasi persyaratan
• Daftar risiko
Perusahaan/Organ
isasi

Gambar 5-9. Mendefinisikan Ruang Lingkup: Diagram Aliran Data
Karena semua persyaratan yang diidentifikasi dalam Kumpulkan Persyaratan mungkin tidak disertakan dalam
proyek, proses Define Scope memilih persyaratan proyek akhir dari dokumentasi persyaratan yang dikembangkan
selama proses Kumpulkan Persyaratan. Kemudian mengembangkan deskripsi rinci tentang proyek dan produk,
layanan, atau hasil.
Persiapan pernyataan ruang lingkup proyek yang terperinci dibangun berdasarkan hasil utama, asumsi,
◻
dan kendala yang didokumentasikan selama inisiasi proyek. Selama perencanaan proyek, ruang lingkup proyek
◻
didefinisikan dan dijelaskan dengan lebih spesifik seiring dengan semakin banyaknya informasi tentang proyek yang
diketahui. Risiko, asumsi, dan kendala yang ada dianalisis untuk kelengkapan dan ditambahkan atau diperbarui
seperlunya. Proses Define Scope bisa sangat berulang. Dalam proyek siklus hidup yang berulang, visi tingkat tinggi akan
dikembangkan untuk keseluruhan proyek, tetapi ruang lingkup terperinci ditentukan satu per satu, dan perencanaan
terperinci untuk iterasi berikutnya dilakukan seiring dengan kemajuan pekerjaan pada ruang lingkup dan hasil
proyek saat ini.
Bagian 1 -
152
Panduan
5.3.1 TETAPKAN RUANG LINGKUP: MASUKAN
Dijelaskan dalam Bagian 4.1.3.1. Piagam proyek memberikan deskripsi proyek tingkat tinggi, karakteristik produk, dan
persyaratan persetujuan.
Dijelaskan dalam Bagian 4.2.3.1. Komponen rencana manajemen proyek termasuk tetapi tidak terbatas
pada rencana manajemen ruang lingkup seperti yang dijelaskan di Bagian 5.1.3.1, yang mendokumentasikan
bagaimana ruang lingkup proyek akan didefinisikan, divalidasi, dan dikendalikan.
pada:
◆ Log asumsi. Dijelaskan di Bagian 4.1.3.2. Catatan asumsi mengidentifikasi asumsi dan kendala tentang produk,
proyek, lingkungan, pemangku kepentingan, dan faktor lain yang dapat memengaruhi ruang lingkup proyek dan
produk.
◆ Dokumentasi persyaratan. Dijelaskan dalam Bagian 5.2.3.1. Dokumentasi persyaratan mengidentifikasi
persyaratan yang akan dimasukkan ke dalam ruang lingkup.
◆ Daftar risiko. Dijelaskan dalam Bagian 11.2.3.1. Daftar risiko berisi strategi respons yang dapat
memengaruhi ruang lingkup proyek, seperti mengurangi atau mengubah ruang lingkup proyek dan produk
untuk menghindari atau memitigasi risiko.
Faktor-faktor lingkungan perusahaan yang dapat memengaruhi proses Define Scope termasuk namun tidak terbatas
pada:
◆ Infrastruktur,
◆ Kondisi pasar.
Aset proses organisasi yang dapat mempengaruhi proses Define Scope termasuk namun tidak terbatas pada:
◆ Kebijakan, prosedur, dan templat untuk pernyataan ruang lingkup proyek;
◆ File proyek dari proyek sebelumnya; dan
◆ Pelajaran yang dipetik dari fase atau proyek sebelumnya.
153
5.3.2 MENENTUKAN RUANG LINGKUP: ALAT DAN TEKNIK
Dijelaskan di Bagian 4.1.2.1. Keahlian harus dipertimbangkan dari individu atau kelompok yang memiliki
pengetahuan atau pengalaman dengan proyek serupa.
Contoh teknik analisis data yang dapat digunakan dalam proses ini termasuk namun tidak terbatas pada analisis
alternatif. Analisis alternatif dapat digunakan untuk mengevaluasi cara-cara untuk memenuhi persyaratan dan tujuan
yang diidentifikasi dalam piagam.
Dijelaskan di Bagian 5.1.2.2. Teknik pengambilan keputusan yang dapat digunakan dalam proses ini termasuk namun
tidak terbatas pada analisis keputusan multikriteria. Dijelaskan di Bagian 8.1.2.4, analisis keputusan multikriteria
adalah teknik yang menggunakan matriks keputusan untuk memberikan pendekatan analitis sistematis untuk
menetapkan kriteria, seperti persyaratan, jadwal, anggaran, dan sumber daya, dalam rangka menyempurnakan proyek
dan ruang lingkup produk untuk proyek tersebut.
5.3.2.4 KETERAMPILAN INTERPERSONAL DAN TIM
Dijelaskan di Bagian 4.1.2.3. Contoh teknik keterampilan interpersonal dan tim adalah fasilitasi. Fasilitasi
digunakan dalam lokakarya dan sesi kerja dengan para pemangku kepentingan utama yang memiliki berbagai
harapan atau bidang keahlian. Tujuannya adalah untuk mencapai pemahaman lintas fungsi dan pemahaman umum
tentang hasil proyek serta batasan proyek dan produk.
5.3.2.5 ANALISIS PRODUK
Analisis produk dapat digunakan untuk mendefinisikan produk dan layanan. Analisis ini mencakup pengajuan
pertanyaan tentang produk atau layanan dan menyusun jawaban untuk menggambarkan penggunaan, karakteristik,
◻
dan aspek relevan lainnya dari apa yang akan disampaikan.

◻
Setiap area aplikasi memiliki satu atau lebih metode yang diterima secara umum untuk menerjemahkan deskripsi
produk atau layanan tingkat tinggi ke dalam hasil yang bermakna. Persyaratan ditangkap pada tingkat tinggi dan
diuraikan ke tingkat detail yang diperlukan untuk mendesain produk akhir. Contoh teknik analisis produk termasuk
tetapi tidak terbatas pada:
◆ Kerusakan produk,
◆ Analisis persyaratan,
◆ Analisis sistem,
◆ Rekayasa sistem,
◆ Analisis nilai, dan
◆ Rekayasa nilai.
Bagian 1 -
154
Panduan
5.3.3 MENENTUKAN RUANG LINGKUP: KELUARAN
5.3.3.1 PERNYATAAN RUANG LINGKUP PROYEK
Pernyataan ruang lingkup proyek adalah deskripsi ruang lingkup proyek, hasil utama, asumsi, dan kendala. Pernyataan
ruang lingkup proyek mendokumentasikan seluruh ruang lingkup, termasuk ruang lingkup proyek dan produk. Pernyataan
ini menjelaskan hasil proyek secara rinci. Hal ini juga memberikan pemahaman umum tentang ruang lingkup proyek di
antara para pemangku kepentingan proyek. Pernyataan ini mungkin berisi pengecualian ruang lingkup eksplisit yang
dapat membantu dalam mengelola ekspektasi pemangku kepentingan. Hal ini memungkinkan tim proyek untuk
melakukan perencanaan yang lebih rinci, memandu pekerjaan tim proyek selama pelaksanaan, dan memberikan
dasar untuk mengevaluasi apakah permintaan untuk perubahan atau pekerjaan tambahan terkandung di dalam atau
di luar batas proyek.
Tingkat dan tingkat kerincian pernyataan ruang lingkup proyek yang mendefinisikan pekerjaan yang akan
dilakukan dan pekerjaan yang dikecualikan dapat membantu menentukan seberapa baik tim manajemen proyek dapat
mengendalikan ruang lingkup proyek secara keseluruhan. Pernyataan ruang lingkup proyek yang terperinci, baik
secara langsung maupun dengan mengacu pada dokumen lain, mencakup hal-hal berikut:
◆ Deskripsi ruang lingkup produk. Menguraikan secara progresif karakteristik produk, layanan, atau hasil
yang dijelaskan dalam piagam proyek dan dokumentasi persyaratan.
◆ Hasil kerja. Setiap produk, hasil, atau kemampuan yang unik dan dapat diverifikasi untuk melakukan layanan
yang diperlukan untuk menyelesaikan proses, fase, atau proyek. Kiriman juga mencakup hasil tambahan, seperti
laporan dan dokumentasi manajemen proyek. Hasil kerja ini dapat dijelaskan secara ringkas atau sangat
rinci.
◆ Kriteria penerimaan. Seperangkat kondisi yang harus dipenuhi sebelum hasil kerja diterima.
◆ Pengecualian proyek. Mengidentifikasi apa yang dikecualikan dari proyek. Menyatakan secara eksplisit apa
yang berada di luar cakupan proyek akan membantu mengelola ekspektasi pemangku kepentingan dan
dapat mengurangi pergeseran cakupan.
Meskipun piagam proyek dan pernyataan ruang lingkup proyek terkadang dianggap mengandung tingkat
redundansi tertentu, namun keduanya berbeda dalam hal tingkat detail yang terkandung di dalamnya. Piagam
proyek berisi informasi tingkat tinggi, sedangkan pernyataan ruang lingkup proyek berisi penjelasan rinci tentang
komponen ruang lingkup. Komponen-komponen ini diuraikan secara progresif selama proyek berlangsung. Tabel 5-1
menjelaskan beberapa elemen kunci untuk setiap dokumen.
155
Tabel 5-1. Elemen-elemen Piagam Proyek dan Pernyataan Ruang Lingkup Proyek
Piagam Proyek Pernyataan Ruang Lingkup

Proyek
Tujuan proyek
Deskripsi ruang lingkup proyek
Tujuan proyek yang terukur dan kriteria
(diuraikan secara bertahap)
keberhasilan terkait
Hasil proyek
Persyaratan tingkat tinggi
Kriteria penerimaan
Deskripsi proyek tingkat tinggi, batasan, dan
hasil utama Pengecualian
Risiko proyek secara keseluruhan proyek
Ringkasan jadwal pencapaian
Sumber daya keuangan yang telah
disetujui sebelumnya Daftar
pemangku kepentingan utama
Persyaratan persetujuan proyek (yaitu,
apa yang dimaksud dengan
keberhasilan, siapa yang memutuskan
proyek tersebut berhasil, siapa yang
menandatangani proyek tersebut)
Kriteria keluar dari proyek (yaitu, apa
saja syarat yang harus dipenuhi untuk
menutup atau membatalkan proyek atau
fase
Manajer proyek yang ditugaskan,
tanggung jawab, dan tingkat otoritas
Nama dan otoritas sponsor atau orang lain
yang mengesahkan piagam proyek
Dokumen proyek yang dapat diperbarui sebagai hasil dari pelaksanaan proses ini termasuk namun tidak terbatas pada:
◆ Log asumsi. Dijelaskan di Bagian 4.1.3.2. Catatan asumsi diperbarui dengan asumsi atau kendala
tambahan yang diidentifikasi selama proses ini.
◻
◆ Dokumentasi persyaratan. Dijelaskan dalam Bagian 5.2.3.1. Dokumentasi persyaratan dapat diperbarui
dengan persyaratan tambahan atau perubahan.
◻
◆ Matriks ketertelusuran persyaratan. Dijelaskan dalam Bagian 5.2.3.2. Matriks penelusuran persyaratan
dapat diperbarui untuk mencerminkan pembaruan dalam dokumentasi persyaratan.
◆ Daftar pemangku kepentingan. Dijelaskan dalam Bagian 13.1.3.1. Apabila informasi tambahan mengenai
pemangku kepentingan yang ada atau yang baru dikumpulkan sebagai hasil dari proses ini, maka informasi
tersebut dicatat dalam daftar pemangku kepentingan.
Bagian 1 -
156
Panduan
5.4 MEMBUAT WBS
Membuat WBS adalah proses membagi hasil proyek dan pekerjaan proyek menjadi komponen-komponen yang
lebih kecil dan lebih mudah dikelola. Manfaat utama dari proses ini adalah memberikan kerangka kerja tentang apa yang
harus disampaikan. Proses ini dilakukan sekali atau pada titik-titik yang telah ditentukan dalam proyek. Input, alat dan
teknik, dan output dari proses ini digambarkan pada Gambar 5-10. Gambar 5-11 menggambarkan diagram aliran data
dari proses tersebut.
Membuat WBS

.1 Rencana manajemen proyek .1 Penilaian ahli .1 Cakupan dasar
• Rencana pengelolaan ruang lingkup .2 Dekomposisi .2 Pembaruan dokumen proyek
.2 Dokumen proyek • Log asumsi
• Pernyataan ruang lingkup • Dokumentasi
proyek persyaratan
• Dokumentasi
persyaratan
.3 Faktor lingkungan
perusahaan
Gambar 5-10. Membuat WBS: Masukan, Alat & Teknik, dan Keluaran
Rencana
Manajemen
Proyek Rencana
Manajemen
Proyek
• Cakupan dasar
Rencana manajemen
proyek
ruang lingkup
5.4
Memb
uat - Piagam
Dokumen
WBS proyek
Proyek
Dokumen proyek Dokumen

• Pernyataan ruang lingkup
proyek Proyek
• Dokumentasi persyaratan Pembaruan dokumen proyek
• Log asumsi
• Dokumentasi persyaratan
Perusahaan/Organ
isasi

Gambar 5-11. Membuat WBS: Diagram Aliran Data
157
WBS adalah dekomposisi hirarkis dari total ruang lingkup pekerjaan yang harus dilakukan oleh tim proyek untuk
mencapai tujuan proyek dan membuat hasil yang diperlukan. WBS mengatur dan mendefinisikan ruang lingkup total proyek
dan mewakili pekerjaan yang ditentukan dalam pernyataan ruang lingkup proyek yang telah disetujui.
Pekerjaan yang direncanakan terkandung dalam komponen WBS tingkat terendah, yang disebut paket kerja. Paket
kerja dapat digunakan untuk mengelompokkan aktivitas di mana pekerjaan dijadwalkan dan diperkirakan, dipantau,
dan dikendalikan. Dalam konteks WBS, pekerjaan mengacu pada produk kerja atau hasil kerja yang merupakan hasil dari
aktivitas dan bukan pada aktivitas itu sendiri.
5.4.1 MEMBUAT WBS: MASUKAN
Komponen rencana manajemen proyek termasuk tetapi tidak terbatas pada rencana manajemen ruang lingkup.
Dijelaskan di Bagian 5.1.3.1, rencana manajemen ruang lingkup mendokumentasikan bagaimana WBS akan dibuat dari
pernyataan ruang lingkup proyek.
pada:
◆ Pernyataan ruang lingkup proyek. Dijelaskan dalam Bagian 5.3.3.1. Pernyataan ruang lingkup proyek
menjelaskan pekerjaan yang akan dilakukan dan pekerjaan yang dikecualikan.
◆ Dokumentasi persyaratan. Dijelaskan di Bagian 5.2.3.1. Persyaratan terperinci menjelaskan bagaimana
persyaratan individu memenuhi kebutuhan bisnis untuk proyek.
Faktor lingkungan perusahaan yang dapat mempengaruhi proses Create WBS termasuk tetapi tidak terbatas
pada standar WBS khusus industri yang relevan dengan sifat proyek. Standar khusus industri ini dapat berfungsi
◻
sebagai sumber referensi eksternal untuk membuat WBS.

◻
Aset proses organisasi yang dapat mempengaruhi proses Create WBS termasuk namun tidak terbatas pada:
◆ Kebijakan, prosedur, dan templat untuk WBS;
◆ File proyek dari proyek sebelumnya; dan
◆ Pelajaran yang dipetik dari proyek-proyek sebelumnya.
Bagian 1 -
158
Panduan
5.4.2 MEMBUAT WBS: ALAT DAN TEKNIK
Dijelaskan di Bagian 4.1.2.1. Keahlian harus dipertimbangkan dari individu atau kelompok yang memiliki
pengetahuan atau pengalaman dengan proyek serupa.
5.4.2.2 DEKOMPOSISI
Dekomposisi adalah teknik yang digunakan untuk membagi dan membagi lagi ruang lingkup proyek dan hasil
proyek menjadi bagian-bagian yang lebih kecil dan lebih mudah dikelola. Paket kerja adalah pekerjaan yang didefinisikan
pada tingkat terendah dari WBS yang biaya dan durasinya dapat diperkirakan dan dikelola. Tingkat dekomposisi sering kali
dipandu oleh tingkat kontrol yang diperlukan untuk mengelola proyek secara efektif. Tingkat detail untuk paket kerja akan
bervariasi sesuai dengan ukuran dan kompleksitas proyek. Penguraian total pekerjaan proyek menjadi paket-paket
pekerjaan umumnya melibatkan kegiatan-kegiatan berikut:
◆ Mengidentifikasi dan menganalisis hasil kerja dan pekerjaan terkait,
◆ Penataan dan pengorganisasian WBS,
◆ Menguraikan tingkat WBS atas menjadi komponen-komponen rinci tingkat yang lebih rendah,
◆ Mengembangkan dan menetapkan kode identifikasi untuk komponen WBS, dan
◆ Memverifikasi bahwa tingkat penguraian hasil kerja sudah sesuai.
Bagian dari WBS dengan beberapa cabang WBS yang didekomposisi ke bawah melalui tingkat paket kerja ditunjukkan
pada Gambar 5-12.
1.0
Proyek Sistem
Manajemen Nilai
1.1 1.2 1.3 1.4

Penilaian Pengembang Rekayasa Manajemen
Kebutuhan an Standar Sistem Proyek
1.1.1 1.1.2 1.1.3 1.1.4

Audit Sistem Penentuan Pengembang Pengembangan
Saat Ini Persyaratan an Alternatif Persyaratan Sistem
1.1.1.1 1.1.2.1 1.1.3.1

Identifikasi Penilaian Identifikasi
Komponen Kesenjangan Alternatif
1.1.1.2 1.1.2.2 1.1.3.2

Analisis Identifikasi Perubahan Analisis
Komponen Persyaratan Alternatif
WBS hanya bersifat ilustratif. Hal ini tidak dimaksudkan untuk mewakili cakupan proyek secara
keseluruhan dari proyek tertentu, j u g a t i d a k menyiratkan bahwa ini adalah satu-
satunya cara untuk mengatur WBS pada jenis proyek ini.
Gambar 5-12. Contoh WBS yang Diuraikan Melalui Paket Kerja
159
Struktur WBS dapat dibuat melalui berbagai pendekatan. Beberapa metode yang populer termasuk pendekatan
top-down, penggunaan pedoman khusus organisasi, dan penggunaan template WBS. Pendekatan bottom-up dapat
digunakan untuk mengelompokkan subkomponen. Struktur WBS dapat direpresentasikan dalam beberapa bentuk,
seperti:
◆ Menggunakan fase siklus hidup proyek sebagai tingkat dekomposisi kedua, dengan produk dan hasil
proyek dimasukkan pada tingkat ketiga, seperti yang ditunjukkan pada Gambar 5-13;
◆ Menggunakan hasil utama sebagai tingkat dekomposisi kedua, seperti yang ditunjukkan pada Gambar 5-14; dan
◆ Memasukkan subkomponen yang mungkin dikembangkan oleh organisasi di luar tim proyek, seperti
pekerjaan kontrak. Penjual kemudian mengembangkan WBS kontrak pendukung sebagai bagian dari
pekerjaan yang dikontrakkan.
Rilis Produk
Perangkat
Lunak 5.0
Manajeme Persyarata Desain Integrasi

Membang
n Proyek n Produk Detail dan
un
Pengujia
n
Perenca Perangka Perangka Perangka Perangka

naan t lunak t lunak t lunak t lunak
Dokument Dokument Dokument Dokument

Rapat
asi Pengguna asi Pengguna asi Pengguna asi Pengguna
Materi Program Materi Program Materi Program Materi Program

Administrasi
Pelatihan Pelatihan Pelatihan Pelatihan
Gambar 5-13. Contoh WBS yang Diatur Berdasarkan Fase

◻
◻
Bagian 1 -
160
Panduan
Sistem
Pesawa
t
Manajeme Kend Peralatan Tes dan

Pelatiha Data Fasilitas
n Proyek araan Pendukung Evaluasi
n
Udara
Manajemen Bangu
Pelatihan Perintah SE Tingkat
Rekayasa Mock-up
Sistem Peralata Teknis Organisasi nan
n Dasar
Mendukung Pelatihan Data Teknik SE Tingkat Fasilitas Uji

Kegiatan PM Fasilitas Menengah Pemelihar Operasi
aan onal
Pelatiha Data Tingkat Tes

n Manaje Depot SE Perkemb
Layanan men angan
Tes
Sistem Sistem Sistem

Badan Mesin
Komunikasi Navigasi Pengend
pesawat
alian
Kebakara
n
Gambar 5-14. Contoh WBS dengan Hasil Utama
Dekomposisi komponen WBS tingkat atas membutuhkan pembagian kerja untuk setiap hasil kerja atau
subkomponen ke dalam komponen yang paling mendasar, di mana komponen WBS mewakili produk, layanan, atau hasil
yang dapat diverifikasi. Jika pendekatan agile digunakan, epos dapat diuraikan menjadi cerita pengguna. WBS dapat
disusun sebagai garis besar, bagan organisasi, atau metode lain yang mengidentifikasi rincian hirarki. Memverifikasi
kebenaran dekomposisi memerlukan penentuan bahwa komponen WBS tingkat rendah adalah komponen yang
diperlukan dan cukup untuk menyelesaikan deliverable tingkat tinggi yang sesuai. Hasil kerja yang berbeda dapat memiliki
tingkat dekomposisi yang berbeda. Untuk sampai pada sebuah paket kerja, pekerjaan untuk beberapa deliverable hanya
perlu didekomposisi ke tingkat berikutnya, sementara yang lain membutuhkan tingkat dekomposisi tambahan. Ketika
pekerjaan diuraikan ke tingkat yang lebih rinci, kemampuan untuk merencanakan, mengelola, dan mengendalikan
pekerjaan akan meningkat. Namun, dekomposisi yang berlebihan dapat menyebabkan upaya manajemen yang tidak
produktif, penggunaan sumber daya yang tidak efisien, penurunan efisiensi dalam melakukan pekerjaan, dan kesulitan
menggabungkan data di berbagai tingkat WBS.
Penguraian mungkin tidak dapat dilakukan untuk hasil atau subkomponen yang akan diselesaikan jauh di masa
depan. Tim manajemen proyek biasanya menunggu hingga hasil atau subkomponen disepakati, sehingga rincian
WBS dapat dikembangkan. Teknik ini kadang-kadang disebut sebagai perencanaan gelombang bergulir.
161
WBS mewakili semua pekerjaan produk dan proyek, termasuk pekerjaan manajemen proyek. Total pekerjaan di
level terendah harus bergulir ke level yang lebih tinggi sehingga tidak ada yang tertinggal dan tidak ada pekerjaan
tambahan yang dilakukan. Hal ini terkadang disebut dengan aturan 100 persen.
Untuk informasi spesifik mengenai WBS, lihat Standar Praktik untuk Struktur Perincian Kerja - Edisi Kedua [15]. Standar
ini berisi contoh templat WBS khusus industri yang dapat disesuaikan dengan proyek tertentu di area aplikasi tertentu.
5.4.3 MEMBUAT WBS: KELUARAN
5.4.3.1 RUANG LINGKUP
Baseline ruang lingkup adalah versi yang disetujui dari pernyataan ruang lingkup, WBS, dan kamus WBS terkait, yang
hanya dapat diubah melalui prosedur kontrol perubahan formal dan digunakan sebagai dasar perbandingan. Ini adalah
komponen dari rencana manajemen proyek. Komponen dari baseline ruang lingkup meliputi:
◆ Pernyataan ruang lingkup proyek. Pernyataan ruang lingkup proyek mencakup deskripsi ruang lingkup
proyek, hasil utama, asumsi, dan kendala (Bagian 5.3.3.1).
◆ WBS. WBS adalah dekomposisi hirarkis dari total ruang lingkup pekerjaan yang harus dilakukan oleh tim
proyek untuk mencapai tujuan proyek dan membuat hasil yang diperlukan. Setiap tingkat WBS yang
menurun mewakili definisi yang semakin rinci dari pekerjaan proyek.
◆ Paket kerja. Tingkat terendah dari WBS adalah paket kerja dengan pengenal unik. Pengidentifikasi ini
menyediakan struktur untuk penjumlahan hirarkis biaya, jadwal, dan informasi sumber daya dan membentuk kode
akun. Setiap paket kerja merupakan bagian dari akun kontrol. Akun kontrol adalah titik kontrol manajemen di
mana ruang lingkup, anggaran, dan jadwal diintegrasikan dan dibandingkan dengan nilai yang diperoleh untuk
pengukuran kinerja. Sebuah akun kontrol memiliki dua atau lebih paket kerja, meskipun setiap paket kerja dikaitkan
dengan satu akun kontrol.
◆ Paket perencanaan. Akun kontrol dapat mencakup satu atau lebih paket perencanaan. Paket perencanaan
adalah komponen struktur rincian pekerjaan di bawah akun kontrol dan di atas paket pekerjaan dengan konten
pekerjaan yang diketahui tetapi tanpa jadwal kegiatan yang terperinci.
◻
◻
Bagian 1 -
162
Panduan
◆ Kamus WBS. Kamus WBS adalah dokumen yang menyediakan informasi detail deliverable, aktivitas, dan
penjadwalan tentang setiap komponen dalam WBS. Kamus WBS adalah dokumen yang mendukung WBS.
Sebagian b e s a r informasi yang termasuk dalam kamus WBS dibuat oleh proses lain dan ditambahkan ke
dokumen ini pada tahap selanjutnya. Informasi dalam kamus WBS dapat mencakup tetapi tidak terbatas pada:
◼ Kode pengenal akun,
◼ Deskripsi pekerjaan,
◼ Asumsi dan batasan,
◼ Organisasi yang bertanggung jawab,
◼ Jadwalkan pencapaian,
◼ Jadwal kegiatan yang terkait,
◼ Sumber daya yang dibutuhkan,
◼ Perkiraan biaya,
◼ Persyaratan kualitas,
◼ Kriteria penerimaan,
◼ Referensi teknis, dan
◼ Informasi perjanjian.
Dokumen proyek yang dapat diperbarui sebagai hasil dari pelaksanaan proses ini termasuk namun tidak terbatas pada:
◼ Log asumsi. Dijelaskan di Bagian 4.1.3.2. Log asumsi diperbarui dengan asumsi atau kendala tambahan
yang diidentifikasi selama proses Create WBS.
◼ Dokumentasi persyaratan. Dijelaskan di Bagian 5.2.3.1. Dokumentasi persyaratan dapat diperbarui untuk
menyertakan perubahan yang disetujui yang dihasilkan dari proses Create WBS.
163
5.5 RUANG LINGKUP VALIDASI
Validate Scope adalah proses memformalkan penerimaan hasil proyek yang telah selesai. Manfaat utama dari proses
ini adalah memberikan objektivitas pada proses penerimaan dan meningkatkan probabilitas penerimaan produk,
layanan, atau hasil akhir dengan memvalidasi setiap hasil. Proses ini dilakukan secara berkala selama proyek
berlangsung sesuai kebutuhan. Input, alat dan teknik, serta output dari proses ini digambarkan pada Gambar 5-15.
Gambar 5-16 menggambarkan diagram aliran data dari proses tersebut.
Memvalidasi Ruang Lingkup

.1 Rencana manajemen proyek .1 Inspeksi .1 Hasil kerja yang diterima
• Rencana pengelolaan .2 Pengambilan keputusan .2 Informasi prestasi
ruang lingkup • Pemungutan suara kerja
• Rencana manajemen .3 Permintaan perubahan
persyaratan .4 Pembaruan dokumen proyek
• Cakupan dasar • Daftar pelajaran yang dipetik
.2 Dokumen proyek • Dokumentasi
• Daftar pelajaran yang persyaratan
dipetik • Matriks penelusuran
• Laporan kualitas persyaratan
• Dokumentasi
persyaratan
• Matriks penelusuran
persyaratan
.3 Hasil kerja yang terverifikasi
.4 Data prestasi kerja
Gambar 5-15. Memvalidasi Ruang Lingkup: Masukan, Alat & Teknik, dan Keluaran
◻
◻
Bagian 1 -
164
Panduan

Extracted Pages From PMI Project Management Body of Knowledge PMBoK 151-200 Id

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Extracted Pages From PMI Project Management Body of Knowledge PMBoK 151-200 Id

Diunggah oleh

Hak Cipta:

Format Tersedia

Subscribe to DeepL Pro to translate larger documents.

Visit www.DeepL.com/pro for more information.

Rencana Perusahaan 4.3

5.5 9.4 11.5 12.2

5.6. 9.5 11.6 12.3

6.6 9.6 11.7 13.1

4.6.1.1 RENCANA MANAJEMEN PROYEK

4.6.1.2 DOKUMEN PROYEK

4.6.1.3 LAPORAN PRESTASI KERJA

4.6.1.5 FAKTOR LINGKUNGAN PERUSAHAAN

4.6.1.6 ASET PROSES ORGANISASI

4.6.2.1 PENILAIAN AHLI

◆ Undang-undang dan peraturan,

◆ Hukum dan pengadaan,

◆ Manajemen konfigurasi, dan

4.6.2.2 ALAT KONTROL PERUBAHAN

◆ Mendokumentasikan perubahan. Mendokumentasikan perubahan ke dalam permintaan perubahan yang tepat.

4.6.2.3 ANALISIS DATA

4.6.2.4 PENGAMBILAN KEPUTUSAN

serangkaian kriteria yang telah ditetapkan.

4.6.3 MELAKUKAN KONTROL PERUBAHAN TERINTEGRASI: KELUARAN

4.6.3.1 PERMINTAAN PERUBAHAN YANG DISETUJUI

4.6.3.2 PEMBARUAN RENCANA MANAJEMEN PROYEK

4.6.3.3 PEMBARUAN DOKUMEN PROYEK

Menutup Proyek atau Fase

Masukan Alat & Teknik Keluaran

Rencana manajemen Pelanggan

• Dokumentasi pengadaan • Perjanjian • Kasus bisnis - Aset proses organisasi

Gambar 4-15. Menutup Proyek atau Fase: Diagram Aliran Data

◼ Mengumpulkan catatan proyek atau fase,

berikutnya atau ke produksi dan/atau operasi.

4.7.1.1 PIAGAM PROYEK

4.7.1.2 RENCANA MANAJEMEN PROYEK

4.7.1.3 DOKUMEN PROYEK

4.7.1.4 HASIL YANG DITERIMA

4.7.1.5 DOKUMEN BISNIS

4.7.1.7 DOKUMENTASI PENGADAAN

4.7.2 MENUTUP PROYEK ATAU FASE: ALAT DAN TEKNIK

4.7.2.1 PENILAIAN AHLI

◆ Hukum dan pengadaan, dan

◆ Undang-undang dan peraturan.

4.7.2.2 ANALISIS DATA

4.7.3 MENUTUP PROYEK ATAU FASE: KELUARAN

4.7.3.1 PEMBARUAN DOKUMEN PROYEK

4.7.3.2 TRANSISI PRODUK, LAYANAN, ATAU HASIL AKHIR

4.7.3.3 LAPORAN AKHIR

◆ Deskripsi tingkat ringkasan proyek atau fase.

◆ Ringkasan informasi validasi untuk produk, layanan, atau hasil akhir.

4.7.3.4 PEMBARUAN ASET PROSES ORGANISASI

lengkap dalam Panduan PMBOK®.

5.1 Ruang Lingkup 5.2

Gambar 5-1. Gambaran Umum Manajemen Lingkup Proyek

Dalam konteks proyek, istilah "ruang lingkup" dapat

PERTIMBANGAN UNTUK LINGKUNGAN YANG LINCAH/ADAPTIF

Manajemen Lingkup Rencana

Masukan Alat & Teknik Keluaran

Rencana 5.1 Rencana

• Faktor lingkungan perusahaan

Gambar 5-3. Manajemen Lingkup Rencana: Diagram Aliran Data

5.1.1 MANAJEMEN RUANG LINGKUP RENCANA: MASUKAN

5.1.1.1 PIAGAM PROYEK

5.1.1.2 RENCANA MANAJEMEN PROYEK

5.1.1.3 FAKTOR LINGKUNGAN PERUSAHAAN

◆ Administrasi personalia, dan