CYBER CRIME dan PENANGGULANGANNYA
Keunggulan komputer berupa kecepatan dan ketelitiannya dalam menyelesaikan pekerjaan sehingga dapat menekan jumlah tenaga kerja, biaya serta memperkecil kemungkinan melakukan kesalahan, mengakibatkan masyarakat semakin mengalami ketergantungan kepada komputer. Dampak negatif dapat timbul apabila terjadi kesalahan yang ditimbulkan oleh peralatan komputer yang akan mengakibatkan kerugian besar bagi pemakai (user) atau pihak-pihak yang berkepentingan. Kesalahan yang disengaja mengarah kepada penyalahgunaan komputer.
Pada tahun 1982 telah terjadi penggelapan uang di bank melalui computer sebagaimana dapat dilihat dalam Putusan Mahkamah Agung Nomor 363 K/Pid/1984 tanggal 25 Juni 1984 mengenai. “Suara Pembaharuan” edisi 10 Januari 1991 memberitakan tentang dua orang mahasiswa yang membobol uang dari sebuah bank swasta di Jakarta sebanyak Rp. 372.100.000,00 dengan menggunakan sarana komputer.
Perkembangan lebih lanjut dari teknologi komputer adalah berupa computer network yang kemudian melahirkan suatu ruang komunikasi dan informasi global yang dikenal dengan internet.
Kebutuhan dan penggunaan akan teknologi informasi yang diaplikasikan dengan Internet dalam segala bidang seperti e-banking, ecommerce, e-government, eeducation dan banyak lagi telah menjadi sesuatu yang lumrah. Bahkan apabila masyarakat terutama yang hidup di kota besar tidak bersentuhan dengan persoalan
teknologi informasi dapat dipandang terbelakang atau ”GAPTEK”.
Percepatan teknologi semakin lama semakin supra yang menjadi sebab material perubahan yang terus menerus dalam semua interaksi dan aktivitas masyarakat informasi.
Internet merupakan big bang kedua – setelah big bang pertama yaitu material big bang menurut versi Stephen Hawking – yang merupakan knowledge big bang dan ditandai dengan komunikasi elektromagentoopis via satelit maupun kabel, didukung oleh eksistensi jaringan telefoni yang telah ada dan akan segera didukung oleh ratusan satelit yang sedang dan akan diluncurkan.
Internet merupakan symbol material embrio masyarakat global. Internet membuat globe dunia, seolah-olah menjadi seperti hanya selebar daun kelor. Era informasi ditandai dengan aksesibilitas informasi yang amat tinggi. Dalam era ini, informasi merupakan komoditi utama yang diperjualbelikan sehingga akan muncul berbagai network & information company yang akan memperjualbelikan berbagai fasilitas bermacam jaringan dan berbagai basis data informasi tentang berbagai hal yang dapat diakses oleh pengguna dan pelanggan. Semua itu membawa masyarakat ke dalam suasana yang disebut oleh John Naisbitt, Nana Naisbitt dan Douglas Philips sebagai Zona Mabuk Teknologi.
Kebijakan Kriminalisasi Cybercrime
Kebijakan kriminalisasi merupakan suatu kebijakan dalam menetapkan suatu perbuatan yang semula bukan tindak pidana (tidak dipidana) menjadi suatu tindak pidana (perbuatan yang dapat dipidana). Jadi pada hakekatnya, kebijakan kriminalisasi merupakan bagian dari kebijakan kriminal (criminal policy) dengan menggunakan sarana hukum pidana (penal), dan oleh karena itu termasuk bagian dari “kebijakan hukum pidana” (penal policy), khususnya kebijakan formulasinya.
Pertanyaan tentang kriminalisasi muncul ketika kita dihadapkan pada suatu perbuatan yang merugikan orang lain atau masyarakat yang hukumnya belum ada atau belum ditemukan. Berkaitan dengan kebijakan kriminalisasi terhadap perbuatan yang masuk dalam kategori cybercrime sebagai tindak pidana sebagaimana diulas dalam buku tersebut di atas, ada beberapa tanggapan yang hendak dikemukakan, yaitu:
1. Persoalan kriminalisasi timbul karena dihadapan kita terdapat perbuatan yang berdimensi baru, sehingga muncul pertanyaan adakah hukumnya untuk perbuatan tersebut. Kesan yang muncul kemudian adalah terjadinya kekosongan hukum yang akhirnya mendorong kriminalisasi terhadap perbuatan tersebut. Sebenarnya dalam persoalan cybercrime, tidak ada kekosongan hukum, ini terjadi jika digunakan metode penafsiran yang dikenal dalam ilmu hukum dan ini yang mestinya dipegang oleh aparat penegak hukum dalam menghadapi perbuatan-perbuatan yang berdimensi baru yang secara khsusus belum diatur dalam undang-undang. Persoalan menjadi lain jika ada keputusan politik untuk menetapkan cybercrime dalam perundang-undangan tersendiri di luar KUHP atau undang-undang khusus lainnya. Sayangnya dalam persoalan mengenai penafsiran ini, para hakim belum sepakat mengenai kateori beberapa perbuatan. Misalnya carding, ada hakim yang menafsirkan masuk dalam kateori penipuan, ada pula yang memasukkan dalam kategori pencurian. Untuk itu sebetulnya perlu dikembangkan pemahaman kepada para hakim mengenai teknologi informasi agar penafsiran mengenai suatu bentuk cybercrime ke dalam pasal-pasal dalam KUHP atau undang-undang lain tidak membingungkan.
2. Dilihat dari pengertian kriminalisasi, sesungguhnya kriminalisasi tidak harus berupa membuat undang-undang khusus di luar KUHP, dapat pula dilakukan tetap dalam koridor KUHP melalui amandemen. Akan tetapi proses antara membuat amandemen KUHP dengan membuat undang-undang khusus hampir sama, baik dari segi waktu maupun biaya, ditambah dengan ketidaktegasan sistem hukum kita yang tidak menganut sistem kodifikasi secara mutlak, menyebabkan munculnya bermacam-macam undang-undang khusus.
3. Kriminalisasi juga terkait dengan persoalan harmonisasi, yaitu harmonisasi materi/substansi dan harmonisasi eksternal (internasional/global) – lihat hal. 43-44. Mengenai harmonisasi substansi, bukan hanya KUHP yang akan terkena dampak dari dibuatnya undang-undang tentang cybercrime. Kementerian Komunikasi dan Informasi RI mencatat ada 21 undang-undang dan 25 RUU yang akan terkena dampak dari undang-undang yang mengatur cybercrime. Ini merupakan pekerjaan besar di tengah kondisi bangsa yang belum stabil secara politik maupun ekonomi. Harmonisasi eksternal berupa penyesuaian perumusan pasal-pasal cybercrime dengan ketentuan serupa dari negara lain, terutama dengan Draft Convention on Cyber Crime dan pengaturan cybercrime dari negara lain. Harmonisasi ini telah dilaksanakan baik dalam RUU PTI, RUU IETE, RUU ITE, RUU TPTI maupun dalam RUU KUHP. Judge Stenin Schjolberg dan Amanda M. Hubbard mengemukakan dalam persoalan cybercrime ini diperlukan standardisasi dan harmoonisiasi dalam tiga area, yaitu legislation, criminal enforcement dan judicial review. Ini menunjukkan bahwa persoalan harmonisasi merupakan persoalan yang tidak berhenti dengan diundangkannya undang-undang yang mengatur cybercrime, lebih dari itu adalah kerjasama dan harmonisasi dalam penegakan hukum dan peradilannya.
4. Berkaitan dengan harmonisasi substansi, ada yang bagian yang tak disinggung dalam buku tersebut, terutama mengenai jenis pidana. Mengingat cybercrime merupakan kejahatan yang menggunakan atau bersaranakan teknologi komputer, maka diperlukan modifikasi jenis sanksi pidana bagi pelakunya. Jenis sanksi pidana tersebut adalah tidak diperbolehkannya/dilarang sipelaku untuk menggunakan komputer dalam jangka waktu tertentu. Bagi pengguna komputer yang sampai pada tingkat ketergantungan, sanksi atau larangan untuk tidak menggunakan komputer merupakan derita yang berat. Jangan sampai terulang kembali kasus Imam Samudera – terpidana kasus terorisme Bom Bali I – yang dengan leluasa menggunakan laptop di dalam selnya.
5. Setelah harmonisasi dilakukan, maka langkah yang selanjutnya adalah melakukan perjanjian ekstradisi dengan berbagai negara. Cybercrime dapat dilakukan lintas negara sehingga perjanjian ekstradisi dan kerjasama dengan negara lain perlu dilakukan terutama untuk menentukan yurisdiksi kriminal mana yang hendak dipakai. Pengalaman menunjukkan karena ketiadaan perjanjian ekstradisi, kepolisian tidak dapat membawa pelaku kejahatan kembali ke tanah air untuk diadili.
6. Hal lain yang luput dari perhatian adalah pertanggungjawaban Internet Service Provider (ISP) sebagai penyedia layanan internet dan Warung Internet (Warnet) yang menyediakan akses internet. Posisi keduanya dalam cybercrime cukup penting sebagai penyedia dan jembatan menuju jaringan informasi global, apalagi Warnet telah ditetapkan sebagai ujung tombak untuk mengurangi kesenjangan digital di Indonesia. Bentuk pertanggungjawaban pidana apa yang mesti mereka terima jika terbukti terlibat dalam cybercrime. Apakah pertanggungjawabannya dibebankan secara individual atau dianggap sebagai suatu korporasi. Ini akan memiliki konsekuensi tersendiri.
Pencegahan dan Penanggulangan Cybercrime Dengan Sarana Non Penal
Tidak ada jaminan keamanan di cyberspace, dan tidak ada sistem keamanan computer yang mampu secara terus menerus melindungi data yang ada di dalamnya. Para hacker akan terus mencoba untuk menaklukkan sistem keamanan yang paling canggih, dan merupakan kepuasan tersendiri bagi hacker jika dapat membobol sistem keamanan komputer orang lain. Langkah yang baik adalah dengan selalu memutakhirkan sistem keamanan computer dan melindungi data yang dikirim dengan teknologi yang mutakhir pula.
1. Di Swedia, perusahaan keamanan internet, NetClean Technology bekerjasama dengan Swedish National Criminal Police Department dan NGO ECPAT, mengembangkan program software untuk memudahkan pelaporan tentang pornografi anak. Setiap orang dapat mendownload dan menginstalnya ke computer. Ketika seseorang meragukan apakah material yang ada di internet itu legal atau tidak, orang tersebut dapat menggunakan software itu dan secara langsung akan segera mendapat jawaban dari ECPAT Swedia.
2. Di Inggris, British Telecom mengembangkan program yang dinamakan Cleanfeed untuk memblok situs pornografi anak sejak Juni 2004. Untuk memblok situ situ, British Telecom menggunakan daftar hitam dari Interent Watch Foundation (IWF). Saat ini British Telecom memblok kira-kira 35.000 akses illegal ke situs tersebut. Dalam memutuskan apakah suatu situ hendak diblok atau tidak, IWF bekerjasama dengan Kepolisian Inggris. Daftar situ itu disebarluaskan kepada setiap ISP, penyedia layanan isi internet, perusahaan filter/software dan operator mobile phone.
3. Norwegia mengikuti langkah Inggris dengan bekerjasama antara Telenor dan Kepolisian Nasional Norwegia, Kripos. Kripos menyediakan daftar situs child pornography dan Telenor memblok setiap orang yang mengakses situ situ. Telenor setiap hari memblok sekitar 10.000 sampai 12.000 orang yang mencoba mengunjungi situ situ.
4. Kepolisian Nasional Swedia dan Norwegia bekerjasama dalam memutakhirkan daftar situs child pornography dengan bantuan ISP di Swedia. Situs-situs tersebut dapat diakses jika mendapat persetujuan dari polisi.
5. Mengikuti langkah Norwegia dan Swedia, ISP di Denmark mulai memblok situs child pornography sejak Oktober 2005. ISP di sana bekerjasama dengan Departemen Kepolisian Nasional yang menyediakan daftar situs untuk diblok. ISP itu juga bekerjasama dengan NGO Save the Children Denmark. Selama bulan pertama, ISP itu telah memblok 1.200 pengakses setiap hari.
Sebenarnya Internet Service Provider (ISP) di Indonesia juga telah melakukan hal serupa, akan tetapi jumlah situs yang diblok belum banyak sehingga para pengakses masih leluasa untuk masuk ke dalam situs tersebut, terutama situs yang berasal dari luar negeri. Untuk itu ISP perlu bekerjasama dengan instansi terkait untuk memutakhirkan daftar situs child pornography yang perlu diblok.
Faktor penentu lain dalam pencegahan dan penanggulangan cybercrime dengan sarana non penal adalah persoalan tentang etika. Dalam berinteraksi dengan orang lain menggunakan internet, diliputi oleh suatu aturan tertentu yang dinamakan Nettiquette atau etika di internet. Meskipun belum ada ketetapan yang baku mengenai bagaimana etika berinteraksi di internet, etika dalam berinteraksi di dunia nyata (real life) dapat dipakai sebagai acuan.
Penanganan Cybercrime di Indonesia
Meski Indonesia menduduki peringkat pertama dalam cybercrime pada tahun 2004, akan tetapi jumlah kasus yang diputus oleh pengadilan tidaklah banyak. Dalam hal ini angka dark number cukup besar dan data yang dihimpun oleh Polri juga bukan data yang berasal dari investigasi Polri, sebagian besar data tersebut berupa laporan dari para korban. Ada beberapa sebab mengapa penanganan kasus cybercrime di Indonesia tidak memuaskan:
1. Cybercrime merupakan kejahatan dengan dimensi high-tech, dan aparat penegak hukum belum sepenuhnya memahami apa itu cybercrime. Dengan kata lain kondisi sumber daya manusia khususnya aparat penegak hukum masih lemah.
2. Ketersediaan dana atau anggaran untuk pelatihan SDM sangat minim sehingga institusi penegak hukum kesulitan untuk mengirimkan mereka mengikuti pelatihan baik di dalam maupun luar negeri.
3. Ketiadaan Laboratorium Forensik Komputer di Indonesia menyebabkan waktu dan biaya besar. Pada kasus Dani Firmansyah yang menghack situs KPU, Polri harus membawa harddisk ke Australia untuk meneliti jenis kerusakan yang ditimbulkan oleh hacking tersebut.
4. Citra lembaga peradilan yang belum membaik, meski berbagai upaya telah dilakukan. Buruknya citra ini menyebabkan orang atau korban enggan untuk melaporkan kasusnya ke kepolisian.
5. Kesadaran hukum untuk melaporkan kasus ke kepolisian rendah. Hal ini dipicu oleh citra lembaga peradilan itu sendiri yang kurang baik, factor lain adalah korban tidak ingin kelemahan dalam sistem komputernya diketahui oleh umum, yang berarti akan mempengaruhi kinerja perusahaan dan web masternya.
Upaya penanganan cybercrime membutuhkan keseriusan semua pihak mengingat teknologi informasi khususnya internet telah dijadikan sebagai sarana untuk membangun masyarakat yang berbudaya informasi. Keberadaan undang-undang yang mengatur cybercrime memang diperlukan, akan tetapi apalah arti undang-undang jika pelaksana dari undang-undang tidak memiliki kemampuan atau keahlian dalam bidang itu dan masyarakat yang menjadi sasaran dari undang-undang tersebut tidak mendukung tercapainya tujuan pembentukan hukum tersebut.
Rabu, 24 Maret 2010
Senin, 22 Maret 2010
secondhand serenade - goodbye
secondhand serenade - goodbye
it's a shame that it
had to be this way
its not enough
to say i'm sorry
its not enough
to say i'm sorry
meybe i'm to blame
or maybe we're the same
but
either way
i can't breathe
either way
i can't breathe
all i had to
say is goodbye
we're better
off this way
we're better
off this way
i'm alive but i'm
losing all my drive
cause everything
we've been through
and everything about you
seemed to be a lie
a guitless twisted lie
it made me
learn to hate you
or hate myself for
letting it pass by
all i had to
say is goodbye
we're better
off this way
we're better
off this way
all i had to
say is goodbye
we're better
off this way
we're better
off this way
and every,
everything isn't only
what it seems
so hold these
words that you never
told me
its time to say goodbye
its time to say goodbye
its time to say goodbye
GOODBYE
"bye"
take my pain away
tear it out
tell me i was wrong
tell me i was wrong
take my pain away
tear it out
tell me i was wrong
tell me i was wrong
take my pain away
tear it out
tell me i was wrong
tell me i was wrong
"bye"
it's a shame that it
had to be this way
its not enough
to say i'm sorry
its not enough
to say i'm sorry
meybe i'm to blame
or maybe we're the same
but
either way
i can't breathe
either way
i can't breathe
all i had to
say is goodbye
we're better
off this way
we're better
off this way
i'm alive but i'm
losing all my drive
cause everything
we've been through
and everything about you
seemed to be a lie
a guitless twisted lie
it made me
learn to hate you
or hate myself for
letting it pass by
all i had to
say is goodbye
we're better
off this way
we're better
off this way
all i had to
say is goodbye
we're better
off this way
we're better
off this way
and every,
everything isn't only
what it seems
so hold these
words that you never
told me
its time to say goodbye
its time to say goodbye
its time to say goodbye
GOODBYE
"bye"
take my pain away
tear it out
tell me i was wrong
tell me i was wrong
take my pain away
tear it out
tell me i was wrong
tell me i was wrong
take my pain away
tear it out
tell me i was wrong
tell me i was wrong
"bye"
jangan berhenti berharap
pilihan
aku akan menyudahi semua
aku akan mengakhiri semua
aku tidak akan memilih semua
dan klo itu memang pilihan..
hidup adalah pilihan..
kadang kita bisa memilih
dan kadang kita tidak mendapatkan
semua yang kita inginkan
berharap hanya memegang..
tapi tak bisa dirasakan..
berharap hanya memeluk
tapi tak sanggup tangan ini
wahai untuk sang putri
yang hanya mengecap ikhlas
aq hanya bisa menelanjangi diri
dan tetap saja kembali ketanah
bagi dirinya yang hanya keikhlasan
tapi tak kuasa menahan tangis
tidak ada dan tidak berbekal apa-apa
menghadap yang disana
aku akan menyudahi semua
aku akan mengakhiri semua
aku tidak akan memilih semua
dan klo itu memang pilihan..
hidup adalah pilihan..
kadang kita bisa memilih
dan kadang kita tidak mendapatkan
semua yang kita inginkan
berharap hanya memegang..
tapi tak bisa dirasakan..
berharap hanya memeluk
tapi tak sanggup tangan ini
wahai untuk sang putri
yang hanya mengecap ikhlas
aq hanya bisa menelanjangi diri
dan tetap saja kembali ketanah
bagi dirinya yang hanya keikhlasan
tapi tak kuasa menahan tangis
tidak ada dan tidak berbekal apa-apa
menghadap yang disana
Senin, 15 Maret 2010
SEMPURNA
ratapilah dirimu
jika kau masih inginkan kau memilikiku
kau terus maki aku karena satu kesalahan
bodoh yang lama berlalu
jika ku kira
aku berat untuk meninggalkan kamu
jangan salah
kita liat siapa yang akan menanggis
apa arti cinta
jika sebuah kata maaf sudah tak berarti
mulutmu tajam
seakan kau lebih baik dari aku
lebih baik dari segalanya
atau kau memang sempurna
aku bukan tuk kau maki
salahkan saja bila kelak aku kan meninggalkanmu
memang ku bosan memilikimu
tak pernah ku pahami
semuanya selalu salah dimatamu
dimana rasa itu
seakan kau tak pernah sekalipun
mencintaiku
kau kira aku tak kan tega
kau kira aku takut..
jangan salah
kita liat siapa yang akan menanggis
Mulut dan hatimu tak lagi seindah
nama yang menghiasi tubuhmu
akhiri saja semua sebelum terjadi
akhiri saja
ratapilah dirimu
jika kau masih inginkan kau memilikiku
kau terus maki aku karena satu kesalahan
bodoh yang lama berlalu
jika ku kira
aku berat untuk meninggalkan kamu
jangan salah
kita liat siapa yang akan menanggis
apa arti cinta
jika sebuah kata maaf sudah tak berarti
mulutmu tajam
seakan kau lebih baik dari aku
lebih baik dari segalanya
atau kau memang sempurna
aku bukan tuk kau maki
salahkan saja bila kelak aku kan meninggalkanmu
memang ku bosan memilikimu
tak pernah ku pahami
semuanya selalu salah dimatamu
dimana rasa itu
seakan kau tak pernah sekalipun
mencintaiku
kau kira aku tak kan tega
kau kira aku takut..
jangan salah
kita liat siapa yang akan menanggis
Mulut dan hatimu tak lagi seindah
nama yang menghiasi tubuhmu
akhiri saja semua sebelum terjadi
akhiri saja
Sabtu, 13 Maret 2010
ETIKA DALAM BIDANG IT
selalu ada etika dimana kita berada. tidak dirumah, dijalan, atau pun dilingkungan dimana sehari-hari kita tinggal. et... jangan salah,, dibidang IT juga ada loh etikanya.. hhmmm.. saya kira cuma hidup kita aja yang bisa diatur.. ternyata teknologi bisa kita atur juga. dimana saat ini yang saya angkat adalah etika didalam bidang IT.. baik data, system, coding, network dan sebagainya, sesuatu yang orang katakan tidak tampak.
ini adalah point yang harus diperhatikan dalam beretika di dalam IT:
1. dimana sekarang adalah teknologi yang sangat kuat dan juga sangat2 super canggih, dimana kemajuan teknologi dalam bidang IT sangat pesat. dan komputer bisa digunakan untuk hal yang buruk atau pun baik. tergantung dari hati nurani user atau penggunanya masing2 dan yang tidak kalah penting adalah hati nurani masing2..
2. standar yang menentukan kegiatan tersebut baik atau buruk. dimana dengan contoh dibawah ini sudah jelas.. mereka2 yang mempuyai skill yang berlebih harus bisa melakukan hal-hal yang membangun. melainkan bukan merusak.
3. moral dimana seseorang hanya bisa merusak dan bukan membangun. dan mengarah kepada penggunaan dan sistem informasi.
4. pembajakan dalam hak cipta, hak karya dan etc.
contoh :
Jika ada orang yang mempunyai skill IT yang baik dan kemudian dengan skill-nya dia melakukan transfer uang dari bank account yang bukan miliknya, maka orang ini sudah dikatakan melanggar etika keprofesionalan IT.
Atau jika ada orang yang melakukan penyerangan terhadap sistem komputer tertentu dengan ‘memasukkan’ virus. Ini sudah melanggar etika pula. Skill yang dimiliki haruslah digunakan untuk sesuatu yang membangun, dan bukan menghancurkan. Apa pun yang kita hadapi, janganlah sampai merusakkan keprofesional bidang dan etika. iya tidak???
ada pun langkah untuk pencegahan dari perusakan atau pembajakan adalah : mendokumentasi, knowledge sharing, sehingga akan ada orang yang mengerti bagaimana sistem bekerja. Dan jika ada masalah dilapangan, ada seseorang yang bisa memperbaikinya. dan membuat wirewall yang kokoh, akan terasa sulit bagi para penyusup untuk melakukan perusakan, dan admin harus tanggap jika ada gejala dimana sistem dalam server sudah ada yang akan menyusup..
ada juga code of product dari IT yang saya pernah baca yaitu :
1. komputer tidak boleh digunakan untuk merusak atau merusak orang lain.
2. pekerja tidak boleh mencampuri kerja komputer orang lain.
3. pekerja tidak boleh mencampuri file komputer orang lain.
4. komputer tidak boleh digunakan untuk mencuri.
5. komputer tidak boleh digunakan untuk membuat kesaksian palsu.
6. pengguna komputer tidak boleh mengkopi atan menggunakan perangkat lunak secara ilegal.
7. pengguna koputer tidak boleh menggunakan fasilitas perangkat lunak orang lain tanpa otoritas.
8. pekerja harus memikirkan dampak sosial dari program dan sistem yang dibuat atau didisain.
Maka, bagi rekan-rekan yang membaca artikel diblog saya ini, mari kita sama-sama membangun level keprofesionalan yang tinggi dan baik, yang akhirnya akan selalu memberi sifat membangun.
Selasa, 09 Maret 2010
Pengelolaan Proyek Sistem Informasi
BAB 5
NEGOSIASI DAN KONTRAK
5.1. NEGOSIASI
Mengapa bila orang pergi ke tempat perdagangan di Mexico, mereka akan melakukan negosiasi walaupun hanya untuk beberapa dolar saja, tetapi bila mereka melakukan transasksi dengan sebuah produk berharga ribuan dolar, mereka enggan untuk “tawar-menawar”. Tidak ada kata malu untuk melakukan negosiasi. Belajar dari bagaimana semua itu dilakukan dengan benar dan anda dapat menggunakan keahlian pada saat situasi tawar-menawar dalam lingkungan proyek software.
Ilmu Pengetahuan dan Seni Bernegosiasi
Kunci sukses dari negosiasi adalah mengetahui fakta yang sebenarnya. Hal pertama dan yang terpenting, mengetahui produk yang akan dijual atau dibeli.
Sebelum anda memulai negosiasi, tentukan dua hal :
1. Apa yang sepenuhnya anda inginkan untuk perjanjian
2. Apa yang akan anda berikan
Bila anda penjual software, hal yang akan dinegosiasikan adalah harga, ketahui harga minimum yang akan diminta. Jika anda pembeli, ketahui harga maksimum yang akan dibayarkan. Hal ini juga membantu jika anda mengetahui kebutuhan lawan anda, ini dikatakan dengan fleksibilitas.
Tiga hal yang dinegosiasikan dalam proyek software
Hal yang paling sering dinegosiasikan adalah harga, tetapi lamanya proyek dan fungsi proyek dapat juga dinegosiasikan. Seperti kata pepatah, “Anda akan mendapatkan yang murah, cepat atau bagus : pilih dua hal”. Anda dapat menghemat uang dengan mengambil waktu yang lebih lama. Atau apabila harga terlalu mahal, perhitungkan menawar dengan kelengkapan yang lebih sedikit.
Anda memperoleh apa yang anda bayar
Jika anda membeli produk, berhati-hatilah dengan tawar-menawar Tim proyek yang terlalu rendah, atau menerima tawaran murah yang tidak biasanya.
Contoh kasus :
Perusahaan ABC menawarkan tender keluar untuk kebutuhan software. Mereka menerima 2 tawaran :
Pertama dari Smart Software Co. (SSC). SSC mempunyai perkiraan akurat dan menawarkan harga $200 untuk dilaksanakan dalam 12 bulan.
Kedua, tawaran dari Unscrupulous Software Co. (USC). Mereka menawarkan $100 untuk jangka waktu 6 bulan.
Mencoba menghemat biaya, perusahaan ABC tentu saja menerima USC. Enam bulan kemudian setelah pembayaran $100 kepada USC, kejadian berikut ini terjadi :
ABC : Benarkah sistem akan diantar hari ini ?
USC : Kami mempunyai kabar buruk.
ABC : Kabar buruk apa ?
USC : Sayang sekali, kami telah menghabiskan $100, tetapi kami
baru menyelesaikan hanya setengah dari sistem yang tertulis. Anda punya dua pilihan : berikan kami $100 lagi (atau mungkin lebih), atau ambil saja setengah sistem anda.
ABC : Tetapi kita mempunyai kontrak !
USC : Saya harus menggaji programmer saya, jika tidak mereka
akan berhenti. Jika anda tidak membayar saya, saya akan dinyatakan bangkrut. Silakan kirim surat ke Brazil.
5.2. KONTRAK
Kontrak untuk produk software mengharuskan tim proyek untuk menyediakan pengirim khusus, seperti tanggal yang pasti, untuk berbagai macam pemberian upah. Kecuali proyek ini dilaksanakan pada dasar formal dalam organisasi eksternal, khususnya dalam dokumen “kontrak” yang tidak ingin dituliskan.
Bagian-bagian Kontrak (Items To Be Contracted)
Dalam tambahan untuk harga, tanggal pengiriman dan pengiriman, kontrak ini dapat termasuk dalam hal-hal dan kondisi lain seperti reproduksi, harga bertahan (price holding), lisensi atau garansi. Bila kerusakan dari software dapat menyebabkan tidak hidup atau situasi kritis lain, pertanggung jawaban dari pemulis harus diklarifikasikan. Jika perkiraan didasarkan pada input verbal dari user, “escape clause” harus diikutsertakan. Anjuran tim proyek ini berguna untuk keluar dari kesalahan informasi. Tanggung jawab user, seperti menyediakan informasi yang akurat dan tepat waktu, atau melakukan beberapa pekerjaan seperti dokumentasi, juga harus ditulis.
Kontrak Harga Tetap (The Fixed Price (FP) Contract)
Ini merupakan tipe umum dari kontrak. Di dalam kontrak FP, tim proyek mengajukan harga total pada awal proyek. Bagaimanapun juga tim proyek harus memperkirakan risiko di dalam kontrak FP. Gunakan kontrak FP hanya jika anda dapat memperhitungkan risiko dan harganya.
Kontrak FP sangat tepat bila :
1. Anda yakin bahwa tidak akan terjadi pergantian utama.
2. Anda akan bekerja dengan software dan produk hardware yang anda ketahui.
3. Anda memiliki komunikasi yang baik dengan user.
Kontrak Harga Tambahan (The Cost Plus (CP) Contract)
Apabila risiko terlalu tinggi dalam menentukan harga tetap, tim proyek harus memilih kontrak CP. Pada kontrak CP, tim proyek menerima gaji dalam jumlah tetap per-hari atau per-jam ditambah ongkos-ongkos. Biasanya perusahaan tidak membuat janji untuk berapa lama mereka membuat kontrak.
Kontrak CP sangat tepat bila :
1. Anda merasa bahwa pergantian utama akan terjadi (RD tidak ada atau kebutuhan lain tidak jelas).
2. Anda bekerja dengan tidak mengetahui sistem operasi, paket software atau hardware, atau anda mempunyai peralatan pengembangan khusus untuk menulis, seperti simulator, tes dasar, dsb.
3. Komunikasi yang kurang baik antara anda dan user.
4. Aktifitas utamanya berorientasi pada manusia, contohnya interview.
Kondisi dan Syarat (Terms and Conditions)
Jika anda menjalani kontrak CP, yakinkan bahwa kondisi dan persyaratan jelas.
Masukkan semua syarat dan kondisi – aspek hukum dari cara yang anda inginkan untuk bekerja dengan klien. Ini akan memeberikan perlindungan bagi anda dan klien, dan menghindari kesulitan yang akan datang. Hal-hal yang berkaitan dengan hukum harus diklarifikasi seawal mungkin yang dapat meliputi isu-isu pembayaran, hak cipta untuk sumber daya dan dokumentasi, hutang, jaminan, dan masalah-masalah yang berhubungan dengan hardware dan software yang disediakan oleh pabrik.
Kontrak Di luar Organisasi dan Di dalam Organisasi
Kontrak akan diterima secara luas jika organisasi eksternal atau perusahaan menyediakan layanan proyek. Mengapa ini bukan bagian dari proyek ? Walaupun hubungan antara tim proyek dan user sangat dekat harus ada sesuatu yang bersifat resmi, pernyataan tertulis menjelaskan layanan yang akan disediakan oleh tim proyek . Ini dapat dijadikan surat perjanjian (letter of intent) atau proposal resmi. Garis bawahi ini dan anda akan terhindar dari percekcokan yang tidak pernah berakhir.
5.3. PENINJAUAN PROPOSAL YANG DIKEMBALIKAN
User dapat mengembalikan proposal yang telah diterima dengan “sedikit” perubahan-perubahan. Waktu yang dijadwalkan untuk anggota teknis dari tim proyek untuk meninjau sedikit perubahan susunan kata dapat berarti upaya utama. Masalah harga dapat dinegosiasikan kembali.
Berhati-hati untuk tidak setuju pada kondisi dan persyaratan. Biarkan manajemen tingkat tinggi atau departemen yang sah menangani masalah ini. Jangan memulai pekerjaan sampai seluruh persetujuan selesai. Akan lebih menguntungkan anda untuk membiarkan user mengetahui kondisi-kondisi dan persyaratan sebelum menulis proposal.
5.4. KESIMPULAN UNTUK FASE DEFINISI
Ini akan membawa kita pada akhir fase definisi. Mari kita mengulang kejadian penting yang pernah dicapai. Ingat kembali kejadian penting yang digunakan untuk merencanakan proyek dan mengontrol kemajuan proyek.
1. Dokumen Kebutuhan (RD) yang lengkap dan telah disetujui oleh kedua belah pihak yaitu Tim proyek dan user.
2. Dokumen proposal dapat digunakan untuk analisis atau seluruh pengembangan, yang dilengkapi dan dibeli oleh user. Tulis persetujuan yang diinginkan.
3. Walaupun tidak mempertimbangkan kejadian penting, izin dari PPP itu dengan menyediakan sumber daya yang diperlukan.
BAB 5 Halaman 1 dari 5
BAB 5
NEGOSIASI DAN KONTRAK
5.1. NEGOSIASI
Mengapa bila orang pergi ke tempat perdagangan di Mexico, mereka akan melakukan negosiasi walaupun hanya untuk beberapa dolar saja, tetapi bila mereka melakukan transasksi dengan sebuah produk berharga ribuan dolar, mereka enggan untuk “tawar-menawar”. Tidak ada kata malu untuk melakukan negosiasi. Belajar dari bagaimana semua itu dilakukan dengan benar dan anda dapat menggunakan keahlian pada saat situasi tawar-menawar dalam lingkungan proyek software.
Ilmu Pengetahuan dan Seni Bernegosiasi
Kunci sukses dari negosiasi adalah mengetahui fakta yang sebenarnya. Hal pertama dan yang terpenting, mengetahui produk yang akan dijual atau dibeli.
Sebelum anda memulai negosiasi, tentukan dua hal :
1. Apa yang sepenuhnya anda inginkan untuk perjanjian
2. Apa yang akan anda berikan
Bila anda penjual software, hal yang akan dinegosiasikan adalah harga, ketahui harga minimum yang akan diminta. Jika anda pembeli, ketahui harga maksimum yang akan dibayarkan. Hal ini juga membantu jika anda mengetahui kebutuhan lawan anda, ini dikatakan dengan fleksibilitas.
Tiga hal yang dinegosiasikan dalam proyek software
Hal yang paling sering dinegosiasikan adalah harga, tetapi lamanya proyek dan fungsi proyek dapat juga dinegosiasikan. Seperti kata pepatah, “Anda akan mendapatkan yang murah, cepat atau bagus : pilih dua hal”. Anda dapat menghemat uang dengan mengambil waktu yang lebih lama. Atau apabila harga terlalu mahal, perhitungkan menawar dengan kelengkapan yang lebih sedikit.
Anda memperoleh apa yang anda bayar
Jika anda membeli produk, berhati-hatilah dengan tawar-menawar Tim proyek yang terlalu rendah, atau menerima tawaran murah yang tidak biasanya.
Contoh kasus :
Perusahaan ABC menawarkan tender keluar untuk kebutuhan software. Mereka menerima 2 tawaran :
Pertama dari Smart Software Co. (SSC). SSC mempunyai perkiraan akurat dan menawarkan harga $200 untuk dilaksanakan dalam 12 bulan.
Kedua, tawaran dari Unscrupulous Software Co. (USC). Mereka menawarkan $100 untuk jangka waktu 6 bulan.
Mencoba menghemat biaya, perusahaan ABC tentu saja menerima USC. Enam bulan kemudian setelah pembayaran $100 kepada USC, kejadian berikut ini terjadi :
ABC : Benarkah sistem akan diantar hari ini ?
USC : Kami mempunyai kabar buruk.
ABC : Kabar buruk apa ?
USC : Sayang sekali, kami telah menghabiskan $100, tetapi kami
baru menyelesaikan hanya setengah dari sistem yang tertulis. Anda punya dua pilihan : berikan kami $100 lagi (atau mungkin lebih), atau ambil saja setengah sistem anda.
ABC : Tetapi kita mempunyai kontrak !
USC : Saya harus menggaji programmer saya, jika tidak mereka
akan berhenti. Jika anda tidak membayar saya, saya akan dinyatakan bangkrut. Silakan kirim surat ke Brazil.
5.2. KONTRAK
Kontrak untuk produk software mengharuskan tim proyek untuk menyediakan pengirim khusus, seperti tanggal yang pasti, untuk berbagai macam pemberian upah. Kecuali proyek ini dilaksanakan pada dasar formal dalam organisasi eksternal, khususnya dalam dokumen “kontrak” yang tidak ingin dituliskan.
Bagian-bagian Kontrak (Items To Be Contracted)
Dalam tambahan untuk harga, tanggal pengiriman dan pengiriman, kontrak ini dapat termasuk dalam hal-hal dan kondisi lain seperti reproduksi, harga bertahan (price holding), lisensi atau garansi. Bila kerusakan dari software dapat menyebabkan tidak hidup atau situasi kritis lain, pertanggung jawaban dari pemulis harus diklarifikasikan. Jika perkiraan didasarkan pada input verbal dari user, “escape clause” harus diikutsertakan. Anjuran tim proyek ini berguna untuk keluar dari kesalahan informasi. Tanggung jawab user, seperti menyediakan informasi yang akurat dan tepat waktu, atau melakukan beberapa pekerjaan seperti dokumentasi, juga harus ditulis.
Kontrak Harga Tetap (The Fixed Price (FP) Contract)
Ini merupakan tipe umum dari kontrak. Di dalam kontrak FP, tim proyek mengajukan harga total pada awal proyek. Bagaimanapun juga tim proyek harus memperkirakan risiko di dalam kontrak FP. Gunakan kontrak FP hanya jika anda dapat memperhitungkan risiko dan harganya.
Kontrak FP sangat tepat bila :
1. Anda yakin bahwa tidak akan terjadi pergantian utama.
2. Anda akan bekerja dengan software dan produk hardware yang anda ketahui.
3. Anda memiliki komunikasi yang baik dengan user.
Kontrak Harga Tambahan (The Cost Plus (CP) Contract)
Apabila risiko terlalu tinggi dalam menentukan harga tetap, tim proyek harus memilih kontrak CP. Pada kontrak CP, tim proyek menerima gaji dalam jumlah tetap per-hari atau per-jam ditambah ongkos-ongkos. Biasanya perusahaan tidak membuat janji untuk berapa lama mereka membuat kontrak.
Kontrak CP sangat tepat bila :
1. Anda merasa bahwa pergantian utama akan terjadi (RD tidak ada atau kebutuhan lain tidak jelas).
2. Anda bekerja dengan tidak mengetahui sistem operasi, paket software atau hardware, atau anda mempunyai peralatan pengembangan khusus untuk menulis, seperti simulator, tes dasar, dsb.
3. Komunikasi yang kurang baik antara anda dan user.
4. Aktifitas utamanya berorientasi pada manusia, contohnya interview.
Kondisi dan Syarat (Terms and Conditions)
Jika anda menjalani kontrak CP, yakinkan bahwa kondisi dan persyaratan jelas.
Masukkan semua syarat dan kondisi – aspek hukum dari cara yang anda inginkan untuk bekerja dengan klien. Ini akan memeberikan perlindungan bagi anda dan klien, dan menghindari kesulitan yang akan datang. Hal-hal yang berkaitan dengan hukum harus diklarifikasi seawal mungkin yang dapat meliputi isu-isu pembayaran, hak cipta untuk sumber daya dan dokumentasi, hutang, jaminan, dan masalah-masalah yang berhubungan dengan hardware dan software yang disediakan oleh pabrik.
Kontrak Di luar Organisasi dan Di dalam Organisasi
Kontrak akan diterima secara luas jika organisasi eksternal atau perusahaan menyediakan layanan proyek. Mengapa ini bukan bagian dari proyek ? Walaupun hubungan antara tim proyek dan user sangat dekat harus ada sesuatu yang bersifat resmi, pernyataan tertulis menjelaskan layanan yang akan disediakan oleh tim proyek . Ini dapat dijadikan surat perjanjian (letter of intent) atau proposal resmi. Garis bawahi ini dan anda akan terhindar dari percekcokan yang tidak pernah berakhir.
5.3. PENINJAUAN PROPOSAL YANG DIKEMBALIKAN
User dapat mengembalikan proposal yang telah diterima dengan “sedikit” perubahan-perubahan. Waktu yang dijadwalkan untuk anggota teknis dari tim proyek untuk meninjau sedikit perubahan susunan kata dapat berarti upaya utama. Masalah harga dapat dinegosiasikan kembali.
Berhati-hati untuk tidak setuju pada kondisi dan persyaratan. Biarkan manajemen tingkat tinggi atau departemen yang sah menangani masalah ini. Jangan memulai pekerjaan sampai seluruh persetujuan selesai. Akan lebih menguntungkan anda untuk membiarkan user mengetahui kondisi-kondisi dan persyaratan sebelum menulis proposal.
5.4. KESIMPULAN UNTUK FASE DEFINISI
Ini akan membawa kita pada akhir fase definisi. Mari kita mengulang kejadian penting yang pernah dicapai. Ingat kembali kejadian penting yang digunakan untuk merencanakan proyek dan mengontrol kemajuan proyek.
1. Dokumen Kebutuhan (RD) yang lengkap dan telah disetujui oleh kedua belah pihak yaitu Tim proyek dan user.
2. Dokumen proposal dapat digunakan untuk analisis atau seluruh pengembangan, yang dilengkapi dan dibeli oleh user. Tulis persetujuan yang diinginkan.
3. Walaupun tidak mempertimbangkan kejadian penting, izin dari PPP itu dengan menyediakan sumber daya yang diperlukan.
BAB 5 Halaman 1 dari 5
Pengelolaan Proyek Sistem Informasi
BAB 4
PROPOSAL
4.1. PENDAHULUAN
Sebuah proposal mempunyai 3 kegunaan, yaitu :
1. Berisi perkiraan tim proyek, mulai dari biaya proyek sampai dengan tanggal pengiriman proyek.
2. Untuk proyek eksternal, dokumen hukum formal menunjukkan outline tim proyek untuk memberikan pelayanan yang diperlukan.
3. Sebagai alat penjualan. Proposal yang berisi usulan proyek akan dijual untuk mendapatkan keuntungan.
Kesalahan utama pada proposal dapat disebabkan 2 hal :
1. Tidak menawar, yang mana seharusnya bisa ditawar.
2. Ada tawaran, tetapi hilang dalam kompetisi.
4.2. DUA FASE PROPOSAL PROYEK SOFTWARE
Ada 2 fase proses proposal, yaitu :
1. Buat fase analisis sebagian kecil proyek, usulkan untuk dikerjakan dalam Proposal Analisis (Analysis Porposal).
2. Setelah analisis dikerjakan, usulkan sisanya dibangun dalam Proposal Pengembangan (Development Proposal).
4.3. MENULIS PROPOSAL
Menulis proposal itu sulit. Harus dilakukan dengan benar, selain dapat merusak reputasi anda dan mengubah masa depan bisnis anda dengan klien. Menulis proposal juga mahal, dibuat dengan mengumpulkan banyak sumber dan banyak hal, serta terkadang anda membayar orang untuk membuatnya.
Jika anda menulis proposal gunakan word processor dan gunakan huruf-huruf unik untuk setiap proposal, tetapi pastikan penulisan tersebut dibenarkan untuk setiap klien. Kerjakan dengan Requirement Document (RD), khususnya Request For a Proposal (RFP). Format proposal harus mengikuti RFP dan RD.
Garis besar Proposal (Proposal Outline) :
1. Cakupan Surat (Cover Letter)
Sebuah surat yang ditujukan kepada pengambil keputusan, ditandatangani oleh Manajer Proyek (jika diwakili oleh seorang Akuntan, maka Akuntan tersebut dapat menandatangani surat ini bersama klien yang lain).
• Bentuk dimulai dengan teks pendahuluan, seperti : “Thank you for giving XYZ Software Co. the opportunity to propose ……. For your computer system.”
• Paragraf berikutnya memberikan penjelasan yang mudah dari sistem, seperti “ …….hardware anda software to handle ABC’S registration, finance and management information needs for the next three years.”
• Paragraf berikutnya, jelaskan yang merupakan proposal analisis atau proposal pengembangan
• Penutup, akhiri surat dengan pernyataan yang menunjukkan kecepatan anda membuat keputusan di surat. Bagian penutup disertai batas akhir penentuan harga (biasanya 30 hari), atau pernyataan seperti , “If we are given a go-ahead in 14 days we can start January 1, otherwise we must do another project, and we can only start yours on June 1.” Penutup surat ini dibuat sebagus mungkin.
2. Halam Judul (Tittle Page)
Halaman ini berisi “Proposal”, judul dari sistem, pembuat, tanggal, nomor revisi, logo perusahaan, dan sebagainya.
3. Daftar Isi (Table of Contens)
Bila klien anda tidak terbiasa dengan format proposal anda, beri penjelasan dari kegunaan setiap bagian.
Berikut ini contoh formatnya :
Section 1 : TUJUAN Menggambarkan masalah bisnis yang disertai penyelesaian XYZ, ukuran, tingkat dan batasan yang disarankan untuk sistem penyelesaiannya …………………………… halaman 3
Section 2 : Keuntungan ………………………………….. halaman 4
4. Ruang Lingkup (Scope)
Lihat paragraf yang menjelaskan hal tersebut pada bagian ini langsung dari Requirement Documents.
5. Keuntungan (Advantages)
Jual proyek anda. Buktikan bagaimana perencanaan anda, kontrol dan 7 fase metodologi.
6. Keuangan (Financial)
Buat harga total dan tanggal pengiriman. Bila termasuk hardware, rinci harga hardware dan sistem operasinya.
Buat daftar non material, seperti job satisfaction, good will, customer happiness, management happiness, etc.
7. Rencana (Plan)
Gambarkan langkah-langkah rencana anda untuk membangun proyek. Jika proposal analisis, rinci alasan-alasan untuk penggunaan metode 2 langkah. Jelaskan fase analisis yang dihasilkan tidak terhingga nilainya, dokumen Functional Specification yang akan digunakan oleh Klien dan Tim proyek untuk spesifikasi yang tepat mengenai apa yang dilakukan sistem.
8. Kemampuan dalam penyampaian (Deliverablless)
Daftar user yang akan merinci :
• Hardware, sistem operasi, paket software: buat daftar secara rinci.
Keadaan bagaimana yang anda pilih salah satu fungsi, kapasitas dan tanggal pengiriman.
• Custom software : sama seperti di atas.
• Jaminan : berapa lama setelah pengiriman dan bagaimana anda akan memberikan dukungan.
• Dokumen : daftar manual (user, operator, manajer, maintenance) dengan penjelasan singkat dari pembaca.
• Pelatihan : daftar bagian (user, operator, manajer, maintenance) dengan penjelasan laporan singkat dari peserta.
• Gambarkan metode pengiriman : kapan anda akan mengirim, dimana akan dikirimnya dan bagaimana itu dilakukan.
9. Penerimaan (Acceptance)
Salah satu masalah yang sering terjadi dalam industri komputer adalah sistem yang ditolak. User menolak untuk menerima sistem (dan untuk membayarnya), karena dia merasa tidak seperti apa yang disetujui Tim proyek pada awal pengiriman.
10. Alternatif (Alternatives)
Kadang-kadang kita menentukan RFP ditulis langsung oleh penjual (hardware / software) dalam pikiran kita. Ini baik, jika anda adalah penjual, tetapi apa yang anda lakukan bila anda bukan penjual ?. Anda harus merinci solusi penjual-penjual lain, seperti ALTERNATIVE SOLUTION dan buktikan mengapa solusinya berbeda.
11. Istilah, Kondisi dan Pendapat
(Terms, Conditions and Assumptions)
Daftar yang ada disini adalah semua kondisi yang diinginkan untuk bekerja di dalam proyek internal. Daftarkan semua asumsi, jika asumsinya mempengaruhi biaya proyek, anda harus memproteksinya.
Daftar semua asumsi selalu ada pertanyaan dimana user tidak dapat menjawab dengan tepat, dan hanya dapat menjawab yang bersifat sementara jika asumsi tersebut mempunyai pengaruh yang bernilai pada proyek. User harus melaksanakan sendiri pendapatnya.
12. Istilah khusus (Terminologi)
Setiap proposal harus ditulis dengan menggunakan bahasa user yang mungkin, beberapa istilah komputer mungkin berbeda. Jika anda merasa bahwa istilah khusus ini tidak lazim bagi user, buat definisinya.
4.4. PROPOSAL INFORMAL
Proposal tidak harus dibuat di ruang rapat. Proposal tersebut dapat dibuat menjadi informal melalui telepon, tempat latihan golf, bahkan di bar.
Presentasi proposal secara formal yang dilakukan di ruang rapat akan selalu membutuhkan tempat, tetapi user sudah siap mengetahui hal-hal utama apa yang akan dikemukakan.
4.5. PERSETUJUAN PROPOSAL INTERNAL
Ada aturan di DEC Software Service yang menyatakan bahwa proposal tidak dapat keluar sebelum mendapat persetujuan dari manajemen tingkat tinggi. Persetujuan manajemen tingkat tinggi berhubungan dengan sejumlah hal yang diusulkan. Peraturan ini untuk menghindari hal-hal yang tidak diinginkan.
4.6. PRESENTASI PROPOSAL
Selalu siapkan presentasi. Siapkan dan buatlah jadwal semua peralatan yang dibutuhkan, seperti transparansi, proyektor, layar, sebuah terminal dan modem untuk berhubungan ke dalam sistem yang mirip dengan yang anda usulkan.
Buatlah presentasi di dalam ruangan yang tepat menurut anda, dimana menurut pandangan user akan lebih dapat diterima.
Langkah-langkah presentasi :
Buatlah ucapan pembuka. Perkenalkan tiap peserta, dan nyatakan tujuan pertemuan tersebut.
Perkenalkan proposal anda secara garis besar.
Bagikan proposal anda.
Beri waktu pada tiap peserta untuk membaca proposal.
Kemudian beri penekanan utama di setiap bagian yang penting.
Terakhir, tutup – sarankan user untuk membeli dan membeli secepatnya.
4.7. KESIMPULAN UNTUK PROPOSAL
Penulisan proposal dan mempresentasikannya merupakan sebuah seni.
Anda mungkin beruntung dan tidak harus membuat proposal.
Jangan membuat proposal asal jadi. Utamakan kualitas bukan kuantitas.
Jangan janjikan sesuatu yang tidak diminta oleh klien : Siapa yang anda pikir akan membayar ini ?
Rencanakan memberi solusi untuk semua masalah.
Dan akhirnya, untuk sebuah proyek eksternal, sebuah proposal adalah kumpulan dokumen yang sah. Hal ini seharusnya dibuat sebaik mungkin seperti untuk proyek di dalam yang dengan resmi dibuat seperti jika melakukan kontrak eksternal.
KASUS
Tidak menawar
Sebuah perusahaan minuman ringan mengundang seorang Analis dari Famous Minicomputer Manufacturing Company (FMMC), untuk mempelajari suatu kemungkinan pada suatu hal, jika ada sesuatu yang bermanfaat dari sistem komputerisasi pada pabrik minuman ringan tersebut. Si Analisis mempelajarinya, tetapi selama belajar dia menemui sedikit kesulitan dengan masalah akuntansi di perusahaan tersebut. Akuntan yang ada pada perusahaan tersebut takut kehilangan pekerjaan dengan adanya komputer, sehingga ia mempersulit Analis dengan menolak menjawab pertanyaan yang diajukan kepadanya.
Hasil dari yang dipelajari : Analis menyarankan bahwa beberapa penggunaan sistem komputerisasi akan membantu pekerjaan. Sehingga Analis menyarankan agar sistem komputer yang ada dapat digunakan untuk menjalankan pekerjaan bagian keuangan yang meliputi : piutang, hutang, kontrol persediaan, dll. Analis juga menyarankan untuk mengimplementasikan sistem tersebut untuk menangani masalah gaji, pajak, dan sejenisnya, serta menangani masalah produksi minuman yang meliputi proses produksi pembuatan minuman dan pengawasan barang-barang di gudang secara ototmatis. Ketika ditanya mengenai perincian harga untuk sistem tersebut, berdasarkan konsentrasi waktu, Analis menjelaskan bahwa hanya untuk sistem keuangan diperlukan biaya $150.000.
Reaksi dari user terlihat kasar. Singkatnya dia mengatakan bahwa $150.000 terlalu mahal untuk sistem komputer yang terlihat begitu sedikit kegunaannya. Dia mengatakan tidak akan membayar lebih dari $50.000 untuk sistem keuangan.
Kesalahan fatal dilakukan oleh Manajer si Analis tersebut. Berdasarkan reaksi user (dan mungkin untuk alasan pribadi), Analis menyarankan kepada manajernya agar FMMC menarik kembali penawarannya. Analis merasa bahwa user akan sulit untuk ditangani, dan user tidak akan menjawab pertanyaan-pertanyaan dengan benar. Dan bahwa FMMC dan perusahaan minuman ringan tersebut tidak akan pernah mencapai kesepakatan. Sayangnya Manajer tersebut menyetujuinya dan membatalkan penawaran.
Komentar : Semua user merasa bahwa harga sistem yang ditawarkan terlalu mahal. Mungkin user dapat saja menang dengan pendekatan lain yang berbeda. Analis dapat mengusulkan pembuatan sistem tersebut secara bertahap yaitu dengan membuat sistem dalam ukuran-ukuran yang lebih kecil, sehingga user tertarik. Mungin user memiliki uang, dan dia perlu bernegosiasi. Jangan pernah menyerah untuk menawar dalam pertemuan pertama. Mungkin saja ada masalah pribadi antara Akuntan yang takut kehilangan kedudukannya dengan Analis. Manajer harus mengetahui hal ini dan datang untuk membantu bernegosiasi.
Situasi di atas dapat terjadi pada proyek internal dimana seorang user dan klien berada pada dua departemen dalam satu perusahaan. Usahakan reaksi pertama untuk mengurangi harga. Rencanakan negosiasi. Kadang-kadang lawan anda hanya menguji untuk mengetahui seberapa yakin anda pada proposal anda. Bila anda menarik kembali penawaran haga dengan tergesa-gesa, dia akan mengetahui bahwa anda tidak percaya diri.
Penutup : Perusahaan minuman ringan tersebut menggunakan sistem komputerisasi dengan harga ditetapkan oleh Analis pertama, tetapi tidak oleh perusahaan FMMC.
Kehilangan Penawaran
Seorang pengarang buku terkenal “Software Project Management” (untuk proyek berukuran kecil) memulai karirnya memberi nasehat sebagai guru mikrokomputer. Dia berjalan-jalan di sekitar toko-toko mikrokomputer di kotanya dan memberi informasi pada pemilik toko bahwa ia dapat mengajar apapun pada siapapun. Sungguh meyakinkan, suatu hari ia mendapat panggilan dari departemen pemerintahan bagian pemeliharaan pesawat terbang. Tugas mereka adalah mengetahui siapa saja di negara tersebut yang sudah mendapat pelatihan mengenai jenis-jenis pesawat terbang.
Enam bulan yang lalu seorang anggota departemen telah membeli sebuah mikrokomputer kuno, lengkap dengan program data base yang tidak terdokumentasikan (dengan harga yang luar biasa), tetapi ia telah meninggalkan departemen tersebut sebelum data base diimplementasikan. Tidak seorangpun dari pegawai di departemen itu memiliki pengalaman komputer. Maka guru itu dipekerjakan untuk melatih pegawai di departemen itu dengan cukup baik, untuk menjalankan program data base pada komputer. Guru tersebut memperoleh informasi yang tepat dan berhasil mengajak orang-orang bagaimana menggunakan komputer dan program data base.
Sekitar satu bulan kemudian, guru itu menerima panggilan dari kepala departemen, yang menanyakan jika ia dapat mengajukan harga yang sebenarnya untuk menjalankan data base mereka. Guru tersebut mewawancarai pemakai data base yang berpotensi : ada 25 pemakai yang berpotensi dengan 50 pendapat yang berbeda tentang bagaimana menggunakan data base tersebut. Dengan catatan program data base tidak akan mengatasi semua kebutuhan mereka – program-program yang lainnya akan ditulis. Guru memperkirakan ini akan memakan waktu selama 3 bulan.
Kesempatan pertama si guru harus mengajukan proposal pada rapat komisi tingkat manajer dari 8 manajer departemen. Semua berjalan lancar sampai pada waktu ia mengemukakan harganya : 3 bulan untuk membuat program dengan biaya $400 per-hari, totalnya $20.000. Para manajer terkejut. Selama ini mereka hanya menghabiskan $1000 untuk hardware dan paket software, dan sekarang seorang yang dungu memberitahukan mereka bahwa ia akan menghabiskan $20.000 lagi untuk menjalankannya.
Komentar : Terkadang para pemakai tidak sadar akan harga software, khususnya pada mikrokomputer dimana harga hardware hanya sebagian kecil dari harga keseluruhannya. Pada kasus ini harapan para Manajer tidak ditetapkan dengan tepat untuk batasan harga tersebut.
Penutup : Mikrokomputer ini tetap ada di sana bersama dengan debu.
BAB 4 Halaman 1 dari 6
BAB 4
PROPOSAL
4.1. PENDAHULUAN
Sebuah proposal mempunyai 3 kegunaan, yaitu :
1. Berisi perkiraan tim proyek, mulai dari biaya proyek sampai dengan tanggal pengiriman proyek.
2. Untuk proyek eksternal, dokumen hukum formal menunjukkan outline tim proyek untuk memberikan pelayanan yang diperlukan.
3. Sebagai alat penjualan. Proposal yang berisi usulan proyek akan dijual untuk mendapatkan keuntungan.
Kesalahan utama pada proposal dapat disebabkan 2 hal :
1. Tidak menawar, yang mana seharusnya bisa ditawar.
2. Ada tawaran, tetapi hilang dalam kompetisi.
4.2. DUA FASE PROPOSAL PROYEK SOFTWARE
Ada 2 fase proses proposal, yaitu :
1. Buat fase analisis sebagian kecil proyek, usulkan untuk dikerjakan dalam Proposal Analisis (Analysis Porposal).
2. Setelah analisis dikerjakan, usulkan sisanya dibangun dalam Proposal Pengembangan (Development Proposal).
4.3. MENULIS PROPOSAL
Menulis proposal itu sulit. Harus dilakukan dengan benar, selain dapat merusak reputasi anda dan mengubah masa depan bisnis anda dengan klien. Menulis proposal juga mahal, dibuat dengan mengumpulkan banyak sumber dan banyak hal, serta terkadang anda membayar orang untuk membuatnya.
Jika anda menulis proposal gunakan word processor dan gunakan huruf-huruf unik untuk setiap proposal, tetapi pastikan penulisan tersebut dibenarkan untuk setiap klien. Kerjakan dengan Requirement Document (RD), khususnya Request For a Proposal (RFP). Format proposal harus mengikuti RFP dan RD.
Garis besar Proposal (Proposal Outline) :
1. Cakupan Surat (Cover Letter)
Sebuah surat yang ditujukan kepada pengambil keputusan, ditandatangani oleh Manajer Proyek (jika diwakili oleh seorang Akuntan, maka Akuntan tersebut dapat menandatangani surat ini bersama klien yang lain).
• Bentuk dimulai dengan teks pendahuluan, seperti : “Thank you for giving XYZ Software Co. the opportunity to propose ……. For your computer system.”
• Paragraf berikutnya memberikan penjelasan yang mudah dari sistem, seperti “ …….hardware anda software to handle ABC’S registration, finance and management information needs for the next three years.”
• Paragraf berikutnya, jelaskan yang merupakan proposal analisis atau proposal pengembangan
• Penutup, akhiri surat dengan pernyataan yang menunjukkan kecepatan anda membuat keputusan di surat. Bagian penutup disertai batas akhir penentuan harga (biasanya 30 hari), atau pernyataan seperti , “If we are given a go-ahead in 14 days we can start January 1, otherwise we must do another project, and we can only start yours on June 1.” Penutup surat ini dibuat sebagus mungkin.
2. Halam Judul (Tittle Page)
Halaman ini berisi “Proposal”, judul dari sistem, pembuat, tanggal, nomor revisi, logo perusahaan, dan sebagainya.
3. Daftar Isi (Table of Contens)
Bila klien anda tidak terbiasa dengan format proposal anda, beri penjelasan dari kegunaan setiap bagian.
Berikut ini contoh formatnya :
Section 1 : TUJUAN Menggambarkan masalah bisnis yang disertai penyelesaian XYZ, ukuran, tingkat dan batasan yang disarankan untuk sistem penyelesaiannya …………………………… halaman 3
Section 2 : Keuntungan ………………………………….. halaman 4
4. Ruang Lingkup (Scope)
Lihat paragraf yang menjelaskan hal tersebut pada bagian ini langsung dari Requirement Documents.
5. Keuntungan (Advantages)
Jual proyek anda. Buktikan bagaimana perencanaan anda, kontrol dan 7 fase metodologi.
6. Keuangan (Financial)
Buat harga total dan tanggal pengiriman. Bila termasuk hardware, rinci harga hardware dan sistem operasinya.
Buat daftar non material, seperti job satisfaction, good will, customer happiness, management happiness, etc.
7. Rencana (Plan)
Gambarkan langkah-langkah rencana anda untuk membangun proyek. Jika proposal analisis, rinci alasan-alasan untuk penggunaan metode 2 langkah. Jelaskan fase analisis yang dihasilkan tidak terhingga nilainya, dokumen Functional Specification yang akan digunakan oleh Klien dan Tim proyek untuk spesifikasi yang tepat mengenai apa yang dilakukan sistem.
8. Kemampuan dalam penyampaian (Deliverablless)
Daftar user yang akan merinci :
• Hardware, sistem operasi, paket software: buat daftar secara rinci.
Keadaan bagaimana yang anda pilih salah satu fungsi, kapasitas dan tanggal pengiriman.
• Custom software : sama seperti di atas.
• Jaminan : berapa lama setelah pengiriman dan bagaimana anda akan memberikan dukungan.
• Dokumen : daftar manual (user, operator, manajer, maintenance) dengan penjelasan singkat dari pembaca.
• Pelatihan : daftar bagian (user, operator, manajer, maintenance) dengan penjelasan laporan singkat dari peserta.
• Gambarkan metode pengiriman : kapan anda akan mengirim, dimana akan dikirimnya dan bagaimana itu dilakukan.
9. Penerimaan (Acceptance)
Salah satu masalah yang sering terjadi dalam industri komputer adalah sistem yang ditolak. User menolak untuk menerima sistem (dan untuk membayarnya), karena dia merasa tidak seperti apa yang disetujui Tim proyek pada awal pengiriman.
10. Alternatif (Alternatives)
Kadang-kadang kita menentukan RFP ditulis langsung oleh penjual (hardware / software) dalam pikiran kita. Ini baik, jika anda adalah penjual, tetapi apa yang anda lakukan bila anda bukan penjual ?. Anda harus merinci solusi penjual-penjual lain, seperti ALTERNATIVE SOLUTION dan buktikan mengapa solusinya berbeda.
11. Istilah, Kondisi dan Pendapat
(Terms, Conditions and Assumptions)
Daftar yang ada disini adalah semua kondisi yang diinginkan untuk bekerja di dalam proyek internal. Daftarkan semua asumsi, jika asumsinya mempengaruhi biaya proyek, anda harus memproteksinya.
Daftar semua asumsi selalu ada pertanyaan dimana user tidak dapat menjawab dengan tepat, dan hanya dapat menjawab yang bersifat sementara jika asumsi tersebut mempunyai pengaruh yang bernilai pada proyek. User harus melaksanakan sendiri pendapatnya.
12. Istilah khusus (Terminologi)
Setiap proposal harus ditulis dengan menggunakan bahasa user yang mungkin, beberapa istilah komputer mungkin berbeda. Jika anda merasa bahwa istilah khusus ini tidak lazim bagi user, buat definisinya.
4.4. PROPOSAL INFORMAL
Proposal tidak harus dibuat di ruang rapat. Proposal tersebut dapat dibuat menjadi informal melalui telepon, tempat latihan golf, bahkan di bar.
Presentasi proposal secara formal yang dilakukan di ruang rapat akan selalu membutuhkan tempat, tetapi user sudah siap mengetahui hal-hal utama apa yang akan dikemukakan.
4.5. PERSETUJUAN PROPOSAL INTERNAL
Ada aturan di DEC Software Service yang menyatakan bahwa proposal tidak dapat keluar sebelum mendapat persetujuan dari manajemen tingkat tinggi. Persetujuan manajemen tingkat tinggi berhubungan dengan sejumlah hal yang diusulkan. Peraturan ini untuk menghindari hal-hal yang tidak diinginkan.
4.6. PRESENTASI PROPOSAL
Selalu siapkan presentasi. Siapkan dan buatlah jadwal semua peralatan yang dibutuhkan, seperti transparansi, proyektor, layar, sebuah terminal dan modem untuk berhubungan ke dalam sistem yang mirip dengan yang anda usulkan.
Buatlah presentasi di dalam ruangan yang tepat menurut anda, dimana menurut pandangan user akan lebih dapat diterima.
Langkah-langkah presentasi :
Buatlah ucapan pembuka. Perkenalkan tiap peserta, dan nyatakan tujuan pertemuan tersebut.
Perkenalkan proposal anda secara garis besar.
Bagikan proposal anda.
Beri waktu pada tiap peserta untuk membaca proposal.
Kemudian beri penekanan utama di setiap bagian yang penting.
Terakhir, tutup – sarankan user untuk membeli dan membeli secepatnya.
4.7. KESIMPULAN UNTUK PROPOSAL
Penulisan proposal dan mempresentasikannya merupakan sebuah seni.
Anda mungkin beruntung dan tidak harus membuat proposal.
Jangan membuat proposal asal jadi. Utamakan kualitas bukan kuantitas.
Jangan janjikan sesuatu yang tidak diminta oleh klien : Siapa yang anda pikir akan membayar ini ?
Rencanakan memberi solusi untuk semua masalah.
Dan akhirnya, untuk sebuah proyek eksternal, sebuah proposal adalah kumpulan dokumen yang sah. Hal ini seharusnya dibuat sebaik mungkin seperti untuk proyek di dalam yang dengan resmi dibuat seperti jika melakukan kontrak eksternal.
KASUS
Tidak menawar
Sebuah perusahaan minuman ringan mengundang seorang Analis dari Famous Minicomputer Manufacturing Company (FMMC), untuk mempelajari suatu kemungkinan pada suatu hal, jika ada sesuatu yang bermanfaat dari sistem komputerisasi pada pabrik minuman ringan tersebut. Si Analisis mempelajarinya, tetapi selama belajar dia menemui sedikit kesulitan dengan masalah akuntansi di perusahaan tersebut. Akuntan yang ada pada perusahaan tersebut takut kehilangan pekerjaan dengan adanya komputer, sehingga ia mempersulit Analis dengan menolak menjawab pertanyaan yang diajukan kepadanya.
Hasil dari yang dipelajari : Analis menyarankan bahwa beberapa penggunaan sistem komputerisasi akan membantu pekerjaan. Sehingga Analis menyarankan agar sistem komputer yang ada dapat digunakan untuk menjalankan pekerjaan bagian keuangan yang meliputi : piutang, hutang, kontrol persediaan, dll. Analis juga menyarankan untuk mengimplementasikan sistem tersebut untuk menangani masalah gaji, pajak, dan sejenisnya, serta menangani masalah produksi minuman yang meliputi proses produksi pembuatan minuman dan pengawasan barang-barang di gudang secara ototmatis. Ketika ditanya mengenai perincian harga untuk sistem tersebut, berdasarkan konsentrasi waktu, Analis menjelaskan bahwa hanya untuk sistem keuangan diperlukan biaya $150.000.
Reaksi dari user terlihat kasar. Singkatnya dia mengatakan bahwa $150.000 terlalu mahal untuk sistem komputer yang terlihat begitu sedikit kegunaannya. Dia mengatakan tidak akan membayar lebih dari $50.000 untuk sistem keuangan.
Kesalahan fatal dilakukan oleh Manajer si Analis tersebut. Berdasarkan reaksi user (dan mungkin untuk alasan pribadi), Analis menyarankan kepada manajernya agar FMMC menarik kembali penawarannya. Analis merasa bahwa user akan sulit untuk ditangani, dan user tidak akan menjawab pertanyaan-pertanyaan dengan benar. Dan bahwa FMMC dan perusahaan minuman ringan tersebut tidak akan pernah mencapai kesepakatan. Sayangnya Manajer tersebut menyetujuinya dan membatalkan penawaran.
Komentar : Semua user merasa bahwa harga sistem yang ditawarkan terlalu mahal. Mungkin user dapat saja menang dengan pendekatan lain yang berbeda. Analis dapat mengusulkan pembuatan sistem tersebut secara bertahap yaitu dengan membuat sistem dalam ukuran-ukuran yang lebih kecil, sehingga user tertarik. Mungin user memiliki uang, dan dia perlu bernegosiasi. Jangan pernah menyerah untuk menawar dalam pertemuan pertama. Mungkin saja ada masalah pribadi antara Akuntan yang takut kehilangan kedudukannya dengan Analis. Manajer harus mengetahui hal ini dan datang untuk membantu bernegosiasi.
Situasi di atas dapat terjadi pada proyek internal dimana seorang user dan klien berada pada dua departemen dalam satu perusahaan. Usahakan reaksi pertama untuk mengurangi harga. Rencanakan negosiasi. Kadang-kadang lawan anda hanya menguji untuk mengetahui seberapa yakin anda pada proposal anda. Bila anda menarik kembali penawaran haga dengan tergesa-gesa, dia akan mengetahui bahwa anda tidak percaya diri.
Penutup : Perusahaan minuman ringan tersebut menggunakan sistem komputerisasi dengan harga ditetapkan oleh Analis pertama, tetapi tidak oleh perusahaan FMMC.
Kehilangan Penawaran
Seorang pengarang buku terkenal “Software Project Management” (untuk proyek berukuran kecil) memulai karirnya memberi nasehat sebagai guru mikrokomputer. Dia berjalan-jalan di sekitar toko-toko mikrokomputer di kotanya dan memberi informasi pada pemilik toko bahwa ia dapat mengajar apapun pada siapapun. Sungguh meyakinkan, suatu hari ia mendapat panggilan dari departemen pemerintahan bagian pemeliharaan pesawat terbang. Tugas mereka adalah mengetahui siapa saja di negara tersebut yang sudah mendapat pelatihan mengenai jenis-jenis pesawat terbang.
Enam bulan yang lalu seorang anggota departemen telah membeli sebuah mikrokomputer kuno, lengkap dengan program data base yang tidak terdokumentasikan (dengan harga yang luar biasa), tetapi ia telah meninggalkan departemen tersebut sebelum data base diimplementasikan. Tidak seorangpun dari pegawai di departemen itu memiliki pengalaman komputer. Maka guru itu dipekerjakan untuk melatih pegawai di departemen itu dengan cukup baik, untuk menjalankan program data base pada komputer. Guru tersebut memperoleh informasi yang tepat dan berhasil mengajak orang-orang bagaimana menggunakan komputer dan program data base.
Sekitar satu bulan kemudian, guru itu menerima panggilan dari kepala departemen, yang menanyakan jika ia dapat mengajukan harga yang sebenarnya untuk menjalankan data base mereka. Guru tersebut mewawancarai pemakai data base yang berpotensi : ada 25 pemakai yang berpotensi dengan 50 pendapat yang berbeda tentang bagaimana menggunakan data base tersebut. Dengan catatan program data base tidak akan mengatasi semua kebutuhan mereka – program-program yang lainnya akan ditulis. Guru memperkirakan ini akan memakan waktu selama 3 bulan.
Kesempatan pertama si guru harus mengajukan proposal pada rapat komisi tingkat manajer dari 8 manajer departemen. Semua berjalan lancar sampai pada waktu ia mengemukakan harganya : 3 bulan untuk membuat program dengan biaya $400 per-hari, totalnya $20.000. Para manajer terkejut. Selama ini mereka hanya menghabiskan $1000 untuk hardware dan paket software, dan sekarang seorang yang dungu memberitahukan mereka bahwa ia akan menghabiskan $20.000 lagi untuk menjalankannya.
Komentar : Terkadang para pemakai tidak sadar akan harga software, khususnya pada mikrokomputer dimana harga hardware hanya sebagian kecil dari harga keseluruhannya. Pada kasus ini harapan para Manajer tidak ditetapkan dengan tepat untuk batasan harga tersebut.
Penutup : Mikrokomputer ini tetap ada di sana bersama dengan debu.
BAB 4 Halaman 1 dari 6
Jumat, 05 Maret 2010
mata kuliah pengolahan proyek sistem informasi
Pengelolaan Proyek Sistem Informasi
BAB 1
TUJUH FASE PROYEK SOFTWARE
Ada 7 fase dari proyek software, yaitu :
1. DEFINITION
2. ANALYSIS
3. DESIGN
4. PROGRAMMING
5. SYSTEM TEST
6. ACCEPTANCE
7. OPERATION
Proyek software sama dengan membangun sebuah rumah
DEFINITION DEFINISIKAN RUMAH YANG AKAN DIBANGUN
ANALYISIS SPESIFIKASI RUMAH
DESIGN ARSITEK
PROGRAMMING KONSTRUKSI RUMAH
SYSTEM TEST BASEMENT, LANTAI 1, 2, ….
ACCEPTANCE RUMAH SUDAH SELESAI
OPERATION RUMAH SUDAH DAPAT DITEMPATI
Pengelolaan Proyek Sistem Informasi
BAB 2
FASE DEFINISI
Memahami Masalah User
2.1. PENDAHULUAN
Tujuan dari fase definisi adalah untuk memahami dengan baik masalah-masalah yang dihadapi oleh user dalam memperkirakan biaya dan waktu penyelesaian proyek.
Ada 3 aktifitas utama yang harus dilakukan dalam Fase Definisi :
Pertama
Anda harus memahami dengan baik masalah-masalah yang dihadapi oleh user dan apa saja yang dibutuhkan untuk menyelesaikan masalah tersebut (KEBUTUHAN).
Kedua
Anda harus memutuskan proyek akan dilaksanakan atau tidak.
Jika keputusannnya adalah melaksanakan proyek tersebut, Anda harus dapat menganalisis semua risiko-risiko yang mungkin terjadi yang dapat menggagalkan proyek tersebut. Analisis ini sangat membantu dalam penulisan PROPOSAL yang berisi rincian menganai proyek apa yang akan ditawarkan, kapan, dan berapa biayanya (termasuk biaya untuk risiko-risiko yang mungkin terjadi).
Tulislah beberapa dokumen dan temukan beberapa kejadian penting pada akhir fase ini.
Pertama, menulis Requirement Document (RD), yaitu dokumen yang berisi rincian kebutuhan user. Dokumen RD harus jelas dan lengkap, sehingga Tim Proyek (Project Tem (PT)) dapat memahami seluruh masalah-masalah yang dihadapi oleh user dan dapat memperkirakan biaya penyelesaian proyek tersebut.. Kejadian penting pertama yang akan Anda hadapi berupa persetujuan atau penandatanganan dokumen RD oleh User dan Tim Proyek.
Selanjutnya, menulis Pendahuluan Perencanaan Proyek (Preliminary Project Plan (PPP)). PPP merupakan langkah pertama dalam merencanakan langkah-langkah berikutnya yang harus diambil untuk mengembangkan produk dan sumber-sumber apa saja yang dibutuhkan untuk setiap langkahnya. Rencana tersebut menggambarkan berapa lama sumber-sumber tersebut akan diperlukan dan berapa banyak biaya yang akan dikeluarkan.
Ketiga
Anda harus memberikan perkiraan-perkiraan ini kepada user dalam bentuk PROPOSAL.
Seberapa jauh perkiraan-perkiraan tersebut dapat dipertanggung jawabkan ? Ada dua alasan dalam hal ini. Pertama, kita tidak begitu ahli dalam memperkirakan sesuatu. Kedua, perkiraan-perkiraan tersebut dibuat pada saat masih dalam tahap pendefinisian masalah, dimana pada saat itu baru sebagian kecil informasi yang kita peroleh dari masalah yang sedemikian luas.
Jika anda tidak yakin dengan kebutuhan-kebutuhan yang telah digambarkan secara akurat dalam dokumen RD, disarankan untuk membagi proyek tersebut menjadi 2 tahap : Fase Analisis sebagai proyek pertama diikuti dengan fase sebelumnya sebagai proyek kedua.
Pada saat pendefinisian, proposal anda hanya akan menjadi analisis saja, dan ini disebut PROPOSAL ANALISIS. Setelah analisis akan ada PROPOSAL PENGEMBANGAN (Lihat bab 3). Kedua hal ini disebut dengan dua fase proposal. Kejadian penting yang terdapat disini adalah pembelian proposal oleh user.
2.2. DOKUMEN KEBUTUHAN (REQUIREMENT DOCUMENT / RD)
RD menyatakan masalah-masalah yang dihadapi user dan solusi umum yang dibutuhkan. Bahasanya berorientasi pada bahasa yang digunakan oleh user sehari-hari, dan jauh dari bahasa komputer. Kadangkala dokumen RD digunakan sebagai permohonan untuk sebuah proposal (Request for a proposal (RFP)) ketika user menawarkan proyeknya kepada kontraktor luar.
Tanya jawab dengan User
Proses tanya jawab dilakukan untuk mendapatkan informasi yang tepat dari user untuk memperoleh RD yang baik. User akan memberikan semua informasi yang anda butuhkan dan tidak lebih. Tim proyek interviewer berkewajiban untuk mempelajari semua bisnis user, memahami teknologi user, dan mengajukan pertanyaan-pertanyaan.
Masalah terbesar berkaitan dengan pemakai akhir (end-user) yang sesungguhnya petugas pemasukan data atau petugas pengirim barang yang berada di gudang. Seringkali manajer atau supervisor mengatakan bahwa pemakai akhir sangat sibuk dan tidak mampu untuk memberikan informasi yang dapat dipercaya. Terkadang manajer merasa dilangkahi atau diremehkan jika anda berhubungan langsung dengan pemakai akhir yang berada di departemen mereka. Solusi dari masalah ini adalah mendidik para wakil tim proyek tersebut bagaimana pentingnya komunikasi dengan para pemakai akhir yang sebenarnya. Jika masukkan yang mereka kemukakan tidak mendapat tanggapan pada awal pendefinisian, akan sangat mungkin terjadi perubahan-perubahan di kemudian hari dan hal ini berarti akan membutuhkan biaya yang cukup mahal untuk memperbaikinya. Mintalah izin dari manajer yang berwenang pada saat akan mewawancarai orang-orang mereka.
Siapkan rencana untuk melakukan wawancara. Pelajari tentang bisnis yang mereka lakukan, dan tulislah pertanyaan-pertanyaan yang akan diajukan. Berikut ini pertanyaan yang berhubungan dengan wawancara yang akan dilakukan :
Pertama, cari tahu tentang aliran informasi yang ada dalam perusahaan tersebut. Mulailah dengan pertanyaan-pertanyaan seperti : informasi apa saja yang dibutuhkan untuk menjalankan kegiatan bisnis perusahaan ? Seberapa penting aliran data, baik antara departemen maupun antar individual ? Tentukan frekuensi, waktu dan keakuratannya.
Kedua, masukkan-masukkan yang diterima diikuti dengan pertanyaan-pertanyaan sebagai berikut : Informasi apa saja yang dibutuhkan untuk menghasilkan masing-masing barang? Informasi apa yang tersedia, kapan, dimana ? Informasi-informasi baru apa saja yang harus dikumpulkan ? Ingat tentang 5 W (Who, What, Where, When, Why). Sediakan waktu untuk pertanyaan-pertanyaan di atas selama membuat.
Hal-hal yang terdapat dalam RD
Berikut ini adalah bagian-bagian dari RD :
1. Pendahuluan. Identifikasi perusahaan (user) dan juga penjual dimana RD tersebut ditujukan. Tentukan masalah yang perlu diselesaikan, latar belakang, contoh situasi yang sedang dihadapi, motivasi-motivasi untuk menanggulanginya, dll. Bagian ini digunakan untuk memperkenalkan potensi penjual kepada perusahaan user atau departemen jika diperlukan, jelaskan kultur, lingkungungan, dan bagaimana jalannya bisnis yang dilakukan. Berikan pengertian kepada Tim Proyek tentang masalah yang dihadapi user.
2. Tujuan Proyek. Sebuah pernyataan singkat mengapa kita mengajukan proposal untuk pengembangan proyek. Batasan-batasan utama dalam penggunaan waktu dan keuangan dapat juga disebutkan.
3. Fungsi-fungsi Utama. Pernyataan singkat mengenai bagaimana sistem berfungsi berdasarkan tujuan proyek yang telah ditetapkan.
4. Keluaran Umum. Penjelasan secara singkat tentang informasi yang dibutuhkan dari sistem.
5. Informasi Input secara Umum. Input data apa yang diperlukan untuk menghasilkan output. Ini adalah waktu yang tepat untuk memastikan bahwa seluruh data yang dibutuhkan dapat tersedia pada waktu yang tepat pula.
6. Kinerja (Performance). Berapa banyak transaksi yang akan diproses, berapa banyak data yang akan disimpan, kapan laporan harus dihasilkan, dsb. Jelaskan waktu rata-rata dan waktu maksimal proses (dalam hari atau jam).
7. Perkembangan (Growth). Hal ini mungkin sulit untuk diramalkan, tetapi cobalah untuk menghitung kemajuan bisnis dan menetapkan berapa tahun lagi sistem masih dapat diharapkan untuk berfungsi. Kemukakan dalam bentuk persentase atau angka sebenarnya.
8. Pengoperasian dan Lingkungan. Dimana komputer akan ditempatkan, dimana terminal-terminal yang interaktif ditempatkan, dan siapa yang akan menggunakannya.
9. Kompatibilitas, Pengantarmukaan. Jelaskan jika fasilitas antar komputer dibutuhkan, adakah alat-alat yang harus disatukan, atau jika pengiriman akses dibutuhkan. Jika sistem hanya dapat berjalan dengan komputer yang ada, atau harus dapat diprogram dengan bahasa yang spesifik, semua dokumen dinyatakan di dalam bagian ini.
10. Reliabilitas, Ketersediaan. Tulis penggambaran waktu diantara kegagalan-kegagalan (Meantime between Failures / MTBF), waktu untuk perbaikan (Meantime to Repair / MTTR) dan persentase tambahan yang diperlukan. Semua manufaktur menyatakan penggambaran ini untuk hardware mereka.
11. Pengantarmukaan dengan Pemakai. Rincikan pengalaman-pengalaman yang dibutuhkan user dalam menggunakan komputer, jelaskan bagaimana menangani sistem kapada user yang baru.
12. Pengaruh Organisasi. Departemen-departemen apa yang akan sangat berpengaruh dan seberapa jauh cara kerja mereka harus berubah. Bagaimana sistem yang baru dapat berkomunikasi dengan sistem manual yang ada.
13. Pemeliharaan dan Dukungan. Jaminan-jaminan yang dibutuhkan : berapa lama, sampai kapan, bagaimana pengiriman.
14. Dokumentasi dan Pelatihan. Rincikan semua dokumen-dokumen umum dan / atau pelatihan yang dibutuhkan.
15. Keuntungan (hanya RFP). Jika RD adalah RFP dalam situasi yang kompetitif, mintalah data dari penjual yang menjelaskan mengapa dokumen tersebut harus dipilih. Minta data yang relevan dari penjual yang berpengalaman, komitmen, metodologi proyek, contoh-contoh proyek yang sukses, dan referensi dimana anda dapat menghubungi penjual tersebut.
16. Persyaratan dan Kondisi. Menyatakan syarat untuk seleksi, kapan dan bagaimana akan dilakukan.
2.3. TANGGUNG JAWAB USER
Meskipun user tidak menulis RD, dia bertanggung jawab untuk menyediakan pewawancara tim proyek yang dapat dipercaya, dan informasi tepat pada waktunya. User harus dapat mengajukan orang yang mengetahui tentang semua sistem yang ada dan apa saja yang dibutuhkan untuk sistem baru.
2.4. KEPUTUSAN MELAKSANAKAN / TIDAK MELAKSANAKAN PROYEK
Setelah kebutuhan-kebutuhan ditetapkan, langkah berikutnya adalah memutuskan apakah proyek bernilai untuk dikerjakan atau tidak. Untuk membantu membuat keputusan itu, suatu studi kelayakan dilakukan untuk menjawab pertanyaan : “Dapatkah sistem ini dibangun secara teknik ? Sayangnya, tidak semuanya mungkin secara teknik, sehingga pertanyaan-pertanyaan untuk dijawab diubah menjadi, “Dengan biaya berapa sistem dapat dibangun, dan apa keuntungannya ?
Dalam suatu studi kelayakan kita mempertimbangkan semua penyelesaian masalah teknis yang mungkin, dan coba untuk memperkirakan biaya dari masing-masing penyelesaian masalah. Untuk suatu proyek yang berukuran besar, kita mempertimbangkan keputusan utama mengenai hardware apa yang digunakan, dan apakah akan membuat atau membeli software. Untuk proyek berukuran kecil sampai menengah studi kelayakan yang formal tidak perlu ditulis. Biasanya cukup dengan mengangkat seseorang untuk mempelajari penyelesaian masalah yang mungkin dan menilai keuntungan-keuntungan.
Perkiraan keuntungan ini mungkin saja mudah, tetapi seharusnya tidak dipergunakan. Manajer proyek tidak hanya harus menjawab “Apakah proyek ini secara teknik dapat dikerjakan ?” tetapi juga menjawab pertanyaan yang lebih penting : “Apakah proyek ini dapat dikerjakan oleh saya sekarang ?”
Manajer proyek harus bertanya pada diri sendiri apakah proyek yang ada memiliki peluang untuk sukses, atau proyek tersebut akan mengalami kegagalan disebabkan oleh terbatasnya sumber-sumber, pengetahuan, atau risiko di luar kekuasaannya. Tidak terkira proyek-proyek telah gagal secara keseluruhan maupun sebagian, karena orang mengabaikan tanda-tanda penting dan nyata yang menunjukan kegagalan. Setiap rencana dipengaruhi oleh risiko.
2.5. MANAJEMEN RISIKO
Menurut sejarah, industri pemrosesan data telah membuat reputasi yang buruk sekali karena meremehkan proyek-proyek yang ada. Ketika ditanya tentang alasannya, para ahli pemrosesan data membela diri dengan meberikan pernyataan seperti : “Saya menilai dengan benar berdasarkan fakta-fakta yang diberikan kepada saya.
Alasan yang menumpuk adalah bahwa :
(Pilih satu atau lebih : Si pemakai mengubah pikirannya ….. tidak pernah memberitahukan saya tentang… dan departemen- departemen yang lain menjanjikan ….. dan manajemen tingkat atas mendikte penilaian ….. dengan kata lain, itu bukan kesalahan saya !)
Solusi standar industri untuk semua masalah-masalah ini adalah :
SOLUSI 1. Selidiki masalah-masalah yang ada
SOLUSI 2. Hukum yang tidak bersalah
SOLUSI 3. Promosikan yang tidak terlibat
SOLUSI 4. Kembali ke solusi 1 dan berputar sampai membosankan
2.6. EMPAT LANGKAH MANAJEMEN RISIKO
Setiap proyek akan tepat waktu dan sesuai anggaran jika tidak ada yang salah. Penting sekali untuk berkosentrasi pada hal-hal yang akan menyebabkan salah dan coba untuk menghindari kesalahan-kesalahan tersebut. Hal ini disebut Manajemen Risiko.
Manajemen risiko terdiri dari empat langkah :
Langkah 1. Antisipasi risiko
Langkah 2. Singkirkan risiko yang mungkin terjadi
Langkah 3. Kurangi dampak risiko
Langkah 4. Tetap tenang ketika terjadi kesalahan
Pengelolaan Proyek Sistem Informasi
BAB 3
PERENCANAAN PROYEK
3.1. PENDAHULUAN
Sekarang anda sudah mengevaluasi proyek dan memutuskan untuk melanjutkannya. Pertama, anda harus meyakinkan rekan-rekan lain bahwa proyek sebaiknya dilaksanakan. Hal ini dilakukan dengan membuat proposal. Untuk sebuah proyek eksternal, proposal ditulis untuk meyakinkan klien agar membeli proyek dari tim proyek anda. Untuk proyek internal, manajemen sebaiknya meminta untuk membuat sebuah proposal. Hal ini untuk mendukung tim proyek untuk membuat rencana yang sederhana.
Sebuah proposal adalah dokumen yang merinci biaya dan jadwal proyek, serta menjelaskan langkah-langkah yang akan diambil oleh tim proyek untuk menghasilkan produk yang diinginkan.
Perencanaan adalah sebuah proses yang berulang-ulang : rencana akan ditinjau secara terus menerus sesuai dengan perkembangan proyek dan sesuai dengan bertambahnya pengetahuan dan pemahaman yang lebih baik dari anggota tim. Perencanaan memang merupakan pekerjaan yang sangat sulit, tetapi harus dilaksanakan sebagaimana mestinya. Banyak proyek menjadi kacau dikarenakan tidak adanya perencanaan.
3.2. PENDAHULUAN PERENCANAAN PROYEK
(THE PRELIMINARY PROJECT PLAN / PPP)
Pendahuluan Perencanaan Proyek adalah langkah awal, sumber daya, biaya dan jadwal yang dibutuhkan untuk menyelesaikan proyek. PPP adalah dokumen internal, tidak perlu ditunjukkan ke user, terutama user luar.
3.3. RINCIAN STRUKTUR KERJA
(WORK BREAKDOWN STRUCTURES / WBS)
Kunci berbagai rencana adalah memecah kegiatan yang diperlukan ke dalam sebuah bagian yang lebih kecil lagi. Rincian struktur kerja (WBS) diawali dengan menyusun komponen-komponen utama proyek. Hal ini merupakan Level 1 dari WBS (Level 0 adalah judul proyek).
Untuk proyek software, metode terbaik untuk pemecahan proyek menjadi bagian-bagian utama adalah diawali dengan 7 fase pengembangan software.
Lihat Gambar 3.1. Rincian Struktur Kerja / WBS
Lihat Gambar 3.2. WBS untuk analisis
Sistem Penomoran WBS
Sistem penomoran dalam WBS seperti pada gambar 3.2 :
- Untuk Level 0 atau judul proyek adalah 0.0.
- Pada Level 1 masing-masing item diberi nomor N.0.
Contoh : 1.0, 2.0, dst.
- Kemudian masing-masing item pada Level 2 dibawah item N.0 pada Level 1 diberi nomor N.1, N.2, dst.
Contoh : di bawah Level 1 item Analysis yang bernomor 2.0, kita mempunyai item 2.1, 2.2, dst.
- Sedangkan untuk Level 3, kita tambahkan titik dan digit dari nomor di Level 2. Sebagai contoh, dibawah 2.1 kita harus menuliskan 2.1.1, 2.1.2, dst.
Kapan Anda Berhenti ?
Pemasukkan nomor pada level terendah menunjukkan tugas atau kegiatan dalam proyek. Anda dapat berhenti merinci sebuah kegiatan jika mengikuti langkah-langkah berikut dengan benar :
1. Beberapa orang (atau grup dari sebuah proyek besar) dapat diberikan tanggung jawab untuk melakukan tugas atau menyelesaikan kegiatan-kegiatan yang dilibatkan.
2. Anda dapat memperoleh perkiraan (berupa orang atau hari) secara garis besar sebagai upaya yang dibutuhkan untuk melaksanakan kegiatan-kegiatan yang terlibat. Hal ini dapat dilakukan dengan memberi tanggung jawab pada setiap orang.
3. Anda dapat menjadwalkan tugas.
4. Tugas-tugas tersebut harus singkat dan dapat diselesaikan.
Sebagai seorang ahli kita dapat menetapkan sebuah tugas kepada Programmer, Analis, atau bahkan Manajer Proyek. Tergantung pada pengalaman dan keahlian dalam membuat perkiraan, analis mungkin hanya memerlukan level 1 dari WBS. Beberapa analis dapat dengan mudah membaca RD untuk proyek ABC (Appendix A) secara keseluruhan. Analis lain untuk merinci membutuhkan sampai Level 2. Seperti pada gambar 3.2, analis lainnya memerlukan sampai Level 3 sebelum mereka dapat memperkirakan secara keseluruhan.
Sebagai contoh Level 3 WBS untuk kotak INTERVIEW dan ANALYZE EXISTING SYSTEMS dapat dilihat pada gambar 3.3.
Lihat Gambar 3.3. WBS Level 3
Para ahli merinci setiap kotak pada level terendah sampai ia dapat memperkirakan berapa upaya yang diperlukan. Perkiraan-perkiraan ini dapat dipakai pada WBS seperti pada gambar 3.4. Sebagai catatan bahwa perkiraan total adalah jumlah dari masing-masing waktu. Hal ini disebut DIRECT time, yaitu jumlah hari yang sesungguhnya dibutuhkan untuk melakukan kegiatan .
Lihat Gambar 3.4. Analysis Level 3
Para ahli tersebut dengan cara yang sama dapat merinci kotak yang lain (DEFINE NEW SYSTEM FUNCTIONS, WRITE FUNCTIONAL SPEC. dan NEGOTIATE FUNCTIONAL SPEC.) dan menambahkan total waktu untuk semua analisis. Kemudian ahli tersebut mengajukan perkiraan dan daftar kegiatan sebelumnya yang dibutuhkan untuk seluruh analisis bagi Manajer Proyek. Orang tersebut bertanggung jawab terhadap perencanaan (mungkin Manajer Proyek untuk proyek berukuran kecil - menengah) kemudian menggabungkan seluruh perkiraan dan daftar kegiatan terdahulu. Ia mungkin mengakhirnya dengan daftar seperti berikut ini :
ACTIFITY EFFORT PRECEDENTS
Definition 20 -----------------
Analysis 35 Definition
Design 25 Analysis
Program A (Control) 20 Design
Program B (Registration) 30 Design
Program C (Warehouse) 25 Design
System test 10 Program A, B, C
Documentation 20 Design
Acceptance 5 System Test,
Documentation
Training 10 Documentation
Operation 10 Acceptance
TOTAL 210 person-days
3.4. DIAGRAM JARINGAN (THE NETWORK DIAGRAM)
Langkah kedua dari perencaan adalah menggambarkan diagram jaringan yang menunjukkan urutan kejadian. Tipe diagram yang paling baik untuk masalah ini adalah bagan PERT. Gambar 3.5. adalah sebuah bagan PERT untuk proyek di atas. Urutan kejadian hanya didasarkan pada contoh setiap kegiatan.
Lihat Gambar 3.5. Bagan PERT
Bentuk dari bagan PERT ini disebut Precedence Network (jaringan yang diutamakan). Setiap kotak menunjukkan sebuah kegiatan. Pada setiap kotak ditulis nama kegiatan dan waktu yang diperlukan.
Jalur Kritis & Lamanya Proyek
Bagan PERT dan jalur kritis adalah jumlah jalur, atau serangkaian kegiatan yang dapat ditelusuri pada PERT sederhana di atas, dengan mengikuti petunjuk garis panah. Lamanya waktu yang dibutuhkan untuk menelusuri setiap jalur dapat dijumlahkan dengan menambahkan lamanya waktu dari jalur masing-masing kegiatan.
Jalur kritis (CP / Critical Path) adalah jalur terpanjang dan didefinisikan waktu minimal yang dibutuhkan untuk mengerjakan proyek.
PERT pada gambar 3.5. mempunyai jalur kritis yang terdiri dari kegiatan : START, DEFINITION, ANALYSIS, DESIGN, PROGRAM B, SYSTEM TEST, ACCEPTANCE, OPERATION, dan END. Proyek tersebut membutuhkan total waktu : 135 hari.
3.5. MENGHITUNG BIAYA PROYEK
(CALCULATING PROJECT COST)
Jika kontrak proyek telah mempunyai harga tetap, Manajer Proyek dapat menghitung biaya kasar untuk tenaga kerja, dengan cara mengalikan jumlah tenaga kerja per-hari dengan rata-rata biaya per-hari.
Biaya pekerja perhari disebut ‘biaya penuh’ : yang harus mencakup biaya operasi, sewa, administrasi pekerja, dan keuntungan. Untuk itu anda harus menambahkan biaya tetap, seperti computer time, sewa peralatan khusus, biaya tak terduga, dan sebaginya. Biaya tetap harus dirinci oleh setiap estimator untuk kegiatan utamanya.
Lihat Gambar 3.6. SUPERPROJECT
Rata-rata Pgr 75 pd @ $1000 per pd 75,000
Keuntungan 25% 18,750
Faktor risiko :
User berubah pikiran terhadap 10% format
Biaya = 10% tambahan waktu pemrograman 7,500
Total pemrograman $ 101,250
3.6. PENJADWALAN PROYEK (PROJECT SCHEDULE)
Langkah selanjutnya adalah menghitung jadwal proyek. Untuk melakukan hal ini, perencana (mungkin Manajer Proyek) harus mengaplikasikan jadwal yang sebenarnya dari perkiraan ke CALENDAR DAYS (jadwal harian) atau lamanya pekerjaan.
Salah satu kesulitan tugas ini adalah mengalokasikan sumber daya manusia yang akan bekerja pada kegiatan yang akan dilaksanakan, terutama ketika pekerjaan berlangsung secara serentak. Kesulitan lain adalah memutuskan bagaimana mempersingkat pekerjaan yang dilakukan dengan menggunakan sumber daya yang ada.
Kemudian Manajer Proyek menjadwalkan semua proyek pada kelender atau jadwal yang nyata. Metode terbaik untuk melakukan hal ini adalah dengan menggambarkan ke dalam sebuah Gantt Chart atau Bar Chart seperti pada gambar 3.7.
Lihat Gambar 3.7. SUPERPROJECT project schedule
3.7. Outline Pendahuluan Perencanaan Proyek
(PRELIMINARY PROJECT PLAN OUTLINE)
Dilengkapi dengan semua pengetahuan ini, Manajer Proyek dapat menuliskan dokumen penting ini. Berikut ini adalah outline yang disarankan untuk PPP.
1. Tim Proyek (The Project Team)
Menggambarkan struktur, siapa yang memberikan laporan, siapa yang menerima laporan, kepada siapa berkomunikasi, dst.
Lihat Gambar 3.8. Typical Project Team Structure
Programmer (tidak lebih dari 5 orang). Bertanggung jawab terhadap pemrograman.
Pimpinan Proyek (Project Leader)
Mengawasi programmer.
Bertanggung jawab terhadap kegiatan-kegiatan yang bersifat teknis, seperti analisis, disain dan tugas-tugas pemrograman keseluruhan.
Tujuan utama : kualitas produk yang dihasilkan secara teknik.
Manajer Proyek (Project Manager)
Manajer dalam tim (pimpinan, motivator, dll).
Bertanggung jawab terhadap semua komunikasi yang datangnya dari luar (laporan, pertemuan-pertemuan, penghubung antara manajemen tingkat atas dengan user).
Tujuan utama : keberhasilan proyek (perencanaan, pengontrolan, komunikasi).
2. Biaya Proyek (Projects Cost)
Termasuk WBS, membuat perkiraan dan perhitungan yang digunakan untuk menaksir biaya dalam pembuatan produk.
3. Penjadwal Proyek (Project Schedule)
Merupakan bagian terpenting dalam proyek, dan dapat menggunakan metode Gantt.
4. Pemeriksaan Ulang (Reviews)
Pada bagian ini anda dapat menghubungkan antara pertemuan dari manajemen utama dengan peninjau teknik (jadwal proyek akan memberikan informasi ini), tujuan dari masing-masing peninjau, dan siapa yang akan mengerjakannya. Buatlah daftar tanggung jawab dari orang-orang yang terlibat.
5. Laporan (Reports)
Bentuk dan isi dari laporan keadaan, laporan milestone dan dokumen proyek lain dapat dirinci di dalam laporan tersebut.
6. Dokumentasi (Documentation)
Ada 2 jenis dokumen di dalam proyek, yaitu user dan manajemen proyek.
7. Asumsi (Assumptions)
Disini anda dapat menentapkan harga berdasarkan asumsi : dimana sebagian besar adalah fakta yang diberikan oleh user.
3.8. KESIMPULAN UNTUK PERENCANAAN
Perencanaan itu seperti menunggang kuda : kelihatannya sulit sebelum anda mencobanya. Tetapi begitu anda mencobanya, maka segalanya akan menjadi mudah.
BAB 1
TUJUH FASE PROYEK SOFTWARE
Ada 7 fase dari proyek software, yaitu :
1. DEFINITION
2. ANALYSIS
3. DESIGN
4. PROGRAMMING
5. SYSTEM TEST
6. ACCEPTANCE
7. OPERATION
Proyek software sama dengan membangun sebuah rumah
DEFINITION DEFINISIKAN RUMAH YANG AKAN DIBANGUN
ANALYISIS SPESIFIKASI RUMAH
DESIGN ARSITEK
PROGRAMMING KONSTRUKSI RUMAH
SYSTEM TEST BASEMENT, LANTAI 1, 2, ….
ACCEPTANCE RUMAH SUDAH SELESAI
OPERATION RUMAH SUDAH DAPAT DITEMPATI
Pengelolaan Proyek Sistem Informasi
BAB 2
FASE DEFINISI
Memahami Masalah User
2.1. PENDAHULUAN
Tujuan dari fase definisi adalah untuk memahami dengan baik masalah-masalah yang dihadapi oleh user dalam memperkirakan biaya dan waktu penyelesaian proyek.
Ada 3 aktifitas utama yang harus dilakukan dalam Fase Definisi :
Pertama
Anda harus memahami dengan baik masalah-masalah yang dihadapi oleh user dan apa saja yang dibutuhkan untuk menyelesaikan masalah tersebut (KEBUTUHAN).
Kedua
Anda harus memutuskan proyek akan dilaksanakan atau tidak.
Jika keputusannnya adalah melaksanakan proyek tersebut, Anda harus dapat menganalisis semua risiko-risiko yang mungkin terjadi yang dapat menggagalkan proyek tersebut. Analisis ini sangat membantu dalam penulisan PROPOSAL yang berisi rincian menganai proyek apa yang akan ditawarkan, kapan, dan berapa biayanya (termasuk biaya untuk risiko-risiko yang mungkin terjadi).
Tulislah beberapa dokumen dan temukan beberapa kejadian penting pada akhir fase ini.
Pertama, menulis Requirement Document (RD), yaitu dokumen yang berisi rincian kebutuhan user. Dokumen RD harus jelas dan lengkap, sehingga Tim Proyek (Project Tem (PT)) dapat memahami seluruh masalah-masalah yang dihadapi oleh user dan dapat memperkirakan biaya penyelesaian proyek tersebut.. Kejadian penting pertama yang akan Anda hadapi berupa persetujuan atau penandatanganan dokumen RD oleh User dan Tim Proyek.
Selanjutnya, menulis Pendahuluan Perencanaan Proyek (Preliminary Project Plan (PPP)). PPP merupakan langkah pertama dalam merencanakan langkah-langkah berikutnya yang harus diambil untuk mengembangkan produk dan sumber-sumber apa saja yang dibutuhkan untuk setiap langkahnya. Rencana tersebut menggambarkan berapa lama sumber-sumber tersebut akan diperlukan dan berapa banyak biaya yang akan dikeluarkan.
Ketiga
Anda harus memberikan perkiraan-perkiraan ini kepada user dalam bentuk PROPOSAL.
Seberapa jauh perkiraan-perkiraan tersebut dapat dipertanggung jawabkan ? Ada dua alasan dalam hal ini. Pertama, kita tidak begitu ahli dalam memperkirakan sesuatu. Kedua, perkiraan-perkiraan tersebut dibuat pada saat masih dalam tahap pendefinisian masalah, dimana pada saat itu baru sebagian kecil informasi yang kita peroleh dari masalah yang sedemikian luas.
Jika anda tidak yakin dengan kebutuhan-kebutuhan yang telah digambarkan secara akurat dalam dokumen RD, disarankan untuk membagi proyek tersebut menjadi 2 tahap : Fase Analisis sebagai proyek pertama diikuti dengan fase sebelumnya sebagai proyek kedua.
Pada saat pendefinisian, proposal anda hanya akan menjadi analisis saja, dan ini disebut PROPOSAL ANALISIS. Setelah analisis akan ada PROPOSAL PENGEMBANGAN (Lihat bab 3). Kedua hal ini disebut dengan dua fase proposal. Kejadian penting yang terdapat disini adalah pembelian proposal oleh user.
2.2. DOKUMEN KEBUTUHAN (REQUIREMENT DOCUMENT / RD)
RD menyatakan masalah-masalah yang dihadapi user dan solusi umum yang dibutuhkan. Bahasanya berorientasi pada bahasa yang digunakan oleh user sehari-hari, dan jauh dari bahasa komputer. Kadangkala dokumen RD digunakan sebagai permohonan untuk sebuah proposal (Request for a proposal (RFP)) ketika user menawarkan proyeknya kepada kontraktor luar.
Tanya jawab dengan User
Proses tanya jawab dilakukan untuk mendapatkan informasi yang tepat dari user untuk memperoleh RD yang baik. User akan memberikan semua informasi yang anda butuhkan dan tidak lebih. Tim proyek interviewer berkewajiban untuk mempelajari semua bisnis user, memahami teknologi user, dan mengajukan pertanyaan-pertanyaan.
Masalah terbesar berkaitan dengan pemakai akhir (end-user) yang sesungguhnya petugas pemasukan data atau petugas pengirim barang yang berada di gudang. Seringkali manajer atau supervisor mengatakan bahwa pemakai akhir sangat sibuk dan tidak mampu untuk memberikan informasi yang dapat dipercaya. Terkadang manajer merasa dilangkahi atau diremehkan jika anda berhubungan langsung dengan pemakai akhir yang berada di departemen mereka. Solusi dari masalah ini adalah mendidik para wakil tim proyek tersebut bagaimana pentingnya komunikasi dengan para pemakai akhir yang sebenarnya. Jika masukkan yang mereka kemukakan tidak mendapat tanggapan pada awal pendefinisian, akan sangat mungkin terjadi perubahan-perubahan di kemudian hari dan hal ini berarti akan membutuhkan biaya yang cukup mahal untuk memperbaikinya. Mintalah izin dari manajer yang berwenang pada saat akan mewawancarai orang-orang mereka.
Siapkan rencana untuk melakukan wawancara. Pelajari tentang bisnis yang mereka lakukan, dan tulislah pertanyaan-pertanyaan yang akan diajukan. Berikut ini pertanyaan yang berhubungan dengan wawancara yang akan dilakukan :
Pertama, cari tahu tentang aliran informasi yang ada dalam perusahaan tersebut. Mulailah dengan pertanyaan-pertanyaan seperti : informasi apa saja yang dibutuhkan untuk menjalankan kegiatan bisnis perusahaan ? Seberapa penting aliran data, baik antara departemen maupun antar individual ? Tentukan frekuensi, waktu dan keakuratannya.
Kedua, masukkan-masukkan yang diterima diikuti dengan pertanyaan-pertanyaan sebagai berikut : Informasi apa saja yang dibutuhkan untuk menghasilkan masing-masing barang? Informasi apa yang tersedia, kapan, dimana ? Informasi-informasi baru apa saja yang harus dikumpulkan ? Ingat tentang 5 W (Who, What, Where, When, Why). Sediakan waktu untuk pertanyaan-pertanyaan di atas selama membuat.
Hal-hal yang terdapat dalam RD
Berikut ini adalah bagian-bagian dari RD :
1. Pendahuluan. Identifikasi perusahaan (user) dan juga penjual dimana RD tersebut ditujukan. Tentukan masalah yang perlu diselesaikan, latar belakang, contoh situasi yang sedang dihadapi, motivasi-motivasi untuk menanggulanginya, dll. Bagian ini digunakan untuk memperkenalkan potensi penjual kepada perusahaan user atau departemen jika diperlukan, jelaskan kultur, lingkungungan, dan bagaimana jalannya bisnis yang dilakukan. Berikan pengertian kepada Tim Proyek tentang masalah yang dihadapi user.
2. Tujuan Proyek. Sebuah pernyataan singkat mengapa kita mengajukan proposal untuk pengembangan proyek. Batasan-batasan utama dalam penggunaan waktu dan keuangan dapat juga disebutkan.
3. Fungsi-fungsi Utama. Pernyataan singkat mengenai bagaimana sistem berfungsi berdasarkan tujuan proyek yang telah ditetapkan.
4. Keluaran Umum. Penjelasan secara singkat tentang informasi yang dibutuhkan dari sistem.
5. Informasi Input secara Umum. Input data apa yang diperlukan untuk menghasilkan output. Ini adalah waktu yang tepat untuk memastikan bahwa seluruh data yang dibutuhkan dapat tersedia pada waktu yang tepat pula.
6. Kinerja (Performance). Berapa banyak transaksi yang akan diproses, berapa banyak data yang akan disimpan, kapan laporan harus dihasilkan, dsb. Jelaskan waktu rata-rata dan waktu maksimal proses (dalam hari atau jam).
7. Perkembangan (Growth). Hal ini mungkin sulit untuk diramalkan, tetapi cobalah untuk menghitung kemajuan bisnis dan menetapkan berapa tahun lagi sistem masih dapat diharapkan untuk berfungsi. Kemukakan dalam bentuk persentase atau angka sebenarnya.
8. Pengoperasian dan Lingkungan. Dimana komputer akan ditempatkan, dimana terminal-terminal yang interaktif ditempatkan, dan siapa yang akan menggunakannya.
9. Kompatibilitas, Pengantarmukaan. Jelaskan jika fasilitas antar komputer dibutuhkan, adakah alat-alat yang harus disatukan, atau jika pengiriman akses dibutuhkan. Jika sistem hanya dapat berjalan dengan komputer yang ada, atau harus dapat diprogram dengan bahasa yang spesifik, semua dokumen dinyatakan di dalam bagian ini.
10. Reliabilitas, Ketersediaan. Tulis penggambaran waktu diantara kegagalan-kegagalan (Meantime between Failures / MTBF), waktu untuk perbaikan (Meantime to Repair / MTTR) dan persentase tambahan yang diperlukan. Semua manufaktur menyatakan penggambaran ini untuk hardware mereka.
11. Pengantarmukaan dengan Pemakai. Rincikan pengalaman-pengalaman yang dibutuhkan user dalam menggunakan komputer, jelaskan bagaimana menangani sistem kapada user yang baru.
12. Pengaruh Organisasi. Departemen-departemen apa yang akan sangat berpengaruh dan seberapa jauh cara kerja mereka harus berubah. Bagaimana sistem yang baru dapat berkomunikasi dengan sistem manual yang ada.
13. Pemeliharaan dan Dukungan. Jaminan-jaminan yang dibutuhkan : berapa lama, sampai kapan, bagaimana pengiriman.
14. Dokumentasi dan Pelatihan. Rincikan semua dokumen-dokumen umum dan / atau pelatihan yang dibutuhkan.
15. Keuntungan (hanya RFP). Jika RD adalah RFP dalam situasi yang kompetitif, mintalah data dari penjual yang menjelaskan mengapa dokumen tersebut harus dipilih. Minta data yang relevan dari penjual yang berpengalaman, komitmen, metodologi proyek, contoh-contoh proyek yang sukses, dan referensi dimana anda dapat menghubungi penjual tersebut.
16. Persyaratan dan Kondisi. Menyatakan syarat untuk seleksi, kapan dan bagaimana akan dilakukan.
2.3. TANGGUNG JAWAB USER
Meskipun user tidak menulis RD, dia bertanggung jawab untuk menyediakan pewawancara tim proyek yang dapat dipercaya, dan informasi tepat pada waktunya. User harus dapat mengajukan orang yang mengetahui tentang semua sistem yang ada dan apa saja yang dibutuhkan untuk sistem baru.
2.4. KEPUTUSAN MELAKSANAKAN / TIDAK MELAKSANAKAN PROYEK
Setelah kebutuhan-kebutuhan ditetapkan, langkah berikutnya adalah memutuskan apakah proyek bernilai untuk dikerjakan atau tidak. Untuk membantu membuat keputusan itu, suatu studi kelayakan dilakukan untuk menjawab pertanyaan : “Dapatkah sistem ini dibangun secara teknik ? Sayangnya, tidak semuanya mungkin secara teknik, sehingga pertanyaan-pertanyaan untuk dijawab diubah menjadi, “Dengan biaya berapa sistem dapat dibangun, dan apa keuntungannya ?
Dalam suatu studi kelayakan kita mempertimbangkan semua penyelesaian masalah teknis yang mungkin, dan coba untuk memperkirakan biaya dari masing-masing penyelesaian masalah. Untuk suatu proyek yang berukuran besar, kita mempertimbangkan keputusan utama mengenai hardware apa yang digunakan, dan apakah akan membuat atau membeli software. Untuk proyek berukuran kecil sampai menengah studi kelayakan yang formal tidak perlu ditulis. Biasanya cukup dengan mengangkat seseorang untuk mempelajari penyelesaian masalah yang mungkin dan menilai keuntungan-keuntungan.
Perkiraan keuntungan ini mungkin saja mudah, tetapi seharusnya tidak dipergunakan. Manajer proyek tidak hanya harus menjawab “Apakah proyek ini secara teknik dapat dikerjakan ?” tetapi juga menjawab pertanyaan yang lebih penting : “Apakah proyek ini dapat dikerjakan oleh saya sekarang ?”
Manajer proyek harus bertanya pada diri sendiri apakah proyek yang ada memiliki peluang untuk sukses, atau proyek tersebut akan mengalami kegagalan disebabkan oleh terbatasnya sumber-sumber, pengetahuan, atau risiko di luar kekuasaannya. Tidak terkira proyek-proyek telah gagal secara keseluruhan maupun sebagian, karena orang mengabaikan tanda-tanda penting dan nyata yang menunjukan kegagalan. Setiap rencana dipengaruhi oleh risiko.
2.5. MANAJEMEN RISIKO
Menurut sejarah, industri pemrosesan data telah membuat reputasi yang buruk sekali karena meremehkan proyek-proyek yang ada. Ketika ditanya tentang alasannya, para ahli pemrosesan data membela diri dengan meberikan pernyataan seperti : “Saya menilai dengan benar berdasarkan fakta-fakta yang diberikan kepada saya.
Alasan yang menumpuk adalah bahwa :
(Pilih satu atau lebih : Si pemakai mengubah pikirannya ….. tidak pernah memberitahukan saya tentang… dan departemen- departemen yang lain menjanjikan ….. dan manajemen tingkat atas mendikte penilaian ….. dengan kata lain, itu bukan kesalahan saya !)
Solusi standar industri untuk semua masalah-masalah ini adalah :
SOLUSI 1. Selidiki masalah-masalah yang ada
SOLUSI 2. Hukum yang tidak bersalah
SOLUSI 3. Promosikan yang tidak terlibat
SOLUSI 4. Kembali ke solusi 1 dan berputar sampai membosankan
2.6. EMPAT LANGKAH MANAJEMEN RISIKO
Setiap proyek akan tepat waktu dan sesuai anggaran jika tidak ada yang salah. Penting sekali untuk berkosentrasi pada hal-hal yang akan menyebabkan salah dan coba untuk menghindari kesalahan-kesalahan tersebut. Hal ini disebut Manajemen Risiko.
Manajemen risiko terdiri dari empat langkah :
Langkah 1. Antisipasi risiko
Langkah 2. Singkirkan risiko yang mungkin terjadi
Langkah 3. Kurangi dampak risiko
Langkah 4. Tetap tenang ketika terjadi kesalahan
Pengelolaan Proyek Sistem Informasi
BAB 3
PERENCANAAN PROYEK
3.1. PENDAHULUAN
Sekarang anda sudah mengevaluasi proyek dan memutuskan untuk melanjutkannya. Pertama, anda harus meyakinkan rekan-rekan lain bahwa proyek sebaiknya dilaksanakan. Hal ini dilakukan dengan membuat proposal. Untuk sebuah proyek eksternal, proposal ditulis untuk meyakinkan klien agar membeli proyek dari tim proyek anda. Untuk proyek internal, manajemen sebaiknya meminta untuk membuat sebuah proposal. Hal ini untuk mendukung tim proyek untuk membuat rencana yang sederhana.
Sebuah proposal adalah dokumen yang merinci biaya dan jadwal proyek, serta menjelaskan langkah-langkah yang akan diambil oleh tim proyek untuk menghasilkan produk yang diinginkan.
Perencanaan adalah sebuah proses yang berulang-ulang : rencana akan ditinjau secara terus menerus sesuai dengan perkembangan proyek dan sesuai dengan bertambahnya pengetahuan dan pemahaman yang lebih baik dari anggota tim. Perencanaan memang merupakan pekerjaan yang sangat sulit, tetapi harus dilaksanakan sebagaimana mestinya. Banyak proyek menjadi kacau dikarenakan tidak adanya perencanaan.
3.2. PENDAHULUAN PERENCANAAN PROYEK
(THE PRELIMINARY PROJECT PLAN / PPP)
Pendahuluan Perencanaan Proyek adalah langkah awal, sumber daya, biaya dan jadwal yang dibutuhkan untuk menyelesaikan proyek. PPP adalah dokumen internal, tidak perlu ditunjukkan ke user, terutama user luar.
3.3. RINCIAN STRUKTUR KERJA
(WORK BREAKDOWN STRUCTURES / WBS)
Kunci berbagai rencana adalah memecah kegiatan yang diperlukan ke dalam sebuah bagian yang lebih kecil lagi. Rincian struktur kerja (WBS) diawali dengan menyusun komponen-komponen utama proyek. Hal ini merupakan Level 1 dari WBS (Level 0 adalah judul proyek).
Untuk proyek software, metode terbaik untuk pemecahan proyek menjadi bagian-bagian utama adalah diawali dengan 7 fase pengembangan software.
Lihat Gambar 3.1. Rincian Struktur Kerja / WBS
Lihat Gambar 3.2. WBS untuk analisis
Sistem Penomoran WBS
Sistem penomoran dalam WBS seperti pada gambar 3.2 :
- Untuk Level 0 atau judul proyek adalah 0.0.
- Pada Level 1 masing-masing item diberi nomor N.0.
Contoh : 1.0, 2.0, dst.
- Kemudian masing-masing item pada Level 2 dibawah item N.0 pada Level 1 diberi nomor N.1, N.2, dst.
Contoh : di bawah Level 1 item Analysis yang bernomor 2.0, kita mempunyai item 2.1, 2.2, dst.
- Sedangkan untuk Level 3, kita tambahkan titik dan digit dari nomor di Level 2. Sebagai contoh, dibawah 2.1 kita harus menuliskan 2.1.1, 2.1.2, dst.
Kapan Anda Berhenti ?
Pemasukkan nomor pada level terendah menunjukkan tugas atau kegiatan dalam proyek. Anda dapat berhenti merinci sebuah kegiatan jika mengikuti langkah-langkah berikut dengan benar :
1. Beberapa orang (atau grup dari sebuah proyek besar) dapat diberikan tanggung jawab untuk melakukan tugas atau menyelesaikan kegiatan-kegiatan yang dilibatkan.
2. Anda dapat memperoleh perkiraan (berupa orang atau hari) secara garis besar sebagai upaya yang dibutuhkan untuk melaksanakan kegiatan-kegiatan yang terlibat. Hal ini dapat dilakukan dengan memberi tanggung jawab pada setiap orang.
3. Anda dapat menjadwalkan tugas.
4. Tugas-tugas tersebut harus singkat dan dapat diselesaikan.
Sebagai seorang ahli kita dapat menetapkan sebuah tugas kepada Programmer, Analis, atau bahkan Manajer Proyek. Tergantung pada pengalaman dan keahlian dalam membuat perkiraan, analis mungkin hanya memerlukan level 1 dari WBS. Beberapa analis dapat dengan mudah membaca RD untuk proyek ABC (Appendix A) secara keseluruhan. Analis lain untuk merinci membutuhkan sampai Level 2. Seperti pada gambar 3.2, analis lainnya memerlukan sampai Level 3 sebelum mereka dapat memperkirakan secara keseluruhan.
Sebagai contoh Level 3 WBS untuk kotak INTERVIEW dan ANALYZE EXISTING SYSTEMS dapat dilihat pada gambar 3.3.
Lihat Gambar 3.3. WBS Level 3
Para ahli merinci setiap kotak pada level terendah sampai ia dapat memperkirakan berapa upaya yang diperlukan. Perkiraan-perkiraan ini dapat dipakai pada WBS seperti pada gambar 3.4. Sebagai catatan bahwa perkiraan total adalah jumlah dari masing-masing waktu. Hal ini disebut DIRECT time, yaitu jumlah hari yang sesungguhnya dibutuhkan untuk melakukan kegiatan .
Lihat Gambar 3.4. Analysis Level 3
Para ahli tersebut dengan cara yang sama dapat merinci kotak yang lain (DEFINE NEW SYSTEM FUNCTIONS, WRITE FUNCTIONAL SPEC. dan NEGOTIATE FUNCTIONAL SPEC.) dan menambahkan total waktu untuk semua analisis. Kemudian ahli tersebut mengajukan perkiraan dan daftar kegiatan sebelumnya yang dibutuhkan untuk seluruh analisis bagi Manajer Proyek. Orang tersebut bertanggung jawab terhadap perencanaan (mungkin Manajer Proyek untuk proyek berukuran kecil - menengah) kemudian menggabungkan seluruh perkiraan dan daftar kegiatan terdahulu. Ia mungkin mengakhirnya dengan daftar seperti berikut ini :
ACTIFITY EFFORT PRECEDENTS
Definition 20 -----------------
Analysis 35 Definition
Design 25 Analysis
Program A (Control) 20 Design
Program B (Registration) 30 Design
Program C (Warehouse) 25 Design
System test 10 Program A, B, C
Documentation 20 Design
Acceptance 5 System Test,
Documentation
Training 10 Documentation
Operation 10 Acceptance
TOTAL 210 person-days
3.4. DIAGRAM JARINGAN (THE NETWORK DIAGRAM)
Langkah kedua dari perencaan adalah menggambarkan diagram jaringan yang menunjukkan urutan kejadian. Tipe diagram yang paling baik untuk masalah ini adalah bagan PERT. Gambar 3.5. adalah sebuah bagan PERT untuk proyek di atas. Urutan kejadian hanya didasarkan pada contoh setiap kegiatan.
Lihat Gambar 3.5. Bagan PERT
Bentuk dari bagan PERT ini disebut Precedence Network (jaringan yang diutamakan). Setiap kotak menunjukkan sebuah kegiatan. Pada setiap kotak ditulis nama kegiatan dan waktu yang diperlukan.
Jalur Kritis & Lamanya Proyek
Bagan PERT dan jalur kritis adalah jumlah jalur, atau serangkaian kegiatan yang dapat ditelusuri pada PERT sederhana di atas, dengan mengikuti petunjuk garis panah. Lamanya waktu yang dibutuhkan untuk menelusuri setiap jalur dapat dijumlahkan dengan menambahkan lamanya waktu dari jalur masing-masing kegiatan.
Jalur kritis (CP / Critical Path) adalah jalur terpanjang dan didefinisikan waktu minimal yang dibutuhkan untuk mengerjakan proyek.
PERT pada gambar 3.5. mempunyai jalur kritis yang terdiri dari kegiatan : START, DEFINITION, ANALYSIS, DESIGN, PROGRAM B, SYSTEM TEST, ACCEPTANCE, OPERATION, dan END. Proyek tersebut membutuhkan total waktu : 135 hari.
3.5. MENGHITUNG BIAYA PROYEK
(CALCULATING PROJECT COST)
Jika kontrak proyek telah mempunyai harga tetap, Manajer Proyek dapat menghitung biaya kasar untuk tenaga kerja, dengan cara mengalikan jumlah tenaga kerja per-hari dengan rata-rata biaya per-hari.
Biaya pekerja perhari disebut ‘biaya penuh’ : yang harus mencakup biaya operasi, sewa, administrasi pekerja, dan keuntungan. Untuk itu anda harus menambahkan biaya tetap, seperti computer time, sewa peralatan khusus, biaya tak terduga, dan sebaginya. Biaya tetap harus dirinci oleh setiap estimator untuk kegiatan utamanya.
Lihat Gambar 3.6. SUPERPROJECT
Rata-rata Pgr 75 pd @ $1000 per pd 75,000
Keuntungan 25% 18,750
Faktor risiko :
User berubah pikiran terhadap 10% format
Biaya = 10% tambahan waktu pemrograman 7,500
Total pemrograman $ 101,250
3.6. PENJADWALAN PROYEK (PROJECT SCHEDULE)
Langkah selanjutnya adalah menghitung jadwal proyek. Untuk melakukan hal ini, perencana (mungkin Manajer Proyek) harus mengaplikasikan jadwal yang sebenarnya dari perkiraan ke CALENDAR DAYS (jadwal harian) atau lamanya pekerjaan.
Salah satu kesulitan tugas ini adalah mengalokasikan sumber daya manusia yang akan bekerja pada kegiatan yang akan dilaksanakan, terutama ketika pekerjaan berlangsung secara serentak. Kesulitan lain adalah memutuskan bagaimana mempersingkat pekerjaan yang dilakukan dengan menggunakan sumber daya yang ada.
Kemudian Manajer Proyek menjadwalkan semua proyek pada kelender atau jadwal yang nyata. Metode terbaik untuk melakukan hal ini adalah dengan menggambarkan ke dalam sebuah Gantt Chart atau Bar Chart seperti pada gambar 3.7.
Lihat Gambar 3.7. SUPERPROJECT project schedule
3.7. Outline Pendahuluan Perencanaan Proyek
(PRELIMINARY PROJECT PLAN OUTLINE)
Dilengkapi dengan semua pengetahuan ini, Manajer Proyek dapat menuliskan dokumen penting ini. Berikut ini adalah outline yang disarankan untuk PPP.
1. Tim Proyek (The Project Team)
Menggambarkan struktur, siapa yang memberikan laporan, siapa yang menerima laporan, kepada siapa berkomunikasi, dst.
Lihat Gambar 3.8. Typical Project Team Structure
Programmer (tidak lebih dari 5 orang). Bertanggung jawab terhadap pemrograman.
Pimpinan Proyek (Project Leader)
Mengawasi programmer.
Bertanggung jawab terhadap kegiatan-kegiatan yang bersifat teknis, seperti analisis, disain dan tugas-tugas pemrograman keseluruhan.
Tujuan utama : kualitas produk yang dihasilkan secara teknik.
Manajer Proyek (Project Manager)
Manajer dalam tim (pimpinan, motivator, dll).
Bertanggung jawab terhadap semua komunikasi yang datangnya dari luar (laporan, pertemuan-pertemuan, penghubung antara manajemen tingkat atas dengan user).
Tujuan utama : keberhasilan proyek (perencanaan, pengontrolan, komunikasi).
2. Biaya Proyek (Projects Cost)
Termasuk WBS, membuat perkiraan dan perhitungan yang digunakan untuk menaksir biaya dalam pembuatan produk.
3. Penjadwal Proyek (Project Schedule)
Merupakan bagian terpenting dalam proyek, dan dapat menggunakan metode Gantt.
4. Pemeriksaan Ulang (Reviews)
Pada bagian ini anda dapat menghubungkan antara pertemuan dari manajemen utama dengan peninjau teknik (jadwal proyek akan memberikan informasi ini), tujuan dari masing-masing peninjau, dan siapa yang akan mengerjakannya. Buatlah daftar tanggung jawab dari orang-orang yang terlibat.
5. Laporan (Reports)
Bentuk dan isi dari laporan keadaan, laporan milestone dan dokumen proyek lain dapat dirinci di dalam laporan tersebut.
6. Dokumentasi (Documentation)
Ada 2 jenis dokumen di dalam proyek, yaitu user dan manajemen proyek.
7. Asumsi (Assumptions)
Disini anda dapat menentapkan harga berdasarkan asumsi : dimana sebagian besar adalah fakta yang diberikan oleh user.
3.8. KESIMPULAN UNTUK PERENCANAAN
Perencanaan itu seperti menunggang kuda : kelihatannya sulit sebelum anda mencobanya. Tetapi begitu anda mencobanya, maka segalanya akan menjadi mudah.
Kamis, 04 Maret 2010
cinta kandas beda usia
sayang engaku masih di TK
sedang aq S2
sudut pandang kita berbeda
usia kita jelas tak sama
oh mama..
oh papa...
ini nasib anakmu
yang sudah di S2
ingin rasanya
aq kembali
kemasa-masa di TK
kelak engaku tambah usia
sedang aku semakin tua
mungkinkah kau akan terima
sedang aku si tua bangka
cinta kandas beda usia
mengapa kita berjumpa
selamat tinggal kekasihku
tak mungkin ku menunggumu
_PANDAL_
sayang engaku masih di TK
sedang aq S2
sudut pandang kita berbeda
usia kita jelas tak sama
oh mama..
oh papa...
ini nasib anakmu
yang sudah di S2
ingin rasanya
aq kembali
kemasa-masa di TK
kelak engaku tambah usia
sedang aku semakin tua
mungkinkah kau akan terima
sedang aku si tua bangka
cinta kandas beda usia
mengapa kita berjumpa
selamat tinggal kekasihku
tak mungkin ku menunggumu
_PANDAL_
Langganan:
Postingan (Atom)