CHAOS raporu ve başarısızlık istatistikleri

Sahadan bir an

Salı öğleden sonra, küçük toplantı odası. Bir proje yönetim yazılımı firmasının satış temsilcisi Ertan, Ilgın'a ve bilgi işlemden Onur'a sunum yapıyor. Ekranda büyük harflerle bir sayı var.

Ertan: Araştırmalar gösteriyor ki yazılım projelerinin yalnızca yüzde on altısı başarılı oluyor. Geri kalanı ya geç kalıyor, ya bütçeyi aşıyor, ya da iptal ediliyor.

Onur: Hangi araştırma?

Ertan: Dünyanın en çok bilinen proje raporu. Herkes kullanır bu rakamı.

Ilgın: Başarılı derken neyi kastediyorlar?

Ertan: Zamanında, bütçesinde ve istenen özelliklerle biten proje.

Ilgın: Peki tahmin baştan iyimser yapıldıysa? Proje iyi yürüse de o tahmini tutturamaz, değil mi?

Ertan bir an duraklıyor, sonra sunumun bir sonraki sayfasına geçiyor. Ilgın'ın sorusu, başarısızlık istatistiklerinin en zayıf yerine dokundu. Geçen derste başarının iki anlamını ayırdık; şimdi bir adım daha atmak gerekiyor: bir sayı "başarılı" dediğinde, bunu hangi tanımla ve neyle ölçtüğünü sormak. Bu ders, proje dünyasının en çok alıntılanan istatistiğini, CHAOS raporunu, bu soruyla inceliyor.

Kavram

Bir başarı oranı, tek başına bir gerçeği değil, bir ölçüm tercihini yansıtır. "Projelerin yüzde kaçı başarılı?" sorusunun cevabı, önce "başarılı"nın nasıl ölçüldüğüne bağlıdır.

CHAOS raporu, Standish Group adlı bir danışmanlık şirketinin 1994'ten beri yayımladığı ve yazılım projelerini başarılı, sorunlu ve başarısız diye sınıflayan bir rapordur. Raporun başarı tanımı, geçen dersteki ayrıma göre, tamamen proje yönetimi başarısının tarafındadır: proje planlanan maliyet, süre ve işlevsellikle bitti mi? Ürünün kullanılıp kullanılmadığı, fayda üretip üretmediği bu tanımda yer almaz.

Bu tanımın bir sorunu daha var ve Ilgın'ın sorusu tam onu buldu. "Planlanan maliyet ve süre", projenin başında yapılmış tahminlerdir. Tahmin iyimser yapıldıysa, proje ne kadar iyi yürütülürse yürütülsün onu tutturamaz ve "başarısız" sayılır. Tahmin bilerek şişirildiyse, proje kötü yürütülse bile onu tutturabilir ve "başarılı" sayılır. Yani böyle bir oran, projelerin iyi yönetilip yönetilmediğinden çok, baştaki tahminlerin ne kadar iyimser olduğunu ölçüyor olabilir. İkinci derste gördüğümüz planlama yanılgısı burada bir istatistiğin içine gizlenir.

Tanımın yanında ikinci bir soru da örneklemdir: rakam hangi projelerden geliyor? Bir anketi kimin cevapladığı, sonucu sessizce şekillendirir. Sorunlu bir projeyi yeni yaşamış bir yönetici, sorunsuz bir projeyi bitirmiş bir yöneticiden daha istekli cevap verebilir; bir danışmanlık firmasına başvuran kurumlar, zaten sorun yaşayan kurumlardır. Bu yüzden bir oran, "projelerin" değil, belirli bir yoldan seçilmiş "bu projelerin" oranıdır ve o yol bilinmeden genelleme yapılamaz.

Bir okul müdürü bir toplantıda "dijital eğitim projelerinin çoğu başarısız oluyor" diye bir cümle duysun. Aklındaki ilk soru, bu cümlenin hangi okulları, hangi süre içinde ve neye bakarak "başarısız" saydığı olmalıdır: öğrencilerin notlarına mı, öğretmenlerin araçları kullanıp kullanmadığına mı, yoksa satın alınan tabletlerin teslim tarihine mi? Her birinin cevabı başka bir sayı verir.

Perde arkası

CHAOS rakamlarının en kapsamlı eleştirisi, raporun kendi tanımını gerçek verilere uygulayan iki araştırmacıdan geldi.

Eleştiri daha önce de dile getirilmişti. Yazılım mühendisliği yazarı Robert Glass, raporun gerçekten bir yazılım krizini anlatıp anlatmadığını soran kısa bir yazı yayımladı.

İki metin birlikte okunduğunda ortaya çıkan ders, CHAOS raporunun kendisinden çok onun kullanımıyla ilgili: yüzde on altı rakamı yirmi yılı aşkın süredir sunumlarda, satış konuşmalarında ve kitaplarda, tanımı ve yöntemi sorulmadan dolaşıyor. Rakamın bu kadar dayanıklı olmasının nedeni de anlaşılır: kısa, çarpıcı ve herkesin yaşadığı bir hayal kırıklığını doğruluyor. Bir araç, bir eğitim ya da bir danışmanlık satmak isteyen herkes için de kullanışlı bir açılış cümlesi.

Yaygın yanılgılar

İki sürüm

Ertan gittikten bir saat sonra genel müdürün e-postası geliyor: yazılım hakkında Ilgın'ın görüşü isteniyor. Ilgın notu iki biçimde yazabilir.

Zayıf sürüm

Konu: Proje yönetim yazılımı

Görüş: Araştırmalara göre projelerin yalnızca yüzde on altısı başarılı oluyor. Bizim de bir araca ihtiyacımız var.

Öneri: Satın alalım.

Güçlü sürüm

Konu: Proje yönetim yazılımı

Sunumdaki iddia: Projelerin yüzde on altısı başarılı. Bu rakam 1994 tarihli bir rapordan; başarıyı yalnızca baştaki maliyet, süre ve kapsam tahminlerinin tutup tutmadığıyla ölçüyor ve yöntemi bağımsız araştırmacılar tarafından ciddi biçimde eleştirildi.

Bizim için asıl soru: Bizim projelerimiz neden gecikiyor? Geçen yılki torpido kapağı gecikmesinin kaynakları tahmin, yazılı olmayan kapsam ve sorulmayan tedarik süresiydi; bir yazılım bunların hangisini çözer?

Öneri: Önce son iki yılın beş projesinin kendi kayıtlarımıza bakalım; sorunun aracın yokluğundan mı geldiğini görelim. Sonra ücretsiz bir deneme sürümüyle tek bir projede deneyelim.

Zayıf sürüm sunumdaki rakamı olduğu gibi aktarıyor ve ondan bir satın alma kararı çıkarıyor. Rakamın tanımı sorulmamış, firmanın kendi durumuyla bağlantısı kurulmamış; öneri, rakamın yarattığı kaygıya dayanıyor. Güçlü sürüm rakamı reddetmiyor ama yerine koyuyor: neyi ölçtüğünü ve tartışmalı olduğunu bir cümlede söylüyor. Asıl değeri ikinci ve üçüncü satırlarında: dışarıdaki bir rakam yerine fabrikanın kendi gecikme nedenlerine bakıyor ve bir aracın bunlardan hangisini çözeceğini soruyor. Öneri de bir kanıt toplama adımıyla başlıyor. Ilgın yazılıma karşı değil; satın alma kararının kendi verilerine dayanmasını istiyor.

Bağlam notu

Başarısızlık istatistiklerine şüpheyle bakmak, onları tamamen yok saymak anlamına gelmez. Projelerin sık sık geciktiği ve bütçeyi aştığı, farklı yöntemlerle yapılmış başka araştırmalarda da görülen bir örüntüdür; büyük projelerin verisini ileride ayrıca inceleyeceğiz. Sorun örüntünün kendisi değil, belirli bir yüzdenin tanımı sorulmadan bir karar gerekçesine dönüştürülmesidir.

Neyle bileceğiz? Bir rakamla karşılaştığında üç soru yeterli: başarıyı nasıl tanımlamış, hangi projelere bakmış ve benim projelerime ne kadar benziyor? Bu üç sorunun cevabı bulunamıyorsa, rakamı bir karar gerekçesi olarak değil, en fazla bir merak kaynağı olarak kullanmak gerekir. Kendi kurumunun kayıtları, ne kadar küçük olursa olsun, çoğu zaman uzaktaki bir yüzdeden daha iyi bir rehberdir.

Uygulama

Retro sorusu

Son kez bir kararı bir istatistiğe dayanarak verdiğinde, o istatistiğin "başarı"yı nasıl tanımladığını biliyor muydun?

Kapanış

1. Bir başarı oranı bir gerçeği değil, bir işlemsel tanımı yansıtır; önce başarının nasıl ölçüldüğünü sormak gerekir.
2. CHAOS raporu başarıyı baştaki tahminlerin tutmasıyla ölçer; Eveleens ve Verhoef bu tanımın tek yönlü olduğunu ve gerçek projelere uygulandığında anlamsız sonuçlar verdiğini gösterdi.
3. Uzaktaki bir yüzde yerine kendi projelerinin geçmişine bakmak, çoğu zaman daha iyi bir karar gerekçesidir.

Beş soru

1. Ilgın'ın "tahmin baştan iyimser yapıldıysa?" sorusu CHAOS tanımının hangi zayıflığına dokunuyor?
2. CHAOS'un başarı tanımı geçen dersteki iki başarıdan hangisine aittir?
3. Eveleens ve Verhoef'in eleştirisinin dayandığı veri nedir ve ne buldular?
4. Bir derneğin yöneticisi "bağış kampanyalarının yüzde sekseni hedefini tutturamıyor" diye bir cümle duyuyor ve kendi kampanyasını iptal etmeyi düşünüyor. Ne sorarsın?
5. Güçlü sürümde Ilgın neden yazılım kararını önce kendi kayıtlarına bağlıyor?

Yanıtlar

1. Tanımın yalnızca baştaki tahminlerin tutup tutmadığına bakmasına. Tahmin iyimserse iyi yürütülen proje de "başarısız" sayılır; oran, yönetimden çok tahminin iyimserliğini ölçebilir.
2. Proje yönetimi başarısına: maliyet, süre ve işlevselliğin plana uyup uymadığı. Ürünün kullanılıp kullanılmadığı ve fayda üretip üretmediği tanımda yer almaz.
3. 1.211 gerçek projeye ait 5.457 tahminden oluşan kendi veri setlerine; Standish'in tanımlarını bu verilere uyguladıklarında çıkan rakamların projelerin gerçek durumunu hiç yansıtmadığını buldular. Çekici yanlış cevap "CHAOS her zaman yanlıştı" olurdu; eleştiri tanımın kendisine ve rakamların tanım sorulmadan kullanılmasına yöneliktir.
4. Hedefi tutturmayı nasıl tanımlamışlar, hangi kampanyalara bakmışlar ve benim kampanyama ne kadar benziyor? Belki hedefler baştan iyimser konmuştur; belki örneklem çok farklı kurumlardan gelir. Cevapsız bir yüzde, bir kampanyayı iptal etmek için yeterli gerekçe değildir.
5. Çünkü dışarıdaki rakam fabrikanın kendi gecikme nedenlerini söylemiyor; bir aracın değeri, gerçek sorunu çözüp çözmediğine bağlı. Kendi kayıtları sorunu gösterirse, karar kaygıya değil kanıta dayanır.

Sonraki derse köprü

Ilgın'ın önerisi kendi kayıtlarına bakmaktı; peki projeler ne zamandan beri kayıt tutuyor? Büyük yapıları inşa edenler yüzyıllar önce de işçilerin, malzemenin ve paranın hesabını defterlere yazıyordu. Proje yönetiminin tarihini açan 2.1, büyük yapıların örgütlenişine bu defterlerden bakıyor.