Manajemen proyek: tradisional, berulang, atau hibrid?

Seperti kebanyakan manajer proyek (dan organisasi), Anda mungkin kesulitan memilih pendekatan penyampaian yang optimal. Kebanyakan dari kita menyadari bahwa pendekatan tradisional tidak menjamin penyampaian yang sukses dan selalu mencari cara yang lebih baik.

Metode pengembangan agile atau iteratif dalam beberapa tahun terakhir mendapat banyak liputan positif karena dianggap sebagai peningkatan yang signifikan, sehingga menghasilkan penyampaian proyek yang lebih sukses. Karena itu, seperti kebanyakan organisasi saat ini, organisasi Anda mungkin bertanya-tanya di mana dan bagaimana metode pengembangan agile atau iteratif ini paling baik digunakan untuk meningkatkan ketepatan waktu dan keberhasilan dalam penyampaian proyek.

Singkatnya, teknik pengembangan iteratif merencanakan, mengembangkan, dan mengimplementasikan fungsionalitas proyek dalam bagian-bagian kecil (atau iterasi). Kunci keberhasilan penyampaian iteratif adalah setiap bagian kecil berfungsi secara efektif sebagai proyek mini yang lebih kecil di bawah payung total proyek. Hasilnya, setiap iterasi proyek mini dapat merencanakan upaya yang diperlukan untuk menyelesaikan iterasi dua minggu dibandingkan rencana dua tahun dengan lebih baik. Selain itu, karena kita merencanakan dalam interval dua minggu, rencana untuk dua minggu berikutnya dapat dengan mudah disesuaikan untuk mengakomodasi perubahan apa pun yang teridentifikasi.

Studi kasus Agile versus tradisional

Saya ingin berhenti sejenak untuk menjelaskan situasi non-teknis, di mana keberhasilan yang lebih besar dicapai dengan menggunakan pendekatan agile dibandingkan rencana tradisional.

Mari gunakan contoh merencanakan aktivitas satu hari penuh—itulah proyeknya. Seperti proyek besar, ada banyak ketidakpastian dan risiko dalam hal ini: kita tidak tahu apa yang akan terjadi setelah makan siang yang dapat memengaruhi rencana kita, tetapi tradisi menyatakan bahwa kita menyusun rencana komprehensif untuk apa yang akan kita lakukan setiap jam dalam sehari, dari bangun pukul 6 pagi hingga tidur pukul 11 malam.

Pukul 9 pagi, kami sudah tertinggal jadwal karena lalu lintas menunda perjalanan ke kantor; pukul 10 pagi kami dipanggil ke rapat darurat; dan pada siang hari, satu-satunya tugas harian yang selesai adalah tiba di kantor, itu pun terlambat.

Sekarang, anggap ini sebagai proyek agile dengan rencana hanya untuk iterasi berikutnya: bersiap meninggalkan rumah (dengan cerita: mandi, sarapan, dan mengantar anak ke sekolah). Semua ini berhasil disampaikan tepat waktu dan sesuai anggaran.

Jadi, dengan percaya diri, kami merencanakan iterasi berikutnya, yaitu sampai ke kantor (berkendara ke terminal bus, naik kereta komuter ke stasiun, lalu naik bus kota ke kantor).

Ini tidak berjalan dengan baik: cerita pertama (berkendara ke depo bus) mengalami kendala lalu lintas, sehingga kami mengubah cerita pengguna menjadi berkendara ke kantor dan menyepakati bahwa dua cerita lainnya dapat dihapus dari rencana iterasi. Setibanya di sana, kami merencanakan iterasi berikutnya. Namun, di tengah siklus perencanaan, cerita baru ditambahkan (rapat darurat), dan cerita ini akan menghabiskan seluruh iterasi berikutnya.

Akhirnya, setelah makan siang, keadaan mereda dan kami dapat melihat backlog serta memulai tugas dengan prioritas tertinggi; kami berhasil menyelesaikan dua iterasi yang menangani item prioritas tertinggi pada sore hari.

Seandainya kami tetap berpegang pada rencana tradisional, kami tidak akan pernah menyelesaikan item prioritas tertinggi ini, karena item tersebut dijadwalkan ulang ke hari berikutnya akibat keterlambatan rencana yang disebabkan perjalanan ke kantor.

Apa pendekatan terbaik—agile, tradisional, atau hibrida?

Fleksibilitas untuk menyesuaikan diri dengan kebutuhan bisnis yang berubah inilah yang paling unggul pada metode agile atau iteratif, dan alasan banyak organisasi mengadopsinya. TAPI, apakah organisasi Anda benar-benar siap untuk sepenuhnya beralih ke agile? Pengalaman saya menunjukkan bahwa sering ada banyak hambatan untuk adopsi agile secara penuh, terutama kebijakan organisasi yang sudah mapan dan sering kali kurang kompatibel dengan pendekatan agile.

Kebijakan seperti keharusan memiliki anggaran tetap, pernyataan realisasi manfaat, dan tanggal target sebelum proyek dapat disetujui memang penting (tetapi tidak benar-benar agile). Demikian pula, kebijakan implementasi organisasi yang harus diikuti untuk memastikan tidak ada dampak pada operasi yang ada adalah hal yang kritis (tetapi jelas tidak agile).

Akibatnya, banyak organisasi kesulitan menjaga beberapa “proses tradisional” yang penting sambil menyesuaikan diri dengan metode iteratif. Jawabannya adalah model pengiriman hibrida. Bagian-bagian proyek dapat disampaikan menggunakan metode manajemen tradisional, sementara bagian lainnya dapat bersifat iteratif.

Model pengiriman hibrid

Model hibrida yang paling umum saya temui mendukung startup dan perencanaan proyek tradisional, diikuti serangkaian iterasi dengan jeda untuk aktivitas implementasi tradisional bagi rilis, lalu diikuti serangkaian iterasi lain dan implementasi tradisional.

Dalam model ini, saya menyusun work breakdown structure (WBS) tradisional berbasis hasil kerja, yang mengidentifikasi hasil kerja utama yang diperlukan dalam organisasi untuk persetujuan proyek, seperti Piagam Proyek, Rencana Manajemen Proyek, dan Anggaran Proyek.

Hasil kerja awal ini dapat dikembangkan dan dikelola menggunakan metode tradisional untuk menunjukkan kepada manajemen bahwa proyek ini tepat dan merupakan tempat yang baik untuk menginvestasikan sumber daya.

Setelah proyek disetujui, proyek dapat dilanjutkan secara iteratif dengan mempertahankan backlog cerita, lalu memilih dan mengembangkan cerita dengan prioritas tertinggi secara menyeluruh pada iterasi berikutnya. Tampilan proyek berubah dari visual diagram Gantt tradisional menjadi papan interaktif seret dan lepasuntuk menetapkan cerita secara dinamis ke iterasi.

Kapan saja, bahkan setiap hari, pemilik produk dapat menambah, menghapus, dan mengubah cerita dalam backlog sesuai kebutuhan bisnis yang berubah.

Di akhir setiap iterasi, kami berhenti dan melakukan evaluasi retrospektif atas keberhasilan dan kegagalan, lalu membuat perubahan untuk menerapkan peningkatan yang diperlukan. Selanjutnya, yang terpenting, kami meninjau backlog produk dan memilih cerita terpenting untuk iterasi berikutnya. Pendekatan ini memastikan proyek selalu mengerjakan pekerjaan yang paling sesuai dan bernilai tertinggi.

Dalam setiap iterasi, tim dapat menerapkan prinsip agile, seperti standup harian, untuk membahas status cerita yang dijadwalkan dalam iterasi saat ini. Dengan cara ini, tim memiliki kendali penuh atas pekerjaan yang diselesaikan dalam satu iterasi, sambil tetap memastikan bahwa keseluruhan proyek tetap terkini dan tersedia untuk pelaporan perusahaan terhadap kapasitas sumber daya serta status portofolio dan program.

Salah satu kunci prinsip agile adalah kemampuan mengimplementasikan solusi akhir dalam rilis kecil. Keuntungannya, fungsionalitas awal dapat digunakan untuk mencapai sebagian manfaat bisnis yang diantisipasi secepat mungkin.

Selain itu, solusi dapat divalidasi lebih awal sehingga penyesuaian dapat dengan mudah diterapkan pada cerita yang tersisa dalam backlog produk. Oleh karena itu, setelah cukup banyak cerita berprioritas tinggi diselesaikan dalam beberapa iterasi, proyek kembali ke siklus tradisional dan menjalankan tugas implementasi standar yang diperlukan organisasi.

Coba Microsoft Project secara gratis

Coba Microsoft Project selama satu bulan secara gratis

Pelajari caranya

Aktivitas rilis dan implementasi ini akan direncanakan dan dikendalikan menggunakan pendekatan tradisional dan akan memastikan proses yang ditetapkan diikuti untuk mengurangi dampak apa pun pada operasi yang ada saat proyek baru diimplementasikan.

Setelah rilis pertama selesai, proyek kembali menggunakan pendekatan agile dan memulai rangkaian iterasi berikutnya untuk melanjutkan pengembangan cerita yang tersisa.

Meskipun pendekatan “bertahap” untuk menggabungkan pendekatan agile dan tradisional adalah yang paling umum, Anda dapat mengombinasikan pendekatan untuk mendukung persyaratan penyampaian proyek tertentu. Sebagai contoh, saya mengelola proyek yang menuntut tingkat kepatuhan dan validasi yang sangat tinggi saat mengimplementasikan produk baru ke industri yang sangat diatur. Karena itu, sebagian besar proyek saya direncanakan dan dikendalikan menggunakan metode tradisional.

Namun, ada bagian kecerdasan bisnis dari proyek ini, saat perusahaan saya menambang sejumlah besar data performa yang dihasilkan sistem; bagian ini paling baik didukung dengan pendekatan agile. Untuk komponen BI dalam proyek (yang berjalan paralel dengan pekerjaan tradisional), kami akan memilih cerita berprioritas tertinggi yang dapat diselesaikan dalam sprint tiga minggu, lalu menyelesaikan satu iterasi.

Karena banyak cerita ini bersifat eksploratif, kami sering membuat cerita baru untuk eksplorasi lebih lanjut atau membuat laporan performa tertentu. Semua ini cukup ditambahkan ke backlog untuk dipertimbangkan pada sprint berikutnya.

Dengan pendekatan ini, saya memiliki satu jadwal proyek yang memastikan saya mencapai semua langkah pelaporan dan regulasi yang diperlukan, sambil tetap memungkinkan pendekatan yang sangat fleksibel untuk mengembangkan komponen pelaporan bisnis yang tidak diatur dalam proyek.

Memiliki semua pekerjaan dalam satu jadwal memberikan satu sudut pandang terhadap semua yang terjadi di proyek ini:

Informasi yang saya perlukan untuk mengelola alokasi sumber daya ke tugas yang paling sesuai (tradisional atau agile) langsung tersedia

Kemampuan untuk membuat laporan status mingguan dan bulanan yang andal sudah tersedia

Agile adalah pendekatan penyampaian proyek yang sangat kuat dan seharusnya memberikan manfaat signifikan bagi toolkit penyampaian proyek organisasi Anda secara keseluruhan. Pendekatan ini dapat digunakan sebagai solusi mandiri, sebagai bagian dari pendekatan penyampaian bertahap, atau diintegrasikan ke dalam struktur penyampaian hibrida.

Kuncinya adalah mengadopsi prinsip-prinsip agile yang akan membantu organisasi Anda mencapai keberhasilan penyampaian sambil tetap mengikuti proses tradisional yang telah membantu organisasi Anda sukses hingga saat ini.

Steve Caseley memiliki pengalaman lebih dari 35 tahun di Microsoft Project dan telah menjadi pengguna aktif Microsoft Project sejak rilis pertamanya. Dia adalah editor beberapa buku tentang Microsoft Project dan praktik terbaik manajemen proyek. Dia adalah Konsultan Utama di Sensei Project Solutions, tempat ia membantu organisasi besar mencapai keunggulan dalam pelaksanaan proyek menggunakan rangkaian alat Microsoft Project Portfolio Management (PPM).

PRODUK TERKAIT
Office 365

Mulai menggunakan Microsoft 365

Office ini sama seperti yang Anda kenal, dengan alat yang mengoptimalkan kerja sama sehingga Anda dapat menyelesaikan lebih banyak pekerjaan kapan pun, di mana pun.

Beli Sekarang

Konten terkait

Kelola bisnis saya

Mengapa eksekutif membenci manajer proyek?

Baca selengkapnya

Ide dan Wawasan Bisnis bukan konsultan pajak atau keuangan profesional. Hubungi profesional pajak atau keuangan Anda untuk mendiskusikan situasi Anda.