MENGELOLA PROYEK SISTEM

Bab 3 menjelaskan manajemen proyek untuk proyek TI.

Anda akan belajar tentang perencanaan proyek, penjadwalan, pemantauan, pelaporan, dan
penggunaan perangkat lunak manajemen proyek. Anda akan belajar cara membuat struktur rincian
kerja, mengidentifikasi pola tugas, dan menghitung jalur kritis. Anda juga akan belajar bagaimana
menggunakan bagan Gantt dan teknik PERT / CPM untuk menjadwalkan dan memantau proyek.
Terakhir, Anda akan mempelajari cara mengontrol dan mengelola perubahan proyek saat terjadi.
Selain materi manajemen proyek dalam bab ini, Anda dapat mengunjungi bagian Fitur pada CD-ROM
Alat Belajar Siswa, di mana Anda dapat mempelajari lebih lanjut tentang Microsoft Project dan Open
Workbench, program manajemen proyek sumber terbuka yang dapat Anda unduh dan Install. Anda
juga dapat mengunjungi situs Web MIS CourseMate untuk buku ini di www.cengagebrain.com dan
menjelajahi tautan di perpustakaan sumber daya manajemen proyek SWL. Bab 3 mencakup tiga Sesi
Pembelajaran Video yang menunjukkan kepada Anda cara membuat struktur rincian kerja (WBS),
cara mengidentifikasi pola tugas, dan cara menghitung jalur kritis proyek.
IKHTISAR MANAJEMEN PROYEK
Apakah Anda sedang mengembangkan sistem informasi atau mengerjakan proyek konstruksi seperti
yang ada di Gambar 3-2, prosesnya sama. Satu-satunya perbedaan adalah sifat proyek. Manajemen
proyek untuk para profesional TI meliputi perencanaan, penjadwalan, pemantauan dan pengendalian,
dan pelaporan pengembangan sistem informasi.
Apa yang Membentuk Proyek?
Proyek yang sukses harus diselesaikan tepat waktu, sesuai anggaran, dan memberikan produk
berkualitas yang memuaskan pengguna dan memenuhi persyaratan. Teknik manajemen proyek dapat
digunakan di seluruh SDLC. Pengembang sistem dapat memulai proyek formal sedini tahap
penyelidikan awal, atau nanti, saat aktivitas analisis, desain, dan implementasi terjadi.
Seperti yang ditunjukkan oleh tanda pada Gambar 3-3, terkadang Anda harus memutuskan apa yang
paling penting. Konsep yang sama berlaku untuk pengembangan sistem, di mana faktor-faktor
tersebut meliputi batasan anggaran, batasan waktu, dan standar kualitas. Selama semuanya seimbang,
seperti jungkat-jungkit pada Gambar 3-4, proyek akan berhasil. Namun, jika salah satu faktor
berubah, penyesuaian harus dilakukan. Karena faktor berinteraksi secara konstan, manajer proyek
harus merespon dengan cepat. Misalnya, jika proyek yang sangat membutuhkan waktu mulai
tergelincir, manajer proyek mungkin harus memangkas beberapa fitur, meminta persetujuan untuk
peningkatan anggaran, menyederhanakan rencana pengujian, atau kombinasi dari ketiga tindakan
tersebut. Sayangnya, banyak proyek sistem yang gagal. Sebuah laporan oleh The Standish Group
mencatat bahwa hanya sepertiga dari semua proyek pengembangan perangkat lunak yang berhasil,
dalam arti memenuhi anggaran, jadwal, dan target kualitas. Ketua Standish Jim Johnson mengatakan
bahwa perbaikan akan membutuhkan alat manajemen proyek yang lebih baik, metode yang lebih
berulang, dan komunikasi yang lebih baik antara pengembang proyek dan pengguna.
Apa yang Dilakukan Manajer Proyek?
Apakah sebuah proyek melibatkan gedung kantor baru atau sistem informasi, kepemimpinan yang
baik sangat penting. Dalam proyek sistem, manajer proyek, atau pemimpin proyek, biasanya adalah
analis sistem senior atau manajer departemen TI jika proyeknya besar. Seorang analis atau
programmer / analis mungkin mengelola proyek yang lebih kecil. Selain manajer proyek, sebagian
besar proyek besar memiliki koordinator proyek. Koordinator proyek menangani tanggung jawab
administratif untuk tim dan bernegosiasi dengan pengguna yang mungkin memiliki persyaratan yang
bertentangan atau menginginkan perubahan yang memerlukan waktu atau biaya tambahan. Manajer
proyek biasanya melakukan empat aktivitas, atau fungsi: perencanaan, penjadwalan, pemantauan, dan
pelaporan.

• Perencanaan proyek termasuk mengidentifikasi semua tugas proyek dan memperkirakan waktu
penyelesaian dan biaya masing-masing.
• Penjadwalan proyek melibatkan pembuatan jadwal tertentu, biasanya dalam bentuk bagan yang
menunjukkan tugas, ketergantungan tugas, dan tugas penting yang mungkin menunda proyek.
Penjadwalan juga melibatkan pemilihan dan penempatan staf tim proyek dan menetapkan tugas-
tugas khusus untuk anggota tim. Penjadwalan proyek menggunakan diagram Gantt dan diagram
PERT / CPM, yang dijelaskan di bagian berikut.
• Pemantauan proyek membutuhkan bimbingan, pengawasan, dan koordinasi beban kerja tim
proyek. Manajer proyek harus memantau kemajuan, mengevaluasi hasil, dan mengambil tindakan
korektif bila perlu untuk mengendalikan proyek dan tetap pada target.
• Pelaporan proyek mencakup laporan kemajuan rutin kepada manajemen, pengguna, dan tim
proyek itu sendiri. Pelaporan yang efektif membutuhkan keterampilan komunikasi yang kuat dan
pemahaman tentang apa yang diinginkan dan perlu diketahui orang lain tentang proyek tersebut.
Kegiatan Proyek dan Langkah Perencanaan
Pada hari tertentu, manajer proyek mungkin melakukan satu atau lebih aktivitas yang tercantum di
atas. Namun, seperti yang ditunjukkan Gambar 3-5, setiap aktivitas merupakan bagian dari kerangka
kerja yang lebih besar, yang mencakup tiga langkah utama dalam perencanaan proyek:

• Buat struktur rincian kerja.

• Identifikasi pola tugas.
• Hitung jalur kritis.

Matriks pada Gambar 3-5 di halaman berikutnya menunjukkan aktivitas khas yang dilakukan oleh
pemimpin proyek saat proyek berkembang. Ketika proyek mulai beroperasi, dia juga mengatur orang-
orang, jadwal, anggaran, dan kemajuan. Bagian berikut menjelaskan tiga langkah pengembangan
proyek. Anda dapat melihat Sesi Pembelajaran Video sebelum, selama, atau setelah Anda
mempelajari setiap langkah.
LANGKAH 1: BUAT STRUKTUR RINCIAN KERJA
Struktur rincian kerja (WBS) melibatkan pemecahan proyek menjadi serangkaian tugas yang lebih
kecil. Sebelum membuat struktur rincian kerja, Anda harus memahami dua jenis bagan utama: bagan
Gantt dan bagan PERT / CPM.
Apa Itu Gantt Chart?
Bagan Gantt dikembangkan hampir 100 tahun yang lalu oleh Henry L. Gantt, seorang insinyur mesin
dan konsultan manajemen. Tujuannya adalah untuk merancang bagan yang dapat menunjukkan
kemajuan yang direncanakan dan sebenarnya dalam sebuah proyek. Bagan Gantt adalah bagan batang
horizontal yang mewakili sekumpulan tugas. Misalnya, bagan Gantt pada Peraga 3-6 menampilkan
lima tugas dalam larik vertikal, dengan waktu yang ditunjukkan pada sumbu horizontal. Posisi bilah
menunjukkan waktu mulai dan berakhir yang direncanakan dari setiap tugas, dan panjang bilah
menunjukkan durasinya. Pada sumbu horizontal, waktu dapat ditampilkan sebagai waktu yang telah
berlalu dari titik awal tetap, atau sebagai tanggal kalender sebenarnya. Bagan Gantt juga dapat
menyederhanakan proyek yang kompleks dengan menggabungkan beberapa aktivitas ke dalam
kelompok tugas. Misalnya, pada Peraga 3-6, Tugas 4 mungkin terdiri dari lima tugas terpisah, yang
disembunyikan dalam tampilan ini.
Bagan Gantt dapat memperlihatkan status tugas dengan menambahkan warna kontras ke bilah
horizontal. Misalnya, panah vertikal menandai tanggal hari ini pada Gambar 3-6. Dengan titik
referensi tetap, mudah untuk melihat bahwa Tugas 1 jauh di belakang jadwal, Tugas 2 hanya sekitar
80 persen selesai dan berjalan di belakang jadwal, Tugas 3 seharusnya sudah dimulai, tetapi tidak ada
pekerjaan yang dilakukan, Tugas 4 sebenarnya adalah berjalan lebih cepat dari jadwal, dan Tugas 5
akan dimulai dalam beberapa minggu. Bagan Gantt dapat menyajikan gambaran umum tentang status
proyek, tetapi tidak memberikan informasi yang cukup mendetail, yang diperlukan saat mengelola
proyek yang kompleks. Sebagian besar manajer proyek menemukan bahwa grafik PERT / CPM, yang
dibahas di bagian berikut, adalah alat yang lebih baik untuk mengelola proyek besar.
Apa Itu Diagram PERT / CPM?
Teknik Tinjauan Evaluasi Program (Program Evaluation Review Technique / PERT) dikembangkan
oleh Angkatan Laut AS untuk mengelola proyek yang sangat kompleks, seperti pembangunan kapal
selam nuklir. Pada waktu yang kurang lebih bersamaan, Critical Path Method (CPM) dikembangkan
oleh industri swasta untuk memenuhi kebutuhan manajemen proyek yang serupa. Perbedaan antara
kedua metode tersebut telah menghilang seiring waktu, dan saat ini teknik tersebut disebut PERT,
CPM, atau PERT / CPM. Buku teks akan menggunakan istilah bagan PERT. PERT adalah teknik
bottom-up, karena ia menganalisis proyek yang besar dan kompleks sebagai rangkaian tugas individu.
Untuk membuat bagan PERT, Anda terlebih dahulu mengidentifikasi semua tugas proyek dan
memperkirakan berapa banyak waktu yang dibutuhkan setiap tugas untuk dilakukan. Selanjutnya,
Anda harus menentukan urutan logis di mana tugas harus dilakukan. Misalnya, beberapa tugas tidak
dapat dimulai hingga tugas lain telah diselesaikan. Dalam situasi lain, beberapa tugas dapat dilakukan
pada waktu yang bersamaan. Setelah Anda mengetahui tugas, durasinya, dan urutan pelaksanaannya,
Anda dapat menghitung waktu yang dibutuhkan untuk menyelesaikan proyek. Anda juga dapat
mengidentifikasi tugas-tugas khusus yang akan sangat penting untuk penyelesaian proyek tepat
waktu. Contoh bagan PERT, yang disebut Microsoft sebagai diagram jaringan, ditunjukkan di layar
bawah pada Gambar 3-7.
Jenis Bagan Mana yang Lebih Baik?
Meskipun diagram Gantt menawarkan tampilan snapshot proyek yang berharga, diagram PERT lebih
berguna untuk penjadwalan, pemantauan, dan pengendalian pekerjaan yang sebenarnya. Dengan
bagan PERT, manajer proyek dapat mengonversi waktu mulai dan selesai tugas ke tanggal aktual
dengan meletakkan seluruh proyek di kalender. Kemudian, pada hari tertentu, manajer dapat
membandingkan apa yang seharusnya terjadi dengan apa yang sedang terjadi, dan bereaksi sesuai itu.
Juga, bagan PERT menampilkan pola dan hubungan tugas yang kompleks. Informasi ini berharga
bagi manajer yang mencoba menangani masalah prioritas tinggi. Bagan PERT dan Gantt bukanlah
teknik yang saling eksklusif, dan manajer proyek sering menggunakan kedua metode tersebut.
Gambar 3-7 menunjukkan kedua jenis bagan tersebut. Layar atas adalah bagan Gantt dengan 11 tugas.
Bagan PERT di layar bawah menunjukkan proyek yang sama, menggunakan kotak terpisah untuk
setiap tugas, bukan bilah horizontal. Meskipun keduanya menunjukkan pola dan alur tugas, kotak
bagan PERT dapat memberikan informasi yang lebih detail, seperti durasi tugas, tanggal mulai, dan
tanggal selesai. Anda akan belajar cara membuat bagan PERT di bagian berikut.
Mengidentifikasi Tugas dalam Struktur Perincian Kerja.
Struktur rincian kerja harus mengidentifikasi setiap tugas dengan jelas dan mencakup perkiraan
durasi. Tugas, atau aktivitas, adalah pekerjaan apa pun yang memiliki awal dan akhir dan
membutuhkan penggunaan sumber daya perusahaan seperti orang, waktu, atau uang. Contoh tugas
antara lain melakukan wawancara, merancang laporan, memilih perangkat lunak, menunggu
pengiriman peralatan, atau melatih pengguna. Tugas adalah unit kerja dasar yang direncanakan,
dijadwalkan, dan dipantau oleh manajer proyek - jadi tugas tersebut harus relatif kecil dan dapat
dikelola. Selain tugas, setiap proyek memiliki peristiwa, atau pencapaian. Peristiwa, atau pencapaian,
adalah titik referensi yang dapat dikenali yang dapat Anda gunakan untuk memantau kemajuan.
Misalnya, sebuah peristiwa mungkin menjadi awal pelatihan pengguna, konversi data sistem, atau
penyelesaian wawancara. Tonggak penting seperti Selesaikan 50 persen pengujian program tidak akan
menjadi informasi yang berguna kecuali Anda dapat menentukan dengan tepat kapan peristiwa itu
akan terjadi. Gambar 3-8 menunjukkan tugas dan peristiwa yang mungkin terlibat dalam pembuatan,
distribusi, dan tabulasi kuesioner. Perhatikan bahwa awal dan akhir setiap tugas ditandai dengan
peristiwa yang dapat dikenali. Jika Anda mencoba mengelola proyek sebagai satu tugas besar, itu
tidak mungkin. Sebagai gantinya, Anda memecah proyek menjadi tugas-tugas yang lebih kecil,
membuat struktur rincian kerja (WBS). Langkah pertama dalam membuat WBS adalah membuat
daftar semua tugas.
MENCATATKAN TUGAS.
Meskipun langkah ini kedengarannya sederhana, ini bisa jadi menantang, karena tugas mungkin
disematkan dalam dokumen, seperti yang ditunjukkan pada versi pertama Peraga 3-9. Salah satu
triknya adalah memulai dengan menyorot tugas individu, seperti yang ditunjukkan pada versi kedua.
Menambahkan peluru membuat tugas lebih menonjol, seperti yang ditunjukkan pada versi ketiga.
Langkah selanjutnya adalah memberi nomor tugas dan membuat tabel, mirip dengan yang
ditunjukkan pada Peraga 3-10, dengan kolom untuk nomor tugas, deskripsi, durasi, dan tugas
pendahulu.
PERKIRAAN DURASI TUGAS Durasi tugas bisa berjam-jam, berhari-hari, atau berminggu-minggu
- tergantung pada proyeknya. Karena contoh berikut menggunakan hari, satuan ukurnya disebut
orang-hari. Satu hari-orang mewakili pekerjaan yang bisa diselesaikan satu orang dalam satu hari.
Pendekatan ini, bagaimanapun, dapat menimbulkan beberapa masalah. Misalnya, jika diperlukan satu
orang 20 hari untuk melakukan tugas tertentu, mungkin tidak benar bahwa dua orang dapat
menyelesaikan tugas yang sama dalam 10 hari atau 10 orang dapat melakukan tugas dalam dua hari.
Beberapa tugas dapat dibagi secara merata sehingga memungkinkan untuk menggunakan kombinasi
waktu dan orang yang berbeda, hingga titik tertentu. Misalnya, jika perlu dua persondays untuk
memasang kabel untuk jaringan area lokal baru, satu orang dapat melakukan tugas tersebut dalam dua
hari, dua orang dalam satu hari, atau empat orang dalam setengah hari. Namun, dalam sebagian besar
tugas analisis sistem, waktu dan orang tidak dapat dipertukarkan. Jika satu analis membutuhkan dua
jam untuk mewawancarai seorang pengguna, dua analis juga akan membutuhkan dua jam untuk
melakukan wawancara yang sama. Manajer proyek sering menggunakan rumus berbobot untuk
memperkirakan durasi setiap tugas. Manajer proyek pertama-tama membuat tiga perkiraan waktu
untuk setiap tugas: optimis, atau perkiraan kasus terbaik (B), perkiraan kemungkinan kasus (P), dan
pesimis, atau perkiraan kasus terburuk (W). Manajer kemudian memberikan bobot, yang merupakan
nilai penting, untuk setiap perkiraan. Bobotnya dapat bervariasi, tetapi pendekatan yang umum adalah
menggunakan rasio B = 1, P = 4, dan W = 1. Durasi tugas yang diharapkan dihitung sebagai berikut:
Misalnya, manajer proyek mungkin memperkirakan bahwa tugas konversi file dapat diselesaikan
dalam waktu 20 hari atau dapat memakan waktu hingga 34 hari, tetapi kemungkinan besar akan
membutuhkan 24 hari. Dengan menggunakan rumus, durasi tugas yang diharapkan adalah 25 hari,
dihitung sebagai berikut:
Faktor yang Mempengaruhi Durasi
Saat mengembangkan perkiraan durasi, manajer proyek mempertimbangkan empat faktor:

• Ukuran proyek
• Sumber daya manusia
• Pengalaman dengan proyek serupa
 • Kendala

UKURAN PROYEK
Anda telah mempelajari di Bab 1 bahwa sistem informasi memiliki berbagai karakteristik yang
mempengaruhi kompleksitas dan biayanya. Selain mempertimbangkan faktor-faktor tersebut, manajer
proyek harus memperkirakan waktu yang dibutuhkan untuk menyelesaikan setiap fase proyek. Untuk
mengembangkan perkiraan yang akurat, manajer proyek harus mengidentifikasi semua tugas proyek,
mulai dari pencarian fakta awal hingga implementasi sistem. Terlepas dari metodologi pengembangan
sistem yang digunakan, manajer proyek harus menentukan berapa banyak waktu yang dibutuhkan
untuk melakukan setiap tugas. Dalam mengembangkan perkiraan, manajer proyek harus menyediakan
waktu untuk rapat, tinjauan proyek, pelatihan, dan faktor lain yang dapat mempengaruhi produktivitas
tim pengembangan.
SUMBER DAYA MANUSIA.
Perusahaan harus berinvestasi besar dalam teknologi mutakhir dan
Sistem berbasis web untuk tetap kompetitif di dunia yang terhubung. Di banyak area, profesional TI
yang terampil sangat dibutuhkan, dan perusahaan harus bekerja keras untuk menarik dan
mempertahankan bakat yang mereka butuhkan. Seorang manajer proyek harus mengumpulkan dan
membimbing tim pengembangan yang memiliki keterampilan dan pengalaman untuk menangani
proyek tersebut. Jika perlu, analis sistem atau pemrogram tambahan harus dipekerjakan atau dilatih,
dan ini harus diselesaikan dalam kerangka waktu tertentu. Setelah proyek berjalan, manajer proyek
harus berurusan dengan omset, lowongan kerja, dan kenaikan gaji di sektor teknologi - yang
semuanya dapat mempengaruhi apakah proyek dapat diselesaikan tepat waktu dan sesuai anggaran.
PENGALAMAN DENGAN PROYEK YANG SAMA.
Seorang manajer proyek dapat mengembangkan perkiraan waktu dan biaya berdasarkan sumber daya
yang digunakan untuk sistem informasi serupa yang dikembangkan sebelumnya. Metode pengalaman
bekerja paling baik untuk proyek berukuran kecil atau menengah di mana kedua sistem memiliki
ukuran, konten dasar, dan lingkungan operasi yang serupa. Dalam sistem besar dengan lebih banyak
variabel, estimasi kurang dapat diandalkan. Selain itu, Anda mungkin tidak dapat menggunakan
pengalaman dari proyek yang dikembangkan di lingkungan yang berbeda. Misalnya, saat Anda
menggunakan aplikasi database berbasis web baru, Anda mungkin tidak memiliki pengalaman
sebelumnya untuk mengukur di lingkungan ini. Dalam situasi ini, Anda dapat merancang prototipe
atau sistem percontohan untuk mendapatkan pengalaman memperkirakan teknis dan biaya.
KENDALA.
Anda telah mempelajari di Bab 2 bahwa batasan ditentukan selama investigasi awal. Batasan adalah
kondisi, batasan, atau persyaratan yang harus dipenuhi oleh sistem. Misalnya, batasan mungkin
melibatkan maksimum untuk satu atau lebih sumber daya, seperti waktu, dolar, atau orang. Seorang
manajer proyek harus menentukan persyaratan sistem yang dapat dicapai secara realistis dalam
batasan yang diperlukan. Jika tidak ada batasan, manajer proyek hanya menghitung sumber daya yang
dibutuhkan. Namun, jika ada kendala, manajer proyek harus menyesuaikan sumber daya lain atau
mengubah lingkup proyek. Pendekatan ini mirip dengan analisis bagaimana-jika yang dijelaskan di
Bab 12.
Menampilkan Struktur Perincian Kerja.
Setelah Anda memasukkan durasi tugas, struktur rincian pekerjaan akan terlihat seperti Gambar 3-11.
Jika Anda mengelola proyek yang kompleks dengan banyak tugas, Anda dapat menggunakan grup
tugas, seperti yang Anda lakukan di bagan Gantt, untuk menyederhanakan daftar. Jika Anda
menggunakan Microsoft Project, WBS mungkin terlihat seperti Gambar 3-12.
LANGKAH 2: IDENTIFIKASI POLA TUGAS
Tugas dalam struktur rincian kerja harus diatur dalam urutan logis yang disebut pola tugas. Bagian ini
akan menunjukkan kepada Anda bagaimana memahami dan membuat model grafis dari pola-pola ini.
Apa Itu Pola Tugas?
Dalam proyek apa pun, besar atau kecil, tugas bergantung satu sama lain dan harus dilakukan secara
berurutan, tidak seperti perintah dalam program perangkat lunak. Pola tugas dapat melibatkan tugas
dependen, beberapa tugas penerus, dan beberapa tugas sebelumnya. Dalam proyek yang lebih besar,
pola-pola ini bisa sangat kompleks, dan seorang analis harus mempelajari alur logisnya dengan
cermat.
Bagaimana Saya Menggunakan Kotak Tugas untuk Membuat Model?
Dalam bagan PERT / CPM, tugas proyek ditampilkan sebagai kotak persegi panjang, diatur dalam
urutan yang harus dilakukan. Setiap kotak persegi panjang, disebut kotak tugas, memiliki lima bagian,
seperti yang ditunjukkan pada Peraga 3-13. Setiap bagian dari kotak tugas berisi informasi penting
tentang tugas, termasuk Nama Tugas, ID Tugas, Durasi Tugas, Hari / Tanggal Mulai, dan Hari /
Tanggal Selesai.
NAMA TUGAS
Nama tugas harus singkat dan deskriptif, tetapi tidak harus unik dalam proyek. Misalnya, tugas
bernama Melakukan Wawancara mungkin terjadi di beberapa fase proyek.
ID TUGAS ID Tugas dapat berupa angka atau kode yang memberikan identifikasi unik.
DURASI TUGAS
Durasi adalah jumlah waktu yang dibutuhkan untuk menyelesaikan tugas. Semua tugas harus
menggunakan unit waktu yang sama, yang bisa berupa jam, hari, minggu, atau bulan, tergantung pada
proyeknya. Proyek aktual dimulai pada tanggal tertentu, tetapi juga dapat diukur dari titik waktu
tertentu, seperti Hari 1.

MULAI HARI / TANGGAL

Hari / tanggal mulai adalah waktu dimulainya tugas.
Misalnya, proyek sederhana memiliki dua tugas: Tugas 1 dan Tugas 2. Juga anggap Tugas 2 tidak
dapat dimulai hingga Tugas 1 selesai. Sebuah analogi mungkin bahwa Anda tidak dapat menjalankan
program sampai Anda menyalakan komputer Anda. Jika Tugas 1 dimulai pada Hari 1 dan memiliki
durasi tiga hari, itu akan selesai pada Hari 3. Karena Tugas 2 tidak dapat dimulai hingga Tugas 1
selesai, waktu mulai untuk Tugas 2 adalah Hari 4, yang merupakan hari setelah Tugas 1 selesai.
SELESAI HARI / TANGGAL
Hari / tanggal selesai adalah waktu tugas dijadwalkan untuk diselesaikan. Untuk menghitung hari atau
tanggal selesai, Anda menambahkan durasi ke hari atau tanggal mulai. Saat Anda melakukan ini,
Anda harus sangat berhati-hati untuk tidak menambahkan terlalu banyak hari. Misalnya, jika tugas
dimulai pada Hari 10 dan memiliki durasi 5 hari, maka penyelesaiannya adalah pada Hari 14 - bukan
Hari 15.
 Apa Jenis Utama Pola Tugas?
Sebuah proyek didasarkan pada pola tugas. Dalam proyek besar, pola keseluruhan akan cukup
kompleks, tetapi dapat dipecah menjadi tiga pola dasar: tugas dependen, beberapa tugas penerus, dan
beberapa tugas pendahulu.
TUGAS TERGANTUNG
Ketika tugas harus diselesaikan satu demi satu, seperti perlombaan estafet yang ditunjukkan pada
Peraga 3-14, itu disebut tugas bergantung, karena satu bergantung pada yang lain. Misalnya, Gambar
3-15 menunjukkan bahwa Tugas 2 bergantung pada Tugas 1, karena Tugas 2 tidak dapat dimulai
hingga Tugas 1 selesai. Dalam contoh ini, waktu selesai Tugas 1, Hari 5, mengontrol tanggal mulai
Tugas 2, yaitu Hari 6.
TUGAS GANDA SUCCESSOR
Jika beberapa tugas dapat dimulai pada waktu yang sama, setiap tugas disebut tugas bersamaan.
Seringkali, dua atau lebih tugas bersamaan bergantung pada satu tugas sebelumnya, yang disebut
tugas pendahulu. Dalam situasi ini, setiap tugas bersamaan disebut tugas penerus. Dalam contoh yang
ditunjukkan pada Peraga 3-16, Pengganti Tugas 2 dan 3 keduanya dapat dimulai segera setelah Tugas
1 selesai. Perhatikan bahwa waktu selesai untuk Tugas 1
menentukan waktu mulai untuk Tugas 2 dan 3. Dengan kata lain, paling awal yang bisa diselesaikan
Tugas 1 adalah hari ke-30, jadi hari ke-31 adalah hari paling awal yang dapat dimulai Tugas 2 dan 3.
TUGAS PREDECESSOR GANDA
Misalkan tugas membutuhkan dua atau lebih tugas sebelumnya untuk diselesaikan sebelum dapat
dimulai. Gambar 3-17 di halaman berikutnya menunjukkan contoh itu, karena Tugas 3 tidak dapat
dimulai hingga Tugas 1 dan 2 selesai. Karena dua tugas mungkin tidak selesai pada saat yang sama,
tugas sebelumnya terlama (terbaru) menjadi faktor pengontrol. Perhatikan bahwa awal untuk Tugas 3
adalah Hari 16, bukan Hari 6. Mengapa demikian? Karena Tugas 3 bergantung pada dua tugas
pendahulu, Tugas 1 dan 2, Tugas 3 tidak dapat dimulai hingga tugas tersebut selesai. Oleh karena itu,
waktu mulai untuk tugas penerus harus merupakan waktu selesai terbaru (terbesar) untuk tugas
sebelumnya. Dalam contoh yang ditampilkan, Tugas 1 berakhir pada Hari 15, sedangkan Tugas 2
berakhir pada Hari 5, jadi Tugas 1 mengontrol waktu mulai untuk Tugas 3.

Bagaimana Saya Mengidentifikasi Pola Tugas?

Anda dapat mengidentifikasi pola tugas dengan melihat kata-kata pada pernyataan tugas dengan
cermat. Kata-kata seperti kemudian, kapan, atau dan merupakan kata-kata tindakan yang menandakan
rangkaian peristiwa. Berikut tiga contoh sederhana:

• Lakukan Tugas 1, lalu lakukan Tugas 2 menjelaskan tugas dependen yang harus diselesaikan satu
demi satu.
• Saat Tugas 2 selesai, mulai dua tugas: Tugas 3 dan Tugas 4 menjelaskan beberapa tugas penerus yang
keduanya dapat dimulai segera setelah Tugas 2 selesai.
• Saat Tugas 5 dan 6 selesai, mulai Tugas 7 menunjukkan bahwa Tugas 7 adalah beberapa tugas
pendahulu karena tidak dapat dimulai hingga dua atau lebih tugas sebelumnya semuanya selesai.
Bagaimana Saya Bekerja Dengan Pola Tugas Kompleks?
Ketika beberapa pola tugas digabungkan, Anda harus mempelajari fakta dengan sangat hati-hati untuk
memahami logika dan urutannya. Jadwal proyek tidak akan akurat jika pola tugas yang mendasarinya
salah. Misalnya, pertimbangkan tiga pernyataan fakta berikut dan pola tugas yang mereka wakili.
Contoh pola tugas ditunjukkan Gambar 3-18, 3-19, dan 3-20.
TUGAS TERGANTUNG
Lakukan Tugas 1. Saat Tugas 1 selesai, lakukan Tugas 2.
TUGAS TERGANTUNG DAN TUGAS GANDA PENGHASIL
Melakukan Tugas 1. Saat Tugas 1 selesai, lakukan Tugas 2. Saat Tugas 2 selesai, mulai dua tugas:
Tugas 3 dan Tugas 4. Saat Tugas 3 selesai, mulai dua tugas lagi: Tugas 5 dan Tugas 6.
TUGAS TERGANTUNG, GANDA TUGAS SUCCESSOR, DAN GANDA TUGAS
PREDECESSOR
Lakukan Tugas 1. Saat Tugas 1 selesai, lakukan Tugas 2. Saat Tugas 2 selesai, mulai dua Tugas:
Tugas 3 dan Tugas 4. Saat Tugas 3 selesai, mulai dua tugas lagi: Tugas 5 dan Tugas 6. Saat Tugas 5
dan 6 selesai, mulai Tugas 7. Kemudian, saat Tugas 4 dan 7 selesai, lakukan Tugas 8.
LANGKAH 3: HITUNG JALAN KRITIS
Pola tugas menentukan urutan pelaksanaan tugas. Setelah urutan tugas ditentukan, manajer proyek
dapat menjadwalkan tugas dan menghitung jalur kritis.
Apa Itu Jalur Kritis?
Jalur kritis adalah serangkaian tugas yang, jika ditunda, akan mempengaruhi tanggal penyelesaian
proyek secara keseluruhan. Jika ada tugas di jalur kritis yang terlambat dari jadwal, seluruh proyek
akan ditunda. Misalnya, Anda mengundang Joan dan Jim ke rumah Anda untuk makan malam. Joan
datang tepat waktu, tapi Jim datang terlambat 30 menit. Kedatangan Jim adalah bagian dari jalur
kritis, karena Anda tidak ingin memulai tanpa dia, jadi makanan akan disajikan lebih lambat 30 menit
dari rencana semula. Manajer proyek harus selalu menyadari jalur kritis, sehingga mereka dapat
merespons dengan cepat untuk menjaga proyek tetap pada jalurnya. Microsoft Project dan perangkat
lunak manajemen proyek lainnya dapat menyoroti rangkaian tugas yang membentuk jalur kritis.

Bagaimana Saya Menghitung Jalur Kritis?

Gambar 3-21 menunjukkan proyek pelatihan dengan lima tugas. Perhatikan bahwa analis telah
mengatur tugas dan memasukkan nama tugas, ID, dan durasi. Pertama, Anda harus meninjau pola
tugas. Dalam contoh ini, Tugas 1 diikuti oleh Tugas 2, yang merupakan tugas dependen. Tugas 2
memiliki dua tugas penerus: Tugas 3 dan Tugas 4. Tugas 3 dan 4 adalah tugas pendahulu untuk Tugas
5. Langkah selanjutnya adalah menentukan tanggal mulai dan selesai, yang akan menentukan jalur
kritis untuk proyek tersebut. Penjelasan berikut akan memandu Anda melalui proses langkah demi
langkah. Hasilnya ditunjukkan pada Gambar 3-22 di halaman berikutnya.
PEMANTAUAN DAN PENGENDALIAN PROYEK
Terlepas dari apakah proyek direncanakan dan dijadwalkan dengan perangkat lunak manajemen
proyek atau dengan cara lain, manajer proyek harus melacak tugas dan kemajuan anggota tim,
membandingkan kemajuan aktual dengan rencana proyek, memverifikasi penyelesaian tonggak
proyek, dan menetapkan standar dan memastikan bahwa standar tersebut diikuti.
Teknik Pemantauan dan Pengendalian
Untuk membantu memastikan bahwa standar kualitas terpenuhi, banyak manajer proyek melakukan
panduan terstruktur. Panduan terstruktur adalah tinjauan pekerjaan anggota tim proyek oleh anggota
tim lainnya. Umumnya, analis sistem meninjau pekerjaan analis sistem lain, dan pemrogram meninjau
pekerjaan pemrogram lain, sebagai bentuk tinjauan sejawat. Panduan terstruktur berlangsung di
seluruh SDLC dan disebut tinjauan desain, tinjauan kode, atau tinjauan pengujian, tergantung pada
fase terjadinya.
Mempertahankan Jadwal
Mempertahankan jadwal proyek dapat menjadi tantangan, dan sebagian besar proyek mengalami
setidaknya beberapa masalah atau penundaan. Dengan memantau dan mengendalikan pekerjaan,
manajer proyek mencoba mengantisipasi masalah, menghindarinya atau meminimalkan dampaknya,
mengidentifikasi solusi potensial, dan memilih cara terbaik untuk menyelesaikan masalah. Semakin
baik rencana awal, semakin mudah untuk mengontrol proyek. Jika ada tonggak yang jelas dan dapat
diverifikasi, akan mudah untuk menentukan apakah dan kapan target tersebut tercapai. Jika ada cukup
milestone dan pos pemeriksaan yang sering, masalah akan terdeteksi dengan cepat. Sebuah proyek
yang direncanakan dan dijadwalkan dengan PERT / CPM dapat dilacak dan dikendalikan
menggunakan teknik yang sama. Saat pekerjaan berlanjut, manajer proyek merevisi rencana untuk
mencatat waktu aktual untuk tugas yang diselesaikan dan merevisi waktu untuk tugas yang belum
selesai. Manajer proyek menghabiskan sebagian besar waktunya untuk melacak tugas di sepanjang
jalur kritis, karena penundaan dalam tugas tersebut memiliki potensi terbesar untuk menunda atau
membahayakan proyek. Namun, tugas lain tidak dapat diabaikan. Misalnya, tugas yang tidak berada
di jalur kritis membutuhkan waktu terlalu lama dan menghabiskan waktu jeda yang dialokasikan.
Pada titik itu, tugas sebenarnya menjadi bagian dari jalur kritis, dan penundaan lebih lanjut akan
menghambat keseluruhan proyek.
PELAPORAN
Anggota tim proyek secara teratur melaporkan kemajuan mereka kepada manajer proyek, yang pada
gilirannya melapor kepada manajemen dan pengguna. Seperti yang ditunjukkan pada Gambar 3-23,
manajer proyek mengumpulkan, memverifikasi, mengatur, dan mengevaluasi informasi yang dia
terima dari tim. Kemudian manajer memutuskan informasi mana yang perlu diteruskan, menyiapkan
ringkasan yang dapat dipahami dengan mudah, menambahkan komentar dan penjelasan jika
diperlukan, dan menyerahkannya kepada manajemen dan pengguna.
Rapat Status Proyek
Manajer proyek, seperti yang ditunjukkan pada Gambar 3-24, menjadwalkan pertemuan rutin untuk
memperbarui tim dan mendiskusikan status, masalah, masalah, dan peluang proyek. Meskipun rapat
bisa memakan waktu, sebagian besar manajer proyek percaya bahwa itu sepadan dengan usahanya.
Sesi ini memberi anggota tim kesempatan untuk berbagi informasi, mendiskusikan masalah umum,
dan menjelaskan teknik baru. Pertemuan tersebut juga memberikan kesempatan kepada manajer
proyek untuk mencari masukan dan melakukan sesi curah pendapat.
Laporan Status Proyek
Sebelum melangkah lebih jauh, Anda harus membaca fitur Pertanyaan Etika di halaman 125, yang
menjelaskan konflik menarik di Final Four Industries. Sebuah proyek bermasalah, tetapi manajer
proyek enggan melaporkan masalah tersebut. Kasus tersebut menyoroti masalah etika penting yang
sering muncul dalam situasi ini. Seorang manajer proyek harus melapor secara teratur kepada
supervisor langsungnya, manajemen atas, dan pengguna. Meskipun laporan kemajuan mungkin
diberikan secara lisan kepada supervisor langsung, laporan kepada manajemen dan pengguna
biasanya ditulis. Bagan Gantt sering disertakan dalam laporan kemajuan untuk menunjukkan status
proyek secara grafis. Memutuskan bagaimana menangani potensi masalah bisa jadi sulit. Pada titik
manakah Anda harus memberi tahu manajemen tentang kemungkinan pembengkakan biaya,
penundaan jadwal, atau masalah teknis? Di satu sisi ekstrim adalah manajer proyek yang terlalu
berhati-hati yang memperingatkan manajemen akan setiap potensi hambatan dan sedikit penundaan.
Bahayanya di sini adalah bahwa manajer kehilangan kredibilitas selama periode waktu tertentu, dan
manajemen mungkin mengabaikan situasi yang berpotensi serius. Di sisi lain adalah manajer proyek
yang mencoba menangani semua situasi sendirian dan tidak memberi tahu manajemen sampai
masalah menjadi serius. Pada saat manajemen waktu mempelajari masalah tersebut, mungkin hanya
sedikit waktu yang tersisa untuk bereaksi atau menyusun solusi. Tindakan terbaik manajer proyek
terletak di antara dua ekstrem, tetapi mungkin lebih dekat ke yang pertama. Jika Anda tidak yakin
dengan konsekuensinya, Anda harus berhati-hati dan memperingatkan manajemen tentang
kemungkinan masalah. Saat Anda melaporkan situasi tersebut, Anda juga harus menjelaskan apa yang
Anda lakukan untuk menangani dan memantau masalah. Jika Anda yakin situasinya berada di luar
kendali Anda, Anda mungkin ingin menyarankan tindakan yang mungkin diambil manajemen untuk
menyelesaikan situasi tersebut. Kebanyakan manajer menyadari bahwa masalah memang terjadi pada
sebagian besar proyek; lebih baik memberi tahu manajemen lebih cepat daripada nanti.
CONTOH MANAJEMEN PROYEK
Anda dapat menggunakan contoh-contoh ini untuk mempraktikkan keterampilan yang Anda pelajari
di bab ini. Anda juga akan melihat bagaimana Anda dapat menggunakan perangkat lunak manajemen
proyek untuk membantu Anda mengelola dan menampilkan tugas.
Contoh PERT / CPM
Gambar 3-25 menunjukkan daftar 11 tugas. Contohnya lebih kompleks, tetapi pedoman yang sama
berlaku. Perhatikan bahwa setiap tugas memiliki ID, deskripsi, durasi, dan referensi ke tugas
sebelumnya, jika ada, yang harus diselesaikan sebelum tugas bisa dimulai. Perhatikan juga bahwa
tugas dependen dapat memiliki satu atau beberapa tugas sebelumnya. Anda membuat bagan PERT /
CPM dari daftar tugas ini dalam proses dua langkah:
MANAJEMEN RISIKO
Setiap proyek TI melibatkan risiko yang harus ditangani oleh analis sistem dan manajer proyek.
Resiko adalah kejadian yang dapat mempengaruhi proyek secara negatif. Manajemen risiko adalah
proses mengidentifikasi, menganalisis, mengantisipasi, dan memantau risiko untuk meminimalkan
dampaknya terhadap proyek.
Langkah-langkah dalam Manajemen Risiko
Langkah pertama dalam manajemen risiko adalah mengembangkan rencana khusus. Meskipun pakar
manajemen proyek berbeda dalam hal jumlah langkah atau tahapan, daftar dasar akan mencakup
tugas-tugas berikut:
• Mengembangkan rencana manajemen risiko. Sebuah rencana manajemen risiko mencakup tinjauan
ruang lingkup proyek, pemangku kepentingan, anggaran, jadwal, dan faktor internal atau eksternal
lainnya yang mungkin mempengaruhi proyek. Rencana tersebut harus menetapkan peran dan
tanggung jawab proyek, metode dan prosedur manajemen risiko, kategori risiko, dan rencana
kontinjensi.
• Identifikasi risikonya. Identifikasi risiko mencantumkan setiap risiko dan menilai kemungkinan hal
itu dapat memengaruhi proyek. Rinciannya akan tergantung pada proyek tertentu, tetapi sebagian
besar daftar akan mencakup alat identifikasi, dan deskripsi singkat tentang risiko, apa yang mungkin
menyebabkannya terjadi, siapa yang akan bertanggung jawab untuk merespons, dan potensi dampak
risiko.
 • Analisis risikonya. Ini biasanya merupakan proses dua langkah: Analisis risiko kualitatif dan analisis
risiko kuantitatif. Analisis risiko kualitatif mengevaluasi setiap risiko dengan memperkirakan
probabilitas akan terjadi dan tingkat dampaknya. Manajer proyek dapat menggunakan rumus untuk
menimbang nilai risiko dan dampak, atau mereka dapat menampilkan hasilnya dalam kisi dua sumbu.
Misalnya, bagan Microsoft Excel XY dapat digunakan untuk menampilkan matriks, seperti yang
ditunjukkan pada Gambar 3-33. Di bagan, perhatikan berbagai kombinasi peringkat risiko dan
dampak untuk lima nilai sampel. Alat ini dapat membantu manajer proyek untuk fokus pada area yang
paling kritis, di mana kemungkinan risiko dan potensi dampaknya tinggi.
Tujuan dari analisis risiko kuantitatif adalah untuk memahami dampak aktual dalam hal dolar, waktu,
ruang lingkup proyek, atau kualitas. Analisis risiko kuantitatif dapat melibatkan proses pemodelan
yang disebut analisis bagaimana-jika, yang memungkinkan manajer proyek untuk memvariasikan satu
atau lebih elemen dalam model untuk mengukur efek pada elemen lain. Topik ini dibahas lebih detail
di Bab 12, Mengelola Dukungan dan Keamanan Sistem.

• Buat rencana respons risiko. Rencana respons risiko adalah upaya proaktif untuk mengantisipasi
risiko dan menggambarkan rencana tindakan untuk menghadapinya. Rencana respons risiko yang
efektif dapat mengurangi dampak keseluruhan dengan memicu tindakan yang tepat waktu dan
tepat.
• Pantau risiko. Aktivitas ini berlangsung selama proses manajemen risiko. Penting untuk
melakukan proses pelacakan berkelanjutan yang dapat mengidentifikasi risiko baru, melihat
perubahan dalam risiko yang ada, dan memperbarui area manajemen risiko lainnya.
rencana.

Perangkat Lunak Manajemen Risiko

Sebagian besar perangkat lunak manajemen proyek menyertakan fitur canggih yang memungkinkan
manajer proyek untuk menetapkan tanggal tertentu sebagai batasan, menyelaraskan dependensi tugas,
mencatat faktor eksternal yang mungkin memengaruhi tugas, melacak kemajuan, dan menampilkan
tugas yang terlambat dari jadwal. Selain itu, beberapa vendor menawarkan add-on manajemen risiko,
seperti yang ditunjukkan pada Gambar 3-34. Microsoft Project edisi perusahaan, Microsoft Project
Server 2010, memiliki kapabilitas manajemen risiko bawaan yang dapat digunakan untuk proyek
skala besar di seluruh perusahaan. Microsoft mengklaim bahwa perangkat lunak dapat
menghubungkan risiko dengan tugas dan proyek tertentu, menentukan probabilitas dan dampak,
menetapkan kepemilikan, dan melacak kemajuan untuk mengelola proyek dengan lebih efisien.
Model manajemen risiko Microsoft mencakup faktor-faktor berikut:

• Probabilitas, yang merepresentasikan kemungkinan terjadinya risiko, yang dinyatakan dalam

persentase
• Dampak, yang menunjukkan tingkat efek merugikan jika risiko terjadi, dalam skala 1 sampai 10
• Biaya, yang menunjukkan potensi dampak finansial dari risiko
• Kategori, yang menentukan jenis risiko
• Deskripsi, yang menjelaskan sifat risiko
• Rencana mitigasi, yang mengidentifikasi rencana untuk mengendalikan atau membatasi risiko
• Rencana kontinjensi, yang menetapkan tindakan yang akan diambil jika risiko tersebut terjadi
• Trigger, yang mengidentifikasi kondisi yang akan memulai rencana kontinjensi

Berbekal informasi tersebut, tim IT dapat membuat rekomendasi terkait risiko yang terkait dengan
proyek. Bergantung pada sifat dan besarnya risiko, keputusan akhir mungkin dibuat oleh manajemen.
MENGELOLA UNTUK SUKSES
Agar berhasil, sistem informasi harus memenuhi persyaratan bisnis, sesuai anggaran, diselesaikan
tepat waktu, dan - yang terpenting - dikelola secara efektif. Ketika sebuah proyek mengalami masalah,
alasannya biasanya melibatkan masalah bisnis, anggaran, atau jadwal, seperti yang dijelaskan di
bagian berikut. Selain merencanakan dan mengelola proyek, seorang manajer proyek harus mampu
mengenali masalah dan menanganinya secara efektif.
Masalah Bisnis
Tujuan utama dari setiap sistem adalah memberikan solusi untuk masalah atau peluang bisnis. Jika
sistem tidak melakukan ini, maka itu gagal - terlepas dari reaksi positif dari pengguna, kinerja
anggaran yang dapat diterima, atau pengiriman tepat waktu. Ketika informasi sistem tidak memenuhi
persyaratan bisnis, penyebabnya mungkin termasuk persyaratan yang tidak teridentifikasi atau tidak
jelas, cakupan yang tidak ditentukan secara memadai, target yang tidak tepat, jalan pintas atau
pekerjaan yang ceroboh selama analisis sistem, pilihan desain yang buruk, pengujian yang tidak
memadai atau prosedur pengujian yang tidak memadai, dan kurangnya prosedur kontrol perubahan.
Sistem juga gagal karena perubahan budaya, pendanaan, atau tujuan organisasi. Sistem yang tidak
memenuhi kebutuhan bisnis juga menimbulkan masalah bagi pengguna dan mengurangi semangat
kerja dan produktivitas karyawan.
Seperti yang Anda pelajari di Bab 2, proyek tanpa definisi ruang lingkup yang jelas berisiko, karena
cenderung berkembang secara bertahap, tanpa otorisasi khusus, dalam proses yang disebut creep
proyek. Namun, meskipun proyek dijelaskan dengan jelas, itu harus dikelola secara konstan.
Masalah Anggaran
Pembengkakan biaya biasanya disebabkan oleh satu atau beberapa hal berikut:

• Perkiraan tidak realistis yang terlalu optimis atau berdasarkan informasi yang tidak lengkap
• Kegagalan untuk mengembangkan perkiraan yang akurat yang memperhitungkan semua biaya
selama umur proyek
• Pemantauan kemajuan yang buruk dan respons yang lambat terhadap tanda-tanda peringatan dini
masalah
• Jadwal penundaan karena faktor-faktor yang tidak terduga
• Masalah sumber daya manusia, termasuk pergantian karyawan, pelatihan yang tidak memadai, dan
motivasi
Jadwalkan Masalah
Masalah dengan jadwal dan tonggak proyek dapat menunjukkan kegagalan untuk mengenali
ketergantungan tugas, kebingungan antara upaya dan kemajuan, metode pemantauan dan kontrol yang
buruk, konflik kepribadian di antara anggota tim, atau pergantian personel proyek. Kegagalan suatu
proyek TI juga dapat disebabkan oleh teknik manajemen proyek yang buruk.
Jika manajer proyek gagal untuk merencanakan, mengatur, mengatur, mengawasi,
mengkomunikasikan, memotivasi, mengevaluasi, mengarahkan, dan mengendalikan dengan baik,
maka proyek tersebut pasti akan gagal. Bahkan ketika faktor-faktor di luar kendalinya berkontribusi
pada kegagalan, manajer proyek bertanggung jawab untuk mengenali tanda-tanda peringatan dini dan
menanganinya secara efektif.
GARIS BAWAH
Manajemen proyek adalah tugas yang menantang. Manajer proyek harus waspada, kompeten secara
teknis, dan sangat pandai. Mereka juga harus menjadi komunikator yang baik dengan keterampilan
sumber daya manusia yang kuat. Manajer proyek dapat bangga ketika dia menangani proyek yang
berhasil yang membantu perusahaan mencapai tujuan bisnisnya, seperti peluncuran produk Apple
yang ditunjukkan pada Gambar 3-35. Sayangnya, proyek dapat dan memang tergelincir karena
berbagai alasan. Ketika masalah terjadi, kemampuan manajer proyek untuk menangani situasi menjadi
faktor penting. Ketika manajer proyek pertama kali mengetahui bahwa sebuah proyek bermasalah,
pilihan apa yang tersedia? Alternatifnya dapat mencakup pemangkasan persyaratan proyek,
menambah sumber daya proyek, menunda tenggat waktu proyek, dan meningkatkan kontrol dan
prosedur manajemen. Terkadang, ketika proyek mengalami penundaan atau pembengkakan biaya,
sistem masih dapat dikirimkan tepat waktu dan sesuai anggaran jika beberapa persyaratan yang
kurang penting dipangkas. Sistem dapat dikirimkan untuk memenuhi persyaratan yang paling
diperlukan, dan fitur tambahan dapat ditambahkan nanti sebagai bagian dari proyek pemeliharaan atau
peningkatan. Jika sebuah proyek berada dalam masalah karena kurangnya sumber daya atau dukungan
organisasi, manajemen mungkin bersedia memberikan komitmen dan prioritas yang lebih tinggi pada
proyek tersebut. Misalnya, manajemen mungkin setuju untuk menambahkan lebih banyak orang ke
proyek yang terlambat dari jadwal. Menambahkan staf, bagaimanapun, akan mengurangi waktu
penyelesaian proyek hanya jika orang tambahan dapat diintegrasikan secara efektif ke dalam tim
pengembangan. Jika anggota tim kurang berpengalaman dengan aspek tertentu dari teknologi yang
dibutuhkan, bantuan sementara mungkin diperoleh dari konsultan TI atau staf paruh waktu. Namun,
menambah staf bisa berarti melatih dan mengarahkan orang baru. Dalam beberapa situasi,
menambahkan lebih banyak orang ke suatu proyek sebenarnya dapat meningkatkan waktu yang
diperlukan untuk menyelesaikan proyek karena prinsip yang disebut Hukum Brooks. Konsep menarik
ini dikemukakan oleh Frederick Brooks, Jr., seorang insinyur IBM, yang mengamati bahwa
menambahkan tenaga kerja ke proyek perangkat lunak yang terlambat hanya membuatnya kemudian.
Brooks mencapai kesimpulan ini ketika dia melihat bahwa pekerja baru dalam sebuah proyek harus
dididik dan diinstruksikan oleh karyawan yang ada yang produktivitasnya sendiri dikurangi.