IT Project Management
Manajemen proyek TI berada dalam posisi yang tidak nyaman di antara dua tradisi: pendekatan berbasis rencana yang mengeksekusi desain yang sudah diketahui terhadap jadwal dan anggaran yang tetap, dan pendekatan adaptif yang memperlakukan proyek sebagai pencarian jawaban yang tepat sementara kebutuhannya masih ditemukan. Sebagian besar organisasi memilih sebuah label, memberlakukan sebuah seremoni, dan membiarkan pertanyaan sesungguhnya tidak terjawab. Artikel ini berargumen bahwa penyampaian yang dapat diprediksi tidak berasal dari fanatisme metode, melainkan dari pembacaan yang jujur atas ketidakpastian, dan bahwa sebuah proyek hanya berhasil ketika perangkat lunak yang berfungsi menyampaikan nilai yang menjadi alasan investasi tersebut.
Mengapa penyampaian terus gagal menjadi dapat diprediksi
Keluhan yang terus-menerus tentang proyek TI bukanlah bahwa proyek tersebut gagal total, meskipun sebagian memang demikian. Keluhannya adalah bahwa proyek tersebut gagal menjadi dapat diprediksi. Sebuah program yang selesai enam bulan terlambat dan empat puluh persen melebihi anggaran memang merugikan, tetapi sebuah portofolio yang di dalamnya proyek mana pun mungkin selesai tepat waktu atau mungkin molor satu tahun, tanpa cara yang andal untuk mengetahui yang mana sebelumnya, bersifat merusak dengan cara yang berbeda. Hal itu membuat perencanaan di tingkat bisnis menjadi mustahil. Hal itu mengajari para eksekutif untuk melebih-lebihkan setiap estimasi dan meragukan setiap komitmen, yang pada gilirannya mengajari tim penyampaian bahwa estimasi hanyalah sandiwara. Seluruh sistem melayang menuju keseimbangan bertingkat kepercayaan rendah di mana tidak ada yang percaya pada rencana dan setiap orang melindungi dirinya sendiri.
Hal ini lebih penting sekarang dibandingkan satu dekade lalu karena satu alasan tertentu. Perubahan TI bukan lagi sebuah peristiwa terpisah yang sesekali diserap oleh bisnis. Perubahan itu bersifat berkelanjutan, dan terjalin dengan pendapatan, regulasi, dan pengalaman pelanggan dengan cara yang menyisakan sedikit kelonggaran. Ketika sebuah migrasi perbankan inti molor, atau sebuah konsolidasi ERP mandek, konsekuensinya tidak terbatas pada satu baris anggaran TI. Konsekuensi itu merembet ke komitmen komersial, tenggat kepatuhan, dan kredibilitas kepemimpinan yang mensponsori pekerjaan tersebut. Biaya ketidakpastian telah meningkat bahkan di tempat biaya kegagalan individu tidak meningkat.
Kebenaran yang tidak nyaman adalah bahwa sebagian besar ketidakpastian diciptakan pada awalnya, sebelum satu baris kode ditulis atau satu server disediakan. Ketidakpastian itu diciptakan dengan memperlakukan estimasi sebagai negosiasi, dengan berkomitmen pada lingkup yang tidak pernah benar-benar dipahami, dan dengan mengadopsi pendekatan penyampaian yang dipilih demi kenyamanan budaya alih-alih demi karakter sesungguhnya dari pekerjaan tersebut. Kemampuan untuk diprediksi sebagian besar ditentukan oleh keputusan yang dibuat ketika proyek masih murah untuk dibentuk. Di situlah disiplin harus dimulai.
Prinsip dasar: menyelaraskan metode dengan bentuk ketidakpastian
Keputusan mendasar dalam setiap proyek TI bukanlah kerangka kerja mana yang akan diadopsi. Melainkan sebuah diagnosis tentang di mana ketidakpastian itu berada. Secara umum, ketidakpastian dalam penyampaian datang dalam dua bentuk, dan keduanya menuntut respons yang berlawanan. Yang pertama adalah ketidakpastian pelaksanaan: kita tahu persis apa yang perlu dibangun, tetapi membangunnya bersifat besar, kompleks, atau berisiko. Yang kedua adalah ketidakpastian kebutuhan: kita bisa membangunnya dengan kompeten seandainya kita tahu apa itu, tetapi jawaban yang tepat baru akan menjadi jelas melalui umpan balik dari penggunaan nyata. Mencampuradukkan keduanya adalah asal-usul sebagian besar kegagalan terkait metode.
Ketika ketidakpastian yang dominan adalah ketidakpastian pelaksanaan dan kebutuhannya benar-benar stabil, penyampaian berbasis rencana bukanlah peninggalan yang perlu diminta maaf. Itu adalah alat yang tepat. Sebuah migrasi pusat data, perubahan pelaporan regulasi dengan spesifikasi hukum yang tetap, atau peluncuran paket yang sudah dipahami dengan baik ke lokasi-lokasi baru semuanya memiliki lingkup yang dapat diketahui dan sangat diuntungkan dari pengurutan awal yang rinci, pemetaan ketergantungan, dan manajemen jalur kritis. Berpura-pura pekerjaan semacam itu adalah sebuah petualangan penemuan justru menyia-nyiakan satu keunggulan yang ditawarkannya, yaitu kemampuan untuk merencanakannya dengan benar.
Ketika ketidakpastian yang dominan adalah ketidakpastian kebutuhan, pendekatan berbasis rencana menjadi berbahaya secara aktif, karena memaksa komitmen prematur pada keputusan yang seharusnya tetap terbuka. Di sinilah penyampaian adaptif menemukan tempatnya: siklus pendek, peningkatan yang berfungsi, dan kontak yang sering dengan pengguna nyata mengubah hal yang tidak diketahui menjadi diketahui pada laju berkelanjutan yang tercepat. Tujuan dari iterasi bukanlah kecepatan demi kecepatan itu sendiri. Melainkan penghapusan sistematis atas risiko kebutuhan. Sebuah tim yang beriterasi tetapi tidak pernah menghadapkan peningkatannya dengan umpan balik pengguna yang sesungguhnya telah mengadopsi seremoni tanpa mekanismenya, dan tidak memperoleh apa-apa.
Posisi yang jujur, dan yang diperjuangkan artikel ini, adalah bahwa sebagian besar program besar mengandung kedua jenis ketidakpastian dalam proporsi yang berbeda di seluruh komponennya. Penilaian yang matang bukanlah menyatakan keseluruhannya agile atau waterfall, melainkan menguraikannya, menerapkan ketelitian berbasis rencana ketika lingkupnya stabil dan penemuan adaptif ketika tidak, serta mengelola sambungan di antara keduanya secara sengaja. Sambungan itulah tempat keterampilan sesungguhnya berada.
Apa yang sebenarnya berubah dalam disiplin ini
Beberapa perkembangan telah membentuk ulang manajemen proyek TI dalam beberapa tahun terakhir, dan patut memisahkan yang substantif dari yang sekadar mode. Yang paling substantif adalah pergeseran dari pemikiran proyek ke pemikiran produk pada bagian-bagian lanskap TI yang berumur panjang. Sebuah platform pembayaran atau portal pelanggan bukanlah proyek yang selesai; ia adalah produk yang bertahan, didanai secara berkelanjutan dan dimiliki oleh tim yang stabil. Untuk kelas pekerjaan itu, konstruksi proyek dengan tanggal akhir yang tetap dan pembubaran tim saat penyelesaiannya telah menjadi kewajiban yang membebani, karena mengoptimalkan serah terima alih-alih kepemilikan berkelanjutan yang menjaga perangkat lunak tetap sehat.
Pada saat yang sama, dan agak bertentangan dengan gerakan produk, disiplin mengelola ketergantungan dalam skala besar telah diformalkan. Ketika organisasi menjalankan puluhan tim terhadap arsitektur bersama, kendala yang mengikat penyampaian jarang berupa produktivitas tim tunggal mana pun. Melainkan biaya koordinasi di antara mereka: layanan bersama, pengurutan integrasi, kapabilitas platform yang menjadi sandaran banyak aliran kerja. Kerangka kerja penyampaian berskala, pada inti bergunanya, adalah upaya untuk membuat ketergantungan lintas tim ini terlihat dan menjadwalkannya sebelum menjadi alasan semua orang terhambat.
Perubahan ketiga adalah pematangan continuous delivery dan otomatisasi jalur menuju produksi. Ketika menerapkan sebuah perubahan merupakan peristiwa yang langka, manual, dan berisiko tinggi, ekonominya mendorong ke arah batch besar dan siklus rilis yang panjang, yang pada gilirannya mendorong ke arah perencanaan awal yang berat. Ketika penerapan diotomatisasi, diuji, dan menjadi rutin, peningkatan-peningkatan kecil menjadi murah untuk dirilis, dan seluruh ritme penyampaian dapat bergeser ke arah umpan balik yang sering yang menjadi sandaran pekerjaan adaptif. Sebagian besar dari apa yang dianggap berasal dari metodologi sebenarnya adalah hilir dari kapabilitas rekayasa ini. Sebuah tim tidak dapat beriterasi secara bermakna menuju nilai jika hanya bisa merilis dua kali setahun, terlepas dari kerangka kerja mana pun yang tertulis di dinding.
Arsitektur dan desain yang membuat penyampaian dapat diprediksi
Penyampaian yang dapat diprediksi sama-sama merupakan properti dari bagaimana pekerjaan disusun maupun bagaimana pekerjaan dikelola. Tuas tunggal yang paling ampuh adalah penguraian menjadi peningkatan-peningkatan yang masing-masing menyampaikan sesuatu yang dapat didemonstrasikan dan, idealnya, sesuatu yang dapat digunakan. Ini bukan sekadar kepatutan administrasi proyek. Sebuah peningkatan yang menghasilkan perangkat lunak yang berfungsi memaksa pertanyaan integrasi dan pengujian untuk dijawab lebih awal dan berulang kali, alih-alih ditunda ke fase akhir tempat pertanyaan-pertanyaan itu meledak sekaligus. Kegagalan klasik integrasi big-bang, di mana komponen-komponen yang dibangun terpisah selama berbulan-bulan digabungkan pada akhirnya dan diketahui tidak cocok, adalah kegagalan desain peningkatan sebelum menjadi kegagalan manajemen.
Arsitektur ketergantungan adalah prinsip kedua. Setiap ketergantungan antara tim, sistem, atau vendor merupakan kendala penjadwalan sekaligus risiko. Desain penyampaian yang baik berupaya meminimalkan dan mengurutkannya secara sengaja: mengidentifikasi komponen mana yang berada di jalur kritis, kapabilitas bersama mana yang harus ada sebelum pekerjaan yang bergantung dapat dimulai, dan komitmen eksternal mana, seperti hasil kerja vendor atau persetujuan regulasi, yang berada di luar kendali tim dan karenanya memerlukan perhatian paling awal dan penyangga paling konservatif. Ketergantungan yang ditemukan terlambat adalah jenis yang paling mahal, karena pada saat muncul ke permukaan, opsi untuk menyelesaikannya telah menyempit.
Prinsip ketiga adalah merancang untuk keterbalikan ketika kebutuhannya tidak pasti dan untuk ketahanan ketika kebutuhannya sudah mapan. Keputusan yang murah untuk dibalik dapat dibuat dengan cepat dan direvisi berdasarkan umpan balik; keputusan yang mahal untuk dibalik, seperti model data di jantung sistem atau pilihan platform yang menjadi sandaran segala hal lainnya, layak mendapat penelitian yang tidak sebanding besarnya sebelum dikunci. Sebuah proyek yang dijalankan dengan baik menghabiskan analisis cermatnya di tempat pembalikan itu mahal dan bergerak cepat di tempat pembalikan itu tidak mahal, alih-alih menerapkan seremoni yang seragam pada setiap pilihan. Mencampuradukkan keduanya, bimbang atas hal yang sepele sambil tergesa-gesa pada hal yang tidak dapat dibalik, adalah penyebab kesulitan yang umum dan tenang.
Pola-pola kegagalan yang berulang
Perluasan lingkup yang berkedok fleksibilitas. Penyampaian adaptif sering disalahgunakan sebagai izin untuk tidak pernah menetapkan lingkup sama sekali. Iterasi yang sejati menyempurnakan solusi menuju tujuan yang stabil; perubahan yang tidak disiplin menggantikan satu tujuan dengan tujuan lain setiap beberapa minggu dan menyebutnya sebagai daya tanggap. Pembedanya adalah apakah perubahan-perubahan itu menyatu. Sebuah proyek di mana setiap siklus membawa hasil lebih dekat ke sasaran yang koheren sedang belajar. Sebuah proyek di mana setiap siklus menambah sasaran baru bukanlah mengelola lingkup, melainkan meninggalkannya, dan tidak akan selesai.
Laporan status semangka. Hijau di luar, merah di dalam. Ini adalah produk alami dari menilai proyek berdasarkan tonggak yang terlewati alih-alih perangkat lunak yang berfungsi dan nilai yang terealisasi. Ketika metriknya adalah persentase tugas yang selesai, sebuah tim dapat melaporkan sembilan puluh persen selama berbulan-bulan sementara sepuluh persen yang sulit, mengintegrasikan, dan bernilai tetap tidak tersentuh. Obatnya bukanlah disiplin pelaporan yang lebih baik. Melainkan mengubah apa yang diukur, sehingga kemajuan berarti peningkatan yang dapat didemonstrasikan, diuji, dan dapat digunakan, alih-alih aktivitas terhadap sebuah rencana.
Penyangkalan ketergantungan. Tim merencanakan pekerjaan mereka sendiri dengan cermat dan memperlakukan segala hal di luar batas mereka sebagai masalah orang lain yang akan selesai dengan sendirinya sesuai jadwal. Hal itu jarang terjadi. Ketergantungan yang tidak dimiliki sebuah proyek justru adalah yang paling mungkin molor, dan yang paling tidak mampu dipercepat oleh sebuah tim ketika hal itu terjadi. Membuat ketergantungan eksternal menjadi eksplisit, menetapkan pemiliknya, dan menyangganya secara realistis adalah pekerjaan yang tidak menawan yang memisahkan program yang mempertahankan tanggalnya dari yang tidak.
Ambiguitas pemangku kepentingan. Banyak proyek berjalan selama berbulan-bulan tanpa jawaban jelas atas siapa yang sebenarnya memutuskan. Ketika sponsor, pengguna, dan pemberi dana menginginkan hal yang sedikit berbeda dan tidak ada satu pun pemilik yang bertanggung jawab untuk mendamaikannya, proyek menyerap konflik itu sebagai gejolak, mengungkit ulang keputusan yang telah selesai dan tidak menyenangkan siapa pun. Kejelasan tentang siapa yang memiliki hasil, siapa yang harus dikonsultasikan, dan siapa yang sekadar diberi tahu bukanlah birokrasi. Melainkan mekanisme yang memungkinkan sebuah proyek benar-benar membuat keputusan dan mempertahankannya.
Estimasi sebagai komitmen. Sebuah estimasi adalah pernyataan probabilistik tentang masa depan yang tidak pasti. Saat estimasi diperlakukan sebagai janji, ia berhenti menjadi jujur, karena estimasi paling aman untuk dijanjikan adalah yang dilebih-lebihkan, dan pelebih-lebihan itu menghancurkan informasi yang seharusnya dibawa oleh estimasi tersebut. Penyampaian yang sehat memisahkan estimasi dari komitmen: estimasi menginformasikan perencanaan secara terus terang, dan komitmen dibuat secara sengaja, dengan ketidakpastian yang diakui alih-alih dinegosiasikan hingga hilang.
Bagaimana Nashua bekerja pada penyampaian proyek TI
Pendekatan Nashua terhadap manajemen proyek TI dimulai dari diagnosis alih-alih metode. Sebelum merekomendasikan model penyampaian apa pun, kami berupaya menetapkan di mana ketidakpastian dalam sebuah program tertentu sebenarnya berada, komponen demi komponen, karena pembacaan itu menentukan segala hal di hilir. Ini adalah pekerjaan yang sengaja tidak mengikuti mode. Pekerjaan ini menolak dorongan untuk menyatakan satu metodologi tunggal untuk keseluruhan lanskap dan sebaliknya menerima bahwa sebuah program mungkin membutuhkan ketelitian berbasis rencana untuk intinya yang stabil dan padat ketergantungan serta penemuan adaptif untuk bagian-bagian di mana kebutuhannya masih dipelajari. Kami mengelola sambungan di antara mode-mode itu sebagai perhatian utama alih-alih sebagai renungan belakangan.
Dalam pelaksanaan, kami berpegang pada sejumlah kecil disiplin yang tidak dapat ditawar. Peningkatan dirancang untuk menghasilkan perangkat lunak yang berfungsi dan teruji secara dini dan sering, sehingga risiko integrasi dihadapi secara berkelanjutan alih-alih ditunda. Ketergantungan, terutama yang berada di luar kendali tim, dibuat eksplisit, dimiliki, dan disangga sejak awal. Lingkup dikelola terhadap sasaran yang koheren, dengan perubahan disambut ketika menyatu pada sasaran itu dan ditantang ketika sekadar memperbesarnya. Dan kami menjaga estimasi tetap jujur dengan memisahkannya dari komitmen, sehingga rencana membawa informasi yang sesungguhnya alih-alih pelebih-lebihan defensif. Yang terpenting, kami menilai kemajuan berdasarkan perangkat lunak yang berfungsi dan dapat didemonstrasikan serta bukti nilai yang terealisasi, bukan berdasarkan jumlah tonggak yang terlewati, karena yang kedua mudah dipalsukan dan yang pertama tidak.
Kami juga menganggap serius arsitektur manusia dari sebuah proyek: menetapkan siapa yang memiliki hasil, siapa yang memutuskan, dan bagaimana keputusan-keputusan itu dipertahankan. Sebagian besar dari apa yang tampak sebagai kegagalan penyampaian sebenarnya adalah ambiguitas pemangku kepentingan yang belum terselesaikan yang terekspresikan sebagai gejolak, dan kami memperlakukan penjernihan akuntabilitas sebagai pekerjaan penyampaian tingkat pertama alih-alih sebagai beban tata kelola yang harus diminimalkan.
Di mana Nashua membuat perbedaan
Perbedaan yang dibawa Nashua bukanlah metode berpemilik yang menjanjikan lenyapnya ketidakpastian. Metode semacam itu tidak ada, dan firma yang mengklaim sebaliknya menjual kenyamanan alih-alih penyampaian. Perbedaannya adalah penilaian yang diterapkan secara konsisten: kesediaan untuk mendiagnosis secara jujur, untuk memilih penyampaian berbasis rencana dan adaptif atas dasar kelayakannya alih-alih mode, untuk membuat ketergantungan dan akuntabilitas terlihat sebelum menjadi alasan, dan untuk menegaskan sepanjang jalan bahwa sebuah proyek bernilai sebesar apa yang ia serahkan ke tangan pengguna dan realisasikan sebagai nilai, bukan sebesar apa yang ia laporkan terhadap sebuah rencana. Penilaian itu adalah buah dari telah menyampaikan cukup banyak program untuk mengetahui di mana program-program itu sebenarnya keliru.
Ada pula konsekuensi praktis yang mengubah apa yang boleh diasumsikan oleh pekerjaan. Ketika sebuah penugasan memerlukan kapabilitas yang belum ada, penugasan itu tidak perlu menunggu siklus pengadaan atau peta jalan vendor. enterprise platform dibangun untuk mengakomodasi hampir semua fitur dengan cepat, melalui agentic engineering yang ekstrem: apa yang dibutuhkan dideskripsikan dalam bahasa yang sederhana dan dihasilkan dengan cepat, tetapi selalu dalam prinsip arsitektur yang kokoh dan di bawah jaminan mutu yang ketat, sehingga kecepatan tidak pernah datang dengan mengorbankan koherensi, keamanan, atau kendali. Efeknya bersifat strategis alih-alih sekadar praktis. Efek itu menggeser garis buat-atau-beli, menjaga opsionalitas tetap murah, dan membiarkan arsitektur mengikuti strategi alih-alih strategi menekuk pada apa pun yang kebetulan tersedia di rak.
Yang mengikat semua ini adalah penolakan untuk membiarkan penyampaian menjadi sandiwara. Menjalankan sebuah proyek yang tampak dikelola dengan baik, menghasilkan pelaporan yang meyakinkan, dan memuaskan setiap pos pemeriksaan tata kelola sementara diam-diam gagal menghasilkan apa pun yang bernilai adalah hal yang mudah. Menjalankan proyek yang tetap jujur tentang ketidakpastiannya, menghadapi risikonya lebih awal, menjaga lingkupnya tetap menyatu, dan mengukur dirinya terhadap hasil yang berfungsi adalah jauh lebih sulit, dan jauh lebih langka. Jalan yang lebih sulit itulah yang menjadi komitmen Nashua, karena itu satu-satunya jalan yang membuat perubahan TI benar-benar dapat diprediksi alih-alih sekadar terdokumentasi dengan baik. Organisasi yang bekerja dengan kami akhirnya mengandalkan bukan janji bahwa tidak akan ada yang salah, melainkan keyakinan bahwa ketika sesuatu memang salah, hal itu akan terlihat lebih awal, dinamai dengan jelas, dan ditangani selagi masih murah untuk diperbaiki.
