Sıfır ve birlere dönüşen bir kod olarak tanımlanan yazılım teknolojisi, sistem mimarilerini, program tasarımlarını, bilgisayar programlarının ihtiyaç duyduğu veri yapılarını, fiziksel ve fiziksel olmayan diğer ürünleri kapsar (Cusumano, 2004). 1960’lı yılların başında yazılım, diğer programları ya da bilgisayar donanımlarını kontrol eden işletim sistemlerini kuran programlar olarak tanımlanmış (Haigh, 2002); 70’li yılların son çeyreğinde ise yazılım mühendisliğinin sınırları Boehm tarafında çizilmiştir (Mahoney, 2004’te atıfta bulunulduğu gibi). Yazılım teknolojileri ve buna bağlı olarak yazılım mühendisliği sürekli gelişim içindedir. 60’lı yıllarda işletim sistemleri, programlama dilleri ve uygulamalar ile başlayan yeni ürün geliştirme çabalarına zamanla internet teknolojileri ve çözümleri, açık kaynak yazılımlar ve hizmet olarak yazılım (SaaS-software as a service) gibi yenilikler katılmıştır.
Buna göre, bilişim alanında ürün geliştiren organizasyonlar ya salt yazılım ürünlerini ya da yazılım ve donanım bileşenlerinden oluşan sistemleri gerçekleştirir. Yazılım esas olmak üzere elektrik, elektronik, mekanik, hidrolik, insan ve bilgi gibi bileşenlerin bir kısmı ya da tamamı bir araya getirilerek bilişim sistemleri oluşturulur. Diğer sistemlerde olduğu gibi bilişim sistemlerinin tasarımında üç faaliyet öne plana çıkar: Kavramsal modelin oluşturulması, analiz edilmesi ve gerçekleştirilmesi (Willow, 2007).
Yazılım ve donanım bileşenlerinin beraber gerçekleştirilmesini hedef alan sistem seviyesi tasarım yöntemleri (Albuquerque ve diğ., 1999) ürün yapısına ve ürün büyüklüğüne, müşteri gereksinimlerine, kullanılan teknolojilere, kısıtlara ve kaynak ihtiyaçlarına bağlı olarak oldukça karmaşık ve başarı oranı belirsiz tasarım yöntemlerine dönüşebilir. Sistem tasarımında başarım oranının düşük olması maliyet ve kalite başta olmak üzere diğer tüm unsurları olumsuz yönde etkiler. Ürün geliştirme sürecinin başarısı zaman, maliyet ve ürün performansı (Simon ve De Klerk, 1997) ya da kalitesi (Golubic, 2003) ile ölçülür. Zaman ve maliyet projenin performansı ile doğrudan ilişkili iken karmaşık bir konu olan kalite genellikle müşteri memnuniyetiyle ölçülür.
Cooke-Davies (2002) proje başarısında başarı kıstasları ve başarı etmenleri olmak üzere iki unsurun öne çıktığını söyler. Başarı kıstasları bir projenin başarılı ya da başarısız olduğunu gösteren ölçümlerdir. Başarı etmenleri ise proje başarısını doğrudan ya da dolaylı bir şekilde yönlendiren yönetim sisteminin girdileridir. Bilgi Teknolojileri (BT) sistemlerinin gerçekleştirilmesi esnasında başarıyı ya da başarısızlığı etkileyen etmenler hem yönetim bilimcilerinin hem de BT araştırmacılarının dikkatini çekmiştir (Schmidt ve diğ., 2001). BT konusunda yürütülen araştırmaların önemli bir kısmı proje başarısını etkileyen etmenlerin tanımlanmasına odaklanmıştır. Bir kısım araştırma tanımlanan bu etmenler üzerinden proje büyüklüğünü (çaba ve süre gibi) ya da performansını modellemeye çalışmaktadır.
Zmud başarı ya da risk etmenlerini kurumsal özellikler, çevresel özellikler, görev özellikleri ve bireysel özellikler olmak üzere dört grup altında toplarken (Schmidt ve diğ., 2001’de atıfta bulunulduğu gibi), Chittister ve Haimes (1994) bunları teknik olan ve olmayan riskler olarak iki kategoride incelemiştir. Buna göre, yazılım geliştirme sürecinin performansını etkileyen teknik riskler, yazılım ürününün işlevsel ve performans gereksinimleriyle ilişkili olan ve yazılım geliştirme aşamalarında ortaya çıkan etmenlerin olasılığının ve şiddetinin bir ölçüsüdür. Diğer taraftan teknik olmayan riskler, yazılım geliştirme aşamalarındaki program özelliklerinden kaynaklanan etkilerin olasılığı ve şiddetiyle ölçülür.
Curtis ve diğ. (1988) orta ve büyük ölçekli projeler üzerinde gerçekleştirdiği bir araştırmada, yazılım proje ekiplerinin üç temel sıkıntıyla karşı karşıya kaldığını ortaya çıkarmıştır. Buna göre, yetersiz uygulama alanı bilgisi, kararsız ve tartışmaya açık gereksinimler ile koordinasyon ve iş birliği aksaklıkları yazılım projelerinde öne çıkan risklerdir.
Boehm (1991) yürüttüğü bir çalışmada öncelikli risk kontrol listesi hazırlamış, on adet yazılım risk öğesini bu çerçevede incelemiştir. Personel sıkıntısı ve gerçekçi olmayan takvim ve bütçe öngörüleri dışında kalan diğer tüm risk öğeleri ürün geliştirme sürecinin teknik zorluklarıyla ilgilidir. Bunlar işlevlerin ve özelliklerin hatalı geliştirilmesi, kullanıcı ara yüzlerinin hatalı geliştirilmesi, gereksiz gereksinimlerin kapsam içine alınması, gereksinim değişikliklerinin sürekli olması, dış bileşenlerin ve görevlerin eksik tanımlanması, gerçek zamanlı performans eksiklikleri ve bilgisayar bilimi yeteneklerinin yetersizliği şeklinde sıralanır.
Barki ve diğ.'lerinin (1993, 2001) 120 adet yürüyen proje üzerinde gerçekleştirdikleri bir çalışmada 35 adet proje riski tanımlanmıştır. Kullanıcıların bilişim teknolojileri bilgisi ve projeye verdikleri destek, işletme içindeki ve dışındaki kullanıcı sayısı kullanıcı kaynaklı risklerdir. Ekip elemanlarının sayısı ve göreceli de olsa proje büyüklüğü proje ölçeğiyle ilişkili risklerdir. Ekip elemanlarının ürün geliştirme teknolojilerine hâkim olma düzeyi ve uygulama alanı bilgisi, proje ekibinin bilgi ve deneyimini gösterir. Geliştirilen sistemin mevcut ya da gelecekteki sistemlerle olan etkileşim düzeyi ve işlevlerin zorluk derecesi ürünün karmaşıklığını, yeni yazılım ve donanım teknolojilerine duyulan ihtiyaç geliştirme ortamının karmaşıklığını gösterir. Ürün kapsamının genişliği ise yazılım ve donanım tedarikçilerinin sayısı, alt yüklenicilere duyulan ihtiyaç ve organizasyon dışındaki kullanıcıların sayısı ile belirlenir.
Yürütülen bu çalışmada yukarıda tanımlanan risk değişkenleri kullanılarak proje bilgileri elde edilmiş; elde edilen bu bilgiler, faktör analizi yöntemiyle, beş adet etmen sınıfı altında toplanmıştır. Bu etmen sınıfları proje yöneticilerinden beşli likert ölçeğinde alınan belirsizlik bilgileriyle karşılaştırılmıştır.
Belassi ve Tukel (1996) proje başarısını etkileyen kritik etmenleri dört grup altında toplamışlardır: Projeyle, proje ekibi ve proje yöneticisiyle, işletmeyle ve dış çevreyle ilgili olan etmenler. Gruplar altında tanımlanan etmenler birbirinden tamamen bağımsız değildir. Diğer bir deyişle, bir grup altında tanımlı olan bir etmen diğer gruptaki başka bir etmenle birebir ilişkili olabilir. Belassi ve Tukel’in oluşturduğu bu çerçeve modelde, diğer tanımlamalardan farklı olarak, proje faaliyetlerinin benzersizliğini tanımlayan yeni bir etmen daha bulunmaktadır. Bu çalışmada müşteriler ve alt yükleniciler dış çevre etmen grubu altında tanımlanmıştır.
Moynihan (1997) psikoloji, eğitim ve yönetim bilimlerinde kullanılan kişisel oluşturmalar (personal constructs) yöntemini kullanarak proje yöneticilerinin geliştirme projelerini tanımlama yaklaşımlarını ortaya çıkarmış, bunları literatürdeki proje riskleriyle karşılaştırmıştır. Araştırmada proje yöneticilerine yönetmiş oldukları üç projeden ikisinin hangi durumlarda benzerlik göstererek üçüncüden ayrıldığı sorulmuştur. Bunu yaparken proje planlama aşamasındaki faktörlerin dikkate alınması gerektiği vurgulanmıştır. Oluşturulan ortak yapılar listelendiğinde birinci ve üçüncü sırada müşterinin bilgi, beceri ve deneyim düzeyinin yer aldığı görülür. Buna göre, müşterinin ürün gereksinimlerini ne kadar iyi kavradığı ve konuya ne kadar
hâkim olduğu ilk sırada verilmiştir. Yine müşterinin ya da kullanıcıların bilişim sistemlerine olan yatkınlığı ve deneyimi üçüncü sıradadır. Diğer taraftan, üst düzey yönetimin ya da proje sahibinin projeye sahip çıkma derecesi ikinci sırada yer almıştır. Geliştirilecek ürünün diğer sistemlerle olan etkileşimi, proje ölçeği, proje üzerindeki kontrolün ana kaynağı, proje ekibinin ürün geliştirme konusuna ve geliştirme teknolojilerine olan hâkimiyeti, uygulamanın mantıksal karmaşıklığı ve uygulanacak teknolojinin olgunluk düzeyi listedeki diğer ortak yapılardır.
Field yazılım geliştirme faaliyetlerinde sıkıntı yaratan durumları incelemiş, BT projelerindeki başarısızlığın nedenlerini on başlık altında özetlemiştir. Bunlar proje yöneticisinin kullanıcı taleplerini anlamaması, proje kapsamının düzgün belirlenememesi, projede değişikliğin iyi yönetilememesi, seçilen teknolojilerin değişmesi, işletme ihtiyaçlarının değişmesi, teslimat sürelerinin gerçekçi olmaması, kullanıcının direnç göstermesi, desteğin kaybedilmesi, projeye uygun eleman bulunamaması ve yöneticilerin geçmişte yapılan hataları göz ardı etmeleri olarak sıralanmaktadır (Reel, 1999’da atıfta bulunulduğu gibi).
Ropponen ve Lyytinen’in (2000) 83 adet yazılım proje yöneticisi arasında gerçekleştirdiği bir anket çalışmasında, yazılım geliştirme risk öğelerine ve bu öğeler üzerinde etkili olan etmenlere odaklanmıştır. Bu çalışmada zamanlama riskleri, sistem işlevselliği riskleri, alt yüklenici riskleri, gereksinimlerin yönetimi riskleri, kaynak kullanımı ve performans riskleri ve personel yönetimi riskleri olmak üzere altı temel risk unsuru ele alınmıştır.
Cule ve diğ. (2000) BT proje risklerini iç ve dış riskler olarak ikiye ayırır. İç riskler proje yönetimi ve proje görevleri olarak sınıflandırılırken dış riskler iç ve dış müşterilerden ve dış çevreden kaynaklanan riskler olarak değerlendirilir. 41 adet tecrübeli proje yöneticisiyle yürütülen çalışmada elde edilen 53 risk unsuru bu dört kategori altında toplanmıştır.
Keil ve diğ.(1998) yazılım projelerindeki riskleri dört sınıf altında toplar: Müşteri etkisi, kapsam ve gereksinimler, gerçekleştirme ve çevresel etkiler. Müşteri etkisi, müşteri katılımı gibi müşteri ve son kullanıcılarla ilgili olan etmenleri kapsar. Bu sınıftaki etmenlerin çoğu proje yöneticisinin kontrolü dışındaki durumları gösterir ve proje başarısını doğrudan etkiler. Kapsam ve gereksinim sınıfı, proje yöneticisinin sistem kapsamını belirleyebilme yeteneğiyle ilgilenir. Gerçekleştirme sınıfı, proje
ekibinin yetersiz olması, geliştirme yöntemlerinin uygun olmaması, projenin doğru planlanmaması gibi durumlarla ilgilenir. Çevre etmeni projeyi etkileyebilecek iç ve dış çevre unsurlarıyla ilgilenir.
Schmidt ve diğ. (2001) Barki ve diğ.’lerinin (1993), Boehm’in (1989) ve Moynihan’ın (1997) oluşturduğu risk sınıflarını incelemiş; bu sınıflara yeni risk etmenleri ilave ederek tüm riskleri on dört sınıf altında toplamıştır. Oluşturulan risk sınıfları şunlardır: İşletme çevresi, projeye destek ya da projeyi sahiplenme, ilişki yönetimi, proje yönetimi, kapsam, gereksinimler, mali destek, takvim, personel, eleman sağlama, teknoloji, dış bağımlılıklar ve planlama. Bu çalışmada üç aşamalı Delphi yöntemi kullanılarak yazılım risklerine öncelik verilmiştir. Çalışmaya 45 adet deneyimli proje yöneticisi katılmıştır. Proje başarısını etkileyen unsurlar önem derecesine göre sıralandığında tüm risklerin on bir adet risk etmeni altında gruplandırılabildiği görülmüştür. Buna göre üst düzey yönetiminin taahhüdü en etkin risk etmenidir. Bunu sırasıyla gereksinimlerin hatalı anlaşılması, kullanıcı katılımını sağlamadaki başarısızlıklar, son kullanıcı beklentilerini karşılamadaki başarısızlıklar, proje kapsamının ve amacının değişmesi, deneyimli ve bilgili personelin yeterli düzeyde olmaması takip eder.
Wang ve diğ. (2005) ürün geliştirme sürecindeki riskleri daha farklı bir açıdan incelemiş; bilgi kaybı, ürün veya projenin sahiplenilmemesi ya da kontrolün kaybedilmesi, geliştirmenin planlanandan fazla zaman alması, amaçların farklılık göstermesi, üçüncü kişilerin sözlerinde durmamaları ve ortakların rakip olması gibi risklerin olabileceğinden bahsetmiştir.
Han ve Huang (2007) 27 adet yazılım riskini kullanıcılar, gereksinimler, proje karmaşıklığı, planlama ve kontrol, ekip ve kurumsal çevre olarak tanımlanan altı risk sınıfı altında toplamış, bu risk sınıflarının proje performansı üzerindeki etkilerini analiz etmiştir. 115 adet yazılım proje bilgisi üzerinde gerçekleştirilen bu çalışmada yazılım risklerinin proje performansı üzerindeki etkileri beşli Likert ölçeği ile ölçülür. Her bir riskin oluşma olasılığı ve bunların teknik performans, maliyet ve takvim üzerindeki etkileri bir ile beş arasında değişen rakamlarla belirlenir.
Wiegers (2007) yazılım risklerini bağımlılıklar, gereksinimler, yönetim, bilgi eksikliği ve dış kaynak kullanımı olmak üzere beş grup altında toplanmıştır. Bağımlılık grubu, proje tarafından kontrol edilemeyen, proje dışındaki aktörler
tarafından yaratılan riskleri içerir. Bağımlılıkla ilgili risk etmenleri müşteri kaynaklı öğeler ve bilgiler, alt yüklenici ya da tedarikçi ilişkileri, bileşenler ya da gruplar arası bağımlılıklar, deneyimli ve eğitimli personelin mevcudiyeti ve projeden projeye aktarılan bileşenler, öğeler, kütüphaneler ve alt yapılar olarak sıralanır.
Kesinleştirilmeyen ürün kapsamı, üzerinde uzlaşılamayan, öncelik verilmemiş ve sürekli değişen ürün gereksinimleri, müşterinin katkı sağlamadığı gereksinim analizi süreci ve belirsiz piyasa beklentileri gereksinim kaynaklı etmenleri oluşturmaktadır. Yanlış öngörülen proje planları, gerçekçi olmayan sözlerin verilmesi, son kullanıcıların ya da müşterilerin gerçekçi olmayan beklentileri, ekip elemanları arasındaki anlaşmazlıklar ve sahiplenilmeyen projeler yönetim risklerini oluşturur. Ekip elemanlarının uygulanan teknikler, yöntemler ve araçlar hakkında yeterli donanıma sahip olmaması, alan uzmanlığının yetersiz olması, hatalı teknik çözümlerin önerilmesi ve geliştirme süreçleri konusunda yeterli bilgiye sahip olmama bilgi eksikliği çerçevesinde ele alınır. Yine dış kaynak problemleri tedarik süreciyle ilgili sıkıntıları tedarikçi, tedarik süreci ve yaptırımlar, kurallar ve düzenlemeler çerçevesinde inceler (Wiegers, 2007).
Yazılım mühendisliği enstitüsü (SEI-Software Engineering Institute) yazılım geliştirme projelerindeki tüm riskleri yazılım geliştirme yaşam döngüsü riskleri, geliştirme ortamı riskleri ve program amaçlı çevresel riskler sınıfları altında toplar. Yazılım geliştirme yaşam döngüsü riskleri, gereksinim analizi, tasarım, gerçekleştirme, doğrulama ve geçerleme gibi geleneksel geliştirme süreçlerinden kaynaklanan risklerdir. Geliştirme ortamı sınıfında geliştirme süreçleri (süreç tanımları ve yöntemleri), geliştirme sistemi (kullanılan araçlar ve aletler gibi), yönetim süreçleri (planlama ve bütçeleme gibi), yönetim yaklaşımı ve çalışma ortamı gibi alt sınıflar tanımlanır. Bu etmen sınıfı geliştirme ortamında kullanılan yazılımların ve donanımların seçimi, geliştirme sisteminin kapasitesi, kullanılabilir olması, diğer sistemlerle uyumlu olması ve ekibin bu sisteme aşina olması gibi birçok etmeni içinde barındırır. Program kısıtları sınıfı ise kaynakları, şartnameyi ve program ara yüzleri gibi etmenleri kapsar (Kendall ve diğ., 2007).
Nidumolu (1996a) 64 adet proje üzerinde gerçekleştirdiği bir anket çalışmasında gereksinim belirsizlikleri, yatay koordinasyon düzeyi ve dikey koordinasyon düzeyi ile performans riskleri, süreç kontrolü ve süreç esnekliği arasındaki ilişkileri incelemiştir. Çalışmada kullanılan tüm değişkenler beşli Likert ölçeğinde
tanımlanmıştır. Gereksinim belirsizlikleri etmeni, gereksinimlerin istikrarsızlığı, gereksinimlerin çeşitliliği ve gereksinimlerin analiz edilebilirliği etmenlerinin birlikte değerlendirilmesiyle elde edilir.
Jiang ve Klein (2000) 86 adet proje yöneticisi arasında gerçekleştirdiği bir anket çalışmasında yazılım proje verimliliğini etkileyen etmenleri ortaya çıkarmıştır. Bu çalışmada tüm değişkenler yedi puanlık sıralama ölçeğinde tanımlanmıştır. Burada proje verimliliği ile proje hedeflerine ulaşma yeteneği, yapılan işin miktarı ve kalitesi, takvime ve bütçeye sadık kalma gibi etmenler kastedilmektedir. Çalışmada teknolojik satın alma, proje büyüklüğü, proje ekibinin genel deneyimi, ekibin ürün geliştirme tecrübesi, ekibin görev ya da alan tecrübesi, kullanıcı desteği, anlaşmazlıkların yoğunluğu, rollerin açık bir şekilde tanımlanmaması, kaynakların yetersiz olması, uygulamaların karmaşıklığı, kullanıcının deneyimi ve değişikliklerin kapsamı ile proje verimliliği arasındaki ilişkiler incelenmiştir.
Wallace ve diğ. (2004a) kurumsal çevre riski, gereksinim riski, kullanıcı riski, planlama ve kontrol riski, proje karmaşıklığı riski ve ekip riski olarak adlandırılan altı yazılım risk sınıfı ile geliştirme süreç performansı ve nihai ürün performansı arasındaki ilişkileri inceler. Çalışmada ilk olarak bu altı risk sınıfı kendi içinde değerlendirilir; en uygun risk grupları seçilerek sosyal, teknik ve proje yönetimi alt sistem risk sınıfları elde edilir. Daha sonra bu alt sistem risk etmenleriyle süreç ve ürün performansları arasındaki ilişkiler analiz edilir.
Procaccino ve diğ. (2006) yazılım geliştirmedeki başarı etmenlerini, Web tabanlı bir anket yardımıyla ortaya çıkarır. Anket çalışmasına 20 yazılım firmasını temsilen 30 geliştirmeci katılmıştır. Soruların tamamı yedili Likert ölçeğinde tanımlanmıştır. Analiz sonuçları yazılım geliştirme başarısındaki en etkili etmenin açık ve anlaşılır bir şekilde tanımlanan gereksinimler olduğunu gösterir. Bunu ekibin yeterli yetkinliğe sahip olması ve müşteri ve geliştirme ekibi arasındaki ilişkinin iyi olası takip eder.
Tiwana ve Keil (2006) yazılım projelerindeki işlevsellik riskine odaklanmış, müşteri katılımı, teknik bilgi, gereksinimlerin değişkenliği, geliştirme yöntemi, formal proje yönetimi pratikleri ve proje karmaşıklığı gibi etmenlerin etkisini incelemiştir. 60 adet firma yöneticisinden gelen yanıtlara göre geliştirme yöntemi, müşteri katılımı ve
formal proje yönetimi pratikleri etmenleri işlevsellik riskinde en yüksek önem derecesine sahiptir.
Tesch ve diğ. (2009) proje başarısında yazılım geliştiricilerin alan uzmanlığının ve kullanıcıların yazılım geliştirme tecrübesinin ne kadar etkili olduğunu, ekibin problem çözme yetkinliğini dikkate alarak inceler. Bu çalışma kullanıcılardan ve geliştiricilerden oluşan 168 adet bilişim profesyoneli arasında gerçekleştirilmiştir. Çalışmada kullanıcıların ve geliştiricilerin bilgi düzeyi, ekibin problem çözme düzeyi ve proje başarısı beşli Likert ölçeğinde tanımlanmıştır.
Jiang ve diğ.’lerinin (2009) 151 adet BT proje yöneticisi arasında gerçekleştirdiği bir çalışmada gereksinimlerin istikrarsızlığı, gereksinimlerin çeşitliliği ve paydaşların algı boşluğu ele alınmış; bu etmenlerle projelerdeki artık performans riski ve proje yönetimi performansı arasındaki ilişkiler incelenmiştir. Çalışmada kullanıcı ile BT personeli arasındaki yatay koordinasyonun düzeyi kontrol değişkeni olarak seçilmiştir. Yine çalışmada kullanılan tüm bağımlı ve bağımsız değişkenler beşli Likert ölçeğinde tanımlanmıştır.
Chin ve diğ. (2009) çalışmalarında yeni ürün geliştirme projelerindeki riskleri Ar-Ge, tedarik, ürün güvenilirlik ve üretim riskleri şeklinde sınıflandırmış; yazılım geliştirme proje risklerini analiz eden bir Bayes ağ modeli oluşturmuştur.
Cerpa ve diğ. (2010) proje başarısında etkili olabilecek etmenleri lojistik regresyon yöntemi kullanarak modellemiştir. Bu çalışmada müşteri beklentilerinin gerçekçi olması, gereksinimlerin iyi tanımlanması, kestirimlerin düzgün yapılması ve proje yönetiminin iyi olması gibi farklı etmenler ele alınır. Çalışmada kullanılan tüm değişkenler kategorik ya da sıralama ölçeğinde tanımlanmıştır. Modellemeye giren etmenler içinden sadece üçü anlamlı bir lojistik regresyon modeli oluşturur. Buna göre bir yazılım projenin başarısı iyi tanımlanan gereksinimler, projeye geç katılan elemanlar ve proje yöneticisinin becerisiyle belirlenir.
Jun ve diğ.’lerinin (2011) yürüttüğü bir anket çalışmasında proje belirsizliği, proje planlama ve kontrol, iç bütünleşme ve kullanıcı katılımı ile geliştirme süreç performansı ve nihai ürün performansı arasındaki ilişkiler incelenir. 93 adet yazılım proje yöneticisinin katıldığı bu çalışmada süreç başarısı, takvim ve bütçe hedeflerine uymadaki başarının bir göstergesidir. Yine bu çalışmada proje belirsizliği dört farklı
etmenin (proje büyüklüğü, teknik karmaşıklık, ekip yetkinliği ve müşterilerin ya da kullanıcıların tecrübesi) birlikte değerlendirilmesiyle elde edilir.
Narayanan ve diğ.’lerinin (2010) 186 adet yazılım projesi üzerinde gerçekleştirdiği bir çalışmada proje planlaması, iletişim etkinliği ve ekip sürekliliği etmenleri ele alınmıştır. Çalışma bu üç etmenin proje performansını olumlu yönde etkilediği ortaya çıkmış; büyük ölçekli projelerde ekip sürekliliğinin proje performansı üzerindeki etkisinde bir azalma olduğunu görülmüştür. Bu çalışmada kullanılan tüm değişkenler beşli Likert ölçeğinde tanımlanmıştır.
Liu ve diğ.’lerinin (2011) 114 adet BT profesyoneli arasında gerçekleştirdiği bir anket çalışmasında kişiler arası çatışmalar, gereksinimlerin belirsizliği ve gereksinimlerin çeşitliliği etmenleri ele alınmış; bu etmenlerle proje performansı arasındaki ilişkiler incelenmiştir. Bu çalışmada kullanılan tüm değişkenler yine beşli Likert ölçeğinde tanımlanmıştır. Çalışmada proje performansı, proje hedeflerine ulaşma yetkinliği, yapılan işin miktarı ve kalitesi, takvime ve bütçeye sadık kalma, çalışma morali ve görev verimliliği değişkenlerinin birlikte değerlendirilmesiyle elde edilmiştir. Yine burada kişiler arası çatışmalar ile kullanıcı ve BT geliştiricileri arasındaki çatışmalar kastedilmiştir.
Yürütülen literatür araştırmasında elde edilen bilgiler müşteri ve son kullanıcı kaynaklı riskler, gereksinim kaynaklı riskler, ekip elemanlarının neden olduğu riskler ve proje yönetimi riskleri, tasarım ve gerçekleştirme riskleri, geliştirme ve test ortamı, teknolojisi ve araçlarıyla ilgili riskler, dış çevre bağımlılıkları ve genel proje