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

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.

Kegiatan semu (tidak membutuhkan sumber daya apapun)

Hanya merupakan garis penghubung peristiwa antara dua

A

B

C

D

F

E

10

8

5

a

b c

a

b c

a

b c

ab c

ab c

1515

5

25

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

dengan menampilkan kegiatan proyek, jadwal mulai dan jadwal selesai

dalam format kalender. Gantt Chart menunjukan informasi tugas (task)

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

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.

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

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 Low Low Average

11-20 Low Average High

21+ 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 Σ Fi ]

Fi (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

Tabel 2.3 Menghitung Function Points Fi :

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

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?

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 1.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 1.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 1.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 1.2 = 393.610 months

Duration = 2.5 x 393.610 0.32 = 16.9 months