RAID Log'unuz Gerçekten Çalışıyor mu? Risk Yönetiminin Sahadaki Hali

Neredeyse her projede bir risk kaydı vardır. Ve neredeyse her risk kaydı ölüdür.

Belirtileri bellidir: en son üç ay önce güncellenmiştir; içindeki maddelerin yarısı çoktan gerçekleşmiştir; her riskin "sahibi" proje yöneticisidir; "olasılık: orta, etki: yüksek" yazılmıştır ve bunun ne anlama geldiğini kimse tanımlamamıştır.

Bu belge denetimde gösterilir, kimse okumaz, proje ise kayıtta yazmayan bir sebepten gecikir.

Bu yazı, bir RAID log'un yaşaması için gereken şartlar ve doğrudan kopyalayıp kullanabileceğiniz bir yapı üzerine.

RAID nedir, neden dört ayrı şey?

R, Risks (Riskler): Henüz gerçekleşmemiş, gerçekleşirse projeyi etkileyecek olaylar. A, Assumptions (Varsayımlar): Doğru kabul edip üzerine plan kurduğunuz, ama kanıtlamadığınız şeyler. I, Issues (Sorunlar): Zaten gerçekleşmiş, şu anda projeyi etkileyen şeyler. D, Dependencies (Bağımlılıklar): Kontrolünüz dışındaki, sizin ilerlemenizi belirleyen şeyler.

Dördünün ayrı tutulmasının sebebi, dördünün farklı eylem gerektirmesidir:

• Risk. Ne yaparsınız: İzlersiniz ve azaltma planı hazırlarsınız
• Varsayım. Ne yaparsınız: Doğrularsınız (en çok atlanan eylem budur)
• Sorun. Ne yaparsınız: Çözersiniz, sahibi ve tarihi olur
• Bağımlılık. Ne yaparsınız: Yönetirsiniz (karşı tarafla anlaşma ve takip)

Bu ayrımın en kritik yeri varsayımlardır. Bir projedeki en büyük tehlike, listelenmiş risklerden değil, hiç sorgulanmamış varsayımlardan gelir. "Test tesisi Mart'ta müsait olacak", "müşteri gereksinimi değiştirmeyecek", "o mühendis projede kalacak". Bunların hiçbiri risk olarak yazılmaz, çünkü kimse onları bir belirsizlik olarak görmez.

Kural: her varsayımın bir doğrulama tarihi olmalı. O tarihte doğrulanmayan varsayım, otomatik olarak riske dönüşür.

Ölü bir risk kaydının dört belirtisi ve panzehirleri

1. Tetikleyici yok

En yaygın kusur. Bir risk kaydında "olasılık" ve "etki" vardır ama "bunun gerçekleştiğini nereden anlayacağız" sorusunun cevabı yoktur.

Tetikleyici olmayan risk, izlenemez. Sadece bir gün sorun olarak karşınıza çıkar.

Kötü: "Kritik bileşen tedarikinde gecikme riski." İyi: "Kritik bileşen tedarikinde gecikme riski. Tetikleyici: tedarikçinin teyit ettiği sevk tarihi, ihtiyaç tarihinden 4 haftadan az bir marjla kalırsa. Kontrol sıklığı: haftalık."

Tetikleyici, riski bir kaygı olmaktan çıkarıp izlenebilir bir sinyale çevirir.

2. Sahibi proje yöneticisi

Her riskin sahibi proje yöneticisiyse, hiçbir riskin sahibi yok demektir.

Risk sahibi, o riski azaltacak eylemi yapabilecek yetkiye sahip kişi olmalıdır. Tedarik riski tedarik müdürünün, teknik risk ilgili tasarım liderinin, kaynak riski bölüm yöneticisinindir. Proje yöneticisi kaydı yönetir, riskin kendisini değil.

Bunun bir yan faydası da var: bir riski birine atadığınızda, o kişi ilk kez o riski gerçekten düşünür.

3. Ölçek tanımsız

"Olasılık: yüksek" farklı insanlar için farklı şey demektir. Ölçeği tanımlayın ve projenin ilk haftasında ekiple üzerinde anlaşın.

• 1. Olasılık: < %10 · Etki (takvim): < 1 hafta · Etki (maliyet): < %1
• 2. Olasılık: %10–30 · Etki (takvim): 1–2 hafta · Etki (maliyet): %1–3
• 3. Olasılık: %30–50 · Etki (takvim): 2–4 hafta · Etki (maliyet): %3–7
• 4. Olasılık: %50–70 · Etki (takvim): 1–2 ay · Etki (maliyet): %7–15
• 5. Olasılık: > %70 · Etki (takvim): > 2 ay · Etki (maliyet): > %15

Sayılar projenize göre değişir; önemli olan yazılı ve ortak olmasıdır. Tanımsız ölçek, tartışmayı riskin kendisinden ölçeğin ne anlama geldiğine kaydırır.

4. Kapanma disiplini yok

Risk kayıtları büyür, küçülmez. Bu, ölmüş bir kaydın en görünür işaretidir.

Bir risk üç şekilde kapanır: gerçekleşti (sorun kaydına dönüşür), geçti (artık mümkün değil), ya da kabul edildi (azaltmıyoruz, göze alıyoruz). Üçüncüsü meşru bir seçenektir ama tek şartla: kabul edenin adı yazılmalıdır.

"Bu riski kabul ediyoruz" cümlesinin altında bir isim yoksa, o risk kabul edilmemiş, unutulmuştur. Ve gerçekleştiğinde kimse sorumluluğu üstlenmez.

Kullanılabilir şablon

Aşağıdaki alanlar bir tablo, bir Jira alanı ya da bir Excel sütunu olabilir; araç önemli değil.

Risk kaydı:

• ID. Açıklama: R-001
• Tanım. Açıklama: "Eğer [neden] olursa, [olay] gerçekleşir ve [etki] olur" formatında
• Kategori. Açıklama: Teknik / Tedarik / Kaynak / Dış / Sözleşme
• Olasılık (1–5). Açıklama: Tanımlı ölçekten
• Etki (1–5). Açıklama: Tanımlı ölçekten
• Skor. Açıklama: Olasılık × Etki
• Tetikleyici. Açıklama: Gerçekleştiğini nereden anlayacağız
• Kontrol sıklığı. Açıklama: Haftalık / iki haftalık / aylık
• Azaltma eylemi. Açıklama: Ne yapıyoruz
• Acil durum planı. Açıklama: Gerçekleşirse ne yapacağız
• Sahibi. Açıklama: İsim (proje yöneticisi değil)
• Son güncelleme. Açıklama: Tarih
• Durum. Açıklama: Açık / Gerçekleşti / Geçti / Kabul edildi (kabul eden: isim)

Tanım alanındaki "eğer-o zaman-bu yüzden" formatı önemli. "Tedarik riski" bir risk tanımı değildir. "Eğer tedarikçi Mayıs sevkiyatını kaçırırsa, entegrasyon testi başlayamaz ve teslim 6 hafta kayar" bir risk tanımıdır, çünkü hem izlenebilir hem ölçülebilir.

Toplantı ritmi: kayıt bu sayede yaşar

Belge tek başına yaşamaz. Onu ayakta tutan şey ritimdir.

• Haftalık (15 dk, proje toplantısının içinde): skoru en yüksek beş risk gözden geçirilir. Tetikleyicisi çalan var mı? Yeni risk var mı? Kapanacak olan var mı? Hepsi değil, sadece beşi.
• Aylık (45 dk, ayrı): kaydın tamamı. Skorlar güncellenir, sahipler doğrulanır, kapanmayanlar sorgulanır, varsayımların doğrulama tarihleri kontrol edilir.
• Kilometre taşlarında: yeni faz, yeni risk profili. Tasarım dondurma, kalifikasyon başlangıcı, seri üretime geçiş; her biri kaydın baştan gözden geçirilmesini gerektirir.

Haftalık gözden geçirmeyi 15 dakikada tutmanın yolu, sadece ilk beşe bakmaktır. Kaydın tamamını her hafta okumaya kalkan ekip, üçüncü haftada bunu yapmayı bırakır.

Savunma sanayiine özgü iki not

Sözleşme riski ile teknik risk aynı kayıtta durmalı. Bu sektörde bir teknik gecikmenin sonucu teknik değildir; cezai şart, hakediş gecikmesi, program takvimi kaymasıdır. İkisini ayrı belgede tutan kurumlar, teknik riskin ticari sonucunu geç görür.

Gizlilik sınıfı riski gerçek bir risk kategorisidir. Bir alt yüklenicinin ihtiyaç duyduğu bilgiye erişim yetkisinin zamanında çıkmaması, personelin güvenlik soruşturmasının uzaması, bir belgenin yanlış sınıflandırılması. Bunlar takvimi teknik problemlerden daha sık ve daha sert vurur. Risk kaydında ayrı bir kategori olarak yer almalı.

Kapanış

Risk yönetiminin amacı riskleri ortadan kaldırmak değildir. Ar-Ge yapıyorsanız riskiniz olacak; risksiz Ar-Ge, Ar-Ge değildir.

Amaç, hangi riski bilerek aldığınızı bilmektir. Gerçekleşen bir riskin sizi hazırlıksız yakalamaması, kaydınızın çalıştığının tek gerçek kanıtıdır.

Ve o kayıt, denetim için tutuluyorsa hiçbir zaman çalışmayacaktır.

---

Bu yazıdaki görüşler şahsıma aittir, çalıştığım kurumları bağlamaz.