Mengelola Sebuah Project IT

 

            Terkadang seorang Project Manager dalam sebuah project IT merasa “kepala mau pecah” karena mikirin permasalahan project. Banyak hal yang membikin Sang PM mengalami hal tersebut, misalnya saja waktu molor dari jadwal yang ditentukan, banyaknya permintaan client, sedikitnya waktu pengerjaan project menuju deadline, dan pembayaran uang project yang molor atau bahkan tidak terbayarkan. Bagaimana menyikapinya? Mari kita renungi bersama. J

            Menurut pengalaman dan research beberapa praktisi IT, ada 5 hal yang harus dipikirkan oleh seorang Project Manager antara lain adalah cakupan project (Scope Project), rentang waktu (Timeline), sumber daya (SDM), biaya operasional, dan yang paling akhir yang notabene adalah tujuan akhir dari sebuah project IT adalah kualitas produk yang dihasilkan. Kelimanya merupakan hal-hal yang wajib dipikirkan oleh seorang Project Manager sebelum melangkah pada tahap pengerjaan project. Dengan menanamkan kelima hal tersebut sebelum melangkah diharapkan kita dapat mengawali sebuah project IT dengan sesuatu hal yang professional dan baik. Semua hal yang diharapkan akan mengahasilkan sebuah hasil yang profesional harus diawali dengan usaha yg profesional juga.

 

1. Scope Project

Scope menurut katanya memiliki arti cakupan, di dalam sebuah project cakupan merupakan batasan pekerjaan. Seorang Project Manager diharapkan memahami tugas apa yang harus dikerjakan pertama kali dan tugas apa yang harus dikerjakan terakhir, atau sebagai penanda bahwa sebuah rentangan proses pengerjaan project itu selesai. Dalam project IT scope project juga merupakan scope system yang akan dibuat dalam project tersebut. Apabila project tersebut membuat sebuah system aplikasi maka kita harus tau apa saja fitur-fitur yang harus kita kerjakan untuk dapat mencapai sebuah kata ‘Selesai’.

2. Timeline

Project Timeline atau bahasa ngetren-nya rentang waktu pengerjaan project. Seorang Project Manager harus mengetahui kapan project tersebut harus selesai. Hal ini biasanya berhubungan dengan kebutuhan client.

3. SDM

Setelah melihat poin pertama dan kedua yaitu scope dan timeline, maka yang harus dilirik oleh seorang Project Manager adalah SDM. Mengapa SDM? Yaiyalah… Kalau bukan SDM apalagi? Masak seorang Project Manager harus bekerja sendiri dalam penyelesaian project, itu sangat tidak mungkin. PM harus menimbang scope, timeline dan SDM, bisakah SDM yang dimiliki menyelesaikan semua tugas (hasil ekstraksi scope system) pada waktu yang disediakan (timeline)? Karena pemikiran ini akan mempengaruhi sebuah kebijakan apa yang akan diambil agar project terus berjalan.

4. Biaya Operasional

Yang tidak kalah pentingnya adalah biaya, biasanya penentuan biaya adalah paling akhir setelah hitung-hitungan SDM, timeline dan tugas selesai dilakukan. Karena untuk menghargai sebuah project biasanya diawali dengan perhitungan biaya operasional.

5. Kualitas Produk

Kualitas produk yang baik adalah cita-cita terakhir apabila keempat aspek diatas sudah dijalani.

 

            Pada kondisi yang sangat ideal sebuah project yang baik adalah project yang pelaksanaan tugas-tugas nya secara merata tersebar pada jalur waktu yang telah ditentukan, dan dilaksanakan oleh sekumpulan SDM yang mencukupi, serta pembiayaan project yang tepat waktu. Sehingga project dapat selesai tepat waktu dengan disertai kualitas hasil yang memuaskan. Namun beberapa hal tidak seperti yang dipikirkan. Hal-hal yang sering terjadi yang membuat seorang Project Manager merasa “kepala mau pecah” adalah sebagai berikut :

1. Scope system yang terus berkembang

Menurut pengalaman yang paling sering terjadi adalah permintaan akan perubahan scope system yang tidak ada henti-hentinya. Artinya seorang Project Manager dihadapkan dengan situasi yang tidak ada ujung pangkalnya. Apa yang harus dipikirkan apabila seorang PM mendapati hal yang seperti ini? Orientasi seorang Project Manager adalah menyelesaikan semua tugas dengan kualitas yang memuaskan. Yang harus diusakan adalah mengadakan komunikasi langsung dengan client mengenai scope system. PM dapat meminta kepada client tentang pengurangan scope system dengan menitik beratkan pemikiran pada kualitas system yang dibangun. Karena hal ini dapat berpengaruh pada aspek yang lain.

2. Waktu pengerjaan yang terlalu pendek

Waktu pengerjaan project yang terlalu pendek dengan tugas-tugas yang sangat banyak. Sebuah project haruslah ditata dengan realistis, agar dapat menghasilkan sesuatu yang realistis juga. Apabila sebuah project mendapat alokasi waktu yang mustahil untuk sebuah project bisa dikerjakan maka seorang PM haruslah dapat berkomunikasi dengan pihak client tentang hal itu. Disini seorang PM harus dapat menjelaskan kepada client waktu pengerjaan tugas-tugas yang masuk akal. Dengan disertai alasan-alasan teknis dengan harapan client akan dapat menerima keadaan tersebut.

Apabila seorang PM tidak mau mengusahakan hal tersebut maka aspek lain yang dikorbankan adalah SDM dan kualitas produk itu sendiri. Seorang PM tidak mungkin memaksakan SDM nya untuk bekerja keras melebihi batas standar waktu kerja pegawai, hanya untuk mengejar selesainya sebuah project. Sangatlah tidak manusiawi kalau sampai hal itu terjadi. Sebuah perusahaan haruslah memikirkan kesejahteraan pegawainya jangan mentang-mentang yang punya uang dan yang bisa menggaji pegawai lalu bisa semena-mena kepada pegawai. Pegawai juga manusia Bung, yang punya urusan lain selai pekerjaan. Kalau mau seorang PM juga dapat menambahkan pegawai untuk mempercepat kinerja, sehinggan beban pegawai bisa dikurangi.

3. Pembiayaan project macet

Pembiayaan macet ada juga yang tidak terbayarkan. Ini juga bikin pusing seorang PM. Apa yang bisa dilakukan untuk menangani itu? Lagi-lagi PM harus melakukan komunikasi dengan pihak client. Karena tidak dapat dipungkiri sebuah project pasti memerlukan dana untuk operasional, apabila tidak maka project pastilah tidak dapat berjalan. Ada beberapa perusahaan yang tidak menghiraukan tentang hal itu artinya project tetap dijalankan walaupun dana tidak kunjung datang. Biasanya perusahaan yang seperti ini mengutamakan image perusahaan di mata client nya, dengan cara mengerjakan apapun yang diminta client walaupun tidak dibayar. Namun sampai kapan hal itu akan berlanjut? Apakah sebuah perusahaan hanya bisa makan image perusahaan saja? Disini dibutuhkan ketegasan dalam bertindak, apakah mau dilanjutkan atau menyerahkan hasil kerja sampai dititik terakhir pengerjaan dengan menerima segala resiko yang akan didapat dari client.

 

Inti dari permasalahan diatas adalah komunikasi antara pihak konsultan IT dengan client harus dijalin dengan baik, dengan harapan bahwa hubungan kerja akan lancar. Sebuah survey (The Bulls Survey tahun 1998) menyatakan bahwa 3 (tiga) faktor penyebab terbesar kegagalan proyek adalah buruknya komunikasi antara pihak-pihak terkait, baik pengembang maupun pemilik proyek (57%), Kurang baiknya perencanaan proyek (39%) serta buruknya pengendalian kualitas pekerjaan (35%). Dari ketiganya apabila kita mau menelaah lebih dalam pada poin kedua dan ketiga yaitu masalah perencanaan proyek dan kualitas pekerja kesemuanya itu terdapat pada 4 poin pertama yang harus dipikirkan oleh seorang PM yang kita bicarakan di awal pembahasan. Berikut adalah grafik hasil survey yang dilakukan pada tahun 1998 (The Bulls Survey).

 

The Bulls Survey (1998)

 

Beberapa Pendekatan Pengerjaan Perangkat Lunak Menurut RPL :

1. Model air terjun (waterfall) à Mengambil kegiatan dasar seperti spesifikasi, pengembangan, validasi, dan evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak, implementasi, pengujian dan seterusnya.
2. Pengembangan evolusioner à Pendekatan ini berhimpitan dengan kegiatan spesifikasi, pengembangan, dan validasi. Sistem awal dikembangkan dengan cepat dari spesifikasi abstrak. Sistem ini kemudian di perbaiki dengan masukan dari pelanggan untuk menghasilkan sistem yang memuaskan kebutuhan pelanggan.
3. Pengembangan Sistem Formal à Pendekatan ini menghasilkan suatu sistem matematis yang formal dan mentransformasikan spesifikasi ini, dengan menggunakan metode matematik menjadi sebuah program.
4. Pengembangan berdasarkan pemakaian ulang (Reusable) à Teknik ini menganggap bahwa bagian-bagian sistem sudah ada. Proses pengembangan sistem terfokus pada pengintegrasian bagian-bagian sistem dan bukan pengembangannya dari awal.

 

Ah Teori !!???!!?!?!?

            Beberapa orang menyatakan “Ah teori…”, menurut mereka semua itu teori belaka. Di jaman sekarang ini, semua itu gak penting dalam pengerjaan project IT, menurut mereka semua yang kita dapat di perkuliahan tidak bisa diterapkan dalam pengerjaan project IT. Itu semua teori dan prakteknya tidak seperti itu… Apakah memang benar seperti itu? Kalau memang benar teori yang kita dapat di perkuliahan gak ada gunanya (tidak bisa diimplementasikan di dunia kerja), ngapain sekolah / kuliah? Teori adalah sebuah kesimpulan dari sebuah research yang dijadikan rumusan, dengan memperhatikan pola-pola yang didapat. Intinya teori keluar oleh karena hasil research yang telah dilakukan, jadi percaya aja kalau teori itu diajarkan pasti ada maksudnya. Dari pada kita bikin teori sendiri dalam implementasi dan walhasil malah gak karu-karuan project nya. Jadi apa salahnya mari kita heningkan, kita pikirkan sejenak apa pentingnya teori sejenak……….  J