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

Urban Nulden Departemen 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.