Manajemen Cakupan

Proyek
(Project Scope Management)
Oleh Ruangguru
Pertemuan 5
 Pendidikan

Sarjana Komunikasi Hubungan

Masyarakat, Universitas Paramadina
Magister Manajemen Marketing,
Universitas Negeri Jakarta

Pengalaman Kerja

Advertising and Promotion, Trax FM

Semarang
Account Executive, Goers
Nama Expert
Sales Executive, Moka POS
Account Manager, Ruangguru
Tujuan Pembelajaran

Menjelaskan Pentingnya Project Scope Management

Menjelaskan Proses Project Scope Management
Membuat Work Breakdown Structure (WBS)
Project Scope
Management
Project Scope Management

Cakupan mengacu pada semua

pekerjaan yang terlibat dalam
menciptakan produk dari proyek dan
proses yang digunakan untuk
membuatnya

Produk yang dihasilkan sebagai

bagian dari proyek, seperti perangkat
keras atau perangkat lunak, dokumen
perencanaan, atau notulen rapat
Project Scope Management

Manajemen cakupan proyek

mencakup proses yang terlibat dalam
mendefinisikan dan mengendalikan
apa yang termasuk atau tidak dalam
sebuah proyek.
Memastikan bahwa tim proyek dan
pemangku kepentingan memiliki
pemahaman yang sama tentang produk
apa yang akan dihasilkan proyek dan
proses apa yang akan digunakan tim
proyek untuk memproduksinya
Proses Project Scope Management

Planning scope
Collecting requirements
Defining scope
Creating the WBS
Validating scope
Controlling scope
 “
Planning Scope
1. Planning Scope

PLANNING SCOPE MANAGEMENT

Menentukan bagaimana ruang lingkup dan persyaratan

proyek akan dikelola.
Rencana Scope Management mencakup informasi berikut:
● Bagaimana menyiapkan pernyataan ruang lingkup proyek yang
terperinci
● Cara membuat WBS
● Cara memelihara dan menyetujui WBS
● Bagaimana mendapatkan penerimaan resmi dari proyek yang telah
selesai
● Bagaimana mengontrol permintaan untuk perubahan pada lingkup
proyek
1. Planning Scope

REQUIREMENTS MANAGEMENT PLAN

The PMBOK® Guide, Fifth Edition,

menjelaskan requirements sebagai :
“kondisi atau kemampuan yang harus dipenuhi oleh proyek atau yang ada dalam
produk, layanan, atau hasil untuk memenuhi kesepakatan atau spesifikasi lain
yang dipaksakan secara formal”
 “
COLLECTING
REQUIREMENT
2. Collecting Requirement

COLLECTING REQUIREMENT

● Langkah kedua dalam manajemen cakupan yang paling sulit:

mengumpulkan persyaratan.
● Konsekuensi utama dari tidak mendefinisikan persyaratan dengan baik
adalah pengerjaan ulang, yang dapat menghabiskan hingga setengah
dari biaya proyek, terutama untuk proyek pengembangan perangkat
lunak
● Untuk beberapa proyek TI, akan sangat membantu untuk membagi
pengembangan persyaratan ke dalam kategori yang disebut elisitasi,
analisis, spesifikasi, dan validasi
● Penting untuk menggunakan pendekatan berulang untuk
mendefinisikan persyaratan karena sering tidak jelas di awal proyek
2. Collecting Requirement
METODE UNTUK MENGUMPULKAN PERSYARATAN
Interviewing
Focus groups and facilitated workshops
Using group creativity and decision-making techniques
Questionnaires and surveys
Observation
Prototyping
Benchmarking
2. Collecting Requirement

REQUIREMENTS TRACEABILITY MATRIX

● Persyaratan sering dipecah menjadi kategori yang berbeda seperti

persyaratan fungsional, persyaratan layanan, persyaratan kinerja,
persyaratan kualitas, dan persyaratan pelatihan
● Sebuah Requirement Traceability Matrix (RTM) adalah tabel yang
mencantumkan persyaratan, berbagai atribut dari setiap persyaratan,
dan status persyaratan untuk memastikan bahwa semua persyaratan
ditangani.
● Contoh RTM:
 “
Defining Scope
3. Defining Scope

Definisi ruang lingkup yang baik sangat penting untuk

keberhasilan proyek karena membantu meningkatkan
akurasi perkiraan waktu, biaya, dan sumber daya,
mendefinisikan dasar untuk pengukuran kinerja dan
pengendalian proyek, dan membantu dalam
mengkomunikasikan tanggung jawab kerja yang jelas.
3. Defining Scope

● Hal ini juga membantu untuk mendokumentasikan

informasi terkait ruang lingkup lainnya, seperti batas-batas
proyek, kendala, dan asumsi. Pernyataan ruang lingkup
proyek juga harus merujuk pada dokumen pendukung,
seperti spesifikasi produk

● Seiring berjalannya waktu, cakupan proyek harus menjadi

lebih jelas dan lebih spesifik
 “
Creating WBS
4. Creating WBS
THE WORK BREAKDOWN STRUCTURE

● WBS adalah pengelompokan pekerjaan yang berorientasi pada

pengiriman yang terlibat dalam proyek yang mendefinisikan cakupan
total proyek
● WBS adalah dokumen dasar yang menyediakan dasar untuk
perencanaan dan pengelolaan jadwal proyek, biaya, sumber daya, dan
perubahan
● Dekomposisi adalah membagi hasil proyek menjadi bagian-bagian
yang lebih kecil
● Paket pekerjaan adalah tugas di level terendah dari WBS
● Garis dasar ruang lingkup mencakup pernyataan cakupan proyek
yang disetujui dan kamus WBS dan WBS yang terkait
4. Creating WBS

CONTOH INTRANET WBS DIORGANISASI MENURUT PRODUK

4. Creating WBS
CONTOH WBS INTRANET YANG DIORGANISASI
BERDASARKAN FASE DAN FORMULIR TABULAR
4. Creating WBS
INTRANET WBS DAN GANTT CHART DALAM
MICROSOFT PROJECT
4. Creating WBS

PENDEKATAN PENGEMBANGAN WBS

1. Menggunakan pedoman: Beberapa organisasi, seperti DOD,

memberikan pedoman untuk mempersiapkan WBS
2. Pendekatan analogi: Tinjau WBS proyek serupa dan sesuaikan
dengan proyek Anda
3. Pendekatan top-down: Mulailah dengan item proyek terbesar
dan uraikan
4. Pendekatan bottom-up: Mulailah dengan tugas-tugas spesifik
dan gulung ke atas
5. Pendekatan Mind-mapping: Pemetaan pikiran adalah teknik
yang menggunakan cabang-cabang yang memancar dari ide
inti untuk menyusun pemikiran dan ide
4. Creating WBS
CONTOH PENDEKATAN MIND-MAPPING
UNTUK MEMBUAT WBS
Banyak tugas WBS yang tidak jelas dan harus dijelaskan lebih banyak
sehingga orang tahu apa yang harus dilakukan dan dapat
memperkirakan berapa lama waktu yang dibutuhkan dan berapa biaya
untuk melakukan pekerjaan tersebut.
4. Creating WBS

DASAR KAS DAN LINGKUP WBS

Kamus WBS adalah dokumen yang menjelaskan informasi

rinci tentang setiap item WBS
4. Creating WBS
Saran Untuk Membuat WBS dan Kamus WBS
● Sebuah unit kerja harus muncul hanya di satu tempat di WBS.
● Konten kerja item WBS adalah jumlah item WBS di bawahnya
● Item WBS hanya menjadi tanggung jawab satu individu, meskipun mungkin
banyak orang yang mengerjakannya
● WBS harus konsisten dengan cara kerja yang sebenarnya akan dilakukan; itu
harus melayani tim proyek terlebih dahulu, dan tujuan lain hanya jika praktis
● Anggota tim proyek harus dilibatkan dalam mengembangkan WBS untuk
memastikan konsistensi dan pembelian
● Setiap item WBS harus didokumentasikan dalam kamus WBS untuk memastikan
pemahaman yang akurat tentang ruang lingkup pekerjaan yang termasuk dan
tidak termasuk dalam item tersebut
● WBS harus menjadi alat yang fleksibel untuk mengakomodasi perubahan yang
tak terhindarkan sambil mempertahankan kontrol konten pekerjaan dalam proyek
dengan benar sesuai dengan pernyataan ruang lingkup
 “
Validating Scope
5. Validating Scope

● Sangat sulit untuk membuat pernyataan lingkup dan WBS yang baik untuk
sebuah proyek.
● Lebih sulit lagi untuk memverifikasi ruang lingkup proyek dan meminimalkan
perubahan ruang lingkup
● Bahkan ketika ruang lingkup proyek didefinisikan dengan cukup baik, banyak
proyek TI mengalami creep scope—kecenderungan ruang lingkup proyek
untuk terus menjadi lebih besar dan lebih besar.
● Validasi scope melibatkan penerimaan formal dari kiriman proyek yang
telah selesai
5. Validating Scope

● Penerimaan sering dicapai dengan inspeksi pelanggan dan kemudian

menandatangani kiriman utama
● Untuk meminimalkan perubahan ruang lingkup, sangat penting untuk
melakukan pekerjaan manajemen konfigurasi dengan baik dan memvalidasi
ruang lingkup proyek
● Keluaran utama dari validasi ruang lingkup adalah kiriman yang diterima,
permintaan perubahan, informasi kinerja kerja, dan pembaruan dokumen
proyek
 “
Controlling Scope
6. Controlling Scope

● Kontrol ruang lingkup melibatkan pengendalian perubahan

pada ruang lingkup proyek
● Tujuan pengendalian ruang lingkup adalah untuk
○ mempengaruhi faktor-faktor yang menyebabkan
perubahan ruang lingkup
○ memastikan perubahan diproses sesuai dengan
prosedur yang dikembangkan sebagai bagian dari
kontrol perubahan terintegrasi, dan
○ mengelola perubahan saat terjadi
● Varians adalah perbedaan antara kinerja yang
direncanakan dan aktual
6. Controlling Scope

SARAN UNTUK MENINGKATKAN INPUT PENGGUNA

● Kembangkan proses pemilihan proyek yang baik dan tegaskan

bahwa sponsor berasal dari organisasi pengguna
● Memiliki pengguna di tim proyek dalam peran penting
● Adakan pertemuan rutin dengan agenda yang ditentukan, dan
minta pengguna menandatangani kiriman utama yang disajikan
pada pertemuan
● Kirimkan sesuatu kepada pengguna dan sponsor secara teratur
● Jangan berjanji untuk memberikan ketika Anda tahu Anda tidak
bisa
● Cari pengguna bersama dengan pengembang
6. Controlling Scope
SARAN UNTUK MENGURANGI PERSYARATAN
YANG TIDAK LENGKAP DAN BERUBAH
● Kembangkan dan ikuti proses manajemen persyaratan
● Gunakan teknik seperti prototyping, use case modeling, dan JAD untuk
mendapatkan lebih banyak keterlibatan pengguna
● Cantumkan persyaratan secara tertulis dan jaga agar tetap terkini
● Buat database manajemen persyaratan untuk mendokumentasikan dan
mengendalikan persyaratan
● Menyediakan pengujian yang memadai dan melakukan pengujian
sepanjang siklus hidup proyek
● Tinjau perubahan dari perspektif sistem
● Tekankan tanggal penyelesaian untuk membantu fokus pada apa yang
paling penting
● Alokasikan sumber daya secara khusus untuk menangani permintaan
perubahan/peningkatan seperti yang dilakukan NWA dengan ResNet
6. Controlling Scope
MENGGUNAKAN PERANGKAT LUNAK UNTUK
MEMBANTU DALAM MANAJEMEN LINGKUP PROYEK

● Perangkat lunak pengolah kata membantu membuat beberapa

dokumen terkait ruang lingkup
● Spreadsheet membantu melakukan perhitungan keuangan,
menimbang model penilaian, dan mengembangkan bagan dan grafik
● Perangkat lunak komunikasi seperti email dan Web membantu
memperjelas dan mengkomunikasikan informasi ruang lingkup
● Perangkat lunak manajemen proyek membantu dalam membuat
WBS, dasar untuk tugas pada bagan Gantt
● Perangkat lunak khusus tersedia untuk membantu dalam
manajemen lingkup proyek
PERTIMBANGAN UNTUK
LINGKUNGAN AGILE/ADAPTIF

Dalam proyek dengan persyaratan yang

berkembang, risiko tinggi, atau ketidakpastian
yang signifikan, scope sering tidak dipahami
pada awal proyek atau berkembang selama
proyek.

Metode Agile sengaja menghabiskan lebih sedikit

waktu untuk mencoba mendefinisikan dan
menyetujui ruang lingkup pada tahap awal proyek
dan menghabiskan lebih banyak waktu untuk
menetapkan proses untuk penemuan dan
penyempurnaan yang sedang berlangsung.
PERTIMBANGAN UNTUK
LINGKUNGAN AGILE/ADAPTIF

Banyak lingkungan dengan persyaratan yang

muncul menemukan bahwa sering ada
kesenjangan antara persyaratan bisnis nyata dan
persyaratan bisnis yang awalnya dinyatakan.

Oleh karena itu, metode tangkas dengan sengaja

membangun dan meninjau prototipe dan merilis
versi untuk menyempurnakan persyaratan.
Akibatnya, ruang lingkup didefinisikan dan
didefinisikan ulang di seluruh proyek. Dalam
pendekatan tangkas, persyaratan merupakan
Backlog.
Ada Pertanyaan?
Thank You
 Materi Pertemuan Selanjutnya

Manajemen Waktu Proyek

(Project Time Management)