Rabu, 15 Januari 2014
Selasa, 14 Januari 2014
Ringkasan PMBOK Bagian 6
Manajemen Waktu Proyek
Manajemen waktu proyek mencakup lamanya proses-proses yang
diperlukan untuk memastikan penyelesaian tepat waktu dari proyek.
DEFINISI KEGIATAN.
Definisi Kegiatan melibatkan mengidentifikasi dan
mendokumentasikan kegiatan khusus yang harus dilakukan untuk menghasilkan
deliverable dan subdeliverables diidentifikasi dalam Struktur Perincian Kerja
(WBS). Implisit dalam proses ini adalah kebutuhan untuk mendefinisikan kegiatan
sehingga tujuan proyek akan dipenuhi.
Masukan Definisi Kegiatan.
1. Struktur Rincian Kerja.
2. Lingkup pernyataan.
3. Informasi historis.
4.Kendala.
5. Asumsi.
6. Ahli penghakiman.
Alat dan Teknik Definisi Kegiatan
1. Dekomposisi.
2. Template.
Keluaran Definisi Kegiatan.
1. Daftar
kegiatan.
2. Rincian pendukung.
3. Update Kerusakan Struktur Kerja.
URUTAN KEGIATAN.
Urutan kegiatan melibatkan mengidentifikasi dan
mendokumentasikan interaktivitas hubungan logis. Kegiatan harus diurutkan
secara akurat untuk mendukung kemudian mengembangkan jadwal yang realistis dan
dapat dicapai. Sequencing dapat dilakukan dengan bantuan komputer (misalnya,
dengan menggunakan perangkat lunak manajemen proyek) atau denganpengguna
teknik. Teknik manual sering lebih efektif pada lebih kecil projects dan pada
tahap awal yang lebih besar ketika detail kecil yang tersedia. Pedoman dan
teknik otomatis juga dapat digunakan dalam kombinasi.
Masukan Urutan Kegiatan.
1. Daftar Kegiatan .
2. Deskripsi produk.
3. Dependensi wajib.
4. Dependensi Discretionary.
5. Dependensi eksternal.
6. Milestones.
Alat dan Teknik Urutan Kegiatan.
1.Metode Precedence diagram (PDM).
2. Metode diagram Panah (ADM).
3. Metode diagram Bersyarat.
4. Jaringan template.
6.2.2
Keluaran Urutan Kegiatan.
1. Diagram Jaringan Proyek.
2. Daftar Pembaruan Kegiatan.
6.3 ESTIMASI
DURASI KEGIATAN.
Estimasi durasi kegiatan adalah proses mengambil
informasi mengenai lingkup proyek dan sumber daya dan kemudian berkembang untuk
jangka waktu input ke jadwal. Masukan untuk perkiraan durasi biasanya berasal
dari orang atau kelompok lain. Dengan demikian, perkiraan tersebut dapat
diasumsikan progresif sively lebih akurat dan kualitas yang dikenal. Tim yang
paling akrab dengan sifat dari suatu aktivitas tertentu harus membuat, atau
setidaknya menyetujui, memperkirakan jumlah periode kerja yang dibutuhkan untuk
menyelesaikan suatu kegiatan akan sering membutuhkan pertimbangan waktu berlalu
juga. Misalnya, jika "beton curing "akan memerlukan empat hari waktu
berlalu, mungkin memerlukan dua sampai empat kerja periode, berdasarkan pada)
yang hari minggu itu dimulai, dan b) apakah atau tidak hari pekan diperlakukan
sebagai periode kerja. Kebanyakan komputerisasi penjadwalan soft gudang akan
menangani masalah ini dengan menggunakan alternatif pekerjaan-periode kalender.
Masukan untuk Durasi Kegiatan Memperkirakan.
1.Daftar aktivitas dijelaskan dalam Bagian 6.1.3.1.
2.Kendala.
3. Asumsi.
4. Persyaratan Sumber Daya.
5. Kemampuan Sumber Daya.
6. Sejarah informasi.
6.3.2
Alat dan Teknik Estimasi Durasi
Kegiatan.
1.Ahli penghakiman.
2.Memperkirakan analog.
3.Quantitatively berdasarkan jangka waktu.
4.Reserve waktu (contingency).
Keluaran Estimasi Duras Kegiatan.
1. Perkiraan Durasi Kegiatan.
2. Dasar perkiraan.
3. Daftar Pembaruan Kegiatan.
PENGEMBANGAN
JADWAL.
Pengembangan jadwal berarti menentukan mulai dan
selesai tanggal untuk aktivitas. Jika tanggal awal dan akhir yang tidak
realistis, maka proyek tidak mungkin selesai sesuai jadwal. Proses pengembangan
jadwal seringkali harus terciptakan (bersama dengan proses yang memberikan
masukan, terutama durasi memperkirakan dan biaya estimasi) sebelum penentuan
jadwal proyek.
6.4.1
Masukan untuk Jadwal Pembangunan.
1.Diagram Jaringan Proyek.
2. Kegiatan perkiraan durasi.
3. Kebutuhan sumber daya.
4. Sumber daya.
5. Kalender.
6. Kendala.
7. Asumsi.
8. Pemimpin.
9. Risiko Pengelolaan Rencana.
10. Atribut Kegiatan
Alat dan Teknik untuk Pengembangan Jadwal
1.Analisis Matematis.
2.Kompresi Durasi.
3. Simulasi.
4. Sumber daya meratakan heuristik.
5. Perangkat lunak manajemen proyek.
6. Struktur Pengkodean.
Keluaran Pengembangan Jadwal.
1. Jadwal Proyek.
2. Pendukung detail.
3. Jadwal rencana pengelolaan.
4. Sumber daya persyaratan pembaruan.
PENGAWASAN JADWAL.
Pengawasan jadwal berkaitan dengan yang mempengaruhi
faktor-faktor yang membuat jadwal perubahan untuk memastikan bahwa perubahan
yang disepakati, b) menentukan bahwa jadwal telah berubah, dan c) mengelola
perubahan yang sebenarnya kapan dan karena mereka terjadi. Jadwal kontrol harus
benar-benar terintegrasi dengan kontrol lainnya proses, seperti yang dijelaskan
dalam Bagian 4.3, Integrated Change Control.
Masukan untuk Jadwal Kontrol
1. Jadwal Proyek.
2. Kinerja laporan.
3. Mengubah permintaan.
4. Rencana Pengelolaan Jadwal.
Alat dan Teknik Pengawasan Jadwal.
1. Jadwal perubahan sistem kendali.
2. Pengukuran kinerja.
3. Perencanaan Tambahan.
4. Proyek perangkat lunak manajemen.
5. Varians analisis.
Keluaran dari Control Jadwal
1. Jadwal update.
2. Tindakan korektif.
3. Level pembelajaran.
Manajemen Waktu Proyek (PMBOK Bagian 6)
Manajemen waktu proyek mencakup lamanya proses-proses yang
diperlukan untuk memastikan penyelesaian tepat waktu dari proyek. Gambar 6-1
memberikan gambaran proses utama berikut dalam mengembangkan jadwal waktu
proyek:
6.1 Definisi Kegiatan.
Mengidentifikasi kegiatan khusus yang harus dilakukan untuk
menghasilkan deliverable berbagai proyek.
6.2 Urutan Kegiatan.
Mengidentifikasi dan mendokumentasikan dependensi
interaktivitas.
6.3 Estimasi Durasi Kegiatan.
Memperkirakan-memperkirakan jumlah periode kerja yang akan diperlukan
untuk menyelesaikan kegiatan individu.
6.4 Pengembangan Jadwal.
Pengembangan analisis, jangka waktu kegiatan, dan kebutuhan
sumber daya untuk membuat jadwal proyek.
6.5 Pengawasan Jadwal.
Pengawasan perubahan pada jadwal proyek.
Proses ini 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 yang disajikan di sini
sebagai elemen diskrit dengan antarmuka welldefined, dalam praktiknya mereka
mungkin tumpang tindih dan berinteraksi dengan cara yang tidak rinci di sini.
Proses interaksi dibahas secara rinci dalam Bab 3.
Pada beberapa proyek, terutama yang kecil, urutan aktivitas,
durasi kegiatan memperkirakan, dan pengembangan jadwal yang begitu erat terkait
bahwa mereka dipandang sebagai suatu proses tunggal (misalnya, mereka mungkin
dilakukan oleh satu individu selama periode yang relatif singkat). Mereka
disajikan di sini sebagai proses yang berbeda karena alat dan teknik untuk masing-masing
berbeda.
6.1 DEFINISI KEGIATAN
Definisi Kegiatan melibatkan mengidentifikasi dan
mendokumentasikan kegiatan khusus yang harus dilakukan untuk menghasilkan
deliverable dan subdeliverables diidentifikasi dalam Struktur Perincian Kerja
(WBS). Implisit dalam proses ini adalah kebutuhan untuk mendefinisikan kegiatan
sehingga tujuan proyek akan dipenuhi.
6.1.1 Masukan Definisi Kegiatan.
1. Struktur Rincian Kerja.
WBS adalah masukan utama untuk definisi aktivitas.
(Lihat Bagian 5.3.3.1 untuk diskusi yang lebih rinci tentang
WBS).
2. Lingkup pernyataan.
Pembenaran proyek dan tujuan proyek yang terkandung dalam
lingkup pernyataan harus dipertimbangkan secara eksplisit selama definisi
aktivitas.
(Lihat Bagian 5.2.3.1 untuk diskusi lebih rinci dari
pernyataan lingkup).
3. Informasi historis.
Informasi historis (kegiatan apa yang sebenarnya diperlukan
pada sebelumnya, proyek serupa) harus dipertimbangkan dalam menentukan proyek kegiatan.
4.Kendala.
Kendala adalah faktor yang akan membatasi tim manajemen
proyek yang pilihan, contoh akan penggunaan jangka waktu maksimum yang
diinginkan aktivitas.
5. Asumsi.
Lihat Bagian 4.1.1.5.
6. Ahli penghakiman.
Penilaian ahli dibahas dalam Bagian 5.1.2.2 dan 6.3.2.1.
6.1.2 Alat dan Teknik Definisi Kegiatan
1. Dekomposisi.
Dalam konteks proses definisi kegiatan, dekomposisi posisi
melibatkan pengelompokan paket proyek pekerjaan menjadi lebih kecil, komponen
lebih mudah dikelola untuk memberikan kontrol manajemen yang lebih baik. Teknik
dekomposisi dijelaskan secara lebih rinci dalam Bagian 5.3.2.2. Perbedaan utama
antara dekomposisi di sini dan di Definisi Lingkup adalah bahwa output akhir di
sini digambarkan sebagai kegiatan bukan sebagai kiriman. WBS dan daftar
kegiatan biasanya dikembangkan secara berurutan, dengan WBS menjadi dasar untuk
pengembangan daftar kegiatan akhir. Di beberapa daerah aplikasi, WBS dan daftar
kegiatan yang dikembangkan secara bersamaan.
2. Template.
Sebuah daftar kegiatan (dijelaskan pada Bagian 6.1.3.1),
atau sebagian dari daftar kegiatan dari proyek sebelumnya, sering digunakan
sebagai template untuk sebuah proyek baru. Kegiatan dalam template juga dapat
berisi daftar keterampilan sumber daya dan jam yang diperlukan mereka usaha,
identifikasi risiko, deliverables diharapkan, dan informasi deskriptif lainnya.
6.1.3
Keluaran Definisi Kegiatan.
1. Daftar
kegiatan.
Daftar kegiatan harus mencakup semua kegiatan yang akan
dilakukan pada proyek. Ini harus diatur sebagai perpanjangan ke WBS untuk
membantu memastikan bahwa itu selesai, dan bahwa hal itu tidak
termasuk kegiatan yang tidak diperlukan sebagai deskripsi dari masing-masing
kegiatan untuk memastikan bahwa anggota tim proyek akan memahami bagaimana
pekerjaan yang harus dilakukan.
2. Rincian pendukung.
Rincian pendukung untuk daftar kegiatan harus
didokumentasikan 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
bervariasi oleh aplikasi daerah.
3. Update Kerusakan Struktur Kerja.
Dalam menggunakan WBS untuk mengidentifikasi
kegiatan diperlukan, tim proyek dapat mengidentifikasi kiriman yang hilang,
atau dapat menentukan bahwa deskripsi diserahkan perlu diperjelas atau
dikoreksi. Setiap pembaruan tersebut harus tercermin dalam WBS dan dokumentasi
terkait, seperti perkiraan biaya. Pembaruan ini sering disebut perbaikan dan
kemungkinan besar ketika proyek melibatkan teknologi baru atau belum terbukti.
6.2 URUTAN KEGIATAN.
Kegiatan Sequencing melibatkan mengidentifikasi dan
mendokumentasikan interaktivitas hubungan logis. Kegiatan harus diurutkan
secara akurat untuk mendukung kemudian mengembangkan jadwal yang realistis dan
dapat dicapai. Sequencing dapat dilakukan dengan bantuan komputer (misalnya,
dengan menggunakan perangkat lunak manajemen proyek) atau denganpengguna
teknik. Teknik manual sering lebih efektif pada lebih kecil projects dan pada
tahap awal yang lebih besar ketika detail kecil yang tersedia. Pedoman dan
teknik otomatis juga dapat digunakan dalam kombinasi.
6.2.1 Masukan Urutan Kegiatan.
1. Daftar Kegiatan .
Daftar kegiatan dijelaskan dalam Bagian 6.1.3.1.
2. Deskripsi produk.
Deskripsi produk dibahas dalam Bagian 5.1.1.1.
Karakteristik produk seringkali mempengaruhi aktivitas sequencing (misalnya,
tata letak fisik pabrik yang akan dibangun, subsistem antarmuka pada sebuah
proyek software). Sementara efek ini sering terlihat dalam daftar kegiatan,
deskripsi produk umumnya harus ditinjau untuk memastikan akurasi.
3. Dependensi wajib.
Dependensi wajib adalah mereka yang melekat dalam
sifat pekerjaan yang dilakukan. Mereka sering melibatkan keterbatasan fisik. (Pada
proyek konstruksi, adalah mustahil untuk mendirikan suprastruktur sampai
setelah yayasan telah dibangun, pada proyek elektronik, prototipe harus
dibangun sebelum dapat diuji.) dependensi wajib juga disebut logika keras.
4. Dependensi Discretionary.
Dependensi Discretionary adalah mereka yang didefinisikan
oleh tim manajemen proyek. Mereka harus digunakan dengan hati-hati (dan
didokumentasikan), karena mereka dapat membatasi pilihan penjadwalan nanti.
Dependensi Discretionary biasanya didefinisikan berdasarkan pengetahuan: "Praktik
terbaik" dalam area aplikasi tertentu.
Beberapa aspek yang tidak biasa dari proyek mana
urutan tertentu yang diinginkan, bahkan meskipun ada urutan lain yang dapat
diterima. Dependensi Discretionary juga dapat disebut logika disukai, logika
preferensial, atau logika lembut.
5. Dependensi eksternal.
Dependensi eksternal adalah mereka yang melibatkan
hubungan antara kegiatan proyek dan kegiatan non proyek. Sebagai contoh,
kegiatan pengujian dalam proyek perangkat lunak mungkin tergantung pada
pengiriman perangkat keras dari sumber eksternal, atau dengar pendapat
lingkungan mungkin perlu diadakan sebelum persiapan lokasi dapat dimulai pada
proyek konstruksi.
6. Milestones.
Peristiwa Milestone perlu menjadi bagian dari
kegiatan sekuensing untuk menjamin bahwa persyaratan untuk memenuhi tonggak terpenuhi.
6.2.2 Alat dan Teknik Urutan Kegiatan.
1.Metode Precedence diagram (PDM).
Ini adalah metode membangun proyek jaringan diagram
yang menggunakan kotak atau persegi panjang (node) untuk mewakili kegiatan dan menghubungkan
mereka dengan panah yang menunjukkan dependensi (lihat juga Bagian 6.2.3.1).
Gambar 6-2 menunjukkan logika diagram jaringan
sederhana digambar dengan menggunakan PDM. Teknik ini juga disebut
kegiatan-on-node (AON) dan merupakan metode yang digunakan oleh proyek
pengelolaan paket perangkat lunak. PDM dapat dilakukan secara manual atau
komputer.
Ini mencakup empat jenis hubungan ketergantungan
atau didahulukan:
Akhir-ke-Awal-inisiasi pekerjaan pengganti
tergantung pada penyelesaian karya pendahulunya.
Akhir-ke-Akhir-penyelesaian pekerjaan pengganti
tergantung pada penyelesaian karya pendahulunya.
Awal-ke-Awal-inisiasi pekerjaan pengganti tergantung
pada
inisiasi karya pendahulunya.
Awal-ke-Akhir penyelesaian penggantinya adalah tergantung
pada diprakarsai-
asi dari pendahulunya.
Dalam PDM, finish-to-start adalah jenis yang paling
umum digunakan dari hubungan logis.
2. Metode diagram Panah (ADM).
Metode ini membangun proyek-net diagram kerja
menggunakan panah untuk mewakili kegiatan dan menghubungkan mereka pada node
untuk menunjukkan ketergantungan mereka (lihat juga Bagian 6.2.3.1). Gambar 6-3
menunjukkan logika diagram jaringan sederhana digambar dengan menggunakan ADM.
Teknik ini juga disebut activityon-panah (AOA) dan, meskipun kurang lazim
dibanding PDM, masih merupakan teknik pilihan di beberapa area aplikasi. ADM
menggunakan hanya finis-to-start ketergantungan dan mungkin memerlukan
penggunaan kegiatan dummy untuk mendefinisikan semua hubungan logis dengan
benar. ADM dapat dilakukan secara manual atau komputer.
3. Metode diagram Bersyarat.
Diagram teknik seperti Grafis Evaluasi dan Teknik
Ulasan (Gert) dan Dinamika Sistem model memungkinkan untuk kegiatan
nonsequential seperti loop (misalnya, tes yang harus diulang lebih dari sekali)
atau kondisional cabang (misalnya, update desain yang hanya diperlukan jika pemeriksaan
mendeteksi kesalahan). Baik PDM atau ADM memungkinkan loop atau kondisional cabang.
4. Jaringan template.
Mereka dapat mencakup seluruh proyek atau hanya sebagian
dari itu. Bagian dari jaringan yang sering disebut sebagai subnet atau
fragnets. Subnet sangat berguna ketika proyek mencakup fitur identik atau
hampir identik beberapa, seperti lantai pada gedung perkantoran bertingkat
tinggi, uji klinis pada sebuah proyek penelitian farmasi, modul program pada
sebuah proyek perangkat lunak, atau fase start-up dari perkembangan proyek.
6.2.3
Keluaran Urutan Kegiatan.
1. Diagram Jaringan Proyek.
Diagram jaringan proyek adalah skematik proyek
kegiatan dan hubungan logis (ketergantungan) di antara mereka. Gambar 6-2 dan
6-3 menggambarkan dua pendekatan yang berbeda untuk menggambar sebuah proyek
bersih diagram. Sebuah diagram jaringan proyek dapat diproduksi secara manual
atau pada komputer. Ini mungkin termasuk rincian proyek penuh, atau memiliki
satu atau lebih ringkasan kegiatan. Diagram harus disertai dengan narasi
ringkasan yang menggambarkan pendekatan sequencing dasar. Setiap urutan biasa
harus sepenuhnya dijelaskan.
Sebuah diagram jaringan proyek sering disebut sebagai
bagan PERT. Secara historis PERT (Program Evaluasi dan Teknik Review) adalah
jenis tertentu diagram jaringan (lihat juga Bagian 6.4.2.1).
2. Daftar Pembaruan Kegiatan.
Dalam banyak cara yang sama bahwa proses definisi
kegiatan dapat menghasilkan pembaruan ke WBS, persiapan diagram jaringan proyek
dapat mengungkapkan contoh di mana suatu kegiatan harus dibagi atau
didefinisikan kembali untuk diagram hubungan logis yang benar.
6.3 ESTIMASI
DURASI KEGIATAN.
Estimasi durasi kegiatan adalah proses mengambil
informasi mengenai lingkup proyek dan sumber daya dan kemudian berkembang untuk
jangka waktu input ke jadwal. Masukan untuk perkiraan durasi biasanya berasal
dari orang atau kelompok lain. Dengan demikian, perkiraan tersebut dapat
diasumsikan progresif sively lebih akurat dan kualitas yang dikenal. Tim yang
paling akrab dengan sifat dari suatu aktivitas tertentu harus membuat, atau
setidaknya menyetujui, memperkirakan jumlah periode kerja yang dibutuhkan untuk
menyelesaikan suatu kegiatan akan sering membutuhkan pertimbangan waktu berlalu
juga. Misalnya, jika "beton curing "akan memerlukan empat hari waktu
berlalu, mungkin memerlukan dua sampai empat kerja periode, berdasarkan pada)
yang hari minggu itu dimulai, dan b) apakah atau tidak hari pekan diperlakukan
sebagai periode kerja. Kebanyakan komputerisasi penjadwalan soft gudang akan
menangani masalah ini dengan menggunakan alternatif pekerjaan-periode kalender.
Durasi proyek secara keseluruhan juga dapat
diperkirakan dengan menggunakan alat dan teknik yang disajikan di sini, tetapi
lebih tepat dihitung sebagai output dari jadwal pembangunan (dijelaskan dalam
Bagian 6.4). Tim proyek dapat mempertimbangkan durasi proyek distribusi
probabilitas (menggunakan teknik probabilistik) atau sebagai perkiraan
singlepoint (menggunakan teknik deterministik).
6.3.1 Masukan untuk Durasi Kegiatan Memperkirakan.
1.Daftar aktivitas dijelaskan dalam Bagian 6.1.3.1.
2.Kendala.
Kendala yang dijelaskan dalam Bagian 6.1.1.4.
3. Asumsi
Asumsi dijelaskan dalam Bagian 4.1.1.5. Sebuah contoh akan melaporkan periode selama
proyek yang bisa mendikte jangka waktu maksimum, yaitu, dua periode pelaporan.
4. Persyaratan Sumber Daya.
Kebutuhan sumber daya yang dijelaskan dalam Bagian
7.1.3.1. Lamanya kegiatan yang paling akan sangat dipengaruhi oleh sumber daya ditugaskan
kepada mereka. Misalnya, dua orang yang bekerja bersama-sama mungkin dapat menyelesaikan
kegiatan desain dalam setengah waktu yang dibutuhkan baik dari mereka secara
individu, sementara orang bekerja setengah waktu pada aktivitas yang umumnya
akan memakan waktu setidaknya dua kali waktu sebanyak sebagai orang yang sama
bekerja penuh waktu. Namun, sebagai tambahan sumber daya ditambahkan, proyek
dapat mengalami kelebihan komunikasi, yang mengurangi produktivitas dan
menyebabkan produksi untuk meningkatkan proporsional kurang dari peningkatan
sumber daya.
5. Kemampuan Sumber Daya.
Lamanya kegiatan yang paling signifikan akan
influenced oleh kemampuan sumber daya manusia dan materi yang ditugaskan kepada
mereka. Misalnya, jika keduanya ditugaskan penuh waktu, anggota staf senior
pada umumnya dapat diharapkan untuk menyelesaikan aktivitas yang diberikan
dalam waktu kurang dari anggota staf junior.
6. Sejarah informasi.
Banyak kategorie kegiatan sering tersedia dari satu
atau lebih dari sumber-sumber berikut:
■ file-satu proyek atau lebih dari organisasi
yang terlibat dalam proyek tersebut dapat
memelihara catatan dari hasil proyek sebelumnya yang
cukup rinci untuk membantu dalam mengembangkan perkiraan durasi. Di beberapa
area aplikasi, anggota tim individu dapat mempertahankan catatan tersebut.
■ durasi Commercial memperkirakan informasi
database-historis sering
tersedia secara komersial. Database ini cenderung
sangat berguna ketika
jangka waktu kegiatan tidak didorong oleh isi
pekerjaan yang sebenarnya (misalnya, berapa lama
dibutuhkan beton untuk menyembuhkan, berapa lama
sebuah instansi pemerintah biasanya diperlukan untuk
menanggapi beberapa jenis permintaan).
■ Proyek Tim pengetahuan anggota individu dari
tim proyek mungkin
ingat actuals sebelumnya atau perkiraan. Sementara
ingatan tersebut mungkin
berguna, mereka umumnya jauh lebih dapat diandalkan
dibandingkan hasil didokumentasikan.
6.3.2
Alat dan Teknik Estimasi Durasi
Kegiatan.
1.Ahli penghakiman.
Penilaian ahli dijelaskan dalam Bagian 5.1.2.2.
Jangka waktu seringkali sulit untuk memperkirakan karena sejumlah faktor yang
dapat mempengaruhi mereka (misalnya, sumber daya tingkat, produktivitas sumber
daya). Ahli penghakiman dipandu oleh informasi historis harus digunakan bila
memungkinkan. Jika keahlian tersebut tidak tersedia, estimasi secara inheren
tidak pasti dan berisiko (lihat Bab 11, Proyek Manajemen Risiko).
2.Memperkirakan analog.
Estimasi analog, juga disebut top-down estimasi,
berarti menggunakan durasi yang sebenarnya dari kegiatan, sebelumnya sama
sebagai dasar untuk memperkirakan durasi kegiatan masa depan. Hal ini sering
digunakan untuk memperkirakan durasi proyek ketika ada jumlah terbatas
informasi rinci tentang proyek (misalnya, dalam fase awal). Estimasi analog
adalah bentuk penilaian ahli (dijelaskan dalam Bagian 6.3.2.1).
3.Quantitatively berdasarkan jangka waktu.
Jumlah yang akan dilakukan untuk setiap spesifik kerja
kategori (yaitu, jumlah gambar, meter kabel, ton baja, dll) ditentukan oleh
upaya rekayasa / desain, bila dikalikan dengan tingkat produktivitas satuan
(misalnya, jam per gambar, meter kabel per jam, dll ), dapat digunakan untuk
memperkirakan durasi kegiatan.
4.Reserve waktu (contingency).
Tim proyek dapat memilih untuk menggabungkan unit
tambahan waktu nasional frame, disebut waktu cadangan, kontingensi, atau
buffer, yang dapat ditambahkan ke durasi kegiatan atau tempat lain dalam jadwal
sebagai pengakuan risiko.
6.3.3 Keluaran Estimasi Duras Kegiatan.
1. Perkiraan Durasi Kegiatan.
Perkiraan durasi kegiatan bersifat kuantitatif
menilai dari jumlah kemungkinan periode kerja yang akan dibutuhkan untuk
menyelesaikan aktivitas. Sebagai contoh:
■ 2 minggu ± 2 hari untuk menunjukkan bahwa
kegiatan akan memakan waktu minimal delapan hari dan tidak lebih dari dua belas
(dengan asumsi pekan kerja lima hari).
■ 15 persen kemungkinan melebihi tiga minggu
untuk menunjukkan tinggi probabilitas -85 persen-bahwa kegiatan tersebut akan
memakan waktu tiga minggu atau kurang.
Bab 11 tentang Manajemen Risiko Proyek mencakup
diskusi yang lebih rinci memperkirakan ketidakpastian.
2. Dasar perkiraan.
Asumsi yang dibuat dalam mengembangkan perkiraan
harus documented.
3. Daftar Pembaruan Kegiatan.
Kegiatan update daftar dijelaskan dalam Bagian
6.2.3.2.
6.4 PENGEMBANGAN
JADWAL.
Pengembangan jadwal berarti menentukan mulai dan selesai
tanggal untuk aktivitas. Jika tanggal awal dan akhir yang tidak realistis, maka
proyek tidak mungkin selesai sesuai jadwal. Proses pengembangan jadwal
seringkali harus terciptakan (bersama dengan proses yang memberikan masukan,
terutama durasi memperkirakan dan biaya estimasi) sebelum penentuan jadwal
proyek.
6.4.1 Masukan untuk Jadwal Pembangunan.
1.Diagram Jaringan Proyek.
Proyek diagram jaringan dijelaskan dalam Bagian 6.2.3.1.
2. Kegiatan perkiraan durasi.
Kegiatan perkiraan durasi dijelaskan dalam Bagian 6.3.3.1.
3. Kebutuhan sumber daya.
Kebutuhan sumber daya yang dijelaskan dalam Bagian
6.3.1.4.
4. Sumber daya.
Pengetahuan tentang apa yang sumber daya akan
tersedia pada apa dan dalam apa pola yang diperlukan untuk pengembangan jadwal.
Misalnya, sumber daya bersama atau kritis bisa sangat sulit untuk menjadwalkan
sejak mereka berhasil. Kemampuan mungkin sangat bervariasi. Jumlah detail dan
tingkat kekhususan dalam deskripsi kolam sumber daya akan bervariasi. Sebagai
contoh, seseorang hanya perlu tahu bahwa dua konsultan akan tersedia dalam
kerangka waktu tertentu untuk awal jadwal pengembangan proyek konsultasi.
Jadwal akhir untuk hal yang sama proyek, bagaimanapun, mengidentifikasi mana
konsultan khusus akan tersedia.
5. Kalender.
Proyek dan sumber daya kalender mengidentifikasi
periode ketika pekerjaan diperbolehkan. Kalender proyek mempengaruhi semua
sumber daya (misalnya, beberapa proyek akan bekerja hanya selama jam kerja
normal, sementara yang lain akan bekerja tiga shift penuh). Sebuah hari kerja
lima hari adalah contoh dari penggunaan kalender. Kalender sumber daya
mempengaruhi sumber daya yang spesifik atau kategori sumber daya (misalnya,
anggota tim proyek mungkin pada vacation atau dalam program pelatihan, sebuah
kontrak kerja dapat membatasi pekerja tertentu untuk mempertahankan hari dalam
seminggu).
6. Kendala.
Kendala adalah faktor yang akan membatasi pilihan
manajemen proyek tim. Ada dua kategori utama dari kendala waktu dipertimbangkan
selama pengembangan jadwal:
■ tanggal dipaksakan tanggal-mulai dikenakan
pada kegiatan atau selesai dapat digunakan untuk membatasi awal atau akhir
untuk terjadi baik tidak lebih awal dari tanggal yang ditentukan atau tidak selambat-lambatnya
tanggal yang ditentukan. Sementara keempat kendala tanggal biasanya
memanfaatkan perangkat lunak manajemen proyek, yang "Mulai ada Sebelumnya
Than" dan "Finish No Nanti Dari" kendala yang paling sering
digunakan.
7. Asumsi.
Lihat Bagian 4.1.1.5.
8. Memimpin.
Salah satu dependensi mungkin memerlukan spesifikasi
memimpin atau lag untuk secara akurat menentukan hubungan. Contoh dari lag:
mungkin ada keinginan untuk menjadwalkan penundaan dua minggu (lag) antara
memesan peralatan dan menginstal atau menggunakannya. Contoh dari memimpin,
dalam ketergantungan finish-to-start dengan memimpin sepuluh hari: kegiatan
penggantinya dimulai sepuluh hari sebelum pendahulunya telah selesai.
9. Risiko Pengelolaan Rencana.
Rencana manajemen risiko dibahas dalam 11.1.3.
10. Atribut Kegiatan.
Atribut dari tanggung jawab kegiatan-termasuk
(yaitu, yang akan melakukan pekerjaan), wilayah geografis atau bangunan (di
mana pekerjaan harus dilakukan), dan jenis kegiatan (misalnya, ringkasan atau
detail)-sangat penting bagi lanjut seleksi dan penyortiran dari kegiatan yang
direncanakan dengan cara yang nyaman bagi pengguna. WBS klasifikasi juga
merupakan atribut penting yang memungkinkan aktivitas yang berguna memesan dan
menyortir.
6.4.2 Alat dan Teknik untuk Pengembangan Jadwal
1.Analisis Matematis.
Analisis matematis melibatkan perhitungan teoritis awal
dan akhir dan selesai tanggal untuk semua kegiatan proyek tanpa memperhatikan
batasan sumber daya kolam renang. Tanggal yang dihasilkan tidak jadwal,
melainkan menunjukkan periode waktu di mana aktivitas dapat dijadwalkan batas
sumber daya yang diberikan dan kendala lain yang dikenal. Teknik yang paling
dikenal luas analisis matematis adalah:
■ Jalur Metode Kritis (CPM)-menghitung, awal
dan akhir tunggal deterministic mulai dan selesai tanggal untuk setiap kegiatan
berdasarkan tertentu, jaringan sekuensial logika dan perkiraan durasi tunggal.
Fokus CPM menghitung float untuk menentukan kegiatan memiliki fleksibilitas
penjadwalan sedikit. Yang mendasari Algoritma BPT sering digunakan dalam jenis
lain dari analisis matematis.
■ grafis Evaluasi dan Review Teknik (Gert)-memungkinkan
untuk probabilistic pengobatan baik logika jaringan dan perkiraan durasi
aktivitas (misalnya, beberapa kegiatan yang tidak dapat dilakukan sama sekali,
beberapa mungkin dilakukan hanya sebagian, dan lain-lain dapat dilakukan lebih
dari sekali).
■ Program Evaluasi dan Teknik Review
(PERT)-menggunakan rata-rata tertimbang durasi memperkirakan untuk menghitung
durasi aktivitas. Meskipun ada permukaan perbedaan, PERT berbeda dari CPM
terutama karena menggunakan distribusi ini berarti (nilai yang diharapkan)
bukan perkiraan yang paling mungkin awalnya digunakan dalam CPM (lihat Gambar
6-4). PERT sendiri jarang digunakan saat ini.
2.Kompresi Durasi.
Kompresi durasi adalah kasus khusus dari analisis matematika
yang mencari cara untuk mempersingkat jadwal proyek tanpa mengubah lingkup
proyek (misalnya, untuk memenuhi tanggal yang ditetapkan atau tujuan jadwal
lainnya). Kompresi durasi meliputi teknik seperti:
■ Menerjang-di mana biaya dan jadwal
pengorbanan dianalisis untuk menentukan bagaimana, jika sama sekali, untuk
mendapatkan jumlah terbesar dari kompresi untuk sedikit satuan jiwa biaya.
■ Cepat pelacakan-melakukan kegiatan secara
paralel yang biasanya akan dilakukan dalam urutan (misalnya, mulai menulis kode
pada sebuah proyek software sebelum desain selesai, atau mulai membangun
fondasi untuk pengolahan minyak bumi tanaman sebelum titik rekayasa 25 persen
tercapai). Cepat pelacakan sering menghasilkan pengerjaan ulang dan biasanya
meningkatkan risiko.
3. Simulasi.
Simulasi melibatkan menghitung jangka waktu beberapa
proyek dengan different set asumsi aktivitas. Teknik yang paling umum adalah
Monte Carlo Analisis, di mana distribusi hasil kemungkinan didefinisikan untuk
setiap kegiatan dan digunakan untuk menghitung distribusi hasil kemungkinan
untuk total proyek (lihat juga Bagian 11.4.2.4). Selain itu, apa-jika analisis
dapat dibuat dengan menggunakan jaringan logika untuk mensimulasikan skenario
yang berbeda, seperti menunda pengiriman komponen utama, memperpanjang jangka
waktu rekayasa tertentu, atau memperkenalkan faktor eksternal (seperti
pemogokan, atau perubahan dalam proses perijinan) . Hasil dari apa-jika
simulasi dapat digunakan untuk menilai kelayakan dari jadwal dalam kondisi yang
sulit, dan dalam mempersiapkan rencana kontinjensi / penanggulangan untuk
mengatasi atau mengurangi dampak dari situasi yang tidak terduga.
4. Sumber daya meratakan heuristik.
Analisis matematis sering menghasilkan awal-awal
jadwal yang membutuhkan lebih banyak sumber daya selama periode waktu tertentu
dibandingkan waktu yang tersedia, atau membutuhkan perubahan dalam tingkat
sumber daya yang tidak dikelola. Heuristik, seperti, "Mengalokasikan
sumber daya yang langka untuk kegiatan jalur kritis pertama," bisa diterapkan
untuk mengembangkan jadwal yang mencerminkan kendala tersebut. sumber daya
meratakan sering menghasilkan durasi proyek yang lebih panjang dari jadwal
awal.
Teknik ini kadang-kadang disebut metode berbasis
sumber daya, terutama ketika diimplementasikan dengan optimasi komputerisasi.
Sumber daya realokasi dari tidak penting untuk kegiatan kritis adalah cara yang
umum untuk membawa jadwal kembali, atau sebagai sedekat mungkin, untuk awalnya
ditujukan durasi keseluruhan. Pemanfaatan jam diperpanjang, akhir pekan, atau
pergeseran beberapa juga harus dipertimbangkan untuk mengurangi dengan jangka
waktu kegiatan kritis. Beberapa proyek mungkin memiliki waktu terbatas dan
kritis sumber daya proyek, yang mengharuskan sumber daya ini akan dijadwalkan
dalam membalikkan dari proyek berakhir tanggal, ini dikenal sebagai alokasi
sumber daya terbalik penjadwalan. Rantai penting adalah teknik yang mengubah
jadwal proyek untuk account untuk sumber daya yang terbatas.
5. Perangkat lunak manajemen proyek.
Perangkat lunak manajemen secara luas digunakan untuk
membantu pengembangan jadwal. Perangkat lunak lain mungkin mampu berinteraksi secara
langsung atau tidak langsung dalam diri mereka sendiri, atau dengan perangkat
lunak lain, untuk melaksanakan persyaratan bidang pengetahuan lainnya.
Produk-produk mengotomatisasi perhitungan analisis matematis dan meratakan
sumber daya, dan dengan demikian memungkinkan untuk pertimbangan cepat
alternatif jadwal banyak. Mereka juga banyak digunakan untuk mencetak atau
menampilkan output dari pengembangan jadwal.
6. Struktur Pengkodean.
Kegiatan harus memiliki struktur coding yang akan
memungkinkan menyortir dan / atau pencabutan berdasarkan atribut yang berbeda
ditugaskan untuk kegiatan, seperti tanggung jawab, wilayah geografis atau
bangunan, fase proyek, tingkat jadwal, jenis kegiatan, dan klasifikasi WBS.
6.4.3 Keluaran Pengembangan Jadwal.
1. Jadwal Proyek.
Jadwal proyek mencakup setidaknya mulai direncanakan
dan diharapkan menyelesaikan tanggal untuk setiap kegiatan. (Catatan:.. Jadwal
proyek masih awal sampai tugas sumber daya telah dikonfirmasi ini biasanya akan
terjadi selambat-lambatnya penyelesaian Rencana Pembangunan Proyek, Bagian 4.1).
Jadwal proyek dapat disajikan dalam bentuk ringkasan (jadwal master),
atau secara rinci. Meskipun dapat disajikan dalam
bentuk tabel, itu lebih sering presented grafis, menggunakan salah satu atau
lebih dari format berikut:
■ diagram jaringan Proyek dengan informasi
tanggal ditambahkan (lihat Gambar 6-5). Ini grafik biasanya menunjukkan baik
logika proyek dan jalur kritis proyek (lihat Bagian 6.2.3.1 untuk informasi
lebih lanjut tentang diagram jaringan proyek).
■ Bar grafik, grafik Gantt juga disebut (lihat
Gambar 6-6), mulai menunjukkan aktivitas dan tanggal berakhir, serta jangka
waktu yang diharapkan, dan kadang-kadang menampilkan dependensi. Mereka relatif
mudah dibaca, dan sering digunakan dalam manajemen presentations.
■ Milestone grafik (lihat Gambar 6-7) mirip
dengan bar chart, tetapi hanya mengidentifikasi awal terjadwal atau penyelesaian
penyerahan utama dan kunci eksternal.
2. Pendukung detail.
Mendukung detail untuk jadwal proyek mencakup
setidaknya documentation dari semua asumsi diidentifikasi dan kendala. Jumlah rinci
internasional bervariasi berdasarkan wilayah aplikasi. Sebagai contoh:
■ Pada proyek konstruksi, maka kemungkinan
besar akan termasuk barang-barang seperti sumber daya histogram, proyeksi arus
kas, dan ketertiban dan jadwal pengiriman.
■ Pada proyek elektronik, maka kemungkinan
besar akan termasuk histogram sumber daya saja.
■ Kebutuhan sumberdaya oleh periode waktu,
seringkali dalam bentuk sumber daya histogram.
■ Alternatif jadwal (misalnya, kasus terbaik
atau terburuk, sumber daya diratakan atau tidak, dengan atau tanpa tanggal yang
ditetapkan).
■ cadangan kontingensi Jadwal (lihat Bagian
11.4).
3. Jadwal rencana pengelolaan.
Sebuah rencana pengelolaan jadwal mendefinisikan
bagaimana perubahan jadwal akan dikelola. Ini mungkin formal atau informal,
sangat rinci atau luas dibingkai, berdasarkan pada kebutuhan proyek. Ini adalah
elemen anak dari rencana proyek secara keseluruhan (lihat Bagian 4.1).
4. Sumber daya persyaratan pembaruan.
Sumber daya update meratakan mungkin memiliki
pengaruh yang signifikan terhadap perkiraan awal kebutuhan sumber daya.
6.5 PENGAWASAN JADWAL.
Pengawasan jadwal berkaitan dengan yang mempengaruhi
faktor-faktor yang membuat jadwal perubahan untuk memastikan bahwa perubahan
yang disepakati, b) menentukan bahwa jadwal telah berubah, dan c) mengelola
perubahan yang sebenarnya kapan dan karena mereka terjadi. Jadwal kontrol harus
benar-benar terintegrasi dengan kontrol lainnya proses, seperti yang dijelaskan
dalam Bagian 4.3, Integrated Change Control.
6.5.1 Masukan untuk Jadwal Kontrol
1. Jadwal Proyek.
Jadwal proyek dijelaskan dalam Bagian 6.4.3.1. Itu disetujui
jadwal proyek, yang disebut dasar jadwal (yang harus layak secara teknis dan
dalam hal sumber daya), adalah komponen dari rencana proyek yang dijelaskan
dalam Bagian 4.1.3.1. Ini menyediakan dasar untuk pengukuran dan pelaporan
kinerja jadwal.
2. Kinerja laporan.
Kinerja laporan, dibahas dalam Bagian 10.3.3.1,
memberikan informasi tentang kinerja jadwal, seperti yang direncanakan tanggal
telah terpenuhi dan yang belum. Laporan kinerja juga dapat mengingatkan tim
proyek untuk isu-isu yang dapat menyebabkan masalah di masa depan.
3. Mengubah permintaan.
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 memperpanjang jadwal atau memungkinkan percepatan itu (lihat Bagian
4.3.1.3).
4. Rencana Pengelolaan Jadwal.
Rencana pengelolaan jadwal dijelaskan dalam Bagian 6.4.3.3.
6.5.2 Alat dan Teknik Pengawasan Jadwal.
1. Jadwal perubahan sistem kendali.
Sebuah perubahan jadwal sistem kontrol
mendefinisikan prosedur dimana jadwal proyek dapat diubah. Ini mencakup
dokumen, sistem pelacakan, dan tingkat persetujuan yang diperlukan untuk
perubahan otorisasi. Jadwal perubahan kontrol harus diintegrasikan dengan
sistem kontrol perubahan yang terintegrasi dijelaskan dalam Bagian 4.3.
2. Pengukuran kinerja.
Pengukuran kinerja teknik seperti yang dijelaskan
dalam Bagian 10.3.2 bantuan untuk menilai besarnya setiap variasi yang memang
terjadi. Suatu bagian penting dari pengendalian jadwal adalah untuk memutuskan
apakah jadwal variable membutuhkan tindakan korektif. Misalnya, penundaan besar
pada noncritical.
3. Perencanaan Tambahan.
Beberapa proyek berjalan tepat sesuai rencana. Perubahan
mungkin memerlukan estimasi durasi aktivitas baru atau direvisi, aktivitas
dimodifikasi urutan, atau analisis jadwal alternatif.
4. Proyek perangkat lunak manajemen.
Proyek perangkat lunak manajemen dijelaskan dalam
bagian 6.4.2.5. Kemampuan perangkat lunak manajemen proyek untuk melacak
tanggal yang direncanakan dibandingkan tanggal yang sebenarnya dan untuk
meramalkan efek dari perubahan jadwal, nyata atau potensial, membuatnya menjadi
alat yang berguna untuk pengendalian jadwal.
5. Varians analisis.
Kinerja analisis varians selama Proses monitoring
merupakan elemen kunci untuk mengontrol waktu. Membandingkan tanggal target
dengan start aktual / perkiraan dan tanggal selesai menyediakan informasi yang
berguna untuk deteksi penyimpangan dan untuk implementasi solusi korektif dalam
kasus penundaan. Varians mengapung juga merupakan komponen penting untuk
mengevaluasi perencanaan proyek. Waktu-kinerja. Perhatian khusus harus
diberikan kepada kritis dan subkritis kegiatan (yaitu, menganalisis sepuluh
jalur subkritis, dalam urutan menaik float).
6.5.3 Keluaran dari Control Jadwal
1. Jadwal update.
Pembaruan jadwal modifikasi jadwal information yang
digunakan untuk mengelola proyek. Stakeholder yang tepat harus diberitahu
sesuai kebutuhan. Jadwal update mungkin atau mungkin tidak memerlukan
penyesuaian aspek-aspek lain dari rencana proyek. Revisi adalah kategori khusus
update jadwal. Revisi adalah perubahan jadwal mulai dan selesai tanggal dalam
jadwal proyek disetujui. Perubahan umumnya dimasukkan dalam menanggapi
perubahan lingkup atau perubahan perkiraan. Dalam beberapa kasus, penundaan
jadwal mungkin begitu parah sehingga rebaselining dibutuhkan untuk menyediakan
data yang realistis untuk mengukur kinerja. Namun, perawatan harus diambil
sebelum rebaselining, sebagai data sejarah akan hilang untuk jadwal proyek. Rebaselining
seharusnya hanya digunakan sebagai pilihan terakhir dalam mengendalikan jadwal,
jadwal target harus menjadi modus normal revisi jadwal.
2. Tindakan korektif.
Tindakan korektif adalah segala sesuatu dilakukan
untuk membawa masa depan yang diharapkan menjadwalkan kinerja sejalan dengan
rencana proyek. Tindakan korektif di daerah manajemen waktu sering melibatkan
mempercepat: tindakan-tindakan khusus diambil untuk memastikan penyelesaian
kegiatan tepat waktu atau dengan penundaan sesedikit mungkin. Tindakan sering
memerlukan akar-penyebab analisis untuk mengidentifikasi penyebab dari variasi,
dan pemulihan jadwal dapat direncanakan dan dilaksanakan untuk kegiatan
digambarkan, kemudian dalam jadwal dan tidak perlu hanya menangani kegiatan
menyebabkan penyimpangan.
3. Level pembelajaran.
Penyebab varians, alasan di balik korektif tindakan
yang dipilih, dan jenis-jenis pelajaran dari kontrol jadwal harus didokumentasikan,
sehingga mereka menjadi bagian dari database historis untuk kedua ini proyek
dan proyek-proyek lain dari organisasi yang melakukan.
Project Time Management (PMBOK Chapter 6)
Project
Time Management includes the processes required to ensure timely completion of
the project. Figure 6-1 provides an overview of the following major processes
in developing the project time schedule:
6.1 Activity Definition
—identifying the specific activities that must be performed to produce the
various project deliverables.
6.2 Activity Sequencing
—identifying and documenting interactivity dependencies.
6.3Activity Duration Estimating
—estimating the number of work periods that will be needed to complete
individual activities.
6.4 Schedule Development
—analyzing activity sequences, activity durations, and resource requirements to
create the project schedule.
6.5 Schedule Control
—controlling changes to the project schedule.
These
processes interact with each other and with the processes in the other knowledge
areas as well. Each process may involve effort from one or more individuals or
groups of individuals, based on the needs of the project. Each process generally
occurs at least once in every project phase.
Although
the processes are presented here as discrete elements with well defined
interfaces, in practice they may overlap and interact in ways not detailed here.
Process interactions are discussed in detail in Chapter 3.
On
some projects, especially smaller ones, activity sequencing, activity duration
estimating, and schedule development are so tightly linked that they are viewed
as a single process (e.g., they may be performed by a single individual over a
relatively short period of time). They are presented here as distinct processes
because the tools and techniques for each are different.
6.1 ACTIVITY DEFINITION
Activity
definition involves identifying and documenting the specific activities that
must be performed to produce the deliverables and subdeliverables identified in
the Work Breakdown Structure (WBS). Implicit in this process is the need to
define the activities such that the project objectives will be met.
6.1.1 Inputs to Activity Definition
.1 Work breakdown
structure.
The WBS is the primary input to activity definition (see Section
5.3.3.1 for a more detailed discussion of the WBS).
.2 Scope statement.
The
project justification and the project objectives contained in the scope
statement must be considered explicitly during activity definition (see Section
5.2.3.1 for a more detailed discussion of the scope statement).
.3 Historical
information.
Historical information (what activities were actually required on
previous, similar projects) should be considered in defining project activities.
.4 Constraints.
Constraints
are factors that will limit the project management team’s options; an example
would be the use of desired maximum activity durations.
.5 Assumptions.
See
Section 4.1.1.5.
.6 Expert judgment.
Expert
judgment is discussed in Sections 5.1.2.2 and 6.3.2.1.
6.1.2 Tools and Techniques for Activity Definition
.1 Decomposition.
Within
the context of the process of Activity Definition, decomposition involves
subdividing project work packages into smaller, more manageable components to
provide better management control. The technique of decomposition is described
in more detail in Section 5.3.2.2. The major difference between decomposition
here and in Scope Definition is that the final outputs here are described as
activities rather than as deliverables. The WBS and the activity list are
usually developed sequentially, with the WBS being the basis for\ development
of the final activity list. In some application areas, the WBS and the activity
list are developed concurrently.
.2 Templates.
An
activity list (described in Section 6.1.3.1), or a portion of an activity list
from a previous project, is often usable as a template for a new project. The
activities in templates can also contain a list of resource skills and their
required hours of effort, identification of risks, expected deliverables, and other
descriptive information.
6.1.3 Outputs from Activity Definition
.1 Activity list.
The
activity list must include all activities that will be performed on the
project. It should be organized as an extension to the WBS to help ensure that it
is complete, and that it does not include any activities that are not required
as part of the project scope. As with
the WBS, the activity list should include descriptions of each activity to
ensure that the project team members will understand how the work is to be
done.
.2 Supporting detail.
Supporting
detail for the activity list should be documented and organized as needed to
facilitate its use by other project management processes. Supporting detail
should always include documentation of all identified assumptions and
constraints. The amount of additional detail varies by application area.
.3 Work breakdown
structure updates.
In using the WBS to identify which activities are needed,
the project team may identify missing deliverables, or may determine that the
deliverable descriptions need to be clarified or corrected. Any such updates
must be reflected in the WBS and related documentation, such as cost estimates.
These updates are often called
refinements and are most likely
when the project involves new or unproven technology.
6.2
ACTIVITY SEQUENCING
Activity sequencing
involves identifying and documenting interactivity logical relationships.
Activities must be sequenced accurately to support later development of a realistic
and achievable schedule. Sequencing can be performed with the aid of a computer
(e.g., by using project management software) or with manual techniques. Manual
techniques are often more effective on smaller projects and in the early phases
of larger ones when little detail is available. Manual and automated techniques
may also be used in combination.
6.2.1 Inputs to Activity Sequencing
.1 Activity list.
The activity
list is described in Section 6.1.3.1.
.2 Product description.
The product description is discussed in Section 5.1.1.1. Product
characteristics often affect activity sequencing (e.g., the physical layout of
a plant to be constructed, subsystem interfaces on a software project). While these
effects are often apparent in the activity list, the product description should
generally be reviewed to ensure accuracy.
3
Mandatory dependencies.
Mandatory dependencies are those that are inherent in
the nature of the work being done. They often involve physical limitations. (On
a construction project, it is impossible to erect the superstructure until
after the foundation has been built; on an electronics project, a prototype
must be built before it can be tested.) Mandatory dependencies are also
called hard logic .
.4 Discretionary
dependencies.
Discretionary dependencies are those that are defined by the
project management team. They should be used with care (and fully documented),
since they may limit later scheduling options. Discretionary dependencies are
usually defined based on knowledge of:
ٱ “Best practices”
within a particular application area.
ٱ Some unusual aspect
of the project where a specific sequence is desired, even though there are
other acceptable sequences. Discretionary dependencies may also be called preferred logic , preferential logic , or soft logic .
.5 External
dependencies.
External dependencies are those that involve a relationship
between project activities and nonproject activities. For example, the testing activity
in a software project may be dependent on delivery of hardware from an external
source, or environmental hearings may need to be held before site preparation
can begin on a construction project.
.6 Milestones.
Milestone
events need to be part of the activity sequencing to assure that the
requirements for meeting the milestone(s) are met.
6.2.2 Tools and Techniques for Activity Sequencing
.1 Precedence
diagramming method (PDM).
This is a method of constructing a project network
diagram that uses boxes or rectangles (nodes) to represent the activities and connects
them with arrows that show the dependencies (see also Section 6.2.3.1). Figure
6-2 shows a simple network logic diagram
drawn using PDM. This technique is also called activity-on-node (AON) and is the method used by most project
management software packages. PDM can be done manually or on a computer.
It includes four types
of dependencies or precedence relationships:
ٱ Finish-to-start—the
initiation of the work of the successor depends upon the completion of the work
of the predecessor.
ٱ Finish-to-finish—the
completion of the work of the successor depends upon the completion of the work
of the predecessor.
ٱ Start-to-start—the
initiation of the work of the successor depends upon the initiation of the work
of the predecessor.
ٱ Start-to-finish—the
completion of the successor is dependent upon the initiation of the
predecessor.
In PDM, finish-to-start
is the most commonly used type of logical relationship. Start-to-finish
relationships are rarely used, and then typically only by professional
scheduling engineers. Using start-to-start, finish-to-finish, or
start-to-finish relationships with project management software can produce
unexpected results, since these types of relationships have not been
consistently implemented.
.2 Arrow diagramming
method (ADM).
This method of constructing a project network diagram uses arrows
to represent the activities and connects them at nodes to show their
dependencies (see also Section 6.2.3.1).
Figure 6-3 shows a simple network
logic diagram drawn using ADM. This technique is also called activity on-arrow (AOA) and, although less prevalent than PDM,
is still the technique of choice in some application areas. ADM uses only
finish-to-start dependencies and may require the use of dummy activities to
define all logical relationships correctly. ADM can be done manually or on a
computer.
.3 Conditional
diagramming methods.
Diagramming techniques such as Graphical Evaluation and
Review Technique (GERT) and System Dynamics models allow for nonsequential
activities such as loops (e.g., a test that must be repeated more than once) or
conditional branches (e.g., a design update that is only needed if the
inspection detects errors). Neither PDM nor ADM allows loops or conditional branches.
.4 Network templates.
Standardized
networks can be used to expedite the preparation of project network diagrams.
They can include an entire project or only a portion of it. Portions of a
network are often referred to as
subnets or fragnets . Subnets are especially useful when
a project includes several identical or nearly identical features, such as
floors on a high-rise office building, clinical trials on a pharma ceutical
research project, program modules on a software project, or the start-up phase
of a development project.
6.2.3 Outputs from Activity Sequencing
.1 Project network
diagrams.
Project network diagrams are schematic displays of the project’s
activities and the logical relationships (dependencies) among them. Figures 6-2 and
6-3 illustrate two different
approaches to drawing a project network diagram. A project network diagram
may be produced manually or on a computer. It may include full project details,
or have one or more summary activities (hammocks). The diagram should be
accompanied by a summary narrative that describes the basic sequencing
approach. Any unusual sequences should be fully described. A project network
diagram is often referred to as a PERT chart. Historically PERT (Program
Evaluation and Review Technique) was a specific type of network diagram (see
also Section 6.4.2.1).
.2 Activity list
updates.
In much the same manner that the activity definition process may
generate updates to the WBS, preparation of project network diagrams may reveal
instances where an activity must be divided or otherwise redefined to diagram
the correct logical relationships.
6.3
ACTIVITY DURATION ESTIMATING
Activity duration
estimating is the process of taking information on project scope and resources
and then developing durations for input to schedules. The inputs for the
estimates of duration typically originate from the person or group on the project
team who is most familiar with the nature of a specific activity. The estimate
is often progressively elaborated, and the process considers the quality and availability
of the input data. Thus, the estimate can be assumed to be progressively more
accurate and of known quality. The person or group on the project team who is
most familiar with the nature of a specific activity should make, or at least
approve, the estimate.
Estimating the number
of work periods required to complete an activity will often require
consideration of elapsed time as well. For example, if “concrete curing” will
require four days of elapsed time, it may require from two to four work
periods, based on a) which day of the week it begins, and b) whether or not weekend
days are treated as work periods. Most computerized scheduling software will
handle this problem by using alternative work-period calendars.
Overall project
duration may also be estimated using the tools and techniques presented here,
but it is more properly calculated as the output of schedule development
(described in Section 6.4). The project team can consider the project duration
a probability distribution (using probabilistic techniques) or as a single point
estimate (using deterministic techniques).
6.3.1 Inputs to Activity Duration Estimating.
.1 Activity list.
The
activity list is described in Section 6.1.3.1.
.2 Constraints.
Constraints
are described in Section 6.1.1.4.
.3 Assumptions.
Assumptions
are described in Section 4.1.1.5. An example would be reporting periods for the
duration of the project that could dictate maximum durations, i.e., two
reporting periods.
.4 Resource
requirements.
Resource requirements are described in Section 7.1.3.1. The
duration of most activities will be significantly influenced by the resources assigned
to them. For example, two people working together may be able to complete a
design activity in half the time it takes either of them individually, while a
person working half time on an activity will generally take at least twice as
much time as the same person working full time. However, as additional resources
are added, projects can experience communication overload, which reduces
productivity and causes production to improve proportionally less than the
increase in resource.
.5 Resource
capabilities.
The duration of most activities will be significantly influenced
by the capabilities of the human and material resources assigned to them. For
example, if both are assigned full time, a senior staff member can generally be
expected to complete a given activity in less time than a junior staff member.
.6 Historical
information.
Historical information on the likely durations of many categories
of activities is often available from one or more of the following sources:
ٱ Project files—one or
more of the organizations involved in the project may maintain records of
previous project results that are detailed enough to aid in developing duration
estimates. In some application areas, individual team members may maintain such
records.
ٱ Commercial duration
estimating databases—historical information is often available commercially.
These databases tend to be especially useful when activity durations are not
driven by the actual work content (e.g., how long it takes concrete to cure;
how long a government agency usually takes to respond to certain types of
requests).
ٱ Project team
knowledge—the individual members of the project team may remember previous
actuals or estimates. While such recollections may be useful, they are generally
far less reliable than documented results.
.7 Identified risks.
The
project team considers information on identified risks (see Section 11.2) when
producing estimates of activity durations, since risks (either threats or
opportunities) can have a significant influence on duration. The project team
considers the extent to which the effect of risks is included in the baseline duration
estimate for each activity, including risks with high probabilities or impact.
6.3.2 Tools and Techniques for Activity Duration
Estimating
.1 Expert judgment.
Expert
judgment is described in Section 5.1.2.2. Durations are often difficult to
estimate because of the number of factors that can influence them (e.g.,
resource levels, resource productivity). Expert judgment guided by historical
information should be used whenever possible. If such expertise is not available,
the estimates are inherently uncertain and risky (see Chapter 11, Project Risk
Management).
.2 Analogous
estimating.
Analogous estimating, also called
top-down estimating , means using the actual duration of a previous,
similar activity as the basis for estimating the duration of a future activity.
It is frequently used to estimate project duration when there is a limited
amount of detailed information about the project (e.g., in the early phases).
Analogous estimating is a form of expert judgment (described in Section
6.3.2.1). Analogous estimating is most reliable when a) the previous activities
are similar in fact and not just in appearance, and b) the individuals
preparing the estimates have the needed expertise.
.3 Quantitatively based
durations.
The quantities to be performed for each specific work category
(i.e., number of drawing, meters of cable, tons of steel, etc.) defined by the
engineering/design effort, when multiplied by the productivity unit rate (i.e.,
hours per drawing, meters of cable per hour, etc.), can be used to estimate
activity durations.
.4 Reserve time
(contingency).
Project teams may choose to incorporate an additional time
frame, called time reserve , contingency , or buffer , that can be added to the activity
duration or elsewhere in the schedule as recognition of schedule risk. This
reserve time can be a percentage of the estimated duration, or a fixed number
of work periods. The reserve time can later be reduced or eliminated, as more
precise information about the project becomes available. Such reserve time should
be documented along with other data and assumptions.
6.3.3 Outputs from Activity Duration Estimating
.1 Activity duration
estimates.
Activity duration estimates are quantitative assessments of the
likely number of work periods that will be required to complete an activity. Activity
duration estimates should always include some indication of the range of
possible results. For example:
ٱ 2 weeks ± 2 days to
indicate that the activity will take at least eight days and no more than
twelve (assuming a five-day workweek).
ٱ 15 percent
probability of exceeding three weeks to indicate a high probability—85
percent—that the activity will take three weeks or less. Chapter 11 on Project
Risk Management includes a more detailed discussion of estimating uncertainty.
.2 Basis of estimates.
Assumptions
made in developing the estimates must be documented.
.3 Activity list
updates.
Activity list updates are described in Section 6.2.3.2.
6.4
SCHEDULE DEVELOPMENT
Schedule development
means determining start and finish dates for project activities. If the start
and finish dates are not realistic, then the project is unlikely to be finished
as scheduled. The schedule development process must often be iterated (along
with the processes that provide inputs, especially duration estimating and cost
estimating) prior to determination of the project schedule.
6.4.1 Inputs to Schedule Development
.1 Project network
diagrams.
Project network diagrams are described in Section 6.2.3.1.
.2 Activity duration
estimates.
Activity duration estimates are described in Section 6.3.3.1.
.3 Resource
requirements.
Resource requirements are described in Section 6.3.1.4.
.4 Resource pool
description.
Knowledge of what resources will be available at what times and in
what patterns is necessary for schedule development. For example, shared or
critical resources can be especially difficult to schedule since their
availability may be highly variable. The amount of detail and the level of
specificity in the resource pool description will vary. For example, one need
only know that two consultants will be available in a particular time frame for
preliminary schedule development of a consulting project. The final schedule
for the same project, however, identifies which specific consultants will be
available.
. 5 Calendars.
Project
and resource calendars identify periods when work is allowed. Project
calendars affect all resources (e.g.,
some projects will work only during normal business hours, while others
will work a full three shifts). A five-day workweek is an example of calendar
usage. Resource calendars affect a specific resource or category of
resources (e.g., a project team member may be on vacation or in a training
program; a labor contract may limit certain workers to certain days of the
week).
.6 Constraints.
Constraints
are factors that will limit the project management team’s options. There are
two major categories of time constraints considered during schedule
development:
ٱ Imposed dates—imposed
dates on activity starts or finishes can be used to restrict the start or
finish to occur either no earlier than a specified date or no later than a
specified date. While all four date constraints are typically available in
project management software, the “Start No Earlier Than” and the “Finish No
Later Than” constraints are the most commonly used. Typical uses of date
constraints include such situations as a market window on a technology project,
weather restrictions on outdoor activities, government man dated compliance
with environmental remediation, delivery of material from parties not
represented in the project schedule, etc.
ٱ Key events or major
milestones—completion of certain deliverables by a specified date may be requested
by the project sponsor, the project customer, or other stakeholders.
Once scheduled, these dates become expected and often may be moved only with
great difficulty. Milestones may also be used to indicate interfaces with work
outside of the project. Such work is typically not in the project database, and
milestones with constraint dates can provide the appropriate schedule
interface.
.7 Assumptions.
See
Section 4.1.1.5.
.8 Leads and lags.
Any
of the dependencies may require specification of a lead or a lag to accurately
define the relationship. An example of a lag: there might be a desire to
schedule a two-week delay (lag) between ordering a piece of equipment and
installing or using it. An example of a lead, in a finish-to-start dependency with
a ten-day lead: the successor activity starts ten days before the predecessor has
completed.
.9 Risk management
plan.
The risk management plan is discussed in 11.1.3.
.10 Activity
attributes.
Attributes of the activities—including responsibility (i.e., who will
perform the work), geographic area or building (where the work has to be performed),
and activity type (i.e., summary or detailed)—are very important for further
selection and sorting of the planned activities in a convenient way for the users.
WBS classification is also an important attribute that allows useful activity ordering
and sorting.
6.4.2 Tools and Techniques for Schedule Development
.1 Mathematical
analysis.
Mathematical analysis involves calculating theoretical early and late
start and finish dates for all project activities without regard for any
resource pool limitations. The resulting dates are not the schedule, but rather
indicate the time periods within which the activity could
be scheduled given resource limits and other known constraints. The most
widely known mathematical analysis techniques are:
ٱ Critical Path Method
(CPM)—calculates a single, deterministic early and late start and finish date
for each activity based on specified, sequential network logic and a single
duration estimate. The focus of CPM is calculating float
to determine which activities have the least scheduling flexibility. The
underlying CPM algorithms are often used in other types of mathematical
analysis.
ٱ Graphical Evaluation
and Review Technique (GERT)—allows for probabilistic treatment of both network
logic and activity duration estimates (i.e., some activities may not be
performed at all, some may be performed only in part, and others may be
performed more than once).
ٱ Program Evaluation
and Review Technique (PERT)—uses a weighted average duration estimate to
calculate activity durations. Although there are surface differences, PERT
differs from CPM primarily in that it uses the distribution’s mean (expected
value) instead of the most likely estimate originally used in CPM (see Figure 6-4 ). PERT itself is seldom used
today.
.2 Duration
compression.
Duration compression is a special case of mathematical analysis
that looks for ways to shorten the project schedule without changing the project
scope (e.g., to meet imposed dates or other schedule objectives). Duration
compression includes techniques such as:
ٱ Crashing—in which
cost and schedule tradeoffs are analyzed to determine how, if at all, to obtain
the greatest amount of compression for the least incremental cost. Crashing
does not always produce a viable alternative and often results in increased
cost.
ٱ Fast tracking—doing
activities in parallel that would normally be done in sequence (e.g., starting
to write code on a software project before the design is complete, or starting
to build the foundation for a petroleum processing plant before the 25 percent
engineering point is reached). Fast tracking often results in rework and
usually increases risk.
.3 Simulation.
Simulation
involves calculating multiple project durations with different sets of activity
assumptions. The most common technique is Monte Carlo Analysis, in which a
distribution of probable results is defined for each activity and used to
calculate a distribution of probable results for the total project (see also
Section 11.4.2.4). In addition,
what-if analyses can be made
using the logic network to simulate different scenarios, such as delaying a
major component delivery, extending specific engineering durations, or
introducing external factors (such as a strike, or a change in the permitting
process). The outcome of the what-if simulations can be used to assess the
feasibility of the schedule under adverse conditions, and in preparing contingency/response
plans to overcome or mitigate the impact of unexpected situations.
.4 Resource leveling
heuristics.
Mathematical analysis often produces a preliminary early-start schedule that requires more resources during
certain time periods than are available, or requires changes in resource
levels that are not manageable. Heuristics, such as, “Allocate scarce resources
to critical path activities first,” can be applied to develop a schedule that
reflects such constraints. Resource leveling often results in a project
duration that is longer than the preliminary schedule. This technique is
sometimes called the resource-based
method , especially when implemented with computerized optimization. Resource
reallocation from non critical to critical activities is a common way to bring
the schedule back, or as close as possible, to its originally intended overall
duration. Utilization of extended hours, weekends, or multiple shifts should
also be considered to reduce the durations of critical activities. Productivity
increases based on the use of different technologies and/or machinery (i.e.,
automatic welding, electrical pipe cutters, etc.) are another way to shorten
durations that have extended the preliminary schedule. Fact tracking, if
feasible (as described in Section 6.4.2.2), is another way to reduce the
overall project duration. Some projects may have a finite and critical project
resource, requiring that this resource be scheduled in reverse from the project
ending date; this is known as reverse
resource allocation scheduling . Critical chain is a technique that modifies
the project schedule to account for limited resources.
.5 Project management
software.
Project management software is widely used to assist with schedule
development. Other software may be capable of interacting directly or
indirectly within themselves, or with other software, to carry out the requirements
of other knowledge areas. These products automate the calculation
of the mathematical
analysis and resource leveling, and thus allow for rapid consideration of many
schedule alternatives. They are also widely used to print or display the
outputs of schedule development.
.6 Coding structure.
The
activities should have a coding structure that will allow sorting and/or
extractions based on different attributes assigned to the activities, such as
responsibility, geographic area or building, project phase, schedule level, activity
type, and WBS classification.
6.4.3 Outputs from Schedule Development
.1 Project schedule.
The
project schedule includes at least planned start and expected finish dates for
each activity. (Note: The project schedule remains preliminary until resource
assignments have been confirmed. This would usually happen no later than the
completion of Project Plan Development, Section 4.1.) The project schedule may
be presented in summary form (the master
schedule ), or in detail. Although it can be presented in tabular form, it is
more often presented graphically, using one or more of the following formats:
ٱ Project network
diagrams with date information added (see
Figure 6-5 ). These charts usually show both the project logic and the
project’s critical path activities (see Section 6.2.3.1 for more information on
project network diagrams).
Bar charts, also called Gantt charts
(see Figure 6-6 ), show activity
start and end dates, as well as expected durations, and sometimes show
dependencies. They are relatively easy to read, and are frequently used in
management presentations.
ٱ Milestone charts
(see Figure 6-7 ) are similar to bar
charts, but only identify the scheduled start or completion of major
deliverables and key external inter faces.
.2 Supporting detail.
Supporting
detail for the project schedule includes at least documentation of all
identified assumptions and constraints. The amount of additional detail varies
by application area. For example:
ٱ On a construction
project, it will most likely include such items as resource histograms,
cash-flow projections, and order and delivery schedules.
ٱ On an electronics
project, it will most likely include resource histograms only. Information
frequently supplied as supporting detail includes, but is not limited to:
ٱ Resource requirements
by time period, often in the form of a resource histogram.
ٱ Alternative schedules
(e.g., best case or worst case, resource leveled or not, with or without
imposed dates).
ٱ Schedule contingency
reserves (see Section 11.4).
.3 Schedule management
plan.
A schedule management plan defines how changes to the schedule will be
managed. It may be formal or informal, highly detailed or broadly framed, based
on the needs of the project. It is a subsidiary element of the overall project
plan (see Section 4.1).
.4 Resource requirement
updates.
Resource leveling updates may have a significant effect on preliminary
estimates of resource requirements.
6.5
SCHEDULE CONTROL
Schedule control is
concerned with a) influencing the factors that create schedule changes to
ensure that changes are agreed upon, b) determining that the schedule has
changed, and c) managing the actual changes when and as they occur. Schedule
control must be thoroughly integrated with the other control processes, as
described in Section 4.3, Integrated Change Control.
6.5.1 Inputs to Schedule Control.
.1 Project schedule.
The
project schedule is described in Section 6.4.3.1. The approved project
schedule, called the schedule
baseline (which must be feasible technically
and in terms of resources), is a component of the project plan described in
Section 4.1.3.1. It provides the basis for measuring and reporting schedule
performance.
.2 Performance reports.
Performance reports, discussed in Section 10.3.3.1, provide information on
schedule performance, such as which planned dates have been met and which have
not. Performance reports may also alert the project team to issues that may
cause problems in the future.
.3 Change requests.
Change
requests may occur in many forms—oral or written, direct or indirect, externally
or internally initiated, and legally mandated or optional. Changes may require
extending the schedule or may allow accelerating it (see Section 4.3.1.3).
.4 Schedule management
plan.
The schedule management plan is described in Section 6.4.3.3.
6.5.2 Tools and Techniques for Schedule Control
.1 Schedule change
control system.
A schedule change control system defines the procedures by
which the project schedule may be changed. It includes the paperwork, tracking
systems, and approval levels necessary for authorizing changes. Schedule change
control should be integrated with the integrated change control system
described in Section 4.3.
.2 Performance
measurement.
Performance measurement techniques such as those described in
Section 10.3.2 help to assess the magnitude of any variations that do occur. An
important part of schedule control is to decide if the schedule variation
requires corrective action. For example, a major delay on a noncritical activity
may have little effect on the overall project, while a much shorter delay on a
critical or near-critical activity may require immediate action.
.3 Additional planning.
Few projects run exactly according to plan. Prospective changes may require new
or revised activity duration estimates, modified activity sequences, or
analysis of alternative schedules.
.4 Project management
software.
Project management software is described in Section 6.4.2.5. The
ability of project management software to track planned dates versus actual
dates and to forecast the effects of schedule changes, real or potential, makes
it a useful tool for schedule control.
.5 Variance analysis.
Performance
of the variance analysis during the schedule monitoring process is a key
element for time control. Comparing target dates with the actual/forecast start
and finish dates provides useful information for the detection of deviations
and for the implementation of corrective solutions in case of delays. The float
variance is also an essential planning component to evaluate project time-performance.
Particular attention has to be given to critical and subcritical activities
(i.e., analyzing the ten subcritical paths, in order of ascending float).
6.5.3 Outputs from Schedule Control
.1 Schedule updates.
A
schedule update is any modification to the schedule information that is used to
manage the project. Appropriate stakeholders must be notified as needed.
Schedule updates may or may not require adjustments to other aspects of the
project plan. Revisions are a special
category of schedule updates. Revisions are changes to the schedule start
and finish dates in the approved project schedule. These changes are generally
incorporated in response to scope changes or changes to estimates. In some
cases, schedule delays may be so severe that
rebaselining is needed to provide
realistic data to measure performance. However, care must be taken before
rebaselining, as historical data will be lost for the project schedule. Rebaselining
should only be used as a last resort in controlling the schedule; new target
schedules should be the normal mode of schedule revision.
.2 Corrective action.
Corrective
action is anything done to bring expected future schedule performance in line
with the project plan. Corrective action in the area of time management often
involves expediting: special actions taken to ensure completion of an activity
on time or with the least possible delay. Corrective action frequently requires
root-cause analysis to identify the cause of the variation, and schedule
recovery can be planned and executed for activities delineated later in the
schedule and need not only address the activity causing the deviation.
.3 Lessons learned.
The
causes of variances, the reasoning behind the corrective action chosen, and
other types of lessons learned from schedule control should be documented, so
that they become part of the historical database for both this project and
other projects of the performing organization.
Langganan:
Postingan (Atom)