Menghindari Terlalu Banyak Perubahan dalam Proyek
Mengontrol yang proyek perubahan yang Anda terima.
Pernahkah Anda pada sebuah proyek yang tampaknya untuk mengembangkan kehidupan sendiri? Tiba-tiba, bukan satu tujuan utama, Anda harus mengurus tiga tujuan sekunder sebelum Anda bisa kembali ke jalur - dan kemudian Anda tidak bisa menyelesaikan tepat waktu?
Mari kita lihat contoh perbaikan rumah. Anda ingin mengganti meja dapur Anda. Tapi kemudian Anda pikir ubin kembali dapat diperbarui dan diganti juga. Dan Anda tentu tidak dapat mengganti meja tanpa wastafel baru dan keran. Oh tidak - wastafel yang Anda inginkan tidak masuk ke ruang lama. OK, Anda hanya akan memindahkan pipa saluran air, kan?!
Sebelum Anda menyadarinya, Anda sudah dirobek-robek seluruh dapur Anda, dan Anda sedang menunggu untuk lemari baru, peralatan, dan lantai. Anda mencoba untuk mencari tahu bagaimana Anda akan tinggal di rumah tanpa dapur untuk enam minggu berikutnya, dan Anda tidak tahu bagaimana Anda akan membayar semua tambahan ini kecil dan upgrade di waktu yang tampaknya seperti ide yang baik.
Apakah Anda pernah mengalami hal ini dengan sebuah proyek bisnis?
Proyek dapat dengan cepat tumbuh melampaui batas-batas awal mereka jika Anda tidak hati-hati mengendalikan perubahan pada mereka. Ini disebut "scope creep" - tujuan baru dan kebutuhan "menyelinap" pada Anda tanpa peringatan.
Mengendalikan Perubahan Permintaan dalam Proyek
Perubahan yang diminta setelah proyek sedang berlangsung adalah bagian tak terelakkan dari setiap proyek. Mereka dapat menjadi hasil dari perubahan eksternal dalam bisnis atau mereka dapat meminta perubahan internal karena tujuan asli dari proyek ini adalah tidak jelas atau dipahami.
Perubahan permintaan yang dihasilkan dari faktor eksternal biasanya di luar kendali seorang manajer proyek dan biasanya ada pilihan kecuali menangani mereka. Manajer proyek yang paling sukses akan telah menempatkan proses di tempat pada awal proyek untuk menangani permintaan tersebut dan rencananya akan cukup fleksibel untuk mengatasi tanpa terlalu mempengaruhi hasil akhir.
Tetapi perubahan permintaan yang dihasilkan dari faktor internal harus ditangani dengan sangat berbeda. Dalam sebuah proyek yang ideal banyak dari ini akan telah dihindari dengan memastikan tujuan proyek ini didefinisikan dengan baik, persyaratan jelas didokumentasikan dan dikomunikasikan kepada semua pemangku kepentingan, dan para pemangku kepentingan memahami apa yang diharapkan dari produk akhir. Tentu saja, kita tidak selalu hidup dalam dunia yang ideal dan tidak peduli seberapa teliti dan rinci tahap awal proyek yang akan selalu ada perlu proses perubahan yang efektif di tempat.
Tidak semua stakeholder dan pengguna akhir dapat memvisualisasikan suatu produk akhir dengan membaca dokumentasi dan mempelajari diagram. Bahkan ketika prototipe digunakan untuk meningkatkan produksi persyaratan mereka, menurut sifatnya, tidak sepenuhnya berfungsi produk dan kesalahpahaman dan asumsi akan dapat dihindari pada proyek-proyek kompleks.
Namun demikian, dokumentasi yang baik dan komunikasi yang jelas dari tujuan proyek dan persyaratan akan meminimalkan jumlah permintaan perubahan.
Jadi apa cara terbaik untuk mengendalikan permintaan perubahan dalam proyek dan masih mampu memberikan proyek diselesaikan dalam waktu, anggaran dan ruang lingkup diterima?
Bedakan Antara Diperlukan dan "Nice-untuk-Have"
Setiap permintaan perubahan harus memiliki kasus bisnis untuk kembali ke atas dengan cara yang sama proyek secara keseluruhan telah. Tentu saja, ini bisa menjadi deskripsi yang sangat sederhana dan singkat, tetapi merupakan elemen penting dari semua permintaan perubahan sebelum mereka dapat dipertimbangkan untuk dimasukkan dalam sebuah proyek.
Unsur paling penting dari kasus permintaan perubahan bisnis adalah manfaat yang diharapkan, yang harus menunjukkan nilai yang akan ditambahkan ke proyek dengan perubahan. Hal ini, dalam dirinya sendiri, akan menunjukkan perubahan yang mungkin diperlukan. Hal ini penting untuk mengenali deskripsi dari beberapa kasus bisnis belum tentu menguntungkan proyek dalam hal waktu dan anggaran, tetapi diperlukan untuk klien untuk tetap kompetitif di pasar mereka.
Jika manfaat yang tidak secara eksplisit dinyatakan kemudian mendiskusikan masalah ini dengan orang yang meminta perubahan untuk menentukan apakah ada manfaat bisnis asli.
Lebih baik merancang solusi, atau lebih bagus, lebih banyak fitur menarik yang tidak manfaat kecuali mereka dapat didukung oleh bagaimana hal ini akan memiliki dampak positif pada anggaran proyek dan jadwal, atau dampak positif pada upaya akhir-pengguna yang dibutuhkan untuk menyelesaikan tugas-tugas rutin. Pertanyaan khas kasus bisnis dari permintaan perubahan harus menjawab adalah:
- "Apa yang mengubah bisnis eksternal telah mengakibatkan permintaan ini berubah?"
- "Apa faktor internal telah mengakibatkan permintaan ini berubah?"
- "Bagaimana perubahan ini mempengaruhi waktu yang dibutuhkan untuk menyelesaikan proyek?"
- "Bagaimana perubahan ini mempengaruhi penggunaan produk akhir?"
- "Apa penghematan biaya akan dilakukan dengan menerapkan perubahan ini?"
Hindari Wasting Waktu dan Usaha
Cara yang paling jelas untuk menghindari pemborosan sumber daya proyek yang berharga pada permintaan perubahan yang berlebihan dan proses perubahan manajemen secara keseluruhan, adalah untuk memastikan proyek dimulai dengan tujuan jelas dan persyaratan.
Hal ini juga penting kriteria yang akan digunakan untuk menentukan keberhasilan proyek ini didokumentasikan singkat pada awal proyek. Pastikan semua dokumen didistribusikan kepada stakeholder dan pengguna akhir dan bahwa salinan mudah diakses.
Hal ini juga penting kriteria yang akan digunakan untuk menentukan keberhasilan proyek ini didokumentasikan singkat pada awal proyek. Pastikan semua dokumen didistribusikan kepada stakeholder dan pengguna akhir dan bahwa salinan mudah diakses.
Jadwal waktu ke dalam rencana proyek untuk menangani permintaan perubahan dan jika waktu yang telah dimakan kemudian menunda permintaan beredar sampai minggu berikutnya. Pastikan bahwa semua pihak yang berkepentingan tahu ini adalah bagaimana proses bekerja.
Memiliki Kriteria Penerimaan dan Penolakan Batal
Gunakan beberapa kriteria yang jelas untuk menyaring permintaan tersebut yang tidak akan, atau tidak dapat, diterapkan. Salah satu kriteria penting adalah kasus bisnis, sehingga setiap permintaan tanpa satu segera dapat dikirim kembali ke penanya tersebut. Jangan buang waktu melacak pemohon untuk mencari tahu apa kasus bisnis. Ini harus menjadi tanggung jawab mereka untuk memberikan itu awalnya (bahkan jika Anda kemudian perlu untuk berdiskusi untuk memperbaikinya).
Bersiaplah untuk kembali alasan Anda untuk menolak permintaan perubahan dengan deskripsi dipikirkan baik-mengapa tidak ada kasus untuk memasukkan perubahan. Stick oleh keputusan Anda kecuali sponsor proyek siap untuk meningkatkan anggaran atau waktu yang tersedia untuk proyek tersebut.
Tapi jangan bersiaplah untuk bersikap fleksibel dan menegosiasikan trade-off dengan menjatuhkan tugas yang direncanakan dalam mendukung perubahan ketika tidak ada anggaran atau waktu ekstra tersedia.
Selalu menerapkan praktek manajemen proyek terbaik sepanjang setiap area proyek jika Anda ingin kesempatan keberhasilan tertinggi.
Mengontrol Perubahan Permintaan
Perubahan adalah bagian penting dari setiap proyek. Ada dua faktor di pekerjaan yang menjamin generasi permintaan perubahan: perubahan yang terjadi pada pasar proyek ini ditujukan untuk, dan pemahaman tidak jelas tujuan dan sasaran proyek. Faktor pertama adalah kekal, kita tidak bisa menghentikan dunia luar pintu kami berubah apakah kita suka atau tidak. Proyek yang berhasil cukup gesit untuk menanggapi rangsangan dan mereka menemukan kembali diri mereka sendiri sehingga ketika produk atau layanan dari proyek hits pasar itu hal yang benar disampaikan pada waktu yang tepat.
Perubahan permintaan yang disebabkan oleh pemahaman stakeholder jelas tentang tujuan dan sasaran dari proyek ini adalah mudah untuk menghindari. Komunikasi yang jelas tentang tujuan keseluruhan proyek dan tujuan proyek akan menempatkan pada pijakan perusahaan.
Memastikan bahwa para pemangku kepentingan yang tepat meninjau persyaratan proyek dan bahwa para pengambil keputusan yang tepat menyetujui mereka juga membantu dalam menghindari permintaan perubahan yang muncul dari pemahaman jelas tentang tujuan proyek, sasaran dan persyaratan. Tapi tidak peduli seberapa rajin manajer proyek adalah dalam komunikasi mereka dan proses pengumpulan persyaratan, mereka masih akan harus berurusan dengan permintaan perubahan yang tidak memiliki nilai lain selain untuk menjernihkan kesalahpahaman stakeholder. Berikut adalah beberapa tips tentang cara untuk melakukan itu dan masih memiliki waktu untuk memberikan proyek.
Bercak Kebisingan
Bagaimana Anda membedakan antara permintaan perubahan yang muncul dari suatu kebutuhan untuk merespon perubahan di pasar, dan masalah proyek ini dimaksudkan untuk memecahkan? Anda harus dapat membuat perbedaan ini sebelum Anda mengambil langkah berikutnya dalam proses manajemen perubahan. Permintaan perubahan seperti kasus bisnis mini dan harus berisi elemen kasus bisnis berisi. Unsur yang menjadi perhatian kita di sini adalah manfaat yang diharapkan dari perubahan. Sebuah permintaan perubahan yang mengartikulasikan manfaat yang akan diperoleh dari membuat perubahan seperti membuat proses pembelian on-line lebih mudah, membuat produk lebih menarik bagi target demografis, atau mengubah fungsi untuk mengatasi perubahan dalam proses alur kerja adalah permintaan perubahan yang mungkin menambah nilai proyek. Jenis permintaan perubahan harus mengalir ke langkah berikutnya dalam Anda Change Control proses.
Manfaat juga dapat bertambah untuk proyek itu sendiri. Sebagai contoh, perubahan yang akan mengurangi jumlah pekerjaan yang diperlukan untuk membangun sebuah penyampaian atau perubahan yang akan memungkinkan tim untuk memberikan awal dari yang direncanakan.
Permintaan perubahan mungkin tidak mengandung deskripsi eksplisit dari manfaat yang mereka bawa. Ahli Subject Matter yang melihat kebutuhan untuk memenuhi permintaan pasar tempat baru atau bintik-bintik kesempatan untuk menyimpan uang atau waktu mungkin tidak ahli dalam menyatakan kasus bisnis. Manfaat tersirat untuk organisasi atau proyek mungkin tersembunyi dalam deskripsi teknis dari perubahan yang diminta. Proses perubahan manajemen Anda harus menyediakan informasi kontak penanya diberikan pada permintaan perubahan dan untuk semua pemohon harus siap untuk menjawab pertanyaan tentang permintaan mereka. Kunjungi, telepon, atau e-mail pemohon dan meminta mereka untuk menjelaskan kasus bisnis secara lebih rinci. Tanyakan kepada mereka pertanyaan terkemuka seperti "Apa permintaan pasar baru akan mengubah ini memenuhi?", "Bagaimana perubahan ini menghemat waktu proyek?", Atau "Berapa banyak uang yang akan perubahan ini menyimpan proyek?" Hindari menanyakan pertanyaan seperti "Bagaimana perubahan ini meningkatkan sistem?", Atau "Bagaimana perubahan ini meningkatkan kualitas?"
Pertanyaan-pertanyaan ini akan membuka pintu untuk diskusi tentang mengapa solusi mereka adalah lebih baik dari yang semula ditentukan.
Uraian tentang manfaat perubahan mungkin harus dibujuk dari penanya, tetapi jika mereka tidak dapat mengartikulasikan manfaat dari perubahan yang diminta setelah pertanyaan terkemuka beberapa, atau mereka bersikeras memutar percakapan mengapa solusi mereka adalah lebih baik dari yang awalnya direncanakan , mengakhiri percakapan, Anda punya informasi yang Anda sedang mencari - ada manfaatnya.
Sebuah Pencegahan dari sesuatu...
Anda memiliki kewajiban untuk menghindari waktu yang terbuang untuk penyusunan permintaan perubahan yang tidak menguntungkan organisasi atau proyek, di sini adalah bagaimana Anda melakukan itu. Negara tujuan proyek dan tujuan jelas dalam Piagam Proyek , Kasus Bisnis, dan Pernyataan Kerja . Kejelasan tujuan proyek ini adalah langkah pertama Anda dalam menghindari kelebihan permintaan perubahan. Pastikan bahwa tujuan proyek dan sasaran dinyatakan dengan jelas dan sederhana. Kriteria keberhasilan proyek juga harus dinyatakan dengan sederhana dan jelas, serta langkah-langkah yang akan digunakan untuk memverifikasi keberhasilan. Komunikasikan Piagam Anda, Pernyataan Ruang Lingkup, atau SOW (Statement of Work) untuk semua stakeholder proyek. Anda tidak bisa memaksa setiap orang untuk membaca dokumen-dokumen, tetapi Anda dapat berkomunikasi harapan Anda dan membuat dokumen-dokumen mudah diakses oleh semua stakeholder.
Pastikan Anda menggunakan praktek-praktek terbaik yang menawarkan manajemen proyek untuk mengumpulkan dan memverifikasi persyaratan proyek Anda. Menurut pendapat saya, praktek-praktek terbaik disiplin yang ditawarkan dijelaskan dalam Tubuh Pengetahuan Manajemen Proyek (PMBOK) . Anda dapat mempelajari praktek-praktek dan menunjukkan kemahiran Anda dalam manajemen proyek dengan mengambil kursus PMP atau produk PMP ujian lainnya persiapan pelatihan dan lulus ujian sertifikasi PMP PMI. Saya telah menulis serangkaian artikel tentang pengumpulan persyaratan untuk proyek-proyek pengembangan perangkat lunak. Aku akan memberikan sketsa kuku jempol satu poin penting dalam artikel-artikel, di sini.
Anda memulai dengan satu set, jelas, singkat tujuan dan tujuan proyek sehingga Anda sudah memenuhi kriteria pertama untuk pengumpulan persyaratan. Yang berikutnya adalah untuk melibatkan stakeholder yang tepat untuk input ke dalam menetapkan persyaratan. Para stakeholder yang tepat adalah mereka yang akan menggunakan sistem, mereka yang pelanggan atau klien sistem, mereka yang memiliki sistem, mereka yang bertanggung jawab untuk pasar pelanggan, atau mereka yang memiliki sistem yang harus antarmuka dengan sistem baru / berubah . Masing-masing kategori stakeholder akan memiliki area perbedaan pengaruh atas proyek dan persyaratan mereka harus dibatasi untuk daerah-daerah.
Persyaratan dikumpulkan dari sumber-sumber juga harus jelas, singkat, dan jelas sehingga mereka dapat ditafsirkan ke dalam spesifikasi yang mengatur apa yang dibangun. Persyaratan juga harus diverifikasi - apa yang akan terlihat seperti ketika persyaratan produk telah puas? Bagaimana sistem merespon? Langkah berikutnya dalam mendapatkan persyaratan adalah memiliki orang yang tepat sign-off pada persyaratan. Sederhananya, orang yang tepat adalah mereka yang memiliki, atau bertanggung jawab, untuk unit bisnis milik stakeholder. Mereka dapat mendelegasikan keputusan untuk bawahan, tetapi hanya harus mendelegasikan ke salah satu bawahan, bukan panitia. Proses sign-off mungkin kompleks membutuhkan setiap stakeholder dalam unit bisnis untuk meninjau kebutuhan mereka dan memberikan masukan, tetapi hanya pembuat keputusan harus sign-off. Ada kemungkinan bahwa para stakeholder dalam satu unit bisnis mungkin bertentangan, atau bersaing, persyaratan dan Anda memerlukan pemilik bisnis untuk menjadi penentu akhir dalam suatu perselisihan.
Langkah terakhir dalam penangkapan persyaratan proyek adalah komunikasi persyaratan disetujui, ditandatangani, kepada para pemangku kepentingan proyek. Persyaratan akan ditangkap dalam beberapa bentuk Dokumen Persyaratan Usaha, atau Spesifikasi Komersial. Pastikan ini adalah dalam bentuk yang dapat dibaca, membuat para pemangku kepentingan menyadari lokasinya, berkomunikasi harapan Anda untuk membacanya, dan pastikan dapat diakses oleh semua stakeholder.
... Adalah Worth a Pound of Cure
Jadi Anda sudah mengikuti saran saya dan Anda masih dibombardir dengan permintaan perubahan tanpa kasus bisnis yang valid. Anda perlu untuk bertindak sebagai pemeriksa sehingga sumber daya proyek yang berharga tidak terbuang menganalisis dan memperkirakan permintaan yang tidak memiliki harapan penerimaan. Alasannya sederhana: proyek Anda hanya memiliki begitu banyak waktu yang dialokasikan untuk mengevaluasi permintaan perubahan dan waktu yang dihabiskan mengevaluasi salah satu yang tidak memiliki harapan persetujuan mengambil jauh dari waktu yang tersedia untuk mengevaluasi mereka yang lakukan. Semua pemangku kepentingan mungkin tidak memahami fakta ini, tetapi Anda akan sponsor eksekutif.
Mengubah rencana manajemen Anda harus memberikan jalan untuk menolak permintaan perubahan un-didukung oleh kasus bisnis sebelum langkah evaluasi. Orang yang bertanggung jawab untuk mengelola perubahan proyek harus menjadi baris pertama pertahanan. Orang itu bisa menjadi manajer proyek, atau seseorang pada tim proyek yang ditugaskan bahwa peran. Salah satu pengalaman saya yang terbaik dalam mengelola perubahan proyek muncul ketika saya mengidentifikasi seorang anggota tim sebagai Manajer Proyek yang bertanggung jawab untuk mengelola perubahan proyek. Wanita ini telah menyatakan minat dalam memperoleh pengalaman dalam mengelola proyek dan memiliki kekuatan karakter untuk mengambil peran dan tidak diganggu oleh para pemangku kepentingan. Dia telah masukan ke dalam mendefinisikan proses dan melakukan sangat baik untuk membatasi jumlah perubahan yang harus dievaluasi (terima kasih Melinda!)
Jangan ragu untuk menolak perubahan yang telah Anda dinilai tidak memiliki kasus bisnis untuk mendukungnya. Pastikan untuk memperluas alasan Anda untuk penolakan ketika Anda berkomunikasi penolakan untuk penulis, tetapi berdiri di belakang keputusan Anda.
Anda mungkin menemukan bahwa Anda harus berbicara dengan sponsor eksekutif Anda pertama kali atau dua Anda menolak permintaan perubahan untuk alasan ini, tapi manfaat itu akan menjadi dukungan Anda terima. Word akan menyebar bahwa Anda tidak bisa diganggu dan yang akan memiliki efek peredam pada penciptaan permintaan perubahan.
Bahkan jika sponsor eksekutif Anda tidak mendukung Anda, Anda akan tahu di mana Anda berdiri dan dapat membenarkan permintaan Anda untuk lebih banyak sumber daya untuk menangani evaluasi permintaan perubahan palsu.
Satu-satunya pengecualian pada aturan di atas adalah di mana Anda berurusan dengan permintaan perubahan yang didukung oleh kasus bisnis yang valid yang tidak disebutkan dalam permintaan dan bahwa Anda gagal untuk mendapatkan ketika mempertanyakan pemohon. Bersiaplah untuk menjadi fleksibel dalam hal ini, setelah semua tujuan Anda adalah tidak untuk menghilangkan permintaan perubahan, hanya untuk menghilangkan mereka tanpa kasus bisnis.
Menggunakan Manajemen Perubahan dan Pengendalian Perubahan Dalam Proyek
Dalam setiap proyek, perubahan tidak bisa dihindari apakah itu berasal dari dalam proyek atau dari sumber eksternal, sehingga masuk akal untuk memiliki proses yang disepakati dalam rangka untuk mengidentifikasi, menilai dan mengendalikan setiap potensi perubahan dan disetujui dengan apa yang awalnya disepakati untuk proyek tersebut.
Apa yang dibutuhkan adalah pendekatan sistematis dan umum.
Setelah rencana proyek dan dokumen lainnya yang terkait kunci telah disetujui, ini menjadi proyek "baseline" dan hanya dapat diubah setelah persetujuan oleh otoritas yang tepat, biasanya Dewan Proyek . Perubahan kontrol tidak ada untuk mencegah perubahan, tetapi untuk memastikan bahwa setiap perubahan disepakati oleh pihak yang berwenang sebelum pelaksanaan.
Sebuah elemen penting dan vital, adalah proyek penggunaan manajemen konfigurasi (CM).
Manajemen konfigurasi dapat diberikan sebagai layanan organisasi terus menerus atau disediakan oleh Kantor Proyek Dukungan (PSO). Segala sesuatu yang menghasilkan proyek tunduk pada manajemen konfigurasi, manajemen ini meliputi dokumentasi serta produk spesialis dan kiriman. Oleh karena itu penting untuk mengintegrasikan penggunaan prosedur pengendalian perubahan dengan sistem manajemen konfigurasi digunakan oleh proyek.
Sistem yang set-up untuk mengelola perubahan juga harus mencakup pengelolaan isu-isu umum. Sebuah Daftar Terbitan harus dibentuk pada awal proyek untuk menangkap dan membantu dalam manajemen perubahan dan isu-isu. Sebuah manajemen konfigurasi dokumen strategi harus dibuat sebagai bagian dari perencanaan dan ini menjelaskan cara di mana perubahan dan isu-isu yang harus dikelola dan ditangani sepanjang proyek.
Perbedaan antara masalah dan risiko adalah bahwa masalah telah terjadi, sedangkan risiko adalah sesuatu yang mungkin atau tidak mungkin terjadi di beberapa titik di masa depan.
Setiap kali masalah muncul, hal itu dapat dikelola secara informal, biasanya oleh manajer proyek, namun jika itu harus dikelola secara resmi maka manajer proyek akan masuk ke masalah register sebelum melanjutkan lebih jauh. Metodologi PRINCE2 menyatakan bahwa Laporan Masalah dibuat bersama-sama dan berisi informasi tambahan tentang itu isu tertentu.
Perubahan datang dalam dua rasa:
Permintaan Untuk Perubahan (RFC).
Ini berasal dari pelanggan atau pengguna dan permintaan untuk mengubah salah satu baseline proyek dalam beberapa cara. Jika ada biaya tambahan yang terlibat dalam pelaksanaan RFC, maka pelanggan biasanya akan membayar untuk itu. Karena semua itu RFC adalah perubahan apa yang telah awalnya disepakati, biasanya Dewan Proyek sendiri akan memiliki wewenang untuk menyetujui perubahan tersebut.
Spesifikasi off. Ini biasanya dibangkitkan dari sisi penawaran proyek, dan rincian beberapa aspek yang harus disediakan oleh proyek, tetapi saat ini tidak, atau diperkirakan tidak akan diberikan. Ini mungkin termasuk produk atau kiriman yang hilang, atau produk tidak memenuhi spesifikasi atau kriteria kualitas.
Pada awal proyek perlu memutuskan bagaimana perubahan dan isu-isu ini harus diprioritaskan, dan itu adalah biasa bahwa sistem penilaian mungkin mencakup istilah-istilah seperti, Harus Memiliki, Harus, Bisa Memiliki, atau tidak Akan Memiliki Untuk Sekarang . Definisi tersebut perlu disepakati.
Aspek lain yang perlu diputuskan adalah apakah atau tidak Dewan Proyek atau manajemen senior ingin terlibat dalam meninjau semua perubahan proyek. Jika banyak perubahan diperkirakan maka mungkin masuk akal untuk Proyek Dewan untuk menunjuk otoritas perubahan yang akan membuat keputusan tentang perubahan tersebut pada nama Dewan Proyek. Dalam kasus tersebut, "aturan keterlibatan" perlu ditentukan.
Sebagai contoh, otoritas perubahan hanya akan berurusan dengan perubahan biaya rendah. Aspek lain adalah menyiapkan anggaran perubahan untuk perubahan wewenang untuk menggunakan untuk mendanai setiap perubahan yang disetujui dan implementasi mereka.
Anggaran tambahan tersebut harus ditangkap dalam rencana proyek sebelum sign-off.
Seterusnya dengan prosedur kontrol perubahan itu sendiri ...
Langkah 1. Setiap kali perubahan atau masalah dinaikkan, itu harus dikategorikan dan dimasukkan dalam daftar isu / perubahan.
Langkah 2. Sebuah analisis dampak sekarang harus dilakukan dan biasanya akan melibatkan anggota tim pakar yang relevan.
Analisis mengenai dampak harus mempertimbangkan dampak perubahan atau masalah (yang mungkin positif atau negatif) pada berbagai aspek proyek seperti:
- Waktu
- Biaya
- Kualitas
- Cakupan
- Kasus Bisnis
- Manfaat
- Resiko
Perubahan atau isu yang harus diprioritaskan, pertama, dengan originator, dan kedua, setelah analisis dampak. Hal ini penting ketika melaksanakan analisis dampak di atas, bahwa wakil-wakil dari area bisnis proyek, para pengguna produk akhir, dan mereka yang memasok sumber daya untuk proyek, yang sepenuhnya terlibat sehingga keputusan seimbang dapat dicapai.
Langkah 3. Setelah memahami dampak dari perubahan atau masalah, langkah berikutnya adalah untuk mempertimbangkan pilihan alternatif dan mengusulkan tindakan terbaik untuk mengambil dalam rangka untuk mengatasi masalah atau menerapkan perubahan. Sebuah pandangan yang seimbang diperlukan dan pertimbangan harus diberikan semua pilihan pada durasi proyek, biaya, kualitas, lingkup, manfaat, dan target kinerja risiko. Keuntungan yang diperoleh harus seimbang terhadap dampak pelaksanaan masalah atau perubahan.
Langkah 4. Keputusan sekarang dibutuhkan apakah atau tidak untuk melaksanakan perubahan. Untuk RFC, ini biasanya akan perlu meningkat kepada Dewan Proyek keputusan mereka, sedangkan Off-Spesifikasi dapat diputuskan oleh manajer proyek jika mereka memiliki kewenangan yang cukup.
Jika proyek ini menggunakan manajemen dengan pengecualian di mana batas-batas toleransi yang telah ditetapkan, maka harus ada implementasi yang diusulkan menyimpang melampaui toleransi ini, Dewan Proyek harus terlibat dalam keputusan apakah akan melaksanakan atau tidak.
Selama implementasi, manajer proyek harus memastikan bahwa statusnya dilaporkan kepada Dewan Proyek sampai ke titik ketika masalah atau mengubah telah sepenuhnya dilaksanakan.
Strategi untuk Mengelola Perubahan: Project Manager
Judul manajer proyek (AM) digunakan untuk mengartikan hal yang berbeda dalam perusahaan yang berbeda. Untungnya ada sebuah badan standar yang disebut Institut Manajemen Proyek yang memberikan bimbingan yang sangat baik di sekitar peran dan fungsi seorang manajer proyek.
Beberapa akan setuju, tapi aku tidak peduli jika Anda adalah manajer proyek PMI bersertifikat atau tidak. Anda perlu peduli tentang memiliki seorang manajer proyek dengan keterampilan untuk melaksanakan peran sebagai Institut mendefinisikan itu. Ini mengubah strategi manajemen Anda, dan itu reputasi Anda di telepon.
Mencari Manajer Proyek
Apakah Anda memerlukan Proyek bersertifikat Management Professional (PMP)? Seperti saya katakan di atas, saya tidak peduli. Ada yang baru disertifikasi PMP yang telah mengambil tes mereka dan mendapatkan sertifikasi, tetapi mereka mungkin tidak perang diuji. Ada manajer proyek veteran yang pernah mendapat gelar mewah, tapi mereka tahu bagaimana mengelola proyek. Dan ada adalah segalanya di antara. Track record adalah apa yang Anda perlu peduli.
Apakah Anda memiliki tim kuat pada AM Anda sekarang? Apakah orang dihormati, mungkin pemimpin opini kunci dalam organisasi Anda? Apakah mereka memperlakukan manajemen proyek sebagai profesi? Maka dengan segala cara menggunakannya.
Jika, di sisi lain, manajer proyek telah judul yang digunakan oleh SMP, orang-orang terlatih yang berjalan sekitar dengan daftar tugas dan clipboard, saatnya untuk membawa pada bakat kuat.
Rute tercepat ke manajer proyek terbukti akan menjadi menyewa kontrak, baik dari perusahaan terkemuka atau independen. Ada yang bagus di luar sana. Dapatkan dan periksa referensi, dan wawancara setidaknya tiga. Biarkan para pemimpin opini kunci dan wawancara manajer mereka juga. Carilah track record mereka dan untuk kimia yang baik.
Set Up Manajer Proyek untuk Sukses
Sederhananya, semua orang perlu memahami bahwa manajer proyek adalah alter ego Anda. Semua orang termasuk Anda.
Manajer Anda dan pemimpin proyek harus memahami bahwa mereka bertanggung jawab kepada PM untuk menyediakan semua tugas mereka, ketergantungan mereka pada tugas-tugas lain dan unit kerja lainnya, komitmen jadwal mereka, dan kebutuhan sumber daya mereka.
Mereka perlu memahami bahwa PM akan meninjau semua informasi mereka dan mencari masalah. Ini dapat mencakup tugas-tugas terjawab, inkonsistensi jadwal, overloads sumber daya, dll Seringkali manajer akan memberitahu PM bahwa mereka dapat menangani beberapa masalah ini, dengan bekerja lagi jam orang atau dengan tumpang tindih beberapa tugas "oleh satu atau dua hari." Seorang manajer proyek yang baik akan menantang klaim tersebut, dan Anda akan perlu untuk berdiri di belakang PM.
PM akan mengadakan setiap orang bertanggung jawab atas kiriman tonggak. Dalam kebanyakan proyek, terutama yang kompleks, tonggak terlewatkan dan rencana kontinjensi harus diaktifkan. Sekali lagi, Anda sebagai pemimpin kebutuhan untuk mendukung PM karena mereka memegang orang bertanggung jawab.
Penanganan Konflik
Sangat mungkin bahwa AM akan memiliki konflik dengan memimpin tim manajer, atau orang lain dalam organisasi. Buatlah aman bagi orang untuk mendiskusikan dan membawa konflik tersebut. Hanya karena PM adalah alter ego Anda tidak membuat mereka benar, lebih daripada Anda selalu benar.
Libatkan pemimpin opini kunci Anda bersama dengan manajer proyek dan lain-lain.
Temukan fakta-fakta berkontribusi terhadap konflik, dan membuat keputusan yang diperlukan untuk mendapatkan strategi manajemen perubahan kembali ke jalur.
Perubahan strategi manajemen yang gagal sering melakukannya karena manajemen proyek yang buruk. Jangan biarkan hal itu terjadi pada Anda.