BAB I

PENDAHULUAN

1.1 Latar Belakang

Ketika perusahaan mengembangkan atau membuat produk, layanan, pasar, sistem

perusahaan, atau aplikasi baru, mereka menggunakan pendekatan manajemen proyek. Manajemen
proyek adalah metodologi terstruktur untuk merencanakan, mengelola, dan mengendalikan
penyelesaian suatu proyek sepanjang siklus hidupnya. Panduan Project Management Body of
Knowledge (PMBOK) menguraikan lima kelompok proses manajemen proyek, yaitu: memulai konsep
atau ide, perencanaan, executing, pengawasan dan pengendalian, closing dan postmortem. Setiap
proses merupakan upaya mewujudkan proyek dari ide ke implementasi sedemikian rupa untuk
membantu memastikan penyelesaiannya berhasil.

Siklus suatu proyek dimulai dengan ide atau konsep dan rencana. Jika proyek disetujui,
maka tim proyek melanjutkan untuk melakukan tugas dan menyelesaikan proyek. Sebagai bagian
dari penutupan proyek, peserta melakukan postmortem untuk mendokumentasikan pelajaran yang
diperoleh untuk meningkatkan proyek mereka berikutnya.

Setiap proyek memiliki berisiko. Manajemen proyek dan proses pengembangan sistem
yang tepat membantu agar proyek TI disampaikan tepat waktu, sesuai anggaran, dan sesuai dengan
spesifikasi. Untuk meminimalkan risiko kegagalan, proyek direncanakan, dievaluasi, dan dipantau
secara ketat. Pertemuan status mingguan, komunikasi, dan pelaporan sangat penting untuk mencari
tahu tentang potensi masalah sejauh mungkin di muka dan memperbaikinya untuk mencegah krisis.
Manajemen proyek semakin penting untuk semua jenis proyek karena kompleksitas teknologi,
anggaran yang lebih ketat, persaingan yang lebih ketat, dan persyaratan waktu pengiriman yang
lebih singkat. Singkatnya, dengan manajemen proyek yang baik akan meminimalisir kemungkinan
perusahaan untuk menanggung kegagalan atau penundaan proyek.

1
 BAB II

PEMBAHASAN

2. 1 Opening Case : Memastikan proyek anda berada pada jalurnya, mengetahui ketika ada
masalah dan kegagalan system bagasi DIA

Mayoritas proyek IT gagal pada setidaknya satu standar penilaian keberhasilan, hal ini
menghabiskan milyaran dollar setiap tahunnya. Proyek bisa gagal diakibatkan dari satu atau
lebih alasan berikut:

1. Kelebihan anggaran
2. Keterlambatan anggaran
3. Menghasilkan lebih sedikit fitur atau fungsi dari yang direncanakan
4. Penghentian sebelum perencanaan
5. Selesai tapi gagal

Kecuali pada kasus yang ektrim, evaluasi kesuksesan atau kegagalan merupakan hal
yang subjektif karna waktu dan biaya untuk menyelesaikan proyek tersebut merupakan
estimasi, sebagai contoh anggaran atau jadwal proyek dapat dinilai dari menetapkan range
anggaran atau waktu yang dapat diterima.

Semua orang harus menyadari bahwasanya proyek yang komplek kadang mengalami
keberhasilan dan kegagalan. Untuk mengurangi tingkat kegagalan proyek IT tergantung dari
kompetensi dalam manajemen proyek. Sering kali proses postmortem dilewatkan dengan
alasan menghemat waktu dan uang. Padahal pada proses postmortem orang akan memperlajari
hal apa saja yang berkotribusi pada keberhasilan proyek dan apa yang tidak. Tidak belajar dari
proyek-proyek masalalu dan mengulangi kesalahan yang bisa dihindari secara konsisten menjadi
rintangan utama dalam memperbaiki IT manajemen proyek.

Memastikan Proyek berada pada Jalurnya

Dalam kurun waktu dua bulan, 500 perusahaan belajar bahwa enam dari proyek
utama sedang dalam masalah. Salah satu masalah terjadi tiba-tiba tanpa ada pemberitahuan.
CIO merasa bingung dan eksekutif manajemen ingin tahu siapa yang bertanggung jawab atas
kejadian tersebut. Manajer Proyek perusahaan (PMO) dimintai penjelasan atas kekacauan yang
terjadi.

Selama proses penyelidikan oleh PMO, PMO mengetahui bahwa staff proyek telah
bekerja keras dan merasa tertekan untuk menyelesaikan tiap masalah sendiri. Enam proyek

2
 yang sedang dalam masalah tersebut berasal dari sponsor yang sangat kuat dan akan
menyerang orang yang membawa berita buruk. Jadi jika proyek mengalami masalah maka
karyawan akan bekerja keras untuk mencari solusinya, tapi tetap saja proyeknya gagal.

Berikut tiga pelajaran untuk manjaga proyek tetap berada pada jalurnya:

1. Tetapkan rencana proyek yang realistis dan detail dengan waktu dan sumber daya yang
memadai.
Proyek-proyek mengacu pada peristiwa-peristiwa tidak terduga dan tidak dapat
dikendalikan, sehingga mereka membutuhkan waktu luang dalam penjadwalan dan
penganggaran, namun tim proyek dapat ditekan untuk mengurangi biaya, sebagai
tanggapan, mereka mungkin mengurangi waktu dan anggaran yang dialokasika untuk
pelatihan, pengujian dan manajemen perubahan. Pemotongan ini menghasilkan kualitas
yang buruk dan penerimaan pengguna yang lebih sedikit.
2. Mendorong umpan feedback dan bersedia untuk mendengar
Semua proyek mengalami kesulitan, pastikan karyawan tahu bahwa mereka tidak akan
dihukum apabila mereka menyampaikan kekhawatiran mereka, bahkan saat anggota proyek
lain menyangkal ada masalah. Ketakutan akan menghalangi aliran informasi yang
bermanfaat.
3. Memperkirakan Risiko dengan cara melakukan review secara teratur atas status proyek.
Sebagian besar tidak ada yang suka ulasan proyek formal,tetapi itu diperlukan untuk
mengatasi masalah saat ini dan potensi masalah yang akan datang.

Ketahui Ketika ada Masalah

Berikut daftar red flag yang menunjukan bahwa proyek sedang dalam masalah:

1. Proyek telah diluncurkan tanpa dukungan senior by- in

Kegagalan dipastikan tanpa dukungan manajemen senior, situasi ini bisa terjadi jika pada
perusahaan memiliki ide dan mulai untuk merencanakan dana mengalokasikan sumber daya
tanpa menunggu manajemen senior by-in. tidak ada satupun orang lain yang tahu bahwa
proyek tersebut belum disetujui atau dianggarkan, banyak kasus seperti ini berlanjut sampai
pada titik dimana uang dibelanjakan, lalu proyek tersebut akan gagal sama sekali.
2. Tidak ada rencana detail
Setiap proyek dengan durasi pengerjaan lebih dari dua atau tiga minggu membutuhkan
perencanaan yang terperici dan jalas.

3
 3. Rapat terjadwal dengan mengabaikan ketersediaan anggota tim
Pertemuan yang bentrok dengan pertemuan penting lain akan mengkibatkan anggota vital
berhalangan hadir, biasanya untuk efektivitas anggota yang bisa hadir mengabaikan anggota
lain yang tidak bisa hadir dan tetap melaksanakan meeting, ini akan mengganggu jalanya
sebuah proyek karna ada anggota vital yang berhalangan hadir.
4. Pengguna hanya terlibat sedikit atau tidak ada sama sekali keterlibatan
Proyek yang besar dan kompleks dihasilkan dari user yang terbiasa dengan proses yang
selesai dan mengapa mereka menyelesaikannya dengan cara itu. Semakin banyak user
terlibat, maka proyek akan semakin sukses, jika proyek anda terlibat dengan banyak bagian,
pastikan setiap user terlibat didalamnya.
5. Tidak ada rencana percobaan detil
Pengujian merupakan hal yang penting untuk kesuksesan proyek. Satu pengujian akan
terintegrasi dengan pengujian2 lain.
6. Tidak ada anggaran pelatihan
Ketika dihadapkan dengan kelebihan anggaran, seringkali anggaran pelatihan yang dijadikan
korban, kemudian mengandalkan user dan karyawan helpdesk untuk mencari tahu system
baru. Dan ini artinya proyek dalam kegagalan. Bersedialah menunda proyek jika pelatihan
tidak tersedia.

Kegagalan System Bagasi DIA (Deven Internasional Airport)

Kasus klasik “bencana” dalam proyek manajemen merupakan proyek penanganan bagasi
di Deven Internasional Airport (DIA) yang baru. Proyek ini direncanakan untuk membuat pelayanan
bagasi terotomatis paling canggih mengintegrasikan ketiga congcourse kedalam satu system. Istilah
“paling canggih, otomatis, dan terintegrasi”dengan jelas menunjukan system akan sangat kompleks
dan berisiko untuk mengalami penundaan. Jadwal yang tidak realistis malah bahkan disertujui
meskipun proyek sangat berisiko mengalami penundaan, dan hal tersebut memaksa pembukaan
systemnya walau belum rampung. System bagasi DIA yang sudah selesaipun belum bisa digunakan
selama 16 bulan selama para insinyur mengerjakan kompleksitas system tersebut, dan penundaan
itu menelan biaya sebesar 560 Juta US Dollar dan biaya pinjaman konstruksi untuk
mempertahankan DIA yang kosong tersebut adalah sebesar 1.1 Juta US Dollar per hari sepenjang
tahun menunda.

Proyek Diperkecil dan dihapus satu Dekade kemudian

Proyek tersebut diskalakan akan diturunkan dari skala aslinya, hanya system penangan
bagasi otomatis diluar yang berjalan sesuai rencana, sementara untuk penanganan bagasi lainya

4
menggunakan troly, dan itu dibangun secara cepat ketika pemegang proyek menyadari bahwa
system otomatis tidak akan berjalan sesuai dengan tujuan. Dan sepuluh tahun kemudian pada
Agustus 2005 perencanaan system otomatis tersebut dihentikan karena masih tidak bekerja dengan
benar dan memakan biaya pemeliharaan sebesar 1 Juta US Dollar per bulan.

Kesalahan Manajemen Proyek.

Sistem penanganan bagasi DIA adalah komponen penting dalam rencana kota Denver untuk
menjadi pusat dari transportasi udara , secara otomatis system penanganan bagasi akan memotong
paling sedikit 30 menit waktu perputaran pesawat. Itu artinya maskapai bisa meminimalkan waktu
penerbangan dan hal tersebut akan membuat DIA lebih kompetitif dibandingkan dengan bandara
lainnya.

Berikut merupakan peristiwa besar dan kesalahan manajemen proyek DIA

1. November 1989 Pekerjaan konstruksi DIA dimulai

2. Ahli yang Diabaikan
Pada 1990, kota Denver menyewa Asosiasi Breider Neidle Patrone untuk melakukan analisis
kelayakan membangun system bagasi terpadu. Laporan menyarankan bahwa kompleksitas
membuat proyek menjadi tidak layak. Para ahli dari bandara Munich menyarankan bahwa
system Munich yang jauh lebih sederhana membutuhkan waktu 2 tahun penuh untuk
dibangun dan telah beroperasi 24/7 selama 6 bulan sebelum pembukaan untuk
kelancarannya.
3. Musim panas 1991: Tim Manajemen Proyek DIA memberikan penwaran untuk system
penanganan bagasi otomatis
4. Kompleksitas yang diremehkan
Musim gugur 1991, dari 16 perusahaan yang masuk dalam daftar penawaran proyek
tersebut hanya 3 perusahaan yang merespon, tidak ada perusahaan yang menyelesaikan
proyek tepat waktu untuk pembukaan pada Oktober 1993. Dan 3 perusahaan tersebut
ditolak kemudian pencarian mendesak untuk perusahaan baru untuk melanjutkan proyek
tersebut.
5. Perencanaan yang buruk dan harapan yang tidak mungkin
Pada April 1992, DIA menandatangani kontrak dengan BAE system untuk menyelesaikan
proyek tepat waktu untuk pembukaan Oktober 1993 dan mengabaikan ahli bahwa target
akan sulit untuk dicapai.
6. Kurangnya uji kelayakan

5
 Ketentuan Kontrak Antara DIA dan BAE dan spesiikasi proyek dilaksanakan hanya dalam tiga
kali pertemuan. Terburu buru untuk menentukan kontrak kemudian mengabaikan analisis
kelayakan. Tekanan untuk bergerak cepat membuat mereka melewati uji kelayakan yang
kritis
7. Tidak melibatkan pemangku kepentingan
BAE dan Tim manajemen proyek bandara mengabaikan pemengku kepentingan
(stakeholder), maskapai yang sudah terikat kontrak dengan DIA, saat negosiasi dengan tidak
mengikutsertakan stakeholder selalu akan membuat kehilangan strategi.
8. Cakupan merayap
1992-1993 banyak sekali perubahan dari proyek yang telah dibuat. Misalnya, Continental
Airlines meminta untuk menyediakan fasilitas penanganan peralatan ski kedalam area
concourse.
9. Mengabaikan perencanaan antarmuka
Mengabaikan pertemuan tatap muka akan mengurangi kesuksesan sebuah proyek.

Masalah tersebut tersebut terlalu banyak untuk disebutkan untuk kegagalan proyek
system bagasi, dan kasus ini mencerminkan beberapa kemungkinan kegagalan dalam proyek
manajemen. Dari sisi luar, proses dengan system single intergrated pada DIA yang mengetahui
bahwa keterbatasan waktu tidak akan menghasilkan kesuksesan proyek. Dan mengabaikan
keterlibatan para ahli hanya akan mengakibatkan kegagalan pronyek.

2.2 Konsep manajemen proyek

Perusahaan menghadapi tantangan dalam memutuskan investasi mana yang akan

dibuat dan bagaimana caranya untuk mengalokasikan sumber daya yang langka untuk proyek-
proyek yang bersaing. Biasanya manajer senior menyusun kasus bisnis yang mengidentifikasi
peluang, masalah, atau kebutuhan dan hasil bisnis yang diinginkan dari proyek. Karena tidak
semua proyek layak dan tidak semua proyek yang layak dapat didanai, kasus-kasus bisnis ditinjau.
Dalam ulasannya proses, proyek bersaing untuk mendapatkan persetujuan dan pendanaan.

Metode analisis proyek digunakan untuk memprioritaskan proyek yang diusulkan dan
mengalokasikan anggaran untuk pengembalian maksimum. Keputusan penganggaran berlaku
untuk semua investasi bisnis, seperti konstruksi untuk meningkatkan kapasitas produksi,
memasuki pasar baru, memodernisasi toko ritel, R&D, dan memperoleh IT, aplikasi, dan sistem
perusahaan.

6
 Investasi dalam TI untuk inovasi pemasaran atau manufaktur bersaing secara langsung
dengan investasi yang diperlukan untuk mematuhi hukum dan peraturan baru di bidang
keuangan, akuntansi, SDM, dan keamanan siber.

Selama analisis proyek, proyek-proyek TI harus diperiksa secara holistik — yaitu, dalam
kombinasi untuk mengidentifikasi sinergi investasi. Pendekatan ini dikenal sebagai proyek
manajemen portofolio (PPM). PPM adalah seperangkat praktik bisnis untuk mengelola proyek
sebagai portofolio strategis. PPM memastikan keselarasan program dan proyek dengan tujuan
organisasi. Manajemen eksekutif perlu meninjau portofolio dan program, tentukan mengapa
proyek dibutuhkan atau tidak, lihat di mana uang itu berada dihabiskan, memprioritaskan proyek,
memulai tahap proyek baru, menyebarkan sumber daya secara tepat, dan kemudian mengawasi
kemajuan.

PPM membangun jalur dari konsep melalui penyelesaian proyek yang berhasil. Tanpa
data yang diperlukan, manajemen tidak dapat membuat informasi keputusan untuk menyetujui
proyek baru "benar" dan untuk menutup proyek tanpa berharap untuk sukses:

• Memetakan proyek yang diusulkan ke strategi organisasi

• Menilai nilai proyek yang diusulkan kepada perusahaan

• Menilai kompleksitas proyek yang diusulkan

• Prioritaskan proposal proyek untuk pemilihan proyek

Sektor jasa keuangan telah dipaksa oleh pedoman anti-moneylaundering (AML)

internasional yang ketat yang mengharuskan perusahaan untuk mengetahui pelanggan Anda
(KYC). Manajemen data master (MDM, Bab 3) diperlukan untuk membuat tampilan tunggal
pelanggan dan analisis AML / KYC diperlukan bagi bank untuk mengelola kenaikan biaya
kepatuhan dan risiko ketidakpatuhan. Untuk secara efektif memotivasi perusahaan untuk
berinvestasi dalam pertahanan yang diperlukan, regulator memberlakukan sanksi keras ketika
mereka mengidentifikasi kegagalan dalam sistem kepatuhan AML / KYC perusahaan. Beberapa
sanksi penting adalah: a Denda $ 1,9 miliar untuk HSBC pada 2012, penyelesaian $ 160 juta
Wachovia pada 2010, dan penyelesaian $ 327 juta dari Standard Chartered pada 2012 (Gupta &
Jain, 2014). Tidak mengherankan bahwa anggaran kepatuhan AML dan KYC telah meningkat
secara signifikan selama beberapa tahun terakhir dan mendapatkan peringkat prioritas. Namun
kepatuhan proyek mungkin selaras dengan proyek intens data lainnya.

7
 Misalnya, undang-undang AML mewajibkan bank untuk menunjukkan pengetahuan di
mana pelanggan mereka hidup, apa bentuk identifikasi yang mereka gunakan untuk memvalidasi
identitas mereka, rekonsiliasi demografi mereka di seluruh produk, validasi bahwa mereka tidak
ada daftar pengawasan pemerintah, dan pemahaman tentang perilaku transaksi normal mereka
untuk mendeteksi aktivitas mencurigakan. Karena banyak dari data ini juga digunakan untuk
pemasaran dan analisis risiko kredit, menjaga data dalam repositori bersama masuk akal dari
perspektif bisnis dan TI tentang biaya, konsistensi, dan akurasi.

Proyek adalah serangkaian tugas untuk menghasilkan satu atau hasil yang lebih . Hasil
kerja adalah item yang Anda serahkan kepada klien atau manajemen untuk ditinjau dan disetujui
dan itu harus diproduksi untuk menyelesaikan proyek atau bagian dari proyek. Proyek sudah
tanggal mulai dan tanggal selesai yang ditentukan yang menentukan durasi proyek, ruang
lingkup, sumber daya, dan anggaran. Proyek berbeda dari operasi atau bisnis seperti biasa
karakteristik yang tercantum dalam Tabel 2.1.

Tabel 2.1

Membedakan Karakteristik Proyek

Sebuah proyek memiliki karakteristik ini.
• Lingkup, kiriman, dan hasil yang didefinisikan dengan jelas
• Perkiraan kerangka waktu atau jadwal yang tunduk pada tingkat tinggi
ketidakpastian
• Perkiraan anggaran dengan tingkat ketidakpastian yang tinggi
• Persyaratan interaksi yang luas di antara peserta
• Tugas yang dapat bersaing atau bertentangan dengan kegiatan bisnis
lainnya, yang
membuat perencanaan dan penjadwalan menjadi sulit
• Berisiko tetapi dengan potensi atau manfaat laba tinggi

Tiga Kendala

Triple constraint mengacu pada tiga atribut yang harus dikelola secara efektif untuk
penyelesaian dan penutupan proyek yang berhasil:

8
1. Lingkup (Scoop): Lingkup proyek adalah definisi dari apa yang seharusnya proyek mencapai —
hasil atau hasil-hasilnya. Lingkup diukur dari segi ukuran proyek, sasaran, dan persyaratan.

2. Waktu: Sebuah proyek terdiri dari tugas-tugas. Setiap tugas memiliki tanggal mulai dan tanggal
akhir. Durasi proyek meluas dari tanggal mulai tugas pertama ke akhir tanggal tugas terakhir. Waktu
yang dibutuhkan untuk menghasilkan barang yang disampaikan secara alami terkait dengan ruang
lingkup dan ketersediaan sumber daya yang dialokasikan untuk proyek.

3. Biaya: Ini adalah perkiraan jumlah uang yang akan dibutuhkan untuk menyelesaikan proyek.
Biaya itu sendiri meliputi berbagai hal, seperti sumber daya, tenaga kerja tarif untuk kontraktor,
perkiraan risiko, dan tagihan bahan, dan lain-lain. Semua aspek dari proyek yang memiliki komponen
moneter menjadi bagian dari keseluruhan biayastruktur. Proyek disetujui dengan biaya mereka.

Kendala ini saling terkait sehingga harus dikelola bersama untuk proyek akan selesai tepat
waktu, sesuai anggaran, dan spesifikasi. Jurusan mengambil dari batasan tiga direpresentasikan
sebagai segitiga adalah bahwa Anda tidak bisa ubah satu sisi tanpa mengubah sisi lainnya.
Mengabaikan dampak potensial dari penyesuaian pada ruang lingkup, waktu, atau biaya proyek akan
menyebabkan masalah dan dapat menyebabkan proyek gagal.

Scope Creep

Selama proyek, hampir dipastikan akan terjadi permintaan untuk mengubah lingkup
(scoope). Perubahan atas lingkup (Scope creep) mengacu pada pertumbuhan proyek, yang mungkin
tampak tidak penting setidaknya bagi orang yang meminta perubahan itu. Scope creep adalah
penumpukan perubahan kecil yang dengan sendirinya dapat dikelola tetapi secara agregat adalah
signifikan. Sangat penting bahwa setiap perubahan pada ruang lingkup proyek secara eksplisit
termasuk mengkompensasi perubahan dalam anggaran, tenggat waktu, dan / atau sumber daya.
Pertimbangkan skenario ini. Lingkup proyek adalah untuk membangun online baru aplikasi akuntansi
yang mampu memproses setidaknya seribu laporan pengeluaran (dalam banyak mata uang) per hari,
yang memiliki anggaran $ 200.000, dan diharapkan tiga bulan terakhir. Setelah proyek dimulai, ruang
lingkup diperluas untuk mencakup pemrosesan ribuan komisi penjualan per hari. Manajer proyek
perlu negosiasi ulang durasi dan anggaran proyek untuk fungsionalitas tambahan, pengujian, dan
pelatihan pengguna, memastikan bahwa setiap perubahan yang diminta, tidak peduli seberapa kecil,
adalah didokumentasikan dan disertai dengan persetujuan.

9
 Pendekatan standar untuk mengelola proyek memberikan manfaat berikut:

• Menetapkan aturan dasar dan harapan untuk tim proyek.

• Memungkinkan manajer proyek, manajer fungsional, dan staf operasional memiliki satu
pemahaman yang memudahkan komunikasi dan membantu memastikan semua orang ada di
halaman yang sama.

• Manajer dapat dengan cepat menentukan mana yang berjalan dengan lancar dan yang tidak
ketika semua proyek mengikuti proses dan pendekatan yang sama dan menggunakan metrik
yang sama untuk mengukur kinerja proyek

Tidak menggunakan praktik terbaik, pendekatan manajemen proyek adalah TI terbesar

memproyeksikan kesalahan yang dapat dilakukan bisnis. Catatan Teknologi 13.1 memberikan
saran yang bagus tentang topik ini. Manajemen proyek membantu menjaga proyek sesuai jadwal
dan sesuai anggaran. SEBUAH rencana manajemen proyek yang baik mengidentifikasi biaya yang
diantisipasi sejak dini untuk mengembangkan a anggaran realistis. Menggunakan solusi konflik
sumber daya, manajer proyek dapat meminimalkan efek dari pendanaan proyek baru pada modal
operasi dengan mengoptimalkan alokasi pekerja. Mengkoordinasikan tugas dan secara jelas
mengidentifikasi tujuan atau hasil dalam fase mengurangi inefisiensi dalam manajemen waktu
yang dapat berakibat anggaran yang berlebihan.

2.3 Perencanaan, Eksekusi, dan Anggaran Proyek

Kemajuan atas dokumen penting dan keputusan utama siklus manajemen proyek diuraikan
pada Gambar 2.2 Proyek dimulai dengan ide yang dijelaskan dalam kasus bisnis. Jika kasus bisnis
diterima, pernyataan kerja/ Statement of Work (SOW) disiapkan. SOW ditulis sebagai
pernyataan definitif, yang berarti bahwa ia mendefinisikan rencana proyek tetapi tidak
menawarkan opsi atau alternatif dalam ruang lingkup. Rencana proyek dalam SOW ditinjau;
keputusan go atau no-go dibuat; jika keputusan go dibuat, proyek dimulai.

10
Gambar 2.2 Tahapan manajemen proyek dan kegiatan

Kasus & SOW

Tinjauan rencana
proyek
menggunakan
PPM; lanjutkan /

Proyek inisiasi &

Perencanaan
manajemen risiko

Eksekusi
proyek,pelacakan
& kontrol

penutupan
proyek& hasil yang
didapat

Kasus Bisnis

Manajer proyek, eksekutif senior, atau sponsor menyiapkan kasus bisnis yang meyakinkan untuk
dipertimbangkan. Berikut adalah contoh komponen kasus bisnis.

Template Kasus Bisnis

Pernyataan Tinjauan Proyek

Nama Proyek :

Departemen :

Tanggal :

Penulis :

Manajer Proyek :

Sponsor Eksekutif :

Jelaskan fakta terkait proyek dengan cara yang jelas dan ringkas

11
KASUS BISNIS PROYEK

Tinjauan Proyek
Jelaskan apa yang terlibat dalam melaksanakan proyek.

Masalah / Peluang Bisnis

Identifikasi dengan jelas peluang, kebutuhan, atau masalah yang dihadapi perusahaan dan
mengapa proyek itu perlu. Diskusikan driver yang telah memicu proposal proyek dan
menghubungkannya dengan kebutuhan bisnis.

Tujuan Bisnis Proyek

Jelaskan manfaat yang diharapkan dan bagaimana proyek cocok dengan strategi bisnis perusahaan
dan berkontribusi terhadap sasaran dan sasarannya.

Tujuan Proyek Utama

Buat daftar dan jelaskan tujuan proyek.
1. Tujuan 1
2. Tujuan 2. . .
3. Tujuan n. . .

Manfaat Proyek dan Analisis Biaya-Manfaat

Jelaskan manfaat utama dari penerapan proyek ini.
1. Manfaat 1
2. Manfaat 2. . .
3. Manfaat n. . .
Berdasarkan biaya yang ditetapkan untuk setiap opsi, jelaskan bagaimana biaya tersebut ditimbang
dengan manfaatnya. Lakukan analisis biaya-manfaat untuk setiap opsi dengan mempertimbangkan
biaya, manfaat, dan risiko.

PENGIRIMAN PROYEK PRIMER

Tahapan 1
1. Hasil Kerja: Deskripsi barang yang dikirim
2. Hasil Kerja: Deskripsi barang yang dikirim
3.. . .

Tahapan 2
1. Hasil Kerja: Deskripsi barang yang dikirim
2. Hasil Kerja: Deskripsi barang yang dikirim
3.. . .

Tahapan n
1. Hasil Kerja: Deskripsi barang yang dikirim
2. Hasil Kerja: Deskripsi barang yang dikirim
3.. . .

Interdependensi dan Input Proyek

Jelaskan proyek lain dalam proses atau yang direncanakan yang memiliki hubungan dengan proyek

12
yang diusulkan ini. Daftar input yang mungkin dimiliki proyek lain untuk pengembangan proyek ini.
• [memasukkan]
• [memasukkan]
• [memasukkan]

Asumsi dan Kendala Proyek

Buat daftar dan jelaskan semua asumsi teknis, lingkungan, dan ketersediaan sumber daya yang
mendasari proyek dan manfaat tersebut. Buat daftar dan jelaskan kendala yang dapat berasal dari
faktor eksternal atau internal.

Risiko Proyek
Jelaskan risiko yang diketahui yang berlaku untuk proyek ini.

INDIKATOR KINERJA UTAMA PROYEK

Faktor Penentu Kesuksesan Proyek atau KPI

a) Melanjutkan reformasi strategis kelembagaan dan peraturan perundang – undangan pada sektor dan lintas sektor yang
mendorong pe-laksanaan KPS,

b) Mempersiapkan proyek KPS secara matang se-hingga dapat menekan biaya transaksi yang ti-dak perlu, dan

c) Menyediakan fasilitas-fasilitas untuk mendu-kung investasi dalam pembangunan dan pe-ngoperasian proyek KPS,
termasuk menyedia-kan dana pendukung didalam APBN.

Sedangkan strategi yang akan ditempuh oleh pemerintah adalah sebagai berikut :

(a) Membentuk jejaring dan meningkatkan kapa-sitas untuk mendorong perencanaan dan per-siapan proyek KPS,
melakukan promosi KPS, peningkatan kapasitas dalam pengembangan, dan memantau pelaksanaan KPS;

(b) Membentuk fasilitas-fasilitas yang mendorong pelaksanaan proyek KPS, seperti : fasilitasi da-lam penyediaan tanah dan
pendanaan seperti Infrastructure funds dan guarantee funds;

(c) Mendorong terbentuknya regulator ekonomi sektoral yang adil dalam mewakili kepenti-ngan pemerintah, badan usaha,
dan konsu-men;

(d) Memfasilitasi penyelesaian sengketa pelaksa-naan proyek KPS secara efisien dan mengikat

(e) Mempersiapkan proyek KPS yang akan dita-warkan secara matang melalui proses perenca-naan yang transparan dan
akuntabel;

(f) Memberi jaminan adanya sistem seleksi dan kompetisi yang adil, transparan, dan akunta-bel;

(g) Meningkatkan pelayanan sarana dan prasa-rana daerah melalui peningkatan pengeluaran pemerintah daerah yang
didukung oleh ke-rangka insentif yang lebih baik.
Daftar dan jelaskan KPI atau faktor penentu kesuksesan yang berlaku untuk proyek ini.

13
ESTIMASI DAN PENGIRIMAN SELAMA PROYEK

Tanggal Perkiraan Tanggal Tingkat Proyek

Tanggal Mulai Proyek [Tinggi sedang Rendah]

Tahapan 1 [Tinggi sedang Rendah]

Tahapan 2 [Tinggi sedang Rendah]

Tahapan n [Tinggi sedang Rendah]

Tanggal Penyelesaian Proyek [Tinggi sedang Rendah]

PERSETUJUAN
Disiapkan oleh

Manajer Proyek

Disetujui oleh

Sponsor Proyek

Sponsor Eksekutif

Sponsor Klien

Laporan Pekerjaan

Garis besar SOW ditunjukkan pada Tabel berikut. SOW adalah kontrak hukum yang digunakan untuk
mendokumentasikan perjanjian antara para pihak setelah persyaratan bisnis diterima dan keputusan
yg dibuat. Keputusan iya / tidak adalah keputusan formal yang dibuat oleh manajer proyek, sponsor,
dan eksekutif serta pemangku kepentingan yang tepat.

14
 Template untuk Laporan Pekerjaan

Tanggal [Masukan tanggal]

Klien [Masukkan nama klien]

Nama Pekerjaan [Masukkan nama proyek]

Diminta oleh [Masukkan nama sponsor klien]

Dari [Masukkan nama manajer proyek]

Ringkasan dan Tujuan Deskripsi proyek tingkat tinggi dan tujuan

Lingkup Proyek Deskripsi ruang lingkup proyek, hasil, dan proses bagaimana hal itu
akandilakukan

Jadwal dan Daftar Berisi urutan sumber daya yang dialokasikan untuk setiap tugas, dan jadwal
Pekerjaan tugas Struktur
Perincian (WBS)

Biaya atau Harga Deskripsi biaya (harga) untuk semua jenis sumber daya — biaya tenaga
kerja, bahan, peralatan, biaya overhead; diskusi tentang ketentuan
pembayaran, termasuk jadwal pembayaran dan jika pembayaran
didasarkan pada tonggak sejarah / pengiriman atau jadwal, jika sesuai

Asumsi-asumsi Utama Bagian penting dari SOW — setiap asumsi yang dibuat ketika melakukan
pelingkupan dan memperkirakan proyek perlu didokumentasikan

Penerimaan Klien yang disebutkan di bawah memverifikasi bahwa persyaratan

pernyataan kerja ini dapat diterima. Para pihak dalam Perjanjian ini masing-
masing bertindak dengan wewenang yang sesuai dari masing-masing
perusahaan.

Nama perusahaan Nama perusahaan

Nama lengkap Nama lengkap

Judul Judul

Tanda tangan Tanda tangan

Tanggal Tanggal

15
STRUKTUR RINCIAN KERJA Setelah tujuan dan ruang lingkup proyek telah ditetapkan, langkah
selanjutnya adalah mengidentifikasi semua pekerjaan atau kegiatan
yang perlu dilakukan, jadwal pekerjaan, dan siapa yang akan melakukan
pekerjaan itu. Ini dilakukan dengan membuat struktur rincian kerja
(WBS) seperti yang ditunjukkan pada Gambar 13.5. Gambar 13.6
menunjukkan tangkapan layar WBS (sisi kiri) yang dikembangkan
menggunakan Microsoft Project. Sumber daya proyek dikelola menurut
WBS.

Tahapan Proyek

Tahapan digunakan untuk WBS memecah proyek menjadi tugas atau kegiatan yang harus
mengelola upaya kerja dilakukan, dan dalam urutan apa, untuk menghasilkan hasil pada setiap
proyek, memantau hasil, tonggak sejarah. Tahapan proyek adalah perangkat penjadwalan dan
dan melaporkan status status yang sangat penting karena memungkinkan manajer proyek
yang bermakna kepada untuk mengukur kemajuan seiring proyek berlangsung melalui siklus
pemangku kepentingan hidup yang direncanakan. Kurangnya tahapan proyek telah menjadi
proyek faktor penyebab banyak kegagalan proyek. Setiap tahapan biasanya
mewakili hasil pengiriman (100 persen selesai), tetapi juga menandakan
persen selesai, seperti 50 persen selesai.

Contoh Tahapan Proyek

Pendanaan orang banyak Asumsikan Anda adalah manajer proyek untuk klien yang ingin
adalah mengumpulkan memposting proyek kreatif di Kickstarter.com untuk mengumpulkan
dana untuk proyek dari dana menggunakan crowdfunding. Anda mengunjungi Kickstarter.com
publik, atau orang banyak, dan melakukan analisis persyaratan. Anda menentukan bahwa Anda
melalui Web. perlu menghasilkan lima hasil: (1) video, (2) satu set foto dan ilustrasi,
(3) naskah yang menjelaskan mengapa proyek kreatif layak
mendapatkan dana, (4) satu set kategori janji dan hadiah kepada
pendukung, dan (5) situs terakhir dengan semua hasil yang diunggah ke
Kickstarter.com dan diuji.

16
 1.0 Mobile Commerce Site

1.1 Perencanaan 1.2 Implementasi 1.3 Pemantauan 1.4 Penempatan

dan Kontrol

1.1.1 Syarat-syarat 1.2.1 1.3.1 Melakukan

Mengembangkan Manajemen Risiko 1.4.1 Melakukan
Arsitektur Penempatan

1.1.2 Opsi 1.2.3 Melakukan

Penelitian 1.2.3
Jaminan Kualitas/QA
Mengembangkan
Situs

1.1.3 Desain 1.2.3 Melakukan isu-isu

manajemen/Masalah
Pengguna Situs 1.2.2.1 dalam manajemen
Mengembangkan
Basis Data Produk

1.2.2.2
Mengembangkan
Situs Web

1.2.2.3 Uji coba Situs

Salah satu segmen dari WBS

untuk proyek situs mobile commerce/telepon seluler

17
Gambar layar Microsoft Project untuk WBS (sisi kiri) dan Gantt chart (sisi kanan).

Setiap hasil merupakan Tahapan Proyek dalam rencana proyek kemudian mengandalkan
jadwal tahapan untuk memverifikasi bahwa proyek berada di jalurnya atau untuk memperingatkan
perlunya tindakan korektif. Tahapan proyek harus alami, titik kontrol penting dalam proyek dan
mudah bagi semua orang.

Estimasi Biaya

Meskipun biaya bukan bagian dari WBS, perkiraan biaya proyek dapat dihitung dari WBS.
Setiap tugas atau aktivitas memiliki tanggal dan durasi mulai, yang menentukan tanggal selesainya.
Misalnya, jika tugas dimulai pada hari Senin, 2 November, dan membutuhkan delapan hari kerja
(tidak termasuk hari akhir pekan) untuk diselesaikan, tanggal selesai adalah Rabu, 11 November.
Asumsikan sumber daya — manusia, peralatan, dan bahan — yang dibutuhkan untuk menyelesaikan
tugas dan biayanya diketahui. Perangkat lunak manajemen proyek mengkompensasi biaya proyek
berdasarkan waktu kerja (durasi) dari setiap tugas dalam WBS dan biaya tenaga kerja atau sumber
daya lainnya.

18
 Matrix Pertanggungjawaban

Matriks Matrix Pertanggungjawaban menunjukkan siapa yang memiliki tanggung

Pertanggungjawab jawab utama dan siapa yang memiliki tanggung jawab dukungan untuk
membuat semua orang kegiatan yang tercantum dalam WBS. Tabel 13.3 adalah contoh dari
tahu siapa yang matriks Pertanggungjawaban.
bertanggung jawab atas
penyelesaian tugas.

Gantt Chart

Gantt chart adalah Gantt chart adalah diagram batang yang menunjukkan garis waktu dari
diagram batang jadwal proyek, seperti yang ditunjukkan di sebelah kanan Gambar 13.6.
horizontal yang secara Pada bagan Gantt, tanggal mulai dan selesai semua tugas dan tonggak
grafik menampilkan muncul sebagai bilah yang panjangnya mewakili durasinya. Gantt chart
jadwal proyek. adalah alat visualisasi multiguna yang digunakan untuk perencanaan,
penjadwalan, dan laporan status sekilas.

TABEL Format Sampel untuk Matriks Pertanggungjawaban yang Menunjukkan Siapa

Memiliki Tanggung Jawab Utama dan Dukungan untuk Tugas WBS

ID WBS Aktivitas Anna Bart Beth Chas Don

1.1 Video Storyboard P

S

1.2 Rekrut sukarelawan untuk membuat video S P

1.3 Rekam segmen video P S

2.1 Pilih lima foto dan gambar P S

2.2 Pangkas dan edit foto S P

P tanggung jawab utama, S mendukung tanggung jawab

19
 Projek Baseline

Baseline adalah
spesifikasi dari rencana
proyek yang telah ditinjau
dan disepakati secara
formal. Itu harus diubah
hanya melalui proses
kontrol perubahan formal
Ketika rencana proyek diselesaikan dan diterima, rencana yang diterima
menjadi garis dasar, atau rencana induk. Baseline digunakan untuk
memonitor dan mengendalikan. Setiap perubahan pada baseline adalah
penyimpangan, atau varian, dari rencana — dan itu perlu
didokumentasikan. Menggunakan perangkat lunak manajemen proyek,
Anda dapat menyimpan WBS sebagai baseline. Sejak saat itu,
penyimpangan akan secara otomatis didokumentasikan sebagai varian
dari baseline, seperti yang ditunjukkan pada Gambar 13.7

Kerja

Dijadwalkan : 680 jam Tersisa : 581.2 jam

Baseline : 528 jam Aktual : 98,8 jam

Varians : 152 jam Persen selesai : 15%

Biaya

Dijadwalkan : $ 14,104.00 Aktual: $ 2,352.40

Baseline : $ 11,751.60 Varians: $ 3,480.00

Varians : $ 10,624.00

Status Tugas Status sumber daya

Tugas belum dimulai : 7 Sumber daya kerja : 4

Tugas yang sedang berjalan : 9 Sumber daya kerja yang ditempatkan secara keseluruhan : 4

Tugas selesai : 0 Sumber materi : 0

Total tugas : 16 Total sumber daya : 8

Gambar 13.7 Varians pekerjaan dan biaya dari baseline proyek yang disepakati didokumentasikan oleh perangkat lunak manajemen
proyek.

20
2.4 Pemantauan, Kontrol, dan Penutupan Proyek

Proses pemantauan dan kontrol dimaksudkan untuk terjadi secara terus menerus selama
proses pekerjaan proyek sedang dilaksanakan. Proses-proses ini, dijelaskan pada Gambar 2.4,
tergantung pada baseline, tonggak sejarah, matriks tanggung jawab, dan elemen-elemen lain dari
tahap perencanaan. Mereka terus memberi tahu tim proyek tentang status proyek dan membantu
mereka mengatasi tantangan yang mereka hadapi. Kecuali untuk proyek pendek dan sederhana,
akan menjadi risiko dan perubahan yang perlu dikendalikan dan didokumentasikan.

Gambar 2.4 Kontrol proyek.

Lingkup Pengendalian
Mengelola dan bernegosiasi
perubahan respons ke ruang lingkup .
Kontrol Lingkup Merekomendasikan
tindakan korektif.

Pengendalian biaya Quality Control

Mengelola faktor yang bisa
menyebabkan perubahan
pada biaya baseline
Kontrol Jadwal
Proyek pemantauan kiriman
Mengelola faktor yang bisa
untuk memverifikasi standar
menyebabkan penundaan
kualitas dan spesifikasinya tidak
waktu atau perubahan jadwal
dikompromikan

Pemantauan tergantung pada umpan balik yang cepat dan jujur dari tim proyek, seperti
Anda baca di case pembuka. Kunjungan langsung, laporan, dan catatan juga merupakan metode
pemantauan. Kontrol proyek tergantung pada sistem dan aturan keputusan untuk mengelola
perbedaan antara ruang lingkup proyek, biaya, jadwal, dan kualitas dan kenyataan implementasi
proyek.

2.4.1 Perubahan Kontrol Terpadu

Perubahan cenderung memiliki efek trickle down karena dependensi tugas dan dibagikan
menjadi sumber daya. Sebagai contoh, perhatikan tiga kegiatan berikut:
1.1 Storyboard sebuah video.
1.2 Rekrut sukarelawan untuk berakting di video.
1.3 Merekam segmen video.

21
Kegiatan 1.3 tergantung pada penyelesaian kegiatan 1.1 dan 1.2. Rekaman video tidak dapat dimulai
sampai setelah video telah storyboard dan aktor tersedia.

Proses kontrol perubahan terpadu membantu mengelola gangguan yang dihasilkan dari
perubahan yang diminta dan tindakan korektif di seluruh siklus hidup proyek. Proses kontrol
perubahan terintegrasi selalu didokumentasikan dan disimpan dalam acara tersebut, kegagalan
proyek atau tuntutan hukum terkait dengan kegagalan tersebut. Dokumen-dokumen ini diperlukan
untuk membela keputusan — apa yang terjadi dan tidak terjadi, seperti:
• Permintaan perubahan yang disetujui
• Menolak permintaan perubahan
• Pembaruan pada rencana proyek
• Pembaruan untuk ruang lingkup
• Tindakan korektif dan preventif yang disetujui
• Perbaikan cacat yang disetujui
• Perbaikan cacat yang divalidasi

JALUR KRITIS
Semua proyek memiliki jalur kritis yang memperpanjang panjang proyek. Perangkat lunak
manajemen proyek menunjukkan jalur kritis pada Gantt chart. Setiap tugas atau aktivitas di jalur
kritis disebut tugas atau aktivitas kritis. Tugas kritis harus selesai sesuai jadwal karena penundaan
akan menunda proyek kecuali ada sesuatu yang dilakukan mengimbangi. Walaupun mungkin tampak
bahwa menambahkan orang baru ke proyek adalah solusi yang jelas, pada kenyataannya, mungkin
pada awalnya memperlambatnya. Jika ada tugas tidak kritis yang cukup tertunda, mereka bisa
menjadi kritis, sehingga jalur kritis dan nonkritis perlu dipantau.

2.4.2 When To Kill A Project That Is Out Of Control

Kontrol proyek juga digunakan untuk mengidentifikasi kapan menyatakan proyek yang
sedang berjalan sebagai suatu kegagalan dan bunuh itu. Berikut ini adalah skenario umum:
Proyek ini terlambat. Lingkupnya berubah hampir setiap hari. Ada juga beberapa tonggak yang
diidentifikasi selama tahap perencanaan untuk dapat memantau kemajuan. Sumber daya
dialokasikan secara keseluruhan. Karena kurangnya jadwal yang teratur rapat, manajer proyek tidak
memiliki informasi tentang apa yang anggota tim sedang mengerjakan pada waktu tertentu. Anggota
tim tidak berkomunikasi karena mereka tahu bahwa proyek itu sedang sekarat dan takut untuk
mengatakannya. Banyak orang di perusahaan juga tahu bahwa proyek ini dalam masalah, kecuali
untuk manajemen senior.

22
Jalur kritis adalah jalur tugas yang terpanjang melalui sebuah proyek, seperti yang ditunjukkan pada
Gantt grafik. Penundaan tugas apa pun pada jalur kritis akan menunda proyek.

Gambar 13.9 Jalur kritis ditampilkan sebagai bilah merah. Jalur kritis terdiri dari tugas-tugas mulai
dari proyek hingga akhir yang harus diselesaikan tepat waktu agar proyek selesai tepat waktu.

Terkadang, satu-satunya cara yang tepat untuk memperbaiki suatu proyek adalah dengan
membatalkannya. Jika suatu proyek menderita dari satu atau lebih kondisi yang tercantum dalam
skenario, itu telah mencapai titik di mana kelayakannya harus diperiksa ulang secara kritis. Sangat
sulit untuk membunuh proyek apa pun ketika jutaan dolar telah dihabiskan sampai saat ini —
bahkan ketika itu jelas benar keputusan. IT at Work 13.1 menjelaskan kasus dunia nyata.
Uang yang sudah dikeluarkan untuk proyek, atau biaya hangus, tidak boleh dipertimbangkan
dalam keputusan. Satu-satunya biaya yang relevan, dari sudut pandang keuangan, adalah apakah
nilai total dari melanjutkan lebih besar dari total biaya melakukannya
2.4.3 Penutupan Proyek Dan Postmortem
Menutup suatu proyek tidak menguntungkan proyek yang telah selesai (yang merupakan yang
pertama kali terjadi) memotong ketika biaya dibanjiri); melainkan menguntungkan perusahaan dan
orang-orang yang bekerja pada proyek. Mereka mendapatkan pemahaman yang lebih baik tentang
apa yang berhasil dan tidak berhasil. Ini pelajaran yang dipetik memandu proyek-proyek masa
depan.
Ulasan pasca proyek, atau postmortem, mengidentifikasi alasan proyek berhasil atau tidak, kekuatan
dan kelemahan rencana proyek, bagaimana masalah terdeteksi dan diselesaikan, dan bagaimana
proyek itu berhasil terlepas dari mereka.

23
2.5 System Development Life Cycle (SDLC)

Siklus hidup pengembangan sistem (SDLC) adalah metode pengembangan sistem tradisional
untuk proyek TI besar, seperti infrastruktur TI atau sistem perusahaan. SDLC adalah kerangka kerja
terstruktur yang terdiri dari serangkaian proses berurutan, seperti yang ditunjukkan pada Gambar
berikut:

Dimulai dengan ide awal, proses SDLC adalah analisis kebutuhan, analisis dan desain sistem,
pengembangan dan pengujian, implementasi, dan pemeliharaan. Setiap proses terdiri dari tugas-
tugas yang didefinisikan dengan baik yang bergantung pada ruang lingkup proyek. Prosesnya
berulang, yang artinya direvisi ketika ada informasi atau kondisi baru yang membuat revisi menjadi
hal yang cerdas untuk dilakukan. Proses berulang (Iterasi) tidak berarti bahwa pengembangan sistem
harus tunduk pada revisi tak terbatas atau ruang scope creep.

Desain IS sangat rentan terhadap scope creep karena berbagai alasan. Pengguna yang dituju
meminta fitur tambahan. Orang yang bukan pengguna yang dituju meminta untuk dimasukkan.
Teknologi berubah sejak saat kasus bisnis ditulis dan pengembangan sistem dimulai. Tindakan
pesaing, pemasok, atau badan regulator memicu permintaan tambahan untuk fungsionalitas. Karena
scope creep mahal, manajer proyek memaksakan kontrol pada perubahan yang diminta oleh
pengguna. Kontrol-kontrol ini membantu mencegah proyek yang tidak terkendali — proyek
pengembangan sistem yang jauh melebihi anggaran dan batas waktu yang lalu sehingga harus
ditinggalkan, biasanya dengan kerugian moneter yang besar.

Secara umum, metodologi SDLC mengikuti langkah-langkah berikut.

1. Analisa Kebutuhan
Kekurangan dalam sistem yang sudah ada diidentifikasi dan digunakan untuk menentukan
kebutuhan fungsional dan data dari sistem baru. Analisis kebutuhan sangat penting untuk
keberhasilan proyek. Praktisi pengembangan sistem setuju bahwa semakin banyak waktu yang

24
 diinvestasikan dalam menganalisis sistem saat ini, masalah bisnis, atau peluang dan memahami
masalah yang cenderung terjadi selama pengembangan, semakin besar probabilitas bahwa IS
akan berhasil.

2. Analisis Sistem dan Studi Kelayakan

Sistem yang diusulkan dirancang. Rencana disusun mengenai konstruksi fisik, perangkat keras,
perangkat lunak, media, dasbor, sistem operasi, pemrograman, konektivitas, dan masalah
keamanan. Kelayakan desain diuji. Studi kelayakan menentukan probabilitas keberhasilan
proyek yang diusulkan dan memberikan penilaian kasar terhadap kelayakan teknis, ekonomi,
organisasi, dan perilaku proyek. Studi kelayakan sangat penting untuk proses pengembangan
sistem karena jika dilakukan dengan benar, studi ini dapat mencegah perusahaan membuat
kesalahan mahal, seperti membuat sistem yang tidak akan berfungsi, yang tidak akan bekerja
secara efisien, atau bahwa orang tidak dapat atau tidak akan menggunakan. Kasus Biro Sensus
dalam IT kasus pembuka adalah contohnya. Berbagai analisis kelayakan juga memberikan para
pemangku kepentingan kesempatan untuk memutuskan metrik apa yang akan digunakan untuk
mengukur bagaimana sistem yang diusulkan memenuhi tujuan mereka. Analisis kelayakan
tersebut antara lain:

 Kelayakan teknis. Kelayakan teknis menentukan apakah teknologi yang dibutuhkan,

infrastruktur TI, struktur data, analitik, dan sumber daya dapat dikembangkan dan / atau
diperoleh untuk menyelesaikan masalah bisnis. Kelayakan teknis juga menentukan apakah
teknologi yang ada di organisasi dapat digunakan untuk mencapai tujuan kinerja proyek.

 Kelayakan ekonomi. Kelayakan ekonomi menentukan apakah proyek tersebut merupakan

risiko keuangan yang dapat diterima dan apakah perusahaan mampu membayar biaya dan
waktu yang dibutuhkan untuk menyelesaikan proyek. Kelayakan ekonomi menjawab dua
pertanyaan utama: Apakah manfaatnya lebih besar daripada biaya proyek? Bisakah proyek
diselesaikan sesuai jadwal?
Manajemen dapat menilai kelayakan ekonomi dengan menggunakan analisis biaya-manfaat
dan teknik keuangan seperti nilai waktu uang, laba atas investasi (ROI), nilai sekarang bersih
(NPV), dan analisis titik impas. Pengembalian investasi adalah rasio dari laba bersih yang
diatribusikan ke proyek dibagi dengan rata-rata biaya sumber daya yang diinvestasikan
dalam proyek. NPV adalah jumlah bersih dimana manfaat proyek melebihi biaya proyek,
setelah memungkinkan untuk biaya modal dan nilai waktu dari uang. Analisis Breakeven

25
 menghitung titik di mana arus kas kumulatif dari suatu proyek sama dengan investasi yang
dibuat dalam proyek tersebut.
Menghitung kelayakan ekonomi dalam proyek-proyek TI tidak mudah. Bagian dari
kesulitannya adalah bahwa beberapa manfaat tidak berwujud. Untuk sistem yang diusulkan
yang melibatkan data besar, analitik waktu nyata, atau pencetakan 3D, mungkin tidak ada
bukti sebelumnya tentang jenis pengembalian keuangan yang dapat diharapkan.
 Kelayakan hukum dan organisasi. Apakah ada alasan hukum, peraturan, atau lingkungan
mengapa proyek tidak dapat atau tidak boleh dilaksanakan? Analisis ini melihat kebijakan
dan politik perusahaan, termasuk dampak pada distribusi daya dan hubungan bisnis.
 Kelayakan perilaku. Kelayakan perilaku mempertimbangkan masalah manusia. Semua
proyek pengembangan sistem memperkenalkan perubahan, dan orang-orang umumnya
menolak perubahan. Resistansi berlebihan dari karyawan dapat berupa sabotase sistem
baru (mis., Memasukkan data secara tidak benar) atau mengejek sistem baru kepada siapa
pun yang akan mendengarkan. Resistensi terselubung biasanya terjadi ketika karyawan
hanya melakukan pekerjaan mereka menggunakan metode lama mereka.
Kelayakan perilaku berkaitan dengan menilai keterampilan dan pelatihan yang diperlukan
untuk menggunakan IS baru. Di beberapa organisasi, sistem yang diusulkan mungkin
memerlukan keterampilan matematika atau linguistik di luar apa yang dimiliki oleh tenaga
kerja saat ini. Di negara lain, tenaga kerja mungkin hanya perlu meningkatkan keterampilan
mereka. Kelayakan perilaku adalah tentang “bisakah mereka menggunakannya” seperti
halnya “apakah mereka akan menggunakannya.”

Setelah analisis kelayakan, keputusan go / no-go tercapai. Sponsor proyek dan manajer
proyek menandatangani keputusan. Jika itu adalah keputusan “No-Go”, proyek diletakkan di
arsip sampai kondisinya lebih baik, atau proyek dibuang. Jika keputusan itu "Go," maka
proyek pengembangan sistem melanjutkan.

3. Pengembangan Dan Pengujian Sistem

Pengembang sistem menggunakan spesifikasi desain untuk memperoleh perangkat lunak
yang dibutuhkan sistem untuk memenuhi tujuan fungsionalnya dan menyelesaikan masalah
bisnis. Sumber, seperti dibahas pada Bab 12, dan pengkodean in-house adalah opsi.
Pengujian memverifikasi bahwa aplikasi, antarmuka, transfer data, dan sebagainya,
berfungsi dengan benar dalam semua kondisi yang memungkinkan. Pengujian membutuhkan
banyak waktu, upaya, dan biaya untuk melakukannya dengan benar. Namun, biaya dan

26
 konsekuensi dari pengujian yang tidak tepat, yang mungkin dapat mengarah pada sistem
yang tidak memenuhi tujuannya, sangat besar. Risiko tuntutan hukum yang mahal perlu
dipertimbangkan.
4. Implementasi
Implementasi, atau penyebaran, adalah proses konversi dari sistem lama ke sistem baru.
Empat strategi konversi adalah paralel, pemotongan langsung, uji coba, dan bertahap. Dalam
konversi paralel, sistem lama dan sistem baru beroperasi secara simultan untuk periode
waktu tertentu. Artinya, kedua sistem memproses data yang sama pada waktu yang sama,
dan hasilnya dibandingkan. Jenis konversi ini adalah yang paling mahal tetapi paling tidak
berisiko.
Dalam konversi langsung, sistem lama terputus dan sistem baru dihidupkan pada titik waktu
tertentu. Jenis konversi ini adalah yang paling murah, tetapi paling berisiko jika sistem baru
tidak berfungsi seperti yang direncanakan.
Konversi percontohan memperkenalkan sistem baru di satu lokasi untuk mengujinya. Setelah
sistem baru berfungsi dengan baik, itu diluncurkan.
Konversi bertahap memperkenalkan komponen sistem baru, seperti modul individu, secara
bertahap. Setiap modul dinilai, dan, ketika berfungsi dengan baik, modul lainnya
diperkenalkan hingga seluruh sistem baru beroperasi.
5. Pemeliharaan
Setelah operasi sistem baru distabilkan, audit dilakukan selama operasi untuk menilai
kemampuan sistem dan menentukan apakah itu digunakan dengan benar. Pemeliharaan
harus dijaga dengan ketat setiap saat. Pengguna sistem harus selalu terbarui tentang
modifikasi dan prosedur terbaru.

27
 BAB III

PENUTUP

Kesimpulan

Semakin berkembangnya teknologi informasi, semakin cangih dan kompleks proyek

yang dikerjakan dengan melibatkan pengguna sumberdaya dalam bentuk tenaga manusia,
material dan dana yang jumlahnya bertambah besar. Diiringi pula dengan semakin ketat
kompetisi penyelenggaraan proyek untuk memenuhi kebutuhan masyarakat sehingga
dibutuhkan cara pengelolaan, metoda serta teknik yang paling baik sehingga pengunaan sumber
daya benar-benar efektif dan efisien sehingga dibutuhkan manajemen proyek. Dengan kata lain
manajemen proyek tumbuh karena dorongan mencari pendekatan penggelolaan yang sesuai
dengan tuntutan dan sifat kegiatan proyek, suatu kegiatan yang dinamis dan berbeda dengan
kegiatan operasional rutin. Manajemen Proyek berbeda dengan manajemen klasik yang berhasil
menggelola kegiatan operasional. Hal ini karena beberapa prilaku proyek yang penuh dinamika
dan adanya perubahan cepat.

SDLC (Systems Development Life Cycle, Siklus Hidup Pengembangan Sistem) atau
Systems Life Cycle (Siklus Hidup Sistem), dalam rekayasa sistem dan rekayasa perangkat lunak,
adalah proses pembuatan dan pengubahan sistem serta model dan metodologi yang digunakan
untuk mengembangkan sistem-sistem tersebut.

Adapun kegunaan utama dari SDLC adalah mengakomodasi beberapa kebutuhan.

Kebutuhan-kebutuhan itu biasanya berasal dari kebutuhan pengguna akhir dan juga pengadaan
perbaikan sejumlah masalah yang terkait dengan pengembangan perangkat lunak. Kesemua itu
dirangkum pada proses SDLC yang dapat berupa penambahan fitur baru baik itu secara modular
maupun dengan proses instalasi baru. Dari proses SDLC juga berapa lama umur sebuah
perangkat lunak dapat diperkirakan untuk dipergunakan

28