PROPOSAL DAN NEGOSIASI MANAJEMEN PROYEK SISTEM INFORMASI SESI AKHIR

Proposal Sebuah proposal mempunyai 3 kegunaan, yaitu : Berisi perkiraan tim proyek, mulai dari biaya proyek sampai dengan tanggal pengiriman proyek. Untuk proyek eksternal, dokumen hukum formal menunjukkan outline tim proyek untuk memberikan pelayanan yang diperlukan. Sebagai alat penjualan. Proposal yang berisi usulan proyek akan dijual untuk mendapatkan keuntungan.

Proposal Proposal Administrasi: Profil Perusahaan (struktur organisasi, manajemen, “kondisi keuangan”), pengalaman (proyek2 yang telah dikerjakan). Proposal Teknis Proposal Biaya

Kesalahan utama pada proposal dapat disebabkan 2 hal : Tidak menawar, yang mana seharusnya bisa ditawar. Ada tawaran, tetapi hilang dalam kompetisi.

DUA FASE PROPOSAL PROYEK SOFTWARE Ada 2 fase proses proposal, yaitu : Fase analisis sebagian kecil proyek, usulan untuk dikerjakan dalam Proposal Analisis (Analysis Porposal). Setelah analisis dikerjakan, sisanya dibangun dalam Proposal Pengembangan (Development Proposal).

Garis besar Proposal (Proposal Outline) : 1. Cakupan Surat (Cover Letter) Sebuah surat yang ditujukan kepada pengambil keputusan, ditandatangani oleh Manajer Proyek 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.

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 untuk membangun proyek. Jika proposal analisis, rincilah alasan-alasan untuk penggunaan metode 2 langkah. Jelaskan fase analisis yang dihasilkan, 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 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. Gambaran 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.

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.

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

Pedoman Umum Penyusunan Proposal Teknis: Penampilan menarik (perhatikan: cover, struktur isi buku, font, gambar berwarna). Jelas (disertai dg visualisasi – gambar, tabel, grafik). Isi meyakinkan: konsisten, “menjawab” semua butir-butir TOR dg baik. Keahlian tim pelaksana proyek dipresentasikan dengan meyakinkan (perhatikan: pendidikan, pengalaman).

Isi Proposal Teknis (yg utama): Bab 1: Pendahuluan (biasanya isi TOR). Bab 2: Tanggapan thd TOR Bab 3: Bahasan sistem (PL) yg diusulkan (dpt > 1 bab, jika perlu). Bab 4: Metodologi Pelaksanaan Pekerjaan. Bab 5: Kesimpulan. Lampiran: CV para tenaga ahli.

KESIMPULAN Penulisan proposal dan mempresentasikannya merupakan sebuah seni. Sangat beruntung jika 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.

NEGOSIASI DAN KONTRAK Negosiasi 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: 1. Harga 2. Lamanya proyek 3. 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.

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) 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 penulis 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 : Anda yakin bahwa tidak akan terjadi pergantian utama. Anda akan bekerja dengan software dan produk hardware yang anda ketahui. 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 : Anda merasa bahwa pergantian utama akan terjadi (RD tidak ada atau kebutuhan lain tidak jelas). Anda bekerja dengan tidak mengetahui sistem operasi, paket software atau hardware, atau anda mempunyai peralatan pengembangan khusus untuk menulis, seperti simulator, tes dasar, dsb. Komunikasi yang kurang baik antara anda dan user. 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 diinginkan untuk bekerja dengan klien. Ini akan memberikan 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.

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

KESIMPULAN Dokumen Kebutuhan (RD) yang lengkap dan telah disetujui oleh kedua belah pihak yaitu Tim proyek dan user. Dokumen proposal dapat digunakan untuk analisis atau seluruh pengembangan, yang dilengkapi dan dibeli oleh user. Tulis persetujuan yang diinginkan. Walaupun tidak mempertimbangkan kejadian penting, izin dari PPP itu dengan menyediakan sumber daya yang diperlukan.

Skenario Perolehan Proyek PL: “Penunjukan Langsung” oleh Client (pemberi kerja). Melalui Tender.

Penunjukan Langsung (di Indonesia), bisa dengan Cara: Konsultan (tim pengembang) melakukan survei di perusahaan Client (wawancara, mengumpulkan dokumen, observasi sistem dan prosedur kerja). Konsultan menyusun proposal (bisa dengan berkonsultasi dengan Client). Negosiasi antara Konsultan dan Client. Penanda-tanganan dokumen kontrak oleh Konsultan dan Client.

Proposal pada Penunjukan Langsung: Singkat tapi jelas (minimal). Kisi-kisi materi disusun atas kesepakatan Client – Konsultan. Bisa hanya terdiri dari satu dokumen, isi utama: spesifikasi teknis sistem / PL yang akan dibangun, rencana kerja, anggaran yang diusulkan (atau hanya nilai total proyek yang diminta).

Mekanisme Melalui Tender Proyek: Client menyusun TOR TOR (Term Of Reference)/ (Kerangka Kerja). Pengumuman lelang / tender proyek melalui media publikasi atau pengiriman undangan tender kpd Konsultan2 yang dipilih. Pendaftaran peserta tender (= Konsultan). Pemasukan proposal tender oleh peserta. Penilaian dan seleksi proposal pemenang. Pengumuman pemenang. Penanda-tanganan dok kontrak dan penerbitan SPK (Surat Perintah Kerja) oleh Client.

Setelah membaca TOR/KAK: To BID or NOT bid (ikut tender / tidak)? Dilema Konsultan: Setelah membaca TOR/KAK: To BID or NOT bid (ikut tender / tidak)?

Isu Utama to BID or NOT bid: Biaya yang dikeluarkan untuk penyusunan proposal (untuk gaji tim penyusun, survei awal, peralatan): 10% dari nilai proyek. Waktu penyusunan proposal: dapat dipenuhi? Mampu melaksanakan TOR atau tidak? (Pertimbangan: keahlian personil yang ada, peralatan yang dimiliki Konsultan, waktu yang ditetapkan pada TOR.)

Tugas Kelompok: Susunlah Proposal yang meliputi perusahaan (admnistrasi) , Teknik (CPM/PERT) dan Biaya untuk TOR Dikumpulkan 2 minggu lagi. Judul Proposal jangan sama termasuk teknik penjadwalan dan biaya

Isi Proposal (tugas MPSI) Cover Table of Content Cover letter (ditujukan ke klien) Executive Summary (tentang perusahaan anda) Pendahuluan Statement of Need: pemahaman konsultan ttng permasalahan yang di-ceritakan di TOR Tanggapan (proposed solution) Bahasan sistem…(detil) Metodologi Pelaksanaan (Implementasi+Project Management) Tahapan pengerjaan Scheduling WBS Biaya Estimasi biaya proyek (personil: mandays) Kesimpulan CV semua anggota dengan posisi: PM, …(Programmer, Analyst&Desainer, Network Engineer, QA, dst…)