Modul 6 - Kominfo Jatim

Manajemen Proyek dan Pengadaan
MODUL 6
Tim Penyusun Modul Bimtek
Dan Sertifikasi Kompetensi Dasar
Government Chief Information Officer
2013
Kementerian Komunikasi dan Informatika
bekerja sama dengan
Institut Teknologi Bandung
Institut Teknologi Sepuluh November
Universitas Gajah Mada
Universitas Indonesia
KEMKOMINFO
Agenda
KEMKOMINFO
 Introduksi: Siklus produk
 Pengadaan (akuisisi) sebagai bagian dari siklus
produk
 Ragam metode pengadaan
 Manajemen proyek
 Tahapan dalam manajemen proyek dan aktivitasaktivitasnya
 Penutup
Siklus Hidup Produk
KEMKOMINFO
Ide/konsep
Realisasi
Penggunaan
Phasing out
Pengembangan/
Pembelian/
Penyewaan
Pengadaan
Manajemen proyek
Contoh: Aplikasi sistem informasi
Ide dan konsep dikembangkan saat perencanaan strategis dan/atau
operasional
Sistem dibuat mengikuti
prinsip-prinsip rekayasa
yang baku, dibawah
manajemen proyek
Operasionalisasi sistem
pada unit pengguna
Sistem perlu diganti atau
ditingkatkan dengan
yang baru
Pengadaan (Akuisisi)
KEMKOMINFO
 Istilah “Pengadaan” tidak seperti yang dimaksud dalam
Perpres 54/2010
 Pengadaan  Akuisisi (acquisition): the act of acquiring
or gaining possession (Dictionary.com Unabridged)
 Penekanan pada “dapat menggunakan karena penguasaan
terhadap sesuatu”
 “Penguasaan” tidak selalu berkonotasi “kepemilikan” (ownership),
tapi lebih pada hak dan kebebasan untuk menggunakan (rights
and freedom to use)
 “Penguasaan” tidak harus selalu membeli !
 Contoh: Bank sering mengadakan infrastruktur TIKnya dengan cara menyewa
(leasing), bukan membeli
Mode/Cara Pengadaan
KEMKOMINFO
Pengadaan dapat dilakukan dengan berbagai cara:
Pengembangan/pembuatan
 Secara mandiri (swakelola, in-house development)
 Outsource (dikerjakan pihak lain)
Pembelian jadi
Sewa (leasing)
Kustomisasi sistem yang ada
Pengembangan Mandiri (In-house)
KEMKOMINFO
 Hanya cocok dilakukan kalau institusi memiliki kapasitas
pengembangan yang memadai  biasanya hanya untuk
sistem-sistem perangkat lunak atau konten (bukan untuk
perangkat keras & jaringan)
 Kapasitas pengembangan ditentukan oleh:
 SDM (kompetensi, jumlah)
 Pengalaman (track record pengembangan sebelumnya)
 Sumber daya lainnya (ketersediaan pendanaan, tools, dan teknologi)
 Kewenangan pengambilan keputusan terkait kegiatan pengembangan
 Semua tahapan pengembangan dijalankan sendiri.
Keterlibatan pihak luar minimal (mis: sebagai technical
assistance/penasihat)
Pengembangan Mandiri (In House)
KEMKOMINFO
 Dijalankan oleh sebuah tim yang anggotanya
adalah personil di instansi pelaksana
 Keuntungan: lebih menguasai permasalahan 
kemungkinan keberhasilan implementasi lebih tinggi
 Kelemahan: kadang-kadang proses
pengembangan terganggu oleh tugas-tugas lain
yang dibebankan kepada tim
Pengembangan Outsource
KEMKOMINFO
 Proses pengembangan dijalankan oleh pihak lain yang
memiliki kemampuan
 Faktor-faktor yang harus dipertimbangkan:
 Kapasitas/kemampuan pengembangan
 Keberlanjutan sistem (outsource membangun ketergantungan
terhadap vendor)
 Pembelajaran institusi (outsource menghambat peluang bagi
instansi pemilik untuk belajar tentang pengembangan sistem)
 Regulasi/kebijakan
Pembelian Jadi (Out-of-the-Box Purchase)
KEMKOMINFO
 Hampir selalu dilakukan untuk perangkat keras/infrastruktur
 Untuk perangkat lunak, hanya cocok untuk sistem-sistem
yang sifatnya umum, bersifat utility
 Sistem aplikasi pada umumnya bersifat spesifik dan memiliki
requirements yang berbeda-beda  tidak bisa disamakan
 Contoh sistem yang bisa dibeli jadi: sistem operasi, aplikasi office,
aplikasi akuntansi sederhana
 Faktor-faktor pemilihan produk sistem
 Spesifikasi teknis: kesesuaian dengan kebutuhan
 Keberlanjutan: apakah produk yang dibeli tetap dikembangkan
pembuatnya , didukung update-nya, dan ada dukungan teknisnya
 Biaya (total cost of ownership – TCO, terutama untuk sistem
perangkat lunak): biaya-biaya pelatihan, dukungan teknis,
konsultasi, dll.
 Dukungan purna-jual
Pembelian Jadi (Out-of-the-Box Purchase)
KEMKOMINFO
 Faktor-faktor pemilihan vendor
 Harga yang ditawarkan
 Layanan (pra- dan purna-jual)
 Dukungan teknis yang diberikan
 Prospek keberlanjutan bisnis (kekuatan perusahaan,
penguasaan pasar, dsb)
 Ketaatan (compliance) terhadap syarat-syarat tertentu (mis:
punya NPWP, faktur pajak, keanggotaan dalam asosiasi,
dsb).
Sewa
KEMKOMINFO
 Mengapa menyewa ?
 Tidak ingin mengeluarkan usaha yang terlalu besar untuk pembuatan
sistem  terutama cocok untuk institusi yang tidak memiliki core business
dalam bidang TI, tetapi operasinya sangat tergantung pada TI (mis:
bank)
 Proses deployment lebih cepat
 Upgrade ke versi berikutnya secara lebih cepat
 Model bisnis baru: application service provider (ASP)
 Vendor ASP memberikan layanan aplikasi kepada institusi (institusi tidak
perlu memiliki aplikasi tsb)
 Institusi cukup memanfaatkan layanan, tidak mengurusi pembelian,
pembuatan, pemeliharaan aplikasi
 Titik kritis:
 keselarasan dengan proses bisnis: vendor ASP belum tentu memahami rincian
proses bisnis instansi penyewa
 pengelolaan data, terutama yang terkait dengan keamanan, kerahasiaan,
ketersediaan, dsb.
Sewa
KEMKOMINFO
 Menjadi semakin
populer seiring dengan
berkembangnya
teknologi cloud
computing  penyewa
tidak perlu tahu detil
implementasi dari
layanan-layanan
fungsional yang disewa
Detil hardware, jaringan, server,
database, dan aplikasi tidak terlihat
oleh pemakai.
Pemakai mengakses layanan-layanan
fungsional sesuai kebutuhan mereka
http://www.vedainformatics.com/blogs/cloud-computing-applications-real-test-case/
Kustomisasi
KEMKOMINFO
 Kustomisasi (penyesuaian sistem yang ada terhadap
kebutuhan spesifik) umum digunakan apabila proses
bisnis yang didukung bersifat generik dengan variasivariasi yang tidak terlalu banyak
 Syarat melakukan kustomisasi
 Pemahaman tentang proses bisnis yang akan didukung sistem
aplikasi
 Pemahaman tentang sistem aplikasi yang ada saat ini (existing)
 Spesifikasi kebutuhan kustomisasi (gap analysis)
 Kustomisasi dapat dilakukan secara mandiri (in-house)
atau outsource
 Pada umumnya kustomisasi dilakukan terhadap
perangkat lunak Open Source, yang lisensinya
mengijinkan dilakukannya perubahan pada source
code-nya
KEMKOMINFO
Pada cara pengadaan dengan pengembangan atau pembuatan
(baik secara mandiri atau outsource), ada proses yang harus
dijalankan. Proses ini melibatkan beberapa stakeholders,
memerlukan sumber daya, dan harus memenuhi sasaran-sasaran
yang telah ditetapkan sebelumnya.
Perlu pendekatan yang sistematis
dan berdisiplin dalam pelaksanaannya
Manajemen Proyek
Survei tentang Eksekusi Proyek TI
KEMKOMINFO
http://www.it-cortex.com/Stat_Failure_Rate.htm
 KPMG Canada Survey (1997) tentang manajemen
proyek TI
 Lebih 61% proyek dinyatakan gagal oleh responden
 The Chaos Report by Standish Group (1995)
 31.1% proyek dibatalkan sebelum dinyatakan selesai
 52.7% proyek mengalami kelebiha biaya sebesar 189% dari
perkiraan awalnya
Penyebab Kegagalan
KEMKOMINFO
http://www.it-cortex.com/Stat_Failure_Cause.htm
The Bull
Survey
(2001)
Definisi “Proyek”
KEMKOMINFO
 Rangkaian aktivitas sekali waktu yang memiliki tujuan
dan sasaran akhir yang jelas
 Karakteristik proyek
 Memiliki dukungan kepemilikan (tidak ada proyek “liar” tanpa
pemilik)
 Memiliki tanggal mulai dan tanggal berakhir yang spesifik
 Ruang lingkup yang terdefinisi dan terdokumentasi
 Memiliki anggaran yang terbatas
 Hasil akhir yang spesifik
 Batasan kualitas (output harus memenuhi spesifikasi kualitas ttt)
 Memerlukan sumber daya
 Proyek TIK: proyek dengan TIK sebagai obyek
Proyek TIK vs Proyek Non-TIK
KEMKOMINFO
Komponen
Proyek Non-TIK
Proyek TIK
Proyek
Tidak terintegrasi dengan
proses/fungsi bisnis
Biasanya terkait dengan fungsi
organisasi & proses bisnisnya
Struktur proyek
Sering bersifat stand-alone
Biasanya terkait dengan proyekproyek lain
Lingkup
Well-defined
Sulit dijelaskan dan mudah
berubah
Pengengalian
perubahan
Well-defined
Dapat dijelaskan, tapi sulit dilacak
Kebutuhan staf
Generalis, sering full-time
Spesialis, sering part-time
Resiko
Lebih mudah diidentifikasi,
sulit dikelola tapi tidak terlalu
berefek negatif
Tidak mudah diidentifikasi, sulit
dikelola dan sering berefek negatif
bagi organisasi
Pembelajaran
Cukup mudah
Sulit
Estimasi anggaran
dan penjadwalan
Mudah
Sulit
KEMKOMINFO
Proyek dalam Kerangka Perencanaan
TIK
Rangkaian kegiatan perencanaan TIK
Input bagi
proyek
mencerminkan
peran strategis TIK
dalam mencapai
tujuan organisasi
Tujuan
organisasi
dasar bagi
perencanaan
programprogram TIK
Tujuan
TIK
Analisis
kondisi
saat ini
implementasi
cara-cara
pencapaian
tujuan TIK
Indikator
dan
sasaran
cara untuk mengetahui
keberhasilan pencapaian tujuan
Program
dan
kegiatan
Timeline
dan
alokasi
sumber
daya
untuk keperluan
evaluasi dan
pemantauan
Dari Renstra ke Proyek
KEMKOMINFO
Renstra
Jangka panjang,
strategis
Renop
Renop
DIPA,
RKAT,
RBA,
Tahunan,
operasional
Proyek
Proyek
Proyek
(dan berbagai
nama lainnya)
Realisasi
Rencana Kegiatan  Proyek
KEMKOMINFO
Rencana Operasional
• Judul kegiatan
• Indikator & sasaran
• Anggaran
Proyek
• Terukur  bisa dipantau dan
Jika Rencana Operasional sudah dievaluasi
• Jelas kapan mulai & selesainya
baik (akurat), maka biasanya
• Jelas outputnya
sebuah kegiatan bisa langsung
diterjemahkan menjadi sebuah proyek.
Penyusunan rencana proyek bertujuan
membuat proyek tersebut menjadi
jelas dan terukur
Manajemen Proyek
KEMKOMINFO
Definisi: Sekumpulan prinsip, praktek, dan teknik yang
digunakan untuk memimpin tim proyek dan
mengatur jadwal proyek, biaya, dan risiko untuk
memberikan kepuasan bagi stakeholder
(Chapman, 1997)
Manajemen proyek memiliki unsur ilmiah maupun seni
 Seni  hubungan/relasi yang kuat dengan berbagai kelompok
 hubungan antar manusia (resolusi konflik, negosiasi, dsb.)
 Ilmiah  penggunaan metodologi dan tools teknis
Stakeholder Proyek
KEMKOMINFO
 Sebuah proyek selalu memiliki stakeholder (pihak yang
memiliki kepentingan terhadap proyek tersebut)
 Pengembang  menyelesaikan pengembangan dan mendapatkan
haknya
 Pemakai  mendapatkan hasil yang bisa membantunya menjalankan
tugas
 Pimpinan/manajer  memastikan proyek berjalan dengan baik secara
keseluruhan
 Lembaga pemeriksa  memastikan tidak ada penyimpangan di
dalam proyek
 Lembaga donor  memastikan bantuan yang diberikan dimanfaatkan
secara semestinya dan optimal
 Manajemen proyek mengusahakan setiap stakeholder
merasa sebagai pemenang (winner)  terakomodasi
kepentingannya
Tahapan Proyek
KEMKOMINFO
Biaya
Jadwal
Kegiatan
Inisiasi
Perencanaan
Output proyek
Eksekusi
Monitoring & Kontrol
Perencanaan ulang secara Iteratif,
untuk menghadapi dinamika dalam proyek
Penutupan
Tahap I: Inisiasi Proyek
KEMKOMINFO
 Kegiatan-kegiatan
 Persiapan-persiapan (administratif, logistik, dan sumber daya
lainnya)
 Kontrak
 Kick-off (memulai proyek secara resmi)
Tahap II: Perencanaan Proyek
KEMKOMINFO
 Kegiatan utama: estimasi (prakiraan)
 Estimasi diperlukan karena pada awal proyek kita
memerlukan ukuran-ukuran kuantitatif, sementara
data yang ada tidak mencukupi
 Banyak pertanyaan tentang biaya, waktu, dan sumber
daya yang diperlukan untuk menjalankan proyek
 Estimasi dilakukan terhadap ketiga aspek tersebut: biaya,
jadwal, dan sumber daya (SDM, sarana/fasilitas, dsb)
 Estimasi memerlukan pendefinisian lingkup (scope)
proyek
 Estimasi melibatkan unsur ilmiah & seni
 Ilmiah: penggunaan metode & tools
 Seni: penerimaan terhadap ketidakpastian
Penentuan Lingkup (Scope) Proyek
KEMKOMINFO
 Merinci kegiatan-kegiatan yang dijalankan dalam
proyek
 Harus bersifat “bounded” (ada batas-batas yang jelas,
tidak mengambang)
 Contoh: jangka waktu, biaya, sasaran/output, rincian kegiatan,
kebutuhan sumber daya, dsb.
 Faktor-faktor penting:
 Output: menetapkan apa yang seharusnya dicapai di akhir
proyek
 Kegiatan: mengidentifikasi aktivitas yang harus dijalankan untuk
mencapai output yang diinginkan
 Jadwal, kebutuhan sumber daya, dsb akan mengikuti rincian
kegiatannya
Penentuan Output Proyek
KEMKOMINFO
Output proyek harus
sejalan/memenuhi
indikator dan sasaran
yang ditetapkan pada Renop
Renstra
Renop
Renop
Proyek
Proyek
Proyek
Identifikasi Kegiatan Proyek
KEMKOMINFO
 Tiap kegiatan perlu diidentifikasi karena:
 Ia memerlukan sumber daya yang harus dialokasikan (dana,
SDM, sarana/fasilitas)
 Ia harus dijadwalkan
 Identifikasi kegiatan dilakukan dengan teknik
dekomposisi  mengurai tema proyek menjadi
kegiatan-kegiatan operasional
 Dekomposisi membawa proyek ke tingkat yang lebih rinci dan
operasional  harus bisa dijalankan
 Tool untuk dekomposisi: Work Breakdown Structure (WBS)
Work Breakdown Structure (WBS)
KEMKOMINFO
 Dekomposisi dilakukan secara
berulang, tiap pengulangan
akan membawa ke level
yang lebih rinci
 Pada akhirnya akan terbentuk
struktur “pohon” yang
menunjukkan hirarki
komponen dan kegiatan
proyek
 Level terendah menunjukkan
work packages (WP), atau
kegiatan-kegiatan yang
benar-benar dapat
dijalankan
 Dari WP dapat ditentukan
jadwal, kebutuhan biaya, dan
kebutuhan sumber daya
Rincian
lebih lanjut,
dst.
Judul
Proyek
Kelompok
aktivitas
utama
umum
detil
KEMKOMINFO
Tahap III: Pemantauan dan Kontrol
dalam Eksekusi Proyek
 Tujuan pemantauan & kontrol untuk menjamin
pelaksanaan proyek tetap berada pada jalur
seperti yang direncanakan (dalam dokumen
Rencana Proyek), dan jika terjadi perubahan, efek
negatifnya terhadap keberhasilan proyek dapat
diminimalkan
 Pemantauan& kontrol perlu dilakukan karena ada banyak sekali
faktor penyebab kegagalan proyek
 Terutama dijalankan untuk aspek jadwal & biaya
 Lingkup
 Identifikasi status/kondisi saat itu
 Mengambil langkah-langkah yang diperlukan sekiranya ada
penyimpangan
Pemantauan & Kontrol
KEMKOMINFO
 Untuk mengetahui kondisi proyek saat itu, perlu
pengukuran  dokumentasi proyek harus bisa
merekam semua data kinerja proyek dengan baik.
Yang perlu didokumentasikan:
 Rencana jadwal, biaya, dan alokasi sumber daya
 Realisasi waktu pelaksanaan kegiatan
 Realisasi pengeluaran (keuangan, penggunaan sumber
daya)
 Perlu menggunakan teknik-teknik tracking & estimasi
untuk menjawab pertanyaan apakah proyek
terlambat, pengeluarannya over budget, dsb
 Contoh teknik tracking: Earned Value Analysis (EVA)
Earned Value Analysis (EVA)
KEMKOMINFO
 EVA digunakan untuk menjawab pertanyaanpertanyaan:
 Seberapa jauh kemajuan proyek?
 Berapa banyak usaha/biaya yang harus dikeluarkan untuk
menyelesaikan proyek?
 Kapan proyek dapat diselesaikan?
 EVA melakukan:
 Pengukuran terhadap pekerjaan yang telah diselesaikan
 Meramalkan beban pekerjaan yang masih harus
diselesaikan
Ilustrasi Penggunaan EVA
KEMKOMINFO
Activities
Requirement gathering,
$500
today
System architecture,
$5000
Software design,
$3000
Actual cost
Requirement gathering
600
System architecture def.
4500
Software design
2100
Coding
3000
Hardware design
1600
Coding, $10000
Hardware design,
$2000
Hardware devt.,
$2000
9/4
2-Apr-06
16/4
23/4
30/4
7/5
14/5
21/5
28/5
4/6
System integration
& testing, $6000
11/6
18/6
25/6
2/7
9/7
16-Jul-06
Apakah pada minggu ke-6 proyeknya lagging?
Apakah pada minggu ke-6 biaya yg telah dikeluarkan over budget?
Earned Value Analysis
KEMKOMINFO
Task Name
%complete
Total PV
To date PV
AC
EV
CV
(EV-AC)
SV
(EV-PV)
Req. gathering
100
500
500
600
500
-100
0
System architecture
100
5000
5000
4500
5000
500
0
S/W design
67
3000
2010
2100
2010
-90
0
H/W design
83
2000
1340
1600
1660
60
320
Coding
25
10000
0
3000
2500
-500
2500
20500
8850
11800
11670
-130
2820
Total
Requirement gathering,
$500
today
System architecture,
$5000
Cost Variance (CV) dan
Schedule Varianve (SV):
menentukan kinerja proyek
Software design,
$3000
Coding, $10000
Hardware design,
$2000
Hardware devt.,
$2000
9/4
2-Apr-06
16/4
23/4
30/4
7/5
14/5
21/5
28/5
4/6
System integration
& testing, $6000
11/6
18/6
25/6
2/7
9/7
16-Jul-06
Pedoman untuk perbaikan cost/effort performance
(Jalote, P. Software Project Management in Practice, 2002.)
KEMKOMINFO
Possible Reason
Action to Consider
If actual cost/schedule is less than estimate by more than the allowable limit
Estimates for programs were too high or
project team has more domain
knowledge or experience than
expected


Reestimate for future modules
Release resources
The tasks so far have not been thoroughly
performed

Review tasks done so far and schedule reviews for work
products not reviewed
Examine issues log

If actual cost/schedule is more than estimate by more than the allowable limit
Low domain knowledge

Schedule training
Low software/coding experience of author

Reassign to leverage existing experience
New technology area


Reestimate or request resources
Negotiate delivery dates
Estimates were too aggressive (not much
consideration of limiting factors)

Identify main componenets for extra effort, and revise
estimate for future activities
Request resources
Negotiate to scale down project objectives
Resource optimization is low

Reschedule and reprioritize tasks, and identify and eliminate
"waiting items"
Nonavailability of a critical resource



Escalate the issue
Get a backup resource
Reschedule, keeping critical resources in mind
Too much rework due to poor quality of
output of earlier phases


Identify sources of problems and rectify them
Change project schedule


Quality Assurance (QA) dalam Proyek
KEMKOMINFO
 Kualitas (output) adalah hasil sebuah proses, ia harus
dibentuk dari awal proses  proses pengembangan
dijalankan dengan memperhatikan kualitas sebagai
sasaran yang harus dicapai
 Untuk menghasilkan output yang berkualitas,
prosesnya juga harus berkualitas
 Pendekatan kualitas
 Metodologi: cara menjalankan proses  berdasar pada
standar dan best practice
 Mekanisme organisasi: struktur organisasi yang
mengakomodasi dilaksanakannya proses yang berkualitas
Kualitas Proses
KEMKOMINFO
Peningkatan
kualitas proses
secara kontinyu
(Sommerville, 2004)
Kerangka untuk Peningkatan Kualitas Proses: Capability Maturity Model (CMM)
Level 1 – initial
A project is executed in a manner that the team sees fit
Level 2 – repeatable
Established PM practices are employed, but organization-wide process may not exist
Level 3 – defined
Organization-wide processes have been defined and followed
Level 4 – managed
Quantitative predictions and control on process performance
Level 5 – optimizing
Process capability is improved in a controlled manner
Tahap IV: Evaluasi Output
KEMKOMINFO
 Dilakukan pada tahap akhir proyek
 Dilakukan dengan membandingkan antara output
aktual dengan sasaran yang ditetapkan pada awal
proyek (scope verification)
 Perlu mendapatkan penerimaan (acceptance) dari
pemakai
 Instalasi dan deployment dilakukan secara tuntas
 User acceptance test
 Diakhiri dengan penandatanganan pernyataan penerimaan
(acceptance declaration)  pemakai sudah menyetujui produk
hasil proyek
KEMKOMINFO
Manajemen Proyek dengan Skema
Outsource
 Pada tahap awal dan akhir tidak berbeda dengan
proyek yang dikerjakan secara mandiri. Perbedaan
terletak pada tahap pelaksanaan: manajemen proyek
dilakukan oleh pihak vendor
Requirement
Pemilik
proyek
Proyek
Vendor
Manajemen
proyek
KEMKOMINFO
Manajemen Proyek dengan Skema
Outsource
 Pemilik Proyek
 Melakukan request for
participation (RfP) 
pengumuman lelang
 Menentukan spesifikasi
requirement (hasil yang
diharapkan dari produk)
 Melakukan seleksi dan
penentuan vendor
pemenang
 Mengikuti dan memantau
pelaksanaan proyek
 Mengevaluasi hasil akhir
dan output proyek
 Vendor Outsource
 Mengumpulkan proposal
 Melaksanakan proyek dan
manajemennya
 Menyerahkan hasil dan
mendapatkan user
acceptance
Penutup
KEMKOMINFO
 Pengadaan sistem TIK dapat dilakukan dengan
berbagai cara
 Pengadaan yang melibatkan aktivitas
pengembangan (development) perlu dilakukan
secara sistematis dan berdisiplin
 Proyek adalah “wadah” bagai usaha untuk
merealisasikan kegiatan-kegiatan pengembangan
sistem TIK
 Manajemen proyek melibatkan banyak pihak dan
kepentingan. Perlu metode ilmiah dan seni untuk
menjamin proyek menghasilkan produk seperti yang
diharapkan
KEMKOMINFO
Akhir dari Modul 6
Terima kasih
Alamat kontak penyelenggara :
Puslitbang Literasi dan Profesi SDM Kominfo
Jln Medan Merdeka Barat 9 Jakarta 10110
Tlp : 021 3856068
Email : [email protected]