BAB 2. perencanaan (Planning), pengorganisasian (Organizing), pelaksanaan. yang ada secara efisien.(

Transkripsi

1 BAB 2 LANDASAN TEORI 2.1 Manajemen Proyek 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.( Menurut Fayol pengertian Manajemen adalah Fungsi-fungsi untuk merencanakan, mengorganisir, memimpin, dan mengendalikan. ( 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.( 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.

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.

3 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? 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.

4 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.( 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, terusmenerus 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

5 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.( 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.

6 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 :

7 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

8 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 :

9 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 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

10 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) 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. Kadangkadang organisasi proyek adalah organisasi yang berdiri sendiri. Organisasi proyek parsial juga exist. Pada struktur organisasi ini seorang manajer proyek

11 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) 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

12 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.

13 Area Pengetahuan Manajemen Proyek 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

14 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.

15 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 sudahsudah 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 :

16 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.

17 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, pp ), 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.

18 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 :

19 24 b a c E a A 15 5 C 15 b a c b c 5 B 10 8 b a c F b a c D Gambar 2.5 Critical Path Method ( 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

20 25 kegiatan yang tidak saling tergantung. A A menunjukan kode pekerjaan atau nama pekerjaan 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)

21 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 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 :

22 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 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

23 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.

24 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 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.

25 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 resikoresiko 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 :

26 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 macammacam 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.

27 Metode Estimasi Proyek 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 Karakteristik lima sumber informasi yang ditetapkan, dan menghitung semua yang disediakan di dalam lokasi tabel yang sesuai. Lima sumber informasi ini adalah :

28 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.

29 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-10 Low Low Average Low Average High 21+ Average High High Processing Steps merupakan seri dari transformasi yang dibatasi oleh kumpulan Semantic Statement. Sebagai aturan umum, transformasi diselesaikan

30 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 [ x Σ 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 : No Incidental Moderate Average Significant Essential

31 36 Tabel 2.3 Menghitung Function Points F i : 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? Lines Of Code (LOC) Menurut Olson (2003, pp ), 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

32 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, mos , Average per KLOC SLOC : estimate lines of code, multiply Effort x 10,000 LOC = 16 person-months Budget x 10,000 LOC = $157,000 Documentation x 10,000 LOC = 581 pages Errors x 10,000 LOC = 98 Defects x 10,000 LOC = 25 People x 10,000LOC = 2 people Constructive Cost Model (COCOMO) Menurut Olson (2003, pp ), Dasar model COCOMO menghitung usaha pengembangan software berdasarkan dari ukuran program. Model

33 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 personmonths 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 = months Duration = 2.5 x = 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 = months Duration = 2.5 x = 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

34 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 = months Duration = 2.5 x = 16.9 months