Professional Documents
Culture Documents
Pendahuluan
Makalah 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
Situasi Eskalasi
Sebuah 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.
Studi Kasus
a. 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. Diskusi
a. 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.
kesimpulan
Salah 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?