Premortem analizi yapmak için projenin hedefe ulaşamadığını düşünün ve bu sonuca hangi nedenlerin yol açmış olabileceğini yazın. Sonra önemli riskleri seçip erken işaretlerini ve uygulanacak önlemleri konuşun. Her önlemi sorumlu kişi ve kontrol tarihiyle kaydedin. Amaç geleceği tahmin etmek değil; henüz düzeltme imkanı varken zor soruları görünür kılmaktır.
“Bir sorun çıkarsa bakarız” yaklaşımı küçük işlerde bile beklenmeyen son dakika telaşı yaratabilir. Premortem, iş başlamadan konuşulması zor gelen olasılıklar için alan açar. Başarısızlık ihtimalini tartışmak, projenin başarısız olmasını istemek değildir.
Atlassian örneğinde endişe göreve dönüştürülüyor
Atlassian’ın premortem uygulaması ekip üyelerinin önce olası sorunları yazmasını, benzer düşünceleri gruplamasını ve önemli riskleri tartışmasını istiyor. Seçilen riskler için yapılacak hareket, sorumlu kişi ve tarih belirleniyor. Hazırlanan kayda daha sonra yeniden dönülmesi öneriliyor.
Bu örnekten üç mesaj çıkarabiliriz. Herkesin ilk anda aynı fikir etrafında konuşması yerine ayrı düşünmesine alan bırakmak yararlı olabilir. Riskleri listelemek yeterli değildir. Ayrıca tek bir toplantıda yazılan kayıt proje boyunca güncel kalmayabilir. Yeni bilgi geldikçe kontrol edilmelidir.
Burada risk olasılığı için uydurulmuş sayılar vermiyoruz. Elinizde gerçek veri varsa kullanabilirsiniz. Yoksa “Bu kesin olur” veya “Başarı ihtimali şu kadar” gibi ölçülmemiş sonuçlar yazmadan, etkisini ve hangi bilginin eksik olduğunu açık tutun.
Önce projenin başarısını tanımlayın
Neyin başarısızlık sayılacağı belli değilse farklı kişiler farklı şeyler yazacaktır. Projenin hedefini, teslimini ve önemli sınırını kısaca belirtin. “Yeni rapor hazırlamak” yerine “Müşteri temsilcilerinin yenileme görüşmesinde kullanacağı güncel raporu ortak kaynaktan hazırlamak” daha net bir başlangıçtır.
Belirsiz görevi netleştirme soruları bu hazırlık için kullanılabilir. Teslim tarihi, kapsam ve kontrol kişisi açık olsun. Premortem, henüz tanımlanmamış bir projeyi tek başına düzeltmez.
Ardından ekibe şu soruyu yöneltin: “Bu proje sonunda istediğimiz sonucu vermedi. Sizce hangi durum buna yol açmış olabilir?” Başlangıçta cevaplara hemen itiraz etmeyin. Önce farklı düşünceleri görün; sonra gerekçelerini ve mevcut bilgiyi konuşun.
Bir müşteri raporu için risk örneği
Şöyle bir durum düşünün: Farklı ekiplerin verisini tek müşteri raporunda birleştireceksiniz. İlk cevaplar “gecikme”, “veri hatası” ve “kimsenin kullanmaması” gibi geniş olabilir. Bunları daha somut hale getirin:
Olası neden | Erken işaret | Önlem | Kontrol kişisi |
Ekipler müşteri durumunu farklı tanımlıyor | Aynı müşteri iki kaynakta farklı görünüyor | Örnek kayıtlar üzerinde ortak tanım kontrolü | Veri sorumlusu |
Kullanıcı ihtiyacı geç öğreniliyor | İlk taslakta gereken bilgi bulunmuyor | Taslak öncesi kullanıcı görüşmesi | Rapor sahibi |
Tek bir kişiden bilgi bekleniyor | Başlangıç bilgisi gelmedi | Beklenen bilgi ve alternatif destek yolunu netleştirme | Proje sorumlusu |
Son kontrol zamanı ayrılmıyor | Teslimden hemen önce hesaplar değişiyor | Kontrol aşamasını takvimde ayırma | Rapor sahibi |
Bu tablo kişinin karakterini değil, işin koşulunu inceliyor. “Finans hep gecikir” yerine hangi bilginin ne zaman gelmesi gerektiğini konuşmak daha uygulanabilir bir önlem sağlar. Geniş suçlama, hem ilişkiyi zorlaştırır hem de gerçek nedenin görülmesini engeller.
Önlem için sorumlu yazarken kişinin kabulünü alın. Haritada adı bulunan herkes otomatik görev sahibi değildir. Yetki ve kapasite sorunu varsa ilgili karar kişisine taşıyın. Bir toplantıda görev dağıtılmış görünmesi, işin gerçekten üstlenildiğini kanıtlamaz.
Riskleri nasıl seçmelisiniz?
Her ihtimali aynı yoğunlukta ele alamazsınız. Etkisi, mevcut işaretleri ve önlem alınabilirliğini konuşun. Küçük ama sık görülen bir sorun ile seyrek ama ciddi etkisi olan bir durum farklı değerlendirme gerektirebilir. Veriniz yoksa bunu açık belirsizlik olarak tutun.
Bir riski sırf çok kişi söyledi diye kesin kabul etmeyin. Aynı düşünce ekipte yaygın olabilir ama dayanağı zayıf kalabilir. Karşı örnek veya kaynak isteyin. Önlem seçmeden önce sorunun zaten başka bir kontrol tarafından ele alınıp alınmadığını öğrenin.
İç iletişim gecikmeleri için yanıt bekleyen işlerin takibi kullanılabilir. Ancak her riski yeni toplantı açarak çözmeye çalışmayın. Bazen bir tanım, kontrol satırı veya erken örnek yeterlidir. Önlem, riskin gerçek nedenine bağlansın.
Geniş bir endişeyi erken işarete çevirin
Ekibin “Kullanıcılar raporu benimsemeyebilir” dediğini düşünün. Bu endişeyi doğrudan göreve çevirmek zordur. Önce hangi durumun bu riski göstereceğini konuşun. Kullanıcılar aynı bilgiyi başka dosyadan mı arıyor? Rapordaki tanımı mı anlamıyor? Gereken alan mı bulunmuyor?
Her cevap farklı önlem gerektirir. Alan eksikse kullanıcı örneğiyle taslağı incelemek uygun olabilir. Kaynak karışıyorsa ortak dosya yerini açıklamak gerekir. Tanım bilinmiyorsa kısa açıklama eklemek işe yarayabilir. Tek bir “eğitim verelim” görevi bütün nedenleri karşılamayabilir.
Önlemin kendisi yeni risk yaratıyor mu, buna da bakın. Her kontrol için ayrı onay eklemek teslimi zorlaştırabilir. Kontrolün gerçekten hangi hatayı yakaladığını ve kimin bilgisine ihtiyaç olduğunu belirleyin. Faydasını bilmediğiniz her yeni adımı güvenlik gibi sunmayın.
Sonraki görüşmede yalnız önlemin yapıldığını değil, erken işaretin değişip değişmediğini kontrol edin. Kullanıcı hala başka dosyaya gidiyorsa hazırlanan açıklama yeterli olmayabilir. Risk kaydı yaşayan bir çalışma notu olduğunda bu yeni bilgi görülebilir. İlk toplantıda doğru tahmin yapmış görünmekten çok, proje ilerlerken gerekli önlemi güncellemek önemlidir.
- Başarısızlığı düşünün
Projenin hedefe ulaşamadığını varsayıp olası nedenleri yazın.
- Önemli riski seçin
Benzer nedenleri ayırın; etki ve erken işaretleri konuşun.
- Önlemi göreve çevirin
Yapılacak hareketi, sorumlu kişiyi ve kontrol tarihini belirleyin.
Görüşme sonrasında kayıtla ne yapılmalı?
Risk kaydını ekipte bulunabilir yerde tutun. Önlemleri toplantı kararları takip tablosuna bağlayabilirsiniz. Böylece endişe listesi ve yapılacak iş birbirinden ayrı ama ilişkili kalır. Tamamlanan görevin ilgili riski gerçekten azaltıp azaltmadığını da kontrol edin.
Projede önemli kapsam veya kaynak değişikliği olduğunda kayda dönün. Yeni veri kaynağı farklı hata ihtimali getirebilir. Kullanıcı grubu değiştiyse eski görüşme yeterli olmayabilir. Başlangıçtaki risk listesini değişmez bir belge gibi tutmayın.
Küçük uygulama için bugün yürüttüğünüz bir işi seçin. Hedefe ulaşmamasına yol açabilecek üç somut neden yazın. Birini seçip erken işaret ve uygulanabilir önlem belirleyin. Bu düşünme biçimini kariyer gelişiminizle birlikte ele almak için kariyer gelişim kursunun programını inceleyebilirsiniz.
Sık sorulan sorular
Premortem karamsarlık yaratır mı?
Amaç suçlama veya felaket senaryosu biriktirmek değil, önlem seçmektir. Her risk için yapılabilecek hareketi konuşun. Kontrol edilemeyen endişeyi kesin sonuç gibi sunmayın.
Tek başınıza premortem yapabilir misiniz?
Küçük kişisel bir işte yapabilirsiniz. Ekipler arası projede farklı bilgiyi göremeyebilirsiniz; ilgili kişilerin görüşü önemlidir. Kendi tahmininizi ortak değerlendirme gibi göstermeyin.
Proje başladıktan sonra yapılabilir mi?
Evet, kalan aşamalar için yararlı olabilir. Hedefi ve mevcut durumu güncelleyerek başlayın. Geçmiş hatayı değerlendirmekle gelecekteki riski konuşmayı ayrı tutun.
Risk ortaya çıkmadıysa önlem gereksiz miydi?
Tek başına böyle sonuç çıkarılamaz. Önlem etkili olmuş olabilir veya koşullar değişmiştir. Sonucu ve kullanılan bilgiyi değerlendirip sonraki iş için kaydı güncelleyin.
