Buku Manajemen Proyek-110-174

Machine Translated by Google
Bab 3
Proyek
Pengelolaan
Grup Proses
Tujuan pembelajaran
Setelah membaca bab ini, Anda akan dapat:
•Jelaskan lima kelompok proses manajemen proyek, tingkat aktivitas masing-masing kelompok,
dan interaksi di antara kelompok tersebut
• Mengaitkan kelompok proses manajemen proyek dengan proyek

bidang pengetahuan manajemen
•Diskusikan bagaimana organisasi mengembangkan proyek teknologi informasi (TI).

metodologi manajemen untuk memenuhi kebutuhan mereka
• Meninjau studi kasus organisasi yang menerapkan proyek

kelompok proses manajemen untuk mengelola proyek TI, menggambarkan keluaran dari
setiap kelompok proses, dan memahami kontribusi yang diberikan oleh permulaan,
perencanaan, pelaksanaan, pemantauan dan pengendalian, dan penutupan yang
efektif terhadap keberhasilan proyek
•Meninjau studi kasus dari proyek yang sama yang dikelola dengan fokus agile dan
membandingkan perbedaan utama antara pendekatan agile dan pendekatan
prediktif. •Menjelaskan
beberapa templat untuk membuat dokumen untuk setiap kelompok proses

86 bagian 3
Pembukaan C ase
Erica Bell bertanggung jawab atas Kantor Manajemen Proyek (PMO) untuk perusahaan konsultannya,
JWD Consulting, yang telah berkembang hingga mencakup lebih dari 200 konsultan penuh waktu
dan bahkan lebih banyak lagi konsultan paruh waktu. JWD Consulting menyediakan berbagai
layanan konsultasi untuk membantu organisasi dalam memilih dan mengelola proyek TI. Perusahaan
berfokus pada menemukan dan mengelola proyek dengan bayaran tinggi dan mengembangkan metrik
yang kuat untuk mengukur kinerja dan manfaat proyek bagi organisasi setelah proyek dilaksanakan.
Penekanan perusahaan pada metrik dan kerja sama dengan pelanggan memberikannya keunggulan
dibandingkan banyak pesaing.
Joe Fleming, sang CEO, ingin perusahaannya terus berkembang dan menjadi organisasi
konsultan kelas dunia. Karena inti bisnisnya adalah membantu organisasi lain dalam manajemen
proyek, ia merasa penting bagi JWD Consulting untuk memiliki proses yang patut dicontoh dalam
mengelola proyeknya sendiri. Dia meminta Erica untuk bekerja dengan timnya dan konsultan lain di
perusahaan tersebut untuk mengembangkan beberapa aplikasi situs intranet yang memungkinkan
mereka berbagi pengetahuan manajemen proyek. Dia juga berpikir bahwa perusahaan harus
menyediakan beberapa informasi kepada klien perusahaan. Misalnya, perusahaan dapat
menyediakan templat manajemen proyek, alat, artikel, tautan ke situs lain, dan fitur Tanya Ahli
untuk membantu membangun hubungan dengan klien saat ini dan masa depan. Karena JWD
Consulting menekankan pentingnya proyek dengan bayaran tinggi, Joe juga ingin melihat kasus
bisnis untuk proyek ini sebelum melanjutkan.
Ingat dari Bab 1 bahwa manajemen proyek terdiri dari 10 bidang pengetahuan: integrasi, ruang
lingkup, jadwal, biaya, kualitas, sumber daya, komunikasi, risiko, pengadaan, dan
manajemen pemangku kepentingan. Konsep penting lainnya untuk dipahami adalah bahwa proyek
melibatkan lima kelompok proses manajemen proyek: permulaan, perencanaan, pelaksanaan,
pemantauan dan pengendalian, dan penutupan. Menyesuaikan kelompok proses ini untuk memenuhi
kebutuhan masing-masing proyek akan meningkatkan peluang keberhasilan dalam mengelola proyek.
Bab ini menjelaskan setiap kelompok proses manajemen proyek secara rinci melalui studi kasus
simulasi berdasarkan JWD Consulting. Ini juga mencakup contoh dokumen proyek tipikal yang
diterapkan pada kasus ini. Anda dapat mengunduh templat untuk dokumen ini dan dokumen proyek
lainnya dari situs web Pendamping untuk teks ini. Meskipun Anda akan mempelajari lebih lanjut tentang
masing-masing bidang pengetahuan di Bab 4 hingga 13, pertama-tama penting untuk mempelajari
bagaimana pengetahuan tersebut sesuai dengan gambaran besar pengelolaan sebuah proyek.
Memahami bagaimana bidang pengetahuan dan kelompok proses manajemen proyek berfungsi
bersama akan memberikan konteks pada bab-bab selanjutnya.
Grup Proses Manajemen Proyek
Manajemen proyek adalah upaya integratif. Keputusan dan tindakan yang diambil dalam satu
bidang pengetahuan pada waktu tertentu biasanya mempengaruhi bidang pengetahuan lainnya.
Mengelola interaksi ini sering kali memerlukan trade-off antara ruang lingkup, waktu, dan biaya proyek—
tiga kendala dalam manajemen proyek yang dijelaskan di Bab 1. Manajer proyek mungkin juga perlu
melakukan trade-off antar bidang pengetahuan, misalnya antara pengelolaan risiko dan sumber daya.
Akibatnya, Anda dapat melihat manajemen proyek sebagai sejumlah proses terkait.
Grup Proses Manajemen Proyek 87
Proses adalah serangkaian tindakan yang diarahkan menuju hasil tertentu . Kelompok proses
manajemen proyek berkembang dari memulai aktivitas ke aktivitas perencanaan, melaksanakan aktivitas, memantau
dan mengendalikan aktivitas, dan menutup aktivitas. Ingatlah bahwa suatu proyek dapat memiliki kombinasi tahapan
yang berbeda. Satu proyek mungkin memiliki fase konsep, pengembangan, implementasi, dan penyelesaian, dan proyek
lainnya mungkin memiliki fase awal, menengah, dan akhir. Namun semua proyek dan semua fase proyek harus
mencakup kelima kelompok proses. Anda tidak dapat menyamakan grup proses dengan fase proyek. Misalnya, manajer
dan tim proyek perlu mengkaji ulang kebutuhan bisnis terhadap proyek, bagian dari aktivitas pemantauan dan pengendalian,
selama setiap fase siklus hidup proyek untuk menentukan apakah proyek layak dilanjutkan.
• Memulai proses mencakup pendefinisian dan otorisasi suatu proyek atau fase proyek. Proses inisiasi
berlangsung selama setiap fase proyek. Misalnya, dalam fase penutupan, proses inisiasi digunakan
untuk memastikan bahwa tim proyek menyelesaikan semua pekerjaan, bahwa seseorang
mendokumentasikan pembelajaran, dan bahwa pelanggan menerima pekerjaan tersebut.
• Proses perencanaan mencakup perancangan dan pemeliharaan skema yang dapat diterapkan untuk
memastikan bahwa proyek memenuhi kebutuhan organisasi. Proyek mencakup beberapa rencana, seperti
rencana pengelolaan ruang lingkup, rencana pengelolaan jadwal, rencana pengelolaan biaya, dan
rencana pengelolaan pengadaan. Rencana ini mendefinisikan setiap bidang pengetahuan yang
berkaitan dengan proyek pada titik waktu tertentu. Misalnya, tim proyek harus mengembangkan rencana
untuk menentukan pekerjaan yang diperlukan untuk proyek tersebut, menjadwalkan aktivitas yang
terkait dengan pekerjaan tersebut, memperkirakan biaya untuk melaksanakan pekerjaan, dan memutuskan
sumber daya apa yang harus diperoleh untuk menyelesaikan pekerjaan tersebut. Untuk
memperhitungkan perubahan kondisi proyek dan organisasi, tim proyek sering merevisi rencana selama
setiap fase siklus hidup proyek. Rencana manajemen proyek, yang dijelaskan dalam Bab 4,
mengoordinasikan dan mencakup informasi dari semua rencana lainnya.
• Proses pelaksanaan mencakup koordinasi orang dan sumber daya lainnya untuk melakukan hal tersebut
melaksanakan berbagai rencana dan menciptakan produk, layanan, atau hasil proyek atau fase.
Contoh proses pelaksanaan termasuk mengarahkan dan mengelola pekerjaan proyek, mengelola
pengetahuan proyek, memperoleh sumber daya, dan melakukan pengadaan.
• Proses pemantauan dan pengendalian mencakup pengukuran dan pemantauan kemajuan secara
berkala untuk memastikan bahwa tim proyek memenuhi tujuan proyek. Manajer proyek dan
staf memantau dan mengukur kemajuan terhadap rencana dan mengambil tindakan perbaikan
bila diperlukan. Proses pemantauan dan pengendalian yang umum adalah pelaporan kinerja, di
mana pemangku kepentingan proyek dapat mengidentifikasi perubahan apa pun yang diperlukan untuk
menjaga proyek tetap berjalan pada jalurnya.
• Proses penutupan mencakup formalisasi penerimaan proyek atau fase proyek dan mengakhirinya secara
efisien. Kegiatan administratif sering kali terlibat dalam kelompok proses ini, seperti pengarsipan file
proyek, mendokumentasikan pembelajaran, dan menerima penerimaan formal atas pekerjaan yang
diserahkan sebagai bagian dari fase atau proyek.
88 bagian 3
Kelompok proses tidak saling eksklusif. Misalnya, manajer proyek harus

melakukan proses pemantauan dan pengendalian sepanjang masa proyek. Artinya, proses pemantauan dan pengendalian
terjadi secara bersamaan di seluruh proyek dengan proses inisiasi, perencanaan, pelaksanaan, dan penutupan. Memulai
dan merencanakan proses dapat terjadi bersamaan dengan pelaksanaan proses, dan seterusnya untuk setiap kelompok
proses.
Tingkat aktivitas dan lamanya masing-masing kelompok proses berbeda-beda untuk setiap proyek.
Biasanya, pelaksanaan tugas memerlukan sumber daya dan waktu paling banyak, diikuti dengan tugas perencanaan.
Tugas memulai dan menutup biasanya merupakan tugas yang paling singkat (masing-masing pada awal dan akhir proyek
atau fase), dan memerlukan sumber daya dan waktu paling sedikit. Namun, setiap proyek adalah unik, jadi pengecualian
mungkin saja terjadi.
Anda dapat menerapkan grup proses untuk setiap fase utama atau iterasi suatu proyek, atau Anda dapat menerapkan grup
proses ke keseluruhan proyek. Contoh pertama dari studi kasus JWD Consulting menerapkan kelompok proses pada keseluruhan
proyek. Contoh kedua menunjukkan bagaimana Anda dapat menggunakan pendekatan yang lebih tangkas untuk mengelola
proyek yang sama; beberapa kelompok proses diulang untuk setiap iterasi proyek.
Banyak orang meminta pedoman tentang berapa banyak waktu yang harus dihabiskan dalam setiap kelompok proses.
Dalam bukunya Alpha Project Managers: What the Top 2 persen Know That Everyone Else Does Not, Andy Crowe
mengumpulkan data dari 860 manajer proyek di berbagai perusahaan dan industri di Amerika Serikat. Ia menemukan bahwa
manajer proyek terbaik—manajer proyek alfa—menghabiskan lebih banyak waktu pada setiap kelompok proses, kecuali
pelaksanaan, dibandingkan rekan mereka seperti yang ditunjukkan pada Gambar 3-1. Perhatikan bahwa manajer proyek
alfa menghabiskan hampir dua kali lebih banyak waktu untuk perencanaan (21 persen berbanding 11 persen) dibandingkan
manajer proyek lainnya. Menghabiskan lebih banyak waktu untuk perencanaan akan mengurangi waktu yang dihabiskan
untuk pelaksanaan, sehingga mengurangi waktu dan uang yang dihabiskan untuk proyek. Manajer proyek terbaik mengetahui
dan mempraktikkan konsep penting ini—melakukan perencanaan dengan baik.1
2%
Penutupan
3%
4%
Pemantauan dan Pengendalian
5%
82%
Eksekusi
69%
11%
Perencanaan
21% Menghabiskan lebih banyak waktu
pada perencanaan seharusnya
1% membayar dalam eksekusi
Memulai
2%
Manajer Proyek Lainnya Manajer Proyek Alpha
Sumber: Andy Crowe

Gambar 3-1 Persentase waktu yang dihabiskan pada setiap kelompok proses
Apa yang salah?
Banyak pembaca majalah CIO mengomentari cerita sampulnya tentang masalah sistem informasi di
Internal Revenue Service (IRS) AS. Artikel tersebut menjelaskan masalah serius yang dialami IRS dalam mengelola
proyek TI. Mereka gagal lebih dari satu kali dalam proyek-proyek yang berupaya memodernisasi sistem mereka
yang menua. Philip A. Pell, PMP®, percaya bahwa memiliki manajer proyek yang baik dan mengikuti proses
manajemen proyek yang baik akan sangat membantu IRS dan banyak organisasi. Pell memberikan masukan
berikut untuk artikel tersebut:
Manajemen proyek yang murni dan sederhana, baik, berpusat pada metodologi, dapat diprediksi, dan
dapat diulang adalah TUNGGAL faktor terbesar dalam keberhasilan (atau dalam hal ini kegagalan) dari
setiap proyek. Ketika pemangku kepentingan utama mengatakan, “Saya tidak tahu betapa buruknya
keadaan,” ini merupakan dakwaan langsung terhadap rencana manajemen komunikasi manajer proyek.2
IRS terus menghadapi masalah serius dalam mengelola infrastruktur TI yang menua,
dan kurangnya perencanaan yang tepat masih dipertanyakan. IRS menghabiskan $2,7 miliar setiap
tahunnya untuk bidang TI, dengan sekitar 70 persennya digunakan untuk sistem lama, seperti
Individual Master File yang ditulis pada tahun 1960an. IRS mengelola lebih dari 20 juta saluran
kode perakitan. Sistem mereka adalah kunci untuk mengumpulkan lebih dari $3 triliun pajak. Dalam subkomite
House Ways and Means pada akhir tahun 2017, Rep. Vern Buchanan mengatakan kepada eksekutif IRS
bahwa dia ingin melihat sebuah rencana, termasuk justifikasi finansial yang kuat, untuk permintaan
pendanaan baru-baru ini. “Pertanyaannya adalah untuk mempunyai sebuah rencana, apa keuntungan dari
rencana tersebut dalam hal dana teknologi yang dibelanjakan. . . . Saya sangat suka membuat perencanaan,
secara pribadi, sebagai pebisnis, jika Anda tidak memiliki visi, Anda akan binasa.”3
Masing-masing dari lima kelompok proses manajemen proyek ditandai dengan penyelesaiannya
dari tugas-tugas tertentu. Saat memulai proses untuk proyek baru, organisasi mengakui adanya
proyek baru dan menyelesaikan piagam proyek sebagai bagian dari pengakuan ini. (Lihat Bab 4
untuk informasi lebih lanjut mengenai piagam proyek.) Tabel disediakan kemudian dalam bab ini
dengan daftar rinci kemungkinan keluaran untuk setiap kelompok proses berdasarkan bidang pengetahuan.
Misalnya, Tabel 3-3 hingga 3-7 mencantumkan keluaran potensial untuk kelompok proses permulaan
dan perencanaan. Contoh dari beberapa keluaran disediakan untuk setiap kelompok proses dalam
studi kasus proyek situs intranet manajemen proyek JWD Consulting. Manajer proyek dan timnya
harus memutuskan keluaran mana yang diperlukan untuk proyek khusus mereka.
Keluaran dari kelompok proses perencanaan meliputi penyelesaian pernyataan ruang
lingkup proyek, struktur rincian kerja (WBS), jadwal proyek, dan banyak item lainnya. Proses
perencanaan sangat penting untuk proyek TI. Siapa pun yang pernah bekerja pada proyek TI
besar yang melibatkan teknologi baru pasti mengetahui pepatah, “Satu dolar yang dikeluarkan
di muka untuk perencanaan bernilai seratus dolar yang dikeluarkan setelah sistem
diimplementasikan.” Perencanaan sangat penting dalam proyek TI karena ketika tim proyek
mengimplementasikan sistem baru, diperlukan upaya besar untuk mengubahnya. Penelitian menunjukkan
bahwa perusahaan yang berupaya menerapkan praktik terbaik harus menghabiskan setidaknya 20
persen waktu proyek untuk memulai dan merencanakan.4 Persentase ini didukung oleh bukti dari
manajer proyek Alpha, seperti yang dijelaskan sebelumnya.
90 bagian 3
Kelompok proses pelaksana mengambil tindakan yang diperlukan untuk menyelesaikan pekerjaan
yang dijelaskan dalam kegiatan perencanaan. Hasil utama dari kelompok proses ini adalah penyampaian
pekerjaan proyek yang sebenarnya. Misalnya, jika sebuah proyek TI melibatkan penyediaan perangkat
keras, perangkat lunak, dan pelatihan baru, proses pelaksanaannya akan mencakup memimpin tim proyek
dan pemangku kepentingan lainnya untuk membeli perangkat keras, mengembangkan dan menguji
perangkat lunak, serta menyampaikan dan berpartisipasi dalam pelatihan. Kelompok proses yang melaksanakan
harus tumpang tindih dengan kelompok proses lainnya, dan umumnya memerlukan sumber daya paling banyak.
Proses pemantauan dan pengendalian mengukur kemajuan menuju tujuan proyek,
memantau penyimpangan dari rencana, dan mengambil tindakan korektif untuk mencocokkan kemajuan
dengan rencana. Laporan kinerja adalah keluaran umum dari pemantauan dan pengendalian. Manajer proyek
harus memantau kemajuan dengan cermat untuk memastikan bahwa hasil telah diselesaikan dan tujuan
tercapai. Manajer proyek harus bekerja sama dengan tim proyek dan pemangku kepentingan lainnya dan
mengambil tindakan yang tepat untuk menjaga proyek berjalan lancar. Hasil ideal dari kelompok proses
pemantauan dan pengendalian adalah menyelesaikan proyek dengan sukses dengan memberikan ruang
lingkup proyek yang disepakati dalam batasan waktu, biaya, dan kualitas. Jika diperlukan perubahan
terhadap tujuan atau rencana proyek, proses pemantauan dan pengendalian memastikan bahwa perubahan
tersebut dilakukan secara efisien dan efektif untuk memenuhi kebutuhan dan harapan pemangku kepentingan.
Proses pemantauan dan pengendalian tumpang tindih dengan semua kelompok proses manajemen proyek lainnya
karena perubahan dapat terjadi kapan saja.
Selama proses penutupan, tim proyek bekerja untuk mendapatkan penerimaan produk akhir,
layanan, atau hasil dan membawa fase atau proyek ke akhir yang tertib. Hasil utama dari kelompok proses ini
adalah penerimaan formal atas pekerjaan dan pembuatan dokumen penutup, seperti laporan proyek akhir dan
laporan pembelajaran.
Cuplikan media S
Sama seperti proyek TI yang harus mengikuti kelompok proses manajemen proyek, demikian pula proyek
lainnya, seperti produksi film. Proses yang terlibat dalam pembuatan film mungkin mencakup penulisan
skenario, produksi, akting dan penyutradaraan, pengeditan, dan peluncuran film ke bioskop. Banyak orang
menikmati menonton fitur tambahan pada DVD yang menjelaskan bagaimana proses ini mengarah
pada pembuatan film. Misalnya, DVD Lord of the Rings: The Two Towers Extended Edition mencakup
penjelasan rinci tentang bagaimana naskah dibuat, bagaimana struktur besar dibangun, bagaimana efek
khusus dibuat, dan bagaimana para profesional berbakat mengatasi banyak kendala untuk menyelesaikan
proyek.
Materi ini “bukan sebagai pengisi promosi tetapi sebagai pemeriksaan yang serius dan cermat terhadap
keseluruhan proses pembuatan film.”5 New Line Cinema membuat sejarah dengan merekam ketiga film
Lord of the Rings secara berurutan dalam satu produksi besar-besaran.
Butuh waktu tiga tahun persiapan untuk membangun lokasi syuting, mencari lokasi, menulis naskah, dan
memilih aktor. Sutradara Peter Jackson mengatakan bahwa banyaknya perencanaan awal yang mereka
lakukan membuatnya lebih mudah dari yang dia bayangkan untuk memproduksi film tersebut. Manajer
proyek di bidang apa pun tahu betapa pentingnya memiliki rencana yang baik dan mengikuti proses yang
baik. Jackson melanjutkan kesuksesan filmnya dengan menyutradarai The Hobbit, yang diproduksi
sebagai film trilogi, dengan film yang dirilis pada tahun 2012, 2013, dan 2014.
Memetakan Grup Proses ke Area Pengetahuan
Anda dapat memetakan aktivitas utama setiap kelompok proses manajemen proyek ke dalam 10 area pengetahuan
manajemen proyek. Tabel 3-1 memberikan gambaran besar tentang hubungan antara 49 aktivitas manajemen proyek,
kelompok proses di mana
Tabel 3-1 Kelompok proses manajemen proyek dan pemetaan area pengetahuan
Pemantauan
dan
Memulai Perencanaan Eksekusi Mengontrol Penutupan
Pengetahuan Proses Proses Proses Proses Proses
Daerah Kelompok Kelompok Kelompok Kelompok Kelompok
4. Manajemen 4.1 4.2 Mengembangkan Rencana Pengelolaan Proyek 4.3 Langsung 4.7 Tutup
Integrasi Proyek Mengembangkan dan 4.5 Monitor Kelola Pekerjaan dan Kontrol Proyek
Proyek Proyek Pekerjaan atau Fase
Piagam 4.4 Kelola Proyek
4.6 Melakukan
Pengetahuan Proyek Pengendalian

Perubahan
Terintegrasi
5. Manajemen Lingkup 5.1 Rencana Lingkup 5.5 Validasi
Proyek Manajemen Cakupan

5.2 Kumpulkan 5.6 Pengendalian
Persyaratan Cakupan
5.3 Tentukan Ruang Lingkup
5.4 Membuat WBS
6. Jadwal 6.1 Rencana Jadwal 6.6 Jadwal

Proyek Pengelolaan Pengendalian
Pengelolaan 6.2 Mendefinisikan Kegiatan
6.3 Urutan
Kegiatan
6.4 Perkiraan
Durasi Aktivitas
6.5
Mengembangkan Jadwal
7. Manajemen Biaya 7.1 Biaya Rencana 7.4 Biaya
Proyek Pengelolaan Pengendalian

7.2 Perkiraan Biaya
7.3 Tentukan
Anggaran
(lanjutan)
92 bagian 3
Tabel 3-1 Kelompok proses manajemen proyek dan pemetaan area pengetahuan (lanjutan)
Pemantauan
dan
Memulai Perencanaan Eksekusi Mengontrol Penutupan
Pengetahuan Proses Proses Proses Proses Proses
Daerah Kelompok Kelompok Kelompok Kelompok Kelompok
8. Manajemen 8.1 Rencana 8.2 Kelola 8.3 Pengendalian
Kualitas Manajemen Mutu Kualitas Kualitas

Proyek
9. Manajemen 9.1 Merencanakan 9.3 Memperoleh 9.6 Pengendalian

Sumber Pengelolaan Sumber Daya Sumber Daya Sumber Daya
Daya Proyek 9.2 Perkirakan Sumber 9.4

Daya Kegiatan Mengembangkan Tim
9.5 Kelola Tim
10. Manajemen 10.1 Rencana 10.2 Kelola 10.3

Komunikasi Manajemen Komunikasi Komunikasi Pemantauan Komunikasi
Proyek tions dekorasi
11. Manajemen Risiko 11.1 Rencana 11.6 11.7
Proyek Manajemen Risiko Menerapkan Memantau Resiko
11.2 Identifikasi Risiko Respons Risiko

11.3 Melakukan
Analisis Risiko Kualitatif
11.4 Melakukan
Analisis Risiko Kuantitatif
11.5 Merencanakan
Respon Risiko
12. Manajemen 12.1 Rencana Manajemen 12.2 Melakukan 12.3 Kontrol

Pengadaan Proyek Pengadaan Pengadaan Pro
penyembuhan
13. Proyek 13.1 13.2 Rencana 13.3 Mengelola 13.4 Memantau

Pemangku kepentingan Identifikasi Keterlibatan
Keterlibatan Pemangku Kepentingan Keterlibatan
Pengelolaan Pemangku Kepentingan

Pemangku Kepentingan
pemangku kepentingan
Sumber: Project Management Institute Panduan untuk Badan Pengetahuan Manajemen Proyek (PMBOK®
Guide) – Edisi Keenam, Project Management Institute, Inc., (2017). Hak Cipta dan semuanya
hak dilindungi undang-undang. Materi dari publikasi ini telah direproduksi dengan izin dari PMI.
mereka biasanya diselesaikan, dan bidang pengetahuan yang sesuai dengan mereka. Kegiatan yang tercantum dalam
tabel merupakan proses utama untuk setiap bidang pengetahuan yang tercantum dalam PMBOK®
Panduan – Edisi Keenam. Perlu diperhatikan bahwa Panduan PMBOK® dapat berfungsi sebagai panduan untuk
semua jenis proyek yang menggunakan semua jenis pendekatan, termasuk Agile. Setiap tim proyek berhak memutuskan
proses dan keluaran apa yang diperlukan berdasarkan kebutuhan spesifik mereka.
Beberapa organisasi menggunakan informasi Panduan PMBOK® PMI sebagai landasan untuk
mengembangkan metodologi manajemen proyek mereka sendiri, seperti yang dijelaskan di bagian berikutnya.
Perhatikan pada Tabel 3-1 bahwa banyak aktivitas manajemen proyek terjadi sebagai bagian dari kelompok proses
perencanaan. Karena setiap proyek adalah unik, tim proyek selalu berusaha melakukan sesuatu yang belum pernah
dilakukan sebelumnya. Agar berhasil dalam aktivitas unik dan baru, tim proyek harus melakukan banyak
perencanaan. Namun perlu diingat bahwa sebagian besar waktu dan uang biasanya dihabiskan untuk mengeksekusi.
Merupakan praktik yang baik bagi organisasi untuk menentukan bagaimana manajemen proyek akan bekerja paling
baik di organisasi mereka sendiri.
Mengembangkan Metodologi Manajemen Proyek TI
Beberapa organisasi menghabiskan banyak waktu dan uang untuk upaya pelatihan keterampilan manajemen proyek
secara umum, namun setelah pelatihan, manajer proyek mungkin masih tidak tahu bagaimana menyesuaikan keterampilan
manajemen proyek mereka dengan kebutuhan khusus organisasi. Karena masalah ini, beberapa organisasi
mengembangkan metodologi manajemen proyek TI internal mereka sendiri. Panduan PMBOK® adalah standar
yang menjelaskan praktik terbaik untuk apa
harus dilakukan untuk mengelola suatu proyek. Metodologi menggambarkan bagaimana sesuatu harus dilakukan, dan
organisasi yang berbeda seringkali mempunyai cara yang berbeda dalam melakukan sesuatu .
Selain menggunakan Panduan PMBOK® sebagai dasar metodologi manajemen proyek, banyak
organisasi menggunakan panduan atau metode lain, seperti berikut:
• Proyek DI Lingkungan Terkendali (PRINCE2): Awalnya dikembangkan untuk proyek TI, PRINCE2 dirilis
pada tahun 1996 sebagai metodologi manajemen proyek umum oleh Kantor Perdagangan Pemerintah
Inggris (OGC). Ini adalah standar de facto di Inggris dan digunakan di lebih dari 50 negara.
(Lihat www.prince2.com untuk informasi lebih lanjut.) PRINCE2 mendefinisikan 45 subproses terpisah
dan mengaturnya menjadi delapan kelompok proses sebagai berikut:
1. Memulai sebuah proyek

2. Perencanaan
3. Memulai sebuah proyek
4. Mengarahkan suatu proyek
5. Mengendalikan suatu tahapan
6. Mengelola pengiriman produk

7. Mengelola batasan tahapan
8. Menutup proyek
• Metode tangkas: Seperti dijelaskan pada Bab 2, tangkas adalah produk adaptif
siklus hidup digunakan ketika kiriman memiliki tingkat perubahan yang tinggi dan frekuensi
pengiriman yang tinggi. Istilah tangkas sering digunakan untuk menggambarkan berbagai metode.
Misalnya, Panduan Latihan Agile menjelaskan tangkas dan Kanban
94 bagian 3
sebagai bagian dari lean. (Lihat Bab 8, Manajemen Kualitas Proyek, untuk rincian lebih
lanjut tentang lean.) Pendekatan Agile mencakup Scrum, Scrumban (hibrida dari Scrum dan
Kanban), Extreme Programming (XP), Feature Driven Development (FDD), Crystal, Agile
Unified Process (AUP) ), Metode Pengembangan Sistem Dinamis (DSDM), dan Scaled Agile
Framework. Lihat situs web seperti www
.agilealliance.org dan www.scaledagileframework.com untuk informasi lebih lanjut.
Kasus kedua dalam bab ini memberikan contoh penggunaan Scrum.
Isu global
Pada tahun 2018 PMI menerbitkan survei manajemen proyek global tahunan mereka yang kesepuluh (Pulse
of the Profession®). Lebih dari 5.000 orang berpartisipasi, dan responden melaporkan bahwa 47 persen proyek
yang diselesaikan di organisasi mereka pada tahun lalu menggunakan pendekatan prediktif, 23 persen
menggunakan pendekatan agile, 23 persen menggunakan gabungan antara prediktif dan agile, dan 7 persen
menggunakan pendekatan lain. Sebagian besar organisasi telah mengadopsi agile setidaknya di beberapa
bidang dan menggabungkan pendekatan hybrid di seluruh portofolio proyek mereka.6 Dalam survei tahun
2015, 27 persen responden sebenarnya memiliki langkah formal dalam evaluasi proyek di mana agile atau
Scrum secara terang-terangan ditentukan untuk dapat diterapkan atau tidak. untuk situasi proyek tertentu.
Survei global tahun 2017 yang dilakukan oleh VersionOne menemukan bahwa 94 persen responden
mengatakan organisasi mereka berlatih secara tangkas, namun 60 persen tim mereka belum
mempraktikkannya. 80 persen responden juga mengatakan organisasi mereka berada pada atau di bawah
level “masih matang” dalam hal tangkas. Tiga manfaat utama dari agile adalah kemampuan untuk mengelola
prioritas yang berubah seiring bertambahnya usia, meningkatkan produktivitas tim, dan meningkatkan visibilitas proyek.7
• Kerangka Rational Unified Process (RUP): RUP adalah perangkat lunak yang berulang
proses pengembangan yang dibuat oleh IBM yang berfokus pada produktivitas tim dan
memungkinkan semua anggota tim untuk memberikan praktik terbaik perangkat lunak ke organisasi.
Menurut pakar RUP Bill Cottrell, “RUP mewujudkan manajemen standar industri dan
metode serta teknik teknis untuk menyediakan proses rekayasa perangkat lunak yang
khususnya cocok untuk menciptakan dan memelihara solusi sistem perangkat lunak berbasis
komponen.”8 Cottrell menjelaskan bahwa Anda dapat menyesuaikan RUP untuk menyertakan
PMBOK ® kelompok proses karena beberapa pelanggan meminta kemampuan tersebut. IBM
juga mengembangkan metode OpenSource yang disebut OpenUP untuk penyampaian
proyek tangkas. Beberapa metodologi manajemen proyek lainnya digunakan khusus untuk
proyek pengembangan perangkat lunak, seperti Joint Application Development (JAD) dan
Rapid Application Development (RAD).
• Metodologi Six Sigma: Banyak organisasi mempunyai proyek yang menggunakan Six
Metodologi Sigma. Pekerjaan banyak ahli kualitas proyek memberikan kontribusi terhadap
pengembangan prinsip-prinsip Six Sigma saat ini. Dua metodologi utama digunakan pada
proyek Six Sigma: Define, Measure, Analyze, Improve, and Control (DMAIC) digunakan
untuk meningkatkan proses bisnis yang ada, dan Define, Measure, Analyze, Design, dan Verify
(DMADV) digunakan untuk membuat desain produk atau proses baru untuk mencapai kinerja
yang dapat diprediksi dan bebas cacat. (Lihat Bab 8, Manajemen Mutu Proyek, untuk
informasi lebih lanjut tentang Six Sigma.)
Banyak organisasi menyesuaikan standar atau metodologi untuk memenuhi kebutuhan unik mereka.
Bahkan jika organisasi menggunakan Panduan PMBOK® sebagai dasar metodologi manajemen proyek
mereka, mereka masih harus melakukan banyak pekerjaan untuk menyesuaikannya dengan lingkungan kerja
mereka yang unik.
Apa yang Benar?
Organisasi yang unggul dalam manajemen proyek menyelesaikan 89 persen proyeknya dengan sukses
dibandingkan dengan hanya 36 persen organisasi yang tidak memiliki proses manajemen proyek yang baik.
PMI memperkirakan bahwa kinerja proyek yang buruk memerlukan biaya lebih dari $109 juta untuk setiap
$1 miliar yang diinvestasikan dalam proyek dan program.9
Proyek yang sangat besar dan kompleks seringkali mendapatkan manfaat paling besar dari
penggunaan metodologi manajemen proyek yang telah terbukti. Beberapa perusahaan terkemuka bekerja
sama untuk mengajukan penawaran pada kontrak catatan kesehatan militer bernilai miliaran dolar pada
tahun 2015. IBM dan Epic mengusulkan untuk menjalankan sistem catatan kesehatan Epic (sistem paling
populer di pasar) pada IBM yang aman. -Pusat data yang dioperasikan. PricewaterhouseCoopers (PwC)
bekerja sama dengan Google untuk memberikan solusi berdasarkan versi sumber terbuka dari sistem
catatan kesehatan Vista yang digunakan oleh Departemen Urusan Veteran.10 Kontrak tersebut diberikan
kepada Kemitraan Leidos untuk Kesehatan Pertahanan—yang mencakup Cerner, seorang manajer
catatan kesehatan elektronik; Aksen Federal; dan Leidos, kontraktor pemerintah yang berbasis di Reston,
Virginia. Sistem MHS Genesis mereka telah diterapkan di banyak organisasi pada tahun 2018. Jika
kontrak besar ini dikelola dengan baik, hal ini akan menghemat lebih dari $1,2 miliar dolar yang berpotensi terbuang bagi pembayar pajak.
Bagian berikut menyajikan dua contoh penerapan kelompok proses manajemen proyek pada sebuah
proyek di JWD Consulting. Kedua contoh tersebut menggunakan beberapa ide dari Panduan PMBOK® – Edisi
Keenam, beberapa ide dari metodologi lain, dan beberapa ide baru untuk memenuhi kebutuhan proyek
yang unik. Studi kasus pertama menggunakan pendekatan yang lebih prediktif atau air terjun, sedangkan studi
kasus kedua menggunakan pendekatan yang lebih adaptif dengan menggunakan Scrum. Meskipun
disesuaikan dengan kebutuhan organisasi JWD Consulting, keduanya tetap menggunakan kelompok
proses manajemen proyek dan beberapa keluaran atau hasil yang dijelaskan dalam Panduan PMBOK® .
Studi Kasus 1: Manajemen Proyek JWD Consulting

Proyek Situs Intranet (Pendekatan Prediktif)
Kasus fiktif berikut ini memberikan contoh elemen-elemen yang terlibat dalam pengelolaan sebuah proyek
dari awal hingga akhir. Contoh ini juga menggunakan Microsoft Project untuk menunjukkan bagaimana
perangkat lunak manajemen proyek dapat membantu dalam beberapa aspek pengelolaan proyek. Beberapa
templat menggambarkan bagaimana tim proyek menyiapkan berbagai dokumen manajemen proyek.
File untuk templat ini dan templat lainnya tersedia di situs web Pendamping untuk teks ini.
Detail tentang pembuatan banyak dokumen yang ditampilkan disediakan di bab selanjutnya, jadi jangan
khawatir jika Anda tidak memahami semuanya saat ini. Kedua kasus ini disediakan untuk memberi Anda
gambaran besar tentang manajemen proyek TI. Anda mungkin ingin membaca bagian ini lagi nanti untuk
meningkatkan pembelajaran Anda.
96 bagian 3
Pra-Inisiasi dan Inisiasi Proyek

Dalam manajemen proyek, memulai mencakup mengenali dan memulai proyek baru. Sebuah organisasi
harus mempertimbangkan dengan matang pemilihan proyek untuk memastikan bahwa organisasi tersebut memulai
jenis proyek yang tepat dengan alasan yang tepat. Lebih baik meraih kesuksesan yang moderat atau bahkan
kecil pada sebuah proyek penting daripada sukses besar pada sebuah proyek yang tidak penting. Oleh karena
itu, pemilihan proyek untuk inisiasi sangatlah penting, begitu pula pemilihan manajer proyek. Idealnya, manajer proyek
akan dilibatkan dalam memulai suatu proyek, namun seringkali manajer proyek dipilih setelah banyak keputusan
inisiasi telah dibuat.
Anda akan mempelajari lebih lanjut tentang pemilihan proyek di Bab 4, Manajemen Integrasi Proyek.
Penting untuk diingat bahwa perencanaan strategis harus berfungsi sebagai landasan untuk memutuskan
proyek mana yang akan dilaksanakan. Rencana strategis organisasi mengungkapkan visi, misi, tujuan, sasaran,
dan strategi organisasi. Ini juga memberikan dasar untuk perencanaan proyek TI. TI biasanya merupakan fungsi
pendukung dalam suatu organisasi, sehingga orang yang memulai proyek TI harus memahami bagaimana proyek
tersebut berhubungan dengan kebutuhan organisasi saat ini dan masa depan. Misalnya, bisnis utama JWD Consulting
adalah menyediakan layanan konsultasi kepada organisasi lain, bukan mengembangkan aplikasi situs intranetnya
sendiri.
Oleh karena itu, sistem informasi harus mendukung tujuan bisnis perusahaan, seperti menyediakan layanan
konsultasi secara lebih efektif dan efisien.
Sebuah organisasi mungkin memulai proyek TI karena beberapa alasan, namun alasan yang paling penting
adalah untuk mendukung tujuan bisnis. Seperti disebutkan dalam kasus pembuka bab ini, JWD Consulting ingin
mengikuti proses yang patut dicontoh dalam mengelola proyeknya karena bisnis intinya adalah membantu
organisasi lain mengelola proyek. Mengembangkan intranet untuk berbagi pengetahuan manajemen proyek dapat
membantu JWD Consulting mengurangi biaya internal dengan bekerja lebih efektif, dan dengan memungkinkan
pelanggan lama dan calon pelanggan mengakses beberapa informasi perusahaan. JWD Consulting juga dapat
meningkatkan pendapatan dengan mendatangkan lebih banyak bisnis. Oleh karena itu, perusahaan akan
menggunakan metrik ini—mengurangi biaya internal dan meningkatkan pendapatan—untuk mengukur kinerjanya
pada proyek ini.
Tugas Pra-Inisiasi
Merupakan praktik yang baik untuk meletakkan dasar bagi sebuah proyek sebelum proyek tersebut resmi
dimulai. Manajer senior sering kali melakukan beberapa tugas untuk meletakkan dasar, terkadang disebut
tugas pra inisiasi, termasuk yang berikut ini:
•Menentukan batasan ruang lingkup, waktu, dan biaya untuk proyek tersebut.
• Identifikasi sponsor proyek.
•Pilih manajer proyek.
• Mengembangkan kasus bisnis untuk sebuah proyek.
•Bertemu dengan manajer proyek untuk meninjau proses dan harapan dalam mengelola proyek.
•Tentukan apakah proyek harus dibagi menjadi dua atau lebih proyek yang lebih kecil.
Seperti dijelaskan dalam kasus pembuka, CEO JWD Consulting, Joe Fleming, menjelaskan cakupan proyek
tingkat tinggi. Dia ingin mensponsori proyek itu sendiri karena itu adalah idenya dan penting secara strategis bagi
bisnisnya. Dia ingin Erica Bell, Direktur PMO, mengelola proyek tersebut setelah membuktikan adanya alasan
bisnis yang kuat
dia. Jika terdapat alasan bisnis yang kuat untuk melaksanakan proyek tersebut, maka Joe dan
Erica akan bertemu untuk meninjau proses dan harapan dalam mengelola proyek tersebut. Jika
tidak ada alasan bisnis yang kuat, proyek ini tidak akan dilanjutkan.
Mengenai perlunya tugas pra-inisiasi terakhir, banyak orang mengetahui dari pengalaman bahwa lebih
mudah menyelesaikan proyek kecil dengan sukses daripada proyek besar, terutama untuk proyek TI.
Seringkali masuk akal untuk memecah proyek besar menjadi dua atau lebih proyek kecil untuk membantu
meningkatkan peluang keberhasilan. Namun dalam kasus ini, Joe dan Erica memutuskan bahwa pekerjaan
tersebut dapat diselesaikan dalam satu proyek yang akan memakan waktu sekitar enam bulan.
Untuk membenarkan investasi dalam proyek ini, Erica menyusun kasus bisnis untuk proyek tersebut, dan mendapatkan masukan
dan masukan dari Joe, dari salah satu anggota staf seniornya di PMO, dan dari anggota departemen
Keuangan. Dia juga menggunakan template perusahaan dan contoh kasus bisnis dari proyek sebelumnya
sebagai panduan. Tabel 3-2 menyajikan kasus bisnis. (Perhatikan bahwa contoh ini dan contoh lainnya
disingkat.) Perhatikan bahwa informasi berikut disertakan dalam kasus bisnis ini:
• Pendahuluan/latar belakang
•Tujuan bisnis
•Situasi saat ini dan pernyataan masalah/peluang
• Asumsi dan kendala penting
•Analisis pilihan dan rekomendasi
•Persyaratan awal proyek
•Estimasi anggaran dan analisis keuangan
•Perkiraan jadwal
•Potensi risiko
•Pameran
Karena proyek ini relatif kecil dan ditujukan untuk sponsor internal, kasus bisnisnya tidak sepanjang
kasus bisnis lainnya. Erica meninjau kasus bisnis tersebut dengan Joe, dan dia setuju bahwa proyek tersebut
layak untuk dilaksanakan. Dia cukup senang
Tabel 3-2 Kasus bisnis JWD Consulting
1.0 Pendahuluan/Latar Belakang
Tujuan bisnis inti JWD Consulting adalah menyediakan layanan konsultasi manajemen
proyek kelas dunia kepada berbagai organisasi. Perusahaan dapat menyederhanakan
operasi dan meningkatkan bisnis dengan menyediakan informasi terkait manajemen proyek di
situs intranetnya, membuat beberapa informasi dan layanan dapat diakses oleh klien saat ini dan calon klien.
2.0 Tujuan Bisnis
Sasaran strategis JWD Consulting mencakup pertumbuhan dan profitabilitas yang

berkelanjutan. Proyek situs intranet manajemen proyek akan mendukung tujuan ini
dengan meningkatkan visibilitas keahlian perusahaan kepada klien saat ini dan calon klien
dengan memungkinkan akses klien dan publik ke beberapa bagian intranet. Proyek ini juga
akan meningkatkan profitabilitas dengan mengurangi biaya internal dengan menyediakan
alat standar, teknik, templat, dan pengetahuan manajemen proyek untuk semua konsultan internal.
(lanjutan)
98 bagian 3
Tabel 3-2 Kasus bisnis JWD Consulting (lanjutan)
3.0 Situasi Saat Ini dan Pernyataan Masalah/Peluang

JWD Consulting memiliki situs web perusahaan dan juga intranet. Perusahaan saat ini menggunakan
situs web untuk informasi pemasaran. Kegunaan utama intranet adalah untuk informasi sumber
daya manusia konsultan, seperti memasukkan jam kerja proyek, mengubah dan melihat informasi
manfaat, dan mengakses direktori online dan sistem email berbasis web. Perusahaan juga
menggunakan sistem manajemen proyek di seluruh perusahaan untuk melacak semua
informasi proyek, dengan fokus pada status hasil dan memenuhi tujuan ruang lingkup, waktu,
dan biaya. Ada peluang untuk menyediakan bagian baru di intranet yang didedikasikan untuk
berbagi pengetahuan manajemen proyek konsultan di seluruh organisasi. JWD Consulting hanya
mempekerjakan konsultan berpengalaman dan memberi mereka kebebasan untuk mengelola
proyek sesuai keinginan mereka. Namun, seiring pertumbuhan bisnis dan proyek menjadi lebih
kompleks, bahkan manajer proyek berpengalaman pun mencari saran tentang cara bekerja
lebih efektif.
4.0 Asumsi dan Kendala Kritis
Situs intranet yang diusulkan harus menjadi aset berharga bagi JWD Consulting. Konsultan dan
klien saat ini harus secara aktif mendukung proyek tersebut, dan proyek tersebut harus membayar
sendiri dalam waktu satu tahun dengan mengurangi biaya operasional internal dan menghasilkan
bisnis baru. Manajer Kantor Manajemen Proyek harus memimpin upaya tersebut, dan tim proyek
harus mencakup peserta dari beberapa bagian perusahaan, serta dari organisasi klien saat ini.
Sistem baru harus berjalan pada perangkat keras dan perangkat lunak yang ada, dan memerlukan
dukungan teknis minimal. Ini harus mudah diakses oleh konsultan dan klien dan aman dari pengguna
yang tidak berwenang.
5.0 Analisis Pilihan dan Rekomendasi

Ada tiga opsi untuk mengatasi peluang ini:
1. Jangan melakukan apa pun. Bisnis berjalan dengan baik, dan kami dapat terus beroperasi
tanpa proyek baru ini.
2. Membeli akses ke perangkat lunak khusus untuk mendukung kemampuan baru ini dengan
sedikit pengembangan internal.
3. Merancang dan mengimplementasikan kemampuan intranet baru secara internal, menggunakan sebagian besar kemampuan yang sudah ada
perangkat keras dan perangkat lunak.
Berdasarkan diskusi dengan pemangku kepentingan, kami yakin opsi 3 adalah pilihan terbaik.
6.0 Persyaratan Proyek Awal

Fitur utama situs intranet manajemen proyek antara lain sebagai berikut:
1. Akses ke beberapa templat dan alat manajemen proyek. Pengguna harus bisa
untuk mencari templat dan alat, baca petunjuk penggunaan templat dan alat ini, dan lihat contoh
cara menerapkannya pada proyek nyata. Pengguna juga harus dapat mengirimkan templat dan
alat baru, yang harus disaring atau diedit terlebih dahulu oleh Kantor Manajemen Proyek.
(lanjutan)
2. Akses ke artikel manajemen proyek yang relevan. Banyak konsultan merasakan kelebihan informasi
ketika mereka meneliti informasi manajemen proyek. Mereka sering membuang-buang waktu yang
seharusnya mereka habiskan bersama klien mereka. Intranet baru harus mencakup akses ke artikel
penting mengenai topik manajemen proyek, yang dapat dicari berdasarkan topik, dan
memungkinkan pengguna untuk meminta staf Kantor Manajemen Proyek untuk menemukan artikel
tambahan untuk memenuhi kebutuhan mereka.
3. Tautan ke situs web lain yang terkini, dengan penjelasan singkat tentang fitur utama situs eksternal.
4. Fitur Tanya Pakar untuk membantu membangun hubungan dengan masa kini dan masa depan
klien dan berbagi pengetahuan dengan konsultan internal.
5. Keamanan yang tepat membuat seluruh situs intranet dapat diakses oleh internal
konsultan dan bagian tertentu dapat diakses oleh orang lain.
6. Kemampuan membebankan biaya untuk akses ke informasi tertentu. Beberapa di antaranya
informasi dan fitur situs intranet harus mendorong pengguna eksternal untuk membayar informasi
atau layanan tersebut. Opsi pembayaran harus mencakup kartu kredit atau transaksi pembayaran
online serupa. Setelah sistem memverifikasi pembayaran, pengguna seharusnya dapat mengakses
atau mengunduh informasi yang diinginkan.
7. Fitur lain yang disarankan oleh pengguna, jika memberikan nilai tambah bagi bisnis.
7.0 Perkiraan Anggaran dan Analisis Keuangan
Perkiraan awal biaya untuk keseluruhan proyek adalah $140.000. Perkiraan ini didasarkan pada
manajer proyek yang bekerja sekitar 20 jam per minggu selama enam bulan dan staf internal lainnya
bekerja sekitar 60 jam per minggu selama enam bulan. Perwakilan pelanggan tidak akan dibayar atas
bantuan mereka. Seorang manajer proyek staf akan mendapatkan $50 per jam. Tarif per jam untuk anggota
tim proyek lainnya adalah $70 per jam, karena beberapa jam yang biasanya ditagihkan ke klien mungkin
diperlukan untuk proyek ini. Perkiraan biaya awal juga mencakup $10.000 untuk pembelian perangkat lunak
dan layanan dari pemasok. Setelah proyek selesai, biaya pemeliharaan sebesar $40.000 disertakan
setiap tahunnya, terutama untuk memperbarui informasi dan mengoordinasikan fitur Tanya Pakar dan
artikel online.
Manfaat yang diproyeksikan didasarkan pada pengurangan jam yang dihabiskan konsultan
untuk meneliti informasi manajemen proyek, alat yang tepat, dan templat. Proyeksi manfaat juga didasarkan
pada sedikit peningkatan keuntungan akibat adanya bisnis baru yang dihasilkan oleh proyek ini. Jika
masing-masing dari 400 konsultan menghemat hanya 40 jam setiap tahun (kurang dari satu jam per minggu)
dan dapat menagih waktu tersebut untuk proyek-proyek yang menghasilkan perkiraan keuntungan
konservatif sebesar $10 per jam, maka proyeksi manfaatnya adalah $160.000 per tahun. Jika intranet baru
meningkatkan bisnis hanya sebesar 1 persen, dengan menggunakan informasi keuntungan masa lalu,
peningkatan keuntungan karena bisnis baru akan mencapai setidaknya $40.000 setiap tahun. Oleh karena
itu, total manfaat yang diproyeksikan adalah sekitar $200.000 per tahun. Gambar A merangkum proyeksi
biaya dan manfaat dan menunjukkan perkiraan nilai sekarang bersih (NPV), laba atas investasi (ROI), dan
tahun terjadinya pengembalian. Hal ini juga mencantumkan asumsi yang dibuat dalam melakukan
analisis keuangan awal ini. Semua perkiraan keuangan sangat menggembirakan. Perkiraan
pengembaliannya dalam waktu satu tahun, sesuai permintaan sponsor. NPV-nya adalah $272.800, dan ROI
yang didiskon berdasarkan umur sistem tiga tahun sangat baik yaitu sebesar 112 persen.
(lanjutan)
100 bagian 3

8.0 Perkiraan Jadwal
Sponsor ingin proyek ini selesai dalam waktu enam bulan, namun ada fleksibilitas dalam
jadwalnya. Kami juga berasumsi bahwa sistem baru akan memiliki masa manfaat setidaknya tiga
tahun.
9.0 Potensi Risiko
Proyek ini mempunyai beberapa risiko. Risiko terbesar adalah kurangnya minat terhadap sistem
baru dari konsultan internal dan klien eksternal kami. Masukan pengguna sangat penting untuk
memasukkan informasi ke dalam sistem ini dan mewujudkan potensi manfaat dari penggunaan
sistem. Ada beberapa risiko teknis dalam memilih jenis perangkat lunak yang digunakan untuk
mencari sistem, menerapkan keamanan, memproses pembayaran, dan sebagainya, namun
fitur sistem ini semuanya menggunakan teknologi yang telah terbukti. Risiko bisnis utama
adalah menginvestasikan waktu dan uang ke dalam proyek ini dan tidak merealisasikan
manfaat yang diharapkan.
10.0 Pameran
Gambar A: Analisis Keuangan untuk Proyek Situs Intranet Manajemen Proyek

Nilai diskon 8%
Asumsikan proyek selesai dalam waktu sekitar 6 bulan Tahun

0 1 2 3 Jumlah
Biaya 140.000 1 40.000 40.000 40.000
Faktor diskon 0,93 0,86 0,79
Biaya diskon 140.000 37.037 34.294 31.753 243.084
Manfaat 0 200.000 200.000 200.000

Faktor diskon 1 0,93 0,86 0,79
Manfaat diskon 0 186.185 171.468 158.766 515.419
Manfaat yang didiskon - biaya (140.000) 148.148 137.174 127.013

Manfaat kumulatif - biaya (140.000) 8.148 145.322 272.336 NPV
Pengembalian di
ROI siklus hidup yang didiskon------------> Tahun 1 112%
Asumsi
Biaya # jam
PM (500 jam, $50/jam) 25.000
Staf (1.500 jam, $70/jam) 105.000
Perangkat lunak dan layanan yang dialihdayakan 10.000
Total biaya proyek (semua diterapkan pada tahun 0) 140.000
Manfaat
#konsultan 400
Menghemat keuntungan 40
$/jam selama berjam-jam 10
Manfaat dari menghemat waktu 160.000
Manfaat dari peningkatan keuntungan 1%. 40.000
Total manfaat yang diproyeksikan tahunan 200.000
untuk melihat bahwa pengembalian modal diperkirakan dalam waktu satu tahun dan laba atas
investasi diproyeksikan sebesar 112 persen. Dia meminta Erica untuk melanjutkan tugas inisiasi
formal untuk proyek ini, yang akan dijelaskan di bagian selanjutnya.
Memulai
Untuk secara resmi memulai proyek situs intranet manajemen proyek, Erica mengetahui bahwa tugas utamanya adalah
mengidentifikasi semua pemangku kepentingan proyek dan mengembangkan piagam proyek. Tabel 3-3 menunjukkan
proses-proses ini dan keluarannya, berdasarkan PMBOK®
Panduan – Edisi Keenam. Keluaran utamanya adalah piagam proyek dan daftar pemangku kepentingan.
Keluaran tambahan yang menurut Erica sangat berguna untuk memulai proyek adalah strategi manajemen pemangku
kepentingan dan pertemuan resmi permulaan proyek. Deskripsi tentang bagaimana keluaran ini dibuat dan contoh
dokumen yang terkait dengan masing-masing keluaran disediakan untuk proyek ini. Ingatlah bahwa setiap proyek
dan setiap organisasi adalah unik, sehingga tidak semua piagam proyek, daftar pemangku kepentingan, dan keluaran
lainnya akan terlihat sama. Anda akan melihat contoh beberapa dokumen ini di bab-bab selanjutnya.
Mengidentifikasi Pemangku Kepentingan Proyek
Erica bertemu dengan Joe Fleming, sponsor proyek, untuk membantu mengidentifikasi pemangku kepentingan utama.
Ingatlah dari Bab 1 bahwa pemangku kepentingan adalah orang-orang yang terlibat dalam kegiatan proyek atau
terkena dampaknya, dan termasuk sponsor proyek, tim proyek, staf pendukung, pelanggan, pengguna, pemasok, dan
bahkan penentang proyek. Joe, sponsor proyek, tahu bahwa penting untuk membentuk tim proyek yang kuat, dan dia yakin
dengan kemampuan Erica untuk memimpin tim tersebut.
Mereka memutuskan bahwa anggota tim utama harus menyertakan salah satu konsultan penuh waktu mereka dengan
catatan luar biasa, Michael Chen; salah satu konsultan paruh waktu, Jessie Faue, yang masih baru di perusahaan dan
mendukung Kantor Manajemen Proyek; dan dua anggota departemen TI yang mendukung intranet saat ini, Kevin Dodge
dan Cindy Dawson. Mereka juga tahu bahwa masukan dari klien sangatlah penting, jadi Joe setuju untuk bertanya kepada
CEO dari dua klien terbesar perusahaan tersebut apakah mereka bersedia menyediakan perwakilan untuk mengerjakan
proyek ini dengan biaya sendiri. Semua staf internal yang direkomendasikan Joe dan Erica setuju untuk mengerjakan
proyek tersebut, dan dua perwakilan klien adalah Kim Phuong dan Page Miller. Karena banyak orang lain yang akan
terpengaruh oleh proyek ini sebagai pengguna intranet baru di masa depan, Joe dan Erica juga mengidentifikasi pemangku
kepentingan utama lainnya, termasuk direktur TI, Sumber Daya Manusia (SDM), dan Hubungan Masyarakat (PR),
serta direktur Erica. Asisten administratif.
Setelah Joe dan Erica melakukan kontak awal, Erica mendokumentasikan peran, nama, organisasi, dan
informasi kontak pemangku kepentingan dalam daftar pemangku kepentingan, sebuah dokumen yang mencakup
rincian terkait dengan pemangku kepentingan proyek yang diidentifikasi.
Tabel 3-3 Bidang pengetahuan, proses, dan keluaran inisiasi proyek
Bidang Pengetahuan Memulai Proses Keluaran
Integrasi Proyek Mengembangkan piagam proyek Piagam proyek

Pengelolaan Catatan asumsi
Pemangku Kepentingan Proyek Identifikasi pemangku kepentingan Daftar pemangku kepentingan

Pengelolaan Perubahan permintaan
Pembaruan rencana manajemen proyek
Pembaruan dokumen proyek
Sumber: Panduan PMBOK® – Edisi Keenam, 2017.

102 bagian 3
Tabel 3-4 memberikan contoh bagian dari daftar awal pemangku kepentingan. Karena dokumen ini bersifat
publik, Erica berhati-hati untuk tidak memasukkan informasi yang mungkin sensitif, seperti seberapa kuat
para pemangku kepentingan mendukung proyek ini dan potensi pengaruh mereka terhadap proyek
tersebut. Dia akan menjaga isu-isu ini secara diam-diam dan menggunakannya dalam mengembangkan
strategi pengelolaan pemangku kepentingan.
Analisis pemangku kepentingan adalah teknik yang dapat digunakan manajer proyek untuk
membantu memahami dan meningkatkan dukungan pemangku kepentingan selama proyek berlangsung.
Hasil analisis pemangku kepentingan dapat didokumentasikan dalam daftar pemangku kepentingan atau
dalam strategi pengelolaan pemangku kepentingan yang terpisah. Strategi ini mencakup informasi dasar
seperti nama pemangku kepentingan, tingkat kepentingan terhadap proyek, tingkat pengaruh terhadap proyek,
dan strategi pengelolaan potensial untuk mendapatkan dukungan atau mengurangi hambatan dari masing-
masing pemangku kepentingan. Karena sebagian besar informasi ini bersifat sensitif, maka informasi tersebut
harus dianggap rahasia. Beberapa manajer proyek bahkan tidak menuliskan informasi ini, namun mereka
mempertimbangkannya karena manajemen pemangku kepentingan adalah bagian penting dari pekerjaan
mereka. Tabel 3-5 memberikan contoh bagian dari strategi pengelolaan pemangku kepentingan Erica untuk proyek tersebut
Tabel 3-4 Daftar pemangku kepentingan
Intern/ Proyek
Nama Posisi Luar Peran Kontak informasi
Joe Fleming, CEO Sponsor Internal joe_fleming@jwdconsulting.com
Erica Bell PMO Proyek Dalaman erica_bell@jwdconsulting.com

Direktur Pengelola
Michael Senior Tim Internal michael_chen@jwdconsulting.com

Chen Konsultan Anggota
Bisnis Kim Phuong Penasihat Eksternal kim_phuong@client1.com

Analis
Louise Mills Direktur Humas Penasihat Internal louise_mills@jwdconsulting.com
Tabel 3-5 Strategi pengelolaan pemangku kepentingan
Tingkat Tingkat
Nama Minat Mempengaruhi Strategi Pengelolaan Potensial
Joe Tinggi Tinggi Joe suka terus memantau proyek-proyek penting dan
Fleming menghasilkan uang. Adakan banyak pertemuan singkat dan
tatap muka dan fokus pada pencapaian manfaat finansial proyek.
Louise Rendah Tinggi Louise punya banyak hal, dan dia tampak tidak bersemangat
Pabrik dengan proyek ini. Dia mungkin mencari peluang kerja lain.
Tunjukkan padanya bagaimana proyek ini akan membantu
perusahaan dan resumenya.
proyek situs intranet manajemen. Anda akan melihat contoh lain dalam mendokumentasikan informasi pemangku
kepentingan di bab-bab selanjutnya.
Menyusun Piagam Proyek Erica

menyusun piagam proyek dan meminta anggota tim proyek meninjaunya sebelum menunjukkannya
kepada Joe. Joe membuat beberapa perubahan kecil, yang dilakukan Erica. Tabel 3-6 menunjukkan
piagam tugas akhir. (Piagam dapat mencakup lebih banyak rincian daripada yang ditunjukkan dalam
contoh ini. Lihat Bab 4 untuk informasi lebih lanjut tentang piagam proyek.) Catat hal-hal yang termasuk
dalam piagam proyek dan jangka pendeknya. JWD Consulting percaya bahwa piagam proyek harus sepanjang
satu atau dua halaman, dan dapat mengacu pada dokumen lain, seperti kasus bisnis, jika diperlukan. Erica
merasa bahwa bagian terpenting dari piagam proyek adalah tanda tangan para pemangku kepentingan utama
(tidak disertakan agar singkatnya) dan komentar masing-masing. Sulit untuk membuat pemangku
kepentingan menyetujui piagam proyek yang hanya dibuat satu halaman saja, sehingga setiap orang memiliki
kesempatan untuk menyampaikan kekhawatiran mereka di bagian komentar. Perhatikan bahwa Michael Chen,
konsultan senior yang diminta untuk mengerjakan proyek tersebut, merasa khawatir untuk berpartisipasi ketika
dia merasa bahwa penugasan lainnya dengan klien eksternal mungkin memiliki prioritas lebih tinggi. Dia
menawarkan untuk meminta bantuan asisten jika diperlukan. Anggota staf TI menyebutkan kekhawatiran
mereka tentang masalah pengujian dan keamanan. Erica tahu bahwa dia harus mengatasi kekhawatiran ini
ketika mengelola proyek.
Tabel 3-6 Piagam proyek
Judul Proyek: Proyek Situs Intranet Manajemen Proyek

Tanggal Mulai Proyek: 2 Mei Tanggal Selesai yang Diproyeksikan: 4 November
Informasi Anggaran: Perusahaan telah mengalokasikan $140.000 untuk proyek ini. Mayoritas biaya
untuk proyek ini adalah tenaga kerja internal. Perkiraan awal memberikan total 80 jam per minggu.
Manajer Proyek: Erica Bell, (310) 555-5896, erica_bell@jwdconsulting.com
Tujuan Proyek: Mengembangkan kemampuan baru yang dapat diakses di situs intranet JWD
Consulting untuk membantu konsultan internal dan pelanggan eksternal mengelola proyek dengan lebih
efektif. Situs intranet akan mencakup beberapa templat dan alat yang dapat diunduh pengguna,
contoh templat lengkap dan dokumen manajemen proyek terkait yang digunakan pada proyek nyata,
artikel penting terkait topik manajemen proyek terkini, layanan pengambilan artikel, tautan ke situs lain
dengan informasi berguna, dan fitur Tanya Pakar, di mana pengguna dapat mengirimkan pertanyaan
tentang proyek mereka dan menerima saran dari para ahli di bidangnya. Beberapa bagian dari situs intranet
akan dapat diakses secara gratis oleh publik, bagian lainnya hanya dapat diakses oleh pelanggan saat
ini dan konsultan internal, dan bagian lainnya dapat diakses dengan biaya.
Kriteria Keberhasilan Proyek Utama: Proyek harus membayar sendiri dalam waktu satu tahun setelah
penyelesaian.
(lanjutan)
104 bagian 3
Tabel 3-6 Piagam proyek (lanjutan)
Mendekati:
• Mengembangkan survei untuk menentukan fitur-fitur penting dari situs intranet baru dan meminta
masukan dari konsultan dan pelanggan.
• Tinjau templat internal dan eksternal serta contoh manajemen proyek
dokumen.
•Meneliti perangkat lunak untuk memberikan keamanan, mengelola masukan pengguna, dan memfasilitasi
pengambilan artikel dan fitur Tanya Pakar.
•Mengembangkan situs intranet menggunakan pendekatan berulang, meminta banyak hal
umpan balik pengguna.
•Mengembangkan cara untuk mengukur nilai situs intranet dalam hal pengurangan biaya dan
pendapatan baru, baik selama proyek berlangsung maupun satu tahun setelah proyek selesai.
PERAN DAN TANGGUNG JAWAB (DAFTAR SEBAGIAN)
Nama Peran Posisi Kontak informasi
Joe Fleming Mensponsori Konsultasi JWD, joe_fleming@jwdconsulting.com

CEO
Erica Bell Proyek JWD Consulting, erica_bell@jwdconsulting.com

Pengelola manajer
Tim Michael Chen JWD Consulting, michael_chen@jwdconsulting.com

Anggota konsultan senior
Jessie Faue Tim JWD Consulting, jessie_faue@jwdconsulting.com

Anggota konsultan
Tim Kevin Dodge JWD Consulting, kevin_dodge@jwdconsulting.com

Anggota departemen TI
Cindy Tim JWD Consulting, cindy_dawson@jwdconsulting.com

Dawson Anggota departemen TI
Kim Phuong Klien Penasihat kim_phuong@client1.com

perwakilan
Halaman Miller Klien Penasihat halaman_miller@client2.com

perwakilan
Sign-Off: (Tanda tangan seluruh pemangku kepentingan di atas)

Komentar: (Komentar yang ditulis tangan atau diketik dari pemangku kepentingan di atas, jika ada)
“Saya akan mendukung proyek ini jika waktu memungkinkan, tetapi saya yakin proyek klien saya mendapat prioritas. Saya
akan meminta salah satu asisten saya untuk mendukung proyek ini sesuai kebutuhan.”—Michael Chen
“Kita harus sangat berhati-hati—menguji sistem baru ini, terutama keamanan dalam memberikan
akses ke bagian situs intranet kepada publik dan klien.”—Kevin Dodge dan Cindy Dawson
Mengadakan Rapat Pembukaan Proyek
Manajer proyek berpengalaman seperti Erica tahu bahwa sangat penting untuk memulai proyek dengan baik.
Mengadakan pertemuan awal yang baik adalah cara terbaik untuk melakukan hal ini. Pertemuan awal adalah
pertemuan yang diadakan di awal proyek sehingga para pemangku kepentingan dapat bertemu satu sama lain,
meninjau tujuan proyek, dan mendiskusikan rencana masa depan. Pertemuan awal sering diadakan setelah
kasus bisnis dan piagam proyek selesai, namun dapat diadakan lebih cepat, sesuai kebutuhan. Meskipun beberapa
atau seluruh pemangku kepentingan proyek harus bertemu secara virtual, tetap penting untuk mengadakan
pertemuan awal.
Erica juga mengetahui bahwa semua pertemuan proyek dengan pemangku kepentingan utama harus
mencakup sebuah agenda. Gambar 3-2 menunjukkan agenda yang disediakan Erica untuk pertemuan awal proyek
situs intranet manajemen proyek. Perhatikan topik utama dalam sebuah agenda:
•Tujuan pertemuan
•Agenda (daftar topik yang akan dibahas secara berurutan)
•Bagian untuk mendokumentasikan item tindakan, kepada siapa item tersebut ditugaskan, dan kapan
setiap orang akan menyelesaikan tindakan tersebut
•Bagian untuk mendokumentasikan tanggal dan waktu pertemuan berikutnya
[Tanggal Rapat]
Proyek Situs Intranet Manajemen Proyek
Gambar 3-2 Agenda pertemuan pembuka

106 bagian 3
Merupakan praktik yang baik untuk berfokus pada hasil rapat, itulah sebabnya agenda yang baik memiliki
bagian untuk mendokumentasikan item tindakan dan memutuskan tanggal dan waktu rapat berikutnya. Ini juga
merupakan praktik yang baik untuk mendokumentasikan notulensi rapat, dengan fokus pada keputusan-keputusan
penting dan item-item tindakan. Erica berencana mengirimkan notulensi rapat kepada seluruh peserta rapat
dan pemangku kepentingan terkait lainnya dalam satu atau dua hari setelah rapat.
Perencanaan proyek
Perencanaan seringkali merupakan proses yang paling sulit dan tidak dihargai dalam manajemen proyek.
Karena perencanaan tidak selalu digunakan untuk memfasilitasi tindakan, banyak orang memandang
perencanaan secara negatif. Namun, tujuan utama rencana proyek adalah untuk memandu pelaksanaan proyek.
Untuk memandu pelaksanaan, rencana harus realistis dan berguna, sehingga proses perencanaan harus
memakan waktu dan upaya yang cukup. Orang yang mempunyai pengetahuan tentang pekerjaan perlu
merencanakan pekerjaan. Bab 4, Manajemen Integrasi Proyek, memberikan informasi rinci tentang persiapan
rencana manajemen proyek, dan Bab 5 hingga 13 menjelaskan proses perencanaan untuk setiap bidang
pengetahuan lainnya.
Tabel 3-7 mencantumkan bidang pengetahuan manajemen proyek, proses, dan keluaran perencanaan
proyek menurut Panduan PMBOK® – Edisi Keenam. Jika Anda berencana untuk mendapatkan sertifikasi PMP®
atau CAPM® , akan sangat membantu jika mempelajari tabel ini dan tabel serupa yang terdapat dalam bab
ini untuk memahami potensi keluaran dari setiap kelompok proses. Ada banyak keluaran potensial dari kelompok
proses perencanaan, dan setiap bidang pengetahuan disertakan. Hanya beberapa dokumen perencanaan dari
proyek situs intranet manajemen proyek JWD Consulting yang diberikan dalam bab ini sebagai contoh, dan bab
selanjutnya menyertakan lebih banyak contoh.
Tabel 3-7 Proses dan keluaran perencanaan
Bidang Pengetahuan Proses perencanaan Keluaran
Integrasi Proyek Mengembangkan Rencana manajemen proyek

Pengelolaan rencana manajemen proyek
Ruang lingkup proyek Rencanakan ruang lingkup rencana manajemen ruang lingkup
Pengelolaan Rencana manajemen persyaratan
Kumpulkan persyaratan Dokumentasi persyaratan

Matriks ketertelusuran persyaratan
Tentukan ruang lingkup Pernyataan ruang lingkup proyek

Buat WBS Garis dasar cakupan

Jadwal proyek Jadwal rencana Rencana pengelolaan jadwal

Pengelolaan pengelolaan
(lanjutan)
Tabel 3-7 Proses dan keluaran perencanaan (lanjutan)
Tentukan aktivitas Daftar aktivitas

Atribut aktivitas
Daftar pencapaian
Perubahan permintaan
Urutan kegiatan Diagram jaringan jadwal proyek

Perkirakan durasi Perkiraan durasi aktivitas

aktivitas Dasar perkiraan
Kembangkan jadwal Jadwalkan garis dasar

Jadwal proyek
Jadwalkan data
Kalender proyek
Biaya proyek Rencanakan manajemen biaya Rencana manajemen biaya

Pengelolaan
Perkirakan biaya Perkiraan biaya

Dasar perkiraan
Tentukan anggaran Dasar biaya

Persyaratan pendanaan proyek
Kualitas Proyek Rencanakan manajemen mutu Rencana manajemen mutu

Pengelolaan Metrik kualitas
Sumber Daya Proyek Rencanakan sumber daya Rencana pengelolaan sumber daya
Pengelolaan pengelolaan Piagam tim
Perkirakan aktivitas Pembaruan dokumen proyek
sumber daya Persyaratan sumber daya
Dasar perkiraan
Struktur rincian sumber daya
Proyek Rencanakan komunikasi Rencana manajemen komunikasi

Komunikasi pengelolaan Pembaruan rencana manajemen proyek
Pengelolaan Pembaruan dokumen proyek
(lanjutan)
108 bagian 3
Tabel 3-7 Proses dan keluaran perencanaan (lanjutan)
Risiko Proyek Rencanakan manajemen risiko Rencana manajemen risiko

Pengelolaan Identifikasi risiko Daftar risiko
Laporan risiko
Lakukan analisis risiko kualitatif Pembaruan dokumen proyek
Lakukan analisis risiko kuantitatif Perubahan permintaan
Rencanakan respons risiko Pembaruan dokumen proyek
Proyek Merencanakan Rencana pengelolaan pengadaan

Pengadaan manajemen pengadaan Strategi pengadaan
Pengelolaan Dokumen penawaran
Pernyataan kerja pengadaan
Kriteria pemilihan sumber
Membuat atau membeli keputusan
Perkiraan biaya independen
Pembaruan aset proses organisasi
Proyek Pemangku kepentingan rencana Rencana keterlibatan pemangku kepentingan

Pemangku kepentingan pertunangan
Pengelolaan
Ingatlah bahwa Panduan PMBOK® hanyalah sebuah panduan, sehingga banyak organisasi mungkin
memiliki keluaran perencanaan yang berbeda berdasarkan kebutuhan khusus mereka, seperti yang terjadi dalam contoh ini.
Anda juga dapat menggunakan banyak templat untuk perencanaan; beberapa tercantum di bagian terakhir bab ini.
Karena proyek situs intranet manajemen proyek relatif kecil, Erica yakin beberapa dokumen
perencanaan terpenting yang perlu diperhatikan adalah sebagai berikut:
• Piagam tim, hasil perencanaan pengelolaan sumber daya proyek

•Pernyataan ruang lingkup proyek
•Struktur rincian kerja, merupakan bagian penting dari dasar cakupan
•Jadwal proyek, dalam bentuk diagram Gantt dengan semua dependensi dan
sumber daya yang dimasukkan
•Daftar risiko yang diprioritaskan (bagian dari daftar risiko)
Semua dokumen ini, serta informasi terkait proyek lainnya, akan tersedia untuk semua anggota tim di situs web
proyek. JWD Consulting telah menggunakan situs web proyek untuk
beberapa tahun, dan telah menemukan bahwa mereka membantu memfasilitasi komunikasi dan
mendokumentasikan informasi proyek. Untuk proyek yang lebih besar, JWD Consulting juga menghasilkan banyak
keluaran lain yang tercantum pada Tabel 3-7. (Anda akan mempelajari lebih lanjut tentang dokumen-dokumen ini
berdasarkan bidang pengetahuan di bab-bab berikut.)
Segera setelah tim proyek menandatangani piagam proyek, Erica mengadakan pertemuan pembangunan
tim. Tujuan penting dari pertemuan ini adalah membantu anggota tim proyek untuk mengenal satu sama lain.
Erica telah bertemu dan berbicara dengan masing-masing anggota secara terpisah, tetapi ini adalah pertama kalinya
tim proyek menghabiskan banyak waktu bersama. Jessie Faue bekerja di Kantor Manajemen Proyek bersama
Erica, jadi mereka mengenal satu sama lain dengan baik, namun Jessie masih baru di perusahaan tersebut dan
tidak mengenal satu pun anggota tim lainnya. Michael Chen adalah seorang konsultan senior dan sering
mengerjakan proyek dengan prioritas tertinggi untuk klien eksternal. Dia menghadiri pertemuan tersebut
bersama asistennya, Jill Anderson, yang akan mendukung proyek tersebut ketika Michael terlalu sibuk. Semua
orang menghargai keahlian Michael, dan dia sangat lugas dalam berurusan dengan orang lain. Dia juga mengenal
kedua perwakilan klien dari proyek sebelumnya. Kevin Dodge adalah guru intranet JWD Consulting, yang cenderung
fokus pada detail teknis. Cindy Dawson juga berasal dari departemen TI dan memiliki pengalaman bekerja sebagai
konsultan bisnis dan bernegosiasi dengan pemasok luar. Kim Phuong dan Page Miller, dua perwakilan klien,
sangat antusias dengan proyek ini, namun mereka enggan membagikan informasi sensitif tentang perusahaan mereka.
Erica tahu bahwa penting untuk membangun tim yang kuat dan membuat semua orang bekerja sama dengan
baik. Beliau mempersilahkan seluruh peserta untuk memperkenalkan diri, kemudian beliau memimpin kegiatan
icebreaking agar semua peserta dapat lebih santai. Ia meminta seluruh peserta untuk menggambarkan liburan
impian mereka, dengan asumsi bahwa biaya tidak menjadi masalah. Kegiatan ini membantu setiap orang untuk
mengenal satu sama lain dan menunjukkan berbagai aspek kepribadian mereka.
Erica kemudian menjelaskan pentingnya proyek tersebut, dan kembali meninjau proyek yang telah ditandatangani
piagam. Dia menjelaskan bahwa alat penting untuk membantu tim proyek bekerja sama adalah dengan meminta
anggota mengembangkan piagam tim yang semua orang merasa nyaman untuk menandatanganinya. JWD
Consulting percaya dalam menggunakan piagam tim untuk semua proyek guna membantu meningkatkan kerja tim
dan memperjelas komunikasi tim. Dia menjelaskan topik utama yang dibahas dan menunjukkan kepada mereka
templat piagam tim. Dia kemudian meminta anggota tim membentuk dua kelompok kecil, dengan satu konsultan,
satu anggota departemen TI, dan satu perwakilan klien di setiap kelompok.
Kelompok-kelompok kecil ini memudahkan setiap orang untuk menyumbangkan ide. Masing-masing kelompok
berbagi ide tentang apa yang harus dimasukkan ke dalam piagam, dan kemudian semua orang bekerja sama untuk
membentuk satu piagam tim proyek. Tabel 3-8 menunjukkan hasil piagam tim, yang pembuatannya memerlukan
waktu sekitar 90 menit. Erica bisa melihat ada kepribadian yang berbeda-beda di tim ini, tapi dia merasa mereka
semua bisa bekerja sama dengan baik.
Erica ingin membatasi waktu pertemuan pembentukan tim menjadi dua jam. Tugas selanjutnya adalah
memperjelas ruang lingkup proyek dengan mengembangkan pernyataan ruang lingkup proyek dan WBS. Dia
tahu akan memerlukan waktu dan beberapa pertemuan di masa depan untuk mengembangkan dokumen-dokumen
ini, namun dia ingin mendapatkan gambaran tentang apa yang dianggap sebagai hasil utama proyek ini, peran
mereka dalam menghasilkan hasil tersebut, dan bidang lingkup proyek mana yang perlu diklarifikasi. . Dia
mengingatkan semua orang mengenai tujuan anggaran dan jadwal mereka sehingga mereka selalu mengingat
tujuan tersebut saat mendiskusikan ruang lingkup proyek. Dia juga meminta setiap orang untuk memberikan jumlah
jam yang dia inginkan
110 bagian 3
Tabel 3-8 Piagam tim
Kode Etik: Sebagai tim proyek, kita akan:
•Bekerja secara proaktif, mengantisipasi potensi masalah dan berupaya mencegahnya.

• Selalu memberi informasi kepada anggota tim lainnya tentang informasi terkait proyek.
•Fokus pada apa yang terbaik untuk seluruh tim proyek.
Partisipasi: Kami akan:
•Bersikap jujur dan terbuka selama seluruh kegiatan proyek.

• Mendorong keberagaman dalam kerja tim.
•Memberikan peluang partisipasi yang setara.
•Bersikaplah terbuka terhadap pendekatan baru dan pertimbangkan ide-ide baru.
•Lakukan diskusi satu per satu.
•Beri tahu manajer proyek terlebih dahulu jika ada anggota tim yang harus melewatkan rapat atau mungkin
kesulitan memenuhi tenggat waktu untuk tugas tertentu.
Komunikasi: Kami akan:
•Putuskan sebagai sebuah tim tentang cara terbaik untuk berkomunikasi. Karena beberapa tim
anggota tidak dapat sering bertemu langsung, kami akan menggunakan email, situs web proyek, dan
teknologi lainnya untuk membantu berkomunikasi.
•Mintalah manajer proyek memfasilitasi semua pertemuan dan mengatur konferensi telepon dan video,
jika diperlukan.
•Bekerja sama untuk membuat jadwal proyek dan memasukkan data aktual ke dalam sistem
manajemen proyek seluruh perusahaan paling lambat pukul 4 sore setiap hari Jumat.
•Menyajikan ide-ide dengan jelas dan ringkas.
•Jauhkan diskusi pada jalurnya.
Pemecahan Masalah: Kami akan:
•Mendorong setiap orang untuk berpartisipasi dalam memecahkan masalah.

•Hanya gunakan kritik yang membangun dan fokus pada penyelesaian masalah, bukan menyalahkan
rakyat.
•Berusaha untuk membangun ide masing-masing.
Pedoman Rapat: Kami akan:
•Mengadakan pertemuan tatap muka pada Selasa pagi pertama dan ketiga setiap bulan.
• Bertemu lebih sering pada bulan pertama.
•Mengadakan pertemuan lain bila diperlukan.
•Mencatat notulensi rapat dan mengirimkannya melalui email dalam waktu 24 jam setelah seluruh
rapat proyek, dengan fokus pada keputusan yang diambil dan item tindakan dari setiap rapat.
bersedia untuk mengerjakan proyek ini setiap bulan selama enam bulan ke depan. Dia kemudian meminta
setiap orang menuliskan jawaban atas pertanyaan-pertanyaan berikut:
1. Buatlah daftar satu hal yang paling tidak jelas bagi Anda mengenai ruang lingkup proyek ini.
2. Pertanyaan atau masalah lain apa yang Anda perkirakan mengenai ruang lingkupnya
proyek?
3. Buatlah daftar apa yang Anda yakini sebagai hasil utama proyek ini.
4. Hasil apa yang menurut Anda akan Anda bantu buat atau tinjau?
Erica mengumpulkan masukan semua orang. Dia menjelaskan bahwa dia akan mengambil informasi ini
dan bekerja dengan Jessie untuk mengembangkan draf pertama pernyataan ruang lingkup yang akan dia
kirimkan melalui email kepada semua orang pada akhir minggu. Dia juga menyarankan agar mereka semua bertemu
lagi dalam satu minggu untuk mengembangkan pernyataan ruang lingkup lebih lanjut dan mulai membuat WBS
untuk proyek tersebut.
Erica dan Jessie meninjau semua informasi dan membuat draf pertama pernyataan ruang lingkup. Pada
pertemuan tim berikutnya, mereka membahas pernyataan ruang lingkup dan memulai WBS dengan baik. Tabel 3-9
menunjukkan sebagian dari pernyataan ruang lingkup yang dibuat Erica setelah beberapa email lagi dan pertemuan
tim lainnya. Perhatikan bahwa pernyataan ruang lingkup mencantumkan karakteristik dan persyaratan produk,
merangkum hasil, dan menjelaskan kriteria keberhasilan proyek secara rinci.
Tabel 3-9 Draf pernyataan ruang lingkup
Judul Proyek: Proyek Situs Intranet Manajemen Proyek

Tanggal: 18 Mei Disiapkan oleh: Erica Bell, Manajer Proyek, erica_bell@jwdconsulting.com
Ringkasan dan Justifikasi Proyek: Joe Fleming, CEO JWD Consulting, meminta proyek ini untuk membantu
perusahaan dalam mencapai tujuan strategisnya. Situs intranet baru akan meningkatkan visibilitas keahlian
perusahaan kepada klien saat ini dan calon klien. Hal ini juga akan membantu mengurangi biaya internal dan
meningkatkan profitabilitas dengan menyediakan alat standar, teknik, template, dan pengetahuan manajemen
proyek untuk semua konsultan internal.
Anggaran untuk proyek ini adalah $140.000. Tambahan $40.000 per tahun akan diperlukan untuk biaya operasional
setelah proyek selesai. Perkiraan manfaatnya adalah $200.000 setiap tahun. Penting untuk fokus pada
sistem yang dapat membayar sendiri dalam waktu satu tahun setelah penyelesaiannya.
Karakteristik dan Persyaratan Produk:
1. Templat dan alat: Situs intranet akan mengizinkan pengguna yang berwenang untuk mengunduh
file yang dapat mereka gunakan untuk membuat dokumen manajemen proyek dan membantu mereka
menggunakan alat manajemen proyek. File-file ini akan dalam format Microsoft Word, Excel, Access,
Project, atau dalam format HTML atau PDF, jika diperlukan.
2. Pengiriman pengguna: Pengguna akan didorong untuk mengirimkan file berisi contoh template dan alat
melalui email ke Webmaster. Webmaster akan meneruskan file tersebut ke orang yang tepat
untuk ditinjau dan kemudian memposting file tersebut ke situs intranet, jika diinginkan.
3. Artikel: Artikel yang diposting di situs intranet akan memiliki hak cipta yang sesuai
izin. Format artikel yang disukai adalah PDF. Manajer proyek dapat menyetujui format lain.
4. Permintaan artikel: Situs intranet akan menyertakan bagian bagi pengguna untuk meminta seseorang
dari Kantor Manajemen Proyek (PMO) di JWD Consulting untuk meneliti artikel yang sesuai untuk
mereka. Manajer PMO harus terlebih dahulu menyetujui permintaan tersebut dan menegosiasikan
pembayaran, jika diperlukan.
(lanjutan)
112 bagian 3
Tabel 3-9 Draf pernyataan ruang lingkup (lanjutan)
5. Tautan: Semua tautan ke situs eksternal akan diuji setiap minggu. Tautan rusak akan terjadi
diperbaiki atau dihapus dalam waktu lima hari kerja setelah ditemukan.
6. Fitur Tanya Ahli harus mudah digunakan dan mampu meminta
pertanyaan dan segera mengakui bahwa pertanyaan telah diterima dalam format yang benar. Fitur
tersebut juga harus mampu meneruskan pertanyaan kepada pakar yang sesuai (seperti yang disimpan
dalam database pakar sistem) dan mampu memberikan status pertanyaan yang telah terjawab. Sistem
juga harus memungkinkan pembayaran untuk nasihat, jika diperlukan.
7. Keamanan: Situs intranet harus menyediakan beberapa tingkat keamanan. Semua karyawan
internal akan memiliki akses ke seluruh situs intranet ketika mereka memasukkan informasi
keamanan untuk mengakses intranet utama perusahaan. Bagian dari intranet akan tersedia untuk
umum dari situs web perusahaan. Bagian lain dari intranet akan tersedia untuk klien saat ini
berdasarkan verifikasi dengan database klien saat ini. Bagian lain dari intranet akan tersedia setelah
menegosiasikan biaya atau memasukkan pembayaran tetap menggunakan metode pembayaran pra-
otorisasi.
8. Fitur Pencarian: Situs intranet harus menyertakan fitur pencarian agar pengguna dapat mencari
berdasarkan topik dan kata kunci.
9. Situs intranet harus dapat diakses menggunakan browser Internet yang disetujui perusahaan.
Pengguna harus memiliki perangkat lunak aplikasi yang sesuai untuk membuka beberapa template dan
alat.
10. Situs intranet harus tersedia 24 jam sehari, 7 hari seminggu, dengan satu jam per minggu untuk
pemeliharaan sistem dan pemeliharaan berkala lainnya, jika diperlukan.
Ringkasan Hasil Proyek

Hasil terkait manajemen proyek: Kasus bisnis, piagam proyek, piagam tim, pernyataan ruang
lingkup, WBS, jadwal, garis besar biaya, laporan kemajuan, presentasi proyek akhir, laporan proyek akhir,
laporan pembelajaran, dan dokumen lain yang diperlukan untuk mengelola proyek .
Hasil terkait produk:
1. Survei: Survei konsultan dan klien saat ini untuk membantu menentukan konten yang diinginkan
dan fitur untuk situs intranet.
2. File untuk templat: Situs intranet setidaknya akan menyertakan templat
20 dokumen saat sistem pertama kali diimplementasikan, dan akan memiliki kapasitas
untuk menyimpan hingga 100 dokumen. Tim proyek akan memutuskan 20 template awal berdasarkan
hasil survei.
3. Contoh template yang sudah lengkap: Situs intranet akan menyertakan contoh
proyek yang telah menggunakan templat yang tersedia di situs. Misalnya, jika ada template untuk kasus
bisnis, maka akan ada juga contoh kasus bisnis nyata yang menggunakan template tersebut.
(lanjutan)
Tabel 3-9 Draf pernyataan ruang lingkup (lanjutan)
4. Petunjuk penggunaan alat manajemen proyek: Situs intranet akan memuat informasi tentang cara
menggunakan beberapa alat manajemen proyek, termasuk minimal berikut ini: struktur rincian kerja,
bagan Gantt, diagram jaringan, perkiraan biaya, dan manajemen nilai yang diperoleh. Jika diperlukan, file
sampel akan disediakan dalam perangkat lunak aplikasi yang sesuai untuk alat tersebut. Misalnya, file
Microsoft Project akan tersedia untuk memperlihatkan contoh struktur rincian kerja, bagan Gantt,
diagram jaringan, perkiraan biaya, dan aplikasi manajemen nilai yang diperoleh. File Excel akan tersedia
untuk contoh perkiraan biaya dan grafik manajemen nilai yang diperoleh.
5. Contoh penerapan alat: Situs intranet akan menyertakan contoh nyata

proyek yang telah menerapkan alat yang tercantum di nomor 4.
6. Artikel: Situs intranet akan memuat setidaknya 10 artikel bermanfaat yang relevan
topik dalam manajemen proyek. Situs intranet tersebut akan mampu menyimpan sedikitnya 1.000 artikel dalam
format PDF dengan rata-rata panjang masing-masing 10 halaman.
7. Tautan: Situs intranet akan menyertakan tautan dengan deskripsi singkat untuk setidaknya 20 situs bermanfaat.
Tautan tersebut akan dikategorikan ke dalam kelompok yang bermakna.
8. Basis data pakar: Untuk menghadirkan fitur Tanya Pakar, sistem harus menyertakan dan mengakses basis
data pakar yang disetujui dan informasi kontak mereka.
Pengguna akan dapat mencari pakar berdasarkan topik yang telah ditentukan.
9. Fitur Permintaan Pengguna: Situs intranet akan menyertakan aplikasi untuk meminta dan
memproses permintaan dari pengguna.
10. Desain situs intranet: Desain awal situs intranet baru akan mencakup sebuah situs
peta, format yang disarankan, dan grafik yang sesuai. Desain akhir akan memasukkan komentar dari pengguna
pada desain awal.
11. Konten situs intranet: Situs intranet akan menyertakan konten untuk bagian templat dan alat, bagian artikel, bagian
pengambilan artikel, bagian tautan, bagian Tanya Ahli, fitur Permintaan Pengguna, keamanan, dan fitur
pembayaran.
12. Rencana pengujian: Rencana pengujian akan mendokumentasikan bagaimana situs intranet akan diuji, siapa yang akan mengujinya
melakukan pengujian, dan bagaimana bug akan dilaporkan.
13. Promosi: Rencana untuk mempromosikan situs intranet secara internal dan eksternal akan menjelaskan
berbagai pendekatan untuk meminta masukan selama perancangan. Rencana promosi juga akan
mengumumkan ketersediaan situs intranet baru.
14. Rencana pengukuran manfaat proyek: Rencana manfaat proyek akan mengukur nilai finansial situs intranet.
Kriteria Keberhasilan Proyek: Sasaran kami adalah menyelesaikan proyek ini dalam waktu enam bulan dengan biaya
tidak lebih dari $140.000. Sponsor proyek, Joe Fleming, telah menekankan pentingnya proyek ini membayar sendiri dalam
waktu satu tahun setelah situs tersebut selesai dibangun. Untuk memenuhi tujuan finansial ini, situs intranet harus
memiliki masukan pengguna yang kuat. Kita juga harus mengembangkan metode untuk mendapatkan manfaat ketika
situs intranet sedang dikembangkan dan diuji, dan setelah diluncurkan. Jika proyek membutuhkan waktu lebih lama
untuk diselesaikan atau biayanya sedikit lebih mahal dari yang direncanakan, perusahaan akan tetap menganggapnya
sukses jika proyek tersebut memiliki pengembalian yang baik dan membantu meningkatkan citra perusahaan sebagai
organisasi konsultan yang unggul.
114 bagian 3
Saat tim proyek mengerjakan pernyataan ruang lingkup, tim juga mengembangkan WBS untuk proyek
tersebut. WBS merupakan alat yang sangat penting dalam manajemen proyek karena memberikan dasar
untuk memutuskan bagaimana melakukan pekerjaan. WBS juga memberikan dasar untuk membuat jadwal
proyek dan untuk mengukur serta memperkirakan kinerja proyek.
Erica dan timnya memutuskan untuk menggunakan kelompok proses manajemen proyek sebagai kategori
utama WBS, seperti yang ditunjukkan pada Gambar 3-3. Hal ini mencakup pekerjaan yang telah selesai sejak
proses permulaan untuk memberikan gambaran lengkap tentang ruang lingkup proyek. Anggota tim juga
ingin membuat daftar beberapa pencapaian dalam jadwal mereka, seperti penyelesaian kiriman utama,
sehingga mereka menyiapkan daftar pencapaian terpisah yang akan mereka sertakan dalam bagan Gantt.
Anda akan mempelajari lebih lanjut tentang membuat WBS di Bab 5, Manajemen Lingkup Proyek.
Setelah mempersiapkan WBS, tim proyek mengadakan pertemuan tatap muka lagi untuk mengembangkan
jadwal proyek, mengikuti langkah-langkah yang diuraikan dalam Bagian 2.5 WBS.
Beberapa tugas jadwal proyek bergantung satu sama lain. Misalnya, pengujian situs intranet bergantung pada
konstruksi dan penyelesaian tugas konten. Setiap orang berpartisipasi dalam penyusunan jadwal, terutama tugas-
tugas yang akan dikerjakan masing-masing anggota. Beberapa tugas dipecah lebih lanjut sehingga anggota tim
memiliki pemahaman yang lebih baik tentang apa yang harus mereka lakukan dan kapan.
Mereka juga mempertimbangkan beban kerja dan kendala biaya saat mengembangkan perkiraan durasi.
Misalnya, Erica dijadwalkan untuk bekerja 20 jam per minggu pada proyek ini, dan gabungan anggota tim
proyek lainnya tidak boleh menghabiskan rata-rata lebih dari 60 jam per minggu untuk proyek tersebut. Saat
anggota tim memberikan perkiraan durasi, mereka juga memperkirakan berapa jam kerja yang akan mereka
habiskan untuk setiap tugas.
Setelah pertemuan tersebut, Erica bekerja dengan Jessie untuk memasukkan semua informasi ke
dalam Microsoft Project. Erica menggunakan proyek situs intranet untuk melatih Jessie dalam menerapkan
beberapa alat dan templat manajemen proyek. Mereka memasukkan semua tugas, perkiraan durasi, dan
ketergantungan untuk mengembangkan bagan Gantt. Masukan awal mereka menghasilkan tanggal penyelesaian
yang beberapa minggu lebih lambat dari yang direncanakan. Erica dan Jessie meninjau jalur kritis untuk proyek
tersebut, dan Erica harus mempersingkat perkiraan durasi untuk beberapa tugas penting guna memenuhi
target jadwal mereka untuk menyelesaikan proyek dalam waktu enam bulan. Dia berbicara dengan anggota
tim yang mengerjakan tugas-tugas tersebut, dan mereka sepakat bahwa mereka dapat merencanakan untuk
bekerja lebih banyak setiap minggunya pada tugas-tugas tersebut, jika diperlukan, agar dapat menyelesaikannya
tepat waktu. Gambar 3-4 menunjukkan hasil bagan Gantt yang dibuat di Microsoft Project. Hanya tugas
pelaksana yang diperluas untuk menampilkan subtugas dalam kategori tersebut. (Anda akan mempelajari cara
menggunakan Project 2016 di Lampiran A, yang tersedia di situs web Pendamping untuk teks ini. Bab 6,
Manajemen Jadwal Proyek, menjelaskan bagan Gantt dan alat manajemen jadwal lainnya.)
Jadwal dasar memproyeksikan tanggal penyelesaian pada tanggal 1 November. Perhatikan juga bahwa
hanya ada satu pengiriman perangkat lunak, yang ditampilkan sebagai tonggak sejarah menjelang akhir proyek,
pada tanggal 17 Oktober. Piagam proyek memiliki tanggal penyelesaian yang direncanakan pada tanggal 4
November. Erica ingin menyelesaikan proyek tepat waktu, dan meskipun tiga hari tambahan bukanlah waktu
yang lama, dia merasa bahwa jadwal dasar adalah realistis. Dia akan melakukan yang terbaik untuk membantu
semua orang memenuhi tenggat waktu mereka.
Erica memutuskan untuk memasukkan informasi sumber daya dan biaya setelah meninjau jadwal
karena sebagian besar biaya proyek ini adalah tenaga kerja internal. Menyadari
1.0 Memulai
1.1 Identifikasi pemangku kepentingan
1.2 Piagam proyek 1.3

Rapat permulaan 2.0
Perencanaan
2.1 Rapat perencanaan tim 2.2
Piagam tim 2.3
Pernyataan ruang lingkup
2.4 WBS
2.5 Jadwal dan dasar biaya 2.5.1
Sumber daya tugas
2.5.2 Durasi tugas 2.5.3
Ketergantungan tugas 2.5.4
Draf diagram Gantt
2.5.5 Bagan Gantt akhir
2.6 Prioritas risiko 3.0
Pelaksana 3.1
Survei 3.2
Masukan pengguna
3.3 Konten situs intranet
3.3.1 Template dan alat 3.3.2
Artikel 3.3.3
Tautan
3.3.4 Tanyakan pada
Pakar 3.3.5 Fitur Permintaan Pengguna
3.4 Desain situs Intranet 3.5
Konstruksi situs Intranet
3.6 Pengujian situs intranet
3.7 Promosi situs intranet 3.8
Peluncuran situs intranet
3.9 Pengukuran manfaat proyek 4.0
Pemantauan dan Pengendalian 4.1
Laporan kemajuan 4.2
Permintaan perubahan
5.0 Penutupan
5.1 Laporan akhir proyek 5.2
Presentasi proyek akhir 5.3
Pembelajaran
Gambar 3-3 Struktur rincian kerja proyek intranet (WBS) JWD Consulting
116 bagian 3
Gambar 3-4 Bagan Gantt dasar proyek situs intranet JWD Consulting
Dari hubungan antara waktu yang dihabiskan dan biaya proyek, tim selalu mempertimbangkan batasan jam kerja saat
mengembangkan perkiraan durasi tugas. Erica dan Jessie memasukkan nama masing-masing anggota tim proyek
dan tingkat tenaga kerja di lembar sumber daya untuk file Microsoft Project mereka. Perwakilan klien tidak dibayar atas
waktu mereka, jadi dia membiarkan tarif tenaga kerja mereka pada nilai default nol. Erica juga memasukkan $10.000
untuk pengadaan dalam analisis keuangan yang dia siapkan untuk kasus bisnis. Dia menunjukkan kepada Jessie cara
memasukkan jumlah tersebut sebagai biaya tetap yang dibagi rata antara fitur Tanya Pakar dan Permintaan Pengguna,
karena menurutnya mereka harus membeli perangkat lunak dan layanan eksternal untuk hal tersebut. Erica
kemudian membantu Jessie menetapkan sumber daya untuk tugas-tugas, yang melibatkan memasukkan jumlah jam
yang diproyeksikan setiap orang yang direncanakan untuk bekerja setiap minggu pada setiap tugas. Mereka kemudian
membuat beberapa laporan biaya dan membuat beberapa penyesuaian kecil terhadap penugasan sumber daya
agar total biaya yang direncanakan memenuhi batasan anggaran mereka. Biaya dasar mereka sangat dekat dengan
anggaran yang direncanakan sebesar $140.000.
Hasil terakhir yang perlu dibuat oleh timnya dalam kelompok proses perencanaan adalah daftar risiko yang
diprioritaskan. Seiring berjalannya proyek, informasi ini akan diperbarui dan diperluas dalam daftar risiko, yang juga
mencakup informasi tentang akar penyebab risiko, tanda-tanda peringatan bahwa potensi risiko mungkin terjadi, dan
strategi respons terhadap risiko tersebut.
(Lihat Bab 11, Manajemen Risiko Proyek, untuk informasi lebih lanjut mengenai daftar risiko.) Erica meninjau risiko-risiko
yang telah disebutkannya dalam kasus bisnis serta komentar-komentar yang dibuat anggota tim pada piagam proyek dan
dalam pertemuan tim mereka. Dia mengadakan pertemuan khusus bagi semua orang untuk bertukar pikiran dan
mendiskusikan potensi risiko. Mereka membuat daftar semua risiko yang mereka identifikasi dan kemudian
mengelompokkannya untuk menganalisis seberapa besar kemungkinannya (probabilitas tinggi, sedang, atau rendah)
dan seberapa besar dampaknya (tinggi, sedang, atau rendah).
Hanya satu risiko yang masuk dalam kategori probabilitas tinggi dan dampak tinggi, dan beberapa risiko mempunyai
dampak sedang. Mereka memilih untuk tidak membuat daftar risiko dengan probabilitas rendah dan dampak rendah.
Setelah berdiskusi, tim mengembangkan daftar risiko yang diprioritaskan seperti yang ditunjukkan pada Tabel 3-10.
Tabel 3-10 Daftar risiko yang diprioritaskan
Peringkat Resiko potensial
1 Kurangnya masukan dari konsultan internal
2 Kurangnya masukan dari perwakilan klien
3 Keamanan sistem baru

4 Outsourcing/pembelian untuk pengambilan artikel dan fitur Tanya Ahli
5 Outsourcing/pembelian untuk memproses transaksi pembayaran online

6 Mengatur templat dan contoh dengan cara yang bermanfaat
7 Menyediakan fitur pencarian yang efisien
8 Mendapatkan feedback yang baik dari Michael Chen dan konsultan senior lainnya
9 Mempromosikan sistem baru secara efektif
10 Menyadari manfaat sistem baru dalam waktu satu tahun
Eksekusi projek
Pelaksana proyek melibatkan pengambilan tindakan yang diperlukan untuk menyelesaikan kegiatan
dalam rencana proyek. Produk proyek dibuat selama pelaksanaan proyek, dan biasanya dibutuhkan
sumber daya paling banyak untuk menyelesaikan proses ini. Tabel 3-11 mencantumkan bidang
pengetahuan, proses pelaksanaan, dan keluaran pelaksanaan proyek dari PMBOK®
Panduan – Edisi Keenam.
Banyak sponsor proyek dan pelanggan fokus pada hasil yang terkait dengan penyediaan produk,
layanan, atau hasil yang diinginkan dari proyek. Namun, mendokumentasikan permintaan perubahan
dan memperbarui dokumen perencanaan juga sama pentingnya sebagai bagian dari pelaksanaan.
Templat yang terkait dengan grup proses ini dicantumkan nanti di bab ini.
Erica tahu bahwa memberikan kepemimpinan yang kuat dan menggunakan keterampilan komunikasi yang baik adalah hal yang penting
penting untuk pelaksanaan proyek yang baik. Untuk proyek yang relatif kecil ini, dia dapat bekerja sama
dengan semua anggota tim untuk memastikan mereka mencapai hasil pekerjaan yang diinginkan. Dia
juga menggunakan keterampilan jaringannya untuk mendapatkan masukan dari orang lain di perusahaan
dan dari sumber eksternal tanpa biaya tambahan untuk proyek tersebut. Dia memastikan bahwa setiap
orang yang akan menggunakan aplikasi intranet yang dihasilkan memahami apa yang dihasilkan tim
sebagai bagian dari proyek dan bagaimana aplikasi intranet akan membantu mereka di masa depan.
Erica juga tahu bahwa bekerja secara efisien sangat penting untuk keberhasilan
pelaksanaan, terlepas dari ukuran proyeknya. Oleh karena itu, dia menggunakan sumber daya di
seluruh perusahaan jika tersedia. Misalnya, dia menggunakan formulir permintaan perubahan
formal perusahaan, meskipun formulir tersebut terutama digunakan untuk proyek eksternal. Perusahaan
tersebut juga mempunyai spesialis kontrak dan templat untuk beberapa dokumen pengadaan yang akan
digunakan oleh anggota tim proyek untuk bagian proyek yang direncanakan untuk dialihdayakan.
Erica ingat bahwa Joe, CEO dan sponsor proyek, senang melihat data kinerja melalui
laporan pencapaian. Dia juga ingin Erica mengingatkannya akan hal apa pun
118 bagian 3
Tabel 3-11 Menjalankan proses dan keluaran
Bidang Pengetahuan Proses Eksekusi Keluaran
Integrasi Proyek Mengarahkan dan mengelola Hasil kerja

Pengelolaan pekerjaan proyek Data prestasi kerja
Catatan masalah
Kelola pengetahuan Daftar pelajaran yang dipelajari

proyek Pembaruan rencana manajemen proyek
Kualitas Proyek Kelola kualitas Laporan kualitas

Pengelolaan Dokumen pengujian dan evaluasi
Sumber Daya Proyek Dapatkan sumber daya Penugasan sumber daya fisik
Pengelolaan Penugasan tim proyek
Kalender sumber daya
Pembaruan faktor lingkungan perusahaan

Penilaian kinerja tim
Kembangkan tim Perubahan permintaan

Kelola tim Perubahan permintaan

Proyek Kelola Komunikasi proyek

Komunikasi komunikasi Pembaruan rencana manajemen proyek
(lanjutan)
Tabel 3-11 Menjalankan proses dan keluaran (lanjutan)
Bidang Pengetahuan Proses Eksekusi Keluaran
Risiko Proyek Menerapkan risiko Perubahan permintaan

Pengelolaan tanggapan Pembaruan dokumen proyek
Proyek Mengadakan Penjual terpilih

Pengadaan pengadaan Perjanjian
Proyek Kelola keterlibatan Perubahan permintaan

Pemangku kepentingan pemangku kepentingan Pembaruan rencana manajemen proyek
potensi masalah atau masalah. Erica sering bertemu dengan sebagian besar anggota tim proyeknya, dan
dia berbicara dengan Joe seminggu sekali untuk meninjau kemajuan dalam menyelesaikan pencapaian dan
mendiskusikan masalah proyek lainnya. Meskipun Erica dapat menggunakan perangkat lunak manajemen
proyek untuk membuat laporan pencapaian, dia malah menggunakan perangkat lunak pengolah kata karena
proyek ini kecil dan dia dapat lebih mudah memanipulasi format laporan. Tabel 3-12 menunjukkan contoh
laporan pencapaian proyek situs intranet manajemen proyek yang ditinjau Erica bersama Joe pada pertengahan
Juni.
Permasalahan sumber daya manusia sering terjadi pada saat pelaksanaan proyek, terutama konflik.
Dalam beberapa pertemuan tim, Erica melihat Michael terlihat bosan dan sering keluar ruangan untuk
menelepon klien. Dia berbicara dengan Michael tentang situasinya, dan dia mengetahui bahwa Michael
mendukung proyek tersebut, namun dia tahu dia hanya dapat menghabiskan sedikit waktu untuk proyek
tersebut. Dia jauh lebih produktif di luar rapat, jadi Erica setuju agar Michael menghadiri rapat tim proyek dalam
jumlah minimal.
Dia dapat melihat bahwa Michael berkontribusi kepada tim melalui umpan balik yang dia berikan dan
kepemimpinannya pada fitur Tanya Pakar untuk situs intranet. Erica menyesuaikan gaya komunikasinya untuk
memenuhi kebutuhan spesifiknya.
Masalah lain terjadi ketika Cindy menghubungi calon pemasok perangkat lunak
untuk membantu fitur Tanya Pakar dan Permintaan Pengguna. Kevin ingin menulis sendiri semua perangkat
lunak untuk proyek tersebut, namun Cindy tahu bahwa akan lebih masuk akal secara bisnis jika membeli
kemampuan perangkat lunak baru ini dari sumber yang dapat dipercaya. Cindy harus meyakinkan Kevin
bahwa membeli beberapa perangkat lunak dari sumber lain layak dilakukan.
Cindy juga menemukan bahwa perkiraan mereka sebesar $10.000 hanya sekitar setengah dari jumlah
yang mereka butuhkan untuk layanan perangkat lunak. Dia mendiskusikan masalahnya dengan Erica,
menjelaskan perlunya pengembangan khusus, tidak peduli pemasok mana yang mereka pilih. Erica setuju
bahwa mereka harus mencari sumber dari luar, dan dia meminta sponsor mereka untuk menyetujui dana
tambahan. Joe menyetujuinya, namun dia menekankan pentingnya agar sistem tetap dapat membayar sendiri
dalam waktu satu tahun.
120 bagian 3
Tabel 3-12 Laporan Milestone per 17 Juni

Masalah/
Tonggak pencapaian Tanggal Status Bertanggung jawab Komentar
Memulai 2 Mei Lengkap Erica dan Joe

Pemangku
kepentingan diidentifikasi
Piagam proyek 10 Mei Lengkap Erica

ditandatangani
Pertemuan awal 13 Mei Lengkap Erica Berjalan dengan sangat baik
proyek diadakan
Perencanaan 13 Mei Lengkap Erica

Piagam tim ditandatangani
Pernyataan ruang 27 Mei Lengkap Erica

lingkup selesai
WBS selesai 31 Mei Lengkap Erica
Daftar risiko yang 3 Juni Lengkap Erica Ditinjau dengan

diprioritaskan selesai sponsor dan
tim
Jadwal dan baseline 13 Juni Lengkap Erica

biaya selesai
Eksekusi 28 Juni Erica Respons yang buruk

Survei dan analisis sejauh ini!
selesai
Desain situs intranet 26 Juli Kevin

selesai
Pengukuran 9 Agustus Erica

manfaat proyek selesai
Masukan pengguna 9 Agustus Jessie

dikumpulkan
Artikel selesai 23 Agustus Jessie
Templat dan alat selesai 6 September Erica
Tanyakan pada 6 September Michael

Pakar selesai
(lanjutan)
Tabel 3-12 Laporan Milestone per 17 Juni (lanjutan)

Masalah/
Tonggak pencapaian Tanggal Status Bertanggung jawab Komentar
Fitur Permintaan 6 September Cindy

Pengguna selesai
Tautan selesai 13 September Kevin
situs intranet 4 Oktober Kevin

konstruksi
lengkap
Pengujian situs intranet 18 Oktober Cindy

selesai
situs intranet 25 Oktober Erica

promosi
selesai
Peluncuran situs intranet 25 Oktober Kevin

selesai
Pemantauan dan Setiap Semua
Mengontrol Jumat
Laporan kemajuan
Penutupan
Presentasi 27 Oktober Erica

tugas akhir
selesai
Penandatanganan 27 Oktober Joe

sponsor pada proyek selesai
Laporan tugas akhir 28 Oktober Erica

selesai
Laporan 1 November Semua
pembelajaran diserahkan
Bahkan di awal proyek, Erica telah meminta bantuan Joe saat menjadi tim
menerima tingkat respons yang rendah terhadap survei dan permintaan masukan pengguna. Joe
mengirim email ke seluruh konsultan JWD Consulting yang menjelaskan pentingnya proyek ini. Dia juga
menawarkan lima hari libur tambahan kepada orang yang memberikan contoh terbaik tentang bagaimana
mereka menggunakan alat dan templat untuk mengelola proyek mereka. Erica kemudian mendapat
masukan informatif dari para konsultan. Memiliki keterampilan komunikasi yang efektif dan
dukungan manajemen puncak yang kuat sangat penting untuk pelaksanaan proyek yang baik.
122 bagian 3
Praktek terbaik
Salah satu cara untuk mempelajari praktik terbaik dalam manajemen proyek adalah dengan
mempelajari penerima penghargaan Project of the Year dari PMI. Quartier International de Montréal (QIM), distrik
internasional Montreal, adalah proyek revitalisasi perkotaan seluas 66 hektar di jantung pusat kota Montreal.
Proyek berdurasi lima tahun senilai $90 juta ini mengubah kawasan yang tadinya tidak populer menjadi bagian
kota yang berkembang pesat dengan pasar real estat yang sedang booming, dan telah menghasilkan $770 juta
dalam bidang konstruksi terkait. Clement Demers, PMP®, adalah direktur jenderal proyek QIM. Dia mengatakan
tim “mengambil pendekatan pelaksanaan proyek yang unik dengan membagi pekerjaan ke dalam paket-
paket yang memungkinkan pengujian teknik manajemen dan pemberian kontrak dalam skala yang lebih
kecil. Dengan memanfaatkan pengalaman yang diperoleh di setiap tahap, para manajer kemudian dapat
menyesuaikan segmen kerja di masa depan dan gaya manajemen.”11
Strategi lain yang membantu keberhasilan tim adalah sebagai berikut:
•Tim mengidentifikasi pemimpin di setiap kelompok pemangku kepentingan untuk membantu menginspirasi kelompok lain
ers untuk mencapai tujuan proyek.
•Rencana komunikasi tim mencakup situs web yang didedikasikan untuk publik
kekhawatiran.
•Ada tinjauan dua hari di awal setiap fase proyek untuk didiskusikan
masalah dan mengembangkan solusi untuk mencegah konflik.
•Investor keuangan dimintai masukan untuk meningkatkan kepemilikannya di
proyek.
•Tim menyadari pentingnya mempekerjakan ahli berkualitas tinggi, seperti
arsitek, insinyur, pengacara, dan perencana kota. Mereka membayar semua profesional dengan
harga tetap untuk layanan mereka dan membayar biaya mereka dengan cepat.
•Perusahaan Kanada lainnya memenangkan penghargaan Project of the Year pada tahun 2014.
Proyek AP60 Fase 1 senilai CA $1,3 miliar menghasilkan fasilitas peleburan aluminium yang
ditingkatkan di Jonquiere, Quebec. Pada tahun 2013, proyek desalinasi Adelaide di Adelaide,
Australia, memenangkan penghargaan tersebut. Proyek ini, yang memasok air selama masa
kekeringan, diselesaikan lebih awal dan menghabiskan dana sebesar 1 persen dari
anggarannya sebesar AU$1,4 miliar.12 Penghargaan pada tahun 2017 diberikan kepada
perusahaan AS Washington River Protection Solutions, LLC atas pekerjaan mereka pada Hanford
Double Shell Tank AY -102 Proyek Pemulihan. Proyek ini melibatkan pemindahan dan
pemindahan limbah nuklir ke tangki bercangkang ganda untuk penyimpanan yang aman. Proyek ini
selesai lebih cepat dari jadwal dan lebih dari 8 persen di bawah anggaran.13 Lihat situs web PMI
untuk informasi lebih lanjut mengenai kriteria penghargaan dan pemenang.
Pemantauan dan Pengendalian Proyek

Pemantauan dan pengendalian adalah proses mengukur kemajuan terhadap tujuan proyek,
memantau penyimpangan dari rencana saat ini, dan mengambil tindakan perbaikan untuk
mencocokkan kemajuan dengan rencana saat ini. Pemantauan dan pengendalian dilakukan sepanjang
umur proyek dan melibatkan 10 bidang pengetahuan manajemen proyek. Tabel 3-13 mencantumkan
bidang pengetahuan, proses pemantauan dan pengendalian, serta keluarannya, menurut Panduan
PMBOK® – Edisi Keenam. Templat yang terkait dengan grup proses ini dicantumkan nanti di bab ini.
Tabel 3-13 Pemantauan dan pengendalian proses dan keluaran
Pemantauan dan
Bidang Pengetahuan Mengontrol Keluaran Proses
Integrasi Proyek Memantau dan mengendalikan Laporan prestasi kerja

Pengelolaan pekerjaan proyek Perubahan permintaan
Pembaruan rencana manajemen
proyek
Lakukan kontrol Permintaan perubahan yang disetujui

perubahan terintegrasi Pembaruan rencana manajemen proyek
Ruang lingkup proyek Validasi cakupan Kiriman yang diterima

Pengelolaan Informasi prestasi kerja
Ruang lingkup kendali Informasi prestasi kerja

Jadwal proyek Jadwal pengendalian Informasi prestasi kerja

Pengelolaan Jadwalkan perkiraan
Biaya proyek Biaya pengendalian Informasi prestasi kerja

Pengelolaan Perkiraan biaya
Kualitas Proyek Kontrol kualitas Pengukuran kendali mutu

Pengelolaan Kiriman terverifikasi
Informasi prestasi kerja
Sumber Daya Proyek Kontrol sumber daya Informasi kinerja kerja

(lanjutan)
124 bagian 3
Tabel 3-13 Pemantauan dan pengendalian proses dan keluaran (lanjutan)
Pemantauan dan
Bidang Pengetahuan Mengontrol Keluaran Proses
Manajemen Komunikasi Pantau Informasi prestasi kerja

Proyek komunikasi Perubahan permintaan
Pemangku Kepentingan Proyek Pantau pemangku kepentingan Informasi prestasi kerja

Pengelolaan pertunangan Perubahan permintaan
Risiko Proyek Pantau risiko Informasi prestasi kerja

Pengadaan Proyek Kontrol Pengadaan tertutup

Pengelolaan pengadaan Informasi prestasi kerja
Pembaruan dokumentasi pengadaan
Pada proyek situs intranet manajemen proyek, beberapa pembaruan pada rencana manajemen
proyek dilakukan untuk mencerminkan perubahan yang dilakukan pada ruang lingkup, jadwal, dan
anggaran proyek. Erica dan anggota tim proyek lainnya mengambil tindakan perbaikan bila diperlukan.
Misalnya, ketika survei mereka tidak mendapat banyak tanggapan, Erica meminta bantuan Joe. Ketika
Cindy kesulitan bernegosiasi dengan pemasok, dia mendapat bantuan dari konsultan senior lain yang
pernah bekerja dengan pemasok tersebut di masa lalu. Erica juga harus meminta lebih banyak dana untuk
bagian proyek tersebut.
Anggota tim proyek menyerahkan laporan kemajuan singkat setiap hari Jumat untuk
menunjukkan informasi kinerja kerja. Mereka awalnya menggunakan template perusahaan untuk
laporan kemajuan, namun Erica menemukan bahwa dengan memodifikasi template lama, dia
menerima informasi yang lebih baik, yang kemudian membantu timnya bekerja lebih efektif. Dia ingin
anggota tim tidak hanya melaporkan apa yang mereka lakukan namun juga fokus pada apa yang berjalan
baik atau tidak, dan alasannya. Informasi tambahan ini membantu anggota tim merefleksikan kemajuan
proyek dan mengidentifikasi area yang memerlukan perbaikan. Tabel 3-14 adalah contoh salah satu
laporan kemajuan Cindy.
Tabel 3-14 Contoh laporan kemajuan mingguan
Nama Proyek: Proyek Intranet Manajemen Proyek

Nama Anggota Tim: Cindy Dawson, cindy_dawson@jwdconsulting.com
Tanggal: 5 Agustus
Pekerjaan selesai minggu ini:

–Bekerja dengan Kevin untuk memulai pembangunan situs intranet
–Mengatur semua file konten

–Mulai mengembangkan skema penamaan file untuk file konten
–Melanjutkan pengerjaan fitur Tanya Pakar dan Permintaan Pengguna
–Bertemu dengan pemasok pilihan
–Memverifikasi bahwa perangkat lunak mereka akan memenuhi kebutuhan kami
–Menemukan perlunya beberapa penyesuaian
Pekerjaan yang harus diselesaikan minggu depan:
–Lanjutkan pekerjaan pada pembangunan situs intranet
–Menyiapkan rancangan kontrak untuk pemasok pilihan

–Mengembangkan perkiraan biaya baru untuk pekerjaan outsourcing
Apa yang berjalan baik dan alasannya:
Pembangunan situs intranet dimulai dengan baik. Desainnya sangat jelas dan mudah diikuti. Kevin benar-benar tahu
apa yang dia lakukan.
Apa yang tidak berjalan baik dan alasannya:
Sulit untuk memutuskan bagaimana mengatur template dan contoh. Perlu lebih banyak masukan dari konsultan senior
dan klien.
Saran/Masalah:
–Mengadakan pertemuan khusus untuk memutuskan bagaimana mengatur template dan contoh di
situs intranet.
–Dapatkan beberapa contoh kontrak dan bantuan dalam bernegosiasi dengan pemasok pilihan.
Perubahan proyek:
Saya pikir kita bisa tetap sesuai jadwal, tapi sepertinya kita memerlukan sekitar $10.000 lebih untuk outsourcing. Ini berarti
menggandakan anggaran kami di bidang itu.
Selain laporan kemajuan, alat penting untuk memantau dan mengendalikan proyek adalah menggunakan
perangkat lunak manajemen proyek. Semua anggota tim menyerahkan jam kerja aktual mereka pada tugas setiap Jumat
sore pukul 4 sore melalui perangkat lunak manajemen proyek perusahaan. Mereka menggunakan Microsoft Project 2016
versi perusahaan, sehingga mereka dapat dengan mudah memperbarui informasi tugas mereka melalui Web. Erica bekerja
dengan Jessie untuk menganalisis informasi, memberikan perhatian khusus pada jalur kritis dan data nilai yang diperoleh. (Lihat
Bab 6, Manajemen Jadwal Proyek, untuk informasi lebih lanjut mengenai analisis jalur kritis; Bab 7, Manajemen Biaya
Proyek, untuk deskripsi manajemen nilai yang diperoleh; dan Lampiran A, tersedia di situs web Pendamping untuk teks ini,
untuk informasi lebih lanjut tentang penggunaan Project 2016 untuk membantu mengendalikan proyek.) Erica menginginkannya
126 bagian 3
menyelesaikan proyek tepat waktu, meskipun itu berarti mengeluarkan lebih banyak uang. Joe setuju dengan
pendekatan itu, dan menyetujui pendanaan tambahan yang diproyeksikan Erica yang akan mereka perlukan
berdasarkan proyeksi nilai yang diperoleh dan kebutuhan untuk menyediakan sedikit waktu untuk tugas-tugas penting.
Joe sekali lagi menekankan pentingnya sistem baru ini dapat terbayar dalam waktu satu tahun. Erica
yakin bahwa keuntungan tersebut dapat melebihi keuntungan finansial yang diproyeksikan, dan dia
memutuskan untuk mulai memperoleh manfaat segera setelah tim proyek mulai menguji sistem tersebut. Ketika
dia tidak sedang mengerjakan proyek ini, Erica mengelola Kantor Manajemen Proyek (PMO) JWD
Consulting, dan dia sudah dapat melihat bagaimana situs intranet akan membantu stafnya menghemat waktu
dan membuat konsultan mereka lebih produktif.
Salah satu anggota stafnya ingin pindah ke kelompok konsultan, dan dia yakin PMO dapat terus memberikan
layanan yang ada saat ini dengan mengurangi satu orang karena sistem baru ini—keuntungan yang belum
pernah dipertimbangkan Erica sebelumnya. Beberapa kontrak klien perusahaan tersebut didasarkan pada kinerja
dan bukan jam kerja, jadi dia bersemangat untuk mulai mengukur nilai situs intranet baru tersebut kepada konsultan
mereka juga.
Penutupan Proyek
Proses penutupan melibatkan perolehan penerimaan pemangku kepentingan dan pelanggan atas produk dan
layanan akhir dan kemudian mengakhiri proyek atau fase proyek dengan tertib.
Hal ini mencakup verifikasi bahwa semua kiriman telah selesai, dan sering kali mencakup laporan dan
presentasi proyek akhir. Meskipun banyak proyek TI dibatalkan sebelum selesai, tetap penting untuk menutup
proyek secara resmi dan merenungkan apa yang dapat dipelajari untuk meningkatkan proyek di masa depan.
Seperti yang dikatakan filsuf George Santayana, “Mereka yang tidak dapat mengingat masa lalu dikutuk untuk
mengulanginya.”14
Penting juga untuk merencanakan dan melaksanakan kelancaran transisi proyek ke dalam operasional
normal perusahaan. Sebagian besar proyek memberikan hasil yang diintegrasikan ke dalam struktur organisasi
yang ada. Misalnya, proyek situs intranet manajemen proyek JWD Consulting akan memerlukan staf untuk
mendukung situs intranet setelah beroperasi. Erica memasukkan biaya dukungan sebesar $40.000 per tahun
untuk proyeksi umur tiga tahun sistem baru. Dia juga membuat rencana transisi sebagai bagian dari laporan
akhir untuk memberikan kelancaran transisi sistem ke dalam operasi perusahaan. Rencana tersebut mencakup
daftar masalah yang harus diselesaikan sebelum perusahaan dapat memproduksi situs intranet baru.
Misalnya, Michael Chen tidak dapat bekerja di situs intranet setelah proyek enam bulan selesai, sehingga tim
harus mengetahui siapa yang akan mendukung fitur Tanya Pakar dan merencanakan waktu agar Michael dapat
bekerja dengan orang tersebut.
Tabel 3-15 mencantumkan bidang pengetahuan, proses, dan keluaran penutupan proyek berdasarkan
Panduan PMBOK® – Edisi Keenam. Selama proses penutupan proyek apa pun, anggota tim proyek harus
menyampaikan produk akhir, layanan, atau hasil proyek dan memperbarui aset proses organisasi, seperti file proyek
dan laporan pembelajaran. Jika anggota tim proyek membeli barang selama proyek berlangsung, mereka harus
menyelesaikan atau menutup semua kontrak secara resmi. Templat yang terkait dengan penutupan proyek
dicantumkan nanti di bab ini.
Erica dan timnya menyiapkan laporan akhir, presentasi akhir, dan laporan pembelajaran
dalam menutup proyek. Erica meninjau laporan pembelajaran individual yang bersifat rahasia dari
masing-masing anggota tim dan menulis satu ringkasan
laporan pembelajaran untuk disertakan dalam dokumentasi akhir, yang sebagian disajikan pada Tabel 3-16.
Perhatikan poin-poin dalam pertanyaan keempat, seperti pentingnya mengadakan pertemuan awal yang baik,
bekerja sama untuk mengembangkan piagam tim, menggunakan perangkat lunak manajemen proyek, dan
berkomunikasi dengan baik dengan tim proyek dan
sponsor.
Erica juga meminta Joe menandatangani formulir penerimaan klien, salah satu contoh templat di situs
intranet baru yang disarankan oleh tim proyek untuk digunakan semua konsultan saat penutupan.
Tabel 3-15 Penutupan proses dan keluaran
Bidang Pengetahuan Proses Penutupan Keluaran
Integrasi Proyek Tutup proyek atau Pembaruan dokumen proyek

Pengelolaan fase Produk akhir, layanan, atau transisi hasil
Laporan akhir
Tabel 3-16 Laporan pembelajaran (disingkat)
Nama Proyek: Proyek Situs Intranet Manajemen Proyek JWD Consulting
Sponsor Proyek: Joe Fleming
Manajer Proyek: Erica Bell
Tanggal Proyek: 2 Mei – 4 November
Anggaran Akhir: $150.000
1. Apakah proyek memenuhi sasaran ruang lingkup, waktu, dan biaya?
Kami memang memenuhi sasaran ruang lingkup dan waktu, namun kami harus meminta tambahan
$10.000, yang disetujui sponsor.
2. Apa saja kriteria keberhasilan yang tercantum dalam pernyataan ruang lingkup proyek?
Di bawah ini adalah apa yang kami masukkan dalam pernyataan ruang lingkup proyek kami di bawah kriteria keberhasilan proyek:
“Tujuan kami adalah menyelesaikan proyek ini dalam waktu enam bulan dengan biaya tidak lebih dari $140,000.
Sponsor proyek, Joe Fleming, telah menekankan pentingnya proyek ini membayar sendiri dalam
waktu satu tahun setelah situs intranet selesai dibangun. Untuk memenuhi tujuan finansial ini, situs
intranet harus memiliki masukan pengguna yang kuat. Kita juga harus mengembangkan metode untuk
mendapatkan manfaat ketika situs intranet sedang dikembangkan dan diuji, dan setelah diluncurkan.
Jika proyek membutuhkan waktu lebih lama untuk diselesaikan atau biayanya sedikit lebih mahal dari
yang direncanakan, perusahaan akan tetap menganggapnya sukses jika proyek tersebut memiliki
pengembalian yang baik dan membantu meningkatkan citra perusahaan sebagai organisasi
konsultan yang unggul.”
(lanjutan)
128 bagian 3
Tabel 3-16 Laporan pembelajaran (disingkat) (lanjutan)
3. Renungkan apakah Anda memenuhi kriteria keberhasilan proyek.
Sebagaimana dinyatakan di atas, sponsor tidak terlalu khawatir mengenai kelebihan anggaran selama sistem
tersebut memiliki periode pengembalian modal yang baik dan membantu meningkatkan citra perusahaan kami.
Kami telah mendokumentasikan beberapa manfaat finansial dan citra dari situs intranet baru ini. Misalnya, kami
telah memutuskan bahwa kami dapat mengurangi satu orang staf di PMO, sehingga menghasilkan
penghematan biaya yang besar. Kami juga telah menerima tanggapan yang sangat baik dari beberapa klien
kami tentang situs intranet baru.
4. Apa pembelajaran utama yang diperoleh tim Anda dari pengelolaan proyek ini?
Pelajaran utama yang kami pelajari meliputi hal-hal berikut:
• Memiliki sponsor proyek yang baik berperan penting dalam kesuksesan proyek. Kami menghadapi beberapa
situasi sulit, dan Joe sangat kreatif dalam membantu kami memecahkan masalah.
• Kerja sama tim sangat penting. Sangat membantu untuk meluangkan waktu bagi semua orang untuk melakukannya
saling mengenal pada pertemuan awal. Mengembangkan dan mengikuti piagam tim juga bermanfaat.
• Perencanaan yang baik membuahkan hasil dalam pelaksanaannya. Kami menghabiskan cukup banyak waktu
mengembangkan piagam proyek yang baik, pernyataan ruang lingkup, WBS, jadwal, dan sebagainya.
Semua orang bekerja sama untuk mengembangkan dokumen perencanaan ini, dan terdapat dukungan
yang kuat.
• Perangkat lunak manajemen proyek sangat membantu selama proyek berlangsung.
5. Jelaskan satu contoh mengenai apa yang berjalan baik dalam proyek ini.
6. Jelaskan satu contoh kesalahan dalam proyek ini.
7. Apa yang akan Anda lakukan secara berbeda pada proyek berikutnya berdasarkan pengalaman Anda bekerja
pada proyek ini?
proyek mereka. (Anda dapat menemukan templat ini dan templat lainnya di situs web Pendamping untuk teks ini.)
Tabel 3-17 menyajikan daftar isi laporan tugas akhir. Halaman sampul mencantumkan judul proyek, tanggal,
dan nama anggota tim. Perhatikan penyertaan rencana transisi dan rencana untuk menganalisis manfaat sistem
setiap tahun dalam laporan akhir. Juga, perhatikan bahwa laporan akhir mencakup lampiran untuk semua manajemen
proyek dan dokumen terkait produk. Erica tahu betapa pentingnya menyediakan dokumentasi akhir yang baik mengenai
proyek. Tim proyek menghasilkan salinan cetak dari dokumentasi akhir dan salinan elektronik untuk disimpan di
situs intranet baru agar konsultan lain dapat digunakan sesuai keinginan.
Erica juga menyelenggarakan makan siang penutupan proyek untuk tim proyek tepat setelah presentasi proyek
akhir. Dia memanfaatkan makan siang tersebut untuk berbagi pembelajaran dan merayakan pekerjaan yang telah
diselesaikan dengan baik.
Tabel 3-17 Daftar isi laporan tugas akhir
1. Tujuan Proyek 2.
Ringkasan Hasil Proyek 3. Tanggal
Mulai dan Berakhir Asli dan Aktual 4. Anggaran Asli
dan Aktual 5. Penilaian Proyek
(Mengapa Anda melakukan proyek ini? Apa yang Anda hasilkan? Apakah proyek tersebut
proyek sukses? Apa yang benar dan salah dalam proyek ini?)
6. Rencana Transisi
7. Pendekatan Pengukuran Manfaat Proyek Tahunan
Lampiran:
Dokumentasi Manajemen Proyek

•Kasus bisnis •Piagam
proyek •Piagam tim
•Pernyataan ruang
lingkup •Kamus WBS dan
WBS •Bagan dasar dan aktual Gantt
chart •Daftar risiko yang diprioritaskan
•Laporan pencapaian •Laporan
kemajuan •File kontrak
•Laporan pembelajaran
•Presentasi akhir
•Formulir penerimaan klien
B Dokumentasi Terkait Produk
•Survei dan hasil •Ringkasan

masukan pengguna •Konten situs
intranet •Dokumen desain situs
intranet •Rencana dan laporan pengujian
•Informasi promosi situs intranet
•Informasi peluncuran situs intranet •Informasi
pengukuran manfaat proyek
Studi Kasus 2: Manajemen Proyek JWD Consulting

Proyek Situs Intranet (Pendekatan Agile)
Bagian ini menunjukkan pendekatan tangkas dalam mengelola proyek situs intranet manajemen proyek
JWD Consulting. Daripada mengulangi contoh dokumen yang ditunjukkan pada studi kasus prediktif pertama,
bagian ini menekankan perbedaan penggunaan pendekatan tangkas di setiap kelompok proses. Ingatlah
bahwa pendekatan tangkas sering digunakan untuk proyek di
130 bagian 3
dimana tim bisnis tidak dapat dengan jelas mengungkapkan ruang lingkup di awal siklus hidup produk, namun tim ingin
menyediakan produk yang berpotensi dapat dikirim lebih awal daripada nanti.
Tim proyek yang tangkas biasanya menggunakan beberapa iterasi atau pengiriman perangkat lunak daripada menunggu
hingga akhir proyek untuk menyediakan satu produk.
Perhatikan bahwa tim biasanya tidak mengambil keputusan cepat apakah akan mengelola proyek
menggunakan pendekatan tangkas atau tidak. Demikian pula, Anda tidak asal memutuskan apakah akan naik pesawat atau
mobil dalam perjalanan jauh tanpa logika tertentu. Jika Anda ingin pergi ke suatu tempat dengan cepat, tidak terlalu
memikirkan jalan-jalan di sepanjang perjalanan, dan tidak memiliki masalah dengan penerbangan, Anda mungkin akan
naik pesawat. Jika Anda ingin meluangkan waktu untuk pergi ke suatu tempat, melihat pemandangan di sepanjang jalan,
dan menikmati berkendara, Anda akan menggunakan mobil. Demikian pula, organisasi harus menggunakan logika untuk
memutuskan kapan menggunakan pendekatan prediktif atau pendekatan tangkas untuk mengelola proyek tertentu.
Proyek dengan kendala berat, tim yang tidak berpengalaman dan tersebar, risiko besar, persyaratan awal yang jelas,
dan tanggal penyelesaian yang cukup kaku sebaiknya dilakukan dengan menggunakan pendekatan prediktif.
Sebaliknya, proyek dengan batasan yang tidak terlalu kaku, tim yang berpengalaman dan lebih disukai berada di lokasi
yang sama, risiko yang lebih kecil, persyaratan yang tidak jelas, dan penjadwalan yang lebih fleksibel akan lebih cocok
dengan pendekatan agile. Proyek yang sama digunakan pada bagian ini untuk menyoroti perbedaan utama
antara proses dan keluaran dari kedua pendekatan ini.
Saat menggunakan teknik tangkas dan metode paling populernya, Scrum, yang digunakan oleh tim
peran, artefak, dan upacara tertentu.
Peran, Artefak, dan Upacara Scrum

Ingat dari Bab 2 bahwa Scrum mencakup tiga peran utama peserta proyek:
• Pemilik produk: Orang yang bertanggung jawab atas nilai bisnis proyek dan memutuskan pekerjaan apa
yang harus dilakukan dan bagaimana urutannya, sebagaimana didokumentasikan dalam product
backlog. Dalam hal ini, Joe Fleming adalah pemilik produk. Dia adalah CEO JWD Consulting dan
orang yang menyarankan proyek tersebut.
• ScrumMaster: Orang yang memastikan bahwa tim tetap produktif, memfasilitasi Scrum harian, memungkinkan
kerja sama yang erat di seluruh peran dan fungsi, dan menghilangkan hambatan yang menghambat
efektivitas tim. ScrumMaster mempunyai wewenang atas proses tersebut tetapi tidak pada orang-
orang dalam tim. Mereka harus merasa nyaman menyerahkan kendali kepada pemilik produk dan tim.
Beberapa ahli berpendapat bahwa manajer proyek tradisional tidak bisa menjadi Scrum Master yang
hebat. Dalam hal ini, Erica Bell akan menerima tantangan tersebut dan berperan sebagai ScrumMaster.
• Tim scrum atau tim pengembangan: Sebuah tim lintas fungsi yang terdiri dari lima hingga sembilan orang
orang-orang yang mengatur diri mereka sendiri dan bekerja untuk menghasilkan hasil yang diinginkan
untuk setiap sprint. Sprint biasanya berlangsung selama dua hingga empat minggu, di mana
pekerjaan tertentu harus diselesaikan dan siap untuk ditinjau. Proyek besar mungkin memerlukan tim
dari tim. Dalam hal ini, Michael Chen, Jessie Faue, Kevin Dodge, Cindy Dawson, Kim Phuong, dan Page
Miller adalah anggota tim pengembangan. Posisi mereka tercantum dalam piagam proyek yang
ditunjukkan sebelumnya pada Tabel 3-6. Kim dan Page adalah perwakilan klien yang tidak bekerja
untuk JWD Consulting, namun mereka adalah anggota tim utama, terutama untuk mengembangkan
bagian intranet yang akan digunakan oleh klien eksternal.
Di Scrum, artefak adalah objek berguna yang dibuat oleh manusia. Artefak dapat disebut sebagai
penyampaian dalam pendekatan manajemen proyek lainnya. Tiga artefak berikut dibuat dengan Scrum:
• Product backlog: Daftar fitur yang diprioritaskan berdasarkan nilai bisnis. Itu
item dengan prioritas tertinggi harus dipecah secara cukup rinci agar tim dapat memperkirakan
upaya yang diperlukan untuk mengembangkannya. Beberapa ahli menyarankan penjadwalan
sekitar 10 hari kerja untuk setiap item. Ukuran dan kompleksitas pekerjaan menentukan perkiraannya.
• Sprint backlog: Item dengan prioritas tertinggi dari product backlog yang harus diselesaikan
dalam sprint. Tim Scrum memecah item dengan prioritas tertinggi menjadi tugas-tugas kecil
yang membutuhkan waktu sekitar 12 hingga 16 jam untuk diselesaikan.
Contoh sprint backlog dan product backlog diberikan nanti di bagian Perencanaan.
• Bagan Burndown: Menampilkan sisa pekerjaan kumulatif dalam sprint setiap harinya. Contoh diagram
burndown disajikan kemudian di bagian ini di bagian Pemantauan dan Pengendalian.
ScrumMaster memfasilitasi empat upacara atau pertemuan ketika menggunakan metode Scrum:
• Sesi perencanaan sprint: Pertemuan dengan tim untuk memilih serangkaian pekerjaan dari product
backlog yang akan diselesaikan selama sprint. Pertemuan ini memakan waktu sekitar empat jam
hingga sehari penuh.
• Scrum Harian: Pertemuan singkat bagi tim pengembangan untuk berbagi kemajuan dan tantangan
serta merencanakan pekerjaan hari itu. Idealnya anggota tim berada di tempat yang sama, rapat
biasanya berlangsung tidak lebih dari 15 menit, dan diadakan pada waktu dan tempat yang sama
setiap harinya. Jika hal tersebut tidak memungkinkan, tim dapat menggunakan konferensi video
untuk mengadakan pertemuan virtual singkat. ScrumMaster menanyakan pekerjaan apa yang telah
dilakukan sejak kemarin, pekerjaan apa yang direncanakan hari ini, dan hambatan atau
hambatan apa yang mungkin menghambat upaya tim. ScrumMaster mendokumentasikan hambatan-
hambatan ini dan bekerja sama dengan pemangku kepentingan utama untuk menyelesaikannya
setelah Scrum harian. Banyak tim menggunakan istilah permasalahan untuk hal-hal yang tidak
harus diselesaikan dalam waktu 24 jam ke depan dan istilah penghambat untuk hal-hal yang perlu
segera diatasi. Hal ini memungkinkan ScrumMaster untuk mempertahankan fokus pada item
dengan prioritas tertinggi (blocker) terlebih dahulu dan kemudian mengelola penyelesaian masalah
lainnya pada sekitar hari berikutnya.
• Tinjauan sprint: Pertemuan di mana tim mendemonstrasikan kepada pemilik produk apa yang telah
diselesaikan selama sprint.
• Sprint retrospectives: Pertemuan di mana tim mencari cara untuk meningkatkan produk dan proses
berdasarkan tinjauan terhadap kinerja aktual tim pengembangan.
Gambar 3-5 menampilkan bagaimana Anda dapat melihat kerangka Scrum yang ditunjukkan pada Bab 2
dalam hal kelompok proses manajemen proyek. Membuat product backlog, mengembangkan sprint backlog,
dan mendiskusikan rencana selama Scrum harian akan masuk dalam perencanaan. Melakukan pekerjaan
sehari-hari dan melakukan sprint, serta menciptakan peningkatan produk yang berpotensi dapat dikirim
akan cocok untuk dieksekusi. Menyelenggarakan tinjauan sprint
132 bagian 3
dan mendiskusikan tantangan sebagai bagian dari Scrum harian dapat dipandang sebagai pemantauan dan
pengendalian. Bercermin selama sprint retrospektif akan cocok untuk penutupan. Memulai keseluruhan proyek
adalah fase yang berada di luar kerangka Scrum dalam contoh ini.
Tabel 3-18 merangkum beberapa aktivitas unik Scrum yang dilakukan oleh masing-masing kelompok proses.
Bagian berikut ini memberikan rincian lebih lanjut mengenai kegiatan-kegiatan ini.
Ulangi langkah 1–4 hingga selesai
1. Scrum Harian Pemantauan dan

24
2. pengendalian
jam
3.
4.
5.
Berlari Peningkatan
6. 1.
2–4 produk yang
dll. 2. minggu berpotensi
dapat dikirim
Product
backlog Simpanan lari cepat Ulasan
sprint dan
1. Pemilik produk 2. Tim proyek 3. Tim mengadakan 4. Sprint menghasilkan
menciptakan membuat sprint pertemuan Scrum produk yang
Lari
daftar keinginan atau backlog harian selama sprint bermanfaat cepat retro
simpanan yang diprioritaskan 2–4 minggu
spektif
Perencanaan Eksekusi Penutupan
Gambar 3-5 Kerangka Scrum dan kelompok prosesnya
Tabel 3-18 Aktivitas unik Scrum berdasarkan kelompok proses
Memulai:
•Tentukan peran. •Tentukan
berapa banyak sprint yang akan dibuat untuk setiap rilis dan cakupan perangkat lunak
mengantarkan.
Perencanaan:
•Membuat product backlog. •Buat

sprint backlog. •Membuat backlog
rilis. •Rencanakan pekerjaan setiap
hari di Scrum harian. • Dokumentasikan hambatan dalam
sebuah daftar.
Eksekusi:
•Selesaikan tugas setiap hari selama sprint. • Menghasilkan

produk yang dapat dikirim pada akhir setiap sprint.
(lanjutan)
Tabel 3-18 Aktivitas unik Scrum berdasarkan kelompok proses (lanjutan)
Pemantauan dan Pengendalian:

• Menyelesaikan masalah dan hambatan.
•Membuat dan memperbarui grafik burndown.
•Mendemonstrasikan produk yang telah selesai pada pertemuan tinjauan sprint.
Penutupan:
•Merefleksikan bagaimana meningkatkan produk dan proses selama sprint

pertemuan retrospektif.
Pra-Inisiasi dan Inisiasi Proyek

Perbedaan utama antara pra-inisiasi dalam kasus ini dan kasus pertama adalah menentukan peran dan
memutuskan fungsionalitas apa yang akan dikirimkan sebagai bagian dari setiap rilis, berapa banyak sprint yang
diperlukan untuk menyelesaikan sebuah rilis, dan berapa banyak rilis perangkat lunak yang akan dikirimkan. . Hal ini mirip
dengan membagi proyek menjadi beberapa proyek yang lebih kecil.
Piagam proyek, daftar pemangku kepentingan, strategi pengelolaan pemangku kepentingan, dan pertemuan awal akan
tetap dibuat sebagai bagian dari inisiasi, sama seperti yang ada dalam versi prediktif kasus ini. Namun, dengan
menggunakan peran Scrum, Joe Fleming akan menjadi pemilik produk, Erica Bell sebagai ScrumMaster, dan orang lain
yang tercantum dalam piagam proyek akan menjadi anggota tim.
Joe bertemu dengan Erica untuk mendiskusikan fungsionalitas apa yang akan diberikan dalam setiap rilis, berapa
banyak sprint yang diperlukan untuk setiap rilis, berapa banyak rilis perangkat lunak yang diperlukan, dan pendekatan
yang diperlukan untuk menyelesaikan proyek. Mereka menyadari bahwa sebelum mereka dapat mengetahui fungsionalitas,
rilis, dan sprint, mereka perlu mensurvei pengguna potensial untuk mengumpulkan persyaratan perangkat lunak baru dan
menentukan cara untuk mengukur nilai situs intranet setelah diimplementasikan. Mereka memperkirakan bahwa
pengumpulan dan analisis informasi dari calon pengguna akan memakan waktu sekitar dua bulan.
Bekerja sama, Joe dan Erica akan membuat survei yang secara spesifik menanyakan potensi
pengguna fitur mana yang akan memberikan nilai paling besar. Misalnya, alih-alih membuat daftar ide-ide umum,
mereka akan membuat daftar fitur-fitur spesifik dan meminta responden mengurutkannya berdasarkan tingkat
kepentingannya. Mereka juga akan meminta responden survei untuk mengirimkan contoh template, alat, dan
informasi berguna lainnya kepada Cindy Dawson, anggota tim proyek di departemen TI. Mengumpulkan informasi
ini terlebih dahulu akan menyederhanakan proses pengembangan perangkat lunak.
Joe dan Erica memutuskan bahwa tiga rilis perangkat lunak akan realistis, mengingat keterbatasan waktu dan
biaya. Setiap sprint akan ditargetkan berlangsung selama empat minggu, dan peninjauan serta pembuatan produk
dan sprint backlog akan menjadi aktivitas berkelanjutan dalam setiap sprint.
Joe dan Erica beberapa kali bertemu dengan Cindy dan anggota tim lainnya. Cindy punya
sebagian besar pengalaman bekerja pada proyek tangkas. Dia membahas pentingnya mengirimkan beberapa desain
antarmuka pengguna grafis kepada calon pengguna untuk mendapatkan masukan mereka. Pendekatan ini sangat
berguna di masa lalu, berdasarkan pengalaman Cindy, dan akan menghemat banyak pengerjaan ulang selama
pengembangan. Misalnya, seorang anggota tim akan membuat satu hingga empat desain antarmuka tertentu untuk
ditinjau oleh calon pengguna dalam sesi yang diselenggarakan
134 bagian 3
oleh tim pemasaran. Cindy menjelaskan bahwa masukan tersebut akan membantu menghasilkan antarmuka
pengguna yang lebih baik dan intuitif. Selain itu, meminta calon pengguna untuk menilai “tampilan dan nuansa”
akan sangat bermanfaat. Misalnya, perhatian pengguna mungkin terganggu oleh skema warna yang dipilih,
sehingga anggota tim harus membuat antarmuka yang sama dalam berbagai skema warna untuk mengukur
mana yang memiliki daya tarik terbesar dan menghasilkan skor kegunaan paling positif. Cindy menjelaskan bahwa
perancang antarmuka pengguna biasanya bukan anggota tim pengembangan, namun organisasi mungkin
menggunakannya untuk memberikan spesifikasi desain terperinci yang menyediakan antarmuka pengguna yang
konsisten. Erica dan Joe belajar banyak dari Cindy dan akan memasukkan rekomendasinya ke dalam rencana
masa depan.
Perencanaan
Daripada membuat piagam tim, WBS, bagan Gantt, dan daftar risiko yang diprioritaskan untuk keseluruhan
proyek, tim mengikuti metode Scrum. Pernyataan ruang lingkup awal untuk keseluruhan proyek masih dapat
menjadi alat yang berguna untuk perencanaan, meskipun tim mengetahui bahwa rincian lebih lanjut akan
ditambahkan dan perubahan akan dilakukan. Karena Scrum menyiratkan bahwa anggota tim bekerja sebagai
kelompok yang mandiri, dilatih oleh ScrumMaster, maka piagam tim tidak diperlukan.
Sebagai pengganti WBS, deskripsi tingkat tinggi mengenai pekerjaan yang harus diselesaikan akan
diidentifikasi dalam produk dan sprint backlog. Tim akan mengembangkan daftar cerita teknis yang lebih rinci dan
tugas terkait yang harus diselesaikan selama setiap sprint. Tim juga harus menetapkan perkiraan kecepatan
(atau kapasitas) untuk setiap sprint berdasarkan ketersediaan anggota tim setiap hari sprint. Perkiraan dapat
diberikan dalam bentuk jam kerja, dengan asumsi bahwa semua pengembang adalah kontraktor yang dapat
membuat kode delapan jam per hari. Perkiraan juga dapat diberikan sebagai poin, dengan asumsi bahwa
pengembang adalah karyawan yang melakukan coding kurang dari delapan jam per hari. Misalnya, enam jam per
hari sama dengan satu poin, jadi upaya 36 jam sama dengan 6 poin.
Bagan Gantt untuk keseluruhan proyek masih dapat dibuat, seperti yang ditunjukkan pada Gambar 3-6. Melihat
bahwa kelompok proses tidak mengikuti pola linier sederhana. Beberapa kelompok proses diulangi untuk
setiap sprint, menghasilkan beberapa rilis produk perangkat lunak yang dapat digunakan, seperti yang ditunjukkan
oleh pencapaian. Ingatlah bahwa dalam versi prediktif kasus ini, hanya ada satu rilis atau pengiriman
perangkat lunak menjelang akhir proyek, pada tanggal 17 Oktober. Dalam kasus ini, dua pengiriman perangkat
lunak tambahan dijadwalkan, satu pada tanggal 3 Agustus dan satu lagi pada bulan September. 11.
Beberapa tim membuat peta jalan rilis, seperti yang dijelaskan nanti di bagian ini, untuk setiap rilis perangkat
lunak. Keseluruhan proyek masih dijadwalkan selesai pada 1 November.
Selain mencantumkan semua persyaratan awal proyek dalam pernyataan ruang lingkup, seperti
yang ditunjukkan pada bagian 6.0 kasus bisnis (lihat Tabel 3-2), Joe, pemilik produk, membuat product
backlog untuk memprioritaskan fungsi terpenting dari proyek. perangkat lunak intranet baru dalam hal
menambah nilai bagi bisnis. Joe membuat product backlog setelah menganalisis hasil survei dan mendiskusikan
opsi dengan beberapa orang. Dia menyertakan item terpisah untuk template dan alat yang paling penting, alih-
alih mengelompokkannya dalam satu item, dan meminta orang yang ditunjuk dari kumpulan konsultan perusahaan
mereka untuk menghubungi jika ada pertanyaan tentang setiap template atau alat juga. Perhatikan bahwa
pendekatan ini menggabungkan beberapa item dalam pernyataan cakupan yang ditunjukkan pada kasus pertama
untuk fokus pada apa yang akan memberikan nilai tambah terbesar. Memiliki orang yang ditunjuk akan berguna
sebelum tim mengembangkan fitur Tanya Pakar yang lebih kompleks. Setelah meninjau produk
Gambar 3-6 Bagan Gantt dasar proyek situs Intranet menggunakan pendekatan Scrum
backlog, tim Scrum akan melakukan perencanaan dan memperbarui sprint backlog berdasarkan item yang
dapat diselesaikan tim pada sprint pertama. Tabel 3-19 memberikan contoh product backlog dan sprint backlog
untuk sprint pertama. Tim kemudian akan mengadakan pertemuan Scrum harian pertamanya untuk
merencanakan hari itu.
Tim Scrum memecah item-item dalam sprint backlog menjadi item-item pekerjaan yang lebih spesifik,
seringkali dalam bentuk cerita pengguna, cerita teknis, dan tugas-tugas terkait. Cerita pengguna adalah
deskripsi singkat yang ditulis oleh pelanggan tentang apa yang mereka perlukan agar sistem dapat lakukan
untuk mereka. Deskripsi ini harus terdiri dari tiga kalimat. Mereka memberikan dasar perkiraan waktu untuk
pertemuan perencanaan sprint. Cerita pengguna harus dapat diuji dan cukup kecil sehingga pemrogram dapat
menyelesaikan dan menguji unit kode mereka tepat waktu
tata krama.
Pengembang membagi cerita pengguna menjadi cerita teknis. Kemudian mereka menggunakan cerita
teknis untuk menerjemahkan kebutuhan pengguna ke dalam spesifikasi teknis yang diperlukan untuk
menciptakan fungsionalitas pengguna yang ditentukan. Cerita teknis dapat berisi satu atau lebih tugas
teknis yang digunakan pengembang untuk memetakan kemajuan di papan sprint saat pekerjaan
dilakukan sepanjang sprint. Sebuah tugas harus dapat diselesaikan dalam satu hari. Satu item dalam sprint
backlog mungkin didokumentasikan atau tidak dalam satu cerita pengguna, satu cerita teknis, dan satu tugas,
berdasarkan kompleksitasnya. Mungkin terdapat hubungan satu-ke-satu atau hubungan banyak-ke-satu jika
itemnya sangat kompleks.
Misalnya, seseorang di bidang keuangan perusahaan dapat menulis cerita pengguna yang disebut
“Kemampuan membebankan biaya kepada pelanggan untuk beberapa produk dan layanan intranet.” Isinya
mungkin sebagai berikut: “Sebagai manajer keuangan, saya ingin situs kami menggunakan Perusahaan B untuk
memproses pembayaran sehingga kami menghemat uang untuk biaya transaksi dan layanan
pelanggan.” Kisah pengguna dipecah menjadi kisah teknis terperinci dan kemudian menjadi tugas, mirip dengan tugas di WBS.
136 bagian 3
Tabel 3-19 Product dan Sprint Backlog
Tunggakan Produk Sprint Backlog
1. Templat cerita pengguna, contoh, dan orang 1. Templat cerita pengguna, contoh, dan orang
yang ditunjuk yang ditunjuk
2. Templat WBS, sampel, dan titik 2. Templat WBS, sampel, dan titik
orang orang
3. Templat jadwal proyek, sampel, dan orang yang 3. Templat jadwal proyek, sampel, dan orang yang
ditunjuk ditunjuk
4. Kemampuan membebankan biaya kepada pelanggan 4. Kemampuan membebankan biaya kepada pelanggan
untuk beberapa produk dan layanan intranet untuk beberapa produk dan layanan intranet
5. Kemampuan untuk mengumpulkan saran pengguna 5. Kemampuan untuk mengumpulkan saran pengguna
6. Templat kasus bisnis, sampel, dan orang
yang ditunjuk
7. Tanyakan pada fitur Expert
8. Strategi pengelolaan pemangku kepentingan
templat, sampel, dan orang yang ditunjuk
9. Templat daftar risiko, sampel, dan orang yang
ditunjuk
10. Dll.
Beberapa organisasi menggunakan peta jalan rilis untuk memaparkan semua pekerjaan untuk
keseluruhan rilis, yang dapat mencakup lebih dari satu sprint. Peta jalan ini biasanya direpresentasikan sebagai
bagan yang terdiri dari beberapa kolom. Peta jalan rilis memberikan gambaran yang jelas tentang cerita (ruang
lingkup) apa yang akan dimuat dalam setiap sprint. Alat ini memungkinkan tim Scrum dengan mudah meninjau
dan memperbarui perkiraan kecepatan versus aktual. Peta jalan rilis harus berasal dari data dalam Sistem
Informasi Manajemen Proyek (PMIS) atau sistem manajemen tangkas terkait, seperti Microsoft Team Foundation
Server, Rally, VersionOne, atau JIRA.
Eksekusi
Seperti yang telah dibahas sebelumnya dalam bab ini, sebagian besar waktu dan uang harus dihabiskan
untuk pelaksanaan, ketika rencana diimplementasikan untuk menciptakan produk yang diinginkan. Tim akan
menyelesaikan tugas setiap hari, seperti yang terjadi pada versi prediktif kasus ini. Namun dengan menggunakan
pendekatan tangkas, tim akan menghasilkan beberapa iterasi dari produk yang berpotensi dapat dikirim.
Misalnya, pada akhir sprint pertama, JWD Consulting akan memiliki beberapa fungsi yang tersedia di situs
intranet manajemen proyek barunya. Pengguna akan dapat mengakses templat, sampel, dan orang yang
ditunjuk untuk cerita pengguna, WBS, dan jadwal proyek, seperti yang tercantum dalam sprint backlog
pertama. Pengguna juga dapat memberikan saran mengenai fungsionalitas yang ingin mereka lihat di situs
intranet saat situs tersebut sedang dikembangkan. Iterasi pertama perangkat lunak ini juga akan memberikan
kemampuan untuk membebankan biaya kepada pelanggan untuk beberapa produk dan layanan. Dengan
menggunakan metode Scrum, bisnis dapat memperoleh manfaat dari fitur-fitur baru ini beberapa bulan lebih
awal dibandingkan dengan menggunakan pendekatan prediktif yang dijelaskan pada kasus pertama.
Karena Erica dan beberapa tim proyek tidak berpengalaman dalam menggunakan Scrum, mereka harus
mengatasi beberapa tantangan. Misalnya, komunikasi sangat berbeda karena tim proyek bertemu setiap
pagi, baik secara fisik maupun virtual. Akan ada juga masalah komunikasi dengan pengguna situs intranet
baru, yang mungkin akan bingung jika mendapatkan tiga iterasi produk, bukan hanya satu. Lihat Bab 10,
Manajemen Komunikasi Proyek, dan Bab 13, Manajemen Pemangku Kepentingan Proyek, untuk informasi
tambahan.
Pemantauan dan Pengendalian

Dua alat utama untuk memantau dan mengendalikan kerangka Scrum adalah Scrum harian dan
tinjauan sprint. Scrum Harian diadakan setiap pagi untuk merencanakan dan mengkomunikasikan
pekerjaan pada hari itu dan mendiskusikan risiko, masalah, atau hambatan apa pun. Scrum harian mencakup
diskusi singkat tentang masalah dan hambatan apa pun yang dihadapi tim. ScrumMaster akan bekerja dengan
pemangku kepentingan yang tepat untuk mengatasi masalah ini sebagai bagian dari pemantauan dan
pengendalian. Menghilangkan hambatan agar tim dapat bekerja dengan baik adalah salah satu tugas utama
ScrumMaster. ScrumMaster mendokumentasikan permasalahan dan penghambat, serupa dengan daftar
risiko yang diprioritaskan.
Kemajuan pekerjaan dalam sebuah sprint dapat direpresentasikan pada papan sprint yang dikelola oleh
ScrumMaster. Papan sprint berisi kartu yang mewakili setiap tugas yang harus dikerjakan selama sprint. Setiap
kartu tugas berisi nomor kontrol, nama tugas, perkiraan waktu penyelesaian, peringkat atau nomor prioritas,
dan anggota tim yang ditugaskan. Saat tugas dibuka, dikerjakan, dan ditutup, kartu tugas tersebut
dipindahkan secara fisik ke bagian yang sesuai di papan tulis. Bagian ini meliputi Belum Dimulai, Sedang
Berlangsung, Siap Diuji, Diuji, dan Ditutup.
Pengembang memperbarui status tugas di bagian Belum Dimulai, Sedang Berlangsung, dan Siap Diuji.
Penguji memperbarui status tugas di bagian Diuji. Pemilik produk bertanggung jawab untuk meninjau
fungsionalitas, mengonfirmasi bahwa fungsi berfungsi sesuai harapan, dan mengubah status tugas
menjadi Tertutup.
Bagan burndown adalah artefak penting yang digunakan untuk menampilkan kemajuan secara grafis
pada setiap sprint. Bagan burndown pada Gambar 3-7 menunjukkan kemajuan selama sprint pertama untuk
proyek intranet JWD Consulting, yang dijadwalkan berlangsung selama empat minggu dan menghasilkan lima
item atau cerita pengguna yang tercantum dalam sprint backlog. Ingatlah bahwa selama perencanaan, setiap
cerita pengguna dipecah menjadi tugas-tugas tertentu, dan tim memperkirakan berapa lama waktu yang
dibutuhkan untuk menyelesaikan setiap tugas untuk setiap cerita pengguna. Selama rapat Scrum harian,
pekerjaan yang diklaim oleh anggota tim harus sesuai dalam satu hari. Setiap hari, tim harus memperkirakan
lagi jumlah jam atau poin yang tersisa untuk setiap tugas. Beberapa tugas mungkin ditambahkan dan
beberapa mungkin dihilangkan karena cakupannya menjadi lebih jelas. Tidak peduli berapa jam yang
telah dihabiskan; yang penting adalah berapa jam kerja yang tersisa untuk menyelesaikan cerita pengguna untuk sprint tersebut.
Bagan burndown memplot jumlah perkiraan jam atau poin yang tersisa setiap hari.
Ini juga menunjukkan garis burndown yang diidealkan, seolah-olah tim menyelesaikan jumlah pekerjaan
yang sama setiap hari, atau 10 tugas setiap hari dalam contoh ini. Bagan tersebut kemudian dengan jelas
menunjukkan apakah tim bekerja dengan baik dalam sprint tersebut atau ada potensi masalah.
Bagan burndown membantu tim memahami apakah cerita pengguna mungkin tidak diselesaikan dalam sprint
tersebut. Bagan tersebut memberikan indikator bahwa berita-berita tersebut berisiko dan harus dihapus. Jika
kemajuan lebih baik dari yang diperkirakan, grafik burndown dapat menunjukkan bahwa cerita harus
ditambahkan ke dalam sprint.
138 bagian 3
Bagan Pembakaran Sprint 1

200
150
Pekerjaan
100
50
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
hari
Tersisa Kecepatan Ideal
Gambar 3-7 Grafik Burndown
Di akhir setiap sprint, ScrumMaster—Erica dalam contoh ini—memimpin sprint

pertemuan peninjauan demonstrasi. Tim mendemonstrasikan kepada pemilik produk apa yang telah
diselesaikannya selama sprint. Dalam hal ini, Joe akan meninjau lima fitur yang dibuat selama sprint pertama.
Setelah tinjauan demonstrasi sprint, dia akan memperbarui product backlog berdasarkan informasi terkini dan
kebutuhan bisnis, dan siklus sprint berikutnya akan dimulai.
Penutupan
Setelah tinjauan sprint, ScrumMaster memimpin sprint retrospektif. Dalam pertemuan singkat ini (sekitar
setengah jam), tim merefleksikan apa yang terjadi selama sprint. ScrumMaster biasanya meminta masukan
dari anggota tim melalui email terlebih dahulu dan menyusun hasilnya sebelum rapat. Hal ini menghemat
waktu dan memfokuskan diskusi pada hal-hal yang paling penting. Retrospektif mirip dengan laporan
pembelajaran, namun berfokus pada periode waktu yang lebih singkat. Retrospektif sprint dimaksudkan untuk
menjawab dua pertanyaan mendasar:
•Apa yang berjalan baik pada sprint terakhir yang harus terus kita lakukan?
•Apa yang bisa kita lakukan secara berbeda untuk meningkatkan produk atau proses?
Pertemuan sprint retrospektif biasanya dipimpin oleh ScrumMaster, yang mendokumentasikan daftar
tindakan untuk implementasi. Item tersebut dapat ditambahkan ke product backlog jika pemilik produk
menyetujuinya. Misalnya, setelah sprint pertama untuk proyek situs intranet manajemen proyek JWD, tim
mungkin menyarankan agar situs tersebut diaktifkan untuk seluler. Persyaratan baru ini dapat ditambahkan ke
product backlog dan dipilih sebagai item untuk sprint berikutnya. Ingatlah bahwa pendekatan tangkas
menyambut baik persyaratan baru selama pendekatan tersebut berfokus pada nilai bisnis.
Seperti yang ditunjukkan dalam dua kasus pada proyek yang sama, pendekatan tangkas dan
pendekatan prediktif memiliki persamaan dan perbedaan. Jika dilakukan dengan baik, metode agile dapat
menghasilkan beberapa rilis perangkat lunak yang bermanfaat. Pendekatan ini memungkinkan organisasi untuk
bekerja sama dengan cepat untuk mengatasi perubahan kebutuhan bisnis.
Templat berdasarkan Grup Proses
Seperti yang Anda lihat, tim proyek menyiapkan banyak dokumen sepanjang masa proyek.
Banyak orang menggunakan templat untuk menerapkan format standar dalam menyiapkan dokumen tersebut.
Tabel 3-20 mencantumkan beberapa templat yang digunakan untuk menyiapkan dokumen yang diperlihatkan
dalam bab ini dan bab-bab selanjutnya. Tabel ini mencantumkan nama templat, nomor bab, grup proses di
mana Anda biasanya menggunakan templat tersebut, perangkat lunak aplikasi yang digunakan untuk
membuatnya, dan nama file untuk templat tersebut. Anda dapat mengunduh templat ini dan templat tambahan
dalam satu file terkompresi dari situs web Pendamping untuk teks ini atau dari situs web penulis di
www.kathyschwalbe.com. Jangan ragu untuk memodifikasi template untuk memenuhi kebutuhan Anda.
Saran untuk Pr Muda essi
Sebagian besar organisasi memiliki templat untuk berbagai jenis dokumen. Pastikan untuk menanyakan
templat kepada atasan, rekan kerja, dan kolega Anda yang lain sebelum mencoba menemukan kembali
rodanya. Jika Anda tidak menyukai templat yang Anda temukan, lihat sumber lain. Jika Anda dapat
memperbaikinya, bagikan pekerjaan Anda dengan orang lain. Tidak ada yang mau membuang waktu untuk membuat dokumen proyek.
Jika Anda bekerja untuk sponsor luar, pastikan untuk meminta templat mereka. Jika mereka tidak
memilikinya atau menurut Anda milik Anda lebih baik, bersedialah untuk berbagi dengan mereka juga.
Templat memang bagus, tetapi templat lengkap dengan informasi yang bagus bahkan lebih
berguna. Semoga contoh-contoh dalam bab ini dan seluruh teks akan membantu Anda dalam
membuat dokumen proyek yang baik. Saat Anda menemukan contoh bagus dari sumber lain, cobalah
menyimpannya untuk referensi di masa mendatang.
Tabel 3-20 Templat berdasarkan grup proses
Bab
Di mana Aplikasi
Grup Proses Nama Templat Digunakan Perangkat lunak Nama file
Kasus bisnis Inisiasi awal 3 Kata kasus bisnis.doc
Kasus bisnis Inisiasi awal 3, 4 Unggul kasus bisnis

Keuangan finansial.xls
Pemangku kepentingan Memulai 3, 13 Kata daftar pemangku kepentingan.doc

Daftar
(lanjutan)
140 bagian 3
Tabel 3-20 Templat berdasarkan grup proses (lanjutan)
Bab
Di mana Aplikasi
Pemangku kepentingan Memulai 3, 13 Kata strategi manajemen

Pengelolaan pemangku kepentingan.doc
Strategi
Pertemuan Pembuka Memulai 3 Kata agenda pertemuan

Jadwal acara perdana.doc
Periode Pembayaran Kembali Memulai 4 Unggul grafik periode

Bagan pengembalian.xls
Tertimbang Memulai 4, 12 Unggul model penilaian

Model Penilaian tertimbang.xls
Inisiasi Piagam Proyek 3, 4, 5 Kata piagam.doc
Memulai Log Asumsi 3, 4 Unggul log asumsi.xlsx
Piagam Tim Perencanaan 3, 9 Kata piagam tim.doc
Persyaratan Perencanaan 5 Kata persyaratan

Ketertelusuran ketertelusuran
Matriks matriks.doc
Cakupan Perencanaan 3, 4, 5 Kata pernyataan ruang lingkup.doc

Penyataan
Negara Kontrak Perencanaan 12 Kata pernyataan kontrak

ment Pekerjaan pekerjaan.doc
Meminta Perencanaan 12 Kata proposal permintaan.

Usul dokter
Rencana Manajemen Perencanaan 4 Kata rencana manajemen

Proyek proyek.doc
Struktur rincian Perencanaan 3, 5, 6 Kata wbs.doc

kerja
(WBS)
Kamus WBS Perencanaan 5 Deskripsi kamus

Pintu masuk WBS.doc
Estimasi biaya Perencanaan 7 Unggul perkiraan biaya.xls
Nilai yang Diperoleh Pemantauan dan 7 Unggul grafik nilai yang diperoleh.xls
Bagan Mengontrol
(lanjutan)
Bab
Di mana Aplikasi
Pembakaran Pemantauan dan 3, 7 Unggul burndownchart.xls

Bagan Mengontrol
Pelaksana Metrik Kualitas 8 Kata metrik kualitas.doc
Bagan Pareto Pemantauan dan 8 Unggul bagan pareto.xls

Mengontrol
Bagan Organisasi Perencanaan, 9 Kekuatan bagan organisasi proyek.ppt

Proyek Eksekusi Titik
Penugasan Perencanaan, 9 Unggul Grafik RACI.xls

Tanggung Jawab Eksekusi
Matriks
Sumber Perencanaan, 9 Unggul histogram sumber daya.xls

Histogram Eksekusi
Komunikasi Perencanaan 10 Kata komunikasi

Rencana rencana manajemen.doc
Pengelolaan
Pelajaran yang didapat Eksekusi 4 Unggul register pelajaran

Daftar yang dipelajari.xlsx
Pelaksana Laporan Milestone 3, 6 Kata laporan pencapaian.doc
Perubahan Permintaan Perencanaan, 4 Kata ubah permintaan.doc

Membentuk Pemantauan dan
Mengontrol
Pertunjukan Pemantauan dan 3, 4 Kata laporan kinerja.doc

Laporan Mengontrol
Kemungkinan/ Perencanaan, 11 Kekuatan matriks dampak

Matriks Dampak Mengeksekusi, Titik probabilitas.ppt
Pemantauan dan
Mengontrol
Daftar Risiko Perencanaan, 11 Unggul daftar risiko.xls

Pemantauan dan
Mengontrol
Analisis Titik Perencanaan 11 Unggul titik impas.xls

Impas/Sensitivitas
(lanjutan)
142 bagian 3
Bab
Di mana Aplikasi
Kontrak Perencanaan 12 Kata kontrak.doc
Meminta Perencanaan 12 Kata permintaan

Usul proposal .doc
Log Masalah Pemantauan dan 13 Kata log masalah.doc

Mengontrol
Pelanggan Penutupan 10 Kata formulir penerimaan
Penerimaan pelanggan.doc
Membentuk
Pelajaran Penutupan 3, 10 Kata laporan

Laporan yang Dipelajari pembelajaran.doc
Proyek Akhir Penutupan 3, 10 Kata daftar isi laporan

Tabel Laporan tugas akhir.doc
Isi
Kelompok proses manajemen proyek—memulai, merencanakan, melaksanakan, memantau

dan pengendalian, dan penutupan—memberikan kerangka kerja yang berguna untuk memahami
manajemen proyek. Mereka berlaku untuk sebagian besar proyek, baik TI maupun non-TI, dan bersama
dengan bidang pengetahuan manajemen proyek, membantu manajer proyek melihat gambaran besar
pengelolaan proyek di organisasi mereka.
C ase Bungkus p - Atas
Erica Bell dan timnya menyelesaikan proyek situs intranet manajemen proyek pada tanggal
4 November, sesuai rencana dalam piagam proyek mereka. Mereka melebihi anggaran, namun
Joe telah menyetujui permintaan Erica untuk dana tambahan, terutama untuk pembelian perangkat
lunak eksternal dan penyesuaian. Seperti proyek lainnya, mereka memiliki beberapa
tantangan, namun mereka bekerja sama sebagai sebuah tim dan menggunakan manajemen proyek
yang baik untuk memenuhi kebutuhan sponsor dan pengguna. Mereka menerima tanggapan
awal yang positif dari konsultan internal dan beberapa klien mereka di situs intranet baru. Orang-
orang meminta templat, contoh, dan saran ahli bahkan sebelum sistemnya siap. (Jika mereka
menggunakan pendekatan agile, fitur-fitur ini dapat dikirimkan lebih awal.) Sekitar setahun
setelah proyek selesai, Erica bekerja dengan anggota departemen Keuangan untuk meninjau
manfaat sistem baru ini. Meskipun Kantor Manajemen Proyek kehilangan salah satu stafnya, mereka
tidak meminta penggantinya karena sistem baru membantu mengurangi beban kerjanya. Hal ini
menghemat perusahaan sekitar $70.000 per tahun untuk gaji dan tunjangan posisi staf tersebut.
Tim juga memiliki data yang menunjukkan bahwa perusahaan menghemat lebih dari $180.000
pada kontrak dengan klien karena sistem baru ini, dibandingkan dengan proyeksi mereka sebesar
$160.000. Perusahaan mencapai titik impas dengan fitur Tanya Ahli pada tahun pertama, dan
Erica memperkirakan bahwa sistem tersebut memberikan keuntungan tambahan sebesar
$30.000 pada tahun pertama dengan menghasilkan bisnis baru, dibandingkan dengan $40.000 yang diproyeksikan tim.
Namun, penghematan dari gaji posisi staf PMO dan penghematan ekstra pada kontrak lebih dari
cukup untuk menutupi perbedaan sebesar $10.000. Joe bangga dengan tim proyek dan sistem
yang mereka hasilkan untuk membantu menjadikan JWD Consulting sebagai organisasi kelas dunia.
144 bagian 3
Ringkasan Bab
Manajemen proyek melibatkan sejumlah proses yang saling terkait. Lima kelompok proses manajemen proyek
adalah memulai, merencanakan, melaksanakan, memantau dan mengendalikan, dan menutup. Proses-proses ini
terjadi pada tingkat intensitas yang berbeda-beda di setiap fase proyek, dan hasil tertentu dihasilkan sebagai hasil
dari setiap proses. Biasanya proses pelaksanaan memerlukan sumber daya dan waktu paling banyak, diikuti
dengan proses perencanaan. Menghabiskan waktu yang cukup dalam perencanaan akan membuahkan hasil
dalam pelaksanaannya.
Memetakan aktivitas utama setiap kelompok proses manajemen proyek ke dalam 10 proyek
bidang pengetahuan manajemen memberikan gambaran besar tentang aktivitas apa saja yang terlibat dalam
manajemen proyek.
Penting untuk menyesuaikan metodologi manajemen proyek untuk memenuhi kebutuhan khusus
organisasi. Beberapa organisasi mengembangkan metodologi manajemen proyek TI mereka sendiri, sering kali
menggunakan standar dalam Panduan PMBOK® sebagai landasan. Metode populer seperti PRINCE2,
Agile, RUP, dan Six Sigma mencakup proses manajemen proyek.
Studi kasus JWD Consulting menunjukkan bagaimana sebuah organisasi mengelola proyek TI dari awal hingga
akhir. Studi kasus memberikan contoh keluaran yang dihasilkan untuk memulai, merencanakan, melaksanakan,
memantau dan mengendalikan, dan menutup:
•Kasus bisnis
•Daftar pemangku kepentingan
•Strategi pengelolaan pemangku kepentingan
•Piagam proyek
•
Agenda pertemuan pembuka
• Piagam tim
•Struktur rincian kerja
•Grafik Gantt
• Daftar risiko yang
diprioritaskan •Laporan
pencapaian •Laporan
kemajuan •Laporan pembelajaran

•
Laporan proyek akhir
Versi kedua dari studi kasus yang sama menggambarkan cara menggunakan Scrum, perusahaan tangkas terkemuka
metode, untuk mengelola proyek. Daripada merilis perangkat lunak intranet baru hanya sekali menjelang akhir
proyek, tim dapat merilis tiga iterasi perangkat lunak tersebut. Versi studi kasus ini memperkenalkan beberapa
alat baru, termasuk product backlog, sprint backlog, dan grafik burndown. Bab-bab selanjutnya memberikan
informasi rinci untuk membuat dokumen ini dan dokumen manajemen proyek lainnya serta menggunakan beberapa
alat dan teknik yang dijelaskan dalam kedua versi studi kasus ini.
Pertanyaan Diskusi
1. Jelaskan secara singkat apa yang terjadi di masing-masing dari lima kelompok proses manajemen proyek
(memulai, merencanakan, melaksanakan, memantau dan mengendalikan, dan menutup). Jenis kegiatan
apa yang terjadi sebelum memulai suatu proyek?
2.Kira-kira berapa banyak waktu yang dihabiskan oleh manajer proyek yang baik pada setiap kelompok proses, dan
Mengapa?
3.Mengapa organisasi perlu menyesuaikan konsep manajemen proyek, seperti yang terdapat dalam Panduan
PMBOK®, untuk membuat metodologi mereka sendiri?
4. Apa saja keluaran utama dari masing-masing kelompok proses?
5. Apa saja tantangan umum yang dihadapi tim proyek dalam lima kelompok proses? Anda dapat menyusun diskusi
Anda berdasarkan proyek yang diuraikan dalam salah satu kotak fitur dalam bab ini (misalnya, fitur Apa yang
Benar? atau Apa yang Salah?). Anda juga dapat menyusun diskusi Anda pada salah satu Penghargaan
Proyek Terbaik Tahun Ini dari PMI. pemenang atau kegagalan proyek terkenal seperti sistem penanganan
bagasi Bandara Internasional Denver.
6.Apa perbedaan utama antara kedua versi studi kasus JWD Consulting?
Kapan sebaiknya Anda menggunakan pendekatan yang lebih preskriptif atau tangkas? Menurut Anda, apakah
pengguna situs intranet JWD Consulting lebih memilih satu rilis perangkat lunak atau beberapa rilis
tambahan? Apa saja pro dan kontra dari masing-masing pendekatan?
Kuis cepat
1.A ____________ adalah serangkaian tindakan yang diarahkan pada hasil tertentu.
a.tujuan
b.proses
c.rencana
d.proyek
2. ____________ proses mencakup koordinasi orang dan sumber daya lainnya untuk melaksanakan rencana
proyek dan menciptakan produk, layanan, atau hasil proyek atau fase. a.Memulai b.Perencanaan
c.Pelaksanaan
d.Monitoring
dan pengendalian
e.Penutupan
3. Kelompok proses manakah yang biasanya memerlukan sumber daya dan waktu paling banyak?
a.Memulai
b.Perencanaan
c.Pelaksanaan
d.Monitoring dan pengendalian
e.Penutupan
146 bagian 3
4. Metodologi apa yang dikembangkan di Inggris, mendefinisikan 45 subproses terpisah, dan

mengaturnya menjadi delapan kelompok proses? a.Enam Sigma
b.RUP
c.PMBOK® Panduan
d.PANGERAN2
5. Manakah dari keluaran berikut yang sering diselesaikan sebelum memulai suatu proyek?
a.Daftar pemangku kepentingan

b.Kasus bisnis
c.Piagam proyek
d.Pertemuan pembuka
6.Struktur rincian pekerjaan, jadwal proyek, dan perkiraan biaya merupakan keluaran dari
____________ proses.
a.memulai
b.perencanaan
c.melaksanakan
d.pemantauan dan pengendalian
e.penutupan
7. Inisiasi melibatkan pengembangan piagam proyek, yang merupakan bagian dari proyek ____________
bidang pengetahuan manajemen.
a.integrasi b.ruang
lingkup
c.komunikasi
d.risiko
8. ____________ melibatkan pengukuran kemajuan menuju tujuan proyek dan mengambil tindakan perbaikan
tindakan.
a.Memulai
b.Perencanaan
c.Pelaksanaan
d.Monitoring dan pengendalian
e.Penutupan
9.Manakah dari berikut ini yang bukan merupakan alasan umum tim proyek menggunakan prediktif
pendekatan versus pendekatan tangkas dalam mengelola proyek?
a.Proyek memiliki persyaratan awal yang tidak jelas. b.Tim
proyek tidak berpengalaman dan tersebar. c.Risiko besar yang
terlibat. d.Tanggal penyelesaian
cukup kaku.
10.Banyak orang ____________ memiliki format standar untuk mempersiapkan berbagai proyek
menggunakan dokumen
manajemen. a.metodologi
b.templat
c.perangkat lunak manajemen proyek

d.standar
Jawaban Kuis Cepat
1.b; 2.c; 3.c; 4.d; 5.b; 6.b; 7.sebuah; 8.d; 9.a; 10.b
Latihan
1.Pelajari grafik WBS dan Gantt yang ditunjukkan pada Gambar 3-3 dan 3-4. Masukkan WBS ke dalamnya
Project 2016 atau perangkat lunak manajemen proyek lainnya, membuat indentasi tugas seperti yang ditunjukkan
untuk membuat hierarki WBS. Jangan masukkan durasi atau ketergantungan. Cetak bagan Gantt yang dihasilkan.
Lihat bagian manajemen cakupan pada Lampiran A, tersedia di situs web Pendamping untuk teks ini, untuk bantuan
menggunakan Project 2016.
2.Meneliti metode manajemen proyek, seperti PRINCE2, Agile, RUP, atau Six Sigma,
dan bagaimana organisasi menggunakannya, dengan mengutip setidaknya dua referensi. Menurut Anda mengapa
organisasi menghabiskan waktu dan uang untuk menyesuaikan metodologi dengan lingkungannya? Tulis ringkasan
temuan Anda dan pendapat Anda tentang topik tersebut.
3.Bacalah “Studi Kasus ResNet,” yang tersedia dari situs web Companion untuk teks ini di Bab 3. Studi kasus nyata
tentang sistem reservasi Northwest Airlines ini menggambarkan penerapan lain dari kelompok proses manajemen
proyek. Tulislah makalah yang merangkum keluaran utama yang dihasilkan selama setiap kelompok proses
proyek dalam kasus ini.
Sertakan juga pendapat Anda tentang apakah Peeter Kivestu adalah manajer proyek yang efektif. Jika Anda mau,
carilah proyek lain yang terdokumentasi dengan baik dan rangkumlah proyek tersebut.
4.Tinjau contoh dokumen yang disediakan untuk JWD Consulting untuk menjawab pertanyaan-pertanyaan
berikut. Apa kriteria keberhasilan proyek ini? Berapa perkiraan ROI siklus hidup yang didiskon? Jelaskan
tiga hasil utama terkait produk. Apa saja tiga risiko teratas? Apakah proyek memenuhi sasaran ruang lingkup,
waktu, dan biaya? Kapan produk yang dapat dikirim diselesaikan dengan menggunakan pendekatan prediktif dan
pendekatan tangkas?
5.Baca artikel atau tonton video tentang penerima penghargaan Project of the Year dari PMI. Cari informasi online dari situs
web PMI. Tulis makalah satu halaman yang merangkum proyek pemenang, dengan fokus pada bagaimana manajer
proyek dan tim menggunakan praktik manajemen proyek yang baik.
6.Tinjau product backlog, sprint backlog, dan grafik burndown yang disediakan dalam bab ini.
Baca artikel atau tonton video tentang penggunaan metode Scrum yang menyebutkan artefak ini.
Tulis makalah singkat yang menjelaskan lebih detail tentang cara membuat artefak tersebut; mengutip setidaknya
dua referensi.
148 bagian 3
7.Anda adalah konsultan proyek untuk Perusahaan ACME dan membantu mengembangkan metode tangkas
menggunakan Scrum. Perusahaan selalu menggunakan metode manajemen proyek prediktif untuk
pengembangan perangkat lunak, namun manajer perusahaan telah mendengar bahwa Agile dapat memberikan
keuntungan yang signifikan jika diterapkan dengan benar. Siapkan proposal yang menyarankan pendekatan
pelatihan, dokumentasi, dukungan eksekutif, dan manajemen tim apa yang diperlukan untuk memulai uji coba
Agile. Berikan pembenaran atas rekomendasi Anda.
8.Tinjau setidaknya dua survei tentang penggunaan metodologi agile, seperti survei tahunan tentang status
agile oleh VersionOne. Temukan juga analisis kritis terhadap survei ini karena survei tersebut disponsori
oleh perusahaan yang menjual produk atau survei tangkas. Ringkaslah temuan Anda dalam makalah singkat.
9.Unduh file templat yang digunakan dalam teks ini dari situs web Pendamping. Tinjau beberapa file, dan lihat contoh
penggunaannya dalam teks ini. Cari juga di Internet untuk file templat lainnya. Tulis makalah singkat untuk
merangkum pendapat Anda tentang penggunaan templat dan bagaimana menurut Anda templat tersebut dapat
membantu manajer proyek dan timnya. Diskusikan juga potensi masalah dalam penggunaan templat.
Istilah-Istilah Utama
metode tangkas kelompok proses manajemen proyek

artefak Proyek DI Lingkungan Terkendali
grafik pembakaran (PANGERAN2)
menutup proses Kerangka Proses Terpadu Rasional (RUP).

ScrumMaster
Scrum harian
melaksanakan proses Tim scrum atau tim pengembangan
memulai proses Metodologi Six Sigma berlari
pertemuan awal cepat
metodologi sprint backlog
pemantauan dan pengendalian proses proses sesi perencanaan sprint
perencanaan retrospektif sprint
proses ulasan sprint
pemilik produk daftar pemangku kepentingan
standar
simpanan produk
cerita pengguna
Catatan Akhir
1 Andy Crowe, Manajer Proyek Alpha: Apa yang 2 persen teratas ketahui namun tidak diketahui orang lain
(Atlanta, GA: Velocieach Press, 2006).

2 Phillip A. Pell, Komentar diposting di Elaine Varron, “Tidak Ada Perbaikan TI yang Mudah untuk
IRS” [sebelumnya “Untuk IRS, Tidak Ada Perbaikan EZ”], CIO.com (1 April 2004).
3 Meredith Somers, “'Rasa urgensi' seiring bertambahnya usia sistem TI warisan IRS,”
Radio Berita Federal (5 Oktober 2017).
4 PCI Group, “Laporan Praktik Terbaik PM” (Oktober 2001).
5 Brian Jacks, “Lord of the Rings: The Two Towers Extended Edition (Baris Baru),” Under ground
Online, UGO.com (diakses 4 Agustus 2004).
6
Institut Manajemen Proyek, "Pulse of the Profession®: Sukses di Saat-saat yang Mengganggu"
(2018).
7 Version One Inc., “Survei State of Agile™ Tahunan ke-11,” VersionOne.com (2017).
8 Bill Cottrell, “Standar, Kepatuhan, dan Proses Terpadu Rasional, Bagian I: Mengintegrasikan RUP
dan PMBOK®,” karya Pengembang IBM (10 Mei 2004).
9
Institut Manajemen Proyek, “Denyut Profesi®: Biaya Tinggi di Rendah
Kinerja” (2014).
10 Adam Mazmanian, “Google Bergabung dengan Tawaran PwC Berbasis Vista untuk Catatan Kesehatan Militer,” FWC:
Bisnis Teknologi Federal (14 Januari 2015).
11
Libby Ellis, “Inspirasi Perkotaan,” PM Network (Januari 2006), hal. 30.
12
PMI, “Pemenang Penghargaan Proyek PMI Tahun Ini 2013: Proyek Desalinasi Adelaide,”
31 Oktober 2013, www.youtube.com/watch?v=SIPleb0y0jg.
13
PMI, “Project of the Year Award,” www.pmi.org/about/awards/winners/past-award/project of-the-year
(diakses 27 Februari 2018).
14
George Santayana, Kehidupan Nalar: Nalar dalam Akal Sehat (New York: Scribner's,
1905), hal. 284.

Buku Manajemen Proyek-110-174

Diunggah oleh

Informasi Dokumen

Judul Asli

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

Buku Manajemen Proyek-110-174

Diunggah oleh

Hak Cipta:

Format Tersedia

Machine Translated by Google

Setelah membaca bab ini, Anda akan dapat:

• Mengaitkan kelompok proses manajemen proyek dengan proyek

•Diskusikan bagaimana organisasi mengembangkan proyek teknologi informasi (TI).

• Meninjau studi kasus organisasi yang menerapkan proyek

beberapa templat untuk membuat dokumen untuk setiap kelompok proses

Grup Proses Manajemen Proyek

Grup Proses Manajemen Proyek 87

Kelompok proses tidak saling eksklusif. Misalnya, manajer proyek harus

Manajer Proyek Lainnya Manajer Proyek Alpha

Sumber: Andy Crowe

Grup Proses Manajemen Proyek 89

Apa yang salah?

Grup Proses Manajemen Proyek 91

Memetakan Grup Proses ke Area Pengetahuan

Grup Proses Manajemen Proyek

Pengetahuan Proyek Pengendalian

5. Manajemen Lingkup 5.1 Rencana Lingkup 5.5 Validasi

Proyek Manajemen Cakupan

6. Jadwal 6.1 Rencana Jadwal 6.6 Jadwal

Pengelolaan 6.2 Mendefinisikan Kegiatan

7. Manajemen Biaya 7.1 Biaya Rencana 7.4 Biaya

Proyek Pengelolaan Pengendalian

Grup Proses Manajemen Proyek

8. Manajemen 8.1 Rencana 8.2 Kelola 8.3 Pengendalian

Kualitas Manajemen Mutu Kualitas Kualitas

9. Manajemen 9.1 Merencanakan 9.3 Memperoleh 9.6 Pengendalian

Daya Proyek 9.2 Perkirakan Sumber 9.4

9.5 Kelola Tim

10. Manajemen 10.1 Rencana 10.2 Kelola 10.3

11. Manajemen Risiko 11.1 Rencana 11.6 11.7

Proyek Manajemen Risiko Menerapkan Memantau Resiko

11.2 Identifikasi Risiko Respons Risiko

12. Manajemen 12.1 Rencana Manajemen 12.2 Melakukan 12.3 Kontrol

13. Proyek 13.1 13.2 Rencana 13.3 Mengelola 13.4 Memantau

Pengelolaan Pemangku Kepentingan

Grup Proses Manajemen Proyek 93

Mengembangkan Metodologi Manajemen Proyek TI

1. Memulai sebuah proyek

6. Mengelola pengiriman produk

Grup Proses Manajemen Proyek 95

Apa yang Benar?

Studi Kasus 1: Manajemen Proyek JWD Consulting

Pra-Inisiasi dan Inisiasi Proyek

Grup Proses Manajemen Proyek 97

Tabel 3-2 Kasus bisnis JWD Consulting

1.0 Pendahuluan/Latar Belakang

2.0 Tujuan Bisnis

Sasaran strategis JWD Consulting mencakup pertumbuhan dan profitabilitas yang

Tabel 3-2 Kasus bisnis JWD Consulting (lanjutan)

3.0 Situasi Saat Ini dan Pernyataan Masalah/Peluang

4.0 Asumsi dan Kendala Kritis

5.0 Analisis Pilihan dan Rekomendasi

6.0 Persyaratan Proyek Awal

Grup Proses Manajemen Proyek 99

Tabel 3-2 Kasus bisnis JWD Consulting (lanjutan)

7.0 Perkiraan Anggaran dan Analisis Keuangan

Tabel 3-2 Kasus bisnis JWD Consulting (lanjutan)

Gambar A: Analisis Keuangan untuk Proyek Situs Intranet Manajemen Proyek

Asumsikan proyek selesai dalam waktu sekitar 6 bulan Tahun

Manfaat 0 200.000 200.000 200.000

Manfaat yang didiskon - biaya (140.000) 148.148 137.174 127.013

Grup Proses Manajemen Proyek 101