Selasa, 14 Januari 2014

Manajemen Proyek dan Resiko - Bab 5 Manajemen Lingkup Proyek

Bab 5
Manajemen Lingkup Proyek

5.1 Inisiasi (Permulaan)
            Inisiasi adalah proses pemberian kuasa/hak secara formal untuk pembuatan proyek baru atau proyek yang sedang berkelanjutan kedalam fase selanjutnya. Permulaan formal ini menghubungkan proyek pada pekerjaan yang sedang berjalan untuk menunjukkan organisasi tersebut. Pada beberapa organisasi, proyek mengalami inisiasi secara formal sampai selesainya kebutuhan penaksiran, studi kelayakan, rencana awal, atau hal-hal yang bentuknya setara dari analisa itu sendiri yang inisiasinya terpisah. Beberapa tipe proyek, terutama proyek pelayanan internal dan proyek baru yang berkembang, terinisiasi secara tidak formal, dan beberapa jumlah kerja yang terbatas sudah selesai untuk mengamankan kebutuhan persetujuan inisiasi yang formal. Secara khas tipikal proyek adalah sebagai berikut :
·         Permintaan pasar
·         Kebutuhan bisnis
·         Permintaan pelanggan
·         Manfaat teknologi
·         Persyaratan hukum
·         Kebutuhan sosial
Tipikal di atas bisa dikatakan sebagai rangsangan, kesempatan, atau keperluan bisnis. Inti dari semua persyaratan adalah bahwa manajemen secara umum harus membuat keputusan tentang bagaimana untuk memberi respon / tanggapan.

5.1.1 Input ke Inisiasi
1. Deskripsi produk
Deskripsi produk mendokumentasikan karakteristikproduk atau jasa proyek yang melakukan pembuatan. Deskripsi produkumumnya akan memiliki lebih sedikit detail dalam tahap awal dan lebih rinci dalam yang kemudian sebagai karakteristik produk secara progresif diuraikan.
Deskripsi produk juga harus mendokumentasikan hubungan antara produk atau jasa yang dibuat dan kebutuhan bisnis atau stimulus lain yang memunculkan proyek. Sementara bentuk dan substansi deskripsi produk akan bervariasi , selalu harus cukup rinci untuk mendukung perencanaan proyek nanti.
Banyak proyek melibatkan satu organisasi (penjual) melakukan pekerjaan berdasarkan kontrak yang lain (pembeli). Dalam keadaan seperti itu , deskripsi produk awal biasanya diberikan oleh pembeli .

2. Rencana strategis
Semua proyek harus mendukung strategis organisasi melakukan itu tujuan rencana strategis organisasi melakukan harus dianggap sebagai faktor dalam keputusan seleksi proyek.

3. Kriteria pemilihan proyek
Kriteria pemilihan proyek biasanya didefinisikan dalam istilah manfaat dari produk proyek dan dapat mencakup rentang penuh keprihatinan manajemen mungkin (pengembalian keuangan , pembagian pasar ,persepsi publik , dll).

4. Informasi historis
Informasi sejarah tentang kedua hasil proyek seleksi keputusan sebelumnya dan kinerja proyek sebelumnya harus dipertimbangkan secara luas jika tersedia . Ketika inisiasi melibatkan persetujuan untuk tahap berikutnya dari proyek, informasi tentang hasil tahap sebelumnya sering kali kritis.

5.1.2 Alat dan Teknik untuk Inisiasi

1. Metode seleksi proyek
Metode seleksi proyek melibatkan mengukur nilai atau daya tarik kepada pemilik proyek. Metode seleksi proyek meliputi mempertimbangkan kriteria keputusan (beberapa kriteria , jika digunakan, harus dikombinasikan menjadi fungsi nilai tunggal) dan sarana untuk menghitung nilai di bawah ketidakpastian. Ini dikenal sebagai model keputusan dan metode perhitungan. Pemilihan proyek juga berlaku untuk memilih cara-cara alternatif untuk melakukan proyek. Alat optimasi dapat digunakan untuk mencari kombinasi optimal variabel keputusan. Metode seleksi proyek umumnya jatuh ke dalam salah satu dari dua kategori besar :
ٱ Manfaat pengukuran pendekatan metode komparatif, model penilaian, manfaat kontribusi, atau model ekonomi.
ٱModel optimasi,terkendala metode matematika menggunakan linear, nonlinear, dinamis, integer, dan multi-tujuan algoritma pemrograman. Metode ini sering disebut sebagai model keputusan. Model keputusan termasuk teknik umum (Pohon Keputusan, Keputusan Paksa, dan lain-lain), serta yang khusus (Analitik Hirarki Proses, Analisis Logical Framework, dan lain-lain). Menerapkan kriteria seleksi proyek yang kompleks dalam model canggih sering dianggap sebagai fase proyek terpisah.

2. Penilaian ahli
Penilaian ahli akan sering diminta untuk menilai masukan untuk proses ini. Keahlian tersebut dapat diberikan oleh setiap kelompok atau individu dengan pengetahuan atau pelatihan khusus, dan tersedia dari berbagai sumber, termasuk :
ٱ Unit lain dalam organisasi melakukan.
ٱ Konsultan.
ٱ Kepentingan, termasuk pelanggan.
ٱ Profesional dan teknis asosiasi.
ٱ Kelompok Industri.

5.1.3 Keluaran dari Inisiasi

1. Proyek charter
Sebuah project charter adalah dokumen yang secara resmi wewenang sebuah proyek. Ini harus mencakup, baik secara langsung atau dengan referensi ke dokumen lain :
·          Kebutuhan bisnis yang proyek ini dilakukan untuk mengatasi.
·          Deskripsi produk.
Piagam proyek harus dikeluarkan oleh seorang manajer eksternal untuk proyek, dan pada tingkat yang sesuai dengan kebutuhan proyek. Ini menyediakan manajer proyek dengan otoritas untuk menerapkan sumber daya organisasi untuk kegiatan proyek. Ketika sebuah proyek dilakukan di bawah kontrak, kontrak yang ditandatangani pada umumnya akan berfungsi sebagai piagam proyek untuk penjual.

2. Pengidentifikasian / Penugasan Manajer Proyek
Secara umum, manajer proyek harus diidentifikasi dan ditugaskan sebagai awal dalam proyek sebagai layak. Manajer proyek harus selalu ditugaskan sebelum dimulainya rencana pelaksanaan proyek dan sebaiknya sebelum perencanaan proyek banyak yang telah dilakukan.

3. Kendala
Kendala adalah faktor yang akan membatasi pilihan tim manajemen proyek. Misalnya, anggaran yang telah ditetapkan merupakan kendala yang sangat mungkin untuk membatasi pilihan tim mengenai ruang lingkup, staf, dan jadwal. Ketika sebuah proyek dilakukan di bawah kontrak, ketentuan kontrak umumnya akan kendala. Contoh lain adalah persyaratan bahwa produk proyek secara sosial, ekonomi, dan lingkungan yang berkelanjutan, yang juga akan berpengaruh pada lingkup proyek, staf, dan jadwal.

4. Asumsi


5.2 Perencanaan Bidang / Perencanaan Lapangan
Perencanaan ruang lingkup adalah proses progresif menguraikan dan mendokumentasikan pekerjaan proyek (lingkup proyek) yang menghasilkan produk dari proyek. Perencanaan lingkup proyek dimulai dengan input awal deskripsi produk, piagam proyek, dan definisi awal kendala dan asumsi. Perhatikan bahwa deskripsi produk menggabungkan persyaratan produk yang mencerminkan kesepakatan kebutuhan pelanggan dan desain produk yang memenuhi persyaratan produk. Output dari perencanaan lingkup adalah pernyataan lingkup dan rencana manajemen ruang lingkup, dengan detail pendukung. Pernyataan lingkup membentuk dasar bagi kesepakatan antara proyek dan pelanggan proyek dengan mengidentifikasi kedua tujuan proyek dan deliverable proyek. Tim proyek mengembangkan beberapa pernyataan lingkup yang sesuai untuk tingkat proyek dekomposisi kerja.

5.2.1 Masukan untuk Perencanaan ruang lingkup

1. Deskripsi produk
2. Proyek charter
3. Kendala
4. Asumsi

5.2.2 Alat dan Teknik Perencanaan Lingkup

1. Analisis produk
Analisis produk melibatkan mengembangkan pemahaman yang lebih baik dari produk proyek. Ini mencakup teknik seperti produk pemecahan analisis sistem rekayasa, rekayasa nilai, analisis nilai, analisis fungsi, dan quality function deployment.

2. Analisis manfaat / biaya
Analisis manfaat / biaya melibatkan estimasi berwujud dan tidak berwujud biaya (pengeluaran) dan manfaat (keuntungan) dari berbagai proyek dan alternatif produk, dan kemudian menggunakan ukuran finansial, seperti pengembalian investasi atau payback period, untuk menilai keinginan relatif dari alternatif diidentifikasi.

3. Identifikasi alternatif
Ini adalah istilah umum untuk setiap teknik yang digunakan untuk menghasilkan pendekatan yang berbeda untuk proyek. Ada berbagai teknik manajemen umum yang sering digunakan di sini, yang paling umum di antaranya adalah brainstorming dan berpikir lateral.
4. Penilaian ahli

5.2.3 Keluaran dari Perencanaan Lingkup

1. Pernyataan lingkup
Pernyataan lingkup memberikan dasar didokumentasikan untuk membuat keputusan proyek masa depan dan untuk mengkonfirmasikan atau mengembangkan pemahaman umum tentang ruang lingkup proyek antara para pemangku kepentingan. Sebagai proyek berlangsung, pernyataan ruang lingkup mungkin perlu direvisi atau disempurnakan untuk mencerminkan perubahan yang disetujui pada lingkup proyek. Pernyataan lingkup harus mencakup, baik secara langsung atau dengan referensi ke dokumen lain :
ٱ Pembenaran - Proyek bisnis perlu bahwa proyek ini dilakukan untuk mengatasi. Pembenaran proyek memberikan dasar untuk mengevaluasi pengorbanan masa depan.
ٱ Proyek produk - ringkasan singkat tentang deskripsi produk.
ٱ Proyek kiriman - daftar dari subproducts ringkasan tingkat yang pengiriman penuh dan memuaskan menandai penyelesaian proyek. Misalnya, point utama untuk proyek pengembangan perangkat lunak mungkin termasuk kode kerja komputer, user manual, dan tutorial interaktif. Ketika diketahui, pengecualian harus diidentifikasi, tapi apa pun tidak secara eksplisit dimasukkan secara implisit dikecualikan.
ٱ Tujuan - Proyek kriteria kuantitatif yang harus dipenuhi untuk proyek agar dianggap berhasil. Tujuan proyek harus menyertakan setidaknya biaya, jadwal, dan kualitas tindakan. Tujuan Proyek harus memiliki sebuah atribut (misalnya, biaya), metrik (misalnya, dolar Amerika Serikat), dan nilai mutlak atau relatif (misalnya, kurang dari 1,5 juta). Tujuan unquantified (misalnya, " kepuasan pelanggan ") memerlukan berisiko tinggi untuk keberhasilannya.

2. Mendukung detail
Mendukung detail untuk pernyataan ruang lingkup harus didokumentasikan dan terorganisir yang diperlukan untuk memfasilitasi penggunaannya oleh proses manajemen proyek lainnya. Mendukung rinci harus selalu menyertakan dokumentasi semua asumsi diidentifikasi dan kendala. Jumlah detail tambahan dapat bervariasi berdasarkan wilayah aplikasi.

3. Lingkup rencana pengelolaan
Dokumen ini menjelaskan bagaimana ruang lingkup proyek akan dikelola dan bagaimana perubahan lingkup akan diintegrasikan ke dalam proyek. Hal ini juga harus mencakup penilaian terhadap stabilitas yang diharapkan dari lingkup proyek (yaitu, bagaimana mungkin itu berubah, seberapa sering, dan seberapa banyak). Rencana pengelolaan lingkup juga harus mencakup gambaran yang jelas tentang bagaimana perubahan lingkup akan diidentifikasi dan diklasifikasikan. (Hal ini sangat sulit dan karena itu benar-benar penting - ketika karakteristik produk masih sedang diuraikan.)
Sebuah rencana manajemen ruang lingkup mungkin formal atau informal, sangat rinci atau dibingkai luas, berdasarkan pada kebutuhan proyek. Ini adalah komponen anak perusahaan dari rencana proyek.

5.3 Definisi Bidang / Lapangan
Definisi Lingkup melibatkan pengelompokan proyek besar penyampaian menjadi lebih kecil, komponen lebih mudah dikelola ke:
ٱ Meningkatkan akurasi biaya, durasi, dan sumber daya estimasi.
ٱ Tentukan dasar untuk pengukuran kinerja dan kontrol.
ٱ Memfasilitasi tugas tanggung jawab yang jelas.
Ruang lingkup definisi tepat sangat penting untuk keberhasilan proyek. "Ketika ada definisi lingkup miskin, biaya proyek akhir dapat diharapkan akan lebih tinggi karena perubahan tak terelakkan yang mengganggu irama proyek, menyebabkan pengerjaan ulang, meningkatkan waktu proyek, dan menurunkan produktivitas dan moral tenaga kerja".

5.3.1 Masukan untuk Lingkup Definisi

1. Pernyataan lingkup

2 . Kendala
Ketika sebuah proyek dilakukan di bawah kontrak, kendala didefinisikan oleh ketentuan kontrak sering pertimbangan penting selama ruang lingkup definisi.

3. Asumsi

4. Output perencanaan lainnya
Output dari proses dalam bidang pengetahuan lainnya harus ditinjau untuk dampak yang mungkin pada definisi lingkup proyek.

5. Informasi historis
Informasi sejarah tentang proyek-proyek sebelumnya harus dipertimbangkan selama ruang lingkup definisi. Informasi tentang kesalahan dan kelalaian pada proyek-proyek sebelumnya harus sangat berguna.

5.3.2 Alat dan Teknik untuk Lingkup Definisi

1. Bekerja kerusakan struktur template
Sebuah WBS (Work Breakdown Structure) dari proyek sebelumnya sering dapat digunakan sebagai template untuk sebuah proyek baru. Meskipun setiap proyek adalah unik, WBS sering bisa " kembali " karena sebagian besar proyek akan menyerupai proyek lain sampai batas tertentu. Sebagai contoh, sebagian besar proyek dalam suatu organisasi akan memiliki siklus hidup proyek yang sama atau serupa, dan dengan demikian akan memiliki kiriman yang sama atau serupa yang diperlukan dari setiap tahap.

Banyak daerah aplikasi atau organisasi yang melakukan WBSs memiliki standar atau semistandard yang dapat digunakan sebagai template. Misalnya, Departemen Pertahanan AS telah merekomendasikan standar WBSs Pertahanan Produk Bahan (MIL - HDBK - 881).

2. Penguraian
Dekomposisi melibatkan pengelompokan proyek besar penyampaian atau subdeliverable menjadi lebih kecil, komponen lebih mudah ditangani sampai kiriman didefinisikan secara cukup rinci untuk mendukung pengembangan kegiatan proyek (perencanaan, pelaksanaan, pengendalian, dan penutupan). Dekomposisi melibatkan langkah-langkah utama berikut :
(1) Mengidentifikasi penyerahan utama proyek, termasuk manajemen proyek. Point utama harus selalu didefinisikan dalam hal bagaimana proyek benar-benar akan diselenggarakan. Sebagai contoh:
ٱ Para fase siklus hidup proyek dapat digunakan sebagai tingkat pertama dari dekomposisi dengan deliverable proyek diulangi pada tingkat kedua.
ٱ Prinsip pengorganisasian dalam setiap cabang WBS dapat bervariasi.

(2) Putuskan apakah biaya yang memadai dan perkiraan durasi dapat dikembangkan pada tingkat detail untuk setiap deliverable. Arti dari memadai dapat berubah selama proyek - dekomposisi dari deliverable yang akan diproduksi jauh di masa depan mungkin tidak dapat dilakukan. Untuk setiap deliverable, lanjutkan ke Langkah 4 jika ada detail yang memadai, ke Langkah 3 jika tidak ada - ini berarti bahwa kiriman yang berbeda mungkin telah tingkat dekomposisi berbeda.

(3) Mengidentifikasi komponen konstituen dari deliverable. Komponen-komponen penyusun harus dijelaskan dalam hal yang nyata, hasil diverifikasi untuk memudahkan pengukuran kinerja. Seperti dengan komponen utama, komponen-komponen penyusun harus didefinisikan dalam hal bagaimana pekerjaan proyek benar-benar akan diselenggarakan dan pekerjaan proyek dilakukan. Nyata, hasil diverifikasi dapat mencakup layanan serta produk (misalnya, pelaporan statusnya bisa digambarkan sebagai laporan status mingguan, untuk item diproduksi, komponen konstituen mungkin termasuk beberapa komponen individual ditambah perakitan akhir). Ulangi Langkah 2 pada setiap komponen penyusunnya.
(4) Verifikasi kebenaran dekomposisi :
ٱ Apakah item - tingkat yang lebih rendah perlu dan cukup untuk menyelesaikan item membusuk? Jika tidak, komponen-komponen penyusun harus dimodifikasi (ditambahkan, dihapus dari, atau didefinisikan ulang).
ٱ Apakah setiap item jelas dan lengkap didefinisikan? Jika tidak, deskripsi harus direvisi atau diperluas.
ٱ Dapatkah setiap item secara tepat dijadwalkan? Anggaran? Ditugaskan ke unit organisasi tertentu (misalnya, departemen, tim, atau orang) yang akan menerima tanggung jawab untuk penyelesaian yang memuaskan dari barang? Jika tidak, revisi diperlukan untuk memberikan kontrol manajemen yang memadai.

5.3.3 Keluaran dari Lingkup Definisi

1. Struktur rincian kerja
Sebuah WBS adalah pengelompokan berorientasi deliverable komponen proyek yang mengatur dan mendefinisikan total lingkup proyek, bekerja tidak di WBS berada di luar lingkup proyek. Seperti pernyataan ruang lingkup, WBS sering digunakan untuk mengembangkan atau mengkonfirmasi pemahaman umum tentang ruang lingkup proyek. Setiap tingkat turun mewakili deskripsi semakin rinci deliverable proyek. Bagian 5.3.2.2 menggambarkan pendekatan yang paling umum untuk mengembangkan WBS. Sebuah WBS biasanya disajikan dalam bentuk grafik, seperti digambarkan pada Gambar 5-2, 5-3, dan 5-4, namun WBS tidak harus bingung dengan metode presentasi - menggambar daftar kegiatan terstruktur dalam bentuk grafik tidak membuat WBS.
Setiap item dalam WBS umumnya diberi pengenal unik, pengidentifikasi ini dapat memberikan struktur untuk penjumlahan hirarkis biaya dan sumber daya. Item pada tingkat terendah dari WBS dapat disebut sebagai paket pekerjaan, terutama dalam organisasi yang mengikuti praktek-praktek manajemen nilai yang diterima. Paket-paket pekerjaan pada gilirannya akan lebih terurai dalam struktur rincian kerja proyek. Umumnya, jenis pendekatan yang digunakan ketika manajer proyek menetapkan lingkup pekerjaan ke organisasi lain, dan organisasi lainnya harus merencanakan dan mengelola ruang lingkup kerja di tingkat yang lebih rinci dibandingkan dengan manajer proyek dalam proyek utama. Paket-paket pekerjaan selanjutnya dapat didekomposisi dalam rencana proyek dan jadwal, seperti yang dijelaskan dalam Bagian 5.3.2.2 dan 6.1.2.1.
Deskripsi komponen kerja sering dikumpulkan dalam WBS kamus. Sebuah WBS kamus biasanya akan mencakup deskripsi paket pekerjaan, serta informasi perencanaan lain seperti tanggal jadwal, anggaran biaya, dan tugas staf. WBS tidak harus bingung dengan jenis lain dari "gangguan" struktur yang digunakan untuk menyajikan informasi proyek. Struktur lain yang umum digunakan di beberapa area aplikasi meliputi:
ٱ Kontrak WBS (CWBS), yang digunakan untuk menentukan tingkat melaporkan bahwa penjual akan memberikan pembeli. Para CWBS umumnya termasuk kurang detail dibandingkan WBS digunakan oleh penjual untuk mengelola pekerjaan penjual.
ٱ struktur rincian Organisasi (OBS), yang digunakan untuk menunjukkan komponen kerja telah ditetapkan ke unit organisasi.
ٱ Sumberdaya struktur rincian (RBS), yang merupakan variasi dari OBS dan biasanya digunakan ketika komponen pekerjaan yang ditugaskan untuk individu.
ٱ Bill of material (BOM), yang menyajikan pandangan hirarkis dari majelis fisik, subassemblies, dan komponen yang dibutuhkan untuk membuat sebuah produk manufaktur.
ٱ struktur rincian proyek (PBS), yang pada dasarnya sama dengan WBS dilakukan dengan benar. Istilah PBS banyak digunakan dalam area aplikasi mana WBS istilah salah digunakan untuk merujuk kepada BOM.

2. Update pernyataan lingkup
Sertakan modifikasi dari isi pernyataan ruang lingkup (dijelaskan dalam Bagian 5.2.3.1). Pemangku kepentingan yang tepat harus diberitahu sesuai kebutuhan.


5.4 Verifikasi Bidang / Lapangan
Verifikasi Lingkup adalah proses mendapatkan penerimaan formal dari ruang lingkup proyek oleh para pemegang jabatan penting (sponsor, klien, pelanggan, dll). Hal ini membutuhkan peninjauan pengiriman dan hasil kerja untuk memastikan bahwa semua telah dilakukan dengan benar dan memuaskan. Jika proyek ini dihentikan lebih awal, proses verifikasi lingkup harus menetapkan dan mendokumentasikan tingkat dan tingkat penyelesaian. Lingkup verifikasi berbeda dari kontrol kualitas terutama berkaitan dengan penerimaan hasil kerja sementara kontrol kualitas terutama berkaitan dengan kebenaran hasil kerja. Proses ini umumnya dilakukan secara paralel untuk memastikan baik kebenaran dan penerimaan.

5.4.1 Masukan untuk Lingkup Verifikasi

1. Hasil kerja
Hasil kerja yang pengirimannya telah sepenuhnya atau sebagian selesai adalah output rencana pelaksanaan proyek.
2. Dokumentasi produk
Dokumen yang dihasilkan untuk menggambarkan produk proyek harus tersedia untuk dapat diperiksa. Istilah yang digunakan untuk menggambarkan dokumentasi ini (rencana, spesifikasi, dokumentasi teknis, gambar, dll) bervariasi berdasarkan wilayah aplikasi.

3. Struktur rincian kerja
WBS membantu dalam definisi ruang lingkup, dan harus digunakan untuk memverifikasi pekerjaan proyek.
4. Pernyataan lingkup
Pernyataan lingkup mendefinisikan ruang lingkup dengan detail dan harus diverifikasi.
5. Rencana proyek
Rencana proyek dijelaskan pada Bagian 4.1.3.1.

5.4.2 Alat dan Teknik untuk Lingkup Verifikasi

1. Inspeksi
Pemeriksaan meliputi kegiatan seperti mengukur, memeriksa, dan pengujian dilakukan untuk menentukan apakah hasil memenuhi persyaratan. Ada istilah lain dari inspeksi yaitu : ulasan, review produk, audit, dan penelusuran, dalam beberapa area aplikasi, istilah-istilah yang berbeda memiliki arti yang sempit dan spesifik.

5.4.3 Keluaran dari Lingkup Verifikasi

1. Penerimaan formal
Dokumentasi bahwa klien atau sponsor telah menerima produk dari fase proyek atau penyampaian utama harus disiapkan dan didistribusikan. Penerimaan tersebut mungkin bersyarat, terutama pada akhir fase.


5.5 Pengawasan Perubahan Bidang / Lapangan
Pengendalian perubahan lingkup yang bersangkutan dengan
a) mempengaruhi faktor-faktor yang menciptakan perubahan ruang lingkup untuk memastikan bahwa perubahan yang disepakati
b) menentukan bahwa perubahan lingkup telah terjadi
c) mengelola perubahan yang sebenarnya ketika terjadi perubahan. Pengendalian perubahan lingkup harus benar-benar terintegrasi dengan proses kontrol lainnya.

5.5.1 Masukan untuk Pengendalian Perubahan Lingkup

1. Struktur rincian kerja

2. Laporan kinerja
Laporan kinerja, memberikan informasi tentang kinerja lingkup, seperti yang kiriman sementara telah selesai dan yang belum. Laporan kinerja juga dapat mengingatkan tim proyek untuk menjegah masalah  yang dapat menyebabkan masalah di masa depan.

3. Perubahan permintaan
Perubahan permintaan dapat terjadi dalam berbagai bentuk, yaitu bisa dalam bentuk lisan atau tertulis, langsung atau tidak langsung, eksternal atau internal dimulai, dan mandat hukum atau opsional. Perubahan mungkin memerlukan perluasan lingkup atau memungkinkan menyusut itu.

Kebanyakan permintaan perubahan adalah hasil dari :
ٱ Peristiwa eksternal (misalnya, perubahan dalam peraturan pemerintah).
ٱ Suatu kesalahan atau kelalaian dalam mendefinisikan ruang lingkup produk (misalnya, kegagalan untuk menyertakan fitur yang diperlukan dalam desain sistem telekomunikasi).
ٱ Sebuah kesalahan atau kelalaian dalam mendefinisikan lingkup proyek (misalnya, menggunakan BOM bukan sebuah WBS).
ٱ Sebuah nilai tambah perubahan (misalnya, sebuah proyek rehabilitasi lingkungan dapat mengurangi biaya dengan memanfaatkan teknologi yang tidak tersedia ketika lingkup awalnya didefinisikan).
ٱ Mengimplementasikan rencana kontingensi atau rencana solusi untuk menanggapi risiko.

4 . Lingkup rencana pengelolaan


5.5.2 Alat dan Teknik untuk Pengendalian Perubahan Lingkup

1. Pengendalian perubahan lingkup
Sebuah pengendalian perubahan lingkup mendefinisikan prosedur dimana lingkup proyek dapat diubah. Ini termasuk dokumen, sistem pelacakan, dan tingkat persetujuan yang diperlukan untuk perubahan kekuasaan. Kontrol lingkup perubahan harus diintegrasikan dengan kontrol perubahan yang terintegrasi dan khususnya dengan sistem atau sistem untuk mengontrol lingkup produk. Ketika proyek ini dilakukan di bawah kontrak, pengendalian perubahan lingkup juga harus mematuhi semua ketentuan kontrak yang relevan.

2. Pengukuran kinerja
Teknik pengukuran kinerja, membantu untuk menilai besarnya setiap variasi yang memang terjadi. Menentukan apa yang menyebabkan varians relatif terhadap baseline dan memutuskan apakah varians membutuhkan tindakan korektif adalah bagian penting dari pengendalian perubahan lingkup.

3. Perencanaan tambahan
Beberapa proyek berjalan tepat sesuai rencana, yang membuat perubahan lingkup mungkin memerlukan modifikasi WBS atau analisis alternatif pendekatan.


5.5.3 Output dari Lingkup Pengendalian Perubahan

1. Perubahan lingkup
Perubahan lingkup adalah setiap modifikasi yang disepakati lingkup proyek seperti yang didefinisikan oleh WBS disetujui. Perubahan lingkup sering membutuhkan penyesuaian biaya, waktu, kualitas, atau tujuan proyek lainnya. Perubahan lingkup proyek diumpankan kembali melalui proses perencanaan, teknis dan dokumen perencanaan diperbarui sesuai kebutuhan, dan pemangku kepentingan akan diberitahu sesuai.

2. Tindakan korektif
Tindakan korektif adalah segala sesuatu yang dilakukan untuk membawa harapan kinerja proyek pada masa depan sejalan dengan rencana proyek.

3. Pelajaran yang dipetik
Penyebab penyimpangan, alasan di balik tindakan korektif yang dipilih, dan jenis-jenis pelajaran dari pengendalian perubahan lingkup harus didokumentasikan, sehingga informasi ini menjadi bagian dari database historis untuk kedua proyek ini dan proyek lain dari organisasi pertunjukan.

4. Dasar yang disesuaikan

Tergantung pada sifat perubahan, dokumen dasar yang sesuai dapat direvisi dan diterbitkan kembali untuk mencerminkan perubahan disetujui dan membentuk dasar baru untuk perubahan masa depan.



Amelia Maryam N S - 20112703
Novita Ristyana - 22112423
2KB05 - Sistem Komputer
Universitas Gunadarma
2013-2014

Tidak ada komentar:

Posting Komentar