Prince2 Configuration Management and Change Control

Saya ingat, bertahun-tahun yang lalu, menghadiri kursus pelatihan pertama saya tentang Kualitas. Manajemen tidak bisa mendapatkan cukup banyak orang untuk hadir, jadi mereka menyuap mereka dengan kalkulator ilmiah gratis (saat itu bernilai sekitar $ 200) – jadi saya hadiri.

Sejujurnya, saya menemukan itu jauh lebih menarik daripada yang saya harapkan.

Setelah makan siang pada hari kedua, mereka berbicara dengan ahli tentang Manajemen Konfigurasi.

Yah, dia benar-benar tahu barang-barangnya – tapi aku datang jauh sambil berpikir bahwa CM agak 'akademis'.

Seberapa Salahkah Saya? Manajemen Konfigurasi adalah KRITIS BISNIS!

Aku serius. Apakah Anda membeli mobil lain dari dealer Anda jika mereka tidak diatur dengan alat yang tepat untuk melayani mobil Anda?

Bagaimana kalau mereka memasang suku cadang yang salah? Atau jika Manual memiliki kesalahan di dalamnya?

Ada cerita terkenal tentang Space Shuttle menimbulkan biaya ekstra besar karena pemasok Eropa menggunakan sistem metrik dan Amerika Serikat menggunakan pengukuran Imperial. Kesalahan toleransi dibangun dan bagian-bagiannya tidak cocok dengan benar.

Ubah Manajemen Konfigurasi akan menghentikan itu terjadi, dan itu akan membantu menemukan masalah seperti itu jauh lebih awal.

Mari kita bicara tentang kontrol perubahan dalam Prince2

Perubahan biasanya datang dalam tiga kategori:

Request For Change (RFC). Ini biasanya permintaan dari pelanggan atau pengguna yang meminta perubahan dari yang semula diminta.

Ini mungkin merupakan perubahan terhadap persyaratan, spesifikasi, kriteria penerimaan, atau ruang lingkup – atau semua atau pekerjaan ulang – atau menerima beberapa bentuk pengurangan harga.

Kategori terakhir adalah yang umum. dicadangkan untuk setiap masalah umum, pengamatan atau kekhawatiran (misalnya, insinyur desain saya telah mengundurkan diri!).

Semua hal di atas dapat dilihat sebagai kategori yang berbeda dari suatu Isu.

Jadi apa itu Manajemen Konfigurasi? Yah itu pada dasarnya sebuah

kelompok layanan internal dengan sumber daya, peralatan, prosedur, dan sistem untuk mengontrol berbagai versi produk (yang dapat diserahkan) proyek.

Setiap produk disebut "Aset". Nama untuk kumpulan aset-aset ini disebut konfigurasi.

Dan konfigurasi produk akhir proyek adalah jumlah dari bagian-bagiannya.

Jadi mengapa kita harus peduli menggunakan CM?

Perubahan pada proyek Anda AKAN terjadi – jadi bersiaplah untuk itu. Saya sedang berbicara tentang Manajemen Perubahan, yang dengan cara, harus berada di bawah sayap CM.

Jadi ketika perubahan terjadi, proyek Anda akan berakhir dengan beberapa versi suatu produk.

Jika Anda tidak memiliki pelacakan dan pengetahuan yang tepat tentang versi ini, apa yang diubah, dan mengapa itu berubah, maka proyek Anda akan berakhir dalam kekacauan.

Misalkan Anda seorang insinyur desain, dan seorang rekan meminta Anda untuk salinan dokumen spesifikasi karena mereka akan merancang sesuatu dari itu.

Bagaimana jika Anda telah mengubah dokumen dengan cara tertentu karena sudah disetujui – mungkin karena Anda bisa melihat itu adalah perbaikan?

Rekan Anda sekarang mendesain terhadap spesifikasi yang berbeda ini untuk spesifikasi yang digunakan orang lain – dan produknya tidak berfungsi atau sesuai dengan desain lain dari sistem yang sama. Kekacauan berkuasa.

Bagaimana dengan ini. Klien berbunyi dan mengatakan bahwa mereka menggunakan versi lama dari salah satu produk Anda (karena itu kompatibel dengan sisa sistem mereka), dan dapatkah Anda membuat lebih banyak lagi untuk mereka sebagai pesanan khusus khusus, silakan?

Anda mengatakan 'tidak masalah' – Anda pergi ke toko desain Anda hanya untuk menemukan bahwa mereka telah kehilangan gambar – lebih buruk lagi, desainer pensiun tahun lalu.

Anda akan memiliki masalah yang sama jika pelanggan mengatakan ada kesalahan desain, dan dapatkah Anda memperbaikinya, atau jika pelanggan menginginkan modifikasi berdasarkan desain lama.

Dan masalah yang sama bisa terjadi jika Anda menjalankan perusahaan 'layanan'.

Apakah staf Anda menggunakan alat, prosedur, dan panduan yang tepat?

Apakah mereka dilatih untuk menyediakan layanan itu?

Izinkan saya bertanya – apakah manajemen senior memiliki serangkaian rencana bisnis berdasarkan serangkaian arahan strategis? Dan apakah bagian-bagian yang berbeda dari perusahaan mendasarkan rencana operasional mereka pada dokumen-dokumen ini?

Sheesh! Saya yakin semoga mereka semua menggunakan versi yang benar dari hal-hal ini …

Oke, mari kembali ke proyek Anda, dan bagaimana CM akan membantu.

Saya harap saya meyakinkan Anda bahwa CM harus menjadi perlengkapan permanen di organisasi Anda dan bukan hanya dibentuk oleh dan selama, sebuah proyek (karena produk akhir harus dipertahankan selama hidup mereka).

Orang yang menyediakan layanan CM disebut Configuration Librarian. Ya, aku tahu, kedengarannya agak kuno – tapi jangan biarkan itu membuatmu pergi. Peran ini juga bisa disebut Administrator Konfigurasi.

Beginilah cara mereka dapat membantu proyek Anda:

1. CM memiliki pustaka lengkap dari semua item yang pernah diproduksi di organisasi Anda (termasuk apa pun yang telah 'dibeli' dari pihak ketiga).

Di zaman modern, catatan-catatan ini mungkin akan disimpan dalam database semacam itu. Di masa lalu mereka akan disimpan dalam bentuk hard copy dalam sistem pengarsipan tradisional.

2. Masing-masing catatan ini akan memiliki informasi yang menyatakan siapa yang mendapat apa, di mana informasi itu disimpan, dan mengapa.

Rekaman ini juga akan menyimpan detail dari setiap perubahan yang dibuat.

3. Perpustakaan juga akan menyimpan salinan utama berbagai versi produk dasar.

Jika Anda bekerja untuk organisasi kecil dan menjalankan proyek-proyek sederhana kecil, maka Anda akan berharap cara CM dilakukan menjadi kecil dan sederhana juga. Selama Anda memiliki kendali atas semua versi semua produk dan layanan Anda.

Berikutnya, saya ingin menjelaskan layanan apa yang bisa diberikan CM Library ke proyek Anda.

Ini adalah tanggung jawab manajer proyek untuk memastikan bahwa CM digunakan dengan benar oleh proyek.

Untuk membantu memastikan ini terjadi, Rencana CM dapat dibuat.

Catatan. Untuk proyek kecil dan sederhana, rencananya mungkin hanya berupa daftar poin untuk didiskusikan dan disetujui oleh CM.

Rencana dapat menjadi bagian dari perencanaan kualitas apa pun atau dimasukkan dalam Rencana Proyek.

Lakukan apa yang masuk akal – tetapi di sini adalah area yang harus dicakup:

Narasi singkat menjelaskan metode konfigurasi apa yang akan digunakan (atau referensi sederhana ke sistem 'biasa'.

Standar perusahaan apa yang akan digunakan (atau mengapa mereka akan bervariasi dalam beberapa cara).

Kaitan dengan sistem manajemen konfigurasi lainnya (atau alat apa pun) yang akan digunakan. Contohnya mungkin pihak ketiga yang berkontribusi produk ke proyek.

Bagaimana dan di mana produk akan disimpan. Apakah mereka hanya dokumen?

Atau apakah mereka item fisik lain – dalam hal mana mereka akan dipasang di situs pelanggan, atau disimpan di tempat lain, seperti gudang berikat.

Bagaimana pengajuan akan dilakukan, dan bagaimana prosesnya

untuk pengambilan aman?

Apa bentuk kontrol versi yang digunakan – jelaskan bagaimana mereka

akan diidentifikasi.

Siapa di dalam proyek dan di luar itu

bertanggung jawab untuk menerapkan manajemen konfigurasi?

The Configuration Librarian akan menyediakan LIMA

mengikuti layanan untuk setiap proyek yang diberikan:

1. Perencanaan. Bekerja dengan manajer proyek, untuk menetapkan tingkat detail apa yang diperlukan (ini tergantung pada kompleksitas konfigurasi total produk akhir).

2. Identifikasi. Menyetujui produk apa yang akan berada di bawah kendali konfigurasi (misalnya, Rencana Proyek mungkin tidak disertakan, selama manajer proyek memiliki sistem 'off-line' sederhana untuk menjaganya di bawah kontrol versi mereka sendiri).

3. Kontrol. Prosedur untuk 'membekukan' baseline produk dan membawa mereka di bawah kendali perpustakaan CM.

Pembekuan berarti tidak ada perubahan yang diizinkan pada produk tanpa tingkat otoritas yang tepat (misalnya sponsor proyek).

Ada titik lain untuk dibawa ke sini.

Ikuti perkembangan sepeda gunung baru.

Satu orang sedang mendesain roda, yang lain sedang mengembangkan frame, yang lain lagi, sistem gearing.

Karena masing-masing melalui banyak versi desain yang lain perlu memastikan seluruh konfigurasi sepeda tetap 'selaras'.

Database CM akan mengenali keterkaitan tersebut dan mengingatkan tim (melalui laporan seperti yang dijelaskan nanti dalam artikel ini); hubungan masing-masing produk harus satu sama lain.

4. Akuntansi Status. Ini adalah basis data CM untuk pencatatan dan pelaporan semua produk.

Ini kembali ke sejarah ke versi pertama, dan semua jalan hingga ke versi saat ini. Data ini dapat diberikan kepada manajer proyek pada titik-titik kunci, seperti tinjauan tahap akhir sebagai bukti akurat dari status sebenarnya pada semua produk proyek.

5. Verifikasi. CM memberikan tinjauan dan audit untuk memastikan bahwa tim proyek menggunakan versi dokumen yang benar dan produk lainnya selama proyek (dan bahwa mereka cocok dengan salinan 'master' seperti yang disimpan di perpustakaan).

Ini harus dilihat sebagai layanan – bukan sebagai 'polisi manajemen'!

Akhirnya, ada dua laporan penting yang akan digunakan manajer proyek dari CM Librarian:

1. Rekaman Konfigurasi. Ini adalah catatan semua informasi yang diperlukan tentang setiap status produk, dan termasuk; nomor versi terbaru, yang membuat produk, tempat produk disimpan / disimpan, dan apa statusnya.

2. Akun Status Produk. Ini adalah laporan (biasanya diminta oleh manajer proyek pada titik-titik peninjauan utama), dan memberikan informasi tentang keadaan semua produk dalam jangka waktu tertentu (misalnya, "beri saya laporan tentang semua produk dan statusnya yang telah dibuat selama tahap proyek saat ini "

PSA akan, untuk setiap produk dalam jangka waktu itu, berisi data seperti kapan setiap produk adalah dasar dan kapan perubahan disetujui.

Berikut adalah sinopsis singkat poin-poin penting dalam proyek Prince2 ketika Manajemen Konfigurasi digunakan:

Kualitas Perencanaan.

Rencana Manajemen Konfigurasi dibuat, sebelum

pengembangan Rencana Proyek. Manajer Proyek untuk berhubungan dengan Pustakawan Konfigurasi untuk mendiskusikan bagaimana proyek akan menggunakan / bekerja dengan Sistem Manajemen Konfigurasi (CM) mereka.

Menyiapkan File Proyek

Mengambil informasi dari Rencana Proyek, dan menambahkan struktur pengarsipan proyek ke dalam Rencana Manajemen Konfigurasi. Sistem CM mungkin sudah memiliki fasilitas ini.

Paket Kerja Otorisasi (WP) / memberikan pekerjaan kepada tim

Perbarui Configuration Item Record ke "under development" Configuration Librarian akan melakukan ini.

Pastikan WP berisi informasi mengenai bagaimana kontrol versi akan bekerja untuk pengembang, memperoleh salinan produk atau deskripsi produk, menyerahkan Pustakawan Konfigurasi, dan menyampaikan informasi status produk.

Menilai Kemajuan Proyek.

Menangkap "actual" dan memperbarui status produk Configuration Item Record (CIR). Konfigurasi Pustakawan dapat menyediakan Akun Status Produk (PSA) jika diperlukan.

Menangkap dan Memeriksa Isu / Perubahan Proyek

Pustakawan Konfigurasi dapat menerima / mendokumentasikan semua Perubahan / Masalah serta memelihara Log Perubahan / Masalah.

Mengambil Tindakan Korektif.

Ketika setiap perubahan harus dibuat, Pustakawan Konfigurasi membuat produk atau salinannya tersedia, tambahkan salinan baru yang diberikan ke CIR, dan perbarui CIR untuk setiap perubahan status.

Menerima Paket Kerja Selesai (ketika tim telah menyelesaikan setiap produk / yang dapat dikirimkan)

Konfigurasi Pustakawan untuk memperbarui CIR ke status 'selesai'.

Produk sekarang sudah menjadi dasar jika belum selesai.

Sebagai produk / kiriman yang dilengkapi Tim Spesialis untuk menyarankan Pustakawan Konfigurasi untuk memperbarui

Status CIR dari setiap produk.

Melengkapi Paket Kerja.

Konfigurasi Pustakawan untuk menangani pengembalian produk yang sudah selesai (jika sesuai), dan untuk membantu Jaminan Proyek dalam mengonfirmasi penerimaan pelanggan / pengguna produk.

Laporan Manajemen Reguler

Pustakawan Konfigurasi dengan bantuan Jaminan Proyek untuk mengkonfirmasi CIR sama dengan status produk sebenarnya dengan melakukan Audit Konfigurasi.

Periksa juga bahwa nomor versi sudah benar / diperbarui.

Replanning sebagai hasil dari perubahan.

Pustakawan Konfigurasi akan memberikan Status Produk Akun produk untuk diganti / tidak lengkap.

CIR baru dibuat jika diperlukan.

Menutup Proyek.

CIR diperiksa kelengkapannya, dan digunakan sebagai masukan

Status Produk Akun – konfirmasi dari catatan konfigurasi manajemen pelanggan bahwa semua produk disetujui.

Lihat pada Rencana Manajemen Konfigurasi untuk bagaimana produk diserahkan kepada mereka yang memiliki dukungan / tanggung jawab operasional.

Lakukan Audit Konfigurasi untuk memeriksa bahwa semua produk disetujui dan mematuhi CIR mereka.

Selama Perencanaan Proyek.

Configuration Item Record dibuat dengan mengacu pada Rencana Manajemen Konfigurasi.

Sistem penomoran sederhana untuk setiap produk dapat disusun sebagai: nama proyek / jenis produk / nama produk / sumber / status / nomor versi

Jadi misalnya, jika ada proyek untuk membuat PC notebook baru, dan sistem penomoran unik seperti di atas digunakan untuk hard drive yang dibeli dari pihak ke-3:

Proyek / perangkat keras / hard drive / eksternal / pengembangan / vA.2 baru

Berikut ini panduan rinci tentang informasi yang dibutuhkan dalam

dokumen yang dimaksud dalam artikel ini:

Rencana Pengelolaan Konfigurasi.

– Metode CM yang akan digunakan

– Tautan ke sistem atau alat CM lainnya

– Di mana dan bagaimana produk disimpan

– pengaturan keamanan untuk pengarsipan dan pengambilan

– Identifikasi dan penomoran untuk

produk / versi

– Siapa yang bertanggung jawab untuk CM

Rekaman Item Konfigurasi.

– Pengidentifikasi Unik Proyek

– Jenis produk (web, perangkat keras, dll)

– Nama Produk

– Nomor versi terbaru

– Keterangan lengkap tentang produk

– Langkah Siklus Hidup untuk produk (ie.draft,

disetujui, dalam pelayanan, dll.)

– Siapa yang memiliki produk (Pengguna? Ops Manager? Dll)

– Siapa yang menciptakan produk itu?

– Tanggal yang dialokasikan untuk mereka

– Perpustakaan atau lokasi tempat disimpan

– sumber produk (internal, eksternal)

– tautan ke produk terkait (fisik, listrik,

dll)

– status (di mana dalam siklus hidup itu?

– pemegang salinan dan pengguna potensial

– referensi untuk masalah (jika ada) yang menyebabkan perubahan

ke produk ini

– korespondensi yang relevan

Akun Status Produk

– Nama Proyek

– Tipe produk

– Identifier produk

– Nomor versi

– Deskripsi produk – tanggal dasar

– Produk – tanggal dasar

– Daftar produk terkait

– Tanggal salinan produk dikeluarkan untuk perubahan

– Tanggal yang direncanakan untuk baseline berikutnya

– Tanggal yang direncanakan untuk rilis berikutnya

– Catatan yang relevan (perubahan tertunda / sedang ditinjau, dll)

Leave a Reply

Your email address will not be published. Required fields are marked *