Model Evaluasi Faktor Penyebab Kegagalan Proyek Sistem Informasi Untuk Perangkat Lunak Di Perusahaan

MODEL EVALUASI FAKTOR PENYEBAB KEGAGALAN PROYEK
SISTEM INFORMASI UNTUK PERANGKAT LUNAK DI PERUSAHAAN
Tesis
untuk memenuhi sebagian persyaratan
mencapai derajat Sarjana S-2
Program Studi Magister Manajemen
Diajukan oleh
SYAUGI H.S
12/341910/PEK/17617
Kepada
FAKULTAS EKONOMI DAN BISNIS
UNIVERSITAS GADJAH MADA
2014
Magister Manajemen
Universitas Gadjah Mada
MODEL EVALUASI FAKTOR PENYEBAB KEGAGALAN PROYEK
SISTEM INFORMASI UNTUK PERANGKAT LUNAK DI PERUSAHAAN
yang dipersiapkan dan disusun oleh

SYAUGI H.S
12/341910/PEK/17617
Telah dipertahankan di depan Dewan Penguji
pada tanggal ___________
dan dinyatakan telah lulus memenuhi syarat
Yogyakarta, _________
Dosen Penguji I Dosen Penguji II
…………………….. ……………………..
Dosen Penguji III/Pembimbing
Dr. Wahyu Sardjono, M.M
ii
PERNYATAAN
Dengan ini saya menyatakan bahwa dalam thesis ini tidak terdapat karya yang
pernah diajukan untuk memperoleh gelar kesarjanaan di suatu Perguruan Tinggi,
dan sepanjang pengetahuan saya juga tidak terdapat karya atau pendapat yang
pernah ditulis atau diterbitkan oleh orang lain, kecuali yang secara tertulis diacu
dalam naskah ini dan disebutkan dalam daftar pustaka.
Jakarta, 8 Desember 2014
Syaugi Hasan
iii
KATA PENGANTAR
iv
DAFTAR ISI
Lembar Judul ………………………………………………………………… i
Lembar Pengesahan ………………………………………………………….. ii
Lembar Pernyataan ….….….….….….….….….….….….….….….….….….. iii
Kata Pengantar ….….….….….….….….….….….….….….….….….….…... iv
Daftar Isi ….….….….….….….….….….….….….….….….….….….….…... v
Daftar Tabel ….….….….….….….….….….….….….….….….….….….…... ix
Daftar Gambar ….….….….….….….….….….….….….….….….….….…… x
Daftar Lampiran ….….….….….….….….….….….….…. …………………. xi
Daftar Singkatan .…………………………………………………………….. xii
Intisari ……...….….….….….….….….….….….….….….….….….….….…. xiii
Abstraks ….….….….….….….….….….….….….….….….….….….….…… xiv
BAB I. PENDAHULUAN .......................................................................................1
1.1. Latar Belakang Permasalahan ..................................................................... 1
1.2. Rumusan/identifikasi Masalah .................................................................... 5
1.3. Pertanyaan Penelitian .................................................................................. 7
1.4. Tujuan Penelitian ......................................................................................... 8
1.5. Manfaat Penelitian ....................................................................................... 8
1.6. Ruang Lingkup dan Batasan Penelitian ....................................................... 9
1.7. Sistematika Penulisan .................................................................................. 9
BAB II. LANDASAN TEORI ...............................................................................11
2.1. Tinjauan Pustaka/Landasan Teori ............................................................. 11
v
2.1.1. Teknologi dan Keunggulan Kompetitif (Competitive Advantage) .... 11
2.1.2. Bisnis dan Sistem Informasi .............................................................. 13
2.1.3. Project Management – Body Of Knowledge ..................................... 17
2.1.4. Konsep Dan Indikator ........................................................................ 20
2.1.4.1 Konsep Tata-kelola Komunikasi (Communication Management)
................................................................................................................. 29
2.1.4.2 Konsep Tata-kelola Biaya (Cost Management) .......................... 30
2.1.4.3 Konsep Tata-kelola Sumber Daya Manusia (Human Resource
Management) .......................................................................................... 31
2.1.4.4 Konsep Tata-kelola Integrasi (Integration Management)........... 32
2.1.4.5 Konsep Tata-kelola Pengadaan Barang (Procurement
Management) .......................................................................................... 34
2.1.4.6 Konsep Tata-kelola Kualitas (Quality Management) ................. 35
2.1.4.7 Konsep Tata-kelola Risiko (Risk Management) ......................... 35
2.1.4.8 Konsep Tata-kelola Cakupan (Scope Management) ................... 36
2.1.4.9 Konsep Tata-kelola Pemangku Kepentingan (Stakeholder
Management) .......................................................................................... 37
2.1.4.10 Konsep Tata-kelola waktu (Time Management) ....................... 39
2.1.5. Perangkat Lunak (Software) .............................................................. 40
2.1.6. Metodologi Pengembangan Perangkat Lunak ................................... 41
3.1 Jenis Penelitian ........................................................................................... 43
3.2 Lokasi dan Waktu Penelitian ...................................................................... 43
3.3 Sampel Penelitian ....................................................................................... 44
vi
3.4 Pengumpulan Data ..................................................................................... 44
3.5 Definisi Istilah/Operasional ........................................................................ 45
3.6 Aspek Pengukuran ...................................................................................... 46
3.7 Metode Analisis Data ................................................................................. 47
3.8 Analisis Kelengkapan Data ........................................................................ 49
3.9 Alur Diagram Penelitian ............................................................................. 49
BAB IV. HASIL PENELITIAN ............................................................................51
4.1 Gambaran Responden................................................................................. 51
4.1.1 Pengalaman Bekerja ........................................................................... 51
4.1.2 Pengalaman Tentang Masalah ............................................................ 53
4.1.3 Penilaian Tingkat Masalah ................................................................. 55
4.1.4 Statistik Deskriptif Variabel Penelitian .............................................. 56
4.2 Keterbatasan Penelitian ........................................................................... 60
4.3 Bahasan Tujuan Penelitian Pertama........................................................ 60
4.3.1 Uji Reliabilitas dan Validitas Data ..................................................... 60
4.3.2 Analisa Faktor ..................................................................................... 62
4.3.2.1 Faktor Kepemimpinan Non-Simpatik (absence of sympathetic
leadership) .............................................................................................. 63
4.3.2.2 Faktor Ketidak-pedulian akan Prinsip Keterbatasan Biaya (cost-
impact ignorance).................................................................................... 65
4.3.2.3 Faktor Risiko Laten (latent risks) Terabaikan ............................ 67
4.3.2.4 Faktor Toleransi Jadwal .............................................................. 68
4.3.2.5 Faktor Psikologi Kegagalan (Pessimistic To Achieve) .............. 69
vii
4.3.2.6 Faktor Komunikasi Tidak Efektif ............................................... 70
4.3 Bahasan Tujuan Penelitian Kedua .......................................................... 71
4.4 Analisis Isi Jawaban (Content Analysis) ................................................. 73
4.4.1 Ukuran Proyek Bermasalah (Gagal) ................................................... 73
4.4.2 Keputusan Manajemen atas Proyek Bermasalah (Gagal) ................... 75
4.4.3 Komentar Tambahan Umum .............................................................. 76
4.5 Implikasi Manajerial ............................................................................... 79
BAB V. KESIMPULAN DAN SARAN ...............................................................82
5.1 Kesimpulan ................................................................................................. 82
5.2 Saran ....................................................................................................... 82
DAFTAR PUSTAKA ............................................................................................83
viii
DAFTAR TABEL
Tabel 1.1: Kinerja Proyek selama 2004-2012…………………………………... 4
Tabel 2.1: Area Pengetahuan (Knowledge Area) ……………………………..... 18
Tabel 2.2: Konsep Dan Indikator ….……………………………....................... 20
Tabel 3.1: Definisi Operasional ………………………………………………… 37
Tabel 4.1: Statistik Deskriptif Variabel Penelitian ……………………………... 56
Tabel 4.2: Rekomendasi Ukuran KMO ………………………………………… 61
Tabel 4.3: Tahapan Analisis Komponen Utama ……………………………….. 62
Tabel 4.4: Variabel Faktor Pertama ……………………………………………. 63
Tabel 4.5: Variabel Faktor Kedua ……………………………………………… 65
Tabel 4.6: Variabel Faktor Ketiga ……………………………………………… 67
Tabel 4.7: Variabel Faktor Keempat …………………………………………… 68
Tabel 4.8: Variabel Faktor Kelima ……………………………………………. 69
Tabel 4.9: Variabel Faktor Keenam …………………………………………… 70
Tabel 4.10: Variabel Regresi Linear ………………………………………….. 71
Tabel 4.11: Simulasi Prediksi Model Regresi ………………………………… 72
Tabel 4.12: Respon Tentang Ukuran Kegagalan ………………………………. 74
Tabel 4.13: Respon Status Kelanjutan Proyek …………………………………. 75
Tabel 4.14: Analisis Komentar Tambahan ……………………………………... 76
ix
DAFTAR GAMBAR
Gambar 1.1: Kinerja Proyek selama 2004-2012 ……………………………….. 5
Gambar 2.1: Teknologi Informasi dalam Rantai Nilai ………………………… 12
Gambar 2.2: Process Perencanaan Sumber Daya IS …………………………… 14
Gambar 2.3: The Relationship Between Stakeholders and the Project ………… 38
Gambar 2.4: The Software Iceberg …………………………………………….. 40
Gambar 2.5: Fase dan Tahapan SDLC …………………………………………. 42
Gambar 3.1: Grafik Waktu Pengumpulan Data ………………………………... 45
Gambar 3.2: Alur Diagram Penelitian .……..………………………………... 50
Gambar 4.1: Lama Pengalaman Bekerja ….…..…………………………….. 51
Gambar 4.2: Latar Belakang Pengalaman ……..……………………………….. 52
Gambar 4.3: Pernah Mengalami Masalah ……..……………………………….. 53
Gambar 4.4: Persepsi Tingkat Masalah …..…………………………………….. 55
Gambar 4.5: Tipe Organisasi Responden……………………………………….. 56
Gambar 4.6: Grafik Histogram Total Variabel ………………………………….58
Gambar 4.7: Grafik Histogram Setiap Variabel …….………………………….. 59
Gambar 4.8: Prosentasi Respon Ukuran Kegagalan …………………………….74
Gambar 4.9: Prosentasi Respon Status Kelanjutan ...…………………………... 76
x
DAFTAR LAMPIRAN
Lampiran 1 ONLINE SURVEY ……………………………………... 87
Lampiran 2 STATISTIK DESKRIPTIF 26 VARIABEL …………… 90
Lampiran 3 HASIL UJI VALIDITAS ……………………………….. 92
Lampiran 4 ANALISA KOMPONEN UTAMA ……………………. 96
Lampiran 5 REGRESI LINEAR BERGANDA ……………………... 100
Lampiran 6 KOMENTAR TAMBAHAN RESPONDEN …………... 101
xi
DAFTAR SINGKATAN
ICT Information, Communication and Technology

ISV Independent Software Vendor
IS/SI Information System/Sistem Informasi
PMI Project Management Institute Inc.
PM-BOK Project Management Body of Knowledge
xii
INTISARI
Penelitian empiris ini dilakukan melalui survei sesaat terhadap 90

responden dalam bidang industri pengembang perangkat lunak di Jakarta. Metode
analisa faktor dan regresi linear digunakan untuk menjawab pertanyaan berupa
pencarian faktor penyebab kegagalan proyek perangkat lunak, serta model
evaluasinya.
Penelitian dalam bidang perangkat lunak masih menarik banyak peneliti
disebabkan antara lain dinamika pelaksanaan proyek yang akan menghasilkan
output/asset yang bersifat intangible, berupa rekayasa pemrograman berdasarkan
permintaan yang seringkali menghadapi situasi ketidak-pastian. Keberhasilan atau
kegagalan proyek umumnya diukur berdasarkan pada business profitability
melalui proxy biaya dan jadwal.
Validitas isi instrumen kuesioner dibuat berdasarkan sumber dari beberapa
literature pendahulu yang terkait. Hasil statistik deskriptif menunjukkan bahwa
mayoritas responden menyatakan persetujuan bahwa 26 pernyataan variabel
obesrvasi sebagai indikator penyebab masalah over-budget dan over-schedule.
Berdasarkan pengalaman responden, proyek perangkat lunak saat
penelitian ini dilakukan ternyata dipersepsikan memiliki tingkat masalah di atas
rata-rata.
Penelitian ini menghasilkan kontribusi berupa implikasi manajerial berupa
6 faktor yang perlu diperhatikan untuk menurunkan tingkat masalah. Disamping
kontribusi manajerial, evaluasi model yang dihasilkan dapat dijadikan sebagai
bahan penelitian lebih lanjut oleh peneliti lain, agar dihasilkan historical-data
yang dapat menggambarkan perkembangan proyek setelah dilakukan perbaikan.
Kata Kunci: Proyek perangkat lunak, kesuksesan dan kegagalan proyek, melebihi
anggaran, melibihi jadwal, prediksi masalah proyek, sistem informasi dan bisnis,
studi empiris, analisa faktor eksploratif.
xiii
ABSTRACT
This thesis is an empirical one-time research that collected response from

90 people who have working experiences in information system industry in
Jakarta. Research questions were resolved using factor analysis and linear
regression technique to find out answers for this research around factors causing
failure in software project, and a model to evaluate the findings.
There are still many interests to do research in software project topic due
to the characteristic of software as intangible output/asset produced through
engineering process based on customer’s somewhat uncertain requirements to
cater their dynamic business needs. While in contrast, a project’s success of
failure is commonly measured based on strict budget and schedule as proxy to
business profitability.
Content validity of questionnaires research were observed from prior
related journals. The research findings indicated that 26 item (variable) were
perceived by respondents as being indicators to over-budget and over-schedule
circumstance.
The respondents perceive that software projects having difficulties and
problems to complete on-time and on-schedule at level above average.
This thesis research contributes six factors as feedback for manajerial to
reduce the intensity of project’s level of problem. Feedback for academic is
project evaluation model from this one-time research that is open for further
improvement.
Key Words: Software project, success/failure, over-budget, over-schedule, project

problem, business and information system, empirical study, exploratory factor
analysis.
xiv
BAB I. PENDAHULUAN
1.1. Latar Belakang Permasalahan
Penggunaan teknologi komputer oleh organisasi memiliki beberapa tujuan
yang intinya adalah peningkatan kinerja (performance and efficiency) dan tingkat
validitas proses (accuracy) dalam proses bisnis. Akan tetapi, organisasi kerap
menghadapi masalah ketika sistem teknologi komputer yang dikenalkan tidak
digunakan oleh karyawan. Organisasi juga menghadapi dilema untuk memutuskan
apakah akan menghentikan proyek yang berarti investasi untuk mencapai tujuan
organisasi kandas di tengah jalan, atau melanjutkan proyek dengan konsekuensi
adanya penambahan investasi demi kesuksesan program yang akan mendukung
strategi bisnis.
Pencapaian manfaat dari sebuah proyek perangkat lunak (software) tidak
semata-mata bergantung pada kecanggihan teknologi saja, melainkan ada komponen
lain yang mempengaruhi yaitu proses (process) dan manusia (people). Oleh sebab itu,
penelitian dalam bidang manajemen sistem informasi seringkali mengadopsi teori dari
bidang lain seperti psikologi dan prilaku orgnaisasi. Salah satu contoh penelitian lama
yaitu Technology Acceptance Model (TAM) oleh Davis (1985). Teori TAM
melanjutkan temuan dari tulisan lain yaitu Innovation Diffusion Theory oleh Rogers
(1962) yang menekankan perlunya sebuah proses sosialisasi dalam mengenalkan
sebuah inovasi. Teori lainnya lagi adalah Theory of Reasoned Action (Fishbein &
Ajzen, 1975) yang menggagas bahwa prilaku seseorang ditentukan oleh adanya
kehendak untuk menciptakan prilaku tersebut (behavioural intention) yang
dipengaruhi oleh norma-subyektif (subjective-norm). Intinya, teori tersebut membahas
1
tentang penerimaan teknologi oleh pengguna untuk produksi/operasional, yaitu ketika
proyek pengembangan (development) teknologi telah selesai.
Teknologi perangkat lunak dapat berupa aplikasi yang siap pakai (off-the-shelf
application) atau aplikasi rancangan khusus (customized solution) yang dikerjakan
dalam sebuah rangkaian kegiatan proyek seperti analisa kebutuhan, pemilihan
pemasok, konstruksi, pengujian dan implementasi.
Beberapa metodologi dan best-practice framework mengenai proyek perangkat
lunak terus dikembangkan dan dikenalkan. Metodologi dibuat sebagai standar acuan,
yang dapat disesuaikan secara otonom dalam proyek untuk menyeimbangkan
keterbatasan pada dimensi-dimensi cakupan pekerjaan (scope) yang dikerjakan sesuai
anggaran (cost) dan selesai dalam target waktu (time) tertentu dengan memperhatikan
kualitas atas hasil (quality).
Salah satu penghalang utama yang dihadapi oleh manajer proyek dalam
mengelola manajemen risiko pada proyek perangkat lunak adalah membuat ukuran
bagi risiko itu sendiri, disebakan karakteristik perangkat lunak yang intangible (Islam
et al, 2014). Karakterisitik tersebut menimbulkan kesulitan untuk mengukur secara
kuantitatif pencapaian (progress) proyek sistem informasi (Abdel-Hamid, 1989).
Ditambah lagi oleh seringnya user/business requirement yang tidak didefinisikan
dengan jelas (uncertainty) sehingga sulit mendapatkan perkiraan biaya yang tepat
untuk mencakup semua dimensi proyek (Heemstra, 1992).
2
Ketika proyek perangkat lunak tidak berjalan sesuai yang diharapkan dan
mengalami masalah karena berbagai sebab, maka cepat atau lambat manajer proyek
melakukan proses eskalasi (escalation) kepada sponsor proyek dan manajemen-atas
sebagai indikasi terjadinya masalah pada proyek, agar dapat diambil keputusan dan
tindakan lebih lanjut.
Menurut temuan dan laporan dari beberapa studi dan penelitian, bahwa proyek
perangkat lunak sangat rentan mengalami eskalasi yang akibatnya dapat saja berakhir
dengan penghentian proyek, atau bila mungkin, proyek akan diarahkan kembali pada
jalurnya (Mark dan Robey, 1999). Sejalan dengan itu, kegiatan penelitian terus
berlanjut untuk menemukan penyebab utama kegagalan proyek. Pada sudut pandang
berbeda, penelitian lain menggagas faktor-faktor penting kesuksesan proyek. Pada
intinya, dinamika proyek sistem informasi khususnya perangkat lunak masih menarik
perhatian para peneliti untuk menawarkan gagasan untuk perbaikan.
Sebuah penelitian yang dilakukan oleh Keil et al. (2000) melalui survei
terhadap 361 IS Auditor yang telah menangani paling sedikit 5 proyek dengan masa
pengalaman profesi di bidang audit dan pengendalian (audit and control) rata-rata 10,5
tahun. Hasil survei menunjukkan bahwa lebih dari 82% proyek yang tereskalasi
dipersepsikan telah melebihi anggarannya (over-budget), dan 92% dari jumlah tersebut
mengalami keterlambatan jadwal (delay). Meski demikian, penelitian lain
menunjukkan bahwa proyek yang tereskalasi tidak selalu berarti buruk dalam
pelaksanaannya dibandingkan dengan yang tidak tereskalasi.
3
The Standish Group International (2013) dalam laporannya menyampaikan
temuan hasil dari data penelitian mereka sebagai berikut:
The 2012 CHAOS results show another increase in project success rates, with
39% of all projects succeeding (delivered on time, on budget, with required
features and functions); 43% were challenged (late, over budget, and/or with
less than the required features and functions); and 18% failed (cancelled prior
to completion or delivered and never used). These numbers represent an uptick
in the success rates from the previous study, as well as a decrease in the
number of failures.The low point in the last five study periods was 2004, in
which only 29% of the projects were successful. This year’s results represent a
high watermark for success rates in the history of CHAOS research.
CHAOS Research membuat kategori berikut terhadap proyek perangkat lunak:
Success, Challenging, dan Failed. Riset tersebut menunjukkan bahwa tingkat
kesuksesan proyek (Success) adalah sebesar 39%, yang berarti terjadinya peningkatan
angka dari data studi mereka sebelumnya. Adapun yang masuk dalam ketegori
menantang (Challenging) sebesar 43%, dengan kriteria terjadinya keterlambatan
penyelesaian, biaya yang melebihi anggaran, dan pekerjaan yang belum memenuhi
fungsi dan fitur yang diharapkan. Sedangkan 18% dikategorikan sebagai gagal
(Failed) sebelum digunakan atau dibatalkan sebelum proyek selesai. Tabel dan Grafik
di bawah ini menggambarkan temuan tersebut.
Tabel 1.1: Kinerja Proyek selama 2004-2012
Criteria/year 2004 2006 2008 2010 2012

Successful 29% 35% 32% 37% 39%
Failed 18% 19% 24% 21% 18%
Challenge 53% 46% 44% 42% 43%
Sumber: Chaos Research 2013
4
Gambar 1.1: Kinerja Proyek selama 2004-2012
Sumber: Chaos Research 2013
1.2. Rumusan/identifikasi Masalah
Penelitian ini didasarkan pada beberapa rumusan dan identifikasi masalah yang
terjadi, sebagai berikut:
1) Pilihan adopsi teknologi sistem informasi
Keputusan adopsi aplikasi komputer yang umum terjadi adalah: membuat
sendiri (to make) atau membeli (to buy) baik dengan menyewa atau beli putus.
Keputusan membeli berarti menyerahkan tanggung jawab dan risiko pekerjaan
pada pihak luar. Organisasi cenderung memilih untuk membeli dengan tujuan
meminimalkan risiko pelaksanaa pekerjaan, terutama jika teknologi dianggap
masih baru dan belum dikuasai. Alasan lainnya adalah faktor propriatery
information dan keahlian khusus (specialized skill) yang dimiliki oleh vendor.
Untuk tujuan tersebut, proses pemilihan dan pengadaan perlu dilakukan dengan
benar.
5
2) Dilema yang dihadapi organisasi
Karakteristik yang intangible ditambah dengan pelaksanaannya oleh pihak
luar (vendor/supplier) menciptakan kombinasi proses yang kompleks.
Kompleksitas muncul antara lain karena adanya konflik kepentingan antara
client/buyer dan vendor/supplier antara lain:
a. Vendor menginginkan proyek yang menguntungkan (profitable),
adapun buyer mengingingkan biaya yang ekonomis dan efisien untuk
memenuhi permintaan atau kebutuhan pengguna/bisnis.
b. Melakukan penilaian terhadap proyek ketika terjadi masalah, apakah
proyek masih dalam kondisi yang wajar untuk dilanjutkan, atau justru
berisiko dan perlu segera dihentikan.
Eskalasi proyek bermasalah kepada sponsor proyek bahkan manajemen-
atas (C-level) akan menentukan keputusan yang dapat berupa penghentian proyek
(terminated), atau melanjutkan dengan tambahan dan sumber daya lain
(continued), atau meninjau ulang proyek (redirected) (Keil et al., 2000).
Organisasi harus siap menghadapi keadaan dilematis tersebut.
3) Faktor-faktor penyebab eskalasi
Jumlah proyek perangkat lunak yang mengalami eskalasi menunjukkan
angka yang tidak kecil yaitu 30-40% dari seluruh proyek menurut hasil penelitian
yang dilakukan oleh Keil et al., (1999) sebagaimana yang dikatakan dalam
tulisannya:
6
Based on a subsample of 361 experienced IS audit and control
professionals, responses to these questions indicated that escalation
occurs in approximately 30-40 percent of all IS project.
Sekian banyak faktor penyebab eskalasi proyek yang disimpulkan oleh Kundi et
al. (2007) menjadi 4 (empat) penyebab yang fundamental, yaitu faktor terkait
proyek itu sendiri, faktor psikologi manusia, faktor sosial, dan faktor dari dalam
organisasi:
Most of the researchers agree on the four fundamental causes of escalation

as being: a. project-related, b. human psychology/ personality, c. social,
and d. organizational.
Manajemen dalam organisasi client serta vendor perlu mengenali indikator-
indikator penting yang dianggap sebagai pencetus gagalnya proyek.
1.3. Pertanyaan Penelitian
Penelitian ini akan melakukan eksplorasi untuk mendapatkan jawaban atas
beberapa pertanyaan penelitian di bawah ini:
1) Faktor-faktor apa saja yang sering menjadi penyebab kegagalan proyek
implementasi perangkat lunak?
2) Bagaimana model evaluasi faktor-faktor penyebab kegagalan proyek
implementasi perangkat lunak?
7
1.4. Tujuan Penelitian
Berangkat dari rumusan masalah dan pertanyaan penelitian di atas, maka
tujuan dari penelitian ini diharapkan dapat menghasilkan beberapa jawaban antara
lain:
1) Mencari faktor-faktor penyebab kegagalan proyek implementasi perangkat
lunak.
2) Membangun model evaluasi penyebab kegagalan proyek implementasi
perangkat lunak.
1.5. Manfaat Penelitian
Penelitian diharapkan dapat memberikan manfaat baik dalam aspek teoritis
akademis, maupun aspek praktis bisnis.
Sejauh pengetahuan penulis sebelum memilih bahasan ini, bahwa masih jarang
sekali penelitian di Indonesia yang melakukan eksplorasi untuk meneliti faktor-faktor
penyebab kegagalan proyek perangkat lunak. Hal tersebut terutama disebabkan karena
industri perangkat lunak lokal yang masih relatif baru dan sedang tumbuh menyaingi
perusahaan luar negeri yang lebih matang.
Manfaat teoritis dari penelitian juga akan membangun sebuah evaluasi atas
model persamaan untuk membuat perkiraan mengenai tingkat masalah yang dihadapi
proyek perangkat lunak. Harapannya, berangkat dari model awal tersebut, peneliti
berikutnya dapat mengembangkan dengan bentuk yang jauh lebih baik dan akurat.
8
Adapun pada sisi praktis bisnis, manfaat yang dapat diambil dari penelitian ini
berupa masukan bagi organisasi client maupun vendor mengenai faktor-faktor utama
penyebab gagalnya proyek melalui studi empiris (kuesioner) berdasarkan sudut
pandang responden yang sebagian besar adalah manajer proyek.
1.6. Ruang Lingkup dan Batasan Penelitian
Batasan penelitian hanya terkait pada proyek perangkat lunak yang dilakukan
oleh organisasi buyer/client yang melibatkan pihak luar supplier/vendor ketika
pelaksanaannya dilakukan dalam rangkaian kegiatan proyek antara kedua organisasi
tersebut.
Penelitian dilakukan dengan cara mengumpulkan data lewat survei pengalaman
(experience survey) dan merupakan penelitian sesaat terhadap responden pelaku
proyek sistem informasi yang tidak dibatasi pada industri atau sektor tertentu.
1.7. Sistematika Penulisan
Penulisan disusun dalam beberapa bab yang terdiri dari Bab-I Pendahuluan
yang menjelaskan latar belakang, rumusan masalah, pertanyaan yang menjadi topik
dalam penelitian ini serta batasan-batasannya. Bab ini juga memberikan penjelasan
tentang tujuan dan manfaat yang ingin dicapai oleh penelitian ini.
Pada Bab-II, penulis memaparkan landasan teori dan topik bahasan yang
diambil dari penelitian sebelumnya serta literatur pustaka berupa text-book, dan
laporan institusi jurnal maupun non-jurnal.
9
Bab-III adalah mengenai metodologi penelitian yang menjelaskan tentang
obyek penelitian yang dipilih, serta teknik sampling yang diambil untuk
mengumpulkan data melalui instrumen kuesioner.
Bab-IV menjelaskan keterbatasan penelitian, dan menjabarkan proses data
yang telah terkumpul menggunakan alat-bantu statistik standar untuk penelitian bisnis,
serta proses analisis dan interpretasi atas temuan empiris tersebut.
Bab-V berisi kesimpulan dan saran sebagai hasil dari kegiatan penelitian bagi
akademisi maupun dunia praktisi.
Bagian terakhir berisi daftar pustaka, lampiran-lampiran yang menyertakan
beberapa data pendukung serta data hasil pengolahan statistik.
10
BAB II. LANDASAN TEORI
Bab ini akan memaparkan istilah dan konsep yang terkait dengan penelitian ini.
Berdasarkan pada pertanyaan dan tujuan penelitian pada Bab I, landasan teori dipilih
sebagai pijakan yang bersumber dari literatur text-book maupun penelitian-penelitian
sebelumnya yang membahas hubungan antara bisnis dan sistem informasi, serta peran
sebuah proyek dalam hubungan tersebut.
2.1. Tinjauan Pustaka/Landasan Teori
2.1.1. Teknologi dan Keunggulan Kompetitif (Competitive Advantage)
Organisasi bisnis dalam era modern menghadapi persaingan yang ketat dan
berskala global, sehingga mendesak pengambil keputusan untuk membuat strategi
unggulan dalam persaingan yang antara lain dengan menciptakan kemampuan yang
tidak dimiliki oleh pesaing, atau melakukan sesuatu dengan cara atau hasil yang lebih
baik dari pesaing.
Porter & Miller (1985) mengemukakan peran teknologi informasi bagi bisnis
dalam hal penciptaan strategi bersaing yang mampu menghasilkan sesuatu yang
berbeda (differentiation) agar bisnis dapat mengambil manfaat dari persaingan.
Teknologi telah menciptakan perubahan dalam struktur sebuah industri terkait
hubungan antar lima-kekuatan (“five-forces”) dalam hal bertransaksi yang mencakup
skala, metode, serta kelenturan proses. Teknologi juga membantu perusahaan untuk
menjalankan strategi bisnis berbiaya-rendah (low-cost leadership) dengan memotong
biaya akibat proses rantai-nilai yang tidak efisien. Untuk menghasilkan suatu pembeda
(differentiation) dalam produk dan layanan, sebagai contoh, perusahaan mulai
11
mengadopsi Computer-Aided Design dan Computer-Aided Manufacturing agar proses
produksi berjalan secara lentur namun akurat serta customizable. Lebih dari itu,
teknologi telah membantu terciptanya bisnis baru yang menggantikan bisnis lama yang
secara alamiah mengalami kemerosotan permintaan, seperti layanan pos surat manual.
Porter & Miller (1985) memberikan ilustrasi pada diagram di bawah mengenai
teknologi dan sistem informasi sebagai salah satu peran dan aktifitas pendukung yang
berada pada setiap rantai-nilai bisnis utama dalam menghasilkan margin.
Gambar 2.1: Teknologi Informasi dalam Rantai Nilai

Sumber: Porter & Miller (1985)
Bagi perusahaan modern, untuk melibatkan teknologi informasi dalam proses
bisnis, maka adopsi teknologi telah didiskusikan sejak tahap awal perencanaan strategi
bisnis. Melibatkan teknologi informasi bertujuan antara lain agar manajemen memiliki
kemampuan mengukur intensitas dan kinerja kegiatan secara akurat dan langsung
12
(real-time), sehingga keputusan serta reaksi terhadap pasar dan persaingan dapat
dibuat secara cepat.
David, Fred. R (2011) dalam “Strategic Management Concept and Cases”
mengatakan bahwa kekuatan teknologi secara dramatis mempengaruhi organisasi
dalam hal produk, layanan, pasar, pemasok, distributor, pesaing, pelanggan, proses
produksi, praktik pemasaran, dan posisi bersaing. Dengan kata lain, organisasi
seharusnya tidak menyerahkan keputusan adopsi teknologi kepada pelaksana di
jenjang-bawah struktur organisasi. Mengingat peran teknologi yang penting dalam
implementasi strategi organisasi, manajemen-atas harus mengambil sikap inisiatif dan
proses adopsi teknologi perlu dilakukan dengan cara yang integral dan menyeluruh
serta tidak terpilah-pilah (silo).
2.1.2. Bisnis dan Sistem Informasi
Brown et al. (2012) dalam “Managing Information Technology 7th Edition”
memaparkan mengenai pentingnya keselarasan antara bisnis dengan teknologi
informasi yang dapat terjadi melalui keterlibatan manajer bisnis dalam perencanaan
sistem informasi dan infrastuktur teknologi. Dalam struktur organisasi perusahaan,
fungsi dan peran SI berada di bawah manajemen yang beragam, terkadang berada di
bawah departemen keuangan, atau departemen operasi, atau sebagai organisasi
tersendiri yang langsung berada di bawah CIO. Keputusan tersebut tergantung pada
sudut pandang pimpinan perusahaan terhadap peran teknologi informasi bagi bisnis.
13
Brown et al. menggambarkan proses perencanaan sumber daya informasi oleh
organisasi SI yang melibatkan fungsi bisnis seperti pada Gambar-2.2. Keselarasan
antara Teknologi Informasi dan Bisnis (IT-Business Alignment) merupakan sebuah
proses yang berlangsung terus menerus, yang direalisasikan dalam bentuk rencana
penerapan jangka pendek maupun jangka panjang sebagai wujud kontribusi untuk
mencapai sasaran yang dibuat oleh manajer bisnis. Keterlibatan yang terus-menerus
adalah penting mengingat inovasi yang cepat dalam informasi, komunikasi dan
teknologi (ICT) berdampak pada pendeknya siklus-hidup teknologi tertentu dan
penyusutannya.
Gambar 2.2: Process Perencanaan Sumber Daya IS

Sumber: Brown (2012)
14
Ada 5 (lima) tahapan yang dipaparkan oleh Brown, yaitu:
1) Menguji sumber daya informasi yang dimiliki saat ini terkait posisinya
dalam competitive advantage. Konsultan ahli dari luar mungkin dilibatkan
pada tahapan ini untuk memberikan pandangan kepada manajer bisnis dan
SI mengenai benchmark, standar industri, praktik terbaik yang sudah ada,
agar diketahui kesenjangan (gap) antara sumber daya informasi saat ini dan
rencana ke depan. Selanjutnya, misi organisasi SI perlu disesuaikan sebagai
hasil dari tahapan ini.
2) Membuat “Visi Informasi” berupa sebuah kesepakatan tertulis mengenai
bagaimana kekayaan/aset informasi akan diproses, digunakan serta dikelola
di dalam organisasi. Informasi dan proses bisnis akan dibuat standar,
diotomatiskan, digabungkan/dihubungkan, serta disimpan/diamankan.
3) Membuat disain arsitektur teknologi informasi yang mencakup sumber
daya teknologi (perangkat keras, perangkat lunak, jaringan, dan data), serta
sumber daya manusia. Organisasi SI melakukan proses pembelajaran untuk
meningkatkan kematangan arsitektur tersebut agar dapat terus mendukung
strategi bisnis, seperti aristektur untuk menghadapi rencana merger,
integrasi rantai-nilai dengan rekan bisnis, alih-daya proses bisnis tertentu,
dan sebagainya.
4) Membuat rencana strategis sistem informasi dalam bentuk rangkaian
kegiatan jangka panjang, strategi operasional, dan inisiatif yang ingin
15
dijalankan atau dicapai oleh organisasi SI sesuai dengan rencana bisnis
yang memiliki competitive advantage, seperti low-cost IT investment,
differentiation in IS solution. Ukuran kinerja perlu dibuat untuk setiap
wilayah dan komponen kunci seperti tingkat layanan jaringan data,
produktifitas personil pendukung SI, manfaat aplikasi komputer bagi
bisnis, dan sebagainya.
5) Membuat rencana operasional sebagai realisasi dari rencana strategis dan
program initiatif yang dibuat di tahapan sebelumnya. Realiasi biasanya
berupa rencana proyek-proyek sistem informasi dan teknologi termasuk
prioritas dan anggarannya. Rencana proyek berisi penjelasan tentang
tujuan, tindakan yang akan diambil, analisa biaya dan manfaat investasi,
serta tata-kelola risiko. Keputusan menjalankan proyek termasuk pilihan
to-make or to-buy dengan kelebihan dan kekurangannya yang perlu
dianalisa dan diputuskan bersama. Sebuah proyek sistem informasi
biasanya diawali dengan mengajukan kasus-bisnis (Business-case)
menjelaskan manfaat yang ingin dicapai, perkiraan investasi modal, dan
biaya operasional untuk diputuskan dalam sidang komite proyek.
Brown et al. berdasarkan pada artikel yang dibuat oleh Pottruck & Pearce
(2000); serta Weill & Ross (2009) yang menceritakan kisah berlatar belakang
Peleburan Teknologi Informasi dan Bisnis, ketika seorang manajer bisnis yang
mengalami kegagalan dalam sebuah proyek karena menganggap IT hanyalah sebuah
alat-bantu yang tidak ada hubungannya dengan urusan bisnis mereka, padahal IT
16
merupakan dasar bagi perusahaan untuk memiliki kemampuan berkompetisi dalam
bisnis.
“Fusing IT and the Business - When Terry Pearce was an IT manager at a

large financial services company several decades ago, he found that the
business managers who refused to help the IT managers understand what new
information systems they actually needed were the managers who ended up
with the least successful IT projects.
Their projects were delayed and more expensive than planned. He concluded
that it wasn’t intentional. Rather, the business managers just couldn’t
appreciate why their involvement was important; they saw IT as merely a
tool—not as integral to their business. But to succeed in today’s digital
economy, senior business managers in companies dependent on information
need to be “IT-savvy.” When IT is the basis for a company’s competitive
capabilities, business managers need to be confident in their abilities to build
their company’s IT capabilities into a strategic asset.”
2.1.3. Project Management – Body Of Knowledge
Pinto J.K (2007), menuliskan dalam bukunya “Project Management: Achieving
Competitive Advantage” bahwa daftar proyek-proyek dalam sebuah perusahaan ibarat
susunan-batu (building-block) yang merupakan batu-loncatan (stepping-stone) yang
berisi program dan rangkaian rencana aksi untuk merealisasikan strategi perusahaan.
Mengacu kepada konsep proyek yang digagas oleh Project Management
Institute Inc. yang tersusun dalam buku “A Guide to the Project Management Body of
Knowledge 5th Edition (2013)” yang memberikan definisi manajemen proyek sebagai
sebuah penerapan terhadap pengetahuan, keahlian, alat-bantu dan teknik untuk
melakukan proyeksi terhadap aktifitas agar memenuhi kebutuhan/permintaan serta
tujuan proyek yang mencakup: (1) mengenali kebutuhan/permintaan; (2) membangun
17
tujuan yang jelas dan dapat dicapai; (3) menyeimbangkan tuntunan yang saling beradu
kepentingan antara kualitas, cakupan kerja, jadwal, dan biaya; (4) menyesuaikan
spesifikasi, rencana, dan pendekatan terhadap masalah dan harapan yang berbeda dari
beragam pemangku kepentingan.
Area pengetahuan proyek (project knowledge area) yang dijabarkan dan
didefinisikan dalam buku tersebut sebagai berikut:
Tabel 2.1: Area Pengetahuan (Knowledge Area)

No. Area Pengetahuan Definisi
Proyek (project
knowledge area)
1. Tata-kelola Komunikasi Meliputi proses yang diperlukan untuk
(Communication memastikan tepatnya perencanaan, pengumpulan,
Management) pembuatan, pendistribusian, penyimpanan,
pengambilan, pengelolaan, pengendalian,
pengawasan, dan penyerahan akhir mengenai
informasi proyek.
2. Tata-kelola Biaya (Cost Meliputi proses mengenai perencanaan,

Management) perkiraaan, anggaran, keuangan, pembiayaan,
pengelolaan dan kendali biaya agar proyek selesai
sesuai anggaran yang disetujui.
3. Tata-kelola Sumber Daya Meliputi proses untuk menyusun, mengelola, dan

Manusia (Human memimpin tim proyek.
Resource Management)
4. Tata-kelola Integrasi Meliputi proses dan aktifitas identifikasi,

(Integration pendefinisian, penggabungan, penyatuan, dan
Management) kordinasi antar beragam proses dengan aktifitas
manajemen proyek dalam kelompok proses.
5. Tata-kelola Pengadaan Meliputi proses yang dibutuhkan untuk membeli

Barang (Procurement atau pengadaan produk, layanan atau hasil yang
Management) diperlukan dari luar lingkungan proyek.
Sumber: Ringkasan oleh peneliti dari PM-BoK, PMI Inc, 2013
18
Tabel 2.1, lanjutan
No. Area Pengetahuan Definisi
Proyek (project
knowledge area)
6. Tata-kelola Kualitas Meliputi proses dan kegiatan oleh organisasi
(Quality Management) pelaksana dalam menentukan kebijakan mutu,
tujuan, dan tanggung jawab agar memberikan
kepuasan atas hasil dari tugas yang diemban.
7. Tata-kelola Risiko (Risk Meliputi proses pelaksanaan rencana mengenai

Management) tata kelola risiko, identifikasi, analisa, rencana
reaksi, dan kendali risiko dari sebuah proyek.
8. Tata-kelola Cakupan Meliputi proses yang diperlukan untuk

(Scope Management) memastikan bahwa proyek telah dan hanya
mencakup pekerjaan yang diminta agar selesai
dengan sukses.
9. Tata-kelola Pemangku Meliputi proses yang diperlukan untuk

Kepentingan identifikasi semua orang, ataupun organisasi yang
(Stakeholder terdampak oleh proyek, analisa harapan mereka
Management) serta dampaknya bagi proyek, membangun
strategi yang tepat untuk melibatkan mereka
dalam hal keputusan dan pelaksanaan proyek.
10. Tata-kelola waktu (Time Meliputi proses yang diperlukan untuk mengelola
Management) proyek agar selesai tepat waktu.
Sumber: Ringkasan oleh peneliti dari PM-BoK, PMI Inc, 2013
Berangkat dari konsep awal berdasarkan pada pembagian di atas, peneliti
berusaha menemukan indikator masalah yang muncul dalam proyek perangkat lunak
sesuai konsep tersebut. Analisa indikator dilakukan berdasarkan pada jurnal penelitian
sebelumnya yang kemudian diringkas menjadi sebuah pernyataan yang dijadikan
instrumen dalam survei responden. Indikator-indikator tersebut dikelompokkan ke
dalam konsep-konsep yang dibagi dalam 10 (sepuluh) area pengetahuan yang
dijabarkan pada tabel dan sub judul berikut.
19
2.1.4. Konsep Dan Indikator
Tabel di bawah ini menjelaskan hubungan konsep, referensi jurnal, serta indikator sebagai instrumen kuesioner.
Tabel 2.2: Konsep, Indikator, dan Referensi Jurnal

No KODE - REFERENSI JURNAL INDIKATOR/ PERNYATAAN Definisi Indikator/Variabel
KONSEP VARIABEL KUESIONER
1. COM1 - Kundi, G.M., Nawaz, A., Shah, B. Masalah Proyek Masalah dan risiko Jika risiko/masalah tidak disampaikan
Communication "De-Escalating The IT Projects". proyek tidak sepenuhnya, maka client akan kecewa ketika
Management Journal of Information Systems and sampaikan akhirnya mengetahui. Hal ini menunjukkan
Technology Management Vol. 4, No. sepenuhnya. komunikasi tidak berlangsung secara efektif,
3, 2007, p. 325-332 yaitu tidak adanya keterbukaan antar manajer
proyek baik vendor dan client.
2. COM2 - Keil, M. Robey, D. "Turning around Perencanaan Kesepakatan rencana Tidak adanya reaksi serta sikap pro-aktif
Communication Troubled Software Projects: An Komunikasi komunikasi manajemen-atas ketika disampaikan
Management Exploratory Study of the (communication plan) masalah/risiko proyek merupakan indikator
Deescalation of Commitment to tidak berjalan efektif. bahwa rencana komunikasi yang telah
Failing Courses of Action". Journal disepakati tidak berjalan dengan baik.
of MIS, Vol. 15, No. 4 (Spring,
1999), pp. 63-87
3. COM3 - Keil, M. Mann, J. and Rai, A. "Why Laporan Manajemen tidak Kemungkinan akan adanya bias dalam isi
Communication Software Projects Escalate: An Kinerja menguji keakuratan laporan proyek yang sampaikan kepada
Management Empirical Analysis and Test of Four laporan kinerja manajemen-atas. Bila tidak dilakukan
Theoretical Models". MIS proyek. pengecekan langsung, maka terjadi
Quarterly, Vol. 24, No. 4 (Dec., kesalahpahaman tentang kinerja proyek yang
2000), pp. 631-664 ternyata tidak sesuai dengan harapan
biaya/jadwal. Bila kemudian hari baru akan
muncul, maka dapat menyebabkan proyek
dihentikan (dianggap gagal).
Sumber: Ringkasan yang dibuat oleh peneliti
20
Tabel 2.2, lanjutan
4. COS1 - Cost Nelson, R.R. 2005. "PROJECT Trade-off of Customer tidak Ketika pekerjaan dirinci lebih dalam dan
Management RETROSPECTIVES evaluating project bersedia mengurangi diketahui akan melampaui biaya atau jadwal
project success failure and constraints 'scope'. semula, negosiasi jadwal/biaya perlu
everything in between". MIS dilakukan. Bila client tidak menyetujui trade-
Quarterly Executive Vol. 4 No. 3 / off dengan mengurangi cakupan, atau
September 2005. menambah biaya/jadwal, maka dapat
dipastikan jadwal akan meleset, atau
anggaran akan kurang.
5. HUM1 - Almeida, M.V. Soares, A.L. 2014. Komunikasi Komunikasi verbal Komunikasi verbal antar internal tim proyek
Human "Knowledge sharing in project- internal tim tim internal proyek akan membantu proses pertukaran informasi
Resource based organizations: Overcoming tidak lancar. dan pengetahuan yang akan mempercepat
Management the informational limbo" proses dinamika kerjasama. Ketika
International Journal of komunikasi dalam bentuk formal yang sering
Information Management 34 dilakukan lewat dokumen dan tulisan, akan
(2014) 770–779 banyak menyita waktu dan biaya.
6. HUM2 - Abdel Hamid. 1989. "A Study of Pelatihan tim Pelatihan bagi anggota Ketika anggota proyek yang lama
Human Staff Turnover, Acquisition, And baru baru dilakukan oleh memberikan pelatihan kepada anggota baru,
Resource Assimilation and Their Impact on anggota lama. maka kontribusi anggota lama terhadap
Management Software Development Cost and kinerja proyek akan menurun karena waktu
Schedule". Journal of Management untuk melatih. Disamping itu, anggota baru
Information Systems, Vol. 6, No. 1 pun belum bisa berproduksi untuk proyek
(Summer, 1989), pp. 21-40. ketika pelatihan memerlukan waktu
tergantung pada kemampuan individu
anggota baru.
21
Tabel 2.2, lanjutan
7. HUM3 - Human Abdel-Hamid, T.K. 1992. Suksesi Terjadi suksesi Peran manajer proyek dan manajemen-atas yang
Resource "Investigating the impacts of kepemimpinan pada manajer telah mengerti seluk-beluk proyek adalah peran
Management managerial turnover/succession of proyek, atau sangat penting agar proyek dapat selesai tepat
software project performance". sponsor proyek. waktu dan anggaran. Bila terjadi pergantian pada
Journal of Management peran tersebut, sedikit atau banyak pasti akan
Information Systems Vol. 9, No. 2, berpengaruh kepada jadwal dan biaya proyek.
(fall 1992) pp. 127-144.
8. HUM4 - Human M. André et al. 2011. "Formal Masalah Terjadi masalah Ketimpangan dalam pembagian tugas kepada
Resource model for assigning human Penugasan dalam internal tim anggota tertentu menyebabkan masalah internal
Management resources to teams in software karena anggota tim. Ketimpangan dapat berupa
projects". Information and ketimpangan penugasan pada orang yang salah, atau penugasan
Software Technology 53 (2011) (kesalahan) dalam berlebih kepada orang yang tepat (overload).
259–275. pembagian tugas.
9. INT1 - Harris, M.L, Collins, R.W., and Kemampuan Manajer proyek Lingkungan proyek penuh dengan ketidakpastian,
Integration Hevner, A.R. Manajer Proyek tidak mampu baik dari segi sumber daya manusia, kemampuan
Management "Control of Flexible Software menangani bekerja-sendiri namun terhubung satu dan yang
Development Under Uncertainty". lingkungan proyek lainnya, serta ketidakpastian dari sisi permintaan
Information Systems Research, Vol. yang tidak pasti. customer. Kondisi tersebut perlu dilihat secara
20, No. 3, Flexible and Distributed integral oleh manajer proyek. Disamping itu,
Information Systems Development manajer proyek perlu memiliki kemampuan untuk
(September 2009), pp. 400-419 mengendalikan keadaan tersebut dengan cara
memilih metode kendali (control method) yang
tepat.
22
Tabel 2.2, lanjutan

10. INT2 - Maruping, Venkatesh, and Metodologi Salah memilih Setiap metode memiliki ciri dan khas sendiri.
Integration Agarwal. 2009. "A Control Theory Proyek metode untuk Pada proyek dengan tingkat ketidakpastian atau
Management Perspective on Agile Methodology proyek dengan perubahan permintaan yang tinggi, maka perlu
Use and Changing User tingkat perubahan digunakan metode yang sesuai, spt Agile dsb.
Requirements". Information permintaan yang
Systems Research 20(3) pp. 377- tinggi.
399, 2009 INFORMS.
11. INT3 - Ferrat T.W. , Ahire, S. Prabuddha Model Hasil Customer tidak Ketika teknologi relatif baru bagi client maka
Integration De. 2006. "Achieving Success in memiliki contoh hasil proyek tidak tampak jelas, dan
Management Large Projects - Implications from konkrit tentang dikhawatirkan hasil tidak sesuai dengan harapan.
a Study of ERP Implementation". hasil dari proyek Contoh/model dari best-practice yang sudah ada
Interfaces, Vol. 36, No. 5 (Sep. - yang akan dibuat. perlu didemonstrasikan kepada client agar
Oct., 2006), pp. 458-469. mereka memiliki gambaran mengenai rencana
hasil/output proyek.
12. INT4 - Abdel-Hamid, T.K. Sengupta, K. Tujuan Tidak Tujuan proyek Manajer proyek menilai realistis atau tidaknya
Integration and Swett, C. "The Impact of Goals Realistis dianggap tidak tujuan proyek secara jadwal dan biaya. Ketika
Management on Software Project Management: realistik oleh tujuan dianggap oleh manajer proyek tidak
An Experimental Investigation". manajer proyek. realistis, akan tetapi proyek tetap harus
MIS Quarterly, Vol. 23, No. 4 dijalankan atas keinginan sponsor
(Dec., 1999), pp. 531-555 proyek/manajemen-atas, maka keterlambatan
dan kekurangan biaya memang sudah dapat
diperkirakan sebelumnya.
23
Tabel 2.2, lanjutan
13. INT5 - Patanakul , P. et al. "How project Strategi Proyek Tata-kelola proyek Pentingnya manajemen proyek untuk selaras
Integration strategy is used in project tidak disesuaikan dengan strategi bisnis yang menghendaki
Management management-Cases of new product dengan strategi bisnis dijalankannya proyek. Bila strategi bisnis
development and software (seperti: keunggulan contohnya adalah 'time-to-market' maka
development projects". Journal of produk, atau time-to- manajemen proyek harus membuat
Engineering and Technology market). keputusan tentang pekerjaan agar tujuan
Management 29 (2012) 391–414 'time-to-market' harus terlaksana.
14. PRO1 - Heemstra, F.J. 1992. "Software cost Price-to-win Terjadi perilaku Tender yang melibatkan banyak vendor
Procurement estimation". Butterworth-Heinemann 'under-estimate' oleh mempengaruhi prilaku ingin menang oleh
Management Ltd Vol 34 No 10 October 1992. vendor untuk vendor. Ketika customer memiliki anggaran
memenangkan tender. tertentu yang menjadi acuan hitungan, maka
vendor akan berusaha mendekati hitungan
biaya pada anggaran tersebut agar dapat
dipilih sebagai pemenang tender.
Dampaknya adalah vendor tidak melakukan
perhitungan secara hati-hati (under-estimate)
ketika pekerjaan sebenarnya ternyata lebih
besar dari perkiraan.
15. PRO2 - Sommerville, I. 2004, Software Proses Terjadi selisih yang Sponsor proyek (buyer) melakukan
Procurement Engineering Edition 7.Pearson Penganggaran jauh antara anggaran perkiraan anggaran untuk proyek
Management Education Ltd p-620. buyer dengan harga berdasarkan pada besar permintaan. Ketika
oleh vendor. ditemui bahwa penawaran harga oleh vendor
memiliki selisih yang jauh dengan anggaran
sponsor proyek (buyer), berarti
menunjukkan indikasi adanya kesalahan
dalam anggaran oleh salah satu pihak.
24
Tabel 2.2, lanjutan

16. QUA1 - Abdel-Hamid, T.K. 1987. "The Anggaran QA Anggaran untuk Manajemen-atas menginginkan proyek
Quality Economics of Software Quality Quality Assurance berjalan dengan efisien secara keuangan,
Management Assurance- A System Dynamics sangat terbatas. akan tetapi client/proyek menginginkan hasil
based Simulation Approach" yang berkualitas. Kebijakan alokasi biaya
[Working Paper]. Massachusetts utk QA sering ditentukan sangat minim,
Institute of Technology. sehingga kegiatan QA berlangsung dengan
kekurangan biaya dan menyebabkan kualitas
proyek rendah seperti banyaknya defects.
17. RIS1 - Risk V.C. Gu et al. 2014. "The effects of Toleransi Manajemen-atas tidak Gaya kepemimpinan manajemen-atas sangat
Management organizational culture and Manajemen toleran mengenai berpengaruh pada lingkungan proyek,
environmental pressures kemungkinan/dampak terutama ketika menentukan tingkat
on IT project performance: A risiko. kemungkinan dan dampak dari risiko.
moderation perspective". Tingkat toleransi tinggi yang diberikan oleh
International Journal of Project manajemen akan memberikan ruang
Management 32 (2014) 1170–1181. (reserved) yang cukup bagi manajer proyek,
ketika risiko terjadi. Toleransi termasuk pada
kuantifikasi biaya, waktu, cakupan proyek,
serta kualitas.
18. RIS2 - Risk Keil, M., Cule, P.E., Lyytinen, K. Pengujian Pengujian risiko tidak Tata-kelola risiko perlu melakukan
Management Schmidt, R.C. 1998. "A Frameworks Risiko detil dan menyeluruh pengujian secara menyeluruh pada tahap
identifying Software Project Risk". di tahap awal. awal, jika tidak maka ketika risiko muncul di
Communications of The ACM tengah pelaksanaan proyek, maka akan
November 1998/Vol. 41 No. 11 berdampak pada biaya dan waktu yang
disepakati (tanpa daftar risiko dan
kuantifikasinya).
25
Tabel 2.2, lanjutan

19. RIS3 - Risk Barki, H. Rivard, S. and Talbot, J. Tanggapan atas Tanggapan atas Risiko Daftar risiko dan Risk Owner yang telah
Management "An Integrative Contingency Model Risiko sering menggantung dibuat tidak mendapatkan reaksi/tindakan
of Software Project Risk tanpa tindakan. konkrit, penerunan/mitigasi risiko, atau
Management". 2001. Journal of lainnya. Keadaan ini sebagai indikasi
Management Information Systems, buruknya tata-kelola risiko proyek.
Vol. 17, No. 4 (Spring, 2001), pp. 37-
69
20. SCO1 - Scope Young, R. Jordan, E. "Top Arahan Manajemen-atas tidak Ketika cakupan pekerjaan dinilai tidak dapat
Management management support: Mantra or Cakupan terlibat langsung dipenuhi karena keterbatasan anggaran dan
necessity?". International Journal of Pekerjaan dalam mengarahkan waktu, maka peran manajemen-atas sangat
Project Management (2008), cakupan pekerjaan. diperlukan sebagai penentu arah/kebijakan.
doi:10.1016/j.ijproman.2008.06.001 Tanpa peran tersebut, maka seringkali
anggota proyek tidak dapat memutuskan bila
cakupan perlu untuk dikurangi sebagai trade-
off waktu dan biaya.
21. SCO2 - Scope Meli, R. 1999. "Risk, Requirements Perubahan Permintaan perubahan Ketika client mengajukan permintaan
Management and Estimation of a Software Project". Permintaan yang berdampak pada perubahan yang menurut vendor akan
ESCOM-SCOPE 99 April27-29, biaya seringkali tidak berdampak pada perubahan rancangan yang
1999, disepakati oleh client. sudah ada, atau dampak pada penambahan
pekerjaan/biaya yang tidak direncanakan. Hal
tersebut sering tidak disetujui oleh client
terutama bila dampak pada tambahan biaya
proyek.
26
Tabel 2.2, lanjutan

22. SCO3 - Scope O. Shmueli, et al., 2014. "Explaining Permintaan Client seringkali Client seringkali menyampaikan permintaan
Management over-requirement in software Berlebih (Over- meminta fitur-fitur fitur-fitur yang dianggap 'nice-to-have' untuk
development projects: An requirement) yang tidak berkaitan mempermudah pekerjaan operasional mereka,
experimental investigation of langsung dengan akan tetapi tidak berkaitan langsung dengan
behavioral effects". International kebutuhan bisnis. kebutuhan bisnis, spt auto-loading non-
Journal of Project Management standard data, etc. Semakin banyak hal seperti
Manag.http://dx.doi.org/10.1016/j.ijp itu yang dipenuhi, maka proyek akan banyak
roman.2014.07.003 menyita waktu dan biaya untuk hal yang bukan
prioritas.
23. STA1 - Leonard, A. 2013. "Keeping in mind Hubungan Hubungan sosial dan Ketika hubungan sosial dan politik antara
Stakeholder the impact of social relationships Sosial Politik politik dengan client vendor dan client mengalamai masalah, maka
Management when managing software project bermasalah. unsur lain dalam proyek juga akan
teams". Procedia Technology 9 ( terpengaruh. Paling penting adalah faktor
2013 ) 767 – 776 kepercayaan yang harus terbangun lewat
hubungan sosial dan politik. Bila tidak ada
faktor kepercayaan, maka berdampak pada
keterlambatan di banyak proses.
24. STA2 - Nguyen, Q.M. 2006. "Planning in Keterlibatan Rendahnya Kegiatan requirement gathering merupakan
Stakeholder software project management: An Pemangku keterlibatan tahapan paling penting untuk bisa membuat
Management empirical research of software Kepentingan pengguna-kunci (key rancang dan implementasi lebih lanjut. Ketika
companies in Vietnam". Thesis of user) saat proses requirement gathering sering tertunda
The Faculty of Economics and Social requirement akibat minimnya keterlibatan key-user akan
Sciences at the University of gathering. berdampak pada jadwal proyek dan anggaran
Fribourg. proyek.
27
Tabel 2.2, lanjutan
25. TIM1 - Time Nidumolu, S. 1995. "The Effect of Ketergantungan Adanya permintaan Pendefinisian permintaan seringkali ditunda
Management Coordination and Uncertainty on Pada Pihak yang bergantung karena menyangkut pekerjaan oleh pihak ketiga.
Software Project Performance - Lain pada pekerjaan Perincian permintaan ditangguhkan karena
Residual Performance Risk as an pihak lain. bergantung pada system yang dilakukan pada
Intervening Variable". Information proyek lain oleh pihak ketiga. Client tidak
Systems Research, Vol. 6, No. 3 bersedia bila permintaan tersebut dikeluarkan
(September 1995), pp. 191-219 (out-of scope) dari cakupan walaupun dengan
batas waktu yang diberikan.
26. TIM2 - Time Jones, C. 2004. "Software Project Perencanaan Perencanaan proyek Perencanaan proyek seringkali memberikan
Management Management Practices - Failure versus Waktu tidak alokasi waktu untuk analisa kebutuhan yang
Success". mengantisipasi minim. Desain ingin segera dimulai secara paralel
Software Productivity Research LLC - perincian analisa meskipun rincian kebutuhan belum dapat
October 2004. kebutuhan. diselesaikan. Dampaknya adalah kemungkinan
pekerjaan desain yang berulang, bilamana terjadi
perubahaan permintaan ketika dirinci lebih lanjut.
1. YES/NO Yeo, K.T. 2002. “Critical failure factors Faktor Setujukah Anda bila proyek gagal diukur karena 'delay' atau kehabisan
in information system projects”. Sukses/Gagal anggaran?
International
Journal of Project Management Vol.20
2. YES/NO Savolainen, P et al. 2012. "Software Visi Proyek Setujukah Anda bahwa proyek harus terus dilanjutkan apapun risikonya,
development project success and failure karena sebagai penerapan visi/strategi bisnis?
from the suppliers perspective -A
systematic literature review".
International Journal of Project
Management 30 (2012) 458–469
28
2.1.4.1 Konsep Tata-kelola Komunikasi (Communication Management)
Tata kelola komunikasi sebagai segala bentuk pemindahan informasi mengenai
proyek antar pemangku kepentingan lewat berbagai metode dan media secara efektif
(sesuai bentuk, waktu, dan penerima) serta efisien dengan memberikan hanya
informasi yang diperlukan (PMI Inc, 2013).
Proyek sistem informasi tidak lepas dari adanya hubungan sosial dan politik
yang jika terganggu maka akan berpengaruh negatif pada keberhasilan proyek
(Leonard, 2013). Permindahan informasi juga tidak lepas dari dilematika keagenan
yang melahirkan asymmetric information dan terjadinya bias dalam laporan, terutama
ketika eskalasi masalah terjadi pada proyek. Manajemen-atas perlu membuat sebuah
sistem pendeteksi dini dalam menentukan kapan melakukan tindakan de-escalation
(koreksi atau teminasi) terhadap proyek bermasalah (Keil et al, 2000).
Budaya komunikasi yang terbuka perlu dibangun antara manajer proyek,
anggotanya, dan manajemen-atas agar masalah pada proyek dapat disampaikan tanpa
ada rasa takut akan hukuman (Kundi et al, 2007), serta tidak perlunya manajer
melakukan pembungkusan-pesan (framing) agar terus mendapat dukungan dan
menghindar dari persepsi buruk (Liang et al). Terhadap manajamen-atas, sikap positif
juga perlu ditunjukkan dengan menanggapi laporan masalah secara pro-aktif dan rasa
ingin tahu (Keil & Robey, 1999).
Budaya komunikasi yang baik, cara berinteraksi, dan hubungan sosial (formal
dan informal) yang lancar antar anggota tim proyek seperti bertukar dan berbagi
pengetahuan dapat mengantar kepada kesuksesan proyek, terlebih pada organisasi
29
berbasis-proyek yang padat dengan pola kerjasama dan pertukaran-pengetahuan
(Nelson, 2005).
2.1.4.2 Konsep Tata-kelola Biaya (Cost Management)
Pemangku-kepentingan akan mengukur biaya proyek dengan cara berbeda
serta pada saat yang berbeda. Penetapan anggaran sebagai proses agregat dari total
biaya setiap aktifitas yang akan dijadikan pijakan biaya (cost baseline) untuk
memantau dan mengendalikan kinerja proyek (PMI Inc, 2013).
Biaya adalah sesuatu yang ditentukan (given) sesuai dengan rencana total-
upaya dan sumber daya dalam nilai uang untuk memenuhi cakupan pekerjaan.
Kehabisan biaya sebagai salah satu alasan perusahaan menghentikan proyek sistem
informasi (Ewusi-Mensah, 1997 dalam Ferrat et al (2006). Pengelolaan keuangan
memerlukan kejelian karena menyangkut penggunaannya seefisien mungkin terhadap
segala kemungkinan risiko. Oleh sebab itu, manajer proyek harus memiliki keahlian
untuk menghadapi keadaan yang tidak dapat dihindari yaitu negosiasi (‘trade-off’)
antara biaya, waktu, dan cakupan pekerjaan, yang pada dasarnya adalah karena
keterbatasan biaya (Nelson, 2005).
Meskipun demikian, efisiensi biaya tidak seharusnya mengorbankan tugas-
tugas penting seperti tata-kelola pengetahuan yang merupakan aset penting terlebih
bagi organisasi berbasis proyek (Project-based Organization). Pekerjaan dan masalah
yang menumpuk serta tekanan deadline seringkali menyebabkan tidak diperhatikannya
aset pengetahuan, sedangkan manajemen pengetahuan terbukti berperan sangat
penting bagi efektifitas kerja proyek dan lebih jauh lagi adalah efektifitas organisasi
30
(Ajmal & Koskinen, 2008). Bagi perusahaan jasa perangkat lunak yang umumnya
berbentuk organisasi yang berbasis pada proyek, maka konsep pemanfaatan-ulang
(reusability) bergantung pada kematangan organisasi dalam membangun budaya alih-
pengetahuan baik yang bersifat tacit maupun eksplisit dokumen (Huber 1991, dalam
Ajmal & Koskinen, 2008).
2.1.4.3 Konsep Tata-kelola Sumber Daya Manusia (Human Resource

Management)
Pentingya tata-kelola jadwal karena menyangkut waktu yang tepat untuk
menarik dan melepas sumber daya manusia yang terbatas (scarce) ke/dari lingkungan
proyek yang dinamis (PMI Inc, 2013). Penambahan sumber daya manusia tidak lantas
dapat mempercepat penyelesaian tugas, karena masih bergantung pada kemampuan
individu serta waktu untuk pelatihan dan alih pengetahuan (M. André et al. 2011).
Tingginya rasio keluar-masuk (turn-over) anggota proyek, akusisi dan
asimilasi personil mempengaruhi lama waktu proyek, serta dampak pada biaya yang
tak terduga. Produktifitas anggota baru yang rendah serta proses asimilasi yang
mengurangi produktifitas anggota lama, sedikit atau banyak mempengaruhi kinerja
proyek (Abdel-Hamid, 1989). Bahkan lebih berpengaruh lagi, bila suksesi terjadi pada
manajer proyek. Oleh sebab itu, manajemen-atas perlu melakukan antisipasi terutama
pada proyek-proyek strategis (Abdel-Hamid, 1992).
Kesalahan dalam pemberian tugas dan masalah sosial antar tim proyek
teridentifikasi sebagai dua faktor penting yang mempengaruhi kesuksesan proyek (M.
André et al. 2011). Konflik sebagai hal yang tidak dapat dihindari dalam lingkungan
proyek sehingga menuntut perlunya terbangun budaya saling-percaya dan kerjasama.
31
Dengan demikian, proses pertukaran pengetahuan dan keahlian antara anggota akan
terjalin dengan baik (PMI Inc, 2013), sehingga terciptanya sumber daya manusia
dengan kemampuan yang dinamis.
Berangkat dari teori dynamic capabilities dan control theory seorang manajer
proyek diharapkan dapat memilih metode pengembangan aplikasi dan metode kendali
yang sejalan dengan tingginya tingkat ketidakpastian pada lingkungan proyek (Harris
et al, 2009), serta tuntutan fleksibilitas dan kompleksitas sumber daya manusia seperti
dalam virtual team, outsourcing, distributed location, dan sebagainya.
2.1.4.4 Konsep Tata-kelola Integrasi (Integration Management)
Piagam project (project charter) menggambarkan pernyataan pekerjaan
(statement of work) dengan latar belakang kebutuhan bisnis, rencana strategis, kasus-
bisnis (business-cases), serta kesepakatan-kesepakatan awal yang semuanya dijadikan
landasan untuk menghasilkan rencana tata-kelola manajemen (project management
plan). Tata-kelola integrasi proyek dibangun melalui hubungan antar proses serta
konsolidasi dengan semua knowledge area lainnya (PMI, 2013). Tujuan utamanya
adalah untuk menyeimbangkan keterbatasan proyek dan mencapai tujuan melalui
alternatif yang ada ketika interaksi proses antara knowledge area terjadi.
Umum sekali terjadi bahwa proyek berlangsung melebihi anggaran atau lewat
dari jadwal waktu yang direncanakan. Keadaan tersebut berdampak pada penilaian
bahwa proyek mengalami kegagalan secara proses (process failure) dari rencana
sasaran, harapan dan manfaat yang ingin dicapai (Yeo, 2002). Padahal, perkiraan awal
yang dibuat seringkali tidak sepenuhnya tepat, sedangkan manajer proyek ‘terpaksa’
32
berusaha mencapai sasaran yang tidak realistis tersebut. Rencana awal yang dibuat
atas dasar perkiraan mengenai sesuatu yang belum sepenuhnya jelas, sebaiknya tidak
dijadikan standar tunggal untuk mengukur kinerja manajer (Abdel-Hamid et al, 1999).
Dari sudut pandang vendor, persepsi tentang kesuksesan proyek adalah sangat
penting karena menyangkut reputasi dan hubungan bisnis jangka panjang, sehingga
ukuran keberhasilan seharusnya dilihat melalui visi bisnis yang lebih jauh (Patanakul
et al, 2012), dan proyek harus diselesaikan sebagai konsekuensi penerapan strategi
bisnis.
Rencana tata-kelola manajemen termasuk menentukan metode proyek yang
digunakan. Metodologi dipilih untuk menentukan karakteristik proses yang tepat,
seperti metodologi untuk proyek dengan tingkat ketidakpastian dan perubahan yang
tinggi (Maruping et al, 2009) yang disebabkan oleh keterbatasan pengetahuan
pengguna dalam mendefinisikan kebutuhan proyek berskala besar dan berisiko. Ferrat
et al (2006) memberikan gagasan agar dibuat sebuah business-case yang menjabarkan
maksud dan tujuan proyek serta usulan bentuk contoh/model hasil proyek.
Contoh/model tersebut dapat diambil dari best-practice yang telah banyak digunakan.
Tata-kelola integrasi perlu memperhatikan faktor-faktor lingkungan
perusahaan (“enterprise environmental factors”) yang dapat berpengaruh baik atau
buruk pada proyek, antara lain mengenai kanal komunikasi dengan manajemen-atas
serta tingkat toleransi pemangku kepentingan terhadap risiko (PMI Inc, 2013).
Keterlibatan manajemen-atas dianggap penting dalam mewarnai budaya kerja proyek
33
melalui dukungan, motivasi, dan sikap yang toleran terhadap risiko yang dihadapi tim
proyek (V.C. Gu et al, 2014). Manajemen-atas perlu memberikan pemahaman tentang
strategi proyek yang harus sejalan dengan strategi bisnis seperti keunggulan produk,
time-to-market, atau keintiman dengan pengguna-akhir (Patanakul et al, 2012).
Kesuksesan proyek bergantung pada kualitas keterlibatan manajemen-atas, terutama
peran untuk mengarahkan bila terjadi perbedaan antara kepentingan pengguna
(harapan) antara kebutuhan bisnis (business requirement) (Young & Jordan, 2008).
2.1.4.5 Konsep Tata-kelola Pengadaan Barang (Procurement Management)
Kontrak kerja harus mencakup butir-butir pekerjaan yang cukup detil agar
terhindar dari adanya kesalahpahaman dalam penawaran harga. Perbedaan yang
mencolok dalam perkiraan biaya (atau penawaran harga) sebagai indikator kelemahan,
ambiguitas, kesalahpahaman dalam memahami cakupan pekerjaan (statement of
work). Kontrak juga menetapkan termin dan persyaratan yang dijadikan masukan oleh
vendor untuk menentukan proses pelaksanaan proyek (PMI Inc, 2013).
Persaingan untuk memenangkan proyek oleh vendor berpengaruh pada proses
penawaran harga. Strategi Price-to-win yang digunakan vendor memiliki tingkat
keakuratan yang rendah dibandingkan bila perkiraan biaya dibuat menggunakan
metode perkiraan biaya yang sudah dikenal (Heemstra, 1992). Strategi tersebut tidak
melakukan perhitungan murni berdasarkan pada beban/upaya sesuai besar permintaan,
akan tetapi menjadikan perkiraan anggaran milik pembeli (buyer/owner estimates)
sebagai acuan penawaran harga agar tepat pada angka tersebut (Sommervile, 2004).
34
Pembeli menetapkan termin dan persyaratan untuk melindungi mereka dari
risiko kegagalan proyek, terutama dalam hal pembayaran. Model termin pembayaran
diduga berpengaruh kepada prilaku manajer proyek dalam mendefinisikan proses
kegiatan proyek (Clark & O’Connor, 2012), terutama terhadap pencapaian milestone
yang dipantau terus menerus oleh manajemen atas.
2.1.4.6 Konsep Tata-kelola Kualitas (Quality Management)
Biaya untuk menjamin mutu (cost of quality) adalah bentuk kebijakan investasi
untuk menghindari kesalahan melalui proses pengesahan deliverables, dan untuk
memperbaiki temuan cacat pada produk pasca-proyek (PMI Inc, 2013).
Proses pengawasan dan kendali mutu berada di antara kepentingan
manajemen-atas terkait efisiensi anggaran, serta kepentingan menjaga kualitas produk.
Produk yang gagal tidak dapat memenuhi kriteria uji-terima oleh pengguna, atau tidak
mampu mendukung tuntutan operasional.
Sebuah penelitian mengenai nilai ekonomis biaya untuk menjamin mutu
(quality assurance) menunjukkan angka optimal pada 16% dari total proyek yang
merupakan sebuah pilihan kebijakan karena dampaknya terhadap total biaya proyek
(Abdel-Hamid, 1987).
2.1.4.7 Konsep Tata-kelola Risiko (Risk Management)
Risiko dianggap sebagai efek ketidakpastian untuk mencapai tujuan akibat
suatu sebab yang memberikan dampak pada cakupan, jadwal, biaya, dan kualitas.
Proses mengenali risiko harus dilakukan terus-menerus, dan bila telah diketahui maka
35
harus ditanggapi dengan terencana (risk taking or risk avoidance), dan bila berdampak
negatif maka perlu diangkat menjadi sebuah isu proyek dalam bentuk daftar risiko
(risk register) dan laporan yang perlu dikomunikasikan secara terbuka dan jujur (PMI
Inc, 2013).
Pengelolaan risiko yang tidak terintegrasi sejak awal proyek akan
memperburuk keadaan kehabisan anggaran (over-budget) (Islam et al, 2014). Strategi
menanggapi risiko harus mencakup pengujian apakah rencana tindakan dapat berhasil
secara teknis, dan apakah hasilnya dapat diterima oleh pengguna (Keil, 1995).
Kegiatan tersebut harus dilakukan oleh manajer proyek secara menyeluruh dan
mendalam agar ditemukan strategi yang paling efektif untuk setiap risiko (Keil et al,
1998).
Dalam tata-kelola ini, perlu dibuat indikator dan metric untuk setiap risiko agar
dapat diketahui masih ada atau tidaknya risiko tersebut berdasarkan indikatornya,
misalkan risiko rendahnya keterlibatan pengguna dengan indikator jumlah rencana
pertemuan yang gagal (Kasser & William, 1998). Terlebih penting lagi indikator
terhadap risiko-tinggi (Risk Exposure) yang perlu mendapat keputusan dari
manajemen-atas sesuai dengan kesepakatan tata-kelola risiko agar tidak terus
menggantung (Barki et al, 2001).
2.1.4.8 Konsep Tata-kelola Cakupan (Scope Management)
Rencana tata-kelola cakupan yang telah dibuat dirinci dalam kegiatan
pembuatan spesifikasi kebutuhan akan menghasilkan antara lain daftar dokumen-
dokumen kebutuhan, pijakan cakupan, serta daftar perubahan permintaan (PMI Inc,
36
2013). Cakupan pekerjaan merupakan topik paling penting karena sebagai dasar
penghitungan biaya serta penetapan jadwal proyek. Meli (1999) menyimpulkan
bahwa dua buah proses yang paling strategis adalah mengelola permintaan pengguna,
serta memperkirakan dengan tepat sumber daya bagi permintaan tersebut. Adapun
permintaan perubahan, atau tambahan cakupan harus dipertimbangkan karena
menyangkut risiko berubahnya biaya dan jadwal yang perlu persetujuan kembali oleh
manajemen. O. Shmueli et al. (2014) mengingatkan juga bahwa mengelola permintaan
termasuk menghindari adanya permintaan yang berlebih (over-requirement) dari
kebutuhan bisnis sebenarnya, termasuk seleksi atas fitur-fitur yang sangat diperlukan
saja, dan tidak larut pada emosi untuk menyenangkan pengguna dengan fitur yang
bersifat ‘kosmetik’ (nice-to-have).
2.1.4.9 Konsep Tata-kelola Pemangku Kepentingan (Stakeholder Management)
Terkait dengan pentingnya pengaruh pemangku-kepentingan (stakeholder)
untuk mencapai keberhasilan, Simon (2011:17) dalam bukunya “Why new systems
fail” meberikan jawaban singkat bagi sekian banyak pertanyaan mengenai penyebab
kegagalan, yaitu “manusia (people)”, yang tidak lain adalah pemangku kepentingan
(stake-holder) dan hubungan antar mereka. Seiring dengan pernyataan tersebut,
Project Management Institute (2013:30) dalam topik mengenai hubungan antara
proyek dan pemangku kepentingan (internal maupun eksternal) menggambarkan
hubungan tersebut seperti pada diagram di bawah:
37
Gambar 2.3: The Relationship Between Stakeholders and the Project
Sumber: PMI Inc, PMBoK Guide (2013)
Di antara pemangku kepentingan tersebut ada yang secara aktif maupun pasif
mempengaruhi kesuksesan atau kegagalan proyek. Dengan demikian, manajer proyek
harus melakukan identifikasi pengaruh dari setiap pemangku kepentingan terhadap
proyek secara terus-menerus.
Prinsip tata-kelola pemangku kepentingan adalah menciptakan dan menjaga
hubungan baik dengan cara memberikan kepuasan dalam hal kebutuhan dan
permintaan yang sesuai dengan batasan proyek. Disamping itu, konflik kepentingan
antara pemangku kepentingan perlu dikenali terus-menerus sesuai prioritas serta
tingkat otoritas mereka yang mempengaruhi kesuksesan proyek (PMI Inc, 2013).
Hasil studi oleh Nguyen (2006) menunjukkan implikasi praktis bagi manajer
proyek berupa perlunya membangun hubungan dan kepuasan dengan cara melibatkan
pemangku kepentingan sejak tahap paling awal, yaitu proses pendefinisian permintaan
dan pembatasannya agar tidak terjadi perubahan. Implikasi praktis tersebut sebagai
konsekuensi logis dari temuan bahwa para manajer proyek lebih memilih kriteria yang
38
secara urut yaitu: kepuasan pelanggan, kualitas pekerjaan, serta proyek yang tepat-
waktu dan sesuai-anggaran sebagai ukuran kinerja mereka. Pada urutan tersebut,
kepuasan pelanggan diletakkan sebagai kriteria pertama, yang tidak lain adalah
pemangku kepentingan.
Meskipun demikian, hubungan yang baik dengan pemangku kepentingan
terutama manajemen-atas dan sponsor proyek harus berlaku secara wajar, agar ketika
masalah kritis terjadi, mereka tetap harus melakukan tindakan korektif. Pengaruh
dukungan psikologis oleh manajemen-atas serta ditambah lagi dengan sifat perangkat
lunak yang intangible, menjadikan sulit bagi manajemen-atas untuk menilai kinerja
proyek yang sebenarnya berdasarkan laporan. Komitmen dan dukungan berlebih yang
tidak wajar terhadap proyek bermasalah seharusnya tidak terjadi (Keil et al, 1995).
2.1.4.10 Konsep Tata-kelola waktu (Time Management)
Pembuatan jadwal memperhatikan semua rincian aktifitas, lama waktu, dan
saling-ketergantungannya, serta milestone proyek. Pengelolaan waktu akan sangat
terganggu ketika dokumen spesifikasi permintaan tidak selesai tepat waktu serta
berlarut-larut disebabkan antara lain ketergantungan kegiatan tersebut pada
keterlibatan pengguna kunci (Turner, 1992 dalam Nidumolu, 1995).
Pada beberapa kasus, risiko perencanaan waktu yang salah dapat berakibat
pada keterlambatan yang menyebabkan pembatalan proyek karena sudah hilangnya
momentum. Keterlambatan terjadi antara lain karena tidak adanya proses yang efektif,
seperti pada: penjabaran rinci tentang permintaan; perubahan permintaan; keluar-
39
masuknya anggota tim; serta minimnya waktu untuk kegiatan kendali dan uji mutu
(Jones, 2004).
2.1.5. Perangkat Lunak (Software)
Perangkat lunak (software) dapat didefinisikan sebagai rangkaian kesatuan
instruksi-instruksi komputer yang disebut program yang mengatur dan mengendalikan
kerja dari sistem komputer. Perangkat lunak komersial yang umumnya dikerjakan
untuk keperluan fungsi bisnis tertentu adalah perangkat lunak paket (package) yang
dapat digunakan secara luas oleh perusahaan-perusahaan yang mencakup aspek
dokumentasi, pelatihan, dan pelayanan pemeliharaan (Brown, 2012).
Instruksi-instruksi perangkat lunak dibuat dan direkayasa sesuai kebutuhan dan
permintaan bisnis. Saat ini dengan berkembangnya teknologi pengembangan
perangkat lunak, upaya penggunaan ulang (reusability) komponen-komponen
perangkat lunak mengalami peningkatan agar terjadinya proses standarisasi dan
perbaikan kualitas.
Gambar 2.4: The Software Iceberg

Sumber: Managing Information Technoglogy (Brown 2012)
40
Brown (2012) mengkategorikan perangkat lunak menjadi 2 jenis: perangkat
lunak aplikasi (application software) yang dibuat untuk membantu pengguna dalam
bisnis, dalam bentuk perangkat lunak paket package customized seperti CRM,
Accounting, ataupun off-the-shelf seperti Email dan sebagainya. Jenis kedua yaitu
perangkat lunak pendukung (support software/system software) sebagai program yang
dibuat untuk mendukung proses pembuatan applicaton software, seperti Operating
System, Database, compiler, dan lainnya yang dibuat oleh perusahaan terbatas saja.
Penelitian ini difokuskan pada perangkat lunak jenis pertama, yaitu perangkat
lunak aplikasi yang dikembangkan sesuai kebutuhan bisnis (customized) yang
memiliki kecirian tersendiri antara satu perusahaan dengan perusahaan lainnya.
2.1.6. Metodologi Pengembangan Perangkat Lunak
Metodologi pengembangan perangkat lunak dibuat dengan tujuan untuk
mengatur dan mengendalikan proyek agar berjalan sesuai dengan batasan-batasan
yang ada, namun tetap memenuhi tuntutan hasil yang diinginkan baik dari segi
cakupan maupun kualitas yang diharapkan.
Metodologi umum yang digunakan dalam pengembangan perangkat lunak
yang disebut SDLC (System/Software Development Life-Cycle) yang memiliki tahapan
secara ringkas yaitu: (1) Pendefinisian kebutuhan (2) Konstruksi sistem dalam bentuk
disain, pembuatan, dan pengujian, serta (3) Penerapan melalui pemasangan,
pengoperasian, dan pemeliharaan (Brown, 2012).
41
Gambar 2.5: Fase dan Tahapan SDLC
Sumber: Managing Information Technoglogy (Brown 2012)
Beberapa metode lain yang banyak digunakan antara lain Metode Prototipe
(Prototyping Methodology), Rapid Application Development (RAD), Agile
Methodology, dan sebagainya yang masing-masing memiliki kelebihan dan
kekurangan yang dipilih dan digunakan sesuai dengan karakteristik proyek dan
tantangannya. Penelitian ini tidak akan membahas secara mendalam setiap metode
yang ada, akan tetapi lebih pada aspek strategi manajemen proyek yang menentukan
metode yang tepat untuk digunakan untuk keberhasilan proyek.
42
AB III. METODE PENELITIAN
3.1 Jenis Penelitian
Penelitian menggunakan pendekatan eksploratif terhadap beberapa variabel
yang diangkat dari beberapa jurnal penelitian sebelumnya yang diuraikan pada Bab-II
yang membahas mengenai proyek perangkat lunak. Observasi secara kualitatif
dilakukan terhadap responden dengan menggunakan instrumen survei untuk
menghasilkan data empiris, kemudian analisis induktif akan dilakukan terhadap data
tersebut dengan metode statistik Analisa Faktor dan Regresi.
3.2 Lokasi dan Waktu Penelitian
Penelitian menggunakan data primer melalui survei terhadap responden yang
bekerja di industri perangkat lunak di Jakarta, dengan latar belakang pengalaman
responden berasal dari berbagai perusahaan baik di dalam maupun di luar negeri.
Waktu pengumpulan data dilakukan mulai tanggal 22 September 2014 s/d 21
Oktober 2014 dengan tingkat partisipasi survei sebanyak 90 orang responden.
Gambar 3.1: Grafik Waktu Pengumpulan Data

Sumber: Summary Report www.surveymonkey.com
43
3.3 Sampel Penelitian
Pengumpulan data survei terhadap 90 orang responden dilakukan secara
purposive-sampling dan teknik snow-balling yaitu pemilihan responden yang memang
benar-benar dapat memberikan jawaban berdasarkan adanya pengalaman sebelumnya.
Tahap pengujian instrumen dilakukan sebelum proses pengumpulan data, yaitu
dengan mengirimkan instrumen kuesioner kepada 2 orang responden dengan latar
belakang yang diharapkan. Komentar dan masukan pada pre-test tersebut yaitu agar
kuesioner diberikan penegasan tujuan penelitian serta pendefinisian istilah, dan usulan
perubahan bentuk pertanyaan/pernyataan. Perbaikan terhadap rancangan kuesioner
dilakukan berdasarkan masukan tersebut.
3.4 Pengumpulan Data
Pengumpulan data dilakukan melalui instrumen kuesioner yang diisikan oleh
responden secara self-administered melalui web-site dengan alamat internet
(https://www.surveymonkey.net/s/mmugm_thesis_survey) selama rentang waktu
tersebut di atas.
Data yang tidak benar (invalid) sebanyak 2 buah telah dikeluarkan yang
kemungkinan berasal dari sumber yang sama yaitu dengan indikasi berupa jawaban
yang identik (redundansi) yang mungkin terkirim dua kali pada waktu (menit) yang
sangat berdekatan.
44
3.5 Definisi Istilah/Operasional
Beberapa definisi operasional yang dipakai dalam penelitian ini antar lain:
Tabel 3.1: Definisi Operasional
No. Istilah Definisi
1. Analisis pada Proyek  Adanya hubungan antara buyer dengan

perangkat lunak supplier/vendor, yaitu customer/client/user
(penelitian ini) menyerahkan proyek kepada vendor
(external/contract/outsource);
 Proyek yang dinilai adalah dengan jangka waktu
3 bulan atau lebih;
 Software dalam pengertian perangkat lunak
secara umum untuk keperluan bisnis
perusahaan.
2. Proyek Bermasalah Proyek bermasalah diartikan sebagai proyek yang

mengalami kondisi over-budget dan/atau over-
schedule.
3. Over-budget dan/atau Keadaan ketika proyek belum selesai sedangkan

over-schedule anggaran dan jadwal telah terlampaui dari rencana,
yang berdampak pada aspek keuangan dan bisnis.
4. Vendor atau supplier Perusahaan penyedia jasa pengerjaan proyek

perangkat lunak.
5. Customer/client/user Perusahaan beserta karyawannya yang

mempercayakan pekerjaan proyek perangkat lunak
kepada vendor atau supplier.
6. Manajemen Proyek Tata kelola proyek yang pada penelitian ini banyak
mengacu pada PM-BOK (Project Management
Body of Knowledge)
Sumber: Definisi dibuat oleh peneliti
45
Variabel penelitian dibangun berdasarkan observasi pada jurnal-jurnal yang
ada. Hasil observasi terhadap jurnal tersebut menghasilkan sebanyak 26 indikator.
Variabel penelitian dalam 26 indikator tersebut seperti yang dijelaskan dalam Bab II
tabel 2.2 (Konsep, Indikator, dan Referensi Jurnal).
Indikator dalam tabel tersebut dikelompokkan dengan asumsi awal berdasarkan
pada konsep Project Management Body of Knowledge yang terdiri dari 10 Knowledge
Area. Pengelompokan akan dibentuk ulang melalui proses Analisa Faktor dengan
metode Analisa Komponen Utama.
3.6 Aspek Pengukuran
Pengukuran dilakukan terhadap hasil kuesioner yang terdiri dari 2 (dua) bentuk
pertanyaan, yaitu:
1) Pertanyaan Inti yaitu pengukuran hasil kuesioner dilakukan terhadap dua
variabel, yaitu satu buah variabel terikat (dependent variable) serta 26 buah
variabel amatan bebas (independent variable) yang semuanya dalam skala
ordinal.
a. Variabel terikat yaitu skala Tingkat Masalah yang pernah dialami
responden, yaitu: 1= Tidak ada s/d 10= Sangat Banyak.
b. Variabel bebas yang terdiri dari 26 indikator yang akan diproses
dengan pendekatan analisis faktor terhadap nilai isian yang bersifat
nonmetric (ordinal) Skala Likert dalam 5 ukuran yang diberikan
skor 1 sampai dengan 5, yaitu: Sangat Tidak Setuju (1), Tidak
Setuju (2), Netral (3), Setuju (4), dan Sangat Setuju (5).
46
2) Pertanyaan Tambahan yaitu kuesioner dengan bentuk tertutup (Ya/Tidak)
yang menanyakan persetujuan responden mengenai ukuran kegagalan
proyek, serta sikap yang perlu diambil manajemen terhadap proyek yang
bermasalah. Responden juga diberikan kesempatan untuk memberikan
komentar tambahan untuk menjelaskan alasan pilihannya. Kesimpulan atas
jawaban jenis ini dilakukan melalui analisis isi jawaban.
3.7 Metode Analisis Data
Untuk menjawab pertanyaan penelitian pertama, jenis analisa yang akan
dilakukan adalah terhadap interdependence variables sebanyak 26 variabel yaitu
dengan metode Eksplorasi Analisis Faktor (Exploratory Factor Analysis). Analisa
Faktor bertujuan untuk melakukan pengurangan sejumlah besar variabel menjadi
jumlah yang lebih kecil yang membentuk kesamaan karakteristik ukuran yang
memiliki tingkat saling-berkorelasi (intercorrelation matrix) kemudian membentuk
sejumlah gabungan variabel (komponen utama) yang akhirnya tidak saling berkorelasi.
Kombinasi gabungan variabel tersebut disebut dengan Factor yang akan terbentuk
secara urut mulai dari kombinasi linear terbaik (Cooper & Schindler, 2008:562), yang
sering juga disebut sebagai variabel laten (non-observable variable atau construct).
Metode analisa komponen utama (PCA) akan dijalankan melalui tahapan
pengujian reliabilitas dan validitas terlebih dahulu, sebagai berikut:
1) Uji Kehandalan Data (Reliability) terhadap hasil survei dengan tujuan
mengeluarkan data yang tidak lengkap sebelum dihasilkan nilai Cronbach's
Alpha dengan tingkat signifikansi 5% (0,05).
47
2) Uji Ukuran Kecukupan Sampel dengan nilai kecukupan berdasarkan pada
Kaiser-Meyer-Olkin (KMO) dengan target nilai di atas > 0,5.
3) Uji nilai signifikan dengan Bartlett's Test of Sphericity untuk membuktikan
tidak adanya matriks identitas sehingga analisis faktor dapat dilanjutkan,
yaitu dengan nilai signifikansi mendekati 0 (nol).
4) Uji Kecukupan Sampel dengan MSA – Measure of Sampling Adequacy
yang berdasarkan indikasi Anti-image Correlation digunakan untuk
mengeluarkan variabel yang memiliki nilai “anti-image” < 0,5 yang
dianggap tidak dapat digunakan dalam analisa faktor.
5) Ekstrak Pengurangan Faktor melalui metode analisa komponen utama
(PCA – Principal Component Analysis) yang secara apriori membiarkan
pengelompokan variabel-variabel laten terjadi sebagai manifestasi dari
variabels covarian dengan mempertahankan variabel yang memiliki nilai
Eigenvalue >= 1.
6) Interpretasi (penamaan) faktor melalui observasi sub-faktornya yang
merupakan hasil dari proses rotasi komponen dengan metode Varimax.
Selanjutnya untuk menjawab pertanyaan penelitian kedua, yaitu menggunakan
regresi linear berganda dengan lebih dari satu independent variables. Analisa regresi
merupakan metode yang digunakan untuk memantau nilai pada independent variabel
untuk memperkirakan nilai dependent variable yang menghasilkan fungsi yang terdiri
dari beberapa predictors atau disebut model regresi dalam bentuk persamaan dengan
nilai-nilai koefisien regresi (slope and intercept) (Cooper & Schindler, 2008:519).
48
Alat bantu yang digunakan untuk menghasilkan laporan analisis data berupa
tabel-tabel dan gambar-gambar dilakukan dengan perangkat lunak SPSS versi 20 dan
Microsoft Excel.
3.8 Analisis Kelengkapan Data
Perbaikan data perlu dilakukan untuk menghindari ditolaknya data oleh SPSS
karena ketidaklengkapan isian untuk variabel yang menggunakan nilai ordinal dalam
skala Likert 1 s/d 5. Pada beberapa data dalam 26 variabel yang tidak diberikan nilai
oleh responden, maka akan ditandai terlebih dahulu kemudian dilengkapi dengan nilai
3 = Netral.
3.9 Alur Diagram Penelitian
Diagram di bawah ini menggambarkan tahapan penelitian yang dilakukan
secara umum pada proses penelitian kualitatif (Cooper & Schindler, 2008:167):
49
Meneumukan Dilema Manajemen
Proposal Masalah dan Topik Penelitian
Kajian literatur dan seleksi
Desain instrumen penelitian

Desain kuesioner Rencana Pengumpulan Sampel
Pengujian instrumen
Test Awal (pre-test) Perbaikan kuesioner
Peluncuran Instrumen & Pengumpulan data
Pengujian, analisa dan Interpretasi Data
Kesimpulan dan Saran
Gambar 3.2: Alur Diagram Penelitian

Sumber: Diagram disusun oleh peneliti
50
BAB IV. HASIL PENELITIAN
Bab ini menjelaskan hasil temuan serta proses analisis statistik berupa validasi,
korelasi, analisa faktor, serta regresi linear untuk menemukan jawaban atas pertanyaan
penelitian.
4.1 Gambaran Responden
Responden yang terdiri dari 90 orang, terwakili dalam beberapa kategori
berdasarkan jawaban atas latar belakang mereka, seperti lama pengalaman kerja, peran
yang pernah dijalani, serta pengalaman menghadapi masalah dalam proyek.
4.1.1 Pengalaman Bekerja
Sebagai jawaban atas pertanyaan “Lama pengalaman terlibat dalam proyek
software/information technology ?”, maka grafik di bawah menunjukkan bahwa
mayoritas responden yaitu 58 orang (64%) memiliki pengalaman lebih dari 10 tahun.
Gambar 4.1: Lama Pengalaman Bekerja

Sumber: Hasil Pengolahan MS-Excel
51
Adapun latar belakang pengalaman responden untuk pertanyaan “Jabatan
sekarang dan yang pernah dijalani (bisa pilih lebih dari satu)”, tergambar pada grafik
di bawah ini:
Gambar 4.2: Latar Belakang Pengalaman

Sumber: Hasil Laporan www.surveymonkey.com
Grafik menunjukkan 60% responden pernah menjalani peran/tugas sebagai
Manajer Proyek dan Konsultan/Spesialis. Kedua peran tersebut dianggap memenuhi
harapan purposive sampling dengan pertimbangan bahwa jabatan dan pengalaman
52
tersebut memberikan kemampuan menjawab pertanyaan berdasarkan pengetahuan
terhadap problematika sebuah proyek perangkat lunak.
4.1.2 Pengalaman Tentang Masalah
Terhadap pertanyaan “Pernah mengalami masalah dalam proyek?”, hasil
menunjukkan adanya dukungan data yang diperoleh dari sampel dengan mayoritas
yaitu 87 orang (97%) mengakui telah mengalami masalah dalam proyek perangkat
lunak, yaitu:
Tidak 3
Ya 87
0 20 40 60 80 100
Gambar 4.3: Pernah Mengalami Masalah

Sumber: Hasil Proses MS Excel
Analisis mengenai pernah atau tidaknya responden mengalami masalah:
1) Di antara responden yang menjawab “Ya”, sebanyak 55 responden pernah/
sedang berperan sebagai manajer proyek, adapun lainnya berperan dalam
tugas lainnya seperti pada tabel sebelumnya.
53
2) Terhadap 3 orang responden yang menjawab “Tidak” pernah mengalami
masalah dalam proyek: 1 responden bekerja sebagai manajer proyek, dan 1
responden sebagai IS auditor, serta 1 responden bekerja dalam peran
lainnya. Meskipun ketiga responden tersebut menyatakan tidak pernah
mengalami proyek bermasalah, akan tetapi mereka memberikan nilai skala
ordinal pada 26 variabel (dengan jawaban antara 5 – 7) untuk pertanyaan
mengenai intensitas masalah. Jawaban tersebut memberikan dugaan dua
kemungkinan sebagai berikut:
a. Kemungkinan pertama, bahwa responden yang bersangkutan
memang tidak pernah mengalami masalah, namun mengetahui
terjadinya masalah dari sumber lain.
b. Kemungkinan kedua, bahwa responden sebenarnya pernah
mengalami masalah, karena menjawab seluruh variabel, namun
tidak mengkaitkan dengan konteks/definisi bahwa proyek
bermasalah diukur oleh keterlambatan jadwal atau melebihi
anggaran yang direncanakan yang terwakili oleh 26 variabel.
Keputusan: Penelitian ini akan memasukkan data 3 responden tersebut dalam
analisa, dengan pertimbangan lain adanya keragaman jawaban mereka
terhadap 26 variabel observasi yang ditanyakan.
54
4.1.3 Penilaian Tingkat Masalah
Penilaian terhadap skala tingkat/besarnya masalah sebagai jawaban atas
pertanyaan: “Secara rentang (interval), berapa banyak permasalahan dalam proyek
perangkat lunak menurut Anda? (1= Tidak ada s/d 10= Sangat Banyak)”, hasil
menunjukkan bobot cenderung ke arah kanan yaitu masalah proyek perangkat lunak
diakui lebih dari rata-rata – nilai tengah).
Nilai tengah
Tidak ada masalah Masalah sangat banyak
Gambar 4.4: Persepsi Tingkat Masalah

Sumber: surveymonkey.com dan modifikasi grafik oleh peneliti
Pengetahuan atas permasalahan tersebut terjadi ketika bekerja pada tipe
organisasi yang dibedakan dalam vendor dan customer/user. Sebanyak 60% jawaban
adalah “keduanya” yang menunjukkan bahwa mayoritas responden pernah bekerja
pada kedua tipe organisasi. Gambar di bawah ini menunjukkan hasil tersebut untuk
pertanyaan: “Pengalaman masalah tersebut ketika bekerja pada?”:
55
Gambar 4.5: Tipe Organisasi Responden
Sumber: Laporan www.surveymonkey.com
4.1.4 Statistik Deskriptif Variabel Penelitian
Sebelum membahas tujuan penelitian pertama, analisis statistic descriptive
terhadap terhadap 26 variabel (indikator) sesuai hasil sesuai tabel berikut:
Tabel 4.1: Statistik Deskriptif Variabel Penelitian

No Kode Pernyataan Mean Median Mode Std.
Dev.
1. COM1 Masalah dan risiko proyek tidak 4.3 4 4 0.74
disampaikan sepenuhnya.
2. COM2 Kesepakatan rencana komunikasi 4.2 4 4 0.61
(communication plan) tidak berjalan
efektif.
3. COM3 Manajemen tidak menguji keakuratan 3.8 4 4 0.79
laporan kinerja proyek.
4. COS1 Customer tidak bersedia mengurangi 3.7 4 4 1.01
'scope'.
5. HUM1 Komunikasi verbal tim internal proyek 3.8 4 4 0.89
tidak lancar.
6. HUM2 Pelatihan bagi anggota baru dilakukan 3.0 3 3 0.91
oleh anggota lama.
7. HUM3 Terjadi suksesi pada proyek manajer, atau 3.5 4 4 0.86
sponsor proyek.
Sumber: Pengolahan oleh peneliti dengan MS Excel
56
Tabel 4.1, lanjutan
Dev.
8. HUM4 Terjadi masalah dalam internal tim karena 3.6 4 4 0.85
ketimpangan (kesalahan) dalam
pembagian tugas.
9. INT1 Manajer proyek tidak mampu menangani 4.0 4 4 0.87
lingkungan proyek yang tidak pasti.
10. INT2 Salah memilih metode untuk proyek 3.6 4 4 0.95
dengan tingkat perubahan permintaan
yang tinggi.
11. INT3 Customer tidak memiliki contoh konkrit 3.5 4 4 0.94
tentang hasil dari proyek yang akan
dibuat.
12. INT4 Tujuan proyek dianggap tidak realistik 3.5 4 4 0.97
oleh manajer proyek.
13. INT5 Tata-kelola proyek tidak disesuaikan 3.4 4 4 0.91
dengan strategi bisnis (seperti:
keunggulan produk, atau time-to-market).
14. PRO1 Terjadi perilaku 'under-estimate' oleh 4.1 4 5 1.03
vendor untuk memenangkan tender.
15. PRO2 Terjadi selisih yang jauh antara anggaran 3.5 4 3 0.97
buyer dengan harga oleh vendor.
16. QUA1 Anggaran untuk Quality Assurance sangat 3.6 4 4 0.87
terbatas.
17. RIS1 Manajemen-atas tidak toleran mengenai 3.6 4 4 0.95
kemungkinan/dampak risiko.
18. RIS2 Pengujian risiko tidak detil dan 3.9 4 4 0.79
menyeluruh di tahap awal.
19. RIS3 Tanggapan atas Risiko sering 4.0 4 4 0.81
menggantung tanpa tindakan.
20. SCO1 Manajemen-atas tidak terlibat langsung 3.9 4 4 0.86
dalam mengarahkan cakupan pekerjaan.
21. SCO2 Permintaan perubahan yang berdampak 4.0 4 4 0.78
pada biaya seringkali tidak disepakati
oleh client.
22. SCO3 Client seringkali meminta fitur-fitur yang 4.0 4 4 0.83
tidak berkaitan langsung dengan
kebutuhan bisnis.
23. STA1 Hubungan sosial dan politik dengan client 3.7 4 4 0.99
bermasalah.
57
Tabel 4.1, lanjutan
Dev.
24. STA2 Rendahnya keterlibatan pengguna-kunci 4.3 4 5 0.92
(key user) saat requirement gathering.
25. TIM1 Adanya permintaan yang bergantung 3.7 4 4 0.86
pada pekerjaan pihak lain.
26. TIM2 Perencanaan proyek tidak mengantisipasi 3.8 4 4 0.75
perincian analisa kebutuhan.
Tabel menunjukkan bahwa umumnya variabel memiliki nilai MEDIAN = 4,
serta didukung oleh grafik batang yang condong ke arah kanan (Setuju=4, dan Sangat
Setuju=5), berarti pernyataan kuesioner disetujui sebagai indikator masalah proyek.
Histogram Statistik pada Gambar 4.6 yang merupakan representasi dari
keseluruhan nilai/skor jawaban variabel (90 sampel x 26 item) dalam grafik batang
memberikan indikasi bahwa sebagian besar 1135 (48,5%) responden “setuju” bahwa
variabel kuesioner sebagai indikator penyebab kegagalan proyek.
Gambar 4.6: Grafik Histogram Total Variabel

Sumber: Hasil proses peneliti dengan MS Excel
58
Adapun grafik batang pada Gambar 4.7 untuk seluruh 26 variabel yang
menggambarkan kesan kecenderungan (skewness) jawaban responden antara skor 1
(sangat tidak setuju) sampai 5 (sangat setuju), mendukung kecenderungan jawaban
responden yaitu ke arah atas (skor 3 – 5). Pada grafik dalam skala 0 - 100 akan lebih
tampak arah dominan jawaban tersebut pada variabel COM2, COM3, HUM4, RIS2,
RIS3, SCO1, SCO2, TIM2, seperti pada gambar di bawah ini:
Gambar 4.7: Grafik Histogram Setiap Variabel

Sumber: Hasil proses peneliti dengan MS Excel
59
Hasil lengkap statistik deskriptif terhadap 26 variabel di atas terdapat pada
Lampiran 2 – Statistik Deskriptif 26 Variabel.
4.2 Keterbatasan Penelitian
Penelitian ini merupakan penelitian sesaat yang dilakukan terhadap responden
yang sebagian besar berada di Jakarta. Responden memiliki latar belakang pekerjaan
dari berbagai industri, seperti telekomunikasi, perbankan, sektor publik, dan
sebagainya.
Pada penelitian sesaat ini dengan data yang terbatas, peneliti menggunakan
fungsi regresi hanya untuk mengambil model persamaan, tidak memperhatikan nilai
statistik R-square yang diharapkan akan meningkat sejalan dengan adanya data-data
baru dengan penelitian berkelanjutan (time-series).
4.3 Bahasan Tujuan Penelitian Pertama
Untuk mendapatkan jawaban penelitian pertama, beberapa tahap akan
dilakukan antara lain tes ketangguhan data (reliability), validitas, serta analisa faktor.
Metode analisa faktor eksploratif digunakan untuk mengurangi jumlah variabel yang
banyak menjadi konstruksi faktor laten sebelum dibuat model regresi.
4.3.1 Uji Reliabilitas dan Validitas Data
Hasil pengolahan SPSS mengenai reliabilitas dan validitas data atas
independent variable dengan 90 sampel data terdapat pada Lampiran 3, yang secara
ringkas menghasilkan temuan sebagai berikut:
60
1) Validitas Isi (content validity) instrumen kuesioner penelitian yang dijadikan alat
ukur terambil dari konsep dan ide yang terkait dengan penelitian sebelumnya yang
telah dibahas pada Bab II.
2) Cronbach’s Alpha untuk menguji konsistensi dan kehandalan internal independent
variable dengan sampel sebanyak 90 dengan nilai koefisien 0,842 yang berada
diantara 0,7 dan 0,9 sehingga keseluruhan item dianggap memiliki reliabilitas yang
cukup untuk dilanjutkan.
3) Uji Kecukupan Sampel berdasarkan pada Kaiser-Meyer-Olkin Measure of
Sampling Adequacy (KMO-MSA) yang merupakan indeks perbandingan jarak
koefisien korelasi dengan koefisien parsial, dengan hasil pada proses pertama
(N=26) nilai KMO = 0,676, dan pada proses kedua (N=25, variabel HUM2
dihilangkan) nilai KMO = 0,685. Nilai tersebut memenuhi persyaratan untuk
analisa faktor sesuai dengan rekomendasi tabel di bawah ini:
Tabel 4.2: Rekomendasi Ukuran KMO

Ukuran KMO Rekomendasi
≥ 0,90 Sangat baik (Marvelous).
0,80 – 0,89 Berguna (Meritorious).
0,70 – 0,79 Biasa (Midding).
0,60 – 0,69 Cukup (Mediocre).
0,50 – 0,59 Buruk (Miserable).
≤ 0,50 Tidak diterima (Unacceptable).
Sumber: Manajemen Penelitian (Arikunto, 2006)
4) Uji Bartlett's Test of Sphericity juga membuktikan tidak adanya matriks identitas
sehingga proses dapat dilanjutkan, yaitu dengan nilai mendekati 0 (Sig. = 0,000)
dalam signifikansi 5%.
61
5) Uji Kecukupan dengan Anti-image Matrices dilakukan untuk menemukan variabel
dengan nilai “anti-image” < 0,5. Pada proses pertama, variabel HUM2 dengan
a
nilai (,448 ) atau di bawah 0,5, sehingga variabel tersebut dikeluarkan. Proses
analisa diulang terhadap 25 item, menghasilkan semua nilai “anti-image” yang
berada > 0,5. Hasil proses pertama terdapat dalam Lampiran 3 Hasil Uji Validitas.
4.3.2 Analisa Faktor
Metode analisa komponen utama (PCA – Principal Component Analysis) yang
bertujuan untuk membentuk kelompok sub-faktor dilakukan melalui beberapa uji coba
agar terbentuk faktor yang terwakili (representative) oleh anggota sub-faktornya.
Tabel 4.3 di bawah ini meringkas proses analisis komponen utama, sehingga
diputuskan untuk mengambil bentuk pengelompokkan sub-faktor menjadi 6 komponen
(faktor). Hasil rinci proses terdapat di Lampiran 4 - Analisa Komponen Utama.
Tabel 4.3: Tahapan Analisis Komponen Utama

Tahap Metode Ekstraksi Analisis
1 EigenValue > 1  Total Variance Explained = 66,237%
 Rotasi Varimax membentuk 8 komponen
 Terdapat 3 komponen (faktor) dengan anggota (sub-
faktor) hanya 1 atau 2
2 Set manual Factor=7  EigenValue > 1
 Total Variance Explained = 62,151%
 Masih terdapat komponen (faktor) beranggotakan (sub-
faktor) hanya 2
3 Set manual Factor=6  EigenValue > 1
(metode terpilih)  Total Variance Explained = 57,493% (masih diatas 50%)
 Seluruh komponen (faktor) telah beranggotakan 3 atau
lebih sub-faktor
Sumber: Ringkasan analisis yang dibuat peneliti
62
Tahapan berikutnya adalah interpretasi latent-variable (construct) melalui sub-
variable dari 25 variabel terobservasi. Interpretasi faktor dilakukan dengan mengamati
anggota faktor (sub-faktor), kemudian memberikan nama faktor sesuai dengan pola
pengaruh faktor tersebut terhadap dependent variabel yang dihasilkan oleh proses
regresi. Interpretasi terhadap factors loading sebagai proses yang subyektif mengingat
tidak mungkin dilakukan lewat perhitungan untuk memberikan ‘arti laten’ atas faktor.
Dengan alasan ini, analisa faktor sangat banyak digunakan pada tujuan eksplorasi
untuk mengurangi data dan menemukan konsep baru (Cooper & Schindler, 2008:565).
Berikut ini adalah penjabaran interpretasi atas 6 buah faktor tersebut.
4.3.2.1 Faktor Kepemimpinan Non-Simpatik (absence of sympathetic leadership)
Muatan faktor ini terdiri dari beberapa sub-faktor dengan bobot variannya
sebagai berikut:
Tabel 4.4: Variabel Faktor Pertama

Kode Indikator Pernyataan Bobot
STA1 Hubungan Sosial Hubungan sosial dan politik dengan client 0.788
Politik bermasalah.
STA2 Keterlibatan Rendahnya keterlibatan pengguna-kunci (key 0.635
Pemangku user) saat requirement gathering.
Kepentingan
INT1 Kemampuan Manajer Manajer proyek tidak mampu menangani 0.594
Proyek lingkungan proyek yang tidak pasti.
HUM4 Masalah Penugasan Terjadi masalah dalam internal tim karena 0.508
ketimpangan (kesalahan) dalam pembagian tugas.
QUA1 Anggaran QA Anggaran untuk Quality Assurance sangat <0.5
terbatas.
Sumber: Interpretasi faktor oleh peneliti
63
Faktor mempunyai hubungan POSITIF dalam model regresi, beberapa
indikator yang dapat menambah permasalahan proyek antara lain: (1) hubungan yang
tidak harmonis antara vendor dan client, (2) tingkat ketidak-hadiran pengguna kunci
pada kesempatan pertemuan penting, (3) aspek bersosialisasi manajer proyek yang
rendah, (4) masalah penugasan yang tidak efektif.
Observasi terhadap sub-faktor ini menunjukkan perlunya sebuah kualitas dan
gaya kepemimpinan tertentu pada manajer proyek serta manajemen-atas dalam
memimpin proyek. Didukung pula oleh data bahwa faktor kepemimpian paling sering
disebutkan oleh responden dalam komentar tambahan dengan pengulangan 10 kali
sebagai faktor penentu sukses atau gagalnya suatu proyek. Semakin besar keterlibatan
manajemen maka semakin tinggi kemungkinan suksesnya proyek (Nguyen, Q.M.,
2006) bahkan lebih penting dibandingkan dengan bantuan manajemen berupa saran
perbaikan yang bersifat teknis maupun saran tentang tata-kelola proyek (Young, R.
Jordan, E., 2008).
Muatan varian (factor loading) untuk faktor bentukan pertama ini memiliki
bobot persentase sebesar 22,887% total variance explained dari total akumulasi
persentase sebesar 57,493% yang dapat dijelaskan oleh 6 faktor yang terbentuk.
64
4.3.2.2 Faktor Ketidak-pedulian akan Prinsip Keterbatasan Biaya (cost-impact
ignorance)
sebagai berikut:
Tabel 4.5: Variabel Faktor Kedua

SCO2 Perubahan Permintaan perubahan yang berdampak pada 0.782
Permintaan biaya seringkali tidak disepakati oleh client.
TIM1 Ketergantungan Adanya permintaan yang bergantung pada 0.639
Pada Pihak Lain pekerjaan pihak lain.
COS1 Trade-off of Customer tidak bersedia mengurangi 'scope'. 0.616
project constraints
SCO3 Permintaan Client seringkali meminta fitur-fitur yang tidak 0.596
Berlebih (Over- berkaitan langsung dengan kebutuhan bisnis.
requirement)
PRO2 Proses Terjadi selisih yang jauh antara anggaran buyer 0.569
Penganggaran dengan harga oleh vendor.
indikator yang dapat menambah permasalahan proyek antara lain: (1) seringnya terjadi
perubahan permintaan, (2) dampak sunk-cost akibat ketergantungan penyelesaian pada
pihak lain, (3) sikap client yang selalu cenderung non-negotiable pada setiap
permintaan, (4) serta ketidak-pedulian pada prinsip keterbatasan biaya dan anggaran.
Observasi terhadap sub-faktor ini menunjukkan sisi fundamental mengenai
fungsi biaya (budget) dan jadwal (schedule) sebagai refleksi dan implikasi dari
permintaan cakupan (scope) dalam proyek. Pertanyaannya, adakah metode yang
akurat untuk mengukur beban biaya proyek perangkat lunak ketika permintaan bersifat
dinamis untuk menghasilkan perangkat lunak yang intangible?.
65
Beberapa masukan tambahan sebagai alternatif solusi dari responden, didapati
usulan perlu adanya biaya cadangan mengingat proyek adalah sebuah refleksi dari visi
dan strategi yang harus direalisasikan demi kepentingan bisnis (Pinto J.K, 2007) tidak
semata-mata terkunci hanya dalam batas biaya dan jadwal (Patanakul, P. et al., 2012)
terlebih lagi jika telah diperkirakan sejak awal bahwa proyek memiliki tingkat
ketidakpastian yang tinggi. Pandangan ini menjadi penting bila dilandaskan pada
prinsip bahwa proyek sebagai stepping-stone dalam mewujudkan visi dan strategi
bisnis perusahaan.
Adapun pandangan mengenai prinsip efisiensi biaya, maka proses perhitungan
anggaran harus dibuat setepat mungkin, namun hal tersebut sulit dilakukan terlebih
bila dilakukan secara sepihak (Heemstra, 1992), terutama dalam konteks hubungan
client-vendor yang melalui proses tender dapat mengundang prilaku price-to-win oleh
vendor yang bersaing, terlebih lagi adakalanya terjadi selisih perkiraan anggaran yang
cukup jauh antara perkiraan yang dibuat oleh client dengan perkiraan vendor.
Secara ringkas, observasi terhadap sub-faktor ini menunjukkan perlunya
manajemen memberikan pemahaman kepada pengguna sistem (key-users) serta vendor
pelaksana mengenai keterbatasan biaya dan penentuan cakupan pekerjaan berdasarkan
prioritas, serta penggunaan sunk-cost secara efisien dan efektif oleh manajer proyek.
66
4.3.2.3 Faktor Risiko Laten (latent risks) Terabaikan
sebagai berikut:
Tabel 4.6: Variabel Faktor Ketiga

RIS3 Tanggapan atas Tanggapan atas Risiko sering menggantung tanpa 0.694
Risiko tindakan.
COM3 Laporan KinerjaManajemen tidak menguji keakuratan laporan kinerja 0.633
proyek.
SCO1 Arahan Cakupan Manajemen-atas tidak terlibat langsung dalam 0.587
Pekerjaan mengarahkan cakupan pekerjaan.
COM1 Masalah Proyek Masalah dan risiko proyek tidak disampaikan sepenuhnya. 0.582
PRO1 Price-to-win Terjadi perilaku 'under-estimate' oleh vendor untuk 0.540

memenangkan tender.
indikator yang dapat menambah permasalahan proyek antara lain: (1) lambannya
keputusan menangani risiko dan isu proyek, (2) buruknya kualitas evaluasi terhadap
laporan proyek, (3) reaksi negatif manajemen terhadap hidden/implicit scope, (4) tidak
adanya kuantifikasi risiko terhadap melesetnya perkiraan biaya proyek.
Observasi terhadap sub-faktor ini menunjukkan perlunya sebuah kualitas
proses manajemen dalam menguji risiko dan kinerja proyek secara berkala, termasuk
sikap-tanggap atas risiko yang berdampak pada defisit anggaran proyek dan
tertundanya jadwal penyelesaian.
67
4.3.2.4 Faktor Toleransi Jadwal
sebagai berikut:
Tabel 4.7: Variabel Faktor Keempat

TIM2 Perencanaan Perencanaan proyek tidak mengantisipasi 0.751
Waktu perincian analisa kebutuhan.
RIS1 Toleransi Manajemen-atas tidak toleran mengenai 0.672
Manajemen kemungkinan/dampak risiko.
RIS2 Pengujian Risiko Pengujian risiko tidak detil dan menyeluruh di 0.652
tahap awal.
Faktor mempunyai hubungan NEGATIF dalam model regresi, beberapa
indikator yang dapat diperhatikan untuk mengurangi permasalahan proyek antara lain:
(1) jadwal proyek dibuat dengan cermat berdasarkan analisa kebutuhan dan risikonya,
(2) toleransi manajemen terhadap jadwal untuk kondisi yang tidak terduga.
Observasi terhadap sub-faktor ini menunjukkan perlunya komitmen bersama
mengenai risiko dan dampaknya ketika rincian analisis kebutuhan dihasilkan sejak
tahap awal. Hal ini sejalan dengan temuan yang dituliskan oleh Yeo (2002) tentang
adanya sikap mengganggap kecil (underestimate) proses analisis cakupan dan risiko di
tahap awal proyek. Risiko sebagai suatu yang harus disampaikan kepada orang yang
tepat dan waktu yang tepat, yaitu sesegera mungkin. Manajemen sepatutnya tidak
berpura-pura ‘tuli’ (turn a deaf-ear/deaf-effect) terhadap berita buruk, justru harus
segera ditindaklanjuti (Keil, M., et al, 1999).
68
4.3.2.5 Faktor Psikologi Kegagalan (Pessimistic To Achieve)
sebagai berikut:
Tabel 4.8: Variabel Faktor Kelima

HUM3 Suksesi Terjadi suksesi pada proyek manajer, atau 0.690
kepemimpinan sponsor proyek.
INT4 Tujuan Tidak Tujuan proyek dianggap tidak realistik oleh 0.570
Realistis manajer proyek.
INT5 Strategi Proyek Tata-kelola proyek tidak disesuaikan dengan 0.524
strategi bisnis (seperti: keunggulan produk, atau
time-to-market).
INT3 Model Hasil Customer tidak memiliki contoh konkrit tentang <0.5
hasil dari proyek yang akan dibuat.
indikator yang dapat menambah permasalahan proyek antara lain: (1) transisi
kepemimpinan/ suksesi, (2) anggaran dan jadwal yang dianggap tidak realistik untuk
mendukung hasil bagi strategi bisnis, (3) model konkrit output proyek tidak tergambar
secara jelas bagi pengguna (business user).
Observasi terhadap sub-faktor ini menunjukkan pengaruh buruk ketika terjadi
peralihan kepemimpinan yang searah dengan pernyataan penelitian lain, bahwa
komitmen manajemen terhadap keberhasilan proyek akan terpengaruh oleh adanya
peralihan kepemimpinan (Abdel-Hamid, T.K., 1992) terlebih lagi pada kualitas proyek
yang kompleks (Islam, S., 2014)
69
4.3.2.6 Faktor Komunikasi Tidak Efektif
sebagai berikut:
Tabel 4.9: Variabel Faktor Keenam

HUM1 Komunikasi Komunikasi verbal tim internal proyek tidak 0.687
internal tim lancar.
COM2 Perencanaan Kesepakatan rencana komunikasi 0.684
Komunikasi (communication plan) tidak berjalan efektif.
INT2 Metodologi Salah memilih metode untuk proyek dengan <0.5
Proyek tingkat perubahan permintaan yang tinggi.
indikator yang dapat menambah permasalahan proyek antara lain: (1) komunikasi
antar pemangku kepentingan yang kaku (formal-mode), (2) komunikasi penting yang
terjadwal sering tertunda.
Observasi terhadap sub-faktor ini menunjukkan pentingnya komunikasi pada
setiap jenjang fungsi dan jabatan. Pada komunikasi di tingkat tinggi, efektifitas muatan
informasi menjadi keharusan, agar efek negatif persepsi terhadap perangkat lunak
yang invisible dapat dikurangi. Masalah yang sering menyebabkan komunikasi yang
tidak efektif adalah faktor biased communication akibat adanya asymmetric
information antara pelaksana dan sponsor proyek (Keil, M., et al., 2000).
70
4.3 Bahasan Tujuan Penelitian Kedua
Untuk mencapai jawaban atas tujuan penelitian kedua, yaitu menghasilkan
sebuah model persamaan untuk membuat perkiraan Tingkat Masalah pada proyek
perangkat lunak, maka teknik regresi linear berganda akan digunakan terhadap lebih
dari satu variabel bebas (independent variable).
Variabel terikat (dependent variable) yang digunakan dalam kuesioner adalah
“Tingkat Masalah (PROBLEM WEIGHT)” yang dinilai oleh responden dalam bentuk
skala ordinal (1 s/d 10), melalui pertanyaan: “Secara rentang (interval), berapa banyak
permasalahan dalam proyek perangkat lunak menurut Anda? (1= Tidak ada s/d 10=
Sangat Banyak)”. Lihat grafik pada Bab ini dalam sub-judul “Pengetahuan Tentang
Masalah”, merupakan persepsi responden terhadap tingkat masalah yang dihadapi.
Variabel bebas hasil dari analisa faktor digunakan sebagai independent
variables, seperti tertera pada pemetaan di Tabel 4.10.
Tabel 4.10: Variabel Regresi Linear

Faktor Hasil Sumber Faktor Laten
Regresi
Variabel Terikat Kuesioner Tingkat Masalah
Variabel Bebas Regresi Faktor-1 Kepemimpinan Non-Simpatik
(construct) (absence of sympathetic leadership)
Regresi Faktor-2 Ketidak-pedulian akan Prinsip Keterbatasan
Biaya (Cost-impact ignorance)
Regresi Faktor-3 Risiko Laten (latent risks) Terabaikan
Regresi Faktor-4 Toleransi Jadwal
Regresi Faktor-5 Psikologi Kegagalan (Pessimistic To Achieve)
Regresi Faktor-6 Komunikasi Tidak Efektif
Sumber: Pemetaan variabel regresi oleh peneliti
71
Analisis nilai statistik seperti “R-square” tidak dikemukakan untuk pencapaian
tujuan penelitian manajerial ini, disamping sifat penelitian yang sesaat. Fungsi regresi
yang dijalankan hanya untuk menghasilkan bentuk model persamaan dan nilai
intercept dan slope (coefficient). Hasil SPSS lengkap dari proses ini berada di
Lampiran-6 Regresi Linear Berganda. Persamaan regresi yang dihasilkan adalah
sebagai berikut:
Tabel 4.11: Simulasi Prediksi Model Regresi

Model Y= a + 0,211 b1 + 0,261 b2 + 0,182 b3 - 0,357 b4 + 0,31 b5 + 0,148 b6
Koefisien 6.744 0.211 0.261 0.182 -0.357 0.031 0.148
Prediksi Y Y= A b1 b2 b3 b4 b5 b6
Minimum 5.8 6.744 -3.805 -2.061 -3.158 -4.270 -2.533 -3.156
Maksimum 8.0 6.744 2.229 2.653 2.175 2.194 2.044 3.104
Ideal 3.5 6.744 -3.805 -2.061 -3.158 2.194 -2.533 -3.156
Ekstrim 10.3 6.744 2.229 2.653 2.175 -4.270 2.044 3.104
* Ekstrem melebihi rentang maksimum "10"
Sumber: Hasil proses peneliti dengan spreadsheet MS Excel
Model Evaluasi dalam simulasi perkiraan dengan empat nilai yaitu minimum,
maksimum, ideal, dan ekstrim yang dihasilkan berdasarkan data penelitian sesaat
untuk memperkirakan Tingkat Masalah (skala 1 s/d 10) pada proyek perangkat lunak.
Sasaran yang perlu dicapai oleh manajemen adalah menguranginya dari skala
nilai konstan 6,744 menjadi skala nilai ideal 3,5 dengan memperhatikan faktor-faktor
yang mempengaruhi tinggi/rendahnya permasalahan pada proyek yang akan dibahas
pada bagian Implikasi Manajerial di akhir Bab ini.
72
4.4 Analisis Isi Jawaban (Content Analysis)
Terdapat dua pertanyaan tambahan yang disampaikan kepada responden
berupa pertanyaan tertutup (Ya/Tidak) yang diakhiri dengan tambahan komentar yang
dapat diisi bila ada.
4.4.1 Ukuran Proyek Bermasalah (Gagal)
Umumnya, manajemen proyek yang berorientasi bisnis melakukan pengukuran
kesuksesan (profitability) proyek berdasarkan pada biaya dan jadwal, sebagai alat ukur
yang lebih mudah dilakukan dibandingkan ukuran kualitas yang biasanya diwakili
oleh kepuasan pelanggan yang hanya diketahui pada tahap operasional.
Meskipun demikian, dalam beberapa literatur definisi tentang ukuran
kesuksesan proyek berubah sepanjang waktu. Pada tahun 1960, kesuksesan diukur
dengan kriteria teknis yaitu apakah perangkat lunak tersebut dapat digunakan atau
tidak. Beberapa waktu belakangan sekitar tahuan 1980, ukuran kesuksesan dibuat
berdasarkan 3 buah kriteria, yaitu tepat-waktu, sesuai anggaran, serta kualitas sesuai
harapan (Kerzner, 1998).
Terhadap pertanyaan “Setujukah Anda bila proyek gagal diukur karena
keterlambatan jadwal (overschedule) atau kehabisan anggaran (overbudget)?”, hasil
survei menunjukkan jawaban yang hampir seimbang. Meskipun berarti juga adanya
keinginan yang berbeda dari responden terhadap penggunaan ukuran sukses atau
tidaknya sebuah proyek, sebagai berikut:
Tabel 4.12: Respon Tentang Ukuran Kegagalan
73
Jawaban Jumlah
Tidak menjawab 1
Ya 47
Tidak 42
TOTAL 90
Sumber: Hasil proses oleh peneliti
Gambar 4.8: Prosentasi Respon Ukuran Kegagalan

Hal lainnya yaitu terdapat beberapa komentar tambahan dari responden yang
telah menjawab baik “Setuju (Ya)” ataupun “Tidak Setuju (Tidak)”, yang terlampir
pada Lampiran 7 - Komentar Tambahan Responden, dengan analisis isi jawaban
sebagai berikut:
1) Responden yang setuju (YA), sesuai dengan pernyataan bahwa over-budget
dijadikan ukuran, karena menyangkut penghitungan biaya yang sesuai
dengan permintaan (requirement) agar proyek dapat menguntungkan.
2) Responden yang tidak setuju (TIDAK), mengecualikan bila keterlambatan
disetujui oleh manajemen karena alasan tertentu, meskipun secara kuangan
proyek telah merugi. Hal tersebut dengan pertimbangan future business
74
value yang diharapkan terhadap proyek strategis. Komentar ini searah
dengan pertanyaan setelah ini, mengenai keputusan manajemen atas proyek
bermasalah.
4.4.2 Keputusan Manajemen atas Proyek Bermasalah (Gagal)
Ketika sebuah proyek dianggap telah melewati jadwal yang diharapkan, atau
telah menghabiskan dana yang dianggarkan, maka tindakan manajemen akan
bervariasi.
Terhadap pertanyaan “Setujukah Anda bahwa proyek harus terus dilanjutkan
apapun risikonya, karena sebagai penerapan visi/strategi bisnis?”, hasil survei
memberikan gambaran mayoritas harapan responden agar proyek tidak dilanjutkan,
masing-masing memberikan tambahan komentar pada jawaban mereka. Jumlah
jawaban masing-masing seperti pada tabel dan grafik berikut:
Tabel 4.13: Respon Status Kelanjutan Proyek

Jawaban Jumlah
Tidak menjawab 10
Ya 37
Tidak 43
TOTAL 90
75
Gambar 4.9: Prosentasi Respon Status Kelanjutan
Terdapat beberapa komentar tambahan dari responden yang telah menjawab
baik “Setuju (Ya)” ataupun “Tidak Setuju (Tidak)”, terlampir pada Lampiran 7 -
Komentar Tambahan Responden. Analisis isi jawaban atas komentar tersebut antara
lain:
1) Responden yang setuju (YA) menyatakan bahwa keputusan tetap
melanjutkan proyek sebagai konsekuensi pentingnya rencana proyek bagi
keberlangsungan bisnis, apapun risikonya maka harus ditangani.
2) Responden yang tidak setuju (TIDAK) menyatakan perlunya menghentikan
ketika tidak ada harapan yang jelas untuk keberhasilan, yaitu terhadap
proyek yang dianggap tidak terlalu mendasar bagi bisnis.
4.4.3 Komentar Tambahan Umum
Pada akhir bagian survei, responden dipersilakan untuk memberikan jawaban
atas pertanyaan terbuka mengenai masukan lain terkait dengan penelitian ini.
Beberapa responden memberikan komentar jawaban yang merupakan informasi
tambahan untuk penelitian ini. Jawaban-jawaban responden tertuang dalam Lampiran
7 – Komentar Tambahan Responden, dengan judul tabel: Komentar Tambahan
Penelitian.
76
Secara ringkat analisis terhadap isi jawaban adalah sebagai berikut:
Tabel 4.14: Analisis Komentar Tambahan

No Tipe Rekomendasi Jumlah
Pengulangan
1. Gaya hubungan vendor-client
 Communication 3
 Negotiation skill 1
 Ketidakpastian permintaan 3
 Gaya payer-worker versus partnership 2
2. Faktor Sukses/Gagal karena Manajemen
 Komitmen Keterlibatan 10
 Komitmen Biaya dan Biaya Cadangan 4
 Manajemen yang Fleksibel 2
3. Ukuran Suksel/Gagal
 Kualitas 3
 Besar (Volume) Proyek 3
Analisis isi jawaban:
1) Faktor penyebab sukses/gagalnya proyek dalam pandangan responden
terfokus pada:
a. Hubungan antara vendor dan client dalam berbagai aspek seperti
komunikasi, negosiasi, kepastian permintaan, serta gaya kerjasama
mendapat perhatian responden sebagai faktor yang berpengaruh.
77
b. Komitmen dan kelenturan manajemen-atas terutama dalam dua hal
yaitu: keterlibatan dalam proyek, serta dukungan tambahan
anggaran bila diperlukan.
c. Ukuran kompleksitas dan besaran proyek yang dapat berpengaruh
pada potensi kegagalan, serta ukuran kualitas yang perlu
diperhatikan juga sebagai faktor kesuksesan.
2) Komentar lainnya juga disampaikan sebagai bahan masukan bagi penelitian
lebih lanjut.
78
4.5 Implikasi Manajerial
Proyek perangkat lunak penuh dengan dinamika yang disebabkan oleh sifat
alamiah perangkat lunak yang intangible dan invisible yang sebagian besar output
pekerjaan adalah buah karya akal dan pikiran manusia yang terpengaruh oleh berbagai
faktor internal maupun eksternal. Mengutip tulisan yang dibuat oleh K.T. Yeo (2002)
yang menyatakan kesan serupa mengenai dilemma yang perlu dipahami oleh setiap
pemangku kepentingan:
It is important that the information technology community together with

other stakeholders have a better understanding of the nature of
software or information system projects and the special problems of the
widespread systems failures. Checkland and Holwell [2] reckon that
the study of information systems remains a crucial but confused field.
Lyytinen and Hirschheim [3] suggested that the study of system failure
still suffers from an inadequate conceptual clarity of the information
system failure notions.
Implikasi yang dapat dipetik dari penelitian manajerial ini berupa hal-hal yang
perlu diperhatikan berdasarkan temuan faktor, antara lain:
1) Menempatkan pemimpin proyek yang simpatik yang mau melibatkan diri
dengan seluruh pemangku kepentingan agar proyek berlangsung optimal
dalam penggunaan sunk-cost yang terbatas. Faktor “Kepemimpinan Non-
simpatik” sebagai faktor yang paling berpengaruh yang dapat dijelaskan
sebesar 22,887% oleh muatan varians (loading factors). Dimulai dari
kepemimpinan yang berkualitas dan efektif, maka kegiatan penting proyek
dapat berlangsung dengan optimal sehingga anggaran dapat digunakan
secara efisien dengan tujuan ideal yaitu on-budget dan on-schedule.
79
Pemimpin yang simpatik diharapkan dapat menjaga komitmen dan
semangat anggota untuk terus terlibat sampai selesainya proyek. Komentar
tambahan dari responden mendukung hal tersebut bahwa komitmen yang
terus-menerus menjadi faktor penting untuk kesuksesan proyek.
2) Pemberian pemahaman kepada pemangku kepentingan mengenai prinsip
keterbatasan biaya, serta mengarahkan cakupan berdasarkan prioritas.
Faktor “Ketidak-pedulian akan Prinsip Keterbatasan Biaya (cost-impact
ignorance)” yang muncul bila terjadi ketidakpastian permintaan dan
tuntutan yang berlebih yang berdampak negatif berupa defisit anggaran.
Keadaan ini dapat diatasi melalui pemberian pemahaman kepada tim
proyek khususnya pengguna-kunci (key users), serta arahan dari
manajemen ketika cakupan perlu dibatasi berdasarkan prioritas. Hal ini
juga perlu mendapat perhatian manajer proyek terkait penggunaan sunk-
cost agar optimal dan efisien terutama dalam keadaan requirement
uncertainty yang tinggi pada proyek strategis bagi client maupun vendor.
3) Menghindari munculnya Risiko Laten di tengah pelaksanaan proyek,
melalui proses analisa risiko yang rinci di tahap awal. Faktor munculnya
Risiko Laten di tengah pelaksanaan proyek akibat terabaikannya proses
analisa risiko yang rinci di tahap awal proyek. Manajer proyek perlu
memperhitungkan efek sunk-cost sumber daya manusia yang ahli ketika
proyek dimulai namun constraint, dependencies, serta risiko proyek belum
teridentifikasi dengan jelas.
80
4) Menyelaraskan bisnis dengan proyek untuk mencapai tujuan yang
achievable agar tidak terjadi dampak Psikologi Kegagalan dalam organisasi
proyek. Faktor lainnya yang berperan terhadap kegagalan proyek adalah
Psikologi Kegagalan akibat persepsi tentang tujuan proyek yang tidak
realistis, serta gagalnya sinergi antara tujuan bisnis dan adopsinya dalam
visi proyek. Rencana proyek yang dibuat atas dasar perkiraan sebaiknya
tidak dijadikan standar tunggal untuk mengukur kinerja manajer. Hal ini
juga sesuai dengan harapan beberapa responden.
5) Membuat pola komunikasi informal yang produktif antara tim proyek dan
tim bisnis, di luar kanal komunikasi formal yang sudah ada. Faktor
Komunikasi internal tim proyek dengan tim bisnis yang tidak efektif
berpengaruh pada tertundanya pekerjaan. Manajemen perlu membuat pola
komunikasi tambahan berupa komunikasi informal agar meningkatkan
produktifitas kerja tim proyek.
6) Manajemen-atas yang perlu memberikan toleransi atas jadwal ketika
seringkali keterlambatan disebabkan oleh faktor eksternal proyek. Faktor
Tingkat Toleransi Manajemen atas jadwal didapati berpengaruh pada
ukuran kesuksesan proyek, seperti juga tercermin dari masukan responden
bahwa seringkali keterlambatan sebenarnya disebabkan oleh faktor
eksternal proyek seperti key-users, atau proyek lain.
81
BAB V. KESIMPULAN DAN SARAN
5.1 Kesimpulan
1) Tujuan penelitian pertama telah menghasilkan 6 faktor yang menjadi penyebab
kegagalan proyek perangkat lunak, serta implikasinya bagi dunia praktis dan peran
manajerial seperti yang tertuang pada Implikasi Manajerial di bagian akhir Bab IV.
2) Tujuan penelitian kedua menghasilkan:
a) Persepsi responden bahwa masalah berada pada rentang di atas rata-rata
(6,744 > 5,5) pada skala 1 s/d 10.
b) Model evaluasi untuk menurunkan masalah dari nilai 6,744 menjadi nilai
ideal 3,5 dengan mengambil langkah perbaikan pada proyek sesuai bahasan
pada implikasi manajerial.
5.2 Saran
Penelitian akademis ini memiliki keterbatasan berupa sebuah penelitian sesaat
yang perlu dilanjutkan untuk mendapatkan data time-series yang lebih lengkap
agar model evaluasi proyek perangkat lunak dapat dilakukan proses regresi lebih
lanjut dan menghasilkan persamaan yang lebih akurat.
Penelitian dalam konteks manajerial ini mengharapkan terjadinya perbaikan
dalam organisasi perusahaan pada pelaksanaan proyek berdasarkan bahasan pada
implikasi manajerial. Harapannya adalah bahwa penelitian berikutnya akan
menemukan persepsi responden terhadap masalah proyek dengan nilai yang lebih
rendah dari nilai saat ini.
82
DAFTAR PUSTAKA
A Guide to the Project Management Body of Knowledge (PMBOK ® Guide) – Fifth

Edition, Project Management Institute, Inc.
Abdel-Hamid, T.K. Sengupta, K. & Swett, C. (1999). The Impact of Goals on

Software Project Management: An Experimental Investigation. MIS Quarterly,
23(4):531-555.
Abdel-Hamid, T.K. (1992). Investigating the impacts of managerial

turnover/succession of software project performance. Journal of Management
Information Systems 9(2):127-144.
Abdel Hamid. (1989). A Study of Staff Turnover, Acquisition, And Assimilation and
Their Impact on Software Development Cost and Schedule. Journal of
Management Information Systems, 6(1):21-40.
Abdel-Hamid, T.K. (1987). The Economics of Software Quality Assurance: A System

Dynamics based Simulation Approach. [Working Paper]. Massachusetts Institute
of Technology.
Ajmal, M.M., Koskinen, K.U. (2008). Knowledge Transfer in Project-Based

Organizations: An Organizational Culture Perspective. Project Management
Journal, 39(1):7–15.
Almeida, M.V. Soares, & A.L. (2014). Knowledge sharing in project-based

organizations: Overcoming the informational limbo. International Journal of
Information Management 34:770–779.
Arikunto, S. 2006. Manajemen Penelitian. Rineka Cipta, Jakarta.
Barki, H. Rivard, S. & Talbot, J. (2001). An Integrative Contingency Model of

Software Project Risk Management". Journal of Management Information
Systems, 17(4):37-69.
Brown, C.V., DeHayes, D.W., Hoffer, J.A., Martin, E.W. 2012. Managing
Information Technology 7th Edition. Prentice Hall Publisher.
83
Clarke, P., O’Connor, R.V. (2012). The situational factors that affect the software
development process: Towards a comprehensive reference framework.
Information and Software Technology, 54:433–447.
Ferrat T.W. , Ahire, S. Prabuddha De. (2006). Achieving Success in Large Projects -
Implications from a Study of ERP Implementation. Interfaces, 36(5):458-469.
Fred R.D. (2011). Strategic management: concepts and cases 13th edition. Pearson
Education, Inc., published by Prentice Hall.
Harris, M.L, Collins, R.W., and Hevner, A.R. (2009). Control of Flexible Software
Development Under Uncertainty. Information Systems Research, 20(3):400-419,
Flexible and Distributed Information Systems Development.
Heemstra, F.J. (1992). Software cost estimation. Butterworth-Heinemann Ltd 34(10).
Islam, S., Mouratidis, H. & Weippl, E.R. (2014). An empirical study on the
implementation and evaluation of a goal-driven software development risk
management model. Information and Software Technology 56:117–133.
Jones, C. (2004). Software Project Management Practices - Failure versus Success.

Software Productivity Research LLC.
Kasser, J.E., William, V.R. (1998). Whad do you mean you cannot tell me if my
project is in trouble?. Reprinted from FESMA 98.
Keil, M., Mann, J., & Rai, A. (2000). Why Software Projects Escalate: An Empirical
Analysis and Test of Four Theoretical Models. MIS Quarterly 24(4):631-664.
Keil, M., Robey, D. (1999). Turning around Troubled Software Projects: An

Exploratory Study of the Deescalation of Commitment to Failing Courses of
Action. Journal of Management Information Systems, 15(4):63-87.
Keil, M. Mixon, R. Saarinen, & T. Tuunainen, V. (1995). Understanding Runaway

Information Technology Projects: Results from an International Research
Program Based on Escalation Theory. Journal of Management Information
Systems, 11(3):65-85.
84
Keil, M., Cule, P.E., Lyytinen, K., & Schmidt, R.C. (1998). A Frameworks identifying
Software Project Risk. Communications of The ACM November, 41(11).
Keil, M. (1995). Pulling the Plug - Software Project Management and the Problem of
Project Escalation. MIS Quarterly, 19(4):421-447.
Kerzner, H. (1998), In Search of Excellent in Project Management. Van Nostrand

Reinhold, New York.
Kundi, G.M., Nawaz, & A., Shah, B. (2007). De-Escalating The IT Projects. Journal
of Information Systems and Technology Management, 4(3):325-332.
Liang, TP., Yen, NS., Kang T.C., & Li YW. (Unknown-year). Escalation of
Commitment in Software Projects An Examination of Two Theories. Internet
searching.
Leonard, A. (2013). Keeping in mind the impact of social relationships when

managing software project teams. Procedia Technology 9:767 – 776.
André, M, Baldoquín, M.G, Acuna, S.T. (2011). Formal model for assigning human
resources to teams in software projects. Information and Software Technology
53:259–275.
Maruping, Venkatesh, & Agarwal. (2009), A Control Theory Perspective on Agile

Methodology Use and Changing User Requirements. Information Systems
Research 20(3):377-399.
Meli, R. (1999). Risk, Requirements and Estimation of a Software Project. ESCOM-

SCOPE 99 April27-29.
Nelson, R.R. (2005). Project Retrospective: evaluating project success failure and
everything in between. MIS Quarterly Executive 4(3).
Nguyen, Q.M. (2006). Planning in software project management: An empirical

research of software companies in Vietnam. Thesis of The Faculty of Economics
and Social Sciences at the University of Fribourg.
85
Nidumolu, S. (1995). The Effect of Coordination and Uncertainty on Software Project
Performance - Residual Performance Risk as an Intervening Variabel.
Information Systems Research, 6(3):191-219.
O. Shmueli, et al., (2014). Explaining over-requirement in software development

projects: An experimental investigation of behavioral effects. International
Journal of Project Management
Manag.http://dx.doi.org/10.1016/j.ijproman.2014.07.003
Patanakul, P. et al. (2012). How project strategy is used in project management-Cases

of new product development and software development projects. Journal of
Engineering and Technology Management, 29:391–414.
Pinto, J.K. (2010). Project Management: Achieving Competitive Advantage, Second

Edition. Pearson Education, Inc., published by Prentice Hall.
Porter, M.E., Millar, V.E. (1985). How Information Gives You Competitive
Advantage. Harvard Business Review Reprint 85415.
Savolainen, P et al. (2012). Software development project success and failure from the
suppliers perspective: A systematic literature review. International Journal of
Project Management, 30:458–469.
Cooper, D.R, Schindler, P.S. (2008). Business Research Methods, Tenth Edition.
McGraw Hill.
Sommerville, I. (2004). Software Engineering Edition 7. Pearson Education Ltd:620.
V.C. Gu et al. (2014). The effects of organizational culture and environmental

pressures on IT project performance: A moderation perspective. International
Journal of Project Management, 32:1170–1181.
Wright, M.K. Capps, C.J. (2009). A Survey of Information System Development

Project Performance. Working Paper. No. 10-07 MGT June 2010 Center for
Business and Economic Development at Sam Houston State University.
Yeo, K.T. (2002). Critical failure factors in information system projects. International
Journal of Project Management 20.
86
Young, R. Jordan, E. (2008). Top management support: Mantra or necessity?
International Journal of Project Management doi:10.1016/ j.ijproman.
2008.06.001.
87
LAMPIRAN 1. ONLINE SURVEY
i. URL: Www.SurveyMonkey.Com
88
ii. Www.SurveyMonkey.Com (lanjutan)
89
iii. Www.SurveyMonkey.Com (lanjutan)
90
LAMPIRAN 2. STATISTIK DESKRIPTIF 26 VARIABEL
i. Tabel Variabel Instrumen Survei

Kode Pernyataan
1 COM1 Masalah dan risiko proyek tidak disampaikan sepenuhnya.
2 COM2 Kesepakatan rencana komunikasi (communication plan) tidak berjalan efektif.
3 COM3 Manajemen tidak menguji keakuratan laporan kinerja proyek.
4 COS1 Customer tidak bersedia mengurangi 'scope'.
5 HUM1 Komunikasi verbal tim internal proyek tidak lancar.
6 HUM2 Pelatihan bagi anggota baru dilakukan oleh anggota lama.
7 HUM3 Terjadi suksesi pada proyek manajer, atau sponsor proyek.
8 HUM4 Terjadi masalah dalam internal tim karena ketimpangan (kesalahan) dalam pembagian tugas.
9 INT1 Manajer proyek tidak mampu menangani lingkungan proyek yang tidak pasti.
10 INT2 Salah memilih metode untuk proyek dengan tingkat perubahan permintaan yang tinggi.
11 INT3 Customer tidak memiliki contoh konkrit tentang hasil dari proyek yang akan dibuat.
12 INT4 Tujuan proyek dianggap tidak realistik oleh manajer proyek.
13 INT5 Tata-kelola proyek tidak disesuaikan dengan strategi bisnis (seperti: keunggulan produk, atau
time-to-market).
14 PRO1 Terjadi perilaku 'under-estimate' oleh vendor untuk memenangkan tender.
15 PRO2 Terjadi selisih yang jauh antara anggaran buyer dengan harga oleh vendor.
16 QUA1 Anggaran untuk Quality Assurance sangat terbatas.
17 RIS1 Manajemen-atas tidak toleran mengenai kemungkinan/dampak risiko.
18 RIS2 Pengujian risiko tidak detil dan menyeluruh di tahap awal.
19 RIS3 Tanggapan atas Risiko sering menggantung tanpa tindakan.
20 SCO1 Manajemen-atas tidak terlibat langsung dalam mengarahkan cakupan pekerjaan.
21 SCO2 Permintaan perubahan yang berdampak pada biaya seringkali tidak disepakati oleh client.
22 SCO3 Client seringkali meminta fitur-fitur yang tidak berkaitan langsung dengan kebutuhan bisnis.
23 STA1 Hubungan sosial dan politik dengan client bermasalah.
24 STA2 Rendahnya keterlibatan pengguna-kunci (key user) saat requirement gathering.
25 TIM1 Adanya permintaan yang bergantung pada pekerjaan pihak lain.
26 TIM2 Perencanaan proyek tidak mengantisipasi perincian analisa kebutuhan.
91
ii. Sebaran Jawaban & Statistik Deskriptif
Jawaban dalam Skala Likert (1-Sangat Tidak Setuju, 2-Tidak Setuju, 3-Netral, 4-
Setuju, 5-Sangat Setuju):
Pilihan COM1 COM2 COM3 COS1 HUM1 HUM2 HUM3 HUM4 INT1 INT2 INT3 INT4 INT5 PRO1 PRO2 QUA1 RIS1 RIS2 RIS3 SCO1 SCO2 SCO3 STA1 STA2 TIM1 TIM2
1 0 0 0 2 0 2 1 0 1 0 2 2 2 2 2 0 2 1 0 0 0 0 2 2 1 1
2 4 2 6 10 10 25 11 14 5 17 12 16 14 7 11 10 10 5 6 8 4 5 9 4 7 5
3 3 3 20 22 16 35 30 15 13 17 23 20 29 9 32 27 26 12 11 13 15 15 21 5 24 13
4 46 58 49 36 46 24 40 54 45 44 43 43 39 31 31 40 39 57 50 48 48 44 38 37 45 60
5 37 27 15 20 18 4 8 7 26 12 10 9 6 41 14 13 13 15 23 21 23 26 20 42 13 11
Total 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
Confd.
Descriptive Std Std. Sample Largest Smallest
Mean Median Mode Kurtosis Skewness Range Min Max Level
Statistic Error Dev. Variance (1) (1)
(95.0%)
COM1 4.29 0.08 4 4 0.74 0.54 2.07 -1.21 3 2 5 5 2 0.15
COM2 4.22 0.06 4 4 0.61 0.38 2.43 -0.76 3 2 5 5 2 0.13
COM3 3.81 0.08 4 4 0.79 0.63 0.05 -0.48 3 2 5 5 2 0.17
COS1 3.69 0.11 4 4 1.01 1.03 -0.24 -0.53 4 1 5 5 1 0.21
HUM1 3.8 0.09 4 4 0.89 0.79 -0.24 -0.57 3 2 5 5 2 0.19
HUM2 3.03 0.1 3 3 0.91 0.82 -0.53 0.12 4 1 5 5 1 0.19
HUM3 3.48 0.09 4 4 0.86 0.75 -0.14 -0.36 4 1 5 5 1 0.18
HUM4 3.6 0.09 4 4 0.85 0.71 -0.23 -0.72 3 2 5 5 2 0.18
INT1 4 0.09 4 4 0.87 0.76 1.01 -0.93 4 1 5 5 1 0.18
INT2 3.57 0.1 4 4 0.95 0.9 -0.78 -0.4 3 2 5 5 2 0.2
INT3 3.52 0.1 4 4 0.94 0.88 -0.06 -0.57 4 1 5 5 1 0.2
INT4 3.46 0.1 4 4 0.97 0.95 -0.42 -0.51 4 1 5 5 1 0.2
INT5 3.37 0.1 4 4 0.91 0.82 -0.22 -0.43 4 1 5 5 1 0.19
PRO1 4.13 0.11 4 5 1.03 1.06 0.91 -1.22 4 1 5 5 1 0.22
PRO2 3.49 0.1 4 3 0.97 0.95 -0.33 -0.23 4 1 5 5 1 0.2
QUA1 3.62 0.09 4 4 0.87 0.75 -0.55 -0.23 3 2 5 5 2 0.18
RIS1 3.57 0.1 4 4 0.95 0.9 -0.05 -0.48 4 1 5 5 1 0.2
RIS2 3.89 0.08 4 4 0.79 0.62 2.07 -1.08 4 1 5 5 1 0.16
RIS3 4 0.09 4 4 0.81 0.65 0.58 -0.79 3 2 5 5 2 0.17
SCO1 3.91 0.09 4 4 0.86 0.73 0.14 -0.7 3 2 5 5 2 0.18
SCO2 4 0.08 4 4 0.78 0.61 0.23 -0.58 3 2 5 5 2 0.16
SCO3 4.01 0.09 4 4 0.83 0.69 0.03 -0.63 3 2 5 5 2 0.17
STA1 3.72 0.1 4 4 0.99 0.99 -0.06 -0.6 4 1 5 5 1 0.21
STA2 4.26 0.1 4 5 0.92 0.84 2.86 -1.6 4 1 5 5 1 0.19
TIM1 3.69 0.09 4 4 0.86 0.73 0.32 -0.56 4 1 5 5 1 0.18
TIM2 3.83 0.08 4 4 0.75 0.57 2.41 -1.17 4 1 5 5 1 0.16
92
LAMPIRAN 3. HASIL UJI VALIDITAS
i. Hasil Uji Kehandalan
Tabel: Uji Kehandalan Kasus

Case Processing Summary
N %
Cases Valid 90 100,0
Excluded 0 0
Total 90 100,0
a. Listwise deletion based on all variables in the procedure.
Sumber: Hasil Proses SPSS
Tabel: Uji Kehandalan Alpha

Reliability Statistics
Cronbach's Alpha
Cronbach's Alpha Based on Standardized Items N of Items
,845 ,846 26

ii. Hasil Uji Validitas (Sumber SPSS)
Tabel: Uji Validitas

Item-Total Statistics
Scale Mean if Scale Variance if Corrected Item- Squared Multiple Cronbach's Alpha
Item Deleted Item Deleted Total Correlation Correlation if Item Deleted
COM1 93.67 100.787 .376 .497 .840
COM2 93.73 103.456 .245 .425 .844
COM3 94.14 98.619 .487 .540 .836
COS1 94.27 99.703 .305 .515 .843
HUM1 94.16 100.088 .338 .459 .841
HUM2 94.92 106.275 -.011 .404 .853
HUM3 94.48 101.668 .257 .388 .844
HUM4 94.36 99.063 .423 .414 .838
INT1 93.96 100.582 .317 .499 .842
INT2 94.39 97.948 .429 .497 .838
INT3 94.43 99.439 .351 .470 .841
INT4 94.50 98.927 .363 .446 .841
INT5 94.59 94.807 .640 .620 .830
PRO1 93.82 95.833 .496 .589 .835
PRO2 94.47 97.196 .456 .569 .837
93
Item-Total Statistics
Scale Mean if Scale Variance if Corrected Item- Squared Multiple Cronbach's Alpha
Item Deleted Item Deleted Total Correlation Correlation if Item Deleted
QUA1 94.33 98.270 .457 .493 .837
RIS1 94.39 98.150 .417 .538 .838
RIS2 94.07 99.748 .416 .692 .839
RIS3 93.96 99.324 .430 .498 .838
SCO1 94.04 100.402 .336 .546 .841
SCO2 93.96 99.144 .461 .622 .837
SCO3 93.94 100.840 .323 .505 .842
STA1 94.23 98.271 .387 .553 .840
STA2 93.70 96.999 .500 .643 .835
TIM1 94.27 99.703 .378 .424 .840
TIM2 94.12 100.333 .397 .555 .839
Tabel: Uji Kecukupan Sampel (N=26)

KMO and Bartlett's Test
Kaiser-Meyer-Olkin Measure of Sampling Adequacy. ,676
Bartlett's Test of Sphericity Approx. Chi-Square 838,181
Df 325
Sig. ,000
Tabel: Uji Kecukupan Sampel (N=25)

KMO and Bartlett's Test
Kaiser-Meyer-Olkin Measure of Sampling Adequacy. ,685
Bartlett's Test of Sphericity Approx. Chi-Square 800,360
Df 300
Sig. ,000
94
Tabel: Uji Kecukupan dengan Anti-image Matrices (dengan HUM2)
Anti-image Matrices
COM1 COM2 COM3 COS1 HUM1 HUM2 HUM3 HUM4 INT1 INT2 INT3 INT4 INT5 PRO1 PRO2 QUA1 RIS1 RIS2 RIS3 SCO1 SCO2 SCO3 STA1 STA2 TIM1 TIM2
a
Anti-image COM1 .739 -.288 -.201 -.109 -.096 .062 -.063 -.084 -.090 .040 .156 .019 .132 -.332 .016 .056 .015 -.237 -.150 .109 -.036 .071 .028 .051 -.041 .133
Correlation COM2 -.288 .575
a
-.019 .111 -.258 -.011 .148 .128 .076 -.225 .020 .117 .145 .029 .065 -.162 -.002 .307 -.060 -.179 -.009 -.053 -.245 -.080 .001 -.200
a
COM3 -.201 -.019 .713 .080 -.101 -.228 -.063 -.069 -.132 .191 -.265 -.102 .066 .033 -.260 .060 .032 -.181 -.055 -.256 .053 -.176 .012 .271 -.154 -.133
a
COS1 -.109 .111 .080 .659 .147 .127 -.248 -.123 .024 .053 .003 -.280 .011 .241 -.263 -.032 -.136 .177 -.028 .021 -.284 -.093 -.194 .075 -.010 -.011
HUM1 -.096 -.258 -.101 .147 .665a -.052 -.065 .005 -.184 -.038 .311 -.271 -.201 .183 -.040 .066 .020 .032 -.044 .114 .094 -.166 .048 -.225 -.078 .001
HUM2 .062 -.011 -.228 .127 -.052 .448a -.294 .001 .360 -.048 -.027 .036 .011 .005 .130 -.323 .111 -.074 .149 -.106 .008 .006 -.123 .123 -.064 .125
HUM3 -.063 .148 -.063 -.248 -.065 -.294 .590a -.074 -.017 -.092 -.041 .121 -.242 -.005 .177 .024 .147 .105 -.060 -.185 .107 -.081 .030 -.057 -.106 .100
HUM4 -.084 .128 -.069 -.123 .005 .001 -.074 .765 a -.085 -.270 .066 .075 .086 .028 .016 -.190 -.053 .119 .009 -.043 .215 .029 -.152 -.225 -.110 -.177
INT1 -.090 .076 -.132 .024 -.184 .360 -.017 -.085 .587 a -.212 -.148 .218 -.058 -.058 .182 -.353 .235 .060 .107 -.186 -.055 .210 -.274 -.046 -.041 .136
INT2 .040 -.225 .191 .053 -.038 -.048 -.092 -.270 -.212 .646a -.215 -.174 -.097 .186 -.067 .048 .089 -.294 -.171 .056 -.321 .042 .117 .246 -.048 .032
INT3 .156 .020 -.265 .003 .311 -.027 -.041 .066 -.148 -.215 .620 a -.153 -.095 -.086 -.144 .088 -.033 .060 .042 .166 .284 -.289 -.068 -.159 .005 -.140
INT4 .019 .117 -.102 -.280 -.271 .036 .121 .075 .218 -.174 -.153 .629a -.207 -.179 .209 -.153 -.023 .195 -.087 -.143 .061 .184 -.081 .001 .036 .013
INT5 .132 .145 .066 .011 -.201 .011 -.242 .086 -.058 -.097 -.095 -.207 .820a -.159 -.167 -.106 -.176 .037 -.043 -.032 -.080 .001 -.232 .091 .082 -.333
PRO1 -.332 .029 .033 .241 .183 .005 -.005 .028 -.058 .186 -.086 -.179 -.159 .752 a -.306 .020 -.056 .177 -.064 -.136 -.167 -.022 -.085 -.254 -.051 .074
PRO2 .016 .065 -.260 -.263 -.040 .130 .177 .016 .182 -.067 -.144 .209 -.167 -.306 .719a -.249 .063 .051 -.049 -.059 -.136 .088 -.057 -.043 -.043 .296
QUA1 .056 -.162 .060 -.032 .066 -.323 .024 -.190 -.353 .048 .088 -.153 -.106 .020 -.249 .626 a -.343 .008 -.026 .221 .093 -.228 .212 -.085 .172 -.089
RIS1 .015 -.002 .032 -.136 .020 .111 .147 -.053 .235 .089 -.033 -.023 -.176 -.056 .063 -.343 .645 a -.406 .113 -.196 .058 .075 -.049 .154 -.405 .065
RIS2 -.237 .307 -.181 .177 .032 -.074 .105 .119 .060 -.294 .060 .195 .037 .177 .051 .008 -.406 .619a -.252 -.106 -.053 -.056 -.269 -.350 .302 -.224
RIS3 -.150 -.060 -.055 -.028 -.044 .149 -.060 .009 .107 -.171 .042 -.087 -.043 -.064 -.049 -.026 .113 -.252 .812 a -.228 .163 -.060 .131 -.185 -.020 .121
SCO1 .109 -.179 -.256 .021 .114 -.106 -.185 -.043 -.186 .056 .166 -.143 -.032 -.136 -.059 .221 -.196 -.106 -.228 .633a -.161 .097 .334 .023 .208 -.164
SCO2 -.036 -.009 .053 -.284 .094 .008 .107 .215 -.055 -.321 .284 .061 -.080 -.167 -.136 .093 .058 -.053 .163 -.161 .664 a -.443 -.045 .000 -.232 -.223
SCO3 .071 -.053 -.176 -.093 -.166 .006 -.081 .029 .210 .042 -.289 .184 .001 -.022 .088 -.228 .075 -.056 -.060 .097 -.443 .591a .172 -.127 -.015 .243
STA1 .028 -.245 .012 -.194 .048 -.123 .030 -.152 -.274 .117 -.068 -.081 -.232 -.085 -.057 .212 -.049 -.269 .131 .334 -.045 .172 .670a -.201 .012 .137
STA2 .051 -.080 .271 .075 -.225 .123 -.057 -.225 -.046 .246 -.159 .001 .091 -.254 -.043 -.085 .154 -.350 -.185 .023 .000 -.127 -.201 .747 a -.115 -.176
TIM1 -.041 .001 -.154 -.010 -.078 -.064 -.106 -.110 -.041 -.048 .005 .036 .082 -.051 -.043 .172 -.405 .302 -.020 .208 -.232 -.015 .012 -.115 .666a -.128
TIM2 .133 -.200 -.133 -.011 .001 .125 .100 -.177 .136 .032 -.140 .013 -.333 .074 .296 -.089 .065 -.224 .121 -.164 -.223 .243 .137 -.176 -.128 .668 a
a. Measures of Sampling Adequacy(MSA)
Tabel: Uji Kecukupan dengan Anti-image Matrices (tanpa HUM2)
95
Anti-image Matrices
COM1 COM2 COM3 COS1 HUM1 HUM3 HUM4 INT1 INT2 INT3 INT4 INT5 PRO1 PRO2 QUA1 RIS1 RIS2 RIS3 SCO1 SCO2 SCO3 STA1 STA2 TIM1 TIM2
Anti-image COM1 .735a -.288 -.192 -.118 -.093 -.047 -.085 -.121 .043 .158 .017 .131 -.333 .008 .080 .008 -.234 -.162 .117 -.037 .070 .036 .044 -.037 .127
Correlation COM2 -.288 .570a -.022 .114 -.259 .151 .128 .086 -.225 .020 .117 .145 .029 .067 -.175 -.001 .307 -.059 -.181 -.008 -.053 -.248 -.079 .001 -.200
COM3 -.192 -.022 .704 a .113 -.116 -.139 -.071 -.055 .185 -.279 -.097 .070 .035 -.239 -.014 .060 -.204 -.022 -.289 .057 -.179 -.017 .309 -.173 -.108
COS1 -.118 .114 .113 .656a .155 -.222 -.124 -.023 .060 .006 -.287 .009 .242 -.284 .009 -.152 .189 -.048 .035 -.288 -.095 -.182 .060 -.002 -.027
HUM1 -.093 -.259 -.116 .155 .666 a -.084 .005 -.178 -.041 .311 -.269 -.201 .184 -.033 .052 .026 .028 -.036 .110 .094 -.165 .042 -.220 -.081 .008
HUM3 -.047 .151 -.139 -.222 -.084 a -.077 .100 -.111 -.051 .138 -.249 -.003 .227 -.078 .189 .087 -.018 -.227 .114 -.082 -.006 -.023 -.131 .145
.533
a
HUM4 -.085 .128 -.071 -.124 .005 -.077 .761 -.091 -.270 .066 .075 .086 .028 .016 -.200 -.053 .119 .010 -.043 .215 .029 -.153 -.227 -.111 -.179
INT1 -.121 .086 -.055 -.023 -.178 .100 -.091 .655 a -.209 -.148 .220 -.066 -.064 .147 -.269 .211 .093 .057 -.159 -.062 .223 -.248 -.098 -.019 .099
a
INT2 .043 -.225 .185 .060 -.041 -.111 -.270 -.209 .645 -.216 -.172 -.097 .187 -.061 .034 .095 -.298 -.166 .051 -.321 .042 .112 .255 -.051 .038
INT3 .158 .020 -.279 .006 .311 -.051 .066 -.148 -.216 .617a -.152 -.095 -.085 -.141 .083 -.030 .058 .046 .164 .284 -.289 -.072 -.157 .004 -.137
INT4 .017 .117 -.097 -.287 -.269 .138 .075 .220 -.172 -.152 .626 a -.208 -.180 .206 -.150 -.027 .199 -.093 -.140 .061 .184 -.077 -.004 .038 .008
INT5 .131 .145 .070 .009 -.201 -.249 .086 -.066 -.097 -.095 -.208 .817a -.159 -.170 -.109 -.178 .038 -.045 -.031 -.080 .001 -.233 .090 .083 -.337
PRO1 -.333 .029 .035 .242 .184 -.003 .028 -.064 .187 -.085 -.180 -.159 .749a -.310 .023 -.057 .178 -.066 -.136 -.168 -.022 -.085 -.256 -.051 .074
PRO2 .008 .067 -.239 -.284 -.033 .227 .016 .147 -.061 -.141 .206 -.170 -.310 .727a -.221 .049 .062 -.070 -.046 -.139 .087 -.042 -.060 -.035 .284
QUA1 .080 -.175 -.014 .009 .052 -.078 -.200 -.269 .034 .083 -.150 -.109 .023 -.221 .692a -.326 -.016 .024 .199 .101 -.238 .184 -.048 .160 -.052
RIS1 .008 -.001 .060 -.152 .026 .189 -.053 .211 .095 -.030 -.027 -.178 -.057 .049 -.326 .656a -.402 .098 -.186 .058 .075 -.036 .143 -.401 .052
RIS2 -.234 .307 -.204 .189 .028 .087 .119 .093 -.298 .058 .199 .038 .178 .062 -.016 -.402 .617a -.244 -.115 -.052 -.056 -.281 -.345 .298 -.217
RIS3 -.162 -.059 -.022 -.048 -.036 -.018 .010 .057 -.166 .046 -.093 -.045 -.066 -.070 .024 .098 -.244 .825a -.216 .164 -.062 .152 -.207 -.011 .105
SCO1 .117 -.181 -.289 .035 .110 -.227 -.043 -.159 .051 .164 -.140 -.031 -.136 -.046 .199 -.186 -.115 -.216 .636a -.161 .098 .325 .036 .203 -.153
SCO2 -.037 -.008 .057 -.288 .094 .114 .215 -.062 -.321 .284 .061 -.080 -.168 -.139 .101 .058 -.052 .164 -.161 .661a -.443 -.045 -.001 -.232 -.226
SCO3 .070 -.053 -.179 -.095 -.165 -.082 .029 .223 .042 -.289 .184 .001 -.022 .087 -.238 .075 -.056 -.062 .098 -.443 .581a .174 -.128 -.015 .244
a
STA1 .036 -.248 -.017 -.182 .042 -.006 -.153 -.248 .112 -.072 -.077 -.233 -.085 -.042 .184 -.036 -.281 .152 .325 -.045 .174 .681 -.189 .004 .155
a
STA2 .044 -.079 .309 .060 -.220 -.023 -.227 -.098 .255 -.157 -.004 .090 -.256 -.060 -.048 .143 -.345 -.207 .036 -.001 -.128 -.189.740 -.108 -.194
TIM1 -.037 .001 -.173 -.002 -.081 -.131 -.111 -.019 -.051 .004 .038 .083 -.051 -.035 .160 -.401 .298 -.011 .203 -.232 -.015 .004-.108 .669a -.121
TIM2 .127 -.200 -.108 -.027 .008 .145 -.179 .099 .038 -.137 .008 -.337 .074 .284 -.052 .052 -.217 .105 -.153 -.226 .244 .155-.194 -.121 .677a
a. Measures of Sampling Adequacy(MSA)
96
LAMPIRAN 4. ANALISA KOMPONEN UTAMA
i. Hasil Analisa Faktor (Komponen Utama, Eigen value >1  8 komponen)
Tabel: Analisa Komponen Utama yang dibentuk melalui metode Varimax

Total Variance Explained
Extraction Sums of Squared Rotation Sums of Squared
Initial Eigenvalues Loadings Loadings
% of Cumulative % of Cumulative % of Cumulative
Component Total Variance % Total Variance % Total Variance %
1 5.722 22.887 22.887 5.722 22.887 22.887 2.657 10.628 10.628
2 2.397 9.590 32.476 2.397 9.590 32.476 2.501 10.004 20.631
3 1.868 7.470 39.946 1.868 7.470 39.946 2.241 8.965 29.597
4 1.666 6.663 46.610 1.666 6.663 46.610 2.230 8.922 38.518
5 1.415 5.659 52.269 1.415 5.659 52.269 1.911 7.643 46.161
6 1.306 5.224 57.493 1.306 5.224 57.493 1.770 7.081 53.242
7 1.164 4.658 62.151 1.164 4.658 62.151 1.648 6.594 59.835
8 1.022 4.086 66.237 1.022 4.086 66.237 1.601 6.402 66.237
Scree plot 8 komponen tersebut dengan Eigenvalue > 1, sebagai berikut:
Gambar: Scree Plot (Sumber: SPSS)
97
ii. Perbandingan auto 8 komponen versus manual 6 dan 7 komponen
Tabel: Loading factor 8 komponen
8 Komponen (N=25)

Extraction Sums of Rotation Sums of Squared Rotated Component Matrix a
Initial Eigenvalues Squared Loadings Loadings Component
Compone % of Cumulativ % of Cumulativ % of Cumulativ
nt Total Variance e% Total Variance e% Total Variance e% N 1 2 3 4 5 6 7 8
1 5.722 22.887 22.887 5.722 22.887 22.887 2.657 10.628 10.628 1 RIS2 .794
2 2.397 9.590 32.476 2.397 9.590 32.476 2.501 10.004 20.631 2 SCO1 .701
3 1.868 7.470 39.946 1.868 7.470 39.946 2.241 8.965 29.597 3 TIM2 .606
4 1.666 6.663 46.610 1.666 6.663 46.610 2.230 8.922 38.518 4 RIS3 .581
5 1.415 5.659 52.269 1.415 5.659 52.269 1.911 7.643 46.161 5 STA1 .731
6 1.306 5.224 57.493 1.306 5.224 57.493 1.770 7.081 53.242 6 INT1 .722
7 1.164 4.658 62.151 1.164 4.658 62.151 1.648 6.594 59.835 7 STA2 .573
8 1.022 4.086 66.237 1.022 4.086 66.237 1.601 6.402 66.237 8 HUM4 .556
9 .989 3.955 70.192 9 SCO2 .863
10 .921 3.684 73.877 10 COS1 .612
11 .864 3.454 77.331 11 TIM1 .562
12 .745 2.979 80.310 12 SCO3
13 .678 2.710 83.020 13 INT2
14 .618 2.471 85.491 14 PRO1 .782
15 .562 2.246 87.737 15 PRO2 .677
16 .503 2.011 89.749 16 COM1 .544 .515
17 .464 1.856 91.605 17 COM2 .739
18 .422 1.688 93.293 18 HUM1 .738
19 .354 1.417 94.710 19 INT3
20 .330 1.320 96.031 20 QUA1 .718
21 .231 .926 96.957 21 RIS1 .631
22 .209 .834 97.791 22 HUM3 .728
23 .201 .802 98.593 23 COM3
24 .190 .760 99.353 24 INT4 .787
25 .162 .647 100.000 25 INT5 .525
Extraction Method: Principal Component Analysis. Extraction Method: Principal Component Analysis.
Rotation Method: Varimax with Kaiser Normalization.
a. Rotation converged in 16 iterations.

7 Komponen (N=25)

Extraction Sums of Rotation Sums of Squared Rotated Component Matrix a
Initial Eigenvalues Squared Loadings Loadings Component
Compone % of Cumulativ % of Cumulativ % of Cumulativ
nt Total Variance e% Total Variance e% Total Variance e% 1 2 3 4 5 6 7
1 5.722 22.887 22.887 5.722 22.887 22.887 2.796 11.184 11.184 STA1 .707
2 2.397 9.590 32.476 2.397 9.590 32.476 2.607 10.428 21.613 INT1 .662
3 1.868 7.470 39.946 1.868 7.470 39.946 2.464 9.855 31.467 HUM4 .637
4 1.666 6.663 46.610 1.666 6.663 46.610 2.255 9.022 40.489 STA2 .602
5 1.415 5.659 52.269 1.415 5.659 52.269 2.028 8.111 48.600 INT3
6 1.306 5.224 57.493 1.306 5.224 57.493 1.757 7.029 55.629 QUA1
7 1.164 4.658 62.151 1.164 4.658 62.151 1.631 6.522 62.151 RIS2 .796
8 1.022 4.086 66.237 TIM2 .686
9 .989 3.955 70.192 RIS1 .588
10 .921 3.684 73.877 SCO1 .581
11 .864 3.454 77.331 RIS3
12 .745 2.979 80.310 SCO2 .796
13 .678 2.710 83.020 TIM1 .648
14 .618 2.471 85.491 COS1 .612
15 .562 2.246 87.737 SCO3 .579
16 .503 2.011 89.749 PRO1 .772
17 .464 1.856 91.605 PRO2 .639
18 .422 1.688 93.293 COM1 .567 .542
19 .354 1.417 94.710 COM2 .727
20 .330 1.320 96.031 HUM1 .689
21 .231 .926 96.957 HUM3 .716
22 .209 .834 97.791 COM3 .508
23 .201 .802 98.593 INT2
24 .190 .760 99.353 INT4 .795
25 .162 .647 100.000 INT5 .526
Extraction Method: Principal Component Analysis. Extraction Method: Principal Component Analysis.
Rotation Method: Varimax with Kaiser
Normalization.
98
6 Komponen (N=25)
a
Total Variance Explained Rotated Component Matrix
Compone Extraction Sums of Rotation Sums of Squared
nt Initial Eigenvalues Squared Loadings Loadings Component
% of Cumulativ % of Cumulativ % of Cumulativ
Total Variance e% Total Variance e% Total Variance e% 1 2 3 4 5 6
1 5.722 22.887 22.8875.722 22.887 22.887 2.755 11.018 11.018 STA1 .788
2 2.397 9.590 32.4762.397 9.590 32.476 2.612 10.448 21.466 STA2 .635
3 1.868 7.470 39.9461.868 7.470 39.946 2.592 10.369 31.834 INT1 .594
4 1.666 6.663 46.6101.666 6.663 46.610 2.300 9.199 41.034 HUM4 .508
5 1.415 5.659 52.2691.415 5.659 52.269 2.112 8.447 49.481 QUA1
6 1.306 5.224 57.4931.306 5.224 57.493 2.003 8.012 57.493 SCO2 .782
7 1.164 4.658 62.151 TIM1 .639
8 1.022 4.086 66.237 COS1 .616
9 .989 3.955 70.192 SCO3 .596
10 .921 3.684 73.877 PRO2 .569
11 .864 3.454 77.331 RIS3 .694
12 .745 2.979 80.310 COM3 .633
13 .678 2.710 83.020 SCO1 .587
14 .618 2.471 85.491 COM1 .582
15 .562 2.246 87.737 PRO1 .450 .540
16 .503 2.011 89.749 TIM2 .751
17 .464 1.856 91.605 RIS1 .672
18 .422 1.688 93.293 RIS2 .464 .652
19 .354 1.417 94.710 HUM3 .690
20 .330 1.320 96.031 INT4 .570
21 .231 .926 96.957 INT5 .407 .524
22 .209 .834 97.791 INT3 .442
23 .201 .802 98.593 HUM1 .687
24 .190 .760 99.353 COM2 .684
25 .162 .647 100.000 INT2 .432
Extraction Method: Principal Component Analysis. Extraction Method: Principal Component
Analysis.
Rotation Method: Varimax with Kaiser
Penelitian menggunakan penentuan komponen menjadi 6, agar terbentuk

pengelompokkan dengan jumlah anggota dalam komponen yang cukup mewakili,
yaitu komponen (faktor) minimal memiliki anggota (sub-faktor) minimal 3.
99
iii. Interpretasi Faktor Laten
Tabel: Interpretasi FaktorLaten
S ub - Ko d e Ind ik a to r P e rny a ta a n Bo b o t Fa k to r La te n
Fa c to r V a ria n ( c o ns truc t)
1a STA1 Hubungan Sosial Politik Hubungan sosial dan politik dengan client 0.788 Kepemimpan Non-
1b STA2 Keterlibatan Pemangku bermasalah.keterlibatan pengguna-kunci (key user)
Rendahnya 0.635 Simpatik
Kepentingan saat requirement gathering. (sympathetic leadership
1c INT1 Kemampuan Manajer Manajer proyek tidak mampu menangani lingkungan 0.594 problem)
Proyek proyek yang tidak pasti.
1d HUM4 Masalah Penugasan Terjadi masalah dalam internal tim karena 0.508
ketimpangan (kesalahan) dalam pembagian tugas.
1e QUA1 Anggaran QA Anggaran untuk Quality Assurance sangat terbatas. <0.5
2a SCO2 Perubahan Permintaan Permintaan perubahan yang berdampak pada biaya 0.782 Ketidak-pedulian akan
seringkali tidak disepakati oleh client. Prinsip Keterbatasan
Biaya
2b TIM1 Ketergantungan Pada Adanya permintaan yang bergantung pada pekerjaan 0.639 (Cost-base Unconcerned)
Pihak Lain pihak lain.
2c COS1 Trade-off of project Customer tidak bersedia mengurangi 'scope'. 0.616

constraints
2d SCO3 Permintaan Berlebih Client seringkali meminta fitur-fitur yang tidak berkaitan 0.596
(Over-requirement) langsung dengan kebutuhan bisnis.
2e PRO2 Proses Penganggaran Terjadi selisih yang jauh antara anggaran buyer 0.569
dengan harga oleh vendor.
3a RIS3 Tanggapan atas Resiko Tanggapan atas Resiko sering menggantung tanpa 0.694 Resiko Laten (Latent Risk)
tindakan. Terabaikan
3b COM3 Laporan Kinerja Manajemen tidak menguji keakuratan laporan kinerja 0.633
3c SCO1 Arahan Cakupan proyek.
Manajemen-atas tidak terlibat langsung dalam 0.587
Pekerjaan mengarahkan cakupan pekerjaan.
3d COM1 Masalah Proyek Masalah dan resiko proyek tidak disampaikan 0.582
3e PRO1 Price-to-win Terjadi perilaku 'under-estimate' oleh vendor untuk 0.540
memenangkan tender.
4a TIM2 Perencanaan Waktu Perencanaan proyek tidak mengantisipasi perincian 0.751 Toleransi Jadwal
analisa kebutuhan.
4b RIS1 Toleransi Manajemen Manajemen-atas tidak toleran mengenai 0.672
kemungkinan/dampak resiko.
4c RIS2 Pengujian Resiko Pengujian resiko tidak detil dan menyeluruh di tahap 0.652
5a HUM3 Suksesi kepemimpinan Terjadi suksesi pada proyek manajer, atau sponsor 0.690 Psikologi Kegagalan
5b INT4 Tujuan Tidak Realistis Tujuan proyek dianggap tidak realistik oleh manajer 0.570 (Pessimistic To Achieve)
5c INT5 Strategi Proyek Tata-kelola proyek tidak disesuaikan dengan strategi 0.524
bisnis (seperti: keunggulan produk, atau time-to-
5d INT3 Model Hasil Customer tidak memiliki contoh konkrit tentang hasil <0.5
dari proyek yang akan dibuat.
6a HUM1 Komunikasi internal tim Komunikasi verbal tim internal proyek tidak lancar. 0.687 Komunikasi Tidak Efektif
6b COM2 Perencanaan Komunikasi Kesepakatan rencana komunikasi (communication 0.684
plan) tidak berjalan efektif.
6c INT2 Metodologi Proyek Salah memilih metode untuk proyek dengan tingkat <0.5
perubahan permintaan yang tinggi.
100
LAMPIRAN 5. REGRESI LINEAR BERGANDA
b
Model Summary
Model R R Adjusted Std. Error Change Statistics

Square R-Square of the R Square F Change df1 df2 Sig. F
Estimate Change Change
a
1 .264 .070 .003 2.056 .070 1.038 6 83 .407
a. Predictors: (Constant), REGR factor score 6 for analysis 5, REGR factor score 5 for
analysis 5, REGR factor score 4 for analysis 5, REGR factor score 3 for analysis 5, REGR
factor score 2 for analysis 5, REGR factor score 1 for analysis 5
b. Dependent Variable: PROBLEM_WGHT
a
ANOVA
Model Sum of Squares df Mean Square F Sig.

b
Regression 26.329 6 4.388 1.038 .407
1 Residual 350.793 83 4.226
Total 377.122 89
a. Dependent Variable: PROBLEM_WGHT

b. Predictors: (Constant), REGR factor score 6 for analysis 5, REGR factor score 5 for
analysis 5, REGR factor score 4 for analysis 5, REGR factor score 3 for analysis 5,
REGR factor score 2 for analysis 5, REGR factor score 1 for analysis 5
a
Coefficients
Model Unstandardized Standardized t Sig.

Coefficients Coefficients
B Std. Error Beta
1 (Constant) 6.744 .217 31.123 .000
REGR factor score 1 for analysis 5 .211 .218 .102 .967 .336
REGR factor score 2 for analysis 5 .261 .218 .127 1.199 .234
REGR factor score 4 for analysis 5 -.357 .218 -.173 -1.636 .106
a. Dependent Variable: PROBLEM_WGHT
101
LAMPIRAN 6. KOMENTAR TAMBAHAN RESPONDEN
i. Komentar Mengenai Ukuran Kegagalan Proyek

Tabel: Komentar Ukuran Kegagalan
No YA TIDAK
1. Ukuran kegagalan utama adalah Value yang didapat oleh bisnis dengan
software tdk memenuhi menggunakan sistem tersebut
kebutuhan bisnis (system drives
business, not the otherwise)
2. Dan tidak sesuai requirement key- Karena ada delay yang disebabkan oleh pihak
users customer
3. Penghitungan nilai proyek harus Requirement yang tidak detail dan jelas jg bs
tepat bila tidak maka akan rugi menyebabkan kegagalan suatu project.
Management yg tdk commit itu jg merupakan
salah satu factor.
4. Quality Tidak apa-apa telat / over budget apabila
softwarenya akhirnya bisa terdelivery dan laku di
pasaran atau disenangi end user
5. Memenuhi requirement Selama over-schedule dan over budget sudah
disampaikan di awal dan mendapat persetujuan
dari stack holder.
6. Banyak sebab dan penyebab
7. Over budget project dapat di closed dgn me-
reduce scope (descoping)
8. Tidak selalu.
102
ii. Komentar Tindakan Terhadap Proyek Bermasalah
Tabel: Komentar Status Kelanjutan Proyek
No YA TIDAK
1. Yg paling kritikal utk di-asses adl pd Kecuali jika komitmen bersama dibuat.
tahap awal pengambilan keputusan utk
membeli software. Saat proyek sudah
diputuskan untuk dijalankan, maka harus
dituntaskan
2. Jika proyek tersebut akan berdampak Kalau proyek masalah akan berulang maka
pada kelangsungan bisnis perusahaan dihentikan saja.
dimasa mendatang, maka proyek harus
dilanjutkan.
3. Kendali resiko perlu diperhatikan Kalau resikonya terlalu besar buat company
sebaiknya jangan dilanjutkan
4. Tidak perlu, itu tergantung dari Stack
Holder, jika dirasa sudah dangat rugi atau
project diluar expectasi, salah satu stak
holder dapat menghentikan project. selama
hl ini tertera pada contract agreement antara
customer dan vendor/supplier.
5. Tergantung kesepakatan
iii. Komentar Tambahan Tentang Masalah Dalam Proyek
Tabel: Komentar Tambahan Bebas

No Komentar Tambahan
1. Proyek gagal diukur juga dari kualitas yg tidak sesuai.
2. Aspek budaya kerja didalam perusahaan tempat project tersebut dilakukan juga memberikan
konstribusi terhadap keberhasilan atau kegagalan project. Contoh : perusahaan yg
mempunyai budaya kerja utk menghargai vendor sbg mitra kerja dibanding sebagai
"pembantu" akan mempunyai kemungkinan keberhasilan yang tinggi.
3. Project tidak selalu berhasil (sukses), adakalanya gagal atau harus dihentikan. jadi perlu
selalu dimonitoring per segment dan dianalisa apakah sesuai harapan atau tidak.?
4. Communication dan negotiation skill termasuk hal utama yg menentukan keberhasilan
proyek
5. Project dpt berjalan lancar apabila ada commitment dr semua pihak. Tanpa hal diatas tdk
akan mungkin tercapai.
6. Korelasi antara proyek harus terus dilanjutkan dengan menempuh resiko apapun dan sebagai
alasan untuk penerapan visi/strategi bisnis harusnya dikaji ulang oleh para stakeholder dan di
adjust strategi nya dengan disesuaikan banyak hal.
103
7. Keberhasilan dari sebuah project development lebih kepada komunikasi yang baik dan
management komitmen.
8. Keputusan kelanjutan proyek yang bermasalah harus didasari pada justifikasi biaya yang
detil - misal melalui Cost Benefit Analysis. Meskipun sebuah proyek itu dinilai strategis,
tapi kalau biaya untuk melanjutkan proyek itu lebih besar dari nilai keuntungan yang akan
diperoleh, sebaiknya proyek itu dihentikan. Peran Project Management Office (PMO)
sangatlah penting dalam sebuah organisasi untuk memberikan masukan terhadap proyek
yang sekarang berjalan atau akan berjalan - apakah diteruskan (commit), dihentikan (kill)
atau direstrukturisasi (transform).
9. Dalam proyek implementasi System Integration IT, kendala yang sering menjadi momok
adalah: - informasi terhadap existing system tidak dikuasai dengan akurat ( vendor
menggampangkan atau end-user malas memberikan data yang detil) - perubahan spek saat
tes UAT atau Design Review karena adanya permintaan tambahan dari user - hubungan
sosial dan kerjasama antara tim proyek dan tim business user tidak selaras dan kompak Ke
3 alasan utama di atas seringkali tidak didukung dengan fleksibilitas tambahan anggaran dan
tambahan waktu dari pemilik proyek (end-user).
10. Kesuksesan proyek diukur dari aspek berikut : 1. Tercapainya kepuasan pelanggan 2.
Tercapainya qualitas yang dijanjikan 3. On bugdet 4. On schedule 5. On scope 6. Meet or
exceed stakeholder expectation.
11. Menurut saya, ada beberapa masukan kenapa Perangkat Lunak sering gagal dalam
implementasi: 1. HW yg di gunakan tidak sepenuhnya mendukung dari SW yg akan di
gunakan, salah mendimensi HW 2. Salah menghitung data input yg akan diprocess terhadap
dimensi HW 3. Salah metode pengolahan data, terhadap flow SW yg di buat, sehingga
memakan resources terlalu banyak 4. SW belum di test, atau tidak pernah di test di Lab;
test yg sebaiknya dilakukan di lab adalah; Stress Test, Load Test, negative test, etc 5. SW
belum sempurna tapi harus di install karena tengat waktu 6. Team tidak available saat di
butuhkan 7. Team implemntasi tidak mendapat informasi yg jelas dan lengkap dari
pengembang(Developer) kira-2 itu tambhaan dari saya; Thanks, <nama dihilangkan>
12. Intinya dalam suatu proyek , antara vendor dengan client/user tidak boleh ada gap. Pada saat
proyek sudah berjalan maka kedua belah pihak harus mempunyai kesamaan persepsi dan
tujuan. Bahwa sekarang sudah dalam satu kapal/satu team yang mempunyai goal yang sama.
Meskipun mempunyai fungsi masing2.
13. Project merupakan tanggung jawab seluruh pihak baik stakeholder maupun shareholder dan
tidak semata2 dibebankan pada seorang Project Manager
14. Seringkali proyek diinisiasi tanpa business case yg jelas dan terukur sehingga sebelum,
selama dan setelah proyek berlangsung pengukuran benefits dari proyek susah diterapkan.
Selain itu, pengelolaan project stakeholders ditataran strategic dan operasional yang tidak
secara serius diterapkan akan menghambat keberhasilan proyek.
15. "Requirement" untuk mengerti kemauan customer adalah step yang sangat menentikan
sukses tidaknya projek.
16. Proyek Perangkat Lunak ataupun proyek di bidang lainnya secara general harusnya dianggap
sebagai "Business Project", sehingga pengukuran tingkat keberhasilannya lebih kebaga
104
seberapa besar values yang bisa ditambahkan terhadap customer/owner of the project, tidak
hanya berdasarkan schedule atau budget. Dan karena business terus berjalan serta berubah,
kadang perlu dilakukan penyesuaian dalam perjalanan suatu proyek. Yang ekstrimnya bisa
saja suatu proyek dihentikan karena values yang akan diberikan sudah tidak inline terhadap
business ke depan.
17. Dalam hal vendor, kesalahan-kesalahan banyak terjadi dari fakstor eksternal dan tidak
semata-mata kesalahan pelaksana project. Diantaranya adalah senior manajemen vendor
yang kurang memiliki concern terhadap utilisasi dan kinerja tim delivery dan kurangnya
mekanisme bagi orang delivery untuk melakukan cross check terhadap risiko yang umumnya
terjadi saat draft kontrak masih berada dalam fase engagement.
18. Didalam pengelolaan proyek hal penting yang harus dilakukan adalah komunikasi yang baik
secara internal team dan external team. Keluwesan manajer proyek sangat dibutuhkan dalam
pengelolaan proyek.
19. Sering project harus lanjut dengan semua tambahan biaya dan resikonya karena sifatnya
strategis. Yg lebih penting bagaimana recovery plan nya.
20. Proyek bermasalah atau beresiko tinggi sebaik nya dikomunikasikan atau disepakati dengan
memecah scope menjadi beberapa fase menghindarkan kegagalan yang kurang perlu.
21. Manajemen atas berperan besar.
22. Belum ada konteks leadership.
105

Model Evaluasi Faktor Penyebab Kegagalan Proyek Sistem Informasi Untuk Perangkat Lunak Di Perusahaan

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Model Evaluasi Faktor Penyebab Kegagalan Proyek Sistem Informasi Untuk Perangkat Lunak Di Perusahaan

Diunggah oleh

Hak Cipta:

Format Tersedia

MODEL EVALUASI FAKTOR PENYEBAB KEGAGALAN PROYEK

SISTEM INFORMASI UNTUK PERANGKAT LUNAK DI PERUSAHAAN

Program Studi Magister Manajemen

MODEL EVALUASI FAKTOR PENYEBAB KEGAGALAN PROYEK

SISTEM INFORMASI UNTUK PERANGKAT LUNAK DI PERUSAHAAN

yang dipersiapkan dan disusun oleh

Dosen Penguji I Dosen Penguji II

Dosen Penguji III/Pembimbing

Dr. Wahyu Sardjono, M.M

pernah diajukan untuk memperoleh gelar kesarjanaan di suatu Perguruan Tinggi,

dalam naskah ini dan disebutkan dalam daftar pustaka.

Jakarta, 8 Desember 2014

Lembar Judul ………………………………………………………………… i

Lembar Pengesahan ………………………………………………………….. ii

Lembar Pernyataan ….….….….….….….….….….….….….….….….….….. iii

Kata Pengantar ….….….….….….….….….….….….….….….….….….…... iv

Daftar Isi ….….….….….….….….….….….….….….….….….….….….…... v

Daftar Tabel ….….….….….….….….….….….….….….….….….….….…... ix

Daftar Gambar ….….….….….….….….….….….….….….….….….….…… x

Daftar Lampiran ….….….….….….….….….….….….…. …………………. xi

Daftar Singkatan .…………………………………………………………….. xii

Intisari ……...….….….….….….….….….….….….….….….….….….….…. xiii

Abstraks ….….….….….….….….….….….….….….….….….….….….…… xiv

BAB I. PENDAHULUAN .......................................................................................1

1.1. Latar Belakang Permasalahan ..................................................................... 1

1.2. Rumusan/identifikasi Masalah .................................................................... 5

1.3. Pertanyaan Penelitian .................................................................................. 7

1.4. Tujuan Penelitian ......................................................................................... 8

1.5. Manfaat Penelitian ....................................................................................... 8

1.6. Ruang Lingkup dan Batasan Penelitian ....................................................... 9

1.7. Sistematika Penulisan .................................................................................. 9

BAB II. LANDASAN TEORI ...............................................................................11

2.1. Tinjauan Pustaka/Landasan Teori ............................................................. 11

2.1.2. Bisnis dan Sistem Informasi .............................................................. 13

2.1.3. Project Management – Body Of Knowledge ..................................... 17

2.1.4. Konsep Dan Indikator ........................................................................ 20

2.1.4.1 Konsep Tata-kelola Komunikasi (Communication Management)

2.1.4.2 Konsep Tata-kelola Biaya (Cost Management) .......................... 30

2.1.4.3 Konsep Tata-kelola Sumber Daya Manusia (Human Resource

2.1.4.4 Konsep Tata-kelola Integrasi (Integration Management)........... 32

2.1.4.5 Konsep Tata-kelola Pengadaan Barang (Procurement

2.1.4.6 Konsep Tata-kelola Kualitas (Quality Management) ................. 35

2.1.4.7 Konsep Tata-kelola Risiko (Risk Management) ......................... 35

2.1.4.8 Konsep Tata-kelola Cakupan (Scope Management) ................... 36

2.1.4.9 Konsep Tata-kelola Pemangku Kepentingan (Stakeholder

2.1.4.10 Konsep Tata-kelola waktu (Time Management) ....................... 39

2.1.5. Perangkat Lunak (Software) .............................................................. 40

2.1.6. Metodologi Pengembangan Perangkat Lunak ................................... 41

3.1 Jenis Penelitian ........................................................................................... 43

3.2 Lokasi dan Waktu Penelitian ...................................................................... 43

3.3 Sampel Penelitian ....................................................................................... 44

3.5 Definisi Istilah/Operasional ........................................................................ 45

3.6 Aspek Pengukuran ...................................................................................... 46

3.7 Metode Analisis Data ................................................................................. 47

3.8 Analisis Kelengkapan Data ........................................................................ 49

3.9 Alur Diagram Penelitian ............................................................................. 49

BAB IV. HASIL PENELITIAN ............................................................................51

4.1 Gambaran Responden................................................................................. 51

4.1.1 Pengalaman Bekerja ........................................................................... 51

4.1.2 Pengalaman Tentang Masalah ............................................................ 53

4.1.3 Penilaian Tingkat Masalah ................................................................. 55

4.1.4 Statistik Deskriptif Variabel Penelitian .............................................. 56

4.2 Keterbatasan Penelitian ........................................................................... 60