Trial

1.4 Segitiga Besi Manajemen Proyek

Menyeimbangkan Anggaran Anda, Ruang Lingkup, dan Jadual
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.

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? 

Menurut PMBOK, sembilan bidang ini mencakup keseluruhan pengetahuan yang dibutuhkan untuk mengelola proyek.
(Gambar milik dari Viva TI)

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
 
Kita semua akrab dengan kendala triple-"segitiga besi" umumnya terkait dengan mengelola proyek. Mari kita menggambar di sini, dan bukan "waktu", "biaya" dan "lingkup", mari kita menempatkan bidang manajemen proyek pengetahuan yang sesuai. Standard Project Triple Constraint Triangle

Pengetahuan Area 4. Manajemen Mutu
Sering "segitiga besi" digambarkan dengan "Kualitas" di hatinya. Hal ini menunjukkan bahwa kualitas dipengaruhi oleh batas-batas segitiga. Kita dapat mencakup area proses di sini. Iron Triangle with Quality
Pengetahuan Luas 5. Manajemen Risiko
Risiko proyek pada dasarnya adalah potensi menggelincirkan dari empat bidang pengetahuan sebelumnya. Mari kita menggambar sebuah lingkaran di sekitar segitiga dan label dengan area pengetahuan yang sesuai. Risk Management Overlaid on Triple Constraint
Kelompok Orang Terlibat dengan Proyek
Oke, jadi di sinilah aku mulai mengetuk hal-hal sekitar. Proyek terdiri dari tiga kelompok utama orang. Mereka adalah stakeholder, tim proyek, dan tim vendor yang menyediakan barang atau jasa untuk proyek. Aku meletakkan mereka sejajar dengan apa yang telah kita ditarik sejauh ini. People Involved with a Project

Pengetahuan Wilayah 6. Komunikasi Manajemen
Area pengetahuan yang berfokus pada komunikasi selanjutnya. Daerah ini mencakup pekerjaan seperti mengembangkan rencana komunikasi, menyiapkan template standar untuk komunikasi rutin, menentukan apa yang perlu dikomunikasikan dan bagaimana. Menurut model di atas posting ini, sebagian besar interaksi dengan pemangku kepentingan terjadi di sini. Setiap manajer proyek akan mengatakan daerah ini adalah binatang. Project Communications Management
Pengetahuan Wilayah 7. Integrasi Manajemen
Ini kelompok proses hubungan semua bidang pengetahuan bersama-sama. Ini dasarnya struktur tingkat tinggi proyek, dan mana piagam dikembangkan, di mana kebijakan perubahan ditetapkan, dan di mana aturan-aturan dasar yang ditetapkan. Project Integration Management

Pengetahuan Daerah 8. Manajemen Sumber Daya Manusia dan 9. Manajemen Pengadaan
Jadi kami pergi dengan dua daerah akhir pengetahuan / kelompok proses. Manajemen Sumber Daya Manusia berfokus pada aspek "orang" dari tim proyek. Ini mencakup hal-hal seperti membangun tim dan bekerja dengan manajer fungsional untuk mengembangkan staf, antara lain. Manajemen Pengadaan dikaitkan dengan semua vendor yang hal. Mengelola hubungan, kontrak dan negosiasi, dll Where is Stakeholder Management

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:

AddThis