BAB 2
LANDASAN TEORI
2.1
Manajemen Proyek
2.1.1
Pengertian Manajemen
Manajemen proyek terdiri dari dua kata yaitu Manajemen dan Proyek.
Manajemen
merupakan
suatu
metode/teknik atau proses
untuk
mencapai
suatu
tujuan
tertentu
secara sistematik
dan
efektif,
melalui
tindakan-tindakan
perencanaan  (Planning), 
pengorganisasian 
(Organizing), 
pelaksanaan
(Actuating) dan pengawasan (Controlling)
dengan
menggunakan
sumber
daya
yang ada secara efisien.(http://library.gunadarma.ac.id)
Menurut   Fayol   pengertian   Manajemen   adalah   Fungsi-fungsi   untuk
merencanakan, mengorganisir, memimpin, dan mengendalikan.
(http://library.gunadarma.ac.id)
Menurut 
Stoner 
pengertian 
Manajemen 
adalah 
Proses  perencanaan,
pengorganisasian, 
pengarahan 
dan 
pengawasan 
terhadap 
usaha-usaha 
para
anggota organisasi dengan
menggunakan sumber daya organisasi lainnya, agar
mencapai tujuan organisasi yang telah ditetapkan.(http://library.gunadarma.ac.id)
Menurut
Robbins & Coulter
(1999,
p8)
pengertian
Manajemen
adalah
Proses 
mengkoordinasi 
dan 
mengintegrasikan 
kegiatan-kegiatan  kerja 
agar
diselesaikan secara efisien dan efektif dengan dan melalui orang lain.
  
7
2.1.2
Pengertian Proyek
Menurut Schwalbe
(2000, p4), Proyek adalah
suatu
usaha yang bersifat
sementara untuk menghasilkan suatu produk atau layanan yang unik. Dalam hal
proyek  sistem  informasi  berarti  proyek  tersebut  berupa  sistem  aplikasi  yang
terdiri
atas
beberapa
modul program, tetapi proyek
software bervariasi
cakupannya,
mulai dari membangun sistem yang besar sampai
hanya
membuat
program satu
modul saja.
Proyek
normalnya
melibatkan
beberapa orang
yang
saling berhubungan aktivitasnya dan sponsor utama dari proyek biasanya tertarik
dalam penggunaan
sumber
daya
efektif
untuk
menyelesaikan
proyek
secara
efisien dan tepat waktu.
Menurut Rakos (1990, p1) proyek adalah sekumpulan
aktivitas yang
menghasilkan  suatu  deliverable  atau  produk.  Proyek  selalu  dimulai  dengan
sebuah
masalah,
kemudian
user
meminta
tim proyek
untuk
memberikan solusi
atas masalah yang ada, solusi tersebut adalah hasil dari proyek.
Menurut Gray dan Larson (2000, p4), Proyek adalah sesuatu yang
kompleks, tidak rutin, usaha
yang tepat waktu
yang dibatasi oleh time, budget,
resources,
dan
performance  
specifications yang
didesain
untuk
kebutuhan
customer.
Menurut Olson (2003, p2), suatu proyek melibatkan aktivitas yang baru
dan kompleks, tujuan yang dapat didefinisikan melintasi bebagai level organisasi
dan merupakan aktivitas yang unik. Karena proyek melibatkan banyak aktivitas,
maka  proyek  biasanya  mengandung  tingkat  ketidakpastian  dan  resiko  yang
tinggi.
Oleh
karena
itu
pula,
tingkat sumber
daya
yang
diperlukan
untuk
penyelesaian proyek biasanya sulit diestimasi.
  
8
Menurut
Schwalbe
(2000,
p5),
setiap
proyek memiliki
batasan
yang
berbeda terhadap ruang lingkup, waktu, dan biaya yang biasanya disebut sebagai
triple
constrain
(Tiga
Kendala).
Setiap
proyek
manajer
harus
memperhatikan
hal-hal penting dalam manajemen proyek :
•
Ruang lingkup (scope) : Apa yang ingin dicapai dalam proyek ? Produk atau
layanan apa yang pelanggan harapkan dari proyek tersebut ?
•
Waktu (time)
:
Berapa
lama
waktu
yang
dibutuhkan
untuk
menyelesaikan
proyek ? Bagaimana jadwal kegiatan proyek akan dilaksanakan ?
•
Biaya
(cost)
:
Berapa
biaya
yang
dibutuhkan
untuk
dapat
menyelesaikan
proyek ?
2.1.3
Pengertian Manajemen Proyek
Menurut Schwalbe (2000, p7), Manajemen Proyek merupakan aplikasi
dari
ilmu
pengetahuan, skills,
tools,
dan
teknik
untuk
aktivitas
suatu
proyek
dengan maksud
memenuhi atau
melampaui kebutuhan stakeholder dan harapan
dari sebuah proyek.
Menurut Soeharto (1997, p28), Manajemen Proyek adalah merencanakan,
mengorganisir, memimpin dan mengendalikan sumber daya perusahaan untuk
mencapai sasaran jangka pendek yang telah ditentukan. Lebih jauh,
manajemen
proyek menggunakan pendekatan sistem dan hierarki (arus kegiatan) vertikal dan
horizontal.
  
9
2.2
Oracle Corporation
Bisnis Oracle adalah bagaimana mengelola, menggunakan, membagikan,
dan memelihara informasi. Salah satu perusahaan software terbesar di dunia,
Oracle merupakan salah satu vendor yang menawarkan solusi-solusi untuk setiap
permasalahan  dari  bisnis  anda  seperti  database,  middleware,  business
intelegence, business
applications,
dan
collaborations.
Dengan
Oracle,
anda
mendapatkan  informasi  yang  membantu  anda  mengukur  hasil,  menjalankan
proses bisnis, dan berkomunikasi dengan setiap kebenaran untuk perusahaan
anda.(http://oracle.com)
2.2.1
Oracle Financial
Oracle Financial adalah Produk dari Oracle 
yang mendukung berbagai
kegiatan 
usaha  dan 
memiliki 
modul–modul 
seperti  General
Ledger 
(GL),
Account Revenue (AR), Account Payable (AP), Cash Management, Purchasing,
dan Purchasing Inventory, dll.
Oracle Financial adalah suatu kumpulan aplikasi yang
mengotomatisasi
dan mengalirkan semua arus informasi proses bisnis anda, mempunyai business
intelligence yang
akan
selalu
mendapatkan
infomasi
tentang
keputusan,
menjalankan operasi-operasi, dan mengurangi biaya. Suatu kesatuan model data
menyediakan setiap laporan informasi keuangan perusahaan anda secara akurat,
termasuk laporan 360-degree atas customer anda. Dan Oracle Financial, terus-
menerus menjalankan teknologi yang memberikan anda suatu kinerja dan
skalabilitas dalam memimpin perusahaan anda.
Oracle Financial adalah bagian dari Oracle E-Business Suite, melengkapi
dengan aplikasi-aplikasi
E-Business
Suite
lainnya
termasuk
Oracle
Marketing
  
10
dan   Oracle   Supply   Chain   Management.   Mengimplementasikan   satu   atau
beberapa
bagian
aplikasi
atau
mengimplementasikan
semua
bagian Oracle
E-
Business Suite adalah cara tercepat untuk kualitas terbaik informasi perusahaan.
Oracle E-Business Suite Financial 11i.10 menawarkan kemampuan-kemampuan
baru
yang memperbaiki
aliran
informasi
seluruh
perusahaan
anda
termasuk
Enterprise Planning and Budgeting.(http://oracle.com)
2.3
Faktor–faktor Penyebab Kegagalan Proyek Piranti Lunak
Menurut
Rakos
(1990,p.2).
Ada
beberapa
masalah
yang
menyebabkan
sebuah proyek gagal antara lain :
1.   Kegagalan pada saat memulai
Banyak proyek yang melenceng karena mereka tidak menentukan arah
yang jelas. Banyak orang-orang yang memulai sebuah proyek
tanpa tujuan
dan perencanaan yang jelas, sehingga memungkinkan kegagalan di awal
memulai proyek.
Perencanaan adalah mengetahui waktu di masa depan ke mana anda akan
pergi, bagaimana anda akan mendapatkannya dan bagaimana anda akan bisa
membuktikan bahwa anda ada disana.
2.   Kegagalan pada saat tahap pembuatan
Setelah membuat perencanaan proyek, anda akan menganalisa masalah
dan merancang suatu desain. Kemudian tahap pembuatan dan pengembangan
dapat dimulai. Proyek dapat
gagal di tahap
ini, jika hasil analisa dan desain
tidak didokumentasikan dengan tepat.
  
11
3.   Kegagalan pada saat akhir
Pada saat akhir proyek dapat
gagal karena saat batas waktu tiba, produk
yang dijanjikan belum selesai dibuat atau produk
telah selesai dibuat tetapi
aplikasi 
yang  dihasilkan  diserahkan 
tanpa  dilakukan  pengujian  terlebih
dahulu sehingga belum diketahui kegagalan
yang akan muncul dari aplikasi
tersebut atau sistem yang diberikan kepada user tidak
sesuai dengan kinerja
yang dijanjikan.
2.4
Tahapan Pengelolaan Proyek Piranti Lunak
Pendekatan yang akan digunakan melibatkan beberapa area penting seperti :
•
Project Methodology FastGoLive
Gambar 2.1
Project Methodology FastGoLive
PT.  Sapora  Nusantara  Consulting akan  menggunakan  phase-phase seperti  di
bawah ini :
  
12
1.   Project Initiation and Planning
Pada phase ini SAPORA Consulting dan TPK KOJA akan mengembangkan
secara
detail Work
Plan,
dokumen Project
Scope,
Objective
dan
Approach
sebagai panduan untuk proyek eksekusi.
2.   Operation Analysis (as is) & Business Process Design (to be)
Praktek bisnis tertentu dikumpulkan untuk mendapatkan kebutuhan.
Pengumpulan
informasi
dari
departemen
yang
terlibat
seperti Purchasing,
Accounting, Finance dan Billing.
Pada
phase
selanjutnya
proses-proses
bisnis
didesain
meliputi
peran-peran
dan
tanggung
jawab
departemen.
Alur
proses
meliputi
Planning and
Budgeting, Request to Pay, Order to Cash, Cash Management and
Management / Financials
Reporting. Aktivitas
ini adalah suatu dasar untuk
mengembangkan setup document.
3.   Business Process Configuration
Pada phase
ini,
modul-modul
aplikasi Oracle
dikonfigurasikan berdasarkan
pada setup document, Custom Reports, Interface dan data conversion scripts
yang dikembangkan. Dan departemen-departemen
pengguna (end users)
didaftarkan ke dalam sistem.
4.   Business Process Training & Bussiness Process Testing
Pada phase ini, terdapat pengembangan dari user manual dan training end
user
untuk
menggunakan
sistem
dalam memproses
transaksi
bisnis
dan
melaporkan hasil keuangan.
Kemudian pada phase pengujian (testing), skenario tes dalam masing-masing
departemen  terdapat  pengembangan  kemudian  dilanjutkan  dengan  Users
  
13
Acceptance Test (UAT). Masalah-masalah lain selama UAT akan dianalisis
dan diperbaiki.
5.   GoLive Preparation / Transition
Selama
peralihan
sistem
produksi
disiapkan, custom
reports
didaftarkan,
Interface
diinstal, end
users
didaftarkan,
master
data
dan
historical
data
dikonversikan
ke
dalam sistem
produksi.
Sistem
produksi
siap
untuk
digunakan.
6.   GoLive & Support
Sistem
berjalan,
semua
departemen
menggunakan
sistem untuk
transaksi
proses yang dihubungkan kepada tanggung jawab
mereka.
SAPORA
akan
mendukung pemakai sistem sekitar 6 bulan.
Menurut Rakos (1990,
p125), pada umumnya masa garansi (warranty
period)
dalam
industri
piranti
lunak
adalah
enam bulan sampai
satu
tahun.
Penyediaan garansi berupa salah satu atau kombinasi dari tiga cara berikut :
1.   Menyediakan seseorang pada pihak user untuk menjawab permasalahan.
Orang ini seharusnya merupakan project leader atau anggota tim proyek
senior yang mengetahui setiap aspek dari sistem.
2.   Menyediakan seseorang
yang
dapat
menjawab
permasalahan
dan
dapat
diakses via telepon. Semua anggota tim proyek harus bisa diakses .
3.   Menyediakan  seseorang  yang  dapat  menjawab  pertanyaan  dalam  satu
periode waktu yang singkat setelah panggilan telepon diterima.
Tim proyek sudah selesai dengan keseluruhan proyek, jika :
  
14
•
Warranty disediakan.
•
Tinjauan
ulang
pasca
proyek
diadakan
dan
semua
hal
yang
dapat
bermanfaat bagi proyek mendatang didokumentasikan.
•
Tanggung 
jawab  dan 
metode  pemeliharaan 
yang  berjalan 
harus
didefinisikan.
2.5
Alternate Organizational Structure
Menurut Olson (2003, p38), Struktur organisasi menggambarkan laporan
secara
hierarki dan
jaringan komunikasi resmi dalam suatu organisasi.
Galbraith
telah
menggambarkan
3
form
dasar
dari
organisasi
proyek,
yaitu
: functional,
project,
dan
matrix.
Setiap
jenis
dari
3
stuktur
organisasi tersebut terdapat
kelebihan masing-masing, dan masing-masing bekerja baik di dalam tipe-tipe
tertentu  dari 
lingkungan.  Penggunaan  struktur  organisasi  tergantung  kepada
tujuan dari organisasi, tipe kerja yang harus dilakukan dan lingkungan dalam yang
beroperasi.
2.5.1
Functional Organization
Menurut Olson (2003, p38), Functional organization bekerja baik dalam
perulangan, lingkungan yang stabil. Subelements organisasi didefinisikan dengan
aktivitas
atau
fungsi
spesial.
Semua
bagian
akuntan
di
dalam perusahaan
dikumpulkan di dalam satu lokasi di mana mereka bekerja bersama-sama.
Keuntungan  dari  organisasi  functional adalah  spesialis  bekerja  bersama  dan
dapat 
mengembangkan  kemampuan  profesional  di  dalam  cara  yang  paling
  
15
efisien.  Akuntan  fokus  pada  masalah  akuntansi  dan  menjadi  terlatih  dengan
sangat bagus di dalam akuntansi.
Gambar 2.2
Functional Organization
Sumber : Olson (2003, p38)
2.5.2
Project Organization
Menurut
Olson
(2003,
p39),
Project
organization murni
terdiri
dari
membuat suatu pemisahan, organisasi mandiri
terutama
untuk
menyelesaikan
suatu proyek istimewa atau terbilang luar biasa. Ketika proyek selesai, tidak ada
alasan bagi organisasi untuk melanjutkan. Pada tabel 2.3 menggambarkan
bagaimana kemampuan dapat dikelompokkan oleh proyek
Pusat  proyek  dihubungkan  kepada  organisasi  induk  untuk
menggambarkan sumber daya manusia dan personnel yang dibutuhkan. Kadang-
kadang organisasi proyek adalah organisasi yang berdiri sendiri. Organisasi
proyek
parsial
juga
exist.
Pada
struktur
organisasi
ini seorang
manajer
proyek
  
16
bertanggung   jawab   untuk   beberapa   aktivitas,   padahal   aktivitas   lain   juga
membutuhkan
lebih
banyak
dukungan.
Seperti
akuntansi
berhubungan
dengan
divisi fungsional. Ini adalah perjanjian yang sudah biasa.
Gambar 2.3
Project Organization
Sumber : Olson (2003, p39)
2.5.3
Matrix Organization
Menurut Olson (2003, p41),
Matrix Organization adalah suatu struktur
gridlike dari hubungan antara pelaporan dan kekuasaan yang menutupi organisasi
fungsi
tradisional. Matrix
Organization
digunakan
dalam organisasi
yang
menggunakan tim proyek dan grup produksi yang minimal.
Penggambaran kunci dari organisasi matrix adalah garis multiple
dari
kekuasaan. Spesialis melaporkan kepada manajer fungsional mereka dengan
menanggapi 
isu-isu  yang 
meliputi  spesialisasi  dan 
laporan 
mereka  kepada
manajer
proyek
untuk
kewajiban
yang
spesifik.
Spesialis
fungsional
ditunjuk
  
17
untuk proyek
yang akan
diimplementasikan. Spesialis
ini
membuat
keputusan
karir personal pada tempat fungsional permanen mereka.
Gambar 2.4
Matrix Organization
Sumber : Olson (2003, p41)
Ada
beberapa
masalah
yang
diperkenalkan
dalam bentuk
matrix
organization. Struktur pelaporan yang ganda menciptakan kondisi yang
membingungkan
pada bagian
yang
tinggi
dari
struktur
tersebut.
Di
dalam tim
matrix organization tersebut harus terdapat prinsip yang tegas dalam hal perintah
atasan. Pada
sistem
matrix,
dengan
dua
sumber
daya
potensial
dari perintah,
telah
ditemukan
dalam menyelesaikan
masalah
karena
permintaan
yang
tidak
dapat digabungkan dan prioritas dari dua manajer dari individual yang spesifik.
  
18
2.6
Area Pengetahuan Manajemen Proyek
2.6.1
Manajemen Ruang Lingkup Proyek
Menurut Soeharto (1997, p49), Lingkup proyek adalah total jumlah
kegiatan atau pekerjaan yang
harus dilakukan
untuk menghasilkan produk
yang
diinginkan oleh proyek tersebut.
Menurut
Schwalbe
(2000,
p76),
ruang
lingkup mewakili
semua kinerja
yang
terlibat
dalam menciptakan
produk
dari
proyek
dan
proses
untuk
menciptakan proyek tersebut. Sedangkan ruang lingkup proyek mencakup semua
proses yang terlibat dalam pendefinisian dan pengaturan mengenai apa yang
termasuk
atau
tidak
di
dalam proyek.
Hal
ini
untuk
menyakinkan
bahwa
tim
proyek  dan  stakeholder mempunyai  pengertian  yang  sama  mengenai  produk
yang akan diproduksi sebagai hasil dari proyek dan proses yang akan digunakan
dalam memproduksi proyek tersebut.
Proses utama yang terlibat di dalam manajemen ruang lingkup proyek
adalah :
1) 
Initiation (Inisiasi)
Proses ini melibatkan tanda mulainya organisasi
untuk
memulai proyek atau
melanjutkan
fase berikut
dari
sebuah proyek.
Keluaran dari
proses
inisiasi
proyek
adalah
sebuah project
charter.
Project
charter
merupakan
kunci
dokumen untuk pengenalan formal mengenai keberadaan dan penyediaan
keseluruhan
proyek. Menurut
Schwalbe
(2000,
p88) project
charter terdiri
dari :
•   Judul proyek dan tanggal pengesahan
•   Nama manajer proyek dan informasi yang dapat dihubungi
  
19
•   Deskripsi proyek secara objektif
•   Penjelasan mengenai rencana pengaturan proyek
•   Peraturan dan tanggung jawab
•   Bagian persetujuan dari pihak stakeholder proyek
•   Bagian komentar mengenai proyek dari pihak stakeholder proyek.
2) 
Scope Planning (Perencanaan Ruang Lingkup)
Proses  ini  melibatkan  dokumen  pengembangan  untuk  menyediakan  dasar
dari keputusan yang akan riter dari proyek, mencakup kriteria untuk
menentukan
apakah
proyek
atau
fase telah diselesaikan sepenuhnya. Tim
proyek menciptakan sebuah pernyataan ruang lingkup dan perencanaan
manajemen proyek sebagai hasil dari proses perencanaan ruang lingkup.
3) 
Scope Definition (Pendefinisian Ruang Lingkup)
Proses  ini  melibatkan  pembagian  dari  proyek  besar  menjadi  kecil,  lebih
mudah
diatur. Tim proyek
menciptakan
sebuah
Work
Breakdown
Structure
(WBS ) selama proses ini.
Menurut   Schwalbe   (2000,   p92),   WBS   adalah   sebuah   analisis   yang
berorientasi keluaran dari pekerjaan yang terlibat dalam proyek yang
mendefinisikan   keseluruhan   ruang   lingkup   proyek.   WBS   merupakan
dokumen
dasar
dalam manajemen
proyek
karena
menyediakan dasar untuk
perencanan
dan
pengaturan
jadwal proyek,
biaya
dan
perubahan.
Seorang
yang
ahli
dalam manajemen
proyek
percaya
bahwa
kegiatan
yang
tidak
seharusnya   dilakukan   dalam   proyek   bilamana   kegiatan   tersebut   tidak
termasuk dalam WBS.
  
20
Menurut Schwalbe (2000, pp95-97), ada beberapa pendekatan yang dapat
digunakan untuk membangun WBS, meliputi :
a.   Menggunakan Guidelines
Jika pendekatan untuk mengembangkan suatu WBS masih berjalan
maka sangat penting untuk mengikuti guidelines tersebut.
b.   The Analogy Approach
Di
dalam pendekatan analogi,
digunakan WBS
proyek
yang
sudah-
sudah yang mirip sebagai tahap untuk memulai. Beberapa organisasi
menyimpan  WBS  dan  dokumen  lain  dalam  file untuk  membantu
orang
yang bekerja dalam proyek. Dengan
melihat contoh dari WBS
proyek yang mirip, akan memungkinkan untuk
mengerti cara yang
berbeda untuk membuat sebuah WBS.
c.   The Top-down dan bottom-up Approach
Untuk  menggunakan  pendekatan  top-down,  mulai  dengan  perihal
yang besar dari proyek dan pecahkan menjadi perihal yang lebih rinci.
Proses ini melibatkan proses penyaringan kerja menjadi detil yang
lebih
besar.
Dengan
pendekatan
bottom-up,
anggota
tim harus
mengidentifikasi sebanyak mungkin tugas khusus yang berhubungan
dengan
proyek.
Kemudian
anggota
tim akan
mengagregasi
tugas
tersebut dan mengatur mereka menjadi aktivitas yang dirangkum.
Untuk
menciptakan WBS
yang baik
membutuhkan beberapa iterasi. Berikut
ini ada beberapa prinsip yang dapat digunakan untuk membuat WBS yang
baik :
  
21
1.   Sebuah jenis kerja hanya muncul sekali dalam WBS
2.   Content pekerjaan
dari sebuah perihal
WBS
adalah
jumlah
perihal
WBS di bawahnya.
3.   Perihal WBS adalah tanggung jawab dari seorang individu, meskipun
banyak orang yang bekerja di dalamnya.
4.   WBS  harus  konsisten  dengan  jalan  di  mana  pekerjaan  dilakukan,
harus membantu anggota tim dulu dan tujuan lain bila perlu.
5. 
Anggota
tim
proyek
harus terlibat
dalam membangun
WBS
untuk
meyakinkan konsistensi dan buy-in.
6.
Setiap perihal WBS harus didokumentasikan untuk meyakinkan
pengertian
yang akurat mengenai
hal
yang termasuk dan
yang tidak
termasuk dalam ruang lingkup kerja.
7.   WBS harus menjadi sebuah alat yang fleksibel untuk mengakomodasi
perubahan yang tak terduga sementara menjaga pengaturan content
pekerjaan dalam proyek agar sesuai dengan pernyataan ruang lingkup.
4) 
Scope Verification (Verifikasi Ruang Lingkup)
Proses ini melibatkan penerimaan formal dari ruang lingkup proyek. Kunci
proyek pemegang saham, seperti pelanggan dan sponsor untuk proyek, secara
formal menerima jalannya proyek ini selama proses ini.
5) 
Scope Change Control (Pengontrolan Perubahan Ruang Lingkup)
Proses 
ini 
melibatkan 
pengontrolan 
perubahan 
terhadap 
ruang 
lingkup
proyek. Perubahan ruang lingkup, tindakan koreksi, dan pengajaran dari
keluaran (output) proses ini.
  
22
2.6.2
Manajemen Waktu Proyek
Menurut Soeharto (1997, p49), Waktu atau jadwal merupakan salah satu
sasaran utama
proyek. Keterlambatan akan mengakibatkan berbagai bentuk
kerugian,  misalnya,  penambahan  biaya, 
kehilangan 
kesempatan 
produk
memasuki pasaran dan lain-lain. Pengelolaan waktu meliputi perencanaan,
penyusunan,
dan
pengendalian
jadwal.
Salah satu teknik yang spesifik untuk
maksud
tersebut
adalah
mengelola float
atau
slack
pada
jaringan
kerja,
serta
konsep cadangan waktu yang diperkenalkan oleh D.H. Bush, (1991).
Menurut Schwalbe
(2000, pp111-112), Manajemen waktu proyek secara
sederhana didefinisikan, yang melibatkan proses yang dibutuhan untuk
meyakinkan
pemenuhan
waktu dari
proyek. Tetapi, pencapaian hasil
ini
tidak
sederhana.
Proses utama yang terlibat didalam manajemen waktu proyek adalah :
1.   Pendefinisian Aktivitas (Activity Definition)
Melibatkan pengidentifikasian
aktivitas
yang
khusus
di
mana
anggota
tim
proyek dan pemegang saham harus bekerja
untuk
menghasilkan pengarahan
proyek. Sebuah aktivitas atau tugas adalah elemen kerja, biasanya ditemukan
di
dalam WBS
yang
mempunyai
durasi
yang
diharapkan,
biaya,
dan
kebutuhan akan sumber daya.
2.   Barisan Aktivitas (Activity Squencing)
Melibatkan pengidentifikasian dan pendokumentasian hubungan antara
aktivitas proyek.
  
23
3.   Perkiraan Durasi Aktivitas (Activity Duration Estimating)
Melibatkan
perkiraan
periode
jumlah
kerja
yang
dibutuhkan
untuk
menyelesaikan tugas individu.
4.   Pengembangan Jadwal (Schedule Development)
Melibatkan analisis urutan aktivitas, perkiraan durasi aktivitas dan kebutuhan
sumber daya untuk menciptakan jadwal proyek.
Menurut  Schwalbe  (2000,  p118),  Penjadwalan  proyek  bisa  digambarkan
dengan menggunakan :
a.   Critical Path Method (CPM)
CPM
disebut
juga
teknik
analisis
jalur
kritis
(Critical
Path
Analysis)
yaitu teknik analisis jaringan proyek yang digunakan untuk memprediksi
total durasi proyek. Langkah ini bertujuan mengkaji secara analitis berapa
lama 
waktu  penyelesaian  proyek.  CPM  dapat  digambarkan  sebagai
berikut :
  
24
Kegiatan semu (tidak membutuhkan sumber daya apapun)
Hanya merupakan garis penghubung peristiwa antara dua
a
b
c
E
A
15
a
a
b
c
b
c
5
10
F
a
8
b
c
a
b
c
Gambar 2.5
Critical Path Method
(http://google.com)
Keterangan :
Event, tanda dimulai atau berakhirnya kegiatan.
Kegiatan (membutuhkan sumber daya terutama waktu)
Garis lurus, arah anak panah menuju kejadian atau event
berikutnya.
Jalur kritis dari kegiatan.
  
25
dengan
menampilkan kegiatan proyek,
jadwal
mulai dan jadwal selesai
dalam format kalender. Gantt Chart menunjukan
informasi tugas (task)
kegiatan yang tidak saling tergantung.
A
A 
menunjukan  kode  pekerjaan  atau  nama  pekerjaan.
15
15  menunjukkan waktu yang dibutuhkan menyelesaikan
kegiatan atau pekerjaan A dengan peristiwa berikutnya.
•
a
: Menyatakan suatu kegiatan
•
b
: LF/LS
•
c
: ES/EF
•
ES (Earliest Start Time)   =  
waktu  
mulai   paling   awal     
sebuah
kejadian.
•
EF (Earliest Finish Time)   =   waktu   selesai   paling   awal   sebuah
kegiatan. Bila hanya ada satu kegiatan
terdahulu,
maka
EF
suatu
kegiatan terdahulu merupakan ES selanjutnya.
•
LS (Latest Start)      =  waktu  paling  akhir  kegiatan  boleh  dimulai
tanpa memperlambat proyek secara keseluruhan.
•
LF (Latest Finish)  
=
waktu paling akhir suatu kegiatan boleh selesai
tanpa memperlambat penyelesaian proyek.
•
D (Duration)          
=  kurun  waktu  suatu  kegiatan,  dengan  satuan
waktu berupa hari, minggu, bulan.
b.   Gantt Chart
Menurut Schwalbe (2000, p119), Gantt Chart menyediakan suatu format
standard 
untuk 
menggambarkan 
informasi 
mengenai 
jadwal 
proyek
  
26
dalam proyek
sebagai
suatu serial batang (bars)
sepanjang
skala
waktu
(timescale).
Bars secara grafik
menunjukkan durasi task dengan tanggal
mulai dan selesai seiring dengan kemajuan terhadap waktu.
5.   Pengontrolan Jadwal (Schedule Control)
Melibatkan  pengontrolan  dan  pengaturan  perubahan  terhadap  perubahan
jadwal.
2.6.3
Manajemen Biaya Proyek
Menurut Soeharto (1997, p49), Pengelolaan biaya meliputi segala aspek
yang berkaitan dengan hubungan antara dana dan kegiatan proyek. Mulai dari
proses
memperkirakan
jumlah
keperluan
dana,
mencari,
dan
memilih
sumber
serta
macam
pembiayaan,
perencanaan, serta
pengendalian
alokasi
pemakaian
biaya sampai kepada akuntansi dan administrasi pinjaman dan keuangan. Agar
pengelolaan
bisa
efektif,
terutama
dalam aspek
perencanaan dan pengendalian
biaya
proyek,
maka
disusun
bermacam-macam
teknik dan metode.
Misalnya
teknik menyusun anggaran biaya proyek, identifikasi varians, konsep nilai hasil,
dan lain-lain.
Menurut Schwalbe (2000, p144), Manajemen biaya proyek melibatkan
proses yang dibutuhkan untuk meyakinkan bahwa proyek terselesaikan dengan
anggaran yang dianjurkan. Seorang manajer proyek harus dapat meyakinkan
bahwa proyek sudah didefinisikan dengan baik, mempunyai anggaran yang
realistis di mana tim proyek terlibat dalam hal penganjuran tersebut. Merupakan
tugas
manajer
proyek
untuk
memuaskan stakeholder
proyek
sementara
melanjutkan penekanan untuk mengurangi dan mengontrol biaya.
Proses yang terlibat di dalam manajemen biaya proyek adalah :
  
27
1.   Perencanaan Sumber Daya (Resources Planning)
Proses ini melibatkan penentuan sunber daya (orang, peralatan, dan material)
dan kuantitas dari
tiap sumber daya
yang akan digunakan dalam melakukan
aktivitas  proyek.  Keluaran  dari  proses  ini  adalah  daftar  dari  kebutuhan
sumber daya.
2.   Perkiraan Biaya (Cost Estimating)
Proses ini melibatkan pengembangan sebuah pendekatan atau perkiraan dari
biaya sumber daya yang dibutuhkan untuk menyelesaikan proyek. Keluaran
utama dari proses ini merupakan perkiraan biaya, mendukung perincian, dan
sebuah perencanaan manajemen biaya.
3.   Penganggaran Biaya (Cost Budgeting)
Proses ini melibatkan pengalokasian perkiraan
biaya
keseluruhan
terhadap
peralatan kerja individu untuk membangun sebuah dasar untuk pengukuran
kerja. Keluaran utama dari proses ini adalah dasar biaya (cost baseline).
4.   Pengontrolan Biaya (Cost Control)
Proses
ini
melibatkan pengontrolan
perubahan
terhadap
anggaran
proyek.
Keluaran
utamanya
adalah
revisi
perkiraan
biaya, update
penganggaran,
tindakan pembetulan, perkiraan pada penyelesaian, dan pelajaran yang
didapat.
2.6.4
Manajemen Sumber Daya Manusia Proyek
Menurut Soeharto (1997, p50), Pengelolaan sumber daya terdiri dari
pengelolaan
sumber
daya
manusia
dan
nonmanusia.
Dalam hal
ini,
sering
dikatakan   salah   satu   fungsi   pengelolaan   yang   mungkin   tersulit   adalah
pengelolaan sumber daya manusia mulai dari inventarisasi kebutuhan, merekrut
  
28
atau mengajukan keperluan, membentuk
tim,
melatih,
memotivasi
serta
membimbing agar menjadi suatu tim yang
tangguh
untuk
menangani kegiatan
proyek yang menjadi tanggung jawabnya. Adapun pengelolaan sumber daya
nonmanusia
antara
lain adalah
sumber daya
yang
berbentuk
material,
seperti
peralatan konstruksi dan lain-lain.
Menurut Schwalbe (2000, p211), Manajemen sumber daya manusia
proyek  
melibatkan
proses
yang dibutuhkan
untuk
melakukan efektivitas
penggunaan 
orang 
yang 
terlibat 
dengan 
proyek. 
Manajemen  sumber  daya
manusia
menyangkut
semua stakeholder
proyek seperti : sponsor,
pelanggan,
anggota tim proyek, staf pendukung, para penjual yang mendukung proyek, dan
lain-lain.
Proses
utama
yang terlibat
di
dalam manajemen sumber
daya
manusia
proyek adalah :
1.   Perencanaan organisasional (Organizational Planning)
Proses ini melibatkan pengidentifikasian, penugasan, dan pendokumentasian
peranan proyek, tanggung jawab, dan melaporkan hubungan. Kunci keluaran
dari proses ini meliputi peranan dan tanggung jawab penugasan yang sering
ditampilkan dalam bentuk matrik dan sebuah bagan organisasional mengenai
proyek.
2.   Akuisisi Staf (Staff Acquisition)
Proses ini melibatkan cara mendapatkan kebutuhan personil yang ditugaskan
untuk
bekerja
dalam proyek.
Mendapatkan
personil
merupakan
salah
satu
tantangan yang penting dari proyek TI apalagi untuk mendapakan personil
yang berkualitas.
  
29
3.   Pengembangan Tim (Team Development)
Proses
ini
melibatkan
pembangunan
individu
dan
kemampuan
tim untuk
meningkatkan
kerja
proyek.
Pembangunan individu dan kemampuan tim
merupakan tantangan bagi proyek TI.
2.6.5
Manajemen Resiko Proyek
Menurut Soeharto (1997, p50), dalam konteks proyek,
mengelola resiko
berarti mengidentifikasi secara sistematis dari jenis, besar dan sumber timbulnya
resiko selama siklus proyek, kemudian menyiapkan tanggapan yang tepat untuk
menghadapi resiko tersebut.
Menurut Schwalbe (2000, p273), Manajemen resiko proyek merupakan
pengetahuan 
untuk 
mengidentifikasi, 
menugaskan, 
dan 
menanggapi  resiko
melalui
daur
hidup
proyek
dan
perhatian
dalam memenuhi
objektif
proyek.
Menurut Schwalbe (2004, p393), tujuan dari manajemen resiko proyek dapat
dilihat dengan meminimalkan potensi resiko sementara memaksimalkan potensi
peluang atau pengeluaran.
Proses utama yang terlibat di dalam manajemen resiko proyek adalah :
1.   Perencanaan Manajemen resiko (Risk Mangement Planning)
Pada proses ini memutuskan bagaimana pendekatan dan rencana kegiatan
manajemen
resiko
untuk
suatu proyek. Dengan meninjau project charter,
WBS,
aturan
dan
tanggung
jawab,
toelransi
resiko stakeholder, dan
kebijaksanaan
manajemen resiko
organisasi,
tim proyek dapat
merumuskan
suatu perencanaan manajemen resiko.
  
30
2.   Identifikasi Resiko (Risk Identification)
Menentukan resiko mana yang paling berpengaruh pada proyek dan
mendokumentasikan karakteristik dari setiap resiko yang ada.
3.   Banyaknya Resiko
Pada proses ini melibatkan pengevaluasian resiko dan interaksi resiko untuk
menafsir kemungkinan output
proyek. Alat atau teknik untuk menghitung
resiko yaitu jumlah uang yang diharapkan, menghitung riter resiko, estimasi
PERT, simulasi dan penilaian dari para ahli.
4.   Pengembangan Tanggapan Terhadap Resiko (Risk Response Planning)
Dalam
proses
ini
tim mengambil
langkah-langkah
untuk
meningkatkan
peluang dan mengembangkan tanggapan terhadap ancaman. Hasil dari proses
ini adalah perencanaan manajemen resiko.
5.   Pengontrolan dan Pengawasan Resiko (Risk Monitoring and Control)
Melibatkan pengawasan
terhadap
resiko
yang diketahui, identifikais resiko-
resiko baru, mengurangi resiko dan mengevaluasi keefektifan dari penurunan
resiko  seluruhnya  dalam  daur  hidup  proyek.  Hasil  utama  dari  proses  ini
adalah
tindakan
pembetulan
terhadap
resiko
dan
update
perencaan
manajemen resiko.
Menurut Rakos (1990, p23), setiap proyek akan tepat waktu dan sesuai
dengan  anggaran  apabila  tidak  ada  kesalahan  dalam  proyek.  Sangat  penting
untuk berkonsentrasi pada segala sesuatu yang dapat menimbulkan masalah dan
mencoba untuk menghindarinya. Ini dinamakan dengan manajemen resiko.
Manajemen resiko terdiri dari empat tahapan :
  
31
1.   Mengantisipasi Resiko
Yang pertama dan hal
yang paling penting dalam manajemen resiko adalah
selalu waspada terhadap segala sesuatu yang dapat menimbulkan masalah.
Metode terbaik untuk mengidentifikasi resiko yang mungkin terjadi adalah
melihat pada sejarah dan membuat suatu daftar kesalahan di masa lalu
sehingga kita dapat mengantisipasi masalah-masalah yang mungkin akan
timbul.
2.   Mengeliminasi Resiko yang mungkin akan timbul
Pada tahap ini adalah suatu ide
yang bagus
untuk memprioritaskan
macam-
macam resiko dari resiko terbesar sampai terkecil. Sehingga kita dapat
menentukan resiko mana yang paling utama harus ditangani dan
mengesampingkan macam-macam yang tidak terlalu penting.
3.   Mengurangi Dampak dari Resiko
Pada
tahap ini,
macam-macam
resiko
yang tidak
dapat
dieliminasi
atau
dikesampingkan, harus mendefinisikan rencana pendekatan situasional. Anda
dapat meringkas rencana-rencana pendekatan situasional anda menggunakan
dengan menggunakan tabel.
4.
Tetap pada Control ketika sesuatu berjalan tidak semestinya
Dan
pada
akhirnya, disamping
usaha-usaha
yang
telah
dilakukan
akan
ada
hal-hal yang tetap berjalan tidak dengan semestinya. Jangan terlalu paranoid
(bahkan jika
setiap
orang
melawan) dan tetap mengendalikan sebaik yang
anda bisa.
  
32
2.7
Metode Estimasi Proyek
2.7.1
Function Point Analysis
Menurut Olson (2003, p167), Metode Function Point (FP) merupakan
suplemen dasar ukuran suatu proyek untuk estimasi. Metode ini dapat digunakan
untuk   mengestimasi   biaya   dan   waktu   yang   didasarkan   pada   spesifikasi
kebutuhan, dan berdiri sendiri dari teknologi yang digunakan. Metode Albrecht
sangat kritis karena perhitungan menggunakan jalur alternatif, bobot yang
disebabkan, dan sistem yang besar sangat ringan.
Menurut Pressman (1997, pp85-87), Function yang berdasarkan software
metrics adalah
suatu
ukuran
dari
fungsionalitas
yang
diterima
oleh
aplikasi
sebagai suatu nilai
normalisasi. Sejak ”fungsionalitas” tidak dapat diukur secara
langsung,
maka
itu diukur
secara tidak
langsung menggunakan
ukuran
lainnya.
Function yang berdasarkan metrics pertama
kali disarankan oleh Albrecht
[ALB79], yang mempelopori suatu ukuran yang disebut function point. Function
points
diukur
dihasilkan
menggunakan suatu
hubungan
secara
empiris
yang
didasarkan
pengukuran
dari
sumber
informasi software
dan
penilaian terhadap
kompleksitas software yang dapat dihitung (secara langsung) .
Function points dihitung dengan melengkapi tabel  2. 2 . Karakteristik
lima sumber informasi  yang ditetapkan, dan menghitung semua yang disediakan
di dalam lokasi tabel yang sesuai. Lima sumber informasi ini adalah :
  
33
Tabel 2.1 Menghitung
Function Points metrics
Weighting factor
Measurement parameter
count
simple
average
complex
count
Number of user inputs
X
3  +
X
4
+
X
6
=
Number of user outputs
X
4
+
X
5
+
X
7
=
Number of user inquiries
X
3
+
X
4
+
X
6
=
Number of files
X
7
+
X
10
+
X
15
=
Number of  external interfaces
X
5
+
X
7
+
X
10
=
Count = total
Number
of
user
inputs. Setiap user
inputs
yang
menyediakan
aplikasi
berorientasi
data
yang
terdapat
pada software.
Inputs
harus
dibedakan
dari
inquiries yang akan dihitung secara terpisah.
Number of user outputs. Setiap user outputs yang menyediakan aplikasi
berorientasi informasi kepada user dihitung. Pada konteks
ini outputs menunjuk
kepada laporan, screens, pesan kesalahan dan banyak
lagi. Jenis data individual
yang terdapat dalam laporan tidak dihitung secara terpisah.
  
34
Number  of  user  inquiries. Suatu  inquiry  didefinisikan  sebagai online
input
yang
menghasilkan
dalam generasi
dari
beberapa
tanggapan
software
menengah dalam form dari suatu online output. Setiap inquiry dihitung.
Number of 
files. Setiap master file (suatu pengelompokkan data secara
logic yang mungkin merupakan satu bagian dari database yang besar atau suatu
file yang terpisah) dihitung.
Number  of 
external  interface. 
Semua 
mesin 
yang 
dapat 
membaca
interface 
(contohnya, 
data 
file 
dalam  disket) 
yang 
digunakan 
untuk
memindahkan informasi ke sistem lain dihitung.
Setelah data diatas dikumpulkan, nilai kompleksitas digabungkan dengan
masing-masing hitungan. Organisasi
yang
menggunakan
metode function point
mengembangkan kriteria
untuk
menentukan apakah entry itu termasuk kedalam
simple, average, atau complex. Pada akhirnya penentuan dari kompleksitas itu
bersifat subjective (menurut penilaian organisasi sendiri).
Tabel 2.2 Menentukan Kompleksitas Function Points
Semantic
Statement
Processing
Steps
1-5
6-10
11+
1-10
11-20
21+
Low
Low
Average
Low
Average
High
Average
High
High
Processing
Steps
merupakan
seri
dari
transformasi
yang
dibatasi
oleh
kumpulan Semantic Statement. Sebagai aturan
umum, transformasi diselesaikan
  
35
dengan algorithm yang menghasilkan perubahan dasar input data yang diproses
menjadi output data.
Tingkatan dari kompleksitas yang
ditandai
untuk
masing-masing
transformasi
merupakan
fungsi
dari
beberapa processing
steps
dan
semantic
statements.
Untuk menghitung function points (FP), rumus yang digunakan adalah :
FP = count total x [0.65 + 0.01 x S F
i
]
F
i  
(i = 1 s/d 14) adalah “nilai ketetapan kompleksitas” berdasarkan dari
tanggapan kepada pertanyaan-pertanyaan [ART85] yang ada pada tabel di bawah
ini.
Rate each factor on a scale of  0 to 5 :
 
0 
1 
2 
3 
4 
5 
No
Incidental
Moderate
Average
Significant
Essential
  
36
F
i
:
Tabel 2.3 Menghitung Function Points
Apakah sistem membutuhkan backup dan recovery yang dapat diandalkan?
Apakah data komunikasi dibutuhkan?
Apakah ada fungsi-fungsi pemrosesan terdistribusi?
Apakah kinerja merupakah hal yang penting?
Apakah sistem akan berjalan pada lingkungan operasional yang berat?
Apakah sistem memerlukan masukan data secara on-line?
Apakah masukan data secara on-line membutuhkan transaksi input pada berbagai layar atau operasi?
Apakah master files di-update secara on-line?
Apakah input, output, atau inquiries kompleks?
Apakah pemrosesan internal kompleks?
Apakah kode dirancang untuk dapat digunakan kembali?
Apakah konversi dan instalasi termasuk didalam perancangan?
Apakah sistem dirancang untuk instalasi di organisasi yang berbeda?
Apakah aplikasi dirancang untuk memfasilitasi perubahan dan memudahkan penggunaan oleh pengguna?
2.7.2
Lines Of Code (LOC)
Menurut Olson (2003, pp166-167), Metode
lines of code dan function
point
memulai
dengan
pendekatan secara
ilmiah
dari
mengumpulkan
catatan
secara
histori 
atas pengalaman proyek
terdahulu. Data secara
histori
ini
adalah
dasar untuk mengidentifikasi hubungan antara ukuran-ukuran kunci yang penting
(seperti person-months dari effort dan biaya-biaya pengeluaran) dan
faktor
lain
yang   juga   penting   (contohnya   halaman-halamam   dari   dokumentasi   yang
  
37
dihasilkan, 
pesan-pesan 
kesalahan 
yang 
ditemukan, 
kerusakan 
sistem, 
dan
penunjukkan sumber daya manusia)
Ketika menjumpai suatu proyek baru, estimasi dibuat berdasarkan lines of
code 
yang 
dibutuhkan 
oleh 
proyek.  Sebagai 
contoh, 
jika  sebuah 
proyek
diestimasi hingga terdapat 10,000 lines of code, estimasi dari ukuran-ukuran ini
adalah sebagai berikut :
Tabel 2.4  Lines of Code Operation
Budget
Documentation
Average of Past Projects :
Effort
($, Thousands)
(pages)
Errors
Defects
People
LOC
20,543
33 mos.
351
1,194
201
52
4
Average per KLOC
1.606
15.673
58.122
9.784
2.531
0.195
SLOC :
estimate lines of code, multiply
Effort
1.606 x 10,000 LOC = 16 person-months
Budget
15.673 x 10,000 LOC = $157,000
Documentation
58.122 x 10,000 LOC = 581 pages
Errors
9.784 x 10,000 LOC = 98
Defects
2.531 x 10,000 LOC = 25
People
0.195 x 10,000LOC  = 2 people
2.7.3
Constructive Cost Model (COCOMO)
Menurut Olson (2003, pp170-171), Dasar model COCOMO menghitung
usaha   pengembangan   software  berdasarkan   dari   ukuran   program.   Model
  
38
menengah
juga
mempertimbangkan
suatu
set
dari
harga
yang
mencerminkan
produk secara spesifik, hardware, personnel, dan karakteristik proyek.
Untuk yang relatif kecil, proyek software sederhana dibangun oleh
tim
kecil dengan pengalaman yang bagus, formula-formula COCOMO untuk person-
months
atas
effort
dan pengembangan
waktu
dalam bulan
secara
kronologis
sebagai berikut (Organik):
Person-months = 2.4 x KLOC
1.05
=
E  for effort
Duration (months) = 2.5 x E
0.38
Di mana KLOC berarti ribuan lines of code. Di bawah ini tipe untuk
pekerjaan yangterdiri dari 50,000 lines of code
Person-months = 2.4 x 50 ¹
.05
= 145.925 months
Duration = 2.5 x 145.925
0.38
= 16.6 months
Untuk
proyek
software dengan
ukuran
menengah
dan
agak
kompleks,
dibangun
oleh
tim dengan
pengalaman
campuran
dan
menghadapi
banyak
kerumitan dibandingkan kebutuhan rata-rata, formulanya adalah (semi detached):
Person-months = 3.0 x KLOC 1
.12
Duration (months) = 2.5 x E
0.35
Suatu pekerjaan dengan tipe ini yang mengandung 50,000 lines of code,
perhitungannya adalah :
Person-months = 3.0 x 50 ¹
.12
= 239.865 months
Duration = 2.5 x 239.865
0.35
= 17.0 months
Akhirnya, untuk pembangunan proyek software di bawah kondisi yang
sangat rumit, formulanya adalah (embadded) :
Person-months = 3.6 x KLOC ¹
.2
  
39
Duration (months) = 2.5 x E
0.32
Suatu pekerjaan yang mengandung 50,000 lines of code dengan kondisi
yang sangat rumit ini adalah :
Person-months = 3.6 x 50 ¹
.2
=
393.610 months
Duration = 2.5 x 393.610
0.32
= 16.9 months