Proyek Manajemen Waktu

Bab 6
Proyek Manajemen Waktu

Proyek Manajemen Waktu mencakup 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 Kegiatan-Definisi mengidentifikasi kegiatan khusus yang harus dilakukan untuk menghasilkan deliverable proyek berbagai.
6.2 Kegiatan-Sequencing mengidentifikasi dan mendokumentasikan dependensi interaktivitas.
6.3 Durasi Kegiatan Memperkirakan-memperkirakan jumlah periode kerja yang akan dibutuhkan untuk menyelesaikan masing-masing kegiatan.
6.4 Jadwal urutan kegiatan Pengembangan-analisis, jangka waktu kegiatan, dan persyaratan sumber daya untuk membuat jadwal proyek.
6,5 Jadwal Pengendalian-pengendalian 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 KEGIATAN DEFINISI
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 ke Definition Kegiatan
.1 Kerja struktur rincian. WBS adalah masukan utama untuk definisi aktivitas (lihat Bagian 5.3.3.1 untuk diskusi yang lebih rinci tentang WBS).
2 Ruang Lingkup Pernyataan. Pembenaran proyek dan tujuan proyek yang terkandung dalam pernyataan ruang lingkup harus dipertimbangkan secara eksplisit selama definisi aktivitas (lihat Bagian 5.2.3.1 untuk diskusi lebih rinci dari pernyataan lingkup).
.3 Historical informasi. Informasi historis (kegiatan apa yang benar-benar diperlukan pada sebelumnya, proyek serupa) harus dipertimbangkan dalam menentukan kegiatan proyek.
Kendala .4. Kendala adalah faktor yang akan membatasi pilihan manajemen proyek tim, contoh akan penggunaan jangka waktu maksimum yang diinginkan aktivitas.
Asumsi .5. 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 untuk Definisi Kegiatan
.1 Dekomposisi. Dalam konteks proses Definisi Kegiatan, dekomposisi 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 bagian dari ruang lingkup proyek. Seperti dengan WBS, daftar kegiatan harus mencakup
deskripsi dari setiap kegiatan untuk memastikan bahwa anggota tim proyek akan memahami bagaimana pekerjaan yang harus dilakukan.
.2 Mendukung detail. Rinci pendukung untuk daftar kegiatan harus didokumentasikan dan terorganisir sesuai kebutuhan untuk memudahkan penggunaannya oleh proses manajemen proyek lainnya. Mendukung rinci harus selalu menyertakan dokumentasi dari semua asumsi diidentifikasi dan kendala. Jumlah detail tambahan bervariasi berdasarkan wilayah aplikasi.
.3 Update kerusakan struktur Kerja. Dalam menggunakan WBS untuk mengidentifikasi kegiatan yang 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 KEGIATAN SEQUENCING
Sequencing Kegiatan melibatkan mengidentifikasi dan mendokumentasikan hubungan interaktivitas logis. Kegiatan harus diurutkan secara akurat untuk mendukung perkembangan selanjutnya dari jadwal yang realistis dan dapat dicapai. Sequencing dapat dilakukan dengan bantuan komputer (misalnya, dengan menggunakan perangkat lunak manajemen proyek) atau dengan teknik manual. Teknik manual sering lebih efektif pada proyek-proyek yang lebih kecil dan di fase awal yang lebih besar ketika detail kecil yang tersedia. Teknik manual dan otomatis juga dapat digunakan dalam kombinasi.
6.2.1 Masukan ke Sequencing Kegiatan
.1 Kegiatan daftar. Daftar aktivitas 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 Wajib dependensi. Dependensi wajib adalah mereka yang melekat pada sifat pekerjaan yang dilakukan. Mereka sering melibatkan keterbatasan fisik. (Pada proyek konstruksi, adalah mustahil untuk mendirikan suprastruktur sampai setelah pondasi telah dibangun, pada proyek elektronik, prototipe harus dibangun sebelum dapat diuji.) Dependensi Wajib juga disebut logika keras.

 

.4 Discretionary dependensi. Dependensi Discretionary adalah mereka yang ditentukan 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, meskipun ada urutan lain yang dapat diterima.
Dependensi Discretionary juga dapat disebut logika disukai, logika preferensial, atau logika lembut.
.5 Eksternal dependensi. 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 memastikan bahwa persyaratan untuk memenuhi tonggak (s) terpenuhi.

6.2.2 Alat dan Teknik untuk Sequencing Kegiatan
.1 Metode Precedence diagram (PDM). Ini adalah metode membangun diagram proyek jaringan 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 disebut juga kegiatan-on-node (AON) dan merupakan metode yang digunakan oleh paket perangkat lunak manajemen proyek yang paling. PDM dapat dilakukan secara manual atau komputer.
Ini mencakup empat jenis hubungan ketergantungan atau didahulukan:
_ Finish-to-start-inisiasi pekerjaan pengganti tergantung pada penyelesaian karya pendahulunya.
_ Finish-to-finish-penyelesaian pekerjaan pengganti tergantung pada penyelesaian karya pendahulunya.
_ Mulai-to-start-inisiasi pekerjaan pengganti tergantung pada inisiasi karya pendahulunya.
_ Mulai-to-finish-penyelesaian penggantinya adalah tergantung pada inisiasi pendahulunya.
Dalam PDM, finish-to-start adalah jenis yang paling umum digunakan dari hubungan logis. Start-to-finish hubungan yang jarang digunakan, dan kemudian biasanya hanya oleh insinyur penjadwalan profesional. Menggunakan start-to-start, finish-ke-akhir, atau mulai-ke-akhir hubungan dengan perangkat lunak manajemen proyek dapat menghasilkan hasil yang tidak diharapkan, karena ini jenis hubungan belum konsisten dilaksanakan.

 

.2 Metode Panah diagram (ADM). Metode ini membangun sebuah diagram jaringan proyek 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 Diagram metode Bersyarat. Teknik diagram seperti Evaluasi Grafis dan Teknik Ulasan (Gert) dan Dinamika Sistem model memungkinkan untuk kegiatan nonsequential seperti loop (misalnya, tes yang harus diulang lebih dari sekali) atau cabang bersyarat (misalnya, update desain yang hanya diperlukan jika pemeriksaan mendeteksi kesalahan). Baik PDM atau ADM memungkinkan loop atau cabang kondisional.
.4 Jaringan template. Standar jaringan dapat digunakan untuk mempercepat penyusunan diagram jaringan proyek. 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 dari Sequencing Kegiatan
Proyek jaringan diagram .1. Proyek diagram jaringan yang menampilkan skema kegiatan proyek dan hubungan logis (ketergantungan) di antara mereka. Angka 6-2 dan 6-3 menggambarkan dua pendekatan yang berbeda untuk menggambar diagram jaringan proyek. Sebuah diagram jaringan proyek dapat diproduksi secara manual atau komputer. Ini mungkin termasuk rincian proyek penuh, atau memiliki kegiatan ringkasan satu atau lebih (tempat tidur gantung). 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).
Daftar Kegiatan update .2. Dalam banyak cara yang sama bahwa proses definisi aktivitas dapat menghasilkan update 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 KEGIATAN DURASI ESTIMASI
Kegiatan estimasi durasi adalah proses mengambil informasi tentang ruang lingkup proyek dan sumber daya dan kemudian mengembangkan jangka waktu untuk input jadwal. Masukan untuk perkiraan durasi biasanya berasal dari orang atau kelompok tim proyek yang paling akrab dengan sifat dari suatu aktivitas tertentu. Perkiraan tersebut semakin sering diuraikan, dan proses mempertimbangkan kualitas dan ketersediaan data masukan. Dengan demikian, perkiraan tersebut dapat diasumsikan semakin lebih akurat dan kualitas yang dikenal. Orang atau kelompok tim proyek yang paling akrab dengan sifat dari suatu aktivitas tertentu harus membuat, atau setidaknya menyetujui, estimasi.
Memperkirakan jumlah periode kerja yang dibutuhkan untuk menyelesaikan suatu kegiatan akan sering membutuhkan pertimbangan waktu berlalu juga. Misalnya, jika “menyembuhkan beton” akan memerlukan empat hari waktu berlalu, mungkin memerlukan dua sampai empat periode kerja, didasarkan pada) yang hari minggu itu dimulai, dan b) apakah hari akhir pekan diperlakukan sebagai pekerjaan periode. Kebanyakan perangkat lunak penjadwalan komputerisasi 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 Kegiatan daftar. Daftar aktivitas dijelaskan dalam Bagian 6.1.3.1.
Kendala .2. Kendala yang dijelaskan dalam Bagian 6.1.1.4.
Asumsi .3. 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 yang 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, sedangkan orang yang bekerja setengah waktu pada aktivitas yang umumnya akan memakan waktu setidaknya dua kali lebih banyak waktu dengan orang yang sama bekerja penuh waktu. Namun, karena sumber daya tambahan yang 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 akan sangat dipengaruhi oleh kemampuan sumber daya manusia dan materi yang ditugaskan kepada mereka. Misalnya, jika keduanya ditugaskan penuh waktu, anggota staf senior umumnya dapat diharapkan untuk menyelesaikan kegiatan tertentu dalam waktu kurang dari anggota staf junior.
.6 Historical informasi. Informasi sejarah mengenai jangka waktu kemungkinan banyak kategori kegiatan yang sering tersedia dari satu atau lebih dari sumber-sumber berikut:
File-satu Proyek _ atau lebih dari organisasi yang terlibat dalam proyek ini 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 waktu yang dibutuhkan beton untuk menyembuhkan, berapa lama sebuah instansi pemerintah biasanya membutuhkan waktu untuk menanggapi jenis tertentu 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.
.7 Diidentifikasi risiko. Tim proyek menganggap informasi mengenai risiko yang teridentifikasi (lihat Bagian 11.2) ketika memproduksi perkiraan durasi aktivitas, karena risiko (baik ancaman atau peluang) dapat memiliki pengaruh yang signifikan terhadap durasi. Tim proyek menganggap sejauh mana efek dari risiko yang termasuk dalam perkiraan durasi dasar untuk setiap kegiatan, termasuk risiko dengan probabilitas tinggi atau dampak.

6.3.2 Alat dan Teknik untuk Durasi Kegiatan Memperkirakan
.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 Analog estimasi. 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).
Estimasi analog yang paling dapat diandalkan ketika) kegiatan serupa sebelumnya pada kenyataannya dan bukan hanya dalam penampilan, dan b) individu yang mempersiapkan perkiraan memiliki keahlian yang dibutuhkan.
.3 Secara kuantitatif berdasarkan jangka waktu. Jumlah yang akan dilakukan untuk setiap kategori pekerjaan tertentu (misalnya, 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 Cadangan waktu (contingency). Tim proyek dapat memilih untuk memasukkan kerangka waktu tambahan, yang disebut waktu cadangan, kontingensi, atau buffer, yang dapat ditambahkan ke durasi kegiatan atau tempat lain dalam jadwal sebagai pengakuan risiko jadwal. Kali ini cadangan dapat menjadi persentase dari perkiraan durasi, atau sejumlah tetap periode kerja. Waktu cadangan nantinya bisa dikurangi atau dihilangkan, karena informasi yang lebih akurat tentang proyek telah tersedia. Waktu cadangan tersebut harus didokumentasikan bersama dengan data lainnya dan asumsi.

6.3.3 Keluaran dari Durasi Kegiatan Memperkirakan
Perkiraan Kegiatan .1 durasi. Kegiatan perkiraan durasi adalah penilaian kuantitatif jumlah kemungkinan periode kerja yang akan diperlukan untuk menyelesaikan suatu kegiatan. Kegiatan perkiraan durasi harus selalu menyertakan beberapa indikasi dari berbagai hasil yang mungkin. 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 probabilitas tinggi-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 didokumentasikan.
Daftar Kegiatan update .3. Kegiatan update daftar dijelaskan dalam Bagian 6.2.3.2.

6.4 JADWAL PEMBANGUNAN
Jadwal pembangunan berarti menentukan mulai dan selesai tanggal untuk kegiatan proyek. Jika tanggal awal dan akhir yang tidak realistis, maka proyek ini tidak akan selesai sesuai jadwal. Proses pengembangan Jadwal seringkali harus mengulangi (bersama dengan proses yang memberikan masukan, terutama durasi estimasi dan estimasi biaya) sebelum penentuan jadwal proyek.

 

6.4.1 Masukan untuk Jadwal Pembangunan
Proyek jaringan diagram .1. Proyek diagram jaringan dijelaskan dalam Bagian 6.2.3.1.
Perkiraan Kegiatan .2 durasi. Kegiatan perkiraan durasi dijelaskan dalam Bagian 6.3.3.1.
.3 Persyaratan Sumber Daya. Kebutuhan sumber daya yang dijelaskan dalam Bagian 6.3.1.4.
.4 Sumber Daya deskripsi kolam renang. Pengetahuan tentang apa yang sumber daya akan tersedia pada apa kali dan dalam apa pola yang diperlukan untuk pengembangan jadwal. Misalnya, sumber daya bersama atau kritis bisa sangat sulit untuk jadwal karena ketersediaan mereka 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 pengembangan jadwal awal dari sebuah proyek konsultasi. Jadwal akhir untuk proyek yang sama, 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 berlibur atau dalam program pelatihan, sebuah kontrak kerja dapat membatasi pekerja tertentu untuk hari-hari tertentu dalam seminggu).
Kendala .6. Kendala adalah faktor yang akan membatasi pilihan manajemen proyek tim. Ada dua kategori utama dari kendala waktu dipertimbangkan selama pengembangan jadwal:
_ Tanggal ditetapkan Dikenakan tanggal mulai kegiatan atau selesai dapat digunakan untuk membatasi awal atau akhir untuk terjadi baik tidak lebih awal dari tanggal yang ditentukan atau paling lambat tanggal ditetapkan. Sementara keempat kendala tanggal biasanya tersedia dalam perangkat lunak manajemen proyek, yang “Mulai ada Sebelumnya Than” dan “Finish No Nanti Dari” kendala yang paling sering digunakan. Khas menggunakan kendala saat ini meliputi situasi seperti jendela pasar pada sebuah proyek teknologi, pembatasan cuaca di kegiatan di luar ruangan, kepatuhan pemerintah dimandatkan dengan rehabilitasi lingkungan, penyampaian materi dari pihak tidak diwakili dalam jadwal proyek, dll
_ Peristiwa kunci utama atau tonggak-penyelesaian kiriman tertentu oleh tanggal yang ditentukan dapat diminta oleh sponsor proyek, pelanggan proyek, atau pemangku kepentingan lainnya. Setelah dijadwalkan, tanggal-tanggal tersebut menjadi diharapkan dan sering dapat dipindahkan hanya dengan kesulitan besar. Milestones juga dapat digunakan untuk menunjukkan antarmuka dengan pekerjaan di luar proyek. Pekerjaan tersebut biasanya tidak dalam database proyek, dan tonggak dengan tanggal kendala dapat menyediakan antarmuka yang sesuai jadwal.
Asumsi .7. Lihat Bagian 4.1.1.5.
.8 Memimpin dan tertinggal. 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-mulai dengan memimpin sepuluh hari: kegiatan penggantinya dimulai sepuluh hari sebelum pendahulunya telah selesai.
.9 Risiko rencana pengelolaan. Rencana manajemen risiko dibahas dalam 11.1.3.
.10 Kegiatan atribut. Atribut dari kegiatan-termasuk tanggung jawab (yaitu, siapa yang akan melakukan pekerjaan), wilayah geografis atau bangunan (di mana pekerjaan harus dilakukan), dan jenis kegiatan (misalnya, ringkasan atau detail)-sangat penting untuk seleksi lebih lanjut dan pemilahan 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 Matematika analisis. Analisis matematis melibatkan perhitungan awal dan akhir teoritis dan tanggal selesai 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:
_ Metode Jalur Kritis (CPM)-menghitung awal, tunggal awal dan akhir deterministik dan tanggal selesai untuk setiap kegiatan berdasarkan tertentu, logika jaringan sekuensial dan perkiraan durasi tunggal. Fokus CPM menghitung mengambang untuk menentukan kegiatan memiliki fleksibilitas penjadwalan sedikit. Algoritma yang mendasari BPT sering digunakan dalam jenis lain dari analisis matematis.
_ Evaluasi Grafis dan Teknik Ulasan (Gert)-memungkinkan untuk pengobatan probabilistik dari kedua logika jaringan dan perkiraan durasi aktivitas (misalnya, beberapa kegiatan 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 perkiraan rata-rata durasi tertimbang untuk menghitung durasi aktivitas. Meskipun ada perbedaan permukaan, PERT berbeda dari CPM terutama karena menggunakan (nilai yang diharapkan) rata-rata distribusi bukannya perkiraan yang paling mungkin awalnya digunakan di BPT (lihat Gambar 6-4). PERT sendiri jarang digunakan saat ini.
.2 Durasi kompresi. 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 biaya sedikit tambahan. Menerjang tidak selalu menghasilkan alternatif dan sering mengakibatkan peningkatan biaya.
_ Cepat pelacakan-melakukan kegiatan secara paralel yang biasanya akan dilakukan secara berurutan (misalnya, mulai menulis kode pada sebuah proyek perangkat lunak sebelum desain selesai, atau mulai membangun fondasi untuk sebuah pabrik pengolahan minyak bumi sebelum 25 persen titik rekayasa tercapai). Cepat pelacakan sering mengakibatkan pengerjaan ulang dan biasanya meningkatkan risiko.
Simulasi .3. Simulasi melibatkan menghitung jangka waktu beberapa proyek dengan set yang berbeda dari 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.

 

Leveling Sumber Daya heuristik .4. Analisis matematis sering menghasilkan jadwal awal-awal start yang membutuhkan lebih banyak sumber daya selama periode waktu tertentu daripada yang tersedia, atau membutuhkan perubahan dalam tingkat sumber daya yang tidak dikelola. Heuristik, seperti, “Mengalokasikan sumber daya yang langka untuk kegiatan jalur kritis pertama,” dapat diterapkan untuk mengembangkan jadwal yang mencerminkan kendala tersebut. Meratakan sumber daya sering mengakibatkan 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 noncritical untuk kegiatan kritis adalah cara yang umum untuk membawa jadwal kembali, atau sedekat mungkin, untuk awalnya ditujukan durasi keseluruhan. Pemanfaatan jam diperpanjang, akhir pekan, atau pergeseran beberapa juga harus dipertimbangkan untuk mengurangi durasi kegiatan kritis. Produktivitas meningkat didasarkan pada penggunaan teknologi yang berbeda dan / atau mesin (misalnya, pengelasan otomatis, pemotong pipa listrik, dll) merupakan cara lain untuk mempersingkat jangka waktu yang telah memperpanjang jadwal awal. Pelacakan Bahkan, jika mungkin (seperti yang dijelaskan dalam Bagian 6.4.2.2), adalah cara lain untuk mengurangi durasi proyek secara keseluruhan. Beberapa proyek mungkin memiliki sumber daya yang terbatas dan proyek penting, yang mensyaratkan bahwa sumber daya ini akan dijadwalkan secara terbalik dari proyek berakhir tanggal, ini dikenal sebagai penjadwalan alokasi sumber daya terbalik. Rantai penting adalah teknik yang mengubah jadwal proyek untuk menjelaskan sumber daya yang terbatas.
.5 Proyek 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 Coding struktur. Kegiatan harus memiliki struktur coding yang akan memungkinkan pemilahan 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 dari Pengembangan Jadwal
.1 Proyek jadwal. Jadwal proyek mencakup setidaknya mulai direncanakan dan tanggal selesai diharapkan 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, hal ini lebih sering disajikan secara grafis, menggunakan satu atau lebih dari format berikut:
_ Diagram jaringan Proyek dengan informasi tanggal ditambahkan (lihat Gambar 6-5). Grafik ini biasanya menunjukkan baik logika proyek dan kegiatan 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), menunjukkan aktivitas mulai dan tanggal akhir, serta durasi yang diharapkan, dan kadang-kadang menampilkan dependensi. Mereka relatif mudah dibaca, dan sering digunakan dalam presentasi manajemen.
_ Milestone grafik (lihat Gambar 6-7) mirip dengan bar chart, tetapi hanya mengidentifikasi awal terjadwal atau penyelesaian penyerahan utama dan interface eksternal kunci.
.2 Mendukung detail. Mendukung detail untuk jadwal proyek mencakup setidaknya dokumentasi dari semua asumsi diidentifikasi dan kendala. Jumlah detail tambahan bervariasi berdasarkan wilayah aplikasi. Sebagai contoh:
_ Pada proyek konstruksi, maka kemungkinan besar akan termasuk barang-barang seperti histogram sumber daya, arus kas proyeksi, dan ketertiban dan jadwal pengiriman.
_ Pada proyek elektronik, maka kemungkinan besar akan termasuk histogram sumber daya saja. Informasi yang sering diberikan sebagai pendukung rinci termasuk, namun tidak terbatas pada:
_ Sumber Daya persyaratan oleh periode waktu, seringkali dalam bentuk histogram sumber daya.
_ 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).
Update Sumber Daya .4 persyaratan. Sumber daya update meratakan mungkin memiliki pengaruh yang signifikan terhadap perkiraan awal kebutuhan sumber daya.

 

6,5 JADWAL KONTROL
Jadwal kontrol berkaitan dengan a) mempengaruhi faktor-faktor yang menciptakan perubahan jadwal untuk memastikan bahwa perubahan yang disepakati, b) menentukan bahwa jadwal telah berubah, dan c) mengelola perubahan yang sebenarnya kapan dan ketika mereka terjadi. Jadwal kontrol harus benar-benar terintegrasi dengan proses kontrol lainnya, seperti yang dijelaskan dalam Bagian 4.3, Integrated Change Control.

 

6.5.1 Masukan untuk Jadwal Kontrol
.1 Proyek jadwal. Jadwal proyek dijelaskan dalam Bagian 6.4.3.1. Jadwal proyek yang disetujui, 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 Perubahan 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 Jadwal rencana pengelolaan. Rencana pengelolaan jadwal dijelaskan dalam Bagian 6.4.3.3.

6.5.2 Alat dan Teknik Pengendalian Jadwal
.1 Jadwal perubahan sistem kontrol. 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. Teknik pengukuran kinerja seperti yang dijelaskan dalam Bagian 10.3.2 membantu untuk menilai besarnya setiap variasi yang memang terjadi. Suatu bagian penting dari pengendalian jadwal adalah untuk memutuskan apakah variasi jadwal memerlukan tindakan korektif. Misalnya, penundaan besar pada aktivitas nonkritis mungkin memiliki sedikit efek pada proyek secara keseluruhan, sementara penundaan lebih pendek pada kegiatan kritis atau dekat-kritis mungkin memerlukan tindakan segera.
.3 Tambahan perencanaan. Beberapa proyek berjalan tepat sesuai rencana. Calon perubahan mungkin memerlukan estimasi durasi aktivitas baru atau direvisi, urutan kegiatan yang dimodifikasi, 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 jadwal-monitoring merupakan elemen kunci untuk mengontrol waktu. Membandingkan tanggal target dengan tanggal awal sebenarnya / perkiraan dan finish menyediakan informasi yang berguna untuk mendeteksi penyimpangan dan untuk implementasi solusi korektif dalam kasus penundaan. Varians mengapung juga merupakan komponen penting untuk mengevaluasi perencanaan waktu proyek-kinerja. Perhatian khusus harus diberikan untuk kegiatan kritis dan subkritis (yaitu, menganalisis sepuluh jalur subkritis, dalam urutan menaik mengambang).

6.5.3 Keluaran dari Control Jadwal
.1 Jadwal update. Pembaruan jadwal modifikasi untuk informasi jadwal 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 perubahan pada jadwal awal dan menyelesaikan tanggal dalam jadwal proyek disetujui. Perubahan ini umumnya tergabung dalam menanggapi perubahan lingkup atau perubahan perkiraan. Dalam beberapa kasus, penundaan jadwal mungkin begitu parah sehingga rebaselining diperlukan 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 baru harus menjadi modus normal revisi jadwal.
.2 Tindakan korektif. Tindakan korektif adalah segala sesuatu dilakukan untuk membawa kinerja jadwal diharapkan masa depan sejalan dengan rencana proyek. Tindakan korektif di bidang manajemen waktu sering melibatkan mempercepat: tindakan-tindakan khusus diambil untuk memastikan penyelesaian kegiatan tepat waktu atau dengan penundaan sesedikit mungkin. Tindakan korektif 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 Pelajaran. Penyebab varians, alasan di balik tindakan korektif yang dipilih, dan jenis-jenis pelajaran dari pengendalian jadwal harus didokumentasikan, sehingga mereka menjadi bagian dari database historis untuk kedua proyek ini dan proyek-proyek lain dari organisasi yang melakukan.

Project Time Management

Chapter 6

Project Time Management

 

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.3 Activity 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 welldefined 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 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 activityon- 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 pharmaceutical 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 singlepoint 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-mandated 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 noncritical 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 interfaces.

.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.

SOAL MANAJEMEN PROYEK

Soal Proses manajemen Proyek

1. Apa yang dimaksud dengan manajemen proyek?
2. Apa yang anda ketahui tentang proses?
3. Mengapa dalam suatu manajemen harus ada manajemen proyek?
4. Sebutkan lima tahap kegiatan utama yang dilakukan dalam siklus hidup proyek!
5. Mengapa sebelum membuat proyek harus ada proses perencanaan terlebih dahulu?
6. Jelaskan yang anda ketahui tentang pelaksana kelompok proses!
7. Apa yang anda ketahui tentang Monitoring dan Pengendalian Proses Kelompok?
8. Apa tujuan utama dari perencanaan proyek ?
9. Jelaskan mengapa dalam menyelesaikan sebuah proyek harus adaPenutup Proses Kelompok?
10. Apa hubungan antara Grup proses dan area Knowledge?
11. Apa yang dimaksud dengan Inisiasi proyek ?
12. Siapa yang bertanggung jawab dalam mengurus sebuah proyek?
13. Apa yang harus dimiliki oleh seorang manajer proyek pada setiap proses manajemen proyek?
14. Kemampuan apa yang harus dimiliki oleh manajer proyek?
15. Apa yang dimaksud dengan Technical Skills?
16. Apa yang anda ketahui tentan Communication Skills dalam manajemen proyek?
17. Apa yang dimaksud dengan Manajemen Waktu Proyek?
18. Apa yang anda ketahui tentang ruang lingkup?
19. Apa tantangan utama dalam mengerjakan sebuah proyek?
20. Apa output yang dihasilkan dalam suatu perencanaan proyek?