Tidak ada yang salah, tetapi bagaimana mitigasinya

Setelah sekian lama ngga nulis, kepikiran di sela2 kirim report dan evaluasi progress untuk nulis2.
Sekedar sharing…

Akhir-akhir ini, melihat kondisi Situ Gintung pasca rubuhnya tanggul yang mengelilingi situ tersebut, ramai2 orang teriak siapa yang salah…

Dalam suatu kerangka project management, disebutkan adanya Risk Management di mana suatu resiko itu tidak dapat dihilangkan sama sekali, tetapi bagaimana kita mitigasi resiko tersebut.
Tidak ada yang salah…tetapi justru perencanaan yang tidak optimal-lah penyebab itu semua. Pemerintah tentunya memiliki anggaran yang terbatas dan perlu memberikan skala prioritas apa saja yang akan didahulukan. Warga…sudah tentu tidak tau mau lapor ke mana setelah melihat adanya gejala-gejala tanggul akan longsor.

Semua tidak salah…dan juga tidak ada yg benar…
Coba sekarang kita perlakukan segala tugas dan pekerjaan dalam kerangka Project Management. Mulai Initiation, Planning, Executing, Monitoring & Control, Closing.

Sekali lagi…mitigasi resiko itu penting…segera assessment resiko yang kemungkinan muncul serta dampak yang ditimbulkan.

Korban tentunya butuh solusi, bukan butuh panggung sandiwara dengan judul “Siapa yang Salah”

Project Management Office (PMO)

Pernahkah Mendengar Project Management Office (PMO)? Kira-kira apakah PMO itu?

Mengutip dari buku PMP Exam Prep oleh Rita Mulcahy PMP, PMO adalah a department that centralizes the management of projects. Jadi, intinya adalah jika perusahaan ingin meng-organize proyek dengan baik, maka bentuklah apa yang dinamakan PMO. Beberapa pengalaman akan saya jelaskan pada tulisan ini.

Pada suatu pertemuan pada akhir Februari 2008 di sebuah hotel berbintang lima di kawasan Kuningan, saya sempat bertemu dengan PMO sebuah bank swasta. Pada pembicaraan tersebut, PMO itu mengeluh bahwa saat ini PMO dijadikan sebagai “dewa project” di organisasi. Jika ada sebuah rencana pada suatu organisasi, maka rencana itu diserahkan “sepenuhnya” ke organisasi PMO. Baik dari inisiasi sampai dengan closing dijadikan urusan PMO. Nah, sebenarnya “wujud” PMO itu seperti apa, ya?

Rita Mulcahy dalam buku yang sama menjelaskan bahwa Fungsi PMO adalah sebagai berikut:
1. Providing the Policies, Methodologies, and Templates for Managing Projects within the organization,
2. Providing Support and Guidance to others in the organization on how to manage projects, training others in project management or project management software, and assisting with specific project management tools,
3. Providing Project Managers for different projects, and being responsible for the results of those projects (All Projects, or project of a certain size, type or influence, are managed by this office).

Sehingga tugas PMO adalah gado-gado. Baik dari penyusunan standar, kebijakan, standard, dan sebagainya terkait dengan Manajemen Proyek. Bahkan dari point 3 di atas disebutkan bahwa tanggung jawab dari pelaksanaan proyek juga diberikan (selain ke Project Manager) juga ke PMO.
Pernah saya melihat talk show di salah satu televisi swasta di mana ada seorang pejabat eselon 2 yang akan diperiksa oleh auditor mengatakan bahwa pertanggungjawaban proyek selain eselon 2 yang melakukan persetujuan pengeluaran anggaran juga ada PMO. Jika terjadi mispurpose, maka PMO juga harus diminta pertanggungjawabannya. Nah, lo…

Itu sangat tergantung seberapa besar peran dan tanggung jawab sebuah organisasi PMO (Roles and Responsibilities) pada perusahaan. Jika memang dianggap PMO adalah “dewa proyek” yang harus mengerjakan sedetil apapun, maka beban PMO akan semakin besar. Jika hanya memberikan guideline, procedures, dan sebagainya, maka organisasi yang meng-execute proyek lah yang bertanggung jawab. Terus terang, sampai saat ini pengukuran nilai keberhasilan proyek masih sumir kecuali dikaitkan dengan uang. Seperti proyek pada pemerintahan, apa tolok ukur keberhasilannya? Sebenarnya harus dijustifikasi oleh pemilik proyek sebelum disetujui proyek tersebut. Jangan sampai PMO dibebankan seluruh pertanggungjawaban. Tetapi pada akhirnya, tergantung peran dan tanggung jawabnya…

Pengalaman saya, PMO itu haruslah multi tasking dan multi purpose. Untuk memberikan sebuah metodologi kepada pemilik proyek, kita tidak bisa langsung justifikasi penggunaan suatu metodologi sebelum membaca, memahami, serta mengerti apa latar belakang, maksud dan tujuan, manfaat dan lain-lain dari proyek tersebut. Mengapa? Ingat proyek adalah pekerjaan yang ada time limitnya, bukan never ending project. Jika memang dalam rentang waktu tersebut ada sebuah achievement yang dicapai, maka PMO harus fokus kepada achievement tersebut. Metodologi yang digunakan bisa saja menggunakan best practice, common practice, atau combined methodologies.

Sebagai contoh, PMO diberikan sebuah rencana kerja pengembangan piranti lunak/software. Kemudian pada akhirnya, akan didapatkan sebuah program yang seperti dijelaskan. Metodologi dan sebagainya diserahkan sepenuhnya kepada PMO. Apa yang harus dikerjakan?
1. Mengundang pemilik pekerjaan untuk menjelaskan latar belakang, maksud dan tujuan, manfaat, dan sebagainya,
2. Justifikasi kebutuhan biaya, waktu, SDM,
3. Pemilihan metodologi yang disesuaikan dengan point 1 dan 2 di atas,
4. Penjabaran guideline berdasarkan metodologi,
5. dan seterusnya.
Ingat, “kebiasaan” yang terjadi selama ini baik pemilik proyek, auditor, dan sebagainya selalu berpatokan pada “angka” alias cost. Keuntungan intangible walaupun dikonversi dalam bentuk rupiah tetap akan dijadikan pertimbangan saja. Sehingga justifikasi biaya harus benar-benar optimal (bukan maksimal) dengan resiko minimal. Dan selalu pertanyaan klasik berupa cost itu akan muncul dalam progress report yang dilakukan secara periodik.

Semoga Berguna…

Manajemen Program R&D berbasis Keppres 80/2003

Apa yang terbayang jika menyebutkan Keppres 80/2003? Pasti langsung berpikir tentang Pengadaan Barang dan Jasa. Memang betul, Keppres tersebut dan perubahannya mengatur pelaksanaan pengadaan barang dan jasa di lingkungan pemerintah. Apakah bisa jika Keppres 80/2003 (selanjutnya disebut Keppres 80) digunakan sebagai acuan untuk melaksanakan penelitian dan pengembangan (research and development)? Di sini saya akan coba sedikit sharing pengalaman…

Tahun 2007, saya dikontrak sebagai Project Management Office pada Program Evaluasi dan Monitoring Pengembangan Industri Telekomunikasi, tepatnya pada Direktorat Standardisasi, Direktorat Jenderal Pos dan Telekomunikasi, Departemen Komunikasi dan Informatika. Pada program tersebut, kami (bukan hanya saya, tetapi rekan-rekan Postel) berupaya keras untuk melaksanakan Program Kerja yang bernama Penelitian dan Pengembangan Produk Telekomunikasi.
Start pada awal Januari 2007, pertama-tama yang kita lakukan adalah mencari dasar hukum pelaksanaan pekerjaan program tersebut. Dari brainstorming pada awal Januari 2007, akhirnya sepakat bahwa pelaksanaan program harus mengacu peraturan perundangan yang berlaku yaitu Keppres 80 serta perubahannya. Pada saat kickoff meeting di Ruang Rapat Dirjen Postel, Gedung Sapta Pesona Lantai 13, di situ Pak Dirjen (Basuki Yusuf Iskandar) mengatakan bahwa ada kemungkinan para peneliti yang notabene adalah pakar di bidang teknologi informasi dan komunikasi akan sibuk mengurus administrasi terutama di akhir tahun anggaran.
Adapun brainstorming dan diskusi yang telah kami lakukan adalah dengan mengundang para auditor eksternal dan internal, baik dari auditor BPK, BPKP, serta Itjen dan bahkan kami sempat diskusi dengan Pak Setia Budi dari Bappenas yang sehari-hari sibuk dengan urusan Keppres 80. Dari hasil brainstorming dan diskusi tersebut, didapat bahwa pola pelaksanaan pekerjaan adalah SWAKELOLA, di mana adanya keterlibatan pihak pemilik pekerjaan (dalam hal ini Direktorat Standardisasi/Ditstand) untuk terjun langsung dalam program Penelitian dan Pengembangan Produk Telekomunikasi.
Yang jelas, dalam KAK (Kerangka Acuan Kerja), tujuan dari program ini sungguh-sungguh mulia, yaitu memajukan industri telekomunikasi dalam negeri dengan memberdayakan peneliti-peneliti dari berbagai institusi (khususnya yang berstatus pegawai negeri). 
Ada sedikit catatan pada saat kita referensi ke Peraturan Menteri Keuangan 96/2006 tentang Standar Biaya di mana seorang peneliti utama digaji Rp. 27.500/jam dengan maksimum meneliti adalah 4 jam/hari. Sehingga didapatkan angka sekitar Rp. 2.310.000/bulan untuk penelitian full 21 hari kerja. Permasalahan yang terjadi adalah di mana pada saat peneliti utama tersebut juga pernah mendapatkan grant dari luar (terutama luar negeri) pada tahun-tahun sebelumnya yang ternyata angka upah per jam-nya sangat fantastis. Bahkan pada saat dilakukan penelitian, ada sedikit anekdot…”bayar murah kok mau selamet” atau “saya bekerja benar-benar Indonesia Raya”, dan sebagainya.
Padahal dari pembicaraan dengan pak Setia Budi, bahwa sebenarnya kita bisa saja mengajukan HSPK (Harga Satuan Pokok Kegiatan) Khusus yang diajukan oleh Menteri terkait kepada Menkeu. Tapi jika hal tersebut dilakukan, kita yakin bahwa penelitian akan mundur dari jadwal semula.
Yang perlu ditekankan, pada akhirnya para peneliti tersebut suka tidak suka, mau tidak mau, akhirnya mengikuti apa yang telah diatur baik oleh Keppres 80 maupun PMK 96/2006. Dan apa yang dikatakan oleh Pak Basuki Yusuf Iskandar pada saat kickoff meeting internal benar-benar terjadi…akhir bulan Nopember 2007, para peneliti utama sibuk sekali dengan pertanggungjawaban administrasi yang notabene itu adalah bukan area expertise mereka. Walaupun hampir seluruh target penelitian yang telah ditetapkan telah tercapai pada akhir tahun anggaran 2007, tetapi saya pikir masih diperlukan upaya Postel untuk pemanfaatan dana yang digunakan (dana PNBP) ini agar lebih optimal dan majunya industri telekomunikasi dalam negeri.

Pada tahun 2008, program kerja ini masih dilanjutkan, tetapi karena saya mendapatkan tugas lain (PMO) maka saya tidak dapat menomitor langsung apa yang terjadi pada program kerja ini. Pastinya, pada bulan Mei 2008 para peneliti akan show off produk mereka dengan menggunakan chipset eksisting yang beredar di pasaran dan harapan di 2009 adalah pure 100% produk lokal Indonesia.

Terima Kasih pak Nuh, pak Basuki Yusuf Iskandar, pak Azhar Hasyim, pak Bambang Suseno, pak Marvels Situmorang dan rekan Postel lainnya yang benar-benar saya acungi jempol atas curahan perhatian, pemikiran, tenaga, waktu, dan lain-lain demi terlaksananya program kerja yang mulia ini.

Untuk Rolas Pago, selamat menempuh “hidup baru”, gunakan ilmu manajemen proyek dengan bijak dan tepat pada program 2008.

Pentingkah Manajemen Proyek?

Mengacu kepada pertanyaan di atas, seberapa pentingkah manajemen proyek (atau program) dalam operasional organisasi/perusahaan?
“Saya sudah biasa dengan proyek”
“Darah saya sudah mengalir mega proyek”
“Separuh hidup saya sudah tidur dengan proyek”
“Saya sudah hapal permasalahan proyek”
dan sebagainya…

Sebenarnya terkadang menjengkelkan juga untuk berurusan orang yang berprinsip “menggampangkan” atau membiasakan untuk “menggampangkan”. Sempat saya bertanya kepada seseorang yang “jago” proyek, tahapan apa saja yang harus dilalui dalam manajemen proyek (istilahnya project life cycle). Mereka langsung menyebut…pertama, tender, kedua, dan lain-lain…

Sebenarnya apa arti harfiah dari proyek itu sendiri?
Menurut Project Management Institute (PMI) melalui Project Management Body of Knowledge (PMBoK), definisi project adalah temporary endeavor with a beginning and an end, creates a unique product, service or result, and is progressively elaborated.
Jadi bisa dipahami adalah adanya 3 unsur utama dalam proyek menurut PMI, yaitu:
1. Performed by People,
2. Constrained by Limited Resources,
3. Planned, Executed, Controlled.

Pada prinsipnya, seluruh proyek memiliki tahapan yang generik. Jarang ditemukan adanya tahapan spesifik untuk manajemen proyek. Adapun tahapan tersebut mengacu ke Project Management Body of Knowledge (PMBoK) adalah sebagai berikut:
1. Inisiasi (Initiation)
2. Perencanaan (Planning)
3. Pelaksanaan (Executing)
4. Monitoring dan Kontrol (Controlling)
5. Penutupan (Closing)

INISIASI
Inisiasi adalah tahapan di mana ada proses penunjukan manajer proyek, mengumpulkan informasi pendukung yang terdahulu, kemudian membagi-bagi proyek besar menjadi beberapa tahapan, kebutuhan dokumentasi, dan sebagainya.
Tahapan ini bukanlah feasibility study, karena feasibility study seharusnya sudah dikerjakan sebelum dilakukan proses manajemen proyek.
Ada salah satu pengalaman proyek besar yang pernah ditangani, di mana feasibility studynya dilakukan bertahun-tahun dengan “menanamkan” sistem ke dalam basis operasional. Jika bagus, maka dilakukan roll out. Jika tidak, maka stop sampai di sini. Ternyata hasilnya bagus dan terjadi transparansi operasi. Dan yang cukup merinding, proses ini malah tidak direview oleh auditor yang memeriksa pekerjaan tersebut.

PERENCANAAN
Benarkah perencanaan proyek berawal dari sini? Bisa ya bisa tidak. Tetapi penekanannya adalah di sini dilakukan perencanaan MANAJEMEN PROYEK, bukan perencanaan PROYEK.
Contohnya adalah membuat statement scope proyek, membuat tugas pokok dan fungsi masing-masing anggota tim, membuat Work Breakdown Structure (WBS), membuat daftar aktivitas, membuat jadwal, merencanakan budget, dll termasuk proses LELANG. Keputusan tertinggi ada di tangan Project Manager dengan tidak mengesampingkan Project Owner selaku Project Director.

PELAKSANAAN
Lampu Hijau untuk Manajemen Proyek. Tahapan ini sudah memiliki anggota tim yang solid, sehingga perencanaan manajemen proyek dapat dideploy.
Manajemen Proyek itu fleksibel, jika ada perubahan dan rekomendasi, maka akan diakomodir sejauh perubahan tersebut masih possible/dimungkinkan. Selain itu, tahapan ini juga dikategorikan sebagai Continuous Improvement. Peningkatan dalam rangka terselenggaranya tata kelola proyek agar tetap on scope, on schedule, on budget, low risk, on quality, best customer satisfaction.

MONITORING DAN KONTROL
Bahasa “gaul”nya adalah Monitoring dan Evaluasi (ada yang menyebutkan ME ada juga Monev). Perencanaan yang telah disepakati pada tahapan Planning akan digunakan sebagai basis untuk melakukan monitoring dan kontrol. Sebagai contoh, dilakukan pengukuran performasi proyek. Jika memang dalam tahapan Planning adanya kategori pengukuran performasi (bisa time-based, result-based, progress-based, dll) maka pengukuran diambil dengan menunjuk titik tertentu. Tetapi harus diingat, bahwa di sini harus ada dokumen yang telah disepakati bersama yang digunakan sebagai acuan dalam pengukuran-pengukuran tersebut.

PENUTUPAN
Dalam fase ini, baik pemilik proyek, pelaksana proyek, dan lain-lain memiliki hak dan kewajiban sebagai syarat dan prasyarat untuk melakukan penutupan proyek. Di lain pihak, manajemen proyek harus menyediakan sebuah tatanan yang terstruktur agar penutupan ini bersifat win-win solution. Tentunya sering terjadi penutupan yang tidak kunjung datang (Saya pernah mengalaminya) karena adanya request berkepanjangan dari sisi owner. Jika memang tidak kunjung henti sampai tidak dapat terdefinisikan, maka manajemen proyek bisa dikatakan FAILED. Dokumen-dokumen yang telah disepakati untuk dideliver akan menjadikan syarat utama penutupan kontrak. Yang perlu diperhatikan juga adalah dokumen perubahan-perubahan perencanaan tentunya akan sangat berharga jika dielaborasi menjadi dokumen inti dan bukannya dokumen terpisah (dokumen inti dan perubahan) yang akan mempersulit pemahaman bagi pembaca dokumen.

Dari beberapa tahapan tersebut, sudahkan Anda memiliki awareness terhadap masing-masing proses? Sudahkan proses tersebut dilalui dengan sukses?
Kembali ke diri kita sendiri, seberapa jauh keinginan untuk mensukseskan pelaksanaan proyek melalui tatanan manajemen proyek yang terstruktur.

Kantor Proyek @ Ciputat, Maret 2008