7 Faktor Untuk Jaminan Kegagalan

Jangan menghargai karyawan, meremehkan kerumitan, atau mengandalkan mitos. Jika ini dan faktor lainnya diperhitungkan, proyek Anda dijamin gagal.

Apakah kamu tahu itu? Selama berminggu-minggu dan berbulan-bulan, manajer proyek melaporkan proyeknya. Tentu saja, lampu status klasik tidak boleh ketinggalan. Dan ini selalu hijau: semuanya baik-baik saja. Tapi suatu hari lampu lalu lintas tiba-tiba berubah menjadi merah! Akibatnya, proses pemrosesan yang sangat tidak menyenangkan dimulai bagi mereka yang bertanggung jawab. Sebagian besar waktu pertanyaan pertama berlaku untuk pelakunya, penyebab kedua, dan kemudian satu hanya dikhususkan untuk solusi yang mungkin.

Di bawah ini adalah 7 faktor tipikal yang hampir menjamin kegagalan.

Faktor 1: mengabaikan faktor manusia

Selama bertahun-tahun sebagai pengembang, manajer proyek, pelatih, dan manajer krisis, saya menemukan bahwa ketegangan antarpribadi adalah hambatan terbesar untuk mengimplementasikan proyek TI. Sebaliknya, chemistry antar karyawan benar dan ada iklim yang terbuka dan toleran terhadap kesalahan, solusi dapat ditemukan untuk semua kesulitan – bahkan dalam situasi kritis.

Sudah menjadi sifat manusia untuk menghindari konflik. Jadi wajar jika orang (misalnya manajer proyek) benar-benar mengabaikan atau berpaling terlalu lama. Tetapi konflik biasanya tidak larut dengan sendirinya. Diperlukan penelitian, sebagai moderasi dan setidaknya perspektif tentang perubahan atau solusi.

Terkadang hal-hal kecil yang berdampak besar, seperti pekerjaan baru bagi seorang karyawan. Namun, biaya yang lebih besar seringkali diperlukan, seperti reorganisasi tim, untuk mengembalikan kedamaian proyek. Namun, alternatif terburuk adalah mengabaikan faktor manusia.

Faktor 2: Berpikir terlalu besar atau membuat terlalu kecil

Beberapa perusahaan mengambil alih sebuah proyek. Mereka meremehkan kerumitan, risiko, dan upaya personel dan material yang sangat besar. Apakah – terlepas dari biayanya – organisasi saya mampu mengelola proyek dengan 100 karyawan? Apakah kita memiliki cukup pekerjaan, ruang pertemuan, kapasitas jaringan, server pengembangan, dll.?

Apakah perusahaan mampu memenuhi persyaratan tim pengembangan gesit yang besar untuk jalur pengembangan dan pengujian termasuk Integrasi/Pengiriman Berkelanjutan? Memprediksi pertanyaan seperti itu, kasus bisnis seharusnya dihitung secara realistis. Saya telah melihat beberapa kali bahwa hanya menjadi jelas sesaat sebelum dimulainya proyek raksasa bahwa sistem yang dihasilkan sebenarnya tidak diperlukan karena tidak sesuai dengan model bisnis perusahaan. Sayangnya, tidak ada yang menyadarinya sebelumnya.

Pola lain yang dapat dikenali: Seorang protagonis benar-benar ingin mewujudkan SW, misalnya untuk alasan prestise atau untuk memanfaatkan karyawan, dan menghitung biayanya dapat diabaikan. Jika manajer proyek nantinya tidak cukup kuat untuk menyajikan perbedaan dalam konteks badan pembuat keputusan, ini menciptakan potensi krisis yang tinggi.

Faktor 3: andalkan perkiraan dan perencanaan 100%

Mitos yang tersebar luas adalah keandalan estimasi dan perencanaan. Konsep proyek ditentukan oleh keunikannya. Mungkin sudah ada proyek serupa, tetapi pada prinsipnya, perusahaan memasuki wilayah baru dengan setiap proyek. Ini berarti perkiraan hanya bisa sebaik pengalaman pencipta dan keterampilan adaptasi mereka terkait proyek saat ini.

Namun, rencana tidak pernah dapat mencakup kejadian spontan, perubahan persyaratan, teknologi, atau masuknya risiko yang tidak terduga. Pada akhirnya, estimasi dan rencana yang didasarkan padanya tidak lebih dari taruhan untuk masa depan! Menerima fakta ini adalah langkah pertama ke depan. Disiplin, keberanian, dan sistem membantu mencegah atau meredakan kemungkinan krisis.

Faktor 4: Segitiga PM ajaib selalu diabaikan

Belajar ilmu komputer, semester pertama, kuliah pertama manajemen proyek: "The magical PM triangle" . Orang yang tertarik dengan tugas manajemen diperkenalkan dengan hukum segitiga ini sejak dini. Ini mengatakan bahwa perubahan dalam salah satu dari tiga parameter pasti mengarah pada konsekuensi dari setidaknya satu dari parameter lainnya.

Namun, undang-undang ini terlalu senang untuk diabaikan dalam praktiknya. Seperti yang telah disebutkan dalam konteks perkiraan dan perencanaan, sebuah proyek agak unik dan kemungkinan pengaruh yang tidak direncanakan sangat tinggi. Itulah mengapa cepat atau lambat di hampir setiap proyek, mereka yang bertanggung jawab harus bereaksi terhadap pengaruh ini. Namun, jika semua parameter sudah diperbaiki, yakni pelanggan terus menuntut pemenuhan waktu, anggaran, dan isi, kegagalan hanya tinggal menunggu waktu saja.

Faktor 5: Dokumentasi segalanya

Gratis setelah Franz Beckenbauer: "Kami menyebutnya klasik!" Meskipun semakin banyak perusahaan mengandalkan prosedur tangkas (kebanyakan scrum), organisasi dan proyek masih ditemukan, yang memberikan dokumentasi ekstensif lebih penting daripada perangkat lunak yang akan dibuat. Ini adalah risiko tinggi, terutama dalam proyek-proyek besar. Seringkali perburuan dari konsultan dan ahli departemen pada ribuan halaman sering bekerja selama berbulan-bulan atau bahkan bertahun-tahun, yang nantinya akan diterjemahkan oleh tim lain di SW.

Semakin luas dokumentasinya, semakin lama waktu realisasinya dan semakin kecil kemungkinan SW sesuai dengan kebutuhan aktual pengguna. Reaksi terhadap perubahan di pasar tidak mungkin atau hanya mungkin dilakukan dengan usaha keras dan konsesi sementara. Dokumen menawarkan dasar untuk menghapus produk. Sayangnya, apa yang tertulis belum tentu jelas dan hasilnya berbeda dengan pemikiran semula. Berapa kali saya mendengar kalimat dari staf departemen dan pengguna akhir: "Oh, saya membayangkannya sangat berbeda!" .

Faktor 6: Tidak ada organisasi proyek yang seimbang

Sebuah tim yang terdiri dari 20 pengembang dan 1 kontak teknis? Tidak perlu pengetahuan ahli untuk menyadari bahwa konstruk ini cepat atau lambat akan gagal. Di awal proyek, apakah air terjun atau gesit, mungkin masih berfungsi karena pengembang sibuk dengan kerangka kerja atau menyiapkan lingkungan. Tetapi segera karyawan akan mengajukan pertanyaan – membutuhkan dukungan profesional yang intensif.

Seorang ahli subjek tunggal tidak akan pernah bisa menahan tekanan temporal dan emosional ini dan membutuhkan dukungan, baik dari segi personel maupun melalui proses implementasi. Namun, merupakan ide yang sangat buruk untuk mengatasi hambatan personel dengan pembatasan komunikasi.

Juga ide yang populer dan sangat terdepan dalam skala kesalahan manajemen yang khas: seorang karyawan mengumpulkan pertanyaan dari pengembang, mendiskusikannya dengan penghubung teknis, dan mengembalikan jawabannya. Dengan cara ini, Anda menciptakan kemacetan par excellence, memicu tingkat kesalahan yang sangat tinggi, dan menunda pengembangan secara signifikan.

Faktor 7: Panaskan katak secara perlahan

Apakah Anda tahu cerita ini? Jika Anda memasukkan katak ke dalam panci berisi air dan terus memanaskannya hingga matang, katak tidak akan berusaha melarikan diri. Jika Anda membuangnya langsung ke air panas, ia langsung melompat keluar.

Salah satu pengetahuan terpenting saya dalam beberapa tahun terakhir adalah bahwa karyawan proyek TI berakhir dengan meningkatnya durasi kebutaan. Proses yang sudah mapan mungkin dipertanyakan dalam retrospektif, tetapi jarang benar-benar drastis. Kemampuan orang untuk bereaksi terhadap perubahan menghilang secara proporsional dengan durasi proyek.

Oleh karena itu, pencahayaan sporadis (Pemeriksaan Kesehatan) direkomendasikan oleh proyek (besar) oleh konsultan eksternal yang sebelumnya tidak terlibat untuk menemukan kebocoran, jalur yang berpotensi tidak ditargetkan. Paling lambat setelah mengenali krisis besar-besaran, hampir tidak mungkin untuk membuat perubahan haluan hanya dengan staf yang ada.

Jadi itu mungkin

Kesalahan manajemen tipikal yang dijelaskan hanyalah sebagian kecil dari daftar pola perilaku pribadi saya, yang mencegah atau bahkan mencegah keberhasilan penyelesaian proyek pengembangan SW. Dari kejauhan, kesan bahwa mudah untuk mengenali masalah dan memperbaikinya pada tahap awal proyek dapat muncul. Namun kondisi kerangka kerja yang konon tidak dapat digerakkan dan kebutaan yang disebutkan seringkali membuat sulit untuk membuat keputusan yang tepat. Statistik Grup Standish mengatakan pada awalnya menunjukkan tahun ini demi tahun.

Jika sebuah proyek bermasalah, sangat disarankan agar manajer krisis eksternal dapat menganalisis dan bertindak secara objektif, bebas dari kepekaan dan tanpa pemberat sejarah proyek. Satu-satunya partisipasi seorang ahli yang mendengarkan orang-orang dalam proyek tersebut sudah dapat menimbulkan efek positif. Pemilihan tindakan yang sesuai juga berhasil dalam transformasi dan akhirnya perputaran.