Menyeimbangkan Anggaran Anda, Ruang Lingkup, dan Jadual
Juga dikenal sebagai The Triple Constraint Manajemen Proyek
Juga dikenal sebagai The Triple Constraint Manajemen Proyek
Pelajari cara untuk memberikan proyek dalam "segitiga besi."
Anda mengelola pelaksanaan sistem pelaporan baru untuk organisasi Anda. Ketika proyek Anda berlangsung, terjadi hal-hal yang berbeda dari hal-hal yang Anda rencana.
Anda menemukan bahwa Anda perlu hardware komputer ekstra, dan beberapa tugas telah dilakukan lebih lama daripada perkiraan semula Anda.
Untuk mendapatkan tugas selesai tepat waktu, Anda mempertimbangkan merekrut kontraktor lebih. Tapi, untuk melakukan ini, Anda harus mengambil biaya lain dari anggaran proyek. Anda berpikir tentang tidak membeli perangkat keras komputer tambahan yang Anda butuhkan, namun, ini berarti mengubah lingkup proyek, sehingga beberapa fungsi tidak perlu di adakan.
Dalam banyak proyek, anggaran, ruang lingkup dan jadual sangat erat terkait. Perubahan salah satu dari tiga kendala utama kemungkinan besar akan mempengaruhi orang lain, atau dampak pada kualitas proyek.
Artikel ini membahas hubungan antara tiga kendala anggaran, ruang lingkup dan jadual, dan melihat ide-ide dan alat untuk membantu Anda berurusan dengan isu-isu yang dapat mempengaruhi hubungan ini.
Besi Segitiga
Para mandat proyek dan flow project mengidentifikasi tujuan proyek. Pada inti dari dokumen ini adalah pernyataan persyaratan yang mengatakan apa proyek perlu deliverable. Hal ini mencakup definisi dari apa yang masuk dan keluar dari ruang lingkup untuk proyek tersebut. Hal ini juga menetapkan tenggat waktu proyek dan anggaran.
Kendala-kendala ruang lingkup, anggaran, dan jadual dikenal sebagai "segitiga besi" (lihat gambar 1).
Kendala ini dianggap sebagai segitiga besi karena Anda jarang dapat mengubah satu kendala tanpa juga mempengaruhi orang lain. Cara bahwa Anda memberikan proyek dalam kendala-kendala dampak kualitas hasil proyek, baik secara positif atau negatif.
Misalnya, mandat proyek Anda adalah untuk meluncurkan sistem TI baru mandiri. Tahap desain telah dikuasai secara signifikan. Anda dapat mempertimbangkan beberapa pilihan.
Setelah Anda memiliki tonggak Anda dan risiko dinilai, langkah berikutnya adalah mulai grafik timeline proyek. Langkah pertama dalam perencanaan timeline Anda adalah untuk meninjau Segitiga Besi waktu, biaya, dan ruang lingkup:
Prinsip Segitiga Besi dalam proyek manajemen menyatakan bahwa untuk setiap perubahan pada satu sisi, satu sisi (atau keduanya) harus berubah juga. Sebagai contoh, jika kita memiliki waktu terbatas untuk menyelesaikan tugas (tanggal tetap), maka kita lebih baik menambah atau mengurangi biaya cakupan. Jika kita perlu untuk mengurangi biaya, kita harus menambah waktu atau mengurangi ruang lingkup. Jika kita perlu menjaga lingkup pekerjaan utuh, kita mungkin perlu untuk meningkatkan waktu, biaya, atau keduanya. Sepertinya sederhana di atas kertas, tetapi sulit untuk mengelola ketika realitas mengendap masuk
Jadi, apakah yang paling proyek Anda membutuhkan : waktu, uang, atau fitur khusus yang ditetapkan / ruang lingkup? Itu adalah faktor pendorong untuk proyek Anda, dan kompromi dari dua faktor lain akan dibutuhkan (lebih banyak waktu, lebih banyak uang, atau mengurangi fitur). Ketika merencanakan proyek Anda, pastikan untuk memahami apa pengorbanan, dan apa prioritas berada pada tonggak masing-masing. Ini membantu mengelola harapan dengan stakeholder anda dan sukarelawan ketika Anda mulai mengatur waktu Anda, dan juga membantu mengelola risiko ketika terjadi hal-hal yang Anda tidak mengharapkannya.
Setelah Anda memiliki tonggak Anda dan risiko dinilai, langkah berikutnya adalah mulai grafik timeline proyek. Langkah pertama dalam perencanaan timeline Anda adalah untuk meninjau Segitiga Besi waktu, biaya, dan ruang lingkup:
Prinsip Segitiga Besi dalam proyek manajemen menyatakan bahwa untuk setiap perubahan pada satu sisi, satu sisi (atau keduanya) harus berubah juga. Sebagai contoh, jika kita memiliki waktu terbatas untuk menyelesaikan tugas (tanggal tetap), maka kita lebih baik menambah atau mengurangi biaya cakupan. Jika kita perlu untuk mengurangi biaya, kita harus menambah waktu atau mengurangi ruang lingkup. Jika kita perlu menjaga lingkup pekerjaan utuh, kita mungkin perlu untuk meningkatkan waktu, biaya, atau keduanya. Sepertinya sederhana di atas kertas, tetapi sulit untuk mengelola ketika realitas mengendap masuk
Jadi, apakah yang paling proyek Anda membutuhkan : waktu, uang, atau fitur khusus yang ditetapkan / ruang lingkup? Itu adalah faktor pendorong untuk proyek Anda, dan kompromi dari dua faktor lain akan dibutuhkan (lebih banyak waktu, lebih banyak uang, atau mengurangi fitur). Ketika merencanakan proyek Anda, pastikan untuk memahami apa pengorbanan, dan apa prioritas berada pada tonggak masing-masing. Ini membantu mengelola harapan dengan stakeholder anda dan sukarelawan ketika Anda mulai mengatur waktu Anda, dan juga membantu mengelola risiko ketika terjadi hal-hal yang Anda tidak mengharapkannya.
Perubahan kontrol . Manajer proyek di mana-mana tahu istilah itu. Ketika permintaan stakeholder perubahan ke pekerjaan proyek (lingkup), dampak dari perubahan yang perlu dinilai secara formal. Jika perubahan akan menghasilkan lebih banyak waktu atau uang, manajer proyek perlu menginformasikan semua stakeholder perubahan, dan mendapatkan persetujuan sebelum perubahan dapat dilanjutkan. Ini adalah cara yang tepat untuk mengandung proyek "besi segitiga".
Banyak manajer proyek saya tahu lebih suka melakukan seppuku sebelum mereka akan membiarkan pemangku kepentingan untuk melakukan perubahan tanpa mengikuti prosedur perubahan kontrol yang tepat. Tapi apakah ada keadaan di mana secara kaku mengikuti proses dapat merugikan proyek?
Bagi banyak orang, manajemen proyek proses adalah kekal. Aturan PM jelas, dan tidak ada pengecualian. Ketika saya berpikir kembali karier saya, meskipun, saya bisa memikirkan berkali-kali di mana melanggar proses adalah hal yang benar untuk dilakukan. Dalam hampir semua kasus, saya membuat konsesi untuk stakeholder, dan makan biaya. Tentunya PMI harus menutupi ini-dari perspektif saya, tidak ada proses yang berubah, dan kadang-kadang melanggar aturan benar-benar tepat.
Setelah memikirkannya, saya memutuskan untuk menarik dalam "kawasan proyek manajemen pengetahuan" tua untuk melihat di mana "pihak manajemen" dapat ditemukan. Apa yang saya temukan adalah bahwa pihak manajemen telah disamakan di bawah "manajemen komunikasi", dan menurut pendapat saya, itu sangat dipoles.
Masalahnya adalah, para pemangku kepentingan adalah orang-orang bebas berkehendak. Mereka akan mengikuti proses PM hanya selama melayani kepentingan mereka. Jika pada titik tertentu, mereka memutuskan PM tidak mendukung mereka, mereka akan mulai meminggirkan PM dan melakukan apapun yang mereka inginkan. Setiap manajer proyek yang dihadapkan ini tahu ada lebih banyak pekerjaan mengoles stakeholder dan menjaga mereka bahagia dari sekedar menyediakan mereka dengan laporan status.
Aku kembali memandang diagram AM bidang pengetahuan di atas dan memutuskan aku tidak menyukainya. Alih-alih membuat semua kelompok proses blok paralel, mari kita mengatur mereka dengan cara yang memungkinkan kita melihat bagaimana mereka berhubungan satu sama lain. Klik pada setiap gambar untuk tampilan yang lebih besar.
Pengetahuan Area 1. Manajemen Waktu , 2. Manajemen Biaya dan 3. Ruang Lingkup Manajemen |
---|
Jadi, inilah masalah besar saya. Bidang pengetahuan khusus untuk menyediakan sumber daya manusia dan pengadaan. Pada dasarnya, PMI mengakui bahwa menjaga tim proyek dan tim vendor yang selaras dengan proyek dua area diskrit yang memerlukan pengetahuan khusus. Mengelola stakeholder, di sisi lain, cukup sketsa. Anda bisa berpendapat itu tertutup di suatu tempat antara komunikasi dan bidang manajemen integrasi pengetahuan, tetapi mari kita hadapi itu, itu cukup terkubur. Apakah semua orang baik-baik saja dengan ini?
Mari saya bertanya dengan cara yang berbeda:? Tidak apa-apa untuk menganggap bahwa komunikasi yang efektif dan kontrol perubahan adalah cukup untuk menjaga stakeholder bermain bola Terus terang, saya tidak percaya itu.
Berikut hal. Menjaga stakeholder Anda di baris adalah jauh lebih sulit daripada hanya menyediakan mereka dengan template laporan standar yang berisi ringkasan nilai yang diterima. Manajer proyek harus menjaga hubungan pemangku kepentingan. Dia harus memahami bagaimana para pemangku kepentingan sesuai dalam konteks organisasi, dan terhadap satu sama lain. Lebih dari apa pun, manajer proyek harus mampu bernegosiasi, mempengaruhi dan menggunakan seluruh array soft skill untuk menjaga stakeholder yang berbaris dengan ketukan sama seperti orang lain ... biasanya tanpa kekuasaan atau otoritas di luar itu nya atau stasiun itu. PMBOK mengakui semua ini, tapi (menurut saya) tidak benar-benar menawarkan sesuatu yang nyata yang bisa menyiapkan manajer proyek baru untuk realitas manajemen pemangku kepentingan.
0 comments:
Post a Comment