Daftar Isi:
- Mencegah Bencana Proyek
- Manajemen Lingkup Sangat Penting untuk Keberhasilan Proyek
- Mencegah Scope Creep
- Kapan Selasa Depan?
- Menyetujui Lingkup Proyek Anda
- Mendapatkan di Halaman yang Sama
- Menyetujui Scope
- Memperjelas Asumsi
- Langkah-langkah Manajemen Lingkup
- Pertanyaan Yang Mendefinisikan Sisa Proyek
- Inklusi dan Pengecualian
- Membuat Work Breakdown Structure (WBS)
- Membuat Rencana Proyek Lainnya
- Mengelola Ruang Lingkup Selama Proyek
- Analisis Nilai yang Diperoleh
- Mengelola Scope Creep
- Mengelola Sembilan Area
- Memberikan Apa yang Anda Janjikan
- Verifikasi dan Validasi
- Pengiriman
- Kesenangan Pelanggan
- Apa yang Menghentikan Proyek Anda?
Siapkan diri Anda untuk kesuksesan proyek dengan mendefinisikan tujuan secara jelas — ruang lingkup — di awal.
Gambar oleh David Mark dari Pixabay
Mencegah Bencana Proyek
Artikel ini adalah ikhtisar dari topik yang sangat besar, Manajemen Lingkup Proyek. Faktanya, seluruh buku telah ditulis tentang manajemen ruang lingkup. Tinjauan ini dapat mengarahkan studi Anda lebih lanjut tentang manajemen ruang lingkup, yang sangat penting untuk kesuksesan proyek.
Manajemen Lingkup Sangat Penting untuk Keberhasilan Proyek
Kebanyakan proyek gagal, dan karena berbagai alasan. Tetapi kegagalan proyek yang benar-benar menghancurkan adalah kegagalan manajemen lingkup. Lingkup adalah definisi maksud dan tujuan proyek. Jadi, jika itu didefinisikan dengan buruk, kita tidak mendapatkan apa-apa sama sekali (tujuan tidak tercapai), atau kita mendapatkan hasil yang tidak sesuai dengan keinginan kita, atau kita mendapatkan dua bagian yang tidak bekerja sama, karena setengah dari tim proyek punya satu ide, dan separuh lainnya punya ide lain. Kami mengirimkan bagian depan keledai dan bagian belakang kuda, dan akhirnya terlihat seperti bagian belakang kuda.
Mencegah Scope Creep
Bahkan jika produk dan tujuannya didefinisikan dengan baik di awal, pelanggan memiliki kebiasaan buruk untuk mendapatkan ide-ide baru dan mengharapkan lebih banyak lagi. Jika kita mengabaikan mereka, mereka akan mulai bermimpi, dan mengharapkan kita untuk mewujudkan impian mereka. Ketika kita memenuhi apa yang kita janjikan — jauh lebih sedikit dari apa yang mereka impikan — mereka tidak akan puas. Tidak masalah jika kita memberi mereka apa yang mereka minta. Orang menjadi kesal ketika mereka tidak mendapatkan apa yang mereka harapkan. Lebih buruk lagi, jika kami mendengarkan mereka, kami terus menambahkan fitur yang mereka minta. Tapi itu memakan waktu lebih lama dari jadwal awal, dan jauh lebih banyak uang daripada anggaran awal.
Akibatnya, kami tidak memiliki apa-apa untuk dikirimkan di akhir proyek. Pelanggan kehabisan waktu dan uang, dan kami tidak memiliki apa pun yang berguna untuk ditampilkan untuk semua pekerjaan kami. Kami menyebutnya monster scope creep, artinya, meskipun kami mendefinisikan scope di awal, semakin banyak fitur, semakin banyak lonceng dan peluit, merayap ke dalam scope, menambah rencana proyek hingga runtuh dari bobotnya sendiri.
Menurut Project Management Institute, 64% dari semua proyek gagal memberikan kepuasan pada jadwal dan anggaran aslinya. Dan penyebab terbesar dari kegagalan ini adalah definisi ruang lingkup yang buruk, atau jika lingkup didefinisikan dengan baik di awal, ruang lingkup merayap.
Kabar baiknya adalah jika kita mendefinisikan ruang lingkup dengan jelas dan mengelola ruang lingkup, kita sedang menuju kesuksesan!
Saya telah melatih lebih dari 4.000 manajer proyek dan memimpin lusinan proyek. Izinkan saya menunjukkan kepada Anda cara menentukan cakupan dan mengelola creep cakupan sebelum proyek Anda kewalahan!
Apakah permintaan untuk lonceng dan peluit ekstra membebani proyek Anda seperti semut di atas kubus gula? Baca terus untuk mempelajari cara mengelola scope creep.
stevendepolo Steven Depolo (CC BY) melalui Flickr
Kapan Selasa Depan?
Setiap kali saya mengajar kelas tentang definisi ruang lingkup dan kejelasan komunikasi, saya meminta angkat tangan untuk pertanyaan ini. Katakanlah saya mengajar pada hari Kamis. Saya bertanya, "Angkat tangan jika menurut Anda Selasa depan adalah 5 hari dari sekarang." Sekitar setengah dari orang di ruangan itu mengangkat tangan. Lalu saya bertanya, "Angkat tangan jika menurut Anda Selasa depan adalah 12 hari dari sekarang." Separuh orang lainnya di ruangan itu mengangkat tangan.
Ini menunjukkan bahwa bahasa Inggris biasa bukanlah bahasa yang tepat. Bagi sebagian orang, "Selasa depan" adalah yang akan datang lima hari lagi. Bagi yang lain, "Selasa depan" adalah setelah "Selasa ini", jadi masih dua belas hari lagi.
Ketika para siswa melihat bahwa, apapun cara mereka berpikir, separuh orang di ruangan itu berpikir secara berbeda, mereka mulai melihat nilai dari definisi tertulis yang jelas dan tepat. Definisi tersebut sangat membantu untuk menghilangkan kesalahpahaman yang merugikan, dan juga mencegah kesalahan yang mengecewakan pelanggan kami.
Menyetujui Lingkup Proyek Anda
Bekerja dengan pelanggan, tim, dan semua pemangku kepentingan untuk menyetujui penyerahan proyek dan fungsi serta tujuannya tidaklah mudah. Misalnya, situs web perusahaan adalah:
- ekspresi citra perusahaan, menurut para eksekutif senior
- sumber eksposur tanggung jawab hukum, menurut penasihat perusahaan
- alat untuk mendatangkan pendapatan baru, menurut departemen pemasaran
- item biaya lain untuk dipelihara, menurut keuangan
- kesempatan untuk menyelesaikan beberapa masalah perekrutan dan mendapatkan calon karyawan yang baik, menurut sumber daya manusia
- pekerjaan pemeliharaan, menurut departemen TI
- sebuah proyek untuk diselesaikan, menurut tim pengembangan web
Kuncinya di sini adalah setiap orang benar. Manajemen ruang lingkup yang sukses membutuhkan kemampuan untuk memahami perspektif setiap orang, melihat apa yang mereka butuhkan dan apa yang mereka tawarkan, dan memasukkan semuanya ke dalam satu rencana dan satu definisi.
Mendapatkan di Halaman yang Sama
Setiap orang yang terpengaruh oleh sebuah proyek memiliki perspektifnya sendiri, dan bahasanya sendiri juga. Bagaimana "citra perusahaan" eksekutif diterjemahkan ke dalam "halaman arahan efektif" pemasaran, dan pesan "Tidak Ada Halaman 404 Tidak Ditemukan" dari departemen TI. Arsitektur adalah kemampuan untuk melihat satu hal dalam berbagai tampilan, berbagai perspektif, dan berbagai bahasa. Sebagai manajer proyek, kita juga harus menjadi arsitek, mampu melihat proyek dari semua perspektif dan mengatasi semua masalah.
Saat kami mengumpulkan definisi awal proyek, pernyataan ruang lingkup, kami harus memastikan bahwa setiap orang memahami maksud dan tujuan. Mereka mungkin memiliki istilah yang berbeda untuk hal yang sama; tidak apa-apa. Tapi jika dua orang memiliki gambaran yang sangat berbeda tentang apa yang sedang dibuat, kita punya masalah. Dan kita tidak bisa kabur tentang itu. Kami tidak dapat menyatakan "Kami membuat mamalia abu-abu," dan meminta tim korporat mengharapkan seekor gajah sementara Direktur Keuangan hanya setuju untuk membayar seekor tikus.
Menyetujui Scope
Begitu kami berada di halaman yang sama, kami bekerja dengan setiap pemangku kepentingan untuk menentukan apa yang kami buat, dan mengapa. Kami masih beroperasi pada level tinggi di sini. Tapi kami bolak-balik, mengklarifikasi, mendefinisikan, dan mendapatkan gambaran yang lebih baik dan lebih baik tentang apa yang kami buat.
Memperjelas Asumsi
Seperti yang kami katakan di atas, pelanggan tidak senang ketika mereka tidak mendapatkan apa yang mereka harapkan. Untuk memastikan kami memahami dan mengelola harapan mereka, kami tidak dapat membiarkan pernyataan ruang lingkup proyek dalam istilah bahasa Inggris yang tidak jelas dan jelas. Itu harus didefinisikan dengan ketelitian teknik, dan itu juga harus dijelaskan dalam bahasa biasa juga. Ini juga membantu untuk menggunakan diagram, dan, jika memungkinkan, mengembangkan mock-up dan prototipe sehingga pelanggan dan pemangku kepentingan kami benar-benar dapat melihat, atau melihat gambar, apa yang akan mereka dapatkan. Untuk pentingnya bahasa yang tepat, lihat bilah sisi, Kapan Selasa depan?
Langkah-langkah Manajemen Lingkup
Institut Manajemen Proyek mendefinisikan empat proses yang membentuk Manajemen Lingkup:
- Perencanaan Lingkup meletakkan rencana kami untuk mengelola ruang lingkup pada proyek khusus ini. Jika proyek kami cukup mirip satu sama lain, maka ini dilakukan sekali untuk semua proyek, dan kami mengikuti metodologi standar.
- Scope Definition adalah proses pembuatan pernyataan pertama kami tentang apa yang kami buat pada proyek ini, termasuk sifat, fungsi, dan tujuannya. Pernyataan Definisi Ruang Lingkup yang dihasilkan adalah konsep inti dari mana keseluruhan proyek direncanakan.
- Work Breakdown Structuring (WBS) adalah proses mendefinisikan semua detail dari apa yang kami buat, membuat definisi ruang lingkup proyek yang lengkap dan tepat.
PMI menawarkan nama mewah untuk membuat definisi cakupan tingkat tinggi terlebih dahulu dan kemudian WBS mendetail. Mereka menyebutnya elaborasi progresif.
Pertanyaan Yang Mendefinisikan Sisa Proyek
Definisi ruang lingkup yang jelas sangat penting untuk merencanakan dan menentukan semua aspek lain dari proyek. Definisi yang tepat dari masing-masing dari delapan bidang lain dari manajemen proyek bergantung pada definisi ruang lingkup yang solid dan jelas. Jika Anda tidak jelas tentang sembilan bidang manajemen proyek, Anda mungkin ingin membaca Sembilan Area Manajemen Proyek, dan Mengapa Mereka Penting.
Inklusi dan Pengecualian
Alat yang sangat baik untuk mendefinisikan ruang lingkup dan mencegah scope creep adalah untuk mencakup definisi dari apa yang kita buat, yaitu daftar inklusi, dan juga daftar apa yang orang telah meminta bahwa kita tidak membuat, yaitu, daftar dari pengecualian. Ada dua alasan untuk melakukan ini.
Pertama-tama, orang cenderung mengingat bahwa mereka akan mendapatkan apa pun yang mereka inginkan, meskipun Anda mengatakan "tidak". Kita dapat mengelola kecenderungan alami manusia ini dengan menuliskan apa yang kita sepakati, dan menunjukkannya kepada mereka, dan membuat mereka menandatanganinya. Kemudian, nanti dalam proyek, ketika mereka ingat bahwa mereka memintanya, dan berpikir mereka akan mendapatkannya, kami dapat menunjukkan kepada mereka, maaf, tidak, itu selalu dikeluarkan dari ruang lingkup, kesepakatan tentang apa yang kita buat.
Misalnya, saya sedang membangun situs web untuk sebuah perusahaan di Florida Selatan, yang memiliki tiga bahasa populer: Inggris, Spanyol, dan Haiti. Selama definisi cakupan awal, kami setuju bahwa situs tersebut akan berbahasa Inggris dan Spanyol, tetapi menerjemahkannya ke dalam Kreol Haiti saat ini tidak hemat biaya. Kami menuliskan "Situs web tidak akan diterjemahkan ke dalam bahasa Kreol Haiti tahun ini. Jika permintaan dari komunitas Kreol meningkat, ini mungkin terjangkau tahun depan."
Kemudian, ketika situs tersebut sedang diuji, seorang manajer datang dan berkata, "tetapi saya tidak dapat membaca situs tersebut dalam bahasa Creole. Apa yang terjadi?" Kami mengeluarkan pernyataan lingkup, dan menunjukkan kepadanya bahwa Kreol dikecualikan untuk saat ini.
Alasan kedua hanyalah untuk kejelasan. Menentukan pengecualian meningkatkan kejelasan tentang apa yang kami lakukan dan memberi kami alat untuk mengelola creep cakupan nanti dalam proyek. Misalnya, salah satu tujuan situs web dalam pernyataan lingkup kami adalah untuk "meningkatkan dukungan pelanggan." Sebagai bagian dari itu, seseorang menyarankan obrolan online, tetapi kami memilih untuk tidak melakukannya. Jika kami tidak menuliskan "obrolan online" di daftar pengecualian, seseorang dapat menyarankannya lagi nanti. Tetapi jika kami menuliskannya, maka semua orang jelas: Kami tidak menerapkan obrolan online. Itu menghemat banyak waktu untuk melakukan diskusi yang sama berulang kali.
Membuat Work Breakdown Structure (WBS)
Penataan Perincian Kerja dimulai ketika Pernyataan Cakupan disetujui oleh semua pemangku kepentingan. Ini adalah proses membuat daftar hierarki yang sangat cermat, terperinci, dari semua komponen proyek.
Misalnya, kita sedang membuat pesawat terbang. Deskripsi awal kami terlihat seperti ini:
- satu badan pesawat
- satu kokpit
- satu kabin
- dua sayap
- perakitan satu ekor
- kontrol penerbangan
- elektronik untuk navigasi dan tujuan lain
Masing-masing komponen utama tersebut menjadi tajuk untuk daftar komponen yang lebih kecil. Sayap meliputi:
- tubuh sayap
- tangki bahan bakar
- saluran bahan bakar
- tutup
Akhirnya, ini dirinci menjadi daftar lengkap bagian. Untuk jet komersial, itu bisa lebih dari 1 juta bagian!
Membuat Rencana Proyek Lainnya
Setelah kami memiliki WBS, Anda dapat membuat sisa rencana proyek terperinci lainnya. Kami dapat membuat perkiraan waktu dan biaya yang akurat. Kami juga dapat menyelesaikan rencana untuk mengelola enam bidang manajemen proyek lainnya: kualitas, risiko, sumber daya manusia, komunikasi, pengadaan, dan integrasi.
Misalnya, WBS adalah daftar dari apa yang kami buat. Dari situ kita bertanya bagaimana kita akan membuat tiap komponen. Itu menghasilkan Daftar Aktivitas, yang merupakan komponen kunci dari perkiraan waktu. Juga, ketika kita tahu apa yang kita buat, kita bisa bertanya, "Apa yang salah?" dan itu adalah titik awal untuk perencanaan risiko. Dan bertanya "apa yang membuatnya bagus?" adalah awal dari perencanaan kualitas.
Mengelola Ruang Lingkup Selama Proyek
Setelah WBS disetujui, kami menyelesaikan sisa rencana proyek. Setelah seluruh rencana disetujui, kami meluncurkan pekerjaannya. Sekarang, tugas kita adalah menyelesaikan proyek tersebut. Atau, dalam istilah manajemen proyek, kami akan memberikan ruang lingkup yang ditentukan dengan kualitas yang dapat diterima tepat waktu dan sesuai anggaran, apa pun yang terjadi.
Melakukan ini membutuhkan pekerjaan, yang disebut eksekusi. Tapi itu juga panggilan untuk melacak pekerjaan itu dan mengoreksi jalannya, jika perlu. Itu disebut pelacakan dan kontrol. Ini seperti mengemudi di jalan raya. Jika yang Anda lakukan hanyalah mengemudi, Anda akan ketinggalan pintu keluar, dan terlambat. Atau Anda akan pergi terlalu lambat dan terlambat, atau Anda akan mempercepat dan mendapatkan tiket. Untuk mengemudi dengan baik, kita harus memperhatikan di mana kita berada, seberapa cepat kita melaju, apakah kita kehabisan bensin, dan apa yang dilakukan pengemudi lain di jalan. Itu sama pada sebuah proyek. Dan kami mencapainya dengan Analisis Nilai Perolehan, mengelola cakupan creep, dan mengelola kesembilan area proyek.
Analisis Nilai yang Diperoleh
Earned Value Analysis (EVA) dimulai dengan pelacakan cakupan, waktu, dan biaya. Dalam bahasa Inggris yang sederhana: Apa yang telah kita selesaikan, berapa banyak waktu yang dibutuhkan, dan berapa banyak uang yang kita habiskan? Setelah kami mendapatkan angka-angka itu, kami memasukkannya melalui beberapa persamaan. Persamaannya proporsional: Mereka menanyakan berapa banyak ruang lingkup yang telah kita selesaikan dalam kaitannya dengan waktu yang dihabiskan dan uang yang dihabiskan. Hasil tersebut menjawab pertanyaan: Jika kita terus berjalan pada kecepatan ini, apakah kita akan menyelesaikannya sebelum kita kehabisan waktu dan uang? Jika demikian, semuanya baik-baik saja. Jika tidak, maka kita harus mencari tahu mengapa kita berjalan lambat, atau menghabiskan terlalu banyak uang, dan mengatasi masalahnya.
Mengelola Scope Creep
Analisis nilai yang diperoleh mengukur kemajuan tujuan berkomitmen kami, ruang lingkup yang ditentukan. Tetapi bagaimana jika pelanggan mendapat ide bagus, dan ingin itu ditambahkan ke proyek? Bagaimana jika seorang insinyur memikirkan fitur yang lebih baik, dan dia ingin fitur itu ditambahkan? Bagaimana jika beberapa eksekutif senior berhenti, dan digantikan oleh bos baru, dan dia menginginkan sesuatu yang sama sekali berbeda?
Masalah ini muncul setiap saat. Seperti yang saya katakan di atas, ruang lingkup muncul dari sifat manusia. Apa yang harus kita lakukan adalah menyadarinya dan membahas setiap perubahan yang diusulkan pada proyek sebelum menjadi asumsi, fitur, atau tuntutan.
Singkatnya, jangan biarkan siapa pun memindahkan tiang gawang. Jika seseorang ingin mengubah ruang lingkup, kami menghitung biaya perubahan proyek dan waktu tambahan yang diperlukan. Kemudian kita bernegosiasi: Kami lebih memilih tidak ada perubahan, tapi kami akan membuat perubahan untuk lingkup jika proyek menerima perpanjangan dari dana batas waktu dan ekstra, sehingga kami dapat memberikan yang baru , peningkatan ruang lingkup, yang lebih dari yang ditentukan, dan oleh karena itu lebih dari yang dianggarkan atau dimasukkan ke dalam jadwal.
Dalam bahasa Inggris sederhana: Jika Anda menginginkan lebih banyak barang, itu akan memakan waktu lebih lama dan biaya lebih banyak. Itu disebut Besi Ruang Lingkup, Waktu, dan Biaya.
Mengelola Sembilan Area
Ada satu hal lagi yang dapat kami lakukan untuk memastikan bahwa kami memberikan hasil proyek dan menyenangkan pelanggan. Perhatikan apa yang saya katakan di atas, berikan hasil "dengan kualitas yang dapat diterima… apa pun yang terjadi." Ini menunjukkan fakta bahwa kita harus mengelola lebih dari sekedar ruang lingkup, waktu, dan biaya. Sangat penting untuk mengelola kesembilan bidang manajemen proyek di seluruh proyek, dari awal hingga akhir. Manajemen Kualitas Proyek memastikan hasil yang dapat diterima - atau sangat baik. Manajemen Risiko Proyek memastikan kesuksesan apa pun yang terjadi. Untuk penjelasan tentang kesembilan bidang, dan mengapa itu penting, silakan baca Sembilan Bidang Manajemen Proyek dan Mengapa Mereka Penting.
Memberikan Apa yang Anda Janjikan
Jika kita tetap mengerjakan proyek untuk membangun produk, layanan, atau hasil yang kita tentukan dalam pernyataan ruang lingkup, maka suatu hari - sehari sebelum uang dan waktu habis, saya harap - kita siap untuk mengirimkan.
Atau, kami pikir kami siap untuk mengirimkan. Tapi apakah kita benar-benar yakin? Dan apa yang dipikirkan pelanggan. Mari kita lihat langkah-langkah yang kami ikuti untuk memastikan kami memberikan hal yang benar kepada pelanggan, dan menyelesaikannya dengan baik.
Verifikasi dan Validasi
Verifikasi adalah proses internal proyek, di mana kami memeriksa apa yang telah kami buat terhadap pernyataan ruang lingkup, WBS, dan dokumen terkait lainnya. Kami memastikan, sebaik mungkin, bahwa apa yang telah kami lakukan memenuhi atau melampaui semua persyaratan pelanggan. Dan, jika kami menyetujui perubahan cakupan proyek, kami juga menyertakan perubahan tersebut dalam penyampaian kami. Sederhananya, kami membandingkan apa yang akan kami berikan dengan rencana, dan memastikan semuanya berjalan lancar. Penting bahwa ini bukan hanya hal yang kami sampaikan. Apa pun yang kami kirimkan harus bermanfaat bagi pelanggan, yaitu harus memenuhi persyaratan fungsional , serta persyaratan fisik. Jadi, sebelum kami mengirimkan, kami ingin bisa mengatakan, "Ini dia, dan berhasil!"
Tapi apakah pelanggan akan setuju? Pertanyaan itu dijawab oleh proses Validasi. Kami tidak dapat melakukan validasi sendiri. Ini biasanya dilakukan oleh pelanggan, saat mereka memeriksa dan menandatangani pengiriman hasil proyek. Tetapi ada dua kemungkinan lain:
- Jika kami mengirimkan sesuatu yang besar, atau rumit, atau sesuatu yang perlu memenuhi persyaratan yang menuntut, kami mungkin ingin mengatur validasi jauh sebelum tanggal pengiriman. Ini memberi waktu kepada tim proyek untuk menyesuaikan atau memperbaiki apa pun yang tidak memenuhi persyaratan pelanggan.
- Jika ada perselisihan tentang apakah proyek kami memberikan hasil yang didaftarkan pelanggan, mereka dapat meminta Verifikasi & Validasi Independen (IV&V), di mana kontraktor luar masuk untuk menentukan celah antara apa yang kami berikan dan apa yang pelanggan keinginan, dan merekomendasikan solusi.
Pengiriman
Namun, biasanya, IV&V tidak diperlukan. Kami memberikan hasil proyek, yang mungkin termasuk instalasi, penyiapan, dan pelatihan, bergantung pada apakah itu termasuk dalam pernyataan lingkup proyek. Pelanggan menendang ban, bisa dikatakan, dan puas atau meminta beberapa perubahan kecil, yang kami lakukan. Dan kemudian proyek selesai - hampir.
Kesenangan Pelanggan
Langkah terakhir kami termasuk memastikan semua orang dibayar dan menandatangani kontrak dan semacamnya, Ini juga harus mencakup pertemuan murni untuk layanan pelanggan, untuk memastikan bahwa mereka senang dengan pekerjaan kami. Akhir dari sebuah proyek bisa menjadi awal dari hubungan yang panjang dan sehat dengan pelanggan.