Bir risk çoğu zaman projenin sonunda ortaya çıkmaz; projenin sonunda artık saklanamaz hâle gelir.
Test ortamının zamanında hazırlanmayacağı, müşteri onayının gecikeceği, kritik bilginin tek kişide bulunduğu veya canlıya geçiş planının yeterince denenmediği daha önce fark edilmiş olabilir.
Ancak bu konular kaydedilmez, sahiplenilmez ve düzenli olarak izlenmezse proje sonuna kadar sessizce büyür. Canlıya geçiş yaklaştığında ise artık risk değil, çözülmesi gereken acil bir sorun hâline gelir.
Yönettiğim projelerde en büyük etkiyi tamamen öngörülemeyen risklerin değil; sinyali daha önce alınan fakat zamanında aksiyon alınmayan konuların oluşturduğunu gördüm.
Risk yönetiminin amacı geleceği kusursuz biçimde tahmin etmek değildir. Belirsizliği görünür hâle getirerek, hareket alanımız daralmadan doğru kararı alabilmektir.
1. Risk Yönetimini Proje Başlangıcında Bırakmak
Proje başlangıcında bir risk listesi hazırlamak değerlidir. Fakat bu liste bir daha açılmıyorsa risk yönetimi yapılmış sayılmaz.
Proje ilerledikçe koşullar değişir:
- Yeni bağımlılıklar ortaya çıkar.
- Müşteri öncelikleri değişebilir.
- Teknik varsayımlar geçerliliğini kaybedebilir.
- Testlerde daha önce bilinmeyen sorunlar görülebilir.
- Başka bir ekibin gecikmesi projenizi etkileyebilir.
Bu nedenle risk listesi yaşayan bir çalışma aracı olmalıdır.
Her durum toplantısında bütün riskleri uzun uzun konuşmak gerekmez. On beş dakikalık kısa bir değerlendirme çoğu zaman yeterlidir:
- Yeni bir risk ortaya çıktı mı?
- Mevcut risklerin olasılığı veya etkisi değişti mi?
- Bir riskin tetikleyicisine yaklaşıyor muyuz?
- Alınması gereken fakat geciken bir aksiyon var mı?
Riskler ayrıca kapsam değişikliği, entegrasyon testi, kullanıcı kabulü ve canlıya geçiş gibi önemli aşamalardan önce yeniden gözden geçirilmelidir.
2. Riski Belirsiz Bir Cümleyle Yazmak
“Testlerde sorun çıkabilir” veya “müşteri gecikebilir” gibi ifadeler gerçek bir risk tanımı değildir.
Bu cümleler neyin takip edileceğini, ne zaman aksiyon alınacağını ve projenin nasıl etkileneceğini göstermez.
Bir riski yazarken üç soruya cevap vermek gerekir:
- Riski ortaya çıkarabilecek neden nedir?
- Hangi belirsiz olay gerçekleşebilir?
- Gerçekleşirse proje hedefi nasıl etkilenir?
Örneğin:
Banka test kullanıcıları planlanan tarihe kadar hazırlanmazsa entegrasyon testi için ayrılan süre daralabilir ve canlıya geçiş tarihi etkilenebilir.
Bu cümlede neden, gerçekleşebilecek olay ve proje üzerindeki etki açıkça görülür.
Risk ile mevcut sorunu da birbirinden ayırmak gerekir. Test kullanıcısının gecikme ihtimali bir risktir. Planlanan tarih geçtiği hâlde kullanıcının hâlâ hazırlanmamış olması ise artık bir sorundur.
Risk gerçekleştiğinde onu risk listesinde izlemeye devam etmek yerine sorun yönetimi ve eskalasyon sürecine taşımak gerekir.
3. Risk Puanı Verip Sahip ve Tetikleyici Belirlememek
Risklere olasılık ve etki puanı vermek önceliklendirme yapmamızı sağlar. Ancak bir riski “yüksek” olarak işaretlemek, tek başına onu yönetmez.
Her kritik riskin bir sahibi bulunmalıdır.
Risk sahibi bütün işi tek başına çözmek zorunda değildir. Ancak şu konuların takibinden sorumludur:
- Riskin durumunu izlemek
- Önleyici aksiyonların ilerlemesini takip etmek
- Tetikleyici koşulları kontrol etmek
- Gerektiğinde yanıt planını devreye almak
- Risk ekip yetkisini aşıyorsa eskale etmek
Bunun yanında her risk için mümkün olduğunca somut bir tetikleyici belirlenmelidir.
Örneğin “test ortamı gecikebilir” demek yerine, “test başlangıcından beş iş günü önce ortam hazır değilse konu eskale edilecek” gibi bir eşik belirlenebilir.
Tetikleyicisi olmayan riskler genellikle çok geç fark edilir. Çünkü ekip hangi noktada beklemeyi bırakıp harekete geçmesi gerektiğini bilemez.
4. Yanıt Planını Proje Planına Taşımamak
Risk kaydına “erken test yapılacak” veya “müşteriyle görüşülecek” yazmak bir yanıt planı değildir.
Risk için alınacak aksiyonun proje planında gerçek bir karşılığı olmalıdır:
- Aksiyon tam olarak nedir?
- Kim gerçekleştirecek?
- Hangi tarihe kadar tamamlanacak?
- Hangi ekip veya karara bağımlı?
- Tamamlandığını nasıl anlayacağız?
Risk yanıtlarını iki seviyede düşünmek gerekir.
İlk seviye, riskin gerçekleşme olasılığını veya etkisini azaltacak önleyici aksiyonlardır. İkinci seviye ise risk gerçekleştiğinde uygulanacak alternatif plandır.
Örneğin canlıya geçişte kullanılacak bir servisin kararsız çalışması riskse, erken yük testi önleyici aksiyon olabilir. Risk gerçekleştiğinde kullanılacak manuel işlem, geri dönüş veya alternatif çalışma yöntemi ise acil durum planıdır.
Risk için yalnızca “ne yapacağımızı biliyoruz” demek yeterli değildir. Yapılacak işin takvimde, sorumluluklarda ve kaynak planında yer alması gerekir.
5. Eskalasyon İçin Riskin Gerçekleşmesini Beklemek
Bazı ekipler riski eskale etmeyi başarısızlık olarak görür. Bu nedenle konuyu kendi içinde çözmeye çalışır ve yönetime ancak hareket alanı kalmadığında bilgi verir.
Oysa doğru eskalasyon, sorumluluktan kaçmak değildir. Ekibin yetkisini, bilgisini veya kaynaklarını aşan bir riski çözebilecek seviyeye taşımaktır.
Aşağıdaki durumlarda eskalasyon bekletilmemelidir:
- Risk birden fazla projeyi veya ekibi etkiliyorsa
- Müşteri ya da yönetim kararı gerekiyorsa
- Güvenlik, finans veya canlı sistem riski bulunuyorsa
- Takvim veya bütçe toleransı aşılmak üzereyse
- Ekip kendi imkânlarıyla riski azaltamıyorsa
Eskalasyon için riskin gerçekleşmesini beklediğinizde yöneticiden artık karar değil, acil müdahale istersiniz.
Erken eskalasyon daha fazla seçenek sunar. Geç eskalasyon ise çoğu zaman yalnızca daha pahalı ve daha riskli seçenekler bırakır.
Kullanılabilecek Basit Bir Risk Kartı
Risk yönetimi için karmaşık bir araca ihtiyaç yoktur. Aşağıdaki bilgilerin bulunduğu basit bir tablo çoğu proje için yeterli olabilir:
- Riskin açık tanımı
- Olasılık ve etki
- Risk sahibi
- Önleyici aksiyon
- Aksiyonun sorumlusu ve tarihi
- Takip edilecek tetikleyici
- Risk gerçekleşirse uygulanacak plan
- Eskalasyon eşiği
- Son değerlendirme tarihi
Buradaki amaç mümkün olduğunca fazla risk yazmak değildir. Projenin hedeflerini gerçekten etkileyebilecek belirsizlikleri görünür ve yönetilebilir hâle getirmektir.
Risk Yönetimi Sorun Çözmekten Önce Başlar
Projenin sonunda ortaya çıkan büyük sorunların bir kısmı, daha önce küçük birer sinyal olarak karşımıza çıkmıştır.
Risk yönetimi bu sinyalleri kaydetmekten ibaret değildir. Sinyali anlamlandırmak, bir sahip belirlemek, aksiyonu planlamak, tetikleyiciyi takip etmek ve gerektiğinde zamanında eskale etmektir.
Çünkü risk gerçekleşmeden önce seçenekleriniz vardır. Gerçekleştikten sonra ise çoğu zaman yalnızca sonuçlarını yönetirsiniz.