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

Layers of Project Management

Photo by Samuel Zeller on Unsplash

Menjadi project manager, bila Anda benar-benar in to it, profesi ini akan menuntut Anda untuk tidak hanya belajar hal-hal yang metodologis dan teratur, tapi ada juga set of non technical skills, very human yang harus dikuasai. Is it about art? Mbuh! Tapi intine kudu luwes, dan terampil. Ini dia set of skills required:

  1. Penguasaan proses bisnis/area bisnis. You better have a decent knowledge dalam mana project Anda dilangsungkan. Saya, bergelut dengan IT project management selama 13 tahun, akan sangat kesulitan jika diminta menangani oil and gas kind of projects, atau project-project sipil. Blas gak dong. Bisa saja dikondisikan, tapi harus mulai dari bawah dulu, tidak ujug-ujug langsung menjadi PM. Memiliki skill yang memadai pada bidang project tersebut, hingga titik tertentu menjadi expert, akan membuat Anda lebih mudah memimpin tim.
  2. General Management. PM juga harus punya decent knowledge perihal ilmu-ilmu yang umum, seperti pemasaran, keuangan, dan akuntansi.
  3. Knowledge. Ini me-refer pada pengetahuan pengelolaan project, based on project management body of knowledge (PMBOK). As we recall, PMBOK adalah set of guidance yang dibentuk dari akumulasi praktik-praktik baik dan teruji. Tidak ada yang mengharuskan PM mengikuti PMBOK since PMBOK bukanlah regulasi, tapi ga ada salahnya loh comply.
  4. Performance. Mengelola unjuk kerja, peka dan adaptif terhadap sekecil apapun situasi yang dapat mempengaruhi milestone(s) dan overall schedule, baik internal maupun eksternal.
  5. Personal. It is about leadership. Set a clear of purpose, dan doing servantship. Menyiapkan jiwa dan mental melayani, since Anda yang harusnya paling fleksibel.

Dalam perspektif lain, yang lebih sederhana seperti disampaikan Lew Sauder dalam bukunya Project Management 101, segala aktivitas PM dalam project, bisa dibagi dalam 3 layer:

Layer 1: Layer Administratif

Layer ini memberikan perhatian pada hal hal sangat dasar, mengenai pencatatan dan perekaman, topiknya. PM bertanggung jawab mengkoleksi status pengerjaan, memperhatikan project plan, kalau perlu harus ada yang disesuaikan ya disesuaikan, mengendalikan anggaran dan secara periodik berkomunikasi dengan upper management.

Layer 2: Layer Manajemen

Layer ini adalah tempat dalam mana PM cenderung mengelola hal-hal yang lebih kompleks, seperti contohnya risiko. Melakukan analisis risiko (qualitative atau quantitative), mengelola issues dan memastikan apakah itu oppty atau threat, lalu mengembangkan mitigasi-mitigasi (risk response) untuk mengantisipasi in-case.. risiko itu terjadi.

Layer 3: Leadership

Layer paling tinggi, menantang setiap PM agar mampu mengubah dirinya, menjadi/memerankan leader yang capable. Mbuh piye carane, bisa dekat dengan pelanggan/mitra yang akan mengkonsumsi artefak yang dihasilkan oleh project Anda. Anda harus paham sejatinya masalah mereka, pun misal mereka tidak mampu menjelaskannya secara efektif. Solusi yang nanti dihasilkan dari project ini, harus dipastikan menjadi pendongkrak nilai tambah bagi organisasi, alih-alih sekedar menuntaskan item per item requirements.

Itu dari sudut pandang eksternal, stakeholders. Untuk internal, lebih-lebih lagi kawan. PM dituntut untuk membuat tim menjadi padu, kompak, men-setup ground-rule, memastikan ada proper training agar hard-skill nya mencapai tingkat yang dibutuhkan dalam project. Lanjut, PM harus kembangkan situational leadership. Penanganan dan pendekatan ke satu anggota tim, berbeda dengan anggota lainnya, karena setiap orang berbeda. PM memastikan, bahwa kesuksesan project ini juga akan berdampak pada kesuksesan setiap anggota tim pada akhirnya, dan karena itu harus diupayakan agar mereka mengeluarkan effort terbaiknya.

Layer yang paling challenging, cant agree more.

Tetap semangat!

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! ^^

Gamatechno

Gamatechno CDP Application Developer kembali digelar!

CDP Application Developer Perdana telah berhasil dilaksanakan pada akhir tahun 2008 lalu dan saat ini beberapa lulusan terpilihnya sedang mengikuti proyek magang dari Gamatechno. Kita akan kembali menyelenggarakan CDP
Application Developer ke-2 yang akan disusul dengan CDP-CDP lainnya.

CDP Application Developer memberikan fundamental web programming yang kuat, mulai dari konsep software development life cycle hingga mampu mengembangkan software aplikasi berbasis web. Pastikan rekan sekalian sudah menguasai dasar-dasar PHP. Mereka yang terpilih akan diberikan kesempatan untuk bergabung dalam pengembangan proyek bersama Gamatechno.

Program ini GRATIS, terbuka bagi fresh graduate dan mahasiswa tingkat akhir, diutamakan dari jurusan Ilmu Komputer, Teknik Elektro, dan Teknik Informatika.
Pelaksanaan CDP : 13 – 30 April 2009

Segeralah mendaftar karena pendaftaran gelombang ini hanya dibuka sampai tanggal 28 Maret 2009.

Cara pendaftaran dan informasi lainnya bisa diperoleh di Portal CDP,
http://cdp.gamatechno.com ( cdp dot gamatechno dot com ).


Portal CDP, Where Legends Begin
http://cdp.gamatechno.com