Gamatechno · Manajemen Proyek · Project Management

Estimate Activity Durations

Dari judulnya, sudah self-explained. Hm.. let’s see. Tapi sengaja memang saya tulis dalam bahasa Inggris, since dalam semua referensi PM, ini adalah formal naming-nya. .

Pada aktivitas ini, PM (dibantu dengan teknik dan alat) mengestimasikan jumlah dari effort (hari-kerja) yang dibutuhkan untuk menyelesaikan setiap aktivitas. Misal, aktivitas A akan memakan waktu 80 manhours (orang-jam) untuk selesai. Ketika kita punya hanya 1 anggota dengan kekuatan 50%,  secara kilat bisa dihitung aktivitas A itu akan selesai dalam 22 hari kerja.

Kok tiba-tiba langsung menghitung estimasi durasi aktivitas? Penentuan aktivitasnya kapan?

Baique. Proses ini, masuk dalam process group Planning, dalam domain Project Schedule Management. Proses ini didahului oleh pendefinisian dan pengurutan aktivitas.

  1. Domain process group : Planning
  2. Domain management   : Project Schedule
  3. Previous step                : Define Activities – Sequence Activities
  4. Post step                       : Develop Schedule
  5. Output                           : Activity Duration Estimates (include reserve)

Ada 1 proses yang hilang, dari peralihan pmbok5 ke pmbok6: Estimate Activity Resources. Somehow proses ini juga mendahului, tapi belum nemu dilebur ke mana. Hehe. Yang jelas, Resource Breakdown Structure (kapan-kapan ya penjelasannya) masih jadi input Estimate Activity Durations.

Okey. Kalian pakai teknik apa untuk menghitung durasi sebuah aktivitas? Pakai hitungan aktivitas serupa sebelumnya trus ditambahin reserve? atau pakai ilmu terawang? atau nanya yang lebih ahli/jago, yang pernah ngerjain todo tersebut?

Semua benar dan masuk akal, kecuali no 2. Hehe. Ilmu terawang itu masuk ke ranah experts opinion. Tool yang digunakan untuk melakukan estimasi, terekam di pmbok ada beberapa: analogous, parametric, three-point, group-decision making, dan reserve analysis. Anda harus tahu semuanya. Yuk, kita kulik.

analog vs parametric
Komparasi analog vs parametric estimating, sodara-sodara…

Lanjut. Three point estimating, berarti kita menggunakan 3 perspektif data untuk menghitung durasi. Alih-alih hanya bertanya versi ‘biasanya (most-likely, alias ML)’ , kita juga gunakan data case terburuk/terparah (pessimistic, P) dan case tercepat (optimistic, O). Data ini bisa diambil dari data riwayat, atau pure dari experts opinions. Ada 2 pendekatan: Triangular (simple average) dan Beta (populer disebut PERT – Program Evaluation and Review Technique).

  • Triangular Estimate       : (P + ML + O) / 3
  • Beta/PERT Estimate      : (P + 4 ML + O) / 6

Teknik PERT boleh perhalus Anda punya estimate ya (baca pake logat Malay).

Berikutnya, Group decision-making technique. Istilah saya: ayo diterawang bareng-bareng, rame-rame, karena kalau tim yang akan mengerjakan project, dilibatkan dalam perhitungan (estimasi) durasi, level komitmennya akan lebih tinggi. Dijamin. Bisa pakai teknik musyawarah untuk mufakat, atau voting.

Terakhir, Reserve Analysis. Judul nya dah jelas. Teman-teman PM tercinta, perhatikanlah faktor known-unknowns dan unknown-unknowns. 2 ini selalu ada disekitar Anda, dan perlu diantisipasi.

Known-unknowns berarti hal-hal yang Anda tahu akan terjadi dan berefek pada aktivitas project, tapi somehow Anda tidak bisa mengukur derajatnya. Seputaran data gathering, misalnya. Ada SOP yang sedang di perbarui padahal itu berimpact pada beberapa requirements, atau aktivitas konversi data yang Anda belum yakin seberapa bagus kamus-data legacy systemnya, atau proses instalasi server production, yang Anda belum yakin apakah spesifikasi nya hardware nya full comply dengan OS yang Anda bawa, dan seterusnya. Risiko-risiko ini wajib tetap masuk dalam kelolaan PM, dan PM harus membuat reserve-nya. Menambahkan prosentase sekian persen dari estimated effort adalah praktik yang lazim.

Nah, Unknown-unknowns ini, adaah hal-hal yang tidak dapat kita lihat/prediksi dan seberapa akan mempengaruhi project. Apa ya contohnya. Hehe. Pergantian middle management mendadak, atau ada perubahan policy anggaran, misal. Atau ada staf Anda tiba-tiba menikah dan memutuskan resign. Tipe risiko ini memang tidak masuk dalam project baseline. Lalu bagaimana mendesain buffer nya? Yaa, pakai data history saja. 😀

Advertisements
Gamatechno · Manajemen Proyek · Project Management

Collect Requirements

rawpixel-648561-unsplash.jpg

Photo by rawpixel on Unsplash

Saya merasa agak aneh kalau judul di atas harus ber-EYD. Para praktisi project lebih familiar dengan frase di atas, alih-alih ‘Pengumpulan Kebutuhan’, misalnya. Hehe. Tidak material ya. Lanjut..

Sekian lama bergelut di IT project management, bagian ini adalah bagian yang sangat penting, pun jika semisal kalian sudah memiliki mock-up, atau bahkan produk jadinya. Di project B2B seperti yang Gamatechno jalani, software development, it really matters to get the right scope right, sedari mula proses penggalian. Abai dan lalai pada fase ini, percayalah akan ada harga yang harus Anda bayar. Pernah ngrasain? Saya pernah, dan semoga bagi yang belum, berusaha-lah belajar dan ambil hikmahnya dari project manager seperti kami-kami ini.

Makin sering dan makin dini diskusi (dengan stakeholders) terjadi, makin baik. Demi apa? Demi akurasi pengumpulan kebutuhan. Bicara tentang jenisnya, ada kebutuhan fungsional, non-fungsional, kebutuhan unjuk-kerja, kebutuhan integrasi, dan lain-lain. In the end, pada beberapa project bahkan, ketika output nya sudah memenuhi kebutuhan, bisa saja project tersebut dianggap gagal loh. Coba tebak kenapa?

Ya karena balik ke ke-akurasi-an tadi itu: 1) Anda mengerjakan kebutuhan yang ternyata bukan itu yang diinginkan (oleh stakeholders); atau,  2) salah mewawancarai stakeholders. Hehe. Bisa nyengir begini biasanya karena sudah jadi masa lalu. Well, sometimes you win, sometimes you learn. Right?

Technically speaking, PM memiliki banyak opsi teknik untuk collecting requirements. Kita bahas beberapa ya.

Focus Groups.  Teknik ini digunakan biasanya untuk mendapatkan ekspektasi dari stakeholders, mendapatkan constraints, so kurang pas untuk penggalian requirements itu sendiri. Yes bisa jadi ada satu dua requirements terucap, tapi sulit untuk mengembangkannya pada forum ini.

Facilitated Workshops. Di Gamatechno, kami mengistilahkannya Workshop RG. Hehe. Apalah arti semua nama (du du du). Lebih teknis nih, for sure. Teknik ini digunakan untuk mengembangkan kebutuhan. Ada beberapa contoh: JAD sessions, atau QFD, atau Agile Methods (diulas di artikel terpisah aja kali ya.. ). Most of the time, Gamatechno gunakan JAD meetings. Again, karena barangkali karakter produk kami lebih pas dengan pendekatan JAD sessions.

Observations, alias job shadowing. Digunakan pada tipikal stakeholders yang sulit mengkisahkan kebutuhannya, atau yang enggan melakukannya.

Prototypes. Dari judulnya sudah self-explaining ya. Biasanya ini berwujud sesuatu, yang bisa disentuh dan diubah-ubah. Boleh dibilang, ini adalah mock-up dari produk sebenarnya yang akan dibuat (pada akhirnya). Yang perlu diperhatikan adalah lakukan iterasi, dan siapkan story-boards nya atau ilustrasi agar stakeholders mudah memahami mock-up Anda itu.

Benchmarking. Metode ini digunakan untuk membandingkan (yang dimiliki) dengan organisasi lain. Tujuannya adalah membantu kita menentukan standard (baca: requirements) dan mengidentifikasi strategi untuk mencapainya.

Context Diagram. Hm. Agak-agak lupa tentang satu ini, tapi  kurang lebih penggambaran  proses bisnis yang terjadi di dalam organisasi beserta interaksinya dengan setiap orang dan setiap hal  yang berkaitan.

Documentation Analysis. Ini sepertinya jadi yang terakhir, tapi juga teknik yang sering digunakan. Yes, analisis dokumentasi dari organisasi stakeholders Anda yang berhubungan dengan project tersebut. Contohnya: Dokumen masterplan/blueprint organisasi, SOP, legacy system user manual, dokumen lessons learned terkait, atau kontrak-kontrak.

Apa lalu keluaran dari kegiatan ini? Kalau sesuai guidance PMBOK, namanya dokumen RTM (Requirement Traceability Matrix). Dokumen ini menjadi panduan penting bagi PM, untuk selalu dapat memastikan bahwa setiap requirement memang terhubung dengan goal besar organisasi, yang harapannya ketika project selesai, terjadi lonjakan nilai tambah bagi organisasi dan bisnisnya. ^^

Tetap semangat!

 

Gamatechno · Manajemen Proyek · Organization · Project Management

Komparasi Organisasi Proyek

Hi Gaes. Sekarang kita akan ulas mengenai organisasi proyek ya. After all, saya adalah IT project manager, dan saya wajibkan diri saya untuk berbagi hal-hal seputaran ini.  Cara sebuah tim bekerja, berkomunikasi, dan pada akhirnya mengirimkan nilai (baca: output dan outcome) proyek kepada stakeholdernya, dipengaruhi seberapa kita secara baik menata tim dan organisasi proyeknya dan memperhatikan selalu apa yang menjadi faktor-faktor pengaruhnya.

Biasanya, kultur organisasi mempengaruhi project Anda dan mempengaruhi pula tingkat kesuksesannya (semacam). Struktur organisasi mempengaruhi kultur dan sebaliknya pula, kultur mempengaruhi struktur. Itu katanya Aileen Ellis, PMP, dan yes it is so true. Terlampir adalah komparasi model organisasi proyek yang dapat terbentuk dalam sebuah institusi yang menjalankan ritual project sebagai kegiatan operasionalnya :

project organization comparison
project organization comparison

Nah, di Gamatechno seperti apa? Well, in between Weak Matrix dan Balanced sih. Kami lebih sering ada di posisi weak matrix, since posisi PM selalu ada di setiap divisi Profit Center (yang mewajibkan PM melapor ke Functional Manajer). Nyaris tidak pernah ada juga memang, project/proyek yang lintas divisi.

Role PM di desain juga fungsional, yang itu berarti ada kewajiban-kewajiban lain yang harus ditunaikan oleh PM, ketugasan-ketugasan divisi yang tidak berhubungan langsung dengan kegiatan pengelolaan proyek. Hal positifnya, masih banyak ruang improvement. Dari pengalaman saya, preferensi setiap institusi perihal organisasi proyeknya selalu menyesuaikan kapasitas, selera risiko perusahaan, dan segmen pelanggan seperti apa yang dilayani oleh produk/jasa perusahaan tersebut. Tidak ada benar-benar 1 model ultimate organisasi proyek.

Belajar terus aja pokoknya. Never settle.

Gamatechno · General · Project Management

The Famous “Triple Constraints”

“Stacked Triangles”. setidaknya ada 2 layer segitiga dalam gambar di atas. Masih terkenal dengan “triple constraints”, hanya saja aspeknya sudah berkembang. Tambah seru, mumet! 😀

Dalam project management, seorang PM dituntut untuk mendesain trade-off terbaik dari 6 aspek di atas. Competing project constraint, kalau menyalin dari literasi PMBOK. Enam aspek itu akan saling menekan, one way or another. You can’t be great at everything. Kurang lebih begitu ya. Excellency needs underperforming pada titik titik tertentu, kata mas Yuswohadi. Enam aspek itu: Risiko, Jadwal, Sumber-daya, Dana, Kualitas, dan Ruang lingkup.

Bahkan Surga-pun, puncak kenikmatan abadi yang dijanjikan Tuhan atas umat-Nya yang beriman, harus dibayar dengan pengorbanan-pengorbanan. Pemahaman yang seperti itu perlu disampaikan kepada stakeholders terkait. PM harus aktif dan terus-menerus jalin komunikasi yang baik dengan pelanggan-nya.

Ada pengguna yang mudah diajak berpikir dan memahami competing project constraints ini, ada pengguna yang keukeuh pengen serba cepat, serba baik, tur rasah Mbayar. Saya pikir itu dinamika normal, hari-hari yang akan dijalani oleh Project Manager.

Last but not least, pun gak nyambung: The devil is in the details. Pengalaman saya selama ini sih, PM perlu masuk cukup dalam di project-nya. Berusaha mengetahui setiap hal, since you’re the Boss dude! Tidak mungkin, setidaknya dalam konteks project management, PM hanya berhenti di permukaan dan merasa bahwa project-nya sepertinya baik-baik saja. Takutnya itu adalah perasaan semu, yang mengantarkan kita tidak kemana-mana selain remuknya project.

Salam sukses! ^^

Project Management

Cara Cepat Mengestimasi Biaya Project

Melakukan estimasi biaya (cost) untuk sebuah project baru, khususnya TI, kadang kala merepotkan. Belum lagi bilamana PM tidak familiar dengan teknologi yang akan digunakan di project itu nantinya.

Pengestimasian mungkin semacam judi; kadang tepat, kadang meleset. Faktor tebakan sedikit banyak pasti memberikan kontribusi, apalagi bila perusahaan TI tersebut belum pernah mengerjakan project yang serupa sebelumnya. Menurut saya, berdasarkan pengalaman pribadi juga, ada 2 hal yang bisa dilakukan :

  1. Membuat estimasi aktivitas project secara terurut
  2. Bertanya pada mereka yang sudah berpengalaman

Untuk yang no 1, penjelasannya seperti ini. Saya yakin para PM sudah ready dengan template project plan mereka. Tuliskan capaian-capaian dari project ini. Capaian lho ya, bukan aktivitas. Setelah semua teridentifikasi, baru kemudian daftarkan semua aktivitas yang diperlukan untuk mencapai setiap capaian dan estimasi work-nya. Bila Anda menggunakan MS Project (contoh case tools saja), semua work akan di sum-up dan kita akan mendapatkan estimasi holistiknya. Jangan lupa menambahkan 15% atau 20% dari estimasi holistik sebagai backup atas risiko-risiko dan ketidakpastian eksekusi project tersebut.

Berlanjut ke no 2, konsultasikan project plan tersebut ke person-person yang sudah berpengalaman mengeksekusi project yang sama/serupa. Barangkali ada masukan dan revisi tentang estimasi.

Saya yakin estimasi akan lebih masuk akal/diterima bila kita dapat memperhitungkan hal-hal yang detil. What do you think? Piece a cake..? Saya pikir relatif ya. Saya pernah menjumpai sendiri sebuah estimasi project dengan breakdown aktivitas sejumlah 700 item. Very very details.

Orang tua bilang kalau estimasi adalah sebuah seni (art). Berarti PM juga seniman dong? Yap. Dan saya memandang, seniman adalah orang yang selalu terobsesi dan cinta dengan pekerjaannya.

Project Management

Bagaimana menjadi Project Sponsor yang buruk!

Bagi para project sponsors/upper stakeholders yang ingin memastikan projectnya gagal, berikut adalah beberapa tips dari Dick Billows yang insyaalloh tokcer:

  1. Jangan mau bila diajak ketemuan oleh Project Manager (PM) ketika fase perencanaan. Jika PM ngotot bertemu Anda dan bertanya segala hal ttg scope, jawablah: “Anda ngapain di sini?! Sudah mulai kerja kan? Seharusnya Anda sudah setengah jalan kan sekarang!”
  2. Ketika PM memberikan rencananya, jangan disetujui, jangan dikomentari, atau bahkan jangan dibaca (parah!). Trus gimana? Tunggu saja 1 minggu, lalu kirim email ke PM dan bilang: “Masa gini aja hasil kerja Anda?”
  3. Berikan PM usulan struktur approval bertingkat untuk progress report project.
  4. Ketika project dimulai, undang anggota tim di sebuah acara dan berikan statement semacam ini: “gimana ya.. saya gak yakin dengan PM Anda yg satu ini. Jika Anda ada pertanyaan, silakan pv saya. Bersama-sama kita bisa selesaikan project ini”
  5. Bila diundang dalam rangka pemaparan progress, sempatkan hadir 5 atau 10 menit lalu berkomentarlah bahwa itu semua nonsens.
  6. Manfaatkan budget project untuk menambahkan pernak pernik (baca: aktivitas) ke project scope. Ini bisa juga digunakan untuk menyenangkan kawan politik Anda, hitung-hitung sebagai balas jasa sudah membantu menggolkan project.
  7. Last but not least, jika projectnya over budget atau telat banget selesainya, jangan mau mengakuinya dan bersumpahlah bahwa Anda tidak pernah berjumpa dengan PM. Tapi jika projectnya sukses berat, tetap saja klaim bahwa Anda tidak pernah ketemu dengan PM dan terima semua pujian yang datang–seakan-akan Andalah yang paling berjasa karena sudah mewujudkannya. OH my…

     

Good Luck!    

Project Management

Membuat Project Charter

Bila ada sebuah dokumen yang harus pertama kali muncul dalam cycle project management (saat-saat sangat awal pada sebuah project), maka itu adalah dokumen project charter.

Dokumen ini harus berisi tentang visi dari project, tujuan dan ruang lingkup pekerjaan yang membuat semua orang menjadi jelas tentang apa yang akan dicapai oleh project tersebut. Keterangan tentang deliverables, orang-orang yang terlibat di dalamnya, dan waktu delivery, juga disebutkan.

Berikut adalah tips untuk membuat dokumen project charter:

  1. Tentukan visi project; Well, setiap orang membutuhkan visi. Tim project pun juga harus punya. Ketika menentukan visi, pastikan bahwa Anda sebagai PM: 1. Mendapatkan persetujuan dari sponsor project (klien) tentang visi tsb.; 2. Tuliskan visi ini dalam kalimat yang jelas dan mudah dipahami; 3. Komunikasikan dengan semua orang di tim. Baiknya, PM mengkomunikasikan visi ini ke tim secara direct/offline. Penggunaan email sedapat mungkin dihindari saja.
  2. Definisikan ruang lingkup; Ruang lingkup berisi tentang aktivitas dan deliverables yang harus dicapai dalam rangka memenuhi visi. Mendapatkan definisi ruang lingkup secara detil jelas akan membantu perencanaan project. Anyway, definisi ini akan mencegah adanya momok ruang lingkup tentang aktivitas/deliverables yang tdk terencana dan biasanya dipaksakan oleh end user. Dengan mendefinisikan ruang lingkup ini, PM dapat mengelola permintaan/kebutuhan end user dan mampu untuk mengatakan kepada mereka bahwa sebuah request misalnya adalah out of scope dan karenanya membutuhkan tambahan uang atau waktu untuk menyelesaikannya.
  3. Tentukan hirarki dan komposisi tim; Ketika kita tahu tujuan akhir project dan deliverables apa saja yang harus dihasilkan, selanjutnya PM harus menentukan siapa yang akan mengerjakan ini. As usual, buatlah sebuah struktur organisasi yang memuat semua stakeholders (eksternal customers dan internal customers – i.e. developer) dan gambarkan sekalian jalur komunikasinya. Gambar ini akan membuat PM mudah untuk menentukan kebutuhan resources, tanggung jawab dan job desc dari timnya.
  4. Buatlah roadmap; Roadmap ini semacam project plan yang memuat fase dan aktivitas yang akan dilalui oleh project ybs., dan menggambarkan 1 cycle project management secara utuh. Lalu, setiap aktivitas harus diidentifikasi siapa-siapa yang akan mengerjakannya. Yang terakhir, keluarkan estimasi pengeluaran (uang) untuk penggunaan resources (mostly sih SDM) dan pastikan tidak over budget. Bila PM belum tahu tentang pagu penggunaan budget, informasinya bisa didapatkan dari otoritas keuangan perusahaan atau bahkan direksi.
  5. Identifikasi risiko dan isu-isu; Langkah terakhir dalam membuat dokumen Project Charter adalah mendaftar risiko dan isu-isu nyata disekitar project. Dengan mendaftar hal tersebut, PM dapat menyodorkannya ke klien dan supaya mereka aware dan goalsnya adalah meminta support penuh supaya risiko bisa dikurangi.