Eskalasi Proyek IT: Berhenti atau Harus Dilanjutkan? PendahuluanMakalah ini membahas ini perilaku dalam teknologi informasi (TI) untuk proyek gagal. Kearifan tradisional memberitahu kita bahwa kegagalan proyek tergantung pada kurangnya kontrol dan proyek miskin manajemen. Makalah ini berpendapat bahwa sebagai eskalasi penjelasan tentang kegagalan proyek memiliki terlalu sedikit perhatian

Ketika Proyek GagalTidak ada pengertian yang konsisten dari apa tepatnya yang dimaksud dengan kegagalan dan apa yang dimaksud dengan keberhasilan suatu proyek TI. Komitmen juga dapat digambarkan sebagai penangkis aktif untuk perubahan. Untuk tujuan pemahaman komitmen dalam organisasi adalah penting untuk menekankan bahwa ketika komitmen menginduksi seseorang untuk menyelesaikan tugas yang sulit atau tidak menyenangkan yang menguntungkan dirinya dan orang lain, kemudian komitmen adalah hal yang baik. Ketika, bagaimanapun, komitmen menyebabkan fiksasi pada kebijakan atau perilaku mengurangi manfaat dan biaya meningkat, situasi ini jelas kurang jelas. Kami telah berlebih-lebihan, atau dengan kata lain, kita memiliki situasi eskalasi.

Situasi EskalasiSebuah situasi eskalasi adalah ketika pembuat keputusan menjadi overcommitted pada keputusan sebelumnya, dan berinvestasi lebih banyak sumber daya dalam proyek gagal. Situasi ini terjadi ketika pengambil keputusan harus terus komitmen untuk program spesifik meskipun informasi yang menyebutkan bahwa tindakan gagal. situasi eskalasi adalah komitmen dalam menghadapi informasi negatif tentang alokasi sumber daya sebelum digabungkan dengan pembuat keputusan yang terkunci dalam situasi eskalasi "ketidakpastian seputar kemungkinan pencapaian tujuan.

Sebuah model eskalasiStaw dan Ross mengusulkan sebuah model eskalasi yang memberikan kita dasar teoritis yangmenjanjikan untuk menganalisa dan sampai batas tertentu menjelaskan apa "manajemen proyek yang buruk". Sebuah proyek kemungkinan akan dilanjutkan dengan komitmen tinggi jika hal itu dirasakan sebagai investasi jangka panjang, diharapkan memiliki hasil yang besar, dan struktur hasiljangka panjang. Komitmen yang tinggi untuk proyek terjadi jika biaya penutupan tinggi dan penyelamatan rendah. Terdapat 4 antecedent dari determinan situasi eskalasi: determinan proyek, determinan psikologi, determinan sosial dan determinan organisasi.

Studi Kasusa. Proyek admin Pada tahun 1994, sebuah subdivisi perusahaan menengah mengembangkan sistem berbasis komputer yang disebut ADMIN. Tujuan sistem ini adalah untuk mengubah secara sederhana namun sangat penting bagi tugas administrative. Secara sah seorang pengguna adalah manajer projek, tetapi dalam realitanya analis sistem mengatur projek. Solusi klien/server disarankan sejak ADMIN digunakan pada dua site yang berbeda. Perusahaan konsultasi luar, selanjutnya menghubungi perusahaan, yang menggunakan bagian rancangan. Peralatan yang digunakan dalam projek seharusnya disetujui oleh departemen sistem sentral. Tahap pengembangan di atur oleh analisis sistem tetapi mengaalami permasalahan pada pemrograman sehingga tidak tepat waktu. Hal ini membuat analsis dan pengguna menjadi khawatir, lalu manajemen senior perusahaan dan pemrogram lain dihubungi dan tergabung dalam kelompok ini. Yang menjadi pengujian pertama adalah sistem. ADMIN sangat tidak stabil dan kelompok tidak dapat menguji sistem pada simulasi situasi kerja. Programmer percaya bahwa ini tidak akan menjadi masalah untuk diperbaiki. Dua minggu setelahnya, dijadwalkan pengujian yang baru. Pada saat ini, sistem menunjukkan reaksi yang sama dengan pengujian sebelumnya. Pengujian lebih mendalam dibatalkan dan analis dihubungi oleh managemen senior perusahaan konsultan. Mereka mengakui bahwa programmer pertama kekurangan pengalaman dalam menggunakan peralatan tersebut. Pertemuan menghasilkan kesepakatan yaitu: ADMIN akan siap dan diimplementasikan pada akhir Februari 1996. sebuah uji coba yang ketiga dilakukan pada akhir Januari, tetapi rencana uji coba dua hari dibatalkan setelah dua jam. Untuk mempercepat pekerjaan, perusahaan konsultan mempekerjakan dua programer baru ke dalam proyek. Sebuah uji coba yang keempat dilakukan satu minggu kemudian, dan seperti uji coba yang sebelumnya, hal ini gagal. analis dan pengguna

melakukan audit yang lebih kecil dari sistem. Penggunaan struktur program ADMIN tidak memuaskan, tetapi programmer meyakinkan bahwa ia sendiri akan merestrukturisasi kode. Manajer proyek tidak merasa sangat nyaman dengan situasi itu. Dua minggu kemudian dia memutuskan untuk memanggil seseorang yang sangat berpengalaman "di bidang" programmer untuk melakukan audit ADMIN yang lebih ekstensif. Kode program adalah bencana. Selain itu, ahli menyimpulkan bahwa Akses tidak akan bekerja dengan baik dalam solusi yang direncanakan klien/server. Kondisi ini juga serta menunjukkan bahwa perusahaan tidak memiliki situasi di bawah kontrol. Manajer proyek memutuskan untuk menghentikan proyek tersebut. Dia dan manajemen senior memutuskan untuk melakukan pengulangan

proyek kembali, dengan programmer baru dan lebih berpengalaman. Sistem lama harus digunakan sebagai spesifikasi untuk sistem baru dan Akses itu harus digantikan oleh alat lain. Pelaksanaan ADMIN dijadwalkan untuk berakhir pada minggu terakhir di bulan Mei 1996. Diskusia. Menganalisis Kasus Manajer proyek mengakui bahwa ada sinyal peringatan dini bahwa proyek mungkin berada dalam kesulitan. Analisa proyek menunjukkan beberapa faktor eskalasi. (1) ADMIN adalah proyek analisis pertama sistem, sebagai seorang manajer dan wawancara mengungkapkan bahwa sangat penting baginya bahwa proyek tersebut berhasil. (2) Awal dari fase ketiga programmer dan anggota proyek lainnya telah bermasalah dalam berkomunikasi. Sejumlah kesalahpahaman terjadi karena ini, tetapi manajer proyek tidak melihat ini sebagai masalah besar pada awalnya. Dia percaya bahwa komunikasi antara dia dan programmer akan memperbaiki, tetapi kenyataannya tidak, (3)Manajer proyek memiliki pandangan bahwa masalah itu akan diselesaikan dengan waktu yang optimis: "Mengakui bahwa proyek telah bermasalah dan menjadi sulit seiring berjalannya waktu, (4) Manajer proyek melihat pengulangan kembali dari proyek sebagai hal yang mahal. Dan restart akan berarti bahwa investasi sebelumnya akan sia-sia dan dia harus mengakui bahwa kesalahan yang dibuat, (5) Seleksi sistem alat sentral departemen datang menjadi alasan utama untuk masalah di ADMIN. Sebagai organisasi desentralisasi peran dan kekuasaan, dari departemen sistem berubah. (6) Yang pertama programmer tidak terlatih dengan benar dalam alat yang digunakan, dan ini tidak diketahui oleh perusahaan sampai proyek dihentikan. b. Menghindari kehilangan Proyek IT Penelitian menunjukkan bahwa eskalasi perangkap atau proyek yang hilang dapat dihindari. Saran ini fokus pada dua aspek: (1). Tindakan individu, yaitu apa yang dapat dilakukan manajer proyek IT dan tindakan organisasi [2]. . Sebuah revisi kerangka kerja untuk menghindari eskalasi akan mencakup: (1)Aspek profesionalisme. Semua profesional IT memiliki etika tugas ketika datang untuk melaporkan status proyek. Manajer proyek, dan pengambil keputusan lainnya, harus mengakui bahwa ada kecenderungan alami yang meningkat ketika seseorang menjadi terlalu berkomitmen untuk suatu tindakan. (2)Aspek Proses Keputusan. Manajer proyek harus memastikan bahwa banyak keputusan mungkin menjadi subyek diskusi, misalnya, tidak ada keputusan harus dibuat tanpa pertimbangan kerugian atau risiko terlibat dalam keputusan alternatif. (3)Aspek Budaya Organisasi. Organisasi sebagian besar harus mengggunakan metode resmi untuk memantau kemajuan proyek. Audit proyek serius harus dijalankan secara teratur. Proyek yang lebih besar memiliki risiko lebih tinggi untuk eskalasi dan lebih besar kebutuhan untuk mengontrolnya. c. Rekomendasi untuk Pendidikan kurikulum untuk pelatihan TI yang profesional seharunya memberikan pengetahuan dasar bagaimana kita bersikap dan bertindak dalam situasi yang gagal. Kita tidak seharunya memberikan siswa metode yang holistik dan alat super, tetapi memberikan mereka tentang kesadaran dan pemahaman tetant bagaimana orang berprilaku. Kurikulum harus bisa menunjukkan kegagaalan adalah wajar untuk proyek-proyek dan pengembangan perangkat lunak, dan kegagalan adalah prasyara untuk inovasi.

kesimpulanSalah satu tugas utama dalam proyek ini untuk menghindari proyek-proyek pelarian. Tetapi jika organisasi anggota tidak tahu tentang situasi eskalasi, jika prosedur pengambilan keputusan memiliki kesalahan, dan jika ada organisasi dengan budaya mempromosikan eskalasi, kita akan menlarikan diri dari proyek. , pendidikan berfokus pada sifat dari proyek dan metode yang digunakan dalam proyek, namun dalam perspektif yang lebih panjang, ada yang yakin bahwa konsep penting proyek-proyek ini akan menjadi berkurang. kecenderungan untuk meningkat masih akan menjadi fenomena penting di semua aktivitas manusia. Kita masih akan menemukan dalam diri kita situasi yang sulit untuk memutuskan apakah kita harus terus atau berhenti, mengatakan: "Bisakah kita mampu untuk berhenti atau tidak kita harus lanjutkan?

Ucapan Terima KasihPenelitian ini sebagian didanai oleh Badan Nasional Swedia untuk Industri dan Teknis Pembangunan (NUTEK). Saya juga berterima kasih kepada manajer proyek untuk berbagi pengalamannya dengan proyek dan kepada rekan-rekan untuk komentar yang konstruktif