PENYELAMATAN/PENYELESAIAN PROYEK YANG DALAM MASALAH

Secara kenyataan dalam mengolah proyek aplikasi IT sering terjadi kesulitan/masalah. Beberapa issue yang sering dihadapi team proyek: 1. Harus dilakukan beberapa langkah untuk mengarahkan proyek sesuai tujuan secepat mungkin. 2. Tekanan yang meningkat seiring dengan batas waktu proyek, oleh karena itu ada keinginan untuk menyelesaikan proyek secepat mungkin sehingga mengabaikan fungsi dan fiture (esensi) dari proyek tersebut. 3. Proyek mungkin akan dibagi beberapa tahap, untuk diselesaikan tepat waktu. Dalam penerapannya salah satu atau lebih bagian belum bisa di laksanakan dan yang lain akan tertunda. 4. Organisasi banyak membuat pengaruh negative yang akan mempengaruhi kualitas proyek. Salah satu contohnya: Mengurangi proses pengujian dan prosedur yang diperlukan untuk memastikan kualitas tinggi. Mencoba untuk menghindari kontrol kualitas proyek yang normal. Tim mungkin akan mencoba untuk menghindari kepatuhan yang ketat dengan standar pembangunan, dengan alasan bahwa mereka sekarang terlalu memakan waktu dan akan menunda kemajuan proyek. Meninggalkan proses proyek dokumentasi, mengklaim tidak ada waktu untuk melakukan pekerjaan itu karena proyek harus memenuhi batas waktu tersebut. Di luar isu yang terkait dengan mengakui masalah yang terlambat dalam siklus pengembangan, pertimbangan politik akan muncul. Akan ada upaya untuk menghindari penyebab kegagalan proyek. Mengingat tim proyek sudah tingkat stres yang tinggi, ini hanya akan menambah masalah dan tidak mencapai apa-apa dan membuat orang enggan untuk mengidentifikasi dan menyajikan masalah yang terkait dengan proyek yang akan membahayakan karier mereka. Hal ini jauh lebih baik untuk mengarahkan waktu dan energi untuk menempatkan untuk memperbaiki proyek. Kemudian, setelah proyek tersebut telah diselamatkan, tim dapat menghabiskan waktu dalam menilai penyebab masalah dan mengambil tindakan korektif.

BIAYA SOLUSI CEPAT Tim proyek membuat kesalahan serius ketika menurunkan kualitas proyek dalam upaya untuk membuat waktu yang hilang. Meskipun proyek ini di belakang jadwal dan harus diselesaikan secepat mungkin, mengambil jalan pintas dengan hasil yang berkualitas adalah keuntungan jangka pendek dengan mengorbankan kerugian jangka panjang. Terlalu sering, ketika sebuah proyek ditentukan akan menghadapi kesulitan, tim bergerak ke serangkaian solusi "perbaikan cepat". Ketika pengembang menyerah pada tekanan untuk memenuhi deadline proyek, mereka akan mencoba sesuatu yang muncul untuk menawarkan beberapa jenis

perbaikan. Biasanya, menerapkan "perbaikan" dalam cara yang tidak terkendali, tanpa memikirkan semua masalah, hanya membuat hal-hal buruk, dan itu menjadi lebih sulit untuk memperbaiki masalah proyek dasar. Satu-satunya cara untuk menyelamatkan sebuah proyek bermasalah mungkin untuk bekerja di sekitar praktek pengembangan proyek yang normal. Namun, akan ada biaya. Akan ada kecenderungan untuk terburu-buru dengan perubahan dan penyesuaian sebelum tim memiliki pemahaman yang jelas tentang penyebab masalah. Organisasi mungkin akan melihat banyaknya pekerja sebagai salah satu penyebab kesulitan karena itu mungkin menambahkan lebih banyak orang untuk proyek. Namun, ukuran ini memerlukan waktu dan perhatian manajemen tambahan untuk berurusan dengan meningkatkan garis komunikasi proyek. Sementara membawa pada orang yang lebih berpengalaman mungkin menjadi pendekatan yang tepat, ini harus dilakukan secara hatihati dikendalikan. Sebelum menambahkan staf untuk proyek, decisionmaker harus memiliki gagasan yang jelas tentang mengapa orang perlu ditambahkan, dan peran yang tepat dan tanggung jawab mereka. Ada kemungkinan akan mendatangkan manajemen senior pada proyek bermasalah. Manajer senior dapat membantu menyelesaikan kendala proyek dan menyediakan tambahan sumber daya yang dibutuhkan. Namun, mereka mungkin memiliki sedikit pemahaman tentang isuisu, namun siap dengan solusi cepat.

Dalam berurusan dengan proyek-proyek IT yang bermasalah, jawaban mudah adalah menghindari situasi. Namun, manajer proyek IT yang berpengalaman tahu bahwa menjaga proyek keluar dari kesulitan ini sering di luar kontrol manajemen tim proyek. Dan, meskipun pendekatan yang paling pragmatis untuk manajemen proyek IT adalah untuk memberikan disiplin yang memadai dan kontrol proyek dari awal sehingga proyek tidak jatuh ke dalam kesulitan, masalah yang sedang dieksplorasi di sini adalah mengenali ketika sebuah proyek yang dalam kesulitan dan mengembangkan pendekatan yang akan membawa kembali proyek di trek. Banyak organisasi menyadari bahwa proyek ini akan jatuh ke dalam kesulitan di beberapa titik dalam siklus pengembangan. Ketika proyek IT tidak datang terpisah, tindakan harus diambil untuk mengembalikan mereka secepat dan seefisien mungkin. Kunci untuk berhasil memulihkan bermasalah proyek IT adalah untuk menentukan sedini mungkin dalam siklus pengembangan bahwa proyek ini mulai memburuk, dan kemudian bergerak cepat dan tegas untuk mengambil tindakan korektif, menilai dan menginstal proses koreksi dibutuhkan dalam disiplin dan dikendalikan dengan cara.

MENGAKUI KESULITAN PROYEK Aspek sulit berurusan dengan proyek IT gagal adalah mengakui bahwa proyek tersebut memang dalam kesulitan, ini terlalu sering adalah masalah emosional. Ketika orang baru saja mulai untuk mengenali kesulitan proyek, mereka akan membuat sedikit upaya untuk mengembangkan rencana untuk mengatasi masalah. Sebaliknya, mereka menyarankan bahwa waktu akan membantu memperbaiki masalah. Pendekatan ini sering berpijak pada asumsi yang salah. Pada

kenyataannya, manajemen tergantung pada keberuntungan, bukan faktual menilai status proyek. Setelah tim proyek mengakui bahwa proyek ini dalam kesulitan, dapat mulai bekerja pada memperbaiki masalah dan menyelamatkan proyek tersebut. Namun, pertama harus ada pemahaman yang jelas tentang penyebab masalah. Sayangnya, ketika proyek jatuh ke dalam kesulitan, orang cenderung untuk melompat ke solusi jelas tanpa memahami isu yang terlibat, hal ini hanya akan membuat masalah lebih buruk. Pendekatan yang lebih efektif adalah untuk menyelidiki apa yang salah dan mengembangkan solusi yang membahas masalah nyata. Sebuah tim yang bergegas untuk solusi tanpa jelas memahami penyebab kesulitan biasanya alamat gejala masalah, daripada masalah itu sendiri. Contohnya adalah ketika pengujian aplikasi menyingkap serangkaian kesulitan. Tim mungkin menganggap bahwa masalah berasal dari kode yang ditulis dengan buruk, yang muncul dalam pengujian. Pendekatan yang jelas untuk perbaikan adalah pergi melalui kode, menemukan kesalahan, dan membuat koreksi yang diperlukan. Namun, sementara kode tampaknya menjadi problem, pada kenyataannya, masalah yang bisa dikaitkan dengan proses pengujian didirikan. Dalam contoh ini, bergegas untuk mengulang kode tidak akan membantu, hanya akan membuat masalah lebih buruk. Dimana masalah ini dilihat sebagai pengkodean miskin, tim akan membuang-buang waktu dan upaya pada "mengoreksi" pengkodean cacat (yang, pada kenyataannya, tidak cacat sama sekali). Ketika tim menemukan bahwa pengkodean tidak menyebabkan masalah, pekerjaan koreksi harus mundur, dan kode diuji ulang berubah. Jadi, pindah ke solusi yang jelas namun tidak tepat untuk kemanfaatan adalah pendekatan yang salah untuk masalah ini.

Menstabilkan LINGKUNGAN Meskipun dimengerti bahwa orang ingin mengatasi masalah proyek secepat mungkin, tim harus meluangkan waktu untuk mengidentifikasi penyebab masalah yang sebenarnya, daripada melompat ke solusi cepat. Setelah penyebab telah diidentifikasi, tim harus memverifikasi bahwa sebab yang jelas memang apa yang perlu koreksi. Langkah terakhir dalam proses ini adalah mengembangkan rencana untuk membuat koreksi yang diperlukan. Sebuah langkah langsung dalam membawa proyek kembali ke jalur untuk sementara harus menghentikan atau membekukan semua pekerjaan proyek. Karena penyebab masalah tidak diketahui, melakukan pekerjaan apapun hanya akan menambah masalah proyek. Idenya adalah untuk mengandung kerusakan proyek sambil mencari solusi yang terbaik. Apa yang dapat proyek anggota lakukan sementara proyek beku? Tentu saja, beberapa anggota tim akan membantu menyelidiki dan memverifikasi penyebab kesulitan proyek dan membantu mengembangkan rencana perbaikan. Selain itu, beberapa daerah proyek dapat fine-tuned untuk sementara. Sebagai contoh, tim dapat meninjau dokumentasi, membawa up-to-date dan klarifikasi itu. Tim juga dapat meninjau rencana pengujian, baik teknis dan kasus bisnis, mengembangkan dan memperkuat mereka. Pengembang juga dapat memeriksa spesifikasi proyek dan persyaratan untuk menentukan apakah mereka masih benar, atau jika sesuatu yang

harus ditambahkan. Akhirnya, sebagai upaya terakhir, anggota tim proyek dapat sementara dialihkan ke pekerjaan lain dalam departemen IT. Khususnya dengan besar proyek-proyek IT, pembekuan proyek tidak dapat dilihat sebagai opsi yang layak karena ada begitu banyak anggota staf yang bekerja pada proyek. Manajer mungkin berpendapat bahwa setiap orang harus tetap sibuk atau orang-orang diambil dari proyek ini sementara akan hilang secara permanen untuk proyek. Dalam kasus tersebut, proyek kemungkinan akan rusak, dengan hasil yang diduga disayangkan. Ini adalah refleksi miskin di manajemen ketika tidak menjadi pilihan untuk membekukan sebuah proyek untuk menemukan dan memperbaiki menyebabkan masalah ', meskipun ada kasus yang kuat untuk membekukan. Mungkin ada pembelaan pada bagian dari mereka yang bekerja pada proyek bermasalah, dan tekanan kuat untuk mendapatkan proyek kembali di trek. Proses stabilisasi mungkin melibatkan menunjuk seorang manajer proyek baru. Hal ini secara substansial dapat menguntungkan proyek karena orang yang baru tidak memiliki koneksi ke proyek dan karena itu dapat membuat penilaian obyektif tentang apa yang dia diceritakan dan mengamati. Selain itu, seorang manajer proyek baru dapat lebih mudah mengambil sikap tegas tentang menyelidiki apa yang telah terjadi, sebelum melakukan penyesuaian proyek. Juga, seorang manajer baru tidak akan memiliki prasangka atau asumsi-asumsi tentang apa yang atau tidak menyebabkan masalah; prejudgments seperti dinyatakan dapat awan analisis.