Pengelolaan Proyek Sistem Informasi
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 Reques For a Proposal (RFP). Format proposal harus
mengikuti RFP dan RD.
t
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.” Pengelolaan Proyek Sistem Informasi
BAB 4 Halaman 2 dari 6
♦ 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 Requiremen
Documents.
t
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 : Pengelolaan Proyek Sistem Informasi
BAB 4 Halaman 3 dari 6
• 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
Pengelolaan Proyek Sistem Informasi
BAB 4 Halaman 4 dari 6
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 Pengelolaan Proyek Sistem Informasi
BAB 4 Halaman 5 dari 6
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 Pengelolaan Proyek Sistem Informasi
BAB 4 Halaman 6 dari 6
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.
Tidak ada komentar:
Posting Komentar