30 saniyede özet

Sorun yönetimi, gerçekleşmiş ve proje hedeflerini etkileyen problemleri kaydetme, sahiplenme, çözme ve sonucu doğrulama sürecidir. Eskalasyon, ekibin yetkisi veya kapasitesi dışında kalan bir çözüm ihtiyacını karar verebilecek kişiye ya da kurula taşımaktır. İyi bir eskalasyon; mevcut durumu, etkisini, denenen adımları, seçenekleri ve gereken karar tarihini açıklar. Proje yönetim ofisinin, yani PMO’nun katkısı, açık sorunları sıralamanın yanında karar bekleyen işleri görünür kılmaktır. Sorun bir yöneticiye bildirildiğinde çözülmüş olmaz; alınan kararın uygulanması ve etkisinin doğrulanması gerekir.

Neden önemli?

Bir müşteri test ortamına erişemediğinde ekip teknik inceleme başlatabilir. Ancak engel, müşteri tarafındaki erişim onayının verilmemesi ise inceleme tek başına ilerleme sağlamaz. Toplantılarda “Çalışmalar sürüyor” denirken asıl beklenen şey bir karardır. Bu ayrım yapılmadığında ekip çalışıyor görünür, fakat teslimat bekler.

Sorunun geç bildirilmesi, yönetimin seçeneklerini azaltır. Testler başlayamadığı halde durum olumlu raporlanırsa müdahale ihtiyacı son anda ortaya çıkar. Diğer yandan her küçük aksaklığı üst yönetime taşımak da karar akışını zorlaştırır. Yönetici, kendi yetkisini gerektiren konuyla ekip içinde çözülebilecek işi ayırt edemeyebilir.

İş analisti için sorun yönetimi, belirsiz bir şikâyeti somut etkiye dönüştürme fırsatıdır. Ürün sahibi, çözüm seçeneklerinin kullanıcı ve öncelik etkisini değerlendirebilir. Proje yöneticisi, aksiyonları ve karar ihtiyacını koordine eder. PMO ise projeler arasında tekrar eden onay gecikmelerini, kaynak çatışmalarını veya tedarikçi sorunlarını birlikte görebilir.

Yönetici açısından önemli soru, sorunu kimin ilk bildirdiğinden çok hangi kararın hangi tarihe kadar gerektiğidir. Sorun bildirmek kişisel başarısızlık gibi algılanırsa kayıtlar geç açılır. Açık iletişimi teşvik eden bir yönetim düzeni, çözüm için kullanılabilecek zamanı korur.

Terim nedir?

Issue, proje yönetiminde mevcut ve ele alınması gereken sorun veya çözülmemiş konu anlamında kullanılır. Risk ise gerçekleşmesi belirsiz olan gelecekteki olay ya da koşuldur. “Erişim onayı gecikebilir” bir risktir; erişim sağlanmadığı için planlanan testin başlayamaması mevcut sorundur. Risk gerçekleştiğinde sorun kaydıyla bağlantı kurulabilir.

Sorun sahibi, çözümün koordinasyonundan ve durum bilgisinin güncel tutulmasından sorumludur. Her işi kendisinin yapması gerekmez. Teknik aksiyonu geliştirme ekibi, onayı müşteri, kaynak kararını sponsor verebilir. Bu nedenle sorun sahibi ile belirli bir aksiyonun sahibi ve karar yetkilisi ayrı gösterilmelidir. Dış bir tarafa sorumluluk atamak, o tarafın rolü kabul ettiği doğrulanmadıkça yeterli değildir.

Eskalasyon, konunun gerekli yetkiye sahip seviyeye taşınmasıdır. Bu seviye her zaman en üst yönetim değildir; ekip lideri, başka bir bölümün yöneticisi veya ortak yönlendirme kurulu olabilir. Yönlendirme kurulu, proje yönü ve önemli kararlar için oluşturulan yetkili gruptur. Eskalasyon yolu ve eşikleri mümkün olduğunca sorun çıkmadan belirlenmelidir.

Eşikler yalnızca sorunun kaç gündür açık olduğuna dayanmaz. Müşteri etkisi, kritik teslimatın durması, güvenlik koşulları, kaynak ihtiyacı veya ekipler arası anlaşmazlık da dikkate alınır. Kritik yol, proje bitişini belirleyen faaliyet zinciridir; bu zinciri durduran sorunda beklemek, karar seçeneklerini hızla daraltabilir.

Öncelik ile etki de ayrılmalıdır. Sorunun etkisi büyük olabilir, ancak müdahale için zaman bulunabilir. Daha sınırlı bir etki ise hemen karar gerektirebilir. Kayıtta hem etkilenen hedef hem gereken kararın son tarihi açıklanmalıdır. Kapanış koşulu da baştan tanımlanır: bir aksiyonun tamamlanması ile sorunun etkisinin giderilmesi aynı şey olmayabilir.

Gerçek vaka: Danimarka’daki BT programında ortak karar düzeni

Pernille Eskerod ve Eva Riis’in PMI tarafından yayımlanan 2008 tarihli araştırması, Danimarka’daki şirketlerin ortak proje yönetimi yaklaşımını inceler. Adı açıklanmayan büyük bir BT sağlayıcısı, 60’tan fazla müşteri projesinden oluşan program için merkezi PMO ve ortak yönetim modeli kurmuştur.

Müşteri tarafında paralel proje organizasyonları ve ortak yönlendirme kurulları oluşturulmuştur. Kurul üyelerinin karar verebilecek resmî yetkiye sahip olmasına dikkat edilmiştir. PMO, bir sorun çıktığında ne yapılacağını açıklayan resmî eskalasyon prosedürü geliştirmiş; ilerleme ve çözülmesi gereken konular yeşil, sarı ve kırmızı göstergelerle izlenmiştir.

Bazı proje yöneticileri ayrıntılı takibi başlangıçta ağır bulmuştur. Ancak yüksek bağımlılık ve sıkı tarihler içeren bu programda ortak yaklaşımı yararlı değerlendirmişlerdir. Araştırma, eskalasyonun daha geniş bir yönetim modeliyle birlikte kullanıldığını gösterir. Bildirilen faydaları tek başına eskalasyon prosedürüne bağlamak, uygulamanın diğer unsurlarını göz ardı etmek olur.

Kaynak: Pernille Eskerod ve Eva Riis, “Creating value by building an intra-organizational common frame of reference for project management”, PMI, 16 Temmuz 2008.

Varsayımsal örnek: Müşteri kabul testinin erişim nedeniyle durması

Bir kurumsal yazılım projesinde müşteri temsilcileri kabul testine başlayamaz. Test ortamı hazırdır, ancak müşterinin kimlik yönetimi ekibi kullanıcı erişimlerini açmamıştır. Proje yöneticisi sorunu kaydeder; erişim talebinin mevcut durumunu ve teknik bir arıza olup olmadığını doğrular.

İş analisti, hangi testlerin engellendiğini ve müşteri kabulünün tamamlanmasına etkisini açıklar. Sadece “Müşteri bekleniyor” yazmak yerine gerekli kullanıcı rolleri, erişim koşulları ve engellenen senaryolar belirtilir. Müşteri tarafındaki sorumlu kişiyle aksiyon ve hedef tarih üzerinde anlaşılır.

Erişim kararı için mevcut sorumlunun yetkisi yetersizse konu belirlenen karar merciine taşınır. Eskalasyon notunda erişim talebinin geçmişi, denenen adımlar ve takvim etkisi yer alır. Seçenekler; onaylı erişimleri hızlandırmak, uygun senaryoları kontrollü biçimde farklı aşamada yürütmek veya kabul takvimini yeniden düzenlemek olabilir. Geçici erişim seçeneği, ilgili güvenlik koşulları doğrulanmadan önerilen çözüm haline getirilmez.

Karar yetkilisine, hangi tarihten sonra canlıya geçiş hazırlığının etkileneceği açıklanır. Böylece aciliyet, mesajın tonundan değil, plan üzerindeki etkiden anlaşılır. Ek kapasite isteniyorsa bunun hangi işi hızlandıracağı da belirtilir.

Erişimler açıldığında kayıt hemen kapatılmaz. Kullanıcıların gerekli senaryoları çalıştırabildiği doğrulanır; testlerin yeni planı ve müşteri onayı netleştirilir. Sorun çözülse de oluşan takvim sapması ayrı olarak izlenir. PMO, sonraki projelerde erişim hazırlığının daha erken başlatılması için ortak süreci gözden geçirir.

Yaygın üç hata

  1. Karar talebi yerine şikâyet göndermek. “Diğer ekip destek vermiyor” ifadesi çözüm için gereken bilgiyi sağlamaz. Mevcut engel, somut etki, denenen adımlar ve istenen karar açıklanmalıdır. Kişiler hakkında varsayım üretmek yerine doğrulanabilir durum sunulması, tarafların birlikte çözüm geliştirmesini kolaylaştırır.
  2. Eskalasyonu geciktirmek veya her şeyi eskale etmek. İlk yaklaşım yönetimin müdahale zamanını tüketir; ikinci yaklaşım karar kapasitesini dağıtır. Etki ve yetki eşikleri tanımlanmalı, konu bu eşiklere göre yönlendirilmelidir. Acil müdahale gerektiren bir durum sıradaki rutin toplantıya kadar bekletilmemelidir.
  3. Bildirimi kapanış saymak. Bir yönetici bilgilendirildiğinde sorun kaydı açık kalır. Karar, uygulama sorumlusu ve doğrulama koşulu izlenmelidir. Geçici çözüm kullanılıyorsa kalıcı çözüm ihtiyacı ayrıca görünür tutulmalıdır. Aksi halde kısa süreli önlem, takip edilmeyen işletim yüküne dönüşebilir.

Mini uygulama: Tek sayfalık eskalasyon notu

Ekibinizin çözemediği bir mevcut sorunu seçin. Aşağıdaki alanları, karar verecek kişinin konuyu ilk kez okuyacağını varsayarak doldurun.

Sorun kimliği ve açılış tarihi
—
Doğrulanmış mevcut durum
—
Etkilenen teslimat ve müşteri ihtiyacı
—
Takvim, maliyet, kalite ve diğer etkiler
—
Sorun sahibi ve aksiyon sahipleri
—
Denenen adımlar ve sonuçları
—
Ekip yetkisini aşan engel
—
Karar seçenekleri ve sonuçları
—
Önerilen seçenek ve gerekçesi
—
İstenen karar ve karar yetkilisi
—
Kararın verilmesi gereken son tarih
—
Karar verilmezse beklenen sonuç
—
Uygulama sorumlusu ve takip tarihi
—
Kapanış koşulu ve doğrulama kanıtı
—

Notu hazırladıktan sonra istenen kararın tek cümlede anlaşılabildiğini kontrol edin. Takipte açık sorunların yaşını, karar bekleme süresini ve yeniden açılan kayıtları birlikte inceleyin. Bu bilgiler, tek tek sorunların yanında karar sürecindeki tekrar eden engelleri de görünür kılar.

İlgili terimler

Issue Log, Risk Register, Escalation Matrix, Decision Log, Steering Committee, Project Sponsor, RACI, Root Cause Analysis, Corrective Action, Dependency Management, Critical Path, Change Control