30 saniyede özet

Bağımlılık yönetimi, bir işin ilerlemesi için gereken dış girdileri tanımlama, karşılıklı doğrulama ve değiştiklerinde etkilerini yönetme sürecidir. Beklenen girdi bir yazılım bileşeni, onay, veri, uzman desteği veya kurumsal politika olabilir. Kritik soru yalnızca “Kimden ne bekliyoruz?” değildir. “Hangi koşullarda, ne zamana kadar kullanıma hazır olmalı ve gecikirse hangi karar gerekir?” sorusunu da yanıtlamak gerekir. Proje yönetim ofisinin, yani PMO’nun katkısı, farklı projelerin birbirlerine verdiği taahhütleri ortak bir görünümde ele alarak toplam teslimat riskini yönetmektir.

Neden önemli?

Bir proje kendi planına göre ilerlerken başka bir projenin teslimatını geciktirebilir. Altyapı ekibi geliştirmeyi tamamladığını söyler, fakat ürünü kullanacak ekip için erişim onayları ve test ortamı henüz hazır değildir. İki rapor da kendi sınırları içinde doğru olabilir. Ortak hedef ise risk altındadır.

Bu durum yöneticilere yanıltıcı bir güven verebilir. Her proje ayrı ayrı olumlu raporlanırken müşteriye sunulacak bütün çözüm gecikebilir. Çünkü proje raporları, ekiplerin kendi işlerini anlatırken aralarındaki geçiş koşullarını yeterince göstermemiştir. Yönetim, sorunu teslim tarihinde öğrenirse seçenekleri daralır; öncelik değiştirmek, kapsamı düzenlemek veya geçişi aşamalara bölmek için daha az zamanı kalır.

İş analisti, gereksinimlerin arkasındaki bağımlılıkları ortaya çıkarabilir. Ürün sahibi, başka ekiplerin katkısını dikkate alarak uygulanabilir bir öncelik sırası kurabilir. PMO ise tek proje yöneticisinin yetkisini aşan kaynak ve karar çatışmalarını görünür kılabilir. Burada asıl değer, herkesi sürekli toplantıya çağırmak değildir. Doğru kişilerin, seçenekler hâlâ açıkken karar verebilmesidir.

Bağımlılık yönetimi yatırım değerlendirmesini de etkiler. Beklenen fayda, yalnızca yeni özelliğin geliştirilmesine değil, kullanıcıların onu kullanabilmesine bağlıdır. Eğitim, süreç değişikliği veya işletim hazırlığı eksikse teknik teslimatın tamamlanması ekonomik sonucu kendiliğinden üretmez.

Terim nedir?

Bağımlılık, bir çalışmanın başlaması, tamamlanması veya hedeflenen sonucu üretmesi için başka bir girdiye ihtiyaç duymasıdır. Proje içindeki faaliyetler arasında bulunabileceği gibi farklı projeler, iş birimleri ve tedarikçiler arasında da ortaya çıkabilir. Yönetim yöntemi, ilişkinin etkisine ve tarafların yetki alanlarına göre seçilmelidir.

Bağımlılık ile risk aynı anlama gelmez. “Test için onaylanmış müşteri verisi gerekiyor” bir bağımlılıktır. “Verinin zamanında onaylanmaması testleri geciktirebilir” ise bu bağımlılığa ilişkin risktir. Onay tarihi geçmiş ve testler başlamamışsa artık gerçekleşmiş bir sorun da vardır. Bu ayrım, kaydın yalnızca olasılık tartışması olarak kalmasını önler.

İhtiyaç tarihi ve taahhüt edilen teslim tarihi ayrı tutulmalıdır. Ayrıca teslimattan sonra doğrulama, kurulum veya uyarlama için süre gerekiyorsa bu süre plana eklenmelidir. Girdinin teslimi ile kullanılabilir hale gelmesi arasındaki boşluk, takvim değerlendirmesini değiştirebilir. Tek bir tarih yazmak bu farkı saklar.

Bir bağımlılığın yönü de önemlidir. Siz başka bir ekipten girdi beklerken başka ekipler de sizin çıktınızı bekliyor olabilir. Yalnızca alınacak girdilere bakmak, verilen taahhütlerin etkisini ihmal eder. Bu ilişkiler haritalandığında ortak bir bileşenin veya kararın çok sayıda işi etkilediği görülebilir. Harita kapsamı anlatır; izleme için somut teslim koşulları ve karar sorumluları gerekir.

Gerçek vaka: Kanada Savunma Bakanlığında projeler arası bağlantılar

Luc Audet, Eric McEwan ve Eric Sargent’ın PMI tarafından yayımlanan 2002 tarihli bildirisi, Kanada Savunma Bakanlığının bilgi yönetimi ve bilgi teknolojileri portföyünde geliştirdiği projeler arası bağımlılık yönetimini anlatır. Uygulama, bağımlılıkları tanımlama ve doğrulamanın yanında düzenli izleme ve yönetim kararlarını desteklemeyi de içerir.

Bildirideki bir örnekte, sanal özel ağın, yani VPN’in başlangıçta düşünülen yetenekleri bütünüyle sağlayamayacağı anlaşılmıştır. Bunun görünür hale gelmesi, bağımlı projelerin kapsam ve takvimlerinin etkileri büyümeden düzenlenmesine yardımcı olmuştur. Başka bir örnekte, dijital imzayı destekleyen açık anahtar altyapısı projesinin bağlantıları incelenirken dijital imza kullanımını yetkilendirecek kurum genelinde bir politika ihtiyacı ortaya çıkmıştır.

Bu örneklerin işaret ettiği nokta, bağımlılıkların yalnızca teknik bağlantılardan oluşmadığıdır. Bir çözüm çalışsa bile onu kullanma yetkisi eksik olabilir. Bildirideki anlatım, bu uygulamaların bütün kurumlarda aynı sonucu vereceğini veya belirli bir tasarruf sağlayacağını kanıtlamaz; somut yönetim kullanımını gösterir.

Kaynak: Luc Audet, Eric McEwan ve Eric Sargent, “Project interdependency management”, PMI, 3 Ekim 2002.

Varsayımsal örnek: Kurumsal faturalandırma özelliğinin yayına alınması

Bir abonelik yazılımı şirketi, kurumsal müşteriler için yeni faturalandırma özelliği geliştirir. Ürün ekibi fiyatlandırma kurallarını belirlerken finans ekibi vergi ve muhasebe kurallarını doğrulayacaktır. Ödeme sağlayıcısının test onayı ve güvenlik ekibinin erişim kararı da yayına çıkış için gereklidir.

İlk planda “Ödeme entegrasyonu tamamlanacak” yazmaktadır. İş analisti bu ifadeyi sorgular: Bağlantı kurulması mı, başarısız işlemlerin ele alınması mı, sağlayıcının onayı mı, yoksa finansın işlemleri doğrulayabilmesi mi kastedilmektedir? Taraflar aynı sözcüğe farklı anlamlar yüklediğinde takvim üzerindeki anlaşma gerçek bir taahhüt oluşturmaz.

Ekip, kullanıma hazır teslimatın koşullarını birlikte tanımlar. Test senaryoları, gerekli erişimler, hata durumları ve onay kanıtları netleştirilir. Girdiyi sağlayan taraf teslim sorumlusunu; kullanan taraf ise kabul sorumlusunu belirler. İhtiyaç tarihi, teslimden sonra yapılacak kontroller dikkate alınarak hesaplanır.

Sağlayıcının onay süreci uzayabileceğini bildirmesi üzerine PMO, etkilenen ürün ve müşteri geçişlerini birlikte değerlendirir. Seçenekler arasında yayını ertelemek, uygun müşteri grubuyla sınırlamak veya onay gerektiren bölümü ayrı aşamaya taşımak bulunabilir. Her seçenek için müşteri deneyimi, işletim yükü ve finansal kontrol etkileri incelenir.

Yöneticiye yalnızca “Bağımlılık riskli” denmez. Hangi kararın ne zamana kadar verilmesi gerektiği açıklanır. Geçici çözüm düşünülüyorsa sorumlusu, sınırları ve sona erdirilme koşulu tanımlanır. Böylece kısa vadeli bir önlem, sessizce kalıcı işletim yüküne dönüşmez.

Yaygın üç hata

  1. Beklentiyi karşı tarafın taahhüdü sanmak. Bir plana başka ekibin teslim tarihini yazmak, o ekibin tarihi kabul ettiği anlamına gelmez. Teslimat içeriği, kabul koşulları ve kapasite iki tarafça doğrulanmalıdır. “Haberdarlar” ifadesi yeterli değildir. Gerçek taahhüt, anlaşmazlık çıktığında hangi referansa dönüleceğini de açıklar.
  2. Yalnızca teknik bağımlılıkları kaydetmek. Veri izni, sözleşme, eğitim veya iş kuralı kararı son aşamada ortaya çıkarsa çalışan çözüm kullanılamayabilir. Gereksinim görüşmelerinde “Bu sonucu kullanabilmek için kim neyi değiştirmeli veya onaylamalı?” sorusu sorulmalıdır. Bu soru, görünmeyen kurumsal hazırlıkları erken açığa çıkarır.
  3. Gecikmeyi yalnızca iki ekip arasında çözmeye çalışmak. Aynı girdiye birden fazla proje bağlıysa bir ekibe verilen öncelik diğerlerini etkileyebilir. Sorunu karar yetkisi bulunan seviyeye taşımak, yani eskalasyon, suçlama amacı taşımaz. Etki, seçenekler, öneri ve kararın son tarihi birlikte sunulmalıdır. Aksi halde yöneticiden çözüm beklenir ama karar verecek bilgi sağlanmaz.

Mini uygulama: Bir bağımlılığı iki tarafla doğrulamak

Mevcut projenizde başka bir taraftan beklenen kritik bir girdiyi seçin. Aşağıdaki kaydı önce kendi ekibinizle, ardından girdiyi sağlayacak tarafla tamamlayın.

Bağımlılık kimliği
—
Girdiyi kullanacak teslimat
—
Beklenen girdi ve kapsamı
—
Kullanıma hazır olma koşulları
—
Sağlayan taraf ve sorumlusu
—
Kullanan taraf ve kabul sorumlusu
—
Girdinin gerekli olduğu tarih
—
Taahhüt edilen teslim tarihi
—
Teslim sonrası doğrulama ihtiyacı
—
Gecikmeden etkilenecek diğer işler
—
Erken uyarı işaretleri
—
Alternatif çözüm ve sınırları
—
Karar yetkilisi ve kararın son tarihi
—
Son doğrulama tarihi ve kanıtı
—

Kaydı gözden geçirirken yalnızca tarih değişikliğini sormayın. İçerik, kabul koşulları veya sorumlu değişti mi, kontrol edin. Bağımlılığı, dosya gönderildiğinde değil, gerekli girdi kabul edilip kullanım koşulları sağlandığında kapatın. PMO, tekrar eden bağımlılık sorunlarını inceleyerek ortak planlama ve karar süreçlerini iyileştirebilir.

İlgili terimler

Work Breakdown Structure, Critical Path, Integrated Master Schedule, Resource Capacity Planning, Risk Register, Issue Management, Escalation, Interface Management, Stakeholder Management, Acceptance Criteria, Change Control, Portfolio Management