Manajemen dalam Lingkup Proyek

Bab 5

Manajemen lingkup proyek mencakup proses-proses yang diperlukan untuk memastikan bahwa proyek tersebut mencakup semua pekerjaan yang diperlukan, dan hanya pekerjaan yang diperlukan, untuk menyelesaikan proyek dengan sukses. itu terutama berkaitan dengan mendefinisikan dan mengendalikan apa atau tidak termasuk dalam project.figure 5-1 memberikan gambaran proses manajemen proyek lingkup besar.

5.1       inisiasi mengesahkan proyek atau fase.

5.2       lingkup perencanaan-mengembangkan tertulis lingkup pernyataan sebagai  dasar untuk keputusan proyek masa depan.
5.3       Definisi-pengelompokan lingkup deliverable proyek besar menjadi lebih kecil,            komponen lebih managaeble.
5.4       lingkup verifikasi-meresmikan penerimaan lingkup proyek.
5.5       perubahan lingkup kontrol pengendali perubahan lingkup proyek.

proses berinteraksi satu sama lain dan dengan proses di bidang pengetahuan lain juga. setiap proses mungkin melibatkan usaha dari satu atau lebih individu atau kelompok individu, berdasarkan kebutuhan proyek. setiap proses umumnya terjadi setidaknya sekali dalam setiap tahapan proyek.

meskipun proses disajikan di sini sebagai komponen diskrit dengan baik didefinisikan MANAJEMEN LINGKUP PROYEKantarmuka, dalam praktiknya mereka mungkin tumpang tindih dan berinteraksi dengan cara yang tidak rinci di sini. Proses interaksi dibahas secara rinci dalam Bab 3.

dalam konteks proyek, ruang lingkup panjang mungkin merujuk kepada:

•  lingkup-Produk fitur dan fungsi yang menjadi ciri suatu produk atau jasa.
• Proyek lingkup-pekerjaan yang harus dilakukan untuk memberikan produk dengan specfitur- ified dan fungsi. Proses, peralatan, dan teknik yang digunakan untuk mengelola lingkup. fokus dari bab ini. Proses, peralatan, dan teknik yang digunakan untuk mengelola lingkup produk bervariasi berdasarkan wilayah aplikasi dan biasanya didefinisikan sebagai bagian dari siklus hidup proyek (siklus hidup proyek dibahas dalam Bagian 2.1).

Sebuah proyek umumnya menghasilkan satu produk, tapi produk yang dapat mencakupanak perusahaan komponen, masing-masing dengan produk sendiri terpisah namun saling cakupan. Sebagai contoh, sistem telepon baru umumnya akan mencakup empat sub-sidiary komponen-hardware, software, pelatihan, dan implementasi.
Penyelesaian ruang lingkup proyek diukur terhadap rencana proyek, namun completion lingkup produk diukur terhadap persyaratan produk. keduanya
jenis manajemen lingkup harus terintegrasi dengan baik untuk memastikan bahwa pekerjaanproyek ini akan mengakibatkan pengiriman produk tertentu.

5.1 Inisiasi

Inisiasi adalah proses formal otorisasi sebuah proyek baru atau bahwa ada proyek harus berlanjut ke tahap berikutnya (lihat Bagian 2.1 untuk lebih rinci diskusi tahapan proyek). Ini inisiasi resmi menghubungkan proyek keberkelanjutan bekerjanya organisasi melakukan. Dalam beberapa organisasi, proyek ini

tidak secara resmi dimulai sampai setelah selesai penilaian kebutuhan, kelayakan suatu

studi, rencana awal, atau bentuk lainnya yang dipersamakan analisis yang sendiri

secara terpisah dimulai. Beberapa jenis proyek, proyek pelayanan terutama internal dan

proyek pengembangan produk baru, yang dimulai secara informal, dan beberapa terbatas

jumlah pekerjaan yang dilakukan untuk mengamankan persetujuan yang dibutuhkan untuk inisiasi formal. proyek biasanya berwenang sebagai akibat dari satu atau lebih dari berikut ini:

• Sebuah permintaan pasar (misalnya, sebuah perusahaan mobil kewenangan sebuah proyek untuk membangun lebih hemat bahan bakar mobil dalam menanggapi kekurangan bensin).
• Sebuah kebutuhan bisnis (misalnya, sebuah perusahaan pelatihan kewenangan sebuah proyek untuk membuat yang baru

Tentu saja untuk meningkatkan pendapatan).

• Sebuah permintaan pelanggan (misalnya, sebuah utilitas listrik mengotorisasi sebuah proyek untuk membangun baru gardu untuk melayani kawasan industri baru).
• Sebuah kemajuan teknologi (misalnya, sebuah perusahaan elektronik mengotorisasi sebuah proyek baru untuk mengembangkan pemutar video game setelah kemajuan dalam memori komputer).
• Suatu persyaratan hukum (misalnya, produsen cat kewenangan proyek untuk pemlish pedoman untuk penanganan bahan beracun).
• Sebuah kebutuhan sosial (misalnya, sebuah organisasi non-pemerintah di negara berkembang wewenang proyek untuk menyediakan sistem air minum, kakus, dan sanitasipendidikan untuk masyarakat berpenghasilan rendah menderita tingkat tinggi kolera). Rangsangan ini juga dapat disebut masalah, peluang, atau bisnis memerlukan kasih. Tema sentral dari semua ketentuan ini manajemen yang umumnya harus membuat keputusan tentang bagaimana menanggapi.

5.1.1 Masukan ke Inisiasi

.1 Uraian produk. Deskripsi produk mendokumentasikan karakteristik
produk atau jasa yang proyek dilakukan untuk menciptakan. produk
deskripsi umumnya akan memiliki detail kurang dalam fase awal dan lebih rinci di kemudian
yang 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 (lihat daftar di Bagian 5.1). Sementara bentuk dan substansi
dari deskripsi produk akan bervariasi, selalu harus cukup rinci untuk mendukung
Port perencanaan proyek selanjutnya.

Banyak proyek yang melibatkan satu organisasi (penjual) melakukan pekerjaan di bawah kontrak kepada yang lain (pembeli). Dalam keadaan tersebut, keterangan produknya adalah biasanya disediakan oleh si pembeli.

.2            Rencana Strategis. Semua proyek harus menjadi pendukung bagi hasil strategis organisasi pertunjukan---rencana strategis dari organisasi pertunjukan harus dipertimbangkan sebagai sebauh factor dalam pemutusan pemilihan proyek.

.3            Kriteria pemilihan proyek. Criteria pemilihan proyek biasanya didefinisikan  dalam jangka waktu kelebihan dari produk sebuah proyek dan bisa menutupi seluruh batas dari kemungkinan manajemen masalah (pengembalian keuangan, pembagiann pemasaran, pemikiran public, dll.).

.4            Informasi Sejarah. Informasi sejarah tentang hasil dari keputusan pemilihan proyek sebelumnya dan penampilan proyek sebelumnya harusnya disadari untuk perluasan yangtersedia. Ketika inisiasi melibatkan persetujuan untuk proyek di fase selanjutnya, informasi tentang hasil dari fase sebelumnya sering kritis.

5.1.2      Peralatan dan Teknis untuk Inisiasi

.1            Metode pemilihan proyek. Metode pemilihan proyek meliputi mengukur nilai atau ketertarikan terhadap pemilik proyek. Metode pemilihan proyek termasuk mempertimbagkan kriteria keputusan (bermacam kriteria, bila digunakan, harus dikombinasikan kepada fungsi nilai tunggal) dan artinya menghitung nilai di bawah ketidaktentuan. Itu semua dikenal sebagai model keputusan dan metode penghitungan. Pemilihan proyek juga berlaku untuk memilih cara alternative untuk melakukan proyek. Alat optimalisasi dapat digunakan untuk mencari sebuah kombinasi optimal dari suatu variable keputusan. Metode pemilihan proyek secara umum berada dalam salah satu dari dua (2) kategori yang luas:

·         Metode pengukuran keuntungan----kemunculan perbandingan, model-model penilaian, kontribusi kuntungan, atau model-model ekonimis.

·         Metode optimisasi terpaksa----model-model matematika menggunakan linier, non-linier, dinamis, integer, dan algoritma pemrograman multi-objektif.

Metode-metode ini sering mengacu sebagai model-model keputusan. Model-model keputusan termasuk teknis umum (Pohon Keputusan, Pilihan Mendesak, dan lainnya), sama bagusnya dengan yang khusus (Proses analisis heirarki, analisis kerangka logis, dan lainnya). Mengaplikasikan criteria pemilihan proyek secara kompleks dalam suatu model yang mutakhir sering diperlakukan sebagai pemisah fase proyek.

.2                    Keputusan Ahli. Keputusan ahli akan sering dibutuhkan untuk menilai input untuk proses ini. Seperti keahlian yang disediakan oleh grup manapun atau individual dengan pengetahuan khusus atau latihan, dan juga tersedia dari banyak sumber, termasuk:

·         Unit lainnya dalam organisasi pertunjukan.

·         Konsultan

·         Pemangku kepentingan, termasuk pelanggan.

·         Tenaga ahli dan asosiasi teknik

·         Grup Industri

5.1.3      Keluaran dari Inisiasi

1. Piagam proyek. Sebuah piagam proyek adalah berkas yang secara resmi mengotorisasi sebuah proyek. Itupun akan termasuk, salah satu yang secara langsung ataupun melalui referensi untuk berkas lain:

·         Suatu bisnis perlu bahwa suatu proyek sudah dilakukan kepada alamat

·         Penjelasan produk (Dijelaskan dalam bagian 5.1.1.1).

Piagam proyek seharusnya dikeluarkan oleh menejer eksternal ke proyek, dan saat level sesuai untuk kebutuhan proyek. Itupun menyediakan pengelolaan proyek dengan otoritas untuk menggunakan sumber organisasional untuk aktifitas proyek.

Ketika sebuah proyek dipertunjukkan dibawah kontrak, yang menandatangani kontrak umumnya akan melayani sebagai piagam proyek untuk penjual.

2. Pengelolaan proyek yang teridentifikas/ditugaskan. Umumnya, pengelolaan proyek seharusnya teridentifikasi dan ditugaskan terlebih dulu dalam proyek yang layak. Pengelolaan proyek seharusnya selalu ditugaskan sebelum perencanaan proyek dimulai (dijelaskan dalam Bag. 4.2) dan lebih disukai sebelum banyak perencanaan proyek selesai (proses perencanaan proyek tersebut dijelaskan dalam Bagian 3.3.2).

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

4. Asumsi. Lihat Bagian 4.1.1.5.

5.2 LINGKUP PERENCANAAN

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

5.2.1      Masukan untuk Perencanaan Ruang Lingkup

1. Uraian produk. Deskripsi produk dibahas dalam Bagian 5.1.1.1.
2. Proyek charter. Piagam proyek dijelaskan dalam Bagian 5.1.3.1.
3. Kendala. Kendala yang dijelaskan dalam Bagian 5.1.3.3.
4. Asumsi. Asumsi dijelaskan dalam Bagian 4.1.1.5.

5.2.2  Alat dan Teknik Perencanaan Ruang Lingkup

1. Produk analisis. Analisis produk melibatkan mengembangkan pemahaman yang lebih baik produk dari proyek. Ini mencakup teknik seperti kerusakan produk analisis sistem rekayasa, rekayasa nilai, analisis nilai, analisis fungsi,

        dan kualitas penyebaran fungsi.

2. Manfaat / analisis biaya. Manfaat / analisis biaya melibatkan estimasi nyata dan

        berwujud biaya (pengeluaran) dan manfaat (keuntungan) dari berbagai proyek dan produk

        alternatif, dan kemudian menggunakan ukuran finansial, seperti pengembalian investasi atau

        payback period, untuk menilai keinginan relatif dari alternatif diidentifikasi.

3. Alternatif identifikasi. Ini adalah istilah umum untuk teknik yang digunakan untuk setiap gen-

       erate pendekatan yang berbeda untuk proyek. Ada berbagai umum pengelolaan

       teknik pemerintah sering digunakan di sini, yang paling umum yang curah pendapat

       dan berpikir lateral.

4. Ahli penghakiman. Penilaian ahli dijelaskan dalam Bagian 5.1.2.2.

5.2.3 Keluaran dari Perencanaan Lingkup

1. Lingkup pernyataan. Pernyataan lingkup memberikan dasar didokumentasikan untuk membuat

       masa depan proyek keputusan dan untuk konfirmasi atau mengembangkan pemahaman bersama

       dari lingkup proyek antara para pemangku kepentingan. Sebagai proyek berlangsung, ruang lingkup

       Pernyataan mungkin perlu direvisi atau disempurnakan untuk mencerminkan perubahan disetujui   

       lingkup proyek. Pernyataan lingkup harus mencakup, baik secara langsung atau melalui ref-

       erence ke dokumen lain:

• Proyek pembenaran-kebutuhan bisnis yang proyek ini dilakukan untuk

           address. Pembenaran proyek memberikan dasar untuk mengevaluasi masa depan

           pengorbanan.

• Proyek produk-ringkasan singkat dari deskripsi produk (produk

           deskripsi dibahas dalam Bagian 5.1.1.1).

• Project kiriman-daftar ringkasan tingkat subproducts yang penuh dan duduk-

           pengiriman isfactory menandai selesainya proyek. Misalnya, utama deliv-

           Erables untuk proyek pengembangan perangkat lunak mungkin termasuk komputer kerja

           kode, panduan pengguna, dan tutorial interaktif. Ketika diketahui, pengecualian

           harus diidentifikasi, tapi apa pun tidak secara eksplisit dimasukkan secara implisit dikecualikan.

• Project tujuan-kriteria kuantitatif yang harus dipenuhi untuk proyek

           agar dianggap berhasil. Tujuan Proyek harus menyertakan setidaknya biaya,

          jadwal, dan kualitas tindakan. Tujuan Proyek harus memiliki atribut

          (Misalnya, biaya), metrik (misalnya, Amerika Serikat [AS] dolar), dan mutlak atau

           relatif nilai (misalnya, kurang dari 1,5 juta). Unquantified tujuan (misalnya, "cus-

           Tomer kepuasan ") memerlukan berisiko tinggi pemenuhan sukses.

.2    Mendukung detail. Mendukung detail untuk pernyataan ruang lingkup harus dokumented dan diatur sesuai kebutuhan untuk memudahkan penggunaannya oleh manajemen proyek      lainnya

proses. Mendukung rinci harus selalu menyertakan dokumentasi dari semua identified asumsi dan kendala. Jumlah detail tambahan dapat bervariasi tergantung

      aplikasi daerah.

.3   Lingkup rencana pengelolaan. Dokumen ini menjelaskan bagaimana ruang lingkup proyek akan

      Dikelola dan bagaimana perubahan ruang lingkup akan diintegrasikan ke dalam proyek. Seharusnya

      juga mencakup penilaian stabilitas diharapkan dari ruang lingkup proyek (yaitu, bagaimana mungkin adalah untuk mengubah, seberapa sering, dan seberapa banyak). Manajemen lingkup rencana juga harus mencakup gambaran yang jelas tentang bagaimana perubahan lingkup akan diidentified 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

luas dibingkai, berdasarkan pada kebutuhan proyek. Ini adalah komponen anak

dari rencana proyek (dijelaskan pada Bagian 4.1.3.1).

5.3  DEFINISI LINGKUP

        Definisi lingkup melibatkan pengelompokan deliverable proyek utama (seperti identified dalam laporan lingkup sebagaimana didefinisikan dalam Bagian 5.2.3.1) menjadi lebih kecil, lebih mankomponen agéable ke:

• Meningkatkan akurasi perkiraan biaya, durasi, dan sumber daya.
• Tentukan dasar untuk pengukuran kinerja dan kontrol.
• Memfasilitasi tugas tanggung jawab yang jelas.

Definisi lingkup yang tepat sangat penting bagi keberhasilan proyek. "Ketika ada ruang lingkup yang buruk Definisi, biaya tugas akhir dapat diharapkan akan lebih tinggi karena tak terelakkan perubahan yang mengganggu ritme proyek, pengerjaan ulang penyebab, proyek peningkatan.waktu, dan menurunkan produktivitas dan moral tenaga kerja ".

5.3.1  Masukan ke Definition Lingkup

1. Lingkup pernyataan. Pernyataan lingkup dijelaskan dalam Bagian 5.2.3.1. Kendala

2. Kendala yang dijelaskan dalam Bagian 5.1.3.3. Ketika sebuah proyek dilakukan

           di bawah kontrak, kendala didefinisikan oleh ketentuan kontrak sering impor-

           tant pertimbangan selama definisi lingkup.

3. Asumsi dijelaskan dalam Bagian 4.1.1.5.

4. Output perencanaan lainnya. Output dari proses dalam bidang pengetahuan lainnya

          harus ditinjau ulang untuk kemungkinan dampak pada lingkup definisi proyek.

5. Historical informasi. Informasi sejarah tentang proyek-proyek sebelumnya harus

          dipertimbangkan selama definisi lingkup. Informasi tentang kesalahan dan kelalaian

          proyek-proyek sebelumnya harus sangat berguna.

5.3.2  Alat dan Teknik untuk Definisi Lingkup

1. Template kerusakan struktur Kerja. Sebuah WBS (dijelaskan dalam Bagian 5.3.3.1) dari

           proyek sebelumnya sering dapat digunakan sebagai template untuk sebuah proyek baru.meskipun

           setiap proyek adalah unik, WBSs sering dapat "kembali" karena sebagian besar proyek akan

           menyerupai proyek lain sampai batas tertentu. Sebagai contoh, sebagian besar proyek dalam

           organisasi tertentu akan memiliki siklus hidup proyek yang sama atau serupa, dan demikian akan

           memiliki kiriman yang sama atau serupa yang diperlukan dari setiap tahap.

Contoh Kerja Struktur Breakdown untuk Produk Bahan Pertahanan

WBS ini adalah ilustrasi. Hal ini tidak dimaksudkan untuk mewakili lingkup proyek penuh dari setiap proyek tertentu, atau untuk menyiratkan bahwa ini adalah satu-satunya cara untuk mengatur WBS pada jenis proyek.

Banyak area aplikasi atau organisasi yang melakukan WBS memiliki standar atau semi-standar yang dapat digunakan sebagai contoh. Sebagai contoh, U.S.Department Pertahanan telah merekomendasikan standar WBS untuk Produk Bahan Pertahanan (MIL-HDBK-881). Sebagian dari salah satu contoh yang ditampilkan sebagai Gambar 5-1.

2.  Penguraian. Penguraian melibatkan pengelompokan kiriman  proyek besar atau sub kiriman menjadi lebih kecil, komponen lebih mudah ditangani sampai kiriman didefinisikan secara rinci cukup untuk mendukung pengembangan kegiatan proyek (perencanaan, pelaksanaan, pengendalian, dan penutupan). Dekomposisi melibatkan langkah-langkah utama berikut:

1.  Mengidentifikasi point utama dari proyek, termasuk manajemen proyek. Point utama harus selalu didefinisikan dalam hal bagaimana proyek akan benar-benar terorganisir. Sebagai contoh:

·         Fase-fase siklus hidup proyek dapat digunakan sebagai tingkat pertama dari dekomposisi dengan deliverable proyek diulang pada tingkat kedua, seperti yang diilustrasikan pada Gambar 5-2.

·         Prinsip pengorganisasian dalam setiap cabang WBS dapat bervariasi, seperti digambarkan pada Gambar 5-3.

  2.  Memutuskan apakah biaya yang memadai dan perkiraan durasi dapat dikembangkan pada tingkat detail untuk setiap pengiriman. Arti dari memadai dapat berubah selama proyek, penguraian dari pengiriman yang akan diproduksi jauh di masa depan mungkin tidak dapat dilakukan. Untuk setiap pengiriman, lanjutkan ke Langkah 4 jika ada rincian yang memadai, ke Langkah 3 jika tidak ada, ini berarti bahwa kiriman yang berbeda mungkin memiliki tingkat yang berbeda dari penguraian.

Contoh Kerja Struktur Breakdown Diselenggarakan oleh Tahap

WBS ini ilustrasi. Hal ini tidak dimaksudkan untuk mewakili lingkup proyek penuh dari setiap proyek tertentu, atau untuk menyiratkan bahwa ini adalah satu-satunya cara untuk mengatur WBS pada jenis proyek.

Di wbs berada di luar lingkup dari proyek. Seperti dengan lingkup pernyataan, wbs yang sering digunakan untuk mengembangkan atau mengkonfirmasi umum pemahaman dari proyek lingkup. Setiap menurun tingkat mewakili yang semakin terperinci proyek deliverables. Bagian 5.3.2.2 menjelaskan pendekatan yang paling umum untuk mengembangkan sebuah wbs. Sebuah wbs itu biasanya disajikan dalam grafik yang membentuk, seperti yang digambarkan dalam angka 5-2, 5-3, dan 5-4; namun, yang wbs jangan bingung dengan metode presentasi menggambar sebuah kegiatan tidak terstruktur daftar dalam grafik yang membentuk tidak membuat sebuah wbs. Setiap item di wbs ini umumnya ditugaskan yang unik identifier; ini pengidentifikasi dapat menyediakan sebuah struktur untuk sebuah hirarkis penjumlahan dari biaya dan sumberdaya. Item pada tingkat terendah dari wbs dapat disebut sebagai bekerja paket, terutama di organisasi yang mengikuti diperoleh nilai praktek manajemen. Paket pekerjaan ini mungkin pada akhirnya menjadi lebih lanjut decomposed dalam sebuah subproject bekerja kerusakan struktur. Umumnya, pendekatan jenis ini digunakan ketika project manager menetapkan sebuah ruang lingkup bekerja untuk organisasi lain, dan organisasi lain Harus merencanakan dan mengelola lingkup pekerjaan di tingkat yang lebih rinci dari proyek manajer di utama proyek. Paket pekerjaan ini mungkin lebih lanjut decomposed dalam rencana proyek dan jadwal, seperti yang dijelaskan di bagian 5.3.2.2 dan 6.1.2.1. Deskripsi pekerjaan komponen yang sering dikumpulkan dalam sebuah wbs kamus. Sebuah wbs kamus akan biasanya termasuk deskripsi pekerjaan paket, serta perencanaan lain informasi seperti jadwal tanggal, biaya anggaran, dan staf tugas. Yang wbs jangan bingung dengan jenis lain dari “kerusakan struktur”  digunakan untuk menyajikan project information. Struktur lainnya yang umum digunakan dalam beberapa aplikasi daerah termasuk:

Contractual WBS (CWBS),, yang digunakan untuk menentukan tingkat pelaporan Penjual akan memberikan pembeli. CWBS umumnya termasuk kurang detail daripada WBS digunakan oleh penjual untuk mengelola penjual yang bekerja.

Organizational breakdown structure (OBS), yang digunakan untuk menunjukkan mana pekerjaan komponen telah ditugaskan untuk yang organisasi unit.

Resource breakdown structure (RBS), yang adalah variasi dari OBS dan biasanya digunakan ketika pekerjaan komponen yang ditugaskan untuk individu.

Bill of material (BOM), yang menyajikan pemandangan hirarkis fisik Majelis, subassemblies, dan komponen yang diperlukan untuk membuat produk yang diproduksi.

Project breakdown structure (PBS), yang pada dasarnya sama dengan WBS dilakukan dengan benar. PBS istilah secara luas digunakan dalam bidang aplikasi mana WBS salah istilah ini untuk merujuk kepada BOM.

2. Scope statement updates.Termasuk apapun modifikasi dari isi pernyataan lingkup (dijelaskan dalam Bagian 5.2.3.1). Stakeholder yang sesuai harus diberitahu yang diperlukan.

WBS ini adalah ilustrasi. Hal ini tidak dimaksudkan untuk mewakili lingkup proyek penuh dari setiap proyek tertentu, atau untuk menyiratkan bahwa ini adalah satu-satunya cara untuk mengatur WBS pada jenis proyek.

3. Mengidentifikasi adalah komponen dari pengiriman. Komponen harus dijelaskan dalam hal nyata, hasil diverifikasi untuk memfasilitasi pengukuran kinerja. Seperti dengan komponen utama,komponen harus didefinisikan dalam hal proyek dicapai. Jelas, hasil diverifikasi dapat mencakup layanan serta produk (misalnya, pelaporan status dapat digambarkan sebagai laporan status mingguan, untuk item diproduksi, komponen mungkin termasuk komponen individu beberapa ditambah perakitan akhir). Ulangi Langkah 2 pada setiap komponen penyusunnya.

4.  Memverifikasi kebenaran dekomposisi :

• Apakah tingkat rendah item penting dan cukup untuk penyelesaian membusuk item? Jika tidak, komponen harus dimodifikasi (ditambahkan ke, 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? Dianggarkan? Ditugaskan ke spesifik unit organisasi (misalnya, departemen, tim, atau orang) yang akan menerima tanggung jawab untuk penyelesaian yang memuaskan dari item? Jika tidak, revisi yang diperlukan untuk memberikan kontrol manajemen yang memadai.

5.3.3 Output dari Definisi Lingkup

1.  Bekerja struktur rincian. Sebuah WBS adalah pengelompokan penyampaian  berorientasi proyek komponen yang mengatur dan menentukan ruang lingkup total proyek; bekerja tidak

5.4 SCOPE VERIFICATION

Lingkup verifikasi adalah proses mendapatkan penerimaan formal lingkup proyek oleh stakeholder (sponsor, klien, pelanggan, dll). Hal ini membutuhkan meninjau hasil penyerahan dan bekerja untuk memastikan bahwa semua diselesaikan dengan benar dan memuaskan. Jika proyek dihentikan awal, proses verifikasi lingkup harus menetapkan dan dokumen tingkat dan sejauh penyelesaian. Lingkup verifikasi berbeda dari kontrol kualitas (dijelaskan dalam bagian 8.3) terutama berkaitan dengan penerimaan hasil kerja sementara kontrol kualitas ini berkaitan dengan kebenaran dari hasil kerja. Proses ini umumnya dilakukan secara paralel untuk memastikan ketepatan dan penerimaan.

5.4.1 input untuk cakupan verifikasi

                1. hasil kerja. Hasil kerja adalah kiriman yang telah sepenuhnya atau sebagian diselesaikan merupakan output dari pelaksanaan rencana proyek (dibahas dalam bagian 4.2).

                2. dokumentasi produk. Dokumentasi produk adalah untuk menggambarkan produk proyek harus tersedia untuk diperiksa. Istilah yang digunakan untuk menggambarkan dokumentasi ini (rencana,spesifikasi,dokumentasi teknis, gambar,dll) bervariasi berdasarkan area(wilayah) aplikasinya.

                3. work breakdown structure. WBS membantu dalam mendefinisikan ruang lingkup dan harus digunakan untuk memverifikasi proyek pekerjaan (lihat bagian 5.3.3.1).

                4. scope statement. Scope statement mendefinisikan ruang lingkup dalam beberapa detail dan harus diverifikasi (lihat bagian 5.2.3.1).

                5. project plan. Project plan di jelaskan dalam bagian 4.1.3.1.

5.4.2 peralatan dan teknik untuk cakupan verifikasi.

                1. inspection. Inspection meliputi kegiatan seperti mengukur memeriksa, dan pengujian dilakukan untuk menentukan apakah hasil sesuai dengan persyaratan.berbagai inspeksi disebut ulasan, review produk, audit, dan penelusuran, dalam beberapa area aplikasi, istilah-istilah yang berbeda memiliki arti yang sempit dan spesifik.

5.4.3 output dari cakupan verifikasi

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

5.5 scope change control

                scope change control 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, dan c) mengelola perubahan yang sebenarnya ketika dan jika mereka terjadi. Lingkup perubahan kontrol harus benar-benar terintegrasi dengan proses kontrol lainnya (jadwal kontrol, pengendalian biaya, kontrol kualitas, dan lain-lain, seperti dibahas dalam Bagian 4.3).

5.5.1 input to scope change control

                1. work breakdown structure. WBS dijelaskan di bagian 5.2.2.1. Ini mendefinisikan dasar ruang lingkup proyek.

                2.perfomance reports. Laporan kinerja, dibahas dalam Bagian 10.3.3.1, memberikan informasi tentang kinerja lingkup, seperti yang penyerahan sementara telah selesai dan yang belum. Laporan kinerja juga dapat mengingatkan tim proyek untuk isu-isu yang dapat menyebabkan masalah di masa depan.

                3 change request. Permintaan perubahan dapat terjadi dalam banyak bentuk-lisan atau tertulis,langsung atau tidak langsung, eksternal atau internal dimulai, dan secara hukum wajib atau opsional. Perubahan mungkin memerlukan perluasan ruang lingkup atau memungkinkan menyusutkannya. Permintaan perubahan Kebanyakan adalah hasil dari:

                * Suatu peristiwa eksternal (misalnya, perubahan dalam peraturan pemerintah).

* Kesalahan atau kelalaian dalam mendefinisikan lingkup produksi (misalnya, kegagalan untuk memasukkan fitur yang dibutuhkan dalam desain sistem telekomunikasi)

* Kesalahan atau kelalaian dalam mendefinisikan lingkup proyek (misalnya, menggunakan BOM bukannya WBS)

* Sebuah nilai tambah perubahan (misalnya, sebuah proyek rehabilitasi lingkungan dapat mengurangi biaya dengan mengambil keuntungan dari teknologi yang tidak tersedia ketika lingkup awalnya didefinisikan)

* Menerapkan rencana darurat atau rencana solusi untuk menanggapi risiko, seperti yang dijelaskan dalam bagian 11.6.3.3.

                4. scope management plan. Rencana pengelolaan lingkup dijelaskan dalam bagian 5.2.3.3.

5.5.2 peralatan dan teknik untuk scope change control

                1. scope changes. Suatu pengendalian perubahan lingkup mendefinisikan prosedur dimana lingkup proyek dapat diubah. Ini mencakup dokumen, sistem pelacakan, dan tingkat persetujuan yang diperlukan untuk perubahan otorisasi. Kontrol perubahan lingkup harus diintegrasikan dengan kontrol perubahan terpadu dijelaskan dalam bagian 4.2 dan, khususnya, dengan sistem di lingkup tempat kontrol produk. Ketika proyek ini dilakukan di bawah kontrak, pengendalian perubahan lingkup juga harus mematuhi semua ketentuan kontrak yang relevan.

                2. performance meansurement. kinerja measurement.Performance, dijelaskan dalam Bagian 10.3.2, 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 kontrol lingkup perubahan.

                3. additional planning. Beberapa proyek berjalan tepat sesuai rencana. Perubahan lingkup Calon mungkin memerlukan modifikasi WBS atau analisis pendekatan alternatif (lihat Bagian 5.3.3.1 dan 5.2.2.3, masing-masing).

5.5.3 output dari scope change control

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

                2.corrective action. Tindakan korektif adalah segala sesuatu dilakukan untuk membawa masa depan yang diharapkankinerja proyek sesuai dengan rencana proyek.

                3. lesson learned. Penyebab varians, alasan di balik korektif tindakan yang dipilih, dan jenis-jenis pelajaran dari kontrol lingkup perubahan harus didokumentasikan, sehingga informasi ini menjadi bagian dari sejarah database untuk kedua proyek ini dan proyek lain dari organisasi yang melakukan.

                4. adjusted baseline. Tergantung pada sifat dari perubahan, yang sesuai Dokumen dasar dapat direvisi dan diterbitkan kembali untuk mencerminkan perubahan disetujui dan membentuk dasar baru untuk perubahan masa depan.

Untuk mendownload e-book asli:

Project Management Body Of Knowledge

Untuk melihat versi bahasa Inggris bisa dilihat di link di bawah ini:

Project Scope Management