Proses Kawalan Perubahan: Langkah dan Templat untuk Projek

Setiap projek akan menghadapi perubahan. Soalannya bukan sama ada skop, belanjawan, atau garis masa akan berubah, tetapi sama ada pasukan anda mempunyai proses kawalan perubahan yang jelas untuk mengendalikan perubahan tersebut tanpa kehilangan jejak tentang apa yang telah dipersetujui, siapa yang meluluskannya, dan mengapa.

Apakah proses kawalan perubahan?

Proses kawalan perubahan ialah urutan langkah berstruktur yang diikuti oleh pasukan projek untuk menyerahkan, menilai, meluluskan atau menolak, melaksanakan, dan mendokumentasikan sebarang perubahan yang dicadangkan kepada skop, jadual, kos, atau penghantaran sesebuah projek. Ia mewujudkan laluan yang terkawal dan boleh diaudit daripada "seseorang mahukan sesuatu yang berbeza" kepada "kami telah mengemas kini pelan dan semua orang sudah mengetahuinya."

Fakta utama

• Hanya 35% projek memenuhi matlamat asalnya apabila perubahan skop dikendalikan secara tidak rasmi, berbanding 65% apabila proses perubahan formal ada (PMI Pulse of the Profession, 2024).
• Laporan Standish CHAOS secara konsisten mendapati bahawa perluasan skop menyumbang kepada lebih separuh projek IT yang bermasalah.
• Edisi ke-7 Panduan PMBOK menyenaraikan Perform Integrated Change Control sebagai proses pengurusan projek teras, menegaskan bahawa tiada perubahan harus melepasi penilaian dan kelulusan formal.

Proses kawalan perubahan yang kukuh melindungi garis dasar projek asal sambil memberikan pihak berkepentingan cara yang adil dan telus untuk meminta perubahan yang benar-benar memberikan nilai.

Kawalan perubahan berbanding pengurusan perubahan

Orang sering menggunakan istilah-istilah ini secara bergantian, tetapi ia bermaksud perkara yang berbeza dalam konteks projek.

Kawalan perubahan adalah sebahagian daripada pengurusan perubahan. Semasa projek, anda memerlukan kedua-duanya: proses formal untuk mengawal apa yang dibina, dan pendekatan dari segi manusia untuk memastikan pasukan dan pihak berkepentingan menyesuaikan diri dengan lancar.

Mengapa proses kawalan perubahan penting

Melangkau atau memendekkan proses kawalan perubahan mewujudkan masalah yang boleh diramalkan.

Perluasan skop tidak dikesan. Apabila ahli pasukan bersetuju secara lisan untuk "tambahan kecil sahaja," tambahan itu jarang kekal kecil. Dan tanpa log, tiada cara untuk menjejak bila projek itu diam-diam berkembang melebihi belanjawan asalnya. Lihat bagaimana ini berlaku secara terperinci di /ms/libraries/project-management/scope-creep.

Akauntabiliti hilang. Jika perubahan menyebabkan jadual tersasar tiga minggu, siapa yang meluluskannya? Tanpa rekod bertulis, tuduhan menggantikan penyelesaian masalah.

Anggaran kos runtuh. Setiap perubahan yang tidak dicatat boleh menambah jam yang tidak dilindungi oleh belanjawan. Darabkan itu merentas projek enam bulan dan lebihan perbelanjaan menjadi ketara.

Hubungan terjejas. Pelanggan dan penaja yang merasakan perubahan dibuat tanpa input mereka cepat kehilangan kepercayaan.

Proses kawalan perubahan yang dijalankan dengan baik memberikan kesan yang sebaliknya: ia memberikan keyakinan kepada pihak berkepentingan bahawa permintaan mereka didengari, dinilai dengan adil, dan dikendalikan secara konsisten tanpa mengira siapa yang bertanya.

Kesilapan kawalan perubahan yang biasa

Walaupun pasukan yang mempunyai proses formal melakukan kesilapan yang boleh dielakkan.

1. Menganggap setiap permintaan sebagai mendesak. Tidak semua perubahan memerlukan keputusan esok hari. Kategorikan permintaan mengikut keutamaan supaya pasukan tidak meninggalkan segala-galanya untuk permintaan yang tidak memberi impak besar.

2. Melangkau penilaian impak. Meluluskan perubahan skop tanpa memeriksa kesannya ke atas jadual dan belanjawan adalah cara terpantas untuk merosakkan kedua-duanya.

3. Menghalakan perubahan kepada pemberi kelulusan yang salah. Penambahbaikan dokumentasi kecil tidak memerlukan mesyuarat penuh Lembaga Kawalan Perubahan. Takrifkan ambang kelulusan terlebih dahulu supaya perubahan kecil bergerak dengan cepat dan perubahan besar mendapat penelitian yang sewajarnya.

4. Terlupa mengemas kini pelan projek. Perubahan hanya selesai apabila piagam projek, jadual, dan garis dasar belanjawan mencerminkan pengubahsuaian yang diluluskan. Ramai pasukan meluluskan perubahan kemudian lupa untuk memfailkan kertas kerjanya.

5. Menutup gelung secara lisan. Memberitahu pemohon "ya, kami akan melakukannya" tidak mencukupi. Hantar pengesahan bertulis supaya ada rekod bila perubahan diluluskan dan apa yang dipersetujui.

6. Tiada borang yang konsisten. Apabila semua orang menyerahkan permintaan perubahan secara berbeza (e-mel, Slack, nota melekat), pengulas membuang masa mengumpul maklumat asas sebelum mereka boleh memulakan penilaian.

Cara membina proses kawalan perubahan

Langkah-langkah di bawah terpakai untuk kebanyakan jenis projek. Sesuaikan bilangan pengulas dan ambang kelulusan dengan saiz dan toleransi risiko pasukan anda.

Langkah 1: Serahkan permintaan perubahan

Sesiapa sahaja dalam projek atau kumpulan pihak berkepentingan harus dapat menyerahkan permintaan perubahan menggunakan borang standard (lihat bahagian templat di bawah). Borang itu merakam apa yang diminta, mengapa, dan apa yang berlaku jika ia tidak dilakukan. Memerlukan borang bertulis menapis permintaan yang tidak dipertimbangkan dengan baik dan memberikan pengulas titik permulaan yang konsisten.

Langkah 2: Rekodkannya dalam daftar perubahan

Pengurus projek merekodkan setiap permintaan yang masuk dalam daftar perubahan pusat, tanpa mengira sama ada ia akan diluluskan. Setiap entri mendapat ID unik, tarikh diterima, status, dan pemilik. Log ini menjadi input kepada log RAID sebagai sumber isu dan keputusan projek.

Langkah 3: Nilai impak

Ini adalah langkah paling penting. Pengurus projek, dengan input daripada ketua yang berkaitan, menilai bagaimana perubahan yang dicadangkan memberi kesan kepada:

• Skop: Kerja baharu apa yang ditambah atau dibuang?
• Jadual: Berapa hari yang ditambah atau dikurangkan?
• Kos: Apakah impak belanjawan?
• Sumber: Adakah orang atau alatan tambahan diperlukan?
• Risiko: Adakah perubahan itu memperkenalkan risiko baharu atau menyelesaikan risiko sedia ada?
• Kualiti: Adakah ia mempengaruhi piawaian penghantaran?

Dokumentasikan penilaian secara bertulis. Ini menjadi asas bagi keputusan kelulusan.

Langkah 4: Semak dan luluskan melalui Lembaga Kawalan Perubahan

Lembaga Kawalan Perubahan (CCB) ialah kumpulan, sering pengurus projek, penaja, dan ketua teknikal utama, yang menyemak permintaan perubahan yang telah dinilai dan mengeluarkan keputusan formal: diluluskan, ditolak, atau ditangguhkan. Untuk projek yang lebih kecil, ini mungkin satu pemberi kelulusan sahaja berbanding sebuah jawatankuasa.

Keputusan CCB, berserta rasionalnya, dimasukkan ke dalam daftar perubahan. Permintaan yang ditolak didokumentasikan dengan berhati-hati sama seperti yang diluluskan, kerana "mengapa kami tidak melakukan itu" sering menjadi konteks yang berharga kemudian.

Langkah 5: Laksanakan dan sahkan

Sebaik sahaja diluluskan, perubahan ditugaskan kepada ahli pasukan yang sesuai dengan tarikh penyiapan sasaran. Pelan projek, pelan komunikasi, dan dokumen yang berkaitan dikemas kini untuk mencerminkan perubahan itu. Pihak berkepentingan dimaklumkan mengikut pelan komunikasi.

Selepas pelaksanaan, pengurus projek atau pengulas yang dilantik mengesahkan bahawa perubahan dilaksanakan sebagaimana yang diluluskan, bukan anggaran kasarnya.

Langkah 6: Tutup permintaan perubahan

Sebaik sahaja pelaksanaan disahkan, permintaan perubahan ditanda tutup dalam daftar. Status akhir, impak sebenar berbanding anggaran, dan sebarang pengajaran yang dipelajari direkodkan. Data penutupan ini menambah baik penilaian masa depan.

Daftar perubahan yang dijaga dengan baik berhubung terus kepada kawalan perubahan bersepadu, yang merupakan proses PMBOK yang lebih luas yang mengawal cara perubahan mengalir merentasi keseluruhan kitar hayat projek.

Templat borang permintaan perubahan

Borang standard adalah tulang belakang proses kawalan perubahan. Berikut adalah set medan yang muncul dalam kebanyakan borang permintaan perubahan yang berkesan.

Simpan borang ini di lokasi yang dikongsi supaya sesiapa sahaja dalam projek boleh mencari dan menyerahkannya tanpa perlu mencarinya. Ramai pasukan menambahkannya sebagai tab dalam dokumen pernyataan skop projek atau alat pengurusan projek mereka.

Best Practices

Takrifkan ambang sebelum projek bermula. Bersetuju terlebih dahulu tentang saiz perubahan yang perlu ke CCB penuh berbanding apa yang boleh diluluskan oleh pengurus projek sahaja. Pembahagian biasa: perubahan di bawah ambang dolar atau hari tertentu pergi ke PM; apa sahaja yang melebihi pergi ke CCB. Dokumentasikan ambang ini dalam piagam projek.

Proses setiap permintaan, termasuk yang ditolak. Merekodkan penolakan penting. Ia menunjukkan kepada pihak berkepentingan bahawa permintaan mereka dipertimbangkan, dan ia mewujudkan rekod yang mencegah permintaan yang sama timbul semula tiga minggu kemudian dengan nama yang berbeza.

Kekalkan daftar perubahan yang hidup. Daftar hanya berfungsi jika dikemas kini dengan segera. Daftar yang lapuk menimbulkan kekeliruan tentang apa yang telah diluluskan dan apa yang masih belum selesai.

Sampaikan keputusan dengan segera. Pemohon tidak perlu mengejar jawapan. Tetapkan perjanjian tahap perkhidmatan: CCB menyemak permintaan standard dalam lima hari bekerja, contohnya, dan pengurus projek menghantar pengesahan bertulis dalam masa 24 jam selepas keputusan.

Semak log perubahan dalam retrospektif projek. Corak muncul dari masa ke masa. Jika anda meluluskan 14 perubahan skop pada bulan kedua, tanya mengapa. Adakah skop asal tidak jelas? Adakah pihak berkepentingan dirujuk dengan betul pada awalnya? Corak ini memberikan maklumat kepada cara anda menulis pernyataan skop projek pada projek seterusnya.

Hubungkan daftar perubahan kepada log RAID anda. Perubahan sering mendedahkan risiko dan isu. Apabila perubahan memperkenalkan risiko baharu, ia harus muncul dalam log RAID dalam kitaran kemas kini yang sama.

Soalan lazim

Apakah tujuan Lembaga Kawalan Perubahan? CCB wujud supaya keputusan kelulusan dibuat secara konsisten oleh orang yang tepat, bukan oleh sesiapa yang kebetulan berada dalam bilik. Ia menghimpunkan pihak berkepentingan yang mempunyai kuasa, pengetahuan teknikal, dan konteks perniagaan untuk membuat keputusan yang bermaklumat tentang sama ada sesuatu perubahan berbaloi dengan kosnya.

Bagaimana permintaan perubahan berbeza daripada isu? Permintaan perubahan adalah permintaan proaktif untuk mengubah suatu aspek garis dasar projek, iaitu skop, jadual, belanjawan, atau penghantaran. Isu adalah sesuatu yang telah pun berlaku dan perlu diselesaikan. Isu kadang-kadang mencetuskan permintaan perubahan (contohnya, masalah teknikal yang memerlukan perubahan skop untuk diselesaikan), tetapi ia dijejak secara berasingan.

Bolehkah permintaan perubahan diluluskan secara lisan? Tidak dalam proses yang dijalankan dengan baik. Walaupun CCB berbincang dan membuat keputusan secara lisan, keputusan itu perlu didokumentasikan secara bertulis sebelum sesiapa bertindak ke atasnya. Kelulusan lisan adalah laluan terpantas menuju pertikaian "saya tidak ingat bersetuju dengan itu."

Siapa yang boleh menyerahkan permintaan perubahan? Kebanyakan projek menerima permintaan daripada mana-mana pihak berkepentingan: ahli pasukan, pelanggan, penaja, dan vendor. Borang itu harus boleh diakses oleh semua mereka. CCB, bukan kesenioranan pemohon, yang menentukan sama ada perubahan diluluskan.

Bagaimana kami mengendalikan perubahan yang mendesak? Takrifkan laluan segera terlebih dahulu. Untuk perubahan yang benar-benar mendesak, satu pemberi kelulusan yang dilantik (sering penaja) boleh memberi kelulusan bersyarat sementara penilaian impak penuh mengejar. Tetapi borang bertulis dan entri daftar masih perlu berlaku; ia hanya berlaku dengan lebih cepat.

Projek yang menganggap perubahan sebagai pengecualian akhirnya mengejar perluasan skop. Projek yang membina proses kawalan perubahan yang jelas ke dalam pelan dari awal kekal terkawal, memastikan pihak berkepentingan dimaklumkan, dan menyampaikan apa yang sebenarnya dipersetujui, bukan anggaran kasarnya.