• Project Factor

Merupakan hal yang penting bahwa pengembangan dan obyektifnya terdefinisi dengan baik dan diketahui secara jelas oleh semua anggota tim dan semua stakeholder utama. Jika hal ini tidak terlaksana dapat muncul resiko yang berkaitan dengan keberhasilan pengembangan tersebut. Dengan cara serupa, perencanaan kualitas yang formal dan telah disepakati harus dipahami oleh semua partisipan.  Jika perencanaan kualitas kurang baik dan tidak tersosialisasi maka  dapat mengakibatkan gangguan pada pengembangan tersebut.

• Project Methods

Dengan mempergunakan spefikasi dan metode terstruktur yang baik pada manajemen pengembangan dan pengembangan sistem akan mengurangi resiko penyerahan sistem yang tidak memuaskan atau terlambat. Akan tetapi penggunaan metode tersebut untuk pertama kali dapat mengakibatkan problem dan delay.

• Hardware/software Factor

Sebuah pengembangan yang memerlukan hardware baru untuk pengembangan mempunyai resiko yang lebih tinggi dibandingkan dengan software yang dapat dibangun pada hardware  yang sudah ada (dan familiar). Sebuah sistem yang dikembangkan untuk satu jenis hardware atau software platform tertentu jika dipergunakan pada hardware atau software platform lainnya bisa menimbulkan resiko tambahan (dan tinggi) pada saat instalasi.

• Changeover Factor

Kebutuhan perubahan “all-in-one” kedalam suatu sistem baru mempunyai resiko tertentu. Perubahan secara bertahap atau gradual akan meminimisasi resiko akan tetapi cara tersebut tidak praktis. Menjalankan secara paralel dapat memberikan solusi yang aman akan tetapi biasanya tidak mungkin atau terlalu mahal.

• Supplier Factor

Suatu pengembangan yang melibatkan organisasi eksternal yang tidak dapat dikendalikan secara langsung dapat mempengaruhi keberhasilan pengembangan.  Misal tertundanya  instalasi jalur telpon atau pengiriman peralatan yang sulit dihindari- dapat berpengaruh terhadap keberhasilan pengembangan.

• Environment Factor

Perubahan pada lingkungan dapat mempengaruhi keberhasilan pengembangan. Misal terjadi perubahan regulasi pajak, akan mempunyai dampak yang cukup serius pada pengembangan aplikasi penggajian.

• Health and Safety Factor

Ada satu isu utama yaitu faktor kesehatan dan keamanan dari partisipan yang terlibat dalam pengembangan software walaupun tidak umum (dibandingkan dengan pengembangan teknik sipil) yang dapat mempengaruhi aktifitas pengembangan.

Kesalahan estimasi

Beberapa pekerjaan lebih sulit untuk melakukan estimasi dibandingkan pekerjaan lainnya disebabkan karena terbatasnya pengalaman pada pekerjaan serupa atau disebabkan karena jenis pekerjaan tersebut. Pembuatan sebuah user manual merupakan langkah yang tepat yang dapat dipertanggungjawabkan dan sebagai bukti bahwa kita pernah mengerjakan tugas yang serupa sebelumnya. Dengan pengalaman itu seharusnya kita mampu untuk melakukan estimasi dengan lebih tepat mengenai berapa lama pekerjaan dapat diselesaikan dan berapa besarnya biaya yang dibutuhkan. Selain itu, waktu yang dibutuhkan untuk melakukan pengujian dan penelusuran program dapat menjadi sesuatu hal yang sulit diprediksi dengan tingkat keakuratan yang serupa walaupun kita pernah membuat program yang serupa sebelumnya.

Estimasi dapat ditingkatkan melalui analisa data historis untuk aktifitas yang serupa dan untuk sistem yang serupa. Dengan menyimpan perbandingan antara estimasi semula dengan hasil akhir akan mengakibatkan beberapa tipe pekerjaan sulit diestimasi secara tepat.

Resiko ini terjadi jika perkiraan LOC pada kenyataan yang ada jauh melebihi LOC perkiraan pada perhitungan COCOMO, yang mengakibatkan berubahnya jadwal pengerjaan dan biaya operasional.

Asumsi perencanaan

Pada setiap tahapan perencanaan, asumsi perlu dibuat, jika tidak benar maka dapat mengakibatkan resiko tersebut beresiko. Misal pada jaringan aktifitas, aktifitas dibangun berdasarkan pada asumsi menggunakan metode desain tertentu dimana memungkinkan urutan aktifitas diubah. Kita biasanya membuat asumsi bahwa setelah coding, biasanya sebuah modul akan diuji dan kemudian diintegrasikan dengan modul lainnya. Akan tetapi kita tidak merencanakan pengujian modul yang dapat mangakibatkan perubahan desain awal. Hal ini dapat terjadi setiap saat.

Pada setiap tahapan pada proses perencanaan, sangat penting untuk memeperinci secara eksplisit semua asumsi yang dibuat dan mengidentifikasi apa pengaruhnya jika ternyata dalam pelaksanaannya tidak sesuai dengan yang sudah direncanakan.

Kemungkinan

Beberapa kemungkinan dapat saja tidak pernah terlihat dan kita hanya dapat menyakinkan diri kita sendiri bahwa ada sesuatu yang tidak dapat dibayangkan, kadang-kadang dapat terjadi. Akan tetapi biasanya jarang terjadi hal seperti itu. Mayoritas kejadian yang tidak diharapkan biasanya dapat diidentifikasi beberapa spesifikasi kebutuhan kemungkinan diubah setelah beberapa modul telah dikodekan, programmer senior meninggalkan pengembangan, perangkat keras yang diperlukan tidak dikirim tapat waktu. Beberapa kejadian semacam itu dapat terjadi sewaktu-waktu dan walaupun kejadian tersebut kemungkinan terjadinya relatif rendah akan tetapi kejadian tersebut perlu dipertimbangkan dan direncanakan.

Metode untuk evaluasi pengaruh ketidakpastian ini terhadap jadwal proyek:

• Penggunaan PERT untuk evaluasi pengaruh ketidakpastian

PERT dikembangkan untuk menghitung estimasi ketidakpastian lingkungan terhadap durasi pekerjaan. PERT dikembangkan pada suatu lingkungan proyek yang mahal, beresiko tinggi dan kompleks. Metode PERT ini memerlukan tiga estimasi:

-      Most likely time

              Waktu yang diperlukan untuk menyelesaikan pekerjaan dalam situasi normal dan diberikan simbol m.

-      Optimistic time

              Waktu tersingkat yang diperlukan untuk menyelesaikan pekerjaan dan diberi simbol a.

-      Pessimistic time

              Waktu terlama yang diperlukan untuk menyelesaikan pekerjaan dikarenakan berbagai kemungkinan yang masuk akal dan diberikan simbol b.

PERT mengkombinasikan ketiga estimasi tersebut untuk membentuk durasi tunggal yang diharapkan, t_e = a + 4m + b

• Penggunaan durasi yang diharapkan

Durasi yang diharapkan dipergunakan supaya suatu forward pass dapat melalui sebuah jaringan; dengan mempergunakan metode yang sama dengan teknik CPM. Akan tetapi dalam hal ini, tanggal aktifitas yang dihitung bukan merupakan tanggal paling awal akan tetapi merupakan tanggal yang diharapkan dapat mencapai aktifitas tersebut. 

Jaringan PERT yang diperlihatkan pada gambar 3 memperlihatkan bahwa kita berharap proyek tersebut dapat diselesaikan dalam waktu 13,5 minggu- tidak seperti CPM yang tidak memperlihatkan tanggal paling awal untuk menyelesaikan proyek tersebut akan tetapi tanggal yang diharapkan (atau most likely). Salah satu keuntungan dari pendekatan ini adalah menempatkan sebuah emphasis dalam ketidakpastian di dunia nyata. 

Tabel 6.3 berikut ini memperlihatkan contoh estimasi durasi aktifitas yang memperkirakan durasi secara optimistic(a), pessimistic(b) dan most likeliy(m).