METODOLOGI MANAJEMEN PROYEK

1. METODOLOGI MANAJEMEN PROYEK Fase Inisialisasi / Project initiation Oleh : Weda Adistianaya Dewa s.kom.,mmsi

2. Referensi • “MANAJEMEN PROYEK SISTEM INFORMASI” OLEH RUDY TANTRA, PENERBIT ANDI YOGYAKARTA • “MANAJEMEN PROYEK BERBASIS TI” OLEH IMAM HERIANTO DAN TOTOK TRIWIBOWA, PENERBIT INFORMATIKA BANDUNG

3. Fase Inisialisasi • Feasibility Study • Requirements Analysis • Project Scope Document • Penyusunan Tim • Manajemen risiko • Proposal • Kontrak / Surat Perintah Kerja • Project Charter • Project kick offf

4. Fase Inisialisasi • Fase Pertama di mana Anda berinteraksi langsung dengan proyek yang Anda tangani. • Keberhasilan tahap selanjutnya ditentukan oleh keberhasilan Anda dalam menangani fase ini.

5. Feasibility Study • Studi kelayakan (feasibility study) adalah tindakan yang dilakukan untuk menentukan apakah suatu proyek layak untuk direalisasikan atau tidak. • Proyek tidak layak jika hanya menghasilkan produk atau jasa yang hanya berfungsi satu kali saja, atau jika proyek yang dilaksanakan itu tidak memberi manfaat apapun selain hanya menambah panjang birokrasi. • Tahap ini sangat penting karena merupakan tahap yang menentukan suatu proyek jadi dilaksanakan atau tidak.

6. Aktivitas dalam Studi Kelayakan • 1. Wawancara. • 2. Kunjungan ke Lokasi. • 3. Pengumpulan Dokumen.

7. 1. Wawancara • Wawancara ditujukan pada pemilik pemilik proyek dan sponsor, apa tujuan yang diharapkan dengan pembangunan sistem ini dan berapa lama waktu yang mereka berikan hingga sistem ini dapat diselesaikan dan digunakan sebagaimana harapan mereka.

8. 2. Kunjungan ke Lokasi • Misalnya proyek yang akan dibangun adalah sebuah sistem retail. • Tim Anda bisa mengamati dan mencatat mulai dari penerimaan barang, kontrol persediaan, penjualan sampai dengan pengelolaan keuangan. • Dengan mengunjungi lokasi maka proyek dapat dirancang untuk memberikan hasil yang tepat guna dan sesuai dengan kondisi lapangan.

9. 3. Pengumpulan Dokumen • Dokumen-dokumen yang digunakan dalam sistem yang sudah berjalan, baik manual maupun terkomputerisasi, harus dikumpulkan. • Pengumpulan dokumen bisa dilakukan sambil melakukan wawancara.

10. Dokumen-dokumen dalam sistem • Formulir Input (Input Forms) • Formulir Output (Output Forms) • Laporan-laporan

11. Formulir Input • Formulir-formulir yang digunakan untuk mencatat data-data yang diperlukan dalam melakukan suatu unit proses. • Contoh : mencatat data pemasok.

12. Formulir Output • Formulir-formulir yang merupakan hasil suatu proses yang kemudian akan diteruskan untuk digunakan bagian lain/ atau pihak di luar organisasi perusahaan. • Contoh : purchase order, invoice, delivery order, dsb.

13. Laporan-laporan • Ada laporan yang menampilkan data detail untuk pemeriksaan, ada yang berupa rekapitulasi untuk keperluan manajemen, ada pula yang bersifat analisis untuk keperluan pengambilan keputusan. • Umumnya jika suatu organisasi telah memiliki alur kerja dan proses bisnis yang berjalan, terlepas dari baik buruknya, benar tidaknya maupun tingkat efisiennya, maka proyek itu layak diteruskan.

14. Laporan studi kelayakan berisi : • 1. Tujuan Studi Kelayakan. • 2. Latar Belakang. • 3. Solusi yang Diajukan. • 4. Analis Biaya-Manfaat.

15. Requirements Analisys • Requirements sangat penting karena merupakan dasar dari perencanaan proyek untuk menentukan apa saja yang perlu dipersiapkan agar proyek dapat terlaksana dengan baik. • Yang dimaksud proses requirements adalah 1. Penyusunan requirements (mengumpulkan, menganalisis, spesifikasi dan validasi). 2. Manajemen requirements (melaksanakan requirements sesudah disepakati)

16. Definisi Requirements • Requirements adalah pernyataan mengenai : • Fungsionalitas sistem (kapabilitas). • Dapat divalidasi. • Harus sesuai dengan sistem yang berjalan. • Solusi untuk masalah klien. • Memenuhi kriteria dengan kondisi yang terukur dan dibatasi oleh constraints.

17. Definisi Requirements • Requirements adalah kebutuhan proyek yang didokumentasikan, dan dikumpulkan untuk mengidentifikasikan constrains yang spesifik dari setiap komponen proyek dan berfungsi sebagai dasar untuk setiap aktivitas yang berlangsung dalam proyek.

18. Jenis-jenis Requirements • Ada beberapa jenis requirements, tergantung sumber datanya, yaitu : • Business Requirements. • Stakeholder Requirements. • End-User Requirements. • System Requirements. • Sotfware Requirements.

19. 1. Business requirements • Terdiri atas bisnis proses dari sistem yang akan dibangun, batasan-batasan seperti biaya, sumberdaya, waktu dan sebagainya.

20. 2. Stakeholder requirements • Terdiri atas susunan kebutuhan terhadap sistem yang akan dibangun, baik untuk kepentingan internal maupun eksternal perusahaan atau organisasi.

21. 3. End-User Requirements • Adalah kebutuhan dari staf yang berinteraksi secara langsung maupun tidak langsung terhadap sistem yang akan dibangun.

22. 4. System Requirements • Merupakan tingkatan tertinggi dari keseluruhan sistem, yang dapat terdiri dari beberapa subsistem seperti subsistem hardware, subsistem software, subsistem network, dan sebagainya.

23. 5. Software Requirements • Requirements yang menjelaskan mengenai kebutuhan user akanfungsionalitas software secara detail dan spesifik. • Untuk tahap desain dan pengembangan, dokumen software requirements ini yang akan menjadi landasan penting dalam memahami seluruh requirements dan implementasinya dalam sistem yang akan dibangun.

24. Menyusun System Requirements Spesifications (SRS) • Penyusunan SRS dilakukan berdasarkan informasi yang telah didapatkan dari studi kelayakan yang dilakukan sebelumnya, dengan tambahan informasi yang bisa didapatkan dari analisis lanjutan dari materi yang didapat.

25. Menurut standar IEEE, SRS harus menjelaskan • Interface • Kapabilitas fungsional • Tingkat kinerja • Struktur Data • Keamanan • Reliability • Proteksi privasi • Kualitas • Batasan-batasan

26. Perubahan dan Manajemen Requirements • Kadang kala bisa terjadi requirements yang berubah karena proses bisnis klien memang selalu menyesuaikan dengan keadaan. • Pengembangan sistem informasi dilakukan sesudah proses bisnis ditetapkan.

27. Requirements sebagai kegagalan proyek • Dari berbagai studi ditemukan bahwa 70% dari proyek yang gagal adalah karena requirements yang tidak lengkap dan akurat. • Hal-hal yang menyebabkan kesalahan dalam menyusun requirements adalah : • Klien tidak mengerti apa yang sebenarnya mereka inginkan. • Requiremets berubah saat proyek berlangsung.

28. Project Scope Document • PSD sangat penting sebelum menyusun proposal untuk diajukan, karena di dalamnya dinyatakan ruang lingkup proyek, yaitu mengenai seberapa luas jangkauan pelaksanaan proyek dan sampai di mana batas-batasnya. • PSD adalah pedoman utama untuk mengawali proyek, sebelum proyek itu benar-benar dimulai.

29. PSD terdiri atas susunan : • Maksud dan Tujuan Proyek. • Rencana Kerja. • Deliverables. • Batasan-batasan. • Kesimpulan.

30. Penyusunan Tim • Tim dalam proyek memiliki karakteristik yang berbeda, al : • Tim proyek dibentuk untuk waktu yang terbatas, yaitu sepanjang proyek berlangsung. • Proses kerja belum ditentukan secara definitif sebelum proyek berlangsung. • Tim akan menemukan banyak hal yang belum diprediksi pada proyek berlangsung, sehingga banyak hal masih belum pasti. • Tekanan kerja atau tingkat stress lebih tinggi, yang disebabkan banyak hal yang belum pasti. • Dalam beberapa hal, anggota tim juga bekerja rangkap dengan tugas sehari-hari

31. Penyusunan Tim (lanj) • Dalam membangun tim proyek, saat memilih masing-masing anggota tim, manajer proyek harus tetap obyektif dan tidak berdasarkan rasa simpati atau emosional, karena yang terpenting adalah kontribusi yang diharapkan dari setiap anggota untuk mencapai tujuan proyek. • Dalam sebuah tim proyek yang terpenteing adalah komunikasi dan keterbukaan.

32. Manajemen Risiko • Suatu proyek pasti memiliki risiko, utamanya adalah kegagalan proyek, baik dalam mencapai tujuan maupun memenuhi kriteria batasan proyek.

33. 10 Golden Rule menurut Bart Jutte Manajemen Risiko : • Jadikan manajemen risiko bagian dari proyek. • Identifikasikan risiko sejak awal proyek. • Komunikasikan risiko-risiko yang ada. • Pertimbangkan baik ancaman (threats) maupun kesempatan (opportunities). • Klarifikasi penanggung jawab untuk setiap risiko. • Buat prioritas risiko. • Melakukan analisa risiko. • Buat rencana dan implementasi tanggapan terhadap risiko. • Dokumentasikan risiko proyek. • Tentukan risiko dan tindakan yang diambil.

34. Proposal • Proposal adalah penawaran, yakni menawarkan jasa Anda atau perusahaan Anda untuk melaksanakan proyek. • Ada beberapa jenis proposal, yakni yang berdasarkan permintaan resmi, permintaan tidak resmi ataau tanpa adanya permintaan dari pihak klien.

35. Proposal berdasarkan permintaan resmi • Klien biasanya membuka peluang kepada beberapa penyedia atau vendor, dengan mengeluarkan Invitation For Bid (IFB). • Umumnya hal ini dilakukan oleh perusahaan besar atau pemerintah. • IFB biasanya diumumkan melalui media atau melalui situs perusahaan/instansi yang ditujukan pada rekanan resmi.

36. Proposal berdasarkan permintaan tidak resmi • Umumnya dilakukan oleh perusahaan-perusahaan menengah atau juga jika nilai proyek kecil sehingga tidak memerlukan aktivitas formal. • Klien biasanya tidak lagi mencari vendor alternatif,atau kalaupun ada hanya sebagai referensi saja. • Klien juga memberikan gambaran mengenai requirements, tetapi tidak secara resmi, biasanya berdasarkan informasi yang didapatkan dari rapat-rapat pendahuluan dengan pihak-pihak yang berkepentingan, seperti feasibility study.

37. Proposal lainnya • Proposal lainnya adalah tanpa permintaan dari klien. • Biasanya ini dilakukan berdasarkan informasi yang didapatkan tentang peluang untuk mengajukan proposal suatu proyek yang mungkin diperlukan klien. • Apapun jenisnya, proposal yang baik adalah proposal yang membawa kepada kontrak sehingga proyek bisa dilaksanakan untuk memberikan hasil sesuai yang diharapkan oleh klien.

38. Struktur Proposal • Ringkasan eksekutif. • Tinjauan dan rincian requirements. • Solusi yang diajukan. • Uraian pekerjaan. • Rencana implementasi. • Investasi/biaya.

39. Presentasi dan Revisi • Setelah proposal diterima klien, tibalah saatnya untuk mempresentasikan proposal. • Agenda presentasi adalah menyampaikan requirements dan solusi yang diajukan sebagaimana yang dijelaskan dalam proposal.

40. Kontrak/Surat Perintah Kerja (SPK) • Kontrak perlu dibuat apabila pelaksana proyek adalah pihak di luar organisasi perusahaan. • Jika pelaksana proyek adalah tim yang dibentuk dari staf internal perusahaan, manajer proyek akan menerima Surat Perintah Kerja yang menegaskan tentang pelaksaan proyek.

41. Kontrak harus berisi beberapa hal : • Deskripsi pihak-pihak yang berkepentingan terhadap proyek . • Deskripsi mengenai deriverable. • Hak dan kewajiban masing-masing pihak yang mengikat selama proyek berlangsung. • Kesepakatan investasi atau biaya yang harus dibayarkan kepada pihak pelaksana proyek. • Jadwal pelaksanaan yang mengacu pada kewajiban pihak pelaksana proyek. • Bagian penutup yang berisi nama-nama penanggung jawab untuk masing-masing pihak

42. Project Charter • Setelah proyek ditandatangi akan dilanjutkan dengan penyusunan definisi proyek secara resmi yang akan menjadi pedoman bagi pelaksanaan proyek. • Definisi ini bertujuan untuk mendokumentasikan visi, tujuan, lingkup, deliverables, organisasi proyek dan rencana implementasi proyek.

43. Langkah-langkah membuat Project Charter • Visi, tujuan, lingkup dan deliverables proyek. • Organisasi proyek. • Implementasi proyek. • Risiko dan masalah.

44. Project kick-off • Setelah inisiasi proyek selesai, tim sudah terbentuk dan kontrak sudah ditandatangi, sekarang saatnya untuk memulai pelaksanaan proyek. • Mulailah proyek dengan melakukan kick-off meeting yaitu pertemuan untuk memberikan informasi tentang pelaksanaan proyek. • Kick-off meeting merupakan kesempatan baik untuk saling mengenal, memberikan motivasi kepada tim, menciptakan lingkungan kerjatim proyek yang akrab dan efektif, serta untuk memberikan atmosfer kepemimpinan sebagai manajer proyek.

45. Contoh dokumen • Project definition

46. TERIMA KASIH