Eskalasi di IT Proyek: Bisakah Kita Mampu untuk Keluar atau melakukan Kita Harus Lanjutkan?

Urban NuldenDepartemen Informatika, Goteborg University, Swedia email: nulden@adb.gu.se

1. Pengantar

Berapa kali Anda berada dalam situasi di mana Anda menghabiskan dua jam

pada film yang buruk dan merasa bahwa dengan waktu ini diinvestasikan itu akan

membuang-buang waktu untuk meninggalkan TV-set sebelum film selesai. Kamu

berkata: Aku punya "terlalu banyak diinvestasikan untuk berhenti. Makalah ini

membahas perilaku ini gagal dalam teknologi informasi (TI) proyek.

Kearifan tradisional memberitahu kita bahwa kegagalan proyek tergantung

pada kurangnya kontrol dan manajemen proyek yang buruk. Itu mungkin benar, tapi

apa yang ada di balik penjelasan singkat manajemen proyek yang buruk? Frasa ini

telah menjadi tempat pembuangan sejumlah penjelasan yang mungkin berbeda untuk

gagal proyek TI, seperti kekurangan persyaratan identifikasi, kebodohan,

kecenderungan kronis untuk meremehkan biaya dan ruang lingkup proyek, kegagalan

pengelolaan risiko yang terkait dengan TI, pengguna ketidakpuasan dan lain-lain.

Meskipun ada banyak jenis kegagalan, beberapa proyek TI tampaknya

mengambil hidup mereka sendiri, "menjadi mereka seperti Musa, dihukum

mengembara sampai akhir hari-hari mereka tanpa melihat tanah yang dijanjikan"

[4].Kami menyebutnya proyek "melarikan diri" karena mereka terus menyerap

sumber daya berharga tanpa pernah mencapai tujuan mereka [5, 6].Akhirnya proyek

ini dihentikan. Ada, Namun, kecenderungan dalam proyek TI membiarkan "pelarian"

carry di jalan terlalu lama sebelum tindakan diambil. Organisasi yang terus

menempatkan sumber daya dalam proyek pelarian karena menghabiskan uang

tambahan tidak memberikan efek bisnis proyek ini dimaksudkan untuk mencapai,

organisasi membuang-buang sumber daya berharga, dan sumber daya yang terbuang

di sini mungkin bisa lebih baik diinvestasikan di tempat lain. Selain itu, meninggalkan

sebuah proyek TI gagal dapat menjadi hasil positif bagi organisasi. Ini memberikan

organisasi dengan kesempatan untuk belajar dari kesalahan dalam proyek dan dengan

demikian meminimalkan risiko membuat kesalahan serupa di masa mendatang [7].

2. Ketika Proyek Gagal

Tidak ada gagasan yang konsisten dari apa tepatnya yang dimaksud dengan

kegagalan dan apa yang dimaksud dengan keberhasilan proyek TI. Sebaliknya itu

adalah terbuka untuk interpretasi yang cukup besar dan mungkin dipandang berbeda

oleh orang yang berbeda pada waktu yang berbeda. Misalnya, pengguna dapat sangat

puas dengan sistem komputer baru, tetapi jika biaya datang untuk menjadi dua kali

atau tiga kali dianggarkan, manajemen mungkin akan memiliki pendapat lain.

Beberapa berpendapat bahwa kita perlu mendefinisikan kembali keberhasilan proyek

karena begitu banyak orang gagal dalam beberapa cara utama [8].Konsep dan

pemahaman TI kegagalan proyek telah berubah selama bertahun-tahun dari isu-isu

teknis untuk manajemen, masalah organisasi dan sosial.Namun, penelitian tampaknya

setuju bahwa tingkat kegagalan terlalu tinggi dan bahwa ini adalah masalah yang

terus-menerus [9].Literatur IT berisi banyak ide, metode, dan saran untuk bagaimana

mengurangi risiko kegagalan dengan meningkatkan keadaan seni dalam

pengembangan dan manajemen proyek, tetapi sastra juga secara eksplisit

mengabaikan pertimbangan alasan kegagalan [10].

Pertimbangkan sebuah skenario di mana sebuah perusahaan konsultan pada

tahun 1988 adalah untuk mengembangkan sistem informasi baru untuk Hotel Hilton,

Marriott, dan Anggaran Rent-A-Car konsorsium [11]. Sistem, CONFIRM, adalah

menjadi keadaan sistem seni perjalanan industri yang komprehensif pemesanan. Tiga

setengah tahun setelah dimulainya proyek dan ketika total sebesar $ 125 juta telah

diinvestasikan, proyek itu dibatalkan. Salah satu senior yang IS manajer menulis:

"Beberapa orang yang telah menjadi bagian dari CONFIRM manajemen tidak

mengungkapkan status sebenarnya dari proyek pada waktu yang tepat. Hal ini

menciptakan masalah-lebih sulit baik etika bisnis dan keuangan-daripada yang

telah ada jika orang-orang datang ke depan dengan informasi yang akurat.

Kejujuran adalah penting dalam bisnis kami-itu adalah kewajiban etis dan

teknis. "

Klien dan manajemen senior yang menyesatkan ke terus berinvestasi dalam

proyek terganggu dengan masalah dalam teknologi database, dukungan keputusan,

dan integrasi. Orang-orang di proyek tahu ini jauh sebelum proyek tersebut

dibatalkan, tetapi tidak ada yang datang ke depan dengan informasi ini, yaitu, tidak

ada yang "whistle blowing" [12]. Sebuah penjelasan yang mungkin untuk kegagalan

CONFIRM adalah bahwa orang-orang di proyek, misalnya, manajer proyek, terlalu

berkomitmen dan yakin bahwa masalah akan diselesaikan. Tapi, di sisi lain, proyek TI

pasti akan gagal jika orang tidak cukup berkomitmen untuk proyek mereka.

Meskipun, ada garis yang sangat tipis antara sikap optimistis dan berlebih-lebihan.

3. Komitmen terhadap Proyek

Komitmen telah dipelajari dari begitu banyak perspektif teoritis yang berbeda

bahwa konsep tersebut harus ditinggalkan demi serangkaian konsep [13].Namun,

dalam tulisan ini, komitmen itu sendiri tidak selalu baik atau buruk, namun tingkat

komitmen berbagai individu dalam suatu proyek diyakini sangat mempengaruhi

keberhasilan akhirnya proyek tersebut.Komitmen didefinisikan sebagai pengikatan

individu untuk tindakan perilaku [14], atau dengan kata lain, keadaan pikiran yang

memegang individu dalam garis perilaku [15]. Selain itu, komitmen juga dapat

digambarkan sebagai penangkis aktif untuk mengubah hal tersebut[16].

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, maka komitmen adalah hal yang baik. Ketika, bagaimanapun, komitmen

menyebabkan fiksasi pada kebijakan atau perilaku mengurangi manfaat dan

meningkatnya biaya, situasi ini jelas kurang jelas. Kami memiliki berlebih-lebihan,

atau dengan kata lain, kita memiliki situasi eskalasi.

4. Situasi Eskalasi

Situasi eskalasi adalah ketika pembuat keputusan menjadi overcommitted

keputusan sebelumnya, dan berinvestasi lebih banyak sumber daya dalam sebuah

proyek gagal. Situasi ini terjadi ketika pengambil keputusan terus komitmen untuk

aksi tertentu meskipun informasi yang menunjukkan bahwa tindakan gagal [17, 18].

Brockner [19] menguraikan ini lebih lanjut dengan menyatakan bahwa situasi eskalasi

adalah komitmen dalam menghadapi informasi negatif tentang alokasi sumber daya

sebelumnya ditambah dengan "ketidakpastian seputar kemungkinan pencapaian

tujuan."

Pengambil keputusan menjadi terkunci dalam situasi eskalasi melalui apa

Staw [16, 17] panggilan ini dikritik oleh Bowen "sindrom kesalahan keputusan." [20]

yang berpendapat bahwa komitmen untuk investasi lebih lanjut terjadi karena

ketidakjelasan situasi dan tidak karena komitmen untuk keputusan gagal. Bowen

melanjutkan bahwa "teknis" seseorang tidak dapat berbuat salah dalam situasi

keputusan yang sakit-terstruktur.

Ada kontroversi mengenai penjelasan eskalasi. Brockner [19] berpendapat

bahwa banyak, tapi tidak semua, dari penjelasan jatuh ke dalam dua kategori besar

dijelaskan oleh teori harapan dan teori diri pembenaran. Harapan teori

mengemukakan bahwa individu memiliki kecenderungan untuk percaya bahwa

mengalokasikan sumber daya tambahan pada akhirnya akan mengarah pada

pencapaian tujuan. Teori pembenaran diri menjelaskan keinginan individu untuk

menunjukkan rasionalitas pada dirinya sendiri karena orang tidak suka bahwa

keputusan masa lalu mereka tidak mencukupi. Namun, semua situasi eskalasi

memiliki beberapa faktor umum yang dapat diisolasi: (1) semua situasi memerlukan

kehilangan beberapa atau biaya-belum tentu moneter yang telah dihasilkan dari kursus

asli tindakan, (2) para predicaments melibatkan beberapa kontinuitas dari waktu ke

waktu-mereka tidak satu-shot urusan, tetapi dilema yang melibatkan program

berkelanjutan tindakan, dan (3) mereka terdiri situasi di mana penarikan sederhana

bukan merupakan solusi yang jelas. Selain itu, (4) pembuat keputusan harus memiliki

pilihan nyata dalam memutuskan apakah akan bertahan atau menarik, dan (5) harus

ada umpan balik yang jelas dari keputusan sebelumnya yang dibuat.

Untuk menghindari kehilangan esensi eskalasi sebagai sebuah fenomena,

perhatian harus bergeser dari mengidentifikasi sejumlah besar anteseden terisolasi

dari situasi eskalasi untuk meneliti pengaruh dari kelas yang lebih umum penentu

dalam berbagai situasi.

4.1 Sebuah Model Eskalasi

Staw dan Ross [23] mengusulkan model eskalasi yang memberikan kita dasar

teoritis menjanjikan untuk menganalisis dan sampai batas tertentu menjelaskan apa

yang "manajemen proyek yang buruk" adalah. Mereka kelompok anteseden dalam

empat kelas penentu situasi eskalasi: penentu proyek, penentu psikologis, determinan

sosial, dan organisasi penentu.

Penentu proyek atribut tujuan proyek, manfaat proyek dan biaya [19]. Sebuah

proyek kemungkinan akan dilanjutkan dengan komitmen yang tinggi jika dianggap

sebagai investasi jangka panjang, diharapkan memiliki hasil yang besar, dan struktur

jangka panjang hasil [24]. Komitmen yang tinggi untuk sebuah proyek juga lebih

mungkin terjadi ketika biaya penutupan yang tinggi dan nilai sisa rendah [23].

Penentu psikologis menyebabkan individu untuk mengambil pandangan

optimis [19].Determinan psikologis menjelaskan keengganan orang untuk mengakui

bahwa keputusan sebelumnya yang salah [18].Pembenaran teori diri dan prospek

teori-individu yang berisiko pameran menolak atau risiko mencari perilaku tergantung

pada bagaimana situasi masalah atau keputusan dibingkai-teori psikologis yang

menjelaskan eskalasi [25, 26]. Determinan lain psikologis adalah perilaku ekonomi

manusia rasional untuk "membuang uang baik setelah buruk" dalam upaya untuk

berbalik situasi gagal, yang disebut "tenggelam biaya" efek [27, 28]. Orang-orang

yang telah memulai sebuah proyek dan bertanggung jawab atas keberhasilan atau

kegagalan lebih mungkin untuk melanjutkan proyek itu [29].Selain itu, keputusan

lebih umum dibuat, semakin kecil kemungkinan bagi pembuat keputusan untuk

mengubah keputusan aslinya.

Determinan sosial berasal dari kelompok mana individu adalah anggota dan

tahan individu untuk tindakan terlepas dari keyakinan individu itu sendiri.Contohnya

adalah wajah tabungan dan pembenaran eksternal [18]. Berhipotesa perbandingan

sosial teori bahwa orang mengevaluasi sikap dan perilaku dalam kaitannya dengan

orang lain dan cenderung menganggap perilaku orang lain sebagai model untuk

perilaku mereka sendiri [30]. Proses evaluatif paling cenderung terjadi ketika

pengambil keputusan tidak yakin tentang kesesuaian sikap mereka sendiri atau

perilaku. Determinan sosial juga melibatkan relasi kelompok ke kelompok lain.

Upaya yang berhasil oleh kelompok dapat mempengaruhi kelompok lain untuk

mencoba pendekatan yang sama. Selain itu, perilaku anggota proyek sangat

dipengaruhi oleh posisi kekuatan relatif mereka [31].

Akhirnya, ada faktor-faktor penentu organisasi di lingkungan struktural dan

politik proyek, seperti dukungan manajemen puncak, inersia administrasi, listrik dan

interaksi antarorganisasi. Menurut Keil [2], proyek lebih rentan untuk meningkat

ketika ada dukungan politik yang kuat dan ketika proyek menjadi dilembagakan.

Pelembagaan terjadi ketika sebuah proyek terikat integral dengan nilai-nilai dan

tujuan organisasi, dan ketika tindakan diambil untuk diberikan karena mereka begitu

dalam tertanam dalam subkultur atau norma-norma organisasi. Lama program dan lini

bisnis yang bahkan tidak dipertimbangkan untuk penghentian karena mereka begitu

diidentifikasi dengan organisasi.

5. Sebuah Studi Kasus

Investigasi merepotkan atau gagal proyek TI menyajikan masalah-masalah

khusus karena sifat sensitif dari materi pelajaran. Kebanyakan orang cenderung

menyembunyikan, lupa atau menempatkan kegagalan balik secepat mungkin dan

pindah ke proyek berikutnya [8]. Juga, tampaknya ada kode keheningan dalam

komunitas pengembangan perangkat lunak yang melarang diskusi tentang kegagalan

[7].Kasus singkat dijelaskan di bagian selanjutnya berfungsi sebagai contoh proyek

yang menunjukkan karakteristik yang konsisten dengan kerangka eskalasi yang

disajikan dalam bagian sebelumnya. Perlu ditekankan bahwa fakta-fakta yang

dihilangkan untuk menjaga deskripsi singkat proyek. Proyek ini masih dalam proses

dan tidak ada evaluasi lengkap atau audit belum dilakukan.

5.1 Proyek ADMIN

Pada tahun 1994 sebuah subdivisi dari sebuah perusahaan menengah mulai

mengembangkan sebuah sistem berbasis komputer yang disebut ADMIN. Tujuan dari

sistem ini adalah untuk meningkatkan tugas administrasi yang relatif sederhana

namun sangat penting. Keberhasilan subdivisi, dan dalam jangka panjang seluruh

organisasi, sampai batas tertentu tergantung pada tugas administratif dan bahwa hal

itu beroperasi dengan lancar.

Tahap analisis proyek selesai pada Juni, diikuti oleh persyaratan sistem dan

fase spesifikasi yang selesai pada Februari 1995. Pekerjaan dalam fase tidak menemui

masalah besar.Sebuah solusi client / server disarankan karena ADMIN adalah untuk

digunakan di dua lokasi yang berbeda.Sebuah perusahaan konsultan eksternal,

selanjutnya disebut sebagai perusahaan, terlibat untuk bagian pemrograman.

Perusahaan ini telah terlibat dalam proyek-proyek yang sukses serta beberapa proyek

sebelumnya kurang berhasil, namun memiliki reputasi untuk menjadi

kompeten.Selama pembahasan isu-isu teknis ADMIN satu permintaan penting

dibesarkan. Alat yang akan digunakan dalam proyek harus disetujui oleh pusat sistem

departemen. Departemen memiliki pengalaman 'Akses' dan 'Visual Basic' dan

menemukan ini sesuai untuk ADMIN. Belakangan ini menunjukkan menjadi

keputusan yang buruk.

Tahap pengembangan secara resmi dikelola oleh analis sistem dan awalnya

dijadwalkan akan selesai pada bulan September 1995. Tanggal ini kemudian

dipindahkan hingga November karena masalah pemrograman. "Ini terjadi," dan

kelompok proyek, sekarang diperluas dengan satu programmer lebih dari perusahaan,

tidak mengambil tindakan segera. Jadwal pelaksanaan sekali lagi berubah di

pertengahan Oktober. Tanggal baru ditetapkan untuk Januari 1996. Ini membuat

pengguna dan analis khawatir. Manajemen senior di perusahaan dihubungi dan lain

programmer dari perusahaan ditambahkan ke grup pada pertengahan November.

6. Diskusi

Beberapa mungkin menganggap desain evolusi sistem, siklus umpan balik,

pengembangan perangkat lunak sebagai proses pembelajaran dan komunikasi, dll,

sebagai solusi untuk menghindari proyek-proyek seperti ADMIN. Tapi titik yang

dibuat di sini adalah bahwa orang-orang dan organisasi dapat menjadi overcommitted

untuk kursus gagal tindakan. Meskipun, ADMIN tidak pernah menjadi sebuah proyek

pelarian itu menunjukkan karakteristik konsisten dengan model eskalasi.

6.1 Menganalisis Kasus

Retrospektif, palungan proyek mengakui bahwa ada sinyal peringatan dini

bahwa proyek mungkin berada dalam kesulitan.Analisis proyek menunjukkan faktor

eskalasi beberapa. (1) ADMIN adalah proyek pertama sistem analis sebagai manajer

dan wawancara mengungkapkan bahwa itu sangat penting baginya bahwa proyek

berhasil. Melalui proyek ini, dia memiliki kesempatan untuk memperbaiki posisinya

dalam organisasi.Kelompok proyek sangat berpengalaman dan banyak keputusan

yang dibuat oleh manajer proyek saja. (2) Dari awal dari fase ketiga programmer

(pertama) dan anggota proyek lain memiliki masalah berkomunikasi. Sejumlah

kesalahpahaman terjadi karena ini, tapi palungan proyek tidak melihat ini sebagai

masalah besar pada awalnya. Dia percaya bahwa komunikasi antara dia dan

programmer akan memperbaiki. Itu tidak. Kemudian ia menyadari bahwa ia

seharusnya bertindak atas masalah ini sebelumnya. (3) Manajer proyek memiliki

pandangan optimis bahwa masalah akan diselesaikan dengan waktu: "Mengakui

bahwa proyek memiliki masalah menjadi lebih sulit seiring berjalannya waktu." (4)

Manajer proyek melihat restart proyek sebagai mahal. Dan restart akan berarti bahwa

investasi awal akan sia-sia dan dia harus mengakui bahwa kesalahan yang dibuat. (5)

Pusat sistem pemilihan departemen alat datang untuk menjadi alasan utama untuk

masalah di ADMIN. Sebagai organisasi yang desentralisasi peran dan kekuasaan, dari

departemen sistem berubah. (6) Programmer pertama tidak benar terlatih dalam alat

yang akan digunakan, dan ini tidak diakui oleh perusahaan sampai proyek tersebut

dihentikan.

6.2 Menghindari di Runaway IT Proyek

Orang-orang dan organisasi dapat menjadi overcommitted untuk kursus gagal

tindakan, mendapatkan diri mereka ke dalam situasi eskalasi disebut. Hal ini

menyatakan bahwa eskalasi sebagai alasan untuk kegagalan proyek TI diberikan

terlalu sedikit perhatian di sebagian besar literatur manajemen risiko dan dalam

praktek. Eskalasi situasi terjadi ketika proyek organisasi memiliki nilai sisa sedikit,

ketika pembuat keputusan ingin membenarkan perilaku masa lalu mereka, ketika

orang-orang dalam proyek terikat satu sama lain, dan ketika inersia organisasi dan

politik internal bergabung untuk mencegah proyek dari yang ditutup.

Penelitian menunjukkan bahwa eskalasi perangkap atau proyek melarikan diri

dapat dihindari. Saran ini fokus pada dua aspek: tindakan individu, yaitu, apa yang TI

manajer proyek dapat dilakukan dan tindakan organisasi [2]. Di sini saya ingin

menjelaskan dua aspek lebih lanjut dan menambahkan aspek ketiga, jatuh di antara

individu dan organisasi. Kerangka direvisi untuk menghindari eskalasi akan

mencakup:

• Aspek Profesionalisme. Semua profesional TI memiliki tugas etis ketika datang

untuk melaporkan status proyek [32-34].Manajer proyek, dan pengambil keputusan

lainnya, harus mengakui bahwa ada kecenderungan alami untuk meningkat ketika

seseorang menjadi terlalu berkomitmen untuk suatu tindakan. Jika manajer proyek

menyadari situasi eskalasi lain dan kekuatan "mengemudi" untuk bertahan pada

tindakan dan "penahanan" penarikan situasi, kecenderungan mereka untuk

meningkat dalam proyek berikutnya mungkin lebih rendah. Hal ini penting bagi

individu untuk tinggal dengan tujuan keseluruhan dari proyek tapi tidak dengan

solusi tertentu karena solusi alternatif selalu mungkin dianggap.

• Aspek Proses Keputusan. Manajer proyek harus memastikan bahwa keputusan

sebanyak mungkin tunduk untuk diskusi, misalnya, ada keputusan harus dibuat

tanpa pertimbangan eksplisit dari kerugian atau risiko pada alternatif keputusan.

Aspek negatif harus muncul dalam semua keputusan yang dibuat.Jika tidak ada

aspek negatif yang ditemukan, menunda keputusan sampai hari berikutnya atau

pertemuan berikutnya. Karena keputusan akhir untuk melanjutkan proyek gagal

sering dibuat oleh seorang individu, proses menuju keputusan harus menjadi upaya

kelompok [21]. Untuk hal ini, konflik adalah mekanisme untuk memfasilitasi

belajar, misalnya, dengan menggunakan seorang advokat setan, seorang individu

yang memainkan peran formal kritikus untuk membantu pembuat keputusan

pengujian asumsi dan logika keputusan akhir. Pentingnya kelompok dalam proses

keputusan lebih ditekankan karena banyak keputusan yang dibuat dalam masalah

keprihatinan proyek yang tidak didefinisikan dengan baik, yaitu, masalah lembut

[35], dan harus dibahas dari berbagai perspektif.

• Aspek Budaya Organisasi. Organisasi harus, untuk sebagian besar, menggunakan

metode formal untuk memantau kemajuan proyek. Audit proyek serius harus

dilakukan secara teratur. Proyek yang lebih besar memiliki risiko lebih tinggi untuk

eskalasi dan kebutuhan yang lebih besar untuk kontrol. Proyek-proyek besar yang

memiliki kompleksitas tinggi, stakeholder lebih dengan pandangan yang berbeda

dan kriteria untuk sukses, kebutuhan sumber daya yang lebih besar, ruang lingkup

yang lebih besar dan lebih banyak interaksi sehingga lebih banyak kesempatan untuk

kekurangan. Kegiatan reaktif yang berbeda, seperti indikator, pengendalian evaluasi,

dan penilaian merupakan isu-isu manajemen penting dalam kegiatan proyek.

Sebagian besar organisasi telah memantau fungsi untuk mengendalikan

penyimpangan dalam proyek-proyek, dan fungsi yang ditambahkan untuk memantau

fungsi dan sebagainya (cara yang umum untuk mengontrol apa yang tidak

terkendali). Namun, tidak peduli seberapa menyeluruh kontrol, audit dan revisi,

semua masalah yang mungkin untuk menyembunyikan, sampai terlalu terlambat

untuk menangani mereka. Oleh karena itu, pendekatan proaktif untuk menghindari

eskalasi diperlukan. Dengan kebijakan perusahaan eksplisit pada kegagalan orang

dalam organisasi memiliki pedoman untuk bagaimana bertindak dalam situasi

eskalasi.

6.3 Rekomendasi untuk Pendidikan

Kurikulum untuk pelatihan profesional TI, atau apapun yang kita memutuskan untuk

memanggil mereka, harus memberikan pengetahuan dasar tentang bagaimana kita

bersikap dan bertindak sebagai manusia dalam situasi gagal. Kita seharusnya tidak

hanya memberikan para siswa dengan metode holistik dan "alat super," tetapi

melengkapi mereka dengan kesadaran dan pemahaman tentang bagaimana orang

berperilaku, misalnya, dalam situasi eskalasi. Saat ini sebagian besar buku teks yang

meliputi manajemen proyek TI mungkin memiliki garis atau dua hal tentang situasi

eskalasi proyek. Program universitas seperti pengantar rekayasa perangkat lunak,

analisis dan desain, dll, harus mengalokasikan waktu bagi siswa untuk bekerja dengan

kasus dan mendiskusikan proyek gagal. Kurikulum kami harus menunjukkan bahwa

kegagalan adalah wajar untuk proyek-proyek dan pengembangan perangkat lunak dan

kegagalan yang merupakan prasyarat untuk inovasi.

7. kesimpulan

Salah satu tugas utama dalam proyek adalah untuk menghindari proyek pelarian.

Tetapi jika anggota organisasi tidak tahu tentang situasi eskalasi, jika prosedur

decisision memiliki kekeliruan, dan jika ada organisasi dengan budaya

mempromosikan eskalasi, kita akan memiliki proyek pelarian.

Karena disiplin kami didirikan pada tahun 60-an, data sistem pengolahan telah

dikembangkan dalam proyek-proyek. Saat ini, pendidikan berfokus pada sifat dari

proyek dan metode yang digunakan dalam proyek, tetapi dalam perspektif lama, ada

pula yang yakin bahwa proyek ini akan menjadi sebuah konsep kurang penting [36].

Namun, kecenderungan untuk meningkat masih akan menjadi fenomena penting

dalam semua aktivitas manusia. Kita masih akan menemukan diri kita dalam situasi

yang sulit untuk memutuskan apakah kita harus melanjutkan atau menghentikan,

dengan mengatakan: "Mampukah kita berhenti atau apakah kita harus terus?"

8. Ucapan Terima Kasih

Penelitian ini sebagian didanai oleh Badan Nasional Swedia untuk Pembangunan

Industri dan Teknik (NUTEK). Saya juga berterima kasih kepada manajer proyek

untuk berbagi pengalaman dengan proyek dan rekan-rekan untuk komentar

konstruktif.